<Acou_Bass>lfam: whats the deal with GRUB on arm? is it not supported by GRUB, or is it not supported by the ARM firmwares? <lfam>Acou_Bass: I'm not sure, but I know that there is some issue with it not working so far. I think it's the primary reason that GuixSD doesn't support ARM yet <lfam>I just saw the headline and went looking in the changelog for mention of ARM. So hopefully it works for us! <Acou_Bass>id love to run guixSD on my raspberry pi - doubt itll happen though, this thing is riddled with nonfree blobs that almost certainly arent in linux-libre <lfam>If it's the original, that architecture (ARMv6) probably won't be supported <lfam>Acou_Bass: It's ARMv8 but I think some things are restricted to 32-bits for the time being <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 <Acou_Bass>which is a shame, because they are awesome for home server projects <davexunit>BeagleBone Black can run a fully free OS, blob-free. <Acou_Bass>is there anything on it that doesnt work though? <Acou_Bass>considering as i said my Pi just runs servers so is headless anyway, lack of 3D gfx isnt a killer for me <paroneayea>davexunit: (btw I gave you access to the talks repo) <paroneayea>maybe I should replace my snowflake slide with it <davexunit>paroneayea: I have cloned the repo with the SSH URL so everything is all good, access-wise. <davexunit>and I got the Makefile to work. I haven't pushed anything yet, though. ***Acou_Bass is now known as Piece_Maker
<procyon_ember>piyo: Thanks, but the topic is still not helpful. Instead of "avoid pastebin.com" it should say "use paste.lisp.org" or something similar. <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 <civodul>i thought the code in (guix profiles) already handled gdk-pixbuf things, but apparently no <Jookia1>I don't think it searches XDG_DATA_DIR for modules <civodul>rekado & iyzsong know better about these things <civodul>at any rate, we could probably add a hook in (guix profiles), like for the other gtk things <iyzsong>no trick for gdk_pixbuf now, applications have to wrap with GDK_PIXBUF_MODULE_FILE currently. <Jookia1>Perhaps profiles need the ability to specify which GTK modules they want to expose? <iyzsong>I think icons are fine, they're searched in XDG_DATA_DIRS. <Jookia1>Setting GDK_PIXBUF_MODULE_FILE fixes this <Jookia1>Not sure exactly where in the stack it'd be appropriate to do that <iyzsong>maybe we can hardcoded librsvg into gdk-pixbuf, there is no other extensions to it AFAIS. <rekado>Jookia1: for input methods I thought GUIX_GTK{2,3}_PATH are sufficient. This is enough to make ibus work for me. <Jookia1>rekado: I'm not exactly sure about the situation with that, I shall have to do more testing. It could be that's sufficient <Jookia1>Ah yes it looks to be at a quick glance <Jookia1>iyzsong: I like the idea of building a 'monolithic' gdk-pixbuf <Jookia1>Or rather, have gdk-pixbuf depend on librsvg somehow <Jookia1>Or! Perhaps we could have GUIX_GTK{2,3}_PATH for pixbuf modules and have librsvg in the profile? <Jookia1>... Which would be the same as setting GDK_PIXBUF_MODULE_FILE. Eugh. <iyzsong>Jookia1: I think replace the 'gdk-pixbuf' of gtk+ to the one with librsvg support should be sufficient :-) <iyzsong>the variable is not for this function.. <Jookia1>iyzsong: One thing that worries me is that overriding GDK_PIXBUF_MODULE_FILE would break things if an application is expecting different <iyzsong>if we can build a gdk-pixbuf with librsvg support hardcoded, there is no need to specified GTK_PIXBUF_MODULE_FILE for applications linking to it. <Jookia1>I see. Well I should try doing that then <civodul>yeah i think hardcoding librsvg support in gdk is reasonable <Jookia1>civodul: I did my first graft today- the GTK theme path patches! So I can now send it to my friends that use binary substitutes for testing <civodul>oh but librsvg depends on gdk-pixbuf, so it's not that simple <iyzsong>yeah, not replace the current gdk-pixbuf, but add gdk-pixbuf+librsvg, I guess it's possiable ;-) <Jookia1>It shouldn't be that hard to build both at once would it? <Jookia1>The problem is that gdk-pixbuf either uses env variables or reads from its build DATADIR for the module cache <civodul>yeah, better make a separate gdk-pixbuf+librsvg package <iyzsong>that's right, I think in the 'post-install' phase of gdk-pixbuf, rebuild the cache in store with librsvg. <Jookia1>Ah, so you build gdk-pixbuf once, then again with librsvg? <Jookia1>Maybe I don't understand this enough <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" ***Gottox_ is now known as Gottox
<efraim>in the 0.9.0 there's an undeclared dependancy on guile-json <roelj>How to deal with source zip files that don't unpack in a subdirectory? <roelj>I don't want to replace the build phase simply because unpacking goes wrong for Guix.. <efraim>if you unpack them after the unpack phase then they'll get the 'patch-shebang phase also <roelj>so (add-after 'unpack 'unpack-in-subdirectory (lambda (...) (mkdir-p "<program-name>") (system* "unzip" "arguments-to-unpack-in-subdirectory"))) ? <efraim>that looks right, you might need to make sure it gets unzipped into the right directory <roelj>How can I refer to the source zip file? <efraim>the source is a zip or there's a zip in the download? <efraim>if its the source then (assoc-ref %build-inputs "source") should work <rekado>we also have "url-fetch/tarbomb", but I don't know if this would work for zip files. <roelj>How can I find out where the build phase looks for the unpacked files? <rekado>roelj: guix/build/gnu-build-system.scm --> "unpack" <rekado>it just goes into the first subdirectory <roelj>And the ant-build-system? ;) <roelj>I can't see the mechanism of moving into the first subdirectory <rekado>(chdir (first-subdirectory ".")) <rekado>the ant-build-system just reuses the gnu-build-system's unpack phase. <roelj>So, when I add a different phase after unpack, that chdirs somewhere else, the build phase will use that directory instead? <roelj>In other words, the current working directory transcends the phases? <roelj>Anyway.. My build fails with "Buildfile: build.xml does not exist!". But ls /tmp/guix-build-xz-java-1.5.drv-5/source/ definitely shows a "build.xml". <roelj>Ah, of course.. I had to chdir into my newly created directory.. <roelj>rekado: Where should we install JAR-files to? Should we use /share/java/<program-name>/ as dist directory? (When using ant-build-system) <rekado>roelj: yes, that's what I've been doing so far. <roelj>Maybe we should change that some day to a maven-compatible path. I'll use the /share/java/.../ path for my packages too for now. <rekado>I agree. We can change this later, if necessary. <roelj>Right now I'm trying to package the dependencies for Picard. :) <wingo>AWBULOSFHGO (always be updating list of substitutes from hydra.gnu.org) <mark_weaver>at this point, part of the problem is with the grafting code <civodul>wingo: does mirror.guixsd.org work better? <wingo>civodul: dunno, will try later :) <wingo>in order to update one profile i appear to be downloading three different builds of the same perl <ehiggs>There's no --with-guile in the configure script so is there a way to convince configure to use ~/.local/bin/guile ? <davexunit>I haven't filled in a ton of stuff yet, but I did add the xkcd comment <wingo>ehiggs: maybe PKG_CONFIG_PATH=~/.local/lib/pkgconfig ./configure <wingo>ehiggs: maybe PKG_CONFIG_PATH=~/.local/lib/pkgconfig:$PKG_CONFIG_PATH ./configure <wingo>profiles are so nice. source the profile file and you're in: no slow sending of packets over the network <davexunit>paroneayea: turns out that I will have to bail out on Saturday after our talk, but I will be there all day on Sunday. <ehiggs>wingo: thanks! that worked perfectly <davexunit>paroneayea: since the FSF can't stream live if we don't use their laptops to present on, I guess we can't really do any demonstrations. <davexunit>so I think that maybe a few more emacs/terminal screenshots would be good in lieu of being able to show it IRL <paroneayea>less chance of mess-ups, plus then we have an excuse for taking the safe route ;) <NiAsterisk>also, is somebody here using Gnus with emacs from Guix and could share with me a way to setup GnuPG encryption? I totally got lost now in outdated configs. idk if it's guix or me. <NiAsterisk>setup.. like, make Gnus not only decrypt but encrypt and sign <ehiggs>It seems guile-top is another unstated dep in 0.9.0. Is there a list of unstated deps somewhere? <davexunit>wingo: since 'guix environment' now creates profiles on-the-fly, we will eventually have UI to put them somewhere convenient so that you can just source and go like you want. <roelj>My Guix does not pick substitutes anymore, even though I have authorized hydra.gnu.org for downloading substitutes, and I am not adding --no-substitutes to my commands..! What could be wrong? <davexunit>roelj: it means that substitutes aren't available for the derivations you are building. <davexunit>is your guix old? have you changed something in the core that causes a full rebuild? <paroneayea>oh, does anyone have an anticapslock caps->ctrl setup for the tty? <davexunit>paroneayea: no, but I would like one, too. :) <roelj>No, but it may be too new.. I changed the symlink ~/.config/guix/latest to the git repository. I pulled, make && make install'ed right before guix build -K <some-package> <wingo>davexunit: sounds like you will then have to manage those profiles (give them names, upgrade them, etc) <davexunit>wingo: haven't thought that part through yet, but it would be nice to be more in control of when the environment gets upgraded. <wingo>i like that i control when profiles are upgraded independently of when i upgrade guix or my default profiles <davexunit>the existing on-the-fly stuff will remain in place for quick jobs. I use 'guix environment' for quick experiments all the time. <davexunit>so I wouldn't want to be burdened with profile management in those cases. <wingo>sure. i need something that is a stable base for long-lived development and i currently use profiles for this purpose <davexunit>I envision something like 'guix environment --save ...' <davexunit>that would drop a profile symlink in the current directory or something <wingo>i've never run guix gc in anger <wingo>so i will hvae to build libreoffice it seems (!) <wingo>at least, it's building vigra now and i guess it will succeed <wingo>surprising hydra hasn't gotten to LO yet i guess <davexunit>would be cool if there was some way of guix informing the user that a derivation is known to fail based on information from the substitute provider <civodul>davexunit: yeah we could provide special narinfos for that <ehiggs>ho ho, i had to set PATH as well as PKG_CONFIG_PATH to pick up the correct guile. <davexunit>ehiggs: FYI, 'guix environment guix' will spawn an environment with everything you need to build Guix. <kristofer>hello! last night I was trying to dd if=$(guix system disk-image os.scm) of=/dev/sdb - which appeared to try and boot up the image in qemu. Am I using it incorrectly? <kristofer>it did not successfully dd the image to my usb disk <civodul>kristofer: no that's fine; it does boot up a VM to be able to create a disk partition <kristofer>civodul: does my grub-configuration device need to reflect a disk-image vs an actual disk? <civodul>kristofer: that suggests (obscurely!) that the image is too small <civodul>so you need to increase the --image-size parameter <wingo>does --pure work with --ad-hoc? for some reason under nixos it's not adding to my $PATH <davexunit>is there something simple I could run to reproduce? <wingo>so, "guix environment --ad-hoc clang" <wingo>in that environment i have clang <wingo>but "guix environment --pure --ad-hoc clang" <wingo>i was trying for some other packages but i knew i didn't have clang in my profile or in nixos <wingo>ACTION stupid user bug reports today :) <alezost>wingo: may it be that you set some environment in your .bashrc instead of .bash_profile? <wingo>nothing important set in ~/.bashrc; it doesn't even source /etc/bashrc <wingo>does the "problem" happen for anyone else? <wingo>i guess the question is mostly for people not on guixsd <davexunit>guix environment --pure --ad-hoc which clang -- which clang <wingo>davexunit: that works for me <kristofer>civodul: is there a way to estimate the resulting disk-image size? <davexunit>wingo: does this work? guix environment --pure --ad-hoc clang -- clang --version <davexunit>if so, I think the problem may lie in your shell config <wingo>davexunit: i would expect so bc your which clang line works <wingo>takes like 10 friggin seconds to run <davexunit>perhaps NixOS is doing something fishy in the system-wide bashrc or something? <wingo>yeah it could be nixos's fault. <davexunit>what does $PATH look like in that env? (might need to toss coreutils into that pure env) <wingo>i have ~/.bashrc, ~/.profile, ~/.bash_profile, ~/.xprofile, and none of that sources the /etc/bashrc etc and yet i do end up with nixos paths <wingo> /home/wingo/bin:/var/setuid-wrappers:/home/wingo/.nix-profile/bin:/home/wingo/.nix-profile/sbin:/home/wingo/.nix-profile/lib/kde4/libexec:/nix/var/nix/profiles/default/bin:/nix/var/nix/profiles/default/sbin:/nix/var/nix/profiles/default/lib/kde4/libexec:/run/current-system/sw/bin:/run/current-system/sw/sbin:/run/current-system/sw/lib/kde4/libexec <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 <wingo>davexunit: the manual says only for login shells or a noninteractive shell with --login. <davexunit>wingo: okay, so I wouldn't think that it would be read in your case. <civodul>kristofer: yes, with: guix size $(guix system build config.scm) <civodul>kristofer: the image has to be bigger than this <davexunit>civodul: there's a wishlist item: inform the user if the image size is too small by analyzing the size before attempting to build. <JeanLouis>NiAsterisk: tell me your problem with Gnupg... <civodul>davexunit: yeaaaah, but it may be somewhat fragile <JeanLouis>currently I am using mutt and Gnupg version 2+ from Guix and is working well. I can decrypt, encrypt, all is well. <civodul>davexunit: i mean it's just a rough estimate <kristofer>civodul: can guix size provide a sum of the packages' size? <NiAsterisk>JeanLouis: see gmane.emacs.gnus.user , a problem with emacs, not gnupg. <JeanLouis>I have just tried to encrypt file through emacs, I am on IRC on emacs, and I could encrypt it without problems. <JeanLouis>ehm, I don't know though how to see that and I don't use gnus... <NiAsterisk>newsreader, or plain gmane.org view or the corresponding maillist. to be more specific: A problem when using Gnus in combination with epa and trying to signencrypt <efraim>every time I create a custom package definition I'm reminded of RMS on the customizability of emacs <kristofer>efraim: speaking of custom packages, do you keep them inline with the gnu packages or do you put them into a seperate package set? <efraim>I stick them in a separate git repo <efraim>vim-custom and such would kill me with separate branches <efraim>I've only modified packages I have installed in my profile, so I don't have a bunch of rebuilding as if I'd upgraded mesa or something locally <efraim>I also have 2 or 3 packages I haven't submitted (like speedtest-cli) <lfam>So close to a proper nmap package... <jlicht>would the easiest way to package a piece of software for guix include working from a git checkout? <davexunit>jlicht: do you mean building from a git checkout? search for 'git-fetch' in the gnu/packages directory for many examples. <NiAsterisk>no, i think it was a question on how to work on guix packaging <kristofer>jlicht: it's easy to manipulate the existing packages from a git checkout. you can easily create a package definition in a file and install it with guix package -f package.scm <kristofer>it's not necessary to checkout the guix source <davexunit>it is necessary if you want to add that software to guix officially. <kristofer>jlicht: if you could clarify your intention the question might be easier to answer :) <jlicht>kristofer: sorry, I thought it was clear enough :O. <jlicht>I was referring to packaging a piece of software that I need to use on guix, and seeing as it would be free software, it does make sense to get it included in guix ;-) <jlicht>davexunit: although that wasn't what I was wondering about, it would probably be the next question I had <wingo>the guix manual uses @var{} to denote concrete bindings, not just function parameters or metasyntactic variables <wingo>"Return a derivation that builds a @var{guile} script" yarrr noooo <davexunit>seems like an accident more than something intentional... unless it's all over the place. <a_e>Hello! I have problems creating guix.pdf; I think I am just missing a package. Does anybody know which one? Here is the output of "make V=1 pdf": <a_e>Output written on guix.pdf (183 pages, 776821 bytes). <a_e>Transcript written on guix.log. <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 <wingo>davexunit: it was in a few sections, didn't look farther <phant0mas>at first I thought that maybe the binaries where being built for the wrong architecture <phant0mas>but then the dissasemby showed that this was not true <davexunit>I have no clue what's going on with avr-gcc. <phant0mas>I have used the same sources to build the toolchain outside guix <davexunit>phant0mas: I compared avr-gcc in guix with the one in debian <davexunit>what I noticed is that our avr-libc has .a files for all of the various supported AVRs <davexunit>for example, libgcc.a is missing for a ton of AVR variants <wingo>cget can be simply installed using pip: <wingo>npm install pip, pip install dnf, dnf install guix, guix install npm <wingo>oh wait "guix install" never landed :) <wingo>meant to paste those first two lines within quotes of course <Jookia>we're truly in the era of crippling our tools across the board so windows users feel equal <davexunit>the conflation build systems and package managers is very problematic <davexunit>the blame isn't completely on the developers of these tools. traditional system package managers really don't have the features that developers need. <davexunit>but I've found that even fixing this problem isn't enough for a lot of people, because a surprising number of developers tell me that any solution *must* work on Windows. <wingo>npm got v popular without windows <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 <davexunit>Homebrew, a package manager for OS X, is a Conservancy member project. <janneke>davexunit: they can use guix...to become a developer they'd have to switch to a free os :-D <rekado>trying to package portmidi, but it's a mess :( <davexunit>janneke: they could hack Guix on OS X just fine. <davexunit>provided there's no nonfree software needed to bootstrap <rekado>I thought you absolutely need to use xcode. <wingo>i don't see why you couldn't cross-build a gcc etc and use that to bootstrap the world <wingo>but maybe i'm missing something <wingo>could be no other system is as advanced as guix :) <wingo>i want to learn more about google's "bazel" one day <janneke>ACTION has a friend who was on the bazel dev team <wingo>they took a former v8 person i knew too <wingo>i wasn't interested but that person was really smart and effective, they must have something of value there ;) <wingo>nah, just looking for things to steal <wingo>like a criminal casing a rich house <janneke>they certainly have a technically inspiring environment, great people <rekado>ZombieChicken: I'm using GuixSD on my main machine. <rain1>yeah it's pretty usable, not perfect but i like to use it <lfam>Any ideas why am I unable to refer to lua-5.2 or lua@5.2 in the inputs of another package? I see other packages that refer to lua-5.1. <Jookia>ZombieChicken: It can be if you want it to be <lfam>And I can refer to lua and lua-5.1 in the package definition <rain1>is it done like "lua@5.2" ,lua ? <ZombieChicken>Jookia: How much of a pain is it to tell it to just do source-based? Also, does the package manager overwrite upstream C/LDFLAGS? <lfam>I thought that the version had to be specified on the right, as in "lua" ,lua@5.2 <lfam>Guix is transparently source based. If binaries are available and enabled, you will get binaries <lfam>But if they are not available, you will build from source <Jookia>ZombieChicken: --no-substitutes will build everything from source, and I don't think you can just overwrite flags like Gentoo <mark_weaver>ZombieChicken: if you pass --no-substitutes to guix-daemon, then you'll never download any binaries <mark_weaver>(except for our bootstrap binaries, which you can't avoid) <Jookia>Having CFLAGS changeable would probably wreck havock on the idea of state in Guix packages <lfam>You just wouldn't get any substitutes <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 <NiAsterisk>what's the current state of getting a functional GNOME desktop into guix? <Jookia>NiAsterisk: I've heard some people have it somewhat working <mark_weaver>NiAsterisk: I've been using GNOME Shell on GuixSD for the last week or two. it mostly works but there are some issues <mark_weaver>the biggest one is that when waking up from suspend-to-RAM, it immediately suspends again and the only way to recover seems to be to power off. <NiAsterisk>ah, interesting. Shell is the equivalent of kdm? <mark_weaver>GNOME Shell is the well-known GNOME 3 interface, highly animated with overview mode, etc. <rain1>when I try to compile this library I get errors about: unknown type name ‘uint32_t’ <rain1>could it be that I need some headers dependency? it feels very unlikely the programmer got this wrong <rain1>i tried adding linux-libre as an input but it didn't have any effect <Jookia>are they including stdint/cstdint <rain1>no, there's a .mk file that mentions inttypes.h <rain1>i don't want to patch the code but maybe that is the only way <Jookia>If it's packaged for other distros you could see what they've done <rain1>if I just do the edit and sucessfully build inside guix environment, is there a way to install that? <rain1>or do I have to create a patch file and upload it somewhere and then make my package def point to that... <mark_weaver>you have to create a patch file, but you don't need to upload it anywhere <mark_weaver>we include many patch files in guix, in gnu/packages/patches