<mark_weaver>osmano807: that's very odd. you mean that after running "guix system reconfigure" with the config that includes console-keymap-service, grub.cfg becomes empty? and then if you reconfigure again without console-keymap-service, the grub.cfg comes back? <mark_weaver>it seems that all other distros that use firefox or derivatives have simply updated their users to esr38, since mozilla is apparently no longer providing security fixes for esr31. <osmano807>mark_weaverÇ If I use "br-abnt2", it becomes empty. If I use "fr", grub.cfg is correct, but it becomes stuck in booting <mark_weaver>and when I asked about this on the gnuzilla ML, someone responded with "How soon can you post your contributions to the git repo?" <mark_weaver>osmano807: when you run 'guix system reconfigure', you should see it mention that it will build /gnu/store/...-grub.cfg <osmano807>mark_weaver: without console-keymap-service at all it boots <mark_weaver>can you look at that file and see if it's also empty? <mark_weaver>because the relevant code copies that file into /boot/grub/grub.cfg <mark_weaver>(this is a very bizarre problem, it's hard to imagine what would cause that behavior) <osmano807>mark_weaver: /gnu/store/...-grub.cfg is also empty ***yenda_ is now known as yenda
<davexunit>So, nix actually tries to solve the problem of "what are your dependencies, how are they declared, how are interdependent parts related to each other?" where docker just goes "screw it. nobody's ever going to be able to tame this tangle. let's just throw it all in behind an os container and let it do what it wants" <bavier`>psutils' source download is hanging; unable to connect to server <yenda>btw I'm in (timezone "Europe/Paris") and the clock says 3:20 while it should be 1:20 <mark_weaver>yenda-: does 'date -u' give the correct time in UTC? <mark_weaver>if not, then you need to set your clock. perhaps the hardware clock was set to your local time instead of UTC. <mark_weaver>(GuixSD assumes that your hardware clock is set to UTC) <mark_weaver>after setting the system clock with "date MMDDhhmm.ss", run "hwclock -u -w" to set the hardware clock. <mark_weaver>sprang: looks like you pasted something that you didn't mean to <sprang_>oh, woops, my window server disappeared <mark_weaver>hopefully that wasn't your password that you just gave the world :-/ <sprang_>fortunately I have good password hygiene <sprang_>just not on this machine for the moment <mark_weaver>I've certainly made my share of embarrassing mistakes, although I try to forget :) <sprang_>don't type when your screen is black... noted <mark_weaver>I'm compiling webkitgtk, wondering why the build log is so huge, and then determined that each compilation command is nearly 16 kilobytes long. yikes. So many -I arguments. <boegel>bavier`: you may like this paper too ^ <mark_weaver>boegel: the authors are civodul and rekado-, both regulars on this channel. <boegel>mark_weaver: thanks for the info <boegel>rekado_: let me know if/when you're around :) <yenda->what is the rationale behind the use of IceCat over IceWeasel ? <DusXMT>yenda-: For example, that iceweasel has EME in debian sid <DusXMT>Basically, it's GNU's fork, so we can be somewhat sure it won't adapt freedom-harming anti-features from firefox <yenda->anti features that respond to (wrong ?) user demand though <yenda->but can't this just be stripped down ? <yenda->instead of having separate developpement effort ? <DusXMT>Sorry, I don't know the history behind icecat <yenda->and broken included extensions that falsely block spywares ? <DusXMT>In that case, they need to be fixed <yenda->I don't see why, there is more promising extensions like the ESF one <yenda->Regarding IceWeasel do you think it can be added to Guix packages ? <DusXMT>I guess it could be, since it doesn't contain any of Mozilla's trademarks, but since there's EME, I think a lot of people here will say no <DusXMT>also, something I think will be said, "we already have one Firefox clone, why bother having two" <yenda->for something that claims it respects my freedom it would be nice not to disable the "remove" button of the incldued extensions <yenda->but I would disagree that IceWeasel is just an other clone, it's the updated one <amz3>is desactivate button still available? <amz3>you can't remove an extensions that is installed by the system <amz3>this is firefox "feature" <amz3>not firefox really anyway <yenda->is anyone using guix to install emacs extension <yenda->i'm still puzzled as if wether of not it is a good idea <yenda->i installed a few with it and the rest using the (use-package) macro but I'm not sure what to do <yenda->I suppose the intresting thing with guix is the ability to rollback easely <osmano807>mark_weaver: any clues about that empty grub.cfg "bug" from yesterday? <bavier`>boegel: what do you think of that paper? <dmarinoj>The one about hpc or functional package management? <bavier`>dmarinoj: "Reproducible and User-Controlled Software Environments in HPC with Guix" <dmarinoj>bavier`: That's a great paper. I hope that guix becomes popular in the hpc world. <dmarinoj>bavier`: I have definitely had problems doing what I wanted in HPC environments because I could not install the software I needed. Guix is a really clean solution to that problem. <bavier`>dmarinoj: what HPC environments have you worked in? (just curious) <dmarinoj>A red hat cluster at my university. I could have installed the software from source but it would have been a real pain as it is a very complex piece of software (sage) <dmarinoj>Yeah. I want to package it for Guix after I package Stumpwm. We'll see when that happens though as I am new to Guix and still figuring everything out. <bavier`>sage bundles *a lot* of other software <bavier`>it'd be crucial to figure out a way to use the guix packages where possible <dmarinoj>I think the cleanest solution would be to package all the dependancies. It would be a lot of work but I think it would be worth it. Thats probably why it is not packaged in debian. <bavier`>dmarinoj: did your red hat cluster use 'modules'? <davexunit>bavier`: we can start with the bundled version and work to un-bundle it incrementally. <dmarinoj>Sounds good. Not that I recall. It was very disorganized: months after I was finished with the project the sysadmins got back to me about installing sage. <bavier`>davexunit: sure. The last time I looked at sage though, it looked like it wanted to build things like gfortran and gmp and such without any way to use system versions from what I could tell <bavier`>I don't have the source at the moment though, so I can't check <dmarinoj>It's a great piece of free software for doing computer algebra <bavier`>dmarinoj: for sure, I used it quite a bit at uni <davexunit>or 'guix package -u' to update the whole profile <dmarinoj>cool, will there be a mailing list announcing updates like debian-security? <bavier`>Is it possible to declare source mirrors directly within an <origin>? <mark_weaver>jas4711: grafts are just a way to drastically speed up the process of building new packages that are linked against fixed libraries <mark_weaver>however, it should be noted that our grafting implementation is not quite right <remi`bd>hi! how/when are generated the `nar` archives? `guix publish' seem to assert the archives are existing <remi`bd>well, I want to directly access the nar archives <davexunit>remi`bd: they are generated by 'guix publish' <remi`bd>aaaah I understand now; generation of the nar archives is done in (@ (guix serialization) write-file) <davexunit>I have a 'guix publish' success story. a coworker of mine is using guix at home now and we were able to successfully setup one machine as the central build node from which all the others fetch substitutes. <dmarinoj>paroneayea: Thanks! We'll see what happens... <boegel>bavier`: I like it, well, the parts I've read so far <boegel>bavier`: the point they make w.r.t. reproducibility are solid imho <boegel>bavier`: but they're also missing certain aspects, I think (but I'm not familiar enough with guix/nix to make bold claims there) <boegel>basically, I *really* need to find time to play around with guix and/or nix <bavier`>boegel: feel free to ask any questions here as you find time to play around <boegel>mark_weaver: something about user friendliness, maybe <boegel>mark_weaver: lots of users of HPC systems are not IT experts (to put it mildly), so running into something like hashes would scare them (I'm not sure how much end users of guix are exposed to something like that) <boegel>a big part of environment modules is shielding users from stuff they shouldn't worry about <boegel>and there's a good reason why we do that :) <boegel>bavier`: I definitely will, it's good to know that some people in here have played around with EasyBuild or at least know about it <boegel>I'm really interesting in seeing how guix/nix can help with setting up a robust build environment for EasyBuild, and how EasyBuild can be used as a 'backend' for guix (to build scientific software in a reproducible way) <boegel>mark_weaver: a big part of the effort of EB is making is significantly easier to get scientific software built, which is not discussed in the paper either (maybe due to scope, but still) <boegel>anyone, I'd love to grab some beers with some of guix experts some time :) <boegel>we're thinking about organising an EasyBuild User Meeting in Ghent right before FOSDEM'16, maybe some people going to FOSDEM could pass by <bavier`>boegel: the goal is similar in guix w.r.t. easily building software. I've gotten a number of scientific packages building in Guix (but not as many as EB has) <boegel>bavier`: try WRF, and we'll talk again ;) <boegel>I can name a couple of others :P <mark_weaver>boegel: I don't see how we could get rid of the hashes, but users don't really have to pay attention to them or think about them. <boegel>mark_weaver: I'm not saying I have a better idea :) <mark_weaver>but we do try to make it very easy to build software, and I think we've mostly accomplished that for the packages we provide. <mark_weaver>but we are of course always open to ideas of how to make it easier <boegel>if you want to capture everything (env, deps, etc.), then you must use hashes I guess <boegel>have you guys looked into HashDist? <boegel>seems like there a similar goals and even methods there <boegel>but you guys are probably way ahead of them, I don't think they ever got the ball rolling community-wise <paroneayea>boegel: most git users can avoid thinking about hashes except when they need to think about them <paroneayea>not exactly in branching model but in the way that there's a symbolic reference <boegel>paroneayea: git scares a large part of our users <boegel>paroneayea: partially because they see all those hashes passing by <paroneayea>boegel: I agree that there should be higher level interfaces to this stuff so you don't have to see the hashes if you don't want to <boegel>paroneayea: think biologists using computers, and then telling them they need to use a supercomputer by staring at a terminal window and forget about their mouse <paroneayea>boegel: modern desktop environments hide a lot of "initially scary technical details" but are built upon them nonetheless <boegel>paroneayea: they freak out, usually ;) <paroneayea>boegel: sure, as I said, I think abstractions can be built on top, and one reason I was attracted to guix especially over nix <boegel>paroneayea: sure, I'm not saying the hashes are bad, just that (end) users should never see them <paroneayea>boegel: but I think guix has the right low levels to build the high levels on top of <paroneayea>boegel: I agree that many users should never see them :) <boegel>paroneayea: the differences to guix and nix are not clear to me (yet) either; any good reference for that by any chance? <paroneayea>(but that the users who want to should be able to too!) <paroneayea>boegel: there are various differences, but the main difference to me is that guix is s-expression based <paroneayea>and does not have a bunch of separate custom languages <paroneayea>boegel: as such, building applications that compose the right system setup <mark_weaver>they are based on the same concepts, and share one piece of underlying software (the daemon that manages the builds), but otherwise are completely different. <boegel>paroneayea: true enough, to quote another tool that's gaining ground quickly in the HPC world (Lmod): "provide users easy access to their software stack, without hindering experts" <mark_weaver>our package definitions, and the mechanism by which they are described and executed, are completely different. <boegel>mark_weaver: interesting, I wasn't aware they were so different (even though I've seen talks on both at FOSDEM'15) <boegel>I'm usually slow in wrapping my head around new stuff :) <mark_weaver>heh, well, I suspect you are being too hard on yourself. there's no reason why these details would be obvious to a newcomer. <mark_weaver>superficially they look quite similar because they are based on the same low-level design. <mark_weaver>so, regarding the hashes: I'm a little nervous about the idea of *completely* hiding them, because I think it should be possible to see that two packages with the same name and version number are not necessarily the same. <mark_weaver>those hashes are kind of like a fingerprint, or the little differences that make two close human relatives distinguishable <boegel>mark_weaver: they should probably pop up somewhere, so that you know which hash you were using so you can get back to it if/when you need, sure <boegel>mark_weaver: but they shouldn't be the main handle people use to set up their environment, then they would get in the way <mark_weaver>boegel: agreed, and in practice people should never need to type them in. <dmarinoj>Exactly, you don't need them to install or update software <mark_weaver>at the command line, users type things like "guix package --install emacs" <boegel>you guys are getting close to making me drop everything I'm working on now, in favor of playing around with guix (even though I don't have time ;)) <boegel>mark_weaver: well, different angle of 'users', I guess <mark_weaver>and of course we should have nicer package managers. we have one for emacs already, and a web-based one that's in (sporadic) development. <boegel>mark_weaver: with users I mean consumers of software builds, not people who build the software <boegel>requiring emacs is a big no-no for our type of users :) <mark_weaver>heh, it was the first example that came to my mind :) <boegel>they typically stick to notepad :P <davexunit>yeah, I have a decently friendly web-based guix UI in the works <davexunit>but I only hack on it sporadically, as mark_weaver noted. I'm mostly focused on other tasks <boegel>what's the UI used for exactly? making builds? composing up profiles? (not sure whether those are separate things) <mark_weaver>boegel: rekado- is one of the authors of "Reproducible and User-Controlled Software Environments in HPC with Guix" <davexunit>boegel: for managing user profiles currently. right now it can only sort of do that. it's best at searching through the package list right now. ;) <rekado->I should really work on the talk outline / slides for the presentation at Reppar on the 25th. <boegel>rekado-: you guys still need to present that paper? <boegel>rekado-: btw, good read (although I mostly focused on the comparison with EB/Spack for now ;-)) <rekado->boegel: we have a talk slot at the reppar workshop which is on the 25th. <boegel>rekado-: I'm the EasyBuild release manager btw, and lead dev <rekado->civodul submitted the latest workshop version before going on vacation. <rekado->boegel: I should say that I have not used EasyBuild myself. civodul took a closer look at it. <rekado->my contribution to the paper was mostly comparing with traditional package managers and talking about how it has helped us at the MDC. <davexunit>boston is considered a tech hub, yet I don't know of a single good tech conference here to propose a talk about guix. <davexunit>(sans the FSF's LibrePlanet, but I'd like to talk to other audiences as well) <boegel>rekado-: I met civodul at FOSDEM'15, I think <boegel>we talked briefly, after his talk I think <bavier`>Is it down or just me: `guix build -S sqlite` <davexunit>bavier`: did you mean to add --no-substitutes? <mark_weaver>interesting, I thought that was an unresolved problem <mark_weaver>last tim I looked, sourceforge was down and the main sqlite web site delivered some bad header <bavier`>eventually downloading an "index.html" file that obviously doesn't have the right hash <bavier`>mark_weaver: yes, sqlite.org still delivers a Date header that (web http) can't parse <bavier`>davexunit: even wget for me just returns an html file <davexunit>bavier`: bah, you're right. I also got an html file <bavier`>davexunit: np, sorry for the confusion <boegel>we've seen this happen too on our end... with some GNU mirrors and mpfr for example <boegel>checking the mime-type helps, if it's not text/html but you're getting an .html file, something is clearly broken <remi`bd>how can I obtain the latest path in the store for a given package? <mark_weaver>remi`bd: I'm doubtful that guix makes a record of when a store item was added <mark_weaver>however, if you built them all on your own machine, then you can find the order by: ls -ltr /var/log/guix/drvs/*/* <davexunit>mark_weaver: I think remi`bd means if you take a package object, how do you get the store path? <davexunit>is that correct, remi`bd? because we have procedures for that. <mark_weaver>remi`bd: guix build will give you the output path(s) of a given build, even if it is already built. <remi`bd>I’m looking for the store path of a package, given a string like "emacs" (a “package specification”?) <remi`bd>my initial problem is: to share packages through GNUnet’s filesharing service, I need an actual file to share; to start with something simple, I was going to upload only one package (specified by the user). <remi`bd>my idea was: given a package name like "emacs", generate the nar archive of the latest version of this package and upload it on GNUnet <yenda>I'm packaging i3, it requires xkbcommon and xkbcommon-X11 <davexunit>remi`bd: you can look up a package in the known list of packages via it's "spec" string with the Scheme interface <davexunit>and from there, you can compute the dervication and its output paths <mark_weaver>remi`bd: anything that stores+distributes store items needs to be keyed on the full filename including the hash <mark_weaver>names like "emacs" are not good enough, as davexunit explained. <mark_weaver>those names are fine for user interfaces where you ask to install something, but a filesharing service for built packages needs to be unambiguous <yenda>what are we suppose to do when there is a configure.ac file in a package ? <rekado->yenda: if there is no "configure" script you can create it by executing "autoreconf -vif" in a separate build phase before 'configure. <yenda>rekado: ty, now I have error: Libtool library used but 'LIBTOOL' is undefined <yenda>does it means I have to define some env variables ? <mark_weaver>rekado-, yenda: the build phase should go after unpack, not before configure <mark_weaver>if you search for "autoreconf" in gnu/packages/*.scm you'll find many examples <mark_weaver>the reason it has to go after unpack, not before configure, is because there are some phases between unpack and configure that need to make changes to the files generated by 'autoreconf' <mark_weaver>the changes made by those phases are important for non-intel platforms <mark_weaver><yenda> rekado: ty, now I have error: Libtool library used but 'LIBTOOL' is undefined <mark_weaver>yenda: ^^ can you explain more clearly what you did and how it failed? this is too vague