bug#40549: More usability issues:
On Fri, Apr 24, 2020 at 10:28:50AM +0200, zimoun wrote: > On Thu, 23 Apr 2020 at 21:52, Tom via Bug reports for GNU Guix > wrote: > > > > To add detail here: > > > > Doing `guix package -d 18 -S 17` actually works. > > > > This gives me the impression that the order of arguments is relevant to the > > processing of them. > > It is known and cumbersome: a feature? ;-) > > Other examples: > > guix package -I -A # does nothing > guix package -A -I # list available > > > > Another, similar, example is: > > > >guix package -l --profile=a > > > > this doesn't work. But the most curious thing is that this does: > > > >guix package --list-installed --profile=a > > It is worse than that. > > --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--- > > > Well, it seems there is a bug. :-) > > Back to the first examples: > > --8<---cut here---start->8--- > # Do something > guix package --list-installed -A > > # Do nothing > guix package -I -A > --8<---cut here---end--->8--- > > > Thanks for reporting. > > All the best, > simon > To add to this: $ guix package -p profile1 -p profile2 -I | wc -l 91 $ guix package -p profile2 -p profile1 -I | wc -l 12 -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
bug#41120: uvesafb service is unsupported on aarch64
Hi, Mathieu Othacehe skribis: > Here's a rebased version of Ludo's patch. I'm not sure about the merge > resolution in "lower-object", but otherwise it works fine! > > Ludo, would it be of to push it? I’d like to think a bit more about it. In particular, ‘let-system’ is not great because we’d also want to know the target in many cases. Sorry for the delay, I need to swap that in! Ludo’.
bug#41233: GNU Freefont is broken
Hello, Thanks for your inputs! Totally my bad here... It appears I didn't have font-gnu-freefont in my system packages anymore and I forgot. + I mixed it with another issue. I'm currently reconfiguring to verify it's ok. Unless I bring something new until tomorrow, this issue can be safely be closed. Sorry for te unnecessary bug report. Have a nice day, L p R n d n
bug#40549: More usability issues:
Dear Arne,
On Wed, 13 May 2020 at 20:53, Arne Babenhauserheide wrote:
> zimoun writes:
> > It would like it works. And to do so, I accept that "guix package -I
> > regexp -p /tmp/profile" does not anymore and would be replaced by
> > "guix package -Iregexp -p /tmp/profile" which already works (as
> > specified by SRFI-37).
>
> Wow, this surprised me. I expected
>
>guix package -Iregexp
>
> to be equivalent to
>
>guix package -I -r -e -g -e -x -p
>
> which is how getopt long works in the shell.
I am not familiar with getopt but I think getopt does what the POSIX specifies.
Your expectation is legitimate when all the flags does not require a
mandatory argument. For example,
ls -artl
but it is not true when one of the flags requires one mandatory
argument, for example,
ls -aIrtl
then 'rtl' is seen as the argument of the option '-I, --ignore='.
Well, the correct is:
ls -aI '' -rtl
And the specification e.g., [1], says that "ls -aI'' -rtl" should too;
as for example "cut -f1 -d" and "cut -f 1 -d" both are allowed.
I should misread but all that perfectly works and is clearly specified
by SRFI-37. What is missing is the corner case: how to deal with
short-name option with optional argument? There is 2 incompatible
rules as I try to explain here [2]. The choice of the Guile
implementation leads to break the permutation rule for the short-name
with optional argument and maintain consistency with the space between
flag and argument. Another choice is to break the consistency with
the space between flag and argument and so it does not break the
permutation rule; as Tom mentioned with the Git example of
'-S[], --gpg-sign[=]'.
The issue is that the semantic of short-name of optional argument is
ambiguous considering all the other rules.
[1] https://www.gnu.org/software/libc/manual/html_node/Argument-Syntax.html
[2] http://issues.guix.gnu.org/40549#16
> > Instead of what I am proposing, what do you suggest?
>
> What I would suggets would break -Iregexp and as such deviate from
> SRFI-37, so it wouldn’t be optimal.
Just to note that the Guile implementation of SRFI-37 is "aware" of
this corner case as it is mentioned in their commentary, already said
here [3]. :-)
http://git.savannah.gnu.org/cgit/guile.git/tree/module/srfi/srfi-37.scm#n51
[3] http://issues.guix.gnu.org/40549#10
> It would first need another SRFI so it’s no shortterm fix :-)
>From my point of view, different fixes are possible depending on what
we accept to break (here for "guix package" and probably similar cases
with other subcommand exist):
- nothing => improve the manual
- remove the short-name -u, -l, -d, -I, -A
- remove the argument for the short-name and keep it for the long-name only.
- remove '-X value' and allow only -'Xvalue' for X in {u, l, d, I, A}
=> new / amend SRFI-37
- other that my imagination is missing
Well, I have asked advices on guile-user [4]. I do not know if the
issue could be seen as a bug of SRFI-37.
[4] https://lists.gnu.org/archive/html/guile-user/2020-05/msg00034.html
> The commandline handling I want is this:
> https://www.draketo.de/english/free-software/shell-argument-parsing
Thank you for the link. For my understanding -- even after reading
the stackoverflow link -- your handling does not address the
short-name with optional argument. Does it mean you consider that
should not happen?
Best regards,
simon
bug#40549: More usability issues:
Hi Efraim, On Thu, 14 May 2020 at 10:15, Efraim Flashner wrote: > $ guix package -p profile1 -p profile2 -I | wc -l > 91 > $ guix package -p profile2 -p profile1 -I | wc -l > 12 I bet: $ guix package -p profile1 -I | wc -l 91 $ guix package -p profile2 -I | wc -l 12 Well, thank you for the report. Cheers, simon
bug#41182: Profile hooks ignore system and target
Hi,
Ludovic Courtès skribis:
> I’ve tried to address it in an API-compatible way, which meant setting
> the ‘%current-system’ and ‘%current-target-system’ parameters around the
> hook calls, but that is ugly, hard to get right (dynamic binding and
> monadic code really don’t go together well :-/), and actually raises
> another issue (‘mapm/accumulate-builds’ appears to ignore the initial
> dynamic bindings for these two parameters). Hacky patch attached to
> illustrate.
I was able to boil this second sub-problem down to a simple case:
--8<---cut here---start->8---
$ cat /tmp/t.scm
(use-modules (guix)
(guix grafts)
(gnu packages idutils))
(define target
(getenv "REAL_TARGET"))
(%graft? #f)
(with-store s
(parameterize ((%current-target-system (getenv "TARGET")))
(pk (if target
(package-cross-derivation s idutils target)
(package-derivation s idutils)
$ REAL_TARGET=arm-linux-gnueabihf ./pre-inst-env guile /tmp/t.scm
;;; (# /gnu/store/6kq4ick0jljrfjnhw0v2yghr8nalhrqi-idutils-4.6 7f0867c0de10>)
$ TARGET=arm-linux-gnueabihf REAL_TARGET=arm-linux-gnueabihf ./pre-inst-env
guile /tmp/t.scm
;;; (# /gnu/store/v4rgm5yhyx5ir3622hhxcaz3a10flcyr-idutils-4.6 7f7a4b1010a0>)
--8<---cut here---end--->8---
IOW, the initial value of ‘%current-target-system’ leads us to pick
ld-wrapper -> guile -> bdw-gc -> libatomic-ops in the second case, which
is wrong and due to this conditional in libgc’s inputs:
(propagated-inputs
(if (%current-target-system)
;; The build system refuses to check for compiler intrinsics when
;; cross-compiling, and demands using libatomic-ops instead.
`(("libatomic-ops" ,libatomic-ops))
'()))
As it turns out, ‘guix pack’ and ‘guix system’ are the only programs
that set ‘%current-target-system’ at the top level, via
‘run-with-store’.
Ludo’.
bug#22459: Guix tools should not honor NIX_* environment variables
These NIX_* variables are still in use: NIX_AFFINITY_HACK NIX_BIN_DIR NIX_BUILD_CORES NIX_HELD_LOCKS NIX_IGNORE_SYMLINK_STORE NIX_STORE NIX_STORE_DIR This is used internally: _NIX_OPTIONS -- Ricardo
bug#41257: ibus-setup failed
wxie@guix ~$ ibus-daemon --xim --replace --daemonize wxie@guix ~$ ibus-setup /gnu/store/y4qwsw06ynvw3fjk2lrspp89mfmjzj5i-python-pygobject-3.28.3/lib/python3.7/site-packages/gi/module.py:177: Warning: cannot register existing type 'GdkPixbuf' g_type = info.get_g_type() /gnu/store/y4qwsw06ynvw3fjk2lrspp89mfmjzj5i-python-pygobject-3.28.3/lib/python3.7/site-packages/gi/module.py:177: Warning: g_type_add_interface_static: assertion 'G_TYPE_IS_INSTANTIATABLE (instance_type)' failed g_type = info.get_g_type() /gnu/store/y4qwsw06ynvw3fjk2lrspp89mfmjzj5i-python-pygobject-3.28.3/lib/python3.7/site-packages/gi/module.py:177: Warning: g_once_init_leave: assertion 'result != 0' failed g_type = info.get_g_type() /gnu/store/y4qwsw06ynvw3fjk2lrspp89mfmjzj5i-python-pygobject-3.28.3/lib/python3.7/site-packages/gi/module.py:211: Warning: g_type_get_qdata: assertion 'node != NULL' failed type_ = g_type.pytype /gnu/store/y4qwsw06ynvw3fjk2lrspp89mfmjzj5i-python-pygobject-3.28.3/lib/python3.7/site-packages/gi/module.py:225: Warning: g_type_get_qdata: assertion 'node != NULL' failed g_type.pytype = wrapper /gnu/store/y4qwsw06ynvw3fjk2lrspp89mfmjzj5i-python-pygobject-3.28.3/lib/python3.7/site-packages/gi/module.py:225: Warning: g_type_set_qdata: assertion 'node != NULL' failed g_type.pytype = wrapper cannot setup extra input method, e.g., ibus-rime
bug#30095: substitute* decoding-error
I’m closing this as eureka-editor has already been added to the Guix package collection. -- Ricardo
bug#41257: ibus-setup failed
Does it work after removing ~/.config/ibus and ~/.cache/ibus/? -- Ricardo
bug#41233: GNU Freefont is broken
L p, L p R n d n 写道： Totally my bad here... It appears I didn't have font-gnu-freefont in my system packages anymore and I forgot. + I mixed it with another issue. ^_^ I'm currently reconfiguring to verify it's ok. Unless I bring something new until tomorrow, this issue can be safely be closed. Great! You can do so yourself by sending your next mail to -d...@debbugs.gnu.org instead of @. Sorry for te unnecessary bug report. No need to apologise for this. We got a slightly nicer WOFF bikeshed out of it. Kind regards, T G-R signature.asc Description: PGP signature
bug#41249: magic-wormhole fails to build
Mikhail Tsykalov writes: > magic-wormhole fails in test stage with errors similar to following: > > Expected: (,) > Got: [Failure instance: Traceback: : an integer is > required (got type bytes) Fixed in f227dd489b0a1e6905801b1e73f85dde852b5713, thanks! signature.asc Description: PGP signature
bug#40549: Fix -p profile -p profile -I
On Thu, 14 May 2020 at 10:15, Efraim Flashner wrote: > $ guix package -p profile1 -p profile2 -I | wc -l > 91 > $ guix package -p profile2 -p profile1 -I | wc -l > 12 Just to let you know that a fix is proposed there [1]. [1] http://issues.guix.gnu.org/issue/41260 All the best, simon
bug#34813: Problem with gnome-online-accounts integration
I can’t reproduce this easily as I have no accounts with any of the supported services. Could this be related to dconf? Have you tried running it with GNOME debug environment variables set? -- Ricardo
bug#41244: xdg-open: mailto doesnt work
Jonathan Brielmaier writes: > Trying `xdg-open mailto:guix-de...@gnu.org` in XFCE or MATE fails. The > same happens when you click on a mailto link in Icecat. I have > claws-mail and icedove installed. They both have > `MimeType=x-scheme-handler/mailto;` in their desktop files. Pushed the fix from #41255 with commit 5c7e477c6cfe89aa4dfce557ea181e5aa8ba8a05. -- Ricardo
bug#41264: Bootstrap packages fail to build.
Hello,
This command fails on one of my systems:
--8<---cut here---start->8---
guix build -e "(@@ (gnu packages commencement) glibc-mesboot0)"
--8<---cut here---end--->8---
with the following error:
--8<---cut here---start->8---
phase `unpack' succeeded after 11.8 seconds
starting phase `apply-boot-patch'
patch: fstatsterror: unknown error:
command "patch" "--force" "-p1" "-i"
"/gnu/store/pfz4y5i7krlvam2m8lpddmg9vi44rpqh-glibc-boot-2.2.5.patch" failed
with status 2
note: keeping build directory `/tmp/guix-build-glibc-mesboot0-2.2.5.drv-1'
builder for
`/gnu/store/jcqggqckhiq43y2ivlfhpkbfbp2vyjlc-glibc-mesboot0-2.2.5.drv' failed
with exit code 1
build of /gnu/store/jcqggqckhiq43y2ivlfhpkbfbp2vyjlc-glibc-mesboot0-2.2.5.drv
failed
View build log at
'/var/log/guix/drvs/jc/qggqckhiq43y2ivlfhpkbfbp2vyjlc-glibc-mesboot0-2.2.5.drv.bz2'.
guix build: error: build of
`/gnu/store/jcqggqckhiq43y2ivlfhpkbfbp2vyjlc-glibc-mesboot0-2.2.5.drv' failed
--8<---cut here---end--->8---
Here's a stracing of the failing "patch" command:
--8<---cut here---start->8---
open("/gnu/store/pfz4y5i7krlvam2m8lpddmg9vi44rpqh-glibc-boot-2.2.5.patch",
O_RDONLY) = 3
brk(0x9377913) = 0x9377913
fstat(3, 0xffb29328)= -1 EOVERFLOW (Value too large for
defined data type)
--8<---cut here---end--->8---
"patch-mesboot" is built for 32 bits. Hence, it can be using
"__ia32_sys_fstat", "__ia32_compat_sys_newfstat" or
"__ia32_compat_sys_x86_fstat64" syscall for "fstat". Here, according to
perf, it's using __ia32_compat_sys_newfstat which is overflowing on my
file system (inode count to high or so).
There's a little demonstration program attached. When built with `gcc
-m32 test.c', I have:
--8<---cut here---start->8---
fstat(3, 0xffad5874)= -1 EOVERFLOW (Value too large for
defined data type)
fstat64(3, {st_mode=S_IFDIR|0555, st_size=4096, ...}) = 0
fstat64(3, {st_mode=S_IFDIR|0555, st_size=4096, ...}) = 0
--8<---cut here---end--->8---
So I think somehow, bootstrap packages use the legacy "fstat" syscall,
which may overflow on a 64 bits system.
WDYT,
Thanks,
Mathieu
#define _GNU_SOURCE
#include
#include
#include
#include
#include
#include
#include
#include
#include
int
main(int argc, char *argv[])
{
struct stat sb;
if (argc != 2) {
fprintf(stderr, "Usage: %s \n", argv[0]);
exit(EXIT_FAILURE);
}
int fd = open(argv[1], O_RDONLY);
syscall(__NR_fstat, fd, &sb);
syscall(__NR_fstat64, fd, &sb);
fstat(fd, &sb);
exit(EXIT_SUCCESS);
}
bug#41182: Profile hooks ignore system and target
Alright, fixed! 80963744a2 store: 'mapm/accumulate-builds' preserves '%current-target-system'. f52fbf7094 packages: Ensure bags are insensitive to '%current-target-system'. Ludo’.
bug#41266: Suggested command to import key does not work on debian
Hi, I just installed a debian VM to test changes in the install script and found this issue when running the installer script: First it fails because it cannot find the public key and suggests running: wget … -q0 - | gpg --import -q0 does not work with debian's wget, but -O works. Aftcr importing the key, the script still complains it cannot find it. Re-running the same command with "sudo" in front of the gpg import command re-imports the key and the script is then able to find it. My guess is that the first import imported the key in my user's keyring, but the script looks in root's keyring. The second attempt added the key to root's keyring.
bug#41025: blueman does not start
I've pushed your latest patch here: c5a9b16dbdc8849560fb43095e090ba0952277b6. The only change I've done beside indentation is patching the scripts in libexec/. Thanks for your patience! -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#26202: XDG_DATA_DIRS issue on foreign distro
Dear, In this old bug [1], you described an issue using ~/.profile, XDG_DATA_DIRS and GNOME on the foreign distro Trisquel 7. I am not able to reproduce the issue on Debian. Because it is old, could you say if this bug is still an issue? or if it is now solved for you. Best regards, simon [1] http://issues.guix.gnu.org/issue/26202
bug#41266: Suggested command to import key does not work on debian
Hi Julien, > First it fails because it cannot find the public key and suggests running: > > wget … -q0 - | gpg --import > > -q0 does not work with debian's wget, but -O works. The installer script does not display this command. There is no zero in the wget commands. > Aftcr importing the key, the script still complains it cannot find > it. Re-running the same command with "sudo" in front of the gpg import > command re-imports the key and the script is then able to find it. > > My guess is that the first import imported the key in my user's > keyring, but the script looks in root's keyring. The second attempt > added the key to root's keyring. Yes, this is correct. Since the installer script runs as root the key import also needs to be done as root to affect the root user’s keyring. -- Ricardo
bug#26202: XDG_DATA_DIRS issue on foreign distro
Hello, zimoun writes: > In this old bug [1], you described an issue using ~/.profile, > XDG_DATA_DIRS and GNOME on the foreign distro Trisquel 7. > > I am not able to reproduce the issue on Debian. Interesting. > Because it is old, could you say if this bug is still an issue? or if > it is now solved for you. I cannot answer for the OP, but bug 35308, which may be related, is still acute. Regards, -- Nicolas Goaziou
bug#22020: guile-sdl-0.5.2 fails to install on i686
Guile SDL 0.5.2 still fails on i686:
--8<---cut here---start->8---
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Internal error: Could not resolve keysym XF86FullScreen
Errors from xkbcomp are not fatal to the X server
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Internal error: Could not resolve keysym XF86FullScreen
Errors from xkbcomp are not fatal to the X server
/gnu/store/v1g7f3p4f0851mywrla8qmr9hb8jgfjr-bash-minimal-5.0.16/bin/bash: line
5: 6964 Segmentation fault HAVE_TTF=1 HAVE_MIXER=0 sh zow ${dir}$tst
FAIL: gfx.scm
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Internal error: Could not resolve keysym XF86FullScreen
Errors from xkbcomp are not fatal to the X server
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Internal error: Could not resolve keysym XF86FullScreen
Errors from xkbcomp are not fatal to the X server
PASS: fading.scm
==
1 of 8 tests failed
(3 tests were not run)
Please report to bug-guile-...@gnu.org
==
--8<---cut here---end--->8---
I’m putting bug-guile-...@gnu.org in Cc, hoping that this time our
message can be delivered.
If this doesn’t work we should mark this package unsupported for
i686-linux.
--
Ricardo
bug#31719: icedtea-3 binaries contain references to icedtea-2
This seems to affect the openjdk packages as well, so a user of OpenJDK 12 will have to download *all* JDKs. Gábor, have you been able to identify locations that retain references to the build JDK? -- Ricardo
bug#22366: [EXT] Bug#22366 Status? Chicken Scheme release tarballs ship non-source C code
On Tue, May 12, 2020 at 7:33 PM zimoun wrote: > > 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? Because software is not bootstrappable if it requires taking for granted files that are not source code. In this case, it is these C files. These files are not source code because they are machine generated. In order to generate these files, you need a Chicken Scheme compiler. Therefore, you cannot build Chicken Scheme from source code without already having Chicken Scheme, which makes it non-bootstrappable. I have not kept track of this issue but my understanding was that the Chicken developers do not care (which is unfortunately a very common reaction from developers of self-hosted compilers) but it is nevertheless a bootstrapping issue. > Thank you in advance for any comments. > Or could this bug report be closed? I don't think this can be closed because it is still an issue. - Dave
bug#41025: blueman does not start
Hi Pierre! > I've pushed your latest patch here: > c5a9b16dbdc8849560fb43095e090ba0952277b6. > > The only change I've done beside indentation is patching the scripts in > libexec/. > > Thanks for your patience! Thank you! Do you still get the following error, while starting blueman-manager or blueman-applet? Failed to apply network settings You might not be able to connect to the Bluetooth network via this machine Exception g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.blueman.Mechanism was not provided by any .service files Regards, RG. signature.asc Description: OpenPGP digital signature
bug#41025: blueman does not start
Hi Pierre!
>> I've pushed your latest patch here:
>> c5a9b16dbdc8849560fb43095e090ba0952277b6.
>>
>> The only change I've done beside indentation is patching the scripts in
>> libexec/.
>>
>> Thanks for your patience!
>
> Thank you!
>
> Do you still get the following error, while starting blueman-manager or
> blueman-applet?
>
> Failed to apply network settings
> You might not be able to connect to the Bluetooth network via this machine
> Exception
> g-dbus-error-quark:
> GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name
> org.blueman.Mechanism was not provided by any .service files
Also, please find the attached patch to enable appindicator in blueman.
Regards,
RG.
From bb7ddb8471d7473fdac3d8e545f0141036d6edb7 Mon Sep 17 00:00:00 2001
From: Raghav Gururajan
Date: Thu, 14 May 2020 20:50:42 -0400
Subject: [PATCH] gnu: blueman: Enable AppIndicator.
* gnu/packages/networking.scm (blueman) [arguments]: Remove --disable
-appindicator configure-flag.
[inputs]: Add libappindicator.
---
gnu/packages/networking.scm | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gnu/packages/networking.scm b/gnu/packages/networking.scm
index 7ae1240e15..42a3609ac2 100644
--- a/gnu/packages/networking.scm
+++ b/gnu/packages/networking.scm
@@ -87,6 +87,7 @@
#:use-module (gnu packages dejagnu)
#:use-module (gnu packages documentation)
#:use-module (gnu packages flex)
+ #:use-module (gnu packages freedesktop)
#:use-module (gnu packages gettext)
#:use-module (gnu packages glib)
#:use-module (gnu packages gnome)
@@ -140,7 +141,6 @@
(build-system glib-or-gtk-build-system)
(arguments
`(#:configure-flags (list "--enable-polkit"
- "--disable-appindicator" ; Not available
"--without-systemdsystemunitdir" ; Not required
"--without-systemduserunitdir") ; Not required
#:phases
@@ -232,6 +232,7 @@
("pycairo" ,python-pycairo)
("pygobject" ,python-pygobject)
("python" ,python-wrapper)
+ ("libappindicator" ,libappindicator)
("libnm" ,network-manager)))
(synopsis "GTK+ Bluetooth manager")
(description "Blueman is a Bluetooth management utility using the Bluez
--
2.26.2
signature.asc
Description: OpenPGP digital signature
