Re: What’s next?

[Ludovic Courtès]

Hi,

Efraim Flashner  skribis:

> On Mon, May 17, 2021 at 10:13:10PM +0200, Ludovic Courtès wrote:
>> Hi,
>> 
>> Efraim Flashner  skribis:
>> 
>> > package-transformations applied to the operating-system field of the
>> > os-config.
>> 
>> Ah, that’s a good one, but possibly tricky!  What would it operate on?
>> Any package?  Only those showing up in the system profile?
>> 
>> The former is not really possible; the latter is.
>> 
>> Ludo’.
>> 
>
> The idea is everything in the system declaration. So the global
> packages, the guix-daemon from the guix-daemon service,

Yeah, that’s not easily possible, in the sense that there’s no place to
“hook” to perform such transforms.  The reason is that references to
packages may be buried down anywhere in gexps or files produced by
services, an obvious example being:

  #~(make-forkexec-constructor
  (list #$(file-append some-package "/bin/xyz")
…))

The reference to ‘some-package’ here is deep down.

An option would be to have a way to provide ‘lower-object’ a customize
way to lower all the  records that it sees, for instance.  But
then, how does that interact with caches, etc.  Tricky!

Ludo’.

Re: What’s next?

[Joshua Branson]

Some other cool thoughts:

Package the PHP bits of wordpress.  Then create a wordpress theme that
uses either no or bootstrapable (reproducible?) javascript.  Wordpress
writes some really minimal simple wordpress themes that have minimal
javascript that could be used as a start.  I think there might be a way
that one could then use Emacs to make a really simple blog.  And we
could have a really simple WordPress service.

Or just go crazy a create a competitor to wordpress in GNU guile or
racket.

Package the PHP bits of mediagoblin.  I think this is already done in
one of the WIP branches.  Then create a front-end of media goblin that
uses no or minimal amount bootstrapable (reproducible?) javascript.

One of the guix developers has a WIP git repo web viewer.  And it looks
amazing!  He's got some of his guile code on there. I think it would be
really awesome if savannah's guix git repos could point to that for the
guix repos.  Then we (who am I kidding you, I'm not a developer...yet)
could somehow combine bugs.guix.gnu.org with that guile git repo web
viewer.  The eventual goal could be to create a competitor to sourcehut!

--
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: What’s next?

[raingloom]

On Tue, 18 May 2021 10:05:05 -0400
Leo Famulari  wrote:

> On Mon, May 17, 2021 at 10:35:22PM -0400, Joshua Branson wrote:
> > I suppose someone should fix the Hurd vulnerabilities as reported
> > here:
> > 
> > https://lists.gnu.org/archive/html/bug-hurd/2021-05/msg00079.html
> > 
> > I don't think the vulnerabilities have been disclosed yet nor has
> > there been a fix yet.  
> 
> That message is the disclosure.
> 

Why not put our eggs in a few more baskets with way fewer holes and
more, uh, basket inspectors looking at them, like maybe packaging Minix,
or OpenBSD, or MirageOS, or whatever? I think I stretched that metaphor
but yknow what I mean.
They have seen way more scrutiny than Hurd and also run on more
architectures and while not GPL licensed, AFAIK they are all libre.

Maybe they can't be used in the operating-system-kernel struct field,
but I don't see anything wrong with using Guix to deploy Mirage
unikernel images for instance.
There is even a nascent Scheme unikernel project with Loko Scheme.

Ooor maybe compile some things to WASM and use a WASM+WASI runtime. I
hate webshit but at least there is already tooling and major porting
efforts for WASM.

Re: What’s next?

[Efraim Flashner]

On Mon, May 17, 2021 at 10:13:10PM +0200, Ludovic Courtès wrote:
> Hi,
> 
> Efraim Flashner  skribis:
> 
> > package-transformations applied to the operating-system field of the
> > os-config.
> 
> Ah, that’s a good one, but possibly tricky!  What would it operate on?
> Any package?  Only those showing up in the system profile?
> 
> The former is not really possible; the latter is.
> 
> Ludo’.
> 

The idea is everything in the system declaration. So the global
packages, the guix-daemon from the guix-daemon service, but not packages
installed using /run/current-system/profile/bin/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: What’s next?

[Ricardo Wurmus]

Katherine Cox-Buday  writes:


Ludovic Courtès  writes:

BTW, another thing that’d be nice it to use Guile-Netlink to 
provide a

more capable static-networking service.


Thank you for the reminder! This is blocking me from standing up 
a few

edge-routers.

Also, more focus on aarch64-linux substitutes!


We’re currently waiting for three new 16-core Honeycomb LX2 boards 
to arrive Berlin, which should help with aarch64-linux 
substitutes.


--
Ricardo

Re: What’s next?

[Katherine Cox-Buday]

Ludovic Courtès  writes:

> BTW, another thing that’d be nice it to use Guile-Netlink to provide a
> more capable static-networking service.

Thank you for the reminder! This is blocking me from standing up a few
edge-routers.

Also, more focus on aarch64-linux substitutes!

-- 
Katherine

Re: What’s next?

[Julien Lepiller]

I've rebuilt only up to python 3, and a handful pytgon packages, not a lot 
more. I'm very confident for the one that enables optimisation, less so for the 
one that removes files (supposedly useless, like windows binaries and test 
files).

I'm go for both options, maybe python-update is more wise.

Le 18 mai 2021 15:30:24 GMT-04:00, Leo Famulari  a écrit :
>On Sat, May 15, 2021 at 02:08:50PM -0400, Julien Lepiller wrote:
>> In the short term I'd like to merge the python optimisations. We
>discussed it before release and thought it might be nice to merge them
>before c-u, from a separate branch.
>
>+1
>
>Have you tested them at all yet? If so, and they don't seem to break
>anything, maybe they could be squeezed onto the wip-ungrafting branch.
>
>The 'ungrafting' jobset (based on the wip-ungrafting branch) entails a
>complete rebuild of Python 2 and 3. If that branch requires another
>iteration due to broken builds, and we are confident that the Python
>optimisations won't break things, I'd say we could include them.
>
>Otherwise, we could do a python-updates branch that includes these
>optimizations, and updates to Python 3.8.10, along with any existing
>bug
>fixes for Python 2. It would be completed more quickly than
>core-updates.

Re: What’s next?

[Ludovic Courtès]

Bonjour !

Julien Lepiller  skribis:

> In the short term I'd like to merge the python optimisations. We
> discussed it before release and thought it might be nice to merge them
> before c-u, from a separate branch.

That’d be great!

BTW, another thing that’d be nice it to use Guile-Netlink to provide a
more capable static-networking service.

> Maybe before next release we'll have our separate repo on savannah for
> translations (it's currently a repo I manage on framagit). I'd also
> like to add some automation so I don't have to manually update the pot
> files :)

+1  :-)

Ludo’.

Re: What’s next?

[Ludovic Courtès]

Hi,

Bone Baboon  skribis:

> 1) Make the core parts of Guix reproducible
>
> Many core parts of Guix are not reproducible.  If more core parts of
> Guix were reproducible it would benefit all Guix users.
>
> There are several core parts of Guix that are not reproducible
> including:
>
> * Linux-libre
>   https://issues.guix.gnu.org/24028#2
>   Note: I like what the Linux-libre project is doing.
>   This is likely a result of Linux not being reproducible.
>
> * Many guix-*
>   https://issues.guix.gnu.org/48487#0
>
> * Guile
>   https://issues.guix.gnu.org/48490#0
>
> * nss 3.59 on the master branch
>   https://issues.guix.gnu.org/40316#5
>
> * Emacs
>   https://issues.guix.gnu.org/35085#7
>   Note: A good text editor is important.
> nvi, vim and neovim are reproducible for me.
>   Emacs is more than a text editor and that is a part of why it is
> not reproducible. 

All these are great (apart from the Guile and guix-* ones, which are
“known” issues).  I think it takes investigation, to pinpoint the source
of non-determinism, and also checking what other distros do, possibly
asking on the .

> 2) Alternative kernel

[...]

> It is great that work is already underway to get Guix to run on the Gnu
> Hurd microkernel.

Yup!  Help welcome on this front, too.  :-)

> I think the design concept of a microkernel make them  more resistant to
> the problem of increasing complexity at the kernel level when compared
> to monolithic kernels.  With microkernels the increased complexity is
> pushes out to user processes.  This allows the user (or their operating
> system) to choose the level of complexity.
>
>  is a listing of microkernel projects.

Note that once you have a microkernel, you have next to nothing, by
definition.  The Hurd (+ libc) provides everything you need to provide a
POSIX personality.

Thanks,
Ludo’.

Re: What’s next?

[Leo Famulari]

On Sat, May 15, 2021 at 02:08:50PM -0400, Julien Lepiller wrote:
> In the short term I'd like to merge the python optimisations. We discussed it 
> before release and thought it might be nice to merge them before c-u, from a 
> separate branch.

+1

Have you tested them at all yet? If so, and they don't seem to break
anything, maybe they could be squeezed onto the wip-ungrafting branch.

The 'ungrafting' jobset (based on the wip-ungrafting branch) entails a
complete rebuild of Python 2 and 3. If that branch requires another
iteration due to broken builds, and we are confident that the Python
optimisations won't break things, I'd say we could include them.

Otherwise, we could do a python-updates branch that includes these
optimizations, and updates to Python 3.8.10, along with any existing bug
fixes for Python 2. It would be completed more quickly than
core-updates.

Re: What’s next?

[Maxime Devos]

Ludovic Courtès schreef op za 15-05-2021 om 19:47 [+0200]:
> [...]
> Here’s my wish list of things that look achievable within 4 to 6 months
> (I hope to help on some of these):
> 
>   • [...]
> 
>   • Merging ‘core-updates’, perhaps with a switch to GCC 10?  Perhaps
> with support for “simplified packages” (getting rid of input
> labels)?  We’ll see how much can go in there, but the sooner the
> better.
> 
>   • On ‘core-updates’, merging either the full-source bootstrap or
> the reduced bootstrap on ARM, whichever comes first.  :-)
> 
>   [...]
> 

While we are talking about ‘core-updates’, could someone have a look
at a patch series I posted exactly a month ago that fixes a class of
cross-compilation bugs? See .
(No replies so far.)

Greetings,
Maxime.


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

Re: What’s next?

[Bone Baboon]

Bone Baboon writes:
> 1) Make the core parts of Guix reproducible
>
> Many core parts of Guix are not reproducible.  If more core parts of
> Guix were reproducible it would benefit all Guix users.
>
> There are several core parts of Guix that are not reproducible
> including:
>
> * Linux-libre
>   https://issues.guix.gnu.org/24028#2
>   Note: I like what the Linux-libre project is doing.
>   This is likely a result of Linux not being reproducible.
>
> * Many guix-*
>   https://issues.guix.gnu.org/48487#0
>
> * Guile
>   https://issues.guix.gnu.org/48490#0
>
> * nss 3.59 on the master branch
>   https://issues.guix.gnu.org/40316#5
>
> * Emacs
>   https://issues.guix.gnu.org/35085#7
>   Note: A good text editor is important.
> nvi, vim and neovim are reproducible for me.
>   Emacs is more than a text editor and that is a part of why it is
> not reproducible. 

I have one addition to this.  mariadb is failing to build from source
because of a failing test suite.  As mariadb is a dependency of
diffoscope this is causing diffoscope's build from source to also fail.
diffoscope is a useful tool for gathering information about why a
package is not reproducible.

`guix graph --path diffoscope mariadb` outputs:

```
diffoscope@174
ffmpeg@4.3.2
sdl2@2.0.12
fcitx@4.2.9.8
extra-cmake-modules@5.70.0
qtbase@5.15.2
mariadb@10.5.8
```

More details on how mariadb is failing to build can be seen here
.

Re: What’s next?

[Bone Baboon]

Ludovic Courtès writes:
> So, now that 1.3.0 is out the door, what’s next?!

> What’s your wish list?  What do you feel an urge to hack on?  :-)

There are two improvements on my Guix wish list.

1) Make the core parts of Guix reproducible
** I do not know if this fits into the 4-6 month time frame mentioned.

2) Alternative kernel
** Motivated by 1.
** Longer term beyond 6 months.

1) Make the core parts of Guix reproducible

Many core parts of Guix are not reproducible.  If more core parts of
Guix were reproducible it would benefit all Guix users.

There are several core parts of Guix that are not reproducible
including:

* Linux-libre
  https://issues.guix.gnu.org/24028#2
  Note: I like what the Linux-libre project is doing.
This is likely a result of Linux not being reproducible.

* Many guix-*
  https://issues.guix.gnu.org/48487#0

* Guile
  https://issues.guix.gnu.org/48490#0

* nss 3.59 on the master branch
  https://issues.guix.gnu.org/40316#5

* Emacs
  https://issues.guix.gnu.org/35085#7
  Note: A good text editor is important.
nvi, vim and neovim are reproducible for me.
Emacs is more than a text editor and that is a part of why it is
not reproducible. 

2) Alternative kernel

It is important to have a reproducible kernel.  Linux-libre is not
reproducible (see 1 above).  Linux-libre has not been reproducible for
an extended period of time.  Linux-libre not being reproducible was
reported in 2016 .

 provides an interesting
thought exercise.  What free libre kernel would Guix use if Linux was
no longer a viable option?  I do not agree with all their points. The
point on Linux complexity increasing rapidly (13:29-17:56) is the one I
would be most concerned about.

Both Linux-libre not being reproducible and the idea that Linux might
not be viable in the future highlight the importance (and potential
urgency) of having an alternative free libre kernel that Guix can run
on.

It is great that work is already underway to get Guix to run on the Gnu
Hurd microkernel.

I think the design concept of a microkernel make them  more resistant to
the problem of increasing complexity at the kernel level when compared
to monolithic kernels.  With microkernels the increased complexity is
pushes out to user processes.  This allows the user (or their operating
system) to choose the level of complexity.

 is a listing of microkernel projects.

Re: What’s next?

[Julien Lepiller]

In the short term I'd like to merge the python optimisations. We discussed it 
before release and thought it might be nice to merge them before c-u, from a 
separate branch.

Maybe before next release we'll have our separate repo on savannah for 
translations (it's currently a repo I manage on framagit). I'd also like to add 
some automation so I don't have to manually update the pot files :)

Le 15 mai 2021 13:47:19 GMT-04:00, "Ludovic Courtès"  a écrit :
>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):
>
>  • Merging Guix Home.
>
>  • Completing and consolidating Disarchive support (see
>): continuously building the
>Disarchive database, making sure it’s replicated or backed up by
>SWH, and having a blog post or two explaining the whole endeavor
>(I’m looking at you, Timothy ;-)).
>
>  • Merging Magali’s ‘guix git log’ work.
>
>  • Merging ‘core-updates’, perhaps with a switch to GCC 10?  Perhaps
>with support for “simplified packages” (getting rid of input
>labels)?  We’ll see how much can go in there, but the sooner the
>better.
>
>  • On ‘core-updates’, merging either the full-source bootstrap or
>the reduced bootstrap on ARM, whichever comes first.  :-)
>
>  • Consolidating the POWER9 and AArch64 ports (more build machines
>behind ci.guix!).
>
>  • Maybe a step towards “early cutoffs” to reduce the amount of
>rebuilding (more on that in a future post).
>
>  • Maybe optimized substitute downloads based on
>  
>or at the store item level (same as for early cutoffs).
>
>  • Maybe parameterized packages based on
> .
>
>What do people think?  What’s your wish list?  What do you feel an urge
>to hack on?  :-)
>
>Ludo’.

Re: What’s next?

[Leo Famulari]

On Mon, May 17, 2021 at 10:35:22PM -0400, Joshua Branson wrote:
> I suppose someone should fix the Hurd vulnerabilities as reported here:
> 
> https://lists.gnu.org/archive/html/bug-hurd/2021-05/msg00079.html
> 
> I don't think the vulnerabilities have been disclosed yet nor has there
> been a fix yet.

That message is the disclosure.

Re: What’s next?

[Joshua Branson]

Leo Famulari  writes:

> On Sun, May 16, 2021 at 06:26:57PM +0200, Svante Signell wrote:
>> What about Hurd?
>
> I think the answer will be: what about it? :)
>
> We always welcome Hurd-related work here in Guix.
>

I suppose someone should fix the Hurd vulnerabilities as reported here:

https://lists.gnu.org/archive/html/bug-hurd/2021-05/msg00079.html

I don't think the vulnerabilities have been disclosed yet nor has there
been a fix yet.

--
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: What’s next?

[Ludovic Courtès]

Hi Brendan,

Brendan Tildesley  skribis:

> Since you asked I'll dump my nebulous wishes here. Sorry that I don't have 
> very
> concrete suggestions and solutions, just things I think could be better.  I
> should also state that 99% of my thoughts about Guix are through the filter of
> "I want to build a Guix based desktop distribution that can be installed on
> library, school, and home computers and Just Work better than Microsoft 
> Windows"

This is great.  I agree that polishing what already exists should remain
a major goal.

> 1. Improve guix pull and updating reliability.
> Updating guix for me is often like this:
> $ guix pull
> retrieving git objects
> TLS error in stream blah blah blah
> $ guix pull
> retrieving git objects..34%. *dies but doesn't return to the prompt*
> ctrl-c

I’ve literally never experienced this.  Could you file a bug or two to
bug-g...@gnu.org, with at least the command and all the output?

> $ guix pull
> $ guix upgrade
> $ sudo guix system reconfigure...
> GUI desktop crashes back to TTY mysteriously.

Likewise, please!

> Often downloads to source tarballs will download at ~30KiB/s. maybe some
> axel-like system where both upstream an mirror urls are used might be
> good.

Could you report as many details when that happens?

> Also this may be wrong but from memory I think if the hash is wrong on
> a source tarball, it will not bother trying to use the guix ci mirror
> of it, only if it's 404. So people with --no-substitutes can get
> completely stuck.

True: .

> 2. 'guix system reconfigure' without instantiating the new system until 
> reboot.
> I think the fact that reconfigure changes the whole system while its running 
> is
> a bit of a party trick, like pulling the table cloth out without any glasses
> falling over.  For a Desktop GNU/Linux it kinda just accidentally works much 
> of
> the time. I've always thought I'd prefer the default to simply install the new
> configuration in to GRUB and tell the user to reboot or add some flag like
> --instatiate-now.

I’m satisfied with the current default, but we could have an option to
delay activation until reboot.  Likewise, please file as a “wishlist”
item to bug-g...@gnu.org.

> 3. CLI consistency, e.g.,
> $ guix package => nothing
> $ guix system =>
> guix system: missing command name
> Try 'guix system --help' for more information.
>
> $ guix package --list-generations, but
> $ guix system list-generations ???\
>
> Also https://issues.guix.gnu.org/47618

All good points!

> 4. Make guix simpler and more performant.
>
> Guix is complex. It has features that make it theoretically superior in many
> ways, but in practice hasn't reached the reliability of simpler systems.  
> Every
> aspect of Guix seems to take more time, cpu, ram, hd space than say pacman.
> It's a bit beyond my skills to figure out how to actually improve these things
> though.
>
> $ guix system foobar
>
> takes 1.5-3.0 seconds on SSD, stats 2374 files, with 345 No such file or
> directories in order to determine the command doesn't exist and do nothing.

Agreed.  There have been improvements over time, such as the ld.so cache
in ‘core-updates’ (not merged yet), but there’s still a long way.

It’s frustrating for all of us, but one way to help is by pinpointing
specific bottlenecks and gathering as much data as possible so we have a
good starting point for optimization work.

> A fast guix could have 'guix time-machine -- environment --ad-hoc emacs --
> emacs' run instantly after its been ran once, and some kind of 'guix run'
> command could be added.

Yeah.

> 5. I think Guix should have some simple system to only update to the latest
> commit where behemoths like webkit/chromium already have substitutes available
> and that should maybe be the default way to update. It's not a big deal if we
> are making people build stuff that only takes 30 seconds and uses minimal
> ram. Doesn't need to be perfect. Ricardo made some simple scripts that did 
> stuff
> like that in the past.

Yes, this is being worked on (you may have seen
‘channel-with-substitutes-available’ in 1.3.0, which is a first step in
that direction.)

Thanks for sharing!  I guess my message here is that all these should be
broken down into individual bug reports/wishes that can be more easily
addressed.  :-)

Ludo’.

Re: What’s next?

[Ludovic Courtès]

Hi,

Efraim Flashner  skribis:

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

Ah, that’s a good one, but possibly tricky!  What would it operate on?
Any package?  Only those showing up in the system profile?

The former is not really possible; the latter is.

Ludo’.

Re: What’s next?

[Leo Famulari]

On Sun, May 16, 2021 at 06:26:57PM +0200, Svante Signell wrote:
> What about Hurd?

I think the answer will be: what about it? :)

We always welcome Hurd-related work here in Guix.

Re: What’s next?

[zimoun]

Hi,

>   • Completing and consolidating Disarchive support (see
> ): continuously building the
> Disarchive database, making sure it’s replicated or backed up by
> SWH, and having a blog post or two explaining the whole endeavor
> (I’m looking at you, Timothy ;-)).

Adding items here:

 - SVN support.  Chunks are there [1] but missing glue.
 - other (Hg, CVS, etc.)
 - coverage (by the Data Service?)

 - guix time -C channels.scm -- help
   where channels.scm describes missing Git repo, fallback to SWH.

   (Corollary, “guix channel” subcommand helping to add, remove, save,
   etc.)

1: 

>   • Merging Magali’s ‘guix git log’ work.

About reviewing, feedback welcome. :-) From my understanding, some
commits should be rewritten (split or merged).

In the same direction, I add 2 items:

 - guix time-machine --commit= / guix pull --commit=
 - guix git tag: for locally tagging a specific commit

On the next-next step, be able to download information (JSON?) from the
Data Service and use it to easy the “navigation” in the history.  


> What do people think?  What’s your wish list?  What do you feel an urge
> to hack on?  :-)

Add another item:

 - Julia importer (I am working on it, slowly! :-))

Cheers,
simon

PS:  I hope that I have not messed up the In-Reply-To. :-)

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

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

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

Re: What’s next?

[Maxim Cournoyer]

Hi Ludovic,

Those are all good ideas, but to be brief:

+1 for core-updates & newer GCC.

Some other things I'd like to see that seem achievable in a 4-6 months
time frame:

* Add .deb and .rpm formats for 'guix pack'.
* Better Texlive importer
* Easier way to debug (guix debug package) -> leaves you in an
environment including everything needed to debug (sources, symbols,
GDB).
* Proper support to mount NFS shares at boot
* guix environment --fhs (file hierachy standard)
* Support for Go modules in the go-build-system
* Better tooling (perhaps contribute to fix perf issues in Geiser/Emacs)
* A bootsplash to finally hide our "Error in finalizer: Success" message ;-)

I'll stop there :-).

Maxim

Re: What’s next?

[Efraim Flashner]

On Sat, May 15, 2021 at 07:47:19PM +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):
> 
>   • Merging Guix Home.
> 
>   • Completing and consolidating Disarchive support (see
> ): continuously building the
> Disarchive database, making sure it’s replicated or backed up by
> SWH, and having a blog post or two explaining the whole endeavor
> (I’m looking at you, Timothy ;-)).
> 
>   • Merging Magali’s ‘guix git log’ work.
> 
>   • Merging ‘core-updates’, perhaps with a switch to GCC 10?  Perhaps
> with support for “simplified packages” (getting rid of input
> labels)?  We’ll see how much can go in there, but the sooner the
> better.
> 
>   • On ‘core-updates’, merging either the full-source bootstrap or
> the reduced bootstrap on ARM, whichever comes first.  :-)
> 
>   • Consolidating the POWER9 and AArch64 ports (more build machines
> behind ci.guix!).
> 
>   • Maybe a step towards “early cutoffs” to reduce the amount of
> rebuilding (more on that in a future post).
> 
>   • Maybe optimized substitute downloads based on
> 
> or at the store item level (same as for early cutoffs).
> 
>   • Maybe parameterized packages based on
> .
> 
> What do people think?  What’s your wish list?  What do you feel an urge
> to hack on?  :-)
> 
> Ludo’.
> 

+1 on core-updates

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

-- 
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: What’s next?

[Ricardo Wurmus]

Ludovic Courtès  writes:

> Ricardo Wurmus  skribis:
>
>> Chris Marusich  writes:
>>
>>> Leo Famulari  writes:
>>>
 So, I use and recommend `guix pull`!
>>>
>>> I use it too.  Statements by others in this thread that "nobody" uses it
>>> or that "everyone" is using Git are mistaken.
>>>
>>> I use Git when I want to hack on Guix.  Otherwise, I use 'guix pull'.
>>> IMO, the biggest problem with 'guix pull' is that there is no easy
>>> rollback.  I can live with long execution times (--fallback is fine, but
>>> it'd be nice if substitutes were available more often), and I can live
>>> with 'guix pull' causing me to get a version of guix that's broken
>>> somehow, but the inability to easily roll back when things go south
>>> makes me hesitant to run 'guix pull' regularly.
>>
>> I believe this can be fixed by adding more links to “.config/guix”,
>> i.e. before creating “latest” it would create “2017-05-24:08:21:01.123”
>> and then link from there to “latest”.  On update it would create a new
>> link “2017-05-25:17:45:45.123” and link that to latest.  Roll back would
>> be a matter of pointing “2017-05-24:08:21:01.123” to “latest”.
>
> There would be some similarity with profiles.  Should we simply use
> profiles, and effectively turn ~/.config/guix/latest into a profile,
> with generations etc.?

That’s not a bad idea!  It sure beats messing with a single link and it
makes it possible to more easily manage different versions of Guix.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: What’s next?

[Maxim Cournoyer]

Hello Ludovic,

l...@gnu.org (Ludovic Courtès) writes:

> Maxim Cournoyer  skribis:
>
>> Hi,
>>
>> l...@gnu.org (Ludovic Courtès) writes:
>>
>>> Hi Brendan,
>>>
>>> Brendan Tildesley  skribis:
>>>
 One little annoyance I have is that guix takes every opportunity to
 update the list of substitutes when guix build, guix package -u, etc...
 is run, and fills my terminal with output like:

 substitute: updating list of substitutes from
 'https://mirror.hydra.gnu.org'... 100.0%
 substitute: updating list of substitutes from
 'https://mirror.hydra.gnu.org'... 100.0%
 substitute: updating list of substitutes from
 'https://mirror.hydra.gnu.org'... 100.0%
 substitute: updating list of substitutes from
 'https://mirror.hydra.gnu.org'... 100.0%
 ...
>>>
>>> I agree, it’s actually a huge annoyance.  It relates to grafts and how
>>> they are implemented; I took a stab at fixing this a while back but the
>>> approach turned out to be (mostly?) misguided:
>>>
>>>   https://bugs.gnu.org/22990
>>>
>>> Would be worth thinking through it again!
>>
>> Maybe we could make a timer variable configurable, so that at least it
>> doesn't try to refresh this information at *every* guix command?
>
> That’s not what’s happening.  When you see repeated lines that go
> directly to 100%, that’s because it’s fetching metadata for just a
> single package, and does that one by one.
>
> In other cases, it fetches as many as possible at once, and uses HTTP
> pipelining to send all these requests to hydra.gnu.org.

My observation was that for the same exact command (I just tried: "guix
environment emacs-el-mock") entered twice:

--8<---cut here---start->8---
$ guix environment emacs-el-mock
substitute: updating list of substitutes from 'https://bayfront.guixsd.org'...  
 0.0
substitute: updating list of substitutes from 'https://bayfront.guixsd.org'...  
33.3
[...] # (downloads a bunch of substitute)
[env]$ exit
$ guix environment emacs-el-mock
substitute: updating list of substitutes from 'https://bayfront.guixsd.org'... 
100.0%
substitute: updating list of substitutes from 'https://bayfront.guixsd.org'... 
100.0%
substitute: updating list of substitutes from 'https://bayfront.guixsd.org'... 
100.0%
[env]$
--8<---cut here---end--->8---

We can see that a connection is made to the substitute server(s) and
data is retrieved each time the command is entered. Why does it need to
refresh the list of substitutes the second time? Everything needed is
already in the store.

Maxim

Re: What’s next?

[Ludovic Courtès]

Ricardo Wurmus  skribis:

> Ludovic Courtès  writes:

[...]

>> Oops.  Here we go:
>>
>> modified   nix/libstore/build.cc
>> @@ -2449,8 +2449,11 @@ void DerivationGoal::registerOutputs()
>>  Hash h2 = recursive ? hashPath(ht, actualPath).first : 
>> hashFile(ht, actualPath);
>>  if (h != h2)
>>  throw BuildError(
>> -format("output path `%1%' should have %2% hash `%3%', 
>> instead has `%4%'")
>> -% path % i->second.hashAlgo % printHash16or32(h) % 
>> printHash16or32(h2));
>> +format("%1% hash mismatch for output path `%2%'\n"
>> +   "  expected: %3%\n"
>> +   "  actual:   %4%")
>> +% i->second.hashAlgo % path
>> +% printHash16or32(h) % printHash16or32(h2));
>>  }
>>
>>  /* Get rid of all weird permissions.  This also checks that
>> @@ -3096,7 +3099,9 @@ void SubstitutionGoal::finished()
>>  Hash expectedHash = parseHash16or32(hashType, 
>> string(expectedHashStr, n + 1));
>>  Hash actualHash = hashType == htSHA256 ? hash.first : 
>> hashPath(hashType, destPath).first;
>>  if (expectedHash != actualHash)
>> -throw SubstError(format("hash mismatch in downloaded path 
>> `%1%': expected %2%, got %3%")
>> +throw SubstError(format("hash mismatch in downloaded path 
>> `%1%'\n"
>> +"  expected: %2%\n"
>> +"  actual:   %3%")
>>  % storePath % printHash(expectedHash) % 
>> printHash(actualHash));
>>  }
>>
>> Should we apply it?
>
> Yes, please.  This looks much better!  Thank you!

Applied!

Ludo’.

Re: What’s next?

[Ludovic Courtès]

Maxim Cournoyer  skribis:

> Hi,
>
> l...@gnu.org (Ludovic Courtès) writes:
>
>> Hi Brendan,
>>
>> Brendan Tildesley  skribis:
>>
>>> One little annoyance I have is that guix takes every opportunity to
>>> update the list of substitutes when guix build, guix package -u, etc...
>>> is run, and fills my terminal with output like:
>>>
>>> substitute: updating list of substitutes from
>>> 'https://mirror.hydra.gnu.org'... 100.0%
>>> substitute: updating list of substitutes from
>>> 'https://mirror.hydra.gnu.org'... 100.0%
>>> substitute: updating list of substitutes from
>>> 'https://mirror.hydra.gnu.org'... 100.0%
>>> substitute: updating list of substitutes from
>>> 'https://mirror.hydra.gnu.org'... 100.0%
>>> ...
>>
>> I agree, it’s actually a huge annoyance.  It relates to grafts and how
>> they are implemented; I took a stab at fixing this a while back but the
>> approach turned out to be (mostly?) misguided:
>>
>>   https://bugs.gnu.org/22990
>>
>> Would be worth thinking through it again!
>
> Maybe we could make a timer variable configurable, so that at least it
> doesn't try to refresh this information at *every* guix command?

That’s not what’s happening.  When you see repeated lines that go
directly to 100%, that’s because it’s fetching metadata for just a
single package, and does that one by one.

In other cases, it fetches as many as possible at once, and uses HTTP
pipelining to send all these requests to hydra.gnu.org.

Ludo’.

Re: What’s next?

[myglc2]

On 05/24/2017 at 21:56 Ricardo Wurmus writes:

> Catonano  writes:
>
>> 2017-05-24 18:25 GMT+02:00 Jan Nieuwenhuizen :
> […]
>>> A friend of mine is having a second look at Guix (not SD yet) and one of
>>> the most confusing things initially is `guix pull'.  "When/how do I use
>>> that," he asks...and I can only say: I'm not using that...I think we
>>> want this to work--or something like this, we talked about this at
>>> FOSDEM, but AFAIK everyone is using Guix with Git.
>>>
>>> He responds with: then *why* is it in the manual.  I have no answer.
>>> Possibly I'm wrong and/or my information is outdated?
>>>
>>
>> This is an important point for me too
>>
>> I realized that everyone is using git and not guix pull just yesterday
> […]
>> I think this is a problem. It' s unfair to newcomers and it damages Guix as
>> a project because it makes the learning curve steeper with not so much of a
>> point why.
>
> There are two reasons why developers use Guix from git:
>
> * it allows them to add new packages and features to Guix itself.  This
>   is something “guix pull” doesn’t support well.
>
> * it doesn’t require compiling all of Guix on each update.

Hmm, that explains how it feels. Why doesn't it just pull the compiled guix 
files?

Re: What’s next?

[myglc2]

On 05/27/2017 at 12:13 Ludovic Courtès writes:

> Ricardo Wurmus  skribis:
>
>> Chris Marusich  writes:
>>
>>> Leo Famulari  writes:
>>>
 So, I use and recommend `guix pull`!
>>>
>>> I use it too.  Statements by others in this thread that "nobody" uses it
>>> or that "everyone" is using Git are mistaken.
>>>
>>> I use Git when I want to hack on Guix.  Otherwise, I use 'guix pull'.
>>> IMO, the biggest problem with 'guix pull' is that there is no easy
>>> rollback.  I can live with long execution times (--fallback is fine, but
>>> it'd be nice if substitutes were available more often), and I can live
>>> with 'guix pull' causing me to get a version of guix that's broken
>>> somehow, but the inability to easily roll back when things go south
>>> makes me hesitant to run 'guix pull' regularly.
>>
>> I believe this can be fixed by adding more links to “.config/guix”,
>> i.e. before creating “latest” it would create “2017-05-24:08:21:01.123”
>> and then link from there to “latest”.  On update it would create a new
>> link “2017-05-25:17:45:45.123” and link that to latest.  Roll back would
>> be a matter of pointing “2017-05-24:08:21:01.123” to “latest”.
>
> There would be some similarity with profiles.  Should we simply use
> profiles, and effectively turn ~/.config/guix/latest into a profile,
> with generations etc.?

+1

Re: What’s next?

[Ricardo Wurmus]

Ludovic Courtès  writes:

> Ricardo Wurmus  skribis:
>
>> Ludovic Courtès  writes:
>>
>>> Hello!
>>>
>>> Ricardo Wurmus  skribis:
>>>
 Here are some other annoyances:

 * the verbosity of reporting hash mismatches.  You posted a neat little
   change for that some time ago, but I cannot find it any more.
>>>
>>> Oh right, see attached.
>>
>> I think you forgot to attach it.
>
> Oops.  Here we go:
>
> modified   nix/libstore/build.cc
> @@ -2449,8 +2449,11 @@ void DerivationGoal::registerOutputs()
>  Hash h2 = recursive ? hashPath(ht, actualPath).first : 
> hashFile(ht, actualPath);
>  if (h != h2)
>  throw BuildError(
> -format("output path `%1%' should have %2% hash `%3%', 
> instead has `%4%'")
> -% path % i->second.hashAlgo % printHash16or32(h) % 
> printHash16or32(h2));
> +format("%1% hash mismatch for output path `%2%'\n"
> +"  expected: %3%\n"
> +"  actual:   %4%")
> +% i->second.hashAlgo % path
> + % printHash16or32(h) % printHash16or32(h2));
>  }
>
>  /* Get rid of all weird permissions.  This also checks that
> @@ -3096,7 +3099,9 @@ void SubstitutionGoal::finished()
>  Hash expectedHash = parseHash16or32(hashType, 
> string(expectedHashStr, n + 1));
>  Hash actualHash = hashType == htSHA256 ? hash.first : 
> hashPath(hashType, destPath).first;
>  if (expectedHash != actualHash)
> -throw SubstError(format("hash mismatch in downloaded path 
> `%1%': expected %2%, got %3%")
> +throw SubstError(format("hash mismatch in downloaded path 
> `%1%'\n"
> + "  expected: %2%\n"
> + "  actual:   %3%")
>  % storePath % printHash(expectedHash) % 
> printHash(actualHash));
>  }
>
> Should we apply it?

Yes, please.  This looks much better!  Thank you!

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: What’s next?

[Ludovic Courtès]

Ricardo Wurmus  skribis:

> Ludovic Courtès  writes:
>
>> Hello!
>>
>> Ricardo Wurmus  skribis:
>>
>>> Here are some other annoyances:
>>>
>>> * the verbosity of reporting hash mismatches.  You posted a neat little
>>>   change for that some time ago, but I cannot find it any more.
>>
>> Oh right, see attached.
>
> I think you forgot to attach it.

Oops.  Here we go:

modified   nix/libstore/build.cc
@@ -2449,8 +2449,11 @@ void DerivationGoal::registerOutputs()
 Hash h2 = recursive ? hashPath(ht, actualPath).first : hashFile(ht, actualPath);
 if (h != h2)
 throw BuildError(
-format("output path `%1%' should have %2% hash `%3%', instead has `%4%'")
-% path % i->second.hashAlgo % printHash16or32(h) % printHash16or32(h2));
+format("%1% hash mismatch for output path `%2%'\n"
+			   "  expected: %3%\n"
+			   "  actual:   %4%")
+% i->second.hashAlgo % path
+		% printHash16or32(h) % printHash16or32(h2));
 }
 
 /* Get rid of all weird permissions.  This also checks that
@@ -3096,7 +3099,9 @@ void SubstitutionGoal::finished()
 Hash expectedHash = parseHash16or32(hashType, string(expectedHashStr, n + 1));
 Hash actualHash = hashType == htSHA256 ? hash.first : hashPath(hashType, destPath).first;
 if (expectedHash != actualHash)
-throw SubstError(format("hash mismatch in downloaded path `%1%': expected %2%, got %3%")
+throw SubstError(format("hash mismatch in downloaded path `%1%'\n"
+	"  expected: %2%\n"
+	"  actual:   %3%")
 % storePath % printHash(expectedHash) % printHash(actualHash));
 }

Should we apply it?

>> I agree with this direction, but we’ll have to work on concrete cases
>> here.  Bug reports of the form “when I do this I get a stack trace
>> instead of an error message” are welcome!
>
> Danny submitted bug #27100 for this with two examples.

Great.

Thanks,
Ludo’.

Re: What’s next?

[Maxim Cournoyer]

Hi,

l...@gnu.org (Ludovic Courtès) writes:

> Hi Brendan,
>
> Brendan Tildesley  skribis:
>
>> One little annoyance I have is that guix takes every opportunity to
>> update the list of substitutes when guix build, guix package -u, etc...
>> is run, and fills my terminal with output like:
>>
>> substitute: updating list of substitutes from
>> 'https://mirror.hydra.gnu.org'... 100.0%
>> substitute: updating list of substitutes from
>> 'https://mirror.hydra.gnu.org'... 100.0%
>> substitute: updating list of substitutes from
>> 'https://mirror.hydra.gnu.org'... 100.0%
>> substitute: updating list of substitutes from
>> 'https://mirror.hydra.gnu.org'... 100.0%
>> ...
>
> I agree, it’s actually a huge annoyance.  It relates to grafts and how
> they are implemented; I took a stab at fixing this a while back but the
> approach turned out to be (mostly?) misguided:
>
>   https://bugs.gnu.org/22990
>
> Would be worth thinking through it again!

Maybe we could make a timer variable configurable, so that at least it
doesn't try to refresh this information at *every* guix command? Default
could be at least one hour. I care about my security, but refreshing
this at every command seems pretty wasteful in terms of resources.

Maxim

Re: What’s next?

[Ricardo Wurmus]

Ludovic Courtès  writes:

> Hello!
>
> Ricardo Wurmus  skribis:
>
>> Here are some other annoyances:
>>
>> * the verbosity of reporting hash mismatches.  You posted a neat little
>>   change for that some time ago, but I cannot find it any more.
>
> Oh right, see attached.

I think you forgot to attach it.

>> * texlive.  I’m working on splitting the package up.  (An aggressive
>>   firewall at work put a stop to that work, but I’ll try to resume very
>>   soon.)
>
> Good point!  Looking forward to that.

Me too!

>> * very explicit but cryptic stack traces.  I think that all errors
>>   should be reported more nicely.  The error can still be printed (on
>>   demand?), but Guix probably should not spill its innards too readily.
>
> I agree with this direction, but we’ll have to work on concrete cases
> here.  Bug reports of the form “when I do this I get a stack trace
> instead of an error message” are welcome!

Danny submitted bug #27100 for this with two examples.

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: What’s next?

[Ludovic Courtès]

Ricardo Wurmus  skribis:

> Chris Marusich  writes:
>
>> Leo Famulari  writes:
>>
>>> So, I use and recommend `guix pull`!
>>
>> I use it too.  Statements by others in this thread that "nobody" uses it
>> or that "everyone" is using Git are mistaken.
>>
>> I use Git when I want to hack on Guix.  Otherwise, I use 'guix pull'.
>> IMO, the biggest problem with 'guix pull' is that there is no easy
>> rollback.  I can live with long execution times (--fallback is fine, but
>> it'd be nice if substitutes were available more often), and I can live
>> with 'guix pull' causing me to get a version of guix that's broken
>> somehow, but the inability to easily roll back when things go south
>> makes me hesitant to run 'guix pull' regularly.
>
> I believe this can be fixed by adding more links to “.config/guix”,
> i.e. before creating “latest” it would create “2017-05-24:08:21:01.123”
> and then link from there to “latest”.  On update it would create a new
> link “2017-05-25:17:45:45.123” and link that to latest.  Roll back would
> be a matter of pointing “2017-05-24:08:21:01.123” to “latest”.

There would be some similarity with profiles.  Should we simply use
profiles, and effectively turn ~/.config/guix/latest into a profile,
with generations etc.?

Food for thought…  :-)

Ludo’.

Re: What’s next?

[Ludovic Courtès]

Hi!

Jan Nieuwenhuizen  skribis:

> A friend of mine is having a second look at Guix (not SD yet) and one of
> the most confusing things initially is `guix pull'.  "When/how do I use
> that," he asks...and I can only say: I'm not using that...I think we
> want this to work--or something like this, we talked about this at
> FOSDEM, but AFAIK everyone is using Guix with Git.
>
> He responds with: then *why* is it in the manual.  I have no answer.
> Possibly I'm wrong and/or my information is outdated?

I think there’s a lot of (well deserved, as far as its implementation
goes) badmouthing against ‘guix pull’ on #guix ;-), but nevertheless, I
think it’s a useful tool for users who don’t want to manage their own
Guix checkout etc. by themselves.

The manual does mention in several places what it’s for, I think.

Ludo’.

Re: What’s next?

[Ludovic Courtès]

Hi Brendan,

Brendan Tildesley  skribis:

> One little annoyance I have is that guix takes every opportunity to
> update the list of substitutes when guix build, guix package -u, etc...
> is run, and fills my terminal with output like:
>
> substitute: updating list of substitutes from
> 'https://mirror.hydra.gnu.org'... 100.0%
> substitute: updating list of substitutes from
> 'https://mirror.hydra.gnu.org'... 100.0%
> substitute: updating list of substitutes from
> 'https://mirror.hydra.gnu.org'... 100.0%
> substitute: updating list of substitutes from
> 'https://mirror.hydra.gnu.org'... 100.0%
> ...

I agree, it’s actually a huge annoyance.  It relates to grafts and how
they are implemented; I took a stab at fixing this a while back but the
approach turned out to be (mostly?) misguided:

  https://bugs.gnu.org/22990

Would be worth thinking through it again!

Thanks,
Ludo’.

Re: What’s next?

[Ludovic Courtès]

Hello!

Ricardo Wurmus  skribis:

> Here are some other annoyances:
>
> * the verbosity of reporting hash mismatches.  You posted a neat little
>   change for that some time ago, but I cannot find it any more.

Oh right, see attached.

> * texlive.  I’m working on splitting the package up.  (An aggressive
>   firewall at work put a stop to that work, but I’ll try to resume very
>   soon.)

Good point!  Looking forward to that.

> * very explicit but cryptic stack traces.  I think that all errors
>   should be reported more nicely.  The error can still be printed (on
>   demand?), but Guix probably should not spill its innards too readily.

I agree with this direction, but we’ll have to work on concrete cases
here.  Bug reports of the form “when I do this I get a stack trace
instead of an error message” are welcome!

Thanks,
Ludo’.

Re: What’s next?

[Adonay Felipe Nogueira]

I think we can try either using:

- ISO dates: [Full year number]-[Two digit month number]-[Two digit day
  number]T[Two digit hour in 24-hour clock]:[Two digit minutes]:[Two digit
  seconds]

- A numeric sufix: Like "latest.1" for the first generation, "latest.2"
  for the second, and so on, and "latest" for the numbered backup being
  considered as current. Thus, the date and time information would be
  kept in the file metadata, not in the name, specially considering that
  names with ":" might be problematic in some file systems.

I of course don't know, from a developer point of view, what is the best
option, but I thought about giving my "personal" two cents on the
matter. :)

-- 
- [[https://libreplanet.org/wiki/User:Adfeno]]
- Palestrante e consultor sobre /software/ livre (não confundir com
  gratis).
- "WhatsApp"? Ele não é livre, por isso não uso. Iguais a ele prefiro
  GNU Ring, ou Tox. Quer outras formas de contato? Adicione o vCard
  que está no endereço acima aos teus contatos.
- Pretende me enviar arquivos .doc, .ppt, .cdr, ou .mp3? OK, eu
  aceito, mas não repasso. Entrego apenas em formatos favoráveis ao
  /software/ livre. Favor entrar em contato em caso de dúvida.

Re: What’s next?

[Ricardo Wurmus]

Chris Marusich  writes:

> Leo Famulari  writes:
>
>> So, I use and recommend `guix pull`!
>
> I use it too.  Statements by others in this thread that "nobody" uses it
> or that "everyone" is using Git are mistaken.
>
> I use Git when I want to hack on Guix.  Otherwise, I use 'guix pull'.
> IMO, the biggest problem with 'guix pull' is that there is no easy
> rollback.  I can live with long execution times (--fallback is fine, but
> it'd be nice if substitutes were available more often), and I can live
> with 'guix pull' causing me to get a version of guix that's broken
> somehow, but the inability to easily roll back when things go south
> makes me hesitant to run 'guix pull' regularly.

I believe this can be fixed by adding more links to “.config/guix”,
i.e. before creating “latest” it would create “2017-05-24:08:21:01.123”
and then link from there to “latest”.  On update it would create a new
link “2017-05-25:17:45:45.123” and link that to latest.  Roll back would
be a matter of pointing “2017-05-24:08:21:01.123” to “latest”.

(“latest” should be renamed to “current” to better match the intent in
this case.)

Timestamped names like this are ugly, but that’s what’s at the top of my
head.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: What’s next?

[Leo Famulari]

On Thu, May 25, 2017 at 07:57:41AM -0700, Chris Marusich wrote:
> I use Git when I want to hack on Guix.  Otherwise, I use 'guix pull'.
> IMO, the biggest problem with 'guix pull' is that there is no easy
> rollback.  I can live with long execution times (--fallback is fine, but
> it'd be nice if substitutes were available more often), and I can live
> with 'guix pull' causing me to get a version of guix that's broken
> somehow, but the inability to easily roll back when things go south
> makes me hesitant to run 'guix pull' regularly.

It's not "easy rollback", but you can at least use it to deploy any Guix
commit, from any source, with the '--url=' argument.


signature.asc
Description: PGP signature

Re: What’s next?

[Chris Marusich]

Leo Famulari  writes:

> So, I use and recommend `guix pull`!

I use it too.  Statements by others in this thread that "nobody" uses it
or that "everyone" is using Git are mistaken.

I use Git when I want to hack on Guix.  Otherwise, I use 'guix pull'.
IMO, the biggest problem with 'guix pull' is that there is no easy
rollback.  I can live with long execution times (--fallback is fine, but
it'd be nice if substitutes were available more often), and I can live
with 'guix pull' causing me to get a version of guix that's broken
somehow, but the inability to easily roll back when things go south
makes me hesitant to run 'guix pull' regularly.

-- 
Chris


signature.asc
Description: PGP signature

Re: What’s next?

[Leo Famulari]

On Wed, May 24, 2017 at 09:34:14PM +0200, Catonano wrote:
> I think this is a problem. It' s unfair to newcomers and it damages Guix as
> a project because it makes the learning curve steeper with not so much of a
> point why.

It's true, we collectively worked around some problems with `guix pull`
for too long. Let's all eat the dog food when we don't actually need to
work from Git. I promise it tastes okay :)


signature.asc
Description: PGP signature

Re: What’s next?

[Ricardo Wurmus]

Catonano  writes:

> 2017-05-24 18:25 GMT+02:00 Jan Nieuwenhuizen :
[…]
>> A friend of mine is having a second look at Guix (not SD yet) and one of
>> the most confusing things initially is `guix pull'.  "When/how do I use
>> that," he asks...and I can only say: I'm not using that...I think we
>> want this to work--or something like this, we talked about this at
>> FOSDEM, but AFAIK everyone is using Guix with Git.
>>
>> He responds with: then *why* is it in the manual.  I have no answer.
>> Possibly I'm wrong and/or my information is outdated?
>>
>
> This is an important point for me too
>
> I realized that everyone is using git and not guix pull just yesterday
[…]
> I think this is a problem. It' s unfair to newcomers and it damages Guix as
> a project because it makes the learning curve steeper with not so much of a
> point why.

There are two reasons why developers use Guix from git:

* it allows them to add new packages and features to Guix itself.  This
  is something “guix pull” doesn’t support well.

* it doesn’t require compiling all of Guix on each update.

The latter is a defect in “guix pull” that we are aware of and working
on.  Progress has already been made in improving “guix pull”, but it
takes time.  It is not by design that “guix pull” is currently less
desirable than working from a git checkout.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: What’s next?

[Catonano]

2017-05-24 18:25 GMT+02:00 Jan Nieuwenhuizen :

>
>
> +1
>
> A friend of mine is having a second look at Guix (not SD yet) and one of
> the most confusing things initially is `guix pull'.  "When/how do I use
> that," he asks...and I can only say: I'm not using that...I think we
> want this to work--or something like this, we talked about this at
> FOSDEM, but AFAIK everyone is using Guix with Git.
>
> He responds with: then *why* is it in the manual.  I have no answer.
> Possibly I'm wrong and/or my information is outdated?
>

This is an important point for me too

I realized that everyone is using git and not guix pull just yesterday

I have been using guix pull until today because I didn' t know any better

The manual mentions something that only beginners use and doesn' t mention
something that the majority of the community is using.

Probably in many of the footages in which Ludo appears, the use of git over
guix pull is assumed.

I think this is a problem. It' s unfair to newcomers and it damages Guix as
a project because it makes the learning curve steeper with not so much of a
point why.

I kinda agree with myglc2, on this.

Re: What’s next?

[Adonay Felipe Nogueira]

As an average Guix user, I use `guix pull`.

In fact, I avoid `git pull and the pre-inst-env stuff`. I prefer to work
with GUIX_PACKAGE_PATH in order to work only with `guix package` and
`guix build` if I do have the need to install or build something that I
changed.

-- 
- [[https://libreplanet.org/wiki/User:Adfeno]]
- Palestrante e consultor sobre /software/ livre (não confundir com
  gratis).
- "WhatsApp"? Ele não é livre, por isso não uso. Iguais a ele prefiro
  GNU Ring, ou Tox. Quer outras formas de contato? Adicione o vCard
  que está no endereço acima aos teus contatos.
- Pretende me enviar arquivos .doc, .ppt, .cdr, ou .mp3? OK, eu
  aceito, mas não repasso. Entrego apenas em formatos favoráveis ao
  /software/ livre. Favor entrar em contato em caso de dúvida.

Re: What’s next?

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

> I think it’s time to think about what we want to work on next, ideally
> before the next release, and ideally said release should be in a couple
> of months rather than in 5 months.  Here are some important items I can
> think of:

Great points!

>  • Implement channels: .  A first step may
>be to fix some of the obvious shortcomings of ‘guix pull’: use (guix
>git) to optimize bandwidth usage, and compute the derivation of the
>new ‘guix’ and use that.
>
> I think the key idea is that we should fix all the annoyances and bugs,
> many of which seasoned Guix hackers more or less got used to, but which
> are nevertheless a serious hindrance when using Guix “normally.”

+1

A friend of mine is having a second look at Guix (not SD yet) and one of
the most confusing things initially is `guix pull'.  "When/how do I use
that," he asks...and I can only say: I'm not using that...I think we
want this to work--or something like this, we talked about this at
FOSDEM, but AFAIK everyone is using Guix with Git.

He responds with: then *why* is it in the manual.  I have no answer.
Possibly I'm wrong and/or my information is outdated?

Greetings,
janneke

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: What’s next?

[Catonano]

2017-05-24 15:11 GMT+02:00 Ludovic Courtès :

> Hello Guix!
>
> I think it’s time to think about what we want to work on next, ideally
>

one little ting I'd love is Janneke's and Jlicht's solution to use "binary"
nodejs packages

That would allow me to play with some projects that depend on nodejs

The problem of evaluating the adherence of the nodejs collection to the
Guix diistribution guidelines could be faced later ( I posted a thread that
I think is relevant in this regard)



>   • ‘guix offload’ terrible bug: .
>
>   • Guile 2.2 compiler terrible issue:
>  >.
>

terrible bugs are terrible bugs. They should be regarded as priorities


>   • Improve the UI: add colors (yay!), hide build logs by default for
> most commands, improve progress reports, display how much will be
> downloaded, etc.
>

This might be regarded as a small thing but to me this is very important
I use to watch Fedora's colorful terminals with longing


> I think the key idea is that we should fix all the annoyances and bugs,
> many of which seasoned Guix hackers more or less got used to, but which
> are nevertheless a serious hindrance when using Guix “normally.”
>

yeah

Re: What’s next?

[Brendan Tildesley]

Ludovic Courtès 於 2017-05-24 23:11 寫道:
> Hello Guix!
>
> I think it’s time to think about what we want to work on next, ideally
> before the next release, and ideally said release should be in a couple
> of months rather than in 5 months.  Here are some important items I can
> think of:
[...]
> I think the key idea is that we should fix all the annoyances and bugs,
> many of which seasoned Guix hackers more or less got used to, but which
> are nevertheless a serious hindrance when using Guix “normally.”
>
> Ludo’.

One little annoyance I have is that guix takes every opportunity to
update the list of substitutes when guix build, guix package -u, etc...
is run, and fills my terminal with output like:

substitute: updating list of substitutes from
'https://mirror.hydra.gnu.org'... 100.0%
substitute: updating list of substitutes from
'https://mirror.hydra.gnu.org'... 100.0%
substitute: updating list of substitutes from
'https://mirror.hydra.gnu.org'... 100.0%
substitute: updating list of substitutes from
'https://mirror.hydra.gnu.org'... 100.0%
...

It will output this line a different number each time based on some rule
I couldn't guess, and renders the percentage measurement meaningless.
Currently I am running `guix system init config.scm
--substitute-urls="http://10.1.1.61:8080 https://mirror.hydra.gnu.org/;
--fallback' from the 0.13 installer, and it his been outputting hundreds
of these lines for the last half an hour. I'm not sure if it is ever
going to stop, perhaps I've stumbled across a genuine bug? In any case,
the minor annoyance version is something I've noticed for a while.

Re: What’s next?

[Ricardo Wurmus]

Ludovic Courtès  writes:

> Hello Guix!
>
> I think it’s time to think about what we want to work on next, ideally
> before the next release, and ideally said release should be in a couple
> of months rather than in 5 months.  Here are some important items I can
> think of:

[…]

Excellent points!

> I think the key idea is that we should fix all the annoyances and bugs,
> many of which seasoned Guix hackers more or less got used to, but which
> are nevertheless a serious hindrance when using Guix “normally.”

Here are some other annoyances:

* the verbosity of reporting hash mismatches.  You posted a neat little
  change for that some time ago, but I cannot find it any more.

* texlive.  I’m working on splitting the package up.  (An aggressive
  firewall at work put a stop to that work, but I’ll try to resume very
  soon.)

* very explicit but cryptic stack traces.  I think that all errors
  should be reported more nicely.  The error can still be printed (on
  demand?), but Guix probably should not spill its innards too readily.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net