***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 setup.py 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>It references setup.py but I don't see a setup.py 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 ayab_devel_launch.py file doesn't seem to be present either, so maybe these docs are outdated <guix-vits>ryanprior: maybe some script generates the setup.py? <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>"Removing unused python setup files", it removes setup.py, setup.cfg, and MANIFEST.in <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>Ugh, I just don't get it. Why would installing an emacs package install python? <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…? <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 :) <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? <spudpnds>Also, I feel a little bit guilty of hitting ci.guix.gnu.org for what seem to be the same files over and over again. <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 <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. <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. <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 ***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 <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 <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 ... <ryanprior>I used erc for years and I don't know how you'd send a message containing everybody's names X.X <pie_>ryanprior: i think ive seen it happen before <kaiwulf>I was wondering wtf I was being tagged lol ***chrislck_ is now known as chrislck
<guix-vits>> This package provides the Jami client for the GNOME desktop. <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]><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 #freenode_#guix:matrix.org *midnight backs into 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'? <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 <OriansJ>db48x: actually you have to choice the non-user friendly route to even do that <kisaja[m]>good to know, seems i forgot guix isn't alpha lol <guix-vits>OriansJ: change comment from sysadmin to devops. cause guix. <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? <OriansJ>guix-vits: if you wanted to see a joke, checkout cc_x86.M1 specifically when dealing with C's break statements <fonz>How can I create a manifest file for the current generation? I didn't find it in the manual. <leoprikler>not sure what exactly they mean, but `guix describe --format=channels`? <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>You can extract that via `(profile-manifest "/path/to/profile")` <fonz>leoprikler: That sounds what's I'm looking for. But profile-manifest doesn't exist in the documentation at http://guix.gnu.org/manual/en/guix.html. And it fails here: $ echo "(profile-manifest \"$HOME/.guix-profile\")" | guix repl <fonz>leoprikler: that's why I piped it into the repl. wrong? <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 <ngz>leoprikler: doesn't glib-or-gtk-wrap take care of this? <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 <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>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 <mbakke>janneke: some glib tests are flaky, maybe you got unlucky? <roptat>jonsger, it did, last time I used it <MrtnDk[m]><brettgilio "Whats up"> Matrix.el is getting better and better. There is a group for it on the Matrix. <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. 🤪 <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 <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>doesn't mean, that everyone has the right technical knowledge to do so, let alone the skill to moderate one, the time… <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>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 :) <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 <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. <guix-vits>i think that the manual missing documentation for packages with multiple outputs (5.4). how to use specific output? <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 :) <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. <cbaines>simonsouth, I seem to have a guile executable at the root of the Guix Git repository, do you? <cbaines>simonsouth, I'd suggest re-running the ./configure script and make <simonsouth>cbaines: Well, I have done that several times already, run "make distclean" and started over. <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>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 <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. <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>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. <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>doc/contributing.de.texi:1197: @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>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/guix.de.info] Error 1 <simonsouth>...and it quits. Nothing before that matches a search for "error". <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/guix.de.info, but make doc/guix.de.info 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>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 <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 ci.guix.gnu.org, 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 <lfam>I think we should still aim to be done next weekend <cbaines>I can get the Guix Data Service to query for ci.guix.gnu.org builds for staging, so that the build information is more up to date <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 <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. <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>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. <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). <cbaines>staging on ci.guix.gnu.org 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>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' <civodul>"-c 10" shows we're missing texlive-bin, mariadb, ghc, ocaml <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: maybe it's safer to reinstate it? <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 <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>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 <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 :-) <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 <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