IRC channel logs

2016-02-13.log

back to list of logs

<janneke>ACTION is happy
<mark_weaver>:)
<lfam>pizzaiolo: I'm not sure in which commit the command was renamed, but the transition started with e932d371e5ab
<pizzaiolo>ah thanks
<cbaines>I'm trying to setup dbus and gconf... (I'm getting this error when trying to run some software "GConf Error: Failed to contact configuration server; the most common cause is a missing or misconfigured D-Bus session bus daemon.")
<cbaines>Is gconf a service that is currently available?
<lfam>I don't see the string "gconf" in gnu/services, so I guess not. We are still working on providing a full-feautured GNOME environment. Perhaps you could try making the service?
<cbaines>Do you have any clues about the right syntax to get the avahi service working? I am getting some type errors currently
<cbaines>I have "(dbus-service (avahi))" so far
<lfam>To be honest, I haven't explored services very much yet, since I'm not running GuixSD "full-time" of any of my machines :(
<lfam>You might get some good advice if you share the context and the error messages
<lfam>I have a to-do wishlist of services that is growing rather long...
<cbaines>Its discussed in the desktop services part of the documentation, I just have not guessed the right syntax so far https://www.gnu.org/software/guix/manual/html_node/Desktop-Services.html
<lfam>Yes, I think we need some more examples of how to do things with services, at least for the Scheme novices like myself :)
<lfam>I used this git repo for help doing some very basic stuff, it might help you too. Although it's author warned me that it was not the best place to take examples from. I don't know whether that was modesty or if there are some real problems with it: https://git.dthompson.us/dotfiles.git/blob/HEAD:/dotfiles/.dmd.d/init.scm
<mark_weaver>cbaines: see %desktop-services in gnu/services/desktop.scm
<mark_weaver>cbaines: (avahi-service) now automatically takes care of telling dbus-service about avahi.
<cbaines>Ah, so I should already have avahi and dbus (as I have %desktop-services in my config already)
<mark_weaver>yep
<cbaines>Great, thanks :)
<mark_weaver>np!
<mark_weaver>cbaines: you probably want this in your OS config, though: (name-service-switch %mdns-host-lookup-nss)
<mark_weaver>to enable resolution of .local names
<pxc>hey guys! I'm a nixer currently diving in with Nix and NixOS and I was wondering if any of you fine folks have a good way of managing similar or overlapping Nix and Guix configurations without much duplicated effort.
<pxc>I'd like to learn them together if I can, and it's not too overwhelming. I want to be in touch with Nix development and use tools like NixOps, but I would really love to run a complete GNU system at home on at least one of my computers.
<mark_weaver>pxc: I'm not aware of any tools for that. Apart from the daemon and fundamental concepts, Guix is quite different. All of the package descriptions, services, system declarations, etc, were built from scratch.
<mark_weaver>but civodul (Ludovic) would be a good person to ask, since he was (is?) a Nix developer as well.
<pxc>Ah. Does Guix still use nix-eval and nix-instantiate at bottom?
<mark_weaver>I don't think so. those names are not familiar to me.
<pxc>okay
<mark_weaver>we use guile on both the client and build sides. guile programs direct the build process of all packages.
<lfam>I'm almost 100% sure no, because our nix package importer requires nix-instantiate, which in practice means running a full Nixpkgs system alongside Guix.
<mark_weaver>well, all non-trivial derivations.
<pxc>It would be cool if Nix and Guix (the package managers, not the projects) could at least be aware of each other. That way if I prefer Guix, I can use it for most things but also take advantage of Nix packages others have put together when I have to, or before porting them over.
<mark_weaver>we don't use the Nix language at all
<mark_weaver>we are certainly aware of each other :)
<pxc>I meant the softwares, running on the same system :P
<lfam>My understanding is that it is _possible_ to share a daemon and a store. Some people have made it work. And I have a NixOS VPS that I use Guix on.
<lfam>But on my VPS, the daemon and store are not shared.
<pxc>hm. God. These projects are so interesting that my ambition really runs wild when I contemplate them.
<mark_weaver>pxc: civodul is really the person who could answer your questions most efficiently. I suggest posting on guix-devel or guix-user about it, and letting him respond.
<pxc>but maybe I'll try to figure out how to do that
<lfam>pxc: Indeed :)
<lfam>mark_weaver: There's a guix-user list? Or do you mean help-guix?
<mark_weaver>sorry, I meant help-guix
<pxc>on Nix I wish I had a fancy editor that would do autocompletion and stuff for me, for writing new packages and editing my config
<pxc>so
<pxc>is the Emacs interface as sweet as I hope it is?
<mark_weaver>pxc: but I'll just say that while it's possible to run Guix and Nix together on the same system, and even sharing the same daemon, they would essentially be two completely separate systems with no sharing of underlying libraries. e.g. they would each have their own libc, etc.
<lfam>Yes, that's true. Most of the benefits are lost.
<pxc>aaah. okay
<mark_weaver>pxc: and I suspect there would be difficulties even referring to a mixture of Guix and Nix packages via environment variables.
<pxc>the derivations/closures each package manager produces are not formally equivalent?
<mark_weaver>e.g. you'd end up trying to link libraries together into an executable, although they are based on different libc and run-time linker, etc.
<pxc>hm.
<mark_weaver>the derivation format is the same, but that's very low level
<mark_weaver>basically just a list of inputs, command to run, arguments, environment variables.
<mark_weaver>I have to go afk for a while. ttyl!
<pxc>k. thanks :-)
<lfam>janneke: I think your tclxml patch no longer applies to master. Can you update your copy of the master branch and rebase your patch on that?
<pizzaiolo>anyone knows if marcus ever solved these issues? https://lists.gnu.org/archive/html/gnu-system-discuss/2015-08/msg00003.html
<pizzaiolo>I'm also experiencing them
<pizzaiolo>petter: did you have an issue with the touchpad?
<janneke>lfam: working on that :-)
<lfam>Thanks! It's much easier to do that from your local branch than with just the patches.
<mordocai>Btw if anyone has the time/inclination, I would love it if someone could review the update to my ccl + sbcl upgrade patch on the mailing list.
<mordocai>technically two patches, one email
<janneke>lfam: yes and i need to test it, made the patch a bit smaller too
<janneke>i'm wondering, why is there no guile-lib-next?
<lfam>mordocai: Review sent :) In general, it's easier to review patches if all the "unusual" parts, like disabling tests, have some context and explanation. Even if it is just speculation. Otherwise it's hard for me to make a judgement without doing some investigation that you have probably already done :)
<mordocai>lfam: Yeah, I originally had that in the commit but apparently that's not allowed :P
<mordocai>lfam: Not sure where the proper place to put such an explanation is. Preferably somewhere people can look it up later.
<mordocai>at work it'd be the commit message
<lfam>What do you mean by "not allowed"? In any case, it can at least go in the email itself. Any context is better than nothing.
<lfam>Oh I see Efraim's comment. It's true, we usually wouldn't put that in the commit message. When I disable tests, I like to put a comment in the package definition itself, and also explain in my email. If the disabled tests are due to an upstream bug, I include a link to the bug in the comment in the package definition.
<mordocai>Alright, i'll work on a better explanation and send up a new patch.
<mordocai>I need to try to reproduce it and ask #guile about it anyway since the theory is it is some kind of regex parser issue.
<lfam>It's nice when we help fix bugs or make improvements in other projects :)
<janneke>ACTION zZzz
<NiAsterisk>hi.. a short question before I'm going to sleep: is guix ath9k-htc-firmware also responsible for ar928x functionality (ar kernel module)?
<orly_owl>most likely
<NiAsterisk>cool. very sleepy, but I have a mostly free corebooted laptop now :)
<orly_owl>why not libreboot?
<NiAsterisk>because of reasons I'm too tired to explain in long detail, short version is I talked to someone involved in the coreboot project who explained and helped me with setting it up in the hackerspace.
<NiAsterisk>good night :)
<paroneayea>ACTION tries to understnad the things that have changed about python packaging for py2
<davexunit>ACTION tries out iyzsong's gnome meta-packae
<calher>How do I specify dependencies? Something about G-expressions...
<mordocai>Bleh, so I tried to set path to only guix path (no debian) on my debian testing + guix box and discovered su/passwd don't work (they give permission denied errors) and gnupg2.0/gpg-agent can't find pinentry...
<mordocai>I know lfam runs guix on top of debian testing, anyone else have experience with it?
<mordocai>In any case I guess guix is downgraded to "play with when I feel like it status" from "use all the time".
<xd1le>mordocai: ugh, that sucks.
<xd1le>mordocai: why did you want to do that?
<xd1le>would there be a benefit?
<janneke>git build laby
<janneke>git: 'build' is not a git command. See 'git --help'.
<janneke>
<janneke>Did you mean this?
<janneke>:-)
<lfam>giux biuld foo
<janneke>lfam: pondering about sending a suggestion patch to git :-D
<NiAsterisk>so according to what I found out last year, +-1c.1-[02]----00.0 Qualcomm Atheros AR928X Wireless Network Adapter (PCI-Express) [168c:002a] should work with linux-libre. but, it does not work out of the box somehow it turns out. do I have false info?
<NiAsterisk>h-node.org says they are libre.
<NiAsterisk>kerneldriver in use: ath9k. and yet the card is unavailable to wicd.
<NiAsterisk>ACTION continues testing
<cbaines>I am getting an error when running guix build "has an invalid input: ("which" #<procedure which (program)>)"
<cbaines>This is for a package I am trying to define
<cbaines>I copied the example from the icedtea-6 definition
<a_e>Did you add this:
<a_e>#:use-module (gnu packages base)
<a_e>This is where the "which" package is defined.
<a_e>I see, you are not using "which" as an input. But the scheme procedure.
<cbaines>The use-module line is at the top of the file
<cbaines>I am trying to add a definition (for vcsh) in version-control.scm
<a_e>The scheme procedure is defined somewhere else.
<cbaines>I don't think I want the scheme procedure?
<cbaines>I want to specify that the package "which" is a native input?
<cbaines>(but I am not sure if the two above things are the same or different)
<a_e>Okay. I just wondered because you mentioned icedtea-6. It uses "(which" in one of its phases.
<a_e>This comes from guix/build/utils.scm .
<a_e>To use it at build time, I think you need to add
<a_e>#:modules ((guix build utils))
<a_e>to the package, as done in icedtea-6, and add it to the native inputs.
<a_e>I hope your package is easier than icedtea...
<cbaines>I am not sure that has helped, I am not trying to use which in the arguments
<cbaines>If I build the package without trying to specify the input, it fails as it can't run which.
<a_e>Then it should be enough to add the native input indeed.
<cbaines>guix build utils is pulled in at the top of the version-control.scm file, perhaps that is the reason why things are not working
<a_e>Indeed, that will create a conflict between the two scheme variables.
<cbaines>That may have helped, but I now get a Backtrace which ends with "ERROR: Unbound variable: gnu-build"
<a_e>Could you start by trying to comment out the #:use-module (guix build utils) at the beginning of version-control.scm?
<cbaines>Done that
<a_e>It does not seem to be needed, the file compiles very well without it.
<a_e>Then there should only be the package WHICH left.
<a_e>So you still get the same error>
<a_e>?
<cbaines>Sorry, being really slow
<cbaines>I think I could have a bracket mismatch problem somewhere...
<cbaines>a_e, No, different error now
<cbaines>The build starts, but there is a backtrace
<cbaines>ERROR: In procedure memoize-variable-access!:
<cbaines>ERROR: Unbound variable: gnu-build
<a_e>Strange. This comes from the build system.
<a_e>Could you paste your package somewhere?
<cbaines>Yep...
<cbaines>Ah, trying to push a branch using git, but git does not work
<cbaines>error: cannot run ssh: No such file or directory
<cbaines>Any tips on making git work?
<a_e>Install ssh? :-)
<a_e>Where do you want to push it? Since you do not have commit access on savannah, it will not work.
<cbaines>I'm pushing to my own server
<a_e>Then try to install ssh from guix, just in case. It should work also with the ssh from your own distribution (assuming you are not using guixsd).
<a_e>But who knows.
<cbaines>I have it on the web now http://git.cbaines.net/guix/commit/?h=vcsh&id=184da0b5b273ed35c7e314d2d53dd9b0f36119c9
<cbaines>I am using GuixSD
<cbaines>Ended up pushing it up via my laptop (running Debian) in the end
<a_e>Drop the line #:modules ((guix build utils)) again...
<a_e>Now it looks for "git" during build, which is a bit suspicious.
<cbaines>That is one of the build dependencies of the Debian package, so that does not surprise me
<a_e>It works! Congratulations!
<a_e>So we can do an online review :-)
<a_e>Instead of "alist-delete", you should use the more modern "modify-phases" syntax (there are example packages using it).
<a_e>Some metadata needs to be updated, and I think you are good for submitting your first package to the mailing list.
<a_e>Congrats again!
<cbaines>I'm still working on getting the brackets right...
<cbaines>Will hopefully be celebrating soon
<a_e>Okay. That sounds like a problem that can be solved.
<a_e>Potentially by changing editors :-)
<cbaines>I think I have it now, just waiting for it to finish building
<cbaines>For some reason its now downloading git (I'm sure I already have some git package on my system)
<cbaines>The git package is also 247MiB!!!
<a_e>Maybe not the latest one? It downloads the one corresponding to the current package recipe.
<a_e>This will need investigation.
<a_e>To see what it really needs from git.
<a_e>Okay, I will leave for the moment.
<a_e>I set myself the boring task of reading the documentation, so I could also install GuixSD. I feel late to the party...
<cbaines>Thanks for all the help a_e :)
<a_e>You are welcome!
<myglc2>a_e: Using guixSD and reading the doc is kinda like feeling different parts of an elephant in a dark room :-) I'd be interested in your impression.
***kelsoo1 is now known as kelsoo
<a_e>myglc2: Okay, I will see. Right now I am still at the Guix description. Even there, I am learning new things!
<myglc2>a_e: IMHO the doc is excellent. The multiple ways guix/SD can be used make it is hard to write and injest.
<NiAsterisk>now you can buy(rent) movies, hardware, and other things on Steam next to games.. wild... if you imagine it's all built on DRM and similar systems and introducing it as mandatory for the orange box some 12 years back (or more? at least my account from playing counter strike back then is 11.5 years old)..
<NiAsterisk>it's like the amazon of games.
<NiAsterisk>sad.
<NiAsterisk>well it will be the amazon of games once they start offering drinks and all.
<NiAsterisk> /OT
<cbaines>Does anyone have email client recommendations (that are available on Guix)? (I am used to using Icedove/Thunderbird)
<NiAsterisk>there's claws
<NiAsterisk>and GNUS, i personally use notmuch + gnus
<Jookia>I use Mutt
<rain1>hi
<rain1>I was wondering how to do the system configuration for a luks encrypted disk
<rain1>is there an example? when I tried it I got an error about could not match pattern but it didn't say what I did wrong
<mark_weaver>rain1: here's a draft of proposed changes to the Guix manual to describe how to set up an encrypted root partition on GuixSD: http://sprunge.us/PMib
<mark_weaver>(written by petter here on channel)
<mark_weaver>a few additional notes: you should run "guix pull" from the USB installer after starting the cow-store, to use the latest guix from git.
<rain1>thanks!
<mark_weaver>and beware that /boot will need to be unencrypted if you plan to use the GRUB on the hard disk that we install.
<mark_weaver>With Libreboot (or coreboot with suitable GRUB and grub.cfg in the boot flash) it is possible to encrypt /boot as well, but there are some minor complications during install in that case. let me know if this case applies to you.
<rain1>yeah ill do grub with boot unencrypted
<mark_weaver>okay, in that case make sure to add and 'file-system' declaration for /boot in the OS config, and to mount it on /mnt/boot before running "guix system init"
<mark_weaver>*add a
<NiAsterisk>I don#t have the content of the proposed changes infront of me right now, but what about the cryptdisk way where you have the crypt headers on a usb disk and the boot on another usb disk? this should theoretically work. I have not tried this with guixsd though..
<rain1>i've heard thats a good way to do it but i've already set up for this way
<NiAsterisk>okay :)
<rain1>what pastebin is preferred here?
<mark_weaver>rain1: anything that doesn't block tor (as pastebin.com does). http://paste.lisp.org/new is one option
<Jookia>Doesn't freenode block Tor?
<NiAsterisk>yes it does
<rain1>they allowed tor for a while
<rain1>even oftc blocks it today though
<mark_weaver>Jookia: yes, but fixing that would be a bigger job for us.
<NiAsterisk>now they are working on a way to de-anonymize tor users to allow it again
<mark_weaver>they used to allow Tor, and we should probably see how we can help them enable it again.
<NiAsterisk>i like how hackint handle it.
<Jookia>'Solve these Google CAPTCHAs to get on to Freenode' :P
<mark_weaver>afaict, freenode has struggled to even keep the network working well in the face of frequent attacks.
<NiAsterisk>and yet every 2nd project continues to use freenode or irc. tried to talk to people before about alternatives, but at some point it's just enough, priorities.
<NiAsterisk>i'd like if gnu projects would have a tor enabled, with hiddenservice available, chat network.
<rain1>what about having running a new IRC network that allows tor connections?
<NiAsterisk>new irc networks are no solution to the overall issue with irc.
<NiAsterisk>if it must be, then there are existing networks already offering tor
<mark_weaver>I get the impression that keeping freenode alive in the face of all the attacks on it is a big job.
<mark_weaver>I'm not sure how starting a new IRC network would solve that problem.
<NiAsterisk>rain1: http://about.psyc.eu/IRC
<rain1> http://paste.lisp.org/display/307176
<rain1>I've taken the desktop config and added mapped-devices and changed file-systems, does this look good?
<NiAsterisk>atm I think using one of the tor friendly networks, like hackint, mufhd/ai, psyced.org(xmpp,telnet,irc,...) are solutions to the freenode/oftc issue.
<NiAsterisk>later on it can be replaced by an irc-like solution based on PSYC2.
<jjmarin>Maybe this is of the interest on some of you https://www.change.org/p/lenovo-release-an-unencumbered-version-of-the-bios
<jjmarin>I have a lenovo thinkpad with this problem :/
<NiAsterisk>urgh change.org
<jjmarin>NiAsterisk: Well it is the platform where this campaign is
<NiAsterisk>i know how problematic lenovo is, but if I'm done with EFF communcation I might give you an update later this year why change.org is equally problematic, at least for people in europe (but i guess what I want affects other people around the world too). on topic: this is 2 years old and no reaction from lenovo.. I don't see how some signatures on a data-selling plattform who pretend to be non-profit will reach
<NiAsterisk>something at a huge global company like lenovo.
<jjmarin> NiAsterisk:
<jjmarin>sorry
<jjmarin>NiAsterisk: You are right, it is an old campaign, I haven't noticed till you tell me. It is on the top in https://www.bios-mods.com/ and I've got confused. I'm spending the whole day how to fix this problem without bricking my laptop
<NiAsterisk>it's okay and wasn't meant to be personal, I just wanted to point this out :)
<NiAsterisk>oh, okay
<Steap> actual-error: (system-error "delete-file" "~A" ("No such file or directory")
<Steap>grmbl
<Steap>y u no tell me what file it is :'(
<rain1>qemu-system-x86_64 -drive index=0,media=disk,file=my_guix_disk.cow,format=qcow2 -drive index=1,media=disk,file=guixsd-usb-install-0.9.0.x86_64-linux,format=raw
<rain1>this isn't working, what shoudl i do to boot guix in qemu?
<rain1>got it
<rain1>guix pull failed in qemu because it ran out of memory :(
<efraim>are we affected by the postgresql CVEs? CVE-2016-0766 and CVE-2016-0773?
<efraim>standard qemu image is 256m of ram? I think because of guix-daemon our recommended minimum is 768m
<rain1>I was using 512M
<davexunit>gnome is working pretty decently!
<davexunit>some stuff missing, but overall it's good!
<davexunit>good enough to use as a daily driver over xfce.
<mark_weaver>rain1: did you start the cow-store service?
<mark_weaver>(before running guix pull)
<rain1>yeah
<rain1>im trying again with 1G memory
<rain1>I decided it would be better to try getting all this crypto stuff working in qemu before metal
<davexunit>I tried packaging the GNOME Tweak Tool. it compiles, but the executable, which is already wrapped, needs to be additionally wrapped with the correct PYTHONPATH, which is proving difficult.
<mark_weaver>it's okay to double-wrap afaik
<mark_weaver>(even if not ideal)
<mark_weaver>efraim: given that our postgresql package was last updated in July 2015, I guess we're affected.
<mark_weaver>efraim: if you'd like to handle it, I'd be grateful
<mark_weaver>davexunit: so configuration works now, e.g. configuring caps lock to be a control key in gnome-shell?
<mark_weaver>(that was the show-stopper for me when I last tried)
<davexunit>mark_weaver: I haven't tried that yet.
<davexunit>the thing I am currently missing most, besides the tweak tool, is whatever daemon will automount usb drives when I plug them in.
<rain1>is that related to gvfs maybeq?
<rain1>(not an expert)
<efraim>mark_weaver: think we should upgrade to the latest 9.3.x, or move up to 9.5.1?
<efraim>or maybe something dbus related, but gvfs is also likely
<rain1>what about a wiki for guix?
<a_e>rain1: It has been suggested several times, each time the conclusion has been to rather submit patches for the main documentation :-)
<rain1>it could lower the bar to contributing tips and info, help collect useful bits that aren't documentation quality yet
<davexunit>we really prefer to get things into the manual
<fhmgufs>rain1: I think, there shouldn't be documentation that isn't in documentation quality.
<rain1> http://sprunge.us/PMib this is really helpful to me right now
<a_e>rain1: This, or at least part of it, will be merged to the main documentation.
<a_e>The machine on which I wanted to try out GuixSD does not boot from USB. So there is nothing to do, eh?
<mark_weaver>a_e: if you can get into a GRUB on that machine, you should be able to use it to load the grub.cfg from the USB installer and boot it
<mark_weaver>On Libreboot machines, for example, that's the only way to boot our USB installer.
<janneke>I use this hack to boot into Debian: http://paste.debian.net/384175/
<a_e>mark_weaver: Okay. I have no experience with grub, but I can give it a try. Thanks!
<janneke>how do you do it, can we/should we offer a nicer solution?
<jubalh>hello
<efraim>hi!
<jubalh>how is it going?
<rain1>networking seems to have died inside my guix qemu but i don't understand why
<fhmgufs>How do I define a dummy package? I thought this couldn't be so difficult. Do I need origin for example?
<mark_weaver>fhmgufs: I realize that merely a dummy package won't be enough. the code that creates our initramfs will try to copy specific files to it from your kernel, including modules, etc.
<mark_weaver>fhmgufs: I would really encourage you to get a BeagleBone Black and using that instead.
<fhmgufs>I'll take a look at it.
<mark_weaver>for a bit more money, the Wandboard is more than capable of building Guix on its own from source.
<mark_weaver>running GuixSD on such a small machine as the BBB (or RPi) is something that's not yet been tried afaik, so there may be difficulties to work through, dunno.
<NiAsterisk>do you think https://tails.boum.org/contribute/design/memory_erasure/ would be doable at some point in guixsd?
<rain1>ifconfig ens3 up ; dhclient ens3 ; ping gnu.org but i get 100% packet loss
<NiAsterisk>possibly in a future where guix might ship a live medium.
<mark_weaver>NiAsterisk: sure, I don't see why not
<mark_weaver>rain1: I don't have much experience using VMs, so I can't help, sorry.
<mark_weaver>NiAsterisk: fwiw, I really like the idea of working toward something like Tails built using Guix.
<NiAsterisk>thinking about it, as some things I'd like to try on other systems.. when the 3tb urandom finish, i'll bring one system back to gentoo, maybe see if I can help someone bringing guix to gentoo (although portage policy and content sucks)
<rain1>i was thinking i should practice in a vm before doing it for real
<NiAsterisk>mark_weaver: i like the idea to work towards something in the next ~3 years to get something like tails in 1+n flavors for gnunet related things in the future. others voted for debian+guix, but it might be doable with guixsd for a number of limited devices.
<rain1>but it seems like that isn't working
<mark_weaver>NiAsterisk: we already have the binary installer, I'm not sure how much a gentoo package would help. and anyway, last I checked, gentoo had guile-2.0 blacklisted (or whatever their term is)
<rain1>im not sure what to do, giving up is easiest
<NiAsterisk>mark_weaver: I discovered guile2 in an onion overlay (ebuild storage) of someone i know
<NiAsterisk>my attempt to package guile2 for gentoo broke my system, but his might work
<mark_weaver>rain1: qemu probably needs some special configuration to pass the network packets through to the outside world and back.
<mark_weaver>NiAsterisk: anyway, what's the advantage of a gentoo package over our binary installer?
<mark_weaver>no matter how you do it, you'll end up using binaries from us anyway, even if only our bootstrap binaries.
<rain1>but wasn't it networking already with guix pull and stuff
<NiAsterisk>idk.. I just know people who'd like to see guix in gentoo for their own packages they maintain themselves, and I like challenges :)
<mark_weaver>NiAsterisk: if people want to see Guix in Gentoo, the first step is to unblock guile-2.0, which would be a good thing to do anyway.
<mark_weaver>we haven't supported guile-1.8 in years. it's terrible for us that Gentoo is still locking their users to that old version.
<NiAsterisk>i want to check the guile2 i've seen in the onion.. if it works without flaws, i see no problem in *trying* to talk to portage involved people. I'm not okay with some things in gentoo, some crypto related software is just sitting there 5 years outdated.. I did update it myself and never push to portage
<mark_weaver>well, "locking" is too strong a word. let's just say that they are strongly discouraging using a supported version of guile.
<mark_weaver>actually, there's another way. make a gentoo package for guix that just uses our binary installer.
<NiAsterisk>were the challenge in that?
<NiAsterisk>or do both
<NiAsterisk>guix-bin and guix
<mark_weaver>well, I think it's a waste of time, but as you wish.
<rain1>ill try virtualbox instead
<mark_weaver>everything in guix is going to be compiled by guix and linked against only guix libraries, built with guix compilers, etc, starting from our pre-built static bootstrap binaries, anyway.
<mark_weaver>and even the first time you use "guix pull", you'll be recompiling guix using guix's toolchain and libraries.
<NiAsterisk>i think the reason for not using binary way for them was to be able to compile it at first attempt on their system to make sure that the sources are okay. or whatever, i never asked, but I assume that's part of the reason
<mark_weaver>so going through efforts to compile the first copy of guix using the gentoo toolchain and libraries, only to immediately replace it on the first 'guix pull' seems rather pointless
<NiAsterisk>true
<NiAsterisk>might be that they wrote an guile2 ebuild just for guix
<mark_weaver>ACTION goes afk
<fhmgufs>Well, for now I just have my Raspberry Pi.
<fhmgufs>I really would like to use a board more suitable for free software, but I won't get another 1 GHz quadcore for this price.
<fhmgufs>If I want to use the Raspberry Pi (and I think theoretically there's nothing that makes that impossible), I need to disable GRUB, the kernel installation and the initramfs.
<fhmgufs>And I'm sure there is a way for doing so.
<fhmgufs>The files I already have in /boot are enough to successfully launch /sbin/init (shepherd), so there shouldn't be any other problems.
<davexunit>we're a real distro now: https://distrowatch.com/table.php?distribution=guixsd
<jubalh>:)
<jubalh>Origin: USA ? oh?
<rain1>guix substitute: error: host name lookup error
<a_e>Who knows where they got it from.
<davexunit>hmm, it's accurate in the sense that the GNU project is associated with the FSF, which is in the USA, but it's not accurate in the sense that Ludovic is from France.
<a_e>Also, "Live Medium" is only sort of correct.
<davexunit>our installer is a live medium
<a_e>But it is not working out of the box, is it? One needs to instantiate the system first.
<davexunit>but it's a live GuixSD distro running
<davexunit>it just doens't have much software
<pizzaiolo>davexunit: woo
<NiAsterisk>distrowatch is often not very accurate.
<a_e>How do I load the grub config file from the USB stick when I am in grub rescue mode?
<NiAsterisk>wow. traveling between these two cities really sucks on saturdays.. need to go to the hackerspace to get some stuff, if I hadn't been that slow today, I wouldn't need to wait until 3AM for the next best subway back, when I go there on 9PM
<a_e>It looks like its partition is called "(hd1,msdos1)".
<mark_weaver>wow, I guess I'll know not to put much confidence in the accuracy of distrowatch's descriptions...
<mark_weaver>Origin: USA
<davexunit>yeah...
<mark_weaver>Desktop: Xfce
<mark_weaver>Category: Education, Live Medium
<mark_weaver>???
<a_e>Okay, I am getting there. Readline support in grub would be nice :-)
<NiAsterisk>yeah.. i wouldn't rely on distrowatch. it's okay guix is on there now, but that's all.
<NiAsterisk>they suck in bein gaccurate
<a_e>mark_weaver: I am in grub rescue mode, since I emptied the hard disk on this computer.
<a_e>The command "configfile" is not available.
<a_e>Is there a way of loading our grub.cfg (without installing debian first...).
<mark_weaver>it sounds like you're using a very stripped-down GRUB that can't find its own modules.
<a_e>I am surprised it is there at all.
<mark_weaver>it's probably not enough to boot the USB installer
<a_e>Okay. Then I will install a minimal debian or so first.
<a_e>Or try Knoppix
<mark_weaver>that distrowatch page claims that guix-0.9.0 used GRUB 2.0.0beta2 (?)
<mark_weaver>and suggests that we have updated mesa since 0.9.0, which I'm pretty sure is not true.
<mark_weaver>I don't know where they got this data from
<mark_weaver>oh, and it says that we now have qt-5.5.1 but that guix-0.9.0 had qt-1.2.0 (??)
<mark_weaver>well, nevermind this :)
<janneke>mark_weaver: a bash script that runs without -e
<mark_weaver>oh, and it says that we have systemd
<mark_weaver>and thunderbird???
<mark_weaver>bah, what a bunch of misinformation...
<a_e>Some of them are followed by blank version numbers.
<mark_weaver>or maybe the left column is just saying what the latest versions of those upstream packages are
<a_e>Yes, I think so.
<mark_weaver>in any case, there are still many inaccuracies
<a_e>When the right column is empty, it means we do not have it.
<a_e>mark_weaver: I installed a minimal debian from cd, and now I can boot the grub from the usb stick! Thanks for the suggestion.
<mark_weaver>a_e: that's good!
<CompanionCube>hm, it'd be interesting to combine GuixSD with Bedrock Linux
<CompanionCube>would be an interesting solution to any issues of missing/unavailable packages
<rain1>i wish guix sd installed faster
<absorto>hello! So I have these Power7 machines with AIX. Wouldn't it be great if I could use Guix in them? :-D
<a_e>mark_weaver: Now dhclient does not give me an ip address. It returns empty handed after a few minutes.
<mark_weaver>a_e: ethernet or wireless?
<a_e>Ethernet, to make things simpler.
<mark_weaver>does it require a blob to work?
<a_e>Maybe.
<mark_weaver>also, "ifconfig <device> up" might be needed first.
<a_e>That one I already did.
<mark_weaver>also beware that the device names are different than what you might be used to.
<a_e>Yes, the device is the good one.
<mark_weaver>but I guess you would have noticed that by now
<a_e>Debian asked me for two firmwares. One I recognised as being for the Intel wireless card. The other one I have forgotten; something starting with a "T".
<mark_weaver>a_e: passing -d to dhclient should run it in the foreground with verbosity
<a_e>Ethernet requiring proprietary blobs?
<mark_weaver>possibly. I don't know how common it is
<mark_weaver>you might be able to find the model of your ethernet adapter using "lspci" or in the "dmesg" output
<a_e>A problem with the cable. It should work now!
<mark_weaver>ah, good!
<a_e>Thanks for the heads up!
<rain1>so im getting perl-5.22 for liku 20 mins already
<rain1>14Mb transferred
<rain1>it's taking so extremely long
<efraim>ouch
<rain1>i wonder if there's another way to do this, like torrent or something
<mark_weaver>rain1: our substitute server is badly overloaded. it should be better in coming weeks.
<rain1>or IPFS
<a_e>herd does not exist. So "herd start cow-store /mnt" cannot work.
<a_e>Can I do a "guix pull" now, or should I simply issue a corresponding dmd command?
<mark_weaver>a_e: s/herd/deco/ on the 0.9.0 installer
<mark_weaver>don't run "guix pull" until after starting cow-store
<a_e>Okay.
<rain1>build failed with 502 bad gateway :(
<rain1>trying again
<mark_weaver>rain1: that happens sometimes when hydra is badly overloaded
<rain1>i see, can i use something else than hydra?
<rain1>or should i just try this again tommorow
<mark_weaver>we outgrew that old VM months ago. a hardware replacement is in the works.
<mark_weaver>rain1: just keep retrying it.
<rain1>okay
<rain1>hmm
<rain1>error build filed while setting up build environment: opening file `/proc/self/mountinfo` no such file or directory
<rain1>i wonder if that means i misconfigured the system
<rain1>this is from running: guix system init /mnt/etc/config.scm /mnt/
<mark_weaver>rain1: from within our USB installer? within a VM? with the kernel on our USB installer?
<rain1>yeah im booting the usb inside virtualbox
<rain1>trying to install guixsd onto a fresh (virtual) disk
<mark_weaver>so you're using the kernel on our USB installer?
<rain1>yes
<mark_weaver>well, I don't know what's going on there.
<mark_weaver>I've never seen a report of this problem before
<rain1>it might be related to the crypto stuff then
<rain1>since i guess nobody does that
<mark_weaver>seems unlikely
<mark_weaver>several people have followed the guide I linked to you and successfully installed GuixSD with full disk encryption.
<rain1>oh cool
<rain1>have any shared the config.scm they made?
<mark_weaver>I don't see how that would cause this error
<mark_weaver>I don't think this has anything to do with the config
<mark_weaver> /proc/self/mountinfo should be there with the kernel we provide
<mark_weaver>can you see it from the shell?
<rain1>well there is no /proc/self
<rain1>in fact /proc is empty
<rain1>mount fails, failed to read mtab
<rain1>ill reboot
<mark_weaver>rain1: when you booted the USB installer, did you do so via the GRUB on the USB stick?
<rain1>yeah
<rain1>the way i boot the usb is to add it as a secondary hard drive
<mark_weaver>we mount /proc during early boot
<mark_weaver>I don't know how it became unmounted
<rain1>ive rebooted and proc is there
<lfam>rain1: Are you still having trouble running GuixSD in QEMU
<lfam>?
<paroneayea>hm
<rain1>lfam yeah i gave up and am using virtualbox now
<lfam>The version of the manual found on Guix's git master branch has a section about how to do it. The version of the manual on the web site hasn't been updated to include that section yet.
<lfam>virtualbox :(
<lfam>The instructions in the manual should *just work* and if they don't I'd appreciate some feedback so I can fix them :)
<lfam>You can build the HTML version of the manual from git with `make doc/guix.html`
<rain1>thanks
<lfam>rain1: If you do have some feedback for me on that subject, please send an email to the list or leave a message for me here on IRC using our bot, sneek. You can ask sneek to save a message for me like this
<paroneayea>hey lfam
<lfam>sneek: later tell rain1 Good luck!
<sneek>Will do.
<rain1>sorry what
<sneek>rain1, you have 1 message.
<sneek>rain1, lfam says: Good luck!
<paroneayea>lfam: do you have a few to explain the state of the python2-variant stuff?
<paroneayea>I'm trying to follow it all in my mediagoblin packaging stuff and trying to make sure I understand properly
<lfam>Yes, as far as I understand it ;)
<paroneayea>that's as far as I'll likely need!
<lfam>If your python2-variant needs no special changes from the python3-variant, then you can just use 'package-with-python2' as before.
<paroneayea>lfam: ok, but if, for example, I don't need setuptools in py3, I can drop it there, etc
<rain1>I can't do the cryptomount part
<lfam>Otherwise, you must register a variant in the python3-variant of the package, as in python-cryptography. As described in guix/build-system/python.scm, this variant-property is "used as a key to search for [a] pre-defined variant" of the python2 transformation.
<paroneayea>lfam: right, and it's delayed so as to not introduce a cycle, then
<lfam>In that case, I referred to Ludo's patch series starting with 1be83341f to understand how to construct the python2-variant with the new system.
<paroneayea>lfam: got it...
<paroneayea>ok!
<lfam>Once this is done, all the consumers of the python2-variant can be simplified, as they no longer need any special treatment to find correct python2-variant. However, you don't *have to* update these consumers. They will continue to work as before.
<lfam>So, it will actually add lines of code if the only python2 difference is to provide setuptools. But there were some real problem packages that were blocking other packages, so overall I'd say it's a win.
<paroneayea>lfam: ok, thanks for the clarity!
<lfam>I hope that helps. I'm still learning Scheme, so I am unfortunately "cargo-culting" some things. For example, I didn't understand the differences between some of Ludo's python2-variant examples. But I do try to look things up and understand them.
<lfam>It's possible that some of my python2-variants could be optimized. But they do work ;)
<lfam>I need to convert some of the big shell scripts I use day-to-day to Scheme. I think that will help me a lot.
***parab is now known as parabool
<paroneayea>lfam: good luck :)
<paroneayea>it's a lot of fun generally
<lfam>Thanks :)
<CompanionCube>ACTION wants to learn both Scheme/Guile and Smalltalk
<lfam>Yes, I like the paradigm a lot. My shell scripting is already somewhat functional. I try to make functions return a value that can be directly consumed by other functions, as in do_something $(with_the_result)
<lfam>But it's rather limited since the return value must be a line of text.
<rain1>hooray! booted an encrypted guix
<efraim>mark_weaver: I've updated postgresql to 9.3.11 locally, which causes ruby-pg to fail to build (as did 9.5.1), and I'm building qt-4 locally to see if that works out
<lfam>rain1: Yay! In virtualbox, QEMU, bare metal?
<rain1>virtualbox
<rain1>this was just practice for metal
<rain1>now shall i try metal today or tommorow..
<lfam>Cool. Keep us posted :)
<rain1>I'm making notes on this and I hope that it can be put into the documentation
<rain1>also i have to manually create a new grub menuentry, but in future I think guix should create it?
<lfam>Indeed, we want our documentation to be 100% sufficient to do something like this. Recently, some other users have been working on the installation section of the manual, and I think they are addressing encrypted disks. You might look in the guix-devel archives of the last month or so.
<rain1>alright!
<paroneayea>I'm using an encrypted setup
<paroneayea>and it was not easy to figure out
<paroneayea>I had to read old removed commits... :)
<paroneayea>it's easy once you have it but it was unclear to me
<paroneayea>but it was mostly unclear because I shared my encrypted /home/ with my debian install, too
<lfam>rain1: One thing to note about GRUB and GuixSD: You can always rollback your system if you break, *unless* you break GRUB. GRUB is the heart of the rollback mechanism, so be careful with it.
<lfam>paroneayea: I wonder, should the old code stay in as comments? Or are we moving forward to not require such archaeology?
<paroneayea>lfam: we should probably just fix the text...
<lfam>Okay, I figure other people are working on that :)
<paroneayea>ACTION figures it too, to conveniently avoid adding one more task to his list... ;)
<lfam>Dangerous mode of thought ;)
***kelsoo1 is now known as kelsoo
<paroneayea>indeed
<paroneayea>also dangerous to stack your list so high you can never reach the top though
<lfam>Yes, petter's draft includes the section "Booting a fully encrypted system". Okay.
<lfam>The mailing list might be stacked that high ;)
<lfam>Did I mention I'm excited to have a declarative system to use MediaGoblin?
<paroneayea>lfam: \\o/
<paroneayea>lfam: me too ;)
<rain1>i will look over petters draft and see if i have anything to add
<lfam>rain1: Thanks!
<paroneayea>ok, whew!
<paroneayea>I think I figured out the python2-variant edition
<paroneayea>lfam: want to quick review before I push?
<paroneayea>it's otherwise the same thing you and davexunit approved on list
<lfam>paroneayea: Sure, can you send it to the list? That's the easiest way for me to test patches.
<paroneayea>lfam: will do
<lfam>cbaines, a_e: Can you summarize the reason for removing (guix build utils) from version-control.scm? Will the other packages in that module continue to build successfully?
<a_e>There is a variable "which" in there that clashes with one from gnu/packages. "make" passes. I think that is enough, even though the module is used in some of the build recipes.
***MatthewAllan93 is now known as MatthewAllan42
<paroneayea>lfam: sent to the list!
<paroneayea>lfam: could you ping me on irc if you respond shortly?
<lfam>Yes, I will
<paroneayea>\\o/
<paroneayea>lfam: the packages seem to work, I tried them.
<paroneayea>now that I'm more comfortable with `guix environment --ad-hoc` I'm cluttering up my profile a lot less
<paroneayea>(thanks again davexunit :))
<lfam>Yeah, it's a lifesaver
<lfam>paroneayea: My (limited) understanding of the new system is that you must call 'package-with-python2', and 'strip-python2-variant'. Right now, python2-wtforms never realizes it is a python-2 package and it's actually using python-3
<lfam>I checked that by digging around in the store directory.
<davexunit>anyone familiar enough with GNOME to make this Python import expression work? from gi.repository import Notify
<davexunit>just having our pygobject package isn't enough, it seems
<daviid>davexunit: is there a pylibnotify somwwhere maybe?
<davexunit>daviid: is that a real library?
<davexunit>perhaps this is the issue
<daviid>yes libnotify
<daviid>here [debian]: libnotify-dev
<daviid>and I have python-notify installed as well
<daviid>python-notify 0.1.1-4 amd64 Python bindings for libnotify
<daviid>OT: i need t upload my local app git server content to savannah, I'd like to confirm with some git pro here that the follwing is the way to do it: [from stackoverflow] git remote add origin http://git.savannah.gnu.org/cgit/foliot.git; git push -u origin master [ then repeat the same for other branches ]: is this correct ?
<davexunit>daviid: thanks, I'll look into this.
<daviid>davexunit: welcome. for info somone wrote a basic dyn ffi binding for it in guile
<daviid>I did ask on #git, but nobody answered? bizare
<paroneayea>lfam: ohhhh I see.
<lfam>daviid: I don't think you can push to the HTTP URI. I'm pretty sure you can only push to the SSH URI, and you have to have uploaded an SSH key to Savannah.
<lfam>And of course that key must be approved by the project admin.
<lfam>Or perhaps they approve your user account. I'm not sure.
<daviid>lfam: ah! so rather: git remote add origin daviid@git.sv.gnu.org:/srv/git/foliot.git
<daviid>then: git push -u origin master
<daviid>that should work, I have accout ssh key(s) uploaded at savannah of course
<daviid>lfam: thanks! but the way to upload is this way right? then repeat for other branch ...
<daviid>I'd be ashamed to do somehting wrong or incomplete then have to ask the savannah hackers to correct my mistake, hence my quizz...
<daviid>lfam: Iam the admin! ah I found a link which explains this: http://savannah.gnu.org/maintenance/UsingGit/
<daviid>cool!
<daviid>thanks
<lfam>Good luck!
<paroneayea>lfam: sent a new patch, thanks