bug#34454: Gtk upstream bug #1280 causes crashes in IceCat and Emacs

Hi Carlo, Carlo Zancanaro writes: > Thanks so much for taking a look at this! > > On Sat, Mar 30 2019, Mark H Weaver wrote: >> If those affected by this issue would like to test this patch and >> report back, that would be helpful. > > I applied your patch to my lo

bug#35010: Many CPAN download URLs are no longer available

Hi Tobias, There are still at least two more bad URLs from this batch of perl updates circa March 23rd: mirror://cpan/authors/id/A/AB/ABW/Template-Toolkit-2.28.tar.gz mirror://cpan/authors/id/M/MA/MAKAMAKA/Text-CSV-1.99.tar.gz Could you take a look? Thanks, Mark

bug#35181: Hydra offloads often get stuck while exporting build requisites

It has become extremely frequent for builds offloaded by hydra.gnu.org to its x86 build slave hydra.gnunet.org to get stuck indefinitely while exporting prerequisites for the build to the build slave. As I write this, both of hydra.gnunet.org's build slots (one for x86_64-linux, and one for i686-l

bug#35181: Hydra offloads often get stuck while exporting build requisites

I wrote earlier: > It has become extremely frequent for builds offloaded by hydra.gnu.org > to its x86 build slave hydra.gnunet.org to get stuck indefinitely while > exporting prerequisites for the build to the build slave. > > As I write this, both of hydra.gnunet.org's build slots (one for > x8

bug#35181: Hydra offloads often get stuck while exporting build requisites

Hi Efraim, Efraim Flashner writes: > For these two specifically it's possible that they are just really > really big. The source checkout currently being transferred for build 3432472 (/gnu/store/…-font-google-material-design-icons-3.0.1-checkout) is 176 megabytes uncompressed, as measured by "d

bug#35181: Hydra offloads often get stuck while exporting build requisites

The same jobs that are consistently getting stuck offloading to hydra.gnunet.org (Hydra's only functional x86 build slave at present) built successfully on armhf, with build times of 1-2 hours. With only one x86 build slave and all armhf build slaves on the same network and running the same ancien

bug#35190: Hydra unable to new create evaluations of master

Hydra's latest attempt to evaluate 'master' failed. Here's the tail of the evaluation log: --8<---cut here---start->8--- building path(s) `/gnu/store/103icyz4q7crjxbh71k3vbill3kzjm9n-profile' Backtrace: 7 (apply-smob/1 #) In ice-9/boot-9.scm: 705

bug#35181: Hydra offloads often get stuck while exporting build requisites

Hi Ludovic, Ludovic Courtès writes: > Mark H Weaver skribis: > >> The source checkout currently being transferred for build 3432472 >> (/gnu/store/…-font-google-material-design-icons-3.0.1-checkout) is 176 >> megabytes uncompressed, as measured by "du -s --si&quo

bug#35181: Hydra offloads often get stuck while exporting build requisites

merge 35181 34157 thanks I looked more closely at the 'mozjs-60' failures, and I'm convinced that it's an instance of the same problem that's currently affecting these large font builds. Mozjs-60 was pushed to the master branch on 2019-01-18. It has _never_ successfully built on x86_64 or i686,

bug#35181: Hydra offloads often get stuck while exporting build requisites

Hi Ludovic, Ludovic Courtès writes: > The problem is that this is an ancient Guix. In the meantime, > offloading has seen relevant changes, in particular things like commit > ed7b44370f71126087eb953f36aad8dc4c44109f which address stability issues > with Guile-SSH (ssh dist node) that was previo

bug#35232: webkitgtk-2.24.1 fails to build on i686, but earlier versions work

Hydra failed to build webkitgtk-2.24.1 on i686-linux, saying "SSE2 support is required to compile WebKit". https://hydra.gnu.org/build/3439652 See below for the tail of the build log. Note that earlier versions of webkitgtk built successfully on i686-linux, including 2.24.0: https://hydra.g

bug#35350: Some compile output still leaks through with --verbosity=1

Sometimes when compiling a package with --verbosity=1, some parts of the compile output leak through. For example, see the transcript below. Mark --8<---cut here---start->8--- mhw@jojen ~$ guix system build /etc/config.scm --verbosity=1 --keep-failed

bug#35350: Some compile output still leaks through with --verbosity=1

Hi Ludovic, Ludovic Courtès writes: > Mark H Weaver skribis: > >> Sometimes when compiling a package with --verbosity=1, some parts of the >> compile output leak through. For example, see the transcript below. > > Weird. FWIW, a few observations, possibly relevant:

bug#35350: Some compile output still leaks through with --verbosity=1

> What’s the value of --max-jobs? max-jobs is 1. Please disregard my previous response. Thanks, Mark

bug#34124: 01/01: gnu: gnome-shell: Add gdk-pixbuf+svg to inputs.

Hi Ricardo, Ricardo Wurmus writes: guix-comm...@gnu.org writes: > commit cd8dce8ac4224d425f13b3c0776884c87ff43562 > Author: Ricardo Wurmus > Date: Thu Apr 25 15:17:05 2019 +0200 > > gnu: gnome-shell: Add gdk-pixbuf+svg to inputs. > > Fixes . > >

bug#35350: Some compile output still leaks through with --verbosity=1

substitution character in case of errors, but I intend to eventually support other error modes as well. What would you think about using this code to replace the uses of 'read-maybe-utf8-string', and storing the UTF-8 decoder state in the object? Would we need to store multiple stat

bug#35350: Some compile output still leaks through with --verbosity=1

Here's an improved version of the code with doc strings. It also properly handles the case of (target-source >= target-end) in 'utf8->string!'. Mark ;;; Copyright © 2019 Mark H Weaver ;;; ;;; This program is free software: you can redistribute it and/or modify ;;;

bug#35350: Some compile output still leaks through with --verbosity=1

Here's version 3 with much more precise specifications in the docstrings. If I recall correctly, the code itself is identical to version 2. Mark ;;; Copyright © 2019 Mark H Weaver ;;; ;;; This program is free software: you can redistribute it and/or modify ;;; it under the terms o

bug#35350: Some compile output still leaks through with --verbosity=1

Hi Ludovic, Ludovic Courtès writes: > Mark H Weaver skribis: > >> Ludovic Courtès writes: >> >>> The third read(2) call here ends on a partial UTF-8 sequence for LEFT >>> SINGLE QUOTATION MARK (we get the first two bytes of a three byte >>> seq

bug#35509: Stopping gdm-service results in an unresponsive system

On my x86_64-linux system running the Guix system, when I include gdm-service in my system services, 'herd stop xorg-server' results in a state where I seemingly cannot recover except by rebooting. I'm left in what appears to be an empty Linux text console with a cursor in the top left corner, but

bug#35510: My GNOME sound settings occasionally get lost

On my x86_64-linux Guix system, I run GNOME 3 within Wayland. However, I need to keep 'slim-service' around for one purpose only: to occasionally remind GNOME sound settings of my preferred "alert" sound, since it forgets several times per month. I personally find the default "Drip" sound to be i

bug#33693: Missing icons in GNOME Shell since core-updates merge

This issue was fixed when 'staging' was merged into master, so I'm closing this bug. Mark

bug#35010: Many CPAN download URLs are no longer available

I believe that these broken URLs are now fixed, so I'm closing this bug. Mark

bug#35519: librsvg broken on i686-linux

Hydra failed to build librsvg on i686-linux, because it depends on Rust which is still broken on i686-linux in Guix. https://hydra.gnu.org/build/3477308 Mark

bug#35520: libplist FTB on i686, causing loss of Nautilus, MATE, LXDE, GNOME, etc

libplist fails to build on i686-linux: https://hydra.gnu.org/build/3484341 Collateral damage from this includes GVFS, Nautilus, MATE, LXDE, and GNOME. Mark

bug#35521: Mariadb test suite failures on x86_64-linux

hydra.gnunet.org has failed to build mariadb on x86_64-linux twice in a row: https://hydra.gnu.org/build/3475081#tabs-buildsteps The same test failed both times: > Failure: Failed 1/5075 tests, 99.98% were successful. > > Failing test(s): tokudb_alter_table.hcad_all_add The same build also f

bug#35521: Mariadb test suite failures on x86_64-linux

Mark H Weaver writes: > The same build also failed twice in a row on my Thinkpad X200, and with > the same error each time, although it's a different error than happens > on hydra.gnunet.org. On my X200, I get this instead: > >> Failure: Failed 1/1091 tests,

bug#35529: libdrm fails to build on armhf-linux

Hydra failed two consecutive attempts to build libdrm on armhf-linux: https://hydra.gnu.org/build/3481547#tabs-summary Both build attempts were made on hydra-slave2, which is a Wandboard Quad based on the Freescale i.MX6 SOC. Collateral damage includes several hundred dependency failures, incl

bug#35530: NSS-3.43 fails its test suite on armhf-linux

NSS-3.43 fails its test suite on armhf-linux: https://hydra.gnu.org/build/3484222 Mark

bug#35509: Stopping gdm-service results in an unresponsive system

Hi Timothy, Timothy Sample writes: > I have a lead now! At least, I have a way to stop GDM and return to a > working TTY. Assuming that you are working on a TTY with elogind > session “c1”, you can run > > herd stop xorg-server & (sleep 5; loginctl activate c1) > > When GDM exits, it leave

bug#35520: libplist FTB on i686, causing loss of Nautilus, MATE, LXDE, GNOME, etc

Ludovic Courtès writes: > Mark H Weaver skribis: > >> libplist fails to build on i686-linux: >> >> https://hydra.gnu.org/build/3484341 > > This was fixed here <https://issues.guix.info/issue/35501>, but I think > the fix hasn’t been cherry-picked to mas

bug#35350: Some compile output still leaks through with --verbosity=1

Hi Ludovic, Ludovic Courtès writes: > Mark H Weaver skribis: > >> Ludovic Courtès writes: > > [...] > >>> So there are two things. To fix the issue you reported (build output >>> that goes through), I think we must simply turn off UTF-8 decoding f

bug#35560: GNOME Shell 3.28 crashes and suspends to RAM (!) after ejecting removable media

Ludovic Courtès writes: > GNOME Shell is crashy since the 3.28 upgrade (it’s an install that was > made before the 3.28 upgrade; I wonder whether the same happens on a > fresh install.) > > It occasionally crashes (SIGSEGV) and is automatically respawned, which > is kinda okay: as a user, you not

bug#35560: GNOME Shell 3.28 crashes and suspends to RAM (!) after ejecting removable media

Earlier, I wrote: > FWIW, I've found GNOME Shell to be quite solid on my X200, including > since the 3.28 upgrade. However, I run it under Wayland, by running > "XDG_SESSION_TYPE=wayland exec dbus-run-session gnome-session" from a > text console. Perhaps that makes a difference? > >> The thing t

bug#35591: Segfault on flatpak remote-add

Hi Jonathan, "Jonathan Frederickson" writes: > I'm attempting to use Flatpak on my Guix system, and I'm experiencing > segfaults when attempting to add a remote repo. Provided below are the > output of the command I'm attempting to run, as well as some info > about my system. My knowledge of Fla

bug#35529: libdrm fails to build on armhf-linux

Hi Ricardo, Ricardo Wurmus writes: > Mark H Weaver writes: > >> Hydra failed two consecutive attempts to build libdrm on armhf-linux: >> >> https://hydra.gnu.org/build/3481547#tabs-summary >> >> Both build attempts were made on hydra-slave2, which

bug#35597: GNOME Tweak Tool does not start

Hi, sirgazil writes: > I installed the GNU system in a real machine using Guix 1.0 ISO > installer > (https://ftp.gnu.org/gnu/guix/guix-system-install-1.0.0.x86_64-linux.iso.xz). > > After installing "gnome-tweak-tool", I cannot launch it. I can confirm that it doesn't work for me either. It u

bug#35594: GNOME: Application icons are not displayed immediately after installation

Hi, sirgazil writes: > I installed the GNU system in a real machine using Guix 1.0 ISO > installer > (https://ftp.gnu.org/gnu/guix/guix-system-install-1.0.0.x86_64-linux.iso.xz). > > Whenever I install a desktop application, the application icon does > not show up immediately in the list of avai

bug#35590: Emacs info can't open info manuals

Hi, sirgazil writes: > I can't open info manuals in an Emacs freshly installed in my GNU > system installed in a real machine using the ISO installer > (https://ftp.gnu.org/gnu/guix/guix-system-install-1.0.0.x86_64-linux.iso.xz). > > ## Steps to reproduce > > 1. guix install emacs > 2. Start Ema

bug#35529: libdrm fails to build on armhf-linux

Hi Ricardo, Ricardo Wurmus writes: >> Ricardo Wurmus writes: >> >>> Mark H Weaver writes: >>> >>>> Hydra failed two consecutive attempts to build libdrm on armhf-linux: >>>> >>>> https://hydra.gnu.org/build/3481547#tabs-summ

bug#35590: Emacs info can't open info manuals

Hi, sirgazil writes: > M-x getenv PATH RET shows "bin"s in other paths, but not "/bin": > > /gnu/store/hk4f641r18vpj44m42pny6rp1nwg3d4w-glib-2.56.3-bin/bin:/home/sirgazil/.guix-profile/bin:/home/sirgazil/.guix-profile/sbin:/run/setuid-programs:/home/sirgazil/.config/guix/current/bin:/home/sirgaz

bug#35529: libdrm fails to build on armhf-linux

Hi Ricardo, Ricardo Wurmus writes: > This has built fine on berlin. We have a completed build for > /gnu/store/3c28p8b07709isd9jlcnnnyrpgz4ndz8-libdrm-2.4.97. What kind of hardware was it built on? >>> >>> I’m not sure. We’re using a few Overdrive 1000 machines that have quit

bug#35510: My GNOME sound settings occasionally get lost

Mark H Weaver writes: > On my x86_64-linux Guix system, I run GNOME 3 within Wayland. However, > I need to keep 'slim-service' around for one purpose only: to > occasionally remind GNOME sound settings of my preferred "alert" sound, > since it forgets several

bug#35623: guix pull failed on RHEL7

Hi Karrick, Karrick McDermott writes: > Note, I ran this with non privileged permissions, which might be > wrong. I am only sending this email because the program requested it. We normally run 'guix pull' unprivileged, so that's fine. > [kmcdermo@kmcdermo-ld2 ~]$ guix pull > Updating channel

bug#35622: Ran into a bug in the new graphical installer on WiFi setup

Hi Hugo, Hugo Saavedra writes: > Thanks for your work on GuixSD. I was excited to try out the new > graphical installer, but ran into a bug while setting up WiFi. I'm sorry to hear it. Thanks very much for the report. > I've uploaded photos of the stacktrace for you to take a look at. This >

bug#35551: guix search

Hi, Ludovic Courtès writes: > Bruno Haible skribis: > >>> For that we’d need to resort to an external service providing this info. >> >> Why would it need to be an external service? Can't you incorporate >> this information in a data file that you ship as part of the >> distribution? > > Such a

bug#35519: librsvg broken on i686-linux

Hi Danny, Danny Milosavljevic writes: > But when I use our separate package definitions it fails when building libcore > (which is the first library for the target compiler). > Invoke seems to swallow the output, so I have no idea where or why it failed > (grr). Hmm. What makes you think that

bug#35551: guix search

Hi Bruno, Bruno Haible writes: > Mark H Weaver wrote: >> If we add functionality that calls out to the network in response to a >> package search, e.g. to query popularity ratings or package file >> listings, we should make sure the user knows it's happening, and prov

bug#35551: guix search

Hi Tobias, Tobias Geerinckx-Rice writes: > Bruno Haible wrote: >> Mark H Weaver wrote: >>> If we add functionality that calls out to the network in response >>> to a >>> package search, e.g. to query popularity ratings or package file >>> list

bug#35761: gnome-maps fails to find Goa

Brendan Tildesley writes: > $ gnome-maps > Unsatisfied dependency: Goa The same thing happens on my system, where 'gnome-maps' has worked in the past, before the recent merge of the 'staging' branch (which happened just before the 1.0.0 release). Mark

bug#36262: cannot install bootloader to root partition

Hi Tobias, Tobias Geerinckx-Rice writes: > zna...@disroot.org wrote: >> bug#36262: cannot install bootloader to root partition > > Installing GRUB to your root partition isn't supported, and should > never be necessary anyway. > >> Hello! I was not able to install Guix having 2 partitions: >> /d

bug#36262: cannot install bootloader to root partition

Tobias Geerinckx-Rice writes: > Mark H Weaver wrote: >> FWIW, I used this partition layout for years, including on Guix >> systems, >> and it worked fine. > > Impossible, sorry. In fact, it _is_ possible, if you use an MBR partition table. I assumed that znavko wa

bug#36443: guix build mixes build dirs?

Robert Vollmert writes: > So this is pretty bizarre, and I haven’t managed to cut it down > to a smaller example yet, but it seems pretty clear that something > is broken: > > $ guix build -K some-package > -> error, referencing /tmp/guix-build-puzzledb-frontend-20190625-git.drv-0 > note: keeping

bug#36443: guix build mixes build dirs?

Mark H Weaver writes: > Robert Vollmert writes: > >> So this is pretty bizarre, and I haven’t managed to cut it down >> to a smaller example yet, but it seems pretty clear that something >> is broken: >> >> $ guix build -K some-package >> -> error,

bug#36443: Canonicalized build directory name in container leads to confusion (was guix build mixes build dirs?)

retitle 36443 Canonicalized build directory name in container leads to confusion thanks Hi Robert, Robert Vollmert writes: > Thanks for clarifying. Do you have an idea how to make this less confusing? > > In my follow-up to the bug report I suggested > >> E.g. instead of saying “keeping build di

bug#36443: Canonicalized build directory name in container leads to confusion (was guix build mixes build dirs?)

Hi Robert, Robert Vollmert writes: > How about dropping the “-0” suffix inside the container? The major part > of my confusion was that the directory “-0” actually existed in /tmp > from a previous failed build; this change might avoid that. Sounds good to me. I think that would clearly be an i

bug#36443: Canonicalized build directory name in container leads to confusion (was guix build mixes build dirs?)

Hi Ludovic, Ludovic Courtès wrote: > The result would be that the temporary directory would always have a > different name inside and outside the container. Consequently, > debugging along the lines of what the manual suggests (info "(guix) > Debugging Build Failures") would become pretty much i

bug#36544: 'set-paths' should exclude 'source' from consideration

The 'set-paths' phase in (guix build gnu-build-system) currently includes 'source' in the set of candidates for inclusion in the search-path variables. First of all, I think it's undesirable to include subdirectories of the source directory in these search paths. However, if you think it's desira

bug#35521: Mariadb test suite failures on x86_64-linux

Hi, Marius Bakke writes: > Chris Marusich writes: > >> Hi, >> >> I've been encountering this failure off and on for a few weeks now, and >> I'd like to help fix it. In short, it seems like non-deterministic test >> failures, to me. I think we should gather data and report the issue >> upstrea

bug#35521: Mariadb test suite failures on x86_64-linux

Hi Marius, > Update: Berlin built mariadb twice on core-updates with this patch: > > --8<---cut here---start->8--- > diff --git a/gnu/packages/databases.scm b/gnu/packages/databases.scm > index 6bfeaad9a2..64bc0938b6 100644 > --- a/gnu/packages/databases.scm > +

bug#35521: Mariadb test suite failures on x86_64-linux

Earlier, I wrote: >> Mark, Chris: Can you try this change with MariaDB 10.1.40 and see if it >> works for you? > > I tried it, but it made no difference on my Thinkpad X200, which still > fails the same way as before with 10.1.38: > > Failing test(s): tokudb_bugs.mdev4533 I should clarify that

bug#35521: Mariadb test suite failures on x86_64-linux

Hi Marius, > Could it be that you don't have enough disk space for this test? Do you > have the log file available still? Yes, I have not only the log file, but also the failed build directory. My log file contains the same error in the 'tokudb_bugs.mdev4533' test: mysqltest: At line 6: query

bug#35521: Mariadb test suite failures on x86_64-linux

Hello again, > Could it be that you don't have enough disk space for this test? Do you > have the log file available still? I made another build attempt on my X200, this time logging the output of "df --si" every 10 seconds. The free space started at ~11 GB free and never went below 7 GB, but t

bug#35521: Mariadb test suite failures on x86_64-linux

Hi Marius, Marius wrote: > There has been some activity around TokuDB in later versions of MariaDB, > maybe we can enable it again with 10.4. For now, I think we should just > disable it. Disabling TokuDB for now sounds like a fine option. Thanks very much for looking into it. Mark

bug#36708: guix.gnu.org/packages is 6 weeks stale, claims recent update

As I write this, is over 6 weeks stale, but claims to have been updated two days ago, on July 15: "GNU Guix provides 9,789 packages transparently available as pre-built binaries. These pages provide a complete list of the packages. Our continuous integration

bug#36724: Unable to independently verify the new bootstrap binaries

Hi, I'd like to start compiling 'core-updates' on my machine, but first I wish to independently verify the new bootstrap binaries. I'm running into difficulties with that. I started by building the new bootstrap binaries from commit 4ae7dc7b9af64794081b1913740b97acd89c91bc, as cited in this comm

bug#36069: Menu-based installer unusable through noVNC

Hi, Ludovic Courtès wrote: > Robert Vollmert skribis: > >>> On 26. Jun 2019, at 22:23, pelzflorian (Florian Pelz) >>> wrote: >>> >>> On Wed, Jun 26, 2019 at 06:51:41PM +0200, Björn Höfling wrote: What's the conclusion? Maybe that Guix is fine and the VNC-clients are also fine. It mi

bug#36724: Unable to independently verify the new bootstrap binaries

Hi Janneke, >> I'm unsure how to proceed. Can someone please help me independently >> verify these binaries? > > Yeah, I don't know...Do I dare to suggest you give it a retry? It built successfully on the second attempt. I'm curious what happened, but not quite curious enough to investigate fur

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

I'm working to independently verify the new bootstrap binaries. Toward that end, I locally built the new bootstrap tarballs by running the following command from a git checkout at commit ef809e3ac036eccc5f9c9edd8fb661d14ae15f2f. ./pre-inst-env guix build bootstrap-tarballs --system=i686-linux

bug#36731: shepherd lost track of nginx

Hello, Ludovic Courtès writes: > Robert Vollmert skribis: > >> The result was this: >> >> $ sudo herd restart nginx >> Service nginx is not running. >> herd: exception caught while executing 'start' on service 'nginx': >> Throw to key `srfi-34' with args `("#> [program: >> \"/gnu/store/mlg0xfbi

bug#36754: New linux-libre failed to build on armhf on Berlin

In commit 1ad9c105c208caa9059924cbfbe4759c8101f6c9, I changed our linux-libre packages to deblob the linux-libre source tarballs ourselves, i.e. to run the deblobbing scripts provided by the linux-libre project to produce linux-libre source tarballs from the upstream linux tarballs: https://git

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

Hi Janneke, Thanks very much for the quick response to this issue. Jan Nieuwenhuizen wrote: > In any case, if store references are present in bootstrap binaries, then > they should be reproducible. Removing store references is one way to > make them reproducible but I'm not sure if that's the b

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

Hi Janneke, Jan Nieuwenhuizen wrote: >> What I need is a way to build the new bootstrap tarballs without using >> the existing 'core-updates' branch. I need a way to build them from a >> branch that's based upon the much older bootstrap binaries that we've >> been using for many years. Preferab

bug#36754: New linux-libre failed to build on armhf on Berlin

Hi Ricardo, Interesting. I distinctly remember that there was no log file when I looked last time. Hmm. Anyway, it seems that now, all of the failed builds have either build logs available or else information about which dependency failed. I don't remember seeing any of this last time, but I'm

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

Hi Janneke, > I have added a very similar set of two patches to wip-cu-binaries, > branched @ ef809e3ac036eccc5f9c9edd8fb661d14ae15f2f. > > They give the same md5sum for me as the wip-binaries branch that > branched off of master; so mine are at > http://lilypond.org/janneke/guix/20190722/ I buil

bug#36754: SSH connections to hydra-slave{1, 2, 3} fail during builds (was: New linux-libre failed to build on armhf on Berlin)

retitle 36754 SSH connections to hydra-slave{1,2,3} fail during builds thanks Hi, I've added Ludovic to the CC list, since he recently added hydra-slave{1,2,3} to Berlin. Marius wrote: > I tried building 5.2.2 'interactively' on Berlin, and got an SSH error: > > CC [M] net/openvswitch/vport-

bug#36754: SSH connections to hydra-slave{1, 2, 3} fail during builds (was: New linux-libre failed to build on armhf on Berlin)

I wrote earlier: > I now believe that these failures are related to the newly added armhf > build slaves, and that they have nothing to do with the recent changes > to our linux-libre packages. I should mention that the armhf build slaves are on a private network, and I use my public-facing intern

bug#36754: SSH connections to hydra-slave{1, 2, 3} fail during builds

Hi Ludovic, Ludovic Courtès wrote: > I noticed that connections to the machines were unstable (using > OpenSSH’s client). That is, the connection would eventually “hang”, > apparently several times a day. > > Currently we have an SSH tunnel set up on berlin to connect to each of > these machines

bug#36754: SSH connections to hydra-slave{1, 2, 3} fail during builds

Hi Marius, Marius Bakke wrote: > The truncated log files seems to happen for other builds as well, even > within the Berlin data center. > > https://ci.guix.gnu.org/log/n3ra1b8ic6qhfinnhb80mrn7snsqws9d-geocode-glib-3.26.0 > https://ci.guix.gnu.org/log/zqhqlib00i8f7f10g4c2dfzprw16h4xv-scintilla-4

bug#36930: NSS 3.45 fails to build on armhf-linux

Hi Marius, Marius Bakke writes: > On armhf-linux, 'nss' fails early in the build process due to an > undefined reference to "PR_Assert": > > https://ci.guix.gnu.org/log/5cqmmjd9a8h05l8y352z1pq4mlyd6w21-nss-3.45 > > This is almost certainly because of this upstream commit, which swaps > out the c

bug#22138: Search paths of dependencies are not honored

Hi Julien, Julien Lepiller writes: > Hi, I've been looking at our current code and would like to propose the > attached patch for that issue. > > From cfd2c229087166ab4cc0a9e2bdb72c8b393bcdd5 Mon Sep 17 00:00:00 2001 > From: Julien Lepiller > Date: Thu, 1 Aug 2019 22:09:38 +0200 > Subject: [PAT

bug#36930: NSS 3.45 fails to build on armhf-linux

Earlier, I wrote: > For now, we could simply revert my commit that updates NSS to 3.45. > Although I mentioned in the commit log that it fixed some CVEs, I later > discovered that 3.44.1 includes fixes for the same CVEs. NSS 3.44.1 was > the version of NSS in 'master' before my commit. I reverted

bug#36870: was: date bug -- really locale bug or ??

Hi Bengt, I'm sorry that I didn't have time to fully read your messages, but if I understand correctly from my quick skimming, the 'date' command from Guix is failing to access the zoneinfo. I think I see your problem. Bengt Richter writes: > $ strace -y date|& egrep 'America|^write'|sed -e 's:

bug#36909: CVE-2017-837{2,3,4} patches for libmad from Debian

Hi, ma...@secmail.pro wrote: > I think that package "libmad" should be updated to include fixes for the > following vulnerabilities: > https://security-tracker.debian.org/tracker/CVE-2017-8372, > https://security-tracker.debian.org/tracker/CVE-2017-8373, > https://security-tracker.debian.org/trac

bug#36938: Website: Package list is not updated

Hi, Hartmut Goebel writes: > The package list at http://guix.gnu.org/packages/ is not updated. It > still says: > > […] provides 9,789 packages […] (updated July 19, 2019). Indeed, and in fact the packages listed are much older than July 19. They are actually from late May. An easy way to chec

bug#36924: fixing GDM + GNOME Shell

Hi Ricardo, Ricardo Wurmus writes: > Today I again couldn’t log into my workstation after upgrading the > system. I’m using GDM + GNOME Shell. > > At first GDM wouldn’t start. I knew what to do: remove /var/lib/gdm, > because some state must have accumulated there. > > GDM came up after a rebo

bug#36992: linux-libre-5.2.7 failed to build on armhf and aarch64; why?

linux-libre-5.2.7 failed to build on Berlin due to a dependency failure: https://ci.guix.gnu.org/search?query=linux-libre-5 https://ci.guix.gnu.org/build/1556871/details https://ci.guix.gnu.org/build/1556831/details I guess that the deblobbing derivation probably failed, but I don't see a w

bug#37003: Guix installer: Unexpected Problem with WiFi

Hi Steve, Steve Sprang writes: > Installing on a Lenovo X200 with the graphical installer. Problem > occurs after selecting WiFi option and then selecting "Scan". > Partitioned drive no longer appears after recovering and a reboot is > necessary to continue. This seems to be the same bug report

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

Jan Nieuwenhuizen writes: > Mark H Weaver writes: > > Hi Mark, > >>> I have added a very similar set of two patches to wip-cu-binaries, >>> branched @ ef809e3ac036eccc5f9c9edd8fb661d14ae15f2f. >>> >>> They give the same md5sum for me as the wip-bin

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

I wrote earlier: > There are two bootstrap tarballs that differ: > > (1) static-binaries > (2) guile-static-stripped > > In this message, I'll address only the 'static-binaries'. > > The only difference in the static-binaries is bash. It turns out that > the bash-4.4 configure script produces an

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

Hi Ludovic, Ludovic Courtès writes: > Mark H Weaver skribis: > >>> I have added a very similar set of two patches to wip-cu-binaries, >>> branched @ ef809e3ac036eccc5f9c9edd8fb661d14ae15f2f. >>> >>> They give the same md5sum for me as the wip-binaries

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

Hi Janneke, Jan Nieuwenhuizen writes: > Mark H Weaver writes: > >> It seems to me that the best way to accomplish this is to backport the >> new '%bootstrap-tarballs' from 'wip-cu-binaries' to the 'master' branch. > > I called that `wip-bin

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

Hi Marius, Marius Bakke writes: > Marius Bakke writes: > >> Jan Nieuwenhuizen writes: >> >>> Mark H Weaver writes: >>> >>> Hi Mark, >>> >>>>> I called that `wip-binaries', @master from three weeks ago. >>>>

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

Earlier I wrote: [...] > (3) The following bootstrap packages in 'core-updates' bootstrap.scm > should be updated to use the new binaries above: > > (a) %bootstrap-linux-libre-headers > (b) %bootstrap-mescc-tools > (c) %bootstrap-mes > > (4) Berlin should start rebuilding 'core-

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

Hi Marius, Marius Bakke writes: > I wanted to check that the bootstrap-tarballs machinery still worked > after merging the branch, since it was non-trivial. Mainly to make the > commit that created them reachable forever, but maybe we don't need it. [...] > [...] I will do this in a 'core-upd

bug#37021: GuixSD 1.01-i686 install DVD boot failure on Macbook1, 1: failed to resolve partition

Calvin Heim writes: > Apologies for the formatting errors in the previous email. Hopefully this > message is cleaner. > > GRUB loads.   > I add acpi=off to the boot options and boot.  Otherwise, the screen goes black > with a '-' symbol at the top left corner and freezes. > > So, after booting w

bug#37035: --with-graft tries to download source files and build them

Hi, writes: > When running `guix build --dry-run --with-graft=mesa=mesa love`, Guix shows > that it will try to download a bunch of source files for quite a few packages: > > ``` > $ guix build --dry-run --with-graft=mesa=mesa love > The following derivations would be built: >/gnu/store/0lf

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

d "guix download" to load the new bootstrap binaries into my store, and am now testing the attached draft patch to 'core-updates'. Thanks, Mark >From e3e477c92af3b62eb8f65a5c4459f02faf60e857 Mon Sep 17 00:00:00 2001 From: Mark H Weaver Date: Thu, 15 Aug 201

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

ep 17 00:00:00 2001 From: Mark H Weaver Date: Thu, 15 Aug 2019 15:39:57 -0400 Subject: [PATCH 1/2] gnu: bootstrap: Update to the 20190815 bootstrap binaries. * gnu/packages/bootstrap.scm (%bootstrap-linux-libre-headers): Update the download URL. (%bootstrap-mescc-tools, %bootstrap-mes): Update the do

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

Marius Bakke writes: > Mark H Weaver writes: > >> I rebased 'wip-binaries' on top of current master (which includes the >> recent 'staging' merge), and excluding the update of mescc-tools to the >> git checkout. >> >> I built the bootstrap

<    4   5   6   7   8   9   10   11   >