IRC channel logs


back to list of logs

<civodul>just pushed minutes ago :-)
<civodul>ACTION starts an eval of core-updates
***kelsoo1 is now known as kelsoo
<quiliro>i would like to understand why a package definition is the way it is. i have read bit i do not get the hang of it. i would like to compare each mark with the contents of the source of a package such as the hello package
<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>i know this in theory
<quiliro>or rather, i understand it
<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.
<sneek>Apteryx, lfam says: The Savannah admins recently disabled cloning via cgit:
<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>lfam: yes!
<quiliro>would someone please guide me with respect of making guix packages according to what i asked?
<lfam>quiliro: I recommend trying to adapt a simple package that already exists. For example, this package:
<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>Okay. Each element of the package definition is a Scheme procedure. Some of these procedures are defined in the Guix source code, and some of them come from Guile. So, you can check if they are part of Guile by looking for them in the Guile procedure index:
<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
<quiliro>lfam: what i ask is: where are the places the data about the Hello package specifically in come from?
<lfam>What do you mean by "data"?
<quiliro>for example: name "hello"
<lfam>quiliro: The person that packaged hello decided to call the package "hello"
<quiliro>ok...that is good
<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
<quiliro>(inputs `(("gawk" ,gawk)))
<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 all the source of Hello?
<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
<quiliro>for the Hello package
<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
<quiliro>is it not in the scm file?
<quiliro>the link
<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'.
<quiliro>where is guix/download.scm
<lfam>In the Guix source code
<quiliro>where is that?
<quiliro>lfam: i found it!
<quiliro>but there are no mirrors
<quiliro>in that file
<Apteryx>quiliro: Are you sure you are looking at guix/download.scm?
<Apteryx>It's all under: (define %mirrors
<quiliro>i am looking now at ~/.config/guix/latest/guix/download.scm
<Apteryx>That's the one.
<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:
<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
<quiliro>i cannot find hello directory
<quiliro>in that server
<Apteryx>quiliro: You're looking at the gcc mirrors.
<Apteryx>I see it there.
<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`
<quiliro>warning: collision encountered:
<quiliro>this is not a problem?
<quiliro>where is the source?
<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>guix build --source hello
<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>lfam: wasn't it extracted already?
<quiliro>i have extracted and i have read README, INSTALL, TODO and doc/
<quiliro>i would say i have skimmed
<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>but i want to learn by example
<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.
<bill-auger>that statement amazes me
***jonsger1 is now known as jonsger
<catonano>where do I find a sheet table of info tags (for writing description fields) ?
<civodul>Hello Guix!
***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>i think it's ok
<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>hi guix
<buenouanq>Happy Vernal Equinox!
<thomasd>buenouanq: thanks, looking forward to summer :-)
<buenouanq>we're halfway there!
***kelsoo1 is now known as kelsoo
<efraim>Webkitgtk takes a long time to build on aarch64
<braunr>it takes a long time everywhere
<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
<jonsger>rekado: just look here
<roelj>There's a type: "and you the command returns in" -> "and the command returns in
<roelj>typo* haha
<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?
<thomasd>CharlieBrown: any suitable place is fine with me (though at least an announcement/link on the Guix homepage would be useful). where ist that instance? I only know of and
<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: does not pull (guix config)
<pmikkelsen>test-name: current-build-output-port, UTF-8 + garbage
<pmikkelsen>I dont know if it has any effect or this is expected
<CharlieBrown>thomasd: or something.
<adfeno>CharlieBrown thomasd: Sorry, I just came by, what is the address that you want to know about?
<adfeno>I know about, and
<CharlieBrown>maybe its the libreplanet one.e i know it's a gmg instance
<CharlieBrown>so not audio-video
<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>thanks jonsger
<civodul>jonsger: it looks like the whitespace-around-em-dash topic is controversial: :-)
<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
<civodul>jonsger: also
<civodul>rekado: yeah depends on the font
<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>heh :)
<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.
<CharlieBrown>ohh idk if fosdem is
<CharlieBrown>i thought it was gnu stuff
<CharlieBrown>rekado: save your config file?
<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”?
<civodul>sounds good
<rekado>(i.e. mentioning “Windows”)
<civodul>ACTION updates the file
<civodul>yeah good idea
<rekado>I like the section “Wait, didn’t you say …”
<civodul>we owe it to Federico i guess :-)
<rekado>it’s a very good article. Thanks for writing it!
<civodul>cool, thanks for the review!
<civodul>i'll upload it
<davexunit>ooh new blog post?
<civodul>davexunit: ↑
<jmd>Does nix have anything similar to guix pack ?
<civodul>jmd: recently i read about "nix-bundle", which is similar in spirit
<civodul>it's outside of Nix proper
<jmd>I see. Thanks.
<davexunit>civodul: cool!
<davexunit>really nice writing
<davexunit>posted to HN
<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>but cuirass fails to start
<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>thomasd: yes, i think so
<civodul>or people producing the packs can do "guix pack foo bar guix --localstatedir", which includes a full-blown Guix
<thomasd>probably a better solution :P
<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
<Apteryx>No substitute for Firefox 45.7.0?
<rekado>Apteryx: we don’t have a package for Firefox.
<rekado>we have a package for Icecat.
<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..
<roelj>Why is that?
<davexunit>civodul: your post is on the HN front page now
<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.
<roelj>rekado: Oh right
<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>I'll add him to the THANKS file
<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.
<davexunit>know nothing, make bold claims.
<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>it's not a valuable opinion in this case
<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.
<davexunit>gazon: thank you :)
<adfeno>gazon: Thanks! :)
<bavier`>warm fuzzies
<civodul>davexunit: when i read the atom feed of via gwene, it's all upside down
<civodul>like the text is reverse, links appear in the wrong place, etc.
<civodul>are we doing something wrong?
<davexunit>civodul: whoa, really? I have never seen that
<civodul>me neither
<civodul>and the web page itself is fine:
<davexunit>yeah that looks just fine to me
<davexunit>the feed renders fine in firefox
<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>which is suspicious
<davexunit>only our posts have this
<davexunit>apparently it doesn't make a difference to the firefox feed reader, but gnus goes bananas.
<civodul>yeah i'm using Gnus
<davexunit>so why does this feed aggregator think it's non-html?
<paroneayea>freedoom works
<paroneayea>ACTION lost 15 minutes to it
<paroneayea>fun :)
<davexunit>oh neat :)
<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>it's a libre implementation of DOOM assets
<paroneayea>so with a free doom engine, you can play a fully libre (code and assets) game!
<paroneayea>it was posted to the bugtracker, I just ran it
<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
<paroneayea>that's why i only lost 15 minutes ;)
<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
<paroneayea>fps: yes
<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>but not strictly gpl compatible
<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
<paroneayea>fps: np :)
<civodul>paroneayea: oooooh, got it :-)
<civodul>sounds fun
<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>Here you can see things that are failing on core-updates, but not on master:
<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
<lfam>This is the better link, I meant to provide it:
<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
<pmikkelsen>Is this the correct thing to do
<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?
<lfam>efraim: I'm wondering about the persistent failure of coreutils:
<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>I'm a bit lost :)
<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>This is silly.
<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>will do.
<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>efraim: Alright
<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>I thought it was time-ordered
<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/' with `/gnu/store/rmjlycdgiq8pfy5hfi42qhw3k7p6kdav-glibc-2.25/lib/' 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
<efraim>svrast instead of swrast
<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
<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>.tra eo es -m kompleti
<quiliro>.tra -m eo es kompleti
<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
<quiliro>but no luck
<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 ?
<paroneayea>civodul: I finally read
<paroneayea>and it's a really nice blogpost!
<quiliro>catonano: in #claws they say it works with hunspell
<quiliro>i am installing it
<buenouanq>quiliro: the claws-mail dictionary thing is a long standing issue that as far as I know, no one's figured out yet
<buenouanq>if you can, I will love you forever
<buenouanq>it's a guixsd specific problem
<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>by default
<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>oh right, sorry
<civodul>you'd still have to set it up by yourself
<civodul>i mean creating the build users etc.
<fps>yeah.. hmm.
<lfam>civodul: What do you make the armhf coreutils build failure? <>
<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...
<quiliro>buenouanq: bug report sent
<lfam>fps: How did it fail?
<fps>the test name-constraints failed
<quiliro><>: host[] 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.\\
<civodul>quiliro: try
<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, civodul: Prior discussion:
<quiliro>civodul: sent
<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?
<fps>ACTION is on ubuntu
<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>Otherwise, I'm not sure
<lfam>We kept that substitute around for a long time but I guess it's gone now
<quiliro>fps: yuck
<quiliro>are you masochist?
<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
<quiliro>to use it
<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 :)
<fps>hmmm, i guess i'll go with a newer guix binary release then. the information on how to tweak the clock is not directly obvious, even from the linked ticket
<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
<lfam>Also quite risky :)
<fps>hrmpf :)
<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
<civodul>lfam: what can go wrong?
<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>so i don't know
<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 ;)
<gazon>Dead link in "see Introduction in Geiser User Manual" in the guix user manual "The Perfect Setup". Geiser "Introduction" is at
<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
<jonsger> what do I need to use guix download with github. other sites work
<civodul>jonsger: try setting SSL_CERT_DIR:
<fps>boost 1.60 seemsto be gone as well..
<civodul>lfam: i'll see what i can do with coreutils on arm
<civodul>ACTION -> zZz
<jonsger>civodul: oh thx.
<fps>nah, it's still there. it just seems to have been redirected to https and then
<fps>following redirection to `'...
<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?
<fps>lfam: guix pull :)
<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 :(