IRC channel logs


back to list of logs

***jonsger1 is now known as jonsger
<PotentialUser-85>ryanprior: I am using git-fetch to download the tagged version "v0.95" from 2019 instead of the pypi url, since the version available on pypi is from 2015. I have the same problem (no found) with both versions.
<rekado>Zrythm looks very interesting. The ability to extend it with Guile means that I will *have* to see if I can switch from Ardour.
<ryanprior>Ooh that's cool software, thanks for working on a package for it!
<ryanprior>PotentialUser-78: it looks like they have some documentation of their build system here:
<ryanprior>It references but I don't see a file in the repo. Wonder where it's stored, or if there's a script that generates it or something?
<alextee[m]><rekado "Zrythm looks very interesting. "> new release out today!
<alextee[m]>i think it's just a matter of bumping the version, don't have time to send a patch now
<ryanprior>The file doesn't seem to be present either, so maybe these docs are outdated
<guix-vits>ryanprior: maybe some script generates the
<ryanprior>I think you need to get in touch with the AYAB folks and ask for clarification about how their build system works:
<ryanprior>I've built Python apps and Qt apps and I don't see what I'd consider the "normal" apparatus for either one in place here, but there's gotta be an answer
<lfam>Does anyone know a package that sets up MIME types for the test suite?
<lfam>I'm testing Okular and the tests all fail due to missing MIME plugins, like this: "No plugin for mimetype '"application/pdf"'"
<lfam>And similar for other types
<ryanprior>Here's an interesting commit from the AYAB repo:
<ryanprior>"Removing unused python setup files", it removes, setup.cfg, and
<ryanprior>So I think they changed their build system and just didn't update their docs.
<spudpnds>I do not understand guix dependencies. I install "emacs-guix" and it downloads a ton of packages, including subversion!?
<spudpnds>Python!? Dbus!?
<spudpnds>Ugh, I just don't get it. Why would installing an emacs package install python?
<guix-vits>spudpnds: try `guix graph --path emacs X`
<lfam>spudpnds: Those are dependencies of the emacs-guix and / or Guix itself
<ryanprior>emacs-guix pulls in texlive apparently, which is a kitchen sink package
<rekado>alextee[m]: yeah, I saw your announcement and it reminded me that I should make time to give Zrythm a thorough spin :
<rekado>argh, smartparens prevented me from inserting a closing paren here… Why is it enabled in my ERC buffer…?
<rekado>–> :)
<rekado>there we go
<spudpnds>ryanprior: That's surprising, if I download it from MELPA it's just a bunch of emacs lisp. I'm not sure why guix is bringing in all this stuff.
<ryanprior>Well, for one thing, melpa is perfectly happy to let you install a non-functioning package that lacks its dependencies, while emacs packages installed via Guix come with their dependencies (and transitive dependencies)
<ryanprior>Incidentally, in this case, guix is also perfectly happy to let you install a non-functioning emacs-guix package because that package is just a mess in general
<ryanprior>But John Soo has been working on pulling it into shape so hopefully we'll be putting that parenthetical behind us soon :)
<spudpnds>ryanprior: I'm starting to get that feeling. I struggled a lot to get it to work on an ubuntu system where I'm running guix as a local user. So I thought I'd sping up a guix os box, and it's not any easier :)
<ryanprior>No, the truth about emacs-guix is it doesn't work
<spudpnds>Ok. I'll give up on it for now, and go back to learning scheme :)
<spudpnds>Thanks for the tip.
<rekado>it no longer works; it used to, but it was declared unmaintained. This will change soon.
<spudpnds>Myabe my dependency problem is because I thought I'd be clever and do a "guix gc".
<spudpnds>So installing tmux causes me to download mesa, cups, and cairo.
<ryanprior>You are gonna find a lot of that spudpnds, there's a lot of package entanglement in the system and it's going to take a lot of work to disentangle.
<spudpnds>guix-vits: I'm going to look at guix graph output and see if I can better understand things.
<spudpnds>ryanprior: Is that how you generally look at dependencies?
<ryanprior>Not sure what precisely you're asking
<spudpnds>Also, I feel a little bit guilty of hitting for what seem to be the same files over and over again.
<guix-vits>spudpnds: guix-service-type at
<guix-vits>it can keep deps on gc
<guix-vits>not by default
<spudpnds>ryanprior: No worries, I'm not sure I entirely understand what I'm asking either. I should read more and ask less ;)
<guix-vits>u need use extra-options field of guix-configuration
<user_oreloznog>good night guix!
<ryanprior>If you're hitting it over and over with a script, you should probably stop that and cache responses instead. If you're just doing it a few dozen times manually in a session, don't worry about it
<Gooberpatrol66>I generated an image with guix system disk-image, and when I boot it, ifconfig shows no network interfaces. I was just wondering if I am forgetting something.
<spudpnds>ryanprior: I see for a number of packages I install I end up with 'cups-2.3.3' as a depdencency. I've downloaded that when I installed emacs, I downloaded that when I installed tmux, I feel caching would be useful somewhere here.
<spudpnds>This is true for a lot of packages.
<ryanprior>Are you doing "guix gc" every day or between each install? That's intended to be a once-in-a-while operation to reclaim some disk space, not an everyday operation.
<spudpnds>I just did it once to see what would happen.
<ryanprior>Okay no problem then. Guix will only install cups again when there's an update, otherwise it'll use the cached one in your store.
<spudpnds>Ok cool. Thanks for your help!
<guixy_>Interesting... multiple machine learning algorithms can predict if source deviates from its build system's equivalent of download->config->make->make test->make install with 90% or greater accuracy. BernoulliNB gives 94% accuracy. MultinomialNB gives 91% accuracy. KNeighborsClassifier gives 95% accuracy. DecisionTreeClassifier gives 95% accuracy. I'm taking the floor for all of these.
<guixy_>When my results are ready and my grades are finalized, I'll let the guix community tear apart this project.
<ngz>Hmm, I packaged wob but I get a segmentation fault when I try it…
<ngz>This does not bode well…
<guix-vits>i just had a dvd failed. want a dvd-raid. why didn't we have a filesystem for that?
<guix-vits>btrfs, zfs, that justa buzz words, i need dvd safety, rlly
<guix-vits>preferably raid10
<Aurora_v_kosmose>We do, sort of.
<Aurora_v_kosmose>You add par2 files with the data you store.
***procra02 is now known as procra
***scs is now known as Guest16503
<Gooberpatrol66>how do you get a guix machine to tell its hostname to the router?
<OriansJ>Gooberpatrol66: anything that supports Multicast DNS Service Discovery will do that
<Gooberpatrol66>OriansJ: is there a particular shepherd service that needs to be enabled?
<Gooberpatrol66>one of my guix machines has a hostname in the router but not the other one
<OriansJ>Gooberpatrol66: look at the diff between the config files
<Gooberpatrol66>the other one is headless, so the difference is likely buried somewhere in the massive number of %desktop-services
<OriansJ>something like avahi would do it
<OriansJ>or mdns
<Gooberpatrol66>ok thanks, I will try that
<brettgilio>Im trying the 1.2.0 installer image and it freezes on trying to find wifi networks with my external thinkpenguin card
***scs is now known as Guest44817
***amfl_ is now known as amfl
<blendergeek>23:13 *** NAMES @ChanServ [df] alextee alextee[m] alfplayer[m] alphazino[m] AlpineLlama am3on[m] amfl amk andi- ane AppAraat[m] apteryx ArneBab atomsk298[m] avoidr aweinstock badpixel bandali bavier[m] bayfront-log bdju benny biotim bjth[m] blendergeek bn_work boegel bojan_petrovic bonz060 BozoJunior[m] bqv branjam brettgilio brown121407 bsima cairn camlriot42 cantstanya cap case_ catonano cbaines Chibani[m] chiefgo
<blendergeek>at chipb chregon[m] chrislck Christoph[m]1 clemens3_ clone11 cnmne[m] colemickens CompanionCube Coyo[m] cyberwolf[m] cyraxjoe cyrozap daerahj2[m] danielp3344 davidl daviid db48x dddddd deedend[m] defaultxr detran dftxbs3e dissoc distopico Distopico[m] distrotube dongcarl dopplergange drakonis dustyweb ece efraim elais elementsmatrix[m elibrokeit elliott_ emacsen emacsomancer emyles[m] emys[m] erhandsome erkin eth01
<blendergeek>euandreh Exagone313 faya01[m] FennecCode fitzsim fkz flor flypaper-ultimat fnstudio Formbi fr33domlover freekurt g_bor[m] gambpang_ gate32[m] genevino ggoes GNUtoo goldenshimmer Gooberpatrol66 grumble Guest60027 guix-vits Hasnep[m] helaoban hendursaga herlocksholmes hji Hozanahin[m] ilmu ilya-fedin iyzsong jackhill Jackneill janneke jchmrt jespada jess jetomit jfred jgart[m] jitwit jkossen jlicht jluttine joehillen
<blendergeek>jonjitsu[m] jorge[m] jsoo juh_[m] jxyzn kaiwulf katco kelsoo kensington kfvn khassanov khlfc[m] Kimapr[m] kini kisaja[m] kkaalltt[m] kmicu kozo[m] kristianpaul l1x langdon leomd leoprikler lewo Lightsword lihua link2xt lispmacs lispmacs[work] lkd luhux luke-jr Lurkki[m] lytedev[m] maav madage malaclyps malaclyps_ manol1s markasoftware marusich matijja matryoshka MatthewAllan93 mbakke mekeor mekeor[m] michel_slm MidA
<blendergeek>utumnHotaru midnight milkman[bot] mizukota[m] monego[m] mroh MrtnDk[m] MSavoritias[m]2 nalaginrut namtsui nckx neuromor` newline[m] nickdaly nikita` niko NinjaTrappeur nitro__ njoseph nlofaro Noclip Noisytoot nothingmuch null_radix[m] numerobis omasanori[m] OriansJ ornxka PatternFinder[m] penguwin pescobar pflanze phant0mas pie_ pinkieval pinoaffe pkill9 plasma41 pmy procra profmakx pukkamustard[m] PurpleSym pushcx
<blendergeek>qyliss raghavgururajan raingloom RanYak[m] rCapital-Surpris rdes[m] regtur rekado_ rixed robmyers roptat roscoe_tw rotty Rovanion runejuhl ryanprior samueldr schaeffer search_social seeg123 sepanko_ ShadowJonathan shtwzrd[m] siraben Sleep_Walker sliced smithras snybajl[m] spk121 spudpnds srk ss2 stefanc_diff str1ngs sturm_ sumpfralle1 surpador terpri teythoon theduke thomassgn tinker tldr32 tsmish[m] txgvnn V viaken
<blendergeek> vldn vup w1gz wehlutyk wigust winsome[m] wleslie Wojciech_K xelxebar xgqt xMopx yjftsjthsd
<ggoes>you rang
<blendergeek>Sorry I think I just accidentally tagged everybody.
<V>that you did
<ornxka>youre all probably wondering why i have gathered you here today
<blendergeek>Sorry guys. I literally just started using emacs as my IRC client and I hit enter ...
<katco>happens all the time :)
<xMopx>> emacs
<ryanprior>I used erc for years and I don't know how you'd send a message containing everybody's names X.X
<cnmne[m]>haha hellooo
<bavier[m]>The Summoning
<pie_>ryanprior: i think ive seen it happen before
<kaiwulf>I was wondering wtf I was being tagged lol
*chrislck jumps
***chrislck_ is now known as chrislck
<raghavgururajan>Does anyone here using Jami on Guix System?
<raghavgururajan>Mine crashes.
<guix-vits>raghavgururajan: for test-user too?
<raghavgururajan>guix-vits, For test user?
<guix-vits>w/o configs, empty home
<raghavgururajan>I freshly installed it
<raghavgururajan>No previous config files
<guix-vits>`strace` it, maybe?
<guix-vits>it sould process some strings before crash.
<guix-vits>raghavgururajan : it is gnome?
<guix-vits>> This package provides the Jami client for the GNOME desktop.
<raghavgururajan>I am currently using slim+dwm
<guix-vits>i hope DE cannot affect the thread thingy.
<leoprikler>raghavgururajan: it does work when you run it on GNOME
<leoprikler>okay, perhaps I cheated too, but what you need to do is to start dring (dbus service) and then jami
<leoprikler>dbus from `guix environment` is a bad idea btw. ;)
<MrtnDk[m]><blendergeek "utumnHotaru midnight milkman[bot"> What's up?
<MrtnDk[m]>brettgilio: Are you Brett from Telegram?
<MrtnDk[m]><blendergeek "Sorry I think I just accidentall"> @blender Can't speak for everybody, but you did manage to tag me. 😀
<chrislck>civodul: guix's ui.scm's known-variable-definition is rather clever
<MrtnDk[m]>blendergeek: Can't speak for everybody, but you did manage to tag me. 😀
<MrtnDk[m]>blendergeek: Congratulations on getting on ERC, if that indeed is your new client!
<MrtnDk[m]>chrislck: Welcome to
<midnight>that's twice I'm pinged? what's up?
*midnight scrollbacks
*midnight backs into hedge
<MrtnDk[m]>midnight: Whats "Hedge" ?
<chrislck>sneek: later tell civodul guix's ui.scm's known-variable-definition is very clever, I'd like to copy it
<kisaja[m]>can guix work if i fully ban 'sudo' and 'doas'?
<MrtnDk[m]>kisaja: You don't have to, afaik.
<kisaja[m]>those are pretty useless, and only bring vulnerabilitys
<MrtnDk[m]>kisaja There are different opinions on that, but I don't see how those apps would prevent your Guix installation from working. The problem might be something else. Maybe you can share what your problem is?
<kisaja[m]>it came preinstalled so i thought its essential
<OriansJ>kisaja[m]: the only essentials are a posix kernel and a scheme interpreter that can run guix (and MesCC, gash and gash-utils); everything else is a build dependency and a choice.
<db48x>sudo is generally considered essential, but it's not actually holding your system together
<OriansJ>oh and cryptsetup if you luks encrypted your drive
<db48x>yes, that could be important :)
<OriansJ>db48x: actually it is a fatal error on first install for guix if you forget it; shepard panics and there is no fix besides reinstall
<db48x>so user-friendly :)
<OriansJ>db48x: actually you have to choice the non-user friendly route to even do that
<OriansJ>eg something like this:
<kisaja[m]>good to know, seems i forgot guix isn't alpha lol
<OriansJ>kisaja[m]: and if you would like an explicit configuration to build upon:
<guix-vits>OriansJ: change comment from sysadmin to devops. cause guix.
<OriansJ>guix-vits: no
<OriansJ>would not be accurate
<guix-vits>the rejection state, aha
<OriansJ>guix-vits: if developers need access to production; you already made too many mistakes in your development process.
<OriansJ>guix-vits: I've worked ops and I am a dev but I see no need to merge them together unless your staff count is 1
<guix-vits>always too many mistakes. devops is reality in config.scm, ye.
<OriansJ>guix-vits: devops was a joke; taken seriously and abused in foolish attempts to cut costs.
<guix-vits>no jokes in config.scm, even if they tell the truth about config.scm?
<guix-vits>ok, then i dont understand it.
<OriansJ>guix-vits: if you wanted to see a joke, checkout cc_x86.M1 specifically when dealing with C's break statements
<guix-vits>check what?
<fonz>How can I create a manifest file for the current generation? I didn't find it in the manual.
<guix-vits>fonz: leoprikler?
<guix-vits>^^^ fonz
<leoprikler>not sure what exactly they mean, but `guix describe --format=channels`?
<guix-vits>thank u
<OriansJ>guix-vits: line 2067
<guix-vits>not understood, but bookmarked
<OriansJ>guix-vits: the TV series breaking bad; main character Walter White started the whole thing because he learned he had lung cancer.
<fonz>leoprikler: guix describe doesn't seem to work here (guix describe: error: failed to determine origin) and doc says it produces a channel. but a manifest is a list of packages, not the same. no? sorry. new to guix.
<OriansJ>guix-vits: you might benefit more from a clone as it is literally C compilers and scheme from hex0
<leoprikler>fonz: sure, a manifest is different from a list of channels, but channels don't have a manifest in the same way, that profiles do
<leoprikler>ah, okay, I goofed
<leoprikler>"current generation"
<leoprikler>You can extract that via `(profile-manifest "/path/to/profile")`
<leoprikler>[I incorrectly assumed pull generation, sorry.]
<fonz>leoprikler: That sounds what's I'm looking for. But profile-manifest doesn't exist in the documentation at And it fails here: $ echo "(profile-manifest \"$HOME/.guix-profile\")" | guix repl
<leoprikler>fonz: profile-manifest is a guile procedure
<fonz>leoprikler: that's why I piped it into the repl. wrong?
<leoprikler>you need to (use-modules (guix profiles))
<fonz>leoprikler: yes! thank you
<ngz>Hello. When trying to package gammastep, I get "gi.require_version('Gtk', '3.0')
<ngz>: Namespace Gtk not avalaible" even though gtk+ is among inputs, and I imported glib-or-gtk-wrap from glib-or-gtk build system (the base build system is gnu). Any idea?
<mdevos>ngz: can you post your package definition?
<ngz>mdevos: sure, one sec
<leoprikler>ngz: you need to wrap GI_TYPELIB_PATH
<ngz>leoprikler: doesn't glib-or-gtk-wrap take care of this?
<leoprikler>sadly not
<ngz>OK, so I'm going to remove that phase and wrap GI_TYPELIB_PATH directly.
<ngz>Ah. Thanks. Now I get a different error (!), but at least I'm moving forward.
<leoprikler>packages, that need gi usually do their 'gi-wrap after 'glib-or-gtk-wrap
<leoprikler>see komikku and polari for those that I packaged and a bunch of others where I took the idea from
<ngz>For now I get "_scale_factor: assertion 'GTK_IS_WIDGET (widget)' failed". Let me see Polari.
<ngz>Oops, truncated message
<ngz>(.gammastep-indicator-real:61667): Gtk-CRITICAL **: 13:14:28.718: gtk_widget_get_scale_factor: assertion 'GTK_IS_WIDGET (widget)' failed
<ngz>I may be missing gsettings-desktop-schemas
*ngz scratches his head.
<mdevos>ngz: no idea what's going on, but you could set a breakpoint there with gdb
<mdevos>see what class the variable widget is
<ngz>Debian does not package the GUI
<ngz>Maybe I should drop it too, so no more Python/GTK nonsense…
<leoprikler>well, there is at least an argument for putting it into its own output
<ngz>This argument doesn't hold if I cannot make it work…
<leoprikler>note the "at least", meaning even if it were to work you could argue that the GUI is very optional
*mbakke wrestles with the mozjs 78 test suite
<mbakke>oh, I might need ICU 68
<mbakke>I'm getting an "off-by-1hr" error in many of the time zone tests, hmm
<gnutec>Hey guys! I'm here to say that xboard still doesn't work in my Guix System. I don't no why.
<janneke>bah, core-updates doesn't build glib
<jonsger>roptat: does JOSM work for you?
<mbakke>janneke: some glib tests are flaky, maybe you got unlucky?
<roptat>jonsger, it did, last time I used it
<brettgilio>MrtnDk[m] yep
<brettgilio>Whats up
<MrtnDk[m]>brettgilio Cool. Good to see you here!
<MrtnDk[m]><brettgilio "Whats up"> Matrix.el is getting better and better. There is a group for it on the Matrix.
<brettgilio>MrtnDk[m] who might I know you as on telegram?
<MrtnDk[m]>brettgilio Hope you were able to read that on the IRC side. I sometimes forget that reply doesn't work too well on the IRC side. 🤪
<dftxbs3e>nckx, how are you doing? :-)
<brettgilio>MrtnDk[m] who might I know you as on telegram?
<brettgilio>Trying to "put a face to a name" so to speak
<MrtnDk[m]>brettgilio Just sent you a dm on Telegram.
<brettgilio>Oh ha!
<brettgilio>MrtnDk[m] im glad the matrix.el project is getting more work. I am not overly fond of matrix, but im glad to see a non-electron client being made
<MrtnDk[m]>I like the idea of federated messaging, instead of having a single and Central point of authority.
<brettgilio>MrtnDk[m] freenode is neither single nor central. IRC standard for Internet Relay Chat. A Relay chat is inherently not centralized
<brettgilio>Stands for*
<MrtnDk[m]>There are other nonelectric clients out there too. I was somewhat getting involved with Ditto, but it turned out to be harder than expected to release it on F-Droid.
<profmakx>otherwise just use weechat with the matrix plugin ;)
<MrtnDk[m]>Exactly. IRC is a good example. However, Matrix has the advantage (and disadvantage, I guess), that everyone can potentially run their own homeserver.
<leoprikler>everyone can also potentially run their own IRC
<leoprikler>doesn't mean, that everyone has the right technical knowledge to do so, let alone the skill to moderate one, the time…
<euandreh>Shouldn't Artanis have dynamic load paths instead of hardcoded Guile 2.2 load paths? See
<euandreh>maybe by using (target-guile-effective-version)
<euandreh>I'm having issues running Artanis with Guile 3.0, and I think this is the reason why
<leoprikler>you'd need a guile3.0-artanis package for that
<leoprikler>but yeah, using target-guile-effective-version might make a build against 3.0 more easier
<euandreh>hmm, but why can't the existing artanis be built with both?
<leoprikler>"building with both" is not really a paradigm in Guix, be it Guile, Python or anything else
<euandreh>I don't quite get what you meant. I get that Python 2->3 was an incompatible change, but Guile 2->3 wasn't. Why is it not possible for this to be accomplished?
<euandreh>actually that's me interpreting Guile's major version upgrade as compatible
<euandreh>OK, "building with both" isn't really that reasonable
<leoprikler>Guile 2→3 did have some package-breaking changes (probably not as bad as Python, but still)
<euandreh>I'll make a patch for guile3.0-artanis and submit it, then :)
<euandreh>ty leoprikler
<leoprikler>Either way, Guix does not use the "shared" site and instead puts everything in site/EFFECTIVE_VERSION
<leoprikler>so guile3.0-artanis (which should be guile-artanis for consistent naming) would put its stuff in site/3.0 and if someone wanted to use guile 2.2, they'd install guile2.2-artanis, which puts its stuff in site/2.2
<euandreh>Using EFFECTIVE_VERSION as a variable on the package definition would make it easier for inheriting from the the existing artanis package, right?
<euandreh>so that I will create a guile3.0-artanis that inherits from artanis, and patch artanis to use EFFECTIVE_VERSION instead of 2.2
<euandreh>how does that sound?
<leoprikler>My personal instinct would be to update guile-artanis to make use of (target-guile-effective-version) as you suggested and then inherit guile2.2-artanis from that.
<leoprikler>That should in theory require less rewriting in the inheriting code.
<leoprikler>You may need to patch Artanis to be compatible with Guile 3, though, not sure about that.
<euandreh>ty again
<janneke>mbakke: ah, thanks --i'll retry
<guix-vits>i think that the manual missing documentation for packages with multiple outputs (5.4). how to use specific output?
<guix-vits>(packages (list `(,pack "out")) ...) ?
<guix-vits>about cli answer is simple.
<guix-vits>* ...))
<atw>just wanted to share something I found on bug 43610 (the icecat 78 segfaulting one): I searched for the minimal part of my profile to delete and found that I can delete just the line user_pref("network.captive-portal-service.enabled", true); from prefs.js to avoid the segfault. As rekado_ says in the thread, this is a workaround, not a fix, but hopefully this gets us closer! I'll email this result too :)
<leoprikler>guix-vits: depends on where
<leoprikler>cli is simple
<leoprikler>manifests: (list package output)
<leoprikler>inputs ("input" ,package "output")
<simonsouth>Anyone else seeing this? After pulling from master and rebuilding "./pre-inst-env guix" always fails with
<simonsouth>./pre-inst-env: 55: exec: guix: Permission denied
<simonsouth>Seems to be related to Ludovic's change on the 7th that modified the shebang line in scripts/guix.
<simonsouth>Now it looks for guile in the root of the source tree, but I don't see how that would ever work.
<simonsouth>Something else I'm missing?
<cbaines>simonsouth, I seem to have a guile executable at the root of the Guix Git repository, do you?
<simonsouth>cbaines: No. How does it get there, I wonder?
<cbaines>simonsouth, I'd suggest re-running the ./configure script and make
<cbaines>hopefully that'll make it appear
<simonsouth>cbaines: Well, I have done that several times already, run "make distclean" and started over.
<simonsouth>Not sure what else to do to start fresh.
<simonsouth>Oh, I wonder if this is related to configuring with "--disable-daemon". That is something I started doing recently.
<cbaines>If I run "make guile", then the file is created. What do you get if you try that?
<simonsouth>cbaines: Ah, that I have not been doing. Just ./bootstrap && ./configure --localstatedir=/var && make.
<simonsouth>Was that something added recently? Or have I been doing it wrong this entire time.
<cbaines>that part of the Makefile should happen by default
<cbaines>I just mentioned the specific target
<cbaines>Looking at the Makefile I have, it's next to bits to do with the daemon, so I'm guessing disabling the daemon might remove that bit of the Makefile
<simonsouth>Ah. Well I've reconfigured without "--disable-daemon" and am rebuilding now. If this fixes it that will reveal something.
<OriansJ>is there any particular reasons why guix doesn't do torrents for stable releases?
<simonsouth>OriansJ: I have wondered the same thing.
<simonsouth>OriansJ: I should mention, there is an unofficial torrent you'll find listed here:
<simonsouth>That's what I'm sharing now.
<simonsouth>cbaines: Removing "--disable-daemon" didn't cause the guile executable to be built, but running "make guile" explicitly did.
<cbaines>simonsouth, right, yeah, running ./configure would have just updated the Makefile
<cbaines>running just make should get the guile executable to appear as well
<simonsouth>cbaines: I ran make as well.
<OriansJ>simonsouth: it would also apply to the GNU Guix 1.2.0 Binary and GNU Guix 1.2.0 Source tarballs; which perhaps are the more important piece of the equation because one should in theory be able to build the ISO from the guix install config
<simonsouth>OriansJ: I agree. GNU doesn't seem to offer any of their software via BitTorrent. Not sure why.
<OriansJ>simonsouth: because of the GPLv2
<simonsouth>It would be an easy way for people to contribute, by helping offload some of their bandwidth.
<OriansJ>in theory the distribution requires source along with the binary
<OriansJ>and the GNU project is always strict in doing what is unquestionably correct.
<simonsouth>Strictly speaking, I believe it requires only that the source code be made available alongside it. Not necessarily the two be distributed together.
<cbaines>I don't think that's correct. The GPL supports a pattern where you write a letter to someone, and receive the source code on a CD
<OriansJ>cbaines: except everyone in the torrent are part of the distribution part; which is the problem with GPLv2
<OriansJ>hence the linking bit in GPLv3
<OriansJ>I believe RMS even touched on that point when expressing the benefits of GPLv3
<cbaines>OriansJ, sure, but you can meet the terms of the license by just including the information on where to get the source. At least that's my reading of section 3c in GPLv2
<simonsouth>cbaines: So "make" on its own doesn't build the guile executable, but "make guile" afterwards does. I may just have to remember to do that for now.
<cbaines>Anyway, this is offtopic, and it's probably not useful to speculate
<simonsouth>Not sure why it doesn't work as-is for me, but then I can _never_ get the documentation to build successfully on my machine. I wonder if these things are related; maybe the build has never completed fully and I just never really noticed.
<simonsouth>At any rate, thanks for the help.
<cbaines>simonsouth, are you sure? If I rm guile then run make, it's there again
<simonsouth>cbaines: For me, doing that causes make to try to build the documentation again, which fails after which make gives up.
<simonsouth>...with no guile executable created. So this really seems like it's the problem.
<cbaines>simonsouth, OK, what's the failure regarding the documentation?
<simonsouth>About 100 lines all along the lines of:
<simonsouth>doc/ @ref reference to nonexistent node `Formatting Code'
<simonsouth>Just endless "reference to nonexistent node" errors for each of the translations.
<cbaines>Those sound like warnings it's just printing out, but not an error that stops make from doing things
<cbaines>Is it clear if there's any error?
<cbaines>If not, perhaps just upload the whole output to a pastebin and share the link
<simonsouth>They do look like warnings. But then immediately afterwards:
<simonsouth>make[2]: *** [Makefile:4388: doc/] Error 1
<simonsouth>...and it quits. Nothing before that matches a search for "error".
<simonsouth>Let me see if I can post this somewhere...
<cbaines> is often usede
<simonsouth>Cool, thanks.
<simonsouth>Is there some trick to building the documentation, I wonder? Or a way to disable it?
<simonsouth>I don't recall ever seeing any instructions specific to it.
<cbaines>simonsouth, what commit are you on, and have you got any unstaged changes?
<simonsouth>cbaines: Commit 6a012dd1ddd02e3f99dddb4094a055e1407711e3, and no unstaged changes.
<cbaines>It seems to be failing on doc/, but make doc/ works for me locally
<simonsouth>Let me try a new, totally clean checkout and see if that changes anything...
<simonsouth>I should mention I'm using guix on top of another distribution. It's certainly possible something isn't set up correctly.
<lfam>cbaines: Does the Guix Data Service currently do anything with the staging branch?
<cbaines>lfam, I'm running for processing patches and branches, including staging:
<lfam>Ah, thanks
<cbaines>I'm also trying to build packages from the staging branch as well
<lfam>I'd like to finish this branch and merge it by next Friday
<cbaines>the recent innovation I was working on is this which lists packages which are building on master but not building on staging (given the limited data the Guix Data Service has)
<lfam>Thanks, that's pretty much exactly what we need
<cbaines>If you're looking to do a merge, I'll try and pull data from, and do some more of the staging builds
<lfam>Do you mean, if I want to merge master into staging?
<mbakke>I have a queue of 40-something patches that I intend to push to staging today
<lfam>I thought the plan was to freeze it 2 days ago :)
<lfam>Well, go ahead and get them in there :)
<lfam>I was wondering about your patches
<mbakke>I got busy with the ungrafting branch, and other things :P
<mbakke>I'll merge in ungrafting first
<mbakke>and try to shape up my queue..
<lfam>I think we should still aim to be done next weekend
<cbaines>I can get the Guix Data Service to query for builds for staging, so that the build information is more up to date
<lfam>Thanks cbaines
<cbaines>I think I'm still catching up from the last staging merge! Although I had some bugs in the Guix Build Coordinator which didn't help.
<lfam>mbakke: Please ping me after you push and I'll start testing here
<cbaines>simonsouth, any luck with make yet?
<simonsouth>cbaines: Yes, I believe so. Looks like the problem was that /bin/sh on my system pointed to dash rather than bash, which caused one of the early build steps that updates the documentation's PO files to fail.
<simonsouth>This failure "stuck" since the broken files wouldn't be updated again and wouldn't be removed by a "make distclean" or even a "git clean" without additional options.
<cbaines>simonsouth, OK, I'm not really sure what Guix should cope with as /bin/sh, maybe this is worth filing a bug about.
<simonsouth>After changing the /bin/sh symlink and starting a new build, everything seems to be going okay.
<simonsouth>Well, on this machine I'm hosting Guix on what I know is a rather broken Void "Linux" installation. It's probably safe to chalk it up to that.
<simonsouth>I.e., most people wouldn't run into this.
<cbaines>Yeah, but having /bin/sh be dash is quite a common thing I think, at least Ubuntu does that I thought
<simonsouth>Perhaps we should at least mention it somewhere then. Or Guix's install script could check for it, maybe.
<lfam>Dash is a Debian-family thing
<lfam>I seem to remember a bug report on this subject
<lfam>Maybe search the bug reports for 'dash' or 'dashism'
<simonsouth>lfam: Nothing obviously related comes up. I can file a bug on this though.
<simonsouth>lfam: Oh wait, this is it:
<simonsouth>cbaines: Yep, now the build completes without error and I do have guile in the top-level folder.
<simonsouth>cbaines: Thanks again for the help, really appreciate it.
<cbaines>That's good :)
<lfam>jsoo: Can you clarify what that rustfmt output patch does?
<mbakke>lfam: pushed! I have a half-finished KDE upgrade in the pipeline too, but it's small enough that it can go in after the deadline (and I can test all dependents without the CI).
<lfam>Thanks mbakke
<cbaines>staging on seems to be a bit weird. There's lots of scheduled builds, but the substitute availability is higher than that would suggest
<civodul>cbaines: heh, weirdness as usual :-) probably Cuirass "didn't notice" that those things we actually built
<vldn>hi, i try to add a custom package to my guix system config.scm .. steps i done:
<vldn>1. (add-to-load-path "/etc/guix/modules")
<vldn>1.1 (use-modules [....] (bin vldn))
<vldn>1.2. (packages (cons* python-autotiling)) added to config.scm
<vldn>2. run "guix import pypi -r autotiling >> /etc/guix/modules/bin/vldn.scm"
<vldn>3. edit vldn.scm and add to top
<vldn>3.1 (define-module (bin vldn)
<vldn> #:use-module [.....]
<vldn>4. guix reconfigure complains about missing "(use-module (bin vldn))" :(
<vldn>does someone see an obvious mistake?
<raghavgururajan>guix-vits leoprikler: Oh! So GNOME is starting the dring automatically?
<civodul>vldn: you need to run "guix system reconfigure -L /etc/guix/modules ..." so that guix knows where to find the (bin vldn) module
<vldn>i thought thats (add-to-load-path) for (see 1.)
<vldn>but it isn't working though
<vldn>how to add a local channel? (path "/etc/guix/modules/") instead of url .. in the channel definition doesn't work :D maybe a local channel works ^^
<mbakke>vldn: (shot in the dark): try removing the 'python-i3ipc' statement on line 30, perhaps guix stops parsing the module because it returns a package?
<vldn>tried already but thanks :)
<vldn>i added it because some sites suggest to add the package name add the end for guix package --from-file
<mbakke>vldn: does 'guix build -L /etc/guix/modules python-autotiling' work?
<mbakke>for 'guix build -f', 'guix environment -l', or 'guix package --install-from-file', a package needs to be returned by the file
<vldn>thank you, with the guix build command i was able to debug the package, after fixing an error with the generated license line it began to built but i have to fix a few errors further :)
<vldn>but now it's detected thank you :)
<vldn>with the unfixed license line my config.scm just ignored the package
<civodul>we're at 40% substitutes for x86_64 on 'ungrafting'
<PotentialUser-69>Has anyone succeeded in creating a package of a python program that uses the fbs build system?
<civodul>"-c 10" shows we're missing texlive-bin, mariadb, ghc, ocaml
<elais>Hello guix
<mbakke>civodul: btw, did you see ?
<lfam>Hi elais
<lfam>mbakke: I was thinking we should keep the patch
<mbakke>lfam: I think so too, so I guess "graft it in place"?
<lfam>mbakke: Yeah, since there is going to be a graft anyways, right?
<mbakke>yes, there is one for curl already on that branch
<civodul>mbakke: no, i hadn't seen it
<civodul>uh, no strong opinion!
<civodul>oh my bad, it's a patch of mine :-/
<civodul>mbakke: maybe it's safer to reinstate it?
<civodul>(in the ungrafted one)
<mbakke>maybe ... I doubt anything uses that at build-time, but who knows
<civodul>OTOH it's a regression: previous the curl --no-graft would honor those variables, now it doesn't
<lfam>But, using "--no-grafts" is not really a supported use case, righT?
<civodul>not a "recommended" use case i'd say
<civodul>bah i'm really sorry for messing up with this!
<civodul>ok so maybe like you were saying, we could just re-apply the patch to the new graft
<lfam>Origin patches are notoriously tricky :/
<civodul>with the understanding that we'll probably remove the patch eventually because upstream didn't want it
<civodul>lfam: yeah, shuffling code around makes it easy to miss something
<lfam>ISTR we kinda needed the patch, but now I don't recall the discussion in much detail
<mbakke>lfam: the alternative is patching every user of libcurl to handle those variables
<civodul>yeah that sucks
<lfam>Although upstream didn't take the patch, I think we could put a little more effort into explaining our use case to them.
<civodul>it's one of these things that makes no sense on an FHS distro because there's just one instance of the certificates
<lfam>I think there is a good chance they would make a change that would meet our needs, if we did explain ourselves carefully
<mbakke>on a related note, we can get rid of cmake-curl-certificates.patch, kodi-set-libcurl-ssl-parameters.patch, and libqalculate-3.8.0-libcurl-ssl-fix.patch
<civodul>heh :-)
<civodul>well, on master, but not on "ungrafting"...
<civodul>so what do we do, we just re-add the patch to the replacement?
<lfam>Relatedly, alsa-lib recently fix this problem for us. That's actually what prompted me to work on the staging branch
<mbakke>I don't have a strong opinion really, we may as well reinstate it and get rid of the new curl graft IMO
<mbakke>it will delay the branch a bit though, and by extension 'staging'
<guixy>hi guix! I got a new arm machine and want to set it up as an offload builder. I followed the instructions, but I keep getting an error when I try `guix offload test`.
<guixy>I have done it successfully with two x86-64 machines.
<mbakke>lz4 failed on all arcitectures on 'ungrafting', perhaps we should take 0fc9f34f1c4357b1152d5eb7e5b71702cf006165 too..
<guixy>It is a foreign distro if that helps diagnostics
<guixy>$ uname -a
<civodul>mbakke: yeah ok, let's fix it and take the new graft
<guixy>Linux raspberrypi 5.4.79-v7l+ #1373 SMP Mon Nov 23 13:27:40 GMT 2020 armv7l GNU/Linux
<civodul>mbakke: it's getting late, i can look at it tomorrow if nobody beats me :-)
<PotentialUser-69>Has anyone succeeded in creating a package of a python program that uses the fbs build system?
<mbakke>civodul: I can take care of it nowish :-)
<civodul>mbakke: alright, if you can, that's awesome :-)
<lfam>mbakke, civodul: We should aim to be done before xmas-time, IMO
<civodul>oh yes, i'd expect it to take less time
<civodul>we'll see how that goes
*civodul -> zZz
<civodul>good night/evening!
<lafrenierejm>Is anyone aware of a recipe for Linux 5.10-rc5?
<PotentialUser-69>The project that I'm trying to package ( uses the fbs build system ( for version 0.95 and consequently it doesn't provide the file for the python-build-system. What should I do?
<mbakke>PotentialUser-69: I think you'll need to package the build tool first, then add phases that make use of it
<lfam>lafrenierejm: I haven't seen one yet
<PotentialUser-69>mbakke: Ok. I will try that.