bug#29727: changing contributing.texi does not trigger rebuild of “info” target

[Chris Marusich]

Mathieu Lirzin  writes:

>  info_TEXINFOS = %D%/guix.texi
>  
> +%C%_guix_TEXINFOS = \
> +  %D%/contributing.texi \
> +  %D%/fdl-1.3.texi

Why is the %C% required here?  What does it do?  I read (automake)
Texinfo, so I understand that this is probably a way to tell Automake
that guix.texi depends on contributing.texi and fdl-1.3.texi, but I
don't understand why %C% is present in the variable name here.

-- 
Chris


signature.asc
Description: PGP signature

bug#25453: Inconsistent keyboard layout affecting encrypted root

[ng0]

Ludovic Courtès transcribed 1.1K bytes:
> Hi!
> 
> Christopher Baines  skribis:
> 
> > I'm using a UK keyboard layout with a computer that I recently installed
> > GuixSD on with a encrypted root parition. Immediately after installation
> > when I attempted to boot in to the new system for the first time I had
> > to enter the passphrase twice, and in doing this, first I had to use the
> > keyboard layout under which I carried out the installation (the layout
> > which I had intended to use), and then during the early boot stage of
> > the system I had to enter the passphrase using a different keyboard
> > layout.
> 
> Currently installing a keymap is something done by the ‘console-keymap’
> Shepherd service, which invokes ‘loadkeys’.  That happens after
> “cryptsetup --open” has opened your encrypted root device, hence the
> problem.
> 
> Should we install the keymap right in the initrd, before we’ve mounted
> the root partition?  That would require copying the right keymap(s) and
> probably ‘loadkeys’ to the initrd, which might make it quite big.
> 
> Suggestions?  How do others handle it?

Yes, this has been annoying me to the point of simply taking it for
granted for now, and replacing it in my own set of defaults.

To answer your question: Others handle it in the initrd aswell.

For example in Gentoo with OpenRC, you set the keyboardlayout for
the initrd. In Archlinux iirc before and after adoption of systemd
you set the keymap for it. In Debian if memory serves me right you
set the keyboard layout. I think I don't need to go on...

What's the size difference for the initrd then in numbers?
I don't think we have to wory about size as we'll never run
on devices smaller than router devices (at least that's my
current assumption looking at the size of a typical minimal
GuixSD, it's possible but requires lots of customization).

> Thanks for your report,
> Ludo’.
> 
> 
> 

-- 
ng0 :: https://ea.n0.is
A88C8ADD129828D7EAC02E52E22F9BBFEE348588 :: https://ea.n0.is/keys/


signature.asc
Description: PGP signature

bug#25453: Inconsistent keyboard layout affecting encrypted root

[Chris Marusich]

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

> Hi!
>
> Christopher Baines  skribis:
>
>> I'm using a UK keyboard layout with a computer that I recently installed
>> GuixSD on with a encrypted root parition. Immediately after installation
>> when I attempted to boot in to the new system for the first time I had
>> to enter the passphrase twice, and in doing this, first I had to use the
>> keyboard layout under which I carried out the installation (the layout
>> which I had intended to use), and then during the early boot stage of
>> the system I had to enter the passphrase using a different keyboard
>> layout.
>
> Currently installing a keymap is something done by the ‘console-keymap’
> Shepherd service, which invokes ‘loadkeys’.  That happens after
> “cryptsetup --open” has opened your encrypted root device, hence the
> problem.
>
> Should we install the keymap right in the initrd, before we’ve mounted
> the root partition?  That would require copying the right keymap(s) and
> probably ‘loadkeys’ to the initrd, which might make it quite big.
>
> Suggestions?  How do others handle it?
>
> Thanks for your report,
> Ludo’.

I may be wrong, but keep in mind that Grub and other bootloaders might
require their own configuration to set the keyboard layout, also.

-- 
Chris


signature.asc
Description: PGP signature

bug#30142: pipe of 'guix --version' produces error

[Leo Famulari]

On Tue, Jan 16, 2018 at 09:01:41PM -0500, George myglc2 Clemmer wrote:
> EXAMPLE:
> ***
> g1@g1 ~/www/VM-on-GuixSD$ guix --version | head -n 1
> guix (GNU Guix) 0.14.0.617-e2f37
> Backtrace:
>5 (primitive-load 
> "/gnu/store/nxdxbad50ydp1nhmgzvlwbk0jkkdc28r-guix-0.14.0-3.f76ff98/bin/.guix-real")
> In guix/ui.scm:
> 390:2  4 (show-version-and-exit _)
> In ice-9/format.scm:
>   1590:19  3 (format #t "Copyright ~a 2017 ~a" "(C)" "the Guix authors\n")
>261:19  2 (format:format-work "Copyright ~a 2017 ~a" ("(C)" "the Guix 
> authors\n"))
> 70:10  1 (format:out-obj-padded _ _ _ _)
> In unknown file:
>0 (display "the Guix authors\n" #)
> 
> ERROR: In procedure display:
> ERROR: In procedure fport_write: Broken pipe
> g1@g1 ~/www/VM-on-GuixSD$ guix --version | head -n 1
> guix (GNU Guix) 0.14.0.617-e2f37
> Backtrace:
>5 (primitive-load 
> "/gnu/store/nxdxbad50ydp1nhmgzvlwbk0jkkdc28r-guix-0.14.0-3.f76ff98/bin/.guix-real")
> In guix/ui.scm:
> 390:2  4 (show-version-and-exit _)
> In ice-9/format.scm:
>   1590:19  3 (format #t "Copyright ~a 2017 ~a" "(C)" "the Guix authors\n")
>261:19  2 (format:format-work "Copyright ~a 2017 ~a" ("(C)" "the Guix 
> authors\n"))
> 70:10  1 (format:out-obj-padded _ _ _ _)
> In unknown file:
>0 (display "the Guix authors\n" #)
> 
> ERROR: In procedure display:
> ERROR: In procedure fport_write: Broken pipe

Thanks for the report!

This is bug #29826 


signature.asc
Description: PGP signature

bug#30142: pipe of 'guix --version' produces error

[George myglc2 Clemmer]

EXAMPLE:
***
g1@g1 ~/www/VM-on-GuixSD$ guix --version | head -n 1
guix (GNU Guix) 0.14.0.617-e2f37
Backtrace:
   5 (primitive-load 
"/gnu/store/nxdxbad50ydp1nhmgzvlwbk0jkkdc28r-guix-0.14.0-3.f76ff98/bin/.guix-real")
In guix/ui.scm:
390:2  4 (show-version-and-exit _)
In ice-9/format.scm:
  1590:19  3 (format #t "Copyright ~a 2017 ~a" "(C)" "the Guix authors\n")
   261:19  2 (format:format-work "Copyright ~a 2017 ~a" ("(C)" "the Guix 
authors\n"))
70:10  1 (format:out-obj-padded _ _ _ _)
In unknown file:
   0 (display "the Guix authors\n" #)

ERROR: In procedure display:
ERROR: In procedure fport_write: Broken pipe
g1@g1 ~/www/VM-on-GuixSD$ guix --version | head -n 1
guix (GNU Guix) 0.14.0.617-e2f37
Backtrace:
   5 (primitive-load 
"/gnu/store/nxdxbad50ydp1nhmgzvlwbk0jkkdc28r-guix-0.14.0-3.f76ff98/bin/.guix-real")
In guix/ui.scm:
390:2  4 (show-version-and-exit _)
In ice-9/format.scm:
  1590:19  3 (format #t "Copyright ~a 2017 ~a" "(C)" "the Guix authors\n")
   261:19  2 (format:format-work "Copyright ~a 2017 ~a" ("(C)" "the Guix 
authors\n"))
70:10  1 (format:out-obj-padded _ _ _ _)
In unknown file:
   0 (display "the Guix authors\n" #)

ERROR: In procedure display:
ERROR: In procedure fport_write: Broken pipe
***

VERSION:
***
g1@g1 ~$ guix --version
guix (GNU Guix) 0.14.0.617-e2f37
Copyright (C) 2017 the Guix authors
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.

bug#30100: core-updates: GHC / Haskell fails to build

[Ludovic Courtès]

Leo Famulari  skribis:

> On core-updates, GHC 7.10.2 fails to build, so there are currently no
> Haskell packages for core-updates:
>
> https://hydra.gnu.org/build/2414139
>
> It looks like the libtinfo substitutions have stopped working:
>
> --
> Installing library in
> /tmp/guix-build-ghc-7.10.2.drv-0/ghc-7.10.2/ghc-bin/usr/lib/ghc-7.8.4/haskell2010-1.1.2.0
> "/tmp/guix-build-ghc-7.10.2.drv-0/ghc-7.10.2/ghc-bin/usr/lib/ghc-7.8.4/bin/ghc-pkg"
>  --force --global-package-db 
> "/tmp/guix-build-ghc-7.10.2.drv-0/ghc-7.10.2/ghc-bin/usr/lib/ghc-7.8.4/package.conf.d"
>  update rts/dist/package.conf.install
> /tmp/guix-build-ghc-7.10.2.drv-0/ghc-7.10.2/ghc-bin/usr/lib/ghc-7.8.4/bin/ghc-pkg:
>  error while loading shared libraries: libtinfo.so.5: cannot open shared 
> object file: No such file or directory
> make[1]: *** [ghc.mk:908: install_packages] Error 127
> make: *** [Makefile:24: install] Error 2
> phase `install-bin' failed after 9.3 seconds
> builder for `/gnu/store/6nvmpr7z6rgg7px9m0z72k65ramd0w7k-ghc-7.10.2.drv' 
> failed with exit code 1
> --

Fixed in ae785e5e55acb6cf4352c871b4840cc52aab0379.\o/

Ludo’.

bug#29662: bug#24194: GUIX gc - add warning

[Adonay Felipe Nogueira]

Has the person who had the unsubscription issue already solved the
specific problem? I'm sending this message to person anyways, if you
received it twice, then you are still subscribed.

Can some list administrator confirm if the person is already
unsubscribed?

Finally, Joshua, I think we are discussing in bug-guix mailing list, not
guix-devel (I can see this because if I choose to reply to group, my
email client writes bug-guix email address in the To field of my
message).

2017-12-24T23:16:20+ Joshua Branson wrote:
> Hey,
> Sorry to bother you guys, but I'm having trouble leaving this email list...
>
> I've tried logging into the web interface, and that failed.
>
> I tried emailing guix-devel-le...@gnu.org, and that didn't seam to work. 
>
> Can someone help me leave this email list?
>
> Thanks,
>
> Joshua

-- 
- https://libreplanet.org/wiki/User:Adfeno
- Palestrante e consultor sobre /software/ livre (não confundir com
  gratis).
- "WhatsApp"? Ele não é livre. Por favor, veja formas de se comunicar
  instantaneamente comigo no endereço abaixo.
- Contato: https://libreplanet.org/wiki/User:Adfeno#vCard
- Arquivos comuns aceitos (apenas sem DRM): Corel Draw, Microsoft
  Office, MP3, MP4, WMA, WMV.
- Arquivos comuns aceitos e enviados: CSV, GNU Dia, GNU Emacs Org, GNU
  GIMP, Inkscape SVG, JPG, LibreOffice (padrão ODF), OGG, OPUS, PDF
  (apenas sem DRM), PNG, TXT, WEBM.

bug#29519: ./pre-inst-env: substitute: Failed to autoload make-session in (gnutls)

[Leo Famulari]

On Tue, Jan 16, 2018 at 04:40:30PM -0200, Adonay Felipe Nogueira wrote:
> I didn't test this yet, but I was wondering about `sudo'
> "-E"/"--preserve-env" option, wasn't it dropped because it would
> conflict with other variables that the user has? Or better yet, because
> it would take package definitions from other places?
> 
> 2017-12-04T10:07:40+0100 Ludovic Courtès wrote:
> > Hello,
> >
> > The problem is that the (gnutls) module is not in the search path of
> > ‘guix substitute’.
> >
> > Usually the solution is to start the daemon using something like:
> >
> >   sudo -E ./pre-inst-env guix-daemon …
> >
> > so that ‘guix-daemon’ inherits the correct values for ‘GUILE_LOAD_PATH’,
> > etc.
> >
> > Does that work for you?
> >
> > We used to have this suggestion in the doc, but it was reverted in
> > commit 73a203450d21241eca50375aeb26fb418b287414.  Leo, do you think we
> > can reinstate it?  I’m not sure why it was reverted in the first place.

I missed this request previously :/

Originally, I reverted the suggestion because it was causing problems
for some users on #guix, and I thought it was risky to propagate the
user's environment into a privileged context.

But perhaps it's not any more risky than using sudo, in general.

Ludo, please let me know if you'd still like me to reinstate the advice
to use `sudo -E`.


signature.asc
Description: PGP signature

bug#29519: ./pre-inst-env: substitute: Failed to autoload make-session in (gnutls)

[Adonay Felipe Nogueira]

I didn't test this yet, but I was wondering about `sudo'
"-E"/"--preserve-env" option, wasn't it dropped because it would
conflict with other variables that the user has? Or better yet, because
it would take package definitions from other places?

2017-12-04T10:07:40+0100 Ludovic Courtès wrote:
> Hello,
>
> The problem is that the (gnutls) module is not in the search path of
> ‘guix substitute’.
>
> Usually the solution is to start the daemon using something like:
>
>   sudo -E ./pre-inst-env guix-daemon …
>
> so that ‘guix-daemon’ inherits the correct values for ‘GUILE_LOAD_PATH’,
> etc.
>
> Does that work for you?
>
> We used to have this suggestion in the doc, but it was reverted in
> commit 73a203450d21241eca50375aeb26fb418b287414.  Leo, do you think we
> can reinstate it?  I’m not sure why it was reverted in the first place.
>
> Thanks,
> Ludo’.
>

bug#30097: [core-updates] nspr 4.17 not reproducible

[Marius Bakke]

Gábor Boskovits  writes:

> 2018-01-14 20:51 GMT+01:00 Marius Bakke :
>
>> Gábor Boskovits  writes:
>>
>> > 2018-01-14 19:28 GMT+01:00 Marius Bakke :
>> >
>> >> Gábor Boskovits  writes:
>> >>
>> >> > nspr 4.17 is not reproducible.
>> >> > Diffoscope output attached.
>> >>
>> >> Thanks for the report!
>> >>
>> >> The attached patch should solve it.  Since there are quite a few
>> >> dependent packages, I'd like to push this to a new 'staging' branch that
>> >> will be started shortly after the core-updates merge.  WDYT?
>> >>
>> >> Yes, it should go to a branch.
>> >
>> > I also don't know if this fixes the difference also, where an additional
>> ;
>> > is present...
>> > Could you check this, or should I run a test with the patch?
>> > It seems like a 2 byte difference.
>>
>> It passes `guix build --rounds=2`, so I'm not sure what was up with that
>> ";".
>>
>
> Most probably it is some kind of checksum which includes the timestamp.
> If it passes "guix build --rounds=2" it should be fine.
> Thanks for the clarification.

I pushed this to a new 'staging' branch based off core-updates.


signature.asc
Description: PGP signature

bug#25296: fully functional desktop installation

[Mathieu Lirzin]

Hi,

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

> Mathieu Lirzin  skribis:
>
>> IMHO Guix should mimic what Debian is doing in this particular case.
>> Meaning having desktop packages that contain a “full” desktop with
>> default applications for common usages.
>>
>> This would consist in adding ‘libreoffice’ and replacing ‘epiphany’ with
>> ‘icecat’ in the ‘gnome’ package.  Additionally a ‘gnome-core’ package
>> (or ‘gnome-minimal’ which seems to be the name convention chosen by
>> Guix) could be created with the minimal set of packages required to have
>> a working GNOME desktop, for OCD people that don't like having unused
>> packages installed.
>
> Hmm, OK.  Do you think it’s too much to ask, given the current audience
> (tinkerers), to add those packages to their config, or to install them
> with “guix package -i”?

Definitely not, it is even better for tinkerers to not have those
“bloated” bundles/meta-packages full of defaults they don't like.  :-)

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

bug#25296: fully functional desktop installation

[Ludovic Courtès]

Danny Milosavljevic  skribis:

>> Hmm, OK.  Do you think it’s too much to ask, given the current audience
>> (tinkerers), to add those packages to their config, or to install them
>> with “guix package -i”?

[...]

> Long story short, I think it's a good thing that the user has his own profile 
> which isn't magically updated and doesn't magically pick up things not in the 
> user profile - except when it's already in the store bitwise-identical.  That 
> way, if he needs some application for work it will not randomly break and he 
> can be sure that it will do what it did yesterday.  If he wants to update, he 
> updates.  Otherwise not.  His choice.

Agreed, though in this case (GNOME), we’re pretty much talking about
single-user machines.

> I'd vote for adding libreoffice and icecat to desktop.tmpl and not to gnome 
> (since they are not part of the GNOME project).

OK, why not.  There’s still the issue that it will make download times
and disk size requirements longer (a problem we should fix, but this
won’t happen overnight.)

Ludo’.

bug#25296: fully functional desktop installation

[Ludovic Courtès]

Hi Konrad,

Konrad Hinsen  skribis:

>> Hmm, OK.  Do you think it’s too much to ask, given the current audience
>> (tinkerers), to add those packages to their config, or to install them
>> with “guix package -i”?
>>
>> Admittedly this is a very subjective issue.
>
> How about organizing Guix in a layered way, with the core distribution
> containing narrow-purpose packages (mostly one piece of software), and
> another layer (in a distinct module, perhaps with a distinct naming
> convention) containing collections of software that works well
> together or is useful for a specific application domain? I see other
> use cases than just desktop stuff.

In GuixSD, that’s more or less what happens with ‘gnome-service-type’
and ‘xfce-service-type’, for example.  (I’m not sure how that could work
at the Guix level, nor whether this is necessary.)

Ludo’.

bug#25296: fully functional desktop installation

[Konrad Hinsen]

Hi,


Hmm, OK.  Do you think it’s too much to ask, given the current audience
(tinkerers), to add those packages to their config, or to install them
with “guix package -i”?

Admittedly this is a very subjective issue.


How about organizing Guix in a layered way, with the core distribution 
containing narrow-purpose packages (mostly one piece of software), and 
another layer (in a distinct module, perhaps with a distinct naming 
convention) containing collections of software that works well together 
or is useful for a specific application domain? I see other use cases 
than just desktop stuff.


The main rationale for distinct layers is that assembling software at 
different levels requires different competences and different ways of 
documenting the assemblies. In the long run, I'd expect different people 
to be in charge of each layer.


Konrad.

bug#30116: [PATCH] `substitute' crashes when file contains NUL characters (core-updates)

[Ludovic Courtès]

Hi,

Maxim Cournoyer  skribis:

> I've encountered the following crash when trying to use substitute on a
> file which contains NUL characters:

Yes, that’s because Guile’s ‘regexp-exec’ simply wraps libc’s ‘regexec’,
which does not handle NULs.

We should consider switching to the pure-Scheme SRFI-115:

  https://srfi.schemers.org/srfi-115/srfi-115.html

Ludo’.

bug#22039: ‘guix system reconfigure’ does not always load new services

[Ludovic Courtès]

Forwarded from
.

--- Begin Message ---
Hello,

ng0  skribis:

> I noticed a `herd restart guix-daemon` after reconfigure wasn't
> enough, I had to reboot to make use of the new guix. Could this
> be improved?

Yes, that’s a problem (Andreas also reported it to me a couple of days
ago.)

The problem is that ‘guix system reconfigure’ reloads and restarts
services that were not currently running.  For other services, such as
guix-daemon, it does nothing—it does not even load the new version.

This is because the Shepherd currently doesn’t offer a way to “hot-swap”
services without stopping them.  Instead it first unloads the service,
loads the new one, and (optionally) starts it.  See (gnu services herd).

So what we would need is to somehow overwrite the current service.  The
problem is that it may be incorrect, for instance because we’d like to
use the ‘stop’ action of the previous service when we eventually stop
it, rather than the new ‘stop’ action.  So perhaps we should register
the new service so that it replaces the old one only when the old one is
stopped.

Thoughts?

Ludo’.

--- End Message ---

bug#25296: fully functional desktop installation

[Danny Milosavljevic]

Hi,

> Hmm, OK.  Do you think it’s too much to ask, given the current audience
> (tinkerers), to add those packages to their config, or to install them
> with “guix package -i”?

I think one of the nice features of Guix is that the user can install packages 
on their own.  Other distributions leave the decision of which packages to 
install up to the administrator (a separate person in companies).  I work in a 
very large company where often some simple stuff is missing on servers and 
admins will not install it for fear of fucking up some unrelated 
already-installed package (understandable since all the dependencies are 
dynamic in Solaris and applications will just pick up whatever is lying around 
in the global namespace).

Long story short, I think it's a good thing that the user has his own profile 
which isn't magically updated and doesn't magically pick up things not in the 
user profile - except when it's already in the store bitwise-identical.  That 
way, if he needs some application for work it will not randomly break and he 
can be sure that it will do what it did yesterday.  If he wants to update, he 
updates.  Otherwise not.  His choice.

So long story short, I myself prefer having no applications in the system 
profile and the user installing all (business-relevant) applications 
themselves.  It gives control to the user.

(my "packages" field is:
  (packages (cons* nss-certs ;for HTTPS access
   font-adobe100dpi font-adobe75dpi font-bitstream-vera 
font-dejavu font-gnu-freefont-ttf font-gnu-unifont font-liberation font-ubuntu
   adwaita-icon-theme
   %base-packages)) ; xterm is there by default.

And the ones that are still in there bother me :)
)

As for libreoffice and other large packages, maybe I'm old-fashioned, but huge 
packages waste disk space and provide an attack surface for exploits - and 
maybe no regular user uses it.

That said, I've installed it :P

I'd vote for adding libreoffice and icecat to desktop.tmpl and not to gnome 
(since they are not part of the GNOME project).

Users who like a minimal system can always use lightweight-desktop.tmpl or even 
bare-bones.tmpl.

And I think it's important to mention the approximate space requirements for 
desktop.tmpl in the manual (for partitioning).

bug#25296: fully functional desktop installation

[Ludovic Courtès]

Hi,

Mathieu Lirzin  skribis:

> IMHO Guix should mimic what Debian is doing in this particular case.
> Meaning having desktop packages that contain a “full” desktop with
> default applications for common usages.
>
> This would consist in adding ‘libreoffice’ and replacing ‘epiphany’ with
> ‘icecat’ in the ‘gnome’ package.  Additionally a ‘gnome-core’ package
> (or ‘gnome-minimal’ which seems to be the name convention chosen by
> Guix) could be created with the minimal set of packages required to have
> a working GNOME desktop, for OCD people that don't like having unused
> packages installed.

Hmm, OK.  Do you think it’s too much to ask, given the current audience
(tinkerers), to add those packages to their config, or to install them
with “guix package -i”?

Admittedly this is a very subjective issue.

Ludo’.

bug#30121: python-matplotlib broken.

[Konrad Hinsen]

On 15/01/2018 17:41, Konrad Hinsen wrote:


After a quick look at the definition of python-matplotlib, I suspect
that python-pyqt should be a propagated-input, not a plain input.
I will try this out as soon as possible.


That was indeed the cause of the bug. I have submitted a patch:

  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=30135

Konrad.