<paroneayea>my friend asheesh mentioned they have a package to test that their install instructions still work in debian and they test it against a CI server <paroneayea>hilariously, I wonder if we could make a guix expression to do this <paroneayea>build a qemu image and run debootstrap or the like inside of it <civodul>paroneayea: that's doable, in fact Nixpkgs has (used to have?) stuff to do things like that <bishopj>are there any guides for setting up guix on system upon which you do not have root access? <davexunit>bishopj: that's not a well-supported use-case right now, though we'd like to improve there. <davexunit>we have a couple of hackers trying to push forward with that <bishopj>Is atleast viable for making such things such emacs-nox and git? <rekado->I think we have a dependency cycle somewhere. Maybe only in my working directory after adding shotwell. <rekado->yup, there's a cycle after adding "rest". <rekado->that's in "gnome.scm". It needs "nss-certs" in "certs.scm", which needs "nss" from "gnuzilla.scm", which again refers to "gnome.scm". <rekado->I guess I could disable certs in "rest" and hope that it still works at runtime. <rekado->I wished Guile produced clearer error messages in general. <civodul>rekado-: what's the problem/backtrace you're seeing? <civodul>module cycles should be fine, we have lots of them already <rekado->it disappeared when I removed the import of the "certs" module from "gnome" again. <rekado->to do that I had to configure "rest" with "--without-ca-certificates". <rekado->ACTION has to leave now, will be back later <civodul>rekado-: could you eventually send the diff? <civodul>adding #:use-module (... certs) alone doesn't seem to cause this <rekado_>maybe it's related to actually referencing a variable from certs? "rest" had "nss-certs" as input. Only after I removed that and the "certs" import did "make" continue. <civodul>yes, variable references from the top-level cannot work if there are circular deps <civodul>they can be referred to in 'inputs' & co., because these are actually thunks <rekado_>well, in that case I don't know what's going on. <rekado_>still, I think it makes sense to build "rest" without a system CA store and make it pick up at runtime whatever certs the user has installed. <ak5>hi, I am trying to find some docs for declarative package mgmt <civodul>rekado_: could you paste the diff that leads to the error? <ak5>civodul: I meant specifically where to declare and the "scheme dsl" that entices me , I am coming from nixos and understand the concept.. <rekado_>civodul: I can't do it today, unfortunately. It happened in my dirty working directory with lots of patches that aren't yet upstream. I do think that just applying the patch for "rest" (part of my shotwell patch set) should be sufficient to reproduce it, but I cannot (at the moment) try it myself. ***frob is now known as Guest16729
<ak5>hmm this is just too painful for china <iyzsong>rekado_: hi, I did package 'rest' as librest. <civodul>ACTION wonders why ak5 wrote "this is just too painful for china" <rekado_>I seem to be doing this much more often than I should. It's not the first time I repackaged something by accident :( My rgrep foo must be failing me. <rekado_>in this case I'll retract my "rest" patch and change shotwell to use iyzsong's "librest". <civodul>better than grep: 'guix package -A rest' :-) <iyzsong>well, maybe I should just use the name 'rest', I forget why choose 'librest' :- <civodul>the upstream name appears to be 'rest', so yes, we should rename it <civodul>ACTION pushed a fix for the libc 2.22 upgrade \\o/ <davexunit>civodul: oh wow you found something that works? <civodul>basically an additional layer of packages plus a hack <rekado_>I really should be using the Emacs interface then to search for existing Guix packages, but using rgrep is a hard habit to break. <davexunit>I confess that I haven't yet figured out all the things to do with guix.el <rekado_>civodul: re your comments to the ggplot2 patch series: all the GPL-licensed packages are "gpl2+", not "gpl3+" as R itself. There is no license conflict is there? <civodul>in practice the "combined work" is necessarily GPLv3 <civodul>but yeah, it's OK to leave GPLv2+ as the license field <rekado_>re R+IcedTea: I'm checking with our local R experts to figure out if we can remove IcedTea from the inputs without breaking common packages. <rekado_>it seems that the few Java/R packages depend on rJava, a separate package using Java at runtime only. <rekado_>so it may actually be okay to remove IcedTea from the inputs there. <rekado_>seems that only environment variables are configured at build time. No other effects are mentioned. <civodul>well i guess it provides *some* functionality <civodul>the question is more how many people it would hurt to not have it by default <rekado_>my local R guru is only aware of packages using "rJava". <rekado_>but I'll continue to investigate and send a patch when it's clear what the effects are. <rekado_>texlive could probably be removed without problems. It's only used to compile the vignettes for base packages. <civodul>the monolithic monster: you can't even cut its arms or legs <efraim>it takes about 5GB of space while being built <civodul>because at one point there's the source tarball in /gnu/store, the unpacked tarball in /tmp, and the thing being installed in /gnu/store <rekado_>other distributions did split it up into several optional packages. Is this not possible when installing into separate output dirs? <rekado_>(I mean: does this only work because they drop stuff in shared mutable directories?) <rekado_>do we actually *need* texlive as provided or could we add a CTAN importer and import modules as needed? <civodul>rekado_: it's a complex thing, but basically, you could split, but then things refer to one another <civodul>Andreas spent a lot of time looking at this <civodul>i don't remember all the details, i mostly remember that it's horrid :-) <davexunit>I often see tweets about Guix in japanese that I cannot read and I wish I could. <taylanub>I might be able to read them if they're written in toddler-level Japanese :P <civodul>paroneayea: i think there's 3G of fonts, and then a whole lot of TeX packages <ArneBab>I tried the binary installation method of guix (not -SD), and I get this error when running guix package: ERROR: bootstrap binary not found "guile-2.0.7.tar.xz" "x86_64-linux" <ArneBab>is that known or should I pastebin the error? <ArneBab>there might be leftovers from a previous installation. <ArneBab>hm, because the user profile is empty… <ArneBab>how do I create a profile for my non-root user? <mark_weaver>ArneBab: just start installing packages with "guix package -i" <ArneBab>even if there’s no directory named /var/guix/profiles/<user>? <ArneBab>even if there’s no directory named /var/guix/profiles/per-user/<user>? <efraim>doesn't mention creating or symlinking /var/guix/profiles/per-user/<user> so it should be automagic <efraim>there's some downtime according to fsfstatus@pumprock.net on pump.io, maybe hydra's one of those machines? <davexunit>they must have forgotten to message "Public" <efraim>"We are having some downtime on machines including the libreplanet.org domain and emailselfdefense and wiki.swpat.org" <davexunit>ACTION tries to recall if those are hosted at MIT <efraim>yeah, it does say only CC:Followers <nully>we lost the entire physical host. <nully>if they didn't go down, what would i do? o.0 <efraim>i imagined civodul typing the message and running out a door for the server room <nully>srsly dude, you tryingto put me out of work? <davexunit>ACTION pictures nully intentionally severing fiber optic cables to data centers <nully>you'll never catch me in the act! <efraim>I should've known better, his email headers include X-Revolutionary-Date <mark_weaver>ArneBab: that backtrace refers to guile-2.0.7, which we haven't used in guix in a long time. what version of guix are you using? <ArneBab>mark_weaver: I installed guix via the binary method this week, but it seems that something is broken <bavier>codemac: it appears there was a server outage <alezost>ArneBab: <ArneBab> there might be leftovers from a previous installation. ← I think this may be the problem. Make sure that you deleted the old version completely <davexunit>iyzsong: the xfce pulseaudio panel icon doesn't show up for me. it shows the "I can't find an icon for this" icon. does it work for you? <sneek>wingo, ArneBab says: could you msg me when you have a few minutes? <wingo>yeah sorta :) i alwauys did irc from my laptop but have not been happy with guixsd since may :P <wingo>davexunit: i was warned and didn't pay attention :) <wingo>nixos on another system has been fairly painless tho <davexunit>I've been quite happy with my guixsd setup for several months now. <wingo>so i wanted to follow up about elogind and polkit and whatwhat <wingo>what's the status? i need to fix the config thing or can i do that in a followup? <wingo>that's the other thing about working on the "sd" part of guix, interminable reboots make me lose my hackplace <davexunit>civodul: not sure if you saw the mail about elogind. wondering what you thought about that. <davexunit>wingo: you reboot your system to test services? I would recommend trying a VM. <davexunit>containers will be even easier soonish, but maybe by then dmd will be smarter. <wingo>i do that sometimes but it takes for friggin ever <wingo>and there's that damned lsh thing <wingo>and the resolution is never right <wingo>if it were in a terminal it would be easier <davexunit>though testing graphical services would be an issue <wingo>hah, if only i were there yet :P <civodul>wingo: oh lemme look at your messages <civodul>FWIW i use 'guix system vm' to test these things <wingo>tx! sorry to bother, i just wanted them off my queue ;) <wingo>yeah i understand what it's about <wingo>keyword arguments + abstraction + composition can be a pain :P <davexunit>maybe we can refactor later, but we all know that sometimes later doesn't come. ;) <wingo>there's some nicer abstraction lurking there <wingo>(ini-file ((Login (FooBar foo-bar int) (Baz baz string) ...) (Sleep (Thingie thingie non-negative-integer) ...))) or something <wingo>but that basically means inlining the ini creation into the user-facing procedure with the kwargs <wingo>so it's not really solving the composition problem, just working around it by having a macro make it more concise... <davexunit>I thought that an sexp->text-file type procedure may be nice. there could be a mapping from keys to serializers <davexunit>the sexp keys could either be the actual strings or symbols. the mapping would need additionally need to include the symbol->string translation for the latter, though, which may be an abstraction too far for this. <wingo>that could be ok but the duplication would be similar, and you wouldn't be guaranteed to reify values for all keys <wingo>i was just trying to prevent future refactoring hazards, dunno <wingo>forgetting to relay a keyword argument would be pretty irritating <davexunit>wingo: why do you need that guarantee if the public procedure already guarantees that each config option has a value? <davexunit>so it's more for your (or whoever else touches it later's) sake? <wingo>yeah it's because i don't trust anyone including myself to refactor it correctly :) perhaps that's too pessimistic :) <davexunit>wingo: and keyword arguments are preferred over regular required arguments to avoid issues around ordering, yes? <wingo>yeah i don't trust anyone at all to pass 20 arguments in the right order ;) <davexunit>wingo: you know, maybe one of my issues is partly cosmetic. that syntax doesn't represent keywords as keywords, but regular symbols. <davexunit>it made the define form a bit hard to parse from my perspective. <wingo>neither does (define* (foo #:key bar) ...), does it? <wingo>but if you have define-three-complicated-words-here then the indentation gets wonky <wingo>maybe lambda-with-required-arguments would be better <wingo>(especially wonky with multiple kwargs) <davexunit>since I don't have a solid suggestion to rewrite the damn thing, I say "leave as is", unless civodul comes up with something. <wingo>actually lemme see if i can do a (ini-file FILE-NAME STRING-OR-FORM ...) <davexunit>wingo: a-ha, civodul suggests define-record-type* <wingo>yeah from there we can get gnome-session i think <wingo>and with mark's networkmanager stuff we can then get gnome-shell <davexunit>ACTION has no idea about how GNOME fits together <wingo>not sure what gdm's deps are but it's not necessary for gnome, it's just a greeter <davexunit>wingo: would having GNOME get you closer to actually liking GuixSD? <wingo>it's my primary browser on other systems <wingo>but on guix it just looks like pants <wingo>one thing is the icons -- there are none <davexunit>wingo: have you installed gnome-themes-standard and gnome-icon-theme? <wingo>and the theme looks like 1995 called and wanted its bevels back <wingo>prolly not, thanks for the tip! <davexunit>wingo: when we have a 'gnome' package, I imagine those will just be included <davexunit>they probably should be with xfce, honestly, but I don't know how to make them the default themes used vs. xfce's not-so-pretty fonts <wingo>yeah these sorta cross-cutting concerns are frustrating <wingo>"x doesn't do what you want? install y which is not in its dependency set" <civodul>i was always "surprised" to get nice themes in Evince in such on GuixSD :-) <civodul>dunno why that doesn't work with epiphany <paroneayea>feel free to read that nonsense statement any way you want ;) <wingo>civodul: evince's fonts aren't great for me either <wingo>perhaps you have the packages davexunit mentioned installed already <davexunit>perhaps our 'xfce' package should include some of these things <wingo>ACTION installs the adwaita theme too <wingo>one ongoing frustration is resolution. on gnome i can set the magnification &c. this laptop has some high-res screen that's not quite 2x the resolution, but without a central control center, it's pretty random what ends up happening from app to app. <civodul>GuixSD: letting users learn things they'd rather ignore <wingo>yeah, hopefully that motto can be retired one day... <wingo>incidentally civodul and davexunit since you're here and both recommended guix environment to me :) <wingo>i didn't know about --ad-hoc, cool, though all environments seem ad hoc to me <wingo>i like the tool and when i'm developing guix or anything i intend to run on the latest guix it's great <civodul>you mean the option name is confusing? <wingo>but when i'm developing something else that's really complicated and has its own churn rate, <davexunit>wingo: perhaps the name could be changed, but the idea is to differentiate between ' <wingo>i want to use guix to fix the deps of the thing i'm working on <davexunit>differentiate between "I want the inputs of this package" vs. "I want these packages" <wingo>which is great that guix does that :) <wingo>but it's also why, when developing things that aren't guix, guix environment is less useful to me <wingo>because i want to know that if something was working in the past but is not working now, it's because it changed, not because the packages installed by guix environment changed. <wingo>but it starts to conflict with guix package now ;) <wingo>don't cross the functional taxonomy streams! ;-) <wingo>ACTION still thinks a separate guix install command is a good idea ;) <civodul>a useful thing would be able to "tag" guixes, after a guix pull <wingo>ACTION lots of ignorant opinions <civodul>so instead of having ~/.config/guix/latest, you could have several of them <davexunit>but to me, the packages that compose the environment + the version of guix fully covers reproducibility. <civodul>and then you could do "guix --last-week environment foo" <davexunit>the guix client needs to become part of the environment <wingo>davexunit: but in order to build some things i need to be using guix from git <wingo>for which i have some unpushed patches still, oh wells <davexunit>civodul: yes, and this is where I think something like what civodul suggested would be nice. <wingo>civodul: yeah that would be really nice. kinda like git branch but for your history. <civodul>sorta like profile generations, but for guix itself <wingo>could be expensive to reify if you are working from git <davexunit>I really want 'guix environment' to be a killer feature <civodul>yeah i'm just thinking about 'guix pull' <wingo>ah i've never used guix pull <davexunit>because I think it is, but obviously needs more work to convince others. <wingo>mark told me not to and i am very obedient as you know :-)) <civodul>i use 'guix env' on CI build machines at work, where i only rarely run 'guix pull' <davexunit>wingo: 'guix pull' has some flaws that need fixing <wingo>davexunit: one more thing about guix environment -- it's slower than entering a profile. <wingo>dunno if guile 2.2 will help here, i would think it would but who knows <wingo>tho guix talking to the network all the time is not so nice for speed <davexunit>yes, because has to compute the environment from the given packages, which takes time. <davexunit>but I leave my environments up for long periods of time <wingo>davexunit: it should be faster :) <davexunit>it's already been optimized once, thanks to civodul. <wingo>i'm not saying it's bad, i rather like it :) <wingo>but i do think it's slow and should be faster. but again /me opinions blablabla <wingo>ok going to log back in, maybe the themes will be nicer <civodul>we should probably do optimization passes in various places <wingo>had to edit xfce's settings away from the horrible raleigh but hoo, much better <davexunit>I wonder if there's a file that can be stuffed in /etc to change the default xfce theme so users don't have to set it themselves. <davexunit>civodul: and yes agreed re: optimization passes <davexunit>I guess we could throw (statprof) at 'guix environment' and see what is the hold up. <wingo>also!!! who is responsible for starting pulseaudio? <wingo>for months i thought sound was just broken <wingo>i never heard the speakers on this computer, as it was new when i installed guix on it <davexunit>pulseaudio is one of things that "just worked" for me <wingo>turns out i just needed to start pulseaudio, manually for some reason <wingo>davexunit: another thing to do would be to strace guix environment and make it do less io -- dunno if it is io or cpu time <davexunit>wingo: my hunch is cpu time, but using strace would certainly help us know for sure. :) <davexunit>can strace measure the amount of time spent doing various things? <daviid>wingo: maybe you know but in case it help0s, on debian pulse has a daemon.conf and friends in /etc/pulse <daviid>iirc there is a 'per user' or global pulse option setting somewhere <ArneBab>I like it that Guix pushes the auto-compilation system of Guile. That’s dogfooding how it’s needed to build big applications in Guile. <civodul>wingo: pulseaudio is automatically started for me <wingo>maybe i don't have pulseaudio installed system-wide <civodul>it doesn't need to be installed system-wide <wingo>civodul: is it installed system-wide for you? <davexunit>I do have pulseaudio system-wide, not sure if that really makes the difference. <wingo>that would create the /etc/foo for pulseaudio <wingo>i start pulseaudio as my user, fwiw <davexunit>pulseaudio is running as my user and I didn't have to tell it to <wingo>it shows as playing but nothing comes out the speakers, unless i start pulseaudio in which case all is swell <civodul>maybe applications do system("dbus-launch foo") <wingo>does gnome-themes-standard conflict with gtk-icon-themes? <wingo>civodul: just installed dbus, i think it was installed before but it's hard to tell in the spew :P <wingo>ACTION reboots to see if his config works <davexunit>civodul: I think if we can make dmd REPL server friendly, then we'd also solve or partly solve the having to reboot after reconfigure issue. <wingo>davexunit, civodul: updated wip-elogind. if you do a git fetch and then examine 1b13da363e5810622eb743806ee8f652583e259d you will see the updated elogind service definition. wdyt? <wingo>that hash is a commit, you can look at it in gitk or whatever <wingo>thank you! may i push those two commits to master? <wingo>and thank you again for the theming hints civodul and davexunit, it is so much nicer now <paroneayea>btw is anyone here dual booting guix and debian from the same partition? <paroneayea>I'd be curious to know if there are any conflicts <davexunit>from the same partition? that sounds like a recipe for disaster <wingo>paroneayea: i tried with nix and it didn't work <wingo>because of conflicts in /etc and /var and the like <civodul>yeah, GuixSD would override stuff in /etc <wingo>civodul: pushed, thank you :) <davexunit>wingo: so I should be able to reconfigure, reboot, and have suspend working when I close the laptop lid? <wingo>davexunit: if you add (elogind-service) to your services, yes! <davexunit>wingo: but it's part of %desktop-services so it should be magic! :) <davexunit>awesome. I have a bit more time on the work clock. <davexunit>I like being able to fearlessly try new configs <wingo>not sure how you could wedge your system and not be able to roll back, but i haven't found it yet <wingo>quite pleasant in that regard <davexunit>if the grub installation got messed up that would bork everything. <davexunit>not sure what safeguards we have around that. <davexunit>wingo: so I've heard. I'm scared to update. :x <wingo>i didn't even like the new 1.x magit <wingo>ACTION needs to be less of a stick in the mud <davexunit>magit 2 is supposed to fix some of the performance issues I've run into, though, which is nice. <davexunit>a stick in the mud working in hipster web dev land. <davexunit>"nooo don't add a node dependency, I beg you!" <civodul>but some things are too "gitish" for me <davexunit>I'm just going to have to dive in and start using it <davexunit>which will probably be when I next run 'guix package -m' without realizing the implications <davexunit>magit is such an essential part to my workflow that any change scares me. :) <civodul>oh except the "rewrite" thing which is gone <paroneayea>I was talking with a friend about why guix will probably never be packaged in Debian because /gnu/ violates the FHS and though a user could do /var/gnu/ they couldn't benefit from mainline hydra <paroneayea>and said friend said "what's the chance that guix might switch to such a directory for mainline then, so as to get guix more easily adopted in other distros?" <paroneayea>I suspect it will be looked down upon as a suggestion here but <paroneayea>it might do well to advance the spread of guix much faster <davexunit>paroneayea: one issue, which is really silly and not our fault, is the crazy restrictions on shebang lengths <davexunit>adding even an extra 4 characters to the store path could cause breakage <davexunit>I believe we're restricted to 127 characters <davexunit>also, we could provide our own .deb/.rpm/.whatever files for people to install <paroneayea>davexunit: yes that's true, it may be a good idea <paroneayea>davexunit: I wonder if something similar to the gexp that builds the binary tarball which civodul wrote <davexunit>yes, that would essentially be what would happen <davexunit>I don't know much about the deb file format though <davexunit>at work I use a tool called 'fpm' so I don't have to think about it at all. <davexunit>I just tell fpm to bundle up directories as deb archives <rekado->heh, I also rather learned how to use fpm than to learn deb a couple of years ago, <rekado->later learned rpm for the RHCE exams. <davexunit>it's really great that no such tool is necessary for guix. :) <wingo>civodul: ptal at e31c07961df4a44969deff9724a47aceb1bf95cd when you have a chance; does it address all your feedback re: polkit? <wingo>that commit and the modifications to the previous ones, obvs <wingo>modulo polkit dirs and static/dynamic scoping <wingo>i would be fine either way but we can patch it up lates <wingo>paroneayea: fwiw i would think that if guix became popular enough we could get the fhs to add /gnu :) <wingo>how much of a sticker is the fhs reall? <civodul>wingo: i think there's a typo in the @uref for PolKit (missing comma) <wingo>civodul: odd, i did build it and look at it in info, must have missed that <wingo>np, thank you for the review <wingo>will push up to the doc patch with fix <wingo>then eventually will fix the pam mess <wingo>yeah so the logind in master is mostly only useful for handling the lid :P <wingo>without being told things by pam_elogind.so it's kinda silly <civodul>paroneayea: i think the binary tarball lowers the barrier of installation, which in turn reduces the need for Debian packages <wingo>the curl | sh school of adoption :) <wingo>ok, /me zz. tx for all the review and goodnight :) <wingo>ACTION shuts laptop lid, heh heh heh <civodul>hydra.gnu.org is the slowest machine i've used over the last years <Steap>civodul: we should get a partnership with Intel and buy a Skylake CPU :) <mthl>civodul: texinfo done! (I hope) <sneek>Welcome back mthl, you have 1 message. <mthl>civodul: thanks for the github link!