IRC channel logs

2017-01-25.log

back to list of logs

<baconicsynergy>hello beautiful people
<adfeno>Hi baconicsynergy :)
<lfam>Howdy
<jmi2k_>Reading the mailing list I noticed neovim was added along with its dependencies...
<jmi2k_>I was working on it but someone got it before :D https://github.com/jmi2k/guix-recipes/blob/master/jmi2k/packages/neovim.scm
<jmi2k_>Well, at least it's way better packaged than my attempts.
<ng0>there's also neomutt or whaterver it was called, if someone wants to review it :)
<ng0>Quick draft start, is this the correct way to start with this? Or would we want to replace openssl by default? I seem to recall that at least the system "Alpine" switched to it by default. https://pagure.io/guix-dev/commits/tls/libressl-everything
<ng0>all I did was inherit original, and replace any "openssl" with "libressl" in the new package
<ZombieChicken>anyone know what the program name is that provides terminal info so that programs like vim know what the terminal is capable of?
<happy_gnu>ZombieChicken: interesting
<cantstanya>ZombieChicken: tput(1)?
<ZombieChicken>Not sure. tput at least looks like it's close
<cantstanya>although ``programs like vim'' probably don't need to system() for that.
<ZombieChicken>yeah. I'm reasonably sure ncurses is looking for something itself
<ZombieChicken>oh well
<cantstanya>maybe its getwin(5)?
<cantstanya>s/5/3x/
<efraim>libelf failed configure on aarch64
<catonano>good morning, guix :-)
<buenouanq>the night is young~
<ng0>hardened tor build looks functional
<ng0>expected nothing else
<ng0>I'll send the patch now
<ng0>how could I express "version without dots" for a file name? do we have that?
<ng0>src name, sorry
<ng0>of course I could just call it version 715 instead of 7.15
<ng0>ah, I can take the gnurl example
<adfeno>ng0: About version without dots: As far as I know, you have to use a regular expression to match only "." and replace with nothing.
<adfeno>Assuming "." is properly escaped, that is.
<efraim>I think until we get something working for coreutils-8.26 it might be best to just revert the update
***ShalokShalom_ is now known as ShalokShalom
<ng0>i did
<ng0>now i have to construct something to prevent the gnu build-system from thingking that file COPYING is the source
<adfeno>ng0: Care to explain the situation in detail?
<ng0>no I can handle it myself
<ng0>ok... why can't I replace the unpack phase in the gnu-build-system?
<adfeno>ng0: Is it by chance a (tar/zip)bomb of somesort?
<ng0>no
<ng0>just a zip file lacking any directory structure
<adfeno>Hm.... so you open the zip file, and you immediatelly see lots of files?
<ng0>yes
<adfeno>Hm.
<ng0>I just need to replace the unpack phase
<adfeno>It's zipbmb
<ng0>but it doesn't work
<adfeno>We might be able to explore the mailing lists to take examples from my previous issue with the Crypto++ zipbomb.
<adfeno>Let's see...
<adfeno>I remember that the example given to me worked.
<ng0>but zpaq is not really a zipbomb.. it's just a single directory
<adfeno>Then perhaps you have to move it to inside another directory.
<ng0>i tried by replacing in the unpack phase
<ng0>which doesn't work
<nckx>ng0: are you packaging zpaq? You seem to have the same problem I did.
<ng0>yeah I kinda need it.. :)
<ng0>I already submitted one package which had the same problem (no directory) but for this one it just worked
<ng0>but the other one had a directory inside
<ng0>so I just had to cd ..
<nckx>I think I have a working package, it just needs a snippet to remove some pre-compiled binaries.
<ng0>now I wanted to replace unpack and add a mkdir src; cd .. but it didn't work
<ng0>yeah the .exe
<ng0>would be cool if you can submit it :)
<nckx>ng0: I'll do so now :-)
<ng0>thanks :)
<adfeno>ng0: See: http://lists.gnu.org/archive/html/guix-devel/2016-09/msg01983.html
<adfeno>Now we just need to adapt to the zpack case.
<adfeno>s/zpack/zpaq/
<ng0>The problem here is that this .zip file is a “tar bomb”, meaning that it
<ng0>unpacks everything in the current directory, which the apply-snippet
<ng0>logic isn’t prepared to deal with.
<ng0>so it really is a * bomb
<ng0>thanks for clearing that up :)
<ng0>as I'm no longer doing this, it'd be useful for nckx
<adfeno>nckx: ↑
<ng0>the package I submitted had the advantage of having one directory inside (doc?) so I could just chdir ..
<nckx>adfeno: yes, I've already packaged it. I just replaced the unpack phase with my own. Yesterday I bookmarked an e-mail from Ludo' in which he mentions the /*bomb variants, but haven't tried that yet.
<nckx>ng0: thanks :-)
<ng0>I need it in Guix only when I have the 0.1 version of my fish-guix done. I prefer zpaq over tar
<nckx>ng0: I'll see if there's a /zipbomb unpacker to make it more succinct, then send-mail it today.
<adfeno>If I recall correctly, that mailing list topic should have resulted in a improved dowload.scm.
<adfeno>But I might be wrong.
<nckx>adfeno: not yet. The patch in that e-mail was never applied. I'll include it if it solves the problem. Thanks for pointing me to that thread!
<ng0>Is it somehow different from other system when you want/need to develop with Java on GuixSD? I might need it in the near future
<adfeno>ng0: Oh... that is... somewhat interesting question.
<adfeno>I would also like to know. :)
<adfeno>nckx: You're welcome :)
<ng0>I'd hate to run a VM with Gentoo when I start university (that's the current plan for winter 2017)
<ng0>all you learn here is C++,C, and Java
<adfeno>Ugh...
<nckx>The problem [I had] with zpaq wasn't the unpack phase (that was trivial to override), but the fact that snippet application in guix/packages.scm repeats the same mistake (a very optimistic ‘first-file’, which leads to ‘chdir COPYING’) with no obvious way to override it.
<ng0>dropping the attempt to learn C back in 2007 was a mistake though
<nckx>ng0: ew.
<ng0>nckx: ah, that's the problem :)
<ng0>I've picked up the debbugs package I made a while back. Doesn't look so terrible incomplete
<nckx>ng0: It would have been, once you'd fixed the unpack phase, so I jumped in to spare you the inevitable disappointment. ;-)
<ng0>well I was able to unpack
<ng0>but I ran into can not chdir to COPYING
<nckx>ng0: that's still done in 'unpack though.
<ng0>rekado_: did you apply any further changes with darcs I could integrate in my darcs branch? Otherwise I'd just use that branch (the state I originally submitted) to test wether https will work one day
<ng0>oh
<ng0>my guix checkout feels like the literal image of 260 keyboards placed on one desk. too many branches
<ng0>oh, I found a webbrowser hidden in branches
<ng0>*webserver
<ng0>I have mbedtls here.. but as a proof of concept I want hiawatha to work, because I have no idea if it actually works.
<ng0>I think I will soon be done with everything I ever maintained or wrote on Gentoo (outside of portage)
<civodul>Hello Guix!
<ng0>hi
<nckx>\\o civodul.
<csanchezdll>civodul: I am trying to test cross-compiled guile on ppc as you suggested on the mail
<csanchezdll>but for some reason getting my guix up to date with core-updates makes tcsh testsuite to fail, so I am blocked solving that
<ng0>I think I will submit mbedtls now.. the hello binary works
<ng0>oh.. tcsh
<ng0>I will make a note for myself that I need to continue the conversation with upstream
<efraim>Tcsh hangs on the test suite for me on aarch64 on core updates
<efraim>Without the patch
<efraim>csanchezdll: I would just disable the test suite as a work around
<ng0>that's still outdated tcsh though and not my work in progress, so nothing I should consider I guess
<ng0>*take in consideration
<civodul>csanchezdll: there should be substitutes available for everything, no?
<civodul>see https://hydra.gnu.org/jobset/gnu/core-updates#tabs-evaluations
<csanchezdll>there seems to be substitutes, true
<efraim>Most of the failures seem related to coreutils-8.26 so I was planning on reverting that upgrade
<jmd>What is different in that version of coreutils which makes things break?
<civodul>efraim: as mentioned at https://lists.gnu.org/archive/html/guix-devel/2017-01/msg01731.html Manolis said there's a patch floating around for this
<civodul>they mentioned it on IRC
<civodul>coreutils.git likely has the fix, it's just a makefile issue apparently
<efraim>I saw manolis patch on the coreutils mailinglist, he wrote that it didnt actually work for him
<efraim> https://lists.gnu.org/archive/html/coreutils/2017-01/msg00072.html
<catonano>given a file in the store, how do I know which package it belongs to ?
<jmd>catonano: In general you can't.
<jmd>Althought you can get an idea from its name.
<jmd>Some store files don't belong to any package.
<catonano>jmd: there are some conflicts when installing geiser. It randomly chooses one off the conflicitng libraries and I'd like to know why those libraries are there
<catonano>whom they belong to ?
<catonano>this is not gonna kill me, it is just a curiosity
<catonano>jmd: thanks, anyway :-)
<GNUnymous_IRC>Hi.
<GNUnymous_IRC>I think I will install GuixSD today.
<GNUnymous_IRC>Can you give me screenshot with GuixSD latest version?
<GNUnymous_IRC>I want screenshot with GUI.
<jmd>There are some screenshots on the web page.
<jmd>But if you're going to install it yourself you can get your own.
<avoine>I'm trying to fix guile extension in gdb but building it with: guix build -f gdb.scm --with-source=./gdb-7.12/ (the extracted tar + patch)
<avoine>I'm getting errors like this: echo: write error: Bad file descriptor or ./config.status: Permission denied when the configure script
<phant0mas>civodul: efraim I was hoping coreutils devs would comment on my patch
<sneek>phant0mas, you have 1 message.
<sneek>phant0mas, efraim says: I have my aarch64 branch at https://gitlab.com/Efraim/guix.git , as core-updates-aarch64
<phant0mas>I found the exact coreutils commit that caused the issue
<avoine>Ignore me, that must be because /tmp/ is full
<phant0mas>civodul efraim I will send the updated patch to coreutils, patch our coreutils package, link to that discusion and push the patch to core-updates
<phant0mas>ok?
<GNUnymous_IRC>Can I install Guix on GNU/Hurd distribution?
<GNUnymous_IRC>Can I install Guix on GNU/Hurd distribution?
<phant0mas>GNUnymous_IRC: not yet, soon :-)
<phant0mas>sneek: later tell GNUnymous_IRC not yet, soon :-)
<sneek>Okay.
<phant0mas>sneek: later tell GNUnymous_IRC the longer answer is you can, you just need to place the tarballs in the correct directory while using core-updates branch
<sneek>Got it.
<efraim>phant0mas: sounds good :) I'm planning on regenerating my aarch64 bootstrap binaries in preparation of sending in some patches
<phant0mas>efraim civodul Have a quick look at the coreutils patch for guix. It works for us, but if the coreutils guys have a different fix I will just update it.
<efraim>Im on my phone, I'll try to take a look at it later tonight when I'm at home and the kids are down :)
<phant0mas>efraim: ok :)
<jin>hi phant0mas
<phant0mas>Hi jin :)
<ng0>hi, gmime fails some tests
<ng0>or at least the one from 2 days ago :)
***kelsoo1 is now known as kelsoo
<ng0>nvm, I had an old checkout
<rekado_>civodul: would you be opposed to using lalr-parser in bournish to support more complicated syntax?
<bavier`>rekado_: a past gsoc project was to implement a more complete shell implementation for guix, but we didn't get to the point of deciding where it would live, as a replacement for bournish or as its own guile language
<civodul>phant0mas: cool! did you send the patch to guix-devel?
<civodul>rekado_: definitely not opposed, it's the right thing to do
<civodul>bavier`: like for (guix gcrypt) and so on, it can start its life in guix.git, that usually makes things easier
<bavier`>civodul: for sure
<phant0mas>civodul: the coreutils patch got accepted. Yes the guix related patch is in the ml
<efraim>phant0mas: civodul: I'm testing the coreutils patch now, trying to compile aarch64 bootstrap binaries
<civodul>cool!
<civodul>rekado_: https://lists.gnu.org/archive/html/guix-devel/2016-06/msg00872.html
<efraim>phant0mas: you missed which package in base.scm the patch applies to, and I would mention that it reverts an upstream commit
<phant0mas>efraim: oops :P you are right, I will send an updated patch
<phant0mas>and it actually doesn't revert the upstream commit, just adds something they missed
<efraim>Ah, ok
<phant0mas>I will also update the patch to remove the extra ":" to mirror the updated coreutils commit they accepted
<jmd>I'm getting this error doing guix package --upgrade --fallback: guix package: error: reference to invalid output 'debug' of derivation '/gnu/store/giyh9cv0avvybhfa0imay4qwj1xsqwli-yelp-3.20.1.drv'
<Apteryx>Could anyone give me a hint about how to connect a bluetooth device? I'm using the %desktop-services default services, which FWIU includes a bluetooth service called bluez. It seems though that I should add myself to the group "lp".
<ng0>civodul: I will look into the shallow clone patch soon, thanks for the link
<rekado_>Apteryx: yes, your account should be member of the “lp” group.
<rekado_>Apteryx: check with “hciconfig” if your bluetooth hardware is up. If it is not run “sudo hciconfig hci0 up”.
<rekado_>Apteryx: then you can use bluetoothctl to pair devices or control the device some other way.
<Apteryx>rekado_: Thanks. I have to install "bluez" in my user profile to get this "bluetoothctl" executable, rigth?
<Apteryx>right*
<Apteryx>t
<rekado_>Apteryx: yes, it’s part of the bluez package.
<efraim>From when I used to bluetooth tether my phone from the cli I had 'hciconfig hci0 up && hcitool cc $phonecode'
<Apteryx>Currently, running "hciconfig" justs waits "to connect to bluetoothd". Maybe this is because I haven't reconfigured my system with group "lp" yet.
<Apteryx>I'll do this and report of success. Thanks efraim & rekado!
<ng0> https://www.phoronix.com/scan.php?page=news_item&px=Arch-Linux-Deprecating-i686 interesting..
<rekado_>ng0: also see https://wiki.archlinux.org/index.php/Arch_Linux_April_Jokes#2009:_Dropping_i686_Support
<ng0>hm
<ng0>ah so it's just a joke again :)
<nckx>‘Hopefully we'll see other Linux distribution vendors do a similar maneuver this year!’ — it has to be, right?
<rekado_>Why is this considered to be a good thing?
<lfam>"Hopefully, we'll see other Linux distros drop support for some of the last trustworthy hardware available."
<nckx>ACTION is talking through a i686 VPS right now :-/
<jmd>I hope guix doesn't do this too soon.
<nckx>Exactly.
<lfam>jmd: I doubt we'll do it *ever*
<lfam>Or at least as long as one of us has 32-bit hardware
<lfam>Honestly, I wouldn't look for leadership from these sites.
<lfam>I don't like to say negative things here, so I just filled my quota for the quarter.
<lfam>LWN has an article about package managers today. Maybe some subscribers would like to pipe up if functional package management is discussed
<ng0>I don't like phoronix.
<Walakea>why?
<ng0>or was this another site? someone showed up here one day and requested to package a huge benchmarking suite and disappeared again
<nliadm>phoronix seems to mostly be lots of low-quality posts
<nliadm>and the in-depth articles are annoyingly paginated
<adfeno>I don't like both. No clear license for content to allow sharing. :)
<rekado_>adfeno: when in doubt it’s all rights reserved.
<rekado_>adfeno: you can still link to it.
<Walakea>adfeno, you don't like content that ain't free culture?
<adfeno>Walakea: I don't like content that isn't at least shareable.
<adfeno>(Free/libre culture is way beyond what I said)
***contrapumpkin is now known as copumpkin
***snape` is now known as snape
<Walakea>how far would you say GuixSD is from a stable release?
<lfam>Walakea: What do you mean by "stable"?
<Walakea>i mean not being "beta software"
<lfam>Walakea: Here's the closest thing to a checklist that I can remember off the top of my head: http://lists.gnu.org/archive/html/guix-devel/2015-12/msg00543.html
<lfam>We have full disk encryption now
<Walakea>i mean, i would like to try it on my computer some day
<lfam>Well, that's up to you :)
<bavier`>Walakea: there are many here who run GuixSD as their primary OS for quite a while
<jmi2k>I have a laptop running Guix almost 24/7, and I carry it in a USB everywhere. Something I miss from Arch Linux are the packages, but I help whenever I can :)
<Walakea>how does GSD manage packages?
<lfam>With Guix
<Walakea>do you need a Guile script for everything?
<adfeno>I use Guix on top of Trisquel, but I'm still trying to gain courage to install GuixSD.
<adfeno>And, I even contribute to some packages :)
<rekado_>Walakea: you need a Guix package expression as much as you need a *.deb for a package on Debian or Ubuntu.
<snape>jmi2k: you won't miss AUR packages :)
<rekado_>Walakea: i.e. you can build software without it, but to have them managed by Guix you need package expressions.
<jmi2k>Something I love of Guix is how *easy* is contributing and hacking into it. Here was the first time I sent a patch to a project.
<Walakea>are Guix packages principially easier to package?
<nliadm>than what
<Walakea>debs and rpms
<nliadm>I've found the average case to be about as easy
<nliadm>I sometimes have to go digging in the scheme or guix docs if I need to do something a bit more complex
<Walakea>do you think Hurd will ever be usable for normal work?
<rekado_>I find rpms more difficult. (I packaged a lot of software with rpm before finally switching to Guix at work.)
<nliadm>but I packaged most of the proprietary stuff I use for $dayjob with little hassle
<jmi2k>Well, I'm still getting used to Guile and there are some packages I tried to package and failed. But
<jmi2k>not but, xD
<rekado_>Walakea: it is already usable for some work. But it doesn’t run on commonly available hardware at this point.
<Apteryx>Back from a successful system reconfigure from Guix master. Bayfront server provided valuable substitutes such as the Linux-Libre 4.9.5 kernel!
<nliadm>I'm still looking for an easier way to specify packages we build from git master
<Walakea>what is the reason for Linux code base being so huge?
<Apteryx>Walakea: drivers?
<Walakea>i thought so
<Walakea>Hurd is written in C, amirite?
<Apteryx>I think it is.
<jmd>Walakea: Mostly, yes.
<Walakea>and Guix?
<jmd>Mostly in scheme.
<Apteryx>rekado_: Shouldn't the bluez service be started already if I'm using the %desktop-services list?
<Apteryx>I'm getting "sudo systemctl start bluetooth" when using bluetoothctl which apparently means the service is not running
<ng0>that's systemd though?
<ng0>oh.. bluetoothctl outputs that
<adfeno>Someone reading this?
<adfeno>Or is my connection slowly dropping?
<Walakea>yes
<adfeno>Oh thanks :)
<rekado_>Apteryx: the service is called “bluetooth”. You can check its status with “sudo herd status”
<Apteryx>rekado_: Ah, I understand my mistake now. I thought the "bluetooth-service" was part of the %desktop-services list, but it's not. It has to be added explicitly to my config.scm.
<Apteryx>Maybe my reading comprehension is bad, but I got that impression from this sentence in the user manual: " The actual service definitions included in ‘%desktop-services’ and
<Apteryx>provided by ‘(gnu services dbus)’ and ‘(gnu services desktop)’ are
<Apteryx>described below.
<civodul`>jmd: the "reference to invalid output" problem is post 482fda2729c3e76999892cb8f9a0391a7bd37119, right?
<civodul`>jmd: do you have an easy way to reproduce it?
<civodul`>"guix build yelp" works for me, for instance
<ng0>108 letters in unixpath length maximum error in an out of tree package i have.. regardless of my further findings and solutions, is this something guix has considered, maximum file name length and maybe shorten the build dirs in /tmp/ to point to a symlink with the long name or smth like that?
<ng0>I can't post the link to the bug report right now
<ng0>wrt archlinux:
<ng0>"ubuntu has already started the same"
<ng0>haha
<ng0>the resulting builds i have in store for this particular package is:
<ng0>zsqqrklysrh25n8kfdbq7qc7aar97qpj-g
<ng0> nunet-git-full-tests-0.10.1-2.15719ea/
<ng0>damn linebreak
<Apteryx>Any suggestion as to how use my config.scm interactively the same way I can use the guix scheme files? I can't associate a running geiser REPL with it.
<ng0> /gnu/store/zsqqrklysrh25n8kfdbq7qc7aar97qpj-gnunet-git-full-tests-0.10.1-2.15719ea/
<ng0>this is way beyond what we do normally, right?
<bavier`>ng0: we don't usually have package names that are that long
<ng0>ok, that's good
<Apteryx>It seems the only problem with my config.scm and Geiser was the "implementation" being set to Chicken Scheme rather than Guile for some reason. I feel silly now ;)
<Apteryx>There most be some dir-locals within the Guix tree which was setting this to Guile.
<Apteryx>*must
<Apteryx>ACTION rebooting
<Apteryx>OK, so I managed to pair & connect the bluetooth keyboard... but I can't input any text yet. Is there something more I should do?
<buenouanq>jiggle the cord
<Apteryx>a
<Apteryx>Aha ;)
<Apteryx>I think I need the hid-apple module.
<Apteryx>it's one of those mini apple bluetooth keyboards.
<Apteryx>Seems to be GPL'd and included in Linux-libre so I'm not out of lock yet (despite the Apple in the name).
<Apteryx>luck*
<ng0>you would also be out of (caps)lock if you would be out of luck
<Apteryx>hehe
<Apteryx>I have no idea how to get a list of the running kernel modules on GuixSD
<Apteryx>there is no "--list" option to modprobe.
<ng0>lsmod or what it was
<ng0>yep
<ng0>lsmod
<Apteryx>Oh, right! I had forgotten that one. Thanks.
<Apteryx>OK. So the device is paired & connected, and the required hid* modules running. Not sure why I still can't input anything using it.
<ng0>restart X / init? i have no idea
<Apteryx>That's a good idea! I wonder if the "paired" state will continue to hold. We'll see!
<Apteryx>(I paired interactively using the bluetoothctl CLI tool).
<Apteryx>Hmm. Still no joy (apple wireless keyboard) -- connected & paired but doesn't register input.
<Apteryx>ng0: I tried restarting the xorg-server service with herd but it didn't seem to help. The log at /var/log/Xorg.0.log doesn't contain anything interesting.
<Apteryx>It works! Not sure which of the following did it: 0) connect & pair using hcitool + bluetoothctl, 1) "sudo modprobe hid-apple" 2) Restart Xorg 3) Disconnect & Reconnect keyboard with bluetoothctl.
<Apteryx>After that, the A1314 apple wireless keyboard got registered in the kernel (visible in dmesg) as an input.
<adfeno>Apteryx: Try seeeing if it stays that way after reboot, just in case :)
<adfeno>But before that, take note of the steps done, and try jumping one or two.
<Apteryx>Probably not, unless the bluetooth controller will stay on (I had to do "sudo hciconfig hci0 up")
<rekado_>Apteryx: you can add a udev rule to start the bluetooth interface automatically.
<rekado_>(I don’t know the magic incantation, but I know it exists.)
<Apteryx>rekado_: OK! Thanks for mentionning it. I'll look into it tonight. I guess this can all be done using gexps from my config.scm file?
<rekado_>Apteryx: yes, you can add the udev rule in your config.scm
<rekado_>Apteryx: here’s an example from my config: http://paste.lisp.org/display/337394
<rekado_>don’t mind the #║
<rekado_>it’s just a custom string delimiter because I wanted to play around with strings without having to escape quotes.
<rekado_>turned out to be ugly
<Apteryx>rekado_: OK! Thanks.
<Apteryx>Seems GnuCash (accounting software) is not able to save data it keeps across sessions (for example, it the tips pop-up always come back, no matter how many times you untick the "don't show me again" checkbox).
<Apteryx>It also doesn't remember about the last opened file (it's usually re-opened automatically). I'll file a bug tonight.
<jlicht>Does anyone have weird input issues using the developer console in IceCat 45.5.1 using recent master guix?
<jlicht>to be specific, after entering an expression such as `2 + 2', and presssing enter, the expression is evaluated, but the console input line now contains `2 + 2' and a newline
<Apteryx>jlicht: I have that too. It's ugly but it doesn't seem to cause an issue.
<Apteryx>Other than you have to manually clear it sometimes. Is this only in IceCat?
<jlicht>Apteryx: I have no other installed browsers with developer console, so I couldn't say
<Apteryx>I'll try Firefox 45 ESR I have on Windows