IRC channel logs


back to list of logs

<lfam>sneek: later tell rekado: I successfully built that Guile derivation that's failing for you on x86_64
<sneek>Got it.
<fr33domlover>Does Xorg work in Guix when not using GuixSD?
<lfam>fr33domlover: What do you mean?
<lfam>Like, using Guix to install X on a foreign distro? I know some people use it like that
<fr33domlover>lfam, I installed xorg-server and xinit as my user (not root); when I run startx, I can en error about the X program not being found at a certain path
<fr33domlover>*I get an
<fr33domlover>startx looks for /gnu/store/somethinggggg-xinit-1.3.4/bin/X
<fr33domlover>but there is no such thing, xorg-server doesn't get installed to that dir
<lfam>Have you recently run `guix gc`?
<fr33domlover>lfam, i never ran it :P
<fr33domlover>but started using Guix just a ~week ago
<lfam>Okay, I guess that rules out <>
<lfam>fr33domlover: Does the bad path at least refer to the right store item? Like, is the hash right?
<fr33domlover>lfam, i didn't check the hash but that dir only as two executables, xinit and startx (as expected)
<fr33domlover>the X executabele probably comes from xorg-server, so why would it be under xinit's bin dir?
<fr33domlover>I don't really care much about fixing this, just curious
<fr33domlover>I want to move to GuixSD anyway
<fr33domlover>and then i imagine things will be a bit smoother
<lfam>It sounds like a packaging bug
<Apteryx>Suppose I boot from another install/live usb, would I be able to chroot into my GuixSD install and do things from there?
<Apteryx>I imagine I'd have to run a guix command to initialize all the environment variables correctly?
<lfam>I'm not sure, I've never tried that :)
<Apteryx>Also, I'm thinking moving from my 10 GB partition to a bigger one, what process would be advisable here? Tar backup of everything? Rsync? Something else?
<Apteryx>ACTION looks at the manual to see what kind of command would initialize the GUix system
<lfam>`guix system init`
<lfam>Not sure about migrating. LVM would be ideal but we don't support it yet
<Apteryx>lfam: But... doesn't this one "installs" stuff as well?
<lfam>Yes, it installs the system that you request
<Apteryx>lfam: OK. So if the /gnu/store already contains all the items it shouldn't take long?
<lfam>Right, if you request something that's already in the store, and you are using the same localstatedir (typically /var/guix), then you will re-use pre-existing items
<atw>is there a way to browse the source of an installed package?
<Apteryx>atw: I know there is guix download to download the tar or archive which was used to build the package
<lfam>atw, Apteryx: `guix build --source foo` will show you the path of the package's source code
<Apteryx>atw: Forget what I said about `guix download`. It looks like you have to manually give it an URL.
<Apteryx>lfam: Thanks! Didn't know that :). Will it just show the path, or also initiate a "build"?
<lfam>Well, it has to "build" the source in order to show the filesystem path. This could involve downloading and patching
<lfam>But the package itself will not be built
<Apteryx>lfam: I see! Nice!
<lfam>However, if you need some software to "build" the source, that software must also come from somewhere. So there's a chance that some other packages will be built or downloaded
<lfam>Like, maybe you need Git to get the source of some package that is distributed from a Git repo
<atw>lfam: makes sense. I was just wondering if there was an easier way than the standard visit project page and clone/download tarball
<atw>I mean, I guess guix will still help me if I do that and then guix environment
<Apteryx>Uh oh. "guix package: error: build failed: setting synchronous mode: unable to open database file". Did I do something wrong?
<Apteryx>My system really thinks it's out of memory, even getting message on the command line. But df -h reports 74% usage. How strange!
<Apteryx>Could hard links cause something like that?
<amz3>where do guix people publish their gpg key?
<amz3>Aptertyx, maybe you reached the max number of inode...
<rekado>Hi Guix
<sneek>Welcome back rekado, you have 1 message.
<sneek>rekado, lfam says: I successfully built that Guile derivation that's failing for you on x86_64
<rekado>sneek: later tell lfam Thanks for trying to build that Guile derivation. Maybe the test fails because the store is on NFS…?
<sneek>Will do.
<Sleep_Walker>it seems that I somehow diverged and my glib is being recompiled each time - can I somehow find why I diverged? what dependency is different from the one on hydra?
<efraim>are you on x86_64?
<Sleep_Walker>it wouldn't be that bad but glib compilation fails for me on test phase on timeout on 642026 test
<Sleep_Walker>I tried even 3 hours timeout with no difference
<Sleep_Walker>I'm not on GuixSD but on openSUSE
<Sleep_Walker>I want to prepare GuixSD from openSUSE through guix system init once again
<efraim>hmm, i'm not sure what could cause that
<Sleep_Walker>I didin't expect that you would
<Sleep_Walker>but maybe there is tool or way how to get the answer
<Sleep_Walker>I need 1] subtree of dependencies and 2] be able to say which hash is available on hydra
<Sleep_Walker>that should give me clue
<janneke>i would certainly like to have that feature: dependency x has changed from y to z
<rekado>Sleep_Walker: are you using Guix from git on openSUSE?
<Sleep_Walker>it's complicated
<Sleep_Walker>I have daemon from the release (installed as package), I'm running from git but I also run `guix pull'
<Sleep_Walker>so I'm not completely sure :)
<efraim>i switch my systemd daemon from exec'ing /gnu/store/...guix-0.11/bin/guix-daemon to /root/.guix-profile/bin/guix-daemon
<efraim>that way I can add `guix pull && guix package -u` to root's cron
<rekado>ACTION still compiles gcj in an arm VM
<efraim> debian has a patch for armhf gcj-4.9.2, if you think that might help
***Digitteknohippie is now known as Digit
<marusich>texlive is so big
<marusich>I wonder why.
***dootniz is now known as kragniz
<rekado>marusich: it’s because it includes *all* TeX packages on CTAN.
<rekado>marusich: apparently it’s hard to split this up and install to separate directories without breaking it.
<marusich>I see. Well, it's not too bad. Takes less time to download than to build some things :)
<efraim>i think i need to hit binutils for my symbol redirection thing, I've been staring at gcc and glibc and nothing's popping out at me
<Sleep_Walker>I'm dirty cheater
<Sleep_Walker>I altered source code of the test under the hands of build daemon
<Sleep_Walker>so I finally passed glib build \\o/ (and haven't altered hash)
<rekado>nasty :)
<efraim>if i'm right this time, then my symbol redirection problem would've been solved if i was working against core-updates like i'm supposed to, since it has a more recent binutils
<bavier1>does anyone know what might cause "assertion 'GDK_IS_PIXBUF (pixbuf)' failed"?
<ng0>this icecat is very unstable.. nothing I ever used has crashed so often in one month
<Apteryx>Wooh. Migrated from my small 10 GB to a 30 GB partition using rsync.
<Apteryx>I didn't figure how to chroot into Guix (being mounted at /mnt/guix made the symlinks/hardlinks point to the wrong absolute locations).
<lfam>Good old rsync
<sneek>Welcome back lfam, you have 1 message.
<sneek>lfam, rekado says: Thanks for trying to build that Guile derivation. Maybe the test fails because the store is on NFS…?
<Apteryx>Since I had only changed partition and label name I could pause grub, edit the boot parameters (basically just change from my old partition label to the new one), and it worked!
<lfam>sneek: later tell rekado: I actually built it on btrfs and then installed it onto ext4. Heh, maybe you *can* blame it all on NFS ;)
<lfam>Apteryx: Tricky maneuver :)
<lfam>ng0: I've heard that complaint from several other people. I wonder why it's crashing...
<Apteryx>Yes, I'm glad I didn't enable luks encryption. Was tempted too, but this would have made things more complicated.
<ng0>lfam: maybe it's just that firefox revision
<lfam>GuixSD needs an LVM / LUKS champion
<lfam>ng0: Maybe... but I wonder what's going wrong? Is the crash some remotely exploitable bug?
<ng0>bugzilla of mozilla would know
<lfam>Another maybe... I get the sense that Mozilla is nursing their core bugs from the early days... No time to nurture new bugs
<lfam>I see open bugs from more than 10 years ago on their bugzilla. Bugs that I found because I'm still suffering from them
<Apteryx>If I run "guix system reconfigure", will my user profile be preserved? Or I will need to re-install (re-link) the packages I had manually installed there?
<lfam>Apteryx: It won't effect your user profile at all
<Apteryx>lfam: OK, nice :)
<lfam>Except in the sense that packages from your user profile might be interacting with some "system packages", so it's possible to see different behavior
<lfam>For example, if one of your packages depends on some kernel feature that changes
<Apteryx>I see. No big deal.
<lfam>I can't predict the size of the deal. In practice, it's a big improvement over the old-school "mutate /usr" method
<lfam>Plus you can rollback if something goes wrong
<Apteryx>In that sense it's quite a big deal!
<lfam>Heh ;)
<lfam>Agreed, it's why I was inspired to get involved
<Apteryx>So I'll update my partition information in my /etc/config.scm and run "guix system reconfigure". This should update my grub on disk, rigth?
<Apteryx>lfam: Thanks for helping making this a reality!
<lfam>I got involved well after it was already a reality. Now we polish and grow :)
<Apteryx>OK :)
<ng0>imagine you are in the middle of an update and power goes out. won't even bother the system update, just start again
<Apteryx>I'm attracted to GNU Hurd recently. I'd like to start working on it shortly. It will be a great companion to Guix.
<lfam>Right, update the bootloader (and possibly the file-systems) section of your configuration and then reconfigure. Make sure it's right... GRUB is how we achieve system rollback so things will be difficult if it breaks
<lfam>ng0: And you might even have some of the updated packages still cached in /gnu/store!
<ng0>Apteryx: actually hurd is being worked on
<Apteryx>ng0: I know, they are quite active in Debian Hurd for example.
<ng0>i mean for guix
<Apteryx>ng0: OK :)
<Apteryx>I saw guix was already Hurd compatible.
<ng0>if it is, this is very recent. I did not read the last updates manolis(?) gave
<lfam>phant0mas is the person to ask :)
<phant0mas>Hello Apteryx :-)
<phant0mas>it's work in progress
<Apteryx>ng0: There's a page on Phoronix, see "GNU Guix Package Manager Ported to GNU Hurd"
<Apteryx>phant0mas: Hi! :)
<phant0mas>Apteryx: yes we can cross-build packages for the Hurd and we can build packages on the Hurd
<phant0mas>but because of ongoing work on both projects, things tend to break now and then
<ng0>Apteryx: i don't read phoronix. i saw the last emails on our mailinglist, that's all
<lfam>We need some Hurd system tests in our test suite :)
<phant0mas>I am trying my best to make everthing work
<phant0mas>and there are some hacks included in order to make it work nicely:-(
<Apteryx>phant0mas: OK :) Seems challenging.
<phant0mas>for example with the latest hurdish glibc, the cross-toolchain broke again
<phant0mas>I can help you setup guix on debian/hurd if you are interested but prepare to get your hands dirty :-)
<Apteryx>phant0mas: OK. I just recently moved over to Guix so I'll still need some days to set my system up, but I'll ping you when I'm there!
<Apteryx>I had already boot a recent image of Debian Hurd with Qemu, so that part should be easy at least.
<phant0mas>yes this should be easy, and the latest versions of Debian Hurd are the most stable in ages!
<phant0mas>the Hurd developers are doing an awesome job on improving the system
<phant0mas>Apteryx: ping me when you are ready to join the dark side :-)
<Apteryx>phant0mas: I will! :)
<Apteryx>Have to head to work for now... later, guix!
<lfam>I wonder if we should try packaging tcc from the Git repo. They haven't released in 3 years but development is very active
<lfam>Hm, building HEAD of the development "mob" branch, it fails almost immediately due to conflicting type definitions
<ng0>i have a branch with this but ran into problems
<ng0>so, yes I agree we should
<lfam>Does it work for you?
<ng0>or at least package it, and preserve the old one, keep two versions around
<ng0>"ran into problems" so no, been a while since I tried :)
<ng0>I think I didn't use the mob branch though
<ng0>i mean, mob is a branch on the very active repo
<ng0>i used the stable head i think.. or
<lfam>Oh, what branch did you use?
<ng0>i should search for it
<ng0>just head
<ng0>last I tried was
<ng0>(commit "c948732efaf823f36d05608fe716bfcc4a98b70c"))
<lfam>That's on the "mob" branch
<ng0>I called it tcc-next and inherited tcc
<ng0>ah, ok
<lfam>I guess that somebody will work on the tcc package if they care about it. I read the mailing list for a while and it seems chaotic
<ng0>yep.. I didn't fix this up because it's one of those packages I do not care about, one of the community-service packages I have
<ng0>i hope mob gets back into stable at some point, used to happen before
<efraim>yay django :/
<lfam>efraim: Marius sent an update to the list. We could apply it ourselves if you feel impatient :)
<lfam>No harm in applying it, I think. I'll do it now
<efraim>i've been staring at my other screen all day, trying to get aarch64 working :)
<lfam>Keep working on that :)
<efraim>LFS doesn't seem so scary anymore, and I find myself yelling at debian patches more than I should
<lfam>efraim: I pushed the django update
<janneke>python for president!
<janneke>that must have been a lot of work...
<lfam>janneke: What do you mean? :)
<lfam>I *have* thought about rotating the Monty Python cast through the American presidency...
<janneke>i guess i'm just showing my history of 10+ years eloving+pushing python and losing interest in python, moving to guile
<lfam>Everything is a lot of work, right? Otherwise you are just standing on some giant's shoulders :)
<ng0>I wished the sample editor included in milkytracker was anything like renoise one
<bavier1>no help from handbrake developers
<bavier1>not interested in helping with a "beta toy"
<davexunit>bavier1: they said that about guix?
<bavier1>davexunit: amongst other things
<davexunit>bavier1: they said other mean things?
<paroneayea>hello all
<paroneayea>so, guixsd hosting
<davexunit>here's the log
<paroneayea>anyone running guixsd on some VPS hoster yet?
<janneke>guixsd hosting, yay!
<janneke>paroneayea: not yet...
<paroneayea>trying to figure out where to try hosting an image that I build here from first
<bavier1>davexunit: yup, that.
<bavier1>not terrible, but clear that they don't appreciate anyone wanting to play with their software internals
<davexunit>yeah not at all
<bavier1>I approached this package wanting to help clean some things, but now I'm a bit shaken up actually
<paroneayea>sorry bavier1
<paroneayea>bavier1: that was a pretty rude response from that person, disappointing
<rekado>:( very mean
<sneek>rekado, you have 1 message.
<sneek>rekado, lfam says: I actually built it on btrfs and then installed it onto ext4. Heh, maybe you *can* blame it all on NFS ;)
<bavier1>paroneayea: thanks
<rekado>I always forget that many free software projects are really hostile
<paroneayea>I guess I ought to be looking at something openstack based still, probably
<janneke>mark_weaver: as you reviewed my mingw v9 patch series and had significant input that lead to v10, i assume you are the most probable suspect to apply them
<paroneayea>probably the best way to be able to generate an image that can be used.
<janneke>mark_weaver: i try to be patient and respect the fact you're terribly busy...but it's been a while (8 weeks?) and i'm getting a bit anxious
<ng0>bavier1: wow..
<ng0>handbrake sounds like your average, sad community.
<davexunit>I got kicked from #handbrake
<davexunit>no one there liked my presence
<ng0>yeah I've read their log
<davexunit>I asked j45 not to disparage people and to be more welcoming, they insisted that calling someone's project a "toy" and not "real" weren't insulting, and everyone agreed.
<davexunit>I don't think we'll get any handbrake devs using guixsd any time soon, sorry.
<bavier1>davexunit: thanks for the support
<davexunit>I've very well burnt that bridge, but I'm just sick of this being the norm in free software.
<efraim>it finally clicked with me that gcc-boot0 shouldn't try to call /gnu/store/eeeeeeeeeeeeeeeeeeee/bin/bash when checking for egrep
<efraim>thats what i've been saying every time it goes by the screen
<ng0>davexunit: no loss..
<ng0>thanks for trying :)
<efraim>it looks like gcc checks for grep and for egrep
<rekado>davexunit: gah, what the … I know I won’t be using handbrake. What a terrible developer community.
<davexunit>yeah, they are awful.
<efraim>are we covered against the tar CVE?
<davexunit>"so if you want to keep fucking around with it, j45 isn't gonna keep helping you."
<davexunit>not hostile at all!
<davexunit>"i suggest you use a *real* *stable* linux distro instead of this Guix "beta" toy"
<davexunit>not hostile at all!
<rekado>I’m having a problem building GNU pascal (WIP). It’s a boring “permission denied” error but I can’t seem to reproduce it in an environment.
<davexunit>rekado: is it reproducible when that environment is in a container?
<rekado>make[4]: Entering directory '/tmp/guix-build-gnu-pascal-4.3.5-1.c0231319f.drv-0/gcc-4.3.5/gcc/p/rts'
<rekado>m4 ./make-acconfig-h.m4 "" > acconfig.h || { rm -f acconfig.h; false; }
<rekado>echo '[fortran]' >> tmp-gi.list
<rekado>/gnu/store/ykzwykkvr2c80rw4l1qh3mvfdkl7jibi-bash-4.3.42/bin/bash: acconfig.h: Permission denied
<rekado>I haven’t tried a container yet.
<bavier1>yeah, I'm torn between dropping the handbrake patch or making it work despite it all
<rekado>when I run that m4 command in the specified directory on the remains of “guix build -K” I get no error.
<ng0>bavier1: sooner or later we come to realize how all other distros happen to carry around aptches which never made it upstream.. I don't know what the problem with handbrake here is right now, buit I think patches are okay.
<bavier1>ng0: indeed
<lfam>So, besides trouble with Hydra itself, is there anything left to do for this core-updates cycle? Does anyone care about the remaining failures?
<rekado>there are failures for ardour and mod-host relating to fftwf
<rekado>I don’t know why they fail
<rekado>they cannot find a library that should be provided by fftwf
<rekado>I cannot take a look at this right now, but I’ll try to debug this soon.
<rekado>but I don’t think we should delay merging core-updates for this
<lfam>rekado: Does the problem persist when you revert the recent fftw update?
<lfam>Or is fftw not the same thing...
<rekado>fftwf inherits from fftw IIRC
<lfam>It would be great to release with all of our big graphical applications working but I agree that it shouldn't block it if everything else is ready
<lfam>Maybe we should try applying the dozens of QEMU bug fix patches that have accumulated, too.
<lfam>Especially since we use QEMU to build the release
<lfam>I wonder if anyone else has tried upgrading their systems to core-updates? Seems like a good way to get motivated to fix things :)
<rekado>I can’t. No space :(
<rekado>2GB left
<lfam>Common problem :)
<ng0>i can't, no time :/
<lfam>It would have caught that annoying glibc locale issue that we released 0.11.0 with...
<rekado>I really need to take time to back up everything, repartition and then reinstall.
<lfam>That issue actually led me to run my GuixSD system with a different glibc since 0.11.0.
<lfam>Looking forward to using substitutes again
<ng0>otoh, what could go wrong.. I'll boot the test computer which already runs from git
<rekado>ironic that using LLVM on this machine turned out to be so inflexible
<lfam>What do you mean?
<rekado>I’ll copy my stuff to an external disk tonight and try to reinstall tomorrow.
<rekado>bleh, I meant LVM :)
<ng0>i'll take a break from wathcing movies & cutting beats, and build the system from core-updates
<lfam>rekado: Ah... that *is* ironic! Not what I would have expected
<lfam>Thanks ng0! Almost everything has substitutes at this point. I'm just hoping to motivate people to fix the last remaining failing leaf applications.
<efraim>i tested that everything I have installed builds on core-updates ;)
<lfam>Yay, thanks :)
<lfam>I recommend `guix package -u .` :)
<lfam>I've been running all my Guix and GuixSD installations on it for a few days now. Seems fine so far!
<lfam>Ah, the recent cups-minimal update requires many rebuilds
<lfam>I started a new evaluation
<efraim>I always loved bzless to read the logfiles of the builds, i JUST learned about bzgrep
<lfam>My Vim opens the compressed log files transparently, very nice :)
<lfam>That's the Debian Vim
<rekado>as does Emacs :)
<lfam>Does the Guix Vim lack this feature?
<efraim>dunno, i've never tried that
<lfam>Hm, it would have been worth it to merge master -> core-updates before starting the new evaluation. I wonder if I can cancel it
<efraim>that's harder than it sounds
<efraim>it'll also cancel everything from previous evaluations that is carried into the current evaluation
<lfam>Hm... well, it's just the "leaves" of the graph. No big deal
<lfam>No big deal to not have merged, that is
<ng0>I wonder what the impact of blobs in average consumer hardware is. I mean, linux-libre. I wonder wether I want to use linux-libre (and therefore sticking to my goal of using as much of guixsd as possible) or linux for a system for people to use where ever they go. What's important is wifi and gpu. I experienced on desktop systems that gpu can be difficult, but laptops worked so far. incompatible wifi can be
<ng0>theoeretically fixed with a wifi usb dongle (which is unfortunate, but should work).. but I'm still not entirely convinced to pick a side, on the hardware support in all corners of the world list..
<ng0>why does this always fail recently:
<ng0>guix system: error: build failed: some substitutes for the outputs of derivation `/gnu/store/f582fw51y6mm2jwavb4njzr7saz49ikm-module-import-compiled.drv' failed (usually happens due to networking issues); try `--fallback' to build derivation from source
<lfam>ng0: I believe those files are not created deterministically. Is there another message about a hash mismatch?
<lfam>In any case, it always works for me when I use --fallback
<ng0>fallback is what I use here too
<efraim>is that the tar one?
<efraim>we also got one for bind ~45 minutes ago on oss-sec
<lfam>I can do the bind update now
<lfam>The tar update will be annoying if we have to graft it...
<efraim>sounds good with the bind
<efraim>tar sounds like it would go nicely with a "bump tar and ungraft everything" branch
<lfam>The tar bug that was reported to MITRE in July...
<civodul>tar is a core thing so that would be the next core-updates
<civodul>the timeline shown in the report on oss-sec was kinda scary
<civodul>the bug had been discovered at the beginning of the year IIRC
<lfam>Sigh... so many core projects don't get the attention they deserve. I think it's a clear example of what economists call a "market failure"
<civodul>though i can understand the viewpoint of the tar maintainer
<civodul>after all, this bug hurts only if you're taking risks already
<lfam>Yes, I understand too. But I wish the advisory would be publicized sooner
<davexunit>icecat is sooooo crashy
<lfam>Yeah, what the heck is going on with icecat? Everybody is complaining and we still don't know what the problem is :/
<davexunit>I restart it over a dozen times a day
<davexunit>I have no clue what the problem could be
<lfam>It seems like it crashes so often that one could trace it
<davexunit>it seems to happen randomly
<lfam>The trace might not end up being too big
<davexunit>so reproducing it is hard... it might take minutes or a couple of hours for it to happen
<ng0>sometimes it's okay for days here
<lfam>Yeah, but I think it could be worth it...
<davexunit>what kind of trace?
<lfam>Especially in such a sensitive application
<rekado>I can reliably crash it on a twitter feed with embedded gifs
<lfam>My naive choice would be strace
<lfam>Great, sounds like an easy reproducer
<davexunit>I don't know if strace will reveal the issue
<rekado>I could try running it in gdb
<ng0>it happens with videoplayback here, or with images
<rekado>(or do I need to build the closure with debug symbols?)
<lfam>I view Twitter Debian's Firefox and it's stable
<lfam>...Twitter with Debian's....
<rekado>yeah, Fedora’s Firefox is stable too.
<davexunit>if it seems to be video and images, perhaps there's a bad call into a library
<ng0>but do they unbundle what we unbundle?
<lfam>My worry is there is some bug that could be exploited remotely with enough effort
<davexunit>we're actually safer because we can't reliably use the web
<lfam>I pushed the BIND update, thanks for the tip efraim
<lfam>davexunit: If only ;)
<lfam>I think of each bit of strange behaviour as an invitation for bad people
<lfam>ng0: Good question
<davexunit>good luck hacking me, my browser will crash first!
<lfam>A common argument for bundling is "we fixed bugs in the library and upstream hasn't released the fix yet"
<lfam>davexunit: You do see my point, right? :)
<davexunit>lfam: yes
<davexunit>just playing :)
<lfam>It's hard to tell on the internet
<lfam>I remember reading commentary on that terrifying libarchive analysis a few months ago, and FreeBSD users were talking about how often the system update component that uses libarchive used to crash...
<ng0>lfam: second question: and if we unbundle comparable, how do our libraries differ from debian/etc
<lfam>Speaking of which, why are we still doing `guix pull` over HTTP? I don't remember if there was a good reason that Savannah's Git repos still aren't served with TLS
<lfam>Does anyone remember?
<ng0>probably gnutls
<lfam>ng0: A tedious task to compare bundled libraries
<lfam>I better re-read the "Trustable guix pull" thread
<ng0>so far core-updates reconfigure just builds fine
<lfam>Yay. There should be substitutes for everything affected by the cups-minimal update within several hours
<lfam>Assuming no breakage...
<ng0>it's not done here
<efraim>lfam: don't forget the bind in isc-dhcp
<lfam>Bah, thanks again :)
<lfam>efraim: Actually, I have to AFK in a few minutes. Can you do it? Or somebody else?
<lfam>Maybe we should update isc-dhcp too?
<civodul>amz3: the libgit2 bindings seem to be making good progress, no? :-)
<civodul>amz3: any ETA for a release?
<efraim>Sorry, off to bed already
<lfam>Okay. Somebody else will do it, or I'll do it in some hours :)
<rekado>trying to crash icecat to debug it but it simply won’t comply.
<rekado>does anyone have a URL that reliably crashes icecat? Mine won’t work.
<ng0>spend some time on youtube or other video streaming sites
<ng0>or some infinite scroling website
<ng0>now the recomnfigure seems stuck
<ng0>I do it via ssh, so it could still be going..
<ng0>udisks2 is making no progress in download anymore
<ng0>with --fallback
<rekado>just abort and retry?
<rekado>finally got it to crash, but lacking debug info I still don’t know what’s going on :)
<rekado>hoped it would be a little more obvious.
<rekado>the error seems to be triggered by cairo.
<ng0>hm... newest firefox brings in an optional experimental cairo(?) replacement, if I remember it correctly. cairo is 2d rendering, right? i think it won't help us for some more versions though
<rekado>in the code there’s an ifdef to use either the internal cairo or system cairo.
<rekado>when you search for “cairo” in about:config it should return two keys: “” and “”.
<rekado>I set both of them to “skia” instead of “cairo” just now and a page that crashed Icecat twice in the last 10 minutes no longer does so.
<rekado>maybe give that a try?
<ng0>yeah that was it. skia is in ff49.x an option
<ng0>I don't know how well it's supported in 45
<ng0>or whatever we use
<ng0>gentoo started providing this new use-flag, that's how i noticed last month on the other system