<arianvp>that would be a nice tradeoff between security and control <arianvp>instead of patch-by-default-behind-the-scenes <NiAsterisk>after/before running guix package -u / -i or any operation, display messages which can be selected to read <NiAsterisk>which will show "hey, package xy has security issue, update" <lfam>Can someone do me a favor and try to build qemu-minimal from current HEAD on x86_64? It's reproducibly failing on my machine. <NiAsterisk>this should still work, right? git://git.sv.gnu.org/guix.git git fetch is not really doing anything on any branch for me <lfam>NiAsterisk: Works for me. Are you sure it's not fetching updates <Jookia>lfam: I'll be doing that today, but someone will probably beat me to it <lfam>If we can't build QEMU we can't make disk images <Jookia>NiAsterisk: Did you change the commit hash if it's alraedy downloaded <Jookia>lfam: I'm building the first GCC :P So a long day ahead of building base packages <Jookia>lfam: Yep, so if nobody's fixed it or found your issue in 6-8 hours I'll have a looksee <lfam>Weird, it just succeeded after several failures <NiAsterisk>cmake complained about: CMake Error: The source directory "/tmp/guix-build-panopticon-0.13.0.drv-0/panopticon-0.13.0" does not appear to contain CMakeLists.txt. but, the repo and 0.13.0.tar.gz contains a CMakeList.txt in the folder "doc". I think I can instruct cmake to use CMakeList.txt in that folder? <lfam>NiAsterisk: Did you try grepping for something like 'CMakeList' in gnu/packages? Maybe case insensitively? <Jookia>Will the cmakelists in 'doc' build panopticon <NiAsterisk>no, that seems to be something with documentation <lfam>I wanted to try packaging the GNOME Maps application. Instead I'm debugging a QEMU / GuixSD problem. How does this happen? ;P <Jookia>Time for someone to write a cargo2guix thing? <Jookia>Maybe there's already one for Nix <NiAsterisk>i mean it's not long, the Cargo.toml of panopticon <NiAsterisk>but having the option for cargo imports would be okay <NiAsterisk>i don't even know rust.. and looking at the 3 nix packages for rust in system is not easy if you don't know rust. <lfam>We should probably get a rust build system first <NiAsterisk>if someone knows rust, that would be cool.. otherwise I'll look into it because I have to <lfam>I've never used it. Sounds promising though! <lfam>Also exciting for Go in Guix. I think we're almost there <NiAsterisk>it(panopticon) also needs kyotoarchives. I did send a patch for it, but I have no clue if it actually works, because I'm not a db person. tests succeeded. <lfam>I'm never sure how to handle those patches <lfam>I guess if the test suite is good, it should work <lfam>Sometimes the test suite is like, just checking if the binary is executable <NiAsterisk>there are tests included to check.. i can run those afterwards manually local, but no idea how (or if at all) this should be done for guix. <lfam>You can add a phase to the build process that runs the tests in a similar way to how you'd run them outside of Guix <NiAsterisk>okay, then I'll add a comment to the patch tomorrow, and send in a patch with the added tests later <NiAsterisk>well. okay htat's a 1 minute thing, I'll do the message now and go to sleep. <lfam>Tempted to reformat / as btrfs to get the COW speedup on the store when generating QEMU images <lfam>Several minutes of copying files for each image <lfam>I realized that generating a vm-image with the Guix tools leaves the disk label empty <lfam>I'm not sure it's possible to create a vm-image system and have the disks set up properly at first boot with our current tools <lfam>And at some point it happened that instead of rebooting, the vm-image just hangs after "Unregister pv shared memory for cpu 0", using 100% of a (real) CPU core <xd1le>how can i specify a dependency but with a different version number than the one in guix? <paroneayea>newest python-unittest2 depends on python-traceback2 which depends on python-linecache2 which depends on python-unittest2 :( <xd1le>yeah how is that even possible <Jookia>Maybe they're not required for building, just runtime? <mark_weaver>paroneayea: are any of those dependencies optional, or only needed for tests? <paroneayea>mark_weaver: it looks like unittest2 might only be needed by traceback2 for tests <xd1le>mark_weaver: no i was trying to see what needs to be done to update pandoc <xd1le>and there are some updates needed to some other ghc packages <xd1le>but not sure if *other* packages depend on those versions of those ghc packages... <paroneayea>I can't figure out how to stop the cycle from stopping :( <paroneayea>"luckily", I can probably avoid needing the latest unittest2 if I disable tests on this other package :P <paroneayea>and for now, I'm going to do that, because screw this. <Jookia>Are circular dependencies bugs? What about bootstrapping? <Jookia>I suppose it's not worth providing bootstrapping binaries for python-unittest2 <lfam>You could bootstrap with older versions <lfam>You don't necessarily need to use binares <lfam>paroneayea: Thanks for filing bugs. I'm interested in what kind of response they get <mark_weaver>paroneayea: poppler and cairo also depend on each other. to see how we deal with it, look at the 'cairo' input to poppler. <paroneayea>for now I just want to make sure all tests pass in mediagoblin :) <paroneayea>so I found 2 more dependencies that were missing <mark_weaver>we have several cases of circular dependencies like this. another example is glibc and bash <paroneayea>didn't realize this was going to be a late night battle! <paroneayea>Stealing a joke from Kenan Bölükbaşı: what do you call a dependency cycle in Python? <Jookia>mark_weaver: I don't quite understand the poppler/cairo example- does it build another cairo package with no poppler input? <Jookia>If cairo requires poppler, won't that fail when it tries to build <paroneayea>I told myself, I'm going to leave at a reasonable time tonight... :) <Jookia>I'm so close to my Guix GRUB patches for the past few days <mark_weaver>Jookia: the input to poppler is a variant of cairo that didn't include poppler as an input. <mark_weaver>so what happens is this: two different cairo packages are built: first one is built without poppler, then poppler is built using that first cairo, and then the final cairo is built based on that poppler. <xd1le>is there a naming convention for development/git versions of packages? <xd1le>like i'm thinking just doing appending -git would be appropriate but not sure if there are gotchas <Jookia>why do i compile everything from source <Jookia>why did i pick up this bad habit from when i had to <lfam>xd11e: Yes, see section 7.6.3 Version Numbers of the current version of the manual (in the git repo) <xd1le>lfam: ah i see thank you. is the official documentation not updated to the latest git version? <xd1le>oh i suppose the official documentation is for the latest version (0.9.0) <lfam>xd1le: No, it refers to the latest release, 0.9.0. There is some discussion on the bug tracker about have an up-to-date manual online too <xd1le>oh yeah i remember seeing smoe recent discussion about that <xd1le>so should the revision number start at 0 or 1? <xd1le>i don't think it matters ofc <lfam>xd1le: I don't think it's been decided how to index the Guix revisions <lfam>Precedent says they start at 1: see commit e932d371e5ab4 <efraim>just realized we lost oxygen-icons, that'll break my local build of quassel <lfam>You mean it stopped building successfully? <efraim>it uses oxygen-icons from kde.scm <lfam>That's annoying. At least it's not *too* hard to keep the file around locally, right? <efraim>it didn't have any inputs so it'll be easy <lfam>I didn't realize we totally dropped KDE. Did we have a working DE? <efraim>there were just a couple of modules, mostly from kde-4 <lfam>You'll re-add oxygen-icons in another module then? <lfam>It looks like telepathy-logger is broken on x86_64 and i686, but if you disable parallel testing, it builds. <lfam>I can't test that it fixes the build on i686. My internet is down and I'm tethering through my phone, and downloading all the i686 stuff will use up my data plan :/ <lfam>I guess I'll send the patch and others can test it <xd1le>anyone have a recipe for vim with features=huge, or knows how to do it? <arianvp>Does anybody know a tiling WM configurable in guile? <taylan>arianvp: guile-wm is a thing, but AFAIK it's more of a WM framework than a works-by-default WM <xd1le>sneek: later tell lfma thanks i will start with 1 index too then <roelj>How is the new build farm/server coming along? <rekado>roelj: we decided on the details of a configuration and have an offer but there's a delay due to issues with SATA initialisation on the board. As soon as these issues have been solved by the supplier we can make the order. <roelj>rekado: Ok. Thanks for the info :) <roelj>Are you going to place one server (only)? <arianvp>About the discussion about the glibc CVE yesterday <arianvp>It seems like guix makes dynamic libs act like static libs right? <arianvp>would there be a way to still have global dynamic libraries while keeping the guix properties? <rekado>arianvp: I think you can still use LD_PRELOAD or similar. <a_e>efraim: Sorry for the oxygen icons! <a_e>They do not need qt-4, so you can simply add them again. <efraim>its ok, I had my chance to speak up :) <efraim>i'm holding them locally until I get some of the other inputs for quassel ready <a_e>There is a slightly newer version 4.14.3 than the 4.14.2 I removed. <a_e>And there is the KDE 5 version: <a_e>Could you use these? <a_e>I started packaging KDE and then lost interest since I wished to move to my Novena, which is not powerful enough. <a_e>So if anyone wants to pick up from where I left, they are very welcome. <efraim>i haven't tried it yet, but i'll try out the kde-5 one <efraim>and being in kde-frameworks it's a shoe-in to kde-frameworks.scm <iyzsong>how about remane kde-frameworks.scm to kde.scm? <efraim>from download.kde.org there's frameworks and there's other folders <efraim>so I'm looking at it like gtk and gnome <iyzsong>yeah, get it, kde-frameworks is aiming to be used for non-KDE things too. <a_e>iyzsong: I think "frameworks" are the libraries. Then there is also "plasma" for the desktop environment around it. And probably more. They adopted a rather confusing naming scheme some time ago. <a_e>I was using the gentoo page for explaining the order of packaging: leave libraries, libraries of level 1 having leave libraries as input, and so on. <a_e>"leaf libraries", not "leave them alone libraries":-) <iyzsong>yes, I think that's the intention of the KDE upstream too. but KDE things is used to seem have more integration than GNOME things. now they changed :-) <efraim>I think it came about near their 5.0 or 5.1 <iyzsong>efraim: do you think we can merge wip-gstreamer and wip-pulseaudio now? <iyzsong>s/do you/how about/ I'd like to merge them. <efraim>if they build, I haven't looked at them for more than a week <iyzsong>well, I'm so slow to hydra. wanting the new one! <iyzsong>ah, they are all in the 'media-updates' branch with xorg updates, I guess it's more safe to rely on wingo. <a_e>iyzsong: Actually I deleted the wip- branches when I saw that Mark Weaver had united them all in one media update branch. <a_e>It would be nice to build one commit after the other to determine what breaks, but with the lack of power of hydra we just cannot afford it. <efraim>when I was doing it locally I built gstreamer, gst-libav, gst-plugins-good/ugly and mpv as a sample of the packages affected <a_e>I need to leave now, talk to you later! <phant0mas>hey guys can you pull changes from savannah? or is it just me? <phant0mas>fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. <efraim>it hasn't been working for me for the last 15-20 minutes or so <NiAsterisk>although i have pinentry-program /home/niasterisk/.guix-profile/bin/pinentry-curses in my gpg-agent.conf and a ttl <NiAsterisk>do I still need to set the $GPG_AGENT_INFO ? I had this on an old system <NiAsterisk>gra. this is one of the reasons why I don't recommend gpg to people. now it worked. ***nckx|offline is now known as nckx
***nckx is now known as nckx|offline
<rekado>cannot download ruby substitute from hydra :-( Aborts with an error about a corrupted archive. <rekado>can't wait for the new hydra to be ready ***kelsoo1 is now known as kelsoo
<mark_weaver>rekado: do you have the exact URI of the corrupted NAR? <mark_weaver>the hydra-server processes get bloated and need to be killed periodically, but when I kill them, if they were in the middle of serving a NAR, a truncated NAR ends up in the nginx cache :-( <rekado>it looks like it may have been an aborted network connection, though. <rekado>at various times I downloaded between 8.5 and 8.6MB before it was aborted. ***kelsoo1 is now known as kelsoo
<paroneayea>texlive-texmf wants to take up All The Space (TM) <paroneayea>davexunit: I finally looked into what this wheels stuff is in Python that people are talking about "replacing eggs" <paroneayea>moving from source dists to binary distribution :( <bavier>but it says pyc files are created as part of installation? <bavier>or is it the C extensions that are binary distributed? <paroneayea>I think they're binary distributed but I'm not sure <paroneayea>> Python needs a package format that is easier to install than sdist. Python's sdist packages are defined by and require the distutils and setuptools build systems, running arbitrary code to build-and-install, and re-compile, code just so it can be installed into a new virtualenv. This system of conflating build-install is slow, hard to maintain, and hinders innovation in both build systems and installers. <paroneayea>> Wheel attempts to remedy these problems by providing a simpler interface between the build system and the installer. The wheel binary package format frees installers from having to know about the build system, saves time by amortizing compile time over many installations, and removes the need to install a build system in the target environment. <bavier>I wonder what a package checkoff list for guix would look like <bavier>might be difficult to get the popularity list <detrout>paroneayea: Debian decided to not use wheels. I suspect wheels are more for Windows / OS X which are frequent lacking compilers <detrout>E.g. trying to install scipy on os x is painful as you have to dig up a fortran compiler <detrout>and windows is even worse as its hard to even get a C compiler <detrout>maybe they intend to mean that wheels are the new binary distribution format replacing eggs. <paroneayea>yeah maybe... I thought eggs was a pretty wide ranging term across sdists and bdists but maybe I'm wrong? <detrout>eggs were more binary like. in as much sense as that makes for python <detrout>So I poked a bit around pypi, bokeh doesn't have a wheel file just tar.gz/zip. numpy on the other hand has 4 wheels in addition to the source archives <detrout>Is there a particular reason guix doesn't have node/npm packaged? (Something other than lack of time) <paroneayea>detrout: nobody has stepped up to do it, and it's hard <paroneayea>maybe I should stop posting that and discouraging people from even trying ;) <davexunit>everything on npmjs.org is essentially useless. <detrout>the debian package is at 1.x, and I was finding application that are demanding npm > 2 <davexunit>but making guix packages for things available on npm... <detrout>paroneayea: I'm well aware of the js nightmare. I've tried to work on ipython notebook and bokeh for debian <detrout>is guix still willing to be cheaters and accept human readable javascript as source? regardless of what sourcery made said javascript? <davexunit>the definition of source code in the GPL is good to reference when this comes up <detrout>The definition I heard from debian developers was "preferred form of modification" <davexunit>source code is the *preferred* form for reading and modification. things like minified javascript are not source code. <detrout>there's no one I consider minified javascript to be source. <detrout>the place I think its arguable is something like bokeh. <detrout>the pypi library contains a human readable copy of the js library <davexunit>now, say, concatenating a bunch of source files together so that you only need to include one JS file in the browser, that seems okay to me. <davexunit>it's still in form suitable for modification. <detrout>Debian wants it to be built from the dependencies... <detrout>which is admirable but a nightmare given javascript <paroneayea>it's postentially a little bit less of a nightmare in guix <paroneayea>because npm can have different versions of dependencies for each dependency up the tree <detrout>I believe so. as you can at least have multiple versions of a dependency installed with guix <davexunit>the culture that has developed around node has made this a tough problem <davexunit>dependency graphs are, frankly, out of fucking control. <detrout>i could imagine something like soname versioned js libraries on debian being theoretically doable <davexunit>people cut up their libraries so that you can import individual functions <davexunit>so that you only include what you need in your project <paroneayea>debian has made an admirable attempt to package pump.io but there's too much churn <detrout>Oh right... because unused functions add to your bandwidth costs... <paroneayea>I have a couple more packages to push, but all the same tests that were passing in virtualenv are passing using guix packages now :) <paroneayea>the last things to do are to package python-gst and to push the other packages I put together locally <paroneayea>we really gotta make the guix vision happen and be useable enough to be appealing to peoples' daily workflows <paroneayea>or else I don't know how we can turn the tide of all these disasterous unmanagable distribution mechanisms being put in place <paroneayea>there's so much temptation to roll your own, and badly <davexunit>yeah having mediagoblin working will be a big win. <davexunit>maybe with some caveats, but that's okay, because the caveats are bigger elsewhere. :) <paroneayea>maybe autotools would have made some of the same mistakes back in the early 90s, but there was no reliable general public access to the internet back then, so you couldn't just assume you could pull down the source on the fly :) <davexunit>someone on guile-user suggested that the guildhall should hook into the guile runtime to download modules on the fly <paroneayea>I thought Racket people were against side effects <detrout>javascript brought a blight upon the field of software engineering... <detrout>(fetching things on demand is a thing that seems normal if you started with JS) <detrout>Though there has been some discussion about fetching debugging symbols on demand <df_>not sure js invented it, it's common in java build systems <detrout>that'd be hard to say who came first since they developed around the same time... <davexunit>no concept of layers. everything is just mashed together. <davexunit>runtime rolled up with a package manager and build system <mark_weaver>rekado: thanks for the URL. I downloaded it and it seems to be a valid bzip2 archive, so I guess it was a network problem. <petter>just thought i'd forward the reply i got in #serveraptor when i asked about GuixSD: <petter>kwiat> petter: No, not yet. They don't provide bootable ISO and I don't have resources to prepare template with GuixSD. Sorry. :( ***_hubertus84_ is now known as _hubertus_
<_hubertus_>I've just successfully run guix app and try to build qemu file with guix system vm <mark_weaver>it needs the OS configuration, which is a text file that you write yourself. See section 7.2 of the Guix manual. <_hubertus_>is there any minimal configuration good enough to build vm image? <efraim>I think we're affected by the CVEs against libssh and libssh2 <efraim>and by think I mean debian stable has the same version of libssh and they've patched <mark_weaver>efraim: if you'd like to handle adding the patches to guix, I'd be grateful <efraim>i've started on libssh, libssh2 has >800 dependant packages <mark_weaver>efraim: we'll need to do the libssh2 update on another branch <mark_weaver>efraim: or at least to keep 'curl' on the unpatched version for now. <mark_weaver>hmm. curl is used by git. I wonder if 'git' ends up using libssh2 for the SSH connection when fetching from an ssh URL. <efraim>that's just about all of the affected packages <efraim>it seems kodi uses both libssh and libssh2 <efraim>in the dependancy graph at least <lfam>I just came here to ask about this <sneek>lfam, xd1le says: thanks i will start with 1 index too then <lfam>Maybe it depends on one of them via curl? <efraim>guile-ssh and kodi are the two dependants of libssh <mark_weaver>okay, I just checked, and git runs 'ssh' as a separate process, so it doesn't seem to use libssh2 <efraim>we also have a private copy of libssh-0.5 in ssh.scm <mark_weaver>it seems to be unused. we should probably just remove it. I wonder why it's still there. <lfam>I agree, I can't find a user for it <mark_weaver>ah, it used to be needed by guile-ssh, but no longer is <mark_weaver>our version of libssh2 is quite old. I wonder if we could update to the version they just released today. <efraim>we can probably also take out vte-0.36.5, everything that used it should've upgraded to the newer versions <lfam>I was gonna say we should ask whoever added it ;) <mark_weaver>efraim: the comment indicates that some terminal emulators might need it. if there are no known security holes in vte-0.36.5, then I guess I'd be reluctant to remove it yet. <efraim>I'm the one who stuck it in, I can check the other ones to see if they've updated <lfam>Is it possible to run tune2fs from the Guile REPL in GuixSD? <mark_weaver>but you could certainly run it from the USB installer <lfam>It's just a VM, I'm gonna let it go <lfam>I do think we recently broke something in our VM tools though. The QEMU images are being created with a filesystem label, meaning that if you don't set the label on first boot, you can't boot again <lfam>This wasn't an issue a few weeks ago <lfam>without* a filesystem label, sorry <lfam>Or some external tool changed somehow <mark_weaver>did we ever set the filesystem label when building a VM? <lfam>I guess it's possible that I don't remember doing it manually in the past <lfam>But I don't understand how it *would* work. <mark_weaver>or maybe we've been using device names directly instead of filesystem labels for VMs. <lfam>I've always just adapted the examples from the manual. They used to use disk labels, now they use UUIDs. <lfam>I'm going to but I want to understand it a little more first <efraim>gah from guile-ssh's github page, it needs libssh-0.6.{4,5} <efraim>it already failed one of the tests with libssh-0.7.3 <lfam>Maybe you should ask them about this issue <efraim>unfortunately I have to go to bed soon and won't be able to finish dealing with the CVEs before tomorrow sometime <lfam>efraim: I can create patches that update both versions of libssh remove libssh-0.5, and send them to the list. What do you think? <mark_weaver>efraim: okay, no worries, and thanks for working on it! <lfam>Or have you already done that, and now you are trying to figure out what breaks? <efraim>I have libssh updated locally and seeing how it breaks guile-ssh, haven't touched libssh2 yet <mark_weaver>I guess we should update the 'home-page' field of our libssh2 package as well. <lfam>Are you sure? They don't seem to offer each other's versions? <mark_weaver>but I guess we should try updating libssh2 to 0.7.3, add libssh2-0.6 for use by guile-ssh, and also temporarily keep a version of libssh2 identical to the current one (such that a rebuild is not needed) for use by curl until we can get hydra to do the 3000+ rebuilds needed for that. <lfam>mark_weaver: For libssh, I think we should update libssh to 0.7.3, and find the latest version of libssh that guile-ssh can use and create that. For libssh2, we should update it to 1.7.0, while keeping the old version to smooth out the transition. <lfam>I think that's similar to what you mean but there were some typos <lfam>mark_weaver: Are you doing that or do you want me to try it? Or should we split up the work? <mark_weaver>oh, I see, I got confused with the libssh and libssh2 version numbers <mark_weaver>lfam: your plan sounds good to me. if you'd like to take care of this, I'd be grateful! <lfam>Okay, when ready, I'll send the patches to the list with comments, for review <mark_weaver>lfam: temporarily, we'll need to avoid rebuilding 'curl', since that leads to 3000+ rebuilds. <davexunit>bah, there's a bug in 'guix environment' that is preventing me from using guile-next <davexunit>does 'guix environment --ad-hoc guile-next -- guile' fail for anyone else? <lfam>mark_weaver: Yes, I'll make sure that curl is still using the old version in my patch series <davexunit>it's because guile-next doesn't set the right search paths <davexunit>and there was some discussion around my patch that adds them <davexunit>so I made an environment that didn't have them. <lfam>libssh2 redirects to https <mark_weaver>lfam: is that a problem? does gnutls depend on libssh2? <lfam>mark_weaver: Not a problem yet but I haven't tried rebuilding gnutls yet <lfam>It seems fine, just another data point in the great HTTPS migration <mark_weaver>lfam: based on the name of the signature file, it's a signature of the uncompressed tar file. <lfam>Although I wonder if anyone has ever exploited a bug in the decompressor this way <lfam>Do you know the reasoning behind this practice? <mark_weaver>I'm not worried about it. if anything, this signature is closer to the source code that will be compiled. <lfam>Well, the signature is good on the uncompressed tarball <lfam>I guess signing the compressed tarball indicates some level of trust in the compressor / decompressor, and they can't control what is used to decompress. <mark_weaver>well, given that things like web pages are often compressed and transparently decompressed, we already need robust decompressors. <lfam>That would be a really crazy attack <lfam>Oh man, their download urls embed a integer for every file they serve, and it's not related to the version or anything I can see. Annoying <lfam>I guess to make things harder for crawlers? <lfam>Every file is in it's own directory from the user's point of view <lfam>We mirror all the sources AFAICT <mark_weaver>it's probably just an artifact of their web content management system <lfam>I actually have to make sure I'm downloading from upstream when doing stuff like this to make sure everything works as expected <paroneayea>I thought if a download uri went down guix couldn't access it anymore because we *didn't* have mirrors <mark_weaver>paroneayea: for anyone that has binary substitutes enabled, hydra acts as a mirror <paroneayea>mark_weaver: oh, I thought that was just for the substitutes <mark_weaver>upstream tarballs are served as substitutes, using the same mechanism as for the build outputs <lfam>guile-ssh doesn't build reliably. It seems non-deterministic in the test suite. Going to try disabling parallel testing <lfam>Or they are already not parallel <xd1le>so a window manager not a desktop environment like it has in the docs <lfam>Heh, good question. I'm wondering how to have my desired setup, too. Boot to console, optionally startx <xd1le>docs seems to suggest that X starts via startx and starts slim <xd1le>but not sure if there's a service or something to enable <xd1le>lfam: that's my desired setup too <xd1le>but apparently it's not possible <lfam>I would look at %desktop-services <lfam>It would be too bad if it's really impossible <xd1le>as in, not possible right now <xd1le>it isn't even possible on nixos btw 