***nckx is now known as nckx|offline
***nckx|offline is now known as nckx
<davexunit>ACTION pushed a libdrm update to core-updates <dmarinoj>mordocai: Oh, I got it, would you please add me to the mirror? I'm dmarinoj87 ***TML-prv is now known as TML
<rekado>One thing that annoys me repeatedly is Python in Guix. <rekado>when I have an old profile with python2, python2-numpy, and a couple of other science python things installed, installing htseq causes lots of conflicts. <rekado>This, of course, is because htseq can be used as a library (in addition to being used as an executable), and thus it must propagate python2-numpy. <rekado>As a user I don't see this when I install htseq. <rekado>guix doesn't warn me about this impending collision. <rekado>even though it does know about it in advance. <rekado>so, once the package has been downloaded I get hundreds of lines telling me about collisions. <NiAsterisk>there's lots of traffic on the dev list: I just updated the status of lispf4. I will get the authors help in a few weeks, what I currently see as necessary is that I should open a bug explaining why it's broken, that I am working on it and close it once it is fixed. <rekado>propagation is annoying and I wished we could get rid of it. <rekado>in the case of Python that's probably very difficult to achieve. <rekado>in the case of Ruby it may be easier (as "require" can use the full paths to libraries). <rekado>I wonder if we should patch all Python files such that they add the store item paths to their PYTHONPATH before importing anything else <rekado>eg import sys; sys.path.append("/gnu/store/cabba9e...-numpy.../lib/..."); import numpy <rekado>I'll send this to the list for discussion <NiAsterisk>ACTION just spend 10 minutes writing an email to a random website where they described LaTeX as if it had no license and was freeware. <cehteh>i bet they need less than 10 seconds to glance at it and hit the delete button :D <NiAsterisk>maybe. maybe not. :) sometimes I have a bit hope in people. <rekado>I had good experiences with license-related bug reports to authors of bioinfo software. <rekado>they are usually not very much concerned with licenses (or software engineering), but many projects actually did clean up their license statements and fixed licensing conflicts. <NiAsterisk>it was just a random advice giving website centered on job application help. it was like "latex has no license, it is freeware and you can use it, it also doesn't cost anything, bla." (rough translation and summary from the german website) <NiAsterisk>somehow it poped up while searching for something LaTeX related. <efraim>wow, and I feel guilty when my guix folder has 100 undread <NiAsterisk>I don't read everything though.. I read what I'm interested in and answer occasionally. I'm not stressed by the ammount of boxes :) <NiAsterisk>okay, thanks for your input rekado. I'll be afk again, got to continue working on that job application. <davexunit>I'm having trouble figuring out where the memfd_create C function lives. <davexunit>the declaration of such a function is in the linux headers <davexunit>but the function isn't in glibc nor any other library that I have on my system. <davexunit>I even built a new glibc with updated kernel headers and it still wasn't there. <rekado>davexunit: I have a file in /gnu/store/.links that matches this string. <rekado>it's an ar file, and so far it's the only matching file. <davexunit>rekado: the kernel itself has a reference to sys_memfd_create <davexunit>but I can't find the library that an application can actually link against that has this. <davexunit>I thought it would be glibc, but I grepped the 2.22 sources for "memfd_create" and got nothing. <davexunit>this is my current blocker for building some bleeding edges intel graphics drivers. <davexunit>which I'm not sure will even work on my hardware, but it would be nice to find out! <mark_weaver>davexunit: it's a system call, and according to that man page you just referenced "Support in the GNU C library is pending." <mark_weaver>davexunit: so, you'll need to use 'syscall' directly, similar to how you wrapped 'clone' in guix/syscalls.scm <davexunit>I'm curious what Mesa expects me to be using to build it, then. <mark_weaver>is it a released version of Mesa, or from their VCS? <davexunit>mark_weaver: it's a branch from their VCS, but Intel made it available for people to build and try out. their README doesn't mention anything in particular about this. <davexunit>so perhaps Fedora's glibc has a patch that exposes this system call. <davexunit>I saw this, but wasn't sure what to make of it. it's over a year old. <davexunit>bah, guess it's a pipe dream to actually be able to use this driver any time soon. <davexunit>oh great. I don't know how to look up their patches. <mark_weaver>davexunit: you could also patch the Mesa to add a wrapper for memfd_create that uses 'syscall'. <davexunit>this way, I should be able to avoid a world rebuild just to try this out. <davexunit>mark_weaver: this is interesting. on closer inspection, this is what mesa already does. so something else is going wrong here. <davexunit>mark_weaver: I see more clearly now. glibc built with the new kernel headers declates SYS_memfd_create in include/bits/syscall.h, but our current glibc does not. <davexunit>so, no patch is needed, but I need to rebuild the whole toolchain to use this new glibc. <davexunit>which I don't really have the resources to do, so I'll wait upon a core-updates build + merge. <mark_weaver>davexunit: in the meantime, if you want to play with it, you could probably hack it to DTRT <davexunit>or maybe hack in the relevant glibc header lines into the mesa source. <mark_weaver>ACTION tries to focus hydra on the most important builds <davexunit>mark_weaver: btw, I pushed a patch to update libdrm to core-updates last night because it will causes rebuilds of basically anything that uses mesa, which is hundreds of things including Qt. <davexunit>this patch is also in anticipation of a future stable Mesa release. <rekado>revisiting my work on the ant-build-system I notice that the first package I successfully built with ant-build-system bundles a couple of libraries. <rekado>when they are removed things no longer work. <rekado>replacing them is going to be difficult because it also requires patching the build.xml :( <rekado>it is so common in the Java world to just ship a ./lib directory containing lots of third-party jars. <rekado>and reference them in the build.xml, so you cannot use equivalent jars elsewhere on the CLASSPATH ***E4xoi is now known as hacker
<mordocai>sneek: later tell dmarinoj You should now be added to my guix mirror, please try to push again. <davexunit>Canonical merged ZFS, which we all know is incompatible with GPLv2, into the Ubuntu kernel tree. <efraim>they said they weren't going to use dkms, but didn't really believe it <davexunit>calher: it's licensed under the CDDL, which is incompatible with the GPL <calher>That's a bug in the GPLv2, then. <calher>Free software should be together. <calher>Free software should not be divided. <Jookia>CDDL is meant to be GPL-incompatible <davexunit>Sun *deliberately* chose this license when ZFS was created. <Jookia>There's no one to kill, you just use something better like XFS or Btrfs <keverets>calher: GPL is explicitly "no further restriction" and CDDL added additional restrictions precisely to be GPL incompatible <calher>I guess Oracle killed Sun for me. <davexunit>this is is a common issue. when people see something that is not compatible with the GPL, they blame the GPL. <Jookia>davexunit: I think a lot of people don't understand that free software is more than just a license, it's about making sure people actually get that freedom <davexunit>I'm interested to see what the SFC has to say about this Ubuntu situation <keverets>the official stance so far is "We've followed ZFS + Linux GPL incompatibility carefully. No new comment now, except: we continue to investigate the evolving situation" <calher>Excuse me, but licenses that are meant to do the same thing should have compatibility clauses. <calher>Like Art Libre License and CC-BY-SA <Jookia>calher: CDDL doesn't want compatibility <davexunit>keverets: interesting, because they already made a commit to their kernel tree! <Jookia>davexunit: bkuhn was right, Linux is the holdoff on copyleft <keverets>davexunit: that's the SFC comment, not Ubuntu/Canonical <Jookia>davexunit: Maybe, companies will rewrite everything except Linux and now they're pushing to see if they can get away with illegally using proprietary kernel modules <keverets>my bad. should have made the author clear <davexunit>keverets: np. it makes sense that it's what you mean upon a second reading. <Jookia>davexunit: You've gotta stop reading HN man <Jookia>Is it even possible to write proprietary kernel modules? The kernel's not LGPL <_`_>wasn't this discussed already <rekado>AFAIU writing is possible, but you cannot redistribute binaries. <_`_>“In the case of the kernel, this prevents us from distributing ZFS as part of the kernel binary. However, there is nothing in either license that prevents distributing it in the form of a binary module or in the form of source code.” <_`_>canonical may be stupid, but they aren't stupid enough to distribute zfs built into the kernel. <davexunit>_`_: the commit I referenced about adds it directly to their kernel tree. <davexunit>_`_: that "distributing it in the form of a binary module" is also wrong. <_`_>you yourself said it should be fine <davexunit>the argument is that kernel modules are derivative works of the kernel <davexunit>a derivative work of the kernel must be GPLv2 licensed. <davexunit>Jookia: it's not in the spirit of the GPL, that's for sure. <rekado>AFAIU that's why Debian builds the modules dynamically from source whenever the kernel is updated. <_`_>there's no definitive/authoritative assessment of how to go about this <_`_>debian and others currently use dkms (which is horrible) <_`_>or individuals package on a per need basis (generic debs, rpms, or like on arch) <Jookia>It seems odd that you a derived work is okay to distribute as source but not object code <davexunit>the legal precedent seems to be that it is OK. I wish it were not. <_`_>but if you can't distribute kernel models, how are all these lives with zfs for linux kernel as modules being built? <davexunit>the trick Debian does that rekado mentioned would also have to be done on Ubuntu <_`_>dkms is already an option on ubuntu <davexunit>_`_: they build the module themselves and do not redistribute. <keverets>it's the difference between distributing a fan-fic "post story chapter" versus selling a book with the original and the addition together <davexunit>it's the distribution that triggers the violation <_`_>davexunit: how is that any different? They're distributing a live with a prebuilt module <_`_>it's not built on init or something <Jookia>So the idea is that they're distributing a way to use it without distributing <_`_>it's already compiled in the live and loaded on boot. <_`_>these lives aren't using dkms <_`_>people are building modules for the kernel of the live and including them in the live <_`_>is this wrong legally? <_`_>if it is, it should be addressed. <Jookia>It's definitely wrong morally, so let's shame Canonical <_`_>if it's not, then nothing that can be done. <davexunit>and it seems like Canonical intends to do this. <df_>don't canonical already distribute several binary kernel modules? <_`_>afaict, you can't distribute a linux kernel binary with zfs built in <_`_>you can distribute a linux kernel module. <Jookia>So the GPL allows for combining code that's otherwise incompatible if you don't distribute it, and so the 'solution' to this is to distribute some code that'll automatically do that for you <davexunit>df_: Canonical has violated the GPL before, yes. <Jookia>I wonder if this is because sfconservancy isn't going to be doing much GPL enforcement for a while aside from vmware <mark_weaver>the GPL is not a contract, and it can't prohibit anything. all it can do is *allow* certain things that would otherwise be prohibited by copyright law, and that's primarily distribition. <df_>davexunit: I meant more as a matter of course - binary-only device drivers for example <davexunit>df_: one can argue that those modules are violating GPLv2 <mark_weaver>it depends on what kernel interfaces are used by the module in question <df_>aiui the kernel developers' position is that they won't enforce it but nor will they provide any support for it <mark_weaver>it's somewhat a judgement call of what constitutes a derivative work. <Jookia>I know there's EXPORT_SYMBOL_GPL but isn't that useless since it's all GPL anyway <davexunit>yes. exactly which modules... now I must defer to lawyers and kernel people. <Jookia>Or is there permissive code in Linux <mark_weaver>but Linux (the kernel) marks certain symbols as being only available to GPL-licensed modules, and the idea there is that by using those interfaces, you are more intimately integrating with Linux and thus becoming a derivative work. <_`_>I'm pretty sure zfs avoids using GPL symbol exports for that very reason <_`_>it's why there's still no FS crypto on zfs on linux <mark_weaver>df_: there are many different copyright holders in the kernel. some of them won't enforce the GPL, but others will. <rekado>aren't there also binaries of proprietary kernel modules that are distributed by graphics card vendors? <_`_>can't use what's GPL, so waiting on illumos. <davexunit>Matthew Garret, who is a long-time kernel developer and FSF board member, asserts that Canonical is in violation here and mentioned contacting the SFC about it. let's see where it goes. <mark_weaver>there are some kernel developers, e.g. Matthew Garrett, who hold copyright in parts of Linux and will enforce the GPL <davexunit>some of his copyrights may be infringed here. <davexunit>I am always surprised at how acceptable it is to ignore the GPL when its convenient to do so. <mark_weaver>when people say that the GPL "prohibits" something, it's more accurate to say that copyright law prohibits it, and the GPL doesn't allow it. <_`_>yes, ergo why I asked “is this wrong legally?” <mark_weaver>well, more precisely, copyright law prohibits it unless specifically allowed by the copyright holders, and the GPL does not give permission in that particular case. <mark_weaver>_`_: I don't know, I'm not sufficiently familiar with this particular case or with the law to answer that. <_`_>so far, I'm unsure Canonical including zfs in their kernel tree just to automate building zfs as a kernel module is wrong. Nothing in that commit suggests they'll be building it in. <Jookia>_`_: Well it's weird for them to add it if they're building it separately <_`_>from every point of view ever <_`_>from a packaging one especially <df_>who is "the industry's leading software freedom legal counsel" ? <_`_>it's just as bad as bundling. <_`_>it effectively is bundling really. <Jookia>If Canonical does this, a lot of other people are going to do it too :| <_`_>if you mean *this* specifically (it's quite the special case) <Jookia>"Our conclusion is good for Ubuntu users, good for Linux, and good for all of free and open source software." Oh ok let's pack up <davexunit>"we are not interested in debating license compatibility" <Jookia>So, to be on topic, does this mean Guix won't package ZFS? <_`_>I've asked if it could be a bunch of times <_`_>I get a different answer each time <Jookia>df: love the picture of the tilted scales in the Ubuntu post- subconcious guilt? <_`_>rh won't because it's betting on xfs/btrfs. <df_>surely getting ZFS on guixsd is easy, just port guixsd to the illumos kernel :p <_`_>I'd love such an effort <_`_>but illumos kernel itself is cddl <davexunit>Jookia: I can't say this with certainly, but we might technically be able to distribute a package, but we'd have to force it to be non-substitutable. <davexunit>or some such trickery. I'm not sure we want to promote this, as a project, but that's not for me to decide. <_`_>mark_weaver: the uncertainty with packaging zfs on linux on guix. <mark_weaver>_`_: if GuixSD were ported to the illumos kernel, then there's be no licensing issue afaict. <Jookia>davexunit: Guix does go above and beyond strictly licensing issues and tends to avoid pushing users to proprietary software. Maybe DKMS is the Javascript downloading of Linux? ;) <_`_>mark_weaver: hopefully. <_`_>I'm tired of all the petty mud slinging and just want definitive answers on what's permitted and what isn't. <Jookia>pizzaiolo: That's so weird that that site gives me *two* scrollbars <_`_>while I agree, let's refrain from name calling ***hacker is now known as init
<davexunit>_`_: calher has been rude in this channel on a number of occasions. <_`_>I'm aware, hence why I agree. <_`_>doesn't take away from my subsequent statement <davexunit>calher: you're going to have a hard time using GuixSD if you hate the FSF, because we follow their guidelines for fully free distributions. <_`_>calher is indeed quite the deconstructive individual. <_`_>But name calling won't help in the matter. <calher>Everyone hates me. I have no place in the world. <fhmgufs>calher: I think it's not a good idea to say that you hate the fsf in this channel. <Jookia>calher needs to get some kind of therapy. He's okay a lot of the time but not great the rest <Jookia>I say that even though it's off topic because I can see a ban coming <Jookia>mark_weaver: I found a good solution to passing arguments for GRUB around without adding intermediate data structures so I'll probably post that patch up soon once I implement it- it relies on the VM refactoring patch though <fhmgufs>Is there sb knowing why the .desktop files aren't shown up in the MATE panel? Why is it working in Xfce? It's a normal XDG menu file and it should respect XDG_DATA_DIRS. <cbaines>I possibly have the same issue with the gnome shell, as I am missing icecat for example... <Jookia>It'd be worth looking at how NixOS handles this <fhmgufs>cbaines, Jookia: Yes, I think each of these has its own implementation of the XDG menu specification, so I'll take a look at the MATE source code. <fhmgufs>cbaines: And for GNOME I saw that the default applications are directly included in the menu file. So they are shown while others are missing. <mark_weaver>ACTION runs in console mode for now, because it was quicker to get rebuild with the glibc fix <fhmgufs>cbaines: But I don't know what Xfce does. <mordocai>ACTION is reminded he should rebuild all the guix stuff on his machines. <mark_weaver>regarding .desktop files: the problem with IceCat is that it simply doesn't install a .desktop file <cbaines>On a different topic, I am having a problem packaging Sonata (a mpd client), the tests fail during the build, probably as it can't import a python package, but when I run the tests from an environment, they work fine. What is different between guix environment and the build environment? <mark_weaver>but I can report the Xfce does detect the .desktop files of other things and include them in the applications menu. <fhmgufs>I think they don't have a menu implementation. <fhmgufs>They just search for files in XDG_DATA_DIRS <cbaines>(another easy way to investigate this would be to get a shell in the build environment, when the build fails if that is possible?) <davexunit>cbaines: 'guix environment' doesn't isolate the network, file systems, etc. by default <davexunit>'guix environment --container' might be worth a shot to try to reproduce <cbaines>Ah that seemed to do it :) (used --pure as well, just to be extra, well, pure) <davexunit>--pure will clear other environment variables, but it won't create an isolated container <davexunit>cbaines: could sonata be trying to access the network? <davexunit>I liked it a lot, but it's been unmaintained for a very long time last I checked <davexunit>so I knew my issues with it would never be fixed unless I did it myself, but the code wasn't so great so I just moved on. <cbaines>davexunit, I don't think so, I think it could be to do with pygobject and typelib files for Gtk, but I'm still investigating <cbaines>So I think the reason why the build is failing is that GI_TYPELIB_PATH is undefined <cbaines>There is a message relating to this for the python-matplotlib package <cbaines>I have looked at package specifications that contain native-search-paths, they all specify some list of search paths (whereas this says the behaviour I am after is automatic). <wingo>ACTION has a fully updated xorg system, with working gl on broadwell <Jookia>wingo: broadwell, does that require blobs? <wingo>it is intel and all their 3d stack is open <wingo>might require microcode blobs and wifi/bluetooth blobs of course <wingo>anyway, working updated xorg, good stuff <wingo>mark_weaver: i had to build an xorg.conf.d directory as part of the xorg service, collecting conf snippets from various packages <wingo>i guess the "right" thing is to make services for xorg modules you would like to include <wingo>otherwise input wasn't working <wingo>i thought the graphics froze and so was spelunking there for a while <wingo>but that wasn't the problem: it was that i had no keyboard/mouse/etc <wingo>because there are some snippets in an xorg.conf.d that need to be present to associate input devices with drivers <wingo>mark_weaver: i have a branch with literally like 10 commits, all of which are named "checkpoint" ;-) <wingo>if you want that, you are welcome, or i can separate them first <mark_weaver>meanwhile, I'm in text-only mode to get the glibc update sooner :) <wingo>i still haven't done that one; i should, though. <mark_weaver>we really do need working grafts urgently, but alas my entire household has been sick the last few days, so I don't have quite enough energy to dig into the grafts code and get it working. <a_e>wingo: That is the exact same thing I said to my colleague at work today! <a_e>So much useful code that could be written, so little time to do it :-) <cbaines>To close off my query earlier, I added gobject-introspection as a propagated-input, and that has fixed the tests for sonata. <mark_weaver>cbaines: does it need to be a propagated-input? if it's just for the tests, making it a normal input should be enough <svetlana>i'm watching the 'emacs of distros' video; there is a web interface to the package manager and a emacs interface to the package manager; are there any other? <mark_weaver>there's also the command-line interface, as well as interfaces from scheme code. <svetlana>are there any ui toolkits which are hackable using guile ? <fhmgufs>mark_weaver: By the way: where is this famous web interface? <mark_weaver>there's guile-gnome, although it hasn't been updated to gnome 3 yet. <cbaines>mark_weaver, It is a propagated-input for python-matplotlib (which is why I made it a propagated-input for sonata. Is there a way I can test the package to check if its not needed at runtime (testing it in isolation)? ***init is now known as \\e
<davexunit>hasn't gotten much love in like a year, though. <davexunit>there's some things I want to rethink about the javascript libraries I am using. <ajgrf>that reminds me. when guix eventually gets a friendly interactive installer, it would be nice if it ran both graphically and in text mode. i was thinking the other day that emacs might actually be a good platform for that <davexunit>svetlana: it would have to be on a different server. gnu.org does not run dynamic web applications. <davexunit>and this web interface is not intended just for package browsing <davexunit>it just so happens that it was the first thing I wrote <davexunit>if/when it's more fleshed out, it will allow for doing all the normal package management things ***marxistvegan_ is now known as marxistvegan
<wingo>jeez this is going to be like 60 packages updated <davexunit>wingo: wow. they sound like good candidates for core-updates <ajgrf>how do i get the glibc update if i don't want to wait for hydra? <davexunit>I pushed a couple patches there recently to prepare for a Mesa release that supports Vulkan on intel chips <davexunit>ajgrf: the hard way. you update the glibc package and then rebuild the world. <wingo>i will push a side branch, people who understand guix releases can decide where it goes :) <wingo>np, i wanted working accelerated 3d and now i have it :) <davexunit>I almoooost got the vulkan branch of Mesa to build. got past my glibc problems, but it appears that gcc thinks their code is invalid in a few places. <ajgrf>davexunit: i found it in the security-updates branch, i guess i'm asking how to get guix to use it <davexunit>then you could cherry-pick that commit into whichever branch you are using. <davexunit>I don't think my laptop is up to the task, so I haven't done it. <Jookia1>It'd only take a few days wouldn't it <ajgrf>i'm not updating my guixsd system, but my debian+guix system probably has a lot less to rebuild <a_e>You could check out the branch from git. <davexunit>ajgrf: once you have guix built from git, you could run this from the root of the source tree to upgrade your profile <davexunit>cbaines: happy to see that someone picked up sonata. it uses GTK3 now. <davexunit>if you manage to get it packaged, I'd love to try it out again. <cbaines>davexunit, I think I have a working package, patches (2) should be on the list within a few hours (I keep getting distracted) :) <davexunit>I'm an MPD fan, but I haven't had a proper setup in quite some time. <davexunit>I'd love to have an mpd client that could control a remote mpd *and* stream its audio <davexunit>or more importantly, if MPD could be a multi-user system where each user could have their own state <davexunit>rather than controlling the same global state. <cbaines>as for state, the easy way of doing that would be to run multiple instances <davexunit>mpdroid did nothing but crash last time I used it. <davexunit>a web or desktop client that did what mpdroid does would be cool. <cbaines>Streaming is really easy, you just go to the right url (as configured in the mpd config), and your browser will stream and play <cbaines>(of course this does not allow any control of what is being streamed) <davexunit>yeah, I want a client that does all of this together <davexunit>without a significant lag in the stream like there currently is <davexunit>I'd change a song but it would take a few seconds before the change was audible to me because of how they were buffering audio <janneke>i need guile-next (and guile-next-lib) for some projects, that still gives me problems <fhmgufs>Could sb using GuixSD please say which value the environment variable XDG_CONFIG_DIRS has? <cbaines>fhmgufs: /home/chris/.guix-profile/etc/xdg:/run/current-system/profile/etc/xdg <fhmgufs>It's not defined on my system (not GuixSD causing me a lot of trouble, <fhmgufs>That was the reason for the missing .desktop files. <davexunit>janneke: I use the current guile-next package for my own Guile projects without issue. what problem are you having? <wingo>mark_weaver: pushed as wip-xorg-server-1.18 <wingo>it's like 64 commits; what should i do with it? send just the updater and the service change to the list? <davexunit>wingo: that sounds reasonable if everything is else is just version bumps and hash updates. <davexunit>maybe just mention the remote branch that the full patch set can be found in <wingo>the push is stuck at sending emails <davexunit>wingo: there's something wrong with a GNU mail server, I think, or perhaps savannah. dunno which. <davexunit>would be nice if the mail hook didn't block the push :) <sneek>dmarinoj, you have 1 message. <sneek>dmarinoj, mordocai says: You should now be added to my guix mirror, please try to push again. <mark_weaver>wingo: I've found those delays to happen more often than not lately, but it does eventually succeed in my experience. <wingo>i sent my mail with the patches <wingo>probably it arrives before the branch :P <mordocai>dmarinoj: Excellent, i'll take a look at it next time I have the motivation :) <efraim>scheme/guile question: if has true->A, false->B, eq? has only true->A ? <efraim>for if I have to account for true or false, for eq? is false just null? <davexunit>efraim: eq? is a procedure that takes 2 objects and returns #t if they are the same object. <efraim>you think i'd remember that from my lisp class <efraim>so I'll go with (if (eq? 'foo bar) <davexunit>efraim: when in doubt, type ",describe foo" at your REPL, where "foo" is the symbol you want to look up documentation for. <dmarinoj>mordocai: I will probably work on it a bit this weekend. Fair warning I did not get very far <wingo>so at this rate i have to leave my laptop open for another hour in order for the emails to finish sending <mordocai>dmarinoj: Feel free to use that mirror for personal use too, just don't mess with my personal branches nor any of the upstream ones :) <wingo>i have a query! if there is an important security update like the glibc one, why not push to master? <davexunit>I wonder if the FSF sysadmins are aware of this issue. <wingo>there is evidently a tradeoff <davexunit>wingo: a bunch of confused users wondering why they are building the world from source. <wingo>and i'm not sure that we're making the right decision right now. dunno. <wingo>is confusion among relatively early adopters more important than this security update? <davexunit>in the future we should be able to push something like this to master without much worry. <mark_weaver>wingo: it's a reasonable position. I'm on the fence myself I confess. <mark_weaver>but if we push it to master now, then most systems will have to do a *lot* of compiling to update. <mark_weaver>and given that "guix pull" has no mechanism to go back to the previous version, basically guix will be unusable for people until hydra has built it out. <mark_weaver>when we have working grafts, then this won't be an issue. <wingo>how much time does it take a recent-ish machine to do the rebuild? i guess i will apply the patch locally and see <wingo>waiting for hydra has the issue that it might be building packages you don't need or care about <mark_weaver>it depends on what packages you're asking to update. <davexunit>yeah, we just have to suffer not having a fast response to this glibc issue this time around, with the expectation that we'll prioritize fixing it for the next one. <wingo>davexunit: i'm just not sure that even in the current case we're making the right decision. but, reasonable people may disagree :) <mark_weaver>we don't currently have a priority system, but hydra supports it, and I've been aggressively, manually, hacking the database of builds on hydra to prioritize the builds. <wingo>and yall have your fingers on the guix user happiness pulse more than me <Jookia1>Regardless of what should be done, we all know what must be done. :) <mark_weaver>for those who run guix from git, it's trivial to cherry-pick the patch: "git cherry-pick origin/security-updates" <mark_weaver>but there's no question that we erred to not get grafts working properly before now. <wingo>mark_weaver: on the upside, it seems that some recent x server api change meant that most every module got a release <wingo>so i didn't have to do much to keep things building; at least for the packages that are pulled in by the slim-service <wingo>yeah. funny to see releases for things like xhost :0 <mark_weaver>when I tried to update to 1.17, it seemed that I would need to drop some drivers. <mark_weaver>which is the main reason I didn't push it at the time. <efraim>on my machine building from the bootstrap binaries to base is about 10 hours <wingo>okeysmokes, i am rebuilding the world after the glibc update <mark_weaver>wingo: suggestions on packages to prioritize for hydra to build, that aren't already built, would be welcome <mark_weaver>IMO, priority should go to popular packages that take a long time to build. <wingo>mark_weaver: i reckon hydra won't help me much because i have a new libx11, and anything that's not graphical won't take long to build. dunno tho <mark_weaver>I prioritized icecat which uses gtk, so I guess gtk is already prioritized by transitivity. <efraim>qt-4 was under 4 hours on my machine <a_e>For qt it would be good if we could revert to parallel builds soon. After the python-2 update, I suppose. <wingo>i thought i would let this thing run overnight but i get a weird error about a missing make-session in (gnutls); ring a bell? <wingo>i guess at some point guix reconfigured but outside of guix environment guix and didn't pick up gnutls, or something. <davexunit>wingo: this likely means that an tarball URL redirects to https <davexunit>we don't pull gnutls into the build environment unless the URL starts with https <davexunit>so find the culprit and s/http/https/ in the origin record <wingo>Starting download of /gnu/store/87mxipb93cxhg4wy13wa8wk9mjsxd937-pkg-config-0.29.tar.gz <wingo>note the dash in the redirection too <davexunit>so requiring gnutls in the pkg-config source build environment leads to a cycle <davexunit>I don't know what the answer to this problem is. <davexunit>basically nothing in the gnutls dependency graph can download source over https <davexunit>there's got to be a solution here, but I don't know what it is. <wingo>download pkg-config from debian's servers maybe? <a_e>Download it by hand and put it into the store? I know that is cheating, but it can break the cycle. <mordocai>Oh yeah, I used a substitute when I ran into the pkg config error. There's a message on guix-devel about it but I don't think it has been discussed much. <wingo>i guess most guix installations that build from source already have the file in their store <davexunit>the problem is that we can't reasonably drop the gnutls dep and implement tls in pure guile. <davexunit>for http downloads we just use pure guile so no worries about this kind of thing. <davexunit>the git and svn download methods also have this same issue. <davexunit>I'm not sure of a reasonable way around it in this case except for pointing to another tarball URL like wingo suggested. <wingo>well, the build is proceeding. tx for the suggestion a_e <mark_weaver>the time may come when we need to include gnutls in our bootstrap binaries <mark_weaver>since they are fixed-output derivations, where we already know the hash of the output, they don't need to be as carefully controlled. <mark_weaver>there's another area where this circularity bites us: currently, we can't use 'git-fetch' for any package that 'git' depends on. <bavier>sounds like something the linter could check for <sheeple>(use-package-modules...) is only working for some packages. <sheeple>It's working for xfce, emacs, and conkeror, but it doesn't work for htop or xmonad <sheeple>I get the error "no code for module (gnu packages <package name>)" <mark_weaver>sheeple: (gnu packages <package name>) is not right. it should be (gnu packages <module name>), where <module name> is the module that contains that package. <mark_weaver>hence the name 'use-package-modules' instead of 'use-packages' <mark_weaver>you can find out the module that contains a package with the command "guix package -A <package name>" <bavier>sheeple: or alternatively use 'specification->package' as outlined in 'Using the Configuration System' <davexunit>holy crap I built the Mesa vulkan branch finally. <sheeple>bavier: I don't see 'specification->package' anywhere <sheeple>What should I do to install xmonad globally? <bavier>sheeple: if you're an xmonad user, help would be appreciated in getting xmonad reconfiguration working. <lfam>I really don't know how to navigate the hydra web interface. Can anyone tell how far along the glibc rebuild is? <bavier>sheeple: 'mod-q' does not work at the moment, AFAIK <sheeple>I don't know much about xmonad but I'll try. <mark_weaver>it's about half way by number of packages, but of course most of those packages will not be important to you. <lfam>Right. I was just wondering. I actually rebuilt my locally, from git. <lfam>I figured I could rebuilt my small subset of the distribution relatively quickly. <mark_weaver>yeah, I'm currently running a minimal text-only system so I could get the glibc fixes sooner. <mark_weaver>but I'm now going to try to graduate back to xfce and see how much remains to be built <lfam>Are native-inputs downloaded when substituting? My understanding is that they are not but I'd like to be sure in an email to cbaines :) <mark_weaver>lfam: only runtime dependencies are downloaded when substituting. <mark_weaver>if a native-input becomes runtime dependency, then that probably indicates a problem <mark_weaver>runtime dependencies are found by scanning the outputs for /gnu/store/xxxxx references <lfam>Right, that was my understanding. And in the case of python packages, the references are in the python wrapper that sets PYTHONPATH, right? <mark_weaver>I guess so, but I'm not sufficiently familiar with our python packaging to say <mark_weaver>hydra has built enough of the glibc security update that it might be reasonable to apply it to master soon. <dmarinoj>How about an option for users like "guix stable-pull" that only gets security updates? <dmarinoj>So there can be a bleeding edge guix and a stable guix <NiAsterisk>dmarinoj: it has been proposed on the list before. idk where. <mark_weaver>dmarinoj: it would be good to have one or more stable branches at some point, but it would be a lot of work to maintain it. <mark_weaver>right now, we often resolve security issues by updating versions, but a stable branch should apply minimal patches to existing versions. <mark_weaver>so, it would more than double the workload of those of us who handle security updates