Eudev in gnome-team [Was: Core-updates coordination and plans]
Hi Vivien, > The eudev package has been touched on gnome-team I reviewed the patches but do not believe they solve Bug#63508 or Bug#63787. That issue, stated succinctly, arises because configure.ac sets the Makefile variable $(udevrulesdir) to the store output [1] while custom rules like mine [2] live in the global folder /etc/udev/rules.d. After some analysis, the upstream sources are best patched here. [3] A explanation for why the flags to ./configure are ineffective can be found here. [4] > Could you try and rebase your work on gnome-team, to see whether it > works? Unfortunately, that rebuild takes two days on my system. Absent an insight that your patches will fix the bug, it is too much effort. Kind regards Felix [1] https://github.com/eudev-project/eudev/blob/611b6fbae2cca9ceeacb820befb3a0e8caec88b8/configure.ac#L180 [2] https://codeberg.org/lechner/system-config/src/commit/a6962d1414d11040072f0e79ffde354fa523137a/service/udev-rules-net-name-mac.scm#L4-L9 [3] https://github.com/eudev-project/eudev/blob/611b6fbae2cca9ceeacb820befb3a0e8caec88b8/src/udev/Makefile.am#L10 [4] https://issues.guix.gnu.org/63508#26
Re: Core-updates coordination and plans
On 2024-01-31, Josselin Poiret wrote: > One conundrum we have for now: glibc 2.38 has a couple of new CVEs, and > we have three options: > 1) change glibc to track the 2.38 release branch → world rebuild. > 2) graft glibc → bad user experience (and we're not supposed to graft > outside of master). > 3) switch to 2.39 → world rebuild + possibly more work fixing new build > failures. > > glibc 2.39 should hopefully release tomorrow (01/02/2024) > > What is everyone's opinion regarding those? > > IMO, option 2 is the one I'd like to avoid, and between 1 and 3 I'd > ideally prefer 3 but we don't know yet if there is going to be a lot of > breakage because of that (feels like usually it's toolchain updates, not > glibc updates that cause them the most). How about doing *both* 1 and 3 ... more world rebuilding, sure, but it means we will have the information to make the correct decision about which to merge into master. It is *possible* that 2.39 is no worse or even less broken than the 2.38 release, even if it is likely that 2.38 is more well tested... and even if 2.38 ends up being the glibc to merge to master, things are better positioned to fairly quickly switch to 2.39 once it becomes a more known quantity... live well, vagrant signature.asc Description: PGP signature
Re: Core-updates coordination and plans
Dear guix, Le mercredi 31 janvier 2024 à 10:19 -0800, Felix Lechner via Development of GNU Guix and the GNU System distribution. a écrit : > Either way, I'd appreciate if Eudev could please be fixed in this > core-updates cycle. The fix has been available for more than half a > year. The eudev package has been touched on gnome-team (unmerged yet, sorry this is taking time) a few months ago with the following commits: d6462be6a8..498db4de1f I submitted these changes against gnome-team because we needed to update libgudev, but in retrospect, it might belong to core-updates. I don’t know if these changes will work with a non-updated libgudev. If we start changing eudev in divergent branches, then it might be a headache to merge. Could you try and rebase your work on gnome-team, to see whether it works? Best regards, Vivien
Re: Core-updates coordination and plans
Hello, Am Wed, Jan 31, 2024 at 05:44:21PM +0100 schrieb Josselin Poiret: > One conundrum we have for now: glibc 2.38 has a couple of new CVEs, and > we have three options: > 1) change glibc to track the 2.38 release branch → world rebuild. > 2) graft glibc → bad user experience (and we're not supposed to graft > outside of master). > 3) switch to 2.39 → world rebuild + possibly more work fixing new build > failures. I would go for whatever fixes the security problems (obviously) and leads to a faster merge. Probably 1), which, if I understand correctly, means using a newer point release or git commit of glibc-2.38 that fixes the CVEs and has a low chance of fundamentally breaking things. Then in the spirit of feature branches, we could have a feature branch "core-team" (not "core-updates"!; well, I do not care about the names, but about the mental idea we attach to them) updating glibc. 2.39 might delay the merge for more months if things do not go well, but you are probably better placed to judge how big the risks are of a lot of breakage. I am also not that worried about world-rebuilds: We should be able to do a world-rebuild not once or twice a year, but at least every month, say, or maybe every week. If this is not the case currently, it is an infra- structure problem that we should try to address. (Relatedly, we should ungraft more often; there are now packages with over 100 grafts, and in updating the system behind a fast internet line, grafting ends up taking a non-negligible proportion of the total time, even on an SSD.) In any case, thanks for your work on getting things in shape! Andreas
Re: Core-updates coordination and plans
Hi Josselin,
On Wed, Jan 31 2024, Josselin Poiret wrote:
> One conundrum we have for now: glibc 2.38 has a couple of new CVEs
The authors describe CVE-2023-6246, which is probably the most serious
of the four vulnerabilities, as "significant" [1] and Red Bat ranks it
as "8.4 (HIGH)" under the new CVD scale. [2]
Most important, "This flaw allows local privilege escalation, enabling
an unprivileged user to gain full root access, as demonstrated in Fedora
38." [again, 1]
> we have three options:
> 1) change glibc to track the 2.38 release branch → world rebuild.
> 2) graft glibc → bad user experience (and we're not supposed to graft
> outside of master).
> 3) switch to 2.39 → world rebuild + possibly more work fixing new build
> failures.
Personally, I would go straight to Glibc 2.39.
I am not sure it's helpful to obsess about "world rebuilds." The fear
and cost of rebuilding in Guix is real, but it is a necessary
consequence of the way Guix works. The fear is also a dominant and
persistent mental obstacle to making Guix better. [3]
> I'd ideally prefer 3 but we don't know yet if there is going to be a
> lot of breakage
Your argument that more work may be needed is well-placed, however.. We
won't know until we get there. Perhaps we can revert to version 2.38
prior to your merge if the problems are severe.
> glibc 2.39 should hopefully release tomorrow (01/02/2024)
Fortunately, your merge schedule conincides more or less with Glib's
release cycle. There should be plenty of data from around the world
about the new Glibc version's performance in two or three weeks.
> most of the patches ... got pushed, are there any other ... ?
I don't know whether eudev is a core-package but I personally find it
irresponsible that my patch to fix the use of MAC-based addresses for
network interfaces [4][5] has not been accepted in some form.
In a functional OS like Guix, no administrator should rely on device
enumerations provided by the BIOS, by UEFI or by the Linux kernel. The
fix is a one-liner. [6]
I used 'regexp-quote' to avoid Guile's quoting madness. [7] As an
alternative, we could quote the literals with the old Perl::Critic trick
that avoids escapes for metacharacters: [8]
(substitute* "src/udev/Makefile.am"
(("[$][(]udevrulesdir[)]") "/etc/udev/rules.d"))
Either way, I'd appreciate if Eudev could please be fixed in this
core-updates cycle. The fix has been available for more than half a
year.
The fix was furthermore deployed on all my systems, including the one
running the test deployment of Debbugs in Guix, which is available at
debbugs.juix.org. The fix works. Thanks!
Kind regards
Felix
[1]
https://blog.qualys.com/vulnerabilities-threat-research/2024/01/30/qualys-tru-discovers-important-vulnerabilities-in-gnu-c-librarys-syslog
[2] https://nvd.nist.gov/vuln/detail/CVE-2023-6246
[3] https://lists.gnu.org/archive/html/guix-devel/2024-01/msg00243.html
[4] https://issues.guix.gnu.org/63508
[5] https://issues.guix.gnu.org/63787
[6] https://issues.guix.gnu.org/63508#12-lineno51
[7] https://www.gnu.org/software/guile/manual/html_node/Backslash-Escapes.html
[8]
https://metacpan.org/pod/Perl::Critic::Policy::RegularExpressions::ProhibitEscapedMetacharacters
Re: Meeting in Brussels on Wednesday night?
I'll join you at some point :) Le 31 janvier 2024 17:21:40 GMT+01:00, Christopher Baines a écrit : > >Ludovic Courtès writes: > >> To those traveling to Brussels tomorrow: who’s in to meet in our lair, >> namely Au Bon Vieux Temps, on Wednesday evening/night? :-) >> >> >> https://www.openstreetmap.org/?mlat=50.84832=4.35237#map=20/50.84832/4.35237=Y >> >> I should be able to be there around 9:30–10PM. > >I'm in, I'll probably be there a little earlier as well, maybe around >20:00 to 20:30.
Core-updates coordination and plans
Hi everyone, Since we're a couple people working on core-updates at the same time, it might be a good idea to coordinate a bit (of course, other volunteers welcome :) ). One conundrum we have for now: glibc 2.38 has a couple of new CVEs, and we have three options: 1) change glibc to track the 2.38 release branch → world rebuild. 2) graft glibc → bad user experience (and we're not supposed to graft outside of master). 3) switch to 2.39 → world rebuild + possibly more work fixing new build failures. glibc 2.39 should hopefully release tomorrow (01/02/2024) What is everyone's opinion regarding those? IMO, option 2 is the one I'd like to avoid, and between 1 and 3 I'd ideally prefer 3 but we don't know yet if there is going to be a lot of breakage because of that (feels like usually it's toolchain updates, not glibc updates that cause them the most). Also, I see that most of the patches that were requested to be merged into c-u (like the big pages for jemalloc) actually got pushed, are there any other (well-tested) ones we can go for at the same time as the glibc rebuild? I will stress that this is about *core* packages now, I feel that it's too late to introduce more complications and delay the update any longer. Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: Meeting in Brussels on Wednesday night?
Ludovic Courtès writes: > To those traveling to Brussels tomorrow: who’s in to meet in our lair, > namely Au Bon Vieux Temps, on Wednesday evening/night? :-) > > > https://www.openstreetmap.org/?mlat=50.84832=4.35237#map=20/50.84832/4.35237=Y > > I should be able to be there around 9:30–10PM. I'm in, I'll probably be there a little earlier as well, maybe around 20:00 to 20:30. signature.asc Description: PGP signature
Re: Golang check phase skipping some tests?
Hi Oleg,
Small update to give you some numbers. Looking through gnu/packages/ I
found a total of 593 packages using the go-build-system. With guix
refresh -l, I find 1449 dependent packages. I am currently at commit
bed3a0b547a59f63b545db165e76ddd9af8bba1a. Take this as a rough estimate,
since I searched back for "define-public" for every occurrence of
"build-system go-build-system".
Without the proposed change in the check phase only a single package
fails to build for me (chezmoi, using x86_64-linux). With the change
this number goes up to 214.
Quite a few failures can be solved by adding missing inputs, but there
is still a fair amount of failures that is harder to solve (cyclic
dependencies, unclear test failures).
All in all, as to be expected I would say. A go-team branch as mentioned
in the other email chain, would be very helpful. In the meantime I will
see how far I get solving some of the build failures locally and sending
those patches to guix-patches.
Best wishes,
Troy
On 2024-01-18 22:45, Sharlatan Hellseher wrote:
> Hi,
>
> There are not too many Golang packages in Guix comparing to other
> language spectific modules:
>
> --8<---cut here---start->8---
> grep -r "build-system go-build-system" gnu/packages | awk '{print $1}'
> | sort | uniq -c | sort -rn
> 382 gnu/packages/golang.scm:
> 47 gnu/packages/golang-web.scm:
> 34 gnu/packages/syncthing.scm:
> 17 gnu/packages/golang-check.scm:
> 9 gnu/packages/web.scm:
> 8 gnu/packages/version-control.scm:
> 7 gnu/packages/databases.scm:
> 5 gnu/packages/ipfs.scm:
> 5 gnu/packages/bioinformatics.scm:
> 4 gnu/packages/virtualization.scm:
> 4 gnu/packages/networking.scm:
> 4 gnu/packages/mail.scm:
> 4 gnu/packages/games.scm:
> 4 gnu/packages/docker.scm:
> 4 gnu/packages/check.scm:
> 3 gnu/packages/file-systems.scm:
> 3 gnu/packages/admin.scm:
> 2 gnu/packages/time.scm:
> 2 gnu/packages/textutils.scm:
> 2 gnu/packages/terminals.scm:
> 2 gnu/packages/password-utils.scm:
> 2 gnu/packages/messaging.scm:
> 2 gnu/packages/irc.scm:
> 2 gnu/packages/geo.scm:
> 2 gnu/packages/education.scm:
> 2 gnu/packages/curl.scm:
> 2 gnu/packages/containers.scm:
> 2 gnu/packages/backup.scm:
> 1 gnu/packages/xdisorg.scm:
> 1 gnu/packages/web-browsers.scm:
> 1 gnu/packages/weather.scm:
> 1 gnu/packages/vpn.scm:
> 1 gnu/packages/tls.scm:
> 1 gnu/packages/terraform.scm:
> 1 gnu/packages/tcl.scm:
> 1 gnu/packages/task-runners.scm:
> 1 gnu/packages/task-management.scm:
> 1 gnu/packages/sync.scm:
> 1 gnu/packages/shellutils.scm:
> 1 gnu/packages/radio.scm:
> 1 gnu/packages/pulseaudio.scm:
> 1 gnu/packages/music.scm:
> 1 gnu/packages/monitoring.scm:
> 1 gnu/packages/linux.scm:
> 1 gnu/packages/image-viewers.scm:
> 1 gnu/packages/hyperledger.scm:
> 1 gnu/packages/high-availability.scm:
> 1 gnu/packages/finance.scm:
> 1 gnu/packages/disk.scm:
> 1 gnu/packages/debug.scm:
> 1 gnu/packages/crypto.scm:
> 1 gnu/packages/configuration-management.scm:
> 1 gnu/packages/compression.scm:
> 1 gnu/packages/calendar.scm:
> 1 gnu/packages/authentication.scm:
> 1 gnu/packages/android.scm:
> --8<---cut here---start->8---
>
> We may enable it globally and rebuild each package and pack and place missing
> in
> native inputs/propagated inputs depending on the purpose.
>
> I would love to investigate the count of packages in `34
> gnu/packages/syncthing.scm:` :-)
>
> Thanks,
> Oleg
>
OpenPGP_0xC67C9181B3893FB0.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: Symlinks in "guix pack" and "guix shell"
Konrad Hinsen writes: > I found a simpler one, using a more recent Guix commit: > >guix time-machine --commit=7b0863f07a113caef26fea13909bd97d250b629e \ >-- pack -S /etc/ssl=etc/ssl --format=squashfs bash nss-certs > > Unfortunately, I have no idea how to debug this, as the image is > constructed by the daemon. I think I found the bug, by playing with variations on my command line: https://issues.guix.gnu.org/68841 Cheers, Konrad.
