<civodul>oh, a GnuTLS replacement package \o/ <civodul>good to see the UI no longer goes awry <civodul>when there's a new replacement to build <joey>thanks, that worked perfectly! *guix-vits what is better for package that need opengl: mesa, or glu? both works in (inputs...? <str1ngs>guix-vits: depends if it uses glu or not. <str1ngs>guix-vits: if the program uses glue, then probably you can just add glu as an input. <str1ngs>mesa is a depends of glu, which makes sense. since glu is just higher level abstraction opengl <alextee[m]>^ i use mesa unless the package explicitly uses glu <Parra>how can I retrieve the path where the unpack phase let the files? <alextee[m]>Parra: you can use relative paths and you will be inside source already <guix-vits>str1ngs, alextee: thanks; idk, both are working. anyway :) <rekado>guix-vits: “glu” works because it propagates “mesa”. <joshuaBPMan>I'm getting this error: error: '/nix/var/nix/profiles/per-user/joshua/profile' is not a symlink <leoprikler>i tried packaging that once, but the graphics seemed to glitch around no matter what i did <pkill9>rekado: which file is the site file for festival? <rekado>pkill9: share/festival/lib/siteinit.scm <rekado>pkill9: just found that nothing’s wrong with our festival package wrt HTS. It’s just that the HTS voices that can be downloaded from the festival website are in the old multi-file format. <rekado>the new HTS engine expects just a single file. <leoprikler>you should add cc-by-4.0 and cc0 license for assets <joshuaBPMan>ok. I got nix-service-type to work. I am now running firefox-74 <rekado>so I’m not going to change anything about the festival package in terms of features <joshuaBPMan>interesting...firefox works, but right now I do not have sound working for it... <guix-vits>leoprikler: but it's not neccessary, i hope (assets are listed somewhere in /share/doc/LICENSE.xyz)? <leoprikler>in guix you usually list all licenses with some comments <pkill9>rekado: can those HTS voices be converted from the old multi-file format to the new single-file format? <guix-vits>[env]λ taisei 0 I: main: Girls are now preparing, please wait\ warmly... <Blackbeard>why does guix suspends if I left my computer for a while? and how can I change that? <guix-vits>Blackbeard: strange it is. Did you received any Kernel updates recently? <Blackbeard>Linux revenge 5.4.28-gnu #1 SMP 1 x86_64 GNU/Linux <Blackbeard>but I've noticed it suspends since I installed guix <Blackbeard>my problem is that once it suspends I have to manually reboot, because it won't go up again <Blackbeard>that is a bug of the kernel, the same happens if I suspend with parabola <guix-vits>Blackbeard: i've this in sway-bar settings: `status_command while date +'%Y-%m-%d %l:%M:%S %p'; do sleep 1; done;` <guix-vits>Mabye you can prevent it from happening by running something alike in background, at least? <brendyyn>Blackbeard: my Arch also does that with my desktop. i think it started within the year. it used to suspend fine and now it just locks up when trying to resume <pkill9>why do the festival emacs modules have .scm suffixes? <Blackbeard>brendyyn: ah yes :/ but I have no desktop and it is really annoying but guix-vits solution seems nice <guix-vits>Blackbeard: i'm not sure if it'll help, though. <brendyyn>Blackbeard: i dont see why that would make any difference <Blackbeard>brendyyn: I thought maybe running a command will stop it from going to sleep, <Blackbeard>I was also thinking on writing a script to move the mouse every 5 minutes of no action <lfam>I'm curious where INHERIT is defined? <reepca>lfam: if you mean as in (package (inherit some-other-package) ...), I don't think it's explicitly defined as a procedure or as a macro, it's just processed in the syntactic constructor for guix records. Said syntactic constructor is created via MAKE-SYNTACTIC-CONSTRUCTOR in (guix records). <jackhill>I have a feature request/idea: guix pull --news should display information about package replacements (e.g. packages for which there is a new graft available). <reepca>Parra: there are three places where you're using quote in your attempt. The first is for the entire argument list (arguments '(#:phases ...)). This prevents evaluation when the package object is being defined, which is good, as this code needs to be passed through to the builder script. The second is around the call to map, and the third is around the call to find-files. These last two prevent evaluation on the build-side twice. <reepca>map returns a list, so for example (map (lambda (x) (list x (list "gcc:lib" "glibc"))) '("a" "b" "c")) would produce (("a" ("gcc:lib" "glibc")) ("b" ("gcc:lib" "glibc")) ("c" ("gcc:lib" "glibc"))). So your call to map doesn't need to be inside an extra level of nesting <reepca>hm, it might be easier to write up and paste some examples where vertical formatting is more readily available <jackhill>pkill9: cool, I'll write something it an issue so we don't forget about it :) <Parra>reepca: So I should avoid the quote on the later two? <reepca>Parra: in short, yes. Will paste full explanation in a smidge <Parra>reepca: Thanks so much I will review it later <Parra>respect to the find-files, it should show the same output as in the unpack rewrite, right? it's supposed to be in the same path during the whole execution of the build <reepca>that should also answer your second question, hopefully ***langdon_ is now known as langdon
<reepca>has ci.guix.gnu.org been having network issues by any chance? A lot of my downloads have been getting stuck lately, and I'm wondering whether it's a problem on my end <jsoo>if i wanted to make authenticate on the repo but i have made some commits that might not be signed on top, how can i do that? <usney>Does anyone use lxde + guix package manager on a foreign distro? <marmulak>I'm trying my hand at running guix system <Parra>reepca: man, you are gold, thanks so much for the tutorial *raghavgururajan guix pulls after long time <marmulak>wait a minute, what is "libdrm" doing in my libre system <bricewge>marmulak: Here DRM stands for Direct Rendering Manager, it's a linux driver. Not to be confused with the so called “Digital Right Management”. <marmulak>when I did guix upgrade --dry-run to see what it wanted to update, it said it'll update netsurf and download 28 megs so I said OK that's not so bad right, so I ran guix upgrade. Surprise! Every package in the entire OS is getting downloaded again! <marmulak>bricewge: d'oh, I should have remember that <marmulak>also it doesn't just download the same package once, but I think 2 or 3 times at least <xelxebar>From early boot guile, is there an easy way to just shutdown? <marmulak>guix system reconfigure covers updating the system's guix-daemon, doesn't it? <Kimapr>i have some problems with webcam. i tried to open it with cheese but it says "No device found". lsusb shows it though, and with lsusb -t i can see that the driver is uvcvideo <raghavgururajan>Folks! How to find list of required dependencies from configure file, inside source tarball? <str1ngs>raghavgururajan: there is no standard way to do that. at best you can check for PKG_CHECK_MODULES in configure.ac. but that's only if it uses pkg-config. that does not take into account things like program checks like AC_PATH_PROG and AC_PROG_LN_S. also neither takes into account. AC_CHECK_LIB <str1ngs>raghavgururajan: maybe PKG_CHECK_MODULES and AC_CHECK_LIB would be enough. but you are bound to hit many edge cases. depends will always me manually thing. until someone adds better support to autotools <marmulak>if edge cases are many doesn't that not make them edge cases <raghavgururajan>str1ngs Yeah, I have been doing this manually. I was different when using cmake and meson. <str1ngs>raghavgururajan: its something I considered before myself. autotools is highly flexible though. my if autotools had a more defector way to standardize dependencies. <str1ngs>raghavgururajan I think at most you can rely on PKG_CHECK_MODULES provided pkg-config is being used of course. <str1ngs>raghavgururajan: but it could also use a combination pkg-config and say AC_CHECK_LIB. also it could use here would not resolve dependencies. <kondor[m]>maybe the `Contribute` section of the manual should recommend out-of-source-tree guix builds. Otherwise, you end up with a lot of cruft in the guix source, which you should be careful not to commit with your patches. <str1ngs>raghavgururajan also there are macros like GUILE_MODULE_AVAILABLE to account for. <str1ngs>kondor[m]: there is not way you should be committing something you don't want committed. try using git add -p to pick hunks. or emacs magit <xelxebar>Holy crap! I got guix running as a GCE instance!!! <xelxebar>It looks like one or two people out there might be interested. heh ***apteryx is now known as Guest36614
***apteryx_ is now known as apteryx
<raghavgururajan>Folks, where do I find "ft2build" header file? I tried 'libxft' and 'freetype' as inputs. I still get: <bricewge>raghavgururajan: Looks like it's in freetype <bricewge>raghavgururajan: I mean, it's there I checked <marmulak>hmm can't login after doing system rebuild <bricewge>raghavgururajan: ls -l $(guix build freetype)/include/freetype2/ft2build.h <marmulak>oh gdm is trying to default to gnome which wasn't installed <bricewge>marmulak: You can always roll back from Grub <marmulak>it's OK luckily I just had to choose my de in gdm <kondor[m]>str1ngs: but, building stuff out of the source tree is much simpler and cleaner than hunting down hunks and messing up the current state of the code. for example, if you build guix in the source tree, you end up with bunch of po files. these are already version controlled and will be listed by magit. this is clearly not what i want when testing the addition of a single new package. <bricewge>kondor: Would you care sharing on the ML how you achieved installing Guix on GCE instances? <eric-guix>I'll use guix on my old x200 but I want use only substitute bin. there is some branch on git that give only pre-build substitute <kondor[m]>liberdiko: share on what, installing guix on what? :D <guix-vits>marmulak: my `lscpu`: "Vulnerability Mds: Vulnerable: Clear CPU buffers attempted, no microcode; ___SMT disabled___"; check yours :) <bricewge>eric-guix: No but it has already been asked for. Maybe reporting this feature request on the bug tracker would help in getting it rolling <bricewge>In the mean time you can still use `guix weather` to check what substitutes are availaible <marmulak>is there a way to check for a particular substitution <eric-guix>with -m you can input a MANIFEST, I think that you can write a list of package inside <marmulak>hmm looks like guix weather can take a package as an argument <marmulak>I need to do something about my fonts... they look so thin and sickly and weak <xelxebar>bricewge: Definitely will share. Currently, I am cross-checking to make sure I actually understand the original problem. Give me a sec and I'll share more. <eric-guix>with "guix weather icecat" and I also discover that there aren't subtitute :/ <eric-guix>I also launch "guix weather" and it show me 85% <eric-guix>civodul: there is something to prebuild all package that you need. I mean, I have a server and a x200 at the state of the art What is the best way to use both to speedup the process on x200 <rekado_>eric-guix: the best way is to offload any builds from the x200 to the server. <bricewge>sneek: Later tell rekado : The new commenting feature in mumi seems great, but it wont cooperate with me “There was an error submitting your comment!”. ***rekado_ is now known as rekado
<sneek>rekado, bricewge says: : The new commenting feature in mumi seems great, but it wont cooperate with me “There was an error submitting your comment!”. <rekado>bricewge: there are a bunch of anti-SPAM measures implemented. <rekado>submitting a comment too quickly (< 5 seconds after loading the page) will be rejected <civodul>woow, issues. is becoming prettier and snappier every day! <rekado>bricewge: my problem is rather with seemingly successful comment submission. Messages are queued up but they cannot actually be sent for weird reasons. <janneke>rekado: can/could/will guile+issues replace bugs+perl eventually? <rekado>I *can* trigger message sending when I run the mailer manually, so it may have something to do with the user running the service or the service environment. <rekado>but I haven’t yet looked at the perl code at all <rekado>because I like my residual sanity a bit too much <janneke>rekado: oh, hmm i seem to remember you looked and decided it was forked and decided not to touch it <bricewge>I wasn't that fast writing my comment, I'll retry later <rekado>oh yeah, the GNU instance of debbugs is a forked version of Debian’s debbugs <rekado>I wouldn’t know who to talk to about replacing the GNU instance. <rekado>and I’m almost certain it would be a rather unthankful position to willingly put myself in. <civodul>well, you would first be regarded as a hero by many people :-) <janneke>rekado: as long as you remain upstream, it could work? <marmulak>I wanted to issue a command to delete all the packages in my profile <janneke>i think debbugs is a "pretty good start" if we had that, implemented in a maintainable, modifiable code base <marmulak>wildcards didn't seem to work, so I was reading the manual and noticed the -m option, and thought OK I can create a manifest file for a blank profile <marmulak>but it didn't seem to let me make it blank <janneke>so if "we" (ahum) could strangle it by testing a setup on g_bor[m]'s postfix+mailman <str1ngs>marmulak: though that assumes you have a generations 1. if not you can switch to the first generation and then --roll-back <rekado>janneke: sounds like a good plan <janneke>rekado: yeah, it could be feasible maybe to migrate bugs over <str1ngs>marmulak: might need a -d if you want to clean your generations at some point <marmulak>str1ngs: unfortunately I don't because I had deleted them <str1ngs>marmulak: what is your first generation? <rekado>migration should be just a matter of using the same mailbox contents; process all the mails to build up initial database state, and then go from there. <str1ngs>marmulak: if you do guix package -S25 and then guix package --roll-back . that should do the trick <marmulak>although I kind of did want to still create a blank manifest file lol <fishinthecalcula>Hi Guixers, does anybody know if there is some way to run a one shot service before killing another service? Something like the (requirement) field but that ensures that a service is killed before another when shutting down the system. Thanks <marmulak>I magined to get as far as having a manifest with only "hello" <str1ngs>marmulak: generally you might want to do -d after this but not if you want to switch back <marmulak>oh don't worry, I'm doing the -d, and gc <str1ngs>marmulak: maybe a manifest with just glibc-locales would be useful <str1ngs>most people dont like to use gc .. just saying <civodul>rekado: i think a tricky part in Debbugs is handling incoming email: addresses, control requests, etc. <marmulak>wait many months and then run gc, or somehow old stuff eventually gets removed? <str1ngs>marmulak: you can use time based gc. anything older then so long <marmulak>sure but I was curious what you were waiting many months for :p <leoprikler>fishinthecalcula: why would you start a service upon shutdown? <brendyyn>i waited until my ext4 hit physical limits and my system started malfunctioning. then i gc'd about 200GiB <marmulak>str1ngs: is there a way to similarly reset pull data (like package -S0), or is that generally never desirable <rekado>civodul: handling email addresses might be the hardest thing to do. At least that’s something I just don’t know how to do at all. <marmulak>I guess it doesn't really matter what my pull generation is, I probably will want to keep whatever generation I happen to be currently on <str1ngs>marmulak guix pull has the same arguments as guix package. <rekado>but reading incoming email and deciding whether to invoke commands seems manageable. <marmulak>right but there's nothing useful of taking it back to 0 I assume, one can just use -d and continue on <str1ngs>marmulak: most useful think with pull might be --roll-back <fishinthecalcula>leoprikler: I want to create a development container to host Wordpress and test a plugin. To test it on real data I would like the container to load a SQL dump at startup and dump any modifications before shutting down MariaDB and I was thinking of using one shot services but if you know a better way I'd very much like to know, thanks <rekado>oh… having a new Debbugs would probably break debbugs.el, because that uses the SOAP service. <rekado>the new Debbugs would have to offer a SOAP service. <rekado>that’s not too hard to do, but making it behave exactly the same as the current Debbugs might be tricky. <leoprikler>fishinthecalcula: so you'll want to override the stop procedure. In (stop), first stop the task, then dump the db somehow, then return to shepherd. <guix-vits>`git describe: bootstrap-20190815-11496-gd7113bb655` <sneek>guix-vits, you have 1 message! <sneek>guix-vits, leoprikler says: still fails <guix-vits>leoprikler: please tell me more, how, and where? <leoprikler>the menu displays just fine, but once I try to start the actual game, the graphics act up <leoprikler>I'm guessing this may be an issue with my particular card, but it's still irritating <guix-vits>leoprikler: pity; i'm not grammar enough for this; do your card needs OpenGL ES (i'm failed to include this backend)? <civodul>rekado: it could be that having a new JSON interface and implementing it in debbugs.el would be easier <leoprikler>I already tried all backends that I could package with similar results. For GLES I think we lack some inputs as Guix packages. <rekado>civodul: I can see that becoming a contentious argument from Emacs folks <guix-vits>if check for build-utils.scm fails, do i need to use another commit to test a package? <leoprikler>Why not serialise it as raw lists with write? 😈️ <leoprikler>guix-vits: according to glxinfo I have OpenGL 4.3, so that should not be an issue ***selimcan-i_sani is now known as selimcan
<rekado>the problem is that there are no messages returned for that bug <rekado>…and that’s probably because the indexer didn’t get run yet <rekado>refreshing our local set of emails is terribly slow <rekado>and only *after* it has finished refreshing emails will it try to index them. <guix-vits>leoprikler: should i revert to "developer" build (so people will easily send the console output to devs, without recompiling)? <rekado>it’s been stuck at 1571 since a few minutes already <leoprikler>just for the record, you do get to play the actual game on your machine, don't you? <guix-vits>leoprikler: yes, played (but outside of ./pre-inst-env) <leoprikler>so you installed it into your packages and ran it from there? <guix-vits>leoprikler: `cp gnu/packages/games.scm ~/taisei # added definition there`, `cd ~/taisei; guix build ...`, `guix environment -L . --ad-hoc taisei`, `taisei` <leoprikler>I did `./pre-inst-env guix environment --ad-hoc taisei -- taisei` <guix-vits>devs of taisei are wonderful: some steps are failing, but there is enoug "or" set for build to success <leoprikler>result is still the same -- after character selection I get epilepsy <civodul>rekado: do we have backups of the local database and index? <rekado>the index can be recreated very quickly <rekado>the database is refreshed from debbugs state, so it is also disposable <rekado>the biggest problem is getting those emails :-/ <rekado>for each bug we need to get a list of messages <civodul>it's just a cache, but if it's expensive to rebuild, perhaps we should back it up <rekado>the list of messages per bug involves … fetching all of those messages via the SOAP interface <rekado>with that list of messages we can check if we already have that message <rekado>so we really actually need a cheaper way to ask for a list of messages. <rekado>civodul: the only thing that’s expensive to rebuild is the mail directory <civodul>perhaps we should ask for rsync access to bugs.gnu.org? <civodul>actually, mailman exposes mbox files too <rekado>we’re currently getting the mbox files from the debbugs web interface <rekado>we don’t get one file per bug but one file per message <rekado>and that’s why we need to get the message numbers <rekado>with one big mbox file we cannot easily tell if we already have its contents <civodul>mailman gives one file per month, in a single round trip :-) <rekado>it might still be faster to just download that one file, split it, and index the maildir <rekado>leoprikler: I don’t know if we can get this info via HTTP <leoprikler>you'll still have to redownload the whole blob if one bit changes, though <rekado>maybe we could do a range request? <rekado>a remaining problem would still be that the mailing list archives are delayed <rekado>taking one step back, we could download one mbox file per bug, compare its size, then use a Range request to get the diff <rekado>looks like debbugs does support Range requests <rekado>but I don’t see the size in the headers <rekado>we can just make a request with the Range offset equal to the size of the existing file <xelxebar>Hrm, bootloader's terminal-{inputs,outputs} are not propogating to my grub.cfg... <guix-vits>leoprikler: can you, please, test it windowed (not fullscreen), and (or) on sway? *civodul closes another 2017 bug \o/ <reepca>Parra: what behavior do you observe? <reepca>is there an error message appearing, or is it just not doing any patchelf-ing? <Parra>reepca: after debugging, the list is constructed perfectly, but when it builds, I go to the folder and I check the linked libs with ldd and they aren't patched <Parra>let me investigate with readelf, it's better for this <reepca>ah, I think I see the problem. So one might (or rather, "I did") expect that if there are duplicate keyword arguments provided, the earlier one would win out. I just did an experiment with that and it turns out the later one won out. <leoprikler>I'd rather not test it full-screen if I'm honest <civodul>bricewge: i hadn't noticed your GSoC proposal, it looks great! <civodul>today's Outreachy application deadline, right? *civodul is totally lost :-/ <Parra>reepca: I understand what you mean but, how is it related? and where are the duplicates? <reepca>this is an issue because many build-systems provide default argument values if it's not explicitly given. So there are actually two #:patchelf-plan arguments in the arguments being applied to old-patchelf, and the later one is the default one <reepca>if we wanted to be independent of arbitrary-seeming things like that, we could use the substitute-keyword-arguments macro from (guix utils) <reepca>that'd be the proper way of doing it <Parra>I see, how can I use that macro to solve the problem? <reepca>alternatively, the quick hack way of doing it would be to change it to (apply old-patchelf #:patchelf-plan ... args) to (apply old-patchelf (append args (list #:patchelf-plan ...))) <reepca>so for example, (substitute-keyword-arguments args ((#:patchelf-plan ignored-old-value) <new-value>)) <leoprikler>I see shepherd has spawned a zombie mcron, how can I collect that? <Parra>so substitute-keyword-arguments is something like call by keywords? <reepca>no, it just takes a list of keyword arguments and replaces some of the values. You'd then use the result of that in apply. <Parra>I have tried the hack, it works <xelxebar>Gah. bootloader configuration is completely ignoring the terminal-input, terminal-output, and serial-unit settings... <xelxebar>Rather, they do not propogate to grub.cfg... <Parra>I don't know the language yet, so I prefer the simple solution <Parra>reepca: it worked now, thanks for your time mate <Parra>reepca: and another thing, if I want to add one element to the find-files list, would it be like this?: <Parra>(append (find-files ...) '"executable") <reepca>not quite, append expects all of its arguments to be lists, so you'd want (append (find-files ...) '("executable")) <reepca>alternatively, you could do (cons "executable" (find-files ...)) if it's fine for it to be at the front of the list <rekado>hmm, when I use http-get with a range header in Guile I get the full response; with wget I get the offset response. <cbaines>It seems like anything in the finance module is broken <raghavgururajan>Folks! I am kinda confused. The package I am trying to build has dependency for libxft. I have put it as input. <leoprikler>look how your package constructs its CFLAGS, specifically -I <leoprikler>if it assumes ft2build.h to come from the sme source as Xft.h, that will be a problem <xelxebar>bricewge: So, essentially the only thing preventing the guixsd vm image from booting on GCE is initrd missing the virtio_scsi module. <mbakke>have there been any new bugs reported lately? <xelxebar>bricewge: That's obviously an easy fix. The rest just boils down to following google's guides for creating custom images. <reepca>hm, it's probably trying to pick up the header files just from CPATH, but the developers expect to have the freetype2 subdirectory in it, but it actually just has the include/ directory <reepca>can the package you're using use pkg-config? <xelxebar>bricewge: The hard part in solving GCE boot problems is that we have to use the serial console. <xelxebar>bricewge: It turns out that operating-system's bootloader isn't properly setting up the serial settings, plus qemu and GCE serial ids differ, so figuring this all out involved a lot of blind poking around. <mbakke>there are new patches on the tracker from today, I doubt bug-guix alone is defunct... weird that my bug reports don't get confirmed. <xelxebar>bricewge: Anyway, I have a working config.scm and documented the custom image creation process via a script. <leoprikler>raghavgururajan: (string-append ... "/include/freetype2") <leoprikler>-I /gnu/store/.../include/freetype2 should be the final string <xelxebar>bricewge: Anyway, I plan on writing this up in more detail and sharing code on the ML, so keep an eye out there if you're interested. <guix-vits>leoprikler: taisei's default is `-O3`; maybe it's a reason? <leoprikler>The debug build fails because the frame buffers are invalidated. Perhaps there's a relation? <reepca>I think it would also work to set CPPFLAGS=-I.../include/freetype2 (the environment variable) <leoprikler>guix-vits: the program crashes with #:build-type "debug" due to invalid framebuffers <leoprikler>those errors seem to be ignored in release builds, which leads to the wonky display <xelxebar>|guix pull: error: You found a bug: the program '/gnu/store/irh2b5nz37rhvjimwjvh2j83g4fq76wz-compute-guix-derivation' <xelxebar>failed to compute the derivation for Guix (version: "58ee99fcb2d31a3eeee402fc013f9d97783bcad3"; system: "x86_64-linux"; <xelxebar>host version: "1.0.1-15.0984481"; pull-version: 1). <leoprikler>yeah, it's probably related to graphics card, I'm using some older NVIDIA <alextee[m]>i think our lv2_validate is broken, i guess i will send a patch to disable tests for now until we figure it out <alextee[m]>is there a way to set a priority on patches? this is probably a bit higher than normal <alextee[m]>rekado: where does that go? anywhere in the subject field? <rekado>alextee[m]: start the message body with “Severity: important” <bricewge>civodul: Really nice to hear! I hope it will pan out. <rekado>alextee[m]: I hope it won’t be needed for long <leoprikler>that's probably it – i found that restarting mcron cleans the zombies <civodul>probably mcron rather than macron :-) <bricewge>raghavgururajan: What package are you trying to build, can you share it? I would have look in Nix how they managed to work around the issue. <civodul>that one is responsible for lots of things, but not zombies <rekado>rewrote the message fetching in mumi. <rekado>now that it uses mbox files we could also just get rid of mumimu and index the mbox files directly <mbakke>apparently having a commit hash in the subject field gets your bug report ignored by debbugs <alextee[m]>rekado: should I close the patch with the meta-package for lv2-plugins? seems there's no interest in having such a package (has every lv2 plugin available in guix as a propagated-input) <bricewge>raghavgururajan: Well done, I didn't knew this GUI toolkit. <xelxebar>bricewge: the only differenec with my setup being that I'm using grub-bootloader instead of grub-efi-bootloader... <mbakke>browsing other issues seems fine <bricewge>rekado: Same thing on #40480 opened at 08:30 UTC <civodul>mbakke: no idea, it'd be best to investigate and understand, but right now i'm trying to get that release off the ground :-) <mbakke>civodul: I'd like to merge master to core-updates so I can get all the security fixes :-) but I guess we can ignore that failure for now? <mbakke>civodul: is there anything I can do to help with the release process? <civodul>mbakke: yeah we can ignore the failure for now <civodul>regarding the release, we need to re-test things, prepare NEWS <civodul>we don't have any tests for the binary tarball on foreign distros <mbakke>phew, NEWS update, maybe we should make a habit of updating it more frequently <civodul>i started preparing the blog post, which will serve as a starting point for NEWS <mbakke>civodul: oh, one last core-updates question: when merging etc/news.scm updates, should I keep the core-updates entries "on top" even though they are older than the news on master? <guix-vits>leoprikler: seems that to try GL ES, we need a spirv-cross (-tools and -headers are already there) <marmulak>I think a lot of people are learning about guix now that they under house arrest <guix-vits>i'm join the club: "guile: warning: failed to install locale" <guix-vits>marmulak: no, `guix environment --pure guix` <marmulak>my install is fairly new and I haven't gotten it yet <marmulak>I had it when I was running it on my fedora box <civodul>mbakke: the order of news entries is not significant <civodul>janneke: i pushed a couple of improvements to wip-hurd-vm, but still no virtual console *rekado updates mumi on issues.guix.gnu.rog *janneke retries building guix for nth time today <leoprikler>okay, can someone explain me the difference between `guix build` and `guix environment --pure -- make` <guix-vits>jonsger: frog ^= federative republic of guix <civodul>janneke: silly me, we need to start bin/console (the console client), and for that we need bdf fonts (DEFAULT_VGA_FONT_DIR in Makefile), and where do we get those? <raghavgururajan>Because I get "configure: error: C compiler cannot create executables". <rekado>leoprikler: “guix build” arranges for the build to happen in a chroot and it runs build phases. <rekado>raghavgururajan: check the config.log first <janneke>"guix search" shows utilities to converf /from/ BDF <leoprikler>okay, my build phases are bootstrap, configure and run, I can do those on my own inside environment <leoprikler>but the chroot environment is different even from guix environment --container <rekado>leoprikler: yes. Eventually, the minor differences should disappear once the daemon uses the same container implementation. <rekado>raghavgururajan: neither. It’s produced by the configure script. <rekado>raghavgururajan: build with “-K” and then look in the directory it leaves behind. ***ssouth is now known as simonsouth
<janneke>civodul: started the debian hurd, but i can't seem to find a bdf font, only utilities? *janneke means: a bd font; or a BDF ont *mbakke goes through open EFI related issues and will test the EFI installer <guix-vits>raghavgururajan: one quick question: CMAKE syntax is -Dsomething=YES ? <rekado>raghavgururajan: the file is big, so take a deep breath <rekado>raghavgururajan: it’s a verbose log of what configure tried to do and the results of these checks. <rekado>you got an error “C compiler cannot create executables”, so search it in that file <rekado>above that is the test program it tried to compile <rekado>and above that it shows a good error: ld: cannot find -lX11 <civodul>i'm pretty sure i did something back in my Nix days <janneke>it could be that urw-fonts are BD fonts <mbakke>rekado: issues.guix.gnu.org a really great tool for triaging bugs, so thanks :-) *guix-vits "great, now i've a spirv-cross-c-shared, next..." *rekado prepares message to help-debbugs@gnu.org… <rekado>pkill9: I only found a Windows tool to convert the old hts voices to the new format. Haven’t seen any source code. <usney>I need help with lxde desktop and use of guix package manager <usney>lxde won't recognize any software installed from guix and even flatpak. <usney>It works in gnome 3 fine though. <rekado>mbakke: hmm, this bug isn’t included in the list of bugs for Guix that I’m getting from debbugs. <rekado>I wonder if that’s because it’s been archived. <rekado>yup, it’s fetched when I asked for archived bugs. <rekado>will update the worker to fetch archived bugs only every nth refresh <mbakke>rekado: impressive turnaround :-) <guix-vits>PS: it cannot, according to diagnostics, find "wayland"... <mbakke>civodul: so the first time someone runs 'guix pull', they will get a suggestion to run it again? <mbakke>from the screenshot it looks like they used 'guix upgrade' without running pull at all <mbakke>ah right, because they haven't run 'hash guix' in between <mbakke>civodul: an evil hack could be to unconditionally add ~/.config/guix/current/bin to $PATH IIUC. Maybe instead of sourcing the profile, as we know that it only sets PATH anyway. <civodul>mbakke: right, they haven't run "hash guix" <civodul>so the solution would be to remove the need for "hash guix", like roptat proposed <civodul>but we'd need to do that for all the user accounts <civodul>and i'm not sure what side effects it would have <civodul>maybe we leave that for the next release? <joshuaBPMan>morning guix! I'm so glad that ya'll have nix-service-type! It's nice to have a working browser that is no longer laggy! <mbakke>joshuaBPMan: is there a problem with IceCat? <rekado>mbakke: joshuaBPMan hasn’t submitted a bug report about this (AFAICS) but all browsers seem to lag on their machine. *rekado cannot reproduce any of that <mbakke>joshuaBPMan: are other graphical programs OK, e.g. games? <mbakke>didn't we fix the problem with SSH failing to start under some circumstances? <joshuaBPMan>mbakke: Regretably I have always had issues with icecat. "Firefox" has always worked for me, but "Icecat" and the other browsers that Guix provides always seem to lag. <joshuaBPMan>mbakke: ummm...I'm not much of a gamer. Can you reccommend some for me to try? <mbakke>joshuaBPMan: SuperTuxKart is pretty fun <joshuaBPMan>mbakke: Also I am using a T400. So my GL is limited to OpenGL 2 I think... <mbakke>and should stress your GPU a bit <joshuaBPMan>mbakke: I'm running libreboot! No GPU is being used! <rekado>surely you have 2D acceleration? <mbakke>joshuaBPMan: not even the built-in Intel GPU? <joshuaBPMan>mbakke: I wish the Libreboot came with a bundled old nvidia GPU. The old nvidio GPUs are pretty much reverse engineered these days. *rekado just found layers.acceleration.draw-fps in about:config <fishyfriend>hi #guix, question. a patch sent to guix-patches@gnu.org got an auto-assigned debbugs case, but did not appear on the guix-patches mailing list (per the archive). i saw some talk about problems with issue tracking systems last week. do i need to resubmit or should i leave it alone? <rekado>fishyfriend: the archive updates slowly <rekado>fishyfriend: it’s unrelated to issues.guix.gnu.org, which has its own problems (that I’m currently trying to fix) <rekado>fishyfriend: if this is your very first message to guix-patches it may be held for a little while <fishyfriend>rekado: i see. this was around a week ago, is it expected to take that long? <mbakke>fishyfriend: what is the issue ID that you got back from debbugs? <rekado>fishyfriend: oh, not it’s not supposed to take *that* long. <rekado>looks like it was sent to the wrong list at first <rekado>(that’s why there is a control message by Glenn Morris) <rekado>looks like it got assigned to the package “debbugs.gnu.org” and not “guix-patches” <fishyfriend>it was sent to guix-patches@gnu.org, i am fairly sure <rekado>if one of the lines in the message said “Package: debbugs.gnu.org” then it may have been assigned to the wrong package. <rekado>don’t know if that’s what happened her. <fishyfriend>i don't think so, just a barebones from/subject/date iirc <fishyfriend>can't rule out a mistake or misrecollection on my side, though <fishyfriend>is there anything else i should do at this point? it's in issues.guix.gnu.org, not on the mailing list <pkill9>rekado: did you make a patch for the siteinit.scm? <rekado>I don’t know how if the mailing list archives will get updated. For us it’s usually enough that it’s in the right “bucket” on debbugs. <rekado>pkill9: I thought you wanted to give this a try *rekado updates issues.guix.gnu.org for real <pkill9>rekado: ah ok, I did give it a try actually, and it does indeed read new voices, however it only did that when i hardcoded a path to the extra voices, for some reason using (getenv) doesn't work <fishyfriend>rekado: ok - will leave it in peace, then. :) thanks <pkill9>rekado: I'll upload the patch i used <civodul>mbakke: that won't work, current-filename returns the name of the source file <civodul>all this is super tricky to get right :-/ <pkill9>rekado: you know emacs better than i do, so I'll have to leave you to finish it off :P <civodul>pkill9: i'm pretty sure that before knowing emacs this well, rekado knew it just as much as you do :-) <rekado>pkill9: good attempt, but this is just Scheme. No Emacs involved at this point :) <rekado>I’m not even sure I know Emacs well, to be honest. Often enough it’s a mystery to me. *rekado prepares email to guix-devel about weird Emacs behaviour <pkill9>rekado: here's a one-liner to build festival with a patch: <pkill9>guix build -e '(begin (use-modules (gnu packages speech) (guix packages)) (package (inherit festival) (source (origin (inherit (package-source festival)) (patches `(,(local-file "/tmp/festival.patch"))))))))' <eric-guix>There is some commando to download only the source and one for calculate size of the source <mbakke>civodul: WDYT about uploading a beta release of 1.1.0 already so people don't have to build their own installer images? <leoprikler>eric-guix not directly, but you have guix download and guix build -S <leoprikler>both give you a store path, download also gives you a hash <pkill9>it looks like they just add a header for 'hts21compat <civodul>mbakke: we could even create a branch so that everything from then on is under control <mbakke>civodul: sounds good, lots of churn on master these days! <rekado>pkill9: that’s for old versions of festival <rekado>this predates the switch to the new HTS <pkill9>i thought maybe that old version would still be backwards compatible <marmulak>does anyone here know how to intall flatpak <mbakke>marmulak: 'guix install flatpak' should do the trick <rekado>sorry for the many mumi updates on master! <marmulak>mbakke: that installs something but for some reason it doen't work <marmulak>I tried adding the flathub repo and it segfaults <mbakke>marmulak: can you send a bug report including the steps to reproduce it to bug-guix@gnu.org ? <marmulak>I noticed on nix flatpak is installed by the system as a service, so maybe that's something that may be needed on guix, though for all I know flathub may work when run as user ***jackhill_ is now known as jackhill
<mbakke>marmulak: I haven't tried it myself, but know others have been using flatpak without special privileges <guix-vits>Blackbeard: ^^ (Blackbeard[m] was just kicked) <marmulak>although if I had multiple users on my system it'd be handy to have flatpaks install system-wide <marmulak>the environments it installs are a little heavy <pkill9>maybe due to same reason it doesn't have firefox, or maybe it' sjust not been added <bricewge>guix-vits: Strange “@appservice-irc:matrix.org kicked Blackbeard (@gold:matrix.eunichx.us). Reason: Idle for 30+ days” <bricewge>He wasn't idle for 30+ days, that's for sure <pkill9>so apparently there is an alternate branded version of thunderbird called 'icedove', like 'icecat' is alternative to firefox, but it's not packaged in guix <eric-guix>marmulak: guix have evolution but it doesn't work due to some missing serive <mbakke>eric-guix: evolution should certainly work, what service is missing? <marmulak>eric-guix: yeah flatpak has grown on me. It solves a number of end-user needs that the distro itself no longer needs to worry about <pkill9>evolutuion also needs evolution-data-server installed <bricewge>rekado: Downloading a patch from mumi append “>” as first character which makes git complaining that the patch is wrongly formatted <mbakke>eric-guix: can you try evolution from Guix again? if there are problems it would be great to fix them before the impending 1.1.0 release. *guix-vits good old times (in env): "ALSA: Couldn't open audio device: Device or resource busy" <joshuaBPMan>It said that they recommended an OpenGL Version of 3.3, which apparently I do not have. <joshuaBPMan>wow, and I can't really see the text that I'm typying in the game. <rekado>bricewge: will add this to the TODO, thanks! *rekado still waits for guix to be built on ci.guix.gnu.org to complete the reconfiguration <lfam>mbakke: I'm not using a desktop but I've had good luck with core-updates on my systems so far <mbakke>joshuaBPMan: right, OK. did you try ungoogled-chromium and experience lags there? <marmulak>considering that I'm using a vesa framebuffer <joshuaBPMan>mbakke: yes sir. Specifically I tried ungoogled-chromium and ungoogled-chromium-wayland <mbakke>joshuaBPMan: wayland, interesting -- which window manager are you using? <rekado>civodul: it’s been bothering me too! <rekado>but I don’t know how to work around it. <rekado>civodul: are you using the latest CSS…? <rekado>I did resize things a bit to make this issue less annoying in most cases. *raghavgururajan says XFE File Manager is now in Guix. (#40487). \o/ <joshuaBPMan>When I was using my macbook, I had issues with the mouse getting stuck going up and down. <joshuaBPMan>Now that I use a T400, I could probably use gnome, but sway is super light weight. and I've heard that wayland is more "secure". <rekado>civodul: the reason why there’s line breaks is that the emails have hard line breaks <rekado>there is an RFC for soft line breaks but Emacs doesn’t support it. <rekado>in the CSS I’m using “white-space: pre-wrap” to preserve all spaces (to prevent ASCII drawings and custom indentation from being screwed up) <cbaines>I think the wrapping changes if you make the box wider <rekado>using just “white-space: pre” works fine, but then there’s overflow for long lines <rekado>cbaines: I can’t find one box size that fits all <cbaines>rekado, indeed, just dropping some of the padding on the .body element does seem to make things wrap nicer in this specific case though <webstrand>I've finally got guix's kernel booting, but I'm still missing something. "No boot file passed via --load"? <webstrand>do I need to pass something on the kernel command line? <rekado>webstrand: no, it should just work. <rekado>“got guix’s kernel booting” sounds like you had some difficulties and tried to work around them. <nagamalli>Hi , I need to add two versions of same package in *.scm file. Suggest me how <sneek>nagamalli, you have 1 message! <sneek>nagamalli, mbakke says: that sneek is really good at remembering messages <rekado>cbaines: are you also using the latest version of the CSS? <webstrand>I forgot to mention, I'm using my own grub, not the one provided by guix (so I don't blow away my existing os) <rekado>cbaines: you may still be caching an old version because nginx doesn’t report the correct modification date. <webstrand>rekado: I've had two major issues that I've had to work around: I'm using LUKS and each os-root is in a btrfs subvolume <cbaines>rekado, yeah, I seem to be seeing the page with the latest CSS <bricewge>It won work, there is patch pending though <civodul>mbakke & all: i pushed a draft of the release announcement to guix-artwork.git <civodul>you're welcome to add/remove things! <nagamalli>Hi , I need to add two versions of same package in *.scm file. Suggest me how <nagamalli>i have a task to add multiple version of same package. Is it just adding two descriptions of same package twice? *rekado restarts issues.guix.gnu.org <webstrand>bricewge: so (options "defaults,lazytime,subvol=/guix") isn't passed unmodified to mount, then? <webstrand>I've copied the initrd and the bzimage off of the luks partition and into my /boot partition, so that grub isn't misconfigured *rekado stops fiddling with it for today <cbaines>Would it be possible to publish an uncompressed version of the ISO installer in upcoming releases? This would help with tools/services where you can specify a ISO/Installer via a URL <mbakke>rekado: that was fast, thanks :-) <lfam>It's a really big file cbaines <cbaines>lfam, well, that's relative. It is big compared to a CD ISO at least, more than ~700MB I believe or whatever the capacity of a CD is. <lfam>cbaines: Is it for, like, VPS hosters? <nagamalli>Hi , I was asked to add 4.14.1 and 4.15.2 , both versions of same package description <nagamalli>can i just add in same file with 2 descriptions <nagamalli>when i tried to build its only build the latest version <cbaines>lfam, yeah, some VPS hosting services support specifying an ISO via URL. <cbaines>lfam, I think with Hetzner, I gave them the URL, but they neglected to decompress the file! So I had to put up a decomressed copy somewhere, and give them that URL instead. <lfam>cbaines: I've ignored QEMU image for a while but that's what I made it for. Maybe we can take another look and fix anything that needs fixing <webstrand>If I can get a working / set up for guix, is there some command I can use to actually boot the system? I could roll my own initramfs that can mount btrfs subvolumes <lfam>It's also compressed, cbaines, but it will be easier to make changes to since it's less important and does less tricky stuff than the installer <lfam>It's created from 'gnu/system/examples/vm-image.tmpl' <efraim>Do we want to host a torrent also? <efraim>And the very top still says 1.0.0 :) <lfam>Looks like a lot has changed since I added that vm-image.tmpl. It might not work out of the box on VPS hosters anymore, oh well <lfam>We could go back if necessary, and add a vps-image.tmpl <bricewge>webstrand: I don't know where the issue with subvol in Guix is. I tried using them, it failed (I was using the Grub from Guix though) and I haven't taken the time to read the subvol btrfs patch. <cbaines>lfam, I'm not sure I know of hosting providers where it's easy to bring your own image. Do you know of any? <lfam>cbaines: I've heard that it's possible on vultr <lfam>I made the image originally for serveraptor.com <lfam>But in that case it was not for user upload, but was provided by the hosting company <cbaines>lfam, ah, cool, I use Vultr, but I think I installed Guix either using a Debian image, or the installer <cbaines>It doesn't seem they're active now though <lfam>I guess the tricky thing is partitioning. Either you install in the normal way, or you have to do some partition / filesystem expansion from the running system <rekado>marmulak: do you want to upgrade it? <marmulak>rekado: I kind of do but I just have no idea how <lfam>My original vm-image.tmpl asked the user to expand the partition and filesystem after first boot <efraim>can I get a graph of creating a VM image? I want to make sure adding tk to xorriso isn't a big problem <efraim>although I suppose with it already needing qemu it's not a big deal <marmulak>I talked to dino devs before so maybe if I can learn how to make a guix package I can work with them for packaging their thing <lfam>raghavgururajan: Is there a link to instructions for uploading an ISO there? <raghavgururajan>cbaines lfam 1984 allows suggestion distros. Long ago I gave asked Guix. They have it now. You can select guix during setting up vps. <marmulak>raghavgururajan: you seem like a pretty capable guix packager <nagamalli>bricewge: I have gone through that , got a doubt , if a package needs older version as input do i need to specify it seperately? <efraim>well that explains these two patches I have sitting in my $HOME. I sent the patch last month and forgot about them <efraim>I tried to use :w in mutt instead of $ to 'write-to-disk' <raghavgururajan>nagamalli: ("package" ,package-x.y). Examples, ("gcc" ,gcc-5) and ("antlr3" ,antlr3-3.1). <TZander>Hey, is it correct that there is no (for packaging) app I can include that defined "(build-system qmake)" ? <kondor[m]>So, what happens when you want to package two different versions of a package? Do you define two packages? <marmulak>opam says my system needs "cc" but I'm not sure what that refers to <TZander>kondor[m]: like python? (see 'guix edit python3' ) <lispmacs[work]>i have cases occasionally where gnome more or less freezes up but I can still access virtual console (probably video card issue). I am wanting to restart gnome in such cases, but am a bit confused how to do this as herd doesn't seem to show a gdm or gnome service, and restarting xorg service doesn't seem to be enough <marmulak>is there a command to run which can tell which guix package provides a certain command? <raghavgururajan>kondor[m]: Different package definitions. Same 'package' name. Different 'version' number. Different 'variable' name, usually in the format of "name-x.y". <mbakke>kondor: the python3 package is called just 'python'. <mbakke>marmulak: GCC does not include a 'cc' executable, often you need to set an environment variable like 'CC=gcc' <Veera>webstrand: I think it is difficult. I not use what Guix offers. <str1ngs>maybe use guix search and guix show more :) <str1ngs>marmulak: for gcc use gcc-toolchains <str1ngs>marmulak: gcc just won't work it needs specs files etc for guix. <marmulak>guix search first hits are "libgccjit" and "gccgo", real helpful... but on the other hand, gcc-toolchain was #3 so not so bad <str1ngs>marmulak: gcc is there but it's hidden. to avoid confusion <nagamalli>raghavgururaja: thanks but ./pre-inst-env guix build <package> is building the old version , if no mention is made its default taken as latest right? <TZander>does anyone here know of any packages that build usign qmake? *guix-vits actually, taisei can use wayland, if started outside M-x shell <guix-vits>nagamalli: try installing with `package@version` <raghavgururajan>nagamalli usually it takes latest. There are exceptions and not sure why. You can build/install specific version as package#x.y <pkill9>TZander: just do `grep -R qmake ~/.config/guix/current/share/guile` <raghavgururajan>nagamalli And if you gonna specify as input inside package definitions, the format is package-x.y <TZander>pkill9: thanks, looks like I'm copy/pasting some unreadable code ;) *raghavgururajan ---> zzZ <nikita`>dunno who does gnurl in guix these days, but I just published an update which merged the 3 last curl versions <nikita`>as far as I'm aware no CVE if present affected gnurl because of what is used/build <mbakke>nikita`: could you submit a patch for guix as well? :-) <nikita`>i hope to get back to this somewhere between now and 2021 <nikita`>or having ported guix to netbsd native, whatever happens first <nikita`>or my hackish workaround, implementing the way guix and nix calculate checksums but in C so I can do trivial updates <mbakke>nikita`: no worries, pinging this channel is the next best thing :-) I'll try to update it later today <mbakke>I for one am looking forward to Guix/kNetBSD \o/ *mbakke goes AFK for a few hours <nikita`>changelog is quiet long, but iirc guix didn't policy include this and just mentions cves.. i do this for pkgsrc <marmulak>ok so what's the best way to make an alias/symlink for cc on guix system? <nikita`>i mean guix and nix are probably more tricky than chromium, and I intend to finish all <mbakke>marmulak: "export CC=gcc" in your shell is typically sufficient <nikita`>hacky workaround could be that guix just runs with our linxu emulation, but i haven't tested this yet because I like to play on hard <marmulak>opam still giving me a warning but it possibly is not really checking hmm <nikita`>i know at least 2 people who want this on NetBSD native instead of pkgsrc, so i hope i can recruit them to work on fixing up stuff once I got the initial porting done 'whenever'.. userbase can be be weird <marmulak>perhaps instead of porting guix to netbsd, port netbsd kernel to guix system <nikita`>I question the understanding of system when people propose to package a *bsd kernel.. like it's not a distribution? there is more work going on in the system which uses this kernel and simply ripping it out works, but good luck developing. <nikita`>i know where this perspective is coming from, i attempted this with guix 4 years ago or so <nikita`>but this argument often comes up when people don't think about the work on a system as a whole <nikita`>i'm not implying you do, but it's an argument i read so often it's annoying me <TZander>scheme is making my head hurt... Does anyone know what this means? Invalid keyword: (replace (quote configure) (lambda _ (invoke "qmake") #t)) <marmulak>well not to upset you but I was only thinking about that because I imagined guix system should probably eventually be kernel independent or include more than one, like as a lame example mach or l4 <nikita`>and it could work for netbsd in a way <marmulak>but you are right, from a netbsd standpoint the reasoning is pretty clear that netbsd is a complete system that should stay intact, and we only want a package manager, which guix does well already <nikita`>from a hackers perspective it's interesting to try but i have no idea how well this would float (license and community wise netbsd is not against gnu stuff (the only part where no gpl must occur by policy is in the kernel etc) <pkill9>could what guix provides ever be kernel independent? it will always require some porting surely? <nikita`>and when you dig deeper you see that some parts of guix require compromises, so kernel independence will be subjective <str1ngs>pkill9: it can the hardest part is porting guix-daemon <marmulak>I suppose you'd need to maintain a port for each kernel you want to use <nikita`>i mean as far as porting goes I think besides the issue i have with gnutls at the moment there's no questions I can not ask if I don't find answers myself, and eventually if there's interest and it's usable having a build machne to provide binaries for guix on netbsd would be cool. i care about both projects, just dropped off the surface of guix for a while because I only have so much energy <nikita`>pkgsrc solves different issues than guix, so having guix there would be interesting but no competition <cbaines>TZander, the (replace bit looks like it should be part of (modify-phases %standard-phases <cbaines>are you trying to follow what another package definition does? <TZander>kinda. Its using qmake, so I tried to find some qmake packages, but they all do things differently. <TZander>oh, it built.. Lets see if it actually runs :D <TZander>after calling the following, is there any way to read the build-log? guix package --install-from-file=fulcrum.scm <lfam>Do `guix build --log-file /gnu/store/...-your-package` where that path is the thing that was built and installed by `guix package` <lfam>You can find that path from `guix package --list-installed` <lfam>We call that thing a "store item" <lfam>If the build log just shows a line about "grafting", ask for the log file of the store item mentioned in there <dongcarl>Hi all, it seems from the INSTALL-LOCALE procedure in (guix build gnu-build system) that LC_ALL is always set to en_US.utf8 in the build environment? Is that correct? <Veera>nikita`: I was able to package Xplanet for guix with part of your inputs and other members here. <Veera>Blackbeard: I asked on other day, about your project on gsoc <Blackbeard>Veera: is that part of your project? That's cool <Veera>Blackbeard: Is it not decided/finalized/not to be disclosed yet <Blackbeard>Veera: ohh it is about improving Shepherd so it has more capabilities, closer to systemd unit files API <Veera>Blackbeard: Yes. Part of Outreachy Project. Before Intern selection. <Blackbeard>Veera: and it is also about being able to parse some types of unit files, <Veera>Blackbeard: Read that in mail. Did not knew it was you. <rekado>I think I should spin up more mumi processes for issues.guix.gnu.org <Veera>Does bugs vanish after somedays from issues.guix.gnu.org page <cbaines>rekado, you're using fibers to serve requests right? Are all the threads busy? <rekado>no, we’re not using fibers because there was a bug with fibers + sxml <Blackbeard>rekado: I had been working on what you told me about the tags. I have the JavaScript and I was going to look at the code to get the list of tags <rekado>arf, something’s not working right <Veera>Blackbeard: Did not read well the mail. Isn't it about integrating systemd into Guix? Will systemd mechanism will run in Guix proper? <rekado>we got a bunch of 403s when fetching bugs from debbugs <rekado>I hope we haven’t been locked out <Veera>Blackbeard: Oh. Then just using systemd API in here. <Veera>Blackbeard: Ok. I will need to check a little. Advantages of Systemd API's. Well your proposal had the details. <Blackbeard>Veera: it was suggested on Guix website. I thought it was a cool project and something useful. But to be honest I did not come up with the idea :) *rekado copies backup of mbox files *rekado disabled the updater on issues.guix.gnu.org for now <TZander>ok, I have packaged this software. Now what? Does guix have an AUR? Or how do I make this available to the world? <rekado>we should catch debbugs errors like this rate limiting 403 *rekado goes away to have a break <cbaines>TZander, Guix doesn't have an Arch user repository, although I think Guix is available from an AUR <cbaines>TZander, if what you've packaged is suitable for Guix, I'd suggest submitting a patch. Otherwise, you can share it as a "channel". <TZander>Is the standalone package file (*scm) Ok, instead of a patch? <cbaines>TZander, the ideal thing is to submit a patch on top of the Guix Git repository. Perhaps try checking that out, and incorporating your package definition there. <dongcarl>TZander: Since electrum is in (gnu packages finance), I assume your software can reside there as well <lfam>I think the master branch is broken on CI since commit 1e96e6ac8bc0285cc2adfac4ac29b538b84d5dfc (the julia upgrade) <cbaines>This bit looks relevant from one of the logs Computing Guix derivation for 'armhf-linux'... builder for `/gnu/store/in2yaqql0dnw1bvz5222snq3d323gvm9-libgit2-1.0.0' failed previously (cached) <mbakke>lfam: I restarted the failed derivation, hopefully the next evaluation goes better. <pinoaffe1> http://dpaste.com/3S3F9MB < I've added two new user accounts (haiku and haiku-bot) to my system configuration, but after running guix system reconfigure the new accounts do not seem to exist (don't show up in /etc/passwd and the like) - anyone know what could be going wrong? <mbakke>the problem is that CMake does not work well for QEMU user-mode emulated armhf builds. <lfam>pinoaffe1: Did you reboot after reconfigure? <TZander>I'm happy to have packaged one thing, but this is really far more difficult than it should be. And not just learning curve either, just too many steps. <TZander>has anyone considerded working on a meta-packager? <TZander>Allowing packagers to write in a simple package format which can be checked/linted etc. Which maybe can get converted to the format your tools use? <TZander>with "simple" i'm thinking something like archlinux' format. <arwn>i'm thinking about installing guix but I need non-free drivers for wifi and graphics so GuixSD is out of the question. is it par for the course to start with a stable distro like centos or ubuntu lts and install guix on top of that or does the underlying distro not really matter? <drakonis>the issue with just the package manager is that its effects are limited unless you fully buy into the whole thing <lfam>I use Guix on Debian and it's great <lfam>arwn: Guix on another distro is not as complete an experience as Guix System, but it works really well <TZander>even just a way to lint a package would be nice. Without having to git clone, edit a huge file, commit (I forgot this one..) guix pull --url=[] and all that. Which takes 10 minutes. <lfam>It's a first-class supported use case, not something that maybe works <str1ngs>arwn: underlying disto does not matter. assuming your kernel is not extremely old <drakonis>its less exciting if you can't use it to manage everything <arwn>heard, maybe looks like i'll use debian then. off to do more research, thanks guys. <lfam>arwn: I wasn't specifically suggesting Debian :) Whatever you are comfortable with will work <str1ngs>arwn: there are some packages that would not work great. mainly things that use pulseaudio or mesa. in which case you can just use the disto provided package. <TZander>mbakke: hmm. Maybe nice to link that from the contribution part, where it just says you lint your package. No hint on how. <lfam>TZander: That is part of the Contributing section :) <arwn>lfam: i'm comfortable with debian, and i don't update often enough to use fedora so debian would be my first choice anyways <lfam>This kind of feedback is super valuable for those of us who've been drinking the kool-aid for years <lfam>It's hard to remember what it's like to begin <drakonis>there's a catch here, it does not accurately reflect how guix would model packages <drakonis>importers parse other formats to generate packages to some degree <drakonis>the nix importer does a surface level conversion to the format as it cannot reasonably model the nix language <drakonis>lfam: y'all gotta work on your guile documentation <lfam>What do you mean drakonis? <TZander>perfection is the enemy of good-enough. I understand that its impossible to get feature-parity and it will be limited. But, you have to understand, packaging a software in guix is more like editing an application which references a huge amount of sources. It takes time to even read the "code". Writing it is just painful at first. <drakonis>it relies way too much on the scheme books <lfam>But I have contributed hundreds of Guix packages <drakonis>there's a thing i've noticed that i'm not sure whether i like here <lfam>I feel like it's an okay compromise <lfam>pinoaffe1: Hm, it should have worked then. You'll probably have to share your config.cm <TZander>Silly question; my english is apperently not helpful as 'article' here doesn't mean what I think it means... ;) Lint says: "no article allowed at the beginning of the synopsis" <drakonis>it is good for the package manager but it doesn't have a lot in the way of using guix features for far more complex tasks <drakonis>which then encroaches onto guile territory <lfam>That's true drakonis. We have recently added the "Guix Cookbook" to cover this sort of stuff <drakonis>use guix facilities to do elaborate system management trickery <lfam>It's a major reason I still use Debian for my primary computer, because systemd makes it really easy to do hard things <drakonis>shepherd is great but its docs are desolate <lfam>shepherd is cool but still quite simplistic <lfam>And yes, the docs don't get a lot of love <pinoaffe1>TZander: "article" can also refer to a word like "a" or "an" (as in "an apple") <drakonis>it needs more scaffolding and parallelism <lfam>There is no shortage of available tasks <lfam>Even just writing wishlists and criticism is useful <lfam>I used Debian before systemd and the difference made me love systemd and journald. I know people don't like those programs but for me, they were great, and made it possible to ditch my macOS computer <drakonis>need user stories that don't assume you're already fully buying into guix <lfam>That level of easy customizability and debugability were huge <drakonis>i have been running nix again and there's a world of difference <lfam>Hm, not sure about your user issue pinoaffe1. Either wait for more advice here or ask on <help-guix@gnu.org> <drakonis>if you get me winded, i'll go on for hours <lfam>Something I struggle with on Nix is more basic stuff. Like, what command do I use to install package? What is the package even called? <lfam>I chose Guix because that stuff was more clear <lfam>I didn't know Scheme or the Nix language <drakonis>scheme is fairly easy to learn because it is very simple <lfam>Yeah, but people learn syntax quickly <TZander>a very simple language, the problem is the long list of imports and the long, undocumented, list of "targets". "like which build-ssytem targets are there?) <lfam>You can run the guix-daemon with --disable-chroot <lfam>Yeah it's useful but what's the point <lfam>You could just use an old-school distro <drakonis>it opens doors for plenty of things for a user perspective <ilikeheaps>I want to run Nix on GuixSD. I found nix package but I can't use it - it tries to access /nix even though I set NIX_STORE_DIR and so on to somewhere in home directory. Do I need to do something more complicated than that? <lfam>Personally I fear the deluge of support requests from people with broken software <drakonis>have policy to not allow it in the main repository <lfam>Yes, but people can still send email <drakonis>people can do it with their own local builds <lfam>Well, that's my only real objection. If there was a consensus in favor I wouldn't make a big stink <lfam>It's true that Guix wants you to do it our way <lfam>Eh, that's a red herring IMO <drakonis>i'd definitely use impure builds as a way to have a CI <lfam>I'm curious, have there been any presentations or papers on the subject from Nix world? <lfam>Yes, and how it's been in practice <lfam>It's an interesting topic since it goes against the grain of Nix / Guix <lfam>Anyways, it should be possible now with a Guile script to programatically generate package definitions or derivations *after* fetching the source code <ArneBab_>LD_LIBRARY_PATH=$HOME/.guix-profile/lib/ bash <ArneBab_>is there a way around this? I must get scripts to run that need libraries installed in my profile <drakonis>impure builds doesn't imply that either guix or nix cannot manage what comes out <drakonis>there has however been an implementation of such a thing <ArneBab_>without LD_LIBRARY_PATH I have java programs that fail on fontconfig <TZander>the docs state that I shoudl use 'git send-email', whcih looks like I need to tell git my smtp etc. Not going to do that. Is it Ok to just attach a git-format-patch file to an email? <TZander>oh, ignore that. This git-send is only for patch-series. <ArneBab_>I can pass only the exact fontconfig library in LD_LIBRARY_PATH, but that’s brittle: guix gc could kill it. <civodul>ArneBab_: the GC "sees" your LD_LIBRARY_PATH <pinoaffe1>TZander: it's ok to send a git-format-patch by another email client, though some client might garble it up <civodul>i didn't read what came before so i can't tell :-) <joshuaBPMan>Hey guix! I've got to recreate my gpg key again...does anyone know of a "create a master gpg key guide to save to your flash drive" somewhere? <ArneBab_>(but there’s a special IRC magic which fired right now: I spent the hole afternoon and evening trying to get this to run, and I tried setting LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:/gnu/store/rkq6ipys8hf5hw66jkzzw4nfr6ncq96a-fontconfig-2.13.1/lib/ only now, and it gets the prog to run <ArneBab_>civodul: yes, LD_LIBRARY_PATH is evil, but less evil than "my program does not start" <rekado>TZander: did you know that Guix supports JSON formatted package definitions? <drakonis>rekado: is this somehow something to do with how JSON-y nix is? <drakonis>rather, does it have something to do with how JSON-y nix feels? <rekado>TZander: note that Guix has been translated into a number of languages, so if you’re not comfortable with English for the output of “guix lint” you can set LANG to switch to a different language. <rekado>drakonis: no, it literally imports packages from JSON files. <rekado>it’s not very useful for complicated packages because for custom build phases you really do need a programming language <rekado>but it’s fine for simple packages. <TZander>how long does it normally take for a patch to get applied? <arwn>does the first `guix pull` usually take 10+ minutes? <mbakke>arwn: it depends on whether substitutes for 'guix pull' are available <rekado>oof, turns out that the new mbox fetching caused high system load on debbugs.gnu.org :( <mbakke>TZander: how long a patch takes to be merged is contingent on many different variables, the answer is something in between "five minutes" and "two years". <mbakke>TZander: pinging the debbugs issue or this channel tends to help, though <TZander>mbakke: :D I'd love for 40061 to be merged <TZander>sounds like low hanging fruit for an actual guix dev. But I could be wrong. <mbakke>TZander: can you rebase it on the current master branch and re-send it? the patch did not apply for me :-) <TZander>hmm. I did that about half an hour ago <mbakke>I blame rekado for breaking debbugs earlier today :P <rekado>I should not be allowed around computers <rekado>I thought I was *reducing* load, not increasing it. <lfam>"We broke it" like last week by sending an email to an address that didn't exist <rekado>I made too many requests for mboxes; apparently this is much more expensive than fetching messages via the SOAP service which we had been doing in the past <mbakke>rekado: lol, debbugs is indeed more fragile than what one would expect by such a battle tested software. NYF! <rekado>I don’t know, I think I really am to blame here. <rekado>probably should have used HEAD requests instead of GET. <lfam>Yes, you are to blame, but I wouldn't say you did anything wrong <rekado>or maybe asking for an mbox triggers some expensive operation in the background that is the same no matter if HEAD or GET is used. <lfam>But we should try to coordinate more with help-debbugs <lfam>I think we are also responsible for most of the bugs these days <TZander>rekado: in my company we tend to blame the last one that designed some crappy system, but is no longer working there. Safe blame. <rekado>(double blame in that case, then) <mbakke>TZander: as someone who has been "the person that designed some crappy system", that attitude is dangerous and tends to cause much more harm than good! I was horrified by some of the myths surrounding my work when talking to former colleagues after a few years. :-) <mbakke>I take great solace in the fact that my crappy system is still running the core business, with zero maintenance, some five years later after they tried migrating to Kubernetes :P <lfam>You should come back as a Kubernetes deployment contractor <TZander>fast forward 40 years and the COBOL problem re-occurs. With different software stacks, I'm sure. <mbakke>lfam: lol I have actually been considering that <mbakke>I know all the ins and outs, who better to migrate to a newer platform. <civodul>mbakke, cbaines: thanks for spotting & fixing the beancount issue <lfam>It's true TZander. This is why it's important to do a complete rewrite every 18 months <cbaines>I guess that issue with inherits is difficult to guard against. I'm surprised the Guix Data Service seemed to handle the packages fine though... <lfam>Inherited packages are kind of a pain <efraim>lfam: it seems to have fixed itself I guess. The only thing julia related I can think of is llvm-julia which inherits from llvm-6 <lfam>efraim: mbakke suggested it was due to the build failure of libgit2 on armhf. But yeah, looks like it's good now <TZander>I'm wondering if the smart way to do stuff is to do a pull before you go to bed, and then you can install stuff the next day being relatively confident that it will come prebuild from the ci.guix server. <lfam>Yes, or pull from a slightly old commit <efraim>gnurl took ~40 minutes on my machine when I last worked on it <efraim>there's the channels script rekado posted a few days ago to pull the latest guix revision that has a substitute <efraim>bah I seem to have closed the tab for that <civodul>a soft issue with inheritance is when it's used to factorize things <civodul>(this is not really news, factorization through inheritance in OOP has that problem) <efraim>rekado: yay! I was thinking of using it for my aarch64 boards <rekado>note that all the reporting is aspirational. None of the messages are printed. <rekado>oh, wait, in this version there are no messages *rekado runs low on sleep <Blackbeard>Is there a reason on why to choose the keyword #export or define-public <civodul>for an API, i find it clearer to add everything in 'define-module': imports, exports, etc. <civodul>but for packages, it would be cumbersome to have to list things in two places <str1ngs>civodul I figured that was the reasoning. so makes sense to me. <TZander>after a slow gnurl 'check' phase, I now am waiting even longer on the 'gnunet' check phase... ***ssouth is now known as simonsouth
<rekado>aren’t there any substitutes for that? <TZander>like the 'duration' indeed. That amount of seconds is 2020-04-07 20:26:50 GMT <simonsouth>Hey everyone. Is there a guide anywhere to building a Guix system for an ARM SBC? <simonsouth>I've just started with Guix and would like to put an image together for my ROCK64, but am kind of stumbling around right now. <civodul>simonsouth: there's no guide, but there's a couple of blog posts on specific boards <str1ngs>simonsouth: there is a u-boot-rock64-rk3328-bootloader bootloader. you can see beaglebone-black.tmpl for a board example <efraim>IIRC the rock64 is supported but I don't think the rock64pro is yet <str1ngs>simonsouth: I don't know about kernel support though <simonsouth>civodul, strings: Thanks. I noticed definitions for the ROCK64 so I assume someone has done this before. <simonsouth>A few Web searches haven't turned up anything, though. <simonsouth>I'm trying to follow the simple example in the manual (section 3.10) but the build is failing, apparently due to the guile-gcrypt module not being able to find guile.m4 at configure time (?). <dalz>?X'??=???????$[/???Y????!????N~!N?W^Z'w <simonsouth>Somehow I missed the fact there's a Guix blog. Reading now... <civodul>that blog is pretty cool BTW, highly recommended ;-) <joshuaBPMan>hey guix, I'm trying to set up an encrypted usb flash drive. <joshuaBPMan>I've got it all set. It's luksFormat, and I'm wondering if there is a way to tell guix to automount it when I plug it in. Even if I plug it in after I boot up. <cbaines>I haven't looked much at that bit of the code <usney>Do you guys when browsing the web constantly get a banner to accept the sites cookies? It seems more and more websites are doing this. <usney>The only solution is to block javascript to get rid of this annoying banners <swedebugia>@usney, this is because of EU and GDPR. With a cookie autodelete privacy is quite easily preserved. the banners are annoying to me also, and with autodeletion of cookies they continue to pop up. So this is actually bad for privacy because the best tool to avoid spying cookies makes the banners worse. :/ <usney>why am I seeing them if I am not in the EU or under the law of GDPR? <swedebugia>@usney, the companies don't know that. This affects all users because many don't filter on IP when showing the banner. The point is that even the citizens of EU do not want these annoying banners. <civodul>but! guix.gnu.org doesn't meddle with cookies, we're safe 