bug#25444: 'guix system init' on GuixSD w/ RAID target produces "guix system: error: failed to register"
** summary Running 'guix system init' on GuixSD with RAID target device produces errors like ... root@g1 ~# guix system init system/g1.00.scm /mnt/md0 [...] initializing operating system under '/mnt/md0'... copying '/gnu/store/0m0clxj69xrxb76kyh3ral8lkfb0vx8c-linux-libre-4.9.2'... In execvp of /usr/local/sbin/guix-register: No such file or directory guix system: error: failed to register '/gnu/store/0m0clxj69xrxb76kyh3ral8lkfb0vx8c-linux-libre-4.9.2' under '/mnt/md0' [...] guix system: error: failed to register '/gnu/store/1k2swlkbpf44d5fzgvrp5znafhw90xh7-grub-image.png' under '/mnt/md0' Running Guix from git checkout and from guix pull produce similar errors. Version info, logs, and config file are attached below. ** Running from git checkout: *** Log root@g1 /home/glc# lsblk -f NAMEFSTYPELABELUUID MOUNTPOINT sdb ├─sdb2 ├─sdb5 linux_raid_member g1:1 644cee85-566f-abce-84c5-5e6f9983c6f8 ├─sdb1 linux_raid_member g1:0 59340f87-fc27-638b-f1cd-42a9a6bdfad3 │ └─md0 ext4 g1-root 415ba95b-7375-4f26-822c-d3d3e7a0f734 /mnt/md0 └─sdb6 linux_raid_member g1:2 1b0c8ab8-0dad-e743-e5c6-577fcd6419cd └─md2 ext4 g1-bstg 02d1d054-fc65-4773-9597-890b56482b6a /mnt/md2 sdc ├─sdc2 ├─sdc5 linux_raid_member g1:1 644cee85-566f-abce-84c5-5e6f9983c6f8 ├─sdc1 linux_raid_member g1:0 59340f87-fc27-638b-f1cd-42a9a6bdfad3 │ └─md0 ext4 g1-root 415ba95b-7375-4f26-822c-d3d3e7a0f734 /mnt/md0 └─sdc6 linux_raid_member g1:2 1b0c8ab8-0dad-e743-e5c6-577fcd6419cd └─md2 ext4 g1-bstg 02d1d054-fc65-4773-9597-890b56482b6a /mnt/md2 sda └─sda1 ext4 ssd-root ec3af1c3-2489-4400-acee-a57438b353d4 / root@g1 /home/glc# cd root@g1 ~# guix system init system/g1.00.scm /mnt/md0 substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 100.0% The following derivations will be built: /gnu/store/a9cpcsbqc0nj2r1qi8a8hzl7m6wnfn4d-system.drv /gnu/store/sgjyqs1nngzfra8j720lgpr7rhfrdbnj-grub.cfg.drv /gnu/store/rh0da4gw9hxskpn8zdxd4f20dd46mwrf-parameters.drv /gnu/store/v12bx159c461xy0yd7x5kra7hfb79f9a-shepherd-user-processes.scm.drv /gnu/store/ddxwbsm2z82fz5ahy6an7mfx67ia9dfa-shepherd-user-file-systems.scm.drv /gnu/store/6inqbx38yajns8dz06r8ij21y8j1gdyk-shepherd-device-mapping--dev-md1.scm.drv /gnu/store/5wknmg4zf4kljwikbnhmwnb0aq6agcky-shepherd-device-mapping--dev-md2.scm.drv /gnu/store/4l7p849pchaxfw628a95c08r2282gxxs-shepherd-file-system--mnt-bstg.scm.drv /gnu/store/syk6y0i21399lfnjwrvcffmk02xbph1h-shepherd.conf.drv /gnu/store/a9hmflqkh2nfns54xfjrwalnzzwzxfhw-activate-service.drv /gnu/store/7wvp80b2rdng391pdncdbc21lsw148fg-activate-service.drv /gnu/store/fbjknymwzdsf5pmsaqxmvn1hdvcinp1i-activate.drv /gnu/store/0rnp9pqyd7j2nd08hav57m3645brlmcv-boot.drv /gnu/store/hbhxxp5vfl0w63js2mrkpfy7zzg4pdly-etc.drv /gnu/store/a04l8ypqwakcv1cpqiq222clv032yk9a-init.drv /gnu/store/76649pq3r2sxjqcpghmp9sw31mhdzi5r-base-initrd.drv [...] /gnu/store/cb6nirh13zhnsrq85jh4xb6hh1i36vbh-system /gnu/store/qbi85dpcnyg3vvpph8jsajfs4f0ahd0b-grub.cfg /gnu/store/q0hvvcydv83hk104fimhj30asn291j9p-grub-2.02beta3 initializing operating system under '/mnt/md0'... copying '/gnu/store/0m0clxj69xrxb76kyh3ral8lkfb0vx8c-linux-libre-4.9.2'... In execvp of /usr/local/sbin/guix-register: No such file or directory guix system: error: failed to register '/gnu/store/0m0clxj69xrxb76kyh3ral8lkfb0vx8c-linux-libre-4.9.2' under '/mnt/md0' root@g1 ~# guix system build system/g1.00.scm /gnu/store/cb6nirh13zhnsrq85jh4xb6hh1i36vbh-system root@g1 ~# guix system init system/g1.00.scm guix system: error: wrong number of arguments for action 'init' root@g1 ~# guix system init system/g1.00.scm /mnt/md0 /gnu/store/cb6nirh13zhnsrq85jh4xb6hh1i36vbh-system /gnu/store/qbi85dpcnyg3vvpph8jsajfs4f0ahd0b-grub.cfg /gnu/store/q0hvvcydv83hk104fimhj30asn291j9p-grub-2.02beta3 initializing operating system under '/mnt/md0'... copying '/gnu/store/0m0clxj69xrxb76kyh3ral8lkfb0vx8c-linux-libre-4.9.2'... In execvp of /usr/local/sbin/guix-register: No such file or directory guix system: error: failed to register '/gnu/store/0m0clxj69xrxb76kyh3ral8lkfb0vx8c-linux-libre-4.9.2' under '/mnt/md0' *** Version root@g1 ~# stat ~/.config/guix/latest | grep File: File: '/root/.config/guix/latest' -> '../../../home/g1/src/guix' root@g1 ~# git -C ~/.config/guix/latest describe v0.12.0-456-gb0a567640 root@g1 ~# guix --version guix (GNU Guix) 0.12.0 ** Running from guix pull *** Log root@g1 ~# guix system init system/g1.00.scm /mnt/md0 substit
bug#25177: [PATCH v6] gnu: python-sphinx: Update to 1.4.8.
Done on the python-tests branch as commit 9a8acd00da3ad44ac6ef423f3d9cba87645cc022. Matplotlib will fail now.
bug#25442: Emacs compilation buffer segfault
Hi! Running bash crash.nw in an xterm makes Emacs segfault about 4 out of 5 times for me. Greetings, Jan crash.nw Description: Binary data mes.crash Description: Binary data -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl
bug#25438: SLIM does not display an option for dwm
For a system config which includes: (packages (cons* nss-certs awesome dwm openbox xfce dmenu %base-packages)) I am able to select (via cycling through them with F1 in the SLIM(?) login screen: * awesome * openbox (and variations) * xfce * GNOME dwm is not selectable. Either this list is too long for slim, or there's some problem with our dwm. -- ♥Ⓐ ng0 -- https://www.inventati.org/patternsinthechaos/
bug#25177: [PATCH v6] gnu: python-sphinx: Update to 1.4.8.
On Fri, Jan 13, 2017 at 01:34:21PM +0100, Marius Bakke wrote: > Leo: I'm unable to reproduce the Hydra failures, so I decided to merge > master so we can restart this branch. However, Savannah refuses the push > for no good reason! > > $ git reset --hard savannah/python-tests > $ git merge master > $ > $ git push -v savannah python-tests > Pushing to mba...@git.sv.gnu.org:/srv/git/guix.git > error: failed to push some refs to 'mba...@git.sv.gnu.org:/srv/git/guix.git' I bet that you are using the new pre-push hook that verifies commit signatures, and you're trying to push some commits that fail the signature verification check. Someone should add some error reporting to the hook. > Any ideas? The merged branch is 687 commits ahead. > > You can try the merge yourself, the local.mk conflict is easy and in > bioinformatics.scm you want to keep [arguments] and not [native-inputs]. Done with the hook disabled. > I suppose we could rebase it and force-push, but it seems heavy-handed. IMO we should avoid it when possible; rebasing loses the original signatures. signature.asc Description: PGP signature
bug#25437: awesome breaks on configuration reload
To reproduce, configure a VM or your system with awesome available, press (where SUPER is usually META4), or do a right click on the desktop and select: awesome -> restart The normal use is, you changed something in your ~/.config/awesome/rc.lua and you reload the config by instructing awesome to restart. There has been a big change with the move to 4.0 and prior to that, but I doubt they changed the behavior of this command. What happens with our current package is that your session terminates and you get back to the login screen. It must be some problem with lua or lua modules, because when you have lua (just lua) in your profile, you get to see a message (OSD) "unable to login" or something like that. At the moment I can't provide logs. -- ♥Ⓐ ng0 -- https://www.inventati.org/patternsinthechaos/
bug#25177: [PATCH v6] gnu: python-sphinx: Update to 1.4.8.
Hi, > Danny: I cannot apply the sphinx update patch for some reason. Did you > use git-send-email? Yes. I also pulled from guix master and did "git am" with my patch-E-Mail from back then a moment ago - it applied fine. >In any case, since you will have commit access soon, > can you please push it to the 'python-tests' branch once this merge is > resolved. Then we can start a new evaluation and hopefully do the last > round of fixes :-) Sure.
bug#25177: [PATCH v6] gnu: python-sphinx: Update to 1.4.8.
Marius Bakke writes: > Danny Milosavljevic writes: > >> * gnu/packages/python.scm (python-sphinx)[version]: Update to 1.4.8. >> [source]: Use pypi-uri. >> [propagated-inputs]: Add python-imagesize, python-sphinx-alabaster-theme, >> python-babel, python-snowballstemmer, python-six. >> [properties]: Add python2-variant. >> (python2-sphinx)[native-inputs]: Add python2-mock. >> [propagated-inputs]: Add python2-pytz. > > LGTM, thanks! As per the prior discussion, it should be applied in the > 'python-tests' branch. Since it requires some packages only present in > 'master', it will have to wait until the remaining failures are fixed. > > Then we can merge master, add this patch and start a new evaluation. Leo: I'm unable to reproduce the Hydra failures, so I decided to merge master so we can restart this branch. However, Savannah refuses the push for no good reason! $ git reset --hard savannah/python-tests $ git merge master $ $ git push -v savannah python-tests Pushing to mba...@git.sv.gnu.org:/srv/git/guix.git error: failed to push some refs to 'mba...@git.sv.gnu.org:/srv/git/guix.git' Any ideas? The merged branch is 687 commits ahead. You can try the merge yourself, the local.mk conflict is easy and in bioinformatics.scm you want to keep [arguments] and not [native-inputs]. I suppose we could rebase it and force-push, but it seems heavy-handed. Danny: I cannot apply the sphinx update patch for some reason. Did you use git-send-email? In any case, since you will have commit access soon, can you please push it to the 'python-tests' branch once this merge is resolved. Then we can start a new evaluation and hopefully do the last round of fixes :-) signature.asc Description: PGP signature
bug#24130: RAID config boot hangs at [...] Clocksource: Switched to clocksource tsc
myglc2 skribis: > On 01/11/2017 at 23:14 Ludovic Courtès writes: > >> Could you tell me if this bug is still relevant? > > Hi Ludo’, > > Sorry for the delay, I had to swap hardware around to revisit this. I > am now able to assemble 3 arrays as shown below, so I think you should > close the bug. Excellent, thanks for reporting back! Ludo’.
bug#25415: MySQL "server has gone away" when reloading database dump due to "max_allowed_packet" default
Ben Sturmfels skribis: > On 13/01/17 01:22, Ludovic Courtès wrote: > >>> Could it be worth setting max_allowed_packet to 16M in Guix's >>> `mysql-configuration-file` function for consistency with Debian? >> >> Definitely. I would add a ‘max-allowed-packet’ field in >> in (gnu services databases) and make sure it’s >> honored. >> >> Would you like to give it a try? > > Sure, I'll give it a shot! > > It looks as though the MariaDB source comes with a settings file for > Debian that includes max-allowed-packet=16M: > > mariadb-XX.XX.XX/debian/additions/my.cnf > > Would you recommend adding just max-allowed-packet, or would it be worth > applying all these settings in this file? I’m not famliar with MySQL/MariaDB, but any setting that sounds useful to you is welcome. Thanks, Ludo’.
bug#23776: Perl's .pod files include timestamps, making Perl package builds non-deterministic
Marius Bakke skribis:
> Ludovic Courtès writes:
>
>> Leo Famulari skribis:
>>
>>> On Thu, Jun 16, 2016 at 11:39:27AM -0400, Leo Famulari wrote:
On Thu, Jun 16, 2016 at 01:33:46PM +0200, Ludovic Courtès wrote:
> The problem is described in
> :
>
> --8<---cut here---start->8---
> timestamps_in_documentation_generated_by_podman:
> description: |
> The module Pod::Man includes timestamps in its embedded manpages:
>
> http://sources.debian.net/src/perl/latest/cpan/podlators/lib/Pod/Man.pm/?hl=1700#L977
> They should be based on the mtime of the original file.
> url:
> https://wiki.debian.org/ReproducibleBuilds/TimestampsInManpagesGeneratedByPodMan
According to the information on this page, we should set POD_MAN_DATE
while building. Should we make the perl-build-system export this
variable? Set to SOURCE_DATE_EPOCH?
>>>
>>> I noticed that Pod::Man is supposed to respect SOURCE_DATE_EPOCH, as of
>>> the upstream module version 4.03 (released 2015-12-06). Does anyone know
>>> how to check the version of the module bundled into perl?
>>
>> For the record, even though Pod::Man supposedly honors SOURCE_DATE_EPOCH
>> as of Perl 5.24, we still have this problem:
>>
>> --8<---cut here---start->8---
>> $ diff -r
>> /gnu/store/hczskszmhm2l65vy8nv990lzc5dk3ln9-perl-algorithm-c3-0.10{,-check}
>> diff -r
>> /gnu/store/hczskszmhm2l65vy8nv990lzc5dk3ln9-perl-algorithm-c3-0.10/lib/perl5/5.24.0/x86_64-linux-thread-multi/perllocal.pod
>>
>> /gnu/store/hczskszmhm2l65vy8nv990lzc5dk3ln9-perl-algorithm-c3-0.10-check/lib/perl5/5.24.0/x86_64-linux-thread-multi/perllocal.pod
>> 1c1
>> < =head2 Wed Jan 11 22:20:36 2017: C L
>> ---
>>> =head2 Wed Jan 11 22:20:34 2017: C L
>> --8<---cut here---end--->8---
>
> Isn't this fixed by be12f4e27505edd87c4aa457fec43dd0fee23b79 from
> 'core-updates'?
Oh, probably! I had forgotten about it, thanks for the heads-up.
Ludo’.
