Re: Guix Package Search API Server

[Tissevert]

I see. Thank you very much for this piece of information ! And I'm
relieved to know everything is fine with the UMC Utrecht instance.

Le Fri, 7 Jan 2022 00:13:40 +0530,
Sai Karthik  a écrit :

> You could also obtain the json file from
> https://guix.gnu.org/packages.json
> 
> On 05/01/22 13:08, Tissevert wrote:
> > Hi,
> > 
> > This JSON file sounds nice and useful. By the way, it may only be a
> > transient error but the instance of hpcguix-web running at UMC
> > Utrecht mentioned in the github repos seems to be down
> > (https://hpcguix.op.umcutrecht.nl/). Is it supposed to be so ?
> > 
> > Tissevert
> > 
> > Le Mon, 03 Jan 2022 17:27:56 +0100,
> > Ludovic Courtès  a écrit :
> >   
> >> Hi!
> >>
> >> Sai Karthik  skribis:
> >>  
> >>> Nice! I didn't knew about this earlier. Does hpc.guix.info exposes
> >>> API ?  
> >>
> >> It runs hpcguix-web¹, which exposes a big (but gzipped) JSON file
> >> at .  Everything else happens
> >> in client-side JavaScript code.
> >>
> >> Ludo’.
> >>
> >> ¹ https://github.com/UMCUGenetics/hpcguix-web
> >>  
> >   
> 

Re: Bug tracker spam

[Ricardo Wurmus]

Tobias Geerinckx-Rice  writes:

> I've asked the debbugs crew over e-mail how to deal with [0], assuming
> there's a way to close bugs without pinging a malicious sender.

FYI: I adjusted the way we sync debbugs data (added a “--delete”) so now
that spam bug is also gone from issues.guix.gnu.org.

-- 
Ricardo

Re: GNU Guix maintainer rotation

[Jérémy Korwin-Zmijowski]

Welcome Efraim ! Best wishes for the duty.

Thank you Ludo' and Marius ! Enjoy the free time

Really hope I will still be able to trade a 'hi' in the IRC on my rare 
connections. haha


Jérémy



OpenPGP_0x700F5E0CCBB2E2D1.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

GNU Guix maintainer rotation

[Maxim Cournoyer]

Hello Guix!

I'd like to bring your attention to a change to the current Guix
maintainers collective; in a nutshell, Ludovic and Marius are stepping
down from maintainer-ship while Efraim is joining.

I won't write more as you can find all the details in this blog post:
https://guix.gnu.org/en/blog/2022/gnu-guix-maintainer-rotation/.

Many thanks to Ludovic and Marius for their past roles as Guix
co-maintainers, and a warm welcome to Efraim!

Happy hacking!

Maxim

Re: Organising Guix Days

[zimoun]

Hi Julien,

On Sat, 11 Dec 2021 at 02:37, Julien Lepiller  wrote:

> I suggest that we have these days right after Fosdem, Monday and
> Tuesday. This should give us just a few more days to prepare, as I think
> we're starting pretty late already. If you prefer to have them before
> fosdem, I can change the blog post of course.

What is the final decision?  No strong opinion on the date, so let pick
the ones your proposed.  How does it sound?


> Also, we need to secure a BBB instance :)

Well, I think we will find one.  Fosshost is not an option though.


Cheers,
simon

Bug tracker spam

[Tobias Geerinckx-Rice]

All,

I've asked the debbugs crew over e-mail how to deal with [0], 
assuming there's a way to close bugs without pinging a malicious 
sender.


Please, nobody respond to or modify it in the mean time.

I'll follow up with a question on how we're supposed to moderate 
bugs if the tracker & archive sit *in front of* the moderation 
queue…


It's frankly a miracle that this doesn't happen constantly.

Kind regards,

T G-R

[0]: https://issues.guix.gnu.org/53051


signature.asc
Description: PGP signature

Re: Guix Package Search API Server

[Sai Karthik]

You could also obtain the json file from https://guix.gnu.org/packages.json

On 05/01/22 13:08, Tissevert wrote:

Hi,

This JSON file sounds nice and useful. By the way, it may only be a
transient error but the instance of hpcguix-web running at UMC Utrecht
mentioned in the github repos seems to be down
(https://hpcguix.op.umcutrecht.nl/). Is it supposed to be so ?

Tissevert

Le Mon, 03 Jan 2022 17:27:56 +0100,
Ludovic Courtès  a écrit :


Hi!

Sai Karthik  skribis:


Nice! I didn't knew about this earlier. Does hpc.guix.info exposes
API ?


It runs hpcguix-web¹, which exposes a big (but gzipped) JSON file at
.  Everything else happens in
client-side JavaScript code.

Ludo’.

¹ https://github.com/UMCUGenetics/hpcguix-web





--
https://kskarthik.gitlab.io/


OpenPGP_0xF5B9A961BF6EAF0E.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Guix "R" Us - GNU's joy store!

[jgart]

On Thu, 06 Jan 2022 09:44:27 -0600 Katherine Cox-Buday 
 wrote:
Hi Katherine,

> I hope we can take the reasons people make these channels and bring
> them back to Guix proper to make contributing here just as easy.

Contributing to Guix upstream is definitely high priority for the guixrus
channel and the whereiseverone community.

For example, as a small community we are planning to organize a monthly
channel cleanup day in which we look at all the packages in guixrus and
determine which packages should be sent upstream and which packages still
need more work. This style of iteration can serve as an additional and
more intimate layer of onboarding for newer users because we review
patches on https://lists.sr.ht/~whereiseveryone/guixrus as well as
discuss package issues on #whereiseveryone (libera.chat) in a short
feedback loop. In the process of doing the above we also explain the
upstream contribution process to newcomers. My hope is that higher-quality
packages by first-time Guixers will become more commonplace in upstream
issue trackers.

We are also experimenting with using builds.sr.ht to run the guix lint
checker, and more when submitting patches to guixrus/upstream thanks
to dhruvin:

https://builds.sr.ht/~dhruvin/job/665098
https://builds.sr.ht/~dhruvin/job/665205

We are developing a package search[1] in the context of the guixrus
channel web site:

https://paste.sr.ht/~dhruvin/0828f7b1df2ffa7b7b31c50e07ef043d94caeea0

guixrus had 83 packages that day. If interested in the library that was
used to generate the json paste output see this repo:

https://git.sr.ht/~dhruvin/doug

A top priority goal of the whereiseveryone community is to encourage
new Guixers to contribute to Guix (upstream as well as whereiseveryone
community projects). We want to facilitate, develop, and discuss that
process, as well as experiment with fun ideas and tools for Guix. It's
ambitious, I know. We'll take it one S-expression at a time.

happy hacking,

https://sr.ht/~whereiseveryone/

Re: Guix Documentation Meetup

[Katherine Cox-Buday]

adriano  writes:

> Il giorno dom, 12/12/2021 alle 21.50 -0600, Katherine Cox-Buday ha scritto:

>> - In geiser, run =,a thing-i-want-to-look-for= (this is supposedly an
>> apropos command that is supposed to search symbols for you). The command
>> returns nothing.

> about this, I want to report an example
>
> scheme@(guile-user)> (help tail)
> Did not find any object named `tail'
> scheme@(guile-user)> 
>
> BUT
>
> scheme@(guile-user)> (help "tail") <-- notice the quotation marks !
> Documentation found for:

> That is, help with the quotation marks reports about things even if
> they're in namespaces you haven't imported yet !

Thank you very much for the tip! I will definitely be trying this next time I'm 
hacking on Guile!

-- 
Katherine

Re: Guix "R" Us - GNU's joy store!

[Katherine Cox-Buday]

jgart  writes:

> On Wed, 29 Dec 2021 00:27:04 +0100 raingloom  wrote:
>> TLDR how much of the effort spent on this channel is really justified
>> compared to making the underserved use-cases easier in upstream Guix?

I also have my own personal "upstream staging" channel so that I can continue 
contributing to Guix at my own pace, in my own way, until I can get enough 
velocity to really internalize contributing in the way Guix would like me to. I 
also tend to hack on things there, and then batch my changes for upstream so 
that I can keep everything consistent and make sure all my code meets upstream 
standards. In the meantime, I'm able to actually use the code.

My only concern with organizing this activity into a group is that it is a kind 
of "community fork". I hope we can take the reasons people make these channels 
and bring them back to Guix proper to make contributing here just as easy.

At any rate, any energy put into the ecosystem is good in my book. Cheers! :)

--
Katherine

Re: Release v1.4 (or 2.0): process and schedule ?

[Maxim Cournoyer]

Hello Chris,

Chris Marusich  writes:

> Maxim Cournoyer  writes:
>
>> About the current status, I'm nearing on pushing a version-1.4.0 branch
>> which is based on master with a few more (core-ish) updates.  There's
>> still a few days ahead of that, so if you manage to get many of this
>> kind of problems fixed & merged in master they can easily be included in
>> the next release.
>
> There is a problem that currently prevents "guix pull" from succeeding
> for powerpc64le-linux on master.  I'd like to resolve it before the
> release if possible.  The problem is here, including a patch to fix it:
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=52940
>
> This patch is relatively simple, but it will rebuild many packages for
> all architectures because it modifies guix/build/gremlin.scm, which is
> used by the gnu-build-system.  How can I integrate this change into the
> 1.4.0 release?
>
> Normally I would commit such a change to core-updates.  However, if I do
> that, then the change probably won't make it into master or the
> version-1.4.0 branch in time.  Is there an opportunity to put the change
> somewhere so that it will make it into the release?  I'm not sure.
>
> Here's my proposal.  Since the bug may very well be benign, I could
> apply a simple work-around to master that just skips the failing test on
> powerpc64le-linux.  I could then apply the actual fix to core-updates.
> Later, after master has been merged to core-updates, I could re-enable
> the test on core-updates.  This would allow "guix pull" to succeed for
> powerpc64le-linux on master without rebuilding the world, and the
> correct fix would still be applied on core-updates for a later release.
>
> Do you think that would work?

Since the version-1.4.0 branch I've been polishing locally still hasn't
been published nor built, there's still time to apply the patch without
any consideration for world rebuilds to that branch (at this point we
want the changes to be low risk ones though, but that sounds like one).

Thanks,

Maxim

Re: Mid-December update on bordeaux.guix.gnu.org

[Christopher Baines]

Ludovic Courtès  writes:

>> However, due to the time spent not building things, the backlog is
>> longer than usual, and the substitute availability (especially for
>> x86_64-linux and i686-linux) is lower than usual.
>
> Yeah, ‘guix weather coreutils’ finds nothing on bordeaux.guix right now.

I've been so slow in replying to this email that the situation has
actually improved now, substitute availability for x86_64-linux is
around ~70% and still slowly rising.

>> ** Space issues and the nar-herder
>>
>> bordeaux.guix.gnu.org wasn't building things for 2 weeks as the space on
>> bayfront was getting a little scarce. This week I started rolling out
>> the nar-herder [2], a utility I've been thinking about for a while. This
>> has enabled moving nars off of bayfront on to another machine which I've
>> confusingly named lakefront.
>
> Woow, neat!
>
> Regarding nar-herder, I think it’d be nice to have a solution to
> mirroring in Guix proper, developed similarly to other components,
> because it could be a fairly central tool.
>
> ‘guix publish’ is probably not extensible enough to support that, but we
> could make it a new ‘guix mirror’ or ‘guix sync’ or whatever command.

I think having something in Guix would be good too.

I still view the nar-herder as a bit wierd in terms of the collection of
concerns, mixing mirroring in with moving nars around between machines
and I'm hoping to add some metrics functionality soon as well.

>> The lakefront machine is hosted by Hetzner in Germany, and has 6TB of
>> storage across 2 hard drives. When a nar is requested from bayfront, it
>> will check it's local storage, and serve it from there if it exists,
>> otherwise it will forward the request to lakefront. There might be a
>> slight drop in the speed you can download nars, but apart from that this
>> change shouldn't be visible.
>
> Excellent, thanks for acting this promptly as problems crop up!
>
> I think we should make sure this is funded by the project and that
> credentials are shared.  As discussed before, I think it’s best to keep
> things tidy in that respect, in the spirit of building and maintaining
> this collectively.

That would be good, I can start a thread on guix-sysadmin about this.

>> Going forward, it would be good to have an additional full backup of the
>> nars that bayfront can serve things from, to provide more
>> redundancy. I'm hoping the nar-herder will also enable setting up
>> geographically distributed mirrors, which will hopefully improve
>> redundancy further, and maybe performance of fetching nars too.
>>
>> Once I've had a chance to neaten up the code a little, I'll get a Guix
>> package and service written, plus I'll draft a Guix blog post about the
>> nar-herder.
>
> Usually I’m the one asking for blog posts :-), but I’d really like us as
> a project to collectively engage on the topic before we publicize this
> specific approach.

Sure, I also still need to post patches for the Guix service, which I'll
try to do soon.

>> That means there's the following currently running build agents (by
>> architecture):
>>
>>  - x86_64-linux + i686-linux (3 machines):
>>- 4 core Intel NUC (giedi)
>>- Max 16 cores for 1 concurrent build on bayfront
>>- 32 cores on milano-guix-1 (slow storage though)
>>  - aarch64-linux + armhf-linux (2 machines)
>>- 16 core HoneyComb LX2 (hatysa)
>>- 4 core Overdrive (monokuma)
>>  - powerpc64le-linux (1 machine)
>>- 64 core machine (polaris)
>
> This is looking pretty nice!  I’m also all for streamlining machine
> handling, both administratively (in maintenance.git) and financially.

I think there was some discussion previously about guix-europe buying
the HoneyComb board, which I can probably restart. It would be good to
also sort out better hosting for the powerpc64le-linux machine.

I'll try to put some time in to organising things in maintenance.git.

>> Ironically, I think that the most under-resourced area is x86_64-linux +
>> i686-linux. bayfront is restricted in what it can do since it also runs
>> the coordinator, and things go badly if the machine gets
>> overloaded. bayfront and milano-guix-1 both have hard drive storage,
>> which also can slow them down when building things (especially
>> milano-guix-1).
>>
>> If we (as a project) want bordeaux.guix.gnu.org to have the capacity to
>> keep up, it would be good to make a plan to add capacity. I think even a
>> single high core count x86_64-linux machine with performant storage
>> would make a big difference.
>
> Yes, we should do that, we still have funds for it.

Great :)

>> ** IPv6 not supported (yet)
>>
>> I was slow to notice, but bordeaux.guix.gnu.org isn't available over
>> IPv6 yet, since bayfront doesn't seem to have IPv6 connectivity. I want
>> to address this, but I haven't worked out quite how to yet.
>
> Should be almost done now, as discussed on IRC today.  \o/

Indeed, I think this is working now.

Thanks,

Chris


signature.asc
Description: PGP signature

Re: Replace current guix website package interface with hpcguix-web?

[Luis Felipe]

On Wednesday, January 5th, 2022 at 11:52 PM, kiasoc5--- via "Development of GNU 
Guix and the GNU System distribution."  wrote:

> Dear Guixers,
> 

> The hpcguix-web package interface (https://hpc.guix.info/browse) supports 
> package search, unlike the current one at https://guix.gnu.org/en/packages/. 
> Plus imo hpcguix-web looks nicer.
> 

> It would be a great UI/UX improvement if the current search was replaced with 
> hpcguix-web. Has this been considered before?

Yes. It just needs to be done :)

One thing that would have to be addressed, though, is that the package list 
view of hpcguix-web seems to work only for JavaScript-enabled browsers. So if 
you are browsing with, say, Lynx, you don't have a way to discover packages.

But I wonder if it is possible now to make the packages part use any of the 
Postgres databases that already exist and allow traditional search without 
JavaScript...

publickey - luis.felipe.la@protonmail.com - 0x12DE1598.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: On raw strings in commit field

[Liliana Marie Prikler]

Hi,

Am Donnerstag, dem 06.01.2022 um 05:38 -0500 schrieb Mark H Weaver:
> > From here on, I will assume that each individual push action is
> > finite as you did, but I don't think that using communications of
> > finite length are a helpful building block here.
> 
> Really?  You don't think communications of finite length are a
> helpful building block here?
> 
> Note that in the real world, every observable time interval is
> finite.
The reason I don't is because if we go all the way back to what we
actually want to do, we're invoking claims of an uncertain future.  At
the time of pushing a package description to guix.git, we already ran
whatever tests we had for the upstream and determined what we believe
to be a safe course of actions.  In theory, this belief could be
shattered mere seconds after.

> You referred to "Git" here.  That's why my proof was about Git.  You
> didn't say that you were talking about some theoretical variant of
> Git that supports "push actions" that literally *never* end, and that
> runs on a theoretical machine with infinite memory that can never be
> built.
Now to be sure, we're both talking about Git here, the porting to
Turing machines is only relevant because if we go that deep to Computer
Science basics, we might as well use them.
The scary parts of Git, that we use to make robustness claims are:
1. In the future, upstream might delete the repo.
2. In the future, upstream might update or delete a branch.
3. In the future, upstream might update or delete a tag.
4. In the future, upstream might update or delete a commit.
> 

> No, that's incorrect.  The set of lists of booleans is countable.
> Moreover, for any type T, if the set of objects of type T is
> countable, then the set of _lists_ of objects of type T is also
> countable.

> Note that lists are finite, by definition.
I'm pretty sure that there's bounded and unbounded lists, but perhaps I
am confusing the latter for infinite streams as you've pointed out.  

> If you intend to claim that by "push actions", you meant to include
> infinite streams of push actions: this has no relevance to the real
> world.
> 
> Even if we live in an open universe, the fact remains that at any
> arbitrary point in time, the age of any git repository is always
> finite.  Therefore, no one can ever observe the result of an
> infinite-length "push action" in the real world.  They can only ever
> observe the result of some finite prefix of that so-called "push
> action".
Even in a closed universe, we can only jump to arbitrary points in time
of which we've already collected a snapshots.  Statements regarding
anything else always carry uncertainty.

That's also a reason to bring Turing machines into this equation.  A
Turing machine would try to observe an infinite stream of push actions
if we program it that way.  This raises the Halting and Non-Halting
problems among others.

Cheers

Re: On raw strings in commit field

[Mark H Weaver]

Hi Liliana,

Liliana Marie Prikler  writes:
> it ought to have been comparatively easy to infer that I was talking
> about push actions (plural) as sequences, not as individual push
> actions like you've used for your proof.

It makes no difference, because the set of push actions is closed under
sequential composition.  Moreover, the argument in my proof applies to
*any* kind of action that can be communicated over a digital
communications channel in finite time.

> From here on, I will assume that each individual push action is finite
> as you did, but I don't think that using communications of finite
> length are a helpful building block here.

Really?  You don't think communications of finite length are a helpful
building block here?

Note that in the real world, every observable time interval is finite.

> Porting Git to Turing
> Machines would have the effect of allowing an infinite tape shared
> between multiple machines and they could possibly run forever.

I'm sorry, I thought we were talking about "Git" as it exists in the
real world.  Please recall that the motivation for my proof was to
refute the following claim of yours from a few messages ago:

>> How about pointing out what acts as the diagonal in your reasoning?
>
>If you are talking specifically about the uncountability of real
>numbers, that'd be quite deep down (as in an uncountability of push
>actions to a particular Git repo, particularly if we also allow
>reinitialization).

You referred to "Git" here.  That's why my proof was about Git.  You
didn't say that you were talking about some theoretical variant of Git
that supports "push actions" that literally *never* end, and that runs
on a theoretical machine with infinite memory that can never be built.

> As we're trying to generalize your proof for a single push action to
> be chosen among a finite set to all communications to a series of push
> actions, we do encounter a problem if we were to encode this as a mere
> list of push actions.  This can be done by a rather simple Cantor
> proof: The set of lists of a particular type T which admits at least
> two values is uncountable (a list of booleans can be directly mapped
> to a binary number and thus Cantor's original proof applied).

No, that's incorrect.  The set of lists of booleans is countable.
Moreover, for any type T, if the set of objects of type T is countable,
then the set of _lists_ of objects of type T is also countable.

Note that lists are finite, by definition.

If you intend to claim that by "push actions", you meant to include
infinite streams of push actions: this has no relevance to the real
world.

Even if we live in an open universe, the fact remains that at any
arbitrary point in time, the age of any git repository is always finite.
Therefore, no one can ever observe the result of an infinite-length
"push action" in the real world.  They can only ever observe the result
of some finite prefix of that so-called "push action".

* * *

I'm sorry, but I'm growing tired of this discussion.  I suppose you will
want to have the last word.  I'll try to resist the temptation to
correct any errors in it, but my silence should not be interpreted as
acceptance of your future claims.

 Regards,
   Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about .

Re: RFC: new syntax for inline patches

[Liliana Marie Prikler]

Hi Ricardo,

Am Donnerstag, dem 06.01.2022 um 08:12 +0100 schrieb Ricardo Wurmus:
> So lets take a step back and look at the location and shape of the
> bikeshed rather than its color.  Do we agree that it would be lovely
> to have a less flexible but declarative pattern to describe changes
> to files?  Less flexible than a full-blown editing DSL as that of
> Emacs, less flexible than perhaps arbitrary regular expression
> replacements as provided by substitute*?  I just think that sometimes
> we want to focus on the change itself and not how we get there.
I can't say that we do.  Look back at Attila's case for plain old
diffs.  It seems to me that if all you want to encode is a patch file,
you ought to use a patch file.  That doesn't necessarily entail adding
it to origin, however, and I think we can find some agreement if we
change the way we write things.

> It’s primarily a matter of style and readability.  I think it’s
> regrettable to have all these boilerplate build phase shenanigans to
> express a simple change in a file.  A large chunk of that is just
> boring set up work to be permitted to use “substitute*”, and then the
> “substitute*” itself is primarily concerned with an anchor that could
> not be much uglier: a regular expression DSL embedded in a string
> with double escaping.  Yuck!
> 
> Even something as simple as diff-in-a-string seems more appealing in
> some cases than all these “substitute*” expressions.
Now X in a string is usually very appealing due to its pretty low
barrier for entry.  For a long time, I had the custom Ren'py launcher
be a big format¹, because that's what worked.  However, I've since
changed it to an aux-file + substitute*, and that gets my intent across
much more clearly.

I think we can do something similar for patches.  Rather than coding
them into the file, we'd have 
#:patches #~(list #$(locate-first-patch) #$(locate-second-patch)), and
a post-unpack phase (let's call it "patch") would take care of applying
these patches.  If you need store paths, you can write
@HERE_COMES_THE_STORE_PATH@ and easily match that in a substitute that
runs in a post-pack phase.  If you prefer we do so atomically in unpack
(i.e. unpack becomes "unpack and apply all #:patches") so as to not
change our phase API, that'd also work for me personally.

In short, I'd say "yes" to making it easier to apply patches at build
time.  Currently, you have to add both the patch and the patch program
as well as code up your own phase to do so – not ideal.  We could
lessen that to just making sure patch is in native-inputs if the
#:patches keyword is used.

Now you still have to adjust dist_patch_DATA and that might be a pain
point for maintainers, but in the grand scheme of things it's in my
opinion a lesser evil.  WDYT?

¹ We need one, because the one supplied by upstream happily loads the
same files twice only to then fail with a huge stack trace.  I'm not
sure if I inadvertently fixed the reason why it loads the same files
twice elsewhere, but it's nice to have that control.