IRC channel logs

<ecbrown>how are you all adding .desktop icons to gnome on foreign systems? can the path to them be extended, or perhaps softlinks?

<ecbrown>(i know that ~/.local/share/applications is a place to put them)

<pkill9>ecbrown: you add <guix-profile-path>/share/ to your $XDG_DATA_DIRS in your ~/.profile

<pkill9>then gnome will look for .desktop files in <guix-profile-path>/share/applications i think

<pkill9>s/add/append

<ecbrown>ok, thanks. didn't get it on the first try, but i think i see that this is the variable to set

<ecbrown>pkill9: works if i set it in /etc/profiles

<ecbrown>tyvm

<ecbrown>awfully hard to tell the difference between debian stable and testing when guix is installed :-D

<ison111>How might I figure out why a go-build-system package is failing? I'm trying to build "gomuks" but it just says build phase starting and then "build failed", nothing more.

<mange>Are you using "guix build" to build it? (As opposed to trying to "guix package -i" it.)

<ison111>mange: I was doing guix package -f

<mange>Try using "guix build -f" instead. Recently a change was pushed that suppresses a bunch of output in build that occur from "guix package".

<mange>You can also use --keep-failed to keep the build directory around so you can take a look at it. I think it prints the location that it saves the build directory to.

<ison111>mange: ok thanks, that prints out a lot more info

<ison111>Ah, found the problem. I guess gomuks requires go version 1.10. Will try again in the future.

<mange>There is a go-1.10 package (looks like 1.10.3).

<mange>I don't know anything about the go-build-system, but I imagine if you specified it as an input with ("go" ,go-1.10) in your inputs list, it might use 1.10 instead?

<ison111>It still used 1.9 to build with

<mange>Can you try adding #:go go-1.10 in your #:arguments list?

<mange>I'm not confident it will work, but I just checked the build system code and it's worth a shot.

<apteryx>What was the Guile library for describing a regexp using proses?

<apteryx>oh, no, maybe I'm confusing with Elisp

<ison111>mange: With that it says invalid input "go". It's alright though I don't mean to cause you trouble. I can wait for the default to update to version 1.10 or maybe play around with it myself later.

<mange>Can you paste the definition you're trying with the link in the channel description?

<ison111>mange: https://paste.debian.net/1042719/

<mange>Give this a go: https://paste.debian.net/1042721/

<mange>Basically what I did is remove the "go" input (because it will be added implicitly by the build system), and change the string "go-1.10" to instead put the go-1.10 package object into the arguments (which requires using , to unquote it).

<mange>That builds on my machine, so hopefully it will build for you.

<mange>It doesn't run for me, though, but I'll leave it to you to work out why.

<lfam>mange, ison111: The go-build-system will work with Go 1.10, but less efficiently than with Go 1.9. No news yet about Go 1.11

<mange>What do you mean by "less efficiently"?

<lfam>mange: In Go 1.10, the method used by the Go compiler to determine when a dependency needs to be rebuilt was changed. Guix's go-build-system hasn't been updated to handle this, so every Go-language dependency will be rebuilt for each package. No compiled objects are re-used

<lfam>The new technique is called "content-based staleness", if you'd like to read about it. On the surface it's basically the same thing as Guix, a memoized cache of compiled objects

<apteryx>anyone having issues with guix offload on recent guix?

<apteryx>The backtrace looks like this: http://paste.debian.net/1042726/; guix offload test fails hinting at the Guile modules, but I verified that this is correctly set.

<apteryx>(and I have a 2nd machine for which offloading works normally using a similarly configured ~/.bashrc)

<apteryx>I need to get some sleep, but feel free to respond :)

*apteryx zzZz

<ecbrown>apteryx: yes, i have the same issue, some machines that do work, some don't. i see references to /usr/local/etc/guix/machines.scm iirc. i could swear that the machines are set up similarly, though i have not been systematic otherwise i'd be able to fix it/make a good bug report.

<ecbrown>i think i have a system that builds remotely, but guix offload test doesn't work

<civodul>Hello Guix!

<sneek>Welcome back civodul, you have 1 message.

<sneek>civodul, atw says: my channel is working perfectly!

<civodul>cool

<roptat>hi guix!

<janneke>civodul: re your first question, on the difference between -s i686-linux and native, this is the current status: http://paste.debian.net/1042743

<janneke>until gettext-boot0 there are no differences; i rewrote all earlier packages from using `package-with-explicit-inputs' to (arguments (#:implicit-inputs #f ...

<janneke>did that mainly to check if there is a problem with package-with-explicit-inputs, and that seems the case

<janneke>i could rewrite the remaining bootstrap packages too and we could remove package-with-explicit-inputs, or package-with-explicit-inputs could be fixed and the other rewrites can be reverted. WDYT?

<civodul>janneke: seems to me that we should fix package-with-explicit-inputs

<civodul>do you think you could report the bug?

<janneke>hmm i hope so but am not 100% sure, i will have a look at that!

<thorwil> ("glib" ,glib "bin") is the way to satisfy a dependency on glib-gettextize?

<rekado>Hi Guix!

*rekado is rarely online because of a big lab evaluation this week

<civodul>hey rekado!

<civodul>good luck with the evaluation

<jlicht>hey guix

<civodul>heya jlicht

<civodul>hey roptat, how's the bittorrent adventure going? :-)

<roptat>civodul: I didn't work on it since last time

<roptat>so still crashing after getting a few pieces

<efraim>how have I not known about 'umount -R'

<efraim>so much easier than finding all the mount points

<civodul>heh

<roptat>is there anything I should be carefull about when using (let loop ...)?

<civodul>non termination? :-)

<roptat>that's basically what I wanted to do though

<roptat>but it doesn't seem to work :p

<roptat>it stops at some point without any error message

<roptat>but the code on the main thread is (let loop ... (loop ...)) with no condition

<roptat>so I don't get why it exits the main thread

<civodul>uh

<civodul>hard to tell without looking more closely at the code

<civodul>it's usually easier to achieve non-termination than to make sure you avoid it :-)

<mbakke>civodul: Do you have an idea how to distribute patches in channels?

<mbakke>(search-patch ...) etc fails because the channels are not on %load-path.

<snape>mbakke: why don't you reply to https://lists.gnu.org/archive/html/guix-devel/2018-09/msg00085.html?

<mbakke>snape: I wanted to set up a channel first :)

<civodul>mbakke: it works for me, though the file name of patches is relative to the top of your channel

<mbakke>civodul: Oh.

<snape>then you just need to say it. No big deal :)

<civodul>snape: that's a bit rude :-)

<snape>civodul: I find rude when nobody replies emails

<civodul>but yeah, i hope we can get out of the browser quagmire soon

<mbakke>Did anyone try packaging the new IceCat yet?

<snape>civodul: email communication is inherently difficult. Non-communication is worse

<civodul>snape: yes but since it's a volunteer effort and mbakke already has a lot on his plate, i think we can't blame him for not replying in a timely fashion

<civodul>i'm saying this as someone who sometimes just doesn't get to read email in time

<snape>Replying "I'm busy" takes 20 seconds.

<civodul>yeah i know

<civodul>but sometimes it's harder that it seems (speaking for myself)

*rekado looks nervously at his overflowing email inbox

<snape>anyway mbakke, sorry if I sounded rude, I just needed to understand, which I did. Now please, take your time :-)

<mbakke>snape: No worries, I've been too busy to register your loss of patience ;-)

<janneke>civodul: bug report sent

<civodul>great, thank you janneke!

<mbakke>I'll send an update for Chromium 69 today, and will start working on Ungoogled next.

<pkill9>mbakke: where is a link to the new icecat?

<snape>thank you very much for you work mbakke

<pkill9>i can't find it

<snape>pkill9: http://git.savannah.gnu.org/cgit/gnuzilla.git/log/

<pkill9>thanks

<apteryx>hmm, on a freshly booted GuixSD, pidof guix-daemon returns two processes; is this expected?

<civodul>apteryx: yes: guix-daemon spawns a child process for each client

<apteryx>and it seems that 'sudo strace -p "either-guix-daemon-pid" -f' is not picking any activity.

<apteryx>civodul: OK!

<civodul>if you look at the child process, its argv[1] is the PID of the client

<apteryx>interesting; I didn't know that using 'guix environment' spawned a guix-daemon instance.

<civodul>'guix environment' opens a connection to the daemon, which spawns a child process to handle it

<apteryx>I see. Thanks for the explanation! strace is helpful again now that I'm tracking the right guix-daemon :)

<apteryx>I'm struggling a bit with guix offload again, on one machine :/. It was working fine until I updated guix on it recently. Strange thing is that doing 'guix offload test /etc/guix/machines.scm 127.0.0.1' to test it result in *zero* activity in either my or the remote machine's guix-daemon. It fails with: http://paste.debian.net/1042776/

*janneke goes to play with new learned guix repl skills to try create more insight into his own bug-32749

<janneke>...but still flabbergasted--package-inputs, package-native-inputs, package-propagated-inputs do not reveal anything interesting

<civodul>apteryx: could it be that guile-gcrypt isn't in GUILE_LOAD_PATH on the target machine?

<civodul>unfortunately the ~/.config/guix/current profile doesn't propagate it

<myglc2>Hi #guix! avahi stopped working after recent 'guix system reconfigure'. E.g., host g1.local gone but var/log/debug contains "avahi-daemon[412]: Server startup complete. Host name is g1.local. Local service cookie is 1956729094." shows '.

<myglc2>Anyone else had this problem?

<apteryx>myglc2: my hostname apteryx.local still pings. I'm on Guix 50b3b831430902224864dbd350179a564561f526.

<apteryx>sneek: later tell civodul I installed guile-gcrypt on the target offload machine, but sadly didn't help.

<sneek>Okay.

<apteryx>sneek: botsnack

<sneek>:)

<ecbrown>apteryx: i wonder if this has something to do with what is placed where, in .bash_profile, .bashrc, .zshenv, .zshrc...

<pkill9_>out of interest, does Cuirass have any limit for Guix pulls? e.g. does hydra build a package from a very old version of guix if a substitute for that package is requested?

<pkill9_>limit for guix pulls meaning limit of number of compiled guix's

<snape>pkill9_: Cuirass (and hydra) evaluations aren't triggered by guix pulls, they triggered by commits git repositories.

<snape>old evaluations are garbage collected, so if a substitute for an old package is requested, it might not be available anymore

<myglc2>apteryx: Thanks. I used the next commit on master, b2c8d31ff. So I am puzzled.

<snape>by commits *in git repositories

<tune>can anyone recommend something that's already packaged that I can use for designing rooms? like input measurement of my bedroom and then simulate new furniture or walls

<tune>I think I might want a CAD thing for this, but I'ven ever really done it before

<tune>I'll try librecad

<rekado>boost fails to build on core-updates

<tune>hm not sure if librecad is what I want for room design since it's 2D, but freecad doesn't seem to be packaged

<mbakke>rekado: Boost 1.59?

<mbakke>vejetaryenvampir: Why, of course :-)

<ecbrown>chromium running! tyvm mbakke

<mbakke>ecbrown: Nice! :-)

<thorwil>tune: freecad is indeed not packaged. blender would be an option, though the initial hurdle before you get anything done is high

<rekado>tune: there’s also libfive, which provides the “Studio” executable, a 3D CAD studio where you design objects through Scheme code.

<rekado>it’s probably not close enough to what you’re looking for, but it might be a simpler alternative to using Blender for this.

<rekado>mbakke: looks like I got confused by the build output.

<rekado>mbakke: glib 2.56.2 fails.

<rekado>this causes graphviz and thus wayland to fail.

<rekado>(this is on berlin.guixsd.org)

*rekado clears the cached failure

<mbakke>rekado: glib has a tendency to fail indeterministically :/

<tune>rekado: I'll install libfive, thanks

<davexunit>I tinkered with libfive. it's fun, but not really a tool that can help you design things you will build.

<davexunit>I wish there was a free tool like sketchup

<tune>yeah, a free tool like sketchup is basically what I want

<tune>sweethome3d looks pretty good, but it's not packaged

<davexunit>iirc librecad is 2d only, so that was out

<davexunit>freecad works, but is so damn hard to figure out I gave up

<davexunit>I had the most success with libfive studio because I like to write Scheme, but it needs ways to texture the various shapes so that you can make a meaningful object.

<tune>I have very little knowledge of scheme, so if that's an important requirement, I probably won't get anywhere

<davexunit>yeah, it is. I imagine it will be difficult for you, then, especially since the docs are so sparse

<tune>darn

<davexunit>I read the source code to discover lots of things

<tune>oh god... that bad

<thorwil>davexunit: freecad is a bit messy, but i'd say much of the difficulty is inherent to parametric solid modeling

<davexunit>it's just very young software

<tune>well, I'll leave it installed and maybe come back to it when I'm wiser

<davexunit>the other issue is that libfive is really designed to the serve the function of a tool like sketchup

<davexunit>I want a tool that help me generate woodworking plans

<davexunit>that can output all the measurements and such, but libfive can't do that.

<davexunit>but I do like writing the object as code, because I can make all of the various measurements variables and then tweak them and have everything adjust the correct amount.

<davexunit>thorwil: are you saying that there are other modeling methods that are better?

<davexunit>I don't know anything about CAD really. I just know that tools like freecad and tools like libfive use very different modeling techniques.

<davexunit>my brief experience with freecad was figuring out how to satisfy a bunch of constraints so that it would stop yelling at me

<davexunit>soooo... my design tool for now is just graph paper.

<thorwil>davexunit: no, the best choice of modeling method depends on the specific project. what i mean is that parametric solid modeling is somthing one has to get used to

<davexunit>I found the UI itself very difficult to navigate

<davexunit>I think if it were friendlier it would be easier to learn the important stuff

<thorwil>davexunit: agreed. it's that way partly because of combining lots of different but related areas, partly because ... many cooks :)

<davexunit>yeah

<davexunit>that's kind of what it felt like

<davexunit>still seems like the best thing available

<davexunit>I'm just going to stick to a combination of graph paper and winging it, though.

<davexunit>I'v been taking a woodworking class where all the projects were designed in sketchup and the source files are provided in case you want to make edits. I have no desire to write something capable of loading sketchup files but I wish someone would!

<dustyweb>hekc yeah chromium channel!

<dustyweb>also

<dustyweb>the words of caution in the guix info manual are great and welcome

<dustyweb>omg

<dustyweb>so cool

<dustyweb>mbakke: THANK YOU for this!

<davexunit>ooh there's a chromium package now? last I searched it wasn't in the package list yet

<lfam>It's from a "channel"! https://gitlab.com/mbakke/guix-chromium

<davexunit>whoa those exist now? since when?

<mbakke>dustyweb: You're welcome! :-)

<lfam>A week or two? The kinks are still being worked out. https://git.savannah.gnu.org/cgit/guix.git/commit/?id=0d39a3b98948314e135566b9315717695a9035ea

<mbakke>davexunit: Work is ongoing to get "ungoogled-chromium" into Guix proper.

<mbakke>For now we have a channel :-) now, who wants to provide substitutes..

<dustyweb>davexunit: yeah, and check the list, mbakke added a chromium channel :)

<dustyweb>now I can not be so scared about being so behind on patches...

*janneke is working through most of the initial wip-bootstrap review by civodul and creating patches

<davexunit>dustyweb: neat!

<davexunit>the design of channels is really cool!

<davexunit>someone should write a blog post about it

<davexunit>mbakke: excited to hear it!

<davexunit>chromium and a new firefox would be so good

<RetardedOnion>is there something like nix's automatic upgrade system planned?

<pkill9_>it would be neat to be able to specify substitute urls for channels in channels.scm

<pkill9_>so it would be like debian PPAs

<pkill9_>i think that's what they're called, not sure actually

<lfam>AFAIK, Debian doesn't use PPAs, but Ubuntu does

<lfam>But yeah, that is a good next step

<lfam>RetardedOnion: What is Nix's automatic upgrade system like?

<RetardedOnion>lfam: actually i dont know. i prefer to upgrade it myself, but i like the idea of making upgrades automatic for getting to the users. it creates a systemdserver

<RetardedOnion>s/server/service/

<lfam>In general, I'm sure an automatic / unattended upgrades service would find some users. As far as I know, nobody is working on it right now

<RetardedOnion>well i guess that should be a problem when we got more "casual" users. so after a graphical installer

<lfam>Yes, but if someone is interested in working on it now, they should go ahead :)

<RetardedOnion>i am not stopping anybody

<thorwil>any pointers on what to do regarding aclocal, m4 macros? trying to package the resynthesizer plugins for gimp. build warnings and error: https://bpaste.net/raw/2fa7e68a1806

<lfam>thorwil: I'm a little confused about the shebang issue. It should be handled by the gnu-build-system's bootstrap phase. Does your package definition use the gnu-build-system? Does it override the built-in bootstrap build phase?

<lfam>As for the gettext warnings, you might try adding gettext-minimal to the build environment

<thorwil>lfam: yes, (build-system gnu-build-system), no overrides yet, as i have no clue whyt may be necessary

<lfam>thorwil: My first read of your paste was pretty loose. I'm not sure how exactly to interpret the line with the shebang error. Is autogen.sh running configure in the bootstrap phase?

<lfam>If 'configure' already exists, it's probably not necessary to bootstrap

<thorwil>lfam: seems to me phase 'bootstrap' starts with autogen, then configure. no other phase entered

<lfam>thorwil: The gnu-build-system phases go like this: [...] bootstrap, patch-usr-bin-file, patch-source-shebangs, configure [...]

<lfam>(see guix/build/gnu-build-system.scm)

<lfam>I'm not an Autotools expert but I don't think the configure script should be run in the bootstrap phase. It needs to be run after patch-source-shebangs

<thorwil>seems i have to look at that autogen.sh

<thorwil>so it contains: $srcdir/configure --enable-maintainer-mode $AUTOGEN_CONFIGURE_ARGS "$@"

<thorwil>why is there even a phase bootstrap, when https://www.gnu.org/software/guix/manual/en/html_node/Build-Systems.html doesn't list one for gnu-build-system?

<lfam>thorwil: The bootstrap phase was recently added. The online manual is static; it always reflects the last release.

<lfam>I'll check that the latest manual mentions it

<thorwil>do i have to patch that autogen.sh? (which i would expect to happen in a phase after unpack, but apparently not)

<lfam>Also, that list only mentions the "notable" phases

<civodul>thorwil: you can use (autoconf-wrapper) instead of autoconf as an input; that will produce a valid shebang

<sneek>Welcome back civodul, you have 1 message.

<sneek>civodul, apteryx says: I installed guile-gcrypt on the target offload machine, but sadly didn't help.

<thorwil>ah, that makes quite a difference. thanks lfam, civodul

<amz3>hello guix!

<amz3>you might not be already aware guile 3.0 is coming...

<amz3>not today, nor tomorrow

<amz3>but one day :]

<amz3>there will be a jit this time, 80% faster than guile 2.2 for the time being

<amz3>nckx: what do you mean "lack of results"?

*amz3 backlogged about mumi

<amz3>I did not look at the code of mumi yet

<amz3>am i voiced?

<civodul>hey amz3, you're voiced (or vocal? :-))

<amz3>^^

<mbakke>ng0: By the way, "xfsprogs" can now be packaged on core-updates with little effort.

<mbakke>Finding the commit that enables that is left as an exercise for the reader.

<rekado>oh, I think I packaged it some weeks ago but never submitted it.

<mbakke>rekado: Really? Nice job, I had a lot of trouble with it.

<lfam>It would be cool if we offered XFS support on GuixSD out-of-the-box

<rekado>I remember that there were some test failures.

<rekado>I’ve got a whole bunch of package drafts that rot in my git stash. I’m close to declaring git stash bankruptcy :)

<mbakke>lfam: I'd like to use XFS on GuixSD too. Hopefully it won't blow up the initrd too much...

<rekado>my primary goal was actually to get to a multipathd service, and to test that I first had to access a file stored on an XFS file system from a RHEL server where we had that set up…

<mbakke>F2FS support would be nice too.

<lfam>rekado: I've done it before

*mbakke compulsively adds package drafts in branches

*lfam reboots with core-updates

<mbakke>`git branch | wc -l` -> 131 :P

<amz3>oh

<ng0>who what

<ng0>ah yes I tried that many months ago. cool

<lfam>I also have a ton of branches :p

<ng0>since i started working more focused on my own thing with a different layout it's easier.. i just have one guix branch and apply code when I send it to guix :) i still have a huge backlog of the over 70 branches.

<ng0>chromium 69 is hard for my builder

<amz3>u no finish your work?

<ng0>what

<amz3>nevermind. just chat.

*amz3 going to bed

<mbakke>civodul: Do you think we can start core-updates on Hydra?

<ng0>well sometimes you get stuck. or life happens, etc. and sometimes you do weird shit like every now and then I pick up ancient code like uwm and try to make it build with 2018 software

<ng0>mbakke: feel free to add xfsprogs, I have exams upcoming in 10 days or so.. would only work on it next month.

<mbakke>ng0: Ok!

<rekado>mbakke: oh, is it not build on Hydra?

<mbakke>rekado: I'd be interested in seeing your patch for xfsprogs :-)

<rekado>I thought that was the idea behind freezing it.

<mbakke>rekado: Only the 'core' subset.

<mbakke>I.e. just up to hello and some other things.

<rekado>ah, I see.

<rekado>FWIW glib has been built on berlin, and also wayland

<ng0>(reminder to self: rebuild the builder with a swap instead of wondering about oom)

<ng0>but chromium 69 can still be build with 8 GB RAM + swap

<civodul>mbakke: TBH i haven't been paying much attention to Hydra lately, but i think we can try

<civodul>you mean the full build? or the "core" subset?

<mbakke>civodul: I mean the full build.

<civodul>ok

<civodul>mbakke: started now!

<mbakke>civodul: Yay! :)

<lfam>My "headless" Thinkpad rebooted on core-updates, now I'm testing the users' `guix pull`s

<ng0>ah, you probably mean the util-linux related commit.

<mbakke>ng0: That was fast :-)

<ng0>tempted to give it a try, one of my xfsprogs should be fast to locate

*civodul -> zZz

<civodul>good night/day!

<mbakke>lfam: I think we should switch to OpenSSL 1.1 in the next core-updates cycle.

<mbakke>Also, what's up with that imagemagick branch.

<lfam>mbakke: Agreed re: OpenSSL

<lfam>I deleted the Imagemagick branch from Savannah because nobody was working on it.

<lfam>Basically, someone needs to test the applications that use Imagemagick's "command-line API" and make sure they still work

<lfam>But, it's not urgent. Imagemagick 6 will be maintained for something like 10 more years

<mbakke>lfam: It would be nice to have ImageMagick 7 around though.

<mbakke>I still have the branch and will try to add it but keep consumers on 6 when I find the time.

<lfam>Yes, we could package it as imagemagick-next, like with OpenSSL

<mbakke>Exactly.

*jonsger gives wip-bootstrap a shot

<ng0>mbakke: latest xfsprogs builds alright. got to fine tune a bit etc

<ng0>that is, just the dyn. link version so far

IRC channel logs

2018-09-17.log