IRC channel logs


back to list of logs

<Apteryx_>Hi Guix!
<Apteryx_>I just installed binary version of Guix, and was wondering if it was possible to use host GTK resources without having to install them inside Guix? For example, on Ubuntu, the GTK theme is messed up in Guix GTK apps such as Emacs, because it can't find "Gtk-Message: Failed to load module "unity-gtk-module", for example.
<Apteryx_>Has anyone the GTK theme going on Ubuntu, or should I simply abstain from using Unity?
<Apteryx_>I just tried using the cinnamon WM instead, but it didn't help with the GTK theming issue.
<baconicsynergy>okay, I can totally confirm that the latest amdgpu driver and kernel won't play nice
<baconicsynergy>thats okay though, i hear 4.9.* will solve a lot of these problems
<buenouanq>there's one thing (perhaps the only thing) systemd did that I actually liked,
<buenouanq>a graphic session remained in the tty you started it in
<paroneayea>hi everyone!
<buenouanq>none of this antiquated tty7 default
<paroneayea>sneek later tell civodul I think davexunit knows a heck of a lot more about the container side of things than I do
<buenouanq>point is, I'd love to see Shepherd/GuixSD adopt this
<lfam>Funny mitigation suggestion from Red Hat for some recent bugs in gstreamer plugins:
<buenouanq>no computer, no computer problems ┐( '~')┌
<lfam>Exactly :)
<rekado>baconicsynergy: have you tried one of the older kernels we provide?
<rekado>looks like latest org mode breaks mu4e’s email capture feature.
<rekado>I tried to capture emails to org mode for keeping better track of them (rather than using the Inbox for this)
<civodul>Hello Guix!
<sneek>Welcome back civodul, you have 1 message.
<sneek>civodul, paroneayea says: I think davexunit knows a heck of a lot more about the container side of things than I do
<rekado>civodul: Hello!!
<cbaines>Good morning :)
<civodul>ACTION goes for coffee, most important things first
<rekado>about the distro track talk: I'd like to give a quick primer on functional package manage, show that having the whole dependency graph gets you close to having a full distro, and then show how it's done in GuixSD.
<rekado>also how easy it is to spin variants of GuixSD with different operating system configurations
<rekado>(compared to abominations like kickstart files)
<rekado>would be excellent to have a version of GuixOps ready for FOSDEM... :)
<civodul>rekado: the outline looks good to me!
<civodul>the variants of OS configs bits sounds cool
<civodul>i've always found it suboptimal that people had to fork complete distros to make Tails, FreedomBox, etc.
<civodul>re GuixOps, not sure we'll have that :-)
<civodul>but i do feel a growing need to use that to administer our build machines
<buenouanq>Guix and GuixSD have totally forced me to reassess the way I'd been trained to think about operating systems - And that we ever didn't do everything this way now seems absolutely appalling. In my head I've been calling it a meta operating system - Perhaps there's a better term, but I'd love to see others talking about and pushing it as such. It is so clearly the bright beautiful future of not only GNU,
<buenouanq>but package management and OSs in general, and in 5 years time, everybody is going to be [poorly] copying the work all you wonderful people are doing right now.
<buenouanq>I wish to see more Guix devs raving like maniacs about how awesome what they're doing is.
<civodul>woow, nice words ;-)
<civodul>but yeah, it's very different from what people are used to
<civodul>so it takes a lot of talking to get people to understand what it's about, and possibly to value it
<civodul>which is why it's a good idea to squat every possible devroom at FOSDEM ;-)
<Petter>I'd surprised if we don't have to go through the standard set of responses: "First they ignore you. Then they laugh at you. Then they fight you. Then you win."
<buenouanq>We're still in stage 1, possible even not to it yet.
<Petter>There's a lot invested in traditional ways of doing things, and it's hard to throw that away.
<jmd>How do applications in Guix search for default Xresource files?
<civodul>no idea
<civodul>same as on other distros?
<jmd>civodul: Yes, I think that is the problem.
<jmd>It searches in the same paths as other distros, but it wont find them there :(
<civodul>sneek later tell alezost inspiration: :-)
<sneek>Got it.
<jmd>civodul: It seems to me, that only xfontsel and xfd are the two programs which have resolved this problem.
<jmd>However if we do that with all programs, then it'll be ugly.
<jmd>Why don't we patch libxt instead?
<civodul>jmd: problem is, where would you tell libxt to look for that?
<jmd>civodul: Theres a config option:
<jmd>os something
<jmd>Or maybe we should just export XFILESEARCHPATH in operating-system-etc-service in gnu/system.scm
<htgoebel1>Hi guix
***htgoebel1 is now known as htgoebel
<htgoebel>I'm currently working on a script to mass-generate *draft* packages for KDE applications. Ca. 170 of them :-)
<htgoebel>The idea is to have a draft which can easily be taken and adopted. Inputs will be lists at best knowledge (taken from the CMakeLists.txt file). Synopsis and description are pre-filled from Debian and Mageia.
<htgoebel>Nevertheless 170 packages are a lot of work, which I would like to distribute.
<htgoebel>Should I push this into a wip-branch? Or hat else would be an option?
<civodul>htgoebel: a wip branch with a message on the list to explain the status etc. would be good
<civodul>nice work, BTW!
<civodul>just make sure you don't re-push the branch too often so we don't get N times 170 messages every day ;-)
<civodul>jmd: the problem of --with-xfile-search-path-default is that we wouldn't know what directory name to provide
<civodul>so i guess the env var is more likely to work, along with a paragraph under "Application Setup" for foreign distros
<civodul>send that to the list ;-)
<htgoebel>civodul: hopefully others will do the work :-) So I need to push only once - at the end
<civodul>often "others" keep lurking, so don't hold your breathe ;-)
<civodul>htgoebel: BTW, what's up with the Python branch?
<civodul>you need to tell us when it's ready to build
<jmd>civodul: ok. Will changes to gnu/system.scm need to go into core-updates or is master ok?
<htgoebel>civodul: the python-branch is ready since weeks. I asked Leo(?) to set up a hydra job and he told me, that he is the wrong one but will tell the hydra-admins.
<htgoebel>I'll just post a message on guix-dev now.
<civodul>jmd: master is ok: it does not trigger any rebuild
<civodul>(except OSes)
<jmd>ok. thatnks. I'll post to the list anyway first.
<jmd>BTW this explains the non-working of Xterm which I mentioned yesterday.
<civodul>great, thanks for investigating
<catonano>ng0: so the thing with CADET is a regression, is it ?
<catonano>ng0: I suppose that the deadline on thhe end of november will not be rrespected ?
<ng0>probably not, i don't know. I can understand the position of christian and I would not make a new release either. It would mean everything but -fs is broken. the best you can do is start working on the source :)
<ng0>gnunet-fs does not make use of cadet, so what others before me and now I am working on for guix, will not be affected by the current damage of cadet.
<ng0>we could even package the current head of gnunet and -gtk and have a somewhat functional gnunet, but only for -fs
<ng0>i think we should fix pybitmessage with patches to use qt5.. i'll ping the bug report again at upstream, but I think it's not one of their primary features to fix
<ng0>the luks system is still not done.. the problem is that all the big applications had to be rebuild, right now it is doing webkit-gtk for 10 hours already.. it's an old laptop
<rekado>re pybitmessage: do you have a patch for upstream? It's fine to add a patch to our package when upstream has a copy of the patch.
<jmd>Correct me if I'm wrong, but %outputs is an alist isn't it?
<ng0>rekado: no
<ng0>but there are applicaitons where I would add patches because comunication with upstream is (to put it very polite) hard
<ng0>as far as I understand it, qt4 no longer receives updates and they do not care about the issues with that
<rekado>do they have arguments against upgrading to qt5?
<ng0>"winxp support"
<ng0>where I told them it's there in qt5
<ng0>it's been weeks or months on the issue, so i'll check what's the status now and if I can get a definite yes, no, or targeted version when they'll get it in
<baconicsynergy>coffee time brb
<catonano>ng0: I beg pardon: what is Christian's position ?
<ng0>counter question: would you rather release something which breaks 40 features and go back to where you were years ago OR release something functional?
<catonano>youu said you share Christian's position not to make a release
<catonano>why not ? Was this CADET problem unexpected ?
<catonano>sorry I didn't read
<ng0>I think this is something which should be discussed in #gnunet and not #guix
<catonano>right. I apologize
<ng0>catonano: may I query you?
<catonano>ng0: sure
<weedsmoker23>Is it possible to install guixsd with full disc encryption? I couldn't find any reference to it in the manual and there doesn't seem to be an dm-crypt package in the package index.
<ng0>Yes! luks is possible now (not lvm) but requires documentation (I'm testing it at the moment and will document if no one else does it). see the latest emails on guix-devel regarding this by ludovic.
<weedsmoker23>thanks, i was just wondering before attempting to install it
<ng0>you also have to guix pull when you use the 0.11 medium before initing the system
<ng0>oh, it seems there is now documentation (in the git)
<ng0>ahhh. this is why the first attempt failed, I missed something in the config.scm
<ng0>well, i've got other work to do now. then I'll test again
<baconicsynergy>building ardour fails on my machine. can anyone replicate it?
<rekado>civodul: I submitted the proposal for the distro track at FOSDEM:
<rekado>I really hope that this submission was successful. My previous submissions to the Guile devroom didn’t appear until Pjotr did something.
<rekado>the title is a bit clunky: “From functional package management to declarative system distributions: How functional package management influences distribution design”
<rekado>shorter alternatives are welcome!
<ng0> can someone apply this trivial patch?
<civodul>rekado: i'm "not allowed to see this event"
<civodul>oh, i can actually see it from another path
<civodul>rekado: LGTM!
<civodul>thanks for submitting it
<civodul>AFAICS the submission is all right, in the right track, etc.
<baconicsynergy>rekado: im about to try to work with linux-libre-lts for the time being unless 4.9 fixes the issue
<baconicsynergy>sorry that was a delayed response
<ng0>civodul: success with luks! i needed to add the (properties mapped-devices)
<baconicsynergy>woop woop
<ng0>awesome work fixing this up!
<lfam>civodul: Good news for us:
<civodul>lfam: woohoo!
<civodul>thanks for pinging them
<lfam>civodul: While you're here, do you think know is a good time to build the python-build-system branch?
<civodul>ng0: great, thanks for your feedback!
<civodul>lfam: i think so, yes
<ng0>i posted it to the thread aswell
<lfam>civodul: Okay, I'll try my hand at setting it up
<civodul>funny VM crash here:
<civodul>never seen that before
<lfam>civodul: How many shares should I give to the new jobset?
<civodul>lfam: i never understood that parameter, just leave the default
<civodul>maybe mark_weaver knows
<civodul>lfam: also, please rebase it on master before starting the jobset
<lfam>Okay, the default is empty. I can make it 100, which is 50% of 200 shares, which is what the core-updates jobs use
<lfam>Okay, I'll rebase it
<ng0>next I try the network-manager service
<lfam>civodul: I'd rather merge master -> python-build-system, to preserve the commit signatures. WDYT?
<civodul>lfam: yes, that's fine too
<lfam>Okay, I set it up as a "one-shot" evaluation for now
<paroneayea>hi hi
<paroneayea>morning, friends
<civodul>hey paroneayea!
<baconicsynergy>man, i wanna use the hurd as my primary kernel already
<baconicsynergy>its so close. all it needs is sata and sound support for me to be able to use it
<paroneayea>hi civodul
<baconicsynergy>how can i declare a specific version of linux-libre to use in my os declaration?
<baconicsynergy>would i use (kernel "linux-libre-4.4.33")?
<jmd>baconicsynergy: Probablly (kernel "linux-libre@4.4.33")
<jmd>but that's just a guess.
<paroneayea>ACTION nearly writes a "If only POSIX capabilities were real capabilities, we wouldn't be having this problem! :)" to the list in reply to an email, and desides that's too much of a peanut gallery comment even for him ;)
<dale`>NOOB here. What is the way in GuixSD to install a system package? E.g. I want all users to have emacs available without each of them individually doing a `guix package --install emacs'?
<baconicsynergy>add 'emacs' to the (use-package-modules...) field at the top, then add emacs to the package declaration under (operating-system
<dale`>The top of what?
<baconicsynergy>of your config.scm, my apologies
<dale`>Is this /etc/config.scm in particular?
<dale`>Brilliant, thank you very much.
<baconicsynergy>no problemooo
<baconicsynergy>you can find out which module a package belongs to by using 'guix package -s'
<baconicsynergy>it'll show you the *.scm module
<baconicsynergy>i still can't find out how to set a particular kernel version in my config. can anyone point me in the right direction?
<quiliro>is there a scm file for a working desktop environment
<quiliro>by the way...congratulations for the project
<quiliro>i am great fan
<baconicsynergy>there is a sample config on the install media under /etc/configuration/desktop.scm
<baconicsynergy>it included desktop sessions for both gnome and xfce
<baconicsynergy>jmd: adding @4.4.33 to linux-libre didn't work :o any other ideas? :)
<baconicsynergy>my guile/scheme is weak
<quiliro>baconicsynergy: i have tested them...they have not given a working desktop before...6 months or so ago
<quiliro>baconicsynergy: thank you for your input
<alezost>sneek: later tell baconicsynergy you need to use a variable, not a string, so it should be: (kernel linux-libre-4.4)
<sneek>Welcome back alezost, you have 1 message.
<sneek>alezost, civodul says: inspiration: :-)
<sneek>Will do.