- User Since
- Aug 2 2016, 10:57 PM (181 w, 1 d)
"Never attribute to malice that which can be adequately explained by stupidity." - Hanlon's razor
Thanks for the comprehensive testing @rjurga. The udisks package being broken is normal, the tmpfile is either being modified by udisks or eopkg (I need to check which), causing the sha of the file to change and for eopkg to report that it is broken, it can be safely ignored.
Tue, Jan 21
LGTM, will get this landed in the morning!
All good, when I saw the NVIDIA version number I knew the issue without looking at the logs :D I've done it before too.
Compilation failed: https://build.getsol.us//logs/mc-4.8.24-11.log.gz
LGTM and thanks for the refinement on having it use our freefont package.
Sent out a cooked Budgie ISO to a few folks that were kind enough to reach out. I've validated full-disk encryption installation using the new testing ISO and will also be doing another re-install with just LVM (no encryption).
Mon, Jan 20
Just a heads-up, the new kernel package (with the patch) seems to prevent my my machine from booting. It gets stuck at the blinking cursor phase (can't switch TTYs either).
There's some backwards incompatible changes so we'll want to keep a watchful eye on builds for a bit.
Please run the following command and reboot:
Re-opening for validation.
Alrighty, I'll prioritize glx and virtualbox during rebuilds then and send you a command to run when they're done rebuilding and ready to be installed for validation.
Cooking linux-current now. In the meantime, do you mind providing the output of: eopkg li | grep 'current' so I know what drivers to prioritize for rebuilds (if any) and provide you links for installation when they're done building and indexing on unstable? Thanks!
Ah, you're right. Clearly I need more coffee.
So I double checked in the pinctrl drivers, the patch referenced is already in 5.4.12 per https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/pinctrl/intel/pinctrl-sunrisepoint.c?h=v5.4.12&id=f702e0b93cdb7785d94d6a508e5b1dac99fd9bff, so your issue is not related to a missing offset.
This is the result of systemd-timesync failing to write the clock file in /var/lib/systemd/timesync/, as in reality prior to v240 (we were on v238, so this applies to us) it was a symlink to ./private/systemd/timesync. The respective clock file cannot be read because the timesync folder itself in /var/lib/systemd/ is owned by root.
Sun, Jan 19
Seriously, read the commit... The tarballs were not up during the release. By now this task is already out-of-date because of the frequency of qownnotes releases. It will be updated to whatever is the most latest release with an available tarball next week, as always.
Sat, Jan 18
Seems like something that certainly has value add for inclusion in the repository and it appears you are well maintaining it :)
That's normal, per our latest blog post: https://getsol.us/2020/01/17/new-updates-for-a-new-decade/
Thanks for the bug report, I'll make sure we get this patch merged into linux-current, didn't see it in the changelog for 5.4.13 so probably not in that yet. Should be in next week's sync.