<taylan>lfam: I can take a look tomorrow... <jlicht>since when is wine an issue w.r.t. software freedom? <rain1>you can run non free software on GNU/Linux <jlicht>by the way, how do more experienced guix hackers deal with having to write myriads of package definitions through guix import? Do you people keep these definitions on your personal git repos, or do you commit them? <lfam>jlicht: I don't understand your question. Can you rephrase it? <jlicht>lfam: I want to work on a Ruby project using guix => I import some gems that are not packaged yet in guix, using guix import gem <jlicht>=> I end up with about ~15 ruby-<whatever> packages in my local guix git checkout <lfam>Do you want to send the gem patches to guix-devel and get them into the distribution? <jlicht>meh, they are not that polished yet, and I should still take care to properly set the license, fix stuff so all unit tests pass etc etc. But my question would boil down to; "Do we aim to package _everything_?" <rain1>I'd like to know what the scope of /packages/ is too <lfam>jlicht: If they are free software and you find them useful, then it's likely that somebody else will find them useful too. I see no reason not to submit them. <jlicht>lfam: that makes a lot of sense :) <lfam>Then why haven't you shared your package definition with the rest of us? ;) <Digit>never managed to write a package for any distro yet. cheeky suggestions/requests are all i have to offer at the moment. sry. ;) <redshelled>Hey guys, quick question. Is it possible to use linux-firmware in guixsd? I know non-free stuff is prohibited, but how about intel firmware? as far as I know it is free? <redshelled>I'm knew to this whole free vs non-free thing so feel free to correct me if I am mistaken <optikalmouse>...I wonder if there's a package for gnu-social or prosody/xmpp yet <optikalmouse>also, it's possible to use guix as a replacement for Chef/puppet correct? <mark_weaver>redshelled: what intel firmware is free, specifically? <redshelled>I was under the impression that intel released their wifi firmware as free software. Like I said, its VERY possible i am mistaken. <redshelled>mark_weaver: I am really wanting to stick to all free software <redshelled>thats really a bummer, what are some free alternatives? atheros maybe? <mark_weaver>yes, ath9k-htc devices have free firmware, which we actually build from source code in guix <redshelled>ok, thanks for that information. I think ill swap out this card then. <mark_weaver>and there are some other atheros devices that don't require the OS to include nonfree software <mark_weaver>note that the proprietary BIOS on Thinkpads typically disables any wireless card that's not on its very short whitelist of approved cards <redshelled>Yep I reflash the stupid bios to get rid of that whitelist bs <redshelled>my y500 had that and that really started my interest in going all free software <redshelled>good laptop, but man a bios restricting what cards i can use just seems silly to me <mark_weaver>alirio: I'm not sure I agree that guix-devel should only be for technical discussions <rain1>alirio, MAME is now GPL2 and 3, I think that page should be improved <alirio>mark_weaver: we want all free distros to be improved by a decision like that <rain1>That page says "Problem: Non-free license" but that is no longer true <mark_weaver>alirio: that's a separate issue though. I'm saying that I disagree with the implication that guix-devel is only for technical discussions <mark_weaver>wine has at least one useful purpose for a free software developer, and that is to test free software built with mingw <mark_weaver>as for mame, I don't know, this is the first I'm hearing about it <rain1>The freedom to run the program as you wish, for any purpose (freedom 0). <rain1>that something can run non free binaries is no problem. wine and mame and linux all have this capability, but it is a freedom <davexunit>I just want to chime to confirm that MAME is indeed free software now, AFAICT. They've gone through the trouble of contacting past contributors and relicensing using GPL-compatible licenses. <alirio>rain1: can you package something useful depending on mame to include in guixsd? <rain1>alirio, the information you posted was out of date <davexunit>but MAME is just one program in this set. There are several other emulators that we provide packages for. <alirio>rain1: the page at libreplanet say to discuss at gnu-linux-libre@nongnu.org <mark_weaver>I guess the relevant text of the GNU FSDG is: A free system distribution must not steer users towards obtaining any nonfree information for practical use, or encourage them to do so. <davexunit>rain1: has MAME made an official release with the liberated source? <davexunit>rain1: it seems to me that they haven't, so we'll have to hold our horses for the next official release. <mark_weaver>rain1: it's definitely not a problem that MAME and WINE and Linux can run non-free software, and in fact if it tried to prohibit it, that itself would make them nonfree because of freedom 0 as you pointed out <rain1>davexunit, ah good point - hopeffully 172 will be <davexunit>so keep your package recipe handy for when that happens. <davexunit>it's good to start the discussion about updating that libreplanet page now, though. <mark_weaver>rain1: however, if it's true that no free software exists that runs under MAME, then one could perhaps argue that it steers users toward obtaining nonfree software. <rain1>you can find a bunch if you like <davexunit>rain1: is there a way to see the licenses for the games on these sites? <rain1>its GPL, you can write your own game boy game too <davexunit>rain1: no I mean the games on this homebrew site <davexunit>I know that there are free games for more mainstream machines <mark_weaver>rain1: if there's free software that runs under MAME, then I think this is a clear case of "it's okay" <mark_weaver>or more to the point, if MAME can be used without using any nonfree software <rain1>well you can just play around in the config menu :) <davexunit>MAME emulates a variety of different arcade machine hardware <davexunit>rain1: is there a game that you can link us to on this site that is free software? I'm actually really curious because I don't know much about the homebrew scene and how much overlap it has with free software. <mark_weaver>this question of whether something steers users to obtain nonfree software is somewhat of a judgment call. <rain1>My opinion: it's free software... end of story. <rain1>it doesn't have an app store that downloads non free binaries <davexunit>a clear case of a program steering someone to install nonfree software would be if one of these emulators presented something like an "app store" where they could proprietary things <alirio>davexunit: there's some problems we can't solve, always will be (rejecting all invalid programs vs accepting all valid programs, typing at compilation time), (sending innocents to prison vs letting guilty people free), (avoid packaging things with no clear use in freedom vs packaging everything not clearly unfree),... <davexunit>alirio: I don't think you're being fair here. <rain1>I really think it's an interesting discussion! <davexunit>or at least, based on how I'm interpreting you. <mark_weaver>rain1: can you provide an example of a game that runs under MAME that is free (as in freedom) software and can be used with MAME without any nonfree software? <mark_weaver>and preferably something where MAME is actually needed, as opposed to something that can be just as easily run natively on GNU/Linux. <davexunit>can an emulator not be useful on its own as a tool for exploring machines that may be hard to obtain physically? <alirio>davexunit: this is the question: assuming innocence or assuming guilty; jmarciano message clearly assumes guilty, so you need to prove innocence; you know someone fiddling with architectures they don't have to test? <mark_weaver>perhaps, but right now I'm trying to evaluate the question of whether MAME steers users to obtaining nonfree software. <alirio>davexunit: you are assuming innocence; no faulty logic, different axioms <mark_weaver>if there are free (as in freedom) games that run under MAME and not natively on GNU/Linux, that would allow us to make this judgement more easily <davexunit>alirio: I think you have the burden of proof mixed up. <alirio>mark_weaver: this is sidestepping the question about assuming innocence or assuming guilty, if we can do that, sure; but maybe in some cases we don't <davexunit>I can go look for free things that run on MAME, but MAME isn't just one thing: it's a whole collection of emulators to vintage hardware, including not only arcade machines but even some old calculators. <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 <mark_weaver>having said that, this case is less clear. even if there is no free software that runs on MAME, I'm not sure what the right decision is here. <alirio>davexunit: i'm saying we don't really have enough information at now, so we _assume_ guilty or _assume_ innocence <mark_weaver>but since I already have too much to do, if the decision can be made more easily, I would be grateful <davexunit>it's not urgent anyway because MAME hasn't made an official release of the newly freed code. <mark_weaver>alirio: how do the words "guilty" or "innocence" fit into this discussion? I don't see how they apply here. <davexunit>rain1: I couldn't find any free software on those sites. <rain1>I don't think there is any need to include MAME in guixsd <rain1>but if someone wants to use it then they should be able to easily use it <rain1>not have to write a package definition, since it's already done <davexunit>rain1: well sure, but that's orthogonal here. <alirio>mark_weaver: earlier analogy: <alirio> davexunit: there's some problems we can't solve, always will be (rejecting all invalid programs vs accepting all valid programs, typing at compilation time), (sending innocents to prison vs letting guilty people free), (avoid packaging things with no clear use in freedom vs packaging everything not clearly unfree),... <mark_weaver>alirio: "jmarciano message clearly assumes guilty" suggests that "guilty" is a word that's applicable to MAME, and I don't see how it is <alirio>mark_weaver: packaging everything not clearly unfree, mame (the yet to be released version) is in that situation <mark_weaver>"not suitable for inclusion in Guix" or "not compliant with the GNU FSDG" is a different concept than "guilt" <rain1>what I am curious is what is the scope of /packages/? <davexunit>I think the issue has begun to take up too much of everyone's time. let's re-evaluate when MAME officially releases the new GPLv2 licensed code. <alirio>mark_weaver: too lengthy to a discussion <davexunit>rain1: it lists everything. we should instead paginate it. <davexunit>the guix website is a scheme program, naturally, so it wouldn't be that hard to do that. <rain1>but why are these packages in that list and not other ones? <mark_weaver>alirio: I don't think we should include in Guix "everything not clearly unfree". rather, I think we should make some effort to ensure that software in free before including it. <rain1>or "anything free that isn't a virus" <davexunit>rain1: that list is of software that we made package recipes for. <rain1>what are the criteria for being accepted in that list, and what are the most desired packages to have there? <davexunit>any free software that is compliant with the FSDG <davexunit>the most desired packages are the ones that people are the most motivated to package <rain1>this is silly but, what if i made a package which replaces libssl with broken crypto and submit it.. under GPL3 ? <davexunit>you couldn't *replace* the ssl libraries we use. <davexunit>you *could* submit a bad, but free, library to us. <rain1>what about with the collision/arbitrarily choosing thing? <davexunit>rain1: ludo explained on the mailing list why that isn't a problem <davexunit>and specifically, in the case of a C shared library, the profile collisions have *no effect* on which library is loaded <rain1>that does enable you to replace libssl though <davexunit>our native binaries have their runpaths configured to use an absolute path for loading shared object files <alirio>mark_weaver: or "avoid packaging things with no clear use in freedom" as i worded it, with "assuming guilty" as analogy, i think the most important thing is that this decision isn't about guixsd, but is about fsdg and all free distros <rain1>one could still replace a binary with a version thaht has been compiled with a bad library <rain1>the impact is much much less which is good <davexunit>as ludo mentioned, the threat is bad software getting onto the user's machine in the first place. <davexunit>we wouldn't package software that was harmful. <davexunit>or we would remove software that we found was harmful. nothing about profiles involved here. <rain1>I think packages could be split into high priority stuff like libressl, glib, etc.. and thes less serious stuff <davexunit>PSA: 'guix environment guix' will *not* produce an environment suitable for building guix from git right now <davexunit>because the guix package is building from the 0.10.0 release tarball <rain1>im sorry that my packaging mame caused such a stir :P <rain1>I really had no idea it was a contraversial thing at all <rain1>I wonder if there is a list of things that would be more practical and useful for guixsd <davexunit>FWIW I don't think software need be practical to be included <rain1>well things that are most wanted <rain1>I don't know the best word to explain what I mean <davexunit>MAME is pretty much entirely not practical. there's not much practicality in running software on emulated vintage hardware, so it seems unfair to me to demand that MAME meets some level of practicality. <davexunit>where people would put stuff that they would like to have <alirio>rain1: in programming static typing (avoiding false negative errors) vs dynamic typing (avoiding false positive errors) is so controversial they invented gradual typing <rain1>alirio, I sent mail the gnu libre list <jololo>Hey! conneting from my new guix laptop! I am newly logged into my personal account but I can't mount usb drives I can only do it from the root account. when I su and run fdisk from commands it says "fdisk command not found" <jololo>ah nevermind, I have to sudo everything <jololo>what email clients do people use? Any other programs people recommend? I'm going on a downloading spree <jololo_>Sorry to bother - I've been reading the manual and it's really helpful, thanks! I have this problem with installing libreoffice and hexchat - they both fail because python-2.7.10.drv failed. Error say it is due to networking issues. <lfam>jololo_: You need to pass the option '--fallback' to the command that is failing. That means you will build from source if the substituter fails <lfam>Can you share the full path of the failing items? For example, /gnu/store/zby49aqfbd9w9br4l52mvb3y6f9vfv22-hello-2.10 <calier>WTF guys, even NixOS has /usr/bin/env. This NixOS user told me so. <calier>I am trying to make my shell script run inside the shell of the program script every time it is run. <calier>*inside the shell of script (the program) <Jookia>glad you're okay if you're who I'm thinking you are <Jookia>civodul: After 0.10, ready to review some patches? :) <Jookia>civodul: I also found out my coreboot patches fix booting on older Libreboot releases <Jookia>civodul: On other notes, when do you HTTPS proxy support will be a thing? <civodul>i haven't looked at it in detail yet <civodul>i'm not sure exactly what needs to be done <civodul>but i agree we should do something about it <Jookia>To explain: /usr/bin/env is a dirty hack and there's a few ways to avoid using it <Jookia>Patching shebangs (this can be done by running a Guile command), adding a configure system for your projects <calier>Yeah, I understand how it is a problem: it allows one to be non-specific about dependencies. <civodul>calier: mkdir -p /usr/bin ; cd /usr/bin && ln -s /run/current-system/profile/bin/env <calier>But if NixOS has the same goal of functional package management, then why on Earth did they do it? <calier>But they have rules! A project needs to follow its principles! <Jookia>civodul: I've heard that you use to actually work on Nix and split off in to Guix <civodul>it appeared overnight with no discussion, some liked it, some didn't, life went on <calier>civodul: I *am* being respectful. Now I'm paranoid about being disrespectful. <civodul>dunno, i felt this discussion was unnecessarily aggressive <civodul>don't remember where we left that discussion about /usr/bin/env on the list <Jookia>Having a mutable system seems important <civodul>maybe we should add a knob, or a binfmt_misc interpreter, someething <Jookia>From my experience /usr/bin/env is generally the tip of the iceberg of projects that assume FHS <calier>But yeah, I was basically wanting to make my script always run itself inside a shell inside of script (the program). But I want to do this in a way that works on all GNU systems. <Jookia>calier: Add a configure or autotools script <calier>I never learned what those things actually were. <DusXMT>calier: they're the tools behind the familiar ./configure script most gnu projects ship with <Jookia>Fun time to learn? :) These things also fix other issues <Jookia>civodul: It's probably best to expose the shebang patcher so people can use it outside of packaging scripts, and educate people to add configure steps to their projects <Jookia>Or have a container that builds a FHS environment <Jookia>Usually where there's a /usr/bin/env there's a /usr/bin/gcc and a singular /usr/include hanging around <Jookia>Though Arch just links /bin to /usr/bin <Jookia>Maybe we could just link the FHS to the profile in a container <calier>OK, my question was answered. I am leaving before I get kicked out. <Jookia>jmarciano: Perhaps you should make your own version of Guix's packages <rekado>rain1: if you want an AUR-like thing you just need to find other people who want that and agree on collaborating with them. <rekado>rain1: guix provides GUIX_PACKAGE_PATH, so the guix project doesn't need to declare any external repos as official. <Jookia>I think that might be problematic <jmarciano>well no, I rather like to contribute to GuixSD development, my "own" versions I would give to GuixSD. <rekado>I still think it makes more sense to add packages to guix directly rather than encourage separate package repositories <Jookia>From what I understand Guix doesn't provide a stable API <Jookia>jmarciano: Sure but you might disagree with some packages in Guix which are staying <rekado>Jookia: well, it's been pretty stable so far. I have a module with custom packages and I only needed to adjust it to upstream changes once. <Jookia>rekado: Sure but any adjustment has to be applied across all third-party packages <rekado>Jookia: and that might be easier if people collaborated when they want to have packages outside of Guix. <rekado>Jookia: I'm not encouraging an AUR-like thing. <Jookia>Me either but I wanted to add that such a thing would be hard to do <rekado>I like the quality of most packages in Guix and I don't like to encourage the growth of an external repository that just accepts anything. <jmarciano>once matters are solved in community, why should I disagree? <rekado>jmarciano: because the community may not agree with you and consider the issue solved while you don't. <Jookia>Anyways there's a lot of things that bug me about Guix that probably won't get fixed too <civodul>ACTION thinks we ought to discuss how to fix things that bother people <Jookia>civodul: The touchy subject of non-software licensing. The best 'solution' would be to add the licenses for ALL content to the license field <Jookia>Then I could blacklist certain outputs, etc <rekado>Jookia: don't we do this already? <rekado>the license field accepts a list of licenses <Jookia>The Emacs package's license is 'gpl3+' <Jookia>Which isn't the license for all content <Jookia>Debian's copyright files are much better in that respect <rekado>about LVM support: GRUB has a module for reading from LVM partitions, so I added "insmod lvm" to my grub.cfg. I think once support for unlocking LUKS devices is merged, support for encrypted LVM would be simple to add. <rekado>Jookia: what would be the difference to guix.git? <rekado>civodul: I like your quote from the free software song in that email :) <Jookia>I'm not even sure if I have the ability to audit all the packages so it might be worth checking Debian <Jookia>Though, it'd be difficult to maintain such a fork too <Jookia>It might be easier to just make a blacklist with patches <rekado>Jookia: do you have an example of packages providing non-software that could be called "nonfree culture"? <rekado>does this include documentation with invariant sections? <civodul>Jookia: i think over time invariant sections will disappear <Jookia>They certainly will disappear from my system :P <rekado>civodul: what is a legal way to get rid of them? Just regular copyright expiration? <civodul>now, calling that "non-free culture" is obviously trollesque ;-) <Jookia>Invariant sections are nonfree in that they can't be modified <civodul>but we should not rehash the Debian vs. GNU GFDL story as-is ;-) <civodul>i think it's been unnecessarily divisive <civodul>whereas the people involved in the fight showed that they cared enough about software freedom <Jookia>I wasn't meaning to bring up a debate but more showing how personal opinions can lead to needs to fork a little bit. I don't look at it as divisive but empowering <Jookia>Imagine a religious person running their own Guix environment on a server with only things that aren't offensive to them <civodul>on the GFDL issue i think the best course of action would be to talk to maintainers of GNU packages that still use invariant sections <civodul>Emacs being obviously more difficult than smaller packages <Jookia>Yeah, though I'm under the assumption that copyright holders need to agree on it <civodul>not really; maintainers have delegation on technical things, mostly <civodul>"mostly" because often rms has the ultimate say... <Jookia>Interesting, I'd have to read the GFDL again <Jookia>I'm glad Guix lacks invariant sections btw <Jookia>Also one problem with user freedom especially in jmarciano's case is that their kids could install their own software, free or not, thanks to Guix ;) <jmarciano>discuss Guix, GuixSD, don't discuss my kids, ok? <Jookia>Sorry I didn't mean it to be personal <Jookia>I couldn't think of another example <jmarciano>Just that you know, I wish to make software packages for GuixSD, and I am learning. I made one package xorriso, later I found it was already there. I am not following on IRC the discussion from yesterday. If there is anything that can be solved, if nobody complains, I will decide if to complain later, but not on IRC, in order not to disturb people, who help on package creations and on system development. <Jookia>I see- I've been replying to your emails <jmarciano>yes that is email, sure, no problem, did not see maybe last email. <Jookia>I don't think Wine is going to be removed <jmarciano>I had computer club with 10 GNU operating systems, and 1-2 Hurd in Stuttgart, Germany, back in 1999, people were using GNU because it is free software. <Jookia>I'm just saying that you might need to look at solutions that don't involve Guix removing packages you disagree with <jmarciano>And I had one computer club Kosmos in Bosnia, back in 1988-1991, so I am and will never encourage other people to use neither one or the other package not mentioning it here any more for reasons I said. And you are free to do what you wish, and also the GuixSD group leaders. <jmarciano>In answer to your last line, I guess, you already said that. I feel your mis-emotion, but I am trying not to get into it, and trying to avoid further discussion. I like to switch subjects to GuixSD new package inclusions rather. <rekado>someone with an account could delete Blender and Mypaint. <rekado>also GNOME -- because we have it. <DusXMT>Wine can be used for porting free software to windows, to help spread the freedom =3 <DusXMT>ACTION actually did that a couple of times <jmarciano>at 10:42 my time, you already mentioned that, that is wrong help from you. I will not need other solutions, you don't need to mention it any more. thank you if your help was genuine and I am wrong in seeing indications. <roelj>DusXMT: I used Wine for compiling Windows binaries as well! <Jookia>jmarciano: Sorry I think there's a bit of a language barrier preventing me from understanding what you're saying fully but I'll drop the subject <jmarciano>thanks, I finished with it too, will not mention it on IRC, maybe on other line, and will rethink of it, rework it, during the time. <Jookia>Okay. I hope you find a solution :) <jmarciano>my current problem is how to include LDFLAGS in package definition, if you can help me on that, I could finish gurgle <civodul>rekado: i think you can create an account on libreplanet.org (though i understand all these accounts are boring) <Jookia>jmarciano: I'm going to go shower but if nobody's helped you by the time I'm back I'll have a look. :) <jmarciano> http://paste.debian.net/422112/ that is what I want to find, how to make a quick patch, and how to include LDFLAGS, I am wrong there. I could install it without mysql, guile, but I wish with 3 options, PostgreSQL, Mysql and Guile <civodul>jmarciano: passing LDFLAGS via #:configure-flags looks good to me <civodul>ACTION notices that "guix import gnu gurgle" doesn't work :-/ <efraim>`guix import gnu foo` also doesn't work, and doesn't exit cleanly <efraim>`guix build foo bar -C2 -M2`, 2 cores for foo and 2 for bar, or 2 cores total? <civodul>yeah "guix import gnu" doesn't gracefully handle errors <shanemikel_>so, is there a tutorial/manual somewhere for setting up a nice interactive emacs environment for guix hacking? <jlicht>shanemikel_: Are you talking about the Geiser/guix.el setup? <alezost>shanemikel_: the only existing manual is the one that comes with guix, see (info "(guix) The Perfect Setup") <rain1>I want to render a graph of all packages I have installed <rain1>guix graph $(guix package --list-installed | awk '{print $1}') > packages.dot <rain1>this seemed likea good start but the dot command produces such a huge output file it made mupdf divide by zero <rain1>sfdp: failure to create cairo surface: out of memory <rekado>rain1: maybe you can create the graph of just the profile instead of giving a list of packages. <rain1>is there a command to do that? I'm not sure what that means exactly <rain1>this program is very nice for getting rid of stuff you don't need, trying to emulate it in guix! <rain1>also I was wondering, how to get guix 0.10 ? <rain1>after guix pull: guix (GNU Guix) 0.9.1 <rain1>so should I git pull and build and then somehow install that? <rekado>rain1: hmm, I see that guix graph does not take a store item but only an expression or a package name. <rekado>what is the manifest file in a profile used for? <rekado>e.g. /gnu/store/rbppr3la...-profile/manifest <rekado>it contains an sexpression, but it's not the manifest we'd use with "guix package --manifest" <rekado>this crashes here: ./pre-inst-env guix size -m profile-size.png /gnu/store/rbppr3la2ral3ga442xk3mdi2882gadm-profile <rekado>In procedure module-lookup: Unbound variable: make-page-map <rain1>how do you find the profile path? <rain1>Unbound variable: make-page-map <wingo>rekado: i think you need guile-charting installed perhaps, dunno <rekado>wingo: that's probably it. Thanks. <rekado>I think it would be nicer if that's what "guix size" told me. <rekado>ACTION considers submitting a bug report <wingo>irc 4ever, bug reports never ***civodul changes topic to 'GNU Guix | https://gnu.org/s/guix/ | videos at https://gnu.org/s/guix/help/#talks | 0.10.0 is out! | https://libreplanet.org/wiki/Group:Guix/GSoC-2016 | paste to http://paste.lisp.org | channel logged: <https://gnunet.org/bot/log/guix>.'
<Digit>oh sweet. i've been teetering on the verge of getting a new guix (somewhere ~ hadnt decided wich machine or how yet) for a while now. i miss it. nearly bit the bullet last night. glad i didnt now that there's a new release. :) <rain1>the layout isn't as good as usual though <davexunit>ACTION waits for release announcement to hit the info-gnu archives <jlicht>Is an update to 0.10.0 just a `guix pull` away? <jlicht>What would be a way to get 0.10.0? <jlicht>from an existing binary guix installation preferably <davexunit>jlicht: 'guix pull' will get you the latest from master by default, which is essentially 0.10.0 right now <davexunit>you can also point 'guix pull' at the tarball for 0.10.0 <jlicht>davexunit: yup, that did the trick :) <civodul>it reached the help-guix archive sooner <rain1>doing guix graph and everything depending on python has tk (and a lot of tk deps) <rain1>is that because they really use tk? <rain1>i see tk as a separate output and I'm not sure who uses that <rain1>it would be quite nice to have python not depend on tk I think <civodul>rain1: the "tk" output normally makes sure that "python" itself does not depend on Tk <rain1>I think openssh doesn't use tk ? but it's there in the graph <civodul>rain1: how did you generate the graphs? <civodul>"guix graph foo" shows the build-time dependencies <civodul>use "guix graph -t references" to see the run-time dependencies <rain1>oh great, ill look at them all again with references mode <rain1>guix graph: error: references for '/gnu/store/3g6zn8y5sfwywr4pqiwqrab735a0x4zl-guix-0.10.0' are not known <civodul>yes but here it's looking at the "guix" package that is available, not the one that is installed <efraim>just saw on the info-gnu mailinglist that guix and guixsd 0.10.0 were released, time to upgrade package it before someone else does :) <civodul>efraim: already upgraded, as part of the release process! <rain1>how to upgrade to guix 0.10? <rain1>but guix pull leaves me at 0.9.1 <civodul>it's a non-event if you already use Guix{,SD} ;-) <civodul>then there's that bug with the version number that remains old <civodul>when you run 'guix system reconfigure' it'll display 0.10.0 <Jookia>maybe guix should also list the version it's loaded in --version <rain1>I gu.ess I have to log out and back in :D <rekado>rain1: maybe do "make clean-go"? <rekado>when I run "guix environment guix" after upgrading to latest master I get this error: <rekado>In procedure module-lookup: Unbound variable: make-session <rekado>guix environment: error: build failed: substituter `substitute' died unexpectedly <rekado>that's because the substitutes are served via https by default, I think <rekado>ERROR: missing interface for module (gnutls) <rekado>odd, I thought I already have gnutls installed <rekado>wingo: "maybe guix should do time-based releases!" <--- I agree! <rain1>is it because I installed guile-next? <rain1>oh I think I know what might have happened <rain1>I could have C-c during guix pull, and ended up with a truncated binary <rain1>can I, as root, replace my users 'guix' to fix this? <davexunit>Guix operations are atomic so that is extremely unlikely <jmarciano>as root, and user: guix pull, guix package -u guix, gives me version 0.10.0 on foreign distro. <rain1>this file is damaged /home/rain/.guix-profile/lib/guile/2.2/ccache/ice-9/eval.go <rain1>I can't really think of any way to get back ot aworking system... <civodul>rekado: i sort-of agree too, but the hard part is doing it ;-) <civodul>like on the D day you realize you're waiting for a patch, and you're rebuilding the world and waiting for it to be done, and there's a problem on the server, and... <civodul>now, we should probably aim for that <civodul>our workflow should be refined to allow it, i guess <rain1>actually i think it might be this file /gnu/store/...-glibc-2.22/lib/gconv/ISO8859-1.so <rain1>any suggestions how to fix guix? or what even could have gone wrong <rain1>I would like to remove guile-next from my user but i can only use the guix tool as root: Any ideas? <rain1>How can I edit this file? /var/guix/profiles/per-user/rain/guix-profile/manifest <efraim>can you do /path/to/root's/guix ? <rain1>$ /gnu/store/3g6zn8y5sfwywr4pqiwqrab735a0x4zl-guix-0.10.0/bin/guix <rain1>Throw without catch before boot: <rain1>Throw to key misc-error with args ("make_objcode_from_file" "bad header on object file: ~s" ("\\x7fELF\\x02\\x01\\x01�\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00") #f)Aborting. <efraim>also, gst-plugins-good@1.8.0 has more non-deterministic test failures <rain1>I tried selecting an older 'system' or whatever in the grub menu but I still get the crash <rain1>is it possible to boot the GuixSD live usb and then sort of chroot in and do stuff? (to delete guile-next, hopefully fix this) <efraim>sorry, I don't have any ideas rain1 :( <rain1>I guess I could just wipe the disk and do something else ^^ <efraim>5th time's the charm! gst-plugins-good@1.8.0 built successfully! <rain1>would anyone like to try to confirm this? (In a VM not your real system) guix pull, install guile-next, reboot, guix should crash <rain1>oh there's an easy way to fix thi,s i can delete my current user reconfigure, then create it again <mark_weaver>civodul: were you able to get binary install tarballs for mips and armhf from the build slaves? <civodul>mark_weaver: yes, i built the derivation from hydra.gnu.org <civodul>sneek: later tell rain1 sounds like you have a mixture of Guile 2.0 and 2.2 object files in $GUILE_LOAD_COMPILED_PATH <mark_weaver>I recently updated the wip-loongson2f branch, but it turns out there's some problem with either the toolchain or the library that's messing up floating point math somehow, such that both ogg123 and mpg321 are producing garbled audio. I've ruled ou the kernel, because the new kernel works fine with old binaries of those programs. <mark_weaver>I can tell this is going to be an ongoing problem with everything that's not x86_64, because almost all of our users are on that architecture <mark_weaver>the other architectures are likely going to be problematic until we have some kind of stable branch where the other arches aren't broken as often <civodul>mark_weaver: yes, but it's a more general problem of GNU/Linux on underused architectures <civodul>the garbled audio problem could be anything, kernel or userland <sneek>rain1, civodul says: sounds like you have a mixture of Guile 2.0 and 2.2 object files in $GUILE_LOAD_COMPILED_PATH <rain1>i booted into another linux, mounted this disk, removed guile-next from my manifest file and the gnu store, updated the symlink so guile points to old guile <rain1>seems to be working fine nnow <rain1>I still get guix (GNU Guix) 0.9.1 after system reconfigure and reboot though <rain1>civodul, yeah looks like installing guile-next shadows the current guile and trashes gux <rain1>trying to reproduce in a VM right now <civodul>they don't shadow each other, but most likely GUILE_LOAD_COMPILED_PATH points to both /2.0 and /2.2 <rain1>I changed /bin/guile in my user profile to point to old guile instead of guile-next <ziz15>guys right now i'm installing guixsd 0.10 (hope today i succeed) one question when i part the disk i didnt give a label now on config.scm can i remove device and title entries or no? <rain1>You don't have to use labels, you can point to your partition like this (file-system (device "/dev/sda1") (title 'device) (mount-point "/") ...) <ziz15>rain1: i have you two days now "working" for me :) <ziz15>rain1: i give u an oscar yesterday <ziz15>I must make an notice: Today when i see that 0.10 is out and after download the file when i went to read the manual its like it was wow compare to yesterday <rain1>dam... trying to install guix in qemu: guix pull error build failed error parsing derivation /gnu/store/...-module-import.drv expected string 'Derive([' <ziz15>(sorry for my english its not my native language) <ziz15>rain1: i m intalling it in virtualbox <ziz15>if you want you can convert the raw image into vdi <ziz15>rain1: yes it has more explanations <ziz15>for everyone who want to try the image in vbox give <ziz15>VBoxManage convertfromraw guix-usb-install yourname.vdi --format=VDI <ziz15>then add a second hard drive and install the os over there <rain1>I'm not sure if anything was corrupt <bavier>ziz15: we try not to promote virtualbox here because its nonfree software <rain1>I think the problem was guile-next shadowing guile <ziz15>bavier: sorry dont think of that <davexunit>rain1: "sounds like you have a mixture of Guile 2.0 and 2.2 object files in $GUILE_LOAD_COMPILED_PATH" <bavier>ziz15: np, glad to have you here <rain1>was anyone able to reproduce the problem? <taylan>rain1: re. your question in #guile: Guile byte-compiles a file and stores it in the cache when the file is first run. it's recompiled when the file changes, but if it includes another file and that file changes, then it's not recompiled. <mark_weaver>civodul: I've ruled out the kernel, it must be userland. <rain1>taylan, do you agree its a bug? <taylan>rain1: I guess it could be viewed as a bug, but I'm guessing the solution would be quite complex. it's best to use the module system instead of 'include'. <mark_weaver>anyway, I agree that this problem is not Guix-specific, but is a problem for any distro that lacks stable branches <taylan>rain1: I guess it would be good; at least it would be a place where the limitation is documented. <civodul>mark_weaver: yes, that makes the problem more acute, but having seen Debian decay on sparc32 years ago, i can tell you that the real problem is upstream <taylan>(though if it's going to stay the way it is, it would be better to actually document it in the manual I guess) <mark_weaver>but distros can compensate for it, and Debian stable is one example of a distro that does compensate for it on many architectures. <civodul>didn't work so well in my experience, but i can imagine that it would help a bit <civodul>i think we should have stable branches at some point <civodul>the tricky thing is finding out when is a good time, so that we don't over-commit :-) <mark_weaver>it can only do so much. if there aren't enough users testing things out during the testing period and sending in reports, and not enough developers to fix the problems, then it's not going to work. that may have been the case with sparc32 <mark_weaver>but for minority platforms like mips64el, it can make a world of difference to give some time to find and fix bugs without new ones being introduced by the frequent upgrades <mark_weaver>things are broken so frequently on mips64el that I lack the capacity to keep up with it <DusXMT>mark_weaver: I wonder, is there currently a commonly available mups64el machine? <DusXMT>Because while the Lemote Yeeloong is commonly mentioned, I haven't been able to spot one for a reasonable price <DusXMT>ACTION would love to have a non-x86 non-arm machine, even better if it could run GuixSD :) <rain1>civodul, I reproduced the problem in qemu! <rain1>should I submit a bug report or what should I do that is most helpful? <rain1>I think it would be good to put out a warning: Do not install guiles-next! <jmd>DusXMT: I suppose it depends on what you mean by "reasonable". <jmd>DusXMT: Mine didn't cost that much. <DusXMT>jmd: But it looks like everyone's out of stock on them <jmd>As I recall, < 300 EUR including delivery. <civodul>rain1: but yeah, submitting a bug report is always a good idea :-) <rain1>civodul, that guix breaks if you install guile-next <civodul>ah, this one is a "known" (and unfortunate) problem <rain1>I think it would be nice if there was a tool that could help one recover from broken-guix situation <rain1>I don't know what it would do or how it could work though <rain1>short term I really think guile-next should be removed from packages <rain1>that isn't nice for people.. <rain1>shall I send a patch deleting it? <rain1>probably easier to just do it than apply a patch <jmd>Any objections from anyone if I move pspp from math.scm to statistics.scm ? <efraim>one of these days I want to move zsh and fish to shells.scm <jmd>efraim: Move nautilus too :P <rain1>anyone else support removing guile-next <DusXMT>ACTION finds it kinda sad that there's a specific laptop model that so much attention goes into supporting, yet it can't be bought by regular mortals... I know, there's the libreboot laptops, I realize that. <janneke>rain1: i'm working on better support for guile-next, why remove? <rain1>because it trashes your guix system <rain1>that's not kind to do to people <DusXMT>rain1: There's other ways to solve problems than to nuke them <rain1>janneke, if you can make it not trash the system then that is perfect <davexunit>it's inevitable that there will be combinations of software that won't play nice. we will try to fix those issues where possible. removing useful things doesn't help. <janneke>davexunit: i intend to have a solution where guile-2.0 and guile-2.2 behave nicely alongside each other <rain1>Just get the latest guix installer image, install a barebones setup, log in as root <janneke>rain1: what problems do you see? often, just unsetting GUILE_LOAD_COMPILED_PATH helps a lot <janneke>i have patches for guile, but they need to be reviewed (and most probably amended) <rain1>It is really not nice to users to make this completely break their system in an almost unrecoverable way <DusXMT>rain1: The system is not ready to "reach the shelves", we can afford to make things temporarely complicated at the moment to solve the problem properly <rain1>ACTION please be a bit more accepting of bug reports <rain1>it's not nice to deny bug exists without even trying to reproduce <DusXMT>rain1: I'm pretty sure no one's denying the existance of the bug; what's not accepted is the proposed solution to "remove guile-next" <davexunit>rain1: we accept your bug report! multiple people have confirmed that it's a bug. <davexunit>I don't know what's going on in this channel and on the mailing list lately, but it's like everyone is talking past each other. <alirio>civodul: some of your messages to guix-devel have a +0100 timezone and others a +0200, this is a privacy leak... <civodul>alirio: indeed! i live in a place that just switch from +0100 to +0200 <rain1>I have asked about 'what if there's a thing you can install that replaces a library or binary with a broken version" and it was said that bad packages like that would be removed <efraim>more of a privacy leak than having the revolutionary date in his mail headers? :) <str1ngs>that narrow's it down to a whole timezone. The hunt continues :P <rain1>guix community isn't friendly :( <DusXMT>But personal things aside for now, <DusXMT>rain1: binaries use the rpath ELF field to find the correct libraries that they were built with <DusXMT>essentally, the library's path in the store is hardcoded into executables <DusXMT>Also, if the user updates to new versions and discovers that they're broken, they can always use rollbacks to return to a previously known good state <anthk_>I am thinking about using qemu's virgil 3D from Guix under Trisquel to run a VM with GuixSD so I can use the GL acceleration to try Gnome3 ***exio is now known as exio4
<str1ngs>also rebuilding would fix the rpath no? <DusXMT>str1ngs: Yes, but that results in a new package instance <alirio>efraim: rain1 seems to be discussing security/safety, privacy leaks are another issue <str1ngs>which substitutes would produce eventually anyways right? <alirio>the problem isn't just privacy leaks, but it's annoying to read several messages with different timezones at lists.gnu.org; altough the proper fix would be to this information don't leave email clients <DusXMT>ACTION just now realized that he misunderstood rain1's statement ... either way, removing something progressive for the sake of solving a temporary issue is something silly <DusXMT>s/something silly/definitely silly/ <rain1>please stop calling me names <DusXMT>rain1: I didn't call you silly, but the removing. <davexunit>ACTION hears that the Guix talk from LibrePlanet will be available soon <davexunit>ooh, our release announcement is on the second page of HN <str1ngs>configure: error: `s390x-linux' is not a supported platform. <str1ngs>See "GNU Distribution" in the manual, or try `--with-courage'. <jmd>str1ngs: I don't think we should be promoting alchohol use in Guix. <str1ngs>at least its only virtual drunken brawls :) <paroneayea>ACTION sends a strongly opinioned post on the MAME thing to the mailing list :) <str1ngs>hmmm guile-json build requirement for guix? <davexunit>str1ngs: it's *supposed* to be optional, but mistakes have been made a couple times that make the build system require it. <davexunit>if that's the case, we'd love to know the error you get so we can fix it. <str1ngs>syscalls backtrace. so porting issue <bavier>paroneayea: thanks for the mame reply; basically what I wanted to say <anthk_>gnome works well under GuixSD (vm) <anthk_>altough the version under "details" is 3.0 <jmd>anthk_: Oh well! I'm glad that at long last somebody has found somthing under which Gnome works well. <anthk_>one thing it needs is networkmanager, but interfacing NM with herd and the network functions would be a little nightmarish <petter>Whoever packaged unclutter. Thank you! <alirio>petter: "git log|grep 'Add unclutter' -B 3" says it was alezost, not here <lfam>anthk_: I saw in the IRC log that you are going to try something to get 3d acceleration in QEMU. Is that right? <lfam>janneke: What do you mean about the locales? <anthk_>lfam: I need a custom build of qemu with virgil <lfam>I would like that too. GNOME in QEMU is too slow to use for me <lfam>Would that help accelerate GNOME? <lfam>Yes, I'm reading that page <lfam>In linux 4.4, so very recent work! <anthk_>lfam: you have that in qemu 2.5 if you build it with the GTK3 GUI <lfam>anthk_: Can you point me to documentation of that? <anthk_>./configure --audio-drv-list=pa,sdl,alsa --with-sdlabi=2.0 --disable-vte --enable-curses --with-gtkabi=3.0 <anthk_>basically is to compile qemu with that, having mesa headers and such <lfam>Is the audio necessary? Or is that unrelated? <ng0>guix package --remove DST <lfam>I wonder if I should vote for the story on Hacker News or if the story will be penalized since I always vote for our stories? ;) <davexunit>it's already been to the front page for a few minutes and bumped down <janneke>lfam: guix substitute: error: corrupt input while restoring '/gnu/store/dcqdfyal290awy1lwb6sxzs8sg0wr99h-glibc-locales-2.22/lib/locale/2.22/ko_KR.UTF-8/LC_CTYPE' from #{read pipe}# <janneke>guix package: error: build failed: some substitutes for the outputs of derivation `/gnu/store/g13n5crbly56y26dlm223zb5scw80ljh-glibc-locales-2.22.drv' failed (usually happens due to networking issues); try `--fallback' to build derivation from source <anthk_>sorry, lfam, you need virglrenderer too <lfam>janneke: Did it work with --fallback? <ng0>is there any relevance to hackernews? <lfam>davexunit: True, but there have been a few new users here on #guix every day recently :) <lfam>I first learned about Nix on hacker news <davexunit>gnu release announcements can often make it to the front page for awhile <lfam>So, it's relevant to me! <davexunit>the only discussion we get most of the time is "why would I use this instead of nix?" <ng0>oh. i just happily ignore hackernews and find news through people and magazines. nix was through a talk on reproducible builds i think <janneke>i was just thinking everyone has glibc-locales as their first package installed <lfam>janneke: Just FYI, there is also glibc-utf8-locales, which is a subset of glibc-locales for when you don't need all 450 MiB of locales ***kyleschmidt_ is now known as kas2207
<lfam>Well, the archive downloaded fine for me, but I may have already had it cached on my personal mirror <ng0>"super small dockr image based on alpine linux" ... okaayy... as if alpine wasn't already small enough <davexunit>the Alpine Linux thing going on with Docker right now is pretty funny <ng0>i just read the title <davexunit>Alpine doesn't use glibc because it's too heavy for them, apparently. <davexunit>so everything is built with musl, which has limited compatibility. <davexunit>changing the libc would be a big deal for most projects, but when Docker does it it's trendy. <ng0>there are other factors to musl i think other than size i think. I tried it with gentoo hardened, but changing the libc is hard when you already have hardened system which is old, but still in progress <davexunit>I should clarify that this is for the images that Docker themselves provide, the official stuff. users are free to use whatever images they'd like. <davexunit>it's definitely motivated by anti-GNU sentiment. <davexunit>just like GNU replaced proprietary UNIX tools with free ones, the anti-GNU crowd is replacing copylefted GNU tools with permissively licensed ones <ng0>but UClibc is okay. hardened musl has less priority in the hardened project i think, but musl seems to be more stable. <fhmgufs>I really don't understand why there is this anti-GNU crowd. <ng0>or not. seems the problem with musl in addition to the license is what you said, it's just difficult for applications <fhmgufs>I also don't understand "Open Source" in general. <fhmgufs>Why would people not agree with the goals of GNU? <fhmgufs>They can't lose anything and win a lot. <ng0>oh i see enough people not agreeing to various not really logical reasons. <davexunit>they want to benefit from free software without having to share back <ng0>"it's "idealistic" therefore i don't look into what it has done and why this has contributed alot to where we are now" etc <rain1>fhmgufs, anti-gnu because they want to be able to use free software in a job and hide the source code <rain1>open-source is mostly a corperate buzzword used to pretend free software doesn't exist <fhmgufs>I must admit that I don't understand a lot of things about GNU vs "Open Source". Especially not, how "Open Source" could become what it is nowadays. <bavier>lfam: it seems not LLVM, but the patch to integrate it into gcc was the the offer <fhmgufs>I always thought that people are good and want the best for others, if they aren't ill. <fhmgufs>So, I don't get any arguments against Free Software. <davexunit>oftentimes the arguments are hard to understand. <fhmgufs>But I'm happy that I found GNU - It's one of the places where people are good. :) <davexunit>it's common to run into someone that thinks the GPL restricts their freedom and is "viral", but think that using "open source" software to make proprietary software is OK. <lfam>Anyways, all we can do now is keep going! <davexunit>lfam: unfortunately, when that came out, people attacked RMS for using antiquated software to read email. :/ <ng0>> attacked RMS for using antiquated software to read mail <ng0>i must have missed the upgrade to neuro interface <lfam>davexunit: If the offer was for all of LLVM, then I would say that whatever the reason was for not reading the message originally, it was a tragic mistake. How many years of developer time were lost to our movement? <ng0>the whole puzzle of "email" server and client stuff is so old that there are no changes <CompanionCube>ACTION likes free software but does not hate proprietary software <ng0>on open source: i think for some it's a process of learning through discussion and challenging what they know <davexunit>I'm noticing a lot of attack strategies that people use against RMS and the free software movement are being applied to Bernie Sanders in the U.S. primary elections. <lfam>Anyways, I brought it up because it seems that, at least for GCC, there was not an effort to "attack" GCC, but rather a missed opportunity for cooperation. <davexunit>there's no visible "war" going on, the llvm folks are just happily hacking away on their compiler, but it's most certainly motivated in part to unseat GCC and the GPL. <optikalmouse>^ which is hilarious, I always like looking at GNU readline <fhmgufs>davexunit: I just wondered why Builder (this new GNOME IDE) doesn't use gcc for compiling. Isn't that GNU software, too? <lfam>davexunit: Like I said, I see it as a tragic missed opportunity. <lfam>Human nature leads them to compete... <davexunit>fhmgufs: GNOME's relationship with GNU is basically a historial footnote at this point. <lfam>I'm glad we made the effort to support them on GuixSD <ng0>there's still kde.. and others <davexunit>I like and use GNOME, but I think they've made many poor technical decisions that I don't think they would have made if they were more aligned with how GNU does things. <fhmgufs>ACTION really dislikes GNOME 3 (sorry) <davexunit>Software, Builder, inventing Vala, using JavaScript for GNOME extensions, etc. <fhmgufs>Especially using JavaScript for the Shell. <davexunit>GNOME has also done some really awesome stuff and overall I am happy with GNOME 3 <ng0>i use it as long as I can't have awesome-wm or kde plasma here. <davexunit>I like more than any other DE. If I didn't use GNOME, I'd use a hackery tiling window manager instead of another DE. <alirio>lfam: apple rejects drm anti-measures of gpl3 and uses old gcc's with gpl2, and invest on llvm <lfam>alirio: Yes, they do that now. It sucks and I don't use their software. <fhmgufs>To get away from this pessimistic discussion: <fhmgufs>How long will the emacs-24.5 [1] build take (average on i686) <fhmgufs> [1] One thing showing there doesn't need to be pessimism <lfam>fhmgufs: I usually answer that by looking at the last hydra build for the package / arch in question <civodul>janneke: re corrupt thing, which server is it? hydra.gnu.org? <paroneayea>cwebber@oolong:~/devel/mediagoblin$ git tag -a v0.9.0 --sign <paroneayea>error: cannot run gpg: No such file or directory <paroneayea>The tag message has been left in .git/TAG_EDITMSG <paroneayea>lfam: str1ngs: yes, probably, but why doesn't git know to look for gpg2 <paroneayea>ok that'll work for a hamfisted quick approach :) <lfam>paroneayea: I believe you can have both gpg and gpg2 in your profile. <lfam>Or, you can (ab) use --ad-hoc <civodul>paroneayea: i have a 'gpg' script that does 'exec gpg2 "$@"' <str1ngs>would be the proper approach I think <str1ngs>oh you'll have pinentry issues nes :P <efraim>would it be easier to modify gnupg2 to output a second binary called gpg? <lfam>I don't think we should do that... <lfam>gpg and gpg2 are different programs that handle sensitive information in different ways. I'd rather not do something that might confuse our users. <lfam>For example, gpg2 will cache symmetric encryption passphrases, while gpg will not. If a user doesn't trust their system enough to keep those passphrases in RAM, they will use gpg. We shouldn't create a 'gpg' binary that does cache those passphrases. <lfam>I will say the situation is rather confusing already <civodul>janneke: thanks, i've removed the corrupt item <civodul>efraim: yes, what lfam said, plus i think we should follow upstream's choices <rain1>I have package X depending on package A <rain1>and then I install package B (which messes with A) <rain1>isn't that what guix is supposed to fix? <davexunit>luckily you have rollbacks and the abilitiy to make separate profiles <lfam>Some of those situations can be worked around with `guix environment --pure --ad-hoc`, if the software in question is not needed very often <str1ngs>might help to know how package B is "messing" with package A <rain1>is there a list of these problems? <str1ngs>this is kinda vogue and generalized. <rain1>str1ngs, a specific example is guile-next trashing guix by messing with guile <davexunit>rain1: our bug tracker may have something if someone reported it <rain1>it can happen in other ways, i made a thread about it <lfam>efraim: I seem to remember you were interesting in khal. I just fixed it on the master branch. <str1ngs>can I assume guile-next to be a bleading edge version of guile <str1ngs>I think it stands to reason there would be clashes with guile <efraim>lfam: thanks, still need to read the documentation and set it up <lfam>Cool, let me know if I can help <str1ngs>its not something I would use. since guix depends heavily on it? <rain1>I think this issue deserves some consideration <lfam>paroneayea: Looking forward to `herd start mediagoblin`! <mark_weaver>rain1: and it's receiving consideration. please, give it a rest. we're not removing guile-next <rain1>mark_weaver, if you do guix package -i guile-next <mark_weaver>in a free software project, all of us have to deal with the unfortunate fact that we can't have everything the way we personally think it should be all the time. <rain1>your system is trashed into an unrecoverable state <mark_weaver>rain1: I understand that you feel very strongly that removing guile-next is the right thing to do. we disagree. sorry <rain1>mark_weaver, you aren't understanding me at all <rain1>consider doing it in a VM so that you don't mess up an important system <mark_weaver>I'm not on current master, and it seems that I'd have to compile guile-2.1.2 locally, which will take a long time <rain1>it's easy to reproduce in a VM, I could make a video or something if it helps <janneke>rain1: what happens when you: unset GUILE_LOAD_COMPILED_PATH <civodul>paroneayea: congrats on the release! it's release day! :-D <davexunit>paroneayea: putting on my nitpicky typo guy hat for a moment: s/coonfusion/confusion/ in the release announcement <civodul>rain1: one can recover by removing the /2.2 entries from GUILE_LOAD_COMPILED_PATH, though it's admittedly non obvious <civodul>but "-next" is supposed to be hardcode bleeding-edge and all that ;-) <rain1>I booted into arch mounted my guix disk and removed guile-next from manifest and fixed up symlinks etc. <str1ngs>would'nt a rool back have fixed all that? <rain1>I tried selecting on older guix version from the grub menu but it didn't help <rain1>I think that only affects the system profile, not users? <str1ngs>however guile-next is kinda an isolated case <mark_weaver>rain1: I guess you end up in a state where 'guix' itself doesn't work, so you can't roll-back using the usual methods. <ng0>are there appropriate warnings for guile-next? <mark_weaver>it would be good to fix this, for starters by making 'guix' set a %load-path (and %compiled-load-path) that includes only the things that are known to be good, e.g. the guix package itself, guile, and whatever else is needed (gnutls, guile-json?) <civodul>currently 'guix' is wrapped with 'prefix IIRC <wingo>ACTION pleased that it's an early error and not something more insiduous :) <mark_weaver>civodul: okay, I'll put it on my TODO. I'm a bit overloaded, as usual. <janneke>wingo: yeah, getting guile-2.0/guile-2.2 doing the right thing (skip invalid .go files) should be "easy" <civodul>mark_weaver: np then, i'll do it now <janneke>we should really give this some thought for more subtle incompatibilities in guile-2.4 <lfam>From the discussion of the release announcement on reddit: wut, Guix is the damn future. Install a system in a vm and adapt it to the host by using a Scheme file? heaven. <civodul>i suppose rain1 maybe found themself unable to run 'herd', 'halt', and 'reboot' too :-/ <rain1>I used the XFCE menu to reboot and that worked, I guess that goes through a different channel <rain1>i can test those commands in my vm <rain1>yeah all those programs fail in the same way <mark_weaver>when packaging things, I've always tried to use 'substitute*' to patch things to run programs via absolute filenames rather than relying on PATH, e.g. see what I did in the 'wicd' package. <mark_weaver>to the extent that we rely on path-like things, we lose the promised advantages of guix <mark_weaver>now, for programs that shouldn't have any reason to need the user-provided PATH-like variables, then we can simply wrap them to set the needed variables with '= <mark_weaver>it gets more tricky when dealing with programs that are expected to look in the user's PATH-like variables for something, e.g. for shells. <str1ngs>or something like how debian handles multi-arch <mark_weaver>or, when dealing with programs that launch other programs, like launchers for desktop environments <rain1>I've been thinking about that a lot today <rain1>because of that, apt-get update or upgrade or something completely trashed my debian system and made it unbootable <rain1>that's why I quit using debian <mark_weaver>where you really don't want a bunch of wrapper-provided environment variables to propagate into user-visible shells <str1ngs>whats the name of the glibc hook system again? <mark_weaver>str1ngs: I've thought about things like that, but I couldn't find a way to make it work sanely. <str1ngs>hard coded rpath's really help here. which we have <mark_weaver>str1ngs: for one thing, that would only work for C programs <lfam>I thought it was funny and I appreciate the raw enthusiasm <mark_weaver>str1ngs: but it doesn't even really work for C programs, because in general a C program is composed of many shared libraries linked together, and those libraries are from different packages with different inputs, etc. <mark_weaver>str1ngs: if you think you have a full solution, can you write it up as a detailed proposal and post it to the list? <str1ngs>I need further thought on the problem. but yes I'll see what I can do <str1ngs>ideally guile needs protection is the main issue at hand <mark_weaver>str1ngs: make sure to consider how to handle things like python programs that use libraries from a bunch of different python packages, with shared libraries also loaded from several packages, etc. <mark_weaver>I'm sorry, I don't have time to continue this discussion right now <str1ngs>just thinking off hand. We would want to hook path lookup call. and replace it with a call that returns guix mangaged PATH. then call the real lookup. and concant them <str1ngs>this would mean less user managed PATH aswell <rain1>ACTION is trying to test the new fix in git guix, just upgrading stuff .. <civodul>oh interesting, i had never understood that one <ng0>maybe i don't understand docker enough :) <fhmgufs>ACTION is really interested in what Guix's name means <mthl>So I guess the answer is that it doesn't mean much :) <petter>it's fun to say though, geeks :) <fhmgufs>I just read the comments of the early announcement of Guix on HN. <fhmgufs>And I must say that I didn't expect that there would be so much bad comments. <fhmgufs>I found Guix great just reading the first lines of the website. <davexunit>GNU project developers always have to put up with people who mock us. <lfam>It's easy to approach unfamiliar subjects with a negative attitude, in my experience. It takes some effort to approach new things positively. <rain1>I suppose it helps to be dissatisfied with current systems? <davexunit>gotta get used to mocking when you do things that are considered "radical" <fhmgufs>Most comments sounded like just wanting to say sth against GNU. <ng0>helps when you have a history of getting mocked for things which are labeled "radical" (dislike the term radical) <ng0>but it's still unnecessary <fhmgufs>I didn't know this site before, too. <fhmgufs>But I thought that this is a common abbreviation. <petter>i was reminded of a quote: "All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident." I suspect it covers Guix somewhat as well <lfam>I'd rather skip the second stage <str1ngs>mocking GNU projects . mean while there hipster polyglot language is all linked to a GNU userland :P <petter>lfam: in an alternate version the second step is characterized as a "period of vehement denial". <lfam>petter: That sounds better to me <fhmgufs>ACTION wishes Happy Hacking and congratulates for resisting the second step <lfam>How can I update all the packages in my profile except for libreoffice? <wingo>that would be a great trick! <ziz15>guys when i try to install guixsd 10 but it keeps show an error when download python 2.7.10 and wicd it says file corrupt how can i continue installation?thanks <lfam>wingo: You can pass a regex to `guix package -u`, so it must be possible :) <lfam>ziz15: You need to pass the option '--fallback' to `guix system init` (assuming that's where it fails) <lfam>ziz15: Can you share the full path of the failing item? <lfam>We will fix it if you share the path <rekado>many years ago I didn't really like GNU and hoped to have a system in which all GNU things were replace by really short non-GNU programmes. I even thought about switching to the BSDs. Guess what GNU/Linux distribution I used... :) <ziz15>lfam: after i give guix system init /mnt/etc/config.scm /mnt for around 40 min it goes alright..it download packages and install them(for desktop config)) <rekado>optikalmouse: No. Of course: Arch! <rain1>i like the philosophy of GNU, but some of the software (like GCC and autoconf) is too large and complex for me to understand and cope with <rekado>I think anti-GNU sentiments are cultural baggage. <optikalmouse>heh, I was thinking it'd be nice to see if writing packages and services for GUIX is as nice as writing PKGBUILDs for Arch. I enjoyed that heh <bavier>lfam: `guix package --do-not-upgrade[=REGEXP]` <rekado>when around Arch users you become like Arch users. <lfam>bavier: D'oh! How did I miss that all this time? Thanks! <lfam>ziz15: Does my advice make sense? <bavier>lfam: yeah, it's in `guix package --help`, but it might be nice to list it immediately after --upgrade <lfam>bavier: I just need to read the manual again ;) <str1ngs>people dont like autoconf because they dont know why it's needed <str1ngs>and the scope of the problem it solves <rekado>much later I learned about GNU and saw that the usual characterisation of "old shell tools that are just really bloated; and also GCC" doesn't do the project justice. <str1ngs>autoconf is the reason GNU software run's on "all the things" :P <ziz15>lfam: python-2.7.10/lib/python2.7/email/test/test_email_renamed.pyc read pipe <rekado>I'm using the autotools in a new project at work and people love it :) <lfam>ziz15: It should look like this: /gnu/store/pizexample0966zz0ki1nik5qs7r3x75-python-2.7.10 <lfam>ziz15: I want to know the hash, so we can delete the corrupted archive from our servers <rekado>in bioinformatics circles custom configure scripts and crude makefiles are so very common (and a common source of frustration) that automatic configuration is almost magical. <ziz15>lfam: /gnu/store/kcc3cxnx9l2hbg7pjhxsa0r5ypq2j2f38-python-2.7.10 <rekado>honestly, probably any other configuration system would have worked here :) <lfam>ziz15: Thanks! And also for wicd? <rekado>Today I extended the CRAN importer to fold over all dependencies recursively. <rekado>I don't know yet how this feature should behave. <lfam>It should behave like it should behave ;) <ziz15>lfam: /gnu/store/klb2s6r0f6cgpns65gkjwd5m8ygw73wj-wicd-1.7.3.drv <str1ngs>I dont think it matters. as long as the end imported depends are accurate? <rekado>a common thing I do to the output of any of our importers is to wrap the generated expression in "(define-public name ...)" <bavier>rekado: interesting, I was contemplating that feature for cpan and hackage <bavier>a recursive import would need to do the wrapping automatically I think <ziz15>lfam: is there a way i can continue the installation or no?? :( <rekado>so for the CRAN importer I'm producing an alist of package expressions, and in an additional function unpack each alist value and wrap it in (define-public name ...) <lfam>ziz15: Yes, retry `guix system init`, but make sure to add the option '--fallback' <rekado>it was really simple to implement this. <rekado>I only had to make the importer return multiple values <ziz15>lfam: will it continue from where it stop??i mean i try 2 days to install and try this os will it take an hour or so ?? <rekado>first value is the package expression, second value is the list of original dependency names. <rain1>rekado, that sounds like a brilliant example of the power of scheme ^^ <bavier>rekado: did you put that logic in the top-level importer code then? <lfam>ziz15: It should continue from where it stopped. Most likely, it will need to build python and wicd from source. I don't know how long that will take for you. <rekado>trying to get a feeling for what it should do. <rain1>a lot of people ask "whats so great about homoiconicity in guix package manager' this could give really show them <lfam>rain1: `guix graph` is a great illustration <rain1>lfam, I was playing with that earlier today, it's really nice! <lfam>Without homoiconicity, we'd have to do some kind of text scraping <rain1>I wanted to graph my whole profile package tree actually, but I couldn't do that <ziz15>lfam: i give guix system init --fallback it says wrong number arguments for init <lfam>ziz15: Add '--fallback' to the full command line that you used before. <bavier>ziz15: put --fallback before "init" <rekado>lfam: I never really use the term homoiconicity (except when I want to show off). In this case we get value from having an embedded DSL instead of an external DSL. <bavier>since it's an option for `guix system`, not the "init" part <lfam>ziz15: What is the full command line? <lfam>It needs to be something like this: 'guix system --fallback init /mnt/etc/config.scm /mnt'. But, make sure to adapt the location of your .scm file <shanemikel_>when is the community expecting the first non-beta release? <ziz15>lfam: ahh yes it wants also the config path <shanemikel_>and, is guixsd planning on being a completely gnu system? is it only going to include gpl packages? what about the linux kernel, is the system going to support hurd only? <bavier>shanemikel_: currently GuixSD uses the linux-libre kernel, and there is continuing work on hurd support <lfam>shanemikel_: Guix is all free software, but it's not all GPL. We have many permissively licensed packages <lfam>In my personal opinion, we should have easy support for LVM and full disk encryption before declaring a non-beta release. <rain1>I would like to help with encryption in some way if I can <lfam>rain1: There's been lots of discussion and work on the mailing list. I'm not sure what the status is. <rain1>it's definitely a thing stopping many people from using guixsd <rain1>maybe we could work out a way that doesn't involve having a secret store <rain1>its ok to have to enter passwords twice as long as its understood why <shanemikel_>I'm really excited about this.. I just discovered it a couple days ago, but I've been following/playing with nix for some time.. I can't express how glad I am there is a foss community fully embracing progress in the realm of distributions and package/install management <petter>shanemikel_: may i ask how you discovered Guix? <lfam>shanemike1_: I agree with your statement about a free software community embracing (and making!) progress in these areas. It's very encouraging. <lfam>Anyways, welcome! Please ask for help if you need it. <shanemikel_>so, I'm guessing a lot of you are using VMs to test and hack on.. anybody have a nice workflow setup, maybe using vagrant or other tools? 
