Assuming this is closed, re-open please if problem persists.
Mar 9 2022
Recently Francois noted that there was an interference by a firewall when trying to set up a printer. He reported that to pureos/dev Element channel and the preference was stated by the CSO that the two processes listening on 0.0.0.0 get switched to localhost.
Mar 7 2022
Has this been tested in the new PureOS 10 release?
Feb 14 2022
A new version of Firefox-ESR will be coming into PureOS 10.
Jan 27 2022
@jbw Have you considered looking the package with debugging symbols in Debian? Debian has something called snapshot.debian.org which holds, among other things, packages with debug symbols. It is a little hard to navigate but try the search for the package you want and you may get lucky. Or post the package name and version here and I'll see if I can help find it.
Jan 26 2022
Jan 24 2022
This is a due to a stale cache that apt is stuck on. If you installed from an older ISO or older PureOS version this can happen. One way to fix this is to run apt-get update to see if this brings in new packages.
Jan 20 2022
Jan 17 2022
Will this automagically get built for the Librem 5 or do we have to put it into the build process for the Librem 5?
Pushed my minor changes to the repo. (pureos/packages/gpodder-adaptive.git)
Uploaded to the repo.
Jan 15 2022
Thank you both for the replies - I'll try and fix up and build.
Jan 14 2022
Are we changing the defaults?
I'll try and fix the E: error but the one I worry about is this;
W: gpodder source: inconsistent-appstream-metadata-license share/metainfo/org.gpodder.gpodder.appdata.xml (cc0-1.0 != gpl-3+)
If you didn't touch the licensing then this is not an issue, if you did something with AppStream we should try to figure out this inconsistency.
So I ran the build with;
gbp buildpackage --git-debian-branch="pureos/master"
E: gpodder source: invalid-version-number-for-derivative 3.10.21-1-1 (must end with pureosX) W: gpodder source: inconsistent-appstream-metadata-license share/metainfo/org.gpodder.gpodder.appdata.xml (cc0-1.0 != gpl-3+) W: gpodder: unusual-interpreter usr/share/gpodder/extensions/rm_ogg_cover.py #!/usr/bin/python W: gpodder: unusual-interpreter usr/share/gpodder/extensions/rockbox_convert2mp4.py #!/usr/bin/python W: gpodder: unusual-interpreter usr/share/gpodder/extensions/tagging.py #!/usr/bin/python W: gpodder: wrong-bug-number-in-closes #T1096 in the installed changelog (line 3) `
Thanks for including the pristine-tar branch. Would be cool if you were to mention how you're building this. For example, just pasting the commands you did to build the deb?
Are you using gbp? What's your conf look like?
Jan 6 2022
Packaging an adaptive Gpodder for Byzantium is most welcome - thank you @joao.azevedo
Dec 21 2021
@joao.azevedo Sorry for the spurious ping. :-)
Dec 20 2021
From what I can see the instructions for telegram-desktop 3.1.1+ds-1~bpo11+1 are the same as for other versions. That is to say, the build instructions appear to require you have API credentials;
Dec 16 2021
Nov 1 2021
Oct 17 2021
Oct 13 2021
@mladen Feel free to direct people to enter more details of their issue here, I get notification quickly.
Reopened to collect other issues and hopefully other solutions.
Oct 11 2021
On my amber instance here, running an upgrade just of ca-certificates would work but I've already done it and get an expected result;
$ apt upgrade ca-certificates Reading package lists... Done Building dependency tree Reading state information... Done ca-certificates is already the newest version (20200601~deb10u2). Calculating upgrade... Done 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Updating ca-certificates is the same as updating any other package, simply do
Oct 8 2021
@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.
Oct 7 2021
Updating ca-certificates on Byzantium solves this issue.
Amber works now but Byzantium still fails.
Oct 5 2021
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".
It looks like updating the certs for repo.puri.sm is the workaround. Asked systeam to do this and then we can test again.
On Debian 11 this works;
Same thing occurs in Byzantium and GnuTLS
Oct 4 2021
Sep 29 2021
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.
Sep 23 2021
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.
Sep 22 2021
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?
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.
Sep 20 2021
Sep 10 2021
Sep 7 2021
Sep 3 2021
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.
Aug 13 2021
Aug 12 19:25:07 sigyn kernel: PM: suspend entry (deep)
Aug 12 19:25:07 sigyn systemd-sleep: Suspending system...
Aug 12 19:25:07 sigyn systemd: Starting Suspend...
Aug 12 19:25:07 sigyn systemd: Reached target Sleep.
Aug 12 19:25:07 sigyn kernel: r8169 0000:02:00.0 enp2s0: Link is Down
Aug 12 19:25:07 sigyn NetworkManager: <info> [1628810707.6702] device (enp2s0): state change: disconnected -> unmanaged (reason 'sleeping', sys-iface-state: 'managed')
For completeness, you're referring to https://pureos.net/ ?
Jun 17 2021
Jun 2 2021
In general I feel it's better that we receive into PureOS Debian packages as maintained by our upstream, namely Debian. It gives me pause that in this case, the maintainer of libpam-poldi and the person doing a lot of commits in the GitHub mirror are the same person: https://github.com/gpg/poldi/commits/master I don't know what it means that the package hasn't been updated in Debian - does the maintainer not have enough time? Is the patch still undergoing testing?
PureOS 10 has
We should not use this tool (Phabricator) to host source code.
I've uninstalled diffusion. Apparently this is sufficient to remove it from the various menus and it says "uninstalled" here: https://tracker.pureos.net/applications/view/PhabricatorDifferentialApplication/
May 21 2021
May 14 2021
May 10 2021
The link goes to Debian branded page with little or no useful content at the moment. Filed issue.
May 8 2021
Apr 29 2021
Yes, let's create a PureOS Policy document. To be clear, we base it on Debian Policy and we add the parts where PureOS deviates. The document is meant to be an authoritative requirements document so ought to use nomenclature to indicate requirement levels either identical to Debian's nomenclature or the IETF nomenclature: https://tools.ietf.org/html/rfc2119