<civodul>the order is sometimes disconcerting <lfam>Right... but still there is no substitute :/ <lfam>I want to make a union of alsa packages. I'm wondering how to specify the mutiple outputs of alsa-plugins in the list of packages to pass to my alsa-union procedure <pkill9>i think there's a union build procedure now. as for specifying the output, I think you can just add it to the input like so: ("package" ,package "output") <pkill9>oh, there's a gexp procedure for create directory unions, not onje to create a pakcage union <lfam>I'm working with (guix build union) <lfam>But, it only uses the primary "out" output of alsa-plugins <lfam>It would be nice for the default to include all of them <sirgazil>I'm trying the system with core-updates now and so far things are working alright. No new bugs, except for some kind of button that I think is supposed to look like three vertical dots or square, but looks like a stain instead. <sirgazil>In the wifi configuration, in Region and language (after pressing the + button), it looks similar. <sirgazil>I'm hopping GNOME 3.34.2 fixes the gnome-shell leak. I'll keep testing this weekend. <sirgazil>Oh, GNOME Web icon looks weird. It seems as if they forgot to clip the land in the globe... ***jonsger1 is now known as jonsger
***catonano_ is now known as catonano
<guix-ci>Problem: Too many processes on hydra-guix-125 Problem started at 02:58:21 on 2020.04.25 <guix-ci>Problem: Too many processes running on hydra-guix-125 Problem started at 02:59:23 on 2020.04.25 <dsmith-work>Heya guix people. Was there any messages around 21:09 utc? Maybe to the bot? <apteryx>dsmith-work: yes, there was: 21:08:40 guix-ci | Problem: Too many processes on hydra-guix-125 Problem started at 02:58:21 on 2020.04.25 <apteryx>and 21:09:40 guix-ci | Problem: Too many processes running on hydra-guix-125 Problem started at 02:59:23 on │ catern <dsmith-work>Problem: Too many processes running on hydra-guix-125 Problem started at 02:59:23 on 2020.04.25 <guix-ci>Resolved: Too many processes running on hydra-guix-125 Problem has been resolved at 03:21:23 on 2020.04.25 <atw>dsmith-work: 02:38 and 02:59, I think? based on the <div>s id? <guix-ci>Resolved: Too many processes on hydra-guix-125 Problem has been resolved at 03:22:21 on 2020.04.25 <apteryx>raghavgururajan: no! But I saw mbakke requesting to try out core-updates, so hopefully core-updates will be integrated into master soon <apteryx>dsmith-work: thanks for working on that bot, or fixing whatever problem there was with hydra <apteryx>raghavgururajan: by the way, I noticed that liblinphone should have its tester binaries and data moved to another output; just the test data weights 11 MiB <dsmith-work>Problem: Too many processes running on hydra-guix-125 Problem started at 02:59:23 on 2020.04.25 <dsmith-work>Problem: Too many processes running on hydra-guix-125 Problem started at 02:59:23 on 2020.04.25 <sneek>civodul was in #guix 3 hours ago, saying: the order is sometimes disconcerting. <apteryx>raghavgururajan: ah, perhaps it was enabled following review, seeing all the dependencies were already satisfied. I think it's nice to have them around, given the package has no test suite. <dsmith-work>Problem: Too many processes running on hydra-guix-125 Problem started at 02:59:23 on 2020.04.25 <sneek>civodul was in #guix 4 hours ago, saying: the order is sometimes disconcerting. <dsmith-work>Problem: Too many processes running on hydra-guix-125 Problem started at 02:59:23 on 2020.04.25 <apteryx>eh, updatedb uses more than 2.5 GiB of RAM <apteryx>3 GiB. The memory is used by the find process it spawns. <apteryx>bah, terminated by earlyoom. seems a bug! <guix-ci>Problem: Too many processes on hydra-guix-105 Problem started at 06:11:44 on 2020.04.25 <guix-ci>Problem: Too many processes on hydra-guix-113 Problem started at 06:17:28 on 2020.04.25 <guix-ci>Resolved: Too many processes on hydra-guix-105 Problem has been resolved at 06:17:44 on 2020.04.25 <apteryx>dsmith-work: looks like the number of process is oscillating around the limit <guix-ci>Resolved: Too many processes on hydra-guix-113 Problem has been resolved at 06:21:28 on 2020.04.25 <apteryx>dsmith-work: also, is there a reason why the bot can't permanently stay connected instead of joining, messaging, then leaving? <emys>when I try to contribute patches for these, would you rather have two mails with patch for each package individually or one mail with both patches? <catonano>dsmith-work: did I change my nickname ? I didn't realize that <catonano>emys: I need an account in order to see your link <catonano>on the pylonsproject patch, on line 1726 <catonano>emys: there's a cr before the actual hash. I would leave the same formatting as before <catonano>it's a minor thing but some people appreciate uniformity in formatting <emys>no problem to preserve formatting <emys>now I only need to get git send-email to work .. *sigh* <guix-ci>Problem: Too many processes on hydra-guix-126 Problem started at 09:34:04 on 2020.04.25 <catonano>emys: that's not strictly necessary. You can attach your patches to an email message manually <guix-ci>Problem: Too many processes running on hydra-guix-126 Problem started at 09:35:06 on 2020.04.25 <catonano>emys: you can fight with git-sendmail later 🤷♂️️ <emys>catonano, yeah I know but I'd like to have that set up once and for all :) <emys>catonano, thanks for your help, patches are out via my normal email client now. <guix-ci>Resolved: Too many processes on hydra-guix-126 Problem has been resolved at 10:03:04 on 2020.04.25 <guix-ci>Resolved: Too many processes running on hydra-guix-126 Problem has been resolved at 10:03:06 on 2020.04.25 <emys>is guix-patches moderated? Wondering whether moderation approval is pending or whether there was a problem with my email ***wxie1 is now known as wxie
<ecbrown>emys: i seem to remember my first patch taking a while to appear, but subsequent patches were registered almost immediately <rekado_>…why does dsmith-work speak like guix-ci? <rekado_>sneek: later tell vagrantc no, hydra-guix-* is the name of those build nodes behind ci.guix.gnu.org that are hosted at the MDC <PotentialUser-91>Has anyone setup guix with StumpWM and if so is he willing to share config files? <dissoc3>PotentialUser-91: i got stumpwm to work but i dont really know what im doing <dissoc3>i just added stumpwm to packages in /etc/config.scm <ecbrown>i wonder if i've gotten "off the rails" with my package manager. i'm guix pull'ing from master, e.g. substitutes seem available, but guix pull && guix package -u seems to be rebuilding everything from source. (it does work as expected, though.) <ecbrown>(this machine is running 5.6.7 with non-free radeon) <ecbrown>odd my very similar laptop (without the radeon) finds substitutes just fine <ecbrown>full disclosure: i did visit the core-updates branch, but coming back to master <leoprikler>ecbrown: even on master substitutes are not always available on fresh `guix pull`s <leoprikler>the non-free stuff also has no substitutes anyway <ecbrown>sure, just annoyed at having to compile all the rust's <ecbrown>maybe it will be back on track once this particular update completes <dsmith-work>rekado_: I was using that as a test input to the bot. For some reason, it was freaking out on it. <janneke>is there anything i can do except start guessing and adding print statements? <dsmith-work>apteryx: The the bot is joining/leaving all the time becuse I'm starting it. <cbaines>janneke, in my limited experience at least, you have to avoid Guile evaluating code on the fly, as that seems to get it thinking that all errors occur in the evaluator <cbaines>assuming you've run make to generate the .go files for Guix, I guess that error is occuring when evaluating the bare-hurd.tmpl file <janneke>cbaines: thanks, at least that helps to change my perspective on it -- hmm <janneke>it's definately related to my bare-hurd effort -- ... but where :-) <janneke>i'll see if i can somehow process/invoke/run smaller chunks of the opaque guix system call <cbaines>it does seem odd to have an interpreted language (Guile), where the first rule is to avoid interpreting code at runtime, as it means the stack traces are unintelligible! <cbaines>janneke, have you tried just running the bare-hurd.tmpl file with Guile? <janneke>that works...adding PK to the resulting os <janneke>ah, bootloader #f -- i'm running with --no-bootloader, but forgot about that <reepca`>so today I learned that there are two completely different software projects called "libtorrent", both providing similar features and used by similar programs. And neither is a fork of the other AFAIK. I only found this out at the bottom of a github wiki page after 30 minutes of confused searching. *reepca` gained a newfound respect for projects renaming to avoid confusion <stikonas_>well, gentoo calls one package libtorrent-rasterbar and the other libtorrent ***stikonas_ is now known as stikonas
*ecbrown memorializes in search engines: guix offload problem? make sure user on remote machine is not using non-default shell, e.g. not using zsh. create another user for offload build <rekado_>ecbrown: does “guix offload” print a good error message in that case? If not, could you please submit a bug report? <ecbrown>rekado_: happy to do so. it's a bit of a cryptic message <dlowe>if I guix install guile3.0-guix will it work? <cbaines>dlowe, that's only really useful if you're using guix as a Guile library <cbaines>(well, or if you have a package that depends on guix) *ecbrown busts out the second t420 in order to confirm gnome wifi connection password bug in core-updates <ecbrown>i accumulate t420's at the earth day dumpster <ecbrown>it's a shame they require non-free firmware for wifi <Bronzu>Hi, I'm having issues running wayland. <Bronzu>Couldnt find active session or greeter session <Bronzu>cannot become drm master, do not have cap_sys_admin <rekado_>tried to upgrade R, but there are new reproducibility problems :( <Bronzu>Well I don't... I'm trying to get sway working. <Bronzu>I don't even have any graphical ui installed (guess im regretting that now huh) <guix-vits>Bronzu: `sudo herd status |grep login` -- elogind? <Bronzu>nothing, guess I'll have to start a service? <rekado_>Bronzu: are you trying to start it via gdm? AFAIU you should just start sway without gdm. <rekado_>(I’m guessing based on you mentioning “greeter”) <guix-vits>Bronzu: elogind should be in your sys. config, i think; do you've the %desktop-services, or the %base-services? <Bronzu>In config.scm i have base services <rekado_>yeah, don’t install it into your user profile and run it from there. You’ll need the service. <Bronzu>I did include it in services but herd still says it cant find it ***benny is now known as Guest80763
<mbakke>Bronzu: did you reconfigure after adding (elogind-service) to your config? <mbakke>Bronzu: the SDDM display manager is able to find and start Sway *jonsger builds thunderbird yet another time :P <civodul>jonsger: oh you have a Thunderbird package? <jonsger>civodul: reviving some old patches (not from me). I think I'll send a first version the next days <TZander>yeah, lots of unfinished packaging on the bug-tracker. *ecbrown makes plug for sypheed patch, another gui email program <mbakke>I want to use (package-with-relocatable-glibc ...) outside of (gnu packages make-bootstrap), but can't make up my mind whether to just export it, or move the relevant procedures to a new module (where?). Ideas? <mbakke>exporting is suboptimal, because I want to use it in one of the modules imported by (gnu packages make-bootstrap), creating a circular dependency <TZander>bootstrap stuff we typically just include in C++, which effectively means create two compiled copies. Even if the sources only exist once <TZander>probably best to not change the main app design too much to adjust for singular exceptions like this <kraai>Hi. I'm using GNOME. When I try to start Geary by selecting Activities > Show Applications > Geary, it doesn't appear. If I run geary in a terminal, it does. Does anyone know how to fix or investigate this? <mroh>where can I put .patch files in a channel, so that (package (source (origin (patches (search-patches)))) finds them? *kmicu ಠ_ಠ at new Nix(OS) Marketing Team. <mbakke>mroh: if your channel uses namespace (foo packages), with a subdirectory "patches", using (search-patches "foo/packages/patches/bar.patch") should work <cbaines>kraai, first you need to find out what the GNOME Shell is trying to launch. Do you have a file for Geary in ~/.guix-profile/share/applications ? <cbaines>I wonder what the costs are of using grafts without substitutes are...? I think I'm seeing some wierd behaviour when I don't have a source of substitutes. Guix builds some seemingly unnecessary stuff, and I think it might just be to figure out something about grafts. If I disable grafts, it doesn't think anything needs building... <emys>Trying to package some more python modules I get the following error: "ValueError: Unable to create the compiledir directory '/homeless-shelter/.theano/...". <emys>it seems homeless-shelter is a sandbox $HOME by guix <cbaines>No, but I don't think it exists in the build environment <cbaines>This is helpful to highlight when packages expect it to be there <cbaines>It seems wrong to me for a python module to be trying to use a users home directory when building/installing... <emys>cbaines, it seems wrong to me, too, it is not my module though. <cbaines>To work around wrong things like this, you can do thinks like (setenv "HOME" "/tmp") <emys>cbaines, I already did, I just put it into the wrong package definition and didn't realize why it had no effect <kmicu>(FYI homeless-shelter is a thing inherited from Nix.) ***Intensity4 is now known as Intensity
*kmicu would prefer a descriptive term like mathy ‘imaginary-directory’ more than a confusing pun 😺 <kmicu>(even ‘impurity-detected’ should be more helpful) <catonano>cbaines: as for grafting inducing (apparently) pointless building, that's a debuggign problem. It's be important to see exactly how it visits the graph of packages and how it decides to build things. It's a tooling problem <catonano>I not this because tooling insufficiencies usually impress me <kraai>cbaines: There's a geary-autostart.desktop in ~/.guix-profile/share/applications. <kraai>cbaines: There's also an org.gnome.Geary.desktop there. <cbaines>kraai, I guess you could look in the org.gnome.Geary.desktop one? <cbaines>I'm not sure how to launch a .desktop file from the command line... <kraai>cbaines: There are two sections in that file, [Desktop Entry] and [Desktop Entry Compose]. <kraai>The Exec line in the Desktop Entry section is /gnu/store/x97linxpzknsjaypy7x3i6r078agb67j-geary-3.34.1/bin/geary %U. <kraai>According to the spec, it looks like the %U should be stripped if no URL is specified. <efraim>datefudge failed to build for me on core-updates (on powerpc) <efraim>nvm, it seems to be a conflict with glibc-2.30 <guix-ci>Problem: Too many processes on Zabbix server Problem started at 21:21:12 on 2020.04.25 <guix-ci>Resolved: Too many processes on Zabbix server Problem has been resolved at 21:24:12 on 2020.04.25 <civodul>mbakke: package-with-relocatable-glibc could be in (gnu packages base), next to glibc <civodul>you sure you want to use it though? :-) <sirmacik>does anyone have working config.scm with current kernel and wireguard? <mihi>is there a branch that is more stable to do so? <mihi>also, I guess it is normal that after updating from git I always have to run make before pre-inst-env guix build is able to give it another shot? <vagrantc>mihi: it will usually produce some warnings about, but it should work as long as you haven't run "guix gc" clearing out the version that was used to run the initial make <sneek>Welcome back vagrantc, you have 1 message! <sneek>vagrantc, rekado_ says: no, hydra-guix-* is the name of those build nodes behind ci.guix.gnu.org that are hosted at the MDC <mbakke>civodul: I needed package-with-relocatable-glibc to create a 'guile-static@3.0' for the initrd... I think I have it working now, will clean up and submit the patches tomorrow. :-) <mbakke>I first tried without it, but the initrd failed to look up 'getpw'. <seepel>Hi guix! I'm trying to figure out how to compile a rust project I found on github, but I cannot for the life of me figure out how to get cargo in my path. <raghavgururajan>sneek, later tell lfam: Any update regarding #40659 (v3) please? Thanks! <raghavgururajan> sneek, later ask civodul: Would you be able to push #40785 please? This is regarding `guix edit` and nano. Thanks! <vagrantc>anyone else seeing some alarming messages during boot on core-updates? <vagrantc>things like: WARNING: (#{ g115}#): imported module (guix build utils) overrides core binding `delete' <vagrantc>;;; ERROR: In procedure make_objcode_from_file: bad header on object file: "\x7fELF\x02\x01\x01ÿ\x00\x00\x00\x00\x00\x00\x00\x00" <vagrantc>(more-or-less similar, at least, only have details for aarch64) <jackhill>vagrantc: yes, I think I saw those, but they scrolled fo the screen before I could read them. <rekado_>the second one looks like a mismatch in Guile versions <rekado_>the warning is new with Guile 3, I think <vagrantc>i guess i could comment on the thread with a little more detail? 