Re: gnu: imagemagick/fixed: Redirect old sonames to new sonames.

Hi Léo, Regarding your commit: > From 2e0ff59f0cd836b156f1ef2e78791d864ce3cfcd Mon Sep 17 00:00:00 2001 > From: Léo Le Bouter > Date: Thu, 18 Mar 2021 11:12:51 +0100 > Subject: [PATCH] gnu: imagemagick/fixed: Redirect old sonames to new sonames. > > * gnu/packages/imagemagick.scm

Re: CVEs missing from the NIST database

Hi Ludovic, Ludovic Courtès writes: > Yes, that can happen when the CVE doesn’t list affected versions: > > https://www.openwall.com/lists/oss-security/2017/03/15/3 Thank you for pointing out that thread, and for starting it 4 years ago. I found it illuminating. > The solution here is to

Re: [opinion] CVE-patching is not sufficient for package security patching

Hi Léo, Léo Le Bouter writes: > I would like to share some opinion I have on CVE-patching for non- > rolling release GNU/Linux distributions and why we should strive to > always update to the latest available releases or always follow > upstream supported release series and never backport

Re: bsdiff package vulnerable to CVE-2020-14315

Léo Le Bouter writes: > On Wed, 2021-03-10 at 12:32 -0500, Leo Famulari wrote: >> Well, we could also just remove this package. It sounds like it is >> not >> supported on Linux. Does it offer some unique functionality? > > I would advocate for removal of the package, or at least warning about >

Re: gnutls package may be vulnerable to CVE-2021-20232

Léo Le Bouter writes: > CVE-2021-2023212.03.21 20:15 > A flaw was found in gnutls. A use after free issue in > client_send_params in lib/ext/pre_shared_key.c may lead to memory > corruption and other potential consequences. I pushed fixes for this and CVE-2021-20231 to 'master' in

Re: CVEs missing from the NIST database

Hi Ludovic, Ludovic Courtès writes: > In this case, I noticed that ‘guix lint -c cve cairo’ wouldn’t report > CVE-2020-35492 and found that > is 404. > > Likewise, this command: > >wget -qO - >

Re: glib vulnerable to CVE-2021-28153

Hi Léo, Léo Le Bouter writes: > CVE-2021-2815311.03.21 23:15 > An issue was discovered in GNOME GLib before 2.66.8. When > g_file_replace() is used with G_FILE_CREATE_REPLACE_DESTINATION to > replace a path that is a dangling symlink, it incorrectly also creates > the target of the

Re: glib@2.62.6 is vulnerable to CVE-2021-27218 and CVE-2021-27219

Mark H Weaver writes: > As I wrote in another thread: I'll backport the fixes for CVE-2021-27218 > and CVE-2021-27219 to our version of Glib, based on the backports > already published by Ubuntu for Glib 2.56.4 and 2.64.4. Done in commit 21b3b755151028647081fe96d2992b3743531d71 on th

Re: glib@2.62.6 is vulnerable to CVE-2021-27218 and CVE-2021-27219

Hi Léo, Thanks for bringing this to our attention. Léo Le Bouter writes: > Upstream does not provide fixes for the 2.62.x series so we need to > backport ourselves. One does not follow from the other. Besides upstream, there exist other competent organizations (such as Debian, Red Hat, and

Re: GNOME 3.34 in GNU Guix and security

Hi Léo, I appreciate your recent work on Guix security. Thank you for that. Léo Le Bouter writes: > I must come to the conclusion that using GNOME 3.34 in GNU Guix right > now is just straight out insecure. I would advise we either, get rid of > GNOME, backport all individual security patches

Re: Opposition to new single-letter package name "t"

Nicolas Goaziou writes: > Raghav Gururajan writes: > >> Makes sense. I have attached the patch. > > Applied. Thank you. > > Sorry for the mess! No worries, it's no mess at all. Thanks to Nicolas and Raghav for taking care of renaming it, and also to everyone who contributed to the bike-shed

Re: core-updates: Emacs is only supported on x86_64-linux?

Hi Ricardo, Chris, Ricardo Wurmus writes: > We have “guix graph --path from to”, but frustratingly it won’t cover > build system packages, [...] Chris Marusich writes: > The "--paths" option with "--type=bag" shows you this (results > below were, of course, taken before applying the patch

Re: core-updates: Emacs is only supported on x86_64-linux?

Hi Chris, Chris Marusich writes: > Actually, I've realized that that patch wasn't quite right. I've > attached a corrected version to this email. > > Although the %current-system parameter will look like "x86_64-linux" > because it's a Guix system name, the %current-target-system parameter >

Re: core-updates: Emacs is only supported on x86_64-linux?

Hi Chris, Christopher Baines writes: > I've gone ahead and pushed the patch I proposed to master, I think it's > a step forward. On second thought, maybe you have the right idea. It's becoming increasingly clear that we cannot continue to postpone fixing our Rust packages on non-Intel

Opposition to new single-letter package name "t"

Hello Guix, Yesterday, an obscure package called "t" was added to Guix. We should reject such short package names in Guix unless there's a very compelling reason to keep them. The problem with single-letter package names is that the probability of collisions is far too high. Due to the

Re: core-updates: Emacs is only supported on x86_64-linux?

Hi Chris, Chris Marusich writes: > I've confirmed that works for emacs, except that you actually have to > also do it for gtk+, too, since rust gets pulled in via gtk+ also. Ugh. I'd prefer to avoid removing 'gtk+' from the inputs to 'emacs' on any system, because the distinguishing

Re: core-updates: Emacs is only supported on x86_64-linux?

Hi Chris, Chris Marusich writes: > I've noticed that the emacs package only supports x86_64-linux, at least > on core-updates. Is that intended? It's not intended. Emacs should certainly be supported on every system that Guix supports. > As for the cause, it looks like one contributing

Re: Implications of QEMU binfmt transparent emulation for builds

Hi Christopher, Christopher Baines writes: > I'm starting to play with mixing native and emulated builds with the > Guix Build Coordinator again. I did do this many months ago, but at that > time, there wasn't support for targeting retries across a range of > machines, to help avoid blockages

Re: branch staging updated (5aeee07 -> 104151f)

Efraim Flashner writes: > On Mon, Feb 01, 2021 at 12:14:03PM +0100, Hartmut Goebel wrote: >> Hi, >> >> maybe the process should be the other way round: >> >> staging -> "staging-frozen" -> master >> no "staging-next" > > I really like this idea It sounds good to me too! Mark >> This

Re: branch staging updated (5aeee07 -> 104151f)

Hi, Jakub Kądziołka writes: > On Sun Jan 31, 2021 at 6:18 AM CET, Leo Famulari wrote: >> On Sat, Jan 30, 2021 at 06:37:11PM -0500, Mark H Weaver wrote: >> > What would the Git hook do, precisely? The reason I ask is that some >> > bug fixes are appropriate on a froz

Re: branch staging updated (5aeee07 -> 104151f)

Leo Famulari writes: > The staging branch is frozen [0] so I reverted these commits and pushed > them to staging-next. > > I wonder what we can do to communicate the branch status. Right now it's > not easy to figure out, aside from asking around. Nicolas Goaziou > suggested using a Git hook.

Re: Staging branch [problem with node-10.22]

Jonathan Brielmaier writes: > I tried to update my desktop system to staging but it already fails in > `guix pull`: > > $ cat > /var/log/guix/drvs/d2/rd3sv1i0wy6bwibp4chjymz6b4dggl-guix-package-cache.drv.bz2 > | bzip2 -d > (repl-version 0 1 1) > Generating package cache for >

Re: Fwd: Building Guile with ‘-j1’?

Leo Prikler writes: > There could potentially be another workaround by synchronizing inside > guild, i.e. claiming a lock before reading and evaling any given source > file. This would have the advantage of applying to all guile packages, > not just the ones that use guile-build-system, and it

Re: Building Guile with ‘-j1’?

Hi Ludovic, Ludovic Courtès writes: > As the saying goes, “the cobbler’s children go barefoot”. Guile/Guix > are no exception since Guile builds are non-reproducible, despite work > done a few years ago: > > https://issues.guix.gnu.org/20272 > > Until it’s fixed in Guile proper, what do you

Re: New “ungrafting” branch

Hi Ludovic, Ludovic Courtès writes: > Following discussions on IRC, I’ve created a new ‘ungrafting’ branch > that does nothing but ungraft things. > > The rationale is that grafts incur additional overhead when installing > things (the time to create those grafts), so it’s good to clean them up

Re: Add Microsoft Cascadia Code font?

Hi, Leo Prikler writes: > Am Sonntag, den 10.01.2021, 07:28 -0500 schrieb Julien Lepiller: >> I might be wrong, but I thought fonts were considered non-functional >> data. If that's the case, isn't cc-by-nc-nd acceptable? > > Not according to the FSDG: >> [Non-functional data] can be included

Re: [Telegram-Desktop]: Help with packaging

Hi, Ricardo Wurmus writes: > Because you are fetching from git and the git checkout is not writable > You need a build phase like this: > > --8<---cut here---start->8--- > (add-after 'unpack 'make-writable >(lambda _ > (map

Re: Linux-Libre-LTS

Hi Jonathan, Jonathan Brielmaier writes: > On 24.12.20 11:15, Mark H Weaver wrote: >>> Thoughts? >> >> I have one concern. >> >> It seems to me that the main reason to specify an LTS kernel is to avoid >> the unscheduled breakage that can occur when

Re: Linux-Libre-LTS

Hi Raghav, Raghav Gururajan writes: > I think it is good to have a package-variable "linux-libre-lts", as > mentioned in the table at https://jxself.org/linux-libre/ > > This way, users don't have to remember and change the version numbers in > their operating-system-configuration or

Re: Identical files across subsequent package revisions

I wrote: > FYI, here's the reason that IceCat is unusual among the projects sampled > in Ludovic's analysis: the large collection of JavaScript source files > and other auxiliary files, which are mostly unchanged from one release > to the next, are bundled into a single zip file in

Re: Identical files across subsequent package revisions

Hi Taylan, Taylan Kammer writes: > My second thought: it's surprising that IceCat supposedly changes so > much between releases. I suppose the reason is that this analysis is on > a per-file basis, and IceCat is mostly a massive binary. FYI, here's the reason that IceCat is unusual among the

Re: [PATCH] gnu: libffi: Add unreleased patch to fix float128 on powerpc64le.

Hi Efraim, Efraim Flashner writes: > "regular powerpc", ie macppc/ppc32/powerpc-linux-gnu, does have some > bootstrap binaries built but isn't near ready for merging. Go ahead and > make any changes necessary. I appreciate that, but if rebuilding the world on regular powerpc would significantly

Re: [PATCH] gnu: libffi: Add unreleased patch to fix float128 on powerpc64le.

Hi Chris, Chris Marusich writes: > Mark H Weaver writes: > >> Earlier, I wrote: >>> When invoking 'patch' in Guix, you should *always* use "--force" instead >>> of "--batch". >> >> (See <https://bugs.gnu.org/45252#19> for m

Re: [PATCH] gnu: libffi: Add unreleased patch to fix float128 on powerpc64le.

Earlier, I wrote: > When invoking 'patch' in Guix, you should *always* use "--force" instead > of "--batch". (See for my earlier message). Since writing the message above, I've found another problem in the same commit (7eaa2f24ea77cddbb4bbc2d6a6905673a36f8f99): it

Re: [PATCH] gnu: libffi: Add unreleased patch to fix float128 on powerpc64le.

Hi, There's a problem with the following commit: > commit 7eaa2f24ea77cddbb4bbc2d6a6905673a36f8f99 > Author: John Doe > Date: Tue Dec 15 10:23:44 2020 +0100 > > gnu: libffi: Add unreleased patch to fix float128 on powerpc64le. > > Fixes . > > *

Re: Offline build failure

Hi Greg, Greg Hogan writes: > For the Python-3.5.9 tarball the first version loads in the expected way. > The second tarball is restored to a new location: > > > $ cp -a /gnu/store/f99fblkzb6ip268sg096shhs7wzjyp55-Python-3.5.9.tar.xz >

Re: New “ungrafting” branch

Hi Leo, Leo Famulari writes: > When we added the recursive grafting feature, we intended to use it to > deploy urgent security updates quickly, but we also intended to > "ungraft" quickly, maybe in a week or two. We never planned to keep > packages grafted for several months as we do now —

Cosmetic changes commits as a potential security risk (was Re: Questionable "cosmetic changes" commits)

Hi Raghav, I asked: >> Do you have an explanation for why you are removing comments in your >> "cosmetic changes" commits? "Raghav Gururajan" replied: > I think the comments are useful for non-trivial cases. In these > definitions, the inputs were propagated because they were mentioned in >

Re: Questionable "cosmetic changes" commits

I wrote: > I just hacked up a little script to determine which ordering is more > common. For simplicity, it only considers top-level declarations of the > form (define-public (package ...)). To be more precise, it only considers packages of that form where the '...' contains both 'home-page'

Re: Questionable "cosmetic changes" commits

Hi Raghav, "Raghav Gururajan" writes: > Yeah, my brain laterally connects fields of different package > definitions. Like a spread-sheet, where each columns are different > package definitions and each row is a fields of a package's > definition. > > For example, if column 1 is glib and column

Re: Questionable "cosmetic changes" commits

Hi Ryan, Ryan Prior writes: > I do think it's important to acknowledge that the commits written by > Raghav were part of his internship and advised by his mentors who signed > off on the commits, so it's not like these changes were unsolicited and > materialized out of nowhere. If those

Questionable "cosmetic changes" commits

Hello fellow Guix, In recent months there have been several "cosmetic changes" commits that I find questionable. These commits reorder package fields and reindent code that was already ordered and indented according to our conventions, apparently in order to match the author's personal

Re: GNU Guix 1.2.0rc1 available for testing!

Ludovic Courtès writes: > One this patch is in, I think we’re ready for either an RC2 or the real > thing. > > WDYT? FYI, within 8 hours I expect to push the IceCat 78.5 security update, in case you'd like that to be in 1.2.0, but perhaps it doesn't matter much. Regards, Mark

Re: RFC: subcommand to pause/resume builds

Hi Ludovic, Ludovic Courtès writes: > Last, you’d need to send SIGTSTP to the whole process group of the > build, like so (I think, haven’t tried): > > sudo kill -TSTP -123 > > where 123 is the “SessionPID” shown by ‘guix processes’. However, doing > so may affect build results: processes in

Re: Using #true and #false everywhere?

Hi Ricardo, Ricardo Wurmus writes: > I think it’s very ugly that we still need to end phases with #T, even > though build systems don’t care any more. The only thing that aborts a > build phase now is an exception. I would be glad if this were the case, but I believe you're mistaken. On both

Re: emacs-lucid (was Re: Emacs closure at ~900MB?)

zimoun writes: > However, I am still confused that the GNU Emacs package with default > options (--with-modules, --with-cairo, --disable-build-details) > depends on LLVM via GTK+ and Mesa; and not on only GNU tools. LLVM is an optional input for Mesa which enables the Gallium 'llvmpipe' driver,

Re: IceCat-78.2 preview on 'wip-icecat-78' branch; need icedove-78.

Jonathan Brielmaier writes: > I updated the patches in the mean time for 78.3.0, see > http://issues.guix.gnu.org/43647 Thank you, Jonathan! Your updated patches look good to me. I've followed up at and we can continue the discussion there. Best,

Re: IceCat-78.2 preview on 'wip-icecat-78' branch; need icedove-78.

Hi, "Zhu Zihao" writes: > @@ -1017,10 +1010,31 @@ from forcing GEXP-PROMISE." > (lambda _ > (use-modules (guix build cargo-utils)) > (let ((null-hash > "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855")) > - (substitute*

Re: emacs-lucid (was Re: Emacs closure at ~900MB?)

Pierre Neidhardt writes: > Mark H Weaver writes: > >> Are there additional benefits to 'emacs-lucid' that are not already >> addressed by 'emacs-no-x-toolkit'? I'm not necessarily opposed to >> adding another Emacs variant, but I don't yet understand the motivation. &g

Re: emacs-lucid (was Re: Emacs closure at ~900MB?)

Hi, Giovanni Biscuolo writes: > Given the size "issue" of emacs-with-gtk and the emacs warning on the > long standing Gtk+ bug: > > --8<---cut here---start->8--- > > Warning: due to a long standing Gtk+ bug > https://gitlab.gnome.org/GNOME/gtk/issues/221 >

Re: Renaming “v” to “vlang”?

Ludovic Courtès writes: > Mark H Weaver skribis: > >> More recently, when I wasn't paying attention, a package called 'v' was >> added to Guix. I really wish it hadn't been. Most of the arguments I >> made against 's' apply to 'v' as well: >> >> https://l

Re: Packaging pd

Andreas Enge writes: > I knew that three letter software names are bad, but there is worse - > two letter software names! It gets even worse: one letter package names. Of course there's 'r', but it's obviously very well established, and grandfathered in, so that's fine. However, in 2017 an

Re: IceCat-78.2 preview on 'wip-icecat-78' branch; need icedove-78.

Hi Jonathan, Jonathan Brielmaier writes: > I had a look. It's at the moment two WIP patches here: > https://gitlab.com/jonsger/Guix/-/tree/wip-icedove-78 Thanks very much for working on it. > Icedove 78 needs nss >= 3.53.1 and we have only 3.52.1. An easy solution for now would be to use the

What should "guix build --source" produce? (was Re: Dependency cycle issues when using a Gexp-based snippet)

Hi Maxim, maxim.courno...@gmail.com writes: > While trying to move some of the patching done to qtbase into a snippet, > with the goal of having at least the ./configure script runnable in a > guix environment without having to manually run patching phases: [...] > + (snippet > +

IceCat-78.2 preview on 'wip-icecat-78' branch; need icedove-78.

Hi Jonathan, and other fellow Guix! I've pushed a preview of IceCat-78.2 to the 'wip-icecat-78' branch on Savannah. It's ready for early testing by interested parties. It works well enough that I've switched to it as my primary browser. This version also supports Wayland natively. However, in

Re: Dependency cycle issues when using a Gexp-based snippet

Hi Ludovic, Ludovic Courtès writes: > Indeed: the problem is that when loading this module, we try to resolve > one of the variables referenced in the snippet, but that variable is not > defined yet because it comes from a module that’s in a dependency circle > with the one at hand. [...] > As

Re: [bug#42738] [PATCH v4] gnu: emacs: Update to 27.1.

Hi Ludovic, Ludovic Courtès wrote: > Mark H Weaver skribis: > >> (define-public emacs-next >> (let ((commit "c36c5a3dedbb2e0349be1b6c3b7567ea7b594f1c") >> (revision "0") >> (emacs-version "27.0.91")) >>

Re: [PATCH v4] gnu: emacs: Update to 27.1.

Hi Morgan, Morgan Smith wrote: > It seems I am taking some credit for Jack Hill's patch. I simply took > Jack's patch (labeled as patch v3 in the debbugs thread) and attempted > to build it with my personal config. Indeed, I see that now. Sorry for the mistake. I suppose it happened because

Re: [bug#42738] [PATCH v4] gnu: emacs: Update to 27.1.

Hi Amin, Amin Bandali wrote: > Brett Gilio writes: > > [...] >> >> Also, are we planning to keep emacs-next and have it track 28.x or >> remove it? >> >> Brett Gilio > > I would like it if it's kept. Though, if it is truly meant to track the > "next" release of Emacs, it should be pointed at

Re: [PATCH v4] gnu: emacs: Update to 27.1.

Hello Guix, Ludovic Courtès wrote: > morgan.j.sm...@outlook.com skribis: > >> From: Morgan Smith >> >> * gnu/packages/emacs.scm (emacs): Update to 27.1. >> [arguments]: Add --with-cairo and --with-modules to #:configure-flags. Add >> restore-emacs-pdump phase. >> [inputs]: Add cairo, libxaw,

Re: Linux-libre 5.8 and beyond

Hi Alexandre, Alexandre Oliva wrote: > On Aug 15, 2020, Mark H Weaver wrote: > >> If I were to implement this, what would you suggest I do if the patches >> fail to apply > > Look at the conflict presented by the rebase, and resolve the likely > freedom iss

Re: Linux-libre 5.8 and beyond

Hi Alexandre, I thought about it some more, and I've changed my mind on one point: I've decided that for future kernel updates, in order to eliminate the risk of unintentionally allowing blobs into Guix, I will either wait for Linux-libre to publish updated deblob scripts, or else I will manually

Re: Linux-libre 5.8 and beyond

Hi Alexandre, Alexandre Oliva wrote: > On Aug 12, 2020, Mark H Weaver wrote: > >>>> It may be useful for users with newer hardware devices, which are >>>> not yet well supported by the latest stable release, to use an >>>> arbitrary commit from eit

Re: Linux-libre 5.8 and beyond

Hi Jason, I didn't see your email until just now. I read this list only sporadically, so it's best to keep me in the CC list for messages that you'd like me to see, or that are responses to me. Mark H Weaver wrote: >> the linux-libre project periodically deletes most of its older >&

Re: Linux-libre 5.8 and beyond

Hi Vagrant, Vagrant Cascadian wrote: > At a longer glance, it looks like I failed to update the hashes > correctly. The hashes for deblob-check 5.7 and deblob-check 5.8 both > began with "1n" and I must have somehow glazed over the differences and > not updated the local commit. Ah, okay, that

Re: Linux-libre 5.8 and beyond

Hi Vagrant, Vagrant Cascadian wrote: > I saw the 5.8 was out, and gave a quick shot at updating it, but it hung > python indefinitely during the deblobbing process. I was unable to reproduce this problem. I simply added version 5.8 in the usual way, without changing the deblobbing code at all,

Re: Linux-libre 5.8 and beyond

Hi, Vagrant Cascadian wrote: > Thanks for updating linux-libre to 5.7! Yes, many thanks to Leo Famulari for taking care of that (large) job. > I saw the 5.8 was out, and gave a quick shot at updating it, but it hung > python indefinitely during the deblobbing process. I also tried > switching

Re: bug#35728: Tor & IceCat's TorButton shows it's connected but doesn't route the traffic

Hello again. In my previous message, I asked: > Which version of Debian did you test with, and how did you > install the Firefox that you used for testing this? Also, what version of Firefox did you test with? Thanks, Mark

Re: bug#35728: Tor & IceCat's TorButton shows it's connected but doesn't route the traffic

Hi, sirmacik wrote: > There seems to be a problem with Tor and TorButton in GNU IceCat's > package. Torsocks works for other apps, TorButton shows notification > that it's connected to the Tor server but when I go to > check.torproject.org I'm not routed through tor. Thanks for bringing this to

Re: Icedove package needs update, following IceCat 68.9.0 update.

Earlier, I wrote: > I just pushed the IceCat-68.9.0 security update to the master branch of > Guix, along with a graft for NSS. > > However, I just noticed that we now have Icedove in Guix, and that it's > based on 'icecat-source'. This is all good and proper (kudos to all who > worked on it!),

Icedove package needs update, following IceCat 68.9.0 update.

Hi, I just pushed the IceCat-68.9.0 security update to the master branch of Guix, along with a graft for NSS. However, I just noticed that we now have Icedove in Guix, and that it's based on 'icecat-source'. This is all good and proper (kudos to all who worked on it!), but unfortunately I

Re: Parallel downloads

Hi, Ludovic Courtès writes: > Pierre Neidhardt skribis: > >> Ludo, what do you think of Tobias suggestion and have an extra knob to >> specifically configure the number of download jobs? > > Like I wrote, it’s not that simple (we’d first need the daemon to > distinguish substitution jobs from

Re: Clang c++ include path

Hi Danny, Danny Milosavljevic wrote: > Hi Mark, > >> variable name. The reason is that IceCat depends on Rust which depends >> on Clang, and there is a chain of *18* Rust compilers that must be built >> before IceCat can be built. On my system, compiling all of those Rust >> compilers

Re: Help needed packaging rust-cbindgen, a dependency of IceCat 68

Hi Chris, Chris Marusich writes: > I'm subscribed to bug-gnuzilla, but I haven't seen messages about this. > Where does communication and coordination for IceCat happen these days? > I'd like to help, and it's tough to work alone. Thanks again for raising this issue. I'm glad to report that

Re: Clang c++ include path

Hi Ricardo and Mathieu, Ricardo Wurmus writes: >> When running clang on a c++ program, it cannot find c++ std libraries. >> That's because, those libraries path are hardcoded inside g++ compiler >> and clang cannot find them. > > Does this patch help? I'd like to request that fixes to

Re: Cuirass exposes evaluation logs

Ludovic Courtès writes: > Good news everyone! Cuirass now keeps logs of evaluations and exposes > them over HTTP! So when an evaluation fails, you can now click on the > red cross to peek at the log. This will be very helpful, thank you! Mark

Re: Help needed packaging rust-cbindgen, a dependency of IceCat 68

Hi Chris, Chris Marusich writes: > Mark H Weaver writes: > >> I have good news and bad news. The good news is that thanks to the >> heroic efforts of Amin Bandali , a recently appointed >> co-maintainer of GNU IceCat, there now exists a preliminary version of

IceCat-68.2.0-guix0-preview1 is now available on master

Hello fellow Guix, I'm pleased to announce that IceCat-68.2.0-guix0-preview1 is now on the 'master' branch, and that substitutes for x86_64-linux are available from ci.guix.gnu.org. This update includes fixes for CVE-2019-11757, CVE-2019-11759, CVE-2019-11760, CVE-2019-11761, CVE-2019-11762,

Re: Profiles/manifests-related command line interface enhancements

Hi Pierre, Pierre Neidhardt writes: > Mark H Weaver writes: > >> It wouldn't be sufficient to remove them. You'd have to restore the >> previous settings. For example, if we remove the settings for PATH, >> MANPATH, etc, without restoring the previous settings, I

Re: Profiles/manifests-related command line interface enhancements

Hi Pierre, Pierre Neidhardt writes: > Danny Milosavljevic writes: > >> On Thu, 24 Oct 2019 11:32:55 +0200 >> Pierre Neidhardt wrote: >> >>>- The inverse command, =guix deactivate /path/to/profile=. >>> This can be useful to deactivate a profile that was activated during login. >> >> That is

Re: Profiles/manifests-related command line interface enhancements

Hi Pierre, Pierre Neidhardt writes: > While playing with multiple profiles and manifests and discussing with > a couple of people in the community, I collected a number of usability > issues with Guix when it comes to managing multiple profiles and dealing > with manifests. > > Ideas for new

Re: Preliminary IceCat 68.2 package

Hi Andy, Andy Wingo writes: > I know that's not very reassuring, but if you're looking for a quick > workaround, running your "make -jN" in a loop 5 times or something may > be good enough. Thanks again for suggesting this. I was stuck, and you got me unstuck, and for that I'm very grateful.

Re: Preliminary IceCat 68.2 package

Hi Andy, Andy Wingo wrote: >> I'd be very grateful for help debugging these failures or finding a >> workaround. > > I don't know what this is, but at work I have to build Firefox a lot, > and sometimes the rust bits die in the middle of compilation. Is it a > resource exhaustion issue? I am

Re: Preliminary IceCat 68.2 package

I wrote: > * Many earlier attempts to build it have failed due to non-deterministic > failures in the build system, possibly due to a bug in the Cargo tool. > I'm not sure how much luck was involved in my successful build. Your > mileage may vary. Having now done a few more test builds,

Re: Help needed packaging rust-cbindgen, a dependency of IceCat 68

Efraim Flashner writes: > It's pushed. I think this should be a good motivator to work on a > wip-rust branch to merge the crates into crates-io and convert the > others over. Thanks, Efraim! Mark

Preliminary IceCat 68.2 package

Hello fellow Guix, I was finally able to successfully build a working IceCat-68.2 package. The 'wip-icecat-68' branch on Savannah contains this preliminary work. A few caveats: * IceCat 68 has not yet been released upstream. This is very much a work-in-progress, and does not currently meet

Re: Help needed packaging rust-cbindgen, a dependency of IceCat 68

Hi Efraim, Mark H Weaver writes: > Efraim Flashner writes: >> Here's what I have for rust-cbindgen based more-or-less on my >> re-imagining of the cargo-build-system and the rust inputs. > > Thank you very much for this! Notably, I see that every package in your > sour

Re: Help needed packaging rust-cbindgen, a dependency of IceCat 68

Hi Efraim, Efraim Flashner writes: > Here's what I have for rust-cbindgen based more-or-less on my > re-imagining of the cargo-build-system and the rust inputs. Thank you very much for this! Notably, I see that every package in your source has a proper 'license' field, and that there are *far*

Re: Help needed packaging rust-cbindgen, a dependency of IceCat 68

Ludovic Courtès writes: > I don’t think I said it publicly yet, so: welcome back! It’s good to > see your energy back here on these essential and tricky topics. Thank you, Ludovic. I'm grateful for your words, and for the wonderful Guix system that you gave birth to and ably nurtured for long

Re: Help needed packaging rust-cbindgen, a dependency of IceCat 68

Mark H Weaver writes: > John Soo writes: >> I have it - but not with all the correct licenses. >> What version do you need? > > According to Debian any version >= 0.8.7 should work. Thank you! Actually, I have it now too. Within a few minutes of seeing your message

Re: Help needed packaging rust-cbindgen, a dependency of IceCat 68

Hi John, John Soo writes: > I have it - but not with all the correct licenses. > What version do you need? According to Debian any version >= 0.8.7 should work. Thank you! Mark

Help needed packaging rust-cbindgen, a dependency of IceCat 68

Hello fellow Guix, I have good news and bad news. The good news is that thanks to the heroic efforts of Amin Bandali , a recently appointed co-maintainer of GNU IceCat, there now exists a preliminary version of IceCat 68 that builds successfully and works on Trisquel. The bad news is that

Re: Linux-libre 5.2 has reached end-of-life. Okay to remove?

Tobias Geerinckx-Rice writes: >> Are there any objections to removing the linux-libre-*@5.2 packages? > > Please do! Done. Thanks for the lightning fast response :) Mark

Linux-libre 5.2 has reached end-of-life. Okay to remove?

Hello fellow Guix, I just pushed a batch of kernel updates, but there was no corresponding 5.2 update because that series has reached end-of-life, and is no longer supported upstream. That means that it's potentially a security risk. Are there any objections to removing the linux-libre-*@5.2

Re: Maintainer (no longer) needed for Linux-libre and IceCat packages

Hi Ludovic, Ludovic Courtès writes: > Thanks for your message. As discussed privately, I’m sad to see you go, > and as co-maintainer I can only say you’re welcome back anytime you want. Thank you Ludovic, and thanks to all for the kind words. In light of recent events at the FSF, I've had a

Maintainer needed for Linux-libre and IceCat packages

Hello, I need to take a break from Guix. I'm not sure if I'll be back or not. Someone else should take over maintenance of the Linux-libre and IceCat packages, starting with the recent kernel updates for 4.4.192, 4.9.192, 4.14.143, 4.19.72, and 5.2.14. Thanks, Mark

Re: 01/01: services: Add ‘/usr/bin/env’ special file.

Tobias Geerinckx-Rice writes: > Christopher Baines 写道： >> This seems to me like quite a big change, and I'd be interested in >> knowing what your motivation was [1]? > > It's not, really. It's equivalent to the impure /bin/sh that Guix > Systems already provide, but actually useful: ‘use

Re: 01/01: services: Add ‘/usr/bin/env’ special file.

Hi Tobias, Tobias Geerinckx-Rice writes: > Christopher, > > Christopher Baines 写道： >> This seems to me like quite a big change, and I'd be interested in >> knowing what your motivation was [1]? > > It's not, really. It's equivalent to the impure /bin/sh that Guix > Systems already provide, but

Re: Using CLISP instead of CCL to bootstrap SBCL

Hi Pierre, Pierre Neidhardt writes: > I've updated SBCL to build against CLISP. > > So now Next is back on the bootstrappability road! Thanks very much for taking care of this! Mark

Re: ‘computed-origin-method’ for IceCat and ungoogled-chromium

Hi Ludovic, Ludovic Courtès writes: > Hello Mark & Marius! > > Somehow I hadn’t noticed the clever trick with ‘computed-origin-method’ > in IceCat and ungoogled-chromium, and it came to me as a shock today. > ;-) Yes, I probably should have brought wider attention to what I did there. Sorry

<    1   2   3   4   5   6   7   8   9   10   >