<kitzman>how is the procedure to merge my own channel into guix's upstream? <kitzman>ah i guess i just have to submit a patch. <kitzman>i guess for maintenance i'll do the same <stryan>I had a question about the go importer; one of the dependendencies of the package I'm importing has a new major verison that exists as a subfolder in it's repo <stryan>This is causing problems since it gets extracted to the the wrong folder during the build step, and setting the #unpack-path doesn't seem to fix it. Is this something wrong with the package definition, or maybe something in the go module? <apteryx>perhaps it'd need 'go modules' support? <stryan>hmm, makes sense. though pragmatically the files just need to copied up a level (into package/ instead of package/v3). I'm not sure how to do that yet though; still puzzling my way through <apteryx>dragestil: i don't know of anyone in the process of packaging it; you may be interested in the jami-service-type though; it supports hosting conferences rather well, although participants will need a jami client instead of a browser <wehlutyk[m]>I just submitted my first patchset (51222), after having twice made a mistake in the intro email which comes before the patches ([PATCH 0/n]) <wehlutyk[m]>I see other such intro emails look pretty standard, as they always include a summary of the commits. Is there an automated way of generating this? <apteryx>wehlutyk[m]: git-send-email piggy-backs on git format-patch; so you probably want to read 'man git-format-patch' to learn more tricks. <apteryx>I think what you were after is '--cover-letter' <apteryx>wehlutyk[m]: congrats and thank you for your submission :-) <apteryx>sneek: later tell civodul I have a local branch with the amassed commits for the big rebuild, ready to push to core-updates-frozen; I have a few more tests I'd like to conduct before pushing it. ***modula is now known as defaultxr
<massn00b[m]>hello! Ive been making pbp images thanks to your patch. Thanks! <massn00b[m]>haven't quite figured out how to get my ath9k dongle working with it but otherwise it's been trying stuff on it <mothacehe>massn00b[m]: isn't (firwmare ath9k-htc-firwmare) working? <vivien>Hello! While compiling blender on my machine, I had an idea: it would be cool if guix could monitor how much memory is used, and kill a build and retry it with fewer cores if it uses too much memory. <massn00b[m]><mothacehe> "massn00b: isn't (firwmare ath9k..." <- I've tried adding it to the firmware part of the os declaration, I've enabled desktop services (for usb-modeswitch) and it builds ok but the firmware doesn't load when I plug the adapter in. dmesg just says I've plugged a USB device in <dragestil>how do people use tramp on remote guix system? i'm getting problems with finding a proper `ls` or `env` because guix does not follow fhs <vivien>dragestil, you need to configure your tramp-remote-path to include "/run/current-system/profile/bin" "/run/current-system/profile/sbin" <dragestil>vivien: do i need to configure (explicit)-shell-file-name also <vivien>Well, I can’t help much there :) <vivien>Anyway, the tramp situation is sorry because if you add random stufff to your tramp-remote-path, you risk connecting to a non-guix server where a malicious user has put malicious coreutils in /run/current-system/profile. To fix it, getconf should return something useful, which is not the case in Guix System. <dragestil>vivien: that's why i use connection-lcaol-set-profile :) <Soheil[m]>Need configuration to compress file/directory in Guix System? After compression, the size does not change! Even in ultra mode!! <vivien>I didn’t know about that function. <dragestil>i started a new emacs instance but it still doesn't work <dragestil>or you mean cached in the guix system (not emacs)? <vivien>Do the coreutils exist in /run/current-system/profile on the server anyway? <dragestil>yeah, if i ssh into guix in a terminal the $PATH is correct <vivien>It’s like if you do ssh host command, not echo command | ssh host <Soheil[m]>Does Guix System need configuration to compress file/directory? After compression, the size does not change! Even in ultra mode!! <vivien>In tramp, no rc file is sourced, so PATH is not set <dhruvin>Soheil[m]: what file/directory are you trying to compress? <vivien>It is set by first trying getconf, or uname -sr, and then try your customized path <dragestil>it's weird, because part of the profile variables (the shell file name) worked but part didn't (the remote path) <vivien>I don’t fully understand why different things work in ssh host command, pasting command in ssh host, and the tramp session <dragestil> (tramp-remote-path . ("/run/current-system/profile/bin" "/run/current-system/profile/sbin")))) <vivien>I have this in tram-remote-path: '(tramp-default-remote-path "/bin" "/usr/bin" "/sbin" "/usr/sbin" "/usr/local/bin" "/usr/local/sbin" "/local/bin" "/local/freeware/bin" "/local/gnu/bin" "/usr/freeware/bin" "/usr/pkg/bin" "/usr/contrib/bin" "/opt/bin" "/opt/sbin" "/opt/local/bin" "/run/current-system/profile/bin" "/run/current-system/profile/sbin")) <dragestil>the (explicit)-shell-file-name worked, but not tramp-remote-path <dragestil>hmm ok, i guess i can set it globally, but then it has the security problem you mentioned <dragestil>well, in guix the poor /bin only has one binary, sh <dhruvin>Soheil[m]: how are you compressing a file? command? <dragestil>20:56:08.921062 tramp-get-connection-property (7) # remote-path (/bin /usr/bin) <Soheil[m]>dhruvin: I used different GUI and command ways <dragestil>i guess that means it can't find getconf either <dhruvin>Soheil[m]: I think this is unrelated to guix system. It'd be helpful if you can share the exact command you're running. <dragestil>so the question is how do i get getconf in guix <vivien>getconf is not a program, it’s a built-in command <vivien>Ok so getconf is from gcc-toolchain <dragestil>oh dear, to connect by tramp i have to install gcc-toolchain, typical guix... <vivien>I don’t have it installed on the server but on my machine it returns /bin:/usr/bin <vivien>If you do, you’ll have "/bin:/usr/bin", so it won’t be of any help <vivien>getconf returrns /bin:/usr/bin on guix system <dragestil>> On remote hosts which do not offer the getconf command (like cygwin), the value "/bin:/usr/bin" is used instead. <vivien>You could maybe fake it though, having a script that returns the right thing <dragestil>i wonder why the value of tramp-default-remote-path gets overridden by getconf output <dragestil>actually that sounds like a bug (getconf PATH returns /bin and /usr/bin) <vivien>Yeah, but it’s so deep in the dependencies that you can’t tweak it without having to rebuild the whole system <vivien>I don’t know, but that’s a good question. <vivien>dragestil, I guess the correct thing would be to have a getconf-path-service-type that takes a profile, and create a /bin/getconf script that advertises the path for this pofile, so you could have a different set of programs than /run/current-system/profile/bin <dragestil>sgtm, though i don't know guix well enough to know whether this is the right solution <vivien>Nothing is the right solution when getconf is involved ^^ <vivien>I’ll try to have an extra special file /bin/getconf that returns the correct path, and see how that works, but not right now <dhruvin>Soheil[m]: I don't use 7z, can't help there. FWIW, I tried gzipping a file on my system and it did get compressed. <Inline>how do you get rid of tags which aren't existent anymore ? <Soheil[m]>dhruvin: Please send a command that compresses with ultra mode so that I can try it too <nckx>Soheil[m]: Pinging random people is rude, as is asking a question I've already answered (no, this has nothing to do with Guix). Please share the output of ‘7z a -t7z Archive.7z -m0=lzma2 -mx=9 -aoa‘, for example. <Soheil[m]>In my opinion, this is completely related to Guix! And the output is successful, but without any change in size!!! nckx <nckx>In my opinion, this behaviour is why nobody will help you. <nckx>Please take me off your ‘people who helped me in the past’ ping list. <nckx>The output of the command would be valuable here. <nckx>7z on Guix System just compressed 1.3G to 353M. The problem is on your end, not Guix's. <Soheil[m]>nckx, I want to know the same!!!! Do I need to do anything to make my system work like yours? <nckx>7z a -t7z Archive.7z -m0=lzma2 -mx=9 -aoa <nckx>will include any already existing previous Archive.7z in the new Archive.7z? <nckx>Soheil[m]: No, I configured nothing. I strongly suspect you're simply misinterpreting how 7z is supposed to work or which file needs to be compared to what. <nckx>Maybe someone else is willing to help you. But please don't bother anyone by name who hasn't volunteered. Good luck. <nckx>(Since you continue to refuse to share the command output — the one thing that could bolster or falsify your claim that nothing happens — I've already drawn my own conclusions.) <attila_lendvai>my guix pull is compiling ghc-8.8.4 locally. i assume this is due to the fact that the substitute servers haven't finished compiling... gut how can i be sure? maybe it's something i have changed locally? (i have several pending changes not yet merged into master) <dhruvin>attila_lendvai: have you tried guix weather? <dhruvin>I use something like: guix weather -m <manifest.scm> to see if/what I'll be compiling locally. <massn00b[m]><attila_lendvai> "my guix pull is compiling ghc-8...." <- can guix weather ghc do that? <attila_lendvai>dhruvin, massn00b[m], thank you! according to guix weather, ghc doesn't seem to be available on the servers (unless i changed something locally, but looking at my commits it's doubtfull) <dhruvin>attila_lendvai: you're right, I just checked, ghc-8.10 is available, and ghc-8.8 is not. <attila_lendvai>how can i find out what requires ghc-8.8? my only guess is: guix refresh --list-transitive idris@1.3.3, but it lists several ghc versions, including 8.10.x <cbaines>bordeaux.guix.gnu.org should have a substitute for ghc@8.8 <dhruvin>attila_lendvai: guix refresh --list-dependent <package>, does something along the lines. But I suspect if it'll be helpful in your case. <dhruvin>cbaines: it is available from bordeaux server. I overlooked. <nckx>attila_lendvai: <how can i find out what> (Very) quick and (very) dirty and (very) slow way: for p in $(guix package -I | cut -f1-2 | sed -E 's/[[:space:]]+/@/'); do guix graph --path $p ghc@8.8; done 2>/dev/null <apteryx>hmm, where can I learn about glibc's implemented character classes? <nckx>Yeah, I was going to point you towards ‘(glibc)Regular Expressions’ via ‘man regex’ too. <nckx>Don't quite get “'info glibc' leaves me uneducated” though. <roptat>on my system (fedora) "info glibc" gives me something that looks like a short man page <roptat>but "info libc" gives me "The GNU C Library Reference Manual" <qyliss>info will fall back to displaying man pages if no info pages are available <roptat>question to OCaml programmers: is there any use for ocaml4.07-merlin anymore, since we have ocaml-merlin too? <roptat>can I assume ocaml-merlin provides services for ocaml 4.07? I'd like to remove some ocaml4.07-* packages (all of them if possible :p) <attila_lendvai>(the local ghc built failed with an unexpected test failure, T16992) <attila_lendvai>nckx, that comes back empty. thanks anyway! i saved it in my notes. <attila_lendvai>nckx, what's more, if i remove the stderr redirect, and the version sepcification for ghc, i still don't see what requires ghc from among my installed packages. but i need to go now, will investigate later. thanks for the help! <apteryx>nckx: I meant uneducated w.r.t. to what are the character classes <apteryx>but since it's "just" standard ERE, I guess that's deferred to another manual <nckx>roptat: You're right, I meant (libc) on Guix System also. <nckx>Heh, diffoscope does depend on everything… <apteryx>roptat: oh, I get the same, I meant 'info libc' then :-) <apteryx>nckx: if I visit that 'Regular Expressions' node, and search e.g. for ':space:', I do not see any result <nckx>They are not part of the class name. <nckx>So have fun searching for ‘space’ yeah I know ☹ Better try ‘alnum’ or so. <attila_lendvai>negative: i have uninstalled diffoscope, but guix package -u still starts to build ghc-8.8.4 <apteryx>nckx: thanks, so the character classes are listed as 'wide character types' under '4.3 Character class determination for wide characters' <civodul>roptat: i think should you send patches that remove them, wait for a week or so, and then push <sneek>Welcome back civodul, you have 1 message! <sneek>civodul, apteryx says: I have a local branch with the amassed commits for the big rebuild, ready to push to core-updates-frozen; I have a few more tests I'd like to conduct before pushing it. <civodul>apteryx: if you want, you can push them to a separate temporary branch first? <apteryx>civodul: I don't mind to push a temp branch if people would like to inspect it before it gets pushed to core-updates-frozen <apteryx>has anyone ever seen this: Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS <apteryx>I get this upon: ./pre-inst-env guix build glade on my branch <bdju>anyone built ghc lately? I started updates last night and they're still going. looks like it's building ghc. it says it's at 100%, but I wonder if it's stuck. I didn't get to see it at an earlier percentage to know how long it's been. <apteryx>civodul: I created the branch as core-updates-frozen-batched-changes <apteryx>it includes the staging branch merge, the core bug fixes, the things marked for core-updates-frozen on the patch tracker, as well as a few additions <roptat>mh, I'm trying to use conditions in the opam importer, but I keep getting error messages <roptat>error: name: invalid field specifier. The correct format would be `(name field-value)' <roptat>on the line that says (raise (condition (&opam-not-found-error (package name)))) <roptat>and if I rename the field to "name" instead of "package" (and update the raise line), I get Wrong type to apply: "abcdefghi" <roptat>(when abcdefghi is the name of the package I try to import) <roptat>(it doesn't exist, the goal was to test the raise code) <roptat>and in a guix repl, I can define that, but I get "Wrong type (expecting exact integer): #<&opam-not-found-error name: "abcd">" on the raise <roptat>also, should I use srfi-35 (looks like it's the one used by other guile modules) or (rnrs conditions)? what's the difference? <apteryx>civodul: seems there's a package cycle w.r.t. to glade on that batched-changes branch; that's what was causing my earlier error <nckx>add-installed-pythonpath is so shockingly stateful I had to double-check 😃 <nckx>I guess that's a good reaction to have. *nckx piles onto the ‘thanks for spoiling me, Guix’ pile. <raiguy>are there any electron applications on the gnu repo? <nckx>raiguy: No. Nor electron itself. It is very hard to build, and we're nowhere close to trying. <nckx>So uhm, help welcome, I mean. <vivien>roptat, guix is full of mysteries, but indeed it’s clearer. <roptat>the patch looks ok, but I don't know much about gnome stuff <apteryx>nckx: 'nowhere close to trying'; haha <podiki[m]>hooray for that world rebuild (when it does get done)! looking forward to getting to a new release <apteryx>the world rebuild seems to be happenning only locally so far... hehe *apteryx wishes mothacehe was hanging around :-) <PurpleSym>The CI did not handle that git update in commit ab3a59453eb3bff9cf330d9301122efeec81d05c well :/ Almost 3000 failures. <apteryx>that's a lot of impacted packages for master <apteryx>nckx: oops, seems dfa2e5b44bb026a7dcbc29134b6831d611e41b86 forgot to add the actual patch file <nckx>Should be fixed already? <nckx>(But thanks for pinging me!) <apteryx>I thought I ran 'git pull' in the last 20 minutes or so; guess I didn't. <nckx>I fixed it only a few ago. <apteryx>PurpleSym: are these failures 'new' failures though? or simply refreshed (probably already existing) ones? <PurpleSym>(Which is to be expected when a high-profile package like git fails to build.) <civodul>apteryx: ah, so you managed to fix the cycle you mentioned? <civodul>roptat: re conditions, you should use srfi-35 (we don't use (rnrs ...) modules in Guix, with one exception) <apteryx>civodul: not sure it was a cycle, I should retry glad soon; currently building the rust toolchain <roptat>civodul, ok, that's what I did, but I got the errors I posted before <nckx>PurpleSym: Interesting, thanks. <apteryx>PurpleSym: the log is useless (derivation); do you know a way to get the actual one? <nckx>Oh, it's the cannot build missing derivation bug. <nckx>Nought to do with gitself. <nckx>Has that been discussed somewhere? <civodul>roptat: could it be that 'package' is bound to something else locally? <apteryx>civodul: where is this work happening though? I expected to see at least one job busy on the head node (berlin), but didn't see that <roptat>civodul, name is, but not package <roptat>when I use package, the error message gives me the line number where it's defined ***tricon_ is now known as tricon
<nckx>/gnu/store/djz9fan7f6cz6z8i424cav01bhpzhaag-git-2.33.1.drv exists on berlin. <nckx>PurpleSym: I restarted the ‘build’ and it ‘succeeded’. <rekado_>something’s not right with PDF fonts <nckx>Informally, but I don't know if it has a #. <civodul>apteryx: seems to be PID 16111 on berlin :-) <rekado_>I’ve got a PDF with forms and when I edit the form inputs the text is not displayed. <civodul>from a quick look at "sudo guix processes" <rekado_>evince and qpdfview only differ in the amount of errors they print <rekado_>I’m now using chromium to view and edit the PDF :-/ <civodul>roptat: could you paste the whole file? *civodul has too much sun here, can hardly read, will have to move to a different place <apteryx>civodul: thanks. How can you tell? I don't see any metadata in 'guix processes' output that'd allow me guessing <roptat>civodul, er, sorry it's not the right file <apteryx>civodule re "(we don't use (rnrs ...) modules in Guix, with one exception)" what is the exception? I've been using 'assert' from (rnrs base) in tests. <nckx>I thought civodul meant (rnrs bytevectors) but now I see we also import (rnrs io ports) a good few times. <nckx>And that's ignoring several (almost-)one-offs. <roptat>ok, condition was already defined, and that caused issues <roptat>now, I get srfi/srfi-35.scm:74:13: In procedure make-condition: unknown field package <roptat>at (make-condition #<record-type &opam-not-found-error> . _) (from the backtrace) <roptat>Soheil[m], we need to see what's in /var/log/guix/drvs/cq/fdg3mnkazdsnyncwxvzkvjn9090hdj-guix-package-cache.drv.bz2 <roptat>ok, I didn't define the condition type correctly, now I can create it, but raise tells me it expects an integer instead... <roptat>Wrong type (expecting exact integer): #<&opam-not-found-error package: "abcdefghi"> <roptat>Soheil[m], what are you updating the guix channel to? what's in your ~/.config/guix/channels.scm? <roptat>1e631e46698289a7182b79e106507ad749f9ee55 is not on master, which branch is it? <viivien>Soheil[m], are you trying to pull core-updates-frozen with the nonguix repo? You can discuss it at #nonguix on this server, but the repo is not ready yet to switch to core-updates-frozen <roptat>finally found it: I needed raise from srfi-34, not the default one ***lukedashjr is now known as luke-jr
<apteryx>so the core-updates-frozen-batched-changes evaluation failed with: cannot build derivation `/gnu/store/g0fwxandd7livpxjrdq5agxnbnc26xdn-avahi-0.8.drv': 1 dependencies couldn't be built <apteryx>a util-linux test failed: lsns: ownership and hierarchy ... FAILED (lsns/ioctl_ns) <roptat>ok, I think I got it working, the opam importer now raises a condition, and I managed to catch it in the updater and in the importer, to either warn or error out, depending on which one catches the condition <apteryx>sneek: later tell civodul the cycle is introduced by the commit getting rid of inkscape@0.92 (b3fea8c277) <apteryx>yeah, inscape -> gtk+ -> json-glib -> gtk-doc -> dblatex -> inkscape <Noisytoot>Why does Guix package such an old version of font-google-noto (20171025)? <vagrantc>Noisytoot: most plausible reasons is nobody has bothered to update it <vagrantc>how many innovations in the latest font are there? :) <vagrantc>other plausible explanations are licensing issues with newer versions... <Noisytoot>What are the licensing issues with newer versions? <vagrantc>i said that was a plausible explanation, i didn't say it was an issue <vagrantc>when asking "why is X out of date" those are some typical reasons <vagrantc>Noisytoot: maybe consider updating it and submitting a patch? <Noisytoot>yggdrasil is also out-of-date and incompatible with the latest version (most of the network), but that has a patch that doesn't apply on the lastest yggdrasil <vagrantc>didn't know yggdrasil was still updated... <vagrantc>according to wikipedia, the last release (1995) predates google <roptat>Noisytoot, do you know where I can download the latest noto version? <roptat>it looks like google wants me to download each file separately instead of a big archive <apteryx>sneek: later tell civodul there's another one: inkscape -> glib -> gtk-doc -> dblatex -> inkscape <vagrantc>honsetly, having them split into separate packages wouldn't be a terrible thing <vagrantc>i seem to recall it was a pretty huge package <roptat>that would make ~220 packages though <apteryx>sneek: later tell civodul rather through gtk+ -> colord -> gtk-doc ... <vagrantc>although that doesn't exactly seem to be true, as the version in debian doesn't match any of those <roptat>it redirects to the same repository <vagrantc>sure, still seems debian pulled an arbitrary version :) <vagrantc>Noisytoot: so, another answer to your question may be it's a bit unclear exactly what to download to update them <roptat>then, what does debian currently uses? <civodul>apteryx: hey! so... package cycles? how can it be? <sneek>Welcome back civodul, you have 3 messages! <sneek>civodul, apteryx says: the cycle is introduced by the commit getting rid of inkscape@0.92 (b3fea8c277) <sneek>civodul, apteryx says: there's another one: inkscape -> glib -> gtk-doc -> dblatex -> inkscape <sneek>civodul, apteryx says: rather through gtk+ -> colord -> gtk-doc ... <civodul>hmm, should we keep inkscape@0 after all? <civodul>for /gnu/store/cb3qjx2xfjyciqpbglkala6cp316ldww-util-linux-2.37.1.drv <nckx>Noisytoot: Just out of curiosity, did you try openemoji at all? <paxton>i'm suddenly having some trouble building emacs packages when the input is emacs-next and branch is git-master. has this happened to anyone else? i wonder if emacs upstream changed something about the dump file, but haven't looked too closely yet https://paste.debian.net/hidden/44990840/ <paxton>they all seem to fail similarly; that's emacs-xelb above <nckx>I wasn't following closely but… do we now need to keep a *bootstrap Inkscape*? Madness. <apteryx>civodul: yep, the test problematic test is now disabled globally <apteryx>I fixed the cycle between gtk+ <-> inkscape locally too, testing <vagrantc>roptat: i would guess a dump from git on a particular date... <apteryx>I'm just introducing a couple 'minimal' variants of GTK+ (3) inputs to break the cycle <apteryx>for json-glib, colord, libcloudproviders and gusb <nckx>When a Python package requires ‘python-foo[bar]’ I assume bar is some kind of feature I must enable in python-foo, but what's the typical way to do that? <apteryx>civodul: I'll push them shortly to the core-updates-frozen-batched-changes (what a mouthful), along the last changes I'd like to see for that core-updates-frozen branch (a phase/profile-hook to generate the gdk-pixbuf loaders cache file + search path), I'll ping you when I do <apteryx>nckx: I think it's usually selected via pip <apteryx>as a user, so you can determine what feature set you want installed <apteryx>not sure at the packaging level; I'd guess if the dependencies are present they get used <apteryx>civodul: I've pushed the commits untangling the gtk <-> inkscape mess <civodul>is the profile hook somewhere already? <civodul>note, you can squeeze the inkscape patches together, it's fine to rebase on that branch <civodul>FWIW, the horizon in my view is to get rid of hooks because there's a source of slowness