bug#34884: guix describe fails with --format=json and --format=recutils
Hi,
> Oleg Pykhalov skribis:
>
>> JSON format:
>>
>> oleg@guixsd ~/src/guix$ ./pre-inst-env env
>> GUIX_PACKAGE_PATH=$HOME/src/guix-wigust:/tmp/noexist:/tmp/noexist:/tmp/noexist:/tmp/noexist:/tmp/noexist:/tmp/noexist:/tmp/noexist:/tmp/noexist:/tmp/noexist:/tmp/noexist:/tmp/noexist:/tmp/noexist:/tmp/noexist:/tmp/noexist:/tmp/noexist:/tmp/noexist:/tmp/noexist:/tmp/noexist
>> guix describe -p ~/.config/guix/current --format=json
>> [{"name":"guix","url":"https://gitlab.wugi.info/guix/guix.git","commit":"4161deb4549c39b7d4801cc8aa63c365d19fc649"},{"name":"guix-wigust","url":"https://gitlab.wugi.info/guix/guix-wigust.git","commit":"f6dfa5fc08824ebe5bdc42ea35ff0e040245c8c0"}]
>> {"name":"GUIX_PACKAGE_PATH","paths":["/home/oleg/src/guix-wigust","/tmp/noexist","/tmp/noexist","/tmp/noexist","/tmp/noexist","/tmp/noexist","/tmp/noexist","/tmp/noexist","/tmp/noexist","/tmp/noexist","/tmp/noexist","/tmp/noexist","/tmp/noexist","/tmp/noexist","/tmp/noexist","/tmp/noexist","/tmp/noexist","/tmp/noexist","/tmp/noexist"]}
>
> Initially the intent was to warn users that ‘GUIX_PACKAGE_PATH’ is set
> and not captured in the output of ‘guix describe’, because fundamentally
> it cannot be captured reliably.
>
> Thus, what about something as attached instead?
>
> Thanks,
> Ludo’.
>
> diff --git a/guix/scripts/describe.scm b/guix/scripts/describe.scm
> index 7d0ecb0a4d..b6287d3a4c 100644
> --- a/guix/scripts/describe.scm
> +++ b/guix/scripts/describe.scm
> @@ -1,5 +1,5 @@
> ;;; GNU Guix --- Functional package management for GNU
> -;;; Copyright © 2018 Ludovic Courtès
> +;;; Copyright © 2018, 2019 Ludovic Courtès
> ;;; Copyright © 2018 Oleg Pykhalov
> ;;;
> ;;; This file is part of GNU Guix.
> @@ -85,7 +85,9 @@ Display information about the channels currently in
> use.\n"))
> (format #t "~%GUIX_PACKAGE_PATH=\"~a\"~%" string))
> ('channels
> (format #t (G_ "~%;; warning: GUIX_PACKAGE_PATH=\"~a\"~%")
> -string))
> +string))
> + (_
> +(warning (G_ "'GUIX_PACKAGE_PATH' is set but it is not
> captured~%")))
>
> (define (channel->sexp channel)
>`(channel
This looks good to me!
--
Ricardo
bug#27217: texlive is too big
Hello! Pierre Neidhardt skribis: > Yesterday Jelle and I started getting down to it. > > I've created a wip-texlive branch. For now, we can run > > (texlive-fetch "xcolor") > > and it returns the appropriate parsed entry from the tlpdb from texlive-bin. Nice! > The first call to texlive-fetch takes some 10-30 seconds because the tlpdb is > some 11MB+ big. > > I'm caching the parsed DB, so that should not be a problem during development. You can use ‘http-fetch/cached’, if that’s not what you’re already doing. > I'm suggesting those following steps: > > - Write the package definition generator. We can take inspiration from > opam.scm, it seems to be well written and very similar. > `texlive-fetch' is already aligned with `opam-fetch'. > > For testing, we can try to recreate a simple package definition. > texlive-latex-xcolor for instance. > There is an immediate difference already: the name generated by the importer > will be texlive-xcolor and not texlive-latex-xcolor. > > - Write texlive-fetch so that we can write definitions with multiple > directories. > > - Update the texlive-build-system to accommodate the importer. For instance, > we > will probably have to build fonts automatically. We will also have to be > smart about the files that need to be generated, and those that need to be > discarded. > > - Write an updater (again, following opam.scm, should be trivial). > > I'll get started with the first step today. Let me know what you think! So TeX Live packages would use ‘texlive-fetch’ instead of ‘svn-fetch’ or similar, right? If that’s the case, then merely computing the derivation of one of these would require fetching the tldb database, which would be problematic. Is this correct? Thank you, Ludo’.
bug#34884: guix describe fails with --format=json and --format=recutils
Hi Oleg, Oleg Pykhalov skribis: > Ludovic Courtès writes: > > […] > >> Initially the intent was to warn users that ‘GUIX_PACKAGE_PATH’ is set >> and not captured in the output of ‘guix describe’, because fundamentally >> it cannot be captured reliably. >> >> Thus, what about something as attached instead? > > OK, no problem for me. ;-) Thanks for explanation. Cool, thank you. I’ll push shortly. Ludo’.
bug#34871: bug: failed to compute derivation (possible duplicate)
Hi Platoxia,
Platoxia skribis:
> Throw to key `srfi-34' with args `(# arguments: ("-C" "tests" "test") exit-status: 2 term-signal: #f stop-signal:
> #f] 491dc0>)'.
> builder for `/gnu/store/k5h4iz2hm48rc145x5fy49dnh3230iac-curl-7.63.0.drv'
> failed with exit code 1
> @ build-failed /gnu/store/k5h4iz2hm48rc145x5fy49dnh3230iac-curl-7.63.0.drv -
> 1 builder for `/gnu/store/k5h4iz2hm48
[...]
> Throw to key `srfi-34' with args `(# [message: "build of
> `/gnu/store/13v1z6zyn412m2r3lb1n61xx4jjhag31-git-minimal-2.21.0.drv' failed"
> status: 100] 6f0a5d0>)'.
> guix pull: error: You found a bug: the program
> '/gnu/store/qhxsq8wk7nysfys9a3n8jbcz838yx1aa-compute-guix-derivation'
> failed to compute the derivation for Guix (version:
> "ce32ce70475254bd5686f8ca77048127037bc87d"; system: "x86_64-linux";
> host version: "14bba460abe1704ef7c02fb144c047ca0c8b821f"; pull-version: 1).
> Please report it by email to .
An indirect dependency of Guix, cURL in this case, failed to build.
The binary for this cURL is available on ci.guix.info, though.
Did you enable substitutes from ? See
and related pages.
Thanks,
Ludo’.
bug#34897: System reconfigure error
Hi, mikadoZero skribis: > Danny Milosavljevic writes: > >> The gettext package is named "gnu-gettext". Modify your "packages" field. > > Thank you. Changing "gettext" to "gnu-gettext" got it working. > > In this case package search seems to be misleading. `guix package -s > gnu-gettext` returns nothing. While in the return of `guix package -s > gettext` there is a package with the name of "gettext" that talks about > gnu gettext in it's description. The name that “guix package -s” shows is the package name. ‘gnu-gettext’, conversely, is the name of the variable bound to that package. In your config file, you can use ‘specifications->manifest’ as documented in the manual if you’d rather avoid dealing with variables. HTH! Ludo’.
bug#34861: TLS Error with Flatpak
Hello, "Raghav Gururajan" skribis: > Whenever I try "flatpak remote-add --if-not-exists flathub > https://flathub.org/repo/flathub.flatpakrepo";; I keep getting the error > "Can't load uri https://flathub.org/repo/flathub.flatpakrepo: TLS support is > not available". > > I even tried following steps mentioned at > https://www.gnu.org/software/guix/manual/en/guix.html#index-TLS. Still not > working. To be more specific, did you install ‘nss-certs’? If you did is it installed system-wide in /etc/ssl/certs, or per-user? Did you set ‘SSL_CERT_DIR’, ‘SSL_CERT_FILE’, or related environment variables? Thanks, Ludo’.
bug#34902: guix cannot find a module on boot
Hi! I've installed the Guix system on my cubietruck yesterday, but had some difficulties. At first, the root partition was not available at boot, so I got a repl with a message saying that /dev/mmcblk0p1 was not available. I added the following to my guix config file: (initrd-modules (cons "sunxi_mmc" %base-initrd-modules)) although the guix system command worked, the produced system still couldn't boot, but this time the message was that guix was unable to find sunxi_mmc.ko. Using the repl I could confirm that this module was indeed here, but under the name sunxi-mmc.ko. Using load-linux-module*, I was able to confirm that loading it made the filesystem available in /dev. In the end this line: (initrd-modules (cons "sunxi-mmc" %base-initrd-modules)) was the right line to add, and I could properly boot my cubietruck! The bug here is that guix should either be smarter and load sunxi-mmc.ko when it can't find sunxi_mmc.ko, or not allow me to build a system when I specify sunxi_mmc since it doesn't exist at boot time.
bug#34333: Docker daemon failing to start on boot
Hi Danny.
Danny Milosavljevic writes:
> Hi Allan,
>
> On Mon, 11 Mar 2019 09:59:19 +0100
> Allan Adair wrote:
>
>> Sorry for the late response. I was offline for the last week or so.
>
> No problem!
>
>>
>> I ended up having to repeat the first command with sudo
>> privileges. Please see below.
>
> Yes, so that looks as if it works fine. What's the difference to a failed
> start by herd (log file in /var/log/docker.log) ?
I have never actually been able to start the dockerd service using herd
explicitly. After booting:
allana@guixsd ~$ docker ps
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the
docker daemon running?
allana@guixsd ~$ cat /var/log/docker.log
time="2019-03-18T10:23:30.462181353+01:00" level=warning msg="Error while
setting daemon root propagation, this is not generally critical but may cause
some functionality to not work or fallback to less desirable behavior"
dir=/var/lib/docker error="error writing file to signal mount cleanup on
shutdown: open /var/run/docker/unmount-on-shutdown: no such file or directory"
time="2019-03-18T10:23:30.46519+01:00" level=info msg="parsed scheme:
\"unix\"" module=grpc
time="2019-03-18T10:23:30.466019010+01:00" level=info msg="scheme \"unix\" not
registered, fallback to default scheme" module=grpc
time="2019-03-18T10:23:30.466291192+01:00" level=info msg="ccResolverWrapper:
sending new addresses to cc: [{unix:///run/containerd/containerd.sock 0
}]" module=grpc
time="2019-03-18T10:23:30.466315303+01:00" level=info msg="ClientConn switching
balancer to \"pick_first\"" module=grpc
time="2019-03-18T10:23:30.466349982+01:00" level=info msg="pickfirstBalancer:
HandleSubConnStateChange: 0xc00012d090, CONNECTING" module=grpc
time="2019-03-18T10:23:30.46736+01:00" level=info msg="pickfirstBalancer:
HandleSubConnStateChange: 0xc00012d090, READY" module=grpc
time="2019-03-18T10:23:30.467531354+01:00" level=info msg="parsed scheme:
\"unix\"" module=grpc
time="2019-03-18T10:23:30.467544289+01:00" level=info msg="scheme \"unix\" not
registered, fallback to default scheme" module=grpc
time="2019-03-18T10:23:30.467972429+01:00" level=info msg="ccResolverWrapper:
sending new addresses to cc: [{unix:///run/containerd/containerd.sock 0
}]" module=grpc
time="2019-03-18T10:23:30.467991848+01:00" level=info msg="ClientConn switching
balancer to \"pick_first\"" module=grpc
time="2019-03-18T10:23:30.468161326+01:00" level=info msg="pickfirstBalancer:
HandleSubConnStateChange: 0xc00012d380, CONNECTING" module=grpc
time="2019-03-18T10:23:30.468444097+01:00" level=info msg="pickfirstBalancer:
HandleSubConnStateChange: 0xc00012d380, READY" module=grpc
time="2019-03-18T10:23:30.471722313+01:00" level=error msg="'overlay' not found
as a supported filesystem on this host. Please ensure kernel is new enough and
has overlay support loaded." storage-driver=overlay2
time="2019-03-18T10:23:30.471762928+01:00" level=error msg="[graphdriver] prior
storage driver overlay2 failed: driver not supported"
Error starting daemon: error initializing graphdriver: driver not supported
The service does start after a guix system reconfigure:
allana@guixsd ~$ sudo guix system reconfigure /etc/config.scm > /dev/null 2>&1
Password:
allana@guixsd ~$ docker ps
CONTAINER IDIMAGE COMMAND CREATED
STATUS PORTS NAMES
allana@guixsd ~$ cat /var/log/docker.log
time="2019-03-18T11:04:08.548958068+01:00" level=info msg="parsed scheme:
\"unix\"" module=grpc
time="2019-03-18T11:04:08.549060661+01:00" level=info msg="scheme \"unix\" not
registered, fallback to default scheme" module=grpc
time="2019-03-18T11:04:08.549129691+01:00" level=info msg="parsed scheme:
\"unix\"" module=grpc
time="2019-03-18T11:04:08.549145165+01:00" level=info msg="scheme \"unix\" not
registered, fallback to default scheme" module=grpc
time="2019-03-18T11:04:08.549194625+01:00" level=info msg="ccResolverWrapper:
sending new addresses to cc: [{unix:///run/containerd/containerd.sock 0
}]" module=grpc
time="2019-03-18T11:04:08.549225327+01:00" level=info msg="ClientConn switching
balancer to \"pick_first\"" module=grpc
time="2019-03-18T11:04:08.549295334+01:00" level=info msg="pickfirstBalancer:
HandleSubConnStateChange: 0xc0007c8730, CONNECTING" module=grpc
time="2019-03-18T11:04:08.549428581+01:00" level=info msg="pickfirstBalancer:
HandleSubConnStateChange: 0xc0007c8730, READY" module=grpc
time="2019-03-18T11:04:08.549823791+01:00" level=info msg="ccResolverWrapper:
sending new addresses to cc: [{unix:///run/containerd/containerd.sock 0
}]" module=grpc
time="2019-03-18T11:04:08.549852586+01:00" level=info msg="ClientConn switching
balancer to \"pick_first\"" module=grpc
time="2019-03-18T11:04:08.549895079+01:00" level=info msg="pickfirstBalancer:
HandleSubConnStateChange: 0xc00048c190, CONNECTING" module=grpc
time="2019-03-18T11:04:08.550230781+01:00" level=info msg="pickfirstBalancer:
HandleSub
bug#34333: Docker daemon failing to start on boot
Hi Allan,
thanks for the logs!
I've found the problem now.
daemon/graphdriver/overlay2/overlay.go:
func supportsOverlay() error {
// We can try to modprobe overlay first before looking at
// proc/filesystems for when overlay is supported
exec.Command("modprobe", "overlay").Run()
f, err := os.Open("/proc/filesystems")
if err != nil {
return err
}
defer f.Close()
s := bufio.NewScanner(f)
for s.Scan() {
if s.Text() == "nodev\toverlay" {
return nil
}
}
logrus.WithField("storage-driver", "overlay2").Error("'overlay' not
found as a supported filesystem on this host. Please ensure kernel is new
enough and has overlay support loaded.")
return graphdriver.ErrNotSupported
}
We don't load "overlay" explicitly. The above is some weird
contraption--loading kernel modules from random user space programs. Seriously?
And I suspect that modprobe is not found in your system profile.
As a workaround, try adding "kmod" to the list of packages in your
operating-system in your system configuration and reconfigure.
But the real fix is for Docker to stop doing this weird thing in the first
place. Nowadays, modules are autoloaded when someone is accessing the thing
(by udev, or just by using it etc).
In this case, they do
if err := mount("overlay", mountTarget, "overlay", 0, mountData); err
!= nil {
later on. And that's how it should have been detecting it, too.
pgp8j008cpYps.pgp
Description: OpenPGP digital signature
bug#34333: Docker daemon failing to start on boot
For our own reference: # lsmod |grep overlay # mkdir -p /b # mount -t overlay none /b mount: /b: wrong fs type, bad option, bad superblock on /a, missing codepage or helper program, or other error. # lsmod |grep overlay overlay 110592 0 pgpaqHWkkR0Wf.pgp Description: OpenPGP digital signature
bug#34333: Docker daemon failing to start on boot
Hi Danny. With great excitement I edited my config.scm to include kmod,
ran guix system reconfigure, and rebooted my machine. Unfortunately my
changes did not seem to fix the issue. I hope the session below can help
us further. Thanks so much for working on this issue.
allana@guixsd ~$ docker ps
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the
docker daemon running?
allana@guixsd ~$ cat /var/log/docker.log
time="2019-03-18T14:39:59.788932321+01:00" level=warning msg="Error while
setting daemon root propagation, this is not generally critical but may cause
some functionality to not work or fallback to less desirable behavior"
dir=/var/lib/docker error="error writing file to signal mount cleanup on
shutdown: open /var/run/docker/unmount-on-shutdown: no such file or directory"
time="2019-03-18T14:39:59.797964377+01:00" level=info msg="parsed scheme:
\"unix\"" module=grpc
time="2019-03-18T14:39:59.797982675+01:00" level=info msg="scheme \"unix\" not
registered, fallback to default scheme" module=grpc
time="2019-03-18T14:39:59.798127164+01:00" level=info msg="ccResolverWrapper:
sending new addresses to cc: [{unix:///run/containerd/containerd.sock 0
}]" module=grpc
time="2019-03-18T14:39:59.798220831+01:00" level=info msg="ClientConn switching
balancer to \"pick_first\"" module=grpc
time="2019-03-18T14:39:59.798291248+01:00" level=info msg="pickfirstBalancer:
HandleSubConnStateChange: 0xc000771980, CONNECTING" module=grpc
time="2019-03-18T14:39:59.800603937+01:00" level=info msg="pickfirstBalancer:
HandleSubConnStateChange: 0xc000771980, READY" module=grpc
time="2019-03-18T14:39:59.801234292+01:00" level=info msg="parsed scheme:
\"unix\"" module=grpc
time="2019-03-18T14:39:59.801254794+01:00" level=info msg="scheme \"unix\" not
registered, fallback to default scheme" module=grpc
time="2019-03-18T14:39:59.801329244+01:00" level=info msg="ccResolverWrapper:
sending new addresses to cc: [{unix:///run/containerd/containerd.sock 0
}]" module=grpc
time="2019-03-18T14:39:59.801366954+01:00" level=info msg="ClientConn switching
balancer to \"pick_first\"" module=grpc
time="2019-03-18T14:39:59.801507445+01:00" level=info msg="pickfirstBalancer:
HandleSubConnStateChange: 0xcd79d0, CONNECTING" module=grpc
time="2019-03-18T14:39:59.802331100+01:00" level=info msg="pickfirstBalancer:
HandleSubConnStateChange: 0xcd79d0, READY" module=grpc
time="2019-03-18T14:39:59.815614194+01:00" level=error msg="'overlay' not found
as a supported filesystem on this host. Please ensure kernel is new enough and
has overlay support loaded." storage-driver=overlay2
time="2019-03-18T14:39:59.815664314+01:00" level=error msg="[graphdriver] prior
storage driver overlay2 failed: driver not supported"
Error starting daemon: error initializing graphdriver: driver not supported
allana@guixsd ~$ cat /etc/config.scm
(use-modules (gnu)
(gnu system nss)
(gnu services))
(use-service-modules desktop docker)
(use-package-modules certs gnome linux)
(operating-system
(host-name "guixsd")
(timezone "Europe/Oslo")
(locale "en_US.utf8")
(bootloader (bootloader-configuration
(bootloader grub-bootloader)
(target "/dev/sda")))
(file-systems (cons (file-system
(device (file-system-label "my-root"))
(mount-point "/")
(type "ext4"))
%base-file-systems))
(users (cons (user-account
(name "allana")
(group "users")
(supplementary-groups '("wheel"
"docker"
"netdev"
"audio"
"video"))
(home-directory "/home/allana"))
%base-user-accounts))
;; This is where we specify system-wide packages.
(packages (cons* nss-certs ;for HTTPS access
gvfs ;for user mounts
kmod ;for modprobe/dockerd
%base-packages))
(services (cons* (console-keymap-service "no-latin1")
(gnome-desktop-service)
(service docker-service-type)
%desktop-services))
;; Allow resolution of '.local' host names with mDNS.
(name-service-switch %mdns-host-lookup-nss))
allana@guixsd ~$ sudo herd start dockerd
Password:
Service dockerd could not be started.
herd: failed to start service dockerd
allana@guixsd ~$ sudo guix system reconfigure /etc/config.scm > /dev/null 2>&1
allana@guixsd ~$ docker ps
CONTAINER IDIMAGE COMMAND CREATED
STATUS PORTS NAMES
allana@guixsd ~$ cat /var/log/docker.log
time="2019-03-18T14:43:00.850449641+01:00" level=info msg="parsed scheme:
\"unix\"" module=grpc
time="2019-03-18T14:43:00.850524161+01:00" level=info msg="
bug#34896: Add "game" to end of synopsis of openttd
Done as 4cb0b5bfd784a314a97172e93c19b8c4493caf98 signature.asc Description: PGP signature
bug#34861: TLS Error with Flatpak
Hello Ludovic! Yes, I did them. Still did not work. I did the following to set env variables: $ guix package -i nss-certs $ export SSL_CERT_DIR="$HOME/.guix-profile/etc/ssl/certs" $ export SSL_CERT_FILE="$HOME/.guix-profile/etc/ssl/certs/ca-certificates.crt" $ export GIT_SSL_CAINFO="$SSL_CERT_FILE" Regards, RG. March 18, 2019 9:49 AM, "Ludovic Courtès" wrote: > Hello, > > "Raghav Gururajan" skribis: > >> Whenever I try "flatpak remote-add --if-not-exists flathub >> https://flathub.org/repo/flathub.flatpakrepo";; I keep getting the error >> "Can't load uri >> https://flathub.org/repo/flathub.flatpakrepo: TLS support is not available". >> >> I even tried following steps mentioned at >> https://www.gnu.org/software/guix/manual/en/guix.html#index-TLS. Still not >> working. > > To be more specific, did you install ‘nss-certs’? > > If you did is it installed system-wide in /etc/ssl/certs, or per-user? > > Did you set ‘SSL_CERT_DIR’, ‘SSL_CERT_FILE’, or related environment > variables? > > Thanks, > Ludo’.
bug#34897: System reconfigure error
Ludovic Courtès writes: > ... > > The name that “guix package -s” shows is the package name. > ‘gnu-gettext’, conversely, is the name of the variable bound to that > package. > > In your config file, you can use ‘specifications->manifest’ as > documented in the manual if you’d rather avoid dealing with variables. > > ... Thank you for pointing this out. I have reread the relevant section of "4.2 Invoking ‘guix package’" of the manual. I have recently started using it in user manifests. I will try using this further.
bug#34886: [Web page] Screenshot alignment (and listing?)
El 17/03/19 a las 10:48 a. m., Tobias Geerinckx-Rice escribió: Ludo', Ludovic Courtès wrote: Tobias Geerinckx-Rice skribis: The full-sized screenshots at https://www.gnu.org/software/guix/screenshots/gnome/ look awkwardly left-aligned to me[0]. Is this intentional? A browser bug? This is in Icecat 60.5.1 on Guix System. The problem is that this secreenshot that I added a couple of days ago has a ratio of 4/3 instead of 16/9 (I think?). While true (I noticed that too), that's not the problem here. The image above is 16:something, but still isn't centred. And even so, … Alternately, or in addition to that, it’d be great if the web site would automatically do the right thing regardless of the aspect ratio of the screenshot. WDYT, sirgazil? …my thoughts exactly :-) Kind regards, T G-R I pushed a fix for this. See: https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/commit/?id=5135c9082f0122912dcd5206f62c555b8b62be34 -- Luis Felipe López Acevedo http://sirgazil.bitbucket.io/
bug#34907: Go compiler refers to multiple versions of GCC
As seen in this example, the Go compilers are keeping references to both GCC 5 and 6, which seems wrong: -- $ guix gc --references $(guix build --no-grafts go) /gnu/store/dna8kpb00kq176rz8x69yy4j33my2q55-perl-5.28.0 /gnu/store/5s2nib1lrd2101bbrivcl17kjx1mspw6-coreutils-8.30 /gnu/store/9mb1npi8xg8yi0swjf91p5n1qn3n315v-go-1.11.5 /gnu/store/dna8kpb00kq176rz8x69yy4j33my2q55-perl-5.28.0 /gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28 /gnu/store/izyk3kppj42pa8i2cq29bw3bnr1607ps-tzdata-2018i /gnu/store/n2p1zs14y89lwkg9da68y12pc10c6sw9-gcc-5.5.0 /gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23 /gnu/store/sj8m05bfj2902h67c4qkmvnzg2pjdgsv-net-base-5.3 /gnu/store/ypiv8dj4lkvsnm82s639h18l87frrh5g-gcc-6.5.0-lib /gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23 -- This is because libgcc 6 is specifically included in the Go dependencies, but parts of GCC 5 come from gnu-build-system by default. We should make the Go compilers use a single GCC version.
bug#34777: Online package list is 3 weeks stale, but claims recent update
Hello Mark, Mark H Weaver skribis: > As I write this, our online package list claims to have been updated 2 > days ago, but in fact the entries I checked are over 3 weeks stale. The > main package list page includes the text "(updated March 4, 2019)" near > the top of the page: > > https://www.gnu.org/software/guix/packages/ > > However, the entries for "linux-libre" shows the most recent kernel as > version 4.20.7, although we updated to 4.20.8 on February 13: > > https://www.gnu.org/software/guix/packages/L/page/5/ I believe this is fixed by the update I made a couple of days ago. Perhaps what happened is that, for the previous update, “haunt build” ended up using the user’s (gnu packages …) modules that happened to be in the load path, and those were outdated. I usually run: ~/src/guix/pre-inst-env haunt build precisely so the web site gets to see the current package set, but it’s easy to forget that. An option would be to have the web site get data from an inferior, perhaps from ~/.config/guix/current, assuming it’s reasonably up to date (alternately the web site could build the latest Guix from master but that’d be inconvenient.) Anyway, closing! Ludo’.
bug#34902: guix cannot find a module on boot
Hi Julien, Julien Lepiller skribis: > I've installed the Guix system on my cubietruck yesterday, but had > some difficulties. At first, the root partition was not available at > boot, so I got a repl with a message saying that /dev/mmcblk0p1 was > not available. I added the following to my guix config file: > > (initrd-modules (cons "sunxi_mmc" %base-initrd-modules)) Didn’t ‘guix system init’ suggest adding this module? Could it be that this module was actually built-in in the kernel you booted? > although the guix system command worked, the produced system still > couldn't boot, but this time the message was that guix was unable to > find sunxi_mmc.ko. Using the repl I could confirm that this module was > indeed here, but under the name sunxi-mmc.ko. Using > load-linux-module*, I was able to confirm that loading it made the > filesystem available in /dev. In the end this line: > > (initrd-modules (cons "sunxi-mmc" %base-initrd-modules)) > > was the right line to add, and I could properly boot my cubietruck! Phewww. > The bug here is that guix should either be smarter and load > sunxi-mmc.ko when it can't find sunxi_mmc.ko, or not allow me to build > a system when I specify sunxi_mmc since it doesn't exist at boot time. This underscore vs. hyphen thing is terrible. In commit fcd068e984078ab74c6842af2525bf88096cd262 we fixed the initrd builder so it would try both file underscore and hyphen. But now I suppose we need to do the same in ‘load-linux-module*’? Thanks, Ludo’.
bug#34861: TLS Error with Flatpak
Raghav Gururajan writes: > Yes, I did them. Still did not work. > > I did the following to set env variables: > > $ guix package -i nss-certs > $ export SSL_CERT_DIR="$HOME/.guix-profile/etc/ssl/certs" > $ export SSL_CERT_FILE="$HOME/.guix-profile/etc/ssl/certs/ca-certificates.crt" > $ export GIT_SSL_CAINFO="$SSL_CERT_FILE" Flatpak uses libsoup with SOUP_SESSION_SSL_USE_SYSTEM_CA_FILE. libsoup delegates TLS handling to glib-networking. Raghav, could you trace flatpak to see what certificate files it is trying to access? -- Ricardo
bug#34902: guix cannot find a module on boot
Le Mon, 18 Mar 2019 21:42:29 +0100, Ludovic Courtès a écrit : > Hi Julien, > > Julien Lepiller skribis: > > > I've installed the Guix system on my cubietruck yesterday, but had > > some difficulties. At first, the root partition was not available at > > boot, so I got a repl with a message saying that /dev/mmcblk0p1 was > > not available. I added the following to my guix config file: > > > > (initrd-modules (cons "sunxi_mmc" %base-initrd-modules)) > > Didn’t ‘guix system init’ suggest adding this module? Could it be > that this module was actually built-in in the kernel you booted? I couldn't find it in the output of lsmod, so I think it was builtin. > > > although the guix system command worked, the produced system still > > couldn't boot, but this time the message was that guix was unable to > > find sunxi_mmc.ko. Using the repl I could confirm that this module > > was indeed here, but under the name sunxi-mmc.ko. Using > > load-linux-module*, I was able to confirm that loading it made the > > filesystem available in /dev. In the end this line: > > > > (initrd-modules (cons "sunxi-mmc" %base-initrd-modules)) > > > > was the right line to add, and I could properly boot my > > cubietruck! > > Phewww. > > > The bug here is that guix should either be smarter and load > > sunxi-mmc.ko when it can't find sunxi_mmc.ko, or not allow me to > > build a system when I specify sunxi_mmc since it doesn't exist at > > boot time. > > This underscore vs. hyphen thing is terrible. > > In commit fcd068e984078ab74c6842af2525bf88096cd262 we fixed the initrd > builder so it would try both file underscore and hyphen. > > But now I suppose we need to do the same in ‘load-linux-module*’? I guess so :) > > Thanks, > Ludo’.
bug#34902: guix cannot find a module on boot
> This underscore vs. hyphen thing is terrible.
Yeah. But looking at kmod, it doesn't seem to be so bad for them.
They basically always use the version with underscores as the lookup
key for their internal hash tables.
For alias resolving, they use a resolver for [a-zxxx] AND they replace
dashes THAT ARE NOT IN THE "[...]" block by underscore before using it
for lookups.
modules.dep entries are always file names (no replacements whatsoever).
When a module is loaded as a result of an alias lookup, it has a special
key (string-append name "\" target-alias). No idea what that's for.
I'd caution about complicating our version overly much by putting
just-in-case replacements everywhere. Rather we should find out what
their original strategy is (if any :P) and do that as well.
Module aliases (the alias itself, not what it's resolved to) sometimes look
like that:
./arch/x86/crypto/des3_ede_glue.c:MODULE_ALIAS_CRYPTO("des3_ede-asm");
WTF...
But the thing the alias is resolved to is always the modname (which
has hyphens replaced by underscore and stops before a dot).
Their bin files (we don't use them) always have the final modname as key,
as opposed to their source files (for example "modules.alias" rather
than "modules.alias.bin"). (The source files sometimes have paths as key)
I think that they assume that each module, whether it has dependencies or
not, is listed in modules.dep . They use modules.dep.bin for the lookup
of a module by modname, rather than by path.
So I think a pretty good fix is:
Every time we want to lookup a module by modname, check a hashtable that
is built from modules.dep by:
* let x-path be the first value of each modules.dep line.
* Then the key for the hashtable entry is (underscore (stop-at-dot (basename
x-path)))
* And the value for the hashtable entry is x-path.
In this way we would look up modules in a way similar to them.
Why they couldn't just have used file names without mangling them beats me.
Sigh...
pgpXqrJTKcQ4F.pgp
Description: OpenPGP digital signature
bug#34861: TLS Error with Flatpak
Hello Ricardo!
Please find the following information.
FROM FLATPAK SOURECODE:
SoupSession *
flatpak_create_soup_session (const char *user_agent)
{
SoupSession *soup_session;
const char *http_proxy;
soup_session = soup_session_new_with_options (SOUP_SESSION_USER_AGENT,
user_agent,
SOUP_SESSION_SSL_USE_SYSTEM_CA_FILE, TRUE,
SOUP_SESSION_USE_THREAD_CONTEXT, TRUE,
SOUP_SESSION_TIMEOUT, 60,
SOUP_SESSION_IDLE_TIMEOUT, 60,
NULL);
soup_session_remove_feature_by_type (soup_session, SOUP_TYPE_CONTENT_DECODER);
http_proxy = g_getenv ("http_proxy");
if (http_proxy)
{
g_autoptr(SoupURI) proxy_uri = soup_uri_new (http_proxy);
if (!proxy_uri)
g_warning ("Invalid proxy URI '%s'", http_proxy);
else
g_object_set (soup_session, SOUP_SESSION_PROXY_URI, proxy_uri, NULL);
}
if (g_getenv ("OSTREE_DEBUG_HTTP"))
soup_session_add_feature (soup_session, (SoupSessionFeature *) soup_logger_new
(SOUP_LOGGER_LOG_BODY, 500));
return soup_session;
}
FROM LIBSOUP MANUAL:
The “ssl-use-system-ca-file” property
“ssl-use-system-ca-file” gboolean
Setting this to TRUE is equivalent to setting “tls-database” to the default
system CA database. (and likewise, setting “tls-database” to the default
database by hand will cause this property to become TRUE).
Setting this to FALSE (when it was previously TRUE) will clear the
“tls-database” field.
See “ssl-strict” for more information on how https certificate validation is
handled.
The “ssl-strict” property
“ssl-strict” gboolean
Normally, if “tls-database” is set (including if it was set via
“ssl-use-system-ca-file” or “ssl-ca-file”), then libsoup will reject any
certificate that is invalid (ie, expired) or that is not signed by one of the
given CA certificates, and the SoupMessage will fail with the status
SOUP_STATUS_SSL_FAILED.
If you set “ssl-strict” to FALSE, then all certificates will be accepted, and
you will need to call soup_message_get_https_status() to distinguish valid from
invalid certificates. (This can be used, eg, if you want to accept invalid
certificates after giving some sort of warning.)
For a plain SoupSession, if the session has no CA file or TLS database, and
this property is TRUE, then all certificates will be rejected.
--
Regards,
RG.
March 18, 2019 9:24 PM, "Ricardo Wurmus" mailto:rek...@elephly.net)> wrote:
Raghav Gururajan mailto:r...@disroot.org)> writes:
Yes, I did them. Still did not work.
I did the following to set env variables:
$ guix package -i nss-certs
$ export SSL_CERT_DIR="$HOME/.guix-profile/etc/ssl/certs"
$ export SSL_CERT_FILE="$HOME/.guix-profile/etc/ssl/certs/ca-certificates.crt"
$ export GIT_SSL_CAINFO="$SSL_CERT_FILE"
Flatpak uses libsoup with SOUP_SESSION_SSL_USE_SYSTEM_CA_FILE. libsoup
delegates TLS handling to glib-networking.
Raghav, could you trace flatpak to see what certificate files it is
trying to access?
--
Ricardo
bug#34861: TLS Error with Flatpak
Hi Ricardo! Please find the log at: https://bin.disroot.org/?597e32cb7e42e40e#r9lqwZ6w7sIAWlY2mt6dsgKCKRO5q0ZVt9U69vnZVZs= Thank you! Regards, RG. March 19, 2019 12:22 AM, "Ricardo Wurmus" wrote: > Hi Raghav, > >> Please find the following information. […] > > Unfortunately, this is not very helpful as it only shows that flatpak > uses libsoup. > >> Raghav, could you trace flatpak to see what certificate files it is >> trying to access? > > I meant: could you run the flatpak command with “strace -f -o log -s > 2048 flatpak …”? This would show us what files it attempts to access, > hopefully including certificate files. > > -- > Ricardo
bug#34861: TLS Error with Flatpak
Hi Raghav, > Please find the following information. […] Unfortunately, this is not very helpful as it only shows that flatpak uses libsoup. > Raghav, could you trace flatpak to see what certificate files it is > trying to access? I meant: could you run the flatpak command with “strace -f -o log -s 2048 flatpak …”? This would show us what files it attempts to access, hopefully including certificate files. -- Ricardo
