bug#63427:

[Sharlatan Hellseher]

Hi,

How to reproduce the issue? May you, please provide some steps please.

-- 
… наш разум - превосходная объяснительная машина которая способна
найти смысл почти в чем угодно, истолковать любой феномен, но
совершенно не в состоянии принять мысль о непредсказуемости.

bug#60657: Rethinking how service extensions work

[Liliana Marie Prikler]

Am Dienstag, dem 09.05.2023 um 20:12 +0100 schrieb Bruno Victal:
> Hi Ludo’,
> 
> On 2023-02-25 17:46, Ludovic Courtès wrote:
> > Bruno Victal  skribis:
> > > In [1], the issue arises from using activation-service-type to
> > > create files/directories for services
> > > when these should be either (1) shepherd one-shot services or
> > > moved into the 'start' procedure of the service.
> > > 'activation-service-type' should only be used for doing things
> > > "listed on its label", that is, performing
> > > actions at boot-time or after a system reconfigure.
> > 
> > Right.
> > 
> > As we once discussed on IRC, the conclusion to me is that some of
> > the
> > code currently implemented as activation snippets should rather be
> > implemented either as part of the ‘start’ method of the
> > corresponding
> > Shepherd service, or as a one-shot Shepherd service that the main
> > service would depend on.
> 
> I think moving them into the ‘start’ method is the best course of
> action.
> I'm considering the following changes:
> * Adding (gnu build activation) to %default-imported-modules +
> %default-modules in (gnu services shepherd).
>   I expect that mkdir-p/perms is going to be used frequently enough,
> using the number of activation-service
>   extensions in use as a rough estimate.
> * Refactor the activation extensions into the ‘start’ method, where
> it makes sense to do so.
> 
> 
> There's one issue I'm somewhat concerned about, consider the
> following snippet:
> 
> --8<---cut here---start->8---
> 
> (define log-directory "/var/log")
> (define username "notroot")
> 
> (start
>  #~(lambda _
>     (mkdir-p/perms #$log-directory (getpw #$username) #o750)
>     ...))
> 
> --8<---cut here---end--->8---
> 
> This is somewhat pitfall prone since you most likely don't want to
> chown /var/log to a non-root user.
> I'm unsure what's the best course to take here, would a simple file-
> exist? check before mkdir-p/perms be sufficient?
I think this question highlights perfectly why one-shot services (or
perhaps an as-of yet unknown type of services) are the way to go: With
clearly named services for the creation of directories, you don't need
to worry about creating some file with the wrong permissions as the
owner is already predetermined.  You also don't need mkdir-p; you
simply depend on the mkdir-#$(dirname my-directory) service.


Cheers

bug#63426: hikari 2.3.3 build failure

[Josselin Poiret via Bug reports for GNU Guix]

Hi,

"bdju" via Bug reports for GNU Guix  writes:

> guix (GNU Guix) e0c35d1578c10a8fe27c8372f3a8bb5dd88b01b8
> guix system
> hikari build log attached

I tried to look into it before the core-updates merge, but it seems that
hikari is not maintained anymore, so I don't expect it to work with
newer wlroots.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#63427: gdk-pixbuf unable to recognize image formats (JPG, PNG, etc.)

[Nathan Dehnel]

Gtk:ERROR:gtkiconhelper.c:494:
ensure_surface_for_gicon: assertion
failed (error == NULL): Failed to load
/run/current-system/profile/share/icons/Adwaita/16x16/status/image-missing.png:
Unrecognized image file format (gdk-pixbuf-error-quark, 3)
Bail out! Gtk:ERROR:gtkiconhelper.c:494:ensure_surface_for_gicon:
assertion failed (error == NULL): Failed to load
/run/current-system/profile/share/icons/Adwaita/16x16/status/image-missing.png:
Unrecognized image file format (gdk-pixbuf-error-quark, 3)

This is breaking various apps like viewnior, xfce4-power-manager,
causing firefox to crash when opening the file picker, making app
icons not appear, etc.

guix version b7e7744

bug#63414: Evaluation comparison on cuirass

[Josselin Poiret via Bug reports for GNU Guix]

Hi Andreas,

Andreas Enge  writes:

> When working on a branch and deciding whether to merge it, we need a way
> of comparing its status with that of the master branch. As far as I can see,
> there is currently no way in cuirass to compare arbitrary evaluations and
> get a list (or a dashboard) of builds that fail in one, but not the other.
>
> Andreas

I guess that this is one of the features that the Build Coordinator was
built for (and it is pretty damn good at this).  Maybe we could start
considering whether it makes sense to duplicate effort on Cuirass and
the Build Coordinator?  I don't know how "production-ready" the build
coordinator is, compared to Cuirass?  Maybe we could target getting the
Build Coordinator up to feature parity with Cuirass so that it may be
used on a wider scale?  If this is something we want to focus on, we
could create a team around it and set clear goals, which would probably
lessen the burden that's on Chris currently.

I understand that Cuirass is general enough to support much more than
Guix, but the coordinator is a wonderful piece of software and our
workflows might be outgrowing it.

WDYT?

-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#63426: hikari 2.3.3 build failure

[bdju]

guix (GNU Guix) e0c35d1578c10a8fe27c8372f3a8bb5dd88b01b8
guix system
hikari build log attached

WARNING: (guile-user): imported module (guix build utils) overrides core 
binding `delete'
starting phase `set-SOURCE-DATE-EPOCH'
phase `set-SOURCE-DATE-EPOCH' succeeded after 0.0 seconds
starting phase `set-paths'
environment variable `PATH' set to 
`/gnu/store/8i3vhqgjsyy6s24szarpavbp7a5237q3-bmake-20230321/bin:/gnu/store/jz5dwdxq4di29cd0rjjzkw356dhkzjil-pkg-config-0.29.2/bin:/gnu/store/gg3kycn5wfjwskx3xfkk1qscjgsvaxcn-cairo-1.16.0/bin:/gnu/store/1z04k5w139770a8blvq1a2i7fpbjr19s-libinput-minimal-1.22.1/bin:/gnu/store/53wla2a7bzcammq26qr8yi8gz7399v9r-libxkbcommon-1.4.1/bin:/gnu/store/65f0cdmsv7qqrc01hjvriwhlrimn4kxv-linux-pam-1.5.2/sbin:/gnu/store/rr1vbf04j27z5465wsm1kdfaw3iriz2k-pango-1.50.10/bin:/gnu/store/a3flz4vpqgnjxc6jv0cjv6f7qdbg4igz-wayland-1.22.0/bin:/gnu/store/sxx22f98vfbavcqmdksm6as8fvskpxiw-tar-1.34/bin:/gnu/store/x24bm49ag5dvki72mjdz195bfb89nrnb-gzip-1.12/bin:/gnu/store/j8wlfmlmfvpbza6is9wv9xsd8psrxn00-bzip2-1.0.8/bin:/gnu/store/gr0sy0m1mv36qv54idm6cn10l3mngshq-file-5.44/bin:/gnu/store/zmcf5kpqiighkbh7wslf91qdjwj06yr1-diffutils-3.8/bin:/gnu/store/210yfax18r2g2inxrml9435ikhfcca6m-patch-2.7.6/bin:/gnu/store/c8jyph2lxw0m9na34fg8h70n4nnnz7is-findutils-4.9.0/bin:/gnu/store/hc05d76f1j3iz3v2bs5jz4fpljl1r4dj-gawk-5.2.1/bin:/gnu/store/xxcfsimvxz7z4dj593gnqbkzc6picwzq-sed-4.8/bin:/gnu/store/yrv5f70mn83a876b78i5s79dd2hsh0zf-grep-3.8/bin:/gnu/store/6k1yys9wqrfn4y41ic1win8gpnimncwj-xz-5.2.8/bin:/gnu/store/a5i8avx826brw5grn3n4qv40g514505c-coreutils-9.1/bin:/gnu/store/wj7casda7rb55rvqjnpm0bm7a2zm6618-make-4.3/bin:/gnu/store/rib9g2ig1xf3kclyl076w28parmncg4k-bash-minimal-5.1.16/bin:/gnu/store/na1dpbbcxjaa3n8wkwrfpch476f90hlf-ld-wrapper-0/bin:/gnu/store/zh4x65snfis7svs6906gj1z8i7dx2j3m-binutils-2.38/bin:/gnu/store/5lqhcv91ijy82p92ac6g5xw48l0lwwz4-gcc-11.3.0/bin:/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/bin:/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/sbin:/gnu/store/zkxvwia0z25409k1kmm0jqzfk9prc8fx-libpng-1.6.37/bin:/gnu/store/3dv9xf07gnmc4gpm0a4h0g7j58dx3l05-freetype-2.13.0/bin:/gnu/store/fncsrwapajvfkl76zmn6z1cxqd7hlbqf-fontconfig-minimal-2.14.0/bin:/gnu/store/8ncip2dd4g6g5pnpil8phfmwn234s7xh-eudev-3.2.11/bin:/gnu/store/8ncip2dd4g6g5pnpil8phfmwn234s7xh-eudev-3.2.11/sbin:/gnu/store/jjnbhhpka0xk8jjs6y973g86n9nm0wqk-fribidi-1.0.12/bin:/gnu/store/ma1zc3gf03v3qa4m7fg7kjlpi1kbarpa-xorg-server-xwayland-21.1.3/bin:/gnu/store/fw1wywd34vh33l4dq182ds5d7jdz45j5-expat-2.5.0/bin:/gnu/store/i371k86cad71y1z0br3d2awgrs4kdjqc-libdatrie-0.2.13/bin:/gnu/store/0ibv7vw1ff6f4c15p9c0k4izx4kqwlkr-icu4c-71.1/bin:/gnu/store/0ibv7vw1ff6f4c15p9c0k4izx4kqwlkr-icu4c-71.1/sbin:/gnu/store/skz71j7pmi8pqmqmcjyaizd7l9hlfd6f-graphite2-1.3.13/bin:/gnu/store/9sp8nqyiarcxh9ivpk8vp8i6xx5wb0yn-elogind-246.10/bin'
environment variable `PKG_CONFIG_PATH' set to 
`/gnu/store/q4yp3xsi6dgj1ln8fndshcb4fkrs531z-wayland-protocols-1.29/share/pkgconfig:/gnu/store/gg3kycn5wfjwskx3xfkk1qscjgsvaxcn-cairo-1.16.0/lib/pkgconfig:/gnu/store/1z04k5w139770a8blvq1a2i7fpbjr19s-libinput-minimal-1.22.1/lib/pkgconfig:/gnu/store/agk7cdgszszwgdkgnnr0vi0r6ni2761p-libucl-0.8.2/lib/pkgconfig:/gnu/store/53wla2a7bzcammq26qr8yi8gz7399v9r-libxkbcommon-1.4.1/lib/pkgconfig:/gnu/store/65f0cdmsv7qqrc01hjvriwhlrimn4kxv-linux-pam-1.5.2/lib/pkgconfig:/gnu/store/rr1vbf04j27z5465wsm1kdfaw3iriz2k-pango-1.50.10/lib/pkgconfig:/gnu/store/a3flz4vpqgnjxc6jv0cjv6f7qdbg4igz-wayland-1.22.0/lib/pkgconfig:/gnu/store/lh0k0z69ydgmjry5rs2l2n9ha7sfvrgh-wlroots-0.16.1/lib/pkgconfig:/gnu/store/gr0sy0m1mv36qv54idm6cn10l3mngshq-file-5.44/lib/pkgconfig:/gnu/store/6k1yys9wqrfn4y41ic1win8gpnimncwj-xz-5.2.8/lib/pkgconfig:/gnu/store/x0p8rbcpql70zf3fvj9fbha67mfq93j7-libxrender-0.9.10/lib/pkgconfig:/gnu/store/z8kgahaarjpl0b1nzpqmzyrm4bbmnxw3-libxext-1.3.4/lib/pkgconfig:/gnu/store/qabydd2r26gcr9s26hzchip3a3h3zhg4-libxcb-1.15/lib/pkgconfig:/gnu/store/0hvkv5kvrk7ix29pfnbkyppbdxa7ki7n-libx11-1.8.1/lib/pkgconfig:/gnu/store/p6za1mhsrw7fxgngyjkkm6z9dkgdfnqf-pixman-0.40.0/lib/pkgconfig:/gnu/store/zkxvwia0z25409k1kmm0jqzfk9prc8fx-libpng-1.6.37/lib/pkgconfig:/gnu/store/nb40pwd37v6i1g4b1fq4l6q4h9px3asr-glib-2.72.3/lib/pkgconfig:/gnu/store/3dv9xf07gnmc4gpm0a4h0g7j58dx3l05-freetype-2.13.0/lib/pkgconfig:/gnu/store/fncsrwapajvfkl76zmn6z1cxqd7hlbqf-fontconfig-minimal-2.14.0/lib/pkgconfig:/gnu/store/8ncip2dd4g6g5pnpil8phfmwn234s7xh-eudev-3.2.11/lib/pkgconfig:/gnu/store/8ncip2dd4g6g5pnpil8phfmwn234s7xh-eudev-3.2.11/share/pkgconfig:/gnu/store/74rb4yrph1yf6whfp7vz9xcyda8jml5i-libxft-2.3.4/lib/pkgconfig:/gnu/store/31nrpzwids7sn442zc36fwx559srjhl3-libthai-0.1.29/lib/pkgconfig:/gnu/store/n7vynkl0rkqmvahxji6530n8hmfscxsd-harfbuzz-5.3.1/lib/pkgconfig:/gnu/store/jjnbhhpka0xk8jjs6y973g86n9nm0wqk-fribidi-1.0.12/lib/pkgconfig:/gnu/store/w8b0l8hk6g0fahj4fvmc4qqm3cvaxnmv-libffi-3.4.4/lib/pkgconfig:/gnu/store/ma1zc3gf03v3qa4m7fg7kjlpi1kbarpa-xorg-server-xwayland-21.1.3/lib/pkgconfig:/gnu/store/5pinmx8hvh0y3r1dfclci722va82q2b9-xcb-ut

bug#63425: GNOME tracker does not work with tracker-miners

[Sughosha via Bug reports for GNU Guix]

GNOME "tracker" is built with "libexecdir" in its own prefix in the store and 
"tracker-miners" in its own. The problem is that "tracker" does not have access 
to the executable files in the "libexecdir" of "tracker-miners", so commands 
like "tracker3 extract file.flac" does not work. Due to this problem GNOME 
Music cannot list FLAC files (I don't know how it listed my MP3 file). As per 
this issue , "tracker3 
extract" should work for GNOME Music to show FLAC files.

bug#63378: [PATCH] teams: Fix script to produce a single X-Debbugs-Cc header.

[Maxim Cournoyer]

Hi Arun,

Arun Isaac  writes:

> Hi Maxim,
>
> When a patch relates to no teams, I get the empty header output
> "X-Debbugs-Cc: ". For such patches, it would be nicer to not add any
> header instead of adding an empty header.

Good catch!  Fixed.

>> +(define (team->members team)
>> +  "Return the list of members in TEAM."
>> +  (sort (team-members team)
>> +(lambda (m1 m2)
>> +  (string> +
>> +(define (member->string member)
>> +  "Return the 'email ' string representation of MEMBER."
>> +  (format #false "~a <~a>" (person-name member) (person-email
>> member)))
>
> When person name contains a comma, it should be escaped by surrounding
> in double quotes. Else, the comma would interfere with the
> comma-separated list that we are constructing for
> X-Debbugs-Cc. Admittedly, none of our current team members have commas
> in their person names. But, some people like to have a name like
> "LastName, FirstName". We should protect against that edge case in the
> interest of futureproofing.

OK!  I opted for simplicity and double-quoted all the names.

>> + (format #true "X-Debbugs-Cc: ~{~a~^,~}"
>> + (append-map (compose (cut map member->string <>)
>> +  team->members
>> +  find-team)
>> + (patch->teams patch-file
>
> A very nitpicky suggestion: Maybe, separate multiple persons by ", "
> instead of just ",". ", " looks slightly better cosmetically. Likewise
> in other places where this occurs.

Good idea; I've learnt this was valid email syntax just today :-).

Below is the diff of my rework:

--8<---cut here---start->8---
1 file changed, 18 insertions(+), 17 deletions(-)
etc/teams.scm.in | 35 ++-

modified   etc/teams.scm.in
@@ -605,20 +605,20 @@ (define (find-team-by-scope files)
 (define (cc . teams)
   "Return arguments for `git send-email' to notify the members of the given
 TEAMS when a patch is received by Debbugs."
-  (format #true
-  "--add-header=\"X-Debbugs-Cc: ~{~a~^,~}\""
-  (map person-email
-   (delete-duplicates (append-map team-members teams) equal?
-
-(define (team->members team)
-  "Return the list of members in TEAM."
-  (sort (team-members team)
+  (let ((members (append-map team-members teams)))
+(unless (null? members)
+  (format #true "--add-header=\"X-Debbugs-Cc: ~{~a~^, ~}\""
+  (map person-email (sort-members members))
+
+(define (sort-members members)
+  "Deduplicate and sort MEMBERS alphabetically by their name."
+  (sort (delete-duplicates members equal?)
 (lambda (m1 m2)
   (stringstring member)
   "Return the 'email ' string representation of MEMBER."
-  (format #false "~a <~a>" (person-name member) (person-email member)))
+  (format #false "\"~a\" <~a>" (person-name member) (person-email member)))
 
 (define* (list-members team #:optional port (prefix ""))
   "Print the members of the given TEAM."
@@ -626,7 +626,7 @@ (define* (list-members team #:optional port (prefix ""))
   (for-each
(lambda (member)
  (format port* "~a~a~%" prefix (member->string member)))
-   (team->members team)))
+   (sort-members (team-members team
 
 (define (list-teams)
   "Print all teams, their scope and their members."
@@ -720,14 +720,15 @@ (define (main . args)
  (apply cc (find-team-by-scope
 (diff-revisions rev-start rev-end
 (("cc-members-header-cmd" patch-file)
- (format #true "X-Debbugs-Cc: ~{~a~^,~}"
- (append-map (compose (cut map member->string <>)
-  team->members
-  find-team)
- (patch->teams patch-file
+ (let* ((teams (map find-team (patch->teams patch-file)))
+(members (sort-members (append-map team-members teams
+   (unless (null? members)
+ (format #true "X-Debbugs-Cc: ~{~a~^, ~}"
+ (map member->string members)
 (("cc-mentors-header-cmd" patch-file)
- (format #true "X-Debbugs-Cc: ~{~a~^,~}"
- (map member->string (team->members (find-team "mentors")
+ (format #true "X-Debbugs-Cc: ~{~a~^, ~}"
+ (map member->string
+  (sort-members (team-members (find-team "mentors"))
 (("get-maintainer" patch-file)
  (apply main "list-members" (patch->teams patch-file)))
 (("list-teams" . args)
--8<---cut here---end--->8---

A proper v2 patch has been sent.

-- 
Thanks,
Maxim

bug#63331: Guile-GnuTLS/Git circular dependency

[Christopher Baines]

Ludovic Courtès  writes:

> Hi,
>
> Christopher Baines  skribis:
>
>> It seems to build for me, but I'm having problems cross building. There
>> were warnings before about protocol/ssl3 being undefined, but now this
>> seems to result in an error when building extra.scm:
>>
>>
>>   GUILEC   modules/gnutls.go
>> gnutls.scm:608:23: warning: possibly unbound variable `protocol/ssl3'
>> gnutls.scm:609:25: warning: possibly unbound variable `protocol/tls1-0'
>> gnutls.scm:610:25: warning: possibly unbound variable `protocol/tls1-1'
>>   GUILEC   modules/gnutls/extra.go
>
> [...]
>
>> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
>> Unbound variable: protocol/ssl3
>> make[3]: *** [Makefile:1295: modules/gnutls/extra.go] Error 1
>
> Is it a regression or did we already have that problem?

A regression I think, the data service doesn't have recent data, but it
does know about builds that worked:

  
https://data.guix.gnu.org/repository/1/branch/master/package/guile-gnutls/output-history?output=out&system=x86_64-linux&target=riscv64-linux-gnu

> That comes from this bit in (gnutls):
>
>   ;; Renaming.
>   (define protocol/ssl-3 protocol/ssl3)
>   (define protocol/tls-1.0 protocol/tls1-0)
>   (define protocol/tls-1.1 protocol/tls1-1)
>
> When cross-compiling, the .so cannot be loaded (understandably; see also
> GNUTLS_GUILE_CROSS_COMPILING) so ‘protocol/ssl3’ above is undefined.
> The problem is that when compiling (gnutls extra), we end up loading
> (gnutls) and thus evaluating the lines above, which fail.
>
> In Guile-Avahi I worked around it like so:
>
>   (define protocol/unspecified
> (and (defined? 'protocol/unspec) protocol/unspec))
>
> I guess we could do that as well

That sort of makes sense, although I don't know why this wasn't failing
in the same way in the past. Build logs are available though, so maybe
this makes sense to someone.


signature.asc
Description: PGP signature

bug#63331: Guile-GnuTLS/Git circular dependency

[Ludovic Courtès]

Hi,

Christopher Baines  skribis:

> It seems to build for me, but I'm having problems cross building. There
> were warnings before about protocol/ssl3 being undefined, but now this
> seems to result in an error when building extra.scm:
>
>
>   GUILEC   modules/gnutls.go
> gnutls.scm:608:23: warning: possibly unbound variable `protocol/ssl3'
> gnutls.scm:609:25: warning: possibly unbound variable `protocol/tls1-0'
> gnutls.scm:610:25: warning: possibly unbound variable `protocol/tls1-1'
>   GUILEC   modules/gnutls/extra.go

[...]

> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> Unbound variable: protocol/ssl3
> make[3]: *** [Makefile:1295: modules/gnutls/extra.go] Error 1

Is it a regression or did we already have that problem?

That comes from this bit in (gnutls):

  ;; Renaming.
  (define protocol/ssl-3 protocol/ssl3)
  (define protocol/tls-1.0 protocol/tls1-0)
  (define protocol/tls-1.1 protocol/tls1-1)

When cross-compiling, the .so cannot be loaded (understandably; see also
GNUTLS_GUILE_CROSS_COMPILING) so ‘protocol/ssl3’ above is undefined.
The problem is that when compiling (gnutls extra), we end up loading
(gnutls) and thus evaluating the lines above, which fail.

In Guile-Avahi I worked around it like so:

  (define protocol/unspecified
(and (defined? 'protocol/unspec) protocol/unspec))

I guess we could do that as well here.

HTH,
Ludo’.

bug#63412: Topological sorting in cuirass

[Dr. Arne Babenhauserheide]

Andreas Enge  writes:

> Cuirass should sort builds and only offload derivations for which all
> inputs are available.
...
> Alternatively, build jobs could be sorted topologically and then be kept
> in a list; then before sending out a job, all its inputs have been tried
> to be built; the job should then be sent if all inputs are available, or
> be marked as "Failed (dependency)" if any of them has failed.

If you want to try this out quickly, you could use code from the
topological sorting SRFI I’m slowly finalizing:

https://srfi.schemers.org/srfi-234/srfi-234.html

For usage see: 
https://github.com/scheme-requests-for-implementation/srfi-234/blob/main/srfi-234-test.scm

Code: 
https://github.com/scheme-requests-for-implementation/srfi-234/blob/main/srfi/234-impl.scm

edgelist->graph should do the conversion from inputs per package to the
input format.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de


signature.asc
Description: PGP signature

bug#63368: Build coordiantor "Signals delivery fails constantly" crashes

[Christopher Baines]

Christopher Baines  writes:

> Since the recent core-updates merge, I've seen the build coordinator
> using less memory, but it's also been crashing in a new way, up to 10
> times a day.
>
> In the log, you see something like:
>
>   2023-05-07 09:15:42 Signals delivery fails constantly at GC #71051
>   2023-05-07 09:15:42 Signals delivery fails constantly
>
> I'm guessing the switch from libgc-8.0.4 to libgc-8.2.2 has something to
> do with this.

I think I've found a workaround. I found a list of environment variables
[1] you can set to affect the GC behaviour, and the first one I tried
(GC_RETRY_SIGNALS=0) seems to have had the desired affect, in that the
crashes/restarts have stopped.

1: https://github.com/ivmai/bdwgc/blob/master/docs/README.environment

I've sent a patch [2] to apply this setting as part of the service.

2: https://issues.guix.gnu.org/63417


signature.asc
Description: PGP signature

bug#43849: mesa is not reproducible

[Maxim Cournoyer]

Hi,

zimoun  writes:

> Dear Danny,
>
> You asked on guix-devel since when Mesa is not reproducible: at least
> since v1.1.0.
>
>   git --no-pager log v1.1.0 -1 --format='%H'
>   d62c9b2671be55ae0305bebfda17b595f33797f2
>
>   guix time-machine --commit=d62c9b2671be55ae0305bebfda17b595f33797f2 \
>-- build mesa
>   guix time-machine --commit=d62c9b2671be55ae0305bebfda17b595f33797f2 \
>-- build mesa --no-grafts --check -K
>
> guix build: error: derivation 
> `/gnu/store/wsp9wf83bbsmz8x061rhqndx05zmjff0-mesa-19.3.4.drv' may not be 
> deterministic: output 
> `/gnu/store/2mf0clz9w64diy0kz11qcs4q5wg9hc6z-mesa-19.3.4' differs from 
> ?/gnu/store/2mf0clz9w64diy0kz11qcs4q5wg9hc6z-mesa-19.3.4-check?
>
> And the differing files are:
>
>  - lib/dri/iris_dri.so
>  - lib/dri/nouveau_drv_video.so
>  - lib/libvulkan_radeon.so
>  - lib/vdpau/libvdpau_nouveau.so.1.0.0

This has supposedly been fixed by updates to Meson.

Closing.

-- 
Thanks,
Maxim

bug#63414: Evaluation comparison on cuirass

[Andreas Enge]

When working on a branch and deciding whether to merge it, we need a way
of comparing its status with that of the master branch. As far as I can see,
there is currently no way in cuirass to compare arbitrary evaluations and
get a list (or a dashboard) of builds that fail in one, but not the other.

Andreas

bug#63413: Stop and restart builds in cuirass

[Andreas Enge]

Stopping and starting builds in cuirass is not very comfortable.

When working on core-updates, I stopped builds for some old evaluations
on aarch64, where our build power would not be enough, assuming that many
of the old builds were made obsolete by newer changes. (For instance,
these could be builds in branches that were already merged to master.)

However, this also stopped the builds that were not obsolete. And if the
derivation was unchanged in a later evaluation (or a different branch),
it would be kept as failed and not be restarted. I would argue that the
desirable behaviour would be to try all derivations in a new evaluation,
regardless of whether they were stopped in a previous evaluation.

A use case are feature branches:
Assume x-team and y-team are branches that are developed simultaneously;
now x-team is ready first and gets merged to master. All builds of y-team
are stopped (since there is no point in continuing with builds made obsolete
by changes in x-team), the branch is rebased on master, and now all builds
need to be restarted on the rebuilt branch. There is a button for this,
but it also restarts genuinely failed builds, if I remember correctly.
(In any case it did not solve the problem, but I have forgotten the
details.)

Restarting builds manually requires to take the dependency order into
account. If x->y->z is a dependency chain, x has been stopped, and y or z
are restarted, they will immediately fail since x is not available;
otherwise said, restarting manually requires a manual traversal of the
dependency graph, which should be automated.

It would also be a useful feature to restart all builds of dependent
packages: If x is "repaired" and manually started, it would be nice to
be able to start all its dependents (ordered automatically by cuirass)
to see whether they now succeed, instead of forcing us to manually
traverse the graph again.
For instance, we recently got a report on guix-devel of "no space left
on device" for icedtea@3. This would be easy to solve by a "guix gc"
on the build machines, but we currently have no way of restarting the
many builds dependent on icedtea@3 other than restarting all packages.

Andreas

bug#63412: Topological sorting in cuirass

[Andreas Enge]

This is a wishlist bug, but it is important for architectures where we
are currently short on build power, and where this issue can stall builds
and waste an arbitrary amount of build power.

Cuirass should sort builds and only offload derivations for which all
inputs are available.

In my current understanding, cuirass offloads arbitrary derivations, and
the machine to which they are offloaded then starts building recursively
all inputs. If this is true, then it is possible that at some point in time,
all build slots are taken by the same package built as many times as there
are machines; I have seen something like this when working on core-updates,
where several machines were building the main gcc compiler at the same time.
At worse, if cuirass asks every machine to build a leaf package, this may
result in a simultaneous full bootstrap on all of them.

The situation becomes worse when the package in question fails. Then as
I understand it, each machine may receive a request to build something
depending on the failing package and try the failing build and thus waste
build power that will not be available to build other packages successfully.

Solving this problem may also make reports of build failures more accurate
and legible. For instance, doxygen currently fails to build on aarch64:
   https://ci.guix.gnu.org/build/969427/details
and is reported as "Failed", and not as "Failed (dependency)".
However, looking at the build log
   https://ci.guix.gnu.org/build/969427/log/raw
shows this:
...
building path(s) `/gnu/store/p5vqrwywz053r1vkiyw54dp9gj7vw9xd-ninja-1.11.1'
...
builder for `/gnu/store/0zf7fqndzf2k595r4s6wblmpccdwr3nx-ninja-1.11.1.drv' 
failed with exit code 1
@ build-failed /gnu/store/0zf7fqndzf2k595r4s6wblmpccdwr3nx-ninja-1.11.1.drv - 1 
builder for `/gnu/store/0zf7fqndzf2k595r4s6wblmpccdwr3nx-ninja-1.11.1.drv' 
failed with exit code 1
cannot build derivation 
`/gnu/store/hlscqram59id51hxg0fj15041v52h1kw-meson-1.1.0.drv': 1 dependencies 
couldn't be built
cannot build derivation 
`/gnu/store/w8qxkrwpffd9qs5w1jggy1yi27ycm0xr-jsoncpp-1.9.5.drv': 2 dependencies 
couldn't be built
cannot build derivation 
`/gnu/store/mss4yv015cil1vnjnglq506m83b7n3dy-cmake-bootstrap-3.24.2.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/w0irp6xn30nlmpizhcbjnvhqmsba41jn-cmake-minimal-3.24.2.drv': 2 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/rqk2rbnpjpcnqswz8hqari1rnw6r8v1m-doxygen-1.9.5.drv': 1 dependencies 
couldn't be built

So it is indeed a different package that fails (and the last few lines
give a list of dependencies between ninja and doxygen, each of which may
or may not fail once ninja is fixed).

Notice that this could be solved without a topological sorting of the
dependency graph: It would be enough to keep an array deriv in which
deriv[i] contains a list of derivations requiring i more inputs to be built,
together with the list of inputs; elements in deriv[0] are ready to be sent
to a build machine, and upon completion of a build, all derivations
depending on it should be moved from deriv[i] to deriv[i-1] if the input
has been built successfully, or marked as "Failed (dependency)" if the
input has failed. (But this could be expensive, and may require appropriate
data structures.)

Alternatively, build jobs could be sorted topologically and then be kept
in a list; then before sending out a job, all its inputs have been tried
to be built; the job should then be sent if all inputs are available, or
be marked as "Failed (dependency)" if any of them has failed.

Andreas