bug#40549: More usability issues:

[Tom Zander via Bug reports for GNU Guix]

It looks like I was wrong on the ls example,

more importantly, it seems we all agree that short options with optional 
arguments are messy, at best.

I think the best course of action is to take a look at the guix command line 
design and find a way to move away from depending on them. Maybe some iterative 
change its approach.

bug#26046: ESS installed without autoload

[zimoun]

Dear,

Digging in the bug tracker, I found this bug [1] about ESS saying that
it does not behave like all other Emacs packages; installing in
'$out/share/emacs/site-lisp/ess' instead of "guix.d".

Well, all other packages do install in '$out/share/emacs/site-lisp/'
as the manual says [2].  Because the Emacs packages location changes
recently, AFAIU.

Does it make sense to close it now?

Cheers,
simon

[1] http://issues.guix.gnu.org/issue/26046
[2] 
https://guix.gnu.org/manual/en/html_node/Application-Setup.html#Emacs-Packages

bug#25632: shogun: Do not upgrade before adjusting the snippet (nonfree)

[zimoun]

Hi Ricardo,

This bug  [1] is fixed by commit 5a14e81e413.
If it really is, feel free to close.

Cheers,
simon

[1] http://issues.guix.gnu.org/issue/25632

bug#24789: closing #24789

[zimoun]

Dear,

Because this bug is more than 3 years old, tagged moreinfo and without
any answer by the submitter since 12 weeks, I am closing.

Best regards,
simon

bug#41224: Documentation: Inconsistent disk device between create vm (sda) and run vm (vda) causes "guix system reconfigure" failure

[W Knight]

Summary: 
The instructions to build a virtual machine uses /dev/sda* devices for 
harddrive which are then referenced in /etc/config.scm. 
The instructions to run the vm uses /dev/vda* devices for harddrive 
This causes "sudo guix system reconfigure /etc/config.scm" to fail with... 
guix system: error: 
'/gnu/store/q6q99b1r6wxzdxh3a19z2ng88sfpdryn-grub-2.04/sbin/grub-install 
--no-floppy --target=i386-pc --boot-directory //boot /dev/sda' exited with 
status 1; output follows: 
Installing for i386-pc platform. 
/gnu/store/q6q99b1r6wxzdxh3a19z2ng88sfpdryn-grub-2.04/sbin/grub-install: error: 
cannot find a GRUB drive for /dev/sda. Check your device.map. 



Specifics: 


For at least quemu-system-x86_64 version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.23) 




 creates a 
disk layout with /dev/sda 

$ qemu-system-x86_64 -m 1024 -smp 1 -enable-kvm \
-nic user,model=virtio-net-pci -boot menu=on,order=d \
-drive file=guix-system.img \
-drive media=cdrom,file=guix-system-install-1.1.0. system .iso 

while  reflects 
the disk layout as /dev/vda 
$ qemu-system-x86_64 \
 -nic user,model=virtio-net-pci \
 -enable-kvm -m 1024 \
 -device virtio-blk,drive=myhd \
 -drive if=none,file=/tmp/qemu-image,id=myhd 

Recommendation.  Change the install directions to use virtio-blk... 
$ qemu-system-x86_64 -m 1024 -smp 1 -enable-kvm \
-nic user,model=virtio-net-pci -boot menu=on,order=d \ 
-device virtio-blk,drive=myhd \ 
-drive if=none,file=guix-system.img,id=myhd \
-drive media=cdrom,file=guix-system-install-1.1.0. system .iso 

bug#22366: Status? Chicken Scheme release tarballs ship non-source C code

[zimoun]

Dear David,

The bug report [1] opened more than 4 years ago about the Chicken
bootstrapping is still pending.

I am not sure to understand these lines; quoting you [1]:

<<
Generated from optimizer.scm by the CHICKEN compiler

This is *not* source code, it's a binary disguised as C source code.
>>

Why is it an issue for bootstrappability?


Thank you in advance for any comments.
Or could this bug report be closed?

All the best,
simon

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

bug#22158: Hunting: chicken tests do not complete gcc compilation

[zimoun]

Dear,

This bug [1] is more than 4 years old.  Does this bug report still make sense?
If yes, could you provide more information? (Guix commit)
If no, could we close it?

Best regards,
simon

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

bug#41217: Resolution

[W Knight]

After troubleshooting with lfam, rekado, cbaines in #guix the problem was found 
to be caused by lack of ram during "guix pull". 
With 1GB of ram for VM "guix pull" fails at different locations. 
With 2GB of ram "guix pull" finishes. Low point of available system memory (per 
'free -s') during pull was ~320MB with ~910MB being common. 

bug#41217: Resolution

[W Knight]

After troubleshooting with lfam, rekado, cbaines in #guix the problem was found 
to be caused by lack of ram during "guix pull". 
With 1GB of ram for VM "guix pull" fails at different locations. 
With 2GB of ram "guix pull" finishes. Low point of available system memory (per 
'free -s') during pull was ~320MB with ~910MB being common. 

bug#40929: go-sctp build failure: "protocol not supported"

[zimoun]

Dear Josh,

On Tue, 5 May 2020 at 16:20, Josh Holland  wrote:

> Ah, that's good.  I'll just wait for the (hopefully soon) core-updates
> merge since this isn't essential to me.  If it is fixed, then presumably
> this bug can be closed?

Could you confirm that the bug is now fixed for you?
If yes, just reply to 40929-d...@debbugs.gnu.org

Thank you in advance.

All the best,
simon

bug#40549: More usability issues:

[zimoun]

On Tue, 12 May 2020 at 22:19, Tom Zander  wrote:

> They are expected to always be equivalent. It would not be logical to have the
> short one as an alias if they are not equivalent.

I agree.
Note that you cannot have short-name with optional argument or you
have to break a rule; see below.


> > > You asked for an example;  see `git commit -S`. From the manpage:
> > >-S[], --gpg-sign[=]
> >
> > Thank you for the example.   Let me show you that it raises an issue
> > too because it is not so "simple". :-)
>
> Easier example then: from the 'ls(1)' manpage:
>   -I, --ignore=PATTERN

No. `ls -I -l` is not doing the right behaviour, i.e., the flag '-l'
is not applied.
PATTERN is not optional.


> seems git is trying to be smart.

Git resolves the ambiguity by removing the form '-S keyid'.
Other said,
(1) '-Skeyid' uses keyid as argument
(2) '-S keyid' fails as I showed you.
(3) '-S' fallbacks to the default (see .gitconfig)

Back to Guix, using the same strategy means:

(1)  guix package -d8 -p /path/to/profile
(2)  guix package -d 8 -p /path/to/profile # fails
(3)  guix pacakge -d -p /path/to/profile # delete all the generations
except the current one

The three cases cannot all works.  You have to choose two cases.
Currently Guix uses (1) and (2); and (3) fails.   Git uses (1) and
(3); and (2) fails.

You have right by remarking that the "git-way" seems more consistent
when flipping the options.  However they are less consistent in regard
with option requiring one argument.

 git commit -S4417B7 -m 'init'

I do not have a strong opinion on the topic.  Even if I am often
annoyed by "guix package -I -p /path/to/profile".


> The point is not to reinvent the wheel that have been invented so many
> times... A command line parser is a known thing that you can, and should,
> mirror how others do things.

Are you aware of the wheel? :-)

https://srfi.schemers.org/srfi-37/srfi-37.html
https://www.gnu.org/software/libc/manual/html_node/Argument-Syntax.html
https://pubs.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap12.html#tag_12_02


> Even 'ls' uses optional short arguments (--ignore). So I'm not sure I agree
> with your line of reasoning.

No, the argument of '--ignore' is not optional.  At least with the GNU
version from coreutils 8.30.
Note the options with optional argument (--color and --hyperlink) do
not have a short-name form.


> Doing;
>   ls -I -v
> clearly understands that '-v' is not to be used as an optional argument.
> The reason, as far as I can tell, is that it does not fit as another argument.

You have wrong.  Compare

   ls -I -l
   ls -l -I
   ls -I '' -l


Because Guix uses SRFI-37 to parse command-line arguments and this
will not change, IMHO, the question asked on guile-devel is the one
explained above about the 3 cases.

All the best,
simon

bug#41211: texlive-luatex-luaotfload fails to build

[Marius Bakke]

merge 39755 41211
thanks

Thanks for the report.  I tried updating texlive-lualatex-otfload a
while back, but gave up because the new versions needs "l3build" which I
have zero experience with.  Any pointers for packaging and using l3build
appreciated.

For reference, as the original home page has been archived, here is the
updated repository with support for Tex Live 2019 and later:

  https://github.com/latex3/luaotfload

bug#40549: More usability issues:

[Tom Zander via Bug reports for GNU Guix]

On dinsdag 12 mei 2020 20:08:32 CEST zimoun wrote:
> > The design of the short options is that it is an alias. Identical to the
> > software regardless of what the user typed.
> 
> Yes.  But AFAIU, it is hard -- not impossible -- to detect what is an
> argument or what is another option in the case of optional argument in
> the short-name form.  Because it leads to ambiguous parsing.

The solution here is to be consistent with the way that others do this.
For those cases that you highlight the consistent solution elsewhere is 
something you can apply here too. This follows the rule of the least surprise.
 
> And try "cut -f -d' '", it raises the error "cut: invalid field value ‘d ’".

that is because -f has a required argument. As such I agree with your example, 
but ignore it because it is not relevant to our discussion. It is not an 
optional short option.
 
> All short-name and long-name are ``equivalent`` when they do not
> require any argument -- for example with cut: -s, --only-delimited --
> *_or_* they require one argument -- for example: -f, --fields=LIST.

They are expected to always be equivalent. It would not be logical to have the 
short one as an alias if they are not equivalent.

> But there is an ambiguity for optional argument.  How do you detect if
> the argument is provided or not?
> With the long-name, it is done with the character '='.
> For short-name, it is ambiguous.  Imagine that "guix package" has in

The point here is that there exist rules that others use, to remove this 
ambiguity. I'm trying to explain them to you to allow guix to behave the same.
I agree its tricky, the good thing is that it has been solved before.

For instance you can provide an argument to short options without spaces too:
You can write `cut -f1 -d:`.

> addition to '-S' the option '-2' meaning verbosity to level 2
> (--verbosity=2).  Then what is the meaning of:
> 
>   guix package -S -2

If the user meant the "-2" argument to be an argument to the -S option, they 
would have to write (again, following the rules used by most software) as:

echo "test" > -bla
ls -I \-bla

or, to comment on your specific example. In git you don't use the dash to have 
a negative, they use a different char. The tilde. Or dotdotdot. (think: range)
   git show HEAD~
git diff  ...master

> Is it equivalent to
>   + --switch-generation=-2
> or
>   + --switch-generation --verbose=2

In most software you would interpret any argument that starts with a dash as 
an option. For consistency sake you would thus interpret your example as the 
latter option.
The user can specify what they mean, but preferably you pick your syntax 
better to avoid the -2 in the example you gave :)


> > You asked for an example;  see `git commit -S`. From the manpage:
> >-S[], --gpg-sign[=]
> 
> Thank you for the example.   Let me show you that it raises an issue
> too because it is not so "simple". :-)

Easier example then: from the 'ls(1)' manpage:
  -I, --ignore=PATTERN

seems git is trying to be smart.

 
> > It looks like the parser could be improved by preferring to see any
> > argument with leading dash as a option when it **might** be an argument.
> 
> It does not work for the general case as you describe.  It is not so simple.
> :-) Because '-d -1' means '--delete-generation=-1' and not
> '--delete-generation -1'.

The point is consistency.
The point is not to reinvent the wheel that have been invented so many 
times... A command line parser is a known thing that you can, and should, 
mirror how others do things.

So, sure, "-d -1" does not give you what you want. BUT it is consistent with
--delete -1.
This is the point the exercise. The basic premise is that the short version is 
an alias for the long version.
Yes, you have to be aware of how to format things, how the rules apply. But 
this is the entire point: people should be able to learn it once. And not 
again for guix because we thought something else worked better...


> From my knowledge, all that is solved by the rule: no short option
> with optional argument.

Sure, you can do that.
You'll probably annoy of a lot of people if you remove the thing they 
use a lot :)

Even 'ls' uses optional short arguments (--ignore). So I'm not sure I agree 
with your line of reasoning.


> > So; if you type -`guix package -l --help` then your parser **first** finds
> > all the items with leading dashes and second it tries to find out if
> > there is an argument for the `-l`.
> > In this case I expect the help to be shown.
> > 
> > This is widely seen as a solution.
> > Users can still use items with leading dashes by using two commonly used
> > tricks.
> > The -l=a type of construction allows the argument to be anything.
> > Including it having a leading dash.
> > 
> > Second is the double-dash argument that stops words leading with dashes
> > being parsed as options.
> > 
> >   For instance;   grep -- -v *
> > 
> > the  -v is parsed as an actual string and not an option because it follows
> >

bug#41217: guix pull: error: You found a bug: the program '/gnu/store/h1b3kqafcgwv5zdj98f9ka3nppkz4l09-compute-guix-derivation'

[W Knight]

Disclaimer: User error highly likely. Only second day playing around with guix 


Action attempted: 


guix pull # As testuser account per < 
https://guix.gnu.org/manual/en/guix.html#After-System-Installation> 



Error Message: 


guix pull: error: You found a bug: the program 
'/gnu/store/h1b3kqafcgwv5zdj98f9ka3nppkz4l09-compute-guix-derivation' 
failed to compute the derivation for Guix (version: 
"75741af9b2996217732c9fe82d408a4927d5e321"; system: "x86_64-linux"; 
host version: "1.1.0"; pull-version: 1). 


Error Detail: 



testuser@guixFirst ~$ guix pull 
... 
downloading from 
https://ci.guix.gnu.org/nar/lzip/sc7z07gim1iq5zvfz1amdwf2irxrzifg-guile-2.2.6...
 
guile-2.2.6 5.5MiB 2.7MiB/s 00:02 [##] 100.0% 

downloading from 
https://ci.guix.gnu.org/nar/gzip/h1b3kqafcgwv5zdj98f9ka3nppkz4l09-compute-guix-derivation...
 
compute-guix-derivation 859B 148KiB/s 00:00 [##] 100.0% 

substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% 
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% 
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% 
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% 
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% 
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% 
/@ substituter-started 
/gnu/store/z7a6sbvqzb5zapwpznmjkq2rsxil6i67-glibc-utf8-locales-2.31 substitute 
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% 
guix pull: error: You found a bug: the program 
'/gnu/store/h1b3kqafcgwv5zdj98f9ka3nppkz4l09-compute-guix-derivation' 
failed to compute the derivation for Guix (version: 
"75741af9b2996217732c9fe82d408a4927d5e321"; system: "x86_64-linux"; 
host version: "1.1.0"; pull-version: 1). 
Please report it by email to . 




System Configuration: 


testuser@guixFirst ~$ guix system describe 
Generation 1 May 11 2020 17:10:26 (current) 
file name: /var/guix/profiles/system-1-link 
canonical file name: /gnu/store/ymbmfzp1jfa966zp7jixmmsdxamgg9mn-system 
label: GNU with Linux-Libre 5.4.31 
bootloader: grub 
root device: UUID: dcb203af-8c28-473b-b101-8553950c56fe 
kernel: /gnu/store/g56i8savnfr7981fil03idkjl0syj29d-linux-libre-5.4.31/bzImage 
configuration file: 
/gnu/store/1hv6mkhh7ziphhyn7axpd0c6p4i4hz14-configuration.scm 

testuser@guixFirst ~$ cat 
/gnu/store/1hv6mkhh7ziphhyn7axpd0c6p4i4hz14-configuration.scm 
;; This is an operating system configuration generated 
;; by the graphical installer. 

(use-modules (gnu)) 
(use-service-modules desktop networking ssh xorg) 

(operating-system 
(locale "en_US.utf8") 
(timezone "America/Chicago") 
(keyboard-layout (keyboard-layout "us")) 
(host-name "guixFirst") 
(users (cons* (user-account 
(name "testuser") 
(comment "Testuser") 
(group "users") 
(home-directory "/home/testuser") 
(supplementary-groups 
'("wheel" "netdev" "audio" "video"))) 
%base-user-accounts)) 
(packages 
(append 
(list (specification->package "nss-certs")) 
%base-packages)) 
(services 
(append 
(list (service xfce-desktop-service-type) 
(service openssh-service-type) 
(set-xorg-configuration 
(xorg-configuration 
(keyboard-layout keyboard-layout 
%desktop-services)) 
(bootloader 
(bootloader-configuration 
(bootloader grub-bootloader) 
(target "/dev/sda") 
(keyboard-layout keyboard-layout))) 
(swap-devices (list "/dev/sda2")) 
(file-systems 
(cons* (file-system 
(mount-point "/") 
(device 
(uuid "dcb203af-8c28-473b-b101-8553950c56fe" 
'ext4)) 
(type "ext4")) 
%base-file-systems))) 




Created on 20200512 (yesterday) with: 


# Download the installation image 
cd /data/isos 
mkdir guix 
cd guix 
wget https://ftp.gnu.org/gnu/guix/guix-system-install-1.1.0.x86_64-linux.iso.xz 
wget 
https://ftp.gnu.org/gnu/guix/guix-system-install-1.1.0.x86_64-linux.iso.xz.sig 
gpg --verify guix-system-install-1.1.0.x86_64-linux.iso.xz.sig 
xz --decompress guix-system-install-1.1.0.x86_64-linux.iso.xz 


# Create vm 
cd /data//vms 
mkdir guixFirst 
cd guixFirst 
qemu-img create -f qcow2 guix-system.img 50G 
qemu-system-x86_64 -m 1024 -smp 1 -enable-kvm \ 
-net nic,model=virtio -net user -boot menu=on,order=d \ 
-drive file=guix-system.img \ 
-drive 
media=cdrom,file=/data/isos/guix/guix-system-install-1.1.0.x86_64-linux.iso 

# Run the vm 
qemu-system-x86_64 \ 
-net nic,model=virtio -net user \ 
-enable-kvm -m 1024 \ 
-device virtio-blk,drive=myhd \ 
-drive if=none,file=guix-system.img,id=myhd 


Qemu version: 



qemu-system-x86_64 --version 
QEMU emulator version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.23) 
Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers 


Please let me know if you want any additional details, 

Cheers, 
Warren 

bug#41215: memory leak in gnome-shell

[Arne Babenhauserheide]

I see a memory leak in Gnome Shell 3.32.2

The following is top output after several days of uptime:

  PID USER  PR  NIVIRTRES  %CPU  %MEM ZEIT+ S BEFEHL
   
  864 gdm   20   0   39,6g   1,1g   0,0   3,5  85:04.12 S  
/gnu/store/3r8h4lygzs06jyx89ffi1y2bbda9s76y-gnome-shell-3.32.2/bin/.gnome-shell-real

RES 1.1g is a bit much.

I tried to capture a coredump with gcore -o /tmp/gnome-shell 864, but
that increased the memory usage to 8g RES before I killed gcore.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken

bug#41214: Pulling 1.0.0 fails while running ‘compute-guix-derivation’

[Ludovic Courtès]

>From today’s Guix, where (default-guile) is 3.0, I can’t build 1.0.0:

--8<---cut here---start->8---
$ guix describe
Generacio 142   May 11 2020 00:51:39(nuna)
  guix b76b1d3
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: b76b1d3fb65fec98b96a2b4cfa984316dd956a29
$ guix time-machine --commit=6298c3ffd9654d3231a6f25390b056483e8f407c -- 
describe
Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
;;; WARNING: loading compiled file 
/gnu/store/g29fabc57fkzimrf6gsb72fr7fq069yf-module-import-compiled/guix/store.go
 failed:
;;; In procedure load-thunk-from-memory: incompatible bytecode kind
;;; WARNING: loading compiled file 
/gnu/store/g29fabc57fkzimrf6gsb72fr7fq069yf-module-import-compiled/guix/store.go
 failed:
;;; In procedure load-thunk-from-memory: incompatible bytecode kind
;;; WARNING: loading compiled file 
/gnu/store/g29fabc57fkzimrf6gsb72fr7fq069yf-module-import-compiled/guix/utils.go
 failed:
;;; In procedure load-thunk-from-memory: incompatible bytecode kind
;;; WARNING: loading compiled file 
/gnu/store/g29fabc57fkzimrf6gsb72fr7fq069yf-module-import-compiled/guix/utils.go
 failed:
;;; In procedure load-thunk-from-memory: incompatible bytecode kind
;;; WARNING: loading compiled file 
/gnu/store/g29fabc57fkzimrf6gsb72fr7fq069yf-module-import-compiled/guix/config.go
 failed:
;;; In procedure load-thunk-from-memory: incompatible bytecode kind
;;; WARNING: loading compiled file 
/gnu/store/g29fabc57fkzimrf6gsb72fr7fq069yf-module-import-compiled/guix/config.go
 failed:
;;; In procedure load-thunk-from-memory: incompatible bytecode kind
[…]
In unknown file:
   5 (primitive-load-path "guix/build/compile" #)
In ice-9/eval.scm:
   626:19  4 (_ #)
159:9  3 (_ #)
   182:19  2 (proc #)
   142:16  1 (compile-top-call # ?)
In unknown file:
   0 (%resolve-variable (7 . #) #)

ERROR: In procedure %resolve-variable:
Unbound variable: tree-il-default-optimization-options
guix time-machine: error: You found a bug: the program 
'/gnu/store/9c0s7llsc1sqw6hkz99vhyr8wmipc1zl-compute-guix-derivation'
failed to compute the derivation for Guix (version: 
"6298c3ffd9654d3231a6f25390b056483e8f407c"; system: "x86_64-linux";
host version: "b76b1d3fb65fec98b96a2b4cfa984316dd956a29"; pull-version: 1).
Please report it by email to .
--8<---cut here---end--->8---

The module in
/gnu/store/g29fabc57fkzimrf6gsb72fr7fq069yf-module-import-compiled were
built with 2.2.4, which is fine, but ‘compute-guix-derivation’ itself
runs on 3.0.

Probably ‘%quirks’ should also change (default-guile).

Ludo’.

bug#34135: IceCat lacks WebGL support

[Jonathan Brielmaier]

429c8284d232c3f9fbe3dc87a3da323f3a864c03 did preliminary work for ffmpeg
white listing. So we need to add the WebGL required stuff as well to
that whitelist. I'll see what I can do.

bug#41212: fail to build python-parso

[zimoun]

Dear,

I am not able to reproduce.

--8<---cut here---start->8---
# first to populate the store
guix time-machine --commit=91be384 \
 -- build python-parso

# second to really build it
guix time-machine --commit=91be384 \
 -- build python-parso --no-grafts --check
--8<---cut here---end--->8---

And I do not have any error.  The substitute is available and the
rebuild is fine.

Could you provide the command-line that you used?


All the best,
simon

bug#40549: More usability issues:

[zimoun]

Dear Tom,

On Tue, 12 May 2020 at 18:23, Tom Zander  wrote:

> The other is the ordering of arguments being parsed unpredictable.
> The usecase given was the `-d 1 -S 2`  arguments  (see earlier emails for
> details).

Fix for that coming soon. :-)
Thank you for the report.


> > Please could you indicate me command-line tools where short-option
> > with optional-argument is possible.
> > Because if there is one, I could have inspiration to know how it
> > resolves the ambiguity.
>
> The design of the short options is that it is an alias. Identical to the
> software regardless of what the user typed.

Yes.  But AFAIU, it is hard -- not impossible -- to detect what is an
argument or what is another option in the case of optional argument in
the short-name form.  Because it leads to ambiguous parsing.


> So you get 'cut --field 1' or 'cut -f1' or 'cut -f 1' or 'cut -f=1'.
> All identical.
> The important part here is that each _option_ is written separately, with a
> leading dash.

And try "cut -f -d' '", it raises the error "cut: invalid field value ‘d ’".

All short-name and long-name are ``equivalent`` when they do not
require any argument -- for example with cut: -s, --only-delimited --
*_or_* they require one argument -- for example: -f, --fields=LIST.

But there is an ambiguity for optional argument.  How do you detect if
the argument is provided or not?
With the long-name, it is done with the character '='.
For short-name, it is ambiguous.  Imagine that "guix package" has in
addition to '-S' the option '-2' meaning verbosity to level 2
(--verbosity=2).  Then what is the meaning of:

  guix package -S -2

?

Is it equivalent to
  + --switch-generation=-2
or
  + --switch-generation --verbose=2
?


> You asked for an example;  see `git commit -S`. From the manpage:
>
>-S[], --gpg-sign[=]

Thank you for the example.   Let me show you that it raises an issue
too because it is not so "simple". :-)

--8<---cut here---start->8---
mv ~/.gnupg ~/.gnupg.bak
gpg --gen-key
gpg --list-keys

mkdir -p /tmp/foo
touch /tmp/foo/bar
git -C /tmp/foo init
git -C /tmp/foo/ add  bar

git commit -S -m 'init'
error: gpg failed to sign the data
fatal: failed to write commit object

git -C /tmp/foo commit -S 4417B7AADBEFFBEBE4C201271A6DD2B6218BF4B3 -m 'init'
error: pathspec '4417B7AADBEFFBEBE4C201271A6DD2B6218BF4B3' did not
match any file(s) known to git

git -C /tmp/foo commit
--gpg-sig=4417B7AADBEFFBEBE4C201271A6DD2B6218BF4B3 -m 'init'
[master (root-commit) f4df0ff] init
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 bar

git config --global user.signingkey 4417B7AADBEFFBEBE4C201271A6DD2B6218BF4B3

echo ok > /tmp/foo/bar

git -C /tmp/foo commit -S -am 'bis'
[master 639c41e] bis
 1 file changed, 1 insertion(+)
--8<---cut here---end--->8---

Maybe Git manual is lying. ;-)


> > The issue is that Guix uses a bad practise: option with optional-argument
> >  with both short and long name.  It is a mistake to provide the short-name
> >  for such case.
>
> It looks like the parser could be improved by preferring to see any argument
> with leading dash as a option when it **might** be an argument.

It does not work for the general case as you describe.  It is not so simple. :-)
Because '-d -1' means '--delete-generation=-1' and not '--delete-generation -1'.

So considering the situation '-d -X', the parser needs to guess if
'-X' is the argument of the option '-d' or if it is another option.
Yes, it is possible but it is not so easy -- nor impossible -- because
what does it means '-S -2d'?
   + --switch-generation=-2d
or
  + --switch-generation --verbosity=2 --delete-generation

>From my knowledge, all that is solved by the rule: no short option
with optional argument.


> So; if you type -`guix package -l --help` then your parser **first** finds all
> the items with leading dashes and second it tries to find out if there is an
> argument for the `-l`.
> In this case I expect the help to be shown.
>
> This is widely seen as a solution.
> Users can still use items with leading dashes by using two commonly used
> tricks.
> The -l=a type of construction allows the argument to be anything. Including it
> having a leading dash.
>
> Second is the double-dash argument that stops words leading with dashes being
> parsed as options.
>   For instance;   grep -- -v *
> the  -v is parsed as an actual string and not an option because it follows the
> double dashes.

You miss the point, I believe.
The issue of *any* parser is only for the "flag" with optional
argument in their short-name form.
Because, as I explained above, the syntax for such cases is ambiguous.

Otherwise, the parser really behaves as you expect!


> > Now all this is clearer for me and I do not think it is a fixable bug.
>
> It is, just follow the suggestion from me and from zimoun: any command-line-
> argument that starts with a dash should be preferred to be an option. Only in
> a

bug#40549: proposal for 'process-actions'

[Tom Zander via Bug reports for GNU Guix]

On dinsdag 12 mei 2020 15:03:14 CEST zimoun wrote:
> If yes, I can come up with a patch.

I think that would be much improved, yes.

-- 
Tom Zander

bug#40549: More usability issues:

[Tom Zander via Bug reports for GNU Guix]

On dinsdag 12 mei 2020 13:35:04 CEST zimoun wrote:
> On Tue, 12 May 2020 at 11:55, Tom Zander via Bug reports for GNU Guix
> 
>  wrote:
> > the bugreport is a usability bug which stems from the fact that the
> > command
> > line parser behaves differently from every single other commandline parser
> > average people like me have ever used.
> > 
> > A near 100% of the command line tools on your Gnu/Linux box will behave
> > differently than guix does now.
> > 
> > C apps using libc, python apps using their parser, even C++ apps using the
> > Qt commandline classes, all are generally compatible with regards to
> > behavior.
> > 
> > Only Guix is different.
> 
> Could you provide concrete examples?  Other than "guix package"?
> And other than short-option with optional argument?

This report lists two items.

Indeed the short options are a good one. It is unheard of to have an alias not 
be an alias but behave differently.
It also can't be said to be documented as the --help output does not actually 
state this. I only learned this difference today :-)

The other is the ordering of arguments being parsed unpredictable.
The usecase given was the `-d 1 -S 2`  arguments  (see earlier emails for 
details).


> Please could you indicate me command-line tools where short-option
> with optional-argument is possible.
> Because if there is one, I could have inspiration to know how it
> resolves the ambiguity.

The design of the short options is that it is an alias. Identical to the 
software regardless of what the user typed.

So you get 'cut --field 1' or 'cut -f1' or 'cut -f 1' or 'cut -f=1'.
All identical.
The important part here is that each _option_ is written separately, with a 
leading dash.

When you talk about flags you can group them. `mv -vufi` is again identical to
`mv -v -u -f -i`.  But this is irrelevant to your question because, as stated, 
this is about _flags_, not option.

You asked for an example;  see `git commit -S`. From the manpage:

   -S[], --gpg-sign[=]


> The issue is that Guix uses a bad practise: option with optional-argument
>  with both short and long name.  It is a mistake to provide the short-name
>  for such case.

It looks like the parser could be improved by preferring to see any argument 
with leading dash as a option when it **might** be an argument.

So; if you type -`guix package -l --help` then your parser **first** finds all 
the items with leading dashes and second it tries to find out if there is an 
argument for the `-l`.
In this case I expect the help to be shown.


This is widely seen as a solution.
Users can still use items with leading dashes by using two commonly used 
tricks.
The -l=a type of construction allows the argument to be anything. Including it 
having a leading dash.

Second is the double-dash argument that stops words leading with dashes being 
parsed as options.
  For instance;   grep -- -v *
the  -v is parsed as an actual string and not an option because it follows the 
double dashes.

> Now all this is clearer for me and I do not think it is a fixable bug.

It is, just follow the suggestion from me and from zimoun: any command-line-
argument that starts with a dash should be preferred to be an option. Only in 
a second phase do you try to match anything to (optional) options.

As stated, the rest of the world does this, please check out the various 
examples I gave here to confirm that others have solved it and it may be 
possible to solve it for guix too.
-- 
Tom Zander

bug#41213: boost-for-mysql fails to build

[Jonathan Brielmaier]

boost-for-mysql fails to build on current master with following error.

```
starting phase `configure'
Backtrace:
  10 (primitive-load "/gnu/store/bsfksp6c63zj3ynx46ck87sip7a…")
In ice-9/eval.scm:
   191:35  9 (_ _)
In guix/build/gnu-build-system.scm:
838:2  8 (gnu-build #:source _ #:outputs _ #:inputs _ #:phases . #)
In ice-9/boot-9.scm:
  1736:10  7 (with-exception-handler _ _ #:unwind? _ # _)
In srfi/srfi-1.scm:
   857:16  6 (every1 # …)
In guix/build/gnu-build-system.scm:
   847:30  5 (_ _)
In ice-9/eval.scm:
619:8  4 (_ #(#(#(#) # #) …))
In srfi/srfi-1.scm:
634:9  3 (for-each # _)
In guix/build/utils.scm:
   736:30  2 (with-atomic-file-replacement "tools/build/src/engine/…" …)
In unknown file:
   1 (stat "tools/build/src/engine/execunix.cpp" #)
In ice-9/boot-9.scm:
  1669:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1669:16: In procedure raise-exception:
In procedure stat: No such file or directory:
"tools/build/src/engine/execunix.cpp"
builder for
`/gnu/store/sk133zc1fbs5352a3k9lzmfg2930rjjx-boost-1.59.0.drv' failed
with exit code 1
build of /gnu/store/sk133zc1fbs5352a3k9lzmfg2930rjjx-boost-1.59.0.drv failed
View build log at
'/var/log/guix/drvs/sk/133zc1fbs5352a3k9lzmfg2930rjjx-boost-1.59.0.drv.bz2'.
cannot build derivation
`/gnu/store/bjn6im95g4669731sfzd8vlyj5742ir3-mysql-5.7.27.drv': 1
dependencies couldn't be built
guix build: error: build of
`/gnu/store/bjn6im95g4669731sfzd8vlyj5742ir3-mysql-5.7.27.drv' failed
```

"tools/build/src/engine/execunix.cpp" is required for boost@1.72 in the
configure phase. boost-for-mysql inherits from.

I don't know how to properly fix that...

bug#39955: wxmaxima: broken help menus

[Christopher Howard]

Hi, after a few months, I still have this problem, though the symptoms
changed somewhat. Now, if I click on either the Help >> wxMaxima help
menu, or the Help >> Maxima help menu, wxMaxima simply terminates, and
the word "Aborted" is dumped to stderr.

-- 
Christopher Howard
Enterprise Solutions Manager
Alaska Satellite Internet
PO Box 70, Ester, AK 99725
3239 La Ree Way, Fairbanks, AK 99709
907.451.0088
1.888.396.5623
www.alaskasatelliteinternet.com

bug#41212: fail to build python-parso

[srandom]

my guix describe:


Generation 3May 12 2020 09:03:13(current)
  guix 91be384
repository URL: /opt/guix
branch: master
commit: 91be384d2ef87af58f814e10a4ce0d8717bea647


(I store the git repository in /opt/guix and pull the source code of upstream 
https://github.com/guix-mirror/guix)


build log:


=== FAILURES ===
___ test_python_exception_matches[(lambda: x := 1)] 


code = '(lambda: x := 1)'


@pytest.mark.parametrize('code', FAILING_EXAMPLES)
def test_python_exception_matches(code):
wanted, line_nr = _get_actual_exception(code)


errors = _get_error_list(code)
wanted, line_nr = _get_actual_exception(code)   

[50/1848]


errors = _get_error_list(code)
actual = None
if errors:
error, = errors
actual = error.message
>   assert actual in wanted
E   AssertionError: assert 'SyntaxError: cannot use named assignment with 
subscript' in ['SyntaxError: cannot use assignment expressions with subscript']


test/test_python_errors.py:39: AssertionError
__ test_python_exception_matches[(a(i) := x)] __


code = '(a(i) := x)'


@pytest.mark.parametrize('code', FAILING_EXAMPLES)
def test_python_exception_matches(code):
wanted, line_nr = _get_actual_exception(code)


errors = _get_error_list(code)
actual = None
if errors:
error, = errors
actual = error.message
>   assert actual in wanted
E   AssertionError: assert 'SyntaxError: cannot use named assignment with 
function call' in ['SyntaxError: cannot use assignment expressions with 
function call']


test/test_python_errors.py:39: AssertionError
__ test_python_exception_matches[(a.b := c)] ___


code = '(a.b := c)'


@pytest.mark.parametrize('code', FAILING_EXAMPLES)
def test_python_exception_matches(code):
wanted, line_nr = _get_actual_exception(code)


errors = _get_error_list(code)
actual = None
if errors:
error, = errors
actual = error.message
>   assert actual in wanted
E   AssertionError: assert 'SyntaxError: cannot use named assignment with 
attribute' in ['SyntaxError: cannot use assignment expressions with attribute']


test/test_python_errors.py:39: AssertionError
_ test_python_exception_matches[[(i.i:= 0) for ((i), j) in range(5)]] __


code = '[(i.i:= 0) for ((i), j) in range(5)]'


@pytest.mark.parametrize('code', FAILING_EXAMPLES)
def test_python_exception_matches(code):
wanted, line_nr = _get_actual_exception(code)
def test_python_exception_matches(code):

 [0/1848]
wanted, line_nr = _get_actual_exception(code)


errors = _get_error_list(code)
actual = None
if errors:
error, = errors
actual = error.message
>   assert actual in wanted
E   AssertionError: assert 'SyntaxError: cannot use named assignment with 
attribute' in ['SyntaxError: cannot use assignment expressions with attribute']


test/test_python_errors.py:39: AssertionError
 test_python_exception_matches[(await a := x)] _


code = '(await a := x)'


@pytest.mark.parametrize('code', FAILING_EXAMPLES)
def test_python_exception_matches(code):
wanted, line_nr = _get_actual_exception(code)


errors = _get_error_list(code)
actual = None
if errors:
error, = errors
actual = error.message
>   assert actual in wanted
E   AssertionError: assert 'SyntaxError: cannot use named assignment with 
await expression' in ['SyntaxError: cannot use assignment expressions with 
await expression
']


test/test_python_errors.py:39: AssertionError
___ test_python_exception_matches[((await a) := x)] 


code = '((await a) := x)'


@pytest.mark.parametrize('code', FAILING_EXAMPLES)
def test_python_exception_matches(code):
wanted, line_nr = _get_actual_exception(code)


errors = _get_error_list(code)
actual = None
if errors:
error, = errors
actual = error.message
>   assert actual in wanted
E   AssertionError: assert 'SyntaxError: cannot use named assignment with 
await expression' in ['SyntaxError: cannot use assignment expressions with 
await expression
']


test/test_python_errors.py:39: AssertionError
== 9 failed, 1181 passed, 1 xfailed in 17.76s ==
command "pytest" "-vv" failed with status 1






How should I solve it?

bug#41211: texlive-luatex-luaotfload fails to build

[Ricardo Wurmus]

--8<---cut here---start->8---
starting phase `configure'
Backtrace:
  19 (primitive-load "/gnu/store/4f9lljysahpgjjlzw02dvnhajnk…")
In ice-9/eval.scm:
   191:35 18 (_ _)
In guix/build/gnu-build-system.scm:
838:2 17 (gnu-build #:source _ #:outputs _ #:inputs _ #:phases . #)
In ice-9/boot-9.scm:
  1736:10 16 (with-exception-handler _ _ #:unwind? _ # _)
In srfi/srfi-1.scm:
   857:16 15 (every1 # …)
In guix/build/gnu-build-system.scm:
   847:30 14 (_ _)
In ice-9/eval.scm:
619:8 13 (_ #(#(#) (# # …)))
In ice-9/boot-9.scm:
  1736:10 12 (with-exception-handler _ _ #:unwind? _ # _)
In ice-9/ports.scm:
   445:17 11 (call-with-input-file _ _ #:binary _ #:encoding _ # _)
In guix/build/utils.scm:
   741:26 10 (_ _)
   767:26  9 (_ # #)
In srfi/srfi-1.scm:
   460:18  8 (fold # …)
In ice-9/eval.scm:
   202:51  7 (_ #(#(#(#(#(#(# …)) …) …) …) …))
163:9  6 (_ #(#(#(#(#(#(# …)) …) …) …) …))
163:9  5 (_ #(#(#(#(#(#(# …)) …) …) …) …))
155:9  4 (_ #(#(#(#(#(#(# …)) …) …) …) …))
In ice-9/boot-9.scm:
   222:17  3 (map1 ((committer . "Philipp Gesang 8---

-- 
Ricardo

bug#41210: gcc-cross-sans-libc-arm-none-eabi-4.9.4-1.227977 fails to build

[Ricardo Wurmus]

gcc-cross-sans-libc-arm-none-eabi-4.9.4-1.227977 (an input to
axoloti-patcher) fails to build.

Just like with issue #41209 the headers for both GCC 5 and 7 are
included.

--8<---cut here---start->8---
…
make[2]: Leaving directory 
'/tmp/guix-build-avr-gcc-5.5.0.drv-0/build/fixincludes'
g++  -I../../gcc-5.5.0/libcpp -I. -I../../gcc-5.5.0/libcpp/../include 
-I../../gcc-5.5.0/libcpp/include  -g -O2 -W -Wall -Wno-narrowing 
-Wwrite-strings -Wmissing-format-attribute -pedantic -Wno-long-long  
-fno-exceptions -fno-rtti -I../../gcc-5.5.0/libcpp -I. 
-I../../gcc-5.5.0/libcpp/../include -I../../gcc-5.5.0/libcpp/include   -c -o 
directives.o -MT directives.o -MMD -MP -MF .deps/directives.Tpo 
../../gcc-5.5.0/libcpp/directives.c
../../gcc-5.5.0/libcpp/charset.c: In function ‘bool 
cpp_interpret_string(cpp_reader*, const cpp_string*, size_t, cpp_string*, 
cpp_ttype)’:
../../gcc-5.5.0/libcpp/charset.c:1453:18: error: ‘free’ was not declared in 
this scope
   free (tbuf.text);
  ^
../../gcc-5.5.0/libcpp/charset.c: In function ‘cppchar_t 
cpp_interpret_charconst(cpp_reader*, const cpp_token*, unsigned int*, int*)’:
../../gcc-5.5.0/libcpp/charset.c:1633:27: error: ‘free’ was not declared in 
this scope
 free ((void *)str.text);
   ^
../../gcc-5.5.0/libcpp/charset.c: In function ‘uchar* 
_cpp_convert_input(cpp_reader*, const char*, uchar*, size_t, size_t, const 
unsigned char**, off_t*)’:
../../gcc-5.5.0/libcpp/charset.c:1732:18: error: ‘free’ was not declared in 
this scope
   free (input);
  ^
In file included from 
/gnu/store/rn75fm7adgx3pw5j8pg3bczfqq1y17lk-gcc-7.5.0/include/c++/stdlib.h:36:0,
 from ../../gcc-5.5.0/libcpp/system.h:214,
 from ../../gcc-5.5.0/libcpp/directives.c:22:
/gnu/store/6wn346cbw1mh6264v426pwj2klgvxr0z-gcc-5.5.0/include/c++/cstdlib:118:11:
 error: ‘::div_t’ has not been declared
   using ::div_t;
   ^
/gnu/store/6wn346cbw1mh6264v426pwj2klgvxr0z-gcc-5.5.0/include/c++/cstdlib:119:11:
 error: ‘::ldiv_t’ has not been declared
   using ::ldiv_t;
   ^
/gnu/store/6wn346cbw1mh6264v426pwj2klgvxr0z-gcc-5.5.0/include/c++/cstdlib:121:11:
 error: ‘::abort’ has not been declared
   using ::abort;
   ^
/gnu/store/6wn346cbw1mh6264v426pwj2klgvxr0z-gcc-5.5.0/include/c++/cstdlib:122:11:
 error: ‘::abs’ has not been declared
   using ::abs;
   ^
/gnu/store/6wn346cbw1mh6264v426pwj2klgvxr0z-gcc-5.5.0/include/c++/cstdlib:123:11:
 error: ‘::atexit’ has not been declared
   using ::atexit;
   ^
/gnu/store/6wn346cbw1mh6264v426pwj2klgvxr0z-gcc-5.5.0/include/c++/cstdlib:129:11:
 error: ‘::atof’ has not been declared
   using ::atof;
   ^
/gnu/store/6wn346cbw1mh6264v426pwj2klgvxr0z-gcc-5.5.0/include/c++/cstdlib:130:11:
 error: ‘::atoi’ has not been declared
   using ::atoi;
   ^
/gnu/store/6wn346cbw1mh6264v426pwj2klgvxr0z-gcc-5.5.0/include/c++/cstdlib:131:11:
 error: ‘::atol’ has not been declared
   using ::atol;
…
In file included from ../../gcc-5.5.0/libcpp/system.h:214:0,
 from ../../gcc-5.5.0/libcpp/directives.c:22:
/gnu/store/rn75fm7adgx3pw5j8pg3bczfqq1y17lk-gcc-7.5.0/include/c++/stdlib.h:38:12:
 error: ‘std::abort’ has not been declared
 using std::abort;
^
/gnu/store/rn75fm7adgx3pw5j8pg3bczfqq1y17lk-gcc-7.5.0/include/c++/stdlib.h:39:12:
 error: ‘std::atexit’ has not been declared
 using std::atexit;
^
/gnu/store/rn75fm7adgx3pw5j8pg3bczfqq1y17lk-gcc-7.5.0/include/c++/stdlib.h:40:12:
 error: ‘std::exit’ has not been declared
 using std::exit;
^
/gnu/store/rn75fm7adgx3pw5j8pg3bczfqq1y17lk-gcc-7.5.0/include/c++/stdlib.h:51:12:
 error: ‘std::div_t’ has not been declared
 using std::div_t;
^
/gnu/store/rn75fm7adgx3pw5j8pg3bczfqq1y17lk-gcc-7.5.0/include/c++/stdlib.h:52:12:
 error: ‘std::ldiv_t’ has not been declared
 using std::ldiv_t;
^
/gnu/store/rn75fm7adgx3pw5j8pg3bczfqq1y17lk-gcc-7.5.0/include/c++/stdlib.h:55:12:
 error: ‘std::atof’ has not been declared
 using std::atof;
^
/gnu/store/rn75fm7adgx3pw5j8pg3bczfqq1y17lk-gcc-7.5.0/include/c++/stdlib.h:56:12:
 error: ‘std::atoi’ has not been declared
 using std::atoi;
^
/gnu/store/rn75fm7adgx3pw5j8pg3bczfqq1y17lk-gcc-7.5.0/include/c++/stdlib.h:57:12:
 error: ‘std::atol’ has not been declared
 using std::atol;
^
/gnu/store/rn75fm7adgx3pw5j8pg3bczfqq1y17lk-gcc-7.5.0/include/c++/stdlib.h:58:12:
 error: ‘std::bsearch’ has not been declared
 using std::bsearch;
^
/gnu/store/rn75fm7adgx3pw5j8pg3bczfqq1y17lk-gcc-7.5.0/include/c++/stdlib.h:59:12:
 error: ‘std::calloc’ has not been declared
 using std::calloc;
^
/gnu/store/rn75fm7adgx3pw5j8pg3bczfqq1y17lk-gcc-7.5.0/include/c++/stdlib.h:60:12:
 error: ‘std::div’ has not been declared
 using std::div;
^
/gnu/store/rn75fm7adgx3pw5j8pg3bczfqq1y17lk-gcc-7.5.0/include/c++/stdlib.h:61:12:
 error: ‘std::free’ 

bug#40549: More usability issues:

[zimoun]

Dear Tom,

On Tue, 12 May 2020 at 11:55, Tom Zander via Bug reports for GNU Guix
 wrote:

[...]

> C apps using libc, python apps using their parser, even C++ apps using the Qt
> commandline classes, all are generally compatible with regards to behavior.
>
> Only Guix is different.

Please could you indicate me command-line tools where short-option
with optional-argument is possible.
Because if there is one, I could have inspiration to know how it
resolves the ambiguity.


> > However (srfi srfi-37) does it as we see it now.  Fixing it would mean
> > implementing a different option parser.
>
> Then fix that parser. It is inconsistent with the rest of the world and as 
> long
> as it is end-user-facing this inconsistency is a usability bug. A rather
> massive one, I might say as this is about as core to the user-interaction of
> the platform as it can get.

The parser is not inconsistent with the rest of the world.  Or please
indicate with concrete examples what is wrong.

The issue is that Guix uses a bad practise: option with
optional-argument with both short and long name.  It is a mistake to
provide the short-name for such case.


Thank you for the report.  Now all this is clearer for me and I do not
think it is a fixable bug.

All the best,
simon

bug#41209: AVR toolchain fails to build

[Ricardo Wurmus]

avr-toolchain-5.5.0 fails to build.  It seems to be mixing headers from
GCC 5 and GCC 7:

--8<---cut here---start->8---
In file included from 
/gnu/store/rn75fm7adgx3pw5j8pg3bczfqq1y17lk-gcc-7.5.0/include/c++/stdlib.h:36:0,
 from ../../gcc-5.5.0/libcpp/system.h:214,
 from ../../gcc-5.5.0/libcpp/directives.c:22:
/gnu/store/6wn346cbw1mh6264v426pwj2klgvxr0z-gcc-5.5.0/include/c++/cstdlib:118:11:
 error: ‘::div_t’ has not been declared
   using ::div_t;
   ^
/gnu/store/6wn346cbw1mh6264v426pwj2klgvxr0z-gcc-5.5.0/include/c++/cstdlib:119:11:
 error: ‘::ldiv_t’ has not been declared
   using ::ldiv_t;
   ^
/gnu/store/6wn346cbw1mh6264v426pwj2klgvxr0z-gcc-5.5.0/include/c++/cstdlib:121:11:
 error: ‘::abort’ has not been declared
   using ::abort;
   ^
/gnu/store/6wn346cbw1mh6264v426pwj2klgvxr0z-gcc-5.5.0/include/c++/cstdlib:122:11:
 error: ‘::abs’ has not been declared
   using ::abs;
   ^
/gnu/store/6wn346cbw1mh6264v426pwj2klgvxr0z-gcc-5.5.0/include/c++/cstdlib:123:11:
 error: ‘::atexit’ has not been declared
   using ::atexit;
   ^
/gnu/store/6wn346cbw1mh6264v426pwj2klgvxr0z-gcc-5.5.0/include/c++/cstdlib:129:11:
 error: ‘::atof’ has not been declared
   using ::atof;
   ^
/gnu/store/6wn346cbw1mh6264v426pwj2klgvxr0z-gcc-5.5.0/include/c++/cstdlib:130:11:
 error: ‘::atoi’ has not been declared
   using ::atoi;
   ^
/gnu/store/6wn346cbw1mh6264v426pwj2klgvxr0z-gcc-5.5.0/include/c++/cstdlib:131:11:
 error: ‘::atol’ has not been declared
   using ::atol;
   ^
/gnu/store/6wn346cbw1mh6264v426pwj2klgvxr0z-gcc-5.5.0/include/c++/cstdlib:132:11:
 error: ‘::bsearch’ has not been declared
   using ::bsearch;
   ^
/gnu/store/6wn346cbw1mh6264v426pwj2klgvxr0z-gcc-5.5.0/include/c++/cstdlib:133:11:
 error: ‘::calloc’ has not been declared
   using ::calloc;
   ^
/gnu/store/6wn346cbw1mh6264v426pwj2klgvxr0z-gcc-5.5.0/include/c++/cstdlib:134:11:
 error: ‘::div’ has not been declared
   using ::div;
   ^
/gnu/store/6wn346cbw1mh6264v426pwj2klgvxr0z-gcc-5.5.0/include/c++/cstdlib:135:11:
 error: ‘::exit’ has not been declared
   using ::exit;
   ^
/gnu/store/6wn346cbw1mh6264v426pwj2klgvxr0z-gcc-5.5.0/include/c++/cstdlib:136:11:
 error: ‘::free’ has not been declared
   using ::free;
   ^
/gnu/store/6wn346cbw1mh6264v426pwj2klgvxr0z-gcc-5.5.0/include/c++/cstdlib:137:11:
 error: ‘::getenv’ has not been declared
   using ::getenv;
   ^
/gnu/store/6wn346cbw1mh6264v426pwj2klgvxr0z-gcc-5.5.0/include/c++/cstdlib:138:11:
 error: ‘::labs’ has not been declared
   using ::labs;
   ^
/gnu/store/6wn346cbw1mh6264v426pwj2klgvxr0z-gcc-5.5.0/include/c++/cstdlib:139:11:
 error: ‘::ldiv’ has not been declared
   using ::ldiv;
   ^
/gnu/store/6wn346cbw1mh6264v426pwj2klgvxr0z-gcc-5.5.0/include/c++/cstdlib:140:11:
 error: ‘::malloc’ has not been declared
   using ::malloc;
   ^
/gnu/store/6wn346cbw1mh6264v426pwj2klgvxr0z-gcc-5.5.0/include/c++/cstdlib:142:11:
 error: ‘::mblen’ has not been declared
   using ::mblen;
   ^
/gnu/store/6wn346cbw1mh6264v426pwj2klgvxr0z-gcc-5.5.0/include/c++/cstdlib:143:11:
 error: ‘::mbstowcs’ has not been declared
   using ::mbstowcs;
   ^
/gnu/store/6wn346cbw1mh6264v426pwj2klgvxr0z-gcc-5.5.0/include/c++/cstdlib:144:11:
 error: ‘::mbtowc’ has not been declared
   using ::mbtowc;
   ^
/gnu/store/6wn346cbw1mh6264v426pwj2klgvxr0z-gcc-5.5.0/include/c++/cstdlib:146:11:
 error: ‘::qsort’ has not been declared
   using ::qsort;
   ^
/gnu/store/6wn346cbw1mh6264v426pwj2klgvxr0z-gcc-5.5.0/include/c++/cstdlib:152:11:
 error: ‘::rand’ has not been declared
   using ::rand;
   ^
/gnu/store/6wn346cbw1mh6264v426pwj2klgvxr0z-gcc-5.5.0/include/c++/cstdlib:153:11:
 error: ‘::realloc’ has not been declared
   using ::realloc;
   ^
/gnu/store/6wn346cbw1mh6264v426pwj2klgvxr0z-gcc-5.5.0/include/c++/cstdlib:154:11:
 error: ‘::srand’ has not been declared
   using ::srand;
   ^
/gnu/store/6wn346cbw1mh6264v426pwj2klgvxr0z-gcc-5.5.0/include/c++/cstdlib:155:11:
 error: ‘::strtod’ has not been declared
   using ::strtod;
   ^
/gnu/store/6wn346cbw1mh6264v426pwj2klgvxr0z-gcc-5.5.0/include/c++/cstdlib:156:11:
 error: ‘::strtol’ has not been declared
   using ::strtol;
   ^
/gnu/store/6wn346cbw1mh6264v426pwj2klgvxr0z-gcc-5.5.0/include/c++/cstdlib:157:11:
 error: ‘::strtoul’ has not been declared
   using ::strtoul;
   ^
/gnu/store/6wn346cbw1mh6264v426pwj2klgvxr0z-gcc-5.5.0/include/c++/cstdlib:158:11:
 error: ‘::system’ has not been declared
   using ::system;
   ^
/gnu/store/6wn346cbw1mh6264v426pwj2klgvxr0z-gcc-5.5.0/include/c++/cstdlib:160:11:
 error: ‘::wcstombs’ has not been declared
   using ::wcstombs;
   ^
/gnu/store/6wn346cbw1mh6264v426pwj2klgvxr0z-gcc-5.5.0/include/c++/cstdlib:161:11:
 error: ‘::wctomb’ has not been declared
   using ::wctomb;
   ^
/gnu/sto

bug#40549: More usability issues:

[zimoun]

On Tue, 12 May 2020 at 10:51, Ludovic Courtès  wrote:

> Nothing new here, and everything is properly documented.

Using optional argument with short-option names is unusual, AFAIK.
And for sure, there is an ambiguity; as we are seeing here. :-)
However, the only mention of that is in the commentaries of srfi-37.

--8<---cut here---start->8---
;;; `required-arg?' and `optional-arg?' are mutually exclusive
;;; booleans and indicate whether an argument must be or may be
;;; provided.  Besides the obvious, this affects semantics of
;;; short-options, as short-options with a required or optional
;;; argument cannot be followed by other short options in the same
;;; program-arguments string, as they will be interpreted collectively
;;; as the option's argument.
--8<---cut here---end--->8---

http://git.savannah.gnu.org/cgit/guile.git/tree/module/srfi/srfi-37.scm#n51


Well, using short-option with optional-argument is not recommended by
POSIX, neither GNU (if I understand well)

https://pubs.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap12.html#tag_12_02
https://www.gnu.org/software/libc/manual/html_node/Argument-Syntax.html


Therefore, it deserves to document it, IMHO.

bug#40549: proposal for 'process-actions'

[zimoun]

Hi again, :-)

On Tue, 12 May 2020 at 12:38, zimoun  wrote:

> > We’ll need to check exactly what will behave differently.  If the tests
> > don’t catch anything, I think we’re fine.  Most likely, we’re talking
> > about corner cases like ‘-S x -d y’, which probably very few people
> > tried.
>
> Ok, on this light, let first point the corner cases.

The only corner cases are the '%actions' (roll-back,
delete-generation, switch-generation).  There are processed in
reversed order as they appear on the command-line -- because
'for-each' and 'assoc-ref'.

However, the transaction plan is always the same:
 step0 process %actions
 step1 remove
 step2 install
 step3 manifest

Therefore, I propose to split the 'for-each' on '%actions' into fixed
steps, such as the transaction always happens using this plan:

 1. roll-back
 2. switch-generation
 3. delete-generation
 4. remove
 5. install
 6 manifest

On one hand, it reduces the "power" of combining '-S', '-d' and
'--roll-back'.  On the other hand, it enforces commutativity which is
somehow what we want a transaction to be.

If yes, I can come up with a patch.


All the best,
simon

bug#40558: (no subject)

[Jelle Licht]

elaexuo...@wilsonb.com writes:

> With the patch to texlive-amsfonts the above typesets just fine; however, 
> metafont ends up generating cmmi10.657pk and cmr10.657pk font files. Is this 
> expected? Typsetting it from the texlive installation of my foreign distro 
> doesn't call out to metafont at all.

As I mentioned earlier, I am not a tex expert at all. I have no clue,
but if my patch makes spooky things happen, we should probably hold off
on applying it.

- Jelle

bug#41207: accountsservice daemon lacks dbus interfaces

[L p R n d n]

Hello,

The accountsservice service hasn't access to dbus' interfaces throwing
an error when they're needed.The problem, at least, appears with LightDM.
The error looks like:

WARNING: Error updating user /org/freedesktop/Accounts/User1000:
GDBus.Error:org.freedesktop.DBus.Error.InvalidArgs: No such interface
"org.freedesktop.DisplayManager.AccountsService"

For information, it already occured[0] and was resolved[1][2] in NixOS.

After testing, simply wrapping the accountsservice package with relevant
XDG_DATA_DIRS directories as done in the attached patch resolves the
issue. However, there might be a proper solution I'm not aware of.
Also the patch used in [2] doesn't seem to be needed in Guix.

Have a nice day,

L  p R n  d n

[0]: https://github.com/NixOS/nixpkgs/issues/45059
[1]: https://github.com/NixOS/nixpkgs/pull/45107
[2]: https://github.com/NixOS/nixpkgs/pull/72400

>From b9c379d068266c9fdc506f60ff05de3b39346999 Mon Sep 17 00:00:00 2001
From: L  p R n  d n 
Date: Tue, 12 May 2020 13:28:47 +0200
Subject: [PATCH] gnu: accountsservice: Wrap program.

* gnu/packages/freedesktop.scm (accountsservice): Add a wrap-program phase
setting XDG_DATA_DIRS to provide dbus interfaces.
---
 gnu/packages/freedesktop.scm | 32 +++-
 1 file changed, 19 insertions(+), 13 deletions(-)

diff --git a/gnu/packages/freedesktop.scm b/gnu/packages/freedesktop.scm
index b59d09d15f..01969e03a1 100644
--- a/gnu/packages/freedesktop.scm
+++ b/gnu/packages/freedesktop.scm
@@ -1020,19 +1020,25 @@ message bus.")
(("/bin/cat") (which "cat")))
  #t))
  (add-before
-  'configure 'pre-configure
-  (lambda* (#:key inputs #:allow-other-keys)
-;; Don't try to create /var/lib/AccountsService.
-(substitute* "src/Makefile.in"
-  (("\\$\\(MKDIR_P\\).*/lib/AccountsService.*") "true"))
-(let ((shadow (assoc-ref inputs "shadow")))
-  (substitute* '("src/user.c" "src/daemon.c")
-(("/usr/sbin/usermod") (string-append shadow "/sbin/usermod"))
-(("/usr/sbin/useradd") (string-append shadow "/sbin/useradd"))
-(("/usr/sbin/userdel") (string-append shadow "/sbin/userdel"))
-(("/usr/bin/passwd")   (string-append shadow "/bin/passwd"))
-(("/usr/bin/chage")(string-append shadow "/bin/chage"
-#t)
+ 'configure 'pre-configure
+   (lambda* (#:key inputs #:allow-other-keys)
+ ;; Don't try to create /var/lib/AccountsService.
+ (substitute* "src/Makefile.in"
+   (("\\$\\(MKDIR_P\\).*/lib/AccountsService.*") "true"))
+ (let ((shadow (assoc-ref inputs "shadow")))
+   (substitute* '("src/user.c" "src/daemon.c")
+ (("/usr/sbin/usermod") (string-append shadow "/sbin/usermod"))
+ (("/usr/sbin/useradd") (string-append shadow "/sbin/useradd"))
+ (("/usr/sbin/userdel") (string-append shadow "/sbin/userdel"))
+ (("/usr/bin/passwd")   (string-append shadow "/bin/passwd"))
+ (("/usr/bin/chage")(string-append shadow "/bin/chage"
+ #t))
+ (add-after 'install 'wrap-program
+   (lambda* (#:key outputs #:allow-other-keys)
+ (let ((out (assoc-ref outputs "out")))
+   (wrap-program (string-append out "/libexec/accounts-daemon")
+ `("XDG_DATA_DIRS" ":" prefix ("/run/current-system/profile/share")))
+   #t))
 (native-inputs
  `(("glib:bin" ,glib "bin") ; for gdbus-codegen, etc.
("gobject-introspection" ,gobject-introspection)
-- 
2.26.1

bug#40549: More usability issues:

[zimoun]

On Tue, 12 May 2020 at 11:55, Tom Zander via Bug reports for GNU Guix
 wrote:

> the bugreport is a usability bug which stems from the fact that the command
> line parser behaves differently from every single other commandline parser
> average people like me have ever used.
>
> A near 100% of the command line tools on your Gnu/Linux box will behave
> differently than guix does now.
>
> C apps using libc, python apps using their parser, even C++ apps using the Qt
> commandline classes, all are generally compatible with regards to behavior.
>
> Only Guix is different.

Could you provide concrete examples?  Other than "guix package"?
And other than short-option with optional argument?

bug#41205: make check stucks for hours

[Wensheng Xie]

commands run
0.
pwd = ~/work/guix
1.
guix environment guix --pure --ad-hoc git emacs strace gnupg
2.
./bootstrap
3.
./configure
4.
make check

output:
wxie@guix ~/work/guix$ guix environment guix --pure --ad-hoc git emacs strace 
gnupg
Folgende Ableitung wird erstellt:
   /gnu/store/96sb2i83hqwnxammj9vjknfpzp4f9wk3-profile.drv
Folgende Profil-Hooks werden erstellt:
   /gnu/store/4v8xf1z30yfir31d4kbdbrmg920ig07x-fonts-dir.drv
   /gnu/store/9gjd7g2mdhf4961rx89si9avs534rnj3-xdg-desktop-database.drv
   /gnu/store/japnrmzaq1a64c6hc1z0r33z2lkqw941-gtk-icon-themes.drv
   /gnu/store/m4a9ank4hkh80q7gwacddyfclzjxgswy-glib-schemas.drv
   /gnu/store/pxff98zfc0smwbqr7znkzf1j5ylaksrh-xdg-mime-database.drv
   /gnu/store/xbffjqblsz038whhbmvc9pi7rizlgrx2-gtk-im-modules.drv
   /gnu/store/xpv0ychbx92g95qgvkb1678j6j5fbim0-info-dir.drv
   /gnu/store/zaq2m6md9fr6mrklv6jfa40hrwr3296d-manual-database.drv
   /gnu/store/zmgzxh8w5pmh7i9bd31pfnykx1yi0msv-ca-certificate-bundle.drv
Zertifikatsbündel der Zertifikatsautoritäten wird erstellt …
Schriftartenverzeichnis wird erstellt …
Zwischenspeicher für GLib-Schemata wird erzeugt …
Zwischenspeicher für GTK-Symbolthemen wird erzeugt …
Dateien im Zwischenspeicher für GTK-Eingabemethoden werden erstellt …
Verzeichnis von Info-Handbüchern wird erstellt …
Datenbank für Handbuchseiten wird erstellt …
Zwischenspeicher für XDG-Desktop-Dateien wird erzeugt …
XDG-Mime-Datenbank wird erstellt …
Profil mit 58 Paketen wird erstellt …
wxie@guix ~/work/guix [env]$ ./bootstrap
++ find po/doc -type f -name 'guix-manual*.po'
++ xargs -n 1 '-I{}' basename '{}' .po
++ sed -e 's,guix-manual\.,,'
+ langs='de
fr
zh_CN
es
ru'
+ for lang in ${langs}
+ '[' '!' -e doc/guix.de.texi ']'
+ for lang in ${langs}
+ '[' '!' -e doc/guix.fr.texi ']'
+ for lang in ${langs}
+ '[' '!' -e doc/guix.zh_CN.texi ']'
+ for lang in ${langs}
+ '[' '!' -e doc/guix.es.texi ']'
+ for lang in ${langs}
+ '[' '!' -e doc/guix.ru.texi ']'
++ find po/doc -type f -name 'guix-cookbook*.po'
++ sed -e 's,guix-cookbook\.,,'
++ xargs -n 1 '-I{}' basename '{}' .po
+ langs=de
+ for lang in ${langs}
+ '[' '!' -e doc/guix-cookbook.de.texi ']'
+ exec autoreconf -vfi
autoreconf: Entering directory `.'
autoreconf: running: autopoint --force
autoreconf: running: aclocal --force -I m4
autoreconf: configure.ac: tracing
autoreconf: configure.ac: not using Libtool
autoreconf: running: 
/gnu/store/yk3zw1pqbs5wlf1lapf25986yjd0g736-autoconf-2.69/bin/autoconf --force
autoreconf: running: 
/gnu/store/yk3zw1pqbs5wlf1lapf25986yjd0g736-autoconf-2.69/bin/autoheader --force
autoreconf: running: automake --add-missing --copy --force-missing
configure.ac:23: warning: The 'AM_PROG_MKDIR_P' macro is deprecated, and its 
use is discouraged.
configure.ac:23: You should use the Autoconf-provided 'AC_PROG_MKDIR_P' macro 
instead,
configure.ac:23: and use '$(MKDIR_P)' instead of '$(mkdir_p)'in your 
Makefile.am files.
Makefile.am:647: warning: AM_GNU_GETTEXT used but 'po' not in SUBDIRS
autoreconf: Leaving directory `.'
wxie@guix ~/work/guix [env]$ ./configure
checking for a BSD-compatible install... 
/gnu/store/bp62pwbhja21d2xzq0n71frhir346d7n-profile/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... 
/gnu/store/bp62pwbhja21d2xzq0n71frhir346d7n-profile/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether make supports nested variables... (cached) yes
checking whether make supports the include directive... yes (GNU style)
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... 
/gnu/store/bp62pwbhja21d2xzq0n71frhir346d7n-profile/bin/grep
checking for egrep... 
/gnu/store/bp62pwbhja21d2xzq0n71frhir346d7n-profile/bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking whether NLS is requested... yes
checking for msgfmt... 
/gnu/store/bp62pwbhja21d2xzq0n71frhir346d7n-profile/bin/msgfmt
checking for gmsgfmt... 
/gnu/store/bp62pwbhja21d2xzq0n71frhir346d7n

bug#40549: More usability issues:

[zimoun]

Hi Ludo,

Sorry, I am not compliant and reorder your quotes to ease the
discussion -- from my point of view. :-)


On Tue, 12 May 2020 at 10:51, Ludovic Courtès  wrote:

> However (srfi srfi-37) does it as we see it now.  Fixing it would mean
> implementing a different option parser.

Yes or add a lot of complexity.
Both appears to me wrong.  Such corner cases do not deserve one or the other.


> I think there are option parsers that “correctly” deal with the
> ambiguity that arises for instance with “-I -p foo” (is ‘-p’ the
> argument to ‘-I’ or something else?).  Perhaps libc’s argp does it
> right.

I have never deeply dove into srfi-37 and 'option' but from my
understanding, it is not possible.  Somehow, the issue comes from
srfi-37 and srfi-37 should consider that if an argument starts with
dash, then it is not an argument and turn it into an option.


> Nothing new here, and everything is properly documented.

I am not sure.  The manual says, for example:

--8<---cut here---start->8---
‘--list-installed[=REGEXP]’
‘-I [REGEXP]’
 List the currently installed packages in the specified profile,
 with the most recently installed packages shown last.  When REGEXP
 is specified, list only installed packages whose name matches
 REGEXP.
--8<---cut here---end--->8---

which is somehow inaccurate.  The REGEXP is not optional for the short
option '-I'.  And that's true for all the short options with optional
argument, if I understand correctly.  For example, "guix package -d -p
/path/to/profile" fails.


Moreover, the distinction between 'action' and 'query' is already
stated so why not underline that composing actions make sense
(transaction) but composing query not?


> > However, main of us are used to read from left to right so it seems
> > more natural to write:
> >
> > guix package --action1 --action2  # (a)
> > than
> > guix package --action2 --action1  # (b)
> >
> > in other words, the fix should be to simply 'reverse opts' and the CLI
> > will read (a) instead of the current (b).  My only concern is about
> > backward compatibility.
>
> We’ll need to check exactly what will behave differently.  If the tests
> don’t catch anything, I think we’re fine.  Most likely, we’re talking
> about corner cases like ‘-S x -d y’, which probably very few people
> tried.

Ok, on this light, let first point the corner cases.


All the best,
simon

bug#40549: More usability issues:

[Tom Zander via Bug reports for GNU Guix]

On dinsdag 12 mei 2020 10:51:28 CEST Ludovic Courtès wrote:
> Nothing new here, and everything is properly documented.

The bugreport was not about a disconnect between documentation and the tool,

the bugreport is a usability bug which stems from the fact that the command 
line parser behaves differently from every single other commandline parser 
average people like me have ever used.

A near 100% of the command line tools on your Gnu/Linux box will behave 
differently than guix does now.

C apps using libc, python apps using their parser, even C++ apps using the Qt 
commandline classes, all are generally compatible with regards to behavior.

Only Guix is different.

> However (srfi srfi-37) does it as we see it now.  Fixing it would mean
> implementing a different option parser.

Then fix that parser. It is inconsistent with the rest of the world and as long 
as it is end-user-facing this inconsistency is a usability bug. A rather 
massive one, I might say as this is about as core to the user-interaction of 
the platform as it can get.

-- 
Tom Zander

bug#40682: Installer hangs while connecting to WiFi network

[Ricardo Wurmus via web]

Alternative URL: https://issues.guix.gnu.org/40993

bug#40682: frozen installer in WiFi section -guix 1.1.0

[Mathieu Othacehe]

Hey Leo,

> If we have a fix, can we make a new installer image? There are people on
> #guix having trouble getting online in the installer, and I think they
> are hitting this issue.

This bug has been fixed with ea6594e0. However, I left the ticket open
because I'm supposed to add some testing using the hostapd service Ludo
proposed.

Regarding providing a new image, I proposed a patch here[1] so that
Cuirass can host fresh installation images built upon master.

Thanks,

Mathieu

[1]: https://lists.gnu.org/archive/html/guix-patches/2020-05/msg1.html

bug#40549: More usability issues:

[Ludovic Courtès]

Hi,

zimoun  skribis:

>> --8<---cut here---start->8---> # OK
>>  guix package --list-generations -p /path/to/profile
>>  guix package --list-installed -p /path/to/profile
>>
>> # KO
>>  guix package -l -p /path/to/profile
>>  guix package -I -p /path/to/profile
>>
>> # OK
>>  guix package -p /path/to/profile -l
>>  guix package -p /path/to/profile -I
>>
>> # KO
>>  guix package -l --profile=/path/to/profile
>>
>> # Do nothing
>>  guix package -I --profile=/path/to/profile
>>
>> # OK
>>  guix package -l --profile=/path/to/profile -l
>>  guix package -I --profile=/path/to/profile -I
>> --8<---cut here---end--->8---
>
> All are expected too.
> Same reason.  And the long option works because no argument is
> provided by '=' so it fallback to the default one "".
> Short options expect an argument so read the next characters as the
> value or fallback to the default one "" when there is no next
> character.
>
> Fixing this will add complexity on parsing 'args' when building
> 'opts'.  Basically, "guix package -I -p /path/tp/profile" returns an
> error because the short option '-I' expect only one argument, read
> '-p' and then Guix cannot deals with the option '/path/to/profile' and
> so raises an error. See the dance with 'handle-argument' and
> 'arg-handler'.  And "guix package -I '' -p /path/to/profile' works,
> obviously.  Well, the extra quotes ('') is annoying but I am not
> convince that better could be done for short options -- regardless the
> order of CLI arguments.

Nothing new here, and everything is properly documented.

I think there are option parsers that “correctly” deal with the
ambiguity that arises for instance with “-I -p foo” (is ‘-p’ the
argument to ‘-I’ or something else?).  Perhaps libc’s argp does it
right.

However (srfi srfi-37) does it as we see it now.  Fixing it would mean
implementing a different option parser.

> Why (a) works and (b) not?  Because the command-line is transformed
> into an alist.  And this alist is built reading the command-line from
> right to left.  Therefore, if you are on the generation 18 and you try
> to delete it, Guix raises an error which seems expected.  The second
> one (b) works because first you switch and then you delete.
>
> Well, that's said, IMHO, two options:
>
>  1) the order of CLI does not matter;
>  2) the order of CLI matters.
>
> Well, the order of 'actions' necessary matters as it is seen with this
> example: "switch and then delete" does not end in the same state than
> "delete and then switch".  Welcome in the classical mess of imperative
> package manager. ;-)
> Therefore, I am not convinced that something should be fixed.  It
> comes from the very nature of 'actions': actions is not always
> commutative.  Otherwise the best is to forbid to provide several
> actions with the same transaction; which seems a bad idea -- at least
> for me.

Right, but at least we could reverse the list returned by ‘args-fold’.

> However, main of us are used to read from left to right so it seems
> more natural to write:
>
> guix package --action1 --action2  # (a)
> than
> guix package --action2 --action1  # (b)
>
> in other words, the fix should be to simply 'reverse opts' and the CLI
> will read (a) instead of the current (b).  My only concern is about
> backward compatibility.

We’ll need to check exactly what will behave differently.  If the tests
don’t catch anything, I think we’re fine.  Most likely, we’re talking
about corner cases like ‘-S x -d y’, which probably very few people
tried.

Thanks,
Ludo’.

bug#41182: Profile hooks ignore system and target

[Mathieu Othacehe]

Hey Ludo,

> So I’m very much tempted to instead require each hook to take ‘system’
> and ‘#:target’ arguments and pass them to ‘gexp->derivation’.  It’ll
> break the API, in case someone out there has custom profile hooks
> (unlikely given that it’s not really documented), but I’d say that’s OK.
>
> Thoughts?

What seems strange to me is that gexp->derivation has target set to
'current by default, so it should use the defined target. Now, that I
look at it, it's using "%current-target-system".

Would it make any difference to switch:

--8<---cut here---start->8---
  (target -> (if (eq? target 'current)
 (%current-target-system)
 target))
--8<---cut here---end--->8---

to

--8<---cut here---start->8---
(target (if (eq? target 'current)
(current-target-system)
(return target)))
--8<---cut here---end--->8---

like for lower-object, gexp->file and gexp->script?

Regarding breaking the profile hooks API, it's fine by me.

Thanks for investigating this,

Mathieu