IRC channel logs


back to list of logs

<ng0>i try packaging mumble, because that's one of the last things I need to participate in team work again
<ng0>not that I need it, but it's nice to be able to join the weekly meetings
<albertoefg>hello anywan wants to play
<albertoefg>libre game night :)
<albertoefg>in half an hour
<albertoefg>this week we are playing openTTD
<ZombieChicken>libre game night?
<ng0>we have much qt-5, but what happened to qt4? when I need qtsvg for qt4, it just gets detected or how does this work?
<ng0>seems so
<rekado>qt4 isn’t maintained anymore
<ng0>mumble (and some other applications) don't use qt5 yet
<ZombieChicken>One day someone will write a Mumble client that is CLI and life will be good
<ng0>oh, new gnupg release
<albertoefg>ZombieChicken: yes :)
<albertoefg>you can join us on #lgn
<albertoefg>we are about to play
<albertoefg>we play only Free Games
<ZombieChicken>albertoefg: this a weekly thing?
<albertoefg>yes :)
<albertoefg>we play every week a different free game
<ZombieChicken>I'll make an note of it, but probably won't be able to join
<albertoefg>everything week at a different time so anyone can join
<albertoefg>you can check
<albertoefg>ar join us on freenode #lgn
<paroneayea>I'd like to look at the ssh config file generatd by guix system
<paroneayea>I'm not sure where I'd find it
<davexunit>so... our openssh-service doesn't work... because openssh-service isn't defined.
<davexunit>but a bunch of the pre-requisite functions are there
<paroneayea>I mean the one I made with (service openssh-service-type (openssh-configuration ...))
<davexunit>it's odd
<davexunit>oh is there a reason?
<paroneayea>davexunit: guess I'd just love to see how it's built. I can't seem to log into a remote guixsd machine as root (to run backups) even though I set permit-root-login to 'without-password
<paroneayea>I can log in as other users
<paroneayea>doesn't seem that openssh logs to anywhere in guixsd by default
<ng0>ZombieChicken: yeah, that it uses qt makes it big
<davexunit>paroneayea: yeah I know nothing about it.
<davexunit>I'm just confused that I can't even use the service as-is right now
<Acou_Bass>heey guys, ive not used guixSD for a while but im thinking about switching back to it... i see 0.11 has support for LUKs partitions now, does this mean i can set up FDE easily with guixSD?
<ng0>getting somewhere with mumble now already.
<ng0>good night
<paroneayea>davexunit: because I can't figure out why I can't log in as the root user via ssh keys, despite setting flags that I would think would permit it
<davexunit>paroneayea: I guess I'm confused :)
<paroneayea>davexunit: ok, so I *want* to be able to ssh into the root user
<davexunit>I understand that
<paroneayea>and i have
<paroneayea> (openssh-configuration
<paroneayea> (x11-forwarding? #f)
<paroneayea> (password-authentication? #f)
<paroneayea> (permit-root-login 'without-password))))
<paroneayea>for whatever reason
<paroneayea>that's not enough
<davexunit>but this is why openssh-service is not defined in (gnu services ssh)
<paroneayea>I can log in as any user but root :)
<davexunit>the symbol is exported but nothing is bound to it
<paroneayea>huh? that's not my issue
<paroneayea>I have an ssh service runnign just fine
<paroneayea>I just wanted to see what config file it was generating and using
<paroneayea>because I couldn't figure out where it is in the profile
<davexunit>if you look in master you'll see that openssh-service isn't a procedure
<paroneayea>to see if that would help me see if it wrote something out wrong or something
<paroneayea>davexunit: I know
<davexunit>sorry, I'm completely lost.
<davexunit>seems that you said earlier that this wasn't your issue.
<paroneayea>I'm not sure why I'm being confusing :)
<paroneayea>I have openssh running fine, I just want to see what the config file it generated was
<davexunit>so you use the service despite not having this procedure
<paroneayea>davexunit: yes, like so:
<davexunit>I haven't yet taken the time to figure it out
<davexunit>but it's definitely a bug. whoever wrote this code intended for such a procedure.
<paroneayea>davexunit: ok! but I have it working even though there's no procedure, via the above
<paroneayea>see the (define ssh-service
<davexunit>I see
<paroneayea>davexunit: but yeah, I'm not sure why there's not a procedure, since there are procedures for everything else
<paroneayea>davexunit: I agree it's an issue, it just wasn't my issue ;)
<davexunit>got it now
<paroneayea>so davexunit
<paroneayea>davexunit: I "solved it"
<paroneayea>davexunit: by rebooting ;)
<paroneayea>I guess I'm not totally clear on when doing a reconfigure will allow me to do "sudo herd restart foo" and get foo with the latest config
<paroneayea>or when I need to reboot
<paroneayea>eg, after doing the reconfigure, I saw that... I think!... it started the ssh service, which I had just added
<paroneayea>but then later, when I changed the configuration of the ssh service
<paroneayea>restarting it had no effect!
<paroneayea>which is confusing, I'm not sure why things would work tthat way
<paroneayea>anyway! horray.
<iyzsong>my understand is when the old service is running, system reconfigure won't replace it with the new one. so run herd stop first, then reconfigure (or reboot..) will get it.
<paroneayea>iyzsong: hm ok!
<enderby>is the build farm down?
<lfam>enderby: I don't know, but why do you ask?
<enderby>lfam: i think it's building everything when i do upgrade, even tho I have substitutes setup
<lfam>enderby: Can you run the command again with --dry-run to see what it is doing?
<lfam>It seems more likely to me that the build farm is just a little behind
<enderby>it says it's going to upgrade some packages and now it's taking forever to update list of subs
<enderby>didn't know that was a thing
<enderby>good to know, thanks
<lfam>After it updates the substitutes lists, it will tell you what will be downloaded and what will be built from source
<enderby>lfam: ah, ic. so it has a several that will be built from source, but the majority would be d/led
<lfam>That sounds about right
<lfam>Hopefully nothing to hard to build...
<enderby>so, why does it do that? are those packages not avail on the farm?
<lfam>Right, they haven't been built yet
<enderby>ah ic
<lfam>`guix pull` gives you the latest commit in our Git repo. You might get it 1 second after it was committed; no time for the build farm to build the changes yet
<enderby>ah ha..... :) i get it now
<lfam>Also, we don't serve substitutes of texlive-texmf. It's simply too large for us to serve right now. Users always have to build it themselves
<lfam>It's not a great situation but it was negatively impacting our ability to serve anything at all
<enderby>thanks again for the info, much appreciated!
<shanemikel>aghh. gnutls build failure
<shanemikel>test failure, actually
<shanemikel>is there somewhere I could post the log?
<shanemikel>Oh, I guess this is it: "/template-test: line 30: datefudge: command not found"
<shanemikel>Is it required to be running GuixSD full system installation to contribute to Guix packages?
<janneke>shanemikel: no that's not required
<janneke>in fact, using Guix on (say) Debian and building with Guix on Debian should make no real difference wrt using GuixSD
<shanemikel>is there a good way to use a combination of guix release and the repo head for some small subset of the packages I'm interested in working on?
<shanemikel>oh, looks like I've found it
<lfam>shanemike1: What version of gnutls fails to build?
<lfam>I think that bug should be fixed in the current packages
<shanemikel>yeah, I'm looking at the history of it in the repo, right now
<shanemikel>I think the one I have here is 3.4.7, (from guix edit, anyway). I just installed from the binary distro. How can I find out how far the release distro is behind the repo?
<shanemikel>I'll try and upgrade it and see what happens
<lfam>If you just installed from the binary installer, then you are using 0.11.0, which is a few months old.
<shanemikel>okay, well that explains that. And as of now, the binary distro is just a build of the repo, and all upgrades pull straight from the head of that?
<lfam>You can also run Guix from a Git repo if you want more flexibility than that
<shanemikel>Yeah, now I'm wishing I did that instead...
<lfam>It's easy to mix the two installations
<lfam>As long as you build the Git repo correctly, the installations will share the same /gnu/store and redundant items will be deduplicated
<shanemikel>oh yeah, its functional :)
<lfam>It's in the manual, section 8.1 Building from Git and 8.2 Running Guix Before It Is Installed
<lfam>The key to sharing the store between the installations is to pass "--localstatedir=/var" when running ./configure in the Git repo
<shanemikel>thanks! btw, how is hydra keeping up with head?
<lfam>Every few hours, it checks out head, evaluates the code, and builds the new packages. In the last few days it ran more slowly while we garbage collected old items in preparation for a new release, but I think it's running automatically again.
<FreedomLover>Hello, GNU community.
<FreedomLover>There is a problem in another distro. Freedom problem.
<quigonjinn>FreedomLover: hello. what's the issue?
<FreedomLover>Distro is Ututo XS.
<FreedomLover>We have PlayOnLinux. This software recommends non-free fonts.
<FreedomLover>Also we have Chromium browser, Firefox Aurora, Iceweasel, HP and Mac OS logos.
<quigonjinn>FreedomLover: you should get into contact with developers of that distro then
<FreedomLover>The project is dead. I want to support it. Or better way is to fork it?
<Petter>Sounds like a message intended for #gnu or #fsf?
<ng0>sneek: later tell iyzsong: Is there any reason why the git-service should not make use of ssh though defining a user "git" instead of what you suggested?
<sneek>Got it.
<ng0>sneek: later tell iyzsong: for memory refreshing, you suggested to set user to "nologin" because the user is just for ssh access
<sneek>Will do.
<iyzsong>ng0: the user which will ssh and the user git-daemon running as are not (can be not) same. i think usually the former is 'git', the latter is 'git-daemon'.
<sneek>iyzsong, you have 2 messages.
<sneek>iyzsong, ng0 says: Is there any reason why the git-service should not make use of ssh though defining a user "git" instead of what you suggested?
<sneek>iyzsong, ng0 says: for memory refreshing, you suggested to set user to "nologin" because the user is just for ssh access
<ng0>but I though this is for enabling limited ssh access to git, in addition to any running ssh daemon
<ng0>this is how i did it sometimes
<ng0>of course I can be wrong, so if there's no one else adding their opinion/experience, I will leave it at nologin for now
<iyzsong>yeah, I agree share a same user do not harm much..
<ng0>i never had more than one user because of decentralized use, but it should work.
<ng0>in the last message (sorry, i have no link, i have the archive locally) send at Date: Sat, 01 Oct 2016 07:49:36 +0800 you mention that it should just use a <git-configuration> object. is there a service I could look at (openssh maybe?) to understand what you meant?
<iyzsong>ng0: yes, i mean a single 'config' argument is enough, eg: dicod-service.
<ng0>okay, I will read that service and ask if I have more questions
<iyzsong>sure, and thanks!
<ng0>thanks so far for your help. I'll be afk for a while now
<iyzsong>me too.. go for meal :-)
<ng0>me too
<baconicsynergy>good morning geeks
<janneke[cm]>good morning baconicsynergy
<Acou_Bass>good morning guix
<baconicsynergy>morning bass
<Acou_Bass>i think im gonna put guixSD back on my laptop this weekend
<baconicsynergy>i was gonna do the same until it died :(
<Acou_Bass>gonna see if i can get FDE working... there seems to be a function for it in the configuration.scm now
<Acou_Bass>i had guix on my laptop for a bit but there were some packages/stuff missing that i would expect to have a relatively secure portable device, such as FDE, dnsmasq/crypt, so i installed nixos instead.. but now it all seems to be there, so back to scheme goodness i reckon :D
<baconicsynergy>i wonder when guix 1.0 will be released?
<Acou_Bass>probably 'when its ready'™
<ng0>next summer.. maybe.
<ng0>isn't gnu hacker meeting around august every year? would be nice timing to get it done then
<baconicsynergy>okay so i have an interesting issue
<baconicsynergy>i was having locale problems, so i installed glibc-locales and set GUIX_LOCPATH accordingly. this solved my locale issues, but now i cant use guix at all. it says "warning: failed to install locale: invaled argument"
<jmd>baconicsynergy: That is very strange. It has misspelt "invalid".
<paroneayea>I'm looking to package dirvish because I think I'd prefer a more minimalist and "pull" based backup system
<paroneayea>one thing is, the install script it comes with wants a configuration directory. it defaults to /etc/dirvish
<paroneayea>which I guess, we don't need to change that?
<paroneayea>since we're likely to run it as a service
<paroneayea>and pass the config file parameter in manually?
<lfam>Seems like a reasonable location for a "pull" backup server
<lfam>Oh, I misunderstood
<lfam>Yeah, seems like a reasonable fallback for those who won't use the GuixSD service
<civodul>paroneayea: it's even better to not use /etc at all and instead run it with --config-file=/gnu/store/...-foobar.conf
<lfam>What do people think about building the python-build-system branch on Hydra? Do we have the capacity?
<lfam>It affects a lot of packages, but I wonder what percentage of them are very cheap to build?
<civodul>lfam: i think we should build it, though we're still a bit short on disk space on the front-end
<lfam>Ah, right
<civodul>did you or someone else look at the patch series?
<lfam>I read it through once. I want to read it again before I'd start building it.
<civodul>ok good
<civodul>in the meantime we can more free space on the machine
<lfam>Most of it is rearranging inputs for most of the Python packages. Things like changing inputs -> propagated-inputs, et cetera
<civodul>mark_weaver: how does building the python branch sound? ↑
<civodul>lfam: so the only critical change is what relates to python-build-system i suppose
<lfam>Yes, that's the core of the change, but there are many changes in python packages in order to adjust to / take advantage of the difference in how they are built
<lfam>If you'd like to skim the commits, they start at 043a51c0c2a025b84b0fb14c157add7236d7a526
<lfam>Probably, I'll want to adjust some of the commit messages. So if we decide to build the branch now, I'll probably start it this weekend after re-reading and changing some of the messages
<lfam>I'll have quite a bit of free time in the next week (USA holiday)
<lfam>civodul: Also, this bit of documentation helps to explain the idea of the change:
<civodul>lfam: i've looked at that message quickly, but (1) it's not an actual patch :-), and (2) it looks like a design rationale more than actual user documentation no?
<civodul>not sure
<lfam>Right, I misspoke in describing it
<civodul>anyway more doc is always good, we just need to make sure it fits in
<lfam>It helps to explain the different ways to build Python software and what we are changing
<lfam>I'm not a Python expert, so it helps me understand why we might want to change the build system like this
<lfam>(If some Python expert wants to take over reviewing / shepherding this patch series, jump in :) )
<lfam>(Or even another interested person)
<civodul>yes right, so it sounds good to add that bit of documentation
<lfam>Changing the subject, I wonder about some of our heavily patched packages. I hope we don't introduce new bugs by applying so many patches out of context to, for example, libtiff.
<civodul>yeah it's tricky
<civodul>usually those patches have one specific focus, which is quite reassuring
<civodul>we could always be making mistakes, but doing nothing would leave us with a libtiff package with known security issues
<lfam>Yes, it's a trade-off. It's a "good thing" that the fixes are usually just adjusting bounds or range checking in C code
<lfam>So, we have to trust the upstream maintainers to adjust it correctly, and we can know there is no API change
<paroneayea>civodul: that's what we'd do with the service, right?
<paroneayea>but it does need some default
<lfam>One of our libtiff patches (CVE-2016-5652) actually already contains the changes for CVE-2016-9453, issued today
<lfam>Tricky :)
<lfam>Feels almost like I'm tracking their CVS "by hand"
<lfam>Opinions on Bash CVE-2016-9401, "popd can be tricked to free a user supplied address"?
<civodul>paroneayea: right, but even on non-GuixSD, people could use that --config-file option, no?
<paroneayea>civodul: of course :)
<paroneayea>well, the other advantage of packaging dirvish with a service is, I get to learn how to write services! :)
<civodul>lfam: i'm not sure how this can be exploited
<lfam>civodul: Me neither, so I asked for more people to look :)
<lfam>paroneayea: python2-pgpme (a dependency of assword) fails its test suite with the latest version of gpgme (1.7.1):
<lfam>Oh, that is no longer the latest gpgme. I'll try with 1.8
<lfam>And I meant to write "python2-pygpgme"
<albertoefg>how can i know if I am running guix inkscape vs package manager inkscape
<rekado>albertoefg: ‘which inkscape’
<albertoefg>well i have inkscape installed through GNOME software
<albertoefg>and gudx
<lfam>paroneayea: Nope, assword will still be broken with the latest gpgme
<albertoefg>how can i be sure i am running guix inkscape
<rekado>albertoefg: whichever is first in your PATH will be run by default.
<rekado>albertoefg: if you want to override this use the full path to the executable
<rekado>e.g. ~/.guix-profile/bin/inkscape
<albertoefg>so if i run that command inkscape will open
<albertoefg> guix inkscape
<paroneayea> * ensure that test suite works with gpg 2.1.x (Closes: #797776)
<paroneayea>I wonder if that will fix it
<lfam>Hm, I also had changed our package to use gnupg 2.1.x, it's possible that is the problem
<rekado>hmm, looks like a lot of packages for i686 aren’t available as substitutes
<lfam>Or something in that area
<rekado>can’t update one of my machines because it can’t possibly build cython before the weekend is over
<civodul>rekado: strangely there aren't many i686 builds queued
<civodul>could it be that some things simply failed to build
<paroneayea>lfam: here's the bug about 2.1.x
<lfam>Thanks for the tip. Do you know if pypgpme is a Debian project? DKG's message about modifying the test suite makes it sound like its developed internally
<paroneayea>lfam: DKG is just very familiar with it I think
<paroneayea>dkg is one of the key encryption people in debian
<lfam>Okay, good to know
<paroneayea>and a user
<paroneayea>he wrote assword :)
<lfam>Okay, I'll contact him directly if I get stuck :)
<paroneayea>lfam: thanks, let me know if that fixes it :)
<paroneayea>thanks for your vigilence :)
<lfam>Is that a portmanteau of vigilance and pestilence? Not sure how I feel about it... ;)
<paroneayea>lfam: just a typo, but interpret in the way that derives greatest satisfaction for yourself.
<lfam>I did :)
<rekado>on i686 the cython build is derivation kpy265nc42…; latest on hydra is dqp9nw1hc8cq2jk9rhwihxnjvsmwizlx-python2-cython-0.24.1.drv
<rekado>I don’t see any other cython builds on hydra.
<lfam>rekado: Do you think it's <>?
<rekado>lfam: well, ludo’s work-around has been applied. Shouldn’t that have fixed it?
<lfam>rekado: Yeah, but I don't see cython in the queued jobs for the latest evaluation
<lfam>I don't think any of the recent changes should require a cython rebuild
<rekado>yeah, I also went through the logs to find another recent commit to revert to, but I couldn’t find a suitable candidate.
<albertoefg>So i am using GUix's Inkscape and Icecat on fedora with no problems. Would you recommend to drop fedoras packages and stick to guix?
<buenouanq>drop everything and move to GuixSD :3
<albertoefg>i know but that is too much work for now buenouanq
<buenouanq>nah man, the install is the slickest thing ever
<albertoefg>but i have to backup everything
<albertoefg>and download lots of stuff again
<lfam>albertoefg: You should do whatever works for you. I mix Debian and Guix packages without trouble
<albertoefg>and configure
<albertoefg>great lfam :)
<lfam>As time goes by, I add software I install from Debian to Guix, so I can use Guix instead :)
<albertoefg>but what i mean is like ace guix packages more secure
<albertoefg>ace, are*
<buenouanq>too loaded a question, best answer being:
<lfam>Yes, it depends
<lfam>We both try to follow security advisories and fix our packages as soon as possible
<buenouanq>I have more reason to trust Guix than anyone else.
<lfam>Well, we have fewer volunteers than Debian. Also, Debian has been patching their packages for many more years than us. If they fixed a security bug 10 years ago, we might not have fixed it yet, because we haven't noticed it.
<jmi2k>One question: if I want to build a package from a custom recipe how can I do it? I have the file prepared, but I can't figure out how to build it and install on GuixSD
<lfam>jmi2k: I recommend using the GUIX_PACKAGE_PATH environment variable to tell Guix where to look for your package. You could also use `guix build --file=`
<jmi2k>Fine, I'll try. Official documentation it's a bit misleading for the newcomer :D
<albertoefg>so how can i help :)
<lfam>jmi2k: Feel free to ask for clarification.
<lfam>albertoefg: Pay attention to the upstream development of packages you care about, and report security bugs or fixes to us
<lfam>You can also subscribe to Fedora's security advisories, and if we haven't fixed something that Fedora has, report it.
<lfam>Or fix it
<albertoefg>fedora has icecat 45.3.0
<albertoefg>but has icecat 38.8.0
<lfam>Your Guix is out of date
<lfam>We have icecat 45 beta
<albertoefg>ok :)
<albertoefg>thats great
<albertoefg>i thought fedora had a custom icegat since was on 38.8
<ng0>45 is beta atm
<lfam>Hm... I think hasn't actually released icecat 45, but we are using the beta release
<lfam>So, is anyone on another distro able to do `guix lint -c cve`?
<lfam>I get this:
<lfam>Throw to key `gnutls-error' with args `(#<gnutls-error-enum Error while reading file.> set-certificate-credentials-x509-trust-file!)'.
<ng0>there's a vote on savannah about icecat development and features, if someone wants to add to that
<lfam>ng0: link?
<ng0>i only have the one abvout "should we base on tor code", rest is in the mailing list aswell
<ng0>I no longer support this course that much, but it's nice to see they act on suggestions
<ng0>it could get challenging for them to be based on a fast moving target.
<ng0> "Now that the Tor Browser includes a patched version of Firefox, and because we don't have enough developer resources to keep up with the accelerated Firefox release schedule, the toggle model of Torbutton is no longer supported. Users should be using Tor Browser, not installing Torbutton themselves."
<ng0>but then it could also help to keep up with development and adjust
<ng0>motivate people to contribute because the browser is more current
<albertoefg>lfam do u still need
<albertoefg>guix lint -c cve
<albertoefg>what output should i expect lfam
<paroneayea>analysis paralysis
<ng0>can someone using a different WM/DM then awesome confirm that the taskbar symbol of utox is just a white box?
<ng0>that's a bug I have ever since I started using it here but it doesn't bother me
<paroneayea>ng0: does utox use gtk3?
<paroneayea>I've noticed some gtk3 widgets have been borken here on recent guix
<paroneayea>eg, scrollbars missing, checkbox boxes not appearing on forms
<paroneayea>(the checks are, oddly)
<ng0>the application itself is mostly okay (you can't change the avatar, but that works in qtox
<ng0>i don't know, it's not in the dependencies
<ng0>i'd guess it is gtk, because qtox is qt based
<ng0> yeah, gtk
<ng0> and uses gtk3
<paroneayea>ng0: are you using recent icecat from guix also?
<paroneayea>does the scrollbar show up for you or is it a blank rectangle?
<ng0>with gtk3 it was blank, with the switch to gtk2 that was "fixed"
<paroneayea>oh was it switched back
<paroneayea>ACTION apparently needs to --upgrade again
<ng0>i can't remember if those problems are gone in gnome, i don't use gnome so often
<ng0>maybe it just misses a dependency or some external application which is not needed in gnome or otherwise provided
<rekado>webkitgtk takes forever to build
<rekado>already built it once today; now it’s the older version for gnucash.
<civodul>on i686?
<paroneayea>somebody tell me not to write my own wrapper around rsync in guile and just finish packaging dirvish :)
<civodul>paroneayea: stay focused! :-)
<civodul>i played supertuxkart with my daughters for the first time today, and i was pleased to see a goblin there
<civodul>next to Tux, Beastie, and even a gnu
<paroneayea>civodul: yeah! :)
<paroneayea>civodul: I haven't played it yet
<civodul>fun stuff!
<civodul>they even translated its name
<paroneayea>there's also Nolok in there, the SuperTuk enemy, which is an olllld character I contributed to supertux, so I technically have two characters in there sort of... I should play it! :)
<civodul>oh, definitely!
<jmd`>I built a new disk-image and it seemed to go fine. But when I boot from that image guix seems to think that packages aren't in the store and tries to rebuild them. How so?
<civodul>jmd`: rule #1: Guix knows what it's doing
<civodul>probably the Guix in the image is different from the one used to build the image
<civodul>you could work around that by using 'current-guix'
<jmd`>Should that matter?
<civodul>it could make a difference, yes
<civodul>that's why in (gnu tests install) we use 'current-guix'
<jmd`>"No index entries containing 'current-guix'
<civodul>right, it's for wizards only ;-)
<jmd`>So where and how should I use "current-guix" ?
<civodul>see (gnu tests install)
<alezost>paroneayea: AFAIK hidden scrollbars is a feature of gtk3, I noticed this thing in conkeror in "Arch Linux" many months ago when Arch's firefox was switched to gtk3
<paroneayea>alezost: hidden scrollbars is a feature, but this isn't
<paroneayea>alezost: instead of being "hidden" and exposed on scrolling
<paroneayea>there's just permanently a grey rectangle on my machine
<paroneayea>which doesn't change at all
<civodul>paroneayea: yes, i noticed that, but only in IceCat/Conkeror
<civodul>other GTK+3 apps don't have this problem
<civodul>but i think it's related to schemas snafu
<civodul>i started fixing it following taylan's report, but there was more snafu
<civodul>and icecat takes ages to build
<jmd`>operating-system-with-current-guix should be exported from guix system install ?
<paroneayea>civodul: ok, well glad I"m not the only one who noticed it :)
<paroneayea>civodul: checkbox boxes are also missing
<paroneayea>I filled out a form wrong by not checking a box :)
<paroneayea>well, it asked me to resubmit, so not so bad
<civodul>uh, that can be problematic indeed
<civodul>jmd`: it's for tests only, but we could export it when the need arises
<jmd`>well if, as you say, guix disk-image is going to result in a broken image otherwise, then I would say the need has arisen.
<janneke>civodul: apropos rule #1, would it be possible for Guix to share some of their wisdom about what they're doing, e.g.: rebuilding foo because dependency bar changed from abcd to abce?
<jmd`>civodul: Actually, what exactly did you mean by 'the Guix' in your above statement.
<civodul>jmd`: my understanding is that you're trying to run 'guix' inside the image you created, right?
<jmd>trivially yes.
<civodul>so there are two Guix here: the one used to build the image, and the one inside the image
<jmd>I was running "guix build" to get the path of a package.
<jmd>I was expected it to do nothing but was suprised when it tried to build something.
<jmd>s/build/fetch a substitute/
<civodul>you could try also with --no-grafts
<jmd>in the image?
<ng0>so far there's no lint for services, right?
<jmd>No. It still tries to build things.
<jmd>(an then fails because there is no network)
<ZombieChicken>I have to say, I like submitting bug reports for guix. Things actually *happen* when they are filed
<jmd>anyway, after I have booted from the image, I am in a new universe, yes? The one used to build the image is outside this universe.
<ng0>cool, so apparently in 2014 and 2013 at least 2 people already proposed and discussed about what I came up with for gnunet-fs and guix. Good to know that there's some past discussions I can read to not repeat questions/answers
<ng0>that's a good discussion. why was it never put to practice? are the guile bindings of gnunet the only outcome so far?
<ng0>Reading it all, and what I gathered before discovering this archive, it's not a trivial goal so there are maybe reasons why this is slow work in progress
<Acou_Bass>eey guys, slightly stupid question potentially XD i did guix system init to install guixSD to my laptop and it finnished without errors, *however* i had some problems with my grub configuration and so i want to run guix system reconfigure *on the installed system* from my liveCD... is this as simple as just chrooting in?
<ng0>lsat time i tried chroot I noticed for myself that I should take the irc log and file a bug
<ng0>so chroot works to some degree
<ng0>do you have an already working system?
<ng0>otherwise you can just change the grub related setting in the config.scm and run init again I think
<ng0>I'm not 100% sure
<Acou_Bass>i tried running init again but it told me that im out of space which im not 100% sure why xD but hmm