bug#37249: console shell upon login is not ~/.guix-profile/bash -- is this always/never ok?
Hello,
In the pursuit of causes for problems as yet not clear enough to
post as bugs, I am looking for ambivalences in name searches
in /gnu/... and /(the-rest).
The first is immediately bash:
To duplicate, log into a fresh console and look at what's running
and invoked. I did an Alt-F4 and logged in fresh, and captured the
terminal screen seen in the following:
-8<-
[ ... snip some output from .bash_profile ... ]
[13:33 ~/bs]$ ps -o pid,tty,args
PID TT COMMAND
25500 tty4 -bash
25966 tty4 ps -o pid,tty,args
[13:35 ~/bs]$ which -a ps
/usr/bin/ps
[13:35 ~/bs]$ file /proc/25500/exe
/proc/25500/exe: symbolic link to /usr/bin/bash
So, the shell I am talking to right after login is /usr/bin/bash,
but if I type bash, the guix version will be found first:
[13:36 ~/bs]$ which -a bash
/home/bokr/.guix-profile/bin/bash
/usr/bin/bash
[13:38 ~/bs]$ which -a bash|xargs readlink -f
/gnu/store/qn1ax1fkj16x280m1rv7mcimfmn9l2pf-bash-4.4.23/bin/bash
/usr/bin/bash
So, nesting into the guix one,
[13:39 ~/bs]$ bash
[13:39 ~/bs]$ ps -o pid,tty,args
PID TT COMMAND
25500 tty4 -bash
26226 tty4 bash
26253 tty4 ps -o pid,tty,args
[13:40 ~/bs]$ file /proc/26226/exe
/proc/26226/exe: symbolic link to
/gnu/store/qn1ax1fkj16x280m1rv7mcimfmn9l2pf-bash-4.4.23/bin/bash
Indeed our current pid belongs to guix bash.
What is the difference? They were built differently...
[13:41 ~/bs]$
[13:42 ~/bs]$ which -a bash
/home/bokr/.guix-profile/bin/bash
/usr/bin/bash
[13:43 ~/bs]$ which -a bash|xargs readlink -f|while read line;do echo -ne
"$line:\n"; file "$line";done
/gnu/store/qn1ax1fkj16x280m1rv7mcimfmn9l2pf-bash-4.4.23/bin/bash:
/gnu/store/qn1ax1fkj16x280m1rv7mcimfmn9l2pf-bash-4.4.23/bin/bash:
ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked,
interpreter
/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/ld-linux-x86-64.so.2,
for GNU/Linux 2.6.32, not stripped
/usr/bin/bash:
/usr/bin/bash: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV),
dynamically linked,
interpreter /lib64/ld-linux-x86-64.so.2,
BuildID[sha1]=21a51cb5f7d727370e4d8099d283d7cd20222571,
for GNU/Linux 3.2.0, stripped
Are the differences possibly dangerous?
The way I got the above, and this tail part itself:
[13:45 ~/bs]$ tty
/dev/tty4
[13:47 ~/bs]$ su -c 'setterm -file login-bashes.txt -dump 4'
Looking for dependencies outside of /gnu from within /gnu, I grepped the whole
as you see below. I am sure most of this is fine and coming out of documentation
and stuff meant for other than normally booted runtime. But does it all look ok?
Or is my foreign-host twilight-zone shared ArchLinux/guix namespace really not
meant to be. I.e., is guix really defined to use /usr/ as a trusted base
namespace
when it is defined by e.g. linux-libre in GuixSD ?
Where would be the best docs to read about the guix name and environment
rationales?
Ok, here is the grep:
(most of the bashes are in the store, as seen at the bottom, but many not)
---
This was generated by:
grep -Ihr '^ *#!' /gnu|sort|uniq -c|sort -h > gnu-bin-hash-bangs.txt
2 #!/bin/csh
2 #!/bin/tcsh
2 #!@GAWK@ -f
2 #!/gnu/store/03n7p9g78ixkrmra674pkx2c9cx8fwmz-guile-1.8.8/bin/guile \
2
#!/gnu/store/0xfmkqpi7xk3ixhrqvjijk4ibsglif62-python-3.7.0/bin/python3.7m
2 #!/gnu/store/57daq0hkwvmwx4asiy669cmln868brfm-python2-2.7.15/bin/python2
2 #!/gnu/store/9alic3caqhay3h8mx4iihpmyj6ymqpcx-guile-2.2.4/bin/guile
2
#!/gnu/store/b7fqhszxl02g6pfm3vw6b3cjz472qrly-python-3.7.0/bin/python3.7m
2
#!/gnu/store/cl42c73h609bp2gy92qkh8q56spnnl2n-python-3.7.0/bin/python3.7m
2 #! /gnu/store/dna8kpb00kq176rz8x69yy4j33my2q55-perl-5.28.0/bin/perl
2
#!/gnu/store/h8l1pby3cm6b4fxsfwwr65b4d1hyh6cs-python-3.7.0/bin/python3.7m
2 #!/gnu/store/l67sib1ld0fgyf0f4vrzyxnmn4yvimvb-gawk-4.2.1/bin/gawk -f
2 #!/gnu/store/qn1ax1fkj16x280m1rv7mcimfmn9l2pf-bash-4.4.23/bin/sh -
2
#!/gnu/store/ybglr7nfs8v9kpnm8vf4drg3gafnvd15-guile-static-stripped-2.2.4/bin/guile
--no-auto-compile
2 #!/gnu/store/zm3188ipzi262s0m8bxm24br77yh9pd8-python-3.7.0/bin/python3
2
#!/gnu/store/zm3188ipzi262s0m8bxm24br77yh9pd8-python-3.7.0/bin/python3.7m
2 #!@GUILE@ -s
2 #!@PHP@ -q
2 #!@TCLSH@
2 #! /usr/bin/perl
2 #!/usr/bin/perl -- # -*- Perl -*-
2 #! /usr/bin/perl -w
2 #! /usr/bin/python
2 #!/usr/bin/python -u
2 #!@WISH@
3 #!#{Gem.ruby}
3
#!/gnu/store/81y6l9ggc5q6z44hp90ll4dv5jl582mq-texlive-bin-20180414/bin/texlua
3
#!/gnu/store/hw0cz0mis43z19i76pl6ijx5risx4lf0-texlive-bin-20180414/bin/texlua
3 #!/gnu/store/lgbiv7q1b6m141nrkjm92qkl9ih5gamw-python2-2.7.15/bin/python
-O
3
#!/gnu/store/pyrlmxqx3g1mhzpnfpw4w94rj08wxfhj-texlive-bin-20180414/bin/texlua
3
bug#37248: GNOME and Icecat problems
There are several problems with using GNOME 3.28 and Icecat 60 on Guix, many of which impact each other. 1. The gnome-tweaks package can't find gnome-shell extensions from the gnome-shell-extensions package, and so claims none are installed. This is a packaging problem because on normal distributions, packaged extensions are visible to gnome-tweaks. 2. The stock "Web" browser is not able to install shell extensions. This may be an upstream bug. 3. Icecat can not install gnome-shell extensions because the Native Connector is not packaged in Guix. Despite the misleading name, this is the tool needed. https://wiki.gnome.org/Projects/GnomeShellIntegrationForChrome/Installation 4. Icecat is unable to sign in to Firefox sync. This is apparently fixed in 68.
bug#36402: installation error
Hey Ludo, > Does that make sense? > > I think we should audit and adjust Guile-Parted in that spirit. WDYT? Sorry for the delay! I followed your advice and hid all destroy related functions behind pointer finalizers. I also added some unit tests to Guile-Parted. I pushed everything but feel free to comment! Then, I'll make a new release and try to adapt the installer to those changes. Thanks, Mathieu
bug#37246: Cuirass builds spuriously fail with truncated build logs
Cuirass builds sometimes spuriously fail with truncated build logs.
Recent examples:
https://ci.guix.gnu.org/build/1643344/details
https://ci.guix.gnu.org/build/1632149/details
Previously, we've noticed that this problem happens quite frequently
with armhf builds offloaded to hydra-slave{1,2,3}, which are hosted far
from Berlin. The examples above show that this problem also happens
with build slaves that are local to Berlin.
Mark
bug#37244: Icecat Audio Issues
Hello! Not sure the issue is with upstream or with guix system. While streaming/watching movie on some (more than one) websites, audio has constant cracking sounds and voice of characters in the video becomes robotic. When I stream/watch the same movie on ungoogled-chromium, the audio is just fine. This issue with Icecat has been there for quite some time (across multiple updates). I also tried running IceCat on safe-mode and got the same issue. INFO: My Guix System and Icecat are up-to-date. Regards, RG. signature.asc Description: This is a digitally signed message part
bug#36747: Official MesCC bootstrap binaries differ from my locally built ones
Hi, Mark H Weaver skribis: > Ludovic Courtès writes: > >> Mark H Weaver skribis: >> >>> Thanks. The next evaluation got further, but eventually failed. Again, >>> there seems no way to get any details on what went wrong from the web >>> interface: >>> >>> https://ci.guix.gnu.org/jobset/core-updates-core-updates >>> https://ci.guix.gnu.org/eval/7029 >> >> A Guile build of >> /gnu/store/lbbgpkrs9mpw68k1bz0dwpi8ch6gp557-guile-2.2.6.drv had timed >> out. I restarted manually earlier today with a larger timeout. It >> succeeded and a new evaluation is now “in progress”… > > Thanks. It has since failed again, same as before. This time it was ENOSPC of a Guile derivation. I’ve restarted it and then restarted the evaluation. > I'm unable to get any information from the web interface on what went > wrong. Yup. :-/ Ludo’.
bug#37162: ‘guix pack -f docker’ creates an image without /etc/passwd
Hello! Sorry for the late reply.
Ludovic Courtès writes:
> Hi Maxim,
>
> Maxim Cournoyer skribis:
>
>> Ricardo Wurmus writes:
>>
>>> Hi Maxim,
>>>
Ludovic Courtès writes:
> ‘guix pack -f docker’ currently creates an image without
> /etc/{passwd,group,shadow}.
>
> It’s OK most of the time, but again it looks like a gratuitous annoyance
> for those cases where having them around matters (that’s also the reason
> why guix-daemon creates them.)
Would that include the files required for PAM authentication to work
correctly? I remember struggling with this use case: using the Docker
image with CQFD wrapper, which must be able to create a user and
sudo'ing (or 'su') to it in the docker container.
>>>
>>> I wonder if at this point it wouldn’t be better to build a whole system
>>> container. Isn’t that outside the scope of “guix pack” and rather a
>>> task for “guix system”?
>
> I think so.
>
>> Probably! But then one has to wonder if adding some base files to `guix
>> pack' is not one of those slippery slopes where users come back
>> expecting more stuff to be there?
>>
>> What use case(s) exactly depend on the presence of the
>> /etc/{passwd,group,shadow} files?
>
> Generally, absent these files, getpw(3) and co. won’t give useful
> results, and some applications will behave poorly (e.g., the PS1 prompt
> in Bash can’t show the user name; ‘id’ fails).
I see! I understand better the source of the annoyance now, thanks!
> Most of the time it’s just a minor inconvenience.
It seems OK to me to add those small files since make the experience
better.
Maxim
