bug#39195: guix pull switching between profiles/per-user and profiles/default

[Ludovic Courtès]

Hi,

zimoun  skribis:

> I even propose that Guix bumps the minor version each time
> core-updates or staging is merged. :-)
> Zero cost for us to bump the minor version. And the plus are:
>
>  - a bit easier to navigate; because there more tags in the repo ;-)
>  - non rolling release users expect version numbering; other said
> current Debian or Ubuntu users are "afraid" to "pull" and be in
> "unstable", so they jump only from version to version.
>
> We could add a policy about the bumping the minor version.
>
> What do you think?

I guess semver doesn’t apply to Guix taken as a whole, so version
numbers should be chosen to suggest how “different” the new release is.
That’s pretty subjective, though.

Ludo’.

bug#39194: help for non-root users to start using

[Ludovic Courtès]

Hi,

Bengt Richter  skribis:

> Did that commit cause an automatic update to the tarball
> found and used by the binary install script [1] ??

No, it didn’t automatically create a new Guix release.

> commit 7842ddcbc118cbc2799e22651732b7cdc06b93ee
> Author: Ludovic Courtès 
> Date:   Sun Jan 19 22:52:31 2020 +0100
>
> guix package: Create profiles/per-user/$USER upfront.
> 
> Fixes .
> Reported by Matt Wette .
> 
> * guix/scripts/package.scm (build-and-use-profile): Move
> 'ensure-default-profile' call to...
> (process-actions): ... here. 
>  --8<---cut here---end--->8---
>
> So for a script user, 2019-05-19 16:54 tarball vs Sun Jan 19 22:52:31 2020 fix
> appears to be a problem :)

The problem Matt reported came up after running ‘guix pull’.  Someone
running ‘guix pull’ today will get the fix above.

HTH!

Ludo’.

bug#39199: Edit in installer doesn't work

[Jonathan Brielmaier]

I built an installation image with the patch and can confirm that the
issue is really fixed. Thank you Ludo!

bug#39217: Installer: Retry system install after editing the config doesn't work

[Jonathan Brielmaier]

Go through the installer and edit the config file. If you make a syntax
error in the config.scm you get to the "Installation failed" window.

But both options "Restart installer" and "Retry system installer" let
the installer begin from the very beginning (locale setup). There is no
way to edit the config.scm again, in order to correct the syntax error.

Tested on current master including the fix for bug#39199.

bug#39217: Installer: Retry system install after editing the config doesn't work

[Jonathan Brielmaier]

I used this image:
https://brielmaier.net/guix-system-install-1.0.1-2.a19fb6a.x86_64-linux.iso

bug#39195: guix pull switching between profiles/per-user and profiles/default

[zimoun]

Hi Ludo,

On Tue, 21 Jan 2020 at 10:04, Ludovic Courtès  wrote:

> > We could add a policy about the bumping the minor version.
> >
> > What do you think?
>
> I guess semver doesn’t apply to Guix taken as a whole, so version
> numbers should be chosen to suggest how “different” the new release is.
> That’s pretty subjective, though.

I move the discussion to guix-devel [1] to keep cleaner the Bug Tracker. ;-)

[1] https://lists.gnu.org/archive/html/guix-devel/2020-01/msg00385.html


Cheers,
simon

bug#39203: GNOME desktop is not displaying battery status

[Ludovic Courtès]

Hi Jesse,

Jesse Gibbons  skribis:

> It looks like the problem was introduced in
> df45af90413906b18710d8c51c44afd5b92d6db6 when upower was updated to
> version 99.11. I also expect it is related to gnome-tweaks, which is
> out of date.
>
> I'm going to see if updating gnome-tweaks fixes it. If so, I'll send an
> update patch. If not, we can determine if it's worth reverting upower.

Fixed in 5dc6d5ce9997e4caf66d154f91c3695e02e5386f!

Below are the notes I took as I was debugging this.

Thanks for your report,
Ludo’.

Actually upowerd fails to start and /var/log/messages here has things
like:

--8<---cut here---start->8---
dbus-daemon[429]: [system] Activating service name='org.freedesktop.UPower' 
requested by ':1.48' (uid=989 pid=822 
comm="/gnu/store/lcn1flxr0z575jmv2m2p6hgzn3caf6x2-gnome-") (using servicehelper)
dbus-daemon[429]: [system] Failed to activate service 'org.freedesktop.UPower': 
timed out (service_start_timeout=25000ms)
--8<---cut here---end--->8---

I attached ‘strace’ to dbus-daemon and then launched ‘upower’ to cause
it to attempt to start upowered.  At some point, the gdbus thread of
upowerd makes a ‘RequestName’ RPC, and the reply of dbus-daemon is:

--8<---cut here---start->8---
429   sendmsg(30, {msg_name=NULL, msg_namelen=0, 
msg_iov=[{iov_base="l\3\1\1\205\0\0\0\t\0\0\0m\0\0\0\6\1s\0\5\0\0\0:1.68\0\0\0\4\1s\0'\0\0\0org.freedesktop.DBus.Error.AccessDenied\0\5\1u\0\f\0\0\0\10\1g\0\1s\0\0\7\1s\0\24\0\0\0org.freedesktop.DBus\0\0\0\0",
 iov_len=128}, {iov_base="\200\0\0\0Connection \":1.68\" is not allowed to own 
the service \"org.freedesktop.UPower\" due to security policies in the 
configuration file\0", iov_len=133}], msg_iovlen=2, msg_controllen=0, 
msg_flags=0}, MSG_NOSIGNAL 
--8<---cut here---end--->8---

Indeed, upower no longer shows up in /etc/dbus-1/system-local.conf.
That’s because the relevant files are now in share/dbus-1 instead of
etc/dbus-1 where our ‘dbus-configuration-directory’ procedure looks for
them.  I traced it back to:

  
https://cgit.freedesktop.org/upower/commit/?id=18457c99b68786cd729b315723d680e6860d9cfa

bug#39203: GNOME desktop is not displaying battery status

[Jesse Gibbons]

On Tue, 2020-01-21 at 09:50 +0100, Robert Smith wrote:
> I'm experiencing the same issue, upower-daemon is simply exiting
> immediately after startup. Can we just revert upower to the previous
> version for the time being? Seems like the 0.99.11 release is broken.
> 
> -Robert
Hi Robert,
Since the upower-daemon is exiting on startup, we should check if it
requires any build step or configuration not needed for 0.99.10. If so,
future releases are likely to require that step as well, so we should
work on fixing that. Meanwhile, I agree that reverting to 0.99.10 is
the next best solution, since this bug is keeping us from having an up-
to-date system with a function as basic as a power indicator.

The 0.99.10 tarball is no longer hosted. :( We will need to change the
source to git. The repository is <
https://gitlab.freedesktop.org/upower/upower>.

My current workaround is to use a channel at commit
a4ac25df71a5b397d0a8e758e53ea3ba8981ecda when I reconfigure my system.
That's the commit before upower was upgraded.

bug#38422: Bug status? '.png' files with executable permissions

[zimoun]

Dear Bengt,

The bug report [1] points out files with unexpected permission; based
on extension filename.

[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38422


It is not an security issue or the Guix packager did not carefully
check the validity of these files.

If you are security paranoid, you *have to* check by yourself all the
files using "guix build -S" because in paranoid mode you cannot trust
Guix packagers (and Guix committers neither).


In normal mode, 2 options:

 a- propose a patch to change the permission for each offending package
 b- report upstream

Well, at least  these 3 packages docbook-xsl, faba-icon-theme, and
moka-icon-theme comes with unexpected .png file permission.


On the long term, I am not convinced that adding automatic check and
permission change based on filename extension would really add Quality
Assurance. Because we are speaking about quality, not security.


I am inclined to close this bug. What do you think?

All the best,
simon

bug#38422:

[zimoun]

tags 38422 notabug
quit

bug#39023: adduser/addgroup vs useradd/groupadd

[zimoun]

Dear,

The bug [1] reports that useradd/groupadd are not provided on BusyBox.
And for example, they had this discussion [2].

[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39023
[2] http://lists.busybox.net/pipermail/busybox/2016-February/083907.html


For example, on Debian, adduser is a Perl script calling useradd under the hood.

And the current Guix manual says:

<<
On a GNU/Linux system, a build user pool may be created like this
(using Bash syntax and the shadow commands):
>>

where the parenthesis should be understood as: "adapt to your distribution".


Two options:

 a/ explicitly notice in the parenthesis that the chunk needs to be
adapted; mentioning adduser/addgroup instead of useradd/groupadd for
example.

 b/ replace useradd/groupadd by adduser/addgroup using the
corresponding options.

The option b/ means that 'adduser/addgroup' is more portable (more
chance to work on everywhere GNU/linux). I am not convinced.

Personally, I am in favor for option a/.


What do the *NIX gurus think?

All the best,
simon

bug#38422: Bug status? '.png' files with executable permissions

[Bengt Richter]

Hi zimoun,

On +2020-01-22 01:22:45 +0100, zimoun wrote:
> Dear Bengt,
> 
> The bug report [1] points out files with unexpected permission; based
> on extension filename.
> 
> [1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38422
> 
> 
> It is not an security issue or the Guix packager did not carefully
> check the validity of these files.
> 
> If you are security paranoid, you *have to* check by yourself all the
> files using "guix build -S" because in paranoid mode you cannot trust
> Guix packagers (and Guix committers neither).
> 
> 
> In normal mode, 2 options:
> 
>  a- propose a patch to change the permission for each offending package
>  b- report upstream
> 
> Well, at least  these 3 packages docbook-xsl, faba-icon-theme, and
> moka-icon-theme comes with unexpected .png file permission.
> 
> 
> On the long term, I am not convinced that adding automatic check and
> permission change based on filename extension would really add Quality
> Assurance. Because we are speaking about quality, not security.
> 
> 
> I am inclined to close this bug. What do you think?
> 
> All the best,
> simon

Ok with me to close, thanks.

-- 
Regards,
Bengt Richter

bug#30756: GCC >= 6 '-isystem' and C_INCLUDE_PATH behavior changed, breaking

[Maxim Cournoyer]

Hello,

Ludovic Courtès  writes:

> Hi,
>
> Maxim Cournoyer  skribis:
>
>> It'd be nice to find a correct solution, but it seems I can't even make
>> the build system of Inkscape work after switching from CPATH to
>> CPLUS_INCLUDE_PATH and stripping it from any glibc/gcc include
>> directories (I don't get the "stdlib.h: No such file or directory."
>> error anymore, but I now get:
>> "/gnu/store/zw5f5g5aqlxam3imaylfla0i98nkridf-glibc-2.30/include/bits/errno.h:26:11:
>> fatal error: linux/errno.h: No such file or directory" instead, which I
>> don't understand).
>>
>> I also tried moving the glibc include directory to the end of
>> CPLUS_INCLUDE_PATH and it would still wouldn't be happy.  Hmmph!
>
> Oh, really?  I think that, as Mark H Weaver mentioned in this thread, if
> we make sure that glibc comes next-to-last (before Linux-libre headers)
> and appears only once in the list, it should work.
>
> Can you confirm?

OK, so the errors I was getting about linux/errno.h missing was caused
by my omission to *also* set C_INCLUDE_PATH to the content of CPATH,
because Inkscape goes on building some bundled libraries which are C and
not C++.

After this was understood, Inkscape now builds successfully by simply
taking out glibc from the inputs.  Keeping GCC headers in seems OK,
although I reckon if we fix this at the core (by extending what can be
done which search path specifications) we should take it out as it could
potentially cause problems:  GCC keeps a reference to its own standard
include directories, as shown by the command 'echo | ~a/bin/c++ -E
-Wp,-v -').  On core-updates, this command, when ran in the following
phase:

--8<---cut here---start->8---
(add-before 'set-paths 'show-g++-internal-paths
  (lambda* (#:key inputs #:allow-other-keys)
(system (format #f "echo | ~a/bin/c++ -E -Wp,-v -" (assoc-ref inputs 
"gcc")))
#t))
--8<---cut here---end--->8---

gives:

--8<---cut here---start->8---
starting phase `show-g++-internal-paths'
ignoring nonexistent directory "/no-gcc-local-prefix/include"
ignoring nonexistent directory 
"/gnu/store/bhn2mqpnxabmllh1kclrmkqp8mhhvjb0-gcc-7.5.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.5.0/../../../../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 
/gnu/store/bhn2mqpnxabmllh1kclrmkqp8mhhvjb0-gcc-7.5.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.5.0/include
 
/gnu/store/bhn2mqpnxabmllh1kclrmkqp8mhhvjb0-gcc-7.5.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.5.0/include-fixed
 /gnu/store/zw5f5g5aqlxam3imaylfla0i98nkridf-glibc-2.30/include
End of search list.
--8<---cut here---end--->8---

which lists references to GCC itself as well as to glibc.

The use of -idirafter is to append a headers directory after
*everything* else, including the compiler's own standard include paths.
I think that to -idirafter glibc shouldn't have any effect, since glibc
headers are already in the standard include path, and IIUC GCC will scan
a header directory only once (the first time it encounters it).  The GCC
manual lists the include directories order as (c.f. the node 'Options
for Directory Search' of the GCC reference manual):

   1. For the quote form of the include directive, the directory of
  the current file is searched first.

   2. For the quote form of the include directive, the directories
  specified by '-iquote' options are searched in left-to-right
  order, as they appear on the command line.

   3. Directories specified with '-I' options are scanned in
  left-to-right order.

   4. Directories specified with '-isystem' options are scanned in
  left-to-right order.

   5. Standard system directories are scanned.

   6. Directories specified with '-idirafter' options are scanned in
  left-to-right order.

It'd be very cool to embed arbitrary logic such as sorting, filtering,
or whatever else we need doing directly in a search path specification
:-).  Do you thing this could be done?  Perhaps Gexps could be useful
for this?

Maxim

bug#39023: binary installation manual doesn't work on Alpine Linux

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Gábor,

Gábor Boskovits 写道：
 ezt írta (időpont: 2020. jan. 7., K, 
22:32):
I suggest adding another example which works by default on 
busybox.


[…]


addgroup -S guixbuild


[…]

I assume that the command you gave would work on non-busybox 
also. I

would say we should replace the
command we have with this more compatible one.


It doesn't even work on Guix:

 nckx@berlin ~$ adduser
 -bash: adduser: command not found

Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#39023: adduser/addgroup vs useradd/groupadd

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Hullo Simon,

zimoun 写道：

options:

 a/ explicitly notice in the parenthesis that the chunk needs to 
 be
adapted; mentioning adduser/addgroup instead of useradd/groupadd 
for

example.


There's also:

 c/ do nothing, or

 d/ include the complete code snippet provided by symphonia, but 
 as an ‘out-of-band’ footnote to avoid confusion/blind 
 copy-pasting/distracting the majority of (GNU) users with 
 irrelevant variants.


With a/, the user won't know which options to change, or how. 
They might not understand our ‘useradd’ syntax, and won't have its 
man page installed.


As implied by my reply to Gábor, b/ isn't an option so I've 
snipped it.


I strongly prefer option d/.


What do the *NIX gurus think?


GNU's not *NIX! :o)  (Nor is it POSIX.)

Kind regards,

T G-R


signature.asc
Description: PGP signature