Re: 04/08: gnu: QEMU: Unbundle iPXE.
On Sat, Jan 7, 2023 at 9:24 PM Marius Bakke wrote: > > --8<---cut here---start->8--- > > grub <- qemu-minimal <- ipxe-qemu <- ipxe <- syslinux > > --8<---cut here---end--->8--- > > > > with syslinux that only supports x86_64-linux and i686-linux. > > > > I'm not sure how to break that path. It looks like qemu-minimal is > > required by grub for test purposes. Maybe we could restrict that > > dependency and the tests to x86_64-linux and i686-linux? > > I don't know what iPXE uses syslinux for (CC Vincent); it appears to > build fine without it. I made the dependency conditional on > architecture in d15972194aaef17fd1f7fd713d235c70794c9d4f, that way QEMU > should still work on aarch64. I don't know for sure, but searching a bit, I've found 2 references to syslinux : You will need to have at least the following packages installed in order to build iPXE: [...] - syslinux (for isolinux, needed only for building .iso images) [...] See page : https://ipxe.org/download?s[]=syslinux And : To be able to boot memtest, there are a couple requirements: [...] The memdisk kernel from the syslinux library [...] See page : https://ipxe.org/appnote/memtest?s[]=syslinux So maybe add a comment somewhere explaining that those 2 things won't work on any arch != x86_* Maybe just add that to the commitmsg... Regards -- Vincent Legoll
Re: Guix wiki
Hello, There is something here: https://libreplanet.org/wiki/Group:Guix -- Vincent Legoll
Re: [PATCH RFC 0/4] Getting rid of input labels?
Hello,
On Thu, May 20, 2021 at 5:03 PM Ludovic Courtès wrote:
> Instead of writing:
>
> (native-inputs
> `(("autoconf" ,autoconf)
>("automake" ,automake)
>("pkg-config" ,pkg-config)
>("guile" ,guile-3.0)))
>
> one can write:
>
> (native-inputs (list autoconf automake pkg-config guile-3.0))
What about
> (native-inputs
> `(,autoconf
>("truc" ,muche)
>"pkg-config"
> ))
i.e. allowing package objects, tuples and names, and it would DTRT ?
Wouldn't something like that be possible ?
--
Vincent Legoll
Re: Guix help page
Hello, On Mon, May 3, 2021 at 4:11 PM Luis Felipe wrote: > I just sent a patch to add this (https://issues.guix.gnu.org/48187/). At a cursory glance, it LGTM. Thanks a lot. -- Vincent Legoll
Re: Pinebook Pro no longer WIP
Hello, On Sun, May 2, 2021 at 2:33 AM Vagrant Cascadian wrote: > Untested: > eMMC I've tested this today. I was on sdcard, and migrated "/" to emmc, keeping the bootloader on sdcard because I don't like opening the PBP to get back to a booting state in case of problems. I modified the root FS UUID in system config, then `guix system init`'ed to the emmc, rebooted and it was working OK. then did a pull+reconfigure to double check. > Outstanding bugs and/or quirks: > > often hangs on reboot and keeps draining power > sometimes hangs on shutdown and keeps draining power Yes, I'm also having problems to (re)boot. > I've only tested with the "linux-libre-arm64-generic" kernels Same here. Thanks -- Vincent Legoll
Re: New blog post on the Guix Build Coordinator: Building derivations, how complicated can it be?
Thanks Christopher, Mathieu & Ludo to help us understand what's going on -- Vincent Legoll
Re: RISC-V is giving away developer boards
Hello, On Fri, Apr 30, 2021 at 7:08 PM Ludovic Courtès wrote: > Mark H Weaver skribis: > > > This might be of interest: > > > > https://riscv.org/blog/2021/04/risc-v-is-giving-away-developer-boards/ > > > > Perhaps the Guix project would like to apply to get one of these? > > What do you think? > > That’d be great; a few people were interested in a port to RISC-V. > > Could interested developers raise their hands? :-) I am interested. -- Vincent Legoll
Re: ISO image: to xz or not to xz?
On Wed, Apr 28, 2021 at 10:18 PM Ludovic Courtès wrote: > What do people think? I'd say distribute both, so the bandwidth-starved can get the smaller, and the CPU-starved can get the uncompressed one. -- Vincent Legoll
Re: Pinebook pro TODO
Hello Vagrant, Thanks a lot for the update. I'll see what I can do. -- Vincent Legoll
Re: New blog post on the Guix Build Coordinator: Building derivations, how complicated can it be?
On Sat, Apr 24, 2021 at 11:10 AM Christopher Baines wrote: > I did think about trying to include something about Cuirass, but I don't > have a clear picture of it's scope or purpose, so I'm not really the > right person to attempt to write authoritatively about it. OK, fair enough, Matthieu, Ludo, or anyone else can shed some light here ? > I try to avoid using the CI (Continuous Integration) term as I'm not > sure there's a shared understanding of the term (I think it's the > practice of multiple people frequently merging their changes to some > software they're all working on). Yes, I know the term is overloaded, but it's easy and conveys at least a bit of the subject at hands, so... > Does that make any sense? Do say if you have more questions. Yes, and I will, thanks -- Vincent Legoll
Pinebook pro TODO
Hello, now that I've got my pbp running guix, I have more questions. The kernel is still "manjaro kernel", should this be changed to reflect some changes we have made ? What about the panfrost patch ? https://issues.guix.gnu.org/40835 https://lists.gnu.org/archive/html/guix-patches/2020-04/msg01317.html The wip-pbp branch: why does it get merges from master instead of being rebased (as wip-* branches can be) ? How can one help getting things going upstream ? Thanks to all people involved -- Vincent Legoll
Re: New blog post on the Guix Build Coordinator: Building derivations, how complicated can it be?
Hello, On Sat, Apr 24, 2021 at 8:28 AM Christopher Baines wrote: > With some prompting, there's now a blog post about the Guix Build > Coordinator Nice post that explains a lot, but I'm still not so sure about the relations to cuirass. I'd have liked a small paragraph explaining what the differences are, how can they complement each other, kind of the CI envisionned big picture... Regards -- Vincent Legoll
Re: Guix help page
> I'll give it a shot Here is an (untested) attempt, is it any good ? -- Vincent Legoll From 50f15a322e86591bc6e3572245c98eb79c0dfafb Mon Sep 17 00:00:00 2001 From: Vincent Legoll Date: Mon, 19 Apr 2021 19:48:51 +0200 Subject: [PATCH] website: help: Add development manual link. * website/apps/base/templates/help.scm (manual): Add development manual link. --- website/apps/base/templates/help.scm | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/website/apps/base/templates/help.scm b/website/apps/base/templates/help.scm index 6eeb176..5179990 100644 --- a/website/apps/base/templates/help.scm +++ b/website/apps/base/templates/help.scm @@ -62,7 +62,11 @@ system|GNU Hurd|GNU Guix package manager|Help resources") #\|) ,(link-more #:label (G_ "Get Guix reference card") - #:url (guix-url "guix-refcard.pdf"))) + #:url (guix-url "guix-refcard.pdf")) + +,(link-more + #:label (G_ "Read Guix manual (development versions)") + #:url (guix-url "manual/devel" #:localize #f))) (div -- 2.20.1
Re: Guix help page
Hi, On Mon, Apr 19, 2021 at 6:44 PM Luis Felipe wrote: > It sounds good to me. I added this to my list, but if someone else wants to > do it, please go ahead. I'll give it a shot -- Vincent Legoll
Guix help page
Hello, I think we could add a link to the devel doc [1] (with the appropriate warnings) to the "all help" page. WDYT ? [1] https://guix.gnu.org/manual/devel/ -- Vincent Legoll
Re: [PATCH 0/9] Add 32-bit powerpc support
Hi, On Sat, Apr 17, 2021 at 9:44 PM Efraim Flashner wrote: > As far as operating systems with support¹ Adélie Linux is the only > one I know that's actually targeting the machines. There's also a void port being worked on, but not upstreamed yet (https://voidlinux-ppc.org) gentoo, openbsd & netbsd also still have support too. -- Vincent Legoll
Re: [PATCH 0/9] Add 32-bit powerpc support
Hi, On Sat, Apr 17, 2021 at 6:04 PM Ludovic Courtès wrote: > 3. OTOH, what will be the status of this architecture? I don’t think > new 32-bit PPC hardware is being made (right?), so I guess we > probably won’t have substitutes for that architecture. That means > it won’t be supported at the same level as other architectures and > may quickly suffer from bitrot. > > I’m torn between #2 and #3. I don't think we have checked that ppc64 is unable to build this in a similar way that x86_64 is able to build 32 bit x86 without virtualization. But that may be possible, so all hope is not lost. -- Vincent Legoll
Re: bug#47615: [PATCH 1/9] gnu: bootstrap: Add support for powerpc-linux.
Hello, On Wed, Apr 14, 2021 at 5:51 AM Chris Marusich wrote: > Generally speaking, this patch looks fine to me. Just curious, what > sort of machines does one use for 32-bit powerpc? Old apple hardware based on powerpc G4 (powermacs, mini, imac, etc.), maybe even G3. > Any ideas for how we can get a machine for powerpc CI? Maybe VMs, I > guess? Can a POWER9 machine be a powerpc-linux machine...? A VM on power9 may be able to run BE ppc32. Regards -- Vincent Legoll
Re: Following Guix weather.
On Fri, Apr 9, 2021 at 9:38 PM Mathieu Othacehe wrote: > > The column sorting icon is overlapped with the columns title > > Oh, didn't notice it on my large screen! I've got plenty of whitespace around the whole table (probably enough to fit 2 whole tables). I cropped it from the screen capture. My screen is 1440p. And a page forced-refresh did not change it, even in full screen. But that is perhaps a browser glitch. > > The jobs column: > > * is there really a need for decimals for the %age, an integer would > > be good enough ? (no more ".00%" nor "100.00%") > > Yeah, I hesitated a bit about that. As the master specification has 45k+ > items, those extra digits give the impression that something is going > on. But I'll think more about that. a " 93% (42042/45073)" would be perfect, but maybe too much... you've got the big picture (%age) and actual precise numbers that can change upon reload to show progress. > > * could you give a bit more width so that it always fits in two lines ? > > I think you are still using a cached CSS. You can reload the page using > "Ctrl - F5" to fix it. The Jobs column displays either the percentage or > the build count but not both. You're right, a forced reload (CTRL-SHIFT-R here) did the trick. Thanks -- Vincent Legoll
Re: Following Guix weather.
Hello, On Fri, Apr 9, 2021 at 7:12 PM Pierre Neidhardt wrote: > Wow, great work! Indeed, I especially like the new specifications for tarballs, images, etc. But (as always) I have a few nits to pick... The column sorting icon is overlapped with the columns title The jobs column: * is there really a need for decimals for the %age, an integer would be good enough ? (no more ".00%" nor "100.00%") * could you give a bit more width so that it always fits in two lines ? See the attached capture Thanks, this is nice work / progress ! -- Vincent Legoll
Re: Semi-automated patch review
Hello, On Fri, Apr 9, 2021 at 1:27 PM Léo Le Bouter wrote: > > On Wed, 2021-04-07 at 17:00 +0200, Andreas Enge wrote: > > posting messages to the issues looks like a feasible and good thing > > to me, > > then all relevant information would be present in the same place. > > I also think that's what should be done but it seems there are worries > that this may cause people to unsubscribe considering the already > existing flood of information in the guix-patches list. I think this was understood as "posting to individual issues" and not to the guix-patches ML. As in: a followup to "xxx...@debbugs.gnu.org" At least that was what I was +1'ing -- Vincent Legoll
Re: Document our WIP
Hi, On Thu, Apr 8, 2021 at 9:55 PM Luis Felipe wrote: > > I just sent a patch to include a link to the wiki in the Help page > > (https://issues.guix.gnu.org/47555). I'm sorry to not have given feedback, the Help page addition is great ! Nice wiki icon too. > > If the patch is applied, I can send a separate patch to update the Help > > menu as Vincent suggested: > > > > Help > > • GNU Guix Manual > > • Videos > > • Cookbook > > • GNU Manuals > > • Wiki > > • IRC Chat > > • Mailing lists > > I've just sent a patch to add this menu (https://issues.guix.gnu.org/47663). I'm not sure if I can help, but this LGTM (untrained eyes)... Thanks a lot -- Vincent Legoll
Re: Please review blog post draft: powerpc64le-linux support
Hello, On Thu, Apr 8, 2021 at 6:37 PM Chris Marusich wrote: > I specifically avoided speaking about the Blackbird, only because it's > not yet RYF-certified. However, perhaps I'm being too strict about it. Ah, yes, I forgot about this detail. I'd have chosen the blackbird myself, for the same reasons. But it's still a bit pricey for me though. I'd say you can talk about it, the way you proposed, as there's a high probability that it will get the certification. -- Vincent Legoll
Re: Please review blog post draft: powerpc64le-linux support
Hello Chris, Great blog post ! I've not seen anything more than the already reported issues. On Thu, Apr 8, 2021 at 10:55 AM Chris Marusich wrote: > Talos II and Talos II Lite Why only speaking of Talos and not about the 3rd option: the blackbird ? Maybe just concentrate on the vendor, more than on particular models... Thanks -- Vincent Legoll
Re: [PATCH 0/9] Add 32-bit powerpc support
Hello, On Tue, Apr 6, 2021 at 2:26 PM Efraim Flashner wrote: > The wip-ppc branch on Savannah is currently in a good state. With the > recent rapid churn on core-updates I haven't been very quick about > rebasing on core-updates but I can confirm that building out to mesa > works. Building is slow, it took 6 days to build from guile-final to > mesa without stopping. I still haven't dragged my G4 mini from its osx misery, so I tried cross-building (from x86_64) instead. cross-builds ok: * bootstrap-tarballs * guile * binutils * mac-fdisk failed: * guix (perl refused to cross-build) * nss, because nspr failed with: [...] ../../../config/./nsinstall -R -m 444 ./_aix32.cfg ./_aix64.cfg ./_bsdi.cfg ./_darwin.cfg ./_freebsd.cfg ./_hpux32.cfg ./_hpux64.cfg ./_linux.cfg ./_netbsd.cfg ./_nto.cfg ./_openbsd.cfg ./_os2.cfg ./_qnx.cfg ./_riscos.cfg ./_scoos.cfg ./_solaris.cfg ./_unixware7.cfg ./_unixware.cfg ./_win95.cfg ./_winnt.cfg ../../../dist/include/nspr/md ../../../config/./nsinstall: ../../../config/./nsinstall: cannot execute binary file mesa and afl refused because of meson-build-system. -- Vincent Legoll
Re: Document our WIP
Hello, On Tue, Apr 6, 2021 at 1:35 AM Léo Le Bouter wrote: > I am thinking we could establish policy so that the WIP wiki page is an > index to mailing list threads, git branches or other "updatable" > locations so that it is less likely to need updating and therefore > stays updated w.r.t. it's main purpose: finding out about WIP work. > > The policy would say that one must create a mailing list thread, git > branch or else and link it there and **NOT** include original > information on the wiki page but rather just link to ML/git/else. > > We could write such policy at the top of the page so contributors to it > can easily see it. > > What do you think? It can be an index, but I personally prefer if it can be a bit more than that, so I don't see strict policy being useful. Just collectively try to keep it sane, organized and as up to date as possible. It already is only an index to ML, blog, git branches for some items, and I think that's OK. I also think that the entries with a bit more context (arch support, mainly) are also useful in explaining what one can expect from that item. Thanks -- Vincent Legoll
Re: Semi-automated patch review
Hello, On Wed, Apr 7, 2021 at 5:03 PM Andreas Enge wrote: > posting messages to the issues looks like a feasible and good thing to me, > then all relevant information would be present in the same place. Yes, +1 to that -- Vincent Legoll
Re: [PATCH 9/9] gnu: nss: Skip tests on powerpc-linux.
On Tue, Apr 6, 2021 at 9:18 PM Efraim Flashner wrote: > On Tue, Apr 06, 2021 at 07:00:50PM +0200, Vincent Legoll wrote: > > s/sporatically/sporadically/ > > Not going to lie, spelling is hard. I normally have spell check turned > off for scheme files. But you *are* lying, you have the guile spell-(and-syntax-)checker enabled for all your scheme files, and it is a picky one... ;-) -- Vincent Legoll
Re: [PATCH 7/9] build: qemu-command: Add support for powerpc.
On Tue, Apr 6, 2021 at 9:18 PM Efraim Flashner wrote:
>
> On Tue, Apr 06, 2021 at 07:02:47PM +0200, Vincent Legoll wrote:
> > Hello,
> >
> > On Tue, Apr 6, 2021 at 2:44 PM Efraim Flashner
> > wrote:
> > > +((string-match "powerpc" cpu) "ppc")
> >
> > Won't there be some "powerpc64le" conflict here ?
> >
>
> I thought not, but it appears it would match all of powerpc*
>
> (ins)scheme@(guile-user)> (use-modules (ice-9 regex))
> (ins)scheme@(guile-user)> (string-match "powerpc" "powerpc")
> $1 = #("powerpc" (0 . 7))
> (ins)scheme@(guile-user)> (string-match "powerpc" "powerpc64le")
> $2 = #("powerpc64le" (0 . 7))
> (ins)scheme@(guile-user)> (string-match "powerpc" "armhf")
> $3 = #f
>
> If it were string=? then it would be fine, but that would break the
> ^i[3456]86$ regex. It looks like I would need to add a powerpc64 case
> above the powerpc case. Looking at the output of qemu adding
> ((string-match "powerpc64" cpu) "ppc64") would be the right answer.
or you can use anchored regex, like in the x86 case:
((string-match "^powerpc$" cpu) "ppc")
--
Vincent Legoll
Re: [PATCH 7/9] build: qemu-command: Add support for powerpc.
Hello, On Tue, Apr 6, 2021 at 2:44 PM Efraim Flashner wrote: > +((string-match "powerpc" cpu) "ppc") Won't there be some "powerpc64le" conflict here ? -- Vincent Legoll
Re: [PATCH 9/9] gnu: nss: Skip tests on powerpc-linux.
Hello, On Tue, Apr 6, 2021 at 2:44 PM Efraim Flashner wrote: > + ;; Tests on powerpc-linux take forever and fail sporatically. s/sporatically/sporadically/ -- Vincent Legoll
Re: Why ban underscores?
Hello, On Sun, Apr 4, 2021 at 10:49 PM Tobias Geerinckx-Rice wrote: > nsis-x86_64 > mingw-w64-x86_64 > mingw-w64-x86_64-winpthreads That will make really strange names, at least for those -- Vincent Legoll
Re: Question about compile packages
Hello Mark, On Wed, Mar 31, 2021 at 2:30 AM Mark H Weaver wrote: > If more people are interested in using Guix in this way, the experience > could probably be made much nicer. I think this would interest quite a few people, a guixtoo cookbook chapter ? I've wondered about such subject myself since my early tries with guix, and just today, I got to know it is doable, and there are people just doing it, and some hints about what & how to try it myself... So thank you, and Raingloom. -- Vincent Legoll
Re: Let's include powerpc64le-linux in the next release
Hello, On Tue, Mar 30, 2021 at 10:24 AM Ludovic Courtès wrote: > Plus, I’m really grateful to OSUOSL for giving > us access to this machine! Yes, it's really nice to have access to those, and in the future, if we want to really support the ppc64le with substitutes, we may ask for a CI-class VM which should have better performance. I've also asked for details of the openstack setup, and the virtual disks provided to the VMs are networked ceph storage which is quite slow, they are investigating the problem. I also asked if they can try to provide hypervisor-local scratch storage (way faster but not durable, and would make the VM non migratable) to the VMs and they may be able to do so in the future. Tchuss -- Vincent Legoll
[aarch64] sbcl build failure
Hello, I'm looking at the following cl-zstd build failure: https://ci.guix.gnu.org/build/133326/details which is caused by sbcl build failure that I reproduced locally. I diffed the CI build log output with my local attempt and got the same thing modulo timings [1] and other harmless stuff. [1] the Odroid N2 looks roughly 3x faster than the CI on this specific build / test (total 30 mins vs 90). -- Vincent Legoll
Re: hikari build failure
> I've restarted <https://ci.guix.gnu.org/build/133895/details>. I'm seeing overdrive1 as idle (as a lot of hydra workers) yet the restart is still in scheduled state. What am I missing ? -- Vincent Legoll
hikari build failure
Hello, I saw the aarch64 build failure for hikari on cuirass https://ci.guix.gnu.org/build/133895/details it looked like the failure was because bmake (a dep) failed, I tried to build it locally which succeded, then also retried hikari with success. I'm on a binary install above armbian on odroid N2. vince@odroidn2:~$ guix describe Génération 230 mars 2021 22:59:41(actuelle) guix 634d984 URL du dépôt : https://git.savannah.gnu.org/git/guix.git branche : master commit : 634d9845a6b4e362f32ba369ae42851719455ba3 The retry button on cuirass gave me a 403 forbidden. What should we do ? just wait for next build ? -- Vincent Legoll
Re: Document our WIP
Hello, Mathieu, thanks for the additions. Can someone having some experience with pinebook-pro double-check this item ? Vagrant, you seem to have some good results, can you add something about them ? Any other subjects worth mentionning there ? https://libreplanet.org/wiki/Group:Guix/WorkInProgress -- Vincent Legoll
Re: Document our WIP
On Sat, Mar 27, 2021 at 7:11 PM Luis Felipe wrote: > I see a newly created page for Works in Progress, though Yep, my announce and your email crossed past each other... -- Vincent Legoll
Re: Document our WIP
The first bits are in, look: https://libreplanet.org/wiki/Group:Guix/WorkInProgress Add / enhance to tell what is running, where to find good recipes... To create pages you have to score a few edits (I went typo-hunting for a bit). I think about 5 should do. -- Vincent Legoll
Re: Document our WIP
On Sat, Mar 27, 2021 at 5:50 PM Léo Le Bouter wrote: > After looking more closely at the help page, I think it could be > acceptable to have it there too. But is the wiki an help resource? Even if it may not be today, we are proposing something that could turn it into a helpful resource. So OK with me. -- Vincent Legoll
Re: Document our WIP
On Sat, Mar 27, 2021 at 5:42 PM Luis Felipe wrote: > The reason I didn't suggest that, though, is that the primary menu has already > grown too big in my opinion. And, with the current design, the visibility of > the > primary menu changes depending on screen width: The primary menu is hidden > behind a primary menu button for screens narrower than 920 px (which may be > too soon already). I can hear that. OK, no more top bar pollution, Let's get it in "Help", but we could make this one a submenu with direct links (the same list as the sections from the help page). There's something strange, the default link to the doc is for the /en/ language when I selected the french web site, this could go directly to the french version. BTW, there's no rush to change this, as Leo, I can't create a page on libreplanet's wiki -- Vincent Legoll
Re: Cuirass not processing core-updates (or weirdly)
Maybe we can have both: a core-updates:'core with a sufficient priority so that it is built often enough, and then a core-updates:'all with the lowest priority (batch) so that it does not steal any processing power from the other more important stuff... -- Vincent Legoll
Re: Document our WIP
On Sat, Mar 27, 2021 at 4:54 PM Luis Felipe wrote: > Or that, yes. I can send a patch to add a Wiki entry to the Help page instead > of adding a "Wiki" item to the "About" menu. Or even better a "Wiki" title bar entry of its own, like we have one for "Blog"... -- Vincent Legoll
Re: Document our WIP
Looks like we have a plan. Now for the hard part, how do we name it ? "Guix/WIP" or "Guix/WorkInProgress" or "Guix/Hacking", "Guix/CoolStuff", "Guix/BleedingEdge", "Guix/NewShiny" Some of those may be half-jokes, I'd personally go with WorkInProgress. -- Vincent Legoll
Re: Document our WIP
On Sat, Mar 27, 2021 at 3:44 PM Ricardo Wurmus wrote: > > I'd like to reiterate my proposal to document our > > ongoing projects, maybe with a "WIP" page on the > > web site (even if I'm not a web guy, I volunteer > > the maintenance of it). > > There’s a wiki that could be used for this purpose: > https://libreplanet.org/wiki/Group:Guix I'm OK with hosting that page there, but I still think discoverability from a link on: https://guix.gnu.org/en/help/ will help... I don't know if libreplanet's wiki meets Léo's requirements, but this is probably OK from a PoV of spam management. -- Vincent Legoll
Document our WIP
Hello, I'd like to reiterate my proposal to document our ongoing projects, maybe with a "WIP" page on the web site (even if I'm not a web guy, I volunteer the maintenance of it). * CI-built pinebook-pro images [1] * other ARM boards * ppc64 & ppc * Hurd VM * Full source bootstrap And probably other things I missed. This should complement the ML archives, IRC logs or blog, with pointers to (hopefully) more current infos on those subjects. WDYT ? [1] I only (accidentally) discovered today that those exist -- Vincent Legoll
ARM64 hardware
Hello, I stumbled upon the following blog post: https://www.mininodes.com/arm-server-update-fall-2020/ Which was a summary of what should be available. I say "should" because some links are already dead now. There are mentions of non-FLOSS things there. -- Vincent Legoll
Re: cuirass
> The rule for “#search #search-hints” should have a “z-index: 1;” or
> similar, so that the icons don’t overlap the search box.
Like the following ?
diff --git a/src/static/css/cuirass.css b/src/static/css/cuirass.css
index e713b6f..2754415 100644
--- a/src/static/css/cuirass.css
+++ b/src/static/css/cuirass.css
@@ -4,6 +4,7 @@
#search #search-hints {
display: none;
position: absolute;
+z-index: 1;
top: 3em;
background: white;
border: 1px solid #ced4da;
--
Vincent Legoll
cuirass
Hello, I just made a tour of the new cuirass, this is much nicer than when I last visited (a long time ago). Kudos ! I saw a few glitches (with firefox 78.8.0esr) * The "Home" & "Guix logo" buttons bothlink back to the home page (duplicate). * The search combobox help popup window is not on top level, probably on all pages. So other page elements are displayed over it. * Overdirve1 does not have infos (missing zabbix) I have collected a buch of ideas for additions. Should I create bugs for those or just the above list will suffice ? Thanks a lot for the improvements ! PS: Sorry for ENOPATCH but I'm not good at web. -- Vincent Legoll
Re: [opinion] CVE-patching is not sufficient for package security patching
Hello, On Wed, Mar 24, 2021 at 8:51 PM Leo Famulari wrote: > > We bought a handful of Overdrive 1000 in the past (they are no longer > > sold), and hosting was always an obstacle. > > I volunteer to host one or two workstation-type 64-bit ARM machines. I already volunteered (privately) to host the same (1 or 2 WS power-class), currently on ADSL uplink (so not for substitute distribution, only building), FTTH in the future, no UPS though. -- Vincent Legoll
Re: [SPITBALL] Jehanne as another kernel option / porting target
On Sunday, March 21, 2021, raingloom wrote: > On Fri, 19 Mar 2021 20:42:19 +0100 > Vincent Legoll wrote: > > > + '(#:tests? #f ;; No need for tests when you have formal proof > > of correctness > In just about any talk about Idris and Type Driven Development, Edwin > Brady always starts with "you still need tests". > That package is not intended to be included, as it is far from finished, sorry, I should have added " pun intended" with the accompanying smiley ... -- Vincent Legoll
Re: [SPITBALL] Jehanne as another kernel option / porting target
On Fri, Mar 19, 2021 at 8:42 PM Vincent Legoll wrote: > > On Fri, Mar 19, 2021 at 7:02 PM Vincent Legoll > wrote: > > I have created a guix build recipe for seL4 recently, it builds, but I don't > > know what to do with it :-) > > > > I'll send it as a followup to this thread, if any one is interested. > > Here it is, ukernel only, hardcoded arch, nothing fancy like camkes, etc. vince@guix ~/dev/repo/guix [env]$ file /gnu/store/8j7zdpnagz2i90cbmrqnk1vbsdck4d21-sel4-12.0.0/kernel.elf /gnu/store/8j7zdpnagz2i90cbmrqnk1vbsdck4d21-sel4-12.0.0/kernel.elf: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, not stripped vince@guix ~/dev/repo/guix [env]$ l /gnu/store/8j7zdpnagz2i90cbmrqnk1vbsdck4d21-sel4-12.0.0/kernel.elf -r-xr-xr-x 2 root root 179K Jan 1 1970 /gnu/store/8j7zdpnagz2i90cbmrqnk1vbsdck4d21-sel4-12.0.0/kernel.elf vince@guix ~/dev/repo/guix [env]$ ./pre-inst-env guix build --check --rounds=5 sel4 [...] successfully built /gnu/store/laxxpkng3rs3kq1b5gbyzqsvlw97hdwk-sel4-12.0.0.drv The following builds are still in progress: /gnu/store/laxxpkng3rs3kq1b5gbyzqsvlw97hdwk-sel4-12.0.0.drv /gnu/store/laxxpkng3rs3kq1b5gbyzqsvlw97hdwk-sel4-12.0.0.drv /gnu/store/laxxpkng3rs3kq1b5gbyzqsvlw97hdwk-sel4-12.0.0.drv /gnu/store/laxxpkng3rs3kq1b5gbyzqsvlw97hdwk-sel4-12.0.0.drv successfully built /gnu/store/laxxpkng3rs3kq1b5gbyzqsvlw97hdwk-sel4-12.0.0.drv The following builds are still in progress: /gnu/store/laxxpkng3rs3kq1b5gbyzqsvlw97hdwk-sel4-12.0.0.drv /gnu/store/laxxpkng3rs3kq1b5gbyzqsvlw97hdwk-sel4-12.0.0.drv /gnu/store/laxxpkng3rs3kq1b5gbyzqsvlw97hdwk-sel4-12.0.0.drv Looks even reproducible... -- Vincent Legoll
Re: [SPITBALL] Jehanne as another kernel option / porting target
On Fri, Mar 19, 2021 at 7:02 PM Vincent Legoll wrote:
> I have created a guix build recipe for seL4 recently, it builds, but I don't
> know what to do with it :-)
>
> I'll send it as a followup to this thread, if any one is interested.
Here it is, ukernel only, hardcoded arch, nothing fancy like camkes, etc.
--
Vincent Legoll
From 607cef41839131fd740fbf754d30f3a9277c5a0a Mon Sep 17 00:00:00 2001
From: Vincent Legoll
Date: Fri, 19 Feb 2021 23:49:43 +0100
Subject: [PATCH] gnu: Add sel4.
* gnu/packages/sel4.scm: New file...
* gnu/local.mk (GNU_SYSTEM_MODULES): ...Add it here.
---
gnu/local.mk | 1 +
gnu/packages/sel4.scm | 83 +++
2 files changed, 84 insertions(+)
create mode 100644 gnu/packages/sel4.scm
diff --git a/gnu/local.mk b/gnu/local.mk
index 33da7b979a..6d4ddb2bdd 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -502,6 +502,7 @@ GNU_SYSTEM_MODULES =\
%D%/packages/sdl.scm\
%D%/packages/search.scm \
%D%/packages/security-token.scm \
+ %D%/packages/sel4.scm\
%D%/packages/selinux.scm \
%D%/packages/sequoia.scm \
%D%/packages/serialization.scm \
diff --git a/gnu/packages/sel4.scm b/gnu/packages/sel4.scm
new file mode 100644
index 00..6fc3f88ac2
--- /dev/null
+++ b/gnu/packages/sel4.scm
@@ -0,0 +1,83 @@
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2021 Vincent Legoll
+;;;
+;;; This file is part of GNU Guix.
+;;;
+;;; GNU Guix is free software; you can redistribute it and/or modify it
+;;; under the terms of the GNU General Public License as published by
+;;; the Free Software Foundation; either version 3 of the License, or (at
+;;; your option) any later version.
+;;;
+;;; GNU Guix is distributed in the hope that it will be useful, but
+;;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+;;; GNU General Public License for more details.
+;;;
+;;; You should have received a copy of the GNU General Public License
+;;; along with GNU Guix. If not, see <http://www.gnu.org/licenses/>.
+
+(define-module (gnu packages sel4)
+ #:use-module (gnu packages)
+ #:use-module (gnu packages python)
+ #:use-module (gnu packages python-xyz)
+ #:use-module (gnu packages python-web)
+ #:use-module (gnu packages ninja)
+ #:use-module (gnu packages xml)
+ #:use-module (guix build-system cmake)
+ #:use-module ((guix licenses) #:prefix license:)
+ #:use-module (guix packages)
+ #:use-module (guix git-download))
+
+(define-public sel4
+ (package
+(name "sel4")
+(version "12.0.0")
+(source
+ (origin
+ (method git-fetch)
+ (uri (git-reference
+ (url "https://github.com/seL4/seL4;)
+ (commit version)))
+ (file-name (git-file-name name version))
+ (sha256
+(base32 "1zkx6x5jly8f75ph9jxd2jrp1kg5l001zkfqpmjf8ancsi1b43y7"
+(build-system cmake-build-system)
+(arguments
+ '(#:tests? #f ;; No need for tests when you have formal proof of correctness
+ #:configure-flags
+ (list
+"-G" "Ninja"
+"-DKernelArch=x86"
+"-DCROSS_COMPILER_PREFIX="
+"-DCMAKE_TOOLCHAIN_FILE=../source/gcc.cmake"
+"-C" "../source/configs/X64_verified.cmake")
+ #:phases (modify-phases %standard-phases
+ (replace 'build
+(lambda _
+ (invoke "ninja" "kernel.elf")))
+ (replace 'install
+(lambda _
+ (mkdir-p %output)
+ (copy-file "kernel.elf"
+ (string-append %output "/kernel.elf")))
+(native-inputs
+ `(("libxml2" ,libxml2)
+ ("ninja" ,ninja)
+ ("python" ,python-3)
+ ("python-future" ,python-future)
+ ("python-jinja2" ,python-jinja2)
+ ("python-paste" ,python-paste)
+ ("python-ply" ,python-ply)
+ ("python-six" ,python-six)
+ ))
+(synopsis "Operating System microkernel")
+(description "Formally verified member of the L4 microkernel family.")
+(home-page "https://sel4.systems;)
+(license (list license:asl2.0 ; And also a variant in LICENSES/SHL-0.51.txt
+ license:bsd-2
+ license:bsd-3
+ license:cc-by-sa4.0
+ license:gpl2
+ license:gpl2+
+ license:lppl1.3c
+ license:x11
--
2.30.0
Re: [SPITBALL] Jehanne as another kernel option / porting target
Hello, On Fri, Mar 19, 2021 at 5:45 PM Joshua Branson wrote: > >> seL4 would be cool too. > > Didn't someone do some work on making hurd run on SEL4? > > Or am I misremembering > > You are correct. :) It was a member of the L4 family, but I think it was not seL4 (looks like seL4 started in 2006). I have created a guix build recipe for seL4 recently, it builds, but I don't know what to do with it :-) I'll send it as a followup to this thread, if any one is interested. -- Vincent Legoll
Re: Release 1.2.1: zstd 1.4.4 -> 1.4.9: grafting or core-updates?
Hello, On Tue, Mar 16, 2021 at 9:53 PM Tobias Geerinckx-Rice wrote: > Wow, Léo. You've done some seriously impressive CVE squashing in > such a short timespan, and I'm very grateful to have you on board. Yes, impressive, I have been following the repology page about potentially vulnerable & upgradable packages for Guix, and the number has significantly decreased the last weeks, kudos ! I did some package updates (chosen from the very same page) but unlike you, I only cherry-picked the low hanging fruits from there and punted on the more involved ones. A good part of that ended on core-updates due to the rebuilds needed. I think we really should be shortening our releases cycles (core-updates, staging merges), because piling upon those branches for too long increase the disruption in a way that is probably more exponential than linear. My perception is the following (please correct me if I'm wrong): A graft involves work on master for the inherited package & graft, sometimes an update of the package on core updates, then the cleanup (which are more or less all done in a short time frame when we want to release). So while it may good enough for some fixes, they should be limited in number and in time, which also comes to the release early, release often (in a reasonable way). I was told that we can always update packages because guix easily allows anyone to go back to a working state, the same reasoning should be applicable to staging and core-updates merging. Why delay them for too long if the potential disruption is mitigated by going back to a workinig profile or system generation (modulo the substitute availability which is almost only a compute resource problem) Cheers -- Vincent Legoll
Re: Release 1.2.1: timeline
Hello, On Mon, Mar 15, 2021 at 7:50 PM Leo Famulari wrote: > we should include in the release announcement a clear description of > the level of support that users can expect. Yes, that would be useful too, I'm all for giving people the information that it may not be easily usable, but still providing what we have now so that any one can try to push it a bit further. -- Vincent Legoll
Re: Release 1.2.1: timeline
Hello, On Mon, Mar 15, 2021 at 5:55 PM Ludovic Courtès wrote: > > The architecture armf will not be included. > > Wait wait, I missed that. What happened? I think we should include it, > even if substitute availability remains low. IMHO, substitute availability should not be an inclusion criteria -- Vincent Legoll
Re: Guile Netlink 1.0 released
Hello, just a few questions about the API On Sun, Mar 14, 2021 at 8:31 PM Julien Lepiller wrote: > ;; same as "ip a add 192.0.2.15/24 dev enp1s0 > (addr-add "enp1s0" "192.0.2.15/24") Why not separating the netmask from the address ? It forces to do string manipulation, and prevent the use of bitfield, or the dotted bytes representation "255.255.255.0". > (addr-add "enp1s0" "2001:db8::1a4c/64" #:ipv6? #t) what does the "ipv6?" parameter add ? This could be deduced from the address length, no ? > ;; same as "ip r add default via 192.0.2.1 dev enp1s0" > (route-add "default" #:device "enp1s0" #:via "192.0.2.1") "via" could also be called "gateway" (maybe that's an oldtimer thing ;-) ) But that's all kind of bikesheddy... -- Vincent Legoll
Re: Release on April 18th?
Hello Chris, On Fri, Mar 12, 2021 at 7:42 PM Chris Marusich wrote: > Vincent Legoll writes: > > I rebuilt guix on core-updates with gcc-8 succesfully > > I'll now try the same above wip-ppc64le. > > Awesome! Thank you for doing this. I'm sure there will be some bumps, > and the sooner we can fix them, the easier it will be to integrate > later. I did not `make check` on core-updates + gcc 8, will retry that later. On wip-ppc64le, guix built OK, but am meeting `make check` failures: Testsuite summary for GNU Guix 1.0.1.31332-e8b83e # TOTAL: 1171 # PASS: 1153 # SKIP: 7 # XFAIL: 2 # FAIL: 9 # XPASS: 0 # ERROR: 0 See ./test-suite.log Please report to bug-g...@gnu.org I'm looking at those log files now... > I'm still working on getting you access to ppc64le hardware or a VM. I already send my public key to Tobias, so that is WIP. Tchuss -- Vincent Legoll
Re: Release on April 18th?
Hello, I rebuilt guix on core-updates with gcc-8 succesfully I'll now try the same above wip-ppc64le. -- Vincent Legoll
Re: Release on April 18th?
Hello Chris, I'm all for that, what can I do to help ? I don't have a Talos, though... So only cross- or emulated- stuff... Willing to help, but needs directions. -- Vincent Legoll
Re: Hurd substitute availability (27.5%) and next steps?
Hello, On Mon, Mar 8, 2021 at 10:57 PM Christopher Baines wrote: > In terms of getting more packages building, and substitute availability, > personally I think it would be useful to disable tests for packages for > i586-gnu if that gets packages building. It's not ideal to not run the > tests, but it's also difficult to investigate the failures and develop > patches if you don't have substitutes for the software you need to do > that (like Git for example). Is disabling tests for a whole platform possible without patching all the build recipes ? > often I'll be unable to SSH in Couldn't you get a console from a virtual serial port from the VM ? BTW, looks like you're doing excellent work ! Thanks -- Vincent Legoll
Re: Xpdf with or without Qt
In retrospect, I should probably have added a note in the commit message that it would be a somewhat major change. With an emphasis on the X -> QT migration. On Fri, Feb 26, 2021 at 6:02 PM Andreas Enge wrote: > How can I personally keep the old variant? > Should I create a custom channel with xpdf@4.02? Or even xpdf@5 to have > a higher version number, but with the old 4.02 package code and source? > Or a manifest including some time-machine thing, or a personal package > transformation that compiles xpdf --with-source=...? I don't really know the answer to this, but if you're copying the old code, just name your "pinned" package "xpdf-4.02" so that it's not recognized as "xpdf", and that should protect you from xpdf upgrades. -- Vincent Legoll
Re: Xpdf with or without Qt
Hello Andreas, On Fri, Feb 26, 2021 at 4:43 PM Andreas Enge wrote: > commit 35089dca4053bf5888441d1648086cdadb6eb1e4 adds Qt to the xpdf package > and removes most X libraries. The result is quite different and does not > correspond to the synopsis "...based on the Motif toolkit" any more, and we > get closer to more modern pdf readers such as evince or okular. On the other > hand, I have been using xpdf as a "no frills" reader with an interface that > had not changed forever, which I am missing now. > > Is this a change that became necessary with the update from 4.02 to 4.03 > (that looks minor from the numbers!)? If no, I would like to suggest getting > back to the previous inputs. If yes, I do not quite know what to do :) Yes, it fails without it: CMake Warning at CMakeLists.txt:32 (message): Couldn't find Qt4 or Qt5 -- will not build xpdf. >From the xpdf INSTALL file: * Make sure you have the following installed: - CMake 2.8.8 or newer - FreeType 2.0.5 or newer - Qt 4.8.x or 5.x (for xpdf only) - libpng (for pdftoppm and pdftohtml) - zlib (for pdftoppm and pdftohtml) If Qt isn't found, the GUI viewer (xpdf) won't be built, but the command line tools will still be built. This is also documented here: http://www.xpdfreader.com/download.html There may exist a cmake param to get the old bare xpdf, but I've not found it. -- Vincent Legoll
Re: Staging branch [substitute availability armhf-linux]
On Sun, Jan 17, 2021 at 12:01 PM Mathieu Othacehe wrote: > you should be able to download this image. Yep, I DL'ed and got the same result as with my own images, so my building is not be the problem. > Yes looks like the search pagination and ordering is broken, those are > definitely bugs that you can report. Done : https://issues.guix.gnu.org/45936 -- Vincent Legoll
Re: Staging branch [substitute availability armhf-linux]
On Sun, Jan 17, 2021 at 11:17 AM Mathieu Othacehe wrote: > --8<---cut here---start->8--- > guix build -f pinebook.scm > --8<---cut here---end--->8--- > > should achieve the same result locally. That's slightly different than what I have been doing, but the resulting image has the same problem than mine, no LCD output, nothing answering on serial console (@1.5Mbps (uboot speed) or 115.2Kbps (kernel speed, I think)). > > That's where I searched, but did not find one with > > the "Build outputs" link like the one you cited. > > > > Why is 190783 different from the 6 other ones returned > > by this search query ? > > Because I just enabled build outputs production for Pinebook Pro images. Does cuirass only remove the link after a while after the image has been gc'ed ? > > BTW, I think there is a problem in the way Cuirass web UI sorts > > its results (apparently by oldest to newest, on the completion > > time column) it looks like it is doing a string comparison, where > > "32 minutes ago" is older than "37 hours ago". The "<< < > >>" > > buttons also act strangely. Do you see such things ? > > Should I report them as bugs ? > > Yes looks like the search pagination and ordering is broken, those are > definitely bugs that you can report. I'll do it later today Thanks -- Vincent Legoll
Re: Staging branch [substitute availability armhf-linux]
Hello, Thanks On Sun, Jan 17, 2021 at 10:35 AM Mathieu Othacehe wrote: > You can download the latest Pinebook Pro image here: > > https://ci.guix.gnu.org/build/190783/details trying to DL (in browser or with wget) the build output, by using the "https://ci.guix.gnu.org/download/190783; link, I get: error "Could not find the request build product." > to search for the latest images: > > https://ci.guix.gnu.org/search?query=spec%3Aguix-master+system%3Ax86_64-linux+status%3Asuccess+pinebook-pro That's where I searched, but did not find one with the "Build outputs" link like the one you cited. Why is 190783 different from the 6 other ones returned by this search query ? BTW, I think there is a problem in the way Cuirass web UI sorts its results (apparently by oldest to newest, on the completion time column) it looks like it is doing a string comparison, where "32 minutes ago" is older than "37 hours ago". The "<< < > >>" buttons also act strangely. Do you see such things ? Should I report them as bugs ? Tchuss -- Vincent Legoll
strange english in docstring
Hello, I don't understand the following docstring english (even if I guess the meaning): https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/system.scm#n861 -- Vincent Legoll
Re: Staging branch [substitute availability armhf-linux]
Hello, > > I even attempted building the pinebook pro image without success. > > Hm... it's a shame we are building this and it doesn't work. I only tried my locally built one, is there a substitute that I can try ? That would tell if the problem is on my side or not. > Do you also use some armhf (32-bit) hardware? I would like. I tried and failed (I tried to build an image for an orangepi+2e) I have other non-x86 HW that I would like to have guixsd on. I don't ask for susbstitutes, I can build them locally if needed and doable. -- Vincent Legoll
Re: Staging branch [substitute availability armhf-linux]
Hello, On Fri, Jan 15, 2021 at 10:54 AM Mathieu Othacehe wrote: > It seems that Caliph Nomble succeeded to build a Pinebook Pro image and > booted it, without graphics, after a few fixes: > https://issues.guix.gnu.org/45584. > > You may want to try again :). DONE, it's a bit better, this time initrd, kernel & dtb loaded properly. But serial output stopped after "Starting kernel ..." which is probably because of mismatched serial port speed, but I tried to relaunch screen with 57600, 115200 and still go no output. [complete uboot log attached] LCD screen stays black which is probably normal. The image was built like the following: # ./pre-inst-env guix describe Git checkout: repository: /home/vince/dev/repo/guix branch: master commit: c03875b0361f114634caeb54935fe37a9b7b05af # echo "(use-modules (gnu system images pinebook-pro)) pinebook-pro-barebones-os" > /tmp/os.scm # ./pre-inst-env guix system disk-image -t pinebook-pro-raw /tmp/os.scm [...] /gnu/store/5fj3aha8jsyji9mpqzf2krakl08r9zlw-disk-image Next I'll try the hints from: https://issues.guix.gnu.org/45584 > >> There is almost no armhf hardware that is suitable > >> for a build-from-source distro in terms of performance, thermal design > >> and suitable storage (SD cards will not last for unless you pay a huge > >> amount for the absolute highest quality). Binary distros like Trisquel > >> are a much better option for armhf. > > > > The cross buildability *should* be kind of a solution for this. > > Yes we could always decide to stop supporting native ARMv7 substitutes > and only focus on the cross-building to provide ready to use image for > this architecture. Isn't there a way to reconcile the 2 ? At least theoretically cross- or native- compilation should give identical output, though I dunno how far that is from reality (probably not good, or we would be doing just that) > >> All that is not a reason to not support armhf, but if nobody is using > >> it, then we should officially deprecate it, and not leave it in this > >> in-between state. > > > > I'm not using it because I can't make it work. > > Don't hesitate to report the issues you encountered! I've done it a few times already, for armhf, arm64, powerpc64, mipsel. And I'll (re-)try anything if I'm hinted as what to try next. The main problem from my PoV is the scatteredness of the infos. Tchuss -- Vincent Legoll DDR Version 1.20 20190314 In channel 0 CS = 0 MR0=0x98 MR4=0x1 MR5=0xFF MR8=0x8 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 CS = 1 MR0=0x18 MR4=0x1 MR5=0xFF MR8=0x8 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 1 CS = 0 MR0=0x98 MR4=0x1 MR5=0xFF MR8=0x8 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 CS = 1 MR0=0x18 MR4=0x1 MR5=0xFF MR8=0x8 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 0 training pass! channel 1 training pass! change freq to 400MHz 0,1 channel 0 CS = 0 MR0=0x98 MR4=0x1 MR5=0xFF MR8=0x8 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 CS = 1 MR0=0x18 MR4=0x1 MR5=0xFF MR8=0x8 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 1 CS = 0 MR0=0x98 MR4=0x1 MR5=0xFF MR8=0x8 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 CS = 1 MR0=0x18 MR4=0x1 MR5=0xFF MR8=0x8 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 0 training pass! channel 1 training pass! change freq to 800MHz 1,0 Channel 0: LPDDR4,800MHz Bus Width=32 Col=10 Bank=8 Row=15/15 CS=2 Die Bus-Width=16 Size=2048MB Channel 1: LPDDR4,800MHz Bus Width=32 Col=10 Bank=8 Row=15/15 CS=2 Die Bus-Width=16 Size=2048MB 256B stride ch 0 ddrconfig = 0x101, ddrsize = 0x2020 ch 1 ddrconfig = 0x101, ddrsize = 0x2020 pmugrf_os_reg[2] = 0x3AA1FAA1, stride = 0xD OUT Boot1: 2019-03-14, version: 1.19 CPUId = 0x0 ChipType = 0x10, 251 SdmmcInit=2 0 BootCapSize=10 UserCapSize=119276MB FwPartOffset=2000 , 10 mmc0:cmd5,20 SdmmcInit=0 0 BootCapSize=0 UserCapSize=30528MB FwPartOffset=2000 , 0 StorageInit ok = 191888 SecureMode = 0 SecureInit read PBA: 0x4 SecureInit read PBA: 0x404 SecureInit read PBA: 0x804 SecureInit read PBA: 0xc04 SecureInit read PBA: 0x1004 SecureInit read PBA: 0x1404 SecureInit read PBA: 0x1804 SecureInit read PBA: 0x1c04 SecureInit ret = 0, SecureMode = 0 atags_set_bootdev: ret:(0) GPT 0x3380ec0 signature is wrong recovery gpt... GPT 0x3380ec0 signature is wrong recovery gpt fail! LoadTrust Addr:0x4000 LoadTrust Addr:0x4400 LoadTrust Addr:0x4800 LoadTrust Addr:0x4c00 LoadTrust Addr:0x5000 LoadTrust Addr:0x5400 LoadTrust Addr:0x5800 LoadTrust Addr:0x5c00 Addr:0x4000 No find trust.img! LoadTrustBL error:-3 SecureMode = 0 SecureInit read PBA: 0x4 SecureInit read PBA: 0x404 SecureInit read PBA: 0x804 SecureInit read PBA: 0xc04 SecureInit read PBA: 0x1004 SecureInit read PBA: 0x1404 SecureInit read PBA: 0x1804 SecureInit read PBA: 0x1c04 Secur
Re: Staging branch [substitute availability armhf-linux]
Hello, On Fri, Jan 15, 2021 at 12:07 AM Leo Famulari wrote: > Specifically about armhf, if anybody wants to use it with Guix, I hope > they will speak up. I am interested, I have tried, and failed to get anything (apart from guix on foreign armbian). But I am more interested in guixsd though. I even attempted building the pinebook pro image without success. > I think we should monitor the volume of substitute requests per platform > and see how big the demand for armhf Guix really is. With the current situation, I'm not sure this would really be representative of the armhf or arm64 demand. > Although there is a huge amount of armhf hardware deployed, Guix seems a > very poor fit for it. In its current state. > There is almost no armhf hardware that is suitable > for a build-from-source distro in terms of performance, thermal design > and suitable storage (SD cards will not last for unless you pay a huge > amount for the absolute highest quality). Binary distros like Trisquel > are a much better option for armhf. The cross buildability *should* be kind of a solution for this. > All that is not a reason to not support armhf, but if nobody is using > it, then we should officially deprecate it, and not leave it in this > in-between state. I'm not using it because I can't make it work. -- Vincent Legoll
Re: Add Microsoft Cascadia Code font?
Hello, On Sun, Jan 10, 2021 at 10:16 AM Leo Prikler wrote: > there is no .tar of the fonts however, that's a source tarball > generated by github. To be fair, one should probably build this font > (and other fonts) from source instead. In particular, we might want to > package nerd-fonts[1] first, since Cascadia appears to be an iteration > of it. Yes you're right, I did not look at the submitted scm hard enough to see it. Sorry for the noise. -- Vincent Legoll
Re: Add Microsoft Cascadia Code font?
On Sun, Jan 10, 2021 at 9:46 AM Vincent Legoll wrote: > * I've not checked the difference size (nor that it matters) between zip > and tar.gz, you may want to use the smallest one to minimize download. > I just did, and the tgz wins: 3.1 MB vs 5.7 MB -- Vincent Legoll
Re: Add Microsoft Cascadia Code font?
Hello, On Sun, Jan 10, 2021 at 9:04 AM yasu wrote: > Attached is my Guix package submission of Microsoft Cascadia Code > fonts. > > This is my very first attempt to make a Guix package contribution and I > did this in less than 30 minutes, copying the package descriptions of > IBM Plex fonts and modifying a few things. I dont' know what > protocols I may have missed > > Would you please let me know how to proceed from here? > LGTM small nitpicks: * 80 columns (you can auto-format the code with etc/indent-code.el, this is documented here: https://guix.gnu.org/manual/en/html_node/Formatting-Code.html) * I've not checked the difference size (nor that it matters) between zip and tar.gz, you may want to use the smallest one to minimize download. Thanks -- Vincent Legoll
Re: [RFC] Improve Python package quality
On Tue, Jan 5, 2021 at 11:28 AM Lars-Dominik Braun wrote: > > Like in a separate pure-python file. > I don’t know how unfortunately. Any ideas? No sorry, I'm still a newbie > I moved it into a separate top-level variable now and turned it into a > single multi-line Scheme string. That makes it easier to read. That is better, but the separate file would allow to have proper syntax highlighting, allow linting/pep8'ing, etc. Cheers -- Vincent Legoll
Re: [RFC] Improve Python package quality
Hello, I like the idea of better testing for our python packages, but would it be possible to avoid embedding the python code as scheme strings ? Like in a separate pure-python file. WDYT ? -- Vincent Legoll
profile-collisions linter
Hello,
I'm having a look at the reported profile-collisions
linter warnings.
See for example:
http://data.guix.gnu.org/revision/f521104e344ed9bf259a6b821fd0f3080f8ebf6b/package/python-requests/2.20.1?locale=en_US.UTF-8
I'm trying to remove the duplicated propagated-inputs
entries (from the inherited package) and then
concatenating the overrides.
I've come with the attached diff, but it's giving me
headaches.
Anyone can give it a look and tell me what is wrong
with my coding ?
PS: I don't know if this would be better posted in guix-help or elsewhere...
Thanks
--
Vincent Legoll
diff --git a/gnu/packages/python-web.scm b/gnu/packages/python-web.scm
index c1de8197e0..94a7210bbf 100644
--- a/gnu/packages/python-web.scm
+++ b/gnu/packages/python-web.scm
@@ -2454,6 +2454,11 @@ APIs.")
than Python’s urllib2 library.")
(license license:asl2.0)))
+(define (propagated-inputs-filtered overrides old_inputs)
+ (let* ((overrides_names (map caar overrides))
+ (old_inputs_filtered (remove (lambda i (member (caar i) overrides_names) old_inputs
+(concatenate '(old_inputs_filtered overrides
+
;; Some software requires an older version of Requests, notably Docker/Docker
;; Compose.
(define-public python-requests-2.20
@@ -2466,9 +2471,10 @@ than Python’s urllib2 library.")
(base32
"0qzj6cgv3k9wyj7wlxgz7xq0cfg4jbbkfm24pp8dnhczwl31527a"
(propagated-inputs
-`(("python-urllib3" ,python-urllib3-1.24)
- ("python-idna" ,python-idna-2.7)
- ,@(package-propagated-inputs python-requests)
+ `,@(propagated-inputs-filtered
+ `(("python-urllib3" ,python-urllib3-1.24)
+ ("python-idna" ,python-idna-2.7))
+ (package-propagated-inputs python-requests)
(define-public python2-requests
(package-with-python2 python-requests))
Re: A script to check an edit does not break anything
Hello Edouard,
I think you left a hardcoded package name in your script, line 29, fix
with:
s/python-websockets/$package/
Also you sometimes use $package vs ${package}
This kind of thing (maybe converted into scheme what about
`guix before-submit') should be a valuable addition to guix,
it would help beginners (like me do less mistakes) and comitters
could have more confidence in a submission if it has gone through
this. Which would in turn enable us to integrate patches quicker.
WDYT ?
--
Vincent Legoll
Re: [OUTREACHY]: Integration of desktop environments into GNU Guix
Hello Raghav, On 04/06/2020 20:31, Raghav Gururajan wrote: Please find attached patches. Could you add a simple / small description of the patch set each time you send one ? The bare email with only attached files is not directly useful to us mere bystanders, without opening each file which is tedious. So with maybe the `git log --oneline' or something like that we can quickly see if there is something of direct interest and then dig in. Or you can do the usual full dance with an introductory message to guix-patc...@gnu.org, then followed by each patch in a single email (easy to do with `git send-email'). Dunno if that is useful in that case. I hope not to have stepped on mentor's toes with this inquiry ;-) Happy contributing ! -- Vincent Legoll
Re: Request to verify powerpc64-linux bootstrap binaries
Hello, On 02/06/2020 04:56, Chris Marusich wrote: Hopefully, you'll get identical results! You don't have to run "guix gc" if you don't want to, but doing so will increase the likelihood of catching nondeterminism issues propagated from dependencies (which seem unlikely, but you never know). It took 3 or 4 for me hours on a modern 16-core machine. Once we verify the binaries, we can actually start using them to build stuff! Léo has already gotten an optimistic start on that work, and many things are building successfully. Exciting!! Almost there... [A few hours passed...] successfully built /gnu/store/pygln3lr6qbxcps3kmn3w4bc0d0nlpd3-gcc-stripped-tarball-5.5.0.drv building /gnu/store/icnj0m294b94pc3rhpmkz6zc41w8vyqj-bootstrap-tarballs-0.drv... /gnu/store/4v278jn0kd12zc6xwyr144lgi1ca7a69-guile-static-stripped-tarball-2.0.14/guile-static-stripped-2.0.14-powerpc64-linux-gnu.tar.xz -> /gnu/store/dy4fhy2vqyxqfad59mfdqdd0qpcrwmyx-bootstrap-tarballs-0 /gnu/store/rsmhiyplmbiqm1qwniiafi4ak76pd61v-gcc-stripped-tarball-5.5.0/gcc-stripped-5.5.0-powerpc64-linux-gnu.tar.xz -> /gnu/store/dy4fhy2vqyxqfad59mfdqdd0qpcrwmyx-bootstrap-tarballs-0 /gnu/store/fgw2hwyaw00xn8fb1pbpazl8hga8xfci-binutils-static-stripped-tarball-2.34/binutils-static-stripped-2.34-powerpc64-linux-gnu.tar.xz -> /gnu/store/dy4fhy2vqyxqfad59mfdqdd0qpcrwmyx-bootstrap-tarballs-0 /gnu/store/p40gsw7qh5xzic38l99ildbxcz4zag3y-glibc-stripped-tarball-2.31/glibc-stripped-2.31-powerpc64-linux-gnu.tar.xz -> /gnu/store/dy4fhy2vqyxqfad59mfdqdd0qpcrwmyx-bootstrap-tarballs-0 /gnu/store/svc6d7qrmacqc4pqzqhqyks421fb6jcb-static-binaries-tarball-0/static-binaries-0-powerpc64-linux-gnu.tar.xz -> /gnu/store/dy4fhy2vqyxqfad59mfdqdd0qpcrwmyx-bootstrap-tarballs-0 successfully built /gnu/store/icnj0m294b94pc3rhpmkz6zc41w8vyqj-bootstrap-tarballs-0.drv /gnu/store/dy4fhy2vqyxqfad59mfdqdd0qpcrwmyx-bootstrap-tarballs-0 vince@guix ~/dev/repo/guix [env]$ sha512sum /gnu/store/dy4fhy2vqyxqfad59mfdqdd0qpcrwmyx-bootstrap-tarballs-0/* 426e5f1d0d7023a90e73286ccda1fa55a359301e998a19dfe00f5b4f5d387e69d7a247f47056f41e609393893b0238a908698fbd28d73b183b32a5dadcfe9fbb /gnu/store/dy4fhy2vqyxqfad59mfdqdd0qpcrwmyx-bootstrap-tarballs-0/binutils-static-stripped-2.34-powerpc64-linux-gnu.tar.xz 87f7583cf483ac3ba0ab978862873e68757bc4ddd10f739a90a9e4598f79e7fa45ec369c6efcff8d72fba87ea99f1e7a01a39450c7bf20790bc1d89d4b69a15b /gnu/store/dy4fhy2vqyxqfad59mfdqdd0qpcrwmyx-bootstrap-tarballs-0/gcc-stripped-5.5.0-powerpc64-linux-gnu.tar.xz a717a420e765accf12cfc1e18ebed76e9359ee58e8781601ca9066ced59196f88a528ddc554c0f57c77e2c01908cafe596f3c8d1df135beb4cae4073b9a999d2 /gnu/store/dy4fhy2vqyxqfad59mfdqdd0qpcrwmyx-bootstrap-tarballs-0/glibc-stripped-2.31-powerpc64-linux-gnu.tar.xz e2e70c7fcc477fced12eb76704212f9bda0e1ec2cf40137ff6a32a85ca75fec10ec20076b73698438e48c3ce45d24542aa309bb99274f4c3d4f9d49ec9d1dd7b /gnu/store/dy4fhy2vqyxqfad59mfdqdd0qpcrwmyx-bootstrap-tarballs-0/guile-static-stripped-2.0.14-powerpc64-linux-gnu.tar.xz 04d9203467ecb48e9f1fca5130199c292212d4d119153778d398899aeef517fc8bce5d25f3505063f38e433fa09e3c723a6da5dee4943dbc9d3728279356879b /gnu/store/dy4fhy2vqyxqfad59mfdqdd0qpcrwmyx-bootstrap-tarballs-0/static-binaries-0-powerpc64-linux-gnu.tar.xz vince@guix ~/dev/repo/guix [env]$ ./pre-inst-env guix describe Git checkout: repository: /home/vince/dev/repo/guix branch: bootstrap-ppc64le commit: 8159ce1970d91567468cf1bacac313099a009d2a Only gcc differs, I did not use a channel (nor gc'ed) but just a local branch at the right commit: git checkout -b bootstrap-ppc64le 8159ce1970d91567468cf1bacac313099a009d2a make distclean ./bootstrap ./configure --localstatedir=/var make -j 16 ./pre-inst-env guix build --no-substitutes --target=powerpc64-linux-gnu bootstrap-tarballs PS: Yes, it looks like I misnamed my branch, endian-size-wise... -- Vincent Legoll
Re: Should guix track package aliases?
Hello, On 25/05/2020 16:20, Josh Marshall wrote: Checking out repology.org/repository/gnuguix <http://repology.org/repository/gnuguix> , it got picked up and guix looks like it is in much better shape. Yay, but we're still far from the front page's top repositories... But, to celebrate our come back into the fray, I've grabbed a few low hanging fruits from the outdated and/or potentially vulnerable list. Series incoming (on guix-patches, issue #41533)... -- Vincent Legoll
Guix scheme code being recompiled when target ARCH changes
Hello,
I'm wondering if the following is expected:
I'm build the guix binary tarball for i686 & x86_64 (without changing
any scheme code) and the whole guix codebase gets recompiled for each
of the builds.
I'm doing this:
./pre-inst-env make update-guix-package
git add gnu/packages/package-management.scm
git commit -m NOT_FOR_UPSTREAM \
gnu/packages/package-management.scm
SYSTEM=x86_64-linux
./pre-inst-env guix build -s "${SYSTEM}" guix
./pre-inst-env guix pack -s "${SYSTEM}" --localstatedir \
--profile-name=current-guix guix
SYSTEM=i686-linux
./pre-inst-env guix build -s "${SYSTEM}" guix
./pre-inst-env guix pack -s "${SYSTEM}" --localstatedir \
--profile-name=current-guix guix
I intended to run the:
./pre-inst-env make "guix-binary.${SYSTEM}.tar.xz"
afterwards.
Are the .scm files recompilations needed ?
What for ?
And as an additionnal question, are the ./pre-inst-envs needed on
all the CLIs above ?
I still have a TODO to put everything I gathered about building the
binary tarballs in the doc.
I also still cannot test on foreign arches, see:
https://lists.gnu.org/archive/html/guix-devel/2020-05/msg00213.html
Thanks
--
Vincent Legoll
foreign arch binary tarball creation problem
I am trying to build binary tarball for foreign OS / arches, and this is failing, in an unhelpful way. This is guix master branch with a few patches (mostly to etc/guix-install.sh, so I assume they are not the cause of the problem seen here) I have built the i686 & x86_64 ones without any problem. I can create the guix packs: -->88<-- vince@guix ~/dev/repo/guix [env]$ ./pre-inst-env guix pack --target="aarch64-linux-gnu" --localstatedir --profile-name=current-guix guix /gnu/store/d3h12sglx1jb073ybdz39v2qd7ir6xf6-tarball-pack.tar.gz -->88<-- vince@guix ~/dev/repo/guix [env]$ ./pre-inst-env guix pack --target="arm-linux-gnueabihf" --localstatedir --profile-name=current-guix guix /gnu/store/4ab2zgvfvgxlgvm0l07iwa6b1laqwcdj-tarball-pack.tar.gz But building the tarballs fails: -->88<-- vince@guix ~/dev/repo/guix [env]$ ./pre-inst-env make "guix-binary.aarch64-linux.tar.xz" GEN guix-binary.aarch64-linux.tar.xz guix pack: package 'guile3.0-guix' has been superseded by 'guix' The following derivation will be built: /gnu/store/4xwf7y6r1p6q9v2vkvgrxri9r6yvbs1p-guix-1.1.0-4.ce97922.drv building /gnu/store/4xwf7y6r1p6q9v2vkvgrxri9r6yvbs1p-guix-1.1.0-4.ce97922.drv... |builder for `/gnu/store/4xwf7y6r1p6q9v2vkvgrxri9r6yvbs1p-guix-1.1.0-4.ce97922.drv' failed with exit code 1 build of /gnu/store/4xwf7y6r1p6q9v2vkvgrxri9r6yvbs1p-guix-1.1.0-4.ce97922.drv failed View build log at '/var/log/guix/drvs/4x/wf7y6r1p6q9v2vkvgrxri9r6yvbs1p-guix-1.1.0-4.ce97922.drv.bz2'. guix pack: error: build of `/gnu/store/4xwf7y6r1p6q9v2vkvgrxri9r6yvbs1p-guix-1.1.0-4.ce97922.drv' failed cp: cannot stat '': No such file or directory mv: cannot stat 'guix-binary.aarch64-linux.tar.xz.tmp': No such file or directory make: *** [Makefile:6166: guix-binary.aarch64-linux.tar.xz] Error 1 -->88<-- vince@guix ~/dev/repo/guix [env]$ ./pre-inst-env make "guix-binary.armhf-linux.tar.xz" GEN guix-binary.armhf-linux.tar.xz guix pack: package 'guile3.0-guix' has been superseded by 'guix' The following derivation will be built: /gnu/store/hcyy8pgpjs5dga5rj47xjy7s0v8rkd33-guix-1.1.0-4.ce97922.drv building /gnu/store/hcyy8pgpjs5dga5rj47xjy7s0v8rkd33-guix-1.1.0-4.ce97922.drv... |builder for `/gnu/store/hcyy8pgpjs5dga5rj47xjy7s0v8rkd33-guix-1.1.0-4.ce97922.drv' failed with exit code 1 build of /gnu/store/hcyy8pgpjs5dga5rj47xjy7s0v8rkd33-guix-1.1.0-4.ce97922.drv failed View build log at '/var/log/guix/drvs/hc/yy8pgpjs5dga5rj47xjy7s0v8rkd33-guix-1.1.0-4.ce97922.drv.bz2'. guix pack: error: build of `/gnu/store/hcyy8pgpjs5dga5rj47xjy7s0v8rkd33-guix-1.1.0-4.ce97922.drv' failed cp: cannot stat '': No such file or directory mv: cannot stat 'guix-binary.armhf-linux.tar.xz.tmp': No such file or directory make: *** [Makefile:6166: guix-binary.armhf-linux.tar.xz] Error 1 -->88<------ How are the official tarballs created ? What am I doing wrong ? -- Vincent Legoll
Re: Should guix track package aliases?
On 09/05/2020 22:18, Josh Marshall wrote: This appears that it could be low effort, not interfere with any commands, not really change the interface, and make life easier. Anybody have any thoughts as to whether this would be a good idea or not? What about the following: >8---8< # default to list guix things without --all $ guix rosetta [--package|-p] truc-bidule machin-chose (guix) # Show available translations with --all $ guix rosetta --package|-p [--all|-a] truc-bidule bidule-chouette (ubuntu) bouzin (freebsd) machin-chose (guix) truc-bidule (debian) <- this one being also added by --all trucmuche (centos) truc-machin (fedora, rhel) # default to list guix things without --all $ guix rosetta [--service|-s|--daemon] systemctl restart THING herd restart THING # Show available translations with --all $ guix rosetta [--service|-s|--daemon] [--all|-a] herd status THING systemctl status THING (systemd) rcctl check THING (4.4BSD rc) /etc/init.d/THING status (sysv-init) # default to list guix things without --all $ guix rosetta [--command|-c] yum search THING guix search THING # Show available translations with --all $ guix rosetta [--command|-c] [--all|-a] yum install guix package -i (guix official) guix install (guix alias) apt-get install (debian official) apt install (debian alias) yum install (centos) dnf install (fedora, rhel) $ guix rosetta [--help|-h] guix rosetta [--help|-h] [--package|-p] [--command|-c] [--all|-a] THING* Rosetta stone to help translation of various things between unix dialects. The default mode is to only show translation targeting guix. --help|-h Show this help --all|-a Show all available translations for THING --command|-c Show package manager command translations --service|-s|--daemon Show service, daemon manager translations --package|-p Show package names translations This tool is only giving fuzzy answers that may not be fully accurate. >8---8< This would go lovely along the guix foreign distro installer. I'm only (but still only) half-joking, this is a tool I'd have loved to have on multiple occasions, often not on guix. Used googl often being used to approximate it, crudely but effectively. I'm not starting to work on it though, but I'd gladly help anyone who do. -- Vincent Legoll
Re: MIPS support
Hello, I forgot to add that there's actual mips64 HW (Cavium Octeon-based MIPS64 systems) available in the form of the ubiquity routers. OpenBSD supports some of them already, and it looks like nice hw (4 cores @ 1GHz, 1GB RAM). Look for ER-4 or ER-6P, but not the ER-X line as the CPU is not the same and less interesting. -- Vincent Legoll
Re: MIPS support
Hello everybody, I'll do a single email answer, hope that is not off limits... The gnubee is dual-core x 2 threads, 880 MHz 32 bit mips, 512 MB RAM, 2x1Gbps ethernet, 6 SATA ports, SPI flash & microSD, USB 2 & 3, u-boot bootloader. http://gnubee.org https://www.mediatek.com/products/homeNetworking/mt7621n-a To Jack Hill > There seems to be a a fair amount of the router-class hardware available > that works with Free Software, but not much, if any, of the latter, more > powerful hardware. Unfortunately, I think having the more powerful > hardware available would make it much easier to work on the port. Yes, there's only a handful of desktop-class hw available, and it's hard to find, probably expensive too. On the other hand there are a lot of router-class hw, and the gnubee which lies in between . Debian has a lot of mips hw available, see: https://db.debian.org/machines.cgi maybe we can ask for an account there if needed. > I feel similarly. It's always sad to see things go (I used to have a > collection of SPARC hardware, but let it go when I moved a few years ago), > but no need to keep it just for me. I never got my hands on sparc (to own one, we used to have sparcs at school, and even alphas then, I'm getting old...) > Vincent, it sounds like there are at least two of us. Maybe we can work > together. Yes, certainly, I really hope to be able to get something done on that front. To Christopher Baines > At least the main blocker for me is the lack of substitutes for the > things that fail to build with QEMU. So maybe one or a few machines > which were able to build those specific things would be sufficient to > provide some substitutes. I still not have tried mips (arm*, powerpc* and even there I still do not have gone very far, but only tried cross-compilation which has it own set of problems). Can you elaborate a bit, compilation through qemu should be slow but mostly work, at least I hope. We should have a look at debian's arches MLs, there are a lot of efforts made to fix and upstream things, being done there. > I did have a look at seeing if I could purchase hardware, but I didn't > really know what to look at. Maybe we could try putting out an appeal > for MIPS hardware, maybe someone has some they don't use and would > donate? I jumped on the gnubee, as even if it only is 32bit, it was nicer hw than the available routers. I think the crowdsupply campaign founder still had some available last I heard. There are 2 versions one for 2"1/2 drives and one for 3"1/2 that was in a following campaign (I didn't grab one of those). It is not dirt-cheap, though. To Leo Famulari > It's not really a maintenance burden currently since we don't actually > build or maintain the Guix on MIPS at all. OK, that's (kind of) nice to hear, that it is not a great burden for guix maintainer > I think this discussion is evidence that people find the situation a bit > confusing. When I am looking into a project, I find it demotivating to > read documentation about features that may or may not work — it's best > when the documentation accurately reflects what the software can do. Yes, exactly, that's why I asked if there was any incentive to try to document the state and actual efforts being done on the porting front. https://lists.gnu.org/archive/html/guix-devel/2020-04/msg00175.html > So, whether or not to officially retire the Guix MIPS port would not be > related to supporting Guix on the GnuBee, which would be cool! Yes, maybe apart from a few entries in case/switch statements, this would not cost us a lot of SLOCs, then people can build themselves and/or share the results with guix publish, and make it into a collective effort... OpenBSD is also doing a lot of work supporting some select old HW, their ports building time is in weeks for some of them. So it should be doable. > Declarative NAS configuration would be nice :) Yes, the power of guix to the rescue of poor old hw ! > It would be helpful to get some clarification of the relationship > between these architectures before deciding what to do. If none of us has access to any mips64 (which is what I think guix support was targeting), the point is kind of moot. And there's also the problem of guix/scheme being hard on resources (This is something I'm not really sure, but the attempts I did on arm32 were not really promising on that front, which is why I postponed further investigations there. Hoping to get accustomed with guix porting for ppc64 which don't have those problems in the mean time) That was a long one... Thanks everyone for guix it's a refreshing thing ! -- Vincent Legoll
Re: https://guix.gnu.org/packages ?
Hello, On Wed, May 6, 2020 at 3:06 PM zimoun wrote: > Is someone really use this interface [1]? > > [1] https://guix.gnu.org/packages/ Yes, me, sometimes... > Because, when I need something, I prefer to use this one [2]. > > [2] http://hpc.guix.info/browse Because I did not know about this one. I think keeping a js-free one is good, but the UX from HPC's is better, so can we have both ? -- Vincent Legoll
Re: MIPS support
Hello, > In the intervening years, interest faded away as free software friendly > MIPS hardware became more rare. I grabbed a gnubee during the crowdfunding campaign, but the CPU is too low spec to do a lot of compilation on it. > Perhaps it would be more honest to officially remove the MIPS port now? > > Technically that would involve removing it from the manual, from > configure.ac, and little more. >From the manual or from the CI, to let the build farm do more useful things I'm not against, but is it really making maintenance difficult by still being in the codebase ? > If there’s a need for it in the future, and developments happening for > MIPS in general (for the GNU tool chain, the kernel, etc.), then we can > always start a new MIPS port. The kernel side looks good enough to me, there's a lot of openwrt running on mips and it looks well maintained. > Until then, POWER9 and perhaps RISC-V seem to have more > appeal to free software hackers. I have grabbed an old power8, that I also intend to put guix on. > What do people think? I may not be able to put huge time in it so won't ask you to keep it just for me. I'll restart working / trying things in the foreign archs area after my list of pending things is drained a bit (guix-install.sh & tarball CI, native-inputs lint warning chasing) but that's only wishful thinking for now. -- Vincent Legoll
Re: 18/36: services: hurd: Add dummy loopback.
Hello, On Tue, May 5, 2020 at 11:23 AM Ludovic Courtès wrote: > The patch below appears to fix it: Is target-word-size checking always equivalent to cross-compiling ? Aren't there cross-compilation host/target combos where this will be true, but still there will be other differences (endianness maybe) ? I don't know if the question really makes sense, though, so please forgive my ignorance... -- Vincent Legoll
Re: branch master updated: gnu: Add musl-cross.
Hello, On 03/05/2020 22:17, Danny Milosavljevic wrote: The use case is to be able to build heads in Guix without modification. I was about to ask you what was the motivation for that commit, thanks for reading my mind ! I'm obviously interested in the subject. I'd love to explore bootstrapping guix with a musl libc. Also, they are using musl instead of glibc. I don't think we have a musl-gcc yet and I've never done a musl gcc before. We have musl, but are currently disabling the building/installation of its musl-gcc wrapper, I'm not sure you're speaking of this one though. But maybe we can revisit enabling it, I'll put that on my todo list, if you won't beat me to it. -- Vincent Legoll
Re: hint: Run `guix search ... | less' to view all the results
Hello, On Mon, Apr 27, 2020 at 1:59 PM wrote: > imo the best option would be to page, print or truncate depending on > an envvar and/or a commandline flag PAGER="head -20" maybe ? I'm also of the opinion to respect PAGER. Untruncated ouput if unset. -- Vincent Legoll
Re: U-boot update revert.
Hello, On 23/04/2020 21:46, Pierre Langlois wrote: > Switching u-boot's dependency on sdl to sdl2 fixed it for me locally! > > I can send a patch tomorrow if nobody beats me to it :-) The u-boot sandbox switched to SDL2 recently, see: https://gitlab.denx.de/u-boot/u-boot/-/commit/96d0cd460430f18d0f22eead5409ed3dc53b4c4e -- Vincent Legoll
Re: Progress on the Hurd; new state of wip-hurd-vm
Hello, On Mon, Apr 20, 2020 at 7:39 AM Jan Nieuwenhuizen wrote: > Yes, some of them (gnutls, git, python) have just been cleaned-up and > applied to core-updates. nice ! > > I'm looking at the first one (for perl) for example... > > Ah, that one took some review and effort, see https://bugs.gnu.org/40698 > and has now been applied too. Oh, funny, I stumbled upon perl-cross, just after having sent my email. > > So, what's the status of those patches ? > > Hard to tell! Some of those are ready, others need review, others need > work. > > The autotools patches need review, but they work. The patches to > cross-build guix need some discussion and worse, cross-compiling guix > currently uses a terrible kludge; so while also that "works", its still > under development. Thanks a lot for your work ! And also for the status update. -- Vincent Legoll
Re: [PATCH] Fix typo.
Hello Matthew, LGTM, (I think I saw it myself, but forgot about it) I think you should send your patches to: guix-patc...@gnu.org Thanks -- Vincent Legoll
Re: Progress on the Hurd; new state of wip-hurd-vm
Hello, I just had a tour of that branch, it looks like there are interesting patches wrt cross-building, aren't those ready for upstream (core- updates maybe) ? I'm looking at the first one (for perl) for example... I've been trying to cross-compile the binary-tarball to new arches, without any success, all failing the same way, on perl... And when it hit me that there is a recurring theme in those failures I found a few issues and ML posts about the same problem. So, what's the status of those patches ? -- Vincent Legoll
Re: GNU Guix 1.1.0 released
On 19/04/2020 16:35, Marius Bakke wrote: Another question, why is the VM image partitionned like that (root first, then EFI) ? It makes root partition resizing more painful than needed. This one's still bugging me though Not really an answer to your question, but you can safely delete the EFI partition unless you are using QEMU with a UEFI firmware (default is BIOS emulation). Ah, thanks, that is useful info. But I did an install in another disk image... I couldn't find that in the manual, would it be useful to add it ? If yes, where ? -- Vincent Legoll
Re: GNU Guix 1.1.0 released
Hello, On 16/04/2020 00:04, Vincent Legoll wrote: I'm trying the prebuilt VM image and cannot find the /etc/config.scm file on it ? (nor any other system config templates, but I may not be looking at the right places) I see that this is now fixed by: 9d0b9c7c6c0b0d45653dea80b499314ea415d3c7 Another question, why is the VM image partitionned like that (root first, then EFI) ? It makes root partition resizing more painful than needed. This one's still bugging me though -- Vincent Legoll
Re: 1.1.0 for HPC & reproducible research
Hello, On 16/04/2020 14:28, Ludovic Courtès wrote: For the scientists & HPC folks among us, I’ve compiled a list of relevant changes in 1.1.0: https://hpc.guix.info/blog/2020/04/hpc-reproducible-research-in-guix-1.1.0/ Here's my first one for 1.1.0+: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=40691 -- Vincent Legoll
Re: GNU Guix 1.1.0 released
Hello, I'm trying the prebuilt VM image and cannot find the /etc/config.scm file on it ? (nor any other system config templates, but I may not be looking at the right places) This is documented here: 8.16 Running Guix in a Virtual Machine second paragraph. Another question, why is the VM image partitionned like that (root first, then EFI) ? It makes root partition resizing more painful than needed. What am I missing ? -- Vincent Legoll
