***mage is now known as Guest45623
<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? <civodul>i don't remember seeing issues in Emacs shell <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 <civodul>right, there's a recent thread on this topic <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>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 <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>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>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>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? <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>rebuilding some firmwares to test right now. <phant0mas>if we find why it works then I am totally in support of using it <davexunit>janneke could explain more on the mailing list <davexunit>phant0mas: I made an avr-toolchain package as well. <davexunit>it includes: avr-gcc, avr-libc, avr-binutils, and avrdude <davexunit>it's the recommended flashing tool so it seems appropriate <davexunit>in the future we could also add simulavr and friends <phant0mas>sneek: later tell janneke hey can you help us understand why CPATH works instead of C_INCLUDE_PATH? <davexunit>phant0mas: it seems that simply (unsetenv "C_INCLUDE_PATH") is enough <davexunit>yup. it's because now the build doesn't try to use the native system's headers. <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>I will test it in both x86_64 and arm to see if everything works <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. <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>/gnu/store/...avr-gcc-4.9.3/lib/gcc/avr/4.9.3/include-fixed/limits.h <phant0mas>/gnu/store/...avr-gcc-4.9.3/lib/gcc/avr/4.9.3/install-tools/include/limits.h <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>avr-gcc knows how to find its own built-in headers <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>does anyone have an idea about what is causing mass rebuilds on master right now? <davexunit>it's not a full world rebuild, but it seems like anything that creates an X window needs rebuilding <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 :) ***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>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 <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>with some problems....and i would be grateful for some guidance <civodul>sure, share your problems either here or on help-guix@gnu.org <quiliro>but i still need the usb emories to be mounted on xfce or gnome <civodul>hopefully people will provide guidance :-) <davexunit>quiliro: I don't know if we have the software for automounting removable drives <davexunit>this would be a good question for help-guix@gnu.org <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 <davexunit>I don't know how udisks works. is there a daemon that isn't running? <davexunit>civodul: I guess we should just let it go, rather than revert 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>IN XFCE THERE IS THE OPTION TO LOG OUT <davexunit>if someone knew the answer it probably would have been dealt with <quiliro>but gnome only allows rebooting and shutting down <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 <quiliro>davexunit: possibly nobody knows that is happening <paroneayea>this might be an interesting one to look into :) <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 <davexunit>trying to find the source code for gnome-shell's logout button might be a first step <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) <jmd`>Hasn't it been packaged? <davexunit>I presume you are using 'guix download' or something <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>let me know when you're done so i can cancel pending jobs <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 <quiliro>davexunit: you mean there is no solution? <quiliro>davexunit: oh.....ok...i understand now <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. <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 <quiliro>i have discovered how to search for packages <quiliro>davexunit: no...it is making me download from source....isn't that what you wrote? <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 <davexunit>our master branch is constantly rolling with new updates. rebuilds are inevitable. <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>how can i go back in the commit history? <quiliro>how can i know which commits are available? <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>if you're not comfortable with git, you may have trouble using Guix right now. <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? <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 <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? <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>btw civodul davexunit I really think we should keep explicit packages for each avr tool <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>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. <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>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. <civodul>davexunit: oh indeed, it's a script-generating script! <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>Freshly installed from the AUR <davexunit>that should be fine, but I'm not talking about just the version number. <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>otherwise you're frozen in time and won't get things like security updates <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