<mark_weaver>katco: thanks for bringing this to my attention. it may not be in the relevant CVE database yet <katco>mark_weaver: what is the procedure for updating the cve db? i wanted to see how i could contribute going forward <katco>mark_weaver: and ta for updating the packages <mark_weaver>we don't maintain that database, so we can't update it. it's maintained by nist <mwcampbell>How are the GuixSD kernel configurations created? linux-libre-4.7-x86_64.conf is very different from the output of "make x86_64_defconfig" for the same kernel version. So did someone just enable all those additional options by hand? <katco>when i do guix package -u -n it returns without saying it's going to do anything. guix package -u then proceeds to try and build vigra and i have no idea why. any ideas? <mark_weaver>katco: the -n is interpreted as the argument for -u there. if you want other options after -u, then you need to say "-u ." instead of just "-u" <mark_weaver>katco: I just pushed updates for those packages to our 'master' branch <katco>mark_weaver: that would make sense. not sure why it's not using a substitute though <mark_weaver>unfortunately, in the presence of grafts, with the current implementation at least, it's not possible to see ahead of time what will be built. <katco>ah, so -n is not always reliable? <mark_weaver>if you use 'guix build' on individual packages, then you can do this: "guix build -n <package> --no-grafts" <mark_weaver>or even without the -n, it will show you ahead of time what will be built. <mark_weaver>but --no-grafts doesn't really work with other things, and if things need to be grafted, then the grafting code needs the outputs of packages in order to decide what ultimately needs to be built. <mark_weaver>so, even if you ask for -n, if grafts are enabled and there are some grafts needed, then things need to be built before you question can be answered. <mark_weaver>it's definitely not ideal, but so far we haven't figured out how to do better with grafting. <katco>is there any reason to use grafts if i'm primarily using substitutes? <mark_weaver>yes, you need to use grafts to get certain important security updates, including the updates for libgcrypt that I just pushed <mark_weaver>without grafts, updating libgcrypt would involve rebuilding almost every package we have from scratch <katco>oh that's right, grafts operate at the linking level don't they <mark_weaver>but sometimes I start by building something big without grafts, just so that I can see the list of what needs to be built ahead of time. and after that's done, I build (or install) it again *with* grafts, and that goes much faster. <katco>i wonder why it's trying to build vigra instead of using a substitute <mark_weaver>probably because the needed substitute is not yet built. for one thing, an update to pulseaudio was just pushed to 'master', and it's not yet built out. <katco>i kind of wish there was an --only-substitutes flag or something. this workstation is not equipped to handle a build like that <mark_weaver>well, most of the packages should be built for the new pulseaudio, because we had hydra build the 'pulseaudio-update' branch, which was based on master from a week ago or so. <mark_weaver>however, there have been some other updates to master since then. <mark_weaver>katco: what you can do for now is this: guix package -u . --do-not-upgrade libreoffice <mark_weaver>and maybe add some other things after that, to avoid rebuilding the really big things for now. <mwcampbell>mark_weaver: How do you generate the GuixSD kernel configurations? Do you just have to start with "make defconfig" and then turn all those other options on manually? <mwcampbell>Just wondering how to make sure my ARM kernel configuration will have everything GuixSD needs. <mark_weaver>mwcampbell: we started from kernel configs maintained by Jason Self, but lately I've been updating them by hand on each major new kernel version using "make oldconfig" <mark_weaver>the configs for linux-libre-4.4 were the last ones I copied from jxself <mark_weaver>hmm, well, there will probably be some trial and error there <mwcampbell>Then I guess for ARM, I'll have to start with "make multi_v7_defconfig", then if I notice any major class of drivers missing, add them myself <mark_weaver>ideally, I'd like to move to a model where we have less redundancy between kernel configs. e.g. to have maybe one base config for each major kernel version, plus some added bits for each architecture. <katco>mark_weaver: sorry, got pulled away by my toddler :) ty, i will try that <mark_weaver>katco: no problem, I'm quite familiar with that problem myself :) <mark_weaver>mwcampbell: one issue is that our initrd-generation code expects certain modules to be available. see the inner *-modules variables within 'base-initrd' in gnu/system/linux-initrd.scm <mark_weaver>and some other important configuration options are those added to the .config in our 'linux-libre' package in gnu/packages/linux.scm (search for "CONFIG_NET_9P" for example) <mark_weaver>and generally, we want to enable modules for almost every driver or feature that we can. <mwcampbell>mark_weaver: Thanks for the tips. I'll try starting with the ARM config from Parabola. <mwcampbell>GuixSD doesn't apply any patches to the kernel, does it? <mark_weaver>just one, to add the bathing penguin logo. it's applied in a phase instead of in the 'source' form. <mark_weaver>although it does have the nice side effect of avoiding a separate step to patch and create new compressed tarballs of the patched source, which takes quite a long time for linux-libre <mark_weaver>I'd like to overhaul our kernel packages from the ground up at some point. <mwcampbell>Parabola applies a handful of patches, but I'll see how far I can get on my board without applying any patches. <mark_weaver>yes, it is our policy to stick as close to upstream as possible <mark_weaver>I need a custom kernel for my Lemote YeeLoong, which requires a large set of patches that never made it upstream. <mark_weaver>the way I did that was to create a separate package 'linux-libre-loongson2f' that inherits from linux-libre-4.1 and adds a bunch of patches. <mwcampbell>I didn't know you could run GuixSD at all on a MIPS-based machine. <mark_weaver>see the 'wip-loongson2f' branch on savannah for an old version of what I've been running. <mark_weaver>well, I'm currently the only one doing it as far as I know :) <mark_weaver>mainly because not all of the patches are ready to push to master <mwcampbell>I had forgotten that the Yeeloong could boot from USB. Most ARm boards can't AFAIK. <mark_weaver>that depends on being able to create and run mips64el-linux virtual machines within qemu on this machine, which I can't do yet. <mark_weaver>I could create a USB installer by hand, but I haven't done it yet. <mark_weaver>anyway, the important point is that if you need to add patches, I'd prefer to make that a separate package for now, like I did for 'linux-libre-loongson2f'. <mwcampbell>Manually building a stock kernel now with the ARM config from Parabola. Then I'll see if that runs on my Wandboard. <katco>hm, guix seems to have filled up my disk. gc doesn't remedy the situation :( <mark_weaver>katco: remove old profiles using "guix package -d" and try again. Note that "guix package -d" will delete *all* of your profiles except for the current one. you can specify a set of profiles to remove with additional arguments; see the manual. <katco>mark_weaver: ah ty! i hadn't quite delved into generations yet. <mark_weaver>garbage collection will only delete store items that are not reachable from a set of "gcroots" (see /var/guix/gcroots), which notably includes all user and system profiles. <katco>mark_weaver: i've seen this behavior a few times now: why when i guix package -r something does it sometimes download packages? <mark_weaver>guix package -r creates a new profile (tree of symlinks), and part of the process of making a profile involves running profile hooks (see %default-profile-hooks in guix/profiles.scm). running those profile hooks involves running the latest versions of various programs. <katco>i see. that makes some sense conceptually, but it's a little counter-intuitive that to remove a program i must install others <katco>is that a wart to be fixed later, or something folks don't see an issue with? <mark_weaver>I don't see a reasonable way to improve the situation, and I don't consider it a big problem. <mark_weaver>think of it this way: there is a certain set of tools that you need to create profiles. guix will use the latest versions of those tools to create them. <mark_weaver>you think of -r as simply removing stuff, but actually it doesn't remove anything, it only creates new things. <mark_weaver>it creates a new tree of symlinks, which we call a profile, with the new set of packages in your profile, and runs the hooks to create the needed indexes etc that need to be customized for that particular mix. <katco>it certainly makes sense once explain. i'm wondering if it's a usability issue... maybe -r should be reworked to better align with the fact that you're creating a new profile or something /naive-suggestion <mark_weaver>it's not clear to me how to improve it. if you have a more concrete suggestion, I'd be glad to consider it. <katco>i don't have anything atm. maybe as i use it more? at the risk of developing stockholm syndome :) <mark_weaver>this question of how to name purely-functional "remove" or "delete" operations is an old one, though. I've not seen an idea that's better than this, so far. <mark_weaver>things like --new-generation-with-packages-removed would be too awkward. <katco>that's along the lines of what i was thinking though <katco>guix package --new-generation -(hello) +(emacs vim) <katco>who the heck would know how to use that though haha <catern>so is .guix-profile hard-coded or compiled in somewhere? <catern>i am compiling a guix with some different config options and i'd like to use a store in a different location in parallel (basically two guix installations in parallel) <catern>but the new guix seems to be referencing .guix-profile, how might that be happening? <mark_weaver>catern: there's almost never a reason to use two separate stores <mark_weaver>many different versions of guix can share the same store without interfering with each other <mark_weaver>but if you insist, make sure that the two guix daemons have a different localstatedir (default ${prefix}/var) and pass -p to 'guix profile' to specify a profile symlink name. <catern>mark_weaver: yeah... but I am trying to build packages without root in a locked-down environment, and my store path is /home/catern/guix/store :( <mark_weaver>and there might be other problems as well. I've never tried this, never saw a reason to try it, so I don't know what complications will arise. <catern>mark_weaver: I configured a different localstatedir at build time, is there a way to configure the profile symlink name thing as well? I'm assuming that defaults to ~/.guix-profile? <mark_weaver>ah, well, that's a whole other can of worms. without building things in a chroot environment, it's likely that at least some package's build systems will find things in /usr, /bin, /lib, etc, and try to use them. <catern>indeed, but I have a hack around that as well :) <mark_weaver>I would guess that there are a non-trivial number of builds that won't work properly outside of a chroot environment <catern>I will build the packages on a server on which I *do* have root, and use the same store directory <mark_weaver>catern: I don't know, search for ".guix-profile" in the source code I guess <mark_weaver>I don't think there's a way to configure the default one, no. <catern>also without the build daemon running as root I'm getting "guix build: error: build failed: the build users group `catern' has no members" <catern>since I am running the guix-daemon as a normal user on my client server, and going to build all the packages remotely :/ <catern>oh heh the group genuinely has no members :) <catern>since it's my user's *primary* group :) <catern>ugh... "guix build: error: build failed: the Nix user should not be a member of `catern-sup'" <catern>since I just want to use substitutes :/ <catern>(when I am done creating the substitutes anyway) <lfam>I noticed your libgcrypt grafts did not define private variables for the graft packages, so there is a warning printed about "ambiguous package specifications". <lfam>It seems the ambiguity is not resolved deterministically <lfam>Usually those packages are private ***adam^ is now known as adam12
***adam12 is now known as Guest20954
***Guest20954 is now known as adam12
<janneke>ACTION just spammed guix-devel again ;-) <ng0>sneek: later tell lfam: never mind the email, i just checked the old updates and I still need to apply some of them to core-updates <rekado>I wish you all a happy GNU Hackers’ Meeting! Sad I couldn’t make it. Hope there will be videos! <nckx>G'day Guix. Is there a trivial way to tell gnu-build-system that it shouldn't try to chdir after unpacking a tarball, but build in the root instead? <alezost>nckx: do you mean the tarball is a tarbomb? If so, there is 'url-fetch/tarbomb' origin method for this case. Look at "guix edit muscle" for example <nckx>alezost: a zip bomb, to be precise. <nckx>alezost: thanks, I'll take a look. <alezost>nckx: I don't know whether 'url-fetch/tarbomb' work for zip, but if it doesn't, you can add a special phase to chdir where needed; look at 'java-xz' package <nckx>alezost: I found plenty of “add-after 'unpack” examples, the problem was that there are no subdirs, not even bogus ones. So 'unpack fails. I've “replace”d it for now with a manual call to “unzip”, but it feels dirrty. <davexunit>if the zip doesn't behave then you have no choice but to do something else. <nckx>ACTION thought there might be a #:subdirectory he could set to "." <alezost>nckx: oh, now I get it. Yeah, I agree then: replacing 'unpack' phase sounds like the way to go <rekado>Yesterday I had a problem using url-fetch/tarbomb. It complained about an undefined variable "name" IIRC. <bavier>speaking of our icecat being old and possibly vulnerable, my desktop at $work is running firefox 38.6 ;) <bavier>wow, I didn't know qt takes such a long time to build <davexunit>I don't know why it gets so much praise vs. gtk <mog>and people who dont code in it love to talk about it <mog>like xorg vs wayland <mog>qt is choose your own adventure licensed <mog>but used to be gpl / proprietary <catonano>bavier: that would be very interesting. I have been wondering, recently, about Backfeed and how it could play with free software communities <bavier>catonano: interesting. I hadn't read about backfeed yet <sankey>if anybody has access to a NetBSD system and is interested in having khal@0.8.2 packaged for guix <janneke>i mean: {appropriete or otherwise funny daytime} Greetings! <mark_weaver>sankey: guix currently only works on Linux (the kernel) <mark_weaver>each architecture+kernel combination requires a new port <sankey>mark_weaver: sorry, i should have been clearer---khal project is looking to release soon but they need to test khal on different platforms <sankey>i'm sitting on a set of guix package definitions for khal that i'll send out to guix-devel once it gets released <dtmeme>hello, I am installing GuixSD as a second OS next to Parabola on my UEFI PC <dtmeme>the ESP is /dev/sda1, guixsd root partition is /dev/sda5 <dtmeme>how should I configure the bootloader? <mark_weaver>dtmeme: do you want Guix to install GRUB, or do you want to use the GRUB from Parabola? <dtmeme>don't want to crap up my installation you know <mark_weaver>then pass --no-grub to "guix system init" (and also to "guix system reconfigure" later when you update your system) <dtmeme>Should I update grub config somehow? <mark_weaver>iirc, it will still install a grub.cfg file, which you can load from your parabola grub. <dtmeme>or will it detect the new OS automatically? <dtmeme>so how do I make GRUB detect GuixSD? <Petter>dtmeme: It's a possibility to type in the GRUB commands manually if you want to start there. <dtmeme>Petter: there must be a way to configure that <mark_weaver>dtmeme: you'll need to add a new entry to Parabola's grub.cfg that uses the 'configfile' grub command to load GuixSD's grub.cfg <mark_weaver>see the entry for it in the grub manual. it takes an argument, specifying the configuration file to load. <mark_weaver>you'll need to use the right grub syntax to specify the appropriate partition <mark_weaver>I would start by running that command manually from grub, and use the TAB auto-completion to find the right partition+fiel syntax. <mark_weaver>and once that works, you can put the same command in a new menu item in the parabola grub.cfg <dtmeme>I think os-prober should find GuixSD automatically <dtmeme>thank god there is grub-customizer tool <mark_weaver>dtmeme: btw, unlike other distros where the contents of grub.cfg doesn't change much, with GuixSD a new fresh menu item gets added every time you "guix system reconfigure", and it's very important for our system roll-back functionality that all of the menu items are usable. <mark_weaver>so, loading the GuixSD grub.cfg via configfile is by far the best option here. <dtmeme>it's not advised to directly change the contents of /boot/grug/grub.cfg <dtmeme>okay, what would I have to do to configure GuixSD's own GRUB to see Parabola? <mark_weaver>dtmeme: see section 7.2.12 (GRUB Configuration) of the Guix manual, specifically the 'menu-entries' field. it's fairly bare bones at the moment though. <mark_weaver>definitely don't edit /boot/grub/grub.cfg manually, because every time "guix system reconfigure" is run, it needs to add another menu item to it. <dtluna>There is no mention of ESP anywhere <dtluna>on Parabola you'd have to do "#grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=grub" <dtluna>And you don't have to specify the device <mark_weaver>Guix runs grub-install, which seems to auto-detect UEFI and installs the needed grub.elf (?) to the ESP. or at least that's my impression based on what users have experience when they tried to install and neglected to create the ESP. <mark_weaver>I don't have any UEFI machines, so I can't help with the specifics. <dtluna>Not good when there is magic involved <mark_weaver>well, that's grub's department. if there's magic that you don't like, complain to them :) <mark_weaver>(grub-install *does* seem to autodetect UEFI and figure out which partition is the ESP without being told) <dtluna>In GuixSD you have to specify the boot device when grub doesn't need to <dtluna>>grub-install *does* seem to autodetect UEFI and figure out which partition is the ESP without being told <mark_weaver>well, I acknowledge that this is not my area of expertise, and I've got other things to do anyway, so I'll leave you to it. <mark_weaver>if you think we're going something wrong, please mail bug-guix@gnu.org about it <mark_weaver>dtluna: btw, you certainly need to tell grub which disk to install to, when you're not booted into that system already (e.g. when first installing a system) <dtluna>okay, I've added an entry as specified by ArchWiki, now let's try and boot into GuixSD <mark_weaver>oh, well, sure, for UEFI all you need to know is the ESP partition. <sankey>in GuixSD is there any tooling around setting up service? <sankey>e.g. in debian if i instal bitlbee, it will also install the init scripts and automatically enable them <davexunit>sankey: packages and services are different. <davexunit>there happens to be a bitlbee service available <davexunit>in Debian, the services come along with the packages and everything is stuffed into the global /usr, Guix doesn't have this restriction <davexunit>you can use the software without needing a systemwide service, and you add a systemwide service without having the software visible to the rest of the system <davexunit>we have far fewer services than packages, so you lucked out that someone already wrote a bitlbee service. :) <ng0>is roel here? I tagged the gparted patch from around may 2016 as work in progress but I wanted to know if it's still appropriate of if I should bump the thread <ng0>could be. i have no nicklist in my client <ng0>i'll leave a message <ng0>sneek: later tell roelj: If you have been working on gparted in may this year, is this still being worked on or should the email thread be bumped to attention again? <ng0>sneek: later tell catonano: the gnunet* errors looked like something upstream can help with in resolving, it can also be fixed in later versions of gnunet, which is why I recommend either the gnunet-devel mailinglist or directly the mantis (bugtracker) of gnunet. <sneek>Welcome back catonano, you have 1 message. <sneek>catonano, ng0 says: the gnunet* errors looked like something upstream can help with in resolving, it can also be fixed in later versions of gnunet, which is why I recommend either the gnunet-devel mailinglist or directly the mantis (bugtracker) of gnunet. <catonano>ng0: ok now I understand what the real cost of following their developmnet affort can be. But I didnß t know they have a dev mailing list. I could try <catonano>ng0: as for Mantis, I took a look. It's messy, I don't understand completely what I see. Maybe I'm too old to get used to new UIs <catern>does the hydra substitutes server have substitutes for source tarballs? <ng0>I would help if I could, but the thing is that currently - and in general - gnunet development is fast. a bug today is fixed tomorrow so to say. and if it's not fixed and you find it, patches are welcome to fix it <ng0>the developer mailinglist is low frequented, so it's not adding noise to subscribe :) <ng0>low frequented but still answered <ng0>especially not only the patch, but the failing package on hydra also <lfam>ng0: I'm getting to that patch soon :) <sneek>Welcome back lfam, you have 1 message. <sneek>lfam, ng0 says: never mind the email, i just checked the old updates and I still need to apply some of them to core-updates <bavier>ng0: we usually split up patches like that <ng0>in my view it was related.. change the prefix to add the package. but I'll send it again. thanks <bavier>they're certainly related, but not dependent on each other <lfam>sneek: later tell mark_weaver: Is it possible to start an evaluation of wip-python? It seems that most of the failed jobs are caused by failures of guile-2.0 and subversion. But, I can get subsitutes for those packages from wip-python, so I think the issues have been resolved. <lfam>ng0: Please resend your sparta-dsmc to guix-devel <bavier>ruby-puma fails its tests when boost is upgrade to 1.61.0, apparently because some of the test data is serialized differently