IRC channel logs

2015-08-19.log

back to list of logs

<davexunit>oof, webkitgtk, texlive-bin, and qt depend on ruby.
<davexunit>I was going to push a patch version update.
<davexunit>it has a fix for this CVE: http://blog.rubygems.org/2015/05/14/CVE-2015-3900.html
<sbidin>what actually happens when guix is "downloading a list of substitutes from hydra"? it usually takes quite some time, but I had assumed it's mostly just simple package metadata and hashes and the like
<davexunit>something like that
<davexunit>it's slow because hydra is underprovisioned for the traffic it receives
<sbidin>ah, I see
<davexunit>we need more powerful hardware to host the hydra frontend, but getting it is difficult.
<Steap>ie, costful
<davexunit>it's expensive *and* it's hard to find a motherboard that supports a free BIOS replacement
<Steap>oh right, you're asking for a lot
<davexunit>but I believe mark is aware of something that can work with libreboot
<davexunit>basically, intel hardware is out of the question.
<Steap>does it not work well with libreboot ?
<davexunit>malware
<Steap>oh ?
<davexunit>stuff like "Active Management Technology"
<Steap>damn, I knew only about the rigged random number generator
<davexunit>intel motherboards have chips that run a separate OS that can be used to remotely monitor the system
<davexunit>and are nearly impossible to disable
<davexunit>the machine refuses to boot if you tinker with it.
<Steap>so basically, INtel is crap
<Steap>AMD is crap
<Steap>so x86 should be avoided ? :p
<davexunit>I don't think AMDs chips have such terrible anti-features, but I don't actually know.
<Steap>I think their IGPs require non-free firmwares
<davexunit>but yeah, modern x86 isn't looking too good
<Steap>is there anything "mainstream" that looks good ?
<davexunit>hell, my thinkpad x220 which would be considered old by some people has AMT
<davexunit>not that I know of.
<davexunit>it's all built to spy.
<Steap>I mean, apart from the crazy hardware RMS buys
<davexunit>a thinkpad x200 isn't exacly crazy hardware
<Steap>doesn't he have a MIPS laptop ?
<davexunit>it's an easily acquired laptop
<davexunit>he used to
<Steap>oh I see
<davexunit>then he got a thinkpad x60 when libreboot became available
<Steap>and a thinkpad isn't bad ?
<davexunit>modified thinkpads
<davexunit>not thinkpads as received from lenovo
<davexunit>and only specific models
<Steap>yeah, that is quite a pain then
<xentrac>someone stole his MIPS laptop when last time was here in Buenos Aires giving a talk
<Steap>hahaha
<Steap>poor guy
<davexunit>but the x200 is really not a bad laptop.
<davexunit>it's leaps and bounds more modern than the previous options, and you buy one that has been liberated for you.
<davexunit>you can buy*
<Steap>yeah
<Steap>if you don't really care about performance
<davexunit>it performs quite well.
<Steap>well
<Steap>I used to have a Core 2 Duo
<Steap>and less than 4GB of RAM
<Steap>I'm not sure it would be painless to go back to that
<Steap>but well, on the other hand, it is free
<xentrac>I'm using an Atom with 2GB now
<xentrac>it ended my friendship with Skud when I tried to use it to remotely pair with him (her at the time IIRC)
<davexunit>I use an x220 with a hacked proprietary BIOS that allowed me to replace the intel wireless chip with an atheros one.
<xentrac>at the end of our timeslot I was still trying to get the dependencies compiled
<Steap>davexunit: oh I love the "you cannot replace your card" part
<Steap>the whole point of the PC was to be able to replace parts
<Steap>now you can't do it in your laptop
<Steap>that is genius
<davexunit>yeah it's wonderful
<davexunit>how far we've come
<Steap>it defeats the purpose
<davexunit>now things are being made super slim and tons of stuff is soldered to the board
<davexunit>so you have to be an electronics engineer to replace even more things
<Steap>yeah
<Steap>but at least, it sort of makes sense
<Steap>"it is so damn slim we had to solder it to board"
<Steap>but not being able to replace you wifi card...
<Steap>someone actually had to write a piece of code in the bios
<davexunit>yeah
<Steap>that checks whether the "right" card is there
<davexunit>but both things move more to the computer being an appliance that gets used and thrown away
<Steap>that is broken by design
<davexunit>"consumers" want devices so thin that there's no room for customization
<Steap>well, makes sense for Apple users
<Steap>davexunit: I don't know
<Steap>for laptops, being thin and easy to carry around is a nice feature
<Steap>still people who don't know anything about computers are usually happy when you tell them they can replace a part for $50 instead of buying a new PC
<davexunit>I gladly accept a small amount of bulk for being able to dismantle and replace parts more easily.
<xentrac>I do sometimes, but not other times
<davexunit>I consider my x220 to be super portable
<davexunit>12.5" form factor is nice
<davexunit>I just wish I could put a higher resolution display on it
<xentrac>this netbook is 10"
<xentrac>but it's not nearly as portable as my Android, which I can use standing up on the train
<davexunit>well sure, it's not a phone.
<davexunit>but those are very different use-cases
<davexunit>a phone is convenient on the train, but you can't really do "real work" on it.
<xentrac>that sounds like a problem to solve
<sbidin>I wish 'guix package' behaved outwardly more like a regular package manager. "Here's how much room that package and its dependencies will take."
<sbidin>And not output each file it links, it's very noisy.
<sbidin>Possibly prompt for continue before installing?
<sbidin>If useful info is shown upfront.
<sbidin>Though I do understand it's not as dangerous as a regular package manager, so there's not as big of a need for stuff like that.
<sbidin>Basically, it feels as if there's a --verbose active by default. :)
<davexunit>prompts don't help anything. I really dislike interactive processes for stuff like this.
<sbidin>There's also a silly bug when downloading a package from hydra: the individual lines are so long that they wrap, and the updating percentage ticker then forces the output of a new line for each update.
<sbidin>davexunit: I'd appreciate a prompt in cases where installing a package would pull a large amount of dependencies I don't want. But ATM I have to check on that myself, before installing.
<davexunit>you can ask for a "dry run" with the -n flag
<davexunit>and I agree that we should display some statistics about the disk space it will use
<davexunit>I'm not sure if we know that at that stage
<davexunit>but maybe
<sbidin>Oh, didn't know about the dry run, will try it out.
<sbidin>About the wrapping "bug": do you also experience it or is it just me?
<sbidin>It could be fixed by using two lines for each download.
<sbidin>(one for the name, the other for the ticker)
<davexunit>I've been it on someone else's computer
<davexunit>but not my own
<sbidin>Possibly it's rxvt specific..
<davexunit>sbidin: could you write to bug-guix about it?
<sbidin>Sure, I'll do so.
<davexunit>thanks
<davexunit>mark_weaver: ruby 2.2.3 was released today, which includes a fix for a CVE. however, texlive-bin, qt, and webkitgtk have ruby as an input so I'm hesitant to push an update and cause a lot of rebuilding
<davexunit> https://www.ruby-lang.org/en/news/2015/08/18/ruby-2-2-3-released/
<davexunit>what's the best way to proceed?
<mark_weaver>sneek: later tell davexunit: Thanks for letting me know about the ruby update. I created a 'security-updates' branch and jobset to rebuild after 4 security updates, including ruby.
<sneek>Will do.
<mark_weaver>sneek: botsnack
<sneek>:)
<marcus>hi. i tried to add the icecat package to the system configuration. i just added it to the block (packages (cons* xfce ratpoison ;desktop environments ...
<marcus>when i try to reconfigure it, i got an error like unbound variable : icecat
<alezost>marcus: it is placed in (gnu packages gnuzilla) module, so you need to use it.
<alezost>But actually there is no need to install everything globally, you just can install the programs you need in your profile
<alezost>the only program I have in my system packages is iproute2
<marcus>and have you created a scm file for your personal packages?
<marcus>as i want to make the system reproducible
<alezost>marcus: yes, you can make a scm file with your manifest (a set of your packages) and use it later with 'guix package --manifest' command. See (info "(guix) Invoking guix package")
<marcus>and how do i figure out that a package is not installable by its name but like gnu packages gnuzilla?
<alezost>marcus: it's not about "a package is not installable": some guile variable is defined in a particular module, so to use this variable you need to export it from that module.
<alezost>that's why you probably use 'use-package-modules' in your system config
<alezost>so "icecat" variable (which contains a package definition) is defined in (gnu packages gnuzilla) module, so you need to use it
<marcus>ok, so how can i figure out that the variable is defined in that module?
<alezost>marcus: there are several options. For example, you can "guix edit icecat" and look where it is placed
<marcus>ah, great
<marcus>i have now reconfigured the system using the same configuration and wondered why a lot of packages seems to be re-installed
<marcus>is that always the case on a reconfigure?
<alezost>I think it's because after your last reconfiguring some packages were updated, so all other packages that depend on those were rebuilt
<alezost>(another reason to avoid putting all packages into a system config)
<marcus>ok, good to know
<marcus>so what is the suggested way to keep the core system up2date? running guix package --upgrade as root does not seem to be the way to go either?
<alezost>the only way to update the system is "guix system reconfigure"
<alezost>(with "guix pull" before that)
<marcus>ok, i thought so ;)
<marcus>is it suggested to run guix pull regularly? even on a normal package install?
<alezost>yes, if you didn't do "guix pull" before installing a package, you may get an outdated package.
<alezost>However "guix pull" takes some time, so I don't use it. Instead I made "~/.config/guix/latest" to be a symlink to my guix git repo dir.
<marcus>ok. that may also be the case why guix edit gives me an error execlp no such file or directory?
<alezost>All "guix pull" does is: it downloads the guix repo to some /gnu/store dir, compiles all the scheme files and made "~/.config/guix/latest" a symlink to it
<marcus>so you compile the schema manually?
<alezost>marcus: not manually, I do "make" in my guix dir regularly
<alezost>marcus: not sure about "guix edit", might be
<marcus>ok, thanks for the hint. i am going to check them out now ;)
<alezost>marcus: or maybe it just can't open an EDITOR
<alezost>IIRC "guix edit" tries to open $EDITOR, check this var
<remi`bd>hum; when I install Guix from source, its configurations goes in /usr/etc, which is strange
<remi`bd>(--prefix /usr)
<alezost>marcus: yes, it tries to use this EDITOR env variable, so you probably have some "my-favourite-editor" value which cannot be started
<remi`bd>how do one generate the signing keys needed to call `guix publish`?
<marcus>alezost, yes, this funny thing is called vim. still working on the emacs tutorial ;)
<alezost>we have "vim" package, so you can install it
<alezost>remi`bd: what files go to /usr/etc? "guix-daemon.service" and bash completions?
<remi`bd>and acl
<remi`bd>I do not have guix-daemon.service :o
<remi`bd>(well, it’s in the source, but not installed anym
<remi`bd>*anywhere)
<alezost>that doesn't sound right, could you report at <bug-guix@gnu.org> please?
<remi`bd>well, it’s most probably an error from my side
<remi`bd>this is how I installed guix this morning: http://paste.awesom.eu/remi%60bd/XgQL
<alezost>I don't really know, may be those files should be installed in PREFIX/etc by default. There is --sysconfdir option, perhaps it will help
<alezost>our "guix" package is also compiled with "--sysconfdir=/etc"
<alezost>and "--with-bash-completion-dir="
<marcus>wow compiling the catalogue on my T60 single core really takes long.
<marcus>how can i determine if a package is already installed?
<davexunit>marcus: guix package --list-installed
<sneek>Welcome back davexunit, you have 1 message.
<sneek>davexunit, mark_weaver says: Thanks for letting me know about the ruby update. I created a 'security-updates' branch and jobset to rebuild after 4 security updates, including ruby.
<davexunit>mark_weaver: thanks!
<marcus>davexunit, but this does only affect packages installed in the user context? is there a way to list all packages, even those installed system-wide?
<davexunit>you must query about that profile instead
<marcus>sorry, how can i do that?
<davexunit>guix package --list-installed --profile=/run/current-system/profile
<marcus>great, thanks
<marcus>and as a systems administrator is there a way to force upgrade of all packages in all profiles on a system?
<davexunit>it's possible
<davexunit>but there's no tool to do it automagically
<davexunit>as root, you have the ability to change anyone's profile
<davexunit>something like: guix package --profile=/home/marcus/.guix-profile --upgrade
<marcus>ok, that should work for me ;)
<rekado_>marcus: do note, though, that Guix is designed with user freedom in mind. While it is possible to force updates onto other users it's not in the spirit of letting users have control over their profiles.
<marcus>rekado-, yes that's clear
<marcus>is it true that by default everything gets compiled from source?
<davexunit>marcus: if you don't authorize a server to provide substitutes, yes.
<davexunit>guix is a source and binary based distro.
<marcus>ok, thanks. i have a synaptics touchpad in my t60. i have already installed xf86-input-synaptics - but when I try to run synclient I got an error like: the module is not loaded. how can i make it load correctly?
<davexunit>that I have no idea.
<rekado_>what module is not loaded?
<rekado_>"module" as in "kernel module"?
<marcus>it isn't that specific. i guess its an xorg module.
<marcus>found this one https://lists.gnu.org/archive/html/guix-devel/2015-05/msg00395.html
<marcus>when i list all packages within an environment, packages like xorg-server are not displayed. why is that?
<davexunit>marcus: I don't follow. can you explain more?
<marcus>i have installed a desktop system with xorg and xfce
<marcus>and xorg starts correctly. but when i do a guix package --list-installed --profile=/run/current-system/profile no x related packages are listed
<marcus>do they perhaps come out of the Desktop Services?
<davexunit>yes.
<davexunit>not every piece of software is associated with a profile
<davexunit>services often refer directly to the store items that they need to do their job
<marcus>and is there a way to display those packages as well? as i might now have installed packages that have already been pulled on the system that way (eg libinput driver)
<davexunit>you can look at the generated dmd services and see the store item paths
<marcus>hmm, so unless one writes the profiles on it's own, this might get a little confusing.
<davexunit>you can inspect the derivations of the system to see all of the references, they just aren't in a profile.
<marcus>so you mean i have to read the profiles to see what they provide?
<remi`bd>hum… sometimes, `query-path-info' can’t find the derivation associated with a store path; is it normal?
<remi`bd>well, it’s not right
<remi`bd>or is it?
<remi`bd>ok, let me reword that
<remi`bd>sometimes, the pathinfo returned by query-path-info on a store-path includes a non-existant derivation
<remi`bd>(depends on the choosen store-path)
<davexunit>I think that's OK
<davexunit>ludovic would know the specific technical reason
<remi`bd>is there a way to regenerate the matching derivation?
<davexunit>if there's a package definition for it in the system
<davexunit>the package->derivation procedure does that
<yenda>do we have a task/bug tracker for guix ?
<davexunit>bug-guix@gnu.org
<yenda>that's a mailing list
<davexunit>it's the bug tracker
<davexunit>we handle bugs over email
<davexunit> http://debbugs.gnu.org/cgi/pkgreport.cgi?package=guix for a web view
<yenda>that's more like what I had in mind thanks
<yenda>I like this bugs over email system
<davexunit>yeah it has some nice advantages once you get used to it
<davexunit>I'm not very used to it, but it's cool
<remi`bd>well, having store-path with a nonexistent derivation file might be problematic for `guix publish` and, thus, for publishing a store item over GNUnet
<davexunit>I have noticed no such problems with 'guix publish'
<davexunit>can you write to guix-devel about this so ludo sees it?
<davexunit>he will have the proper explanation for whatever behavior you are seeing.
<remi`bd>yep
<remi`bd>thanks :D
<remi`bd>it is probably a problem in my installation
<remi`bd>anyway, `guix publish` doesn’s seem able to handle it
<mark_weaver>marcus: note that our installers now authorize binary substitutes by default, so if you don't want that you should edit /etc/guix/acl to be just "(acl)"
<martinkl_>hey. Is guix running on raspberry pi/arm? couldn't find much information so I assume it's mostly uncharted territory?
<davexunit>we have an arm port
<davexunit>armv7
<davexunit>raspberry pi uses armv6, afaik.
<mark_weaver>martinkl_: as davexunit says, the raspberry pi cannot run our arm port, which targets arv7 with NEON.
<mark_weaver>the beaglebone black should work, however.
<mark_weaver>we don't yet provide pre-built binaries for armhf, but we should be able to do so within a few weeks.
<martinkl_>mark_weaver, cool. Any particular place to get short updates?
<martinkl_>back in a bit
<bavier>mark_weaver: I looked at the hummingboard a bit more. It looks promising.
<dmarinoj>Does anyone know why 'guix-daemon --build-users-group=guixbuild' would take really long in Debian?
<bavier>dmarinoj: guix-daemon doesn't drop to the background
<bavier>dmarinoj: you'll need to send it their manually
<dmarinoj>What do you mean? I was following the instructions for the binary installation
<bavier>dmarinoj: I might be confused by what you mean by "why [guix-daemon] would take really long"
<dmarinoj>It has been running for hours, do I need to stop it or do I just leave it running?
<mark_weaver>dmarinoj: you leave it running. if you use systemd, you might be interested in the systemd service file that was contributed to us. it's in the etc directory of our source tree.
<dmarinoj>mark_weaver: Okay cool, thanks
<sbidin>I've had xmonad working before, but now slim yells "failed to execute login command" at me. I have no idea what I did wrong. Is there a log somewhere that's more detailed than /var/log/slim.log?
<sbidin>I use a simple .xsession containing only the shebang and "exec xmonad".
<sbidin>It also seems that xmonad's binary gets created fine.
<sbidin>Which would mean that xmonad *does* get called after I log in via slim.
<mark_weaver>sbidin: did you chmod +x .xsession ?
<sbidin>Yes.
<mark_weaver>cat you show me your .xsession file?
<mark_weaver>*can
<sbidin>#!/usr/bin/env bash
<sbidin>exec xmonad
<sbidin>I linked env myself.
<mark_weaver>there's no /usr/bin/env in GuixSD
<mark_weaver>oh
<sbidin>Note that this exact .xsession worked in the past for me, with xmonad.
<sbidin>Here's some changes I made in the meantime:
<sbidin>I deleted all of root's packages.
<sbidin>(I'm not logging in as root.)
<mark_weaver>can you verify that /usr/bin/env still works?
<mark_weaver>also, it depends on the environment variable settings
<mark_weaver>at the time that this is launched
<mark_weaver>better to put #!/bin/sh there
<sbidin>env still works, running .xsession complains that xmonad cannot open a display
<sbidin>ah, good idea, I'll do that
<sbidin>What I most wish for is some kind of log. "Failed to execute login command" is too vague.
<sbidin>Xorg seems to have run fine...
<mark_weaver>why don't you use strace to attach to slim, making sure to pass -f, and see what happens
<sbidin>I'll do that
<sbidin>hmm, it seems hydra is down for me. "server is somewhat slow".
<sbidin>I'll take a short break. Thanks for the help!
<sbidin>(i need to install strace :))
<mark_weaver>pass --no-substitutes
<mark_weaver>strace is not a big compilation job
<mark_weaver>ACTION works on getting hydra more usable
<mark_weaver>there's a space leak in postgres, and the process bloats up to use ridiculous amounts of memory. restarting everything now...
<davexunit>is this running the latest postgres release?
<mark_weaver>no
<mark_weaver>when I tried to upgrade it, everything broke and I spent a few hours manually rolling everything back. I really wished hydra was running guix that night.
<davexunit>oh jeeze :(
<sbidin>mark_weaver: strace might not be, but I came back and guix was compiling bash :D
<davexunit>so let's worry about the upgrade when we move hydra to guixsd
<mark_weaver>right
<sbidin>it's still at it.
<mark_weaver>sbidin: compiling bash???
<sbidin>I have no idea why.
<mark_weaver>abort
<sbidin>ok, hydra is back online, got a strace substitute
<sbidin>
<mark_weaver>sounds like the 'guix' you were running to build strace is a very different version than the one you've already got your system running on. one or the other is probably old.
<sbidin>ah, yeah, that's probably it (again)
<mark_weaver>what is ~/.config/guix/latest and what is ~root/.config/guix/latest ?
<sbidin>They're the same.
<sbidin>Pointing to somewhere in /gnu/store.
<mark_weaver>are they pointing to a git checkout, or have you run "guix pull" ?
<sbidin>I have my own git cloned version, but it's not used as latest.
<sbidin>So it's a result of guix pull.
<mark_weaver>fwiw, I have both of those 'latest' links pointing to my git checkout.
<mark_weaver>and then I never run 'guix pull'. instead I "git pull && make"
<sbidin>Yes, I've tried that, but then I deleted libgcrypt and that guix refused to run. So, just to avoid headaches in the short-term, I reverted back.
<sbidin>Using the git clone directly is on my todo list. :)
***ecbrown- is now known as ecbrown
<sbidin>mark_weaver: Thank you for the strace tip. It turns out it was, (drumroll), all my fault. And the problem was completely unrelated to guix or guixsd in any way.
<codemac>does anyone here run bitlbee from guix? It's looking for lots of libraries that it can't find - libotr, libglib, etc
<codemac>I tried to rebuild it with --no-substitutes, but that lead to rebuilding the world so i C-c'd that.
<taylanub>codemac: I'm running a guix-installed bitlbee on Debian
<taylanub>don't remember having a problem like you mention. maybe your configuration specifies that some non-default features should be enabled, which require said libraries? (I have a minimal config.)
<codemac> https://ptpb.pw/4evD
<codemac>bitlbee literally just exits. I haven't even edited my config? maybe you're right though
<codemac>in that case it exits because it can't find libotr
<taylanub>codemac: hmm, just checking: did you ever manually mess with the contents of /gnu/store?
<codemac>no, never.
<taylanub>could it be some filesystem problems? do the /gnu/store directories it tries to access (e.g. the one of libotr) actually exist?
<codemac>and libotr.so exists, but if you look at the last search path there in strace, it's looking in libotr-4.1.0/tls/x86_64/libotr.so.5
<codemac>whereas I can find libotr.so.5: /gnu/store/l2qg8jc5kbz81xmdh02waavn8a5mdndi-libotr-4.1.0/lib/libotr.so.5
<codemac>But you see the library path that bitlbee is checking is odd and doesn't include all possibilities.
<codemac>like - why does it try /tls/libpoop.so for everything before trying /lib/libpoop.so?
<taylanub>ACTION is out of ideas, and doesn't fully understand .so-searching logic
<bavier>codemac: is the dynamic linker looking for those libraries, or does bitlbee dlopen them?