Re: Booth at FOSDEM (Brussels), 4-5 Feb 2023?

[Julien Lepiller]

Deadline for stands is November 15th. Quoting the website:

FOSDEM 2023 stands call for proposals

Back after two virtual editions, FOSDEM 2023 will take place at the ULB on the 
4th and 5th of February 2023. As has become traditional, we offer free and open 
source projects a stand to display their work “in real life” to the audience. 
You can share information, demo software, interact with your users and 
developers, give away goodies, sell merchandise or accept donations. All is 
possible! 

We offer you: 

One table (180x80cm) with a set of chairs and a power socket.

Fast wireless internet access.

A spot on stands.fosdem.org. 

You can choose if you want the spot for the entire conference, or simply for 
one day. Joint submissions (sharing a table) will be favoured in the process. 

Submit your application at stands.fosdem.org/submission! Deadline closes the 
15th of November; accepted stands will be announced the 1st of December. 

Le 20 octobre 2022 19:36:48 GMT+02:00, zimoun  a 
écrit :
>Hi Julien,
>
>> IIRC, Julien was responsible for a booth at FOSDEM for Linux From
>> Scratch some years ago, so maybe they can share their experience?
>
>I am a bit lost with FOSDEM website, news and deadline.  How does it
>work to ask for a booth?
>
>
>Cheers,
>simon

Pinning package inputs using inferiors?

[Phil]

Hi all,

A change in a package ("dependency" in the below example) in a channel I
own has caused a conflict in another package in the same channel that depends
on it ("test-package" in the below).  Whilst fixing the "test-package"
package is the right solution, this is too complicated in do in the
short-term.  I need to pin "dependency" to v1.0 in test-pacakge's
propagated-inputs. Simultaneously, other packages need the new update to
the "dependency" package to use this functionality to deliver new
functionality that can't wait. 

This isn't a one-off situation; this happens frequently and I'm
interested in how other Guixers resolve this with as little friction to
users as possible?

One brainwave I had was to use inferiors - but this doesn't seem to
work.  Continuing from the above example we could define access to a
historical v1.0 of the dependency package for the test-package like so:

(define dependency-inferior
  ;; An inferior containing dependency v1.0.
  (inferior-for-channels dependency-channels))

If we do this then I can get the below manifest to work, just like the
example in the manual:

(packages->manifest
 (list (specification->package "python") ;; useful for testing
   ;; Remove current dependency add old dependency
   (package/inherit test-package
(propagated-inputs
 (modify-inputs (package-propagated-inputs test-package)
(delete "dependency"
   (car (lookup-inferior-packages dependency-inferior "dependency"
 "1.0"

But this isn't a practical approach - knocking "dependency" out of
test-package's inputs means the unit tests would fail, so I would also
have to delete the check phase - I don't want to do this, it's too much
compromise.

Instead I was hoping to replace the dependency *inside* the package
definition with an inferior like this, so it's still available whilst
the inherited package is being built.

(packages->manifest
 (list (specification->package "python") ;; useful for testing
   ;; Remove current dependency, add old dependency
   (package/inherit test-package
(propagated-inputs
 (modify-inputs (package-propagated-inputs test-package)
(replace "dependency" (car 
(lookup-inferior-packages dependency-inferior "dependency" "1.0"

When I try this, depending what operation I perform on the manifest, I
normally get some type mismatch telling me I've used a package-inferior
when Guile was expecting a package.  Nothing works, alas.

Thus I'm assuming the two types are not completely substitutable, and
this won't work?

Given this, the workaround I am employing is to replace a single package
definition of "dependency" with locally scoped definitions for each
package that uses it.  This is duplication feels suboptimal.

FWIW, a much more involved solution is to store the dependency package
inside test-package's project repo (rather than my channel), and then
automate copying this into the channel at build time.  This is a cool
exercise, but means we are decentralizing the channel's package
definitions and co-locating them across many repos - which feels not in
the spirit of Guix, and more like how requirements.txt files are
co-located in (non-Guix) python projects. 

My questions are:

1. Is my above use of inferiors always doomed, or something we code make
work with changes to Guix core?

2. Is there another way of handling the situation elegantly without
using inferiors or duplicating package definitions at module scope. 


Any advice or comments gladly received!

Cheers,
Phil.

Re: How long does it take to run the full rustc bootstrap chain?

[Efraim Flashner]

On Thu, Oct 20, 2022 at 11:59:34AM +0200, Ludovic Courtès wrote:
> Hi Félix,
> 
> Félix Baylac Jacqué  skribis:
> 
> > I'd be curious to know how long it takes to run the full rustc bootstrap
> > chain on the Guix build farm. I'm sadly not sure how to approach this
> > problem.
> 
> I believe Efraim, Maxim, and probably a few other people have first-hand
> experience building the whole chain.  Any estimate, people?

I have a number! I just pushed a couple of patches to staging to fix the
bootstrap on aarch64, and to decrease the build time and resource usage,
and the numbers are in!

https://ci.guix.gnu.org/build/1632586/details

11863 seconds from downloading mrustc to building rust-1.60, for 198
minutes, or 3.3 hours.

> > Is there a way to extract this information from Cuirass or the Guix data
> > service?
> 
> Maybe not from the Guix Data Service, but most likely from Cuirass and
> the Guix Build Coordinator.
> 
> For example,  shows the
> duration, which could can also get with:
> 
>   wget -qO- https://ci.guix.gnu.org/build/1505621 |jq
> 
> (The (guix ci) module needs an update to let you do access that info
> right from Scheme.)
> 
> Now the /search interface doesn’t have a JSON equivalent, but you can
> find the build ID using something along these lines:
> 
> --8<---cut here---start->8---
> scheme@(guile-user)> ,use(guix ci)
> scheme@(guile-user)> (latest-evaluations "https://ci.guix.gnu.org; 10 #:spec 
> "master")
> $14 = (#< id: 739193 spec: "master" complete?: #t checkouts: 
> (#< commit: "4716cea6256523a8ecf90a426d675bfb7620f3e4" channel: 
> "guix">)> #< id: 738364 spec: "master" complete?: #t checkouts: 
> (#< commit: "16d4ded6302c0650978203d0df83614896c453e8" channel: 
> "guix">)> #< id: 737995 spec: "master" complete?: #t checkouts: 
> (#< commit: "e61660c78f1190c578dd6f202bc5529cbdcff84e" channel: 
> "guix">)> #< id: 737588 spec: "master" complete?: #t checkouts: 
> (#< commit: "88746cd80bc56212ae7922c0fa1cd9a18e44c3bb" channel: 
> "guix">)> #< id: 737529 spec: "master" complete?: #t checkouts: 
> (#< commit: "ac553ba68e535810085dd838e48e4fa6ac553e67" channel: 
> "guix">)> #< id: 736841 spec: "master" complete?: #t checkouts: 
> (#< commit: "7ecd85eacbfa5b7379f563b83807d3e5258cf700" channel: 
> "guix">)> #< id: 734789 spec: "master" complete?: #t checkouts: 
> (#< commit: "3bb145b6e2a8c84e7739ead9ae76dc4d42bb9850" channel: 
> "guix">)> #< id: 734747 spec: "master" complete?: #t checkouts: 
> (#< commit: "033cbd11a837dbc7602799f15d691221653e1996" channel: 
> "guix">)> #< id: 734733 spec: "master" complete?: #t checkouts: 
> (#< commit: "c9eac0c3553703385c997a70741348ae5d34dc68" channel: 
> "guix">)> #< id: 734718 spec: "master" complete?: #t checkouts: 
> (#< commit: "2589997fab07bcebe6d87fd227852389ab5b1962" channel: 
> "guix">)>)
> scheme@(guile-user)> (define jobs (evaluation-jobs "https://ci.guix.gnu.org; 
> (evaluation-id (car $14
> scheme@(guile-user)> (length jobs)
> $15 = 76649
> scheme@(guile-user)> (car jobs)
> $16 = #< build-id: 1627000 status: scheduled name: "0ad.aarch64-linux">
> scheme@(guile-user)> ,use(srfi srfi-1)
> scheme@(guile-user)> (find (lambda (job) (string=? "rust.x86_64-linux" 
> (job-name job))) jobs)
> $17 = #< build-id: 1275492 status: succeeded name: "rust.x86_64-linux">
> scheme@(guile-user)> (job-build "https://ci.guix.gnu.org; $17)
> $18 = #< id: 1275492 derivation: 
> "/gnu/store/dmzhvql66a1n31j2xpygfxpw576wpkwb-rust-1.60.0.drv" evaluation: 
> 579940 system: "x86_64-linux" status: succeeded timestamp: 1662284654 
> start-time: # 9 year: 2022 zone-offset: 7200> stop-time: # minute: 44 hour: 11 day: 4 month: 9 year: 2022 zone-offset: 7200> products: 
> ()>
> --8<---cut here---end--->8---
> 
> That still doesn’t answer your question, because you’re interested in
> the build time of the full Rust bootstrap chain, but that’s a start!
> 
> HTH,
> Ludo’.
> 

-- 
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: Release progress, week 2

[Efraim Flashner]

On Thu, Oct 20, 2022 at 03:49:00PM +0200, Ludovic Courtès wrote:
> Hello!
> 
> Release progress: week 2.
> 
>   • ‘staging’ branch → merged!
> 
> Apparently there’s a regression with Rust no longer being buildable
> on aarch64-linux, but I can’t find a bug report.  Marius?

I can answer this one.

I'm not sure there is a bug report, I didn't see it either. It looks
like when I bumped rust-bootstrap from 1.39 to 1.54 we lost aarch64
support. I've bumped mrustc on staging and successfully performed a
qemu-binfmt build of rust-bootstrap for aarch64 on my x86_64 box. I was
then able to use that to build rust-1.55 on actual aarch64 hardware, so
I assume it's good, I just don't have the hardware to build
rust-bootstrap for aarch64 natively.

With the bump to mrustc I also pushed (a modified version of) Mark's
patches to reduce the resource load of building the rust bootstrap
chain.

Direct links to the build status of rust on staging:
https://ci.guix.gnu.org/build/1632586/details for x86_64
https://ci.guix.gnu.org/build/1628677/details for aarch64

I also tossed in a patch to reduce the verbosity of unpacking rust
crates during the 'configure phase of cargo-build-system.

>   • ‘make assert-binaries-available’ reports 92.7% coverage, slightly
> more than last week, and despite the ‘staging’ merge; details below.
> 
>   • Architectures:
> 
>  - armhf-linux is disabled on ci.guix due to improper offloading
>setup (probably along the lines of
>).  Should we try and reenable
>it, or should we drop it?
> 
>  - powerpc64le-linux is disabled on ci.guix since today
>(maintenance.git commit
>d641115e20973731555b586985fa81fbe293aeca).  However it did work
>until recently and we have one machine to offload to.  Should we
>fix it or drop it?  Mathieu?

What happened to guixp9? I recently used GUIX_DAEMON_SOCKET to have it
build vim, emacs and openssh to help make assert-binaries-available, for
when those are next offloaded to it.

>  - i586-gnu is disabled due to .
>No fix yet, so I may resort to installing the workdaround so we
>can try and build things there.   I believe Chris didn’t hit this
>bug when setting up childhurds on Intel hardware behind
>bordeaux.guix, so substitutes should be coming there.
> 
>   • Installer:
> 
>  - ‘guix system init’ will print progress bars instead of dots
>again (patch available): .
> 
>   • Release issue  still blocked
> by 8 open bugs that we should review!
> 
>   • Others:
> 
>  - Bugs related to grafts were reported and fixed this week:
>  https://issues.guix.gnu.org/58419
>  https://issues.guix.gnu.org/58567
> 
>  - A memory leak of shepherd that manifests on berlin is being
>investigated: .
> 
> Let’s coordinate and focus on these issues!
> 
> Ludo’.
> 
> --8<---cut here---start->8---
> $ make assert-binaries-available 
> Compiling Scheme modules...
> Compiling Scheme modules...
> Compiling Scheme modules...
> Compiling Scheme modules...
> computing 401 package derivations for x86_64-linux...
> looking for 508 store items on https://ci.guix.gnu.org...
> https://ci.guix.gnu.org ☀
>   92.7% substitutes available (471 out of 508)
>   at least 4,332.1 MiB of nars (compressed)
>   6,445.4 MiB on disk (uncompressed)
>   0.026 seconds per request (1.1 seconds in total)
>   38.4 requests per second
> 
>   0.0% (0 out of 37) of the missing items are queued
>   at least 1,000 queued builds
>   x86_64-linux: 1000 (100.0%)
>   build rate: 15.77 builds per hour
>   i686-linux: 2.96 builds per hour
>   x86_64-linux: 9.88 builds per hour
>   aarch64-linux: 3.71 builds per hour
>   armhf-linux: 0.04 builds per hour
> 
> Substitutes are missing for the following items:
>   /gnu/store/885iln2zpcxqvbr35d54bqhzs7l9djmq-libreoffice-7.3.5.2 
>i686-linux
>   /gnu/store/3fbzxn7bmlx7f250n6wdk56fl633giha-mate-1.24.1 
>i686-linux

mate is blocked by some java-12 unpack bug, through a series of packages
to font-abattis-cantarell. I think libreoffice is a plain FTBFS that no
one has sorted out yet.

>   /gnu/store/475m6q7hp7a1gw98ki9l4g04gmvsa75y-xz-5.2.5
>i586-gnu
>   /gnu/store/8fhdpb76nqy3v22jr33j18i1k07rl5n1-xz-5.2.5-static 
>i586-gnu
>   /gnu/store/6dvavfwg4zdih3rlvac4qqkx46my8gl6-tar-1.34
>i586-gnu
>   /gnu/store/sa1ay72axmi9g75sll2wy9cqpfldfy40-gcc-toolchain-12.2.0-debug  
>i586-gnu
>   /gnu/store/qxwclv8hx9z3gqwjil4hpwkwndh6f2zm-gcc-toolchain-12.2.0
>i586-gnu
>   /gnu/store/dypv1jgfzxlkbpp36z393xbdqal1v591-gcc-toolchain-12.2.0-static 
>i586-gnu
>   

Re: Booth at FOSDEM (Brussels), 4-5 Feb 2023?

[Julien Lepiller]

I'll be happy to help!

From my experience with LFS it's important to have enough to share with people. 
We had stickers (obviously), and also bookmarks and even printed versions of 
the book. Even with three people we could manage the stand, but the more we 
are, the easier it becomes. Remember you have to attend the devroom too!

We had issues managing stocks of stickers. Having too many displayed at once 
will incentivise people to take a huge pile to share with friends at home, but 
it also means the stocks deplete quickly :)

One nice thing to have is also a table cloth with our logo/graphics. Some 
distros have live-CDs.

I can take care of ordering that, stickers and anything else if I get 
reimbursed. I can't come up with nice graphics by myself though, so please 
share any ideas :)

Le 20 octobre 2022 16:44:49 GMT+02:00, Jonathan Brielmaier 
 a écrit :
>On 18.10.22 18:59, zimoun wrote:
>> Hi,
>> 
>> As the winter, FOSDEM 2023 is coming…
>> 
>>  https://fosdem.org/2023
>> 
>> 
>> Three questions:
>> 
>>   1. do we run for a booth?
>>   2. who is in?
>>   3. who is volunteer to make that happens?
>
>Count me in as volunteer for the booth. I'll can help from Friday
>afternoon until sunday afternoon/evening.
>
>~Jonathan
>

Re: Creating an Emacs Home Configuration Service

[Liliana Marie Prikler]

Am Sonntag, dem 16.10.2022 um 16:34 -1000 schrieb Zain Jabbar:
> 2. Have Emacs update whenever the =home-environment= is updated.
> Meaning, if I did not add =(service emacs-evil-service-type)= in my
> =home-environment= then obviously =M-x evil-mode= should not work.
> But after adding the service then I want =M-x evil-mode= to work
> without having to restart Emacs. I do not understand the Emacs
> loading system on Guix well enough to know why it does not work.
> Skipping all of the =home-service= stuff, running =guix install
> emacs-evil-mode= then =(guix-emacs-autoload-packages)= does not let
> emacs know that =evil-mode= is installed. I would need to close Emacs
> and start Emacs again for Emacs to know about =evil-mode= being
> installed.
I suggest not doing this; there are good reasons why I disabled it.  If
you still want to, you can instruct your running emacs process to load
$GUIX_PROFILE/share/emacs/site-lisp/subdirs.el and perhaps also (guix-
emacs-autoload-packages).

Cheers

Re: Booth at FOSDEM (Brussels), 4-5 Feb 2023?

[zimoun]

Hi Julien,

> IIRC, Julien was responsible for a booth at FOSDEM for Linux From
> Scratch some years ago, so maybe they can share their experience?

I am a bit lost with FOSDEM website, news and deadline.  How does it
work to ask for a booth?


Cheers,
simon

Re: Release progress, week 2

[Mathieu Othacehe]

Hey,

Thanks for the update!

>  - armhf-linux is disabled on ci.guix due to improper offloading
>setup (probably along the lines of
>).  Should we try and reenable
>it, or should we drop it?
>
>  - powerpc64le-linux is disabled on ci.guix since today
>(maintenance.git commit
>d641115e20973731555b586985fa81fbe293aeca).  However it did work
>until recently and we have one machine to offload to.  Should we
>fix it or drop it?  Mathieu?

Yeah, we only have a single machine to offload to and each time it is
not reachable, the "guix" specification fails on Cuirass.

That's because we need to offload to a powerpc64le-linux machine in
order to evaluate the guix derivation for that specific architecture
(that's true for all the other architectures).

Given the lack of workers for powerpc64le-linux I think we should drop
it. Regarding armhf-linux we can in theory rely on the overdrives but
we are already struggling on aarch64-linux, we I think we should also
drop it for now.

Focusing on x86_64-linux, i686-linux and aarch64-linux for this release
seems more pragmatic.

>  - ‘guix system init’ will print progress bars instead of dots
>again (patch available): .

Just merged the fix that you reviewed :)

>   • Release issue  still blocked
> by 8 open bugs that we should review!

I'll take care of #53194 and #53541. I just closed #52943. It means that
we will have to take care of:

57068 important, Ludovic CourtèsResizing mcron job in vm-image.tmpl 
interferes with settings
53594 important, Guu, Jin-Cheng no matching pattern #

Re: elogind configuration

[Csepp]

Ludovic Courtès  writes:

> Hi,
>
> Antonio Carlos Padoan Junior  skribis:
>
>> I do not know why but "suspend" stopped working on my computer
>> after a recent upgrade (pull & reconfigure).
>
> By that you mean that ‘loginctl suspend’ doesn’t have any effect?
>
> I’ve just tried on my laptop and it works for me with this system
> generation:
>
> $ guix system describe
> Generation 204  Oct 10 2022 00:29:29(current)
>   file name: /var/guix/profiles/system-204-link
>   canonical file name: /gnu/store/yvaj9yi25rm16q9j6jccviaf5i55hk83-system
>   label: GNU with Linux-Libre 5.19.14
>   bootloader: grub-efi
>   root device: label: "root"
>   kernel: 
> /gnu/store/8s41d36dgb700p3g5jbgl5vy7wi7lbsw-linux-libre-5.19.14/bzImage
>   channels:
> guix:
>   repository URL: https://git.savannah.gnu.org/git/guix.git
>   branch: master
>   commit: e827d45db92d6e1f9dc68199cd40cb5d67de9d46
>   configuration file: 
> /gnu/store/p4w6x2q9x9cakslb0n6qcqyydn5y0a8m-configuration.scm
>
>
>> However I'm intrigued because my
>> /run/current-system/profile/etc/elogind/logind.conf
>
> As Tobias wrote, it’s a trap.  :-)
>
> The config file that’s actually use can be found like so:
>
> $ sudo herd status elogind
> Status of elogind:
>   It is started.
>   Running value is 347.
>   It is enabled.
>   Provides (elogind).
>   Requires (dbus-system).
>   Conflicts with ().
>   Will be respawned.
> $ sudo cat /proc/347/environ |xargs -0
> ELOGIND_CONF_FILE=/gnu/store/z14j9xi29aci66d2akcflbgxzwm4lg8q-logind.conf
>
> I guess we could improve that user interface.
>
> Ludo’.

I have that issue on my netbook which uses Slim as a display manager to
launch an i3wm session.  It looks like Slim isn't launching dbus, which
also breaks a host of other things, like managing removable storage
devices.

The problem is not present on my x64 machine where I manually launch Sway
with dbus-run-session.

Re: GNU Mes 0.24.1 released

[Ludovic Courtès]

Hi,

Janneke Nieuwenhuizen  skribis:

>> Janneke Nieuwenhuizen  skribis:
>>
>> This is exciting news!  Looking forward to having full-source
>> bootstrapped AArch64… and it looks like there’s already activity on a
>> ‘wip-’ branch.
>
> Yes, it is!  The ARM bootstrap story is still a bit flakey, as
> stage0-posix does not support ARM.  So, ARM would need
> %bootstrap-mescc-tools and %bootstrap-mes binary seeds...meh.

By “ARM”, you mean the 32-bit ARMv7 ISA, which armhf-linux targets,
right?  (AArch64, aka. ARMv8, is also “ARM”.  :-))

> However, aarch64-linux now bootstraps from 526 bytes all the way until
> gcc-core-mesboot 2,95.3.  Very nice!

Impressive!

> We're still stuck at building a full gcc+glibc combo;
> glibc-mesboot-2.2.5 builds, but possibly not correctly; as the full
> gcc-mesboot0 (2.95.3) build fails at configure time: gcc-core-mesboot0 +
> glibc-mesboot0
>
>?: 0 [execle "./gencheck" # "./gencheck"]
> ERROR: In procedure execle: Exec format error
>
> Not sure what to do here.  We could somehow try to debug/bisect this.
> We could try to use a newer glibc; glibc-2.2.5 happened during the
> OABI/EABI switch and is heavily patched.

This issue is on aarch64-linux?  What does “file gencheck” say?

> Or, we could try to remove glibc-2.2.5/gcc-2.95.3 altogether and aim
> for a direct tcc => gcc-4.6.4.  We need to go that way anyway for
> RISCV.

That sounds like the best approach longer-term, but possibly more work
than figuring out the issue above?

Thanks,
Ludo’.

Re: Booth at FOSDEM (Brussels), 4-5 Feb 2023?

[Ludovic Courtès]

Hello!

zimoun  skribis:

> As the winter, FOSDEM 2023 is coming…
>
> https://fosdem.org/2023
>
>
> Three questions:
>
>  1. do we run for a booth?
>  2. who is in?
>  3. who is volunteer to make that happens?

Having a booth can be a way to have informal conversations with folks
who are curious about Guix or haven’t heard about it before.

IIRC, Julien was responsible for a booth at FOSDEM for Linux From
Scratch some years ago, so maybe they can share their experience?

For this to be viable, I suppose there needs to be about at the very
least 4 people (that’d still be half a day each!).  However,
pre-pandemic, there would usually be somewhere between 20 and 40 Guix
people joining, so I’m sure 10 of us or so could take care of the booth
for a couple of hours.

Thanks,
Ludo’.

Re: Booth at FOSDEM (Brussels), 4-5 Feb 2023?

[Jonathan Brielmaier]

On 18.10.22 18:59, zimoun wrote:

Hi,

As the winter, FOSDEM 2023 is coming…

 https://fosdem.org/2023


Three questions:

  1. do we run for a booth?
  2. who is in?
  3. who is volunteer to make that happens?


Count me in as volunteer for the booth. I'll can help from Friday
afternoon until sunday afternoon/evening.

~Jonathan

Re: Creating an Emacs Home Configuration Service

[Ludovic Courtès]

Hi,

Zain Jabbar  skribis:

> Thank you for showcasing Andrew Tropin's rde project. I believe the
> =features= abstraction have potential and make more intuitive sense
> for the design of configurable programs. There is a lot for me to
> learn from this design choice.
>
> As it stands, =features= are not in Guix proper, are there plans to
> merge them? How will they end up relating to the existing home
> services feature set?

I don’t think merging “features” into Guix has been discussed before.
It does sound like a logical next step to declarative configuration, but
I don’t have any experience to really say.

Anyway, I think the first step for Emacs configuration with Home is a
‘home-emacs-service-type’, possibly based on/inspired by the one in rde
that Andrew mentions.

Thanks,
Ludo’.

Re: crate importer throws

[Csepp]

Efraim Flashner  writes:

> [[PGP Signed Part:Undecided]]
> On Sat, Oct 15, 2022 at 02:58:53PM +0200, Csepp wrote:
>> 
>> Maxime Devos  writes:
>> 
>> > Could you check if
>> >
>> > $ guix shell --pure -- "$(which guix)" import crate the-way
>> >
>> > (i.e. a pure environment without any packages) works for you?  Maybe
>> > somehow there is some other guile-semver in your usual environment
>> > that breaks Guix.
>> 
>> Weirdly enough it works.
>> ...oh it also works without importing guile-semver.
>> HhmmMM!
>> Maybe my channels config makes a difference?
>
> More likely something in your .bashrc

It's a standard Guix System bashrc and bash_profile.
...oh, I actually use zsh, so not sure why I even checked that.  But
yeah, that is not customized much either, I just added the GRML config.

Re: GNU Mes 0.24.1 released

[Jan Nieuwenhuizen]

Efraim Flashner writes:

Hi Efraim,

> On Wed, Oct 19, 2022 at 09:41:20PM +0200, Janneke Nieuwenhuizen wrote:
>
> Which hardware are you building on? On my pine64 I'm getting stuck at
> tcc-0.9.26-1134-g80114c4d
> On commit 519f4c8c9a0b191e9a447116685393c2fed4cd3b
>
> starting phase `build'
>   CCLD   mes-tcc
> mkdir -p 
> /gnu/store/d3kcgm0z3yyc7bplaacr7g0j8gk36h5j-tcc-boot0-0.9.26-1134-g80114c4d/lib/tcc
> rm -f crt1.o;
> cp -f /gnu/store/nli76zd955d9xksy01qrfzlizq4c28kd-mes-boot-0.24.1//lib/crt1.c 
> .
> crt1.c:149: warning: implicit declaration of function 'main'
> rm -f crti.o;
> cp -f /gnu/store/nli76zd955d9xksy01qrfzlizq4c28kd-mes-boot-0.24.1//lib/crti.c 
> .
> rm -f crtn.o;
> cp -f /gnu/store/nli76zd955d9xksy01qrfzlizq4c28kd-mes-boot-0.24.1//lib/crtn.c 
> .
> rm -f libc.a
> cp -f 
> /gnu/store/nli76zd955d9xksy01qrfzlizq4c28kd-mes-boot-0.24.1//lib/libc+gnu.c 
> libc.c
> error: in phase 'build': uncaught exception:
> srfi-34 # exit-status: 1 term-signal: #f stop-signal: #f] 10f6100>
> phase `build' failed after 21994.9 seconds

Oops.  Not sure what happened on my side, but yeah this error reproduces
for me.  I've pushed an updated tcc-boot0 to wip-aarch64-bootstrap.

Greetings,
Janneke

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

Re: https://guix.gnu.org/ is offline

[Ludovic Courtès]

Hi!

Tobias Geerinckx-Rice  skribis:

> Thanks!  You can follow along with debugging at
> .

It looks quite scary but there’s a lot of fun to be had.  Join me!
:-)

Ludo’.

Release progress, week 2

[Ludovic Courtès]

Hello!

Release progress: week 2.

  • ‘staging’ branch → merged!

Apparently there’s a regression with Rust no longer being buildable
on aarch64-linux, but I can’t find a bug report.  Marius?

  • ‘make assert-binaries-available’ reports 92.7% coverage, slightly
more than last week, and despite the ‘staging’ merge; details below.

  • Architectures:

 - armhf-linux is disabled on ci.guix due to improper offloading
   setup (probably along the lines of
   ).  Should we try and reenable
   it, or should we drop it?

 - powerpc64le-linux is disabled on ci.guix since today
   (maintenance.git commit
   d641115e20973731555b586985fa81fbe293aeca).  However it did work
   until recently and we have one machine to offload to.  Should we
   fix it or drop it?  Mathieu?

 - i586-gnu is disabled due to .
   No fix yet, so I may resort to installing the workdaround so we
   can try and build things there.   I believe Chris didn’t hit this
   bug when setting up childhurds on Intel hardware behind
   bordeaux.guix, so substitutes should be coming there.

  • Installer:

 - ‘guix system init’ will print progress bars instead of dots
   again (patch available): .

  • Release issue  still blocked
by 8 open bugs that we should review!

  • Others:

 - Bugs related to grafts were reported and fixed this week:
 https://issues.guix.gnu.org/58419
 https://issues.guix.gnu.org/58567

 - A memory leak of shepherd that manifests on berlin is being
   investigated: .

Let’s coordinate and focus on these issues!

Ludo’.

--8<---cut here---start->8---
$ make assert-binaries-available 
Compiling Scheme modules...
Compiling Scheme modules...
Compiling Scheme modules...
Compiling Scheme modules...
computing 401 package derivations for x86_64-linux...
looking for 508 store items on https://ci.guix.gnu.org...
https://ci.guix.gnu.org ☀
  92.7% substitutes available (471 out of 508)
  at least 4,332.1 MiB of nars (compressed)
  6,445.4 MiB on disk (uncompressed)
  0.026 seconds per request (1.1 seconds in total)
  38.4 requests per second

  0.0% (0 out of 37) of the missing items are queued
  at least 1,000 queued builds
  x86_64-linux: 1000 (100.0%)
  build rate: 15.77 builds per hour
  i686-linux: 2.96 builds per hour
  x86_64-linux: 9.88 builds per hour
  aarch64-linux: 3.71 builds per hour
  armhf-linux: 0.04 builds per hour

Substitutes are missing for the following items:
  /gnu/store/885iln2zpcxqvbr35d54bqhzs7l9djmq-libreoffice-7.3.5.2   
 i686-linux
  /gnu/store/3fbzxn7bmlx7f250n6wdk56fl633giha-mate-1.24.1   
 i686-linux
  /gnu/store/475m6q7hp7a1gw98ki9l4g04gmvsa75y-xz-5.2.5  
 i586-gnu
  /gnu/store/8fhdpb76nqy3v22jr33j18i1k07rl5n1-xz-5.2.5-static   
 i586-gnu
  /gnu/store/6dvavfwg4zdih3rlvac4qqkx46my8gl6-tar-1.34  
 i586-gnu
  /gnu/store/sa1ay72axmi9g75sll2wy9cqpfldfy40-gcc-toolchain-12.2.0-debug
 i586-gnu
  /gnu/store/qxwclv8hx9z3gqwjil4hpwkwndh6f2zm-gcc-toolchain-12.2.0  
 i586-gnu
  /gnu/store/dypv1jgfzxlkbpp36z393xbdqal1v591-gcc-toolchain-12.2.0-static   
 i586-gnu
  /gnu/store/7bx9jykip9lc13yn2bck1m4q8ccds1mz-make-4.3-debug
 i586-gnu
  /gnu/store/422i4q46cisabwsxrs7raf67awwwzsys-make-4.3  
 i586-gnu
  /gnu/store/f8jsczp72i49c79rjf8nv2q6jskqa5vy-gawk-5.1.0
 i586-gnu
  /gnu/store/d646qvpcdi0l9r2mqhqkxkrgwm0b50qh-findutils-4.8.0   
 i586-gnu
  /gnu/store/zb0zbds0k2vjnln88dp4paldghl2mdwv-grep-3.6  
 i586-gnu
  /gnu/store/62hb8sk7vnz26flasklrm0x0yh5pdnq4-coreutils-8.32-debug  
 i586-gnu
  /gnu/store/fmk805j58dig4076wy8q6fj1w47jxaw1-coreutils-8.32
 i586-gnu
  /gnu/store/kgz0xm0c05ys92nkg07l7lbbikrx7hia-guix-1.3.0-31.3170843 
 armhf-linux
  /gnu/store/nz1rw5cfrh4z3bl7fm2qsvxxpl955cqh-guile-3.0.8-debug 
 armhf-linux
  /gnu/store/zmk1kmfk7wxm5w3ambajgnx7b0s5iq84-guile-3.0.8   
 armhf-linux
  /gnu/store/26yb2pj71wg9cywmhpmsf6n1d81i43c5-python-3.9.9-idle 
 armhf-linux
  /gnu/store/dh5rr8gd148afs3jzijs8i9gfwwi6igz-python-3.9.9  
 armhf-linux
  /gnu/store/x0yzk738mm4if6kbc8i8q7x3ajz2rd27-python-3.9.9-tk   
 armhf-linux
  /gnu/store/5p9jplb7hzci9nrpk4nxqa7qlyfb6wji-vim-9.0.0719  
 armhf-linux
  /gnu/store/kxzqk19zm8y8dchcgx0izhwhfmzxwdmi-emacs-no-x-28.2   
 armhf-linux
  /gnu/store/3ss4kln2a69xfja55wbi46pr1nsjbngr-openssh-8.9p1 
 armhf-linux
  

Re: How long does it take to run the full rustc bootstrap chain?

[Ludovic Courtès]

Hi Félix,

Félix Baylac Jacqué  skribis:

> I'd be curious to know how long it takes to run the full rustc bootstrap
> chain on the Guix build farm. I'm sadly not sure how to approach this
> problem.

I believe Efraim, Maxim, and probably a few other people have first-hand
experience building the whole chain.  Any estimate, people?

> Is there a way to extract this information from Cuirass or the Guix data
> service?

Maybe not from the Guix Data Service, but most likely from Cuirass and
the Guix Build Coordinator.

For example,  shows the
duration, which could can also get with:

  wget -qO- https://ci.guix.gnu.org/build/1505621 |jq

(The (guix ci) module needs an update to let you do access that info
right from Scheme.)

Now the /search interface doesn’t have a JSON equivalent, but you can
find the build ID using something along these lines:

--8<---cut here---start->8---
scheme@(guile-user)> ,use(guix ci)
scheme@(guile-user)> (latest-evaluations "https://ci.guix.gnu.org; 10 #:spec 
"master")
$14 = (#< id: 739193 spec: "master" complete?: #t checkouts: 
(#< commit: "4716cea6256523a8ecf90a426d675bfb7620f3e4" channel: 
"guix">)> #< id: 738364 spec: "master" complete?: #t checkouts: 
(#< commit: "16d4ded6302c0650978203d0df83614896c453e8" channel: 
"guix">)> #< id: 737995 spec: "master" complete?: #t checkouts: 
(#< commit: "e61660c78f1190c578dd6f202bc5529cbdcff84e" channel: 
"guix">)> #< id: 737588 spec: "master" complete?: #t checkouts: 
(#< commit: "88746cd80bc56212ae7922c0fa1cd9a18e44c3bb" channel: 
"guix">)> #< id: 737529 spec: "master" complete?: #t checkouts: 
(#< commit: "ac553ba68e535810085dd838e48e4fa6ac553e67" channel: 
"guix">)> #< id: 736841 spec: "master" complete?: #t checkouts: 
(#< commit: "7ecd85eacbfa5b7379f563b83807d3e5258cf700" channel: 
"guix">)> #< id: 734789 spec: "master" complete?: #t checkouts: 
(#< commit: "3bb145b6e2a8c84e7739ead9ae76dc4d42bb9850" channel: 
"guix">)> #< id: 734747 spec: "master" complete?: #t checkouts: 
(#< commit: "033cbd11a837dbc7602799f15d691221653e1996" channel: 
"guix">)> #< id: 734733 spec: "master" complete?: #t checkouts: 
(#< commit: "c9eac0c3553703385c997a70741348ae5d34dc68" channel: 
"guix">)> #< id: 734718 spec: "master" complete?: #t checkouts: 
(#< commit: "2589997fab07bcebe6d87fd227852389ab5b1962" channel: 
"guix">)>)
scheme@(guile-user)> (define jobs (evaluation-jobs "https://ci.guix.gnu.org; 
(evaluation-id (car $14
scheme@(guile-user)> (length jobs)
$15 = 76649
scheme@(guile-user)> (car jobs)
$16 = #< build-id: 1627000 status: scheduled name: "0ad.aarch64-linux">
scheme@(guile-user)> ,use(srfi srfi-1)
scheme@(guile-user)> (find (lambda (job) (string=? "rust.x86_64-linux" 
(job-name job))) jobs)
$17 = #< build-id: 1275492 status: succeeded name: "rust.x86_64-linux">
scheme@(guile-user)> (job-build "https://ci.guix.gnu.org; $17)
$18 = #< id: 1275492 derivation: 
"/gnu/store/dmzhvql66a1n31j2xpygfxpw576wpkwb-rust-1.60.0.drv" evaluation: 
579940 system: "x86_64-linux" status: succeeded timestamp: 1662284654 
start-time: # stop-time: # products: ()>
--8<---cut here---end--->8---

That still doesn’t answer your question, because you’re interested in
the build time of the full Rust bootstrap chain, but that’s a start!

HTH,
Ludo’.

Re: Creating an Emacs Home Configuration Service

[Andrew Tropin]

On 2022-10-19 10:53, Zain Jabbar wrote:

> Aloha All,
>
> Super awesome to hear from you! I'm quite star stuck.
>
> Thank you for showcasing Andrew Tropin's rde project. I believe the
> =features= abstraction have potential and make more intuitive sense
> for the design of configurable programs. There is a lot for me to
> learn from this design choice.
>
> As it stands, =features= are not in Guix proper, are there plans to
> merge them?

There was no plan to merge this mechanism to Guix proper and I think
it's actually good to maintain this as a separate project/guix channel,
however it is discussable.  Features itself are quite opinionated and
doesn't fit general-purpose nature of the Guix IMO, so I don't think we
(Guix devs) want to merge them.

> How will they end up relating to the existing home services feature
> set?

rde features are basically wrappers around home and system services,
which allows to share values among those services, also it allows to
implement polymorphic behavior.

You can trace origins somewhere in rde-devel mailing list:
https://lists.sr.ht/~abcdw/rde-devel/%3C87sg56g97i.fsf%40trop.in%3E

Because rde features are a user-facing interface, and services mechanism
is slightly hidden underneath, rde's home and system services are less
suitable for end-user, but more flexible.  We (rde devs) usually don't
use records, which help to define rigid config structure, provide
autocompletion, field existence and type checks, and other benifits, but
provide sxml or other sexp based representation of underlying
configuration formats.

BTW, there is an emacs-home-service-type in rde:
https://git.sr.ht/~abcdw/rde/tree/59a2c1ef615aac7c5dac08660bd00ea5873e77b7/rde/home/services/emacs.scm#L20

and you can find various usage examples in people's configuration or in
rde/feature/emacs* modules.
https://git.sr.ht/~krevedkokun/dotfiles/tree/master/item/config/home/yggdrasil/emacs.scm
https://git.sr.ht/~akagi/guixrc/tree/master/item/magi/home/emacs.scm
https://git.sr.ht/~abcdw/rde/tree/master/item/rde/features/emacs.scm
https://git.sr.ht/~abcdw/rde/tree/master/item/rde/features/emacs-xyz.scm

>
> On Wed, Oct 19, 2022 at 5:36 AM Ludovic Courtès  wrote:
>>
>> Hi Zain, and welcome!
>>
>> Zain Jabbar  skribis:
>>
>> > Running =guix home search emacs= returns nothing. I also could not find an
>> > email using =C-u M-x debbugs-gnu= about an Emacs configuration service.
>> >
>> > This is my first email to this mailing address. Please give me pointers on
>> > formatting and further improvements.
>> >
>> > I have attempted to make an =emacs-home-service-type= so that it is
>> > possible to configure Emacs using Guix home. This code is extremely
>> > preliminary hence I don't even think it is worth sending as a patch. Also I
>> > have never worked on a multi person Git project before and do not know how
>> > to solve the keyring error I get when using guix pull. I will outline what
>> > my code does and what features I would like to add.
>>
>> I am all for something like you describe, and the code you sent may be
>> good starting point!
>>
>> The rde project¹ by Andrew Tropin et al. may be a good source of
>> inspiration.  The “features” abstraction in particular seems to be
>> well-suited for Emacs.  But overall it’s reasonable to start small, with
>> a low-level approach to combine and configure Emacs packages.
>>
>> Thanks,
>> Ludo’.
>>
>> ¹ https://trop.in/rde/manual

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature