<brendyn>Any idea why I get this error using --container? guix environment: error: cannot create container: user namespaces unavailable <ngz>brendyn: What is your host distro? <ngz>brendyn: Some of them disable containers (e.g., Arch Linux IIRC) <cehteh>is guix packaged for debian somewhere? :) <edangor>guys whats the extension for a guix package? <alezost>edangor: there is no special extension for a guix package, it's a usual scheme (guile) file with package definition(s) <alezost>edangor: I meant .scm as brendyn says, but it's not a special-purpose extension <brendyn>edangor: The actual compiled 'package' is just a directory containing all the relevant files in /gnu/store/...../ I think. I suppose you could make that into a tar.xz file and call it a guix package? <sneek>lfam, rekado says: re ardour: “g++: internal compiler error: Killed (program cc1plus)” <sneek>lfam, rekado says: I didn’t see this on my machine. It built just fine. Maybe we should just restart it…? <efraim>lfam: I thought that was a result of the grafting process, that it showed the wrong version number <lostcoffee>janneke: thanks for all the help! I've sent in my patch now. btw, have you noticed that guile-wm stops capturing the prefix key after a while? <lfam>efraim: The version number is expected to be wrong in this case. I'm looking at the hashes <brendyn>Is it necessary to bother listing the copyright of configure files? <brendyn>.. when it just says unlimited freedom <brendyn>civodul: Do you think supporting free software tools for dropbox is ok? <civodul>brendyn: as long as the software itself is free, i think it's ok to package it <civodul>i don't think the FSDG have anything more to say about it <brendyn>Ok I found it. it seems like its sole purpose is linking with the dropbox API, so it doesn't depend on the dropbox app <brendyn>There was another dropbox app that is proprietary, so it looks like it's independant <brendyn>So pypi packages seem to be quite a bit different to the upstream sources <brendyn>Like 3MiB of extra tests and stuff upstream ***snape` is now known as snape
<quigonjinn>How can one add a source to the build inputs, and link it(its directory) inside the build directory? <civodul>quigonjinn: you can add an 'origin' in the 'inputs', and then add a build phase that creates the symlink <brendyn>So this programs build process is to open a GUI and click some buttons. haah <civodul>brendyn: you can spawn Xvfb during the build if the test suite expects to be able to start an X11 program <brendyn>It's been rewritten on Qt, and uses Qtcreator to compile <civodul>is Qt Creator really needed, or is qmake enough? <brendyn>Dunno, I'm just starting to stick my head down the rabbit hole. <brendyn>civodul: Can I boot to btrfs with GuixSD 0.11 ? <brendyn>i.e., can I install a system with that <cehteh>btrfs has still plenty problems and bugs <brendyn>cehteh: Do you mean in Guix or btrfs its self? <brendyn>I think its problems are outside my basic use case, which is just use it plain on my ssd <cehteh>then you wont get any benefits from btrfs, only the problems :D <cehteh>well your decision, but i'd rather go with ext4 or *maybe* f2fs for SSD's <cehteh>obscure error modes, failing to write files, defect file system, perfomance degradion <cehteh>lots of things you never ever want to see on a fs :D <brendyn>ACTION just packaged par2cmdline. maybe this is an omen? <brendyn>You can bork a file up to a degree and it'll fix it <cehteh>wont fix corrupt metadata on the filesystem and completely vanished files <cehteh>a friend of me tried btrfs on a backup server serveral times .. it always died after some use <cehteh>now he uses zfs and is much more happy, if only the licensing issues with zfs wont be <cehteh>no idea, whenever i tried/stresstested it i ran into trouble too <cehteh>feature wise i would be very happy if btrfs would be stable and deliver what it promises <cehteh>but from my experience it is far from there yet <brendyn>Well I've got some ext4 backup drives and btrfs backup drives. I kinda just pillage any drive I can find and put backups on it <cehteh>some people even say its fundamentally broken .. and when i look about the doctoring they do on it in the past years instead making real progress i start to believe that. and i am really sad about that <cehteh>well wanrnings saied, for some light usecases it seems to work, but its nothing you would trust valuable data to <cehteh>and the raid5/6 code is broken beyond repair, some time ago they announced that it should not be used and will be completely rewritten <brendyn>I never expect to trust any in the first place <brendyn>but files vanished I've never heard of <cehteh>i havent tried it recently (my jolla phone uses BTRFS still) <cehteh>but there are a lot complaints on the fs there going out for lunch (ok that kernel isnt the newest) <cehteh>and saied friend had backups running, rsync happily transfered data into a big hole, lots network load an no files :) <brendyn>I wonder if btrfs deduplication would be better than guix's store hardlinks? <cehteh>i'd stay with standard tooling, aka hardlinks <cehteh>thats easy to debug, portable and works well <cehteh>it may have some overhead on the cpu and io/load side for checksumming/comparing/hardlinking and can only hardlink exact same files <cehteh>while a filesystem based dedup could do that block or extent based and using cow <cehteh>but the savings from that wont be dramatic <cehteh>civodul: btw: with the services stuff, guix creates the config for deamons and so on from guile expressions .. i feel this has a steep learning curve and each and every service created needs a lot works to get this going. <brendyn>hmm ok well I guess I'll just keep ext4 for now and switch over to GuixSD one day <cehteh>i would like to have some way to specify a configfile at some user defined position (/root/my-system-config...) and let system reconfigure copy/install that into place. that would be straightforward and still functionally sound or? <civodul>cehteh: there's indeed quite a bit of learning here, but how much harder is it compared to creating a system service in, say, a .deb? <civodul>i like to thing that it's at least easier to reason on what the service does, and how it meshes with other services <cehteh>the services concept in guix is pretty nice <cehteh>i am just thinking about the config files of the underlying daemons themself which have varying syntaxes <cehteh>an sysadmin is most likely quite fond of the existing syntax rather than some guile expression <cehteh>so having config files as plainfiles could be benefitful, as long their mutation is managed by guix system <civodul>for some config files, we have complete "Scheme bindings" <civodul>for others, we just let people use the original syntax <civodul>it really depends, it's not clearcut, i think <cehteh>would be nice to have both, with a general template engine for config files in scheme, m4 like (duck, cover) <brendyn>civodul: That was your talk at the hackers meeting right? I watched the video <cehteh>well seriously, configfiles in plain with some commented annotations and some well defined text replacement engine could be much nicer <cehteh>and i have some doubt that the scheme bindings approach will scale in futrue when you have to reinvent the wheel for new daemons continously <civodul>brendyn: indeed; the one on services? <jmd>cehteh: The thing is, our wheels have less corners on them. <civodul>jmd: our wheels are round like parentheses :-) <cehteh>well thinks about the children^Wnon schemers .. i am bitching from that perspective <cehteh>there are a lot of things which could the usability better for people who dont know much schmeme <cehteh>(using cons* everywhere in the template files would be a start :D) <brendyn>But what was most interesting is Ian Jackson's talk, and I have some ideas for guix from it.. <jmd>cehteh: civodul is the guile maintainer. Persuading him to give up scheme is like persuading the pope to give up catholicism. <cehteh>i am currently struggeling a bit with guix because there are so much things i dont know how to solve and figuring that out is a lot work <cehteh>i dont want that, scheme per se is ok <cehteh>(well i would like lua more, but really thats not the point here) <cehteh>just the way things are done should be simple and consistent <jmd>There is indeed a lot to learn. But I think that guix is easier to learn and in general is self consistent. Of course the hardest part is letting go of pre-conceived notions. <cehteh>currently one needs to know a lot scheme to configure some details, this should eventually be wraped up to make things simpler <jmd>I agree that things should be better documented and with more examples. <cehteh>yes, but argueing this way doesnt improve guix, even if it *is* a lot easier to learn and package stuff, the goal should be to make it much easier further <brendyn>Essintially, Currently, many packages only link to source tarballs, but I think this is missing out on a big opporutinity. If instead of just the tarball, the version control repo was provided with the revision corresponding to the tarball (assuming upstream is kinda enough to do that, then I'd like to implement in no-nonsense feature in guix to download the repo, copy out the guix package definition to a .scm <brendyn>file changing it to set the repo as the package source, set GUIX_PACKAGE_PATH etc... <brendyn>The goal would be facilitate taking any program in Guix and immediately start hacking on it without pain ant struggle <brendyn>For example, we could start by doing it for all GNU packages since gnu.org follows a consistant format <cehteh>brendyn: fetching sources from git tags etc? .. would be nice <jmd>brendyn: That would be a useful feature to have, but I don't think it should be the default way that packages are built. <cehteh>apropos .. idea i had some time ago: could we add a --exclude option to guix hash? rationale: then one can hash a directory which is under revision control without doctoring the rcs out <brendyn>Anyway I'm not sure how this can be done at the present time, for example how could I add the git repo into a package definition? <cehteh>brendyn: yes thats not that simple yet <cehteh>you have to clone it and remove the .git to make the source tree verbatim <brendyn>cehteh: What I think is ideal is a sort of source agnostic source specification... if you get what I mean. The hash is the true source identifier, and the rest are just methods of getting it, ftp, http, gnunet-fs, git, ... <cehteh>you reminded me about that, the --exclude thing above comes into play here <brendyn>Currently, we use sha256, so all sha256 hashes can be converted into IPFS addresses and the download requested that way., for example. <cehteh>guix hash need to be aware/ignore revision control metadata, thats often non determnistic, but it shouldnt matter <efraim>brendyn: I started on gcompris-qt but iirc we're missing qtwebkit or something wasn't being found at build time, I forget which <efraim>I'm not at my computer so I can't check it now <jmd>cehteh: But how could I be sure that the presence/absence of certain metadata hasn't introduced a serious security hole? <cehteh>jmd: i cant come up with a case how this could be caused <cehteh>even if one manages to add some shellcode/sql injection ito a commit comment for example <AppAraat>if so, it's not loading for me at the moment, so if anyone has the package definition, could you please be so kind to paste it somewhere? <efraim> How does git handle files in a different branches? <cehteh>and if the build queries git to include revision control metadata from git <jmd>cehteh: if (0 == strcmp("$RCS", sentinel)) some_nasty_malware (); <cehteh>you still reset the repo to some given commit you want to build <cehteh>git history is deterministic from there, if that contains malware then its the same problem as it contains it in the first place in a tarball <cehteh>you still give the hash of the exact source tree you expect, only .git gets ignored .. anything nasty has to exist in your source tree already <jmd>But there could be a malicious git server serving up different code to different people. <jmd>if (ip_address == our_attack_target) serve_code_with_backdoor() ; else server_normal_code (); <cehteh>then the hash check will error out <cehteh>we check hashes on unpacking tarballs right? <cehteh>if one can make a hash collision then things get bad anyway <AppAraat>so when you're locally building from package definitions, the resulting files are hash-checked with the hydra server builds? <jmd>AppAraat: guix challenge does that. <rekado>sneek: later tell lfam I restarted the build for Ardour 5.3 and it finished successfully (in much shorter time than the previous build attempt). Not sure what happened there. <AppAraat>jmd: ah cool, does it do this automatically? <rekado>sneek: I’m looking at the botsnack jar, but I think you had enough. <jmd>What do you mean "automatically". You have to enter the command. I suppose you could put it in a script, and voila! It's automatic!! <AppAraat>I meant when the build finishes it automatically checks whether hashes coincide with hydra server as a secure-by-default approach kind of thing. <rekado>AppAraat: no, it doesn’t do that. <rekado>I think it’s okay the way it is, because I think talking to hydra should be opt-in. <jmd>Also if it did that it would rather defaut the purpose of substitutes. <rekado>ACTION wonders why GHC needs to be built/downloaded for haskell packages to work. Should the binaries really keep references to GHC? <cehteh>does it include some runtime lib? <cehteh>and some haskell packages do jit stuff <AppAraat>jmd: what do you mean with defaulting the use of substitutes? <cehteh>anyway practical problem: where do i set the keyboard configuration that Xorg should use? <civodul>rekado: like cehteh writes, 'ghc' probably contains runtime libs; we should try to move them to a separate "lib" output, like for gcc <AppAraat>perhaps a hash(-tree?) of all packages could be downloaded from the hydra server and local builds checked against that list, so that local machines don't keep contacting the hydra servers? <cehteh>i configured a guix build server here, with publish and offload stuff <cehteh>what i miss is that it can actually fetch and cache things from hydra <civodul>ACTION applies that Django package that has been sitting there for several weeks <cehteh>aka if a client has is as substitute and the package is not on the build server it should fetch it from hydra, is that possible somehow? <cehteh>currently i have to supply hyda as substitute on the client as well, but that means each client will contact hydra again instead my own server <jmd>AppAraat: I meant to write "defeat". <AppAraat>ah ok, well it seems to me that when one is getting a substitute from hydra then there is some inherent trust in the hydra server. <AppAraat>oh now I see, so if one doesn't trust the hydra, then why rely on the hash trees in the first place? <AppAraat>this actually makes quite a lot of sense. <jmd>No. I mean that if you ran challenge on every substitute that hydra gave you, then it wouldn't save you any effort, which is what hydra is meant to do. <AppAraat>oh I see, yeah but what if you're building locally and don't want the substitutes from hydra, just hashes of hydra's substitutes? <jmd>I cannot imagine why one would want that. <jmd>Except perhaps to test the veracity of hydra. <cehteh>ACTION was wondering if one could build something like guix but using hashes only from sources not over the generated files. That has ups and downs, just a thought <cehteh>lessen the 'deterministic build' condition, allowing for prelinking and easier patching/grafting .. <jmd>I'm sure that could be done. But the effort at the moment is in the direction of hardening that condition. <AppAraat>jmd: because if there's a discrepancy between the resulting hash of the local build and hydra's build, you know there's something wrong either on your system or on hydra. <jmd>AppAraat: Right. That's what guix challenge does. <cehteh>doh .. where is the | on a us-english keyboard? :D .. i am still struggeling to figure out how to configure the keyboard for X <AppAraat>jmd: though if I'm understanding the documentation correctly, guix challenge first scans the local store, and then queries the servers. But if the local machine is offline? <cehteh>local as in your /gnu/store on the machine you type that <alezost>cehteh: re configuring keyboard on X: I think usually people put "setxkbmap ..." to their ~/.xsession file; or use DE facilities for this <cehteh>oops ... one should not have the same command modifier on the host and in a vm .. just closed my session :D <cehteh>uhm why does librecad pull postgresql, ruby, shitloads of other packages <cehteh>sometimes its better not to question the dependencies on software <davexunit>these are questions that you can answer yourself with the tools guix provides <cehteh>i know .. but i guess it drives one insane looking at that <davexunit>it's frustrating when people ask these questions as if the packagers were blind fools just throwing things <efraim>Trying to view the PDF afterwards brings my computer to its knees <cehteh>davexunit: nah, i dont blame the packagers, just the growing complexity of modern software <efraim>Is there an ncurses program that I can use to see the output of dot -Tsomething? <cehteh>not that i know, but the dotfile itself is somewhat readable <cehteh>there are some asciiart->dot tools but i dont know the other way around <davexunit>efraim: there are many different ways to view the graph <davexunit>some of them produce enormous graphs, others are better. <davexunit>guix graph --type=package librecad | dot -T pdf > librecad.pdf <davexunit>the graph is quite big but you can zoom around and read it <davexunit>you will quickly see that the graph is pretty much entirely Qt. <davexunit>some effort has been taken to break up the monolithic qt package into many smaller ones <davexunit>so perhaps the librecad needs tweaking to use those instead <davexunit>that will hopefully eliminate a lot of nodes from the graph <cehteh>just forget about it, i just installed librecad because i wanted to test the new installation and how it works woth a slightly more complex package, i dont even have any use of librecad in that vm <cehteh>either way .. i have guix running fine now, one 'farm' vm for building and some experimental vm's, only waiting for the full disc encryption finished to deploy it on real hardware <davexunit>hopefully full disk encryption will happen soon <davexunit>I know there's a bunch of folks interested in it <cehteh>if i wont be so much of a scheme noob i would contribute to it <cehteh>maybe i find some time to look into it <cehteh>and on the way i make some notes, prolly giving a talk about guix on one of our next LUG meetings here <cehteh>disc encryption is really mandatory imo .. i mean a friend uses a degausser before he RMA's a disc, but i dont have one :D <snape>cehteh: people using libreboot can use full disc encryption. Not everyone uses libreboot though. <cehteh>i doubt that will work on the hardware i plan to use <cehteh>wlan isnt supported with linux-libre already .. <cehteh>i have a thinkpad x230, libreboot should work on it, but i am a bit reluctant to try it there <davexunit>due to intel AMT being too difficult to break <cehteh>nah .. at froscon i talked with one of the libreboot devs he saied x230 is fine <cehteh>i didnt thought so either, and havent looked into details <cehteh>ah maybe i mix up libreboot/coreboot .. <davexunit>but it sounds like an improvement over my hacked completely proprietary BIOS <cehteh>i just cant afford to brick the device <cehteh>and this still doesnt solve the problem with the samsung netbook, eventually it needs a vanilla kernel and firmware to be able to use wlan too ***harlequn79 is now known as harlequn78
<snape>cehteh: changing the wlan card might not be that difficult <davexunit>snape: without flashing new boot firmware it's not possible. <davexunit>the proprietary BIOS has a whitelist for the PCIe slot that the wireless chip is in <davexunit>to get around this restriction one must either flash a hacked version of the proprietary BIOS that removes the whitelist (what I did, was pretty shady) or flash coreboot <davexunit>I don't think coreboot was available when I got my x220 <snape>davexunit: I see. It sounded to easy to be true <cehteh>snape: changing kernel is simpler :D <paroneayea>it looks like it requires some problematic thing to be written to its confg first <paroneayea>I don't think we even have a mysql service yet though <lfam>Wow, Vim version 8.0 is released <sneek>lfam, rekado says: I restarted the build for Ardour 5.3 and it finished successfully (in much shorter time than the previous build attempt). Not sure what happened there. <lfam>paroneayea: From what I've seen, there aren't any patches yet for that MySQL issue, right? <lfam>Ah, yes, the researchers disclosed it as a 0day <lfam>efraim: Want to do the update? :) <efraim>i've also decided to ditch plugin managers with vim and use myrepos instead <quigonjinn`>I'm trying to define a package that inherits gcc. It seems to use -j flag with make. How can I verify that? Can I force it to build with one thread? <efraim>i forgot how annoying the audio bell is when running the tests on vim <lfam>efraim: The test suite rings the bell?! <quigonjinn`>I dont see that flag in #:make-flags in gcc-4.7.4 from which 4.9 inherits. <janneke>how do i use plain-file/file-append? <lfam>quigonjinn`: I don't really know if this applies to your situation, but the gnu-build-system does have a #:parallel-build? flag <janneke>if one is specified e.g. in a service configuration, must i evaluate these and write to disk/make symlinks? <janneke>i'm looking at *-file-compiler...but no-one is calling those? <lfam>I don't know what this error on Hydra means: "cannot build missing derivation ?/gnu/store/r4cficy0cjf2y16sznw1lrh1z37b2m67-ladspa-1.13.drv?" <janneke>yay, figured it out, i think...just do nothing ;-) <lfam>janneke: That's always the best solution <efraim>making it bit-reproducable, in a snippet is better than in a phase? <jmd>I don't see any advantage of one method over the other. <lfam>Yeah, for this case, I think it's a matter of taste. My understanding is that snippets are primarily meant to strip non-free bits from the source code returned by `guix build --source` <lfam>Using a patch is nice, because you can easily send it upstream :) <efraim>now the extra ) in vim --version is much more noticable <efraim>also, looking at the included scheme.vim and reading :help ftplugin, it looks like it should be possible to create a guix.vim that will help with indentation and possibly other things <efraim>and to think every time I thought about vim plugins it never interested me in the slightest <janneke>how do i create a directory in etc-service-type? <janneke>this works great: (("rc" ,(rottlog-rc-file config)) ...) <janneke>but puts all files in /etc, now i want /etc/rottlog <efraim>our mpv doesn't reference vapoursynth <jmr>I just installed guixsd on a box. I find it very interesting. <jmr>Now I have to sort out exactly how the shepherd/init system thing works and then how to build packages. <jmd>jmr: Building packages is easy. Understanding shepherd is another thing. <cehteh>sheepherd isnt that complicated eithre <jmr>at first glance shepherd doesn't seem that compliated either. <jmr>Suspect I need to learn guile, tho. <davexunit>it's been pretty easy for me to figure out anything I've needed to figure out so far <janneke>creating a dir in /etc drives me mad...too difficult for me <davexunit>shepherd is a much smaller codebase so it's pretty easy to find what you're looking for <jmr>Seems to be a different mindset... files in /etc aren't supposed to be directly modified. <janneke>efraim: no, the directory creates fine when i set periods to '() <janneke>i just can't seem to get the for-each loop, or the '#$periods thing <janneke>davexunit: thanks for trying...me neither :-( <davexunit>too much car/cdring, weird indentation, comments, etc. <davexunit>(map identity periods) is the same as 'periods' <janneke>it's just that i copied from a snippet that seems to work <janneke>where foo and bar are outer variables just like `periods' <janneke>ERROR: In procedure scm_lreadr: /gnu/store/iiz76bwwx24vdn309h3phhqs2qj9ap2f-rottlog-builder:1:208: Unknown # object: #\\< <civodul>janneke: if you open that "rottlog-builder" file, you'll see what the object at hand is <davexunit>janneke: it's because 'periods' is an object returned by rottlog-periods <davexunit>which is presumably not a primitive data type <civodul>but we should raise an error instead of letting the invalid object through ***jmr is now known as jamesrichardson
<janneke>(begin (mkdir ((@ (guile) getenv) "out")) (for-each (lambda (period) ... (quote (("weekly" ...) ("daily" . ..)))))) <janneke>i need some eval'ling or instead quoting...hmm ***jamesrichardson is now known as jamesr
<janneke>ah, it needs to be a lambda i guess, hmm ***jamesr is now known as help
<efraim>... and python itself wants cython <lfam>efraim: Typo in the Vim reproducible commit. s/reproducable/reproducible <civodul>i got little support from these ARM employees so far, hopefully that'll come :-) <lfam>Surely we can't be the only people experiencing this bug! <lfam>My understanding is that the bug only manifests when expat is compiled with -DXML_UNICODE <lfam>I'm working on updating expat to the latest release (2.2.0) for core-updates, but that commit is not in 2.2.0. Do we want to apply it as a patch? <civodul>is there a security analysis of this bug somewhere? <civodul>i'm not clear on what the consequences are <civodul>i was browsing it but it's kinda long :-) <lfam>Apparently, the consequence of the bug is that tags are limited to 15 characters, which seems to me to mean "the library doesn't work" <lfam>But like I said, I don't think the bug will manifest for the way that we build expat. <lfam>There's really no cost to applying the patch on core-updates. I'm wondering more if we want to use a graft. <civodul>right, i don't understand if there's a buffer overflow or if it's just a silly limit that is reached <lfam>Since mark_weaver's faster grafting patch, even grafts have little cost... when they work :) <civodul>did mark_weaver eventually apply his patch? <civodul>damn it, i had forgotten/overlooked that <lfam>I think you might have been AFK at the time <lfam>My preference is to apply the patch, even if the bug doesn't manifest for our expat package. I don't think it's unreasonable that somebody would use Guix as a tool for getting free source code that they build in some other way. <civodul`>lfam: yes, that sounds safe and doesn't cost much <lfam>No worries! I'll send patches to guix-devel for master and core-updates shortly <habs>What's the recommended solution in guix for programs that use the read-only filesystem in /gnu/store for configuration, like claws-mail uses it for plugins? <lfam>habs: Most programs that use configuration files allow you to choose the location of the configuration files. So, we typically set that option to somewhere appropriate that is not read-only <habs>lfam: Hm, I think I can get around it, thanks. One more question, if a package wants the gtk+-2 dev files but guix uses gtk+-3, how can I install gtk+-2 separately without downgrading gtk+-3 using the @ syntax? <lfam>habs: I don't really understand how GTK software works. But typically an application built with Guix will link against a specific build of its dependencies in /gnu/store. <lfam>So, one application would link against a build of gtk+-2 and another against gtk+-3, as needed by each application <lfam>I don't believe it's usually necessary to install GTK in your profile with `guix package --install gtk` <habs>lfam: Actually I wasn't being too clear, what I meant was if I was trying to build a binary (in this case a claws-mail plugin .so file) from source code, and it depends on the gtk+-2 libraries <habs>I was able to get around that in the mean time by downgrading my gtk+ package to gtk+-2 though, thanks for your very helpful answers! <OrangeShark>habs: you can use a guix environment to just put gtk+-2 in your environment <OrangeShark>it useful for building software from source without having to install it in your profile ***edangor_ is now known as edangor