IRC channel logs

2021-04-20.log

back to list of logs

<civodul>roptat: yes, but pointer->diff-delta for instance creates a copy of the underlying C structure
<civodul>so at least the caller can capture those
<roptat>so, that means the pointer is not finalized by guile, right?
<roptat>which might be the reason why we don't have issues with it
<roptat>honestly I don't understand these issues very well
<civodul>the diff code might be leaking, though
<civodul>maybe not
<civodul>now, if it dose leak, Gitile will have to be restarted once in a while, so you'll know :-)
<civodul>*does
<roptat>civodul, well, it does, but I don't think it's related to memory consumption
<jgart[m]>nckx: python-hy is broken also due to python-funcparserlib failing: https://paste.debian.net/1194347/
<civodul>roptat: i looked at the diff code and added a test; it seems to be good
<civodul>so i think we can label that 0.5.1
<derivates>im installing firefox right now, just didnt know it was going to compile from source haha, how can i apot this with guix search?
<nckx>jgart[m]: The bright side is that's the only dependent...?
<nckx>derivates: ‘guix search’ doesn't tell you whether there's a substitute for a package, but ‘guix weather PACKAGE’ can.
<nckx>Firefox isn't in Guix proper, so unless someone (like the owner of the channel you're using) is running a substitute server *and* you've authorised it, you'll always have to build it (and other packages from that channel) yourself.
<derivates>i just notices this! my bad
<nckx>No bad; Firefox is free, and whatever more you may use at home is none of our business (but thanks for not mentioning them either).
<nckx>We think proprietary software harms people. We don't think people who (have to, or even choose to) use it are bad.
<nckx>We just ask that you don't promote it, or ask for support. </ramble>
<derivates>yeah i completely understand, i didnt double check the channel and also thought it would a default because it was open source
<roptat>civodul, thanks, let's do that, and update guix too!
<civodul>roptat: cool, i'll do that tomorrow!
<Noclip>Would it be a bad idea to run 'guix pull' on two users at the same time?
<nckx>No.
<Noclip>So it won't download and build stuff twice then?
<nckx>Nope.
<Noclip>Nice
<Noclip>Same with 'guix upgrade' and 'guix install'?
<pkill9>i think it waits for build slots
<nckx>Yes, Guix should always be parallel-safe, anything less is a bug.
<nckx>My ‘just update stuff’ script pulls for all users in parallel, and it's never failed. If it does, it is absolutely a bug we're happy to hear about.
<Noclip>How about invoking the garbage collector while installing/upgrading?
<nckx>The garbage collector takes a global lock on the entire system (it could be rewritten not to, but it's not that important), so it won't interfere with builds either or vice versa. And builds take temporary GC roots for their inputs so you won't have to rebuild them twice in the same invocation.
<Noclip>Ok
<nckx>Really, the rule is: if you do manage to break Guix merely by doing multiple things at once that are supported on their own, you've found a bug. The design allows it.
*nckx will probably think of an known exception at 4 AM, but arguably that would be a bug too...
<Noclip>How about restarting the guix daemon?
<derivates>theres something i dont quite understand quite well about Guix installaton intself, so i have my configs, now i should create an iso image for my laptop, but what about partitioning, what if my laptop does no longer have the scheme it used to when i installed the first time
<roptat>you'd have to change your file-systems declaration to reflect the changes
<jgart[m]>nckx: `guix refresh --list-dependent python-funcparserlib` says yes. python-hy is the only dependant
<derivates>right so when i boot up i dont use graphical but mabual instead!
<derivates>its unfortunate theres no video about this! :(
<jgart[m]>does anybody use dwm as their window manager with guix system?
<derivates>jgart: Im looking forward to it, will do once I set everything else, then ill get my st and dmenu builds as well
<derivates>im positive its not that hard you should be able to make your own scm file by using (inherit dwm) and modifying the url
<jgart[m]>That part I'm not clear on yet is the guix system configuration for running it. Ideally, I'd like to start xorg from a tty and with no display manager.
<jgart[m]>That's how I currently have my NixOS setup
<jgart[m]>but I'm using i3wm at the moment instead of dwm
<jgart[m]>It's probably something simple that I just haven't read yet.
<jgart[m]>I'll be happy to add an entry to the cookbook once I set myself up with that.
<derivates>I quickly found this hope this helps you and me on the future
<jgart[m]>derivates: What desktop environment or window manager are you currently using?
<derivates> https://gitlab.com/tkiat/guix-channel.git
<jgart[m]>I just came across that
<derivates>currently using awesome but havent touched anything just wanted any graphical thing to setup my system with Emacs
<jgart[m]>but that only shows how to package your own fork of dwm
<derivates>next step for me right now is get rid of this GDM Login Manager thing
<roptat>jgart[m], I know some people managed to use xinit
<derivates>I usually just use xinitrc file and startx
<derivates>that ^^^^
<roptat>I mean xinit the command, instead of startx that doesn't work with guix
<jgart[m]>roptat: do you happen to know who?
<roptat>no, sorry
<roptat>there might be some reports on the ML
<jgart[m]>what does the invocation look like for xinit on guix system?
<roptat>I think it's just xinit, but you have to configure something in your os declaration
<jgart[m]>oh ok.
<derivates>just found this cookbook thing!
<derivates>it has a stumowm guide!! finally
<jgart[m]>roptat: what non guix system distros have people tested guix-home-manager on?
<derivates>stumpwm**
<jgart[m]>derivates: that doesn't show it either
<roptat>jgart[m], https://lists.gnu.org/archive/html/help-guix/2018-07/msg00080.html
<roptat>jgart[m], er, none as far as I know
<jgart[m]>roptat: thanks! I'll take a look
<jgart[m]>roptat: We're starting work on packaging a bootstrappable crystal for guix: https://board.disroot.org/project/guix-packaging/us/15?kanban-status=12313
<jgart[m]>We're currently reading through this and translating to guile/guix https://github.com/crystal-lang/bootstrap-script
<jgart[m]>Here are some notes from the last meetup with questions at the bottom: https://github.com/ryanprior/guix-packages/blob/master/testing/crystal.org
<jgart[m]>Some of the software on that dependency list is pretty old but we need it in order to bootstrap the crystal compiler.
<derivates>so the most minimal thing to use right should be SLiM? instead of GDM?
<jgart[m]>yup slim, IIRC
<derivates>not a bad idea, ill mess around with that once I export everything to literate config
<jgart[m]>ohh Ludo mentioned a really nice idea here: https://lists.gnu.org/archive/html/help-guix/2018-07/msg00121.html
<jgart[m]>Does anyone know if that's been implemented yet?
<jgart[m]>*jgart goes off to read the guix bible (guix/)
<nckx>derivates: SDDM is also a contender. I don't care^Wknow who comes first in the minimal olympics, but at least it's maintained.
<nckx>jgart[m]: You can combine ‘extra-special-file’ and ‘xorg-start-command’ to create (say) /bin/startx. I did that once when I still used X. It worked, so I deleted it, satisfied.
<nckx>Had I kept it and sold one to everyone who's asked about it over the years since, I'd be rich.
<nckx>If it still works, maybe a cookbook item would make a nice LM workshop...?
<nckx>What did you mean by ‘review this server’ + URL? I missed you earlier.
<raghavgururajan>> ‎jgart[m]‎: ohh Ludo mentioned a really nice idea here: https://lists.gnu.org/archive/html/help-guix/2018-07/msg00121.html
<raghavgururajan>Is that been implemented in https://git.savannah.gnu.org/cgit/guix.git/commit/?id=e429325d37e5752656a03882f60ee56d4f541fd1 ???
<raghavgururajan>iyzsong: Can 'xorg-server-service-type' be used instead of display-managers? Would it start X on start-up?
<nckx>Oh!
<nckx>Is that new?
<roptat>jgart[m], thanks, that's something you'll work on this week-end, right?
<nckx>Newish.
<nckx>This is grand, thanks iyzsong.
<raghavgururajan>Yep! I appreciated iyzsong as soon as they committed it.
<raghavgururajan>Long awaited service-type.
*raghavgururajan stops sleep typing and goes to bed
<nckx>I appreciated them before that, too.
<nckx>Good night, Raghav.
<raghavgururajan>o/
<iyzsong>raghavgururajan: 'xorg-server-service-type' only add 'Xorg' to /run/current-system/profile/bin, to use it you have to run 'sx' from console.
<derivates>SDDM feels a bit plastic for me, to each their own I guess, good to know its mainted tho
<raghavgururajan>iyzsong: I see. Thanks for clarification.
<nckx>‘Plastic’?
*raghavgururajan now really goes to bed
*nckx pushes raghavgururajan gently back to bed.
<derivates>don't know if thats the correct term, but I feels its too flashy, too bright, idk..
<derivates>never been interested in KDE for example, more of a xfce/lxde guy
<derivates>actually I've never really lived in a DE, WM from the start
<nckx>Fair enough. It's themable.
<jgart[m]><nckx "If it still works, maybe a cookb"> sure, that would be great! Would you like to come show that or anything else you'd like to share? I can promote the event.
<jgart[m]>I'm planning on hosting an event (TBD) with Christopher Lemmer Webber and the racket/guix community to work on a racket-build-system together
<xelxebar>derivates: I use startx with Guix. Unfortunately, the startx script that installs with xinit is broken, but you can get around that with an appropriate `.xserverrc` in your `$HOME`: http://ix.io/2WGk
<jgart[m]>If you happen to know any racketeers who know their way around racket/raco well let me know.
<xelxebar>I'm working on patching the xinit package to fix startx, though.
<jgart[m]><roptat "jgart, thanks, that's something "> We might just work on packaging or updating something. It depends who comes and what people want to do. We can also break up into groups in rooms. Mumble supports that quite nicely.
<jgart[m]>I'm starting to work on the bootstrap crystal project whenever I can. If people want to pair on it out of the context of a meetup let me know also. Send all patches to upstream or ryanprior for merging into our working crystal bootstrap repo.
<jgart[m]>xelxebar: thanks for sharing!
<jgart[m]><nckx "What did you mean by ‘review thi"> I meant this one: http://donotshake.libremiami.org/
<jgart[m]>nckx: It's a substitute server.
<jgart[m]>It's not serving anything special at the moment.
<jgart[m]>We'd like to eventually get a channel going and provide a binary/service for wahay since it looks like our patch won't get accepted upstream because it is still in active development.
<jgart[m]> https://wahay.org/
<jgart[m]>I meant our patch for grumble. Wahay uses a fork of grumble repackaged as a library.
<jgart[m]>grumble is an implementation of murmur in golang. It doesn't maintain feature parity.
<derivates>xelxebar: very nice man!!
<jgart[m]>derivates: did you try it?
<derivates>I will very soon
<derivates>I will first switch to stumpw, I love chords
<jgart[m]>stumpwm was great when I tried. I really enjoyed it. I'd like to get back to it soon given that guix has the best infrastructure for experimenting with common lisp libraries
<jgart[m]>I highly recommend wigust's configs for stumpwm: https://github.com/kitnil/dotfiles/search?l=common-lisp
<jgart[m]>there's lots of great material there
<derivates>thanks, looks promising
<derivates>now i broke my system again
<derivates>wth
<derivates>Im getting base-operating-system unbound variable
<derivates>i literally had everything up and running, then i did a guix pull and all died
<PotentialUser-36>hello all, I'm seeing a difference in ld behavior between `guix environment --ad-hoc libev` and `guix package --manifest=... --profile=...`, the former doesn't seem to setup load paths and ld complains "cannot find -lev", while the latter creates a profile where ld can indeed locate libev. Am I misunderstanding how guix environment works?
<derivates>I'm getting error: base-os: unbound variable
<derivates>hint: Did you forget a `use-modules' form?
<derivates>which doesn't make sense because i'm delcaring (define-module (systems asus) #:use-module (systems base-sys) #:use-module (gnu))
<Noclip>Are there any plans for adding electron-based programms to the guix repo?
<derivates>anyone around? need a bit of help with a tiny problem with a module
<lfam>Howdy derivates
<lfam>Feel free to ask your question
<lfam>Oh, is it the question in the log?
<lfam>Is base-os exported from the module it's in? And is that module imported in your (systems asus) file?
<derivates>Hopefully this bin helps, https://paste.debian.net/1194357
<derivates>i think i moved a tiny little thing because it worked a few hours ago :(
<lfam>Does the filesystem directory structure that holds these files match the "module path" of (systems base-sys)?
<lfam>Like, is it stored in a directory structure like 'systems/base-sys.scm'?
<lfam>The module path should match the directory layout
<derivates>yeah, look https://paste.debian.net/1194358/
<derivates>i don't get it really, worked fine before
<lfam>It worked fine, and then it stopped working, after nothing changed at all?
<lfam>If so, it will be easiest to assist debugging if you can share these files
<derivates>I tweaked a few thing, please let me upload em
<lfam>Sure
<derivates>base-sys.scm :: https://paste.debian.net/1194361/
<derivates>asus.scm :: https://paste.debian.net/1194360/
<derivates>Makefile :: https://paste.debian.net/1194362/
*lfam looking
<gry>Hello! Is texmacs in repositories in guix? I have an issue with it in debian and would be interested in someone checking it on guix.
<derivates>gry: https://paste.debian.net/1194363/
<lfam>derivates: Nothing obviously wrong stands out to me but I'm not very good with Scheme
<lfam>If nobody else here has advice, you might as in #guile
<lfam>You might ask in #guile, I mean
<gry>derivates: could you please install it and attempt to reproduce a bug?
<gry>derivates: create a new document in it and start an interactive gnu/octave session via toolbar button
<derivates>ifam: thanks i will ask there!
<derivates>gry: yeah, let me get it
<derivates>lfam: actually mispelled
<gry>once done, please upload screenshot somewhere, it is visual defect
<lfam>That's okay :)
<lfam>derivates: One thing I tried was to add (use-modules (gnu) (systems base-sys)) to asus.scm
<lfam>With that, the error changes to this: https://paste.debian.net/1194364/
<lfam>As you can see, this error indicates that Guix / Guile knows where the variable might be defined, but it's not being made available in the right context
<lfam>I'd hoped this would solve it, but nope
<lfam>I also tried adapting the example use of 'base-os' from the Cookbook: https://guix.gnu.org/cookbook/en/html_node/Guix-System-Image-API.html
<derivates>right, mi client died
<derivates>lfam: ill check the cookbook !
<derivates>gry: are you here?
<lfam>derivates: I wonder if the problem is about the packages field of base-os
<gry>yes, i am
<lfam>You don't import any package modules
<derivates>gry: I creates a new doc, its blank
<derivates>lfam: how would you do it?
<gry>derivates: ok, second row of toolbars, last button, create new gnu/octave session
<lfam>derivates: I've never made this kind of "layered" config
<derivates>Start an interactive session it says
<derivates>It asks for Scheme, Shell, Remote, other?
<derivates>maybe I don't see any octave thing cus I don't have it
<lfam>I got it to work derivates
<lfam>Give me a minute to pare down the changes I made
<derivates>lfam: great!!!!!
<gry>derivates: sorry, i reproduce issue only with octave, would you mind installing it also to test?
<derivates>yeah I am installing it
<gry>thanks a lot, it is a pretty big package
<derivates>let me anticipate, don you think its more of a driver issue rather than a distro issue?
<derivates>I got it already
<gry>i think it may be issue with distribution, i'm wondering whether guix did anything about it
<derivates>gry: my texmaxcs explodes right after I click octave
<gry>does it do this each time?
<gry>or only the first time
<gry>it isn't the behaviour i experience, to me it writes something and stays open
<derivates>terminate called after throwing an instance of 'string'
<lfam>derivates: Hm, now I'm not sure. It's working for me without any changes
<derivates>running texmacs via terminal
<gry>okay. i'll try it in a guix in a short bit, thanks for checking
<lfam>Btw, you don't need to be root to use `guix system build`. The only thing that requires root is reconfiguring
<lfam>In general, any user can "build things" with Guix
<derivates>lfam: are you using the same commands?
<derivates>right ill take it off then
<lfam>I changed the build-asus Makefile target to not use sudo
<lfam>And then, I do `make build-asus`
<lfam>It starts working, which means that the code is well-formed
<derivates>let me try something real quick
<lfam>My initial problems were caused by not setting up the load path correctly (because I wasn't using your Makefile)
<derivates>Hm.. do you happen to know how to pass a channels.scm to guix system?
<apteryx>ryanprior: I think I may have found what to change for getting rid of the mass po diffs
<apteryx>s/SUBDIRS = po/guix po/packages/DIST_SUBDIRS = po/guix po/packages/ (untested)
<apteryx>(in the top Makefile.am)
<derivates>lfam: i got it to work... I ran guix pull and i got a few updates... please don't ask, i just don't understand...
<derivates>i mean cool it works, but shouldn't guix pull shouldnt of been the solution
<ryanprior>apteryx: oh that's cool, I looked into it a little this morning but didn't figure out anything relevant yet
<apteryx>I ran 'make --dry-run' and was surprised to see po/guix po/packages as the first default make targets
<apteryx>Make builds inconditionally SUBDIRS at first, it appears
<apteryx>it seems to work so far
<apteryx>thanks for reminding me of that annoyance
<lfam>derivates: I'm not sure that `guix pull` was the thing that fixed it, but I understand that it's not good that it mysteriously broke for a while
<apteryx>roptat: building po/guix and po/packages *is* a dist target related task, right?
*apteryx zzz
<derivates>lfam: don't know, but at least it works!
<lfam>Yes :)
<sebastien65>Hi there, does anyone here has experience with packaging Python modules/apps with Guix? Would benefit from some pointers on how to get started.
<lfam>sebastien64: Yeah, I have some experience
<lfam>Did you have any specific questions?
<lfam>We also have a brief section in our manual about packaging Python modules: https://guix.gnu.org/manual/devel/en/html_node/Python-Modules.html
<derivates>Hello, what's the "Guix way" of starting application (e.g 'sxhkd')? I used to use `~/.xprofile`
<sebastien65>lfam so really basic things: I'm trying to package a local application in a container using Guix.
<sebastien65>First thing is that I did `python setup.py sdist` to build a source tarball, use a local uri, but am getting stuck at the sha256 hash: `(build-content-hash #vu8(105 221 155 211 134 247 127 205 159 241 254 155 227 167 118 209 247 91 123 141 125 119 207 30 105 254 187 115 190 91 117 254 221 123 94 247 211 71 221 213 239 90 209 221 221 111 135 54)
<sebastien65>sha256): invalid content hash length
<sebastien65>make: *** [Makefile:4: package] Error 1`
<sebastien65>And the source:   (source (origin
<sebastien65>              (method url-fetch)
<sebastien65>              ;; Q: Can we not generate a tar file?
<sebastien65>              (uri (string-append "./dist/guix-python-app-0.0.0.tar.gz"))
<sebastien65>              ;; Q: How do we generate the SHA1 signature
<sebastien65>              (sha256 (base64 "ad2b04b3f82f8f6b46d20fdbe419d88eaf67c75bdf7de17300fd1e9a0d3db4c2"))))
<sebastien65>And just to clarify, I did run sha256 sum on the tarball
<lfam>To get the hash, use the `guix hash` command
<lfam>E.g. `guix hash ./dist/guix-python-app-0.0.0.tar.gz`
<lfam>That way, you'll be sure to get the right format
<lfam>And then, use it like (sha256 (base32 "..."))
<sebastien65>OK, that got me one step further. Now get `guix package: error: cannot install non-package object: #<unspecified>`
<sebastien65>Here's the full `package.scm` file if that's useful.
<sebastien65>```
<sebastien65>(use-modules (guix packages)
<sebastien65>     (guix download)
<sebastien65>     (guix build-system python)
<sebastien65>     (guix licenses))
<sebastien65>(define-public hello
<sebastien65>  (package
<sebastien65>    (name "guix-python-app")
<sebastien65>    (version "0.0")
<sebastien65> ;; Q: How do we express dependencies?
<sebastien65>    (source (origin
<sebastien65>              (method url-fetch)
<sebastien65>              ;; Q: Can we not generate a tar file?
<sebastien65>              (uri (string-append "./dist/guix-python-app-0.0.0.tar.gz"))
<sebastien65>              ;; Q: How do we generate the SHA1 signature
<sebastien65>     ;; A: guix hash ./dist/guix-python-app-0.0.0.tar.gz
<sebastien65>              (sha256 (base32 "1hml7l6rl7px01ry2zfzbg3ngbwfv0cy9nqgs936p3rgz2rh8axd"))))
<derivates>use the pastebin please
<derivates> https://paste.debian.net/
<lfam>+1
<sebastien65>@lfam I've never used IRC before, sorry...
<lfam>No worries
<lfam>Can you upload your package.scm to <https://paste.debian.net> and share the link here?
<sebastien65>Here you go: https://paste.debian.net/1194367/
<lfam>Can you also share the result of `guix describe`?
<sebastien65>A cryptic `guix describe: error: failed to determine origin`
<lfam>I'm guessing it's a new install? Is it 1.2.0?
<lfam>And, are you building it like `guix build -f package.scm`?
<lfam>If so, you need to make the sure the last expression of the file returns the value of the package that you've defined
<lfam>That means that the last line of the file should be the word 'hello'
<lfam>(You might want to rename your package variable :)
<lfam>)
<derivates>lfam: do you happen to know what i asked before?
<lfam>I didn't understand that question derivates
<sebastien65>@lfam I was actually running `guix package --install-from-file=package.scm`, but the `guix build -f` was much more helpful
<lfam>Yeah, it's better for development
<derivates>lfam: run xyz con x11 boot, for example a script
<derivates>run xyz command on Xorg start **
<sebastien65>Thanks a lot for your help lfam, getting started is quite hard, I really appreciate the support!
<lfam>We are happy to help!
<lfam>We improved that error message after 1.2.0
<lfam>It looks like this now: https://paste.debian.net/1194370/
<lfam>I know it seems weird but it's a Scheme thing, and using --install-from-file or --file is veering into Scheme territory, away from the normal UI
<lfam>My advice for developing Guix packages is to set up a Guix development environment and work from that. It's the most comfortable way to do it.
<lfam>It's documented in the manual sections Building From Git and Running Guix Before It Is Installed
<lfam> https://guix.gnu.org/manual/devel/en/html_node/Building-from-Git.html
<lfam> https://guix.gnu.org/manual/devel/en/html_node/Running-Guix-Before-It-Is-Installed.html
<lfam>Then you can just refer to packages, like `guix build guix-python-app`
<lfam>You can use the name you've defined rather than just the Scheme variable's name
<sebastien65>That is super helpful, thanks a lot ! End of day for me, so have a good one!
<tissevert>hi guix !
<lfam>Howdy tissevert
***rekado_ is now known as rekado
<tissevert>it seems I'm facing the same thing civodul had https://issues.guix.gnu.org/43747
<tissevert>I wonder why it's started on my system, I don't even have proper channels, just .scm files containing the recipes for my local packages
<tissevert>and it's worked fine so far, I had no message about newer versions and cached ones or anything
***jx97 is now known as jx96
<wonko7>Hi all! any of you use skim? I just installed version 0.9.4 and running sk lists all the entries without new lines, instead of one entry per line
<nckx>Morning, Guix.
<nckx>wonko7: https://www.tobias.gr/sk-0.9.4.png
<wonko7>heh, what's wrong on my end then...
<nckx>Dunno. Try a different terminal? I'm using alacritty.
<wonko7>I tried different terms, different shells, same thing
<nckx>Let me try master's just in case.
<wonko7>utf8 seems to be working, no weird characters
<nckx>Shameful success on Guix 72bba784.
<nckx>wonko7: What's your $TERM? Mine's "xterm-256color". "xterm" and "linux" work too.
<wonko7>nckx: screen-256color, but I tried xterm and linux, same thing
*nckx is out of ideas, sorry.
<meo>!randquote
<meo>uh wrong window sorry
<wonko7>thanks, $TERM was a good idea :)
<wonko7>I'm running guix pull in the meantime
<nckx>meo: Your present plans will be successful.
<nckx>-- $ fortune
<rekado>hi there, I’m using Gnome and would like to use the ibus-libpinyin input method
<rekado>I have ibus and ibus-libpinyin installed at the system level
<rekado>(to avoid compatibility problems when the system is upgraded)
<rekado>I deleted ~/.config/ibus and ~/.cache/ibus
<rekado>ibus libpinyin is not a selectable option in the Gnome language settings
<rekado>I can run ibus-setup manually, which prompts me to start ibus-daemon (which is odd, because it’s already running)
<rekado>there I can add ibus-libpinyin and configure it, but as soon as I exit ibus-setup nothing has changed and I still can’t switch to that input method.
<rekado>any ideas what might be wrong?
<jonsger>updating in the morning seems to be a good idea: way faster (10MB/s+) then usual, so it's maybe a problem between Vodafone DE and MDC data center
<rekado>running “ibus restart” I get “Can’t connect to IBus”
<rekado>Gnome (or rather gdm) starts IBus for the whole session.
<rekado>it’s a bit sad that ibus on Guix has deteriorated so much. It was never easy to configure, but it used to be more reliable.
<asdf-uiop>hi!
<nckx>Hi asdf-uiop.
<tissevert>hi rekado
<tissevert>hmmm same problems I have here with ibus, haven't set out to fix that yet but very interested
<tissevert>if setup prompts to start the daemon (which it does here too) it probably means the proper variable isn't set in environment
<tissevert>last time I checked, I was puzzled to find something in gnome-shell running ibus (so if you use GDM, it should be the case)
<tissevert>but which was unavailable from my (XFCE) session
<tissevert>about the «configure but nothing changes», it's an issue I used to have on other systems, and it was a dconf issue
<tissevert>(ibus uses dconf to store its config, but the dependency isn't mentioned in the package, for some reason)
<asdf-uiop>Is there an easy way to globally disable the 'beep' in guix? I tried searching the manual and the web, but I could not find anything.
<rekado>tissevert: yes, dconf uses the memory backend by default, IIRC, which is oddly named as it doesn’t memorize anything :)
<rekado>tissevert: I suppose we’d need to figure out a way to let the ibus client connect to the “global” ibus socket instead of the per-user socket that is created when starting ibus-daemon as a user.
<rekado>completely unrelated issue: I’m trying to package irods and it insists on using clang and libcxx.
<rekado>the configure step to test that the clang toolchain is capable of compiling a test program fails with linker errors.
<rekado>does anyone know how to use libcxx with the clang toolchain in a package definition?
<rekado>(I’m also exploring ways to build with GCC instead, but there are errors that I understand even less)
<efraim>glib failing again on core-architectures on powerpc (slow architectures). I'll bump the test_timeout_slow value
<civodul>Hello Guix!
<efraim>hello!
<asdf-uiop>Hello!
<nckx>asdf-uiop: What is ‘the beep’?
<nckx>You can add modprobe.blacklist=pcspkr to kernel-arguments to prevent loading the driver for the built-in ‘PC speaker’.
<asdf-uiop>The default alarm sound
<asdf-uiop>Thank you
<asdf-uiop>!
<civodul>andreas-e: oh i see you already pushed the openjdk changes
<civodul>i have fixups locally
<efraim>up to the test suite again in glib
<asdf-uiop>Is it possible to create dotfiles in the user profiles as part of the system configuration?
<leoprikler>I think you're looking for something akin to 'guix home'.
<leoprikler>As it stands, 'guix system' only handles skeletons.
<asdf-uiop>Thank you, I'll look into that
<asdf-uiop>In case someone else interested in that finds this in the logs: https://framagit.org/ardumont/guix-home-manager
<asdf-uiop>This one is the original and maintained: https://framagit.org/tyreunom/guix-home-manager
<mange>civodul: Hi! I've just seen your changes to the openjdk patch I sent yesterday. Can you explain why it's safe to remove the (or ...) around the (search-path ...) calls? According to "(guile) Load Paths", search-path returns #f if it can't find the file, which I would expect to then substitute #f incorrectly?
<sneek>Welcome back mange, you have 1 message!
<sneek>mange, efraim says: I hope you can get rails working with guix packages, I have a half-finished discourse app and service that uses rails :)
<civodul>hi mange!
<civodul>i noticed that in the patch you sent it's the only place where you'd replace (search-path ...) by (or (search-path ...) ...)
<civodul>among the 3 places
<civodul>so i wondered if it was necessary in this one case and not in the others
<civodul>and apparently it's not necessary
<civodul>does that make sense?
***ece3 is now known as ece
<mange>Hmm. That's a mistake by me, then. I had intended to put the (or ...) around all three, because I thought it was necessary based on the documentation. I haven't actually checked whether it works. I'll do a guix pull and check how the build result looks.
<mange>I should be able to see if it has a "#f" in the build result.
<civodul>i think the build would simply fail in that case, no?
<civodul>because we'd get #f instead of a string
<tissevert>civodul: I've stumbled upon an issue you opened https://issues.guix.gnu.org/43747
<civodul>so a type error down the road
<tissevert>I have similar messages but not from /gnu/store, from my .cache in my $HOME
<mange>It gets used in a (format #f "\"~a\"" (find-library name)), which would substitute #f into the program source.
<civodul>mange: ooh, not good
<mange>The resulting JVM will try to load a dynamic library named "#f".
<civodul>i recommend string-append in such cases
<tissevert>so I can simply remove the cache, but I was wondering whether you knew why they appeared, and if something should be done about it (except clearing the cache)
<civodul>tissevert: ~/.cache/guile/ccache is the compilation cache automatically populated by Guile
<mange>Let me verify that it's actually a problem, but I think it will be.
<civodul>ok
<tissevert>it seems so, but then why does it complain about it being older and not re-populate it with fresher data ?
<civodul>tissevert: because guix disables auto-compilation
<civodul>so it must have been populated by running guile explicitly, or via Geiser
<tissevert>hmm not that I recall, maybe when I gave guix home a try ?
<efraim>looks like the glib test timed out again, even with test_timeout_slow set to 1800
<efraim>does anyone know some meson magic to disable a test? something like prepending 'if FALSE' to the test?
<mange>Yeah, looks like it's a problem. I'm seeing #f in the resulting .so files, that look significant. I'll put together a fix based on the patch you just sent.
<civodul>tissevert: could be
<civodul>mange: d'oh! so i'd recommend string-append instead of format while you're at it
<wonko7>since I've started using profiles for my user su & sudo are broken:
<civodul>but you'll have to rebuild it all up to openjdk@11 at least
<wonko7>su: Authentication service cannot retrieve authentication info
<wonko7>sudo: /run/current-system/profile/bin/sudo must be owned by uid 0 and have the setuid bit set
<mange>Yep, I've made that change, too. I'm rebuilding as we speak.
<mange>It'll take a while, but I'd rather verify it before pushing it.
<civodul>mange: coolio, thanks for checking
<civodul>wonko7: you should be running /run/setuid-programs/sudo instead
<civodul>see https://guix.gnu.org/manual/en/html_node/Setuid-Programs.html
<wonko7>civodul: thanks
<wonko7>that works
<wonko7>should I just put /run/setuid-programs/ in my path? or is there a profile I should be sourcing?
<civodul>wonko7: normally it's in PATH by default, but perhaps the mistake you made was to add "sudo" to the 'packages' field of 'operating-system'?
<civodul>not sure, you could try "echo $PATH" to see whether /run/setuid-programs comes first
<wonko7>it's not in there
<civodul>oh weird
<civodul>could it be that ~/.bash_profile or ~/.bashrc overrides PATH?
<civodul>you can see the default PATH in /etc/profile
<wonko7>yeah, I'm looking into it, my zsh config only adds stuff
<wonko7>source /etc/profile; zsh => gives me a zsh with a correct path
<wonko7>new shell with zsh as user's default shell doesn't have the correct path
<mange>Looking at the zsh documentation, I think /etc/profile is only loaded for login shells in sh compatability mode (i.e. when run as /bin/sh or /bin/ksh).
<mange>Otherwise, it tries to run /etc/zprofile on login, and /etc/zshrc for interactive shells.
<wonko7>I'll just source it in my config
<rekado>re ibus: I think one of the problems may be that gdm’s ibus socket file is not readable by other users.
<rekado>the socket file is, but the directory /var/lib/gdm is not accessible
<rekado>when I make the directories executable by others, ibus tells me that the owner of that gdm ibus socket file is not my user, so perhaps I need gdm to perform these ibus actions on my behalf
<brendyyn>Is it a per-user thing? maybe that is just the socket used by ibus used by gdm in the login window. in your user you would have your own? like gdm has its own per user pulseaudio running too
<rekado>yes, perhaps
<rekado>another problem we have is that /var/lib/gdm is stateful, so its .cache/ibus directory will refer to outdated store locations for ibus
<rekado>so it may end up trying to load ibus methods from a previous system generation.
<rekado>it’s pretty terrible and I think /var/lib/gdm/.cache must be moved to a tmpfs
<rekado>stracing the gnome control center I don’t see any attempt to discover input methods when I go to Region & Language
<rekado>this must be loaded statically
<rekado>no, it’s actually happening over dbus
*rekado enters unfamiliar waters
<brendyyn>there is ibus_get_socket_path
<rekado>and now for completely unknown reasons the libpinyin method *does* appear
<rekado>so, here’s what I did: killed the gdm ibus processes for fun; deleted /var/lib/gdm/.{cache,config}/ibus, started ibus-daemon manually, and then restarted gnome-control-center a few times
<rekado>I don’t think the gdm user’s ibus matters here, but I think something’s not right with how we start gnome.
<rekado>whenever a user logs in there should probably be a per-user ibus thing on the session dbus
<rekado>I can now type with ibus-libpinyin when I’m in the gnome shell (e.g. to search applications), but other applications don’t seem to be using ibus.
<brendyyn>the ibus package includes some dbus files, but i dont see anything in the gnome service that puts them in the system profile
<rekado>I also note that neither GUIX_GTK2_IM_MODULE_FILE nor GUIX_GTK3_IM_MODULE_FILE are set.
<rekado>I wonder why we no longer set it.
<brendyyn>maybe those are just for systemd tho
<rekado>way back I implemented this because I found that the IM module file needs to be a) separated by GTK version and b) known to GTK in the non-FHS case
<brendyyn>leo submitted a patch to add that, mentioning ibus, did you find it?
<brendyyn> http://issues.guix.gnu.org/44354
<rekado>thanks, let me check
<brendyyn>seems its just for system wide ones
<rekado>ah, beautiful
<rekado>this would probably solve the problem
<brendyyn>still, we would want it to also see the users ones
<rekado>sure, but I’d settle for anything that would make things work *at all*
<brendyyn>i know what it feels like making cjk input work
<rekado>I just tried setting GUIX_GTK3_IM_MODULE_FILE to the system profile’s file and started gnome-terminal, but it doesn’t seem to have an effect.
<brendyyn>without rebooting?
<rekado>yes
<brendyyn>dont need to?
<rekado>the variable is in effect for the environment of the newly started gnome-terminal process
<rekado>that should be enough
<leoprikler>rekado, you need to do so in your shell profile
<leoprikler>and IIRC you need to log in to gnome again
<rekado>I wonder if I can set this property at runtime in dconf…
<rekado>isn’t that only required if I want to have this effect for all applications in my Gnome session?
<leoprikler>I'm not sure how GNOME <-> IBus interacts, but you need it at least in order to set ibus methods from GNOME
<rekado>I’m struggling to understand how having that variable set for the gnome-shell process would affect the result compared to having the application itself have that variable.
<leoprikler>The application doesn't handle input on its own afaik.
<rekado>so… I found just now that I *don’t* need the variable at all to list and use ibus methods in the Gnome control center
<rekado>it’s enough for me to start ibus-daemon manually, and then start gnome-control-center
<rekado>the ibus input method appears in the list then
<rekado>(it does not appear when my ibus-daemon process is not running)
*rekado has to go for a while
<apteryx>civodul: Hi! Does this patch: 's/SUBDIRS = po/guix po/packages/DIST_SUBDIRS = po/guix po/packages/' makes sense to you? It prevents the first make from creating a flurry of diffs under 'po/' (which we regularly tell users to just 'git checkout po/).
<apteryx>err, 's,SUBDIRS = po/guix po/packages,DIST_SUBDIRS = po/guix po/packages,' :-)
<apteryx>is it new that the python test suite hangs on armhf-linux? (qemu)
<apteryx>ah, already reported here https://issues.guix.gnu.org/47759 it seems
*rekado is temporarily back
<rekado>I feel like I’m not fully understanding how this is all *meant* to work.
<roptat>apteryx, I don't know enough automake to be sure that's the right way to fix it, but it makes sense that we don't want to updte po files when running make for the first time
<rekado>brendyyn, leoprikler, perhaps we could ask the Gnome developers for documentation / assistance
<rekado>though it may be difficult to overcome the problem of us using a somewhat dated Gnome version
<leoprikler>I think the procedure should be the same for GNOME 3.* with only 40 making a differnce
<brendyyn>is there any reason for it to be any different from gnome to xfce etc?
<apteryx>roptat: OK. Reading the manual that seems OK; targets found in SUBDIRS are inconditionally built first according to the manual. We don't want that.
<rekado>brendyyn: yes, because Gnome attempts to closely integrate ibus
<rekado>xfce doesn’t
<rekado>Gnome adopted ibus as the one supported input method framework
<apteryx>is explicitly adding 'control@debbugs.gnu.org' required to use commands such as 'block NNNN\nthanks' at the beginning of a reply to an existing bug? Or is this already implicit by having NNNNN@debbugs.gnu.org in CC?
<rekado>this is why I can’t get things to work now with more recent versions, whereas I had no problems (other than stale caches) in earlier versions of Gnome.
*apteryx tries
<rekado>apteryx: you can send “hidden” control messages to the control address.
<apteryx>How do I do this? :-)
<rekado> https://debbugs.gnu.org/server-control.html
<rekado>as you can see, all of these commands require the current bug number as an argument
<mange>efraim: I've given up on getting ruby and rails to work how I wanted. :( I've managed to get it working by only installing Ruby via Guix, then installing everything else via "gem" rather than Guix. Not what I was hoping for, but I don't understand enough to solve any of the real problems.
<rekado>whereas visible inline commands sent to NNNN@debbugs.gnu.org don’t need that
<roptat>where is ibus cache again?
<rekado>brendyyn, leoprikler, one of the ways that this integration shows is in the fact that ibus-daemon is running by default, and that some operations are performed via dbus caalls.
<rekado>~/.cache/ibus
<rekado>but also /var/lib/gdm/.cache/ibus
<rekado>and then there’s also .config/ibus
<rekado>and perhaps even something in .local/share
<rekado>the .cache/ibus stuff is the nastiest, though, because discovered modules are recorded there with their full store file names
<apteryx>rekado: I see; so for blocking X by Y, replying to the Y bug issue, can I just add 'block Y' at the beginning of the message?
<rekado>apteryx: I don’t know!
<rekado>haven’t tried it
<apteryx>OK
<roptat>thanks
<apteryx>I'll play it safe for now with 'block 47297 by 47759'
<rekado>I see that dconf contains /org/gnome/desktop/input-sources/mru-sources/, which is empty
<rekado>oh, sorry, “dconf read /org/gnome/desktop/input-sources/mru-sources” (without the trailing slash) returns a dictionary
<rekado>nope, a list of tuples
<rekado>[('ibus', 'libpinyin'), ('xkb', 'us')]
<rekado>dbus-monitor shows me that something attempts to write to this key
<xmx>Is it necessay to include dependency if its only glibc ?
<xmx>for package definition
<rekado>glibc is an implicit input
<rekado>you don’t need to explicitly add it
<xmx>so no
<xmx>okay
<apteryx>roptat: hmm, now I get: automake: warning: AM_GNU_GETTEXT used but 'po' not in SUBDIRS
<roptat>apteryx, I guess it's just a warning?
<roptat>as you said, if we keep po in SUBDIRS, it's gonna be regenerated
<roptat>and we don't want that
<apteryx>Hmm. But it seems we loose the doc-make-target (it'll source the make definitions at dist time), which is not what we want
<apteryx>err, doc-po-update target
<apteryx>I'm guessing the problem has to be resolved by having the Makefile definitions under po/ to not contain any default target? not sure.
<civodul>apteryx: i'm discovering that DIST_SUBDIRS is a thing (which is humbling, i didn't think i could still discover automake stuff)
<brendyyn>i switched from gnome to xfce and it seems gnome has broken ibus for me. I only see ibus Anthy in the ibus settings, which i installed previously while on gnome. now im on xfce i installed ibus-libpinyin and ibus-rime but they do not appear
<civodul>apteryx: but yeah, we'd lose targets and make automake unhappy it seems
<civodul>roptat: BTW, i'm skeptical about the addition of translations of the manual below 5%
<leoprikler>brendyyn: what about purging the ibus cache?
<civodul>brendyyn: what leoprikler suggests makes sense in light of https://issues.guix.gnu.org/47576
<brendyyn>for the one in my home directory it makes no difference. should i delete the /var/lib/gdm one?
<roptat>civodul, the idea was to add all of them, and provide them with "info guix.xx", but not necessarily to render them on the website or otherwise advertise them
<apteryx>civodul: make --dry-run complains following the removal of the nix importer
<apteryx>make[3]: *** No rule to make target '../../guix/scripts/import/nix.scm', needed by 'guix.pot-update'. Stop.
<roptat>civodul, and it lets me redefine download-po as a much simpler procedure, see #47882
<rekado>civodul: that bug is even older actually: https://issues.guix.gnu.org/22707
<rekado>2021 seems like a good year to fix that 2016 bug :)
<brendyyn>if its all generated could it not in theory just not use a cache at all? whats the justification for it?
<efraim>about the cache stuff, I was actually considering creating a symlink from ~/.cache to $XDG_RUNTIME_DIR/cache, just wasn't sure how to make it work well at boot/login
<xmx>How can I fix these ? http://ix.io/2WJD
<xmx>Do I need to fix all of these ?
<xmx>I copied tarball link for nix package definition.
<brendyyn>xmx: descriptions need to be wrapped like the other examples in guix
<brendyyn>xmx you can switch to git-fetch and use the version tag if it has one
<brendyyn>xmx: search the guix repo for examples of git reference. the commit in this case will be (string-append "release-" version)
<brendyyn>xmx: dont worry about the no updater warning, and sofware heritage warning
<brendyyn>they may even fix themselves when you use git-fetch, im not sure
<brendyyn>and the first one just means after full stops in sentences, add two spaces
<xmx>brendyyn: So always git-fetch i prefered that than the rest ?
<xmx>is*
<brendyyn>xmx: It's just that those "archive" links on github have been known to be regenerated with differences so git fetch is preferred to that
<roptat>apteryx, any idea when we can make this release?
<roptat> https://guix.gnu.org/cookbook/ seems to be stuck
<roptat>(same for devel manual)
<apteryx>roptat: I just marked another bug as blocking; python-minimal fails building for armhf (and the report says x86_64 as well although I couldn't reproduce that)
<avalenn>Hello guix
<apteryx>roptat: also, the only armhf offload machine on berlin is offline; I'm in contact with Simon to resolve this
<brendyyn>pulseaudio stopped working despite still runninng. the native socket disappeared. so i restarted pulse audio and it worked, but then my keyboard volume control stopped working... sort of. it uses amixer set Master to change volume. spamming volume up and down it somehow made the right channel louder than the left...
<brendyyn>funny. there is a stackexchange with the same problem
<roptat>apteryx, would be cool to get guix pull and maybe the core packages building again on ci
<apteryx>yes!
<apteryx>rekado: what's the process for reconfiguring Berlin?
<apteryx>If I push change to the guix-maintenance repo, adding two new wireguard peers to berlin.scm, what's next?
<cybersyn>hiya guix
<cybersyn>is anyone working on the localization of guix in vietnamese?
<cybersyn>my partner and I were thinking it could be a cool "kill 2bird with one stone" project for me, I could improve my vietnamese and understanding of guix simultaneously, while she checks and corrects all of my errors.
<rekado>apteryx: someone’s got to run “guix system reconfigure” on the host
<civodul>apteryx: oh, did i forget to remove import/nix.scm from somewhere? POTFILES.in maybe?
<civodul>roptat: ok, why not then
<civodul>rekado: re ibus, did you see the patch at https://issues.guix.gnu.org/47576 ?
<civodul>i've only checked that it builds :-), but it'd be nice if someone could give it a spin
<rekado>I don’t know how helpful a test on my end would be when I haven’t yet been able to get ibus-libpinyin to work
<rekado>the patch looks reasonable to me, but as you wrote it doesn’t help with installed input methods other than those that come with ibus.
<rekado>(such as ibus-libpinyin)
<efraim>does copy-build-system work for others on core-updates?
<efraim>works for me on x86_64
<apteryx>rekado: OK, so I clone guix-maintenance the 'sudo guix system reconfigure hydra/berlin.scm'. Sounds simple.
<apteryx>s/the/then/
<apteryx>I'll need sudo access to do so though
<rekado>we seem to be doing “/root/.config/guix/current/bin/guix system -L modules reconfigure berlin.scm -c60” from the /root/maintenance/hydra directory
<rekado>I can do that for you
<apteryx>OK. I haven't pushed the commit yet, I'll do so now
<rekado>ok
<apteryx>oh, I see Mathieu has just done so
<efraim>well I just noticed that our llvm targets a lot of architectures. Looks like I might be diving down a rabbit hole to see if an llvm-minimal useful for mesa might be worthwhile
<rekado>apteryx: so, should I reconfigure now?
<apteryx>no, it seems Mathieu's on it! Sorry for the bother :-)
<rekado>okay, no worries
<xmx> http://ix.io/2WJV
<xmx>Anything thing to fix ?
<rekado>xmx: add some line breaks to line 50
<rekado>the second issue is not a problem
<apteryx>civodul: yes, I think it's 'guix/scripts/import/nix.scm' in POTFILES.in
<raghavgururajan>Hello Guix!
<apteryx>hello, Raghav!
<raghavgururajan>How is it going with the new release work?
<roptat>still a few blockers
<raghavgururajan>I see.
<rekado>does anyone know what I’d need to do to satisfy these references?
<rekado> https://elephly.net/paste/1618931044.html
<roptat>to me it looks like libstdc++
<roptat>but that's already used, so maybe there's an incompatibility between libstdc++ and the one used to build llvm?
<rekado>isn’t libstdc++ part of GCC? I’m attempting to build this with the clang toolchain.
<roptat>it looks like it's using "clang -stdlib=libc++ -lstdc++"
<rekado>oh, the -lstdc++ is what I snuck in there; I get the same error with just “-stdlib=libc++”
<raghavgururajan>rekado: I think you may need to recompile libcxx with -fPIC flag?
<roptat>oh, then I don't know, it's weird that it's missing some symbols, it should be either part of that library or one of its dependencies, that should be in its rpath...
<raghavgururajan>Looks like there are only native-inputs for libcxx. If it depends on something at run-time, there should be inputs or propagated-inputs right?
<xmx>How do I calculate hash for perticular tag in git
<xmx>using guix
<rekado>xmx: you check out the code, switch to the commit corresponding to the tag, and then you run “guix hash -rx .” from within the directory
<rekado>IIRC
<Sirex>How do you organize your software development with guix? Imagine, I have 20+ projects. Each project has multiple components: frontend, backend, database, memcache, some cli, etc and lives in their own git repositories. Projects are related. Firstly I thought, I can create channel-repo and put all packaging code here. But it feels wrong to me: each
<Sirex>project team must re-invent building, testing, packaging in upstream repo. And again in channel-repo.
<Sirex>Any best practice here?
<Sirex>I'm also considering use guix in company as universal packaging system: develop, build, test, deploy all. Declarative. As code.
<pkill9>cool
<pkill9>Sirex: see direnv, that might help
<tissevert>Sirex: very interested in what you'll find but I have pretty much the same needs at a much smaller scale, and so far this is what I've done:
<pkill9>it comes with a script to create guix environments for each directory
<pkill9>so when you enter it you will enter a guix environment
<tissevert>- a file to define local builds for each of these packages (so, central, not one per project like I used to in nix — default.nix if that rings a bell)
<tissevert>- a couple bash aliases to be able to simply «build» or «enter» from any of these directory to try building or entering an environment where the package is installed, based on the current directory's name
<tissevert>pkill9: thanks for the direnv tip, I didn't know about that
<Sirex>@tissevert, I can put package definitions in each $PROJECT_GIT_ROOT/guix.scm and treat it as independent channel. In that case I likely end up with a lot of channels with few packages in them. And will get lot of maintenance headache, won't I? Another case: I create single guix repo and put all package definitions for all my projects here. One chan
<Sirex>nel is better to maintain, but each project team must either copy-paste definitions or use their own or whatever. Keep in mind, that upstream team wants to develop project, build release candidates, test, have multiple environments, etc.
<rekado>Sirex: you don’t need to use channels at all.
<rekado>just a single guix.scm file will suffice.
<rekado>you *can* put shared package definitions in a channel that this guix.scm references
<rekado>looks like libcxx might need the additional libcxxabi library
<rekado>it contains files that are named like the missing symbols, so I’ll package that next
<apteryx>rekado: would you mind initializing my user password on berlin? It'll enable me to use sudo.
<rekado>apteryx: okay, just a minute
<rekado>apteryx: sent you an email
<apteryx>thanks!
<apteryx>it works
<Sirex>rekado: I won't have any shared packages probably. let me recap the idea: i create a guix repo *apps-suite.git*. I put in the *apps-suite.git* all my `(define-public projectN-componentM ...`. All these definitions reference upstream project git repository. In upstream project I put *guix.scm*. And what is next? Just reference *apps-suite.git* as ch
<Sirex>annel, inherit package definition like `(define-public projectN-componentM-dev ...` and override source version to use local files instead of git ref?
<lfam>A moment of silent keyboards for d95168321f4a9bf6857b598da0a183b45a868d54
<lfam>That removes the oldest code in Guix
<avalenn>code did his duty
<avalenn>An unrelated matter I need to use the source of an other package during the build phase. How would I do that ?
<raghavgururajan>iyzsong: You around?
<rekado>avalenn: add this to the inputs ("the-package-source" ,(package-source the-package))
<lfam>Does anybody know how to make a service use syslog?
<lfam> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=47905#26
<lfam>Or, have an example?
<avalenn>rekado: thank you, will try this
*lfam greps the manual for 'syslog'
<tissevert>Sirex: ah, yes you've got several developpers, I'm the sole user of my packages ^^
<apteryx>lfam: good news, our two ARMv7 offload machines are back online
<lfam>Nice
<lfam>I'm very interested to see how they do now that Cuirass itself is not the bottleneck
<lfam>Thanks for your work getting them back
<tissevert>yes, what you say sounds right, it should work (give or take one fix or two, I don't see any issue with the general picture) but yeah like rekado said you don't even need it to be a proper channel, only a mere scheme file (this is what I use)
<leoprikler>We should have called the guix.scm file guix.lock, then people wouldn't have so much trouble committing it to version control :)
<lfam>Lol
<lfam>I was thinking of rewording the two options on this page: https://guix.gnu.org/manual/devel/en/
<lfam>I *always* struggle to pick the right one
<lfam>Because, both options include the word "one"
<lfam>I was thinking that it should instead be "HTML, with a separate page per node" and "HTML, entirely on one page"
<lfam>I frequently choose between these options. I search the entire manual to find an example, and then I use the "per node" manual when sharing links
<avalenn>lfam: +1 same problem here
<roptat>+1 :)
<lfam>Haha
<avalenn>I always wonder why CTRL-F does not work as expected
<lfam>I was worried I might have to try to explain it more, and then to resort to "just please let me change it"
<roptat>well, I always wonder why the computer stops answering for a while and the fan is suddenly so loud...
<lfam>Wait, why does it cause high load?
<roptat>the html manual on one page is huge
<lfam>Yeah, I guess my laptop is fast enough. Or maybe my browser is caching it efficiently
<lfam>Anyways
<lfam>I'll make the change
<roptat>and probably doesn't play well with my addons
<roptat>but it's the same terminology for other online manuals of GNU software
<iis>Hello, I want to run a web server with php capabilities and option to download and upload files from/to it. I would install LAMP using any gnu/linux distro. But using gnu guix what would be the right approximation. I mean, I haven't found enough tutorials / videos about the topic with gnu guix.
<lfam>roptat: Perhaps, but I think it's okay to change from the norm. It sounds like a lot of us have the same problem
<lfam>I guess we need a LAMP recipe for the Cookbook
<roptat>iis, you would add a web server (nginx or apache) in your system configuration (usually /etc/config.scm), php-fpm and use https://guix.gnu.org/manual/devel/en/html_node/Web-Services.html to configure them
<roptat>the page has examples both for apache and nginx
<iis>roptat: thanks. I'll check that. By the way, GNU Artanis is for local web server only?
<roptat>I don't think so, you should be able to use it anywhere
<roptat>maybe behind a reverse proxy
<luis-felipe>lfam: Where is the code that generates that page (https://guix.gnu.org/manual/devel/en/)?
<lfam>luis-felipe: It's in the guix.git repo, 'doc/build.scm'
<luis-felipe>thanks
<davidl>Hi, I read somewhere that core-updates is merged every 6 months or so - is there any way to find out approximately when the next merge will be? I sent in a patch (#47898) but I have no idea when I can expect it to be merged to master provided someone reviews and commits it.
<lfam>luis-felipe: By the way, I liked your "Bermuda triangle" graphic regarding 1.2.1
<luis-felipe>:)
<lfam>david1: I'm sorry that current core-udpates has been delayed so long
<apteryx>davidl: it'll be the focus after 1.3.0 for sure
<lfam>Due to the pandemic and problems with the build farm software, we became uncoordinated for a while, and the build farm / CI was not up to the task
<lfam>The build farm software is ready now, thanks to sustained development attention
<lfam>I agree with apteryx. After the upcoming release, core-updates will be the focus
<lfam>This delay has been atypical
<lfam>Well, your patch is new, so there hasn't been a delay :)
<apteryx>nckx: did you have any luck configuring the powerpc64le VM?
<lfam>You should expect it to take 2 or 3 months, davidl
<davidl>Ok, thanks :-) Yeah, it's new, I was mainly curious, and did not mean to complain on anyone!
<lfam>Sorry we assumed that :)
<lfam>But, now you know the background story too!
<davidl>yeah, thx :)
<apteryx>nckx: guix offload test /etc/guix/machines.scm p9.tobias.gr times out
<apteryx>if you need help with the wireguard configuration or something please ping
<guixy>Hi guix
<guixy>I'm working on a jupyter server service.
<apteryx>convert is missing from somewhere; when building on berlin I need to 'guix environment guix --ad-hoc imagemagick' else I get /bin/sh: convert: command not found
<apteryx>during: GEN doc/images/coreutils-size-map.eps
<guixy>The jupyter config file is in python. Would you advise for or against making a DSL for the more commonly touched fields?
<efraim>building llvm-11 which only targets the host's architecture cut down the build time by 33% and also cut down the package size by 33%
<apteryx>(for the release target)
<apteryx>efraim: that's great!
<efraim>graphviz? is that where convert is?
<apteryx>imagemagick
<guixy>"commonly touched fields" in this case includes c.NotebookApp.{password_required,default_kernel_name,certfile,keyfile,client-ca}, ...
<efraim>apteryx: just like when I made a native-only qemu variant, my main goal is to cut down on build times on powerpc
<efraim>9 minutes on my fast desktop, 16 hours on my ppc
<apteryx>hehe
<apteryx>that's a worthile goal! Many of us are on dated hardware
<apteryx>worthwhile*
<apteryx>for QEMU, we should split it up also. 30 targets (or so) is a bit much.
<guixy>I'll start without a DSL, then work on one if I find myself with long string blocks of python in my scheme files.
<efraim>apteryx: that's what qemu-minimal is, beyond just without a GUI
<lfam>It would be nice to keep a "full QEMU" package, IMO
<apteryx>civodul: interesting, I just noticed that the version string produced by the autoconf machinery (cat $.version) gives 1.3.0rc1.1-c3953, and this doesn't match what's expected in Makefile.am
<apteryx>if I run it a 2nd time it works because then my tree is dirty and the filename changes ;-)
<lfam>I know that people have been talking about splitting packages more, but I think it's better to keep them together :) So let's find a balance
<apteryx>err, $ cat .version
<apteryx>lfam: I think for QEMU we could do it with outputs;
<lfam>I just don't see the value of doing that. If you are working with QEMU VMs, then you have disk space
<apteryx>it'd at least alleviate the problem of having a ~700 MiB package :-)
<apteryx>sending this back and forth the network on a 1M upload link is not fun (e.g., when using offload, or when using guix deploy)
<lfam>Also, doesn't the grafting code require that all outputs are downloaded?
<lfam>Or am I misremembering that? Or was it improved?
<apteryx>ah yeah, this is probably still the case
<lfam>Well, my "objection" is not a strong one :)
<lfam>Ultimately, whoever makes these changes will be the one that decides :)
<lfam>Stand by for a wishlist bug about improving the UI about multiple outputs, too :)
<apteryx>hehe
<lfam>I've had the IRC log where I first discussed open in a tab for way too long
<iskarian>Hello :) is there a best practice for writing a package for something which installs files in /etc during make install, other than just preventing it from doing so via a patch and then having the guix package do it instead?
<apteryx>civodul: nevermind, that seems to be because one has to re-run 'autoreconf -f' *before* using Make again (at which point the var gets set and it's too late)
<apteryx>even though 'make release' ends up running 'autoreconf' itself
<apteryx>confusing
*apteryx documents
<lfam>iskarian: Basically, as you suggested. But, sometimes the package's build scripts take an argument (often called sysconfdir) that lets you put the files in /gnu/store/...-package-version/etc
<lfam>That's what we normally do in Guix
<lfam>Like, configuration templates would end up in that /gnu/store/...-package-version/etc directory
<lfam>It's up to the user / administrator, or a service, to put the files in the "real" /etc
<lubrito>cbaines Hi, could you give me some more details about what could be my next step on contributing?
***jx97 is now known as jx96
<lubrito>I was looking the repository and I saw the comparison.scm. derivation-outputs-differences-data is this the relevant function to change the field "recursive" from the outputs?
<lfam>apteryx: My wishlist bug for improving the outputs UI <https://bugs.gnu.org/47911>
<lubrito>cbaines I mean, are the functions of comparison.scm that I should be looking at?
<derivates>Hi, I'm getting this error: guix system: error: service 'xorg-server' provided more than once
<derivates>the only solution i've found is to take this off my services https://paste.debian.net/1194443/
<lfam>derivates: If you'd like assistance, please share your config.scm
<derivates>here: https://paste.debian.net/1194445/
<derivates>the issue raised once i dropped %desktop-services for %base-services, everything else workings and builds if i take I what pasted before off
<lfam>I see
<lfam>Your paste isn't sufficent on its own to create a Guix operating system, bty
<lfam>btw
<lfam>"guix system: error: 'paste_1194445' does not return an operating system or an image"
<derivates>sure I can share my repo
<lfam>I'd guess that slim-service-type and set-xorg-configuration are overlapping somehow
<iskarian>lfam: ah, that makes more sense! Is there an idiomatic way for a shepherd service to install /etc files when installed, then?
<lfam>derivates: You might see if you can set the keyboard layout from the slim service configuration
<lfam>Or, even better, someone else can answer you more specifically :)
<lfam>iskarian: Hm, I'm not sure (I'm not that strong with services).
<lfam>iskarian: All I could do to answer you would be read existing services and see what they do
<lfam>So, you could do that too :) But just like for derivates, hopefully someone else has a better answer
<derivates>I'll put xorg first, let's see if that works
<roptat>derivates, there's a xorg-configuration field in slim-configuration you can set, instead of a separate xorg service
<derivates>right!
<derivates>by "set-xorg-configuration config [login-manager-service-type]"
<derivates>i can put slim unter set-xorg-configuration, sounds better
<derivates>there's something minor i'm doing wrong here: https://paste.debian.net/1194450/
<derivates>i'm trying to do what i understand from here: "set-xorg-configuration config [login-manager-service-type]"
<derivates>might as well contribute with an example once i get this up and running
<apteryx>does someone know how to add a branch to Cuirass so that it gets built by the CI?
<apteryx>I'd like to add the 'version-1.3.0' branch.
<gr0n>why does guix spend a good 5 minutes on "building profile"?
<gr0n>how can i speed this up
<derivates>i pass --cores=$(nproc) to all my guix commands
<gr0n>oh, have i been using guix wrong this entire time
<apteryx>roptat: about the manual not refreshing, any pointer?
<apteryx>derivates: that's automatically done
<apteryx>(i.e., you don't have to :-))
<derivates>does it? hmm
<apteryx>gr0n: it's quite IO intensive
<gr0n>right, so the bottleneck is my shitty hdd
<derivates>same ^^^
<apteryx>Roughly (and probably unexactly), building a profile involves traversing the sum of all the files involved, and symlinking them to the store
<apteryx>gr0n: yes, HDD makes it a real pain
<derivates>quick, question I'm creating an iso image for a friend, what about some of my file-system declared stuff? how'd he do if he has a different partition scheme?
<apteryx>then there are also profile hooks which are notoriously slow, such as building the manpage database
<roptat>apteryx, not really, I was expecting that it just got stuck at building a dependency, but it's taking some time...
<roptat>I can build the doc locally
<apteryx>OK
<apteryx>weird that it'd take so long
<apteryx>berlin is not under very high load
<roptat>right, are you able to inspect what's going on on the server?
<apteryx>yeah
<apteryx>but I'm still a newbie with the CI so I don't know my way too well
<roptat>it's not part of the CI
<roptat>also, when I tried to build it, it ended up having to build the monolithic texlive, until I stopped it and waited a bit to get a substitute for that one
<roptat>so I thought maybe it was busy building it, but it's taking a long time just for texlive
<apteryx>I see the latest manual gets served from this static-web-site-service-type: https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/berlin.scm#n337
<apteryx>I'm not sure how that directory /srv/guix-manual-devel gets refreshed though
<roptat>so maybe you could try running the derivation manually?
<roptat>the static-website-configuration extends mcron, there's a cron job that updates git pulls it
<roptat>er, service-type*
<apteryx>I see
<apteryx>it seems like this service should be added to Guix proper :-)
<BlackMug>Hi There
<BlackMug>is there .iso for the new guix image?
<BlackMug>(i mean for testers not stable)
<BlackMug>i believe 1.2.1 if im not mistaken
<apteryx>BlackMug: 1.3.0 is in the making but there's nothing yet; still fighting with it :-)
<BlackMug>ah i see
<apteryx>you could try an 'latest' image and try that though
<apteryx>at this time the version-1.3.0 and master haven't diverged that much
<BlackMug>.iso ?
<apteryx>I think they are .iso.xz
<BlackMug>where to get it?
<apteryx> https://guix.gnu.org/en/download/latest/, it's an .iso
<BlackMug>great!
<apteryx>yw
<apteryx>roptat: the next job is schedule for 21 h in the +2 time zone (CEST?)
<roptat>that's once every hour
<roptat>that's in 30 minutes
<apteryx>the output of 'herd schedule mcron' suggests the frequency is every hour
<arkhan>Greetings to all, I started to have this error with the last update, apparently it is related to python-importlib-metadata: https://paste.debian.net/1194452/, does the same thing happen to someone else?
<derivates>roptat: do you think you can give me a hand on the issue i had before?
<derivates>arkhan: broken link
<arkhan>derivates: https://paste.debian.net/1194452
<roptat>arkhan, looks like a python issue indeed, maybe a dependency was updated that broke that package?
<roptat>derivates, which issue?
<apteryx>roptat: the mcron job is extended in hydra/modules/sysadmin/web.scm with (list #~(job '(next-minute '(0)) #$update [...]
<derivates>there's something minor i'm doing wrong here: https://paste.debian.net/1194450/
<roptat>apteryx, yes, that means every hour at minute 0
<derivates>i'm trying to do what i understand from here: "set-xorg-configuration config [login-manager-service-type]"
<roptat>derivates, from what I understand in the manual, that would be: (set-xorg-configuration (xorg-configuration ...) slim-service-type) only
<apteryx>roptat: the date is confused (?) in mcron.log, but there was a failed job at 'Tue Apr 20 22:00:00 2021 +0200'
<roptat>then you declare your slim-service-type later (or before, whatever) as a separate service entry
<apteryx>ug.org/
<apteryx>err, https://paste.debian.net/1194454/
<roptat>so, a failure of guix-translated-texinfo, right?
<apteryx>yes
<roptat>great, non deterministic failures...
<derivates>roptat: So I previously had it like this (i think this is what you mean): https://paste.debian.net/1194445/
<derivates>but getting this error: guix system: error: service 'xorg-server' provided more than once
<apteryx>roptat: the log output reads: https://paste.debian.net/1194456/
<derivates>this why i wanted to "put slim into xorg"
<arkhan>roptat: Based on what I was reviewing that package is part of the Liberia python standard, but in the git log at https://git.savannah.gnu.org/cgit/guix.git/log/ I don't see any recent update regarding to the default version of python3
<roptat>derivates, do it exactly like it was before, but add slim-service-type as the last parameter of set-xorg-configuration
<roptat>I mean literally "slim-service-type", not the whole service configuration
<roptat>you need to declare slim outside of set-xorg-configuration, but you want to let set-xorg-configuration know you're using slim-service-type instead of the default gdm-service-type
<roptat>derivates, https://paste.debian.net/1194457/
*roptat afk
<roptat>my students hate me for that in lab sessions, I give them answers for one issue and run away, but then they have a second issue right after that and I'm already gone ^^'
<derivates>great!
<derivates>it's a double slim-service-type declaration somehow
<derivates>is it possible to add an example to http://guix.gnu.org/en/manual/en/guix.html#index-set_002dxorg_002dconfiguration ?
<derivates>it wasn't THAT easy to switch away from GDM
*gr0n likes lightdm a lot
<roptat>tbh, past tense, haven't had students in almost two years
<roptat>derivates, that should be possible, yes
<roptat>but the reason why we have that is mostly to easily configure gdm that's hidden inside %desktop-services
<derivates>hm... i got Wrong type to apply: #<service-type slim 7fb56906ce00>
<roptat>it's not really required when you declare slim
<derivates>yeah, i took %desktop-services off for %base-services
<roptat>mh, don't know, then the manual is wrong or I can't read it
<roptat>derivates, try this instead and remove set-xorg-configuration: https://paste.debian.net/1194459/
<derivates>yeah, i was about to suggest using slim's field of xorg-configuration
<vagrantc>so, got some of the typical package description typo fixes after testing origin/version-1.3.0 ... should those go to master and/or origin/version-1.3.0 ?
<apteryx>ah nice, there's a cuirass-service that takes branches as argument
<roptat>vagrantc, they can go to both branches
<derivates>roptat: actually this was the correct way
<apteryx>vagrantc: I'd send it to master for now though, as version-1.3.0 is still in flux
<derivates>but apparently SLIM won't pick certain settings... Wrong type to apply: #<<keyboard-layout> name: "us" variant: "altgr-intl" model: #f options: ("caps:escape")>
<apteryx>(e.g., I delete and recreate the branch often)
<apteryx>it's mostly there for others to try (and soon for the CI to build it)
<apteryx>(at this point in time)
<vagrantc>roptat, apteryx: thanks!
<iskarian>something I am trying to package manually installs a few things using $(INSTALL) ... $(DESTDIR)/etc/..., yet when I set DESTDIR using (assoc-ref %outputs out) I end up with some things installed in a nested /gnu/store/...
<derivates>roptat: I ended up building succesfully with: https://paste.debian.net/1194462/ ; even tho i couldn't set my slim settings, it's fine
<iskarian>setting DESTDIR as above, and then setting prefix= seems to somewhat work, but now I'm getting errors about libraries not being found in RUNPATH
<AleQu[m]>Ni! Hey everyone, I've migrated my main PC to Guix System over the weekend (for which I was here before under the name `solstag`) and now I'm writing my first package definition. I've stumbled upon something that I haven't been able to figure out: with only `(build-system gnu-build-system)`, guix is compiling the package with a very old version of GCC (gcc-7). Why is that and how can I make sure in the package definition that
<AleQu[m]>it uses the latest toolchain? Thanks!
<apteryx>vagrantc: by the way, if you are interested in learning how 'make release' works (along with debbuging the current failures blocking the release :-)), I regularly update https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/release.org with my findings.
<apteryx>you can skip the 'updating translation files', as those have been updated recently and commited an that branch (and master) already
<apteryx>lle-bout[m]: I forgot; had you offered access to a powerpc machine?
<BlackMug>Hi There
<BlackMug>trying to install 1.3.0
<BlackMug>herd start cow-store /mnt
<BlackMug>this command doesnt work
<BlackMug>i will copy error message one sec
<BlackMug> https://gofile.io/d/bsx49T
<BlackMug>i should report errors here or i open ticket in the bug tracker for 1.3.0?
<apteryx>That's using the latest master image, BlackMug ?
<BlackMug>cc apteryx roptat
<BlackMug>apteryx the link you gave me
<apteryx>OK!
*apteryx looks at the error you linked
<apteryx>ah, I need to whitelist 23 scripts on that page, could you please paste it on paste.debian.net instead?
<lfam>AleQu[m]: The reason that GCC 7 is being used to build packages is that, currently, GCC 7 is the "default" version of GCC on Guix
<lfam>It's set here: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/gcc.scm?id=46852000c99b226ee61384e3b63595e9ffdaaf10#n597
<lfam>If you want to use a different version of GCC in a package, you can add a different GCC package to the native-inputs of your package
<BlackMug>apteryx what i paste? the error lines you mean?
<lfam>So, for example, you could add ("gcc" ,gcc-10) to your native-inputs, AleQu[m]
<apteryx>yeah, I use Icecat and only whitelist a few sites
<apteryx>we recommend paste.debian.net as it doesn't rely on javascript
<BlackMug>wget https://srv-store3.gofile.io/download/bsx49T/f1cc2d7faad7f177f051790b478aaf56/herd.png
<apteryx>thanks, that did it
<apteryx>I hadn't realized it was an image
<BlackMug>if you cant get it or open it i can write down the error no problem
<BlackMug>because i cant copy/paste from VM post installation
<apteryx>ah, it downloaded the page's HTML instead of the image, it seems
<apteryx>if it's not too verbose, that'd be useful in the bug report you'll open, yes!
<apteryx>or if the image is small it's OK to add it to the bug report as an attachment
<apteryx>small being < 100 KiB I'd say
<lfam>It downloads fine with `curl -LO https://...`
<BlackMug>yeah 3.1kb
<apteryx>lfam: is it a png?
<lfam>Yes
<lfam>It's definitely a weird message that I haven't seen while testing the installer
<lfam>I wonder if there is anything unusual about the setup...
<BlackMug>i can give you every step i have done
<BlackMug>or you can get give me any command to debug anything for you
<apteryx>that'd be nice to write down in the bug report yes! as a reproducer
<BlackMug>ok i will open a ticket and post here
<BlackMug>one sec
<nckx>apteryx: Ricardo has requested a firewall hole. That is pending. In the meantime, Mathieu has responded (to your mail IIRC?) with a wireguard snippet that's eminently cargo-cultable, so I can use that if the MDC doesn't respond.
<nckx>I'll give them some time though; a direct connection is still less fragile IMO.
<apteryx>one wart with 'make release' is that when it fails, it won't pick up when it left the next time you try
<apteryx>so you basically have to clean the tree, undo the automatic commits and start over
<apteryx>not fun
<apteryx>or manually figure out the individual commands it's running (and failing on) and retry those manually (makes more sense)
<lfam>nckx: Check PMs
<apteryx>nckx: thanks! while you're here, is this machine supposed to be up? (name "localhost") (port 2223). It returned #f while offloading
<apteryx>guix offload: error: remote command 'guix repl -t machine' failed with status #f
<BlackMug>apteryx https://issues.guix.gnu.org/47917
<apteryx>BlackMug: thank you! When I get to roll the first RC release I'll definitly try reproducing it
<BlackMug>sure tyt
<smoothdev>I'd like to get started with defining a package for a small program which is not packaged yet, I've checked all the dependencies (but maybe wxgtk3 which is optional) seems to be already available, it is a CPP terminal program
<apteryx>nckx: oh, why is a firewall hole necessary?
<apteryx>wireguard has a single port which is public, and that should be enough
<smoothdev>the first suggestion I have would be for the maintainers of the web site listing the packages, is it possible to have a link to the package descriptor in the git repository on the page?
<apteryx>the external machines connect to it (with their whitelisted public key, ala SSH), and keep the connection open in case they are behind NAT
<AleQu[m]><lfam "So, for example, you could add ("> Thanks, will try that. I had thought about adding gcc-toolchain-10 to native inputs, but was afraid that would not be the right way to do it. What is the difference? lfam
<rekado>yay, got around the clang problems
<rekado>I had to build libcxxabi and then build libcxx with libcxxabi
<rekado>and I had to hide the GCC headers.
<xmx>Is it okay for description http://ix.io/2WLI
<xmx>If there is a wrong in the subbmitted patch. Do I have to resubmit it ? Or someone will look in to it.
<rekado>what issue number did you get?
<xmx>47914
<nckx>apteryx: The policy is ‘block by default’, at least for non-HTTP(S).
<nckx>apteryx: localhost:2223 is down for different reasons 😒 I have a visit planned this week.
<rekado>xmx: I’m a little confused. The patch at https://issues.guix.gnu.org/47914 is about “xdo”, not “daemonize”.
<apteryx>nckx: you mean for the MDC?
<rekado>xmx: for the description I would remove the definition.
<rekado>and perhaps I’d also remove the term “Unix” ;)
<nckx>apteryx: Yes.
<nckx>berlin can't connect out.
<apteryx>are we talking about using wireguard or something else?
<rekado>not wireguard
<apteryx>OK
<rekado>plain old firewall exception for outgoing SSH connections
<apteryx>is there a reason we can't/don't want to use wireguard? It seems relatively painless to setup.
<rekado>nckx: if you have a moment I’d be happy if you could comment on my plans to purchase some aarch64 boards
<nckx>The reason for 😒 above is that I rebooted the machine without configuration changes and it never came back up & I blame Guix.
<xmx>rekado: I also made package def for daemonize. I gave a wrong commit message.
<xmx>Is this okay http://ix.io/2WLP
<xmx>Its for daemonize
<nckx>rekado: I don't know *anything* about aarch64. Seriously. The only reason I can host an Overdrive is because it acts exactly like a slower PC.
<civodul>nckx: or like a VCR gathering dust and not making too much noise
<rekado>nckx: oh, I meant, like, you know, approve the purchase or something :)
<nckx>There's actually a VCR next to them this week! It... makes less noise.
<nckx>Oh, sure.
<nckx>I thought it was cancelled again.
<nckx>I'm confused.
<nckx>‘I decided, for the time being, that I don't want to take the risk of spending thousands ...’ &c.
<nckx>These are different orders?
<rekado>yes
<rekado>I plan to buy three boards myself
<rekado>let me find the message id for you
<nckx>And you don't share Leo's concerns?
<nckx><87y2dfnvsj.fsf@elephly.net> ?
<rekado>here’s one: Message-ID: <87tuo5p1cj.fsf@elephly.net>
<rekado>I think Leo’s concerns are understandable, but I’m aware of the risk of sitting on the expenses.
<rekado>it would not be great. At all. But it wouldn’t ruin me right away :)
<roptat>and you'd make a very generous donation to the project :D
<nckx>I replied to the other on in the mean time.
<nckx>rekado: How do I even search for Message-Ids in mu4e?
<rekado>the key name is “msgid” or “i”
<nckx>Thanks. Done.
<vagrantc>apteryx: thanks for the info regarding "make release"! i've so far only fiddled with "make dist" to generate one-off tarballs
<lle-bout>hello! 'make' fails on master for me, with doc errors
<lle-bout>./doc/guix.pt_BR.texi:34518: @include: could not find contributing.pt_BR.texi
<lle-bout>and others
<lle-bout>is that a me problem or anyone gets it also?
<nckx>lle-bout: Have you tried rebootstrapping?
<lle-bout>nckx: yes
*nckx tries.
<Sebastien-16199>Hi there! Newbie question: can we define a source that is a set of local files? At the moment I need to package my sources as a tarball and compute the signature, but I'd like to skip that step as I'm building locally.
<mbakke>Sebastien-16199: perhaps you can use (source "/the/directory")?
<Sebastien-16199>I tried `(source ".")` which gives me a `guix build: error: invalid name: '.'`
<mbakke>Sebastien-16199: try the absolute pathname :)
<mbakke>or (getcwd) perhaps
<Sebastien-16199>Ah, yes, that did work! Now, the next problem I have is that I'm packaging a Python module with the intention to package it and run it as a container. I added a dependency in my `setup.py` but it somehow fails to resolve.
<Sebastien-16199>Specifically ` install_requires=[ "pytz" ]`, which fails downloading `Download error on https://pypi.org/simple/: [Errno -2] Name or service not known -- Some packages may not be found!`
<Sebastien-16199>(I have started `nscd` just in case, BTW)
<Sebastien-16199>and `curl https://pypi.org/simple/pytz/` resolves properly
<lle-bout>nckx: only thing I didnt do is re-clone, I did make clean, bootstrap, configure, make..
<apteryx>There's now a Cuirass specification/jobset for building the version-1.3.0 branch: https://ci.guix.gnu.org/jobset/version-1.3.0
<lle-bout>why did we go to 1.3.0?
<mbakke>Sebastien-16199: the build environment does not have network access, did you try adding "python-pytz" as a propagated-input?
<apteryx>lle-bout: to denote the amount of changes that went in the release
<lle-bout>apteryx: I see
<Sebastien-16199>@mbakke: No as the documentation seems to say that the python-build-system would automagically inject that from the setup.py
<mbakke>Sebastien-16199: the PyPI importer only reads requirements.txt IIRC
<Sebastien-16199>@mbakke: It does detect the dependency from setup.py, does does not manage to retrieve the package from the network.
<Sebastien-16199>@mbakke: So I tried (propagated-inputs `(("python-tz" ,python-tz))) and this gives me a `error: python-tz: unbound variable`
<mbakke>Sebastien-16199: the package name is "python-pytz"
<mbakke>(and variable name)
<mbakke>Sebastien-16199: did you create the package definition by hand, or with "guix import pypi PACKAGE"?
<Sebastien-16199>@mbakke: Still getting the same error: error: python-pytz: unbound variable -- hint: Did you forget a `use-modules' form?
<Sebastien-16199>@mbakke: I'm creating everything by hand, I want to do everything from source not REPL
<mbakke>Sebastien-16199: ah, you need #:use-modules (gnu packages time) somewhere at the top of the file
<Sebastien-16199>@mbakke: guix import pypi pytz worked, package was resolved and downloaded
<mbakke>Sebastien-16199: if the package you are packaging is already on PyPI, "guix import pypi PACKAGE" will produce a complete package definition to be pasted into your favorite editor :)
<mbakke>you don't need to guix import python-pytz, because it is already available in the (gnu packages time) module
<Sebastien-16199>I tried adding `#:use-modules (gnu packages time)` at the top, but got `error: gnu: unbound variable`. I also try to ad (gnu packages time) in the (use-module (guix-packages) ...) preamble with similar results
<dongcarl>Testing v1.3.0 right now...
<dongcarl>Seeing error: failed to load 'guix/import/go.scm':
<dongcarl>ice-9/eval.scm:293:34: no code for module (htmlprag)
<dongcarl>Configure did not complain
<mbakke>Sebastien-16199: (use-modules (gnu packages time)) should work
<Sebastien-16199>@mbakke: Scratch that, actually including it in the existing (use-modules) did the trick, I forgot to save. Now could you elaborate on why this is required? I don't understand why having `time` suddenly enables the downloading of a Python package.
<nckx>lle-bout: I can't reproduce it in my very much not shinily new checkout.
<nckx>On 4685200.
<lle-bout>nckx: weird
<lle-bout>nckx: I'm on the same commit
<mbakke>Sebastien-16199: (use-modules ...) is required to make variables from other modules available in the current scope
<lle-bout>nckx: I did: rm -rf * && git checkout -- .
<lle-bout>Re-trying
<nckx>./doc/guix.pt_BR.texi does not exist here. MAKEINFO doc/guix.pt.info does not occur in my ‘make’ output.
<lle-bout>nckx: I get this now: make[3]: *** No rule to make target '../../guix/scripts/import/nix.scm', needed by 'guix.pot-update'. Stop.
<lle-bout>nckx: with: rm -rf * && git checkout -- . && ./bootstrap && ./configure --localstatedir=/var && make -j$(nproc)
<Sebastien-16199>@mbakke: yes, but what is the relation between the (gnu packages time) and python-pytz? Why is it required? I'm asking as basically there I'd like to have that automated. From what I understand, for any PyPI package I want to use I would need to 1) run guix import pypy $PACKAGE 2) add the corresponding (propagated-input) 3) run a guix build -f mypa
<Sebastien-16199>ckage.scm 4) Look at the hint in the console for which module I need to add 5) add the module in (use-modules ...) 6) run guix build -f mypackage.scm again. This seems a bit contrived -- is there a better way to do this that would be fully automated?
<lle-bout>nckx: this one last seems like a genuine error
<nckx>Yes, it seems so. po/guix/Makefile: ../../guix/scripts/import/nix.scm \
<mbakke>Sebastien-16199: python-pytz is defined in the (gnu packages time) module: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/time.scm#n123
<mbakke>Sebastien-16199: you don't need to 'guix import' anything that is already packaged
<mbakke>but you will need to import the corresponding module and add the package as a propagated-input
<lle-bout>nckx: also po/guix/POTFILES.in or is that generated?
<nckx>lle-bout: Time for me to test in a clean clone. This will take a while.
<Sebastien-16199>@mbakke: And is there a way to automatically get which module a package belongs to?
<lle-bout>nckx: I think the command I sent is pretty much equivalent (besides leftover hidden files which also includes .git which must not be deleted but those shouldnt affect build)
<civodul>i've pushed that POTFILES.in fix, sorry about that!
<lle-bout>nckx: It's interesting to know that 'make clean' doesnt clean everything
<mbakke>Sebastien-16199: the PyPI importer is for creating package definitions for things that exist on PyPI but not in Guix. It will automatically add things from the remote requirements.txt as (propagated-inputs ...), but currently it can not create the corresponding (use-modules ...) stanza.
<lle-bout>civodul: thanks a lot!!
<mbakke>Sebastien-16199: my main method of finding the module is 'guix show PACKAGE'
<civodul>i was secretly hoping someone would clean up my mess but hey ;-)
<nckx>^C
<mbakke>gnu/packages/time.scm corresponds to (gnu packages time)
<lle-bout>civodul: if you didnt do it I was about to, I was mostly puzzled about how the commit message should look like heh
<Sebastien-16199>@mbakke: OK, makes sense, so then the alternative would be to calling `guix import pypy $PACKAGE` to generate the .scm package definitions, and then load them as part of my main package.scm -- at least for the packages not available with guix by default?
<mbakke>Sebastien-16199: That sounds about right. Note that package.scm can contain multiple packages. :-)
<Sebastien-16199>@mbakke: Well, that is super useful. For context I'm evaluating Nix and Guix for our build system, and really appreciate how quickly I can get support with Guix and also the quality of the responses. That's exciting!
<nckx>lle-bout: Yes, it was equivalent. My ~/guix has precious untracked files.
<lle-bout>nckx: okay! :)
<rekado>Sebastien-16199: one note about the pypi importer: the quality of generated packages from Pypi is sometimes a bit lacking. I ran into several cases where I had to add more inputs to get the thing to compile.
<rekado>In that case I recommend asking for help here.
<Sebastien-16199>@rekado: Thanks for that, it will also be an opportunity to get up to speed on Scheme, it's been a while ;)
<mbakke>Sebastien-16199: :-)
<mbakke>Sebastien-16199, rekado: I think that's because often there is a separate "dev-requirements.txt" or similar for test dependencies, which the importer can't know about
<Sebastien-16199>Oh, and that's not going to be a popular question, but how can I add a proprietary license to the package definition?
<rekado>mbakke: right; it seems that Python conventions have been shifting a little over the past years
<mbakke>and indeed, some packages don't have requirements.txt and just use install_requires from setup.py
<rekado>Sebastien-16199: you can declare any license value, or even use a boolean.
<Sebastien-16199>@rekado I wasn't sure as in licenses.scm it seems structured, but that solves my problem
<Sebastien-16199>So I now have my python app packaged, how can I package it as container image and run `python -m mymodule` to execute the code? (I'll publish a repo with the example in there so that it will help others)
<rekado>Sebastien-16199: you can use “guix pack” to build different images, including a plain tarball, a Docker image, a Squashfs image (for Singularity), etc
<lle-bout>nckx: things built now with the nix fix and rm etc.!
<nckx>\o/
<rekado>the “guix pack -RR” option is also pretty neat if you don’t have an existing container setup that expects Docker/Singularity images