IRC channel logs


back to list of logs

***mage is now known as Guest45623
<civodul>Hello Guix!
<civodul>mark_weaver: the armhf builds of gnome-updates were canceled; do you think we should restart them now?
***Basstard1 is now known as Basstard`
***Basstard1 is now known as Basstard`
<magnicida>I'm having problems when running Guix on a terminal that is less than 80 char wide
<magnicida>I dug in the code and found a ;; TODO note commenting on this problem
<magnicida>the problem is that the progress indicator for downloads starts flooding the terminal
<magnicida>if I am running the shell inside emacs it blows the buffer and everything becomes super slow
<civodul>oh, because lines are too long, right?
<magnicida>is there a workaround for this?
<civodul>not sure which problem then
<civodul>i don't remember seeing issues in Emacs shell
<civodul>where is the TODO you mention?
<magnicida>yeah, it seems that when the line wraps around, the progress bar is unable to delete de last printout before printing the next one
<magnicida>and the terminal is flooded
<magnicida>1 sec, i'll find it again
<civodul>ah yes
<civodul>right, there's a recent thread on this topic
<magnicida>guix/build/download.scm, line 185
<magnicida>in function progress-proc
<iyzsong>oops, wget even get "Segmention fault" when the terminal is small :-
<magnicida>it did not seem trivial to fix because this function is passed around between the client and the daemon
<civodul>right, that's the problem
<civodul>download is started by the daemon, where we don't know the client's terminal width
<civodul>however, the problem that lines are not erased should be fixed, i think there's a patch pending
<magnicida>oh cool
<civodul>using the right ANSI escape sequence
<magnicida>that should be good enough for me, the flooding is the most anoying part, i can live with unwanted wraping
<civodul>yeah, though we should fix all these annoyances somehow
<civodul>they all add up and, well, annoy us all :-)
<magnicida>yup, can influence the overall feeling of robustness in the face of potential adopters
<magnicida>btw, I have another question
<magnicida>I see Guix has support for building containers for the cloud
<magnicida>I wonder if it can do something like that for a desktop app: building a self-contained binary package with all the dependencies that could be just uncompress -> double click
<iyzsong>I don't think so.. we have minimal containers support, but what's the cloud?
<magnicida>well, yeah, forget about the cloud
<magnicida>I am not very familiar with containers, I just hear of them all the time when people talk about the cloud hehe
<magnicida>the stuff i'm most interested though is on something like a xdg-app or alike
<iyzsong>I think that's possible and have been discussed before.. but not interesting enough to be a focus. having more users to install guix on other distros is better :)
<magnicida>I understand
<magnicida>yeah, makes sense that Guix be easily installed and managed in other distros is higher priority
<magnicida>the xdg-app support would be an incentive for peopleto contribute Guix packages though... I'll look into adding it myself when I get more serious about xdg-app for my software
***ringst_ is now known as ringst
<htgoebel>civudol, magnicida: I'm annoyed by the flooding of the progress report, too.
***paolo_ is now known as paolo
<htgoebel>magnicida: Does anybody work on a RPM .spec-description for Guix already?
<jmarciano>Interesting Guile based, package manager: (of course not for GuixSD approach)
<davexunit>phant0mas: the suggestion given by janneke on the mailing list to fix the avr-libc build worked for me!
<davexunit>instead of altering gcc, though, I added a build phase that did this:
<davexunit>(setenv "CPATH" (getenv "C_INCLUDE_PATH"))
<davexunit>(unsetenv "C_INCLUDE_PATH")
<phant0mas>but why it works?
<phant0mas>what's the difference?
<davexunit>that needs more explanation to me
<davexunit>but it totally works
<davexunit>rebuilding some firmwares to test right now.
<davexunit>firmwares build!
<phant0mas>if we find why it works then I am totally in support of using it
<phant0mas>yay :-D
<davexunit>janneke could explain more on the mailing list
<davexunit>he seems to understand.
<davexunit>phant0mas: I made an avr-toolchain package as well.
<phant0mas>he doesn't seem to be online now
<davexunit>it includes: avr-gcc, avr-libc, avr-binutils, and avrdude
<davexunit>do you agree with adding avrdude to this?
<davexunit>it's the recommended flashing tool so it seems appropriate
<davexunit>in the future we could also add simulavr and friends
<davexunit>once they are packaged.
<phant0mas>sounds like a plan
<phant0mas>send the patch to the list
<davexunit>will do
<phant0mas>sneek: later tell janneke hey can you help us understand why CPATH works instead of C_INCLUDE_PATH?
<sneek>Got it.
<davexunit>phant0mas: it seems that simply (unsetenv "C_INCLUDE_PATH") is enough
<davexunit>no CPATH needs to be set at all
<phant0mas>hm.. we really need to find why
<davexunit>yup. it's because now the build doesn't try to use the native system's headers.
<phant0mas>and where it finds limits.h then?
<davexunit>that's a great question
<davexunit>phant0mas: I'm updating avr-libc to 2.0.0 in this patch set.
<davexunit>I'm doing so in the same patch that fixes the build. I hope that's okay. the 1.8.1 build has been broken for some time anyhow.
<phant0mas>davexunit: okay from me!
<phant0mas>I will test it in both x86_64 and arm to see if everything works
<phant0mas>davexunit: thanks for working on this :-)
<davexunit>phant0mas: my fork of guix has the commits
<davexunit>probably easier to check that out than to apply the patch set
<phant0mas>one sec to find a screen to connect the rpi at work :P
<rekado>davexunit: re electronics: some of the things I learned in school, others are just adapted standard circuits that appear again and again in amplifiers in slightly modified arrangements.
<rekado>at some point you stop seeing things as discrete components; you just see that that's an amplifier, that's a buffer, that's to reset the DC level, etc.
<rekado>none of these circuits are my own invention. There's a lot of tested circuitry out there since decades. Playing with the actual implementation leads you to the desired component values.
<rekado>sneek: later tell mck I haven't used Java with certificate stores at all. I'm not a Java developer and I know very little about Java use in practise. Sorry.
<sneek>Got it.
<rekado>pandas still fails one test. As a hack I'd like to disable it with a FIXME comment just so we can get all the science stuff built again.
***Digitteknohippie is now known as Digit
<phant0mas>davexunit: I know why cpath works
<phant0mas>it isn't using glibc limits.h
<phant0mas>but gcc's
<phant0mas>actually why it is working when unsetting c_include_path
<phant0mas>cpath works because gcc doesn't take it into account
<rekado>a fix for the pandas test failure was released two weeks ago; I'll add a patch to fix this.
<davexunit>phant0mas: CPATH is not needed, yeah.
<davexunit>avr-gcc knows how to find its own built-in headers
<davexunit>without needing a search path
<phant0mas>davexunit: if Ludo is okay with the patches, please push :-)
<davexunit>phant0mas: yeah I'm gonna wait a bit for some feedback.
***sankey1 is now known as sankey
<davexunit>man, I really don't understand why I'm rebuilding so much
<davexunit>I think someone introduced a change that caused too much churn
<davexunit>maybe it's samba, somehow.
<davexunit>hmm, doesn't seem to be.
<Sleep_Walker>Guix is now official package in openSUSE :)
<paroneayea>Sleep_Walker: nice! :D
<Sleep_Walker>now I need to update it to 0.10.0
<Sleep_Walker>it was waiting almost month for legal review
<iyzsong>oh, greet!
<davexunit>does anyone have an idea about what is causing mass rebuilds on master right now?
<civodul>Sleep_Walker: woow, congrats! :-)
<civodul>davexunit: like which package?
<civodul>could it be fc1adab?
<davexunit>it's not a full world rebuild, but it seems like anything that creates an X window needs rebuilding
<davexunit>maybe gtk or something
<davexunit>gtk+, emacs, eog, evince, file-roller, inkscape, livestreamer, milkytracker, qt, gnuplot, texlive, geda-gaf
<davexunit>I can give many other examples, but I think that's probably enough :)
<davexunit>one more: icecat
***drewc_ca is now known as drewc
<civodul>davexunit: gtk+ is grafted, but is not rebuilt, AFAICS
<civodul>we have one graft for pcre currently
<davexunit>it's more than just grafts, it seems
<davexunit>I'm building so much from source. I see a lot of tarballs below "The following files will be downloaded:"
<wingo>is it adding svg support to gtk?
<bavier>davexunit: would it be the 'search-patches' commit?
<civodul>davexunit: with v0.10.0-204-ga2d0e20, "./pre-inst-env guix build emacs -n --no-grafts" shows that everything would be downloaded
<civodul>same for icecat
<civodul>evince appears to be missing though
<quiliro>how is everyone?
<quiliro>i was about to return to trisquel
<quiliro>but i am resolved to working to make a usable setup
<quiliro>if it takes that i compile myself the necessary elements, i will learn
<quiliro>if nobody helps me, too bad.....but i will do it
<quiliro>so i am here
<quiliro>with some problems....and i would be grateful for some guidance
<civodul>hello quiliro!
<quiliro>guixsd is working
<civodul>sure, share your problems either here or on
<quiliro>but i still need the usb emories to be mounted on xfce or gnome
<civodul>hopefully people will provide guidance :-)
<quiliro>civodul: thanks for your motivation
<davexunit>quiliro: I don't know if we have the software for automounting removable drives
<davexunit>this would be a good question for
<davexunit>I've been missing it too. for now I've just been mounting manually.
<davexunit>which is easy enough but not very convenient.
<quiliro>i think it is included because the usb is mounted if i turn on the computer with the device plugged in
<civodul>davexunit: BTW, you were right, i just noticed an util-linux change that causes massive rebuilds in master :-/
<civodul>i don't know if it's still worth reverting
<civodul>mark_wea`: thoughts? ↑
<davexunit>civodul: aha!
<davexunit>civodul: df88743?
<quiliro>udisks is included
<quiliro>why is it not mounting?
<davexunit>someone should investigate
<davexunit>I don't know how udisks works. is there a daemon that isn't running?
<civodul>davexunit: yes, that one
<davexunit>civodul: I guess we should just let it go, rather than revert it.
<civodul>yeah, probably
<davexunit>hydra is probably already building it
<civodul>quiliro: "udisksctl status" returns something sensible here, but i don't know much about udisks
<davexunit>civodul: actually, I think we should probably revert.
<davexunit>"...would ensure 751 dependent packages are rebuilt"
<davexunit>and I can see that we're a long way from having them all built again
<davexunit>civodul: I'll do the revert if that's okay with you
<quiliro>i don't have a usb memory with me right now :P
<quiliro>why is there no logout in gnome?
<quiliro>sorry for yelling
<davexunit>not sure
<davexunit>if someone knew the answer it probably would have been dealt with
<quiliro>but gnome only allows rebooting and shutting down
<davexunit>gnome is pretty new for us
<paroneayea>quiliro: it might be something to do with elogind missing something
<paroneayea>quiliro: gnome's default is to expect to "return" to gdm, and that's not what we do in guixsd
<paroneayea>that would be my *suspicion* anyway
<quiliro>davexunit: possibly nobody knows that is happening
<paroneayea>quiliro: if you're interested in researching
<paroneayea>this might be an interesting one to look into :)
<davexunit>quiliro: that's my point, yes.
<quiliro>paroneayea: oh
<davexunit>someone needs to look into it.
<paroneayea>quiliro: luckily, guix makes hacking and exploring and experimenting a lot of fun, if you want to delve into it... :)
<quiliro>paroneayea: i do not know where to start
<quiliro>i am reading the manual
<quiliro>it is very useful
<quiliro>but i have a lot to learn still
<davexunit>trying to find the source code for gnome-shell's logout button might be a first step
<quiliro>davexunit: elogind?
<davexunit>elogind is logind extracted from systemd, so that it can operate standalone.
<paroneayea>davexunit: it's probably something in gnome-shell
<davexunit>you could find out under what conditions gnome-shell shows the logout button
<davexunit>and proceed with an investigation from there
<jmd`>What does this error indicate:
<jmd`>;;; Failed to autoload make-session in (gnutls):
<jmd`>;;; ERROR: missing interface for module (gnutls)
<davexunit>jmd`: that you don't have gnutls
<jmd`>Hasn't it been packaged?
<davexunit>of course, guix needs it.
<jmd`>So then I have it.
<davexunit>I presume you are using 'guix download' or something
<jmd`>guix build
<davexunit>then it means you are using an http:// URI when you mean to be using https://
<davexunit>gnutls isn't used in the source derivation if the resource isn't being downloaded via https
<civodul>davexunit: well we have 1400+ scheduled out of 12000+
<civodul>for master
<civodul>davexunit: well ok for the revert
<civodul>let me know when you're done so i can cancel pending jobs
<civodul>and let lfam know as well ;-)
<davexunit>civodul: if you think we should just wait it out, I defer to you.
<davexunit>I can revert locally until its done if no one else is bothered
<davexunit>ACTION checks to see if this solves his profile update issue
<quiliro>guix package: error: build failed: some substitutes for the outputs of derivation `/gnu/store/7z2l3jqsdsfq7i91gmlcip34bhh4f36w-texlive-20150523-texmf.tar.xz.drv' failed
<quiliro>i get that when installing libreoffice
<davexunit>yeah that happens sometimes
<quiliro>guix substitute: error: download from '' failed: 503, "Service Temporarily Unavailable"
<quiliro>why is it unavailable?
<davexunit>the server didn't respond in time
<quiliro>davexunit: what to do?
<davexunit>try again
<davexunit>that's about it
<quiliro>davexunit: you mean there is no solution?
<davexunit>it's a transient error from our mirror
<quiliro>davexunit: oh.....ok...i understand now
<quiliro> it is working
<davexunit>it would be nice if this never happened, which is why we're trying to upgrade servers
<davexunit>quiliro: you should take note of what guix is going to build from source
<davexunit>if you're installing libreoffice and it's trying to build texlive from source...
<davexunit>you'll probably be building tons of other things from source
<davexunit>and if you're using the latest from the master branch, it's surely because of the commit that I'm about to revert.
<quiliro>you suggest i wait until later?
<quiliro>davexunit: ^
<davexunit>civodul: there's more to it than just the util-linux commit.
<davexunit>reverting it still results in tons of rebuilds.
<quiliro>it woulh be nice to have the option of using source or binary
<davexunit>that's exactly what guix gives you.
<quiliro>i have discovered how to search for packages
<civodul>davexunit: x86_64?
<davexunit>civodul: yes.
<davexunit>there's less to rebuild now
<quiliro>davexunit: is making me download from source....isn't that what you wrote?
<davexunit>but still a bunch
<civodul>davexunit: can you try reverting the 'search-patches' commit as well?
<davexunit>quiliro: how you can download a binary that doesn't yet exist?
<davexunit>the reason it's building from source is *because* there's no binary available
<davexunit>changes have been introduced to master that have triggered many rebuilds on our build farm.
<quiliro>davexunit: i would like the latest available binary
<davexunit>there's no latest. there either is or there isn't
<quiliro>the previous version must have it
<davexunit>our master branch is constantly rolling with new updates. rebuilds are inevitable.
<davexunit>civodul: trying to revert that
<davexunit>civodul: that didn't have any effect
<davexunit>something has caused texlive to rebuild
<quiliro>davexunit: i don't understand...but i bet your decision is the best
<davexunit>quiliro: you'll have to go back into the commit history a bit if you want a pre-built libreoffice
<quiliro> a source package, right?
<davexunit>that's a source tarball, yes.
<quiliro>so i am now downloading the source
<quiliro>how can i go back in the commit history?
<quiliro>how can i know which commits are available?
<quiliro>for libreoffice
<davexunit>I'm sorry, I can't keep answering all these questions.
<davexunit>Guix is a constantly changing piece of *beta* software.
<quiliro>could you only point to the part i should read in the documentation?
<davexunit>civodul: I reverted the util-linux commit. it reduces the number of rebuilds.
<davexunit>quiliro: do you know how to use git?
<davexunit>you should use a git checkout of guix
<quiliro>davexunit: a little
<davexunit>if you're not comfortable with git, you may have trouble using Guix right now.
<davexunit>might be best to use Trisquel
<davexunit>and install Guix on top to experiment with.
<quiliro>davexunit: why will git be best?
<davexunit>because you'll be able to checkout the source at arbitrary points in time
<davexunit>so you could go back to a point where the libreoffice package is one for which binaries are available on hydra
<quiliro>will i be able to download all guixsd binaries with git?
<quiliro>or just the sorce?
<davexunit>git has nothing to do with the way guix works
<davexunit>it's just a way to get the source to build and fork as necessary
<quiliro>ok, with the source i just have to guix package -i ....the same way i have done until now?
<quiliro>davexunit: thank you for the information
<quiliro>once i read that and experiment, i will report back
<quiliro>i have to go now
<quiliro>thank you for your help
<davexunit>civodul: I need to explain it on the list, but I think the AVR toolchain isn't your typical cross-compiler, if I'm reading correctly.
<davexunit>phant0mas: did you see ludo's comments on the avr patch set?
<davexunit>oh wait, I see you replied to something :)
<phant0mas>davexunit: yes I did, I am preparing a patch for core-updates :-)
<phant0mas>but I went to a voluntary blood donation today, and they took a lot more than usuall from me, so I am taking it slow today
<phant0mas>I feel really tired :P
<davexunit>no worries!
<phant0mas>btw civodul davexunit I really think we should keep explicit packages for each avr tool
<phant0mas>meaning avr-binutils avr-gcc avr-libc
<davexunit>I agree.
<davexunit>I think we need to explain the situation more in the mailing list thread
<davexunit>since AVRs aren't a system type that you could run any other software on.
<davexunit>I think ludo's right that we can remove many of the flags. I will try that when I get a chance.
<civodul>davexunit: i felt like my review was somewhat boring, sorry 'bout that ;-)
<davexunit>civodul: nah, it's good stuff.
<davexunit>I think we just have some explaining to do to get us all on the same page.
<davexunit>avr-gcc isn't something that one uses to compile the usual software one would compile with GCC, but rather specialized firmware for 8-bit microcontrollers.
<davexunit>unless I'm misunderstanding a concept here, it's something that we want to use like a normal package.
<davexunit>all of the systems are supported systems for avr-libc, because you use it on your build machine to build the firmware that you will flash onto AVR chips with avrdude.
<civodul>ok, i see
<davexunit>these chips have like 32k of storage or less. ;)
<civodul>yeah i played with an ATMega128 and a Tiny when i was young :-)
<civodul>so yes, we're not going to run Guix natively on these
<davexunit>civodul: do the native search paths make sense now or still no?
<davexunit>civodul: oddly enough, patch-shebang doesn't work in place of substitute* for the genmultilib fix.
<davexunit>I haven't looked into why yet.
<davexunit>civodul: I see why! patch-shebang does what it is supposed to do, but it turns out that /bin/sh appears many times in this file.
<davexunit>scripts embedded within the script.
<civodul>davexunit: oh indeed, it's a script-generating script!
<davexunit>phant0mas: I uploaded some pictures of what I've done with the PS2 controller project so far:
<davexunit>since you expressed some interest :)
<mood>Is it expected that, after installing guix on an existing system and authorizing substitutes, `guix build hello --dry-run` would have to still build everything? Doing s/hello/emacs does show things that would be downloaded, but most wouldn't
<davexunit>mood: no, you've likely done something wrong.
<davexunit>you should make sure that you are using the latest guix, first.
<davexunit>we only keep binaries for a limited time to conserve space
<mood>guix 0.10.0
<mood>Freshly installed from the AUR
<davexunit>that should be fine, but I'm not talking about just the version number.
<davexunit>we should still have binaries for that
<davexunit>provided what you built from the AUR hasn't done something that changes the hashes of everything
<mood>It doesn't appear to do anything weird
<davexunit>I recommend running 'guix pull' always
<davexunit>otherwise you're frozen in time and won't get things like security updates
<davexunit>gotta go
<mood>Alright, I'll try that
<mood>Hrm, guix pull fails to build because '...bash: fork: retry: No child processes'
<mood>Or, no. 'fork: retry: Resource temporarily unavailable' comes earlier
<mood>I believe that usually has to do with file descriptor limits
<mood>or process limits, or... I have no clue how to debug the building process