IRC channel logs


back to list of logs

<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"
<NiAsterisk>or "stuff changed, do this"
<Jookia>guix cve?
<NiAsterisk>just for individual / system updates.
<davexunit>we have a cve checker
<davexunit>but it's not foolproof
<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 fetch is not really doing anything on any branch for me
<NiAsterisk>idk if savannah changed things
<NiAsterisk>nope, still there.
<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
<lfam>That will take a while
<NiAsterisk>possible, yes. thanks for the reminder.
<Jookia>lfam: Yep, so if nobody's fixed it or found your issue in 6-8 hours I'll have a looksee
<lfam>I'm going to bisect
<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?
<NiAsterisk>not yet. I only picked it up again now
<Jookia>Will the cmakelists in 'doc' build panopticon
<NiAsterisk>no, that seems to be something with documentation
<NiAsterisk>most of it
<NiAsterisk>check doc/CMakeLists.txt in
<lfam>I wanted to try packaging the GNOME Maps application. Instead I'm debugging a QEMU / GuixSD problem. How does this happen? ;P
<NiAsterisk>so the author of the software is wrong.
<lfam>That's always fun
<NiAsterisk>the build system now *is* cargo
<NiAsterisk>well, seu said "it should still work"
<NiAsterisk>the cargo file sources other git repos
<Jookia>Even better
<Jookia>Time for someone to write a cargo2guix thing?
<Jookia>Maybe there's already one for Nix
<NiAsterisk>there is
<NiAsterisk>which is why i thought about it earlier
<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.
<NiAsterisk>ACTION moves panopticon down in priority
<lfam>Yeah, that happens.
<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>all in one, not 2 patches
<lfam>Okay, sounds good
<NiAsterisk>well. okay htat's a 1 minute thing, I'll do the message now and go to sleep.
<NiAsterisk>g 'night
<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
<Jookia>Building Tar!
<lfam>Building the whole system, I often think about tar:
<lfam>Heh, I just stumbled across this:
<Jookia> Nice
<xd1le>ew containers
<xd1le>how can i specify a dependency but with a different version number than the one in guix?
<xd1le>ah i see i can just probably refer the differently numbered variable itself, i think:
<paroneayea>newest python-unittest2 depends on python-traceback2 which depends on python-linecache2 which depends on python-unittest2 :(
<Jookia>how do they even build that
<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?
<mark_weaver>xd1le: which package do you need an old version of?
<paroneayea>mark_weaver: it looks like unittest2 might only be needed by traceback2 for tests
<paroneayea>I'm going to try disabling it there.
<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...
<xd1le>if that makes sense..
<xd1le>er ghc-pandoc
<paroneayea>mark_weaver: sort of
<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.
<paroneayea>I filed bugs.
<Jookia>Are circular dependencies bugs? What about bootstrapping?
<paroneayea>we want to bootstrap as little as possible
<paroneayea>bootstrapping is always a pain in the neck...
<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>mark_weaver: kk
<paroneayea>for now I just want to make sure all tests pass in mediagoblin :)
<paroneayea>so I found 2 more dependencies that were missing
<paroneayea>filling that hole...
<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!
<mark_weaver>but that's probably a bit thornier
<paroneayea>Stealing a joke from Kenan Bölükbaşı: what do you call a dependency cycle in Python?
<mark_weaver>what do you call it?
<paroneayea>An ouroboros!
<mark_weaver>heh :)
<mark_weaver>(I confess I had to look up that word)
<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... :)
<paroneayea>but I keep thinking
<paroneayea>"I'm so close!"
<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.
<Jookia>Ah I see
<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.
<lfam>Has anyone tried to use GNOME in GuixSD, and gotten an error screen like this when trying to log in?
<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>i should have read that
<xd1le>will do so
<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?
<efraim>probably kde-frameworks.scm
<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
<arianvp>hmm that's fine. I'll have a look
<xd1le>sneek: later tell lfma thanks i will start with 1 index too then
<sneek>Got it.
<roelj>How is the new build farm/server coming along?
<efraim>sneek help
<efraim>sneek: later ask xd1le this is my WIP vim but I'm not happy with it yet
<sneek>Got it.
<efraim>sneek: botsnack
<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 there's frameworks and there's other folders
<iyzsong>I just prefer short words :-)
<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>okey, let me see :-)
<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.
<iyzsong>ok, thanks!
<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>when I try I get
<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
<phant0mas>great it's the fourth time this week
<NiAsterisk>hrmm. pinetry keeps failing on me
<NiAsterisk>although i have pinentry-program /home/niasterisk/.guix-profile/bin/pinentry-curses in my gpg-agent.conf and a ttl
<NiAsterisk>same for every 3 of the pinentry bins
<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>buliding from source now.
<rekado>can't wait for the new hydra to be ready
<bavier>I know we all love language package managers:
***kelsoo1 is now known as kelsoo
<mark_weaver>rekado: do you have the exact URI of the corrupted NAR?
<mark_weaver>if so, I can clear it from the cache
<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>mark_weaver: looks like it was
<rekado>yes, that's the one.
<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>my goodness
<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 :(
<davexunit>paroneayea: wonderful...
<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
<bavier>or maybe not:
<wingo> is my polkit bug, i find. they knew they broke pkexec some 6 months ago and haven't fixed it :(
<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
<paroneayea>detrout: thank you
<paroneayea>that's helpful
<paroneayea>but it also makes mse worried that advertises as if sdists are a thing of the past
<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>I think node *is* packaged?
<paroneayea>it's just everything else under node right?
<paroneayea>maybe I should stop posting that and discouraging people from even trying ;)
<davexunit>our node is really out of date.
<davexunit>everything on is essentially useless.
<davexunit>they are binaries, not source.
<detrout>i was afraid of that.
<detrout>the debian package is at 1.x, and I was finding application that are demanding npm > 2
<davexunit>we can update node itself easily enough
<davexunit>but no one has done it yet.
<davexunit>but making guix packages for things available on npm...
<davexunit>that's a rough one.
<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>because it's not source code.
<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>er no way
<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
<davexunit>we would want the same.
<paroneayea>detrout: yup
<paroneayea>same problem here
<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
<paroneayea>and guix can handle that, debian can't
<davexunit>the culture that has developed around node has made this a tough problem
<detrout>debian can't easily...
<davexunit>there are just *so many* packages
<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
<davexunit>it's insane.
<paroneayea>debian has made an admirable attempt to package but there's too much churn
<paroneayea>davexunit: btw, good news
<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
<davexunit>paroneayea: that's great news!
<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. :)
<davexunit>we can improve.
<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 :)
<paroneayea>or the binaries ;)
<davexunit>someone on guile-user suggested that the guildhall should hook into the guile runtime to download modules on the fly
<paroneayea>I saw that...
<paroneayea>I think that's what Racket does
<davexunit>a single tear rolled down my cheek
<paroneayea>which, egads!
<paroneayea>I thought Racket people were against side effects
<paroneayea>and now you just fetch modules on demand??
<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_
<mark_weaver>greetings, _hubertus_
<_hubertus_>I've just successfully run guix app and try to build qemu file with guix system vm
<_hubertus_>but I have a quastion
<_hubertus_>as a input guix system vm needs file
<_hubertus_>what kind of file? where is that file?
<_hubertus_>how to generate this file?
<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_>that's what I suspected
<_hubertus_>is there any minimal configuration good enough to build vm image?
<_hubertus_>maybe example from section 7.2 is enough?
<petter>you can find complete example files here,
<efraim>I couldn't find the online repo
<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
<_hubertus_>thanks petter
<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>ah, it's because curl depends on libssh2
<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, you have 1 message.
<sneek>lfam, xd1le says: thanks i will start with 1 index too then
<davexunit>efraim: interesting!
<davexunit>I didn't notice that when I packaged kodi.
<lfam>Maybe it depends on one of them via curl?
<efraim>curl uses libssh2
<davexunit>perhaps, yeah.
<davexunit>I know that it's not a problem at runtime
<efraim>guile-ssh and kodi are the two dependants of libssh
<davexunit>I use Kodi on my living room computer
<lfam>That's cool :) Dogfood
<efraim>I hear 16 is out
<mark_weaver>okay, I just checked, and git runs 'ssh' as a separate process, so it doesn't seem to use libssh2
<davexunit>efraim: oh really? I'll have to upgrade
<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.
<efraim>it dates back to early 2014
<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>we should remove it
<mark_weaver>our version of libssh2 is quite old. I wonder if we could update to the version they just released today.
<mark_weaver>version 1.7.0
<efraim>that was my plan for the CVE
<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>lfam: I'm not sure we include it in the initramfs
<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.
<mark_weaver>I really don't know, I almost never use VMs.
<lfam>I've always just adapted the examples from the manual. They used to use disk labels, now they use UUIDs.
<mark_weaver>feel free to mail about it though.
<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>The maintainer is spending time on guile-ssh today:
<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>huh, many of these versions that you've been talking about are not available here:
<mark_weaver>and says that the latest release is 0.7.0
<mark_weaver>I guess we should update the 'home-page' field of our libssh2 package as well.
<mark_weaver>looks like it should just be now, without the "2"
<efraim>there's two different projects
<lfam>Are you sure? They don't seem to offer each other's versions?
<lfam>That's to mark_weaver
<mark_weaver>no, I'm not sure.
<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.
<_hubertus_>my hirst handmade guixsd almost ready :)
<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
<lfam>Thanks for the reminder
<davexunit>nevermind, actually!
<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
<lfam>Another wrinkle
<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>cool :)
<lfam>mark_weaver: The libssh-0.7.3 tarball fails its signature check for me. Can you try it?
<lfam>Can anybody try checking the signature of libssh-0.7.3, as downloaded from <>?
<mark_weaver>lfam: based on the name of the signature file, it's a signature of the uncompressed tar file.
<lfam>Oh, duh
<mark_weaver>linux (the kernel) does the same thing
<lfam>Sorry for the noise
<mark_weaver>no worries :)
<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
<mark_weaver>thanks for your vigilance
<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>yeah, I see what you mean
<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
<paroneayea>lfam: whaat
<paroneayea>why would someone do that?
<lfam>I guess to make things harder for crawlers?
<lfam>I don't know
<paroneayea>maybe we should mirror it
<paroneayea>the tarball
<lfam>Every file is in it's own directory from the user's point of view
<lfam>We do!
<lfam>We mirror all the sources AFAICT
<paroneayea>wait, guix does?
<paroneayea>I thought it didn't
<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
<paroneayea>not the sources
<mark_weaver>upstream tarballs are served as substitutes, using the same mechanism as for the build outputs
<paroneayea>oh that's good to hear
<paroneayea>(though we don't long-term host it right?)
<lfam>guile-ssh doesn't build reliably. It seems non-deterministic in the test suite. Going to try disabling parallel testing
<xd1le>how do i start X?
<sneek>xd1le, you have 1 message.
<sneek>xd1le, efraim says: this is my WIP vim but I'm not happy with it yet
<lfam>Or they are already not parallel
<xd1le>e.g. i want to start xmonad
<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