IRC channel logs

2020-04-07.log

back to list of logs

<civodul>dunno
<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...?
<joey>dunno
<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>err glu*
<str1ngs>mesa is a depends of glu, which makes sense. since glu is just higher level abstraction opengl
<str1ngs>abstraction of*
<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?
<Parra>is it source?
<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 :)
<alextee[m]>try (pwd) to see
*guix-vits that is how i like it: https://github.com/taisei-project/taisei/blob/master/README.rst , especially "or" parts <3
<rekado>guix-vits: “glu” works because it propagates “mesa”.
<rekado>if “mesa” works just use “mesa”
<guix-vits>rekado: i'll, thanks.
<leoprikler>you're working on taisei?
<joshuaBPMan>hey Guix, trying to use the nix service...
<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?
<guix-vits>leoprikler: yes
<guix-vits>leoprikler: (in games.scm): https://paste.debian.net/1138795
*guix-vits WIP
<guix-vits>seems that it's working (at least there)
<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
<joshuaBPMan>sweet.
<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...
<joshuaBPMan>Not a huge issue I suppose.
<joshuaBPMan>But kind of sad.
<joshuaBPMan>i'm going to reboot and see if that fixes anything.
<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
<guix-vits>leoprikler: ok, you win :)
<jonsger>janneke: https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/drafts/hello-hurd.md#n64 should be hello-hurd.img :)
<pkill9>rekado: can those HTS voices be converted from the old multi-file format to the new single-file format?
<guix-vits>/me devs rock:
<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?
<Parra>this line ( https://github.com/metacall/distributable/blob/ef921f12645137957ecec3e1c3d7da07bfa9c693/source/metacall.scm#L368 ) prints a list of files, how can I obtain the same list of files in #:patchelf-plan, and mapping all of them into the form of ("file" ("gcc:lib" "glibc")) ?
<Parra>this is the format I want: https://github.com/metacall/distributable/blob/ef921f12645137957ecec3e1c3d7da07bfa9c693/source/metacall.scm#L374
<Parra>and this ( https://github.com/metacall/distributable/blob/ef921f12645137957ecec3e1c3d7da07bfa9c693/source/metacall.scm#L376 ) is my attempt but it doesn't work
<guix-vits>Blackbeard: Gnome?
<Blackbeard>guix-vits: no, just StumpWM
<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>I am not sure how old is that one
<Blackbeard>but I've noticed it suspends since I installed guix
<Blackbeard>I rarely stay away for long
<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?
<leoprikler>guix is still compiling and I'm getting sleepy
<leoprikler>I'll tell you tomorrow if it worked
<Blackbeard>guix-vits: thanks!
<Blackbeard>leoprikler: good night
<raghavgururajan>Hello Guix!
<guix-vits>Hi raghavgururajan.
<raghavgururajan>o/
<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
<raghav-gururajan>Hello Guix!
<raghav-gururajan>Hello Guix!
<pkill9>why do the festival emacs modules have .scm suffixes?
<pkill9>ah well
<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
<Blackbeard> https://imgs.xkcd.com/comics/command_line_fu.png
<Blackbeard>hahahaha
<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).
<lfam>I see, thanks reepca
<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).
<jackhill>what do y'all think?
<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
<pkill9>that would be good jackhill
<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>Parra: http://paste.debian.net/1138812
<reepca>that should also answer your second question, hopefully
<jackhill>pkill9: #40478 submitted
***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>where is bill?
<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>long time, short time... no difference
<marmulak>wait a minute, what is "libdrm" doing in my libre system
<Veera>Hi Guix
<bricewge>Hello Guix
<user_oreloznog>Hi!
<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?
<bricewge>xelxebar: I only see a reboot command
<marmulak>guix system reconfigure covers updating the system's guix-daemon, doesn't it?
<xelxebar>bricewge: Yeah, me too.
*xelxebar shrugs
<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
<Kimapr>ah nvm it works with vlc
<raghavgururajan>Hello Guix!
<marmulak>hello
<marmulak>how are you guruji
<raghavgururajan>Folks! How to find list of required dependencies from configure file, inside source tarball?
<raghavgururajan>marmulak I am good. How about you?
<marmulak>pretty good
<marmulak>learning to use guix system
<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
<raghavgururajan>str1ngs Okay. Thanks!
<raghavgururajan>marmulak Nice!
<marmulak>it's pretty cool
<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
<str1ngs>s/me/be
<marmulak>if edge cases are many doesn't that not make them edge cases
<str1ngs>not if the edge case are unigue
<str1ngs>unique*
<marmulak>aren't all cases unique
<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.
<raghavgururajan>I see.
<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.
<raghavgururajan>strings Thanks for the information, I will look into them. :-)
<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!!!
<marmulak>what is that
<xelxebar>Google's virtual servers
<marmulak>nice
<xelxebar> https://lists.gnu.org/archive/html/guix-devel/2017-01/msg01815.html
<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
<guix-vits>Hi Guix
<raghavgururajan>Folks, where do I find "ft2build" header file? I tried 'libxft' and 'freetype' as inputs. I still get:
<raghavgururajan>fatal error: ft2build.h: No such file or directory
<raghavgururajan> #include <ft2build.h>
<bricewge>raghavgururajan: Looks like it's in freetype
<bricewge> https://github.com/NixOS/nixpkgs/blob/master/pkgs/tools/system/plan9port/default.nix#L54
<bricewge>o/
<raghavgururajan>bricewge Hmm, freetype is already there as input.
<marmulak>does guix utilize smp in any way?
<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
<raghavgururajan>bricewge Thank you!
<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.
<eric-guix>hi, all
<bricewge>Hello
<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
<eric-guix>?
<bricewge>That looks interesting
<kondor[m]>liberdiko: share on what, installing guix on what? :D
<eric-guix>kondor[m]: +1
<bricewge>I mean xelxebar
<kondor[m]>oh
<bricewge>Sorry for the mismatch :s
<kondor[m]>phew
<kondor[m]>ML=mailing list i suppose
<bricewge>yes
<guix-vits>marmulak: my `lscpu`: "Vulnerability Mds: Vulnerable: Clear CPU buffers attempted, no microcode; ___SMT disabled___"; check yours :)
<marmulak>ok
<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
<eric-guix>bricewge: Thanks!
<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>maybe more than one
<eric-guix>oh, i read it now
<civodul>Hello Guix!
<marmulak>buna dia
<eric-guix>Buon giorno
<user_oreloznog>o/
<civodul>heh, bon dia a tothom :-)
<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.
<bricewge>xelxebar: Awesome, thanks!
<marmulak> https://ci.guix.gnu.org/api/queue?nr=1000' returned 504 ("Gateway Time-out")
<marmulak>hmm
<eric-guix>It happen also to me
<eric-guix>with "guix weather icecat" and I also discover that there aren't subtitute :/
<marmulak>that's the problem
<civodul>indeed, no icecat substitute yet
*civodul kicks ci.
<marmulak>zkurvysyn
<eric-guix>I also launch "guix weather" and it show me 85%
<marmulak>should be 100%
<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
<leoprikler>sneek: later tell guix-vits still fails
<sneek>Okay.
<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!”.
<sneek>Okay.
***rekado_ is now known as rekado
<rekado>bricewge: it’s time sensitive
<sneek>rekado, you have 1 message!
<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!”.
<bricewge>WDYM?
<rekado>bricewge: there are a bunch of anti-SPAM measures implemented.
<rekado> https://git.elephly.net/gitweb.cgi?p=software/mumi.git;a=blob;f=mumi/web/controller.scm;h=6ca7627b3d02dd3c2b2700bcf86de4b70fc9efb3;hb=HEAD#l129
<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>janneke: I’m sure it could
<civodul>yay
<rekado>but I haven’t yet looked at the perl code at all
<rekado>because I like my residual sanity a bit too much
<rekado>perl makes me twitch
<civodul>sounds reasonable
<civodul>stay safe, stay at home
<rekado>:)
<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
<janneke>rekado: yeah $_`#@
<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.
<civodul>help-debbugs@gnu.org
<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 :-)
<bricewge>That's for sure!
<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
<bricewge>Not having this 7 year old bug from Debbugs https://debbugs.gnu.org/cgi/bugreport.cgi?bug=15361 would be so nice
<rekado>I’m fearing that there might be demangs for bug compatibility and https://xkcd.com/1172/
<rekado>demands*
<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[m]: guix package -S0
<str1ngs>marmulak: ^
<marmulak>oh smart
<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?
<marmulak>25
<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.
<janneke>right!
<str1ngs>marmulak: if you do guix package -S25 and then guix package --roll-back . that should do the trick
<marmulak>oh that's magic
<marmulak>my generation is 0 again!
<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
<marmulak>hmm yeah
<str1ngs>most people dont like to use gc .. just saying
<str1ngs>I know I don't :P
<marmulak>then what do you do
<marmulak>to clean your store
<civodul>rekado: i think a tricky part in Debbugs is handling incoming email: addresses, control requests, etc.
<str1ngs>marmulak wait many months lol
<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
<str1ngs>s/think/thing
<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`
<guix-vits>FAIL: tests/build-utils.scm
<sneek>guix-vits, you have 1 message!
<sneek>guix-vits, leoprikler says: still fails
<guix-vits>leoprikler: what fails?
<leoprikler>gameplay
<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
<fishinthecalcula>leoprikler: Thank you a lot, I will definitely try that!
<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
<rekado>(am I too jaded?)
<civodul>ah, dunno
<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
<civodul> https://issues.guix.info/issue/40422 is 500
*rekado checks
<rekado>the problem is that there are no messages returned for that bug
*rekado checks more
<rekado>…and that’s probably because the indexer didn’t get run yet
<rekado>refreshing our local set of emails is terribly slow
<rekado>unreasonably so
<rekado>it’s now at 1571/1742
<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
<rekado>I wonder what’s up
<leoprikler>that would be one idea
<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`
<guix-vits>like this
<leoprikler>hmm
<leoprikler>I did `./pre-inst-env guix environment --ad-hoc taisei -- taisei`
<guix-vits>i'll do it too... soon
<guix-vits>devs of taisei are wonderful: some steps are failing, but there is enoug "or" set for build to success
<leoprikler>sounds like a mess
<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 :-/
<civodul>yeah
<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?
<rekado>yes
<rekado>I think that would be useful.
<rekado>would solve a lot of problems
<civodul>actually, mailman exposes mbox files too
<civodul>dunno if that would help
<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 :-)
<civodul>ah yes
<leoprikler>what about hash/mtime?
<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>The Modified-Since header perhaps
<leoprikler>wget -N uses that and it's a charm
<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
<civodul>right, that'd be a real issue
<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>(these files are append-only)
<rekado>looks like debbugs does support Range requests
<rekado>but I don’t see the size in the headers
<rekado>but that’s fine
<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?
*guix-vits in case someone interested: https://paste.debian.net/1138856
<Parra>reepca: I've tried your code but it doesn't work, maybe I added it improperly: https://github.com/metacall/distributable/blob/df695f8e04e4c1eb591ea4bd5a4a9493772ab2f2/source/metacall.scm#L364
*guix-vits fun-time (possibly a fake): https://paste.debian.net/1138854
*civodul closes another 2017 bug \o/
<janneke>\o/
<janneke>2017, a good bug-year
<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>not patchelfing
<Parra>on sec
<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>guix-vits: windowed on GNOME is the default rn
<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>g_bor[m]: where as we for GSoC?
<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
<Parra>I see
<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>it's got a useful enough docstring: https://git.savannah.gnu.org/cgit/guix.git/tree/guix/utils.scm#n364
<Parra>I prefer the hack XD
<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 see
<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...
<xelxebar>What could cause this?
<Parra>I don't know the language yet, so I prefer the simple solution
<Parra>reepca: it worked now, thanks for your time mate
<reepca>Parra: 👍
<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")
<Parra>sorry, '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
<Parra>it worked like a charm!!
<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
<cbaines>→ guix build ledger
<cbaines>error: beancount: unbound variable
<cbaines>The actual output isn't more useful: http://paste.debian.net/plainh/83f6024c
<raghavgururajan>Folks! I am kinda confused. The package I am trying to build has dependency for libxft. I have put it as input.
<raghavgururajan>I got:
<raghavgururajan>Xft.h:39:10: fatal error: ft2build.h: No such file or directory
<raghavgururajan> #include <ft2build.h>
<raghavgururajan>So I also added freetype as input, which provides ft2build.h file.
<raghavgururajan>But I still get same error. Am I missing something?
<raghavgururajan>bricewge ^
<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.
<raghavgururajan>I have there in configure file.
<raghavgururajan>XFTCFLAGS="-I/usr/include/freetype2"
<raghavgururajan>XFTLIBS="-lfreetype -lfontconfig -lXft"
<raghavgururajan>*these
<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.
<leoprikler>yeah, you'll have to substitute* XFTCFLAGS
<raghavgururajan>Okay. So what the value should be?
<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.
<raghavgururajan>XFTCFLAGS= --> assoc-ref %build-inputs "freetype"?
<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")
<raghavgururajan>leoprikler Should I keep the "-I"?
<leoprikler>yes
<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.
<raghavgururajan>leoprikler I stilll get the same error. Here is the pack-def, https://bin.disroot.org/?401fef868efd70ca#BWxZhpikTAFMcQsd1PGVPGiboDwacx9TR8AQ9AVHdgNx
<leoprikler>that's because you're goofing around
<leoprikler>you have to substitute the relevant code
<leoprikler>before bootstrapping
<leoprikler>(equivalently after 'unpack)
<raghavgururajan>Hmm. Okay
<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?
<leoprikler>("the build fails" = "the program crashes")
<guix-vits>leoprikler: what build fails?
<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
<raghavgururajan>leoprikler It worked. Thank you!
<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).
<xelxebar>Blargh.
<guix-vits>leoprikler: can't reproduce it on my box :(
<leoprikler>yeah, it's probably related to graphics card, I'm using some older NVIDIA
<alextee[m]>sherlock-lv2's test suddenly fails
<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]>(it breaks during guix upgrade now)
<alextee[m]>is there a way to set a priority on patches? this is probably a bit higher than normal
<rekado>“severity:important”
<alextee[m]>rekado: where does that go? anywhere in the subject field?
<rekado>alextee[m]: start the message body with “Severity: important”
<rekado> https://debbugs.gnu.org/Reporting.html
<alextee[m]>oh nice a debbugs manual, thanks ! rekado
<bricewge>civodul: Really nice to hear! I hope it will pan out.
<rekado>alextee[m]: I hope it won’t be needed for long
<bricewge>leoprikler: I don't think shepherd can clean zombie or else I would like to know how too. Since it's macron maybe it's related to https://issues.guix.info/issue/36838
<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.
<leoprikler>well, macron doesn't clean up either ;)
<civodul>that one is responsible for lots of things, but not zombies
<civodul>:-)
<raghavgururajan>bricewge All good now. :-) leoprikler's suggestion worked.
<raghavgururajan>bricewge I am packing 'fox tool-kit'.
<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
<rekado>hu
<raghavgururajan>bricewge http://debbugs.gnu.org/cgi/bugreport.cgi?bug=40484
<raghavgururajan>Guix now has FOX Tool-Kit ^
<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>xelxebar: Regarding the serial console settings it worked well for me on bare-metal. Did you configured it similarly to this https://lists.gnu.org/archive/html/guix-devel/2019-12/msg00346.html ?
<marmulak>I think guix overpowered my vm
<bricewge>raghavgururajan: Well done, I didn't knew this GUI toolkit.
<raghavgururajan>bricewge :-)
<xelxebar>bricewge: the only differenec with my setup being that I'm using grub-bootloader instead of grub-efi-bootloader...
<bricewge>Weird...
<mbakke>rekado: I'm getting a 500 response on this page: https://issues.guix.gnu.org/issue/40482
<mbakke>browsing other issues seems fine
<mbakke>maybe it's too new?
<mbakke>civodul: is it OK to work around https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40482 by simply changing the order of those tests for now?
<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 :-)
<civodul>can we postpone that a bit?
<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>get translations updated
<civodul>we don't have any tests for the binary tarball on foreign distros
<civodul>so that would be one thing to test
<mbakke>phew, NEWS update, maybe we should make a habit of updating it more frequently
<civodul>yeah
<civodul>i started preparing the blog post, which will serve as a starting point for NEWS
<civodul>i'll push that soon
<mbakke>terrific :-)
<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)
<mbakke>i.e. is the order significant?
<marmulak>I think a lot of people are learning about guix now that they under house arrest
<leoprikler>guix build toilet-paper
<marmulak>currently broken
<guix-vits>i'm join the club: "guile: warning: failed to install locale"
<marmulak>guix-vits: foreign distro?
<guix-vits>marmulak: no, `guix environment --pure guix`
<marmulak>wow
<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
<civodul>arrgh
<janneke>oh!
*rekado updates mumi on issues.guix.gnu.rog
<rekado>*org even
*janneke retries building guix for nth time today
<leoprikler>okay, can someone explain me the difference between `guix build` and `guix environment --pure -- make`
<janneke>bah, mosh does not forward agent
<jonsger>rog ^= republic of guix :P
<leoprikler>specifially w.r.t. glib
<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>Is it possible to use clang compiler in gnu-build-system?
<janneke>civodul: ah, good...progress :)
<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
<raghavgururajan>rekado Is it part of the build log or part of the source tarball?
<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.
<raghavgururajan>rekado I see. How do I access that file? In /tmp?
<rekado>raghavgururajan: build with “-K” and then look in the directory it leaves behind.
<raghavgururajan>rekado Cool! Let me try that.
***ssouth is now known as simonsouth
<raghavgururajan> https://disroot.org/upload/YziuWt7xTUYpnTv9/config.log
<raghavgururajan>rekado ^
<janneke>civodul: started the debian hurd, but i can't seem to find a bdf font, only utilities?
<raghavgururajan>I am not able to understand the contents of that file.
*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
<raghavgururajan>guix-vits Configure flags? yes.
<rekado>raghavgururajan: it’s a verbose log of what configure tried to do and the results of these checks.
<guix-vits>raghavgururajan: thanks
<rekado>you got an error “C compiler cannot create executables”, so search it in that file
<rekado>there’s one match
<rekado>above that is the test program it tried to compile
<rekado>and above that it shows a good error: ld: cannot find -lX11
<raghavgururajan>Thanks. I am kinda thinking it couldn't set correct Architecture
<rekado>that’s why it failed.
<raghavgururajan>Oh
<raghavgururajan>So it needs libx11 as input?
<civodul>janneke: yeah, dunno!
<rekado>raghavgururajan: probably
<civodul>i'm pretty sure i did something back in my Nix days
<civodul>but i can't find it
<janneke>it could be that urw-fonts are BD fonts
<raghavgururajan>rekado Thanks for guiding me step by step. I appreciate it :-)
<mbakke>rekado: issues.guix.gnu.org a really great tool for triaging bugs, so thanks :-)
<rekado>mbakke: it’ll get better!
<mbakke><3
*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.
<mbakke>rekado: another 500 issue, this time pretty old: https://issues.guix.gnu.org/issue/30312
<usney>hi rekado
<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.
<civodul>there's this bug about guix pull telling the user to run guix pull: https://issues.guix.gnu.org/issue/36374
<civodul>i'm not sure what to do about it
<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>leoprikler: Can you please test it with `taisei --renderer gles30` https://paste.debian.net/1138890 ?
<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>civodul: what about something along these lines? https://paste.debian.net/1138893/
<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'll give it a try.
<joshuaBPMan>mbakke: I'm running libreboot! No GPU is being used!
<rekado>surely you have 2D acceleration?
<rekado>using the GPU
<mbakke>joshuaBPMan: not even the built-in Intel GPU?
<joshuaBPMan>mbakke: It does use the built-in Intel GPU.
<joshuaBPMan>That does not required any proprietary firmware.
<joshuaBPMan>rekado: How do I test if I have 2D acceseration?
<joshuaBPMan>I'm guessing that I do, but I'm not certain.
<joshuaBPMan>mbakke: I wish the Libreboot came with a bundled old nvidia GPU. The old nvidio GPUs are pretty much reverse engineered these days.
<joshuaBPMan>joshuaBPMan is downloading supertuxkart
*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?
<kondor[m]>oh man, when is that maven build coming ...
<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?
<fishyfriend>it is my first msg to guix-patches
<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.
<fishyfriend>40276
<rekado> https://issues.guix.gnu.org/40276
<rekado>looks like it was sent to the wrong list at first
<fishyfriend>hmm, it seems https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40276
<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.
<rekado>*here
<fishyfriend>i don't think so, just a barebones from/subject/date iirc
<rekado>weird!
<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: no.
<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>and HOME is not necessarily set
<pkill9>rekado: https://paste.debian.net/plain/1138894
<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
<leoprikler>guix-vits: gles30 works, thanks
<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"))))))))'
<rekado>unbalanced parens!
<pkill9>:P it seemed to work anyways :P
<eric-guix>There is some commando to download only the source and one for calculate size of the source
<eric-guix>?
<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
<guix-vits>eric-guix: math-commando :)
<pkill9>rekado: maybe doing what this package does could make the HTS voices work? https://aur.archlinux.org/packages/festival-hts-voices-patched/
<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: that's a good idea
<pkill9>here https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=festival-hts-voices-patched#n38
<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>oh ok
<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
<marmulak>mbakke: I'll try
<mbakke>marmulak: I haven't tried it myself, but know others have been using flatpak without special privileges
<marmulak>it seems like it should work
<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
<marmulak>does guix not have thunderbird?
<pkill9>apparently not
<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
<user_oreloznog>It has also claws-mail
<eric-guix>best things in my opinion is to use flatpak
<pkill9>claws-mail is great
<user_oreloznog>pkill9: +1
<eric-guix>user_oreloznog: it work 100% ?
<mbakke>eric-guix: evolution should certainly work, what service is missing?
<user_oreloznog>I think 98% I think...
<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
<eric-guix>mbakke: some times ago*
<pkill9>evolutuion also needs evolution-data-server installed
<user_oreloznog>For my use, it's sufficient
<guix-vits>bricewge: it's different accs, afaik
<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>Well I'm about to run supertukkart.
<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
<bricewge>Thank you rekado :)
<joshuaBPMan>mbakke: so I can run supertuxkart.
<joshuaBPMan>It runs fairly smoothly
<marmulak>gotta run supertuxkart!
<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?
<mbakke>lfam: good to know :-)
<marmulak>that runs quite well for me
<marmulak>(ungoogled-chromium, I mean)
<marmulak>considering that I'm using a vesa framebuffer
<joshuaBPMan>mbakke: yes sir. Specifically I tried ungoogled-chromium and ungoogled-chromium-wayland
<joshuaBPMan>and yesterday I tried epiphany.
<mbakke>joshuaBPMan: wayland, interesting -- which window manager are you using?
<civodul>rekado: there's a CSS issue that bothers me, dunno if it's fixable: text, e.g., at https://issues.guix.gnu.org/issue/39729 is wrapped, as if the box was just slightly too narrow
<rekado>civodul: it’s been bothering me too!
<rekado>but I don’t know how to work around it.
<rekado>should it overflow instead?
<rekado>civodul: are you using the latest CSS…?
<rekado>(try bypassing the cache)
<rekado>I did resize things a bit to make this issue less annoying in most cases.
<rekado>in icecat: Ctrl-F5
*raghavgururajan says XFE File Manager is now in Guix. (#40487). \o/
<joshuaBPMan>mbakke: sway.
<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.
<rekado>can you share details?
<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>webstrand: Btrfs subvolume no good
<bricewge>It won work, there is patch pending though
<bricewge>s/won/won't/
<bricewge> https://issues.guix.info/issue/37305
<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>finished the update
*rekado stops fiddling with it for today
<mbakke>civodul: \o/
<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
<rekado>mbakke: https://issues.guix.gnu.org/issue/30312 works now
<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>I think it's ~1 GB
<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.
<bricewge>nagamalli: Have a look at help2man
<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
<bricewge>nagamalli: There are 2 version defined
<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.
<nagamalli>bricewge: thanks i will try
<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>I was also looking at https://www.serveraptor.com/ recently, as I thought they offered Debian GNU/Hurd hosting at one point
<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
<marmulak>dino on guix seems really out of date
<efraim>digitial ocean?
<lfam>Either way works
<rekado>marmulak: do you want to upgrade it?
<raghavgururajan>cbaines lfam https://1984hosting.com
<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
<rekado>marmulak: I suggest these tutorials: https://guix.gnu.org/videos/
<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.
<lfam>Oh cool
<marmulak>raghavgururajan: you seem like a pretty capable guix packager
<raghavgururajan>marmulak I had my days of messing things up ;-)
<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?
<kondor[m]>* two different versions of a program :)
<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>I guess it's just gcc
<marmulak>or some c compiler
<marmulak>is there a command to run which can tell which guix package provides a certain command?
<lfam>No marmulak
<lfam>cc is from GCC
<marmulak>ok cool
<kondor[m]> guix edit python3
<kondor[m]>guix edit: error: python3: unknown package
<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>kondor[m]: python is version 3.7.4
<marmulak>apparently "gcc" is not a package
<str1ngs>maybe use guix search and guix show more :)
<kondor[m]>thanks all of you
<str1ngs>marmulak: for gcc use gcc-toolchains
<str1ngs>marmulak: gcc just won't work it needs specs files etc for guix.
<str1ngs>marmulak: err gcc-toolchain
<marmulak>guix search first hits are "libgccjit" and "gccgo", real helpful... but on the other hand, gcc-toolchain was #3 so not so bad
<marmulak>sweet
<str1ngs>marmulak: gcc is there but it's hidden. to avoid confusion
<marmulak>that's good
<marmulak>I wonder if clang provides cc
<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>for gcc 'cc' is a symlink to gcc.
<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`
<guix-vits>*or building
<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>* package@x.y
<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`>not really set up for this, still
<nikita`>i hope to get back to this somewhere between now and 2021
<mbakke>brendyyn: is this bug still relevant? https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38414
<nikita`>or having ported guix to netbsd native, whatever happens first
<marmulak>guix on bsd = lol?
<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
<nikita`>thanks
<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
<marmulak>great
<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
<nikita`>well, not hacky
<marmulak>mbakke: thanks
<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
<nikita`>or one of them wants guix or nix
<marmulak>pkgsrc is a good tool
<marmulak>perhaps instead of porting guix to netbsd, port netbsd kernel to guix system
<nikita`>no
<marmulak>guix/knetbsd
<nikita`>but I'm too tired to go into this
<marmulak>lol
<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))
<TZander>why does it say "invalid keyword"
<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`>same thinking i had
<nikita`>and it could work for netbsd in a way
<nikita`>because we have rump, etc
<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`>even hurd uses parts of our code
<cbaines>TZander, could you upload the package definition to http://paste.debian.net/ ?
<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
<TZander>I'm not managing to understand this weird packaging format... any help? https://paste.debian.net/1138925/
<cbaines>TZander, the (replace bit looks like it should be part of (modify-phases %standard-phases
<TZander>thanks
<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>Yes TZander
<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
<Blackbeard>Hello Guix :D
<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?
<TZander>lfam: sweet, thanks
<Veera>nikita`: Hi
<Veera>nikita`: I was able to package Xplanet for guix with part of your inputs and other members here.
<Veera>nikita`: Its in Guix now!
<Blackbeard>Veera: :)
<Veera>Blackbeard: Hi
<nikita`>Cool
<Veera>Blackbeard: I asked on other day, about your project on gsoc
<Veera>nikita`: thanks
<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
<rekado>Veera: no.
<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
<rekado>it’s just a single process
<rekado>oops
<rekado>help needed!
<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>gotta go
<Blackbeard>rekado: good luck (:
<Veera>My bug report is not showing atleast when till now (checked 4 hours ago) https://issues.guix.gnu.org/issue/40376
<rekado>arf, something’s not working right
<Veera>oh
<Veera>Blackbeard: Did not read well the mail. Isn't it about integrating systemd into Guix? Will systemd mechanism will run in Guix proper?
<Veera>Or systemd binary itself?
<Blackbeard>Veera: my project is not about that :(
<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.
<Blackbeard>Veera: yes, working on Shepherd :)
<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
<Veera>Blackbeard: Ok.
<Veera>I have to go...
<Veera>bye
<Blackbeard>Veera: good luck (:
*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>help welcome!
*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".
<guix-vits> https://guix.gnu.org/manual-devel/en/html_node/Contributing.html#Contributing
<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)
<lfam> https://ci.guix.gnu.org/jobset/guix-modular-master
<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)
<lfam>efraim: Any idea? ^
<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?
<drakonis>do tell?
<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?
<drakonis>ah, right.
<TZander>with "simple" i'm thinking something like archlinux' format.
<drakonis>its never so siple
<drakonis>simple
<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
<TZander>drakonis: I like limited
<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
<mbakke>TZander: you don't need to 'guix pull' to test your changes, see https://guix.gnu.org/manual/en/guix.html#Running-Guix-Before-It-Is-Installed
<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
<arwn>str1ngs: heard
<TZander>lfam: reference, actually.
<TZander>sigh, ok. I'll stop complaining ;)
<drakonis>updates arent exactly a huge concern
<lfam>No TZander, don't stop!
<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>now, regarding metapackaging
<drakonis>there's a catch here, it does not accurately reflect how guix would model packages
<drakonis>see also lisp
<drakonis>importers parse other formats to generate packages to some degree
<drakonis>its not perfect
<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
<drakonis>so it is too strongly API reference
<lfam>I ... don't know Scheme
<drakonis>ah i see
<drakonis>then let's talk about the guix docs
<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
<pinoaffe1>lfam: yes
<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
<lfam>config.scm
<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>a la what people do with nix
<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
<pinoaffe1>lfam: posted it above, see http://dpaste.com/3S3F9MB
<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>systemd is a grand thing
<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>Help wanted drakonis :)
<drakonis>always
<lfam>There is no shortage of available tasks
<lfam>Even just writing wishlists and criticism is useful
<drakonis>oh that one's not lacking
<lfam>"User stories"
<drakonis>user stories are ever good.
<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?
<drakonis>they've changed the CLI
<lfam>I chose Guix because that stuff was more clear
<lfam>I didn't know Scheme or the Nix language
<drakonis>but it isn't the default yet
<drakonis>scheme is fairly easy to learn because it is very simple
<drakonis>nix has a bit of a heavier syntax
<lfam>Yeah, but people learn syntax quickly
<drakonis>wishlist: optional impure builds
<drakonis>these are useful for a variety of tasks
<lfam>We already have that
<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?)
<drakonis>oh?
<lfam>You can run the guix-daemon with --disable-chroot
<drakonis>oh no, not like that
<drakonis>i mean disabling the input checks
<lfam>Oh
<drakonis>the input is now mutable
<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?
<drakonis>that's not where i'm going
<drakonis>guix would still manage the end result
<lfam>Hm
<lfam>Personally I fear the deluge of support requests from people with broken software
<janneke>+1
<drakonis>have policy to not allow it in the main repository
<lfam>Yes, but people can still send email
<lfam>And do :)
<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
<drakonis>you can use it for mutable git repos
<lfam>It's true that Guix wants you to do it our way
<drakonis>something something freedom zero?
<lfam>Eh, that's a red herring IMO
<drakonis>of course it is.
<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?
<drakonis>on impure builds?
<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_>I get a segfault on
<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
<drakonis>it is being revived for flakes
<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
<ArneBab_>at all times?
<civodul>when it runs
<civodul>it's omniscient!
<ArneBab_>So I do have to set that globally?
<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 :-)
<civodul>(LD_LIBRARY_PATH is evil though)
<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"
<joshuaBPMan>I might have found it:
<joshuaBPMan> https://alexcabal.com/creating-the-perfect-gpg-keypair
<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.
<drakonis>or is it just a guile library?
<drakonis>i see
<rekado>I wrote this back in the day
<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?
<TZander>arwn: its not unlikely
<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
<TZander>you sure you have version 3?
<mbakke>TZander: weird, I see it here: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40061 , but it did not yet arrive in my mailbox
<mbakke>I blame rekado for breaking debbugs earlier today :P
<TZander>fair :)
<mbakke>TZander: https://git.savannah.gnu.org/cgit/guix.git/commit/?id=9f1b787120b1b81abffaf0fa13fdbdf4cca39f2d :-)
<TZander>awesome!
*rekado takes the blame
<rekado>:(
<rekado>writing an apology email now
<lfam>Debbugs broke again?!
<rekado>I should not be allowed around computers
<rekado>I broke it
<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
<mbakke>civodul: I'm not sure if updating Guix UI strings is OK just as 1.1.0 translations are incoming, let me know if you think https://git.savannah.gnu.org/cgit/guix.git/commit/?id=9f1b787120b1b81abffaf0fa13fdbdf4cca39f2d should be reverted temporarily
<lfam>I think we are also responsible for most of the bugs these days
<civodul>mbakke: it's not good timing indeed
<civodul>so yeah, maybe revert temporarily
<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
<TZander>LOL
<lfam>Hahaha
<lfam>That is sweet
<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>civodul, I just filed the bug :)
<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.
<TZander>gnurl 'checks' phase takes forever.
<lfam>Yes, or pull from a slightly old commit
<TZander>ah, thats an idea as well
<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>phases, specifically
<civodul>it can quickly become unfathomable
<rekado>efraim: here’s your tab https://paste.debian.net/1137596/
<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>never mind
*rekado runs low on sleep
<rekado>baby cries, gotta go
<civodul>say hi!
<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
<civodul>hence define-public
<civodul>does that make sense?
<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?
<rekado>no, only started https://ci.guix.gnu.org/build/2549237/details
<civodul>"Duration -1586291210 seconds"
<TZander>like the 'duration' indeed. That amount of seconds is 2020-04-07 20:26:50 GMT
<civodul>heh
<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>hi simonsouth
<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
<usney>rekado is bill okay?
<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>Ah, there's this: https://guix.gnu.org/blog/2019/guix-on-an-arm-board/
<simonsouth>Somehow I missed the fact there's a Guix blog. Reading now...
<Blackbeard>civodul: yes, thanks
<civodul>simonsouth: yup, and there's more: https://guix.gnu.org/blog/tags/arm/ :-)
<simonsouth>civodul: Great, thank you.
<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'm following the installation manual...to do so.
<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.
<civodul>cbaines, rekado: any idea why https://ci.guix.gnu.org/api/queue?nr=10 is slow (even with nr=10)?
<cbaines>None from me
<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