<guix-ci>Problem: Free disk space is less than 10% on volume /gnu/store Problem started at 23:49:17 on 2020.04.26 <joshuaBPMan>does anybody know how to compile a package with a newer version of meson? <joshuaBPMan>The manual says it's possible, but I'm not certain how to do it. <joshuaBPMan>This is what I have, and "make" is not letting it compile <guix-ci>Problem: Free disk space is less than 10% on volume / Problem started at 00:01:28 on 2020.04.27 <guix-ci>Problem: Free disk space is less than 10% on volume /gnu/store Problem started at 00:01:29 on 2020.04.27 <leoprikler>try adding #:meson my-updated-meson to the arguments <pkill9>is it possible to prioritise network traffic both uploading and donwloading depending on the application? without using bandwidth limits <leoprikler>you could very likely come up with a scheme, that effectively ends in "smart bandwidth limits", but I doubt it'd have much effect further up in routing <malaclyps>is there a command to check whether a substitute is available for a given package? <malaclyps>thank you! i didn't realise it worked for individual packages! <malaclyps>i'm having problems building libreoffice at the moment -- the vigra dependency is actually completely crashing my machine during its build. Is there a way I can check whether that's happening on the Guix build servers too? Like, look at the build logs for a package there? <lfam>malaclyps: The build timed out on the CI servers <lfam>What kind of computer are you using malaclyps? <lfam>Is it really crashing the computer, or just making it really slow? <lfam>You may want to limit the number of cores it can use, and increase the timeout and max-silent-time parameters <lfam>(Those are parameters of the guix-daemon) <leoprikler>I'd also throw in the suggestion of pinning libreoffice via manifest <leoprikler>That's a huge package that requires loads of rebuilds while rarely changing itself. <lfam>I use an x230 and I can build vigra, but it does take a long time *jonsger has sent his review of the YouTube review to guix-devel :P <KE0VVT>jonsger: review of review? can i see both? <guix-ci>Problem: Free disk space is less than 10% on volume / Problem started at 00:24:52 on 2020.04.27 <malaclyps>lfam, well, it froze the mouse and i couldn't alt-ctrl-F1 to a console -- on the other hand, I've had problems with the OOM-killer picking bad targets during a Guix build on this, so limiting cores might help anyway <guix-ci>Problem: Free disk space is less than 10% on volume /gnu/store Problem started at 00:24:53 on 2020.04.27 <joshuaBPMan>To those who were curious: (arguments `(#:meson ,meson-0.51.2 fixed it. <joshuaBPMan>Guix now can build the latest version of wlroots! Sweet. <guix-ci>Problem: Free disk space is less than 10% on volume /gnu/store Problem started at 00:28:05 on 2020.04.27 <lfam>malaclyps: On the CI server, the build fails due to timing out. In your case it's probably a resource exhaustion problem <KE0VVT>jonsger: thanks, although my german isnt good <guix-ci>Problem: Free disk space is less than 10% on volume / Problem started at 00:29:04 on 2020.04.27 <malaclyps>sounds like the CI server is having a few exhausted resources itself <lfam>malaclyps: No, it just times out after 1 hour of silence, which is normal. It's not actually out of memory or anything <lfam>I reported a bug about this <lfam>It's tricky but we need to solve it. In the meantime I would try again, making sure you have a few gigabytes of memory available, that you are building on a filesystem that is not too small (again, several gigabytes) or slow (use ext4 or xfs) <lfam>Another option for the builder filesystem is tmpfs, that is really fast <lfam>It's quite slow for this kind of thing <lfam>A lot of distros set up a really small /tmp and then we run out of space while building <lfam>Your computer should be more than fast enough to avoid timing out but if you are concerned, you can set the timeout and max-silent-time arguments of the guix-daemon <malaclyps>lfam, sorry i was just referring to the "guix-ci" messages in this channel. <malaclyps>thank you very much for filing the bug -- it gives me a template to do the same in the future <malaclyps>in general, if a build crashes, what's the easiest way to find the log after the event? <leoprikler>is there a reason Guix System does not already have tmpfs /tmp? <str1ngs>malaclyps oh you just want the build log. it will say when the build fails <reepca>malaclyps: you can also use 'guix build --log-file' <lfam>leoprikler: I don't know... does it not? <lfam>leoprikler: Room for improvement! <guix-ci>Problem: Free disk space is less than 10% on volume / Problem started at 01:03:16 on 2020.04.27 <guix-ci>Problem: Free disk space is less than 10% on volume /gnu/store Problem started at 01:03:17 on 2020.04.27 <rekado>nothing to worry about. We still have 45G on / and 7.2T on /gnu <guix-ci>Problem: Free disk space is less than 10% on volume / Problem started at 01:31:41 on 2020.04.27 <guix-ci>Problem: Free disk space is less than 10% on volume /gnu/store Problem started at 01:32:41 on 2020.04.27 <guix-ci>Problem: Free disk space is less than 10% on volume / Problem started at 01:55:52 on 2020.04.27 <guix-ci>Problem: Free disk space is less than 10% on volume /gnu/store Problem started at 01:55:53 on 2020.04.27 <raghavgururajan>lfam Hmm. I agree it is not good idea to propagate icons. But here it is not propagated. It is just like any other required run-time dependecy added as input. :-) <lfam>raghavgururajan: A purely run-time dependency doesn't need to be added in the package definition. Your change makes it a build-time dependency, so that any changes to the icons mean that transmission needs to be recompiled. I don't think that transmission or any other package needs to be recompiled because the icons changed <vagrantc>it sure would be nice if there were a proper way to document what icons a package needs <raghavgururajan>Hmm. How is that different from any other input being changed? Like changes in python also gonna trigger rebuild. <lfam>But, those are functional changes, to code. Icons are just pictures <raghavgururajan>But the probability of those changes are gonna be more or less same. <raghavgururajan>The frequency of changes happening to icon package and any other package. <lfam>It's not about frequency. It's about whether or not the change impacts the function of the software. <lfam>Right, but it also requires fonts, and we don't add those as a dependency. Similarly, we ask the user to install fonts. <lfam>Because, there is no functional relationship between the icons or fonts and the applicatoin <reepca>if by "function of the software" we mean "what the software does", then technically the presence or absence of icons does affect the function - part of the software's job is to present those to the user. But I think I'm nitpicking there. <lfam>Right, but we've always expected users to install the icons on their own. I agree that you can't use the GUI without icons <reepca>I actually never knew that I needed to install any icons, so I never did <lfam>Interesting... did you ever miss any icons in GUIs? <reepca>sometimes. Stuff like emacs and icecat is fine, but for example I fired up transmission the other day and it was all missing-icon symbols <raghavgururajan>I get the point. What I am saying is, it is one less job to install icons/fonts separately. <raghavgururajan>Unless, it has to be propagated. Then the rationale woule be poluting profile. <lfam>If anything, the packages that currently include icons as dependencies should be changed to remove those dependencies <lfam>On Guix System we can provide the icons at the system level, and on foreign distros add a note to the manual reminding users to install icons <raghavgururajan>My thought is: If icon/font can be added as input, let's do it. It's one less job to find the right icon/package and installing it explicitly. But if a package requires icon/font to be propagated, let's NOT do it. As it will pollute profiles. <lfam>I don't think anyone is talking about propagating icons or fonts <lfam>And we should definitely not add fonts as package inputs <raghavgururajan>Also, let's do the former, only if an icon/font is hard-coded. So there is no choice for user anyway to try different icon/font. <reepca>in general it'd be nice if there was a way for a package to specify that it depends on some category of runtime packages, if only to be able to present that to the user so that they know other stuff needs to be installed for full operation <raghavgururajan>Why not, If the application is hard-coded to look for specific icon/font, why not add as input. Not gonna have any downsides. Just one less job. <lfam>It doesn't matter that Transmission only uses adwaita. We should not put adwaita as a dependency of transmission. Transmission does not need to depend on it directly <lfam>Non-functional packages (icons and fonts) should not be coupled to packages <raghavgururajan>IN FACT, I prefer the idea that non-functional packages (icons/fonts) should not be made as dependency, and should be included as part of source code. But, here transmission does that. May be we can suggest it upstream. Until then, we can add as input? <lfam>raghavgururajan: That's not what I suggested. Icons should not be included as part of source code. They should be provided in the environment -- that is, by installing them. <lfam>I replied in the bug thread. I have to go AFK <raghavgururajan>lfam Okay. That assuming icons are provided by another package. I was referring to ideal situation, where application uses it's own unique icons. <apteryx>lfam: do you know how icons are referred to? Is it true that some packages can *only* use a specific icon theme? Couldn't another theme provide same named icons and be compatible with that theme? <raghavgururajan>apteryx I do two things.1) Look at source for hard-coded names 2) Try with another icons installed. <raghavgururajan>By another, I mean, couple of widely used icons. Not just one another. :-) ***jonsger1 is now known as jonsger
<raghavgururajan>jonsger A while back, you were talking about Icedove? What's the matter? <schaeffer>hello! i'm trying out guix right now on a fresh VM and want to install icecat from a substitute, but `guix install icecat` still installs rust (among other things) and attempts to build icecat. `guix weather icecat` turns up a 504 from the CI server API; am i doing something wrong? <apteryx>raghavgururajan: OK. But the hicolor theme is the default fallback on all X-based desktops, so I after some thinking and reading lfam's comments here I reckon it should be removed from liblinphone's inputs. ***catonano_ is now known as catonano
<raghavgururajan>apteryx But it only works on GTK+2. GTK+ 3 does not fall-back to hicolor. Eventhough, it says in the error output. <guix-ci>Resolved: Free disk space is less than 10% on volume / Problem has been resolved at 02:51:40 on 2020.04.27 <guix-ci>Resolved: Free disk space is less than 10% on volume /gnu/store Problem has been resolved at 02:51:41 on 2020.04.27 <mroh>maybe a new field like "suggested packages" in the package definition would be nice (debian has suggested and recommented). that way transmission could recomment the theme (to the user). <guix-ci>Resolved: Free disk space is less than 10% on volume / Problem has been resolved at 02:51:52 on 2020.04.27 <guix-ci>Resolved: Free disk space is less than 10% on volume /gnu/store Problem has been resolved at 02:51:53 on 2020.04.27 <guix-ci>Resolved: Free disk space is less than 10% on volume / Problem has been resolved at 02:51:52 on 2020.04.27 <guix-ci>Resolved: Free disk space is less than 10% on volume /gnu/store Problem has been resolved at 02:51:53 on 2020.04.27 <guix-ci>Resolved: Free disk space is less than 10% on volume / Problem has been resolved at 02:52:04 on 2020.04.27 <guix-ci>Resolved: Free disk space is less than 10% on volume /gnu/store Problem has been resolved at 02:52:05 on 2020.04.27 <guix-ci>Resolved: Free disk space is less than 10% on volume / Problem has been resolved at 02:52:16 on 2020.04.27 <jfred[m]>heheh wonder if that has something to do with those 504s from the CI API <guix-ci>Resolved: Free disk space is less than 10% on volume /gnu/store Problem has been resolved at 02:52:17 on 2020.04.27 <mroh>schaeffer: no, you arent doing something wrong, icecat substitution isnt on ci (yet) <guix-ci>Resolved: Free disk space is less than 10% on volume / Problem has been resolved at 02:52:28 on 2020.04.27 <guix-ci>Resolved: Free disk space is less than 10% on volume /gnu/store Problem has been resolved at 02:52:29 on 2020.04.27 <guix-ci>Resolved: Free disk space is less than 10% on volume / Problem has been resolved at 02:55:16 on 2020.04.27 *raghavgururajan wonders why qt-based application never throws up error regarding icons. <guix-ci>Resolved: Free disk space is less than 10% on volume /gnu/store Problem has been resolved at 02:55:17 on 2020.04.27 *raghavgururajan thinks may be qt has more standarized icons than gtk. <mroh>raghavgururajan: try `export QT_LOGGING_RULES="*.debug=true"` <schaeffer>mroh: got it. i'll just start building it now then <ryanprior>How come there's no electron apps in guix? I tried web searching and didn't see much on the subject. <jfred[m]>ryanprior: I think generally because to package electron apps you'd need to package all of their dependencies, and that's... a challenge for most of them <jfred[m]>Guix is very strict about all package dependencies themselves being in Guix <raghavgururajan>apteryx I am afraid gtk+3 is not hornoring those specs. :( . That is bad. I do think it is logical to have consistent fall-back icon/font across GUI applications. <pkill9>do any other distributions actually build electron from source? <ryanprior>Right, that makes sense. Are there certain dependencies which are not possible to build in guix? Or is it just a matter of being a lot of work? <pkill9>i think everyone depends on prebuilt binaries <pkill9>i think there are hundreds of dependencies <jfred[m]>Right, my suspicion is just that it's a lot of work. My experience with electron apps is that having hundreds to thousands of dependencies is the norm <mrwater>pkill9: Pretty sure Gentoo builds electron from source <schaeffer>silly question: does anyone in here run emacs as a daemon on guix? if so, what's your setup? i use a systemd service on my arch box, so something similar in guix would be great <jfred[m]>an npm importer could maybe start to make it feasible, but it'd have to be pretty good - you don't want to have to dig through 1000 dependencies by hand <pkill9>even sisyphus wouldn't want to package electron <mrwater>schaeffer: I don't know about guix, but it does have an init system, so it should be manageable to write a service that runs emacs as a daemon <jfred[m]>fwiw I don't believe there are any electron apps in debian either, probably for the same reason *raghavgururajan adds hicolor-icon-theme to system-wide packages <raghavgururajan>apteryx Let's remove icon as input for liblinphone. Since it's gtk+2, it is honoring the specs. <schaeffer>mrwater: right, i'm still trying to feel out the difference between a service that the system runs for the whole system and a service that runs on, say, my user logging in <str1ngs>schaeffer: for emacs a user services makes more sense you can create when in ~/.config/shepherd/init.scm for <mrwater>schaeffer: Essentially, a daemon can be run by any user, but an init system like systemd ensures that the daemon runs at startup and handles what happens if there is an interruption, etc. <jfred[m]>yeah, I think it'd be interesting to see guix's concept of a "service" extended to user-level services, but for now to my knowledge the best option is to run another instance of shepherd as your user <mrwater>And if my init system has the ability to run user services from .config I'm unaware, so that's pretty legit <jfred[m]>(guix services being more flexible than just shepherd services) <mrwater>I just run emacs --daemon in my .xinitrc and a command to kill it in my .bash_logout <jfred[m]>anyway, for electron apps that I absolutely need I've been installing them via flatpak, though of course I prefer software natively in guix whenever possible <arpunk>jfred[m]: I was looking for a way to extend shepherd to run my user-defined services, thanks for the tip <ryanprior>Yeah that makes sense, I've been using flatpak for that too. <ryanprior>There's Electrino, of which "the plan is to examine API usage of real-world apps that use Electron but don't really need the full capabilities" and build a minimal Electron-like framework that can accommodate them. <raghavgururajan>apteryx Hmm. Then, the application is not honoring. If you try gtk+3 based apps like pavucontrol, transmission etc. Having hicolor installed does not work. I tried. <ryanprior>It might be less work for some free electron apps to port them to electrino than it would be to create an electron-build-system in guix X.X <jfred[m]>The issue is less with electron itself and more with the enormous amount of dependencies that most apps written for it have <jfred[m]>(Though electron itself may be tricky to package as well) <mrwater>I never ran into an electron app that wasn't sufficiently replaced with midori running in... I think it's called "app mode" or something? <ryanprior>Free software, depends on electron and libcurl (so can't run in Midori) <jfred[m]>vendoring would do the trick but I think it's pretty frowned-upon - might be something to ask about in guix-devel though <ryanprior>npm made the experience of creating, uploading, and consuming a package so streamlined that it carries little cost <jfred[m]>that's more of a policy question than a technical one <mrwater>Maybe use docker? That's my pie in the sky plan if I switch to guix and can't do something x) <apteryx>raghavgururajan: interesting. Thanks for sharing. <jfred[m]>yeah, which unfortunately means it doesn't play so nice with the traditional distro packaging model <ryanprior>that's the narrative I get from what I hear from y'all <ryanprior>Oh I definitely use Docker, Flatpak, etc. So my needs are taken care of for now- I'm asking so that I understand the issues better :) *apteryx mistakingly type 'k' <lafrenierejm>Anyone available to debug a texlive recipe? I'm getting an "In procedure copy-file: Is a directory" error, despite using copy-recursively in my recipe... <lafrenierejm>Does anyone have an example shepherd init.scm they'd be willing to share? I'm getting a "wrong type" error and I'm not sure why. <rekado_>schaeffer, jfred[m] The 504 comes from cuirass being rather slow when asking for a large number of builds. <rekado_>the guix-ci messages are for sysadmins ***guix-vits is now known as TvCvRuy007
<TvCvRuy007>apteryx: `(string-append (getenv "HOME")`: is it works? Are user-services good on shepherd? <lafrenierejm>It seems that my problem was fixed by just passing `--config=$HOME/.config/shepherd/init.scm`. Any ideas why that would be? <apteryx>TvCvRuy007: yes it works, I'm using it. <apteryx>Although, it's uncessary since recently to specify the pinentry program's exact path. As long as it's present in your default profile (~/.guix-profile), it should work. <TvCvRuy007>lafrenierejm: if you run emacs-daemon, steel start some-things (like Geiser) inside of a separate instantion. So some experimentation will not froze your ERC. <apteryx>TvCvRuy007: I regularly do 'herd restart emacs' because of Geiser ;-) <apteryx>raghavgururajan: I've pushed a couple clean-up patches against liblinphone <apteryx>I've added output splitting doing so, so you don't need worry about that one. <apteryx>I've noticed the tester is pretty useless for liblinphone. It tries connecting to an actual SIP server that doesn't exist (you'd have to setup the same thing as what Belledone must be using). <apteryx>but I haven't explored all the test suites available, perhaps some could be useful, I don't know. <emys>hi, can I export my current guix profile (~/.guix-profile) into a manifest file or something? <sneek>Welcome back emys, you have 1 message! <sneek>emys, catonano says: did you manage to get your patches through ? <emys>catonano, yes, I did get them through <emys>catonano, patches made their way <emys>I would be especially interested in user-level services <akoppela>Could you please help me to improve my Guix experience. I'm located in Indonesia and for some reason it's verys slow to download from ci.guix.gnu.org. <akoppela>And another issue I don't understand is why each time I run "guix package --manifest" it redownloads and rebuilds everything. Even if manifest didn't change. <efraim>akoppela: Currently there aren't mirrors available, the substitutes come from the build farm in Berlin. There is work to create a mirror in China but IIRC it's still ongoing. <efraim>the installed packages can change if one of the dependencies change, not just if the manifest of installed packages or an installed package changes. <efraim>also, make sure you don't have 'guix' installed. If you do you'll run into a bug where that guix binary is used and each time you upgrade your packages you'l actually downgrade everything to an older version. <CRCRCRCR>I am going to replace my cloud server with Guix. I want to use the initramfs of the ssh server (I can already do this because I packaged the initramfs myself), and then install Guix from the initramfs. I make a busybox rootfs on the installation target disk Then put in Guix, and then chroot in to execute guix system init, so can it be successfully installed? <efraim>arch was going to be my next stop <efraim>what if you just rename install.py to setup.py? <raghavgururajan>Would trivial build system work? I could just add python modules and invoke install.py. <akoppela>efraim: Thanks. I do have "guix" installed as package and notice version downgrades. <efraim>raghavgururajan: I think I would stick with python-build-system and just use cusom phases for 'configure (if there is), 'build, 'check and 'install. It makes it easier to deal with PYTHONPATH <slaasl_>error: failed to run download program '/gnu/store/p7jcjqcaw66g05zjim0famggfwpna8k0-guile3.0-guix-1.1.0/bin/guix': Permission denied <raghavgururajan>efraim I see. I not sure what should I modify the phases to. I'll figure something out. Thanks! <efraim>(invoke "python" "install.py" (string-append "--prefix" ... <akoppela>Another issue I'm facing is "minimal-5.0.7/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)". <akoppela>There was another message about locales and it's gone after "glibc-locales" package installation. But not the other one. <akoppela>Should I install "glibc-locales" under root user? <slaasl_>you only need install glibc-utf8-locales. ***ramajd_ is now known as ramajd
<fishinthecalcula>Hello Guixers! Does somebody have any idea why if I just add "#use-module (guix glob)" to "guix/build/node-build-system.scm" I get "No code found for module (guix glob)" https://paste.debian.net/1143283/ ? I'm working on a local Guix checkout to try and fix bug 40710, but to do it I need a working glob implementation accessible from guix/build/node-build-system.scm. Any pointers? Thanks a lot :D <cbaines>fishinthecalcula, it'll probably be to do with %node-build-system-modules in (guix build-system node) <rekado_>fishinthecalcula: is guix/glob.scm on your Guile load path? <rekado_>oh, sorry, didn’t realize it’s part of Guix <rekado_>everything under guix/build/ is build-side code <fishinthecalcula>cbaines: Is that a list of modules to be made available to node-build-system? I'll check that out right away <cbaines>there are also another set of modules listed in the arguments to node-build in (guix build-system node), and you might want to add it there too <sneek>Welcome back janneke, you have 1 message! <sneek>janneke, raghavgururajan says: I have replied to the spacefm thread. <akoppela>Installing "glibc-utf-locales" under root fixed the issue with locales. <janneke>raghavgururajan: yes, sadly i did not really understand your response: it still does not work for me <janneke>raghavgururajan: also KTSUSS does not work for me; i'm afraid it has a similar error <raghavgururajan>janneke Sorry, I forgot mention that you have to manually set sudo program in preferences. Without the patch, options with correct path will not appear as option. <efraim>IMO it should work out-of-the-box on Guix System and then let people using Guix on a foreign distro set their own sudo path <janneke>raghavgururajan: and that works for you without calling with: -c .../etc/spacefm ? <raghavgururajan>janneke No /etc/spacefm has to be modified so that correct path appears in option. This is what the patch does. <raghavgururajan>efraim Yes, that is the idea. I am patching spacefm.conf for guix system. <janneke>raghavgururajan: this helps...but i suspect that spacefm does not read .../etc/spacefm/spacefm.conf unless I use the -C option <raghavgururajan>janneke I think I know what the issue with ktsuss. I should have used /suid-programs/sudo in that package as well. <raghavgururajan>Thanks for pointing it out. I assumed things were woking fine when I saw the popup. <janneke>so users still need to manully select the correct entry, that's sad :-( <janneke>i am really not a gui program user; i didn't guess this, so that's why i started playing with the -c ... option <raghavgururajan>janneke Yeah. I planned to remove all other entries, so that only one option with correct path is available. That will used by default, without manually needing to change it. I will do this later. <janneke>raghavgururajan: yes, please take some time to do this right <raghavgururajan>janneke How do programs like sudo appear under /run/suid-programs/? Is it possible make any other program to run with suid set? <bricewge>raghavgururajan: Check out setuid-program-service-type <raghavgururajan>So how a program running with suid set as root, different from running that program as 'sudo program'? <xelxebar>raghavgururajan: No problem :) If you want to know what %setuid-programs contains, you can open a "guix repl", issue ",use (gnu system)" at the prompt, followed by "%setuid-programs" <guix-ci>Problem: Too many processes on hydra-guix-126 Problem started at 11:09:04 on 2020.04.27 <guix-ci>Problem: Too many processes running on hydra-guix-126 Problem started at 11:11:06 on 2020.04.27 <guix-ci>Resolved: Too many processes running on hydra-guix-126 Problem has been resolved at 11:14:06 on 2020.04.27 <guix-ci>Resolved: Too many processes on hydra-guix-126 Problem has been resolved at 11:16:04 on 2020.04.27 <xelxebar>raghavgururajan: That's a good question. Setuid is a Linux kernel mechanism (standardized in POSIX) that lets some user run an executable with the permissions of the executable's owner. Sudo, in a sense, is a wrapper around this. Sudo needs to be setuid root to work properly. <xelxebar>As it turns out, %setuid-programs essentially looks like '(passwd su newuidmap newgidmap ping ping6 sudo sudoedit fusermout mount umount) <jonsger>raghavgururajan: I'm still working on an Icedove patch. Will sent it soon <bricewge>How to deal with package without release in git? <mothacehe>bricewge: You can use the commit of your choice and set a 0.0.0 version. <raghavgururajan>bricewge I usually select a functionally good commit and put it's date as version. For example, 2020.02.18 <janneke>mothacehe: wip-disk-image looks tempting, how do i get started? <janneke>i'm trying to move our hurd efforts from the custom: guix build -f gnu/system/hurd.scm (which creates a qemu-image) to guix system vm-image --target=i586-pc-gnu <bricewge>raghavgururajan: That was what I was going for, but if a release is going to be made doesn't it'll be perceived as a reversion. Like from 2020.02.18 to 1.0.0? <mothacehe>janneke: great! For now wip-disk-image only supports the disk-image argument of guix system, i.e, production of raw disk-images and iso9660 images. <raghavgururajan>bricewge I think the version can be changed according to release later. IIRC, youtube-dl also follow this date method. <efraim>youtube-dl chose this as their release/tag name. If there are no tags to start from then we start counting from 0.0.0 <efraim>I sometimes put a date in a comment next to the commit chosen so I know offhand which date it was from <raghavgururajan>bricewge I don't think it can be percived as reversion, as commit field also change, along with version field. <raghavgururajan>efraim What if the upstream git source never makes release? Like a rolling model. <efraim>raghavgururajan: take a look at cuirass <bricewge>raghavgururajan: That's the case with edid-decode <mothacehe>janneke: I'll have a look to gnu/system/hurd.scm to see how it could fit :) <janneke>mothacehe: is disk-image also available though the command-line yet? <mothacehe>janneke: Yes, currently `guix system disk-image my-os' produces a raw disk-image and `guix system disk-image --file-system-type=iso9660 my-os' produces an ISO. *janneke read "image-with-os" ... nice <mothacehe>heh, I'm annoyed by partition from srfi-1, which is different from (gnu image)'s partition, but turns out I need both in that function :p *janneke finds "Add iso support." that patches scripts/system :-) <janneke>so much easier to find with a little help! <jlicht>hey folks, I remember some very hand-wavy talk about having a guix service for _using_ guix-generated docker images in your operating system declaration. So a guix system inside a guix system if you will :-) <efraim>oh no! test failure for vim on powerpc! <akoppela>I'm using Guix on top of Debian. I installed `nginx` package with guix. What is the best way to run it? <dutchie>i suppose create a service file that references $HOME/.guix-profile/bin/nginx <dutchie>systemd, so that the host os knows about it <dutchie>i'm not sure where the guix-provided nginx will look for its configuration files though <akoppela>when I run `nginx -s reload` it looks inside /gnu/store <mbakke>akoppela: it's terrible, but you need something along the lines of "nginx -s -g 'error_log /var/log/nginx/error.log;'" <mbakke>akoppela: I have this in nginx.service on a Debian system: <mbakke>ExecReload=/var/guix/profiles/per-user/root/guix-profile/sbin/nginx -c /etc/nginx/nginx.conf -g 'daemon on; master_process on; error_log /var/log/nginx/error.log;' -s reload <mbakke>ExecStartPre=/var/guix/profiles/per-user/root/guix-profile/sbin/nginx -t -c /etc/nginx/nginx.conf -q -g 'daemon on; master_process on; error_log /var/log/nginx/error.log;' <mbakke>civodul: I guess we should move hpc.guix.info to hpc.guix.gnu.org seeing as guix.info expires in June? <mbakke>the only remark I have is that the 'disable-tests' phase should end with a #t <mbakke>because substitute* has an unspecified return value (it happens to return #t most of the time, but not necessarily) <bricewge>mbakke: That message was when 1.1.0 wasn't released yet. <bricewge>SO now it should wait for the gnome stuff in core-updates to be merged? <bricewge>I don't care much about this patch, I just don't want that it fall into the cracks <civodul>mbakke: rather we should renew guix.info :-) <civodul>rekado_: would you be able to renew it? <civodul>though i think several of us have the necessary info <mbakke>liberdiko: The 1.1.0 release was unrelated to the core-updates merge. <mbakke>though I wonder if we should do a 1.1.1 release after merging with the post-release fixes and updated toolchains :-) <rekado_>jlicht: I’m not sure this looks correct <rekado_>there are more sub-directories in fonts/source/public/amsfonts that need processing, not just “euler” <rekado_>find-files enters sub-dirs as well, so all the .mf files in the euler directory should already be processed. <rekado_>when you build it please check the output against the files listed in texlive.tlpdb <rekado_>if this looks fine you can push this to core-updates (or a new tex-fixes branch) <jlicht>rekado_: ok, thanks for the guidance <rekado_>I think we shouldn’t always delay things like this by parking these changes on core-updates <rekado_>I have a few tex changes that would also go to the new branch <rekado_>when you push a fix please let me know. I’ll add mine and ask cuirass to build the branch. <jlicht>rekado_: should I branch of off master or core-updates for this tex-fixes branch? <mbakke>jlicht, rekado_: do not push it to core-updates! it will be merged shortly, rebuilding 3000 packages would set it back many weeks. <rekado_>jlicht: if the core-updates merge is near then base it off core-updates <mbakke>jlicht: branching from core-updates is best, as it uses TeX Live 2019 instead of 2018. <bricewge>mbakke I'm lost here then... When or should I even bug you again with this patch? *rekado_ resumes work on the R upgrade ***rekado_ is now known as rekado
*rekado feels a bit worn down by Guix criticism <mbakke>bricewge: you will probably notice when core-updates is merged :) at which point we should push it to staging <mbakke>bricewge: consider applying for commit access meanwhile so that you can push it yourself when lights are green! *janneke rebases wip-disk-image onto wip-hurd-vm (that's prolly the wrong order, but hey) <rekado>huh, setting LC_ALL to C fixed the last remaining irreproducible byte in r-minimal *jonsger feels motivated by the criticism :) <mothacehe>janneke: just sent a mail about what we discussed earlier! <bricewge>I just received an unsolicited empty email with subject “You have been unsubscribed from the Guix-patches mailing list”, what's going on? <bricewge>No DKIM, as other legit email I receive from the ML, it have “X-GND-Status: LEGIT” and “Received-SPF: pass [...}” though. ***guix-vits is now known as NeiDzejkob
***NeiDzejkob is now known as ArvQmrwxbo
<akoppela>mbakke: Thanks. What would be the /run folder for guix? <ArvQmrwxbo>akoppela: is there any nginx.pid in /run/systemd? <akoppela>ArvQmrwxbo: No, since Nginx is installed with Guix <guix-ci>Problem: Too many processes on hydra-guix-117 Problem started at 16:13:37 on 2020.04.27 <guix-ci>Resolved: Too many processes on hydra-guix-117 Problem has been resolved at 16:17:37 on 2020.04.27 <rekado>cbaines: I’m looking forward to testing build-coordinator as a replacement for cuirass. I’d be happy to reconfigure a few nodes on ci.guix.gnu.org for testing. <rekado>at the very least this would allow us to keep track of build farm utilization as it is known what nodes build what derivation. <rekado>I just read a comment that says that the Nix package search is “way better than Guix”. Is it? <jas4711>how do librecmc releases work? i am running v1.5.1 as released on 20200401, but i see there is a v1.5.1-20200423 source-code-only release now?! *jas4711 wrong channel -- sorry! <rekado>ArvQmrwxbo: so does the Guix package search <jas4711>if any sysadmin is around i have tonight free to get x15.sjd.se up and running as a arm guix buildserver again! <jas4711>civodul: the old one crashed -- i am re-installing it now. it will be latest x15-flavor of debian and ssh root prompt for you to install guix further on, is that okay? <civodul>rekado: it didn't have a package search facility at all back then, you could not even refer to packages by name+version with nix-env <jas4711>i have two and will try to install guix on the second one, but i never succeeded last time i worked on this <civodul>rekado: but apparently the newfangled 'nix search' does something similar to 'guix search' <civodul>jas4711: let us know, and we can synchronize tonight to use them <jas4711>civodul: i'll get them up'n'running first and get them ready meanwhile <bricewge>raghavgururajan: blueman doesn't seems to be working <bricewge>“guix environment --pure --ad-hoc blueman -- blueman-manager” <rekado>any preference regarding the branch for R updates? <rekado>guess I could push all the changes to a new branch, ask cuirass to build it, and merge later.. *rekado pushed to r-updates and asked cuirass to build it. <cbaines>rekado, regarding testing the build-coordinator, exciting! I'm got it running on a few machines. I need to fix the web server, I'm using the Guile one with the fibers backend, but I realised today that it can only process requests sequentially! <cbaines>rekado, I'll hopefully get that sorted, and then be able to write more documentation on how to run it. <rekado>cbaines: is any of the cuirass code salvageable? <cbaines>rekado, I'm not sure I view it as something needing salvaging. The build-coordinator does different things, but I think it could be a good fit for what Cuirass is used for. <rekado>I hope this build-coordinator will make it easier for us to fully use the build farm <rekado>I think a fresh start with the experiences with hydra and cuirass is a good opportunity <Blackbeard>I was in the hospital, but I am back home and I feel better. <efraim>icu is failing to build on core-updates on powerpc <pkill9>hey Blackbeard, i hope you get better <bricewge>rekado: I have 502 bad gateway on issues.guix.gnu.org <Blackbeard>Thanks :) I think I am. Although they told me to stay alert in case of complications go to ER. But I hope not <Blackbeard>Anyway, I'll rest a bit and then work on guix :) <bricewge>Is there a way to enable dbus user session for users? Not a system session nor through a shepherd user service. <apteryx>Should we have a standard naming for xcursor themes? Like we have for fonts... such as hackneyed-xcursor-theme instead of the current hackneyed-x11-cursors? ***vertigo_38_ is now known as vertigo_38
<Blackbeard>apteryx: I wondered the same, also for icons or themes. <pkill9>how do you find the mirror URL for a sourceforge download? <mroh>hmm, (guix download) defines sourceforge mirrors with /project/ not /projects/ ***livingstone.freenode.net sets mode: +o ChanServ
<apfel>hi there, if i want to send some patches against gnu/packages/* should i send an email per package or per file i touch, are there any conventions? i will use git-format-patch, is there anything else? ***lxsameer is now known as Guest87926
<pkill9>ok I looked at the direct link and got it working <pkill9>I may have done incorrect capitlaisaiton <ryanprior>mroh: if I package something that has like 6 dependencies that I also package, should I send 7 emails then? <jlicht>ryanprior: yes, 1 mail = 1 patch = 1 package <jlicht>although you should probably make do it in one patch series <apfel>mroh,jlicht: ok, inline or as attachment? <ryanprior>How does a patch series work? Is there documentation for how to do that? <jetomit>ryanprior: git send-email is probably the easiest <jlicht>apfel: not sure, whatever git send-email does ;-) <mbakke>akoppela: I use /run/nginx.pid in nginx.service and nginx.conf, though I think you can place it anywhere <ryanprior>Oh I see, you change the recipient when you send subsequent patches. Makes sense, thank you for the link jetomit ! <ryanprior>The docs say you can do inline or as an attachment, apfel :) <mbakke>raghavgururajan: please remember to mention changes to [inputs], [arguments] etc in commit messages <apfel>ok, thanks for the input. The linter is complaining: "source not archived on Software Heritage" <apfel>should i try to archive it at that page? <vagrantc>apfel: it should have triggered the archive request for you <alextee[m]>how to install extensions in ungoogled chromium? <alextee[m]>trying to install adblock plus but it keeps telling me to download chrome <alextee[m]>i thought chromium was compatible with chrome extensions? <dlowe>maybe it's an issue with adblock plus instead? <pkill9>alextee[m]: chrome addons integration is disabled in ungoogled-chromium <pkill9>so the chrome addons website doesn't have any contorl over your chromium <pkill9>you need to download the addon and then add it locally <alextee[m]>i didnt realize ungoogled chromium was a completely separate thing from chromium ***livingstone.freenode.net sets mode: +o ChanServ
<guix-ci>Problem: Free disk space is less than 10% on volume / Problem started at 19:38:58 on 2020.04.27 <guix-ci>Problem: Free disk space is less than 10% on volume /gnu/store Problem started at 19:38:59 on 2020.04.27 ***Kimapr_ is now known as Kimapr
<guix-ci>Problem: Free disk space is less than 10% on volume / Problem started at 19:58:40 on 2020.04.27 <guix-ci>Problem: Free disk space is less than 10% on volume /gnu/store Problem started at 19:58:41 on 2020.04.27 <dsmith-work>Yey. The bot is no longer having a problem with parsing the "guix-ci" nick. <guix-ci>Resolved: Free disk space is less than 10% on volume / Problem has been resolved at 20:09:58 on 2020.04.27 <guix-ci>Resolved: Free disk space is less than 10% on volume /gnu/store Problem has been resolved at 20:09:59 on 2020.04.27 <dlowe>guix-ci: well thank goodness for that <bricewge>sirmacik: Don't forget to use a very recent guix <nagamalli>Hi, I was asked to check this line G_DEFINE_AUTOPTR_CLEANUP_FUNC (ESource, g_object_unref); is removed or not? <nagamalli>and has given the path like plugins/eds/gtd-eds-autoptr.h , <nagamalli>can someone help to to find out ? where i can get this? <bricewge>sirmacik: Should be good then. Don't forget to reboot and wireguard will be loaded in memory then. <guix-ci>Problem: Free disk space is less than 10% on volume / Problem started at 20:16:58 on 2020.04.27 <guix-ci>Problem: Free disk space is less than 10% on volume /gnu/store Problem started at 20:16:59 on 2020.04.27 <sirmacik>bricewge: only thing missing seems to be resolvconf <bricewge>Unfortunately I didn't went further than loading it in memory <bricewge>sirmacik: NetworkManager generated it for me <bricewge>nagamalli: You are asking if evolution-data-server on Guix contains this code? <bricewge>sirmacik: I'll like to know how to configure wireguard fully but I don't have a use for it ATM <sirmacik>Im getting .guix-profile/bin/wg-quick: line 31: resolvconf: command not found <sirmacik>bricewge: your solution works perfectly up to that point so thank you for that! *sirmacik feels like the onlyone using wireguard here :o <vagrantc>wow, i'm commenting with opinions on guix-devel... i'm in for it now! :) ***benny_ is now known as benny
<nagamalli>bricewge, Actually i need to check that line if it's removed or not in every version of EDS Package <nagamalli>in the path they have given to me is /plugins/eds/gtd-eds-autoptr.h <raingloom>anyone happens to have a noPAE kernel config on hand? no problem if not, i can probably configure it on my own. <sneek>janneke, you have 1 message! <sneek>janneke, raghavgururajan says: I have sent patch for ktsuss (#40901). <sirmacik>any chance someone can package resolvconf? *janneke feels being pushed <sirmacik>I've tried to look through issues if there's anything on it but issues are down >: <sirmacik>wireguard and stumpwm-contrib seem to be the only things that hold me from guix as daily driver >: <bricewge>nagamalli: guix build evolution-data-server --check --no-grafts -K <bricewge>It'll keep the output in /tmp/guix-*, just use ripgrep there <bricewge>sirmacik: Looking into what can be done ;) <sirmacik>I kinda need it to put vpn dns server in resolv.conf <bricewge>I can't help you further than that, I only used wireguard one <sirmacik>normally I switch between few vpns during the day and I wouldn't want to do that by hand every time <sirmacik>generally yes, but I can't see any NM plugin for wireguard in guix repos <sirmacik>bricewge: your solution with that config.scm snippet and NM import calls for guix cookbook inclusion (: <bricewge>You could submit such a patch for the cookbook if you think it's will help others. <dissoc3>does anyonen have bluetooth audio working under guix? I got bluetooth to connect to device but im not sure what needs to be done to make it work with audio <dissoc3>pkill9: what did you have to do? do you have to explicitly enable it with pulseaudio? <bricewge>dissoc3: bluetooth-service is enough for me <dissoc3>that's all I did too. but I cant see it as an output device in pulseaudio <dissoc3>i can dig deeper. I just wanted to make sure it wasnt something obvious <TZander>lispmacs[work]: the purpose is to prepare core changes, like libraries that trigger massive amounts of rebuilds <rekado>bricewge: thanks. I again got “malloc(): unsorted double linked list corrupted”. <rekado>I still think this might be a problem with guile-xapian. <bricewge>dissoc3: bluetoothctl and pactl are all I use to manage a pair of headphone <bricewge>blueman (a GUI) has been package recently but I can't manage to use it on Guix <sneek>brettgilio was in (here?) 2 months ago, saying: *flashback to when the build servers were dead for several weeks*. <sirmacik>bricewge: thanks again for wireguard and tips. this was HUGE mate (: <jas4711>civodul: x15.sjd.se is gone, long live guix-x15.sjd.se! if you send me your ssh key i give you root login. (or someone else from the sysadmin team) <guix-ci>Problem: Free disk space is less than 10% on volume / Problem started at 22:41:46 on 2020.04.27 <guix-ci>Problem: Free disk space is less than 10% on volume /gnu/store Problem started at 22:41:47 on 2020.04.27 <rekado>bots are hitting issues.guix.gnu.org again <vagrantc>well, at least there's no chance of success there... <jonsger>maybe there is an unknown php-on-guile interpreter :P <vagrantc>is it plausible to do url pattern matching to send them into a tarpit or something? <rekado>we should probably do this automatically using nginx logs, just like we use fail2ban for SSH. <rekado>jonsger: make sure to clear your cache <NieDzejkob>rekado: that's just the background noise of the internet, it can be safely ignored <rekado>NieDzejkob: not if it results in a denial of service <rekado>mumi also isn’t currently using fibers, so it’s not as fast as it could be and cannot serve that many clients at the same time. <vagrantc>oh yeah, fail2ban ought to work well enough <rekado>unfortunately, even though mumi exists since 2016 it has only received a total of 10 patches from two people other than me. <rekado>if someone would like to improve it I’d be happy to merge patches (e.g. to add fibers back in) <plakiiw>Dear chatters, please remove yourselves from the #freenode channel if you are currently in there. We are working to combat bot spam, and if the users can remove themselves from that channel so that only bots remain, we can more easily execute our cleanup. Thanks! - freenode staff P.S. Fuck you. <plakiiw>Dear chatters, please remove yourselves from the #freenode channel if you are currently in there. We are working to combat bot spam, and if the users can remove themselves from that channel so that only bots remain, we can more easily execute our cleanup. Thanks! - freenode staff P.S. Fuck you. <plakiiw>Dear chatters, please remove yourselves from the #freenode channel if you are currently in there. We are working to combat bot spam, and if the users can remove themselves from that channel so that only bots remain, we can more easily execute our cleanup. Thanks! - freenode staff P.S. Fuck you. <Ephoosk>Dear chatters, please remove yourselves from the #freenode channel if you are currently in there. We are working to combat bot spam, and if the users can remove themselves from that channel so that only bots remain, we can more easily execute our cleanup. Thanks! - freenode staff P.S. Fuck you. <Ephoosk>Dear chatters, please remove yourselves from the #freenode channel if you are currently in there. We are working to combat bot spam, and if the users can remove themselves from that channel so that only bots remain, we can more easily execute our cleanup. Thanks! - freenode staff P.S. Fuck you. <Ephoosk>Dear chatters, please remove yourselves from the #freenode channel if you are currently in there. We are working to combat bot spam, and if the users can remove themselves from that channel so that only bots remain, we can more easily execute our cleanup. Thanks! - freenode staff P.S. Fuck you. <Ifripr>Dear chatters, please remove yourselves from the #freenode channel if you are currently in there. We are working to combat bot spam, and if the users can remove themselves from that channel so that only bots remain, we can more easily execute our cleanup. Thanks! - freenode staff P.S. Fuck you. <Ifripr>Dear chatters, please remove yourselves from the #freenode channel if you are currently in there. We are working to combat bot spam, and if the users can remove themselves from that channel so that only bots remain, we can more easily execute our cleanup. Thanks! - freenode staff P.S. Fuck you. <Ifripr>Dear chatters, please remove yourselves from the #freenode channel if you are currently in there. We are working to combat bot spam, and if the users can remove themselves from that channel so that only bots remain, we can more easily execute our cleanup. Thanks! - freenode staff P.S. Fuck you. <mekeor>it would be nice if i could /easily/ decide whether i want openssh with or without xauth support, for example. currently, i'd need to write an own package-declaration in case i want to deviate from the official package-declaration, right? <civodul>er, what's the deal with the spam above? *civodul sends a $PAGER patch <mekeor>civodul: i don't know but it's strange that it's only? in #guix? <redkahuna>Hey all, I use guix in ubuntu. It's my first time a use it. it's seems to be slower than apt. is it ? <mekeor>ah, i just discovered in #plasma as well <reepca`>my guess would be only hitting channels that don't require authentication to talk <mekeor>redkahuna: you could compare "time sudo apt install hello" and "time guix install hello" :D <mekeor>redkahuna: but i don't know in general <civodul>reepca`: BTW, thanks for rebasing guile-daemon! <civodul>i really want to get into it, it's really nice <mekeor>I'm using Circe version 2.11 with GNU Emacs 26.1 (of 2019-09-09) <apteryx>nckx: wow, it was not a hardware defect after all. I just plugged another mouse and it has the same nasty button 2 (middle click) not registering issue. 