IRC channel logs


back to list of logs

<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
<dragestil>what is the status of packaging jitsi
<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?
<stryan>build log at
<apteryx>perhaps it'd need 'go modules' support?
<apteryx>we don't have such support yet
<apteryx>(in the go-build-system)
<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
<dragestil>apteryx: ok thanks
<wehlutyk[m]>o/ guix
<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?
<wehlutyk[m]>I couldn't find anything in git-send-email
<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 :-)
<wehlutyk[m]>apteryx: thanks!
<wehlutyk[m]>--cover-letter looks like it yes :)
<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
<mothacehe>hey guix!
<massn00b[m]>hello! Ive been making pbp images thanks to your patch. Thanks!
<mothacehe>massn00b[m]: great to hear :)
<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
<massn00b[m]>* it's been fun trying stuff
<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
<dragestil>tramp as in the emacs package
<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>No, /bin/sh exists
<dragestil>hmm my default is /bin/bash
<vivien>Well, I can’t help much there :)
<dragestil>i managed to get a shell, but still no ls
<vivien>Maybe restart emacs
<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!!
<Soheil[m]>I had never seen such a thing!
<vivien>I didn’t know about that function.
<dragestil>i started a new emacs instance but it still doesn't work
<dragestil>remote path does not get into $PATH
<vivien>Maybe the path is cached?
<dragestil>doubt it
<dragestil>or you mean cached in the guix system (not emacs)?
<vivien>No no, in 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
<dragestil>and ls works
<vivien>But that’s not how tramp works
<vivien>It does not open a session
<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!!
<Soheil[m]>I had never seen such a thing!
<Soheil[m]>Any help?
<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
<Soheil[m]>dhruvin: anything 😕
<dragestil> 'guix-bash
<dragestil> '((explicit-shell-file-name . "/bin/sh")
<dragestil> (shell-file-name . "/bin/sh")
<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
<vivien>But try to add /bin
<dragestil>well, in guix the poor /bin only has one binary, sh
<dhruvin>Soheil[m]: how are you compressing a file? command?
<dragestil>i took a look at tramp debug log
<dragestil>20:56:08.921062 tramp-get-connection-property (7) # remote-path (/bin /usr/bin)
<dragestil>it resolved remote-path to only these two
<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
<dragestil>builtin in what? bash?
<dragestil>it's not in my guix system
<dragestil>i can't find getconf in bash info manual
<vivien>That’s very weird
<vivien>Ok so getconf is from gcc-toolchain
<vivien>And it is a program
<dragestil>it's from glibc
<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>No no
<vivien>It’s useless
<vivien>Don’t do it
<vivien>If you do, you’ll have "/bin:/usr/bin", so it won’t be of any help
<dragestil>no it's the other way around
<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.
<dragestil>ah, i see
<vivien>You could maybe fake it though, having a script that returns the right thing
<Soheil[m]>dhruvin: XZ_OPT=-9 tar cJf Archive.tar.xz 'Archive'... (full message at
<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
<dragestil>makes sense
<dragestil>how does nix handle it?
<vivien>I don’t know, but that’s a good question.
<Soheil[m]>Anyone can help me?
<Soheil[m]>roptat, Please help me 😅
<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
<Soheil[m]>nckx, civodul, cbaines
<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.
<dragestil>vivien: that's a good idea
<Inline>how do you get rid of tags which aren't existent anymore ?
<dragestil>i'll try it too later
<Inline>like zile-on-guile or some such
<Soheil[m]>dhruvin: Please send a command that compresses with ultra mode so that I can try it too
<cbaines>Soheil[m], why have you pinged me?
<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.
<Soheil[m]>dhruvin, ?
<dhruvin>Soheil[m]: man gzip
<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>You do realise that
<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.
<Soheil[m]>nckx, OK. Thanks...
<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)
<singpolyma>Why does a guix pull need ghc at all??
<attila_lendvai>oh, sorry, i mean guix package -u, *after* a pull.
<dhruvin>attila_lendvai: have you tried guix weather?
*attila_lendvai looks
<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>* --display-missing
<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> 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
<nckx>(I'm sorry.)
<apteryx>hmm, where can I learn about glibc's implemented character classes?
<apteryx>'info glibc' leaves me uneducated
<apteryx>possibly this set:
<nckx>Yeah, I was going to point you towards ‘(glibc)Regular Expressions’ via ‘man regex’ too.
<roptat>hi guix!
<nckx>Don't quite get “'info glibc' leaves me uneducated” though.
<nckx>Hi roptat.
<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>oh I see
<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
<attila_lendvai>oh, i found it by a gut feeling: it's diffoscope
<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 :-)
<attila_lendvai>nckx, but why does it require an older version?
<attila_lendvai>the package definition looks innocent
<apteryx>nckx: if I visit that 'Regular Expressions' node, and search e.g. for ':space:', I do not see any result
<nckx>No ::s.
<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: yay, sounds great!
<civodul>apteryx: if you want, you can push them to a separate temporary branch first?
<civodul>dunno if that would help
<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
<roptat>civodul, makes sense
<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>and just added it to the CI
<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
<nckx>This is all very coincidental:
<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?
<roptat>guix modules*
<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
*apteryx digs
<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>Hello guix, I had some trouble with deja-dup (the GNOME backup tool), and I think I fixed it with a patch series:
<roptat>vivien, hint: it's slightly easier to read on :)
<vivien>roptat, guix is full of mysteries, but indeed it’s clearer.
<vivien>(thank you for the hint)
<roptat>the patch looks ok, but I don't know much about gnome stuff
<apteryx>nckx: 'nowhere close to trying'; haha
<apteryx>how long does it usually take before the CI starts crunching a new revision? that one's been in progress for like 40 minutes, apparently still in the process of starting it:
<apteryx>(and most workers are idling)
<apteryx>perhaps the CI is hung?
<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>I see :-)
<apteryx>thanks for the heads up
<apteryx>PurpleSym: are these failures 'new' failures though? or simply refreshed (probably already existing) ones?
<PurpleSym>apteryx: A few new ones like this one: But most of them failed due to missing dependencies.
<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?
<civodul>apteryx: re, keep in mind that the performing the evaluation involves building guix itself, the way "guix pull" would
<nckx>Oh, it's the cannot build missing derivation bug.
<civodul>so it's gonna take a long time
<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’.
<apteryx>nckx: is this bug reported?
<rekado_>something’s not right with PDF fonts
<nckx>Informally, but I don't know if it has a #.
<nckx>Hence my question.
<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.
<nckx>So yeah, not sure.
<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)
<PurpleSym>nckx: Thanks for restarting.
<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...
<drakonis>new branch?
<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)
<apteryx>disabled globally and repushed
<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>well done!
<apteryx>sneek: later tell civodul the cycle is introduced by the commit getting rid of inkscape@0.92 (b3fea8c277)
<sneek>Got it.
<apteryx>I think through dblatex/gtk-doc
<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>the addition of "🦙"
<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
<vagrantc>ah, not the linux distribution :)
<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
<sneek>Got it.
<Noisytoot>roptat, maybe
<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>yeah, 736 MiB of substitute...
<roptat>that would make ~220 packages though
<vagrantc>debian gets the source from:
<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>ah, had missed the first message
<civodul>hmm, should we keep inkscape@0 after all?
<civodul>apteryx: BTW, evaluation failed due to an util-linux test failure:
<civodul>for /gnu/store/cb3qjx2xfjyciqpbglkala6cp316ldww-util-linux-2.37.1.drv
<nckx>Noisytoot: Just out of curiosity, did you try openemoji at all?
<nckx>(I didn't.)
<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
<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
<apteryx>it was a bit involved
<vagrantc>roptat: i would guess a dump from git on a particular date...
<apteryx>nckx: nope
<civodul>apteryx: awesome, that was fast!
<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> has been 'in progress' for 3 hours; perhaps the cycle is killing it
<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
<Noisytoot>nckx, I didn't either
<apteryx>civodul: I've pushed the commits untangling the gtk <-> inkscape mess
<civodul>apteryx: alright!
<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