Re: Synchronizing the Disarchive databases

[zimoun]

Hi Timothy,

On Tue, 04 Oct 2022 at 12:22, Ludovic Courtès  wrote:

> How could we copy the contents of disarchive.ngyro.com to Guix infra?

A friendly ping. :-)


Cheers,
simon

Reproducible Builds Summit 2022

[Efraim Flashner]

Chris and I are here at the reproducible builds summit in Venice, we're
winding down now but it's been a great time meeting everyone and
planning out upcoming tasks.

The good news is Guix is Great! We have our tightly controlled
dependency chain which makes it really easy to know exactly which inputs
were present during a build and how to rebuild a package to check for
reproducibility. We have Guix challenge to easily challenge the build
farms to see if locally available packages are reproducible against the
ones built on the build farms.

I'm going to link to Vagrant's email^1 from back in June where they
talked about some of the unreproducibility issues in Guix. We know the
issues are there, so it would be good for us to go ahead and fix them.
They might not all be low hanging fruit, but we do want to make sure
that our builds continue to be reproducible.

Moving forward, it would be nice to test for reproducibility in
qa.guix.gnu.org. It should be possible to build packages more than once
and to compare the results of the two to check for reproducibility.
qa.guix.gnu.org already shows which packages in patches build for each
architecture, being able to check for reproducibility also would be a
good next step.  We should also continue working on implementing a
change in the ACL to allow requiring a K of N agreement between
different substitute servers that a build is correct^2. If someone is
downloading substitutes I'm sure they would be happier to know that the
two build farms (or more if you have access to more build farms!) agree
to the hash of the packages.

Other ideas moving forward is the ability to sign a narinfo with more
than one key. Then in theory these multisigned narinfo files could be
distributed and one could trust it without putting undue load on the
substitute servers. This would also be helpful if there are network
problems but we want to have that not affect the distribution of nars.

^1 https://lists.gnu.org/archive/html/guix-devel/2022-06/msg00191.html
^2 https://lists.gnu.org/archive/html/guix-devel/2020-06/msg00179.html

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

Re: Release progress, week 3

[Ludovic Courtès]

Hi,

Vagrant Cascadian  skribis:

>>> test-name: channel-news, no news
>>> ...
>>> actual-error:
>>> + (git-error
>>> +   #< code: -1 message: "invalid version 0 on 
>>> git_proxy_options" class: 3>)
>>> result: FAIL
>>
>> This looks like an ABI issue with libgit2.  Are you sure the same
>> version of libgit2 is used on all these platforms?
>
> My quick and rough archeaology shows that libgit2-dev
> 1.1.0+dfsg.1-4.1+b1 was used to build guile-git 0.5.2-4, but the current
> libgit2-dev package in Debian is 1.5.0+ds-6 ... so that seems plausible.

[...]

> Maybe there is a better way I can track the various guile-* packages in
> Debian, but manually tracking all the relevent dependents seems
> implausible (or at least, a lot of work)... which may lead to the
> conclusion that maintaining Guix in Debian implausible. :/

I don’t see how that’s specific to guile-* packages though.  Anytime a
dependency is upgraded that introduces a different ABI, you need to
rebuild dependents, right?  That’s what’s happening here.

> Seems like the most likely ones I would have to keep a close eye on are
> guile-gcrypt, guile-git, guile-gnutls (although currently part of gnutls
> this will likely change soonish), guile-lzlib, guile-ssh, guile-sqlite3,
> guile-zlib, guile-zstd. And there's also keeping an eye on guile itself,
> which adds another set of packages. Wheee. Hrm.

Heh.  Speaking of which, guile-gnutls is now a thing of its own,
separate from GnuTLS:

  https://gitlab.com/gnutls/guile/

I believe Andreas Metzler already update Debian’s guile-gnutls package
accordingly.

Thanks,
Ludo’.

Re: Antioxidant (new rust build system) update - 100% builds

[Ludovic Courtès]

Hi,

Maxime Devos  skribis:

> On 02-11-2022 12:20, Ludovic Courtès wrote:
>> [. ..]
>> That’s  but it probably needs work if
>> we want it to work reliably on all the packages.  My understanding is
>> that we’d need a “flag day” where we’d switch all Rust packages to
>> Antioxydant in one commit, is that correct?  Any ideas how to achieve
>> the big migration?
>
> That's the idea I think, yes.  For this big migration, I propose to
> make the "guix style" good enough to do the switch at once (and let
> ci.guix.gnu.org build it etc. before merging).

OK, makes sense.

> On how to achieve this: the basic antioxidation (e.g. move
> #:cargo-inputs to inputs) is currently fully automated (*).  Then
> there is stuff like 'add this-input to that-package', which is
> 'half-automated', in the sense that there are a bunch of declarative
> alists for that, interpreted automatically but declared manually;
> those could be interpreted by "guix style" as well.

Perhaps we could temporarily support the “old style”, using the run-time
transformation currently in your repo?  That would allow third-party
channels to migrate peacefully, and it would also reduce the likely hood
of breakage during transition in Guix (e.g., if an old-style package is
merged while the new branch is being built.)

Anyway, please do ping people here when specific action is needed from
the rest of us!

Thanks,
Ludo’.

Re: guix lint false positives and RFC patch

[Ludovic Courtès]

Vagrant Cascadian  skribis:

> --- a/guix/lint.scm
> +++ b/guix/lint.scm
> @@ -313,7 +313,8 @@ (define (tests-explicitly-enabled?)
>'()))
>  
>  (define (properly-starts-sentence? s)
> -  (string-match "^[(\"'`[:upper:][:digit:]]" s))
> +  (string-match "^[(\"'`[:upper:][:digit:]]"
> +(string-replace-substring s "@code{" "")))

An identifier in @code or file name in @file may legitimately start with
a lower-case letter so I don’t think we should try to prevent that.

However, maybe we could change the regexp above to something that
accepts @ or some other non-letter character at the start?

Ludo’.

Re: Reproducible Builds Summit 2022

[Ludovic Courtès]

Hello!

Efraim Flashner  skribis:

> Chris and I are here at the reproducible builds summit in Venice, we're
> winding down now but it's been a great time meeting everyone and
> planning out upcoming tasks.

Thanks for the report!  I have fond memories of previous editions of the
summit, I hope this was as pleasant as in previous years.

There are well-identified things we can do to move forward, let’s hope
we get there by the next summit.  :-)

Ludo’.

Release progress, week 4

[Ludovic Courtès]

Hello Guix!

Release progress: week 4.

  • ‘make assert-binaries-available’ reports 92.7% coverage (details
below).  We’re not making much progress.

  • Architectures:

 - i586-gnu: Chris and I fixed core packages (test failures;
   bordeaux.guix is building them and I’ll enable it on ci.guix real
   soon now.

 - armhf-linux: No progress so far.  Chris rightfully points out
   that bordeaux.guix has 100% coverage for these core substitutes.
   Can we arrange so that ci.guix at least builds these core subset
   of packages?

 - aarch64-linux: Rust is now available.  Other than that, similar
   situation: a few substitutes for these core packages are still
   missing on ci.guix (they are on bordeaux.guix) for unclear
   infrastructure reasons.

 - powerpc64le-linux: Only Emacs and Vim are reported as missing on
   ci.guix by ‘make assert-binaries-available’.

  • Installer:

 - Core dumps can now be sent upon crashes:
   .

 - ‘read-partition-uuid’ is called until it succeeds, fixing
   .

 - Guile-Parted crash is being investigated:
   .

 - I’m working on a patch similar to
    to report about unsupported
   devices.

  • Release issue  blocked by 6 open
bugs, down from 9.  Some issues that are still opened are no longer
considered blocking.

  • Others:

 - Shepherd memory leak still being investigated, with ramifications
   in Fibers and probably in Guile proper:
   .

 - Vagrant updated the ‘guix’ package in Debian:
   

Ludo’.

Week 3: https://lists.gnu.org/archive/html/guix-devel/2022-10/msg00293.html
Week 2: https://lists.gnu.org/archive/html/guix-devel/2022-10/msg00210.html
Week 1: https://lists.gnu.org/archive/html/guix-devel/2022-10/msg00137.html

computing 400 package derivations for x86_64-linux...
looking for 507 store items on https://ci.guix.gnu.org...
https://ci.guix.gnu.org ☀
  92.7% substitutes available (470 out of 507)
  at least 4,252.6 MiB of nars (compressed)
  6,657.5 MiB on disk (uncompressed)
  0.016 seconds per request (1.8 seconds in total)
  61.0 requests per second

  0.0% (0 out of 37) of the missing items are queued
  at least 1,000 queued builds
  powerpc64le-linux: 88 (8.8%)
  aarch64-linux: 405 (40.5%)
  x86_64-linux: 369 (36.9%)
  i686-linux: 138 (13.8%)
  build rate: 251.68 builds per hour
  powerpc64le-linux: 108.39 builds per hour
  x86_64-linux: 72.28 builds per hour
  i686-linux: 92.62 builds per hour

Substitutes are missing for the following items:
  /gnu/store/yxn8sqvp6jqw9wznr8qhi4fdskj35icc-linux-libre-6.0.6 
  i686-linux
  /gnu/store/885iln2zpcxqvbr35d54bqhzs7l9djmq-libreoffice-7.3.5.2   
  i686-linux
  /gnu/store/293s4skwr9n7lrg02zlzshd75w2lxnxx-mate-1.24.1   
  i686-linux
  /gnu/store/v5qp1pzb2m6j3fd92gzzxcmgadg3hfz4-xz-5.2.5  
  i586-gnu
  /gnu/store/y31ay7pcbd2w1qh4wgbgwzhp5m2x9z5c-xz-5.2.5-static   
  i586-gnu
  /gnu/store/s4z0ly9cs082i49iykn9rf0ppq8rpkbs-tar-1.34  
  i586-gnu
  /gnu/store/c1id7w3kalxq3cj8sd0pnsv7r3qn3ihf-gcc-toolchain-12.2.0-debug
  i586-gnu
  /gnu/store/gppcg4vz1wv6z0wqrqxp7s7l5prdf20l-gcc-toolchain-12.2.0  
  i586-gnu
  /gnu/store/83fgwws1cy5rgi48h285yazxzz0wsbar-gcc-toolchain-12.2.0-static   
  i586-gnu
  /gnu/store/n94fq1ilqmfg304b2sqmpdnkxfqwiqn1-make-4.3-debug
  i586-gnu
  /gnu/store/5l4i1hkl7s4d8vzy09ld1yg26qhv6039-make-4.3  
  i586-gnu
  /gnu/store/z8k8mm9pg1jajslcji2793q8b6wgl4nc-gawk-5.1.0
  i586-gnu
  /gnu/store/yr8pmis073qg3vk2f0dg5g6f8mk0vhak-findutils-4.8.0   
  i586-gnu
  /gnu/store/5cyfkp6293523q1mjp7wib7hbnxji0b1-grep-3.6  
  i586-gnu
  /gnu/store/nn3y9cs6fsyhj9z8psxp1ijvsfq1h3k0-coreutils-8.32-debug  
  i586-gnu
  /gnu/store/n8x5p6yjims31mgkdrrklxi40ypcb757-coreutils-8.32
  i586-gnu
  /gnu/store/nz1rw5cfrh4z3bl7fm2qsvxxpl955cqh-guile-3.0.8-debug 
  armhf-linux
  /gnu/store/zmk1kmfk7wxm5w3ambajgnx7b0s5iq84-guile-3.0.8   
  armhf-linux
  /gnu/store/26yb2pj71wg9cywmhpmsf6n1d81i43c5-python-3.9.9-idle 
  armhf

Permanent URL for GUIX packages

[Development of GNU Guix and the GNU System distribution.]

Hello,

I'd like to link guix.gnu.org/packages/monolith-2.6.1/ from my project's 
README file (https://github.com/Y2Z/monolith), but due to the version string 
being part of the URL, I can't easily do that, would have to change the link 
for every new release.

Could you please let me know how to permanently link to a specific package on 
that website from somewhere else?  If it's currently not possible, could you 
please mention this issue to someone who could potentially add this enhancement 
to the website, or point me in the right direction as who to talk to?

Thank you.

Best,
Sunshine

Re: splitting up and sorting commits?

[Liliana Marie Prikler]

Am Mittwoch, dem 02.11.2022 um 00:05 + schrieb Csepp:
> Hey all!
> 
> I'm working on a fairly sizeable MirageOS branch, just getting the
> hello-world kernel running involved adding about 40 packages.  Very
> often I run into a scenario where an imported package needs some
> other package to compile, and then that needs another, and then that
> another, and so on and so on, so by the time I can commit the first I
> have a plethora of new packages that should in theory all get their
> own commits.
> There are two problems with this:
> * Splitting up the commit is a pain, even with git add --patch,
> because hand editing the diff sucks and splitting does not work,
> possibly due to there not being enough space between defines for
> git's taste.
> * It is very easy for package to get added before their dependencies,
> so even though by the end of the commit chain everything builds
> perfectly fine, there are intermediate commits that can't be tested
> on their own.
> 
> How should one solve this?  I already spent way too much time on a
> script that I foolishly thought would be able to automatically sort
> commits based on their dependencies, but now I'm throwing in the
> towel, it's not getting anywhere.
zimoun mentioned etc/committer.scm, which is nice if it works for you,
but perhaps doesn't fully answer your question.  The pauper's solution
would be to keep a separate "scratch pad" file containing a bunch of
assorted guix packages, ordered in a way that all packages are defined
before they're used as inputs – you can easily maintain this order by
insertion sort.  Then, once the big package finally builds and you're
content with it, you can copy the definitions to the correct file(s) in
the guix tree one by one.

Cheers

Re: guix lint false positives and RFC patch

[Vagrant Cascadian]

On 2022-11-03, Ludovic Courtès wrote:
> Vagrant Cascadian  skribis:
>
>> --- a/guix/lint.scm
>> +++ b/guix/lint.scm
>> @@ -313,7 +313,8 @@ (define (tests-explicitly-enabled?)
>>'()))
>>  
>>  (define (properly-starts-sentence? s)
>> -  (string-match "^[(\"'`[:upper:][:digit:]]" s))
>> +  (string-match "^[(\"'`[:upper:][:digit:]]"
>> +(string-replace-substring s "@code{" "")))
>
> An identifier in @code or file name in @file may legitimately start with
> a lower-case letter so I don’t think we should try to prevent that.
>
> However, maybe we could change the regexp above to something that
> accepts @ or some other non-letter character at the start?

Great suggestion, as it is simpler, easier to read, and actually covers
more false positives! Updated patch attached!

I think there was only one case fixed by the @code{} check for the
synopsis length check, and I don't see any obvious other @*{} checks
that would currently improve anything, though it would be ideal to make
it more future-proof just in case... though I think my attempt at that
would be awfully ugly, help from others would be welcome!

That said, I think this resolves 52 false positives with guix lint (~10%
of the 536 synopsis/description issues currently).


live well,
  vagrant
From d4ddd4a90f18666352b07a4ebe0ed6b79c74f21e Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Wed, 2 Nov 2022 19:56:12 -0700
Subject: [PATCH] guix: lint: Exclude some "@" symbols from various checks.

The visual representation of "@code{}" or similar in the description and
synopsis do not include the string, so exclude it from checks to avoid false
positives.

FIXME handle @command, @file, @acronym, etc.

* guix/linx.scm (properly-starts-sentence): Exclude leading "@".
  (check-synopsis-length): Exclude "@code{".
---
 guix/lint.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/guix/lint.scm b/guix/lint.scm
index 8e3976171f..26d8f59a2c 100644
--- a/guix/lint.scm
+++ b/guix/lint.scm
@@ -313,7 +313,7 @@ (define (tests-explicitly-enabled?)
   '()))
 
 (define (properly-starts-sentence? s)
-  (string-match "^[(\"'`[:upper:][:digit:]]" s))
+  (string-match "^[@(\"'`[:upper:][:digit:]]" s))
 
 (define (starts-with-abbreviation? s)
   "Return #t if S starts with what looks like an abbreviation or acronym."
@@ -650,7 +650,7 @@ (define check-start-article
   '()
 
   (define (check-synopsis-length synopsis)
-(if (>= (string-length synopsis) 80)
+(if (>= (string-length (string-replace-substring synopsis "@code{" "")) 80)
 (list
  (make-warning package
(G_ "synopsis should be less than 80 characters long")
-- 
2.35.1



signature.asc
Description: PGP signature

guix bisect

[jgart]

hi,

do we have something similar to nix-bisect but for guix?

* https://github.com/timokau/nix-bisect

CLI flag to ignore guix channel

[jgart]

Hi,

I'd like a CLI flag to be able to ignore channels.

Where should I look if I'd like to implement something like this?

I prefer not to edit and comment out channels in ~/.config/guix/channels.scm

I'd prefer to do the following

guix import crate behemoth-rust-package-foo -r --ignore-channel=guixrus

WDYT