bug#39976: next browser fails to build

[Tomáš Čech]

Hi!

On Sat, Mar 07, 2020 at 05:13:00PM +0100, Pierre Neidhardt wrote:

Hi!

Glad to see you are interested in Next! :)

Next 1.5.0 should work rather well on Guix.

However the SBCL 2.0.2 update broke it.  But no worries, I've just
pushed a fix so you should able to install Next after a `guix pull'.

I'm hard at work with Next 2.0 and it should fix some long standing
issues that are still in Next 1.5.0.


Thanks for swift response and reaction. I can confirm that new pull
fixes the issue for me.


Stay tuned!


I will, good luck with 2.0!

Best regards,

Tomáš Čech


PS: I used bug-tracker e-mail in initial e-mail but you got the e-mail
   without assigned bug. So your response probably opened new one -
   please, be so kind and close it.


signature.asc
Description: PGP signature

bug#39976: next browser fails to build

[Tomáš Čech]

Hi,

what is the status of next browser?

When I noticed there is such thing I was happy as it could be
replacement for Conkeror and even with better language to use

I used to have crashes pretty often and usually blamed WebKit for that...

But for some time I'm not able even to build it.

It seems that I have the same issue as can be seen here:

 https://ci.guix.gnu.org/log/91snb4sd5c6xrp930s3v5a5yrxfr0n3h-next-1.5.0


Thanks in advance,

Tomáš Čech


signature.asc
Description: PGP signature

bug#33832: The VPN service 'org.freedesktop.NetworkManager.openvpn' was not installed.

[Tomáš Čech]

Hi!

On Mon, Jun 24, 2019 at 09:34:34PM +0200, Jelle Licht wrote:

Hi S_W, Maxim

Tomáš Čech  writes:


Hi Ludo,
[...]

But with Maxim's DBus related patches and my NM patch it seemed to be
starting daemons at least.


Do you still have the patches for these changes lying around? I am
trying to get network-manager-vpnc packaged+working, but it seems this
issue will also need to be solved first.


I didn't have time to refresh it to our current version - it's just in the mail:

https://www.mail-archive.com/bug-guix@gnu.org/msg11776.html

Best regards,

S_W


signature.asc
Description: Digital signature

bug#33832: The VPN service 'org.freedesktop.NetworkManager.openvpn' was not installed.

[Tomáš Čech]

Hi Ludo,

On Wed, Mar 06, 2019 at 02:19:20PM +0100, Ludovic Courtès wrote:

Hi Tomáš,

Tomáš Čech  skribis:


On Thu, Jan 10, 2019 at 07:51:07AM -0500, Maxim Cournoyer wrote:


[...]


To be continued...


You seem to be on very right track. There is another unexpect problem
- NetworkManager doesn't seem to respect NM_VPN_PLUGIN_PATH in the
right place.

Try this quick patch:

From fc8bbfe018b4f19fb383391c71e3518a9c46e0f3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tom=C3=A1=C5=A1=20=C4=8Cech?= 
Date: Sun, 17 Feb 2019 13:23:43 +0100
Subject: [PATCH] respect NM_VPN_PLUGIN_DIR


Does this patch solve the problem for you?  How did you get there?  :-)


Partially. I was not interested in OpenVPN, but L2TP/IPSec VPN (my new
employer is using) so I was using network-manager-l2tp module with the same 
problems.
(Actually it is much more painful because it requires some more
patching of xl2tpd and strongswan to bring it up together... They have
somehow hardcoded locations for configuration and secrets...)

But with Maxim's DBus related patches and my NM patch it seemed to be
starting daemons at least.

Best regards,

S_W


signature.asc
Description: Digital signature

bug#33832: The VPN service 'org.freedesktop.NetworkManager.openvpn' was not installed.

[Tomáš Čech]

On Thu, Jan 10, 2019 at 07:51:07AM -0500, Maxim Cournoyer wrote:

Debugging a bit further, it seems that my change to the
network-manager-service-type had the following effect:

A file populated at /etc/dbus-1/system-local.conf now has an include
directive for network-manager-openvpn:

--8<---cut here---start->8---
/gnu/store/gw3ckmw2pihc44d23lc8pipfw7wr16g7-network-manager-openvpn-1.8.0/etc/dbus-1/system.d
--8<---cut here---end--->8---

There is no /etc/dbus-1/system.conf file, which usually should source
the above system-local.conf, although the package holds a copy of it
such as
/gnu/store/5bda3bgy871dyb9cna4k7gnz002j88rq-dbus-1.12.6/share/dbus-1/system.conf,
and this file has:

--8<---cut here---start->8---

 /etc/dbus-1/system-local.conf
--8<---cut here---end--->8---

I'm not sure if it works though, because using the Emacs dbus support to
view the available definitions, I cannot see the ones from the
system-local.conf file:

--8<---cut here---start->8---
(require 'dbus)
(dbus-list-activatable-names ':system)

;; Results:
("org.freedesktop.DBus";
"org.freedesktop.UPower"   ;from /etc/dbus-1/system-services
"org.freedesktop.GeoClue2" ;from /etc/dbus-1/system-services
"org.freedesktop.login1"   ;from /etc/dbus-1/system-services
"org.freedesktop.UDisks2"  ;from /etc/dbus-1/system-services
"org.freedesktop.ColorHelper"  ;from /etc/dbus-1/system-services
"org.freedesktop.PolicyKit1"   ;from /etc/dbus-1/system-services
"org.freedesktop.Accounts" ;from /etc/dbus-1/system-services
"org.freedesktop.ColorManager" ;from /etc/dbus-1/system-services
"org.freedesktop.nm_dispatcher")  ;from /etc/dbus-1/system-services
--8<---cut here---end--->8---

So it could be that the system-local.conf file is not read in.

I've tried stracing the dbus-daemon (by attaching to it) as suggested by
Ludovic on #guix, but that doesn't mention anything about reading the
files.

So, to debug this further, I've added the documentation to dbus [1] and
in `man dbus-daemon`, we can read:



--8<---cut here---start->8---
DEBUGGING
  If you're trying to figure out where your messages are going or why you 
aren't getting messages, there are
  several things you can try.

  Remember that the system bus is heavily locked down and if you haven't 
installed a security policy file to
  allow your message through, it won't work. For the session bus, this is 
not a concern.

  The simplest way to figure out what's happening on the bus is to run the 
dbus-monitor program, which comes
  with the D-Bus package. You can also send test messages with dbus-send. 
These programs have their own man
  pages.

  If you want to know what the daemon itself is doing, you might consider 
running a separate copy of the daemon
  to test against. This will allow you to put the daemon under a debugger, 
or run it with verbose output,
  without messing up your real session and system daemons.

  To run a separate test copy of the daemon, for example you might open a 
terminal and type:

DBUS_VERBOSE=1 dbus-daemon --session --print-address

  The test daemon address will be printed when the daemon starts. You will 
need to copy-and-paste this address
  and use it as the value of the DBUS_SESSION_BUS_ADDRESS environment 
variable when you launch the applications
  you want to test. This will cause those applications to connect to your 
test bus instead of the
  DBUS_SESSION_BUS_ADDRESS of your real session bus.

  DBUS_VERBOSE=1 will have NO EFFECT unless your copy of D-Bus was compiled 
with verbose mode enabled. This is
  not recommended in production builds due to performance impact. You may 
need to rebuild D-Bus if your copy
  was not built with debugging in mind. (DBUS_VERBOSE also affects the 
D-Bus library and thus applications
  using D-Bus; it may be useful to see verbose output on both the client 
side and from the daemon.)

  If you want to get fancy, you can create a custom bus configuration for 
your test bus (see the session.conf
  and system.conf files that define the two default configurations for 
example). This would allow you to
  specify a different directory for .service files, for example.
--8<---cut here---end--->8---

This should help in further debbugging the issue, along with this local
definition that enables the verbose mode of dbus:

--8<---cut here---start->8---
gnu/packages/glib.scm | 11 +++

modified   gnu/packages/glib.scm
@@ -68,6 +68,7 @@
  ;; Export variables up-front to allow circular dependency with the 'xorg'
  ;; module.
  

bug#30760: guix system init broken on non GuixSD

[Tomáš Čech]

On Mon, Mar 12, 2018 at 01:24:37PM +0100, Danny Milosavljevic wrote:

I'm afraid this is still not correct.

# guix system init config.scm /mnt/mnt/
...
config.scm:64:9: error: you may need these modules in the initrd for 
/dev/nvme0n1p2: shpchp
hint: Try adding them to the `initrd-modules' field of your `operating-system' 
declaration, along these lines:

  (operating-system
;; ...
(initrd-modules (append (list "shpchp")
%base-initrd-modules)))

I don't have `shpchp` as a module as I have it compiled into kernel
directly. Can I somehow disable the check?


I think it's a good idea to add a command-line switch that disables the check.

But then people will just disable the check always and it won't improve until
it's correct.  It's still a good idea to give people the choice.


Just small note - In my case I always run `system build` before
`system init` so I don't mind having any deeper analysis based on code
and configuration as long as it is correct. Maybe more people is using
same approach.

Best regards,

S_W


signature.asc
Description: Digital signature

bug#30760: guix system init broken on non GuixSD

[Tomáš Čech]

On Sun, Mar 11, 2018 at 10:38:18PM +0100, Ludovic Courtès wrote:

Tomáš Čech  skribis:


In ice-9/boot-9.scm:
   829:9  1 (catch system-error # …)
In gnu/system/linux-initrd.scm:
   361:6  0 (_)

gnu/system/linux-initrd.scm:361:6: known-module-aliases: unbound variable


My bad!  Danny eventually fixed it in
0803ddf2677ead5e9d8ef698316125e0c8b9c998.


I'm afraid this is still not correct.

# guix system init config.scm /mnt/mnt/
...
config.scm:64:9: error: you may need these modules in the initrd for 
/dev/nvme0n1p2: shpchp
hint: Try adding them to the `initrd-modules' field of your `operating-system' 
declaration, along these lines:

 (operating-system
   ;; ...
   (initrd-modules (append (list "shpchp")
   %base-initrd-modules)))

I don't have `shpchp` as a module as I have it compiled into kernel
directly. Can I somehow disable the check?

Thanks.

S_W


signature.asc
Description: Digital signature

bug#30760: guix system init broken on non GuixSD

[Tomáš Čech]

On Sat, Mar 10, 2018 at 12:19:52AM +0100, Ludovic Courtès wrote:

Danny Milosavljevic  skribis:


[huge build]

The current tradeoff is to make that diagnostic based on the running
kernel, even if it’s an approximation.


Ah, good point.


If that’s fine with you I’d like to fix this bug with the conservative
patch below.


Sure, looks good.


Pushed as 8d5c14edf5a6d01f859b1aa00c836ffdb5ddecf4.


I'm afraid that now it leads to:

Backtrace:
12 (primitive-load "/usr/bin/guix")
In guix/ui.scm:
1501:12 11 (run-guix-command _ . _)
In ice-9/boot-9.scm:
  829:9 10 (catch _ _ # …)
  829:9  9 (catch _ _ # …)
In guix/scripts/system.scm:
 1180:8  8 (_)
 1052:6  7 (process-action _ _ _)
In guix/store.scm:
1443:24  6 (run-with-store _ _ #:guile-for-build _ #:system _ # _)
In guix/scripts/system.scm:
1065:13  5 (_ _)
  764:4  4 (perform-action init #< kernel: # …)
In srfi/srfi-1.scm:
  640:9  3 (for-each # …)
In gnu/system/linux-initrd.scm:
  360:4  2 (check-device-initrd-modules "/dev/nvme0n1p2" ("ahci" …) …)
In ice-9/boot-9.scm:
  829:9  1 (catch system-error # …)
In gnu/system/linux-initrd.scm:
  361:6  0 (_)

gnu/system/linux-initrd.scm:361:6: known-module-aliases: unbound variable


This is part of my config:

(initrd (lambda (file-system . rest)
 (raw-initrd file-systems
 #:linux linux-x1-sw1
 #:linux-modules '()
 #:helper-packages '(linux-firmware-initrd-x1-sw1)
 #:mapped-devices mapped-devices)))


I don't have any modules to be loaded in initrd, kernel is compiled
using my configuration which fits my needs and follows the HW it will run on.

S_W


signature.asc
Description: Digital signature

bug#30760: guix system init broken on non GuixSD

[Tomáš Čech]

`guix system init` seems to be broken for non GuixSD distirbutions:
When I tried it on openSUSE:

# guix system --no-bootloader init /Devel/git/guix-config/config.scm /mnt/mnt/
;;; note: source file /Devel/extra/gnu/packages/connman.scm
;;;   newer than compiled /root/.config/guix/latest/gnu/packages/connman.go
;;; note: source file /Devel/extra/gnu/packages/connman.scm
;;;   newer than compiled 
/usr/lib64/guile/2.2/site-ccache/gnu/packages/connman.go
;;; note: source file /Devel/extra/gnu/packages/connman.scm
;;;   newer than compiled 
/usr/lib64/guile/2.2/site-ccache/gnu/packages/connman.go
guix system: error: open-file: No such file or directory: 
"/run/booted-system/kernel/lib/modules/4.15.6-1-default/modules.alias"

4.15.6-1-default is version of my running kernel, but not defined as package - 
it is not expected to be used for guix call.

/run/booted-system/ is specific for GuixSD.


signature.asc
Description: Digital signature

bug#28522: Cannot upgrade due to "guix pull" errors

[Tomáš Čech]

On Wed, Sep 20, 2017 at 03:08:59AM +, Adam Bolte wrote:

Hi there,

I'm running Guix 0.10.0 on a Debian stretch box, and I'd like to
upgrade. The box had not been booted for quite some time, hence the
version is somewhat old.

Running `guix pull`, I get the following:


Starting download of /tmp/guix-file.k6X14m
From http://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz...
master.tar.gz  628KiB/s 00:22 | 13.6MiB transferred
unpacking '/gnu/store/i17ynp73h182q1n72a6nqsyxk32fkhhr-guix-latest.tar.gz'...
Your installation is too old and lacks a 'guile2.0-git' package.
Please upgrade to an intermediate version first, for instance with:

 guix pull 
--url=https://git.savannah.gnu.org/cgit/guix.git/snapshot/v0.13.0.tar.gz




And little note based on my recent experience. v0.13.0. doesn't contain
the package neither. Use this as middle stage pull:

 guix pull 
--url=https://git.savannah.gnu.org/cgit/guix.git/snapshot/70bc608503f9029a065026a99ec45dbd0ec631c0.tar.gz

That is the commit which defines missing package.

Best regards,

S_W



signature.asc
Description: PGP signature

bug#27007: boot-parameters are not documented

[Tomáš Čech]

On Tue, May 23, 2017 at 11:31:12AM +0200, Mathieu Othacehe wrote:


Hello,


So how does the ‘menu-entry’ example that Tomáš gave translate with this
new API?  (Apologies for asking, I admit I haven’t fully adjusted to the
new API mentally.  :-))


Well it's still moving :)

We can ask him but I guess something like that :

--8<---cut here---start->8---
(boot-parameters
 (label "openSUSE")
 (root-device #f)
 (boot-name 'grub)
 (store-device #f)
 (store-mount-point "/")
 (kernel "(hd0,msdos1)/vmlinuz")
 (kernel-arguments (list  "root=/dev/penguin/opensuse"  
"init=/usr/lib/systemd/systemd"))
 (initrd "(hd0,msdos1)/initrd"))
--8<---cut here---end--->8---

Note that root-device, boot-name, store-device and store-mount-point are
useless here.


I came with something similar:

(boot-parameters
 (label "openSUSE")
 (root-device "/dev/penguin/opensuse")
 (boot-name 'grub)
 (store-device "(hd0,msdos1)")
 (store-mount-point "/")
 (kernel "(hd0,msdos1)/vmlinuz")
 (kernel-arguments '("root=/dev/penguin/opensuse"
"init=/usr/lib/systemd/systemd"))
 (initrd "(hd0,msdos1)/initrd"))

Unfortunately useless entries were still required (I didn't have that
idea with setting them to #f).

I couldn't verify the result configuration yet as I'm facing another,
unrelated problem.

Thanks,

S_W


signature.asc
Description: Digital signature

bug#27007: boot-parameters are not documented

[Tomáš Čech]

On Sat, May 20, 2017 at 10:31:59PM +0200, Mathieu Othacehe wrote:


Hi Tomáš,


My question without answer is - how can I specify bootloader menu entries now?


You're right, you have to pass a  now. The
documentation patch is still in review, you can find it here :

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26339#489

The example has been updated :

--8<---cut here---start->8---
@example
-(menu-entry
+(boot-parameters
  (label "The Other Distro")
-  (linux "/boot/old/vmlinux-2.6.32")
-  (linux-arguments '("root=/dev/sda2"))
+  (root-device "my-root")
+  (boot-name 'grub)
+  (store-device "my-root")
+  (store-mount-point "/")
+  (kernel "/boot/old/vmlinux-2.6.32")
+  (kernel-arguments '("root=/dev/sda2"))
  (initrd "/boot/old/initrd"))
@end example
--8<---cut here---end--->8---

It will maybe change again in the future, I'm not sure 
are our best option here.


It's a bit complicated but much more flexible compared to
menu-entry. 'store-device' and 'store-mount-point' are Guix-centric
parameters and it is not obvious how to configure it for distributions
with kernel and initrd in /boot.



Anyway, let me now if it works for you.


After following these changes I'm able to build system again. I'll
check the result GRUB configuration and report issue if there is one.

Thanks for your help,

S_W


signature.asc
Description: Digital signature

bug#27007: boot-parameters are not documented

[Tomáš Čech]

On Sat, May 20, 2017 at 10:52:34PM +0200, Danny Milosavljevic wrote:

Hi,

there's a doc patch in review by Mathieu (16 May 2017 15:03 +0200, "doc: Adapt to 
multiple bootloader support", bug# 26339) in guix-patches.


As I have seen this feature on ML some time ago already, I didn't
expect to be in between acceptance of both patches. Sorry.



Although I wonder what menu-entries can be used for.  What are you using it for?



Defining other operating system entry:

(menu-entry
 (label "openSUSE")
 (linux "(hd0,msdos1)/vmlinuz")
 (linux-arguments (list  "root=/dev/penguin/opensuse"  
"init=/usr/lib/systemd/systemd"))
 (initrd "(hd0,msdos1)/initrd"))


Best regards,

S_W


signature.asc
Description: Digital signature

bug#27007: boot-parameters are not documented

[Tomáš Čech]

I'm running from GIT with HEAD on 12eecbf0bb798f99454a46c191bb0ec6bdef1aa5.

It seems that menu-entry is still described in documentation

doc/guix.texi:15337

but code seems to abandon the use already in favor of boot-parameters
at least to my level of understanding.

My question without answer is - how can I specify bootloader menu entries now?

TIA,

S_W


signature.asc
Description: Digital signature

bug#25852: Users not updating their installations of Guix

[Tomáš Čech]

On Thu, Mar 09, 2017 at 11:58:12AM +0100, Ludovic Courtès wrote:

Tomáš Čech  skribis:


On Tue, Mar 07, 2017 at 05:22:15PM -0500, Leo Famulari wrote:

On Tue, Mar 07, 2017 at 09:58:48PM +0100, Tomáš Čech wrote:

On Tue, Mar 07, 2017 at 02:51:18PM -0500, Leo Famulari wrote:
> This will take effect for the next release of Guix; it addresses a
> problem that arises when somebody installs the binary release of Guix.
>
> I'm not addressing downstream packages of Guix with this commit.

I'm sorry, I may not understand correctly your answer.

Are you saying that situation when user freshly installs Guix on
system with systemd (and thus has empty /gnu/store)?


The "fix" I pushed will help anyone who does a new installation of Guix
on a Systemd or Upstart-based system, after the next release of Guix.


Unless I'm missing some other commit, this won't work.

When I perform these steps:
1] ./configure && make && sudo make install (or package installation)
2] mkdir /gnu/store
3] attempt to start daemon will fail as there is no guix-daemon in
  @localstatedir@/guix/profiles/per-user/root/guix-profile/bin/guix-daemon
  because there is no guix-daemon in /gnu/store

Without daemon running you won't be able to make one in that location.


Good point.

To address this, we might actually need to revert
613d0895b92c677e0639d5e77c55043e38e020c8 (that is, keep @bindir@ in the
.service files), and instead replace @bindir@ with @localstatedir@ in
the recipe of the ‘guix’ package.

That way, the install-from-source scenario Tomáš describes above would
work, *and* the binary tarball would refer to localstatedir as Leo
intended.

WDYT?


That will eliminate the problem introduced by the Leo's change but
still keep original problem.

To adress the latter I'm thinking I'll just make simple wrapper script
which will check whether new version in root user's profile exists and
run from @bindir@ if not.

Not the nicest solution but it is safe.

Best regards,

S_W


signature.asc
Description: Digital signature

bug#25852: Users not updating their installations of Guix

[Tomáš Čech]

On Wed, Mar 08, 2017 at 03:45:47AM -0500, Leo Famulari wrote:

On Wed, Mar 08, 2017 at 07:25:42AM +0100, Tomáš Čech wrote:

Unless I'm missing some other commit, this won't work.

When I perform these steps:
1] ./configure && make && sudo make install (or package installation)
2] mkdir /gnu/store
3] attempt to start daemon will fail as there is no guix-daemon in
  @localstatedir@/guix/profiles/per-user/root/guix-profile/bin/guix-daemon
  because there is no guix-daemon in /gnu/store


I haven't used `make install`. Does this change break it? On my system,
the old @bindir@ method didn't yield a usable guix-daemon.service
either, because there is no '/usr/local/bin/guix-daemon'.

The binary tarball that we distribute includes the guix-daemon in its
store, and the '/var/guix/...' path works too.

There were lots of people trying to follow the Binary Installation
instructions in the manual [0] and getting stuck on step 5. They weren't
able to symlink the systemd service file, and they had to edit the file
too.

With this change, the instructions in the manual should work whether or
not the user copies or symlinks the service file.

[0]
https://www.gnu.org/software/guix/manual/html_node/Binary-Installation.html



Thank you for your explanation and your patience. I finally understand
now what you mean with binary installation and understand how it
doesn't break it.

I'll try to fix source installation somehow.

Best regards,

Tomas


signature.asc
Description: Digital signature

bug#25852: Users not updating their installations of Guix

[Tomáš Čech]

On Tue, Mar 07, 2017 at 05:22:15PM -0500, Leo Famulari wrote:

On Tue, Mar 07, 2017 at 09:58:48PM +0100, Tomáš Čech wrote:

On Tue, Mar 07, 2017 at 02:51:18PM -0500, Leo Famulari wrote:
> This will take effect for the next release of Guix; it addresses a
> problem that arises when somebody installs the binary release of Guix.
>
> I'm not addressing downstream packages of Guix with this commit.

I'm sorry, I may not understand correctly your answer.

Are you saying that situation when user freshly installs Guix on
system with systemd (and thus has empty /gnu/store)?


The "fix" I pushed will help anyone who does a new installation of Guix
on a Systemd or Upstart-based system, after the next release of Guix.


Unless I'm missing some other commit, this won't work.

When I perform these steps:
1] ./configure && make && sudo make install (or package installation)
2] mkdir /gnu/store
3] attempt to start daemon will fail as there is no guix-daemon in
  @localstatedir@/guix/profiles/per-user/root/guix-profile/bin/guix-daemon
  because there is no guix-daemon in /gnu/store

Without daemon running you won't be able to make one in that location.

Dead end.

Best regards,

S_W


signature.asc
Description: Digital signature

bug#25852: Users not updating their installations of Guix

[Tomáš Čech]

On Tue, Mar 07, 2017 at 02:51:18PM -0500, Leo Famulari wrote:

On Tue, Mar 07, 2017 at 07:33:30AM +0100, Tomáš Čech wrote:

On Mon, Mar 06, 2017 at 04:34:34PM -0500, Leo Famulari wrote:
> On Mon, Mar 06, 2017 at 10:12:21PM +0100, Ludovic Courtès wrote:
> > Leo Famulari  skribis:
> >
> > > In my opinion, the recent bug #25775 (Can't install packages after guix
> > > pull) [0] exposed a sort of meta-bug: there are a significant number of
> > > users who were still using the guix-daemon from 0.10.0.
> > >
> > > It seems unlikely that they have been updating all of root's
> > > packages except for the guix package. Rather, I bet they never updated
> > > root's packages at all, for ~1 year.
>
> They could have been stuck with an old daemon if they copied the systemd
> or upstart service files we provide.
>
> That problem should be fixed by 613d0895b92c677e0639d5e77c55043e38e020c8
> (build: Don't embed absolute paths in .service and .conf service
> files.).

That is right. But

1) there was no release with this "fix"
2) I (as distro package maintainer) didn't take this patch manually as
  it is fragile and hacky. Have you considered fresh guix installation?


This will take effect for the next release of Guix; it addresses a
problem that arises when somebody installs the binary release of Guix.

I'm not addressing downstream packages of Guix with this commit.


I'm sorry, I may not understand correctly your answer.

Are you saying that situation when user freshly installs Guix on
system with systemd (and thus has empty /gnu/store)?

S_W



signature.asc
Description: Digital signature

bug#25852: Users not updating their installations of Guix

[Tomáš Čech]

On Mon, Mar 06, 2017 at 04:34:34PM -0500, Leo Famulari wrote:

On Mon, Mar 06, 2017 at 10:12:21PM +0100, Ludovic Courtès wrote:

Leo Famulari  skribis:

> In my opinion, the recent bug #25775 (Can't install packages after guix
> pull) [0] exposed a sort of meta-bug: there are a significant number of
> users who were still using the guix-daemon from 0.10.0.
>
> It seems unlikely that they have been updating all of root's
> packages except for the guix package. Rather, I bet they never updated
> root's packages at all, for ~1 year.


They could have been stuck with an old daemon if they copied the systemd
or upstart service files we provide.

That problem should be fixed by 613d0895b92c677e0639d5e77c55043e38e020c8
(build: Don't embed absolute paths in .service and .conf service
files.).


That is right. But

1) there was no release with this "fix"
2) I (as distro package maintainer) didn't take this patch manually as
  it is fragile and hacky. Have you considered fresh guix installation?

Best regards,

S_W


signature.asc
Description: Digital signature

bug#25852: Users not updating their installations of Guix

[Tomáš Čech]

On Sun, Mar 05, 2017 at 09:25:11AM +, Pjotr Prins wrote:

On Sun, Mar 05, 2017 at 08:56:41AM +0100, Tomáš Čech wrote:

And IMHO the best and also "Guix way" could be making guix-daemon aware of
possible newer versions in /gnu/store and execing them instead...


Giving a loud warning should really be sufficient. The Guix way is to
have a system not surprise us by shifting the sand under our feet ;)


Yes, but the surprise is made when your expectations are different
from what is naturally expected.

My expectation is that when `guix pull' is run, it should update whole
guix, not just part (guix - guix-daemon).

Surprise is when it does not do it.

Removing the surprise can be either by splitting the package to make
obvious it is independent part or making `guix pull' able to update
guix-daemon as well.

Loud warning is really sufficient for user (or admin) but not for
distribution package maintainer.

Another option is that I will do the split by myself and take
guix-daemon sources from GIT but I'm sure I'll make much worse job
than you.

Best regards,

S_W


signature.asc
Description: Digital signature

bug#25852: Users not updating their installations of Guix

[Tomáš Čech]

On Sat, Mar 04, 2017 at 05:43:59PM -0500, Leo Famulari wrote:

On Sat, Mar 04, 2017 at 09:29:41PM +0100, Tomáš Čech wrote:

On Thu, Feb 23, 2017 at 04:11:56PM -0500, Leo Famulari wrote:
> In my opinion, the recent bug #25775 (Can't install packages after guix
> pull) [0] exposed a sort of meta-bug: there are a significant number of
> users who were still using the guix-daemon from 0.10.0.
>
> It seems unlikely that they have been updating all of root's
> packages except for the guix package. Rather, I bet they never updated
> root's packages at all, for ~1 year.
>
> I think this is a serious documentation bug.

One problem may be that Guix on top of foreign distribution is not
able to update itself.


I can update my Guix-on-Debian systems without trouble, using the normal
`guix pull && guix package -u .` method.


I'm sorry, I meant guix-daemon here.


I still offer guix-0.12 RPM package for openSUSE installation as there
was no new release. Guix is able to update itself via `guix pull' but
it doesn't affect system installation of guix-daemon.


Interesting, I didn't know there was a distro package for openSUSE.


I'm trying to maintain it for quite a long time already... It's part
of distribution (but not on installation medium :)


For that package, the root user cannot update the guix-daemon?


root user can do anything, but that is not the point here. The point
is that root user interaction is _required_.

I may alter guix-daemon service file to use
/root/.guix-profile/... path that that is also unsafe hack relying
that root user will not break his stuff.

Splitting packages into 2 could be another way to do it, better, quite natural.

And IMHO the best and also "Guix way" could be making guix-daemon aware of
possible newer versions in /gnu/store and execing them instead...

Best regards,

S_W



signature.asc
Description: Digital signature

bug#25852: Users not updating their installations of Guix

[Tomáš Čech]

On Thu, Feb 23, 2017 at 04:11:56PM -0500, Leo Famulari wrote:

In my opinion, the recent bug #25775 (Can't install packages after guix
pull) [0] exposed a sort of meta-bug: there are a significant number of
users who were still using the guix-daemon from 0.10.0.

It seems unlikely that they have been updating all of root's
packages except for the guix package. Rather, I bet they never updated
root's packages at all, for ~1 year.

I think this is a serious documentation bug.


One problem may be that Guix on top of foreign distribution is not
able to update itself.

I still offer guix-0.12 RPM package for openSUSE installation as there
was no new release. Guix is able to update itself via `guix pull' but
it doesn't affect system installation of guix-daemon.

It would help splitting releases of Guix and guix-daemon.

Best regards,

S_W


signature.asc
Description: Digital signature

bug#24138: SIGSEGV of useradd (from shadow package)

[Tomáš Čech]

On Tue, 31 Jan 2017 23:25:32 +0100,
Ludovic Courtès wrote:
> 
> Hi Tomáš,
> 
> Any updates on this bug, or should we close it?

I haven't met this bug since. Let's close it.

Thanks.

S_W

bug#25248: Merry Christmas and Happy New Year! GRUB1 and GRUB2

[Tomáš Čech]

On Fri, 30 Dec 2016 18:20:11 +0100,
Gennadii Kondratiev wrote:
> 
> [1  ]
> [2  ]
> #Hello!
> #
> #Thanks for your kind words and encouragement!
> #
> #As far as GRUB is concerned, please email 25...@debbugs.gnu.org detailed
> #information about what you expected and what you get (wrong behavior,
> #error messages, etc.), and how one can reproduce it. This information
> #is crucial in allowing us to debug and fix the problems you experience.
> #
> #Thanks for your support!
> #
> #Ludo’.
> 
> I wrote to Ludovic Cortes that you should include Legacy Grub into GNU 
> packages, because it can be installed in any place (e.g., on the root 
> partition), but
> Grub 2 has this feature blocked by default (at least, all people in the 
> Internet say so). Or it would be better to unblock this feature in Grub2. 
> Even with the
> powerful Grub people can make less harm to their conputers than, for example, 
> with fdisk, which you like and include everywhere. 
>
> I installed GuixSD with big difficulties, and at the end I could not boot it. 
> Of course, I booted via Aptosid Grub, but it is not very nice to use a 
> bootloader from
> another OS.
> 
> You do very amazing and advanced things and do not worry about some simple 
> things. A good bootloader is important.
> 
> Just, please, recover the ability of Grub 2 to write on the disk. At now 
> moment it says that it needs to calculate block sizes, something like that. 
> When people
> write --force option, it says that everything is ok, but in reality it does 
> not write on the disk.

1] If you want to put Grub2 into partition, you can use filesystem, which 
reserves enough space at the beginning like BtrFs.
2] You can also use calculated block size which is less safe but still works in 
most of cases

In those cases you can use either `multiboot' to chainload GuixSD's bootloader 
or just load GuixSD's configuration with `source'.

3] You can use GuixSD's configured Grub2 as your default bootloader in MBR of 
the disk which is the easiest way to deal with that.

Relying on unmaintained Grub is probably not the right way for anything.

HTH and happy New Year to you too!

S_W

bug#25043: mount is unable to locate mount helpers

[Tomáš Čech]

mount command from util-linux is expecting helpers in /sbin/
directory, which is not available on GuixSD.

If found it when I tried to mount manully NFS:

 # mount -t nfs server:/some/path /mnt

Manual page of `mount' - section EXTERNAL HELPERS and strace seems to agree:

...
stat("/sbin/mount.nfs", 0x7ffe421e9080) = -1 ENOENT (No such file or directory)
stat("/sbin/fs.d/mount.nfs", 0x7ffe421e9080) = -1 ENOENT (No such file or 
directory)
stat("/sbin/fs/mount.nfs", 0x7ffe421e9080) = -1 ENOENT (No such file or 
directory)
getuid()= 0
geteuid()   = 0
getgid()= 0
getegid()   = 0
prctl(PR_GET_DUMPABLE)  = 1
getuid()= 0
geteuid()   = 0
getgid()= 0
getegid()   = 0
prctl(PR_GET_DUMPABLE)  = 1
stat("/run", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/etc/mtab", {st_mode=S_IFLNK|0777, st_size=17, ...}) = 0
lstat("/run/mount/utab", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
open("/run/mount/utab", O_RDWR|O_CREAT|O_CLOEXEC, 0644) = 3
close(3)= 0
mount("disk:/", "/mnt", "nfs", MS_MGC_VAL, NULL) = -1 EINVAL (Invalid argument)
write(2, "mount: ", 7mount: )  = 7
write(2, "wrong fs type, bad option, bad s"..., 110wrong fs type, bad option, 
bad superblock on disk:/,
   missing codepage or helper program, or other error) = 110
write(2, "\n", 1
)   = 1
write(2, "   (for several filesystems "..., 108   (for several 
filesystems (e.g. nfs, cifs) you might
   need a /sbin/mount. helper program)
) = 108
write(2, "\n   In some cases useful inf"..., 86
   In some cases useful info is found in syslog - try
   dmesg | tail or so.
) = 86
close(1)= 0
close(2)= 0
exit_group(32)  = ?
+++ exited with 32 +++


The best approach to me seems to patch mount so it search PATH or
introduce some other environment variable to search helpers in.

bug#20067: fix interpretation of grub configuration

[Tomáš Čech]

On Sat, Sep 10, 2016 at 12:03:38AM +0200, Ludovic Courtès wrote:

Good news!


Good news indeed!



l...@gnu.org (Ludovic Courtès) skribis:


Tomáš Čech  skribis:


Grub configuration interpretes `linux' as directory where is located
bzImage. If I enter file name instead, result configuration will be
wrong.


The solution will be to not automatically append “/bzImage” (and
likewise for the initrd.)

We could change places where ‘menu-entry’ is instantiated to:

  #~(string-append #$kernel "/bzImage")

However, there’s the problem that the image name appears in the
‘parameters’ file of the system (as seen in the output of ‘guix system
build foo.scm’), where it is unevaluated.  If we use ‘string-append’ as
above, a raw (string-append …) sexp will appear in there, which is not
nice.

To address this, an idea is to add “expanders” for gexps: gexps already
have “compilers”, and expanders would be similar except that they would
produce something possibly different from just the derivation’s output
file name.  For instance, we could write:

  (file-append kernel "/bzImage")

and that would expand directly to:

  "/gnu/store/…/bzImage"


AFAICS this is finally fixed!

 expanders in commit ebdfd776f4504c456d383ee8afa59fc6fdfc6756
 ‘file-append’ in commit a9e5e92f940381e3a4ee828c6d8ff22a73067e17
 kernel file name in commit 44d5f54e31039d78f156bd9562dca293124eaa76

Please let me know how it goes!  In particular, does it work for the
dual-boot scenario you were interested in?


It is almost perfect.

Configuration excerpt...

(bootloader (grub-configuration
 (device "/dev/sda")
 (menu-entries
  (list
   (menu-entry
(label "openSUSE")
(linux "(hd0,msdos1)/vmlinuz")
(linux-arguments (list
  "root=/dev/venom/opensuse"
  "init=/usr/lib/systemd/systemd"))
(initrd "(hd0,msdos1)/initrd"))


...transforms into

menuentry "openSUSE" {
  search --file --set (hd0,msdos1)/vmlinuz
  linux (hd0,msdos1)/vmlinuz root=/dev/venom/opensuse 
init=/usr/lib/systemd/systemd
  initrd (hd0,msdos1)/initrd
}

I think that if linux contains prefix '(.*)/', there should be no
search for kernel.

Thank you very much for fixing this bug (especially when I wasn't
able). I believe that fixing this bug is big step in more friendly
behavior to other OS.

Best regards,

S_W


signature.asc
Description: Digital signature

bug#24145: [PATCH] gnu: asciidoc: Use local docbook-xsl package.

[Tomáš Čech]

On Sun, Aug 21, 2016 at 05:44:12PM -0400, Leo Famulari wrote:

On Fri, Aug 19, 2016 at 09:08:43PM +0200, Tomáš Čech wrote:

* gnu/packages/documentation.scm (asciidoc)[inputs]: Add docbook-xsl.
[arguments]: Add 'make-local-docbook-xsl' phase.


Thanks! I added a comment above the phase and pushed as dd10ba6356.


Thanks!


And then I remembered that you could have pushed it yourself. Oops!


That doesn't matter :)

I think we can close bug#24145 now.

S_W


signature.asc
Description: Digital signature

bug#24138: SIGSEGV of useradd (from shadow package)

[Tomáš Čech]

On Wed, Aug 03, 2016 at 06:56:19PM +0200, Ludovic Courtès wrote:

Hello!

Tomáš Čech  skribis:


It seems to be easy to crash useradd (from shadow package).


Is it on GuixSD?


Yes. \o/


from strace:

read(3, "account required pam_deny.so \nau"..., 4096) = 223
open("/gnu/store/2xmwkq2ycwk89xlxnvib5wnjaacfy0rg-linux-pam-1.2.1/lib/security/pam_deny.so",
 O_RDONLY|O_CLOEXEC) = 5
read(5, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\6\0\0\0\0\0\0"..., 
832) = 832
fstat(5, {st_mode=S_IFREG|0555, st_size=6728, ...}) = 0
mmap(NULL, 2100200, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 5, 0) = 
0x7fb8b447c000
mprotect(0x7fb8b447d000, 2093056, PROT_NONE) = 0
mmap(0x7fb8b467c000, 4096, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 5, 0) = 0x7fb8b467c000
close(5)= 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x7fb8b3d1bda8} ---


Could you check in the ‘strace’ output whether PAM modules build with
another libc are being loaded?


It doesn't seem to be that case:

# grep linux-pam ~/useradd.strace  | grep -v ENOENT
19555 
open("/gnu/store/2xmwkq2ycwk89xlxnvib5wnjaacfy0rg-linux-pam-1.2.1/lib/libpam_misc.so.0",
 O_RDONLY|O_CLOEXEC) = 3
19555 
open("/gnu/store/2xmwkq2ycwk89xlxnvib5wnjaacfy0rg-linux-pam-1.2.1/lib/libpam.so.0",
 O_RDONLY|O_CLOEXEC) = 3
19555 
open("/gnu/store/2xmwkq2ycwk89xlxnvib5wnjaacfy0rg-linux-pam-1.2.1/lib/security/pam_unix.so",
 O_RDONLY|O_CLOEXEC) = 4
19555 
open("/gnu/store/2xmwkq2ycwk89xlxnvib5wnjaacfy0rg-linux-pam-1.2.1/lib/security/pam_rootok.so",
 O_RDONLY|O_CLOEXEC) = 4
19555 stat("/gnu/store/m4xna3zq2il5an61wxbmfv82ndvz70f6-linux-pam-1.2.1/lib", 
{st_mode=S_IFDIR|0555, st_size=4096, ...}) = 0
19555 
open("/gnu/store/2xmwkq2ycwk89xlxnvib5wnjaacfy0rg-linux-pam-1.2.1/lib/security/pam_deny.so",
 O_RDONLY|O_CLOEXEC) = 5

On the other hand it seems to load part of the libraries from 2.22,
part from 2.23 and that is not healthy.

# grep glibc ~/useradd.strace  | grep -v ENOENT
19555 
open("/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/lib/libdl.so.2", 
O_RDONLY|O_CLOEXEC) = 3
19555 
open("/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/lib/libc.so.6", 
O_RDONLY|O_CLOEXEC) = 3
19555 
open("/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/share/locale/locale.alias",
 O_RDONLY|O_CLOEXEC) = 3
19555 
open("/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/lib/libnss_compat.so.2",
 O_RDONLY|O_CLOEXEC) = 3
19555 
open("/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/lib/libnsl.so.1", 
O_RDONLY|O_CLOEXEC) = 3
19555 
open("/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/lib/libnss_nis.so.2",
 O_RDONLY|O_CLOEXEC) = 3
19555 
open("/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/lib/libnss_files.so.2",
 O_RDONLY|O_CLOEXEC) = 3
19555 
open("/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/lib/libcrypt.so.1",
 O_RDONLY|O_CLOEXEC) = 4
19555 stat("/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib", 
{st_mode=S_IFDIR|0555, st_size=4096, ...}) = 0
19555 
open("/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/libm.so.6", 
O_RDONLY|O_CLOEXEC) = 4
19555 
open("/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/librt.so.1", 
O_RDONLY|O_CLOEXEC) = 4
19555 
open("/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/libpthread.so.0",
 O_RDONLY|O_CLOEXEC) = 4

It seems to be more serious than I thought:

# login
Neoprávněný přístup do paměti (SIGSEGV) (core dumped [obraz paměti uložen])

S_W


signature.asc
Description: Digital signature

bug#24145: [PATCH] gnu: asciidoc: Use local docbook-xsl package.

[Tomáš Čech]

* gnu/packages/documentation.scm(asciidoc): New input docbook-xsl,
  replace use of online source and prefer docbook-xsl package.
---
 gnu/packages/documentation.scm | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/documentation.scm b/gnu/packages/documentation.scm
index 72af708..98d30e7 100644
--- a/gnu/packages/documentation.scm
+++ b/gnu/packages/documentation.scm
@@ -49,8 +49,22 @@
(base32
 "1w71nk527lq504njmaf0vzr93pgahkgzzxzglrq6bay8cw2rvnvq"
 (build-system gnu-build-system)
-(arguments '(#:tests? #f)); no 'check' target
-(inputs `(("python" ,python-2)))
+(arguments
+ `(#:tests? #f ; no 'check' target
+   #:phases
+   (modify-phases %standard-phases
+ (add-before
+ 'install 'make-local-docbook-xsl
+   (lambda* (#:key inputs #:allow-other-keys)
+ (substitute* (find-files "docbook-xsl" ".*\\.xsl$")
+   (("xsl:import 
href=\"http://docbook.sourceforge.net/release/xsl/current";)
+(string-append
+ "xsl:import href=\""
+ (string-append (assoc-ref inputs "docbook-xsl")
+"/xml/xsl/docbook-xsl-"
+,(package-version docbook-xsl))
+(inputs `(("python" ,python-2)
+  ("docbook-xsl" ,docbook-xsl)))
 (home-page "http://www.methods.co.nz/asciidoc/";)
 (synopsis "Text-based document generation system")
 (description
-- 
2.9.2

bug#24145: asciidoc depends on Internet connection instead of docbook-xsl package

[Tomáš Čech]

I'm trying to create package for sway and I noticed strange behavior
difference between build by daemon and by me within prepared
environment.

I found the reason for that - a2x (asciidoc) is trying to access
manpage/docbook.xsl.

asciidoc package needs to be adjusted to use docbook-xsl package files
instead so it could be used for build.



$ ag 'import.*docbook\.xsl' /gnu/store/*-asciidoc-*
/gnu/store/…-asciidoc-8.6.9/etc/asciidoc/docbook-xsl/xhtml.xsl
12:http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl"/>

/gnu/store/…-asciidoc-8.6.9/etc/asciidoc/docbook-xsl/fo.xsl
16:http://docbook.sourceforge.net/release/xsl/current/fo/docbook.xsl"/>

/gnu/store/…-asciidoc-8.6.9/etc/asciidoc/docbook-xsl/manpage.xsl
12:http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl"/>

/gnu/store/…-asciidoc-8.6.9/etc/asciidoc/docbook-xsl/epub.xsl
12:  http://docbook.sourceforge.net/release/xsl/current/epub/docbook.xsl"/>


IMO, for these files it should be sufficient to replace:

http://docbook.sourceforge.net/release/xsl/current/

with

/gnu/store/…-docbook-xsl-*/xml/xsl/docbook-xsl-*/


S_W


signature.asc
Description: PGP signature

bug#24138: SIGSEGV of useradd (from shadow package)

[Tomáš Čech]

It seems to be easy to crash useradd (from shadow package).

# ls -l $(which useradd)
lrwxrwxrwx 4 root guixbuild 69 Jan  1  1970 /root/.guix-profile/sbin/useradd -> 
/gnu/store/ylnc73apl1irl0s613rxjl445x2zx8a5-shadow-4.2.1/sbin/useradd


# useradd test
Neoprávněný přístup do paměti (SIGSEGV) (core dumped [obraz paměti uložen])

(139) # gdb $(which useradd) core
GNU gdb (GDB) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /root/.guix-profile/sbin/useradd...(no debugging symbols 
found)...done.
[New LWP 1603]

warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
Core was generated by `useradd test'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7f457ee6503c in call_init.part () from 
/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/lib/ld-linux-x86-64.so.2
(gdb) bt
#0  0x7f457ee6503c in call_init.part () from 
/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/lib/ld-linux-x86-64.so.2
#1  0x7f457ee65205 in _dl_init () from 
/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/lib/ld-linux-x86-64.so.2
#2  0x7f457ee696a0 in dl_open_worker () from 
/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/lib/ld-linux-x86-64.so.2
#3  0x7f457ee64f34 in _dl_catch_error () from 
/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/lib/ld-linux-x86-64.so.2
#4  0x7f457ee68d33 in _dl_open () from 
/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/lib/ld-linux-x86-64.so.2
#5  0x7f457e841fb9 in dlopen_doit () from 
/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/lib/libdl.so.2
#6  0x7f457ee64f34 in _dl_catch_error () from 
/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/lib/ld-linux-x86-64.so.2
#7  0x7f457e842589 in _dlerror_run () from 
/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/lib/libdl.so.2
#8  0x7f457e842051 in dlopen@@GLIBC_2.2.5 () from 
/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/lib/libdl.so.2
#9  0x7f457ea49e8d in _pam_load_module () from 
/gnu/store/2xmwkq2ycwk89xlxnvib5wnjaacfy0rg-linux-pam-1.2.1/lib/libpam.so.0
#10 0x7f457ea4a4f9 in _pam_add_handler () from 
/gnu/store/2xmwkq2ycwk89xlxnvib5wnjaacfy0rg-linux-pam-1.2.1/lib/libpam.so.0
#11 0x7f457ea4ad90 in _pam_parse_conf_file () from 
/gnu/store/2xmwkq2ycwk89xlxnvib5wnjaacfy0rg-linux-pam-1.2.1/lib/libpam.so.0
#12 0x7f457ea4b395 in _pam_init_handlers () from 
/gnu/store/2xmwkq2ycwk89xlxnvib5wnjaacfy0rg-linux-pam-1.2.1/lib/libpam.so.0
#13 0x7f457ea4cae1 in pam_start () from 
/gnu/store/2xmwkq2ycwk89xlxnvib5wnjaacfy0rg-linux-pam-1.2.1/lib/libpam.so.0
#14 0x00403351 in main ()


Interesting information about module causing it would be in stackframe
#9 but there are no debugging information available. Adding debug
`output' to linux-pam would diverge me from GuixSD.

from strace:

read(3, "account required pam_deny.so \nau"..., 4096) = 223
open("/gnu/store/2xmwkq2ycwk89xlxnvib5wnjaacfy0rg-linux-pam-1.2.1/lib/security/pam_deny.so",
 O_RDONLY|O_CLOEXEC) = 5
read(5, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\6\0\0\0\0\0\0"..., 
832) = 832
fstat(5, {st_mode=S_IFREG|0555, st_size=6728, ...}) = 0
mmap(NULL, 2100200, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 5, 0) = 
0x7fb8b447c000
mprotect(0x7fb8b447d000, 2093056, PROT_NONE) = 0
mmap(0x7fb8b467c000, 4096, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 5, 0) = 0x7fb8b467c000
close(5)= 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x7fb8b3d1bda8} ---
+++ killed by SIGSEGV (core dumped) +++

# cat /etc/pam.d/useradd
account required pam_unix.so
auth sufficient pam_rootok.so
password required pam_unix.so
session required 
/gnu/store/4mmn5y6syzv7wwz1y6bl1ab4g0yvkdq1-elogind-219.14/lib/security/pam_elogind.so
session required pam_unix.so

# cat /etc/pam.d/other
account required pam_deny.so
auth required pam_deny.so
password required pam_deny.so
session required 
/gnu/store/4mmn5y6syzv7wwz1y6bl1ab4g0yvkdq1-elogind-219.14/lib/security/pam_elogind.so
session required pam_deny.so


signature.asc
Description: Digital signature

bug#24092: installation of password-store doesn't require installation of tree

[Tomáš Čech]

I installed `password-store' and simple invocation failed:

 $ LC_ALL=C pass
 Password Store
 /home/tcech/.guix-profile/bin/pass: line 324: tree: command not found

After manually installing `tree' package it works as expected.

A `pass' is bash script, shouldn't be inputs be changed to propagated-inputs?
   (inputs `(("gnupg" ,gnupg)
 ("pwgen" ,pwgen)
 ("xclip" ,xclip)
 ("git" ,git)
 ("tree" ,tree)
 ("which" ,which)))

Best regards,

S_W


signature.asc
Description: PGP signature

bug#20081: issue is still not fixed

[Tomáš Čech]

Hi,

during my clean-up of taskwarrior package I removed section which
removes broken symlinks. Even though this bug is considered as fixed, I
believe I reproduced it after 347f54e.

...
task-2.4.3/src/ViewText.cpp
task-2.4.3/src/ViewText.h
task-2.4.3/src/wcwidth6.cpp
phase `unpack' succeeded after 0 seconds
starting phase `patch-usr-bin-file'
phase `patch-usr-bin-file' succeeded after 0 seconds
starting phase `patch-source-shebangs'
Backtrace:
In ice-9/boot-9.scm:
157: 15 [catch #t # ...]
In unknown file:
  ?: 14 [apply-smob/1 #]
In ice-9/boot-9.scm:
 63: 13 [call-with-prompt prompt0 ...]
In ice-9/eval.scm:
432: 12 [eval # #]
In ice-9/boot-9.scm:
2401: 11 [save-module-excursion #]
4050: 10 [#]
1724: 9 [%start-stack load-stack ...]
1729: 8 [#]
In unknown file:
  ?: 7 [primitive-load 
"/gnu/store/06l4f3al56cg49rfiy79risam0f8yb4y-taskwarrior-2.4.3-guile-builder"]
In ice-9/eval.scm:
387: 6 [eval # ()]
In srfi/srfi-1.scm:
830: 5 [every1 # ...]
In 
/gnu/store/j8w9vf3diyvkccsa21p9fqpwsl3wlsy3-module-import/guix/build/gnu-build-system.scm:
584: 4 [# #]
167: 3 [patch-source-shebangs # ...]
In unknown file:
  ?: 2 [remove # #]
In ice-9/boot-9.scm:
1461: 1 [# "./src/cal"]
In unknown file:
  ?: 0 [stat "./src/cal" #]

ERROR: In procedure stat:
ERROR: In procedure stat: No such file or directory: "./src/cal"


pgp64uvl1BNNK.pgp
Description: PGP signature

bug#20037: problem still persist

[Tomáš Čech]

On Sun, Apr 05, 2015 at 11:05:34PM +0200, Ludovic Courtès wrote:

Tomáš Čech  skribis:


I'm afraid I can reproduce it.


It’s a different problem this time.  :-)


--%<my-config.scmbegin>%---


[...]


 (packages
  (append
   (list
;; absolutely necessary
emacs lvm2 mc bash texinfo


(Unrelated, but I personally find it more convenient to have only core
packages in the global profile, and then have the rest in user
profiles.)


(
I do agree with you, but
   emacs - default editor and interface for Guix
   lvm2 - I need it to mount filesystems
   mc - OK, this can be ommited
   bash - regardless being BASH fan and user - this de-facto standard, my
  scripts relies on bashism for speed and cleaner code (really! :)
   texinfo - I really need to access DMD and Guix manuals to be able to use
 them (already happened to me when I got lost without Internet
 connection)
)



[...]


 (services
  (append
   (list
(lsh-service #:port-number 22 #:root-login? #t #:initialize? #t)
(slim-service)
(wicd-service)
(avahi-service)
(dbus-service (list avahi wicd))
(mingetty-service "ttyS0"))


[...]


   ?: 0 [symlink "/gnu/store/z95z25d73kjza99s3w95lrdsiqlcdv0a-login" ...]

ERROR: In procedure symlink:
ERROR: In procedure symlink: File exists


The culprit is the ‘mingetty-service’ call above: since it uses a #:motd
different from that used in the other ‘mingetty-service’ calls in
%base-services, the thing tries to create a different pam.d/login file
for it, but that fails because there’s already a pam.d/login file.

The workaround is to write:

   (mingetty-service "ttyS0"
 #:motd (text-file "motd" "
This is the GNU operating system, welcome!\n\n"))


FTR (in case someone will face the same problem), text-file is in (guix store)
module so you will need to add that one as well.


Since this is the same motd as the other mingetty services, everything
is fine.

This is of course unsatisfactory.  The more general issue is that
service procedures need to be able to share state/configuration info,
which I hope we can fix soon.


Thanks for your analysis. I can confirm that your workaround worked and I can
use Guix once again. Sorry for not recognizing this as another issue.

Thanks,

S_W

bug#20037: problem still persist

[Tomáš Čech]

I'm afraid I can reproduce it.

I'm at revision bfe3c6857251c1fff24317da602b9cd762c1c112, running guix from
GIT through pre-inst-env.

I was able to remove all my local modifications so no GUIX_PACKAGE_PATH is in
place.

--%%---
(use-modules (gnu))
(use-package-modules
 ;; generic guix packages modules
 admin autotools avahi base bash commencement cryptsetup curl
 emacs enlightenment gdb glib gnutls gnuzilla grub links linux lsh mail
 mc patchutils slim synergy texinfo version-control video wget wicd
 xfce xorg dwm avahi ssh xorg vpn openssl)
(use-service-modules
 avahi base dbus networking ssh xorg)

(operating-system
 (host-name "venom")
 (timezone "Europe/Prague")
 (locale "cs_CZ.utf8")
 (bootloader (grub-configuration
  (device "/dev/sda")
  (menu-entries
   (list
(menu-entry
 (label "Gentoo")
 (linux "/vmlinuz-gentoo")
 (linux-arguments (list
   "root=/dev/venom/gentoo"
   "init=/usr/lib/systemd/systemd"))
 (initrd "/initramfs-gentoo")
 )
 (file-systems (append (list (file-system
  (device "/dev/sda3") ; or partition label
  (mount-point "/")
  (type "ext4"))
;;   (file-system
;;(device "/dev/venom/home")
;;(mount-point "/home")
;;(type "ext4"))
 )
   %base-file-systems))
 (swap-devices '("/dev/sda2"))
 (users (list (user-account
   (name "tcech")
   (uid 1000) (group "users")
   (comment "Tomas Cech")
   (password "password")
   (home-directory "/home/tcech"
 (packages
  (append
   (list
;; absolutely necessary
emacs lvm2 mc bash texinfo
grub nss-mdns procps cryptsetup alsa-utils

;; networking

iw iproute wicd links wpa-supplicant dbus
vpnc openconnect openssl lsh

;; minimal Xorg

slim xrandr xterm slock

;; mail

mutt mu gnutls

;; web
icecat wget curl

;; enlightenment

terminology enlightenment

;; xfce
xfce

;; other X stuff
synergy
;; multimedia
mplayer mplayer2 vlc
;; mpv
;; development
git magit subversion cvs rcs quilt patchutils patch gcc-toolchain-4.9 
gnu-make
automake autoconf gdb
strace ltrace

;; other
htop
;; not packaged yet
;; isync cmus cscope ctags the-silver-searcher
)
   %base-packages))
 (services
  (append
   (list
(lsh-service #:port-number 22 #:root-login? #t #:initialize? #t)
(slim-service)
(wicd-service)
(avahi-service)
(dbus-service (list avahi wicd))
(mingetty-service "ttyS0"))
   %base-services))
 )
--%%---

As I lost ability to boot after repartitioning so I run it from chroot from
openSUSE. Guix daemon is started from chroot.

Failure is happening with:

$ guix system reconfigure my-config.scm
substitute-binary: updating list of substitutes from 'http://hydra.gnu.org'...
The following derivations will be built:
   /gnu/store/igkyyxgpyvizzpkygji34dkyiivrbqbj-system.drv
   /gnu/store/khgv41ycwz0vg6sadgzrbrpsl93mii5c-grub.cfg.drv
   /gnu/store/j1s6vh555l6bjmf343wf9f1iyzdzwnv8-activate.drv
   /gnu/store/mx0rmnfqi998lpdv8iaywj66wdjnhmsy-boot.drv
   /gnu/store/wnj7qwhn1i7akk6crkg6s0diksi3lhyr-pam.d.drv
   /gnu/store/7dm59cc020dfma43b24pilrp98zgsbs8-etc.drv
Backtrace:
In ice-9/boot-9.scm:
 157: 10 [catch #t # ...]
In unknown file:
   ?: 9 [apply-smob/1 #]
In ice-9/boot-9.scm:
  63: 8 [call-with-prompt prompt0 ...]
In ice-9/eval.scm:
 432: 7 [eval # #]
In ice-9/boot-9.scm:
2401: 6 [save-module-excursion #]
4050: 5 [#]
1724: 4 [%start-stack load-stack ...]
1729: 3 [#]
In unknown file:
   ?: 2 [primitive-load 
"/gnu/store/b027n4gx00y19bpyi1h5hasvnpp95ff4-pam.d-builder"]
In srfi/srfi-1.scm:
 616: 1 [for-each # (# # # # 
...)]
In unknown file:
   ?: 0 [symlink "/gnu/store/z95z25d73kjza99s3w95lrdsiqlcdv0a-login" ...]

ERROR: In procedure symlink:
ERROR: In procedure symlink: File exists
builder for `/gnu/store/wnj7qwhn1i7akk6crkg6s0diksi3lhyr-pam.d.drv' failed with 
exit code 1
cannot build derivation `/gnu/store/7dm59cc020dfma43b24pilrp98zgsbs8-etc.drv': 
1 dependencies couldn't be built
cannot build derivation 
`/gnu/store/igkyyxgpyvizzpkygji34dkyiivrbqbj-system.drv': 1 dependencies 
couldn't be built
killing process 7202
guix system: error: build failed: build of 
`/gnu/store/igkyyxgpyvizzpkygji34dkyiivrbqbj-system.drv' failed



It seems to be identical to the report. Furthermore - `make clean' in my GIT
repository is not helping so right now I'm not sure how to progress.

I'd appreciate if

bug#20137: number of generation doesn't always rise monotonically

[Tomáš Čech]

On Mon, Mar 23, 2015 at 10:13:13AM +0100, Ludovic Courtès wrote:

Tomáš Čech  skribis:


Perhaps we can eventually move to an actual tree structure where the
nodes can be named whatever.  Until now I thought that's how generations
work, and are just named after integers for identification purposes.


[...]


I’m concerned that this would add both code and user interface
complexity for mostly hypothetical use cases.  WDYT?


Yes, it would surely add some more code and would be demanding for
creating good visual represantation for users, but it could also be
much closer to behavior user would expect. And that is something which
makes tools to be natural to use.


I’m not sure.  My guess is that an undo-style tree would turn out to be
less obvious or more difficult to use.

Currently, understanding what’s going on with M-x guix-generations or
--list-generations and similar is fairly straightforward.


I'm not using emacs for controling guix at all. But I should start - I can see
that is completely different user experience!

Thanks!

S_W


pgpzWHJqVpxbw.pgp
Description: PGP signature

bug#20137: number of generation doesn't always rise monotonically

[Tomáš Čech]

Sorry, for some reason I didn't get any e-mail and noticed only
closing the bug. I'll subscribe to bug-guix ML to prevent it.



That’s expected, yes.  What makes you think it’s a problem?


First, it was conflicting experience with what you were saying on IRC.
User experience was a bit confusing because the behaviour seemed
unexpected.


When implementing that, there were several possible choices:

 1. Upon rollback to N, remove all generations above N.  Rejected
  because it gratuitously prevents useful use cases.

 2. Upon rollback from P to N, keep all the generations, but use P+1
for the next generation number.  Doesn’t work, because rolling back
from P+1 would bring you back to P instead of N.


I can't understand this reason. It doesn't look like valid reason to
me, but only consequence of current implementation. It seems that you
don't store information about what was the previous generation and
that is whole point.


 3. The current behavior.

See 
for part of the discussion.


Thanks for looking that up!




Perhaps we can eventually move to an actual tree structure where the
nodes can be named whatever.  Until now I thought that's how generations
work, and are just named after integers for identification purposes.


Yes, I had this in mind as well.



I agree this would be the right thing for a real undo mechanism.


Exactly!


But how useful would it be?  I’ve never been in a situation where
rollback/switch-generation would be insufficient or inappropriate.


I haven't met such situation either (yet).


I’m concerned that this would add both code and user interface
complexity for mostly hypothetical use cases.  WDYT?


Yes, it would surely add some more code and would be demanding for
creating good visual represantation for users, but it could also be
much closer to behavior user would expect. And that is something which
makes tools to be natural to use.

Thank you all for your comments.

S_W


pgpV0LBGg_cbR.pgp
Description: PGP signature

bug#20137: number of generation doesn't always rise monotonically

[Tomáš Čech]

Generation number is not always the maximum of all generation numbers
and so generation number is not always monotonic.

Steps to reproduce:

Lets start with on generation N.

1] install some package (you'll have N and N+1)
2] install some other package (you'll have N, N+1 and N+2)
3] delete generation N+1 (you'll have N and N+2)
4] switch to generation N
5] install some package - you'll get generation N+1 again
  (you'll have N, N+1 and N+2 again)


pgp2dw6muDvfZ.pgp
Description: PGP signature

bug#20121: curl program is broken

[Tomáš Čech]

I have almost forgot about this bug so lets track it.

Calling curl from shell causes error message:

$ curl http://www.google.com
curl: (4) A requested feature, protocol or option was not found built-in in 
this libcurl due to a build-time decision.

You'll get this answer on any protocol I could come with.

bug#20081: patch-source-shebangs crashes on broken symlink

[Tomáš Čech]

On Thu, Mar 12, 2015 at 10:30:55AM +0100, Ludovic Courtès wrote:

Tomáš Čech  skribis:


On Wed, Mar 11, 2015 at 06:32:30PM +0100, Andreas Enge wrote:

On Wed, Mar 11, 2015 at 04:02:11PM +0100, Tomáš Čech wrote:

I'm trying to create package for taskwarrior.
Source tarball contain symlinks to nonexisting file `task':


I would argue that this is not a bug in guix, but in the tarball.
You can remove the link with an additional phase before 'configure, see, for
instance, the dvdisaster package in cdrom.scm.


I agree with you that the fishy part is in tarball, but we could make
build more robust. Getting backtrace is not nice way to end a build.


I agree.  I think we should patch ‘find-files’ in core-updates to not
follow symlinks:




diff --git a/guix/build/utils.scm b/guix/build/utils.scm
index a5a6167..9cbddcd 100644
--- a/guix/build/utils.scm
+++ b/guix/build/utils.scm
@@ -288,7 +288,8 @@ matches REGEXP."
 file (strerror errno))
 result)
   '()
-  dir)
+  dir
+  lstat)
 string



Thoughts?


Ignoring symlinks is nice solution.
I'd add comment:

We won't touch broken symlinks, symlinks pointing within the sources will be
fixed anyway.

Thanks!

S_W


pgpIndV5ENFOa.pgp
Description: PGP signature

bug#20081: patch-source-shebangs crashes on broken symlink

[Tomáš Čech]

On Wed, Mar 11, 2015 at 06:32:30PM +0100, Andreas Enge wrote:

On Wed, Mar 11, 2015 at 04:02:11PM +0100, Tomáš Čech wrote:

I'm trying to create package for taskwarrior.
Source tarball contain symlinks to nonexisting file `task':


I would argue that this is not a bug in guix, but in the tarball.
You can remove the link with an additional phase before 'configure, see, for
instance, the dvdisaster package in cdrom.scm.


I agree with you that the fishy part is in tarball, but we could make
build more robust. Getting backtrace is not nice way to end a build.

And we alone are getting into this problem it is not usual to
preprocess source files before compilation.

I already worked around the bug to confirm I correctly identified the cause.

S_W

bug#20081: patch-source-shebangs crashes on broken symlink

[Tomáš Čech]

I'm trying to create package for taskwarrior.

Source tarball contain symlinks to nonexisting file `task':

$ tar tvf /gnu/store/*-task*.tar.gz | grep -E '/src/(tw|cal |calendar|task)'
lrwxr-xr-x ultrafredde/staff  0 2015-02-16 23:45 task-2.4.1/src/cal -> task
lrwxr-xr-x ultrafredde/staff  0 2015-02-16 23:45 task-2.4.1/src/calendar -> 
task
lrwxr-xr-x ultrafredde/staff  0 2015-02-16 23:45 task-2.4.1/src/tw -> task

When I run build, I got this backtrace:

phase `unpack' succeeded after 0 seconds
starting phase `patch-usr-bin-file'
phase `patch-usr-bin-file' succeeded after 0 seconds
starting phase `patch-source-shebangs'
Backtrace:
In ice-9/boot-9.scm:
 157: 15 [catch #t # ...]
In unknown file:
   ?: 14 [apply-smob/1 #]
In ice-9/boot-9.scm:
  63: 13 [call-with-prompt prompt0 ...]
In ice-9/eval.scm:
 432: 12 [eval # #]
In ice-9/boot-9.scm:
2401: 11 [save-module-excursion #]
4050: 10 [#]
1724: 9 [%start-stack load-stack #]
1729: 8 [#]
In unknown file:
   ?: 7 [primitive-load 
"/gnu/store/ix1s7q448frw02wy9xvzhd66vh08lxcw-taskwarrior-2.4.1-guile-builder"]
In ice-9/eval.scm:
 387: 6 [eval # ()]
In srfi/srfi-1.scm:
 830: 5 [every1 # ...]
In 
/gnu/store/dyv4k9p9na96q4yzahdlvij3nadaz65h-module-import/guix/build/gnu-build-system.scm:
 511: 4 [# #]
 164: 3 [patch-source-shebangs # ...]
In unknown file:
   ?: 2 [remove # #]
In ice-9/boot-9.scm:
1461: 1 [# "./src/cal"]
 In unknown file:
   ?: 0 [stat "./src/cal" #]

ERROR: In procedure stat:
ERROR: In procedure stat: No such file or directory: "./src/cal"
builder for `/gnu/store/vr408ijifflkqjk9lgpj3sv469fj2pik-taskwarrior-2.4.1.drv' 
failed with exit code 1
cannot build derivation 
`/gnu/store/367g51d6vh8v5m1q58hls6bn40ha1262-profile.drv': 1 dependencies 
couldn't be built
guix package: error: build failed: build of 
`/gnu/store/367g51d6vh8v5m1q58hls6bn40ha1262-profile.drv' failed


pgpRpAC1JGUut.pgp
Description: PGP signature

bug#20071: none

[Tomáš Čech]

On Fri, Dec 05, 2014 at 09:35:42AM +0100, Tomas Cech wrote:

At Fri, 05 Dec 2014 00:04:23 +0100,
Ludovic Courtès wrote:


Tomas Cech  skribis:

> I tried to install Guix as alternative OS to my Gentoo and openSUSE
> installations to give a try. I tried unsupported scenario -
> installation on LVM volume and separate /boot partition until I was
> told it is unsupported. Separate boot wasn't hard as I had to just
> copy generated files so they are loaded.

OK, but there’s still an open bug on that topic.  :-)
http://bugs.gnu.org/19220


Good, I'll give a try again.


> 1] if you set device to partition (and not to disk) in your 
grub-configuration like this:
>
>  (bootloader (grub-configuration
>(device "/dev/sda4")))

Why would you want to use a partition and not a disk?  I didn’t know
this was even possible.


Because this way I can separate Grub managed by Guix and Grub from my
Gentoo. As I'm playing with that on my notebook I need for work, this
way can reduce risks.

I'm not sure how Guix installer can manipulate with grub.cfg and I'd
like to always have some working system...



> `guix system init' will fail on grub installation. By default Grub
> tries to fit in the beginning of partition and fails if it can't fit
> in. I asked about this behaviour on Grub mailing list and it seems
> that there are two options:
>
>   a] add `--force' to command line and use block list for keeping information 
about position of Grub's core.img
>   b] use filesystem which allows embedding - BtrFS or ZFS
>
> I verified both options (a] and then b] with BtrFS) and it no longer fails.
>
> But,
> ad a] - I don't feel safe passing `--force' to grub-install every
> time. So if installation fails on this point and you'd like to use
> your FS anyway, you can pass `--no-grub' to `guix system init' and
> then rung grub-install manually.
>
> ad b] - I don't feel safe using still experimental BtrFS.

OK.  I think the conclusion for Guix is to leave the defaults unchanged.
Perhaps we could add a ‘force?’ field to the ‘grub-configuration’ data
type to allow those who know what they doing to get the effect of
‘--force’.  WDYT?


After giving some more thoughts and after more experience with the process I
do agree that exposing `--force' parameter into grub-configuration is good idea.

I'm filing bug for that.


pgpC3l4OROYuc.pgp
Description: PGP signature

bug#20025: user in ratpoison doesn't have access to guix by default

[Tomáš Čech]

On Sun, Mar 08, 2015 at 11:09:13PM +0100, Ludovic Courtès wrote:

tc...@suse.cz skribis:


After booting into Guix I used slim to login into Ratpoison and I run
there terminal emulator. `guix' wasn't available in current PATH
settings so user couldn't maintain his profile.

I believe that /run/current-system/profile/bin/ should be added to PATH.


AFAICS it is.

Could it be that the account’s .bash_profile fails to source
/etc/profile, or something like that (info "(bash) Bash Startup Files")?
See /etc/skel/.bash{rc,_profile} as examples.


As my config file changed, I'm no longer able to reproduce it. If there is
such bug, it will reappear in future.

Please close the bug.


pgpuKOOenKANL.pgp
Description: PGP signature

bug#20024: grub store is not copied to target system

[Tomáš Čech]

On Tue, Mar 10, 2015 at 11:54:53AM +0100, Ludovic Courtès wrote:

Tomáš Čech  skribis:


On Tue, Mar 10, 2015 at 08:58:07AM +0100, Ludovic Courtès wrote:

Tomáš Čech  skribis:


[...]


Shouldn't `grub' be in `%base-packages'?


It could be there; OTOH, we don’t want to encourage users to bypass
‘reconfigure’.  WDYT?


Aha! Now it makes sense!

Yes, you're right, but there is also chance that after initialization of
GuixSD and reboot you will have no way back to original distribution.


As I wrote before, once you’ve booted into GuixSD, chances are that the
original distro on that partition is in a bad state because GuixSD has
fiddle with /etc and other global directories.


Irrelevant. As I wrote before - I have two separate partitions with root
filesystem. Problem is that when `guix system init' takes care of grub
configuration.


After my installation I got into state where Guix couldn't access network so
`guix system reconfigure' was not possible and my graphic card needs some
special care during boot to make KMS work (which I was hardly googling on
tablet to fix it).


Could you explain the KMS issue in a separate thread?


Irrelevant. It is not related to Guix and it may be even fixed already in
vanilla.


We could just add note in documentation that one can add grub as system
package as safety belt and remove it when confirmed it works. OTOH this may
encourage users to bypass reconfigure even more.


It’s enough to modify grub.cfg.  GRUB itself is not needed.

But anyway, the take-home message is that if you run ‘guix system init’
on your current root, then you can assume the former distro to no longer
be bootable.


No, I'm initializing GuixSD root filesystem, not the Gentoo one.

Lets just stop to avoid further confusion.

I take it that my usecase is corner case and I should add grub as system
package by myself. My goal was to consider providing grub and you have your
reasons. And it looks like I have too weird setup - separate /boot, LVM,
bootloader chainloading. I have found my way to workaround it.

Please close the bug.


pgpkGYJo3xnDa.pgp
Description: PGP signature

bug#20024: grub store is not copied to target system

[Tomáš Čech]

On Tue, Mar 10, 2015 at 08:58:07AM +0100, Ludovic Courtès wrote:

Tomáš Čech  skribis:


TL;DR
I run `guix system init' from Gentoo to separate partition to
_init_ root filesystem and after reboot to boot into GuixSD.


OK, that’s not what I had understood, so thanks for bearing with me!
;-)


But!  Beware that GuixSD wants to own /etc.  So in practice, when you
boot GuixSD, it may override most of the files in there with its own (it
might also bork of some of its assumptions do not hold, like if Gentoo
left files in /etc that it doesn’t expect to see.)  So the next time you
boot into Gentoo, Gentoo will basically be somewhat broken.

IOW, using ‘guix system init’ on the current root should be thought of
as a one-way transition.  It’s not documented because it’s brittle and
it’s most likely not what you want.


Yes, that would be way to hell. So the better solution can be putting
/gnu on separate partition and share it among the systems like you can
do for /home, /boot etc.


Possibly, yes.


Let me the whole bug rephrase into single simple question:

Shouldn't `grub' be in `%base-packages'?


It could be there; OTOH, we don’t want to encourage users to bypass
‘reconfigure’.  WDYT?


Aha! Now it makes sense!

Yes, you're right, but there is also chance that after initialization of
GuixSD and reboot you will have no way back to original distribution. I
understand that that is probably just corner case and typical Guix user
(yay! :) would just reboot to the image he used for installation...

After my installation I got into state where Guix couldn't access network so
`guix system reconfigure' was not possible and my graphic card needs some
special care during boot to make KMS work (which I was hardly googling on
tablet to fix it).

We could just add note in documentation that one can add grub as system
package as safety belt and remove it when confirmed it works. OTOH this may
encourage users to bypass reconfigure even more.


Is it really the only thing you were asking for?  If yes, I think we
could have been more efficient in our communication.  :-)


I'm afraid that yes. I wasn't able to say it in this simple way before as I
didn't know the reason. And yes, I'll do my best to explain it better next
time.


I just realized that I misread “grub store is not copied” in the title
as “/gnu/store is not copied.”  Sorry for the confusion.


I'm glad we finally made it clear :)

Best regards,

S_W


pgpajHLSi9za_.pgp
Description: PGP signature

bug#20067: fix interpretation of grub configuration

[Tomáš Čech]

Grub configuration interpretes `linux' as directory where is located
bzImage. If I enter file name instead, result configuration will be
wrong.


Example of system configuration:
(bootloader (grub-configuration
  (device "/dev/sda")
  (menu-entries
   (list
(menu-entry
 (label "Gentoo")
 (linux "/vmlinuz-gentoo") ; vmlinuz-gentoo is file
 (linux-arguments (list
   "root=/dev/venom/gentoo"
   "init=/usr/lib/systemd/systemd"))
 (initrd "/initramfs-gentoo")
 )



Result part of grub.cfg:
menuentry "Gentoo" {
 # Set 'root' to the partition that contains the kernel.
 search --file --set /vmlinuz-gentoo/bzImage


 linux /vmlinuz-gentoo/bzImage root=/dev/venom/gentoo 
init=/usr/lib/systemd/systemd
 initrd /initramfs-gentoo
}



It would be nice if the the string would be simply copied into
grub.cfg, so I could use even `(hd0,msdos1)/vmlinuz'.


pgpRRJ38ofkVI.pgp
Description: PGP signature

bug#20024: grub store is not copied to target system

[Tomáš Čech]

On Mon, Mar 09, 2015 at 06:00:24PM +0100, Ludovic Courtès wrote:

Tomas Cech  skribis:


I'm afraid that I don't understand the relation between `guix system init' and
`guix system reconfigure' you insist on. My understanding was, that `guix
system init' will create new system in subdirectory as it is described in
manual (6.1.4 Proceeding with the Installation).


‘guix system init’ initializes a GuixSD root file system.  It is
typically used from the USB installation image.

Conversely, ‘guix system reconfigure’ is used to reconfigure an already
installed GuixSD system, with the untold assumption that the root
partition remains the same (which is reasonable, IMO.)


Thank you for your verification. It means I understand it correctly.

I reread whole bug again and I couldn't find the reason you even
consider me using `guix system reconfigure'. My assumption is that you
didn't expect me to have Guix on my Gentoo.

Guix is (as you have to know the best) non-intrusive for OS so I have
standard Gentoo installation and Guix built from GIT and installed to
system. Binaries are in /gnu/store so it is not colliding with the
rest of my system. I'll keep that in mind to mention it better in
future bugs. Sorry for confusion.

TL;DR
I run `guix system init' from Gentoo to separate partition to
_init_ root filesystem and after reboot to boot into GuixSD.


Seriously, I don’t think we’d want it to automagically migrate the
store.


How does it differ from building new VM image?


‘init’ is similar to building a new VM image; ‘reconfigure’ is not.

Specifically, ‘reconfigure’ changes things to have immediate effect,
such as switching /run/current-system/ to the new (reconfigured) system.
Eventually it will also offer to restart dmd services whose definition
have changed.


I hope it is now obvious that I didn't `reconfigure', but `init'.


Maybe it could check whether the root partition in the OS declaration is
the same as the one that holds the current store, but I’m not sure if
that can be done reliably.  Thoughts?


Again, I'm afraid we misunderstood each other.

One thing is that you can expose it to configuration and let user configure it
correctly. I was already thinking that I'm wasting disk space with two copies
of /gnu/store on my computer (on Gentoo and on GuixSD).


Oh, I see.  So you had installed Guix atop Gentoo, and from there you
wanted to install GuixSD while (1) keeping Gentoo, and (2) not
rebuilding a new store, right?


Yes.


The solution to is to run, from your Gentoo system:

 # guix system init config.scm /

The “/” here means that you keep the same root file system, and thus the
same store.

If you want to still be able to boot into Gentoo, you need to specify
GRUB menu entries in config.scm, like

 (define gentoo-entry
   (menu-entry
(label "Gentoo")
(linux "/whatever/bzImage")
(linux-arguments '("answer=42"))
(initrd "/something/initrd.gz")))

 (operating-system
   ;; ...
   (bootloader (grub-configuration
(device "/dev/sda")
(menu-entries (list gentoo-entry)


I'm aware of this feature, I'm preparing bug report for that :)


But!  Beware that GuixSD wants to own /etc.  So in practice, when you
boot GuixSD, it may override most of the files in there with its own (it
might also bork of some of its assumptions do not hold, like if Gentoo
left files in /etc that it doesn’t expect to see.)  So the next time you
boot into Gentoo, Gentoo will basically be somewhat broken.

IOW, using ‘guix system init’ on the current root should be thought of
as a one-way transition.  It’s not documented because it’s brittle and
it’s most likely not what you want.


Yes, that would be way to hell. So the better solution can be putting
/gnu on separate partition and share it among the systems like you can
do for /home, /boot etc.



Does that better answer your questions?


Yes and no. I really appreciate your patience here but we diverged
from original reported issue.

Let me the whole bug rephrase into single simple question:

Shouldn't `grub' be in `%base-packages'?


Thanks and best regards,

S_W


pgp_BccXGMVVW.pgp
Description: PGP signature

bug#20024: grub store is not copied to target system

[Tomáš Čech]

On Sun, Mar 08, 2015 at 10:49:37PM +0100, Ludovic Courtès wrote:

tc...@suse.cz skribis:


With guix at revision df81e046c57e5f767738113e4e7a28b212c03d63 I tried
to deploy Guix to another partition.


Do you mean that you wanted to use a different root partition than the
one that was being used?


Yes. I am running from my Gentoo `guix system init -c 3 /guix' where /guix is
different partition planned to be booted as root filesystem for GuixSD.


Result system installed Grub into partition but did not copied it's
store to /gnu/store/ on target partition.


Indeed, ‘guix system reconfigure’ assumes that the root partition
remains the same and does not try to copy the store.


I'm runnning `guix system init' though.

S_W


pgp3cfdHdq1k1.pgp
Description: PGP signature