bug#53742: rust-fiat-crypto missing source

[Dr. Arne Babenhauserheide]

Jack Hill  writes:
> These files are autogenerated from the Coq source. I think that we
> should build from that source as part of our package definition.
>
> What do you think?

I think that sounds sensible. Can you try whether it works?

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de


signature.asc
Description: PGP signature

bug#53742: rust-fiat-crypto missing source

[Jack Hill]

Hi Guix,

It looks like our rust-fiat-crypto package is not built from source, but 
from autogenerated files. All the code retuned by `guix build -S 
rust-fiat-crypto` contains headers like


"""
// AUTOGENERATED FILE: DO NOT EDIT
"""

or

"""
//! Autogenerated: 'src/ExtractionOCaml/word_by_word_montgomery' --lang Rust 
--inline secp256k1 64 '2^256 - 2^32 - 977' mul square add sub opp 
from_montgomery to_montgomery nonzero selectznz to_bytes from_bytes one msat 
divstep divstep_precomp
//! curve description: secp256k1
//! machine_wordsize = 64 (from "64")
//! requested operations: mul, square, add, sub, opp, from_montgomery, 
to_montgomery, nonzero, selectznz, to_bytes, from_bytes, one, msat, divstep, 
divstep_precomp
//! m = 0xfffefc2f (from 
"2^256 - 2^32 - 977")
//!
//! NOTE: In addition to the bounds specified above each function, all
//!   functions synthesized for this Montgomery arithmetic require the
//!   input to be strictly less than the prime modulus (m), and also
//!   require the input to be in the unique saturated representation.
//!   All functions also ensure that these two properties are true of
//!   return values.
//!
//! Computed values:
//!   eval z = z[0] + (z[1] << 64) + (z[2] << 128) + (z[3] << 192)
//!   bytes_eval z = z[0] + (z[1] << 8) + (z[2] << 16) + (z[3] << 24) + (z[4] << 32) + (z[5] << 40) + (z[6] << 48) + (z[7] << 56) + (z[8] << 64) + (z[9] << 72) + (z[10] << 80) + (z[11] << 88) + 
(z[12] << 96) + (z[13] << 104) + (z[14] << 112) + (z[15] << 120) + (z[16] << 128) + (z[17] << 136) + (z[18] << 144) + (z[19] << 152) + (z[20] << 160) + (z[21] << 168) + (z[22] << 176) + (z[23] 
<< 184) + (z[24] << 192) + (z[25] << 200) + (z[26] << 208) + (z[27] << 216) + (z[28] << 224) + (z[29] << 232) + (z[30] << 240) + (z[31] << 248)
//!   twos_complement_eval z = let x1 := z[0] + (z[1] << 64) + (z[2] << 128) + (z[3] 
<< 192) in
//!if x1 & (2^256-1) < 2^255 then x1 & (2^256-1) else 
(x1 & (2^256-1)) - 2^256
"""

These files are autogenerated from the Coq source. I think that we should 
build from that source as part of our package definition.


What do you think?
Jack

bug#28659: Content-addressed mirror is not used upon invalid hash

[zimoun]

Hi Ludo,

On Fri, 15 Dec 2017 at 10:30, l...@gnu.org (Ludovic Courtès) wrote:

>> So I think we have to communicate more info from the daemon to ‘guix
>> substitute’.
>
> The attached patch addresses that by simply calling out to the daemon to
> determine whether we’re dealing with a content-addressed item.

WDYT to rebase this patch [1] and resubmit to guix-patches in order to
get more attention and so potential feedback and/or review?

1: 


Cheers,
simon

bug#25325: elogind does not set ACLs promptly

[zimoun]

Hi,

On Wed, 05 Jan 2022 at 00:37, zimoun  wrote:

> I am doing some triage of old bug and I hit this one [1].  Since it is
> from 2017 and many things changed since then, is it still an issue?
>
> 1: 

Can I assume it is not an issue anymore?


> On Sun, 01 Jan 2017 at 14:58, Chris Marusich  wrote:
>> Please find attached a description of the bug, which came from the
>> following email thread:
>>
>> https://lists.gnu.org/archive/html/guix-devel/2016-12/msg01126.html
>>
>> From: Chris Marusich 
>> Subject: Re: Let non-root users use MTP devices (Attempt #2)
>> To: l...@gnu.org (Ludovic Courtès)
>> Cc: guix-de...@gnu.org
>> Date: Thu, 29 Dec 2016 16:41:10 -0800 (5 years, 5 days, 16 hours ago)
>>
>> l...@gnu.org (Ludovic Courtès) writes:
>>
>>> Chris Marusich  skribis:
>>>
 Chris Marusich  writes:

> Here's a second attempt to fix MTP support for GuixSD.  It's simple and
> requires no special group permissions.
>
> It turns out that elogind (like systemd's logind) can be compiled with
> support for ACLs (provided by libacl), in which case elogind will
> automatically set an ACL on a device file granting access to a user when
> that user is logged in using a seat to which the device is attached.  In
> short, by adding acl as an input to elogind, users will be able to
> access devices without running programs as root, and without being a
> member of any special group.
>
> That's just one piece of the puzzle, though.  The other piece is the
> udev rules provided by libmtp.  It's necessary to install those udev
> rules; if we don't, then the MTP device won't be tagged properly, so
> elogind will not set any ACLs for it.  I've chosen to install those
> rules by modifying the base services in desktop.scm so that all desktops
> will get the rules, not just GNOME; if you know of a better way to
> install them, please let me know.
>
> This patch has a happy side effect.  Namely: because elogind is now
> setting ACLs, it gives a user access to other devices that are attached
> to their seat.  For instance, after this change, I can access /dev/kvm
> and /dev/cdrom (and other devices) without being root, and without being
> in any special group.  How nice!

 After sending this, I've noticed something odd: sometimes, it can take
 quite a while for elogind to set the ACLs.  It's a bit of a mystery to
 me.  I'm not sure how/when elogind decides to update the ACLs; I assumed
 it was continuously checking for changes in the hardware or receiving
 notifications about hardware changes, but it seems like elogind isn't
 noticing when I plug in my phone.  Even though the device file shows up,
 elogind doesn't set the ACLs unless I do something.

 By "do something," I mean: Apparently, logging out and logging back in
 seems to trigger elogind to set the ACLs.  Even just switching virtual
 terminals (i.e., Control + F1, followed by Control + F7) seems to
 trigger it, which is weird.  Even when elogind has not yet set the ACLs,
 the "uaccess" tag has in fact been correctly set for the device (as
 reported by e.g. "udevadm info /dev/libmtp-1-1"), which leads me to
 suspect that elogind is either failing to notice or just ignoring the
 hardware change.  I wonder if this might be a bug of some kind.

 What do you think we should do?
>>>
>>> Good question!  I don’t know.  Does this happen only for MTP devices or
>>> also with other things (KVM?)?
>>
>> Yes, this happens for other devices, too.  For example, I observe
>> exactly the same behavior for /dev/sr0 when I plug in an external CD-ROM
>> drive (via USB cable) after logging in.  The ACL doesn't get set until
>> after I do something like switch to another virtual terminal and back.
>>
>>> Does “udevadm settle” trigger the ACL change?
>>
>> No, neither "udevadm settle" nor "sudo udevadm settle" triggers the ACL
>> change.  I suspect that maybe elogind is ignoring or failing to notice
>> the new device, or perhaps the mechanism that elogind relies on to learn
>> about new devices is not working for some reason.
>>
>> It looks like elogind sets the ACLs via devnode_acl_all, defined in
>> src/login/logind-acl.c.  Ultimately it seems this gets called while in
>> seat_set_active (specifically, invoked at src/login/logind-seat.c:213),
>> under certain conditions.  That's as far as I got.
>>
>> I cannot reproduce this issue on Ubuntu; there, the ACL gets set
>> promptly.

Cheers,
simon

bug#23196: GNOME "Sharing" settings is blank

[zimoun]

Hi,

On Wed, 05 Jan 2022 at 00:44, zimoun  wrote:

> Is this old bug [1] from 2016 still happening?
>
> 1: 
>
>
> On Thu, 19 Nov 2020 at 10:08, zimoun  wrote:
>> On Wed, 18 Nov 2020 at 11:28, Leo Prikler 
>> wrote:

[...]

>> I see.  Let mark it as important and hope for a fix in the next Gnome
>> round. :-)
>
> The next Gnome round happened, I guess.  Therefore, is it still an
> issue?

I assume it is not an issue anymore.  So if no more comment, I will
close.


Cheers,
simon

bug#25957: gitolite broken: created repositories keep references to /usr/bin for hooks

[zimoun]

Hi Efraim,

On Wed, 12 Jan 2022 at 20:07, Efraim Flashner  wrote:

>> …the package redis is not a dependency of gitolite.  Therefore, the
>> question is: is our Gitolite package working with Redis?  Even using the
>> /usr/bin one?  Idem for SVN.
>>
>> Otherwise, I am favor to remove the 2 “problematic” references.   WDYT?
>
> Or change it to search the $PATH for the binary, so it would just be
> 'redis-server' or 'svnserve'

Is our Gitolite package working with Redis?  If not, why try to fix. ;-)


Cheers,
simon

bug#33362: System tests stuck in "shepherd[1]: waiting for udevd..."

[zimoun]

Hi,

On Wed, 05 Jan 2022 at 00:21, zimoun  wrote:
> On Fri, 26 Nov 2021 at 18:21, Mark H Weaver  wrote:
>>> On Mon, 12 Nov 2018 at 20:09, Mark H Weaver  wrote:
>>>
 As I write this, there are two system test builds that have been stuck
 for many hours, endlessly printing "shepherd[1]: waiting for udevd...":

   https://hydra.gnu.org/build/3153725
   https://hydra.gnu.org/build/3154365

 They are both on i686-linux, and on the 'core-updates' branch, but with
 two different build slaves (hydra.gnunet.org and guix.sjd.se).

 I will now abort these builds, to free up build slots for other jobs.
>>>
>>> I am doing bug triage and I hit this old one #33362 [1] from 2018.  It
>>> is about hydra which is down now, IIRC.
>>
>> I doubt that this bug was about Hydra.  It guess that the bug was in our
>> system test derivations.  As far as I know, the only relevance of Hydra
>> to this bug is that Hydra was our CI system at that time, and therefore
>> it was Hydra that brought this bug to my attention.
>
> I agree, but I am not able to connect to the mentioned logs.  Are the
> links still working?
>
>
>>> Does it still make sense to keep it open?  Or can we close it?
>>
>> If the bug hasn't occurred recently, then I agree it's okay to close it.
>>
>> It would be good to check our modern Cuirass-based ci.guix.gnu.org to
>> find out whether this failure mode is still occurring in our system
>> tests.
>>
>> I see that Cuirass's web interface has improved quite significantly in
>> the last couple of years, and I'm very grateful to those who've worked
>> on it.  However, Cuirass still seems to be missing some important
>> functionality that Hydra had.  Most notably, unless I missed something,
>> it seems to lack the ability to compare the results of two evaluations
>> and show the *differences* between those results, i.e. to enumerate the
>> newly failing jobs, the newly succeeding jobs, and the newly aborted
>> jobs.
>>
>> Without that functionality, it's not easy for us to notice when a job
>> starts to fail, unless a user files a bug report.  The total list of job
>> failures has always been too large to easily notice changes in that list
>> without assistance.
>
> I agree.  Maybe Mathieu could comment more because this missing feature
> is floating around. :-)

Since the initial report does not seem to have occurred recently and
because the feature is not related (or let open another report), I am
closing.

Feel free to reopen if I miss an important point.


Cheers,
simon

bug#30840: the panel crash

[zimoun]

On Wed, 05 Jan 2022 at 00:26, zimoun  wrote:
> On Thu, 25 Nov 2021 at 00:51, zimoun  wrote:
>> On Sat, 17 Mar 2018 at 15:10, Catonano  wrote:
>
>>> Maybe related to the previous bug I filed (dbus unavailability ?)
>>>
>>> When attempting to add a keyboard layout, the panel crashes
>>>
>>> Here the footage
>>> https://youtu.be/anHeACHu8OQ
>>
>> Is it still an issue?  If not, let close this old bug. :-)
>
> Thanks for the report of [1].  Is it still an issue?  If not, let
> close. :-)

Without an answer, I assume it is not an issue anymore, so I am closing.


Cheers,
simon

bug#51536: openblas builds not reproducible on different x86_64 machines

[Ludovic Courtès]

Hi!

Maxim Cournoyer  skribis:

> Our OpenBLAS package uses DYNAMIC_ARCH=1 to provide optimizations for
> all supported targets, at least of x86 and x86_64.  In theory that seems
> OK, but in practice the builds differ depending on the host CPU.

What follows is the log of an investigation that didn’t find the root
cause, but perhaps it’ll give us ideas…

Right now the build results of ci.guix and bordeaux.guix differ:

--8<---cut here---start->8---
$ guix describe
Generacio 202   Jan 30 2022 23:57:03(nuna)
  guix 43dd34c
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 43dd34ca212c99a97da7a2c237158faa9a1b
ludo@ribbon ~/src/guix$ guix challenge openblas
/gnu/store/ras6dprsw3wm3swk23jjp8ww5dwxj333-openblas-0.3.18 contents differ:
  no local build for 
'/gnu/store/ras6dprsw3wm3swk23jjp8ww5dwxj333-openblas-0.3.18'
  
https://ci.guix.gnu.org/nar/lzip/ras6dprsw3wm3swk23jjp8ww5dwxj333-openblas-0.3.18:
 0m1jlc26yrwxn8gxwpj8452kw4g84ywclh0hnab93873ifz87s5c
  
https://bordeaux.guix.gnu.org/nar/lzip/ras6dprsw3wm3swk23jjp8ww5dwxj333-openblas-0.3.18:
 1d0m9v3kpsqzplpl1law2lfhm6rrbhkkqsvh19dlg9wx45vbbvjb
  differing file:
/lib/libopenblasp-r0.3.18.so

1 store items were analyzed:
  - 0 (0.0%) were identical
  - 1 (100.0%) differed
  - 0 (0.0%) were inconclusive
--8<---cut here---end--->8---

To get an idea, I thought we could compare the two build logs:

  https://ci.guix.gnu.org/log/ras6dprsw3wm3swk23jjp8ww5dwxj333-openblas-0.3.18
  https://bordeaux.guix.gnu.org/build/3fab433c-e7d3-498d-86f8-4bcd5da9c4db

(Protip: I found the second one via
.)

The “ar  -ru ../libopenblasp-r0.3.18.a …” are apparently the same in
both cases, which rules out the simple case of unsorted .o files.

The .so on ci.guix is slightly bigger:

--8<---cut here---start->8---
$ wget -qO - 
https://ci.guix.gnu.org/nar/lzip/ras6dprsw3wm3swk23jjp8ww5dwxj333-openblas-0.3.18|
 lzip -d | guix archive -x /tmp/o1
$ wget -qO - 
https://bordeaux.guix.gnu.org/nar/lzip/ras6dprsw3wm3swk23jjp8ww5dwxj333-openblas-0.3.18|
 lzip -d | guix archive -x /tmp/o2
$ ls -l /tmp/{o1,o2}/lib/libopenblasp-r0.3.18.so
-r-xr-xr-x 1 ludo users 40538768 Jan  1  1970 
/tmp/o1/lib/libopenblasp-r0.3.18.so
-r-xr-xr-x 1 ludo users 40436368 Jan  1  1970 
/tmp/o2/lib/libopenblasp-r0.3.18.so
--8<---cut here---end--->8---

Both have the same symbols though, and in the same order:

--8<---cut here---start->8---
$ diff -u <(objdump -T  /tmp/o1/lib/libopenblasp-r0.3.18.so |cut -c 60-  ) 
<(objdump -T /tmp/o2/lib/libopenblasp-r0.3.18.so |cut -c60- )
$ echo $?
0
--8<---cut here---end--->8---

… which suggests they include code optimized for the same
micro-architectures because symbols include the name of the
micro-architecture:

--8<---cut here---start->8---
$ objdump -T  /tmp/o1/lib/libopenblasp-r0.3.18.so |cut -c 60-|tail -10
  csymm3m_RU
  cgemv_c_BARCELONA
  csymv_U_HASWELL
  dtrmm_iltncopy_CORE2
  LAPACKE_dsytrs2
  openblas_num_threads_env
  csycon_rook_
  csytri_rook_


--8<---cut here---end--->8---

Some of the offsets differ though:

$ diff -u <(objdump -T  /tmp/o1/lib/libopenblasp-r0.3.18.so  ) <(objdump -T /tmp/o2/lib/libopenblasp-r0.3.18.so )
--- /dev/fd/63	2022-02-03 00:10:17.308357982 +0100
+++ /dev/fd/62	2022-02-03 00:10:17.276357923 +0100
@@ -1,5 +1,5 @@
 
-/tmp/o1/lib/libopenblasp-r0.3.18.so: format de fixer elf64-x86-64
+/tmp/o2/lib/libopenblasp-r0.3.18.so: format de fixer elf64-x86-64
 
 DYNAMIC SYMBOL TABLE:
   DF *UND*	  GLIBC_2.3.2 pthread_cond_signal
@@ -91,57 +91,57 @@
 013edb70 gDF .text	01be  Basezgemm3m_incopyb_BULLDOZER
 00e6d200 gDF .text	2b06  Basestrsm_kernel_RT_BOBCAT
 00512c00 gDF .text	0a0a  Basezsymv_U_PRESCOTT
-023c7530 gDF .text	0201  BaseLAPACKE_dpttrs_work
+023ae930 gDF .text	0201  BaseLAPACKE_dpttrs_work
 00692000 gDF .text	0b89  Basesrot_k_PENRYN
 0179caa0 gDF .text	0200  Basedgemm_beta_HASWELL
 00a44690 gDF .text	04b4  Basedtrsm_iutucopy_OPTERON
-0231cfc0 gDF .text	021d  BaseLAPACKE_sstein_work
-02327800 gDF .text	014b  BaseLAPACKE_ssytrd
-01ad9100 gDF .text	02aa  Basechemm_outcopy_SKYLAKEX
+023043c0 gDF .text	021d  BaseLAPACKE_sstein_work
+0230ec00 gDF .text	014b  Base

bug#53696: Integer overflow on Guix GC size calculation

[Bengt Richter]

Sorry for following up my own post, but maybe it wasn't clear
why I printed (* 17592186042897 (expt 2 20)) in hex ? 

That is the value of [17592186042897 MiB] that you've been discussing.
(expt 2 20) is one MiB

Does that make
> --8<---cut here---start->8---
> $ guile --no-auto-compile -c '(use-modules (ice-9 format))(format #t 
> "~20x\n~20x\n~20d\n" (* 17592186042897 (expt 2 20)) #xa110 #xa110)';
> a110
> a110
>   2702180352
> --8<---cut here---end--->8---
a little clearer?

The discussion seems to be continuing, but no mention of the above.
How come?

Feeling ignored, and top-posting in desperation ;/

CC-ing ludo, who will instantly know where to fix it, if he hasn't already.


On +2022-02-02 13:04:41 +0100, Bengt Richter wrote:
> Hi Maxime, Ekaitz, et al,
> 
> On +2022-02-02 11:05:31 +0100, Maxime Devos wrote:
> > Ekaitz Zarraga schreef op di 01-02-2022 om 14:06 [+]:
> > > [17592186042897 MiB] deleting 
> > > '/gnu/store/wbz6vkiz7cq8c531xvb31lxm28nz332i-ghc-8.10.7'
> > 
> > For comparison, this is about 16 exbibyte.
> > According to ,
> > that's more than the global monthly Internet traffic in 2004.
> > 
> > According to , 16 exbibyte would be about
> > 17 million solid-state disks.  Even though this ignores deduplication,
> > this seems rather expensive. 
> > 
> > My guess is that the size of a store item was misrecorded somewhere.
> > 
> > Greetings,
> > Maxime.
> 
> s/misrecorded/mis-defined-in-record/ ?
> Wild guessing follows:
> 
> --8<---cut here---start->8---
> $ guile --no-auto-compile -c '(use-modules (ice-9 format))(format #t 
> "~20x\n~20x\n~20d\n" (* 17592186042897 (expt 2 20)) #xa110 #xa110)';
> a110
> a110
>   2702180352
> --8<---cut here---end--->8---
> 
> It looks to me like a 32-bit unsigned int should have been turned to 64-bit 
> unsigned long or bigint
> but somehow got cast/interpreted as signed, becoming signed 64-bit long,
> which then in turn was seen by the print as 64-bit unsigned long.
> 
> I don't know, but if records are being used, perhaps some slot 
> integer-widening logic
> might be involved? Or a mis-defined int slot that should have been long to 
> accomodate
> big > 31-bit  positive integers?
> 
> Just guessing wildly -- I think I saw something about records and defining 
> their fields
> as fixed C ints or longs.
> 
> -- 
> Regards,
> Bengt Richter
> 
> 
> 

bug#53645: Unable to guix pull on pinebook pro

[Pierre Langlois]

Hi,

"D. Birch"  writes:

> Thank-you for all the help.
>
> I left the laptop ticking away again after adding 10G of swap.
>
> I've attached the stdout and stderr, as before.
>
> Things got much further and the system was building for the whole day, I left 
> it running overnight and in the morning hit another "bug".
>
> I can't see where the build log is this time to attach.

That's strange that there isn't a log file to report, it looks like
util-linux didn't build but I'm not sure. What you could try is to run
`guix pull -v3' to enable more verbosity, and it should show build
output for packages as it's building them.

> I don't fully understand what guix pull does. If I was to run it again, would 
> everything begin from the start, or is there some chance re-running it would 
> pick up where it left off?

Yeah, luckily guix pull should pickup where it left off and not rebuild
packages that are already built and present in /gnu/store. So normally,
you should only have to go through the couple of days of building once
(Well actually, in normal times we should have binary substitutes that
guix pull can download instead of building them, but the CI is having
issues with aarch64 at the moment :-/.).

That being said, new commits could be pushed and cause new rebuilds
between guix pull invokation, what you can do is pull a specific commit
first:

  guix pull -v3 --commit=2641621  # Commit picked from the log file.

Hope that helps!

Thanks,
Pierre




signature.asc
Description: PGP signature

bug#53736: Guix pull on aarch64 fails

[Maxime Devos]

phodina via Bug reports for GNU Guix schreef op wo 02-02-2022 om 19:57
[+]:
> - 'check' phasebuilder for
> `/gnu/store/993rbp825msc392wqnwnz3mwzjg7cp65-mariadb-10.5.12.drv'
> failed with exit code 1
> build of /gnu/store/993rbp825msc392wqnwnz3mwzjg7cp65-mariadb-
> 10.5.12.drv failed
> View build log at
> '/var/log/guix/drvs/99/3rbp825msc392wqnwnz3mwzjg7cp65-mariadb-
> 10.5.12.drv.bz2'.

To investigate the issue, this build log is required.

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

bug#49083: ‘guix import pypi’ fails in the absence of “sdist” releases

[Maxim Cournoyer]

Hi,

Ludovic Courtès  writes:

> Hi!
>
> So for now I “fixed” it by displaying a hint in commit
> 00762a4c4c8ecdd71cccf6afdd87ae68bf9b4964.
>
> $ ./pre-inst-env guix import pypi jaxlib
> guix import: error: no source release for pypi package jaxlib 0.1.76
>
> hint: This indicates that the package is available on PyPI, but only as a 
> "wheel" containing
> binaries, not source.  To build it from source, refer to the upstream 
> repository at
> `https://github.com/google/jax'.

That's much clearer, thanks!

Maxim

bug#53696: Integer overflow on Guix GC size calculation

[Liliana Marie Prikler]

Hi,

Am Dienstag, dem 01.02.2022 um 21:54 + schrieb Ekaitz Zarraga:
> 
> Hi,
> 
> ‐‐‐ Original Message ‐‐‐
> 
> On Tuesday, February 1st, 2022 at 10:20 PM, Liliana Marie Prikler
>  wrote:
> > 
> > I find it somewhat concerning that you've accumulated more than
> > 2^64 bytes of garbage.
> 
> I'm a dirty boy.
> 
> > Are some items counted double here?
> 
> The number started growing from 0 and then that appeared and it
> continued smoothly from the previous. It's like something went bad in
> the middle.
WDYM by the middle?  Do you mean the jump back to 0 or do you mean
something before those lines?  If you did encounter a "self-correcting"
bit-flip that'd be one thing, but to me it appears as though you have
some very large storage on your hands.  Would you mind me asking where
you purchased that disk 

> > Other than that, that's pretty normal size_t wraparound semantics.
> > I don't think that number is used for anything other than
> > displaying.
> 
> Showing wrong information to the people that use the program is
> pretty weird. The program still works but showing wrong data is worse
> than not showing it in my opinion.
> I'll take a look and try to see if I can fix it.
I mean we could switch to GMP for those numbers, but it doesn't make
sense.  Ext4 volume size is capped at 2^60, which is still pretty well
below 2^64.  Even BTRFS can't get larger than that.  So unless you have
a distributed store, I'd hazard a guess that such numbers ought not to
even appear.

Cheers

bug#53736: Guix pull on aarch64 fails

[phodina via Bug reports for GNU Guix]

Hi,

I've recently done guix pull on foreign Manjaro distro on aarch64.

Unfortunately the build did not go through and I got message about a bug to 
report which happened during check phase of mariadb.

Not exactly sure what should be attached in the email so here's just the last 
messages with the failure.

Petr

-

- 'check' phasebuilder for 
`/gnu/store/993rbp825msc392wqnwnz3mwzjg7cp65-mariadb-10.5.12.drv' failed with 
exit code 1
build of /gnu/store/993rbp825msc392wqnwnz3mwzjg7cp65-mariadb-10.5.12.drv failed
View build log at 
'/var/log/guix/drvs/99/3rbp825msc392wqnwnz3mwzjg7cp65-mariadb-10.5.12.drv.bz2'.
building 
/gnu/store/bqgjwwasppbrq5zw34dzxm2qbac86f9g-module-import-compiled.drv...
cannot build derivation 
`/gnu/store/c4j4n939fxw3gh97yik555zh6ij93fx4-ruby-mysql2-0.5.2.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/7q8hr1qd7pzf6r96vwz3fzsd79m6hn11-ruby-parallel-1.21.0.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/afgi4hr2z420fkyab0dmmihwpzrj6i4g-ruby-byebug-11.1.3.drv': 1 
dependencies couldn't be built
building 
/gnu/store/bzqyvbs7dcgglirhaksxjmay5ql35bxq-module-import-compiled.drv...
cannot build derivation 
`/gnu/store/iakr6hq55flgafkqh30c64pzx4wm9zyi-texlive-hyphen-afrikaans-59745.drv':
 1 dependencies couldn't be built
cannot build derivation 
`/gnu/store/zk9hi2bx018g54xpwckyng02hxar4xda-texlive-hyphen-ancientgreek-59745.drv':
 1 dependencies couldn't be built
cannot build derivation 
`/gnu/store/cmhv2l8dbvg0rn3gl26slzmlwiqpbbps-texlive-hyphen-armenian-59745.drv':
 1 dependencies couldn't be built
cannot build derivation 
`/gnu/store/va6vj6y773kbp3aah7hs2pjzvgdy0ghj-texlive-hyphen-basque-59745.drv': 
1 dependencies couldn't be built
cannot build derivation 
`/gnu/store/inwqzij7pnicsg06khglpbl8p4dm6n4b-texlive-hyphen-belarusian-59745.drv':
 1 dependencies couldn't be built
cannot build derivation 
`/gnu/store/f8dq13f143r3rlgq661zn5adbr65syk5-texlive-hyphen-bulgarian-59745.drv':
 1 dependencies couldn't be built
cannot build derivation 
`/gnu/store/22xkvqlvakjn704d67djgd9ypz101vpg-texlive-hyphen-catalan-59745.drv': 
1 dependencies couldn't be built
cannot build derivation 
`/gnu/store/3dnpmg28k6iizhmqivcn0gz76kl5hdwl-texlive-hyphen-chinese-59745.drv': 
1 dependencies couldn't be built
cannot build derivation 
`/gnu/store/2g0adjydkv79xyzd8l5952ny7ilsyw6w-texlive-hyphen-churchslavonic-59745.drv':
 1 dependencies couldn't be built
cannot build derivation 
`/gnu/store/ddiqcrg8xhqzvk257pib7shskvxs16n4-texlive-hyphen-coptic-59745.drv': 
1 dependencies couldn't be built
cannot build derivation 
`/gnu/store/1qlw9rqxd7yv3akppc2gx15srrswyjpd-texlive-hyphen-croatian-59745.drv':
 1 dependencies couldn't be built
cannot build derivation 
`/gnu/store/s02al1gyklhb9im15vjjyn4bv7jn18qi-texlive-hyphen-czech-59745.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/ifdsmxispbq27w1cfrv4j7madasbah3c-texlive-hyphen-danish-59745.drv': 
1 dependencies couldn't be built
cannot build derivation 
`/gnu/store/bscby29jfin82mk0h2pipirmczxqdf4v-texlive-hyphen-dutch-59745.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/sm74wnr57cbzx10xmq6yln76zi75svr4-texlive-hyphen-english-59745.drv': 
1 dependencies couldn't be built
cannot build derivation 
`/gnu/store/ynq3c5ymsfc4fcicpnl33dw3w5mxran6-texlive-hyphen-esperanto-59745.drv':
 1 dependencies couldn't be built
cannot build derivation 
`/gnu/store/9s0sp6fl17xgijymd85i6g2yfsaj0vnn-texlive-hyphen-estonian-59745.drv':
 1 dependencies couldn't be built
cannot build derivation 
`/gnu/store/2yimkp6cvkqi2qh84bmvfmqbgpvx9hsn-texlive-hyphen-ethiopic-59745.drv':
 1 dependencies couldn't be built
cannot build derivation 
`/gnu/store/x8i0mrr2znxhaqlc1lygg4jx47pgwm0r-texlive-hyphen-finnish-59745.drv': 
1 dependencies couldn't be built
cannot build derivation 
`/gnu/store/nsajqg54jsdgnryh29ia77k14hwi283v-texlive-hyphen-french-59745.drv': 
1 dependencies couldn't be built
cannot build derivation 
`/gnu/store/s5klvw847df9nqmvhxx4k937nq04chzr-texlive-hyphen-friulan-59745.drv': 
1 dependencies couldn't be built
cannot build derivation 
`/gnu/store/0dzhysxcj49xcf9dkx443jg8zi9k40b0-texlive-hyphen-galician-59745.drv':
 1 dependencies couldn't be built
cannot build derivation 
`/gnu/store/wp9kmasbw2ddb95x5ph8ccnym0v0i1rf-texlive-hyphen-georgian-59745.drv':
 1 dependencies couldn't be built
cannot build derivation 
`/gnu/store/n511izc2laqack6vx371hh02yy8ab3ms-texlive-hyphen-german-59745.drv': 
1 dependencies couldn't be built
cannot build derivation 
`/gnu/store/qlwxg7s9dbhcrvpv7aq52qp5fq9kd0qz-texlive-hyphen-greek-59745.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/psizsm1jjd19i6v8l7f2rzllja8cjccr-texlive-hyphen-hungarian-59745.drv':
 1 dependencies couldn't be built
cannot build derivation 
`/gnu/store/rxbk5rn5f9pq926v35lpy35kngch0d1f-texlive-hyphen-icelandic-59745.drv':
 1 

bug#53696: Integer overflow on Guix GC size calculation

[Liliana Marie Prikler]

Hi,

Am Mittwoch, dem 02.02.2022 um 19:51 + schrieb Ekaitz Zarraga:
> I mean something like:
> 
> 0
> 1
> 2
> 4
> 8
> 10
> 12
> HUGE_NUMBER
> HUGE_NUMBER
> ...
> HUGE_NUMBER
> 15
> 20
> ...
> 
> It's like it corrected itself. It happened in "low numbers" (less
> than a
> hundred).
> 
> I just say this if it helps in the correction. It's very funny, still
> :3
Thanks, that wasn't clear from your original report.  As I hinted at in
my previous message, I think you'd get such results through well-placed
bit flips.  I'm not aware of Guix itself intentionally or otherwise
causing those, but bit flips are a problem on any modern hardware and
thus I'm sure such glitches will be encountered.

bug#53696: Integer overflow on Guix GC size calculation

[Ekaitz Zarraga]

Hi,

On Wednesday, February 2nd, 2022 at 8:45 PM, Liliana Marie Prikler 
 wrote:

> Hi,
>
> Am Dienstag, dem 01.02.2022 um 21:54 + schrieb Ekaitz Zarraga:
>
> > Hi,
> >
> > ‐‐‐ Original Message ‐‐‐
> >
> > On Tuesday, February 1st, 2022 at 10:20 PM, Liliana Marie Prikler
> >
> > liliana.prik...@gmail.com wrote:
> >
> > > I find it somewhat concerning that you've accumulated more than
> > >
> > > 2^64 bytes of garbage.
> >
> > I'm a dirty boy.
> >
> > > Are some items counted double here?
> >
> > The number started growing from 0 and then that appeared and it
> > continued smoothly from the previous. It's like something went bad in
> > the middle.
>
> WDYM by the middle? Do you mean the jump back to 0 or do you mean
> something before those lines? If you did encounter a "self-correcting"
> bit-flip that'd be one thing, but to me it appears as though you have
> some very large storage on your hands. Would you mind me asking where
> you purchased that disk 

I mean something like:

0
1
2
4
8
10
12
HUGE_NUMBER
HUGE_NUMBER
...
HUGE_NUMBER
15
20
...

It's like it corrected itself. It happened in "low numbers" (less than a
hundred).

I just say this if it helps in the correction. It's very funny, still :3

bug#53712: Guix System hangs after boot with linux-libre 5.15.17

[Leo Famulari]

Discussion of the problem on a reddit page about Fedora:

https://old.reddit.com/r/Fedora/comments/shhj6e/kernels_above_51516_are_crashing/

They say that 5.15.18 works for them.

bug#53463: ci.guix.gnu.org not building the 'guix' job

[Mathieu Othacehe]

Hello,

The issue here seems to be that the evaluations of the 'guix' jobset are
never finishing, even when the GC is not running.

I tried to strace one of the stuck evaluation process, it returns
repeatedly:

--8<---cut here---start->8---
[pid 36294] read(227, "gmlo\0\0\0\0J\0\0\0\0\0\0\0guix offload: error: failed 
to connect to 'localhost': Connection refused\n\0\0\0\0\0\0", 65536) = 96
[pid 36294] write(239, "gmlo\0\0\0\0J\0\0\0\0\0\0\0guix offload: error: failed 
to connect to 'localhost': Connection refused\n\0\0\0\0\0\0", 96) = 96
[pid 36294] rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
[pid 36294] pselect6(240, [40 227 239], [], [], NULL, NULL) = 1 (in [227])
[pid 36294] read(227, "gmlo\0\0\0\0G\0\0\0\0\0\0\0process 40190 acquired build 
slot '/var/guix/offload/localhost:2224/0'\n\0", 65536) = 88
[pid 36294] write(239, "gmlo\0\0\0\0G\0\0\0\0\0\0\0process 40190 acquired build 
slot '/var/guix/offload/localhost:2224/0'\n\0", 88) = 88
[pid 36294] rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
[pid 36294] pselect6(240, [40 227 239], [], [], NULL, NULL) = 1 (in [227])
[pid 36294] read(227, "gmlo\0\0\0\0J\0\0\0\0\0\0\0guix offload: error: failed 
to connect to 'localhost': Connection refused\n\0\0\0\0\0\0", 65536) = 96
[pid 36294] write(239, "gmlo\0\0\0\0J\0\0\0\0\0\0\0guix offload: error: failed 
to connect to 'localhost': Connection refused\n\0\0\0\0\0\0", 96) = 96
[pid 36294] rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
[pid 36294] pselect6(240, [40 227 239], [], [], NULL, NULL) = 1 (in [227])
[pid 36294] read(227, "gmlo\0\0\0\0G\0\0\0\0\0\0\0process 40190 acquired build 
slot '/var/guix/offload/localhost:2224/0'\n\0", 65536) = 88
[pid 36294] write(239, "gmlo\0\0\0\0G\0\0\0\0\0\0\0process 40190 acquired build 
slot '/var/guix/offload/localhost:2224/0'\n\0", 88) = 88
[pid 36294] rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
[pid 36294] pselect6(240, [40 227 239], [], [], NULL, NULL) = 1 (in [227])
[pid 36294] read(227, "gmlo\0\0\0\0J\0\0\0\0\0\0\0guix offload: error: failed 
to connect to 'localhost': Connection refused\n\0\0\0\0\0\0", 65536) = 96
[pid 36294] write(239, "gmlo\0\0\0\0J\0\0\0\0\0\0\0guix offload: error: failed 
to connect to 'localhost': Connection refused\n\0\0\0\0\0\0", 96) = 96
--8<---cut here---end--->8---

To be continued,

Thanks,

Mathieu

bug#53011: Possible to Update qtbase-5 to v5.15.8?

[Jaft via Bug reports for GNU Guix]

 I don't know if it's the best method to handle this but I tried just applying 
the patch manually with substitute*s.
Whatever point the codebase in the patch is, what's being pulled down by Guix 
doesn't seem to be there yet as one of the files was entirely missing but 
adding the file manually didn't seem to disturb anything and everything was 
able to build alright, for me.
I'm now typing this from Qutebrowser, built with my altered QTwebengine, and 
I've got proper text rendering (at least, for the sites I first noticed text 
rendering failing at and sites that had worked properly, to begin with).
On Wednesday, January 5, 2022, 01:09:58 PM CST, Leo Famulari 
 wrote:  
 
 On Wed, Jan 05, 2022 at 02:08:08PM -0500, Leo Famulari wrote:
> On Tue, Jan 04, 2022 at 07:04:57PM +0100, Florian Bruhin wrote:
> > Alternatively, to fix the issues with missing text, backporting this
> > patch should suffice:
> > https://codereview.qt-project.org/c/qt/qtwebengine-chromium/+/374232
> 
> I'm testing this now.

Oh, the patch does not apply to the source code of our qtwebengine
package. So, I hope that somebody else will take a look and try to fix
this bug.
  * gnu/packages/qt.scm (qtwebengine): Backport fix for text rendering.
---
gnu/packages/qt.scm | 286 
1 file changed, 286 insertions(+)
diff --git a/gnu/packages/qt.scm b/gnu/packages/qt.scm
index ca97725052..111e068094 100644
--- a/gnu/packages/qt.scm
+++ b/gnu/packages/qt.scm
@@ -1878,6 +1878,292 @@ (define (delete-unwanted-files child stat flag base level)
   ;; Respect the '--cores' option of 'guix build'.
   " -j" (number->string (parallel-job-count
#t))
+   ;; Backport
+   ;; https://codereview.qt-project.org/c/qt/qtwebengine-chromium/+/374232
+   ;; to fix broken text rendering.
+   ;; The patch couldn't be applied directly as it does not apply to
+   ;; the source code of our qtwebengine package
+   (add-before 'configure 'fix-text-rendering
+ (lambda _
+   (let ((output-port (open-file "src/3rdparty/chromium/sandbox/linux/system_headers/linux_stat.h" "a")))
+ (display "// Copyright 2021 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#ifndef SANDBOX_LINUX_SYSTEM_HEADERS_LINUX_STAT_H_
+#define SANDBOX_LINUX_SYSTEM_HEADERS_LINUX_STAT_H_
+
+#include 
+
+#include \"build/build_config.h\"
+#include \"sandbox/linux/system_headers/linux_syscalls.h\"
+
+#if defined(ARCH_CPU_MIPS_FAMILY)
+#if defined(ARCH_CPU_64_BITS)
+struct kernel_stat {
+#else
+struct kernel_stat64 {
+#endif
+  unsigned st_dev;
+  unsigned __pad0[3];
+  unsigned long long st_ino;
+  unsigned st_mode;
+  unsigned st_nlink;
+  unsigned st_uid;
+  unsigned st_gid;
+  unsigned st_rdev;
+  unsigned __pad1[3];
+  long long st_size;
+  unsigned st_atime_;
+  unsigned st_atime_nsec_;
+  unsigned st_mtime_;
+  unsigned st_mtime_nsec_;
+  unsigned st_ctime_;
+  unsigned st_ctime_nsec_;
+  unsigned st_blksize;
+  unsigned __pad2;
+  unsigned long long st_blocks;
+};
+#else
+struct kernel_stat64 {
+  unsigned long long st_dev;
+  unsigned char __pad0[4];
+  unsigned __st_ino;
+  unsigned st_mode;
+  unsigned st_nlink;
+  unsigned st_uid;
+  unsigned st_gid;
+  unsigned long long st_rdev;
+  unsigned char __pad3[4];
+  long long st_size;
+  unsigned st_blksize;
+  unsigned long long st_blocks;
+  unsigned st_atime_;
+  unsigned st_atime_nsec_;
+  unsigned st_mtime_;
+  unsigned st_mtime_nsec_;
+  unsigned st_ctime_;
+  unsigned st_ctime_nsec_;
+  unsigned long long st_ino;
+};
+#endif
+
+#if defined(__i386__) || defined(__ARM_ARCH_3__) || defined(__ARM_EABI__)
+struct kernel_stat {
+  /* The kernel headers suggest that st_dev and st_rdev should be 32bit
+   * quantities encoding 12bit major and 20bit minor numbers in an interleaved
+   * format. In reality, we do not see useful data in the top bits. So,
+   * we'll leave the padding in here, until we find a better solution.
+   */
+  unsigned short st_dev;
+  short pad1;
+  unsigned st_ino;
+  unsigned short st_mode;
+  unsigned short st_nlink;
+  unsigned short st_uid;
+  unsigned short st_gid;
+  unsigned short st_rdev;
+  short pad2;
+  unsigned st_size;
+  unsigned st_blksize;
+  unsigned st_blocks;
+  unsigned st_atime_;
+  unsigned st_atime_nsec_;
+  unsigned st_mtime_;
+  unsigned st_mtime_nsec_;
+  unsigned st_ctime_;
+  unsigned st_ctime_nsec_;
+  unsigned __unused4;
+  unsigned __unused5;
+};
+#elif defined(__x86_64__)
+struct kernel_stat {
+  uint64_t st_dev;
+  uint64_t st_ino;
+  uint64_t st_nlink;
+  unsigned st_mode;
+  unsigned st_uid;
+  unsigned st_gid;
+  unsigned __pad0;
+  uint64_t st_rdev;
+  int64_t st_size;
+  int64_t st_blksize;
+  int64_t st_blocks;
+  uint64_t st_atime_;
+  uint64_t st_atime_nsec_;
+ 

bug#53544: [installer] Trying to edit the generated config.scm crashes the installer

[Leo Famulari]

On Wed, Feb 02, 2022 at 06:23:04PM +0100, Mathieu Othacehe wrote:
> I followed the exact same steps on Guix commit
> 4943ac86e4f95a2e14fd209f3fdaac74a0d9ca2e and could not reproduce the
> issue. It was possibly fixed by the wip-harden-installer branch
> merge. Could you please confirm that you have the same behaviour
> locally?

Indeed, it must have been fixed by the recent changes from that branch.
Thanks!

bug#49083: ‘guix import pypi’ fails in the absence of “sdist” releases

[Ludovic Courtès]

Hi!

So for now I “fixed” it by displaying a hint in commit
00762a4c4c8ecdd71cccf6afdd87ae68bf9b4964.

--8<---cut here---start->8---
$ ./pre-inst-env guix import pypi jaxlib
guix import: error: no source release for pypi package jaxlib 0.1.76

hint: This indicates that the package is available on PyPI, but only as a 
"wheel" containing
binaries, not source.  To build it from source, refer to the upstream 
repository at
`https://github.com/google/jax'.
--8<---cut here---end--->8---

Ludo’.

bug#53594: no matching pattern #

[Guu, Jin-Cheng]

I downloaded it form the Guix website. If memory served me right, it was from
https://guix.gnu.org/en/download/latest/

Jin

bug#53594: no matching pattern #

[Mathieu Othacehe]

Hey,

Thanks for the report.

> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> Throw to key `match-error' with args `("match" "no matching
> pattern" # 7f6e64aa7b00>)'.

I had the exact same issue while trying to build an installer
image. Running `make clean-go` and retrying fixed the error. Did you
build the installation image or downloaded it from the Guix website?

Thanks,

Mathieu

bug#53544: [installer] Trying to edit the generated config.scm crashes the installer

[Mathieu Othacehe]

Hello Leo,

> At the end, it shows the generated configuration, and crashes when I
> select "edit". Unfortunately, the installer becomes unresponsive when
> this happens, so I cannot scroll down and read the entire backtrace.

I followed the exact same steps on Guix commit
4943ac86e4f95a2e14fd209f3fdaac74a0d9ca2e and could not reproduce the
issue. It was possibly fixed by the wip-harden-installer branch
merge. Could you please confirm that you have the same behaviour
locally?

Thanks,

Mathieu

bug#53141: installer failed in mkfs.ext4 when installing to the same USB drive

[Mathieu Othacehe]

The latest installer should hide the installation media in the device
selection list, preventing this kind of issues.

Closing,

Thanks,

Mathieu

bug#52680: installer error

[Mathieu Othacehe]

Pushed, thanks.

Mathieu

bug#53696: Integer overflow on Guix GC size calculation

[Bengt Richter]

Hi Maxime, Ekaitz, et al,

On +2022-02-02 11:05:31 +0100, Maxime Devos wrote:
> Ekaitz Zarraga schreef op di 01-02-2022 om 14:06 [+]:
> > [17592186042897 MiB] deleting 
> > '/gnu/store/wbz6vkiz7cq8c531xvb31lxm28nz332i-ghc-8.10.7'
> 
> For comparison, this is about 16 exbibyte.
> According to ,
> that's more than the global monthly Internet traffic in 2004.
> 
> According to , 16 exbibyte would be about
> 17 million solid-state disks.  Even though this ignores deduplication,
> this seems rather expensive. 
> 
> My guess is that the size of a store item was misrecorded somewhere.
> 
> Greetings,
> Maxime.

s/misrecorded/mis-defined-in-record/ ?
Wild guessing follows:

--8<---cut here---start->8---
$ guile --no-auto-compile -c '(use-modules (ice-9 format))(format #t 
"~20x\n~20x\n~20d\n" (* 17592186042897 (expt 2 20)) #xa110 #xa110)';
a110
a110
  2702180352
--8<---cut here---end--->8---

It looks to me like a 32-bit unsigned int should have been turned to 64-bit 
unsigned long or bigint
but somehow got cast/interpreted as signed, becoming signed 64-bit long,
which then in turn was seen by the print as 64-bit unsigned long.

I don't know, but if records are being used, perhaps some slot integer-widening 
logic
might be involved? Or a mis-defined int slot that should have been long to 
accomodate
big > 31-bit  positive integers?

Just guessing wildly -- I think I saw something about records and defining 
their fields
as fixed C ints or longs.

-- 
Regards,
Bengt Richter

bug#53719: Guix lacks ability to customize guix package that gets installed as part of main guix channel

[Gordon Quad via Bug reports for GNU Guix]

According to configure.ac script in guix repo guile-avahi dependency is
optional, and guix package definition has cross-compilation exceptions
for guile-avahi, meaning guix surely can be built without it.

However those checks are hardcoded and there is no way of specifying
that I want to build guix w/o guile-avahi if I am just doing a mere guix pull.

I can make my own package definition for guix by inheriting guix package
and remove guile-avahi dependency but there is no way to supply that
package definition instead of original guix for guix pull.

Moreover there is no simple way to customize guix by doing guix fork
since all the commits are authenticated, which means I either have to
give up authentication completely not only for guix channel but for every
other channel by doing guix pull --disable-authentication or I have to
re-sign every single commit in my local guix repo fork.

I understand that it is part of security model but it is also a
significant obstacle for intent of utilizing the ability to turn
optional dependency off and not have bunch of extra stuff installed on
my system that I don't need.

Perhaps there should be another mechanism for customizing guix from guix
channel?

bug#52963: freedroidrpg: build failure

[Efraim Flashner]

On Wed, Jan 05, 2022 at 11:58:20PM -0500, Leo Famulari wrote:
> On Sun, Jan 02, 2022 at 02:40:55PM -0500, Leo Famulari wrote:
> > On Sun, Jan 02, 2022 at 10:11:01AM -0900, Christopher Howard wrote:
> > > Package "freedroidrpg" fails to build:
> > [...]
> > > ld: addon_crafting_ui.o:(.bss+0x0): multiple definition of 
> > > `tux_rendering'; action.o:(.bss+0x0): first defined here
> > 
> > I think we need to build the package with -fcommon. This is a typical
> > problem with unmaintained or old codebases, now that we have switched to
> > GCC 10.
> > 
> > Are you able to test it? Check the commit log for examples.
> 
> I tried this with the attached patch, but the build failed due to issues
> with how it finds SDL:

It looks like you missed the space after '/include/SDL' for sdl-mixer
when you added '-fcommon'. In any case, it's been fixed by Tobias so I'm
closing the bug.

> --
> gcc -DHAVE_CONFIG_H -I. -I..  
> -DFD_DATADIR='"/gnu/store/kjwi84vzlgxxj0s19nsmfblpipk5rlm6-freedroidrpg-0.16.1/share/freedroidrpg"'
>  -I../lua 
> -DLOCALEDIR='"/gnu/store/kjwi84vzlgxxj0s19nsmfblpipk5rlm6-freedroidrpg-0.16.1/share/locale"'
>   -I/gnu/store/l4k60q5jm9g2f3jslnhjsldls0l4vf9q-sdl-1.2.15/include/SDL 
> -D_GNU_SOURCE=1 -D_REENTRANT  -pipe -Wall -Wno-format-zero-length -ffast-math 
> -I/gnu/store/2qfzwl2k819cdp57xwikhp0i3sl27hma-sdl-gfx-2.0.26/include/SDL 
> -I/gnu/store/h9b8d63bxyjd5hl1mdmicrvl4rhz87vp-sdl-image-1.2.12/include/SDL 
> -I/gnu/store/4n31akz1025w8c9yjfa5mwf9b2q2vv83-sdl-mixer-1.2.12/include/SDL-fcommon
>  -MT armor.o -MD -MP -MF $depbase.Tpo -c -o armor.o armor.c &&\
> mv -f $depbase.Tpo $depbase.Po
> In file included from struct.h:30,
>  from animate.c:33:
> system.h:132:10: fatal error: SDL_mixer.h: No such file or directory
>   132 | #include 
>   |  ^
> In file included from struct.h:30,
>  from addon_crafting_ui.c:24:
> system.h:132:10: fatal error: SDL_mixer.h: No such file or directory
>   132 | #include 
>   |  ^
> compilation terminated.
> compilation terminated.
> make[3]: *** [Makefile:663: addon_crafting_ui.o] Error 1
> make[3]: *** Waiting for unfinished jobs
> make[3]: *** [Makefile:663: animate.o] Error 1
> In file included from action.c:32:
> system.h:132:10: fatal error: SDL_mixer.h: No such file or directory
>   132 | #include 
>   |  ^
> compilation terminated.
> In file included from armor.c:25:
> system.h:132:10: fatal error: SDL_mixer.h: No such file or directory
>   132 | #include 
>   |  ^
> compilation terminated.
> make[3]: *** [Makefile:663: action.o] Error 1
> make[3]: *** [Makefile:663: armor.o] Error 1
> make[3]: Leaving directory 
> '/tmp/guix-build-freedroidrpg-0.16.1.drv-0/freedroidrpg-0.16.1/src'
> make[2]: *** [Makefile:352: all] Error 2
> make[2]: Leaving directory 
> '/tmp/guix-build-freedroidrpg-0.16.1.drv-0/freedroidrpg-0.16.1/src'
> make[1]: *** [Makefile:474: all-recursive] Error 1
> make[1]: Leaving directory 
> '/tmp/guix-build-freedroidrpg-0.16.1.drv-0/freedroidrpg-0.16.1'
> make: *** [Makefile:354: all] Error 2
> error: in phase 'build': uncaught exception:
> %exception #< program: "make" arguments: ("-j" "4") exit-status: 
> 2 term-signal: #f stop-signal: #f> 
> phase `build' failed after 2.6 seconds
> --

> From 6c9bbda796c3528f018bd4590238aeebcbe81feb Mon Sep 17 00:00:00 2001
> From: Leo Famulari 
> Date: Wed, 5 Jan 2022 23:54:33 -0500
> Subject: [PATCH] gnu: FreedroidRPG: Fix build with GCC 10?
> 
> * gnu/packages/games.scm (freedroidrpg)[arguments]: Add -fcommon to CFLAGS.
> ---
>  gnu/packages/games.scm | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/gnu/packages/games.scm b/gnu/packages/games.scm
> index bfd566aac0..e4ddcf8aea 100644
> --- a/gnu/packages/games.scm
> +++ b/gnu/packages/games.scm
> @@ -1365,7 +1365,8 @@ (define-public freedroidrpg
>  (string-append "CFLAGS="
> "-I" (assoc-ref %build-inputs "sdl-gfx") 
> "/include/SDL "
> "-I" (assoc-ref %build-inputs "sdl-image") 
> "/include/SDL "
> -   "-I" (assoc-ref %build-inputs "sdl-mixer") 
> "/include/SDL")
> +   "-I" (assoc-ref %build-inputs "sdl-mixer") 
> "/include/SDL"
> +   "-fcommon") ; Fix build with GCC 10
>  "--enable-opengl")
> ;; FIXME: the test suite fails with the following error output:
> ;;   4586 Segmentation fault  env SDL_VIDEODRIVER=dummy \
> -- 
> 2.34.0
> 




-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#53696: Integer overflow on Guix GC size calculation

[Maxime Devos]

Ekaitz Zarraga schreef op di 01-02-2022 om 14:06 [+]:
> [17592186042897 MiB] deleting 
> '/gnu/store/wbz6vkiz7cq8c531xvb31lxm28nz332i-ghc-8.10.7'

For comparison, this is about 16 exbibyte.
According to ,
that's more than the global monthly Internet traffic in 2004.

According to , 16 exbibyte would be about
17 million solid-state disks.  Even though this ignores deduplication,
this seems rather expensive. 

My guess is that the size of a store item was misrecorded somewhere.

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

bug#52808: Guix home should not assume that all targets are dot files

[Andrew Tropin]

On 2022-01-30 18:13, Ludovic Courtès wrote:

> Hi Andrew,
>
> Andrew Tropin  skribis:
>
>> On 2021-12-26 12:17, Nick Zalutskiy wrote:
>>
>>> The following configuration results in a `~/.run` symlink being
>>> created. My expectation is that a `~/run` symlink is created
>>> instead. (ie. not a dotfile)
>>
>> Some how I missed it and not documented home-files-service-type in the
>> manual, I'll add it soon.  Thank you for mentioning it.  It should break
>> this expectation :)
>>
 (home-environment
   (services
 (list (service
 home-bash-service-type
 (home-bash-configuration
   (guix-defaults? #t)))
   (simple-service 'my-files
   home-files-service-type
   `(("run" ,(local-file "run")))
>>>
>>> This applies to all other targets. My expectation is that the
>>> configuration should expect the exact target and not make an
>>> assumption that all targets are hidden files, since that allows for
>>> more utility:
>
> I share Nick’s surprise.  :-)
>
> [...]
>
>> It's intentional and is a part of a design decision:
>>
>> For example for ("config/guix/channels.scm" ,(local-file "./chans.scm"))
>> chans.scm goes not to ~/.config/guix/channels.scm, but to
>> $XDG_CONFIG_DIR/guix/channels.scm, which can be a different location
>> from ~/.config, absent dot should partially break this expectation.
>>
>> It's a bad practice to use something without "config/..."  prefix and
>> generally it should be avoided, it still possible to use something
>> different in rare use-cases, for example for zsh: ("zshenv"
>> ,zshenv-file-like-here), because it's hard to implement the lookup for
>> initial configuration file other way for shells.
>
> Oh, I see.
>
>> You can elaborate more on what you try to achieve and I can try to give
>> you a recommendation how to implement it.
>
> I’d expect ‘home-files-service-type’ to do just that: add files to the
> home directory, without trying to be smart.
>
> Would it make sense to distinguish between ‘home-files’ and (say)
> ‘home-xdg-configuration-files’?

Yep, I can do that, actually, it will be even better for the purpose I
originally had.  I'll make home-files to store files as it is and
symlink manager not to add leading dots and a separate folder for
xdg configs.

Ludo, Nick, what do you think about following names?
~/.guix-home/home-dir-files/
~/.guix-home/xdg-config-dir-files/

>
> The latter would copy files to $XDG_CONFIG_DIR at activation time,
> whereas the former would just copy them to $HOME.
>
>
> I’d also suggest removing special handling of HOME/files in
> symlink-manager.scm.  Relations between the various components of Guix
> Home should preferably be made explicit via service extensions, and not
> implicit through conventions like this ‘files’ sub-directory.
>
> Thoughts?

Unfortunatelly, I don't know how to implement polymorphic behavior the
other way with current extension mechanism, so I would prefer to keep
this relation implicit, to make it possible to use a different machinery
instead of symlink manager to implement advanced techniques similar to
read-only home from Julien's guix-home-manager.

It's almost impossible to turn off symlink manager unintentionally, so
it should be ok.

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature