bug#30756: GCC >= 6 '-isystem' and C_INCLUDE_PATH behavior changed, breaking
Hi, Maxim Cournoyer skribis: > It'd be nice to find a correct solution, but it seems I can't even make > the build system of Inkscape work after switching from CPATH to > CPLUS_INCLUDE_PATH and stripping it from any glibc/gcc include > directories (I don't get the "stdlib.h: No such file or directory." > error anymore, but I now get: > "/gnu/store/zw5f5g5aqlxam3imaylfla0i98nkridf-glibc-2.30/include/bits/errno.h:26:11: > fatal error: linux/errno.h: No such file or directory" instead, which I > don't understand). > > I also tried moving the glibc include directory to the end of > CPLUS_INCLUDE_PATH and it would still wouldn't be happy. Hmmph! Oh, really? I think that, as Mark H Weaver mentioned in this thread, if we make sure that glibc comes next-to-last (before Linux-libre headers) and appears only once in the list, it should work. Can you confirm? Thanks, Ludo’.
bug#39172: SElinux guix-daemon.cil file
Hi Matt, Matt Wette skribis: > I'm trying to get guix-1.0.1 running on Fedora-30 with its default > SElinux set up. > I found (hint from > https://lists.gnu.org/archive/html/guix-devel/2019-05/msg00109.html) > that the guix-daemon.cil file seems to be missing a few items. Without > this patch > # restorecon -R /gnu/store > fails. OK, thanks for finding it out! > --- guix-daemon.cil.orig 2020-01-18 07:08:12.905986299 -0800 > +++ guix-daemon.cil 2020-01-18 07:09:49.765737261 -0800 > @@ -34,14 +34,19 @@ > (roletype object_r guix_daemon_t) > (type guix_daemon_conf_t) > (roletype object_r guix_daemon_conf_t) > + (typeattributeset file_type guix_daemon_conf_t) > (type guix_daemon_exec_t) > (roletype object_r guix_daemon_exec_t) > + (typeattributeset file_type guix_daemon_exec_t) > (type guix_daemon_socket_t) > (roletype object_r guix_daemon_socket_t) > + (typeattributeset file_type guix_daemon_socket_t) > (type guix_store_content_t) > (roletype object_r guix_store_content_t) > + (typeattributeset file_type guix_store_content_t) > (type guix_profiles_t) > (roletype object_r guix_profiles_t) > + (typeattributeset file_type guix_profiles_t) > > ;; These types are domains, thereby allowing process rules > (typeattributeset domain (guix_daemon_t guix_daemon_exec_t)) Ricardo, WDYT? I know nothing about this config file so I’d rather have your approval before pushing. Ludo’.
bug#39172: SElinux guix-daemon.cil file
Ludovic Courtès writes: > Hi Matt, > > Matt Wette skribis: > >> I'm trying to get guix-1.0.1 running on Fedora-30 with its default >> SElinux set up. >> I found (hint from >> https://lists.gnu.org/archive/html/guix-devel/2019-05/msg00109.html) >> that the guix-daemon.cil file seems to be missing a few items. Without >> this patch >> # restorecon -R /gnu/store >> fails. > > OK, thanks for finding it out! > >> --- guix-daemon.cil.orig2020-01-18 07:08:12.905986299 -0800 >> +++ guix-daemon.cil2020-01-18 07:09:49.765737261 -0800 >> @@ -34,14 +34,19 @@ >>(roletype object_r guix_daemon_t) >>(type guix_daemon_conf_t) >>(roletype object_r guix_daemon_conf_t) >> + (typeattributeset file_type guix_daemon_conf_t) >>(type guix_daemon_exec_t) >>(roletype object_r guix_daemon_exec_t) >> + (typeattributeset file_type guix_daemon_exec_t) >>(type guix_daemon_socket_t) >>(roletype object_r guix_daemon_socket_t) >> + (typeattributeset file_type guix_daemon_socket_t) >>(type guix_store_content_t) >>(roletype object_r guix_store_content_t) >> + (typeattributeset file_type guix_store_content_t) >>(type guix_profiles_t) >>(roletype object_r guix_profiles_t) >> + (typeattributeset file_type guix_profiles_t) >> >>;; These types are domains, thereby allowing process rules >>(typeattributeset domain (guix_daemon_t guix_daemon_exec_t)) > > Ricardo, WDYT? I know nothing about this config file so I’d rather have > your approval before pushing. Could we also do this in one expression? (typeattributeset file_type (or guix_profiles_t guix_daemon_conf_t guix_daemon_exec_t guix_daemon_socket_t guix_store_content_t)) I also think we need to declare our use of “file_type” first: (typeattribute file_type) What do you think? -- Ricardo
bug#39199: Edit in installer doesn't work
Hi, I followed Ludo's call for testing the installer. I built an installer image from commit da76518. I couldn't find anything installer related on master branch since then. You can found the image here: https://brielmaier.net/guix-system-install-1.0.1-1.da76518.x86_64-linux.iso I'm testing in the Hetzner "Cloud", so basically in a VM with VGA/Display-output over HTTP. Everything is smooth until I click "Edit" at the end. I add some stuff (vim, screen packages) to the config.scm in nano, save it and then I click on "OK". Instead of the starting the actual installation, I get back to the very beginning of the installation proccess (choose locale). You can't do the same again as the hard disk doesn't show up in the partitioner anymore. ~Jonathan
bug#39199: Edit in installer doesn't work
If I don't edit the config.scm, the installation process succeeds and the installed system is usable as expected.
bug#39203: GNOME desktop is not displaying battery status
At the top-right corner of the GNOME desktop I expect to see my laptop's battery status. Furthermore, when my laptop's battery drains to a low percentage I expect to see a notification warning me before it dies. This is not the case. I temporarily fixed this by rolling back my system generations, but since I want to add some services I don't want to keep it like this. I don't know what the issue is, but gnome-desktop-service-type and its dependencies are my primary suspects. I ran guix system list-generations and got the following results: The battery status displays with a system built in commit a066e289ab8ea971336515b53dd5340cbdf90904 This commit uses Linux-Libre 5.4.6 in case that's important. It does not display with a system build in commit 6e02ef79f574855db28e23d891db690925119e7b This commit uses Linux-Libre 5.4.12. I hope this information is helpful in fixing this issue. I will work on determining which commit breaks it. -Jesse
bug#39204: r-rgdal: Reading of vector GIS data causes segfault
Hi list,
The same behaviour on two machines.
To reproduce:
guix environment --container --ad-hoc r r-rgdal
Rscript -e 'library(rgdal); dsn <- system.file("vectors", package =
"rgdal")[1]; ogrInfo(dsn=dsn, layer="cities")'
Loading required package: sp
rgdal: version: 1.4-8, (SVN revision 845)
Geospatial Data Abstraction Library extensions to R successfully loaded
Loaded GDAL runtime: GDAL 3.0.2, released 2019/10/28
Path to GDAL shared files:
GDAL binary built with GEOS: TRUE
Loaded PROJ.4 runtime: Rel. 4.9.3, 15 August 2016, [PJ_VERSION: 493]
Path to PROJ.4 shared files: (autodetected)
Linking to sp version: 1.3-2
*** caught segfault ***
address 0x30, cause 'memory not mapped'
Traceback:
1: ogrFIDs(dsn = dsn, layer = layer)
2: ogrInfo(dsn = dsn, layer = "cities")
An irrecoverable exception occurred. R is aborting now ...
sh: rm: command not found
Segmentation fault
Opening with QGIS, which also depends on GDAL (it uses PROJ.6 instead of
PROJ.4, though), works.
WŻ
signature.asc
Description: PGP signature
bug#39195: guix pull switching between profiles/per-user and profiles/default
Hi Jimmy, Jimmy Thrasibule skribis: >> but it’s possible that you were running a version that lacks this fix. > > That's is what I started to understand after playing around a bit. The > Guix version provided into the archive is old so it was failing back > to the "default" profile. Once upgraded, the "new" Guix was trying to > switch back to the "root" profile. > > Now with the $USER environment variable set all is working great. Good to hear. I guess that’s another reason why we should push a new release. Thanks for your feedback! Ludo’.
bug#39195: guix pull switching between profiles/per-user and profiles/default
> What do you mean by “unpacking the store”? I'm actually deploying Guix from the archive at https://ftp.gnu.org/gnu/guix/guix-binary-1.0.1.x86_64-linux.tar.xz in a Docker container. > I believe /var/guix/profiles/default is used because neither $USER nor > $LOGNAME were defined, right? > > This was fixed here: > > > https://git.savannah.gnu.org/cgit/guix.git/commit/?id=c20ba18304ee63f01895f092bb51bc2a9ce3303b This is the piece of code I was looking for to understand where this "default" profile was coming from. The $USER environment variable was indeed not set into the Docker image. Now that it is done, Guix does not complain about the profile anymore. > but it’s possible that you were running a version that lacks this fix. That's is what I started to understand after playing around a bit. The Guix version provided into the archive is old so it was failing back to the "default" profile. Once upgraded, the "new" Guix was trying to switch back to the "root" profile. Now with the $USER environment variable set all is working great.
bug#39177: The installer encountered unexpected problem. Please report to
The attached screenshot might be of interest to you: What you see is the screen of LMint Live USB. You can see that on the left under Devices there is a 50 GB - which is the same amount of GB i allocated a partition yesterday. So might it be the partition I created? if it is then this is weird because I aborted the process before I finished creating the partition. There is also n Error message - which i do not understand. Maybe you will. I hope this actually helps improve Guix in one way or another. Sherab Just like an experience in a dream Everything I now enjoy Will become a mere recollection For what has past will not be seen again Sent from ProtonMail, encrypted email based in Switzerland. Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Sunday, January 19, 2020 10:16 PM, wrote: > OK Folk here's another one for you[this is not complaining this is for you to > see if there is a problem somewhere??]: > > I wanted to try Guix again. > > This time I wanted it on a Librem 13" [instead of Macbook Air][so i can enjoy > the libre wifi] > I wanted to have Guix installed next to my already installed Linux Mint. > > So I created usb live Guix os > I booted into the usb > Got to the bit when it asks about Partitioning method choose the Manual, > created two partitions > 1 50.00GB ext4 / > 70.00GB Free space > > When i was about to continue Format disk? it said we are about to format your > hard disk. All its data will be lost Do you wish to continue? > I promptly clicked exit > > then the installation menu window appeared and i clicked Abort > > it took me to local language window where again i clicked exit > > so this cycle of going form one menu to another > Locale language window -> click exit -> installation menu window -> click > Abort -> Local language -> click exit -> locale language menu window->click > exit -> abort ad infinitum > > so I did the only thing I could and that was switching the machine of form > the power button. > > Now I want to boot back to my Linux Mint and the system is stuck it says > Booting from Hard Disk... > > And nothing happens > > When I then boot again to the live usb stick with Guix on it - the previous > partitioning is till there available as if nothing has happened. > > This sounds strange to me. And of course now I cannot boot to my machine. > > Not good. [not the end of the world as well because i have a back up and > another live usb with linux mint on it and it boots fine] > > Sherab > > Just like an experience in a dream > Everything I now enjoy > Will become a mere recollection > For what has past will not be seen again > > Sent from ProtonMail, encrypted email based in Switzerland. > > Sent with ProtonMail Secure Email. > > ‐‐‐ Original Message ‐‐‐ > On Sunday, 19 January 2020 21:49, wisdomli...@protonmail.com wrote: > > > Hi > > Sherab > > Just like an experience in a dream > > Everything I now enjoy > > Will become a mere recollection > > For what has past will not be seen again > > Sent from ProtonMail, encrypted email based in Switzerland. > > Sent with ProtonMail Secure Email. > > ‐‐‐ Original Message ‐‐‐ > > On Sunday, 19 January 2020 21:33, Ludovic Courtès l...@gnu.org wrote: > > > > > Hello, > > > wisdomlight--- via help-g...@gnu.org skribis: > > > > > > > Attached is a photo of my screen. > > > > I am installing on MacBook Air 13” > > > > I had guix already installed but wanted a fresh install. > > > > I used exactly the same usb-image I used before. > > > > So it’s strange that this is happening. > > > > > > What file system type did you select for your partitions? > > > > I don't remember but I always choose ext4 for linux install. so i presume > > it was ext4 > > Also, what > > > > > kind of partitioning did you choose (guided, etc.)? > > > > guided whole disk without seprate home folder > > gpt > > It asked me to have at least one partition with the / mount and when I put > > it it just did not recognize the / > > I had problem afterwards when needed to recover the MacosX - the recovery > > did not recognize the disk. > > MacOS offers a Disk Utility so i fiddled around with somethings there and > > finally managed to make the disk seen and re installed MacOSX > > > > > BTW, note that, for Guix System, doing a “fresh install” doesn’t buy you > > > much in the sense that ‘guix system reconfigure’ amounts to doing a > > > “fresh install”: the result is the same. > > > > Yeah - I got impatient!!! > > > > > Thanks for your report! > > > > Pleasure > > > > > Ludo’. > > > > Sherab
bug#39195: guix pull switching between profiles/per-user and profiles/default
Hi Ludo, On Mon, 20 Jan 2020 at 16:46, Ludovic Courtès wrote: > Good to hear. I guess that’s another reason why we should push a new > release. I even propose that Guix bumps the minor version each time core-updates or staging is merged. :-) Zero cost for us to bump the minor version. And the plus are: - a bit easier to navigate; because there more tags in the repo ;-) - non rolling release users expect version numbering; other said current Debian or Ubuntu users are "afraid" to "pull" and be in "unstable", so they jump only from version to version. We could add a policy about the bumping the minor version. What do you think? Cheers, simon
bug#39204: r-rgdal: Reading of vector GIS data causes segfault
Hi,
Thank you for reporting.
The issue is that the error is not catched at build time. It is not
expected. This package should fail and not say "successfully built".
Well, this needs more investigation.
--8<---cut here---start->8---
$ guix build r-rgdal --check --no-grafts -K
[...]
phase `install' succeeded after 19.0 seconds
starting phase `check'
Testing examples for package ‘rgdal’
/gnu/store/dnb6fzp5295fcda66dnjk2y51mcva20f-r-minimal-3.6.2/lib/R/bin/BATCH:
line 60: 598 Segmentation fault ${R_HOME}/bin/R -f ${in}
${opts} ${R_BATCH_OPTIONS} > ${out} 2>&1
[...]
successfully built /gnu/store/7spmagnk5fycwxsigdypwkmk4kazbw7a-r-rgdal-1.4-8.drv
note: keeping build directory `/tmp/guix-build-r-rgdal-1.4-8.drv-0'
/gnu/store/dgkyzlasbqsxcsfk3n3bgmhrpg447f55-r-rgdal-1.4-8
--8<---cut here---end--->8---
Good catch! :-)
All the best,
simon
--
$ guix describe
Generation 68 Jan 16 2020 15:57:09(current)
guix d14e474
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: d14e4745b36a835c6babd5b5f5562e12294cd9cf
bug#39203: GNOME desktop is not displaying battery status
Update: Some testing reveals this bug was introduced somewhere between 10576acbbf496a051d488c2832f1e474ef6074f3 and d75a0cd98649c610c8c6ed05011233a49af156e9 I'm going to continue looking for the exact commit. I'll report when I find it. I have some suspicions, but it's better to know for certain. What is the protocol for undoing a commit that breaks something? On Mon, 2020-01-20 at 08:34 -0700, Jesse Gibbons wrote: > At the top-right corner of the GNOME desktop I expect to see my > laptop's battery status. Furthermore, when my laptop's battery drains > to a low percentage I expect to see a notification warning me before > it > dies. This is not the case. > > I temporarily fixed this by rolling back my system generations, but > since I want to add some services I don't want to keep it like this. > I > don't know what the issue is, but gnome-desktop-service-type and its > dependencies are my primary suspects. > > I ran guix system list-generations and got the following results: > > The battery status displays with a system built in commit > a066e289ab8ea971336515b53dd5340cbdf90904 > This commit uses Linux-Libre 5.4.6 in case that's important. > > It does not display with a system build in commit > 6e02ef79f574855db28e23d891db690925119e7b > This commit uses Linux-Libre 5.4.12. > > I hope this information is helpful in fixing this issue. I will work > on > determining which commit breaks it. > > -Jesse > > > >
bug#39209: Guix-commits digest settings
Hello, would it be possible for the Guix-commits list administrator to tune the Digest settings, so as to reduce the numbers of Digest emails sent each day? I'm using Digest mode, but still receive about 8-15 emails per day. One thing that might help is to increase the number of messages that can be lumped into one digest: I frequently receive two or three emails within 30 seconds of each other, than have nine messages in each. I think you can adjust also how long the system waits before creating a new digest. -- Christopher Howard Enterprise Solutions Manager Alaska Satellite Internet PO Box 70, Ester, AK 99725 3239 La Ree Way, Fairbanks, AK 99709 907.451.0088 1.888.396.5623 www.alaskasatelliteinternet.com
bug#39203: GNOME desktop is not displaying battery status
It looks like the problem was introduced in df45af90413906b18710d8c51c44afd5b92d6db6 when upower was updated to version 99.11. I also expect it is related to gnome-tweaks, which is out of date. I'm going to see if updating gnome-tweaks fixes it. If so, I'll send an update patch. If not, we can determine if it's worth reverting upower. On Mon, 2020-01-20 at 13:41 -0700, Jesse Gibbons wrote: > Update: > Some testing reveals this bug was introduced somewhere between > 10576acbbf496a051d488c2832f1e474ef6074f3 and > d75a0cd98649c610c8c6ed05011233a49af156e9 > > I'm going to continue looking for the exact commit. I'll report when > I > find it. I have some suspicions, but it's better to know for certain. > > What is the protocol for undoing a commit that breaks something? > > On Mon, 2020-01-20 at 08:34 -0700, Jesse Gibbons wrote: > > At the top-right corner of the GNOME desktop I expect to see my > > laptop's battery status. Furthermore, when my laptop's battery > > drains > > to a low percentage I expect to see a notification warning me > > before > > it > > dies. This is not the case. > > > > I temporarily fixed this by rolling back my system generations, but > > since I want to add some services I don't want to keep it like > > this. > > I > > don't know what the issue is, but gnome-desktop-service-type and > > its > > dependencies are my primary suspects. > > > > I ran guix system list-generations and got the following results: > > > > The battery status displays with a system built in commit > > a066e289ab8ea971336515b53dd5340cbdf90904 > > This commit uses Linux-Libre 5.4.6 in case that's important. > > > > It does not display with a system build in commit > > 6e02ef79f574855db28e23d891db690925119e7b > > This commit uses Linux-Libre 5.4.12. > > > > I hope this information is helpful in fixing this issue. I will > > work > > on > > determining which commit breaks it. > > > > -Jesse > > > > > > > >
bug#38562: the installer crash when pressing shift+f2 or f12
Hi Brice, Brice Waegeneire skribis: > Using the installer guix-system-install-1.0.1.x86_64-linux.iso it > crash at least on the first page, the language selection one, when > pressing shift+f2 or f12. The dumps are attached. Good catch! Fixed in commit 37eda8c044d7923da36f2857040d48335ca6f439. Ludo’.
bug#39199: Edit in installer doesn't work
Hi Jonathan, Jonathan Brielmaier skribis: > I followed Ludo's call for testing the installer. I built an installer > image from commit da76518. I couldn't find anything installer related on > master branch since then. You can found the image here: > https://brielmaier.net/guix-system-install-1.0.1-1.da76518.x86_64-linux.iso Thanks a lot for testing! > I'm testing in the Hetzner "Cloud", so basically in a VM with > VGA/Display-output over HTTP. Everything is smooth until I click "Edit" > at the end. I add some stuff (vim, screen packages) to the config.scm in > nano, save it and then I click on "OK". Instead of the starting the > actual installation, I get back to the very beginning of the > installation proccess (choose locale). I believe commit 48659aa22170a252c9b2e60f16fbe9f83a6deba4 fixes it. Thanks, Ludo’.
bug#39203: GNOME desktop is not displaying battery status
It appears gnome-tweaks does not fix this issue. I'm out of ideas. Please help! On Mon, 2020-01-20 at 15:01 -0700, Jesse Gibbons wrote: > It looks like the problem was introduced in > df45af90413906b18710d8c51c44afd5b92d6db6 when upower was updated to > version 99.11. I also expect it is related to gnome-tweaks, which is > out of date. > > I'm going to see if updating gnome-tweaks fixes it. If so, I'll send > an > update patch. If not, we can determine if it's worth reverting > upower. > > On Mon, 2020-01-20 at 13:41 -0700, Jesse Gibbons wrote: > > Update: > > Some testing reveals this bug was introduced somewhere between > > 10576acbbf496a051d488c2832f1e474ef6074f3 and > > d75a0cd98649c610c8c6ed05011233a49af156e9 > > > > I'm going to continue looking for the exact commit. I'll report > > when > > I > > find it. I have some suspicions, but it's better to know for > > certain. > > > > What is the protocol for undoing a commit that breaks something? > > > > On Mon, 2020-01-20 at 08:34 -0700, Jesse Gibbons wrote: > > > At the top-right corner of the GNOME desktop I expect to see my > > > laptop's battery status. Furthermore, when my laptop's battery > > > drains > > > to a low percentage I expect to see a notification warning me > > > before > > > it > > > dies. This is not the case. > > > > > > I temporarily fixed this by rolling back my system generations, > > > but > > > since I want to add some services I don't want to keep it like > > > this. > > > I > > > don't know what the issue is, but gnome-desktop-service-type and > > > its > > > dependencies are my primary suspects. > > > > > > I ran guix system list-generations and got the following results: > > > > > > The battery status displays with a system built in commit > > > a066e289ab8ea971336515b53dd5340cbdf90904 > > > This commit uses Linux-Libre 5.4.6 in case that's important. > > > > > > It does not display with a system build in commit > > > 6e02ef79f574855db28e23d891db690925119e7b > > > This commit uses Linux-Libre 5.4.12. > > > > > > I hope this information is helpful in fixing this issue. I will > > > work > > > on > > > determining which commit breaks it. > > > > > > -Jesse > > > > > > > > > > > >
bug#39194: help for non-root users to start using
Hi Ludo,
On +2020-01-19 23:12:43 +0100, Ludovic Courtès wrote:
> Hi Matt,
>
> Matt Wette skribis:
>
> > This guix-1.0.1 on x86_64 Fedora 30.
> >
> > After installing as root, it's not clear from the manual how users
> > should start.
> > I found out "guix pull" is the right thing.
> > Maybe add that to the manual? (Or add a "guix init" command.)
>
> “guix pull” brings you an up-to-date Guix, which is a good thing, but
> you don’t _have_ to run it to get started.
>
> > Here is the error that I get w/o "guix pull":
> >
> > [mwette@localhost ~]$ guix install hello
> > Backtrace:
> > 8 (primitive-load "/usr/local/bin/guix")
> > In guix/ui.scm:
> > 1813:12 7 (run-guix-command _ . _)
> > In ice-9/boot-9.scm:
> > 829:9 6 (catch _ _ # ?)
> > 829:9 5 (catch _ _ # ?)
> > In guix/scripts/package.scm:
> > 948:10 4 (_)
> > In guix/status.scm:
> > 768:4 3 (call-with-status-report _ _)
> > In guix/scripts/package.scm:
> > 956:14 2 (_)
> > In guix/build/syscalls.scm:
> > 1127:14 1 (call-with-file-lock/no-wait _ # ?)
> > In ice-9/boot-9.scm:
> > 777:6 0 (throw "open-file" "~A: ~S" ("No such file or direc?" ?) ?)
> >
> > ice-9/boot-9.scm:777:6: In procedure throw:
> > In procedure throw: Wrong type argument in position 1: open-file
>
> I believe this is fixed by commit 7842ddcbc118cbc2799e22651732b7cdc06b93ee.
>
Did that commit cause an automatic update to the tarball
found and used by the binary install script [1] ??
[1] https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh
The latter defines GNU_URL="https://ftp.gnu.org/gnu/guix/";
as its source of tarballs and signatures. Looking at that URL with
a browser, I see
--8<---cut here---start->8---
[ ]guix-binary-1.0.1.x86_64-linux.tar.xz 2019-05-19 16:54 60M
[ ]guix-binary-1.0.1.x86_64-linux.tar.xz.sig 2019-05-19 16:54 833
--8<---cut here---end--->8---
and checking on the date of commit 7842dd, I get
--8<---cut here---start->8---
commit 7842ddcbc118cbc2799e22651732b7cdc06b93ee
Author: Ludovic Courtès
Date: Sun Jan 19 22:52:31 2020 +0100
guix package: Create profiles/per-user/$USER upfront.
Fixes .
Reported by Matt Wette .
* guix/scripts/package.scm (build-and-use-profile): Move
'ensure-default-profile' call to...
(process-actions): ... here.
--8<---cut here---end--->8---
So for a script user, 2019-05-19 16:54 tarball vs Sun Jan 19 22:52:31 2020 fix
appears to be a problem :)
I doctored the script [1] to do everything but the installing part,
to make sure what tarball was being used by my system. Here is its output:
--8<---cut here---start->8---
[05:53 ~/bs]$ ./get-guix-ver.sh
░░░ ░░░
░░▒▒░ ░▒▒░░
░░▒░░░ ░░░▒░
░▒▒▒░░▒ ░░░▒▒░
░░ ░░
▒ ░░
▒ ░
░▒ ░
▒ ░
▒ ░
░▒░
▒▒░░░
▒▒░
_ _ _ ___ _
/ | \ | | | | | / | (_)
| | __| \| | | | | | | __ _ _ ___ __
| | |_ | . ' | | | | | | |_ | | | | \ \/ /
| |__| | |\ | |__| | | |__| | |_| | |> <
\_|_| \_|\/ \_|\__,_|_/_/\_
This script is a modification of the guix-install.sh script
recommended in the on-line guix manual section on binary
installation [1] where the actual script is also linked [2].
It normally installs GNU Guix on your system, but was modified
by commenting out the actual installation parts, retaining
determination of the release for your system and checking
the signature. In addition sha1 digests of the tarball
and the original and modified scripts are also provided.
[1] https://guix.gnu.org/manual/en/html_node/Binary-Installation.html
[2] https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh
This modified version does not need to be run as root.
https://www.gnu.org/software/guix/
Press return to continue...
[1579528426.548]: Starting installation (Mon 20 Jan 2020 05:53:46 AM PST)
[1579528426.550]: [ PASS ] verification of required commands completed
[1579528426.574]: [ INFO ] init system is: systemd
[1579528426.576]: [ INFO ] system is x86_64-linux
[1579528427.114]: [ PASS ] Release for your system:
guix-binary-1.0.1.x86_64-linux
[1579528427.116]: [ INFO ] Downloading Guix release archive
guix-binary-1.0.1.x86_64-linux.tar.xz
100%[==>] 59.66M 7.05MB/s
in 9.2s
guix-binary-1.0.1.x86_64-linux.tar.xz.s
100%[==>] 833 --.-KB/s
in 0s
bug#38521: guix package: error: build of `...-youtube-viewer-3.5.8.drv' failed
FWIW, I recently updated youtube-viewer to version 3.7.0. That version contains a new port to perl-gtk3, so whoever feels like packaging that perl module can go right ahead ;) `~Eric - On Jan 15, 2020, at 10:16 PM, Ludovic Courtès l...@gnu.org wrote: > Hi Pierre, > > Pierre Neidhardt skribis: > >> I've pushed a fix in 8fcb607780dc9809949c573865c5e1a04770d0c5. >> The test was a benign check that didn't match pixbuf's behaviour: >> >> https://gitlab.gnome.org/GNOME/perl-gtk2/issues/3 > > Thanks for fixing it, now we can upgrade ‘youtube-viewer’ again. :-) > > Ludo’. -- `~Eric
