***hodapp1 is now known as hodapp
<Petter>Can you show the link to the original? <jmd>I've noticed that guix doesn't support reiserfs. Is there a fundamental reason for that? <brendyn>How does one list the dependencies required to build a package? The only way I know is to use guix graph but that outputs a dot file <jmd>brendyn: guix gc --references <brendyn>Often I wish guix's commands weren't so obscure <jmd>In some cases I agree. <brendyn>Why the hell is "listing the dependencies of a package" a part of the garbage collector <dvc>so are my linux-libre patches ok? <brendyn>I mean, when you spend enough time with it, it all *makes sense* but it still seems *wrong* <dvc>brendyn: the garbage collector needs to know what depends on what - how do you think it decides what store locations to free? <jmd>I agree. If you think about what the gc does, then it's a logical implementation detail. But not where you would normally think of looking. <jmd>Some time ago there was a discussion about breaking the user interface and reorganising the commands, but I don't think any conclustion came of it. <dvc>brendyn: do you have any other examples of obscurity? Adding a new command for this one case... <brendyn>Some people are talking about how to setup a build environment to build guix on the mailing list, since guix environment guix --pure doesn't work. <jmd>"guix package -l" is not particularly intuitive either IMO <jmd>brendyn: You can't build guix on a mailing list. <brendyn>What would be a command to setup the build dependencies without having to manually list them all <dvc>that's what I do, why doesn't it work? <brendyn>My email is turing complete, not sure about yours. <brendyn>because thinks like `which' will be missing <dvc>I usually don't bother - but I don't see why not <jmd>If "which" is an input, then guix environment will make it available. <brendyn>Hmm, I'll have to investigate again since I thought I had issues with that. <dvc>funny I always thought that the user interface was one of guix nicest features (coming from nixos, now that's a mess) <dvc>maybe something can be done to improve some of these exceptions - but I don't think that a redesign is needed <jmd>I think it could be designed more from the user's point of view, rather than the implementation's. <jmd>But probably we should wait until the implementation has progressed a bit further. <jmd>I wonder if "guix package" ought not to be renamed "guix profile". <brendyn>It seems there is a Law that says brendyn's problems always magically go away when he complains about them on IRC. I just build guix successfully under guix environment guix --pure. <jmd>brendyn: That's because there is a special bot, which fixes bugs when you mention them. <brendyn>Just as I suspected. Sounds like a security threat. <brendyn>What are the licensing rules for epiphenominal software? <dvc>I'll push my linux-libre patches since I need the substitutes available to continue, and they are pretty straight forward... <dvc>the kernel options I'm removing are already inside the kernel configuration files for i686 and x86_64. <brendyn>jmd: It seems guix gc --references requires guix to allready be installed in the guix store. I'm using guix from git <jmd>I think that is correct. <dvc>is there a test failure in master <dvc>if someone wants to fix it make check TESTS="tests/guix-build.sh" <retroj2>i'm interested in using a python program called fast-export (it converts mercurial repos to git). when i run it, it errors with "ImportError: no module named 'mercurial'". what should i do? <efraim>retroj2: you might need to wrap the program so it can find mercurial <efraim>I'm not in front of my computer ATM, but we have a number of python programs that have to wrap non-python inputs so they can be found at run time <efraim>I'd grep 'wrap gnu/packages/*scm -A3 <retroj2>should i make a guix package, or is it possible to do this ad hoc? i only need the program once <retroj2>efraim: i think i see what you mean. the package will need a 'wrap-program clause to set PYTHONPATH, yes? <retroj2>it might be good to have some kind of package request place, where people could name programs that they want packaged, and it would aggregate the data so that the guix community would know what is missing but in high demand <bavier>and it doesn't have a "voting" convention yet <retroj2>bavier: that's cool. the only thing that may improve upon it is some way of knowing which packages have the most requests <bavier>we could do like the fsf's pages and just request people put a "1+" or increment a vote count for packages they also want <retroj2>maybe (N votes) next to package names <bavier>retroj2: I updated the wiki with a suggestion to add +1-style votes <retroj2>is this url published anywhere where people new to guix would know to find it? <davexunit>I just made a page on the libreplanet wiki years ago <dvc>ng0: there already is documentation about how to start a vm with the -net user flag... <dvc>I'll add a note that the run-vm script doesn't add the flag by default and that ping doesn't work inside a vm ***[0xAA] is now known as Zer0Pings
<dvc>so submitted a patch to ML for some additional documentation on using qemu with guix. ng0: can you let me know if this would have helped you? <ng0>sigh. why does everyone assume I follow this with eagle eyes. okay, let me try to respond to what I can respond to. <ng0>dvc: network does not work *at all* in the vm for me, that's my current problem. i add ntp to that mix and for a short moment it works a bit, then it dies again <ng0>it was never exclusively about ping, ping is just a side problem i have <ng0>I will try to read through the patch you've sent. thanks <lfam>Huh, that's weird that it works sporadically <lfam>I wonder, does it work reliably when you are connecting to an IP address rather than a DNS name? <ng0>well sporadically: ntp starts yelling at me like I try to start a revolution in a dictatorship. for some time I can resolve gnu.org to an IP, then ping becomes unavailable again. I wished I could paste output. <ng0>I think I'll switch my Guix to build from a stable git checkout where I can create branches for such experiments.. I can rollback like always. <ng0>I'm working on this bigger project, and well I want to work, not debug ping when I don't need to. <ng0>David Craven (whatever the nick is here): many thanks for the work on cargo build system :) I've been hoping and whishing and partly working on this since february. <lfam>Hey jmd, I saw your comment about anti-features. Although we shouldn't have any packages with those f-droid antifeatures, I wonder about software that's abandonded upstream for so long that it's not safe to use. <jmd>lfam: That's a possibility. Although calling that an "anti-feature" is a bit harsh I think. <ng0>i wonder if this pcre bundle comment is really necessary. I'm not a neutral party in this, but I don't understand what pcre does in psyclpc. we have the meeting tonight and I try to get more information. I know we'll work on this, but channel was rather silent the last days when I tried to get information. <ng0>I know psyclpc powers psyced, that's all. <lfam>jmd: Yeah, it's not the right word. But it's something that users would want to know about in the same way as some phone-home software, in my opinion <lfam>Although it's a slippery slope. I think we'd have to issue warnings about half the system ;) <jmd>Well that's the other thing. It would be a rather subjective judgement. <ng0>yeah, because we don't do this for any other package afaik <lfam>ng0: Basically, if PCRE is used to process untrusted text (over the network, etc), then it's pretty dangerous. There are code execution bugs in that library <lfam>ng0: Let us know if you learn anything tonight <lfam>jmd: Yeah, I'm just playing devil's advocate :) We have to move forward, not scare everyone away from computers <lfam>I should clarify, I'm talking about a 13 year old version of PCRE. Hopefully the current version is bug-free :) <ng0>i know no one is in favor of bundling, so work on new features is massively happening on libpsyc, so I think I can make it a high priority to update it and unbundle. <lfam>sneek: later ask rekado: Do you know any free software that can be used to do SysEx over MIDI? I'm looking for something that can talk to my old Yamaha DX-7 <ng0>I've replied to too much emails etc today.. if there's anything I'll reply in a few hours. hopefully someone starts on mailman. and reviews debbugs ;) <jmd>Do people think we should mutate man pages which refer to paths? ***[0xAA] is now known as AutisticFag
<lfam>jmd: Hm, I guess we should if it's not too hard and the docs are very confusing otherwise <lfam>Then we know it's possible. It's worth somebody doing <jmd>I think it'll require another stage. <lfam>There's a lot of things we need to change about our man pages. There are changes to the various man page generators coming in new versions that will remove the timestamps <lfam>For python-2, that's the only thing holding us back from building reproducible packages in most cases <lfam>I think that we will get something similar for python-3 but I'm not totally sure. Upstream changes were required in the python-3 bytecode compiler <lfam>jmd: So would this phase do textual substitution of '/usr' to store paths, for example? <jmd>lfam: In most cases, yes. <lfam>Guix does use /etc in many cases <lfam>Or I should say, Guix packages use /etc <jmd>Some man pages refer to /usr/local <dvc>the hydra webgui is soo slow... <dvc>I've tryied looking at it today a couple of times - gateway keeps timing out... <bavier>dvc: hydra may be busy with an evaluation <dvc>why does an evaluation cause the webgui to be unresponsive? <Drakonis_>a question, if i were to install guix, what would prevent me from installing non free software and replacing the kernel with its non free version? <Drakonis_>guix seems like the free-est option so far, i'd install it and chuck nix inside to use nix's packages <lfam>That importer probably gets the least attention. It can only capture the very basic parts of Nix expressions. <lfam>But if you have to import many packages, it's better than starting from scratch <Drakonis_>nix has a lot of packages not in guix's packages list <dvc>we have some not in nix's package list... :) <ng0>when I have free time, I would hack on a ebuild/gpo.z.o/p.g.o importer. some day. <lfam>You're better of using the importers that those packages correspond to. For example, the PyPi importer, the CPAN importer, etc <lfam>Trying to parse Nix package expressions and convert them to Scheme is a fool's errand in my opinion <Drakonis_>the ebuild importer would make a couple folks in another channel go wild <Drakonis_>because gentoo is supposely the holy grail of source distros <ng0>I started gentoo specific packages for myself so i do not have to boot into the vm for ebuild maintenance tasks. <lfam>Like I said, the Nix importer will get the basics: name, source URL, hash, version. But all the "wrinkles" that Nix solves with `sed` et al? Those won't be captured <Drakonis_>i should be going now, but it is good to know <Drakonis_>and most importantly, i expected some blowback because of the whole "you want to run non free software" thing, but well, its good to know that i can get help <ng0>i have some gentoo specific branch on gitlab. pfl is there, but the frankenstein creation where I package portage to give pfl all lookup options I have not done so far xD <bavier>maybe if we had a sed->substitute* parser... :P <lfam>Drakonis_: We don't offer support on the official Guix IRC channel, the mailing list, etc. But people _are_ doing that stuff. <lfam>support for non-free software, that is <ng0>but apropos gentoo: i also have guix on gentoo done almost complete now. the openrc service needs work <ng0>well lynX fixed my work up. but you can build hello now :) <jmd>I think guix has got most essential packages. What it needs right now is services. <ng0>only downside: with the service you still have 30 minutes shutdown . <dvc>I can think of a few packages that are missing... but we are getting there quickly <ng0>the psyced suite and secure_delete (targeted around spring next year) and for me personally palemoon will be my last contributions in packages i think.. what I need afterwards are services I work on and core contributions/extensions. <ng0>like erase ram on shutdown (secure_delete) etc <lfam>dvc: Put 'em on your wish list :) <dvc>well, there's been wip on all the ones I'm interested in, people just got to finish them... :) <lfam>I'm going to propose we take my crude Syncthing package for now, in the absence of a Go build system <ng0>some have horrible large dependency graphs <ng0>gitlab and gogs need a go build system for example <lfam>I don't know how to handle Go's assumptions about fetching dependencies <lfam>We need a Go expert to decide what to do <dvc>lfam: from what I read on the rust mailing list go has the same issues as rust <dvc>debian packages go libraries as source because it lacks a stable api <dvc>you can take a similar approach to the rust build system, I added comments explaining this stuff to the patches today <lfam>dvc: Which issues are those? <lfam>It doesn't seem relevant for us, right? <lfam>Unless we start grafting Go packages? <dvc>it's relevant if the build system doesn't support precompiled libraries <lfam>Any change in the graph will trigger rebuilds <lfam>Do you mean bundled pre-compiled libraries? <lfam>So far, I've only looked at software that bundles source code <dvc>cargo will compile all it's dependencies - there isn't a LD_LIBRARY_PATH <dvc>so to package them I'm adding the source to out/rustsrc and replacing all dependencies with local copies so that cargo doesn't fetch them from crates.io <ng0>lfam: saw the replies on the list on the other python packages, I'm just busy and I'd rather throw packages in one large pack to the list. thanks for reviewing them :) <dvc>does that make sense? <jmd>lxc hasn't been packaged. <ng0>dvc: sounds like what our rust packager is currently doing. <dvc>exactly - I'm our rust packager... <ng0>bundling because rust has no concept of local things.. or what it was <dvc>that's what nixos does <ng0>no 'our' .. i'm not primarily speaking for guix <ng0>so our as in another project <dvc>a rust crate just isn't compiled yet <dvc>so it has a /bin and /rustsrc folder ***AutisticFag is now known as Zenified
<lfam>dvc: I don't get it, but that's okay :) To me, unstable ABIs don't matter in Guix (except when grafting), because everything dependent on foo is rebuilt when foo changes <dvc>lfam: that's right - but if cargo and rustc don't respect an LD_LIBRARY_PATH because of it, it doesn't matter that it wouldn't be an issue <dvc>it's a feature that hasn't been implemented yet because of this - that's all <lfam>My quandary with Go is mostly how to programmatically determine where to unpack the source code. It seems that each upstream's build scripts require it to go in some path that is a paraphrase of the source URL. For example, syncthing must be unpacked into 'src/github.com/syncthing/' <lfam>All the dependencies go into some path relative to 'src/' <lfam>Then you build from 'src/..' <lfam>It might be possible to instrument `go` to figure that out, but I'm not sure. <lfam>I got to my "worse is better" state with the Syncthing package and moved on <dvc>I'm not familiar with go. But it looks like a dependency is specified like this: "ImportPath": "code.google.com/p/go-netrc/netrc", <dvc> "Rev": "28676070ab99" <dvc>so you can replace that with something like "ImportPath": "/gnu/store/..." <dvc>and the go build system will then build *all* dependencies <dvc>so the go importer gives you some inputs. then you just generate a new dependency file. I'm guessing you can simply remove Rev if it's not a git repo <dvc>but anyway... for one go package it's not worth it... <dvc>how is docker packaged? <lfam>I guess I can't send my Syncthing package in as-is, since Syncthing bundles the source of several dozen dependencies. It would probably be faster to make the go-build-system than all those package definitions, and the transitive dependencies thereof <dvc>lfam: FIY don't know how debian does it exactly but I saw it mentioned on the rust pages that they do something like what I described ^^ <lfam>Debian does not use the bundled dependencies <lfam>Wishing for a "IRL" Guix hackathon. I'd love to put the go-build-system together along with a more skilled mentor <lfam>Or another project like that <dvc>I just know what I read - but don't know anything about go... <dvc>and why do you need a mentor? <lfam>I may have been around Guix for longer than you, but it's clear to me that you are a much better Scheme programmer. I'd love to "pick someone's brain" without the friction and latency of going through a computer <lfam>In the meantime, I will keep polishing the wall with my head :) <dvc>I think a hackathon would be cool, but the real life thing could be hard... <lfam>Yeah, we are quite a distributed group, which *is* cool <dvc>lfam: where are you located? <lfam>I'm planning to go to FOSDEM this year <davexunit>lfam: didn't realize you were on the east coast <lfam>Hoping to meet some Guix people <lfam>I95 corridor Guix hackers <efraim>I was thinking of a go-build-system a bit <efraim>i was inspired by the tree of my wakatime vim plugin, where every bundled dependancy bundled its dependancy <lfam>Again, does anyone know what Hydra uses ImageMagick for? <lfam>I guess I should ask on #nix <efraim>so if we build something, split off the source into a "source" output, it can be used as a replacement for other bundled dependancies <dvc>efraim: That's what I was saying!! <lfam>Does anyone know an interactive "graph explorer" that I can hook up to `guix graph`? <dvc>lfam: you mean FOSDEM Feb 2017? <lfam>Okay, so Hydra can use CAPTCHA's via perl-catalyst-plugin-captcha, which depends on imagemagick transitively. Hydra also depends on imagemagick via dblatex <lfam>Seems like dblatex should not be accessible via the web interface, but who knows <lfam>I haven't noticed any CAPTCHA's while using Hydra so far. The question would be, "Where does the CAPTCHA image come from? Who controls the image?" <efraim>interesting bug: I changed the flann version to 1.9.1 but forgot to update the hash. guix found the hash using nix's content-addressed-mirror, and it downloaded flann-1.8.4 and set about using that <lfam>efraim: I've gotten that <lfam>It's a "safety-belt" bug in my opinion :) <efraim>seems like it could be a security concern, to get the wrong tarball <lfam>Assuming we trust those who can push to Hydra (we do), the impact is limited to "trick users into not upgrading", right? <lfam>I mean, who can push to Savannah <lfam>Not saying that's not a real issue <lfam>Considering how often people send patches with bad URLs because they had the source cached in their stores, we could plausibly be suffering this bug already <lfam>Back to Hydra / ImageMagick, if we use CAPTCHA's somewhere, whoever controls the CAPTCHA image could probably do some bad stuff on Hydra <lfam>Food for thought and a reason to not enable CAPTCHA's <lfam>OTOH, the content addressed stores are valuable... <lfam>efraim: Are you going to email guix-devel about it? If not, I will <dvc>hey guys - gotta go... <efraim>lfam: can you do it? I gotta fix my resume before sending it back to my contact <jcjordyn120>im using arch linux and elogind wont run, even though I have it in pam.d <lfam>jcjordyn120: wingo (in this channel) made elogind <lfam>Just calling his name in case he's available :) <ng0>(without seeing this channel) lfam: I don't have much further insight as lynX is not present this night, but our pcre in addition to old is also stripped down. I'll put updating it on the project roadmap. <ng0>psyclpc/src/pcre/README.LDMUD in case you have the tarball extracted. <ng0>there's much documented in our wiki, but even more (undocumented) in lynX head. that can turn out to be a problem sometimes ;) <ng0>so I'll know more when lynX told me how it's used. <bavier>ng0: I don't quite understand the problem. is the configure script generating a file with "#!/bin/sh" that it then tries to execute? <ng0>more or less yes. you pass arguments to mach, and in mach build this gets created and executed. nix seems to deal with this better in a way which is not obvious to me. <ng0>I could make my palemoon branch available so you could see it in practice <ng0>should we have a comparision page on the website? 'how does snappy differ from nix and guix' is something I found as a question in a search unrelated to this subject.