<civodul>ACTION starts an eval of core-updates ***kelsoo1 is now known as kelsoo
<quiliro>where is the source of hello?, where are the values that are specified in the package definition for the GNU Hello package taken from? <quiliro>but i would like to see it in a simple package <quiliro>then i will really know how it works and then will be able to do it for other packages <Apteryx>Has anyone else noticed how long webkit takes to compile? It's been more than 24 hours so far! <sneek>Welcome back Apteryx, you have 1 message. <lfam>Apteryx: It takes hours for me, but not close to 24 hours! What hardware are you using? <Apteryx>Old i3 based processor (low power one -- laptop), 4 GB ram, SSD. <quiliro>Apteryx: that is pretty new to me... my newest machine is a centrino duo! <lfam>Well, the time it takes to compile will scale based on the value of "old" :) <quiliro>would someone please guide me with respect of making guix packages according to what i asked? <quiliro>lfam: before trying to adapt any package, i would like to understand the Hello package <quiliro>lfam: would you please guide me in finding the data? <lfam>If not, they are in the Guix code <quiliro>lfam: thank you. but that is not what i am asking <lfam>Please clarify your question <lfam>What do you mean by "data"? <lfam>quiliro: The person that packaged hello decided to call the package "hello" <lfam>They chose to make a package of version "2.10" <lfam>They chose to build it with gnu-build-system <lfam>They learned that hello needs gawk, so they include gawk as an input to the build <lfam>The wrote or copied the synopsis and description <lfam>They read the source code and learned that hello is distributed under the gpl3+ <quiliro>ok...but where is that in Hello source <lfam>Where is what in hello source? <quiliro>where is the data in the hello scm file in the Hello source code <lfam>The person that wrote the package definition searched online and found the source code of hello on the GNU servers. They use a GNU mirror to download the source code. That is in the (source (origin ...)) <quiliro>please show me where specifically so i can read it <lfam>You can unpack it in your current directory like this: tar xf $(guix build --source hello) <lfam>Or, you can use a search engine to find it on the web <lfam>Usually yes, but not always. The URL "mirror://gnu/hello/hello-..." uses a list of GNU mirrors that we've prepared. That list is in the Guix source code in 'guix/download.scm'. <Apteryx>quiliro: Are you sure you are looking at guix/download.scm? <quiliro>i am looking now at ~/.config/guix/latest/guix/download.scm <quiliro>i am confused now...where can i find the source of Hello? <Apteryx>quiliro: The source will be hosted at any of those gnu mirrors in download.scm. <quiliro>for example there is mirror: ftp://ftp.nluug.nl/mirror/languages/gcc/ <Apteryx>quiliro: I believe mirror://gnu/... means that the package is hosted at a gnu mirror. The gnu mirrors are defined in download.scm as a list bound to "gnu-mirrors" <quiliro>so i can find Hello source in ftp://ftp.nluug.nl/mirror/languages/gcc/gnu/hello/hello-version.tar.gz <Apteryx>quiliro: You're looking at the gcc mirrors. <quiliro>i downloaded it...i also installed hello using guix package -i hello <quiliro>is the source in my computer when i install hello via guix package <lfam>quiliro: Sometimes yes, sometimes no. It depends on whether you had to compile hello or download a pre-built binary substitute. Either way, you can get it with `guix build --source hello` <lfam>To get the source code for the hello binary created by `guix package -i hello`, use `guix build --source` <Apteryx>quiliro: From what I understand, a collision arises when two or more packages provide files which path clashes together (most commonly the same files are provided by both packages). <quiliro>lfam: if it was compiled from source, where should it be <quiliro>when installed with guix package -i guix <lfam>quiliro: The command `guix build --source hello` will show you the filename <quiliro>/gnu/store/hbdalsf5lpf01x4dcknwx6xbn6n5km6k-hello-2.10.tar.gz <lfam>That's the source code of hello. You can extract it to your current directory with `tar xf /gnu/store/hbdalsf5lpf01x4dcknwx6xbn6n5km6k-hello-2.10.tar.gz` <quiliro>i have extracted and i have read README, INSTALL, TODO and doc/hello.info <quiliro>now what should i do to find the data that gnu-hello.scm contains in the source? <quiliro>now what should i do to find the data that the source has for gnu hello.scm? <quiliro>what i want to learn is how to make an scm file for guix in order to include other software in guix <quiliro>so i was looking at the hello scm file <quiliro> and i want to know where that data came from <ZombieChicken>It's amazing how much an additional 1280x1024 monitor can improve life when you're used to trying to survive with just a single monitor. ***jonsger1 is now known as jonsger
<catonano>where do I find a sheet table of info tags (for writing description fields) ? ***jonsger1 is now known as jonsger
<roelj>Is it possible to specify a username and a password in a (source (origin ...) field for an FTP url? <civodul>roelj: currently ftp-open in (guix ftp-client) has the user name and password hardcoded <civodul>that could easily be changed, though <roelj>civodul: I remember attempting to change that about half a year ago, but I never really got that to work. <roelj>May I attempt to change it again? <civodul>there are 2 changes to make: add user and password parameters in ftp-client (easy), and make sure the URL parsing stuff in (guix build download) passes the user name and password to ftp-open <roelj>Or does this open the door to unjust use? <civodul>probably not useful for free software out there, but i can imagine it might be useful for private software, for instance <roelj>civodul: Fortunately, the username and password would have to be hardcoded in the package recipe anyway :D <roelj>Does a change in URL trigger a change in output hash? <efraim>The hash is a hash of the downloaded file itself <roelj>What parses the uri string in a package recipe? <roelj>Is that string->uri from (web uri)? <thomasd>buenouanq: thanks, looking forward to summer :-) ***kelsoo1 is now known as kelsoo
<efraim>Webkitgtk takes a long time to build on aarch64 <civodul>rekado: i pushed to guix-maintenance.git a post about 'guix pack', could you take a look? <civodul>i'd like to publish it today, if possible <civodul>well everyone is welcome to comment on it of course :-) <rekado>civodul: I’ll take a look in a few minutes <rekado>civodul: maybe I’m doing something wrong, but I don’t see it. <rekado>the last commit is three days old. <jonsger>civodul: interesting reading. in the second last paragraph I would place whitespaces around the "-" software-for -> software - for <rekado>also checking maintenance.git/refs/heads/master I see that the last commit was pushed on March 17 <roelj>There's a type: "and you the command returns in" -> "and the command returns in <rekado>oh, in “guix-artwork”, not “guix-maintenance”! <roelj>Packing -> Docker container is definitely an interesting feature <roelj>Even though that -f option does not exist yet..? <thomasd>I noticed all videos for the Guile devroom at FOSDEM are available now. I think a blogpost with links and a small synopsis for each talk could be useful, wdyt? <CharlieBrown>thomasd: Wouldn't it be better to just put the description and any other info about the videos on the MediaGoblin instance where they're hosted? <pmikkelsen>Hi guix! when i build guix from source on a fully updated guixSD machine, I get two fails <snape>Hi pmikkelsen, could you please tell us more? <pmikkelsen>snape: from reading the test-suite.log I see that the two fails were <pmikkelsen>test-name: current-build-output-port, UTF-8 + garbage <pmikkelsen>I dont know if it has any effect or this is expected <adfeno>CharlieBrown thomasd: Sorry, I just came by, what is the address that you want to know about? <adfeno>I know about media.libreplanet.org, and audio-video.gnu.org. <CharlieBrown>maybe its the libreplanet one.e i know it's a gmg instance <snape>pmikkelsen: I could bin in a "guix environment guix" <snape>but I could not without the "guix environment guix" <snape>I presume because of the Guile upgrade <civodul>i'm used to not surrounding it with whitespace <civodul>roelj: 'guix pack -f docker' does exist <pmikkelsen>snape: I was in a "guix environment guix", so it seems strange to me <rekado>(I also don’t add whitespace surrounding em-dashes.) <rekado>(but with some fonts it looks terrible, because the em-dash is rendered like a regular dash.) <roelj>civodul: Oh.. "guix pack: error: f: unrecognized option". I'm at: 0420e8968240c9e12acc5fa69373f1ff5110ee99 <rekado>I’m playing around with GuixSD on a server and I’m trying to make Active Directory accounts work. <rekado>I’ve set up kerberos and the pam-krb5 service <rekado>does anyone here know more about this? <rekado>I usually set up LDAP and then use PAM with LDAP. Not sure if pam-krb5 could be configured to make this work without LDAP. <davexunit>rekado: I'm a bit ignorant right now but we're trying to get ldap setup at work so maybe I will more when I see what some other people on my team have done. <davexunit>you'll probably have figured out your problems by then. <rekado>I’ll see if I can write a service for this <rekado>This stuff is always confusing. I’ve done this configuration many many times in the past, and every time I feel like I’m starting from scratch. <thomasd>adfeno: CharlieBrown mentioned there is a gnu mediagoblin instance where the FOSDEM 2017 videos are hosted. I wanted to know where it was. <rekado>CharlieBrown: that’s not the problem. It’s a problem of intuition. <roelj>civodul: Heh. My guix was still lagging behind :) Sorry for the confusion. <rekado>civodul: “and you the command returns” should be “and the command returns” <rekado>civodul: what do you think about replacing “creates a pack with binaries for MinGW” with “creates a pack with Windows binaries using the MinGW cross-compiler”? <rekado>I like the section “Wait, didn’t you say …” <rekado>it’s a very good article. Thanks for writing it! <jmd>Does nix have anything similar to guix pack ? <civodul>jmd: recently i read about "nix-bundle", which is similar in spirit <thomasd>is there a way to remove obsolete items from the /gnu/store installed with packs? <jmd>Presumably gc will do that? <davexunit>I'm not sure how the gc will behave in this case <davexunit>since the /gnu/store items are not in the db <jmd>davexunit: Oh in that case it won't! <thomasd>does the pack even contain guix itself? <jmd>Presumably not. (unless you type "guix pack guix") <rekado>thomasd: it does not unless you ask for it. <rekado>I’m trying to set up cuirass on a GuixSD server <rekado>I’m following the example configuration in the Gui manual <civodul>rekado: Cuirass is a bit capricious ;-) <civodul>i'd recommend following the bayfront.scm example, or what Mathieu O. posted <civodul>but actually our cuirass-jobs.scm is currently broken <thomasd>I suppose people who will upgrade from packs to guix proper should better remove the old /gnu/store containing the packs? <civodul>or people producing the packs can do "guix pack foo bar guix --localstatedir", which includes a full-blown Guix <roelj>So, I created a Docker container image using: "guix pack -f docker -S /opt/gnu=/ r".. How can I run it now/where is the R executable located? <rekado>civodul: is our documentation for the cuirass service wrong then? <rekado>I get a syntax error on the spec field (#:name . "guix") <rekado>I’ll try to make it work and then submit a patch for the service documentation <rekado>Apteryx: we don’t have a package for Firefox. <Apteryx>err, I meant IceCat 45.7.0, of course ;) <rekado>looks like the documentation is wrong. The cuirass specs need more list nesting. <roelj>Hm. I created a pack 'guix pack bash coreutils' and I ran 'guix environment --container --pure --ad-hoc bash coreutils', and they seem to use a different version of bash.. <rekado>roelj: re docker: You probably want to do “guix pack -f docker -S /opt/gnu/bin=bin r” <rekado>roelj: this will include a symlink /opt/gnu/bin to the profile’s “bin” directory, so you can R with “/opt/gnu/bin/R” <roelj>rekado: Where does this /opt/gnu come from? I used -S /bin=bin and that seems to work. <rekado>roelj: erm, it actually doesn’t work for me… <roelj>guix pack -S /bin=bin bash coreutils; sudo docker load < *resulting tarball*; sudo docker run -i -t *image id* /bin/bash; Works for me :) <rekado>hmm, I always used “docker import”, not “docker load” <roelj>Hmm. That should also work I think ***jonsger1 is now known as jonsger
<snape>rekado: roelj: I could not get "docker import" to work, but "docker load" worked. <roelj>rekado: Hmm. It seems I cannot run the container after using "docker import". <rekado>using “docker load” is probably right. <rekado>I’m not familiar with docker. Obviously, I’m not using it in production. <rekado>ah, the documentation (which I wrote) says I should be using “docker load” :) <rekado>trying to run R from Docker fails with an error: “Fatal error: cannot create 'R_TempDir'” <rekado>works after passing --tmpfs /tmp:rw,size=787448k,mode=1777 <roelj>So this is a nice way out for people who are afraid to use a proper solution ;) <civodul>rekado: re cuirass doc, not sure, it could be wrong <civodul>roelj, rekado: thanks for testing; glad i didn't break Docker support :-) <davexunit>#gnu and #fsf are so full of trolls it's disappointing <davexunit>latest example being a user in #gnu that insists that guix doesn't really work, that we have nothing to show for years of development. lol <davexunit>"Is it really that hard to write a new package manager?" <efraim>I haven't gone into either one for months <davexunit>oh and we have to structure what our volunteers (i.e. everyone) work on better otherwise we'll continue to go nowhere. <adfeno>davexunit: I was there seeing the troll giving us headaches... :S <davexunit>adfeno: in the middle I remembered that he was a known troll <adfeno>I can't beleave people think that we are "going nowhere" or "going slow". <adfeno>Also, my English isn't very good today. :) <davexunit>not to go super political, but this is the ignorance that I've been accustomed to from living in the US. <adfeno>Now, of course, we mustn't be blind either, sometimes it's necessary to indeed get opinions from people outside the project. <adfeno>However, that person doesn't seen to know much about what we do either :) <adfeno>So we must take his suggestions with a grain of salt, but still need to see through them, of course. <davexunit>opinions are valuable when someone understands your mission and has critique <gazon>here's an opinion from outside the project: you're doing good work. <civodul>davexunit: when i read the atom feed of scheme.dk/planet via gwene, it's all upside down <civodul>like the text is reverse, links appear in the wrong place, etc. <davexunit>civodul: whoa, really? I have never seen that <davexunit>civodul: you're saying that it's only our articles that are doing this? <civodul>i think so, though there are few articles these days <civodul>yeah the "Word Sets" article displays properly <davexunit>is this in a particular feed viewing application? gnus? <davexunit>civodul: the entry stanza in the feed is <entry xml:lang="non-html"> <davexunit>apparently it doesn't make a difference to the firefox feed reader, but gnus goes bananas. <davexunit>so why does this feed aggregator think it's non-html? <efraim>nothing uses wxwidgets@2.8, time to toss it <civodul>paroneayea: you mean you fixed the aggregator think? or some other freedom-related issue? :-) <paroneayea>civodul: no, I mean the package "freedoom" <- notice two o's! <paroneayea>so with a free doom engine, you can play a fully libre (code and assets) game! <paroneayea>unfortunately, I *really* need to add a cpu frequency scaling service, because I crashed my laptop again :) <efraim>also the only thing directly using webkitgtk@2.4 is webkitgtk/gtk2, which is only used by gnucash <fps>hi, legal question: the scheme code that makes up a package "recipe" that is not part of guix' tree has to be licensed compatibly with the guix code base, right? <fps>as it's a derivative work? <efraim>webkitgtk on aarch64: phase `build` succeeded after 39154.4 seconds <fps>how about the stuff that gets packaged? does it have to be licensed compatibly, too? <paroneayea>fps: the packages (as in, the software being packaged) themselves do not strictly hae to be licensed under anything compatible <paroneayea>fps: to make it into guix upstream, they need to be free software licenses <paroneayea>eg we have some eclipse public licensed software packaged in there iirc, and that isn't gpl compatible, but it is free <paroneayea>so package definitions: must be gpl compatible. packaged software: must be freely licensed, if going into guix proper, but if external there are no requirements <fps>paroneayea: talking strictly out of upstream here.. <fps>ok, thanks a bunch for the info <jmd>Is there any chance of predicting when core-updates will merge, or is it just a "when it happens" thing? <efraim>normally depends on the build failures vs master <jmd>efraim: And how is it looking now? (Sorry I just can't fathom how to use hydra's web interface) <jmd>efraim: So if I interpret that correctly, then right now more packages are building successfully on core-updates than on master? <efraim>jmd: if they were canceled on master then building successfully counts as newly succeeding <lfam>I've never used that Hydra view: of master, compared to core-updates. Usually I look at it the other way around <lfam>By the way, now is the time to fix your favorite leaf packages if they are failing on core-updates. <lfam>It's not fair to make a handful of us fix that leaf package that you care about :) <jmd>How do I git a list of failing leaf packages on c-u ? <lfam>It might take a few minutes to load the page... patience :) <lfam>The failures with the brown icon are failing because some other package failed to build. The red icon indicates that that package is the one that failed to build <jmd>Ahh thanks. I always wondered what the colours meant. <lfam>If the build failure appears non-deterministic or spurious (SSH connection failure, out of memory, etc), let me know and I'll restart the build <roptat>hi, I have an issue compiling guix sources <jmd>Bad way to represent pertinent data BTW. Useless for the colour blind and people with monochrome monitors. <lfam>jmd: I agree. It's really frustrating and my vision is more or less fine <lfam>roptat: What did you try and what goes wrong? <jmd>lfam: When I load that page I see only one package and that's yellow. <lfam>jmd: Click on the "newly failing jobs" tab <roptat>I nevermind, I wasn't in the environment <roptat>I had some guile2.2 errors in bootstrap, but using a fresh clone makes solved the issue <pmikkelsen>Hi guix! I have just made my first patch and send it of to guix-patches@gnu.org <bavier`>pmikkelsen: that would be the right place <jmd>lfam: Is there a way to filter it so that I see just the red ones? <lfam>jmd: I haven't found a way :( <bavier`>in emacs-debbugs you can sort by state <pmikkelsen>bavier`: Okay, I just had to make sure. The manual says guix-devel as far as I can see ***jonsger1 is now known as jonsger
<lfam>pmikkelsen: The online manual gets updated when we make a new Guix release. But, I *think* we updated the manual in the Git repo to mention guix-patches. Please let us know if not :) <pmikkelsen>lfam: Yes, it is updated in the git repo. Thanks :) <lfam>efraim: Have you tried core-updates on armhf at all? <jmd>lfam: I suggest that it is worth putting a that link on the website somewhere along with an explanation. I suspect the majority of people have no idea how to generate or interpret such a list. <lfam>efraim: It seems to be failing immediately due to cached failure of the gcc-4.9.4 tarball. But, gcc-4.9.4 is built for armhf. <lfam>jmd: Yeah, or maybe in the manual <lfam>It took me a while of exploring to learn this much <lfam>It doesn't help that the website is typically slow as molasses <jmd>That page lists pspp on X86_64 in red. <jmd>So I thought I'd fix it. <jmd>I checkout core-updates, do a git pull, then ./pre-inst guix build pspp expecting it to start building - and low and behold I get a substitute downloaded. <jmd>If it's failed how on earth is there a substitute? <lfam>Do you have a link to the pspp failed build page handy? <lfam>Now you are getting a taste of why it takes a while to do these core-updates cycles :) <lfam>jmd: From that page, click the "inputs" tab. It shows which Guix Git commit it's building from. Does that correspond to your Git checkout? <jmd>No. I have one more commit. <lfam>Hm, maybe try building from that specific commit <jmd>Ah yes. Now it starts building! <efraim>lfam: I don't actually have an armhf machine, haven't yet figured out how to get my aarch64 machine to build for armhf <lfam>jmd: Okay, so we can check pspp off the list :) <jmd>But that one commit relates to wget. I can't imaging how that could affect it. <lfam>I wonder where that substitute came from, however. <efraim>i think that coreutils on armhf it lost the ssh connection <lfam>efraim: Yeah, it looks like that, but I've tried restarting it. I don't know how to clear the cached failure of the GCC tarball <lfam>That version of GCC appears to have been built for armhf <efraim>chronological, that's the word I wanted <lfam>efraim: Oh yeah? I can't tell <lfam>There is so much tribal knowledge with Hydra :( <lfam>jmd: Another good test of core-updates is to do `guix package -u .` or `guix system reconfigure` from the core-updates branch <lfam>Perhaps impractical with graphical systems, but definitely doable for headless systems and non-graphical packages <jmd>The latter sounds a bit dangerous. <lfam>I'd argue it's more dangerous if we never do it :) <efraim>I still like `guix package -I | cut -f1 | sort -u | xarge ./pre-inst-env guix build' <lfam>If nobody does it, then we end up merging serious bugs into master <jmd>Well it depends on your perspective. <lfam>Anyways, I did it one week ago and everything is fine :) <jmd>Great. Then the serious bugs are only in your system! :) <lfam>Assuming the GRUB tests work, I don't think there are many ways to break your GuixSD system by reconfiguring on core-updates <efraim>aarch64 I think my targets are gtk, gtk2 and mesa <lfam>I do expect some of the other Guix hackers to do this. I think it's the right thing to do near the end of the core-updates cycle <lfam>Otherwise we end up releasing serious bugs like the one fixed by 9f58fe3d1c32e3f0ced065e286532a10cad1b5e3 <lfam>Where locales didn't work on GuixSD <lfam>One can always roll-back after testing for a while. And I don't expect anyone to do this in a production environment. But I think it's fine for a workstation <lfam>efraim: I don't think the failures are listed chronologically, because that build says it failed in 2 seconds. That sounds like a cached failure. <jmd>Looks like pspp is not fixed after all :( <bavier`>building a vm from your system config on core-updates would be enought, too, no? <lfam>bavier`: Sure, if you try to live in it for a while <lfam>That locales bug didn't stop anything from building or booting. You had to actually try using some applications to discover it <lfam>Although, VMs might not catch issues with system initialization on real hardware <lfam>Anyways, I understand that everyone has their own tolerance for risk. I would really like it if a handful of us tried using core-updates "for real" before we merge it to master <lfam>My x86_64 headless GuixSD system is working fine for ~1 week on core-updates :) <jmd>ohhh. What does this mean: +/tmp/guix-build-pspp-0.10.2.drv-0/pspp-0.10.2/src/ui/terminal/.libs/pspp: Relink `/gnu/store/vis7x2j2lsmwbl5m5w794c23ysqah8xh-libpng-1.6.28/lib/libpng16.so.16' with `/gnu/store/rmjlycdgiq8pfy5hfi42qhw3k7p6kdav-glibc-2.25/lib/libpthread.so.0' for IFUNC symbol `longjmp' ? <jmd>The errror is in libpng16 and not pspp? <lfam>I was going to suggest checking for a bug fix in the development repo, but I guess you'd know :) <jmd>It's also showing a similar error for libfreetype <efraim>looks like I did a terrible job with my mesa patch, found another typo <lfam>You need a source-code spellchecker! <jmd>Well its going to take ages to rebuild but it would seem to me that both libpng and libfreetype need to have (arguments `(#:configure-flags '("LDFLAGS=-lpthread"))) <efraim>fun times, but better in core-updates than a graft <pmikkelsen>Maybe I am doing this the wrong way. The patches I send to guix-patches hasn't showed up anywhere yet, but I sent them 2 hours ago <pmikkelsen>Can someone guide me on how to do this? I just used git send-email to guix-patches@gnu.org <jmd>pmikkelsen: It could be that the mailing list server is overloaded. Sometimes it happens. <pmikkelsen>jmd: Oh okay, I'll wait till tomorrow then, thanks. ***Steap_ is now known as Steap
<quiliro>Mi kompletas instali claws-mail kun vortaro esperanta <quiliro>claws-mail will not work with spell checker <quiliro>i have an error message every time i create a new mail message <quiliro>No se puede iniciar el corrector ortográfico. <quiliro> No se pudo inicializar el diccionario Ninguno: <quiliro>No se pudo inicializar el corrector Ninguno. <quiliro> that says that the spell checker could not be started <quiliro>and that the dictionary none could not be started <quiliro>guix package -i aspell-dict-es aspell-dict-eo aspell-dict-en enchant <catonano>quiliro: I don't know claws mail but I was wondering: is the dictionary a claws mail plugin ? Or is it a standalone package ? <quiliro>catonano: in #claws they say it works with hunspell <buenouanq>quiliro: the claws-mail dictionary thing is a long standing issue that as far as I know, no one's figured out yet <quiliro>buenouanq: claws-mail needs to be built with libenchant support <quiliro>buenouanq: you can't add it afterwards <quiliro>buenouanq: that is what claws main developer said <quiliro>i guess guix does not build claws-mail with libenchant support <quiliro>and i do not know how to change that <fps>how does the usual gc work on the store. could something similar be achieved for guix packs? <paroneayea>fps: I think at the point where you want gc from guix packs, just run guix as a package manager ;) <civodul>paroneayea: thanks! glad you liked it <buenouanq>quiliro: will you submit that in a report if you havn't yet <fps>paroneayea: haha, true. side note: i wonder if it would maybe make sense to have a guix pack to install guix and the build daemon (would be different for different host OSs) <civodul>fps: just do "guix pack foo bar baz guix --localstatedir" <fps>civodul: i have to play around with the current guix to grok your comment :) <civodul>what i meant to say is that you can add Guix itself to the pack <fps>yeah, that part i understood. i wondered about setting up the daemon, too, though <civodul>you'd still have to set it up by yourself <civodul>i mean creating the build users etc. <rekado>lfam: I just fixed bristol on core-updates. <rekado>lfam: the next build failure I’m looking into is related to openjpeg. <rekado>lfam: the patches to fix CVEs no longer apply cleanly. Do you have a fix for that? <lfam>rekado: How do they fail to apply? Did openjpeg get updated? (I can't try the build at the moment to see what you mean) <fps>hmm, my guix pull just failed on gnutls... <fps>the test name-constraints failed <quiliro><bug-guix@debbugs.gnu.org>: host debbugs.gnu.org[xxx.xxx.xxx.xxx] said: 550 <quiliro> Unrouteable address (in reply to RCPT TO command) <rekado>lfam: there are a couple of hunks that fail. <rekado>lfam: there isn’t much more info there.\\ <rekado>lfam: I’m just asking because you appeared to have adjusted the patches and the version to ungraft fixes. <civodul>fps: are you upgrading from an old Guix? an old GnuTLS had that problem... <fps>civodul: yep. pretty old. probably 0.10 binary release or so <lfam>fps: Unfortunately you won't be able to build gnutls unless you roll-back your system clock <lfam>I recommend *not* doing that <quiliro>also...claws-mail dev said that not showing several images embedded on mail will be checked <fps>lfam: sooo, get a newer guix binary release? <lfam>fps: Well, you can do the clock thing if you understand that many other things might break :) <lfam>For example, HTTPS certificate validation will not work properly in many cases. <quiliro>i had an email that had 4 images but only 1 would be show on the view....but i could open all 4 <lfam>We kept that substitute around for a long time but I guess it's gone now <lfam>Come on, there's no need to insult other projects here, quiliro. <quiliro>i am not insulting i just say i don't like it and that it hurts <rekado>quiliro: it’s better to say it directly like that. <lfam>Also, I think it's not welcoming towards fps. Let's try to welcome everybody and help them with Guix :) <lfam>I think it's a bit of risky maneuver. You *could* do the build on a "throwaway" system, for example another machine or a VM. Then, use `guix archive` to make the built binary substitute available on your primary machine. <quiliro>rekado: lfam: i guess you are right... i am sorry fps...please disregard those comments i made <lfam>fps: If you did that, you'd also need to authorize the signing key of 2nd machine before you decommission it for good <fps>lfam: yeah, sounds like a hassle. i'll see if i can find info on updating my guix install with a newer binary release.. <lfam>Overall, that gnutls bug is a real pain in the context of functional package management. I'd hoped that nobody would be experiencing it at this point <fps>i might just try to copy the contents of the tarball over the old ones ;) <quiliro>fps: please feel welcome with guix in ubuntu <fps>quiliro: thanks. fyi, i also have a guixsd system running.. i'm not a sith and don't deal in absolutes ;) <lfam>Alright, I've fixed my Guix installation. I'll look at the openjpeg issue now, rekado <lfam>(Don't do `./pre-inst-env guix package -u guix` unless you're sure about the state of the work tree!) <fps>was that last comment directed at me? <lfam>No, it was for everyone :) I did that and ended up with a broken Guix! <lfam>Well, that's what I think happened, anyway <lfam>civodul: What I observed was that any Guix command that might build things got stuck in `guix substitute` until $localstatedir ran out of disk space (>2 GB) <lfam>civodul: I think that my tree must have contained compiled objects from different branches, or something like that <lfam>Actually, even `guix package -S` got stuck in `guix substitute`. I'm not sure if `guix package -S` is expected to build things <lfam>I should have kept an strace log of `guix substitute` but I didn't <civodul>i've seen 'guix substitute' enter an endless loop a couple of times <lfam>Even with --no-substitutes it was still doing something with narinfos, according to strace <civodul>but rm -rf /var/guix/substitute fixed it and then it did not come back <civodul>what you describe here sounds even weirder :-) <lfam>If it happens again I'll make a bug report <fps>at least irc doesn't break with a bad date ;) <fps>lfam: fudging the date seems to have worked. ty <lfam>rekado: openjpeg should be fixed now <rekado>lfam: thank you! This should fix quite a few other packages! <lfam>Yeah, sorry about the earlier commit. I guess I didn't try building it at the time <lfam>Either that or something got lost in a merge <fps>boost 1.60 seemsto be gone as well.. <civodul>lfam: i'll see what i can do with coreutils on arm <fps>nah, it's still there. it just seems to have been redirected to https and then <fps>;;; Failed to autoload make-session in (gnutls): <fps>;;; ERROR: missing interface for module (gnutls) <fps>the other mirrors are html though <lfam>fps: What command results in that? <lfam>Try doing `guix environment --ad-hoc gnutls` first <fps>installing nss-certs now.. <fps>ok, will try when that fails <fps>lfam: no dice. need to sleep now though :(