Re: Linux-libre source code will be taken offline

[zimoun]

Hi,

On Mon, 27 Sep 2021 at 17:46, Jason Self  wrote:

>> https://linux-libre.fsfla.org/pub/linux-libre/releases/old/
>
> Yes. In gen6. They have been moved, not deleted.
>
> The versioning and locations in terms of gnuN and genN are knowable and
> predictable in advance. I wonder if there is, or could be made, a way to
> leverage that so that future moving of files can be done without
> causing problems, as long as the files themselves remain otherwise
> identical. As an example, the current cleanup scripts might be found in
> old/gen7 in the future. Although using git would probably be a better
> choice as it would seem to eliminate URL hunting.

Guix has the availability to transparently build any old version using
“guix time-machine”, i.e.,

  guix time-machine --commit=0c7c84407d65f3d03ad1fe3984ae4d524992f498 \
   -- build linux-libre

should build the Linux (libre) kernel as it was on 2020, 25th May.

If the user allow substitutes, then the necessary materials is fetch
from machines hosted in Berlin and maintain by Guix folk.

However, if the user does not allow substitutes, then the source are
first fetched from upstream.  Here several cases of origin.  Upstream is
still up, everything is fine.  Upstream disappeared in the meantime, it
depends on the “type” of the origin and the core issue is the mapping
between the information at package time (e.g., 2020, 25th May) and the
servers providing a fallback at request time for this missing source.

When the upstream source is a Git repo, this map is a simple
contend-addressed lookup by a (almost) straightforward resolver.

When the upstream source is not Git repo, this map becomes harder and
requires – in addition to a fallback server – an external resolver:
something that maps from the information at package time (2020, 25th
May) to the fallback server.

If the package linux-libre defined on 2020, 25th May (written on stone)
points to an URL source which disappears, this Guix time-machine feature
becomes doomed because URL is a really bad contend-addressed system as
all the broken internet shows us.

For sure, the infrastructure needs to evolve for a better future; easier
maintainability for instance.  However, please consider the archivist
point of view and help to not break the past. :-)


Cheers,
simon

Re: Merging wip-guix-home to master

[Andrew Tropin]

On 2021-09-24 15:38, Xinglu Chen wrote:

> On Thu, Sep 23 2021, Andrew Tropin wrote:
>
>> The core part of Guix Home project has been moved from rde
>> repository[fn:1] to wip-guix-home branch of guix repository.
>>
>> I'm about a week on wip-guix-home branch completely and Guix Home works
>> fine.  There are no any major issues on rde-devel and guix-devel mailing
>> lists and it seems that branch is ready to be merged.
>>
>> My guix describe looks like:
>> --8<---cut here---start->8---
>> Generation 114   Sep 17 2021 13:33:55(current)
>>   rde 31f8003
>> repository URL: https://git.sr.ht/~abcdw/rde
>> branch: without-guix-home
>> commit: 31f800353a781cef25fc80c05ad824a068a049c8
>>   guix a2324d8
>> repository URL: https://git.savannah.gnu.org/git/guix.git
>> branch: wip-guix-home
>> commit: a2324d8b56eabf8117bca220a507cc791edffd2e
>> --8<---cut here---end--->8---
>>
>>
>> There is a discussion[fn:2] on moving home services to (gnu services
>> ...)  modules, which is likely to happen, but it's possible to do the
>> migration relatively painless by re-exporting necessary symbols in
>> (gnu home-services ...) at first and removing them completely later.
>>
>> Another important part of the work related to Guix Home project is
>> covering related modules and cli with tests, but it can be done in
>> parallel and is not a blocker for merging.
>
> I noticed that the ‘guix home import’ subcommand is included, but I
> think it needs more thought and feedback from people before it makes its
> way into ‘master’; it also seems to lack documentation.
>
> I just realized that it generates the following service declaration
>
> --8<---cut here---start->8---
> (service
>  home-bash-service-type
>  (home-bash-configuration
>   (bashrc
>(list (slurp-file-gexp
>   (local-file "/home/yoctocell/.bashrc"))
> --8<---cut here---end--->8---
>
> but when running ‘guix home reconfigure’, the ~/.bashrc file will be
> moved, so when running ‘guix home reconfigure’ for the second time, it
> would read the ~/.bashrc which is itself a symlink to a file the store.
> ‘guix home import’ clearly isn’t in a usable state as of right now…

Yep, I remember that it is not documented.  I think it's ok for
generating a simple sample configuration, but I agree that it's not yet
complete, if you wish I'll disable it in cli.

Just an idea for the future: it's probably better to copy .bashrc to the
current directory and do (local-file "./bashrc").


signature.asc
Description: PGP signature

Re: Building guix system

[Brendan Tildesley]

To build the Guix System (The complete system you would call a GNU/Linux 
distribution),
first, install Guix its self on your existing distribution.

https://guix.gnu.org/manual/en/html_node/Binary-Installation.html

It's a bit involved since Guix is a unique program.
Then, download the git repository

https://git.savannah.gnu.org/git/guix.git

cd guix;
Then you can build an image for any operating system definition. Start with one 
of the
examples in gnu/system/examples:
guix system image -t iso9660 gnu/system/examples/desktop.tmpl

core-updates-frozen: Planning for the last world rebuild

[Ludovic Courtès]

Hello Guix!

Wouldn’t it be nice to get ‘core-updates-frozen’ merged?  :-)

What about merging the patches blocked by
?  We could even have them on a
separate branch, have Cuirass build it, and merge it 24–36h later, at
which point substitute coverage should be reasonably good.

I haven’t followed the new ports, POWER9 and RISC-V.  If there’s
anything needed in this area, like localized toolchain changes, please
send a heads-up!

As I say every time someone proposes a new port, the main issue is not
the port itself but maintaining it longer-term.  And here it’s not even
clear to me what the status of POWER9 is on ‘core-updates-frozen’, so
it’d be great to get feedback on this, ensure Cuirass builds it, and so
on.

Thanks,
Ludo’.

Re: eudev deprecation

[Ludovic Courtès]

Hi,

Lars-Dominik Braun  skribis:

> it looks like eudev, which we heavily rely on, is dead upstream:
> https://github.com/gentoo/eudev/issues/199
>
> Looking at Gentoo’s ebuilds it should be possible to “extract”
> and build udev from systemd’s sources.

Good.  That’s essentially what eudev is.

Tobias Geerinckx-Rice  skribis:

> Further update:
>
>> ADOPTION NOTICE (2021-09-14)
>> Currently eudev is in the process of being adopted by a newly
>> formed project by Alpine, Devuan and Gentoo contributors [...]
>
> -- https://github.com/eudev-project/eudev
>
> We'll see?  Talk and Git repos are cheap; actually putting in this
> work is not.

Interesting.

Julien mentioned on IRC that Linux From Scratch is also considering
switching.  Julien, what’s the takeaway from the LFS discussions so far?

Thanks,
Ludo’.

Re: On the naming of System and Home services modules.

[Ludovic Courtès]

Hi Andrew,

Andrew Tropin  skribis:

> On 2021-09-23 22:08, Ludovic Courtès wrote:

[...]

>> Silly question, but why do we need to have two different configuration
>> record types in the first place?

To be clear: you’ll have to be very convincing as I know all too well
the cost of maintaining such a thing :-) and can already foresee that
this would also be annoying to users.

> 1. Different fields (for example system services in many cases wants to
> know the username, which will be used to run process from, home services
> will probably use the user's username and won't rely on this field, home
> services on the other hand can have something like xdg-flavor? or
> anything else unrelated to system services).
>
> Even if fields are not conflicting with each other, it's very likely
> that it will introduce a confusion: user of Guix Home on foreign distro
> will be guessing why there is a field in configuration record, which
> doesn't make sense for a home service.

Do you have specific examples?  The user name example isn’t a convincing
one for me, at least not in the abstract.

> 2. Different default values.  $HOME/mail or /var/spool/mail? Even if we
> can technically bypass those problems, semantically the values will be
> incorrect.

Again, any specific example?  How frequently does this problem occur?

It could be solved, say, by having a ‘home-service?’ Boolean in the
config, which default values would take into account.

>> Sharing configuration between Home and System sounds important to me: it
>> means users can easily move services from one to the other, which is
>> pretty big deal.  It also means we’d have much less code to maintain.
>>
>> Would that be feasible?  (Apologies if this has already been discussed!)
>
> I find records to be a very rigid and hard to reuse

We can discuss the suitability of records, but we need an immediate
solution to the problem, especially now that it’s in ‘master’.

Duplicating configuration records for each and every service could have
a huge maintenance cost that we’re probably not willing to pay.

>> Also, I proposed earlier a possible way to generate a Home service type
>> from the corresponding System service type—or, IOW, to generate a Home
>> service type graph from the System graph.  Does that sound feasible?
>
> Not sure what you mean here, can you share a link to the proposal or
> elaborate one more time, please.

I can’t find the message anymore.  The suggestion is to have helpers to
“rewrite” the System service type graph for Home, so you could do things
like:

  (define home-profile-service-type
(system->home-service-type profile-service-type))

  (define home-mcron-service-type
(system->home-service-type mcron-service-type))

because fundamentally, these two things are the same as their System
counterpart, except that they graph is rooted in ‘home-service-type’ (or
whatever it’s called) instead of ‘system-service-type’.

Of course there are exceptions, but it may be possible to do that for
quite a few services.

Thoughts?

Ludo’.

Re: Code sharing between system and home services (was Re: On the naming of System and Home services modules.)

[Ludovic Courtès]

Hi,

Xinglu Chen  skribis:

> I didn’t know about the parent mechanism; that could be an approach to
> take.  But since ‘define-configuration’ is based on (guix records),
> would it make sense to adapt (guix records) to (rnrs records syntactic)
> instead of SRFI-9 records?

Yes, it would make sense (using the lower-level record API, as Maxime
writes), and it’d be useful in other situations as well.

I can take a look if nobody beats me.

Thanks,
Ludo’.

Re: core-updates-frozen: Planning for the last world rebuild

[Mathieu Othacehe]

Hey!

> Wouldn’t it be nice to get ‘core-updates-frozen’ merged?  :-)

That would be great :) Before merging to master, it would be nice to
have more system tests passing. Currently 16 out of 87 are
broken. Except for the nfs-root-fs that has always been broken, the
other tests probably cover user configurations out there.

I'm currently working on the installation tests.

Thanks,

Mathieu

Re: Code sharing between system and home services (was Re: On the naming of System and Home services modules.)

[Ludovic Courtès]

Hi,

Joshua Branson  skribis:

> Apologies if I'm speaking for something I know very little
> about...Wouldn't it be nice if guix home services would accept a user
> and a group field?  For the syncthing service, perhaps the user wants to
> limit Syncthing's runtime permissions.  So instead of running as the
> user, the user would run synthing as a different user with less permissions?

That’s not possible unless the calling user is root, since you’d need
the ability to switch users somehow.

> Please note it may be much better to just container-ize the synthing
> service.  Does guix home have that ability?
>
> https://guix.gnu.org/en/blog/2017/running-system-services-in-containers/

It can gain that availability without doing anything actually: service
implementations “just” need to use ‘make-forkexec-constructor/container’
instead of ‘make-forkexec-constructor’.

However, that would only work on systems where unprivileged user
namespaces are enabled, so we’d need a way to turn it off.

Ludo’.

Re: On the naming of System and Home services modules.

[Ludovic Courtès]

Hi,

(+ Cc: Oleg.)

Andrew Tropin  skribis:

> For now my personal ranking of the ideas is following:
>
> 1. Move to (gnu services ...) :: can(?) provide some additional reusability.
> 2. Keep as it is right now (gnu home-services ...) :: already works.
> 3. Move to (gnu home services ...) :: good stylistic change, but breaks
> backward compatibility.

As I stated in another message, backward compatibility is not a concern
here from the Guix POV (of course it’s a concern for those who were
already using pre-merge Guix Home, but for Guix all these APIs are new.)

(As an aside, part of the reason I asked a few days ago to have more
time for review was precisely so we could refine the APIs before it goes
public.)

I would very much like to have these modules renamed to (gnu home
services …) quickly.  WDYT?  Could the two of you take a look?

Thanks,
Ludo’.

Re: guix weather -m etc/sources-manifest.scm and CI?

[Ludovic Courtès]

Hello!

zimoun  skribis:

> On Thu, 23 Sep 2021 at 22:18, Ludovic Courtès  wrote:

[...]

>> I set up a Cuirass job the other day¹, but due to my aforementioned
>> disorganization, I haven’t yet taken the time to investigate its
>> failure.
>>
>> ¹ https://ci.guix.gnu.org/jobset/source
>
> Cool!

It turns out that at first sight I can’t see what I’m doing wrong here.
Evaluation fails with:

--8<---cut here---start->8---
Computing Guix derivation for 'x86_64-linux'...  
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
#:16:103: Unknown # object: "#<"
--8<---cut here---end--->8---

Mathieu, could it have to do with the fact that the manifest is within
the ‘guix’ channel?

Thanks,
Ludo’.

Re: Merging wip-guix-home to master

[Ludovic Courtès]

Xinglu Chen  skribis:

> I noticed that the ‘guix home import’ subcommand is included, but I
> think it needs more thought and feedback from people before it makes its
> way into ‘master’; it also seems to lack documentation.

Agreed.  There are a few (very few) exceptions, but in general each
command needs (1) a section in the manual and (2) unit tests and/or
integration tests in a shell script.

Could you submit patches for that?

IWBN if others could do an after-the-fact review of the code, too.

> I just realized that it generates the following service declaration
>
> (service
>  home-bash-service-type
>  (home-bash-configuration
>   (bashrc
>(list (slurp-file-gexp
>   (local-file "/home/yoctocell/.bashrc"))
>
> but when running ‘guix home reconfigure’, the ~/.bashrc file will be
> moved, so when running ‘guix home reconfigure’ for the second time, it
> would read the ~/.bashrc which is itself a symlink to a file the store.
> ‘guix home import’ clearly isn’t in a usable state as of right now…

Also, I argued earlier against ‘slurp-file-gexp’:

  https://lists.gnu.org/archive/html/guix-devel/2021-06/msg00192.html

I haven’t checked the different service configuration APIs, but I think
we should avoid uses of ‘slurp-file-gexp’ entirely and instead do the
same as in the majority of Guix System services, which is to accept
file-like objects.

Thoughts?  Could you take a look?

Thanks,
Ludo’.

Dealing with interface deprecation

[Ludovic Courtès]

Hello Guix!

In Guix, configuration is code, which is great!  But that also means
users occasionally have to deal with things like “API deprecation”,
which never sounds exciting, especially when all you want is to get your
system upgraded Right Now.

So I think it’s important to be very careful in how we deal with API
deprecation, in particular in Guix System (and in Guix Home once we’ve
removed the “technology preview” label).

There were two examples where, with my “regular user” hat on (which I
particularly enjoy), I got deprecation messages that were not actionable
for me because they lacked source location info.  This was addressed by
these changes:

  
https://git.savannah.gnu.org/cgit/guix.git/commit?id=e0bd47b4fd5eb009f34004242e16b976e58756b0
  
https://git.savannah.gnu.org/cgit/guix.git/commit?id=baf4272df2350a40bfa198f5cdb42e707e32ad71

As you can see, providing good actionable messages for record field
deprecation is a bit of a craft, but hopefully that gives an idea of how
to get there; maybe we’ll eventually come up with a high-level way to
express that.

Packages may also be part of the “API”.  On ‘core-updates’, several TeX
Live packages were deprecated but still used because there wasn’t any
warning.  This is how I addressed it:

  
https://git.savannah.gnu.org/cgit/guix.git/commit?id=3dc8052b51241fe7857059d3300dad3a0f9f68fd

Thoughts?  Tips and tricks?

Ludo’.

Re: Linux-libre source code will be taken offline

[Ludovic Courtès]

Hi,

Vagrant Cascadian  skribis:

> Not sure exactly how Software Heritage handles rebased branches...

It keeps the history of the history, so to speak.  A “snapshot” in SWH
parlance contains the branches as they existed at one point in time.

Ludo’.

Re: guix environment --load vs. --file inconsistency

[Ludovic Courtès]

Hi Robin & Attila,

Attila Lendvai  skribis:

> FWIW, i'm new to Guix, and it was enough to read the --help output to
> understand how --file works, but i still don't know what manifests are
> (even though i'm regularly using `guix package -m
> /path/to/manifest.scm`, which i have copied from somewhere).
>
> i know where it's documented. what i'm talking about here is how to
> optimize the results/time ratio of the project for newcomers; IOW, the
> project's approachability. i just haven't gotten to reading up on
> manifests, and yet i'm already getting things done.

Alright, I hadn’t seen it from that perspective, but that makes a lot of
sense.

Thanks for your feedback,
Ludo’.

PS:  hopefully contains enough
about manifests to get you started.

Re: On the naming of System and Home services modules.

[Andrew Tropin]

On 2021-09-28 14:26, Ludovic Courtès wrote:

> Hi,
>
> (+ Cc: Oleg.)
>
> Andrew Tropin  skribis:
>
>> For now my personal ranking of the ideas is following:
>>
>> 1. Move to (gnu services ...) :: can(?) provide some additional reusability.
>> 2. Keep as it is right now (gnu home-services ...) :: already works.
>> 3. Move to (gnu home services ...) :: good stylistic change, but breaks
>> backward compatibility.
>
> As I stated in another message, backward compatibility is not a concern
> here from the Guix POV (of course it’s a concern for those who were
> already using pre-merge Guix Home, but for Guix all these APIs are new.)
>
> (As an aside, part of the reason I asked a few days ago to have more
> time for review was precisely so we could refine the APIs before it goes
> public.)
>
> I would very much like to have these modules renamed to (gnu home
> services …) quickly.  WDYT?  Could the two of you take a look?

Doable.

What about moving home services to (gnu services ...)?

It's a little harder, because we probably will need to adjust `guix
system search` and `guix home search`, but other than that seems not too
hard.

However, I'm quite ok with (gnu home services ...), just asking to avoid
one more migration later.

Let me know, which option seems better to you, I can take this task
tomorrow.

>
> Thanks,
> Ludo’.


signature.asc
Description: PGP signature

Re: Linux-libre source code will be taken offline

[Jason Self]

On Tue, 28 Sep 2021 10:43:20 +0200
zimoun  wrote:

> Hi,
> 
> On Mon, 27 Sep 2021 at 17:46, Jason Self  wrote:
> 
>  [...]  
> >
> > Yes. In gen6. They have been moved, not deleted.
> >
> > The versioning and locations in terms of gnuN and genN are knowable
> > and predictable in advance. I wonder if there is, or could be made,
> > a way to leverage that so that future moving of files can be done
> > without causing problems, as long as the files themselves remain
> > otherwise identical. As an example, the current cleanup scripts
> > might be found in old/gen7 in the future. Although using git would
> > probably be a better choice as it would seem to eliminate URL
> > hunting.  
> 
> Guix has the availability to transparently build any old version using
> “guix time-machine”, i.e.,
> 
>   guix time-machine --commit=0c7c84407d65f3d03ad1fe3984ae4d524992f498
> \ -- build linux-libre
> 
> should build the Linux (libre) kernel as it was on 2020, 25th May.
> 
> If the user allow substitutes, then the necessary materials is fetch
> from machines hosted in Berlin and maintain by Guix folk.
> 
> However, if the user does not allow substitutes, then the source are
> first fetched from upstream.  Here several cases of origin.  Upstream
> is still up, everything is fine.  Upstream disappeared in the
> meantime, it depends on the “type” of the origin and the core issue
> is the mapping between the information at package time (e.g., 2020,
> 25th May) and the servers providing a fallback at request time for
> this missing source.
> 
> When the upstream source is a Git repo, this map is a simple
> contend-addressed lookup by a (almost) straightforward resolver.
> 
> When the upstream source is not Git repo, this map becomes harder and
> requires – in addition to a fallback server – an external resolver:
> something that maps from the information at package time (2020, 25th
> May) to the fallback server.
> 
> If the package linux-libre defined on 2020, 25th May (written on
> stone) points to an URL source which disappears, this Guix
> time-machine feature becomes doomed because URL is a really bad
> contend-addressed system as all the broken internet shows us.
> 
> For sure, the infrastructure needs to evolve for a better future;
> easier maintainability for instance.  However, please consider the
> archivist point of view and help to not break the past. :-)

It's not really breaking the past if this is how the past worked in
reality: That previous generations of scripts are moved to old/genN,
but more of Guix's representation of how the past worked which says
that they not move, which doesn't reflect the actual reality of the
past. The two don't seem equivalent.

It seems that Guix can handle multiple download locations already,
either from the main location or from others so why is the old/gen7
location not already in the kernel build recipe? If a new freedom
problem were found that resulted in the need to come up with an 8th
generation, the current ones will be findable in old/gen7. Is Guix
build machinery currently aware of that and ready to check old/gen7
now for whenever that future move happens? If not, then this would seem
to create future breakage when that happens. This move is 100% knowable
and predictable in advance so why not have it ready for now and put
old/gen7 into the recipe for the kernel, even if it's just an additional
hardcoded URL and not something dynamically computed? If not, using git
would seem to be a better choice. I'm not sure why it's not used
already.


pgpBs5nAG4au9.pgp
Description: OpenPGP digital signature

Re: Linux-libre source code will be taken offline

[Jason Self]

Granted that old/gen7 is not currently a valid URL but we can know
that, 5 or 10 years from now, when Linux-libre has moved on to the 8th,
9th or even 10th generation, the 7th generation scripts will exist
there. If Guix can begin checking those additional locations now then,
in the future once the current Guix version becomes an old version,
hopefully it can transparently handle that transition without issue. Or
just use git. :)

Even this method is just a band-aid though and has a different set of
challenges for the long-term. I'd be happy to discuss that with whoever
is interested.


pgpQIsClMHVKg.pgp
Description: OpenPGP digital signature

Re: Merging wip-guix-home to master

[Xinglu Chen]

On Tue, Sep 28 2021, Ludovic Courtès wrote:

> Xinglu Chen  skribis:
>
>> I noticed that the ‘guix home import’ subcommand is included, but I
>> think it needs more thought and feedback from people before it makes its
>> way into ‘master’; it also seems to lack documentation.
>
> Agreed.  There are a few (very few) exceptions, but in general each
> command needs (1) a section in the manual and (2) unit tests and/or
> integration tests in a shell script.
>
> Could you submit patches for that?

Sure!  :-)

> IWBN if others could do an after-the-fact review of the code, too.

Agreed.  I quickly skimmed through (gnu home-services xdg), and I can
already see some things that can be improved.  :-)

>> I just realized that it generates the following service declaration
>>
>> (service
>>  home-bash-service-type
>>  (home-bash-configuration
>>   (bashrc
>>(list (slurp-file-gexp
>>   (local-file "/home/yoctocell/.bashrc"))
>>
>> but when running ‘guix home reconfigure’, the ~/.bashrc file will be
>> moved, so when running ‘guix home reconfigure’ for the second time, it
>> would read the ~/.bashrc which is itself a symlink to a file the store.
>> ‘guix home import’ clearly isn’t in a usable state as of right now…
>
> Also, I argued earlier against ‘slurp-file-gexp’:
>
>   https://lists.gnu.org/archive/html/guix-devel/2021-06/msg00192.html
>
> I haven’t checked the different service configuration APIs, but I think
> we should avoid uses of ‘slurp-file-gexp’ entirely and instead do the
> same as in the majority of Guix System services, which is to accept
> file-like objects.
>
> Thoughts?  Could you take a look?

Yeah, I never really liked ‘slurp-file-gexp’; using ‘local-file’ &
co. would be better and more consistent.


signature.asc
Description: PGP signature

Re: On the naming of System and Home services modules.

[Xinglu Chen]

On Tue, Sep 28 2021, Ludovic Courtès wrote:

> Hi,
>
> (+ Cc: Oleg.)
>
> Andrew Tropin  skribis:
>
>> For now my personal ranking of the ideas is following:
>>
>> 1. Move to (gnu services ...) :: can(?) provide some additional reusability.
>> 2. Keep as it is right now (gnu home-services ...) :: already works.
>> 3. Move to (gnu home services ...) :: good stylistic change, but breaks
>> backward compatibility.
>
> As I stated in another message, backward compatibility is not a concern
> here from the Guix POV (of course it’s a concern for those who were
> already using pre-merge Guix Home, but for Guix all these APIs are new.)
>
> (As an aside, part of the reason I asked a few days ago to have more
> time for review was precisely so we could refine the APIs before it goes
> public.)
>
> I would very much like to have these modules renamed to (gnu home
> services …) quickly.  WDYT?  Could the two of you take a look?

I think it would be better to put home services in the same modules as
system services, i.e., (gnu services mcron) would contain the Mcron
service for Guix System and the Mcron service for Guix Home.  That would
also mean that we wouldn’t have to export ‘job-files’ and
‘shepherd-schedule-action’[1].

I think using (gnu home services …) would only make sense if we already
had (gnu system services …).

WDYT?

[1]: 


signature.asc
Description: PGP signature

bug#50346: [PATCH core-updates-frozen] gnu: strace: Allow readlink, readlinkat tests to pass.

[Simon South]

Could this patch be reviewed please?  It's needed to build strace from
core-updates-frozen on AArch64 and it would be good to get it applied
ahead of the merge.

It wasn't sent out to guix-patches and I think it got missed.

http://issues.guix.gnu.org/50346#7

-- 
Simon South
si...@simonsouth.net

Re: Go importer and packages with version flags

[Katherine Cox-Buday]

Sarah Morgensen  writes:

> Hi Katherine, Jack,
>
> Katherine Cox-Buday  writes:
>
>> Jack Hill  writes:
>>
>>> Hi Guix,
>>
>> Hey, Jack, a few thoughts.
>>
>>> While I was was working with the go importer today, it suggested I package
>>> go-github-com-russross-blackfriday-v2. Fair enough, except we already have a
>>> package for go-github-com-russross-blackfriday.
>>
>> I was poking around a rust code-base the other day and I noticed our crate
>> importer, and thus a lot of crate packages, have major-version suffixes. I
>> think one of the unique benefits of Guix is that it can simultaneously have
>> multiple versions of libraries installed, and I think we should allow this
>> for library packages.
>>
>> I know that leads to dependency graph explosion, but perhaps we only commit
>> to substitutes for the latest version, and thus any packages using old
>> versions. It should converge over time unless packages go unmaintained.
>>
>> I thought our current stance was to only allow one version at a time, but
>> the crate packages made me question this. I'd like clarity too.
>
> I think there's a bit of a difference between (our packages for) the Rust and
> Go ecosystems here.
>
> In the Go ecosystem, a module is uniquely identified by its module path,
> e.g. "github.com/russross/blackfriday/v2".  According to Go's major version
> suffix rules [0], "[s]tarting with major version 2, module paths must have a
> major version suffix like /v2 that matches the major version."  Therefore,
> each major version is logically a different module according to Go, and so I
> think we should treat them as separate packages as well.  (Note that in many
> cases we can use 'inherit' for brevity.)

That's a great point! I hadn't considered that we could leverage this to 
consider major versioned Go modules as separate packages. That's great!

> Additionally, the major version suffix rules dictate that "[i]f an old package
> and a new package have the same import path, the new package must be backwards
> compatible with the old package."  Assuming upstream sources follow the rules,
> we should be able to update each Go package within each major version without
> breaking dependencies.
>
> (A corollary to that is that packages often break if you try to use a v2 when
> it is expecting a v1.)
>
> I think this differs from Rust, where we have, for example, package-0.1 and
> package-0.2 coexisting.  This difference should prevent dependency graph
> explosion for Go.

It's nice that our Rust packages are enjoying the same stance, but I'm still 
not clear on why? Does Rust have the same guarantees?

> There are some caveats with "major version suffixes":
>
> * Major versions 0 and 1 don't get a version suffix (so no /v1)...
>
> * ...except for module paths starting with "gopkg.in/", which always have
>   a major version suffix, but theirs is styled ".v1" rather than "/v1".
>
> * Modules may either be located in the repository root, or in a "/v2"
>   subdirectory (for major version 2).  This makes things difficult for our
>   importer, because we can't know whether the unpack path should include "/v2"
>   without looking at the repository contents.
>
> This is why Jack had to manually add "/v2" to the unpack path.  I recently
> made some changes to the importer to better handle, for example,
> "github.com/example/repository/subproject", but it doesn't yet discriminate
> between "/subproject" and "/v2", so it treated "/v2" like a subdirectory of
> the repository.  (Until we fix this properly, the importer should probably not
> count major version suffixes when calculating the unpack path, since most
> projects don't use a "/v2" subdirectory.)

As an aside, when I started writing the importer, I didn't know it was a 
possibility to just use the Go toolchain to help us generate packages. I 
thought "the Guix way" was to do it all in scheme. It's nice that it's in 
scheme, but I would love to leverage the Go toolchain instead.

IMO, module resolution and graph dependencies in Go are complicated enough that 
I'd much rather take the effort we put in trying to replicate and keep up with 
the Go toolchain's behavior, and spend that effort elsewhere.

Does anyone have opinions on this?

> All that to say... I think we should definitely maintain coexisting Go v2, v3,
> etc. package definitions.  We should probably go the way of Rust though, so we
> have them all in the same package, at different versions:
>
> (define-public go-github-com-russross-blackfriday-v2
>   (package
> (name "go-github-com-russross-blackfriday")
> (version "2.1.0")
>
> instead of as different packages:
>
> (define-public "go-github-com-russross-blackfriday-v2"
>   (package
> (name "go-github-com-russross-blackfriday-v2")
> (version "2.1.0")
>
> And of course, it should be policy to remove dependency packages with no
> dependents.  (Perhaps we could write a new linter to warn if a "go-" package
> has no inheriters and no dependents?)

I disagree with

Re: Linux-libre source code will be taken offline

[zimoun]

Hi,

On Tue, 28 Sept 2021 at 16:32, Jason Self  wrote:
>
> Granted that old/gen7 is not currently a valid URL but we can know
> that, 5 or 10 years from now, when Linux-libre has moved on to the 8th,
> 9th or even 10th generation, the 7th generation scripts will exist
> there. If Guix can begin checking those additional locations now then,
> in the future once the current Guix version becomes an old version,
> hopefully it can transparently handle that transition without issue. Or
> just use git. :)

I am not familiar with the Linux Libre scripts.  Are these scripts
already under a Git repo?

The method you are proposing seems awkward; as you say, old/gen7 is
not currently a valid URL.  And you are proposing that you set in
stone now this URL expecting that maybe it will be valid in the
future.  Ah future cannot be predicted. ;-)  Who knows that this old/
folder will not be renamed as 'not-fully-free' or whatever.

Working with URL limits the time-travel because it is a really poor
mechanism (and not robust at all) for content-address something, IMHO.

Well, maybe I miss a point or something.

Cheers,
simon

Re: Linux-libre source code will be taken offline

[Jason Self]

On Tue, 28 Sep 2021 19:11:58 +0200
zimoun  wrote:

> The method you are proposing seems awkward; as you say, old/gen7 is
> not currently a valid URL.  And you are proposing that you set in
> stone now this URL expecting that maybe it will be valid in the
> future.  Ah future cannot be predicted. ;-) 

On the contrary: The file versioning and locations are 100% knowable
and predictable in advance. This has been the point I've been trying to
get across this entire time.

> I am not familiar with the Linux Libre scripts.  Are these scripts
> already under a Git repo?

Yes, git://linux-libre.fsfla.org/releases.git which carries tagged
releases, scripts, and logs. As you can see it goes all the way back to
2.6.21.

The primary motivation for the creation of this git repository was
actually for Guix, as a solution to the feedback from the tarballs
being removed due to the lack of disk space, but it appears that it is
not being used.


pgpS_jzKZewEi.pgp
Description: OpenPGP digital signature

Re: core-updates-frozen: Planning for the last world rebuild

[John Kehayias]

Hi Ludo’ and Guixers,

Thanks for the good progress on core-updates-frozen (where I'm currently 
writing from and have nearly everything working as before). Seems like we have 
a few different bug numbers and threads for the world rebuild. Sorry for 
repeating from #50860, which I will paste below.

In summary, I also noticed an older bug for Flatpak with p11-kit, as well as 
p11-kit being out of date. Locally I've tested it builds with the patch and 
version update and fixes the bug. The configuration change is the same as nix 
does for p11-kit for the same reason, for what that is worth.

Less critical is Mesa continuing to put out updates, both on 21.1 and now 
moving to 21.2 (considered stable I believe). I thought we might sneak that in 
if we're doing lots of rebuilding.

Thanks! Original message with more details below:

Is there anything else with huge rebuilds to push together? I don't want to 
keep finding and adding things, but two possibilities come to mind that I've 
just noticed:

1a. p11-kit #49957 https://issues.guix.gnu.org/49957

I've just hit this bug on core-updates-frozen as well, though was originally 
reported on master. As I noted there, I tried to test with just grafts but 
didn't fix it for me (I'm guessing grafting won't work with that configure flag 
change). The patch matches how nix configures p11-kit as well, due to this bug.

1b. p11-kit is also now out of date. The changelog doesn't look substantial or 
serious, but given the nature of p11-kit I wonder if we want to update it now 
too. https://github.com/p11-glue/p11-kit/releases/tag/0.24.0

2. (minor) Mesa has had a few more bugfix and major releases since my initial 
patch for core-updates-frozen. Now at 21.1.8 for the 21.1 branch (we have 
21.1.6 currently), but 21.2 has also had stable releases, with 21.2.2. I 
previously built 21.2.1 and sent a patch for it, and could test 21.2.2 if we 
want to do that too.

I'm aware this could continue forever, and #2 is likely lower priority. #1, 
though, should we consider p11-kit a critical update (version, at least) since 
we're still fixing core-updates-frozen?

John

Re: On the naming of System and Home services modules.

[Oleg Pykhalov]

Andrew Tropin  writes:

[…]

>> I would very much like to have these modules renamed to (gnu home
>> services …) quickly.  WDYT?  Could the two of you take a look?
>
> Doable.
>
> What about moving home services to (gnu services ...)?
>
> It's a little harder, because we probably will need to adjust `guix
> system search` and `guix home search`, but other than that seems not too
> hard.
>
> However, I'm quite ok with (gnu home services ...), just asking to avoid
> one more migration later.

I'm OK with both variants, but (gnu services) seems more friendly for
sharing the code and as (gnu home services) doesn't look hard to migrate
with current amount of services in (gnu home-services).

> Let me know, which option seems better to you, I can take this task
> tomorrow.

I could try to join the migration on friday, or weekends.  Fill free to
delegate (gnu home-services XYZ) module migration to me here, or IRC.

Oleg.


signature.asc
Description: PGP signature

Re: eudev deprecation

[Julien Lepiller]

Le 28 septembre 2021 08:00:02 GMT-04:00, "Ludovic Courtès"  a 
écrit :
>Hi,
>
>Lars-Dominik Braun  skribis:
>
>> it looks like eudev, which we heavily rely on, is dead upstream:
>> https://github.com/gentoo/eudev/issues/199
>>
>> Looking at Gentoo’s ebuilds it should be possible to “extract”
>> and build udev from systemd’s sources.
>
>Good.  That’s essentially what eudev is.
>
>Tobias Geerinckx-Rice  skribis:
>
>> Further update:
>>
>>> ADOPTION NOTICE (2021-09-14)
>>> Currently eudev is in the process of being adopted by a newly
>>> formed project by Alpine, Devuan and Gentoo contributors [...]
>>
>> -- https://github.com/eudev-project/eudev
>>
>> We'll see?  Talk and Git repos are cheap; actually putting in this
>> work is not.
>
>Interesting.
>
>Julien mentioned on IRC that Linux From Scratch is also considering
>switching.  Julien, what’s the takeaway from the LFS discussions so far?
>
>Thanks,
>Ludo’.

My understandeng is that LFS will use udev, directly extracted fsom systemd's 
sources, in its sysvinit version. See 
https://wiki.linuxfromscratch.org/lfs/ticket/4914 for reference.