IRC channel logs

2020-07-21.log

back to list of logs

<xoxoboii>is in tommorow but i want use my laptop now
<mbakke>brettgilio: indeed, CMake itself would need to be compiled with that flag, so it's a core-updates change if we want it.
<mbakke>alextee: we normally only carry stable releases, unless there are good reasons for taking pre-releases
<mbakke>alextee: distrho-ports also seems to have a new release now, can you send an updated patch? :-)
<alextee[m]>can probably skip it then. the big thing is vst3 support on gnu/linux but guix doesn't ship any anyway
<alextee[m]>mbakke: sure!
<alextee[m]>mbakke: any ideas what i should do with zrythm re the trademark?
<alextee[m]>should i send a patch anyway and mention that stuff in the email ?
<mbakke>alextee: there is another problem with DISTRHO, I'm sending an email shortly
<mbakke>I know nothing about trademarks, so better take it up on the bug tracker.
<alextee[m]>👌
<apteryx>alextee[m]: why not mention that trivial modifications made in the context of packaging the software on free software distributions are allowed?
<apteryx>that doesn't sound legally slippery to me (I'm not a lawyer)
<vagrantc>"trivial" is the kind of words that lawyers have a party over.
<nckx>Hackers too. How I *wish* all the work-arounds in Guix were trivial…
<hendursaga>Is guix-patches-owner [at] gnu.org a bot trap or something? I'm looking at https://lists.gnu.org/mailman/listinfo/guix-patches
<hendursaga>Apparently my email with my patch didn't go through, nor did I get signed up for any of the mailing lists.
<brettgilio>mbakke: I sent that information to the issue tracker issues.guix.gnu.org/42448
<brettgilio>Thanks :)
***ilbelkyr is now known as nicole
<mbakke>brettgilio: thanks! by the way, you can not commit to staging or core-updates until .guix-authorizations has been merged anyway :-)
<guixy>Hello guix!
<guixy>hy is a standalone package, but it can also be used as a python library, like how Clojure is a java library that is also a standalone application(if we ever get a launcher). Should it be moved to its own hy.scm and/or renamed to "hy"? I already have a patch to rename it.
<brettgilio>guixy: Send us a patch :)
<brettgilio>And state your case there.
<brettgilio>That way we can all see it
<brettgilio>there = the mailing list
<brettgilio>mbakke: I believe the change would go in the cmake-minimal package right?
<brettgilio>I'm testing it locally without committing, just to see if I can't figure it out
<brettgilio>Thanks for helping with this issue btw.
<mbakke>brettgilio: yes, adding to cmake-minimal should fix it (we'll still have the problem for the few packages that use cmake-bootstrap, but I think we can ignore those)
<mbakke>hendursaga: are you sure you sent to the correct tracker (guix-patches@gnu.org)? I don't see it in the queue either.
<nckx>hendursaga: Where do you see -owner? Unsubscribed postings and your first post after subscription can take a while due to moderation. So can any post, really, due to machine slowness 😛
<nckx>mbakke: It can even take several hours to appear in the moderation queue.
<mbakke>oh
<hendursaga>How about a few days?
<nckx>mbakke: Yeah, no idea why :-/
<nckx>hendursaga: That's pushin' it. Can you sign up using the form you posted above? And what was the subject of your list mail?
<hendursaga>nckx: And I see it at the very bottom of the page, when you hover over the link. That's why I thought it was a spam trap.
<nckx>Oh. That's to send actual mail to actual people. It's not a spam trap but it's not a subscription address either.
<nckx>I'm deliberately not on that list so I can't say if your mail arrived if you sent any.
<nckx>By which I mean -owners.
*nckx tired.
<hendursaga>nckx: The subject was [PATCH] Add XStow and I can't find it on the tracker either.
<nckx>No, it's nowhere in the system. Sorry about that.
<hendursaga>OK. I sent an email directly to one of the addresses in case the -owner address was a spam trap.
<guixy>brettgilio, I'll send the patch then.
<brettgilio>Oddly enough, when I make the change for cmake-minimal it loses track of `rhash`
<brettgilio>weird.
<nckx>hendursaga: Welcome aboard!
*nckx → 😴
<apteryx>alextee[m]: another attempt: "as an exception, modifications to allow the software to better integrated with a free software distribution are permitted"
<apteryx>s/integrated/integrate/
***catonano_ is now known as catonano
<wdkrnls>Is there a prefered location to upload GIF files which demonstrate bugs for inclusion into bug reports and help questions?
<alextee[m]>apteryx: i don't think it's 100% safe. I thought of it before. Better to check this with a lawyer. Actually I'll try emailing the fsf to see if they can help. I hope they dont try to charge me too much
<guixy>There are a lot of things to check off when preparing a patch.
<guixy>I'm going to write a script to do all of them, then I'll call that script when I rebase my changes
***terpri__ is now known as terpri
***lukedashjr is now known as luke-jr
*raghavgururajan is feeling that moment, when the tests pass without manual intervention.
<bdju>anyone know what package has the "at" command?
<guixy>What does `at` do?
<bdju>I've not actually used it before, someone recommended it to me. I think it lets you do something *at* a certain time, if I'm understanding correctly.
<guixy>BLFS says it's in the "at" package http://www.linuxfromscratch.org/blfs/view/stable/general/at.html
<guixy>It looks like it does that by editing the crontab.
<bdju>I tried searching for thath and wasn't seeing it, but I guess I didn't try just installing it
<bdju>unknown package. so is it not on guix?
<guixy>guix uses its own cron.
<guixy>mcron needs updating...
<guixy>or a sister project
<bdju>I've never been one to get into cron stuff, but I probably should figure it out someday
<guixy>Actually, it looks like at has its own daemon
<guixy>Read up on it in the linked BLFS page.
<guixy>You will probably want to turn it into a service.
<guixy>Or clone it in guile scheme ;)
<bdju>both things are far out of my comfort zone, sadly. in reality I just won't use it if it's not already packaged.
<guixy>Running guix distro?
<bdju>yeah, I'm on guix system
<guixy>or foreign like debian?
<guixy>ok
<guixy>mcron is relatively easy.
<bdju>I'm looking at the man page but so far I'm not quite sure how it works
<guixy>Though I think at would be useful.
<guixy>Short Descriptions
<guixy>at
<guixy>queues, examines or deletes jobs for later execution.
<guixy>atd
<guixy>is the daemon that runs jobs queued for later execution.
<guixy>atq
<guixy>lists the user's pending jobs, or all jobs, if superuser.
<guixy>atrm
<guixy>deletes jobs, identified by their job number.
<guixy>atrun
<guixy>runs jobs queued for later execution.
<guixy>batch
<guixy>is a script that executes commands when system load levels permit.
<guixy>So I guess it lets you schedule a one-time task to run at a particular time.
<bdju>yeah, I told someone I ran sleep for 17h to set a reminder for something and they told me I may be interested in the at command instead
<guixy>I think I can work on packaging it and putting together a service. It looks simple enough.
<guixy>You could probably package it.
<guixy>You can always contact the guix help list.
<bdju>there's a long list of stuff I wish were packaged, and honestly I would probably not start with `at`. I've never used it anyway so I don't know what I'm missing
<bdju>I'm trying to find a usage example of mcron but I'm not finding anything. the man page doesn't make the syntax clear, in my opinion
<guixy>man mcron "Guile Simple Examples"
<guixy>i mean info mcron "Guile Simple Examples"
<guixy>g2g
<bdju>thank you
<bdju>hm it doesn't seem like what I wanted after all. I just wanted something that'd work in my shell without me creating files or configs, so I can set something to happen later on a whim, not necessarily permanent
<efraim>we don't have at yet, I was thinking of re-implementing it for guix using mcron
***apteryx is now known as Guest4223
***apteryx_ is now known as apteryx
***sputny1 is now known as sputny
<civodul>Hello Guix!
<alextee[m]>o/
*civodul wants to get to the bottom of the C++ issue at https://issues.guix.gnu.org/42392
<civodul>has anyone looked into it any further?
<cnmne>Hi guix! I'm trying to add a ruby package, but I'm getting a MissingSpecVersionError. `Could not find 'tty-table' (= 0.10.0, >= 0.10.0) - did find: [tty-table-0.11.0] (Gem::MissingSpecVersionError)`. Is it possible ruby can't see the spec for the 0.11.0 version ? Not sure what to do here.
<civodul>hi cnmne!
<civodul>cnmne: did you add ruby-tty-table (or whatever it's called) to the 'inputs' of your package?
<civodul>i know nothing about Ruby but hopefully others do
<efraim>it looks like it's the wrong version input, the question is does it actually have to be 0.10.0 or if 0.11.0 is also fine
<cnmne>civodul, efraim: hi! I also know nothing of ruby (oops), but I've hacked away with version substitutions to get it to work before. I'm trying to do it right this time. All the packages are there with recursive import.
<efraim>My brain is a bit fried right now, I'm putting the finishing touches on the mailman patches
<efraim>zope and django fun!
<cnmne>no worries!
<efraim>if there's a test suite that passes with the later version I'd assume it's ok
<cnmne>so everything builds and installs without error. I only get the error at runtime
<cnmne>i should mention, tty-table is just a dep of what i really want: neocities
<civodul>cnmne: could it be that tty-table needs to be propagated?
<cnmne>already propogating :[
<cnmne>when I substitute for a more lenient dependency number, the error moves on to other packages.
<efraim>I hope everyone likes mailman, that was a beast
<rekado>mbakke: I’ll take a look at them soon.
<civodul>NieDzejkob: hey! you should have received a message for your gitlab.inria.fr account
<civodul>it's become pretty painful and i've shared my frustration with those who take care of that
<mbakke>rekado: excellent, ty
<mbakke>efraim: wooow, nice job :-)
<civodul>heya mbakke!
<mbakke>NieDzejkob: interestingly there are no performance-related changes here: https://salsa.debian.org/chromium-team/chromium/-/commits/master -- probably the maintainer uploaded a local build with some weird settings? not sure how Debian works.
<mbakke>sup civodul :)
***terpri_ is now known as terpri
<civodul>mbakke: it's quiet here, i was wondering whether everyone was sunbathing!
<civodul>we should resume that discussion about making a release
<civodul>i think we've met our main goals
<mbakke>civodul: yes indeed, can't think of any current "release blockers"
<civodul>cool
***apteryx is now known as Guest4026
***apteryx_ is now known as apteryx
<civodul>the libstdc++ thing is problematic, but prolly fixable
***Guest4026 is now known as apteryx
***apteryx is now known as Guest13088
***apteryx_ is now known as apteryx
***Guest13088 is now known as apteryx
<mbakke>it's been like that "forever", no? or maybe a regression since the CPLUS_INCLUDE_PATH change?
***apteryx is now known as Guest93264
***apteryx_ is now known as apteryx
***Guest93264 is now known as apteryx
***apteryx is now known as Guest23268
***Guest33859 is now known as apteryx
***Guest23268 is now known as apteryx
<civodul>mbakke: yeah i think it's a regression since CPLUS_INCLUDE_PATH
***apteryx is now known as Guest35780
***Guest81865 is now known as apteryx
***apteryx is now known as Guest77003
***apteryx_ is now known as apteryx
***Guest77003 is now known as apteryx
***apteryx_ is now known as apteryx
***Guest82453 is now known as apteryx
***apteryx_ is now known as apteryx
***Guest90220 is now known as apteryx
***apteryx is now known as Guest11739
***Guest11904 is now known as apteryx
***Guest11739 is now known as apteryx
<civodul>apteryx is hacing connectivity issues :-)
<civodul>*having
<apteryx>hey. I think I've got a hold of the situation. Sorry for the noise that must have ensued.
<apteryx>I had a hard time understanding what was going on, my weechat client was throwing write errors until I figured out it couldn't write to its log files because they were broken symlinks. I must have shot my foot with Stow :-)
<civodul>heh :-)
<civodul>Stow + Guix, your machine must definitely be a symlink farm
<apteryx>eh! It's been a confusing pain at times (.gnupg versioned files missing or disliking symlinks causing subtle, hard to debug issues), but overall I'm pretty satisfied with the setup. I'm using Stow to manage my dot files and per project "private" files.
<apteryx>On another subject it seems my machine's lost mdns since reconfiguring.
<civodul>oh
<apteryx>I still have that old line (name-service-switch %mdns-host-lookup-nss) in my config. Has something changed?
<civodul>seems to work for me
<civodul>nope
<apteryx>OK, it pings locally? 'ping your-hostname.local' ?
<civodul>apteryx: actually no! it pings other machines, but not mine
<civodul>uh
<civodul>ah wait, that's because mine got renamed to HOSTNAME-2.local
<civodul>that one works
<apteryx>oh, same
<apteryx>why is that
<civodul>(you can check "avahi-browse _workstation._tcp")
<civodul>that happens if your name was already taken
<civodul>which itself can happen if you disconnect and reconnect to the same LAN, i think
<apteryx>Ah :-/
<apteryx>that'd be a shame, since it'd mean you can't really rely on this being stable across reboots
<apteryx>I'll reboot to check
***apteryx is now known as Guest12029
***apteryx_ is now known as apteryx
***Guest12029 is now known as apteryx
***apteryx_ is now known as apteryx
***apteryx is now known as Guest7237
***Guest52373 is now known as apteryx
***apteryx is now known as Guest36388
***Guest7237 is now known as apteryx
***apteryx is now known as Guest70436
***Guest36388 is now known as apteryx
<apteryx>hmm. I'll let go of the relay business for today. Something's not right.
<apteryx>civodul: it seems to consistenly boot into hostname-2 now. I'm thinking something might be up in the ordering of the network service starts.
<apteryx>'herd restart networking' brings the correct host name back.
<mbakke>on a related note, the 'nss-mdns' system test has been broken for a long time, I tried looking into it during the Avahi 0.8 upgrade but could not figure it out :/
<civodul>apteryx: ah, perhaps check /var/log/messages to see what happens at boot time
<civodul>mbakke: yeah, that test has always been flaky/broken
<civodul>we could comment it out maybe
<civodul>i've posted my findings: https://issues.guix.gnu.org/42392#2
<civodul>mjw: hey, do you happen to know how include/c++/TRIPLET is added to the g++ header search path?
<civodul>where TRIPLET is x86_64-unknown-linux-gnu or similar
<mjw>civodul, I happen not to know that. sorry
<apteryx>civodul: thanks, I'll take a look when I have a chance
<civodul>ah, GPLUSPLUS_TOOL_INCLUDE_DIR
<civodul>thanks anyway mjw :-)
<mjw>civodul, some upstream gcc hackers and other distro gcc packagers do hang out in #gcc on irc.oftc.net if you need real help
<mjw>But it looks you found ./gcc/cppdefault.c already
<civodul>mjw: yeah i'll go to #gcc if i get stuck
<civodul>folks: could not authenticate commit 84d31a5c356bdff541cfaec70630330d69408e14: key #vu8(232 42 192 38 149 214 255 2 67 202 30 92 246 197 45 209 186 39 203 135) is missing
<civodul>that's the commit by brett
<civodul>looks like we'll have to hard-reset
*civodul has to go
<mbakke>civodul: works for me, did you forget to update your keyring branch?
<civodul>oh my authentication error was PEBKAC: my 'keyring' branch was not up-to-date
<apteryx>perhaps the hook should refresh that branch?
<apteryx>by the way, is it possible to refresh that branch without checking it out? it causes the whole source tree to be rebuilt
<dadinn>hi all
<dadinn>I have a question about running scripts in Guix: why is it that there is no /usr/bin/env in the live environment? It seems virtually impossible to use any shebang line without even env :/
<dadinn>I tried `#! env env env env env env env env env env guile` to run y guile scripts, to no avail :(
<dadinn>sorry typo, the correct shebang would be `#! env -S env -S env -S env -S env -S env -S env -S env -S guile` :P
<mbakke>apteryx: you can create a "git worktree" with the keyring branch as a workaround
<mbakke>dadinn: do you mean in the installer? Guix System has /usr/bin/env, unless you changed special-file-service-type
<dadinn>mbakke: I am using guix-system-install-1.1.0.x86_64-linux.iso
<dadinn>the /usr directory doesn't exist on it :/
<dadinn>I think /usr/bin/env is the bare minimum which has to be at least symlinked there
<fps>dadinn: on my installed guix system there's a /usr/bin/env. why do you need it in the installer?
<mbakke>dadinn: the installer is not meant as a general-purpose computing environment, you can easily make another "live" Guix image that suits your needs though
<dadinn>mbakke: The "installer" gives the option to "Install using the shell based process", which is what I aim to do :)
<dadinn>mbakke: https://github.com/dadinn/init-instroot/tree/feature/multi-distro
<mbakke>dadinn: if all you need is to run 'guile', using /bin/sh as the shebang is actually more flexible than /usr/bin/env, you can search for /bin/sh here as an example: https://www.draketo.de/proj/py2guile/
<mbakke>not sure if /bin/sh is present in the installer though
<mbakke>efraim: probably the mailman inputs do not need to be propagated, as the 'wrap' phase should take care of things?
<efraim>mbakke: hmm, probably right
<dadinn>mbakke: actually there is a symlink for `/bin/sh`, but I am not sure how that helps :/
<dadinn>I have some guile scripts which I want platform independent, so I have to use either `#!/usr/bin/guile` or `#!/usr/bin/env guile`... as you can see these are scripts to help with the install/bootstrap a new system
<mbakke>dadinn: this should be sufficiently platform-independent and work even in the installer: https://paste.debian.net/1157328/
<mbakke>dadinn: I don't think you need -e main, you can omit that and write the script directly following the !#
<dadinn>mbakke: wow, that's actually freakin' awesome!
<mbakke>dadinn: it's a neat hack :-) I had seen it before but did not appreciate the cleverness until reading ArneBab's nice 'Python to Guile' book: https://www.draketo.de/proj/py2guile/
*ArneBab is happy to see people read py2guile :-)
<pkill9>i made a bug report that guix stores a git origin in the same store path whether it's recursive or not, and nobody has replied :<
<sneek>Welcome back pkill9, you have 2 messages!
<sneek>pkill9, mwette says: to read/write scheme files look at last lines of http://git.savannah.nongnu.org/cgit/nyacc.git/tree/module/nyacc/lang/c99/ffi-help.scm
<sneek>pkill9, mwette says: call-with-input-file ... call-with-output-file
<nckx>Evening all!
<nckx>mbakke: <if all you need is to run 'guile', using /bin/sh as the shebang is actually more flexible than /usr/bin/env> Oh? How?
<mbakke>nckx: https://paste.debian.net/1157328/
<mbakke>you can do all sorts of trickery before the 'exec guile' line
<nckx>But what does #!/bin/sh give you that #!/usr/bin/env sh doesn't?
<nckx>Better portability?
<nckx>mbakke: Ah, no, /bin/sh was for flexibility. /usr/bin/env sh for portability (reading backlog in reverse order is not a good idea). I'm just wondering which flexibility that is.
<mbakke>nckx: ah, I was comparing to the '#!/usr/bin/env guile' case
<nckx>Ack.
<nckx>Day-to-day Guile scripting is weird & wonderful, I should get into it more.
<pkill9>has any plans/progress been made on having the build farms provide lists of files in packages?
<pkill9>i have some stuff I'd like to do with that
<pkill9>i suppose for now I could use file lists provided by archlinux
<zimoun>pkill9: last time about the topic, see http://issues.guix.gnu.org/issue/42291 and Pierre said: «The good news is that I'm going to work on this... Soon© ;)» But no progress I am aware.
<pkill9>that last post sounds promising for now, just download all the new nar files and index them
<pkill9>so the question is, how to listen for new nars
<pkill9>unpacking them can be done with guix copy
<pkill9>then just dump the list into a text file with the name being the same as the store path
<pkill9>in the long run would be better for the guix publish service to provide this itself though, or guix data service, or whatever
<pkill9>oh they suggested listening to the guix data service for new nars
<civodul>pkill9: publish creates nars on demand, so it could update indexes on demand as well
<civodul>doing roughly the equivalent of "guix archive -t"
<apteryx>mbakke: worktrees to the rescue, thanks. I wish there was a git command to update branches without having to checkout a copy.
<pkill9>how do you find out what is preventing the garbage collector removing a store path?
<apteryx>pkill9: I'd try something like 'guix gc -R /path/to/item'
<civodul>you can look at "guix package --list-profiles", and then things like "guix graph -t references --path $(readlink -f ~/.guix-profile) $(guix build strace)"
<civodul>it's pretty involved, we should do something about it
<civodul>and "guix gc --referrers /path/to/item", too
<pkill9>i found out why
<pkill9>my shell was in the store path directory
*jonsger works on hunspell-dict-de and wonders why no one (German) did that before :P
<jonsger>because it needs not yet packaged ispell :P
<dadinn>I am getting a no space left on device issue on the ISO environment... is there a way to increase the available space on the overlay fs?
<dadinn>in Arch I had similar problems, i had to add update some kernel args during boot :/
<dadinn>I see I can get to the kernel command line with 'e'... what's the kernel argument to increase overlayfs / space?
<nckx>dadinn: There is no such kernel argument. Perhaps you can mount -o remount,size=foo the backing tmpfs. The ISO (installer, I presume) live environment isn't really meant for storing large datasets in RAM. Why are you running out of space?
<nckx>What are you storing?
<dadinn>building ZFS kernel modules
<nckx>And why haven't you (been able to) start(ed) cow-store by that point?
<nckx>dadinn: OK. Do you have any storage you could add to the live system?
<dadinn>nckx: I am inside KVM, have storage and memory too
<nckx>dadinn: Are you using the graphical installer?
<dadinn>nckx: nope, just commandline
<dadinn>nckx: shell process, I suppose
<nckx>OK. Are you following the ‘System installation’ part of the manual?
<nckx>Yeah, it's called ‘Manual Installation’ in the… manual.
<nckx>Which command did you run that ran out of space?
<dadinn>nckx: I think it was `guix package -i zfs`
<dadinn>but i installed couple of other packages before that
<dadinn>and it failed firstekrpat
<nckx>Which device is full (df -h)?
<dadinn>nckx: /
<dadinn>nckx: / type overlay
<dadinn>nckx: I suppose it's memory backed, hence increasing the memory is usually what I have to do
*nckx started an installer VM to help, but it's frozen :-/ Just sitting there.
<dadinn>nckx: in Arch, I had to add cow_spacesize=1G in the kernel arguments
<nckx>So I can't give you precise info/commands.
<nckx>dadinn: Guix doesn't have such a knob.
<dadinn>nckx: ah yeah, I ran guix pull, and then installed tmux, and then zfs... seems not enough space left :/
*kmicu mapped midi keyboard to guix command flags. There are plenty of knobs to wiggle.
<nckx>dadinn: Oh… I strongly unadvise running guix pull or guix install in the live environment before starting cow-store.
<nckx>guix install a few things, fine, but adding guix pull will download a huge number of things.
<dadinn>is `guix pull` like an `apt upgrade`?
<NieDzejkob>guix pull is like apt update
<nckx>dadinn: Dunno, but Web says ‘apt update’.
<lfam>If the distros must be compared, it's like `apt update`. But it will download a bunch of things
<lfam>`guix upgrade` is like `apt upgrade`
<nckx>Not enough to eat all your RAM, but it will cause anything you install afterwards to pull in completely new and shiny dependencies.
<lfam>There are not many points of comparison between Guix and old-school distros, however
<dadinn>btw, I have 4G RAM in the VM :/
<nckx>That should be more than enough, but I've never installed ZFS 😛
<lfam>I agree with nckx that you shouldn't run `guix pull` before starting the cow-store service, or before installing Guix System at all, really
<kmicu>That’s exactly how I killed my latest Guix installation and I was guix pulling a default XFCE config. Nothing more.
<nckx>dadinn: First of all, I think your current VM is probably not worth saving. I'd start a new one. But firster of all: what kind of system are you building? One that boots off of ZFS (…is that supported)?
<nckx>☝ question for the room.
*kmicu says no, it’s not supported. Even booting from btrfs barely works. 😺
<nckx>I don't see any ZFS support in gnu/system.
<nckx>kmicu: Orly? That's unfort.