bug#68333: Time bomb in icedtea/openjdk

[Julien Lepiller]

Hi Guix!

There seems to be a time bomb in icedtea@2 and openjdk@9. while
building it:

Error: time is more than 10 years from present: 138852720
java.lang.RuntimeException: time is more than 10 years from present:
138852720 at
build.tools.generatecurrencydata.GenerateCurrencyData.makeSpecialCaseEntry(GenerateCurrencyData.java:288)
at
build.tools.generatecurrencydata.GenerateCurrencyData.buildMainAndSpecialCaseTables(GenerateCurrencyData.java:227)
at
build.tools.generatecurrencydata.GenerateCurrencyData.main(GenerateCurrencyData.java:158)

I managed to work around that by setting the date back, but we should
investigate and fix it. icedtea@3 doesn't seem to be affected.

bug#39885: Bioconductor URI, fallback and time-machine

[Ricardo Wurmus]

Ludovic Courtès  writes:

>> With all these notes out of the way I’ll prepare a series of patches
>> next.
>
> I don’t think it happened but it’d still be nice.  :-)

The WIP commit is here:

https://git.savannah.gnu.org/cgit/guix.git/commit/?h=wip-r=e81a75a7b28c633a658ceeb0a728255674f56c58

-- 
Ricardo

bug#39885: Bioconductor URI, fallback and time-machine

[Ludovic Courtès]

Hi,

(Replying to a 1.5-year-old message…)

Ricardo Wurmus  skribis:

> I have finally taken the time to review this and implement a first draft
> of a change to the bioconductor importer and updater.
>
> There are some limitations:
>
> - we cannot use the updater to go from “url-fetch” to “git-fetch”.
>   That’s because “package-update” in (guix upstream) decides whether to
>   use package-update/url-fetch or package-update/git-fetch based on the
>   *current* package value’s origin fetch procedure.  For the switch we
>   can hack around this (adding an exception for bioconductor packages),
>   but there is no pretty way to do this in a generic fashion that could
>   be committed.
>
>   Perhaps we could operate on the url included in the 
>   instead of looking at the *current* package value.  We’re only
>   accessing “package” once in the url-fetch case, so maybe we can work
>   around this problem.

Alternatively, how about writing a custom one-shot tool to change the
‘source’ field of all the Bioconductor packages to ‘git-fetch’?

It may be easier than adjusting (guix upstream) to cater to this
probably unusual case.

> - the repositories at https://git.bioconductor.org/package/NAME do not
>   tag package versions.  The only method of organization is branches
>   that are named after *Bioconductor releases* (not package releases),
>   e.g. RELEASE_3_15.  We can only determine the package version by
>   reading its DESCRIPTION file or by looking up the version index for
>   all Bioconductor packages (we do that already).  This means that there
>   could be different commits for the same package version in the same
>   release branch — so we have to include the commit hash and a revision
>   counter in the version string.

OK, sounds acceptable.

> - the updater doesn’t work on version expressions like (git-version
>   "1.12" revision commit).  It expects to be able to replace literal
>   strings.  Because of that my changes let the importer generate a
>   string literal such as "1.12-0.cafebab" without a let-bound commit
>   string.

Maybe we can build upon Maxime’s patch at
?

> - “experiment” or “data” packages are not kept in Git.  They only exist
>   as volatile tarballs that will be overwritten.  Thankfully, they don’t
>   change all that often, so they have a good chance of making it into
>   our archives.
>
> - the above exception means that we need to litter the importer and
>   updater code with extra checks.
>
> With all these notes out of the way I’ll prepare a series of patches
> next.

I don’t think it happened but it’d still be nice.  :-)

Thanks,
Ludo’.

bug#39885: Bioconductor tarballs are not archived

[Ludovic Courtès]

Hi!

Simon Tournier  skribis:

>> I was wondering whether we’re now doing better for Bioconductor
>> tarballs.  The answer, based on small sample, seems to be “not quite”:

[...]

> but, now the past reads,
>
> $ for url in 
> https://bioconductor.org/packages/release/bioc/src/contrib/BiocNeighbors_1.20.0.tar.gz
>  \
>  
> https://bioconductor.org/packages/3.18/bioc/src/contrib/BiocNeighbors_1.20.0.tar.gz
>  ;  \
>   do guix download $url ;done

Thanks for investigating & explaining!

I my previous message, I wrote:

> As for past tarballs, #swh-devel comrades say we could send them a list
> of URLs and they’d create “Save Code Now” requests on our behalf (we
> cannot do it ourselves since the site doesn’t accept plain tarballs.)

Were you able to retrieve some of these?  What are the chances of
success?

> Hence the discussion we had: switch from url-fetch to git-fetch.
> However, after some investigations, it does not seem straightforward:
> The main issue being the almost automatic current updater.  See for
> details [2].

[...]

> https://issues.guix.gnu.org/msgid/878rnwuemq@elephly.net

Indeed, thanks for the link.  I agree that long-term moving to
‘git-fetch’ sounds preferable, but there are quite a few obstacles to
overcome.

Ludo’.

bug#67329: Plan9port breaks Emacs Dired

[宋文武 via Bug reports for GNU Guix]

Navajeeth  writes:

> There’s a bug with the ‘plan9port’ (p9p) package on Guix—installing it on the 
> Guix System breaks Dired inside Emacs.
> When I try to open a Dired buffer with p9p installed, I get the following 
> error:
>
>  (error "Listing directory failed but ‘access-file’ worked")
>error("Listing directory failed but `access-file' worked")
>insert-directory("/home/guix/" "--dired -lFaGh1v --group-directories-first 
> --time-..." nil t)
>dired-insert-directory("/home/guix/" "-lFaGh1v --group-directories-first 
> --time-style=lo..." nil nil t)
>dired-readin-insert()
>#()
>combine-change-calls-1(1 17349 # F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_47>)
>dired-readin()
>dired-revert(nil nil)
>revert-buffer()
>dired-internal-noselect("~/" nil)
>dired-noselect("~/" nil)
>dired("~/" nil)
>funcall-interactively(dired "~/" nil)
>command-execute(dired)
>
> p9p distributes its own version of ‘ls’, so maybe that’s interfering?
>
> The output of ‘ls’, on the command-line, with p9p installed is:
>
>~% ls --version
>usage: ls [-dlmnpqrstuFQ] [file ...]
>~% ls --help
>usage: ls [-dlmnpqrstuFQ] [file ...]
>~% ls -v
>usage: ls [-dlmnpqrstuFQ] [file ...]
>~% ls
>usage: ls [-dlmnpqrstuFQ] [file ...]

Hello, I beileve this had been fixed with commit 2538a773c, which put
p9p into $out/plan9, only '9' is available via PATH.

User can append $GUIX_PROFILE/plan9/bin into $PATH if wanted.


Close now, thanks!

bug#39885: Bioconductor tarballs are not archived

[Simon Tournier]

Hi,

On Fri, 22 Dec 2023 at 14:40, Ludovic Courtès  wrote:

>> guix build: error: build of 
>> `/gnu/store/q9ggmh5a9bzmnr49p10x1w9sv6pzjarv-BiocNeighbors_1.4.1.tar.gz.drv' 
>> failed

First thing first, please note that we are speaking about tag 1.4.1 and
not 1.20.0.  And this 1.4.1 is gone from “our” infra since… ?? That’s
one of the things I do not like with Guix: I never know what to expect
from the infra.  Anyway, I have my list of TODOs for improving the
annoyances (I and maybe others have :-)); stay tuned. ;-)

Considering the state of “our” infra and how Bioconductor manages the
tarballs, many tarballs are lost forever, sadly.  Although the content
is still around, I guess.


> I was wondering whether we’re now doing better for Bioconductor
> tarballs.  The answer, based on small sample, seems to be “not quite”:

Thanks for diving into this.


>  has entries like:
>
> --8<---cut here---start->8---
> {
>   "type": "url",
>   "urls": [
> 
> "https://bioconductor.org/packages/release/bioc/src/contrib/BiocNeighbors_1.20.0.tar.gz;,
> 
> "https://bioconductor.org/packages/3.18/bioc/src/contrib/BiocNeighbors_1.20.0.tar.gz;,
> 
> "https://bordeaux.guix.gnu.org/file/BiocNeighbors_1.20.0.tar.gz/sha256/0a5wg099fgwjbzd6r3mr4l02rcmjqlkdcz1w97qzwx1mir41fmas;,
> 
> "https://ci.guix.gnu.org/file/BiocNeighbors_1.20.0.tar.gz/sha256/0a5wg099fgwjbzd6r3mr4l02rcmjqlkdcz1w97qzwx1mir41fmas;,
> 
> "https://tarballs.nixos.org/sha256/0a5wg099fgwjbzd6r3mr4l02rcmjqlkdcz1w97qzwx1mir41fmas;
>   ],
>   "integrity": "sha256-WlUXSI41dP7xSTx81ibFsrIsACW5jmzaX5I/lxJ4vCg=",
>   "outputHashAlgo": "sha256",
>   "outputHashMode": "flat"
> },
> --8<---cut here---end--->8---

Please note that Bioconductor 3.18 released BiocNeighbors v1.20.0 but
then updated to v1.20.1 still under Bioconductor 3.18 and Ricardo did
this update with 5673484cbc2ed74c61ae81d623646fa7829fbc32.  On a side
note, between the Bioconductor update and the update on our side, there
is a mismatch where the source of r-biocneighbors is unreachable.

Other said, post-update on our side,

--8<---cut here---start->8---
$ zcat sources.json | jq | grep BiocNeighbors | grep bioconductor | sed 
's/"//g' | sed 's/,//g'

https://bioconductor.org/packages/release/bioc/src/contrib/BiocNeighbors_1.20.1.tar.gz

https://bioconductor.org/packages/3.18/bioc/src/contrib/BiocNeighbors_1.20.1.tar.gz

$ for url in $(zcat sources.json | jq | grep BiocNeighbors | grep bioconductor 
| sed 's/"//g' | sed 's/,//g'); \
 do guix download $url ;done

Starting download of /tmp/guix-file.STc9fQ
>From 
>https://bioconductor.org/packages/release/bioc/src/contrib/BiocNeighbors_1.20.1.tar.gz...
 …_1.20.1.tar.gz  1015KiB   
  60.3MiB/s 00:00 ▕██▏ 100.0%
/gnu/store/nxab1pskh9zcjspczph6jcs5fk79pb7k-BiocNeighbors_1.20.1.tar.gz
0w7hd6w0lmj1jaaq9zd5gwnnpkzcr0byqm5q584wjg4xgvsb981j

Starting download of /tmp/guix-file.aZFRLv
>From 
>https://bioconductor.org/packages/3.18/bioc/src/contrib/BiocNeighbors_1.20.1.tar.gz...
 …_1.20.1.tar.gz  1015KiB   
  63.5MiB/s 00:00 ▕██▏ 100.0%
/gnu/store/nxab1pskh9zcjspczph6jcs5fk79pb7k-BiocNeighbors_1.20.1.tar.gz
0w7hd6w0lmj1jaaq9zd5gwnnpkzcr0byqm5q584wjg4xgvsb981j
--8<---cut here---end--->8---

but, now the past reads,

--8<---cut here---start->8---
$ for url in 
https://bioconductor.org/packages/release/bioc/src/contrib/BiocNeighbors_1.20.0.tar.gz
 \
 
https://bioconductor.org/packages/3.18/bioc/src/contrib/BiocNeighbors_1.20.0.tar.gz
 ;  \
  do guix download $url ;done

> > 
Starting download of /tmp/guix-file.MUB3ow
>From 
>https://bioconductor.org/packages/release/bioc/src/contrib/BiocNeighbors_1.20.0.tar.gz...
download failed 
"https://bioconductor.org/packages/release/bioc/src/contrib/BiocNeighbors_1.20.0.tar.gz;
 404 "Not Found"

Starting download of /tmp/guix-file.MUB3ow
>From 
>https://web.archive.org/web/20240102105016/https://bioconductor.org/packages/release/bioc/src/contrib/BiocNeighbors_1.20.0.tar.gz...
download failed 
"https://web.archive.org/web/20240102105016/https://bioconductor.org/packages/release/bioc/src/contrib/BiocNeighbors_1.20.0.tar.gz;
 404 "NOT FOUND"
Trying to use Disarchive to assemble /tmp/guix-file.MUB3ow...
could not find its Disarchive specification
failed to download "/tmp/guix-file.MUB3ow" from 
"https://bioconductor.org/packages/release/bioc/src/contrib/BiocNeighbors_1.20.0.tar.gz;
guix download: error: 
https://bioconductor.org/packages/release/bioc/src/contrib/BiocNeighbors_1.20.0.tar.gz:
 download failed

Starting download 

bug#64360: error: ghc-onetuple: unbound variable

[Simon Tournier]

Hi,

On Wed, 20 Dec 2023 at 11:56, Csepp  wrote:

>>> In guix/packages.scm:
>>>   1371:17 17 (supported-package? # …)
>>> In guix/memoization.scm:
>>> 101:0 16 (_ # # …)
>>> In guix/packages.scm:
>>>   1349:39 15 (_)
>>>   1611:16 14 (package->bag _ _ _ #:graft? _)
>>>   1715:47 13 (thunk)
>>> In gnu/packages/video.scm:
>>>   2615:11 12 (native-inputs #)
>>> In guix/packages.scm:
>>>   1371:17 11 (supported-package? # …)
>>> In guix/memoization.scm:
>>> 101:0 10 (_ # # …)
>>> In guix/packages.scm:
>>>   1349:39  9 (_)
>>>   1611:16  8 (package->bag _ _ _ #:graft? _)
>>>   1712:48  7 (thunk)
>>> In gnu/packages/haskell-xyz.scm:
>>>   9121:35  6 (inputs #)
>>> In guix/packages.scm:
>>>   1424:32  5 (package-closure _ #:system _)
>>>   1611:16  4 (package->bag _ _ _ #:graft? _)
>>>   1712:48  3 (thunk)
>>> In gnu/packages/haskell-web.scm:
>>>943:18  2 (inputs #)
>>> In ice-9/boot-9.scm:
>>>   1685:16  1 (raise-exception _ #:continuable? _)
>>>   1685:16  0 (raise-exception _ #:continuable? _)
>>>
>>> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
>>> error: ghc-onetuple: unbound variable

[...]

>222:29 12 (map1 _)
>222:17 11 (map1 (((gnu packages tex)) ((gnu packages xml)) ((…)) …))
>   3327:17 10 (resolve-interface (gnu packages tex) #:select _ #:hide …)
> In ice-9/threads.scm:
> 390:8  9 (_ _)
> In ice-9/boot-9.scm:
>   3253:13  8 (_)
> In ice-9/threads.scm:
> 390:8  7 (_ _)
> In ice-9/boot-9.scm:
>   3544:20  6 (_)
>2836:4  5 (save-module-excursion _)
>   3564:26  4 (_)
> In unknown file:
>3 (primitive-load-path "gnu/packages/tex" #)
> In gnu/packages/tex.scm:
> GC Warning: Failed to expand heap by 8388608 bytes
> ...repeats a bunch of times...
> GC Warning: Failed to expand heap by 8388608 bytes
> GC Warning: Failed to expand heap by 65536 bytes
> GC Warning: Out of Memory! Heap size: 2498 MiB. Returning NULL!
> Exception thrown while printing backtrace:
> Out of memory
>
> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> error: license:arphic-1999: unbound variable

Could you please do not mix all the bugs you are hitting?  The initial
report is about ghc-onetuple.  The error message says:

error: ghc-onetuple: unbound variable

and as explained in [1], this error does not come from the ’guix’
channel but by one of the others you are also pulling.  Could you
confirm that?


Next, I am not able to reproduce the initial failure about yt-dlp and
instead I hit a failure about:

--8<---cut here---start->8---
$ guix time-machine --commit=63660f0febb \
   -- shell --rebuild-cache -s i686-linux yt-dlp \
   -- yt-dlp --version

[...]

starting phase `check'
running "runhaskell Setup.hs" with command "test" and parameters ()
Running 1 test suites...
Test suite tasty: RUNNING...

Test suite tasty: FAIL
Test suite logged to: dist/test/base64-0.4.2.4-tasty.log
0 of 1 test suites (0 of 1 test cases) passed.
error: in phase 'check': uncaught exception:
%exception #< program: "runhaskell" arguments: 
("-package-db=/tmp/guix-build-ghc-base64-0.4.2.4.drv-0/package.conf.d" 
"Setup.hs" "test") exit-status: 1 term-signal: #f stop-signal: #f> 
phase `check' failed after 0.3 seconds
command "runhaskell" 
"-package-db=/tmp/guix-build-ghc-base64-0.4.2.4.drv-0/package.conf.d" 
"Setup.hs" "test" failed with status 1
builder for 
`/gnu/store/n2yl83p37j9mazjh58d5fxixjiq188px-ghc-base64-0.4.2.4.drv' failed 
with exit code 1
build of /gnu/store/n2yl83p37j9mazjh58d5fxixjiq188px-ghc-base64-0.4.2.4.drv 
failed
--8<---cut here---end--->8---

as reported in [1].  Could you confirm that failure?  And thus the
failure of pandoc for i686 architecture?

Cheers,
simon

1: bug#64360: error: ghc-onetuple: unbound variable
Simon Tournier 
Fri, 24 Nov 2023 15:43:26 +0100
id:87zfz3ciup@gmail.com
https://issues.guix.gnu.org/64360
https://issues.guix.gnu.org/msgid/87zfz3ciup@gmail.com
https://yhetil.org/guix/87zfz3ciup@gmail.com

bug#39885: Bioconductor URI, fallback and time-machine

[Simon Tournier]

Hi Ludo,

On Fri, 22 Dec 2023 at 21:57, Ludovic Courtès  wrote:

> In hindsight this is not surprising: this is a Dec. 2019 commit and I
> set up ,
> disarchive.guix.gnu.org, and related machinery in Sep/Oct 2021.
>
> Of course Timothy set up  earlier, but not
> so much—Timothy started work on Disarchive ca. July 2020:
> .
>
> (Not that it helps but at least it’s a relief to know that this
> particular problem predates our more serious efforts.)

Yeah!  On the other hand, I wish that Guix will be able to build all –
or at least most of – the packages that time-machine is able to reach –
say Guix v1.0. :-)  Let be ambitious. ;-)

Cheers,
simon