<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. <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>Wow, berlin.guixsd.org 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. <Guest34672>a other question how I can put slim in keyboard french ? ***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. <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/guix-package.sh <jonsger>I see 3 :) derivations.scm works here <civodul>for tests/guix-pack.sh there's an open bug <rekado_>I introduced a bug with the change from #:tar –> #:archiver <rekado_>parts of guix-package.sh 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. <civodul>rekado_: re python2, we need to find another example of a collision then :-) <rekado_>civodul: well samtools@0 should collide with samtools, but there is no warning on core-updates. <rekado_>soundtoxin: I saw a bug report about pyqt being broken at the moment. <rekado_>soundtoxin: people are working on fixing it. <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_>“internal compiler error: Segmentation fault” <rekado_>I’ll try a different compiler version. ***Guest25977 is now known as Sleep_Walker
<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." <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_>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_>If this is done it would have to wait for the next core-updates cycle. <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? <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 <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>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 <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 <civodul>IntoxicatedHippo: no, but perhaps you can achieve what you want through 'kernel-arguments'? <civodul>if not, could you provide an example? <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 bug-guix@gnu.org <rekado_>the glibc package that we use to build glibc-locales is broken on core-updates. <rekado_>didn’t mean to pull you out of guix pull NG™ <civodul>i'll see if i can do something useful with glibc-locales in a reasonable amount of time :-) <rekado_>I’ll continue updating my profile then <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>(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>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 <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>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. <civodul>rekado_: cool! we're making progress :-) <jonsger>icecat also succeeds on core-updates, I'm impressed :) <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>lfam: dunno, i've seen a couple of Qt-related fixes <lfam>I think I've found a promising commit in the kxmlgui repo, similar to one of Clément's fixes <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 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. <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_>you can consider it a precondition for a new release, though ;) <snape>ngz: could you report a bug? <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>that also includes a number of big tarballs and checkouts, but still <snape>but I don't think it's in Guix :) <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 <snape>one in srfi-28, the other in ice-9 <civodul>snape: actually three: one in (guile) :-) <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>me neither, but that what's appear in the info manual first :-) <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. <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 <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`>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... <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 :) 