bug#25018: GC incorrectly removes the temporary root file of the calling process

[Ludovic Courtès]

Hi Maxim,

Maxim Cournoyer  skribis:

> Ludovic Courtès  writes:
>
>> Hi Maxim,
>>
>> (Stripping Cc:.)
>>
>> Ludovic Courtès  skribis:
>>
>>> Thank you!  (Your bug triage work is much appreciated!)  We could turn
>>> the example here in a unit test; the only downside is that running the
>>> GC in a test is expensive.
>>
>> Actually, there are tests that most likely relied on the previous
>> behavior and are now failing in
>> tests/{derivations,nar,publish,pypi,store}.scm.  We’ll have to look at
>> each one to make sure they are indeed making the wrong assumption and to
>> fix them.
>
> Hmm, I hadn't seen that coming.
>
>> What about reverting the change first so we can do that without
>> pressure and come up with a self-contained patch?
>
> Sounds reasonable, if we can't think of an immediate fix.

I reverted it in eec920ba93ecb086366576e31b785962fbaf81c2.

The way forward will be to review those tests one by one, make sure they
were making the “wrong” assumption, adjust them accordingly, and
possibly add new tests.  It’s not necessarily difficult but takes a bit
of time.  (In the coming weeks I’m going to try and focus on more urgent
matters but I’m happy to review if you or someone else gets to it!)

Thanks,
Ludo’.

bug#58561: Source hash mismatch with aggregator + possible guix bug with hashes.

[zimoun]

Hi Tobias,

On dim., 16 oct. 2022 at 11:45, Tobias Geerinckx-Rice via Bug reports for GNU 
Guix  wrote:

> Oh!  This is a fun one!

Oh, cool!  Thanks for explaining. 


> What Guix could do is refuse to continue when it detects set 
> higher bits, as they always indicate programmer error.

Do you mean another linter?  Or something else?  As a field checker?


Cheers,
simon

bug#58561: Source hash mismatch with aggregator + possible guix bug with hashes.

[zimoun]

Hi,

I am also confused.

On dim., 16 oct. 2022 at 14:42, Brendan Tildesley  wrote:

> sha256 hash mismatch for 
> /gnu/store/iv6ixlrvh0swq22fjal0cbfbr9ayaq7m-akregator-22.04.3.tar.xz:
>    expected hash: 1yy5c29zxpli4cddknmdvjkgii3j7pvw6lhwqfrqjc8jh83gm8f8
>    actual hash: 08n713271i7ifnbrgwrqmxvcpvj45wfqjiidw8zf9rpwxg2m2m9g
>
>
> However what concerned me more is that when I look in the source code it 
> looks like this:
>
> (sha256
>      (base32 "9yy5c29zxpli4cddknmdvjkgii3j7pvw6lhwqfrqjc8jh83gm8f8"))
>
> Notice how at the start its a '9', not a '1'?


Indeed, commit 6971feca53a19d60fdd2b39fb2a8966ccf1d6598 pushed on
core-updates reads,

--8<---cut here---start->8---
 (define-public akregator
   (package
 (name "akregator")
-(version "21.12.3")
+(version "22.04.3")
 (source
  (origin
(method url-fetch)
(uri (string-append "mirror://kde/stable/release-service/" version
"/src/akregator-" version ".tar.xz"))
(sha256
-(base32 "1yy5c29zxpli4cddknmdvjkgii3j7pvw6lhwqfrqjc8jh83gm8f8"
+(base32 "9yy5c29zxpli4cddknmdvjkgii3j7pvw6lhwqfrqjc8jh83gm8f8"
 (build-system qt-build-system)
--8<---cut here---end--->8---

> Is there a bug with how guix is reading/writing sha256 hashes?

Is it a mistake here?  A human-typo replacing ’1’ by ’9’?  Or
something else?  Petr?


Then, indeed KDE did a in-place replacement since the hash is now,

--8<---cut here---start->8---
$ guix download 
https://mirrors.xtom.de/kde/stable/release-service/22.04.3/src/akregator-22.04.3.tar.xz

Starting download of /tmp/guix-file.JTZn04
>From 
>https://mirrors.xtom.de/kde/stable/release-service/22.04.3/src/akregator-22.04.3.tar.xz...
 ….04.3.tar.xz  2.2MiB  
  22.2MiB/s 00:00 [##] 100.0%
/gnu/store/w4jqrza9ffsflim5ilwq7jr75rxicn1g-akregator-22.04.3.tar.xz
08n713271i7ifnbrgwrqmxvcpvj45wfqjiidw8zf9rpwxg2m2m9g
--8<---cut here---end--->8---

as submitted in patch#57608 [1].

1: 


Cheers,
simon

bug#58526: bug report upgrading Guix from 1.0.1 to 1.3

[zimoun]

Hi,

On dim., 16 oct. 2022 at 17:25, Timothée Flutre  wrote:

> Thank you Simon. I copy-pasted your command but I have no file named
> "/gnu/store/n8vdar2f60mvq62g7mngpqwykbm9rw1q-guix-1.2.0rc2-1.0d4b1af".

Hum, the error is about curl, no?  I mean the message reads,

> ./guix/store.scm:1414:15: Throw to key `srfi-34' with args `(# &store-protocol-error [message: "some substitutes for the outputs of 
> derivation `/gnu/store/i6ckkxx8211x9yz3f34wcnbg7mblk7kg-curl-7.84.0.drv' 
> failed (usually happens due to networking issues); try `--fallback' to build 
> derivation from source " status: 1] a58b0c0>)'.

so do I miss something?

Well, could you try to add the option --fallback

   sudo -i guix package --bootstrap --fallback -r guix -i \
 /gnu/store/n8vdar2f60mvq62g7mngpqwykbm9rw1q-guix-1.2.0rc2-1.0d4b1af

?


Cheers,
simon

bug#58567: Some grafts use a different input derivation than computed by --no-grafts

[zimoun]

Hi Marius,

I reminds me this [1].

1: 


On dim., 16 oct. 2022 at 19:35, Marius Bakke  wrote:

> It works for 'python-patiencediff', but fails for 'python-patch-ng',
> both of which have no dependencies other than Python; but one uses
> url-fetch and the other git-fetch.

I guess that

   guix build python-patch-ng -d

uses a grafted git-minimal and propagates it, whereas

   guix build python-patch-ng -d --no-grafts

uses a non-grafted git-minimal.  Well, something like that. :-)


Here some investigations for what they are worth.

--8<---cut here---start->8---
$ guix time-machine --commit=3d8c243efb615c7e642942433be1c7badf0ae65e \
   -- build python-patch-ng -d 
/gnu/store/gy6ksy7h02qi062wwh00wqxfjzqj7vjg-python-patch-ng-1.17.4.drv
--8<---cut here---end--->8---

where the no-grafted is,

/gnu/store/xi035mv5cv8j9d2sm8hcwi293vcix28q-python-patch-ng-1.17.4.drv

and the command-line non-grafted reads,

--8<---cut here---start->8---
$ guix time-machine --commit=3d8c243efb615c7e642942433be1c7badf0ae65e \
   -- build python-patch-ng -d --no-grafts
/gnu/store/v4w24l63864x2304pv9a9fz3knzf1lxb-python-patch-ng-1.17.4.drv
--8<---cut here---end--->8---

However, both derivations have the same output.

--8<---cut here---start->8---
$ guix build \
  /gnu/store/xi035mv5cv8j9d2sm8hcwi293vcix28q-python-patch-ng-1.17.4.drv \
  /gnu/store/v4w24l63864x2304pv9a9fz3knzf1lxb-python-patch-ng-1.17.4.drv
/gnu/store/d6nhxbayyal1nximx048bvk6zx4phcap-python-patch-ng-1.17.4
/gnu/store/d6nhxbayyal1nximx048bvk6zx4phcap-python-patch-ng-1.17.4
--8<---cut here---end--->8---

The difference in the derivation hash comes from the order and checkout,

   ,("/gnu/store/52aymnx4px77ig2irmi16nncb9d27z9y-gawk-5.1.0.drv",["out"])
   
,("/gnu/store/7bcypqy80bz8ygi4880dxdj8vzcsvhdf-python-patch-ng-1.17.4-checkout.drv",["out"])
   ,("/gnu/store/7p8m2v35lrjmgffv7map1cmn45vi0pkm-binutils-2.37.drv",["out"])

vs

   ,("/gnu/store/h5nligvx7n87jg0zxsiw536lz0q1gr3j-tar-1.34.drv",["out"])
   
,("/gnu/store/ivbkmnl6md7lzf275nvqwdh6lc924hal-python-patch-ng-1.17.4-checkout.drv",["out"])
   
,("/gnu/store/jj494gyb7r3jnn15jd240dn5zd6crnyk-bash-minimal-5.1.8.drv",["out"])


Well, it is the same checkout output:

--8<---cut here---start->8---
$ guix build \
   
/gnu/store/7bcypqy80bz8ygi4880dxdj8vzcsvhdf-python-patch-ng-1.17.4-checkout.drv 
\
   
/gnu/store/ivbkmnl6md7lzf275nvqwdh6lc924hal-python-patch-ng-1.17.4-checkout.drv
/gnu/store/jddbmm7nxhv9sl84j1jlsdy5iiwjpbiy-python-patch-ng-1.17.4-checkout
/gnu/store/jddbmm7nxhv9sl84j1jlsdy5iiwjpbiy-python-patch-ng-1.17.4-checkout
--8<---cut here---end--->8---

Again, the checkout derivation hash is different because order and an
item,

   ,("/gnu/store/6ynvjkk6yzkpsl0x703hlvdrmp96plm1-guile-zlib-0.1.0.drv",["out"])
   
,("/gnu/store/7df196dbwb4w03q8wnvfys0j5npnqbcd-git-minimal-2.38.0.drv",["out"])
   ,("/gnu/store/cmiqs6lp2ss4i3f9cy5vsinh7795bxcy-gzip-1.10.drv",["out"])

vs

   ,("/gnu/store/ifvnf3rwyhhgjman6qn332j2sfn8hlp5-guile-json-4.7.1.drv",["out"])
   
,("/gnu/store/q074d9578lbq2y9ls5xycbm0jmyr1z75-git-minimal-2.38.0.drv",["out"])
   ,("/gnu/store/snyyq4ssjff5ajwswwg4absrhfv8pc4z-tar-1.34.drv",["out"])

And the Git is probably the root of the final mismatch.

--8<---cut here---start->8---
$ guix time-machine --commit=3d8c243efb615c7e642942433be1c7badf0ae65e \
   -- build git-minimal -d --no-grafts
/gnu/store/7df196dbwb4w03q8wnvfys0j5npnqbcd-git-minimal-2.38.0.drv

$ guix time-machine --commit=3d8c243efb615c7e642942433be1c7badf0ae65e \
   -- build git-minimal -d
/gnu/store/q074d9578lbq2y9ls5xycbm0jmyr1z75-git-minimal-2.38.0.drv
--8<---cut here---end--->8---


Cheers,
simon

bug#58419: Grafting order depends on store connection state

[Ludovic Courtès]

Hi,

Ludovic Courtès  skribis:

> If we squint a bit, we realize it’s the same thing but in a different
> order, which is good news: it’s functionally equivalent.
>
> The downside is obvious: it’s stupidly non-deterministic, and we can end
> up building the same grafts multiple times.
>
> The order differs in two places: in the definition of ‘%build-inputs’,
> and in the definition of the ‘mapping’ variable.  This can be solved by
> sorting things in the right place, but that needs some thought.

I posted a patch series that fixes this as a side-effect of switching to
‘gexp->derivation’:

  https://issues.guix.gnu.org/58579

That eliminates ‘%build-inputs’, which was one source of differences,
and the ‘mapping’ variable is now populated in a deterministic fashion,
though I must say it’s not entirely clear to me why this part has
changed.

Feedback welcome!

Ludo’.

bug#58567: Some grafts use a different input derivation than computed by --no-grafts

[zimoun]

Hi,

On dim., 16 oct. 2022 at 19:06, Marius Bakke  wrote:

> As an example, as of commit 3d8c243efb615c7e642942433be1c7badf0ae65e,
> 'guix build -d telegram-desktop' produces:
>
>   /gnu/store/q1gx5xaszlyyr0sx663c2qkx92cqbr4r-telegram-desktop-4.2.2.drv
>
> If we open that graft derivation, we see that it depends on:
>
>   /gnu/store/92bl6qmj5r0byc59fykvlfaqmw6ikvy8-telegram-desktop-4.2.2.drv
>
> However:
>
>   $ guix build -d --no-grafts telegram-desktop
>   /gnu/store/4vbj4gblmwvl645z1q3aaxfhckjqi3kg-telegram-desktop-4.2.2.drv

--8<---cut here---start->8---
$ guix build 
/gnu/store/92bl6qmj5r0byc59fykvlfaqmw6ikvy8-telegram-desktop-4.2.2.drv
/gnu/store/in8b3sycbpjmy1jk8887b1siwycmm19y-telegram-desktop-4.2.2

  vs

$ guix build 
/gnu/store/4vbj4gblmwvl645z1q3aaxfhckjqi3kg-telegram-desktop-4.2.2.drv
/gnu/store/qhd9qyma22k12gbp0f0yi1389wyiai64-telegram-desktop-4.2.2
--8<---cut here---end--->8---

Indeed that’s an issue.  Examining,

/gnu/store/vv1f598yc17rl08059625cw61ig0c3k0-telegram-desktop-4.2.2-builder
  vs
/gnu/store/qjw2k2dzvw51rxa5k9mr7i41ql4gwr28-telegram-desktop-4.2.2-builder


the differences are,

 ("fcitx-qt5" . 
"/gnu/store/swyjasxcnlbxavpaiaginsyzr1gdpban-fcitx-qt5-1.2.6")

  vs

 ("fcitx-qt5" . 
"/gnu/store/k184g9bj05zz0lnz7j5h1zsrjavdadwp-fcitx-qt5-1.2.6")


and

   "/gnu/store/ir6lpakwwj897lbjfn4n9kmxiqxs377l-qtbase-5.15.5"

  vs

   "/gnu/store/w66rzihchl7n9d1zpr2qvgiyd58zr2pp-qtbase-5.15.5"



Cheers,
simon

bug#58581: Ungoogled-chromium cannot "cast" to a projector

[Nicolas Goaziou]

Hello,

I noticed that our "ungoogled-chromium" package allows me to list
available Chromecast devices on the network, but when I connect to
one --- the list of devices mention there's a connection to it ---,
I only get a black screen.

As a data point, Debian's own chromium doesn't have this issue.

On the terminal, I can see the following error:

  libva error: vaGetDriverNameByIndex() failed with unknown libva error, 
driver_name = (null)

but I don't know if it is related.

Regards,
-- 
Nicolas Goaziou

bug#58567: Some grafts use a different input derivation than computed by --no-grafts

[Marius Bakke]

zimoun  skriver:

> Hi Marius,
>
> I reminds me this [1].
>
> 1: 

Not sure if it's the same problem, but it is weird.  On 3d8c243efb615c7:

  $ guix build mesa
  /gnu/store/ccf705wvh0w224d6nyscnwlhqr04agk7-mesa-21.3.8-bin
  /gnu/store/vcmxgmmhwr39gwwnz7ljkhcg1bmq2r5z-mesa-21.3.8
  $ guix build --no-grafts mesa
  /gnu/store/grh2142hg6l5g5xav2di7rr1pwbg9m38-mesa-21.3.8-bin
  /gnu/store/sdzfljm6san79pqiy42yp0nzmkr2bafc-mesa-21.3.8
  $ guix size icecat | grep mesa
  /gnu/store/sdzfljm6san79pqiy42yp0nzmkr2bafc-mesa-21.3.8411.6   
169.6  11.6%
  $ guix size $(guix build --no-grafts icecat) | grep mesa
  /gnu/store/sdzfljm6san79pqiy42yp0nzmkr2bafc-mesa-21.3.8411.6   
169.6  11.6%

Should not the mesa used by icecat be the same as `guix build mesa`,
just like in the ungrafted case?  Their outputs differ, too:

  $ guix hash -r $(guix build mesa | tail -n1)
  1invy9jcd1fnfx7d4asfyjqs1jn7lngjfqswak6sy9ffjbhhsg6x
  $ guix hash -r $(guix size icecat | grep mesa | awk '{ print $1 }')
  195zk0c0h5m016hp0c1haqws47rwfj7sbpqpddmwk2iw402p3apv

Diffoscope says it will take 123 days to process these, so don't hold
your breath!

> On dim., 16 oct. 2022 at 19:35, Marius Bakke  wrote:
>
>> It works for 'python-patiencediff', but fails for 'python-patch-ng',
>> both of which have no dependencies other than Python; but one uses
>> url-fetch and the other git-fetch.
>
> I guess that
>
>guix build python-patch-ng -d
>
> uses a grafted git-minimal and propagates it, whereas
>
>guix build python-patch-ng -d --no-grafts
>
> uses a non-grafted git-minimal.  Well, something like that. :-)

Indeed.

> Well, it is the same checkout output:
>
> --8<---cut here---start->8---
> $ guix build \
>
> /gnu/store/7bcypqy80bz8ygi4880dxdj8vzcsvhdf-python-patch-ng-1.17.4-checkout.drv
>  \
>
> /gnu/store/ivbkmnl6md7lzf275nvqwdh6lc924hal-python-patch-ng-1.17.4-checkout.drv
> /gnu/store/jddbmm7nxhv9sl84j1jlsdy5iiwjpbiy-python-patch-ng-1.17.4-checkout
> /gnu/store/jddbmm7nxhv9sl84j1jlsdy5iiwjpbiy-python-patch-ng-1.17.4-checkout
> --8<---cut here---end--->8---

That's guaranteed since these derivations are "fixed-output" (notice the
r:sha256 property in the beginning of the file).  If they had any other
output the daemon would throw a failure.

The bug here is that Guix treats grafted origins as different, even
though their outputs are known in advance.

Probably the grafting machinery should ignore fixed-output derivations
somehow?


signature.asc
Description: PGP signature

bug#58561: [PATCH 2/2] gnu: akregator: Fix build.

[Marius Bakke]

phodina via Bug reports for GNU Guix  skriver:

> Hi,
>
> unfortunately incorrect hash was pushed in the last patchset.
>
> The patch is already part of the next patch series [1].
>
> Also it's tracked here [2].
>
> 1 
> https://github.com/phodina/guix/commit/4636279dfb3b96eb5836baad0d8ea36e58ff79ee
> 2 https://issues.guix.gnu.org/57608#8

Whoops, I had missed these patches and pushed similar fixes to 'master':

  8681d90d50 gnu: akgregator: Fix source hash.
  3d8c243efb gnu: akgregator: Fix build.

Sorry for the duplicate work Brendan & Petr!


signature.asc
Description: PGP signature

bug#58567: Some grafts use a different input derivation than computed by --no-grafts

[Marius Bakke]

Marius Bakke  skriver:

> zimoun  skriver:
>
>> Hi Marius,
>>
>> I reminds me this [1].
>>
>> 1: 
>
> Not sure if it's the same problem, but it is weird.  On 3d8c243efb615c7:
>
>   $ guix build mesa
>   /gnu/store/ccf705wvh0w224d6nyscnwlhqr04agk7-mesa-21.3.8-bin
>   /gnu/store/vcmxgmmhwr39gwwnz7ljkhcg1bmq2r5z-mesa-21.3.8
>   $ guix build --no-grafts mesa
>   /gnu/store/grh2142hg6l5g5xav2di7rr1pwbg9m38-mesa-21.3.8-bin
>   /gnu/store/sdzfljm6san79pqiy42yp0nzmkr2bafc-mesa-21.3.8
>   $ guix size icecat | grep mesa
>   /gnu/store/sdzfljm6san79pqiy42yp0nzmkr2bafc-mesa-21.3.8411.6   
> 169.6  11.6%
>   $ guix size $(guix build --no-grafts icecat) | grep mesa
>   /gnu/store/sdzfljm6san79pqiy42yp0nzmkr2bafc-mesa-21.3.8411.6   
> 169.6  11.6%

Derp, the last two should be:

  $ guix size $(guix build icecat) | grep mesa
  /gnu/store/dbrsf4wmjjxwd3cvnbfrvikilj42gamy-mesa-21.3.8411.6   
169.6  11.6%
  $ guix size $(guix build --no-grafts icecat) | grep mesa
  /gnu/store/sdzfljm6san79pqiy42yp0nzmkr2bafc-mesa-21.3.8411.6   
169.6  11.6%

('guix size' implicitly disables grafts)


signature.asc
Description: PGP signature

bug#58567: Some grafts use a different input derivation than computed by --no-grafts

[Marius Bakke]

Marius Bakke  skriver:

> Should not the mesa used by icecat be the same as `guix build mesa`,
> just like in the ungrafted case?  Their outputs differ, too:
>
>   $ guix hash -r $(guix build mesa | tail -n1)
>   1invy9jcd1fnfx7d4asfyjqs1jn7lngjfqswak6sy9ffjbhhsg6x
>   $ guix hash -r $(guix size icecat | grep mesa | awk '{ print $1 }')
>   195zk0c0h5m016hp0c1haqws47rwfj7sbpqpddmwk2iw402p3apv

Errh, the difference in output is not surprising since mesa obviously
contains references to itself.  Different derivation, different store
file name.

> Diffoscope says it will take 123 days to process these, so don't hold
> your breath!

It did not take 123 days, but I had diffed the wrong mesa.  Will update
if the difference is anything other than the mesa store file name...


signature.asc
Description: PGP signature

bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd)

[Ludovic Courtès]

Hi,

Ludovic Courtès  skribis:

> … so ‘exec_load’ is doing its job, it seems.

Turns out that may not be the case.

Here’s a *bad* mapping on the second ‘task_resume’ breakpoint (when
‘exec’ is about to start):

--8<---cut here---start->8---
  db> show all threads
  TASKTHREADS
0 gnumach (f5f7cf00): 7 threads:
0 (f5f7be18) .W..N. 0xc11dac04
1 (f5f7bcd0) R..O..(idle_thread_continue)
2 (f5f7bb88) .W.ON.(reaper_thread_continue) 0xc12015d4
3 (f5f7ba40) .W.ON.(swapin_thread_continue) 0xc11f8e2c
4 (f5f7b8f8) .W.ON.(sched_thread_continue) 0
5 (f5f7b7b0) .W.ON.(io_done_thread_continue) 0xc1201f74
6 (f5f7b668) .W.ON.(net_thread_continue) 0xc11db0a8
1 ext2fs (f5f7ce40): 6 threads:
0 (f5f7b520) RF
1 (f5f7b290) .W.O..(mach_msg_receive_continue) 0
2 (f5f7b148) .W.O..(mach_msg_receive_continue) 0
3 (f5f7b000) .W.O..(mach_msg_continue) 0
4 (f67d3e20) .W.O..(mach_msg_receive_continue) 0
5 (f67d3cd8) .W.O..(mach_msg_continue) 0
2 exec (f5f7cd80): (f5f7b3d8) ..SO..(thread_bootstrap_return)
   db> trace
  task_resume(f593e010,fb7d9010,f5f73e80,c106972a)
  ipc_kobject_server(f593e000,3,18,0)+0x1eb
  mach_msg_trap(b4c0,3,18,20,8)+0x1703
  > user space <
  db> x/tbx 0xcbc 0xf5f7b3d8

  no memory is assigned to address 0cbc
  0
  db> show map $map2
Map 0xf5f6ff30: name="exec", pmap=0xf5f71fa8,ref=1,nentries=5
  size=290816,resident:225280,wired=0
  version=13
 map entry 0xf625ec08: start=0x0, end=0x1000
 prot=1/7/copy, object=0x0, offset=0x0
 map entry 0xf625ebb0: start=0x1000, end=0x26000
 prot=5/7/copy, object=0xf5f6ad70, offset=0x0
  Object 0xf5f6ad70: size=0x25000, 1 references
  37 resident pages, 0 absent pages, 0 paging ops
   memory object=0x0 (offset=0x0),control=0x0, name=0xf5f82780
   uninitialized,temporaryinternal,copy_strategy=0
   shadow=0x0 (offset=0x0),copy=0x0
 map entry 0xf625eb58: start=0x26000, end=0x34000
 prot=1/7/copy, object=0xf5f6ad20, offset=0x0
  Object 0xf5f6ad20: size=0xe000, 1 references
  14 resident pages, 0 absent pages, 0 paging ops
   memory object=0x0 (offset=0x0),control=0x0, name=0xf5f82730
   uninitialized,temporaryinternal,copy_strategy=0
   shadow=0x0 (offset=0x0),copy=0x0
 map entry 0xf625eb00: start=0x34000, end=0x37000
 prot=3/7/copy, object=0xf5f6acd0, offset=0x0
  Object 0xf5f6acd0: size=0x3000, 1 references
  3 resident pages,--db_more--
--8<---cut here---end--->8---

Compare with what a “good” mapping looks like at that same moment:

--8<---cut here---start->8---
  start ext2fs: Hurd server bootstrap: ext2fs[device:hd0s1]Kernel Breakpoint 
trap,
   eip 0xc1030d5b
  Breakpoint at  task_resume: pushl   %ebp
  db> show all threads
  TASKTHREADS
0 gnumach (f5f7cf00): 7 threads:
0 (f5f7be18) .W..N. 0xc11dac04
1 (f5f7bcd0) R..O..(idle_thread_continue)
2 (f5f7bb88) .W.ON.(reaper_thread_continue) 0xc12015d4
3 (f5f7ba40) .W.ON.(swapin_thread_continue) 0xc11f8e2c
4 (f5f7b8f8) .W.ON.(sched_thread_continue) 0
5 (f5f7b7b0) .W.ON.(io_done_thread_continue) 0xc1201f74
6 (f5f7b668) .W.ON.(net_thread_continue) 0xc11db0a8
1 ext2fs (f5f7ce40): 6 threads:
0 (f5f7b520) RF
1 (f5f7b290) .W.O..(mach_msg_receive_continue) 0
2 (f5f7b148) .W.O..(mach_msg_receive_continue) 0
3 (f5f7b000) .W.O..(mach_msg_continue) 0
4 (f67d2e20) .W.O..(mach_msg_receive_continue) 0
5 (f67d2cd8) .W.O..(mach_msg_continue) 0
2 exec (f5f7cd80): (f5f7b3d8) ..SO..(thread_bootstrap_return)
  db> x/tbx 0xcbc 0xf5f7b3d8
  8
  db> show map $map2
  Map 0xf5f6ff30: name="exec", pmap=0xf5f71fa8,ref=1,nentries=5
  size=290816,resident:229376,wired=0
  version=14
   map entry 0xf625ec08: start=0x0, end=0x1000
   prot=1/7/copy, object=0xf5f6ad70, offset=0x0
Object 0xf5f6ad70: size=0x1000, 1 references
1 resident pages, 0 absent pages, 0 paging ops
 memory object=0x0 (offset=0x0),control=0x0, name=0xf5f82780
 uninitialized,temporary  internal,copy_strategy=0
 shadow=0x0 (offset=0x0),copy=0x0
   map entry 0xf625ebb0: start=0x1000, end=0x26000
   prot=5/7/copy, object=0xf5f6ad20, offset=0x0
Object 0xf5f6ad20: size=0x25000, 1 references
37 resident pages, 0 absent pages, 0 paging ops
 memory object=0x0 (offset=0x0),control=0x0, name=0xf5f82730
 uninitialized,temporary  internal,copy_strategy=0
 shadow=0x0 (offset=0x0),copy=0x0
   map entry 0xf625eb58: start=0x26000, end=0x34000
   prot=1/7/copy, object=0x

bug#58567: Some grafts use a different input derivation than computed by --no-grafts

[zimoun]

Hi Marius,

On lun., 17 oct. 2022 at 13:36, Marius Bakke  wrote:

>> 1: 
>
> Not sure if it's the same problem, but it is weird.

About mesa, the graft machinery produces two different items with the
same content.  It is because multi-outputs; as pointed in [1].


> The bug here is that Guix treats grafted origins as different, even
> though their outputs are known in advance.

About python-patch-ng, I miss the origin of the difference, e.g.,

--8<---cut here---start->8---
diff -r --no-dereference 
/gnu/store/a58yf1jbryyffzs4i8zp8ywns1b5hrvs-python-patch-ng-1.17.4/lib/python3.9/site-packages/patch_ng.py
 
/gnu/store/d6nhxbayyal1nximx048bvk6zx4phcap-python-patch-ng-1.17.4/lib/python3.9/site-packages/patch_ng.py
1c1
< #!/gnu/store/9qz2zckx1mlcg8lijl7rb4fyxygv32ml-python-wrapper-3.9.9/bin/python
---
> #!/gnu/store/slsh0qjv5j68xda2bb6h8gsxwyi1j25a-python-wrapper-3.9.9/bin/python
Binary files 
/gnu/store/a58yf1jbryyffzs4i8zp8ywns1b5hrvs-python-patch-ng-1.17.4/lib/python3.9/site-packages/__pycache__/patch_ng.cpython-39.pyc
 and 
/gnu/store/d6nhxbayyal1nximx048bvk6zx4phcap-python-patch-ng-1.17.4/lib/python3.9/site-packages/__pycache__/patch_ng.cpython-39.pyc
 differ
--8<---cut here---end--->8---

and then, this python-wrapper reads,

--8<---cut here---start->8---
$ guix gc --derivers 
/gnu/store/9qz2zckx1mlcg8lijl7rb4fyxygv32ml-python-wrapper-3.9.9
/gnu/store/xm26mvbldnqa081mbnnlcikn30xxvzrg-python-wrapper-3.9.9.drv

$ guix gc --derivers 
/gnu/store/slsh0qjv5j68xda2bb6h8gsxwyi1j25a-python-wrapper-3.9.9
/gnu/store/28b2j5m498bry3x33by2y7h8ms5fsxmk-python-wrapper-3.9.9.drv
/gnu/store/d78g4awha9cplcxmz7ssxdd1jgn55iym-python-wrapper-3.9.9.drv
/gnu/store/l2x2bh5l37cjiifv9qws9700vb0h583j-python-wrapper-3.9.9.drv
--8<---cut here---end--->8---


About telegram-desktop, it is probably another origin of difference.
See [2].

2: 


> Probably the grafting machinery should ignore fixed-output derivations
> somehow?

Well, I do not know what could be fixed about all these mysteries. :-)


Cheers,
simon

bug#58567: Grafting affects origins

[Ludovic Courtès]

Hi,

Marius Bakke  skribis:

> As an example, as of commit 3d8c243efb615c7e642942433be1c7badf0ae65e,
> 'guix build -d telegram-desktop' produces:
>
>   /gnu/store/q1gx5xaszlyyr0sx663c2qkx92cqbr4r-telegram-desktop-4.2.2.drv
>
> If we open that graft derivation, we see that it depends on:
>
>   /gnu/store/92bl6qmj5r0byc59fykvlfaqmw6ikvy8-telegram-desktop-4.2.2.drv
>
> However:
>
>   $ guix build -d --no-grafts telegram-desktop
>   /gnu/store/4vbj4gblmwvl645z1q3aaxfhckjqi3kg-telegram-desktop-4.2.2.drv

The differences between these two are:

--- #
+++ #
@@ -44,7 +44,7 @@
 	  ("abseil-cpp" . "/gnu/store/lsrda46kb137fnwslwhg9bpqgnakasy8-abseil-cpp-20220623.1")
 	  ("alsa-lib" . "/gnu/store/nfxcjvv9c2q6in9x52kkkayqv38k00ai-alsa-lib-1.2.4")
 	  ("c++-gsl" . "/gnu/store/bpszfya32r8zj0rhaijckh5bj6fmj709-c++-gsl-3.1.0")
-	  ("fcitx-qt5" . "/gnu/store/swyjasxcnlbxavpaiaginsyzr1gdpban-fcitx-qt5-1.2.6")
+	  ("fcitx-qt5" . "/gnu/store/k184g9bj05zz0lnz7j5h1zsrjavdadwp-fcitx-qt5-1.2.6")
 	  ("fcitx5-qt" . "/gnu/store/cbpycbi5r23dgwl7k20g6h0kkmznz7pz-fcitx5-qt-5.0.7")
 	  ("ffmpeg" . "/gnu/store/jhd8y6a2j9jcx0icq25qdhs1m8i8qfy7-ffmpeg-4.4.2")
 	  ("glib" . "/gnu/store/96srhmpmxa20wmsck95g3iq4hb3lz4a0-glib-2.70.2")
@@ -250,7 +250,7 @@
 		  (quote glib-or-gtk-wrap)
 		(assoc-ref glib-or-gtk:%standard-phases
 			   (quote glib-or-gtk-wrap
-	#:qtbase "/gnu/store/ir6lpakwwj897lbjfn4n9kmxiqxs377l-qtbase-5.15.5" #:qt-wrap-excluded-outputs
+	#:qtbase "/gnu/store/w66rzihchl7n9d1zpr2qvgiyd58zr2pp-qtbase-5.15.5" #:qt-wrap-excluded-outputs
 	(quote
 	 ())
 	#:qt-wrap-excluded-inputs


I believe that’s a bug in ‘qt-build-system’: like ‘gnu-build-system’, it
should pass #:graft? #f (patch below).  Failing that, it’ll end up using
a different #:qtbase depending on whether or not grafts are enabled.

Does that make sense?

I found a similar issue in ‘python-build-system’ in
.

Thanks,
Ludo’.

diff --git a/guix/build-system/qt.scm b/guix/build-system/qt.scm
index a9bf728f25..7e3a54f1f8 100644
--- a/guix/build-system/qt.scm
+++ b/guix/build-system/qt.scm
@@ -181,6 +181,7 @@ (define builder
   (mlet %store-monad ((guile (package->derivation (or guile (default-guile))
   system #:graft? #f)))
 (gexp->derivation name builder
+  #:graft? #f ;consistent with 'gnu-build'
   #:system system
   #:guile-for-build guile)))
 
@@ -269,6 +270,7 @@ (define %outputs
   (mlet %store-monad ((guile (package->derivation (or guile (default-guile))
   system #:graft? #f)))
 (gexp->derivation name builder
+  #:graft? #f ;consistent with 'gnu-build'
   #:system system
   #:guile-for-build guile)))
 

bug#58290: guile ssh error on guix deploy

[Ludovic Courtès]

Hi,

Andrew Tropin  skribis:

>>> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
>>> Throw to key `guile-ssh-error' with args `("channel-open-session" "Channel 
>>> opening failure: channel 67 error (2) open failed" #>> (closed) 7f7d1af9e140> #f)'.
>>
>> Are there any hints from sshd in the /var/log/messages of that machine
>> as to why the connection was closed?
>
> bob@pinky /var/log$ zcat messages.1.gz | grep "Oct  4" | grep ssh

It’s hard (if not impossible) to see which lines correspond to the error
above.  :-)

Could try to reproduce the bug, and have ‘tail -f /var/log/messages’
running on the server side so you can capture just the right lines?
/var/log/debug might be interesting too.

Thanks,
Ludo’.

bug#58571: translations are incompletely pulled from weblate

[pelzflorian (Florian Pelz)]

two--- via Bug reports for GNU Guix  writes:
> hi
> in https://git.savannah.gnu.org/cgit/guix.git/tree/po/guix/uk.po i see
> kyrylo's translations are pulled there from weblate, but mine
> (https://translate.fedoraproject.org/changes/?project=guix&lang=uk&user=two22)
> are not, these strings stay untranslated or erroneous.

This is strange and I do not yet see what could be the cause.

Weblate is backed not by savannah but by an intermediate repository
https://framagit.org/tyreunom/guix-translations
which Julien regularly syncs with Savannah each month.

Perhaps could you try changing a translation on Weblate and see if there
is a change to ?  It
will sync faster if after you make the change on Weblate, you use
Weblate’s File download button.

Regards,
Florian

bug#58290: guile ssh error on guix deploy

[Marius Bakke]

Ludovic Courtès  skriver:

> Hi,
>
> Andrew Tropin  skribis:
>
 ice-9/boot-9.scm:1685:16: In procedure raise-exception:
 Throw to key `guile-ssh-error' with args `("channel-open-session" "Channel 
 opening failure: channel 67 error (2) open failed" #>>> (closed) 7f7d1af9e140> #f)'.
>>>
>>> Are there any hints from sshd in the /var/log/messages of that machine
>>> as to why the connection was closed?
>>
>> bob@pinky /var/log$ zcat messages.1.gz | grep "Oct  4" | grep ssh
>
> It’s hard (if not impossible) to see which lines correspond to the error
> above.  :-)
>
> Could try to reproduce the bug, and have ‘tail -f /var/log/messages’
> running on the server side so you can capture just the right lines?
> /var/log/debug might be interesting too.

I have the same problem.  Log messages around failure look something
like this (extracted from above message):

  Oct  4 11:51:49 localhost shepherd[1]: Service sshd-2 has been started. 
  Oct  4 11:51:50 localhost sshd[250]: Accepted publickey for bob from 
185.70.53.164 port 1915 ssh2: RSA 
SHA256:/X3jyhyMizAOKOjCfXK5cLN3Pa0vmi7dbQG+fxK3d3Y
  Oct  4 11:52:28 localhost sshd[252]: error: no more sessions
  Oct  4 11:52:28 localhost shepherd[1]: 1 connection still in use after sshd-2 
termination. 
  Oct  4 11:52:28 localhost shepherd[1]: Service sshd-2 has been disabled. 

Then deploy crashes with 'Channel opening failure'.

Due to the number of SSH connections made by deploy and frequent
occurence of this problem, I was not able to successfully deploy through
many attempts.

I found that removing the memoizing open-machine-ssh-session* in
(gnu machine ssh) works around it and can happily deploy again.

(that is, just use 'open-machine-ssh-session' instead)


signature.asc
Description: PGP signature

bug#58526: bug report upgrading Guix from 1.0.1 to 1.3

[Timothée Flutre]

Hello Simon,

I have curl on my computer (v7.81.0). I tried running your command but it
failed, returning the following:
~$ sudo -i guix package --bootstrap --fallback -r guix -i
/gnu/store/n8vdar2f60mvq62g7mngpqwykbm9rw1q-guix-1.2.0rc2-1.0d4b1af
[sudo] password for tflutre:
/gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/bash:
warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
guix package: warning: Consider running 'guix pull' followed by
'guix package -u' to get up-to-date packages and security updates.

guix package: error: package 'guix' not found in profile

Tim

bug#58526: bug report upgrading Guix from 1.0.1 to 1.3

[Timothée Flutre]

Hello Maxime,

Thanks for finding this issue that seems related to my issue.

As it may take some time for someone to fix this issue, could I uninstall
my current Guix setup, and install it again?

Sorry for top-posting, I was not aware of the problem it may caused.

Best,
Tim

bug#58561: Source hash mismatch with aggregator + possible guix bug with hashes.

[phodina via Bug reports for GNU Guix]

Hi Simon,

> Indeed, commit 6971feca53a19d60fdd2b39fb2a8966ccf1d6598 pushed on
> core-updates reads,
> 
> --8<---cut here---start->8---
> 
> (define-public akregator
> (package
> (name "akregator")
> - (version "21.12.3")
> + (version "22.04.3")
> (source
> (origin
> (method url-fetch)
> (uri (string-append "mirror://kde/stable/release-service/" version
> "/src/akregator-" version ".tar.xz"))
> (sha256
> - (base32 "1yy5c29zxpli4cddknmdvjkgii3j7pvw6lhwqfrqjc8jh83gm8f8"
> + (base32 "9yy5c29zxpli4cddknmdvjkgii3j7pvw6lhwqfrqjc8jh83gm8f8"
> (build-system qt-build-system)
> --8<---cut here---end--->8---
> 
> > Is there a bug with how guix is reading/writing sha256 hashes?
> 
> 
> Is it a mistake here? A human-typo replacing ’1’ by ’9’? Or
> something else? Petr?

It's just typo. I used mostly guix refresh for large part of the packages. 
Guess I updated this one manually or somehow cast wrong incantation in Vim.

Sorry for my mistake. I tried to check most of the changes I made in the patch 
series but this one slipped through in the many rounds of rebuilding Qt and KDE.



Petr

bug#58526: bug report upgrading Guix from 1.0.1 to 1.3

[Maxime Devos]

On 17-10-2022 20:25, Timothée Flutre wrote:

Hello Maxime,

Thanks for finding this issue that seems related to my issue.

As it may take some time for someone to fix this issue, could I 
uninstall my current Guix setup, and install it again?


As far as I know there is no law against that, sure (it also doesn't 
appear to be a 'moreinfo' situation).


Greetings,
Maxime.


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#58198: topological-sort does not sort topologically in case of diamonds

[Maxime Devos]

The revised module is _also_ broken (in case of nushell's member graph). 
 Will wait with posting the revised² module until it has seen more 
testing ...


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#58586: Astropy 5.0.1 tests failed after staging->master marge

[Sharlatan Hellseher]

Hi Guix team,

It looks like Astropy stoped building with failed tests after commit
c567a82a6975e70c8207a4aeed55a72b5121213c.:

-
E   DeprecationWarning: FLIP_TOP_BOTTOM is deprecated and will be
removed in Pillow 10 (2023-07-01). Use Transpose.FLIP_TOP_BOTTOM
instead.

/gnu/store/q3hdznwiyz7ywhmfnddv9b3g3v1plhqw-python-pillow-9.2.0/lib/python3.9/site-packages/PIL/_deprecate.py:62:
DeprecationWarning
=== short test summary info 
FAILED 
astropy/visualization/wcsaxes/tests/test_misc.py::test_no_numpy_warnings[lines]
FAILED 
astropy/visualization/wcsaxes/tests/test_misc.py::test_no_numpy_warnings[contours]
FAILED astropy/visualization/wcsaxes/tests/test_misc.py::test_plt_imshow_origin
FAILED astropy/visualization/wcsaxes/tests/test_misc.py::test_ax_imshow_origin
FAILED astropy/visualization/wcsaxes/tests/test_wcsapi.py::test_edge_axes - D...
= 5 failed, 18427 passed, 1065 skipped, 126 deselected, 67 xfailed in
262.41s (0:04:22) =
error: in phase 'check': uncaught exception:
%exception #<&invoke-error program: "python" arguments: ("-m" "pytest"
"--pyargs" "astropy" "-m" "not remote_data") exit-status: 1
term-signal: #f stop-signal: #f>
phase `check' failed after 269.2 seconds
-

The test failing isues comes from Pillow update
https://github.com/astropy/astropy/issues/13044 and fixed in the
latest release of Astropy.

I've tried to urade it to the latest 5.1 but it requires:

https://github.com/astropy/astropy/blob/v5.1/setup.cfg#L57
pytest>=7.0

So I've stoped here for now. I'll give it a go to have all the chain
to be upgraded and see how deep it will go. This blocking me to sent
patches for SunPy which were built just fine :).

Regards,
Oleg

-- 
… наш разум - превосходная объяснительная машина которая способна
найти смысл почти в чем угодно, истолковать любой феномен, но
совершенно не в состоянии принять мысль о непредсказуемости.

bug#58526: bug report upgrading Guix from 1.0.1 to 1.3

[zimoun]

Hi,

On Mon, 17 Oct 2022 at 20:23, Timothée Flutre  wrote:

> ~$ sudo -i guix package --bootstrap --fallback -r guix -i
> /gnu/store/n8vdar2f60mvq62g7mngpqwykbm9rw1q-guix-1.2.0rc2-1.0d4b1af
> [sudo] password for tflutre:
> /gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/bash:
> warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
> guix package: warning: Consider running 'guix pull' followed by
> 'guix package -u' to get up-to-date packages and security updates.
>
> guix package: error: package 'guix' not found in profile

sudo -i \
   guix package --bootstrap --fallback \
-i /gnu/store/n8vdar2f60mvq62g7mngpqwykbm9rw1q-guix-1.2.0rc2-1.0d4b1af


Cheers,
simon

bug#33614: reposurgeon build is broken

[zimoun]

Hi,

On Wed, 13 Jul 2022 at 09:22, Maxim Cournoyer  wrote:

> I tried updating reposurgeon to see if I could get that resolved, but
> reposurgeon is now a Go module, so we'd need to change the build system
> and perhaps add a couple supporting Go modules.
>
> Would you like to take a look?

reposurgeon is broken since a while; [1] is reported on Dec. 2018.

Since no one care enough this package, I am propose to close this issue
by simply removing the package.  WDYT?


1: 


Cheers,
simon

bug#49206: source hash mismatch on hypre

[zimoun]

Hi,

On Wed, 03 Nov 2021 at 15:06, phodina  wrote:

> I've checked the hypre package and it builds with the checksum
> 1lvh4ybqkriyqfg2zmic6mrg1981qv1i9vry1fdgsabn81hb71g4.
>
> It was updated in commit be0997278b5 by Tobias Geerinckx-Rice.

So closing.

Moreover, hypre is currently at 2.20.0; at least using Guix
b73814872e5b753588d8f4a126add403d8b390df.

Cheers,
simon

bug#58591: Java packages do not appear to keep a reference to their inputs

[Maxim Cournoyer]

Hello,

I'm not a Java expert, but this appears to me problematic:

--8<---cut here---start->8---
$ guix build java-commons-dbcp
/gnu/store/jghsa6fmh9vjcsmj7wwilk3w6iblvh32-java-commons-dbcp-2.6.0

$ guix gc -R /gnu/store/jghsa6fmh9vjcsmj7wwilk3w6iblvh32-java-commons-dbcp-2.6.0
/gnu/store/jghsa6fmh9vjcsmj7wwilk3w6iblvh32-java-commons-dbcp-2.6.0
--8<---cut here---end--->8---

Digging a bit more, peeking into the .jar file, which is a ZIP archive:

--8<---cut here---start->8---
$ unzip /gnu/store/jghsa6fmh9vjcsmj7wwilk3w6iblvh32-java-commons-dbcp-2.6.0/\
share/java/java-commons-dbcp.jar -d /tmp/java-commons-dbcp.jar

$ grep -rin CLASSPATH /tmp/java-commons-dbcp.jar
$ grep -rin /gnu/store /tmp/java-commons-dbcp.jar
/tmp/java-commons-dbcp.jar/META-INF/INDEX.LIST:3:/gnu/store/jghsa6fmh9vjcsmj7wwilk3w6iblvh32-java-commons-dbcp-2.6.0/share/java/java-commons-dbcp.jar

$ cat /tmp/java-commons-dbcp.jar/META-INF/INDEX.LIST
JarIndex-Version: 1.0

/gnu/store/jghsa6fmh9vjcsmj7wwilk3w6iblvh32-java-commons-dbcp-2.6.0/share/java/java-commons-dbcp.jar
org
org/apache
org/apache/commons
org/apache/commons/dbcp2
org/apache/commons/dbcp2/cpdsadapter
org/apache/commons/dbcp2/datasources
org/apache/commons/dbcp2/managed
--8<---cut here---end--->8---

Still, no traces of the other libraries such as 'java-commons-pool'
which should be referenced.

I assume this means grafts doesn't currently work for Java libraries.

-- 
Thanks,
Maxim

bug#33614: reposurgeon build is broken

[Maxim Cournoyer]

Hi,

zimoun  writes:

> Hi,
>
> On Wed, 13 Jul 2022 at 09:22, Maxim Cournoyer  
> wrote:
>
>> I tried updating reposurgeon to see if I could get that resolved, but
>> reposurgeon is now a Go module, so we'd need to change the build system
>> and perhaps add a couple supporting Go modules.
>>
>> Would you like to take a look?
>
> reposurgeon is broken since a while; [1] is reported on Dec. 2018.
>
> Since no one care enough this package, I am propose to close this issue
> by simply removing the package.  WDYT?

I'm fine with it.  I tried updating it, but it is now written in Go and
would require packaging a few new Go packages; the list is here [0].

[0]  https://gitlab.com/esr/reposurgeon/-/blob/master/go.mod

-- 
Thanks,
Maxim

bug#58561: [PATCH 2/2] gnu: akregator: Fix build.

[Brendan Tildesley]

On October 16, 2022 4:39:16 PM GMT+11:00, phodina  
wrote:
>Hi,
>
>unfortunately incorrect hash was pushed in the last patchset.
>
>The patch is already part of the next patch series [1].
>
>Also it's tracked here [2].
>
>1 
>https://github.com/phodina/guix/commit/4636279dfb3b96eb5836baad0d8ea36e58ff79ee
>2 https://issues.guix.gnu.org/57608#8
>
>
>Petr
>
>
>
>
>Sent with Proton Mail secure email.
>
>--- Original Message ---
>On Sunday, October 16th, 2022 at 6:33 AM, 'Brendan Tildesley 
> wrote:
>
>
>> From: Brendan Tildesley m...@brendan.scot
>> 
>> 
>> * gnu/packages/kde.scm (akregator)[phases]: Fix finding
>> QtWebEngineProcess path.
>> ---
>> gnu/packages/kde.scm | 5 ++---
>> 1 file changed, 2 insertions(+), 3 deletions(-)
>> 
>> diff --git a/gnu/packages/kde.scm b/gnu/packages/kde.scm
>> index 37125b1d0b..d0ffb28505 100644
>> --- a/gnu/packages/kde.scm
>> +++ b/gnu/packages/kde.scm
>> @@ -167,9 +167,8 @@ (define-public akregator
>> (lambda* (#:key inputs outputs #:allow-other-keys)
>> (let* ((out (assoc-ref outputs "out"))
>> (bin (string-append out "/bin/akregator"))
>> - (qt-process-path (string-append
>> - (assoc-ref inputs "qtwebengine-5")
>> - "/lib/qt5/libexec/QtWebEngineProcess")))
>> + (qt-process-path (search-input-file
>> + inputs "/lib/qt5/libexec/QtWebEngineProcess")))
>> (wrap-program bin
>> `("QTWEBENGINEPROCESS_PATH" = (,qt-process-path)
>> (native-inputs
>> --
>> 2.37.2

I think the correct way is to use something like search-input-file instead 
ungexping qtwebengine-5, right? Input transformations well not work otherwise?

bug#58571: translations are incompletely pulled from weblate

[Julien Lepiller]

One thing I suspect is that weblate takes quite a lot of time to pull changes 
from the intermediate repository, so if you provide a translation while the 
repo is being synced, I think they might be reset when the file is finally 
loaded by weblate.

Not sure if this could explain this many ignored translations though…

For anyone in that situation, the translations are not lost. You can always go 
back to them and you'll see they are untranslated, but you'll see a red box on 
the right saying it's already translated. If the text is correct, you can click 
"fix string" to apply the translation.

Le 17 octobre 2022 19:12:24 GMT+02:00, "pelzflorian (Florian Pelz)" 
 a écrit :
>two--- via Bug reports for GNU Guix  writes:
>> hi
>> in https://git.savannah.gnu.org/cgit/guix.git/tree/po/guix/uk.po i see
>> kyrylo's translations are pulled there from weblate, but mine
>> (https://translate.fedoraproject.org/changes/?project=guix&lang=uk&user=two22)
>> are not, these strings stay untranslated or erroneous.
>
>This is strange and I do not yet see what could be the cause.
>
>Weblate is backed not by savannah but by an intermediate repository
>https://framagit.org/tyreunom/guix-translations
>which Julien regularly syncs with Savannah each month.
>
>Perhaps could you try changing a translation on Weblate and see if there
>is a change to ?  It
>will sync faster if after you make the change on Weblate, you use
>Weblate’s File download button.
>
>Regards,
>Florian
>
>
>

bug#58591: Java packages do not appear to keep a reference to their inputs

[Julien Lepiller]

You're right, java package don't retain references to there input, that's why 
we propagate required dependencies (mh… sometimes). I don't know how they could 
reference dependencies directly.

Le 17 octobre 2022 23:04:47 GMT+02:00, Maxim Cournoyer 
 a écrit :
>Hello,
>
>I'm not a Java expert, but this appears to me problematic:
>
>--8<---cut here---start->8---
>$ guix build java-commons-dbcp
>/gnu/store/jghsa6fmh9vjcsmj7wwilk3w6iblvh32-java-commons-dbcp-2.6.0
>
>$ guix gc -R 
>/gnu/store/jghsa6fmh9vjcsmj7wwilk3w6iblvh32-java-commons-dbcp-2.6.0
>/gnu/store/jghsa6fmh9vjcsmj7wwilk3w6iblvh32-java-commons-dbcp-2.6.0
>--8<---cut here---end--->8---
>
>Digging a bit more, peeking into the .jar file, which is a ZIP archive:
>
>--8<---cut here---start->8---
>$ unzip /gnu/store/jghsa6fmh9vjcsmj7wwilk3w6iblvh32-java-commons-dbcp-2.6.0/\
>share/java/java-commons-dbcp.jar -d /tmp/java-commons-dbcp.jar
>
>$ grep -rin CLASSPATH /tmp/java-commons-dbcp.jar
>$ grep -rin /gnu/store /tmp/java-commons-dbcp.jar
>/tmp/java-commons-dbcp.jar/META-INF/INDEX.LIST:3:/gnu/store/jghsa6fmh9vjcsmj7wwilk3w6iblvh32-java-commons-dbcp-2.6.0/share/java/java-commons-dbcp.jar
>
>$ cat /tmp/java-commons-dbcp.jar/META-INF/INDEX.LIST
>JarIndex-Version: 1.0
>
>/gnu/store/jghsa6fmh9vjcsmj7wwilk3w6iblvh32-java-commons-dbcp-2.6.0/share/java/java-commons-dbcp.jar
>org
>org/apache
>org/apache/commons
>org/apache/commons/dbcp2
>org/apache/commons/dbcp2/cpdsadapter
>org/apache/commons/dbcp2/datasources
>org/apache/commons/dbcp2/managed
>--8<---cut here---end--->8---
>
>Still, no traces of the other libraries such as 'java-commons-pool'
>which should be referenced.
>
>I assume this means grafts doesn't currently work for Java libraries.
>
>-- 
>Thanks,
>Maxim
>
>
>

bug#58591: Java packages do not appear to keep a reference to their inputs

[Mark H Weaver]

Julien Lepiller  writes:

> You're right, java package don't retain references to there input,
> that's why we propagate required dependencies (mh… sometimes). I don't
> know how they could reference dependencies directly.

A better workaround would be to add a phase that installs file(s) in the
output(s) that contain references to the required store items.  They
could simply be text files with one line per reference.  That would at
least protect the dependencies from the garbage collector.

The remaining unsolved problem is, of course, grafting.

   Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about .

bug#58591: Java packages do not appear to keep a reference to their inputs

[Maxim Cournoyer]

Hi Julien,

Julien Lepiller  writes:

> You're right, java package don't retain references to there input,
> that's why we propagate required dependencies (mh… sometimes). I don't
> know how they could reference dependencies directly.

Could we, along with installing Java classes as directories instead of
.jar archive files [0] at a more specific prefix, define a search path
specification that'd set CLASSPATH?  Currently I don't see anything
setting CLASSPATH outside of the build systems, so even if we propagate
Java things, I don't see how it'd find them in a profile.

[0]  Not exactly sure how that's done yet, but it's mentioned here: 
https://docs.oracle.com/javase/8/docs/technotes/tools/windows/classpath.html

--
Thanks,
Maxim