<quiliro>is it possible to install guixsd on raspberry pi? <lfam>quiliro: No, we don't support the CPU architecture in the raspberry pi 1 <lfam>It could be possible with some work <lfam>Currently, it's not possible <Apteryx>quiliro, adfeno: IIRC you cannot currently have both python2 and python3 in the same profile. Installing Python3 is seen as an "update" to Python2... Which is true in a very strict sense, but not very useful in practice where Python2 and Python3 are both still in (con)current use. <lfam>quiliro: I created a new bug about your mozjs build failure. It's not related to the original bug report which I had closed <quiliro>lfam: perhaps it is not a problem with mozjs <lfam>quiliro: Why do you think that? <quiliro>i have very different problems every time, check my reports <quiliro>but i have not tested several times with good network ..to be sincere <lfam>quiliro: You sent several reports with the root failure "guix system: error: build failed: substituter `substitute' died unexpectedly" <lfam>Then you sent another report about "`/gnu/store/0f5k3zc7l1mhgrjg0avnqy71afrs4ppn-mozjs-24.2.0.drv' failed" <lfam>The 2nd report is a different problem <lfam>The 1st problem is caused by the binary substitution (downloading) failing unexpectedly. The 2nd problem is a package that fails its test suite. <quiliro>the first problem is with guix pull and with guix system reconfigure <lfam>Yes, and I think it's caused by an unstable network connection, although I'm not sure <quiliro>but the second problem is only withguix system reconfigure <lfam>The 2nd problem is not really specific to `guix system reconfigure`. It's a problem with building the mozjs package. Building the mozjs package happens when you run `guix system reconfigure` because your system uses mozjs <quiliro>different but that does not mean they should be closed, just renamed <lfam>The 2nd one has a bug report now <lfam>Feel free to re-open the 1st one <lfam>But, I think there is a larger bug, which is "Guix does not work well with unstable internet connections" <lfam>By the way, it shouldn't be necessary to build mozjs on your machine. We have substitutes available for it. But, if you can't download them, of course you'll have to build mozjs yourself <lfam>We should investigate how to make it more reliable when the network is bad <quiliro>lfam: where is "Guix does not work well with unstable internet connections"? <quiliro>lfam: so, i should copy the text of the other email and rename it "Guix does not work well with unstable internet connections" and then send it to bug-guix? <quiliro>lfam: done ... i will send it when i connect to a good link <quiliro>it has references to the previos report <Apteryx>Which package provides "aplay"? I'm trying to see if my system "knows" of HDMI audio output. <kevinfish>how do I get a mixer to crank up my volume? I installed aumix and I get: aumix: error opening mixer: No such file or directory <Apteryx>Ugh. fedorahosted has been retired but we don't seem to have a bug opened about it. Should I create one? We still have some packages hosted there. <lfam>Apteryx: Sure, and include a list of affected packages in the bug report <emaczen>Is this channel for the OS or the package manager or both? <Apteryx>Hmm... I'm fixing guile-lib ATM and hitting gnutls-error (this is a recurrent theme it seems). One way I can trigger this is by running "guix lint". <lfam>Apteryx: Is gnutls-guile (from the gnutls package) available in your environment? Does the error go away with `guix environment --ad-hoc gnutls`? <Apteryx>lfam: Good guess! I experienced the error in "guix environment guix". Just to be sure I re-ran "guix lint guile-lib" in my normal profile (not environment), and I get the same error. I'm using GuixSD. <lfam>By good guess, do you mean that you can fix the issue by adding gnutls to your environment? <Apteryx>No, I meant it could have well been this, but helas it doesn't seem to be... <lfam>And are SSL_CERT_DIR and SSL_CERT_FILE set? <Apteryx>Yes, the former is set to /etc/ssl/certs while the later to /etc/ssl/certs/ca-certificates.crt. <lfam>Apteryx: Are you on GuixSD or another distro? <lfam>And the certificates exist in '/etc/ssl/certs'? (It's not a standard feature) <Apteryx>There's apparently 331 files in there. <lfam>Hm. I can't reproduce on my GuixSD system <lfam>The error seems to indicate that GnuTLS is having trouble reading some certificate file. <Apteryx>OK. I guess I should reconfigure (to update) my system. It's nearly a month and a half behind. <Apteryx>But I have to fix some issues with the packages to get there. <Apteryx>I've just send a patch to fix guile-lib to guix-devel. <jmd>Are there any javascript zealots who feel game to packaging mathjax ? <Apteryx>wicd build is broken due to urwid python dependency failing 4 tests. <jmd>Apteryx: In master ? <jmd>That sounds like a problem. <jmd>When did that start happening? <Apteryx>Not sure. I've updated my git checkout today, then tried running "guix system reconfigure my_config.scm". <jmd>Apteryx: Perhaps you could try to track it down using git bisect? <Apteryx>There was also a problem with guile-lib which I sent a patch to guix-devel a couple hours ago. <jmd>Or maybe hydra can give some hints (I never can understand hydra's user interface). <lfam>I can build python-urwid and python2-urwid on x86_64 from commit a78e0bda99fed71e43f5dd3a64e5613bd808fa92 <Apteryx>jmd: Yes. I'll analyze what might have changed (I'd guess just urwid) before attempting the bissect. <Apteryx>Interesting. Which architecture? I'm amd64. <Apteryx>well, x86_64 or whatever its called now. <lfam>I assume it has to do with the merge of the python-tests branch. <lfam>The python-build-system was broken in a way where test suite failures may not fail the build. Now they will fail the build <lfam>However, we tried to fix the problems or at least disable the broken tests before merging the new build system onto the master branch <Apteryx>OK. Well that's good thing to detect test failures. <Apteryx>Thanks for that. I'll see if I can fix that failure tomorrow. <lfam>It's strange that we have different results on our machines. How does it fail for you? <Apteryx>OSError: Interrupted system call. Not sure what could be causing this. <Apteryx>Would be an ugly way to report it though. <lfam>It also failed on armhf. The python-2 variants all succeeded <Apteryx>Different causes. And my HD still has 1.1G to go. Scrap that. <Apteryx>I'll investigate with a fresh head tomorrow. Good night/day! <efraim>i looked at how the daemon allows x86_64 to also build for i686, not sure how to implement that for aarch64 to also build for armhf <efraim>also streamlink looks like they finally have some real releases, so its about time to package that up and depreciate livestreamer <rekado>sneek: later tell kevinfish The alsa-utils package provides “alsamixer”, which you can use to adjust the volume. ***kelsoo1 is now known as kelsoo
<ng0>whoever wanted me to test the openssh patches, I hope to give back reports before 8 PM UTC today. <ng0>I don't like to do it on sundays, but all other days next week won't work out for me. <ng0>whoever feels like checking, there'S a CVE on texlive 2016 (CBE-2016-10243) <clacke[m]>by coincidence I tried to build texlive yesterday and got a 410 gone on one of the sources <rekado>clacke[m]: that’s a known issue. <rekado>clacke[m]: you need to build with “--fallback” ***Piece_Maker is now known as Acou_Bass
<jmd>clacke[m]: That's kindof a deliberate bug. <jmd>It's quicker to build Texlive yourself than to download the built result. ***Piece_Maker is now known as Acou_Bass
<rekado>jmd: I think it’s not. We want to let people build it locally, but it shouldn’t result in a 410. I think I submitted a bug report about this some time ago. <rekado>it seems that Guix tries to get a substitute for it even though it’s marked as not substitutable. <ng0>it just takes up too much space on the binary substitutes distribution server <jmd>Disk space is cheap. i/o bandwidth is not. <ng0>there's something I'd like to explore, which is for now cuirass as a substitutes server in a freifunk mesh network. <ng0>which would take the "bandwidth is expensive" out of this <jmd>ng0: It sounds like an interesting idea. <jmd>Is freifunk in principle different from any other network? <ng0>someone told me freifunk hosting (running service in there for the mesh users) is possible, but so far I have never tried it <jmd>I think you're right, but that's an internal detail. Batman is a bgp implementation I think. <ng0>i'm not sure (anymore) about the technical details of freifunk. <ng0>some years ago I looked into it, then störerhaftung was still a thing, and now that störerhaftung law is almost gone, and we're about to switch the ISP contract I can offer freifunk <ng0>I'm just trying several guixsd server scenarios out at the moment, so I can document them. <jmd>How about giving us a talk about it at GHM this year? <ng0>I'd rather talk about my blend of GuixSD, as I was asked about it often.. but I think GHM falls into a bad time. I'd like to go, but university starts around that time iirc, and currently I'm trying to figure out financing, legal details, etc. <jmd>I think it's before most universities start. <ng0>I imagine to run into more problems, but maybe I'm wrong and it can all be solved within the next 1 - 2 months <catonano>ng0: I'm not sure I understand your argument about the Freifunk thing <ng0>it's not the internet. you don't pay for it, other than electricity <catonano>is there an ISP contract going to be dismissed ? <ng0>okay, the common use case is to still use the internet, where organizations like the ISP-license granted Friefunk Rheinland with their VPN comes in <ng0>you can have no ISP contract at all, you can connect to the internet if at least the major node in your subdomain has access to it <ng0>if you're not sure what freifunk is, there's an english documentation on their website <ng0>i think it's mostly a german thing which starts getting used in austria and some other countries now too <catonano>yes, thanks, I was readign Wikipedia, about it <adfeno>This seems to be similar to Netsukuku, only that Freifunk became somewhat more popular. <catonano>isn't any license required to occupy wavelenghts ? <adfeno>Due to some radio signal regulations here in Brazil, Netsukuku users might even suffer fines or jailtime. <ng0>i mean the frequencies used are common <catonano>I know about a similar effort in the area of Rome. But I know they are in a legal grey zone <adfeno>Because Netsukuku requires that you set it up so that the radio space occupied is bigger than an average router or so. <ng0>lt's say freifunk andother open wireless mesh networks are fighting back commercial solutions/lobyism for years <ng0>small victories are won, then they come back <ng0>that's why I said störerhaftung is "almost" gone <ng0>some years ago you were legally responsible for everyone and every content they used in your network <ng0>I'll try and find an english text about it, should be easier <adfeno>Note: I told about radio regulations in Brazil because I thought that Freifunk was similar to Netsukuku, because I vaguely saw messages similar to "connecting to each node", so I assumed it was through radio signals. <ng0>at the end of 2016 iirc a temporary success was made and only parts of störerhaftung still apply <ng0>well it is radio.. but the 2.4GHz frequency iirc <balduin>how do I define the license of a package as mit? <ng0>there is no MIT :) it could be expat.. or some other commonly mistaken license <ng0>it's a very common used mistake by developers <ng0>adfeno: interesting.. and sad :/ <adfeno>balduin: There is no "MIT License". <adfeno>MIT never made a license of it's own. <adfeno>It used either Expat license, or the X11 License. <adfeno>The later one only has a trademark notice at the bottom that says that theX11 license is just a license, and doesn't imply that the licensed work itself is from X11 project. While the Expat license has no such last paragraph. <catonano>so I understand that this störerhaftung provision hhas been limited, now ? <ng0>the openssh patches are confusing. where did the 'subsystems' move to? <ng0>there's one series with 4 patches <ng0>it's included in there <ng0>but in the newest batch, 3 patches, it's not in the subject titles at least <ng0>or is this still the 4 patches, and it just branched in my view because of discussions on 3 patches? <catonano>anyway, the legal provisions in Italy are worse <ng0>catonano: limited, yes. it has always been secure enough if you used the VPN of freifunk rheinland, which is what everyone does <ng0>but I know people in positions where it's not good to rely on this for reasons. for me it's okay, I know there is practically no risk involved <ng0>the other big evil which keeps coming back here regulary is long term data storage/retention <ng0>it's the 5th or 6th time now <adfeno>balduin: That file seems to license the main project under non-copyleft (Expat to be exact). <adfeno>balduin: (it's the topmost license) <adfeno>However, we stll have to evaluate if the other licenses in same file don't cause other problems. <balduin>@adfeno right, especially mod_neko and mod_tora are under apache v2 license <catonano>balduin: the topmost license looks like it's expat. But there are a lot more licenses in that file <balduin>@adfeno, nekoc and nekoml are under GPL v2 <ng0>if Clement is around: I understand that the openssh patch series is ready for push and that the subsystems patch is excluded anyway? <adfeno>balduin: Also, under mysql subsection, they mention LGPL 2.1, we must investigate if by chance they have made changes to the LGPL'd code. <adfeno>Because LGPL is not non-copyleft. In contrary, it's weak copyleft. That is: it only obligates the project to keep same or compatible license if the project itself modifies the LGPL'd work. <catonano>It's to oharrd ofr me to read the GNUS manual to configure it to interact with an smpt server and that seems t be useful in order to use the Debbugs facilities :-/ <ng0>there's msmtp,sendmail and others which can be used for GNUS <ng0>and many more applications like them <balduin>@adfeno, as far as I understand it mysql.ndll is derived from the maria-db connector (mysql connector), but is under LGPL2.1+ ***Piece_Maker is now known as Acou_Bass
<catonano>ng0: are you suggesting that I use a smtp service running locally on my laptop ? <ng0>it's not a full server <ng0>all GNUS would do is similar to little smtp programs <mekeor>catonano: there are two widely spread programs for this: "offlineimap" and "mbsync" from the isync package <mekeor>okay, i'm wrong. this is for imap. not smtp <catonano>ng0: ok but thhe problem for me is configuration. The GNUS manual is incredibly verbose. <catonano>mekeor: I'm not going to setu up a whole email thing. I ust want the Debbugs-Emacs machinery to work <ng0>you don't really have to use gnus to use debbugs.. unless you use emacs, then idk ***Piece_Maker is now known as Acou_Bass
<catonano>currently I see bugs in the Emacs client but I can't reply rom within there <ng0>then you just need to set up some generic way to send emails from within emacs <ng0>unless debbugs mode thing really requires gnus <catonano>ng0: don't you use the Emacs Debbugs client ? <ng0>occasionally I filter, but that's all <adfeno>But I also don't use server software for sending via SMTP or for receiving emaisl. <rekado>I use debbugs with mu4e. Needed to patch debbugs-gnu.el. <rekado>I prefer using debbugs over just working with the mails directly. <ng0>adfeno: in some domains (cities/communes) there's a big overlap of amateur / citizenband radio operators and the freifunk meshnetworking community. One example was Göttingen, where when the CB community discovered freifunk increased the community by 50% or something <rekado>I consider unsubscribing from guix-patches. I’d just access the reports via debbugs then. <snape>ng0: so the gitolite patch was pushed... ? <snape>I did not get it. What happens when, say, perl is upgraded? <snape>are the hooks going to be upgraded? <snape>I don't think so, unless they are symlinks to some profile <snape>which I don't think they are <ng0>tjat was my question <ng0>I didn't think of this before <ng0>but the same applies for git, how to fix this? locally I rewritte them with a symlink to a profile <ng0>maybe wrap them? which makes no sense.. <ng0>but somehow wrapt the content <ng0>this rewriting, as written in the bug, doesn't work out for gitolite-admin though <ng0>my idea is that a gitolite service would have a user "git" and that it would have the major group "git-daemon" (or be part of "git-daemon" in addition to "git"), making /srv/git accessible to this, and that user "git" would have a guix-profile where perl is available <ng0>not one bit.. but I have no idea how to fix it, at the moment <efraim>When doing a system reconfigure, maybe it should use that commit's git and Perl? <efraim>If the service could be written so that it would need to have it? I haven't done a lot with services <ng0>but the files are not in control of guix <ng0>but our problem is having Guix in addition to GuixSD.. so the solution must also affect gitolite without shepherd <snape>I hadn't seen your answer here, so I sent an email <snape>ng0: anyway did you consider using special-files-service-type? <ng0>it's no service so far <ng0>and I have no idea what that is ***MinceR_ is now known as MinceR
<jmd>We need a lint checker to check spelling in package descriptions. <paroneayea>rekado: a "solution" ie workaround on 25961 now, but the cause, I'm still not totally sure <paroneayea>basically you upgrade to the last known revision to build, do a guix system reconfigure, then restart and do a git pull and make <sneek>ng0_, nckx says: I've sent my zpaq patch. Sorry for the delay. <sneek>ng0_, nckx says: sorry, I'd completely missed your nyx attempt! <sneek>ng0_, snape says: it is possible with mu4e, by appending :message-id to 'mu4e-view-fields'. <ng0>I've made some changes to the weebsite, they are okay now I need to quit haunt <ng0>i see no stop option <paroneayea>and it'll automatically reload when you make changes <snape>ng0: what does "The off-the-shelves status of gitolite is broken, you are not informed about these shebangs" mean? <ng0>sorry for being short in words, but I'm trying to fix something and I've already written the problem <adfeno>I have explored the source files a bit and the same source repository includes nekoc and nekoml directly (they are not separated in different projects). <adfeno>... So, unless I missed some important GPL section or clause (which applies to nekoc and nekoml, per the LICENSE file referenced), I think the neko project itself should be under GPL. <Apteryx>adfeno: Without looking myself, what you says sound right (GPL + Expat --> GPL) since GPL has more requirements. <Apteryx>adfeno: Or maybe we could list the different licenses, since the components could be used separately I guess. <adfeno>I know balduin is actually looking for packaging neko for Guix, so I don't exactly know neko's internals on how tight things are inside it. <ng0>it's in their interest to point out the correct license <adfeno>I just made a low-detailed look through it and found that what I just described (nekoc and nekoml inside neko itself). <ng0>ohno. i htink I've just opened a new ticket with an reply to a ticket where I haven't replied to the id <ng0>do we have masters of the debbugs realm which can shuffle messages around? <yrk>adfeno: as long as the project as a whole is licensed under the terms of the GPL, the components of the project can be under GPL-compatible licenses <ng0>oh, debbugs sorted it out <adfeno>nekoc and nekoml are components of neko project. <adfeno>nekoc and nekoml are under GPL 2 <yrk>adfeno: so it sounds like the project, as a whole, would be under GPL <adfeno>yrk: Yes, that seems to be the case. <yrk>adfeno: if there are any issues following this up feel free to write to licensing@fsf.org <adfeno>It is strange that the main heading of the LICENSE file says that it's under Expat. <jmd>rekado: www.bootstrappable.org seems not to be responding anymore. <yrk>adfeno: (especially since I think I saw that there are materials in the project for which the fsf are the copyright holder) <Apteryx>sneek: Later, tell gnu_guix: About pip not finding python packages, this is a "known" issue. I haven't bothered opening a bug bug it's on my fixing todo list. Even have a branch with some hacking on it. The problem is how we define the searchpath (and use PYTHONPATH). We should create a distinct GUIX_PYTHONPATH for that instead. <adfeno>Apteryx: Try "later tell username" <Apteryx>The git history is a bit confused regarding the python-test merge, or is it just me? <adfeno>Now that we mostly need its help :) <adfeno>gnu_guix has no registry in NickServ, so we cannot use MemoServ to send memos to him/she. <Apteryx>sneek: later tell gnu_guix, About pip not finding python packages, this is a "known" issue. I haven't bothered opening a bug about it but it's on my fixing todo list. Even have a branch with some hacking on it. The problem is how we define the searchpath (and use PYTHONPATH). We should create a distinct GUIX_PYTHONPATH for that instead. <adfeno>sneek: later tell gnu_guix continuing Apteryx's message: Also check that there is a file at "$HOME/.pip/pip.conf" and see if it has "target=" set to some place you can write to. <Apteryx>Actually, the only thing confusing about the python-test branch was that master was "merged" into it rather than rebased, so we get noise commits such as "Merge branch 'master' into python-tests". No big deal, but please "git pull --rebase" instead of "git pull (--merge)" in the future to prevent that. <jmd>When is that madman civodul going to pop up again? <efraim>If we rebase then all the commits have to be signed again <alezost>mekeor: re "M-x guix-system-generations" error: if "M-x guix-version" tells "Emacs-Guix 0.2.2", you need to update it to 0.3 <quiliro>i would like to learn emacs, but i need hand-holding :-( <adfeno>Apteryx yrk ng0: I just sent neko project an email. <adfeno>I asked how nekoc and nekoml relate to it in terms of dependency. <adfeno>And yes, when writting the email, I remembered that the GPL has an exception for "mere aggregations". <lfam>Apteryx: I agree with efraim. We should not rebase unless there are only a few commits. It's important to preserve the signatures <lfam>The signatures are the only thing that tells us who pushed the commit to the central repo. If we start rewriting signatures between branches on a large scale, it will become confusing to know who pushed what code. <Apteryx>efraim: OK, thanks for reminding me that signatures are lost when rebasing. <Apteryx>lfam: Right. I had not considered signatures. Thanks for reminding me about it. <lfam>I agree that merge commits can be confusing, to say the least <adfeno>I just have an idea on what can be causing people not to be updating their copy of guix-daemon. <adfeno>I'm trying to confirm the possibility. <Apteryx>adfeno: Foreign distro where service definition cannot use symlink (e.g., Ubuntu 14.04 /w upstart) is one. <lfam>Is it the problem where the service file includes an absolute path instead to /gnu/store instead of /var/guix/profiles/per-user/root... ? <adfeno>I'm using Upstart, and using symlinks, Trisquel 7 (based on Ubuntu 14.04) <lfam>Bah, I knew that change might cause problems <Apteryx>I'm pretty sure upstart shipped with the Ubuntu 14.04 I use at work doesn't support it. <adfeno>I think systemd is the one that has a thing against symlinks (in older versionss) <lfam>There was no reason to embed the /gnu/store path regardless of whether or not the service manager allowed symlinked service files <adfeno>Also, the same might happen (outdated guix-daemon) if the user who install Guix-daemon mistakenly copies the service file instead of symlinking. <lfam>The service file should always execute the guix-daemon in root's profile. <adfeno>As a correction: It only happens with COPIED service files,. <lfam>Then, it doesn't matter if the file is a symlink or not <adfeno>Apteryx: I'll double-check if I'm really running guix-daemon htrough Upstart. But I'm pretty sure I am. <Apteryx>adfeno: Haha, what I tried actually was this: copied service files to /etc/init/guix-daemon.init or something like this. Then I tried rewriwing the /gnu/store absolute uri in the file to point to a symlink in /var/guix/profile/... or something like this. And this was failing using upstart. Maybe using an actual symlink for the service file itself is supported, I'm not sure. <Apteryx>I would have think I would have tried that as well; I don't remember for sure but it's been some time. <lfam>I don't know upstart. For systemd, only recent versions support symlinked service files. They all support service files that execute a symlink <lfam>Let's fix this today. I forgot that we never resolved it after the discussion in January <adfeno>I'm against instructing users to copy the file. <adfeno>This copied file scales to this issue of outdate guix-daemon. <lfam>adfeno: What do you mean? <lfam>The symlinked files *don't work* at all for many users <lfam>If the service files include execute a specific version of the guix-daemon, then we have to change that as well <Apteryx>lfam: Would the service file copying to the right place be automated? If not, we'll still have users who won't know/bother manually copying there. <lfam>Apteryx: It's a documented installation step in the manual. If they don't copy (or link) the file into place, then they aren't going to use Guix at all :) <Apteryx>I'm thinking it's not easy to get this automated since you can't rely be sure about the system (unless it's guixSD). <adfeno>lfam: I do agree that we must change "/gnu/store" references in service file to "/root/.guix-profile/" references instead. <lfam>I prefer '/var/guix/profiles/per-user/root' instead of '/root/.guix-profile', because it avoids looking in a protected directory, which may or may not work <Apteryx>lfam: OK. I thought we were considering the "guix-daemon" update issue. I think the file itself keeps a hard coded reference to the guix-daemon location. And changing this reference to a symlink might not work on upstart (IIRC). <adfeno>lfam: Oh... I see, that can work also. <Apteryx>I can try it right now actually, I have that upstart equipped machine here. <lfam>Apteryx: Are you using upstart? Can you try it? I don't have access to any systems that use upstart <lfam>We can treat the upstart and systemd service files differently. <Apteryx>My personal machine is running GuixSD <adfeno>My upstart service is working, updated guix-daemon because the service file is symlinked <adfeno>(I have done the symlink per the Guix installation documentation). <lfam>Please test using a version of upstart that is widely deployed. The reason we had a problem with systemd is that we didn't test against "stable" distros like Debian Jessie, so we didn't notice that support for symlinked service files was not yet common <Apteryx>Currently, this laptop is configured using a guix-daemon.conf file which was *copied* to /etc/init/guix-daemon.conf (I think this follows the manual). <lfam>We tested on things like Debian unstable, which have the latest systemd <lfam>That's when we started instructing people to symlink the file <lfam>I'm going to work on the systemd service file. Can the two of you please investigate the situation with upstart and send patches (or at least recommendations)? <Apteryx>OK. I first installed guix on this machine when version was at 0.11.0. Maybe that's why I went with the "copy the file" instruction. <lfam>Yes, that was the instruction for 0.11.0. <Apteryx>The problem with that file was that the reference to guix-daemon is a hard coded path reference to the version shipped with 0.11.0. I had to manually update that reference in the file. <lfam>None of this explains why people were still using the daemon from 0.10.0, however :) <Apteryx>Probably the template for 0.10.0 was similar (using a hard coded path to guix-daemon 0.10.0). <Apteryx>Unless you bother to recopy that file everytime you guix pull (which we can't rely expect normal users to do), they'd be stuck forever running 0.10.0. <Apteryx>The same way I was stuck using 0.11.0. <lfam>Yes, the 0.10.0 service file contains an absolute path to /gnu/store <Apteryx>OK. I just tried using "/var/guix/profiles/per-user/root/guix-profile/bin/guix-daemon" in the /etc/init/guix-daemon.conf (copied) file, and it works with upstart on Ubuntu 14.04. <Apteryx>So that would be a very good improvement already. <Apteryx>On a foreign distro, am I right that the only way to update the "guix-daemon" is currently to run "guix pull" as root? <Apteryx>I tried using it at the location it gets built in my git checkout, but that was failing last time I tried. <adfeno>Apteryx: I also think that (about updating guix-daemon by running guix pull as root). But I'm not sure if this is true. <adfeno>The symlink as an Upstart service never required me to modify the service file. <Apteryx>Hmm... after I ran "sudo guix pull", "realpath /var/guix/profiles/per-user/root/guix-profile/bin/guix-daemon" still returns 0.12.0-4. 0.12.0-5 was expected. <adfeno>Oh... sorry... We must extend our argument a little bit, Apteryx, see my reasononing: <adfeno>`guix pull` only gets the recipes. <lfam>`guix pull && guix package -u guix`, right? <adfeno>It's `guix package -u` that upgrades. <adfeno>Apteryx: So, it's only expected that "realpath ..." returns older version still... <adfeno>... because no upgrade was made. <lfam>adfeno: You said "The symlink as an Upstart service never required me to modify the service file." <lfam>But, the upstart service file from Guix 0.10.0 executes /gnu/store/3g6zn8y5sfwywr4pqiwqrab735a0x4zl-guix-0.10.0/bin/guix-daemon <lfam>So, your service is getting updated properly? <Apteryx>OK. I've been using guix from a git checkout for too long, I've forgotten how to actually update guix the "normal" way. I didn't remembered there was a guix package! <Apteryx>lfam: That works ('sudo guix package -u guix' following a 'sudo guix pull') <Apteryx>Now realpaths shows me guix-daemon is at 0.12.0-5.1162 <lfam>Do we need to change the upstart files? Or do the most widely deployed versions of upstart support symlinked service files? <lfam>Even if they do, should we change the path they execute to point to '/var/guix/per-user/root...'? <lfam>I'm guessing there's going to be a "long tail" of old upstart versions from users who don't want to update to a systemd ubuntu <lfam>Are any distros shipping upstart *now*? <adfeno>lfam: I'll check that question about guix 0.10.0 now. <lfam>I have a good idea about how to handle systemd, but I have no experience with upstart at all, so I need advice :) <adfeno>lfam: Yep, my point stands: the symlink Upstart service is updated. <adfeno>exec /gnu/store/ybi3iccynp36nhmj99759v2mn7dlx25j-guix-0.12.0-4.d9da/bin/guix-daemon --build-users-group=guixbuild <lfam>I wonder if we should change it anyways in case somebody decides to copy it <adfeno>Note: I didn't update my own copy of Guix since two weeks ago. <adfeno>If you want, I can check the version of guix that is really available at root profile. <adfeno>Yep. Right version when doing `sudo guix package -I guix`. <Apteryx>I'll try to follow the latest guix manual closely now to see if using symlinked service files with Ubuntu 14.04 upstart works here as well. <Apteryx>I'm confirming that the symlink procedure described in the latest guix texinfo under "Binary Installation" works for Ubuntu 14.04. <Apteryx>I'm not sure what it is I wasn't doing right the last time. Maybe I was forgotting to call "initctl reload-configuration". <lfam>So, distros using upstart are ubuntu 14.04, trisquel 7 (based on that ubuntu), and RHEL 6 and it's derivatives. Anything else? <Apteryx>quiliro: No! It uses shepherd, a guile service manager. <Apteryx>*service manager written in guile ;) <Apteryx>Could anyone try "guix build python2-urwid" on git master? I get two test failures. <lfam>Apteryx: It successfully creates the store item: /gnu/store/ay0fv2d72fhdjjqs8qsffhghyf99lh2h-python2-urwid-1.3.1 <Apteryx>Hmm. How about "guix build --check python2-urwid" ? <lfam>Apteryx: Yesterday I saw that some of the variants had failed on Hydra, so I restarted them. Now, they all built successfully. So there is some non-deterministic failure in the build process. <lfam>I recommend trying it again <lfam>I've noticed this before with urwid <lfam>I can make it fail reliably when building on an ext4 filesystem with 128 byte inodes (too small for sub-second timestamps). It builds reliably on a btrfs filesystem <Apteryx>I tried "guix build python2-urwid" on my 2nd (ubuntu) machine, and there it seems to be happy using substitutes, even when using (guix build --check). Is this a reliable check? <Apteryx>Or to be 100% sure should I use the --no-substitutes option of guix build? <lfam>It also fails on ext4 with larger indoes <lfam>Apteryx: It shouldn't use substitutes with --check. Make sure to pass --no-grafts when using --check <lfam>Someone should figure out why urwid doesn't build reliably, but it's not something I'm going to personally investigate <lfam>ng0: I think you can close that one. <sneek>paroneayea, you have 1 message. <lfam>It's definitely a configuration problem in that webserver. <Apteryx>lfam: When using "guix build --check --no-grafts python2-urwid", I get: some outputs of '/gnu/store/d3nn0j....jn2-python2-urwid-1.3.1.drv' are not valid, so checking is not possible. What does this mean? <lfam>Apteryx: You have to build once before you can --check it <lfam>paroneayea: Savannah itself is using certificates from Let's Encrypt. Do you have problems cloning the Guix repo? <paroneayea>lfam: ng0: okay I'll reply to those details and close it. <ng0>oh, I have already closed it <lfam>Also, the failing command in #22408 works now, so I'm going to close it <ng0>i just thought it was already closed when I read the last message in my mailreader <lfam>Yes, if you can download a substitute for libmicrohttpd, or build libmicrohttpd, then I think it can be closed <ng0>hm... I never submitted the .desktop file patch for rxvt-unicode? <lfam>I *am* working through old emails, but there are a lot of them <lfam>I also don't use a desktop environment, so I'm not a good person to test changes involving .desktop files <lfam>ng0: Please don't remove the subject lines when closing bugs :) <Apteryx>What is the policy for a proper review? Is testing always required? <ng0>I did not reply to a mail, I had no clue about the exact line <ng0>I just blindly closed <lfam>Apteryx: It's not only required, but expected :) <lfam>The type of test depends on the nature of the change. <Apteryx>OK. That's very high standards. Which is nice, but a lot of work! <ng0>The comment in 24341.. do other distros really have more than one executable for libreoffice? <ng0>I had soffice/libreoffice in gentoo <lfam>Apteryx: I disagree that it's a very high standard :) We do much less testing than distros like Debian and Red Hat <ng0>and there's no form like for packages I've seen in fedora <ng0>they have standardized package inclusion procedures I think <Apteryx>I guess we're just sloppy at work then ;) Most of the burden of test is put on the submitter/continuous integration tests. The review process itself is focused on the actual code changes, not testing. <lfam>We do as much as we can with the humanpower that we have <efraim>on debian there's soffice, libreoffice, loffice, lofromtemplate and unopkg from libreoffce-common <ng0>soffice is historic, libreoffice is a symlink <efraim>/usr/bin/libreoffice: symbolic link to ../lib/libreoffice/program/soffice <efraim>loffice is a shell script pointing to /usr/lib/libreoffice/program/soffice <adfeno>Since libreoffice is symlink to soffice, I would say the contrary to "soffice is historic". <ng0>it's only 'soffice' executable which gets build <adfeno>Because "historic" often relates to "deprecated" or "on deprecation". <ng0>if you don't symlink others <ng0>my "historic"refered to "I think it comes from StarOffice" <ng0>historic as in not technically historic, real historic <efraim>i'm off to bed, hopefully I can figure out my networking issue with my aarch64 board tomorrow :/ today didn't get it fixed <lfam>efraim: Did you get the firefly yet? <Apteryx>Interesting. The python2-urwid build problem only seem to occur on GuixSD. Maybe something to do with the 4.9.5 kernel I'm using right now. <lfam>Apteryx: I reproduced it from Guix on Debian with Linux 4.9.13 <lfam>It built on btrfs but not ext4. I'm not sure what other factors could be different between my two environments <Apteryx>lfam: I can build python2-urwid on Ubuntu 14.04 with ext4 and linux 4.2.0. ***kelsoo1 is now known as kelsoo
***Guest53072 is now known as sturm
<Apteryx>I'll disable tests for now, reconfigure, then try again.