<lfam>Yes, these old versions of software may be vulnerable to bugs fixed in later versions of the software <lfam>The user decides if they want to use the time machine <cj>I understand, so I have to be more careful when using GuixSD than with Debian and see if the dependencies are up to date. Thank you all! <lfam>Just do not use the time-machine, if you are worried <cj>I understood! Thanks! <nij>Hello! I have a manifest in the repl. How do I install it in a specific profile (in that repl)? <nij>Or I should always save that to a file, and invoke `$ guix install -f ...` from the cli? <nckx>nij: Untested, but you can try importing (gnu scripts package) and using build-and-use-profile. Or some other procedure if that's not the right one. But, honestly, I know I'd go for a quick & lazy (system ...) instead. *nckx -> đ´ Good night, Guix. <jgart[m]>Does anybody happen to know a particular example where a dependency is needed as both a propagated-input and a native-input? What would you do in that case? Duplicate it? <jgart[m]>The case where I need this is python-abjad. It requires lilypond for the tests to pass but it also needs lilypond as a propagated input since the abjad api directly calls the lilypond binary from a method in order to compile a pdf <nipcat>This does not work, though. I removed the gdm-service-type but it still starts up. I then tried to specify my own %desktop-services, but when I try to use the avahi-service-type in my own config it says "guix system: error: service 'avahi-daemon' requires 'networking', which is not provided by any service" <nij>Good night #guix. You made my day again :) <lfam>jgart[m]: I would just do 'propagated-inputs'. I think that Guix will do the right thing, in terms of native dependencies when cross-building *lfam looks at nipcat's notes <lfam>nipcat: Regarding the "requires networking" thing, I would add (service dhcp-client-service-type), which will provide networking for you. Plus, you probably want to use a DHCP client to get IP addresses assigned automatically <lfam>You might also want (service ntp-service-type), to set the clock automatically <lfam>jgart[m]: Sure, whatever seems best to you. I don't have experience with lilypond so I can't give very specific advice <nipcat>lfam: error about something missing ... I basically simply copy pasted all the services defined in desctop.scm as %desktop-services ... I don't understand why that shouldnt work <lfam>Hm, that's not what your paste showed. Was that in another revision of your config.scm? <nipcat>(service ntp-service-type) does not work either <lfam>What do you mean it doesn't work? Can you be more specific? <iyzsong-w>re 'xinit', there is a 'xorg-server-service-type', which should work out-of-box with 'sx' <nipcat>if I add (service ntp-service-type) I get "guix system: error: service 'ntpd' requires 'networking', which is not provided by any service" <jgart[m]>lfam: The issue is that I would have to duplicate lilypond in the propagated inputs as well as the native inputs since lilypond is also required for tests to pass <nipcat>lfam: of course i changed that trying to minimize my config to hunt for that bug <jgart[m]>lfam: Should I just put lilypond in both, native-inputs and propagated-inputs? <nipcat>lfam: but trust me, I did try that first .. simply defined my own %desktop-services exactly like in desktop.scm <lfam>jgart[m]: What I'm saying is that you don't have to do that. Just use propagated-inputs, and the right thing will happen with respect to native compilation when cross-compiling (which is what native-inputs is about) <lfam>jgart[m]: Propagated inputs are available in the build environment <nipcat>ok adding dhcp-client-service fixed that networking dependancy .. although I still don't understand how .. because it's not defined by the original %desktop-services either <lfam>nipcat: If you simply copied and pasted %desktop-services from it is defined, without any other code, I would not expect it to work. You would also need to import the variety of modules, and perhaps procedures defined in that file <lfam>Those modules are imported at the top of the file, with #:use-module <nipcat>lfam: of course, I imported the modules accordingly <nipcat>lfam: otherwise scheme would had complained about unbound variables, not about servicse that are not provided :) <lfam>Okay, I wasn't sure how it failed <nipcat>lfam: thanks, though! this helped alot :) <lfam>I suppose that %desktop-services handle DHCP via network-manager-service-type <lfam>By the way, if you install xdot (from the xdot package), you can do this: `guix system shepherd-graph config.scm | xdot -` <lfam>It shows the services of your config.scm in a graph <nipcat>yeah i just thought about that .. it makes sense now! <lfam>Well, let us know if you have more questions. I wish I could answer your original question (how to use xinit) <lfam>I really like the startx / xinit workflow: boot to console, start X by hand if wanted <nipcat>just one more mystery for me would be why the remove gdm-service-type call wont work <lfam>That's unexpected to me, but the graph tool might help unravel the mystery <lfam>You could even use it before reconfiguring, just to be sure it's how you want it <nipcat>yeah i used to do startx with arch .. i dont really mind gdm, but I kinda wanna define all my emacs packages in a manifest file for my user profile .. which is not possible when i use exwm via display manager <nipcat>it seems to expect all the emacs packages in the system profile <lfam>Hm, there must be a way to make it work :) Hopefully something with experience with exwm can chime in <jgart[m]>lfam: Thank you! I rebuilt successfully with your suggestion. I'll send a patch soon with the package update. ***iyzsong-- is now known as iyzsong-w
***sneek_ is now known as sneek
<lfam>Client: HexChat 2.14.2 ⢠OS: Debian 10.9 ⢠CPU: Intel(R) Core(TM) i5-6300U CPU @ 2.40GHz (2.50GHz) ⢠Memory: Physical: 14.7 GiB Total (11.5 GiB Free) Swap: 15.3 GiB Total (14.8 GiB Free) ⢠Storage: 932.2 GB / 1.0 TB (83.8 GB Free) ⢠VGA: Intel Corporation HD Graphics 520 @ Intel Corporation Skylake Host Bridge/DRAM Registers ⢠Uptime: 1d 7h 26m 10s <Oxddc>I am torn with using Guix any longer. I dislike how it has become political. I dislike how they dont want to be apart of the FSF GNU and just using the GNU name and brand as "Gathering under a New Umbrella." I dislike how they say its for inclusivity where FSF GNU shows no signs that they are not inclusive. Why am I typing this here? Because its the GNU head devs how are always at the tops of these lists. What are their motives? It <Oxddc>seems pretty irrational and ridiculous. I wish I could use Gathering under a New Umbrella Guix without having to worry about what the head devs politcal motives are, but it is very hard not to. Especially when contributing to packages and other ways. It is all very sad. I like the Guix ecosystem, but these actions do not sit well with me to want to support the project furthur. It seems like its all half truths. <Frosku>Wait, guix doesn't want to be part of the FSF? <rekado>Frosku: confusion: Guix has never been âpart of the FSFâ <Frosku>Part of the GNU project as associated with the FSF <rekado>Oxddc: the GNU project has always been political. <rekado>Frosku: Guix is part of GNU and that hasnât changed. <rekado>whatâs changed is that some GNU maintainers and contributors have more formally gathered <Frosku>Does this involve throwing RMS under the bus? <rekado>you will find that rms is not mentioned at all. <rekado>not *everything* needs to be about rms <rekado>thatâs also kinda the point here <Frosku>Everything seems to be changing exactly at the time RMS is a headline <Frosku>I agree not everything needs to be about RMS <rekado>rms is a good catalyst, thatâs for sure <Frosku>But he also shouldn't be thrown under the bus <rekado>I donât throw people; itâs bad for my back ;) <Frosku>So this GNU is the same as gnu.org or some weird fork? <rekado>but more seriously: I think rms has a voice that *should* be heard, that is valuable in the wider free software community <Frosku>It seems quite deliberately vague <rekado>I donât think, however, that the close association between rms and GNU (and even the FSF) does anyone any good. <rekado>GNU is what those contributing to it make of it. <rekado>itâs about time those who make GNU also collaboratively make decisions <Frosku>Copy pasted Contributor Covenant <rekado>I donât think this discussion is on topic for #guix, though <rekado>there are more projects involved in gnu.tools <Frosku>Yeah, I don't see an issue with the general idea of GNU developers collectively making decisions, I would just like to see the site actually tell me what's going on. <Frosku>(and ideally not use the Contributor Covenant, but that's a much longer discussion) <rekado>Frosku: frankly, there isnât *much* going on. We are collaboratively working on a governance model (see the documents there). At this point it isnât much more than whatâs on the website. <rekado>it gives a name to this otherwise diffused dissatisfaction with where (or where not) GNU is headed <rekado>and naming things, as we Schemers all know, gives those who wield the name power of the thing thatâs been named ;) <Frosku>Yes, which is concerning. If this is i.e. a 'union' for gnu developers, that's a good thing in my view, if this is splitting gnu between 'Stallman GNU' and 'Not Stallman GNU' it seems like a horrible idea. <rekado>but I really suggest taking the discussion off #guix; I donât like to dominate a channel with a discussion that is really at best a tangent for Guix <Frosku>Sure, is there a channel for it? <Frosku>What you wrote sounds quite promising, I'd suggest reconsidering Contributor Covenant in favor of a less vague CoC though. <rekado>I heard that before, but the truth of the matter is: itâs a decision the assembly will have to make if the assembly members have a problem with the CoC as is. Thatâs perhaps a little circular, but ⌠you know, such is bootstrapping ÂŻ\_(ă)_/ÂŻ *rekado goes to make breakfast <mdevos>sneek: later tell nckx: is nckx available for discussing translations? <mdevos>sneek: later tell nckx: never mind <efraim>rekado: I just used etc/committer.scm for the first time, wow is it nice to use <rekado>with *lots* of changes (like after using âguix refresh -t cran -uâ) itâs rather slow due to the way it mates up old and new sexprs for each hunk <rekado>but Iâm sure this can be improved <mdevos>does anyone have insight on how to translate 'derivation'? <rekado>itâs an odd word in English as well. *rekado looks up the German translation <mdevos>I could translate it as 'afleiding' or 'afgeleide' (as in d/dx, taking a derivative) <rekado>yeah, the German word is âAbleitungâ, which is the calculus thing <mdevos>the exact translation doesn't really matter I think, as long as it is consistent <rekado>personally, I think the German translation would benefit from using âDerivatâ (which is not primarily a finance term) <rekado>yeah, it just needs to be consistent. Itâs a new meaning for whichever word you choose. <mdevos>leoprikler: in which language would âDerivationâ be better? <leoprikler>It may be three more letters, but the connotation is different. <rekado>âDerivatâ is that which has been derived. <rekado>and I think that fits pretty well, no? <leoprikler>Ehh, not really, since most people associate the complicated finance thingy with it. <mdevos>it is derived from all the source code and the package recipe <mdevos>derivative doesn't really fit well, since most people associate the complicated calculus thingy with it? <rekado>leoprikler: really? I must be very special to not even have thought of finance. <leoprikler>Well, it probably depends on who you ask, but according to German Wikipedia, it's used for that, some turbine, and some chemistry/medical stuff. <leoprikler>Whereas "Derivation" has a mathematical/linguistic connotation, which personally feels closer. <mdevos>that's true (functional package management / mathematical theory of functions ...) <leoprikler>That being said with Ableitung as an already German expression, that is not a Lehnwort, I think we're much closer to the average German-speaking person. <leoprikler>Particularly, because derivatives in the sense of (d/dx) are called Ableitung in German. <canant>Hi cbaines are you there? I have a quick question. <meo>hey, anyone knows who's the admin for git.gnu.io? <meo>it fell off, connection refused <sneek>Welcome back nckx, you have 2 messages! <sneek>nckx, mdevos says: is nckx available for discussing translations? <sneek>nckx, mdevos says: never mind <manumanumanu>Hello! I just installed guix using the script, but now I try to run guix as my user, I get access denied to my profile.lock: guix install: error: open-file: Access denied: "/var/guix/profiles/per-user/manumanumanu/guix-profile.lock" <raghavgururajan>nckx: Hey o/ I was wondering if you could setup .authorization on c-u as well? *nckx never minds, that's my secret. <nckx>I think there are non-trivial merge conflicts on masterâc-u. <nckx>Would it break anything if I cherry-picked the single authorisation commit instead? Anyone? <mdevos>nckx: at worst, it would cause a trivial merge conflict I think, but I don't have much experience with cherry-picking and merge conflicts <manumanumanu>forget my error. I managed to make the manumanumanu dir belong to root <nckx>I'm not worried about the git side of things. I wonder whether it would confuse the authentication mechanism, or perhaps do so after the next merge. I don't see how, but it's safer to ask đ <nckx>manumanumanu: By using sudo guix, perchance? <mdevos>perhaps "guix PROFILE-STUFF" could check whether the username and uid match before writing a profile to /var/guix/profiles/per-user/USER/*? <nckx>manumanumanu: I keep thinking there's a patch somewhere to make Guix check who owns the directory and not silently change it, but maybe I've just imagined it because it's so damn common. <nckx>mdevos: Yes, that's what I mean, I think. <efraim>I can take a look at master -> c-u. I did the last one <cbaines>canant, I was out earlier, but I'm back around now <mdevos>reminder: don't use ~p in format strings that must be translated <nckx>mdevos: Just so I know: are you making a note of these? <mdevos>nckx: do you use âcurly quotesâ? <nckx>I honestly don't know. I use â...â â...â. Is that curly? <mdevos>yes. `' isn't, and '' isn't either <nckx>Ew. Even calling those âquotesâ will get you kicked out of some places. <nckx>I think there are debatable reasons to stick to ASCII in English source strings, but not translations. <nckx>I just hope they're not a pain to type for you? <mdevos>here's a fun one: '~a' should probably be a native input. --> inboorlingsinvoer, autochtooninvoer, ??? <nckx>I read that as inboorlingenvoer. <mdevos>then I can type â with alt gr + f, and â with alt gr + g <canant>Thanks, cbaines. I asked on the mailing list, and you've answered it already. <mdevos>'inputs' --> 'voer' klopt eigenlijk wel. Je âvoedâ het compilatieprocess mt pakketten, derivaties, broncode, ... <mdevos>gaan we er native-inputs->inboorlingenvoer, propagated-inputs->herkauwde invoer en inputs->voer van maken? (-: <nckx>I propagated my inputs once, and afterwards I felt a lot better. <mdevos>of inheems voer, dat is wat korter dan inboorlingenvoer <nckx>I feel like we need to find a metaphor for cross-compilation (âkruiscompilatieâ zegt het Web) that fits better. All I can find are articles talking about het hostsysteem and de targetcompiler :-/ <mdevos>'herkauwd voer' klinkt als iets dat je niet wil. Dat is de juiste connotatie voor propagated-inputs denk ik <nckx>This supports my biases A+++ *mdevos adds "propagated-inputs" -> "rechewed inputs" to the glossary <mdevos>patch --> pleister, plakker, oplapbestand, lapje? <rekado>wow, âpleisterâ sounds so nice <efraim>ok, merged master -> core-updates, running make now <mdevos>ik ga patch->pleister toevoegen aan glossary. rekado approves *efraim goes afk fro a bit <nckx>Pleister... did not occur to me, or (more likely) sounds better now than at 3am. Sounds good. <nckx>I'm not happy at all with my current translation for âpatchâ (âpatchâ), please adjust on sight. <nckx>(Unironic approval, just to be clear â) <efraim>nckx, raghavgururajan: master merged into core-updates <nckx>mdevos: Please delete that from the Internet. (By the way, I capitalised Internet and think you did to, but it's apparently not.) <mdevos>bedoel je upgraden is een anglicisme? <nckx>I use âbijwerkenâ (saving âvernieuwenâ for ârefreshâ) but my point is just that that table is cursed. <mdevos>ok ga âbijwerkenâ in het vervolg gebruiken <nckx>Against god and nature, yes. <roptat>I see the Dutch translation is progressing :D <nckx>mdevos: locale âmodifiersâ are sometimes expanded to âvariant modifiersâ, so I'm going with âvariantâ there. Unless you have a better synonym or suggestion. <nckx>roptat: Prepare for a huge influx of new users! <nckx>âDisallowed translation: can â can.â <mdevos>Off-topic: Is there an IRC channel for R? I'm stuck somewhere, and if I can become unstuck, then I have more time for translations <nckx>roptat: Would adding a comment for translators now fall under string freeze? <mdevos>nckx: patch headers (/ e-mail headers) --> pleisterkoppen, e-mailkoppen? <mdevos>ik heb er een paar keer thuispagina van gemaakt ... klinkt gezelliger, maar hoofdpagina is meer standaard <nckx>I don't browse the Dutch Web apart from news papers, I don't actually know what's common there. <mdevos>except $SCHOOL, nl.wikipedia.org when looking for synonyms, nl.wiktionary.org, ... <mdevos>I actually even always set LC_ALL=en_GB.utf-8 <mdevos>ik denk dat ik er eens het depot van heb gemaakt <nckx>I'm going with â~a~{ ~a~}â beĂŤindigd met status ~a, met uitvoer:~%~%~{ ~a~%~} for âoutput follows:â if that's OK with you. <roptat>as long as it doesn't change the string itself <mdevos>hash -> hachee, of controlecijfer? Tweede is eigenlijk niet correct <nckx>mdevos: I've punted on âstoreâ so far (there's an untranslated âstoreâ somewhere that needs to be fixed). I think I've used âmagazijnâ once. I considered depot but thought it was too Belgian (you'd know). <mdevos> In onderzoek van het Centrum voor Leesonderzoek uit 2013 werd "depot" herkend door: <nckx>mdevos: I did use controlegetal. <nckx>I think the distinction is so subtle as to be irrelevant. <mdevos>dat is goed. Dat impliceert niet dat we een som nemen (controlesom) of het een enkel extra cijfer is (controlecijfer) <nckx>I think accurately communicating what's actually going on matters more than the academically-correct âhashâ that just scans as an opaque loanword. <nckx>âDistillatieâ for âderivationâ appeals to me for that reason. <mdevos>dat klinkt goed ... maar dan moeten we oude tekenreeksen aanpassen <mdevos>je kunt het aanpassen in de glossary voor in het vervolg <mdevos>Hmmm â Map a device node using Linux's device mapper.â <mdevos>In Hurd-speak: âVertaal een <device-node> met ...â <nckx>OK, I will change all previous uses if you agree it's an improvement. I like having help but it's an adjustment :) <nckx>Heh, I recall hitting Punt on that string. <mdevos>Volgens Frans: âprojecteer <un pĂŠripherique> met ...â <mdevos>projecteren klinkt passend, maar toch ook weer niet duidelijk ... <nckx>Inderdaad wiskundig accuraat doch eerder obscuur. <PotentialUser-65>Hi all. An executable is missing libstdc++.so.6 and having installed gcc-toolchain@10.2.0 I don't see it either under .guix-profile/lib but `locate` does show it somwhere in /gnu/store ... what am I missing? <pkill9> PotentialUser-65 is this an executable you downloaded? <pkill9>because if so guix doens'tby defualt support running those executables <mdevos>t'zal obscuur worden in de vertaling <PotentialUser-65>this is an executable I've built, but I would imagine it simply used binary python wheels <mdevos>het was al obscuur in het Engels <jlicht>hello guix! (the Dutch made me do a double take) <PotentialUser-65>oh ... I can't say i understand what this even means? You mean those executables would usually have hardcoded paths or smth? <nckx>I like both with a mild preference for âvertalenâ but it's more likely to collide if we ever use âmapâ & âtranslateâ in the same sentence. I'll follow whatever you think best. <PotentialUser-65>is there a way I could run such executables, atm I can't build it from source - there is no such package under guix, so I had to go the pip install way <pkill9>PotentialUser-65: portable binaries generally expect the glibc interpreter in /lib and /lib64 <mdevos>Het is iets obscuurs, dus heb ik tussen aanhalingstekens âdevice mapperâ geschreven, zodanig dat de gebruiker de details kan opzoeken <pkill9>but guix doesn't use those paths <nckx>Guix has been taken over. <nckx>mdevos: Great! I did the same with user namespaces. <pkill9>but, if it's saying there's a missing library, then that sounds like it is executing, maybe it's a wrapper script that checks for the libraries <pkill9>PotentialUser-65: post the full error and command you're executing *jlicht wonders whether Eelco has some 'blessed' translations for us <PotentialUser-65>pkill9: that paste bin link on this IRC website that guix hosts haven't worked for me even once <PotentialUser-65>this is python binary inside virtualenv, built with usual python tools, no essentially `pip install` <jlicht>I might be misunderstanding your problem, PotentialUser-65, but I do know that 'virtualenv' on guix' master branch or not really isolated <PotentialUser-65>bottom line, python binary calls to its dependency blspy I think and that can't find shared lib <pkill9>find libstdc++.so.whatever, and then set LD_LIBRARY_PATH to the directory it's in <pkill9>then the executable will find it <pkill9>that's the standard workaround for libraries that aren't found <PotentialUser-65>ok will try that. But why isn't that env var set to begin with? After all I have gcc-toolchain installed <nckx><that paste bin link on this IRC website that guix hosts>What paste bin is that, PotentialUser-65? <pkill9>not something to rely on, because otherwise it might look for libraries in conflicting versions of packages <pkill9>they get compiled with references to those paths <pkill9>LD_LIBRARY_PATH adds to the paths it searches <nckx>jlicht: Do you know where Nix translations live? Not in the main repo IIRC. It's a great idea to look to them for inspiration. <pkill9>well those paths are more like a side effect <pkill9>the hash is formed from the explicitly given inputs in the package definition <jlicht>nckx: I started looking as well, but no luck yet <PotentialUser-65>that is ... if something has that that libc++ in its input then it'll know what to find it <pkill9>not by looking in the compiled source <PotentialUser-65>but in this case I used `pip` and I bet its C++ dep was looking in standard Linux paths <nckx>jlicht: Oh, I haven't looked. Don't assume it's not in some obvious place. :) <nckx>PotentialUser-65: We don't host that, is the problem. We just link to it. <mdevos>French: binaire d'initialisation. IntitiĂŤle binaire bestanden? <nckx>âDrop files here, paste, or import fromâ that thing? *nckx â AFK, houdoe goed. <roptat>depends on the context for bootstrap <roptat>sometimes I just use "bootstrap" directly <jlicht>mdevos: are those the binary seeds? <jlicht>binaire kiembestanden? Misschien wat vreemd, maar dekt de lading <mdevos>Als je een binair kiembestand plant, bekom je dan een binaire plant (-:? <jlicht>oh! Een binaire starter, zoals bij yoghurt/zuurdesem <mdevos>misschien gewoon van kiembestanden spreken? De binariteit is slechts een âimplementation detailâ <mdevos>'t zou evengoed ternaire kiembestanden geweest kunnen zijn <mdevos>raw build system -> ongeraffineerd bouwsysteem? <jlicht>afhankelijk van de context zou onverfijnd kunnen passen, maar in deze context niet. <mdevos>wie is nu bezig met Nederlandse translatie? Ik, nckx, jij ook? <jlicht>nee, ik heb uberhaupt nog nooit NL gesproken met iemand van #guix. (Ik wist niet eens dat er vertalingen waren) <jlicht>mdevos: that's a lot of strings :-) <mdevos>btw, the R trouble is no resolved <mdevos>removed the lm in MASS::boxcox(lm(y~1)) <mdevos>offload --> ??? According to {fr,nl}.wiktionary en->fr->nl: offload-->fourguer-->helen. Errr <nckx>mdevos: I've gone for uitbesteden. <mdevos>dat soort-van impliceert dat er geld mee bemoeit is (-besteden) <mdevos>->uitbesteden in de glossary gezet <nckx>Conversely, âdelegerenâ is something I'd do to the agent, not the job. <mdevos>debugging output --> insecticideuitvoer, foutopsporingsinformatie? <nckx>This is all extremely subtle :) <nckx>I've heard foutopsporingsinformatie before. <mdevos>ik heb debug->debug op de zwarte lijst gezet <mdevos>oh en soms gebruik in compilatie, en soms gebruik ik bouwen. Soms lijkt het ene te passen en soms het andre <mdevos>waarom niet manifest->pakketlijst <pkill9>has anyone successfully built something using --target=armhf-linux? <mdevos>ik zie nu dat paklijs een wat gangbaar woord is <pkill9>I'm hoping to build hedgewars for android using guix <nckx>âpakketlijstâ = âpackage listâ, âpaklijstâ = âmanifestâ, that's all. <nckx>I think a similar example would be the oft-confused beschrijving vs. omschrijving. <nckx>But I'm not a highly-paid linguist. <pkill9>currently i get this error in the configure phase when building binutils: checking target system type... Invalid configuration `armhf-linux': machine `armhf-unknown' not recognized <pkill9>configure: error: /gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash ./config.sub armhf-linux failed <nckx>Someone once told me âbootstrappingâ came from a Dutch folk tale (and thought perhaps we could call it âHenkingâ) but it seems I was misled. <nckx>German at best, and even that is dubious. <mdevos>â Report failure to compile a package to a derivationâ --> âMeld het mislukken van het opstellen van een distillatie voor een pakketâ --- ik heb de zin wat omgegooid <pkill9>what's the difference between --target and --system? <nckx>pkill9: --target uses a cross-compiler, --system a ânativeâ compiler running emulatedly. <mdevos>generation->generatie, dat behouden we zo dacht ik? <pkill9>what's the difference between them? <nckx>So on x86, --target=aarch64-linux-gnu will use an x86 GCC binary that creates an aarch64 output. --system=aarch64-linux will run an aarch64 GCC binary, using transparent qemu-binfmt emulation, that creates an aarch64 output. <mdevos>the latter is sort-of a lightweight VM <nckx>mdevos: Agreed on generatie. <roptat>mdevos, the French translation uses "dĂŠcharger" for offload <jlicht>nckx: oeps, je hebt gelijk! Maar ik dacht dat we meer een stille minderheid waren, alsnog :) <roptat>pkill9, --target requires a triplet (like arm-unknown-linux-gnueabihf) whereas --system requires a nix system name (like armhf-linux) <jlicht>Is alles met dat rode icoon rechts een 'verboden' vertaling? <roptat>I wasn't aware we had so many Dutch speakers, that's nice :) <nckx>jlicht: In the glossary? Yes. <roptat>nckx, did you update the comment you wanted to add? <nckx>I'm a bit busy, but is it better to do so first? <nckx>jlicht, mdevos: âzelfstartenâ OK for bootstrapping? <nckx>âUit het niets verrijzenâ is quite long. <mdevos>daarbij denk ik aan self-extracting executables <jlicht>zou 'kwetsbaarheid' ipv 'zwakte' beter passen voor 'vulnerability'? Kan ik dit gewoon zelf aandragen via de web interface? <roptat>nckx, that's fine, ping me when it's done, and I'll update the file on weblate <mdevos>pas het eerst gewoon aan in de glossary <nckx>jlicht: I think kwetsbaarheid is the common term here, yes. <mdevos>als je dat aanpast, pas dan ook de glossary aan <mdevos>(bootstrap, bootstrapping en bootstrap binaries) <mdevos>hoe noem je dan de bootstrap binaries <nij>Hello! I'm setting up a foreign input method (chinese, japanese, korean) on my guix system. Currently, it works well for my terminal and qutebrowser, but it while I type through them in emacs and icecat, it appears that they are not existing at all.. namely what show up are plain english characters. This could be a tough problem to resolve, but I hope I can get some hint here. <roptat>nij, have you set GUIX_GTK{2,3}_IM_MODULE_FILE? <nij>These are from my arch machine's setting. <nij>As an equivalent, should I also set GUIX_QT{1,2,3,4}_IM_MODULE_FILE? <roptat>I have GUIX_GTK2_IM_MODULE_FILE=$HOME/.guix-profile/lib/gtk-2.0/2.10.0/immoudules-gtk2.cache <nij>Hmm.. I set them in a terminal, and launched emacs in that terminal.. but it still doesn't lemme type in CJK. <raghavgururajan>nckx: Let's say my local copy of c-u is 9 commits ahead of remote c-u. If I `git rebase HEAD~9 -i` and edit on 5th commit, and then if I push; only the first 5 commits will be pushed right? <nij>(Same.. it doesn't work for icecat.) <roptat>nij, I think you need that in the whole environment, not just a terminal <roptat>but, even though I have those variables, it doesn't work for me either (well, ibus is detected, I can see it change the behavior of typing dead keys like ^, but it doesn't find anthy, which might be due to stray cache refering to non existing store paths) <nij>roptat: no worries! i will do it for the whole environment and try again <roptat>you probably need that in .profile, or in my case, I have it in .config/openbox/environment <nckx>raghavgururajan: <If I `git rebase HEAD~9 -i` and edit on 5th commit> So your editor is open and is showing 9 âpickâ lines. What exactly do you do at this point? <nij>I got that in my whole env.. still doesn't work. <nij>Anyway, thanks so much for your help roptat :) <mdevos>is er een NL vertaling voor commit <nckx>raghavgururajan: I have to leave again but in general I'd say: in such a case, be completely explicit in what you push (git push origin HEAD:core-updates, git push origin HEAD~5:core-updates, or ever git push origin <commit>:core-updates), don't rely on what you think should happened if you kept track of all state perfectly. Git is stupid; don't be too clever. <nckx>mdevos: If you find one let me know, I've used âcommitâ so far. Mainly because it's extremely common in all Dutch git tutorials/docs. <nij>OHHH, roptat, it actually works for icecat!! That suggests it's a right way to go :D <nojr>hello :) has anyone ran cider and gotten this error message? <nojr>Caused by: java.lang.ClassNotFoundException: jdk.javadoc.doclet.Doclet <nojr>I installed openjdk v 14 <nojr>the one in the official guix channel <nckx>mdevos, jlicht: Suggestions for âinstall the package that the code within FILE evaluates toâ (holy split infinitives, Batgirl)? âwaartoe ⌠evalueertâ is hella meh, and âbeschreven doorâ feels like cutting one corner too many. <mdevos>ik heb er â -f, --install-from-file=BESTAND <mdevos> installeer het pakket waar de uitdrukking in BESTAND <raghavgururajan>nckx: Among those 9 pick lines, I do edit on 5th commit and proceed. It will be land me on 5th commit, where HEAD is too. <nckx>mdevos: But it doesn't point at an existing package (unless you're a hardcore Platonist), it defines it. <mdevos>I'm a bit of a Platonist, it seems <nckx>raghavgururajan: Then yes, whatever âgit showâ shows will be pushed as the new tip. <nckx>âAll packages exist somewhere, you merely redescribed one.â <mdevos>âinstalleer het pakket EXPâ is wel wat kort door de bocht <efraim>raghavgururajan: I believe the time I tried it I ended up pushing all the commits <mdevos>Soms beschrijven we een pakket bij naam "hello", soms bij de locatie van de definitie -e (@ (gnu packages ???) hello), soms geven we de definitie -e (package ...) <mdevos>soms komen verschillende definities op hetzelfde pakket neer (de synopsis aanpassen wijzigt de derivatie niet, en heeft geen invloed op âgraftingâ) <nckx>efraim: It just depends on what you push, at the risk of being tautological. <nckx>Pushing HEAD:core-updates or core-updates:core-updates differ. <nojr>another question: do I need to specify JAVA_HOME when installing openjdk? which would be the path for it via guix package -i ? <mdevos>En dan is nog de vraag als je verschillende versies van een pakket als htzelfde pakket beschouwd ... Is "hello" op core-updates hetzelfde pakket als "hello" op master? Kunnen we wel van een "hello" pakket spreken op core-updates wanneer core-updates weer eens kapot is? <nckx>I really really recommend being explicit, not relying on âso this should do that by default, right?â. <efraim>nckx: sounds like technically correct, the best kind of correct <jlicht>mdevos: het gaat in ieder geval beide om een pakket met de naam "hello", meer dan dat zou je volgens mij niet kunnen zeggen <efraim>I normally run 'git push origin core-updates' <jlicht>mdevos: maar dat lijkt me op zich wel logisch, zo werken namen van dingen meestal ;-) <mdevos>ik spreek ook niet over âde paklijst BESTANDâ, maar âde paklijst in BESTANDâ <nckx>mdevos: There's a string in English somwhere like âcan' find package X for version Yâ which seems to acknowledge your point, but this is all quite esoteric. <efraim>raghavgururajan: nckx suggested using 'git push origin HEAD:core-updates', I would either create a temporary branch to push just the commits I wanted or create patches of the ones I didn't want to send, reset HARD to the commit I want to push, push those and then reapply the patches <efraim>(or find the previous HEAD using git reflog) <nckx>raghavgururajan: HEAD will be where you stopped, HEAD~N will go back N commits *from there*. Again, danger, just put away the tightrope. <efraim>so I guess 'git checkout -b cu-to-push; git reset --hard HEAD~6; git push origin HEAD:core-updates; git checkout core-updates' is what I'd probably do <nckx>raghavgururajan: You can always âgit show HEADâ and âgit show core-updatesâ to see the facts, no need to guess. <nckx>It will make it clear what's going on more than we can <raghavgururajan>nckx: When I am on the 5th commit and if I do `git push HEAD~5 origin HEAD:core-updates`, it will push the commits 1-5 right? <nckx>I can't even answer that without first making sure we're counting in the same direction from the same point. :) <nckx>Yes, just rely on what âgit showâ tells you. <mdevos>wat gebruiken we nu weer voor bootstrap? <mdevos>in âuse the bootstrap Guile to build the profileâ <raghavgururajan>Ah also, `git format-patch HEAD~5` generates the 5 patches I want. Doesn't include 6-9. <nckx>sneek: (string-length "langetermijnondersteuning") <nckx>mdevos: âvoor zelfstartenâ or so, I haven't considered all uses. <mdevos>ik zal zelfstart-Guile gebruiken <jlicht>optuig-Guile, zoals een feestelijke boom :) <nojr>so... I uninstalled guix's openjdk 14 and installed the one in ubuntu's apt <nojr>now I don't get the error message! but how come guix's openjdk is throwing the error message? <nojr>Caused by: java.lang.ClassNotFoundException: jdk.javadoc.doclet.Doclet <nckx>raghavgururajan: Yes, inclusive. *mjw is blij dat we voortaan Nederlands gebruiken :) <mdevos>is dit een potentiĂŤle vertaler? (-: <nckx>Now this, this is a coup. <nckx>mdevos: What've you used for âreturn [a list etc.]â? <mdevos>heb ik goed begrepen dat command -> roepwoord niet is doorgegaan, maar dat we command -> opdracht gebruiken? <mdevos>âdeze opdracht geeft een lijst van pakketnamen terugâ of dergelijke <nckx>Yes, I thought we had consensus on that last night and changed the glossary. <nojr>btw I'm running from a foreign distro <nckx>I see German uses âdeliverâ, I'll go with that over â~a gaf geen lijst van bouwmachines terugâ, but it's probably fine elsewhere. <nckx>mdevos: Sounds good and is used elsewhere. <nckx>Well, âsounds goodâ is always relative in these cases. <nckx>âSounds utterly alien because computers speak Englishâ. <apteryx>is the operating system PATH set correctly in a marionette test OS? (system* "pgrep" ...) suggests not <apteryx>ah, peeking at (gnu tests ganeti) I see (setenv "PATH" "/run/current-system/profile/bin") was used <solstag>Ni! Hey folks, I've successfully installed guix in a vm, now I'm trying to generate an image from within it, but `guix system image install.scm` yields `guix system: error: failed to load 'install.scm': Permission denied`. Any ideas? The file is there and its mode is 644. Sorry to bother. <darth-cheney>Hello all, guix newbie here. I have a question about environments <darth-cheney>I regularly use python venv and nodeenv as part of my dev workflow, but I use this liberally <mdevos>yes. For a project, I've a "guix.scm" <apteryx>darth-cheney: sure! 'guix environment --ad-hoc python python-dep ...' <mdevos>when I hack on the project, I do "guix environment -l guix.scm" <mothacehe>solstag: hey! what's the origin of the install.scm file you are trying to use? <mdevos>the first time I run it (or when packages are updated), it takes some time to compile everything <mdevos>but the second, third ... times things are fast enough for me <pkill9>you can also use direnv to automatically enter a guix environment when you enter the directory <darth-cheney>I guess the part that is confusing for me is what is the result of the guix environment? Is it a local dir that I can source like venv? How can I flip back and forth between environments? <mdevos>guix environment starts a shell that has environment variables set <mdevos>the environment variables are such that the packages you requested are visible <pkill9>and it saves the guix environment, so it will always be quick. i.e. won't build/download updates if you update guix <mdevos>to exit, type ^D, or exit, or whatever <solstag>mothacehe: well, I copied it from /gnu/store/.../install.scm <darth-cheney>mdevos is there a way to quickly source the env myself? I'm asking because I use ansi-term in emacs and I have custom setup stuff that happens there. I like to have only one term buffer open <mdevos>darth-cheney: see the "-p" option of "guix install" <mdevos>(that's not a use case I often have though, so I can't help you much there) <darth-cheney>ok thanks everyone, that's probably enough info to play around for a bit and see what I can do <nckx>The common phrase âexterne hostâ is also meh. <nckx>âBuitenlandse gastheerâ đ§ <mothacehe>solstag: looks like install.scm is refering to relative files, try "guix system image /gnu/store/xxx/install.scm" instead <pkill9>darth-cheney: there is a etc/profile file generated in the store path of the guix environment you can source <solstag>mothacehe: hm... that works with the original, but I had copied it over to modify the file. I have tried placing it in /tmp/install.scm but that didn't help. <pkill9>and you can create a symlink with guix environment -r <symlink> <pkill9>which will also prevent the garbage collector deleting that generated profile, until the symlink is removed <pkill9>so you can source <symlink>/etc/profile to initialise environment variables for that profile, e.g. PATH <pkill9>since you mentioned using venv, you'll want to add python itself to the environment so that it adds the PYTHONPATH environment variable to the etc/profile <mothacehe>solstag: you can then "cp -r /gnu/store/xxx/gnu/system /tmp/system"; edit /tmp/system/install.scm; run guix system image /tmp/system/install.scm <darth-cheney>pkill9: Thanks. And from there I use guix to install the python and/or node packages, rather than pip/npm in the sourced environment, correct? <pkill9>yea darth-cheney, although guix has almost no node packages, so you'll want to use node separately <pkill9>if it did, then you would want to <pkill9>actually, just to note, you don't install it from in that envrionment darth-cheney <gr0n>hi. i'm running guix on top of trisquel and am trying to install texlive with it, but am hitting an issue with latexindent (Can't locate LatexIndent/Document.pm in @INC (you may need to install the LatexIndent::Document module)) <gr0n>does anyone know how to fix this? <pkill9>you need to run something like `guix package -p <guix-enviornment-symlink> -i <package>` to install more packages to the environment <pkill9>but, it would make sense actually for guix to install to the current guix environment <pkill9>i'll send an email to the dev mailing list <nij>Hello! I'm trying to put up a working personal channel, by mimicking another one.. However, I don't know why I keep getting an error while `guix pull`: <nij>cannot build derivation `/gnu/store/g5yg63086vji1xplwnqlrj7g578abmpl-profile.drv': 1 dependencies couldn't be built <nij>I didn't bother putting any channel authentication stuff yet, because I want to go step by step. And it seems that it isn't required either. <nij>I have added my channel's name and url to `~/.config/guix/channels.scm` and run `guix pull`. That's where I got the error. <gr0n>also... how does one install packages with a regular expression, e.g. guix install 'foo-*'? <pkill9>what you could do is search with `guix package -A 'foo-*' | awk '{print $1}'` and turn those into arguments to use with guix package -i <pkill9>there's also a function for guile that lets you return a list of packages matching a regex, but I'm not sure <pkill9>though idk if you could use that with guix package -i <gr0n>pkill9: alright, i'll try that. thanks <solstag>mothacehe: sorry, it was my fault all along; my modifications were causing the error when ran; there was never a problem accessing install.scm; thanks a lot and sorry for the bother; at least your suggestions did lead me to figure it out. cheers! <gr0n>pkill9: it works, thanks <nij>Hmm.. I commented out everything in the only scm file in my channel, but `guix pull` still fails. What could I try? <nij>error - cannot build derivation `/gnu/store/mgp4h3lisygd8nny3fjqlagwlgvf615q-profile.drv': 1 dependencies couldn't be built <mdevos>gecached of gecachet? Ik heb geen idee hoe je "cache" uitspreekt <mdevos>de uitspraak van "to cache" eindigt op een sch-klank <mdevos>en het ex-kofschip zegt niets over sch-klanken <mdevos>misschien is het ex-kofschip gebrekkig <mdevos>maar het is wel in de xtc-koffieshop ... ik zal andere bronnen moeten raadplegen <cdegroot>Question on the erlang package - it has "glu" and "mesa" as propagated-inputs, which means it pulls in everything and the kitchen sink (I even saw cups pop by...). I'm not even sure it is needed to run wxWindows (which probably caused this), but given that not many people actually use wxWindows, is it an idea to have an "erlang-wx" package that just mixes erlang and these two and do the regular package without these deps? <cdegroot>Moet ik mijn zus vragen? Die is lerares Nederlands :) <mdevos>het is precies een coup, zoals nckx opmerkte <mdevos>Ik heb het op taaladvies.net gevonden <nij>I wish I understand what you are talking about. <mdevos>we're conjugating English verbs in Dutch <cdegroot>Die pagina is een goeie reden waarom ik nooit vertaler wil worden. Ik zie regelmatig "geĂźpdated" voorbij komen. Jasses. <cdegroot>nij: we're talking about you. Only bad stuff, don't worry :P <nij>cdegroot: I know. I have that feeling. <nij>Btw, I finally knew (somehow) why my channel doesn't work. <mdevos>cdegroot: moet dat niet "geĂźpdatet" zijn? Of bestaat er een uitzondering waardoor het "geupdatet" moet zijn <nij>I defpublic "hello", which might conflict with one from the official channel. <cdegroot>mdevos: zal best. Ik vraag mijn zus altijd :P <nij>But say I want to do that, how suppress "hello" from the official? <cdegroot>nij: I know exactly how you feel, like me when I commuted to work with the streetcar through chinatown here. <mdevos>ik cache, jij cachet, hij/zij cachet, wij cachen. Ik cachede/cachete (?), ik geef op <cdegroot>nij: shouldn't module names ensure no clashing? <nij>But anyway that's some progress.. i will keep trying. <nij>what's good about a talos? <nij>does it run lisp faster? <terpri>they're the only free-as-in-ryf high-end workstations afaik <lispmacs[work]>There is another company that does pretty good RYF x86-64 workstations, costing around $1000 <terpri>even my little half-assembled microatx blackbird box (waiting on ram) has 32 cpu threads <terpri>well, maybe beyond RYF then. as you say, free firmware, motherboard schematics included, etc. <lispmacs[work]>I'm living pretty much paycheck-to-paycheck, though, so I can hardly afford to keep my 6 year old Gigabyte motherboard running (replacing the fans and such) <cdegroot>```Engelse ww worden opgenomen in het Nederlandse klanksysteem. Dus roetsjte, geroetsjt, [kesjte], [gekesjt]. De ik-vorm blijft echter gehandhaafd: cache``` zegt ze. <lle-bout[m]>I suggest OpenPOWER for desktop/workstation and RISC-V for laptop when it becomes available, though chips with less power consumption based on OpenPOWER might also appear though not the focus of IBM now it seems (they're the main vendor of chips for now) <nij>lispmacs[work]: why not saving some money? <lispmacs[work]>nij: no money left over to save. It all goes to rent and buying food, clothes, etc. for the wife and kids <terpri>as they say, lots and lots of cash is the price of liberty (one reason i'm not a huge fan of the hardline anti-blob policy though i understand the reasoning behind it) <lle-bout[m]>nij: lispmacs[work] : I think obsessing on freedom with hardware when you can't afford it is not worthwhile, better get some refurbished hardware with proprietary parts and reasonable performance and wait for an affordable option, that's my personal opinion, I have a Dell XPS 13 2020, I just wish better options freedom-wise appear soon, but I can't take in so much frustration, I also need the performance-per-watt for my <nij>lle-bout[m]: you know, obsession about freedom is like obsession about art. hard to deny.. <lle-bout[m]>Strict anti-blob is not environmentally responsible, and that overlap for me is also problematic <cdegroot>lle-bout[m]: for pretty much the same reasons I got a T5810 a new lease on live last year :) <lle-bout[m]>There's so much proprietary hardware available second+ hand that works and it would be unreasonable for me to just trash that for freedom <mdevos>Now, if only $VENDORS would always publish the firmware as free software, and give everyone a mechanism for replacing the firmware with your own copy! <lle-bout[m]><mdevos "Now, if only $VENDORS would alwa"> Yes, so the electronical waste would be even lower since users could make communities to maintain their own hardware software-wise forever if they needed to. <terpri>there's some world wherein the anti-blob policy would increase overall software freedom (pressuring vendors, motivating reverse-engineering etc.) but i don't think we live in such a world atm <lfam>It's definitely a balancing act <lfam>We don't want to push away people who are sympathetic to our ideals, just because they can't use their computers with Guix and linux-libre <gr0n>^ this is a common thing that i see <terpri>...but they *can* use windows and run guix in a vm, which imho is strictly worse <lfam>It's a situation where "the perfect is the enemy of the good", IMO <gr0n>even though i run fully free trisquel, i'd rather see someone use ubuntu on their system than see them use windows or macos <lle-bout[m]><lfam "We don't want to push away peopl"> I wouldnt want to, but I also don't want to spend time *supporting* proprietary stuff, but that work's mostly done with Linux vanilla these days so.. <lfam>Another thing to consider is that the foundations of GNU were created on hardware that would never meet the RYF standards <nij>:-((( after three hours I'm still trying to set up a minimal working personal channel.. `guix pull` kept failing.. i wonder if someone could help out :-) <lfam>Have you shared your channel definition and your error messages yet? <nij>Yep, up there. I can share again. Hold on. <lle-bout[m]>I also hope that people don't forget these ideals once things work on proprietary hardware, as in that Linux-libre is also a push to make things work with it <lfam>Right, and that is what makes it a balancing act <lle-bout[m]>The convenience can drive away your motivation to act for change <lfam>It's hard to find the right place <gr0n>lle-bout[m]: it is pretty common to see it happen, but it's the cracks in "convenience" start to show when you realize that the thing you want to do on some system doesn't work because the company doesn't want you to do it <lle-bout[m]>Let's be honest since I got my x86 laptop, I barely use my OpenPOWER desktop, because transportation is actually really important for me. <gr0n>so said convenience quickly turns to frustration. <gr0n>even though i have the option to use a perfectly functional MBP, i still prefer my x200 because the MBP just doesn't let me do things i want to do <gr0n>wanting to tile with the keyboard, using tools like argbash with ansible deployments written to be run on GNU/linux and various tools like that. <gr0n>all of this is absolutely terrible on a MBP <gr0n>so it's not all that convenient if that's a main part of your workflow. <gr0n>oh good luck getting linux-libre to work on the modern MBPs <gr0n>every time i tried it didn't even boot <lle-bout[m]>Ah right, that for sure. I think you can reinstall with GNU Guix there. <gr0n>i tried ubuntu once and had no wifi working <lle-bout[m]>It should boot and if not it would be something not too hard to fix <gr0n>kind of defeated the purpose <cdegroot>gr0n: my previous employer forced an MBP on it, I expensed a parallels license and just had it start a fullscreen Linux VM on boot ;-) <gr0n>cdegroot: yeah, that's one way around it :D <lfam>Friends! This is the best time to test the installers for the upcoming 1.2.1 release. <lfam>Let us be bold, and risk wrecking our installations :) <lfam>(I already tried them in recent days, and it went okay, but there are always more bugs to find) <nij>How could we help out? By using it and reporting errors? *gr0n should spin up guix in a VM to try out these things. currently runs guix on top of trisquel for a few things <lfam>That's how to install Guix System in a QEMU VM ^ <nij>I will wipe my current machine and try it tonight! <lfam>But, I'll be reinstalling on bare metal later today <gr0n>lfam: thanks. i'll probably end up just running my libvirt setup that i have for my VM pool. you think it will work that way as well? <lfam>mothacehe: Really? It worked for me just a couple days ago <lfam>Now is the time to report bugs <mothacehe>There's at least a timeout issue while building libgc <lfam>Oh, you mean about ppc64le <gr0n>btw, do you guys know if guix works on non-GNU/Linux things, such as the BSDs? we have a very large deployment of FreeBSD for research purposes at a university and we currently build everything ourselves when it comes to packages using poudriere (typical FreeBSD way to do it). guix would be really helpful to use when it comes to maintaining different versions of things on user accounts, and not requiring a <cdegroot>I just installed Guix on Debian/arm64, did I get the "this is the version we want you to test with" installer? <lfam>gr0n: Guix basically assumes that glibc is there, so it won't be trivial to use it on BSD. But, I'm sure that something could be done to make it work <lfam>Does BSD have a KVM-like "native" virtualization option? (I figure it must) <gr0n>lfam: i see, that makes sense. i guess i'll play around with it in a FreeBSD VM from time to time <gr0n>it's called bhyve and libvirt supports it as well <gr0n>i believe people have previously used it to do a macOS-style docker (and i actually think macOS used bhyve itself to do it...) <Telc[m]>that looks workable but needs some efforts in getting it to compile <lfam>Telc[m]: Guix includes a crate importer. Did you see that yet? <lfam>For example, `guix import crate --recursive rav1e` <lfam>If it's not in your copy of the docs, then your Guix is too old to include it <Telc[m]>hmm maybe im looking in the wrong place <lfam>However, from what I can see, it was included in 1.2.0 <lfam>Crate packaging is still somewhat (too) complex in Guix, but at least this tool will help <Telc[m]>yes thank you this is a better start <lfam>Alright, let us know how it goes <mdevos>heeft iemand een idee hoe je deploy vertaald <mdevos>in âDownload and deploy the latest version of Guix.â <cdegroot>"uitrollen" is wat ik zou zeggen. Maar "Download en rol uit..." - bah... <mdevos>Ik heb "download" op de zwarte lijst gezet als anglicisme. Misschien is dat wel een beetje overdreven <mdevos>ik maak er âbinnenhalenâ van. âHaal de laatste versie van guix binnen en rol het uitâ <mdevos>voorlopig hou ik het op uitrollen <jlicht>uitrollen/'de uitrol' is hoe ik heb meer dan eens voorbij heb zien komen <mdevos>wanneer is de âdeadlineâ (daar heb je weer een Engels woord) voor de vertalingen <mdevos>zodat ze in de nieuwe guix âreleaseâ (uitgave) komen? <jlicht>roptat will know (/decide?) when the deadline for translations is. <cdegroot>mdevos: ik zie dat je een .be adres hebt, dat is permissie om alle anglicismen de nek om te draaien, niet? <mdevos>zijn anglicismen verplicht in NL of zo? <cdegroot>Ik heb me altijd laten vertellen dat onze zuiderburen meer gesteld zijn op de Nederlandse taal en beter hun best doen het ding in stand te houden dan de Hollanders, die met plezier Duits met Engels mengen en dat dan Nederlands noemen ;-) <jlicht>De laatste 'vergadering' die ik had staat me niet meer bij, maar 'meetings' heb ik elke dag <mdevos>Here's an untranslatable fluff word: Provisioning <mdevos>âProvisioning for machines that are accessible over SSH and have a ....â <cdegroot>(rent naar zijn boekenplank met woordenboeken...) <mdevos>ik heb een vertaalwoordenboek Engels->Frans en Frans->Nederlands <mdevos>een familielid is die nu gaan halen <cdegroot>"verschaffen"? Technisch correct, maar of het gaat helpen in een zin... <jlicht>ik ken 'reserveren' vanuit het (kleinschalig) boekhouden, maar dat past hier niet <roptat>jlicht, mdevos, I'll send the translations to master tomorrow (17), and I'll try to send an update on the 18, before the release <jlicht>mdevos: 'Ter beschikking stellen' zou op zich passen <roptat>consider 17 evening to be the soft deadline, with a hard deadline on the 18 <roptat>of course, you can continue to translate afterwards, the hope is that we can have continuous translation after the release <mdevos>tip of a branch --> uiteinde van een tak? <cdegroot>sorry, zat ff de "prov...." in het Groot Woordenboek door te nemen. Niks. <jlicht>mdevos: vertakking i.p.v. tak, (tenzij we nu al overal tak gebruiken) <jlicht>en daar een "?" achter, want het was slechts een voorstel :) <mdevos>maar ik kan in vervolg vertakking gebruiken? <mdevos>ik heb branch->tak in de glossary gezet <mdevos>Als je twijfelt of iets een anglicisme is --> Woordenboek der Nederlandsche Taal ***badpixel- is now known as badpixel
<nckx>I've used aftakking or vertakking thusfar, I can't remember. <nckx>I think aftakking because it was surprisingly (to me) more common. <nckx>âProvisioningâ isn't a word, surely? <mdevos>âInternal tool to substitute a pre-built binary to a local build.â <mdevos>what is âto a local buildâ doing there? <rekado>instead of performing a build locally you get a pre-built binary <mdevos>so âto a local buildâ is superfluous? <nckx>So it should be âforâ? <rekado>(I donât have the context right now, so I could be wildly off target) <nckx>mdevos: Translate it as if it said âfor a local buildâ and we can fix the English later. <roptat>you can leave comments for the source string, to not forget about it, and fix it after the release for instance <roptat>I did that on a couple minor issues I found in the cookbook <Telc[m]>@lfam so I'm getting """;;; Failed to autoload string->semver-range in (semver ranges): <Telc[m]>;;; no code for module (semver ranges)""" on any invocation of guix import crate -v foo <lfam>Telc[m]: I think (not sure!) that you need to make guile-semver available. <gr0n>lfam: sorry for the ping, i'm just curious if you know where the bottlenecks of guix come from. it seems to be pretty slow when installing a lot of packages that aren't dependencies <lfam>So, before your command, do something like `guix environment --ad-hoc guile-semver`, and then try again the environment <lfam>I mean, try again within the environment <lfam>gr0n: There's a few bottlenecks, and there is some recent discussion about profiling them on the mailing list <lfam>One big bottleneck is with grafting on spinning disks. It's very I/O intensive. It's not even that fast on SSDs <gr0n>i see, that makes sense why my guix run right now is painfully slow. it's running on the HDD :) <leoprikler>grafting is not even that slow, union-building the profile is the real killer <Telc[m]>lfam: haha awesome that was the trick... unfortunately now I have a 1300line scm file filled to the brim with dependencies <lfam>Yeah, Rust is like that! <lfam>Ah, thanks for clarifying leoprikler <lfam>There's a profiler built-in to Guix, right? <leoprikler>I do think Guile has a profiler, but I only have anecdotal evidence. <leoprikler>(Said anecdotal evidence being, that a particular profile with ~60 packages takes about 10 to 15 minutes to build after grafts succeeded.) <gr0n>my anecdotal evidence is that i've been installing ^texlive-* for the past hour and it's not done :( <gr0n>it's basically installiing one by one and building profile with X packages takes a long time <roptat>have you tried installing the monolithic "texlive" package, instead of every small part? <gr0n>roptat: i have, but i'm trying to get latexindent to work which asks me to install something i don't understand :) <roptat>that package is huge (2GB I think), but at least it's only one <roptat>oh ok, I don't understand latex either <gr0n>basically, latexindent complains about: Can't locate LatexIndent/Document.pm in @INC (you may need to install the LatexIndent::Document module) <gr0n>so i'm taking a chance that if i install everything texlive-*, it will install that thing too <gr0n>i don't understand guix well enough to know how to fix this <roptat>hm, maybe you're simply missing an environment variable? have you tried loading ~/.guix-profile/etc/profile? <gr0n>roptat: yep, that's all loaded (and texlive itself works, it compiles things, etc). latexindent is the only thing that's broken <gr0n>the thing is, latexindent is a perl script and has some dependencies that might not have been installed. however, i've tried to install the ones i can find it using manually and it didn't help <roptat>I see, sorry I can't help more than that <gr0n>no worries, appreciate the help you already gave :) ***sneek_ is now known as sneek
<sneek>lfam, Noisytoot says: I can still use sneek <roptat>since it seems we have a service for that now? <lfam>It is nice to have some advice about imperative connections, but unless there is something special about that on Guix, it's not something we need to document <lfam>`nmcli connection up wg0` doesn't seem Guix-specific <lfam>Is it still necessary to manually add the kernel modules? <lfam>We have two kernel versions that include Wireguard by default, IIUC <gr0n>hmm, i think the guix texlive package is missing LatexIndent::Document, there isn't any way to obviously get it <roptat>the manual says it's for Linux-Libre < 5.6 <gr0n>when you install texlive, you can't really run latexindent as a result <lfam>I wish we had a better understanding of which kernel versions were actually being used <gr0n>how do i contact whoever packaged a specific guix package? sorry i'm a complete newbie to guix <lfam>gr0n: In Guix, we don't have "package maintainers". Anyone is welcome to work on a package <lfam>But, you can use the Git log to see who added a package originally, or who has worked on it recently <roptat>in general, you should send bug reports to bugs-guix@gnu.org, not to individual people <roptat>is LatexIndent::Document a perl package then? <gr0n>i'm actually not sure. i think it's actually a package of texlive, but it is a perl script <gr0n>when i look at what trisquel installs from perl, it doesn't include anything like this as a part of perl <gr0n>instead, it gets installed as a part of texlive <meo>test "channel news, one entry" fails in current guix master, is this worth reporting? <roptat>right, tried to import it, but it's not part of cran <gr0n>this is the exact line that fails <gr0n>now, for some reason, it is missing. <gr0n>in fact it seems like the whole LatexIndent directory is missing <gr0n>hm, maybe not. i just found it *gr0n wonders why latexindent can't find it <gr0n>Can't locate LatexIndent/Document.pm in @INC -> seems like it has something to do with @INC, whatever @INC is in texlive... i'll look into it a bit <roptat>@INC sounds like perl's search path <gr0n>i wonder if this is because of the directory structure guix sets up, specifically ~/.guix-profile/share/texmf-dist/scripts/latexindent, so we maybe need to set an additional -I in the latexindent invocation? <gr0n>or perhaps just set PERL5LIB somewhere? <roptat>that's not the usual location for perl scripts <roptat>unless latex is supposed to do something by itself <gr0n>yeah, but i assume that this isn't *too* different to the upstream texlive distribution, so latex probably does it itself? <roptat>yeah, but then why doesn't it do it under Guix? <gr0n>that's what i don't understand :( <roptat>is this file also in this location on other distros? /usr/share/texmf-dist/scripts/latexindent? <gr0n>under trisquel, it's /usr/share/texlive/texmf-dist/scripts/latexindent <roptat>according to the line before, the magic is supposed to be lib in "use lib $FindBin::RealBin;" <gr0n>perhaps what's missing is texlive/texmf-dist/scripts? <gr0n>as in, the texlive/ part <roptat>Noisytoot, why talk through sneek? <roptat>gr0n, maybe... I'd like to understand the lib part in the code above, to understand what it does and why it's supposed to ensure @INC contains latexindent <Noisytoot>sneek: tell roptat because lfam ignored me, so if I don't use sneek, lfam won't see the message (and it's unrelated to the reason that he ignored me) <sneek>roptat, Noisytoot says: because lfam ignored me, so if I don't use sneek, lfam won't see the message (and it's unrelated to the reason that he ignored me) <gr0n>roptat: yeah, i haven't looked into it in too much detail. i assume it uses Document later on, assuming it's in the @INC path instead of trying to guess where it should be based on the texlive installation <gr0n>but i'm not sure if that's the actual reason. <roptat>so $FindBin::RealBin must be wrong <jeko>sneek: tell Noisytoot Hello from my first sneeky message <sneek>Noisytoot, jeko says: Hello from my first sneeky message <roptat>does it tell you what @INC is at that point? <gr0n>i guess another (perhaps obvious) question is, can you reproduce this or is it my borked installation? <gr0n>it does, i will DM it to you to avoid spam <roptat>you can also use paste.debian.net <nckx>Using sneek to evade ignores is not acceptable. It's sad that I even have to point this out. <jeko>Broad question : how do you manage your emacs dotfiles for your Guix System ? I mean, do you have it somewhere defined into your system definition ? or do you git pull it when your system is ready to operate? <roptat>gr0n, I'll need time to download the substitute :p <gr0n>roptat: in that case, i can try to look at each include path and try to see if the right thing is there <roptat>/gnu/store/jr9czrjx7slnda355xfmbv6hkkdpl5qi-texlive-bin-20190410/share/texmf-dist/scripts/latexindent sounds the most promising <gr0n>roptat: the only thing in there is latexindent.pl (the actual script). however, there is no directory <roptat>so where does your ~/.guix-profile/share/texmf-dist/scripts/latexindent come from? <gr0n>the other directories seem irrelevant <gr0n>roptat: it comes from doing a find in .guix_profile <gr0n>just to see if it exists. <roptat>ah sorry, I misunderstood, you couldn't find a Document.pm, could you? <gr0n>it sounds like /gnu/store/jr9czrjx7slnda355xfmbv6hkkdpl5qi-texlive-bin-20190410/share/texmf-dist/scripts/latexindent should actually be ~/.guix_profile/share/texmf-dist/scripts/latexindent <gr0n>roptat: yep, Document.pm is the missing thing, which is under LatexIndent directory <roptat>and there's no LatexIndent directory in your profile? <roptat>oh texlive is bigger than I thought, 3.3GB <gr0n>there is in the profile, specifically at ~/.guix_profile/share/texmf-dist/scripts/latexindent/LatexIndent <gr0n>when i do a realpath on it, it's in /gnu/store/cqfhb3hfvyxacn200n0jxkf3wq8328yq-texlive-texmf-20190410/share/texmf-dist/scripts/latexindent/LatexIndent <civodul>lfam: hi! there's an "ungrafting" branch meant to be merged before the release, right? <gr0n>however, it seems like jr9czrjx7slnda355xfmbv6hkkdpl5qi-texlive-bin-20190410 should be cqfhb3hfvyxacn200n0jxkf3wq8328yq-texlive-texmf-20190410 <gr0n>so instead of texlive-bin, it should be texlive-mf <roptat>latex expects to be installed in the same directory, but we split it in latex-bin and latex-texmf <gr0n>yes, i think that might be the cause <roptat>so use lib $FindBin::RealBin; adds the path of the binary, in texlive-bin <roptat>but this is incorrect, because it should be the path to texlive-texmf <gr0n>so i guess the question becomes, does it make more sense to not split texlive, or does it make more sense to fix the paths? <roptat>it's probably better to fix the paths *gr0n wonders if any other texlive tools have this problem <roptat>mh, although that will be an issue: then we would have a reference from bin to texmf <gr0n>roptat: that's true, which isn't great if someone wants to just install a small part of texlive and no tools <roptat>Noisytoot, isn't that obvious? if they're ignoring you, that's their choice, you shouldn't evade it <Noisytoot>roptat, The messages I am sending via sneek are unrelated to the reason for ignoring me <roptat>but that's not a reason, if someone tells you "I don't want to listen to you anymore", you don't take a megaphone to talk to them <roptat>gr0n, maybe the best solution would be to make latexindent part of texmf instead? <gr0n>roptat: so i'm a bit of a newbie in guix, but it seems like in tex.scm, there's no obvious way to fix up the paths? it seems like texlive-bin itself will set up these paths, rather than guix? <roptat>then it would have the right path and wouldn't make the rest of texlive-bin depend on texmf <gr0n>hmm, it would solve the issue with latexindent but i wonder if other tools do that? <gr0n>i found this with latexindent through pure chance by running latexindent in vim <gr0n>if it's only latexindent, it probably is the simplest workaround <roptat>right, I don't think anyone uses these tools very often <roptat>maybe they're all broken except the ones we fixed manually ^^' <gr0n>the good news is that latexdiff works. <roptat>but if we only used the ones we fixed... <gr0n>another one that doesn't work is latex-git-log <roptat>in any case, if you can't write a patch, could you at least send a bug report to bugs-guix@? <Telc[m]>in the package scm files what is "license:expat" it should say bsd something <gr0n>let me take a look if i can patch it relatively painlessly. i've done scheme before but need some time to familiarize myself with guix itself <Telc[m]>this is in a generated file from guix import <roptat>Telc[m], expat is what most people call the MIT license <lfam>civodul: No, we aren't going to ungraft for the release <Telc[m]>having some issue building around license module <roptat>Telc[m], if the importer is wrong about the license, then fix it manually <lfam>civodul: There were so many grafts, some of which were full upgrades, that it was basically a core-updates branch, and we didn't think it could be done in time <roptat>in many files, we import the license module as #:use-module ((guix licenses) #:prefix license:), which means that every variable from the module must be prefixed with license: <Telc[m]>"""error: unknown-license!: unbound variable <Telc[m]>hint: Did you forget a `use-modules' form? <roptat>yeah, we don't have unknown-license <gr0n>roptat: it might make sense to make all of the texlive-scripts become a part of texmf, since a lot of them exhibit this behaviour <roptat>oh, maybe you're using it in a module that simply imports (guix licenses) without a prefix <Telc[m]>""" #:use-module ((guix licenses) #:prefix license:)""" <gr0n>there would be a lot of exceptions in texlive-bin it seems <lfam>I really wanted to ungraft, but I thought it was too ambitious <roptat>Telc[m], are you sure you don't have "unknown-license" somewhere in the file? <civodul>lfam: perhaps it'd still be an improvement to ungraft just some of the things? <civodul>that can still be done relatively quickly <roptat>that would be the importer telling you it couldn't determine the license, and you have to check by yourself <lfam>civodul: Yes, perhaps... it seems very late to be making changes to low-level parts of the system, though <gr0n>yeah i don't see an obvious way to do this split, i'll write an email to bugs-guix@, perhaps some discussion can happen on how texlive should be packaged to make the workaround unugly <gr0n>any patch i write will be opinionated, so i'd rather avoid that given that i haven't worked with guix before <lfam>civodul: Regarding Nettle, it's a difficult situation. There's no ABI compatible bug-fix release, and the Nettle author didn't point to any patches we could cherry-pick <lfam>Unfortunately, there's not much we can do <lfam>Maybe another distro has patches we can use <civodul>lfam: yes, i looked at applying the patches, but as Niels wrote, there are conflits, and i'm not comfortable with that <civodul>turns out Debian doesn't have 3.5 :-) <lfam>Yeah, I had checked Debian at the time <Telc[m]>sorry roptat is the license field text or is it an enum of some kind? license is "MIT-0" according to crates.io <roptat>er, MIT-0 doesn't make much sense ^^' <roptat>(guix licenses) exports a bunch of variables <lfam>civodul: If we want to try ungrafting some things, we should push the code ASAP, if we want substitutes at release time for aarch64 <lfam>I'll look now for candidates; grafts that only apply some patches <sneek>lfam, Noisytoot says: What's ungrafting? <lfam>And certain packages we can be more confident about upgrading, like OpenSSL <civodul>lfam: yes, and presumably for packages not too deep in the graph <lfam>Noisytoot: I asked you to stop contacting me, and others have asked you to respect my wishes ***ChanServ sets mode: +o lfam
<roptat>Telc[m], so it's like expat, but without the attribution requirement <roptat>I don't know what's the requirement to add a new license to Guix *Noisytoot still doesn't know what ungrafting is <roptat>in the worst case you can use the non-copyleft procedure <Telc[m]>ok well i wont block on just building <roptat>like (license:non-copyleft "LICENSE") <roptat>with a comment saying it's MIT-0, and maybe with a link <civodul>yeah, until there are several users of the license, it doesn't need to be defined in (guix licenses) ***ChanServ sets mode: +b *!*@fsf/member/Noisytoot
***Noisytoot was kicked by ChanServ (User is banned from this channel)
***noisytoot[x] was kicked by ChanServ (User is banned from this channel)
<vagrantc>Noisytoot: grafting is a trick to avoid having to rebuild lots of things things for things like security updates ... but best to remove them eventually <Telc[m]>i suspect there will be more then 1 civodul <lfam>Noisytoot was warned not to try circumvent my attempt to ignore their messages <lfam>It's not okay to use technical workarounds to contact users who have asked to not be contacted and set up ignores ***ChanServ sets mode: -o lfam
<civodul>lfam: thanks for doing the right thing <gr0n>hum, am i missing something here? i can't seem to send an email to bugs-guix@gnu.org? <cdegroot>is it me or is the substitute coverage for ARM lacking? My poor RPi4 is running hot compiling all sorts of stuff. Not a biggie, if it melts I'll return it as DOA, it's new :P, but wanted to know whether that's expected. <lfam>cdegroot: I'm not surprised it's lacking. We recognize a lack of build capacity for 64-bit ARM as a problem, and we are taking steps now to improve it <lfam>It's hard because the market for capable hardware is still in its infancy <lfam>But, there are some options, and we are trying to acquire them <Telc[m]>next license missing :) " Apache-2.0 WITH LLVM-exception" <cdegroot>lfam: ok, if it's expected, i'm good. I wish I could contribute. Want to have my spare RPi B? :P <lfam>I think the Pis won't make great build farm machines. We need hardware that is designed for high-performance (server chips), rather than low power consumption (mobile chips) <cdegroot>OTOH, a distributed effort using people's RPis might be better than nothing... <lfam>We have the resources we need to get the hardware. Now, it's just a matter of the hardware actually existing. The semiconductor shortage has hurt the device manufacturers <lfam>What was "in stock" a couple months ago seems to have vanished <lfam>And there is not much of a second-hand market yet <vagrantc>i had hoped to get at least my own personal armhf/aarch64 build machine going on some decent hardware, but ... other priorities :/ <cbaines>I think the overdrive I have with me is still idle <cbaines>and the "experiment" I'm running with guix.cbaines.net for armhf-linux and aarch64-linux builds is going pretty well, armhf-linux builds are still happening, so I'm waiting to see how far it gets, but I'll email guix-devel when I have a little more data <lfam>cbaines: I'm still waiting for "simple instructions" on how to connect your overdrive to Berlin to emerge <lfam>I didn't totally forget about it... <mihi>Hello :) My quest on Guix Hurd continues. Last time "guix pull" inside died at some point (after building openssl) as there were no CA certificates bundled, so this time I'd try to give it some CA certificates first. I could copy some from my (Debian) Linux system, but was wondering what the canonical way is to get them on a Guix system. Some package to install? <lfam>Yes, they come from the nss-certs package <lfam>I think it's enough to add nss-certs to your config.scm's 'packages' field and reconfigure <lfam>civodul: I just pushed a wip-ungrafting branch. These are grafts that are just a patch or two, plus an OpenSSL update (I'm confident in those) <lfam>We should start building it ASAP <lfam>We could also do curl, I suppose <mihi>lfam, no way to reconfigure. I'm using the downloaded Hurd VM image without having a Guix Linux available. guix reconfigure does not work before guix pull on the VM image, it seems. <mihi>my first goal was to reconfigure to get some more TTYs. now there are more sub-goals until I can get to that point :) <lfam>Then, I would do `guix build nss-certs`, and then manually set up the environment variables mentioned in that manual section that I linked to <mihi>but what works is to pass a VISO to the Hurd VM as /cdrom, mount it, drop into kernel debugger (apparently there is a breakpoint in cdrom driver somewhere), exit kernel debugger with "cont" and copy the files from there into the system :) <lfam>What happened with `guix pull` is actually a bug on our end <mihi>ah, http is probably the easiest way, yes :) <lfam>But, we can't go back in time and fix it for 1.2.0 <raghavgururajan>Hmm. I think someone else is using the nick Noisytoot, lfam. I never seen this behaviour from that nick before. <lfam>It's unfortunate, but the 'Noisytoot' user earned the ban <nckx>lfam: Thanks for banning NoisyToot. You did the right thing. <lfam>If I understand correctly, the ban was not just based on nick <nckx>Nope, they were logged in. <lle-bout>Wasnt Noisytoot working on SourceHut stuff <lfam>Like I said, It's not okay to use technical workarounds to contact users who have asked to not be contacted and set up ignores <raghavgururajan>Yeah. I use to see that nick in #libreboot often in #libreboot. But never seen behaviour like this. <lfam>The mailing list is still open... <nckx>raghavgururajan: They've been around in #guix a lot recently, and I didn't expect this behaviour from them either. But it happens. <nckx>âauthenticated to servicesâ, to use the formal term :) <lfam>Guix development is based on mutual respect. I set my client to ignore that user, and asked them to stop trying to contact me. Instead of dropping the issue, they used sneek to speak to me anyways <lfam>They were warned to stop doing that, and they did not stop <bandali>is it a short-term time-out type thing? <lfam>They DM-ed and used sneek to contact me in this channel <lfam>If they continue to attempt to circumvent the ban, no <lfam>If they demonstrate a pattern of good behaviour in other regards, I don't know <lfam>Unfortunately, they aren't doing themselves any favors since the ban... <nckx>I'm never sure for how long to ban someone. <nckx>Disregarding the own-grave-digging sounds: when do you decide it's time to give someone that chance, bandali lfam? <civodul>lfam: thanks for wip-ungrafting! do you want me to set up ci.? <Telc[m]>is there some normal path for greping guix tree sources in guix itself or should i just check it out somewhere? I have no idea how guile is resolving libraries I guess... <lfam>Great civodul. I'm pushing one more ungraft, of GnuTLS <lfam>The remaining grafts are version upgrades, or a long list of patches <nckx>dongcarl: Wow! Long. Sweet. Thank you, I'm going to bookmark this for future pointings to. <lfam>nckx: I leave it up to the maintainers <dongcarl>I'm following in the footsteps of pjotrp[m] with the very long docs :-) <lfam>I got started with Pjotr's notes! <lfam>You can say that about Pjotr :) <nckx>different-nick: I don't like bans. You're welcome back when you agree not to play any more games trying to skirt social rules. How does that sound? <mihi>lfam, seems that "guix build nss-certs" as well as "guix install nss-certs" fail as python cannot be built due to some dependency... So now plan B :) <mihi>I know Hurd is an adventure :) <lfam>mihi: We are planning a new release (1.2.1) on Sunday. Hopefully it will be easier to start with that. We could even run some tests now, before the release, if you could give us advice about what to try <lle-bout>lfam: hey, you saw xorg security releases recently? <mihi>somebody even forgot to link the MAKEDEV script somewhere outside of the store, so my way to make devices for my CDROM is 'find the MAKEDEV script in store and symlink it manually' <lfam>This assumes you are working from the 1.2.0 release. If you are working from the current master branch (ie with `guix pull`), then your tests are the same as what we'd do <lfam>lle-bout: I saw CVE-2021-3472 <lfam>Yes mihi, that is the master branch <lfam>You can find that out by clicking the "Evaluation" number (21564), where it shows which Git commit the build is based on. Then, use `git log` or other tools to check which branch the commit is from <civodul>apteryx: hi! if you're giving "make release" a try, you can ping me in the coming days if you notice anything wrong <civodul>or if there are offloading issues or anything <mdevos>zijn Nederlandse vertalers nog hier <mdevos>nckx, jlicht: host -> herbergier? <jonsger>btw congrats on all those involved with GNU assembly! Nice initiative :) <nckx>mdevos: I never know if you're joking. <mdevos>nckx: I might be joking, but my proposal is still serious <nckx>God you're me 10 years ago. <apteryx>civodul: alright, yeah I test this weekend. Also I've been trying to finishing up some tests for a jami service, I think it's almost complete. We should be able to use this a live bridge soon. One issue I had is attempting to import the json module inside the gexp of a computed file, like so: https://paste.debian.net/1194049/ <nckx>âMachineâ or âcomputerâ or so; it's not waard puns. <mihi>mdevos, I saw in the logs that you also tried to join the adventure of Guix Hurd. How far did you get? :) <mdevos>But my preferred system for managing VMs is gnome-boxes <mihi>ah now wit the certs from debian, guix pull dies with a SIGILL :( <jlicht>mdevos: herbergies is misschien vergezocht <mdevos>but gnome-boxes only supports installing from ISOs <mihi>I don't have a child hurd (not even a Guix Linuxx system) but I successfully converted the qcow to vdi with qemu-img and then imported it into VirtualBox <mdevos>jlicht: heb je een alternatief? Dit is voor VM's en containers, waar je een systeem binnenin een ander systeem kan hebben <mihi>now the good question: how to get gdb into the hurd image? or should I try to mount it from my Debian hurd and use gdb from there? <mdevos>"guix install gdb" from within the VM? <jlicht>mdevos: kent onze mooie taal een unisex woord voor gastheer/vrouw? <jlicht>wat niet direct doet denken aan een herberg, bij voorkeur <mihi>will be built: python-minimal-wrapper... I'm curious whether that one will work... <nckx>Or is that implicitly gendered. <mdevos>hospes, hospita, volgens nl.wiktionary.org <nckx>I think plenty of gender-neutral terms are gramatically m, but maybe. FWIW I've only ever heard hospita used in practice. <mdevos>hier is een lang woord: initrdmoduleveiligheidscontroles <mdevos>ga er veiligheidscontroles van X en Y van maken <nij>lfam: I'm installing a fresh guix on my machine using the ISO you posted a few hours ago. So far so good, except it doesn't detect my wired internet (yes I'm using graphical).. which is weird cuz my machine is always on ethernet and it has been working for days. <lfam>Do you know if there is a DHCP server running on your network? <nij>Hmm i dunno what that is @_@.. <nij>I'd be happy to dump you my machine info if that'd be helpful, once it finishes installing. <lfam>Okay, then it's probably "yes" :) <civodul>apteryx: for (json) and (zlib), you need: (with-extensions (list guile-json guile-zlib) #~(...)) <lfam>I'll be testing it this evening too, nij. But, please your findings in an email to <guix-devel@gnu.org>, maybe with a subject like "1.2.1 pre-release testing" <nij>After installing it, would it help more if I keep using it? Or if the installation is OK, then it's probably OK enough? <mdevos>nckx: ik ga in het vervolg hospes gebruiken, ok? ***overclucker_ is now known as overclucker
<mdevos>weet je iets leuks voor ânetwerkinterfaceâ? <vagrantc>wow, the projected 1.2.1 release date is fast approaching ... will there be a release-candidate today or tomorrow? <lle-bout>Would it be reasonable to postpone the release by a couple of days to give time for more testing?