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

[Maxim Cournoyer]

Hello,

Julien Lepiller  writes:

> Hi, replying to a few emails at once.
>
> The ant-build-system uses zip -0 to produce an uncompressed
> archive. By default, jar produces a compressed one, so there's a
> repack phase for that:
>  
> http://git.savannah.nongnu.org/cgit/guix.git/tree/guix/build/ant-build-system.scm#n226

Ah, I had missed the -0 == uncompressed part.  Thank you.

> Embedding the classpath in the manifest is possible but would not have
> the expected effect. That's because a line in the manifest cannot
> exceed 72 bytes (see "line length" in
> https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#Notes_on_Manifest_and_Signature_Files),
> so the classpath will look like:
>
> Class-Path: ../../../1234567891011
>  1213141516/share/java/foo.jar

Although it looks like the 72 bytes line width limitation may has to do
with binary data:

   Binary data of any form is represented as base64. Continuations are
   required for binary data which causes line length to exceed 72
   bytes. Examples of binary data are digests and signatures.

Worth a try in my opinion (I'm giving it a shot as I write this).

Thanks for the explanations!

Maxim

bug#39571: evolution and bogofilter

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

Hi Christopher,

Thanks for the swift response!

Christopher Howard 写道：

If you wish to close this old bug I will not be affected.


Will do.

Why let zimoun have all the fun,

T G-R


signature.asc
Description: PGP signature

bug#39571: evolution and bogofilter

[Christopher Howard]

Hello, I switched to the Mutt email-client about about 1 year ago. If you wish 
to close this old bug I will not be affected.

Christopher Howard

On Tue, Oct 18, 2022 at 07:09:59PM +0200, Tobias Geerinckx-Rice wrote:
> Let's try this one first.
> 
> Christopher, assuming you have a clue what this is about: are you still
> affected by ?
> 

bug#40237: Cannot build gcc-toolchain with "make-gcc-toolchain"

[Roel Janssen]

Hi Simon,

On Tue, 2022-10-18 at 17:41 +0200, zimoun wrote:
> Hi Roel,
> 
> It is about this old bug#40237 [1]
> 
> 1: 
> 
> On Thu, 26 Mar 2020 at 11:29, Roel Janssen  wrote:
> 
> > I am trying to build a package with glibc-2.28.  So my native-inputs looks 
> > like
> > this:
> > --
> > (native-inputs
> >  `(("gcc-toolchain" ,(make-gcc-toolchain gcc-5 glibc-2.28
> > --
> > 
> > 
> > When building this custom gcc-toolchain, it fails with:
> 
> Is it still the case?  Well, could you provide more information about
> your use case?
> 

Actually, I don't have any more information, and most probably I messed up 
myself.
I suppose we can just close this. If there's anything actually wrong it'll pop 
up
another bug report. Shall I close this bug report, or would you like to keep it 
open?

Thanks for looking into this old bug report!


Kind regards,
Roel Janssen

bug#39571: evolution and bogofilter

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

zimoun 写道：
For the record, the message I received back.  Therefore, I will 
close

if no objection.


Let's try this one first.

Christopher, assuming you have a clue what this is about: are you 
still affected by ?


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#34427: guile-bootstrap@2.2 segfault?

[Efraim Flashner]

We've moved the bootstrap guile to 3.0 for riscv64 and haven't seen any 
problems. I think we can just close this one and we'll revisit it if someone 
else decides to use guile-2.2 for a bootstrap guile and runs into this issue.


On October 18, 2022 4:14:32 PM UTC, zimoun  wrote:
>Hi,
>
>It is about this old report #34427x [1].
>
>1: 
>
>On Thu, 23 Jun 2022 at 10:17, zimoun  wrote:
>> On Fri, 15 Apr 2022 at 09:45, Ludovic Courtès  wrote:
>>
> The problem has to do specifically with powerpc-linux-gnu (this is with
> transparent emulation via QEMU+binfmt_misc):
>
> --8<---cut here---start->8---
> $ unshare -mrf chroot $(guix build guile-static-stripped 
> --target=powerpc-linux-gnu) /bin/guile
> guile: warning: failed to install locale
> GC Warning: pthread_getattr_np or pthread_attr_getstack failed for main 
> thread
> GC Warning: Couldn't read /proc/stat
> Pre-boot error; key: wrong-type-arg, args: (#f "Wrong type to apply: ~S"
> (#f) (#f))qemu: uncaught target signal 6 (Aborted) - core dumped
> Aborted
> --8<---cut here---end--->8---
>
> Unfortunately I fail to get a backtrace from that core dump.
>
> Efraim, could you get a backtrace on the bare metal?
>>>
>>> Sorry I wasn’t clear; could you get a backtrace from GDB, as in:
>>>
>>>   …/bin/guile
>>>   # segfault
>>>   gdb …/bin/guile core
>>>
>>> and then at the GDB prompt:
>>>
>>>   bt
>
>What is the status?  Since a release is maybe coming, it could be the
>opportunity to tackle it… or not. :-)
>
>Cheers,
>simon

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

bug#40237: Cannot build gcc-toolchain with "make-gcc-toolchain"

[zimoun]

Hi Roel,

It is about this old bug#40237 [1]

1: 

On Thu, 26 Mar 2020 at 11:29, Roel Janssen  wrote:

> I am trying to build a package with glibc-2.28.  So my native-inputs looks 
> like
> this:
> --
> (native-inputs
>  `(("gcc-toolchain" ,(make-gcc-toolchain gcc-5 glibc-2.28
> --
>
>
> When building this custom gcc-toolchain, it fails with:

Is it still the case?  Well, could you provide more information about
your use case?


Cheers,
simon

bug#39080: How do language packs work?

[zimoun]

Hi,

This old bug report #39080 [1] is about translation to Pennsylvania
Dutch.

1: 

On Sat, 11 Jan 2020 at 14:54, Julien Lepiller  wrote:
> Le Fri, 10 Jan 2020 22:58:35 -0600,
> Caleb Herbert  a écrit :
>> On 1/10/20 10:31 PM, Julien Lepiller wrote:

> ah indeed, glibc doesn't seem to have a locale definition for pdc. We
> can't really do anything about this ourselves, but you should
> definitely talk to the glibc folks, they'll know what you need to
> create and contribute locale data.

What is the status about this?  Still an interest in?

If not, do we close?


Cheers,
simon

bug#39571: evolution and bogofilter

[zimoun]

Hi,

Sorry for not being very responsive.  It is about this old bug#39571
report [1].

1: 

On Tue, 11 Feb 2020 at 12:10, Christopher Howard  
wrote:

> Hello, I'm trying to get spam filtering working in
> evolution. According to evolution docs, evolution is supposed to use
> either bogofilter or spam assassin. I am focusing on bogofilter since
> guix has a bogofilter package. I have set all settings in evolution
> according to the evolution docs from the help menu, but cannot get
> confirmation either than spam filtering is actually working, or that
> evolution is in fact interacting with bogofilter to build a words
> database. As part of that, I'm trying to confirm if guix has correct
> options for that built into evolution, to properly interact with
> bogofilter binary.

What is the status?  Is it fixed for you?  If no, could you do an update
on this bug? :-)


Cheers,
simon

bug#34427: guile-bootstrap@2.2 segfault?

[zimoun]

Hi,

It is about this old report #34427x [1].

1: 

On Thu, 23 Jun 2022 at 10:17, zimoun  wrote:
> On Fri, 15 Apr 2022 at 09:45, Ludovic Courtès  wrote:
>
 The problem has to do specifically with powerpc-linux-gnu (this is with
 transparent emulation via QEMU+binfmt_misc):

 --8<---cut here---start->8---
 $ unshare -mrf chroot $(guix build guile-static-stripped 
 --target=powerpc-linux-gnu) /bin/guile
 guile: warning: failed to install locale
 GC Warning: pthread_getattr_np or pthread_attr_getstack failed for main 
 thread
 GC Warning: Couldn't read /proc/stat
 Pre-boot error; key: wrong-type-arg, args: (#f "Wrong type to apply: ~S"
 (#f) (#f))qemu: uncaught target signal 6 (Aborted) - core dumped
 Aborted
 --8<---cut here---end--->8---

 Unfortunately I fail to get a backtrace from that core dump.

 Efraim, could you get a backtrace on the bare metal?
>>
>> Sorry I wasn’t clear; could you get a backtrace from GDB, as in:
>>
>>   …/bin/guile
>>   # segfault
>>   gdb …/bin/guile core
>>
>> and then at the GDB prompt:
>>
>>   bt

What is the status?  Since a release is maybe coming, it could be the
opportunity to tackle it… or not. :-)

Cheers,
simon

bug#43432: trilinos source vanished

[zimoun]

Hi,

I think it is a duplicate of #40074 [1].  I am in favour to close both.

1: 


Cheers,
simon

bug#39571: Fwd: Alaska Satellite Internet Re: bug#39571: evolution and bogofilter

[zimoun]

Hi,

For the record, the message I received back.  Therefore, I will close
if no objection.

Cheers,
simon


-- Forwarded message -
From: Christopher Howard 
Date: Tue, 18 Oct 2022 at 18:19
Subject: Alaska Satellite Internet Re: bug#39571: evolution and bogofilter
To: 


Good day Sir or Ma'am



We at Alaska Satellite Internet are happy to assist you with any of
your needs and/or concerns. Unfortunately, the person you are trying
to reach, is no longer part of the organization. Please forward your
email the appropriate department below or call us at 907-451-0088 and
we would be happy to assist you.



Thank you,



Accounting, General Assistance

Marti Steury

General Manager

E-mail: ma...@alaskasi.com



Business Services

Trevor Nickisch

Enterprise Solutions Manager

E-mail: tre...@alaskasi.com



Residential Services

Isaac Ben David

Residential Technician

E-mail: is...@alaskasi.com

bug#39738: ffmpeg-4.2.2 fails to build on native i686-linux

[zimoun]

Hi,

It is about the old bug#39738 [1].

1: 

On Sat, 07 Aug 2021 at 23:53, Maxim Cournoyer  wrote:

>> Building it on 64 bit hardware (much faster!) works for me, i.e. this
>>
>> guix build --system=i686-linux ffmpeg
>>
>> works for me and can be used as a substitute...
>
> I don't have real 32 bits hardware to test on, but could you please test
> ffmpeg 4.4 on such hardware if you have a chance and see if the issues
> still exist?

Friendly ping. :-)

Is ffmpeg still an issue an real 32 bits hardware?

Cheers,
simon

bug#43432: trilinos source vanished

[Efraim Flashner]

On October 18, 2022 3:38:40 PM UTC, zimoun  wrote:
>Hi,
>
>I think it is a duplicate of #40074 [1].  I am in favour to close both.
>
>1: 
>
>
>Cheers,
>simon

Works for me
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

bug#39677: Evolution's inbox widget is blank

[zimoun]

Hi,

It is about this old bug#39677 [1].  Sorry for not noticing it before.

1: 


On Wed, 19 Feb 2020 at 15:20, raingloom  wrote:

> I've been haunted by this for months, so it's high time I make a proper bug
> report.
>
> I wiped all Evolution related directories I could find in .cache, .config, and
> .local, and reconfigured it from scratch, but that didn't help.
>
> When I open Evolution it prompts me for my password and pulls my emails
> without a problem, even shows a notification for them, but it doesn't
> display anything.
>
> It's not a font issue, because the scroll bar does not appear. There are no
> emails displayed at all. Double clicking on it should open a mail in a new
> window, but no window appears.
>
> I tried it in a VM that's a slight modification of my system, that had no
> problems.
> I also tried it in both i3wm and Gnome, but the results are identical.
>
> All I see in the log is this:
> ```
> (evolution:23706): GLib-GIO-WARNING **: 15:17:11.805: Your application did not
> unregister from D-Bus before destruction. Consider using g_application_run().
> ```
>
> I can send an strace log if necessary. The one I took was a bit long and
> didn't reveal much, but someone might have better luck.
>
> Any tips on where I should look?
>
> I suspect that it either doesn't play nice with some other package or that
> there is some state corruption I couldn't track down.
>
> For now I'll just use Geary for this account.

Well, I am not an user of Evolution.  The question is: is it still an
issue for you?  If yes, are you running Guix on foreign distro?  Or Guix
System?


Cheers,
simon

bug#39374: Failing channels and graph on 1.0.1.10297-c5bbcb

[zimoun]

Hi,

It is an old bug report #39374 [1].

1: 


On Wed, 05 Feb 2020 at 14:49, Ludovic Courtès  wrote:

> I wonder if this could be caused by settings in ~/.gitconfig.  Could you
> try to move it out of the way and run the test?  With:
>
>   rm ~/.gitconfig{,.bak}
>   make check TESTS=tests/channels.scm

Because of this, the bug is marked as ’moreinfo’ since 2 years, 2 days,
8 hours ago.


> The second failure is:
>
> test-name: reverse bag DAG
> location: /home/ep/src/guix/tests/graph.scm:194
> source:
> + (test-assert
> +   "reverse bag DAG"
> +   (let-values
> + (((dune bap ocaml-base)
> +   (values
> + (specification->package "dune")
> + (specification->package "bap")
> + (specification->package "ocaml-base")))
>
> [...]
>
> actual-error:
> + (quit 1)
> result: FAIL
>
> It’s due to recent changes in the OCaml packages.  I’ll push a fix
> shortly.

Well, I assume this fix had been pushed since then.


Therefore, I am in favor to close this report.  Any objection?


Cheers,
simon

bug#40074: trilinos-serial-xyce source disappeared

[zimoun]

Hi,

On Thu, 15 Oct 2020 at 21:38, zimoun  wrote:
> On Sun, 15 Mar 2020 at 13:48, Marius Bakke  wrote:

> First patch, replace ’url-fetch’ by ’git-fetch’ with creating a Git repo
> from the build farm tarball and falling back to SWH.  This does not
> change the integrity checksum.  And it avoids the “pressure“ on the
> build farm.
>
> Second patch, update the upstream source to the new good ’git-fetch’.
> And this change the integrity checksum.  Maybe upstream released a new
> version.

Commit b729be989f137749430779499b8c0dd1d54f2a18 did the replacement by
’git-fetch’ using the upstream repo.

It is hard to compare the both sources but it does not really matter
since the new one is the official upstream one.

Well, what remains is the guarantee that ’guix time-machine’ will still
work even if the Guix project looses the tarball.

This case should be covered by Disarchive and SWH.  Well, is it worth to
keep open this issue when the question about the time-machine coverage
is bigger than just this example.

Closing?

Cheers,
simon

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

[Maxim Cournoyer]

reopen 25018
quit

Hi,

Ludovic Courtès  writes:

[...]

> 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, and sorry for not noticing the breakage.  I'm reopening the bug
so that we don't forget about it.

-- 
Thanks,
Maxim

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

[Julien Lepiller]

Hi, replying to a few emails at once.

The ant-build-system uses zip -0 to produce an uncompressed archive. By 
default, jar produces a compressed one, so there's a repack phase for that:
 
http://git.savannah.nongnu.org/cgit/guix.git/tree/guix/build/ant-build-system.scm#n226

Embedding the classpath in the manifest is possible but would not have the 
expected effect. That's because a line in the manifest cannot exceed 72 bytes 
(see "line length" in 
https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#Notes_on_Manifest_and_Signature_Files),
 so the classpath will look like:

Class-Path: ../../../1234567891011
 1213141516/share/java/foo.jar

Although java would read that fine, the grafter will not see it, nor be able to 
graft foo in a meaningful manner: java would still use the ungrafted version 
even if another file references foo.

Le 18 octobre 2022 16:56:01 GMT+02:00, Maxim Cournoyer 
 a écrit :
>Hello,
>
>Maxim Cournoyer  writes:
>
>> Tobias Geerinckx-Rice  writes:
>
>[...]
>
>>> Groan.  Which package(s) compress .jars?
>>
>> Oh, aren't they all?  I hadn't realized .jar compression was optional.
>
>Actually, reading [0] again, it seems a JAR *is* a zip archive, so
>cannot be either compressed or uncompressed.
>
>[0]  https://docs.oracle.com/en/java/javase/19/docs/specs/jar/jar.html
>
>-- 
>Thanks,
>Maxim

bug#58290: guile ssh error on guix deploy

[Ludovic Courtès]

Hi,

Marius Bakke  skribis:

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

“no more sessions” comes from this:

--8<---cut here---start->8---
int
session_open(Authctxt *authctxt, int chanid)
{
Session *s = session_new();
debug("session_open: channel %d", chanid);
if (s == NULL) {
error("no more sessions");
return 0;
}

[...]

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

Would be interesting to run sshd in verbose/debug mode and see why we
hit that; it could be because the maximum number of sessions has been
reached or something.

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

Ouch.  Normally, thanks to memoization, ‘guix deploy’ opens only one
session per machine.  (I think it works well with the 25 local build
machines behind berlin; it’s also fine for a small set of machines I
take care of at work.)

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

Interesting.  That gives us a hint.  Could you add a ‘pk’ in
‘open-machine-ssh-session*’ to see how many connections it opens?

Thanks for your feedback!

Ludo’.

bug#58375: Installer does not show what is being downloaded

[Ludovic Courtès]

Hi Mathieu,

Mathieu Othacehe  skribis:

> So I implemented your proposal. It seems to be working quite well. As
> discussed on #guix, we could avoid to dump the download bars to the
> syslog if the "guix system init" command succeeds. However, it seems
> quite tricky in the current implementation where the syslog dumping is
> actually a hook (%syslog-line-hook).

Yes.

I haven’t actually tested the patch but it LGTM.  One thing to check is
whether ‘terminal-window-size’ returns something sensible for the
pseudo-terminal; it could be that we need an extra ioctl so the
pseudo-terminal has the same size as the actual terminal.

> Fixing this issue, I also realized that when the "guix system init"
> command fails, the user is only offered to resume the installation or
> restart it.
>
> In cases where "guix system init" failed because of a network issue, or
> because a partition was too small, restarting/resuming seems like the
> right thing to do.
>
> However, when the installer failed because "guix system init" crashed or
> segfaulted, restarting/resuming won't probably help, and dumping the
> crash is probably the best way to get help. That's why I added in a
> second patch, a new button "Report the failure" to the
> "run-install-failed-page".

Neat!

> From c6286404e9c4c0dc302c3d398a8f27b050cf4ce0 Mon Sep 17 00:00:00 2001
> From: Mathieu Othacehe 
> Date: Fri, 14 Oct 2022 17:28:27 +0200
> Subject: [PATCH 1/2] installer: Run the "guix system init" command in a PTY.
>
> Fixes: 
>
> * gnu/installer/utils.scm (run-external-command-with-handler/tty): New
> procedure.
> (run-external-command-with-line-hooks, run-command): Add a TTY? argument.
> * gnu/installer/final.scm (install-system): Call run-command with TTY?
> argument set to #true.

LGTM, modulo the terminal size issue mentioned above.

> From 159b82a013cad8c3c698031cce9ee07956153da3 Mon Sep 17 00:00:00 2001
> From: Mathieu Othacehe 
> Date: Fri, 14 Oct 2022 17:33:28 +0200
> Subject: [PATCH 2/2] installer: Propose the user to report a "guix system
>  init" failure.
>
> * gnu/installer/newt/final.scm (run-install-failed-page): Add a "Report the
> failure" button.

LGTM.

Thank you!

Ludo’.

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

[Maxim Cournoyer]

Hello,

Maxim Cournoyer  writes:

> Tobias Geerinckx-Rice  writes:

[...]

>> Groan.  Which package(s) compress .jars?
>
> Oh, aren't they all?  I hadn't realized .jar compression was optional.

Actually, reading [0] again, it seems a JAR *is* a zip archive, so
cannot be either compressed or uncompressed.

[0]  https://docs.oracle.com/en/java/javase/19/docs/specs/jar/jar.html

-- 
Thanks,
Maxim

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

[Maxim Cournoyer]

Hi Tobias!

Tobias Geerinckx-Rice  writes:

> Hi Maxim,
>
> Maxim Cournoyer 写道：
>> not obfuscated due to zip compression
>
> Groan.  Which package(s) compress .jars?

Oh, aren't they all?  I hadn't realized .jar compression was optional.
I believe our ant-build-system produces compressed jars; in fact it uses
'zip' directly to pack them.

-- 
Thanks,
Maxim

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

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

Tobias Geerinckx-Rice via Bug reports for GNU Guix 写道：

Groan.  Which package(s) compress .jars?


OK, found one: openjdk@16.0.1's /lib/jrt-fs.jar.

Kind regards,

T G-R


signature.asc
Description: PGP signature

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

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

Hi Maxim,

Maxim Cournoyer 写道：

not obfuscated due to zip compression


Groan.  Which package(s) compress .jars?

(I found a few in -checkouts, which is its own potential thing, 
but that aside.)


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#58571: translations are incompletely pulled from weblate

[pelzflorian (Florian Pelz)]

Julien Lepiller  writes:
> 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.

Something similar happened to me once: Immediately after Weblate
reported I had successfully uploaded a PO file, I decided to translate a
new untranslated string.  This made Weblate lose all translations from
the previous PO file upload.

tl;dr: Yes, Weblate sometimes can lose translations.

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

Good to hear.

Regards,
Florian

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

[Maxim Cournoyer]

Hi,

Maxim Cournoyer  writes:

[...]

> A nice read is [0], which mentions the existence of a 'Class-Path' main
> attribute that can go in the manifest file.  If using unpacked jars
> works the same as .jars (which are just zip files) for Java, then we
> could not only have dependency correctly referenced and loaded via
> 'Class-Path', but also the grafting mechanism would work, since the
> paths would appear in clear (not obfuscated due to zip compression).

Ugh, Class-Path only accepts relative path, not absolute paths:

   The location of the JAR file or directory represented by this entry
   is contained within the containing directory of the context JAR. Use
   of "../" to navigate to the parent directory is not permitted, except
   for the case when the context JAR is loaded from the file system.

Perhaps we could patch Java so that it's loader is more adapted for our
use case, or extend its manifest with a Guix-specific Guix-Class-Path
section that'd allow for absolute paths.

> [0] https://docs.oracle.com/en/java/javase/19/docs/specs/jar/jar.html

-- 
Thanks,
Maxim

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

[Maxim Cournoyer]

Hello,

Liliana Marie Prikler  writes:

> Am Montag, dem 17.10.2022 um 22:45 -0400 schrieb 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.
> I'd recommend writing an xml file like 
>
>   
> 
> 
> ... 
>  
>   
>
> to a well-known location.  Then we could reuse those files in ant-
> build-system.

A nice read is [0], which mentions the existence of a 'Class-Path' main
attribute that can go in the manifest file.  If using unpacked jars
works the same as .jars (which are just zip files) for Java, then we
could not only have dependency correctly referenced and loaded via
'Class-Path', but also the grafting mechanism would work, since the
paths would appear in clear (not obfuscated due to zip compression).

Our current usage of JarIndex doesn't suite the bill it was intended
for; this is a performance trick to index all the .jars of a .jar pack;
it'll only list its dependencies if they are packed in the same jar,
which is not what we do or want as a distribution.

[0]  https://docs.oracle.com/en/java/javase/19/docs/specs/jar/jar.html

-- 
Thanks,
Maxim

bug#28644: Missing icons in pulseview

[phodina via Bug reports for GNU Guix]

Hi,

recently I used Pulseview to debug eMMC issues.

I was also surprised why they are some icons and others are missing.

Based on the code some are implemented as png and some as svg.

I tried to add the qtsvg-5 but it did not work and made the resulting 
derivation larger.

Therefore there are 2 possibilites:

- Add support for SVG by adding qtsvg-5 and any additional packages [1]
This would be preferable as the images are displayed in the time series and the 
bitmaps will look ugly.

2. Convert all into pngs
This will save size but will require a big patch (which will be mostly binary)
What do you think?

[1] https://sigrok.org/bugzilla/show_bug.cgi?id=239


Petr

bug#58567: Grafting affects origins

[Ludovic Courtès]

Hi,

Ludovic Courtès  skribis:

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

Pushed as dada5e86ed58c1869e30678c4d69582b1528ed6c.

Thanks,
Ludo’.

bug#54354: [BUG] guix home: on foreign distro, ~/.bash_profile is not initialized

[Andrew Tropin]

On 2022-03-20 14:09, florhizome wrote:

> Hi Liliana,
>
> Hm, well it doesn't seem like the exact same issue, but that thread is
> helpful. Could systemd/logind be made to use bash for login?

Login shell is usually controlled by /etc/passwd, so it shouldn't
inerfer with systemd, elogind.

> For now I thought maybe I can just write shepherd services to do
> that stuff for me, to stay in guix homes framework. But shepherd seems
> to have a problem starting up:
>
> /gnu/store/y85vzni5yc6lcb7qqhmlkifis9nzmm5l-shepherd.conf wird geladen.
> herd: Ausnahmefehler während der Ausführung von »load« mit dem Dienst »root«:
> In procedure fport_write: Eingabe-/Ausgabefehler
>
> If you don't speak german, that roughly translates to:
>
> loading /gnu/store/...-shepherd.conf
> herd: exception error during the execution of <> with the service
> <>:
> In procedure fport_write: i/o error
>
> I got the same error when reconfiguring with two differing simple
> service configurations (just start a program from a package) passed to 
> shepherd.
> In anyway I think it would be good to add to guix home's documentation that 
> some features might not work
> due to the login system of a foreign distro if we are sure of that?
>

There were a few fixes related to shepherd service, which probably fixes
it.  Can you confirm this?  Or issue is still valid?

Is the whole issue 54354 still valid?

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

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

[Liliana Marie Prikler]

Am Montag, dem 17.10.2022 um 22:45 -0400 schrieb 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.
I'd recommend writing an xml file like 

  


... 
 
  

to a well-known location.  Then we could reuse those files in ant-
build-system.

Cheers

bug#58571: translations are incompletely pulled from weblate

[Maxime Devos]

On 16-10-2022 18:33, two--- via Bug reports for GNU Guix wrote:

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


If I guess correctly, translations are currently moved from weblate to 
Guix by overwriting the local .po with a copy from weblate and likewise 
in the other direction.


However, a 'msgmerge' program exists: 
‘https://www.gnu.org/software/gettext/manual/html_node/msgmerge-Invocation.html’. 
Maybe that could be used?


Also, on pushing new .po to weblate, 'git push' has a '--with-lease' 
option, which IIUC is a kind of 'atomic compare-and-swap' operation, 
which could help with avoiding race conditions.


Greetings,
Maxime.


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#58606: Emacs next pgtk crashes when pasting to other app

[Andrew Tropin]

Recently discovered a problem, which reproduces this way:
- Open a new emacs instance.
- Yank anything with M-w or select with mouse.
- Paste yanked text to chromium/icecat.

Both browser and emacs are hanging up for a while and after that Emacs
crashes with:

--8<---cut here---start->8---
Fatal error 11: Segmentation fault
--8<---cut here---end--->8---

sway, emacs-next-pgtk, ungoogled-chromium

--8<---cut here---start->8---
Generation 75   Oct 17 2022 15:54:07(current)
  rde 05225a3
repository URL: https://git.sr.ht/~abcdw/rde
branch: master
commit: 05225a3a20e2f3eba9ebaa3df4cdce3e8b0c33c1
  guix 3ab1438
repository URL: file:///home/bob/work/gnu/guix
branch: master
commit: 3ab14386cd2a3fc4bacf2291ee585a0685aceb17
--8<---cut here---end--->8---

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

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

[Maxime Devos]

On 18-10-2022 04:45, Maxim Cournoyer wrote:

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


FWIW, when I used java things in Guix, I manually did 
CLASSPATH=$GUIX_ENVIRONMENT/... or the CLI equivalent (some option 
argument of 'java').


Some more automatisation, e.g. in the form of search paths as you 
propose, would be nice though.


Greetings,
Maxime.


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature