<lfam>Any opinions on adding things like init scripts for multiple init / process supervision systems to packages? <SusWombat>Just wanted to ask. Is guixSD ready for use yet? <lfam>SusWombat: It depends on your needs. There are people here using it as their main operating system. Of course, you can always use Guix, the package manager, on top of another GNU / Linux distro. <lfam>I wouldn't go replacing your company's RHEL infrastructure with GuixSD just yet ;) <SusWombat>lfam: nah im just interested in it for desktop usage <lfam>But one nice thing about the Guix system is that, even in an alpha state, it's very easy to recover from problems. It's not like Debian where a botched upgrade can break the whole OS <lfam>Ah, you should join the fun :) <SusWombat>lfam: i have one "maybe stupid" question left <SusWombat>lfam: Do i need a "Only free software" opinion to be comfortable in the community? <SusWombat>sry it may sound wird but i dont now how to ask an other way ^^ <lfam>The project is definitely committed to free software. But Guix is so totally "hackable" that you can easily package any software you want. I don't speak for everyone, but I don't think it's the goal of Guix to _prevent_ you from using non-free software if you want to. But I know that I'm not going to spend my time on it :) <lfam>Some people are using Guix at their jobs, and that requires them to package non-free software. <SusWombat>lfam: naaah i didnt meant like hey you gonna do such stuff for me or such. If i need to i think im gonna be able to. I just meant if im gonna have a hard time in the community if im not fully committed to free software. <lfam>I have found this community to be very friendly so far. I don't think anyone will give you a hard time. <lfam>One thing to notice is that GuixSD uses the linux-libre kernel, which doesn't include binary blobs. That may trip you up if your hardware requires these closed binaries. It is possible to use another kernel, although I haven't tried yet so I'm not sure how. <SusWombat>lfam: Oh good you mention it! Never thought about this. I might have to check this before trying GuixSD <lfam>Good luck and ask questions! <efraim>a search for CVE-2015-8560 primarily points to debian-security mailinglist <efraim>cve.mitre.org doesn't have any information on this vulnerability ***jgay is now known as jgay-tmp
***jgay-tmp is now known as jgay_
***jgay_ is now known as jgay
<efraim>civodul: I have the update for cups-filter to fix CVE-2015-8560, but it involves rebuilding gtk2/3 and qt4/5. the cve doesn't seem to be widely known yet, so should I push it to master? or core-updates? or security-updates or something? <efraim>guix lint doesn't pick up anything on cups-filters <civodul>efraim: security-updates sounds good <civodul>mark_weaver or myself can then tell Hydra to build it <civodul>would also be nice to investigate why 'guix lint -c cve' doesn't pick it up <civodul>apparently it simply isn't in the XML file served by NIST <efraim>when I searched duckduckgo most of the results were from the debian security mailinglist <efraim>I tossed in an update to cups, gtk3 and at-spi2-core while I was at it since they'll be rebuilt anyway <efraim>it seems we currently have origin/security-updates already <Digit>ACTION hopes to get this laptop back on guix once his main workstation is configured to working order, after the laptop's guix crashed (abrupt shutdown) and failure to reboot, which he hopes to understand how it happened... might get that workstation up to working order later today <efraim>civodul: nvm, security-updates can be fast-forwarded to master <wingo>that one is very amusing, isn't it <efraim>I'm going to try it the next time I reboot <nateo>I had a more or less successful install of guix 0.9.0, with one exception: the display is a bit messed up. I have two ATI cards that are supported in the linuxlibre kernel, but neither of them display properly. One (x300se) has the proper geometry, but the color looks like it is 16bit. The other (a bit newer) as the proper color, but geometry is seriously messed up. <nateo>I guess my question is: has there been issues with video before? If not, are the some tweaks I can try? <wingo>i have not heard of such things fwiw but my guixsd system is intel <wingo>i guess i would look at your /var/log/X.0.log or whatever <wingo>perhaps you didn't install a package that would do better for your display adapter <alezost>nateo: people complaint about ATI cards before, but it was because of binary blobs that are removed from linux-libre kernel. But if you are sure, you card works, I think the problem is that our xorg service does not load xf86-video-ati driver <nateo>I am sure of the cards. They both work on Trisquel 6.0 and 7.0, neither of which have binary blobs. <nateo>I'll check out the xf86-video-ati driver question, too. <alezost>nateo: we have 'xorg-configuration-file' (described in the manual), but I'm not sure if it can be used to add a driver. At first I would try to start X server manually with this driver (and the other drivers you need), and if it works, then you can report about it, so that the line with this driver will be added to xorg.scm <wingo>alezost: that is a bug, no? that -ati isn't mentioned <wingo>or are there freedom-related considerations there or something <alezost>wingo: In my opinion it should be there, I think it wasn't added just because people thought that all ATI cards don't work properly with linux-libre <wingo>regardless of what the kernel situation is, seems to me all x drivers should be there <wingo>or maybe the idea was, ati cards work better with vesa or something <wingo>i was building gdb from git in a checkout <wingo>In file included from peigen.c:66:0: <wingo>/home/wingo/.guix-profile/include/wchar.h: In function ‘wctob’: <wingo>/home/wingo/.guix-profile/include/wchar.h:397:47: error: comparison of unsigned expression >= 0 is always true [-Werror=type-limits] <wingo>obviously this error in wctob is in libc or something <wingo>which makes it a system header <wingo>how to mark ~/.guix-profile/include to be a system header dir for gcc? <wingo>civodul: you might know the answer to this, see recent scrollback <wingo>and what's the right solution for this in general? <wingo>when compiling any given project from git, i don't want gcc to report warnings about things in ~/.guix-profile/include <wingo>or in any profile, actually. because that's not what i'm working on, and that's not what gcc does on "normal" systems, where it suppresses errors from /usr/include etc <wingo>civodul: i paste the two lines <wingo><wingo> i was building gdb from git in a checkout <wingo><wingo> /home/wingo/.guix-profile/include/wchar.h:397:47: error: comparison of unsigned expression >= 0 is always true [-Werror=type-limits] <wingo>in specific i guess i add some cflag about system header dirs; should we do somethign in general? <wingo>i guess it's -isystem ~/.guix-profile/include or so... <wingo>ACTION finally dusts off gdb/guile unwinder patches <wingo>CPATH includes are treated as non-system includes <wingo>C_INCLUDE_PATH includes are treated as system includes but are only searched when compiling C <wingo>so i guess instead of setting CPATH we could set C_INCLUDE_PATH, CPLUS_INCLUDE_PATH, and OBJC_INCLUDE_PATH <civodul>wingo: could you check if you get warnings when you prepend /gnu/store/...-glibc/include to CPATH? <alezost>civodul: what do you think about adding xf86-video-ati to 'xorg-configuration-file' in (gnu services xorg)? It may be the root of nateo's problem <wingo>civodul: sure. i think i would though, given that CPATH includes are explicitly marked as not being treated as -isystem. will check tho <civodul>i think this has to do with the configure-time --with-native-system-header-dir=dir <civodul>another thing to try might -fcanonical-system-headers, although that seems to be the default <wingo>there's also the case of errors in any other system header, not just libc <civodul>alezost: why not! eventually we should provide a list of drivers <civodul>wingo: maybe we should open a bug because it sounds like it's going to take more than 5mn ;-) <nateo>wingo/alezost: it looks like I'm going to need to read some more documentation; starting and stopping x and loading modules doesn't appear to work in the same way as it does in other distros. But I am a mere linguist... <alezost>civodul: OK, I'll send a patch for this then (for adding xf86-video-ati, not for a list of drivers feature :-)) <alezost>nateo: If you have a wish, I can guide you through a "hard way": installing X server and required modules to your user profile and starting it manually to see if this will fix your issue <alezost>nateo: at first could you paste your /var/log/Xorg.0.log file? <davexunit>nateo: please do not use pastebin.com. they block Tor users. <nateo>you want me to paste it here, then? <paroneayea>so, last night I did a podcast interview about guix! <civodul>paroneayea: i also thought you would have been a good candidate to speak about Guix{,SD} in the "containers" track at FOSDEM, in the absence of davexunit :-) <alezost>nateo: OK, so it fails to find "ati" module and loads "vesa" instead – I would say it's a good news. However there is also "open /dev/dri/card0: No such file or directory" I don't really now what it is. Just in case could you run "dmesg | grep BLOB" <davexunit>ACTION fights with Chef, Vagrant, Berkshelf, Test Kitchen and wishes it would all just go away <nateo>[ 24.215212] r8169 0000:04:00.0: Direct firmware load for /*(DEBLOBBED)*/ failed with error -2 [ 24.215221] r8169 0000:04:00.0 enp4s0: unable to load firmware patch /*(DEBLOBBED)*/ (-22) <civodul>efraim: be careful with updates in 'security-updates'; last time we did that, it took us days to stabilize the branch, and we wouldn't want to delay security updates too much <mark_weaver>civodul, alezost, nateo: adding xf86-video-ati has been suggested occasionally when people with ati cards try to use GuixSD, but in the past we've always found that adding the driver didn't help anything, because we exclude the non-free firmware blobs needed for ATI cards. <mark_weaver>I'm not sure if there are any cards using xf86-video-ati that can be used without uploading non-free firmware. <nateo>mark_weaver: these two cards are known to work on other linuxlibre kernels without binary blobs <alezost>mark_weaver: yes, I remember it too, but nateo said that his card works with linux-libre <wingo>long mail regarding cpath sent :) <civodul>mark_weaver: oh, would be good to check that, then <alezost>nateo: what is r8169, is it your card? <nateo>the later generations of ATI cards were a step backwards for the Free world... <alezost>nateo: could you run "lspci | grep VGA" <nateo>01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV370 [Radeon X300] <mark_weaver>efraim: I'd like to echo civodul's concern about adding non-security updates to the security-updates branch. unrelated updates may cause additional problems that could significantly delay the security updates. <nateo>i think i was wrong about the r8169... <alezost>nateo: hm, I'm concerned about "/dev/dri/card0" error, but we can try to check X server with ati module anyway. So at first install some X packages (you can remove them later): "guix package -i xorg-server xf86-input-evdev xf86-video-fbdev xf86-video-modesetting xf86-video-ati xrandr" <nateo>alezost: okay that is done. most of them were already installed <efraim>civodul: mark_weaver: sorry about that, I was out for a while. I'll take out the extras updates. I figured since they'd get updated also it would be ok, but they're not really security related. <alezost>nateo: OK, now (in theory :-)) you can start another X server: "sudo X -modulepath $HOME/.guix-profile/lib/xorg/modules :1 vt8". If everything will be ok, you'll be thrown to vt8 (with a black screen), then press Ctrl+Alt+F7 to return back. <mark_weaver>efraim: sure, I can understand why you did it, and I think that's a fine thing to do on branches that aren't for security-updates. <mark_weaver>but we should strive to build and deploy security-updates as quickly as possible <mark_weaver>efraim: btw, thanks very much for taking care of this update :) <nateo>alezost: that did what you said it would <alezost>nateo: Great, now you can start smth on that X server like this: "DISPLAY=:1 xterm &", then switch to VT8 and check with "xrandr" if the resolution is OK. <alezost>nateo: Or the resolution wasn't a problem? I forgot :-) <alezost>anyway now you can check /var/log/Xorg.1.log to see if ati module was loaded <alezost>nateo: I think it's because you have "Depth 8" in your "/var/log/Xorg.0.log". Could you paste "/var/log/Xorg.1.log" now? <nateo>it looks like ati did get loaded, but depth is still 8/8 <alezost>Yes... Hm, I'm afraid "(EE) open /dev/dri/card0: No such file or directory" is a real blocker then. Do you by chance have "Xorg.0.log" file from Trisquel? <alezost>nateo: This "/dev/dri/card0" error sounds like a kernel problem, so I wonder how it works in Trisquel, maybe something has changed in the latest kernel (I think Trisquel uses some old kernel). I vaguely recall someone (yenda ?) has a kernel-specific problem with ati firmware <bavier>does anyone have a clearer idea what the "offline installation media" request on the ML is about? <alezost>I didn't check the ML, but it sounds like a wish to install a system without network access <alezost>nateo: btw could you now run "DISPLAY=:1 xterm &", then switch to VT8 and start something there to be sure that the color problems persist <bavier>that might already be possible, depending on which system packages are declared in the OS config <efraim>mark_weaver: how do I do that? delete the remote branch and recreate it? <davexunit>ACTION reads wingo's mail about 100% solutions <davexunit>I'm inclined to agree, and he mentions wanting the nginx service to be 100% scheme, but I don't see how to do it reasonably <davexunit>there are many nginx extensions that add new directives <davexunit>how could I possibly cover all of that ground? <wingo>not calling you out personally <davexunit>I want what you want, but I don't see the path to get there. <wingo>davexunit: only way i can think of would be to write a tool that extracts the data from nginx source <wingo>and builds a model of what the nginx configuration language is <wingo>unless this model already exists somewhere else <wingo>nginx in particular is ridiculously complicated <wingo>maybe there is a not-so-bad way to do it with clang <paroneayea>wingo: interesting that nginx is more complicated than others <paroneayea>wingo: I've always found it more consistent than apache <wingo>i think you could write a nginx module that traversed ngx_modules and printed out all of the configuration options in a machine-readable format <wingo>that one is probably as complicated as it gets <wingo>ACTION thinking it would not be so bad, and they would probably accept the patch upstream, who knows :) <paroneayea>the sad reality is that we probably need to do string templating for a lot of these things.. <wingo>what do you mean about string templating? <paroneayea>wingo: I mean stuff like jinja2 templates, something like <wingo>to me it seems that each field has its type and its own serializer, is all <wingo>string templating sounds like the wrong thign to me <paroneayea>yeah if we can get proper parsers that'd be nice <paroneayea>the main challenge is that there's so *many* types of config files... <wingo>you don't need a proper parser; just a proper language model <paroneayea>soon guix will be filled with config writers! :) <wingo>serializing is easy when you have the language modelled already <wingo>as long as the scheme interface is more or less uniform, fine with me :) <paroneayea>I agree that string templating is "admitting defeat" <davexunit>that's what all the Chef cookbooks I use at work do <paroneayea>I guess I wave the white flag earlier than others :) <davexunit>postgresql is more realistic to get done in the short tem <paroneayea>it might be nice to have something like fmt for when we *don't* have yet a good config writer for the system <paroneayea>since a modern system involves so many types of config files, it'll likely be true that we'll have many systems packaged before we get around to getting their config writers handled <wingo>`format' is fine :) fmt is nice but afaiu doesn't provide any benefits that i know of <wingo>you still have to implement your own escaping and protect against double-escaping etc <paroneayea>wingo: well one thing that format doesn't provide is a nice dsl for doing things like looping/mapping over values <paroneayea>and writing many config files involving looping over many things <wingo>you can always do for-each, string-join etc :) <paroneayea>we shouldn't do "stringly typed" solutions like jinja2 style templating <paroneayea>I imagine everyone in the channel cringing at that :) <paroneayea>I'll admit that I've spent nearly a decade using stuff like this so it's taken me a long time to recognize what a nightmare it is ;) <paroneayea>wingo: this is what most of the webdev world looks like! string dsls glued together by some other dynamic lang :) <bavier>paroneayea: can't you do stuff like that already with (ice-9 format)? <bavier>I'm apparently lacking on experience. Any examples? <paroneayea>davexunit: wingo: speaking of string formatting hell, I just got a spam email that said <paroneayea>Our records show that your account has a debt of $771.{rand(10,99)}}. <SusWombat>I installed guixSD on my harddrive and it worked so far. But it didnt picked up my arch install into the grubmenu. So i inserted a arch live cd chrooted and reinstalled grub, now i have arch back but there is no guixSD entry in the grub menu <davexunit>SusWombat: there's no way that arch could discover guixsd <davexunit>let alone make an entry to boot the right generation of the system <davexunit>what I think we need is a mechanism for manually adding additional menu entries <davexunit>I have a dual boot system at home that I'd like to work properly, too. <davexunit>the reason guixsd needs to manage the grub menu is so you have the option to boot old generations in case something goes wrong with a system update <SusWombat>davexunit: so i do need to chroot into my GuixSD install now and reinstall grub? <davexunit>I'm not sure exactly. a new install would definitely work. <davexunit>I don't know the steps to recover without reinstalling completely. <SusWombat>davexunit: but is it possible to add my arch install manually afterwards? cause you said there would be a need for an mechanism to add manual entrys? <efraim>debian has os-prober, that might be worth looking into <efraim>I don't know what other distros do <davexunit>the functionality doesn't exist in guixsd's system configuration interface yet <SusWombat>davexunit: but i could manually edit the grub config or not? <davexunit>well, I suspect you *can* manually edit, but it will be wiped out each time you 'guix system reconfigure' <davexunit>SusWombat: right now we have no interface for it. we would like to change that, of course, and would accept patches that add the necessary functionality. <davexunit>efraim: adding a #:probe? keyword arg to whatever generates the grub config would be cool <alezost>SusWombat: I use both Arch and GuixSD <SusWombat>davexunit: how hard is such a thing to implement for an "beginner" in development? <alezost>SusWombat: for that I maintain my grub.cfg manually <davexunit>I suspect alezost maintains his own grub config by hand <efraim>I'll add it to my list of things to work on <davexunit>SusWombat: I was about to get to this. you can pass the --no-grub command to 'guix system' to have it skip doing the grub stuff. <SusWombat>alezost: so you need to replace the condig every update/generation? <efraim>oh, for our tex issue, they have another source tarball on their site that's only 343mb <efraim>and it can be subdivided into smaller packages at configure time <alezost>SusWombat: no, I always have a "current GuixSD system" entry, wait a minute I'll paste it <SusWombat>davexunit: but thgat would mean i would have to add all generations on my own right? <davexunit>SusWombat: if you want to access old generations, yeah. <davexunit>and you or someone else can work on making multi-booting a first-class citizen in Guix <davexunit>SusWombat: "unblock" as in "let you have a GuixSD + Arch system" <davexunit>it's not an ideal solution, but it will work for the short-term <alezost>SusWombat: also I always use "guix system --no-grub ..." <SusWombat>oh and i have a more out of interest question <SusWombat>why does the install system include zile instead of emacs or vi? <SusWombat>im gonna give it another try first without arch. <davexunit>SusWombat: yeah, it's an attempt to keep the image size down <SusWombat>Do i have to config everything in the global config system? <SusWombat>or can i have seperate configs if i need to like an xorg.conf or a .bashrc for example <davexunit>SusWombat: .bashrc is a thing in your home directory, which is a stateful place that guix doesn't manage <davexunit>basically, all system-level configuration is handled by guix <SusWombat>davexunit: could i manage .bashrc with guix? <davexunit>SusWombat: it will be possible, but there's a distinction to be made about files like that <davexunit>first comment about it in #fsf: "meh, this probably won't even surpass Trisquel in number of users" <aeva>I'm planning on attempting to put GuixSD on an x200 soon - does anyone have a system config I can have a look at for a laptop configuration? <francis7>aeva, mark_weaver uses GuixSD on his librebooted x200 <davexunit>(there's nothing laptop-specific about it, really) <efraim>i've been looking at test results people have posted for gcc5.x, and it looks like we might be missing the --with-system-zlib configure flag <aeva>davexunit: is "laptop stuff" accomplished automatically somehow, or in a different config, or does your machine just not have any stuff specific to battery reporting / hibrinate and suspend states? <davexunit>aeva: hibernate and suspend is taken care of by elogind, which is available in %desktop-services ***civodul changes topic to 'GNU Guix | http://gnu.org/s/guix/ | 0.9.0 is out! | donations for the build farm are welcome! https://www.fsf.org/blogs/community/fsf-announces-support-for-gnu-guix | This channel is logged, see <https://gnunet.org/bot/log/guix>.'
<wingo>that fsf article is excellent! <wingo>i've never seen the fsf come out in such strong support of a project like this <wingo>or at least, of a project i was involved in <wingo>yeah i guess so, i was ignorant then :) <efraim>ok, checking my local build log for gcc-5, stage 1 so far uses bundled zlib <civodul>efraim: yes, i've fixed that in core-updates <civodul>wingo: check the author of the article, tho ;-) <fhmgufs>If I have the choice between lgpl3+ or CC BY-SA 3.0, which one should I add to the package definition? I would prefer lgpl3+. <paroneayea>davexunit: can you post it to /r/linux/ and hackernews while I post to the social microblags? <civodul>i guess i should add a post on sv.gnu.org pointing to that one? <civodul>and at least add a link on the "donate" page <civodul>while someone like roelj comes up with neat graphics and stuff ;-) <davexunit>paroneayea: someone already beat me to r/linux :) <civodul>oh, the author name has changed, funny :-) <civodul>there must be a spy on this channel ;-) <davexunit>civodul: looks like john made an edit and it set him as the other <davexunit>"GNU Guix is a solution looking for a problem. Nothing it does can't be done by normal package management and done better." <davexunit>except unprivileged package management, transactional upgrades, rollbacks, etc. <fps>is there someone wrong on the internet? <paroneayea>davexunit: could you link the HN and reddit posts? <paroneayea>though I guess we should upboat from HN new itself <davexunit>so I don't really care if we trigger the voting ring detector <paroneayea>civodul: replace that whole top header in blue with a call to donate, or put it somewhere else prominent <paroneayea>it's super critical it gets on the site right now <roelj>I've got an extra green head info bar right now with a donate message, if you want.. <roelj>I'm also working on a graphic to put in a corner or on a side. <SusWombat__>is it normal r=that it takes verz long to install stuff_ <SusWombat__>is it normal that it takes very long to install stuff? <davexunit>SusWombat__: unfortunately yes for now, our build farm frontend is too slow... which is why we're seeking donations currently! <roelj>If you have a better message, please tell :) <davexunit>we may want to remove the other banner for now <davexunit>or at the very least put the fundraiser banner on top <bavier>roelj: I'd replace "this Christmas" with "for the holidays" <roelj>davexunit: What do you prefer? Remove the blue bar, or swap the order? <davexunit>I'd leave that up to someone else with a better idea of usability :) <roelj>I could make the "donate" a button-style thing too. <karhunguixi>seems like there's a mix of alpha and beta. Homepage says alpha (banner and button), FSF contribution post says beta. <davexunit>karhunguixi: yeah, banner should be updated to say beta <bavier>it's a big day, moving to beta status <civodul>and without writing a single line of code! <bavier>many lines of natural language though ;) <roelj>Suggestions for a other color? Possibly dark gray or light gray with black text? <roelj>Or softer red (like the button on the bottom of the page)? <civodul>i'm not convinced by the green though <civodul>what about using another shade of light blue, or one of the colors already in use on the page? <tsyesika>Hey, I'm adding packages to my package declaration in my /etc/config.scm however a lot of them are undefined so i need to add the modules to "use-package-modules", to get the information about which module the package is in through i'm going to https://www.gnu.org/software/guix/packages/ and clicking on the package to see which module it's declared in, is there an easier way? <tsyesika>davexunit: I'm also strugging to list "make" there, it seems to be in base, but even when explicitly including that it still complains about an unbound variable <civodul>roelj: or rather black text on white background? <davexunit>tsyesika: the variable name is not necessarily the same as the package name <davexunit>because 'make' is actually a generic procedure in Guile for the OOP interface <karhunguixi>my favourite so far is the one with green background <bavier>there was some discussion on the MK about using specification->package, did the manual get updated with an example of that? <civodul>bavier: yes, under "Using the Configuration System" <paroneayea>davexunit: I didn't know about "guix package -A", thanks! <paroneayea>tsyesika: my answer wouldn't have been nearly as good... I just use "grep -R" and the emacs M-x guix-all-available-packages interface to find out the info ;) <roelj>I'm going to try purple as well <civodul>roelj: could you send a patch for the black-on-white variant? <civodul>i can apply it before going to bed :-) <roelj>civodul: Are you sure? I'll send it in a sec 
