What usually happens is that you debootstrap green and then just add the landing repository (either replacing green, or on top).
Oddly though, that's not mentioned in https://tracker.pureos.net/w/development/pbuilder_environment_quick_setup/ even, so I think the docs need some update to reflect the current state of things (even if we add a landing suite to debootstrap later).

@mak then what about

Well, 2 months later Thunderbird is still 1:52.4.0 in PureOS :/

Yeah, this looks like a sideeffect of the arm64 architecture addition (which shouldn't have happened).
This should fix itself soonish, I will monitor the issue though in case it doesn't.

@mak remove and block from re-entering the chromium package from archive as GNU-libre ML is pointing this out.

PureOS does not intend to add i386 at this point nor in future unless compelling reason is there as it takes engineering time to add an arch and maintain it. Someone could probably compile wine to use 64bit libs only (though I didn't test it and how limited usage would be).

:p

An extra thing that we can do is to make sure that new PureOS users are part of the kvm group?

That's intentional, because landing is/was not supposed to be bootstrapped. It's original intent was just a playground like experimental, while the real deal is green.

@mak should I create a separate task for the pipe issue?
The situation is very confusing to me. Pipe worked when I received my German Librem13V2 a few days ago, now it no longer works.
I'm wondering if this is a result of T328 (fixing US, breaking DE?), but I can't tell.
However, two other users previously reported that it stopped working: https://forums.puri.sm/t/librem-13-backslash-key-generates-less-than-symbol/2133
This makes me wonder if it could be a weird sideeffect of ME-disablement / hardware initialization.

@ah_purism Have you selected a German keyboard layout in System Settings --> Region and Language --> Input Sources? (click the plus symbol, then the dots and search for the German keyboard layout you want)

This is a very weird glitch, as it seems like the package is present, but its override was not added as well (and therefore it doesn't show up in the output files).
I will take a look at this, hopefully this does not affect other packages as well.

For the impatient, there is now an initial experimental image to test, demoing the new changes.
I don't want to receive bug reports for that just yet, because I haven't tested it a lot myself yet and there are quite a bunch of issues that I am already aware of.

I think you're mixing up hardware layout (or labeling) and software layout. If you select a German layout, Z will yield z.

@guido Packages recompiled in different environments do produce different behavior though. A lot of packages have Ubuntu/Tanglu/PureOS specific configurations that get enabled when (re)built on a particular system.
Also, lots of software enables different codepaths depending on which version of a particular shared library it was compiled against. Additionally, unless there is a symbols file in a Debian package, the Debian package will always depend on at least the shared library version it was compiled against, meaning that you can not selectively pull a few package from a particular suite and expect the result to work.

(this relates to the original topic of recompiling packages not about having to rebuild because we carry patches)

(seems I forgot to actually post this yesterday)

Texmaker is updated in PureOS now :-)

This was taking far too long on the Debian side for a new package to be uploaded, therefore I just did a dummy upload to reset the changes.
As soon as a newer package is published in Debian, it will automatically by synced to PureOS, removing the delta entirely.

That's a good behavior. Thanks again.

@heather.ellsworth Jup, this feature would be rather straightforward to implement.
The tough bit implementation-wise would be to make Synchrotron selectively only sync source packages. At the moment, there is only a global switch for whether binary packages should be synced or not.

Since recompiling unstable packages in PureOS is recommended, is it just as easy as adding a source site to a list and then that site is polled for updates? I am assuming that these packages are auto compiled by the build system?

FWFIW In the current iteration the screens shield will still show up after a while, but the screen will not be locked anymore. So there should be no instances where someone would need to enter a password.

No, it is not always needed to recompile - Debian packages are *never* recompiled when moving from unstable to testing.

This issue seems to have been resolved for me in the latest PureOS update, version 8.0
Thank you for your work!

I just tried vagrant (using libvirt) and it works, but gnome-boxes does not.

Perfect. Thank you @mak !

Thank you @mak !

To clarify - and address the comments from @heather.ellsworth above:

I am aware that we can recompile.

This is fixed as part of my live session and live-build rework.
I will publish some initial images for testing soonish.

This is fixed as part of my live session rework.
I will publish some initial images for testing soonish.

Deviations from Debian are - in a way - tracked at a global level at http://master.pureos.net/synchrotron/ - going to a per-patch level would be nicer, but this page already gives an overview of packages that have been modified in PureOS and where a newer version of them is available in Debian.
That way currently, changes in PureOS are reviewed regularly, any time we merge in a newer package from Debian.

Well, we can already sync packages with Debian unstable or experimental, but those have to be recompiled in PureOS - otherwise we can not ensure they actually work with the software that is in PureOS (that's based on testing).
Also, pulling packages from non-testing suites is an explicit task that is currently done manually.

Another point to consider:
When implementing this we must consider that the Librem5 might have forks of important libraries with patches that are either:

• not upstream yet since they're still in review
• not in the version that is currently in Debian testing Therefore we should cater for a way to build packages on or own until we get the correct version from Debian.

I don't know. But only suggested solution, adding kvm group did change the error messages, but there is still some problem.

I think this is https://tracker.pureos.net/T292 ?

I think we could do two things here:

Adding my user to the kvm group worked (after reboot)

@chris.lamb I can reproduce this bug on both my Librem 13 and 15 both running PureOS pointing to green with the latest updates.

Also the log contains things like this:

Adding kvm to my user did solve something. Then I also installed libvirt-daemon-system manually, because it is only suggested.
But still I get some error when creating vm:

Issue has seemed to resolve itself. Update successful.

Thank you very much @mak !

I tried many things and couldn't reproduce this issue - please file a new one in case the problem persists.

Logo changed to the simple text version - it looks weird though:

Thanks. base-files=10.1pureos1 was considered a downgrade, but an apt update and upgrade doesn't upgrade. Must have come from an old deb source I don't use any more. I'll schedule a re-installation!

You can maybe resolve this by running sudo apt install base-files=10.1pureos1, but if this one package was upgraded for some reason, chances are that there are multiple other ones that also have wrong versions, making any bug happening on that system not a PureOS issue - so maybe a reinstallation is a safer bet.

Yeah, this PureOS has been messed with... How did you manage to install a base-files package from Trisquel?

This is impossible, something has severely messed up your system. What is the output of apt-cache policy base-files as well as cat /etc/apt/sources.list ; cat /etc/apt/sources.list.d/*?

Similarly, today an update re-triggered GNOME's "initial setup" wizard, and at the end invited me to start using Trisquel.

Split from https://tracker.pureos.net/T257

Renamed back and filed the 'default' issue as https://tracker.pureos.net/T364. These are two seperate issues AIUI.

.tar.bz2 files are not installable packages, they are just compressed archives like .zip/.tar.gz/.tar.xz files. They are to be uncompressed with an Archive Manager, and can't be installed with a tool like GNOME Software.

Software and Software Install does not install tar.bz2 files, in this case, Firefox.

Confirmed. Thanks!

I tried to use cvt -r 3840 2160 in order to produce a modeline for my system, and while I can see the resolution in the XFCE Display settings (after having configured xorg), I can't switch to it.

@kyle.rankin Thanks using xorg is a good work around for now. Just picking that at login is simple enough I thought it was going to require a more substantial and permanent tweak / swap between wayland / xorg

The pure-text logo will look really bad as window and toolbar icon, but I can use it anyway.
Thanks for updating the link!

I have fixed the link.

Should be resolved in network-manager-openvpn_1.8.0-2pureos2 uploaded with urgency=high.

@d3vid Thank you for the update. I'm a little hesitant to package the latest upstream as Debian have not done it yet and we might be introducing *other* problems to our users. I will go ahead and add and push though. Stay tuned.

Alternatively (from #nm IRC):

Apparently v1.8.2 was just released, could @chris.lamb look at packaging and releasing that?

Thanks for pushing this through. Updated to network-manager-openvpn v1.8.0-2pureos1 and network-manager-openvpn-gnome v1.8.0-2pureos1. Unfortunately the problem persists. Reporting the details upstream in https://bugzilla.gnome.org/show_bug.cgi?id=788226

This worked for me as a temporary solution (sorry I am a Linux noob and I dont know if it might be the same solution you provided and just done in an other way?)

@mak Great news!

This is fixed in calamares >= 3.2~rc3-0pureos2 now, but will also require a rebuild of the live images to be in full effect.
For some reason, Calamares doesn't create a swap partition right now, I am currently investigating that behavior (and playing with the idea of using swapfiles instead of swap partitions).
Once that issue is dealt with, I will build new live ISO images.

Does the update really fail (as in apt showing an error), or does it not boot, or what exactly happens here?
Packages being held back in landing is normal for that suite.