Re: Nitrokey and udev rules

[Ricardo Wurmus]

Mike Gerwitz  writes:

> Looking through my notes, it looks like I symlinked
> `/run/current-system/profile/pcsc/drivers/' to `/var/lib/pcsc/drivers'.
> See Marius Bakke's message on ccid here:
>
>   <87vawczpb2.fsf@duckhunt.i-did-not-set--mail-host-address--so-tickle-me>:
>   https://lists.gnu.org/archive/html/guix-devel/2016-10/msg01433.html
>
> Can you see if that solves your problem?

This sounds like you’ve installed the package into the system profile.
If this works we should probably add a system service that takes care of
setting up this directory.

--
Ricardo

Re: Nitrokey and udev rules

[Mike Gerwitz]

Pierre:

On Thu, May 24, 2018 at 16:04:31 +0200, Pierre Neidhardt wrote:
> Mike Gerwitz  writes:

[...]

> I did:
>
>> sudo pcscd 
>> gpg --card-status
> gpg: selecting openpgp failed: No such device
> gpg: OpenPGP card not available: No such device
>
> Can you share your udev rules?

I don't have any udev rules that weren't included by default with
GuixSD.  The packages I installed are: gnupg, pcsc-lite, ccid, and
pinentry.

I used to know how to debug this problem very well back when I
contributed the pcsc-lite package, but it's been a couple years, but I
can try to help you through this.

Looking through my notes, it looks like I symlinked
`/run/current-system/profile/pcsc/drivers/' to `/var/lib/pcsc/drivers'.
See Marius Bakke's message on ccid here:

  <87vawczpb2.fsf@duckhunt.i-did-not-set--mail-host-address--so-tickle-me>:
  https://lists.gnu.org/archive/html/guix-devel/2016-10/msg01433.html

Can you see if that solves your problem?


While we're at it, here's my dmesg output for the Nitrokey Pro:

--8<---cut here---start->8---
[17145.084169] usb 6-2: new full-speed USB device number 9 using uhci_hcd
[17145.269203] usb 6-2: New USB device found, idVendor=20a0, idProduct=4108
[17145.269211] usb 6-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[17145.269215] usb 6-2: Product: Nitrokey Pro
[17145.269219] usb 6-2: Manufacturer: Nitrokey
[17145.269223] usb 6-2: SerialNumber: 3C75
[17145.276690] input: Nitrokey Nitrokey Pro as 
/devices/pci:00/:00:1d.0/usb6/6-2/6-2:1.0/0003:20A0:4108.0009/input/input21
[17145.336410] hid-generic 0003:20A0:4108.0009: input,hidraw0: USB HID v1.10 
Keyboard [Nitrokey Nitrokey Pro] on usb-:00:1d.0-2/input0
--8<---cut here---end--->8---

And `pcscd -f' output (which looks bad, but `gpg --card-status' does work):

--8<---cut here---start->8---
 ifdhandler.c:150:CreateChannelByNameOrChannel() failed
0023 readerfactory.c:1106:RFInitializeReader() Open Port 0x20 Failed 
(usb:20a0/4108:libudev:0:/dev/bus/usb/006/009)
0006 readerfactory.c:376:RFAddReader() Nitrokey Nitrokey Pro 
(3C75) init failed.
--8<---cut here---end--->8---

If you're still having a problem then we can continue from that point.

-- 
Mike Gerwitz
Free Software Hacker+Activist | GNU Maintainer & Volunteer
GPG: D6E9 B930 028A 6C38 F43B  2388 FEF6 3574 5E6F 6D05
https://mikegerwitz.com


signature.asc
Description: PGP signature

Re: [ANN] Emacs-Guix 0.4

[myglc2]

Hi Alex,

Thank you for this new release. I am enjoying the cool new features!

On 05/24/2018 at 20:21 Alex Kost writes:

[...]

> I recalled that C-u prefix is already occupied by specifying an
> arbitrary profile for the package commands.  So, I'm afraid instead of
> "C-u M-x guix-dependent-packages" there will be "M-x
> guix-direct-dependent-packages".
>
> Or maybe I should just break this dull "convention" (I mean "C-u" for
> profiles) as probably no one uses it anyway :-)

+1

FWIW, ISTM this use of "C-u" is more global than typical and thus feels
a bit counter-intuitive. Since you have made it very easy to jump
between profiles in *Guix Profiles* I think it would be good to switch
to using "C-u" for more command-specific modifications. This might also
help avoid "function bloat in emacs-guix."

HTH - George

Re: Simple configure-make-make_install with Guix

[Jone]

Thanks, Julien.
Minimal working variant:

(use-modules
 (ice-9 match)
 (srfi srfi-1)
 (guix gexp)
 (guix licenses)
 (guix build-system gnu)
 (guix packages)
 (gnu packages)
 (gnu packages gettext)
 (gnu packages pkg-config)
 (gnu packages glib)
 (gnu packages gtk)
 (gnu packages linux)
 (gnu packages audio))
(define-public gvolwheel
  (package
   (name "gvolwheel")
   (version "-1.0")
   (source (local-file "/home/jone/Desktop/gvolwheel-1.0" #:recursive? #t))
   (build-system gnu-build-system)
   ;; see https://github.com/pjotrp/guix-notes/blob/master/HACKING.org
   (arguments
'(#:phases
  (modify-phases %standard-phases
 (delete 'check
   (native-inputs
`(("pkg-config" ,pkg-config)
  ("intltool" ,intltool)
  ("gettext" ,gettext-minimal)))
   (inputs
`(("alsa-lib" ,alsa-lib)
  ("gtk+" ,gtk+)))
   (synopsis "Volume control")
   (description "ALSA mixer")
   (home-page "https://sourceforge.net/projects/gvolwheel;)
   (license gpl2)))
gvolwheel

What else should I fix in this package definition? 

Re: How to make a working ld in guix pure environment?

[Ludovic Courtès]

Hello,

Fis Trivial  skribis:

> I tried to use ld in guix pure environment, tested with bintuils,
> gcc-toolchain, ld-wrapper, and none of them work.
>
> Take the following trivial snippy (not opencl related) as an example:
>
> // main.c
> #include 
>
> int main()
> {
>   log1p(32);
> }
>
>
> To build it, one would do something similar to `ld -lm main.o` after
> compilation. But I got an error saying "ld: cannot find -lm".

You would need to use ld-wrapper, not ld, so that ld-wrapper sets the
RUNPATH appropriately.

But this won’t fix the problem above.  The problem above is that glibc
is not in the search path.  To fix that, a simple fix would be to add a
wrapper atop ld-wrapper (!) that would add “-L /gnu/store/…-glibc/lib”.

Perhaps there are more elegant ways to achieve it though.  How is ld
invoked?  Would it work to add that -L flag directly in the code that
invokes ld?

HTH!

Ludo’.

Re: emacs-dev: 'unpack' phase does not seem to preserve timestamps

[Ludovic Courtès]

Pierre Neidhardt  skribis:

> Ludovic Courtès  writes:
>
>> Nope.  Again, Git does not “preserve” timestamps (rightly so IMO), so
>> there’s nothing we can do.
>
> I think there is a misunderstanding: I'm working on a local folder, this
> has nothing to do with git.
>
> From my 'emacs-dev' package definition:
>
>   (source (local-file "/home/ambrevar/projects/emacs" #:recursive? #t))

Oh sorry.  It’s a similar kind of issue: when that directory is added to
the store, its timestamps are lost.  One workaround would be to create a
tarball out of it, and *then* add that tarball to the store.  Not
difficult to do, but a bit cumbersome.

Ludo’.

Re: Simple configure-make-make_install with Guix

[Julien Lepiller]

Le Thu, 24 May 2018 22:48:48 +,
Jone  a écrit :

> Hello! I'm wondering, how could I operate with unpacked sources?
> So far I see only this:
> 
>   guix build -f /home/jone/Desktop/template.scm
> guix build: error: #: not something we can build

Hi Jone,

your file should evaluate to a package, not simply define it.
http://www.gnu.org/software/guix/manual/html_node/Additional-Build-Options.html#Additional-Build-Options
has an example for how to use -f. In your case, adding gvolwheel at the
end of the file should work too. Also, you don't need guix' sources for
that.

> 
> Files:
> 1. template.scm
> (use-modules
>  (ice-9 match)
>  (srfi srfi-1)
>  (guix gexp)
>  (guix licenses)
>  (guix build-system gnu)
>  (guix packages)
>  (gnu packages)
>  (gnu packages glib)
>  (gnu packages gtk)
>  (gnu packages audio))
> (define-public gvolwheel
>   (package
>(name "gvolwheel")
>(version "-1.0")
>(source (local-file "/home/jone/Desktop/gvolwheel-1.0"
> #:recursive? #t)) (build-system gnu-build-system)
>(native-inputs
>   `(("pkg-config" ,pkg-config)))
>(inputs
>   `(("alsa-lib" ,alsa-lib)
> ("gtk+" ,gtk+)))
>(synopsis "test")
>(description "test")
>(home-page "https://sourceforge.net/projects/gvolwheel;)
>(license gpl2)))
> 
> 2. ls -1 .
> aclocal.m4
> AUTHORS
> ChangeLog
> config.guess
> config.h.in
> config.sub
> configure
> configure.ac
> COPYING
> depcomp
> INSTALL
> install-sh
> ltmain.sh
> Makefile.am
> Makefile.in
> missing
> mkinstalldirs
> NEWS
> pixmaps
> po
> README
> src
> 
> This is just an example (a little harder than "GNU Hello"). I would
> like to learn to build such things.

Simple configure-make-make_install with Guix

[Jone]

Hello! I'm wondering, how could I operate with unpacked sources?
So far I see only this:

  guix build -f /home/jone/Desktop/template.scm
guix build: error: #: not something we can build

Files:
1. template.scm
(use-modules
 (ice-9 match)
 (srfi srfi-1)
 (guix gexp)
 (guix licenses)
 (guix build-system gnu)
 (guix packages)
 (gnu packages)
 (gnu packages glib)
 (gnu packages gtk)
 (gnu packages audio))
(define-public gvolwheel
  (package
   (name "gvolwheel")
   (version "-1.0")
   (source (local-file "/home/jone/Desktop/gvolwheel-1.0" #:recursive? #t))
   (build-system gnu-build-system)
   (native-inputs
`(("pkg-config" ,pkg-config)))
   (inputs
`(("alsa-lib" ,alsa-lib)
  ("gtk+" ,gtk+)))
   (synopsis "test")
   (description "test")
   (home-page "https://sourceforge.net/projects/gvolwheel;)
   (license gpl2)))

2. ls -1 .
aclocal.m4
AUTHORS
ChangeLog
config.guess
config.h.in
config.sub
configure
configure.ac
COPYING
depcomp
INSTALL
install-sh
ltmain.sh
Makefile.am
Makefile.in
missing
mkinstalldirs
NEWS
pixmaps
po
README
src

This is just an example (a little harder than "GNU Hello"). I would like
to learn to build such things.

How to make a working ld in guix pure environment?

[Fis Trivial]

Hi, I'm working to get OpenCL into guix. In the OpenCL world, source
code for devices (such as GPU or FPGA or just CPU) is shipped as string
and embeded in the binary object, then latter compiled by OpenCL
implementation at runtime.

So, a correct linker at runtime is necessary for runing OpenCL
program, but I don't know how to achieve it.

I tried to use ld in guix pure environment, tested with bintuils,
gcc-toolchain, ld-wrapper, and none of them work.

Take the following trivial snippy (not opencl related) as an example:

// main.c
#include 

int main()
{
  log1p(32);
}


To build it, one would do something similar to `ld -lm main.o` after
compilation. But I got an error saying "ld: cannot find -lm".

I have a little chat with @lfam at IRC (thanks:) ). In order to clear
one of the confusions, please know that ld needed to be used standalone,
not with gcc-toolchain, since it's needed at target program runtime.

Please give me some advices about making a correct ld.

Thanks in advance.

Re: [ANN] Emacs-Guix 0.4

[Alex Kost]

Ludovic Courtès (2018-05-24 14:16 +0200) wrote:

> Hello!
>
> Alex Kost  skribis:
>
>> Ludovic Courtès (2018-05-23 17:30 +0200) wrote:
>
> [...]
>
>>> I think ‘guix-dependent-packages’ is going to be very useful.  I wonder
>>> if we could have ‘C-u guix-dependent-packages’ list only packages that
>>> are direct dependents?  That would be helpful in some situations.
>>
>> I agree!  Is there a shell command for this?  I mean I'd like to know
>> what Guile code can do this :-)
>
> No, there’s no such command.  Perhaps something to add to ‘guix refresh
> -l’, say ‘guix refresh -l direct’?

It would be good!

>> Currently, the following code is used to get dependent packages:
>>
>> (with-store store
>>   (run-with-store store
>> (mlet %store-monad ((edges (node-back-edges %bag-node-type
>> (all-packages
>>   (return (node-transitive-edges packages edges)
>
> ‘node-transitive-edges’ traverses the whole DAG, so you should simply
> call ‘edges’ instead.
>
> HTH!

Yes, now it's clear, thanks!

I recalled that C-u prefix is already occupied by specifying an
arbitrary profile for the package commands.  So, I'm afraid instead of
"C-u M-x guix-dependent-packages" there will be "M-x
guix-direct-dependent-packages".

Or maybe I should just break this dull "convention" (I mean "C-u" for
profiles) as probably no one uses it anyway :-)

-- 
Alex

Re: Nitrokey and udev rules

[Pierre Neidhardt]

Mike Gerwitz  writes:

> Have you started pcscd?  We don't yet have a service for it, so that
> needs to be done manually.  When I first log in, I run it as root (just
> `sudo pcscd'), and then `gpg --card-status` works as expected.
>
> Can you give that a try?

I did:

--8<---cut here---start->8---
> sudo pcscd 
> gpg --card-status
gpg: selecting openpgp failed: No such device
gpg: OpenPGP card not available: No such device
--8<---cut here---end--->8---

Can you share your udev rules?

-- 
Pierre Neidhardt


signature.asc
Description: PGP signature

Re: On network management and documenting nmcli

[Pierre Neidhardt]

Ludovic Courtès  writes:

> Perhaps we need another command, like ‘guix system show’, which would
> list the services used by a particular config?  Thoughts?

I like it, I think it's more relevant in terms of user interface than
what Swedebugia suggest with 'guix show %desktop-services', because in
the latter case the user must already know the variable, and it does not
tell anything about the current system.

-- 
Pierre Neidhardt


signature.asc
Description: PGP signature

Re: On network management and documenting nmcli

[Ludovic Courtès]

Pierre Neidhardt  skribis:

> Ludovic Courtès  writes:
>
>> If you’re using Emacs, the latest version of Emacs-Guix has this new
>> ‘guix-default-services’ command that does exactly what you’re
>> suggesting.
>
> It's great but it's not obvious enough for newcomers in my opinion.

Sure.  So there’s ‘guix system search’ and ‘guix system extension-graph’
which can help visualize what’s going on.

Perhaps we need another command, like ‘guix system show’, which would
list the services used by a particular config?  Thoughts?

Ludo’.

Re: emacs-dev: 'unpack' phase does not seem to preserve timestamps

[Pierre Neidhardt]

Ludovic Courtès  writes:

> Nope.  Again, Git does not “preserve” timestamps (rightly so IMO), so
> there’s nothing we can do.

I think there is a misunderstanding: I'm working on a local folder, this
has nothing to do with git.

From my 'emacs-dev' package definition:

(source (local-file "/home/ambrevar/projects/emacs" #:recursive? #t))

-- 
Pierre Neidhardt


signature.asc
Description: PGP signature

Re: [ANN] Emacs-Guix 0.4

[Ludovic Courtès]

Hello!

Alex Kost  skribis:

> Ludovic Courtès (2018-05-23 17:30 +0200) wrote:

[...]

>> I think ‘guix-dependent-packages’ is going to be very useful.  I wonder
>> if we could have ‘C-u guix-dependent-packages’ list only packages that
>> are direct dependents?  That would be helpful in some situations.
>
> I agree!  Is there a shell command for this?  I mean I'd like to know
> what Guile code can do this :-)

No, there’s no such command.  Perhaps something to add to ‘guix refresh
-l’, say ‘guix refresh -l direct’?

> Currently, the following code is used to get dependent packages:
>
> (with-store store
>   (run-with-store store
> (mlet %store-monad ((edges (node-back-edges %bag-node-type
> (all-packages
>   (return (node-transitive-edges packages edges)

‘node-transitive-edges’ traverses the whole DAG, so you should simply
call ‘edges’ instead.

HTH!

Ludo’.

Re: emacs-dev: 'unpack' phase does not seem to preserve timestamps

[Ludovic Courtès]

Pierre Neidhardt  skribis:

> Ludovic Courtès  writes:
>
>> Yes, that’s annoying, but that’s expected.  
>
> Right, but then how would it be possible to call `make install` without
> rebuilding everything all over again?
>
>> Perhaps the ‘unpack’
>> phase could automatically make the copy that it creates with
>> ‘copy-recursively’ writable?
>
> That wouldn't solve the issue: it would build but the point is to skip
> the compilation phase.
>
> Can you think of a way around this?

Nope.  Again, Git does not “preserve” timestamps (rightly so IMO), so
there’s nothing we can do.

Ludo’.

Re: Install new package in current generation?

[Ricardo Wurmus]

Jone  writes:

>> Also note that generations are generally lightweight
>
> It's right. But I have another problem with different generations:
> I build and install xfce4-cpugraph-plugin
>
> /gnu/store/qf0khvz9vj5lj4k9sfjxqlbs0kl8ssr3-xfce4-cpugraph-plugin-1.0.5/
> ├── lib
> │ └── xfce4
> │ └── panel
> │ └── plugins
> │ ├── libcpugraph.la
> │ └── libcpugraph.so
> ...
>
> of course xfce-panel does not see libcpugraph.so
>
> /gnu/store/rp40p839f65bzkkzrgcx7jbxb0c38nx4-xfce4-panel-4.12.0/
> ├── bin
> ...
> │ └── xfce4
> │ └── panel
> │ ├── migrate
> │ ├── plugins
> │ │ ├── libactions.la
> │ │ ├── libactions.so
> │ │ ├── libapplicationsmenu.la
> │ │ ├── libapplicationsmenu.so
> │ │ ├── libclock.la
> │ │ ├── libclock.so
> │ │ ├── libdirectorymenu.la
> │ │ ├── libdirectorymenu.so
> │ │ ├── liblauncher.la
> │ │ ├── liblauncher.so
> │ │ ├── libpager.la
> │ │ ├── libpager.so
> │ │ ├── libseparator.la
> │ │ ├── libseparator.so
> │ │ ├── libshowdesktop.la
> │ │ ├── libshowdesktop.so
> │ │ ├── libsystray.la
> │ │ ├── libsystray.so
> │ │ ├── libtasklist.la
> │ │ ├── libtasklist.so
> │ │ ├── libwindowmenu.la
> │ │ └── libwindowmenu.so
> │ ├── wrapper-1.0
> │ └── wrapper-2.0
> ...
>
> Problem! Probably I should to modify the "xfce" package itself, but it's
> not so easy for me.

Garbage collection won’t make a difference here.

According to the definition of the “xfce” and “xfce4-panel” packages,
plugins are searched for on directories listed in the environment
variable “X_XFCE4_LIB_DIRS”.  Try setting that to the directory
containing “xfce4-cpugraph-plugin” before Xfce is started.

--
Ricardo

Re: [racket-users] Using Racket's raco on on Guix(SD)

[Konrad Hinsen]

On 22/05/2018 15:42, Christopher Lemmer Webber wrote:


Unfortunately when I try to install packages with "raco pkg install"
I get errors like the following:


I filed a bug report about this problem a while ago:

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30680

Quote:

  I traced this back as far as I could by looking at the Racket compiler
  source code. Compilation generates a temporary file in the same
  directory where the result is supposed to go. If no errors occur, the
  temporary file is then renamed to become the output. The partial stack
  traces point to locations in the code that do a recursive traversal of
  a library in order to compile everything. Unfortunately, the part that
  decides where the output goes is not referenced in the stack trace.


I seem to remember a couple of packages failing altogether, though in
the present moment I think the result is bad performance due to not
being properly compiled, but I'm not really sure.


In my tests, all packages ended up working, but performance is indeed 
worse than with a Racket installation outside of Guix.


It would be nice if someone with more knowledge of Racket internals 
could give a hint or two for debugging this issue!


Konrad.