This has been a problem since late last year. You may want to follow this tracking item.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Mar 26 2019
Mar 25 2019
This is very helpful @mak, thanks. I'll read up.
The problem is solved. It was a conflict with my virtual machines that was using the wifi network.
Mar 24 2019
2019-03-24 08:06:17 - INFO: Imported 'mcomix_1.2.1-1.1.dsc' to 'landing/main'. 2019-03-24 08:07:25 - INFO: Imported 'mcomix_1.2.1-1.1_all.deb' to 'landing/main'. 2019-03-24 08:07:26 - INFO: Imported 'mcomix_1.2.1-1.1_all.deb' to 'landing/main'. 2019-03-24 08:07:27 - INFO: Imported 'mcomix_1.2.1-1.1_all.deb' to 'landing/main'.
2019-03-24 08:03:59 - INFO: Imported 'openttd_1.8.0-2.dsc' to 'landing/main'. 2019-03-24 08:05:09 - INFO: Imported 'openttd-data_1.8.0-2_all.deb' to 'landing/main'. 2019-03-24 08:05:16 - INFO: Imported 'openttd_1.8.0-2_amd64.deb openttd-data_1.8.0-2_all.deb' to 'landing/main'. 2019-03-24 08:05:19 - INFO: Imported 'openttd_1.8.0-2_arm64.deb openttd-data_1.8.0-2_all.deb' to 'landing/main'.
Looks like I somehow always ignored those issues when processing bugs, sorry for that!
2019-03-24 07:59:26 - INFO: Imported 'angband_3.5.1-2.3.dsc' to 'landing/main'. 2019-03-24 08:01:49 - INFO: Imported 'angband-data_3.5.1-2.3_all.deb' to 'landing/main'. 2019-03-24 08:01:57 - INFO: Imported 'angband-data_3.5.1-2.3_all.deb angband_3.5.1-2.3_amd64.deb' to 'landing/main'. 2019-03-24 08:02:00 - INFO: Imported 'angband_3.5.1-2.3_arm64.deb angband-data_3.5.1-2.3_all.deb' to 'landing/main'.
I can do it, unless you are faster with it - it's a really trivial upload anyway :-)
In other words: Feel free to reassign to me for now if you prefer
Ah, sorry - I was wondering why I had "missed" to file this issue sooner, and your remark now hints that there was a good reason.
Can you check if this is still an issue? There have been lots of changes on the locale handling in the PureOS initial setup and installer.
No problem with processing delay: Had it been urgent then I would have shouted louder :-)
FTR, this goes together with https://github.com/systemd/systemd/pull/9864 where I am still waiting on feedback.
The current situation with localed on Debian is really suboptimal.
2019-03-24 07:51:04 - INFO: Imported 'atool_0.39.0-9.dsc' to 'landing/main'. 2019-03-24 07:52:11 - INFO: Imported 'atool_0.39.0-9_all.deb' to 'landing/main'. 2019-03-24 07:52:12 - INFO: Imported 'atool_0.39.0-9_all.deb' to 'landing/main'. 2019-03-24 07:52:13 - INFO: Imported 'atool_0.39.0-9_all.deb' to 'landing/main'.
FTR, the reason for blocking nvidia-settings was "References non-free NVIDIA driver".
Package is removed from blacklist now.
Yikes, looks like this issue fell through the cracks completely, sorry for that.
2019-03-24 07:27:13 - INFO: Imported 'mate-sensors-applet_1.20.3-1.dsc' to 'landing/main'. 2019-03-24 07:28:21 - INFO: Imported 'mate-sensors-applet-common_1.20.3-1_all.deb' to 'landing/main'. 2019-03-24 07:28:22 - INFO: Imported 'mate-sensors-applet_1.20.3-1_amd64.deb libmate-sensors-applet-plugin-dev_1.20.3-1_amd64.deb mate-sensors-applet-common_1.20.3-1_all.deb mate-sensors-applet-nvidia_1.20.3-1_amd64.deb libmate-sensors-applet-plugin0_1.20.3-1_amd64.deb' to 'landing/main'. 2019-03-24 07:28:24 - INFO: Imported 'libmate-sensors-applet-plugin-dev_1.20.3-1_arm64.deb mate-sensors-applet-common_1.20.3-1_all.deb libmate-sensors-applet-plugin0_1.20.3-1_arm64.deb mate-sensors-applet_1.20.3-1_arm64.deb' to 'landing/main'.
@jeremiah.foster The data on this URL lists which packages are in certain seeds and why. Some might be explicitly requested, while others are implicitly added via dependencies of packages that were not explicitly requested to be in the default set.
A "standard" PureOS installation consists of the "minimal", "standard" and a desktop seed (e.g. "gnome"), while the desktop seed is itself comprised of a common platform seed ("desktop-common") combined with a desktop specific one ("gnome" or "plasma").
So, if you want to know what is explicitly added to the GNOME flavor of PureOS, https://master.pureos.net/raw/germinate/pureos.green/gnome.seedtext could be interesting, while tables like https://master.pureos.net/raw/germinate/pureos.green/gnome also contain implicitly added stuff and sizes.
Needs a fake upload as the PureOS version is higher than the one in Debian.
If you have not already, you may want to look at /etc/resolv.conf and see if any nameservers are there. Many moons ago, though not on Linux, I had a vpn that would create new dns data. When it crashed, I could not get out of my local system because the it was trying to use the vpn-created entries and had no clue. I had to undo the changes before things would work again.
Mar 21 2019
Wanted to bump this and check on it, thank you.
On tilix I do the command ifconfig and I see my wifi antenna that is well connected to my network.
I made a "ping puri.sm" but impossible to resolve the domain
Mar 20 2019
Pinged Debian bug…
Mar 19 2019
@mak you wrote this in a related discussion (in a non-public chat where you gave permission to quote in public):
Laniakea can sync a specific list of packages from any suite into landing, however this is definitely not a smart idea on PureOS as it currently is. We did that mistake on Tanglu in the past. Since PureOS doesn't rebuild all packages synced from Debian, there might be subtle incompatibilities, or synced packages would just flat out not work due to dependency issues. Or the synced experimental packages would break other stuff if not rebuilt against them, GLib is a primary candidate here (but we also had DBus interface incompatibilities occasionally).
So, if we sync stuff from random suites, I would also opt for rebuilding all Debian packages for PureOS, which in turn would require us to do transitions like Debian does (which would mean people would have to monitor and do those).
4.1.0+dfsg.1-1 is now in PureOS so the issue is gone.
I was commenting on a PureOS forum topic, and I discovered the same error when using Software->left application icon->Software Repositories. My system log file displayed the above stack.
Mar 18 2019
Scope of this issue now relaxed to include source-identical but rebuilt packages.
Whoops, sorry: I totally misread this issue: Clearly not that PureOS is too unstable.
I generally find that it is easier to handle issues when framed by describing the "issue" (i.e. the thing broken or missing) as the topic - rather than an open-ended question.
Comments that were removed can be discussed in a separate issue: https://tracker.pureos.net/T722
Mar 11 2019
Installed on L15 V3.
Earlier systems implemented it as a screw or switch on the mainboard. The current solution is an onboard controller (CR50, IIRC) dedicated to debugging and owner control
Mar 10 2019
Mar 8 2019
"cat: /etc/default/grub.cfg: No such file or directory"
Btw, gksu will not work at all on Wayland as wayland does not allow GUI apps to be run as root without some reconfiguration (which intentionally isn't done), and on Xorg I guess it's just broken because nobody looks at its code anymore.
So, I think we should just close this bug.
@jonas.smedegaard Apparently gksu wasn't auto-removed from PureOS because sbackup had a dependency on it. That package itself is cruft though, so I just dropped both from the archive.
Interestingly, sbackup was not considered for autoremoval in PureOS, I will have to take a closer look at why that happened later (my guess is that it has something to do with the package being NMU'ed and building only arch:all binary packages).
Why do PureOS distribute gksu at all? It was dropped from Debian a year ago: https://tracker.debian.org/pkg/gksu
What does
Mar 7 2019
- grub.cfg #
- DO NOT EDIT THIS FILE #
- It is automatically generated by grub-mkconfig using templates
- from /etc/grub.d and settings from /etc/default/grub
#
Since you insist, @jeremiah.foster, on expanding/redefining the scope of this issue to be about switching *GENERALLY*, I cannot help and therefore unsubscribe from participation here:
Can you paste a copy of you grub.cfg file? Either here or in a pastebin somewhere? That might help debugging the issue. You grub.cfg file likely won't have any secret info, just things like the command line to boot your system as well as the UUID of your disks.
From the phone perspective we we'd like to pull a rather fixed set of packages from e.g. Debian experimental during the freeze automatically (assuming Debian's GNOME team ends up putting the packages there) but after all it's more of an example of a general pattern: grab packages a, b, c from repository x (ideally including required dependencies not present in the target distribution).
It's not, I installed the module and the same happens.
Nope. Installing libcanberra-gtk-module and libcanberra-gtk0 doesn't help.
I can reproduce this. I also get a message "Gtk-Message: 09:43:04.539: Failed to load module 'canberra-gtk-module'" when I run this so perhaps the error is there.
Also, could they provide more information, like actual log files or similar? Currently it is just port numbers and IP addresses which are no evidence of anything.
Mar 6 2019
Yes, I updated grub before reboot.
@jeremiah.foster are you asking to *generally* switch from tracking testing to track unstable (or experimental), or are you - like this issue was initially intended to be about - asking about singling out packages to be tracked exceptionally from unstable (or experimental), where packages otherwise generally continue to track testing?
Syncing from unstable is just flipping a switch. But we need to know if we *want* to do that. Unstable won't get many package changes during the freeze period either.
Autosyncing with experimental is a terrible idea, because experimental packages may just get deleted without ever reaching unstable. There is also a lot of broken stuff in there which we really don't want in PureOS (experimental is really just a playground with zero QA happening).
So, stuff from experimental should only ever be synced manually and if there is a good reason for doing so.
I asked, user said he is not able to install OpenSnitch manually (by compiling from source).
I commented out "GRUB_ENABLE_CRYPTODISK=y" in/etc/default/grub then ran sudo update-grub. This stopped grub from asking me for a password.
Also, could they provide more information, like actual log files or similar? Currently it is just port numbers and IP addresses which are no evidence of anything.
Did you run
Grrr, this means a distro patch to python-qpt got reverted in PureOS somehow.
I will have a look, thanks for the direct bug assignment!
I believe this is the same problem as T660. In my case, this application does not launch. Fortunately, I do not use it very much.
Found the comment in /etc/default/grub and commented it out, then updated grub. Rebooted, but still the same startup sequence. Double checked to make sure the grub default file was saved with the enable_cryptodisk statement commented out.
Software and Updates starts, it just fails to find a distribution template for PureOS
In the grub package in Debian there was a configuration change that PureOS inherited. That change is the addition of an enabled display of the encryption password prompt. Can you check to see if there is a "GRUB_ENABLE_CRYPTODISK=y" line in/etc/default/grub ?