IRC channel logs


back to list of logs

<g_bor>rekado,lfam: thanks for the trust. I will make sure to read those. I already have a savannah account, and I have already uploaded my key, I will send an e-mail now. I did not ask for push access before it seemed unnecessary at the time.
<lfam>soundtoxin: Did you rebuild the font cache with `fc-cache -f`? See <> for more info
<soundtoxin>lfam: That did the trick, thanks! I installed it ages ago, and kept meaning to go back and figure out what the problem was.
<lfam>Great :)
<lfam>Wow, already has the new Git package built. I am impressed!
<Guest34672>I finishwith guix pull now I reconfigure my system and I will informed you.
<g_bor>I need some sleep now, bye!
<Guest34672>rekoda ty for the help it's right !
<Guest34672>a other question how I can put slim in keyboard french ?
<Rukako>hi guix!
<Guest34672>hi !
***robmyers_ is now known as robmyers
***Sleep_Walker is now known as Guest25977
<jsoo>How do i set keybindings in the linux console a la vconsole.conf in systemd?
<nckx>jsoo: No idea what vconsole.conf is, but most key bindings are handled by the shell.
<nckx>Or did you mean keyboard layout?
<nckx>Hm. The manual uses both ‘keyboard layout’ and ‘keymap’ in different sections. Users searching for ‘layout’ will never find the console-keymap-service documentation.
<jsoo>ahh, good catch, thank you
<jsoo>much better than the scattered conf file approach. cool, thanks nckx
<nckx>jsoo in-the-logs: Happy to've been of assistance!
<rekado_>ACTION built gnome with core-updates yesterday
<nckx>ACTION can't build anything in this weather.
<rekado_>it stays surprisingly cool indoors
<nckx>Expect only Perl and Python updates from me this week :-p
<efraim>We're unseasonably cool at 26 today, last week we were in the mid 30s
<efraim>single board computers are generally good in any weather I've found, they just don't like direct sunlight
<nckx>Passively cooled 'uns? Interesting. I probably would have guessed otherwise.
<efraim>Armbian's monitoring at ssh login says they run quite hot but they keep on running
<nckx>The only ‘board’ I have is a Pi a friend gave to me a year or two ago. Around the time I went full Guix. It has been sitting in a drawer unused.
<nckx>I vaccilate between guilt about not using it and potential guilt about doing so.
<nckx>Then there's the RISC-V ‘board’ I'm qemulating on x86-64.
<nckx>I guess what I'm saying is: sorry for my contribution to the climate :-/
<rekado_>I think it would be useful to have a dconf service that takes an alist of key/value pairs.
<efraim>rekado_: my internets are back! Overdrive2 should be reachable again once the dynamic DNS updates
<jonsger>rekado_: are there "make check" failures on core-updates for you to?
<rekado_>jonsger: yes, I see four failures with “make check”
<rekado_>tests/derivations.scm tests/graph.scm tests/pack.scm tests/
<jonsger>I see 3 :) derivations.scm works here
<civodul>rekado_: that's on core-updates?
<rekado_>I know why pack fails
<civodul>for tests/ there's an open bug
<rekado_>I introduced a bug with the change from #:tar –> #:archiver
<rekado_>will fix this momentarily
<rekado_>parts of are outdated on core-updates
<rekado_>python@2 is no longer named “python” but “python2”.
<rekado_>so it won’t conflict with the “python” package.
<rekado_>hmm, I tried replacing this with samtools@0 and samtools, but it does not abort with a conflict warning as it should.
<soundtoxin> got this error during an earlier update, it's been a few hours so not sure if it's still relevant
<civodul>rekado_: re python2, we need to find another example of a collision then :-)
<civodul>do we have one?
<rekado_>civodul: well samtools@0 should collide with samtools, but there is no warning on core-updates.
<civodul>ah hmm
<rekado_>soundtoxin: I saw a bug report about pyqt being broken at the moment.
<rekado_>soundtoxin: people are working on fixing it.
<soundtoxin>alright, cool
<civodul>rekado_: that's because they have the same name
<civodul>so it's not a collision: one overrides the other
<civodul>the original example had: -i python@2 python-wrapper
<civodul>where python-wrapper propagates python@3
<rekado_>argh, icedtea@2 fails to build on core-updates :(
<rekado_>sorry, icedtea@1
<rekado_>“internal compiler error: Segmentation fault”
<rekado_>doesn’t sound good.
<rekado_>I’ll try a different compiler version.
***Guest25977 is now known as Sleep_Walker
<rekado_>same with gcc-7 :(
<civodul>does it break the whole Java chain?
<rekado_>I’m trying with 4.9 now
<rekado_>4.9 seems to work better, but I’ll wait until icedtea@3 has been built before pushing this.
<rekado_>oddly, it also misses a dependency now (libnsl)
<civodul>libnsl has this: "This library was part of glibc < 2.26, but is now distributed separately."
<civodul>we were already past 2.26 though
<rekado_>hmm, the build still fails even when libnsl is added.
<rekado_>oh, don’t mind me: I added it to the wrong version of icedtea.
<efraim>I don't need the test-tmp folder in the guix repo, right?
<rekado_>you shouldn’t need to keep it.
<rekado_>another build failure on core-updates: emacs-emms
<rekado_>says: “gzip: emms-print-metadata.1: warning: file timestamp out of range for gzip format”
<jonsger>would it be possible to make the binaries in gnu/packages/bootstrap/ position independent (-fPIE)?
<rekado_>maybe. Is it a problem that they are not?
<jonsger>not a huge problem, but for our opensuse package we got often in submit request the feedback to make them position independent
<rekado_>I see.
<rekado_>If this is done it would have to wait for the next core-updates cycle.
<jonsger>it's not urgent
<rekado_>icedtea-1 builds now, but the compiler segfaults in icedtea-2.
<rekado_>will switch to gcc-4.9 there as well.
<rekado_>is it normal that with the latest Emacs I need to move all (define-key *-mode-map …) expressions into mode hooks?
<snape>my ido-enter-magit-status binding doesn't work anymore, maybe it's the same issue
<efraim>Would that involve rebuilding all the bootstrap binaries?
<jonsger>efraim: compiling them with -fPIE?
<roptat>hi guix!
<rekado_>hello roptat!
<roptat>one of my coworkers suggested we could use a tag system to refer to similarly-named packages or whose name is different than the upstream one
<g_bor[m]>Hello guix!
<roptat>for instance, the upstream name of the z3 smt solver is z3-solver, but our package is z3
<roptat>the idea would be to be able to install z3 with "guix package -i smt/z3-solver" for instance
<roptat>or "guix package -i ocaml/p4" to install camlp4
<efraim>We can add aliases like with 'pinentry'
<roptat>let me see
<roptat>that's not exactly the idea
<roptat>the idea is that we could select the correct one with say "qt/pinentry"
<roptat>the example is a bit silly because the package is called pinentry-qt
<roptat>but it could be usefull if we have a bunch of similarly named packages with different purposes
<civodul>roptat: in the end, would it be more than just a different naming convention?
<roptat>yes: it's about selecting a subset of potential packages and looking for one that corresponds
<roptat>so installing "pinentry" will result in guix telling you there are multiple packages, while "pinentry-qt" and "qt/pinentry" would be the same
<civodul>oh, i see
<roptat>"qt/pinentry" would mean any package whose name is like "pinentry" tagged with "qt"
<roptat>and names could be the guix name, upstream-name if there is a property for that or other things
<civodul>so we could have several packages with the same name, but with different tags, right?
<roptat>we could keep distinct names internally
<civodul>it sounds interesting, but maybe also overengineered? :-)
<roptat>but have the same aliases for different packages
<roptat>maybe :)
<IntoxicatedHippo>Hi Guix!
<IntoxicatedHippo>Is there a way to use options with modules in the initrd?
<civodul>IntoxicatedHippo: no, but perhaps you can achieve what you want through 'kernel-arguments'?
<civodul>if not, could you provide an example?
<IntoxicatedHippo>I'm trying to set up vfio-pci as described here:
<g_bor>Hello guix!
<civodul>heya g_bor!
<civodul>IntoxicatedHippo: i see
<civodul>you don't need vfio-pci in the initrd though, do you?
<civodul>or maybe you do actually, i'm confused
<civodul>anyway short answer is: not supported at the moment, but you can report it to
<rekado_>the glibc package that we use to build glibc-locales is broken on core-updates.
<rekado_>patch doesn’t apply
<civodul>i can look into it
<civodul>ACTION was into guix pull NG™
<rekado_>no no no
<rekado_>didn’t mean to pull you out of guix pull NG™
<civodul>ah :-)
<rekado_>unless you need a diversion
<civodul>i'll see if i can do something useful with glibc-locales in a reasonable amount of time :-)
<rekado_>heh, okay
<civodul>rekado_: done!
<civodul>that was easy ;-)
<rekado_>I’ll continue updating my profile then
<civodul>the pyqt issue is problematic
<rekado_>I just told a user to pull the version before the Qt update :-/
<rekado_>(which isn’t great because they won’t get the git fix this way)
<rekado_>with the exception of two packages (both affected by the Qt upgrade) my profile has been updated to core-updates.
<civodul>yesterday, on v0.14.0-5793-g9ab0627ee, berlin had 22% of substitutes and hydra had 74%
<civodul>for x86_64
<civodul>(at some point we should investigate why berlin has fewer substitutes but that's another story)
<vagrantc>ACTION ponders what it would take for a "copy kernel, initrd and bootloader to /boot" functionality
<civodul>vagrantc: i suppose 'guix system' would need to take care of this
<civodul>is it really needed though? (honest question)
<civodul>i remember NixOS had such an option back in the day but it wasn't clear to me why one would want to do that
<vagrantc>on some of the arm boards, the only boot media available may not be where you want /gnu/store
<vagrantc>or, almost certainly isn't
<vagrantc>e.g. boot from microSD, /gnu/store on SATA, USB-SATA, etc.
<vagrantc>ACTION is noticing due to a rash of really flaky microSD cards failing after doing "guix system reconfigure" more than a trivial number of times
<vagrantc>e.g. more than 3
<civodul>oh, i see
<civodul>i suppose we could add a --copy option to 'guix system', something like that
<vagrantc>might also allow /gnu/store on raid or something if the bootloader doesn't support it
<vagrantc>grub is more capable these days, and can support a lot of those use-cases out-of-the-box ... but u-boot less so
<rekado_>upon logging out of EXWM and logging in again I got a segfault in some login process.
<rekado_>but it’s fine after a reboot into the new core-updates system
<vagrantc>civodul: worthy of a wishlist bug
<vagrantc>civodul: for the copy to /boot stuff?
<vagrantc>ACTION might reduce the impact by having /tmp and/or / on separate media from /gnu/store
<rekado_>ACTION will try core-updates on RHEL 6 tonight
<rekado_>that was quick. Seems to work fine on RHEL 6.
<pkill9>oops wrong chat
<civodul>vagrantc: worth a wishlist bug, yes
<civodul>rekado_: cool! we're making progress :-)
<jonsger>icecat also succeeds on core-updates, I'm impressed :)
<bavier`>hello guix
<lfam>Is there a typical way that packages are failing as a result of the Qt 5.11 upgrade? I'm trying to get Krita building again
<civodul>hey lfam
<lfam>Hey civodul!
<civodul>lfam: dunno, i've seen a couple of Qt-related fixes
<civodul>by Clément
<civodul>(what's the IRC nick again?)
<lfam>I think I've found a promising commit in the kxmlgui repo, similar to one of Clément's fixes
<civodul>oh, snape
<civodul>so yeah, maybe snape knows
<civodul>i think the lesson is that next time we update Qt we should do it in a branch
<snape>yes, lfam, it's always the same headers that are missing
<lfam>snape, it's the QAction stuff, right?
<snape>the name of the missing header is written in the error message
<snape>I'll push a fix for Scribus tonight
<snape>basically, if it says 'error: invalid use of incomplete type ‘const class QStyleOptionGraphicsItem’', that means you need to add #include <QStyleOptionGraphicsItem>
<pkill9>how do you refer to a package's cofnigure flags? I've inherited a package and want to append to the original package's configure flags
<bavier`>pkill9: usually done with 'substitute-keyword-arguments'
<pkill9>oh i'm already using that, how would i append to the configure flags?
<pkill9>since #:configure-flags is within package-arguments
<bavier`>pkill9: (substitute-keyword-arguments (package-arguments the-package) ...)
<bavier`>pkill9: there are examples in other packages
<pkill9>oh ok i foudn an example
<pkill9>oh i wasn't already using that, i was just using the package-arguments one
<efraim>mariadb is failing on aarch64 on core-updates, so far it looks like updating 10.1.29 to 10.1.33 is working
***snape` is now known as snape
<rekado_>about core-updates: I’d be happy if more people here could try to switch their computers to core-updates.
<rekado_>it works on my Fedora workstation in the office, on my laptop, and on a RHEL6 cluster.
<rekado_>if you use somewhat uncommon packages now is a good time to make sure these packages work as expected.
<rekado_>I’d like us to merge core-updates in fewer than 6 days.
<reepca-laptop>and that'd be "guix pull --branch=core-updates" to switch?
<civodul>ACTION tries 'guix package -u' from core-updates
<civodul>which reminds me i need to fix emacs-w3m, which broke with the emacs upgrade
<ngz>Qt update broke Musescore, too =/
<reepca-laptop>Hm, tried "guix pull --branch=core-updates" and I get: no binding `invoke-error?' in module (guix build utils)
<civodul>reepca-laptop: could you paste the backtrace and all?
<vagrantc>is all this in preparation for a new "release" ?
<vagrantc>all the talk of testing core-updates and all that
<rekado_>vagrantc: it’s primarily to finally get the core-updates merged into master.
<rekado_>this has been delayed for months.
<rekado_>you can consider it a precondition for a new release, though ;)
<civodul>thanks reepca-laptop
<snape>ngz: could you report a bug?
<snape>please :-)
<ngz>snape: Sure.
<civodul>reepca-laptop: good question, i see the dreaded square as well
<civodul>'guix package -u' says: "2,233.9 MB would be downloaded"
<ngz>Hopefully, you have a broadband connection ;)
<civodul>i do, FTTH and all :-)
<civodul>that also includes a number of big tarballs and checkouts, but still
<civodul>oh, and texlive :-)
<civodul>why is it not more than 2G then?
<ngz>Texlive full?
<snape>reepca-laptop: Symbola
<snape>but I don't think it's in Guix :)
<reepca-laptop>yeah, just found that out
<reepca-laptop>license issues or just not packaged yet?
<snape>seems non-free :(
<snape>in the manual it says: "free strictly for personal, non-commercial use"
<ngz>Is it me or there's something odd with `format' in Guix? It seems to re-use the last argument for any spurious "~a" in the format string.
<OriansJ>snape: guixsd is used in commericial environments and thus can't be included in guixsd because it is not a free license
<nckx>The licence also explicitly prohibits ‘educational’ use...
<snape>OriansJ: it's what I just said :)
<OriansJ>It also implicitly forbids Government use (another group that uses guixsd)
<snape>too bad because it looks nice
<snape>maybe there's an free alternative
<ngz>It might be worth to contact the author.
<snape>he seems to know what he wants though
<ngz>I admit the "educational use not permitted" is rather opinionated.
<ngz>Quite uncommon, too.
<civodul>i'm confident there are free fonts providing THUMBS UP SIGN though
<rekado_>ngz: could you give an example for “format” that shows the odd behaviour?
<nckx>Seems so broad as to be ludicrously unenforceable.
<nckx>‘Better make sure no one learns anything from what you just wrote!’
<snape>ngz: there are two 'format' procedures
<rekado_>what about font-gnu-freefont-ttf?
<snape>one in srfi-28, the other in ice-9
<civodul>snape: actually three: one in (guile) :-)
<civodul>aka. 'simple-format'
<nckx>Note that the ‘thumbs up’ displays just fine for me in Hexchat, but not in Emacs, so it's not merely a matter of installing the right fonts.
<snape>but it's the same as the srfi 28 right?
<snape>with #f as destination
<civodul>ACTION has never used srfi 28
<snape>me neither, but that what's appear in the info manual first :-)
<snape>*what appears
<ngz>rekado_: Cannot find it at the moment. It was a format call for a ".desktop" with less arguments than "~a" in the format string. It may be a bug, though.
<ngz>On another topic, I wonder if there's a shortcut for the following situation. I package something where `build' phase is very long. It succeeds, but I made a mistake in `install' phase. I fix it and build again from the start.
<ngz>Is there anyway to somehow store the build state and start over from there.
<civodul>ngz: nope
<ngz>Like a special mode where we have a snapshot from both the source directory and the "outputs" after each phase.
<civodul>for debugging you can always --keep-failed and then fiddle with the build tree
<civodul>but that's the best we can do
<ngz>It helps finding the `install' error, but it cannot help skipping the `build' step.
<civodul>yeah, but there's no easy way to "skip" that
<civodul>it would break the whole model if this were permitted
<ngz>Hmmm. May I ask you why?
<bavier`>it would introduce a side-effect into the build
<civodul>the functional model means that the build process is viewed as a pure function
<ngz>I was thinking in terms of continuations
<ngz>You can go back to a previous continuation without breaking the functional model (or so I think)
<bavier`>you could look at it like that, I suppose
<bavier`>you'd need to infrastructure to support that
<bavier`>like a checkpoint/restart, with grafting upon restart
<ngz>Ah well. A silly/unreasonable vague idea, then. :)
<bavier`>not silly, imho
<bavier`>it'd be very useful for packagers, if we could convince ourselves that an implementation that doesn't break our functional model is possible
<snape>I think continuations break the functional model.
<snape>because invoking them adds a new input to the function
<vagrantc>would it be feasible to mark something as dirty, and not treat the build result as valid, but still otherwise proceed with the build?
<rekado_>a practical problem is that things in the store end up having their timestamps reset.
<rekado_>that would be bad for naively implemented checkpoints.
<civodul>vagrantc: in theory yes, but normal users don't have write access to the store
<vagrantc>ACTION found the numerous linux-libre builds on slowish armhf/aarch64 hardware only to find a typo near the very end to be ... time consuming. :)
<snape>you don't have to keep looking at it :p
<vagrantc>do have to check periodically ... make sure it didn't run out of swap, crash, etc.
<vagrantc>and the hardware i've been testing on is relatively capable...
<snape>ha :)
<vagrantc>ACTION recalls someone doing guix on a beaglebone black with only 512MB of ram and a lot of swap on usb
<vagrantc>tried on the wandboard solo with similar specs and quickly learned about offloading :)
<civodul>ACTION -> zZz
<civodul>good night/day!