bug#52375: webkitgtk needs gst-plugins-bad
I asked about this issue on #webkitgtk:gnome.org on IRC. It turns out that what's missing from my environment is gst-plugins-bad (most likely the fakevideosink plugin contained therein). If I install gst-plugins-bad into an environment with a webgkitgtk browser, the crash I was seeing is resolved. Only adding gst-plugins-bad to the inputs of webkitgtk doesn't seem to be enough to solve the problem. I suppose some additional wrapping is needed somewhere (although gst-plugins-base shows up in the webkitgtk references). What's the best path forward here? Should leaf applications that use webkitgtk be wrapped to find the right gst-plugins? This seems suboptimal to me. If the plugins are really dependencies of webkitgtk then perhaps they should be encoded that way in Guix. Should webkitgtk be wrapped somehow to find the plugins on its own? How would this wrapping be done? Do we want to force all webkitgtk applications to carry around these dependencies? Best, Jack
bug#52694: time-machine error when leaping from version-1.2.0 to version-1.4.0
Hi Carl,
On Mon, 20 Dec 2021 at 17:28, Carl Dong wrote:
> $ guix time-machine --branch=version-1.2.0 -- time-machine
> --commit=6dffced09ecda024e0884e352778c221ad066fd6 -- describe
This works for me:
--8<---cut here---start->8---
$ guix time-machine --branch=version-1.2.0 -- time-machine
--commit=6dffced09ecda024e0884e352778c221ad066fd6 -- describe
Mise à jour du canal « guix » depuis le dépôt Git «
https://git.savannah.gnu.org/git/guix.git »...
guix 6dffced
URL du dépôt : https://git.savannah.gnu.org/git/guix.git
commit : 6dffced09ecda024e0884e352778c221ad066fd6
--8<---cut here---end--->8---
But another commit does not work:
--8<---cut here---start->8---
$ guix time-machine --branch=version-1.2.0 -- time-machine --commit=6786336 --
describe
Mise à jour du canal « guix » depuis le dépôt Git «
https://git.savannah.gnu.org/git/guix.git »...
Backtrace:
In guix/store.scm:
2042:24 19 (run-with-store # …)
In guix/inferior.scm:
734:8 18 (_ _)
In guix/channels.scm:
876:2 17 (_ _)
836:2 16 (_ _)
In ./guix/monads.scm:
482:9 15 (_ _)
In guix/store.scm:
1876:8 14 (_ _)
In guix/channels.scm:
604:36 13 (_ #)
657:11 12 (_)
In ice-9/eval.scm:
196:35 11 (_ #(#(#) "/gnu…" …))
173:47 10 (_ #(#(#(#) # …) …))
213:37 9 (_ #(#(#(#) # …) …))
159:9 8 (_ #(#(#(#) # …) …))
159:9 7 (_ #(#(#(#) # …) …))
159:9 6 (_ #(#(#(#) # …) …))
In guix/modules.scm:
157:28 5 (module-closure _ #:select? _ #:dependencies _)
In guix/memoization.scm:
100:0 4 (_ # "/gnu/store/dljzmm…" …)
In ice-9/ports.scm:
445:17 3 (call-with-input-file _ _ #:binary _ #:encoding _ # _)
In guix/modules.scm:
69:4 2 (_ _)
In ice-9/boot-9.scm:
1669:16 1 (raise-exception _ #:continuable? _)
1669:16 0 (raise-exception _ #:continuable? _)
ice-9/boot-9.scm:1669:16: In procedure raise-exception:
Throw to key `match-error' with args `("match" "no matching pattern"
(#:re-export-and-replace (delete) #:replace ((define-public* . define-public))
#:export (content-hash content-hash? content-hash-algorithm content-hash-value
origin origin? this-origin origin-uri origin-method origin-hash origin-sha256
origin-file-name origin-actual-file-name origin-patches origin-patch-flags
origin-patch-inputs origin-patch-guile origin-snippet origin-modules base32
base64 package package? this-package package-name package-upstream-name
package-version package-full-name package-source package-build-system
package-arguments package-inputs package-native-inputs
package-propagated-inputs package-outputs package-native-search-paths
package-search-paths package-replacement package-synopsis package-description
package-license package-home-page package-supported-systems package-properties
package-location package-definition-location hidden-package hidden-package?
package-superseded deprecated-package package-field-location this-package-input
this-package-native-input lookup-package-input lookup-package-native-input
lookup-package-propagated-input lookup-package-direct-input prepend replace
modify-inputs package-direct-sources package-transitive-sources
package-direct-inputs package-transitive-inputs
package-transitive-target-inputs package-transitive-native-inputs
package-transitive-propagated-inputs package-transitive-native-search-paths
package-transitive-supported-systems package-mapping package-input-rewriting
package-input-rewriting/spec package-source-derivation package-derivation
package-cross-derivation package-output package-grafts
package-patched-vulnerabilities package-with-patches package-with-extra-patches
package-with-c-toolchain package/inherit transitive-input-references
%supported-systems %hurd-systems %cuirass-supported-systems supported-package?
&package-error package-error? package-error-package &package-input-error
package-input-error? package-error-invalid-input
&package-cross-build-system-error package-cross-build-system-error?
package->bag bag->derivation bag-direct-inputs bag-transitive-inputs
bag-transitive-host-inputs bag-transitive-build-inputs
bag-transitive-target-inputs package-development-inputs package-closure
default-guile default-guile-derivation set-guile-for-build package-file
package->derivation package->cross-derivation origin->derivation)))'.
--8<---cut here---end--->8---
Hum!
(Well I am surprised to not get twice “Updating channel 'guix'”.)
Cheers,
simon
bug#52694: time-machine error when leaping from version-1.2.0 to version-1.4.0
Hi all,
A fellow Bitcoin developer has submitted a patch bumping our time-machine to a
commit on the version-1.4.0 branch for testing. While testing that change, a
few developers encountered a bug in the time-machine script.
I’ve been able to distill it down to a reproducible form:
$ guix time-machine --branch=version-1.2.0 -- time-machine
--commit=6dffced09ecda024e0884e352778c221ad066fd6 -- describe
The specific error that you get:
--8<---cut here---start->8---
Updating channel 'guix' from Git repository at
'https://git.savannah.gnu.org/git/guix.git'...
Updating channel 'guix' from Git repository at
'https://git.savannah.gnu.org/git/guix.git'...
Backtrace:
In guix/store.scm:
2042:24 19 (run-with-store # ?)
In guix/inferior.scm:
734:8 18 (_ _)
In guix/channels.scm:
876:2 17 (_ _)
836:2 16 (_ _)
In ./guix/monads.scm:
482:9 15 (_ _)
In guix/store.scm:
1876:8 14 (_ _)
In guix/channels.scm:
604:36 13 (_ #)
657:11 12 (_)
In ice-9/eval.scm:
196:35 11 (_ #(#(#) "/gnu?" ?))
173:47 10 (_ #(#(#(#) # ?) ?))
213:37 9 (_ #(#(#(#) # ?) ?))
159:9 8 (_ #(#(#(#) # ?) ?))
159:9 7 (_ #(#(#(#) # ?) ?))
159:9 6 (_ #(#(#(#) # ?) ?))
In guix/modules.scm:
157:28 5 (module-closure _ #:select? _ #:dependencies _)
In guix/memoization.scm:
100:0 4 (_ # "/gnu/store/i88h59?" ?)
In ice-9/ports.scm:
445:17 3 (call-with-input-file _ _ #:binary _ #:encoding _ # _)
In guix/modules.scm:
69:4 2 (_ _)
In ice-9/boot-9.scm:
1669:16 1 (raise-exception _ #:continuable? _)
1669:16 0 (raise-exception _ #:continuable? _)
ice-9/boot-9.scm:1669:16: In procedure raise-exception:
Throw to key `match-error' with args `("match" "no matching pattern"
(#:re-export-and-replace (delete) #:replace ((define-public* . define-public))
#:export (content-hash content-hash? content-hash-algorithm content-hash-value
origin origin? this-origin origin-uri origin-method origin-hash origin-sha256
origin-file-name origin-actual-file-name origin-patches origin-patch-flags
origin-patch-inputs origin-patch-guile origin-snippet origin-modules base32
base64 package package? this-package package-name package-upstream-name
package-version package-full-name package-source package-build-system
package-arguments package-inputs package-native-inputs
package-propagated-inputs package-outputs package-native-search-paths
package-search-paths package-replacement package-synopsis package-description
package-license package-home-page package-supported-systems package-properties
package-location package-definition-location hidden-package hidden-package?
package-superseded deprecated-package package-field-location this-package-input
this-package-native-input lookup-package-input lookup-package-native-input
lookup-package-propagated-input lookup-package-direct-input prepend replace
modify-inputs package-direct-sources package-transitive-sources
package-direct-inputs package-transitive-inputs
package-transitive-target-inputs package-transitive-native-inputs
package-transitive-propagated-inputs package-transitive-native-search-paths
package-transitive-supported-systems package-mapping package-input-rewriting
package-input-rewriting/spec package-source-derivation package-derivation
package-cross-derivation package-output package-grafts
package-patched-vulnerabilities package-with-patches package-with-extra-patches
package-with-c-toolchain package/inherit transitive-input-references
%supported-systems %hurd-systems %cuirass-supported-systems supported-package?
&package-error package-error? package-error-package &package-input-error
package-input-error? package-error-invalid-input
&package-cross-build-system-error package-cross-build-system-error?
package->bag bag->derivation bag-direct-inputs bag-transitive-inputs
bag-transitive-host-inputs bag-transitive-build-inputs
bag-transitive-target-inputs package-development-inputs package-closure
default-guile default-guile-derivation set-guile-for-build package-file
package->derivation package->cross-derivation origin->derivation)))'.
--8<---cut here---end--->8---
Let me know if there’s any other information I can provide or if this is a dupe!
Cheers,
Carl Dong
bug#52684: [BUG] Multiple Packages Failing to Build
Hi,
Thanks for your report. It is collateral issue of recent core-updates
merge which major updates. Almost was fine, except sparse packages
which seem broken.
The commit merging core-updates is 6dffced09e (where the one you mention
2c469f0 is a direct descendant), so the 2 parents are: b603554ed0 (old
master) and e3196755e6 (major updates). Let compare availability:
--8<---cut here---start->8---
$ guix time-machine --commit=b603554ed0 -- weather apl beets-bandcamp frotz
nomad passwordsafe
calcul de 5 dérivations de paquets pour x86_64-linux…
recherche de 5 éléments du dépôt sur https://ci.guix.gnu.org...
https://ci.guix.gnu.org
100.0 % des substituts sont disponibles (5 sur 5)
au moins 8,7 Mo de fichiers nar (compressés)
11,0 Mo sur le disque (décompressé)
0,161 secondes par requête (0,3 secondes en tout)
6,2 requêtes par seconde
au moins 1 000 constructions dans la queue
aarch64-linux : 836 (83.6 %)
i686-linux : 56 (5.6 %)
x86_64-linux : 75 (7.5 %)
powerpc64le-linux : 33 (3.3 %)
vitesse de construction : .00 constructions par l'heure
i686-linux : 0.00 constructions par heure
x86_64-linux : 0.00 constructions par heure
recherche de 5 éléments du dépôt sur https://bordeaux.guix.gnu.org...
https://bordeaux.guix.gnu.org
100.0 % des substituts sont disponibles (5 sur 5)
2,5 Mo de fichiers nar (compressés)
11,0 Mo sur le disque (décompressé)
0,080 secondes par requête (0,3 secondes en tout)
12,6 requêtes par seconde
(informations sur l’intégration continue indisponibles)
--8<---cut here---end--->8---
and
--8<---cut here---start->8---
$ guix time-machine --commit=e3196755e6 -- weather apl beets-bandcamp frotz
nomad passwordsafe
calcul de 5 dérivations de paquets pour x86_64-linux…
recherche de 5 éléments du dépôt sur https://ci.guix.gnu.org...
https://ci.guix.gnu.org
0.0 % des substituts sont disponibles (0 sur 5)
taille des substituts inconnue
0,0 Mo sur le disque (décompressé)
0,104 secondes par requête (0,5 secondes en tout)
9,6 requêtes par seconde
0.0 % (0 sur 5) des éléments manquants sont dans la queue
au moins 1 000 constructions dans la queue
aarch64-linux : 836 (83.6 %)
i686-linux : 56 (5.6 %)
x86_64-linux : 75 (7.5 %)
powerpc64le-linux : 33 (3.3 %)
vitesse de construction : .00 constructions par l'heure
i686-linux : 0.00 constructions par heure
x86_64-linux : 0.00 constructions par heure
recherche de 5 éléments du dépôt sur https://bordeaux.guix.gnu.org...
https://bordeaux.guix.gnu.org
0.0 % des substituts sont disponibles (0 sur 5)
taille des substituts inconnue
0,0 Mo sur le disque (décompressé)
0,057 secondes par requête (0,3 secondes en tout)
17,4 requêtes par seconde
(informations sur l’intégration continue indisponibles)
--8<---cut here---end--->8---
where e3196755e6 is the core-updates branch using GCC 10 as default and
many other things.
On Mon, 20 Dec 2021 at 14:17, Christopher Rodriguez wrote:
> building /gnu/store/x1mx0g2cxlkmgyz4ljkkhcdcqqvidby0-apl-1.8.drv...
> | 'build' phasebuilder for
> `/gnu/store/x1mx0g2cxlkmgyz4ljkkhcdcqqvidby0-apl-1.8.drv' failed with exit
> code 1
> build of /gnu/store/x1mx0g2cxlkmgyz4ljkkhcdcqqvidby0-apl-1.8.drv failed
> View build log at
> '/var/log/guix/drvs/x1/mx0g2cxlkmgyz4ljkkhcdcqqvidby0-apl-1.8.drv.bz2'.
--8<---cut here---start->8---
Shape.hh: In member function ‘Shape Shape::insert_axis(Axis, ShapeItem) const’:
Shape.hh:68:46: error: ‘*(const ShapeItem*)((char*)& ret + *8 +8)’
may be used uninitialized in this function [-Werror=maybe-uninitialized]
68 | loop(r, MAX_RANK) rho[r] = other.rho[r];
| ~~~^
cc1plus: all warnings being treated as errors
--8<---cut here---end--->8---
Therefore, this patch fixes apl.
diff --git a/gnu/packages/apl.scm b/gnu/packages/apl.scm
index badec04333..a1b923053c 100644
--- a/gnu/packages/apl.scm
+++ b/gnu/packages/apl.scm
@@ -49,7 +49,8 @@ (define-public apl
("sqlite" ,sqlite)
("readline" ,readline)))
(arguments
- `(#:configure-flags (list (string-append
+ `(#:configure-flags (list "CXX_WERROR=no"
+ (string-append
"--with-sqlite3="
(assoc-ref %build-inputs "sqlite")
(synopsis "APL interpreter")
The other beets-bandcamp, it is because the new ’sanity-check’ phase for
Python package, so it is easy to fix. Do you want to give a try?
For frotz, nomad and passwordsafe, they require more investigations.
Cheers,
simon
bug#52539: Fwd: Comments in /etc/passwd don't get updated
Changing the shell indeed causes the comment to be updated.
If lazy update is the correct behavior, then the docs about user
accounts are a bit misleading:
"When booting or upon completion of guix system reconfigure, the
system ensures that only the user accounts and groups specified in the
operating-system declaration exist, and with the specified properties.
Thus, account or group creations or modifications made by directly
invoking commands such as useradd are lost upon reconfiguration or
reboot. This ensures that the system remains exactly as declared."
As a user it would be helpful to know from the docs that some of the
fields actually persist across reboots/reconfigurations.
Thanks for the workaround in any case!
On Fri, Dec 17, 2021 at 4:02 AM Liliana Marie Prikler
wrote:
>
> Hi,
>
> Am Donnerstag, dem 16.12.2021 um 07:00 + schrieb Jacob First:
> > In my Guix system's /etc/passwd file, my user named "abc" has a
> > comment attached to it. The relevant line is:
> >
> > abc:x:1000:998:Old
> > Comment:/home/jkf:/gnu/store/71yp1p06jy2j96bfdz43f4p6ncdym5a1-zsh-
> > 5.8/bin/zsh
> >
> > Today the users section of my current config.scm looks like this:
> >
> > (users (cons* (user-account
> > (name "abc")
> > (group "users")
> > (comment "New Comment")
> > (supplementary-groups '("wheel"
> > "netdev"
> > "audio"
> > "video"
> > "disk"
> > "cdrom"
> > "docker"
> > "libvirt"
> > "kvm"))
> > (shell #~(string-append #$zsh "/bin/zsh")))
> >%base-user-accounts))
> >
> > After I apply this configuration with `guix system reconfigure', I
> > expect /etc/passwd to have been updated with "New Comment" in place
> > of "Old Comment". However, "Old Comment" remains.
> >
> > Similarly, if I omit the `comment' field entirely, I expect my user
> > comment to be removed from /etc/passwd, since the default value of
> > the `comment' field is documented to be an empty string (manual
> > 10.6). Again, the old comment remains.
> >
> > I am reporting this on a recent Guix version cev9c6c5, but have
> > noticed this issue for a year at least.
> What if you were to temporarily change your login shell to let's say
> bash? IIRC, Guix is quite lazy when it comes to updating these values,
> but a change in the shell ought to get them revised. I think the
> reason behind it is that it doesn't want to lock you out by messing
> with the password field, but that's a little unrelated here.
>
> Cheers
>
bug#51787: Disk performance on ci.guix.gnu.org
Hey, > Do you mean time the copy or time the removal from that storage? You > know what, I’ll time both. I’ll need to get more space first. I think > the trash directory is larger than the 500G that I got for testing the > SAN. Yeah I meant removal time :) I found this article[1] that suggests that over time the ext4 fragmentation can cause a performance drop that is very noticeable on hard drives. I'm trying to determine how fragmented is the sdb1 file-system, by running e4defrag and e2freefrag[2], but I'm not sure if they will complete soon. Copying and removing /gnu/store/trash on the SAN will be interesting but the ultimate test would be to be able to re-create the ext4 file-system directly on Berlin's sdb drive to evaluate the fragmentation role in this funny business. Thanks, Mathieu [1]: https://www.usenix.org/system/files/hotstorage19-paper-conway.pdf [2]: https://cromwell-intl.com/open-source/performance-tuning/file-systems.html
bug#52671: glibc patch causes crash on failure to find path to executable
Hi, Ivan Kozlov skribis: > glibc-dl-cache.patch causes segmentation fault when _dl_get_origin fails > (which should be harmless unless there is $ORIGIN in RUNPATH). I found this > when running a dynamically linked executable as ‘init’, before /proc was > mounted. There needs to be an origin != (char *)-1 check. Ouch. Would you like to send a patch against glibc-dl-cache.patch? Thanks, Ludo’.
bug#52520: Multicast is off by default
Mathieu Othacehe skribis: >> Can we instead use for these purposes? It is already >> there, just unused. BTW, for the purposes of fixing the bug you initially reported, I suggest simply adding #:multicast-on #t as you initially proposed. We discuss the proper API separately. > Mmh, indeed. Well it is already used to create vlan and veth > interfaces. What we could do then, is expose the record > as a direct equivalent of the Guile-Netlink record. > > The links list of the record would contain all the > links that are managed by Guix. We would require all "device" fields > that appear in the records to have their matching link > declared. If the link doesn't already exists (vlan, veth type) then > link-add is called, otherwise nothing happens. The link existence can be > tested using link-name->index. link-set would always be called > afterwards to setup link properties. > > static-networking-shepherd-service would then create on service per link > present in the links list. The provisioned name > would be (concat 'networking- (network-link-name link)). > > On tear down, which is equivalent to "herd stop networking-", we > would call link-del if the link was created by Guix with link-add, or > (link-set ... #:down #t) if the link was already present. I'm not sure > how to distinguish between those two cases at this step. > > This sounds like a complex plan, that will moreover require and > adaptation of existing static-networking configurations, but I cannot > think of anything easier to fix this issue and the other one I reported. Hmm yeah. I think it’s good to have defaults right, so #:up and #:multicast-on set. We could set those when a device lacks a corresponding link. Food for thought… Ludo’.
bug#51787: GC takes more than 9 hours on berlin
My colleague extended the SAN slice to 5TB for more realistic testing. I formatted the disk with btrfs, and mounted it like this: mount /dev/sdd /mnt_test/ Then I ran the test with block size 512k: --8<---cut here---start->8--- root@berlin ~# fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=/mnt_test/test --bs=512k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75 test: (g=0): rw=randrw, bs=(R) 512KiB-512KiB, (W) 512KiB-512KiB, (T) 512KiB-512KiB, ioengine=libaio, iodepth=64 fio-3.6 Starting 1 process test: Laying out IO file (1 file / 4096MiB) Jobs: 1 (f=1): [m(1)][100.0%][r=802MiB/s,w=274MiB/s][r=1603,w=547 IOPS][eta 00m:00s] test: (groupid=0, jobs=1): err= 0: pid=16949: Mon Dec 20 22:18:28 2021 read: IOPS=1590, BW=795MiB/s (834MB/s)(3055MiB/3842msec) bw ( KiB/s): min=747520, max=857088, per=99.83%, avg=812763.43, stdev=44213.07, samples=7 iops: min= 1460, max= 1674, avg=1587.43, stdev=86.35, samples=7 write: IOPS=542, BW=271MiB/s (284MB/s)(1042MiB/3842msec) bw ( KiB/s): min=262144, max=297984, per=100.00%, avg=278820.57, stdev=15115.88, samples=7 iops: min= 512, max= 582, avg=544.57, stdev=29.52, samples=7 cpu : usr=1.98%, sys=96.28%, ctx=1096, majf=0, minf=6 IO depths: 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.2%, 32=0.4%, >=64=99.2% submit: 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0% issued rwts: total=6109,2083,0,0 short=0,0,0,0 dropped=0,0,0,0 latency : target=0, window=0, percentile=100.00%, depth=64 Run status group 0 (all jobs): READ: bw=795MiB/s (834MB/s), 795MiB/s-795MiB/s (834MB/s-834MB/s), io=3055MiB (3203MB), run=3842-3842msec WRITE: bw=271MiB/s (284MB/s), 271MiB/s-271MiB/s (284MB/s-284MB/s), io=1042MiB (1092MB), run=3842-3842msec --8<---cut here---end--->8--- Because this is fun I reran it with the same arguments: --8<---cut here---start->8--- root@berlin ~# fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=/mnt_test/test --bs=512k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75 test: (g=0): rw=randrw, bs=(R) 512KiB-512KiB, (W) 512KiB-512KiB, (T) 512KiB-512KiB, ioengine=libaio, iodepth=64 fio-3.6 Starting 1 process Jobs: 1 (f=0): [f(1)][-.-%][r=756MiB/s,w=260MiB/s][r=1511,w=519 IOPS][eta 00m:00s] test: (groupid=0, jobs=1): err= 0: pid=17488: Mon Dec 20 22:18:56 2021 read: IOPS=1647, BW=824MiB/s (864MB/s)(3055MiB/3708msec) bw ( KiB/s): min=738304, max=929792, per=99.28%, avg=837485.71, stdev=73710.05, samples=7 iops: min= 1442, max= 1816, avg=1635.71, stdev=143.96, samples=7 write: IOPS=561, BW=281MiB/s (295MB/s)(1042MiB/3708msec) bw ( KiB/s): min=234496, max=320512, per=99.79%, avg=287012.57, stdev=29009.60, samples=7 iops: min= 458, max= 626, avg=560.57, stdev=56.66, samples=7 cpu : usr=1.38%, sys=96.47%, ctx=1394, majf=0, minf=16420 IO depths: 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.2%, 32=0.4%, >=64=99.2% submit: 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0% issued rwts: total=6109,2083,0,0 short=0,0,0,0 dropped=0,0,0,0 latency : target=0, window=0, percentile=100.00%, depth=64 Run status group 0 (all jobs): READ: bw=824MiB/s (864MB/s), 824MiB/s-824MiB/s (864MB/s-864MB/s), io=3055MiB (3203MB), run=3708-3708msec WRITE: bw=281MiB/s (295MB/s), 281MiB/s-281MiB/s (295MB/s-295MB/s), io=1042MiB (1092MB), run=3708-3708msec --8<---cut here---end--->8--- Then I mounted with compression and space cache: mount /dev/sdd -o compress-force=zstd,space_cache=v2 /mnt_test/ The numbers don’t differ much at all. --8<---cut here---start->8--- Run status group 0 (all jobs): READ: bw=882MiB/s (925MB/s), 882MiB/s-882MiB/s (925MB/s-925MB/s), io=3055MiB (3203MB), run=3464-3464msec WRITE: bw=301MiB/s (315MB/s), 301MiB/s-301MiB/s (315MB/s-315MB/s), io=1042MiB (1092MB), run=3464-3464msec --8<---cut here---end--->8--- I then erased the file system and again put on a big ext4: --8<---cut here---start->8--- root@berlin ~# fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=/mnt_test/test --bs=512k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75 test: (g=0): rw=randrw, bs=(R) 512KiB-512KiB, (W) 512KiB-512KiB, (T) 512KiB-512KiB, ioengine=libaio, iodepth=64 fio-3.6 Starting 1 process test: Laying out IO file (1 file / 4096MiB) Jobs: 1 (f=1): [m(1)][-.-%][r=1539MiB/s,w=526MiB/s][r=3078,w=1052 IOPS][eta 00m:00s] test: (groupid=0, jobs=1): err= 0: pid=20672
bug#52686: menus in qt programs not visible or appearing far away on wayland
guix system guix (GNU Guix) b3a0db7a0e5fa7186c090647cfd5666e2b9287ff sway In keepassxc the menus don't show anything when clicked. (actually, I restarted it and now they work, but leaving that in to show it was multiple programs) In pcmanfm-qt the menus at the top as well as the right click menu don't show anything. In nheko the right click menu appears very far from the cursor, the same spot regardless of where in the window I've clicked.
bug#52684: [BUG] Multiple Packages Failing to Build
__ [BUG] MULTIPLE PACKAGES FAILING TO BUILD rodnchr __ Table of Contents _ 1. Environment 2. Steps to reproduce 3. Expected Result 4. Actual Result 5. Visual Proof (screenshots, videos, text) 6. Severity/Priority 1 Environment = - *Device:* Linode Virtual Server, and Lenovo Thinkpad E14. - *OS:* Guix System, and a workplace-modified version of Ubuntu. - *Commits:* guix: `2c469f04a3bec27b1f49680c638814bc06075b9a`. - *Substitutes:* Enabled, but unavailable for these packages. - *Additional Channels:* yewscion (personal channel): `84d82fede37110a34e2df5e1712eb3bf934936cf`. - *Blast Radius:* apl beets-bandcamp frotz nomad passwordsafe. 2 Steps to reproduce 1. *Update:* Run `guix pull`. 2. *Upgrade:* Run `guix package -u apl nomad beets-bandcamp frotz passwordsafe`. 3 Expected Result = All packages should build and install properly on both System and Binary Installs. 4 Actual Result === *Failure:* Build of `apl` fails, complaining. If `--keep-going` is specified, the above-listed packages all fail as well, though nothing else does. As a result, I either have to remove all of the above packages from my profile (which I did, and which let me upgrade but prevented my use of those packages) or pin my system to an earlier commit (I have been using the attached `channels.scm` file, which still contains the commented commit line). 5 Visual Proof (screenshots, videos, text) == Attached are the failed build logs, as well as a log of stdout during the attempted build, and of the output of `guix describe`. 6 Severity/Priority === 5 (Lowest Priority) Generation 53 Dec 20 2021 11:13:43 (current) guix 2c469f0 repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: 2c469f04a3bec27b1f49680c638814bc06075b9a yewscion 84d82fe repository URL: https://git.sr.ht/~yewscion/yewscion-guix-channel branch: trunk commit: 84d82fede37110a34e2df5e1712eb3bf934936cf The following packages will be upgraded: apl(dependencies or package changed) beets (dependencies or package changed) beets-bandcamp (dependencies or package changed) frotz (dependencies or package changed) nomad (dependencies or package changed) passwordsafe (dependencies or package changed) python-pyqt(dependencies or package changed) The following derivations will be built: /gnu/store/m2lcg448yhgvv45kwr9hv3sn7ph3v15v-profile.drv /gnu/store/7qsgqn0r9w8d6ilnsgwdmrvs13l6q3qj-nomad-0.2.0-alpha-199-g3e7a475.drv /gnu/store/8b7p5m8jaycc0bfklkh2rg75r989m323-frotz-2.44.drv /gnu/store/9l47ki9g4y3xd33kj2l9ilnrn702v760-passwordsafe-5.0.drv /gnu/store/x1mx0g2cxlkmgyz4ljkkhcdcqqvidby0-apl-1.8.drv /gnu/store/yf47dj34q26smhwl6046xdbnn21fwvh4-beets-bandcamp-0.1.4.drv building /gnu/store/x1mx0g2cxlkmgyz4ljkkhcdcqqvidby0-apl-1.8.drv... | 'build' phasebuilder for `/gnu/store/x1mx0g2cxlkmgyz4ljkkhcdcqqvidby0-apl-1.8.drv' failed with exit code 1 build of /gnu/store/x1mx0g2cxlkmgyz4ljkkhcdcqqvidby0-apl-1.8.drv failed View build log at '/var/log/guix/drvs/x1/mx0g2cxlkmgyz4ljkkhcdcqqvidby0-apl-1.8.drv.bz2'. building /gnu/store/yf47dj34q26smhwl6046xdbnn21fwvh4-beets-bandcamp-0.1.4.drv... / 'sanity-check' phasebuilder for `/gnu/store/yf47dj34q26smhwl6046xdbnn21fwvh4-beets-bandcamp-0.1.4.drv' failed with exit code 1 build of /gnu/store/yf47dj34q26smhwl6046xdbnn21fwvh4-beets-bandcamp-0.1.4.drv failed View build log at '/var/log/guix/drvs/yf/47dj34q26smhwl6046xdbnn21fwvh4-beets-bandcamp-0.1.4.drv.bz2'. building /gnu/store/8b7p5m8jaycc0bfklkh2rg75r989m323-frotz-2.44.drv... - 'build' phasebuilder for `/gnu/store/8b7p5m8jaycc0bfklkh2rg75r989m323-frotz-2.44.drv' failed with exit code 1 build of /gnu/store/8b7p5m8jaycc0bfklkh2rg75r989m323-frotz-2.44.drv failed View build log at '/var/log/guix/drvs/8b/7p5m8jaycc0bfklkh2rg75r989m323-frotz-2.44.drv.bz2'. building /gnu/store/7qsgqn0r9w8d6ilnsgwdmrvs13l6q3qj-nomad-0.2.0-alpha-199-g3e7a475.drv... | 'configure' phasebuilder for `/gnu/store/7qsgqn0r9w8d6ilnsgwdmrvs13l6q3qj-nomad-0.2.0-alpha-199-g3e7a475.drv' failed with exit code 1 build of /gnu/store/7qsgqn0r9w8d6ilnsgwdmrvs13l6q3qj-nomad-0.2.0-alpha-199-g3e7a475.drv failed View build log at '/var/log/guix/drvs/7q/sgqn0r9w8d6ilnsgwdmrvs13l6q3qj-nomad-0.2.0-alpha-199-g3e7a475.drv.bz2'. building /gnu/store/9l47ki9g4y3xd33kj2l9ilnrn702v760-passwordsafe-5.0.drv... / 'configure' phasebuilder for `/gnu/store/9l47ki9g4y3xd33kj2l9ilnrn702v760-passwordsafe-5.0.drv' failed with exit code 1 build of /gnu/store/9l47ki9g4y3xd33kj2l9ilnrn702v760-passwordsafe-5.0.drv failed View build log at '/var/log/guix/drvs/9l/47ki9g4y3xd33kj2l9ilnrn702
bug#52682: installer freezes when ci.guix.gnu.org cannot be reached
Today I got another chance to try the installer. I first used the latest installer image from today (which failed to install Guix because of a test failure) and then fell back to the 1.3.0 installer image. Both installers had the same behavior when it came to accessing ci.guix.gnu.org for substitutes. I ran the installer on a new build node, which cannot access ci.guix.gnu.org through the public IP address. I forgot to add a line to /etc/hosts to resolve ci.guix.gnu.org to the local IP. When I started the installation it would print two lines and then seemingly freeze. There was no timeout either. When the installer is killed and restarted it fails with other errors that I didn’t record. I had to reboot and remember to make the change to /etc/hosts first before starting the installation. -- Ricardo
bug#51787: Disk performance on ci.guix.gnu.org
On +2021-12-20 17:59:33 +0100, Mathieu Othacehe wrote: > > Hey, > > > This is still pretty bad, but better than the <1M performance suggested > > by previous runs. > > Mmh interesting, I also have a x10 speed up on sdb by increasing the > block size from 4k to 512k. I'm not sure what conclusion should we draw > from this observation. > > In particular for our most urging matter, /gnu/store/trash > removal. Moving to a faster hard drive would definitely help here, but I > still don't understand if that disk performance regression comes from > Linux, the file-system fragmentation, or the disk itself. > > >READ: bw=1547MiB/s (1622MB/s), 1547MiB/s-1547MiB/s (1622MB/s-1622MB/s), > > io=3055MiB (3203MB), run=1975-1975msec > > WRITE: bw=527MiB/s (553MB/s), 527MiB/s-527MiB/s (553MB/s-553MB/s), > > io=1042MiB (1092MB), run=1975-1975msec > > Wooh that's fast! On test could be to copy the /gnu/store/trash content > to the SAN an observe how long that it takes for this operating to > complete. also might be interesting to copy to /dev/null to see read rate alone on /gnu/store? > > Thanks for your support on that complex topic :) > > Mathieu > > > -- Regards, Bengt Richter
bug#52520: Multicast is off by default
Hey, > Can we instead use for these purposes? It is already > there, just unused. Mmh, indeed. Well it is already used to create vlan and veth interfaces. What we could do then, is expose the record as a direct equivalent of the Guile-Netlink record. The links list of the record would contain all the links that are managed by Guix. We would require all "device" fields that appear in the records to have their matching link declared. If the link doesn't already exists (vlan, veth type) then link-add is called, otherwise nothing happens. The link existence can be tested using link-name->index. link-set would always be called afterwards to setup link properties. static-networking-shepherd-service would then create on service per link present in the links list. The provisioned name would be (concat 'networking- (network-link-name link)). On tear down, which is equivalent to "herd stop networking-", we would call link-del if the link was created by Guix with link-add, or (link-set ... #:down #t) if the link was already present. I'm not sure how to distinguish between those two cases at this step. This sounds like a complex plan, that will moreover require and adaptation of existing static-networking configurations, but I cannot think of anything easier to fix this issue and the other one I reported. Thanks, Mathieu
bug#52051: [core-updates-frozen] cannot login ('org.freedesktop.login1' service times out)
I am using an X200 Tablet with an HDD. This happened on my system. I am now on Fedora with Guix until this issue is fixed. OpenPGP_0x42E4FDF80F03CA7C.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
bug#52671: glibc patch causes crash on failure to find path to executable
glibc-dl-cache.patch causes segmentation fault when _dl_get_origin fails (which should be harmless unless there is $ORIGIN in RUNPATH). I found this when running a dynamically linked executable as ‘init’, before /proc was mounted. There needs to be an origin != (char *)-1 check.
bug#36389: Nginx and certbot
Hello, I am also experiencing problems with setting up nginx and certbot, but I think it is more nginx that is to blame. After reconfiguring and restarting nginx, it is still running with the old configuration. Only rebooting solves the problem for me. Here is what it looks like (everything as root): $ ps -ef | grep nginx root 2821 1 0 17:03 ?00:00:00 nginx: master process /gnu/store/bdhfqs7sx3mal6pzz8z00hw4cpn5dj7x-nginx-1.21.4/sbin/nginx -c /gnu/store/q7bwm828r8y88sfs395n04bi8s6b7zwl-nginx.conf -p /var/run/nginx $ guix system reconfigure ... nginx: configuration file /gnu/store/clq2yshkq3gxpcqa6d54m8qif8i37kl9-nginx.conf test is successful $ herd restart nginx; ps -ef | grep nginx root 2835 1 0 17:12 ?00:00:00 nginx: master process /gnu/store/bdhfqs7sx3mal6pzz8z00hw4cpn5dj7x-nginx-1.21.4/sbin/nginx -c /gnu/store/q7bwm828r8y88sfs395n04bi8s6b7zwl-nginx.conf -p /var/run/nginx Notice that it is still running the old, q7b... config file! $ reboot $ ps -ef | grep nginx root 188 1 0 17:13 ?00:00:00 nginx: master process /gnu/store/bdhfqs7sx3mal6pzz8z00hw4cpn5dj7x-nginx-1.21.4/sbin/nginx -c /gnu/store/clq2yshkq3gxpcqa6d54m8qif8i37kl9-nginx.conf -p /var/run/nginx Now the new, clq... config file is used! So somehow nginx appears to memorise its previous configuration file even when the service is stopped. The problem can be solved by rebooting after each web server reconfiguration, but this is of course not very comfortable. Andreas
bug#36389: Nginx and certbot
Actually this seems to be a thing of the service, not nginx itself. When I stop the service with the old configuration file, manually run /gnu/store/bdhfqs7sx3mal6pzz8z00hw4cpn5dj7x-nginx-1.21.4/sbin/nginx -p /var/run/nginx -c new_configuration_file kill the process, and "herd restart nginx", the herd service uses the old configuration file again. Andreas
bug#51787: Disk performance on ci.guix.gnu.org
Mathieu Othacehe writes: >> This is still pretty bad, but better than the <1M performance suggested >> by previous runs. > > Mmh interesting, I also have a x10 speed up on sdb by increasing the > block size from 4k to 512k. I'm not sure what conclusion should we draw > from this observation. As a general rule, we want the block size to match that of the configured disk layout — if we care about getting the best numbers in our benchmarks. With real workloads things are always going to be slower anyway. > In particular for our most urging matter, /gnu/store/trash > removal. Moving to a faster hard drive would definitely help here, but I > still don't understand if that disk performance regression comes from > Linux, the file-system fragmentation, or the disk itself. > >>READ: bw=1547MiB/s (1622MB/s), 1547MiB/s-1547MiB/s (1622MB/s-1622MB/s), >> io=3055MiB (3203MB), run=1975-1975msec >> WRITE: bw=527MiB/s (553MB/s), 527MiB/s-527MiB/s (553MB/s-553MB/s), >> io=1042MiB (1092MB), run=1975-1975msec > > Wooh that's fast! On test could be to copy the /gnu/store/trash content > to the SAN an observe how long that it takes for this operating to > complete. Do you mean time the copy or time the removal from that storage? You know what, I’ll time both. I’ll need to get more space first. I think the trash directory is larger than the 500G that I got for testing the SAN. > Thanks for your support on that complex topic :) Hey, I’m just happy neither of us has to do this alone. Thank you! -- Ricardo
bug#51787: Disk performance on ci.guix.gnu.org
Hey, > This is still pretty bad, but better than the <1M performance suggested > by previous runs. Mmh interesting, I also have a x10 speed up on sdb by increasing the block size from 4k to 512k. I'm not sure what conclusion should we draw from this observation. In particular for our most urging matter, /gnu/store/trash removal. Moving to a faster hard drive would definitely help here, but I still don't understand if that disk performance regression comes from Linux, the file-system fragmentation, or the disk itself. >READ: bw=1547MiB/s (1622MB/s), 1547MiB/s-1547MiB/s (1622MB/s-1622MB/s), > io=3055MiB (3203MB), run=1975-1975msec > WRITE: bw=527MiB/s (553MB/s), 527MiB/s-527MiB/s (553MB/s-553MB/s), > io=1042MiB (1092MB), run=1975-1975msec Wooh that's fast! On test could be to copy the /gnu/store/trash content to the SAN an observe how long that it takes for this operating to complete. Thanks for your support on that complex topic :) Mathieu
bug#52551: Supercollider and ableton-link build failure
Hello, Aleksandr Vityazev writes: > On 2021-12-16, 16:37 +, Maxime Devos wrote: > >> Running make with parallelism can mix up the error messages. >> Probably the actual error message is before a lot of >> [$$%] Built target [...] lines. >> I recommend building with "--cores=1" for debugging. > > Thanks, that helped, patches sent to guix-patc...@gnu.org. These were pushed by Ludovic with e874c730eaa369e42cff3b2c2e3599d33a7aceff and 0745c8205a4ef77b6b2f8e004d3c4d6e6e7ddccc. Closing. Thank you! Maxim
bug#52520: Multicast is off by default
Hello, Mathieu Othacehe writes: > Hey, > >> Is it #:multicast-on or #:allmulticast-on ? > > The "ip link set multicast ..." command corresponds to the the > IFF_MULTICAST flag hence to the #:multicast-on parameter. > >> Anyhow, I suggest adding a ‘multicast?’ field to , with >> #t as its default value, and honoring this. > > I'm not sure is the right place for this flag. If > there are two records in the same list, one for ipv4 > and one for ipv6 it means that we need to repeat this flag twice. > > Same for the MTU, having different MTU for ipv4 and ipv6 addresses > doesn't have any meaning. The MTU and multicast properties belong to the > device itself. > > I think we should introduce a record that would gather > the properties that can be passed to the "link-set" method of > Guile-Netlink. The record would point to a unique > . We would remove the device field from > . > > Then each service would provision (concat > 'networking- (network-device-name device)) or something like that, to fix > https://issues.guix.gnu.org/52511 as well. > > How does that sounds? Seems to have it on the network device would be less surprising, indeed :-). It makes sense to me. Thank you, Maxim
bug#52678: sway unable to start Xwayland
On Sun, 19 Dec 2021, Jack Hill wrote: Hi Guix, With Guix 11334d15d590073c631c574436d2110aa1ea2142, sway is not able to start Xwayland. I believe that is was working correctly for me at commit d627fbad8f4e157103251b07d7543dd2f5647cea. Running sway manually from a VT, I was able to capture the following messages: ``` 00:00:00.002 [wlr] [libseat] [libseat/backend/seatd.c:78] Could not connect to socket /run/seatd.sock: No such file or directory 00:00:00.084 [wlr] [xwayland/sockets.c:99] /tmp/.X11-unix not owned by root ``` And, had I thought about the above messages more, I would have looked at the ownership of /tmp/.X11-unix initially. I've now done so and found out that it was owned by gdm. The weird bit is though that I had previously run `herd stop xorg-server` and there were not gdm processes running, and loginctl reported no gdm sessions. Anyways, I don't think the commits above are particularly relevant. I'll go ahead and re-title the issue. Best, Jack
