*raghavgururajan is back on track <jonsger>raghavgururajan: you are in India, aren't you? <jonsger>for me in Germany it's around 3MB/s like usually... ***jonsger1 is now known as jonsger
<nckx>guix-vits: Congatulations on your first patch. <nckx>Hah, I only now saw your message about adding my name. No need (but thanks). I've no shortage of HTTP→S commits already. <nckx>git log --format=oneline --author=nckx | grep -c HTTPS <guix-vits>nckx: was 385 before another `pull` there; indeed: + 11. <nckx>Now it's 403. Damn, I should have made it 404. <guix-vits>i'm currently try to say "no" to proprietary machine translators. Looks like Wiktionary know not much about Persian, though. <guix-vits>"فایل"... is "file" ,Wiktionary to according ,ok <guix-vits>At lest TS formatted text well, so same words easy to spot :) <nckx>guix-vits: Watcha doin'? <guix-vits>i'm just try to understand an post; it mention a stardict and "Aryanpoor Persian to English Advanced Dictionary" (on "Ask Fedora") <guix-vits>looks like an instruction. I'm give up for today on this matter. <ArneBab_>Is there an ETA for full migration of Guix to Guile 3? <ArneBab_>I have both guile and guile-next, and that seems to cause load errors because ~/.guix-profile/etc/profile to contain GUILE_LOAD_COMPILED_PATH for both Guile 3 and Guile 2.2. <guix-vits>ArneBab_: did you're tried to pass --no-auto-compile to guile 2.2, as a workaround? <ArneBab_>guix-vits: no — can I do that when installing from Guix? <ArneBab_>guix-vits: it’s not that my programs don’t run: they just show lots of errors when I start them <ArneBab_>guix-vits: but thank you for your answer! <abralek>Hi, I amend a set of my patches and sent v2 to the bug-track. And now I see that my patches are failing here https://patchwork.cbaines.net, but It seems to me that it doesn't apply them as a set anymore. <abralek>Could someone explain me how it should be done properly? <guix-vits>ArneBab_: honestly, idk. I'm only have a feel, that it should be possible. But my most complex program is `(display x)` <guix-vits>abralek: if i click an entry in "Series" col.|| , new page is opened with the related patches. Maybe they just shown this way on this site? <abralek>guix-vits: Yes, but that is original series. First I sent 7 patches. Build went fine, but I had to do some work and split few of them into two <abralek>guix-vits: I did that and send two separated patches to one of those bugs I had to split <abralek>I thought a bundles should do the trick <janneke>oh...In procedure stat: No such file or directory: "sysdeps/mach/hurd/Makefile:" *janneke made another rebuild-wurld typo <abralek>guix-vits: Hmm it looks like submitter=166 is 'Vitaliy Shatrov Via Guix-patches via' <efraim>go inputs for go packages are what kind of inputs? <efraim>the Via Guix-patches was a mistake that some of the commits have <abralek>guix-vits: In other cases that is an only my email/name <guix-vits>abralek: what i think is common in our failures: "fatal: remote patches already exists." <abralek>It could if the system checks checks stdout/stderr on fatal errors. <abralek>But in my case I also see errors in git am steps <jboy>does anyone know why that is? <jboy>oh, is expat the mit license? <abralek>I fixed those trailing whitespaces but it is not that my patches are failing. In the related field I don't my other patches <abralek>Does patchwork relies on the merged header from debbugs? <guix-vits>abralek: thanks, cool link. if i'll arrange any more patches i'll send them as a new mail, not as a reply. <abralek>Well, I am still confused How should I send a v2 patch in a series in case I split it in to two commits <abralek>But I think debbugs is more important that patchwork. <civodul>abralek: to send a v2, you can do "git send-email --to=NNN@debbugs.gnu.org --in-reply-to=ID" <civodul>where NNN is the bug number and ID is the message-id of the previous discussion <abralek>civodul: Thank you, but that is exactly what I am doing <jboy>running `guix pull` I get: guix/ui.scm:1826:12: In procedure run-guix-command: error: sqlite-3.26.0: unbound variable <jboy>Any ideas what that may be about? <rekado_>jboy: can you tell us what ‘guix describe’ says? <rekado_>jboy: do you have GUIX_PACKAGE_PATH set or are you using any extra channels? <rekado_>guix-vits: this should have no impact on ‘guix pull’. <jboy>oh, I do have GUIX_PACKAGE_PATH set from some testing I was doing. let me unset and try again. <jboy>guix describe says guix f255a19 <jboy>ok, unsetting GUIX_PACKAGE_PATH fixed it. thanks rekado_! <rekado_>‘guix describe’ also says that GUIX_PACKAGE_PATH is set, which would have been the answer here :) <rekado_>you probably know this already, but I recommend switching to channels when possible. <rekado_>GUIX_PACKAGE_PATH is a neat hack when testing channels, but I advise against setting it permanently <rekado_>(I keep using it for a quicker turnaround when developing the guix-bimsb channel. But not for ‘production’ use.) <dongcarl>I've seen this syntax in the manual: (@ (gnu packages guile) guile-1.8) <dongcarl>Wondering if there's more documentation on "@" <dongcarl>for example: how would I import multiple modules? <rekado_>@ is an accessor when the module in question is not used <rekado_>it’s only for single variable access <rekado_>and the variable must be public in that module <rekado_>there’s also the naughty sibling ‘@@’ which gets you private variables in the module, but I’m not sure if this still works with Guile 3.0 <dongcarl>Does it work to return a procedure if it's public? <rekado_>it’s better to avoid use of @, in my opinion. <dongcarl>((@ (gnu packages commencement) make-gcc-toolchain) foo bar) <dongcarl>I'm just doing inline things in guix build -e <rekado_>as long as the module has a binding for make-gcc-toolchain this should work <dongcarl>no worries, this is good info already :-) <dongcarl>I wish the generated html docs had hash links that are easier to extract <dongcarl>anyway, always good to have a reference! <jboy>rekado_: Thanks. It's not something I have set permanently, just as I was developing a package that I'm now trying to create a patch for. <rekado_>jboy: for packages that should become part of Guix it may be more convenient to use ‘./pre-inst-env guix’ from a git checkout. <jboy>that's what I'm experimenting with right now <rekado_>I always found it to be a hassle to move packages from a GUIX_PACKAGE_PATH module to the git repository. <rekado_>let us know if you run into any problems with that. <jboy>I find the manual a little confusing since it suggests that `./pre-inst-env` and `etc/indent-code.el` are already present when you checkout the repository, but you actually have to run configure/make first <jstierhof>Hello everyone, stupid question regarding package definition. I try to build software which requires libx11 and the Intrinsics.h from libxt, however, they are not found by default and I can only specify --x-includes for one directory. Does anyone know how to deal with that? Thanks! <dongcarl>Anyone know why `gcc -v` has the "Configured with:" line blanked out? <rekado_>dongcarl: to prevent /gnu/store references from being retained. <rekado_>having the references appear in text would let the reference checker record them and increase the GCC package closure. <rekado_>we sometimes need to erase references like that to keep the closure size smaller. We did this in Icecat and in Perl. <rekado_>in both cases they recorded the environment in which they were configured which led to all sorts of items to be retained as part of the package closure even though they were not needed at runtime. <dongcarl>Anyone know an easy way to inspect what configure flags a package has? <rekado_>dongcarl: there’s only a verbose way, I’m afraid. <dongcarl>rekado_: if you point me in the right direction I'll walk it myself :-) <rekado_>using (and=> (memq #:configure-flags (package-arguments pkg)) cadr) or similar *dongcarl fires up the repl <rekado_>this takes the arguments of pkg, then searches for #:configure-flags and returns whatever follows it, if it exists. <rekado_>I think it would be nice to have convenience procedures for that sort of thing. <nckx>jstierhof: Tricky. If the sources use ‘#include <…>’ you can try adding multipile -I…s to CFLAGS. That should work. Other options are patching the source or (probably worse) creating a little union include/ directory in . <sneek>Welcome back nckx, you have 1 message! <dongcarl>Does anyone have tricks for using the repl effectively? I was quite surprised that neither Ctrl-P nor up-arrow works to get the last line <nckx>dongcarl: Do you have guile-readline installed? <guix-vits>/msg nckx (patches (search-patches "libxt-guix-search-paths.patch")))) <dongcarl>nckx: does `guix environment guix` do that? <dongcarl>ah... so `guix environment guix --ad-hoc guile-readline`? <nckx>No. Install it regularly, along with guile-colorized if you want. <dongcarl>`guix environment guix --ad-hoc guile-readline guile-colorized` <dongcarl>many thanks for improving my productivity leoprikler nckx ! <nckx>Using Guile without line editing is the hell. <leoprikler>We should probably make guile3 the default soon and use normal guix versioning stuff to end this. <rekado_>dongcarl: are you using Emacs and Geiser? <dongcarl>rekado_: I'm on spacemacs and they don't have a Guix layer yet :-/ *dongcarl regrets not having gone to "the perfect setup" session at Guix Days <nckx>It's highly unintuitive for folks that ‘Guix’ uses Guile 3.0 by default but ‘Guix’ doesn't. <civodul>it's transitory, but... transitions take time <dongcarl>Huh... `guix environment guix --ad-hoc guile-readline guile-colorized` doesn't work... I'm guessing because what nckx just mentioned? <nckx>guix-vits: No flood. No need to /msg me though 🙂 (How'd you even manage to not-do that without a leading space?) <dongcarl>cuz I'm doing ./pre-inst-env guix repl... <nckx>guix-vits: I don't understand the message though. What about X resource search patch? <nckx>I'm still on Guile 2 \o/ <guix-vits>nckx: it's about jstierhof's question; i'm wonder if the patch solves this issue? <nckx>civodul: How close do you think wip-guile3.0-packages is to merging? <dongcarl>rekado_: When I do that complicated thing to get the configure flag... I get what looks like an expression that needs to be evaluated? <dongcarl>(cons "--with-glibc-version=2.27" (map (lambda (flag) (if (string-prefix? "--with-glibc-version=" flag) (string-append "--with-glibc-version=2.27 " (substring flag 21)) flag)) (quasiquote ("--enable-plugin" "--enable-languages=c,c++" "--disable-multilib" "--with-system-zlib" "--disable-libstdcxx-pch" "--with-local-prefix=/no-gcc-local-prefix" <dongcarl>(unquote (string-append "--with-gxx-include-dir=" (assoc-ref %outputs "out") "/include/c++")) (unquote (let ((libc (assoc-ref %build-inputs "libc"))) (if libc (string-append "--with-native-system-header-dir=" libc "/include") "--without-headers"))))))) <dongcarl>I feel like I gotta eval or expand this somehow... <dongcarl>but perhaps it's evaluated at build time? *dongcarl needs to stop thinking out loud <nckx>guix-vits: No, that patch changes run-time behaviour of libXt, not where it installs headers. jstierhof problem is that the package expects all ‘X’ headers to be under 1 directory, which can't be fixed by a patch. A union package, yes, but that's probably overkill at this time. <nckx>civodul: …oh. Since you deleted it 15 minutes ago I hope ‘closer’. <rekado_>dongcarl: package-arguments returns data, not code. <rekado_>that’s because package arguments are quoted. <rekado_>they will be evaluated on the build side. <rekado_>you can’t get an evaluated list because it’s evaluated on the build side <rekado_>you can’t just eval it because it references things like %build-inputs <rekado_>and you don’t have access to that on the host side. <guix-vits>nckx: about "... /msg ... without a leading space?" also i have a strange thing in *shell* when using `guile` inside of emacs: it refuses to evaluate a code that contains copied newline (M-w, C-y). <leoprikler>If I were to add a package that is a perl script (specifically convmv), should I name it $package or perl-$package? <nckx>leoprikler: If it's mainly used at the command line, no perl-. If mainly a library, perl-. <leoprikler>and if it's the former, I also don't add it to perl.scm but rather somewhere else, right? <nckx>E.g. ‘rename’ is written entirely in Perl but that's just an implementation detail, everybody wants the command. <nothingmuch>(i named it python-compiledb but it's not meant to be used as a library) <nckx>nothingmuch: Sounds like the right thing to do. <nothingmuch>as far as submitting that, would it be appropriate to just send a --fixup commit to the ticket number? <nckx>nothingmuch: Fix it up locally and send a stand-alone ‘-v2’ patch to the bug number. <nothingmuch>nckx: there's 3 patches in 3 messages, since i comitted the deps separately, -v2 for the entire format-patch series or only the last one? <nckx>That's my opinion anyway. <nckx>It would be different if this were a 22-patch series and you were amending #17. Then things get annoying quickly. <nothingmuch>thanks for the advice, i didn't see much feedback on the various submissions i looked at so i have no clue how review/feedback cycle works in guix yet <nothingmuch>did i accidentally make a joke? from what i've noticed most stuff in the ML just got applied eventually <nothingmuch>and i know there's a backlog so i want to make reviewers/commiters' life easy as muc has i can <nckx>No, no. It's just that our review ‘process’ isn't… well, we don't quite have the luxury of ‘cycles’ or ‘procedures’. <nckx>Once in a long while a lone reviewer rides through town <nckx>the townspeople throw their patches at 'em *nckx should do some review. <jstierhof>nckx: Thanks, I think my problem is that ./configure is not at project root and I was just cding to the build dir. Still was wondering how this can be done in general <nckx>jstierhof: The problem is that there's no general answer, it depends on how the build system does things this (IMO silly) way and where exactly you can get your fingers inside to change it. <nckx>It's so common in SDL land that all SDL headers are in one tree that there's an ‘sdl-union’ procedure to do it. But that's overkill for a single package with a non-standard(?) configure script. <jstierhof>nckx: I see, will try to find a solution. Thanks anyway! <guix-vits>jstierhof: what about `(setenv "CPLUS_INCLUDE_PATH"`? (gnuzilla.scm) <nckx>jboy: Sweet congrats! I will review that, because I have some questions. <janneke>now /me also has what rekado_ had... /bin/sh: ((: 6 <many numbers> <dustyweb>sent my first guix patch in quite a few months :) <janneke>"someone" should rewrite the daemon in guile *janneke admires civodul for his amazing code reviews <rekado_>reepca: are you still working on the daemon rewrite in Guile? *janneke is looking at integrating phant0mas' clone/chroot thing for the hurd, trying to weigh it against a quick-and-dirty hack <janneke>why do i take-up big tasks and then get discouraged when it turns out that there is some extra work? <civodul>but really, you seem to be 90% there, and you've made us all hopeful :-) ***janneke_ is now known as janneke
<janneke>civodul: thanks ... i'm well aware that you didn't create the extra work; you're really helping a lot <janneke>i often find it diffucult when i feel that i have to switch to another problem; and it helps to just talk about that *rekado_ will try to work on mumi tonight <jonsger>civodul: can't say yet if your "fix" with guile 3.0.1 helps with libgc8 <lfam>Ah you are testing that package too <lfam>I'll leave you to it then <nckx>lfam: I wrote most of it, so an extra eye is more than welcome. <lfam>Honestly I wasn't feeling very motivated <lfam>I would just want to poke around to make sure the relaxed pygit2 version requirement will work okay <lfam>And check if there is upstream discussion since upstream should really be handling that <nckx>lfam: I'm already trying with libgit2 0.28, since it's closely tied to the version. <lfam>Does our manual still suggest adding Python 2 variants by default? <nckx>‘If it is compatible with both versions, we create two packages with the corresponding names.’ <lfam>Maybe it's time to stop recommending that <lfam>I haven't been doing it at least! <nckx>lfam: Yes. I haven't done it for many months. <lfam>I actually thought this was a conclusion of the discussion about how to handle the end of upstream Python 2 support but I'm not going to look it up <nckx>No, we definitely came to the same conclusion between the lines at least 😛 <lfam>I didn't know the manual is in multiple files now <lfam>Alright I'm writing the patch <bandali>nckx, yeah so i haven't used gandi-cli but it does seem to be not in great shape <bandali>based on the repo's issues and your comments <efraim>lfam: while you're at it... want to add a section about packaging go packages? <bandali>if anyone knows a domain registrar that doesn't force use of nonfree JS, or has a working CLI tool, i'd appreciate a hint <lfam>efraim: Hm... not really :) The current go-build-system is super-hacky considering the changes in upstream Go, and I'm not sure what the way forward is. <lfam>efraim: Some other Guix hackers have been paying attention to Go and they will have a better idea of what to do <nckx>bandali: Please let me know if they offer .gr, which is (for reasons unknown to me) ‘rare’. <lfam>I feel like the manual section on the go-build-system, and the code comments in the go-build-system, should be enough <bandali>nckx, ha. i used a .li for a while, that too is somewhat rare <bandali>iwantmyname seems to have .gr, but their entire site is js-based -_- <lfam>Weird there is no copyright on contributing.texi <nckx>‘Mr. Domain’ (the name you trust!) does too, for less than Gandi, and there doesn't *seem* to be any required JS… I'll have to look into their trustworthiness. <nckx>If your domaincoin (‘dominitis’) sounds like a disease, you can't be too artful a scammer. <nckx>jboy: So it only happens if you have a detached head. <nckx>Which is my ~/guix, 100% of the time 🤷 *nckx now building with pygit2/libgit2 0.28… <jonsger> https://www.inwx.de offers .gr (I have also one) but some of their JS files doesn't have license information. Don't know if thats a problem <jboy>bandali: I haven't used them in a while, but from what I recall moniker.com is simple enough to work with js disabled (at least it used to be) <nckx>lfam: Removing lpd8editor makes me wonder: how was it broken? <nckx>jonsger, bandali: TBH I've used Gandi's JS (under protest, and after opening a pointless ticket) since the CLI broke. But since renewal is coming up anyway I might as well aim higher. So thanks! <jboy>nevermind, I just searched for a domain with js enabled, that won't even work. <lfam>nckx: The test suite was failing. If you disabled the test suite the program itself did not work either, failing to detect the connected device <lfam>I think nobody else has been using it <nckx>lfam: OK, thanks. That you tested it with an actual device gives me all the confidence it was the right decision. <lfam>I don't know what I'm going to do now with my lpd8 but oh well <jackhill>lfam: efraim: I'm paying attention to go, and agree with lfam that is needs more figuring out. <jackhill>I don't have any ideas now though, I'll have to actually work on it, not just pay attention :) *nckx forgot that every package with ‘git’ in the name will have interminable test suites, let alone 3… <bandali>esp now that they're shutting down v4.gandi.net <nckx>bandali: It's already gone, unless you're ‘lucky’? <bandali>also, hadn't heard of neither mr. domain nor inws; will look into them <jonsger>tbh, I don't really care. We (guix) also have files without explicit license information (gnu/packages/patches/)... <bandali>i remember asking the fsf sysadmins about a replacement <bandali>gotta dig into my logs and see if i can find anything <nckx>Yeah, good point, what does the FSF use? <bandali>i'm holding out for names.sr.ht, but there's no telling when that'll be available <bandali>nckx, gandi, currently; not sure what next <bandali>i suggested them the gandi cli, but that seems to be defunct and not working with their new apis <nckx>Dang. Assuming the FSF already talked to them about interface freedom, I have little hope for my silly mail. <bandali>yeah, afaik they tried reaching out, but nothing came of it <bandali>one of the fsf sysadmins mentioned dnsimple <bandali>not as a definite alternative, as one of the things to look into <nckx>I only knew them as a hosted DNS provider (please don't outsource your DNS), I didn't know they offered registrar services until now. <vagrantc>janneke: did you ever make progress on your pinebookpro ? <bandali>but i don't have an account with them to test <bandali>also, fwiw, mrdomain gives me empty search result without librejs, and inwx's search doesn't even work; i'm greeted with "Please activate JavaScript in your Webbrowser." <bandali>nckx, btw, what's wrong with using something like dnsimple, dyn, freedns, or dns.he.net? <nckx>Oh, sorry. I didn't try searching (technically, I just care about transferring, and will have to use Gandi.js to do it anyway) but it's not a good sign. <mjw>yeah, I was recently going through domain updates and for all I needed some environment to run (proprietary) javascript just to renew my domains :{ <bandali>whoops, s/without librejs/with librejs/ <mjw>sadly even GNU software doesn't always work with librejs <janneke>vagrantc: no; after i bricked it i only got to exchange one non-informative email with pbp support <janneke>vagrantc: so sadly that's on hold for me atm <vagrantc>janneke: hopefully can carry the torch you started, then! <mjw>Was setting up mailman3 with hyperkitty. It is nice and the idea of using the archive as a forum is actually an interesting idea. All javascript used of course is Free Software. But it doesn't use any tags or source maps :{ <vagrantc>i've got it running ... wondering if the recent changes to guile-next allow guix pull to work again <janneke>i thought it was probably not a good time to go press things to hurry a new pbp out of china atm ;-) <janneke>i definately want to give it another go...but yeah, some working hardware would belp <janneke>and yes, if guix pull works that's really going to help *vagrantc is trying right now <bandali>NearlyFreeSpeech seems to be a possible option *janneke instruments the build daemon to learn about waitpid 999 <vagrantc>was guix pull on aarch64 hanging on building /gnu/store/...-guix-system.drv... ?? <vagrantc>because i was able to finish that much... <vagrantc>pull succeeded with commit: c03fc422b933c97da088bbcb76236b119f29587c <civodul>i feel bad for the big bump on the road but i'm much more confident now <civodul>it seems that we'll also be able to turn on JIT on ARMv7 <vagrantc>civodul: glad to see it fixed, bugs happen. <janneke>civodul: on the hurd, kill -KILL -1 as a regular user simply gives Operation not permitted (EPERM) <civodul>hurd/hurdkill.c seems to implement it, though <civodul>maybe it's __proc_getpgrppids that returns EPERM <civodul>or it's pid2task, but where does that come from? <civodul>maybe the 'kill' command does something more than just kill(2)? <janneke>hmm, i'll better write a small C program then; kill -1 should be doable <bandali>apteryx, hey, any news re that autoload-related emacs 27 issue? <bandali>sorry i've been *super* busy and haven't had a chance to look into it myself <rekado_>I wonder if maybe I should drop mumimu and switch to guile-xapian instead. <rekado_>for mumi we need a lot of information that is simply not available in the mails, such as bug status, severity, etc. <rekado_>I was only able to speed up ‘recent issues’ by using mumimu. <rekado_>can’t even speed up the search much, because important information is only available after a complex Debbugs query. <janneke> 89<--95(pid6905)->proc_getpgrppids_request (1) = 0 5292 <janneke>task80(pid6905)->gsync_wake (194556 0 0); <janneke>task80(pid6905)->gsync_wake (194556 0 0); <janneke> 89<--95(pid6905)->proc_pid2task_request (5292) = 0x40000001 (Operation not permitted) <rekado_>does the process need to have a right on the control port of the target process to do that? <Blackbeard>Packaging for guix has been the only thing to help me keep my mind distracted and not anxious <Blackbeard>So.. thanks everyone for helping me and making guix awesome :) <janneke>eh...? also, i'm wondering what 5292 is; if it's a PID, then something is wrong: <civodul>janneke: ah it comes from 'kill' in sysdeps/mach/hurd/kill.c <janneke>- 5292 - So 0:00.00 /hurd/storeio -Tzero <janneke>it looks like "storeio" has no UID; could that be a problem... <civodul>that means proc_getpgrppids returns too many things <civodul>rekado_: xapian looks like a good match for mumi <rekado_>modifying mu is annoying. Lots of C code. <rekado_>but I really also need to store ‘bugs’. <rekado_>so I guess I could do all of that directly with xapian, but from the convenience of Guile <jboy>nckx: thanks for the comments tobias. I'll keep all that in mind for my next contribution. <civodul>good night and/or happy hacking! :-) <nothingmuch>nckx: well, got more feedback just in time, with good reasons to redo the whole thing ;-) <nothingmuch>(i added python2 variants for the deps because cargo cult) <seepel>Hi there, I've been looking through the docs and I have a question about the vpn client service. If I have a .ovpn file, is there an easy way for me to configure a client using it? <janneke>well, that was fun; kill -KILL -1 is broken on the hurd <alextee[m]>anyone knows how to maintain sudo status in a makefile? <alextee[m]>i'm running some sudo this sudo that inside a target, but it takes a long time to complete so it keeps asking for a pw :-) <lfam>alextee[m]: Check `man sudo.conf` for how to increase the timeout <lfam>Or even `man sudo` but you'll probably want to change the config <vagrantc>looks like pinebook-pro .dts patches are likely to be in linux 5.7.x <alextee[m]>hmm i'd need a guix service for this i guess to put the file in /etc/sudo.conf