IRC channel logs

<civodul>normally "gnunet-arm -s" is all it takes

<civodul>good night/day!

<lfam>What is the best way to tell this software (sent) where to find the freetype headers? http://git.suckless.org/sent/tree/config.mk

<lfam>Currently I am using a #:make-flags to append to $INCS

<lfam>But I'm wondering if there is a more portable way to write that config.mk that I could try to get upstream

<cehteh>lfam: do they depend on gnu make or any other/portable make

<cehteh>plain posix make is quite powerless :/

<lfam>cehteh: I don't know if they care which make is used. I'm building it with Guix's gnu-build-system.

<lfam>It would be good if the website's package list had an anchor link for each package name

<lfam>Are there any standard practices for creating a version-number for sources fetched from a git repo with no tags / releases? I see some packages in gnu/packages that use (string-append "0.0-" commit) and some that just use the commit.

<lfam>Rather, "0.0."

<mark_weaver>lfam: we don't have a standard practice yet, but given that "guix package -u" depends on being able to compare version numbers, I would suggest YYYY.MM.DD.<commit-id>

<mark_weaver>or something along those lines

<mark_weaver>I suppose if it is expected that the project will some day have versioned releases, maybe putting a "0." or "0.0." in front would be reasonable

<lfam>mark_weaver: That's good to know. What about making "git package -u" access the git DAG's logical history?

<lfam>Using timestamps is fine for now, but it would be nice to eventually make the guix tools use the canonical history from the source.

<mark_weaver>lfam: the git repo is not normally available, and cloning all the git repos and searching their history for commit ids would be prohibitively expensive.

<mark_weaver>multiply that process by the number of packages in the profile, which for me is about 150.

<mark_weaver>also, a human should be able to look at two version numbers and see which one is newer, IMO.

<lfam>mark_weaver: The manual says that using (git-fetch) clones the repo and checks out the commit specified in the package definition. Does the daemon not cache these repos like it does with source tarballs? As for the expense, I don't know one way or the other.

<lfam>The human readability is important.

<lfam>I see that the memoized git-checkout is just the data files, none of the git metadata.

<mark_weaver>origins using the 'git-fetch' method does clone the repo, but the .git directory is removed before adding it to the store

<mark_weaver>and it has to be that way, because otherwise the result of those source derivations would not be deterministic.

<lfam>Yeah, I remember a discussion on that subject.

<fps>lfam: i fetched a particular commit zip. that gets stored just fine..

<fps>lfam: only applicable to github or similar though

<Digit>dear fellow guix(SD) Xmonad users, what's the trick to getting xmonad "--recompile"d with contrib extensions in GuixSD? :/ http://dpaste.com/3MGPVF8 http://dpaste.com/2FE2X5V ~ vanilla xmonad is nice, but i'd prefer my config.

<fps>Digit: sorry, no idea. i just use xmonad with a different terminal and that's it :)

<Digit>thnx for the responce anyway. :)

<Digit>ACTION continues searching

<civodul>Hello Guix!

<Digit>morning civodul

<efraim>hi!

<lfam>fps: I meant that the .git directory with all of the repo metadata does not get stored

<Digit>"patching the XMonad source may be the only way" (from a nixos log). is there a fundamental difficulty in getting xmonad reconfigured past guix/nix package imutableness that means i need to create a guix package every time i want to change my xmonad configuration? ...or some simpler issue that will mean some day reconfiguring xmonad will be as simple as issuing "xmonad --recompile" ?

<civodul>Digit: i don't know the answer, but i think issues with xmonad configuration were discussed on the ML a few weeks ago

<Digit>yeah, just starting to read some of those from around october time. :)

<efraim>python2-zope-security failed to build on hydra, I have the fix locally, just waiting for my current builds to finish before I can test it

<taylan>civodul: working on the auto-compile solution at the moment. problem: how do I induce the auto-compilation without 'load'ing the files? (when I do that it means we still have the same problem of evaluating the top-level of many files twice.)

<lfam>efraim: It looks like the dependently built zope-testrunner can't find its own dependencies. It seems like another python-3 to python-2 translation error. Is that what you found?

<efraim>yeah

<efraim>have to manually specify python2-zope-testrunner

<lfam>I don't understand why it builds for me and not on hydra

<civodul>taylan: i would just enable auto-compilation, then call 'compile-file' in a loop

<civodul>that should induce auto-compilation

<taylan>oh I see

<Munksgaard>Hi guys! Is it possible to boot the USB image using Virtualbox or is there another image I should use?

<Munksgaard>Found this https://gitlab.com/ecelis-guix/hackathon/blob/master/INSTALL.VirtualBox, guess I'll give it a try.

<Lillo>hi

<Lillo>how can i run guixsd on qemu?

<Lillo>(if i can)

<Lillo>...

<taylan>Lillo: there should be something in the manual about making Qemu VM images

<taylan>this is a low-traffic IRC channel :)

<Lillo>there is nothing abot virtualization

<taylan> http://www.gnu.org/software/guix/manual/html_node/Invoking-guix-system.html#Invoking-guix-system

<Lillo>thanks

<Lillo>jq

<Digit>ACTION almost tried a kludge partial-remedy of ~/.guix-profile/lib$ ln -s ghc-7.10.2 ghc-7.8.4 before deciding that's silly, wont work, makes a mess, n instead he should just wait for better minds to tackle the xmonad issue

<fps>hmm, it would be nice if one could make "sudo guix pull; guix pull" an atomic operation

<fps>right now i have to maintain three guix'es to keep everything up to date

<fps>root's to reconfigure my system, my user's to get packages and my git clone to hack on things

<fps>maybe i'm just doing it wrong (tm) though

<fps>sneek: ask lfam later: ok, nvm the noise then :)

<fps>oops

<fps>sneek: later ask lfam: ok, nvm the noise then :)

<sneek>Okay.

<fps>sneek: botsnack

<sneek>:)

<fps>and why is "make" in the guix git clone about one million times faster than "guix pull"? :)

<taylan>fps: it's the same the first time you run make in the repo. later, it reuses the state of already compiled files in the repo. guix pull is as if you run "make clean" first every time.

<fps>taylan: oh ok. got ya

<fps>ty

<davexunit>package-with-python2 is going to become unusable soon enough

<davexunit>it needs fixin'

<Steap>why is that ?

<davexunit>as soon as one package in the graph isn't compatible with package-with-python2, you can't use it.

<davexunit>and we have a growing number of those.

<davexunit>efraim just fixed an issue with python2-zope-security related to this

<efraim>more manual python2- definitions

<davexunit>that issue propagates itself

<davexunit>python2-zope-testrunner needed a manual definition, so now python2-zope-security must as well.

<davexunit>and anything that uses python2-zope-security will in turn need it

<efraim>It looks like python-mock might've been incorporated into python itself in 3.2 or so, we have lots of packages that use python-mock

<davexunit>I don't know how to fix this problem.

<efraim>actually, I'm pretty sure it doesn't go more than 1 generation

<davexunit>that's not what I've observed, but it would be good to be wrong

<Steap>efraim: yeah, mock is part of the stdlib nowadays

<Steap>Maybe we could remove Python 2.

<davexunit>no. a good amount of software still needs it.

<efraim>what about packages that haven't migrated yet

<Steap>yeah :(

<Steap>This is a shame

<davexunit>even so, for developers, I think it is important that we provide a way to recursively replace python versions throughout an entire dependency graph

<davexunit>I plan to do this with ruby

<efraim>I'm convinced the key is in package-with-explicit-python in guix/build-system/python.scm

<davexunit>ah, so we already have it

<efraim>its part of the package-with-python2 magic

<Steap>yeah I was just joking

<Steap>though I'd love to get rid of Python 3

<Steap>s/3/2/

<efraim>ok I think if I copy the logic from renaming the name field of the package and use that instead of recursively calling transform, it might work

<efraim>python2-scikit-learn has 2 switches, I'll see if it works on that one, with guix graph

<efraim>whats the guile version of .tostring()?

<davexunit>efraim: object->string

<taylan>TIL

<taylan>was going to recommend (format #f "~s" obj) (or same with ~a)

<efraim>davexunit: thanks

<efraim>now the graph looks crazy with the specified changes in package-with-python2

<efraim>well, i might be on the right track, but what i've done doesn't work yet

<rekado>FYI: I'm working on a gnunet-gtk package now.

<efraim>what about anonymiss?

<rekado>efraim: did they say they'd work on it?

<rekado>oh, I didn't see the email. Hmm.

<rekado>well, it seems pretty simple.

<rekado>it's already building right now...

<rekado>texlive still makes me sad.

<rekado>I want to test whether python2-matplotlib really needs numpy as a propagated input --- but I have to wait for texlive to be downloaded before I can test this.

<rekado>is anyone sitting on unfinished work to break up texlive into many little packages?

<cehteh>ACTION wonders if that really makes sense, yes its huge, but once you have it all it should just work and rarely gets updates

<cehteh>the only think i could imagine would be some texlife-lite for very small netbooks or so with just basic functionality, everyone else nowadays has prolly a few GB at spare to install the full thing

<rekado>we need to download it often, whenever an input changes.

<rekado>I've had to download it for about a dozen times on my machines since I started using it.

<rekado>and it usually doesn't succeed.

<rekado>I'd be okay with it if I just had to wait, but often the download is corrupt and has to be restarted.

<cehteh>huh

<rekado>on my workstation in the office I usually just build it rather than download the package.

<cehteh>then this downloading / restarting should be fixed .. partial transfers, restarts

<cehteh>does hydra offer rsyncd as download option?

<efraim>last time I timed it, ~20 minutes to build, 1:20 to download

<fps>hmmm, gparted would be nice to have :)

<fps>ugh, sourceforge downloads suck

<fps>oh, libuuid misses

<fps>hmm

<davexunit>cehteh: can't be fixed until we have a new server

<davexunit>hydra is simply overloaded

<cehteh>should be time to make it distributed :D

<davexunit>that's also WIP

<davexunit>it's not as if we aren't aware of these things

<cehteh>at least the downloading .. imagine 1) round robin DNS to a few frontend squid proxy servers (hosted by the community) 2) this squids are configured in a hierarchy with a 2nd level of cachinng servers

<cehteh>well i know such things progress slowly

<cehteh>distributed builds would be another thing

<fps>ok, that was easy to package..

<fps>hmm, the library part from the parted package seems to be missing..

<fps>ah no, it's there.. hm hm

<cehteh> [==========>..........] reshape = 54.7% (2137274892/3901308928) finish=889.8min speed=33038K/sec

<cehteh> .. in some hours i have 4TB more to play with, then i'll starting again with guixsd in a vm :D

<fps> https://pastee.org/xd9ky

<fps>anyone see what the problem is straight away?

<fps>libparted not found

<fps>it does exist though in the store in the parted directory

<cehteh>does 'parted' install 'libparted' or how is that linked?

<fps>it seems to, yes..

<cehteh>then check the configure where it tries to pick it up .. pkgconfig? does parted install that?

<bavier>fps: the symbol is indeed in the library, so it's probably a configure issue

<fps> https://pastee.org/mq93s

<fps>parted's store contents

<fps>bavier: hmm, ok..

<fps>libparted is not found at all though (see the first pastee)

<fps>i'll check the pc file

<bavier>fps: it says it can't find the symbol, not that it can't find the library

<bavier>check configure.log from the build

<fps>bavier: i have the output before my eyes, but thanks for the hint for the log

<fps>i'll try and see if i can get parted to build from source again and check its output

<davexunit>this is a good time to start using 'guix environment'

<davexunit>if you keep doing failed build after failed build

<davexunit>I do something like this to build a sandbox to play in:

<davexunit>cd /tmp && tar xf $(guix build -S gparted) && cd gparted-XXX && guix environment --container gparted

<davexunit>I'd like to write a tool that does exactly this, but I don't know where to fit it.

<fps>maybe add an option to guix build to drop you in an environment shell with the source extracted?

<fps>and once you leave the shell the build is considered done

<davexunit>fps: adding it to 'guix build' seems like a good idea

<davexunit>thanks

<fps>np ;)

<fps>oooor, add an option to guix environment that does not consider it to be a build

<fps>hm hmm

<fps>guix environment --container --extract-source gparted

<fps>or somehting like that

<fps>what package contains "nm"?

<fps>oh, in the former case also check the exit value of the shel

<fps>l

<fps>to scrap the build exit 1

<fps>;)

<fps>man roads lead to rome

<fps>*many

<fps>my y key is on strike sometimes.. i hope my keys don't form a union

<efraim>apt-file isn't helping with nm

<fps>apt in general is pretty horrible

<fps>ACTION runs away

<bavier>fps: nm is in binutils: https://www.gnu.org/software/binutils/

<amz3>I get an lesspipe command not found when doing `guix environment guile'

<amz3> https://friendpaste.com/7D0cpNLNfLIcggBlOmoDeO

<davexunit>amz3: that's not a guix error

<davexunit>that's a problem with your bash config most likely

<amz3>ok thx

<fps>bavier: thanks

<fps>shouldn't guix environment clear out all user defined stuff? otherwise it's not really the build environment

<fps>aah, --pure might help :)

<davexunit>fps: --container as well

<fps>and yes, the library has the symbol

<fps>davexunit: :)

<davexunit>'guix environment' supports many levels of isolation

<fps>davexunit: i'll remember it at some point in time :)

<fps>repetition is key ;)

<davexunit>a lot of times I like to augment my existing env with some extra guix stuff, thus the default behavior.

<fps>davexunit: oh, that makes sense, true

<fps>davexunit: in a sense those are rather separate usecases though, no?

<fps>1] embelish the normal user's environment with stuff

<fps>2] recreate a build environment

<fps>might help to name them separately

<fps>or maybe i should just read more docs :)

<fps>hmm

<fps>fps@cherry ~$ nm /gnu/store/l9fwspd868rk2bnkqvp4wixz37fj8xxz-parted-3.2/lib/libparted.so | grep device_read

<fps>000000000000d930 T ped_device_read

<fps>but

<fps>checking for ped_device_read in -lparted... no

<fps>configure: error: *** libparted not found.

<fps>hm hm

<davexunit>fps: read more docs, the functionality is all basically the same

<davexunit>and the user can control the degree of isolation

<lfam>davexunit: Why do you think I was able to build the letsencrypt dependency graph but hydra could not? Is it because I already had all the zopes in my store from when I was building them individually during testing? Especially because there was a time when I used straight package-with-python2 for all of them, with any python-2 specific dependencies in the "main" python-3 recipe? (That was a stroke of laziness)

<sneek>lfam, you have 1 message.

<sneek>lfam, fps says: ok, nvm the noise then :)

<davexunit>lfam: I was able to build it, as well.

<davexunit>nondeterminism?

<lfam>I thought that the package recipe was included in the dependency graph of a package, so that if it changed, the package would have to be rebuilt. Is that correct?

<davexunit>yes

<davexunit>so everything is the same

<lfam>Okay, so that can't be it. Maybe the ordering of the build has some effect?

<davexunit>yet it failed on hydra

<davexunit>no

<davexunit>this happens on a regular basis

<davexunit>running the same build on a different machine can fail for a variety of reasons

<davexunit>this is the nondeterminism we fight against

<davexunit>I don't know the details of why it happened here

<lfam>But this seems different. For these python packages aren't we basically just unpacking them? Is there any real compilation happening?

<lfam>And based on some other packages like python-pyopenssl, we could have guessed this would happen. Although the whole situation may be a bug, in this particular case it seems like a bug that it succeeded on our machines at all

<davexunit>lfam: we aren't just unpacking them, there's a whole build system for python projects

<lfam>Okay, I don't really know the details of how python software is compiled.

<davexunit>there's more to build systems than compilation

<lfam>I ask these things because after Efraim's report, I tried and failed to build python2-zope-security locally. But I could still build letsencrypt. It seems like the memoization is breaking down.

<davexunit>there's no bug in memoization

<lfam>That's true about the build system. I guess I am just able to imagine a million sources of non-determinism in C compilation but not in Python builds, because I have more experience with the former.

<davexunit>if it's true that letsencrypt builds but python2-zope-security doesn't, it means that the python2-zope-security used in the letsencrypt dependency graph is different than the one bound to the variable python2-zope-security

<lfam>Why do you say that? I could not build the dependency based on the current recipe, but I had a cached output of that recipe that the system was willing to use. So I never actually built based on that recipe.

<lfam>That is in response to your previous message

<davexunit>lfam: if it was changed, then it would be rebuilt.

<davexunit>guix isn't just going to use a previous build unless the hash of the derivation is the same

<lfam>That's what I thought. So I guess I did somehow successfully build that recipe, but it doesn't work in isolation.

<davexunit>what do you mean "doesn't work in isolation"?

<lfam>I mean that if I `guix gc`, and then `guix build letsencrypt`, joy! If I `guix build python2-zope-security`, it fails. I shouldn't say things like "in isolation" without being more explicit. I just meant that it fails on its own but not when part of a larger dependency graph.

<lfam>And that `guix gc` should work because I never put letsencrypt in a profile with this machine's store.

<davexunit>lfam: that's incorrect

<lfam>That's what happened to me last night.

<davexunit>that means that the python2-zope-security used in the letsencrypt graph *MUST BE* different than the package bound to the python2-zope-security variable in (gnu packages python)

<davexunit>all builds happen in isolation

<davexunit>I don't have time to investigate why they are different, but they surely are. I suspect a package-with-python2 somewhere could be the culprit.

<lfam>Yes, something is up

<lfam>efraim: Thanks for catching it and fixing it!

<davexunit>to guix, these are 2 totally different packages.

<davexunit>despite having the same name and version

<davexunit>those are only a couple of the factors that determine the hash of a package build in the store

<lfam>Is "bag" and acronym like "dag"?

<lfam>an*

<davexunit>no

<davexunit>it's a funny term for an intermediate representation of a package

<lfam>big ass graph

<davexunit>hahaha

<lfam>Or, bag full of dependencies

<lfam>I'm reading package-with-python2

<davexunit>packages are "lowered" to bags, which are lowered to derivations

<davexunit>bags give one access to the implicit inputs added by a package's build system

<davexunit>folks with encrypted file systems: what file system type do you use to control that?

<lfam>Oh, does that work in GuixSD now?

<davexunit>lfam: not for the root partition yet

<lfam>'/home' is the most important

<fps>btw: where does the tree of the failed build built with -K live?

<lfam>By default in /tmp

<fps>aah, good :)

<fps>thanks

<lfam>I, like a heathen, put mine in ~/tmp rather than enlarge /tmp

<lfam>But I use ~/tmp pretty heavily

<fps>oh ok. configure was lying to me :)

<davexunit>the guix daemon will put those failed builds in your $TMPDIR

<fps>/gnu/store/l9fwspd868rk2bnkqvp4wixz37fj8xxz-parted-3.2/lib/libparted.so: undefined reference to `uuid_generate@UUID_1.0'

<fps>/gnu/store/ajdpjbyybmpga0v6m9bjf6i0xfwp7njs-util-linux-2.27/lib/libblkid.so.1: undefined reference to `uuid_unparse@UUID_1.0'

<fps>tsk tsk tsk

<fps>i think i know how to make gparted build then..

<fps>thanks again

<fps>hmm, intersting. how did guix survive without libuuid for all that time? :)

<davexunit>we have numerous missing packages

<lfam>We have libuuid. It's in util-linux IIRC

<lfam>fps^

<lfam>See the recutils package definition

<fps>lfam: that's where i just added it, since after libparted complaining about missing symbols, i added the libuuid input to linux-utils now

<fps>or maye i'm super dense and struck by blindness

<fps>checking recutils

<lfam>It should have already been in there. I have used it before.

<davexunit>fps: what lfam is saying is that libuuid is provided by the util-linux package

<davexunit>which is correct.

<fps>davexunit: ok

<davexunit>so yeah, no need for that separate libuuid package

<lfam>It tripped me up for a while back then. I think I figured it out with my trusty grep in gnu/packages

<fps>then the symbols somehow don't survive.. they were missing in some libblj-something or other..

<fps>hm hm

<fps>lfam: might be nice to have some package aliases :)

<fps>then i could have saved myself the trouble of packaging libuuid :)

<lfam>fps: Yeah, maybe :) Good practice, though?

<davexunit>you cannot assume that every single library will have its own package

<lfam>But it sounds like there is a problem with it

<fps>guix package -A uuid -> "Yes, good sir, libuuid is provided by linux-utils. Keep on packaging"

<fps>lfam: it might just be my ignorance again :)

<lfam>We could update the description for util-linux. I think that would be helpful and appropriate. Thoughts?

<mark_weaver>lfam: sounds reasonable

<davexunit>"... including libraries such as libmount, libuuid, etc."

<fps>hmmm, but there's a more general problem though which might need a more general solution, too

<fps>how to find out what package provides some file, short of building them all and doing a find /gnu/store? :)

<mark_weaver>"guix package -s" searches package descriptions

<mark_weaver>fps: I agree that it would be nice to have something like that, but we've not found a satisfactory solution.

<davexunit>fps: that's basically what you'd have to do

<davexunit>especially since the relationship between store items and packages is a one way street

<mark_weaver>hydra could produce such a list

<davexunit>that is, you can't see that a file is in a store item and find the guix package object.

<fps>yep

<efraim>so a guix version of apt-file?

<lfam>fps: Don't you have all the packages built locally? You are more able than the rest of us to `find` things ;)

<davexunit>the problem is that it encourages people to use a centralized system for this information

<mark_weaver>I don't see how to integrate it into 'guix' itself nicely, but we could perhaps have hydra produce such a list that would be available on the web somehow

<fps>lfam: it's on a vm on a server which i cannot use anymore right now :)(

<fps>:(

<lfam>Ah, too bad

<davexunit>building all packages is prohibitively expensive for a user to do by themselves

<lfam>fps did it!

<fps>yes, i did it

<lfam>I agree, it's insane for the rest of us without a super beefy server

<fps>almost at least. quite a frew failed :)

<davexunit>sure, but that can't be the answer to "which package has this file?"

<lfam>No, I'm just kidding around.

<davexunit>:)

<davexunit>introducing something that users couldn't reasonably do themselves doesn't make me feel very comfortable

<fps>one question though: hydra builds packages one by one, too, right?

<lfam>I think this problem doesn't crop up that often. At a certain point we have to learn about the software we want to package. There is a whole class of software that doesn't really have a clear provenance and we have to hunt for the source. For example, libuuid is provided by util-linux. But if you google it, the linux.die.net manpage points you to e2fsprogs

<fps>so for every built package you can remember the list of files produces

<davexunit>fps: introducing reliance upon hydra is not something that I want

<lfam>Or, try fakeroot. AFAICT, the "canonical" source for fakeroot is a Debian developer uploading it him- or herself

<fps>ok, agreed.

<fps>the solution again lives in decentralization :)

<fps>once i have gparted figured out i can finally put guixsd on my main machine..

<davexunit>why do you need gparted?

<lfam>I thought we had parted?

<davexunit>gparted is the graphical frontend

<fps>cause i like it.. i might try parted, too, though

<davexunit>I just use parted

<davexunit>simple enough interface

<davexunit>in fact, I've had way better luck using it than gparted

<fps>ok, getting gparted built is too deep for me anyways..

<fps> https://pastee.org/e48as

<fps>if someone else wants to try their luck..

<lfam>It would be good to have gparted, I think.

<fps>yeah, i had this idea in the back of my mind to produce a somewhat less minimal image in the end which people can use to install guixsd

<fps>like with xfce, gparted and a decent terminal :)

<fps>and a browser to read the docs etc..

<fps>oh and emacs ;)

<lfam>I want to print a list of package descriptions of everything that depends on util-linux. I know how to use recutils but I don't know how to make `guix package` print the dependencies. Anyone have a method for this?

<fps>lfam: repl :)

<lfam>I'm a heathen

<fps>lfam: or can you print the dependencies for each package recursively?

<fps>then iterate over the output of guix packake -A | cut -f1 and grep through each package's deps

<lfam>guix package -A doesn't print the deps

<fps>that's why i asked whether you had a way to print the deps

<lfam>I think I used to know how to do this...

<fps>didn't you figure out a way previously via some graph

<lfam>The graph command outputs in graphviz format, which isn't ideal. I just want to get a sense of what util-linux is commonly used for so that I can decide what to put in the description.

<fps>for n in `guix package -A | cut -f1`; do guix graph "$n" | grep util-linux; done

<fps>or something

<lfam>I think the output of guix graph is really not that good for this. It's only useful for piping into `dot`

<fps>true.. maybe a different output format for guix graph is needed

<efraim>gah. to update python-keystoneclient from 1.8.1 to 2.0.0 I have to add python-reno, which requires updating python-testtools, which requires packaging python-traceback2, and I've stopped there for now

<fps>i.e. guix-graph --recursive-inputs foobar

<fps>right now guix-graph just prints a dot format, but it could be envisioned as a more general graph querying utility for the package DAG

<efraim>guix refresh -l util-linux

<bavier>guix refresh -l prints just the leaf nodes of the dependents, but it could be tweaked a bit to print all packages

<lfam>In this case, `guix package -s` could just print the inputs as well. That would be useful. I'm doing ` vim $(grep -rI util-linux | cut -f1 -d: | uniq)`, since it takes me where I want to go

<fps>lfam: ooh, this maybe: guix package --show=parted outputs a line "dependencies"

<zacts>m

<lfam>Um... I'm blind

<lfam>Thanks

<lfam>`guix package -s "" | recsel -p name,synopsis -e 'dependencies ~ "util-linux"'`

<fps>ok, brb, installing to the iron :)

<davexunit>brb, installing to the toaster

<fps>n1 :)

<davexunit>I should put a computer running guixsd inside my toaster

<davexunit>so I can finally say "why yes, I *do* run GNU/Linux on my toaster"

<lfam>You should put a raspberry pi in your toaster and turn on the toaster ;)

<davexunit>I do have one of those that I'm not using...

<lfam>A delicious name for a flawed device

<lfam>Huh, I found an interesting package, 'libchop', among the referrers to util-linux. A backup program I've never heard of...

<davexunit>has guile bindings too :)

<lfam>I see a familiar name

<davexunit>yeah?

<davexunit>ludo?

<lfam>Yup!

<davexunit>cool :)

<lfam>I'll have to read all the stuff about it. I'm a sucker for backup programs

<lfam>So much work to be done in that area...

<fps>oh great, i screwed myself :)

<fps>fps@cherry ~$ sudo deco start cow-store /mnt/

<fps>No service provides cow-store.

<fps>Providing cow-store impossible.

<efraim>I have a hot-water kettle that I disconnected the heating element, and I was going to stick an arm board inside

<lfam>Trying to summarize util-linux is hard. It provides both `cal` and `ionice`. Not exactly a focused package...

<efraim>then when you turn it on the arm board turns on

<lfam>And then what? ;)

<fps>and then it'll blink in morse code: "no hot water, sucker, bwahahahaha"?

<efraim>I hadn't decided, but maybe a speaker

<efraim>of course it'll be bad when someone puts water in it

<lfam>You should make your own hardware watchdog that uses the kettle's button

<lfam>I feel like the watchdog is the most important feature of ARM SBCs

<efraim>my other idea was sticking one in a microwave and trying to replace the glass panel on the front with a screen

<lfam>Most of util-linux makes sense. But then it includes `cal`, `getopt`, and `hexdump`, which seem to be 100% userspace from my naive perspective.

<lfam>Also, `more`

<lfam>Alright, how about this patch on util-linux's description and synopsis? http://paste.lisp.org/+3K2S

<lfam>fps ^

<fps>lfam: so glad for having irssi run on a server :)

<fps>lfam: much better than before imho..

<lfam>It's hard to summarize the whole package without just listing the few dozen tools it provides

<lfam>I'll send it

<lfam>fps: What package module is that gparted paste from?

<lfam>So that I don't have to waste time adding all the imports

<fps>lfam: i put it into disk.scm

<fps>sadly the system i had it on is down right now ;)

<fps>part of me screwing up

<fps>i had to add import gtk glib and pkg-config

<fps>though not sure about pkg-config

<fps>worst time for hydra being slow ;)

<fps>updating hte list of substitutes takes ca. 30 minutes now and is at 28% :)

<lfam>civodul: Hello! Earlier today I read with interest the package definition of libchop.

<civodul>hey, lfam

<civodul>cool

<civodul>is it that interesting? :-)

<lfam>I'm a sucker for backups

<fps>hydra.gnu.org needs a backup ;

<fps>;)

<fps>7KiB/s right now :)

<fps>and i just replaced my main system's root fs with guixsd

<fps>this is gonna be along night

<civodul>yeah i was noticing that as well

<civodul>how's the fps.io build node doing? :-)

<fps>sadly i cannot continue using it for now :(

<civodul>ok

<fps>i'll have to rent my own box, which i planned for a while anyways..

<fps>so stupid. 4 big servers doing nothing but idling because "there might be work coming in -you can not haz the cycles" :)

<civodul>heh

<fps>oh well, it was fun while it lasted. i still have the image lying around though, if someone's interested ;)

<civodul>cool

<fps>civodul: oh btw: all the time i wondered about how to make the builds as allencompassing as possible

<fps>civodul: basically clone the git repo at 0.9.0 and then step ahead one commit at a time and rebuild everything?

<civodul>roughly, one can use the 'fold-packages' procedure, which iterates over all the packages

<civodul>and from there use package->derivation and such

<fps>hmm, maybe there's a misunderstanding

<fps>all kinds of different people might have different revisions of guix on their system looking for substitutes

<civodul>rebuild everything for each commit, right?

<fps>yes.

<civodul>ok, so for each commit you would iterate on all the packages defined at that commit

<fps>but dependent packages might have changed, too

<fps>is there really a shortcut to rebuild every package for each commit?

<fps>and let the dependency resolution and hashes figure out what needs rebuilding and what doesn't?

<civodul>you just call 'build-derivations' for each package derivation; if the result is already available, nothing is done; otherwise, it actually builds it

<fps>ah ok, i misunderstood "defined". i interpreted it as "had changed during that commit"

<fps>but got ya

<fps>so you're basically saying that the ole' bash way of iterating through the packages is inefficient

<fps>and one should do it scheme style..

<fps>but then one commit at a time for all package derivations

<davexunit>ugh, bad news. nodejs bundles OpenSSL

<davexunit>ugh

<lfam>Lol

<civodul>bah

<civodul>the nodejs we already have? or another version?

<davexunit>the one we already have

<davexunit>I'll have a fix at some point

<davexunit>there's a configure flag to use the system version

<davexunit>I also need to update us to the latest node

<davexunit>but that requires some more work

<davexunit>need to patch a /bin/sh somewhere

<davexunit>civodul: okay I fixed it. I'm just going to push it if you don't mind.

<davexunit>'guix gc --references' now contains the store paths for openssl, libuv, and zlib.

<civodul>davexunit: excellent, that was fast!

<davexunit>I'm trying to get a newer node to use at work and I noticed this.

<davexunit>luckily the configure script has easy flags to skip the bundling

<fps>does emacs have a way of taking a list of words, once word per line, and put them on less lines space separated, max. 80 columns long?

<davexunit>bundling openssl is so dangerous.

<codemac>fps: M-q ?

<fps>nice :) thanks

<fps> https://pastee.org/bjn4j

<fps>though that list is probably excessive ;)

<davexunit>you should actually put line breaks there

<davexunit>and use texinfo formatting

<davexunit>the list does look excessive :)

<fps>btw: can someone show me exemplary lint output for a package that's fine?

<fps>is it supposed to eat its own lines?

<fps>my last line of output always gets mixed with the prompt and looks like this:

<fps>fps@cherry ~/src/guix [env]$ -11-11-5098e0 [formatting]...me]...ive]...

<davexunit>yeah me too

<davexunit>not sure what's up with that

<davexunit>anyone else see that?

<davexunit>I have an assortment of terminal issues for which I don't know the cause

<fps>also: do you people also have broken line editing?

<davexunit>including C-c not working in some cases

<civodul>is it in xterm?

<fps>i suspect terminfo database issues :(

<fps>in all terminals

<civodul>is it a new issue?

<davexunit>civodul: yeah, any terminal. I use gnome-terminal

<fps>including lxterminal, xfce4-terminal and xterm

<davexunit>civodul: been happening for a few months now

<civodul>but not forever?

<davexunit>not the C-c thing

<fps>:)

<fps>git bisect to the rescue? :)

<civodul>i don't seem to have the problem

<civodul>is there a specific trick to reproduce it?

<fps>dunno, happened in all installs for me

<fps>civodul: is your install old? :)

<civodul>i don't think so :-)

<civodul>i've been leaving on the bleeding edge, you know ;-)

<davexunit>it seems random to me

<fps>i.e. when did you guix system init :)

<davexunit>not sure how to reproduce

<davexunit>civodul: oftentimes, I cannot abort 'guix build' with C-c

<davexunit>not sure if every time

<civodul>it certainly works for me

<civodul>so there must be something special with my setup

<davexunit>yeah I have no idea what's going on or how to begin to debug

<fps>what does TERM evaluate to on your systems?

<civodul>i have ~/.inputrc with:

<civodul>set convert-meta off

<civodul>set input-meta on

<civodul>set output-meta on

<civodul>TERM=screen

<fps>xterm here..

<fps>let's try changing that :)

<civodul>seems to work well in TERM=xterm too

<civodul>i have ~/.Xdefaults with:

<civodul>XTerm.vt100.metaSendsEscape: true

<fps>TERM=screen bash

<fps>and line editing works

<davexunit>I have no special config for this

<davexunit>gotta run though!]

<fps>but guix lint output still looks garbled.

<fps>civodul: can you paste an example for how lint output is supposed to look for a fine package?

<fps>hmm, no, false positive.. line editing seems to only fail under certain circumstances... setting TERM didn't seem to have changed anything at all

<fps>:)

<civodul>fps: oooh i do have the problem for 'guix lint' output in xterm

<civodul>ludo@pluto ~$ ape-0.91 [formatting]...me]...

<civodul>but i guess that's because use of \\r in there is simplistic

<civodul>insufficient

<fps>and non portable ;)

<civodul>yeah, dunno what the right thing to do is

<civodul>suggestions?

<civodul>ACTION was distracted and found himself writing a GNOME updater

<civodul>rekado: thanks for reviewing the git-annex series!

<fps>civodul: do you want a newline and a carriage return?

<fps>i'm not too familiar with scheme (assumng lint is implemented in scheme)

<fps>but in C you'd just use \\n

<fps>and the runtime would guarantee to do the right thing [CR on some systems, just R on some others, etc.]

<fps>if you want to fancily rewrite a line, there;s basically no way around curses, ncurses or something similarly dreadful

<lfam>Are you just trying to clear the line?

<lfam>I do have that issue but it doesn't bother me too much

<fps>why try to be fancy at all?

<fps>just write lines of output :)

<lfam>If you just want to clear the line and rewrite, you don't need curses. You can use ANSI shell escapes. In bourne shell it's 'printf "\\r\\033[K"'. Of course I have no idea how to do that in Scheme.

<lfam>That just erases the line so you can rewrite it.

<lfam>Which I think is preferable if there are no issues. A successful pass through the linter should leave no output except for a zero return status.

<fps>oh wow, ansi

<fps>reminds me of my bbs days

<fps>and yes, they are as horrible as termcap/terminfo

<fps>stuff that should die

<fps>unix terminals in general should mostly just die.. the whole ecosystem

<fps>don't get me wrong. i love shells

<lfam>Maybe so, but that is how you do it.

<fps>ansi sequences look horrible in copied and pasted text, unless all tools know how to handle them right

<fps>just

<fps>don't

<lfam>I don't understand that objection. That's code to do a carriage return and then clear to the end of the line. It leaves a blank line. Nothing to copy and paste.

<fps>i was speaking more generally

<fps>coloured log files using ansi sequences

<fps>the horror

<fps>etc..

<fps>:)

<fps>pipe em through less -> get eye damage

<fps>what's wrong with just outputting some text for a tool like lint? :)

<lfam>Silence is golden. A successful run of Unix tool should have no output, IMO

<fps>i agree

<fps>it's vanity not to stay silent in case of success, though we all fell victim to it (and i'll do in the future, too) :)

<fps>btw: where's guixsd's termcap/terminfo?

<fps>oh, vte