<bavier>oriansj: guix has a gtk+@3.24.10 package <oriansj>leoprikler: that is the error message provided by meld when the following commands are executed: guix package -i meld; export GIO_EXTRA_MODULES="...;export XDG_DATA_DIRS="...; meld <oriansj>bavier: is it really a requirement to manually install it? shouldn't it have been packaged with meld, such that this sort of failure doesn't occur? <oriansj>as I distinctly remember guix building gtk+ to just build meld <leoprikler>I'm pretty sure it's not actually GTK, which is the problem <bavier>yeah, there's something else going on <oriansj>bavier: well I am able to reproduce the issue with p3qfajwh360a3p6z73n9xfcrghrvlkrd-meld-3.20.1 on a virtual machine with only slim, dwm and urxvt as extras <bavier>oriansj: I think this is a python thing, pygobject isn't able to find a gtk module <oriansj>so an export to help it find it's way? <bavier>probably, but I don't see a pygtk package that support python3 or gtk+3 <bavier>might be something we need to add <dongcarl>that feeling when the build that you’ve been struggling with for days finally works..... ***ng0_ is now known as ng0
<leoprikler>but it appears, that even with that fixed it still segfaults <leoprikler>it fails somewhere during startup when initializing GSettings <leoprikler>I'd like to give more info, but debugging symbols... <dekaidle>nckx: I was able to successfully build dub manually per your advice. Everything working perfectly again now. Thanks for the help! Will probably get around to looking at dub and other dlang packages when I get more time, that ldc package needs an update anyway. <apteryx>nckx: and what commands must you run do exactly to re-activate your mouse? <apteryx>my kernel messages look exactly as yours when I plug a bluetooth keybord (with minor details) <apteryx>at the interactive bluetoothctl, the message "[CHG] Device 7C:D1:C3:B5:42:95 Connected: yes" was also printed upon re-powering up the bt keybord <apteryx>nckx: I'd suggest you try out with outher bluetooth devices to rule out any software/hardware issues with your system/controller combo. <apteryx>why do guix services take so much time to compile, compared to packages? is it because of the Guile optimization level is higher for non package files? ***jje_ is now known as jje
<g_bor>I have found that the #35586 issue page is blank on the issue tracker. <g_bor>Any idea what is going wrong there? <g_bor>it shows fine on debbugs by the way. <brendyyn>So I'm wondering how i can reply to an email on guix-devel when im not subscribed. If I just copy paste the Subject like and add Re: and sent it to guix-devel will it work? <leoprikler>brendyyn: just add guix-devel to Re: or CC:, yes <leoprikler>in your mail client "answer to group" should do the right thing <roptat>g_bor, I'm a bit worried that we won't have an intern for this outreachy round... <g_bor>roptat: yes, it looks like that's the way it is. <civodul>we had only one person chime in, right? <roptat>yes and they aren't very active... <g_bor>civodul: yes, an I also believe they are not active. <roptat>well, if it doesn't work for this round, I'm still willing to mentor next round <g_bor>I think this might be related to the Outreachy application procedure changes this round. <civodul>or to the "events" on our list and IRC channel... <g_bor>I will ask Sage to publish the next round timeline soonish, so that we can be better prepared. <g_bor>civodul: I don't know. I am unsure about the effect of those events... <g_bor>I believe this is a guile question, but is there a way to easily read back a record written to a file? I have a simple record, no addresses involved. <g_bor>It is written like this: #<<test-record> name: "a" value: 7> <g_bor>civodul: the main change on the Outreachy side was that the initial applications were due much earlier, and there was no real chance to apply once the project lists were available. <leoprikler>g_bor: not really, but you can try to use custom writers <g_bor>I have to go now, I'll be back later. <peanutbutterandc>I am on Linux Mint 19 and just installed guix on the host system with the installer script and after running guix pull and also installing the locale packages and exporting the required variables, I am still getting complaints of failed locale installations. Any help please? <civodul>raghavgururajan: you'd have to check whether you're eligible, but i believe there's still a bit of time to apply (roptat?) <brendyyn>I notice than every program, when run with strace will show many "No such file or directory" messages before it finally finding the right path for a .so file. Is it not possible with Guix's functional design to somehow embed the right path at build time so they are always found first at run time? <brendyyn>yeah i know its wellknown i just dont know much about it. theres also machine specific directories that are probably never used. i just thought it was interesting <leoprikler>it's probably possible to use a custom dynamic linker <leoprikler>however, you'd have to compile a new linker for each input set, which is probably not what you want to do <civodul>brendyyn: ELF binaries embed a search path ("RUNPATH"), and that's where .so files are searched for <peanutbutterandc>Solved the previous issue. However, I am still getting the following error from bash-minimal (not guix/guile): <civodul>of course, the longer the search path, the more ENOENTs <peanutbutterandc>substitute: /gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.utf8) <peanutbutterandc>substitute: /gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.utf8) <civodul>peanutbutterandc: this is coming from 'guix substitute', which is invoked by guix-daemon <civodul>plus "systemctl restart guix-daemon.service" ***ng0_ is now known as ng0
<g_bor>civodul: could you tell me what causes the nss-certs substitute failure, while it builds fine locally. What does guix do with the substitutes? <g_bor>I am not very familiar with that <g_bor>could we do something to make the substitutes local independent? <civodul>in short, make sure your daemon runs in a UTF-8 locale <g_bor>civodul: is the daemon running on an utf8 locale on Guix System by default? <g_bor>efraim: very good question... I was also wondering about it just yesterday... <efraim>the workaround is still in the code <efraim>it mentions gnutls-3.6.5, we're at 3.6.9 now <efraim>i feel like some bugs can be closed with "we've moved on, it's probably not an issue now" <g_bor>I have just closed some referring to hydra... <brendyyn>civodul: for some reason there is also a <a id="org98fddee"></a> in the page <g_bor>civodul: I've just seen you suggestion to add the current and previous locales to locale-libcs, and I believe that it would be a good idea. <g_bor>I came up with the same suggestion a few days ago at a place where Guix System is running in production. <efraim>I was thinking of hacking together some maths to make my locales current and current-1 (which I guess I could send to the cookbook) *efraim grumbles about a backlog of cookbook and blog posts and too little time <g_bor>efraim: I was thinking about introducing a variable, something like glibc-locales-previous, that is simply update alongside with glibc. <g_bor>I believe it would not be too much of a burden... <efraim>I think I'd still math it as (string-append (version-major (version glibc)) "." (- (version-minor (version glibc))) 1) so it doesn't get left behind <efraim>prepare the errors for glibc 3.0 ! <g_bor>efraim: I guess with a bit more conditionals, it could be solved :) <efraim>not sure it's worth the extra work for an eventual 3.0 :) <g_bor>I have to go now... have a nice day! <mbakke>efraim: I think TLSv1.3 is supported now -- at least I enabled it a couple of weeks back w/o problems. <mbakke>I intend to update the issue once I've verified that it works with the daemon, too. <roptat>raghavgururajan, if you're eligible for outreachy, you'll need to register a contribution before the 1st of november <roptat>you'll have to register on their website too <civodul>g_bor[m]: yeah, it sounds like we should do that every time we have a glibc upgrade <civodul>but perhaps it's still time to do it in master? <brendyyn>So we still have that thing where reconfiguring can result in the screen going black and requiring a forced reboot, like if the display manager is changed. i wonder if it would be nice to have a feature where when the system is reconfigured, the new configuration is only available on reboot <bdju>in that case have you tried changing TTYs? I used to have something that would kick me to my display manager, but then I could find my old session still running <brendyyn>ah maybe that was it, im not sure any more <bgardner>Good morning Guix! I have a stable server running guix and I'm exploring the possibility of migrating DNS services onto it. Knot sets up crazy fast but is authoritative, so I was looking at dnsmasq to provide resolver... but it looks like from the docs that there is no way to tell dnsmasq about knot (e.g. address/localdomain/ip.add.here). Any suggestions? <roptat>what do you mean, tell it about knot? <bgardner>roptat: Well, if you are running dnsmasq to resolve, you want knot to be asked about your zone, but upstream resolvers for regular queries. <bgardner>But the dnsmasq configuration doesn't have a provision for "address" or similar (that I saw) <bgardner>Hmm, unless (server) accepts /domain/ip.address entries? Let me try that. <nckx>brendyyn: If you're reading the Web archives and want to be really nice, you can include ‘In-Reply-To: <message ID>’ (including the <>) so you don't break threading. The message ID can be found by viewing the source (<input type="hidden" name="d" value="this">). Maybe I'm the only person crazy enough to do so. <nckx>(re: re:ing guix-devel.) <bgardner>roptat: Never mind, that totally works! So knot serves my private domain authoritatively on an alternate port (2053 in my case) and then dnsmasq has (servers '("/my.domain/127.0.0.1#2053" "1.1.1.1")) and it all Just Works(TM) <raghavgururajan>roptat Nvm, I just read outreachy.org. Anyway, I will not be able to do it this year as I will occupied with my work. I am eager to join for next year though. :-) <leoprikler>raghavgururajan: You mean the line "Approved applicants will make contributions to projects"? <raghavgururajan>leoprikler Oh shoot! I misinterpreted that a prospective participant must have contributed something to be eligilble to apply. <raghavgururajan>leoprikler roptat Seems like registration is closed. "The initial application period for the December 2019 to March 2020 round is closed." <raghavgururajan>"Applications for the May to August 2020 round will open on January 22.". Excited for this :-) <roptat>raghavgururajan, you need one commit in the guix repository :) <roptat>of course, you can contribute outside of outreachy, you just won't be paid for it :) <raghavgururajan>roptat Ah I see. Should not be a problem. I can do something before Jan 22. <dongcarl>If I wanted to add something to the CI pipeline... Where would I look? <civodul>dongcarl: to build a branch, you'd have to ask one of the people with access to ci.guix.gnu.org <civodul>which basically means the maintainers and a few other people <dongcarl>civodul: Oh what I mean is... I fixed `MAKE-GCC-TOOLCHAIN`, and would like to have that added to the normal CI pipeline <bavier>civodul: I saw the article posted also on lobste.rs <bavier>I don't usually comment on those platforms, and feel that my voice would probably be drowned out by the tidal wave of pessimists and naysayers. <bavier>e.g. the top comment on HN: "Sad to see Guix struggling" really? in response to a random blog post where the person barely tried and encountered problems more innocuous that I've seen elsewhere <leoprikler>Tag yourselves, I'm "my first guix pull took two weeks" <dongcarl>bavier: That top comment is probably the most positive you're gunna get on HN... <amz3>top comment means something on HN? <bavier>It seems I'm in a different world now, having run exclusively Guix for the last 5 years; I might be blind to most of these "issues" people bring up <civodul>dongcarl: ah! then you can add something to (gnu ci), or simply define a top-level package making use of make-gcc-toolchain <dongcarl>civodul: under %core-packages in (gnu ci)? <roptat>bavier, in fact most of us probably learned how to avoid issues with guix and know how to fix any issue, so we don't struggle as much as newcomers <civodul>bavier: i think the post raises valid issues, and the first answer is definitely an overstatement, but it's good if we can bring some balance to that <roptat>but this kind of posts means we still have some work to do to help every user :) <civodul>ideally we'd address the issues *and* let people know that no, the project is not "struggling" :-) *mbakke would like to have system tests for the various desktop environments <leoprikler>In a way, we *are* struggling with hardware, that requires blobs, though. <leoprikler>It's just not the kind of struggle, that "struggling" implies. <dongcarl>This might be a stupid idea, but I want some more coordinated effort in organizing all the various non-free guix channels out there... <dongcarl>Yeah, I understand that... Just thought it'd be nice if people joined forces somewhere like #guix-nonfree or something <roptat>I was thinking about using it (or a scheme implementation) to display lint warnings for instance :) <dongcarl>roptat: Oh that's cool... Looks like what rustc does <roptat>he reimplemented it in OCaml too <civodul>roptat: nice! i'd like to have something like that for Guile <roptat>basically, you can give it a set of ranges and associated message, and it displays them nicely <bavier>I've liked all the work gcc has done with such things recently <roptat>I also thought it would be nice to have a "guix system lint" or something <roptat>but maybe nicer error messages would already do the work <roptat>it doesn't detect pairs of things, it just displays ranges <roptat>so if you can programmatically detect the beginning and the end of it, yes :) <leoprikler>oh, so you do the whole pattern matching on your own? <civodul>roptat: what would "guix system lint" do? <roptat>I was thinking for instance about multiple definitions of a service, it would be nice to point to sources of these multiple services (like, one defined in the os, and one in %base-services for instance) <roptat>but it could be done with a better error message, too <civodul>ah yes, that's what should be done IMO <civodul>there are some messages that lack location info <roptat>and well, it'd be best to eliminate as much backtrace as possible and show friendlier error messages <roptat>oh, another question: how could you redefine a package globally, say I want to use my own variant of openssl in anything that's built by my os-configuration? <roptat>(I see it's used in tests, but I'm not sure what it does exactly :)) <sirmacik1>hey guix! anybody knows to which group I need to add my user so it has acces to modem via mmcli without sudo? <leoprikler>as far as I can see, mmcli belongs to network-manager, which uses polkit <leoprikler>and IIRC the default polkit setup under Guix is not that good <dongcarl>Anyone know how to `git format-patch` a "followup" patch to one I've already emailed? Basically wanna add a commit... <leoprikler>dongcarl, assuming all your patches are applied on a clean master in order, do `git format-patch origin/master` <leoprikler>your original patch will be overwritten with the same contents, then its 0002-... etc <leoprikler>I personally use this in my config.scm to get proper sudo prompts <civodul>there's no "good" solution to the problem you describe, though <civodul>currently invididual services offer a way to change their package, but that's about it <leoprikler>can we do something like package-input-rewriting for operating systems? <roptat>That wouldn't work for, say, the shepherd-service-type <civodul>there's a low-level 'map-derivation' that's never been used anywhere but that serves this purpose <roptat>It's not part of the os declaration <leoprikler>perhaps the shepherd service could be made explicit (as part of %base-services) ***ng0_ is now known as ng0
<dongcarl>Can manifest files read environment variables? e.g. `env FOO=bar guix environment --manifest=manifest-that-changes-based-on-foo.scm`? <bavier>dongcarl: I don't see why not, the file just needs to return a manifest object when it's evaluated <dongcarl>bavier: Yeah I tried it and it works... MUAHAHAHAHAHA <bluekeys>Hi guix, I noticed we don't have the dracula theme for emacs. Is it because it is MIT licensed? <leoprikler>it's probably because it hasn't been packaged yet <sirgazil>Shouldn't it be "environment variables" instead of "environmental"? <sirgazil>I'm still using python venv everywhere; I have to try Guix profiles then... <davexunit>but I'm not sure if the terminology differs for people depending on where they are from? <kolyad>Is there someway for me to update the Guix store in an iso installer? The profile system-1-link has the important install utilities, but it is out of date - notably with the cryptsetup util, which was updated to the newest version at the start of the month, at a version without support for LUKS2. <leoprikler>kolyad simply guix pull after starting the cow-store <bluekeys>I think im nearly there with the dracla theme. Will someone take a look for me? It downloaded the source but I havent managed to load it in emacs. I think it could be related to git shas which i have no idea how to figure from the helloworld example <leoprikler>(or be like me, set any hash and let the error message correct you) <leoprikler>by the way, is it really called dracla theme or dracula theme? <bluekeys>I'm waiting for the punch line... Did I do something silly? <leoprikler>bluekeys: you could simply have done `guix import elpa -a melpa dracula-theme` <leoprikler>it would set the license wrongly, but should otherwise work <bluekeys>Cool, the font really isn't that great but, I learnt plenty today. Thanks. <leoprikler>having dropped dark themes for adwaita, not really <bluekeys>Adwaita? Is that an emacs theme or gnome? <apteryx>bluekeys: arc-theme + custom stuff in .Xresources <leoprikler>an Emacs theme, that looks like GNOME, should come packaged <bluekeys>hmm, I'm using stumpwm. I'm gonna search melpa. Settling on a theme is like picking a function name <leoprikler>not quite -- picking a name affects everyone around you as well <bluekeys>Wait a minute, why does my dracula look soooo awful but the pictures on the site look clean? I think it must be font related. People, recommend me a font (please). <kirisime>I did a guix pull and now guix is nagging about $GUIX_LOCPATH. What are the implications for setting the variable as suggested for all my earlier installed packages? <leoprikler>kirisime: you shouldn't need it if you spawn a new shell <leoprikler>also, what font do you have on other systems in your Emacs? <bluekeys>nimbus mono. I think that's the default? I have no other emacs :( <kirisime>leoprikler: My system profile is still more than a month old and the variable points to /run/curent-system/locale <leoprikler>if not that, then pick one of the "optimized for code" ones <leoprikler>kirisime: you mean that will be a problem with the glibc change? <kirisime>Well, I don't know if it will be. I'd like to avoid having to upgrade all my packages and/or having to upgrade the system because both involve lots of compiling <kirisime>The system profile and my user profile now have different versions of locales though <leoprikler>yeah, you should update both when you have some spare time <roptat>kirisime, you can install more than one glibc-locales package <roptat>in your os declaration, so older profiles can be supported <kirisime>leoprikler: For official guix yes, there aren't any for my own local channel <nckx>Do ‘we’ have a preference for either yyyy-mm-dd or yyyymmdd versions when the project itself doesn't? <roptat>oh I thought your issue was that you profile was older, sorry :) <roptat>nckx, do you mean they officially have both versionning scheme, or is there no version number? <kirisime>What's the worst that can happen if my $GUIX_LOCPATH is set incorrectly then? <bricewge>Does someone worked on using `guile-semver` in a importer? <nckx>I mean that they're sloppy (it's neomutt, they've gone from 2018mmdd to 2019-mm-dd git tags). <roptat>nckx, I see yyyymmdd, yyyy-mm-dd and yyyy.mm.dd (which I like better) in the repo, without a clear winner <nckx>Welp, version>? stops at the first dash (making 2018mmdd > 2019-mm-dd) so I guess I'll have to munge. <nckx>roptat: I prefer dots too but introducing a third variant feels like trolling 😛 <roptat>bricewge, I'd like to try with an npm importer <roptat>I have some building blocks, and if I work on it, maybe I'll have a prototype this week-end <bluekeys>Ok, dracula looks good with fira code. Thanks guix <bricewge>roptat: Ho nice, does your work on it is public? <bricewge>I'm looking into improving the rust importer. <roptat>it's supposed to work even in the presence of dependency loops <roptat>a depends on b which depennds on a. Hopefully, when considering package name *and* version, there's no loop anymore <roptat>so it tries to use an already imported package if compatible, or the latest compatible version if it's a new package, or the oldest compatible version if the package is being imported or already exists in the distribution <roptat>and if it's blocked, it backtracks <bdju>looks like the clojure package is a minor version behind <nckx>bdju: I think I have an update for that… <nckx>(Unless you'd rather update it, of course — be my guest!) <dongcarl>Curious: if a patch fixes existing broken behaviour and you've tested it... What's the appropriate amount of time to wait for review until it's okay to push to master? <nckx>dongcarl: Rule of thumb is a week. <nckx>That said, if things can objectively only improve (e.g. a package didn't build before, now it does) and the breakage is annoying it might be OK to bend the rules. <bdju>nckx: any chance you've used clojure? I was just gonna try it out but I'm not sure how to get a repl. I'm getting "command not found" <bdju>someone is telling me this shouldn't be the case <nckx>bdju: IIRC the clojure package doesn't provide a ‘/bin/clojure’ wrapper that execs ‘java $clojure/share/…/clojure.jar’ for you. <nckx>So if you're just running ‘$ clojure’, that's what's (not) happening. <bdju>I do not like what I'm hearing <bdju>trying to wrap my head around this <nckx>Then you must change the reality. <bdju>it doesn't help that I never used clojure <bdju>java command is also not found. do I need openjre or something to use clojure? <nckx>bdju: It's simply that you have to ‘java $path_to_clojure/share/java/clojure.jar’ yourself, Guix creates no helper script for you. <bdju>shouldn't that be a dependency or something? <nckx>That's for a Java person to decide. <nckx>Also why I'm not interested in fixing the build failure: I just wanted to play around with the language, not the implementation. <bdju>I really think java should be a dep and you should be able to just run `clojure` out of the box. is that crazy? you can get racket or python working that easily <nckx>It's not crazy. I just don't know enough about Java to make that decision. I dunno, maybe there are multiple Java implementations, all equal, and people should be freeee to chooose. Or something. 🤷 <nckx>Plonking ‘/gnu/store/…/bin/java’ into a /bin/clojure wrapper would make it a dependency and is fine by me. <bdju>oh yeah, I guess any java would be fine. just so that it worked. <nckx>bdju: It's a reasonable bug report, hinty hint. <leoprikler>nckx: For the Java thing, one could use one as default (e.g. OpenJDK) and build other versions with package rewriters <leoprikler>it seems we only have multiple versions of openjdk and icedtea (which builds on openjdk) anyway <nckx>All I noticed was that ‘guix build openjdk’ started building openjdk, which implies it's not the version actually used to build closure. <nckx>I really don't care about Java. <nckx>There are people who do who are not on IRC, hence my suggestion. <leoprikler>IIUC Java is currently not a dependency of clojure at all, which is why `guix build openjdk` would build it <leoprikler>So the only java you do have built is one of icedtea-7 or icedtea-8, depending on which ant ant-build-system is using <roptat>also, it could be that you only have one output of openjdk <roptat>guix build openjdk would build all of them <leoprikler>btw. is there a way of doing `guix build` with substitutes? <leoprikler>(i.e. one quicker than `guix environment --ad-hoc ... ^D) <roptat>guix build uses substitutes by default <nckx>‘build’ doesn't mean ‘force local build’. <nckx>B-b-but I didn't *want* to learn about Java ☹ <nckx>g_bor[m]: Agreed & bugs merged.