Re: Guix beyond 1.0: let’s have a roadmap!

[pelzflorian (Florian Pelz)]

On Fri, Jun 28, 2019 at 07:35:22PM -0600, ison wrote:
> On Thu, Jun 27, 2019 at 06:05:27PM +0200, Ludovic Courtès wrote:
> > What do *you* want Guix to address in the future?
> 
> How about a --with-version flag for guix build and guix package?
> Sort of like the convenience features --with-source and --with-input for 
> re-writing package fields but this would be convenient for rewriting the 
> package version string.
> 

+1

This is .

Regards,
Florian

Re: Guix beyond 1.0: let’s have a roadmap!

[ison]

On Thu, Jun 27, 2019 at 06:05:27PM +0200, Ludovic Courtès wrote:
> What do *you* want Guix to address in the future?

How about a --with-version flag for guix build and guix package?
Sort of like the convenience features --with-source and --with-input for 
re-writing package fields but this would be convenient for rewriting the 
package version string.

Guix beyond 1.0: let’s have a roadmap!

[Jesse Gibbons]

My wishlist (a bit wordier and less organized than what most have
responded):

- At least two have already said this, improve package searching. I
  recommend every package have an optional list of keywords or
  keyphrases to make searching a lot more reliable and possibly faster.

- Refactor the package modules. A lot of packages stand alone in their
  own module when they could fit well into an already established
  module without making it much larger.

- Document all functions or syntax exported in any guix modules (like
  substitute*) either in the guix manual or in a separate guix reference
  manual.

- Debugging/diagnostic mechanism for hanging build processes. (I want
  to know why guile-emacs takes forever to build on my machine).

- `guix import git` to more easily define packages from a git
  repository.

- A way to generate a manifest from the command line.

- A way to generate a service definition from the command line.

- A way to select services and system-wide packages in the graphical
  installer (like how aptitude lets you browse and select packages when
  installing debian)

- A way to install a service (built for mcron or shepherd) specifically
  for a user.

- #:glib-or-gtk option for (potentially) all build systems (like what
  meson-build-system currently provides). If not for all build systems,
  at least for python-build-system.

Re: 01/01: gnu: gstreamer: Skip failing test on 32-bit systems.

[Marius Bakke]

Mark H Weaver  writes:

> Marius Bakke  writes:
>
>> Mark H Weaver  writes:
>>
>>> Hi Marius,
>>>
>>> guix-comm...@gnu.org writes:
>>>
 mbakke pushed a commit to branch staging
 in repository guix.

 commit 2a9d89afb6fb869dd2bdf1e9f710f487786930fc
 Author: Marius Bakke 
 Date:   Thu Jun 13 14:08:32 2019 +0200

 gnu: gstreamer: Skip failing test on 32-bit systems.
 
 * gnu/packages/gstreamer.scm (gstreamer)[arguments]: When building for 
 a
 32-bit system, add #:phases.
>>> [...]
 +   ,@(if (not (target-64bit?))
 +   ;; Skip test that fails on 32-bit systems:
 +   ;; 
 .
 +   `(#:phases (modify-phases %standard-phases
 +(add-before 'check 'disable-gstbufferpool-test
 +  (lambda _
 +(substitute* "tests/check/Makefile"
 +  (("^[[:blank:]]+gst/gstbufferpool.*$")
 +   ""))
 +  #t
 +   '(
>>>
>>> This might be sweeping a critical bug under the rug.  Does
>>>
>>>   Unexpected critical/warning: gst_buffer_resize_range:
>>> assertion 'bufmax >= bufoffs + offset + size' failed
>>>
>>> really sound like something we can safely ignore?
>>
>> I think you are right to be concerned.  I found the upstream commit that
>> introduced the problem.  See
>> .
>
> *ping*?

Sorry, I've been on holiday.  Will get it sorted this weekend.

Thanks!


signature.asc
Description: PGP signature

Re: Guix beyond 1.0: let’s have a roadmap!

[swedebugia]

On 2019-06-28 18:54, zna...@disroot.org wrote:

** TODO make a wiki online for newcomers
** TODO make some other methods for chatting (for those who use free vpn, tor)


Telegram seems to work well. Only the client is free though.

--
Cheers Swedebugia

Re: Guix beyond 1.0: let’s have a roadmap!

[znavko]

** TODO make a wiki online for newcomers
** TODO make some other methods for chatting (for those who use free vpn, tor)

Re: Guix beyond 1.0: let’s have a roadmap!

[John Soo]

Hi all,

I’m a newcomer of sorts but I would like a programming abstraction over 
profiles. It feels like some requests for better cache file state handling, 
declarative user services, and declarative user packages could be gained. Plus 
I think profiles are still maybe the most confusing thing to a newcomer and 
they are not explicit in the configuration.

- John

> On Jun 27, 2019, at 11:11 PM, Julien Lepiller  wrote:
> 
> Le 28 juin 2019 00:33:12 GMT+02:00, swedebugia  a 
> écrit :
>> On 2019-06-27 21:02, Alex Griffin wrote:
>>> 
>>> ** TODO better Node.js packaging and tooling
>> 
>> This seem to have gotten stuck. But I heard something about a 
>> guile-semver and also we need to handle circular dependencies better in
>> 
>> guix to make it easier to discover and mitigate them.
>> 
>> Compared to the whole expat/JS community Guix is still a very small 
>> project. The bootstrap problems will probably take years to complete 
>> with the current pace/manpower/interest.
>> 
>> Maybe we should propose The GNU Project to create and seek funding for
>> a 
>> "fix JS (bootstrap)" campaign? Compilers will need to be written 
>> according to Julien (like rustc).
> 
> We're good with nust now :). A big issue is coffeescript and probably most of 
> the languages that compile to javascript.
> 
>> 
>>> *** TODO package important Icecat and Ungoogled-Chromium extensions.
>> This is a pain point because IceCat steers users away from Firefox
>> Add-ons and Ungoogled-Chromium completely disallows installing from
>> Chrome Web Store.
>> 
>> Actually currently our Chrome does not support add-ons at all. See bug 
>> #35709
> 
> 

New German PO file for 'guix-manual' (version 1.0.1-pre1)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'guix-manual' has been submitted
by the German team of translators.  The file is available at:

https://translationproject.org/latest/guix-manual/de.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

https://translationproject.org/latest/guix-manual/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/guix-manual.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

New German PO file for 'guix-manual' (version 1.0.1-pre1)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'guix-manual' has been submitted
by the German team of translators.  The file is available at:

https://translationproject.org/latest/guix-manual/de.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

https://translationproject.org/latest/guix-manual/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/guix-manual.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: having trouble modifying guix-daemon

[Robert Vollmert]

Hi,

thanks for the detailed reply.

On 27. Jun 2019, at 17:34, Ludovic Courtès  wrote:
> Robert Vollmert  skribis:
> 
>> I’m trying to investigate why guix-daemon appears to spend
>> a lot of time locking store directories. (It’s possible that
>> it’s doing useful work and just the debug output is useless.)
> 
> Note that there are already quite a few debugging statements that you
> can view by running something like:
> 
>  guix build --debug=5 …

Yes I found that, and the output is not very helpful (yet). I get hundreds
of repetitive

  acquiring write lock on `'
  downgrading to read lock on `'

at the start. By modifying that debug statement, I can now see that at least
these are calls to add roots for different parts — I assume by now that
these are client calls to add-temp-root.

I’d like to improve the debug output here more generally: At (high enough)
debug level, it seems to make sense to log every operation. What I’m unclear
on here is whether it’s better to do that client or server side, what do you
think? The spots would be

(a) nix/nix-daemon/nix-daemon.cc:performOp (inside each start/stopWork pair)
(b) guix/store.scm:operation (next to record-operation)

I have a slight preference for (b) since it avoids the sending data back
and forth.

>> To do this, I’ve tried adding some debug statements to the
>> C++ files in guix/nix/…. I’m having trouble getting those
>> changes live. My understanding is that committing those
>> changes to my configured guix channel, then running
>> 
>> $ guix pull
>> 
>> should rebuild the guix client tools from that repository.
> 
> Unfortunately no.  The ‘guix’ channel is built using (guix self).  That
> module has code to build everything, except the daemon itself; for the
> daemon, it resorts to the ‘guix-daemon’ package of (gnu packages
> package-management).  Thus, changes to the C++ code base do not
> propagate until we update the ‘guix’ and thus the ‘guix-daemon’ package.
> 
> It’s usually not a problem, but it does mean that your use case is not
> supported.
> 
> I would suggest simply building it from a checkout and running it
> directly from there:
> 
>  sudo herd stop guix-daemon
>  sudo -E ./pre-inst-env guix-daemon --build-users-group=guixbuild

Thank you, that works!

>> (Relatedly, two areas where it feels the Guix System feels
>> needlessly confusing:
>> - root guix vs. user guix (and apparently there’s even a
>>  system guix in /var/guix/profiles/system/profile/bin/guix:
>>  does that even get used?
>>  I’d be tempted to simplify this by going for a rootless
>>  setup (i.e., you can’t log in to root account, root has no
>>  home and no profile). Reasons against?
> 
> No, that’s actually what we recommend now—that is, not running ‘guix
> pull’ as root.

Alright. I’ll see if I can figure out how to set up the system without
login-able root account, and might send a patch if successful.

>> - opaque system status: it’s very hard to figure out what
>>  configuration and what versions of programs are current. My
>>  current best attempt is to grep through the output of ps
>>  and then look at those paths in /gnu/store. This is made
>>  worse due to the lack of timestamps in /gnu/store, as I
>>  can’t tell which of the many versions of some package is
>>  the newest just from looking in /gnu/store. Then, the
>>  shepherd configuration is very opaque: I have to follow
>>  through a chain of illegible scheme modules to figure
>>  out what the current configuration is (and then how do
>>  I know I’m even looking at the right shepherd config?).)
> 
> Are you talking about the status of system services specifically?
> For those, my trick is usually to simply look up the command line of
> the service, like so:
> 
> --8<---cut here---start->8---
> $ sudo herd status ssh-daemon
> Status of ssh-daemon:
>  It is started.
>  Running value is 528.
>  It is enabled.
>  Provides (ssh-daemon).
>  Requires (syslogd loopback).
>  Conflicts with ().
>  Will be respawned.
> $ sudo cat /proc/528/cmdline |xargs -0 echo
> /gnu/store/qpvxwh0l5l2vs7m6dnaclb5y5vll0mlg-openssh-8.0p1/sbin/sshd -D -f 
> /gnu/store/0h0lap06j58acndz9agdzf10cj1gqnr8-sshd_config
> --8<---cut here---end--->8---
> 

That’s a bit more precise than what I was doing, thanks. It would be
quite helpful for `herd status` to do that work itself, what do you
think? Also maybe to optionally show the service definition?

(I do still think that having the system configuration stored in a
rather opaque database and only queryable via tools is a disadvantage.
Sort of like how systemd’s binary logging has disadvantages compared to
plain text logfiles in /var/log.)

> For the global profile, you can of course just run:
> 
>  guix package -p /run/current-system/profile -I
> 
> There’s also ‘guix system list-generations’, which prints useful info.

Thanks, interesting. Following the output of these commands, here are two
questions I didn’t manage to an