bug#55665: GCC fails to cross-compile

[Pavel Shlyak]

It seems to be still there, even after dfda2cc5f6a57a0b89b98f389a2f28bf1e94eaa4

bug#57143: python-dolfin-adjoint / FEniCS fails to build

[Andreas Enge]

Hello,

when updating python-sympy, I noticed that its dependent python-dolfin-adjoint
fails to build. Probably this was also true before, since we do not have a
substitute.

I think the problem was in FEniCS, with an assertion failure, so my
impression was that the code computed a wrong solution.

It would be nice if someone with special knowledge could have a look;
some of the packages in the family also have updates available (but not
dolfin itself if I saw correctly).

Andreas

bug#57127: unzip fails to cross-compile

[Andrew Patterson]

unzip now cross-compiles successfully.  Thank you!

--
Andrew Patterson

bug#57091: Git authentication reports subkey fingerprints

[Maxime Devos]

On 11-08-2022 18:31, Tobias Geerinckx-Rice wrote:

* Expiration times and GPG-level revocation must be ignored (for
time-travel, and pulling from an old Guix), similarly to why it must
be ignored for when no subkeys are used
 * Someone used to GPG-style subkeys generates a new subkey to
replace old expired subkey or revokes old subkey, without keeping in
mind that Guix doesn't take that in account.
 * An attacker uses a compromised-but-revoked-or-expired subkey to
compromise the channel.


Why does none of this apply to primary keys? 


For primary keys as they are currently used in Guix, to revoke a key 
(from Guix' point of view), you remove it from .guix-authorizations, done.


For revoking subkeys, you trust GPG or whatever to take care of things, 
but Guix-modified-to-allow-subkeys-too doesn't have a clue that the 
subkey should be considered revoked, se bullet list above.


That could be solved by also adding a list of revoked subkeys to 
.guix-authorization, but that seems opposite to the proposed change.



Expiration times might be solvable by taking the commit time of the
previous commit as 'current time' (not the commit that was signed,
otherwise an attacker could just lie). I don't know a solution for
GPG-level revocation of old subkeys but I haven't looked either.


Git commit dates aren't reliable.  Requiring that they be accurate 
going forward would be imposing yet another 'artificial'/idiosyncratic 
limitation.  I think we should be very hesitant to build a 
verification system on assumptions stacked just so.
Yes, forbidding setting the datetime to something way off (e.g. 
1970-01-01) for privacy or such is quite a limitation.


They do not have to be accurate however, as long as the discrepancies in 
commit dates / actual time (*) are small compared to the expiration times.


(*) of non-attackers -- assuming frequent commits, an attacker cannot 
trick the expiration mechanism into large time difference. That might 
not be good enough for branches like 'wip-foo' or channels with 
infrequent commits though.


Greetings,
Maxime.


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#57046: Spanish documentation uses exclusive language

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

>Just a thought, but maybe it shouldn't be a group of men who decides
>what language is and is not inclusive and whether that's important.
>We've had some Outreachy interns, maybe some of them wouldn't mind being
>consulted on this.

Inclusion through exclusion, this is just sending the messages that men
bad anything else better. That just spreads hate for no particular reason.

I doubt that a lot of people translate the Guix manual to Spanish, so,
it probably wasn't even discussed or decided by anyone, let them be
women, men or non-binary.

And yes, language changes through use, but forcing it isn't the way,
people use the language and it naturally adapts, and if inclusive
language like using the letter "e" to make words neutral is going to
be used it has to be justified, I don't think that there's justification
to do so, or that anyone complained, there's not even people complaining
for other languages that use masculine words.

And yes, using "usuarios y usuarias" excludes non-binary people, that's
a limitation of the language and nothing can be done about it unless
everyday people start using it (read again, using it, not forcing it
onto people).

And in justification, I mean, real world data, statistics of people using
it or willing to do so.

To clarify I'm not against change, but I'm against forcing it. Nothing else.

Anyway, all people are welcome to discuss this.

And the fact that no one started an edit war on Weblate says it all, no men
is deciding anything. I personally want to know the reasoning behind it
and if it was discussed and not abused for personal reasons or a movement.

>I can’t really judge but don’t believe their and Ludo’s proposal “les
>usuaries” is really perceived neutral and acceptable.  (To Spanish
>speakers: What do psychologists say?  Does it appear feminine to you?)

It doesn't feel feminine or masculine, so I guess it's neutral. But the fact
that it makes text hard to read. I'd say that anyone can try doing a Stroop
test to feel the same in their own language to.

I say this being a neuro-typical person. I don't think forcing the "e" is
going to make it easier for neuro-divergent people.

—
Jean-Pierre De Jesus DIAZ

bug#57091: Git authentication reports subkey fingerprints

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

Hi Maxime,

Quick reply mainly to say thanks for replying :-)

On 2022-08-11 17:07, Maxime Devos wrote:

On 11-08-2022 13:17, Tobias Geerinckx-Rice wrote:


Apologies if I'm wildly off the mark here.  But then I'd like to
hear some plausible threat models.  Maxime?


Here's a problem with allowing subkeys, if that's what you mean:


(Well, you snipped my previous paragraph where I mention what you seem 
to describe below, so yes.)



* Expiration times and GPG-level revocation must be ignored (for
time-travel, and pulling from an old Guix), similarly to why it must
be ignored for when no subkeys are used
* Someone used to GPG-style subkeys generates a new subkey to
replace old expired subkey or revokes old subkey, without keeping in
mind that Guix doesn't take that in account.
* An attacker uses a compromised-but-revoked-or-expired subkey to
compromise the channel.


Why does none of this apply to primary keys?


Expiration times might be solvable by taking the commit time of the
previous commit as 'current time' (not the commit that was signed,
otherwise an attacker could just lie). I don't know a solution for
GPG-level revocation of old subkeys but I haven't looked either.


Git commit dates aren't reliable.  Requiring that they be accurate going 
forward would be imposing yet another 'artificial'/idiosyncratic 
limitation.  I think we should be very hesitant to build a verification 
system on assumptions stacked just so.



Another problem:

* When replacing the key in the 'keyring' branch with an 'updated'
key that contains the new subkey, we have to be careful to never
remove old subkeys, to avoid breaking time travel or pulling from old
versions.


Sure.  We always need to be careful when updating the keyring branch.

Kind regards,

T G-R

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

bug#57091: Git authentication reports subkey fingerprints

[Maxime Devos]

On 11-08-2022 13:17, Tobias Geerinckx-Rice wrote:

Apologies if I'm wildly off the mark here.  But then I'd like to hear some 
plausible threat models.  Maxime?


Here's a problem with allowing subkeys, if that's what you mean:

 * Expiration times and GPG-level revocation must be ignored (for
   time-travel, and pulling from an old Guix), similarly to why it must
   be ignored for when no subkeys are used
 * Someone used to GPG-style subkeys generates a new subkey to replace
   old expired subkey or revokes old subkey, without keeping in mind
   that Guix doesn't take that in account.
 * An attacker uses a compromised-but-revoked-or-expired subkey to
   compromise the channel.

Expiration times might be solvable by taking the commit time of the 
previous commit as 'current time' (not the commit that was signed, 
otherwise an attacker could just lie). I don't know a solution for 
GPG-level revocation of old subkeys but I haven't looked either.


Another problem:

 * When replacing the key in the 'keyring' branch with an 'updated' key
   that contains the new subkey, we have to be careful to never remove
   old subkeys, to avoid breaking time travel or pulling from old versions.

Greetings,
Maxime.



OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#57046: Spanish documentation uses exclusive language

[pelzflorian (Florian Pelz)]

Thank you Tobias.

Tobias Geerinckx-Rice  writes:
> How about we turn them into guidelines and add them to Contributing?

Yes, it would prevent such discussions.  But as lfvega says and as is
generally acknowledged, there is no good solution on how to deal with
gender here.

I can’t really judge but don’t believe their and Ludo’s proposal “les
usuaries” is really perceived neutral and acceptable.  (To Spanish
speakers: What do psychologists say?  Does it appear feminine to you?)

In Germanic (and Slavic?) grammatically feminine is clearly derived from
the grammatically masculine form (Benutzerin from Benutzer), which may
be a different situation from Latin; maybe it is not.

Listing both is verbose and unnatural.

Regards,
Florian

bug#55848: [cuirass] workers stalled

[Ludovic Courtès]

Hi,

Ricardo Wurmus  skribis:

> 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.

Oh my bad, sorry for overlooking your message.

Explicitly going through http://10.0.0.1 is still desirable I think
because we avoid HTTPS altogether.

‘guix deploy’ is still running on berlin.guix and building things;
unfortunately I’m going AFK for a bit.  I’ll pick it up later unless
someone takes care of it by then.

Thanks,
Ludo’.

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

[Ludovic Courtès]

Hello,

Mathieu Othacehe  skribis:

>> 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.

Indeed.  This should be fixed by
a81706494753ad84754cbb7583ccc783452decc0.

Thanks!

Ludo'.

bug#57071: Xscreensaver not working since latest patch

[Ludovic Courtès]

Hi Rick & Roman,

Rick Huijzer  skribis:

> 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?

Yes, either that or a special case in ‘screen-locker-service’.

Could you give it a try?

Unfortunately I’m going to be away from keyboard for a bit; please do
ping here and/or on IRC if you don’t get a timely reply.

Thanks,
Ludo’.

bug#57116: cling: missing some system header files

[Gang Liang]

I had a fresh installation of cling from guix, and got the following
error. Seems some system headers are missing.

Tried it on two machines, and both had the same problem.

** CLING **
* Type C++ code and press enter to run it *
* Type .q to exit *
***
[cling]$ #include 
In file included from input_line_3:1:
In file included from
/gnu/store/069aq2v993kpc41yabp5b6vm4wb9jkhg-gcc-10.3.0/include/c++/iostream:39:
In file included from
/gnu/store/069aq2v993kpc41yabp5b6vm4wb9jkhg-gcc-10.3.0/include/c++/ostream:38:
In file included from
/gnu/store/069aq2v993kpc41yabp5b6vm4wb9jkhg-gcc-10.3.0/include/c++/ios:42:
In file included from
/gnu/store/069aq2v993kpc41yabp5b6vm4wb9jkhg-gcc-10.3.0/include/c++/bits/ios_base.h:41:
In file included from
/gnu/store/069aq2v993kpc41yabp5b6vm4wb9jkhg-gcc-10.3.0/include/c++/bits/locale_classes.h:40:
In file included from
/gnu/store/069aq2v993kpc41yabp5b6vm4wb9jkhg-gcc-10.3.0/include/c++/string:55:
In file included from
/gnu/store/069aq2v993kpc41yabp5b6vm4wb9jkhg-gcc-10.3.0/include/c++/bits/basic_string.h:6545:
In file included from
/gnu/store/069aq2v993kpc41yabp5b6vm4wb9jkhg-gcc-10.3.0/include/c++/ext/string_conversions.h:44:
In file included from
/gnu/store/069aq2v993kpc41yabp5b6vm4wb9jkhg-gcc-10.3.0/include/c++/cerrno:42:
In file included from
/gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/include/errno.h:28:
/gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/include/bits/errno.h:26:11:
fatal error: 'linux/errno.h' file not found
# include 
  ^~~

bug#57137: FreeCAD welcome page text rendering does not work.

[Guillaume Le Vaillant]

It's a QtWebengine/Chromium bug that affects several programs like
Calibre, FreeCAD or Qutebrowser (see issues #54033 and #54297).

A workaround is to pass the "no-sandbox" option to Chromium. It can be
done by setting the QTWEBENGINE_CHROMIUM_FLAGS environment variable.
For example:

--8<---cut here---start->8---
QTWEBENGINE_CHROMIUM_FLAGS="--no-sandbox" FreeCAD
--8<---cut here---end--->8---

or:

--8<---cut here---start->8---
export QTWEBENGINE_CHROMIUM_FLAGS="--no-sandbox"
FreeCAD
--8<---cut here---end--->8---


signature.asc
Description: PGP signature

bug#57091: Git authentication reports subkey fingerprints

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

Of all the stupid typos...

>Ludo', are you worried that, since we already handle revocations like GPG would

...DON'T handle, of course, by design.

Kind regards,

T G-R

Sent on the go.  Excuse or enjoy my brevity.

bug#57091: Git authentication reports subkey fingerprints

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

This is not a mere UI issue.  Basic verification is currently broke^Wdifferent, 
too, or the latest incident wouldn't have happened.

Hmm.  I wonder...

Ludo', are you worried that, since we already handle revocations like GPG 
would, the 'proper' OpenPGPmodel could somehow break?  That we are in effect 
unable to safely fix this (yes, I maintain it is a) bug?

Apologies if I'm wildly off the mark here.  But then I'd like to hear some 
plausible threat models.  Maxime?

In their absence, nasty surprises like what happened last week are argument 
enough to (try to! :-) implement normal OpenPGP behaviour.



Kind regards,

T G-R

Sent on the go.  Excuse above-average rambliness.

bug#57068: Resizing mcron job in vm-image.tmpl interferes with settings

[Ludovic Courtès]

Hi Maxim,

Maxim Cournoyer  skribis:

> The vm-image.tmpl is the template we use for our graphical Guix demo
> QEMU image that can be downloaded from our site
> (https://guix.gnu.org/en/download/ ->
> https://ftp.gnu.org/gnu/guix/guix-system-vm-image-1.3.0.x86_64-linux.qcow2).
>
> This commit was made to allow SPICE dynamic resizing to work, as
> mentioned in a comment part of this commit.  XFCE lacks support for it,
> as also mentioned in the comment
> (https://gitlab.xfce.org/xfce/xfce4-settings/-/issues/142), which means
> a new user downloading the image and running it in a SPICE-capable
> viewer such as virt-manager or gnome-boxes will be dismayed that it
> doesn't resize as they may have come to expect from other modern
> distributions.

Understood.

(I wonder if the QEMU Guest Agent can serve a similar purpose.)

>> Should we remove this workaround, possibly finding another one?
>
> I think we should use a desktop environment that is better maintained,

I think this is unfair criticism: Xfce is actively maintained, with a
large user base.

> and which works well with SPICE, without hacks, given the improvements
> to the user experience it provides, and given it's important that a
> first user encounter with Guix be smooth and shiny.  GNOME could do it,
> at the cost of a bigger image size.

Right.  I wouldn’t mind GNOME, but one reason we went for Xfce is that
GNOME is just too big, at least as currently packaged in Guix.

> There are other, perhaps worst issues with XFCE, which is that the
> keyboard layout switcher doesn't work, and it didn't seem trivial to fix
> when I looked at it.

Oh, I wasn’t aware of that, that should certainly be fixed.  (I fixed a
similar issue in GNOME some years ago, and I’m confident it’ll be easier
to fix in Xfce because it doesn’t have all those layers and daemons and
JavaScript and DBus interfaces.  :-))

That’s a general issue with all Xfce installations, not just in the VM
image, right?

Thanks,
Ludo’.

bug#57068: Resizing mcron job in vm-image.tmpl interferes with settings

[Ludovic Courtès]

Hi,

Maxim Cournoyer  skribis:

>> There’s a third problem that I initially thought was unrelated:
>>
>>   3. The mcron job starts running before ‘xorg-server’ is up, and that
>>  can cause Xorg to fail to start.
>>
>> Namely, if you run the command above, you’ll see that Xorg starts and
>> fails typically a few times in a row, until it eventually succeeds.  In
>> /var/log/messages, you can see that the ‘xorg-server’ process exits with
>> code 1 (without any indication of what went wrong AFAICS) and the
>> service gets respawned.
>>
>> Now if you remove the mcron job and boot the VM, the ‘xorg-server’
>> service successfully starts.  It’s 100% reproducible for me.
>
> I tried to reproduce the problem without any luck on my machine (it
> always boots fine).  Odd.

Does ‘xorg-server’ successfully start from the first time, or does
succeed after a few tries?  For me it systemically tries a couple of
time before it succeeds.

Ludo’.

bug#57127: unzip fails to cross-compile

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

(Now home:) fixed in 45db0ca5e9.

Can you confirm that it works for you?

Closing,

T G-R

Sent on the go.  Excuse or enjoy my brevity.

bug#57067: Missing Xfce icons

[Ludovic Courtès]

Hi,

宋文武  skribis:

> Ludovic Courtès  writes:
>
>> In current ‘master’ (ca. 6db3b34d7203639ef4286c237a6e536259f92352), in a
>> VM created with:
>>
>>   guix system vm gnu/system/examples/vm-image.tmpl
>>
>> Xfce is lacking a few icons in window decorations and in the bar at the top:
>>
>
> Fixed in commit 02b69362cb5922e3e2579b120a12afcc6167a46e now.

Excellent, thanks for the quick fix!

Ludo’.

bug#57091: Git authentication reports subkey fingerprints

[Ludovic Courtès]

Hi,

Maxime Devos  skribis:

> On 09-08-2022 23:07, Ludovic Courtès wrote:
>> Hello,
>>
>> As Tobias explains at
>>   and
>> as can be seen from ‘.guix-authorizations’, the (guix openpgp) and (guix
>> git-authenticate) machinery reports the fingerprint of subkeys on
>> signatures (when subkeys are used) rather than the fingerprint of
>> primary keys.
>>
>> This should be changed to report primary keys, at least optionally.
>
> Why should it be changed? IIUC .guix-authorizations and (guix ...)
> care about the key that things were signed with, not necessarily the
> primary key, so it seems to me that it needs to report the subkey
> fingerprint, not the fingerprint of the primary key it belongs to, as
> the primary key is irrelevant to them IIUC.

Yes, I kinda agree, but…  the motivation here is that OpenPGP user
interfaces don’t normally refer to subkey fingerprints; instead they
refer to primary key fingerprints, even if you use a subkey, which is
the point of subkeys AIUI.  That Guix treats subkeys differently is
confusing to seasoned OpenPGP users.

Ludo’.

bug#56799: (gnu services configuration) usage of *unspecified* is problematic

[Attila Lendvai]

> OK, I've reread this, and it is indeed a risk, that 'unset could leak in
> the case of a serializable configuration making use of a maybe-value
> field of type maybe-symbol. I've added the unit test suggested as
> 97cb43e732a38758c95b7caf3963507188d011cf (currently marked as 'expected
> to fail'). Luckily no current service uses that.

thank you for that Maxim!

and sorry for my initial, somewhat reactive, and emotionally driven response 
earlier! maintaining a channel with complex services, and finally getting the 
changes i needed merged into Guix proper was a source of frustration for me.

i've looked at the current state of the code, and it looks good to me. the only 
issues i have left are the following:

1) the (eq 'unset ...) scattered around the code; it should be hidden behind an 
explicit abstraction, but you yourself mentioned this already in an earlier 
mail. i'd call it CONFIGURATION-FIELD-SET? (instead of MAYBE-SET?). it's 
longer, but we have completion in emacs, and it won't be used a gazillion times 
all around the code either.

2) the lack of an abstraction for the unset/unspecified value. whatever we use 
as the marker should be hidden behind either an exported global variable, or a 
function called UNSET-CONFIGURATION-FIELD! (or something alike). i should have 
introduced these myself, and then your fix would have been as simple as 
replacing *UNSPECIFIED* with 'UNSET in the abstraction.

3) the SYMBOL? corner case that your test captures, but it's not a burning 
issue for me (it doesn't affect the user facing API, once the above leakages 
are fixed).

do you agree? if yes, will you implement it, or shall i prepare a patch?

one more note: sometimes it's useful to have a field with a maybe type that 
also has a default, together with the ability to explicitly unset this field.

an example would be a port specification for a torrent client: it has some 
default port, but it's possible to explicitly unset the port value to request 
the allocation of a random port at startup.

to better accommodate for this use case, 2) should probably be implemented not 
as an UNSET-FOO! function, but as a global variable holding the unset value 
marker. or maybe both?

--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“There is only one thing more harmful to society than an elected official 
forgetting the promises he made in order to get elected; that's when he doesn't 
forget them.”
— John McCarthy (1927–2011), father of Lisp

bug#57127: unzip fails to cross-compile

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

Hi Andrew,

This is a bug in Guix, not really related to cross-compiling (hence you can 
stop cross-testing and reporting different architectures, although the effort 
is appreciated!).

%output is practically deprecated, but is still present in a good number of 
packages.  Sometimes it happens to work, because a specific build system 
explicitly kept support for it.  Some build systems don't, making support for 
it feel unreliable.  It is.  %output is obsolete for new code.

What also happens is that build systems still support it in the well-tested 
native build path, but not when cross-compiling.  That seems to be the case 
here.

> Interestingly, it gives the same errors when explicitly building for x86_64 
> on an x86_64 machine, even though I would expect doing so to compile as 
> normal.

You don't define what you mean by 'explicitly building'.

If you mean --target=x86_64-linux-gnu, why would it not fail?  You're 
cross-compiling.  Guix doesn't silently fall back to a non-cross build when the 
architectures match, no should it IMO.

The fix should be simple: rewrite unzip to use gexps and hence #$output.  Why 
didn't I simply do so yet?  Because too many packages depend on unzip to simply 
do so on master.  There's probably a way around that, but I'll try it when I'm 
back at a computer.

Kind regards,

T G-R

Sent on the go.  Excuse or enjoy my brevity.

bug#57127: unzip fails to cross-compile

[Maxime Devos]

On 11-08-2022 00:06, Andrew Patterson wrote:
unzip fails to build when cross-compiling (at least from x86_64 
linux), complaining that '%output' is unbound.


Change #:make-flags to use a G-exp instead of a S-exp and replace the 
undocumented %output by the #$output.


For consistency, you can do the same for #:phases.

For simplicity, I recommend not using ` for argument but 'list': 
(arguments (list #:phases #~(modify-phases ...) #:make-flags #~(list ...))).


  It gives identical errors when compiling for aarch64, riscv64, and 
arm. Interestingly, it gives the same errors when explicitly building 
for x86_64 on an x86_64 machine, even though I would expect doing so 
to compile as normal.


Technically that's cross-compilation from Guix perspective, though maybe 
it should just compile natively in that case.



On my x86_64 machines, 'guix show unzip' does only have x86_64-linux 
and i686-linux in the 'systems' list, but that's also true of htop, 
which does cross-compile.  (Also, why does it do that?  The same 
command on my aarch64 machine shows many more system types.)


I don't know.

Greetings,
Maxime.


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#57136: Snakemake cannot execute remote jobs

[Konrad Hinsen]

The execution of Snakemake workflows fails on a cluster because the
script that Snakemake executes remotely does not reference Python
correctly.

This is due to a patch applied in the Guix package
definition (build phase call-wrapper-not-wrapped-snakemake, 
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/python-xyz.scm#n9713)
which is outdated. The corresponding code in Snakemake was changed
significantly in the following commit:

  
https://github.com/snakemake/snakemake/commit/e87cc979bea0567e1cd97722d385f472857df83c#diff-438f3317205fd7130727d0589d2fc1a6c2e1f6fc48c2c04d354a8a09b91ba2f4

Cheers,
  Konrad

bug#57104: Python-symengine fails to build

[宋文武 via Bug reports for GNU Guix]

Andreas Enge  writes:

> Since it replaces a broken package by a more modern broken package, I still
> took the liberty to push, but it would be nice if someone with knowledge of
> python and/or symengine could have a look. Disabling the tests makes the
> compilation succeed, but it would be nice to find a better solution...
>

Fixed it by using 'nosetests' to run the tests.

Close now, thanks!

bug#57134: powerpc64le: gst-plugins-good build link error on aalib (libgstaasink.so)

[Marcel van der Boom]

Building gst-plugins-good on powerpc64le (Talos II machine) 
produces a link error related to aalib.


Commenting out the 'aalib' input makes the build succeed.

Relevant snippet from the build log below.

--8<---cut here---start->8---
[444/851] Linking target ext/aalib/libgstaasink.so
FAILED: ext/aalib/libgstaasink.so
gcc  -o ext/aalib/libgstaasink.so 
ext/aalib/libgstaasink.so.p/gstaasink.c.o 
ext/aalib/libgstaasink.so.p/gstaatv.c.o -Wl,--as-needed 
-Wl,--no-undefined -shared -fPIC -Wl,--start-group 
-Wl,-soname,libgstaasink.so -Wl,-Bsymbolic-functions 
-Wl,-rpath=/gnu/store/ypfbdcb16s2mir7x51hv0jckcq8rl15b-gst-plugins-good-1.18.5/lib 
/gnu/store/3zfl42ll99vhf8dg1na6vwp7iqn2439q-gst-plugins-base-1.18.5/lib/libgstvideo-1.0.so 
/gnu/store/s4hh37b9z35ik9mv5vsxyfdx4pdi84py-gstreamer-1.18.5/lib/libgstbase-1.0.so 
/gnu/store/s4hh37b9z35ik9mv5vsxyfdx4pdi84py-gstreamer-1.18.5/lib/libgstreamer-1.0.so 
/gnu/store/3d194piqkas8gv66qa9hawa6qa115i6a-glib-2.70.2/lib/libgobject-2.0.so 
/gnu/store/3d194piqkas8gv66qa9hawa6qa115i6a-glib-2.70.2/lib/libglib-2.0.so 
-laa -Wl,--end-group
ld: 
/gnu/store/xq3kvsvfmbi1hlr6ilpcw8zi7ylxnvl6-aalib-1.4rc5/lib/../lib/libaa.a(aarender.o): 
in function `aa_renderpalette':

(.text+0x798): undefined reference to `pow'
ld: 
/gnu/store/xq3kvsvfmbi1hlr6ilpcw8zi7ylxnvl6-aalib-1.4rc5/lib/../lib/libaa.a(aacurses.o):(.text+0xe8): 
undefined reference to `curs_set'
ld: 
/gnu/store/xq3kvsvfmbi1hlr6ilpcw8zi7ylxnvl6-aalib-1.4rc5/lib/../lib/libaa.a(aacurses.o):(.text+0x130): 
undefined reference to `wrefresh'
ld: 
/gnu/store/xq3kvsvfmbi1hlr6ilpcw8zi7ylxnvl6-aalib-1.4rc5/lib/../lib/libaa.a(aacurses.o):(.text+0x18c): 
undefined reference to `wmove'
ld: 
/gnu/store/xq3kvsvfmbi1hlr6ilpcw8zi7ylxnvl6-aalib-1.4rc5/lib/../lib/libaa.a(aacurses.o):(.text+0x1d4): 
undefined reference to `waddnstr'
ld: 
/gnu/store/xq3kvsvfmbi1hlr6ilpcw8zi7ylxnvl6-aalib-1.4rc5/lib/../lib/libaa.a(aacurses.o): 
in function `curses_init':

(.text+0x250): undefined reference to `initscr'
ld: (.text+0x27c): undefined reference to `termattrs'
ld: (.text+0x2d4): undefined reference to `intrflush'
ld: (.text+0x344): undefined reference to `wclear'
ld: (.text+0x354): undefined reference to `intrflush'
ld: (.text+0x360): undefined reference to `wrefresh'
ld: (.text+0x3a4): undefined reference to `endwin'
ld: (.text+0x46c): undefined reference to `wclear'
ld: (.text+0x47c): undefined reference to `intrflush'
ld: (.text+0x488): undefined reference to `wrefresh'
ld: (.text+0x50c): undefined reference to `endwin'
ld: 
/gnu/store/xq3kvsvfmbi1hlr6ilpcw8zi7ylxnvl6-aalib-1.4rc5/lib/../lib/libaa.a(aacurses.o):(.toc+0x0): 
undefined reference to `stdscr'
ld: 
/gnu/store/xq3kvsvfmbi1hlr6ilpcw8zi7ylxnvl6-aalib-1.4rc5/lib/../lib/libaa.a(aacurkbd.o):(.text+0x2c): 
undefined reference to `nodelay'
ld: 
/gnu/store/xq3kvsvfmbi1hlr6ilpcw8zi7ylxnvl6-aalib-1.4rc5/lib/../lib/libaa.a(aacurkbd.o):(.text+0x70): 
undefined reference to `wgetch'
ld: 
/gnu/store/xq3kvsvfmbi1hlr6ilpcw8zi7ylxnvl6-aalib-1.4rc5/lib/../lib/libaa.a(aacurkbd.o):(.text+0x104): 
undefined reference to `nodelay'
ld: 
/gnu/store/xq3kvsvfmbi1hlr6ilpcw8zi7ylxnvl6-aalib-1.4rc5/lib/../lib/libaa.a(aacurkbd.o):(.text+0x224): 
undefined reference to `initscr'
ld: 
/gnu/store/xq3kvsvfmbi1hlr6ilpcw8zi7ylxnvl6-aalib-1.4rc5/lib/../lib/libaa.a(aacurkbd.o):(.text+0x254): 
undefined reference to `cbreak'
ld: 
/gnu/store/xq3kvsvfmbi1hlr6ilpcw8zi7ylxnvl6-aalib-1.4rc5/lib/../lib/libaa.a(aacurkbd.o):(.text+0x25c): 
undefined reference to `noecho'
ld: 
/gnu/store/xq3kvsvfmbi1hlr6ilpcw8zi7ylxnvl6-aalib-1.4rc5/lib/../lib/libaa.a(aacurkbd.o):(.text+0x264): 
undefined reference to `nonl'
ld: 
/gnu/store/xq3kvsvfmbi1hlr6ilpcw8zi7ylxnvl6-aalib-1.4rc5/lib/../lib/libaa.a(aacurkbd.o):(.text+0x27c): 
undefined reference to `keypad'
ld: 
/gnu/store/xq3kvsvfmbi1hlr6ilpcw8zi7ylxnvl6-aalib-1.4rc5/lib/../lib/libaa.a(aacurkbd.o):(.text+0x330): 
undefined reference to `keypad'
ld: 
/gnu/store/xq3kvsvfmbi1hlr6ilpcw8zi7ylxnvl6-aalib-1.4rc5/lib/../lib/libaa.a(aacurkbd.o):(.text+0x340): 
undefined reference to `nodelay'
ld: 
/gnu/store/xq3kvsvfmbi1hlr6ilpcw8zi7ylxnvl6-aalib-1.4rc5/lib/../lib/libaa.a(aacurkbd.o):(.text+0x358): 
undefined reference to `nocbreak'
ld: 
/gnu/store/xq3kvsvfmbi1hlr6ilpcw8zi7ylxnvl6-aalib-1.4rc5/lib/../lib/libaa.a(aacurkbd.o):(.text+0x360): 
undefined reference to `echo'
ld: 
/gnu/store/xq3kvsvfmbi1hlr6ilpcw8zi7ylxnvl6-aalib-1.4rc5/lib/../lib/libaa.a(aacurkbd.o):(.text+0x370): 
undefined reference to `nl'
ld: 
/gnu/store/xq3kvsvfmbi1hlr6ilpcw8zi7ylxnvl6-aalib-1.4rc5/lib/../lib/libaa.a(aacurkbd.o):(.text+0x3a8): 
undefined reference to `intrflush'
ld: 
/gnu/store/xq3kvsvfmbi1hlr6ilpcw8zi7ylxnvl6-aalib-1.4rc5/lib/../lib/libaa.a(aacurkbd.o):(.text+0x3b4): 
undefined reference to `wclear'
ld: 
/gnu/store/xq3kvsvfmbi1hlr6ilpcw8zi7ylxnvl6-aalib-1.4rc5/lib/../lib/libaa.a(aacurkbd.o):(.text+0x3c0): 
undefined reference to `wrefresh'
ld: 
/gnu/store/xq3kvsvfmbi1hlr6ilpcw8zi7ylx