Re: What’s next?

[Pierre Neidhardt]

Hi Chris,

>> - File search.
>>
>>   (I did work on it a year ago, it's stuck, would need help from people
>>   familiar with Cuirass.)
>
> That sounds interesting.  What does it mean?  Would it help me figure
> out which commands come from which package?

Yes, and more ;)

> A feature I remember being cool they had enabled by default on Ubuntu
> back in the day was:
>
>   $ crawl-tiles
>   Not found.  Maybe "sudo apt-get install crawl-tiles"?
>
> So for us:
>
>   $ crawl-tiles
>   Not found.  Maybe "guix package -i crawl-tiles"?

Guix file-search can do that, but it wouldn't be limited to executables,
it would work for any file.

So `guix filesearch myimage.png`
would return a list of matches:

--8<---cut here---start->8---
emacs-myimage-mode:out  share/assets/myimage.png
...
some-game:assets  share/some-game/subfolder/myimage.png
--8<---cut here---end--->8---

It works by crawling the files and maintaining a database.

The work-in-progress on the wip-filesearch branch works for locally
built packages.  It's obviously very limited, the next thing we need to
do is sync the database from substitute servers.

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature

Re: What’s next?

[Joshua Branson]

Finally finish my endlessh service.

There's a version that works here:  http://issues.guix.gnu.org/39136

But it runs as root and IS NOT containerized.


P.S.  Also there were some really great suggestions in the previous
emails!

--
Joshua Branson (joshuaBPMan in #guix)
Sent from Emacs and Gnus
  https://gnucode.me
  https://video.hardlimit.com/accounts/joshua_branson/video-channels
  https://propernaming.org
  "You can have whatever you want, as long as you help
enough other people get what they want." - Zig Ziglar

Re: bug#47897: [PATCH] substitutes: Don't cache negative lookups or transient errors.

[Ludovic Courtès]

Hi,

Christopher Baines  skribis:

> The patches you've sent look good.

Pushed as 938ffcbb0589adc07dc12c79eda3e1e2bb9e7cf8 (I was generous and
lowered ‘%narinfo-negative-ttl’ to 10mn :-)).

Thanks,
Ludo’.

Re: unifying mcron and shepherd, service woes, improvements

[Xinglu Chen]

On Sat, May 15 2021, raingloom wrote:

> Just throwing this out there:
> mcron is basically a very simple service manager, so, why not just move
> all its timer functionality into shepherd (like systemd's timer units)
> and then we can have a unified way to manage and debug services.

Yes please!

Not really related to Shepherd or Mcron, but having something like
Syslogd/Journald at the user level to browse and rotate logs would be
nice.


signature.asc
Description: PGP signature

Re: unifying mcron and shepherd, service woes, improvements

[Philip McGrath]

On 5/15/21 12:59 PM, Ludovic Courtès wrote:

raingloom  skribis:

Or is everyone else happy with the current design and it's just me who
can't use Shepherd properly? 


I think it’s fair to say it’s rough on the edges.  :-)

One thing that’s on the to-do list is switching to a real event loop in
lieu of the current ad-hoc blocking design (this was discussed recently
on this mailing list).  The switch to ‘signalfd’ in the last release in
a step in that direction.  This will unlock “socket activation” and
possibly timers as you mentioned.


From a newcomer's perspective---I haven't used shepherd at all yet---I 
was surprised by the discussion leading up to 
:


On 3/19/21 10:42 PM, raid5atemyhomework wrote:
> Perhaps the point is not so much to be *multi-threaded* but to be 
*concurrent*


From very occasionally reading Andy Wingo's blog, I understand that 
Guile has a Concurrent ML implementation: 
.


I haven't programmed with it in Guile at all, but, from my experience 
using Racket's Concurrent ML system, I think it is the right foundation 
for a supervisor daemon. CML provides a consistent, extensible way to 
express, "when something happens, do some action", where "something 
happens" might be:


  * a timer fires;
  * a service, or a set of them, come up;
  * a subprocess exits (successfully or not);
  * a file descriptor is ready for reading and/or writing;
  * a "green thread" (IIUC, a Guile "fiber") has an uncaught exception;
  * a signal is received from the OS kernel;
  * a user sends a command from the client program;

... etc, etc, etc. The CML implementation handles many low-level details 
that are easy to get wrong.


-Philip

Re: unifying mcron and shepherd, service woes, improvements

[raingloom]

On Sat, 15 May 2021 18:59:52 +0200
Ludovic Courtès  wrote:

> > Security could also be improved probably. Can we have an OCAP model?
> > I feel like I don't know enough to say, so this mail is meant more
> > as a conversation starter.  
> 
> I think “having an ocap model” sounds nice but also vague.  :-)
> 
> A concrete step we can take is follow the principle of least authority
> (POLA) for more services.  That was the spirit of
> .

By OCAP I was thinking of things like not having global state, or at
least not having it implicitly. Something more functional. The lambda
calculus supports the OCAP model, and Guix is all about being
functional, so service management should not be any different.

Would also be nice if replacing running components was supported, a la
Erlang. Maybe steal the supervisor tree idea as well.

Re: What’s next?

[raingloom]

On Sat, 15 May 2021 23:24:41 +0300
Efraim Flashner  wrote:

> package-transformations applied to the operating-system field of the
> os-config.
> 

Gosh, yes please. I keep bumping into this while debugging services.

Also:
* substitutes over bittorrent might be cool.
* split packages more, similar to how Alpine does it. (i said i'd work
  on this and i intend to)
* deduplicate similar but not identical files (if the file system
  allows it)
* better GDB integration
* better initramfs environment, so debugging isn't such a horrible
  experience
* integrate environments with GUIs. if you've used nested rio on Plan
  9, you know what I'm talking about. I already have some utility
  programs for this, but they are pretty basic and only tested on my
  setup.
* accessible installer! even Arch has this now. (also something I want
  to work on eventually)

[spitball] integrating analyzers into build systems

[raingloom]

Would it make sense to run analyzers like Infer or MyPy at build time?
Maybe have something like --with-debug, so if there is an analyzer-log
output, only then is Infer ran?

In theory these tools are more useful for developers, but it's still
potentially useful to independently analyze our software for memory
safety and other errors, but also the build might run in or target an
environment the upstream developer didn't anticipate, for example when
cross compiling, or it could just straight up be patched and not
identical to whatever upstream verified as working.

Could also just be used to scan our software for vulnerabilities.

Anyways, just throwing this out there. I don't think it would have
immediate benefits, but it could be nice in the long term.

Re: What’s next?

[Christopher Lemmer Webber]

Pierre Neidhardt writes:

> Hi,
>
> Off the top of my head:
>
> - Optimize the man page database update during profile builds.
>
> - File search.
>
>   (I did work on it a year ago, it's stuck, would need help from people
>   familiar with Cuirass.)

That sounds interesting.  What does it mean?  Would it help me figure
out which commands come from which package?

A feature I remember being cool they had enabled by default on Ubuntu
back in the day was:

  $ crawl-tiles
  Not found.  Maybe "sudo apt-get install crawl-tiles"?

So for us:

  $ crawl-tiles
  Not found.  Maybe "guix package -i crawl-tiles"?

The curious thing about this though... it seems to require knowledge of
the *outputs*.

To invoke this manually, a user could type:

  # Queries curiass or some sort of build system, similar to guix weather
  $ guix search --binary crawl-tiles
  Found in:
   - crawl-tiles

> - A GUI.
>
>   https://gitlab.com/daym/guix-gui.git seems to be a good starting point.

Oh wow!  I'm going to give this a try.

> Maxim Cournoyer  writes:
>
>> * Add .deb and .rpm formats for 'guix pack'.
> [...]
>> * guix environment --fhs (file hierachy standard)
>
> Oh my, awesome ideas!!!  (These 2 in particular.)
>
> Cheers!

I'll add one that I *should* finish: I should get the setuid stuff
done.  IIRC it's like, two minor tweaks away from being done and
bitrotting... I've been busy...

Maybe I could do it towards the end of the following week?  Would be
good to get the damned thing done... and then finally get postfix in,
too.

Re: What’s next?

[Svante Signell]

On Sat, 2021-05-15 at 19:47 +0200, Ludovic Courtès wrote:
> Hello Guix!
> 
> So, now that 1.3.0 is out the door, what’s next?!
> 
> Here’s my wish list of things that look achievable within 4 to 6
> months
> (I hope to help on some of these):

What about Hurd?

Re: What’s next?

[Vagrant Cascadian]

On 2021-05-15, Ludovic Courtès wrote:
> So, now that 1.3.0 is out the door, what’s next?!
>
> Here’s my wish list of things that look achievable within 4 to 6 months
> (I hope to help on some of these):

   • Add a "make dist" job to ci.guix.gnu.org to produce prerelease
 source tarballs.

   • guix lint: support for spellchecker or basic grammar
 https://issues.guix.gnu.org/44675
 Let's have fewer spelling/typo/grammar issues end up in the next
 release tarballs! :)

live well,
  vagrant


signature.asc
Description: PGP signature

Re: GNU Guix 1.4.0 in September? (was: Re: GNU Guix 1.3.0 released)

[Vagrant Cascadian]

On 2021-05-16, Maxim Cournoyer wrote:
> Yes, thank you Simon and Leo for the help with the release!  I felt less
> lonely :-).  I've learned that producing a release can easily take 2-3
> weeks even in good conditions (e.g., not many blockers to fix).  I'd
> suggest anyone (myself included :-)) trying to meet the schedule to
> seriously start trying to put out RCs a month before the planned release
> date.

It would be nice to get a Release Candidate (or Pre Release?) out with
some time before the string freeze; it's easiest for me to do the
spelling/grammar/typo checks and fixes after the first RC tarball (as it
is basically just part of my packaging for Debian workflow), but was a
little disappointing to not be able to get such trivial fixes into the
release.

Alternately or additionally, setting up a "make dist" job on
ci.guix.gnu.org and publishing the resulting tarball somewhere would
allow me to check at arbitrary points during the release cycle and catch
things earlier.


live well, 
  vagrant


signature.asc
Description: PGP signature

Re: What’s next?

[Maxime Devos]

Ludovic Courtès schreef op za 15-05-2021 om 19:47 [+0200]:
> Hello Guix!
> 
> So, now that 1.3.0 is out the door, what’s next?!
> 
> Here’s my wish list of things that look achievable within 4 to 6 months
> (I hope to help on some of these): [...]

Distributing substitutes over IPFS.

The original patch series dates from 2018
. We now have an IPFS service
(, merged) and a patch to expose the the 
gateway
and not only the API (, unmerged).
It seems the only part missing is the IPFS substituter (and relevant "guix 
publish"
code) itself.

The discussion on IPLD and Unixfs is rather esoteric to me, so I can't help
there.

Greetings,
Maxime


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

GNU Guix 1.4.0 in September? (was: Re: GNU Guix 1.3.0 released)

[Maxim Cournoyer]

Hello,

Ludovic Courtès  writes:

> Hi!
>
> Maxim Cournoyer  skribis:
>
>> We are pleased to announce the release of GNU Guix 1.3.0!
>
> Yay, congrats everyone!
>
> Kudos Maxim for taking responsibility for the whole process!  Now you
> know what can be improved :-) and I’m interested in helping make the
> process smoother.

Thanks :-).  It was nice to have the backing of the bug fixing squad and
your generous contributions in the release material write-up.  Thanks to
Julien Lepiller for their help and availability w.r.t. the translations.

> There’s no rush, but we can already start thinking about who’s turn is
> next.  It’s great if it’s you, Maxim, but if another experienced hacker
> is interested, please make yourself known!

I wouldn't mind to do it again; twice in a row seems like it may be a
bit fresh in my mind and enable me to do more refinements to the build
system.  I'd also be happy to mentor someone else to try their hand at
it.  I feel like rotation improves our processes, especially w.r.t. to
its documentation.

> Note also that we were “only” 3 weeks late thanks to the hard work of
> zimoun and Leo early on keeping track of everything that needed to be
> addressed.  If someone wants to propose a date for the next release and
> take responsibility as “release keeper”, we’ll all welcome that!

Yes, thank you Simon and Leo for the help with the release!  I felt less
lonely :-).  I've learned that producing a release can easily take 2-3
weeks even in good conditions (e.g., not many blockers to fix).  I'd
suggest anyone (myself included :-)) trying to meet the schedule to
seriously start trying to put out RCs a month before the planned release
date.

Perhaps we can aim for the next release mid-September (core-updates).
I'm not too sure of the status of core-updates right now, but last time
I worked on it was in a rather good state.

Thanks,

Maxim

Re: What’s next?

[Pierre Neidhardt]

Hi,

Off the top of my head:

- Optimize the man page database update during profile builds.

- File search.

  (I did work on it a year ago, it's stuck, would need help from people
  familiar with Cuirass.)

- A GUI.

  https://gitlab.com/daym/guix-gui.git seems to be a good starting point.

Maxim Cournoyer  writes:

> * Add .deb and .rpm formats for 'guix pack'.
[...]
> * guix environment --fhs (file hierachy standard)

Oh my, awesome ideas!!!  (These 2 in particular.)

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature