<vincele>hello, I'm getting strange error just doing `./bootstrap ; ./configure --localstatedir=/var ; make -j 16` <vincele>ice-9/eval.scm:293:34: error: %strict-tokenizer?: unbound variable <vincele>it's reproducible even after make clean <lfam>vincele: Hm, that's familiar but I was able to get past it <lfam>You might need a more recent version of Guix. That means doing `guix pull` <lfam>You can check your version with `guix describe`, and a `which guix` for good measure <vincele>OK I'm on old version (19 march) and I remeber having had a disk full (cuirass-induced) so that may be another hint... I'll go try `guix gc --verify=contents` <leoprikler>civodul: I'm not familiar enough with the Go side of things, but I think my personal nitpicks have been addressed. <civodul>efraim: it'd require including (gnu packages hurd) in (gnu packages linux), though <sneek>Welcome back civodul, you have 1 message! <sneek>civodul, apteryx says: thanks that helped :-) <xkcn>sneek is back? sneek is back! <leoprikler>I think I figured out the use behind sneek tell. <sneek>leoprikler, leoprikler says: heartbleed <xkcn>sneek: tell leoprikler I don't get it. <sneek>leoprikler, xkcn says: I don't get it. <leoprikler>sneek tell xkcn essentially, tell is a more powerful "echo" <sneek>xkcn, leoprikler says: essentially, tell is a more powerful "echo" <xkcn>That answers none of my questions and serves only to further confuse me. <leoprikler>Essentially, you don't use tell to delay telling someone something in the future (or to circumvent certain technical measures *cough*), you use it to test sneek's latency itself. <drakonis>is there any mailing list email listing features new to 1.3.0? <roptat>how much should a translation be at before we include it in guix, for the manual/cookbook? <roptat>I think I would add new languages at any percent for guix and packages, but should we start advertising a translated manual when it's at 3%? <roptat>or should we wait for contributors to ask for inclusion? <nckx>Just to give you an idea: I thought you were talking about where in the 80-90% range was OK. <sneek>Welcome back nckx, you have 1 message! <sneek>nckx, dsmith says: Thanks for the heads up regarding the bot. *nckx thanked them for fixing it. <roptat>nckx, the Russian translation is at 25% <nckx>Self-correction: I think adding them at 1% is fine, just not implying anywhere we have a translated manual until it's very close to complete. <nckx>I don't know if info does that? I don't use translations myself. <nckx>Meh, it's not really that important I guess. <nij>nckx, xkcn - thanks for helping out! and sorry for the delay of my response. <roptat>nckx, well, we advertise them in the manual/cookbook directly, and on the website by listing available languages <roptat>it would be available as "info guix.ko" for the Korean manual for instance <nij>The current issue I'm having is mainly "Settings schema 'org.freedesktop.IBus.Chewing' is not installed". I am at the test phase, passing 40%. The log file (the last 168 lines) is here: https://bpa.st/AOQA <nij>I figure this won't be the last issue I can't get pass though.. so I'm questioning perhaps I need to get more general knowledge by reading more for example. <nij>I also wonder if I should start packaging softwares with toolchains I'm more familiar with (elisp, common-lisp for example), instead of c, gnu which I have never had experience with. <roptat>nckx, alright, I'll add them all, but we're not advertising them until they reach a good percentage, sounds good <nckx>roptat: If we can omit languages from those lists but still ship them, that has my vote. But no idea if it's possible. You're the locale master. <roptat>I mean, we would build all those manuals/cookbooks that have like 23 strings translated <nckx>It doesn't sound expenside though. <nckx>nij: That's fine, I've actually been extremely occupied. <roptat>but we wouldn't have a link to them (or generate them) on the website, and we wouldn't link to them from the English (and other languages) manual <roptat>so they would still be available as info manuals for users <nckx>That to me sounds optimal. <nij>nckx - no worries - I actually don't care too much if I can successfully packaged it quickly - I just want to learn more guix. So I can take my time xD <nij>Do you think I should start reading how to modify phases? By reading the PKGBUILD file in the arch repo, it seems that they are calling cmake with different arguments. <nij>I haven't learned how to do that in guix. <nckx>nij: Did you try setting #:tests? #f at all, if you saw my PM? It's not acceptable for the final patch, of course, but it can help if you're stuck. For morale, but also to see whether running the result (a) works - great, almost done (b) gives a more informative/different error. <nij>Uh, I didn't see you're PM. Lemme see if I can see that in my local backups. <nckx>nij: I don't think any of those are needed, and Guix should set the ones that are by default anyway. <nckx>Not that it was P in nature. <nckx>nij: Now that I have my machine back, could you share your current state? <nij>I'm trying with tests? #f now :) <nij>Yeah, keep in mind that I might have to leave soon (in 10 min)? And come back a few hours later. <nckx>I just want to try a few things so that's fine. <nij>That's my current definition. <nij>OHhhh ~ after setting test to #f, I got a new error - which is not surprising <nij> file cannot create directory: /usr/libexec. Maybe need administrative <nij>I don't think setting "-DLIBEXEC_DIR='/usr/libexec'" in guix system makes sense to me <nckx>It doesn't. You can add #:configure-flags (list (string-append "-DLIBEXEC_DIR=" (assoc-ref %outputs "out") "/libexec")) to fix that. <nckx>I forgot whether you had other configure-flags. Add it if so. <nckx>Just replace all of '("." "-DLIBEXEC_DIR='/usr/libexec'") with (list ...) above. <nckx>I'm not convinced about "." unless you know something I don't? <nij>successfully built /gnu/store/s01qn7cq38x1lk112hq9w3236yqs1824-ibus-chewing-1.6.1.drv <nij>now lemme take tests? #f away *nij 's heart delays a beat <nckx>It will fail again, but didn't that feel good? 😛 <nij>(Btw, some friends tell me that after they grown up things aren't as excited as when they are young, and they become more depressive.) <nij>(I should just tell them to play with guix before they kill themselves xD) <nckx>nij: ‘instead of’, you mean ‘instead of’! <nckx>Otherwise we'll be blamed. <nij>lol that's just a joke <nij>i think my friends are depressed because they don't get enough excitement.. but to get that one has to endure some pain which i enjoy <nij>taking the #test f away does make the error come back <nckx>nij: Does $(guix builf -f FILE)/libexec/ibus-setup-chewing work for you? <nckx>I don't have ibus set up on this machine. <nckx>I don't know if the 2 binaries in libexec are safe to wrap (=replace with a wrapper shell script that sets certain variables and might fix the glib error), or whether ibus expects them to be ELF. <nij>nckx i don't understand what that is <nij>should I paste that in my terminal? <nckx>Yes, substituting FILE for the version that built (so with #:tests? #f). <nij>Oh lemme build it again. <nckx>Er, modulo typo builf → build of course. <roptat>nckx, there's an issue with nl.po (guix domain): nl.po:1481: format specifications in 'msgstr[0]' are not a subset of those in 'msgid_plural' <roptat>nckx, that line says "Je installatie van Guix is één dag oud.\n" <nckx>Any chance you could quickly map that to an actual string? <roptat>it should contain a ~a (that would be the number, so instead of één I suppose?) <roptat>English is "Your Guix installation is ~a day old." <nij>$ /gnu/store/589zzsf94qihvz5dnjjrzycg9v2iqdrk-ibus-chewing-1.6.1/libexec/ibus-setup-chewing <nij>(ibus-setup-chewing:6157): GLib-GIO-ERROR **: 19:39:41.012: Settings schema 'org.freedesktop.IBus.Chewing' is not installed <nckx>roptat: I see what happened, they didn't -- oh. Yes. So that. <nij>It's exactly the same error I got in the test phase! <roptat>where ~a is singular (which is 1 in Ennglish, but could be 0 or 1 in French for instance) <nckx>I hope it was a one-off. <nij>In the official INSTALL guide, there was a line asking me to `make install_schemas`. However, there's no Makefile in the repo.. in fact, Makefile is gitognored. <nij>So I don't really know what to do. <roptat>now I have similar issues with Portugues and Russian translations <nij>Building! I might have to leave at any moment. Finger crossed!! *raghavgururajan tickles nckx and runs away <nij>$ /gnu/store/dzzpn7rxsji8b2qsna3563gfi81jwqcz-ibus-chewing-1.6.1/libexec/ibus-setup-chewing <nij>(ibus-setup-chewing:8334): GLib-GIO-ERROR **: 19:54:03.971: Settings schema 'org.freedesktop.IBus.Chewing' is not installed <nij>What a weird and stubborn error! <nij>I did put in inputs: <nij> ("gsettings-desktop-schemas" ,gsettings-desktop-schemas) <nckx>nij: Yeah, but try installing it. <nij>On my machine, you mean, by `guix install -i gsettings-desktop-schemas`? <nckx>nij: Or move ("gsettings-desktop-schemas" ,g...) to a new propagated-inputs field. <raghavgururajan>nij: Try moving to propagated-inputs or add dconf to propagated-inputs. <nij>Trying propagated-inputs <raghavgururajan>nckx: Yo! The html I was trying earlier. Damn! After getting used to scheme, I unable to withstand <> and {}. <nckx>nij: That has roughly the same effect as ‘guix install gsettings-desktop-schemas’ would have had, by the way. <nckx>raghavgururajan: I feel your pain. <nckx>Very minimal, tobias.rg approves. *nckx not so minimal anymore, I'm not very happy with the current page. <nij>I moved gsettings-desktop-schemas to propagated-inputs (twaeking the file from nckx).. built, and run $(..), and still get <nij>$ /gnu/store/2ckr2scznbic0w5z0yp06nbn89jhmg1a-ibus-chewing-1.6.1/libexec/ibus-setup-chewing <nij>(ibus-setup-chewing:9782): GLib-GIO-ERROR **: 20:00:08.141: Settings schema 'org.freedesktop.IBus.Chewing' is not installed <nij>trying with dconf now (building..) <nij>With ("dconf" ,dconf).. built, and ran $(..). Same error. <nij>Ergggggh! It's appearing to be my first phd project XDD <nij>Hopefully this error won't become my nightmare. <nckx>raghavgururajan is our resident gnomologist. <nckx>Since I don't in all honesty enjoy GNOME errors (and this is a GNOME error), I'll take advantage of their presence to wish you good luck and go AFK before Raghav can protest. *raghavgururajan was about to doze-off <nij>(i had had to leave.. thanks for all your help. i will try afterward.) <nij>thank you, tahnk you. <roptat>how can I compute the derivations to test guix pull, before I send my commits? <apteryx>roptat: do you mean 'make as-derivation'? I don't know what it is for exactly, but perhaps this? <roptat>ok, I'll push these commits tomorrow, after I check make as-derivation <roptat>at least, "make" works, so the manual translations should not be too broken <nij>raghavgururajan: tried your patch.. didn't work on the nose <nij>It says `glib-or-gtk:%standard-phases` isn't bound.. so I take glib-or-gtk: away. Still didn't work though. <nij>I did put #:use-module (guix build glib-or-gtk-build-system) #:prefix glib-or-gtk:)) under define-module, btw. <nij>----- Anyway, I will leave this little project for a while. No genuinely new idea for now. <nij>Any common-lisp folks here? I'm curious how you manage the cl packages (or called systems in cl community) obtained from the guix official channel? <nij>Either you use asdf or quickload.. you have to manage to tune them so they know where to search within /gnu/store. <nij>I haven't yet found an efficient way for them to do that. There must be some black magic, but I failed to find much info lying in the intersection of guix and common-lisp ;) <Noclip>Could someone please update glances? <Noclip>Mhh, actually 3.1.6 (currently in guix) is marked as the latest release on the glances github page. But 3.1.6.1 and 3.1.6.2 got released shortly after, they are however not marked as latest release. <Noclip>But every time I close glances it complains about not being the latest version ... <brendyyn>Noclip: sounds like a bug. packages shouldn't be checking if they are the latest version <sneek>Welcome back brendyyn, you have 2 messages! <sneek>brendyyn, leoprikler says: the hard limit seems to be (expt 2 (expt 2 28)) and likely has to do with the amount of continuous memory you'd need to allocate for that <sneek>brendyyn, rekado_ says: For CRAN / Bioconductor packages what you describe is already reality. I can’t remember the last time I wrote an R package definition by hand. <Noclip>brendyyn: glances always does that, no matter how it was installed. And it always tells you to update with pip even if it isn't installed with pip. <brendyyn>Noclip: we should ideally patch that out <brendyyn>looks like it actually has a fix from 2019. maybe it doesnt work <brendyyn>Noclip: do you have a config file for glances? <Noclip>Unless any of those files is a config file, no. <Noclip>But .cache and .log doesn't sound like config files to me. <Noclip>Mhh, there are a lot of glances files outside of my home directory. Maybe one of them is a config file causing the behaviour. <Noclip>Ohh and glances is also installed through apt. I forgot about that. I'm however using the version from guix as it's listed before the apt version in $PATH. <Noclip>I'm definitely running the guix one as the apt one is outdated since a long time. <Noclip>glances -V prints out the guix version. <Noclip>Also 'which glances' is pointing to my guix profile. <Noclip>'$ guix environment -CN --no-cwd --ad-hoc glances -- glances' <Noclip>If I could get it to work I could run glances inside a clean environment but I don't know how to get it to work. <brendyyn>read the error message. the answer is right there <Noclip>Thanks. Now it's working and it's not complaining about the version after closing it. <brendyyn>did you look in all of those glance files? <brendyyn>you can also use strace to look at what files its reading <Noclip>So it seems to be caused by a config file. <Noclip>"You can put your own glances.conf file in the following locations: <Noclip>Linux, SunOS: ~/.config/glances/glances.conf, /etc/glances/glances.conf" <Noclip>The last file exists on my system. <Noclip>Weird, this seems to have no effect: <Noclip>"guix environment -CN -E TERM --no-cwd --expose=/etc/glances/glances.conf --ad-hoc glances -- glances" <Noclip>It just behaves as if 'expose' had not been specified so maybe the config file is not the reason?! <brendyyn>i wonder if networking is actually working <Noclip>Even more weird this does exactly nothing, it doesn't start glances but it also doesn't print any error message: <Noclip>"guix environment -CN -E TERM --no-cwd --expose=/etc --ad-hoc glances -- glances" <Noclip>"guix environment -CN -E TERM --no-cwd --expose=/etc/glances/glances.conf --ad-hoc glances curl -- curl ifconfig.me; echo" <Noclip>This prints out my current ip adress as expected so the network seems to be working. <pat>I'm getting a kernel panic when trying to boot the 1.2 vm image. Error is: not syncing: VFS: Unable to mount root fs on unknown-block. Any help would be appreciated <derivates>Hello people, just starting to get into Guix, Ive installed several packages thru config.scm but particularly fonts arent showing up in fc-list, any ideas? <derivates>on the other hand, when I got them via guix install they worked fine. <g_bor[m]>derivates: have you tried updating you fontconfig cache? <derivates>I did fc-cache -v only, is that the same approach? <derivates>also, is that the correct way to setup fonts? thru packages? should be right? asking because on Nix there's quite a different approach <Shmiggles>Q: using `guix environment --container`, how do I expose an IP port from the container to the host without sharing the entire network namespace? <rekado>derivates: installing fonts through packages is correct. You can also install fonts manually (by dropping them in ~/.fonts). <leoprikler>Which packages are we talking about? The packages field of operating-system or the user profile? <leoprikler>In Guix, we typically prefer the latter. I don't know how well the former is supported. ***sneek_ is now known as sneek
<pat>g_bor: you're right. I forgot the -m. It boots fine with 2G. Thanks <brendyyn>yep the default doesnt have enough ram to even load GDM <efraim>on core-updates we use llvm 7,8,9,10,11 during the rust bootstrap process. <brendyyn>there is a gcc front end being developed. any plans to use that in the future? <efraim>when it's available we'll probably try it out <leoprikler>Hopefully rust-gcc does away with the need for cargo as well. <brendyyn>I'm having trouble finding the true source for polkit-gnome. the source is just tarball but i have no idea where the original repo is <brendyyn>i say that then i just found it on gitlab.gnome.org <roptat>do we still plan to release today? <nckx>brendyyn: If that file were copyrightable I'd say you had a problem but I don't think it is. <civodul>roptat: i don't think so; there's still much testing and stuff to be done <roptat>alright, that means we have more time for translation :) <nckx>brendyyn: And origin sounds good, but be sure to replace /trunk/ with something fixed. <nckx>The nl translation should be finished today, I said optimistically. :) <rekado>so I just upgraded the daemon on a shared cluster installation and I’m not able to download substitutes (reliably or at all?) <rekado>the download stalls and eventually I get this error: “guix substitute: error: TLS error in procedure 'read_from_session_record_port': Error decoding the received TLS packet.” <rekado>I should note that “guix download” works exceptionally well on the same substitute. <rekado>for smaller substitutes (like python-pandas, or r-bookdown) the download passes, but it is very slow. <raghavgururajan>sneek, later tell nij: I think you implemented it wrong. You just have to add #:use-module (guix build glib-or-gtk-build-system) at the top. For reference, you can look at telegram-desktop package. :) <roptat>just pushed a bunch of commits to update locales <roptat>I ran "make as-derivation" to check, so it should work. The commit adds new languages for the manual and cookbook, so I wanted to make sure nothing breaks :) <nij>raghavgururajan: i just woke up and have stayed online <roptat>if you pull these changes (on master, not sure how I should push them to the release branch?), you'll have to run ./bootstrap again <nij>Btw, any common lisper here? <nij>I apologize if I'm missing something trivial. This is my second package. <nij>Thanks raghavgururajan :) <nckx>So sneek's come back as a liar? <nckx>sneek: later tell nckx: no botsnacks for me. <sneek>Welcome back nckx, you have 1 message! <sneek>nckx, nckx says: no botsnacks for me. <smoothdev>running guix under vmware, I somehow encounter a freeze of the machine once it gets into "sleep" mode (runs under gnome desktop environment), any suggestion to work around that issue? <sneek>Welcome back smoothdev, you have 1 message! <smoothdev>the symptom is the machine only shows black screen with white underscore cursor at the top left, and accepts no input <smoothdev>I'll give a shot at qemu and exporting the vm image, as I gather vmware host is probably not the best approach <nij>Hello! I'm unsure about the following. Could someone help out? I'm define-public a package, and I have (source (origin .. (uri (git-reference (comment XYZ))))). I notice that altering XYZ from commit to another different commit DOES NOT alter the hash of the whole package -- so when I build with the second commit, it does not rebuild! That contradicts to my understanding that if the commit (the source) is different, then the package <nij>must be rebuilt. Could someone clarify what's going on? Thanks a lot! <nij>raghavgururajan: no code for module (guix build glib-or-gtk) <nij>OK I see.. I filled in junk to XYZ, and it still compiles. That means guix does not even look at that list.. <terpri>nij, did you update the sha256 field of the origin? that's what causes guix to rebuild or not, not the git commit <civodul>peut-être qu'on peut chercher dans d'autres traductions (Debian, LFS, etc.) <nij>raghavgururajan: -- guix build: error: file 'unquote-splicing/%cmake-build-system-modules.scm' could not be found in these directories: /gnu/store/..... <roptat>ça me plait pas trop, parce qu'avec un verbe ça devient plus dur à exprimer <civodul>« faire un montage lié » (le problème se pose avec tous les verbes composites je pense ?) <roptat>j'ai "monter en double" / "montage double" sur LFS <roptat>donc... "montage dupliqué" / "dupliquer un montage" ? <civodul>c'est juste sémantiquement, mais c'est un peu éloigné de l'original <civodul>dans le Hurd on parle de « liens fermes » (firmlinks) pour quelque chose qui ressemble aux bind mounts <nij>sure, i will be here, thanks for your help :D <nij>Hello #guix, any common-lispers here :)? *rekado appreciates the dash <civodul>nij: i suspect the common lispers are out for a walk, but you'll find'em on the mailing list <civodul>in other news, i posted a patch to remove "guix import nix" <roptat>reached 80% for the cookbook, 129 strings left :) <roptat>btw, I commited it to the guix repo, but I'm not sure how we can start rendering it on the website? <civodul>roptat: it'll just happen within an hour, no? <civodul>there are cron jobs building the manuals and cookbooks <rekado>nij: ambrevar is a common-lisper (contributes to nyxt), but I haven’t seen them on IRC recently <rekado>nij: IIRC katco is also knowledgeable about CL stuff <roptat>ah, I need to update doc/build.scm too <roptat>we also have other languages, but they're under 10% (like single-digit number of translated strings) <roptat>I added them to guix, but not sure if we should render them on the website or advertise them yet in the manual <roptat>(I left out Mongolian and Portuguese because they have exactly 0 strings translated) <roptat>also just noticed it's Chinese (Simplified) just like zh_CN, but it's zh_Hans <roptat>and for some reason I commited it with Chinese (Traditional) in my commit message (though it doesn't change anything) <apteryx>civodul: ah, I think I got the logic in the update-NEWS script; the regexp used is strict :-) <roptat>I added Italian, Korean, Persian, Portuguese and Slovak that we didn't have before <apteryx>2005 new packages and 3092 packages updates <Noisytoot>civodul, What is the reason for removing "guix import nix"? <yoctocell>roptat: Any way to help out with the translations? <rekado>then you’ll have to take our word for it, or use “guix pull” to get an older version and observe the failures with your own eyes. <apteryx>civodul: is it OK to push a commit for the data file of version-1.3.0 already to the guix-maintenance repo? <roptat>you need an account, then you can start translating right away! <nij>raghavgururajan: :D ? <roptat>civodul, so what should I do? Add only the French cookbook, add some of them above a threashold, or all of them? <brown121407>Hi! Is the fact that `guix system reconfigure` doesn't by default reuse the current system definition when not given an input file a design choice? <nij>Hello #guix! I wonder how you setup asdf properly for #'asdf:load-system to load common-lisp packages you got from the guix channel? <nij>raghavgururajan: I can't see what you posted. <apteryx>I feel like 'make release' is supposed to take care of it, but somehow it was complaining about something like 'No rule to make target ...guix-manual.pot' <nij>raghavgururajan: I tried to `git patch that-diff-file`, but I'm not sure what to do next. Thanks for your help anyway! <mdevos>sneek: later tell raghavgururajan: I've an incomplete start on meson cross-compilation if you're interested <mdevos>sneek: later tell raghavgururajan: emphasis on incomplete. <roptat>apteryx, download-po doesn't build the pot files though <raghavgururajan>nij: You have to apply it on ibus.scm, bootstrap and build the package. <sneek>Welcome back raghavgururajan, you have 2 messages! <sneek>raghavgururajan, mdevos says: I've an incomplete start on meson cross-compilation if you're interested <sneek>raghavgururajan, mdevos says: emphasis on incomplete. <apteryx>roptat: I'll update the release.org process; it seems ./bootstrap is what was needed (along a re-run of configure). <raghavgururajan>mdevos: I see. Glad to know you are working on it. But my plate is kinda full atm. <nij>raghavgururajan: Hmm.. I'm working on ibus-chewing.scm, not ibus.scm. Do you mean the former? <nij>Or do you mean I really have to change ibus in my profile? <nij>Back to the main crux, the error is "Settings schema 'org.freedesktop.IBus.Chewing' is not installed" <apteryx>hm, so ./bootstrap along is not enough to make 'make release' happy: make[3]: *** No rule to make target 'po/doc/guix-manual.pot', needed by 'distdir-am'. Stop. <raghavgururajan>nij: For testing, I have introduced your package-definition in ibus.scm, instead of creating new file ibus-chewing.scm. <raghavgururajan>I was under the impression that you were talking about run-time errors. That's nckx and I were suggesting to propagate some inputs. <raghavgururajan>If it's during tests, it means tests are supposed to be run after install. Looks like the tests programs doesn't have access to [output]/share/glib-2.0/schemas <nckx>I enter by sheer coincidence at this very point. <nckx>raghavgururajan: It's both. The test tries to run the resulting binaries (in libexec IIRC?), but they also fail when invoked after installation. <apteryx>actually, I see that 'make release' depend on the 'dist-with-updated-version' target, which runs bootstrap... <apteryx>so running bootstrap manually shouldn't be required <nckx>So if you wrap, you have to make sure the test suite uses the wrapped binaries, and if conversely you can't just set up the test environment and expect the output to work later. <nckx>s/if conversely/conversely/ <raghavgururajan>Ah, after installation I get "(ibus-engine-chewing:3699): ibus-chewing-ERROR **: 11:05:44.948: Cannot connect to IBus!" *raghavgururajan has an idea <nckx>And if you set up IBus you'll get the same gsettings error as the tests. *nckx puts on their string and gaat nog wat vertalen. <nckx>Not here, but maybe if you run GNOME. *nckx kicks IBus in the pit. <brendyyn>nij: There should be an .xml with that in the name somewhere. Have you found it? *raghavgururajan is running SLiM+dwm+st <nckx>mdevos: Why process → process [sic] and not proces? <nckx>Yes, I'm going to blame you for every single translation that isn't mine because I'z lazyboy. <mdevos>nckx: daar had ik een spelfout gemaakt <nckx>Thought you'd considered proces & rejected it. <brendyyn>nij: there is a profile hook to genrate the glib schemas from the profile. so it needs to be in a package thats in the profile. <mdevos>nckx: about that string with the missing ~a. ‘Je installatie van Guix is één dag oud.\n" (format #f "Je [...] één dag oud.\n" 1) werkt <nckx>mdevos: 👍 for ‘ontkieming’. <mdevos>maar je krijgt wel een waarschuwing als je dat uitvoerd helaas <nckx>I don't think it's worth the style points of using ‘één’ over ‘1’ if it causes warnings. WDYT? <nckx>I ‘fixed’ it, though, right? Just so I don't forget. *nckx binnenkort heet 't gewoon dement. <mdevos>als die waarschuwing in een latere versie verdwijnt, kunnen we dit heroverwegen <apteryx>are translation files supposed to be committed along the code in Guix? Or fetched in an ad-hoc way and added to the tarball at release time? <apteryx>seems it they should be committed, looking at git <nckx>Merged in occasionally, and rushed in before release. <apteryx>I see. And to update the translation, one has to run 'make download-po', then 'make doc-po-update' ? <nckx>The difference is subtle but leads to questions like: what's the exact CET deadline for translations, roptat? <nckx>apteryx: Something like that, I've never done it. <nckx>Things might've changed with Weblate, or might not. <apteryx>The file 'po/doc/guix-manual.pot' is not under version control yet it appears in the release archive <nckx>mdevos: afvalverzamelaar makes me smile and think of my grandfather. -ophaler? <mdevos>verzamelaar: het afval wordt verzameld in één plaats <mdevos>ophaler: het afval daardwerkelijk weggegooid, niet gewoon verplaatst <apteryx>perhaps the 'make release' target should take care of it '(pull translations, run the update target, commit it) *apteryx starts by documenting it <nckx>But seriously: stroomopwaards? Bovenstrooms? <mdevos>ik had er bovenstrooms van gemaakt <nckx>Als de software niet naar de berg komt. <mdevos>ik heb ‘kijk of er bovenstroomse uitgaves bestaan’ of zoiets gedaan in "guix refresh" <nckx>OK, I wrote exactly the same thing elsewhere. <nckx>Some package transformation option. <nckx>Toolchain = gereedschapsgordel, or do I need to step back from the page again. <nckx>Really it's more of an assembly line. <iis>Hello, I see nextcloud client 3.1.3 in the guix packaqes, how about nextcloud server on guix? It is doable? <apteryx>civodul: do you remember why we do not want to include the .pot files? They are part of the release, so I find it odd that they aren't committed along the other translation files. <leoprikler>php would probably be doable, but I worry about the js side <morgansmith>what's the problem with all the web dev tools again? Was it something like node isn't bootstrapable or something like that? I remeber being frustrated trying to package an electron app <iis>leoprikler: and what about owncloud server on guix? there is an owncloud client package. The same javascript thing? <mdevos>Question: wrap-script is used for wrapping scripts. By default (which "guile") as interpreter. But that's incorrect when cross-compiling. I'd prefer for wrap-script to automatically do the right thing, which is using a guile of the target. Problem is, wrap-script has no way of guessing where the target guile is located. Proposal: introduce a PATH_FOR_TARGET environment variable, which is like PATH, but contains binaries for the <jgart[m]>The reason I ask is because GNU MediaGoblin is trying to be packaged for guix and it also has some bundled jquery. How much javascript do we need to remove in order for it to be accepted upstream? Or phrased differently, what javascript is ok and what javascript is not ok to include? <leoprikler>mdevos: I think the proper solution would be to evaluate the search path in target without binding it to a variable <cbaines>jgart[m], the line against bundling blobs of JavaScript has already been crossed, so providing it's just a few files, it won't we off lower standard than other packages <nckx>raghavgururajan: Excellent! <mdevos>leoprikler: sorry, I didn't understand any of that <leoprikler>I recently encountered a similar problem as a developer writing a guix.scm for my own package, and I think as a solution to this and problems like it I'd prefer a cleaner separation between inputs and native-inputs. <jgart[m]>cbaines: sorry I didn't understand the last sentence after the second comma. It looks like it got munged <leoprikler>mdevos: inside guix, you have a search-path specification for stuff like PATH <cbaines>jgart[m], ah, yeah, it won't be of a lower standard than other things already packaged <leoprikler>My idea is to iterate over inputs ad-hoc with this search-path specification in mind. <jgart[m]>fosspay has less bundled javascript than cuirass <leoprikler>(because you would otherwise already need to iterate over this in shell code anyway) <mdevos>leoprikler: I'm confused by your last two posts, what you're trying to do there. <mdevos>What I'm trying to do, is changing wrap-script such that all existing package definitions are automatically fixed <mdevos>(at least w.r.t. this particular cross-compilation problem) <leoprikler>okay, so you have a set of inputs, e.g. ("coreutils" . "/gnu/store/...") ("emacs . "/gnu/store/...") and so on <leoprikler>And you have a search path PATH which says "string-append /bin", bla bla <mdevos>yes /gnu/store/[...]/bin:/gnu/store/[other-...]/bin <leoprikler>So instead of using (which "foo"), you do (which "foo" inputs) <mdevos>leoprikler: I just submitted a patch for that! <leoprikler>where (which "foo" alist) searches for /bin/foo or /sbin/foo in the cdr's of alist <leoprikler>Okay, so we had the same idea and I just phrased it differently :) <mdevos>so the idea is to add a "inputs" argument to wrap-script and adjust all callers? <morgansmith>I noticed an odd thing. We have the package "tidy" which is just our "tidy-html" package except the version is from 2009. It seems there are like 267 packages that depend on tidy but only 10 depend on tidy-html. Is this intention or are people just accidentally using the wrong tidy? <mdevos>number of uses of wrap-script on core-updates: "git grep -F wrap-script gnu guix | wc -l" <leoprikler>mdevos: I think with wrap-script being syntax, you could probably expand native-inputs in place if they're kept somewhere <mdevos>wait, wrap-script is a procedure for me <mdevos>are we both on core-updates, guix/build/utils.scm? <leoprikler>sorry, I'm doing this out of my brain without looking at the code ^^" <mdevos>btw, I think simply adjusting all callers should be feasible. Number of callers: 26 <raghavgururajan>nij: For testing, [1] `./pre-inst-env guix build ibus-chewing` and copy the resulting store path. [2] `./pre-inst-env guix environment --pure --ad-hoc ibus ibus-chewing`. [3] `cd [ibus-chewing-store-path]/libexec`. [4] `ibus-daemon --daemonize`. [5] `./ibus-setup-chewing`. [6] `./ibus-engine-chewing`. <vincele>lfam: Thanks for your hint about the `%strict-tokenizer?` problem, that put me on the right path <leoprikler>mdevos: still, adjusting the callers more or less voids the optionality of the guile argument <leoprikler>(because you need to supply native-inputs always) <mdevos>leoprikler: don't you mean: supply native-inputs always? <mdevos>native-inputs = architecture + OS of system you are performing the build on <civodul>apteryx: .pot files are automatically-extracted templates, they're not "source", and thus conventionally not checked in <mdevos>inputs (when cross-compiling) = architecture + OS of system the end result must be able to run on <nckx>roptat: I'd rather not specify a separate address for ‘translation bugs’ -- I'm not in any team, and would rather see them reported to bug-guix. WDYT? <mdevos>leoprikler: the number of callers is actually smaller. leoprikler: maybe, by using an unhygienic macro <mdevos>Some packages have a 'wrap-scripts phase that really calls wra-program, not wrap-scripts <leoprikler>doesn't wrap-program suffer from a similar issue, though? <mdevos>and you'll see comments like (("guile" ,guile)) ; for wrap-script <mdevos>I can pun that for later for now (-; <vincele>mothacehe: I've setup a local cuirass, which is working, and now I'm on to add remote-worker nodes, but reading the doc (or your blog), I'm not sure how to do that declaratively (f.e. as a service in `operating-system`), any hint ? <janas>Is it possible to add a guix channel to the guix system configuration so that it is available to the system profile? <mdevos>janas: I don't see why not. You're using "lookup-inferior-package", and the "packages" field of "operating-system", right? <roptat>nckx, if you think that's the best contact point for Dutch, sure <roptat>I'm not sure what you're refering to though <roptat>but maybe some translators are not part of guix-devel <janas>mdevos: thanks, I didn't know about lookup-inferior-package, that looks like it's what i need to use <roptat>nckx, "the following package would be removed"? <nckx>Yay for individualised URLs. <nckx>Signalez toute erreur de traduction à : traduc@traduc.org. etc. <nckx>translation-team-de@lists.sourceforge.net. <roptat>oh right, you can put whatever feels right for the Dutch translators <nckx>I'm not a member of any such team, dunno about mdevos, others. <roptat>the idea is that if you disappear, hopefully we can still contact other Dutch translators <mdevos>maybe we could mention the #guix channel? <mdevos>since when do I have an e-mail account at tobias.rg <nckx>roptat: I didn't mean guix-devel btw, but bug-guix. <nckx>Noisytoot is onto me. Er, us. <nckx>mdevos: Everyone has an e-mail account at tobias.rg, they just don't know it. <mdevos>Everyone has an e-mail account, but does everyone know their password? <vincele>mothacehe: thanks a lot. I always forgot that there is a devel doc with the bleeding edge stuff... <nckx>Noisytoot: Yours is also mdevos@tobias.rg <nckx>I didn't say you all had a different one. <mothacehe>vincele: np, don't hesitate to send an email if you have troubles setting those workers up. This stuff isn't really mature yet. <nij>raghavgururajan: Thanks for your help! I've been away and now i'm back. <nij>Is it possible to separate the code to an independent ibus-chewing.scm, just for now? I'm not sure if I understand how to test your diff file. <nij>(even after reading your instruction: <nij> >>> <raghavgururajan> nij: For testing, [1] `./pre-inst-env guix build ibus-chewing` and copy the resulting store path. [2] `./pre-inst-env guix environment --pure --ad-hoc ibus ibus-chewing`. [3] `cd [ibus-chewing-store-path]/libexec`. [4] `ibus-daemon --daemonize`. [5] `./ibus-setup-chewing`. [6] `./ibus-engine-chewing`. <mdevos>leoprikler: correction, I only needed to adjust 9 callers <Noisytoot>nckx, A shared email account with a public password will end up sending spam, and being blocked by many email servers <nij>raghavgururajan: AH! I manually move codes from the diff you gave me to a separate file "ibus-chewing.scm", and it compiles successfully!! <raghavgururajan>nij: [1] `git clone https://git.savannah.gnu.org/git/guix.git` [2] `cd guix` [3] `guix environment guix --pure --ad-hoc guix` [4] `./bootstrap && ./configure --localstatedir=/var && make` [5] `exit` [6] `git apply nij.diff` [7] Continue with the 'For testing' message I sent earlier. <Noisytoot>raghavgururajan, You can use make -j $(nproc) to use all CPUs/cores <Noisytoot>And if you're on guix system, configure with --sysconfdir=/etc/ <nckx>Propagated-inputs worden ‘doorgegeven’. <nij>hold on.. I compiled it successfully, but haven't figured out how to use it <mdevos>nckx: ik had er ‘herkauwde invoer’ van gemaakt <nij>lemme re-login and see if it works <nckx>mdevos: It's not that I don't like it, but I don't think it explains anything beyond ‘ew’. *Noisytoot gets lots of warnings with guix import nix <nckx>If it were a synonym for ‘regurgitated’ I'd agree but it's just ‘re-chewed’. <mdevos>als in ‘corrupt input while restoring archive from ~s~%’ <nckx>Oh, we were about to step on each others' toes badly. <nckx>I was going to go with ‘terugplaatsen’. <nckx>Something in that direction anyway. *nckx sets &offset=1100 then. <mdevos>‘beschadigde invoer tijdens het terugplaatsen van het archief van ~s%’? <nckx>Double ‘van’ isn't great but oh well. <nckx>Depends on the nature of ~s. If a file, yes. <mdevos>een URL denk ik. Maar URL's zijn gewoon bestanden op afstand, nee? <nij>nckx: good news, raghavgururajan's build for ibus-chewing does compile. <nij>Thank you both so much for helping me along the way, nckx raghavgururajan :-) <nij>Now I'll try to figure out why ibus doesn't see the compiled&installed ibus-chewing. <Noisytoot>rekado, guix import nix just prints out some warnings and freezes <nij>I cannot push that to guix though, as i haven't got it working with ibus :) But that's a major leap. <nij>raghavgururajan: in a few words, could you share how you deal with the error ";; Settings schema 'org.freedesktop.IBus.Chewing' is not installed" <raghavgururajan>ibus-chewing was using a deprecated way of referring to its own schemas. So I wrapped it by extending XDG_DATA_DIRS. <apteryx>civodul: OK! In this case I'll add the doc-po-update target as a dependency of release <raghavgururajan>the error happens during tests and and during run-time. The above explanation is for run-time. <apteryx>and also ignore the *.pot files in .gitignore <raghavgururajan>During tests, the test binaries looked for schemas, which were not compiled until 'glib-or-gtk-compile-schemas phase. So I moved the 'check phase to the end and modified env-var XDG_DATA_DIRS to include files in /share of output. <raghavgururajan>nij: Btw, ibus is working with ibus-chewing. `ibus list-engine` shows chewing and `ibus engine chewing` set the engine to chewing. <roptat>looks like something's wrong with doc/build.scm <raghavgururajan>nij: Glad that you are working on ibus-chewing. I packaged libchewing in the hope to bring guix to more chinese users, but couldn't get to the ibus part of it. So thanks so much. <lfam>roptat: The web-based manuals are based on doc/build.scm, and it looks like the devel manual is still building <lfam>I did find this thing doc/build.scm kind of 'fiddly'. Maybe there is something wrong with your environment, or you need the latest version of a dependency <roptat>lfam, looks like it's working with -c1, but it's taking some time <lfam>Okay, my fingers are crossed! <roptat>mh, which derivation is it building now? <cbaines>lfam, by the way, I contacted SolidRun yesterday, and they said my order (one HoneyComb LX2) was delayed but is expected to ship in the first week of May <lfam>cbaines: I got the same message. It makes sense that production would have delays, especially since all of NXPs fabs were severely damaged in February <cbaines>lfam, yeah, right. I haven't looked at what other parts I'll need to get it operational, but hopefully they won't be as hard to come by. <lfam>I bought a "single shot" (slow version) macchiatobin off ebay yesterday <lfam>The accessories should still be widely available, if I understand correctly. <lfam>Maybe the RAM will be more expensive now, if your order did not include it <lfam>cbaines: Something that I'm wondering about is if *any* of the Honeycomb's NICs work with linux-libre <lfam>It would be nice if the 1 GbE copper NIC did. I don't expect the others to <apteryx>something seems wrong with the doc-update-po target <apteryx>it creates msgid ""\n"The string"... <nij>raghavgururajan: you and nckx did most of the work....... <nij>But hey, `ibus list-engine` doesn't give any chewing instance here on my machine. <nij>Once these are all done, I can write a tutorial for setting up ibus-rime and ibus-chewing to attract more Chinese user. <apteryx>eh, translate.fedoraproject.org doesn't like my various attempts: ERROR 429: Too Many Requests. *apteryx tries on a 2nd box <nij>raghavgururajan: I'm still very new to guix, and can be missing some trivial things.. <nij>I haven't followed the instruction you gave. Instead, I try to use the way I'm familiar. <roptat>lfam, so the manual and cookbook built fine locally, so I just hope it's the server being slow at building that <apteryx>Could someone try 'make doc-po-update' on the version-1.3.0 branch? Fails for me. Before or after 'make download-po' <apteryx>actually, no, that target passes, but 'make dist' fails <lfam>Let's monitor the situation <raghavgururajan>> nij: But hey, `ibus list-engine` doesn't give any chewing instance here on my machine. <raghavgururajan>rg@secondary ~/guix/rg-master [env]$ ibus list-engine | grep chewing <cyberTeX>I just installed GNU GUIX on my Toshiba Tecra A8. The initial part of the boot process proceeds successfully, but it encounters errors regarding GDM. Whether I login or not, the system reports "Cannot make/remove an entry for the specified session", and an ambiguous message about "no return value" from a daemon. <apteryx>cyberTeX: was this with the 1.2.0 installer? <nij>Hello #guix! I did the following and got an error. Is it a bug in guix? <nij>make[4]: Entering directory '/home/nij/guix/po/packages'. File vi.po does not exist. If you are a translator, you can create it through 'msginit'. make[4]: *** [Makefile:476: vi.po-create] Error 1 <nij>roptat: ha! yo hoy! what can i do now roptat? <derivates>(keyboard-layout "us" "altgr-intl" #:options '("caps:escape")) seems to be invalid <cyberTeX>apteryx: Yes, this was with the System Installer v1.2.0 for i686 architectures. <derivates>meanwhile (keyboard-layout (keyboard-layout ...)) works, why is this? <roptat>nij, just wait one or two minuse and pull, I'll fix that <nij>roptat: you have the freedom to change the official guix repo at will?! that's cool. <roptat>derivates, the outer keyboard-layout is the name of a field, which is part of the syntax of operating-system (and an xorg thing too) <roptat>the inner one is a function that returns a <keyboard-layout> object <roptat>if you have only one, it's understood as the name of the field, but then the rest is interpreted as its value, and a field can only have one value <derivates>alright, just odd because on the manual there is nothing like that shown <derivates>thanks man, just slowly trying to understand everything i love this system <roptat>mh... can you point to what was confusing in the manual? we could change that <derivates>you see, it's just (keyboard-layout ...) not (keyboard-layout (keyboard-layout ...)) <roptat>oh, have you seen the second example box below? <roptat>this is an example of the function itself <roptat>the second box is an example in context <roptat>mh, how can we make that clearer... <derivates>wouldn't be able to tell, but i understand that's something more related to guile right? <roptat>having two keyboard-layout would be technically incorrect in the first box... <apteryx>cyberTeX: OK; I'm not sure if i686 is very well tested. We're in the process of issuing a new release, it'd be useful if you could test a new image. Would you be interested in trying? <roptat>maybe we should just rename the function to not have the same name as the field, that would be less confusing <derivates>also i'm widly guessing #:options '("caps:escape") remaps caps -> escape, where can i consult this? <derivates>"See the share/X11/xkb directory of the xkeyboard-config package for a complete list of supported layouts, variants, and models." <derivates>"maybe we should just rename the function to not have the same name as the field" would that be possible? wouldn't that make major breakages? <derivates>man im so excited to setup my system with guix, once i get everything to work I am willing to package a lot of projects i used to use on arch <derivates>i'm really happy, hopefully i meet my expectations <nij>roptat: it's fixed. thanks :D <roptat>derivates, glad to see your enthusiasm :) <roptat>don't hesitate if you have questions <roptat>or just share your experience, sometimes it's hard to see obvious blockers when you're experienced, so it's always a good thing to hear what works and what doesn't from newcomers <cyberTeX>apteryx: I'm willing to try newer images, especially if they might address something that was untested in previous i686 images. Regarding architecture, this machine has an Intel Core 2 Duo T5500; I just looked up the product specification on Intel's website, which states that the processor does support the 64-bit instruction set. Should I instead u <derivates>yeah, right now i want to get rid of GDM and just boot to a TTY, and use ~/.xinitrc with startx command <cyberTeX>apteryx: This machine only has 2GB of RAM, which is why I chose the 32-bit image. I always get confused when needing to choose installation images for systems that have <4GB RAM and aren't Intel Core "i[[:digit:]]". <apteryx>cyberTeX: no the i686 image, just a recent one. Let me find a link. <apteryx>ah, we do not generate it it seems for the latest images <apteryx>I can ping you after I've managed to generate the first RC for what will become 1.3.0. <cyberTeX>rotpat: I read that you have high priveleges in the GNU GUIX infrastructure. While it's something that most GUIX can eek out, it's easy to forget when a system actually requires a non-x86_64 image. Could "3.3 USB Stick and DVD Installation" of _System Installation_ be modified to include a reminder that the architecture images are specific to the _ <cyberTeX>processor architecture_ and do not regard the amount of installed memory in the system. <apteryx>I'll upload it to the GNU ftp server <cyberTeX>roptat: I misspelled your nickname. See my message above, please. :) <cyberTeX>apteryx: Okay, I can try that. Are we sure I _should_ be using the i686 image? It boots and runs, but given the processor (Intel Core 2 Duo) is a 64-bit processor I should probably be using the x86_64 installation image, right? <apteryx>it'd probably give you better performance yes, at the price of a bit more RAM <roptat>cyberTeX, depends if we plan to take at least one more week to finish the release <roptat>we're in string freeze, which means it's too late for the next release, but we can update the text on master <apteryx>has someone got that: doc/contributing.de.texi:708: @pxref reference to nonexistent node `build-system' <apteryx>trying to build the guix.de.info manual <roptat>apteryx, did you run make download-po by any chance? there are some issues with the po from weblate that I fixed manually (and sent a comment to translators about) <roptat>if that's the case, just "git checkout po" :) <derivates>is there any reason to use supplementary-groups, instead of just using groups? <cyberTeX>roptat: I've only used `patch` or `diff` a couple times, and I struggled with that. I've also never made an account on Savannah or the GNU infrastructure sites. I can iterate over a reminder text, though; I've got a little bit of technical writing education, so it's mostly determining how to remind the audience, who generally understand this concep <cyberTeX>t, of something that can be easily forgotten because of disuse. :) <apteryx>(I did run it, perhaps 30 minutes ago) <cyberTeX>How should I go about submitting a patch, if that is the preferred method? I'll look for a _Contributing_ section in the Documentation, however. :) <roptat>cyberTeX, you don't need a savannah account to write a patch, but if that's too hard, just send the text you'd like to see and where (what it replaces) to bug-guix@gnu.org <roptat>cyberTeX, yeah "Contributing" in the manual :D <apteryx>roptat: by the way, I'm working on the version-1.3.0 branch in case that wasn't obvious <roptat>apteryx, tell me how I can help :) <apteryx>if you want, I can push what I've got here, and after you reproduce what I see, we can try finding the solution <roptat>cyberTeX, basically, clone the repo, change doc/guix.texi (or doc/contributing.texi) as you wish, "git add doc/guix.texi; git commit", write your commit message, save, then "git format-patch -1" and attach the file it created to a message you send to guix-patches@gnu.org <apteryx>there'll be the WIP commit at the top which will be used to document what's new; this is going to take some time to write, so help will be welcome <apteryx>roptat: ah but... the pre-push hook won't let me push while it doesn't build... hmm. Should I disable it for now? <roptat>did you pick my commits to master, or did you do something else with tarnslations? <apteryx>I won't be pushing anything to master so I guess it's safe for me to disable it why we straighten firm up 1.3.0 into something that builds. <cyberTeX>roptat: Thank you for that instruction; I did read _16.6 Submitting Patches_, but that is a nice stepped instruction. I'll make a note of this and see what I can contribute. <apteryx>(it doesn't build because I've committed the updated translations) <luis-felipe>So, next Guix version won't be 1.2.1 but 1.3.0, right? <apteryx>roptat: OK, I just pushed what I have here to version-1.3.0 <apteryx>if you try to build that branch, it should fail on attempting ot build the doc <apteryx>seems just an invalid reference, I'll see if I can fix it <cyberTeX>take a look at the packaging guidelines, but seeing that KDE is not an available desktop environment on GNU GUIX, does that forebode that Qt 5 is unavailable as well, or merely the KDE framework? This software is built with cmake and qmake, and requires Qt 5.9.5 or later for compilation and runtimes. I'd be happy to package it for GUIX and submit i <cyberTeX>t to the project. It's GPLv3 licensed, so there is no conflict of licensing. :) <derivates>I'm getting this odd error: guix system: error: font-adobe-source-han-sans:cn: unknown package <derivates>manual : guix install font-adobe-source-han-sans:cn <roptat>mh, it exists on my system, maybe your guix is not up to date? <roptat>apteryx, strangely enough I get an error with the pt_BR translation of guix <Noisytoot>cyberTeX, You can run Guix on a foreign distro <apteryx>roptat: I guess there's more than one issue to be fixed :-) <mdevos>cyberTex: some examples of KDE in Guix: kded, kdeconnect, kdvelop <luis-felipe>derivates: guix install font-adobe-source-han-sans:cn works here <derivates>I ran guix pull before, I'm not doing it via command but via config.scm instead <apteryx>roptat: did you try: make doc/guix.de.info <roptat>apteryx, that's weird because I don't get the issue on master <roptat>apteryx, the file is not the same on master and on version-1.3.0 <apteryx>roptat: the difference is that I've updated the translation files on version-1.3.0 (but I had the problem even before I did IIRC) <cyberTeX>I see. I'll do what I can on my Fedora Workstation; packaging on a Core 2 Duo wouldn't be fun anyways. <luis-felipe>derivates: How are you specifying that font package in your config.scm? <derivates>trying to paste a pestebin but im getting error <roptat>oh bf814642dcb8689557bbdcdc485a163952b18703 "nls: Fetch latest translations with 'make download-po'" <apteryx>OK, we want to stick to the versions that were already checked in master? I can remove the updates. <roptat>similarly 6997f145585c72a25d473f424d2f566fb8852fae "nls: Update translation files with doc-po-update." must have updated the po files against the pot from master, which is not the same as the string freeze <roptat>or were those specific to version-1.3.0? <roptat>in any case, we probably want to stick to the versions I pushed this morning for now <apteryx>no! It's just that I had issues with building the manual so I thought perhaps it's expected to use the latest versions of these <luis-felipe>derivates: Yeah, the specification->package procedure does not work for strings that specify outputs. <derivates>alright, i suspected, how would i modify my syntax to accept those? <apteryx>roptat: OK; so you pushed versions earlier today to the master branch? <apteryx>alright, I'll cherry pick these to the version-1.3.0 branch and see! It'll probably resolve it. <roptat>also, when adding a new manual file (cookbook or manual) you need to add the po file, and update doc/local.mk as well as po/doc/local.mk <luis-felipe>derivates: So, you have to take those out of the map. <roptat>(looking at 8d2a33777d81239b5ea7edf3441ef9cf47226779 :D) <apteryx>roptat: ah! thanks. I'll update the release.org doc accordingly. <nij>raghavgururajan: I'm now in `guix environment guix`.. what next? <apteryx>roptat: its in doc/release.org of guix-maintenance repo <rekado>Noisytoot: you’ll find worse when you actually configure it properly. <roptat>apteryx, there 28 commits I think that went to master this morning (plus the one that I pushed a few minutes ago) <luis-felipe>derivates: Then, you have to use the module(s) that define those font packages, and add them to the list of system packages in the form of lists. <derivates>alright I understand, i'll manage to get them in one way or the other as having both forms look odd :) <apteryx>roptat: I'm not planning to cherry pick anything to version-1.3.0 unless it's blocking the release <luis-felipe>derivates: Yeah, but it's not horrible, let me link you to an example... <nij>raghavgururajan: Your instruction: [1] `./pre-inst-env guix build ibus-chewing` and copy the resulting store path. [2] `./pre-inst-env guix environment --pure --ad-hoc ibus ibus-chewing grep`. [3] `cd [ibus-chewing-store-path]/libexec`. [4] `ibus-daemon --daemonize`. [5] `ibus list-engine | grep chewing` <nij>I've skipped [1] and did [2]. But for [3] I dod need the store path. <roptat>apteryx, oh, can you still cherry-pick those nls commits? <roptat>would be nice to have translations in the release :D <roptat>it should help with the issue we have <roptat>otherwise, we can redo all the fixes I made manually yesterday that translators didn't fix yet <nij>raghavgururajan: Skipped [1] [3], and ran [2] and [4]. Now [5] still doesn't find chewing. <nij>(I appreciate your patience a lot!) <apteryx>roptat: yes sure! These are blocking the release as they doc doesn't currently build :-) <nij>raghavgururajan: lemme double check if `git apply` did make a change <nij>It does. For example, "bison" was used as a module, which is new. <roptat>apteryx, did you change anything on the branch? <derivates>luis-felipe: thanks for the example, should i replace (append ...) with (cons ...) <raghavgururajan>nij: I think it has to do with running on foriegn-distro, in contrast to guix system. That's the only difference between our setup. <roptat>apteryx, I wonder though, I don't think download-po will actually add any new file <luis-felipe>derivates: If you want the list of packages to work like I show you, it is better to use cons* <nij>raghavgururajan: I'm on guix system. <nij>I had another arch machine, but I'm not using it. <apteryx>roptat: oh? Which make target would? doc-update-po? <raghavgururajan>nij: Wait what? They how come you for gcrypt error while running ./pre-inst-env <roptat>we've always added new languages manually <luis-felipe>derivates: If you want to use append, know that append operates on lists. <nij>raghavgururajan: I believe the repo I pulled from savannah is different from yours. <roptat>nij, sorry, I didn't follow your issue <nij>remembered that I couldn't make guix at all? before roptat's fix (on some vi.po something something). <apteryx>yikes, too many requests (attempting to download the translations) <apteryx>I was trynig to see if the download-po target really created the new French translation file <roptat>maybe we should download from the git repo that's behind weblate *raghavgururajan git pulls <nij>raghavgururajan: [2] without --pure ===> no code for module (gcrypt hash) <roptat>apteryx, no it wouldn't, it lists languages by looking at the LINGUAS file for guix and packages, and to existing files for the manual and cookbook <nij>i have to be away for some moments. but i will be very glad to test anything you mention after coming back. <nij>thank you raghavgururajan, thank you..! <apteryx>roptat: could teh doc-update-po target be responsible for it then? <roptat>doc-update-po will simply create a pot file, and update existing files from it; it doesn't download anything <cyberTeX>startx isn't present, so `startx openbox` was not possible. :P <nckx>raghavgururajan: Wow, that patch segfaults GNU patch. Well done. <nckx>But only when curled on stdin. /file/name works fine. *Noisytoot downloads the patch <nckx>Noisytoot will be disappointed. <nckx>It's something about the ‘-’. <dissoc>how do i reload udev rules after doing a system reconfigure? <mdevos>dissoc: the easiest way is by rebooting (-:, but there might be a better way <dissoc>that's what i was trying to avoid. although this is probably the last device i have to add <mdevos>maybe things ‘just work’? Have you tried attaching the device to the computer yet? *nckx wonders how it's pronounced. <apteryx>roptat: weird, then I don't have an explanation to how I got that new French translation file to appear <nckx>[Total guess] Does udevd listen for some signals? <apteryx>roptat: does 'make dist' runs for you on master? <mdevos>there was a mail or bug report or patch some time ago <dissoc>mdevos: yeah. but you win. reboot it is <mdevos>idk the details (about udev reloading) <Noisytoot>2 out of 2 hunks FAILED -- saving rejects to file -.rej <Noisytoot>patch: **** Can't reopen file - : No such file or directory <roptat>apteryx, no: make[2]: *** Aucune règle pour fabriquer la cible « po/doc/guix-manual.pot », nécessaire pour « distdir-am ». Arrêt *raghavgururajan hopes that nckx's spamdar didn't get triggered for multi-lines <nckx>Nah, it's not that sensitive. <roptat>apteryx, oh and I messed something up with the Chinese cookbook <mdevos>nckx: where did you find that image <nckx>I searched for ‘acoustic aeroplane locator’, why? <nckx>Good I was worried it was you. <nckx>raghavgururajan: What do I run in this pure env? *rekado mmmh, Chinese cookbook… <mdevos>nckx: Wouldn't that mean you was worried it was yourself? (-: Like Noisytoot said: nckx=mdevos <roptat>rekado, not that type of cookbook :p *rekado slowly walks to the fridge to devour a slab of cheese <roptat>apteryx, make dist succeeded now <mdevos>roptat: The nettle manual has a nettle soup recipe. It wouldn't be outlandish for the guix cookbook to have a recipe as well <nckx>Aurora_v_kosmose: It doesn't; Guix doesn't add hep global cflags like that. <roptat>hm... what's a tablespoon of butter? <Aurora_v_kosmose>nckx: I see. So it'd be up to gcc defaults (if any)? Is there a way to generally do that, force flags everywhere? <apteryx>roptat: cool! I'll cherry pick all the nls commits from master and try again <roptat>do people use spoons to cut butter? <mdevos>It even comes with security warnings! (‘Use gloves’) The author really knows their crypto :p <roptat>apteryx, before we really release, we'll probably want to update nls again <roptat>I can take care of that, and fix remaining issues... mh maybe I can kinda force the changes directly without commiting on weblate (I don't want my name in the files for languages I don't speak) <apteryx>roptat: wondering if new packages should be treated as breaking the 'string freeze'; we don't care right? <nckx>...and it's reset my layout to us-stupid, great. <apteryx>then I'll just rebase version-1.3.0 atop master <raghavgururajan>nckx: Great! It works for you too. No idea why it didn't work for nij, even after bootstraping and using pure env. <apteryx>it's 50 new commits, most of them fixing important bugs or adding translations <nij> I laughed so hard ==> * rekado .oO( chewing ) * rekado slowly walks to the fridge to devour a slab of cheese [15:33] <nckx>But only for HexChat, must be some GTK stupidity. Grrr. <roptat>apteryx, don't some of them contain changes to the manual though? <nij>Just came back - will stay for a moment <nij>hmmmmmm maybe I messed some step up? I find it unlikely. I can do it again. But lemme paste what exactly I did. Hold on. <nckx>raghavgururajan: Already tried. *raghavgururajan just noticed .chewing dir in their $HOME. Shoo!! <nij>guix` [3] `guix environment guix --pure --ad-hoc guix` [4] <nij>`./bootstrap && ./configure --localstatedir=/var && make` [5] <nij>`exit` [6] `git apply nij.diff` [7] `./pre-inst-env guix <rekado>roptat: using a tablespoon is good for plausible deniability. <nij>environment --pure --ad-hoc ibus ibus-chewing grep`. [8] <nij>`ibus-daemon --daemonize`. [9] `ibus list-engine | grep chewing` <nij>Any step here wrong? <nckx>nij: Just FYI, a paste would be less noisy and easier to read. <apteryx>roptat: the only new commits touching doc are: doc: Fix pxref translation issue. and doc: Build the French HTML cookbook. <nij>nckx: Oh you mean to use a paste bin? I will do that next time. <nckx>Aurora_v_kosmose: Correct, and Guix builds are pure anyway. <cyberTeX>I'm trying again, but `guix pull` failed: `error: Git error: error inflating zlib stream`. This is a bit confusing for me, guix seems to be using git, but git is not installed (I tried just `git`). <nckx>No prob nij. We recommend the one in the topic but any non-JS, non-Tor-blocking, non-horrible one is fine. <nckx>Aurora_v_kosmose: Depends on how powerful your workstation is. <nckx>You don't need a build farm for anything but saving time. <civodul>cyberTeX: hi! how did you install Guix? <cyberTeX>civodul: From the i686 system install image. <cyberTeX>There were graphical "Oh no!"s at first, but I managed to change to a different virtual terminal and now I have a working system, at least without X it seems. I think the problem may be with gdm or a driver, but I'm unsure right now. <civodul>cyberTeX: so you installed Guix System 1.2.0, right? <nckx>What is bpa? I wasn't paying attention. <cyberTeX>civodul: `guix pull` seems to have succeeded this time. It's building the store now. <nij>raghavgururajan: nckx: This is what I've tried - which led to an error that both of you didn't have. Would you mind taking a look? Maybe I've messed something up. https://bpa.st/JUJQ <civodul>cyberTeX: to answer your other question, Guix uses libgit2 (via Guile-Git) for Git operations <Aurora_v_kosmose>nckx: Well, I'd essentially need to substitute gcc with a gcc using the configs I'd want. <pkill9>but it wasn't thought out or anything <jgart[m]>The fact that it is a wrapper for the Chromium browser core. But that doesn't hold given ungoogled-chromium is in guix, right? <mdevos>jgart: I thought Chromium != Webkit <jgart[m]>And it's rebranded/a different browser from chromium <mdevos>looks like falkon uses qtwebengine, which uses parts of chromium ... <mdevos>never mind about chromium != WebKit <jgart[m]>mdevos: Hmmm, not sure. Maybe someone can chime in if they know the answer to that. <jgart[m]>ohh ok, will that be an issue for upstream, then/ <jgart[m]>Let me know if you need any help with gnome 40 stuff. I'd be happy to help with the beast of a task you've taken on ;) <Noisytoot>It's an issue for some FSDG distributions, but maybe not Guix <jgart[m]>Falkon is my goto "normal" browser on this old librebooted T400 that I use daily. I install it via nix currently though :( <mdevos>Noisytoot: IIRC, the latest N versions of nmap are non-free, but previous versions were fine <mdevos>or maybe that was for a different package <raghavgururajan>Noisytoot: What issue does QtWebEngine brings, that violates FSDG? I am not aware of any. <Noisytoot>raghavgururajan, It bundles Chromium, which may have FSDG issues (I am not sure what exactly) <Noisytoot>So some FSDG-compliant distributions don't package it <jgart[m]>Soon, we'll have an alternative to wasting time in an emacs buffer (emacs-2048): Wasting time in a gtk window (gnome-2048). <raghavgururajan>Noisytoot: It does bundles chromium stuff, but the non-free parts have been patched. <apteryx>civodul: is there no way to force pushed to a branch on savannah? for the version-1.3.0, I rebased it off master, and was planning to keep the WIP commit at the top <apteryx>we had to delete the branch and repush <apteryx>roptat: the version-1.3.0 was recreated now, the 'make dist' works, so I supposed 'make release' will proceed further. Will try do to so a bit later. <mdevos>I'm preparing a patch that fixes a cross-compilation issue in 'wrap-program'. It add an 'inputs' argument for where to search for "bash". It is the same argument as in (lambda* (#:key inputs #:allow-other-keys) ...). Is it a problem that the patch needs to adjusts the 200 (or so) callers? <mdevos>Aside from the tediousness of writing it in the first place of course ;-) <nij>raghavgururajan: should i push your definition to guix channel anyway? Maybe it will work after it becomes official.. <mdevos>I need to go now, send responses to sneek! <nij>But.. it's almost your work. I feel guilty doing that. Plus, it didn't really work on my machine. <nij>I trust you and nckx obviously xD I can try to do that (also my first time) if you don't mind. <lle-bout>nckx: hello! I am trying to add f2fs to the GNU Guix installer before the release but it may be too late. <nckx>It's almost definitely too late. <roptat>I'm working on another implementation of download-po that will not exhaust weblate's limit and will copy po files even for new languages <nckx>Well, I shouldn't say that, but ‘trying to add’ sounds like it'll be a few days lle-bout? <roptat>nckx, oops, the plural form is missing in "The following ~a packages are missing from '~a' for '~a':~%" <nckx>Well, let's review it when it's finished. Just don't count on it making the release; the branch is already frozen. <lle-bout>nckx: wont be too bad if it doesnt, there's still the latest images <nij>raghavgururajan: uh.. but I'm also worrying that it might break on others' guix system.. <nij>Or would you say that I must have done something wrong - so I don't have to worry? <nij>No need to worry to offend. I don't mind. I just don't want others getting a package that breaks. <raghavgururajan>nij: Sending patches to guix-patches@gnu.org doesn't break anything. Its a maillist. <nckx>nij: Sending in a patch just means sending in a patch for review (to guix-patches at gnu.org -- search the manual), you won't be breaking anything. WIP patches are welcome. <nckx>lle-bout: No, bcachefs. :) <raghavgururajan>nij: I meant that, since we couldn't figure out what went wrong on your setup, if you send the patch, others can also try to review and reproduce it. <nckx>No problem. I'll stay here in case more needs fixing. <roptat>well, with the Dutch translation at least :p <lle-bout>nckx: okay! did you have to customize GNU Guix for that? Does Linux-libre support it? <nckx>Is there a checklist for adding a new language to the Web site? <nckx>lle-bout: Yes and I didn't try, I don't have time to maintain a port. <raghavgururajan>> nckx: Is there a checklist for adding a new language to the Web site? <nckx>Admit that Dutch is basically Martian to you. <lle-bout>We could translate the GNU Guix website to pirate language <raghavgururajan>nij: Once you send the patch, folks will review and send feed-backs by replying in that thread. You can use those feed-backs to edit the patch and resend it. Once, the patch is satisfactory, a committer (folks who have commit access) will push your patch to guix channel. <nckx>lle-bout: Was f2fs already enabled in the kernel? *raghavgururajan leaves nij under the care of nckx and goes-off to bed <nckx>Good night raghavgururajan. <lle-bout>nckx: f2fs is in Linux and all its downstreams (Linux-libre as well..), and there's already support in GNU Guix System also. <nckx>lle-bout: I meant .config. <lle-bout>nckx: oh didnt check but I think if GNU Guix System supports it then yes! 