<bandali>for packaging java programs, is there a preference on building from source vs. using prebuilt jars? <bandali>esp ones with complex builds using gradle, which i don't think is currently well supported by guix? <nckx>bandali: Less ’preference’ than ‘I'd be suprised and disappointed if prebuilt jars were accepted at all’, but then I'm not a Java person. <apteryx>it might not be easy (can't type tonight) <apteryx>rekado_: I couldn't reproduce the python-pygithub issue anymore, after modying the python-build-system to print if it was using setuptools or not (a non-functional change) which triggered rebuilding the transitive dependencies of python-pygithub... how strange. <sp3ncer>I was here last night and having trouble getting the guix binary to run on fedora, it just shows a failed status in systemctl <sp3ncer>The only step I haven't done is run "guix-daemon --build-users-group=guixbuild" in the build environment setup because it doesn't seem to do anything after several mionutes <sp3ncer>Nevermind, I didn't realize that was the actual daemon <apteryx>rekado_: seems the bytecode produced by running the tests was interfering with the byte-compilation, as disabling the tests for python-pygithub makes it reproducible. <apteryx>I'm attempting to move the check phase below the install phase (which does the byte-compilation) in the python-build-system. Will report. <apteryx>rekado_: success :-) the culprit was the ordering of the install vs check phase. <efraim>And I always assumed tests were supposed to be nondestructive <apteryx>the sources are intact; it's the bytecode that is produced by the interpreter at runtime when the tests run that doesn't seem to match the bytecode produced by the setuptools/distutils install phase. <apteryx>and somehow instead of forcing new bytecode generation it is recycled as cache -- this is speculation but that's the only way I can explain it. <apteryx>it also doesn't seem to affect many packages ***roptat_ is now known as roptat
***buffet_ is now known as buffet
*civodul sends the localed patches <roptat>civodul, looks ugly indeed... could we not patch gdm instead so it doesn't try to be smart? <civodul>roptat: i looked into that: there's a set_keymap call in JS that we could comment out, but that would probably break the keyboard switcher altogether <civodul>so i think it's safer to isolate the kludge in localed <roptat>in patch 2, "to maintain of fork of the bits we need" -> "to maintain a fork of the bits we need" <roptat>civodul, other than that it looks acceptable (not tested though) <roptat>does gdm start with the right locale too? <civodul>roptat: yes, but that was already the case <apteryx>is the issues.guix.info being updated still? recent issues are 1 month behind <apteryx>(as seen from the front page section "Recent activity") <civodul>i'm not sure how it determines recent issues <civodul>so maybe its cache is stale or something <civodul>roptat: ↑ after that i think we're all set in terms of keyboard & doc <roptat>civodul, either you forgot to add extensions to the other login managers we have (sddm and slim iirc) or you forgot to add them in the changelog <roptat>shouldn't the use of define-deprecated output a warning instead of doing nothing? or is it exactly the purpose of returning #f? <civodul>yes, i didn't modify the other login managers out of laziness <civodul>left as an exercise to the reader :-) <civodul>re define-deprecated, #f means that there's no replacement for the deprecated procedure *civodul goes afk for a bit <jackhill>guix package: error: getting status of /gnu/store/.links/1acwqa90qh1j5i8q2jd3a7hf6gf489c8vkp63li8nkbvxfc8dq3d: Bad message <bavier>jackhill: could you try 'guix gc --verify'? <jackhill>benny: completes sucessfully with exit code 0 <bavier>jackhill: does it print anything? (our error codes are not reliable iirc) <civodul>i can't find an errno value for "Bad message" in the Linux headers <civodul>jackhill: if you rerun "guix package -i icecat", do you get the same error? <civodul>could you "strace -p PID -f -s 200 -o log", where PID is the PID of the main guix-daemon process as returned by "herd status guix-daemon"? <jackhill>running ls in /gnu/store/.links turns up 10 things with that fail with ls: cannot access '1rn6wdgc9c7xnvrc36bnl2j3x8v27ri5q3kbfc8n6fwjdl087ajx': Bad message (hashes vary) <civodul>lstat("/gnu/store/.links/1acwqa90qh1j5i8q2jd3a7hf6gf489c8vkp63li8nkbvxfc8dq3d", 0x7ffda3a75600) = -1 EBADMSG <civodul>jackhill: what kernel version and architecture is this? *kmicu bets on Linux-libre kernel on x86 Broken Disk OS. <civodul>i also wonder if there's a mapped device beneath that file system <bandrami>I just ran 'guix pull' and 'guix system reconfigure' with the lightweight-desktop.scm configuration from the 0.16 installer, and instead of LightDM I now have GDM, and ratpoison can't spawn any processes. <apteryx>what was the 'env' incantation to source a profile in a pure way? <apteryx>env -i source /gnu/store/.../profile/etc/profile doesn't work <apteryx>(env: 'source': no such file or directory) <nckx>apteryx: source is a shell built-in so yeh, that can't work. <efraim>it seems when I fixed my xorg-module list I lost my two-finger right-click :/ <civodul>bandrami: %desktop-services switched to GDM recently <efraim>I still have two-finger scroll, just lost right click *efraim is looking into it, no need to worry about me <bandrami>civodul: C-c for an xterm fails with status 127, as does C-d (I bound it to dmenu_run). If I try to start something in ratpoisonrc it also fails with status 127 (at least that's what the message in the top right corner says) <bandrami>I think I'll try hand-building from the components I want; I've never trusted GDM... <civodul>yeah i have mixed feelings about GDM <civodul>bandrami: could you check the value of PATH via /proc/PID/environ for your ratpoison process? <bandrami>I'll reboot to that generation and try it <bandrami>(side question: is there a way to tag system generations with friendlier names?) <nckx>apteryx: I'm afraid I don't know which original ‘env incantation’ you're referring to, just that the one you pasted won't work. But it'll be in the direction of spawning a new bash shell first, yes. <bandrami>PATH is /run/setuid-programs:~/.config/guix/current/bin:~/.guix-profile/bin:/run/current-system/profile/bin:/run/current-system/profile/sbin (tildes expanded in original) <nckx>(bash -c 'foo bar' executes ’foo bar’, but I don't know how you get an interactive shell from that. There's also --noprofile. 🤷) <bandrami>and... yep, no xterm or dmenu_run in any of those <bandrami>Thanks! so: it can spawn processes, but the two programs I use to do that weren't in the profile <civodul>bandrami: and xterm isn't found in any of these? <bandrami>I'm assuming desktop-services used to add them and doesn't now? I just installed both to my local profile and all is fine now. <bandrami>well, wait, dmenu_run should have still been there because it's in the config file. That's odd. <nckx>Dear #guix, what programme do y'all use to browse installed fonts? <nckx>(Visually. No ‘fc-list’ plz.) <jackhill>civodul: it was linux-libre 5.0.2. No device mapper. I reconfigured, and now have 5.0.5. Upon rebooting, I had to run fsck manually to fix detected problems. Two html files ended up in lost+found, but I'm no longer experiencing any Bas Message errors. ***rekado_ is now known as rekado
<rekado>nckx: there’s an old X11 programme for that… but I forgot its name. It’s not pretty, but it’s used to generate and copy the X11 font spec strings. <nckx>Thanks. Yeah, xfontsel, but it's limited to the point of uselessness (to me). <nckx>It shows only a small subset of 'em too (or I'm using it wrong). <rekado>looks like there’s a font viewer for GNOME. *nckx prefers a GNOME programme over nothing at all. <kmicu>nckx: When I was searching for typefaces I was using FontMatrix but it looks like it’s not packaged in Guix yet. (You could use Nix to install it though xD). <apteryx>rekado: would you remember the command you once shared with me to source a profile in a pure way? Something to do with env -i ... but I can't find the right incantation. <apteryx>nckx: yeah, I figured out I also don't know how to run a command *and* get an interactive session out of it. <apteryx>nckx: env -i bash --init-file '/gnu/store/6dz...vggr-profile/etc/profile' <nckx>apteryx: I was grepping the man page for ’profile’, of course, when I obviously should have used ‘init’. 😒 <rekado>for users I often write little “activate” shell scripts that change the prompt and start a sub-shell. <rekado>I think it would be nice if Guix did this automatically. <nckx>rekado: When doing what? (I never asked what the use case for all this was and am just curious.) <efraim>hmm, just reconfigured and I've rebooted to tty <efraim>might be related to using slim, not sure <nckx>civodul: I'm excessively dense today, but what will replace console-keymap-service, exactly? <efraim>sometime between march 28th-ish and yesterday-ish *nckx reconfigured this morning but hasn't rebooted yet. Uh oh. <rekado>nckx: I ask people to use separate profiles for separate projects. It’s convenient to have a little script that can be run to “enter” the profile’s environment. <rekado>source-ing the etc/profile file isn’t quite the same as it changes the current environment <rekado>and nobody remembers the right incantation for “env -i bash --init-file …” <nckx>rekado: So not that different from guix env --pure, but with a ‘use this here profile’ argument? <rekado>“guix environment” can be a little too slow. <rekado>whereas the “activate” script is instantaneous <rekado>Guix is particularly slow at the MDC, because we have the store on NFS, so nobody uses “guix environment” for recurring tasks. <nckx>‘guix environment’ takes a few tolerable seconds here but that's still not ideal. <rekado>(I’m trying to get approval for dedicated storage, so the problem should eventually disappear) <apteryx>nckx: I had an idea to use 'guix environment -p /your-profile' to recycle an existing profile, which rekado thought was OK, but haven't had time to implement it yet. <apteryx>that way you can say you want it --pure, for example <nckx>apteryx: Yeah, that's what I was thinking. -p fits relatively nicely with its use in other subcommands. <nckx>Glad to hear it's coming! <nckx>Hey I didn't say ’soon’. <apteryx>I tried: guix pack --manifest=some-manifest.scm --format=docker -S /etc/profile=etc/profile, thinking the PATH would be configured automatically when using docker run, but nope :-/. Any nice way to do this? <apteryx>oh! the -S option doesn't seem to be honored by the '-f docker' flavor of guix pack? <apteryx>nevermind, I think the emacs tar viewer is playing tricks on me <apteryx>and I was trying to execute "bash" without including it in my manifest... duh. *apteryx is having fun with guix packs for docker <civodul>jackhill: weird, but good that it's fixed! <civodul>nckx: console-keymap-service is superseded by the 'keyboard-layout' field, which installs the keyboard layout at boot time, from the initrd <civodul>it's not 100% equivalent, as shown with the example that used to be in the manual <roptat>I don't understand what's happening... I tried to update ocaml-cmdliner, but the ocaml4.02 variant needs to stay at the same version <roptat>so I defined ocaml4.02-cmdliner and used the properties field in the ocaml-cmdliner package <roptat>now I can't build any of these because guix cannot find ocaml4.02-cmdliner <roptat>"Unbound variable: ocaml4.02-cmdliner" <roptat>I used (properties `((ocaml4.02-variant . ,(delay ocaml4.02-cmdliner)))) <roptat>ah nevermind, it's because the properties get inherited in the 4.02 variant <nckx>civodul: Huh. So it really does use the ‘X-style’ keyboard-layout to set the console map? I didn't know that was even possible. <nckx>Even when loadkeys & XKB use completely different names for the same thing? <civodul>it's something that other distros do, like Debian <civodul>you define it once, including options like "ctrl:nocaps", and then it works for GRUB, Linux, and Xorg *nckx uses a zany amount of those so yay. <vagrantc>civodul: thanks for merging the veyron-speedy/asus-c201 stuff ... i'll try to write some documentation, though latex and i have nver been good freinds <nckx>civodul: Thanks for all that ☺ <nckx>Yes. Let us all give thanks. <apteryx>can guix run inside a docker container? <nckx>civodul: So the ‘top-level’ keyboard-layout is equivalent to the old console-keymap-service, correct? I mean: it does something on its own and isn't just there to pass to xorg- & bootloader-configuration? <apteryx>civodul: really cool, the keyboard layout stuff! I'm looking forward trying it <vagrantc>civodul: somehow they all look alike to me :) *nckx is high on life also pain killers and a bit stupid today. <civodul>nckx: the top-level 'keyboard-layout' is for the Linux console <vagrantc>now if i could only figure out why luks devices crash badly on this machine, i'd have a usable armhf guix laptop <vagrantc>though when stranded on a console, long as i have tmux, i actually find i can go hours without noticing that X isn't running <nckx>Why is vorbis-tools not public? <rekado>take a look at the module definition <nckx>I had a syntax error in an unfinished package but it's weird that no errors were printed :-/ <vagrantc>so this c201 is the fastest armhf machine i have running guix ... 4GB of ram ... it managed to run "guix pull" in under 12 hours ... <civodul>vagrantc: ouch, still no substitutes? <vagrantc>civodul: substitutes have been happening, but there are usually some parts of guix pull that don't usually seem to have substitutes <vagrantc>though this appears to have taken less than ... 20 minutes for a whole guix pull && guix package -u . && guix system reconfigure ... <vagrantc>that seemed overly optimistic ... still on building /gnu/store/312i6kyg97laf92a5jmk3xrr29jfk21i-guix-packages-base.drv... since i started babbling about it <ngz>Hello. How can I "touch" a file, i.e., create an empty file during a phase? <ngz>besides invoke touch, that is. <bavier>ngz: idk if guix has something simpler already, but you could do (close (open <path> O_CREAT)) <ngz>Hmm, maybe (call-with-output-file "foo" (lambda _ #f)) <ngz>I eventually settled on (invoke "touch" "foo"), at least the intent is clear.