bug#55026: potential prebuilt binaries in the Mono package

Hello, Mono was removed from Guix with commit bd638a8ad6140db87851a86faae89e736e148f3d. Closing. Maxim "Zhu Zihao" writes: > Agree. > > > Actually, there's more prebuilt binaries in Mono 6 (current version) > > > And it's impossible to remove these binaries (see >

bug#57095: 'terminal-window-size' throws ENOTTY ("Inappropriate ioctl for device")

On 01-09-2022 23:04, Ludovic Courtès wrote: [...] We expect 'x to be caught, leading the handler to return 'good. Instead, 'x is not caught at all. In both cases, setting #:unwind? #t in the outer ‘with-exception-handler’ gives the expected result. I spent some time staring at the relevant

bug#57095: 'terminal-window-size' throws ENOTTY ("Inappropriate ioctl for device")

Hi, Josselin Poiret skribis: > We also use a big wrapping `with-error-handling` to display errors > properly in the case when they are not caught. The difference is that > `with-error-handling` adds a non-unwinding handler, while catch is > unwinding. My first thought was that non-unwinding

bug#55898: Services depending on new Shepherd features may fail until reboot

Hi, Ludovic Courtès writes: > Howdy! > > Maxim Cournoyer skribis: > >> I had something different on mind; I was thinking of some added field to >> our shepherd-service object where the minimal version of Shepherd >> required could be specified, e.g. "0.9.1". >> >> The check could be abstracted

bug#57315: guix upgrade --dry-run output is basically useless

Hi, Thanks for explaining. On jeu., 01 sept. 2022 at 14:05, Ludovic Courtès wrote: >> Just to mention this report is somehow a duplicate of bug#40612 [1]. >> Maybe, they could be merged. WDYT? > > Yes, please. Done. >> $ guix package -i opensurge --dry-run >> guix package: warning: Your

bug#57527: compute-guix-derivation has an error

Hi, > For now, you can try working-around by retrying "guix pull". Henk, could you retry guix pull --commit=89d427e4be35fe79c23e2785a55c19df781fb77e ? BTW, it works for me with: guix time-machine --commit=fc94e93c4b60addfda3c1eddfb85907e9459a8af \ -- time-machine

bug#25957: [EXT] Re: [EXT] bug#25957: gitolite broken: created repositories keep references to /usr/bin for hooks

Hi, On jeu., 01 sept. 2022 at 10:41, "Thompson, David" wrote: > Thanks, pushed as commit c053dfa52dc778eb3d965f58a85c435ae7fab0dd. Cool! Thank you. Cheers, simon

bug#57090: 'guix style' pretty-printer always renders integers as base10

Hi, Ludovic Courtès skribis: > Now, we could tweak the pretty printer so that it recognizes patterns > where numbers or strings should be printed in a certain way. I did that in c3b1cfe76b7038f4030d7d207ffc417fed9a7ead. Lemme know how you like it! :-) Ludo’.

bug#57527: compute-guix-derivation has an error

severity 57527 important merge 47764 57527 severity 53802 important merge 47764 53802 severity 56466 important merge 47764 56466 thanks Found a few apparent duplicates (they are all about a , read-int and process-stderror). On second thought, I don't think the patch I referred to #56466 will

bug#57474: compute-guix-derivation fails due to insufficient memory

Hi, "Michael F. Lamb" skribis: > I was following the instructions in the Guix Reference Manual for running > Guix in a VM using the pre-built qcow2 VM image: > > https://guix.gnu.org/manual/en/guix.html#Running-Guix-in-a-VM > > The documentation instructs me to create a qemu VM with the option

bug#57527: compute-guix-derivation has an error

severity 57527 important merge 47764 57527 thanks For now, you can try working-around by retrying "guix pull". On 01-09-2022 17:00, Toorn, H.W.P. van den (Henk) via Bug reports for GNU Guix wrote:   1417:15  4 (_ # ("/gnu/store/4khcb3b0iqfimjgg6yqnlpf9pkim7s4v-curl-7.84.?" ?) ?)   1417:15 

bug#57527: compute-guix-derivation has an error

Dear developers, the guix pull command ended in an error, and requested to send the error to this e-mail.  Backtrace:   17 (primitive-load "/gnu/store/vkwh34wlnqqfyf44giczcx848i3vdckr-compute-guix-derivation") In ice-9/eval.scm:     155:9 16 (_ _)     159:9 15 (_

bug#57356: libtool-2.4.7 removed as a "duplicate"?

Ludovic Courtès skriver: > Hi, > > Michael Ford skribis: > >> In commit 5b6b731c7d8ecbae0ead1600b4cd2f70c66d51ca, the libtool-2.4.7 >> package was removed as a "duplicate". The commit message doesn't explain at >> all why libtool 2.4.7 was being removed, or what it was a duplicate of? As >> of

bug#25957: [EXT] Re: [EXT] bug#25957: gitolite broken: created repositories keep references to /usr/bin for hooks

Hi Efraim, On Thu, Sep 1, 2022 at 10:20 AM Efraim Flashner wrote: > > On Thu, Sep 01, 2022 at 09:59:55AM -0400, Thompson, David wrote: > > Hi all, > > > > Reviving this old thread. > > > > On Mon, Mar 28, 2022 at 2:51 AM Efraim Flashner > > wrote: > > > > > > > > Seems like all we have to do

bug#25957: [EXT] bug#25957: gitolite broken: created repositories keep references to /usr/bin for hooks

On Thu, Sep 01, 2022 at 09:59:55AM -0400, Thompson, David wrote: > Hi all, > > Reviving this old thread. > > On Mon, Mar 28, 2022 at 2:51 AM Efraim Flashner wrote: > > > > > > Seems like all we have to do is 'substitute*' a '/usr/bin/svnserve' > > > into a '/gnu/store/...' (untested), so seems

bug#25957: [EXT] bug#25957: gitolite broken: created repositories keep references to /usr/bin for hooks

Hi all, Reviving this old thread. On Mon, Mar 28, 2022 at 2:51 AM Efraim Flashner wrote: > > > > Seems like all we have to do is 'substitute*' a '/usr/bin/svnserve' > > into a '/gnu/store/...' (untested), so seems actionable to me. > > Alternatively, as Efraim wrote, let it search the $PATH

bug#55898: Services depending on new Shepherd features may fail until reboot

On 01-09-2022 15:18, Maxim Cournoyer wrote: I had something different on mind; I was thinking of some added field to our shepherd-service object where the minimal version of Shepherd required could be specified, e.g. "0.9.1". The check could be abstracted in the shepherd-service

bug#55898: Services depending on new Shepherd features may fail until reboot

Howdy! Maxim Cournoyer skribis: > I had something different on mind; I was thinking of some added field to > our shepherd-service object where the minimal version of Shepherd > required could be specified, e.g. "0.9.1". > > The check could be abstracted in the shepherd-service implementation, >

bug#55898: Services depending on new Shepherd features may fail until reboot

Hi, Ludovic Courtès writes: > Hi Maxim, > > Maxim Cournoyer skribis: > >> Agreed, but the context differs wildly: while Autoconf or browsers for >> example really are facing a diversity of configuration, the version of >> Shepherd used in Guix System is known and controlled. So the only >>

bug#22020: [PATCH] gnu: guile-sdl: Update to 0.6.1

It's been a while since you submitted this patch, but it's applied now. Thanks! -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature

bug#57356: libtool-2.4.7 removed as a "duplicate"?

Hi, Michael Ford skribis: > In commit 5b6b731c7d8ecbae0ead1600b4cd2f70c66d51ca, the libtool-2.4.7 > package was removed as a "duplicate". The commit message doesn't explain at > all why libtool 2.4.7 was being removed, or what it was a duplicate of? As > of latest master, libtool is still

bug#57315: guix upgrade --dry-run output is basically useless

Hi, zimoun skribis: > Just to mention this report is somehow a duplicate of bug#40612 [1]. > Maybe, they could be merged. WDYT? Yes, please. >> (If you’re curious, see >> for details.) > > Nice read! Quoting: > > [...] do a first

bug#57477: "guix refresh -u" sometimes 'unmirrors' source URLs

Fixed in #57515 OpenPGP_0x49E3EE22191725EE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature

bug#57306: guix pull to old commit fails due to unsupported manifest format

Hi Ludo, Thanks for explaining. On Thu, 01 Sep 2022 at 09:42, Ludovic Courtès wrote: >> It means version 3 is used all the time, right? > > Yes. > >> Well, I miss when or where version 4 is used then. > > Generations that were created with a slightly older Guix have a > version-4 manifest. It

bug#57306: guix pull to old commit fails due to unsupported manifest format

Hi, zimoun skribis: > On Wed, 31 Aug 2022 at 13:06, Ludovic Courtès wrote: > >> I fixed it in 67a6828b2bb821274757f686f7c685b664339a96 using the same >> trick as earlier. > > It means version 3 is used all the time, right? Yes. > Well, I miss when or where version 4 is used then.