Screenshot works for me (it's not adaptive and only capturing the full screen works) but I use it all the time.

This is resolved now - please test the images available on https://downloads.pureos.net/byzantium/ (preferably the latest ones built ^^) as I could only test this on a few systems and configurations that I had available. The images should support UEFI, as long as secure boot is not enforced, as the necessary pieces are not signed.

@lo0 You may be right. My original URL was tested and now fails. I'm having trouble connecting to the new URL however so cannot confirm.

@jeremiah.foster I believe the sonic url is actually https://mirrors.sonic.net/pureos/repo/pureos/

Updating ca-certificates on Byzantium solves this issue.

Amber works now but Byzantium still fails.

...or in this case, package repos (plural) as this issue affects both Amber and Byzantium.

thanks, @evangelos.tzaras - but you guessed correct: please only close when done from a user perspective, i.e. when fix has reached target repo.

With https://source.puri.sm/Librem5/debs/pkg-phosh/-/merge_requests/21 merged this can be closed (unless it's preferred to wait for a new release incorporating those changes reaches the archive)

My understanding was that in Debian they updated the buildd chroots. In any case, Stelios writes; "very likely an issue client side. a few days ago intermediate lets-encrypt certificates expired ,workaround on older debian systems was to drop the line DST from /etc/ca-certificates.conf and run update-ca-certificates its not a server side issue its a client side issue".

We certainly can't update the system's certificates store, as that would mean people couldn't get the update that lets them get updates again :-P

It looks like updating the certs for repo.puri.sm is the workaround. Asked systeam to do this and then we can test again.

More here: https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/1944481

On Debian 11 this works;

Same thing occurs in Byzantium and GnuTLS

@jonas.smedegaard
Ahh, right! Thanks for pointing. I happily agree an that.

Please (for future sake, if not this one) note that this issue tracker should be tracking user-visible targets, not staging targets like "landing".
I.e. not option e) but option g) at https://tracker.pureos.net/T553#18719

With the help by Guido we managed to get this addition into landing. So closing this issue.
https://software.pureos.net/package/src/landing/lollypop

The packaging effort for seahorse has now reached landing so this issue can be closed.
https://software.pureos.net/package/src/landing/seahorse

Since I just saw this issue on the byzantium board I've opened https://source.puri.sm/Librem5/debs/pkg-phosh/-/merge_requests/21
/cc @guido

This should be resolved in byzantium already :-)

Does this issue still exist? I changed the image build process quite a bit, so the current images are not comparable to the old ones.

This should be fixed in landing/byzantium for a while now :-)

I would rather add a search function to this, as this page can get extremely large (to the point of hanging up a browser tab).
Currently, the database has indices (no dedicated fulltext searches), but with that one could already implement a simple search. Added to the todo list, but as usual, patches welcome :-)

I guess this is changing. I found: 0001-general-Remove-option-to-bypass-delete-confirmation.patch. I guess I will look for a new File Manager that lets me work the way I wish. Thanks.

Actually, this bug doesn't just affect alt-menu symlink creation - anything done with a nautilus alt-menu is affected and kills nautilus (even simply clicking outside of the alt-menu)

Please help me to understand. Why would an upstream change be reflected in Purism's version, but not Debian 11 (bullseye) at the same level?

It may have been upstream that made these changes, if so, the bug ought to go there.

We need more information. Perhaps the version of Plasma they're using and a screenshot if possible?

dpkg is now at version 1.20.9pureos2 thanks to uploads by Sebastian this July.

nice, I have no criticism :D

Feedback in the Debian derivatives list agrees with Carstens proposal, so I withdraw my alternative proposal.

This issue is now raised in Debian Derivatives team: https://lists.debian.org/debian-derivatives/2021/09/msg00006.html

I think it is wrong needless busywork to rename original Uploaders field: During the lifetime of a forked package it is sensible to know who maintains the non-forked package (the Maintainer field) but not really relevant to know who was responsible of uploading within the upstream distribution (the Uploader field).

Issue description updated to not mention experimental.

Just FTR, we can't binary-sync anything from experimental, ever. Packages there are built with other binaries from experimental, which would break any suite we sync them into. Source syncs can work though, but will need support implemented in Synchrontron in Laniakea.

To me, this Lintian check actually makes little sense. The one for Maintainer is important, so the maintenance status is reflected in the modified package, but Changed-by could be any address. When Zlatan and I created the project, the initial goal was explicitly to get the community involved and have people outside of Purism contribute. That didn't really work out, but by limiting change authors to people with an @puri.sm address we make this even less likely and also make the project look a lot more like a Purism inside job than is good for it ;-)

This was a bit tricky, as byzantium is still an in-development release and all changes should go through landing. Fortunately though, the synchrotron Laniakea module is flexible enough nowadays to accommodate for that.
I've implemented a solution which will fill up the -updates and -security suites directly for byzantium from the respective bullseye suites, while not allowing manual uploads from us which should still go through landing. That workflow should work well for byzantiums current odd in-between state between "released" and "in-development".

I've prepared a setup on https://source.puri.sm/carsten.schoenert/seahorse

@carsten.schoenert happy to help here, first good step would be a MR against the above repo with the necessary changes. I usually do

Oh I see. This means that d/control email address can be arbitrary but the uploading key must be in the keychain. Thanks for the clarification. In such case we ought to mark it as pedantic (or just info) in Lintian.

@carsten.schoenert Excellent!

@jonas.smedegaard
Let's call it a first challenge. ;)

The linitan check is about the fields in d/control. I doesn't care who signs/uploads the package later on.

The name "Hephaestus" is going to be deprecated and removed in favor of just the version number, e.g. PureOS 9 Amber, Pureos 10 Byzantium, etc.

Sorry for the open/close ping pong but the issue is still there (and not a dup, i'll clarify in the other issue).

For completeness, you're referring to https://pureos.net/ ?

@carsten.schoenert i've created https://source.puri.sm/pureos/packages/lollypop by mirroring https://salsa.debian.org/python-team/packages/lollypop.git (see https://source.puri.sm/Librem5/librem5-dev-tools/-/issues/1 for the steps) since i wasn't sure if you have all the permissions set up yet.

@carsten.schoenert, will you have the honour?

I was intructed on the pureos-project mailinglist that if the latest package in Debian is a clean backport and I haven't seen any regressions, then the simplest solution is to simply backport that from unstable to byzantium.

@jeremiah.foster Please share your opinion on this issue, as it seems @mak is too busy to work on it.

See https://forums.puri.sm/t/pureos-better-integration-with-pureboot/14765

Won't users have to sign the package with their email address? So won't the email address have to be in the keyring? Or is there a workaround?

It's not a rejection reason (afaik Laneakia doesn't reject based on linitan errors yet) so likely not security relevant or am i missing something?

Will have a look at this over the weekend, shouldn't be that difficult on the technical side.

This is a good question. Since it affects security in the archive I'd like to have consensus and have Matthias' view.

I think this is an issue with the runtime that Gitg uses.

Morning @carsten.schoenert I was told that this ticket should be brought to your attention.