bug#40977: --load-path does not honor ~

[Hartmut Goebel]

Specifying the home directory using `~` (tilde) in `--load-path` does
not add the proper path to

Does not work (not who "mypackage":

  guix package --load-path=~/path/tp/my/project -A mypackage

Using $HOME (which si resolve by the shell works:

  guix package --load-path=$HOME/path/tp/my/project -A mypackage


I would expect ~ and ~username to work, too.

bug#40952: gnuradio-osmosdr: no hook into gnuradio block directory?

[Guillaume Le Vaillant]

Christopher Howard  skribis:

> I can see the osmosdr sink, insert it into the flow graph, and change
> the settings. However, when trying to build the flow graph, I receive
> the following error. Apparently you need to also update whatever
> environment variable controls the python module load path.
>
> <<< Welcome to GNU Radio Companion 3.8.0.0 >>>
>
> Block paths:
>   /home/christopher/.guix-profile/share/gnuradio/grc/blocks
>   /gnu/store/h2igg2gcbx6ds8wbvlkqz0dkplvwjxbd-gnuradio-
> 3.8.0.0/share/gnuradio/grc/blocks
>
> Generating: '/home/christopher/Scratch/test.py'
>
> Executing: /gnu/store/c0ysvb6s92kwwnmkgdhnspllxvd3f231-python-
> 3.7.4/bin/python3 -u /home/christopher/Scratch/test.py
>
> Warning: failed to XInitThreads()
> Traceback (most recent call last):
>   File "/home/christopher/Scratch/test.py", line 33, in 
> import osmosdr
> ModuleNotFoundError: No module named 'osmosdr'
>
 Done (return code 1)

I pushed a patch to set PYTHONPATH in the profile when gnuradio is
intalled (commit f03e5ca59f2f099693def2c8e6ff409e5b4ed40a). I guess
I had another installed package that had set it, because I didn't get
this error.
Could you try if it works for you?


signature.asc
Description: PGP signature

bug#40981: Graphical installer tests sometimes hang.

[Mathieu Othacehe]

Hello,

Graphical installer tests sometimes hang, before starting marionette
tests. See for instance:
https://ci.guix.gnu.org/log/d31s9sycixhvfak5lpzdg0mzvz5aa9av-gui-installed-os-encrypted.

Restarting tests just after a hang (on the same installed image),
sometimes work. I removed the "quiet" kernel argument to see what's
going on.

--8<---cut here---start->8---
[0.862608] Freeing unused kernel image memory: 1964K
[0.863177] Run /init as init process
GC Warning: pthread_getattr_np or pthread_attr_getstack failed for main thread
GC Warning: Couldn't read /proc/stat
Welcome, this is GNU's early boot Guile.
Use '--repl' for an initrd REPL.

loading kernel modules...
[0.915640] usbcore: registered new interface driver usb-storage
[0.917800] usbcore: registered new interface driver uas
[0.919569] hidraw: raw HID events driver (C) Jiri Kosina
[0.920519] usbcore: registered new interface driver usbhid
[0.921177] usbhid: USB HID core driver
[0.933506] isci: Intel(R) C600 SAS Controller Driver - version 1.2.0
[0.951303] PCI Interrupt Link [LNKD] enabled at IRQ 11
[0.970144] PCI Interrupt Link [LNKA] enabled at IRQ 10
[0.974033] virtio_blk virtio1: [vda] 4505600 512-byte logical blocks (2.31 
GB/2.15 GiB)
[0.976186]  vda: vda1 vda2

;; hanging here.
--8<---cut here---end--->8---

It seems that the boot freezes, soon after the initrd is started, and
before loading the boot script.

Mathieu

bug#40952: gnuradio-osmosdr: no hook into gnuradio block directory?

[Guillaume Le Vaillant]

Christopher Howard  skribis:

> Works now, thanks! Am able to feed data in from HackRF using osmosdr
> source block.
>
> (As a side note to posterity reading this: I have the hackrf system
> service set in my config.scm, as described in the hackrf package
> description.)

Ok, closing the bug.


signature.asc
Description: PGP signature

bug#22883: Authenticating a Git checkout

[Ludovic Courtès]

Hi there!

Ludovic Courtès  skribis:

>> You mentioned that checking signatures on commits is also kinda slow
>> because it’s sequential and not cached.  I don’t know what I really
>> want, but is there perhaps a way to aggregate signatures on past commits
>> so that the client’s work is reduced…?
>
> The caching implemented in 787766ed1e7f0806a98e696830542da528f957bb
> makes things acceptable: the first “make authenticate” run takes a bit
> more than two minutes to check all the commits starting from ‘v1.0.1’,
> but subsequent runs take a few seconds.
>
> I have plans to make things faster (independently of the cache) by doing
> OpenPGP signature verification entirely in Scheme instead of spawning
> ‘gpgv’ every time.  Again, we’ll have to get a prototype before we can
> tell whether it actually is faster.

I’ve been able to resume work on that in the ‘wip-openpgp’ branch:

  5a86b96f54 git-authenticate: Use (guix openpgp).
  4e66563449 openpgp: Add 'string->openpgp-packet'.
  dc0b5d5e01 openpgp: 'lookup-key-by-{id,fingerprint}' return the key first.
  740d804621 openpgp: 'verify-openpgp-signature' looks up by fingerprint when 
possible.
  0157c5ef7f openpgp: Add 'lookup-key-by-fingerprint'.
  31fc7cf080 openpgp: Store the issuer key id and fingerprint in 
.
  c22bede3ce openpgp: Decode the issuer-fingerprint signature subpacket.
  74d0d85e49 DRAFT Add (guix openpgp).

At this stage, ‘make authenticate’ uses the pure-Scheme implementation
(based on Göran Weinholt’s code, heavily modified).  It can authenticate
14K+ commits in ~20s instead of 4m20s on my laptop, which is really nice.

Signature verification in (guix openpgp) does just that: signature
verification.  It does not validate signature and key metadata, in
particular expiration date.  I guess it should at least error out when a
signature creation time is newer than its key expiration time.

It should also reject SHA1 signatures, at least optionally (I haven’t
checked whether our Git history has any of these).

I would very much welcome feedback and advice from an OpenPGP-savvy
person (I’ve Cc’d one to maximize the chances of success :-)).

Next steps:

  • Clean up the (guix openpgp) API a bit, for instance by using proper
SRFI-35 error conditions.  Perhaps handle v5 packets too.

  • Load the keyring from files in the repo, possibly in a dedicated
branch.

  • Load the list of authorized keys from the parent of the commit being
authenticated.

  • Generalize that to channels.

Ludo’.

bug#40977: --load-path does not honor ~

[zimoun]

Dear,

On Thu, 30 Apr 2020 at 10:17, Hartmut Goebel
 wrote:
>
> Specifying the home directory using `~` (tilde) in `--load-path` does
> not add the proper path to
>
> Does not work (not who "mypackage":
>
>   guix package --load-path=~/path/tp/my/project -A mypackage

It seems related to long vs short options, not to the expansion.


The short option works:

  guix package -L ~/path/to/my/project -A mypackage

but not the long '--load-path='.


> I would expect ~ and ~username to work, too.

Same for '~username'.


Well, I think it is related to bug #40549, see [1].

[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40549#14


All the best,
simon

bug#40977: --load-path does not honor ~

[Hartmut Goebel]

Hi,

This is not related to #40549.

The short option "-L ~/…" works, since thin this case the shell resolves the 
tilde. Whereas for the long-option the shell does not revolve the tilde, since 
the tilde is in the middle of the argument. Yu can verify this yourself easily:

$ python -c 'import sys; print(sys.argv)' ~
['-c', '/home/hartmut']
$ python -c 'import sys; print(sys.argv)' -L ~
['-c', '-L', '/home/hartmut']
$ python -c 'import sys; print(sys.argv)' ---long=~
['-c', '---long=~']


Proposed solution:

After processing options, guix need to "expanduser()" (as it is called
in Python) on all arguments which are paths.


-- 
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

bug#40977: --load-path does not honor ~

[zimoun]

On Thu, 30 Apr 2020 at 17:31, zimoun  wrote:
>
> Dear,
>
> On Thu, 30 Apr 2020 at 10:17, Hartmut Goebel
>  wrote:
> >
> > Specifying the home directory using `~` (tilde) in `--load-path` does
> > not add the proper path to
> >
> > Does not work (not who "mypackage":
> >
> >   guix package --load-path=~/path/tp/my/project -A mypackage
>
> It seems related to long vs short options, not to the expansion.

I am wrong. It is about the expansion. When using the short option,
then the expansion is done by the shell.

Note that it should be the same for '--manifest=~/path/to/manifests/'.
And all the '--long-options=~/path/to/something'.

Well, I do not find a function to expand tilde in Guile.


All the best,
simon

bug#40977: --load-path does not honor ~

[zimoun]

Dear Hartmut,

On Thu, 30 Apr 2020 at 18:42, Hartmut Goebel
 wrote:

> The short option "-L ~/…" works, since thin this case the shell resolves the 
> tilde. Whereas for the long-option the shell does not revolve the tilde, 
> since the tilde is in the middle of the argument. Yu can verify this yourself 
> easily:

Yes, you have right.


> Proposed solution:
>
> After processing options, guix need to "expanduser()" (as it is called
> in Python) on all arguments which are paths.

I agree.
I am not aware of such function in Guile.

All the best,
simon

bug#40985: building profile with 1 package

[Alexandru-Sergiu Marton]

For more than a week now, whenever I do a guix pull, it tells me it's
building a profile with 1 package. If I do other operations, such as
removing a package, it displays the number of packages installed in my
profile correctly (180-ish).

Here's the bit that it's outputting at the end of guix pull:

building CA certificate bundle...
building fonts directory...
building directory of Info manuals...
building profile with 1 package...
building /gnu/store/1lbks2qii5fdwigln34yd4cpvg5gxk7i-inferior-script.scm.drv...
building package cache...
building profile with 1 package...

I'm confused by this behaviour. It has not changed in the last two
`guix system reconfigure`s I did.

bug#40977: --load-path does not honor ~

[Danny Milosavljevic]

> After processing options, guix need to "expanduser()" (as it is called
> in Python) on all arguments which are paths.  

Please don't do it.

UNIX has its warts, and this is a well-known one (use ${HOME} instead).

If we did expanduser, I'm sure we'd be seeing bug reports about paths where
there was a tilde in the actual file name, NOT as a expanduser mark.

UNIX tools do what they do, and this wart is here to stay in a lot of tools.
Then at least make it consistent across all the tools UNIX has.


pgpOe1J_r6XzZ.pgp
Description: OpenPGP digital signature

bug#40977: --load-path does not honor ~

[Leo Famulari]

On Thu, Apr 30, 2020 at 07:34:39PM +0200, Danny Milosavljevic wrote:
> UNIX has its warts, and this is a well-known one (use ${HOME} instead).
> 
> If we did expanduser, I'm sure we'd be seeing bug reports about paths where
> there was a tilde in the actual file name, NOT as a expanduser mark.
> 
> UNIX tools do what they do, and this wart is here to stay in a lot of tools.
> Then at least make it consistent across all the tools UNIX has.

If it's true that this behaviour is more or less consistent in UNIX /
POSIX, then I agree with Danny that we should leave it as is. And, I
have noticed that ${HOME} is the way to go.

bug#40985: building profile with 1 package

[Leo Famulari]

On Thu, Apr 30, 2020 at 07:53:21PM +0300, Alexandru-Sergiu Marton wrote:
> For more than a week now, whenever I do a guix pull, it tells me it's
> building a profile with 1 package. If I do other operations, such as
> removing a package, it displays the number of packages installed in my
> profile correctly (180-ish).
> 
> Here's the bit that it's outputting at the end of guix pull:
> 
> building CA certificate bundle...
> building fonts directory...
> building directory of Info manuals...
> building profile with 1 package...
> building 
> /gnu/store/1lbks2qii5fdwigln34yd4cpvg5gxk7i-inferior-script.scm.drv...
> building package cache...
> building profile with 1 package...
> 
> I'm confused by this behaviour. It has not changed in the last two
> `guix system reconfigure`s I did.

Guix can manage multiple profiles, each with their own history, and that
is what's happening here. By default, there are two profiles: the one
that deals with Guix itself, and the one that contains your installed
packages.

`guix pull` uses the former, found at '~/.config/guix/current'.

You can interact with this profile using the '--profile' argument to
`guix package`. For example:

--
$ guix package --profile=$HOME/.config/guix/current --list-generations
Generation 115  Mar 27 2020 03:05:01
  guix  260eae7 out 
/gnu/store/ynihdaa8ripvrw2mzxdslhl3av938jpp-guix-260eae789
[...]
$ guix package --profile=$HOME/.config/guix/current --switch-generation=115
switched from generation 121 to 115
--

On the other hand, when you install packages, Guix uses the default
profile, which is found at ~/.guix-profile.

bug#40977: --load-path does not honor ~

[zimoun]

On Thu, 30 Apr 2020 at 19:53, Leo Famulari  wrote:

> > UNIX tools do what they do, and this wart is here to stay in a lot of tools.
> > Then at least make it consistent across all the tools UNIX has.

I do not have a clear opinion on the subject so I fall with the
Danny's wise opinion.

bug#40977: --load-path does not honor ~

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

Hartmut, Zimoun,

Hartmut Goebel 写道：
After processing options, guix need to "expanduser()" (as it is 
called

in Python) on all arguments which are paths.


If any Python (or other) software does this, it's broken.  File a 
bug there.


This is the wrong thing to do and makes the GNU system an 
inconsistent mess.  …OK, *more* of an inconsistent, loveable, mess 
;-)


It also makes

 $ sudo guix system --load-path=~/path/tp/my/project …

and

 $ sudo guix system -L ~/path/to/my/project -A mypackage …

suddenly result in different file names.

Please don't do it.

Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#40966: Missing substitutes on ci.guix.gnu.org?

[Leo Famulari]

On Thu, Apr 30, 2020 at 12:15:47AM +0200, Björn Höfling wrote:
> This is broken in a very strange, indeterministic way. At first I
> thought you were right. But with modified searches, there are several
> hits. For example this query:
> 
> https://ci.guix.gnu.org/search?query=^bor
> 
> has several hits, for example one for x86-64_linux from "8 Apr 04:09
> +0200".

Interesting... and strange. Thanks for digging in.

bug#40977: --load-path does not honor ~

[zimoun]

Hi Tobias,

On Thu, 30 Apr 2020 at 21:20, Tobias Geerinckx-Rice  wrote:
>
> Hartmut, Zimoun,
>
> Hartmut Goebel 写道：
> > After processing options, guix need to "expanduser()" (as it is
> > called
> > in Python) on all arguments which are paths.
>
> If any Python (or other) software does this, it's broken.  File a
> bug there.
>
> This is the wrong thing to do and makes the GNU system an
> inconsistent mess.  …OK, *more* of an inconsistent, loveable, mess
> ;-)
>
> It also makes
>
>   $ sudo guix system --load-path=~/path/tp/my/project …
>
> and
>
>   $ sudo guix system -L ~/path/to/my/project -A mypackage …
>
> suddenly result in different file names.

Sorry to be slow. Naive questions.

Do you mean the issue comes from who expand '~' (user vs sudo)?
Or do you mean refer to subfolder named '~, i.e., $HOME/foo/~/bar?

I should miss a point... about what is less or more inconsistent. :-)
Because it seems more based on conventions than on consistent inconsistencies.

About expansion, is it not the same question with
'--load-path=$HOME/path/to/' vs '-L $HOME/path/to/'?
About naming, is it possible to create a folder named '~' directly in $HOME?

Well, I am surely not enough skilled to have an opinion but I have
learnt something. :-)


> Please don't do it.

The fact that Guile does not have a built-in ``expand-tilde`` is a
strong indication to not do it. ;-)


Cheers,
simon

bug#40790: OOM error in graphical installer tests.

[Ludovic Courtès]

Hi,

Mathieu Othacehe  skribis:

>> Can we throw a little bit more memory at it?  :-)
>
> That's what I did with ae1a0f758 :)

Oh, good.

Next we should of course find out why ‘guix system init’ is consuming so
much memory.  I haven’t tried GC-profiling that yet, but here’s a rough
figure:

--8<---cut here---start->8---
$ GUIX_PROFILING=gc GUIX_PROFILING_EVENTS=exit guix system build -d --no-grafts 
gnu/system/examples/desktop.tmpl
/gnu/store/2by26x4pvvp9vi1f0lmrq39wqqkj0s0f-system.drv
Garbage collection statistics:
  heap size:98.80 MiB
  allocated:548.35 MiB
  GC times: 26
  time spent in GC: 1.84 seconds (36% of user time)
$ guix describe
Generacio 140   Apr 29 2020 19:43:22(nuna)
  guix 19987f5
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 19987f5efe0acb65918802681f3a18cbb6a07c2a
--8<---cut here---end--->8---

So at first sight, it’s surprising that it couldn’t fit in the VM with
800 MiB of RAM.  Oh well, we’ll see!

Nitpick: please include the canonical bug URL in commit logs rather
than a link to the mailing list, like so:

  Fixes .

That makes it easier to grep for fixed bugs.

> I didn't have the courage to bisect it, given how long this test
> is. Fixing it, I discovered two more issues:
>
> * "sherpherd services" test was failing because a wrong swap device was
>   used (fixed with be3abf28a).

Good catch!

> * I have some hangs when doing the final testing in marionette. Still
>   trying to understand why.

Oh.

Thank you!

Ludo’.

bug#28159: Closing bug #28159? Updater needs to support HTTP(S) servers

[Ludovic Courtès]

Hi Brice,

Brice Waegeneire  skribis:

> It looks like now most of the major updaters that relied on FTP (GNU,
> kernel.org, KDE and Gnbome) now support HTTP(S). I think we can close
> this
> bug.

Yup.  There’s still the ‘gnu-ftp’ and the ‘xorg’ updaters which,
according to ‘guix refresh --list-updaters’, account for 2.2% of the
packages.  We can change them later when it becomes necessary.

Closing, thank you!

Ludo’.

bug#40381: Guix shouldn't request substitutes for profile derivations

[Ludovic Courtès]

Hi,

pkill9  skribis:

> So it seems it tries to look for substitutes when the profile hooks are built,
> not when profile.drv is built.
>
> Here is the output without build hooks:
> ```
> itsme@antelope ~> guix environment --ad-hoc hello
> The following derivation will be built:
>/gnu/store/gkz9hzjpc9pj1np7vi5pwb4xhmssk55d-profile.drv
> building profile with 1 package...
> Welcome to fish, the friendly interactive shell
> itsme@antelope ~ [Guix env: /gnu/store/nsi48y..]>
> ```
>
> And here is output with build hooks:
> ```
> itsme@antelope ~> guix environment --ad-hoc man-db hello
> substitute: updating substitutes from 'https://berlin.guixsd.org'... 100.0%
> substitute: updating substitutes from 'https://mirror.hydra.gnu.org'... 100.0%
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> The following derivation will be built:
>/gnu/store/w623j5spid7kyxjdp6xbgxs2r5scpjkn-profile.drv
> The following profile hooks will be built:
>/gnu/store/14d1mgn1mwz66mj28rwjmnkddskf4zm0-info-dir.drv
>/gnu/store/7rrkqrdpxahk8g0927d56lpgz3n1kl6z-manual-database.drv
>/gnu/store/8h76m85hiyilv0mj053i9n7k2nxb0wf1-ca-certificate-bundle.drv
>/gnu/store/ia5d18hpmza375dizljqi2x12zlirwqi-fonts-dir.drv

Looks like manual-database.drv was the only hook not mark as
non-substitutable.

Fixed in 69de98391d720b92206d5e45072ecd3944d95774.

Thanks,
Ludo’.

bug#40603: SpaceFM

[Raghav Gururajan]

Hi Tobias!

OOPS! I have missed your replies as I am not subscribed to mail-list. Just saw
your replies when I revisited the bug thread via web.

Please ignore my report rearding icons. It was due to missing icon-theme
installed.

There were issues with privilege and disk management. I have sent fixes to
#40982 and #40922.

Thank you!

Regards,
RG.

bug#40977: --load-path does not honor ~

[Bengt Richter]

On +2020-04-30 22:54:47 +0200, zimoun wrote:
> Hi Tobias,
> 
> On Thu, 30 Apr 2020 at 21:20, Tobias Geerinckx-Rice  wrote:
> >
> > Hartmut, Zimoun,
> >
> > Hartmut Goebel 写道：
> > > After processing options, guix need to "expanduser()" (as it is
> > > called
> > > in Python) on all arguments which are paths.
> >
> > If any Python (or other) software does this, it's broken.  File a
> > bug there.
> >
> > This is the wrong thing to do and makes the GNU system an
> > inconsistent mess.  …OK, *more* of an inconsistent, loveable, mess
> > ;-)
> >
> > It also makes
> >
> >   $ sudo guix system --load-path=~/path/tp/my/project …
> >
> > and
> >
> >   $ sudo guix system -L ~/path/to/my/project -A mypackage …
> >
> > suddenly result in different file names.
> 
> Sorry to be slow. Naive questions.
> 
> Do you mean the issue comes from who expand '~' (user vs sudo)?
> Or do you mean refer to subfolder named '~, i.e., $HOME/foo/~/bar?
> 
> I should miss a point... about what is less or more inconsistent. :-)
> Because it seems more based on conventions than on consistent inconsistencies.
> 
> About expansion, is it not the same question with
> '--load-path=$HOME/path/to/' vs '-L $HOME/path/to/'?
> About naming, is it possible to create a folder named '~' directly in $HOME?
> 
> Well, I am surely not enough skilled to have an opinion but I have
> learnt something. :-)
>

FYA:(Amusement): man bash to see what more ~ can lead to ;-)
(scroll down or search for the "Tilde Expansion" section)

> 
> > Please don't do it.
> 
> The fact that Guile does not have a built-in ``expand-tilde`` is a
> strong indication to not do it. ;-)
> 
> 
> Cheers,
> simon
> 
> 
> 

-- 
Regards,
Bengt Richter