3 users reported another breakage today, this time GNOME session was broken after failed/incomplete upgrade process. Waiting for additional info.

There's a new experimental live image available now for testing.
This build is feature-complete now, which means that - at the current point in time - I don't plan to add more features and the only remaining things to work on are bugs.

We better solver this independently from PureBrowser, to provide the freedom of opt-out to _not_ installing the plugin.

@I_have_issues wrote:

I have never got multitouch, or two finger click to work. I run Ubuntu 17.10.

can we get rid of this hack? There will be more people contributing to pureos in the future (phone team).

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