Re: Installation: Load non-free wifi firmware (iwlwifi)

[Chris Marusich]

Marius Bakke  writes:

> Chris Marusich  writes:
>
>> Hi Pierre,
>>
>> Pierre Neidhardt  writes:
>>
>>> linux-libre turns off the ability to load non-free firmware.  Why is
>>> it so?
>>
>> I did a little bit of searching on the Internet, and it seems to me like
>> the reason why Linux-libre turns off the ability to load non-free
>> firmware is because the project does not want to induce you to use
>> non-free software.
>
> This is not true.  After all, you may wish to load a firmware that you
> have developed yourself, but that is not possible either.  The problem
> is a limitation of the kernel interface and/or the deblobbing script:
>
> From an interview with Alexandre Oliva[0]:
>
> "Indeed, I became aware that some users have got the idea that blocking
> the loading of blobs is a feature. It's not; it's just a bug that's
> quite difficult to fix. The decision on whether or not to use a piece of
> software, be it Free or not, should belong to the users, and it's not
> our intent to make that difficult."
>
> [0] 
> https://www.fsfla.org/ikiwiki/blogs/lxo/2013-11-08-linux-libre-interview-by-bruce-byfield.en.html

Thank you for correcting my understanding!  I read the interview you
linked, as well as the original email thread referenced by the LWN
article [1].  My understanding is now that Linux-libre wants both (1) to
avoid inducing users to install non-free firmware (e.g. even logging the
non-free firmware name is something they would consider to be "inducing"
the user to install the non-free firmware), and (2) to allow users to
install whatever firmware they want, regardless of whether it is free or
non-free firmware.  However, due to the way the kernel Linux loads
firmware combined with the way that Linux-libre mangles the non-free
firmware identifiers to accomplish (1), users of Linux-libre currently
need to go through the extra effort of modifying the Linux-libre source
code (which they are free to do) if they want to load non-free firmware
(or firmware they have built themselves but have chosen not to share).

It is good to know that the Linux-libre project intends to allow users
to do whatever they want with the kernel.  I appreciate you taking the
time to clarify this for me!

Footnotes: 
[1]  https://lists.nongnu.org/archive/html/gnu-linux-libre/2010-12/msg00022.html

-- 
Chris


signature.asc
Description: PGP signature

Re: Locale error: Falling back to C locale

[Pierre Neidhardt]

Marius Bakke  writes:

> Pierre Neidhardt  writes:
>
>>> guix package -I local
>> glibc-utf8-locales   2.26.105-g0890d5379cout 
>> /gnu/store/3k6hl20c3b7big8ngrsl6mj9k8xav99d-glibc-utf8-locales-2.26.105-g0890d5379c
>>
>>> guix package -I emacs
>> emacs25.3out 
>> /gnu/store/y335nx4r08m6kg0yrna7spfwr4s05n36-emacs-25.3
>>
>> How do I check which glibc Emacs is using?
>> I can think of `ldd emacs` but... Where is ldd? :p
>
> "ldd" is in "glibc" :-)
>
> You can also use `guix gc -R /gnu/store/...-emacs-25.3 | grep glibc`.

Here:

> guix gc -R ${guix build emacs} | grep glibc
/gnu/store/4sqaib7c2dfjv62ivrg9b8wa7bh226la-glibc-2.26.105-g0890d5379c

>> A more general question: How do I find to which non-installed package a
>> filename belongs?
>
> Guix does not currently know anything about the files inside each
> package, I typically do a web search...

This is too bad, I believe it's an important feature for any package
manager.
As far as I can tell, `portage` and `pacman` can both do it.

Any plan regarding guix?

>> If Emacs happens to be using glibc 2.25, how could such a sitution occur
>> in the first place?  Why is glibc 2.25 needed at all?
>
> This situation can occur when you've installed emacs built against glibc
> 2.25 (which was the glibc in Guix until ~February), and then later
> updated "glibc-utf8-locales" to 2.26 which has incompatible locale data.
>
> Updating emacs would fix it in that case, since it would be built
> against the new glibc.

Running `guix package -u emacs` does nothing special, possibly because
it's already up to date.  Can I force a rebuild?

-- 
Pierre Neidhardt


signature.asc
Description: PGP signature

Re: Locale error: Falling back to C locale

[Marius Bakke]

Pierre Neidhardt  writes:

>> guix package -I local
> glibc-utf8-locales2.26.105-g0890d5379cout 
> /gnu/store/3k6hl20c3b7big8ngrsl6mj9k8xav99d-glibc-utf8-locales-2.26.105-g0890d5379c
>
>> guix package -I emacs
> emacs 25.3out /gnu/store/y335nx4r08m6kg0yrna7spfwr4s05n36-emacs-25.3
>
> How do I check which glibc Emacs is using?
> I can think of `ldd emacs` but... Where is ldd? :p

"ldd" is in "glibc" :-)

You can also use `guix gc -R /gnu/store/...-emacs-25.3 | grep glibc`.

> A more general question: How do I find to which non-installed package a
> filename belongs?

Guix does not currently know anything about the files inside each
package, I typically do a web search...

> If Emacs happens to be using glibc 2.25, how could such a sitution occur
> in the first place?  Why is glibc 2.25 needed at all?

This situation can occur when you've installed emacs built against glibc
2.25 (which was the glibc in Guix until ~February), and then later
updated "glibc-utf8-locales" to 2.26 which has incompatible locale data.

Updating emacs would fix it in that case, since it would be built
against the new glibc.

On GuixSD, you can use the 'locale-libc' operating-system parameter to
install locale data for multiple glibc versions to ease transition
between glibc updates.


signature.asc
Description: PGP signature

Re: Trouble with adding a package

[Ricardo Wurmus]

Hi Nadya,

> I'm so sorry. I did probably the dumbest mistake.
> I have package named "tcalc" and i was using "tcal" instead. Of course it
> was unknown package.

I’m glad you figured it out.

This happened to me more often than I’d like to admit.  Often this
message is just a symptom of a different error, but sometimes it really
does mean that you’ve mistyped the name of a package.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: Fail to configure home-directory

[Pierre Neidhardt]

Ludovic Courtès  writes:

> Oops, that’s a bug that should be fixed now:
>
>   
> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=82b71ac366ef154400653d264b46b7aa3520f393

It works, thanks!

>> Furthermore, I cannot mount a filesystem as /home:
>>
>> ```
>> (file-system
>>   (device "home")
>>   (title 'label)
>>   (mount-point "/home")
>>   (type "ext4"))
>> ```
>>
>> Running `guix system reconfigure' hangs after the `usermod...' changes.
>> Not sure about how to print more debug details.
>
> Does /var/log/messages or /var/log/shepherd.log have more info?

/var/log/shepherd.log does not log anything from the `guix system
reconfigure...`.

Reconfiguring with --verbosity=10 fails with the following:

|   lock released on 
`/gnu/store/qz82gly176p51n82j60rx9aadqxyrm0k-grub.cfg.lock'
|   building of `/gnu/store/xhg2rknd3yvhhb5vsalwwz14kf6184v1-grub.cfg.drv': 
goal destroyed
guix system: error: build failed: |   |   |   bind mounting `/dev/full' to 
`/gnu/store/xhg2rknd3yvhhb5vsalwwz14kf6184v1-grub.cfg.drv.chroot/dev/full'

I've managed to work around the issue:

- Moving the mount point of "LABEL=home" from /mnt to /foo did not work.

- After a failure, all subsequent `guix system reconfigure` fail, even
  the original, working configuration.
  
- After a fresh system boot, commenting out the filesystem configuration
  of LABEL=home works.  I rebooted after that.  From then, I re-added
  the entry for LABEL=home with the new mount point /home.  It worked
  after a reboot.

Something is fishiy...

-- 
Pierre Neidhardt


signature.asc
Description: PGP signature

Re: Package request inxi

[Pierre Neidhardt]

Oleg Pykhalov  writes:

> You could take a package recipe [1].  I don't think it's ready to push
> to Guix package collection, because it requires more ‘(substitute* …)’.
>
> [1]  
> https://notabug.org/wigust/guix-wigust/src/master/wigust/packages/inxi.scm

Nice, thanks!

-- 
Pierre Neidhardt


signature.asc
Description: PGP signature

Package request inxi

[Oleg Pykhalov]

Hello Pierre,

Pierre Neidhardt  writes:

> inxi: script to get system information
> Upstream URL: https://github.com/smxi/inxi

You could take a package recipe [1].  I don't think it's ready to push
to Guix package collection, because it requires more ‘(substitute* …)’.

[1]  https://notabug.org/wigust/guix-wigust/src/master/wigust/packages/inxi.scm

Oleg.


signature.asc
Description: PGP signature

Package requests: fortune, gifsicle, inxi, uncrustify, unrar, vsftp, xss-lock

[Pierre Neidhardt]

I'm missing the following packages in Guix.  If no one has planned to
package them yet, I'll give it a go.

fortune:The Fortune Cookie Program from BSD games
Upstream URL:   http://www.shlomifish.org/open-source/projects/fortune-mod/

gifsicle:   A powerful command-line program for creating, editing, 
manipulating and getting information about GIF images and animations
Upstream URL:   http://www.lcdf.org/gifsicle/

inxi:   script to get system information
Upstream URL:   https://github.com/smxi/inxi

uncrustify: A source code beautifier
Upstream URL:   http://uncrustify.sourceforge.net/

Description:The RAR uncompression program
Upstream URL:   http://www.rarlab.com/rar_add.htm
(Not sure about the licensing of this one: does not look free.  Is there
any free way to extract RAR?)

vsftp:  Very Secure FTP daemon
Upstream URL:   https://security.appspot.com/vsftpd.html
(It seems that there is not a single FTP server on Guix.  Strange... Can anyone
recommend anything better than vsftp for file sharing?  Not necessarily
FTP.)

xss-lock:   Use external locker as X screen saver
Upstream URL:   https://bitbucket.org/raymonad/xss-lock

-- 
Pierre Neidhardt


signature.asc
Description: PGP signature

Re: Missing pinentry-emacs for gpg-agent?

[Pierre Neidhardt]

Thinking more about it, wouldn't it make more sense to use several
outputs instead of several packages?
Is it possible to specify additional inputs for specific outputs?

-- 
Pierre Neidhardt


signature.asc
Description: PGP signature

Re: Missing pinentry-emacs for gpg-agent?

[Oleg Pykhalov]

Pierre Neidhardt  writes:

> Well, at least Arch Linux, Gentoo and Void Linux ship it!
> Not tht uncommon!

Then could you add a flag Vladimir talked about and send a patch?  ;-)

See https://www.gnu.org/software/guix/manual/html_node/Contributing.html

Thanks,
Oleg.


signature.asc
Description: PGP signature

Re: Test fail

[Maria Sidorova]

On 28.03.2018 09:33, Gábor Boskovits wrote:
2018-03-27 23:34 GMT+02:00 Maria Sidorova >:


Hello,

Running the test suite (`make check`) gives me one of the tests failed.

This is from test-suite.log

test-name: pivot-root
location: /home/masha/src/guix/tests/syscalls.scm:156
source:
+ (test-equal
+   "pivot-root"
+   #t
+   (match (pipe)
+          ((in . out)
+           (match (clone (logior CLONE_NEWUSER CLONE_NEWNS SIGCHLD))
+                  (0
+                   (dynamic-wind
+                     (const #t)
+                     (lambda ()
+                       (close in)
+                       (call-with-temporary-directory
+                         (lambda (root)
+                           (let ((put-old (string-append root
"/real-root")))
+                             (mount "none" root "tmpfs")
+                             (mkdir put-old)
+                             (call-with-output-file
+                               (string-append root "/test")
+                               (lambda (port) (display "testing\n"
port)))
+                             (pivot-root root put-old)
+                             (write (file-exists? "/test") out)
+                             (close out)
+                     (lambda () (primitive-exit 0
+                  (pid (close out)
+                       (let ((result (read in)))
+                         (close in)
+                         (and (zero? (match (waitpid pid)
+                                            ((_ . status)
+                                             (status:exit-val
status
+                              (eq? #t result
expected-value: #t
actual-value: #f
result: FAIL


The summary is:
# TOTAL: 777
# PASS:  772
# SKIP:  4
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

I'm novice in Guix, can anyone give me a clue?


Can you please write the type of system you are building guix on?
We recently discovered that on systemd based systems pivot-root
might fail because of shared mountpoints.


Ubuntu 16.04 (64)

Re: Test fail

[Gábor Boskovits]

2018-03-27 23:34 GMT+02:00 Maria Sidorova :

> Hello,
>
> Running the test suite (`make check`) gives me one of the tests failed.
>
> This is from test-suite.log
>
> test-name: pivot-root
> location: /home/masha/src/guix/tests/syscalls.scm:156
> source:
> + (test-equal
> +   "pivot-root"
> +   #t
> +   (match (pipe)
> +  ((in . out)
> +   (match (clone (logior CLONE_NEWUSER CLONE_NEWNS SIGCHLD))
> +  (0
> +   (dynamic-wind
> + (const #t)
> + (lambda ()
> +   (close in)
> +   (call-with-temporary-directory
> + (lambda (root)
> +   (let ((put-old (string-append root
> "/real-root")))
> + (mount "none" root "tmpfs")
> + (mkdir put-old)
> + (call-with-output-file
> +   (string-append root "/test")
> +   (lambda (port) (display "testing\n" port)))
> + (pivot-root root put-old)
> + (write (file-exists? "/test") out)
> + (close out)
> + (lambda () (primitive-exit 0
> +  (pid (close out)
> +   (let ((result (read in)))
> + (close in)
> + (and (zero? (match (waitpid pid)
> +((_ . status)
> + (status:exit-val status
> +  (eq? #t result
> expected-value: #t
> actual-value: #f
> result: FAIL
>
>
> The summary is:
> # TOTAL: 777
> # PASS:  772
> # SKIP:  4
> # XFAIL: 0
> # FAIL:  1
> # XPASS: 0
> # ERROR: 0
>
> I'm novice in Guix, can anyone give me a clue?
>
>
Can you please write the type of system you are building guix on?
We recently discovered that on systemd based systems pivot-root
might fail because of shared mountpoints.


> Thanks,
> Maria.
>
>