IRC channel logs


back to list of logs

<Blackbeard[m]>rvgn: hi ٩(◕‿◕。)۶
<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?
<apteryx>bandali: from source, of course :-)
<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>bandali: Although
<apteryx>it might not be easy (can't type tonight)
<bandali>i see
<bandali>i kinda had that impression as well
<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>sp3ncer: eh :-)
<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
*apteryx waves
***roptat_ is now known as roptat
<roptat>hi guix!
<Blackbeard[m]>roptat: hi
<Blackbeard[m]>ardumont: hi :D
***buffet_ is now known as buffet
<civodul>Hello Guix!
<buffet>hello civodul
*civodul sends the localed patches
<civodul>beware, it hurts the eyes
<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>I see
<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
<civodul>and thanks for the typo
<apteryx>is the 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>and i think it has a cache
<civodul>so maybe its cache is stale or something
<civodul>roptat: some more keyboard layout stuff:
<civodul>roptat: ↑ after that i think we're all set in terms of keyboard & doc
<civodul>so i'd say ready for the TP!
<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>well, the firt case
<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
<roptat>is that a guile thing?
<civodul>it's in (guix deprecation)
*civodul goes afk for a bit
<roptat>thanks :)
<jackhill>hmm, when I run guix package -i icecat, it downloads a substitute for and then prints:
<jackhill>guix package: error: getting status of /gnu/store/.links/1acwqa90qh1j5i8q2jd3a7hf6gf489c8vkp63li8nkbvxfc8dq3d: Bad message
<jackhill>that, uh, doesn't seem good
<bavier>jackhill: could you try 'guix gc --verify'?
<jackhill>bavier: sure, running…
<jackhill>benny: completes sucessfully with exit code 0
<bavier>jackhill: does it print anything? (our error codes are not reliable iirc)
<civodul>"Bad message"?
<bavier>oh, is that a gettext thing?
<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?
<jackhill>and the original package invocation:
<jackhill>civodul: yes
<civodul>EBADMSG, didn't know that one
<civodul>jackhill: what's your file system?
<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>don't run 'ls' in there :-)
<civodul>lstat("/gnu/store/.links/1acwqa90qh1j5i8q2jd3a7hf6gf489c8vkp63li8nkbvxfc8dq3d", 0x7ffda3a75600) = -1 EBADMSG
<civodul>that's "impossible"
<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
<civodul>ratpoison can't spawn processes?
<civodul>like which commands?
<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?
<apteryx>nckx: so, can I do:
<bandrami>I'll reboot to that generation and try it
<apteryx>env -i bash source /some/profile ?
<bandrami>(side question: is there a way to tag system generations with friendlier names?)
<civodul>that could be useful
<bandrami>Maybe I'll work on that
<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?
<civodul>ah ok, just read the back log :-)
<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.)
<bavier>hi quiliro
<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.
<jackhill>thanks for your help
***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.
<rekado>but there’s no package yet
<rekado>this one:
<nckx>rekado: Ah, perfect.
*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>oh, I remember now!
<apteryx>We can pass --init-file :-)
<apteryx>nckx: env -i bash --init-file '/gnu/store/6dz...vggr-profile/etc/profile'
<nckx>apteryx, kmicu: Thanks!
<rekado>yes, that’s what I do.
<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
<nckx>Got it.
<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!
<apteryx>nckx: eh ;-)
<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
<civodul>well, that is still in the manual
<civodul>but it's very expressive
<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>nckx: indeed!
<civodul>wonderful, no?
<civodul>it's something that other distros do, like Debian
<civodul>the 'console-setup' package
<nckx>‘Wonderful if true’.
<civodul>you define it once, including options like "ctrl:nocaps", and then it works for GRUB, Linux, and Xorg
<civodul>crazy stuff ;-)
*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 ☺
<civodul>vagrantc: cool, thank *you*!
<nckx>Yes. Let us all give thanks.
<civodul>it's not LaTeX, it's Texinfo ;-)
<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
<nckx>civodul: OK. Cool.
<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>oh, and getting X to be useable ...
<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>nckx: it is
<rekado>take a look at the module definition
<rekado>there’s an #:export list.
<nckx>rekado: You're right.
<nckx>Hm. My Guix is borked.
<nckx>Nothing is public 😃
*nckx rebuilds.
<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>oops, wrong system ...
<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))
<bavier>that would also work
<ngz>I eventually settled on (invoke "touch" "foo"), at least the intent is clear.