IRC channel logs


back to list of logs

<bavier>rain1: is it not possible to bootstrap mlton without a prebuilt binary?
<rain1>i don't think so, it's written in mlton
<bavier>rain1: the Makefile seems to suggest that it will bootstrap itself without an existing binary
<rain1>well when I try to build it it complains about not being able to run mlton
<rain1>so I thought it needed one, maybe I'm wrong and its a different error
<ajgrf`>there may be another sml compiler which can build mlton without relying on a prebuilt binary
<ajgrf`>i don't know of one, but the fact that sml has more implementations than ocaml or haskell gives me hope
<lfam>It seems that 0.10.0 was released with a substitute for Emacs! At least, while installing GuixSD 0.10.0 I find that I must build Emacs from source
<kyamashita>Quick question: I've checked out the guix tree to define packages using git clone. How do I run guix lint on those packages that I've built (that aren't a part of the official tree)?
<lfam>kyamashita: You'll need to build (or at least ./configure) that tree to generate the file pre-inst-env'. Then, prefix your `guix` commands with ./pre-inst-env
<lfam>Sorry, I hit enter before I was done typing
<lfam>Prefix your invocations of `guix` to use the tree you've cloned rather than the one in ~/.config/guix/latest
<lfam>So, ./pre-inst-env guix lint foo
<kyamashita>Alright. Trying it now...
<lfam>Do you already have Guix or GuixSD installed?
<lfam>When configuring, you have to make sure to match the value of localstatedir to that of the pre-existing Guix installation
<lfam>Typically, it's like this: ./configure --localstatedir=/var
<kyamashita>I'm in GuixSD right now. And yes, I just saw that bit in the README.
<kyamashita>Cool, it's working! Thanks.
<lfam>When creating a new GuixSD system with an encrypted home, my user's home directory is not created automatically
<kyamashita>I've noticed that too. I've had to go in manually and create it/grant myself permission to use it.
<lfam>kyamashita: You use an encrypted /home as well?
<kyamashita>lfam: I do.
<lfam>Hopefully when I log in for real (rather than `su` as root) I have a proper $PATH
<kyamashita>You should. Mine gets the job done.
<lfam>Okay! Because my su-ed path is just /bin:/usr/bin
<lfam>Not very Guix-y!
<kyamashita>Mine isn't anymore.
<kyamashita>What? The fact that the directory creation doesn't work with an encrypted home?
<lfam>No, that path! GuixSD doesn't even have /usr
<kyamashita>ls /usr
<kyamashita>LOL, that was meant for my shell.
<lfam>Heh, you should have the same result when you run it there ;)
<kyamashita>Well what do you know? There *isn't* a /usr folder!
<lfam>It's all in /gnu!
<kyamashita>Right. And /gnu is immutable for reproducibility reasons, I assume.
<lfam>Well, there are several reasons. But /gnu/store is immutable
<lfam>My user's home directory is suboptimal
<kyamashita>How so?
<lfam>I think that if it is created automatically by GuixSD, it should contain some configuration files that it is lacking
<lfam>I noticed because my prompt was just "bash-4.3$"
<kyamashita>Same here.
<lfam>I deleted it and am reconfiguring. Hopefully that will cause it to be regenerated.
<lfam>Else I will remove the user from my configuration, reconfigure, then add the user back and reconfigure.
<lfam>I've installed GuixSD a few times for testing and I have a long-running VM, but this is my first time with LUKS on bare metal
<lfam>With GuixSD anyways
<anthk_>it would be nice something like -> export PS1='\\[\\e[1;34m\\]$(whoami)@$(hostname):\\e[1m\\[\\e[1;32m\\][$(pwd)]\\[\\e[1;34m\\]\\e[0m>'
<kyamashita>I'm curious to see if this works.
<lfam>I'm not sure exactly what that does, but the default GuixSD prompt is not just 'bash-4.3$'
<lfam>I'm optimistic
<lfam>I never opened the LUKS partition while initializing the system. I wasn't sure if I should or not and I was curious about what would happen if I didn't
<rain1>I like a simple PS1: $ for user # for root
<kyamashita>I opened my LUKS partition and mounted it and my home directory still wasn't created.
<lfam>I have to turn of the PC speaker
<anthk_>I use [\\e[1;31m\\] for root rain1
<lfam>paroneayea: Did you have to do anything to make the GRUB menu show up on your x200? On my x200s, it's totally scrambled
<kyamashita>lfam: I use the configfile command to load the grub.cfg on my x200.
***drewc_ is now known as drewc
<lfam>kyamashita: I had to remove the user from my configuration, reconfigure, then add the user back and reconfigure.
<lfam>Simply reconfiguring after deleting the user's home directory had no effect
<kyamashita>Interesting. What do you have in your home directory now?
<lfam>I recommend doing this if it's not too inconvenient
<lfam>Copied by hand, .bash_profile, .bashrc, .config/, .gdbinit, .guile-wm, .Xdefaults, .zlogin
<kyamashita>At this point it could be... I could backup everything first.
<lfam>Previously I had nothing
<lfam>I had forced the creation of .guix-profile by invoking the guix in /run/current-system/profile/bin but I could tell that things were still "off"
<lfam>All my environment variables were wrong
<kyamashita>Yeah, I don't have .gdbinit, .guile-wm, .Xdefaults, .zlogin
<lfam>Now everything "just works"
<kyamashita>I'll try it.
<lfam>I don't know *why* I have some of those files. This system doesn't have X, guile-wm, and I haven't used gdb
<lfam>The environment was the real problem
<lfam>And GuixSD sets package's search paths automatically, which is awesome. Having to export all the paths on a foreign distro is a PITA.
<lfam>I was worried that wasn't going to work
<kyamashita>Root gets the same base file layout in its directory as what you seem to have in your user directory now. I'll try copying over the files from root.
<lfam>I wonder how this issue could be avoided (besides initializing with the barest of bare-bones systems, and adding your user when reconfiguring).
<lfam>Actually, I think a bare-bones init is the way to go. Initialization is the most finicky part of GuixSD in my (limited) experience
<lfam>But users aren't going to follow that instruction
<lfam>And in the long run, GuixSD should be easy enough for anyone to get started with
<kyamashita>I agree. Is there a way to debug the initialization process during installation?
<lfam>What do you mean?
<kyamashita>Step through and see what's going on. I suppose that looking at the guix system init code would be a start.
<lfam>We've fielded similar questions about stepping through package building.
<lfam>I really have no idea how to achieve this, but right now your best bet is probably to invoke the relevant commands from a Guile REPL
<lfam>Which would require you to read the code and understand it
<kyamashita>Heh. I'm relatively new to both C and Guile.
<lfam>As I said, I have no idea how to do that ;) I'm pretty new to Scheme
<lfam>I wonder if my user's home directory would have been created if I had opened and mounted the encrypted partition before initializing the system
<kyamashita>I've done that and it wasn't created for me. Neither from GuixSD 0.9.0 nor the GuixSD 0.10.0 install images.
<lfam>Okay, good to know
<lfam>I'm going to file a bug report
<kyamashita>Sounds good.
<kyamashita>Excellent. Hopefully progress will be made before the next release.
<mark_weaver>rain1: the ffmpeg update also broke blender
<mark_weaver>in <>, search for "AUD_FFMPEGReader.cpp"
<mark_weaver>(the error is quite far from the end of the log)
<mark_weaver>and it also broke libextractor.
<rain1>odd that blender broke
<mark_weaver>well, it uses ffmpeg, and apparently they made an API change that breaks a lot of things
<rain1>we have a problem with libextractor, it's already at the latest version
<rain1>for these two packages maybe it would be best to add back the old version of ffmpeg as a separate thing they can reference?
<mark_weaver>maybe there's a patch in their upstream repo
<rain1>or what do you think is the best solution
<rain1>ill check
<mark_weaver>ideally, we'd find patches to fix these things without adding back the old ffmpeg. but if that fails, we could temporarily add the old ffmpeg.
<mark_weaver>my concern with adding the old ffmpeg is that ffmpeg has a large attack surface and is regularly exposed to potentially hostile data from the network.
<rain1> there's this for 2.9
<rain1>yes absolutely
<mark_weaver>and not all potentially-exploitable bugs are assigned CVEs
<rain1>I think ffmpeg was really due and upgrade
<rain1>i didn't know it would break things though
<mark_weaver>yeah, I wouldn't have known either.
<rain1>not sure where to get the information on which blender versions work with which ffmpeg versions
<rain1>people don't seem to want to list this sort of info anywhere
<rain1>I'll just try a version bump and see if it builds
<mark_weaver>rain1: okay. while you do that, I'll test that patch you found for libextractor.
<mark_weaver>(which looks quite promising)
<mark_weaver>the patch helped, but was incomplete. I should be able to finish it up
<mark_weaver>rain1: I got libextractor building successfully, will push soon.
<rain1>awesome! I'm having trouble with blender
<mark_weaver>the key changes that I needed to add to the patch for libextractor were as follows: avcodec_alloc_frame has been renamed to av_frame_alloc, and avcodec_free_frame has been renamed to av_frame_free
<mark_weaver>although it's worth looking in the blender upstream repo for a more official patch
<rain1>oh good but I was getting this: Could NOT find PythonLibsUnix (missing: PYTHON_LIBRARY PYTHON_LIBPATH PYTHON_INCLUDE_DIR PYTHON_INCLUDE_CONFIG_DIR)
<rain1>I will have to investigaet it more tommorow
<kyleschmidt>I have a guix daemon running but guix commands do not work. Is there a specific make command or build command that I need to run?
<mark_weaver>kyleschmidt: what happens when you try to run guix commands?
<kyleschmidt>No command guix found
<mark_weaver>how did you install guix>?
<mark_weaver>binary installer, or from source?
<kyleschmidt>binary installation
<mark_weaver>step 6 of the binary install instructions made a symlink /usr/local/bin/guix pointing to /var/guix/profiles/per-user/root/guix-profile/bin/guix
<mark_weaver>does that symlink exist?
<mark_weaver>is it pointing to the right place?
<kyleschmidt>:P thanks that fixed it!
<kyleschmidt>mark_weaver: if I wanted to install a guixsd vm, is there a config.scm file that I can use to get this up and running?
<kyleschmidt>a sample file or something similar?
<lfam>kyleschmidt: Did you ever get an answer about a template config for creating VMs?
<lfam>There are some samples in the Guix source code. See the files 'doc/os-config-*'
<lfam>Do GNOME users on GuixSD have a way to prevent their laptop from suspending when the lid is closed?
<Jookia>I'm going to create a repo with unmerged patches for people to use
<Jookia>I'll try to keep it in sync as much as possible and if they get merged in to the official Guix, great. If not, no big deal since people can still use them
<Jookia>rain1: This might help if people have patches that aren't suitable for upstream Guix too, so almost like an AUR but not :P
<Jookia>ng0: This could help you too with gnunet patches
<ng0>sorry did not follow
<ng0>was trhere something before these lines?
<Jookia>ng0: I'm going to create a git repo containing some patches to apply to Guix with a way for users to apply which ones they want with latest Guix
<ng0>ah okay. but the gnunet things are ready. the only thing lagging behind is me, as gnunet-svn depends on new description which depends on me contacting bug-womb with cg's approval
<ng0>which i have, so i need to contact bug-womb
<Jookia>Cool, but if you want people to be able to use your patches right away it'd be nice to be able to direct them to a script that will let them use them immediately. guix-now :P
<ng0>description update -> only patch which needs testing again is gnunet-svn without python.
<Jookia>I don't intend for it to fork but if it accumulates unmerged patches that refactor/change Guix enough it might end up that way
<ng0>the only thing you could get in there could be secushare, which i'll write after whois and after the gnunet-service
<Jookia>I might pull in your patches anyway since they're not in guix yet, unless someone merges them before I create whatever system I'm going to make
<ng0>please don't do it yet
<ng0>i have certain quality standards to my work (disregard what's in the gentoo repo currently though ;D), and the gnunet-svn patches are not done. what's done is gnurl.
<Jookia>Ah. But if they're usable, surely it'd be okay for them to be available for people to test/use without official merging?
<ng0>my name would still be on them.
<ng0>if it's indexed on the net, i'd like to only have complete patches out there.
<Jookia>Your patches are already indexed on the mailing list
<ng0>i know
<ng0>but this indicates work in progress
<Jookia>I'll just put the first version that I did and gave to you up
<ng0>where as your repo would have to state it somewhere, then i would be okay with it. "currently being worked on, see link to threads"
<ng0>i just woke up, so i might take this in the confused way. but some link to the threads would be okay for me.
<ng0>like in our gentoo overlay i write explicitly that the guix ebuilds are still work in progress.
<ng0>or would, with the next pull and merge by lynX
<ng0>Jookia: i think the patches will get finished before the end of this week, if I don't forget it after the appointment I have today, I'll write to bug-womb@gnu about the new description
<ng0>to the rest of you, can somebody take a look at
<ng0>i'll have to go now for some hours, see you.
<Jookia>sorry was afk
***kelsoo1 is now known as kelsoo
<civodul>Jookia: cool, sorry that i'm taking so long on reviewing these things!
<Jookia>civodul: We need more reviewers. :P Also lack of reviewing led to a bad GTK+ patch. :(
<civodul>yes, i've just seen that
<civodul>lack of reviewers, and people not paying enough attention to the bugs being reported ;-)
<Jookia>It's fine :)
<lfam>$ herd restart shepherd
<lfam>You must be kidding.
<wingo>if we never land a bad patch it means we're being too strict, probably :)
<Jookia>civodul: Dunno if I linked this on the mailing list, regarding the GTK+ patch
<iyzsong>cool! and I have run 'guix refresh -t gnome -u', preparing patches...
<civodul>Jookia: i hadn't seen it before, but it looks like the Right Thing no?
<civodul>yeah, i think we can create a branch with this patch plus the updates that iyzsong is working on
<iyzsong>yes, I think the gtk-update branch should be delete, and create a 'gnome-updates' branch.
<civodul>good, let's do that! :-)
<Jookia>Sounds good, though you'd still need the GTK+2 patch from the mailing list, which is identical in function but fixes GTK+2 too
<Jookia>There's also the need to patch some applications, mainly lxappearance and gnome-tweak-tool. I already have a patch for lxappearance but not the latter
<civodul>Jookia: is there a GTK+2 version of the theme patch coming from upstream?
<Jookia>I don't know, I don't think so
<Jookia>The GTK+2 patch in the mailing list I wrote seems to work fine and bugfree
<Jookia>Even with grafts
<civodul>ok, sounds good
<civodul>iyzsong: could you apply these two patches in the gnome-updates branch?
<civodul>do you where to find them? :-)
<iyzsong>civodul: sure, but I haven't done yet.
<rekado_>I would like "herd restart shepherd" to work. Just to reload its init.scm file.
<rekado_>ACTION promises to review more patches starting June.
<civodul>rekado_: but currently restart means "stop" followed by "start", which is also known as "reboot" in the case of PID 1 :-)
<efraim>how about launch a new shepard instance, move the children to the new instance, and do a rotate_root thingy to the new one?
<rekado_>I'm using shepherd as a user, so its PID is not 1.
<rekado_>civodul: should we instead add a "reload" command?
<rekado_>(not asking for the work to be done; I can prepare a patch if that's how it should be done.)
<civodul>rekado_: yeah but we'd have to think about what it means to "reload" init.scm, since init.scm is code that defines and registers and possibly starts services
<wingo>what would happen if shepherd did an execve of itself?
<civodul>ACTION follows a webinar on "reproducible research" for work:
<civodul>unfortunately, it's all about how Docker is The Solution
<efraim>however, i figured out how to download all of the qt-5.6.0 modules in one go:
<efraim>curl | grep tar.xz | cut -d '>' -f7 | cut -d '<' -f1 | awk '{print "" $0}' | aria2c -i -
<efraim>yay for parallel downloads
<civodul>apparently they'll mention Nix:
<civodul>not so bad ;-)
<rain1>good mirning
***wgreenhouse is now known as Guest61626
<rain1>a program to help make guix packages -
<ng0>fascinating. still have to debug towards guix compability though.
<efraim>that's the most "expensive" hello program I've seen
<rain1>:p yeah
<rain1>GNU hello doesn't really have any inputs
<taylan>rain1: doesn't it? I thought it's internationalized and all, for demonstration purposes.
<taylan>so that'd be gettext as an input
<taylan>never mind, apparently it has none
<taylan>rain1: oh and BTW, that's great! :)
<taylan>I love the idea of bridging the gap between devs and users
<jmarciano> Now I understand zenity bindings...
<jmarciano>zenity has also --width option for easier input of long lines...
<htgoebel>HI, I'm new to guix and trying to find may way. I've set up guix onto a debian machine for testing.
<htgoebel>Now I want to use `guix enviroment -l ...` to setup an environment containing nginx and a small static website.
<htgoebel>Is there an example for this kind of stuff? (I did not find one)
<iyzsong>I don't see that, use 'guix environment --ad-hoc nginx' you only get nginx, and there need some step to run it manually..
<taylan>(off-topic: )
<htgoebel>iyzsong: This is just what I'm going to start with.
<htgoebel>And I want to have this reproducible in a .scm file
<htgoebel>like a operation-system definietion
<davexunit>htgoebel: doing what iyzsong suggests is good to start with
<davexunit>as an unprivileged user, you can then run nginx on a port numbered 1000 or greater and serve your static site
<htgoebel>davexunit: The aim is not to start nginx manually and passing it options. The aim is to fire up an environment (or whatever) and have an already configured nginx running in there.
<htgoebel>The next step then would be to have this nging talking to some fast-cgi server ...
<davexunit>htgoebel: that's not really going to work, sorry.
<htgoebel>... which is also started be this environment
<taylan>well, guix is just a package manager. maybe guix + shepherd can do such a thing.
<iyzsong>yep, not now. but I think that could be a container (launching the nginx shepherd service) and shared the working directory.
<davexunit>htgoebel: I mean you could something like: guix environment --ad-hoc nginx -- nginx -c some-config.conf
<htgoebel>iyzsong: MAybe something like that :-)
<rain1>thanks taylan :)
<davexunit>'guix environment' will run an arbitrary command for you. in your case, you can use it to run whatever you need to set things up
<davexunit>I set up ruby on rails environments like this
<rain1>We reject your support for torture, your calls for murdering civilians, and your general encouragement of violence
<rain1>what is this
<htgoebel>davexunit: But guix already provides *a lot* of config managment options. Look at all this dovecot-stuff in sec. 7.2.7 of the manual.
<iyzsong>yes, 'guix environment' is designed just to give an environment, nothing more.
<htgoebel>Okay. I understood, `guix enviroment` is not what I want :-)
<taylan>rain1: an open letter to Donald Trump, a neo-fascist running for presidency in the US and gaining a lot of steam
<htgoebel>But what then?
<davexunit>htgoebel: 'guix system' handles full-system configuration
<rain1>obama is responsible for drone attacks
<davexunit>htgoebel: 'guix system container' will eventually be what you want, but it can't do networking at this time.
<taylan>we shouldn't go very off-topic in this channel I think :)
<davexunit>'guix system vm' might work, but I actually don't know if you can forward ports to it.
<efraim>mercurial updated, that takes care of the CVEs
<htgoebel>davexunit: I assume, I' defining a system like in sec. 7.2 of the manual, and just leave the disk-stuff (and such) away?!
<davexunit>htgoebel: yeah, mostly
<davexunit>I think you need to specify a bootloader field, but it isn't used
<htgoebel>davexunit, iyzsong: thanks so far. I'll give it a try. Expect more questions soon ;-)
<davexunit>htgoebel: yw. I've been (slowly) working on things to make this stuff more possible, because I also want the same thing.
<davexunit>what's nice about guix is that you get to choose from many levels of isolation and pick the one that is most convenient for your needs.
<davexunit>'guix environment' provides simple environment variable based isolation and also a type of container, and 'guix system' can be used for making completely isolated systems in VMs or, eventually, in containers.
<iyzsong>it's cool, and mostly in scheme, very hackable.
<iyzsong>night :o
<davexunit>being able to compose environments like this is what makes it a total win over Docker and others.
<davexunit>see ya iyzsong
<davexunit>when 'guix deploy' has been written and our container implementation supports networking, we'll be able to do what docker-compose does.
<davexunit>oh, and the other big win is that you use the same software at all layers. from the bare metal to the VM.
<htgoebel>davexunit: This is exaclty what I've read between the lines of the manual. Very impressive
<htgoebel>got to go now. see you the nexts days.
<ng0> so opensource these days is == we give you a .deb , you can look at the source code but you won't get instructions or hints on how to build it if you theoretically want to run it. good job \\o/
<davexunit>if that software were GPL it would be a GPL violation
<davexunit>if it ain't reproducible, it ain't free software.
<ng0>package.json .. is that nodejs? it is build on top of electrum
<ng0>ah... inside apm/ is a readme describing on how to "build" it
<ng0>it uses apm not npm
<ng0>i would never look inside a folder apm for build instructions
<ng0>davexunit: it is gpl
<rain1>I had similar trouble with qt
<rain1>takes almost a day to compile it
<ng0>see LICENSE. v3 or later
<rain1>it's not a nice program
<ng0>rain1: i have no intentions to package that. I was only pointed to it on another network
<davexunit>ng0: if they truly don't provide any information for users to build their own binaries, then they are violating the GPL.
<ng0>they have this apm, that's all
<ng0>from what i see
<rain1>the noscript extension is similar
<rain1>he just dumps the .xpi online
<efraim>rain1: I'm working on compiling the modular version of qt5
<rain1>and if people ask about the source? well unzip it its in there
<efraim>so we can replace the monolithic version
<rain1>that sounds like a great improvement
<ng0>davexunit: is this how opensource java based projects are these days? is it that much "fun" because everyone has just given up on package managementand expects given up as the status quo?
<ng0>i remember software shipping at least build instructions :/
<davexunit>it's a total disaster, yes.
<ng0>should've picked the totally burnout-sure-job in rigging and eventsplanning 10 years ago.. now getting into some other field is like well there are things you dislike and everybody seems to expect them
<anthk_>would be difficult to adapt the icecat derivation to create an abrowser one?
<davexunit>won't know until you try.
***piyo` is now known as piyo
<ng0>today I had one guix related question while writing notes down on finding the right ISP as I did not bury the search yet: the (currently) 20GB caches of hydra, what's the average total monthly outbound traffic consumption and what's the average total monthly inbound traffic consumption? Also same for, not the cache.
<efraim>ng0: I don't know for sure, but I think the number thrown around a few months ago was 600GB/month for, pre mirror
<ng0>oh, so little :)
<paroneayea><mark_weaver> spyware can be useful too, e.g. chromium can be useful to study how much and what kinds of personal information are sent to google, but that doesn't mean we want it in Guix
<paroneayea>mark_weaver: I though that (with the exception of that voice recognition blob that "accidentally" ended up in there) Chromium did not really phone home?
<paroneayea>mark_weaver: for one reason I'd love to see Chromium in Guix: their gnu/linux port has an actual sandbox around the application itself apparently
<davexunit>a technical issue with chromium is that they bundle the entire world
<davexunit>and no distro I know of has been able to fix that]
<davexunit>so you just have to "deal with it"
<jlicht>wasn't one of the issues with chromium the fact that it is not quite clear how everything is licensed?
<ng0>re: sandbox, it would be great to get input on that alone in guix. i have an application which was build with something like a sandbox in mind and it's a feature which gave them now almost 30 years without a security issue.
<ng0>what if a server software needs to write inside its application folder?
<ng0>was this thought of before in guix?
<davexunit>ACTION sends a NodeJS upgrade to the list
<jlicht>ng0: can you give an example? I do not use a lot of server software that does not allow you to specify the folder in which it is allowed to write stuff
<ng0>jlicht: see the inline appended chatlog in the mail i sent to the mmailinglist
<paroneayea>davexunit: yay
<davexunit>ng0: software that overwrites its own source code is just not going to work
<ng0>so guix thinks that there's no software like this out there and it should not be integrated at all into guix at this point? I see it as an interesting case to solve something where guix might be lacking features.
<davexunit>the store is immutable.
<davexunit>no exceptions.
<davexunit>now, a GuixSD service could copy from the store and populate some directory in /var to use
<davexunit>Guix strictly separates stateless from stateful
<davexunit>in this case, it seems that the application itself is state
<davexunit>it's not Guix lacking features
<ng0>it has a state, yes.
<davexunit>that said, I still don't understand this application and the developer's insistance that what it does is a good thing.
<ng0>so I could write a service in addition to the service it needs anyhow, to copy all the data to /var or /opt or whereever not /gnu/store and then work around this
<rain1>what program is it?
<ng0>you hack a psyced chat server, you can't gain root on the box itself. you hack an ircd, you can gain root.
<davexunit>I don't understand how that can be true
<rain1>just dont run IRCd as root
<ng0>that was what I have been told, there are design decision behind psyced as it is now, driven from what irc was and is.
<ng0>more technical replies you might get from lynX and/or reading the wiki on it, it's just something which exists as a basic feature.
<davexunit>it just seems like brittle, inflexible software that thinks its more clever than it is.
***Basstard1 is now known as Basstard`
<ng0>no. let me paste something back after i translated it
<jlicht>which mail client do people around here use to make dealing with all the patches on guix-devel as easy as possible?
<efraim>i like mutt for patches
<efraim>many people use emacs for everything
<davexunit>jlicht: I use notmuch with the emacs client
<davexunit>and tag mail from guix-devel
<jlicht>davexunit: notmuch is used in combination with a mail client in emacs?
<ng0>davexunit: psyced does not describe its own sourcecode. it only has programmable parts. the connected(?) editor is part of lpc. guix can not cope with this, but this is not a bug of lpc. anyway, talked this through and i know how it can be solved. resulting from this i wonder: is there no single chrooted software in guix? no chroot at all? did you just leave out this as a security decision? is there some paper
<ng0>or early videos/texts I can look into, because just trusting in the store seems not to be enough. i know guix departs from unix in some points, but why leave out chroot?
<rain1>ng0, what about guix environment -C ?
<rain1>that makes a container you can write inside
<davexunit>jlicht: yes, I use offlineimap to sync mail and notmuch to index it
<rain1>i can't understand this error message
<davexunit>ng0: I think we need to better understand the problem.
<rain1>guix/build-system/gnu.scm:274:0: In procedure gnu-build: Error while printing exception.
<rain1>just trying to build a package i made
<ng0>not really in the sense I would need it for. i assume guix environment assumes that all software is stateless?
<davexunit>you are making assertions about Guix that I don't think are true, but I don't understand psyced yet so I can't say for sure.
<davexunit>ng0: it's not 'guix environment', but that *everything* in the store *must* be immutable
<ng0>davexunit: i'm just starting to understand psyced more than I did before, so I can't really talk very much about it.
<ng0>it's a nice feature to have an immutable store, but some writeable location is sometimes needed for software which alters itself and has no static sourcecode.
<ng0>so currently i think:
<davexunit>computer systems have stateless components and stateful components. the stateless stuff gets put in the store, and in the case of GuixSD, the stateful stuff lives in the service layer
<davexunit>I use gpg from guix, but when I run it it does stateful things to my home directory.
<davexunit>there's no conflict with this in guix.
<efraim>node bundles openssl?
<davexunit>efraim: yes, and other things. it provides configure switches to force it to use shared libraries from the build environment though.
<efraim>noticed it while it was building
<ng0>guix package -i psyced -> postinstall hook activates a service which copies data outside into /opt/ or /var/ -> further hook runs the configuration of psyced, defining the data directory of psyced to be /opt/ or /var/ , where all symlinks it needs are in the structure they need to be.
<davexunit>ng0: we will not be implementing any sort of post-installation hooks
<ng0>i only described a one time service with it
<efraim>also, if you add sqlite to offlineimap and 'status_backed = sqlite' to .config/offlineimap/conf [Account] then syncing is faster
<davexunit>efraim: !
<davexunit>did not know about that!
<efraim>after taking forever to index my empty sync went down from 55 seconds to 37
<davexunit>efraim: do we need to sqlite as an input to the offlineimap package?
<davexunit>if so, we should do that.
<davexunit>send patch? :)
<efraim>will do :)
<davexunit>efraim: thanks for the review by the way.
<ng0>should I start a conversation on the ML about it so that one of the developers of the protocol (and application) could join? I was not talking about any "hook", it was just a bad choice of words. I want the service which runs psyced to copy all datafiles into a writeable location, because else the software will not work.
<davexunit>I'll clean up the style nitpicks. I'll see if anyone has any bigger problems with it.
<davexunit>ng0: I think that you should read up on how GuixSD services work and try writing a psyced service.
<ng0>i'm curently doing that.. I think from what I see it will require some more guile learning. I said I wanted to write a gnunet-service to work on and to extend later to some levels, but that's going to be less trouble (and higher priority) than psyced.
<efraim>bad news on the modular-qt front: the other downloads don't seem to ship with any way to build them, so it looks like we're stuck with monolithic
<bavier>efraim: the toplevel 'configure' script in the monolithic tarball is a simple wrapper around qtbase/configure, could we build qtbase first, and use it to build the rest?
<efraim>bavier: possibly, but there's no configure or makefile or anything for the others
<bavier>efraim: they just need qmake run, I believe
<davexunit>does anyone understand this?
<rain1> /j #python
<davexunit>don't like coreos, but like matthew garrett
<efraim>hmmm, i'll have to try that
<rain1>davexunit, do you have a saved copy?
<bavier>efraim: well, no, maybe more than that
<davexunit>"As of @coreoslinux is the first OS to publicly distribute known good PCR values for OS components"
<rain1>what is PCR short ofr?
<davexunit>don't know
<rain1>is it really the first.......
<rain1>i think they just mean putting a checksum in
<rain1>that isn't a new idea lol
<lfam>It might be "Platform Configuration Register" which is a trusted computing thing
<davexunit>that sounds right, lfam
<lfam>Having an auditable immutable store of software, with some trustable inventory of hardware, would be cool
<davexunit>I'm just wondering if there's any ideas we should be taking from coreos
<lfam>Yes, hire their PR firm ;)
<rain1>is trusted computing ok?
<lfam>My opinion is that like most tools, it's okay if you own the key. Otherwise it will be used to subjugate you
<lfam>Does anyone have a way to keep their GuixSD / GNOME laptop from sleeping when they close the lid?
<lfam>Also, has anybody else had an issue with a "scrambled" GRUB menu?
<keverets>rain1: in general it's not a bad idea. All current implementations in practice are not good for software freedom:
<lfam>I think the idea of trusted computing is broader than the Intel ME
<lfam>I think the ARM TrustZone stuff could be on the side of the user, although my very limited understanding is that it's really full of holes
<rain1>I'm not able up bump python3s version up, ctypes compile error
<lfam>rain1: Did you see the WIP update of python-3 on the mailing list a few weeks ago?
<lfam>Actually, it starts here:
<lfam>Hopefully that helps!
<efraim>python-2.7.11 has been sitting in core-updates for a while now :)
<lfam>Cool, just where it belongs ;)
<rain1>that's the same error i get!
<lfam>efraim: I want to update setuptools
<lfam>rain1: If you follow the thread, I think she resolved that error but had some other issues
<lfam>efraim: Any advice on packages to test the update with? Like, the really important python leaf packages?
<efraim>i think some of the bio packages are python packages
<lfam>Yeah, I really don't want to break those
<efraim>python-cython is one I try to stay away from though, really long build time
<lfam>Heh, that's why it *has to work* for our users ;)
<lfam>Worthy of a local test
<civodul>alezost: upon "M-x guix-licenses", i get: "funcall: Symbol's function definition is void: guix-list-get-url"
<civodul>even though guix-licenses.el requires guix-list
<alezost>civodul: well, I don't have this error :-) Could you check (featurep 'guix-list)
<alezost>civodul: also look at "M-x find-library guix-list" and check if there is 'guix-list-get-url' function there (it was introduced in commit 6dd460c 2 months ago)
<alezost>wait a second, I thought "M-x guix-licenses" worked for you, didn't it?
<ng0>can we define dns resolvers to use in the system config via a service already?
<ng0> <- doesn't look like it
<lfam>So, what's the best method for picking up changes to my user's init.scm?
<lfam>Should I just kill and restart my shepherd daemon?
<ng0>You know, i had this idea about being able to just deploy an OpenNIC tier2 server with some toolkit/script, or at least for users.. That's doable with an guixsd service i think. that wasn't what I asked about, but I remembered this
<rain1><sugam> Hi all, i deleted an important tarball from my /gnu/store/ dir (3fx2sz92g8j6z152j3yjq203p87v7q7q-gcc-4.9.3.tar.xz) without successfully finishing compiling GCC 4.9.3, and now i cannot run guix build hello:
<rain1><sugam> guix build: error: build failed: getting attributes of path `/gnu/store/3fx2sz92g8j6z152j3yjq203p87v7q7q-gcc-4.9.3.tar.xz': No such file or directory
<rain1>relaying a message for someone - if anyone knows what they should do i can tell them
<lfam>You really have to jump through some hoops to delete files in /gnu/store
<rain1>I suggested a guix system reconfigure but I don't know if its the best approach
<lfam>The whole system assumes that the store is immutable
<lfam>I would try to do `guix gc -d /gnu/store/3fx2sz92g8j6z152j3yjq203p87v7q7q-gcc-4.9.3.tar.xz` and then see what happens
<lfam>It would be easiest and sugam was in this channel
<lfam>"easiest if sugam"
<rain1>they said that freenode blocks tor
<rain1>so I asked if tehy'd like me to relay
<civodul>rain1: they could try "guix gc --verify"
<civodul>but removing/modifying files from the store voids one's warranty :-)
<rain1><sugam> Oh that suggestion worked, thank you to lfam!
<rain1>sent thanks civodul too :)