IRC channel logs


back to list of logs

<Laalf>pkill9: hah
<pkill9>that's not the same bug?
<Laalf>pkill9: that is the problem i am facing
<Laalf>MY GOD! i got it to work: /xfce4-power-manager/logind-handle-lid-switch true and it works
<Laalf>that took me way too long
<pkill9>what did you do?
<Laalf>xfconf, add /xfce4-power-manager/logind-handle-lid-switch as boolean set to true, rebooted
<apteryx>rekado: I see! Maybe there is a fancy way for incrementally fetching only new emails to update the cache?
<lafrenierejm>Would someone be willing to link me to the docs for running X on GuixSD? I would like to login via TTY and start X manually with `startx`. `startx` times out with 'unable to run server "/gnu/store...xinit-1.4.0.bin/X": No such file or directory'.
<Laalf>lafrenierejm: do you have a problem with running slim? startx will not be supported anymore due to security concerns
<Laalf>for anyone who missed it:
<efraim>in regards to bug#33300, in the absense of an in-place solution, I'm thinking of writing my own custom phase(s) to drop into place while checking packages to fail if there are bundled blobs/cythonized files
<efraim>pytest-cache is no longer maintained since its functionality was integrated into pytest core starting with pytest-2.8.0.
<efraim>from their repo:
***rekado_ is now known as rekado
*rekado reboots berlin
<efraim>ah I see it's already noted in the source
<rekado>it says error: no such device: <the correct UUID>
<rekado>so, this is weird.
<rekado>after that error I’m permitted to continue, and then the system boots and /gnu is mounted from the external storage.
<rekado>we only have 400MB left on the root device but now /gnu has at least 35TB free.
<efraim>time to build all the things!
<rekado>well, I think we should also clean up the root file system.
<rekado>because the way it is now we probably wouldn’t be able to simply reconfigure the machine and reboot.
<rekado>it’s also very unfortunate that the initrd fails to find the disk and then requires a key to be pressed before it continues booting.
<rekado>so we need to reboot with serial console at this time
*rekado starts mumi
<swedebugia>:D 35TB is a lot!
<swedebugia>In trying to package ufw from git I understood that "guix download" does not download from git.
<swedebugia>to get the hash I simply tried building the package and got the hash from the failed output
<swedebugia>(ufw has no release tarballs :-/)
<swedebugia>is this the correct way to get the hash?
<rekado>swedebugia: I hope it will last long enough until we can get a storage extension.
<rekado>it could be more but we lost quite a bit of space due to RAID 6.
<swedebugia>rekado, there are 2 evaluations of core-updates in progress at berlin now. see
<swedebugia>I saw now that guix hash does support cloned git directories.
<civodul>Hello Guix!
<rekado>Hello civodul!
<rekado>civodul: we now have some extra space on berlin.
<rekado>I removed an old copy of the nginx cache, so the root file system has 11GB free now.
<rekado>I also managed to boot with /gnu on the external storage.
<civodul>35T on /gnu! \o/
<civodul>thank you rekado!
<rekado>I’ve sent you an email about some of the problems we will need to fix.
<civodul>so using the FS UUID did the trick?
<rekado>yes, but it was weird
<rekado>the initrd still complained about not being able to find the disk.
<rekado>then I was asked to press any key and the system booted just fine.
<civodul>to press any key?
<civodul>interesting :-)
<rekado>no such device: <the correct UUID>
<rekado>press any key to continue
<brendyyn>Is it all being kept? If I had enough hard drives and quota, I'd like to constanly archive all guix packages sources and builds for archival purposes.
<rekado>civodul: another problem is that the GRUB entry specifies the initrd and kernel as files starting with /store, not /gnu/store.
<rekado>so booting is currently a rather manual affair.
<rekado>(I did this over the serial console)
<rekado>brendyyn: we will see. I’d love to keep as many sources and binaries as we can.
<civodul>it's normal that it's using /store, but i understand this is problematic here since GRUB can't access the device
<rekado>I’d also like to remove /gnu on the root file system and make Guix copy the store items needed for booting.
<civodul>rekado: the difficulty is that we'd also need to clean up unneeded store items, meaning we effectively need a full-blown store
<rekado>or could it be just an extra profile?
<civodul>it looks like a store more than a profile, no?
<civodul>well i guess this needs more thought
<rekado>can’t be a profile because we can’t just link items.
<brendyyn>Is it possible to decouple /gnu/store from guix's design somewhat. On windows, most programs can be installed to an abitrary location, games and such can be installed to an external drive or some programs can be put on an SSD, but guix is stuck building up a single directory.
<kmicu>Hi brendyyn that’s not possible currently and is inherent to how guix/nix works.
<brendyyn>kmicu: I feel it's a huge pragmatic limitation
<rekado>brendyyn: if you want to store things elsewhere you could use “guix pack”.
<brendyyn>but not run them from that location?
<rekado>you can run them from that location.
<rekado>you would use a relocatable “guix pack”
<swedebugia>can I specify multiple substitutions with one (substitute* ?
<swedebugia>to the same file
<kmicu>brendyyn: It’s not a limitation but a trade-off. Eelco’s paper describes intensional store model which is more or less what you are aking for but I think we can all agree that it’s better to have something not-ideal but existing than something ideal but non-existing. ;)
<swedebugia>found an example in (define-public python-3.6 :D
<swedebugia>pack it in a good-ol lambda with a #t in the end
<brendyyn>kmicu: is the paper in here?
<rekado>swedebugia: substitute* accepts more than one substitution clause.
<rekado>swedebugia: that’s unrelated to where it’s used.
<kmicu>brendyyn: yes, it’s called “phd-thesis” ;) Basically there are a lot of security issues and the fact that software is not deterministic yet.
<rekado>I need some help with replacing “source” fields for packages that use generated github tarballs.
<rekado>there are 800+ instances left.
<rekado>I already got rid of them in some of my favourite modules.
<brendyyn>Are there other handmade tarballs that are supposed to be used?
<rekado>if there’s a developer-uploaded tarball we should use that, of course.
<rekado>but in these cases there is none, so we should use git-fetch instead.
<brendyyn>oh. why use git fetch. what's wrong the the generated tarball?
<rekado>it’s not reproducible.
<rekado>it’s just cached for a long time.
<rekado>it can disappear and be regenerated by github, so it will have a different hash.
<swedebugia>a ha. will try to figure it out :)
<brendyyn>kmicu: I was just thinking of the case where a user could install a package to a given location for their own use. if anyone else used it then it'd be produced in the store again
<Laalf>is there someone who has done some work on gnustep?
<civodul>Laalf: i don't think so
<civodul>rekado: BTW, could you take a look at the email i sent about bayfront on guix-sysadmin?
<efraim>python2-futures' test-suite is driving me crazy
<Laalf>civodul: gnustep-make is packaged. i thought about doing base and maybe more but i found out that libz doesnt seem to be packaged.
<joshuaBPMan>maybe I'm being dumb, but I'm trying to export my guix build options in my bash_profile.
<joshuaBPMan>I'm getting this error:
<joshuaBPMan>guix package: error: extraneous argument
<joshuaBPMan>I wonder why that would be.
<rekado>Laalf: it’s called “zlib”.
<Laalf>rekado: so i would do something like ("libz" ,zlib) in inputs? shouldnt this produce problems with the license?
<Laalf>WARNING: (gnu packages gnustep): `openssl' imported from both (guix licenses) and (gnu packages tls)
<Laalf>guix build: error: gnustep.scm:70:2: package `gnustep-base@1.15.1' has an invalid input: #<<license> name: "Zlib" uri: "" comment: "">
<efraim>Laalf: in many modules, the licenses are imported with the license prefix
<rekado>Laalf: the first part of each input is just a label. It could be anything.
<rekado>Laalf: because of the fact that there is a zlib value that is a license we usually prefix license values with “license:”
<Laalf>rekado: i dont quite get how to get around that.
<Laalf>ah i got it
<rekado>civodul: the one about certbot on bayfront failing? I’ll take a look at this today.
<Laalf>how can i find out why my guix system reconfigure is stuck?
<rekado>Laalf: you could post the error message here if you get one.
<Laalf>rekado: its just stuck at usermod: no changes for 2 hours
<rekado>that shouldn’t happen.
<Laalf>rekado: i guessed. is there something like --stack-trace?
<rekado>if you’re curious you could attach strace to the daemon
<Laalf>rekado: how would i do that?
<cbaines>Laalf, is is still stuck?
<Laalf>cbaines: yes
<cbaines>Laalf, if you want to try using strace, I normally run it from htop
<Laalf>cbaines: i dont know how to use strace
<cbaines>Run htop as root, use the arrow keys to highlight the right proccess, and press the s key
<Laalf>ah alright
<cbaines>Laalf, strace will show you the system calls that are being made, which might give you a clue as to what it's stuck on
<Laalf>that doesnt help me
<Laalf>should i guix system init?
<thorwil>hi guix!
<xrogaan>is this the right channel for elogind?
<cbaines>Laalf, could you cancel the reconfigure, and try it again?
<Laalf>cbaines: ye i did that
<Laalf>i should delete everything but /gnu and /home and init. /afk for 15 minutes
<rekado>Laalf: this is rarely a good idea.
<xrogaan>Well, I'm going to trust the elogind readme and ask my stupid question. Is it elogind that is responsible for creating the /run/user/$UID/ folder?
<Laalf>rekado: what do you recommend?
<xrogaan>Because sometimes that folder isn't created and there is no log or error I can read to point me to an understanding of the cause. I'm currently running devuan ascii.
<civodul>xrogaan: it is, yes
<thorwil>hmm, i can't `git pull` anymore: "fatal: unable to access '': Problem with the SSL CA cert (path? access rights?)"
<xrogaan>When the /run/user/$UID/ folder isn't being created, loginctl will returns nothing in the list of sessions.
<xrogaan>devuan seems to be using elogind 234.4 (+PAM +SELINUX +SMACK +UTMP +ACL default-hierarchy=legacy)
<rekado>Laalf: I recommend figuring out what’s wrong, to see if it’s just busy or actually hung e.g. with strace.
<xrogaan>is it possible to have elogind to be a bit more verbose with what it is doing?
<thorwil>nevermind, i introduced a typo in my .profile, regarding GIT_SSL_CAINFO :/
<Laalf>rekado: 0% CPU, 0% io. Strace says nothing
<rekado>Laalf: pgrep -fa guix should show you Guix processes.
<rekado>you can then attach to them with “strace -f -p PID” where PID is the PID of the process you want to attach to.
<thorwil>would folks here prefer a package of the lv2 port of the calf plugins to be called caps-plugins-lv2, or just caps-lv2?
<rekado>thorwil: I’d prefer “caps-plugins-lv2” but either is fine.
<rekado>“calf” already provides lv2 plugins, though.
<Laalf>rekado: ppoll([{fd=-1}, {fd=6, events=POLLIN}], 2, NULL, NULL,
<rekado>Laalf: which of the processes are you attached to?
<Laalf>rekado: sudo guix system reconfigure config.scm -K -c 8 --fallback
<Laalf>rekado: /gnu/store/p9wm67w3rfw3hlb9iljgvsfn84mz4w9d-guile-2.2.4/bin/guile --no-auto-compile /home/lars/.config/guix/current/bin/guix system reconfigure config.scm -K -c 8 --fallback shows [pid 25792] read(15,
<rekado>Laalf: can you share your config.scm?
<Laalf>rekado: i changed nothing but the mounts. even if i comment out the mounts it doesnt work
<rekado>Laalf: why do you define a module?
<Laalf>rekado: i think thats easier to define packages in there.
<Laalf>like my kernel because my bios has a whitelist so i cant use libre kernel with my wifi card
<rekado>you don’t need a module to refer to custom packages in the same file.
<rekado>the configuration is not supposed to be a module.
<Laalf>does it harm anything? as said: the config worked before
<rekado>oh, I missed that it worked before.
<rekado>I only saw that you mentioned that it hung.
<rekado>so, you made no changes whatsoever and reconfigure hangs on the very same configuration file?
<Laalf>rekado: you see that i have a service which saves my config. if i use that config that is saved (so the system worked) it hangs
<Laalf>ill be afk again but still interested in ideas...
<civodul>rekado: is 500 :-)
<rekado>I see a backtrace, but it’s so long that it goes beyond the default screen buffer…
<civodul>nice! people often complain about terse backtraces ;-)
<rekado>looks like it’s something to do with the recent switch to guile-email.
<rekado>I got a list of mime-entries when I expected a string… Will fix it.
<civodul>static type checking FTW!
<rekado>tests FTW!
<cbaines>I've been trying to reinstall Guix on a machine this afternoon, and I've made some process, but some things are a bit odd
<cbaines>I noticed it compiling some Guile code during boot, and running guix pull, it's compiling more Guile code, including stuff from the store in the guile-2.2.4 and guix-0.15.0-6 packages
<cbaines>During guix pull, it also output a warning relating to the failed compilation of gnu/packages/commencement.scm
<cbaines>seemingly due to a stack overflow
<civodul>cbaines: lots of weirdness!
<civodul>why did you reinstall it in the first place?
<cbaines>Hardware change, swapping out the previous root 250GB M.2 drive for a 1TB M.2 NVMe drive
<civodul>oh ok, i thought that was because of buggy behavior or something
<civodul>you enabled substitutes and all?
<cbaines>Installing seemed to use substitutes
<cbaines>I think something has just not worked quite right during the installation
<cbaines>Running guix, with no arguments prints out...
<cbaines>;;; note: source file /gnu/store...-guile-2.2.4/share/guile/2.2/ice-9/eval.scm
<cbaines>;;; newer than compiled /gnu/store/...-guile-2.2.4/lib/guile/2.2/ccache/ice-9/eval.go
<civodul>did you enable offloading?
<civodul>could you check the mtime on these two files?
<Laalf>ill now be guix system initing. wish me luck
<cbaines>civodul, I'm not doing offloading
<cbaines>I'm guessing ls -l shows mtime... if so, about an hour ago, for both files
<cbaines>that's not usual is it? It should be 1970...
<civodul>cbaines: it should be 1970 indeed
<civodul>is it coming from a binary tarball?
<cbaines>I installed using the USB installer, I downloaded that this weekend
<apteryx>Is it me or Github stopped working with our Icecat?
<cbaines>It took me a number of attempts to successfully install, first I booted the wrong partition from the USB installer, so I ended up without EFI support
<apteryx>I mean, I cannot seem to select a tag with the branch button, and earlier they showed me some warning about now only supporting latest chrome, firefox and safari
<cbaines>So I did end up running guix system init a number of times before it finished successfully
<apteryx>ah, just maybe there's *no* branch:
<apteryx>nope, really seems broken
<apteryx>thanks, microsoft ;)
<nly>Hi apteryx :-)
<apteryx>nly: hi :)
<nly>Are you perhaps looking into gnunet?
<nly>Just curious :) hope i can learn fron you
<apteryx>nly: today, I am trying to fix a libssh bug. Will start by enabling tests for libssh; I need to add 'cmockery' for that.
<nly>Yay :D
<nly>Got it
<nly>Thanks :-)
<apteryx>nly: no problem. I started watching 'the mother of all demos'; truly impressive for 1968 :-)
<nly>Is guix working for any arm boards? I want to use it for a low power personal server
<thorwil>what does native-search-paths do? any chance an lv2 package would _not_ need it?
<thorwil>seeing a bunch of these: (native-search-paths (list (search-path-specification (variable "LV2_PATH") (files '("lib/lv2")))))
<apteryx>nly: I think it does for a few! You'll probably have an idea by looking at the bootloaders available (they are often platforms specific for ARM IIUC).
<apteryx>thorwil: search-path-specifications will make it so that the variable specified (LV2_PATH) in your case will be assigned to any package directory that has the file "/gnu/store/...some-package/lib/lv2") in it.
<thorwil>apteryx: i'm puzzled why this doesn't appear for ladspa plugins and ... "native" implies it's (also?) a built-time thing, right?
<apteryx>thorwil: yes, 'native' would be honored at build time only, if I'm not mistaken.
<thorwil>ok, guess i'll just try if it stumbles over a lack of that, then :)
<apteryx>when you build, look at the log, you should see the value LV2_PATH was set to.
<apteryx>(at least the gnu-build-system does so).
<thorwil>I found talk about making `guix download` work with git, also taking a commit ... but that hasn't been implemented, right?
<nly>Ok thanks
<mbakke>The WebkitGTK documentation commit broke webkitgtk@2.22.
<mbakke>If I make it inherit the new phases, it fails to generate documentation late in the build.
<rekado>civodul: fixed the mumi bug.
<thorwil>guix lint complains: "the source file name should contain the package name". vs caps-plugins-lv2
<thorwil>should i leave it at (define-public caps-plugins-lv2 ...) but change the name to caps-lv2, then?
<rekado>thorwil: better keep it consistent.
<rekado>caps-lv2 will be fine.
<thorwil>ok then
<mbakke>I think I have a fix for webkitgtk, testing it now.
<thorwil>eek, i still get "gnu/packages/audio.scm:522:5: caps-lv2@0.9.24: the source file name should contain the package name"
<rekado>did you specify (file-name (git-file-name name version)) ?
<thorwil>rekado: no, git-reference with url and commit
<rekado>please add this field
<thorwil>ah, now i see
<rekado>git downloads otherwise look ugly.
<thorwil>guess lint should complain about the missing field, then
<thorwil>happy lint, thanks rekado!
<thorwil>hash mismatch. i take it `guix hash -r caps-lv2` where caps-lv2 was the result of `git clone ...` isn't the right way?
<thorwil>of course there is an example at
<apteryx>is there a reason why we don't update our libssh to the 0.8.x series instead of 0.7.x?
<amz3>civodul: you just sent an email with a large sql query, can you tell me in which file it is used, please?
<amz3>got it
<amz3>it's database.scm
<amz3>btw how big is the sqlite database file right now?
<pkill9>how do i test a change made in a clone of the git repository of guix?
<cbaines>pkill9, what's the change?
<amz3>pkill9: ./pre-inst-env guix package -i package-fu
<pkill9>how do I create the pre-inst-env wrapper?
<pkill9>do i just need to run the ./bootstrap?
<amz3>follow the readme, basically: ./boostrap && ./configure --with-state-dir=/something && make -j4
<amz3>pkill9: you changed a package, correct?
<pkill9>cbaines: i'm changing the xonotic package so the data is symlinked instead of copied, so whenever any dependencies of xonotic are changed, it doesn't redownload all the data
<pkill9>also i have a bunch of other packages i want to add
<pkill9>but right now that's what I'm doing as it's the simplest change
<rekado>amz3: the db is 1.6GB. I think that’s a little too big.
<pkill9>ok amz3, I didn't read that one, i read the 'contributing to guix' pages, and 'HACKING'
<pkill9>so should i set localstatedir to '/var/guix'?
<rekado>to /var
<cbaines>pkill9, sounds good, for testing a change to a package, I'd suggest building it with guix build, and also running guix lint
<pkill9>do i need to run 'sudo -E ./pre-inst-env guix-daemon --build-users-group=guixbuild' before testing?
<cbaines>pkill9, you'll need a running build daemon
<cbaines>if you're on GuixSD, then this is fine
<pkill9>oh ok
<pkill9>yeah im on guixsd
<cbaines>and by "this is fine", I mean you don't need to do anything with the build daemon
<amz3>also I think mozilla is moving away from sqlite, I can't find the link tho.
<amz3>they are tips in the above link to fine tune sqlite
<luciddreamz>calling bullcrap probably due to their CoC
<luciddreamz>sqlite's CoC is non-conventional
<cbaines>They use the Mozilla Community Participation Guidelines, anyway, this is offtopic
<luciddreamz>who uses the Mozilla Community Participation Guidelines?
<cbaines>The SQLite project
<luciddreamz>not AFAIK
<cbaines>That was what they listed as the Code of Conduct, but it changed
<luciddreamz>figured that would happen eventually
<rekado>civodul: I’m looking at bayfront now and I can reproduce the certbot error.
<rekado>civodul: but I don’t see any uncommitted changes to the configuration.
<pkill9>hmm I just got an error relating to the output of guix: ERROR: In procedure make-string:
<pkill9>Value out of range 0 to 18446744073709551615: -51
<rekado>yes, got that too
<pkill9>something to do with the progress bar
<rekado>see bug 33030
<rekado>it probably works fine when running the command again
<rekado>civodul: oh, easy! bayfront used to host but no longer does. So I just need to remove the cert from there.
<civodul>rekado: cool, thanks!
<civodul>there's znc running on bayfront, right?
<civodul>at some point we should make a service
<rekado>yes, the logs are collected via znc
<cbaines>I've just tried starting the installation again... I'm in the installer at the moment, but it doesn't look promising
<rekado>it’s very ad-hoc, I have to admit.
*rekado –> zzZ
<cbaines>at least in ls, the timestamps on the files in /mnt/gnu/store are all from a couple of minutes ago
<cbaines>I thought the timestamps for files in packages where changed by during the build...
<cbaines>civodul, the timestamps in the target store seem to correspond to when guix system init is run
<civodul>cbaines: doh!
<civodul>could it be that 'guix system init' no longer resets timestamps?
<cbaines>seems so
<cbaines>looking at the code, copy-closure calls copy-item, which calls register-path, and a comment claims that register-path should reset timestamps
<civodul>i changed a couple of things in this area recently...
<civodul>cbaines: seems to work for me
<civodul>i tried this: ./pre-inst-env guix system init gnu/system/examples/bare-bones.tmpl /tmp/system
<civodul>(as non-root)
<civodul>which copies all the store items to /tmp/system
<civodul>and everything is Jan. 1970
<cbaines>I think this may relate to running guix system init more than once... maybe try again?
<cbaines>There's a guard for reset-timestamps in guix/store/database.scm, (path-id db to-register) is tested
<civodul>cbaines: indeed! running a second time breaks all the timestamps
<cbaines>is there something I can remove or tweak to make it reset the timestamps?
<civodul>you mean in the code or to salvage your installation?
<cbaines>The latter
<civodul>you can probably do something like "find -L -name \* -exec touch -t 197001010000.01 {} \;"
<civodul>cbaines: i've pushed a fix