I have a preliminary image with PureOS 10 for UEFI available, but some polishing work is still needed on this.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jul 11 2021
May 27 2021
Apr 17 2021
So, that RST packet is indeed the issue, and there's a high chance that either APT or GnuTLS don't handle this correctly. I talked with an APT developer, and we may actually need to debug this further in future.
In the meanwhile though, the issue can be mitigated by throwing an Apache2 webserver in front as proxy, instead of Nginx.
Apr 16 2021
Some new observations:
- This is not a proxy server issue: Even without proxy, the issue occurs
- The TLS version doesn't matter at all
- Before the issue occurs, we get quite a few TCP retransmissions from the client to the server, and then the current connection is dropped:
- There is nothing suspicious in the Nginx logs, not even at info priority. A quick glance at the debug logs also didn't show anything interesting, but those are massive and it's possible that I missed something.
Mar 4 2021
I also tried messing with timeouts on APTs transport methods, with no luck - according to APT, the server just stops responding (according to curl though, it doesn't).
I pasted the wrong log, but the connection timeout is actually even more frequent now than the Resource temporarily unavailable issue - but both appear.
I tested this with https::Verify-Peer false, still the same issue happens:
Fetched 1016 MB in 4min 12s (4025 kB/s) 2021/03/04 22:30:39 apt | E: Failed to fetch https://repo.pureos.net/pureos/pool/main/f/fftw3/libfftw3-double3_3.3.8-2_amd64.deb Connection timed out [IP: 138.201.228.45 443] 2021/03/04 22:30:39 apt | E: Failed to fetch https://repo.pureos.net/pureos/pool/main/s/spice-gtk/libspice-client-glib-2.0-8_0.39-1_amd64.deb Connection timed out [IP: 138.201.228.45 443] 2021/03/04 22:30:39 apt | E: Failed to fetch https://repo.pureos.net/pureos/pool/main/libs/libsodium/libsodium23_1.0.18-1_amd64.deb Connection timed out [IP: 138.201.228.45 443] 2021/03/04 22:30:39 apt | E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?
Feb 28 2021
Feb 11 2021
Fixed now. Apparently dak forgot a source package... Not sure how that happened, this could only occur if something was manually deleted the wrong way, or a bad database backup was restored...
It's fixed now though, and I checked for any more of this kind of issue and found none.
Noticed this too late because the warning email went straight to spam (the attached logfile apparently was suspicious).
This is caused by either a dak bug or something feeding dak bad data:
File "/srv/dist/dak/daklib/archive.py", line 164, in install_binary .filter(Suite.suite_id == source_suites.c.id) AttributeError: 'NoneType' object has no attribute 'c'
Feb 10 2021
Jan 5 2021
Has this been done? I think only sysadmins have the necessary privileges to destroy a user account, all I can do is disable them.
Then this should have worked - they should verify that /etc/apt/apt.conf.d/20auto-upgrades exists and has the correct values.
Jan 4 2021
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.
Dec 30 2020
No, disabling the timers is completely the wrong approach. The service belonging to the timer unit has built-in logic to do only what it was configured to do + some cleanup work that we always want to have done.
All you need to do to disable upgrades is to disable them in GNOME Software as well as in software-sources-gtk which is available in GNOME Software's burger-menu as well.
See the attached picture:
Dec 7 2020
Why? We want the users to stay secure by default, and disabling automatic upgrades is the opposite of that. So I think disabling updates is a huge disservice and definitely not beginner-friendly. Users who want to disable autoupdates can always do that via the respective GUI (software-properties-gtk).
Nov 26 2020
I think @adrien.plazas pushed a workaround for this recently: https://source.puri.sm/Librem5/pureos-store/-/merge_requests/14
Nov 3 2020
That depends on how the suite is set up and where it gets its overrides from - the phone suites do not share overrides with the main amber suite, so everything goes through NEW once (but that also means the changing overrides for the phone suite is easier and there is less room for error and it impacting one of the main suites).
Oct 13 2020
Those packages are available, but only for the latest builds of the development version of PureOS and only for the ones we rebuilt ourselves: https://repo.pureos.net/pureos-debug/dists/
Anything else would require mirroring the debug packages from Debian, and we do not have the disk space for that, currently.
Sep 27 2020
Did you use the OEM image or the Live image? Which version of the install ISO (date) did you use?
What is the use case for explicitly staying below a Debian revision? This may break quite a few assumptions and no Debian derivative (that I know of) does this.
Aug 16 2020
These images should now be(come) default. Thanks everyone for testing!
Aug 6 2020
Nice! If nobody vetoes this image until next Monday/Tuesday, I will send this image to the factory and marketing people - we really have to update the default image, and especially that OEM username issue is causing very frequent support issues, so it has to go (not to mention the huge amount of security fixes that newer PureOS releases contain and that just aren't there yet with the current images).
Aug 5 2020
Aug 4 2020
The image has been updated to incorporate the latest security fixed for a bunch of vulnerabilities in GRUB (less relevant for us if /boot is verified anyway, but still good to have, especially for custom installations).
This should have been resolved with the latest util-linux upload.
Aug 3 2020
At some point the intent is to make this nicer-looking and better integrated, but until that point is there, we'll have this page :-)
They were signed with an expired key. refreshging that key from a keyserver fixed this issue.
Aug 2 2020
Jul 23 2020
@all but especially @richard.kolla : Can you please test the 2020-07-22 image? There were now functional changes, only minor bugfixes from Debian and security fixes (so I expect everything to still work as before).
Jul 22 2020
Jul 20 2020
In T919#17068, @richard.kolla wrote:[...]
Does the OEM initial setup work as expected?Won't boot.
Any noticeable bugs/regressions?I erase the disk, install on my SATA SSD with the bootloader going to the MBR of the same drive. Can't boot from the coreboot 4.12-2 boot menu. Will need to confirm with Carlsbad what settings they use when installing PureOS OEM and use those same settings to test.
Jul 18 2020
Is this not something that can also be pushed to upstream g-i-s
This has been fixed in PureOS for some time now, but we'll still need an upstream solution. I'll likely push this change to Debian as well meanwhile, so Debian can benefit from the bugfix as well.
Jul 9 2020
This bug was indeed fixed by me earlier this week :-)
Jun 4 2020
What do you mean with "breaks"? Does it crash? Is it not installable? In the former case, a backzrace or at least console output would be nice.
Jun 3 2020
This should be fixed now, but the update will need a few days to migrate out of landing.
May 13 2020
It's unfortunately one with a US keyboard :-/
Apr 30 2020
Do we need a new version of the library in amber, or is there a patch that we can apply to the amber version? Uploading a new upstream version always comes with some risk of breaking other stuff (unless it's a pure bugfix release).
Apr 8 2020
Hmm, I don't have a Librem with a German keyboard so I can't test this and would have to apply this change blindly.
This looks like something that should also go into upstream systemd, right?
Feb 17 2020
Jan 8 2020
Whoops, looks like I completely forgot to close this... Thanks!
Jan 3 2020
The only thing I can say at the moment that we will have this done for the next release of PureOS. I know this is kind of vague, but at the moment I can't make a more definitive statement about it, sorry.
Most likely this feature will come with a complete overhaul of the process we use to build images for PureOS.
Dec 14 2019
Nov 20 2019
Yay!
Oct 13 2019
This should be fixed in amber now :-)
Thanks for reporting the issue!
Oct 10 2019
There are no resource limits on the container, so I have no idea what goes wrong here.
Does this code access a device that is maybe unavailable?
Unfortunately I am traveling in the next weeks, so I don't know if I'll have time to look into this.
Oct 8 2019
Done :-)
The update should be available once it passes QA and the regular delay period.
Sep 26 2019
This is fixed in PureOS 9.0 (Amber) image build 2019-09-26.
Thank you for reporting the issue!
Sep 20 2019
We may need to add some note then that it's "community supported" or something.
I build the image and somewhat maintain the flavor, but it doesn't receive nearly as much attention as the GNOME flavor does and any issue report there as a really low priority for me.
Jul 29 2019
Thank you for the feature request, but unfortunately we'll definitely not have cdrtools in PureOS.
There has been an old fight about its license change which I really don't want to start again. Also, the legal situation didn't really change and Debian, the FSF and Red Hat all agree on this particular legal issue.
Plus, to put it frankly, Jörg Schilling is one of the least fun upstream developers one could ever deal with.
Jul 15 2019
This has been updated a few days already, but the new images weren't fully tested yet (so aren't on the pureos.net page for download by default). That should happen this week.
Thanks for the heads up though!
Jul 2 2019
In T57#14719, @jonas.smedegaard wrote:@mak Please stop block chromium - it does not contain non-free code and is no longer unclear about licensing.
Jun 27 2019
See https://software.pureos.net/sw/linphone.desktop
(there is still a warning that the icon is upscaled, which could be fixed in the packaging)
This seems to be fixed now - sort of...
Jun 20 2019
Well, the message was a false and the actual culprit was a SQL query failing. The cause of that is fixed now, so this shouldn't happen again (but if it does, I'll look into it again). Not sure why exactly the database was in a wrong state though, but that's really hard to figure out at this point.
That's why the issue is resolved.
@jonas.smedegaard No, I mean the same file (without it being rebuilt) was apparently already uploaded and rejected before. Dak hashes the files to not process the same, already rejected upload multiple times (even if it has different names) - and to prevent people from just uploading the same thing over and over again.
That said, this case is really strange, as the upload actually wasn't known before, as far as I can see in the database.
I forced the package in now, it is available in the landing suite now (and will be built soon), but I'll keep an eye on this issue - could maybe be a bug in dak.
Jun 19 2019
According to dak and the SHA256 hash of the package, the upload is indeed already known and would just be rejected again - can you rebuild the package again and do another upload?
TBH it is *really* weird that the package is rejected, as I would expect to find the originally rejected upload in the rejected queue, but that doesn't appear to be there.
So if your next upload doesn't succeed, let me know immediately! (I also made dak forget about the last upload attempt).
Jun 13 2019
Jun 10 2019
Hmm... I can't reproduce this either and looking at https://repo.pureos.net/pureos/dists/green/InRelease all dates are correct.
May 11 2019
Well....
Version check failed: Your upload included the source package librem5-devkit-tools, version 0.0.2, however landing already has version 0.0.2. Uploads to landing must have a higher version than present in landing.
Looks like this version is already in (I see it in all suites):
librem5-devkit-tools | 0.0.2 | green | source librem5-devkit-tools | 0.0.2 | landing | source librem5-devkit-tools | 0.0.2 | purple | source
May 10 2019
@guido You're absolutely right, sorry - I was confusing the .dsc and .changes files somehow (the former already has all the necessary information).
Apparently the architecture in your previous changes file was not (only) set to source, and therefore a non-source upload was suumed, which does required the Binary field.
Anyway, to make some progress on this, can you please attempt another upload? I am curious at what dak has to say to that, and if it gets rejected again, I can debug the issue further looking directly into dak to determine why it things the package is unsuitable.
May 9 2019
You can also maybe circumvent the issue by doing a binary upload, but it would actually be useful to know what went wrong here.
Ok, weird - maybe just build it again and see what happens (the dpkg version in the chroot env also needs to be high enough).
Very strange... Do you happen to have the package built with dpkg << 1.19.3?
You need at least that version to generate a valid package.
Done - the package was actually already synced, I just forgot to close this issue.
The new changes were stuck in testing though, due to a dependency issue, which is now fixed as well (so expect the package to become available soon).
May 7 2019
@Gnutella If it's just changes like a different slideshow, icon, colors and logo image then yes, that's possible - I already did that once.
That said, the GNOME flavor is currently the focus of development, the Plasma flavor is less well maintained (so focusing on GNOME as long as it doesn't completely break the Plasma installations would also be fair).
May 5 2019
Package is updated in landing and will soon migrate to green.
May 4 2019
I wondered about that as well, turns out the package priority changed from optional to important.
I adjusted the override now, so the package can be removed again and should no longer be present in default installations.
This is now a new issue, caused by a change in lsb-release which was switched to exclusively read /etc/os-release and started to capitalize the distribution-ID, which works for Debian, but not for PureOS.
I submitted a patch upstream: https://salsa.debian.org/debian/lsb/merge_requests/1
This has been fixed for a while now, can you try again with the latest PureOS Plasma image (>> 2019-05-04)?
May 2 2019
This is fixed in gnome-control-center 3.30.3-1pureos1. After you installed this version, desktop-base can be removed (and ideally will be autoremoved).
Since PureOS *still* doesn't have any proper logo, I just reset the logo to the default GNOME one.
Jup, reason being that the displaymanager isn't configured. This was once disabled on purpose, I just don't remember why, unfortunately.
I re-enabled the feature, the next live image should have it if there aren't any drawbacks to having it (I can't see any issues, the only potential clash would have been with the OEM installer, but we don't run the module there anyway).
This is because gnome-control-center suddenly started to pull in desktop-base.
I'll look into this.
This is fixed in python-apt >= 1.8.4pureos1 - please verify that this works for you. The new version should reach the green channel in a few days.
Hmm... This is the last changelog entry for python-apt:
python-apt (1.8.1pureos1) green; urgency=medium