bug#43321: programs depending on libcap 2.31 are crashing (including ntpd, chrony, and potentially others)
On Thu, Sep 10, 2020 at 05:06:55PM -0400, Jesse Dowell wrote: > I am experiencing issues with ntpd crashing after a recent `guix pull` and > `guix system reconfigure`. Messages like the following can be found in > /var/log/messages Oof... thank you for the report. > I was able to fix the issue by rebuilding chronyd with the libcap/next > package. Great. I'm also testing the same solution for ntpd now. I'll make sure that works and figure out what the situation is on the 5.4 kernel.
bug#43075: Prioritize providing substitutes for security-critical packages with potentially long build times
On Thu Sep 10, 2020 at 1:00 AM PDT, Ludovic Courtès wrote: > Hi, > > chaosmonk skribis: > > > ungoogled-chromium receives frequent security updates, so it is > > important for users to keep it up-to-date. However, binary > > substitutes for the latest version are usually not available, and it > > can take a very long time to build from source, possibly multiple > > days on low-end hardware. This might tempt or force some users to put > > off upgrading the package and run an older, vulnerable version until a > > binary substitute is available or they have a chance to set aside the > > uptime needed to build from source. > > > > I don't know what Guix's CI system looks like or how packages are > > queued for building, but if there is a way to prioritize builds for > > certain packages, I propose that substitutes for packages like > > ungoogled-chromium should be built as soon as possible once there is a > > new version. Other security-critical packages with potentially long > > build times that come to mind are icecat and linux-libre. > > Thanks for your feedback. Our build farm has often been lagging behind > lately and that’s something we’ve been working on. The > ungoogled-chromium package is even more problematic because it takes > more than ~80 CPU-hours to build, and that often times out with our > current build farm settings (where we don’t allow builds to take more > than 6h, IIRC). Yes, Chromium's build time is obscene. However, not providing substitutes for it duplicates that problem to the machines of every Guix user who uses ungoogled-chromium. In the time that it would take Guix's build farm to build u-c it could probably build many other packages, but users are in the exact same situation, so a substitute for u-c is likely more valuable to them than substitutes for those other packages. If it is possible to override the 6h timeout value for individual packages, I think that it would be worth doing so for u-c, and perhaps for Icecat and Linux-libre as well. > Right now we’re trying to improve build throughput in general but your > proposal makes sense, of course. > > Thanks, > Ludo’.
bug#43075: Prioritize providing substitutes for security-critical packages with potentially long build times
On Thu Sep 10, 2020 at 2:19 AM PDT, zimoun wrote: > Hi, > > On Thu, 10 Sep 2020 at 10:01, Ludovic Courtès wrote: > > chaosmonk skribis: > > > > I don't know what Guix's CI system looks like or how packages are > > > queued for building, but if there is a way to prioritize builds for > > > certain packages, I propose that substitutes for packages like > > > ungoogled-chromium should be built as soon as possible once there is a > > > new version. Other security-critical packages with potentially long > > > build times that come to mind are icecat and linux-libre. > > > Right now we’re trying to improve build throughput in general but your > > proposal makes sense, of course. > > The recent updates of ungoogled-chromium do not mention [security > updates]. Security fixes are generally provided upstream by the Chromium devs, so the place to look for them is not ungoogled-chromium's changelog, but Chrome/Chromium's changelog.[1] > Well, I do not know if they are. So the question would be: > what triggers the special security build? For ungoogled-chromium, it is safe to assume that every new Chromium release will contain security fixes. I'm not sure about a general solution that would work for other packages. If Guix is tracking a package's upstream VCS and upstream has a consistent commit message format indicating security fixes, perhaps releases containing such commits could trigger a security build. Otherwise I'm not sure. [1] https://chromereleases.googleblog.com/2020/08/stable-channel-update-for-desktop.html > Well, the work-in-progress [1] about some metrics of Cuirass (Guix's > CI) would provide interesting answers on the concrete feasibility and > future improvements. > > [1] http://issues.guix.gnu.org/32548#1 > > > All the best, > simon
bug#43075: Prioritize providing substitutes for security-critical packages with potentially long build times
Hi, On +2020-09-10 11:19:11 +0200, zimoun wrote: > Hi, > > On Thu, 10 Sep 2020 at 10:01, Ludovic Courtès wrote: > > chaosmonk skribis: > > > > I don't know what Guix's CI system looks like or how packages are > > > queued for building, but if there is a way to prioritize builds for > > > certain packages, I propose that substitutes for packages like > > > ungoogled-chromium should be built as soon as possible once there is a > > > new version. Other security-critical packages with potentially long > > > build times that come to mind are icecat and linux-libre. > > > Right now we’re trying to improve build throughput in general but your > > proposal makes sense, of course. > > The recent updates of ungoogled-chromium do not mention [security > updates]. Well, I do not know if they are. So the question would be: > what triggers the special security build? > > Well, the work-in-progress [1] about some metrics of Cuirass (Guix's > CI) would provide interesting answers on the concrete feasibility and > future improvements. > > [1] http://issues.guix.gnu.org/32548#1 > > > All the best, > simon > > > Given [1]https://www.theregister.com/2020/09/04/linux_kernel_flaw_detection/ I would guess that any publicly visible coding meant to trigger special prioritized security builds would feed the process described in [1]. Maybe that's insignificant compared to scraping commit notes and patches etc, idk. HTH :) -- Regards, Bengt Richter
bug#43321: programs depending on libcap 2.31 are crashing (including ntpd, chrony, and potentially others)
Hello, I am experiencing issues with ntpd crashing after a recent `guix pull` and `guix system reconfigure`. Messages like the following can be found in /var/log/messages --8<---cut here---start->8--- Sep 9 10:04:06 localhost ntpd[10104]: Listen normally on 10 wlp2s0 [fda3:bae9:8e85:0:1421:58a2:ada:1923]:123 Sep 9 10:04:06 localhost vmunix: [13620.607643] traps: ntpd[10104] general protection fault ip:7fc1baa34207 sp:7ffd6b331f80 error:0 in libcap.so.2.31[7fc1baa33000+3000] Sep 9 10:04:06 localhost ntpd[10104]: Listen normally on 11 wlp2s0 [2601:582:300:88a:58f1:d50e:9b9a:37d7]:123 Sep 9 10:04:06 localhost ntpd[10104]: Listen normally on 12 wlp2s0 [fe80::487a:7283:64fd:9e25%6]:123 Sep 9 10:04:06 localhost ntpd[10104]: Listen normally on 13 tun0 [fe80::7672:ef25:4507:33e7%7]:123 Sep 9 10:04:06 localhost ntpd[10104]: Listening on routing socket on fd #30 for interface updates Sep 9 10:04:06 localhost ntpd[10104]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized Sep 9 10:04:06 localhost ntpd[10104]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized Sep 9 10:04:06 localhost shepherd[1]: Service ntpd has been disabled. Sep 9 10:04:06 localhost shepherd[1]: (Respawning too fast.) --8<---cut here---end--->8--- At first I thought this was ntpd specific so I tried switching to chronyd and experienced the same problem. --8<---cut here---start->8--- Sep 9 14:41:56 localhost shepherd[1]: Service chronyd has been started. Sep 9 14:41:56 localhost chronyd[26478]: chronyd version 3.5.1 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER -SIGND +ASYNCDNS +SECHASH +IPV6 -DEBUG) Sep 9 14:41:56 localhost vmunix: [30290.527369] traps: chronyd[26478] general protection fault ip:7f1653729207 sp:7fffc9161900 error:0 in libcap.so.2.31[7f1653728000+3000] Sep 9 14:41:56 localhost shepherd[1]: Respawning chronyd. --8<---cut here---end--->8--- I was able to fix the issue by rebuilding chronyd with the libcap/next package. To give more context - I'm using guix master and am using the latest 5.8 kernel. I'm wondering if it might be something related to recent kernel upgrades but I haven't tried reverting to a previous kernel. Is there a plan to go ahead and perform the switch described in the source code for gnu/packages/linux.scm? --8<---cut here---start->8--- ;; libcap 2.31 causes problems for 'fakeroot', so provide this newer variant. ;; To be merged with libcap on the next rebuild cycle. (define-public libcap/next (package (inherit libcap) (version "2.34") (source (origin (method url-fetch) (uri (string-append "mirror://kernel.org/linux/libs/security/linux-privs/" "libcap2/libcap-" version ".tar.xz")) (sha256 (base32 "048n1gy2p48vl9hkrr9wymfxxcpwj2aslz2bv79nhl4m2lhd9kdf")) --8<---cut here---end--->8--- Best, Jesse
bug#43296: [PATCH] gnu: Fix gnome-builder build.
As reported in #43296, gnome-builder tries to be linked against the static
version of libselinux (propagated through glib/gio), failing to do so, as it
also wants to be a PIE. To keep the PIE, link it against the dynamic library.
* gnu/packages/gnome.scm (gnome-builder)[#:phases]: Add 'fix-ninja.
---
gnu/packages/gnome.scm | 7 +++
1 file changed, 7 insertions(+)
diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
index 31c5b0319c..bc8e28becf 100644
--- a/gnu/packages/gnome.scm
+++ b/gnu/packages/gnome.scm
@@ -11336,6 +11336,13 @@ libraries. Applications do not need to be
recompiled--or even restarted.")
(string-append (assoc-ref inputs "python-pygobject")
"/lib")))
#t))
+ (add-after 'configure 'fix-ninja
+ (lambda _
+ ;; #43296: meson(?) incorrectly assumes we want to link
+ ;; this PIE against a static libselinux.
+ (substitute* "build.ninja"
+ (("libselinux\\.a") "libselinux.so"))
+ #t))
(add-before 'check 'pre-check
(lambda _
(system "Xvfb :1 &")
--
2.28.0
bug#43296: [PATCH 1/1] gnu: Fix gnome-builder build.
Leo Prikler writes:
> As reported in #43296, gnome-builder tries to be linked against the static
> version of libselinux (propagated through glib/gio), failing to do so, as it
> also wants to be a PIE. To keep the PIE, link it against the dynamic library.
> * gnu/packages/gnome.scm (gnome-builder)[#:phases]: Add 'fix-ninja.
> ---
> gnu/packages/gnome.scm | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
> index 31c5b0319c..ff4cb8a383 100644
> --- a/gnu/packages/gnome.scm
> +++ b/gnu/packages/gnome.scm
> @@ -11336,6 +11336,12 @@ libraries. Applications do not need to be
> recompiled--or even restarted.")
> (string-append (assoc-ref inputs "python-pygobject")
> "/lib")))
> #t))
> + (add-after 'configure 'fix-ninja
> + (lambda _
> + ;; #43296: meson(?) incorrectly assumes we want to link
> + ;; this PIE against a static libselinux.
> + (substitute* "build.ninja"
> + (("libselinux\\.a") "libselinux.so"
Please end the phase on #t, because “substitute*” has no specified
return value.
Other than that it looks good to me, thanks!
--
Ricardo
bug#43296: [PATCH 1/1] gnu: Fix gnome-builder build.
Hi,
Leo Prikler writes:
> As reported in #43296, gnome-builder tries to be linked against the static
> version of libselinux (propagated through glib/gio), failing to do so, as it
> also wants to be a PIE. To keep the PIE, link it against the dynamic library.
> * gnu/packages/gnome.scm (gnome-builder)[#:phases]: Add 'fix-ninja.
> ---
> gnu/packages/gnome.scm | 6 ++
> 1 file changed, 6 insertions(+)
Thanks for this! One comment, though:
> diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
> index 31c5b0319c..ff4cb8a383 100644
> --- a/gnu/packages/gnome.scm
> +++ b/gnu/packages/gnome.scm
> @@ -11336,6 +11336,12 @@ libraries. Applications do not need to be
> recompiled--or even restarted.")
> (string-append (assoc-ref inputs "python-pygobject")
> "/lib")))
> #t))
> + (add-after 'configure 'fix-ninja
> + (lambda _
> + ;; #43296: meson(?) incorrectly assumes we want to link
> + ;; this PIE against a static libselinux.
> + (substitute* "build.ninja"
> + (("libselinux\\.a") "libselinux.so"
> (add-before 'check 'pre-check
> (lambda _
> (system "Xvfb :1 &")
This new phase should end by returning #t.
Thanks,
Mark
bug#43296: [PATCH 1/1] gnu: Fix gnome-builder build.
As reported in #43296, gnome-builder tries to be linked against the static
version of libselinux (propagated through glib/gio), failing to do so, as it
also wants to be a PIE. To keep the PIE, link it against the dynamic library.
* gnu/packages/gnome.scm (gnome-builder)[#:phases]: Add 'fix-ninja.
---
gnu/packages/gnome.scm | 6 ++
1 file changed, 6 insertions(+)
diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
index 31c5b0319c..ff4cb8a383 100644
--- a/gnu/packages/gnome.scm
+++ b/gnu/packages/gnome.scm
@@ -11336,6 +11336,12 @@ libraries. Applications do not need to be
recompiled--or even restarted.")
(string-append (assoc-ref inputs "python-pygobject")
"/lib")))
#t))
+ (add-after 'configure 'fix-ninja
+ (lambda _
+ ;; #43296: meson(?) incorrectly assumes we want to link
+ ;; this PIE against a static libselinux.
+ (substitute* "build.ninja"
+ (("libselinux\\.a") "libselinux.so"
(add-before 'check 'pre-check
(lambda _
(system "Xvfb :1 &")
--
2.28.0
bug#43296: bug#43269: Gnome Builder doesn't install.
Hi Marinus, I've noticed your report and quickly found a rather crude way of fixing it. I'm not sure, why meson tries to link gnome-builder statically against selinux in the first place, but it should do the job. Regards, Leo Leo Prikler (1): gnu: Fix gnome-builder build. gnu/packages/gnome.scm | 6 ++ 1 file changed, 6 insertions(+) -- 2.28.0
bug#43306: roffit is missing a dependency
raingloom writes: > ``` > Can't locate HTML/Entities.pm in @INC (you may need to install the > HTML::Entities module) (@INC contains: > /gnu/store/8zvc5mvk0xm3ygrxsgpyy5ilxb5rzjry-perl-5.30.2/lib/perl5/site_perl/5.30.2/x86_64-linux-thread-multi > /gnu/store/8zvc5mvk0xm3ygrxsgpyy5ilxb5rzjry-perl-5.30.2/lib/perl5/site_perl/5.30.2 > /gnu/store/8zvc5mvk0xm3ygrxsgpyy5ilxb5rzjry-perl-5.30.2/lib/perl5/5.30.2/x86_64-linux-thread-multi > /gnu/store/8zvc5mvk0xm3ygrxsgpyy5ilxb5rzjry-perl-5.30.2/lib/perl5/5.30.2) > at /gnu/store/60054xxdp3y1406xs0zn8vqj9xskh0m9-profile/bin/roffit line > 17. BEGIN failed--compilation aborted at > /gnu/store/60054xxdp3y1406xs0zn8vqj9xskh0m9-profile/bin/roffit line 17. > ``` > > I tried adding perl-html-parser to its inputs, but it didn't solve it. You probably also need to wrap the executable with wrap-program to set the PERL5LIB environment variable when the program is executed. -- Ricardo
bug#32548: Cuirass: Performance monitoring
Hello, > Agreed. We regularly push commits that are weeks or months old > (sometimes years), so there might be too many outliers when looking at > the commit time. Yes, so I used checkout time instead of commit time with af12a80599346968fb9f52edb33b48dd26852788. I also turned Evaluation 'in_progress' field into 'status' field. This way it's much easier to create some metrics on evaluations. It also allows to distinguish between 'aborted' and 'failed' evaluations. Thanks, Mathieu
bug#43303: GCC package name
zimoun writes: > On Thu, 10 Sep 2020 at 13:31, Ricardo Wurmus wrote: > >> > What is the best for #2? Add 2 optional arguments to 'custom-gcc' >> > (synopsis and description)? Other? >> >> custom-gcc returns a package value, so we can inherit from that and >> overwrite the synopsis and description fields. > > Well, custom-gcc is already an inherit. So it seems awkward to > inherit twice. Nobody will ever know when just looking at the final package. :) -- Ricardo
bug#43306: roffit is missing a dependency
``` Can't locate HTML/Entities.pm in @INC (you may need to install the HTML::Entities module) (@INC contains: /gnu/store/8zvc5mvk0xm3ygrxsgpyy5ilxb5rzjry-perl-5.30.2/lib/perl5/site_perl/5.30.2/x86_64-linux-thread-multi /gnu/store/8zvc5mvk0xm3ygrxsgpyy5ilxb5rzjry-perl-5.30.2/lib/perl5/site_perl/5.30.2 /gnu/store/8zvc5mvk0xm3ygrxsgpyy5ilxb5rzjry-perl-5.30.2/lib/perl5/5.30.2/x86_64-linux-thread-multi /gnu/store/8zvc5mvk0xm3ygrxsgpyy5ilxb5rzjry-perl-5.30.2/lib/perl5/5.30.2) at /gnu/store/60054xxdp3y1406xs0zn8vqj9xskh0m9-profile/bin/roffit line 17. BEGIN failed--compilation aborted at /gnu/store/60054xxdp3y1406xs0zn8vqj9xskh0m9-profile/bin/roffit line 17. ``` I tried adding perl-html-parser to its inputs, but it didn't solve it.
bug#43303: GCC package name
Hi Ricardo, On Thu, 10 Sep 2020 at 13:31, Ricardo Wurmus wrote: > > What is the best for #2? Add 2 optional arguments to 'custom-gcc' > > (synopsis and description)? Other? > > custom-gcc returns a package value, so we can inherit from that and > overwrite the synopsis and description fields. Well, custom-gcc is already an inherit. So it seems awkward to inherit twice. But yes, since it is the only case, it could be the simplest: gccgo-4.9 would become only 'define' and a new 'gccgo' would be inherit from gccgo-4.9 and would be define-public. Cheers, simon
bug#43303: GCC package name
zimoun writes: > About discoverability (guix search gcc) there is still 2 issues: > > 1. libgccjit inherits from gcc-9 but the synopsis/description is not updated. > 2. gccgo uses custom-gcc and so reuse the same synopsis/description. > > The #1 is easy to fix -- I can send a patch which precises the > synopsis/description of libgccjit. Sounds good! > What is the best for #2? Add 2 optional arguments to 'custom-gcc' > (synopsis and description)? Other? custom-gcc returns a package value, so we can inherit from that and overwrite the synopsis and description fields. -- Ricardo
bug#43303: GCC package name
On Thu, Sep 10, 2020 at 6:33 AM Ludovic Courtès wrote: > > Hi Jeffrey, > > Jeffrey Walton skribis: > > > It took me about 15 minutes to install GCC on Guix because Guix named > > the GCC package libgccjit. > > I’m sorry to hear it caused you so much trouble and actually led you to > install the “wrong” package. Lol... Yeah, I found out libgccjit was not right either. > > With the aliases in place, a command like 'guix install gcc' works as > > expected. > > I’ve now added such an alias: > > > https://git.savannah.gnu.org/cgit/guix.git/commit/?id=f17e1802ec325e5cc86d4908f05ac69aafdf39da Perfect, thanks. > I’ll install ‘gcc-toolchain’, which is explained here: > > > https://guix.gnu.org/manual/en/html_node/Application-Setup.html#The-GCC-toolchain Thanks. I was working from https://guix.gnu.org/manual/en/html_node/Invoking-guix-package.html and the search command. Jeff
bug#43303: GCC package name
Hi Ludo, On Thu, 10 Sep 2020 at 12:41, Ludovic Courtès wrote: > > With the aliases in place, a command like 'guix install gcc' works as > > expected. > > I’ve now added such an alias: > > > https://git.savannah.gnu.org/cgit/guix.git/commit/?id=f17e1802ec325e5cc86d4908f05ac69aafdf39da Nice use of deprecated-package. :-) About discoverability (guix search gcc) there is still 2 issues: 1. libgccjit inherits from gcc-9 but the synopsis/description is not updated. 2. gccgo uses custom-gcc and so reuse the same synopsis/description. The #1 is easy to fix -- I can send a patch which precises the synopsis/description of libgccjit. What is the best for #2? Add 2 optional arguments to 'custom-gcc' (synopsis and description)? Other? Last, it is unfortunate that the package gccmakedep has the exact same number of occurence of the term 'gcc' but it is not an issue. Cheers, simon
bug#43303: GCC package name
Hi Jeffrey, Jeffrey Walton skribis: > It took me about 15 minutes to install GCC on Guix because Guix named > the GCC package libgccjit. I’m sorry to hear it caused you so much trouble and actually led you to install the “wrong” package. > With the aliases in place, a command like 'guix install gcc' works as > expected. I’ve now added such an alias: https://git.savannah.gnu.org/cgit/guix.git/commit/?id=f17e1802ec325e5cc86d4908f05ac69aafdf39da I’ll install ‘gcc-toolchain’, which is explained here: https://guix.gnu.org/manual/en/html_node/Application-Setup.html#The-GCC-toolchain Thanks, Ludo’.
bug#43075: Prioritize providing substitutes for security-critical packages with potentially long build times
Hi, On Thu, 10 Sep 2020 at 10:01, Ludovic Courtès wrote: > chaosmonk skribis: > > I don't know what Guix's CI system looks like or how packages are > > queued for building, but if there is a way to prioritize builds for > > certain packages, I propose that substitutes for packages like > > ungoogled-chromium should be built as soon as possible once there is a > > new version. Other security-critical packages with potentially long > > build times that come to mind are icecat and linux-libre. > Right now we’re trying to improve build throughput in general but your > proposal makes sense, of course. The recent updates of ungoogled-chromium do not mention [security updates]. Well, I do not know if they are. So the question would be: what triggers the special security build? Well, the work-in-progress [1] about some metrics of Cuirass (Guix's CI) would provide interesting answers on the concrete feasibility and future improvements. [1] http://issues.guix.gnu.org/32548#1 All the best, simon
bug#43303: GCC package name
Dear, Thank you for the feedback. On Thu, 10 Sep 2020 at 07:22, Jeffrey Walton wrote: > It took me about 15 minutes to install GCC on Guix because Guix named > the GCC package libgccjit. It is a common "mistake" and there is an entry in the manual about that: https://guix.gnu.org/manual/devel/en/guix.html#The-GCC-toolchain Moreover, I am not sure what you want is 'libgccjit' but 'gcc-toolchain'. > These are the names developers expect for the compiler. They don't > expect a name like libgccjit. However, you are right. Something is wrong with "guix search", for example: --8<---cut here---start->8--- guix search gcc | recsel -p name,relevance | head -11 name: libgccjit relevance: 11 name: gccmakedep relevance: 11 name: gccgo relevance: 11 name: gcc-toolchain relevance: 11 --8<---cut here---end--->8--- It is unfortunate and the synopsis of 'libgccjit' should be more descriptive than "GNU Compiler Collection". > With the aliases in place, a command like 'guix install gcc' works as > expected. As said above, the right command is "guix install gcc-toolchain". > Without the aliases (and absent a sane package name), people have to > lookup the documentation and read how to use the package manager for a > simple task like installing the compiler. When 50 or 100 developers > waste 15 minutes of their time, that's about 1 man-week wasted. > There's no reason to waste man-weeks on simple tasks. I understand the frustration. What could be improved in the manual? How did you process after $ guix install gcc guix install: error: gcc: unknown package ? Which terms did you use with "guix search"? All the best, simon
bug#28659: Content-addressed mirror is not used upon invalid hash
Hello, zimoun skribis: > On Fri, 14 Feb 2020 at 22:34, Ludovic Courtès wrote: > >> One thing I don’t quite like about the patch is the fact that ‘guix >> substitutes’ connects to the daemon in ‘content-addressed-item?’. > > What is the status of this patch [1] following the recent discussion about > tar “disarchive” and SWH? > > Related: > - http://issues.guix.gnu.org/issue/39575 > - http://issues.guix.gnu.org/42162 > - https://git.ngyro.com/disarchive/ Thanks for the reminder. I don’t think Timothy’s work changes anything wrt. to this issue: it would still need to be addressed. Ludo’.
bug#43075: Prioritize providing substitutes for security-critical packages with potentially long build times
Hi, chaosmonk skribis: > ungoogled-chromium receives frequent security updates, so it is > important for users to keep it up-to-date. However, binary > substitutes for the latest version are usually not available, and it > can take a very long time to build from source, possibly multiple > days on low-end hardware. This might tempt or force some users to put > off upgrading the package and run an older, vulnerable version until a > binary substitute is available or they have a chance to set aside the > uptime needed to build from source. > > I don't know what Guix's CI system looks like or how packages are > queued for building, but if there is a way to prioritize builds for > certain packages, I propose that substitutes for packages like > ungoogled-chromium should be built as soon as possible once there is a > new version. Other security-critical packages with potentially long > build times that come to mind are icecat and linux-libre. Thanks for your feedback. Our build farm has often been lagging behind lately and that’s something we’ve been working on. The ungoogled-chromium package is even more problematic because it takes more than ~80 CPU-hours to build, and that often times out with our current build farm settings (where we don’t allow builds to take more than 6h, IIRC). Right now we’re trying to improve build throughput in general but your proposal makes sense, of course. Thanks, Ludo’.
bug#43132: [GUIX SYSTEM]: Malfunction
Hey Raghav, Did you eventually find what went wrong? Should we close this bug or at least retitle it? Thanks, Ludo’.
bug#43303: GCC package name
Hi, the GCC package itself isn't to useful. I think you are looking for the gcc-toolchain package which installs GCC, binutils and libc. Malte On Thu, 10 Sep 2020, 07:22 Jeffrey Walton, wrote: > Hi Everyone, > > It took me about 15 minutes to install GCC on Guix because Guix named > the GCC package libgccjit. > > I understand Guix package manager is powerful. I think you should use > an alias feature (or whatever it is called under Guix), and create and > few aliases to help with administration: > >gcc -> libgccjit >g++ -> libgccjit >gcc-c++ -> libgccjit > > These are the names developers expect for the compiler. They don't > expect a name like libgccjit. > > With the aliases in place, a command like 'guix install gcc' works as > expected. > > Without the aliases (and absent a sane package name), people have to > lookup the documentation and read how to use the package manager for a > simple task like installing the compiler. When 50 or 100 developers > waste 15 minutes of their time, that's about 1 man-week wasted. > There's no reason to waste man-weeks on simple tasks. > > Thanks in advance. > > > >
