<nckx>Regexes are too useful to drop, but that second behaviour sounds good. It's just tweaking the order after all, it won't fail to find things the user expected. <lle-bout>nckx: I never said to drop regex just to clarify <nckx>Oh, you mean rename the packages, I see. That's seems overkill too though. <lle-bout>non-technical users can't be expected to know regex <kcurtet>lle-bout: I think regex its fine. I just need to escape special chars <nckx>lle-bout: Getting in the way is too strong but your second (amazing? OK :) option would improve ordering without breaking things, which sounds perfect. <nckx>kcurtet: A few. You can change the hard-coded path to ld*.so using patchelf, or on Guix System you can create a symlink in /lib automatically. You can also patchelf each library location individually, or you can install all required libraries into a profile (e.g., using ‘guix install’) and add $HOME/.guix-profile/lib to LD_LIBRARY_PATH, or a few other similar hacks. <nckx>There are multiple ways to do it, all of them a bit dirty, but the fact remains that Guix/Nix don't cater to seamlessly running third-party binaries. It's just not a priority. <nckx>Be prepared to have to learn a bit to get them to work ☺ <kcurtet>I see. maybe i can clone the package recipe for node 10 and upgrade it to 15 <lle-bout>We maintain a non-trivial downstream patch to qemu to build info manuals, it doesnt apply on qemu 5.2.0, would be nice if it got merged <nckx>kcurtet: That would be the Right Way! <nckx>I'd be amiss if I didn't point out that it's probably not trivial (we'd have node 14/15 already if it were), so plan accordingly. <nckx>Oh, it seems there is/was a wip-node-14 branch. <nckx>I don't know what the status is. <apteryx>lle-bout: it got mostly merged already <kcurtet>Its because i have a library @hapi/hapi it dosen't support node 10 <apteryx>lle-bout: lfam made a patch to update 5.2.0 that gets rid of it <apteryx>(while preserving the info manual, I believe) <pkill9>can i change the user's home directory in a guix container, without simply changing $HOME (it seems that programs use the 'real' home folder vs $HOME environment variable)? <pkill9>well -u changes the user and home directory, so it is definitely possible <pkill9>just seems to be hardcoded i guess <nckx>pkill9: $HOME is the ‘real’ home directory, so how would they know? If it's a subdirectory of the original $HOME, maybe they're using $XDG_...? <lle-bout>apteryx: it says it drops the patch and doesnt build an info manual but no big deal I think, we should submit such patches upstream first I think <pkill9>nckx: maybe from the passwd file? idk <lle-bout>apteryx: didnt see the patch to update qemu from lfam so thanks <lfam>It's on the patch tracker *nckx tried to get into a container to see what's virtualised and what's not (like /etc/passwd) but kernel says no :-/ <pkill9>maybe it's getting the HOME var before it's been changed by guix <pkill9>it puts me in my 'real' home dir, rather than the new $HOME var <pkill9>also mesa shader cache keeps getting put in the 'real' home directory inside the container <pkill9>so I'm wondering where they're getting them from <nckx>pkill9: Here, ‘HOME=/tmp fish’ respects it and ‘HOME= fish’ prints ‘Please set the XDG_DATA_HOME or HOME environment variable before starting fish.’ So... maybe, although I don't actually know fish at all. <nckx>pkill9: So ‘cd’ in fish doesn't change to whatever $HOME is set to in fish? Or...? <kcurtet>Any guix command to copy a recipe? or i need to go to the repo <lle-bout>lfam: apparently the security bug is only in a feature added in 5.2 so we're safe <pkill9>nckx: I mean when you start it it starts in the real home dir, but typing 'cd' it goes to new one <lle-bout>lfam: but for your patch, I think you should actually patch it <leoprikler>doesn't any shell start in the PWD of the previous one? <nckx>kcurtet: ‘guix edit PACKAGE’ will open the file in your $EDITOR, and you can save/copy it elsewhere, but actually saving it to the same file won't work. <nckx>pkill9: fish doesn't chdir on start, it just keeps the current pwd, so maybe that's expected here. <nckx>(Again, unable to try in a container, but that's what happens without one. cd /blah && fish → fish in /blah → cd → fish in /home/nckx) <apteryx>lle-bout: the original info patch was submitted upstream here <apteryx>this was the version working on what became 5.2 (ninja build system) <pkill9>after removing --no-cwd it seems to stay in previous directory now, maybe --no-cwd puts you in real home dir <nckx>Unless guix env -C chdirs, I think fish is acting normally. Less sure about mesa. Might be related. <apteryx>lle-bout: there was an email exchange that followed and their way to build the doc was revised (not sure this landed in 5.2) *lfam tries and fails to make a simple-service of sysctl-service-type <apteryx>which should make it trivial to build an info manual (hopefully it should be as simple as a configure flag) <nckx>pkill9: It does no such thing, but maybe that's where your starting guix env... <nckx>Or something in the way you start it is doing so. <pkill9>nckx: if i run `guix environment -C --no-cwd --ad-hoc fish` it puts me in my homedir <nckx>Errr, correction pkill9, it does so on once machine and not on another. <pkill9>(if i run that while in /tmp directory) <pkill9>nckx: if you use the -u option to change the user, which also automatically changes the homedir, it changes directory <pkill9>maybe guix is getting the real homedir from real /etc/passwd, and then changing to it, idk <nckx>OK, if I remove the 500+ line bashrc on the ancient box acting weird it works as expected, quelle surprise. <nckx>pkill9: You are very correct. <nckx>(mkdir-p home-dir) (setenv "HOME" home-dir) (chdir (if map-cwd? (override-user-dir user home cwd) home-dir)) <nckx>and, last for dramatic effect: (home-dir (password-entry-directory passwd)). <i1l>sneek: seen pipeware? <sneek>Not as far as I can remember. <i1l>damn, sneek! thou also not an part of "we". <i1l>what bugs me, is that nothing better than alsamixer was found by me. new protos are, but where are the "things"? <lle-bout>nckx: upstream git release key 'E1F036B1FEE7221FC778ECEFB0B5E88696AFE6CB' does not have non-sha1 self-signature, so what do we do? <pkill9>why can i not access this in guix repl or guile :( (@@ (guix scripts environment) launch-environment) <i1l>pkill9: guess: it is an macro (launch-environment) maybe? <lfam>lle-bout: I think we just ignore it. One could ask the upstream to upgrade their PGP or whatever they should do <nckx>lle-bout: I don't have a better (non)solution than to disable that line in your gpg.conf. It's just not tenable to keep working around the rest of the world. <lle-bout>nckx: just did so hopefully temporarily, thanks <nckx>I guess it happens to work for me because I never use ‘guix refresh’. <nckx>And don't let friends use SHA-1. ***sturm is now known as sturm11
<nckx>Wish I had a better answer lle-bout. <lle-bout>not sure who to send an email to though.. <lle-bout>updating git to 2.30.2 on master, that OK? it doesnt have <300 dependents <nckx>If you have the energy to do so, please do! :) I'm too de{ple,fea}ted atm. <nckx>How many dependents does it have? <lle-bout>nckx: 119 IIRC - but it surprised me it is so low <nckx>‘doesnt have <300’ → typo then? <nckx>No problem. I've always updated git on master too. Go ahead. <nckx>(It's always possible that some change would cause that number to skyrocket, so thanks for paying attention.) ***sturm11 is now known as sturm1
<i1l>pkill9: do not be greedy. show the errors. <pkill9>it just says error: launch-environment: unbound variable <nckx>I don't follow Guile dev closely but I think that @@ is no longer something you can count on working in 3.0. <nckx>Either it only sometimes does or it always doesn't, I'm not sure. <nckx>Er, declarative modules something something. <nckx>Being incompatible with the @@ hack so it had to go. <i1l>i mean, i used this thing in config. <i1l>aren't it was seen in Guix packages sometimes? <nixo>Hi guix, it's super late so I'm going to sleep, but I just tryied to upgrade guix and got a failing graft <nixo>pstoedit-3.75: replacement length differs from the original length "vlix7fclb7ifjgmxgpwr1pvraff89w7b-imagemagick-6.9.11-48" "mf0y39m4n8j9g189pyv7idc69k0dgr3w-imagemagick-6.9.12-2" <pkill9>so there's no alternative to @@? <nckx>nixo: The version has to be exactly the same length, because a graft is a filthy naive string replacement in binaries. <nckx>So you have to lie, basically. <nckx>Drop the 8 or the - or whatever offends you least. <i1l>pkill9: copy-paste needed things to an separate module.. then maintain synchronisarion with upstream. that what all serious dudes do! <nckx>lle-bout: Thank you for fixing all the CVEs. <kcurtet>> Im building a service for emacs --daemon but im not sure witch <kcurtet> command tu use for #:start () `make-forkexec-constructor' seems to <kcurtet> kill the process and restart but not sure if its the #:stop <nixo>nckx: but that is already on master <nckx>Guix 1.2.1 CVE-free edition. <nckx>Thanks for reporting it. <nixo>However, with --no-grafts it did work so I'm fine, but maybe it should be fixed <nckx>It definitely should, thanks. What command was that? guix pull? *nckx was also about to go to bed... <nckx>lle-bout: Could you take care of that first? ☝ <i1l>wait. Guix has no pre-defined service for Emacs? <i1l>just grepped the Manual. <nixo>nckx: I'm runnign 'guix package -m manifest.scm' <nckx>i1l: Those who run emacs as a service do so as their own user. Shepherd user services aren't (...yet?) handled by Guix. <nckx>Yes. Mind if I revert 82e887ba48c2ba91b17aa9b6b17501e3e0ef4aef? <i1l>nckx: bbut.. i saw Emacs service in Nix. <nckx>lle-bout: (I have only to press return.) <nckx>i1l: Yes, and it's ‘Whether to enable a user service for the Emacs daemon’ :) <nckx>Guix System only configures system services for now. <i1l>nckx: was systemd not ised due to reproducibility, btw? <nckx>You *could* (probably?) run emacs as your user that way, but it ain't right. <nckx>i1l: I don't think so, simply that the Shepherd (previously: dmd) already existed and is written in Guile Scheme. <nckx>Synergy & all that. That systemd is explicitly Linux-only (no Hurd support) might have been a factor even then, but I don't know about that. <nckx>Maybe we just got lucky. <lle-bout>i1l: the GNU Guile Scheme extensibility feature is the main argument to me. *nckx not anti-systemd, no shoot. <lle-bout>Actually using systemd would've probably saved us lots of hassle, but GNU Guile Scheme extensibility is also really good and important in GNU Guix. Opens so much possibilities. <lle-bout>GNU Guix is 'GNU', so if there's the opportunity to use GNU software I think it is preferred. <i1l>did anyone used lsh ever, btw? <i1l>lle-bout: not sure if It alive.. <lle-bout>but to be honest here, I try openssh more w.r.t. security considering lsh's much less popular and gets less auditing. <nckx>i1l: Believe it or not, there was no openssh-service when I started using Guix in 2015, only lsh. So very many people have used it. Well, as many as used Guix. <bone-baboon>I would like to look at some package modules. Where are they located on a Guix system? <lle-bout>You wont be able to edit source files this way but you can inspect them. To edit, clone a local copy then use ./pre-inst-env guix edit <pkg> - see manual for usage of pre-inst-env etc. <bone-baboon>Section 10.1 Using the Configuration System of the Guix manual mentions unambiguous package reference like `(list bind "utils")`. It mentions a downside of this approach is that you need to know what modules defines a package. What is a good way to find out what module defines a package? <pkill9>how much memory/CPU does a guix container use? <lle-bout>pkill9: it's a Linux container so not much no, but do calculate it more precisely. <lle-bout>bone-baboon: "guix show <pkg>" will tell about the filename the package is defined in (ending in .scm), GNU Guix uses file name without extension as module name AFAICT. ***qyliss- is now known as qyliss
<Gooberpatrol66>Is it possible to generate a Btrfs RAID configuration from config.scm? <morgansmith>hey in commit c05ceaf2b650d090cf39a048193505cb4e6bd257 a comment near the top of tests/lint.scm (line 64) should have been deleted but was not. It's a super quick and easy thing so I'm hoping complaining here will fix it. <bone-baboon>`guix show git` has a location field. If I search for a module using it's location `locate gnu/packages/version-control.scm` there are many files that match the search that have different hashes. If I want to read the module which one should I be looking at? <apteryx>dongcarl: I narrowed the issue to dbus-c++; for some reason attempting to use this from Guix to build static libraries would result in the previously reported errors. I think we may be missing patches to our dbus-c++ package, compared to debian and others. <bone-baboon>I am using Emacs and ansi-term. When I run `guix edit git` it opens `nano` in the Emacs ansi-term buffer. Is there a configuration variable I can set so that it just opens the file in a regular Emacs buffer? <morgansmith>so if you run `M-x server-start` then you run the emacs daemon. This is nice because now you can send things to that daemon and it will pop up in your emacs. Then you can set you $EDITOR var to emacsclient. emacsclient is the executable you use to interact with the daemon <morgansmith>alternativly, you could decide to not use guix edit. the location you found is relative to the root of the git repository (Only true if the package your looking at is not from a 3rd party channel). I'm not sure where that reposity is located on your local disk, but you could obtain a new copy from here: https://git.savannah.gnu.org/git/guix.git <bone-baboon>What is the signifigance of the "gnu/packages/version-control.scm" file that `guix edit git` opens compared to the other "gnu/packages/version-control.scm" files that are located with `locate gnu/packages/version-control.scm`? <lle-bout>bone-baboon: the other copies could be cached versions that GNU Guix kept <morgansmith>so how do I actually use data.guix.gnu.org? I want to show someone that emacs-flymake-shellcheck is bust by sending them a link. Can I use data.guix.gnu.org for this purpose? And if so, how? <lle-bout>morgansmith: if you are talking about failed builds, then you use ci.guix.gnu.org rather <morgansmith>oh. yes ci.guix.gnu.org is wonderful and is exactly what I wanted. Thank you very much!! :D <raghavgururajan>> apteryx: sorry, I've forgotten once more; what exactly do I need to do to have icons available in a pure environment? <raghavgururajan>For gtk, --ad-hoc hicolor-icon-theme and adwaita-icon-theme, with or without dconf. <apteryx>raghavgururajan: I've tried that in a pure environment but jami would still lack some icons <apteryx>gtk+ is included in the profile, so XDG_DATA_DIRS is defined ***iyzsong-- is now known as iyzsong-w
***iyzsong-- is now known as iyzsong-w
<hapster>is anyone here using EMMS and MPD successfully? I could use some help setting it up or an example configuration :) ***ppsym is now known as PurpleSym
<Whyvn>I am trying to build my first package. From the looks of it, it should be a very simple package to implement. But I am having issues. It is a python package and only needs to run python3 setup.py install. I am getting an error on the build phase. From looking the manual python-build-system says it does python setup.py build and then python setup.py install. My question is, how can I skipp the build phase and go directly to the install <Whyvn>phase? I tried modify-phases %standard-phases (delete 'build) but that didnt work. this is the package declaration I have so far http://paste.debian.net/1188632/ I am sure I am missing something obvious... <lle-bout>mothacehe: I have something to discuss with you! ***apteryx is now known as Guest97284
***apteryx_ is now known as apteryx
<lle-bout>Whyvn: hey, what's the error you are getting? <lle-bout>mothacehe: I would like to suggest you remove paging on evaluation pages in Cuirass and add ability to sort by the build icon so we can easily see new build failures in individual evaluations <lle-bout>Whyvn: so you used a GNU Guix hash as commit, that's wrong <lle-bout>Whyvn: also try: guix import pypi -r cryptop <Whyvn>lle-bout: thanks that seems to make it a little easier. how do you add licenses that are not in guix licenses? <lle-bout>Whyvn: what license are you referring to? <Whyvn>i am getting error: license:bsd-3: unbound variable hint: Did you forget a `use-modules' form? <Whyvn>i tried gnu packages form, but thats wrong. <lle-bout>Whyvn: Add: ((guix licenses) #:prefix license) <mothacehe>lle-bout: isn't the filter per failing builds sufficient? <lle-bout>Whyvn: ((guix licenses) #:prefix license:) rather <brendyyn>mothacehe: simple-cuirass-service test uses the code you removed and breaks the build for me <lle-bout>mothacehe: well when I make a change I want to check if I made GNU Guix more broken than it was, going to fix already-failing builds is another quest <lle-bout>brendyyn: yes I corrected a bit later as well <gagbo>Hello, I have a small issue when trying to run a simple "guix pull", I fail building the "guix-system-tests" derivation, with a "simple-cuirass-configuration->specs unbond variable" error. Has anyone encountered this ? <Whyvn>lle-bout: apologies for the needing of step by step guidence, but I am getting this error now error: cannot install non-package object: #<unspecified> <mothacehe>gagbo: it should be fixed if you run "guix pull" again. <lle-bout>Whyvn: your manifest must return the package object <mothacehe>lle-bout: I see, that would be a filter on "new-failures" <gagbo>mothacehe: seems good, sorry for the noise ! (had weird timing on that one, I thought I did something wrong on my desktop install) <lle-bout>mothacehe: yes! :-) Also fixed builds would be great too! <lle-bout>mothacehe: thank you! And what about paging on evaluations, what do you think? I think the paging is useless and making navigation troublesome there. <mothacehe>yeah I agree it's painful, maybe the Boostrap library has a better suited object for that <Whyvn>lle-bout: is there a place in the manual that will expand upon that, I do no know what that means. From what I gathered from the package guides is using guix package --install-from-file=, would I have to append a --manifest field? Or would another entry go into the package.scm file? <lle-bout>Whyvn: the (package ..) object needs to be last in the file, or a variable that references one <lle-bout>Whyvn: in Scheme, values are returned when they are present last in a function or file here <lle-bout>Whyvn: unspecified here means you have nothing last, you must be using only (define-* ..) expressions <Whyvn>lle-bout: ok that makes a little more sense. yes there are two (define-public <names>) ***iyzsong- is now known as iyzsong
<mbakke>lle-bout: do you think it's feasible to add absolute references to xdg-utils in ungoogled-chromium instead of wrapping with PATH? <lle-bout>mbakke: I tried, there's many places, also xdg-utils has many executables, xdg-open, xdg-email, xdg-mime, .. <lle-bout>mbakke: the solution I proposed is easiest and most maintainable <lle-bout>mbakke: considering the prefix, the wrapper has no downsides <mbakke>lle-bout: rumor has it that you can push now? :) <mbakke>it's been so long I'm not sure I remember how.. <lle-bout>I can push it, will do shortly if you don't <mbakke>lle-bout: that's great, I'm not really setup for pushing atm :) <Whyvn>lle-bout: if python-requests is in the package repo, what would be the reason for getting and unbound variable? `(("python-requests" ,python-requests) is defined in propagated-inputs, shouldnt it be automatically pulled? *mbakke has been trying to add a "debug" variant of ungoogled-chromium for investigating a crash on some sites, but it's tricky because the debug code is not properly "ungoogled" <raghavgururajan>leoprikler: Examples needed more work. So I disabled it for time-being. Working on it now. <raghavgururajan>efraim efraim_ efraim1 : Thanks for merging #47016. Would you be able to merger related #47017 as well? <Whyvn>lle-bout: holy hell, it worked. Thanks a lot lle-bout! its a simple package, but i am happy to have one made. I appreciate the patience and help. ***amfl_ is now known as amfl
<Whyvn>brendyyn: thanks, it was a small victory i needed. I thought I was going to get filtered by the guix package system. I would eventually like to help contribute to more packages and documentation, but I first have to understand it myself. <efraim>raghavgururajan: 47017 fails to build for me <jlicht>Whyvn: perseverance and being patient with oneself go a long way in learning new things, congrats :) <Whyvn>brendyyn: I woudldnt be cut out to help with creating packages with guile/scheme/guix as it would be too complex, but of course with enough time there comes understanding. I have just been bashing my head against the keyboard the past few days trying to get at least 1 package together. <raghavgururajan>successfully built /gnu/store/z4b9sha76jz1zm7kmppg841rvx7mx4xh-gajim-1.3.1.drv <efraim>raghavgururajan: I'm building on a tmpfs using stock linux-libre 5.10.19, also fails with --cores=1 <raghavgururajan>efraim: With `./pre-inst-env guix describe` = f4018716bbbf87f54fe9c9429edb51e222ef2aaa, I get "successfully built /gnu/store/zqnp5z4a1n9xmqqrdvzid8qblj7fk827-gajim-1.3.1.drv" <efraim>I last tried on f4fd7bda51f26c3ae00c4c8681c344074739df5c, also failed before that commit <efraim>raghavgururajan: that worked, not removing the old failing test. should the old linked issue remain? <efraim>hmm, looks like a different failure, following the link <efraim>hmm, adding add-installed-pythonpath didn't help <efraim>lle-bout: if we were able to rebase some of the ppc64le patches onto master would powerpc64le work? or are there other things in core-updates (besides gcc-8) that it needs <efraim>and by some of the patches I mean the ones in the wip-ppc64le branch starting from where it adds the bootstrap binaries <brendyyn>Anyone else getting bizarre http headder erros downloading substitutes lately? <lle-bout>efraim: if someone could do that then it would be awesome, you told earlier it would be difficult, gcc-8 is only required for glibc >=2.32, otherwise some patches were taken from core-updates like gnutls, but you'll see <efraim>it looks like gcc-4.7/libstdc++, findutils-boot0 and glibc are the only tough ones. I think the rest that aren't specific to core-updates can probably be straight cherry-picked to master <lle-bout>efraim: alright! that really sounds good! <raghavgururajan>leoprikler: I have CCd you on #47042, with regards to enabling examples for QtSolutions. <jx96>Is anyone trying to compile rust-cargo-c 0.7.3+cargo-0.51? <Formbi>but I'm getting «unable to execute 'cc': No such file or directory» when it tries to build the CFFI stuff <Formbi>which is quite strange, cause I don't really see 'cc' anywhere in the source <Formbi>lle-bout: I passed --cc=gcc to the rpython <Formbi>I did «export CC=gcc» in guix environment and it doesn't work either <PurpleSym>Formbi: PyPy2 as in the JIT Python interpreter? <lle-bout>was thinking about something the other day, doesnt time-machine command mean every package that will ever violate FSDG will continue to be available on GNU Guix <wleslie>cffi pulls its C compiler from distutils <Rovanion>lle-bout: Isn't that always the case with a versioned package repo, sort of? It's just easier to use now. <Formbi>wleslie: but it uses the bundled distutild <lle-bout>Rovanion: Yes it is but I don't think any other FSDG distro has such capability. <PurpleSym>Formbi: Have a look at the existing pypy3 package. There’s a substitute* for lib-python/3/distutils/unixccompiler.py <PurpleSym>Maybe you can even inherit from that package and just adjust the things that are different for Python 2. <wleslie>also: there's an existing pypy3 package? how do you even build pypy3 without pypy2? I guess "very slowly" <Formbi>also I did guix build -K and guix environment --pure from the build directory <leoprikler>raghavgururajan: you have to set a slash at the end of one of "examples" or "bin" (i.e. "examples/" or "bin/"), but I'm not sure which <leoprikler>note that you shouldn't install the examples though (see my mail), it's just in case you want to learn more about copy-build-system <apteryx>raghavgururajan: about that icon issue; I've built the application from a 'guix environment', not relying on the gtk-or-glib-build-system phases; perhaps something from it is required? <raghavgururajan>apteryx: In those phases, for gtk, the executables get wrapped with gtk modules. IIUC, icons are not included in modules. So probably unrelated. <apteryx>right, it just wraps them with the environment variables such as XDG_DATA_DIRS, but that's set in my 'guix environment' <raghavgururajan>I mean executables get wrapped with .so files under /lib/gtk/modules. <raghavgururajan>leoprikler: The compiled examples might be useful right? like an reference implementation or something? <leoprikler>for icons, schemas etc. to work such packages need an envrionment with --ad-hoc glib <leoprikler>(which just causes XDG_DATA_DIRS to be set accordingly) <raghavgururajan>For [1], I get "no library QtSolutions_LockedFile found" while linking. Even when I mention "-l../../qtlockedfile/libQtSolutions_LockedFile.so", I get "no such file or directory". <apteryx>leoprikler: ah, funny, I knew that, but I thought gtk+ was propagating glib. It isn't. <leoprikler>raghavgururajan: -L../../qtlockedfile -lQtSolutions_LockedFile. <leoprikler>oh, of course, because it's in the lib subfolder 😋️ <apteryx>lle-bout: in theory yes. In practice, I'd expect the lack of substitutes, and the original sources disappearing to cause problems (although Software Heritage intends to change that, but it doesn't cover everything yet). <raghavgururajan>leoprikler: LoL, I did not notice the missing /lib. But I tried with /lib. *raghavgururajan looks up <apteryx>leoprikler: sadly, adding glib is not enough in this case; I guess the wrapping of .so and other dirs in the glib-or-gtk build system really does something helpful ***janneke_ is now known as janneke
<leoprikler>ahhh, but for schemas, you still need glib, because they're not in the data folder or the input <raghavgururajan>leoprikler: With "LIBS += -L../../qtlockedfile/lib -lQtSolutions_LockedFile", I get "ld: cannot find -lQtSolutions_LockedFile". <civodul>avalenn, apteryx: i'm looking at "guix import go", we should be all set! <civodul>avalenn, apteryx: i'll add an entry in etc/news.scm so people can discover it <efraim>lle-bout: I got waylaid by some household stuff, I got libstdc++ adjusted, next bit is gcc itself <efraim>of course after I finish it has to be tested on powerpc64le <apteryx>civodul: cool, I'll keep polishing extra bits I have locally when I have a chance and submit for review later <apteryx>raghavgururajan: the idea that some modules required to load icons is missing sounds like plausible; here's one of the messages from the client: DEBUG: 08:44:15.457: Could not load icon: Unrecognized image file format <apteryx>so probably need to extend GIO_EXTRA_MODULES the way glib-or-gtk-build-system does <apteryx>interesting, there's no $GUIX_ENVIRONMENT/lib/gio/modules in that profile <apteryx>it's a shame this hackery is not transparently handled by search paths <raghavgururajan>I see LIBS += -L../../qtlockedfile/lib -lQtSolutions_LockedFile -L$$QTSINGLEAPPLICATION_LIBDIR -l$$QTSINGLEAPPLICATION_LIBNAME <leoprikler>now you can run make inside the build directory and check which modifications actually lead to a good result <apteryx>civodul: it's not currently possible to express a search path such that it selects the parent directory if it contains some child directory/file, correct? <apteryx>raghavgururajan: it's strange, inspecting what the glib-or-gtk build system does, and looking at the glib and gtk+ packages search paths, the only difference seem to be that the build system sets GTK_PATH rather than GUIX_GTK3_PATH. <apteryx>another interesting point is that the jami package doesn't even make use of glib-or-gtk-build-system (it uses cmake-build-system), yet when installed to my user profile along with adwaita I do get icons. <efraim>lle-bout: got gcc adjusted, both patches pushed to wip-ppc64le <efraim>looks like findutils is core-updates specific <roptat>so it's not clear to me, shall we start merging c-u soon, or do we wait for the next release? <roptat>also for next release, I can send a message to all our translators via weblate, to inform them of our plans, string freeze and release dates, etc <roptat>and we'll have to compromise on readability of commits related to locales I think, because weblate updates po files from the pot, even when there is no change to the translation itself <roptat>meaning there are many changes in po files that are just "let's update the comment that gives the line number of this string" <roptat>especially in the manual, since any modification will change line numbers of every string after it <efraim>my understanding is core-updates after the next release <efraim>we'd like it, but there ends up being a lot that goes into fixing everything <zimoun>roptat: my understanding is merge core-updates after the next release. <roptat>so we plan the release for april 18? <zimoun>IIUC, merginf c-u requires more than 6 weeks <zimoun>I think it is a good date, initial commit anniversary. <roptat>zimoun, since you were complaining about readability of po commits, is it ok to push current po files, even though some update only comments / untranslated strings? <roptat>I don't think we have a choice anyway, but if you oppose, we can try and think about something, like I did with how we normalize po files now <leoprikler>if you install missing icons, they do get seen by XDG_DATA_DIRS, since that has ~/.guix-profile by default IIUC <zimoun>well, the best (pragmatic) seems to push the current po files and think about something as incremental improvement for next. <emacsen>I'm looking for an article... maybe someone else has read it... It basically shows how you can go from a configuration language, or a data language like JSON and you realize quickly you've made a lisp <emacsen>it's driving me mad that I can't find it again! <apteryx>leoprikler: I do have adwaita-icon-theme in the environment manifest <apteryx>even when not using --pure the icons cannot be loaded <apteryx>it seems to find the icons, but fail to load them <apteryx>this kind of call fails: GdkPixbuf* icon = gdk_pixbuf_new_from_resource("/net/jami/JamiGnome/jami-symbol-blue", &error); <leoprikler>hmm, are the gresources installed or are they linked into the application? <leoprikler>a similar failure occurs in mumble (it is unable to load sounds) <apteryx>it returns NULL and I get this message (from the client-gnome code of Jami): g_debug("Could not load icon: %s", error->message); which gets printed as DEBUG: 09:40:34.180: Could not load icon: Unrecognized image file format <apteryx>and to be clear, I'm building the application in 'dev mode' outside of a Guix package definition for now; so perhaps that's at play but I at least extend XDG_DATA_DIRS to its local install/share directory <leoprikler><file alias="jami-symbol-blue">jami.svg</file> <- it could also be that svg support is missing? <roptat>does strace show it finds jami.svg? <apteryx>leoprikler: right, the application itself cannot be grafted <apteryx>roptat: so the icon is installed locally (dev tree): ./install/client-gnome/share/icons/hicolor/scalable/apps/jami.svg <roptat>oh wait, is that a Qt application? <apteryx>and in the environment I'm doing XDG_DATA_DIRS=install/client-gnome/share:$XDG_DATA_DIRS command-to-run-jami <apteryx>nope, that's still the GNOME client (gtk+) <roptat>I had issues with Qt and svg icons in the past <leoprikler>the icon itself maybe installed, but not under the name it's searched for <roptat>Qt was missing its QtSvg plugin (or whatever it's called), and I had to wrap the program <apteryx>ah, it must be that the gtk-font-cache is not build with those icons since the application is *not* in a package form <apteryx>leoprikler: the icon is registered in client-gnome/pixmaps/pixmaps.gresource.xml, using: <file alias="jami-symbol-blue">jami.svg</file> <efraim>lle-bout: you can't update mongodb, the license changed <leoprikler>yes, and that resource gets linked into the application itself <leoprikler>so, wait, if I were to use --latest and somehow got a working package, it might no longer be under the version I assume it has? <zimoun>apteryx: do we agree that we can remove python2 packages if there are broken and without any dependant? <civodul>apteryx: right, search paths only add matching files/directories <civodul>so for XDG_DATA_DIRS, it's share/, which is admittedly pretty broad but IMO a "problem" with XDG <zimoun>apteryx: ok, so I am doing the list <apteryx>civodul: right; every package must have a share due to installing the license file <apteryx>but that doesn't seem to cause a problem so far <civodul>apteryx: re "guix import go", do you know where i can find examples of packages that can be imported? <civodul>looks like the go-version->git-ref call in definitions is bogus <civodul>avalenn: we do, say, (go-version->git-ref version) == (go-version->git-ref "2.4.0") == "2.4.0", but the Git tag is "v2.4.0" <avalenn>you can find packages in pkg.go.dev, but an example of package would be golang.org/x/sys <apteryx>civodul: oh, I have a fix for that in my tree <apteryx>but my tree is in a messy state... let me try to extract that bit <avalenn>you're right, "v" should be added if it does not exists <apteryx>go version should include the v, so I think my fix is more correct <avalenn>my version adds it in go-version->git-ref, yours add-it after <apteryx>right, I'm just being picky that strictly, a go-version must be formed with the v prefix, so it makes sense that the regexp matches it <civodul>i'll take that and then leave it up to y'all for further improvements <apteryx>I have another little one for the license field unless it's been applied already <apteryx>ah, but license extraction is to be applied later anyway, it #f right now, right? nevermind then <avalenn>I cannot remember why I made the "v" optional in the go-version regexp <apteryx>it's possible that non-module Go packages use non v prefixed versions; I'm not sure if the generated go.mod from the proxy server would normalize it but probably not, so that may be why <civodul>apteryx: shouldn't the two arms of the 'if' be swapped? <civodul>as in: (if (and plain-version? v-prefixed?) '(go-version->git-ref version) '(string-append "v" version)) <apteryx>so plain-version? basically means it's a tag such as v1.2.0 <apteryx>it's fun, it's because the code is quoted <apteryx>the version you see is not the version passed as argument :-P <apteryx>the version in the quote is the guix record bound version variable, whichis stripped of any 'v' prefix <apteryx>the version provided as argument has the prefix. Confusing, eh? <avalenn>I think my patch makes the think more understandable <avalenn>always make the output of go-version->git-ref output the "v" prefix <avalenn>and just strip the "v" for the version field of the package <avalenn>as the regexp matches with or without "v", go-version->git-ref is idempotent and works with the stripped version as input too <Noisytoot>I have noticed a spelling mistake in guix/licenses.scm, in a comment on line 239 <Noisytoot>";; "LOST PROFITS" becoms "LOSS OF GOODWILL" and a section is added between 6.2" should be ";; "LOST PROFITS" becomes "LOSS OF GOODWILL" and a section is added between 6.2" <apteryx>avalenn: what is version is "v2.3.4"? It'll become "vv2.3.4", no? <apteryx>avalenn: I don't have the full code context, just looking at the diff <apteryx>(go-version->git-ref "v2.3.4") -> "vv2.3.4" <apteryx>avalenn: also we could normalize the string so that it always outputs a v prefixed one, but that ends up getting used as the git refspec so we shouldn't alter it in my opinion <apteryx>as you said, there may be a good reason why the v is made optional in that regexp, and I'm sure some Go package indeed would use a tag such as "1.0.0" rather than "v1.0.0" if they predate the Go module system or don't care about it <avalenn>apteryx: you're right, I missed something <lfam>I'm trying to make a simple-service of sysctl-service-type, to set up some default sysctl settings on Guix System <pkill9>i thought there is already a sysctl service <lfam>Yeah pkill9, I'm trying to use it :) <lfam>Does anyone have any advice? <lfam>I tried copying the pattern used by the other "default settings" simple services, which are the console-font-service and the static-networking-service <lfam>I tried just using (service sysctl-service-type ...) in %base-services, but this prevents users from setting more sysctl settings in their config.scm. In that case, it fails like "guix system: error: service 'sysctl' provided more than once" <lfam>Although, it seems to me this should work. It does work for special-files-service-type <lfam>I've been trying to figure this out for hours <Artemix>Hey there! during setup on my laptop, due to having a shitty router the dhcp address resolution is very slow, and the eth link establishment of 5s timeouts before. Is there a way to avoid that? <Artemix>if that was being hosted at OVH strasbourg, the datacenter was destroyed in a fire today <lfam>That's pretty crazy though <roptat>but I thought it was berlin answering directly on ci.guix, so it's not offline, is it? <lfam>I see that the main admin is logged in <civodul>avalenn, katco, apteryx: pushed! \o/ <katco>civodul: i assume you're talking about the go importer? <katco>woo! awesome work all! it's going to be fantastic having that :D <apteryx>civodul: yay! thanks to katco and avalenn for their work on it, and for you for reviewing it! <katco>yes, big thanks to all involved. especially avalenn for carrying it over the finish line. <katco>i don't usually do `pull`s in the middle of the week, but today i make an exception :) <avalenn>I am focusing now to try to package some software I need that have big dependency chains. <avalenn>And I am already hitting some limits which can quickly become painful with recursive import. <avalenn>This importer is really a work in progress but the first step is here now. We just have to improve it. <pkill9>is unionfs safe enough to rely on? <avalenn>cidovul: you added the hash generation from git. Thanks a lot. <avalenn>I can now drop my dirty patch which tried to do it. <civodul>anyone knows how to invoke the Postgres CLI to fiddle with the Cuirass database? <jonsger>civodul: sudo -u cuirass -s /bin/sh -c 'psql cuirass -h /var/run/postgresql' <apteryx>avalenn: in my tree I was trying to unlock pinned version imports to deal with recursive dependencies of self <apteryx>for example golang-protobuf's bootstrap is reminiscent of rust's <rekado>is it expected that cuirass is down? <rekado>so, nobody is restarting it right now <lfam>I saw that mothacehe was logged in so I figured they knew, but I sent htat email anyways <rekado>I just started the cuirass services <lfam>This isn't your problem, but I notice that the list of specifications in the web interface is no longer correct <rekado>why are all the values in the “channels” column “guix”? <lfam>mothacehe replied to the email <civodul>i think it has to do with the new evaluation process <daviwil>Hey folks! Quick question - is there any way to get the shell output when running a script using `invoke` in a package definition? My `(invoke "sh" "script.sh")` is failing with a nonzero exit code and I can't see any script output to figure out why <apteryx>rekado: could be due to me pushing a commit triggering 2700 builds 30 minutes ago; I had checked the number for gtk+@3 but didn't for gtk+@2; decided to let it slip rather than revert. <roptat>daviwil, invoke does send the output of the script to the console though <roptat>if the error code is "127", that's no such file or directory, which would explain why there's no output <daviwil>roptat: Yes! That's the code. Thanks, I'm probably using the wrong script path <daviwil>Could it also be that `sh` itself isn't being resolved? <daviwil>I see some packages `(invoke "sh")` without adding `bash-minimal` to `native-inputs` <roptat>I doubt it, unless you're doing something very crazy with the package definition <daviwil>Ok, `sh blah.sh` returns error code 127 so it's definitely a bad script path <apteryx>is someone else using the staging branch? <apteryx>I though a profile defined with a manifest incluing gdb and some :debug output should define GDB_DEBUG_FILE_DIRECTORY, but that doesn't seem to happen (anymore?) <apteryx>the variable is defined as a native-search-path on gdb on staging ***jx97 is now known as jx96
***qyliss_ is now known as qyliss
<euandreh>is it my env, or the latest commit on guix can't be authenticated? <euandreh>guix pull: error: could not authenticate commit 15092548804b6c50ea276d098f76a79bd0042398 <euandreh>since the commit was pushed to Guix upstream repo, I assume this might be a new committer missing its fingerprint in the 'keyring' branch <leoprikler>Typically we set up keyring and authentications first, though. <leoprikler>but "key 51A0 982A 58B6 4622 4648 3308 5EEB 3986 CB2F 65ED is missing" <nckx>("9ADE 9ECF 2B19 C180 9C99 5CEA A1F4 CFCC 5283 6BAC" (name "taylanub")) <nckx>[commit made] using RSA key 51A0982A58B64622464833085EEB3986CB2F65ED <nckx>euandreh: A very old committer. <euandreh>makes sense, maybe from before authentication was setup <roptat>there's a key for taylanub in the keyring branch, but it's not the same fingerprint <euandreh>maybe contact taylanub to update the keyring, and move the commit to a different branch so that the channel doesn't stay broken <leoprikler>fwiw, it seems their key was updated on savannah <lfam>I can't stick around but I saw the logs <lfam>I removed taylan from the Savannah project <lfam>This is a case where I suggest rewriting the history of the branch <lfam>Once things are fixed, another Savannah admin can re-add them to the group <euandreh>the commits to be rewritten are just one FTR <cbaines>I think savannah is configured not to allow force pushes, so the only way to remove the commit might be to delete the master branch, and re-create it without the commit <efraim>I thought the master branch was protected also <lfam>I was actually going to remove them from the project anyways, due to a long time without any participation <cbaines>I'm not sure what the implications of that are, I wonder what would end up being sent to guix-commits <lfam>It will send an email that the branch is deleted. No big deal <lfam>We do it all the time for other branches <lfam>And if we break it... it's already broken <Noisytoot>I just ran "guix pull", and I got this error: "guix pull: error: could not authenticate commit 15092548804b6c50ea276d098f76a79bd0042398: key 51A0 982A 58B6 4622 4648 3308 5EEB 3986 CB2F 65ED is missing" <euandreh>Noisytoot: its really broken now, still working on fix <Noisytoot>Maybe "guix pull --commit=60174c9c8c307be43450af38ce7c4e268278e07c" will work (it's the commit before), but it's slightly older *nckx got disconnected at this ideal time, reads backlog. <Noisytoot>guix pull --commit=60174c9c8c307be43450af38ce7c4e268278e07c is working so far <nckx>Noisytoot: ‘So far’? It should just work. <nckx>guix pull: error: could not authenticate commit 999a1cba5416bb2099e21d4fc55624d8ef2c7fa1: key CA4F 8CF4 37D7 478F DA05 5FD4 4213 7701 1A37 8446 is missing <nckx>(Yes, git log --format=oneline {origin/,}keyring | head -n1 → 3da8e4a6587d05145d1cad94ef6183d34bac7555 Add keys for lbraun.) <zimoun`>nckx, 999a1cba54 works for me, I guee. But 1509254880 not. <nckx>zimoun`: 1509254880 is expected. <nckx>I'm not going to bother debugging 999a1cba54 now. <nckx>I've asked #savannah about deleting the remote master branch. ***nckx changes topic to 'GNU Guix | ⚠️ you need to run guix pull --allow-downgrades exactly once | get Guix at https://guix.gnu.org | videos: https://guix.gnu.org/blog/tags/talks/ | bugs & patches: https://issues.guix.gnu.org | paste: https://paste.gnome.org/ | Guix in high-performance computing: https://hpc.guix.info | This channel's logged: https://logs.guix.gnu.org'
<nckx>OK, people. Things should be back to normal. You need to run guix pull --allow-downgrades as the topic says. Do not make a habit of this. <zimoun`>nckx: I am not sure 999a1cba54 is broken. rm -fr ~/.cache/guix && guix pull --commit=999a1cba54 -p /tmp/trash works for me. But 1509254880 is definitively broken. As reported before. <roptat>nckx, that would be for people who ran guix pull during the breakage only, right? <nckx>roptat: To add more to the topic I need to cut something :) <nckx>It shouldn't stay up for long. <euandreh>nckx: I'm already used to adding --allow-downgrades, due do doing git push -f frequently on a personal channel XD <nckx>euandreh: Ssh, I use it every time, but I Know What I'm Doing (I Do Not). <lle-bout>nckx: maybe we should have more granular --allow-downgrades <nckx>lle-bout: --allow-downgrades=<commit> ? Right now it is a needlessly racy thing. <nckx>Noisytoot: Only with --allow-downgrades, I hope? <nckx>Otherwise we have another more serious fun bug. <nckx>I had already pulled the bad commit, you sane people hadn't. ***nckx changes topic to 'GNU Guix | get Guix at https://guix.gnu.org | videos: https://guix.gnu.org/blog/tags/talks/ | bugs & patches: https://issues.guix.gnu.org | paste: https://paste.gnome.org/ | Guix in high-performance computing: https://hpc.guix.info | This channel's logged: https://logs.guix.gnu.org'
<euandreh>I'll try "guix import go -r terraform" later today! *lle-bout runs M-x cve-squashing-robot-mode <lle-bout>It's just I've been doing very repetitive task of patching CVEs in GNU Guix since last few days and I'm again back at it. <roptat>no idea what 3mf is, so it's hard to say <lle-bout>roptat: apparently it's a 3D model standard and lib3mf is the reference impl, it's used by openscad <lle-bout>I am updating lib3mf to fix security issues and it seems they added support for this "Secure Content Extension" in the more recent version <lle-bout>roptat: it isnt but the name of the standard kind of.. smelled like it. <lle-bout>"Ensuring end-to-end encryption from producer to device for privacy sensitive information (like medical patient data)" <roptat>if it's just encryption, then it's fine, if it's encryption + so weird permission model, then it's maybe not fine <lle-bout>"Obeying Governmental regulations for production data (like ITAR or GDPR)" <lle-bout>"Digital Asset Security applications in Industry 4.0 environments" <lle-bout>"Secure Archiving of Print Data in untrusted environments (like Cloud Storage) without the risk of content leakage." <roptat>probably, apart from point 3, it sounds legitimate (I don't understand point 3) <lle-bout>It looks very bullshit indeed, if one wants content protection then just share like 7z archives with AES encryption, don't know <nckx>bullshit = content leakage, to be fair. *nckx just rolls eyes at the buzzwords. <lle-bout>Noisytoot: yes but maybe less user-friendly <dongcarl>mbakke: Do you remember what prompted you to write qtbase-moc-ignore-gcc-macro.patch? Did you post an issue? <lle-bout>roptat: It looks like a public/private encryption scheme like you can create 3D files encrypted for certain public keys <roptat>lle-bout, that's what it looks like to me too <lle-bout>roptat: yes I think too, let's update it. <Noisytoot>Why did Guix decide to use IPFS instead of GNUnet for distribution of substitutes? <rekado>Noisytoot: Guix didn’t decide that. <lle-bout>Noisytoot: GNU Guix didnt decide much, it's whoever implements something first at this point. Also GNUnet isnt as mature of a software and big of a network I think. <rekado>Noisytoot: we wanted to use GNUnet before we became aware of IPFS, but the Guile bindings for GNUnet (a GSoC project IIRC) didn’t progress enough to be useful, and GNUnet took a *very* long time to be unbroken between releases. <rekado>GNUnet didn’t make a new release but requested that older releases not be used. <rekado>not very encouraging; and then IPFS came along: it actually worked, and the developers actively engaged with us to get things going. <rekado>that doesn’t mean there won’t even be substitute distribution over GNUnet. <rekado>the next step for that to happen would be to update the Guile bindings for GNUnet. <rekado>the commit history does not look very encouraging <rekado>(it seems rude to me to squash other people’s commits.) <rekado>it looks fine in ungoogled-chromium <nckx>It looks fine in IceCat 78.3.0esr. <nckx>Literal octocats or whatever it's called. <lle-bout>Why do these font issues happen in IceCat specially? <lle-bout>I wonder why we package docker/engine instead of moby/moby <cbaines>the docker packaging was done before the moby arrived I believe <lle-bout>I can't say for sure that every known security issue is fixed there <lle-bout>moby/moby has newer versions that docker/engine doesnt have <Noisytoot>rekado: I fixed it by copying the necessary fonts to ~/.local/share/fonts, and then running fc-cache -rv, but that is non-optimal <lle-bout>I don't have that issue and never had to copy fonts around *lle-bout installs their fonts using system configuration *Noisytoot runs a foreign distro, and can't do that <nckx>Noisytoot: I guessed cosm(etic comm)it. <nckx>And TODO++ = add to TODO. <nckx>It makes me grateful for GNU/Guix's format at least. <mbakke>dongcarl: there is some information in the linked bug report, any package invoking 'moc' at build time failed (qgpgme and a couple others) <nckx>A random Linux experiment. ***sturm1 is now known as sturm
***sturm is now known as Guest4039
<dongcarl>mbakke: Interesting. It just fixed a long-standing problem for me, so thanks! <mbakke>dongcarl: cool, you're welcome :-) <lle-bout>I just learned about "git add -i" partial file staging, awesome! ***Guest4039 is now known as sturm__
<lle-bout>I call for testing of the just updated containerd and docker paackages <pkill9>TIL of bindfs, mount --bind as user