Re: Introduce Cuirass and remove Hydra on https://www.gnu.org/software/devel.html

Simon Tournier writes: > Hi, > > Well, I do not see if there is a reply. If no, sorry! If yes, I am > just adding my own curiosity. :-) > > CC: guix-maintainers and guix-sysadmin > CC: Mark Weaver > > On lun., 08 janv. 2024 at 13:19, Jing Luo wrote: > >> I am Jing Luo, a new member from the

Re: The package/inherit trap

Hello again, I made a mistake in my previous message. Earlier, I wrote: > Consider 'kodi/wayland' as an example: > > __ (define-public kodi/wayland > (package > __ (inherit kodi) > __ (name "kodi-wayland") > __ (arguments > ___ (substitute-keyword-arguments

Re: The package/inherit trap

Hi, Maxim Cournoyer writes: > Mark H Weaver writes: > >> Simon Tournier writes: >>> and in the light of this discussion, 5f83dd03a2 seems incorrect, no? >> >> I agree that commit 5f83dd03a2 is incorrect. 'kodi/wayland' is quite >> clearly a case

Re: The package/inherit trap

Simon Tournier writes: > Hi Tobias, > > On Tue, 07 Mar 2023 at 22:11, Tobias Geerinckx-Rice wrote: > >> However, merely documenting something is not enough when we have the >> chance to fix misleading naming, as we do here. It would be nice to >> have, but orthogonal. > > I would not say it

Re: substitute derivation: also substitute grafts?

zimoun writes: > On Wed, 05 Oct 2022 at 12:03, Ludovic Courtès wrote: >> Ricardo Wurmus skribis: >> >>> In my scenario I have two machines, one building stuff the other only >>> substituting. The serving machine would be the one deciding whether to >>> enforce substitutability or not. >> >>

Re: Needed for IceCat-102: rust-1.59 and rust-cbindgen-0.23

Hi John, John Kehayias writes: > Ah, a bunch of the packaged needed for this (cbindgen dependencies) > are done in (unmatched-paren > pointed out this patch series on #guix) > > So after 57702 I think it might just be one or two packages, then > cbindgen and

Re: Needed for IceCat-102: rust-1.59 and rust-cbindgen-0.23

Hi John, John Kehayias writes: > I actually added rust-cbindgen-0.23 and 0.24 for another channel which > needs them for a similar purpose (I will not link the channel but I > think you will know which I mean). So I can submit the patches here, > though I'm not familiar with all the ins and

Needed for IceCat-102: rust-1.59 and rust-cbindgen-0.23

Hello Guix, In one week (Sept 20) Mozilla is scheduled to release Firefox 102.3 ESR with another batch of fixes for security flaws that they will publicize on the same day, but there will be no corresponding fixes for the 91 ESR branch. I hope to update our IceCat package to version 102 by then.

Re: Bug in strip phase of gnu-build-system?

Hi, elaexuo...@wilsonb.com writes: > Hello, > > Sanity check, please. > > When `strip-binaries?` is `#f` and a "debug" output is defined, said output > remains empty. Instead, I expect "debug" to get populated with separated debug > files. > > The logic for creating debug files exists in (guix

Re: Non-free data in Poppler test suite

Hi Ludovic and Marius, Ludovic Courtès writes: > Marius Bakke skribis: > >> So the million dollar question ... are these files okay to use for Guix? >> >> In my (non-lawyer) opinion, I have faith that Poppler developers would >> not distribute files that are not freely redistributable, and

Re: Statement from the Guix maintainers regarding recent events

Hi Maxim, Maxim Cournoyer writes: > * The person who lacked judgment and caused hurt by repeatedly pushing > their exclusionary views onto our community have been removed from the > trusted list, meaning each of their messages will now have to go > through moderation. Can you please cite

Re: [minor patch] Amend CoC

Hi Liliana, Liliana Marie Prikler writes: >> Note: The upstream Contributor Covenant wouldn't want to include it >> because the author seems to have a peculiar world-view where they >> don't acknowledge that humans actually have a sex. I hope the Guix >> maintainers are more reasonable than

Re: On raw strings in commit field

Hi Liliana, Liliana Marie Prikler writes: > it ought to have been comparatively easy to infer that I was talking > about push actions (plural) as sequences, not as individual push > actions like you've used for your proof. It makes no difference, because the set of push actions is closed under

Re: On raw strings in commit field

Hi Liliana, Earlier, I wrote: > Sorry, but this is not even close to a valid argument that the set of > possible push actions to a Git repo is uncountable. In fact, it's quite > easy to prove that the set is countable. Any mathematician will know this. I suppose I should give a proof. I'll

Re: On raw strings in commit field

Hi Liliana, Liliana Marie Prikler writes: > Am Montag, dem 03.01.2022 um 18:14 -0500 schrieb Mark H Weaver: >> >> > If you are talking specifically about the uncountability of real >> > numbers, that'd be quite deep down (as in an uncountability of push >> &

Re: On raw strings in commit field

Hi Liliana, Liliana Marie Prikler writes: > Am Sonntag, dem 02.01.2022 um 17:57 -0500 schrieb Mark H Weaver: >> Hi Liliana, >> >> Liliana Marie Prikler writes: >> >> > Am Samstag, dem 01.01.2022 um 15:37 -0500 schrieb Mark H Weaver: >> > >

Re: On raw strings in commit field

Hi Liliana, Liliana Marie Prikler writes: > Am Samstag, dem 01.01.2022 um 15:37 -0500 schrieb Mark H Weaver: >> Liliana Marie Prikler writes: >> >> > > Where is the Cantor-style diagonalization argument that you spoke >> > > of? >> >

Re: On raw strings in commit field

Hi Liliana, Liliana Marie Prikler writes: > Am Samstag, dem 01.01.2022 um 15:19 -0500 schrieb Mark H Weaver: >> Hi Liliana, >> >> Liliana Marie Prikler writes: >> >> > Am Freitag, dem 31.12.2021 um 20:41 -0500 schrieb Mark H Weaver: >> > > I di

Re: On raw strings in commit field

Liliana Marie Prikler writes: >> Where is the Cantor-style diagonalization argument that you spoke of? > You skipped over it, read again. The key point is that you're > referencing the thing you think will be invalidated to create your > scheme. I've carefully read your message at least 4

Re: On raw strings in commit field

Hi Liliana, Liliana Marie Prikler writes: > Am Freitag, dem 31.12.2021 um 20:41 -0500 schrieb Mark H Weaver: >> I disagree with the last line above.  What makes you think that I'm >> presupposing that the tag does change? >> >> There's a difference between &quo

Re: On raw strings in commit field

Hi Liliana, Liliana Marie Prikler writes: > Am Freitag, dem 31.12.2021 um 18:36 -0500 schrieb Mark H Weaver: >> Hi Liliana, >> >> Liliana Marie Prikler writes: >> > In my personal opinion, the version+raw commit style can be >> > discredited using Ca

Re: On raw strings in commit field

Hi Liliana, Liliana Marie Prikler writes: > Am Mittwoch, dem 29.12.2021 um 20:13 -0500 schrieb Mark H Weaver: [...] >> The simple fact is that the way Ricardo wrote the 'guile-aiscm' package >> is the right way to ensure that it can be reliably reproduced in the >> future.

Re: On raw strings in commit field

Hi Liliana, Liliana Marie Prikler writes: > Git commit hashes do not just depend on the content. They also depend > on how much effort you put into solving a proof of work challenge that > won't ever earn you crypto coins [1]. My knowledge of git is admittedly not that strong, but my

Re: On raw strings in commit field

Hi Liliana, Liliana Marie Prikler writes: > In my personal opinion, the version+raw commit style can be discredited > using Cantor's diagonal argument. You've mentioned Cantor's diagonalization argument at least twice in this thread so far, but although I'm familiar with that kind of argument

Re: On raw strings in commit field

Hi Liliana, Liliana Marie Prikler writes: > It should be noted, that in the case of moving or deleted tags, the > assertion Guix "1.2.3" = upstream "v1.2.3" no longer holds. Agreed, but I don't think that assertion should be our top priority. For purposes of Guix's core goal of enabling

Re: Reverse the naming of store items?

Hi Jacob, Jacob Hrbek writes: > Currently we use > /gnu/store/zzz16sfz4jxsdvf8j29rkd46psrc6dpj-emacs-ert-runner-0.8.0.drv > for store items which are painful to navigate from CLI using bash's > auto-completion as the first letter doesn't correspond to the package > name which usually requires

Re: Linux-libre source code will be taken offline

Leo Famulari writes: > On Sat, Sep 04, 2021 at 01:32:16PM -0700, Jason Self wrote: >> The scripts are not being removed and my understanding is that Guix >> only uses the scripts anyway. > > Okay, that's great. We do use the scripts. Unfortunately, the older deblobbing scripts have now been

Re: Audacity has new administration

Hi, Bone Baboon writes: > My initial message in this email tread did not clearly communicate what > the issues with Muse Group's new privacy policy for Audacity are. > > The two main issues are the on by default telemetry and that Audacity > can no longer be used for any purpose contradicting

Re: Effectively force all GNOME users to locally compile ZFS?

Hi Tobias, Tobias Geerinckx-Rice writes: > Something about this virt-manager reasoning strikes me as bogus, According to , "a module covered by the GPL and a module covered by the CDDL cannot legally be linked together." Regards,

Re: Effectively force all GNOME users to locally compile ZFS?

Hi, Giovanni Biscuolo writes: > Mark H Weaver writes: > >> Tobias Geerinckx-Rice writes: >> >>> Maxime Devos 写道： >>>> Perhaps the "zfs" package can be split in an userspace package >>>> (containing userspace binaries and libra

Re: Effectively force all GNOME users to locally compile ZFS?

Hi Ludovic, Ludovic Courtès writes: > I would rather have nothing depend on ZFS by default, but we could have > “libvirt-with-zfs” etc. > > I agree that GNOME Boxes and libvirt should not depend on ZFS by default > because (1) ZFS is an optional feature and probably not widely used, (2) > ZFS

Re: Effectively force all GNOME users to locally compile ZFS?

Tobias Geerinckx-Rice writes: > Maxime Devos 写道： >> Perhaps the "zfs" package can be split in an userspace package >> (containing userspace binaries and libraries) and a kernelspace >> component (containing the kernel module)? And let the kernelspace >> component be unsubstitutable and the

Effectively force all GNOME users to locally compile ZFS?

Hello Guix, Regarding the following commit, recently pushed to our 'master' branch: --8<---cut here---start->8--- commit 61ccd756e5ff73b2f8dc3449df537f1c5adb5872 Author: Tobias Geerinckx-Rice Date: Thu Jul 1 18:46:49 2021 +0200 gnu: libvirt: Support

Re: Telemetry on by default kitty

Hi Leo, Leo Famulari writes: > On Tue, Jun 15, 2021 at 11:39:59PM +0200, Leo Prikler wrote: >> Am Dienstag, den 15.06.2021, 19:24 +0200 schrieb Giovanni Biscuolo: >> > I'm sorry you don't see the point, but > > Good grief... > >> Might be just me, but this phrasing appears a little aggressive

Re: Telemetry on by default kitty

Hi Leo, Leo Famulari writes: > I feel that, ultimately, we already trust most software authors > implicitly and totally, because we are not auditing their programs. Agreed. > So, I am personally happy to enable the telemetry for most software I > use — especially if it is free software and

Re: Telemetry on by default kitty

Hi Leo, Leo Prikler writes: > If I read terminals.scm, we already disable the telemetry in kitty: > >> (invoke "python3" "setup.py" "linux-package" >> ;; Do not phone home. >> "--update-check-interval=0" Indeed, it appears that Nicolas Goaziou addressed this issue last December

Re: Which kernel series to use in the installer and for installed systems?

Hi Efraim, Efraim Flashner writes: > I don't really understand why > and how a newer kernel would make things stop working, Newer kernels _usually_ work fine, but occasionally things break, and that's much more likely to happen when switching to a newer kernel series. It happened to me quite

Re: Which kernel series to use in the installer and for installed systems?

Hi, Vagrant Cascadian writes: > Would it be too complicated to include both the latest LTS kernel and > the most recently packaged kernel in the installer, and default to using > the same kernel for the installation? Sounds good to me. More specifically, I would suggest offering the user a

Re: Free software telemetry and the Guix System

Hi, Bone Baboon writes: > What types of telemetry in free software programs are compatible with > the Guix System? The relevant text in the GNU FSDG is here: "No Malware The distro must contain no DRM, no

Re: Criticisms of my "tone" (was Re: A "cosmetic changes" commit that removes security fixes)

Hi Leo, Leo Prikler writes: > Am Montag, den 03.05.2021, 05:00 -0400 schrieb Mark H Weaver: >> Leo Prikler writes: >> >> > Am Samstag, den 01.05.2021, 23:13 -0400 schrieb Mark H Weaver: >> > > I don't think I fumbled on the facts at all. It's true

Re: Criticisms of my "tone" (was Re: A "cosmetic changes" commit that removes security fixes)

Am Samstag, den 01.05.2021, 23:13 -0400 schrieb Mark H Weaver: >> I don't think I fumbled on the facts at all. It's true that I didn't >> yet have _all_ of the relevant facts, but as far as I know, every >> fact that I presented is true. >> >> If you disagree, can yo

Re: Criticisms of my "tone" (was Re: A "cosmetic changes" commit that removes security fixes)

Hi Ludovic, Ludovic Courtès writes: > I’m sorry to inform you that this is not a philosophy or linguistics > mailing list. *lol* Indeed, this conversation has wandered quite far off-topic. Thanks for stepping in. > I invite you to continue this discussion off-list. We have a release > coming

Re: Criticisms of my "tone" (was Re: A "cosmetic changes" commit that removes security fixes)

Hi Leo, Leo Prikler writes: > Am Sonntag, den 02.05.2021, 15:29 -0400 schrieb Mark H Weaver: >> >> Leo Prikler writes: >> >> > Let us assume for the sake of argument I were to introduce a bug >> > into Guix. There are a number of ways this can happen

Re: Criticisms of my "tone" (was Re: A "cosmetic changes" commit that removes security fixes)

Hi Leo, Leo Prikler writes: > Let us assume for > the sake of argument I were to introduce a bug into Guix. There are a > number of ways this can happen, but let's focus on the important > distinction here, which is me purposefully introducing that bug vs. it > happening due to oversight. > >

Re: FYI: guile-scheme bindings to GNU Mach and the Hurd

Hi Maxime, Maxime Devos writes: > Joshua Branson schreef op za 01-05-2021 om 11:04 [-0400]: >> Hey guix people, >> >> I just ran across a pretty recent thread in bug-hurd land. Apparently >> there is a VERY WIP effort to get some guile-scheme bindings for GNU >> Mach and the Hurd. >> >>

Re: What processor features does Guix support on i686?

Hi Leo, Thanks for asking about this, and for ably taking care of our Linux-libre packages. I'm grateful for your work on this. Leo Famulari writes: > I noticed that Linux 5.12 has a new config option regarding "Processor > family". The default choice, Pentium-Pro (M686), is highlighted in

Re: Jam: which licence is this?

Hi Jack, Jack Hill writes: > On Sun, 25 Apr 2021, Jack Hill wrote: > >> I have asked the FSF licensing lab about this in RT #1718940 Thanks very much for doing this, Jack. > I've also asked OSI: >

Re: Jam: which licence is this?

Hi Leo, I took the liberty of adding a bit more context to your quotation of me below, since I've added Ludovic to the CC list. Leo Famulari writes: > On Sun, Apr 25, 2021 at 04:37:42PM -0400, Mark H Weaver wrote: >> It's true that Guix has a >> longstanding practice of om

Re: Criticisms of my "tone" (was Re: A "cosmetic changes" commit that removes security fixes)

Hi Leo, I took the liberty of refilling the quotations in your email to make them more readable. Leo Prikler writes: > Am Samstag, den 01.05.2021, 18:12 -0400 schrieb Mark H Weaver: >> Can you please point out which of my words led you to conclude that I >> was assuming bad

Re: Criticisms of my "tone" (was Re: A "cosmetic changes" commit that removes security fixes)

Mark H Weaver writes: > Leo Prikler writes: > >> Am Samstag, den 01.05.2021, 19:02 +0200 schrieb Giovanni Biscuolo: >>> If you want you can consider Mark used an /harsh/ tone but this is a >>> personal feeling, something one /could/ read "between the lines

Re: Criticisms of my "tone" (was Re: A "cosmetic changes" commit that removes security fixes)

Hi Leo, Leo Prikler writes: > Am Samstag, den 01.05.2021, 19:02 +0200 schrieb Giovanni Biscuolo: >> I also spent some time re-reading messages that Mark sent in this >> thread and, like him, I really don't understand what Mark did wrong. >> >> For sure Mark /insisted/ that Raghav and Léo did

Re: RISC-V is giving away developer boards

Ludovic Courtès writes: > Could interested developers raise their hands? :-) I'd be glad to help with development of the port, but I do not have enough spare cycles at present to help with the process of applying to get the hardware. Mark -- Disinformation flourishes because many

RISC-V is giving away developer boards

Hello Guix, This might be of interest: https://riscv.org/blog/2021/04/risc-v-is-giving-away-developer-boards/ Perhaps the Guix project would like to apply to get one of these? What do you think? Mark -- Disinformation flourishes because many people care deeply about injustice but

Criticisms of my "tone" (was Re: A "cosmetic changes" commit that removes security fixes)

Hi Ludovic, Ludovic Courtès writes: > Mark H Weaver skribis: > >> Léo Le Bouter writes: >> >>> It seems you are more focused and spend more time sending accusations >>> here than collaboratively working to improve GNU Guix. I don't feel >>> like

Re: Jam: which licence is this?

Hi Leo, Leo Famulari writes: > On Sun, Apr 25, 2021 at 01:25:21PM -0400, Mark H Weaver wrote: >> In general, I think that the license field of a package should include >> all licenses that cover any files in its source distribution (by which I >> mean the output of

Re: Jam: which licence is this?

Hi Jack, Jack Hill writes: > I'm working on packaging the Argyll Color Management System for Guix. To > build, it uses the Jam tool, which has the following license: > > ``` > This is Release 2.5 of Jam, a make-like program. > > License is hereby granted to use this software and distribute it

Re: Jam: which licence is this?

Hi Ricardo, Ricardo Wurmus writes: >> I'm working on packaging the Argyll Color Management System for >> Guix. To build, it uses the Jam tool, which has the following >> license: > > This is also used by Boost. > > I don’t know what the license is called, but the build tool is not > part of

Re: A "cosmetic changes" commit that removes security fixes

Hi Raghav, Raghav Gururajan writes: >> Thank you for these links. From the IRC log cited above, it now appears >> that Léo Le Bouter bears primary responsibility >> for these mistakes. In particular, according to the IRC >> logs, Léo wrote: >> >> raghavgururajan: the main issues on the

Re: A "cosmetic changes" commit that removes security fixes

Hi Léo, Léo Le Bouter writes: > On Fri, 2021-04-23 at 15:18 -0400, Leo Famulari wrote: >> Léo and Raghav, you need to keep learning our workflow around >> security updates. It's not okay to remove security patches and later >> update a package to a fixed version in a different commit. `git >>

Re: Another misleading commit log (was Re: A "cosmetic changes" commit that removes security fixes)

Léo Le Bouter writes: > On Thu, 2021-04-22 at 13:40 -0400, Mark H Weaver wrote: >> This commit was digitally signed and pushed to the 'wip-gnome' branch >> by >> Raghav, but it's also "Signed-off-by: Léo Le Bouter", so I'm not sure >> who bears primary resp

Re: A "cosmetic changes" commit that removes security fixes

Hi Léo, Léo Le Bouter writes: > I don't share your analysis, the security fixes werent stripped because > glib/cairo was also updated to latest version in subsequent commits > which were pushed all at once. 'glib' was updated, but 'cairo' wasn't, presumably because there's no newer stable

Re: A "cosmetic changes" commit that removes security fixes

Hi Leo, Leo Famulari writes: > On Thu, Apr 22, 2021 at 12:05:36AM -0400, Raghav Gururajan wrote: >> Okay, I was able to retrace. When Leo and I were working outside savannah, >> there was master --> core-updates merge. Leo made these changes when he >> committed to his repo >>

Another misleading commit log (was Re: A "cosmetic changes" commit that removes security fixes)

Here's another commit with a blatantly misleading commit log: https://git.savannah.gnu.org/cgit/guix.git/commit/?h=wip-gnome=f5fc3c609e2f38ca1c0523deadb9f77d838fbf32 The summary line is "gnu: gdk-pixbuf: Add missing arguments", but in fact it does all of the following: (1) Ungrafts

Re: A "cosmetic changes" commit that removes security fixes

Hi Raghav, Raghav Gururajan writes: > Okay, I was able to retrace. When Leo and I were working outside > savannah, there was master --> core-updates merge. Leo made these > changes when he committed to his repo > (https://logs.guix.gnu.org/guix/2021-03-26.log#000811), from which I > pulled

Re: Why is glib still grafted on the 'wip-ungrafting' branch? (was Re: wip-ungrafting builds stuck)

Hi Leo, Leo Famulari writes: > On Wed, Apr 21, 2021 at 04:47:06PM -0400, Mark H Weaver wrote: >> I just noticed that 'glib' is still grafted on the 'wip-ungrafting' >> branch. Was that intentional? >> >> https://git.sv.gnu.org/cgit/guix.git/tree/gnu/package

Re: A "cosmetic changes" commit that removes security fixes

Hi, 宋文武 writes: > This patch is for core-updates: > From 15e28e84eaea8f68b6247ab53052f0dd50a544b2 Mon Sep 17 00:00:00 2001 > From: 宋文武 > Date: Thu, 22 Apr 2021 19:21:51 +0800 > Subject: [PATCH] gnu: cairo: Reintroduce security patches [security fixes]. > > Two patches were accidentally removed

Re: A "cosmetic changes" commit that removes security fixes

Hi Raghav, Raghav Gururajan writes: > Okay, I was able to retrace. When Leo and I were working outside > savannah, there was master --> core-updates merge. Leo made these > changes when he committed to his repo > (https://logs.guix.gnu.org/guix/2021-03-26.log#000811), from which I > pulled

Re: A "cosmetic changes" commit that removes security fixes

Hi Raghav, Raghav Gururajan writes: >> Those commits on 'core-updates' were digitally signed by Léo Le Bouter >> and have the same problems: they remove security >> fixes, and yet the summary lines indicate that only "cosmetic changes" >> were made. > > Yeah, the commit title didn't mention

Re: A "cosmetic changes" commit that removes security fixes

Hi Raghav, Raghav Gururajan writes: >> Raghav Gururajan has pushed another misleading "cosmetic changes" >> commit. [...] >> This one is *far* worse than the examples I gave before. >> This one removes the security fixes for CVE-2018-19876 and >> cairo-CVE-2020-35492 that I had applied in

Re: A "cosmetic changes" commit that removes security fixes

... and here's another "cosmetic changes" commit from Raghav that removes all of the security fixes for 'glib' that I had added: https://git.savannah.gnu.org/cgit/guix.git/commit/?h=wip-gnome=40b58074895ee510cab496655e6bec8d95abe693 Also, both of these commits were marked as:

A "cosmetic changes" commit that removes security fixes

Hello Guix, Raghav Gururajan has pushed another misleading "cosmetic changes" commit. This one is *far* worse than the examples I gave before. This one removes the security fixes for CVE-2018-19876 and cairo-CVE-2020-35492 that I had applied in commit bc16eacc99e801ac30cbe2aa649a2be3ca5c102a.

Why is glib still grafted on the 'wip-ungrafting' branch? (was Re: wip-ungrafting builds stuck)

I just noticed that 'glib' is still grafted on the 'wip-ungrafting' branch. Was that intentional? https://git.sv.gnu.org/cgit/guix.git/tree/gnu/packages/glib.scm?h=wip-ungrafting=e12210dc92098d8581cea3007d57dbb6be16bb41#n171 Mark

Re: wip-ungrafting builds stuck

of interest. Mark >From cfe7ed9732e77eacf7f9e6b6db0d731b2f7d100e Mon Sep 17 00:00:00 2001 From: Mark H Weaver Date: Sun, 19 Jul 2020 23:13:28 -0400 Subject: [PATCH] gnu: rust: Disable check phases of versions before 1.40. This saves 49 hours of total build time on a Thinkpad X200. * gnu/packages/rust.scm (rust-1.19)[

Re: GNOME 40

Hi Raghav, Raghav Gururajan writes: > Let us do this, > [1] Create wip-gnome branch on savannah > [2] Create guix-patches thread for wip-gnome. > [3] Leo, me or anyone else can contribute by sending patches to that thread. > [4] Leo and I (hopefully after getting commit access) can review and

Re: Why ban underscores?

Tobias Geerinckx-Rice writes: > Indeed, underscores were explicitly banned in 2014 (commit > 25083588). Why? > > Where's the advantage in renaming the following packages from > their canonical names? While I was not involved in this decision, I think it's desirable to standardize on a single

Re: Needed: tooling to detect references to buggy */stable packages (was: Re: [PATCHES] ImageMagick security updates without grafting)

Hi Maxime, Maxime Devos writes: > On Sun, 2021-03-28 at 18:33 -0400, Mark H Weaver wrote: >> Earlier, I wrote: >> > One thing to be very careful about is to only use 'gtk-doc/stable', >> > 'dblatex/stable', and 'imagemagick/stable' in native-inputs, and

Re: Needed: tooling to detect references to buggy */stable packages

Hi Ludovic, Ludovic Courtès writes: > Mark H Weaver skribis: > >> It occurs to me that we will need some tooling to ensure that no >> references to these buggy "*/stable" packages end up in package outputs >> that users actually use. Otherwise, it is likely

Re: GNOME 40 work should be done on Savannah

Hi Léo, Léo Le Bouter writes: > I think Mark misrepresents my sayings in their messages. I'm sorry if that happened. It was not my intent. Can you show me what I wrote that misrepresents your position? > We are ONLY using git to exchange work and collaborate on the patchset > with Raghav,

Re: Question about compile packages

Hi, Charles Direg asked: > How can I modify the flags that any program is compiled with within guix? That > is, I can allow in the gnu-build-system to modify it globally so that I can > add the build flags to any package, for example, add the flags -O2 > -march=native -mtune=native so global as

Re: [PATCHES] ImageMagick security updates without grafting

Mark H Weaver writes: > Maxime Devos writes: > >> guix build $PACKAGES >> # maybe guix build $PACKAGES --no-grafts? >> guix graph --type=references $PACKAGES >> # ^ look in output for "imagemagick". > > For the record, it seems that this command

Re: GNOME 40 work should be done on Savannah (was: Re: GNOME 40)

Hi Léo, Léo Le Bouter writes: > The people that work on it now are Raghav and me, and Raghav does not > have commit access yet, so that's the only way we can work and > cooperate now. We don't have a choice. Sorry, but that's simply false. You _do_ have a choice. You can do what we've been

GNOME 40 work should be done on Savannah (was: Re: GNOME 40)

Christopher Baines writes: > Mark H Weaver writes: >> How is it more flexible than a "wip-*" branch on Savannah? > > I wouldn't use quite the same words as Léo, but from my perspective, > controlling access to particular branches (master, staging, > core-upda

Re: [PATCHES] ImageMagick security updates without grafting

Hi Maxime, Maxime Devos writes: > On Sun, 2021-03-28 at 17:37 -0400, Mark H Weaver wrote: >> One thing to be very careful about is to only use 'gtk-doc/stable', >> 'dblatex/stable', and 'imagemagick/stable' in native-inputs, and >> moreover to make sure that no referen

Needed: tooling to detect references to buggy */stable packages (was: Re: [PATCHES] ImageMagick security updates without grafting)

Earlier, I wrote: > One thing to be very careful about is to only use 'gtk-doc/stable', > 'dblatex/stable', and 'imagemagick/stable' in native-inputs, and > moreover to make sure that no references to these */stable packages > remain in any package outputs. > > Of course, if any package retains

Re: [PATCHES] ImageMagick security updates without grafting

Maxime Devos writes: > On Sat, 2021-03-27 at 20:01 -0400, Mark H Weaver wrote: >> [...] >> Maxime wrote: >> > What does ‘guix refresh --list-dependent imagemagick@6.9.11-48’ >> > output now? > >> When I last checked, it reported on the order of 2400 d

Re: GNOME 40

Léo Le Bouter writes: > If anyone is curious of the work or wants to participate, we are > working there: > https://git.guix-patches.cbaines.net/guix-patches/log/?h=wip-gnome-40 > > The branch is based on core-updates and we will rebase it every now and > then, as well as merging patches to

Re: [PATCHES] ImageMagick security updates without grafting

Hi Maxime, Maxime Devos writes: > This approach (& patches) look good to me. Thanks for looking. > What does ‘guix refresh --list-dependent imagemagick@6.9.11-48’ > output now? When I last checked, it reported on the order of 2400 dependent package rebuilds. > If it there are many dependent

[PATCHES] ImageMagick security updates without grafting

to this approach? Mark Note: I haven't yet fully tested these commits. >From eaecf83224fdae115a533d03b6fe949794835d43 Mon Sep 17 00:00:00 2001 From: Mark H Weaver Date: Sat, 27 Mar 2021 07:07:32 -0400 Subject: [PATCH 1/8] gnu: imagemagick: Remove graft. Note that this commit d

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

Mark H Weaver writes: > The following dependency chain seems to be responsible for most of the > imagemagick-dependent packages: > > gtk+@3 -> at-spi2-atk -> at-spi2-core -> gtk-doc -> dblatex -> imagemagick It occurs to me that we could add "stable" va

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

Joshua Branson writes: > raingloom writes: >> >> What about a Liberapay for Guix? Could also be used to pay developers. >> > > I'd be game for something like this. We could have a guix membership. > Drew Devault has a "secret irc" channel for paying patreons. Perhaps we > could advertise a

Re: imagemagick@6.9.11-48 to graft or not to graft with 6.9.12-2

Hi Andreas, Andreas Enge writes: > these are very good arguments, which I understand and share. But moving > to another version is problematic even when there is no soname bump, as > I wrote in my bug report https://issues.guix.gnu.org/47315; grafts with > different version numbers lead to a

Re: imagemagick@6.9.11-48 to graft or not to graft with 6.9.12-2

Hi Ludovic, Ludovic Courtès writes: > Mark H Weaver skribis: > >> Andreas Enge writes: >>> And please let us agree that in the future, we only backport fixes in grafts >>> and do not update version numbers. >> >> I agree that in this particul

Re: imagemagick@6.9.11-48 to graft or not to graft with 6.9.12-2

Hi Leo, Leo Famulari writes: > On Tue, Mar 23, 2021 at 03:38:02PM +0100, Léo Le Bouter wrote: >> For this, the problem is not grafting but that the replacement package >> definition has been made public, this is an "issue" (?) that is known >> and I try to not make replacement package

Re: imagemagick@6.9.11-48 to graft or not to graft with 6.9.12-2

Hi Andreas, Andreas Enge writes: > And please let us agree that in the future, we only backport fixes in grafts > and do not update version numbers. I agree that in this particular case, that's what should have been done, and that we should still try to do it. It will be several days at least

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

Hi Leo, > On Fri, Mar 19, 2021 at 08:14:03PM -0400, Mark H Weaver wrote: >> The following dependency chain seems to be responsible for most of the >> imagemagick-dependent packages: >> >> gtk+@3 -> at-spi2-atk -> at-spi2-core -> gtk-doc -> dblat

Re: A Critique of Shepherd Design

Hi, raid5atemyhomework writes: > GNU Shepherd is the `init` system used by GNU Guix. It features: > > * A rich full Scheme language to describe actions. > * A simple core that is easy to maintain. > > However, in this critique, I contend that these features are bugs. > > The Shepherd language

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

Leo Famulari writes: > On Thu, Mar 18, 2021 at 09:40:04AM -0400, Mark H Weaver wrote: >> I knew this couldn't be right, but I thought I remembered it having >> fewer dependencies. Oh well. Sorry for the noise. > > It's relatively new that ImageMagick is depended on by

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

Earlier, I wrote: > Why is imagemagick grafted, anyway? I think it can simply be updated > without causing many rebuilds, no? Actually, I see now that it would cause many more rebuilds than is appropriate for master. mhw@jojen ~$ guix refresh -l imagemagick Building the following 1270

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

  1   2   3   4   5   6   7   8   9   10   >