bug#32548: Cuirass: Performance monitoring

[Bonface M. K.]

Hi all.

zimoun  writes:

> Hi Mathieu,
>
> Really cool!
>
> On Mon, 14 Sep 2020 at 15:35, Mathieu Othacehe  wrote:
>
>> * Builds per day
>> * Average evaluation speed per specification.
>
> Something interesting could be: min and max (of 100 evaluations).
> The standard error deviation too but I am not sure it is easy to
> interpret with a quick look.  Instead, the median could be
> interesting.
>
> For example, consider these 2 evaluations:
>
> https://ci.guix.gnu.org/build/2094496/details
> https://ci.guix.gnu.org/build/3035986/details
>

I'm getting a 504 Gateway Time-out error when
visiting the above links(at the time of sending
this email).

> Well, if there is say 99 evaluations of first "kind" and 1 of second
> kind, the average is:
> (99*849 + 1_595_796_252) / 100 = 15_958_803.03
> which does not really represent the effective workload.
>
> Well, I will try to give a look if I can schedule a moment. :-)
>
>
>> Those metrics can now be seen at:
>>
>> https://ci.guix.gnu.org/metrics
>
> Nice plot!
>
>
>> I plan to add more metrics such as:
>>
>> - Evaluation completion percentage.
>> - Evaluation completion speed.
>> - Failed evaluations percentage.
>> - Pending builds per day.
>
> Cool!
> Maybe time between commit time (not author time) and start of the build.
>
>
> Cheers,
> simon
>
>
>
>

-- 
Bonface M. K. (https://www.bonfacemunyoki.com)
Chief Emacs Mchochezi
GPG key = D4F09EB110177E03C28E2FE1F5BBAE1E0392253F


signature.asc
Description: PGP signature

bug#43418: ffprobe/avprobe and ffmpeg/avconv should be added as dependencies of youtube-dl so it will function correctly

[Nathan Dehnel]

Ludovic wanted to add useflags to guix.
https://lists.gnu.org/archive/html/guix-devel/2019-05/msg00285.html
I don't know what became of it.

On Tue, Sep 15, 2020 at 2:44 PM raingloom  wrote:
>
> On Tue, 15 Sep 2020 14:06:11 +0200
> Tobias Geerinckx-Rice via Bug reports for GNU Guix 
> wrote:
>
> > Hi Nathan,
> >
> > Nathan Dehnel 写道：
> > > bash-5.0$ youtube-dl -x
> > > https://www.youtube.com/watch?v=7Ijd_iN9Blk
> > > [youtube] 7Ijd_iN9Blk: Downloading webpage
> > > [download] Deadmau5 - Hit Save-7Ijd_iN9Blk.webm has already been
> > > downloaded
> > > [download] 100% of 15.45MiB
> > > ERROR: ffprobe/avprobe and ffmpeg/avconv not found. Please
> > > install one.
> >
> > It works fine without ‘-x’:
> >
> >   λ youtube-dl https://www.youtube.com/watch?v=7Ijd_iN9Blk
> >   [youtube] 7Ijd_iN9Blk: Downloading webpage
> >   [download] Destination: Deadmau5 - Hit Save-7Ijd_iN9Blk.mp4
> >   [download] 100% of 37.09MiB in 00:02
> >
> > This *is* functioning correctly in my view: that advanced options
> > optionally require run-time dependencies is not a bug but a
> > feature.  The programme clearly explains which package could be
> > installed to continue, and the user can chose which one they
> > prefer - including neither, which suffices for the majority of
> > youtube-dling.
> >
> > Matters would be different if the error message were less clear,
> > or perhaps if ffmpeg weren't so insanely great:
> >
> >   λ guix size youtube-dl | tail -n1
> >   total: 186.9 MiB
> >   λ guix size youtube-dl ffmpeg | tail -n1
> >   total: 811.2 MiB
> >
> > (!)
> >
> > Kind regards,
> >
> > T G-R
>
> Maybe it's time we added an "optional dependencies" field?
> There seems to be a bug report or help request like every week that
> just boils down to "this package has an undocumented dependency".

bug#42773: sbcl-hu.dwim.common is missing a description

[zimoun]

Hi Pierre,

The commit 89a3fec558e07434e8370896248bc272c9b4ece5 adds the package
hu.dwim.common and the description of ’sbcl-hu.dwim.common’ is empty, as
Jack had reported.

Therefore, the 2 others {e,}cl-hu.dwim.common have also an empty
description.

Could you fix this?
Please. :-)

Cheers,
simon

bug#43418: ffprobe/avprobe and ffmpeg/avconv should be added as dependencies of youtube-dl so it will function correctly

[Leo Famulari]

On Tue, Sep 15, 2020 at 02:06:11PM +0200, Tobias Geerinckx-Rice via Bug reports 
for GNU Guix wrote:
> Matters would be different if the error message were less clear, or perhaps
> if ffmpeg weren't so insanely great:
> 
>  λ guix size youtube-dl | tail -n1
>  total: 186.9 MiB
>  λ guix size youtube-dl ffmpeg | tail -n1
>  total: 811.2 MiB

I wonder, should we expect FFmpeg to already be referenced by somebody's
profile if they are using youtube-dl? VLC and mpv both depend on FFmpeg.
The use case of "download video and watch it on another machine (or
never watch it)" seems somewhat esoteric.

On the other hand, youtube-dl has no explicit dependencies — I guess
that everything it needs is from Python. That's beautiful, and I
understand the reluctance to add a dependency, especially on a "kitchen
sink" package like FFmpeg.

bug#43344: "basic" system tests fail (and all the other ones) on guix master

[Leo Famulari]

On Tue, Sep 15, 2020 at 06:34:21PM -0400, Mark H Weaver wrote:
> That's useful information, but we should not stay frozen on the 5.8.7
> kernel for much longer.  5.8.8 contains many bug fixes, some of which
> might fix potentially exploitable flaws.
> 
> It would be useful to know if this problem still occurs with 5.8.9,
> which has since come out.  If so, we should do a bisection between 5.8.7
> and 5.8.8 to find out which upstream commit introduced the problem.
> 
> Would anyone like to investigate this further?

I will try to reproduce the bug with 5.8.9 now. I will try the bisection
if time permits.

bug#43232: [PATCH] gnu: jack-2: Update to 1.9.14.

[Mark H Weaver]

Mike Rosset  writes:

> Mark H Weaver  writes:
>
>> [...] patches are more robust than 'substitute*' for
>> fixing bugs, and less likely to be misapplied or left forgotten in a
>> vestigial state after they are no longer needed.
>
>  That change was not quite fitting right with me either.
> So I appreciate the review and comments.  Thankful it's not needed with
> 1.9.14 and I'll take your comments into account in the future.

Sounds good.  Thank you, Mike!

 Mark

bug#42810: Guix doesn't follow all symlinks

[zimoun]

Dear,

On Tue, 11 Aug 2020 at 15:54, Steffen Rytter Postas  wrote:
> Hi,
>
> Some background first, to better understand the issue:
> I've been running Guix on a foreign distribution
> with my own channel in ~/.config/guix/channels.scm for some time now. 
> However this means having to deal with doing both a `guix pull` as
>  a user, but also `guix pull` as superuser to keep the system
> builder daemon etc up to date.
> I wanted to avoid this, by using simply a system-wide guix install, and
> not have my own user have a guix variant. I tried simply deleting
> ~/.config/guix/current symlink, and confirmed that `guix` was now using
> the `/usr/local/bin/guix` symlink.
> Then I moved my ~/.config/guix/channels.scm file to
> /etc/guix/channels.scm
> and satisfied with my setup, performed `sudo guix pull --fallback` to
> pull the latest changes and verify it worked.
> The command ran as expected, and printed the new packages from my
> channel that were now available.

Well, I am not sure to understand why you want this setup since
“guix-daemon” needs (really) few updates and as regular user, when doing
“guix pull”, if there is major upgrade, then it will be announced with
“guix pull –news”.  We all like different tastes. :-)


> `type guix`:
> /usr/local/bin/guix
>
> `readlink /usr/local/bin/guix`
> /var/guix/profiles/per-user/root/current-guix/bin/guix
>
> `/usr/local/bin/guix show entr-git`
> guix show: error: entr-git: package not found
>
> `/var/guix/profiles/per-user/root/current-guix/bin/guix show entr-git`
> name: entr-git
> version: 4.5-0.6b13a97

[...]

So, if I understand correctly, as a regular user, the command ’guix’
points to ’/usr/local/bin/guix’ which points to
’/var/guix/profiles/per-user/root/current-guix/bin/guix’, and this
latter points to ’/gnu/store/…-guix-command’.

I think the issue is that Guix is not only one binary, so ’bin/guix’ is
not enough.

So you need to have also in the correct symlinks with ’lib/{guile,guix}’
and others.

I have not investigated but I guess the issue you hit comes from
’lib/guix/package.cache’, correctly see by
/var/guix/profiles/…/bin/guix’ but not all your other symlink machinery.


Well, I do not know if it helps.

All the best,
simon

bug#43132: [GUIX SYSTEM]: Malfunction

[Raghav Gururajan]

Hi Mark and Maxim!

>> Ext4 won't detect bitrot (silent corruption of your drive's data).
>> You'll probably wake one day with a fsck that won't be able to recover
>> some files, or worst, a completely dead drive.
>>
>> Your backups would also contain corrupted data (garbage in, garbage
>> out!).
> 
> For what it's worth, I wholeheartedly agree with Maxim.  Btrfs did you a
> great service by calling attention to this problem with your drive, and
> it would be a shame to ignore it and switch back to ext4 where your data
> may instead be silently corrupted.
> 
> I've been using btrfs for several years now on my x86_64 Guix system,
> and it has served me well.  Previously, I used ext4, which would
> silently leave some of my files empty after crashes.  I've never seen
> that happen with btrfs.

Yeah, makes sense. I have placed an order for WDS100T2B0A.

Thanks folks!

Regards,
RG.



signature.asc
Description: OpenPGP digital signature

bug#43432: trilinos source vanished

[zimoun]

Hi,

On Tue, 15 Sep 2020 at 22:24, Efraim Flashner  wrote:
> The source page for trilinos (gnu packages engineering) now points to a
> Github page and the previous tarballs no longer seem to be available.
> There's a content addressed substitute available from Berlin but I don't
> see an original tarball from Debian to point to.

Ouch!

Well, Github delivers this tarball:

  

but yes, the hash does not match (guix download).  Does it matter?  Is
it not possible to replace the vanished tarball by this one?


And it seems better to switch to git-fetch with commit.  Some arguments
are exposed in this thread:

  

BTW, since the Tarball Heritage is not ready yet, currently the easiest
is to use ’git-fetch’, via “guix lint” to queue to SWH and with the
right content-address, the fallback works.


All the best,
simon

bug#43344: "basic" system tests fail (and all the other ones) on guix master

[Mark H Weaver]

Hi,

Danny Milosavljevic  writes:

> On Mon, 14 Sep 2020 15:26:52 +0200
> Mathieu Othacehe  wrote:
>
>> Anything special with your hardware? KVM support disabled maybe?
>
> The culprit had been the Linux kernel update to 5.8.8.
>
> After downgrading to 5.8.7 it works just fine--no other changes done.
>
> Previously, I had tried also to add wipefs -a before the parted--that
> hadn't helped either.

That's useful information, but we should not stay frozen on the 5.8.7
kernel for much longer.  5.8.8 contains many bug fixes, some of which
might fix potentially exploitable flaws.

It would be useful to know if this problem still occurs with 5.8.9,
which has since come out.  If so, we should do a bisection between 5.8.7
and 5.8.8 to find out which upstream commit introduced the problem.

Would anyone like to investigate this further?

Mark

bug#43232: [PATCH] gnu: jack-2: Update to 1.9.14.

[Mike Rosset]

Mark H Weaver  writes:

> Earlier, I wrote:
>> In contrast, a call to 'substitute*' will silently start doing nothing,
>> and may easily be forgotten.  To make matters worse, a future version of
>> jack-2 might add another 'for' loop in that file, matching the same
>> pattern but where it is important that 'i' _not_ be initialized to 0.
>
> Sorry, I made a mistake in the details here, since the pattern applies
> only when 'i' is already initialized to 0, but the more general point
> still stands, namely that patches are more robust than 'substitute*' for
> fixing bugs, and less likely to be misapplied or left forgotten in a
> vestigial state after they are no longer needed.
>
>   Mark

 That change was not quite fitting right with me either.
So I appreciate the review and comments.  Thankful it's not needed with
1.9.14 and I'll take your comments into account in the future.

Mike

bug#43132: [GUIX SYSTEM]: Malfunction

[Mark H Weaver]

Maxim Cournoyer  writes:

> Raghav Gururajan  writes:
>
>>> Maxim Cournoyer  skribis:
>>> 
 I took Raghav to #btrfs last week, where with the help of gentle folks a
 failing drive was established as the most likely culprit.

 In other words, Btrfs checksuming capabilities helped quickly
 discovering a hardware problem which might otherwise have silently
 caused non-recoverable damage to Raghav's data.
>>> 
>>> Good, thanks for following up!
>>> 
>>> Ludo’.
>>
>> Thank you!
>>
>> Yeah, seems like my disk is shot, but I am not sure. I have reinstalled
>> guix with ext4, instead of btrfs, as these issues started to arise after
>> migration to btrfs from ext4. So far, my system is doing well. Lets see
>> how it goes. :-)
>
> Sounds like playing with fire to me :-).
>
> Ext4 won't detect bitrot (silent corruption of your drive's data).
> You'll probably wake one day with a fsck that won't be able to recover
> some files, or worst, a completely dead drive.
>
> Your backups would also contain corrupted data (garbage in, garbage
> out!).

For what it's worth, I wholeheartedly agree with Maxim.  Btrfs did you a
great service by calling attention to this problem with your drive, and
it would be a shame to ignore it and switch back to ext4 where your data
may instead be silently corrupted.

I've been using btrfs for several years now on my x86_64 Guix system,
and it has served me well.  Previously, I used ext4, which would
silently leave some of my files empty after crashes.  I've never seen
that happen with btrfs.

   Mark

bug#43435: bootstrap (bash-mesboot0) and ’make release’ error

[zimoun]

Dear,

Reading the release document [1] and going step by step, so I start from
a fresh worktree and branch and I tweak a bit (maybe I am doing wrong)
otherwise it fails:

   ./bootstrap && ./configure --localstatedir=/var/
   make
   make GUIX_MAINTENANCE_DIRECTORY=../../maintenance update-NEWS
   make doc-pot-update

then the target and the error:

--8<---cut here---start->8---
$ make release

[...]

make[4]: Leaving directory '/home/simon/src/guix/wk/rel/po/packages'
make  \
  top_distdir="guix-1.0.1.22205-a8360-dirty" 
distdir="guix-1.0.1.22205-a8360-dirty" \
  dist-info dist-hook
make[4]: Entering directory '/home/simon/src/guix/wk/rel'
  GEN  gen-ChangeLog
  GEN  gen-AUTHORS
echo 1.0.1.22205-a8360-dirty > "guix-1.0.1.22205-a8360-dirty/.tarball-version"
guix-1.0.1.22205-a8360-dirty/gnu/packages/commencement.scm:// 
/gnu/store/cq0cmv35s9dhilx14zaghlc08gpc0hwr-tcc-boot0-0.9.26-6.c004e9a/lib/libc.a:
 error: 'sigprocmask' defined twice
error: store file names embedded in the distribution
make[4]: *** [Makefile:6335: assert-no-store-file-names] Error 1
--8<---cut here---end--->8---

The checkout is based on commit a8360892d7.


On IRC [2], it rings a bell. :-)  The error should come from
’bash-mesboot0’ in (gnu packages commencement) at the ’modify-phases’
[3]:

--8<---cut here---start->8---
 (add-after 'configure 'configure-fixups
   (lambda _
 (substitute* "config.h"
   (("#define GETCWD_BROKEN 1") "#undef GETCWD_BROKEN"))
 (let ((config.h (open-file "config.h" "a")))
   (display (string-append "
// tcc: error: undefined symbol 'enable_hostname_completion'
#define enable_hostname_completion(on_or_off) 0

// 
/gnu/store/cq0cmv35s9dhilx14zaghlc08gpc0hwr-tcc-boot0-0.9.26-6.c004e9a/lib/libc.a:
 error: 'sigprocmask' defined twice
#define HAVE_POSIX_SIGNALS 1
#define endpwent(x) 0
")
config.h)
   (close config.h))
 #t))
--8<---cut here---end--->8---

Let indicate me how to investigate, I have no clue. :-)

All the best,
simon

[1]:

[2]: 
[3]

bug#43232: [PATCH] gnu: jack-2: Update to 1.9.14.

[Mike Rosset]

Mark H Weaver  writes:

> Efraim Flashner  writes:
>
>> On Mon, Sep 14, 2020 at 09:25:25PM -0700, Mike Rosset wrote:
>>> * gnu/packages/audio.scm (jack-2): Update to 1.9.14.
>>> [arguments]: new 'declare-for-int phase after unpack that declares 'i in the
>>> for initialize statement.  Add -lstdc++ to LDFLAGS 'set-linkflags phase
>>> ensures -lstdc++ is at the tail.
> [...]
>>> @@ -2047,8 +2047,18 @@ synchronous execution of all clients, and low 
>>> latency operation.")
>>> "--alsa")
>>> #:phases
>>> (modify-phases %standard-phases
>>> + (add-after 'unpack 'declare-for-int
>>> +   (lambda _
>>> + ;; Declare the for loop i incrementer.
>>> + (substitute* "dbus/sigsegv.c"
>>> +   (("for\\(i = 0") "for(int i = 0"))
>>> + #t))
>>
>> Any chance of an upstream bug number or something for this? It seems
>> like the type of thing that might be put into a snippet.
>
> I agree that somehow this fix should be in the 'origin', so that this
> fix will be in the output of "guix build --source".  However, I'd go
> further and suggest that it should be a patch instead of a call to
> 'substitute*'.
>
> Although patches are larger and a bit more work to create, they are far
> more robust.  When this bug is eventually fixed upstream, a patch to fix
> it will begin raising an error, alerting us that it's time to remove it.
>
> In contrast, a call to 'substitute*' will silently start doing nothing,
> and may easily be forgotten.  To make matters worse, a future version of
> jack-2 might add another 'for' loop in that file, matching the same
> pattern but where it is important that 'i' _not_ be initialized to 0.
> This 'substitute*' call, likely vestigial by that time but long since
> forgotten, could start silently introducing a new bug.
>
> What do you think?
>
>   Thanks,
> Mark

Hello Mark,

 Turns out version 1.9.14 is not effected by this. So the version bump
is good enough. I resubmitted a first in series with just the version
bump and linker change. Which Andreas has merged into master.

Mike

bug#43232: [PATCH] gnu: jack-2: Update to 1.9.14.

[Mark H Weaver]

Earlier, I wrote:
> In contrast, a call to 'substitute*' will silently start doing nothing,
> and may easily be forgotten.  To make matters worse, a future version of
> jack-2 might add another 'for' loop in that file, matching the same
> pattern but where it is important that 'i' _not_ be initialized to 0.

Sorry, I made a mistake in the details here, since the pattern applies
only when 'i' is already initialized to 0, but the more general point
still stands, namely that patches are more robust than 'substitute*' for
fixing bugs, and less likely to be misapplied or left forgotten in a
vestigial state after they are no longer needed.

  Mark

bug#43232: [PATCH] gnu: jack-2: Update to 1.9.14.

[Mark H Weaver]

Efraim Flashner  writes:

> On Mon, Sep 14, 2020 at 09:25:25PM -0700, Mike Rosset wrote:
>> * gnu/packages/audio.scm (jack-2): Update to 1.9.14.
>> [arguments]: new 'declare-for-int phase after unpack that declares 'i in the
>> for initialize statement.  Add -lstdc++ to LDFLAGS 'set-linkflags phase
>> ensures -lstdc++ is at the tail.
[...]
>> @@ -2047,8 +2047,18 @@ synchronous execution of all clients, and low latency 
>> operation.")
>> "--alsa")
>> #:phases
>> (modify-phases %standard-phases
>> + (add-after 'unpack 'declare-for-int
>> +   (lambda _
>> + ;; Declare the for loop i incrementer.
>> + (substitute* "dbus/sigsegv.c"
>> +   (("for\\(i = 0") "for(int i = 0"))
>> + #t))
>
> Any chance of an upstream bug number or something for this? It seems
> like the type of thing that might be put into a snippet.

I agree that somehow this fix should be in the 'origin', so that this
fix will be in the output of "guix build --source".  However, I'd go
further and suggest that it should be a patch instead of a call to
'substitute*'.

Although patches are larger and a bit more work to create, they are far
more robust.  When this bug is eventually fixed upstream, a patch to fix
it will begin raising an error, alerting us that it's time to remove it.

In contrast, a call to 'substitute*' will silently start doing nothing,
and may easily be forgotten.  To make matters worse, a future version of
jack-2 might add another 'for' loop in that file, matching the same
pattern but where it is important that 'i' _not_ be initialized to 0.
This 'substitute*' call, likely vestigial by that time but long since
forgotten, could start silently introducing a new bug.

What do you think?

  Thanks,
Mark

bug#43418: ffprobe/avprobe and ffmpeg/avconv should be added as dependencies of youtube-dl so it will function correctly

[raingloom]

On Tue, 15 Sep 2020 14:06:11 +0200
Tobias Geerinckx-Rice via Bug reports for GNU Guix 
wrote:

> Hi Nathan,
> 
> Nathan Dehnel 写道：
> > bash-5.0$ youtube-dl -x 
> > https://www.youtube.com/watch?v=7Ijd_iN9Blk
> > [youtube] 7Ijd_iN9Blk: Downloading webpage
> > [download] Deadmau5 - Hit Save-7Ijd_iN9Blk.webm has already been 
> > downloaded
> > [download] 100% of 15.45MiB
> > ERROR: ffprobe/avprobe and ffmpeg/avconv not found. Please 
> > install one.  
> 
> It works fine without ‘-x’:
> 
>   λ youtube-dl https://www.youtube.com/watch?v=7Ijd_iN9Blk
>   [youtube] 7Ijd_iN9Blk: Downloading webpage
>   [download] Destination: Deadmau5 - Hit Save-7Ijd_iN9Blk.mp4
>   [download] 100% of 37.09MiB in 00:02
> 
> This *is* functioning correctly in my view: that advanced options 
> optionally require run-time dependencies is not a bug but a 
> feature.  The programme clearly explains which package could be 
> installed to continue, and the user can chose which one they 
> prefer - including neither, which suffices for the majority of 
> youtube-dling.
> 
> Matters would be different if the error message were less clear, 
> or perhaps if ffmpeg weren't so insanely great:
> 
>   λ guix size youtube-dl | tail -n1
>   total: 186.9 MiB
>   λ guix size youtube-dl ffmpeg | tail -n1
>   total: 811.2 MiB
> 
> (!)
> 
> Kind regards,
> 
> T G-R

Maybe it's time we added an "optional dependencies" field?
There seems to be a bug report or help request like every week that
just boils down to "this package has an undocumented dependency".

bug#43432: trilinos source vanished

[Efraim Flashner]

The source page for trilinos (gnu packages engineering) now points to a
Github page and the previous tarballs no longer seem to be available.
There's a content addressed substitute available from Berlin but I don't
see an original tarball from Debian to point to.


-- 
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#43232: [PATCH 2/2] gnu: jack2: 'declare-for-int phase no longer required.

[Mike Rosset]

Andreas Enge  writes:

> On Tue, Sep 15, 2020 at 01:37:05AM -0700, Mike Rosset wrote:
>> Apologies, I just wanted to keep a series for posterity which normally
>> I'm terrible at. I should have mentioned you could just squash them.
>
> No problem, it is just less work for me to apply just one patch :)

Totally understandable. I'll remember this in the future.

> I pushed the commit, thanks a lot! The new jack2 now also compiles on
> aarch64, so the original problem is solved.
>
> Andreas

Thanks for reviewing this, much appreciated.

Mike

bug#43232: [PATCH 2/2] gnu: jack2: 'declare-for-int phase no longer required.

[Andreas Enge]

On Tue, Sep 15, 2020 at 01:37:05AM -0700, Mike Rosset wrote:
> Apologies, I just wanted to keep a series for posterity which normally
> I'm terrible at. I should have mentioned you could just squash them.

No problem, it is just less work for me to apply just one patch :)

I pushed the commit, thanks a lot! The new jack2 now also compiles on
aarch64, so the original problem is solved.

Andreas

bug#25638: [Hunting]: linux libre 4.4.18 tarball has disappeared

[Ludovic Courtès]

Hi,

zimoun  skribis:

>> When building without substitutes, users should end up downloading:
>>
>>   
>> https://mirror.hydra.gnu.org/file/linux-libre-4.4.18-gnu.tar.xz/sha256/0k8k17in7dkjd9d8zg3i8l1ax466dba6bxw28flxizzyq8znljps
>>
>> … which is still available.
>
> Well, I am not sure to correctly understand the API of 
> in order to see if the tarball is currently on the build farm.

It’s available from

now (found a copy at hydra.gnunet.org!).  (This URL is served by ‘guix
publish’.)  There’s no GC root though.

> Is such version reachable with "guix time-machine"?  I guess no, so does
> it make sense to keep the tarball?

Good question, maybe not.

>> If disk space is a problem, I think it would be great if we could agree
>> on “pinning” specific versions that should never vanish from
>> ftp.gnu.org.  That way we could ensure future reproducibility of
>> Linux-libre and GuixSD.
>
> Such issue is discussed in #42162, especially the thread starting here:
>
>

Yes.

> Therefore, if the linux-libre 4.4.18 tarballs is substituable on
> , I suggest to close this bug.  WDYT?

Yeah, we can probably close it.  The more general issue of tarballs in
general, and linux-libre tarballs in particular, can be dealt with in
the issue above.

Thanks,
Ludo’.

bug#43366: "error: rmdir: Device or resource busy" when using btrfs

[Fredrik Salomonsson]

Hi Maxim,

Maxim Cournoyer  writes:

> I just sent a patch now, but here's a bit more background on what led to
> it.

Nice find! I'm unable to test out the patch right now on my original use
case as I soft bricked my laptop fiddling around with coreboot. And I'm
having some issues with my external flasher.

> The issue seems to be with:
>
> --8<---cut here---start->8---
>   ;; If a previous installation was attempted, make sure we start anew; in
>   ;; particular, we don't want to keep a store database that might not
>   ;; correspond to what we're actually putting in the store.
>   (let ((state (string-append target "/var/guix")))
> (when (file-exists? state)
>   (delete-file-recursively state)))
> --8<---cut here---end--->8---
>
> Which is part of the install procedure (which gets called when using
> 'guix system init /some/target').  So your guess was correct :-).

Yay!

> To confirm this was the case, I did:
>
> sudo btrfs subvolume create /tmp/toto
> mkdir /tmp/tata
> sudo mount -o subvol=/tmp/toto /dev/mapper/cryptroot /tmp/tata
>
> sudo -E guix repl
>> ,import (guix build utils)
>> (delete-file-recursively "/tmp/tata/")
> ice-9/boot-9.scm:1669:16: In procedure raise-exception:
> In procedure rmdir: Device or resource busy
>
> Bingo!
>
> Reading the docstring of delete-file-recursively, it says it should
> "report but ignore errors", so that's a bug.

Yeah, that's is the same error I get when running guix init. So this
sounds like it will fix my issue!

Thanks for the speedy fix.

-- 
s/Fred[re]+i[ck]+/Fredrik/g

bug#43109: Infinite loop in cl-subseq

[divoplade]

Hello,

Le mardi 15 septembre 2020 à 17:44 +0200, Michael Rohleder a écrit :
> I believe, this should be fixed with removing the emacs-seq package
> (commit 852ae64e11ef9107afabbdb307770f946376addd), no?

It is fixed as of now, yes.

bug#43406: Emacs 27.1 memory consumption grows indefinitely

[Ludovic Courtès]

Hi!

Pierre Neidhardt  skribis:

> I believe believe helm-ff cache came with Helm 3.6.4.
>
> I find it slow (and not so useful?) so I've disabled it with:
>
> (setq helm-ff-keep-cached-candidates nil)

Michael Rohleder  skribis:

> What helped me was disabling it with:
> (setq helm-ff-keep-cached-candidates nil)

I definitely helps, thanks!

I seem to have something else leaking still, but this time it’s
primarily Gnus and/or EIEIO:

--8<---cut here---start->8---
- command-execute   1,117,368,135  88%
 - call-interactively   1,117,276,295  88%
  - funcall-interactively   1,116,838,121  88%
   - gnus-group-save-newsrc   460,241,156  36%
- gnus-save-newsrc-file   460,241,156  36%
 - gnus-run-hooks 429,283,350  34%
  - apply 429,283,350  34%
   - run-hooks429,283,350  34%
- gnus-registry-save  429,283,350  34%
 - eieio-persistent-save  427,938,700  33%
  - apply 427,938,700  33%
   + #427,938,700  33%
 + gnus-registry--munge-group-names 1,340,064   0%
 + gnus-message 3,530   0%
 + gnus-gnus-to-quick-newsrc-format20,126,054   1%
 + save-buffer  9,613,098   0%
 + gnus-agent-save-local  595,652   0%
 + gnus-gnus-to-newsrc-format 577,848   0%
 + gnus-group-set-mode-line 6,458   0%
 + gnus-message 3,736   0%
 + gnus-dribble-delete-file 3,352   0%
   gnus-get-buffer-create   2,138   0%
 + gnus-prune-buffers   1,056   0%
   - gnus-topic-read-group208,616,775  16%
- gnus-group-read-group   208,616,775  16%
 - gnus-summary-read-group208,616,775  16%
  - gnus-summary-read-group-1 208,616,775  16%
   - gnus-run-hooks   163,821,469  13%
- apply   163,821,469  13%
 - run-hooks  163,821,469  13%
  - spam-find-spam162,365,376  12%
   - mapcar   162,328,432  12%
+ #   162,328,432  12%
   + gnus-parameter-spam-autodetect35,888   0%
   + gnus-parameter-spam-autodetect-methods 1,056   0%
  + gnus-apply-kill-file1,456,093   0%
   + gnus-select-newsgroup 31,456,212   2%
--8<---cut here---end--->8---

Any cache to turn off?  :-)

Ludo’.

bug#25638: [Hunting]: linux libre 4.4.18 tarball has disappeared

[zimoun]

Dear,

This bug report #25638  is about
the linux-libre tarballs for version 4.4.18 are no longer available on
their usual locations.


>> As a short-term fix could we upload the tarball for 4.4.18 to
>> ftp://alpha.gnu.org/gnu/guix/mirror as done before[1] for 3.3.8?
>>
>> [1]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=14851

Currently, such tarballs are not served by
, if I read correctly.


>> The lack of this tarball doesn’t hurt most users because a substitute
>> for the tarball is available on hydra, but this doesn’t help when
>> building everything without substitutes.
>
> When building without substitutes, users should end up downloading:
>
>   
> https://mirror.hydra.gnu.org/file/linux-libre-4.4.18-gnu.tar.xz/sha256/0k8k17in7dkjd9d8zg3i8l1ax466dba6bxw28flxizzyq8znljps
>
> … which is still available.

Well, I am not sure to correctly understand the API of 
in order to see if the tarball is currently on the build farm.

Is such version reachable with "guix time-machine"?  I guess no, so does
it make sense to keep the tarball?


> If disk space is a problem, I think it would be great if we could agree
> on “pinning” specific versions that should never vanish from
> ftp.gnu.org.  That way we could ensure future reproducibility of
> Linux-libre and GuixSD.

Such issue is discussed in #42162, especially the thread starting here:

   


Therefore, if the linux-libre 4.4.18 tarballs is substituable on
, I suggest to close this bug.  WDYT?


All the best,
simon

bug#43109: Infinite loop in cl-subseq

[Michael Rohleder]

Hello divoplade,

I believe, this should be fixed with removing the emacs-seq package
(commit 852ae64e11ef9107afabbdb307770f946376addd), no?


signature.asc
Description: PGP signature

bug#43421: Encoding issue in exported archive signatures

[Ludovic Courtès]

Hi,

Ludovic Courtès  skribis:

> Following the ‘guix authenticate’ in commit
> 64cf660f872fb7aaf0d2b463e45b4c756297f743¹, I’m observing encoding
> issues:
>
>   guix archive --export \
> /gnu/store/3p5wcw2a0844rbcmlrqfjx8bx7b7gq34-r-rvest-0.3.6-guile-builder
>
> yield an archive with this signature:
>
> (signature
>  (data
>   (flags rfc6979)
>   (hash sha256 
> #1DEE0418AF5FD8A05D2142290BA03735176FA27BB68B3A02977C774EA3DBDAEC#)
>   )
>  (sig-val
>   (ecdsa
>(r #072B8E5C6B84D4ED469EC2CF63103621602E9AF3902E454CAD49CFA6BDE2FBF0#)
>(s "~%*Øw2%YZ»+yvc*¤Ì44C;RM\t3EQIp<ü")
>)
>   )
>  (public-key
>   (ecc
>(curve Ed25519)
>(q #8D156F295D24B0D9A86FA5741A840FF2D24F60F7B6C4134814AD55625971B394#)
>)
>   )
>  )
>
> Notice the ‘s’ field of the signature.
>
> The problem does not occur systematically: it depends on the byte string
> (libgcrypt encodes Latin-1ish strings as strings and other strings as
> hex sequences.)  The problem is similar to 
> .

Fixed in b911d6547444b5f8d17b224bafa5ee1b5aafaff5!

> The interesting bit is that this archive can be correctly ingested by a
> new daemon, but it fails signature verification with an older daemon.

This is because when using the new daemon on both sides, we were
encoding/decoding strings as UTF-8, which made no sense but worked
well.  Older implementations rightfully expect “raw strings”
aka. ISO-8859-1.

Ludo’.

bug#43402: [BUG] python-gssapi-1.6.5 not building

[Michael Rohleder]

Hello Kurt,

Thank you the report!
It has been reported twice in these bugs, so I will merge it:
42370 43284


-- 
SVRMGR> shutdown
ORA-01034: ORACLE not available
SVRMGR> startup
ORA-01081: cannot start already-running ORACLE - shut it down first


signature.asc
Description: PGP signature

bug#43406: Emacs 27.1 memory consumption grows indefinitely

[Michael Rohleder]

Hi Ludovic,

I also had trouble with that helm caching. I had the impression that it
was because of newer helm versions not emacs versions.

What helped me was disabling it with:
(setq helm-ff-keep-cached-candidates nil)

-- 
Alles fließt, nichts bleibt.
 Heraklit


signature.asc
Description: PGP signature

bug#43406: Emacs 27.1 memory consumption grows indefinitely

[Ludovic Courtès]

More precisely:

--8<---cut here---start->8---
- timer-event-handler 805,671,418  87%
 - apply  804,987,874  87%
  - helm-ff--cache-mode-refresh   802,103,698  86%
   - helm-ff--cache-mode-refresh-1801,321,290  86%
- helm-ff-refresh-cache   801,237,818  86%
 - maphash801,237,818  86%
  + #  801,237,818  86%
  helm-ff--cache-mode-max-idle-time 6,384   0%
   + run-with-idle-timer  651,464   0%
--8<---cut here---end--->8---

bug#43406: Emacs 27.1 memory consumption grows indefinitely

[Ludovic Courtès]

Hi!

Ludovic Courtès  skribis:

> Since I upgraded to Emacs 27.1, its memory consumption grows without
> bounds, to the point that it gets OOM-killed after just a couple of
> hours (meaning that it’s used most of the 16G of RAM of my laptop!).
>
> Does that ring a bell to anyone?  I have 50+ ^emacs- packages in my
> profile; any clues on what could be the cause before diving further?
>
> $ guix package -I ^emacs$
> emacs   27.1out /gnu/store/ipgb6s3phz3n740xlcdzaxnbgvncdh11-emacs-27.1
> $ guix describe
> Generacio 157   Sep 10 2020 08:49:21(nuna)
>   guix 7090159
> repository URL: https://git.savannah.gnu.org/git/guix.git
> branch: master
> commit: 7090159c23d6345992ab976d71fefeb1583cfcdf

Emacs is about to crash :-), so let me share this finding from
M-x profiler-report (mem) on a sample of a few minutes:

--8<---cut here---start->8---
- timer-event-handler 805,671,418  87%
 - apply  804,987,874  87%
  + helm-ff--cache-mode-refresh   802,103,698  86%
  + emms-playing-time-display   1,349,461   0%
  + battery-update-handler  1,109,005   0%
  + #221,094   0%
  + # 49,632   0%
  + blink-cursor-start 30,368   0%
  + auto-revert-buffers29,480   0%
  + highlight-symbol-temp-highlight22,076   0%
  + mouse-avoidance-fancy  20,440   0%
  + display-time-event-handler 18,383   0%
  + show-paren-function13,464   0%
  + erc-server-send-ping7,500   0%
jit-lock-force-redisplay4,136   0%
  + blink-cursor-timer-function 4,136   0%
  + nnimap-keepalive2,400   0%
  + gnus-demon-run-callback 1,545   0%
  + isearch-lazy-highlight-start1,056   0%
 + timer-activate 306,016   0%
 + timer-inc-time 191,264   0%
 + timer-activate-when-idle92,928   0%
+ command-execute 100,936,674  10%
+ erc-server-filter-function5,178,272   0%
+ redisplay_internal (C function)   4,988,306   0%
--8<---cut here---end--->8---

It’s Helm eating memory at each timer tick.  That’s with:

--8<---cut here---start->8---
emacs-helm-wikipedia0.0.0-1.126f044 out 
/gnu/store/iy08rcx4hbravm9k3qlinc4wvklp3pqi-emacs-helm-wikipedia-0.0.0-1.126f044
emacs-helm-swoop3.0.0   out 
/gnu/store/qnr6asnk0b360ilx8cnrp35kwrh4fsf7-emacs-helm-swoop-3.0.0
emacs-helm-shell-history0.1-1.110d3c3   out 
/gnu/store/ljgfa72mw8jx6br9khl7idcmrw4i33hc-emacs-helm-shell-history-0.1-1.110d3c3
emacs-helm-make 0.1.0-1.feae8df out 
/gnu/store/lnizl47zxlj03waficpy7fvfrx1mdqn7-emacs-helm-make-0.1.0-1.feae8df
emacs-helm-ls-git   1.9.1-1.76654c7 out 
/gnu/store/897fkkh4bzpvbd06kf7vxr53hgkk0vfs-emacs-helm-ls-git-1.9.1-1.76654c7
emacs-helm-gtags1.5.7   out 
/gnu/store/lhibi05hvvn3zglcx2ii44yw723pfyja-emacs-helm-gtags-1.5.7
emacs-helm  3.6.5   out 
/gnu/store/ka9lph0hpzaky0sa52zf09469apkhb68-emacs-helm-3.6.5
emacs-helm-system-packages  1.10.1-1.6572340out 
/gnu/store/lvkan5dsbcdkvl3y1fjmsgb423nzmmqc-emacs-helm-system-packages-1.10.1-1.6572340
emacs-helm-emms 1.3-3.37e5aa0   out 
/gnu/store/g06lnxvyqnp9d2yqgfanp69350f7m2yp-emacs-helm-emms-1.3-3.37e5aa0
--8<---cut here---end--->8---

Cc’ing a couple of people who I think use Helm and hopefully have
valuable advice to share.  :-)

Ludo’.

bug#25913: [PATCH 0/1] Fix unreachable gdsl package

[zimoun]

On Tue, 15 Sep 2020 at 16:01, zimoun  wrote:

> $ guix time-machine --commit=f6dfe42 -- build gdsl
> /gnu/store/yd0vadqjx998v76ynx27klg7i62ra1l1-gdsl-1.8
>
> $ ./pre-inst-env guix build gdsl
> /gnu/store/zp18gsfw128aam2ifh9rsfn7wxx1fnzh-gdsl-1.8
>
> $ diff -r --no-dereference \
>   /gnu/store/zp18gsfw128aam2ifh9rsfn7wxx1fnzh-gdsl-1.8 \
>   /gnu/store/yd0vadqjx998v76ynx27klg7i62ra1l1-gdsl-1.8
> diff -r --no-dereference 
> /gnu/store/zp18gsfw128aam2ifh9rsfn7wxx1fnzh-gdsl-1.8/bin/gdsl-config 
> /gnu/store/yd0vadqjx998v76ynx27klg7i62ra1l1-gdsl-1.8/bin/gdsl-config
> 3c3
> < prefix=/gnu/store/zp18gsfw128aam2ifh9rsfn7wxx1fnzh-gdsl-1.8
> ---
>> prefix=/gnu/store/yd0vadqjx998v76ynx27klg7i62ra1l1-gdsl-1.8
> diff -r --no-dereference 
> /gnu/store/zp18gsfw128aam2ifh9rsfn7wxx1fnzh-gdsl-1.8/lib/libgdsl.la 
> /gnu/store/yd0vadqjx998v76ynx27klg7i62ra1l1-gdsl-1.8/lib/libgdsl.la
> 41c41
> < libdir='/gnu/store/zp18gsfw128aam2ifh9rsfn7wxx1fnzh-gdsl-1.8/lib'
> ---
>> libdir='/gnu/store/yd0vadqjx998v76ynx27klg7i62ra1l1-gdsl-1.8/lib'
>
> zimoun (1):
>   gnu: gdsl: Replace 'url-fetch' by 'git-fetch'.
>
>  gnu/packages/datastructures.scm | 11 ++-
>  1 file changed, 6 insertions(+), 5 deletions(-)

The patch is in .

bug#25913: [PATCH 0/1] Fix unreachable gdsl package

[zimoun]

Dear,

The mention of the gna.org closing down is reported in bug #25913
.  Therefore, the package gdsl is not
maintained and the both URLs source and home-page are now unreachable.
Currently, substitutes are available on  but nothing prevents
an unfortunate "guix gc".  This patch uses Software Heritage as an archive for
upstream source, but since tarballs are not yet fully supported by SWH, the
support 'git-fetch' is used instead.

Last, let check the integrity of the switch.

--8<---cut here---start->8---
$ guix time-machine --commit=f6dfe42 -- build gdsl
/gnu/store/yd0vadqjx998v76ynx27klg7i62ra1l1-gdsl-1.8

$ ./pre-inst-env guix build gdsl
/gnu/store/zp18gsfw128aam2ifh9rsfn7wxx1fnzh-gdsl-1.8

$ diff -r --no-dereference \
  /gnu/store/zp18gsfw128aam2ifh9rsfn7wxx1fnzh-gdsl-1.8 \
  /gnu/store/yd0vadqjx998v76ynx27klg7i62ra1l1-gdsl-1.8
diff -r --no-dereference 
/gnu/store/zp18gsfw128aam2ifh9rsfn7wxx1fnzh-gdsl-1.8/bin/gdsl-config 
/gnu/store/yd0vadqjx998v76ynx27klg7i62ra1l1-gdsl-1.8/bin/gdsl-config
3c3
< prefix=/gnu/store/zp18gsfw128aam2ifh9rsfn7wxx1fnzh-gdsl-1.8
---
> prefix=/gnu/store/yd0vadqjx998v76ynx27klg7i62ra1l1-gdsl-1.8
diff -r --no-dereference 
/gnu/store/zp18gsfw128aam2ifh9rsfn7wxx1fnzh-gdsl-1.8/lib/libgdsl.la 
/gnu/store/yd0vadqjx998v76ynx27klg7i62ra1l1-gdsl-1.8/lib/libgdsl.la
41c41
< libdir='/gnu/store/zp18gsfw128aam2ifh9rsfn7wxx1fnzh-gdsl-1.8/lib'
---
> libdir='/gnu/store/yd0vadqjx998v76ynx27klg7i62ra1l1-gdsl-1.8/lib'
--8<---cut here---end--->8---

zimoun (1):
  gnu: gdsl: Replace 'url-fetch' by 'git-fetch'.

 gnu/packages/datastructures.scm | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

-- 
2.28.0

bug#43423: [core-updates] Mesa test suite fails

[Maxim Cournoyer]

Mesa fails to build on current core-updates:

starting phase `check'
[1/31] Generating git_sha1.h with a custom command
[1/2] Running all tests.
 1/94 mesa:util / drirc xml validation  OK 0.00s
 2/94 mesa:util / u_atomic  OK 0.00s
 3/94 mesa:util / blob  OK 0.00s
 4/94 mesa:util / rb_tree   OK 0.00s
 5/94 mesa:util / roundeven OK 0.00s
 6/94 mesa:util / mesa-sha1 OK 0.00s
 7/94 mesa:util / bitsetOK 0.00s
 8/94 mesa:util / fast_idiv_by_constOK 0.37s
 9/94 mesa:util / fast_urem_by_constOK 0.02s
10/94 mesa:util / clear OK 0.00s
11/94 mesa:util / collision OK 0.00s
12/94 mesa:util / delete_and_lookup OK 0.00s
13/94 mesa:util / delete_management OK 0.00s
14/94 mesa:util / destroy_callback  OK 0.00s
15/94 mesa:util / insert_and_lookup OK 0.00s
16/94 mesa:util / insert_many   OK 0.00s
17/94 mesa:util / null_destroy  OK 0.00s
18/94 mesa:util / random_entry  OK 0.00s
19/94 mesa:util / remove_keyOK 0.00s
20/94 mesa:util / remove_null   OK 0.00s
21/94 mesa:util / replacement   OK 0.00s
22/94 mesa:util / string_buffer OK 0.00s
23/94 mesa:util / timespec  OK 0.00s
24/94 mesa:util / vma_randomOK 0.00s
25/94 mesa:util / set   OK 0.00s
26/94 mesa:util / sparse_array_multi_threaded   OK 0.37s
27/94 mesa:format / srgbOK 0.00s
28/94 mesa:format / u_format_test   OK 0.01s
29/94 mesa:format / u_format_compatible_testOK 0.00s
30/94 mesa:util / vectorOK 0.00s
31/94 mesa:mapi / shared-glapi-test OK 0.00s
32/94 mesa:mapi / shared-glapi symbols checkOK 0.06s
33/94 mesa:mapi / es1-ABI-check OK 0.07s
34/94 mesa:mapi / es2-ABI-check OK 0.07s
35/94 mesa:compiler+nir / nir_builder   OK 0.00s
36/94 mesa:compiler+nir / nir_control_flow  OK 0.00s
37/94 mesa:compiler+nir / nir_vars  OK 0.00s
38/94 mesa:compiler+nir / nir_algebraic_parser  OK 0.11s
39/94 mesa:compiler+nir / negative_equalOK 0.00s
40/94 mesa:compiler+nir / comparison_preOK 0.00s
41/94 mesa:compiler+nir / load_store_vectorizer OK 0.00s
42/94 mesa:compiler+nir / nir_serialize_testOK 0.00s
43/94 mesa:compiler+glcpp / glcpp test (unix)   FAIL   0.17s (exit 
status 1)
44/94 mesa:compiler+glcpp / glcpp test (windows)FAIL   0.17s (exit 
status 1)
45/94 mesa:compiler+glcpp / glcpp test (oldmac) FAIL   0.17s (exit 
status 1)
46/94 mesa:compiler+glcpp / glcpp test (bizarro)FAIL   0.17s (exit 
status 1)
47/94 mesa:compiler+glsl / cache_test   OK 0.02s
48/94 mesa:compiler+glsl / general_ir_test  OK 0.00s
49/94 mesa:compiler+glsl / uniform_initializer_test OK 0.00s
50/94 mesa:compiler+glsl / sampler_types_test   OK 0.00s
51/94 mesa:compiler+glsl / glsl compiler warnings   OK 0.22s
52/94 mesa:compiler+glsl / glsl optimizationOK 0.12s
53/94 mesa:amd / radv symbols check OK 0.07s
54/94 mesa:intel / gen_device_info_test OK 0.00s
55/94 mesa:intel / isl_surf_get_image_offsetOK 0.00s
56/94 mesa:intel / genxml_test  OK 0.00s
57/94 mesa:intel / fs_cmod_propagation  OK 0.00s
58/94 mesa:intel / fs_copy_propagation  OK 0.00s
59/94 mesa:intel / fs_saturate_propagation  OK 0.00s
60/94 mesa:intel / vf_float_conversions OK 0.00s
61/94 mesa:intel / vec4_register_coalesce   OK 0.00s
62/94 mesa:intel / vec4_copy_propagationOK 0.00s
63/94 mesa:intel / vec4_cmod_propagationOK 0.00s
64/94 mesa:intel / vec4_dead_code_eliminate OK 0.00s
65/94 mesa:intel / eu_compact   OK 0.72s
66/94 mesa:intel / eu_validate   

bug#42740: Segfault in libssh during ‘guix copy’

[Maxim Cournoyer]

Hi Ludovic,

Ludovic Courtès  writes:

> Hi Maxim,
>
> Maxim Cournoyer  skribis:
>
>> What is the manifestation of the current guile-ssh remaining problems?
>
> To me, the Guile-SSH problems were successfully worked around on our
> side with 61fe9ced7da7eefceb931af0cb7363b721f5bdd6.  It could be that
> you found an issue we didn’t address.
>
>> Is it like the error message below?
>>
>> guix offload: error: corrupt input while restoring archive from #> string 7ff371d9e7e0>
>>
>> I just had this today during guix offload.
>
> Hmm.  Is it reproducible?  Can you show the 10-or-so lines above, to see
> if the build completed, whether the error happened while sending build
> results, etc.?

Sorry for the noise, I cannot reproduce after restarting guix-daemon.  I
guess I just hadn't restarted it in a long time (the recent testing I
did for the fix was with a locally started daemon in my guix checkout).

Thank you,

Maxim

bug#43132: [GUIX SYSTEM]: Malfunction

[Maxim Cournoyer]

Hello Raghav,

Raghav Gururajan  writes:

> Hi!
>
>> Maxim Cournoyer  skribis:
>> 
>>> I took Raghav to #btrfs last week, where with the help of gentle folks a
>>> failing drive was established as the most likely culprit.
>>>
>>> In other words, Btrfs checksuming capabilities helped quickly
>>> discovering a hardware problem which might otherwise have silently
>>> caused non-recoverable damage to Raghav's data.
>> 
>> Good, thanks for following up!
>> 
>> Ludo’.
>
> Thank you!
>
> Yeah, seems like my disk is shot, but I am not sure. I have reinstalled
> guix with ext4, instead of btrfs, as these issues started to arise after
> migration to btrfs from ext4. So far, my system is doing well. Lets see
> how it goes. :-)

Sounds like playing with fire to me :-).

Ext4 won't detect bitrot (silent corruption of your drive's data).
You'll probably wake one day with a fsck that won't be able to recover
some files, or worst, a completely dead drive.

Your backups would also contain corrupted data (garbage in, garbage
out!).

Maxim

bug#43420: icecat causes pulseaudio to crash

[Nathan Dehnel]

So...playing a youtube video in icecat causes pulse to crash. You can
play one video and it works, but it crashes if you open another tab or
page with a video in it. Also skipping around the seekbar causes it to
crash.

bash-5.0$ pulseaudio
W: [pulseaudio] pid.c: Stale PID file, overwriting.
E: [pulseaudio] bluez5-util.c: GetManagedObjects() failed:
org.freedesktop.DBus.Error.ServiceUnknown: The name org.bluez was not
provided by any .service files
E: [pulseaudio] module-stream-restore.c: Assertion
'pa_hashmap_put(u->dbus_entries, de->entry_name, de) == 0' failed at
modules/module-stream-restore.c:1406, function subscribe_callback().
Aborting.

Chromium and mpv do not cause pulse to crash.

bug#43402: Addition

[Kurt]

This error is showing up when trying to build the "synapse" matrix
server.

bug#43421: Encoding issue in exported archive signatures

[Ludovic Courtès]

Following the ‘guix authenticate’ in commit
64cf660f872fb7aaf0d2b463e45b4c756297f743¹, I’m observing encoding
issues:

  guix archive --export \
/gnu/store/3p5wcw2a0844rbcmlrqfjx8bx7b7gq34-r-rvest-0.3.6-guile-builder

yield an archive with this signature:

--8<---cut here---start->8---
(signature
 (data
  (flags rfc6979)
  (hash sha256 
#1DEE0418AF5FD8A05D2142290BA03735176FA27BB68B3A02977C774EA3DBDAEC#)
  )
 (sig-val
  (ecdsa
   (r #072B8E5C6B84D4ED469EC2CF63103621602E9AF3902E454CAD49CFA6BDE2FBF0#)
   (s "~%*Øw2%YZ»+yvc*¤Ì44C;RM\t3EQIp<ü")
   )
  )
 (public-key
  (ecc
   (curve Ed25519)
   (q #8D156F295D24B0D9A86FA5741A840FF2D24F60F7B6C4134814AD55625971B394#)
   )
  )
 )
--8<---cut here---end--->8---

Notice the ‘s’ field of the signature.

The problem does not occur systematically: it depends on the byte string
(libgcrypt encodes Latin-1ish strings as strings and other strings as
hex sequences.)  The problem is similar to .

The interesting bit is that this archive can be correctly ingested by a
new daemon, but it fails signature verification with an older daemon.

Ludo’.

¹ https://issues.guix.gnu.org/43340

bug#43418: ffprobe/avprobe and ffmpeg/avconv should be added as dependencies of youtube-dl so it will function correctly

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Hi Nathan,

Nathan Dehnel 写道：
bash-5.0$ youtube-dl -x 
https://www.youtube.com/watch?v=7Ijd_iN9Blk

[youtube] 7Ijd_iN9Blk: Downloading webpage
[download] Deadmau5 - Hit Save-7Ijd_iN9Blk.webm has already been 
downloaded

[download] 100% of 15.45MiB
ERROR: ffprobe/avprobe and ffmpeg/avconv not found. Please 
install one.


It works fine without ‘-x’:

 λ youtube-dl https://www.youtube.com/watch?v=7Ijd_iN9Blk
 [youtube] 7Ijd_iN9Blk: Downloading webpage
 [download] Destination: Deadmau5 - Hit Save-7Ijd_iN9Blk.mp4
 [download] 100% of 37.09MiB in 00:02

This *is* functioning correctly in my view: that advanced options 
optionally require run-time dependencies is not a bug but a 
feature.  The programme clearly explains which package could be 
installed to continue, and the user can chose which one they 
prefer - including neither, which suffices for the majority of 
youtube-dling.


Matters would be different if the error message were less clear, 
or perhaps if ffmpeg weren't so insanely great:


 λ guix size youtube-dl | tail -n1
 total: 186.9 MiB
 λ guix size youtube-dl ffmpeg | tail -n1
 total: 811.2 MiB

(!)

Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#43132: [GUIX SYSTEM]: Malfunction

[Raghav Gururajan]

Hi!

> Maxim Cournoyer  skribis:
> 
>> I took Raghav to #btrfs last week, where with the help of gentle folks a
>> failing drive was established as the most likely culprit.
>>
>> In other words, Btrfs checksuming capabilities helped quickly
>> discovering a hardware problem which might otherwise have silently
>> caused non-recoverable damage to Raghav's data.
> 
> Good, thanks for following up!
> 
> Ludo’.

Thank you!

Yeah, seems like my disk is shot, but I am not sure. I have reinstalled
guix with ext4, instead of btrfs, as these issues started to arise after
migration to btrfs from ext4. So far, my system is doing well. Lets see
how it goes. :-)

Regards,
RG.



signature.asc
Description: OpenPGP digital signature

bug#43418: ffprobe/avprobe and ffmpeg/avconv should be added as dependencies of youtube-dl so it will function correctly

[Nathan Dehnel]

bash-5.0$ youtube-dl -x https://www.youtube.com/watch?v=7Ijd_iN9Blk
[youtube] 7Ijd_iN9Blk: Downloading webpage
[download] Deadmau5 - Hit Save-7Ijd_iN9Blk.webm has already been downloaded
[download] 100% of 15.45MiB
ERROR: ffprobe/avprobe and ffmpeg/avconv not found. Please install one.

bug#43166: The issues.guix.gnu.org is hard to read in emacs-w3m.

[Mark H Weaver]

Earlier, I wrote:
> However, I've noticed that in Dillo with CSS disabled, generating a
> 'pre' for each line makes the line spacing larger than would be ideal.
> It seems that some vertical padding or margins are added around each
> 'pre'.  It's likely that many browsers do this in their default styling
> for 'pre'.  With this in mind, it would perhaps be better to wrap a
> single 'pre' around each message.  Then you could either (1) leave the
> lines as 'span's and add a raw CR-LF after each line (which would make
> the HTML source code more readable) or (2) change the 'span's to 'div's
> as in your proposed patch.

Actually, I just found by experimentation that option (2) above doesn't
work well in either Lynx or Dillo.  Option (1) works well in the simple
browsers I've tried so far, which are Lynx, Dillo, Netsurf, and Eww.

   Mark


Title: test

  
  
line1
line2
  line3
line4

  

Title: test

  
  
line1line2  line3line4
  

bug#43166: The issues.guix.gnu.org is hard to read in emacs-w3m.

[Mark H Weaver]

Ricardo Wurmus  writes:

>> On Mon, 14 Sep 2020 at 22:58, Mark H Weaver  wrote:
>>
>>> For what it's worth: not everyone uses Emacs, and it would be good to
>>> support users who choose to use simpler software.  I guess that it would
>>> be quite easy to modify the software behind 'issues.guix.gnu.org' to
>>> generate HTML that works well with simpler web browsers, so I'd prefer
>>> to keep this bug open.  What do you think?
[...]
> As the primary author of mumi (the software behind issues.guix.gnu.org)
> I agree with Mark and think this is worth fixing.  [...]

Thank you, Ricardo.

> There is no good reason why this should not be usable by people who use
> a simpler browser (I’m one of these people on some days).  If it turns
> out to be tricky to implement or to cause a degraded experience for
> those who use popular browsers we can still close this, but I think we
> should at least try.

Fair enough.

Thanks also for your proposed patch to change some spans to divs.  It's
a significant improvement, but there remains a very serious problem:
multiple spaces are being collapsed into a single space, and leading
spaces are lost entirely.  This destroys the indentation of all inline
code and patches.  The two solutions I know are (1) to generate 'pre'
elements, or (2) to convert leading spaces and runs of two or more
spaces into runs of 'nbsp' entities.

(I'm deliberately avoiding HTML syntax in this email, for fear that some
email clients may try to render it).

My suggestion would be to generate 'pre' elements.  It would avoid runs
of 'nbsp' entites making the raw html larger and harder to read.  It
would also ensure that a fixed width font is used.

My first thought was to simply modify your patch to change the 'span's
with class "line" into 'pre's instead of 'div's.  If 'pre' comes with
default styling that you don't like, perhaps it could be overridden by
additional code in screen.css.  I guess this approach would likely work
well enough in practice.

However, I've noticed that in Dillo with CSS disabled, generating a
'pre' for each line makes the line spacing larger than would be ideal.
It seems that some vertical padding or margins are added around each
'pre'.  It's likely that many browsers do this in their default styling
for 'pre'.  With this in mind, it would perhaps be better to wrap a
single 'pre' around each message.  Then you could either (1) leave the
lines as 'span's and add a raw CR-LF after each line (which would make
the HTML source code more readable) or (2) change the 'span's to 'div's
as in your proposed patch.

Another issue, which affects Dillo, is that ASCII apostrophes (') are
being converted to 'apos' entities, which are not valid HTML 4.  Dillo
renders these as the raw source, namely "&" followed by "apos" and ";",
which corrupts English text.  I suggest removing the third entry in
%escape-chars in (mumi web sxml).  Is there a reason to keep it?

What do you think?

   Thanks again,
   Mark

bug#43166: The issues.guix.gnu.org is hard to read in emacs-w3m.

[Jan Nieuwenhuizen]

Ricardo Wurmus writes:

> The attached patch seems to fix the worst problems.

Ohh...thank you!!!  This makes issues at least readable in EWW.

It's a bit annoying to change issues URLs into bugs.gnu.org urls and
this also made me reluctant to share issues URLs -- altough I greatly
appreciate all the work you have been doing here: in heavyweight modern
mouse-shoving-browsers --that I personally try to avoid-- it really
looks beautiful.

> What do you think?

It seems that EWW ignores ’monospace’...

-.message span.line {
+.message div.line {
 white-space: pre-wrap;
 font-family: monospace;
 display: block;
 }

... here, or otherwise "eats" spaces; so diffs/patches are still a bit
annoying to read.  Ideas?

Greetings,
Janneke

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

bug#43416: waybar 0.9.3 fails to build

[Efraim Flashner]

On Mon, Sep 14, 2020 at 10:18:01PM -0500, bdju via Bug reports for GNU Guix 
wrote:
> build log: http://ix.io/2xBx
> guix (GNU Guix) 818237d947f0f48eaa1033bca9e090ceeeb5a9ab
> 

I checked upstream and there doesn't seem to be a way yet to build
waybar with fmt-7 so I've built it with fmt-6 like before.

-- 
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#43232: [PATCH 2/2] gnu: jack2: 'declare-for-int phase no longer required.

[Mike Rosset]

Andreas Enge  writes:

> Hello Mike,
>
> On Tue, Sep 15, 2020 at 12:48:02AM -0700, Mike Rosset wrote:
>> * gnu/packages/audio.scm (jack2): remove 'declare-for-int phase.
>> [arguements]: phases 'declare-for-int has been removed. since package now
>> builds.
>
> I am getting a bit lost; it looks like this patch has to be applied on top
> of your previous one. But since the previous one is not in master yet, there
> will be no point in pushing one patch, then another one that partially
> reverts the first one.
>
> Could you please just post a new patch with the one modification you propose,
> to be applied on master?
>
> Thanks,
>
> Andreas

Apologies, I just wanted to keep a series for posterity which normally
I'm terrible at. I should have mentioned you could just squash them.

I emailed a new first in series that squashed and improved the commit
message.

Hope that helps.

Mike

bug#43232: [PATCH] gnu: jack-2: Update to 1.9.14.

[Mike Rosset]

* gnu/packages/audio.scm (jack-2): Update to 1.9.14.
[arguments]: 'set-linkflags phase now adds -lstdc++ to the LDFLAGS
environment variable.

This fixes an issue that where the linker would fail with "undefined reference
to symbol '__gxx_personality_v0@@CXXABI_1.3" on aarch64-linux system.
---
 gnu/packages/audio.scm | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/audio.scm b/gnu/packages/audio.scm
index 38ee4f8bcc..fb98777290 100644
--- a/gnu/packages/audio.scm
+++ b/gnu/packages/audio.scm
@@ -2030,7 +2030,7 @@ synchronous execution of all clients, and low latency 
operation.")
 (define-public jack-2
   (package (inherit jack-1)
 (name "jack2")
-(version "1.9.13")
+(version "1.9.14")
 (source (origin
  (method url-fetch)
  (uri (string-append "https://github.com/jackaudio/jack2/releases/;
@@ -2039,7 +2039,7 @@ synchronous execution of all clients, and low latency 
operation.")
  (file-name (string-append name "-" version ".tar.gz"))
  (sha256
   (base32
-   "1d1d403jn4366mqig6g8ghr8057b3rn7gs26b5p3rkal34j20qw2"
+   "0z11hf55a6mi8h50hfz5wry9pshlwl4mzfwgslghdh40cwv342m2"
 (build-system waf-build-system)
 (arguments
  `(#:tests? #f  ; no check target
@@ -2049,6 +2049,10 @@ synchronous execution of all clients, and low latency 
operation.")
(modify-phases %standard-phases
  (add-before 'configure 'set-linkflags
(lambda _
+ ;; Ensure -lstdc++ is the tail of LDFLAGS or the simdtests.cpp
+ ;; will not link with undefined reference to symbol
+ ;; '__gxx_personality_v0@@CXXABI_1.3'
+ (setenv "LDFLAGS" "-lstdc++")
  ;; Add $libdir to the RUNPATH of all the binaries.
  (substitute* "wscript"
((".*CFLAGS.*-Wall.*" m)
-- 
2.28.0

bug#42740: Segfault in libssh during ‘guix copy’

[Ludovic Courtès]

Hi Maxim,

Maxim Cournoyer  skribis:

> What is the manifestation of the current guile-ssh remaining problems?

To me, the Guile-SSH problems were successfully worked around on our
side with 61fe9ced7da7eefceb931af0cb7363b721f5bdd6.  It could be that
you found an issue we didn’t address.

> Is it like the error message below?
>
> guix offload: error: corrupt input while restoring archive from # string 7ff371d9e7e0>
>
> I just had this today during guix offload.

Hmm.  Is it reproducible?  Can you show the 10-or-so lines above, to see
if the build completed, whether the error happened while sending build
results, etc.?

Thanks,
Ludo’.

bug#43416: waybar 0.9.3 fails to build

[bdju]

build log: http://ix.io/2xBx
guix (GNU Guix) 818237d947f0f48eaa1033bca9e090ceeeb5a9ab

bug#43232: [PATCH 2/2] gnu: jack2: 'declare-for-int phase no longer required.

[Andreas Enge]

Hello Mike,

On Tue, Sep 15, 2020 at 12:48:02AM -0700, Mike Rosset wrote:
> * gnu/packages/audio.scm (jack2): remove 'declare-for-int phase.
> [arguements]: phases 'declare-for-int has been removed. since package now
> builds.

I am getting a bit lost; it looks like this patch has to be applied on top
of your previous one. But since the previous one is not in master yet, there
will be no point in pushing one patch, then another one that partially
reverts the first one.

Could you please just post a new patch with the one modification you propose,
to be applied on master?

Thanks,

Andreas

bug#43232: [PATCH 2/2] gnu: jack2: 'declare-for-int phase no longer required.

[Mike Rosset]

* gnu/packages/audio.scm (jack2): remove 'declare-for-int phase.
[arguements]: phases 'declare-for-int has been removed. since package now
builds.
---
 gnu/packages/audio.scm | 6 --
 1 file changed, 6 deletions(-)

diff --git a/gnu/packages/audio.scm b/gnu/packages/audio.scm
index 83c08b718e..fb98777290 100644
--- a/gnu/packages/audio.scm
+++ b/gnu/packages/audio.scm
@@ -2047,12 +2047,6 @@ synchronous execution of all clients, and low latency 
operation.")
"--alsa")
#:phases
(modify-phases %standard-phases
- (add-after 'unpack 'declare-for-int
-   (lambda _
- ;; Declare the for loop i incrementer.
- (substitute* "dbus/sigsegv.c"
-   (("for\\(i = 0") "for(int i = 0"))
- #t))
  (add-before 'configure 'set-linkflags
(lambda _
  ;; Ensure -lstdc++ is the tail of LDFLAGS or the simdtests.cpp
-- 
2.28.0

bug#43232: [PATCH] gnu: jack-2: Update to 1.9.14.

[Mike Rosset]

Efraim Flashner  writes:

> On Mon, Sep 14, 2020 at 09:25:25PM -0700, Mike Rosset wrote:
>> (modify-phases %standard-phases
>> + (add-after 'unpack 'declare-for-int
>> +   (lambda _
>> + ;; Declare the for loop i incrementer.
>> + (substitute* "dbus/sigsegv.c"
>> +   (("for\\(i = 0") "for(int i = 0"))
>> + #t))
>
> Any chance of an upstream bug number or something for this? It seems
> like the type of thing that might be put into a snippet.
>

That's a good idea, in retrospect Andreas did not report having this
issue.  Let me do a second in series that removes this hunk.

The second hunk resolves the undefined reference to symbol
'__gxx_personality_v0@@CXXABI_1.3 I think that change is a safe one..

Then I can do some follow up the for loop initialization
errors. Hopefully it's just not me effected by that error. I'll see
about making this a snippet as well.

Mike

bug#43306: roffit is missing a dependency

[Efraim Flashner]

On Thu, Sep 10, 2020 at 02:44:55PM +0200, raingloom wrote:
> ```
> 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.
> 

Fixed in 8aea855ac1fe05fc462206adb607d639a06b50a5

-- 
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#43232: [PATCH] gnu: jack-2: Update to 1.9.14.

[Efraim Flashner]

On Mon, Sep 14, 2020 at 09:25:25PM -0700, Mike Rosset wrote:
> * gnu/packages/audio.scm (jack-2): Update to 1.9.14.
> [arguments]: new 'declare-for-int phase after unpack that declares 'i in the
> for initialize statement.  Add -lstdc++ to LDFLAGS 'set-linkflags phase
> ensures -lstdc++ is at the tail.
> 
> This fixes issues that cause jack-2 to not build on system aarh64-linux.
> ---
>  gnu/packages/audio.scm | 14 --
>  1 file changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/gnu/packages/audio.scm b/gnu/packages/audio.scm
> index 38ee4f8bcc..83c08b718e 100644
> --- a/gnu/packages/audio.scm
> +++ b/gnu/packages/audio.scm
> @@ -2030,7 +2030,7 @@ synchronous execution of all clients, and low latency 
> operation.")
>  (define-public jack-2
>(package (inherit jack-1)
>  (name "jack2")
> -(version "1.9.13")
> +(version "1.9.14")
>  (source (origin
>   (method url-fetch)
>   (uri (string-append 
> "https://github.com/jackaudio/jack2/releases/;
> @@ -2039,7 +2039,7 @@ synchronous execution of all clients, and low latency 
> operation.")
>   (file-name (string-append name "-" version ".tar.gz"))
>   (sha256
>(base32
> -   "1d1d403jn4366mqig6g8ghr8057b3rn7gs26b5p3rkal34j20qw2"
> +   "0z11hf55a6mi8h50hfz5wry9pshlwl4mzfwgslghdh40cwv342m2"
>  (build-system waf-build-system)
>  (arguments
>   `(#:tests? #f  ; no check target
> @@ -2047,8 +2047,18 @@ synchronous execution of all clients, and low latency 
> operation.")
> "--alsa")
> #:phases
> (modify-phases %standard-phases
> + (add-after 'unpack 'declare-for-int
> +   (lambda _
> + ;; Declare the for loop i incrementer.
> + (substitute* "dbus/sigsegv.c"
> +   (("for\\(i = 0") "for(int i = 0"))
> + #t))

Any chance of an upstream bug number or something for this? It seems
like the type of thing that might be put into a snippet.

>   (add-before 'configure 'set-linkflags
> (lambda _
> + ;; Ensure -lstdc++ is the tail of LDFLAGS or the simdtests.cpp
> + ;; will not link with undefined reference to symbol
> + ;; '__gxx_personality_v0@@CXXABI_1.3'
> + (setenv "LDFLAGS" "-lstdc++")
>   ;; Add $libdir to the RUNPATH of all the binaries.
>   (substitute* "wscript"
> ((".*CFLAGS.*-Wall.*" m)
> -- 
> 2.28.0
> 
> 
> 
> 

-- 
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