bug#39885: Bioconductor URI, fallback and time-machine

[Maxime Devos]

On 10-08-2022 21:44, Maxime Devos wrote:


On 10-08-2022 20:25, Ricardo Wurmus wrote:

- the updater doesn’t work on version expressions like (git-version
   "1.12" revision commit).  It expects to be able to replace literal
   strings.  Because of that my changes let the importer generate a
   string literal such as "1.12-0.cafebab" without a let-bound commit
   string.
I've a patch that implements replacing (revision "N") by (revision 
"N+1"), apparently it's not applied yet but let me search for it ...


Found it:



That patch series was written with Minetest / ContentDB and a new 
'latest-git' updater in mind, but the ContentDB and latest-git bits 
should be separable without much trouble.


Greetings,
Maxime.



OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#39885: Bioconductor URI, fallback and time-machine

[Maxime Devos]

On 10-08-2022 20:25, Ricardo Wurmus wrote:

- the updater doesn’t work on version expressions like (git-version
   "1.12" revision commit).  It expects to be able to replace literal
   strings.  Because of that my changes let the importer generate a
   string literal such as "1.12-0.cafebab" without a let-bound commit
   string.
I've a patch that implements replacing (revision "N") by (revision 
"N+1"), apparently it's not applied yet but let me search for it ...


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#57046: Spanish documentation uses exclusive language

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

Hi all,

On 2022-08-09 22:02, pelzflorian (Florian Pelz) wrote:

There has been plenty of debate elsewhere; no need to bother; I guess
there won’t be consensus. […] Could the bug be closed soon?


I'm torn.  I added & removed ‘-close’ a few times just now.

The initial post was doomed to be flame bate because of the subject 
matter, but was probably in good faith, apart from the title.


If it wasn't, it can be reinterpreted that way, and since when does 
authorial intent matter… :-)


But then, as deterministic dominoes in motion, we follow the unavoidable 
and predictable path downward.  Guix should follow my arbitrary grammar 
rules! — no it shouldn't.  Guix must listen only to my chosen 
demographic! — no it shouldn't.  Gender-neutral language is offensive to 
sexists! — good.


Notably scarce are arguments that actually stand on their own, that can 
help build a (new) consensus if you disagree with the current 
translation.


I don't speak much Spanish, but Ludo's suggestions sound great to me.  
How about we turn them into guidelines and add them to Contributing?


Kind regards,

T G-R

Sent from a Web browser.  Excuse or enjoy my brevity.

bug#39885: Bioconductor URI, fallback and time-machine

[Ricardo Wurmus]

Ricardo Wurmus  writes:

> zimoun  writes:
>
>> At the cost of more bandwidth, we could switch from url-fetch to
>> git-fetch.
>
> Let’s do it!  I’m tired of Bioconductor archive shenanigans messing with
> package availability.

I have finally taken the time to review this and implement a first draft
of a change to the bioconductor importer and updater.

There are some limitations:

- we cannot use the updater to go from “url-fetch” to “git-fetch”.
  That’s because “package-update” in (guix upstream) decides whether to
  use package-update/url-fetch or package-update/git-fetch based on the
  *current* package value’s origin fetch procedure.  For the switch we
  can hack around this (adding an exception for bioconductor packages),
  but there is no pretty way to do this in a generic fashion that could
  be committed.

  Perhaps we could operate on the url included in the 
  instead of looking at the *current* package value.  We’re only
  accessing “package” once in the url-fetch case, so maybe we can work
  around this problem.

- the repositories at https://git.bioconductor.org/package/NAME do not
  tag package versions.  The only method of organization is branches
  that are named after *Bioconductor releases* (not package releases),
  e.g. RELEASE_3_15.  We can only determine the package version by
  reading its DESCRIPTION file or by looking up the version index for
  all Bioconductor packages (we do that already).  This means that there
  could be different commits for the same package version in the same
  release branch — so we have to include the commit hash and a revision
  counter in the version string.

- the updater doesn’t work on version expressions like (git-version
  "1.12" revision commit).  It expects to be able to replace literal
  strings.  Because of that my changes let the importer generate a
  string literal such as "1.12-0.cafebab" without a let-bound commit
  string.

- “experiment” or “data” packages are not kept in Git.  They only exist
  as volatile tarballs that will be overwritten.  Thankfully, they don’t
  change all that often, so they have a good chance of making it into
  our archives.

- the above exception means that we need to litter the importer and
  updater code with extra checks.

With all these notes out of the way I’ll prepare a series of patches
next.

-- 
Ricardo

bug#56263: set-paths phase throws match-error "match" "no matching pattern" while cross-compiling a kernel module

[Maxime Devos]

On 27-06-2022 20:05, Pavel Shlyak wrote:

I don’t know the reason it happens. Maybe it’s somehow related to file-append 
hack that is used to set driver location in the repo. The other problem can be 
about
inputs or native-inputs being empty. Anyway, package definition looks fine to 
me and I suppose there’s a problem with set-paths phase.
Package definition:
https://git.pantherx.org/development/hardware/raspberry/-/blob/c9260f1720f63c409ef3ce88cefa677a21eb9e0b/reterminal.scm
Package ltr30x-linux-module builds successfully here with aarch64 host and it 
fails if I cross-compile it with x86_64 host
Error log here:
https://gist.github.com/shlyakpavel/b8b53e9bb4392cce1bba3c77c6d35d58


linux-module-build-cross quotes stuff:

  (define %build-host-inputs
    '#+(input-tuples->gexp build-inputs))

but 'input-tuples->gexp' already returns something quoted, so its quoted 
twice.


Try removing the 'quote' (i.e., ').

No relation to file-append as far as I can tell.


In rpi-kernel.scm, you are copying stuff from linux.scm without 
preserving copyright lines or the license header and the GPL license 
text is also removed; please respect the GPL license.


In the README, you are writing GUIX, but the standard capitalisation is 
Guix (sometimes guix, but never GUIX outside things like environment 
variable names).


License headers are missing from teterminal.scm, I recommend being 
explicit (gpl3 is kind of implied, but do you mean gpl3-only or gpl3+?)


Greetings,
Maxime.



OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#55848: AArch64 honeycomb machines aren’t building stuff

[Ricardo Wurmus]

Hi,

Ludovic Courtès  writes:

> Ludovic Courtès  skribis:
>
>> guix-daemon is configured to use the default substitute URLs,
>> https://ci.guix.gnu.org and https://bordeaux.guix.gnu.org, which we know
>> are unreachable.
>>
>> I’ve theoretically addressed this here:
>>
>>   
>> https://git.savannah.gnu.org/cgit/guix/maintenance.git/commit/?id=99bd9dc9001d6bea7480a7ce0e0e10ff78adb787
>>   
>> https://git.savannah.gnu.org/cgit/guix/maintenance.git/commit/?id=b0661cc7d6dd74b0aeac3b052a80a8a2fef2af9c
>>
>> I tried to reconfigure those boxes with ‘guix deploy’, but this is
>> currently on hold because ci.guix has run out of inodes…
>
> Time passed and I had kinda forgotten about it, but the problem remains.

I wrote this earlier:

> They should be using the local IP instead of routing through the
> internet, so /etc/hosts should contain an entry for
>
> 141.80.167.131 ci.guix.gnu.org

So running the daemon with “--substitute-urls=http://10.0.0.1” should
not be necessary.

-- 
Ricardo

bug#56263: set-paths phase throws match-error "match" "no matching pattern" while cross-compiling a kernel module

[Maxime Devos]

On 27-06-2022 20:05, Pavel Shlyak wrote:

Error log here:
https://gist.github.com/shlyakpavel/b8b53e9bb4392cce1bba3c77c6d35d58

I recommend a paste service such as paste.debian.net, it's doesn't have 
trackers or non-free javascript, and its implementation is apparently 
free software 

bug#57121: clojure-build-system fails to compile -- backtrace from language/tree-il/peval.scm

[Maxime Devos]

Can't reproduce after touching java-utils.scm.

Greetings,
Maxime



OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#57046: Spanish documentation uses exclusive language

[Csepp]

b...@bokr.com writes:

> On +2022-08-09 15:46:17 +0200, Ludovic Courtès wrote:
>> Hola,
>> 
>> "pelzflorian (Florian Pelz)"  skribis:
>> 
>> > * the main Spanish translation po/guix/es.po uses usuario
>> >
>> > * the French translation switches between “utilisateur·rices”,
>> >   “utilisatrices et utilisateurs” and more often masculine “utilisateurs”
>> >
>> > * the Portuguese, Russian, German translation use masculine (although at
>> >   least for German I use feminine in some examples)
>> >
>> > * German word for users is masculine Benutzer and feminine is
>> >   Benutzerinnen; there is a psychology study that Benutzer*innen is
>> >   perceived feminine while listing both masculine and feminine Benutzer
>> >   und Benutzerinnen is perceived as including men and women (a different
>> >   language and I might give too much weight to one scientific study)
>> >   
>> > 
>> 
>> Just like for French, my suggestion would be to use a mixture of several
>> techniques to achieve gender neutrality, probably in this order:
>> 
>>   • Using gender-neutral words—e.g., “personas” or “quién” rather than
>> “usuarios”.
>> 
>>   • Talking to the user: “puedes hacer …” rather than “usuarios pueden
>> hacer …”.
>> 
>>   • Using the -e suffix, which has the advantage of being concise and
>> readable, but potentially off-putting (at least today).
>> 
>>   • Using repetitions, “usuarias y usuarios”.
>> 
>> Latin languages (among others) are problematic but techniques like these
>> can get us a long way, and by mixing them we can avoid making the text
>> hard to read.
>> 
>> Ludo’.
>> 

> Hi,
>
> tl;dr:
>
> IMO this whole language neutering project, whose goal UIAM is
> purportedly to exclude exclusion, is self-contradictory.
> ...

https://en.wikipedia.org/wiki/Paradox_of_tolerance

ps.: edited by the bottom reply inquisition :)

bug#56263: set-paths phase throws match-error "match" "no matching pattern" while cross-compiling a kernel module

[Pavel Shlyak]

I just checked, this one is still relevant as of 
b21d05d232ec0aba5abec20e83cc52c1d5163cc3

bug#57121: clojure-build-system fails to compile -- backtrace from language/tree-il/peval.scm

[Maxime Devos]

I started with a guix checkout at commit 
d519305d83d08058e4def2c4d72fe62102d9599d. Everything was compiled, 
according to "make".


Then I switched to current master: b21d05d232ec0aba5abec20e83cc52c1d5163cc3.

Now I get the following error:


In language/tree-il/peval.scm:
    799:6 19 (loop _ # #f effect)
  1661:48 18 (loop _ _ _ effect)
In srfi/srfi-1.scm:
   586:17 17 (map1 (# #(const documentation)> #clojure-build-system.")>))

In language/tree-il/peval.scm:
   853:11 16 (loop _ _ #f value)
   346:22 15 (visit-operand #< var: #< name: install 
gensym: #{ g377}# refcount: 2 set?: #f> sym: #{install 412}# visit: 
#counter ctx)> source: #java-utils) install-jars) (const "./")))> visit-count: 1 use-count: 0 
copyable?: #t residual-value: #f constant-value: #f alias: #f> _ value 
_ _)
  1286:21 14 (loop _ # #< effort: 
# size: #0> continuation: # recursive?: #t data: 
#< var: #< name: install gensym: #{ g377}# refcount: 2 
set?: #f> sym: #{install 412}# visit: #language/tree-il/peval.scm:977:40 (exp counter ctx)> source: #(primcall values (call (@ (guix build java-utils) install-…> …)

In srfi/srfi-1.scm:
   586:17 13 (map1 (#install-jars) (const "./"))>))

In language/tree-il/peval.scm:
  1625:20 12 (loop _ # #< effort: 
# size: #0> continuation: # recursive?: #t data: 
#< var: #< name: install gensym: #{ g377}# refcount: 2 
set?: #f> sym: #{install 412}# visit: #language/tree-il/peval.scm:977:40 (exp counter ctx)> source: #(primcall values (call (@ (guix build java-utils) install-…> …)
   981:20 11 (loop _ # #< effort: 
# size: #value: 20> continuation: # recursive?: #f data: 
#(((jar-directory) #f #f #f () (t413)) (lambda () (lambda-case ((() #f 
#f (#t (#:outputs outputs #f)) ((const #f)) (t414)) (let (share) 
(t415) ((call (@ (guile) string-append) (call (@ (guile) assoc-ref) 
(lex…> …)
    799:6 10 (loop #(#:outputs outputs #f)) ((const #f)) (t414)) (let (share) (t415) 
((call (@ (guile) string-append) (call (@ (guile) assoc-ref) (lexical 
outputs t414) (const "out")) (const "/share/java"))) (seq (call (@ 
(guile) for-each) (lambda () (lambda-case (((f) #f #f #f () (t416)) 
(call (@ (guix build utils) install-file) (lexical f t416) (lexical 
share t415) (call (@ (guix build utils) find-files) (lex…> …)
  1699:60  9 (loop _ # #< 
effort: # size: #7f81d9876700 value: 20> continuation: # 
recursive?: #f data: #(lambda-case (((jar-directory) #f #f #f () (t413)) (lambda () 
(lambda-case ((() #f #f (#t (#:outputs outputs #f)) ((const #f)) 
(t414)) (let (share) (t415) ((call (@ (guile) string-append) (call (@ 
(guile) assoc-ref) (le…> …)

In srfi/srfi-1.scm:
   586:17  8 (map1 (#f))
In language/tree-il/peval.scm:
  1691:38  7 (new-sym _)
In ice-9/boot-9.scm:
  1685:16  6 (raise-exception _ #:continuable? _)
  1685:16  5 (raise-exception _ #:continuable? _)
  1780:13  4 (_ #< components: 
(#<> #< origin: "cdr"> #< message: 
"Wrong type argument in position 1 (expecting pair): ~S"> #< 
irritants: (#f)> #< kind: wrong-type-arg 
args: ("cdr" "Wrong type argument in position 1 (expecting pair): ~S" 
(#f) (#f))>)>)

In guix/build/compile.scm:
    191:6  3 (_ _ . _)
In ice-9/boot-9.scm:
  1747:15  2 (with-exception-handler #ice-9/boot-9.scm:1831:7 (exn)> _ #:unwind? _ #:unwind-for-type _)

In guix/build/compile.scm:
   194:22  1 (_)
In unknown file:
   0 (make-stack #t)
Looking at language/tree-il/peval.scm 1691:38, it appears that somehow 
the 'old' symbol does not appear in the environment.


For a minimal test case, remove everything but the 'define-module' and 
the '(define-with-docs install [...])'.


Looks like something is going wrong with 'define-with-docs' (without 
-with-docs and without the docstring, it compiles fine).


Greetings,
Maxime.



OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#57120: guix refresh -u fails in pre-inst-env

[Pavel Shlyak]

test@guix_test ~/guix$ ./pre-inst-env guix refresh -u feathernotes
gnu/packages/task-management.scm:293:13: feathernotes: updating from version 
0.10.0 to version 1.0.0...
guix refresh: error: mkstemp: Read-only file system

Guix system is at b21d05d232ec0aba5abec20e83cc52c1d5163cc3

bug#52029: wterm fails to start on core-updates-frozen

[Joshua Branson via Bug reports for GNU Guix]

"("  writes:

> On Sat Aug 6, 2022 at 2:38 AM BST, Tobias Geerinckx-Rice wrote:
>> Either of you feel like practicing a 'simple deprecation'?  ;-)
> Done at #57014 :)
>

I am going to try to close this bug report.  All further bug reports
should look at 57014.  If I cannot close the bug report.  Will someone
else please close this bug?

Thanks,
Joshua

>
> -- (

bug#54447: cuirass: missing derivation error

[Maxime Devos]

On 10-08-2022 11:43, Maxime Devos wrote:

Here's another instance: https://ci.guix.gnu.org/eval/528710


More information:

 * non-ASCII does not seem to be set up (see: ?) (looks irrelevant)
 * here are connection failures

Log:


substitute:
substitute: updating substitutes from 'http://141.80.167.131'...   0.0%guix 
substitute: warning: 141.80.167.131: connection failed: Connection refused
substitute:
cannot build missing derivation 
?/gnu/store/4gqj2byvj9zz30wzvwkbijpya3vn1bjw-rust-dogged-0.2.0.drv?


Greetings,
Maxime.


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#57093: 'guix style --whole-file' hangs indefinitely if parenthesis is unmatched

[Ludovic Courtès]

Hi Mohammed,

Mohammed AMAR-BENSABER  skribis:

> guix style --whole-file package.scm hangs indefinitely if parenthesis is 
> unmatched. Relevant commit a15542d26df42dabdb5e2f76d150ae200230c3b0.

Oops, fixed in ebda12e1d2c64480bb7d5977e580d8b2eabeb503:

--8<---cut here---start->8---
$ ./pre-inst-env guix style -f /tmp/t.scm
/tmp/t.scm:25:0: error: unexpected end of file
hint: Did you forget a closing parenthesis?
--8<---cut here---end--->8---

Thanks for your report!

Ludo’.

bug#57095: another "inappropriate ioctl" bug :)

[Ludovic Courtès]

Hi!

Josselin Poiret  skribis:

> We also use a big wrapping `with-error-handling` to display errors
> properly in the case when they are not caught.  The difference is that
> `with-error-handling` adds a non-unwinding handler, while catch is
> unwinding.  My first thought was that non-unwinding handlers, even outer
> ones would get priority over unwinding ones, since once the stack's
> unwound you can't really go back (I have no idea if that last part is
> actually true).  In practice this is actually false, I tested with a
> very simple example, but that lead me to test by setting `#:unwind? #t`
> for the `guard*` definition in guix/ui.scm and the issue went away, so I'm
> clueless as to why this happens.  What seems weird is that the error is
> not caught at all!

The inner handler, even if it’s unwinding and the outer one is not,
appears to have higher precedence:

--8<---cut here---start->8---
scheme@(guix read-print)> (with-exception-handler (lambda args (pk 'outer args))
(lambda ()
  (with-exception-handler
  (lambda args (pk 'inner args))
(lambda()
  (rmdir "/"))
#:unwind? #t))
#:unwind? #f)

;;; (inner (#< components: (#<> #< 
origin: "rmdir"> #< message: "~A"> #< irritants: ("Device or 
resource busy")> #< kind: system-error args: 
("rmdir" "~A" ("Device or resource busy") (16))>)>))
$17 = (#< components: (#<> #< origin: 
"rmdir"> #< message: "~A"> #< irritants: ("Device or resource 
busy")> #< kind: system-error args: ("rmdir" "~A" 
("Device or resource busy") (16))>)>)
scheme@(guix read-print)> (with-exception-handler (lambda args (pk 'outer args))
(lambda ()
  (catch 'system-error
(lambda ()
  (rmdir "/"))
(lambda args
  (pk 'inner args
#:unwind? #f)

;;; (inner (system-error "rmdir" "~A" ("Device or resource busy") (16)))
$18 = (system-error "rmdir" "~A" ("Device or resource busy") (16))
--8<---cut here---end--->8---

This appears to work:

--8<---cut here---start->8---
scheme@(guile-user)> ,use(guix build syscalls)
scheme@(guile-user)> (terminal-columns)
$19 = 119
scheme@(guile-user)> ,use(guix ui)
scheme@(guile-user)> (with-error-handling (terminal-columns))
$20 = 119
scheme@(guile-user)> (terminal-columns (open-input-string ""))
$21 = 143
scheme@(guile-user)> (with-error-handling (terminal-columns (open-input-string 
"")))
$22 = 143
--8<---cut here---end--->8---

Needs more investigation…

Ludo’.

bug#57095: another "inappropriate ioctl" bug :)

[Josselin Poiret via Bug reports for GNU Guix]

Hi!

Csepp  writes:

> ```
> ./pre-inst-env guix import pypi -r linode-cli | tee -a 
> gnu/packages/python-xyz.scm
>
> ...
> In guix/build/syscalls.scm:
>   2284:35  1 (_)
>2273:8  0 (terminal-window-size _)
>
> guix/build/syscalls.scm:2273:8: In procedure terminal-window-size:
> In procedure terminal-window-size: Inappropriate ioctl for device
> ```
>
> I assume the progress bar code does not gracefully handle the very
> common case when stdout is not a terminal.

There is some code in place to handle this issue, and it works most of
the time, but not here.  The issue is that we handle any error coming
from ioctl by first throwing a `'system-error`, and handling it with a
`catch` that checks whether the errno is ENOTTY (and deprecated
equivalents) and in that case falls back to a good default.  In the case
where the error is not of that type, it is rethrown.  This works well in
most cases, but here comes the Guile shenanigans:

We also use a big wrapping `with-error-handling` to display errors
properly in the case when they are not caught.  The difference is that
`with-error-handling` adds a non-unwinding handler, while catch is
unwinding.  My first thought was that non-unwinding handlers, even outer
ones would get priority over unwinding ones, since once the stack's
unwound you can't really go back (I have no idea if that last part is
actually true).  In practice this is actually false, I tested with a
very simple example, but that lead me to test by setting `#:unwind? #t`
for the `guard*` definition in guix/ui.scm and the issue went away, so I'm
clueless as to why this happens.  What seems weird is that the error is
not caught at all!

Does anyone have a clue?

Best,
-- 
Josselin Poiret

bug#57117: ‘guix deploy’ doesn’t honor (build-locally? #f) in the presence of grafts

[Ludovic Courtès]

In current ‘master’ (ca. f0ae9da3210cc6d87ca519545203daf9751f3465), when
passed a set of ‘machine-ssh-configuration’ machines, ‘guix deploy’ ends
up trying to build locally even if those machines have:

  (build-locally? #f)

Passing ‘--no-grafts’ works around the problem.

Ludo’.

bug#55848: AArch64 honeycomb machines aren’t building stuff

[Ludovic Courtès]

Hi!

Ludovic Courtès  skribis:

> guix-daemon is configured to use the default substitute URLs,
> https://ci.guix.gnu.org and https://bordeaux.guix.gnu.org, which we know
> are unreachable.
>
> I’ve theoretically addressed this here:
>
>   
> https://git.savannah.gnu.org/cgit/guix/maintenance.git/commit/?id=99bd9dc9001d6bea7480a7ce0e0e10ff78adb787
>   
> https://git.savannah.gnu.org/cgit/guix/maintenance.git/commit/?id=b0661cc7d6dd74b0aeac3b052a80a8a2fef2af9c
>
> I tried to reconfigure those boxes with ‘guix deploy’, but this is
> currently on hold because ci.guix has run out of inodes…

Time passed and I had kinda forgotten about it, but the problem remains.

I’m currently reconfiguring pankow and grunewald⁰ from berlin with ‘guix
deploy’ to include the fix above¹, but it’s gonna take a while as it’s
currently building GCC…

To do that, I had to ‘herd stop guix-daemon’ (thereby stopping
‘cuirass-remote worker’ as well) and run guix-daemon by hand with
‘--substitute-urls=http://10.0.0.1’.

While doing that with Guix 9e4632081ff31bf0d1715edd66f514614c6dc4bb, I
found another bug² (yup, it does look like an endless quest, even more
so that I’ll soon be going AFK and it’s not clear that things will be
settled by then!).

Cheers,
Ludo’, aka. el Quijote.

⁰ More on kreuzberg in a separate message…

¹ For the record, previously ‘guix deploy’ had a bug whereby running it
  from an x86_64 box like berlin would lead it to send x86_64 binaries
  (instead of AArch64 binaries) to the machines.  This was fixed in
  7046e777212233b89df68379c270b448c45195ce:
  .

² https://issues.guix.gnu.org/57117

bug#57046: Spanish documentation uses exclusive language

[pelzflorian (Florian Pelz)]

"pelzflorian (Florian Pelz)"  writes:
> Ludovic Courtès  writes:
>>   • Using repetitions, “usuarias y usuarios”.
> It depends, but I think inclusiveness in technical manual sections is
> not important enough to justify such trade-offs (for the German

I now changed parts of the German website translation on Weblate to use
repetition because I agree with inclusiveness in invitations.

Spanish translators may consider this too.

Could the bug be closed soon?

Regards,
Florian

bug#57110: home: services: Broken openssh service.

[Maxim Cournoyer]

Hi,

Oleg Pykhalov  writes:

> home ssh service is broken on:
>
> $ guix describe
> Generation 33 Aug 10 2022 10:50:55(current)
>   guix b72459a
> repository URL: https://git.savannah.gnu.org/git/guix.git
> branch: master
> commit: b72459a861d7029d69e9e3ffe3dd411b452e26de
>
>
> home.scm:
>
> (use-modules (gnu services)
>  (gnu home services ssh))
>
> (home-environment
>  (services
>   (list
>(service home-openssh-service-type
> (home-openssh-configuration
>  (hosts
>   (list
>(openssh-host (name "git.sv.gnu.org")
>  (user "wigust")
>
> $ guix home build home.scm
> /home/oleg/home.scm:11:15: error: invalid value unset for field 
> 'address-family'

Fixed with d9a0ccf13f.  Sorry for the breakage!

Maxim

bug#57071: Xscreensaver not working since latest patch

[Rick Huijzer]

Hi Roman and Ludo,

It seems that xscreensaver-auth needs to be setuid instead of the main
xscreensaver binary. The screen-locker-service in xorg.scm sets the
provided package setuid and sets the required pam configuration for the
provided package. The problem is that the pam configuration needs to be set
for xscreensaver (/etc/pam.d/xscreensaver) and setuid needs to be set for
xscreensaver-auth.

Interestingly when I setuid xscreensaver-auth manually I run into the
following when unlocking:
Aug 10 13:35:02 localhost unix_chkpwd[2197]: check pass; user unknown
Aug 10 13:35:02 localhost unix_chkpwd[2197]: password check failed for user
(rhuijzer)
Aug 10 13:35:02 localhost xscreensaver-auth: pam_unix(xscreensaver:auth):
authentication failure; logname= uid=1000 euid=1000 tty=:0 ruser= rhost=
 user=rhuijzer

But this might be fixed in time by [RFC PATCH] gnu: linux-pam: Change path
to unix_chkpwd helper .

I don't know how to fix this elegantly, maybe create a dedicated service
for xscreensaver instead of the standard screen-locker-service?

Thanks,

Op wo 10 aug. 2022 om 09:14 schreef Roman Scherer <
roman.sche...@burningswell.com>:

>
> Hi Ludo and Rick,
>
> sorry for the trouble. I'm running xscreensaver on a foreign distro and
> did not notice this. Probably because somehow my screen wasn't locked,
> but still showing random screensavers.
>
> However, now that I tried the `xscreensaver-command -lock` command I see
> a dialog with a "Password initialization failed" message.
>
> The xscreensave logs also show this:
>
> xscreensaver-auth: 06:45:55: OOM: /proc/99677/oom_score_adj: Permission
> denied
> xscreensaver-auth: 06:45:55:   To prevent the kernel from randomly
> unlocking
> xscreensaver-auth: 06:45:55:   your screen via the out-of-memory killer,
> xscreensaver-auth: 06:45:55:   "xscreensaver-auth" must be setuid root.
> xscreensaver-auth: 06:46:06: PAM: warning: /etc/pam.d/xscreensaver does
> not exist.
> xscreensaver-auth: 06:46:06: PAM: password authentication is unlikely to
> work.
> xscreensaver-auth: 06:46:15: PAM: warning: /etc/pam.d/xscreensaver does
> not exist.
> xscreensaver-auth: 06:46:15: PAM: password authentication is unlikely to
> work.
>
> When the dialog popped up, I had to switch to a terminal and kill
> xscreensaver to be able to access my desktop again.
>
> Should we revert it, until we figured out what's necesarry to get this
> working again?
>
> r0man
>
> Ludovic Courtès  writes:
>
> > Hi Rick,
> >
> > Rick Huijzer  skribis:
> >
> >> The latest xscreensaver patch 
> rendered
> >> xscreensaver unusable on my systems. When I try to unlock my screen I am
> >> greeted with the message 'xscreensaver: don't login as root', even
> though I
> >> don't invoke it as root.
> >>
> >>
> >> $xscreensaver-command -lock
> >> Aug  9 08:45:22 localhost shepherd[1]: [slim] xscreensaver-gfx:
> 08:45:22:
> >> 1: running as root: not launching hacks.
> >> Aug  9 09:10:29 localhost shepherd[1]: [slim] xscreensaver-command:
> locking
> >> Aug  9 09:10:32 localhost shepherd[1]: [slim] xscreensaver-gfx:
> 09:10:32:
> >> 0: running as root: not launching hacks.
> >>
> >> When I remove the
> >> (screen-locker-service xscreensaver)
> >> I run into all kinds of set-uid problems.
> >
> > Sorry about that, I built it during review but did not actually run it.
> >
> > One effect of ‘screen-locker-service’ is to make the program setuid-root
> > so that it can authenticate users.  It would seem that something changed
> > in xscreensaver in that area; quoth ‘driver/subprocs.c’:
> >
> >   if (getuid() == (uid_t) 0 || geteuid() == (uid_t) 0)
> > /* Prior to XScreenSaver 6, if running as root, we would change
> the
> >effective uid to the user "nobody" or "daemon" or "noaccess",
> >but even that was just encouraging bad behavior.  Don't log in
> >as root. */
> > {
> >   fprintf (stderr, "%s: %d: running as root: not launching
> hacks.\n",
> >blurb(), ssi->number);
> >   screenhack_obituary (ssi, "", "XScreenSaver: Don't log in as
> root.");
> >   goto DONE;
> > }
> >
> > OTOH the ‘disavow_privileges’ function is supposed to drop root
> > privileges early on.
> >
> > So I’m not sure how it’s supposed to be run.  R0man, ideas?
> >
> > Thanks,
> > Ludo’.
>


-- 
Met vriendelijke groet,

Rick Huijzer

bug#57110: home: services: Broken openssh service.

[Oleg Pykhalov]

home ssh service is broken on:
--8<---cut here---start->8---
$ guix describe
Generation 33   Aug 10 2022 10:50:55(current)
  guix b72459a
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: b72459a861d7029d69e9e3ffe3dd411b452e26de
--8<---cut here---end--->8---

home.scm:
--8<---cut here---start->8---
(use-modules (gnu services)
 (gnu home services ssh))

(home-environment
 (services
  (list
   (service home-openssh-service-type
(home-openssh-configuration
 (hosts
  (list
   (openssh-host (name "git.sv.gnu.org")
 (user "wigust")
--8<---cut here---end--->8---

--8<---cut here---start->8---
$ guix home build home.scm
/home/oleg/home.scm:11:15: error: invalid value unset for field 'address-family'
--8<---cut here---end--->8---

Oleg.


signature.asc
Description: PGP signature

bug#57109: arm-none-eabi-toolchain atomic support is broken

[Jean Pierre De Jesus DIAZ via Bug reports for GNU Guix]

The atomic supports for this toolchain is broken:

A minimal test case:

guix shell arm-none-eabi-toolchain -- \
   bash -c "echo '#include ' \
 | arm-none-eabi-gcc -x c -o /dev/null -c -"

Something similar found online:

https://sourceware.org/legacy-ml/newlib/2017/msg00150.html

However no solution.

This happens with all versions of the arm-none-eabi-toolchain
packages.

—
Jean-Pierre De Jesus DIAZ

bug#53210: installer: referring to N-1 guix is problematic.

[Mathieu Othacehe]

Hey,

> Let me know if you have comments!

Thanks for taking care of this!

Looks like we have a small regression on 'system-tests and 'guix
specifications:

https://ci.guix.gnu.org/eval/528053/log/raw
https://ci.guix.gnu.org/eval/528056/log/raw

I think this is because channel-source->package is given a raw directory
as source in (gnu ci) while this procedure expects either a channel or a
lowerable object.

Thanks,

Mathieu

bug#54447: cuirass: missing derivation error

[Maxime Devos]

Here's another instance: https://ci.guix.gnu.org/eval/528710



OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#56733: Tryton LTS

[Hartmut Goebel]

For the records: Tryton 6.0 was available up to at least 2022-08-09 
(commit 02de6a59813df9dd839117669535118f1b798ed4). So versions and 
hashes can be picked from there. Or even the tryton-scm at that version 
could be used as a base for tryton-lts.scm.


Please also note: The packages can be kept up-to-date easily using my 
tooling at https://codeberg.org/htgoebel/tryton-guix-helpers (and the 
upcoming “refresh to version“ feature).


--
Regards
Hartmut Goebel

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

bug#57071: Xscreensaver not working since latest patch

[Roman Scherer]

Hi Ludo and Rick,

sorry for the trouble. I'm running xscreensaver on a foreign distro and
did not notice this. Probably because somehow my screen wasn't locked,
but still showing random screensavers.

However, now that I tried the `xscreensaver-command -lock` command I see
a dialog with a "Password initialization failed" message.

The xscreensave logs also show this:

xscreensaver-auth: 06:45:55: OOM: /proc/99677/oom_score_adj: Permission denied
xscreensaver-auth: 06:45:55:   To prevent the kernel from randomly unlocking
xscreensaver-auth: 06:45:55:   your screen via the out-of-memory killer,
xscreensaver-auth: 06:45:55:   "xscreensaver-auth" must be setuid root.
xscreensaver-auth: 06:46:06: PAM: warning: /etc/pam.d/xscreensaver does not 
exist.
xscreensaver-auth: 06:46:06: PAM: password authentication is unlikely to work.
xscreensaver-auth: 06:46:15: PAM: warning: /etc/pam.d/xscreensaver does not 
exist.
xscreensaver-auth: 06:46:15: PAM: password authentication is unlikely to work.

When the dialog popped up, I had to switch to a terminal and kill
xscreensaver to be able to access my desktop again.

Should we revert it, until we figured out what's necesarry to get this
working again?

r0man

Ludovic Courtès  writes:

> Hi Rick,
>
> Rick Huijzer  skribis:
>
>> The latest xscreensaver patch  rendered
>> xscreensaver unusable on my systems. When I try to unlock my screen I am
>> greeted with the message 'xscreensaver: don't login as root', even though I
>> don't invoke it as root.
>>
>>
>> $xscreensaver-command -lock
>> Aug  9 08:45:22 localhost shepherd[1]: [slim] xscreensaver-gfx: 08:45:22:
>> 1: running as root: not launching hacks.
>> Aug  9 09:10:29 localhost shepherd[1]: [slim] xscreensaver-command: locking
>> Aug  9 09:10:32 localhost shepherd[1]: [slim] xscreensaver-gfx: 09:10:32:
>> 0: running as root: not launching hacks.
>>
>> When I remove the
>> (screen-locker-service xscreensaver)
>> I run into all kinds of set-uid problems.
>
> Sorry about that, I built it during review but did not actually run it.
>
> One effect of ‘screen-locker-service’ is to make the program setuid-root
> so that it can authenticate users.  It would seem that something changed
> in xscreensaver in that area; quoth ‘driver/subprocs.c’:
>
>   if (getuid() == (uid_t) 0 || geteuid() == (uid_t) 0)
> /* Prior to XScreenSaver 6, if running as root, we would change the
>effective uid to the user "nobody" or "daemon" or "noaccess",
>but even that was just encouraging bad behavior.  Don't log in
>as root. */
> {
>   fprintf (stderr, "%s: %d: running as root: not launching hacks.\n",
>blurb(), ssi->number);
>   screenhack_obituary (ssi, "", "XScreenSaver: Don't log in as 
> root.");
>   goto DONE;
> }
>
> OTOH the ‘disavow_privileges’ function is supposed to drop root
> privileges early on.
>
> So I’m not sure how it’s supposed to be run.  R0man, ideas?
>
> Thanks,
> Ludo’.


signature.asc
Description: PGP signature