IRC channel logs
2016-11-30.log
back to list of logs
<civodul>nckx: you're welcome to join that team though :-) <civodul>just don't subscribe to the list if you're looking for stuff to read ;-) <nckx>civodul: thanks. I've considered, but I wouldn't feel comfortable making that kind of commitment right now. Mainly lack of time, and a long pipeline: I've been beaten to every CVE I've started to fix by lfam. <nckx>...which is a good thing! To the hard-working group of people pretending to be the individual lfam: lfamsnack. <nckx>If subscribing would make me part of a team, I'd rather not be on it. ;-) <Sleep_Walker>I thought it is related to some older problem but it may not <mekeor>Q: weird. guix-daemon is running and i'm still getting "Connection refused" error when i run `guix pull` or whatever. i just installed guix (on debian). should i reboot maybe? <jin>hi jje, how do you deal with variable for network-manager-service ? <buenouanq>what does the roadmap for getting GuixSD on ARM boards look like? Is this even being thought about yet? <buenouanq>I have a BeagleBone Black I want to put it on. <marusich>buenouanq, there has been some work, but there is a lot left, I think. Search for "arm" and similar keywords on the guix-devel and help-guix mailing lists. You'll find some past discussions that will help you see what the current status is. <jin>jje: my config file is similar, i will rewire again, to avoid errors! thanks <marusich>jje, why is wpa-supplicant in your packages field? <marusich>My understanding is that network-manager will work even if you don't install the wpa-supplicant package into the system profile. <jje>so network manager will work with wireless? or is that unnecessary now? <marusich>What I mean is, because you have network-manager-service and a service of type wpa-supplicant-service-type in your list of services, it isn't necessary to install wpa-supplicant as a package into your system profile, unless for some reason you want those tools available for some reason <marusich>I suspect that if you remove the wpa-supplicant package from your config.scm, network manager will still work fine with regards to wireless. <jje>ah i see i will change that. thanks for the tip! <marusich>If it doesn't work, feel free to let me know I'm wrong :) <marusich>If you're using network manager, I'm curious: does "auto connect" work for you? <jin>marusich: I will do tests later to review that detail <jin>I got a network card <jje>jin: mine said that too but works anyway after a reboot <jje>marusich: i could not get auto connect to work on wireless either <marusich>OK, good to know. Something is wrong. I wonder if you can find any error messages? I had trouble finding any. <jje>i will keep an eye out for one next time i login but where would on look, dmesg? <marusich>jje, maybe. I think maybe you can start NM from command line, too, in which case you might see additional warnings/errors on the terminal - not sure what the command is, but it probably lives in the 'network-manager' or 'network-manager-applet' packages. <marusich>jje, I am honestly not sure how to troubleshoot GNOME applications in general, or where they usually log their messages. Seems to me like usually something in /var/log, or the stderr/stdout of the process itself, is most useful, but perhaps a GNOME expert can tell us where to look for additional info. <marusich>When I've troubleshooted those kinds of programs in the past, I've looked in those places, and resorted to Internet searches to find useful info on what else to check. <jje>ok marusich i will stick around to see if anyone says anything pertinent to gnome <buenouanq>we have until the end of may to get GuixSD working on ARM <paroneayea>so through a lot of bad hacks I have an image imported into rackspace. <ZombieChicken>I know this is a bit off-topic, but does anyone here use FoxyProxy? <jmd>What does & do in regex? <Sleep_Walker>chm, dmenu segfaults on function from libx11 depending on current locale :/ <jmd>It's quiet here this morning. <marusich>I'm trying to get GuixSD running on an Amazon EC2 instance. <wingo>that would be pretty neat tho! <marusich>wingo, I got the installation image working. <marusich>Originally, I thought I would just try to do it that way, and then follow the manual to install it on some other device. Although that will probably work out, I think it may be simpler to just do "guix system init" on a loopback device, backed by a file, and then copy the file onto a device in "the cloud". <marusich>Conceptually, I just want to init a device and then copy it block for block onto an EBS volume which I can attach as root for an HVM instance; then it should "just work" when it launches. <rekado>‘config-domain-strings’ for the nginx-service seems to be wrong. It should join the domain names with a space. <civodul>rekado: indeed, same for config-index-strings no? <civodul>ACTION packages Nagios with its CGIs and its PHP thingies <marusich>civodul, is there a trick to managing the cognitive complexity of the Scheme code that generates images? I have trouble following the logic for commands like "guix system disk-image" which involve multiple layers of Scheme code being used to build things. <marusich>How do you navigate the code in your head...? <civodul>which part do you find hard to follow? <civodul>if you understand what's going on in that file, you get the big picture, i think <marusich>I have a hard time maintaining focus on what I am trying to understand, because there are lots of layers and I get lost going back and forth, mainly. <marusich>Also, I'm still not quite sure how the modules are supposed to be organized. Is there like a "map" of the modules which clarifies the intended use of each one? <marusich>I guess I'm not being very clear. I was just hoping perhaps you had some tips on how not to get lost in the code. <marusich>e.g. tools or commands you often use to anchor yourself or find your way around <civodul>and often, i add "pages" inside files, which you can navigate with C-c C-] <marusich>I use Geiser, but I suspect I'm not taking full advantage of it <civodul>i add "pagefeeds" to separate important sections of the file <civodul>M-. is the part of Geiser you want here <civodul>in (gnu build vm), the top of the file is "low level", and the bottom is "higher level" <marusich>On the positive side, I have an EC2 instance running GuixSD now :) <civodul>you should reply to paroneay` on help-guix <marusich>as soon as I can confirm that running "guix system reconfigure" on it won't blow it up, I'll send an email. <civodul>and you can promote your employer's fine services ;-) <jmd>civodul: Regarding your comments about @code{mit-krb5}, this config file will *probably* also work with other Kerberos implementations - although I haven't tried it. I was trying to keep the documentation as generic as possible. <civodul>jmd: sure, then you can write that explicitly <civodul>but i think there were other comments in my initial review <civodul>like giving a bit of context in a paragraph <civodul>i say that as somone who remains intimidated by Kerberos ;-) <jmd>That is understandable. <jmd>For that reason, I don't wish to make the documentation even more intimidating. <jmd>Implementation details don't belong in user documentation IMO. <civodul>i don't think we discussed the documentation of implementation details <civodul>what i suggested is to give more context as to what it does, why it matters, and how it can be used <jmd>Like everything, it is subjective. I would consider the fact that it writes a file /etc/krb5.conf to be an implementation detail. <jmd>Perhaps it is useful to know for someone familiar with hand crafting those files, but for others it is superfluous information. <jmd>It's hard to find the right balance when writing documentation. <civodul>IMO it's useful because it tells people what effect it has on their system: it doesn't start a daemon, it simply creates this file <jmd>ok. I will mention that then. <jmd>I wish that when Julien refactored that stuff he had taken my factors into consideration. <rekado>civodul: I’ll fix them tonight. Currently trying to migrate my web server from a VPS to a Guixified netbook. <marusich>Is it possible to define a 'user ssh key' in the operating system configuration file? Or do I have to make the user account, then deposite the ssh public key into authorized_keys myself? <marusich>I suspect it isn't something you can just specify in the operating system config file right now, but I wanted to double check <civodul>jmd: at one point we had two copies of that stuff in the tree, and another two copies submitted <davexunit>marusich: there's nothing for this currently, though somewhere around a year ago I wrote a user-file-service that never got merged. <davexunit>that could be used to handle putting files into stateful locations <jmd>... maybe I should have just renamed it and made some minor mods after I copied it. Then nobody would have realised it was a copy ... <marusich>davexunit, I see. Cool. Also, is there a way to do something "one time at first boot" in a GuixSD system, I wonder? <jmd>(like I used to do at school! <davexunit>that goes against everything GuixSD is about <davexunit>if the only the first generation of a system did some side-effect <davexunit>unless I'm misunderstanding what "first boot" means? <marusich>that's fair; I'm just curious because in the world of EC2, generally you launch an instance and provide the service with an SSH public key you want deposited into the instance to give you access <rekado>marusich: you can cheat by creating a service that writes a file to user storage when it’s done and doesn’t do anything when the file exists. But that’s ugly. <marusich>For example, Ubuntu uses a "cloud-init" package which, among other things, deposits that key into the ubuntu user's ~/.ssh/authorized_keys file, giving you access. <davexunit>a system service that creates ~/.ssh/authorized_keys on boot is fine <marusich>In EC2, at least, it would be useful to have a feature like that. Elsewhere, it would still be nice to be able to at least specify the public key you want to use for SSH login, in the operating system config file, so that you don't have to start the server, then go in and modify some files. <davexunit>I think you're just misunderstanding something <davexunit>and are being too quick to give up properties that make GuixSD an improvement over other distros <davexunit>surely the problem can be solved without such a sacrifice <jmd>marusich: Why would the keys have to be created on boot? Why can't they be created at guix system init ? <marusich>they can't be right now because there is no such feature <marusich>They don't have to be created on boot; it would be nice to have the ability to say "this user has key X" in the same way we can currently say "this user has password Y", in the config file, so that running guix system init deposits the public key in the user's home directory. <jmd>I can't see any problem with that. I think davexunit is talking about something different. <sovra1>Hello i'm here for a wi-fi module problem when i run: wpa_supplicant -c wpa_supplicant.conf -i wlp16s0 -B <sovra1>Successfully initialized wpa_supplicant <sovra1>Could not set interface wlp16s0 flags (UP): Operation not permitted <sovra1>nl80211: Could not set interface 'wlp16s0' UP <sovra1>nl80211: deinit ifname=wlp16s0 disabled_11b_rates=0 <sovra1>wlp16s0: Failed to initialize driver interface <rekado>marusich: I think for public keys it should be fine to generate a file in the store that users can then link to. <jmd>sovra1: Are you root? <marusich>davexunit, I can understand what you're saying. I wasn't suggesting we SHOULD use cloud-init or something like it; I was just trying to point out that if someone wants to run GuixSD on an EC2 instance, then they will need a way to log in. <rekado>marusich: but that wouldn’t help for users who can’t log in remotely. <sovra1>no but i use sudo but the driver is there <sovra1>10:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02) <rekado>marusich: at the moment we don’t change anything in /home during system configuration. <davexunit>marusich: that's easy. build a systemt that starts the ssh daemon with their public key authorized. <davexunit>I don't see the need for having that *only* happen if the system being booted is the first generation. <marusich>davexunit, sure, that is fairly easy, but the trick is making it convenient for use in EC2. It is not super convenient to take that image and convert it for use on EC2; most people using EC2 expect to be able to launch an instance from an AMI and inject some secrets so they can log in. I'm not saying that's the right way; I'm just saying that's the usual way it's done in EC2. Is that not reconcilable with the way GuixSD should work? <davexunit>marusich: the AMI should be made such then when you boot it the correct users have ssh access <marusich>davexunit, how would you feel about an AMI with a default user and password? <davexunit>that's not the system that you really want to deploy. <davexunit>I think we're getting hung up on the tradition of spawning a VM from a base image and then proceeding to mutate it until it does what you want. <davexunit>with GuixSD, we can just spawn a VM that is precisely what we want from the get-go. <marusich>davexunit, how else would you get your GuixSD image into EC2, though? <davexunit>build system, upload AMI, create instance, boot instance. <marusich>can you elaborate on what the step "upload AMI" would look like? <davexunit>AWS has an API that one could use to upload an AMI <davexunit>that AMI would the image corresponding to the GuixSD OS configuration to be instantiated. <marusich>Well, that's a good idea. Do you recall which API that is? <davexunit>consult the AWS documentation for that, or maybe see how boto, the python client, does it. <rekado>need to package this quick to get git.elephly.net up <civodul>i'd like to move the SSH part of it to Guix proper <marusich>Anyway, you're probably right that something like that is a better long-term solution for using GuixSD with virtualization services like EC2 <davexunit>AFAIK OpenSSH reads authorized keys from user home directories only <davexunit>marusich: eventually 'guix deploy' will exist and can automate all of this stuff. <marusich>OpenSSH can read authorized keys from directories that are not in users' home directories <marusich>You could set the AuthorizedKeysFile to an appropriate value which points to some absolute path; check sshd_config <davexunit>marusich: ah! that would be *much* better to use than putting files in home directories then <marusich>Apparently you can even set AuthorizedKeysCommand to run some arbitrary command to get the keys. <davexunit>we could just point sshd at a file in /gnu/store <marusich>wouldn't we need one file for each user? <civodul>davexunit: yeah lsh only; we need something like your user-file-service for OpenSSH <davexunit>the openssh service can generate a configuration file that does something different <davexunit>we can generate a key file, one per user, and put them in the store. <davexunit>a derivation could produces a directory with files like: civodul_authorized_keys, davexunit_authorized_keys <davexunit>and in the ssh config we'd have a line like: AuthorizedKeysFile /gnu/store/xxx-authorized-keys/%u_authorized_keys <davexunit>openssh substitutes "%u" with the username being authenticated <marusich>Anyway, I confirmed that running "guix system reconfigure" on my EC2 instance didn't blow it up. <marusich>I'll send an email about what I did. And point out that what davexunit was talking about is probably better in the long term. <davexunit>for now, I think providing some base AMI that has a default root username/password is OK <marusich>the process I followed didn't require that - i just used an existing ubuntu AMI to launch an instance from which I did the necessary writes <marusich>I basically just did a system init into a loopback device...and then copied it onto an EBS volume, which I then mounted on the formerly-Ubuntu instance's root. <civodul>that prevents the addition of new authorized keys by users though <davexunit>so it can search where I said *and* in user home directories like normal <lfam>Any hdf5 users? The latest release, 1.8.18, is available from a different URL. It includes some security fixes. <lfam>Any suggestions about how to handle that URL, specifically how to get '18' out of the version string? <bavier>lfam: I was looking at updating to 1.10 last night, but until I finish that, updating to 1.8.18 sounds good <bavier>the url shouldn't need to change <lfam>This release isn't available with the current URL in our package <lfam>I think we should make a list of URLs <lfam>We could use 1.10 instead; that's available where we expect <bavier>lfam: the 1.10 url needs to be adjusted too <bavier>since they started using a different directory structure <bavier>yeah, weird that they didn't put 1.8.18 at their ftp url <lfam>Neither the commit hash nor the commit message are found from the 1.10 tag <bavier>does 1.10.0-patch1 have the fix? <lfam>Not AFAICT. The commit message doesn't appear from there <lfam>Assuming the Git commit dates are roughly chronological, 1.10.0-patch1 predates 1.8.18 by ~6 months <lfam>I'm going to cherry-pick the relevant commits and send a patch to guix-devel for review <lfam>Well... that's more work than adding the new URL for 1.8.18 <bavier>lfam: sure, I think upgrading to 1.8.18 for now to fix the CVE should be fine <bavier>the 1.10 upgrade might break other packages, e.g. netcdf <lfam>Any advice about how to get the 'current18' string from the version? I assume that represents the first two elements of the version, not the third element <lfam>Or, we could just hard code it for now <davexunit>now if only I could implement half the things I talk about on here... <lfam>marusich: Can you send a message to guix-devel about running on EC2? I'm interested <davexunit>I'll just keep spitting ideas out, you folks implement them! <lfam>sneek: later tell marusich: Can you send a message to guix-devel about running on EC2? I'm interested <davexunit>new idea: a hook to order pizza upon successful 'guix system reconfigure' <bavier>lfam: (apply string-append (take (string-split version #\\.) 2)), maybe? <bavier>but hard-coding should be fine, since it'll change for the 1.10 version <rekado>FYI: on this new GuixSD system ‘su - rekado’ as root asks me for the password of user ‘rekado’. <lfam>bavier: Okay, I'll try that, or hard-code it. I'll push it as soon as it build <rekado>It fixes the GCJ build that I broke a few days ago. <davexunit>wingo: lately upgrading a system has been rather painful and taken so long that I wish I had a pizza by the end of it. hmm, maybe the pizza should be ordered during the reconfigure. <lfam>rekado: Yes, I think you should go ahead if it works for you <wingo>or just order pizza and put off the reconfigure until another day <lfam>davexunit: By painful, do you mean that it breaks part-way through, so you have to attend to it personally? <rekado>lfam: pushed. I tested this yesterday (obviously I didn’t rebuild GCJ on armhf). <lfam>I usually start long-running things before bed time, but that's no good if they won't complete on their own <davexunit>lfam: something either breaks or tons of stuff needs compiling and the computer is out of commission for the day. <lfam>Broken stuff on master should be reported so we can fix it :) <davexunit>or, like yesterday, I ran 'guix package -u' and the compilation of something froze my machine. <davexunit>I was able to recover by hibernating it and then quickly killing the process <davexunit>I have 4GiB and with icecat open... not much space left I guess. <bavier>I've had that happen, had to re-enable swap recently <paroneayea>there has been a lot of not-substituted packages lately <davexunit>I ended up cancelling my package update when I saw that icecat was going to be compiled <rekado>davexunit: I upgraded to 8GB on my X200s just to be able to build stuff while Icecat is running. <davexunit>anxiously awaiting the day when we have a new hydra. <lfam>Soon I hope! I saw that Mathieu pushed a cuirass-service yesterday :) <davexunit>for now, I am very careful about what I build and do not do full system upgrades. <lfam>bavier: I pushed the hdf5 update <rekado>I do full system upgrades usually, but when I see that a lot of things need to be rebuilt I exclude specific packages from the upgrade. <lfam>Thanks for your help. I just realized I should have credited you in the commit message. Sorry :) <dvc>hey! can someone explain what staging refers to? :) <dvc>oh, now I get it. git branch -r doesn't show me new branches... <dvc>did git remote update and now it makes sense... <lfam>dvc: Staging is somewhere between master and core-updates. It's for changes that require between 300 and 1200 rebuilds and aren't likely to cause lots of breakage. We plan to merge staging branches every ~3 weeks <civodul>rekado_: the gcj patch could be applied unconditionally, or i guess you wanted to avoid rebuilds of IcedTea? <rekado_>civodul: I tried building gcj on non-arm and it failed somewhere down the line. <rekado_>so i think it must be applied conditionally <rekado_>I got a couple of complaints from users about broken packages and it all came down to gcj :-/ <civodul>rekado_: oh makes sense, i hadn't noticed the patch used ARM-specific options <civodul>rekado_: complains regarding gcj in general, or on ARM? <rekado_>about some other packages that couldn’t be installed because they ultimately depend on GCJ <rekado_>I had updated our central installation a little too early… <dvc>civodul: trying the sddm-service today I noticed it's broken. how hard would it be to write a system test for it? can ocr detect textboxes and type a username and password like with encrypted-root-os-test? <bavier>civodul: I like the updater coverage report! <baconicsynergy>Hi Guix! I've gotten the hang of the OS, but I want to start getting better. What are some good lisp/scheme/guile tutorials/guides for beginners? <bavier>dvc: it seems like the system test marionette supports character recognition only at the moment <bavier>I imagine it could be extended with image recognition <ng0>baconicsynergy: "pamphlet against r", and there was one other not-so-long read <ng0>it seems like cuirass is ignored in my config <dvc>bavier: so it would take quite a bit of work. can you think of any other services that would benefit from it? like gnome or xfce services? <bavier>dvc: it would probably be quite powerful, if it could simulate any user interaction in a graphical environment <bavier>tests for SLiM, screensavers perhaps <bavier>maybe suspend/hibernate from gnome/xfce <ng0>I tried with moving the (let) in services around, with let* or any kind of typo I could've made <ng0>result so far is silent ignorance <efraim>qjson updated to 0.9.0! with qt5 support! <ng0>if we only had the go-build-system already, I could package a go bitmessage client which does not rely on qt4 <ng0>it fits right into the discussion we had at some point with peter surda. I no longer see that it's possible to discuss with them as they set strange priorities. I'd rather switch the client <ng0>*we had at some other list and place with <baconicsynergy>hmm it appears that arc-theme isn't being found by lxappearance ootb <baconicsynergy>env | grep -i gtk --> GTK_DATA_PREFIX=/run/current-system/profile <Sleep_Walker>I noticed that packages using libXft and freetype2 have problems with locating ft2build.h (because Xft.h contains #include <ft2build.h>) <Sleep_Walker>at least those with simple build system like suckless.org ones <Sleep_Walker>is it possible to add ft2build.h path to CPATH on freetype package side? <Sleep_Walker>(IOW If something requires freetype, it will get correct path in CPATH in the build environment) <ng0>so, has someone tried cuirass, or am I the first? <Sleep_Walker>it would be nicer than fixing [arguments] for each package definition <bavier>Sleep_Walker: we could maybe propagate the freetype input of libxft <bavier>or submit bugs to the codes that aren't building correctly :) <Sleep_Walker>like for building against freetype should be used -I/path/to/freetypes/include/ -I/path/to/freetypes/include/freetype2 <bavier>Sleep_Walker: then propagating probably won't help <bavier>the packages would need to be fixed <Sleep_Walker>but still, it would be nice to have a way to express some extra CPATH for the package <baconicsynergy>Since I'm not yet ready to help create packages, what would be the proper channel to recommend new packages? <bavier>civodul: speaking of updaters, I have a prototype cpan updater. I'll see if I can dust it off. <Sleep_Walker>is there reason to keep it at the old version (besides the huge subtree of dependencies) <baconicsynergy>stumpwm is on the wishlist, but there are multiple stumpwm packages. should I go ahead and wipe it? <rekado_>baconicsynergy: for a Scheme intro I recommend taking a look at the “Hello Scheme!” section in the Guile reference manual. <rekado_>baconicsynergy: it also contains pointers to further reading material <rekado_>I’m serving my website from Guix nginx now, but it seems that something’s wrong with the mime types <rekado_>browsers refuse to show the stylesheet, and its mime type is text/plain, not text/css <rekado_>maybe something wrong with the default configuration <davexunit>(our configuration interface for nginx could be improved, but I'm not sure how) <dvc>cool, I added some packages to the wishlist. I wonder if anyone thinks oh I'm kind of bored, let's checkout the wishlist for something to do =P <rekado_>davexunit: we should also have syntax for location directives. <rekado_>and maybe an escape hatch to include plain text snippets <rekado_>also: nginx seems to have /gnu/store/ as its working directory <rekado_>“include mime.types;” will make it try to load /gnu/store/mime.types, which isn’t there. <davexunit>rekado_: you need to use the full file name for that file <davexunit>also, it's not clear how to make configuration syntax for nginx. <davexunit>and furthermore, the set of directives isn't limited to just nginx <davexunit>so our Schemey nginx configuration language seems doomed to always being inadequate <lfam>The nginx configuration system is basically a programming language, right? <davexunit>but there are just lots of directives, and many possible types of values <lfam>I wonder how far you could go. It has conditionals, variable scoping, what else? :) <lfam>It's not just a list of keys and values like many configuration systems <civodul>dvc: it'd be much simpler than the installation tests; you'd have to use OCR to know when to type things in <lfam>It seems like a parallel world to me :) <rekado_>davexunit: I’d say we shouldn’t have to input the full path to files like that. ISTR that nginx supports setting a default working directory. <davexunit>it's kind of the guix way to use absolute file names, though. <lfam>Somebody with a libreplanet account can remove BIND from the wishlist :) <rekado_>true. I’ll have to see if I can use gexps there. <rekado_>it’s nicer than using some really long /gnu/store path there. <davexunit>long-term of course I think we should have some high-level interface <rekado_>can’t we just translate an sexp to the nginx syntax? <rekado_>without having to know anything about supported directives? <rekado_>then we can write and manipulate sexps as usual and translate them to what might be gibberish or a real configuration <rekado_>(I did something like that to write R with sexps) <ng0>civodul: did you try cuirass-service? you had plans for bayfront iirc. I tried today and I hope my config is just wrong <dvc>civodul: I'll have to give it a try. Still struggling to get a btrfs-root-os test to run, and I realized that sddm works in a vm but not on my laptop, which is weird... <davexunit>do we validate the values for directives in any way? <dvc>lfam: do we have a bind service? <dvc>I thought about removing it before <lfam>dvc: I didn't realize the wishlist for a service. I was just thinking about packages. I agree that a service would be desirable <lfam>*the wishlist is for a service* <civodul>ng0: not yet, will try Real Soon, but i've been told it's not production ready <civodul>dvc: re btrfs, two things: lookup by label/UUID is not supported for btrfs, and installation tests are kinda hard (or boring) because you have to rebuild Guix + boot the installation image + run the install + boot the installed system <ng0>I already messaged mthl, for gnunet there's no immediate rush. I just tried today and wanted to figure out why it's not starting the servie <civodul>dvc: i'd recommend starting with a simpler test, you can look at the mcron or "basic" tests <rekado_>bleh, have to include mime.types in the server definitions, not in the http section. <rekado_>this means I can’t use any of the abstractions we have :( <ng0>tried some variations of the config, but none succeeded so far <civodul>coming up with the right abstractions for nginx.conf seems really hard <civodul>i think we can only provide abstractions for selected use cases <dvc>civodul: I know that lookup by label is not supported, how do you know? Any idea why? <civodul>dvc: we don't use blkid and all that; instead, lookup by label/UUID is home made, in (gnu build file-systems) <civodul>i suspect it can be added in less than 2 hours once you've found the documentation for the btrfs superblock format <dvc>I've been ripping my hair out over that one =P <lfam>Has anyone here migrafted from an HDD to an SSD? Did you notice a big Guix performance difference? <rekado_>lfam: I’m using GuixSD on laptops with and without SSD. <rekado_>startup is quite a bit faster with the SSD. <civodul>lfam: "migrafted", that's a Freudian slip no? :-) <lfam>I'm guessing that operations using /gnu/store will be a lot faster <lfam>civodul: Too much grafting ;) <efraim>guix gc is much faster on an ssd <lfam>Right, I'm waiting for `guix gc` right now! <ng0>so far I fear if I do not buy very expensive SSDs, the only difference would be that the SSDs go faster towards being no longer usable / dead <civodul>i've been using an SSD since before i started Guix development, and it's pretty fast indeed <dvc>I can't remember not using an SSD :) <civodul>i've been told GC and other operations are slow on spinning disks <lfam>I have used SSDs, and they are very fast, but I've never migrated a system that uses Guix <lfam>I assume that /gnu/store is a pathologically bad use case for HDDs <ng0>but aren't consumer grade ssds horrible? <civodul>lfam: not as such, rather GC itself is pathological <lfam>ng0: That might be true. My feeling is that *if* I can afford an SSD, it's worth the time I will save afterwards <ng0>I mean there are 2 kinds of memory used, and the cheaper ones wear out faster <lfam>And I think that the computer is meant to be used up :) <dvc>samsung isn't bad. I started buying ssds when they where 1$/GB now they are probably half that or less <lfam>It all breaks eventually :) <ng0>2TB and above are still not affordable for me, while 4+ TB hdds are <rekado_>I have spinning disks for archive type storage <lfam>I read that article, rekado. It took a lot of writing for the first one to die. Those lifetimes are more than acceptable to me <lfam>I found it interesting how the Intel model gradually accumulated bad sectors <lfam>I assume the Corsair was misreporting failures <ng0>last I checked 250GB SSDs were equal to 1.5TB HDDs <efraim>I have a 120 GB SSD that I bought about 4.5 years ago, SMART status says I've used 3% of its health <rekado_>they live long enough for my purposes. <ng0>that's about as long as the 4TB ones I have last usually <lfam>Hm, I have a new bug. Rather than enlarge my /tmp, I sometimes set TMPDIR to something in my home directory, which is very large. Recently I hit this problem: <lfam>guix build: error: build failed: while setting up the build environment: changing into `/home/leo/tmp/guix-build/guix-build-hello-2.10.tar.gz.drv-0': No such file or directory <lfam>But, `ls -l /home/leo/tmp/guix-build` shows that it does exist <lfam>Well, that ~/tmp/guix-build directory exists. <lfam>And the guix-build-hello-2.10.tar.gz.drv-0 build directory is created and removed <lfam>Can you elaborate, paroneayea? <paroneayea>I've had a few friends have some pretty large failures on SSDs <lfam>I've heard that the failures are relatively catastrophic. OTOH, I'm confident in my backups, since I restore from them often. <paroneayea>I guess I worry about encryption also not being as good though I don't have evidence for it <lfam>Encryption provided by the storage firmware? <paroneayea>eg, "shred" wouldn't work, though I encrypt a whole partition anyway" <paroneayea>I really don't have a lot of basis to my fears I guess <lfam>Hm, I hadn't thought about that, or read about it <civodul>lfam: re TMPDIR, i think nothing has changed in this area lately, that's weird <paroneayea>swap is also a no-go though I guess I don't even have swap turned on right now :) <lfam>civodul: strace reveals that the tarball is missing from the store <paroneayea>I don't have swap on anyway because we don't have encrypted LVM working yet in GuixSD afaik :) <ng0>you can have an swap file <efraim>I changed swap on my SSD from a 1GB swap partition to add a 4GB swapfile when I started with guix <lfam>Right, but I don't mind. My attitude towards machines is that they exist to be used. Assuming that I can afford it, anyways <lfam>Destroyed them? Many computers ship with SSDs now. Do those systems not use swap? <lfam>I only get so many rotations of the HDD, too :) <efraim>the drives lifetimes can basically be measured in drive-writes-per-day, even with tons of compiling I'd be hard pressed to write so much to the disk that it'd be a problem <bavier>after reading that techreport study I'm not so worried anymore about swap on my SSD <civodul>paroneayea: you could set (swap-devices '("/dev/mapper/the-encrypted-swap")) and it should kinda work <paroneayea>civodul: then wouldn't I have to type in another passphrase at boot? :) <rekado_>:( can’t get nginx to set the correct mime types <lfam>I like Stack Exchange in general, but not Ask Ubuntu. Whenever I read a question that I know the answer to, the existing answers are usually wrong :/ <rekado_>I’m including the mime.types file in each server section now, but it doesn’t help. <bavier>paroneayea: would a swapfile that sits in your encrypted partition work? <civodul>paroneayea: right, but you can certainly type very fast ;-) <lfam>The SSD will get used up. That's fine with me :) I want things to go faster <rekado_>(maybe something wrong with this version of nginx?) <paroneayea>civodul: I mistype my passphrase so many times sometimes when I try to unlock my machine that it screws up boot and I have to reboot! <lfam>Sounds like a feature, not a bug :) <paroneayea>well except that it keeps turning on other things ;) <paroneayea>so a daemon that is dependent on reading from /home/ possibly might either not turn on or turn on too soon <lfam>From my strace, I find that /var/log/guix/drvs/xv//9vdk2dijx6nnl8hsawffwfnfmm5vny-hello-2.10.tar.gz.drv.bz2 is 14 bytes <ng0>I think I will post my experience (or lack of such which resulted in experience) with cuirass to the mailinglist <paroneayea>ng0: what's cuirass? I've heard it come up a lot lately <ng0>the gsoc project to replace hydra <ng0>and also eventually serve as general CI <ng0>i'm interested in using it instead of hydra for us at gnunet.. but there's no push to change immediately from what there is now (buildbot) <efraim>i made some progress today on perl updates, made it through databases, xml and mail, up to perl-i* in web.scm <paroneayea>I think that one's safe to merge into master without hitting core-updates, wdyt efraim ;) <paroneayea>ACTION apparently not helpful for anything today <efraim>i almost put mpfr in staging, I forgot its an input for gcc <roelj>Have the patches for EFI booting been accepted yet? <efraim>rm no longer accepts shortened variants of the --no-preserve-root option. <civodul>roelj: i think the patches are still pending <roelj>civodul: I think so. In collaboration with Danny I think. <bavier>efraim: 'guix refresh -l' is still an approximation :) <efraim>i've come across that also with libva <roelj>I'm too afraid to try it on my only computing device I have at the moment, but I would love to boot GuixSD with EFI and btrfs. <efraim>i'll have to find the patches, I have a spare overheating macbookpro that I can try it out on <roelj>It'd be a great feature addition for the 0.12 release ;) <roelj>Also, when will Guix get out of beta? Could we maybe say that "base functionality" is stable, and new features are "beta"? It surely would help convincing people Guix is stable enough. <civodul>roelj: could you ping Marius re EFI? <bavier>we'll need to go to "gamma" first :) <civodul>Guix itself is more "gamma" than "beta" now, the main remaining problems being 'guix pull' and inefficient grafts <roelj>But I think Marius has provided working patches already. So it's up to others to try. <civodul>GuixSD is kinda "beta", and some important issues have just been fixed <civodul>roelj: ISTR there were GRUB changes that i reviewed and which were fine no? <roelj>civodul: grub-efi, efibootmgr and efivar <roelj>So, does this mean GuixSD is bootable using EFI? <rekado_>basic auth and autoindex don’t seem to be working in our nginx <rekado_>I took the same nginx configuration that I used on my debian VPS, corrected a few paths, and it’s behaving differently <rekado_>maybe our nginx doesn’t come with all modules <civodul>roelj, efraim: looks like only the GRUB part wasn't merged <bavier>after each release we get enough inquiries about iso images that we might want to have that before moving out of beta <civodul>seriously, i was used to 'genisoimage', which was quite simple, but here i'm a bit lost <roelj>Why don't we use genisoimage then? <civodul>but yeah, maybe there's a very simple solution lying around <roelj>If only there was more time in a day :) <dvc>roelj: only the packages where added, it looks to me like that's still in the future... <roelj>dvc: Well, I think Marius had gotten a EFI boot to work on his own machine. He e-mailed me a GuixSD configuration as well. <roelj>dvc: I guess I'll have to try.. I could go buy a cheap hard disk tomorrow <dvc>looks like I missed some interesting stuff, need to check the ML <efraim>Paste the config somewhere, I can try to work on it tomorrow <roelj>Well, that's all I received from Marius. The rest can be a regular GuixSD configuration. <dvc>awesome! I'll have to try it... <roelj>Please let me know whether you've succeeded. I'm tempted to buy an extra hard drive tomorrow and try it out this weekend.. Not sure if I can postpone work though. <civodul>here's a deal: i provide a Nagios package, and an expert provides a Nagios service for GuixSD <dvc>I probably won't get around to it before the weekend, since I'm recommissioning my old laptop before migrating this one. And if I don't get it done by the end of the week I'll have to use whatever is working till the end of the semester :) <dvc>anyway got to go. bye guys!