No, with the new installation there can't be a kernel mismatch anymore. The problem here is that Libreboot is run with an UEFI payload which boots into an (unsupported) EFI mode of the live-cd, which still offers a debian-installer install option.
See https://tracker.pureos.net/T460 for reference.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jun 21 2018
@chris.lamb No, if network-manager-openvpn-gnome is in the list it *will* be installed, unless there is something else pulled in that is mandatory and conflicts with the package.
It will not be explicitly seeded if it is pulled in by another package that is also seeded.
Jun 17 2018
This was much trickier than usual to resolve, especially with the Britney dupe-pkg-on-arch:all bug being present as well, but it worked out in the end. lintian is updated in green now.
Right, because I uploaded a newer version to sid since I created this issue 4 or 5 days ago.
Heh, the reason for the arm64 issues is that our arm64 builder died, so nothing got built for that architecture for more than a week, No wonder issues exist with package migration.
@chris.lamb At the moment, lintian is simply too young, like the report says:
Package is 1 days old (needed 4)
Jun 11 2018
@chris.lamb Gives me an error 404...
Jun 9 2018
Done. Sorry for taking a bit longer with this, I was traveling yesterday.
I removed the repo, but you do have "Master" permission on the whole PureOS project - not sure why you couldn't remove the repo...
Jun 8 2018
Jun 7 2018
@chris.lamb The os-release thing already results in a neat "PureOS" string, and the logo is being worked on: https://salsa.debian.org/gnome-team/gnome-control-center/merge_requests/1/diffs
@chris.lamb Scroll to the very bottom in g-c-c, click "Details" -> "About"
@wellton To me it looks like you are installing PureOS on an UEFI payload. This has not been tested at all and is not really supported. Are you using an EFI Payload for Libreboot?
What you can try is to run the Live session, and install the system from there with the Live installer - that might work (but has not been tested by anybody yet).
Your remarks around upstream tarballs being ipso facto pristine is
also a little misleading in the general case, due to (at least)
Github's non- deterministic generatation of tarballs...
Jun 6 2018
@chris.lamb I don't really recall why I did that back then, but this is debian/ directory only style packaging with Git. This is completely valid packaging, and gbp will happily use it. It's used inside Debian by a bunch of projects, most notably the KDE/Qt packaging team.
Jun 4 2018
Does the *current* coreboot source package build a coreboot image?
The Tilix Git history, of course, But also the Debian package has no explicit patch (if it had, I should have noticed that as co-maintainer of the package ^^)
When I thought about this at first my intent was to only show the message if a feature requiring the VTE change was activated, but not immediately on startup.
As initial workaround, I added a gsettings change to PureOS default settings, but that only works if Tilix was installed first, which it isn't (so the gsettings override didn't really work, and I did not want to introduce a divergence of Tilix for PureOS).
Can you please point to the commit that fixed this? I fail to find it in the Git history. Thanks!
Jun 2 2018
That was fixed three days ago already.
Thanks for reporting the issue.
May 30 2018
Resolved in the 2018-05-30 image, currently building: http://master.pureos.net/jobs/c1202f83-6ecc-47d7-831a-77f72baa8d0b
May 29 2018
At the moment, apt-file is pretty useless on PureOS, due to the archive not generating a Contents file (or rather, an empty one).
I am not sure though whether it's worth fixing at the current point in time, because the dinstall runs are already really slow, extracting file contents will slow the process down even further.
So this will likely only get fixed when my patches to speed up the process and break it into smaller bits have landed.
Generating Contents is easily one of the most expensive tasks to do (I was under the impression that we were building valid Contents files though and even thought about disabling it - but apparently, it's slow already, even without building them (the archive never created Contents files))
May 28 2018
Simple reason for that being that the utils are part of the main coreboot sources, and we only really want the utilities right now (packaging the rest didn't make sense to me, but it might at some point, at which we can easily add the other pieces to the existing packaging)
I wouldn't mind if someone else updated the package, but I also could take the task of course.
Should we add any new users created on the system to the kvm group, or just the ones that were created by the installers?
@jonas.smedegaard That is because the package has binNMUs, and there is nothing we can do about this issue unless we rebuild all the packages for PureOS again and stop binary-syncing.
You can work around this by making a 1:2.12+dfsg-1+pureos1 upload.
May 27 2018
Can be found at https://source.puri.sm/pureos/packages/pureos-gnome-settings now
Thank you for looking into that so quickly!
I had some mild panic that something seriously broke and the automatic migration let broken packages into green.
I can't reproduce this here... The pureos-desktop package is a transitional package to pureos-gnome, is the latter installable? Can you get a better error message from APT? Are there packages from 3rd-party repositories installed?
May 22 2018
Fixed for a while already, I forgot to close the bug report.
Thank you for reporting the issue!
This should be fixed now (and ideally won't ever break again).
This has been resolved for ages now, thank you for reporting the issue!
May 19 2018
Jup, we are in agreement - and you did say "academically", so I never though you actually wanted to make that change. But I wanted to make absolutely sure that I was just brainstorming here and had no actual intention of modifying user's group settings in a package - sorry for the confusion :-)
@chris.lamb Obviously IMO no package should do this, but purely academically: The seed packages are inadequate, because they are purely metapackages - their purpose is to pull in other packages that make the actual changes and can be removed individually. We would need a package that is on every system though, and one that actually already influences the behavior of users and groups.
The only package that fits this would be the base-files package, because that one already sets group and path defaults and also is on every system.
Alternatively, the gnome-boxes package could do this, but it would be very unexpected for users to see that the group configuration they have set changes for all users due to installing a package.
@chris.lamb Modifying the groups of existing users is evil(tm), and just like writing into $HOME, I don't think we should do that.
Instead, GNOME Boxes could maybe show a nicer error message, so users can add themselves to the group explicitly if they want to.
The groups in which users are is a choice of the administrator who might have intentionally left them out of the kvm group, and we shouldn't change that automatically for every user via a package.
@chris.lamb Ah, I missed the first highlight.
Does adding a user to the kvm group imply any "weaker" security? If not, we can add new users created in the installer to the kvm group, but we likely will have to do that globally, so not only users created by Calamares are in the kvm group by default, but also new user created by our OEM setup wizard.
May 18 2018
Done, the suites are now always ordered alphabetically.
May 17 2018
I could have sworn I fixed that already...
Should be rather trivial to address, in any case :-)
@chris.lamb Jup, in fact, the arm64 package was already there when I looked at it. See http://software.pureos.net/builds/package/eb2f2109-0755-5fc0-b32f-ad5c5274a56c/1/ for its build logs.
@chris.lamb Be patient ;-) Migrating a completely new package taes at least two dinstall runs, so a few hours was just not enough time ^^
@d3vid The website takes a few minutes to update after a new package has been published, so you might have caight the new package immediately after it was migrated, but before it was actually registered in the database as being in green as well.
@d3vid That is a blocker, but I adjusted the code again to ignore the arm64 architecture - we don't have enough build power at time to ensure that we can build every single package on arm64 (although in this case, plymouth built without problems).
May 16 2018
Done, if the package can migrate, it should migrate instantly.
Its status can be monitored at http://software.pureos.net/package/source/landing/fontconfig
Would that be because it is not yet in buster?
The system doesn't seem to know that revision yet, I'll bump the packages urgency in advance.
May 15 2018
How did you get to the Debian installer in that version? Because that is no longer a supported option to installing PureOS.
You are using an old installer image, please use an up-to-date one like https://downloads.pureos.net/live/gnome/2018-04-26/ for installing PureOS.
May 3 2018
Apr 25 2018
This should be addressed in the latest images, I am not sure though if the solution covers all cases (I could only do limited testing).
So, please reopen the issue in case this happens again!
That's a weird one... Can you still reproduce the issue? Can you verify that the "packagekit" package is installed?
What exactly does "issues" mean? What did you try, what did you expect and what was the actual result and error message?
Likely some GNOME weirdness. Needs to be investigated, the image sets should be identical.
Calamares should never even show up in the software center. I marked it's .desktop files to be ignored from inclusion in the software catalog now (effective as of calamares >= 3.2~rc4-0pureos5)
Thanks for noticing!
Apr 23 2018
Yeah, for us it is a change needed for consistency and ease of development, but for our users it doesn't matter at all and thereby is more of a cosmetic change (I should have been clearer on what I meant ^^).
Ok, in that case I claim this task again - this is really not blocking anything at all, in a way it's more a cosmetic/consistency change. I had it on my todo list anyway, so having this bug makes sense.
Apr 21 2018
@todd Why did you reassign the task?
It is still valid, even if Chris can now commit to the repo (which I though he could...), but moving it will need quite a lot more changes to not break things - that's the reason why all infrastructure components are still on Github, especially since Gogs was very unreliable initially and we couldn't risk these repositories to go down.
Apr 19 2018
At the moment, this is not easily possible without setting up some kind of merge with Github or redirection, as a couple of tools pull data from the repository and have it hardcoded.
I want to have the repository and everything else moved rather soon though, and at the same time split the "PureOS" group at Gogs into pureos-packages and pureos proper, so all the infrastructure pieces can live there as well and we have a separate place for packages (for easier permission control, clear scope and less potential for name conflicts).
Apr 15 2018
You got the image from https://downloads.puri.sm/oem/gnome/2018-04-08/ ?
Apr 13 2018
The priority on this is fine, this is a high-priority bug. After getting the debconf prompt once though, you will never see it again.
As for the config file prompt, that is a thing we can ignore for now (it's a minor annoyance regular users won't even see because PackageKit will do the right thing. It's also very tricky to resolve, we likely need to incorporate some changes in the Grub package itself).
The config file change is harmless (I wonder why it's even shown), but the Debconf prompt should never have happened - this means the installer hasn't configured debconf for the GRUB package for some reason.
Apr 11 2018
Apr 10 2018
Can you please try this again with the new OEM installer ISOs and report if that works successfully?
Hmm, popularity contest is not installed by default... Do you still see this issue?
Is this still an issue? I have never experienced this behavior on current PureOS.
At least in the past, we tracked all infrastructure stuff in public here as well (except for concrete machine requests), so I think having this issue here makes sense.
This should be resolved via T365 (doesn't fix the d-i problem, but still resolves the issue in PureOS since the install environment and regular PureOS environment are (almost) identical now, so touchpads work well).
Also, every one of these package managers will not download non-free stuff behind the user's back. Like APT itself or a webbrowser, it will download things only if the users has directly requested that.
This is impossible, as pretty much all of GNOME, systemd, Xorg depends on Meson, and no Rust code can be built without cargo properly at the moment.
@jonas.smedegaard We deliberately added TorBrowser this way when creating PureOS back in the day. I never liked this at all, so personally I would like to remove the package, but I am not sure if we should do that, because the decision to have it that way was done on purpose.
@zlatan.todoric should the Tor Browser package be dropped from PureOS?
Apr 8 2018
I tested this on the devices I have, with no major issue, Everything is working quite well, and the remaining issues are UI things or relatively minor.
So, this task is complete now, and for all further issues with the live boot it makes sense to just have regular bugs (some already exist).
The new and final-ish image can be found at https://downloads.puri.sm/oem/gnome/2018-04-08/, the regular live images have also been rebuilt.