<Acou_Bass>i havent delved too much into the specifics of the device, it sits in a corner behind my TV serving small servers that i wanted offloading from my main desktop and thats about the extent of my knowledge XD
<Acou_Bass>i just know that the raspbery pi range are laden with hardware that has no free drivers for whatever reason despite them being some sort of bastion for the hacker movement
<lfam>Yeah, they have a good network effect but the hardware's not great
<Acou_Bass>i dont think there are many SOC-type boards like the Pi's that are remotely free in terms of hardware/firmware drivers
<davexunit>paroneayea: "GitLab: You are not allowed to push code to protected branches on this project."
<Jookia>Time to graft Xfce with GTK theme patches!
<Jookia>Whoa my patch works and I found a firefox dark theme that works on all sites!
<mik_>what are the recommendations if my wireless card requires iwlwifi?
<Jookia>Don't use wireless, get another wireless card, use a USB dongle, etc
<mik_>looks like someone wrote the guix expression for iwlwifi; I'm just not sure how to add it to the store
<Jookia>mark_weaver: My latest GTK patch series using XDG_DATA_DIRS can be grafted to get a decent result so I'll probably start bugging people to test it soon. Icecat seems to statically link ... everything. So it doesn't work there. If you think it's a good solution on our end (not the grafts, the patch) I'll get some input from GTK upstream
<lfam>I'm working on a package whose version is 2.1, but the source URL says 210. It seems all the releases are like that. The version is multiplied by 100 to name the tarball. Should I do arithmetic on the version to generate the URL?
<Jookia1>Okay so I figured out why Numix icons aren't working
<Jookia1>More GTK stuff needing to be workedaround
<iyzsong>Jookia1: yes, our gdk-pixbuf is still here for librsvg, but when building gdk-pixbuf+librsvg, maybe just copy the cache from librsvg into the right place in store should do it?
<Jookia1>iyzsong: The store is read-only and from what I understand gdk-pixbuf only looks where it was 'make install'd to, so you'd have to build a new version and have a cache built with librsvg in it
<iyzsong>yes, we can it in the 'post-install' phase, `make install' of gdk-pixbuf always install a cache without librsvg. then we copy the one from librsvg (or we generate here) to override the cache.
<Jookia1>That makes sense, but if librsvg depends on gdk-pixbuf wouldn't it need to build gdk-pixbuf first?
<iyzsong>sure, so we'll end up with two version of gdk-pixbuf in the closure.
<Jookia1>Neat. Perhaps I should wait for you to do this?
<iyzsong>well, better remove the cache from our current librsvg, I think it's for legacy using.
<ehiggs>Good morning! Quick one: are any pieces of software available in the chrooted environment without having to be specified? for example, packages don't seem to have to specify which autoconf is needed.
<ehiggs>I'm curious if perl is also in that bucket
<ehiggs>civodul: thanks. i see that there is 'build-system' and pointing to gnu-build-system, I guess points to using autoconf.
<civodul>gnu-build-system does not depend on autoconf
<civodul>Autoconf & co. are only needed for developers
<civodul>people who install software just need a bourne shell and make
<civodul>but yeah, gnu-build-system provides things like gcc, libc, etc.
<ehiggs>hm, I thought I had run into software that required that I have automake > some-version. Maybe they only had the .in files in the vcs and it was incumbent on the developer to generate things when pulling from tarballs.
<civodul>yeah developers are supposed to generate self-contained tarballs with "make dist"
<wingo>so, i guess i need to find what the deal is with nixos bash
<bishopj>How does one make guix use a network proxy?
<wingo>i never understand this stuff in a persistent way :) i can page it in, then it goes away. however. seems that bash will first run /etc/profile if it is there. on nixos it is there and does a few things.
<wingo>so it seems that in --pure setups, it wipes out the PATH etc that has been inherited from guix
<NiAsterisk>wow this is a weird bug. I dislike and like emacs at the same time
<a_e>/gnu/store/wvjdrpwzixccrwnzcxbnlwc445r24ha0-profile/bin/texi2dvi: pdfetex exited with bad status, quitting.
<a_e>So the pdf is created and then deleted again.
<phant0mas>davexunit: I have tried everything I could think of, the avr-binutils, avr-gcc and avr-libc binaries are exactly the same with the ones I have built outside guix, but still I am getting avr-ld: skipping incompatible /gnu/store/vwgp4kkwwiszj640089gx1iklbzlcpw0-avr-libc-2.0.0/avr/lib/libm.a when searching for -lm
<Jookia>rekado: apparently some people develop software using windows
<davexunit>rekado: yeah I dunno, but it's a very common response that I get when I propose Guix as a potential solution.
<Jookia>i've never been able to get past the pain of it
<rain1>why should it work on windows if its a package manage for linux programs
<davexunit>OS X is another issue, but that may be feasible for Guix to do, but I'm not 100% sure because I haven't seen definitive proof that an OS X-based build system can be created without using any proprietary software
<janneke>davexunit: we cross build lilypond to osx using free software
<Jookia>rain1: Guix isn't just a package manager for Linux programs, it's a fantastic development tool
<davexunit>janneke: that's promising, but I'm still not sure if it's possible to do native builds.
<janneke>davexunit: ah... why would you want to do that? ;-)
<Jookia>I have a feeling lots of people will want to develop for their apple phones or whatever they're called which require nonfree software as the toolchain
<Jookia>I mean not that it's undesirable of unpossible but more that you'd lose a big benefit of having the same derivations as everyone else
<ZombieChicken>It's just I don't trust distro maintainers to know what flags a package should be built with, and I know with Gentoo some packages are compiled using less aggressive flags than upstream, which annoys me, but there is no sane way to get around that little problem without having to delv into undocumented "features" of Portage
<Jookia>You can add per-package flags if you want to their package files