IRC channel logs


back to list of 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
<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>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?
<mange>Give this a go:
<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:; 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!
<roptat>hi guix!
<janneke>civodul: re your first question, on the difference between -s i686-linux and native, this is the current status:
<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
<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>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
<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
<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' to test it result in *zero* activity in either my or the remote machine's guix-daemon. It fails with:
*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.
<apteryx>sneek: botsnack
<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
*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
<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>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>the words of caution in the guix info manual are great and welcome
<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"!
<davexunit>whoa those exist now? since when?
<mbakke>dustyweb: You're welcome! :-)
<lfam>A week or two? The kinks are still being worked out.
<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
<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:
<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 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
<thorwil>so it contains: $srcdir/configure --enable-maintainer-mode $AUTOGEN_CONFIGURE_ARGS "$@"
<thorwil>why is there even a phase bootstrap, when 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 (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? :-))
<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
<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?
<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>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!
<ng0>(c) 2016,2017,2018 in the header.. wow. that is a long time coming for such a small patch.
<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
*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