Re: Cross-compilation broken on canonical packages.
Hey Ludo, > Do we need to do it for ‘lower-object’? I think that one is (almost) > always called from a gexp compiler where it’s explicitly passed ‘system’ > and ‘target’. Yes because of lower-object call in "system-derivation" procedure of (gnu services). > Also, a test or two would be welcome as it’s easy to break it without > noticing. > > Otherwise LGTM, thank you, and sorry for the delay! Pushed with a few tests on core-updates, thanks for reviewing! Mathieu
Re: System test manifest
Thanks! Ludovic Courtès writes: > There are probably a couple of things to > improve in ‘guix weather’ to make it more convenient, such as adding a > flag to list missing substitutes. That'd be great indeed! > My next goal is to have a manifest for “release-critical things” that > one can again pass to ‘guix build’ or ‘guix weather’ to have an > immediate picture of the “releasability” status. Do we already know what the critical things are? I guess we need a list of popular packages, right? Maybe this? https://pkgstats.archlinux.de/packages -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: Plan for a release!
Hi Guix, In addition I think issue #38544 (gparted segfaults) should be addressed before a release. I would imagine that partitioning is an activity that happens a lot around new installs. - John
`guix build hello' now succeeds on the Hurd
Hi Guix! The situation on the Hurd starts to look pretty good janneke@debian:~/src/guix$ ./pre-inst-env guix build hello --no-offload /gnu/store/a2sylb94rm1b6qxcp5mqvgiyx9szipz7-hello-2.10 janneke@debian:~/src/guix$ /gnu/store/a2sylb94rm1b6qxcp5mqvgiyx9szipz7-hello-2.10/bin/hello Hello, world! \o/ Current development lives on the `wip-hurd-bootstrap' branch @ my personal gitlab https://gitlab.com/janneke/guix #wip-hurd-bootstrap It has some 20 odd patches. I chose to create workarounds to "get early success" rather than doing everything right. While I worked on forward porting glibc patches, I only took the minimal set that I needed. Also, I reverted to make 4.1 instead of debugging why make 4.3 fails (for now). Most controversial/problematic is the need to use fairly recent gnumach and hurd sources. Somehow the bootstrap in commencement currently tries to usee GIT versions of those (gnumach-headers-boot0, hurd-headers-boot0), creating a bootstrap dependency loop. I tried building from release tarballs with patches but in the end I "simply" ran `make dist' for gnumach and hurd and use those source tarballs. I have built bootstrap tarballs ./pre-inst-env guix build --target=i586-pc-gnu bootstrap-tarballs and put them up at http://lilypond.org/janneke/guix/i586-gnu/20200304/ Gnumach and Hurd tarball sources are here http://lilypond.org/janneke/hurd I have included my setup/install instructions in Git https://gitlab.com/janneke/guix/-/blob/wip-hurd-bootstrap/THE-HURD What could be the next step? We have a stale branch `wip-hurd' at savannah by Manolis and Efraim's recent wip-hurd-bootstrap (which I started from, but rewrote). Shall I push this to savannah as `wip-hurd' (possibly save wip-hurd-> `wip-hurd-old?); I could also rewrite wip-hurd-bootstrap? When we mave a branch I'd like to open a bug report on merging it, and setting up build hosts (as discussed with Ricardo on IRC). Greetings, janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: `guix build hello' now succeeds on the Hurd
Congratulations!! On Fri, 2020-03-06 at 11:15 +0100, Jan Nieuwenhuizen wrote: > Hi Guix! > > The situation on the Hurd starts to look pretty good > > janneke@debian:~/src/guix$ ./pre-inst-env guix build hello --no-offload > /gnu/store/a2sylb94rm1b6qxcp5mqvgiyx9szipz7-hello-2.10 > janneke@debian:~/src/guix$ /gnu/store/a2sylb94rm1b6qxcp5mqvgiyx9szipz7- > hello-2.10/bin/hello > Hello, world! > > \o/ > > Current development lives on the `wip-hurd-bootstrap' branch @ my > personal gitlab > > https://gitlab.com/janneke/guix #wip-hurd-bootstrap > > It has some 20 odd patches. I chose to create workarounds to "get early > success" rather than doing everything right. While I worked on forward > porting glibc patches, I only took the minimal set that I needed. Also, > I reverted to make 4.1 instead of debugging why make 4.3 fails (for > now). > > Most controversial/problematic is the need to use fairly recent gnumach > and hurd sources. Somehow the bootstrap in commencement currently tries > to usee GIT versions of those (gnumach-headers-boot0, > hurd-headers-boot0), creating a bootstrap dependency loop. I tried > building from release tarballs with patches but in the end I "simply" > ran `make dist' for gnumach and hurd and use those source tarballs. > > I have built bootstrap tarballs > > ./pre-inst-env guix build --target=i586-pc-gnu bootstrap-tarballs > > and put them up at > > http://lilypond.org/janneke/guix/i586-gnu/20200304/ > > Gnumach and Hurd tarball sources are here > > http://lilypond.org/janneke/hurd > > I have included my setup/install instructions in Git > > https://gitlab.com/janneke/guix/-/blob/wip-hurd-bootstrap/THE-HURD > > What could be the next step? We have a stale branch `wip-hurd' at > savannah by Manolis and Efraim's recent wip-hurd-bootstrap (which I > started from, but rewrote). > > Shall I push this to savannah as `wip-hurd' (possibly save wip-hurd-> > `wip-hurd-old?); I could also rewrite wip-hurd-bootstrap? > > When we mave a branch I'd like to open a bug report on merging it, > and setting up build hosts (as discussed with Ricardo on IRC). > > Greetings, > janneke >
[GSOC 2020] Introduction and asking for feedback
Hello everyone, My name is Alberto Flores, I am an student from Mexico, I've been part of the #guix IRC channel as 'happy_gnu' and 'Blackbeard'. I've used Guix for a few years, both as a package manager and distribution. I want to apply to Google Summer of Code. The ideas I am most interested are a) for GNU Guix: 'Content-addressed protocol for substitutes' and b) for GNU Shepherd: "Syntax and semantics of systemd units in the Shepherd", because I have a feeling any of this two would improve the experience of most Guix users. However, I would like to ask for feedback in which might be a better option, I would like to chose a project that I can get help and the community is interested in. Any help with the project and proposal would be much appreciated. I am open for other ideas too. I know Christopher Webber started a thread about Guile based build-tool and it looks great, but it seems like a huge project for me and I would not like to fail in case I were accepted. On other notes, I'll be sending my first patch this weekend, I packaged the game widelands and it works, hopefully it will be accepted. I also plan to send patches to the manual, and participate as much as I can. Thank you all for your feedback and comments. Alberto
Re: 01/02: gnu: fmt: Use HTTPS and git-fetch.
Hello Pierre, guix-comm...@gnu.org writes: > ambrevar pushed a commit to branch master > in repository guix. > > commit 744f445c920f60e9080f42866c802184a1503a80 > Author: Pierre Neidhardt > AuthorDate: Thu Mar 5 10:34:21 2020 +0100 > > gnu: fmt: Use HTTPS and git-fetch. > > * gnu/packages/pretty-print.scm (fmt)[source]: Use git-fetch. > [home-page]: Use HTTPS. Why change to git-fetch here, when upstream provides a zipball? The unzip input can be removed now, I guess. signature.asc Description: PGP signature
Re: `guix build hello' now succeeds on the Hurd
Hi Jan, Le 03/06, Jan Nieuwenhuizen a écrit : > The situation on the Hurd starts to look pretty good > > janneke@debian:~/src/guix$ ./pre-inst-env guix build hello --no-offload > /gnu/store/a2sylb94rm1b6qxcp5mqvgiyx9szipz7-hello-2.10 > janneke@debian:~/src/guix$ > /gnu/store/a2sylb94rm1b6qxcp5mqvgiyx9szipz7-hello-2.10/bin/hello > Hello, world! > > \o/ Congrats'! I've been a Hurd enthusiast for quite a long time and I thank you for this work! Cheers! -- Tanguy
Re: planned downtime for ci.guix.gnu.org this Friday
Ricardo Wurmus writes: > on Friday (March 6) the head node and the big storage for > ci.guix.gnu.org will need to be moved to a different aisle in the MDC > data centre. This will require a short downtime as we need to shut off > ci.guix.gnu.org for a little while. We will also take some time to > apply firmware updates, which will delay the reboot. > > We expect that this will take less than a day. ci.guix.gnu.org has been moved successfully and is back online now. -- Ricardo
Re: Plan for a release!
sirgazil writes: > > I'm not sure, but the problem of launching applications from > application menus may be related to the issue of launching > applications when double-clicking files in file managers (Thunar, > Caja, etc.) when there is more than one Desktop Environment or Window > Manager available. Could you please check > https://issues.guix.gnu.org/issue/39843 and see if you get the same > behavior? If so, it would be helpful if you could report your > experience in that bug report as well. Sure. I'll add it to my schedule. > > > Joshua > > > > 1. I wish I knew how I could have reconfigured my laptop instead of > reinstalling everything. I > > tried this. > > > > chroot /mnt; > > guix system reconfigure /mnt/etc/config.scm; > > I may be missing something from previous messages to the list, but to > reconfigure the Guix System you can copy the system configuration file > in "/etc/config.scm" save it wherever you want, modify it to your > liking (e.g. adding or removing more packages or services), and then > > $ guix pull > $ sudo guix system reconfigure /path/to/your/config.scm > My problem was that I could not do a guix pull, because I could not boot into the laptop. Grub would load, and display Guix System boot option, but after that it would show a blank screen. Essentially how do you fix a laptop that will not boot guix, via a guix usb install image? -- Joshua Branson Sent from Emacs and Gnus
Re: Plan for a release!
Jan writes: > On Thu, 05 Mar 2020 13:42:29 + > jbra...@dismail.de wrote: > >> tl;dr Xfce worked fine, and MATE failed to launch any applications. >> > > Hello everyone, > > actually Xfce has been broken for several months already, was too lazy > to report the issue and another one got 0 replies. Oh really? I had no issue with Xfce. > > The first issue: > When right clicking at a file in Thunar and running "open with", an > error window appears telling it couldn't run "gio-launch-desktop" child > process, because it couldn't find such a file or directory. > > The second issue: > When trying to run an application using xfce panel, it throws an error > "Couldn't run /gnu/store/-exo-0.12.6/bin/exo-open --launch > TerminalEmulator" It can't find the file/directory. > > Hope this helps. > > Jan Wielkiewicz -- Joshua Branson Sent from Emacs and Gnus
Thunar cannot launch gio-launch-desktop
Jan writes: > The first issue: > When right clicking at a file in Thunar and running "open with", an > error window appears telling it couldn't run "gio-launch-desktop" child > process, because it couldn't find such a file or directory. Maybe Thunar needs to be wrapped with glib:bin, which provides gio-launch-desktop. Would you like to give this a try? -- Ricardo
Re: 01/02: gnu: fmt: Use HTTPS and git-fetch.
Pierre Neidhardt writes: > Duh, I confused these with the github generated archive, sorry about > that. > > Is there any preference between git-fetch and url-fetch? url-fetch requires less bandwidth, and does not depend on 'git'. Though the most important distinction is that uploaded releases sometimes contain pre-processed sources (e.g. documentation) that need additional dependencies or scripts when building from the raw repository (this is why you often need to add autoconf, libtool & friends as inputs when building Autotools projects from git). I don't know whether there is a difference between the uploaded fmt zipball and the git repository. signature.asc Description: PGP signature
Re: Thunar cannot launch gio-launch-desktop
On Fri, 06 Mar 2020 17:51:46 +0100 Ricardo Wurmus wrote: > > Maybe Thunar needs to be wrapped with glib:bin, which provides > gio-launch-desktop. Would you like to give this a try? The only thing that comes to my mind when someone says "wrapper" is tortilla with chicken, but I can try tinkering with it. > -- > Ricardo Jan Wielkiewicz
Re: 02/02: gexp: Default to current target.
Hi Mathieu, guix-comm...@gnu.org skribis: > mothacehe pushed a commit to branch core-updates > in repository guix. > > commit a6bf7a9745f39afca7412f6627d24dc42ebf8075 > Author: Mathieu Othacehe > AuthorDate: Fri Mar 6 10:06:54 2020 +0100 > > gexp: Default to current target. > > * guix/gexp.scm (lower-object): Set target argument to 'current by > default and > look for the current target system at bind time if needed, > (gexp->file): ditto, > (gexp->script): ditto, > (lower-gexp): make sure lowered extensions are not cross-compiled. > > * tests/gexp.scm: Add cross-compilation test-cases for gexp->script and > gexp->file with a target passed explicitely and with a default target. Could you push to ‘master’ as well? In general, to minimize the risks of merge conflicts, I’m all for pushing things on ‘master’ only (unless they entail full rebuilds of course.) Eventually, they get merged to ‘core-updates’, ‘staging’, etc. Thanks, Ludo’.
Re: branch core-updates updated: gnu: guix: Fix cross-compilation.
Hi, it’s me again! :-)
guix-comm...@gnu.org skribis:
> commit b4335cfb55ced138ce07cf5d0a29c06fa6e6d1c5
> Author: Mathieu Othacehe
> AuthorDate: Fri Mar 6 13:49:40 2020 +0100
>
> gnu: guix: Fix cross-compilation.
>
> * gnu/packages/package-management.scm (guix)[native-inputs]: Add all Guile
> libraries to fix cross-compilation.
[...]
>(native-inputs `(("pkg-config" ,pkg-config)
>
> + ;; Guile libraries are needed here for
> + ;; cross-compilation.
> + ("guile" ,guile-2.2)
> + ("gnutls" ,gnutls)
> + ("guile-gcrypt" ,guile-gcrypt)
> + ("guile-json" ,guile-json-3)
> + ("guile-sqlite3" ,guile-sqlite3)
> + ("guile-ssh" ,guile-ssh)
> + ("guile-git" ,guile-git)
I suppose we need to adjust ‘guile3.0-guix’ as well, and perhaps
‘guix-daemon’ too?
Ludo’.
"make dist" broken by German cookbook translation
It looks like the commit adding the German translation for the cookbook f98e83a17fa30587520e858231ec9c61f3624ecd broke "make dist". in an environment built using: guix environment --pure guix --ad-hoc git imagemagick running: ./bootstrap && ./configure --localstatedir=/var && make -j4 && make doc-pot-update && make -j4 dist Results in: make[1]: Leaving directory '/home/vagrant/src/guix-tarball' for f in po/doc/guix-manual.de.po; do \ lang="`echo "$f" | /gnu/store/zsq3ficl0hmid7aw50qma1ixmbs0jzq9-profile/bin/sed -es'|.*/guix-cookb\ ook\.\(.*\)\.po$|\1|g'`";\ make "doc-po-update-cookbook-$lang"; \ done make[1]: Entering directory '/home/vagrant/src/guix-tarball' make[1]: *** No rule to make target 'doc-po-update-cookbook-po/doc/guix-manual.de.po'. Stop. make[1]: Leaving directory '/home/vagrant/src/guix-tarball' make: *** [Makefile:5735: doc-po-update] Error 2 I haven't tracked down how to fix it properly, but it looks like maybe some rules from guix-manual maybe were copied from the cookbook without sufficiently being adjusted? Reverting the commit works around the issue and generates a tarball, though with the obvious downside of the German translation missing. live well, vagrant signature.asc Description: PGP signature
Re: "make dist" broken by German cookbook translation
On Fri, Mar 06, 2020 at 11:19:27AM -0800, Vagrant Cascadian wrote: > It looks like the commit adding the German translation for the cookbook > f98e83a17fa30587520e858231ec9c61f3624ecd broke "make dist". > Sorry! I should have tested more. Fixed in 895e6e8af657d28527f7cccf68eab7319f50fba5. Regards, Florian
Re: planned downtime for ci.guix.gnu.org this Friday
On 3/6/20 10:45 AM, Ricardo Wurmus wrote: It is too bad that it continues to have that post assualting Richard Stallman's crditbility. You would help your project a great deal to remove that from your blog. Aviva > Ricardo Wurmus writes: > >> on Friday (March 6) the head node and the big storage for >> ci.guix.gnu.org will need to be moved to a different aisle in the MDC >> data centre. This will require a short downtime as we need to shut off >> ci.guix.gnu.org for a little while. We will also take some time to >> apply firmware updates, which will delay the reboot. >> >> We expect that this will take less than a day. > ci.guix.gnu.org has been moved successfully and is back online now. >
Re: Thunar cannot launch gio-launch-desktop
Jan writes: > On Fri, 06 Mar 2020 17:51:46 +0100 > Ricardo Wurmus wrote: > >> >> Maybe Thunar needs to be wrapped with glib:bin, which provides >> gio-launch-desktop. Would you like to give this a try? > > The only thing that comes to my mind when someone says "wrapper" is > tortilla with chicken, but I can try tinkering with it. In many packages we use “wrap-program” (and in a few we use “wrap-script”) to create a shell script that sets environment variables and then calls the actual program. The Thunar executable could perhaps be wrapped with a shell script that first sets the PATH environment variable to a value that includes the “bin” directory of the “glib” package’s “bin” output. The result is that Thunar will be able to find gio-launch-desktop in the PATH. -- Ricardo
Re: "make dist" broken by German cookbook translation
On 2020-03-06, pelzflorian (Florian Pelz) wrote: > On Fri, Mar 06, 2020 at 11:19:27AM -0800, Vagrant Cascadian wrote: >> It looks like the commit adding the German translation for the cookbook >> f98e83a17fa30587520e858231ec9c61f3624ecd broke "make dist". > > Sorry! I should have tested more. Fixed in > 895e6e8af657d28527f7cccf68eab7319f50fba5. Thanks for the quick fix! live well, vagrant signature.asc Description: PGP signature
Re: Thunar cannot launch gio-launch-desktop
On Fri, 06 Mar 2020 22:51:36 +0100 Ricardo Wurmus wrote: > In many packages we use “wrap-program” (and in a few we use > “wrap-script”) to create a shell script that sets environment > variables and then calls the actual program. > > The Thunar executable could perhaps be wrapped with a shell script > that first sets the PATH environment variable to a value that > includes the “bin” directory of the “glib” package’s “bin” output. > The result is that Thunar will be able to find gio-launch-desktop in > the PATH. > > -- > Ricardo Okay, I should be able to do this then. I guess there are many examples, so this should be easy. Just give me a day, because it's night here now. Jan Wielkiewicz
