IRC channel logs


back to list of logs

<paroneayea>there's an interesting idea...
<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
<paroneayea>see if install on debian still works
<civodul>davexunit: makes sense
<civodul>paroneayea: that's doable, in fact Nixpkgs has (used to have?) stuff to do things like that
<paroneayea>civodul: interesting!
<civodul>it's a bit heavyweight tho
<civodul>ACTION -> zZz
<civodul>good night/day!
<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
<davexunit>ACTION has to go afk
<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->how to break this?
<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
<civodul>but otherwise no
<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?
<civodul>ak5: maybe ?
<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"
<amz3>héllo :)
<rekado_>iyzsong: wow, how come I missed it?
<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
<iyzsong>ah, ok
<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
<davexunit>sounds a bit scary :)
<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?
<davexunit>ooh new xfce stuff.
<davexunit>ACTION reconfigures quickly before work
<civodul>rekado_: no, no conflict
<civodul>in practice the "combined work" is necessarily GPLv3
<civodul>but yeah, it's OK to leave GPLv2+ as the license field
<rekado_>civodul: ok
<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_>checking the R manual next
<rekado_>seems that only environment variables are configured at build time. No other effects are mentioned.
<civodul>rekado_: ok
<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>texlive is terrrrible
<davexunit>it's quite the monster
<civodul>the monolithic monster: you can't even cut its arms or legs
<efraim>it takes about 5GB of space while being built
<civodul>or even more than that
<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>IOW, nothing is gained
<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 :-)
<paroneayea>civodul: wow, why so big for texlive?
<paroneayea>is it because of all the TeX macro expansion?
<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
<taylanub>ACTION gotta start learning those Kanji
<civodul>paroneayea: i think there's 3G of fonts, and then a whole lot of TeX packages
<civodul>plus documentation in PDF
<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>(and a backtrace)
<ArneBab>is that known or should I pastebin the error?
<ArneBab>there might be leftovers from a previous installation.
<ArneBab>it works for root…
<ArneBab>hm, because the user profile is empty…
<ArneBab>sorry for the noise…
<civodul>np :-)
<civodul>damn it, we're losing hydra
<davexunit>what do you mean?
<mark_weaver>civodul: what do you mean?
<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>?
<ArneBab>I have to ln -sf something…
<mark_weaver>it should be created automatically, iirc
<davexunit>ACTION can't reach, worries.
<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 on, maybe hydra's one of those machines?
<ArneBab>I get this error when using guix package -i sed as untrusted user:
<davexunit>efraim: i don't see such a notice
<davexunit>they must have forgotten to message "Public"
<davexunit>and just messaged followers
<efraim>"We are having some downtime on machines including the domain and emailselfdefense and"
<efraim>ah, could be
<davexunit>ACTION tries to recall if those are hosted at MIT
<efraim>yeah, it does say only CC:Followers
<nully>there was an outage
<efraim>i can ping now
<nully>hydra is on itsway back up
<nully>we lost the entire physical host.
<davexunit>nully: sorry to hear that.
<nully>hehe, but we be good now :3
<nully>eh, thats life, eh?
<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
<davexunit>cull the cruft? ;)
<nully>srsly dude, you tryingto put me out of work?
<nully>ACTION giggle snorts
<davexunit>efraim: he's in the wrong country :)
<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
<davexunit>haha I never noticed that
<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?
<paroneayea>how's #guix?
<paroneayea>civodul: wow! that's a lot of fonts...
<davexunit>hey paroneayea
<davexunit>things are guixy
<paroneayea>hi davexunit !
<paroneayea>yay for guixy
<ArneBab>mark_weaver: I installed guix via the binary method this week, but it seems that something is broken
<codemac>Is hydra down?
<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, you have 1 message.
<sneek>wingo, ArneBab says: could you msg me when you have a few minutes?
<ArneBab>wingo: yay, you’re back!
<wingo>yeah sorta :) i alwauys did irc from my laptop but have not been happy with guixsd since may :P
<civodul>nully: thanks, nully!
<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
<davexunit>containers will be a lot faster.
<wingo>and the resolution is never right
<davexunit>much less to do.
<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>selfish wingo
<civodul>np :-)
<davexunit>fwiw, my comment wasn't a major gripe.
<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?
<davexunit>okay, makes sense.
<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
<davexunit>that's true.
<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 ...)
<wingo>where FORM := (STRING EXPR)
<davexunit>wingo: a-ha, civodul suggests define-record-type*
<davexunit>which has syntax for required fields
<wingo>ah yeah that works too
<wingo>ACTION will do that
<davexunit>with that done, I'd say it's good to push.
<davexunit>one big step closer to GNOME
<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>what about GDM?
<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
<wingo>another thing
<wingo>so i installed epiphany
<wingo>but it looks *terrrrrrible*
<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>wingo: re theming, that's weird
<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>i,i: guixbuntu, guix for human beings
<paroneayea>feel free to read that nonsense statement any way you want ;)
<wingo>civodul: evince's fonts aren't great for me either
<wingo>icons, etc
<wingo>perhaps you have the packages davexunit mentioned installed already
<civodul>ah, maybe
<davexunit>oh yeah there's that, too.
<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...
<civodul>indeed :-)
<davexunit>having GNOME should be a huge improvement
<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
<davexunit>ACTION braces self
<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
<wingo>i want profiles
<davexunit>differentiate between "I want the inputs of this package" vs. "I want these packages"
<wingo>which is great that guix does that :)
<civodul>yes, that's definitely useful too
<davexunit>I use environments 100% of the time.
<davexunit>but yeah profiles are cool, too. ;)
<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.
<davexunit>perhaps a --profile option would be useful?
<davexunit>or something to freeze the environment
<wingo>yeah maybe...
<wingo>but it starts to conflict with guix package now ;)
<wingo>don't cross the functional taxonomy streams! ;-)
<davexunit>well only in that it can make a profile
<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>I think something like that would work
<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>clang for example
<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.
<davexunit>er, wingo:
<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
<wingo>maybe not, dunno
<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'
<civodul>and there i can choose when i pull
<civodul>so it works well in that context
<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>so 1 second to startup doesn't bother me.
<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>yeah that's still the case
<wingo>so weird
<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
<civodul>by libpulse-client i guess?
<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
<civodul>wingo: no, just in my profile
<civodul>and my user is in the "audio" group
<wingo>mine too
<wingo>i start pulseaudio as my user, fwiw
<civodul>but i have .asoundrc with:
<civodul>pcm.!default {type pulse}
<wingo>mmm hmmm :)
<wingo>fwiw this is with rhythmbox
<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>i also have dbus in my profile
<civodul>maybe applications do system("dbus-launch foo")
<davexunit>here's my config, for good measure:
<wingo>does gnome-themes-standard conflict with gtk-icon-themes?
<wingo>sorry, i misunderstood
<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
<civodul>wingo: LGTM!
<wingo>thank you! may i push those two commits to master?
<civodul>i think so, yes!
<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
<paroneayea>it does sound like it :)
<davexunit>guixsd and debian would conflict for sure
<davexunit>/etc, /boot, /bin/sh, etc.
<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
<paroneayea>wingo: ah :)
<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! :)
<wingo>oh right
<wingo>yeah give it a go :)
<wingo>you can be user #2
<davexunit>awesome. I have a bit more time on the work clock.
<davexunit>but after.
<davexunit>I'll give it a whirl.
<davexunit>I like being able to fearlessly try new configs
<davexunit>knowing I can roll-back
<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.
<wingo>magit 2 is weird
<paroneayea>davexunit: live cds? ;)
<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>ACTION is also a stick in the mud
<davexunit>a stick in the mud working in hipster web dev land.
<davexunit>a bit of a clash.
<davexunit>"nooo don't add a node dependency, I beg you!"
<civodul>ACTION is getting used to magit 2
<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
<civodul>close your eyes and hit RET
<davexunit>bye-bye productivity
<civodul>it wasn't that bad for me
<davexunit>magit is such an essential part to my workflow that any change scares me. :)
<civodul>oh except the "rewrite" thing which is gone
<davexunit>I don't think I ever used that
<paroneayea>oh! so, here's a #guix heresy for you
<paroneayea>ACTION prepares to be thrown from the channel!
<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 hadn't thought of this
<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
<paroneayea>... or something!
<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
<paroneayea>davexunit: :O
<paroneayea>davexunit: ah, that's sad
<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
<paroneayea>could be done here for deb/rpm/etc
<davexunit>yes, that would essentially be what would happen
<davexunit>that directory packaged up in a .deb
<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. :)
<davexunit>packages are code, not archives.
<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 :)
<paroneayea>wingo: well, that would be interesting ;)
<wingo>how much of a sticker is the fhs reall?
<wingo>i mean /run is totes new
<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
<civodul>other than that it looks good
<civodul>thanks for writing the doc as well
<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
<civodul>oh yes, right
<wingo>yeah so the logind in master is mostly only useful for handling the lid :P
<wingo>without being told things by it's kinda silly
<civodul>that's a good start :-)
<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 :)
<davexunit>we do not do that :)
<wingo>ok, /me zz. tx for all the review and goodnight :)
<wingo>ACTION shuts laptop lid, heh heh heh
<civodul> is the slowest machine i've used over the last years
<civodul>(which is unfortunate)
<Steap>civodul: we should get a partnership with Intel and buy a Skylake CPU :)
<civodul>i guess it has AMT++?
<mthl>civodul: texinfo done! (I hope)
<sneek>Welcome back mthl, you have 1 message.
<sneek>mthl, civodul says: cron/systemd vs. mcron/dmd ->
<civodul>mthl: excellent!
<mthl>civodul: thanks for the github link!
<civodul>food for thought :-)