bug#20497: GuixSD installation - Build of system.drv failed
Hello, Thank you for your reply. The GuixSD version is 0.8.1. I figured part of the problem was with libarchive not being the pre-built binary. I even tried reassuring that hydra was authorized, which apparently had no effect on the outcome. Also, while using Guix as a package manager on my host system (Fedora 21), I attempted to install the package 'dfc' from source (not binary) and I encountered the libarchive-3.1.2.drv error there as well, so I checked the build log located at /tmp/nix-build*-libarchive-3.1.2.drv/.../test_option_b.log, and it mentioned that "File archive1.tar has size 3072, expected 2048" and that "bsdtar does not pad archives written directly to regular files". I hope this information helps narrow down the issue. Do you have any suggestions as to how this could be resolved? Best Regards, Jeffrey On Mon, May 04, 2015 at 11:48:32PM +0200, Ludovic Courtès wrote: > Hi, > > Jeffrey Serio skribis: > > > "I've attempted installing GuixSD a few times on the same PC (Different > > USBs, re-downloaded the image, etc.) > > and always get the same error-- that the build of system.drv failed. > > I'm not exactly sure where to go from > > this error message, though, and I was wondering if someone did... > > http://pastebin.com/3vG5GE4f"; > > The log at pastebin.com reads: > > 55. builder for 'gnu/store/[... long string of characters > ...]-libarchive-3.1.2.drv' failed with exit code 1 > [...] > 62. cannot build derivation '/gnu/store/[... long string ...]-system.drv': > 1 dependencies couldn't be built > > This means that, to build the system configuration, Guix tried to build > libarchive, which failed. > > It also means that somehow hydra.gnu.org was not providing pre-built > binaries for libarchive & co., perhaps because they have been GC’d. > > What GuixSD version is it? > > Thanks for your report! > > Ludo’.
bug#20497: GuixSD installation - Build of system.drv failed
Jeffrey Serio skribis: > Thank you for your reply. The GuixSD version is 0.8.1. I figured part of > the problem was with libarchive not > being the pre-built binary. I even tried reassuring that hydra was > authorized, which apparently had no effect > on the outcome. Also, while using Guix as a package manager on my host > system (Fedora 21), I attempted to > install the package 'dfc' from source (not binary) and I encountered the > libarchive-3.1.2.drv error there as well, so I checked the build log located > at > /tmp/nix-build*-libarchive-3.1.2.drv/.../test_option_b.log, and it mentioned > that "File archive1.tar has size > 3072, expected 2048" and that "bsdtar does not pad archives written directly > to regular files". I hope this > information helps narrow down the issue. Do you have any suggestions as to > how this could be resolved? One problem is that hydra.gnu.org didn’t keep the pre-built binaries. We ought to fix it, but our current server is quite limited in resources (hopefully we will change it soon.) As for the exact build issue, I don’t know. You may be able to work around it by running ‘guix pull’ right before running ‘guix system init’ in the installation image (likewise on your Fedora system: just run ‘guix pull’ before trying to install software.) Besides, note that 0.8.2 will hopefully be released within two weeks. Ludo’.
bug#20255: 'search-paths' should respect both user and system profile.
Ludovic Courtès writes: > 宋文武 skribis: > >> Or better to generate a 'profile' script for each manifest, and then >> merged in shell level, so it can work out-of-the-box. How about: >> - /etc/profile: >> # configuration for the whole system goes here. >> # shouldn't refer profile paths. >> export LANG=en_US.utf8 >> export SSL_CERT_DIR=/etc/ssl/certs >> export LINUX_MODULE_DIRECTORY=/run/booted-system/kernel/lib/modules >> [...] >> >> source /run/current-system/profile/etc/profile >> >> if [ -f $HOME/.guix-profile/etc/profile ]; then >> source $HOME/.guix-profile/etc/profile >> fi >> >> # honor setuid-programs >> export PATH=/run/setuid-programs:$PATH >> >> - /run/current-system/profile/etc/profile: >> export >> PATH=/run/current-system/profile/bin:/run/current-system/profile/sbin:$PATH >> export MANPATH=/run/current-system/profile/share/man:$PATH >> [...] >> >> - ~/.guix-profile/etc/profile: >> export PATH=~/.guix-profile/bin:~/.guix-profile/sbin:$PATH >> [...] > > There’s a further complication here: ‘profile-derivation’, which builds > the profile, doesn’t know its user-visible name ~/.guix-profile. It > just knows its store file name. However, we don’t want etc/profile to > read: > > export PATH=/gnu/store/...-profile/bin:$PATH > > because then, the user’s environment variables in a running session > would keep pointing to a given profile generation. Indeed. Run guix to install a package should make it available immediately. Currently, we have 'PATH=~/.guix-profile/bin' in profile and print hint for additional variables. (Note that when profile changes, even we build all variables with the location they going to be, a hint or re-source is still needed when the new profile bring new variables.) > > So we have to tell ‘profile-generation’ what the user-visible name of > the profile is going to be. Attached is a very rough patch to do that. > This is not so nice because all user interfaces will now have to pass > that #:target parameter or etc/profile will be “wrong.” > > Another option would be to simply run: > > eval `guix package -p ~/.guix-profile --search-paths` > > This has two downsides: > > 1. It takes ~200 ms to run on my laptop, which can maybe be > noticeable; OTOH it’s only for interactive shells, so maybe that’s > OK. > > 2. If there’s a manifest format change and /etc/profile calls a ‘guix’ > command that cannot handle the manifest format (because it’s older > than the ‘guix’ used to build the profile), then it doesn’t work at > all (that’s a bit contrived, but not completely impossible.) > > Thoughts? > How about using a shell variable as input for the location: (replace /gnu/store/xxx with $GUIX_PROFILE) # etc/profile export PATH=$GUIX_PROFILE/bin:$PATH export MANPATH=$GUIX_PROFILE/share/man:$MANPATH ... Then when 'source' it, we pass the location: (we did know where $GUIX_PROFILE is when do the 'source') # ~/.bash_profile GUIX_PROFILE=$HOME/.guix-profile if [ -f $GUIX_PROFILE/etc/profile ]; then . $GUIX_PROFILE/etc/profile fi # /etc/profile GUIX_PROFILE=/run/current-system/profile source $GUIX_PROFILE/etc/profile
bug#20255: 'search-paths' should respect both user and system profile.
宋文武 skribis: > How about using a shell variable as input for the location: > (replace /gnu/store/xxx with $GUIX_PROFILE) > > # etc/profile > export PATH=$GUIX_PROFILE/bin:$PATH > export MANPATH=$GUIX_PROFILE/share/man:$MANPATH > ... > > Then when 'source' it, we pass the location: > (we did know where $GUIX_PROFILE is when do the 'source') > > # ~/.bash_profile > GUIX_PROFILE=$HOME/.guix-profile > if [ -f $GUIX_PROFILE/etc/profile ]; then > . $GUIX_PROFILE/etc/profile > fi > > # /etc/profile > GUIX_PROFILE=/run/current-system/profile > source $GUIX_PROFILE/etc/profile Yes, but we would also like users to be able to source ~/.guix-profile/etc/profile themselves directly, and it wouldn’t be nice to ask them to set GUIX_PROFILE before sourcing it. Ludo’.
