Hi.
On Sun, 06 Oct 2024 at 17:15, not emma via Bug reports for GNU Guix
wrote:
> hi, thank you for getting back on this. it likely is related to the
> upstream issue, and i'd be good on closing this out
Since the bug seems coming from upstream, I would be tempted to close
the one here. Or wha
gt; > it seems like lsof is failing the check phase after running guix pull
> > earlier today, leaving me unable to update either the system
> > or home profile. the following output was from the logs:
> >
> > phase `build' succeeded after 1.9 seconds starting p
not emma via Bug reports for GNU Guix writes:
> it seems like lsof is failing the check phase after running guix pull
> earlier today, leaving me unable to update either the system
> or home profile. the following output was from the logs:
>
> phase `build' succeed
i believe this has to do with the updates pushed a couple of hours ago.
reverting to commit eff3ff9878c7225351650bf967c9a8de3869e919 resolves the issue.
Sent with [Proton Mail](https://proton.me/mail/home) secure email.
it seems like lsof is failing the check phase after running guix pull earlier
today, leaving me unable to update either the system or home profile. the
following output was from the logs:
phase `build' succeeded after 1.9 seconds
starting phase `check'
make lib/dialects/linux/tests
Hello,
Maxim Cournoyer writes:
> Hello again,
>
> Mark, I've figured it out and disabled it locally. Will push shortly to
> core-updates-frozen.
core-updates-frozen was merged into master long ago :-)
Closing.
Maxim
Hi Maxim,
Maxim Cournoyer writes:
> For the record it seems Tobias had gotten around filing a bug here:
> https://github.com/lsof-org/lsof/issues/152.
>
> It seems the issue is real and a new Linux-specific tool lsfd is being
> devised. I guess we should disable the test, as
Hello,
For the record it seems Tobias had gotten around filing a bug here:
https://github.com/lsof-org/lsof/issues/152.
It seems the issue is real and a new Linux-specific tool lsfd is being
devised. I guess we should disable the test, as the package is still
probably mostly functional on Btrfs
Hello again,
Mark, I've figured it out and disabled it locally. Will push shortly to
core-updates-frozen.
Thanks!
Maxim
On Sun, 29 Nov 2020 20:30:20 -0500
Mark H Weaver wrote:
> Hi Tobias,
>
> Thanks for the super quick response and for reproducing the bug.
>
> > This looks like an upstream bug to me.
>
> Agreed.
>
> > Do you have time to file
> > one? We're
Hi Tobias,
Thanks for the super quick response and for reproducing the bug.
> This looks like an upstream bug to me.
Agreed.
> Do you have time to file
> one? We're using the <https://github.com/lsof-org/lsof> upstream
> since Victor Abell retired.
I have time, but
Mark,
Mark H Weaver 写道：
In the 'lsof' test suite, the 'LTlock' test consistently fails
on my
system, possibly related to the fact that I use 'btrfs' for my
local
filesystems.
Thanks for the report! I can reproduce this by formatting a btrfs
image file and lo
I should mention that 'gnome' depends on 'lsof' via the following
dependency path (among others):
gnome -> gnome-shell -> ruby-sass -> ruby-sass-spec -> ruby-terminfo ->
ruby-rdoc -> ruby-rubocop -> ruby-parallel -> lsof
Mark
In the 'lsof' test suite, the 'LTlock' test consistently fails on my
system, possibly related to the fact that I use 'btrfs' for my local
filesystems. Here's the relevant build log excerpt:
--8<---cut here---start->
Am Sonntag, 3. März 2013 schrieb Ludovic Courtès:
> Andreas Enge skribis:
> > the lsof tarball contains the source in a two-stage process: After
> > unpacking, one is left with lsof_4.87_src.tar, which needs to be
> > unpacked as well.
> Weird.
I have seen it before,
Hi!
Andreas Enge skribis:
> the lsof tarball contains the source in a two-stage process: After
> unpacking, one is left with lsof_4.87_src.tar, which needs to be unpacked
> as well.
Weird.
> I tried the following:
>
>(arguments
> `(#:phases
> (alist-
Hello,
the lsof tarball contains the source in a two-stage process: After
unpacking, one is left with lsof_4.87_src.tar, which needs to be unpacked
as well. I tried the following:
(arguments
`(#:phases
(alist-replace
'unpack
(lambda* (#:key source name ve
17 matches
Mail list logo
