I'll inquire with MLS to see how we get a key.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Mar 18 2021
Mar 17 2021
Mar 16 2021
Are we trying to get an API key from Mozilla Location Services?
What are we trying to achieve?
I don't know if we have a formal policy around the Mozilla location services though I don't think we should be using Debian's. I think we need to create a policy or at least have a process to do so.
Mar 15 2021
Mar 11 2021
Mar 9 2021
Good points.
Mar 8 2021
I made the changes to the debian/control file (maintainer email address, VCS-*) mandatory.
I can confirm this;
I did two runs of 1000 calls to the server and did not see any anomalies.
Certificate version: 3 Valid from: Oct 7 19:21:40 2020 GMT Valid to : Sep 29 19:21:40 2021 GMT Public key is 2048 bits The issuer name is /O=Digital Signature Trust Co./CN=DST Root CA X3 The subject name is /C=US/O=Let's Encrypt/CN=R3 Extension Count: 8 Peer certificate Certificate version: 3 Valid from: Feb 27 18:12:29 2021 GMT Valid to : May 28 18:12:29 2021 GMT Public key is 2048 bits The issuer name is /C=US/O=Let's Encrypt/CN=R3 The subject name is /CN=downloads.pureos.net Extension Count: 9 Transport Protocol :TLSv1.2 Cipher Suite Protocol :TLSv1.2 Cipher Suite Name :ECDHE-RSA-AES128-GCM-SHA256 Cipher Suite Cipher Bits:128 (128) SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES128-GCM-SHA256 Session-ID: 39DB1E294804DA2D5AB727DE4CF12062B4FA46A36F9DFA278CD675B3535CE0FD Session-ID-ctx: Master-Key: BCF95A63D726D1B9685B5293C6212D1CBD8620E94904D9D3A4CA8B6A9EAA6CF5976F668441B9F8F4DF24A70F457C5422 PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 86400 (seconds) TLS session ticket: 0000 - b1 a5 92 f4 25 9b 67 fc-d5 c9 5e 0b 0d ba e7 5e ....%.g...^....^ 0010 - 66 2e d9 f2 68 3a 4f e9-3e 00 9d 33 7b e2 66 49 f...h:O.>..3{.fI 0020 - ff 93 f6 af 6a a0 64 7b-84 eb fc 07 f1 bf 10 ba ....j.d{........ 0030 - 48 55 66 ca 4a 9e 44 de-3b 5e 7b f9 e0 e9 23 6a HUf.J.D.;^{...#j 0040 - 88 6f 52 da 28 43 c3 92-2b 9a da f7 d4 f1 3b 9c .oR.(C..+.....;. 0050 - 2e 6f 9c a3 71 78 cf f2-4d e6 b1 62 16 87 c3 01 .o..qx..M..b.... 0060 - 58 7d b4 9f 89 e2 e2 98-39 71 3b bd 05 06 5d 22 X}......9q;...]" 0070 - 0e b6 fc 17 2c 86 08 13-3c e3 65 24 a3 7b 45 9a ....,...<.e$.{E. 0080 - 31 10 70 30 1e d7 64 92-09 b4 10 bf 09 e9 be 10 1.p0..d......... 0090 - 18 56 32 e6 60 bf 0f 24-10 ae df 8f 48 b9 8f 48 .V2.`..$....H..H 00a0 - 1c e3 fa bc 2b a7 d2 52-da 1f cf 28 d1 01 cd 95 ....+..R...(.... 00b0 - 91 6b c6 b2 9d 60 96 a1-24 51 18 92 19 c9 ab 3b .k...`..$Q.....;
Server Software: nginx/1.10.3 Server Hostname: repo.pureos.net Server Port: 443 SSL/TLS Protocol: TLSv1.2,ECDHE-RSA-AES128-GCM-SHA256,2048,128 Server Temp Key: X25519 253 bits TLS Server Name: repo.pureos.net
Mar 3 2021
Mar 2 2021
Feb 26 2021
Feb 18 2021
Phabricator's API is called conduit. I can pull data from conduit and it looks like this;
Feb 17 2021
Feb 16 2021
I think "blobs" is tricky terminology which might confuse - it confuses me. I prefer talking about 'firmware'. Firmware is stored in Read Only Memory (ROM) as a binary. It usually cannot be changed and it just meant to make the hardware work at all. The FSF says "Firmware that is installed during use is software; firmware that is delivered inside the device and can't be changed is software by nature, but we can treat it as if it were a circuit." This makes firmware closer, or even the same as, hardware. And while all hardware should have free designs, like Purism's, we don't have to reject non-free hardware the way we have to reject non-free software according to the FSF.
Do we need or want a channel from Gitlab to Matrix too?
Is this a Tracker <--> Matrix channel? We already have #dev/pureos-changes so you don't mean that channel I assume.
Feb 15 2021
I've been informed that it is at least *theoretically* possible to point snapd to a only free "store" https://forum.snapcraft.io/t/external-repositories/1760/7
This might help us not have to remove snapd and then patch and maintain all the software that depends on snap and snapd.
Might be cool to put that documentation here: https://tracker.pureos.net/w/development/
Feb 12 2021
Feb 11 2021
nginx error log on Artemis is saying:
Feb 10 2021
Get:289 https://repo.pureos.net/pureos byzantium/main arm64 xdg-user-dirs arm64 0.17-2 [53.2 kB]
E: Failed to fetch https://repo.pureos.net/pureos/pool/main/c/chardet/python3-chardet_4.0.0-1_all.deb Error reading from server - read (5: Input/output error) [IP: 138.201.228.45 443]
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?
Fetched 94.6 MB in 9s (10.1 MB/s)
@guido - have you seen this issue?
This should be fixed in later versions.
Similar issue:
Feb 5 2021
The idea of "shadowing" upstream or downstream as the case may be seems pretty useful though my brain is more accustomed to having the PureOS version of a package be higher.
Feb 3 2021
Jan 26 2021
AppStream is more for app meta-data while apt-file basically searches a directory of ASCII text to find specific files inside packages. I'm not sure if you could use AppStream as an apt-file replacement.
Jan 25 2021
Jan 22 2021
If this is an issue with Thunderbird, it should be filed upstream
Jan 21 2021
Thanks Sebastian! Let's find another package @alvesadrian
Jan 20 2021
Jan 5 2021
In T978#17857, @mak wrote:the issue is the "Software & Updates > Updates > Automatically check for updates: Never" configuration is not preventing the system from automatically checking for updates every day.
they have to do that *and* disable updates in GNOME: "GNOME Software" > "Burger Menu" > "Update Preferences" > Toggle Automatic Updates
(as shown in the image I posted above)
Jan 4 2021
The Original Poster is stating that their use case is customers at sea who have expensive connection charges which require they disable unnecessary network communication.
The user writes back saying that they disabled GNOME Software and was unable to stop automatic upgrades. There is no effect of the GNOME Software settings observed. I think the next step on my side is to run strace on GNOME Software and settings to see what is happening (or not happening).
Dec 30 2020
It appears that one *cannot* shut off updates with GNOME Software despite the settings that would imply that this is possible. What needs to be address is apt-daily-upgrade.timer. systemctl status apt-daily-upgrade.timer says;
● apt-daily-upgrade.timer - Daily apt upgrade and clean activities Loaded: loaded (/lib/systemd/system/apt-daily-upgrade.timer; enabled; vendor preset: enabled) Active: active (waiting) since Fri 2020-12-11 10:07:48 EST; 2 weeks 5 days ago Trigger: Thu 2020-12-31 06:28:21 EST; 10h left Triggers: ● apt-daily-upgrade.service
This can be disabled which ought to turn off automatic updates. Stop the timer and disable this way;
sudo systemctl stop apt-daily-upgrade.timer sudo systemctl disable apt-daily-upgrade.timer
Dec 23 2020
The plan that was devised consists of two steps;
@jonas.smedegaard Did a user report this? Or is this bug from your own sleuthing? :-) I ask because sometimes the FSF rewards users who report freedom issues with GNU Bucks and there may be some at stake for reporting.
Dec 22 2020
Glad you tracked down the issue! Nice sleuthing!