Re: branch master updated (2bea3f2562 -> 6745d692d4)

[Ricardo Wurmus]

Hi,

> guix-comm...@gnu.org writes:
>
>> rekado pushed a change to branch master
>> in repository guix.
>>
>> from 2bea3f2562 gnu: kubo: Unbundle go-cidutil, go-log and go-ipfs-util.
>>  new 79c2b32337 gnu: r-with-tests: Update to 4.4.0.
>
> ...
>
>>  new 5ad635ec49 gnu: r-job: Update to 0.3.1.
>>  new 6f95883d01 FIXUP r-infercnv
>>  new 1b6f915a88 gnu: r-rcppspdlog: Update to 0.0.17.
>
> ...
>
>>  new babafe251c gnu: r-icellnet: Update to 2.2.1-1.e10ee4a.
>>  new ba8d10c65a FIXUP r-bigmelon
>>  new 6745d692d4 gnu: rcas-web: Update to latest commit.
>>
>> The 670 revisions listed above as "new" are entirely new to this
>> repository and will be described in separate emails.  The revisions
>> listed as "add" were already present in the repository and have only
>> been added to this reference.
>
> Were these changes meant to be pushed to master?

Yes, they had been built on ci.guix.gnu.org in the r-updates jobset.

> These changes from r-updates have effectively jumped the queue past
> those on the core-updates and gnome-team branches, and since there was
> never a "Request for merging" issue opened [1], the bordeaux build farm
> is going to be delayed in building gnome-team as it tries to catch up
> with master.
>
> 1: 
> https://guix.gnu.org/manual/devel/en/html_node/Managing-Patches-and-Branches.html

Oh, this is new to me.  I've just read it.  (Good to know also for the
upcoming merge of the python-team branch!)

My apologies for not following this process for r-updates.  I'm hearing
about this for the first time now.  (I hope the previous wip-python-team
didn't cause too many problems for bordeaux.)

> Also, there appears to be a couple of FIXUP commits that were pushed.

Yeah, it's very annoying that I missed these two FIXUP commits :-/

-- 
Ricardo

Re: `make check` fails when trying to build from Git

[Ashvith Shetty]

Hi Ludovic,
Thank you for the timely response. I'm not sure about what input I should
provide for the first error, as it is probably something that I lack the
understanding of. However, with respect to the second failure, I adhere to
XDG compliance for most of my configs, so my git configs are actually
stored in `~/.config/git/config`. Could that have caused this issue?

On Thu, May 9, 2024 at 1:49 PM Ludovic Courtès  wrote:

> Hi Ashvith,
>
> (Cc: guix-devel.)
>
> Thanks for the logs!  They show two test failures:
>
> Ashvith Shetty  skribis:
>
> > test-name: terminal-string-width Japanese
> > location: /home/ashvith/Desktop/guix/tests/syscalls.scm:590
> > source:
> > + (test-equal
> > +   "terminal-string-width Japanese"
> > +   6
> > +   (terminal-string-width "???"))
> > expected-value: 6
> > actual-value: 3
> > result: FAIL
>
> This one happens when *not* running in a UTF-8-capable locale.  We
> should arrange so that the test is skipped in that case.
>
> > + cmp t-download-2080 /home/ashvith/Desktop/guix/README
> > + guix download file:///does-not-exist
> file:///home/ashvith/Desktop/guix/README
> > guix download: error: file:///home/ashvith/Desktop/guix/README:
> extraneous argument
> > + cd /tmp/tmp.yMJjm0ZbQf
> > + git init
> > Initialized empty Git repository in /tmp/tmp.yMJjm0ZbQf/.git/
> > + touch test
> > + git config user.name User
> > + git config user.email user@domain
> > + git add test
> > + git commit -m Commit
> > fatal: either user.signingkey or gpg.ssh.defaultKeyCommand needs to be
> configured
> > + rm -rf /tmp/tmp.yMJjm0ZbQf
> > + rm -f t-download-2080
> > + rm -rf t-archive-dir-2080
> > FAIL tests/guix-download.sh (exit status: 128)
>
> This one seems to have to do with your own ~/.gitconfig.  We should
> arrange so that Git doesn’t read ~/.gitconfig for these tests.
>
> Thanks,
> Ludo’.
>

Re: question on nss-certs

[Olivier Dion]

On Thu, 09 May 2024, Antonio Carlos Padoan Junior  
wrote:
> Hi,
>
> I made a system reconfigure today and I noticed that my folder
> /etc/ssl/certs disappeared and this annoys me (for instance, mbsync is
> missing it). I suppose this is related to the fact that nss-certs now is
> included in base-packages, but not sure. Am I supposed to still have the
> standard folder /etc/ssl/certs in my system? If no, how can I gracefully
> handle that?

This actualy broke my system.  Could not do `guix pull' anymore
afterward because it could not do authentication.  I had to roll-back to
previous system and remove nss-certs from the list of system packages
and reconfigure the system.

-- 
Olivier Dion
oldiob.ca

question on nss-certs

[Antonio Carlos Padoan Junior]

Hi,

I made a system reconfigure today and I noticed that my folder
/etc/ssl/certs disappeared and this annoys me (for instance, mbsync is
missing it). I suppose this is related to the fact that nss-certs now is
included in base-packages, but not sure. Am I supposed to still have the
standard folder /etc/ssl/certs in my system? If no, how can I gracefully
handle that?

This is the system I build this morning:


Generation 97   May 09 2024 12:07:20(current)
  nonguix 7081518
repository URL: https://gitlab.com/nonguix/nonguix
branch: master
commit: 7081518be7d2dbb58f3fbfeb1785254a6f0059c8
  guix cf5f7a8
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: cf5f7a8bf9ca2288700fcf351bbca0fc341ec969


-- 
Antonio Carlos PADOAN JUNIOR
PGP fingerprint:
243F 237F 2DD3 4DCA 4EA3  1341 2481 90F9 B421 A6C9

Re: Concerns/questions around Software Heritage Archive

[Maxim Cournoyer]

Hi Ian, Ludovic.

Ludovic Courtès  writes:

> Hi Ian,
>
> Ian Eure  skribis:
>
>> Summarizing the situation:
>>
>> - SHF has an opaque, difficult, and undocumented process for
>>   handling name changes.  I’s like to stress again that this is
>>   *not* strictly a transgender issue (though it likely affects   them
>>   more, or in worse/different ways) -- it is a human respect   issue.
>>   Many, many more cisgender people change their name than
>>   transgender people.
>
> It is also not strictly an SWH issue: how does Internet Archive handle
> name changes?  What about append-only storage in general?  We’ve
> discussed this already.

>> - SHF gave their archive to HuggingFace, an "AI" company which is
>>   generating derived works with no attribution or provenance, in
>>   ways which violate the both licenses of the projects used to   train
>>  their model, and the SHF principles for LLMs.
>
> [...]
>
>> - Has Guix reached out to SHF to express these concerns / get a
>>   response?
>
> I’ve seen and participated in informal discussions, but that’s all I
> know.  Maintainers?

We haven't.  Given some improvements were apparently already made by SWF
in response to concerns raised, it seems the dialogue should continue.

>> - Whether a public or private response, what would Guix consider   to
>>  be an acceptable response?  An unacceptable respoinse?
>> - How long is Guix willing to wait for a response?
>
> Free software people, myself included, have expressed disappointment
> regarding the use of code harvested by SWH for HuggingFace’s training.
> Stefano Zacchiroli of SWH responded to these concerns on Mastodon back
> in March, as you probably saw.
>
> One important point is that copyleft code is excluded from the training
> dataset; I was able to anecdotally check that for GPL code such as Guix
> using their interface (there was a thread on Mastodon but I can’t find
> it): .  That
> addresses my main concern.
>
> Remaining concerns include the weak wording of the principles put
> forward by SWH in its statement on LLMs:
> .
> I think this is something worth discussing further with them (it’s
> already been brought up notably on Mastodon).  It’s not clear to me
> whether this is a task for Guix as a project.

I don't think it is a task for Guix specifically, but rather for all
users of SWH or interested parties.

-- 
Thanks,
Maxim

Re: Core updates status

[Maxim Cournoyer]

Hi Josselin,

Josselin Poiret  writes:

> Hi Ludo,
>
> Ludovic Courtès  writes:
>
>> I’m in favor of whatever allows us to move forward more quickly, so
>> temporarily stashing away the pkgconf changes sounds good to me.
>>
>> In that case, when time permits, could you push a ‘core-updates-new’ (?)
>> branch, (partially) rebased and without the pkgconf changes, and a
>> separate ‘wip-pkgconf’ branch?  Does that seem doable to you?
>
> I did that partially yesterday, moved the old borked core-updates to
> old-core-updates and pushed the cleaned-up version at core-updates.  I
> haven't pushed the pkgconf patches anywhere yet, but we should probably
> focus on c-u for now and worry about that later.

All pkgconf related patches except the one effecting the actual
pkg-config -> pkgconf aliasing should be safe to merge already.

-- 
Thanks,
Maxim

Re: Core updates status

[Maxim Cournoyer]

Hi Andreas,

Andreas Enge  writes:

> Hello,
>
> Am Mon, May 06, 2024 at 10:47:13AM +0200 schrieb Josselin Poiret:
>> Maxim Cournoyer  writes:
>> > I don't mind too much; when we re-enable the change we should add a
>> > phase to the gnu-build-system automatically deleting/moving the libtool
>> > archives. so that we're covered.
>> 
>> I agree, although we'll have to be careful since some packages might
>> need them if they don't use pkg-config!
>
> I am a little bit confused by the suggestion; you mean removing all .la
> files from all packages?

Yes!

> I thought they were there for a reason, and usually recorded the
> dependencies. For instance, doing a "guix build mpc" and looking at
> libmpc.la, my impression is that I see correct information.

libtool records the *transitive* dependencies, as would be useful when
doing static builds but not shared builds, as the dependencies are
already recorded in the RUNPATH of the built ELF binaries.  For our
overwhelming common case (shared libraries) on GNU+Linux, these files
are thus unnecessary and when used they lead to over-linking (due to
listing the whole *transitive* dependencies) for shared library.  That
in turn muddles the dependency graph (as more references get retain in
the RUNPATH) and forces us to propagate more stuff.

> Why would
> one want to force upstream to add a pkgconfig dependency additionally
> to libtool? Or do I misunderstand the suggestion?

I hope my explanation above make it clear why libtool for our common
case of building shared libraries is not useful.

It could be useful when building shared libraries or targeting some
systems such as Android, which linker is very dumb or so I've heard. My
suggestion is to delete them by default, or move them to a 'libtool'
output when one is available (similarly to how we handle debug symbol
files).

-- 
Thanks,
Maxim

Re: `make check` fails when trying to build from Git

[Ludovic Courtès]

Hi Ashvith,

(Cc: guix-devel.)

Thanks for the logs!  They show two test failures:

Ashvith Shetty  skribis:

> test-name: terminal-string-width Japanese
> location: /home/ashvith/Desktop/guix/tests/syscalls.scm:590
> source:
> + (test-equal
> +   "terminal-string-width Japanese"
> +   6
> +   (terminal-string-width "???"))
> expected-value: 6
> actual-value: 3
> result: FAIL

This one happens when *not* running in a UTF-8-capable locale.  We
should arrange so that the test is skipped in that case.

> + cmp t-download-2080 /home/ashvith/Desktop/guix/README
> + guix download file:///does-not-exist 
> file:///home/ashvith/Desktop/guix/README
> guix download: error: file:///home/ashvith/Desktop/guix/README: extraneous 
> argument
> + cd /tmp/tmp.yMJjm0ZbQf
> + git init
> Initialized empty Git repository in /tmp/tmp.yMJjm0ZbQf/.git/
> + touch test
> + git config user.name User
> + git config user.email user@domain
> + git add test
> + git commit -m Commit
> fatal: either user.signingkey or gpg.ssh.defaultKeyCommand needs to be 
> configured
> + rm -rf /tmp/tmp.yMJjm0ZbQf
> + rm -f t-download-2080
> + rm -rf t-archive-dir-2080
> FAIL tests/guix-download.sh (exit status: 128)

This one seems to have to do with your own ~/.gitconfig.  We should
arrange so that Git doesn’t read ~/.gitconfig for these tests.

Thanks,
Ludo’.

Re: branch master updated (2bea3f2562 -> 6745d692d4)

[Christopher Baines]

guix-comm...@gnu.org writes:

> rekado pushed a change to branch master
> in repository guix.
>
> from 2bea3f2562 gnu: kubo: Unbundle go-cidutil, go-log and go-ipfs-util.
>  new 79c2b32337 gnu: r-with-tests: Update to 4.4.0.

...

>  new 5ad635ec49 gnu: r-job: Update to 0.3.1.
>  new 6f95883d01 FIXUP r-infercnv
>  new 1b6f915a88 gnu: r-rcppspdlog: Update to 0.0.17.

...

>  new babafe251c gnu: r-icellnet: Update to 2.2.1-1.e10ee4a.
>  new ba8d10c65a FIXUP r-bigmelon
>  new 6745d692d4 gnu: rcas-web: Update to latest commit.
>
> The 670 revisions listed above as "new" are entirely new to this
> repository and will be described in separate emails.  The revisions
> listed as "add" were already present in the repository and have only
> been added to this reference.

Were these changes meant to be pushed to master?

These changes from r-updates have effectively jumped the queue past
those on the core-updates and gnome-team branches, and since there was
never a "Request for merging" issue opened [1], the bordeaux build farm
is going to be delayed in building gnome-team as it tries to catch up
with master.

1: 
https://guix.gnu.org/manual/devel/en/html_node/Managing-Patches-and-Branches.html

Also, there appears to be a couple of FIXUP commits that were pushed.


signature.asc
Description: PGP signature