Re: Fallout from recent nss-certs changes

[pelzflorian (Florian Pelz)]

Ian Eure  writes:
> The change is mentioned in the channel news, but it says nothing about
> needing to remove that part of the config.

You are right; I have added more explicit instructions as commit
e5c0ea22e68cc8d6f99957295bc9198afb8455df.

Users should see it when they guix pull again.

Regards,
Florian

Re: Should we include nss-certs out of the box?

[pelzflorian (Florian Pelz)]

Fabio Natali  writes:
> For what it's worth, I put together a micro-patch and sent it over as a
> follow-up to #70451.

Pushed as 67a3a83170c038d2eb084d3f53a7ea7b033aea74.

Thank you!

Regards,
Florian

Change logs: usage of square brackets

[Nigko Yerden]

Hello Guix!

I wonder what is the proper usage of square brackets in change logs. 
According to 
https://www.gnu.org/prep/standards/standards.html#Change-Logs square 
brackets are used for conditional changes, the name of the condition is 
specified inside '[ ]'.  However looking over the commit history I 
mostly see another usage of '[ ]' for specifying the name of a record 
field which content is being changed.


Is it fine to use the name of a record field inside square brackets for 
changes that are only affected if the content of the record field is #t, 
like in https://issues.guix.gnu.org/70341#2 ?


Best Regards,
Nigko Yerden

Re: Guix bios installation: Grub error: unknown filesystem

[Ada Stevenson]

Hi Attila,

On 4/22/24 9:04 PM, Attila Lendvai wrote:

This should allow grub to recognise your filesystem during the
installation process. I think using a later version of grub would fix
this, but that hasn't happened yet. I think there's a patch to upgrade
it in `core-updates` somewhere, but I'm not sure.



grub seems to be still v2.06 there:

https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/bootloaders.scm?h=core-updates#n103



Maybe it would be a good idea to upgrade it then. This incompatibility 
has probably deterred many potential Guixers- it almost deterred me. 
Having this hacky workaround is just not good UX.


I'm not sure what upgrading GRUB would involve; maybe someone else on 
the mailing list has an idea on where to start? :)


Warmly,
Ada

Re: Value in adding Shepherd requirements to file-systems entries?

[Development of GNU Guix and the GNU System distribution.]

Hi Richard,

On Mon, Apr 22 2024, Richard Sent wrote:

> NFS is allegedly supported

Someone once gave me this service [1] to mount a file-system declared
with (mount? #f). [2] It's been working ever since.

Kind regards
Felix

[1] 
https://codeberg.org/lechner/system-config/src/commit/0131082ff0eb3f1262544f7799d291324ba08282/host/lechner-desktop/operating-system.scm#L209-L222
[2] 
https://codeberg.org/lechner/system-config/src/commit/0131082ff0eb3f1262544f7799d291324ba08282/host/lechner-desktop/operating-system.scm#L130-L139

Re: Sustainability fund application ongoing

[John Kehayias]

Hi Maxim, Ludo’, and everyone,

On Mon, Apr 22, 2024 at 01:52 PM, Maxim Cournoyer wrote:

> Hi Ludovic,
>
> Ludovic Courtès  writes:
>
>> Hi Maxim,
>>
>> Maxim Cournoyer  skribis:
>>
>>> It was pointed to us that the "Free and Open Source Software
>>> Sustainability Fund" [0] is currently receiving applications.  The fund
>>> aim to sponsors free software projects for their
>>> maintenance/organisational activities.
>>
>> Nice!  You forgot the link but I guess it’s
>> .
>> Deadline is May 17th.
>
> Indeed, thanks for pointing it out.
>

Thanks Maxim for sending this out, this looks like a great opportunity
(I'm sure quite competitive though)!

>>> I'm tempted to apply myself, but I thought I'd share it here: the more
>>> submissions they get the more likely Guix is to receive support.
>>
>> Agreed, it’s great to have people apply there (even better if it works,
>> of course).
>>

I'm still looking into the details of this group and their process,
but would it make sense to have small teams in applying (or in mind as
part of a proposal)? I'm thinking in terms of some input and
responsibility, for instance, in a proposal that wants to improve
things like new contributions, community, and related infrastructure
(Cuirass, Mumi, interfacing with debbugs more generally). I guess one
person applies, but in trying to figure out scope and who might be
involved should a proposal get funded it could be good to have some
people in mind.

>> Maybe we should provide a contact point for people who want to
>> coordinate when applying for Guix-related funding, to avoid overlapping
>> or competing applications?
>
> I guess we can use guix-devel for that purpose; the traffic would not justify 
> a new
> mailing list I guess (and we already have too many to keep track of :-)).

I am very interested in this and would love to discuss with some
people for needed information, input, things like scope and what would
have the most impact for Guix. So, I may be soliciting some help on
IRC, here, and reach out individually, but would love to put in a
strong proposal. (I'm at a time where I'm contemplating a career
shift, so this could fit in particularly nicely should I be so lucky.)

Thanks again Maxim for sending this!
John

Value in adding Shepherd requirements to file-systems entries?

[Richard Sent]

Hi Guix!

I wanted to ask the Guix community for their thoughts on improving the
support for adding networked file systems to an operating-system
declaration.

For some context, I started tackling adding CIFS support to file-system
declarations, but I've hit a snag. CIFS is a networked file system, but
Guix mounts all file systems specified in
(operating-system-file-systems) either when booting the system from the
initrd or as shepherd services after boot that depend on
'root-file-system and 'udev.

Either way, these run before any networking service has been
initialized. Ergo, a samba share like //192.168.1.102/share won't be
found. (At least, not on a wireless network. Perhaps the timing is
different for wired ones.)

Obviously, adding shepherd requirements to needed-at-boot? file systems
isn't possible. However, I think it should be possible to add shepherd
services to other file system entries.

(And yet, NFS is allegedly supported, although I can't figure out the
mechanism for that and don't have one set up on my LAN for testing.)

Before hacking away at this myself, I'd like to get other people's
thoughts on the best way to proceed. Do others agree that (file-system)
entries should support networked devices? Should this be transparent
depending on the type, or require explicit configuration?

e.g.

--8<---cut here---start->8---
(file-system
  (device "//192.168.1.102/share")
  (options "guest")
  (mount-point "/mnt/share")
  (type "cifs")
  ;; Should we explicitly require network, or implicitly add it from
  ;; the type? If the latter, what to do about Avahi?
  (requirement 'networking)
  (mount-may-fail? #t)
  (create-mount-point? #t))
--8<---cut here---end--->8---

I could see this being challenging since it's not immediately clear to
me what particular file-system-* service, if any, is provisioning
'file-systems, which other shepherd requirements the user may specify
can depend on. I imagine adding a requirement to the wrong file-system
could easily cause a deadlock.

I know a custom shepherd service could be used to run, say, mount.cifs
from userspace after networking is provisioned, but in my opinion it
would be cleaner to encapsulate within the existing file-system block of
the operating system.

-- 
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.

extlinux and a bootloader system rewrite

[Lilah Tascheter]

heyall!

I've been working on a large bootloader subsystem rewrite to get
everything working together nicer and support future bootloaders
better. however, extlinux is being a bit of an issue.

extlinux installs its second stage (ldlinux.sys) by copying it into the
root (or boot) filesystem, and then copying the on-disk block offset
into the bootblock first-stage. this relies on the now-heavily
discouraged practice of assuming files just stay in the same physical
spot. it requires special treatment with btrfs, will break if anything
rearranges the file-system, and will most likely never work on disk
images.

it hasn't been updated since 2014 and kinda shows.

a possible solution would be re-implementing its installer and instead
installing ldlinux.sys to a separate partition, or maybe see if it
could re-use GRUB's method of installing in the partition gap or even
editing the disk image installer to work in an losetup'd container or
some shit. but, honestly, I don't know if that would actually help
anyone.

does anyone use extlinux on guix still? would anyone mind if I just nix
it (guix it?) entirely in the patch series? grub supports every case
extlinux would support anyway.

thanks!
leila

Re: [PATCH] Fix typo (Re: Feedback of the GNU Guix manual)

[pelzflorian (Florian Pelz)]

Pushed as b8ccbc942e0ec7baf695d383e575991289c6e033.

Thank you for trudging on through the list.

Regards,
Florian

Re: Guix bios installation: Grub error: unknown filesystem

[Attila Lendvai]

> This should allow grub to recognise your filesystem during the
> installation process. I think using a later version of grub would fix
> this, but that hasn't happened yet. I think there's a patch to upgrade
> it in `core-updates` somewhere, but I'm not sure.


grub seems to be still v2.06 there:

https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/bootloaders.scm?h=core-updates#n103

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“In a democracy, mass opinion creates power. Power diverts funds to the 
manufacturers of opinion, who manufacture more, etc. […] This feedback loop 
generates a playing field on which the most competitive ideas are not those 
which best correspond to reality, but those which produce the strongest 
feedback.”
— Mencius Moldbug

[PATCH] Fix typo (Re: Feedback of the GNU Guix manual)

[Matt]

We're working through a list of feedback one item at a time:
https://lists.gnu.org/archive/html/guix-devel/2024-01/msg00117.html

We have completed the first four items.

The next item reported is:

#+begin_quote
3.8 Installing Guix in a Virtual Machine

L25 in an vm should be in a vm
#+end_quote

This is a nice, easy fix, good for me to practice getting the commit formatting 
correct :)


0001-doc-Fix-typo.patch
Description: Binary data

Re: Sustainability fund application ongoing

[Maxim Cournoyer]

Hi Ludovic,

Ludovic Courtès  writes:

> Hi Maxim,
>
> Maxim Cournoyer  skribis:
>
>> It was pointed to us that the "Free and Open Source Software
>> Sustainability Fund" [0] is currently receiving applications.  The fund
>> aim to sponsors free software projects for their
>> maintenance/organisational activities.
>
> Nice!  You forgot the link but I guess it’s
> .
> Deadline is May 17th.

Indeed, thanks for pointing it out.

>> I'm tempted to apply myself, but I thought I'd share it here: the more
>> submissions they get the more likely Guix is to receive support.
>
> Agreed, it’s great to have people apply there (even better if it works,
> of course).
>
> Maybe we should provide a contact point for people who want to
> coordinate when applying for Guix-related funding, to avoid overlapping
> or competing applications?

I guess we can use guix-devel for that purpose; the traffic would not justify a 
new
mailing list I guess (and we already have too many to keep track of :-)).

-- 
Thanks,
Maxim

Re: No default OpenJDK version?

[Maxim Cournoyer]

Hi,

Markku Korkeala  writes:

> On Tue, Apr 16, 2024 at 10:37:30PM +0200, Julien Lepiller wrote:
>> Currently, most java packages use the implicit jdk from the build
>> system (ant- or maven-build-system), which is… icedtea@8. We still
>> have quite a lot of old packages that don't build with openjdk9, so
>> I'm not sure when we can update the default jdk…
>
> Hi,
>
> is there effort to update the default jdk at some point? I could help with
> it. I'm not familiar with the guix java build systems, but have long
> experience as a Java developer. I also maintain few java packages in Fedora
> and saw the transition to to jdk11 [1], jdk17 [2] and now to jdk21 [3]. The
> pages have documented common issues and workarounds, which might help.

I'm not aware of such effort in Guix currently, so feel free to
spearhead it!  It'd be beneficial, although I supposed difficult to
achieve due to bootstrap reasons, perhaps.

-- 
Thanks,
Maxim

Re: Python's native-inputs

[Maxim Cournoyer]

Hi Nicolas,

Nicolas Graves  writes:

[...]

>  TL;DR :
>  - patch series in big progress, not done yet because I don't really
>  know where to stop and massive rebuilds.
>  - WDYT about tweaking the build-system for pytest?
>  - not done : tweaking the pypi import to ignore those packages. I've
>  done it in the juliahub import code, but I haven't delved into that
>  though.
>  - not done : adding those packages to guix lint - trivial. We should
>  probably add a variable in pypi import that is exported and added into
>  guix lint.
>
>  Acting on the three (guix import, guix lint, guix build) can make it
>  quite easy on maintainers in the end IMO.

You're bringing good arguments.  If you can pull it off in the way
outlined above, I agree it's be valuable to have.

-- 
Thanks,
Maxim

is git the right tool for getting package definitions?

[Adam]

(original message was formatted in rich text, so I decided to resend
it in plain text)
Hi guix!
Recently I used nixos on one of my machines. And I noticed people
there use tar balls for fetching package definitions. And It worked
much faster for me.
That was surprising and I decided to write this letter.
Is git the right tool for getting new package definitions? What if git
commits history will become enormous?
As I see, the first guix pull is running too long for a lot of people.
Probably, there are ways to cache all of this.
Anyway, I'm just curious about it. If there are already answers for my
question, I would like to read them.

Is git the best tool for pulling packages?

[Adam]

Hi guix!
Recently I used nixos on one of my machines. And I noticed people there use
tar balls for fetching package definitions. And It worked much faster for
me.
That was surprising and I decided to write this letter.
Is git the right tool for getting new package definitions? What if git
commits history will become enormous?
As I see, first guix pull running too long for a lot of people.
Probably there are ways to cache all of this.
Anyway,  I'm just curious about it. If there are already answers for my
question, I would like to read them.

Re: Status of ‘core-updates’

[Efraim Flashner]

On Wed, Apr 17, 2024 at 01:47:49PM -0400, Maxim Cournoyer wrote:
> Hello,
> 
> Ludovic Courtès  writes:
> 
> > Hi Steve,
> >
> > Steve George  skribis:
> >
> >> On 10 Apr, Ludovic Courtès wrote:
> >
> > [...]
> >
> >>> To be clear (but I guess it’s crystal clear to anyone who’s been around
> >>> long enough :-)), what we need most is someone to keep track of changes,
> >>> coordinate efforts, decide what goes in the branch and what’s postponed
> >>> or moved to a separate branch, and send periodic (weekly) status updates
> >>> over the course of a couple of months.  This can (and probably should)
> >>> be done without doing any actual hacking on the branch.
> >> (...)
> >>
> >> This sounds like something I can do:
> >>
> >> - track changes (in branch)
> >> - co-ordinate blocking issues (in bug system)
> >> - co-ordinate with people doing the actual work :-P
> >> - send (periodic) weekly emails
> >> - encourage shipping by minimising scope creep ;-)
> >
> > Awesome, thanks for volunteering!
> >
> >> Sounds like there's already agreement to revert the 'pkgconf' change
> >> and push a new branch without them which becomes
> >> 'core-updates'. Josselin on IRC I had the impression you were
> >> working on that?
> >
> > I’m not sure what the situation is (I see Maxim just pushed changes on
> > top of current ‘core-updates’, so maybe it’s OK?).
> 
> Since branches were merged in, I believe the problem we are facing at
> the moment is librsvg failing its test suite with a segfault (!).  Could
> be the glibc upgrade, or rust itself, I'm not sure.  I was trying to
> upgrade librsvg, which needs an update anyway, but it pulls many rust
> crates updates.  I'll get there eventually, if nobody beats me to it.

I personally think getting librsvg updated will be easier on the
rust-team branch than on the core-updates branch, since there have been
many commits to the rust-team branch that haven't yet been merged into
master.

Assuming that now that the cairo upgrade to 1.18 was what was holding
back the librsvg upgrade, I can get librsvg up to a newer version and
then submit it for a merge.  Overall the branch should be in fairly good
shape.

> > Josselin, Maxim: could you explain what problems there are around
> > pkgconf and what you would recommend?
> 
> Nothing in particular to point at the moment, but remaining problems
> would manifest in the form of missing inputs, due to transitive libtool
> dependencies causing overlinking and the new pkgconf being smart enough
> to optimize away some previously captured link directives that would be
> baked in the RUNPATH and sastify libtool overlinking needs.
> 
> The solution is to hunt the libtool .la files from the transitive
> dependencies causing the problem and removing them. See commit
> b6540bd285cbe5920ad379ddfc6256359ee7204c for an example.
> 
> -- 
> Thanks,
> Maxim
> 

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

Re: Python's native-inputs

[Ricardo Wurmus]

>  TL;DR :
>  - patch series in big progress, not done yet because I don't really
>  know where to stop and massive rebuilds.

Please take a look at the python-team branch, which contains changes to
the build system.

-- 
Ricardo

Re: Python's native-inputs

[Development of GNU Guix and the GNU System distribution.]

Answer in two different emails.

 On 2024-04-18 22:07, Maxim Cournoyer wrote:

> Hi Nicolas,
>
> Nicolas Graves via "Development of GNU Guix and the GNU System
> distribution."  writes:
>
>> Hi Guix,
>>
>> On some languages, there are a lot of unused native-inputs that are
>> development & linting dependencies much more than packages that are
>> actually used to build or test a package (I'm thinking at least Python
>> and Rust). These fall in the category of tools "useful" at run time, but
>> unecessary at build time.
>
> Indeed.

One more argument: it's important for user experience using python to
have these packages up-to-date, because users will want to have an
up-to-date lsp client and utilities.

>
>> Is there a clear policy about their removal? I've seen the case of
>> pre-commit in Python, and I've commited a series yesterday regarding
>> pylint, but there are a whole lot of them in Python, at least :
>
> [...]
>
>> These packages make a lot of sense when considering things like
>> `guix shell -D` but they are hampering some progress on Python packages
>> since they are everywhere and a small update in their inputs rebuilds
>> the whole python world (even though it has NO influence on the
>> functionality of any other package).
>>
>> What are the guidelines in this case?
>
> There aren't really any guidelines.  It's easy to avoid the linters, it
> makes sense to avoid them, but sometimes upstream makes it difficult to
> avoid running a linter as part of there test suite, in which case I
> think it's acceptable to keep them as native-inputs rather than come up
> with more patches to maintain.
>
>> I can propose a huge patch series (currently ~300 patches, and not
>> finished), to remove them, lint against them and remove them from the
>> importer as a default, but that's a big decision to make. IMO we should
>> have a dev-inputs field to handle these cases, but that's even more work.
>
> The situation is similar as for other test inputs such as pytest; it has
> an enormous amounts of dependents and thus cannot be easily upgraded on
> the master branch.  At least more up-to-date variants can be added since
> these are not in the transitive closure of any packages.

 That's true for some very essential packages (setuptools, pytest...)
 which would make the case to only update these packages once we want to
 update the whole python chain, i.e. when we update python. But IMO it
 shouldn't be the case for a package like black, isort or flake8.

>
> I don't think we should go out of our way to address annoyances that
> upstream have caused -- that'd be too much work to maintain in the long
> run.

 I think it depends on the case. For a package like python-dateutil,
 having pytest-cov as a native-input is bad, because it causes a rebuild
 of the whole chain (guix refresh -l python-pytest-cov went from ~2500
 to ~15 packages with the whole series, but in particular that was a big
 part of dependency removal). Now for small leaf packages, having
 pytest-cov as a native-input is not a big issue indeed, I agree in
 those cases we would better ignore it than fix it in the meantime.

 While making the patches, I realized it's not often that we need a
 convoluted patch. Most of the time, adding "-c" "/dev/null" to
 test-flags will do the trick to remove python-pytest-cov and it's even
 less annoyance for black, flake8 or mypy, if not other cases are often
 handled with a simple removal of the native-input in pyproject.toml, or
 setup.py. What's annoying is when packages are flagged as required when
 they're not.

 It could possibly even be handled in the build-system in the case of
 pytest, to avoid these "-c" "/dev/null". This is untested, but I think
 it'll work.
 
;; Add a pytest plugin for the pyproject-build-system to filter out some
;; arguments we want to be able to ignore.
;; (define (pytest-ignore-options group-options-alist)
;;   "This function converts an alist of (group . options) in a string that can
;; be instantiated as a python pytest plugin."
;;   (string-join
;;(cons*
;; "import pytest"
;; (map
;;  (match-lambda
;;((group . options)
;; (string-append
;;  (format #f "def pytest_addoption(parser):
;; group = parser.getgroup(~s,'Guix ignored options')
;; options = [~{~s, ~}]
;; for option in options:
;; group.addoption(option, action='count')"
;;  group
;;  options
;;  group-options-alist))
;;"\n\n"))

;; (let ((cov-alist
;;'(("cov" . ("--cov" "--cov-reset" "--cov-report" "--cov-config"
;;"--no-cov-on-fail" "--no-cov" "--cov-fail-under"
;;"--cov-append" "--cov-branch" "--cov-context")
;;   (display (pytest-ignore-options cov-alist)))

;; TODO Instantiate this file, add it to the check phase through the 
;; PYTEST_PLUGINS environment variable (possibly also PYTHONPATH or 
GUIX_PYTHONPATH ?)
;; reference: 
https://docs.pytest.org/en/7.1.x/how-to

Re: Adding plumbing subcommand 'derivation'?

[Simon Tournier]

Hi,

On ven., 19 avril 2024 at 16:02, Ludovic Courtès  wrote:

> We should see how that fits into the set of tools we already have, in
> particular the (guix derivations) interface and the REPL meta-commands.
>
> My gut feeling, with a Schemer bias, is that we’d rather enrich the
> Scheme API and/or REPL than add more commands (this is not Nix :-)).
>
> But I don’t know, maybe we can have both?

Yes, I think that’s orthogonal and a good idea.

Maybe a new plumbing generic subcommand, as “guix inspect” or “guix
store”, where showing the fields of a derivation would be a
sub-subcommand.  For instance, diffing two derivations from the
command-line seems helpful when  debugging – I often do that with Emacs
exploiting buffer facilities. :-)

In addition, it could be helpful to improve the readability for the
pretty-printer.  Other said, somehow redesign this:

--8<---cut here---start->8---
(set-record-type-printer! 
  (lambda (drv port)
(format port "# ~a ~a>"
(derivation-file-name drv)
(string-join
 (map (match-lambda
   ((_ . output)
(derivation-output-path output)))
  (derivation-outputs drv)))
(number->string (object-address drv) 16
--8<---cut here---end--->8---

It looks like a plan. ;-)

Cheers,
simon

Re: bug#63267: gcc-toolchain is missing libstdc++.so

[Simon Tournier]

Hi,

On mer., 17 avril 2024 at 05:21, John Kehayias via Bug reports for GNU Guix 
 wrote:

> I've just pushed, as b47ae1ecc43baaf726701ab2d2f810ecfaa75428,

Cool!  Thank you for crossing the finish line.

Cheers,
simon