Re: Update on wip-arm-bootstrap
Danny Milosavljevic writes: Hey Danny, > On Thu, 18 Feb 2021 22:52:57 +0100 > Jan Nieuwenhuizen wrote: > >> # CONFIG_OABI_COMPAT is not set >> >> ...certainly a lot easier to find when you know what you're looking >> for. >> >> @Danny: I'm wondering if we could (should?) try a kernel with OABI >> compatibility? I suppose it would be better to somehow target >> EABI...but I'm not sure that's possible with glibc-2.2.5 / gcc-2.95.3. >> Interesting choices here! > > OABI is older than year 2000, and the kernel docs say not to enable it. > It also breaks seccomp. > I doubt that people have it enabled, and thus would have trouble reproducing > our stuff. Okay, I agree; better to not go this route if we can avoid it. > Since this only affects the syscall interface and since also our > ELF headers specify EABI, I would just change the syscalls to EABI: > Just put the syscall number into r7 and use svc 0. Oh, if that's all we should be able to find and fix it? > I'd do it myself but I don't see what libc the gcc 2.95 we built has been > using. > Is it ours? > If so, how come it then uses svc 9... in the first place? > We don't do that. > > Or is it using glibc ? Not it's not ours, it's gcc-core-mesboot0-2.95.3 binaries built against glibc-mesboot0-2.2.5. So then it's probably glibc-2.2.5 that is using/built for OABI. I didn't know of OABI before, but did look for EABI options and didn't find any in those early gcc/glibc's... We'll have to see if that glibc can be built for OABI, possibly by patching it. If we need to upgrade glibc then that may be an "interesting" undertaking... >From Vagrant's link, I found that Lenny (5.0) is the first armel (EABI) release, it uses glibc-2.7, gcc-4.1, binutils-2.18. > How do I build that gcc on novena? Where would the syscall headers that > I could change be? On latest wip-arm-bootstrap 3c78496c32 DRAFT gnu: mes: Update to 0.22-124-33cf5ea5e8. then building ./pre-inst-env guix build -e '(@@ (gnu packages commencement) gcc-mesboot0)' will be using the gcc,glibc,binutils that's broken and configure will fail on running a conftest. You can get the PATH and other environment settings from that build. I have those settings also in a script: novena:~janneke/src/guix/gcc-mesboot.sh is a reproducer. Greetings, Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: Update on wip-arm-bootstrap
Hi Janneke, On Thu, 18 Feb 2021 22:52:57 +0100 Jan Nieuwenhuizen wrote: > # CONFIG_OABI_COMPAT is not set > > ...certainly a lot easier to find when you know what you're looking > for. > > @Danny: I'm wondering if we could (should?) try a kernel with OABI > compatibility? I suppose it would be better to somehow target > EABI...but I'm not sure that's possible with glibc-2.2.5 / gcc-2.95.3. > Interesting choices here! OABI is older than year 2000, and the kernel docs say not to enable it. It also breaks seccomp. I doubt that people have it enabled, and thus would have trouble reproducing our stuff. Since this only affects the syscall interface and since also our ELF headers specify EABI, I would just change the syscalls to EABI: Just put the syscall number into r7 and use svc 0. I'd do it myself but I don't see what libc the gcc 2.95 we built has been using. Is it ours? If so, how come it then uses svc 9... in the first place? We don't do that. Or is it using glibc ? How do I build that gcc on novena? Where would the syscall headers that I could change be? pgp_fN0CcT3Ao.pgp Description: OpenPGP digital signature
Re: Update on wip-arm-bootstrap
Vagrant Cascadian writes: Hi! > On 2021-02-13, Jan Nieuwenhuizen wrote: [..] >> ...pretty familiar. So, what's going on here? Do the "woody" >> binaries not run on novena? > > My guess would be OABI (debian "arm" architecture) vs. EABI (debian > "armel" or "armhf" architectures). The hardware may likly support OABI, > but the kernel may need a compatibility layer enabled. > > https://wiki.debian.org/ArmPorts Ah, interesting. The kernel config has # CONFIG_OABI_COMPAT is not set ...certainly a lot easier to find when you know what you're looking for. @Danny: I'm wondering if we could (should?) try a kernel with OABI compatibility? I suppose it would be better to somehow target EABI...but I'm not sure that's possible with glibc-2.2.5 / gcc-2.95.3. Interesting choices here! Greetings, Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: Gnome Boxes
Sorry, a compressed .iso is probably common, a .iso.xz is very uncommon :). We even have had some reports of people trying to copy that directly to an installation media. Le 18 février 2021 14:56:44 GMT-05:00, Tobias Geerinckx-Rice a écrit : >Julien Lepiller 写道： >> Usually compression is provided by the webserver, but maybe ours >> is not configured to do that. I think we're the only distro to >> provide compressed isos. > >Really? Most distribution ISOs use squashfs or similar with >XZ/LZMA compression. It doesn't make sense to compress that over >the wire. > >That said: XZ compression currently saves 27% (559M -> 405M). >Transparently serving pre-compressed ISOs with nginx (gzip level >9) would save about 25% (559M -> 415M), which is surprisingly >similar. > >Kind regards, > >T G-R
Re: Gnome Boxes
Julien Lepiller 写道： Usually compression is provided by the webserver, but maybe ours is not configured to do that. I think we're the only distro to provide compressed isos. Really? Most distribution ISOs use squashfs or similar with XZ/LZMA compression. It doesn't make sense to compress that over the wire. That said: XZ compression currently saves 27% (559M -> 405M). Transparently serving pre-compressed ISOs with nginx (gzip level 9) would save about 25% (559M -> 415M), which is surprisingly similar. Kind regards, T G-R signature.asc Description: PGP signature
Guix Packaging Meetup Wednesday February 24 7PM EST
Hi Guix, LibreMiami is hosting a guix packaging meetup next Wednesday, February 24 at 7pm EST. We'll be working on packaging bitmask-vpn. The format for the meetup will involve chatting over LibreMiami's mumble instance while pair programming together on a guix system VPS. Feel free to package with us, watch us via the livestream, or just chat with us over mumble. Here's the meeting link with info on the event and how to join: https://gettogether.community/events/9711/guix-packaging-meetup Hope to see you there! jgart https://libremiami.org https://search.libremiami.org https://gitlab.com/libremiami
Re: New backward incompatible version of Guile Config
Hi Ludo, Hope you're good :-) Ludovic Courtès writes: > Hi Alex! > > Alex Sassmannshausen skribis: > >> To this end, in the attached patch, I add a new variable for 0.5. My >> intention is to have 0.4.2 and 0.5 coexist for a while and then to >> switch fully to 0.5 in due course. >> >> >> Is this an acceptable way of doing a gradual transition to a backwards >> incompatible version of the library? > > Definitely! We’ve done that in the past for Guile-JSON, among others. > > Should we commit it on your behalf? Yes indeed, please go ahead! Cheers :) Alex > > Thanks, > Ludo’. signature.asc Description: PGP signature
Re: [PATCH] Make assert-valid-graph public
Sent to the this mailing list by mistake, please ignore it. Forwarded to guix-patches. On Thu, Feb 18, 2021 at 1:37 PM Andrew Tropin wrote: > > I would like to reuse this function for home-shepherd-service for `guix > home` I'm currently implementing. It seems reasonable to make this > function public instead of copying or reimplementing it. > -- Best regards, Andrew Tropin
Re: Joining committers
On Thu, 2021-02-18 at 10:20 -0500, Joshua Branson wrote: > Are you running Debian on the PowerPC? I assume Debian's got the > best > PowerPC support. Do most programs compile ok/work ok for Debian? I run Fedora currently because that's where the support came first and I think that's where it's best still since Red Hat markets a product that supports the platform commercially as well. But today Debian is fine too. The release model of Fedora made it easier to get incremental improvement on PowerPC 64-bits platform support while still maintaining a well tested and usable system, I didnt think I could obtain such with Debian at install time, but maybe, on testing etc. channels. > Please do consider setting up a patreon/librepay account! Marketing > helps too! For now it is fine, also I don't feel like that would work for now :-| I am on my learning path still! Léo signature.asc Description: This is a digitally signed message part
Re: Gnome Boxes
Usually compression is provided by the webserver, but maybe ours is not configured to do that. I think we're the only distro to provide compressed isos. Le 18 février 2021 12:18:44 GMT-05:00, "Ludovic Courtès" a écrit : >Hi, > >Julien Lepiller skribis: > >> When submitting the MR to libosinfo, there were concerns that the .xz >extension would cause problems with other software, so we left it out. >> >> I think we should provide a .iso download directly, if we want gnome >boxes to propose the guix system. > >We could do that but… isn’t it a bit ridiculous? I mean, compression >is >a well-known technique to reduce bandwidth usage, right? :-) > >That said, we now produce compressed ISOs IIRC, so it might be that the >extra compression layer doesn’t buy us much. Would be worth checking! > >Thanks, >Ludo’.
Re: New backward incompatible version of Guile Config
Hi Alex! Alex Sassmannshausen skribis: > To this end, in the attached patch, I add a new variable for 0.5. My > intention is to have 0.4.2 and 0.5 coexist for a while and then to > switch fully to 0.5 in due course. > > > Is this an acceptable way of doing a gradual transition to a backwards > incompatible version of the library? Definitely! We’ve done that in the past for Guile-JSON, among others. Should we commit it on your behalf? Thanks, Ludo’.
Re: How to store secrets when using guix deploy?
Hi! Leo Prikler skribis: > That's the status quo as far as I understand. How it *should* handle > secrets remains an open question if I recall correctly. Yeah that’s mostly true, though ‘secret-service-type’ in (gnu services virtualization) shows a simple solution for VMs hosted by Guix System (childhurds in this case). Ludo’.
Re: TOCTTOU race
Hi Maxime, Maxime Devos skribis: > From ad10c577eb1f13b9b66ea387648671df33b869d7 Mon Sep 17 00:00:00 2001 > From: Maxime Devos > Date: Sun, 14 Feb 2021 12:57:32 +0100 > Subject: [PATCH] services: prevent following symlinks during activation > > Currently, there's a TOCTTOU race. This can be addressed > once guile has bindings for fstatat, openat and friends. > > XXX I'm horrible at naming exceptions: > (throw 'XXX-TODO-does-someone-have-an-idea? path) > > * guix/build/service-utils.scm: new module > with new procedure 'mkdir-p/perms'. > * Makefile.am (MODULES): compile new module. > * gnu/services/authentication.scm > (%nslcd-activation, nslcd-service-type): use new procedure. > * gnu/services/cups.scm (%cups-activation): likewise. > * gnu/services/dbus.scm (dbus-activation): likewise. > * gnu/services/dns.scm (knot-activation): likewise. Nice! > +(define-module (guix build service-utils) > + #:use-module (ice-9 match) > + #:use-module (guix build utils) > + #:export (mkdir-p/perms)) I think this should go either in (gnu build activation) or in a new (gnu build utils) module. (guix build …) is for non-Guix-System things. > +;; Based upon mkdir-p from (guix build utils) > +(define (verify-not-symbolic dir) > + "Verify DIR or its ancestors aren't symbolic links." > + (define absolute? > +(string-prefix? "/" dir)) > + > + (define not-slash > +(char-set-complement (char-set #\/))) > + > + (define (verify-component path) > +(when (eq? 'symlink (stat:type (lstat path))) > + (throw 'XXX-TODO-does-someone-have-an-idea? path))) It’s tempting to do something like: (error "file name component is a directory" dir) Note that, if that happens at boot time, the system will fail to boot (I think you’d get a REPL rather than a kernel panic, but it’d be good to check in a VM.) > + (let loop ((components (string-tokenize dir not-slash)) > + (root (if absolute? > + "" > + "."))) > +(match components > + ((head tail ...) > + (let ((path (string-append root "/" head))) Per GNU and Guix convention, “path” is for “search paths”; here it should be “file” or something. > + (catch 'system-error > + (lambda () > + (verify-component path) > + (loop tail path)) > + (lambda args > + (if (= ENOENT (system-error-errno args)) > + #t > + (apply throw args)) > + (() #t That reminded me of the ‘safe_path’ function in OpenSSH, but that one checks the permissions on file name components, and doesn’t check for symlinks (maybe it should; there’s an XXX comment there.) > +(define (mkdir-p/perms directory owner bits) > + "Create the directory DIRECTORY and all its ancestors. > +Verify no component of DIRECTORY is a symbolic link. > +Warning: this is currently suspect to a TOCTOU race!" > + (verify-not-symbolic directory) > + (mkdir-p directory) > + (chown directory (passwd:uid owner) (passwd:gid owner)) > + (chmod directory bits)) Otherwise LGTM, thanks! Ludo’.
Re: Update on wip-arm-bootstrap
On 2021-02-13, Jan Nieuwenhuizen wrote: > Let's try to bisect where the problem is; we now have tree first > candidates: gcc-core-mesboot0, glibc-mesboot0 and binutils-mesboot0. > Luckily, Debian "woody" carries an almost compatible set. Doing > someting like > > --8<---cut here---start->8--- > guix environment --ad-hoc binutils patchelf wget > wget > http://archive.debian.org/debian/pool/main/g/glibc/libc6_2.2.5-11.8_arm.deb > ar x libc6_2.2.5-11.8_arm.deb > tar xf data.tar.gz > wget > http://archive.debian.org/debian/pool/main/g/glibc/libc6-dev_2.2.5-11.8_arm.deb > ar x libc6-dev_2.2.5-11.8_arm.deb > tar xf data.tar.gz > wget > http://archive.debian.org/debian/pool/main/b/binutils/binutils_2.12.90.0.1-4_arm.deb > ar x binutils_2.12.90.0.1-4_arm.deb > tar xf data.tar.gz > wget > http://archive.debian.org/debian/pool/main/g/gcc-2.95/gcc-2.95_2.95.4-27_arm.deb > ar x gcc-2.95_2.95.4-27_arm.deb > tar xf data.tar.gz > patchelf --print-interpreter usr/bin/as > /lib/ld-linux.so.2 > patchelf --set-interpreter $PWD/lib/ld-linux.so.2 usr/bin/as > usr/bin/as > Illegal instruction > --8<---cut here---end--->8--- > > Hmm...does it? Using gdb, the problem looks... > > --8<---cut here---start->8--- > Program received signal SIGILL, Illegal instruction. > 0xb6ff3b6c in writev () from /home/janneke/src/debian/lib/ld-linux.so.2 > (gdb) disas /r > Dump of assembler code for function writev: > [..] >0xb6ff3b58 <+28>: 05 20 a0 e1 mov r2, r5 >0xb6ff3b5c <+32>: 07 10 a0 e1 mov r1, r7 >0xb6ff3b60 <+36>: 00 80 90 e5 ldr r8, [r0] >0xb6ff3b64 <+40>: 06 00 a0 e1 mov r0, r6 >0xb6ff3b68 <+44>: 92 00 90 ef svc 0x00900092 > => 0xb6ff3b6c <+48>: 00 40 a0 e1 mov r4, r0 > --8<---cut here---end--->8--- > > ...pretty familiar. So, what's going on here? Do the "woody" > binaries not run on novena? My guess would be OABI (debian "arm" architecture) vs. EABI (debian "armel" or "armhf" architectures). The hardware may likly support OABI, but the kernel may need a compatibility layer enabled. https://wiki.debian.org/ArmPorts live well, vagrant signature.asc Description: PGP signature
Re: Getting the Guix Build Coordinator agent working on the Hurd
Hi! Christopher Baines skribis: > Then I faced two problems with the guix-build-coordinator > package. Firstly, wrap-program picks bash for Linux for the wrapper > script, which isn't very useful. I hacked around this by setting the > PATH such that it picked bash for the Hurd. In terms of properly fixing > this, I guess that needs to somehow be able to find the right bash, I'm > not sure how though? Looks like a bug in ‘wrap-program’ that we should fix in ‘core-updates’. ‘wrap-program’ uses (which "bash"), which is wrong in a cross-compilation context. We should at least add a #:bash parameter to ‘wrap-program’, but then all callers will have to pass it. I’m not sure how to let it do the right thing by default. > The second issue is that I'm not sure capturing the build time > GUILE_LOAD_COMPILED_PATH doesn't seem to work, at least file says that > the .go files this contains are built for a 64-bit architecture. I > worked around this by constructing the GUILE_LOAD_COMPILED_PATH from the > inputs I knew should be on it. Maybe it should always have been done > this way, any ideas? Instead of capturing the build-time ‘GUILE_LOAD_COMPILED_PATH’, which doesn’t contain the target .go files, you should explicitly list the inputs as is done in the ‘guix’ package for example. That’ll ensure the binary refers to the cross-compiled .go files. > There's also one problem probably within the Guix Build Coordinator > itself, after doing a few builds, it will just stop. I've only seen this > behaviour on the Hurd, but I'm unsure how to debug it, any suggestions? > My only idea is add more logging. No idea, but I guess that could just be a crash. Can you still log in afterwards? BTW, note that builds on GNU/Hurd are currently not isolated, and thus it’s the wild west in terms of reproducibility: https://issues.guix.gnu.org/43857 There are open questions as to what to include in the build environment: https://guix.gnu.org/en/blog/2020/childhurds-and-substitutes/ Ludo’.
Re: Update on wip-arm-bootstrap
Hi! I read the story, which I found rather fun and full of suspense, but I admit I was disappointed by the ending. :-) Jan Nieuwenhuizen skribis: > ...pretty familiar. So, what's going on here? Do the "woody" > binaries not run on novena? Does that mean there are no old reference binaries known to work on Novena? Ludo’.
Re: Gnome Boxes
Hi, Julien Lepiller skribis: > When submitting the MR to libosinfo, there were concerns that the .xz > extension would cause problems with other software, so we left it out. > > I think we should provide a .iso download directly, if we want gnome boxes to > propose the guix system. We could do that but… isn’t it a bit ridiculous? I mean, compression is a well-known technique to reduce bandwidth usage, right? :-) That said, we now produce compressed ISOs IIRC, so it might be that the extra compression layer doesn’t buy us much. Would be worth checking! Thanks, Ludo’.
Fix seg-faulting of telegram-desktop
From 15b14fda8d954d184b3509359ae440dd47ab2ff6 Mon Sep 17 00:00:00 2001
From: Raghav Gururajan
Date: Thu, 18 Feb 2021 11:23:16 -0500
Subject: [PATCH 1/2] gnu: webrtc-for-telegram-desktop: Compile with gcc-9.
* gnu/packages/telegram.scm (webrtc-for-telegram-desktop) [native-inputs]: Add gcc-9.
---
gnu/packages/telegram.scm | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gnu/packages/telegram.scm b/gnu/packages/telegram.scm
index 2430242241..5eb4081363 100644
--- a/gnu/packages/telegram.scm
+++ b/gnu/packages/telegram.scm
@@ -126,7 +126,8 @@
(copy-recursively libyuv-from libyuv-to))
#t)
(native-inputs
-`(("pkg-config" ,pkg-config)
+`(("gcc" ,gcc-9)
+ ("pkg-config" ,pkg-config)
("python" ,python-wrapper)
("yasm" ,yasm)))
(inputs
--
2.30.1
From 98cb75d0c5235bfca33f7188f356985b744e1d08 Mon Sep 17 00:00:00 2001
From: Raghav Gururajan
Date: Thu, 18 Feb 2021 11:28:01 -0500
Subject: [PATCH 2/2] gnu: webrtc-for-telegram-desktop: Add missing input.
* gnu/packages/telegram.scm (webrtc-for-telegram-desktop) [native-inputs]: Add perl.
---
gnu/packages/telegram.scm | 1 +
1 file changed, 1 insertion(+)
diff --git a/gnu/packages/telegram.scm b/gnu/packages/telegram.scm
index 5eb4081363..661d390dbf 100644
--- a/gnu/packages/telegram.scm
+++ b/gnu/packages/telegram.scm
@@ -127,6 +127,7 @@
#t)
(native-inputs
`(("gcc" ,gcc-9)
+ ("perl" ,perl)
("pkg-config" ,pkg-config)
("python" ,python-wrapper)
("yasm" ,yasm)))
--
2.30.1
OpenPGP_signature
Description: OpenPGP digital signature
Re: Joining committers
Léo Le Bouter writes: > I've been working on PowerPC 64-bits support on and off on GNU Guix > since 2 years as I own a RaptorCS Talos II machine at home that runs > with only free firmware and software. Are you running Debian on the PowerPC? I assume Debian's got the best PowerPC support. Do most programs compile ok/work ok for Debian? > I have a lot of time these days (choose to leave all jobs and focus on > what I like) so as my learning of GNU Guile, Scheme and GNU Guix > improves, expect me on all fronts! Please do consider setting up a patreon/librepay account! Marketing helps too! > > Thank you! > > Léo Le Bouter > -- Joshua Branson (joshuaBPMan in #guix) Sent from Emacs and Gnus https://gnucode.me https://video.hardlimit.com/accounts/joshua_branson/video-channels https://propernaming.org "You can have whatever you want, as long as you help enough other people get what they want." - Zig Ziglar
Re: Joining committers
> Hello! > > I sent a commit access application few days ago and it was approved! I > am really happy that is the case! That's great, Léo. Thank you for sharing your work :)
Re: License Problem and Other Questions defining new package Geant4 from CERN for Partical Physcis Simulation
Hello Sebastian,
Am Donnerstag, den 18.02.2021, 15:04 +0800 schrieb Sebastian:
> Dear developers at Guix,
>
> I am a physics student willing to use the Geant4 simulation toolkit
> from the European Organization for Nuclear Research (CERN).
> https://geant4.web.cern.ch/
> The Geant4 code is distributied under its own licence, Geant4
> Software License Version 1.0.
> https://geant4.web.cern.ch/license/LICENSE.html
> Let's call this license G4SL1.0. After some searching, finding it is
> NOT listed by FSF or GNU in their license list.
> https://www.gnu.org/licenses/license-list.html
> But from a personal perspective, G4SL1.0 do seems like a free
> software license.
> So, may it be included into the Guix proper (gnu packages)?
You should drop a mail to licens...@fsf.org. On a quick glance, it
appears as though the Geant4 devs had a look at the original BSD
license and thought to themselves "I want that, but harder".
> I am currently testing the package under a custom channel,using
> cmake-build-system.
> https://git.nju.edu.cn/nju/chngix/-/blob/master/gix/packages/geant4.scm
>
> Here is another problem:
> during configuring command "cmake" on a non-Guix system,
> -- Geant4 has been pre-configured to look for datasets in the
> directory:
> -- /usr/local/share/Geant4-10.7.1/data
> the user needs to download datasets and unpack them under that
> directory.
> https://geant4.web.cern.ch/support/download
> Or, set flag -DGEANT4_INSTALL_DATA=ON to automatically download the
> datasets during building.
> On Guix however,
> -- Geant4 has been pre-configured to look for datasets in the
> directory:
> -- /gnu/store/byprhqa1qq6s0ksgdpjgwv58ak25kprd-geant4-
> 10.07.p01/share/Geant4-10.7.1/data
> the building process is sandboxed, and does not allow download during
> building that causing non-repuduciable build result.
> Cmake flag GEANT4_INSTALL_DATADIR defaults to "share", a path
> relative to CMAKE_INSTALL_PREFIX,
> and it can be set to define the directory storing datasets other than
> ../share, but datastes should always be under
> "GEANT4_INSTALL_DATADIR/Geant4-10.7.1/data".
> https://geant4-userdoc.web.cern.ch/UsersGuides/InstallationGuide/html/installguide.html#geant4buildoptions
> But the (source origin) denotes "a file" only,
> https://guix.gnu.org/manual/en/html_node/package-Reference.html
> is it possible to define a package fetching multiple files and
> extracts them into the desired directory, using the Guix package
> definition?
The "proper" way of fixing this would be to patch Geant, so that it
takes data from a configurable directory or path (e.g.
GEANT4_DATA_PATH), so that this can be set through a native-search
path, or alternatively honor XDG_DATA_DIRS, depending on what makes
more sense.
However, if fixing the narrower problem of lacking some important files
is all, that is needed, you can specify an origin to the data as an
input. Assuming that you add ("geant-data" ,(origin ...)) to your
inputs, you then simply need to add a phase, which recursively copies
(assoc-ref inputs "geant-data") to wherever you need it.
Note, that either way you should probably make it so that you're not
relying on such a specific version in your install paths.
> I am not familiar with trivial-build-system.
> The build and install of the geant4 without datasets using cmake-
> build-system seems to be successful.
> Your help would be much appreciated.
This should be doable with cmake-build-system. Alternatively, if you
want the data as an extra package, you can use copy-build-system for
it.
Regards,
Leo
Joining committers
Hello! I sent a commit access application few days ago and it was approved! I am really happy that is the case! I've been working on PowerPC 64-bits support on and off on GNU Guix since 2 years as I own a RaptorCS Talos II machine at home that runs with only free firmware and software. I also use GNU Guix as my daily driver system on my laptop since around 6 months. I feel really happy finding out about GNU Guix in general, I love the community and the fact that it is a GNU project, I really like that we can solve fundamental computer problems with a software freedom philosophy free of any contradictory interest. I have a lot of time these days (choose to leave all jobs and focus on what I like) so as my learning of GNU Guile, Scheme and GNU Guix improves, expect me on all fronts! Thank you! Léo Le Bouter signature.asc Description: This is a digitally signed message part
[PATCH] Make assert-valid-graph public
I would like to reuse this function for home-shepherd-service for `guix home` I'm currently implementing. It seems reasonable to make this function public instead of copying or reimplementing it. >From ffc244f5845996bf4b0365024ac866c86cef81df Mon Sep 17 00:00:00 2001 From: Andrew Tropin Date: Thu, 18 Feb 2021 13:30:22 +0300 Subject: [PATCH] gnu: services: shepherd: Make assert-valid-graph public --- gnu/services/shepherd.scm | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/gnu/services/shepherd.scm b/gnu/services/shepherd.scm index e2ec59f5aa..38b35b6154 100644 --- a/gnu/services/shepherd.scm +++ b/gnu/services/shepherd.scm @@ -73,7 +73,9 @@ shepherd-service-back-edges shepherd-service-upgrade -user-processes-service-type)) +user-processes-service-type + +assert-valid-graph)) ;;; Commentary: ;;; -- 2.30.1
License Problem and Other Questions defining new package Geant4 from CERN for Partical Physcis Simulation
Dear developers at Guix, I am a physics student willing to use the Geant4 simulation toolkit from the European Organization for Nuclear Research (CERN). https://geant4.web.cern.ch/ The Geant4 code is distributied under its own licence, Geant4 Software License Version 1.0. https://geant4.web.cern.ch/license/LICENSE.html Let's call this license G4SL1.0. After some searching, finding it is NOT listed by FSF or GNU in their license list. https://www.gnu.org/licenses/license-list.html But from a personal perspective, G4SL1.0 do seems like a free software license. So, may it be included into the Guix proper (gnu packages)? I am currently testing the package under a custom channel,using cmake-build-system. https://git.nju.edu.cn/nju/chngix/-/blob/master/gix/packages/geant4.scm Here is another problem: during configuring command "cmake" on a non-Guix system, -- Geant4 has been pre-configured to look for datasets in the directory: -- /usr/local/share/Geant4-10.7.1/data the user needs to download datasets and unpack them under that directory. https://geant4.web.cern.ch/support/download Or, set flag -DGEANT4_INSTALL_DATA=ON to automatically download the datasets during building. On Guix however, -- Geant4 has been pre-configured to look for datasets in the directory: -- /gnu/store/byprhqa1qq6s0ksgdpjgwv58ak25kprd-geant4-10.07.p01/share/Geant4-10.7.1/data the building process is sandboxed, and does not allow download during building that causing non-repuduciable build result. Cmake flag GEANT4_INSTALL_DATADIR defaults to "share", a path relative to CMAKE_INSTALL_PREFIX, and it can be set to define the directory storing datasets other than ../share, but datastes should always be under "GEANT4_INSTALL_DATADIR/Geant4-10.7.1/data". https://geant4-userdoc.web.cern.ch/UsersGuides/InstallationGuide/html/installguide.html#geant4buildoptions But the (source origin) denotes "a file" only, https://guix.gnu.org/manual/en/html_node/package-Reference.html is it possible to define a package fetching multiple files and extracts them into the desired directory, using the Guix package definition? I am not familiar with trivial-build-system. The build and install of the geant4 without datasets using cmake-build-system seems to be successful. Your help would be much appreciated. With best regards, Sebastian
Re: Getting the Guix Build Coordinator agent working on the Hurd
Christopher Baines writes: > For the guix.cbaines.net build farm, I've now got an additional machine > running two childhurd VM's, and I plan to scale this up to 7 or 8 in the > coming days to see how far it's possible to get building things for the > i586-gnu. This has now happened, I've now got one machine running 8 childhurd VMs, and another machine just running the one childhurd. Builds for packages seem to be happening (see [1] and [2]), although I'm suspicious some of the VMs are getting stuck sometimes, as I can't always SSH in. There's also the GC not working issue, but both things can be worked around by just restarting the VMs. 1: https://data.guix-patches.cbaines.net/repository/2/branch/master/latest-processed-revision/package-derivations?search_query==i586-gnu_builds=_builds=_status=working=builds_name=_results=_results=on 2: https://data.guix-patches.cbaines.net/repository/2/branch/master/latest-processed-revision/package-derivations?search_query==i586-gnu_builds=_builds=_status=failing=builds_name=_results=_results=on It would be useful to be able to compare builds for packages across different architectures, to find instances where a package builds, but not on all architectures, as those could be useful to know about (either to try and fix, or change to just support the working architectures in the package definition). signature.asc Description: PGP signature
