IRC channel logs

<ryanwatkins>are GSOC applications still open?

<CompanionCube>Don't they go into apri;

<efraim>Do feel free to introduce yourself on the mailinglist though :)

<efraim>nss failing on aarch64, that's not going to be fun to debug

<efraim>sneek: botsnack

<rd161616>Hi there, so far so good with guixSD, I just need to uncompress a few rar files but unrar give me the fail result, do you know another package than unrar to un rar please ?

<buenouanq>rd161616: rar has always been weird and I've never understood the legal issues surrounding it

<rd161616>Yeah but I need to open thoses files lol

<buenouanq>unar (not unrar) can unpack rars and is free software

<buenouanq>but I don't know if it's in the guix repos

<rd161616>It is not xD

<buenouanq>there is an argument that using nonfree software to liberate something is perhaps acceptable

<rd161616>Yep but how could I install lol

<buenouanq>assuming there's really no other way and you don't just put it back how it was

<buenouanq>I've yet to delve in to compiling/packaging things for GuixSD, but someone here can prolly help.

<buenouanq>It is pretty well documented as well I believe.

<efraim>why don't we build curl --with-gnutls ?

<efraim>of anyone knows

<buenouanq>if unar really isn't violating any licenses, someone should prolly package it for us all

<efraim>i don't know anything about unrar personally

<buenouanq>unar, not unrar

<rd161616>Yeah I don't have the knowledge to make it available to all

<catonano>rd161616: : yes, it's in guix. I reviewd the patch a ew days ago.

<catonano>rd161616: youu probably need to guix pull

<catonano>to update your packaged collection

<rd161616>Oh okai i type guix pull

<rd161616>Thanks man

<catonano>rd161616: :-)

<rd161616>I knew I made a good choice when I selected guixsd for my computer best community

<rd161616>Plus I don't know why the command line terminal is nicer than every other right

<buenouanq>within 5 years you're going to see every other distro and operating system [poorly] copying what guix and guixsd are doing

<buenouanq>that we ever didn't do package management and operating systems like this is retrospectively just crazy

<buenouanq>anyway, you did indeed make a good choice - welcome

<rd161616>Yeah I was using clear Linux by intel but too complicated everything goes In bundle

<rd161616>Once I made the pull how do I need to reboot to install unar ?

<buenouanq>catonano: I'm not seeing unar anywhere, only unrar.

<buenouanq> https://packages.debian.org/jessie/unar

<catonano>buenouanq: sorry, I misread

<catonano>the atch I reviewd is unRar

<rd161616>No problem can I still install the Debian package ?

<buenouanq>you can't just install their package, but you can build something you can run from their repos

<efraim>you can use 'ar' to get 'unar' functionality, 'ar t filename' to print the contents, 'ar x filename' to unpack filename

<buenouanq>what is ar supplied by?

<rd161616>File format not recognised :x

<efraim>ar is from binutils iirc, which should be there by default

<civodul>Hello Guix!

<efraim>hi!

<rd161616>Got it guys just compiled unrar non Free

<efraim>debian has a patch for openldap that removes the bdb version check, don't know if its really necessary though

<rd161616>Thx guys anyway for help

<efraim>civodul: from what I've read I should be able to run armhf binaries on aarch64 like x86_64 can run and build x86, is that difficult to implement in the daemon?

<efraim>also, I don't think properties '((timeout ... is honored, guile-next timed out on the armhf build slave on core-updates

<civodul>efraim: it should be easy, look for "personality" in libstore/build.cc

<efraim> http://hydra.gnu.org/build/1887033/log/raw

<civodul>efraim: fixed in 8f7ea70913107d07e2dea721b2f0b8fda1af24da thanks :-)

<jmd>I have a test which assumes that (isatty (STDOUT_FILENO) != 0) - is there any way to make this assumption hold in the guix daemon?

<civodul>just redirect stdin to a file?

<wingo>ACTION updates guile-next to 2.1.8

<efraim>I'm glad I didn't build 2.1.7 yet on aarch64 :)

<jmd>civodul: Nah. The test creates a pipe and then uses dup2 to connect it to STDOUT_FILENO. Then it attempts to call ioctl (TIOCGWINSZ,..) on that descriptor.

<jmd>The result is that the test works fine when run manually, but fails when run by the guix daemon.

<civodul>hmm, no idea

<efraim>python2 failures on core-updates http://hydra.gnu.org/build/1903274/nixlog/1/raw http://hydra.gnu.org/build/1896892/nixlog/1/raw

<roelj>I'm getting 'guix package: error: corrupt input while restoring archive from socket'.

<roelj>Any ideas what the problem could be?

<roelj>Is my store corrupt?

<catonano>where is aclocal in guix ?

<thomasd>catonano: in the automake package

<catonano>thomasd: thanks !

<wingo>roelj: could it be that a cached nar is corrupt?

<wingo>seems unlikely that your store is corrupt

<wingo>"restoring archive from socket" sounds like adding a downloaded NAR to the store, to me anyway

<rekado_>roelj: when using “guix archive” and/or nars from hydra note that compression may be an issue.

<roelj>rekado_: Have you ever encountered this error when the store is served from an NFS mount

<roelj>?*

<rekado_>roelj: I haven’t tried.

<rekado_>roelj: could you give me the exact commands you used?

<roelj>rekado_: Well, that's kind of hard, `guix package -i bwa' gives the error. But I suppose it's what went on before that, is causing trouble.

<roelj>We had /gnu on a disk, then rsync'd it to an NFS mountpoint. Then ran `guix gc --verify=contents,repair'.

<roelj>That ended with: error: cannot repair path `/gnu/store/gj2i5xs7nm80mwrb139pa8iqfccw08zz-guix-0.12.0'

<efraim>Write priveleges?

<roelj>Possibly.. Thanks, I'll troubleshoot it further

<civodul>Guile 2.1.8 in Guix! \\o/

<rekado_>my boss went to a conference in the US where he mentioned Guix in a talk.

<rekado_>people walked up to him and said they would try it, but they were also looking into singularity

<davexunit>brave of him to travel to the US

<ryanwatkins>great job everybody involved, I am glad to have discovered Guix and Scheme/Guile recently!

<rekado_>singularity is a container system, competing with Docker.

<jmd>rekado_: What do you mean singularity?

<rekado_>boss noted that communication between containers is pretty hairy, so having one container per R package, for example, simply wouldn’t be feasible.

<jmd>A black hole?

<rekado_>jmd: “singularity” is the name of a piece of software.

<jmd>oh

<rekado_> http://singularity.lbl.gov/

<jmd>You should have capitalised it!!

<rekado_>I ran out of a capital S after capitalising “us”.

<civodul>rekado_: you can thank your boss for spreading the word ;-)

<civodul>talking points and everything

<rekado_>he said that we should do more outreach work

<rekado_>more conferences, more blog posts, more examples

<rekado_>and: a Debian/Ubuntu package to simplify installation.

<rekado_>(doesn’t need to be official)

<civodul>ACTION agrees

<efraim>As far a i understand SUSE's OBS will build anything, so we just have to have it set up

<rekado_>I’m again working on the R story: using R from Guix without having to change the common workflow of installing packages with R’s “install.packages” procedure.

<civodul>rekado_: so your boss is going to send you to lots of conferences, is what you're saying? :-)

<rekado_>civodul: I suppose that’s one way to interpret it :)

<civodul>efraim: indeed; one idea i had was to eventually propose a replacement for the CI at https://hydra.nixos.org/project/gnu

<rekado_>I’m supposed to go to BOSC at ISMB in Prague.

<civodul>well, and not just GNU

<civodul>rekado_: "BOSC at ISMB"?

<rekado_> http://www.open-bio.org/wiki/BOSC_2017

<efraim>Bombin' Open Source Conference

<rekado_>“ISMB” is “Intelligent Systems for Molecular Biology”

<civodul>ok

<civodul>Prague is great anyway :-)

<rekado_>I agree :)

<rekado_>We’re planning to give two talks there: one about reproducible bioinfo pipelines (using Guix for the “reproducible” part), and another one similar to what you and I presented in Vienna, but with a stronger focus on the number of bioinfo packages we offer.

<civodul>sounds cool

<roelj>rekado_: Here's work on a Debian package: https://github.com/detrout/debian-guix

<efraim>I no particular order, the wife is willing to consider GHM as part of a summer vacation trip, I was thinking of packaging debootstrap and dpkg and maybe some other tools

<civodul>:-)

<roelj>Has anything in the protocol between guix and guix-daemon changed since the 0.12.0 release?

<civodul>roelj: yes, see deac976d3d26c7b85b9c90efb424b0aa94f1027c

<civodul>that is supposed to be backward-compatible

<roelj>Hm, so if I run the daemon from 0.12.0, and run guix with the latest Git checkout, it should work just fine?

<civodul>yes

<civodul>if it doesn't, you'll have to send more details :-)

<roelj>Of course :) I'm not sure what the problem is I am having, so I'll have to dig deeper first

<efraim>Mesa still cant find libdrm on core-updates

<efraim> https://cgit.freedesktop.org/mesa/mesa/tree/configure.ac?id=71f3ff57fa67ef72630821f4fa13a17e264d7ccb#n74 this isn't supposed to mean exactly 2.4.61, right?

<civodul>it has:

<civodul>PKG_CHECK_MODULES([INTEL], [libdrm_intel >= $LIBDRM_INTEL_REQUIRED])

<civodul>so it means 2.4.61 or greater

<efraim>Oh, my thought about gccgo@5+ is despite #:separate-lib? #f it still disallows references to lib, even if its $out/lib

<sirgazil>Hi!

<jmi2k>Hi sirgazil!

<sirgazil>:)

<sirgazil>Do you see what's wrong with this manifest file: https://paste.gnome.org/pwx8xskty ?

<sirgazil>I'm getting this error: https://paste.gnome.org/psljem4qs

<roelj>sirgazil: I think there's no package variable names 'guile'. There is 'guile-2.0' and 'guile-1.8' though

<sirgazil>Oh, I see. I'll try that...

<sirgazil>roelj: Yes, that was the problem, thanks :)

<ng0>there's no xsane as far as I can tell, how do you use image scanner of printer/combinations in Guix?

<ng0>command line scnaning with sane-backends?

<davexunit>could be that no one does that yet

<davexunit>you'll need to package the needed tools

<ng0>okay

<ng0>I hope it just has one dependency. Otherwise I'll just use snailmail for now

<efraim>I used simplescan, but its no xsane

<ng0>all I ever used was xsane… so maybe simplescan works too

<ng0>it's not packaged though, or uses a different name

<ng0>ah, simple-scan

<davexunit>oh darn, I never pushed the guile 2.1.8 update

<ng0>I'll be back :)

<davexunit>I was waiting for 2 full builds to finish

<davexunit>looks like wingo ended up doing it

<davexunit>thanks wingo

<wingo>np, i just tested one build

<wingo>i don't know if it's actually reproducible

<davexunit>wingo: oh well in that case I have some news: it's reproducible

<wingo>wow cool!!!

<wingo>that's great :)

<davexunit>'guix build --rounds=2' didn't scream at me, at least, which I take to mean that it's all good

<roelj>Why is there such a big difference in download speed from mirror.hydra.gnu.org? Sometimes it downloads with a couple of megabytes per second, and sometimes it crawls at 100/150kb/s..

<davexunit>roelj: cache hits are fast and cache misses are slow

<roelj>Ah okay

<ng0>right on, simple-scan was enough

<civodul>davexunit: thanks for testing!

<ng0>Guix has (so far) no problem with the company/product Guix, I suppose if there's already a name with something you want to offer and it's named exactly the same but acts in a different branch (whiskey vs software) it's not so difficult, right? it's not like some irish whiskey brand will come after me for using the same name. Though I'm considering a different name because … whiskey. bad marketing.

<bavier`>that a name overlaps with the same name applied to something completely different is not "marketing" per se

<ng0>I meant, bad choice of association, depending on how you value the other entity

<ng0>I need to look into how popular/known this brand is. Association with a whiskey brand is nothing I prefer

<jmd>ng0: Well, there is a trademark "Guix" registered in the software category. So far the trademark holder hasn't registered a complaint. Civodul's approach was to deal with that problem when it arises.

<ng0>ah :)

<ng0>I came up with an idea for a name as a cover/banner for several projects, but then I ran into whiskey. http://pragmatique.eu/

<ng0>it will not be a problem I guess, but it's just not nice.

<ng0>s/I guess//

<jmd>Whiskey and software are hardly the same trade category.

<ng0>yeah.

<ng0>unless you a jack of all trades as a pirate, merchant, and also software cracker

<jmd>I've installed gcc-toolchain but gcc seems not to be able to find all the necessary prototypes to compile simple unix programs. What else do I have to install?

<quiliro>if i do not 'guix pull' i will use older software?

<jmd>quiliro: In general, yes.

<quiliro>if i 'guix pull' as user (not root) will i use the latest software or the ones root uses?

<ng0>you can also have pull via https now

<quiliro>i would like a guix pull that contains only binaries

<ng0>you are confusing it with 'guix package' I think

<bavier`>quiliro: if you do not 'guix pull' as a user, yes, you will use whatever is installed in the system profile that root created with 'guix system reconfigure'

<bavier`>assuming you don't have the package installed in your user profile

<lfam>ACTION Prepares the getentropy() bug fix for Python 2.7 on core-updates

<efraim>mass rebuilds on my end :)

<efraim>lfam: did you build out to mesa? having trouble with libdrm_intel?

<lfam>ACTION checks

<lfam>So far, I don't know if I got to mesa or not. As of the latest core-updates, I don't have mesa built. When I try building on core-updates, it's by reconfiguring my headless GuixSD system on x86_64. So I miss lots of graphical packages

<sneek>lfam, you have 1 message.

<sneek>lfam, civodul says: thoughts regarding CVEs with unspecified versions? https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00180.html

<lfam>sneek: Go away and eat your botsnack :)

<sneek>:)

<lfam>efraim: I'll try building mesa now

<efraim>lfam: thanks

<efraim>i got a fix for fcitx, turns out some of their infrastructure was on google code, now they're on github

<civodul>rekado_: on openstack & hpc: https://www.openstack.org/assets/science/OpenStack-CloudandHPC6x9Booklet-v4-online.pdf

<civodul>& marketing too ;-)

<lfam>civodul: The Savannah admins pointed out our use of Cgit for `guix pull`: http://lists.gnu.org/archive/html/savannah-hackers-public/2017-03/msg00023.html

<lfam>Probably no action is required, but I like to keep that line of communication open and friendly :)

<civodul>bavier`: see also ↑

<civodul>lfam: fun :-)

<civodul>i hope we're not the only ones filling the disks at Savannah

<lfam>The space they have available for their cache is not enough, IMO: http://lists.gnu.org/archive/html/savannah-hackers-public/2017-03/msg00013.html

<slyfox>tried 'guix pack' today. 'guix build re2c' returns instantly as binary is on disk. 'guix pack re2c' fetches things and builds it. how to find out the difference?

<civodul>slyfox: 'guix pack' needs to build the tarball itself

<civodul>so it doesn't return instantly, even if re2c itself is already on disk

<civodul>lfam: yeah, with all the projects, it's probably filling up quickly

<slyfox>i mean 'guix pack' builds things like boost and guile

<civodul>they could be dependencies of the profile itself

<civodul>or it could be due to grafts

<civodul>the usual suspects

<slyfox>should 'guix build re2c --no-grafts' try to build exactly the same set of packages as 'guix pack'?

<efraim>any objection to merging master into core-updates?

<civodul>slyfox: same as 'guix pack re2c --no-grafts'

<civodul>efraim: nope, good idea!

<civodul>lfam?

<thomassgn>Lately I've been having to figure out which packages provide certain binaries, like context which I found in texlive/tex.scm. Is there some way of searching through what the packages will output?

<civodul>efraim: well i guess that's an ok from lfam :-)

<efraim>ok

<civodul>thomassgn: usually "readline -f $(which something)" gives a good idea

<civodul>that's the fanciest thing we have for this

<rekado_>“The meaning of openness for OpenStack is prescribed by the Four Opens: open source, open design, open development, and open community.”

<rekado_>seriously? The “four opens”?

<slyfox>civodul: http://dpaste.com/1PPXXMT.txt . perhaps it's just a pack/lzip dependency closure.

<civodul>slyfox: among other things, it needs to build guix to build the tarball

<civodul>this is because the tarball contains a full-blown store, with /var/guix/db

<slyfox>aha!

<quiliro>bavier`: ng0 is right i want the database of packages to be downloaded to be only binary

<thomassgn>civodul: thanks, though wouldnt give me results for packages not on my system I assume

<efraim>Depending on how big your store is and how many different packages you have locate can help

<efraim>But nothing like apt-file yet

<efraim>ACTION is building guile-2.1.8 on aarch64 overnight

<civodul>thomassgn: right, that's a limitation

<civodul>"guix build guile-charting --with-input=guile=guile-next --check" tells me it's reproducible \\o/

<thomassgn>hehe, well well.

<AndChat306516>Guix on bootup is spawning a guile session saying: my-root: Inodes that were part of a corrupted orphan linked list found. my-root: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. File system check on /dev/sda1 failed: spawning bourne-like repl

<AndChat306516>I'm not sure how to run fsck though?

<AndChat306516>It's not provided in ,bournish

<civodul>AndChat306516: normally you should find fsck.ext2

<AndChat306516>I don't have the find command

<catonano>AndChat306516: just issue "fsck.ext2 /dev/sda1"

<catonano>that's wat civodul meant

<AndChat306516>In execvp of fsck.ex2: No such file or directory

<AndChat306516>That's what I get

<catonano>I can't help you anymore, sorry

<catonano>but

<catonano>wait

<catonano>it's fsck.ext2 you seem to have missed a t beore the 2