bug#27489: glibc fails to build on i686

[Mark H Weaver]

Adonay Felipe Nogueira  writes:

> NOTE: This message isn't meant to sound aggressive, it's just a question
> from a novice Guix user.
>
> Here is my situation:
>
> - I'm using Guix in a foreign distribution (Trisquel 7).
>
> - In 2017-06-12, I pulled and upgraded Guix and packages successfully as
>   root.
>
> - Last weekend I did (all as root): `guix gc` (successful), `guix pull`
>   (successful), `guix package -u guix` (not successful, because of this
>   bug).
>
> - Some time has passed, and the core-updates branch now seems to have a
>   fix for this bug.
>
> - Yesterday (or was it the day before it?), I did (all as root): `guix
>   gc` (successful), `guix pull` (not successfull, because of this bug),

It might be that you need to manually remove the ~/.config/guix/latest
symlink in root's home directory, and then run "guix pull" again.
Normally this is not needed, but in this case it might be needed to
recover from your current state.

As an aside: I'm not sure why you're running these commands as root.
Running "guix pull" as a user FOO effectively updates the package list
for user FOO, and not for any other user.  Running it as root is no
exception to this rule.  Each user, including root, has their own
private package list.

The main reason to run these commands as root is if you want to update
the packages in ~root/.guix-profile, or if you want to update a GuixSD
system.  Normally, each user runs these commands, including "guix pull"
under their own account.

>   `guix gc`, `guix pull
>   
> --url="https://git.savannah.gnu.org/cgit/guix.git/snapshot/guix-ed068b960eeedb92823238783779730319b8ba0e.tar.gz"`
>   (not successful, because of this bug). Notice that in the last pull I
>   used the snapshot corresponding to the merge in core-updates that has
>   the fix.

As Leo said, unless you want to help us debug problems on core-updates,
it's best stick with 'master' for now.  'master' is the only branch that
receives timely security updates.  'core-updates' is a work-in-progress,
and at present there are many broken packages there.

  Mark

bug#27489: glibc fails to build on i686

[Leo Famulari]

On Wed, Jun 28, 2017 at 09:57:39PM -0300, Adonay Felipe Nogueira wrote:
> Here is my situation:
> 
> - I'm using Guix in a foreign distribution (Trisquel 7).
> 
> - In 2017-06-12, I pulled and upgraded Guix and packages successfully as
>   root.
> 
> - Last weekend I did (all as root): `guix gc` (successful), `guix pull`
>   (successful), `guix package -u guix` (not successful, because of this
>   bug).

I'm sorry you experienced this bug. We didn't test the change to glibc
on i686-linux so we didn't notice this problem until after we pushed it.

> - Some time has passed, and the core-updates branch now seems to have a
>   fix for this bug.

As announced earlier in this bug discussion, the bug was fixed on the
master branch with commit ffc015bea26f24d862e7e877d907fbe1ab9a9967.

https://git.savannah.gnu.org/cgit/guix.git/commit/?id=ffc015bea26f24d862e7e877d907fbe1ab9a9967

> - Yesterday (or was it the day before it?), I did (all as root): `guix
>   gc` (successful), `guix pull` (not successfull, because of this bug),
>   `guix gc`, `guix pull
>   
> --url="https://git.savannah.gnu.org/cgit/guix.git/snapshot/guix-ed068b960eeedb92823238783779730319b8ba0e.tar.gz"`
>   (not successful, because of this bug). Notice that in the last pull I
>   used the snapshot corresponding to the merge in core-updates that has
>   the fix.

I recommend you try again, but on the master branch. Core-updates is not
currently usable (hopefully soon!).


signature.asc
Description: PGP signature

bug#27489: glibc fails to build on i686

[Adonay Felipe Nogueira]

NOTE: This message isn't meant to sound aggressive, it's just a question
from a novice Guix user.

Here is my situation:

- I'm using Guix in a foreign distribution (Trisquel 7).

- In 2017-06-12, I pulled and upgraded Guix and packages successfully as
  root.

- Last weekend I did (all as root): `guix gc` (successful), `guix pull`
  (successful), `guix package -u guix` (not successful, because of this
  bug).

- Some time has passed, and the core-updates branch now seems to have a
  fix for this bug.

- Yesterday (or was it the day before it?), I did (all as root): `guix
  gc` (successful), `guix pull` (not successfull, because of this bug),
  `guix gc`, `guix pull
  
--url="https://git.savannah.gnu.org/cgit/guix.git/snapshot/guix-ed068b960eeedb92823238783779730319b8ba0e.tar.gz"`
  (not successful, because of this bug). Notice that in the last pull I
  used the snapshot corresponding to the merge in core-updates that has
  the fix.

Now, I'm thinking, how can I make the pull and the Guix package upgrade?


Respectfully, Adonay.
-- 
- [[https://libreplanet.org/wiki/User:Adfeno]]
- Palestrante e consultor sobre /software/ livre (não confundir com
  gratis).
- "WhatsApp"? Ele não é livre, por isso não uso. Iguais a ele prefiro
  GNU Ring, ou Tox. Quer outras formas de contato? Adicione o vCard
  que está no endereço acima aos teus contatos.
- Pretende me enviar arquivos .doc, .ppt, .cdr, ou .mp3? OK, eu
  aceito, mas não repasso. Entrego apenas em formatos favoráveis ao
  /software/ livre. Favor entrar em contato em caso de dúvida.

bug#27386: offloading documentation and env

[ng0]

Ludovic Courtès transcribed 2.2K bytes:
> ng0  skribis:
> 
> > I think the method as described never really worked.
> >
> > When I do as you (and the manual) suggested, I no longer
> > have any results for ssh host env | grep "GUILE_".
> >
> > When I extend it like this it works. I include the full
> > paste to show that previously I had the sourcing of /etc/profile
> > in it:
> >
> > user@shadownet ~$ cat .bashrc
> > # Bash initialization for interactive non-login shells and
> > # for remote shells (info "(bash) Bash Startup Files").
> >
> > # Export 'SHELL' to child processes.  Programs such as 'screen'
> > # honor it and otherwise use /bin/sh.
> > export SHELL
> >
> > if [ -n "$SSH_CLIENT" -a -z "`type -P cat`" ]
> > then
> > # We are being invoked from a non-interactive SSH session
> > # (as in "ssh host command") but 'cat' cannot be found
> > # in $PATH.  Source /etc/profile so we get $PATH and other
> > # essential variables.
> > source /etc/profile
> > fi
> >
> > # Adjust the prompt depending on whether we're in 'guix environment'.
> > if [ -n "$GUIX_ENVIRONMENT" ]
> > then
> > PS1='\u@\h \w [env]\$ '
> > else
> > PS1='\u@\h \w\$ '
> > fi
> > source ~/.guix-profile/etc/profile
> > alias ls='ls -p --color'
> > alias ll='ls -l'
> > GUILE_LOAD_COMPILED_PATH="${GUILE_LOAD_COMPILED_PATH}:/run/current-system/profile/lib/guile/2.2/site-ccache:/run/current-system/profile/share/guile/site/2.2"
> > GUILE_LOAD_PATH="${GUILE_LOAD_PATH}:/run/current-system/profile/share/guile/site/2.2"
> 
> The difference compared to /etc/skel/.bashrc is the last two lines,
> right?

Yes. And that I source ~/.guix-profile/etc/profile before those lines.

> On my GuixSD installation they’re not needed because /etc/profile
> sources /run/current-system/profile/etc/profile, which already defines
> these two variables.

Well this file is the same on both systems involved:

user@abyayala ~$ cat /etc/profile
# Crucial variables that could be missing in the profiles' 'etc/profile'
# because they would require combining both profiles.
# FIXME: See .
export 
MANPATH=$HOME/.guix-profile/share/man:/run/current-system/profile/share/man
export 
INFOPATH=$HOME/.guix-profile/share/info:/run/current-system/profile/share/info
export XDG_DATA_DIRS=$HOME/.guix-profile/share:/run/current-system/profile/share
export 
XDG_CONFIG_DIRS=$HOME/.guix-profile/etc/xdg:/run/current-system/profile/etc/xdg

# Ignore the default value of 'PATH'.
unset PATH

# Load the system profile's settings.
GUIX_PROFILE=/run/current-system/profile \
. /run/current-system/profile/etc/profile

# Prepend setuid programs.
export PATH=/run/setuid-programs:$PATH

# Since 'lshd' does not use pam_env, /etc/environment must be explicitly
# loaded when someone logs in via SSH.  See .
# We need 'PATH' to be defined here, for 'cat' and 'cut'.  Do this before
# reading the user's 'etc/profile' to allow variables to be overridden.
if [ -f /etc/environment -a -n "$SSH_CLIENT" \
 -a -z "$LINUX_MODULE_DIRECTORY" ]
then
  . /etc/environment
  export `cat /etc/environment | cut -d= -f1`
fi

if [ -f "$HOME/.guix-profile/etc/profile" ]
then
  # Load the user profile's settings.
  GUIX_PROFILE="$HOME/.guix-profile" \
  . "$HOME/.guix-profile/etc/profile"
else
  # At least define this one so that basic things just work
  # when the user installs their first package.
  export PATH="$HOME/.guix-profile/bin:$PATH"
fi

# Set the umask, notably for users logging in via 'lsh'.
# See .
umask 022

# Allow GStreamer-based applications to find plugins.
export GST_PLUGIN_PATH="$HOME/.guix-profile/lib/gstreamer-1.0"

if [ -n "$BASH_VERSION" -a -f /etc/bashrc ]
then
  # Load Bash-specific initialization code.
  . /etc/bashrc
fi


> But maybe your global profile is slightly different from mine, which
> would explain this.  FWIW I have:
> 
> --8<---cut here---start->8---
> $ guix package -I gui -p /run/current-system/profile
> guix  0.13.0-2.de9d8f0out 
> /gnu/store/js4ml3w20ysh4znp9wl0da0ljji4kisl-guix-0.13.0-2.de9d8f0
> guile 2.2.2   out /gnu/store/5zx29y44nrqj0s8h3jlvlj82k8hj4dxs-guile-2.2.2
> --8<---cut here---end--->8---

user@shadownet ~$ guix package -I gui -p /run/current-system/profile
guix0.13.0-2.de9d8f0out 
/gnu/store/nrd0v38d61l8y16vqkb1gws0bw45q885-guix-0.13.0-2.de9d8f0
guile   2.2.2   out /gnu/store/1pzfigry5bnh3n146w0ib77vkd2g6jdc-guile-2.2.2

So it is not different.
The system in use is this: 
https://gitlab.com/ng0/systems/blob/master/servers/pragmatique/shadownet.scm

> Anyway, if you have ideas on how to improve the doc, they’re welcome.
> 
> Thanks for your feedback!
> 
> Ludo’.
-- 
ng0
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://n0is.noblogs.org/my-keys
infotropique: https://www.infotropique.org


signature.asc
Description: PGP 

bug#27429: Stack clash (CVE-2017-1000366 etc)

[Leo Famulari]

On Fri, Jun 23, 2017 at 01:20:38PM -0400, Leo Famulari wrote:
> By the way, Qualys will probably begin publishing their exploits on
> Tuesday [0]:

Here they are:

http://seclists.org/oss-sec/2017/q2/635

It would be good if we tested the relevant exploits against GuixSD.


signature.asc
Description: PGP signature

bug#27386: offloading documentation and env

[Ludovic Courtès]

ng0  skribis:

> I think the method as described never really worked.
>
> When I do as you (and the manual) suggested, I no longer
> have any results for ssh host env | grep "GUILE_".
>
> When I extend it like this it works. I include the full
> paste to show that previously I had the sourcing of /etc/profile
> in it:
>
> user@shadownet ~$ cat .bashrc
> # Bash initialization for interactive non-login shells and
> # for remote shells (info "(bash) Bash Startup Files").
>
> # Export 'SHELL' to child processes.  Programs such as 'screen'
> # honor it and otherwise use /bin/sh.
> export SHELL
>
> if [ -n "$SSH_CLIENT" -a -z "`type -P cat`" ]
> then
> # We are being invoked from a non-interactive SSH session
> # (as in "ssh host command") but 'cat' cannot be found
> # in $PATH.  Source /etc/profile so we get $PATH and other
> # essential variables.
> source /etc/profile
> fi
>
> # Adjust the prompt depending on whether we're in 'guix environment'.
> if [ -n "$GUIX_ENVIRONMENT" ]
> then
> PS1='\u@\h \w [env]\$ '
> else
> PS1='\u@\h \w\$ '
> fi
> source ~/.guix-profile/etc/profile
> alias ls='ls -p --color'
> alias ll='ls -l'
> GUILE_LOAD_COMPILED_PATH="${GUILE_LOAD_COMPILED_PATH}:/run/current-system/profile/lib/guile/2.2/site-ccache:/run/current-system/profile/share/guile/site/2.2"
> GUILE_LOAD_PATH="${GUILE_LOAD_PATH}:/run/current-system/profile/share/guile/site/2.2"

The difference compared to /etc/skel/.bashrc is the last two lines,
right?

On my GuixSD installation they’re not needed because /etc/profile
sources /run/current-system/profile/etc/profile, which already defines
these two variables.

But maybe your global profile is slightly different from mine, which
would explain this.  FWIW I have:

--8<---cut here---start->8---
$ guix package -I gui -p /run/current-system/profile
guix0.13.0-2.de9d8f0out 
/gnu/store/js4ml3w20ysh4znp9wl0da0ljji4kisl-guix-0.13.0-2.de9d8f0
guile   2.2.2   out /gnu/store/5zx29y44nrqj0s8h3jlvlj82k8hj4dxs-guile-2.2.2
--8<---cut here---end--->8---

Anyway, if you have ideas on how to improve the doc, they’re welcome.

Thanks for your feedback!

Ludo’.

bug#27515: texlive-texmf-minimal is not reproducible

[Marius Bakke]

Danny Milosavljevic  writes:

> $ guix build texlive-texmf-minimal --rounds=2
>
> phase `texmf-config' succeeded after 52.0 seconds
> output 
> ‘/gnu/store/jfs5fsn011w64jgmpc6chcnqr1agfv6h-texlive-texmf-minimal-2016’ of 
> ‘/gnu/store/72z7v217vd976hlhyjrxzmwpqr4nzwh6-texlive-texmf-minimal-2016.drv’ 
> differs from 
> ‘/gnu/store/jfs5fsn011w64jgmpc6chcnqr1agfv6h-texlive-texmf-minimal-2016-check’
>  from previous round
> @ build-failed 
> /gnu/store/72z7v217vd976hlhyjrxzmwpqr4nzwh6-texlive-texmf-minimal-2016.drv - 
> 1 output 
> ‘/gnu/store/jfs5fsn011w64jgmpc6chcnqr1agfv6h-texlive-texmf-minimal-2016’ of 
> ‘/gnu/store/72z7v217vd976hlhyjrxzmwpqr4nzwh6-texlive-texmf-minimal-2016.drv’ 
> differs from 
> ‘/gnu/store/jfs5fsn011w64jgmpc6chcnqr1agfv6h-texlive-texmf-minimal-2016-check’
>  from previous round
> note: keeping build directory 
> `/tmp/guix-build-texlive-texmf-minimal-2016.drv-0'
> cannot build derivation 
> `/gnu/store/dpnlwahp8gp65s6a2q3808z9dgcx0cxj-texlive-minimal-2016.drv': 1 
> dependencies couldn't be built

Can you try building with -K and then run:

$ diffoscope /gnu/store/... /gnu/store/...-check | tee diff.out

Please attach a compressed "diff.out" here.


signature.asc
Description: PGP signature

bug#27519: Podofo security bugs

[Leo Famulari]

There were some bugs with security implications reported in Podofo
recently:

http://seclists.org/oss-sec/2017/q2/0
http://seclists.org/oss-sec/2017/q2/1
http://seclists.org/oss-sec/2017/q2/2

I noticed some fixes committed to the Podofo SVN repo:

https://sourceforge.net/p/podofo/mailman/podofo-svn/?viewmonth=201706

We need to try to cherry-pick these fixes.


signature.asc
Description: PGP signature

bug#27491: Indentation issue in emacs

[Arun Isaac]

> I'm not sure what you mean by a "fix".  This is an Emacs issue, and it
> was there since... I don't know, always.

Oh, my bad. I thought it was something related to guix-devel-mode or the
.dir-locals.el

> Moreover, I don't think it's a bug; it's just how Emacs finds a
> beginning of the top-level sexp – it "sees" a leading parenthesis on a
> line and it considers it to be a beginning of the sexp.

bug#27491: Indentation issue in emacs

[Alex Kost]

Arun Isaac (2017-06-27 11:44 +0530) wrote:

> Ok, fixed! :-)
>
> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=2482c02f3b23b2490a6647e0717cf8a4ccf3f6a8
>
> However, I think this is a hack, and the better solution would be to
> actually fix the underlying indentation issue. But, I am too lazy to
> find out how. :-P

I'm not sure what you mean by a "fix".  This is an Emacs issue, and it
was there since... I don't know, always.  Moreover, I don't think it's a
bug; it's just how Emacs finds a beginning of the top-level sexp – it
"sees" a leading parenthesis on a line and it considers it to be a
beginning of the sexp.

-- 
Alex

bug#26443: vim-full 8.0.0494 and above fails its testsuite

[ng0]

ng0 transcribed 2.7K bytes:
> Currently vim-full in version 8.0.0494 is failing its testsuite:
…

We are able to build vim-full again. Closing.
-- 
ng0
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://n0is.noblogs.org/my-keys
infotropique: https://www.infotropique.org


signature.asc
Description: PGP signature

bug#27386: offloading documentation and env

[ng0]

Ludovic Courtès transcribed 1.8K bytes:
> ng0  skribis:
> 
> > Ludovic Courtès transcribed 2.2K bytes:
> >> ng0  skribis:
> >> 
> >> > Ludovic Courtès transcribed 2.8K bytes:
> 
> [...]
> 
> >> The problem here is that
> >> /run/current-system/profile/share/guile/site/2.2, which is where the
> >> Guix modules are on GuixSD as I wrote above, is missing from the search
> >> path.
> >> 
> >> The session started when you run “ssh shadownet env” does not spawn a
> >> login shell; thus ~/.profile and similar are *not* sourced.  I’m using
> >
> > I was aware of this, but I thought we had (guix) available nevertheless
> > and I was just pushing the wrong buttons.
> >
> >> Bash, so on my accounts, I have this in .bashrc (‘.bashrc’ is for
> >> non-login shells):
> >> 
> >> --8<---cut here---start->8---
> >> if [ -n "$SSH_CLIENT" -a -z "`type -P cat`" ]
> >> then
> >> # We are being invoked from a non-interactive SSH session
> >> # (as in "ssh host command") but 'cat' cannot be found
> >> # in $PATH.  Source /etc/profile so we get $PATH and other
> >> # essential variables.
> >> source /etc/profile
> >> fi
> >> --8<---cut here---end--->8---
> >> 
> >> That way, “ssh HOST COMMAND” effectively gets the same environment as a
> >> login shell.
> >
> > I use the same on this computer, but at the end of it I source some
> > files, among them ~/.guix-profile/etc/profile
> >
> > I would guess that sourcing ~/.guix-profile/etc/profile gets into
> > the way and that moving this to .bash_profile could fix the issue.
> >
> > What do you think?
> 
> ~/.guix-profile/etc/profile won't add /run/current-system/… to the
> search path.  You really need to source /etc/profile, which in turn will
> source ~/.guix-profile/etc/profile (on GuixSD).
> 
> HTH,
> Ludo’.

I think the method as described never really worked.

When I do as you (and the manual) suggested, I no longer
have any results for ssh host env | grep "GUILE_".

When I extend it like this it works. I include the full
paste to show that previously I had the sourcing of /etc/profile
in it:

user@shadownet ~$ cat .bashrc
# Bash initialization for interactive non-login shells and
# for remote shells (info "(bash) Bash Startup Files").

# Export 'SHELL' to child processes.  Programs such as 'screen'
# honor it and otherwise use /bin/sh.
export SHELL

if [ -n "$SSH_CLIENT" -a -z "`type -P cat`" ]
then
# We are being invoked from a non-interactive SSH session
# (as in "ssh host command") but 'cat' cannot be found
# in $PATH.  Source /etc/profile so we get $PATH and other
# essential variables.
source /etc/profile
fi

# Adjust the prompt depending on whether we're in 'guix environment'.
if [ -n "$GUIX_ENVIRONMENT" ]
then
PS1='\u@\h \w [env]\$ '
else
PS1='\u@\h \w\$ '
fi
source ~/.guix-profile/etc/profile
alias ls='ls -p --color'
alias ll='ls -l'
GUILE_LOAD_COMPILED_PATH="${GUILE_LOAD_COMPILED_PATH}:/run/current-system/profile/lib/guile/2.2/site-ccache:/run/current-system/profile/share/guile/site/2.2"
GUILE_LOAD_PATH="${GUILE_LOAD_PATH}:/run/current-system/profile/share/guile/site/2.2"


I suggest that we fix the offloading documentation.
If questions are asked (I'm not the first) there are obviously problems
with how it is written.
If no one else takes on this, I will.
-- 
ng0
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://n0is.noblogs.org/my-keys
infotropique: https://www.infotropique.org


signature.asc
Description: PGP signature

bug#27515: texlive-texmf-minimal is not reproducible

[Danny Milosavljevic]

$ guix build texlive-texmf-minimal --rounds=2

phase `texmf-config' succeeded after 52.0 seconds
output ‘/gnu/store/jfs5fsn011w64jgmpc6chcnqr1agfv6h-texlive-texmf-minimal-2016’ 
of ‘/gnu/store/72z7v217vd976hlhyjrxzmwpqr4nzwh6-texlive-texmf-minimal-2016.drv’ 
differs from 
‘/gnu/store/jfs5fsn011w64jgmpc6chcnqr1agfv6h-texlive-texmf-minimal-2016-check’ 
from previous round
@ build-failed 
/gnu/store/72z7v217vd976hlhyjrxzmwpqr4nzwh6-texlive-texmf-minimal-2016.drv - 1 
output ‘/gnu/store/jfs5fsn011w64jgmpc6chcnqr1agfv6h-texlive-texmf-minimal-2016’ 
of ‘/gnu/store/72z7v217vd976hlhyjrxzmwpqr4nzwh6-texlive-texmf-minimal-2016.drv’ 
differs from 
‘/gnu/store/jfs5fsn011w64jgmpc6chcnqr1agfv6h-texlive-texmf-minimal-2016-check’ 
from previous round
note: keeping build directory `/tmp/guix-build-texlive-texmf-minimal-2016.drv-0'
cannot build derivation 
`/gnu/store/dpnlwahp8gp65s6a2q3808z9dgcx0cxj-texlive-minimal-2016.drv': 1 
dependencies couldn't be built

bug#27386: offloading documentation and env

[Ludovic Courtès]

ng0  skribis:

> Ludovic Courtès transcribed 2.2K bytes:
>> ng0  skribis:
>> 
>> > Ludovic Courtès transcribed 2.8K bytes:

[...]

>> The problem here is that
>> /run/current-system/profile/share/guile/site/2.2, which is where the
>> Guix modules are on GuixSD as I wrote above, is missing from the search
>> path.
>> 
>> The session started when you run “ssh shadownet env” does not spawn a
>> login shell; thus ~/.profile and similar are *not* sourced.  I’m using
>
> I was aware of this, but I thought we had (guix) available nevertheless
> and I was just pushing the wrong buttons.
>
>> Bash, so on my accounts, I have this in .bashrc (‘.bashrc’ is for
>> non-login shells):
>> 
>> --8<---cut here---start->8---
>> if [ -n "$SSH_CLIENT" -a -z "`type -P cat`" ]
>> then
>> # We are being invoked from a non-interactive SSH session
>> # (as in "ssh host command") but 'cat' cannot be found
>> # in $PATH.  Source /etc/profile so we get $PATH and other
>> # essential variables.
>> source /etc/profile
>> fi
>> --8<---cut here---end--->8---
>> 
>> That way, “ssh HOST COMMAND” effectively gets the same environment as a
>> login shell.
>
> I use the same on this computer, but at the end of it I source some
> files, among them ~/.guix-profile/etc/profile
>
> I would guess that sourcing ~/.guix-profile/etc/profile gets into
> the way and that moving this to .bash_profile could fix the issue.
>
> What do you think?

~/.guix-profile/etc/profile won't add /run/current-system/… to the
search path.  You really need to source /etc/profile, which in turn will
source ~/.guix-profile/etc/profile (on GuixSD).

HTH,
Ludo’.