<dustyweb>there's a lot of conversation about guix npm importing <dustyweb>I guess I should have read that before the last Libre Lounge episode came out about npm things :) <dustyweb>swedebugia: thanks for your work on it :) <madage>why did you remove config.scm from Makefile.am on libgit2? <madage>OrangeShark: just to let you know that this breaks guix configure script <swedebugia>I sent the patches to Jullian/guix-devel a minute ago. <dustyweb>swedebugia: so is my understanding that the approach to the blacklist method is to say "ok we aren't going to bother fetching the trees of these packages" <dustyweb>in theory because a "simpler" solution to them can be provided? <swedebugia>dustyweb, exactly. It helps a lot but only for the devDependencies (devdeps). These are dependencies which are nice to have for the developer but VERY often not needed to build the package. <swedebugia>I even choose to block the testing dependencies until we have found a way forward. <dustyweb>swedebugia: we should mention this at the end of next Libre Lounge episode so people know that some things are being tried :) <dustyweb>swedebugia: mind if I crosspost your comments to the #librelounge channel? <swedebugia>Choosing earlier versions works for direct dependencies. Se the example with async in the guix-devel. <swedebugia>thanks for the link to librelounge. I downloaded it and will listen. <nckx>dustyweb: ‘conservnacy’ typo in the sho-notes, if you'd care ☺ <nckx>dustyweb: And Quebes (twice) → Qubes, I think. <dustyweb>nckx: I fixed it in git, will get pushed up whenever emacsen touches it next <dustyweb>feel free to join #librelounge if you have more comments too, though I don't mind getting them here :) <nckx>dustyweb: I'll give it a listen and will, thanks! ***jonsger1 is now known as jonsger
<fps>hmm, i will look at other distributed data stores, too, and see what is required to produce hacky binary caches for them, too ;) ***rekado_ is now known as rekado
<rekado>the new gnome-session / gnome-shell fails ***ng0_ is now known as ng0
<brendyyn>is test.support not in our python for somereason. I'm getting an error saying there is no module named support. is there a dependency I'm missiing? <lprndn>I've seen some activity on wip-gnome-upgrades yesterday. Does anyone know the current status? <ng0>brendyyn: seems to depend on which support module they mean. <ng0>I find 'support.py' in (not Guix): virt-manager, jython, gnat, python3.5, 3to2, alabaster, Babel, future, and so on <ng0>what are you working with that requires test.support? <brendyyn>I'm trying to enable tests for calibre after updating it <ng0>and calibre is using test.support? wow. <brendyyn>oh wait, i think it was python-regex actually, a dependency of calibre <ng0>if that's the core test.support, they are really relying on a good moving target <ng0>python discourages the use of it for anything but core developers. <ng0>yes, but most of the time you can't compare nix definitions directly to guix, there are differences. <ng0>where's the code problem? in callibre or in the dependency? <ng0>ah, that's the same package. <brendyyn>yes, but i updated it to 2018.11.22 first <brendyyn>updating fixes a calibre test, so it probably works, i just wanted to enable python-regex's tests too <brendyyn>ModuleNotFoundError: No module named 'test.support' <ng0>but they are unrelated. why fix more than necessary for calibre? update first, then fix the tests <mbakke>brendyyn: The test.support module is indeed missing from our Python 2 package. There is a FIXME in the package definition on the core-updates branch :/ <civodul>armhf builds are causing some congestion on berlin <baconicsynergy>I've had my fun with Parabola. It's a fantastic operating system, but nothing beats GuixSD. It's time I came back :) <baconicsynergy>I just checked out the packages list, and almost every package I needed is now available! All that's missing is GNU Ring and the Nextcloud client, but I'm sure Owncloud would work with my provider <efraim>civodul: is /dev/tty available in the build environment? <efraim>i was going to test sbcl on overdrive2 but I see berlin found it :) *roptat spent all day translating the manual <catonano>roptat: what language are you translating in ? <civodul>roptat: congrats, and a big thank you! <rekado>civodul: yes, wip-gnome-updates. <rekado>does anyone have hints about how to use gdb with our shell wrappers? <rekado>it’s tedious to copy the “export” lines from the wrapper scripts <efraim>W: Failure trying to run: /gnu/store/63gkgnixg6xj3m9cgl25ib2zxl51ngw0-coreutils-8.29/bin/chroot "/home/efraim/workspace/debian_amd64_sid" /bin/true <civodul>rekado: you could "gdb --args /bin/sh /path/to/wrapper" <civodul>and then "set follow-fork-mode child" <efraim>civodul: looks like you caught it as it went down, it was up 5 minutes ago when I couldn't ping it <civodul>yeah i've been watching cuirass logs :-) <civodul>that's a sane activity for a Saturday evening ;-) <efraim>i've been trying to get debootstrap to work sanely <efraim>patch a lot and it nearly works, but then chrooting it can't find /gnu/store/anything <efraim>I have a note about adding --foreign and chrooting and running debootstrap --second-stage but I wanted to get it to run all in one go <efraim>currently I'm trying EDITOR="" sudo -E debootstrap --arch=amd64 --extractor=ar --foreign stable ~/debian_amd64_stable <rekado>civodul: thanks, I’ll add that to my notes! <efraim>it would amuse me to use guix packages of debian packages to create a debian chroot to build debian packages <efraim>PATH=/bin:/sbin:/usr/bin:/usr/sbin sh debootstrap/debootstrap --second-stage <rekado>hmm, I’ll just upgrade to the newer version of GNOME now :-/ <rekado>I don’t see there’s much of a point trying to fix a now outdated version. <civodul>efraim: that could be the beginning of "guix pack -f deb"... <efraim>i was going to do a slack package first, repack /gnu/store/prefix to /usr <efraim>pbuilder can hook into debootstrap to build debian packages, but it's easier if debootstrap doesn't need manual intervention <lprndn>rekado: I've seen you'r working on updating gnome to the last version? <rekado>I’ve previously upgraded it to 3.28; now I’m going to 3.30 <lprndn->Ok nice! Thank you for your work. Just in case, before the recent activity on wip-gnome-upgrades, I was trying to update directly to 3.30. <rekado>wip-gnome-upgrades is already a few months old, actually <rekado>I only rebased it on top of core-updates. <rekado>(and fixed a few minor problems) <rekado>unfortunately, I found that gnome-shell at version 3.28 segfaults on my machine. <rekado>I don’t know why and I’m upgrading to 3.30 to see if that’s still the case. <lprndn->Yeah thats what I learnt looking at the branch and what I was invastigating. I didn't finish but with my little knowledge and with your previous work, the update seem to be quite smooth. <lprndn->I took a few notes, maybe you it might interest you? <rekado>lprndn-: sure, I’d be interested in your notes <rekado>I’m currently looking into test failures of NetworkManager <civodul>"New French PO file for 'guix-manual' (version 0.16.0.1)" <lprndn->rekado: Yeah, I didn't go further than you on network-manager. I shamelessly used your patch. Hum and looking back at what I did, it's mostly versions bump, switching to meson-build-system and adding or removing a few dependencies. <lprndn->Up until gnome-control-center which has troubles with something related to panels@colors. My guess for now is to update colord. <lprndn->and I think we need to build vala > 0.40 . 0.42.3 builds except a test in valadocs.