<vagrantc>maybe i should just upload and get it over with... <vagrantc>hrm. swear i had a version that i coudl consistantly build and pass all the tests i hadn't yet disabled... <pineapples>mbakke: Will definitely do. In any case, thank you for showing interest in my suggestion <vagrantc>gah. tests/derivations.scm has non-deterministic failures. <civodul>vagrantc: ok, the situation sounds... rather good i guess? <civodul>weird that you see non-deterministic failures in there <vagrantc>civodul: basically, need to disable all the network tests and tests that use any bootstrap binaries ... and still i seem to get various test suite failures <vagrantc>marking all tests using bootstrap binaries with (unless (network-reachable?) (test-skip 1)) <vagrantc>which is a lot of them, and there's probably a better way to do this ... :/ <vagrantc>i also haven't actually tested that the package works in ages. :) <civodul>vagrantc: for the 'guix' package, we pre-download those bootstrap binaries so we can run the tests <civodul>disabling all of them sounds tedious and it amounts to skipping a large part of the test suite <vagrantc>oh, i also tried to make a guix-tarball package that inherited from guix, but for some reason i couldn't get guix to recognize that the package existed ... is there something special about "guix" that makes inherit work more unusually than other packages? <vagrantc>civodul: so, in debian there are build-time tests, which cannot access the network at all, or download any binaries through any means other than depending on other packages <civodul>ah, so you'd need to create "packages" just for the purposes of having these things downloaded, right? <vagrantc>and a relatively new thing is autopkgtests, which are run-time tests of the installed package, and can access the network *vagrantc carries on two simultaneous threads with one other party :) <civodul>thinking about it, another option would be to use statically-linked mkdir, tar, sh from Debian instead of these <vagrantc>civodul: well, skip all the bootstrap tests from build-time, but run all or most of the tests in the run-time tests <civodul>or even dynamically-linked, it may not matter <civodul>so like, if you arrange for search-bootstrap-binary to return /bin/mkdir etc. <vagrantc>i think we tried that last time i really went for this, and it seemed to have other issues? <civodul>at worst, a statically-linked Busybox or whatever would do <vagrantc>it won't break the expectations of the hash around these things? <civodul>but yeah i have a vague recollection that we discussed it long ago :-) <vagrantc>i can try again, as this is getting quite tedious <civodul>see search-bootstrap-binary: you can drop these files under $srcdir and they'll be picked up <vagrantc>ah, i remember ... it uses i686-linux bootstrap binaries even on x86_64 <civodul>so gnu/packages/bootstrap/i686-linux/mkdir, etc. <civodul>i think each one has its binaries, x86_64/i686 is the exception <civodul>oh right, you'd also need to copy bootstrap-guile as in the phase shown above <vagrantc>if that will actually work, that sounds better than disabling boatloads of tests <civodul>for bootstrap-guile, if may be that you could just copy Debian's dynamically-linked Guile in the right place <vagrantc>ok, this build happened to work... uploading :) <vagrantc>can always fix the test suites better later *civodul -> zZz .oO dreams of Debian <vagrantc>oh hrm. i should've split /usr/share/../*.scm into it's own package... <xelxebar>Man, I'd really like a reverse-search that spits out packages that provide a given path-name regex. <vagrantc>there has been some work in that direction... <xelxebar>vagrantc: Oh, really. Very cool. I was just about to offer some help in that direction. <xelxebar>Would you happen to know where to find discussion threads on this topic? <xelxebar>Ah, there's a "command-not-found" thread in the guix-devel mailing list. <vagrantc> August 10 Pierre Neidhardt ┬►File search progress: database review and question on triggers <vagrantc>that said, i would not be surprised if it gets rejected <vagrantc>a huge package, likely i did something wrong <xelxebar>Man Pierre is a monster. It seems like he has his hands on all the cool Guix (and Lisp in general) things! <xelxebar>drakonis: The idea isn't super new, but apparently he has been working on a file search in guix, so you can find which packages provides some file/path. <wleslie>how do I convince gcc 10.2.0 to build me a crtbegin.o? I'd been adding `extra_parts="crtbegin.o crtend.o"` to config.gcc but now that I grep around I see that neither these values nor this variable is used by any other target <wleslie>there's some make snippet that others use called `i386/t-crtstuff` but I'm not sure where this lives <wleslie>ah, these variables probably need to go into libgcc/config.host <librem>I am trying to build guix (on ZorinOS, based on ubuntu) but when I run ./configure it says:checking if (git) is available... noconfigure: error: Guile-Git is missing; please install it. <librem>So I built guile-git-0.4.0 and installed it, and set the environment vars. Here's my ./configure (at the bottom) and the README doc of Guile-Git and the relevant environment vars section of the Guile manual. https://paste.debian.net/1170455/ ***apteryx is now known as Guest52565
***apteryx_ is now known as apteryx
<xelxebar>librem: You are running in a --pure guix env, right? <librem>no, not a --pure guix env, it's on ZorinOS <vits-test>librem: IDK if that'll help, but can U install binary `guix` on top of Zorin, with the installation script? <vits-test>`guix environment` makes things easier a lot (usually). <vits-test>nckx: Hello again; about NVRAM and GRUB: what if Guix use the Boot Loader Specification? Basically grub just loades some files from disk/dir/* and builds a menu (as i remember it was in Fedora). <xelxebar>librem: So just to be clear, you are trying to build guix using the the binarios from ZorinOS, not using guix? <xelxebar>If so, you probably want to look into the guix bootstrapping stuff (caveat, I have no experience with this). <xelxebar>However, if you just want to hack on guix, then the normal way is to install guix on your distro first, then build things from a guix environment [--pure] guix. <xelxebar>Unrelated: Anyone ever run into this error? Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS <xelxebar>Trying to build a haskell package and guix is bailing (before any build phases) with that error <xelxebar>I just did a `guix import hackage -r matterhorn` and lightly edited the resulting collection of packages to resolve some version dependencies. <vits-test>can U paste a definition, i want to run guix build on it? <efraim>no clue, but my guess is if it's from haskell... no idea. if it's from guix/guile, then look for circular package definitions <xelxebar>You will probably have to edit that a bit. That's just the file from my private channel. <xelxebar>efraim: Oh, you mean circular deps? Good idea. <xelxebar>I'm pretty sure it's not getting as far as Haskell. There is literally zero other output from guix, so I believe no build phases are running. <xelxebar>Oh! There you are. The test framework relies on ghc-unique (another new imported package) and the importer has ghc-unique in the native-inputs of itself. lol <xelxebar>efraim: Man, I'm impressed by your laser intuition on this one! <efraim>I've had some great obscure ones. That one I see occasionally on low RAM machines <xelxebar>It seems like an obvious place to look in retrospect, but in prospect, this clearly speaks to your experience <xelxebar>You throw guix on some low-powered machines? *vits-test whispers: MIPS <efraim>less than before. my main machine has 4GB of RAM, I used to play more with aarch64 boards with 2GB but I need to replace some. I spent about a month trying to revive the mips64el port. The machine I have only has 1GB of ram <efraim>1GB is definately too low to build Guix as of 0.15/0.16, but I saw that error a bunch on the mips machine <peanutbutterandc>Hey there, if anybody here has previously worked on gnucash package, please do take a look at: https://issues.guix.gnu.org/44309 and leave some comments/suggestions. I am very keen to see it merged upstream, but I understand that reviews are in order. <xelxebar>efraim: Very cool. Love seeing work on non-x86 archs. <vits-test>peanutbutterandc: so simple, no wrapper script; cool <peanutbutterandc>vits-test, Thank you (: I hope the output name is okay: 'gnucash:python'. I'm re-working on this small gnucash wrapper utility function and would love to have a mere "gnucash:python" as a package specification manifest entry in guix-env-manifest.scm <efraim>errors while building grub for mips64el: build-grub-mkfont: error while loading shared libraries: libfreetype.so.6: wrong ELF class: ELFCLASS32 <efraim>internets say 32-bit/64-bit mismatch <nckx>Good morning, happy band of Guix. <PotentialUser-68>hello, first time install of 64 bit latest version with gnome, i get an oops something went wrong error message probably from gdm or x-server, how can i fix this? <nckx>vits-test: Does GRUB have built-in support for that now? Last I tried it didn't, and there was only a very low-quality contributed Red Hat patch, and I ended up writing a Bootloader Spec parser in GRUBscript, and it was horrible, the end. https://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ hasn't been touched since 2018 and the last link is dead. <nckx>PotentialUser-68: ‘Oops something went wrong’? What went wrong? <PotentialUser-68>instead of user login dialog box gdm displays an error message "oops something went wrong please contact system administrator" <nckx>vits-test: Another problem is that it seems to specify only linux-specific keywords. I don't see a way to boot the Hurd. <leoprikler>PotentialUser-68: That message does indeed come from gnome-shell/gdm. <nckx>Is there a GDM log in /var/log? <nckx>Could you share it through paste.debian.net? <efraim>'guix build freetype --target=mips64el-linux-gnu' produces a 32-bit library <vits-test>efraim: what about `guix build --help`, -s flag? <efraim>vits-test: I'm trying to cross compile for mips64el-linux <vits-test>PotentialUser-87: some people did; IDK how. Basically we do not follow FHS, so programs cannot find their dependencies. <nckx>PotentialUser-68: ‘(EE) systemd-logind disappeared (stopped/restarted?)’, so look into the elogind service. Either through ‘sudo herd status elogind’ or by looking for (e)logind in /var/logs. That's all I can say. <abralek>Hm, cmake-build-system defines options and adds configure-flags to the bottom of the list. Is this the reason why adding "-DCMAKE_INSTALL_LIBDIR" to the configure-flags has no effect? <nckx>PotentialUser-87: Am I correct that GNAT itself is written in ADA? We'd need an ADA compiler written in C (or so) that's able to build GNAT in order to bootstrap it. <PotentialUser-87>unfortunately gnat is the only libre ada compiler that exists, i wonder how other distros bootstraped it <nckx>‘In order to build GNAT, the Ada compiler, you need a working GNAT compiler (GCC version 4.0 or later).’ Blurf. <Fenlair>At work we are installing most software as the admin user and not root. I was wondering, would it be possible to install guix that way, so all the packages in the store would be installed as the admin user or would that break guix? <nckx>PotentialUser-87: I suspect they just used an existing GNAT binary they ‘got elsewhere’. We can't really get away with that. <nckx>PotentialUser-87: We're piggybacking on the work of OriansJ & janneke & others to reduce our binary blob bootstrap soup, adding an ADA compiler to the mix is not happening. We can bootstrap Rust from C through mrustc. Is there nothing similar for ADA? <nckx>Fenlair: Unless ‘admin’ is UID 0 (and then... just why 😛), it's just a regular user. I'm afraid not. <leoprikler>Is there a historical version of gnat built just on GCC? <Fenlair>I suspected as much, all package managers I know install everything as root - was just wondering if guix would get around that, since it's quite special :) <nckx>Assuming admin has all kinds of capabilities (an area I know nothing about) that the daemon requires, it could work, but I'm sure you'd still need to patch a few assumptions. That's just speculation. <nckx>It might be possible to make it possible, I don't know enough about non-traditional (if (uid == 0) ...) access control to guess. <vits-test>efraim: gnu/packages/linux, 'system->linux-architecture. Seem it just see prefix "mips" and sets arch "mips". <nckx>PotentialUser-87: Interesting... <nckx>Judging by the one and only issue # it won't even compile out of the box on GCC 4.8, so it's a ‘project’ for sure. <nckx>‘available through anonymous ftp on cs.nyu.edu (128.122.140.24)’ <nckx>Remember kids, this new-fangled ‘DNS’ nonsense could fail at any time, always include your IP address too. <Kimapr_>"Basically we do not follow FHS, so programs cannot find their dependencies." I recently found GoboLinux, which doesn't follow FHS too but avoids compatibility problems by symlinking required directories from their actual place to root directory. We can do something like that but with system profiles. <nckx>Kimapr_: Yes, it works great. <Kimapr_>vits-test: yes, it is receiving updates, but some recipes like HexChat are broken *nckx apologises for eating our guest. <roptat>we can do the same with a container : ENV=guix environment --ad-hoc dependencies ...; PROFILE=$($ENV -- bash -c 'echo $GUIX_ENVIRONMENT'); $ENV --expose=$GUIX_ENVIRONMENT/bin:/bin (same with /lib, etc) <roptat>actually, the last one should be $ENV -C -N --expose... <roptat>I use this to run android-studio, until I'm able to build it <vits-test>wow, opportunities. Rust binary tarball. emmc-tools. <efraim>that ada interpreter has a bunch of commands I don't recognize, makech, cdecom, x2hdeps <nckx>efraim: Yes, the only results I could find for cdecom were other copies of adaed... <nckx>efraim: ‘It simply strips away blocks of commentary from a verbose version of a header file.’ No Visual Basic after all. <efraim>best I found so far is a language reference manual for ada83 <efraim>reference or source to an early implementation <civodul>janneke: it seems that "guix build bootstrap-tarballs --target=i586-pc-gnu" is broken on master, does that ring a bell? <sneek>Welcome back civodul, you have 1 message! <janneke>civodul: no bell yet, i'll have a look -- most probably i broke something <janneke>i've only been watching the substitutes and saw that some were canceled, others still no progress <civodul>janneke: glibc-cross-i586-pc-gnu-2.31.drv fails because the hurd*.patch are not among the inputs, AIUI <nckx>The answer was ‘nobody carez lol’, I patched it out and have a working adaed on Guix System \o/ <nckx>Now, to watch it fail to compile GNAT because it's not at all equivalent to GCC... <vits-test>ld: /gnu/store/zzgi5iqj7zasd4ckb3ymc6bzxa7cf2w0-profile/lib/crt1.o: in function `_start': <janneke>so, an inputs vs native-inputs thing? <janneke>i did move those patches out of cross-libc and into glibc, on core-updates <Achylles>I have installed guixOS in virtualbox. I am new to Guix and I want to access the guixbox through ssh, I know that I have to configure it inside /etc/config.scm but I am not sure how to achieve it and if installing guixOS on virtualbox was a good idea at all???!!! <civodul>janneke: yeah not sure, i guess it broke at some point due to some other change? <jonsger>Achylles: installing guix is always a good idea <jonsger>Achylles: I guess you need the ssh-daemon running by your Guix System <Achylles>jonsger, perhaps, the packages I need are not on guix... <roptat>Achylles, if you use the openssh service in the VM, then all you need to do is to set up the network so you can access the guest network from the host <janneke>civodul: oh, that's...unexpected; so hurd*.patch did work at some point <janneke>civodul: otoh, we fixed quite some cross-build problems after April 1st <Achylles>ok, but for me to take that sshd config example, and avoid to write everything by hand I need my ungoogled-chromium to access the internet inside my vm-guixbox, which is not doing that :( <Achylles>I can ping the internet, but the browser does not load any page :( <civodul>janneke: no, i'm afraid it's one of the CI issues we've been trying to address for weeks <janneke>civodul: okay -- i haven't been able to follow closely, sorry for that <vits-test>nckx: `ld -l name` searches somewhere for libname.*; the `ls /gnu/store/*/lib/lib${NAME}\.*|grep -v '\-profile'|head -n1` may work if those in store already. <Fenlair>ups :D das was supposed to go somewhere else :P <civodul>janneke: no problem, it's a lot of ground work and mothacehe significantly improved the situation on the Cuirass side, but we're not done yet <civodul>now disk space is dangerously low on the head node, i wonder why that is <vits-test>Achylles: browsers can break in many ways, curl is simple. <janneke>ah there was the image oflloading/not-offloading thingy <civodul>yes, that one was about making the head node usable or not :-) <civodul>but then there are scheduling issues in a broad sense <Achylles>vits-test, no answer with curl, but ping 8.8.8.8 works fine <Achylles>which is the other browser I can install in guix? <nckx>vits-test: I know what -l does, and that it translates to libg.so[.*]. But I'd never heard of libg.so, had you? <nckx>Now you've lost me. Anyway, it's apparently the g in glibc, so that's good to know 😛 And that it's not needed at all, which is even better. <nckx>‘There are two hard problems in computer sci--’ GNU: ‘hold my beer.’ <nckx>chaos: emalloc: ridiculous argument <vits-test>Achylles: btw, aren't there a "clipboard share" options in virtualbox? <vits-test>copy on host, paste in guest, then make a note to OFF the option later? <Achylles>vits-test, I have managed to ssh into guixbox <Achylles>but in terminal, there is no clear command? <vits-test>Achylles: some package provides it.. but also <vits-test>nckx, can U be so kind and say what was the sequense to clear the terminal? <nckx>No, it's part of ncurses. <nckx>vits-test: If you mean the raw escape sequence, no idea, but clear > file && cat file works 😉 <Achylles_>thx for the ncurses clear command. icecat (but, some fonts does not render well in the wikipedia page - like chinese and others) <Achylles_>I want a new version of emacs - but the repo is 26.x <Achylles_>cannot install xiphos, bibledit, diatheke, sword, bible-kjv :( <nckx>Achylles_: Is your Guix up to date? Emacs is at 27.1. <Achylles_>I already did guix pull twice and emacs version shows the same... <nckx>If that does not show 27.1, something is rotten. <nckx>And the output of ‘guix describe’ probably relevant. <Achylles_>it shows 27.1, but when I open emacs and M-x emacs-version it says 26.x <Achylles_>should I uninstall emacs and install it again? <nckx>Achylles_: ‘guix pull’ does not update packages, it updates available packages. You need to upgrade emacs with ‘guix upgrade emacs’. <nckx>‘guix install emacs’ is identical. <nckx>‘guix upgrade’ without a package name will upgrade all packages whose version has changed. <Achylles_>how do I install those packages I've quoted up there? <Achylles_>in debian I just apt install - but I know guix is not debian <nckx>If they were packaged, you could install them with, e.g., ‘guix install emacs-xiphos’. However, they are not. <nckx>You can install Emacs packages from ELPA the classic way. <nckx>I'd recommend writing a Guix package for them and contributing it upstream. I find that by far the easiest. *nckx away again, probably for the day. <Achylles_>gosh, I hardly know how to use guix properly, by now... <vits-test>also U can request them there, but it may be overlooked <vits-test>also U can request them there, but it may be overlooked <Achylles__>vits-test, I know, the list is very long... perhaps nonguix repo <vits-test>Achylles__: packaging isn't that hard; many things can be achieved with copy-paste <Achylles__>looking at that list, it seems that guix is not so ready for a desktop experience right now... <vits-test>Achylles__: heh? I writing that from aarch64 SBC <vits-test>existing packages are in gnu/packages of git tree. <vits-test>People there and on mailing lists are happy to help. <vits-test>Achylles__: ah: also people sometimes install Nix to get more packages (Guix descends from Nix, and both are compatible to each other). <Achylles__>by the way is there any guixOS live image to test it, say, from a usbstick before one install it? <vits-test>nixOS uses Nix language for its configs; guix was built from nix, but uses Guile language; also Guix is a GNU distro, so no proprietary stuff; nixOS may lack this feature. <Achylles__>but, what brought me to guixOS was the scheme language, since I have used stumpwm for a time now on a debian unstable box <vits-test>also `guix` installed on top of another distro can produce custom images <Achylles__>guix-system-install-1.1.0.x86_64-linux.iso -> this is the one I've installed in VB <Achylles__>but, I need some other packages not in guix right now... <Achylles__>I will keep playing guix on VB to get acquainted. Very interesting distro... <vits-test>NP; U can also install it as additional package manager to host. <Achylles__>But, it is really hard to ditch debian... They have nearly everything in their repos <Achylles__>yes, probably I will install guix into debian... <vits-test>If not Armbian, i wasn't able to install Guix on that SBC. <Achylles__>sorry for the ignorance, what is armbian and sbc? <xelxebar>Achylles__: What packages are you looking for? If you're already a lisper, you could probably blast through writing a few package definitions :) <xelxebar>BTW, The documentation for Guix and Guile both is quite fantastic. <Achylles__>bibletime, xiphos, bibledit, diatheke, sword, lamp <Achylles__>vits-test, do you think that these small devices can really be used as desktop replacements? <Achylles__>I know, some do. But they seem like only toys to play and to teach children how to program... <vits-test>If "desktop" is a "web browser + text editor" then absolutely <vits-test>It compiles Linux for 2hours (1hr is deblobbing), so not too weak also. <vits-test>btw, Achylles__ it will be good if U fill some req. to whishlist, with links to sites of programs U want. Someone can attempt to package them too, especially newbs (w/o mistaking xiphos for emacs-xiphos). <Achylles__>virtualbox guest additions do no work with xiphos... <vits-test>ah, important notice: compiles *mostly* linux-generic for 2hr. Not those fat ones that are default.. <civodul>roptat: hello! looks like the latest POT files didn't make it to the TP? *jsoo thinks ghc can have aarch64 support if there was a gold cross compiler <jsoo>cross-gold-binutils? Is it possible? *vits-test gold-binutils -> ETAXES <civodul>we could consider having Gold as part of the default Binutils package too <civodul>we'd need to check how bigger Binutils is <civodul>and then see if that triggers build failures elsewhere (like unrelated packages that pick up ld.gold and then fail to build for obscure reasons) <jsoo>guix size reports binutils-gold as 148.9 mib <jsoo>And binutils as 93.0 mib <civodul>oh i hadn't realized we already have binutils-gold <jsoo>ld.gold itself looks to be around 6M <jsoo>if it was a default output of binutils, it might reduce closure sizes for packages that use binutils-gold currently <jsoo>But slightly increased the size of binutils <roptat>civodul, I sent another email to the coordinator, to check what's going on <civodul>nckx: i hadn't seen it, but maybe it's just because my inbox is a mess <civodul>but yeah, i wrongfully focused on TSTP when everyone was yelling STOP! <nckx>You can stop voting now. <lfam>But I still have a dozen ballots left! <lfam>We are joking about the USA elections, jonsger <nckx>Did PotentialUser-87 (Adafan87) leave any forwarding information? To my own astonishment Guix now has a working Ada compiler, albeit one from 1990. <lfam>I'm wondering if you are using avidemux, nckx? Or just maintaining the package? <lfam>I have prepared an update patch that adds AV1 encoding <nckx>I use it for one-off conversions, like recently digitising someone's VHS tapes, but not frequently. <lfam>I've never actually used it but I am interested in "video editing" for Guix <lfam>Normally I use Blender but it would be nice to have something that is more basic and also focused on video <lfam>I noticed the other day that Youtube was streaming AV1 to me. The future has arrived <nckx>There goes my libav-accelerated i915, probably. <lfam>Yeah, I was surprised. But I guess the bandwidth is that much less <lfam>They already send vp9 a lot of the time. I'm sure they save a ton of money <nckx>Other people's hardware is cheap, especially when you're selling them your own. *nckx AFK, but if your question (if you had a question) was ‘is there interest in avidemux/AV1’, there is. o/ <lfam>No, I was just wondering I might break somebody's workflow <lfam>Since I don't use avidemux, I don't know if it will have changed significantly or not <lfam>I am really glad to see them using opus. AAC is totally dominant in broadcasting / streaming <jonsger>oh nice, some weeks ago I had only on certain resolutions AV1 on YT. Now it's all except 1440p and higher... <lfam>It's funny that they've skipped HEVC. Hopefully the future will be unpatented <efraim>nckx: re Ada you did better than me. I spent the last few hours imagining reimplenting Ada83 from scratch. <jonsger>lfam: does avidemux really use libaom? isn't that a bit slow <lfam>Yes, it's slow, but it gets faster with each release <lfam>Are there any fast encoders yet? I figure we are waiting for hardware acceleration <lfam>There is svt-av1, which is also slow, and rav1e, which is slow and in a weird language <jonsger>but I think they are faster then libaom <lfam>Also, svt-av1 only supports Intel chips, IIUC. And as the person that packaged rav1e, I don't blame anyone for not wanting to use it. The Rust ecosystem is still really tough to integrate <lfam>It will get better :) Every cheap chip has h264 acceleration these days <lfam>Most computers can't actually encode h264 in real time, even now <lfam>The various encoders also lack feature parity at this time .Things like real-time encoding, film grain, etc are not supported across the board yet <jonsger>yeah, I always look away when compiling firefox or thunderbrid when it builds all those bundle rust libraries <lfam>We have a patch series waiting to be polished and merged that will improve our Rust packaging a lot <lfam>I used it to package rav1e and it would have been impossible otherwise <lfam>At this point, we should probably just add it and clean things up later. We know it works *dustyweb forgets, is gabor in #guix often? what is their username? <jonsger>dustyweb: yes from time to time, but I forgot the user name <civodul>dustyweb: g_bor[m] is rarely around lately so perhaps you can send'em a patch for the setuid thing :-) <UnderSampled>I need to run an x86 AppImage; how do I get multilib for that? <roptat>oh gnu/installer/parted.scm:531 and gnu/installer/parted.scm:577 have None, which is hard to translate without context :/ (aucun, aucune, ...) <roptat>thanksfully, it's related to "name" and "type" which both translate to "aucun" in French, but other languages might have a different gender <civodul>ah yes, i managed to avoid freestanding words in other places in that file, but not this one :-/ <efraim>Gooberpatrol66: we don't have a service for smartd or for acpid <nckx>efraim: Well, you set higher goals, that's not fair ☺ I just dragged Ada/Ed into 2020. <nckx>It would be neat if it could be useful as bootstrap-anything but that would be a very happy coincidence, nothing more. <nckx>We'd ‘just’ have to bridge Ada83 to Ada95, I think... <efraim>my impression was that there's sources everywhere for later versions, just nothing to start from... until now <NinjaTrappeur>Hey folks! I'm trying to install guix using the console-graphical installer (via the image published on the website). The installer keep on crashing when applying the partitionning on the disk, regardless on the partitionning nature (several encrypted partitions, single unencrypted partition). Is it a known bug? Is there a way for me to get some error logs? <NinjaTrappeur>By crashing, I mean I see a black screen for a brief moment followed by the installer re-opening on the first screen all over again. <NinjaTrappeur>(in the meantime I'll go the manual way, I'll probably see the parted/mkfs error) <civodul>hi NinjaTrappeur! there were installer bugs in 1.1.0 that have been fixed in the meantime and will soon be in 1.2.0 <cbaines>I've revised and pushed the Guix Data Service blog post! Hopefully it makes sense, and I hope I haven't broken the website... <civodul>cbaines: did you check with "haunt build" or "guix build -f .guix.scm"? <cbaines>civodul, haunt build worked locally following the instructions in the README, and the page seemed to render OK <mbakke>UnderSampled: I don't know if AppImage is supported on Guix, but to produce a 32-bit environment in general, you can use --system=i686-linux with most Guix commands. <cbaines>(I'm still confused by the header styling though...) <UnderSampled>I think it's actually an x64 AppImage, but it doesn't play well with GUIX <mbakke>UnderSampled: that looks correct to me <mbakke>UnderSampled: oh, sorry, that (extra-special-file ...) service should be at the same level as (xfce-desktop-service) <g_bor[m]>I believe we might already have the needed setuid bits in place, or at least most of them <mbakke>derp, I can not read nor type today; to be explicit: (list (service xfce-desktop-service-type) (extra-special-file ...)) <nckx>efraim: <Sources everywhere> Ooh, where?? In theory GNAT predates Ada 95, but I can't find any ancient source releases. The oldest I can find is the ‘famous’ 3.15p, the last stand-alone version without GCC, and that's already written in Ada 95. <efraim>I thought I found something in sourceforge but I didn't look at it too closely <sneek>Someone once said ed is the standard text editor! Ed! Ed! Ed! <efraim>no, the sourceforge one I found was 3.15p <nckx>efraim: I was thinking something closer to 2.x or even 1.x but who knows! 3.04 looks more different from 3.XXp than I expected. <nckx>raghavgururajan: Just... why? <nckx>efraim: How do you find these things by the way? <nckx>raghavgururajan: Why research ed? <efraim>I found the debian sources not the fastest to browse but the most convenient when I wanted to see source but not hunt it down <efraim>then I found out about the snapshots of the repos and thought it was a waste until I needed random old snapshots for projects (like the mips64el port) and realized it was really helpful <nckx>efraim: I'm super unfamiliar with most of Debian so thank you for this. <efraim>don't tell vagrant but I have a guix package for dpkg, just waiting for an excuse to bust it out :) <nckx>Even putting "gnat_3.04-2.tar.gz" into a search engine returns nothing. <nckx>efraim: Revenge for porting Guix to Debian, seems fair. <efraim>one of these days I'll finish getting pbuilder to work on guix and then we can build debian packages <raghavgururajan>> efraim: don't tell vagrant but I have a guix package for dpkg, just waiting for an excuse to bust it out *raghavgururajan was kidding <jeko>Hey Guixters ! Hope you are doing well and safe ! <raghavgururajan>> nckx: Even putting "gnat_3.04-2.tar.gz" into a search engine returns nothing. <jeko>I am trying to "guix deploy" haha (between us: so exiting tool, if I succeed, the next world wide ddos attack is mine. shhhhhh) hahaha <nckx>raghavgururajan: Not when I quote it, and when I don't I don't see anything relevant. <nckx>(And all results but one are from DDG, which I already use.) <nckx>Yep, one (if you quote) it, thanks! I found that somehow but don't remember how. Good to have a back-up URL. However, what I'm really looking for is *older* versions of GNAT, the older the better. *nckx tries to build GCC 2.7.2 in the meantime, doobydoo. <nckx>Puny 6.8-MiB source tarball lol. <cbaines>it looks like the images work, which is a good start! <efraim>if I said 'guix lint -c source' was fun, I'd be lying <nckx>‘guix environment gcc’ is broken. <civodul>cbaines: maybe "what is it" -> "what it is" in the intro? <nckx>Oh, it's because of the ‘toolchain’ thing. Of course. <cbaines>civodul, I've pushed that change now, that does make more sense <nckx>civodul: I'm actually mad enough to want to build (read: fuck around by hand with) a frankenpatched GCC. <jonsger>ah, I always oversee this and concentrate on texlive-* <cbaines>I too need to get some sleep now though, need to work up to fixing the stuck hooks issue in the Guix Build Coordinator and sending an email out about patch review things <nckx>cbaines: Nice post! Thanks. <nckx>civodul: Building GCC 2.7.2 --with-languages=ada. I don't expect it to work. <nckx>./libgcc1.c:256: Error: incorrect register `%rsi' used with `l' suffix <nckx>♪ I don't know what any of that means ♪ <civodul>nckx: ooh, you're on a bootstrapping trip? <civodul>perhaps you need an older GNU as (Binutils) <nckx>raghavgururajan: They got bored of serving weak humans: sneek has quit (Remote host closed the connection) <nckx>civodul: On it! binutils 2.6 is happening, oh dear. <nckx>This is more fun than I bargained for. <raghavgururajan>nckx: LoL. I was interacting with it on a private chat a while ago and suddenly went offline. Looks like sneek hates me. <nckx>(Not really; very expected, much 1997) <nckx>The first GCC I ever used was 2.9 so this is ancient for me. <nckx>raghavgururajan: What did you say!?