Re: Google Summer of Code Inquiry

[Efraim Flashner]

On Tue, Apr 09, 2024 at 05:25:35PM +0200, Ludovic Courtès wrote:
> Hi Sebastian,
> 
> Sebastian Dümcke  skribis:
> 
> > just wanted to chime in. Since last week I have some working code to
> > generate AppImages with guix pack. I was planning on tidying this up
> > for submission over the next weeks.
> > There is still work to do regarding documentation, adding options
> > specific to the AppImage format, building the AppImageKit runtime from
> > source and a lot of testing.
> 
> This is great news!  Looking forward to incorporating those changes.
> 
> > However, I believe that the remaining effort is around 8-10 hours. I
> > am happy to hand the code over to you to finish up and co-mentor
> > (though this patch would be my first contribution to guix) if you
> > think this is appropriate.
> 
> It does sound like it jeopardizes this specific project.  In a way,
> that’s a good problem to have as a project, but it does mean that
> Zachary would need to look for another project (which could still be
> related to ‘guix pack’).
> 
> Thoughts?

There's always the option of trying to create flatpaks using Guix.


-- 
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: [fr] Moment de convivialité Guix@Paris en avril

[Tanguy LE CARROUR]

(Warning: this email is in french because the meeting is supposed
to be held in French.)

Bonjour Guix,

Pour rappel, Guix@Paris c'est demain soir ! 😎
C'est toujours à 19h au local de l'April… ou chez Easter-eggs. Et pour
celles et ceux qui ne veulent pas braver la circulation parisienne,
c’est en direct *live* sur .

Au plaisir de vous y rencontrer,

-- 
Tanguy

Clojure is working on better supporting XDG base directory rules

[Jesús Gómez]

Hello.

I just wanted to mention that the Clojure project had recently
accepted to work on enhancing its support to XDG base directory rules,
as described in their ticket TDEPS-262[1]

I'm sure there are important considerations related to your work. For
example, how would an eventual change affect Debian users when
upgrading the Clojure package?

Anyway, I'm going to work the best I can on this issue, and I'm
opening this thread simply as a "heads-up" and a place to discuss it.

Thank you for your work and contribution to Guix and Clojure!

[1] https://clojure.atlassian.net/browse/TDEPS-262

Re: March update on bordeaux.guix.gnu.org

[Ludovic Courtès]

Hello,

Christopher Baines  skribis:

> The max-age of that narinfo is currently based on the scheduled removal
> of the zstd compressed nar, which is going to happen quite far in the
> future.
>
> I did think of a number of ways to approach this, and I'm not sure I've
> settled on the right one yet. Maybe the TTL should be capped at 600, and
> then drop to 0 as the time to remove the zstd nar approaches?

Not sure what you mean by removal.  To me, it’s the other way around:
when the server advertises a TTL, it must guarantee that the associated
nars remain available until that TTL has expired.  (It can also keep it
longer.)

The way ‘guix publish’ honors that commitment is by keeping track of the
last time each narinfo was published and protecting the narinfo and nars
from deletion until the TTL has expired.

>> But then again, that’s the advertised TTL; the real TTL is still
>> infinite, right?
>
> As you probably know, the situation is more complex.
>
> The problems caused when the nar-herder started removing zstd compressed
> nars shows the difference between retention of the nar in some form, and
> whether a cached narinfo response can be considered fresh or stale.
>
> Users might also not notice the availability of zstd nars if they cache
> responses forever, since currently there will be a lag between the nar
> becoming available, and a zstd compression being created (although we
> could generate zstd compressed nars for everything).

I think we should arrange to never advertise nars that are not actually
available, if that’s what you meant.

>> It’s a cache.  It’s useful to have this cache because in “typical” Guix
>> usage you’re likely to ask repeatedly for the same substitutes.
>>
>> Regarding the cost, 3f5e14182931f123c10513a3e1e2abaebfb52279 made things
>> more reasonable by putting a higher bound on narinfo retention.  On my
>> laptop, I have:
>>
>> $ ls -lrt 
>> /var/guix/substitute/cache/4refhwxbjmeua2kwg2nmzhv4dg4d3dorpjefq7kiciw2pfhaf26a/
>>  |wc -l
>> 11549
>> $ du -h 
>> /var/guix/substitute/cache/4refhwxbjmeua2kwg2nmzhv4dg4d3dorpjefq7kiciw2pfhaf26a/
>>  
>> 50M 
>> /var/guix/substitute/cache/4refhwxbjmeua2kwg2nmzhv4dg4d3dorpjefq7kiciw2pfhaf26a/
>>
>> Maybe that’s still excessive and we could further reduce the maximum
>> caching time.
>
> Having played around with this a bit (e.g. hacking guix weather not to
> cache), I'm a bit sceptical. Given maintaining the cache takes time that
> could be spent doing network I/O, and does potentially slow disk I/O, I
> think it would be interesting to try and work out in what situations the
> cache speeds things up overall, and in what situations it slows things
> down overall..

Yes, we can surely fine-tune that to make sure it remains beneficial.

>>> 6: https://lists.gnu.org/archive/html/guix-devel/2023-05/msg00290.html
>>
>> BTW, should we document this mirror somewhere (and also ensure that Guix
>> Foundation pays the bills), or do you view it more as an experiment for
>> now?
>
> If the project does want to provide mirrors, I think that would be
> great. From this experiment, I think we have some evidence that there
> are people using Guix outside of Europe, and in some cases they struggle
> with the European based infrastructure. It also seems like these mirrors
> do help, and the monetary cost isn't too high in my view.
>
> I think we should probably wait until the project starts managing them
> before documenting/advertising them more widely though.

*We* are “the project”.  :-)

By that I mean that we should discuss it with people at the Guix
Foundation and with the broader community, but it seems pretty clear to
me that there’s interest in having mirrors up and running, especially
outside Europe.  Then of course we need to be able to scale it according
to available funds, but at least the goal itself is clear.

[...]

>> Do you think the Data Service or another source of info would let us
>> make such decisions?
>>
>> If we take it to the extreme, we could have a sophisticated retention
>> policy like: drop all fixed-output derivations known to be available
>> from disarchive.guix + SWH, drop substitutes for packages that have less
>> than 100 dependents, etc.
>
> I think the Data Service (specifically data.guix.gnu.org) might be
> really helpful here, as it speeds up being able to work out what a nar
> or derivation relates to.
>
> Additionally, the nar-herder can tag narinfos (associate key=value pairs
> with them), and that's intended to help you manage the nars. So we
> should probably start tagging the nars with potentially useful
> information now, so that we can use that data later to make desicions.

Really good.

> We're storing 17.5TiB of nars currently, and this increases linearly, so
> it would be good to understand how this can be broken down. The
> nar-herder should help here as well, as providing you can download the
> 11G database, that should contain all the information you need to start
> digging in to this.
>
>   w

Re: Google Summer of Code Inquiry

[Ludovic Courtès]

Hi Sebastian,

Sebastian Dümcke  skribis:

> just wanted to chime in. Since last week I have some working code to
> generate AppImages with guix pack. I was planning on tidying this up
> for submission over the next weeks.
> There is still work to do regarding documentation, adding options
> specific to the AppImage format, building the AppImageKit runtime from
> source and a lot of testing.

This is great news!  Looking forward to incorporating those changes.

> However, I believe that the remaining effort is around 8-10 hours. I
> am happy to hand the code over to you to finish up and co-mentor
> (though this patch would be my first contribution to guix) if you
> think this is appropriate.

It does sound like it jeopardizes this specific project.  In a way,
that’s a good problem to have as a project, but it does mean that
Zachary would need to look for another project (which could still be
related to ‘guix pack’).

Thoughts?

> PS: this is also my first message sent to a mailing list, hope it
> makes it through ok. Please point out any errors or breackes in
> netiquette

It’s perfect!

Thanks,
Ludo’.

Re: [python-team] Weird python-notebook test failures

[Ricardo Wurmus]

[resending as a wide reply, sorry]

Felix Lechner  writes:

> Hi Ricardo,
>
> On Sat, Apr 06 2024, Ricardo Wurmus wrote:
>
>> Any ideas what might be going on here?
>
> Could it be "ModuleNotFoundError: No module named 'jupyter_server'"?

I don't think so.  There is no jupyter_server module in the build
environment on the master branch either.

-- 
Ricardo

Re: The `channels' field of `operating-system' record

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

Hi Nathan,

On Mon, Apr 08 2024, Nathan Dehnel wrote:

> I don't think you're supposed to edit /etc/guix/channels.scm directly,
> I think it's generated by guix system reconfigure.

As Ludo' pointed out on Mastodon recently [1] the system channels can
also be customized, if needed. [2]

Kind regards
Felix

[1] https://toot.aquilenet.fr/@civodul/112235132695871431
[2] 
https://guix.gnu.org/manual/devel/en/html_node/Customizing-the-System_002dWide-Guix.html

Re: The `channels' field of `operating-system' record

[Tomas Volf]

On 2024-04-08 23:06:00 -0500, Nathan Dehnel wrote:
> I don't think you're supposed to edit /etc/guix/channels.scm directly,

Is this documented anywhere?  I used the code for over a year and it worked just
fine.  I cannot find any instruction to not touch it anywhere in the info
manual.

> I think it's generated by guix system reconfigure.
> https://gitlab.com/nonguix/nonguix/-/issues/33
> I have ~/.config/guix/channels.scm generated by putting
> home-channels-service-type in my guix home config.

--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.


signature.asc
Description: PGP signature

Re: The `channels' field of `operating-system' record

[Tomas Volf]

On 2024-04-09 06:16:12 +0200, Marek Paśnikowski wrote:
> 09.04.2024 06:06:00 CEST Nathan Dehnel:
> > I don't think you're supposed to edit /etc/guix/channels.scm directly,
> > I think it's generated by guix system reconfigure.
> > https://gitlab.com/nonguix/nonguix/-/issues/33
> > I have ~/.config/guix/channels.scm generated by putting
> > home-channels-service-type in my guix home config.
>
> Now that you mentioned it — is this not root user’s channel list, and
> one is not supposed to use guix as root?

Not really, it is a system-wide channel list.  Root's channel list would be
/root/.config/guix/channels.scm.

>
> I use home-channels-service-type and the only issue with this solution
> is that it requires a 'guix home reconfigure' before the new channels
> can be used in 'guix pull'.  Though one could also use the -C flag to
> a channels.scm file including the list of channels.

The /etc/... one has advantage of applying to all users.  Which is nice.

Have a nice day,
Tomas Volf

--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.


signature.asc
Description: PGP signature

Re: The `channels' field of `operating-system' record

[Marek Paśnikowski]

09.04.2024 06:06:00 CEST Nathan Dehnel:
> I don't think you're supposed to edit /etc/guix/channels.scm directly,
> I think it's generated by guix system reconfigure.
> https://gitlab.com/nonguix/nonguix/-/issues/33
> I have ~/.config/guix/channels.scm generated by putting
> home-channels-service-type in my guix home config.

Now that you mentioned it — is this not root user’s channel list, and
one is not supposed to use guix as root?

I use home-channels-service-type and the only issue with this solution
is that it requires a 'guix home reconfigure' before the new channels
can be used in 'guix pull'.  Though one could also use the -C flag to
a channels.scm file including the list of channels.

signature.asc
Description: This is a digitally signed message part.

A paper about Plan 9 and Guix

[Nathan Dehnel]

Wow, that's incredible.

>Port number themselves stem from TCP emerging from earlier protocols (see the 
>early RFCs 322, 349, 433 and those that obsolete them), and a clean design 
>would probably elect to eschew them, leveraging a \(2^{128}\) address space to 
>allow process-to-process communication, instead of the route-to-host, then 
>route-to-process dance we do know.
>
>The host to process frontier should be an implementation detail on the 
>receiving end, not baked so deeply in the stack.
>This barrier may even change from request to request as new hosts come up or 
>down depending on load.
>This already happens anyway with e.g. kubernetes, but we would have less cruft 
>if it was baked into the protocol.

That sounds like some of the problems RINA was trying to solve.
https://en.wikipedia.org/wiki/Recursive_Internetwork_Architecture