IRC channel logs

2016-01-28.log

back to list of logs

<civodul>if that's fine with you, please push by then :-)
<civodul>well, 3 out of 4
<civodul>until then, good night/day!
<mthl>good night
<NiAsterisk> re: bug on guix-bugs... sorry, I should write an email tomorrow on how I solved it and why sending to bug list was stupid in the first place. prior to this system I did not work with (local) branches in guix i worked on the master (i think), now that I work with branches which track the master it failed when I was checkout on the branch, but succeeded with master checkout
<NiAsterisk>how do you do it, developing locally? branching? just working on the origin/ branches?
<NiAsterisk>clearly I did something stupid with the way I used branches, but it used to work some time ago
<NiAsterisk>anyhow, gotta go. maybe I ask tomorrow again about this. problem is kinda fixed now.
<NiAsterisk>good night
<lfam>There are security updates for icedtea-1 and icedtea-2. I can test the builds and then push to wherever people think is appropriate.
<lfam>There is also a security update for iceweasel. I'm not sure how that filters down to icecat.
<mark_weaver>lfam: ah yes, there's a Firefox 38.6 now, so I'll probably need to grovel through the upstream git repo for the fixes again.
<mark_weaver>thanks for letting me know!
<mark_weaver>lfam: if you could take care of the icedtea-* updates, that would be appreciated!
<mark_weaver>lfam: we'll make a separate branch with your cURL update and the openssl security update (when its available) and build it out in a separate jobset on hydra.
<lfam>mark_weaver: Sure, I'll do that. What should I do with them when they are ready? Push to master? Not a lot seems to depend on them according to `guix refresh -l`
<lfam>Referring to icedtea
<mark_weaver>lfam: yeah, I think that would be fine.
<mark_weaver>(for icedtea)
<mark_weaver>thanks again for all your help with security updates :)
<lfam>Okay. Will do. It will probably take overnight to build them both on my machine.
<lfam>My pleasure :)
<myglc2>duh, now I see why ssh wasn't working for me. Its on port 2222 in the bare-bones example that I cloned. Any idea why this was chosen? N00be IQ test?
<cehteh>22 gets scanned and attacked quite often
<cehteh>i only let ssh on port22 running when there are no passwords, only key auth, and then with firewall limiting the connects per ip/minute
<myglc2>OK but there are arguments pro and con about e.g. 2222. The use of 2222 in this example config adds an extra hoop for someone just tring guixSD out to jump thru, don't you think?
<davexunit>yeah, I think so.
<cehteh>yeah, agreed
<cehteh>there are way too much things still which raise the entry barrier, i caught by that to
<cehteh>anyone who uses guix or works with it since some longer prolly doesnt even notice that
<myglc2>Of course the next thing I want is to run emacs in a X window. I assume I need to add the equivalent of the 'services.openssh.forwardX11 = true;' and 'programs.ssh.setXAuthLocation = true;' that I had to add to the NixOS example config, right?
<myglc2>
<lfam>I think it's good to start a fresh system with ssh on a non-standard port if root's password is empty
<myglc2>It looks like my guixSD install came up denying root login on ssh, isn't this good enough?
<myglc2>... and so I set the root login in a console terminal, which seemed OK to me.
<lfam>Perhaps. It depends IMO on how the rest of the privilege escalation system is configured (sudo, user passwords, etc). I personally think it would be best if new users tested their OS declarations in QEMU before using real hardware, especially considering how easy that is.
<lfam>If users are blindly copying and pasting the examples then I think it's best to obscure the port
<lfam>Because that means they don't even know whether or not root logins are disabled
<myglc2>Maybe I'm weird, but I have a server on my local LAN and my sniff test is to install on a real machine since that is how I intend to use guixSD.
<lfam>It would have taken me a long time to get a working OS declaration by iterating on real hardware. But I'm no Scheme expert ;)
<myglc2>For my part, I always hope that "blindly copying and pasting the examples" will get my machine up and running in a vanilla way, since there is already enougn confusing new stuff to learn.
<lfam>You're lucky that (file-systems) worked for you with /dev/sdX and a partition named 'my-root' ;)
<lfam>Anyways, since the desktop services include NTP, new systems are going to be getting port scanned by shodan within minutes of coming up. So I think that 2222 is okay as a default.
<lfam>Also the default lsh-service uses 22. It's only people that copy and paste that get 2222
<myglc2>Oh, I fixed sdX & my-root which were obvious... even to me. And don't get me wrong, I'm not complaining, just suggesting. My guixSD install actuallyreally went well.
<lfam>I do think we should streamline it as much as possible but this is one bump in the road that I think makes sense. I got hung up on 'my-root' ;)
<myglc2>If you want the bare-bone example config to include an example of passing in an config argument, how about the ones necessary to enable X11?
<myglc2>FWIW, I have been coding for more years than I care to admit, and I always copy and try first, and then try to figure out what went wrong later...
<lfam>Did I want that? That could be a nice addition to the installation guide
<lfam>My approach is to try to understand it as much as possible for a neophyte, and then copy and paste. But I like to understand each step as much as I can. Sometimes that's not very much understanding, though...
<lfam>It's also a very slow way to get started
<lfam>Ugh, I hate seeing 'patch-patches' in a package definition. That's when you know you're in for a rough ride.
<myglc2>I think it is cool that there is an example of passing a config argument into lsh-service, since it is highly likely that one will want to be doing so immediately. I just think maybe the value shoule be 22 instead of 2222, and xauth and X11 should also be there.
<lfam>Then I think we should use the mailing list to review the change in light of the rest of the security defaults, as I mentioned a few minutes ago.
<lfam>Not that using a non-standard port is really a strong security stance, but it is something.
<lfam>Although 2222 is barely non-standard
<myglc2>what would you think of adding emacs and vi and X11 enabled on ssh to the bare-bone packages config? Then the machine would come up in a pretty usable and explorable way for 'alice'
<lfam>myglc2: It's not up to me ;) It should be discussed on the list. But I wouldn't call emacs and X11 bare-bones :p
<mark_weaver>bah, I can't access the firefox git repo because github is down.
<mark_weaver>looks like they've been having problems for a couple of hours. https://status.github.com/messages
<davexunit>this is a pretty big crash for them. I hope it makes people think about relying on centralized systems.
<cehteh>esp with git where it isnt really necessary
<myglc2>OK, thanks. Which list? user or devel?
<mark_weaver>I've never been able to find my way around Mozilla's official Mercurial repository. Can anyone help me find the Firefox ESR 38 branch here? https://hg.mozilla.org/
<mark_weaver>oh, I think I found it.
<mark_weaver> https://hg.mozilla.org/releases/mozilla-esr38/
<mark_weaver>myglc2: probably the user list
<mark_weaver>but I'm sure we won't want to add X to the "bare bones" config.
<lfam>mark_weaver: icedtea is a bumpy road as well
<mark_weaver>I think the idea is bare-bones really means what it says, and if you want those things you should add them.
<myglc2>mark_weaver: OK Thanks I'll raise it on the user list.
<lfam>mark_weaver: I started with icedtea-1 (based on openjdk-6) since icedtea-2 (openjdk-7) inherits from it. However, one of the many upstream patches does not apply to the relevant file! And I can see that related patches will not apply either.
<lfam>The patch "patches/openjdk/p11cipher-6682411-fix_indexoutofboundsexception.patch" wants to alter the string 'public int unpad(byte[] paddedData, int ofs, int len)', but that string only exists in the source tree in that patch. So I'm going to report the bug upstream and put this on ice.
<lfam>Hm, no pun intended!
<mark_weaver>lfam: I guess the patch needs to be backported, because the patch depends on some earlier commits
<lfam>I'm really not qualifed to do that
<mark_weaver>fair enough :)
<lfam>Do you think I should file the bug or should we work on it ourselves and send the changes upstream?
<mark_weaver>I suspect that I'd be lost in that code as well..
<lfam>In that case, I'm not sure who would do it on our end...
<mark_weaver>lfam: has debian or fedora addressed this problem yet?
<mark_weaver>was are the CVE numbers? how did you find out about it?
<lfam>I learned about it from DSA-3458-1. The CVEs are: CVE-2015-7575 CVE-2016-0402 CVE-2016-0448 CVE-2016-0466 CVE-2016-0483 CVE-2016-0494
<lfam>sneek: later tell mark_weaver: The DSA message didn't address the icedtea built on openjdk-6. But they did update to the newest icedtea release. So perhaps I should try to decouple our icedtea packages and try building the one based on openjdk-7.
<sneek>Will do.
<mark_weaver>I lost my connection, but am back now...
<sneek>mark_weaver, you have 1 message.
<sneek>mark_weaver, lfam says: The DSA message didn't address the icedtea built on openjdk-6. But they did update to the newest icedtea release. So perhaps I should try to decouple our icedtea packages and try building the one based on openjdk-7.
<lfam>Actually, I can still build the openjdk-7 version. Inheritance doesn't require the "parent" to build
<lfam>Or, at least try to build it.
<mark_weaver>lfam: based on looking at the Debian package, there's an upstream icedtea 2.6.4 that fixes the security issues.
<lfam>Indeed, that is the version based on openjdk-7.
<mark_weaver>so that looks like an easy one to address.
<lfam>The icedtea-1 series is also vulnerable and also has an update.
<mark_weaver>where do you see an update for it?
<lfam> http://blog.fuseyism.com/index.php/2016/01/25/security-icedtea-1-13-10-for-openjdk-6-released/
<mark_weaver>ah, good. so is there a problem? do we have patches that don't apply cleanly?
<mark_weaver>it sounds like we can simply update to 2.6.4 and 1.13.10
<lfam>Not our patches. Upstream includes a huge amount of patches that are applied to the bundled openjdk source code. Those are the patches that I am having trouble with. Looks like there is a similar problem with icedtea-2 based on openjdk-7 (the one in the DSA)
<lfam>It's turning out to not be a simple update
<mark_weaver>lfam: maybe post to guix-devel asking for help?
<lfam>Sure, I'm going to bang my head against icedtea-2 for a few minutes, then I'll share my joy with the list
<lfam>:p
<mark_weaver>heh :)
<lfam>Yeah, this version is not working either. It's not something that can be fixed by adjusting the options to `patch`. The string and the variable it contains doesn't even exist in that file.
***kelsoo1 is now known as kelsoo
<efraim>adding libx11 as an input for ffmpeg looks like it adds a bunch of hardware accelleration options
<Jookia>I switched distributions, rebuilt Guix and went to build Guix but it ignored my existing coreutils derivation. I wonder why this is?
<NiAsterisk>hi
<Jookia>o/
<NiAsterisk>offtopic thought of the morning: funny how people use a decentralized sourcecode technology and yet they dump it all into a single point of failure.
<xd1le>NiAsterisk: what do you mean?
<NiAsterisk>gitbigdata, github, went down for a couple of hours.
<xd1le>NiAsterisk: gittorrent ;)
<xd1le>no but i know what you mean then
<NiAsterisk>it's noit like I use github.
<Jookia>I was asleep and missed the schadenfreude
<xd1le>holy shit
<xd1le>a few hours?!
<xd1le>haha wow
<NiAsterisk>git is perfect for running it locally on hidden-service of each person etc.. but idk how that works out for teams bigger than 5.
<Jookia>gittorrent is cool but it doesn't have all the github features that are undoubtedly going to ruin project history
<xd1le>NiAsterisk: have a central repo
<xd1le>as in, it's still decentralized though
<xd1le>if the central repo fails
<xd1le>you just have to not care about your github issues, wiki whatever, *if* you're using github
<df__>the central repo failing is still inconvenient if you make it a part of your workflow though
<xd1le>or otherwise have a way to store them offline and recreate them to your new central repo hosting service
<xd1le>which i don't think actually exists yet
<Jookia>Maybe we should use a decentralized system that provides a wiki and tickets? Maybe something like fossil
<xd1le>i'm not so huge on decentralized issue tracker/wiki whatever
<NiAsterisk>my work with git on local hosting was limited to a team of 5 people, and one person started it and the others started clones and send patches to the central person
<Jookia>xd1le: Why?
<NiAsterisk>*is limited
<Jookia>Or if we really like Git we could have a separate repo for these things and use a program to read/write the repo
<xd1le>Jookia: because you'd have to figure how to merge issue tracker activity, with a centralized one, everyone's on the same page
<xd1le>decentralized wiki actually not a problem though
<xd1le>you can't really *use* a git repo as an issue tracker though
<Jookia>I don't see why not
<df__>a mailing list feels like a decent fit for issue tracking
<xd1le>because to give commit access means one may able to overwrite history
<NiAsterisk>there are things I want to write, or at least theoretical write and design, for gnunet once I get it all.
<xd1le>and of course
<xd1le>*anyone* needs to be able to open an issue
<df__>although that relies on a central server too, so meh
<Jookia>These aren't problems with git or decentralization as much as figuring out a good workflow
<xd1le>thinking about sending patches for your issue comments
<xd1le>that seems overly complicated
<xd1le>like i'm not opposed to *storing* the issue tracker under git
<Jookia>Having a centralized issue tracker is a big problem unless you can decentralize it
<Jookia>ie fork it
<xd1le>(as in all the comments and stuff)
<xd1le>why?
<xd1le>you can solve the single point of failure
<xd1le>by just having offline copies of it
<Jookia>What if I want to fork a project
<xd1le>like encouraging users to download it and stuff
<xd1le>yeah
<xd1le>so download it
<xd1le>and recreate it from your fork
<xd1le>like this is all hypothetically speaking
<Jookia>Then it's not centralized is it? :P
<xd1le>i'm not sure if it is possible to do today
<NiAsterisk>something else... libreboot with both of my laptops is testing ground (displays not even in the tested/untested category), but coreboot seems to have no issues.. will having coreboot spare me the hassle to hack the lenovo bios and whitelist the no-blob wifi cards I bought
<xd1le>no i mean
<xd1le>it's being *used* in a centralized manner
<xd1le>if you make a fork
<xd1le>then that's a different project now
<Jookia>xd1le: This is true, but it's analogous to any other project
<xd1le>(but i assume you still want all the discussion of the original issue tracker)
<xd1le>so basically like a copy paste of issues
<Jookia>Maintainers moderating and running the issue tracker like they do the rest of the project seems simple enough
<Jookia>Yeah
<NiAsterisk>xd1le: sounds like a plugin idea for SecuShare on what I read and talked about with them..
<NiAsterisk>coding could be a social plugin.. idk.
<Jookia>NiAsterisk: Coreboot and Libreboot aren't that different aside from blobs
<NiAsterisk>have to think about it
<NiAsterisk>Jookia: but it's like librecmc vs openwrt,right? if an display panel is not supported by libreboot, it will work in coreboot as coreboot has some features not removed
<xd1le>NiAsterisk: i haven't heard of secushare, thanks
<NiAsterisk>I want libreboot but don't feel like testing
<xd1le>but looking at its homepage, can't figure out what it is?
<xd1le>is it software?
<Jookia>NiAsterisk: I dunno if it's exactly like that for displays
<NiAsterisk>xd1le: yes.. the social plugin for gnunet. they are slow due to receiving minimal funding and more people working on desperate efforts like diaspora, but they are getting to a demo soon.
<sneek>I'll keep that in mind.
<Jookia>Is GNUNet really the right platform for that
<NiAsterisk>for what?
<Jookia>For anything that wants to be anonymous
<NiAsterisk>yes. wait like ~3-4 more years and it will have enough reasons for people to switch over.
<Jookia>Unfortunately to be anonymous it needs much much much more traffic
<xd1le>NiAsterisk: nice, thanks for exmplaining
<NiAsterisk>i just woke up 2 hours ago, and I feel like everything I could talk about would be very offtopic.
<Jookia>I'm planning on writing some P2P applications meant to be anonymous so I'll be using Tor for it
<NiAsterisk>Jookia: there's a video of EDN about this... unfortunately I am very slow at translating and putting stuff into srt format
<xd1le>otoh i'm pretty tired right now
<xd1le>might just afk for a while, catchya later guys
<xd1le>and yeah, world on github is asking for it
<xd1le>imo
<Jookia>I do have a project in mind a bit like secushare so it's a duplication of effort, but if GNUNet had one feature in particular I'd use it
<Jookia>Though it might be easier to get Tor to add it
<CompanionCube>so, just getting started with Guix
<NiAsterisk>might want to contact them via bitmessage or join psyc://psyced.org/@welcome (*welcome@psyced.org with xmpp or something else with irc)
<CompanionCube>is it normal for GNU hello to have all these downloaded deps
<Jookia>CompanionCube: Still compiling?
<CompanionCube>Jookia, nope. The power of -j4.
<NiAsterisk>Jookia: and check https://wiki.c3d2.de/EDN (english) for more on dupplication of effort.
<NiAsterisk>enough offtopic for now :)
<CompanionCube> https://gist.github.com/anonymous/5324e0286476b9f06969 for the list of things it would build/download
<NiAsterisk>might be that welcome is now accessible only via tor. in that case try just psyced.org/PSYC/ in your webbrowser and get the onion address from www.psyced.org
<Jookia>CompanionCube: Seems about right
<CompanionCube>installing....
<CompanionCube>good thing I don't have to compile all of this stuff locally :)
<Jookia>ACTION grumbles
<civodul>hey Guix!
<Jookia>Hey there
<efraim>hi!
<SusWombat>Hey :)
<SusWombat>Is the buildfarm situation better now ? COmpared to 1-2 months ago?
<civodul>SusWombat: not yet!
<civodul>but now we have money to do something about it
<civodul>thanks to everyone who donated
<civodul>we're discussing how to implement it
<civodul>but i hope we can get that done within 1-2 months
<SusWombat>civodul, Okay :)
<SusWombat>civodul, But its still in a usable state right?
<efraim>i'm preparing a patch for ffmpeg adding some more features to it
<efraim>so far I've added libvdpau. libx11, v4l and I'm checking on libxcb for more x11 goodness
<civodul>SusWombat: it's usable, we use it everyday, but it's slow
<civodul>there are periods during which it's overloaded to the point that it's unusable
<SusWombat>civodul, sry for all this asking :( Does this only affect installing stuff?
<Jookia>SusWombat: Should only affect building stuff I think
<SusWombat>Jookia, aaah okay
<civodul>SusWombat: it affects downloads of pre-built binaries as described at https://www.gnu.org/software/guix/manual/html_node/Substitutes.html
<civodul>here we are: the GNU Shepherd is out!
<SusWombat>civodul, so in the worst case i could compile it myself? But it wouldnt be besides the guix package manager right?
<civodul>SusWombat: right, guix can fall back to compiling instead of downloading pre-built binaries, but this is completely transparent
<civodul>it just takes more time/CPU power
<SusWombat>civodul, and there are no problems in mixing these two methods?
<civodul>no, i think this is explained in the above page :-)
<SusWombat>civodul, yes it is :) But asking to be sure is more safe :) Im sry ^^
<efraim>would we want libwebp or wavpack support in ffmpeg?
<efraim>wavpack only adds wavpack, webp is already decoded using vp8 which we have from libvpx
<civodul>efraim: so i would say "no"; you?
<civodul>wavpack is the .mpc files, right?
<efraim>i'm not exactly sure what it is, but it doesn't seem especially useful
<efraim>doh, I'm taking v4l linux back out, forgot it pulls in qt-5
<civodul>ouch
<efraim>currently ffmpeg's closure is 523 MiB, with my additions it's up to 1.4 GiB
<efraim>that's more than a little absurd
<civodul>yeah, that seems too much
<efraim>adding sdl will get us the ffplay command which no one's complained so far that we're missing
<civodul>so let's not do that :-)
<SusWombat>When i would discover something i miss i would need to know a bit guile to make my own package file thingy right?
<NiAsterisk>depends... it's rather accessible without knowing guile, looking at other packages, etc
<efraim>using the other packages as examples helps a lot
<NiAsterisk>it helps knowing guile and lisp
<SusWombat>okay :)
<SusWombat>Well im learning emacs atm so atleast im learning a bit emacs lisp i guess ^^
<efraim>I'm almost done building ffmpeg with libx11 and libvdpau so I can see how that affects the closure, then I can see if adding mesa-headers will let us enable opencl and opengl
<efraim>awesome, libx11 and libvdpau only increase ffmpeg's inclosure from 523.3 to 523.6. 0.06% increase
<mark_weaver>civodul: GC is finished on hydra. should I merge core-updates into master now?
<mark_weaver>civodul: well, I'll assume the answer is yes based on our past conversation about it.
<mark_weaver>it's merged now.
<mark_weaver>hydra is currently evaluating it, and then I'll start the queue-runner.
<civodul>mark_weaver: thanks, it's perfect!
***nckx is now known as nckx|offline
<davexunit>wee, congrats on the shepherd release!
<davexunit>ACTION needs to upgrade
<civodul>heheh
<mark_weaver>ACTION just pushed the 'security-updates' branch, with curl and openssl updates.
<mark_weaver>and asked hydra to build it
<mark_weaver>but at the moment, hydra is still working on evaluating master.
<mark_weaver>there are also security updates to icecat, already on master.
<civodul>mark_weaver: great, thanks again and again!
<mark_weaver>np :)
<mark_weaver>and thanks for the shepherd release. it looks really nice!
<mark_weaver>I have to go afk for a while. happy hacking!
<civodul>mark_weaver: 'guix lint -c cve' reports 3 problems today: glibc, harbuzz, jasper
<NiAsterisk>the amount of packages downloading right now tells me there will be local builds because hydra is still building. but thanks for the sheperd word :)
<NiAsterisk>*work
<davexunit>civodul: that's a handy tool!
<efraim>i assume glibc touches everything
<civodul>yep
<civodul>davexunit: user name spaces at risk: http://lwn.net/SubscriberLink/673597/0d32fe7916f930ca/
<efraim>oh fun
<davexunit>civodul: oh dear
<davexunit>I can't read all of this right now, is there a 1 sentence "too long; didn't read"?
<davexunit>I will read later, maybe over lunch.
<NiAsterisk>the laste sentence of it.
<NiAsterisk>it seems that getting security-related changes into the kernel is still a difficult task.
<NiAsterisk>that's not the total content, but what I did get from quick reading
<calher>What happened when I tried installing GuixSD: http://hastebin.com/raw/nujujeyofa
<NiAsterisk>oh. rms is speaking at fosdem on friday, or at least on location, before fosdem starts on saturday.
<mark_weaver>calher: you need to create the filesystem on /dev/mapper/leela before trying to mount it.
<mark_weaver>calher: that step was missing from the first draft of the guide that petter wrote, but it's here: http://sprunge.us/JNCF
<mark_weaver>*it's in here
<mark_weaver>ACTION goes afk again
<calher>ACTION goes AFK to waste paper on http://sprunge.us/JNCF
<calher>pizzaiolo, do you use Guix(SD)?
<pizzaiolo>calher: planning on it
<pizzaiolo>suitsmeverywell is going to release some documentation on how to install it on a librebooted macbook
<pizzaiolo>I'm waiting for that
<calher>ACTION curl http://sprunge.us/JNCF | fmt | less
<pizzaiolo>according to him, there were some undocumented issues
<pizzaiolo>calher: are you using guixsd?
<mark_weaver>calher: oh yes, you'll need to add the "serpent_generic" and "wp512" kernel modules to the initrd section of the OS config, as described in <https://gnu.org/software/guix/manual/html_node/Initial-RAM-Disk.html>.
<calher>mark_weaver: Made note: "S. 7.2.11: Add serpent_generic and wp512 kernel modules.".
<davexunit>civodul: I read the LWN article finally. it's disappointing that sysadmins seem to want to turn off user namespaces entirely.
<davexunit>user namespaces are such a great feature. they should continue to improve upon it rather than look for ways to turn it off.
<civodul>davexunit: yeah :-/
<civodul>OTOH Linux is such a pile of hacks ;-)
<davexunit>this is true
<NiAsterisk>the names people come up with for libs and software... "viagra"... mkay.
<myglc2>In bare-bones.scm I changed '(packages (cons tcpdump %base-packages))' to '(packages (cons emacs %base-packages))' and now 'guix system build /etc/config.scm' gives me root@g1 /etc# guix system build /etc/config.scm
<myglc2>guix system: error: failed to load '/etc/config.scm':
<myglc2>/etc/config.scm:8:0: In procedure #<procedure 37fd520 ()>:
<myglc2>/etc/config.scm:8:0: In procedure module-lookup: Unbound variable: emacs
<myglc2>Do I have to quote emacs or something?
<NiAsterisk>you have to load the definitions of emacs
<NiAsterisk>in (gnu packages emacs)
<myglc2>Cool, how do I do that?
<NiAsterisk>one sec
<NiAsterisk> https://notabug.org/niasterisk/guixsd_niasterisk-configs/src/master/config-t.scm should have a valid example
<myglc2>Great! Thank you.
<NiAsterisk>(use-package-modules emacs)
<NiAsterisk>sorry if the lingua wasn't entirely correct.. I guess it is the packages definitions, that's the explanations I have for myself as it hold the definition of the package.
<myglc2>So tcpdump is "built in" but for most practical purposes we need to definatively reference the constructs we want to use?
<NiAsterisk>tcpdump should be in (gnu packages admin) i guess
<myglc2>Cool. Thanks.
<NiAsterisk>if you have the source, you can find the scheme file which holds packages, in gnu/packages/$name.scm
<NiAsterisk>also when searching for it via guix package -s "some name" it should be displayed
<NiAsterisk>as in location or something
<myglc2>OK, thanks. I did a guixSD install but not yet really understanding exactly what that gives me or how best to use it or what to do next (but not a complaint, OK)
<GChriss>is there a quick crash-course for scheme syntax linked to from guix doc pages somewhere? just ordered a copy of "Structure and Interpretation of Computer Programs" but wanted to know if there was a 15-min condensed version as it's typically used in guix scheme files
<NiAsterisk>there was something in the manual iirc
<GChriss>oh wait, different page than what I thought, had read through the hello turtle example
<davexunit>mark_weaver: I found this: https://github.com/sarabander/sicp-pdf
<davexunit>oh you said you found it. :)
<mark_weaver> https://github.com/sarabander/sicp
<NiAsterisk>ACTION waits 12 more hours to update. compiling is meh
<efraim>GChriss: i'm using vim, i found the vim-fugitive -airline and -indent-guides help me keep track
<CompanionCube>ACTION is tempted to install guix in his almost-fresh guix-over-arch install
<NiAsterisk>could somebody enlighten me what "woodchipper" in IT/Security means?
<domenkozar>$280 left for stripping Nix of Perl :) https://www.gofundme.com/htuafwrg/
<a_e>You can have it for free in Guix :-)
<domenkozar>civodul: would guix benefit from https://www.gofundme.com/htuafwrg/ in any way?
<a_e>domenkozar: In our "nix/scripts" subdirectory I see only scripts written in bash or guile.
<domenkozar>well maybe those are rewritten from perl so you'd no longer have to maintain them
<domenkozar>I'm just asking really, I never dig into guix code so far.
<a_e>There are only 4 scripts with a total length of 197 lines.
<rekado>NiAsterisk: re rms speaking on Friday: conflicts with the dinner :-/
<rekado>two days before FOSDEM is a really bad time to feel burned out... :-/
<rekado>still haven't prepared the talks and I feel like procrastinating some more.
<a_e>Courage! Valour! Compassion!
<NiAsterisk>rekado: ah. I am not there on friday, only saturday
<rekado>NiAsterisk: rms is also going to be there on Sunday: https://www.fsf.org/events/rms-20160131-brussels-fosdem
<NiAsterisk>ah, okay. well i'll be leaving on 9PM saturday again :D
<NiAsterisk>maybe next year I stay, but being so close to brussel is just perfect for just driving there and back again on one day
<calher>mark_weaver: Installing Guix from new guide. About to guix init system. What did you say about serpent_generic and wp512? I couldn't find (initrd) in config.scm.
<mark_weaver>calher: you need to add that field, as described in the Guix manual section I cited.
<calher>mark_weaver: Like this? -- https://transfer.sh/6mhWP/config.scm
***wgreenho` is now known as wgreenhouse
<calher>Does order matter when you're putting things into the OS declaration?
<davexunit>no
<davexunit>not for the fields of the operating-system form, anyway.
<calher>davexunit: So where I put (initrd) in <https://transfer.sh/6mhWP/config.scm> is OK?
<calher>OK, let's hope this works...
<davexunit>yes
<calher>OK, githeri time!
***efraim_ is now known as efraim
<calher>davexunit: Path `/mnt/boot/grub' is not readable by GRUB on boot. Installation is impossible. Aborting.
<calher>guix system: error: failed to install GRUB on device '/dev/sda'
<CompanionCube>ACTION wondrs what to do with his working guix install
<pizzaiolo>CompanionCube: package software!
<pizzaiolo>:)
<calher>CompanionCube: Help finish the Mumble recipe.
<CompanionCube>hm
<CompanionCube>ACTION will install some more software
<CompanionCube>to the guix package list!
<calher>:( My install failed.
<CompanionCube>calher, mine isn't a guixsd install though
<CompanionCube>just guix over arch#
<calher>I quickly found that annoying, because not all packages were from Guix.
<pizzaiolo>calher: what happened?
<calher>Path `/mnt/boot/grub' is not readable by GRUB on boot. Installation is impossible. Aborting.
<calher>guix system: error: failed to install GRUB on device '/dev/sda'
<calher>I did guix system init /mnt/etc/config.scm /mnt and it did that.
<jin_>calher, try to create a boot partition
<alezost>calher: did you run it as root?
<mark_weaver>calher: that's the same issue suitsmeveryfine had. on a libreboot machine, you should still be able to boot it, but make sure not to run "guix gc" for now.
<mark_weaver>of course, there might be other problems, dunno.
<myglc2>calher: I hit GRUB errors too. One was associated with using GPT partition table, which went away when I switched to dos.
<myglc2> calher: Another was because I had something like '(bootloader (grub-configuration (device "/dev/sda1")))' where it should be '(bootloader (grub-configuration (device "/dev/sda")))'
<mark_weaver>myglc2: calher's issue is a different problem
<mark_weaver>I guess his /boot is on the encrypted root partition, and grub realizes that it won't be able to load its modules. but on a libreboot machine, it doesn't matter because libreboot has its own grub burned into the boot flash.
<mark_weaver>so on libreboot, we don't actually need to install grub, we only need to install grub.cfg which can be loaded by libreboot's grub.
<myglc2>Ooo, I'd like to have a machine like that.
<CompanionCube>is there a verbose mode for guix-daemon? just curious/wondering
<mark_weaver>myglc2: go to libreboot.org to find out more
<mark_weaver>or join #libreboot
<civodul>rekado: same here, re preparing the talks!
<civodul>domenkozar: we've already got rid of the Perl dependency ;-)
<civodul>domenkozar: and i think the next step (longer term) is to get rid of C++ :-)
<CompanionCube>so all would be guile?
<civodul>of course
<a_e>That sounds very zen. Just get rid of everything, since we need nothing after all.
<davexunit>yeah, rewriting the daemon in Guile would be great
<davexunit>and Hydra
<civodul>Hydra will have to happen sooner than expected i think
<myglc2>mark_weaver: Thanks, I check it out.
<a_e>We discussed a few hydra ideas today. Probably we should do it on guix-devel.
<civodul>yes, definitely
<NiAsterisk>hm. would it be better to reach out to torproject to ask them to do the packaging of tor browser bundle in an appropriate form for guix or torbrowser, or something involving the browser, than to maintain it by people here?
<NiAsterisk>it's on my list.. but I thought torporject, maybe it would be in their interest, or someones
<civodul>NiAsterisk: i actually asked a Tor developer in December and it seems not easy
<NiAsterisk>oh
<civodul>Debian gave up on that for instance
<civodul>in spite of the non-empty intersection between Tor and Debian people
<NiAsterisk>what do you mean exactly?
<NiAsterisk>oh.
<NiAsterisk>I remember, i use tbb i ndebian from torproject, not debian
<CompanionCube>ACTION envisions his system becoming more and more from guix over time
<civodul>another option would be to have the IceCat people (person?) pull in some of the TB patches
<NiAsterisk>oh, because we can't have firefox esr here?
<domenkozar>Civodul: awesome.
<NiAsterisk>so it needs to be some iceweasel thing
<NiAsterisk>?
<CompanionCube>327 explicitly installed pacman packages. Wonder how many would be in guix too.
<a_e>NiAsterisk: GNU Icecat. That is a natural choice for us.
<NiAsterisk>hm.
<a_e>It follows ESR, I think. There is a new major release every seven Firefox releases/
<CompanionCube>ACTION is happy with FF 43
<mark_weaver>Hydra has finished building the new security-patched icecat. make sure to update it asap, everyone!
<CompanionCube>FF 44 unfortunately has a visual break for me that was enough to downgrade
<NiAsterisk>I have some short term motivation for primary guix focus for myself, which does not involve tor primarily, but torbrowser would be a nice feature add. I want to be able to produce a laptop server, and variations of the original, with psyed+httpd+git-daemon on tor hiddenservices + gnunet and gnunet services + iptables and some more, as the basis. and then variations of pure tor etc.. it makes me sad that it will
<NiAsterisk>take some time, but I'll probably learn much about service constructions and useful things.
<NiAsterisk>being able to deploy and control it all from one file for guixsd (and including additions for just guix on host systems for example for psyced).
<civodul>mark_weaver: great, thanks for the heads-up
<civodul>grr new Magit goes in my way
<CompanionCube>is there any way to get slightly-more-verbose output from guix-daemon? or is that all stored in the build logs
<bavier>CompanionCube: guix-daemon has a --debug options
<bavier>*option
<bavier>I haven't used it myself; generally the build logs are the most useful
<alezost>civodul: yeah, I find the changes in push/fetch/pull popups and the new key bindings in Magit 2.4.0 (and later) inconvenient.
<mthl>civodul: don't be grumpy ;)
<mthl>civodul: It's the modern world!
<mthl>I like the new endless one button option switch not requiring '-'.
<CompanionCube>ACTION is installing stow as his first non-trivial package
<calher> Stallman still uses the old Tor plugin in an old version of IceCat.
<calher>mark_weaver: OK, so I can just pretend that it went OK and boot into the system?
<CompanionCube>oo, guix graph is nice
<calher>Yesh.
<calher>Installers should be Libreboot-aware; I'm tired of every system installation seeming like it's broken.
<calher>ok, here it goes! im scared!
<civodul>mthl: it's a bit annoying if things change too often
<civodul>i'm a busy person, i can't learn new keybindings all day long ;-)
<civodul>(or i'm getting old?)
<mthl>civodul: yeah maybe :)
<civodul>heheh
<civodul>i still miss the old history rewriting thing
<civodul>the interative rebase thing taken from git is just crap
<mthl>I have never used that, so I can't compare.
<mthl>what annoys you with the interactive rebase?
<calher>(crypto0) not found.
<efraim>I've been trying to think what I'm missing in guix's vim vs debian's, and it might just be python support for vim-fugitive
<calher>Could not boot.
<calher>Slot opened, but could not boot.
<calher>mark_weaver: It didn't work.
<civodul>mthl: it works ok but it's very raw: you're basically editing a sequence of instructions that git processes, not very visual
<calher>Can someone copy and paste the transfer.sh link that had my config.scm in it?
<efraim>CompanionCube: if you want a scary graph, do `guix graph -t bag coreutils`
<efraim> https://transfer.sh/6mhWP/config.scm
<CompanionCube>efraim, nah
<CompanionCube>...ohwow
<CompanionCube>it'd be nice if it would be able to output a .dot directly
<CompanionCube>rather than dumping to the terminal
<efraim>I always run it as `guix graph foo | dot -tPDF > foo.pdf`
<CompanionCube>why PDF over PNG?
<efraim>that was the first one I ever tried, but might be faster
<efraim>for making and for loading
<CompanionCube>I would think fp
<davexunit>I usually generate pngs
<civodul>'M-x guix graph v' FTW!
<civodul>"these components work together to solve the infrastructure problems of today and tomorrow."
<civodul>from https://fosdem.org/2016/schedule/event/coreos_linux_distribution/
<CompanionCube>guix graph --type=references foo | dot -Tpng > graph.png && tycat graph.png
<calher>Thanks, efraim.
<efraim>np
<CompanionCube>tycat works very nicely for viewing graphs :)
<davexunit>civodul: :/
<civodul>davexunit: do you think Guile & Guix could be said to solve the infrastructure problems of today and tomorrow?
<davexunit>matthew garret is employed by CoreOS, so I know they have smart folks over there.
<civodul>oh
<davexunit>civodul: yes, I think so.
<davexunit>we just need 'guix deploy'
<davexunit>to manage entire clusters
<civodul>GuixSD---The infrastructure problems of tomorrow are solved today.™
<davexunit>I want to see guix do things like fully automated installs on bare metal.
<davexunit>and of course virtualized deployments.
<civodul>yeah
<davexunit>the problem with Docker and CoreOS is that you need to use a different tool for each type of environment
<davexunit>CoreOS for the metal, Docker for the containers
<davexunit>they don't compose.
<davexunit>Guix can manage the whole stack.
<CompanionCube>davexunit, and kubernetes / something else for managing things at a higher level
<CompanionCube>i.e services
<davexunit>yeah
<efraim>wow I never tried tycat or typop before
<CompanionCube>tycat is one of terminology's best features imo
<CompanionCube>what's typop though
<efraim>a pop-up instead of cat-ing to the terminal
<efraim>ACTION goes to bed
<efraim>night all
<civodul>atomic upgrades & rollback! https://coreos.com/using-coreos/updates/
<civodul>(ok it takes two partitions...)
<davexunit>yeah it's pretty heavy-handed
<davexunit>I knew they had this
<davexunit>looks like you're limited to one rollback though
<davexunit>it's like double-buffering in graphics programming
<civodul>yes
<CompanionCube>ACTION is going to setup the emacs interface now
<civodul>systematic reboot, worse than 'guix system reconfigure' ;-)
<davexunit>yup
<davexunit>once again Guix has the edge.
<CompanionCube>civodul, didn't they basically take that idea/method wholesale from ChromeOS
<davexunit>we just need to *show* people these edges.
<davexunit>CompanionCube: they based their work off of ChromeOS, which is based off of Gentoo
<calher>How does this sandboxing/containerization work in GuixSD?
<davexunit>they posted a job ad on HN recently looking for Gentoo devs
<calher>davexunit: What about NixOS?
<davexunit>calher: we have the beginnings of container support implemented. more work to be done.
<davexunit>calher: NixOS offers similar features that we do.
<calher>Use NixOS. It's more mature and up-to-date.
<civodul>these companies have people paid full-time to talk about their software
<civodul>that's crazy
<calher>Guix is the IceCat of OSes.
<davexunit>calher: NixOS has been around for many more years, this is true.
<davexunit>more up-to-date is debatable. we typically have the latest versions of software.
<CompanionCube>calher, meaning?
<CompanionCube>ACTION does not use IceCat
<calher>davexunit: I mean up-to-date Nix technologies.
<davexunit>I don't understand.
<calher>CompanionCube: IceCat is a free version of firefox that's lagging way behind upstream.
<davexunit>and I don't think you can really speak to that claim.
<calher>davexunit: Guix is just a free version of Nix that lags behind upstream.
<davexunit>this is not true.
<davexunit>we are not downstream from Nix.
<calher>How is Guix not just an old version of Nix?
<calher>With scheme APIs wrapped around it?
<davexunit>how is it just an old version of Nix? you need to provide evidence of your assertion.
<davexunit>you can't state something and then ask someone to disprove it.
<civodul>calher: please see the doc at http://www.gnu.org/software/guix/help/ for background on the Nix/Guix relationship
<CompanionCube>isn't the only downstream part the nix daemon src?
<civodul>right
<a_e>calher: As said above, icecat does not really lag behind firefox, it is just the esr version (or whatever the acronym is, I mean the more stable one).
<rekado>(bah, I'll try to make some slides tomorrow on the train. Can't concentrate at all.)
<a_e>You will have a long trip I suppose.
<rekado>I hope it's long enough.
<a_e>German trains are always late, you can probably add an hour or two to the travel time :-)
<davexunit>rekado: good luck.
<calher>davexunit: Some guy who normally knows what he's talking about was putting down Nix when I mentioned it.
<calher>*putting down guix.
<rekado>(more demos, fewer slides)
<davexunit>calher: well if they said that Guix is just an outdated Nix then they don't really understand Guix.
<a_e>Demos are good.
<civodul>yup
<calher>OMG! It boots!
<calher>OK, does the keyboard layout load when the kernel boots, just like in Trisquel?
<calher>I need to know how to type in my password.
<calher>Huh: it boots up with QWERTY
<calher>:(
<calher>I told it to use dvorak-uk!
<calher>wlp2s0 link is not ready
<alezost>calher: do you mean you have (console-keymap-service "dvorak-uk") and the layout didn't change in the VT?
<calher>Huh, I guess it's not in the bare-bones config.scm.
<alezost>calher: "I told it to use dvorak-uk!" ← what does it mean?
<calher>I thought I did write it in config.scm somewhere, but grepping it says I didnt'.
<calher>And I didn't put info in there to get it to conect to the network by itself, either. Oh, wll.
<calher>well
<NiAsterisk>graphs... i like graphs: https://ptpb.pw/f9Rl.pdf it almost looks like gnunet function calls.
<NiAsterisk>on trains, I hope there's no strike going on currently, especially when I have to start at 4.30AM or 5AM the trip to belgium on saturday
<civodul>indeed :-)
<calher>Why can't I do 'clear' in terminal?
<fps>maybe the program isn't installed :)
<fps>or the bash function or whatever implemented clear in your previous system :)
<calher>but isn't that in the base system?
<fps>in ubuntu it's in ncurses-bin
<fps>as an example
<calher>Does bare-bones.scm come with coreutils?
<fps>%base-packages?
<fps>hm
<fps>installing ncurses gives you clear
<fps>yes, as i read it coreutils should be in it
<fps>see gnu/system.scm
<calher>Where is gnu/
<fps>oh, in the guix source
<calher>Is the source pre-installed?
<fps>check ~/.config/guix/latest
<calher>Why can't I do $(guix package -i foo bar baz)?
<fps>what do you mean?
<calher>Whenever I tried to install multiple things in one batch, it didn't do it.
<calher>I could only do $(guix package -i foo). Then do the same thing over again if I wanted bar.
<fps>do you get an error?
<fps>and why do you do it in a subshell?
<calher>fps: Not sure if I get an error.
<calher>fps: An IRC message is not a shell, so I have to open one.
<fps>um, a shell helps to issue commands, true..
<mark_weaver>I install multiple things with "guix package -i foo bar baz" syntax all the time. works for me.
<mark_weaver>ACTION goes afk
<fps>dunno, maybe guix package has some bug when used in a non-interactive shell
<fps>not sure, what you do precisely
<mark_weaver>fps: I think he just likes to write shell commands within $( ... ) when typing them on irc. I don't think he actually types the $( ) in the shell.
<mark_weaver>I was confused by that as well, earlier.
<mark_weaver>anyway, I have to go
<fps>cu!
<calher>I do it to symbolize opening a shell since this message that I am typing right now is not a shell. Also, I need something to show clearly that it's bash.
<fps>ok
<fps>in that case installing more than one package with a single call should work
<fps>if something goes wrong it should report an error
<calher|leela>guix package -i tor torsocks
<fps>fps@cherry ~$ guix package -i tor torsocks
<fps>should look similar for you. it tells you what it's going to install
<fps>minus the breakage :)
<fps>after executing the command you can list your generations with
<fps>guix package -l
<fps>to see if the newest generation has the packages you installed
<fps>i need to sleep, though..
<fps>good luck! :)