<codemac>is there a way to build a guix package that is not in GUIX_PACKAGE_PATH? <codemac>When I'm developing packages, it gets very frustrating that these in flux and generally broken packages break the rest of my `guix` command usage. Am I doing it wrong? <iyzsong>codemac: yes, I think the '-L, --load-path=DIR' option do the trick. <davexunit>sneek: later tell codemac to build a package without using the module system, you can do: 'guix build -e '(primitive-load "file.scm")'', where "file.scm" is a file containing Scheme code that evaluates to a package object. <xd1le>is there a mailing list for [newbie] questions? <lfam>xd11e: I think most of the discussion happens here or on the guix-devel@gnu.org mailing list. Ask away <xd1le>lfam: cool. i was wondering if it would bother people. thanks <lfam>That's how I got started <xd1le>yep haha. i actually just solved my question via rtfm. anyway, is there some sort of community managed list of package definitions? <xd1le>i see that there's a lot of packages that i use that are not already packaged, but perhaps others have already written definitions for them... <xd1le>or does the guix project generally accept new definitions that are sent to it? meaning the official defintions are exhaustive? <lfam>xd11e: If you think your package would be useful to others, you should email it as a patch to guix-devel <lfam>But people also maintain private package definitions for work or personal use <xd1le>lfam: thanks. i have some packaging to do... :) <lfam>Good luck and remember to ask questions if you get stuck ***anthk_ is now known as anthk
<civodul>Steap: did you already have a patch for python-minimal + Tk? <rekado>xd1le: there is no central site for a "community managed list of package definitions". Usually, we just accept new definitions. I cannot think of one instance where a patch adding a package definition for free software was rejected. <rekado>xd1le: even though I personally do have a list of package definitions that won't be added to Guix I only use it as a last resort and for things that are incompatible with the project goals. <rekado>when you have a package that seems useful and complies with the rules (e.g. not containing non-free software, not recommending non-free software, etc) it is likely to be accepted. <civodul>it's in the project's interests to accept new package definitions <xd1le>rekado, civodul: thanks. i only want to use free software so i don't think that would be an issue. my thought was how much your build farm can handle, and if it's therefore just for essential packages. <xd1le>i have a question. i am using guix on arch linux. i am wondering about installing packages via guix that have already been installed on the system via pacman (arch's default package manager). <xd1le>is it appropriate to keep both installed, or should i uninstall the one that was not installed via guix? <xd1le>as in, can gnu/linux in general work like that? <xd1le>i understand that the first one under the $PATH will be used, so I can just put the guix-profile/bin before everything else, but anything else to consider? <iyzsong>xd1le: yes, you could (and should) keep both installed. packages installed by guix are all under store (/gnu), it won't confuse the host distro. <rekado>xd1le: there should not be any conflicts. What *could* trip you up is if you had LD_LIBRARY_PATH set to system libs when running Guix software. Or having PYTHONPATH set such that system stuff is listed first, but you're using Guix Python. <rekado>so it's not just PATH that needs to have items in the correct order but also other environment variables. <xd1le>iyzsong, rekado: i see. thanks a lot. <efraim>i'm looking at some of the hydra failures, as part of making sure i fixed gprolog nicely i'm finally trying out guix environment since guix build just downloads the binary <efraim>./pre-build-env guix environment guix -E 'guix build gprolog' <civodul>efraim: to disable downloads of substitutes, use 'guix build gprolog --no-substitutes' <efraim>civodul: i tried that, and it wanted to start from bootstrap <civodul>the 'guix environment' command you give would work, but it's a bit awkward <civodul>that said, i think the fix for gprolog is just to change the 'supported-platforms' field, no? <efraim>yeah, but i wanted to make sure I didn't break anything <efraim>and with the small change it was a good chance to try out guix environment knowing it should build fine <efraim>if we ever get powerpc or mips(not64) or alpha gprolog is supposed to support those so I resisted the urge to just whitelist i686 and x86_64 <civodul>'supported-platforms' only affects what Hydra does, though <civodul>it does not change the result of 'guix build gprolog' <efraim>also about that armhf board with the possibly faulty ram, I built gprolog for i686 no problem on my x86_64 machine and on hydra it shows a build error <civodul>ACTION is afraid of seeing the "faulty RAM" excuse popping up too often ;-) <efraim>er, right. nevermind, don't know what i was thinking when I wrote that :) <xd1le>how are upstream updates to packages handled? <xd1le>is there some sort of automated system set up, or is it more like a maintainer of a package has to check manually for an update? <xd1le>i'm asking because ghc on guix is still on 7.8.4, but the latest release (months ago) is 7.10.2 <taylanub>xd1le: there's "guix refresh" but AFAIK it isn't continuoutly executed by anything; guix developers need to use it. I also never used it and don't know how well it works. for GNU packages conforming to GNU packaging conventions, guix checks automatically whether there's a newer version every time a version is installed, and notifies the user that there's a newer version. <taylanub>it shouldn't be hard to set up a system that continuously looks for new versions and keeps an updated list of outdated recipes <xd1le>taylanub: thanks. I guess it depends on the package? for example, one could check for the existence of any new tags on the origin remote if the package is using git. or is there a better way to check for updates? <xd1le>so I guess the solution is that people can just send patches with updated package definitions if a package they use is outdated? or are there designated 'maintainers' of packages? <rekado>there are no designated maintainers, but sometimes the original contributor of a package may have additional information and can weigh in on discussions about updates. <rekado>to update a package definition anyone could send a patch, and that's often how it's done. <xd1le>is there some sort of policy on how 'stable' guix wants packages to be? for example, in nix there is stable and unstable 'channels'. does guix always try to have the latest release, or is there some sort of 'testing' period before an update on hydra is available? <efraim>we don't have a stable and unstable channel, we have our main branch and a couple work-in-progress branches for new features and a core-updates branch that would result in a huge number of rebuilds. <efraim>so... qpm is for qt modules you might want while writing a qt app? <taylanub>xd1le: if a build recipe still builds after updating the version and doesn't have any obvious problems, then it will be accepted by guix upstream. by the time guix 1.0 is out, maybe there will be a 'stable' branch which 'guix pull' will use instead of the master branch... <xd1le>thanks guys, that makes sense <efraim>quick question: is there any reason for a package with only an "out" output to be an input and a native input? <civodul>rekado: "qpm is focused on application development. All package dependencies are compiled directly into your application binary." ouch! <efraim>but at least they'll be up to date! ...as of the last release of your application <efraim>now working on ocam, which is at a minimum missing camlp4 as an input <efraim>camlp4 has 3 inputs, two of which are ocaml, so fixing that first <davexunit>useful, and slightly funny, container resource <davexunit>including a list of container implementations. we'll need to get call-with-container on that list! <civodul>we need to get wip-container merged! :-) <davexunit>IIRC, I did something that makes tests/guix-environment.sh fail :( ***cyril is now known as Steap_work
<civodul>arf, that's fine, we'll figure it out! <Steap_work>ACTION gave a presentation about Guix-tox to a few colleagues \\o/ <civodul>Steap_work: do they look at you differently now? <Steap_work>civodul: had a few questions, but then we ate like pigs and I forgot them all :D <Steap_work>civodul: well, now that I've proved that Guix is better than RPM, they want me fired. <davexunit>civodul: for speed, would you mind taking a quick look at this updated 'guix environment --container' patch? <davexunit>civodul: you wanted me to extract the network config files list to a global, which I have done, as well as fix up a couple of docstrings. <davexunit>if I can defer the test suite issue which is blocking me, I will apply this now before I go to work. <davexunit>I can also update the branch if that's easier <davexunit>civodul: I see one weird formatting change. too much whitespace before parse-command-line. I'll clean that up. <davexunit>oh, that's just a rendering issue on paste.lisp.org it seems... <davexunit>actually, just reading the diff wrong. ignore me. :) <civodul>the only remaining issue is to add a small test, as i wrote in my Sep. 11 message :-) <civodul>but we can add it afterwards if you prefer <davexunit>yes, the issue I have there is that I can't figure out what that test file is failing. <davexunit>er, that locale warning wasn't there last time ;) <davexunit>I need to get past this issue to get to the real issue I was having before all this libc upgrade stuff... <davexunit>I'm not sure why this test guix daemon is having trouble, though... <civodul>davexunit: because it's linked against libc 2.21; you need to relink it <civodul>but for now, it's enough to run: LC_ALL=C make check <davexunit>I have trouble parsing the failure logs of these bash tests <civodul>davexunit: "guix environment --ad-hoc guile-bootstrap --pure -E 'guile -c "(exit 42)"'" should have exit code 42 but it doesn't <davexunit>okay, I'll debug that. thanks for all the help. <davexunit>looks I swallowed the exit code somewhere. thanks, test suite! <civodul>yeah, the patch removes (return (exit (status:exit-val (system command)))) <civodul>and presumably launch-environment doesn't do something equivalent <davexunit>don't know how I managed to remove that. silly. <davexunit>civodul: what do you think of this helper macro? <davexunit>(define-syntax-rule (return-with-exit-status exp) (return (exit (status:exit-val exp)))) <civodul>davexunit: i doesn't save much typing, so i don't think it's worth it ***chil_ is now known as chil
<davexunit>oh jeeze. that would explain why I can't get substitutes. <mark_weaver>postgresql is bloated up again. it needs to be restarted regularly <davexunit>would a cron job to restart it every day or so be sufficient? <davexunit>until we have a frontend that runs a new postgresql built by Guix <mark_weaver>it's a bit messy. all of the hydra daemons need to be shut down, then the postgres restarted, and then the daemons need to be brought back up. <mark_weaver>so all builds in progress are aborted, and the web server temporarily offline. <mark_weaver>on top of everything else, there's a GC running, and I guess I should leave it running to completion. <efraim>isn't there a way using parallel(?) or some other commands to not start a command unless the load is under a certain level <davexunit>civodul: so for this 'guix environment --container' test, I guess I want to grep through /proc/mounts for things I expect to be there? <davexunit>would making a container with the bootstrap coreutils work? <paroneayea>mark_weaver: what's bloating postgres, do you know? <mark_weaver>paroneayea: good question! we haven't yet investigated. <paroneayea>also yayyyyy for getting "guix environment --container" close, davexunit <mark_weaver>it might be a problem with the old postgresql we currently have running on hydra, or it could be a problem with hydra's programs that use postgresql. <civodul>davexunit: you could make a container with just guile-bootstrap and have it run a piece of code that checks the available mount points <davexunit>civodul: okay, thanks. I'm currently trying to get a test to pass where it just checks exit status but it seems to hang the test suite. <davexunit>it does the right thing when I run it outside of the test env. <civodul>davexunit: or it could make sure (scandir "/") just returns /gnu, /bin, and /etc <civodul>davexunit: you can tail -f tests/guix-environment.log to see where it hangs <davexunit>civodul: eek for some reason it's trying to build a ton of things :/ <paroneayea>I think postgres doesn't so much mutate old rows as much as replace them with new ones <civodul>if we could all sit down for a couple of days and come up with a Hydra replacement <civodul>we already have a 3rd of what we need <mark_weaver>(that revision supports 6-core processors, earlier revisions support only 4-core) <paroneayea>civodul: hydra the frontend machine or the software? <civodul>paroneayea: for the hardware, we need money; for the software, we need hackers <civodul>but yes, hardware is the most pressing need <taylanub>there's no donation instructions up yet are there? <davexunit>mark_weaver: how much does that motherboard cost? <davexunit>civodul: I added an additional chunk of code that is like the "test $? = 42" test, but adds the --container flag. <davexunit>adding that flag seems to fundamentally change things <civodul>davexunit: change things in that it builds a lot of stuff? <civodul>davexunit: i see (package->derivation bash) in the patch <civodul>this involves building guile-final, which means libc, etc. etc. <civodul>'guix package' has a --bootstrap flag specifically for this <civodul>maybe something similar could be done here? <davexunit>as you can see I'm quite ignorant at the bootstrap binary level <civodul>heh, that's fine, it's the kind of thing we don't notice in normal use <davexunit>so rather than "use the bootstrap Guile to build the profile", this new --bootstrap flag avoids mixing in non-bootstrap derivations. <davexunit>not sure how to phrase that in a terse but understandable way <civodul>"use bootstrap binaries to build the environment" <civodul>with the understanding that it's an obscure option anyway <civodul>does anyone know how CPython decides whether it builds tkinter or not? ***davi_ is now known as Guest44531
<davexunit>civodul: sorry to keep pestering you with questions, but I'm trying to figure out how to use a bootstrap bash effectively. I've discovered 'search-bootstrap-binary' and 'add-to-store' <davexunit>which allow me to find the bootstrap bash and add it to the store <davexunit>but it leaves me with a string, not a derivation, and the rest of my code expects derivations <davexunit>the environment creation process adds the bash derivation to the list of things to build <davexunit>do I now need to detect a string and do something special? <davexunit>I was hoping to keep the bootstrap binary stuff more localized. <davexunit>it's an unnatural pronunciation for english speakers, but a natural pronunciation for, say, french speakers. <davexunit>there would be no pun then, and what's the GNU project without puns? nothing, that's what. <paroneayea>maybe it's time I put ~/org/guix.org in place :P <frenda>How much this distro is serious? Would it be sth like trsquel finally? <davexunit>frenda: I don't quite understand the second question, but yes this is a serious project. <davexunit>Guix is fundamental shift from how we've traditionally viewed package and configuration management. <davexunit>it's design enables many features that are not possible in traditional package managers. <frenda>I'm not a technical user or programmer, but I would like help someway, is there any plan to translate something to native languages? <frenda>davexunit: Ubuntu is going to replce apt with Snappy; comparing Snappy and Gnu Guix, Does still Snappy kind of traditional approach? <davexunit>frenda: we have translations in multiple languages and we could definitely use help to add new ones and make the existing ones better <davexunit>frenda: Snappy shares some of the features of Guix, but lacks many things as well. <davexunit>I'm biased of course, but Snappy's design is inferior. <bavier>I just noticed how little of the 'guix-package' domain is translated <davexunit>there's lots of stuff. we probably need to do some outreach there. I have no idea who our translators even are! <yrns>notmuch doesn't include the python bindings? I see there's a python2-notmuch but it's an older version. <davexunit>yrns: perhaps there's a configure flag we need to enable? <davexunit>or perhaps we just need to add python to the build environment or something. dunno. <davexunit>from HN: "The biggest pain I've run into when using Docker for local dev is waiting for pip to install dependencies on rebuilds." <paroneayea>some friends are suggesting I should give a talk on Microsoft Channel Nine on guix, think they might have contacts <davexunit>a problem that you don't have with functional package managers because things that haven't changed don't get rebuilt! <civodul>so i have _tkinter.so, but somehow 'import tkinter' ends up search for tkinter.so, not _tkinter.so <paroneayea>well glad you seem to have figured it out civodul :) <civodul>and i was picking the wrong one, obviously ***exio is now known as exio4
<rekado>My Emacs does not display images in Info mode. <rekado>This is especially sad in the LilyPond manual. <rekado>does anyone know how to make this work? <rekado>(or is this a failure in our lilypond package?) <C-Keen>I didn't know info mode is supposed to do that <rekado>failure to build the info docs correctly maybe? <rekado>David Kastrup often mentioned on emacs-devel that his LilyPond info pages are superior to the HTML thing. <rekado>must be a problem generating the info pages then. <efraim>in a number of packages we don't include doxygen for the documentation <efraim>don't know specifics about the output using doxygen <rekado>it's a backup system using content addressable storage, written in Chicken Scheme. <rekado>ACTION still backs up with rsync, and not nearly often enough <davexunit>and more likely that the developers know what they are doing <cehteh>well yes .. but i just prefer rsync :D <cehteh>robust and works since years here, some script around it <rekado>rsync doesn't work for me well, because I have a big desktop with most files, and a laptop with a subset of these files. <rekado>and I back up to an external drive. <cehteh>thats not a backup by my definition :D <rekado>CAS seems like a good way to make sure I'm not needlessly backuing up dupes. <cehteh>bachups have to to run automatically and regulary without human interaction <rekado>well, yes, I cannot do it often or automatically because of this seemingly odd use case. <cehteh>i use the hardlinking feature of rsync for incremental backups, but only on set at a time, i guess it should be possible to do that in a general way <cehteh>problem is how metadata of the files get handled when things get hardlinked <civodul>i have/had a project kinda similar in spirit but mostly alpha <rekado>I don't want to fiddle with rsync and write bash scripts anymore. I've done this kind of thing too often and I always feel dirty afterward. <cehteh>but i got bitten once by some other backup system which was a big mess <cehteh>ok was implemented in python, i should have known better :D <rekado>gah, I've been working with Python for the past few days. It's not fun. <cehteh>idea to have something content addressable is nice <rekado>what's worse: it's a bioinfo library... <rekado>civodul: I did hear of libchop somewhere ... I wonder where. <cehteh>python on itself .. and the attitude it enforces on developers <cehteh>the other thing is tahoe lafs .. if it only wouldnt be implemented in python <davexunit>civodul: do you have any advice re: derivation for bootstrap bash from earlier? <civodul>davexunit: you could use the bootstrap 'bash' binary when --bootstrap is passed <civodul>so to do that, you need (search-bootstrap-binary "bash") <civodul>something like (local-file (search-bootstrap-binary name (%current-system))) <davexunit>my problem is that now my code has to take special care of plain strings where it before expected only derivations <civodul>rekado: re images in Info, it's probably an issue with the lilypond manual <davexunit>civodul: I was curious if there was a way around that or if I just have to write some extra code? <davexunit>I have a procedure that expects a bash derivation, and I didn't want the bootstrap stuff to leak into it if it were avoidable <civodul>davexunit: i would need to check the details, but if gexps are used somewhere, then passing a <package> or <local-file> just works <davexunit>and the rest of my code will have no idea about the trick I pulled <a_e>Interesting, the ugarit explanation. <a_e>So /gnu/store is a content-addressible store? <rekado>civodul: is chop-backup in a somewhat usable state? It sounds nice. <codemac>davexunit: super excited about guix environment --container ! <sneek>Welcome back codemac, you have 1 message. <sneek>codemac, davexunit says: to build a package without using the module system, you can do: 'guix build -e '(primitive-load "file.scm")'', where "file.scm" is a file containing Scheme code that evaluates to a package object. <davexunit>codemac: I need to write a patch to make this easier. <davexunit>civodul: hmm, so a <local-file>, when lowered, doesn't produce a derivation, does it? <codemac>Anyone here using guix as a user - can you run `locale -a` ? <codemac>it should print everything installed - mine instead prints POSIX and C <codemac>and my profile has glibc-locales installed <codemac>LOCPATH is set to LOCPATH=/home/codemac/.guix-profile/lib/locale <codemac>guix's locale is looking for /run/current-system/locale/locale-archive (that's fine) but then that means because I don't run guixsd, there is no locale-archive for my user <codemac>has anyone else run into this problem? <yrns>I'm in the same boat, yes. <codemac>The answer I think at some point will to just have a 'locale-user' package that is optional that contains the targets / dependencies to build a locale-archive that we can build locale to look for. <codemac>because this guixsd vs user thing will become difficult to compile for locales and other system level configurations that binaries expect to find when they aren't in fact installed at a system level. <yrns>Use of LOCPATH precludes use locale-archive, yeah? <yrns>I couldn't get it to work with the system locales. <codemac>`locale -a` specifically reads out of a locale archive, so regardless of the fact that it launches successfully using your locales, it can't list them <codemac>it's supposed to only print what you localedef --archive-add or whatever, not just what folders are installed. <yrns>Ah. And /run/current-system is only for GuixSD? <codemac>yes, my /run is populated by systemd