<cdegroot>Am I missing something obvious? I want to hack on guix, so I add `use guix guix` to my `.envrc`, `direnv allow`, stuff happens, `./bootstrap` and then `./configure` - which complains that guild isn't there, but direnv added the store with guile (including guild) neatly at the front of my path etc.
<cdegroot>Hmm... adding --pure solves it. I wonder why less software makes configure find more...
<flatwhatson>Maybe it's calling system pkg-config, which is finding system guile? I'm reasonably sure it doesn't use PATH to find guile.
<cdegroot>Ah, good one. I'm closely "strangling" my Ubuntu host, removing dev tools, but I keep missing stuff :)
<cdegroot>Yup. Guess what - "nvidia-settings" on Ubuntu pulls in "pkg-config". No clue why. Good riddance of both. Next.
<flatwhatson>Though `guix environment guix` prefers guix's pkg-config and sets PKG_CONFIG_PATH for me...
<flatwhatson>I've had a much easier time just using pure environments for development anyway. Using a manifest to create the environment gives you a place to define any unpackaged deps, and gives a lot of flexibility for testing different dependency versions, not to mention eliminating host system leakage.
<cdegroot>Yeah, I just need to figure out what I need extra in a pure env (with Emacs wanting external tools like ripgrep). I'll get there - thanks for pointing me in the right direction.
<pkill9>i like guix, but it's a problem that it requires an internet connection just to roll back the system
<cdegroot>I'm on rural WISP. I know the internet connection pain :P
<flatwhatson>cdegroot: I run emacs from outside the environment, and use the envrc package so each buffer gets the proper environment.
<cdegroot>(ah... what tripped up configure was the guile package on the system; without it it works better)
<cdegroot>Yeah, with direnv Emacs (which I start from the Gnome shell) seems to not find ripgrep, for example. Project-wide search with ripgrep is nice.
<flatwhatson>cdegroot: Right, but what I'm saying is you don't need to install ripgrep in the pure environment. Launch emacs outside the pure environment (where it can find your regular ripgrep), then envrc-mode will load the pure environment *per buffer*, and you get the best of both.
<cdegroot>I hoped that that would happen, but apparently not. Oh well... Stuff's working "impure" now I apt-removed guile.
<cdegroot>Heh. Wanted to see what's needed to add mDNS discovery of my local substitute servers, just learned that guix-daemon is C++. Probably gonna be a bit more tricky than I thought.
<flatwhatson>cdegroot: Ah, right, I can reproduce your problem. Guess I don't use 'SPC s p' much so didn't notice!
<flatwhatson>Likewise for magit without git in the environment. Hmm.
<cdegroot>totally different question - one of the packages I want to hammer under Guix control is .NET Core 3.1. Is that considered free software? IOW, in the unlikely case that I manage to define a package, should I submit it to Guix? Don't ask why I want it, please :P
<cdegroot>Now if i only can get it to build. Apparently it's using the dotnet git library, which is an old one that wants OpenSSL 1.0, to pull more deps. Nice puzzle but I'm giving up for the night lol.
<sneek>Welcome back lle-bout, you have 2 messages!
<sneek>lle-bout, flatwhatson says: I've heard minor rumblings about guix vs tramp paths, but don't use it myself and haven't had any proper reports. Happy to help investigate, either here or as a github issue. It's possibly a regression of guix vs master, not specifically related to native-comp.
<marusich>I have a suspicion, but I do not think it is worth worrying too much about, personally.
<lle-bout>cbaines: hello! :-D - is the list all changed derivations why would they change?
<lle-bout>marusich: yes probably, as long as not >300
<marusich>I suspect that changes to syscalls.scm may have somehow propagated into the output of the module-import-compiled derivations, which I believe build the compiled .go files that make various modules (like (guix build syscalls)) available to guile builders when executing other derivations.
<marusich>It appears to be about 500 packages, based on cbaines' output, so it doesn't seem egregious. I would argue that it is better to merge this for the relase and rebuild those ~500 packages, than to postpone making it easier for people to hop in and try out / help out with the powerpc64le-linux port.
<marusich>I have to run, but that's something to consider.
<lle-bout>FossGuy[m]: A GNU/Linux distribution is what you make it, Nix needs contributors like GNU Guix :-) - If nothing's keeping you to GNU Guix, then go to Nix that's OK, there's even a nix-service-type in GNU Guix.
<lle-bout>FossGuy[m]: and adb is not *missing*, it's there just not latest
<lle-bout>It's been working with my Android phone quite fine
<FossGuy[m]>Yes, but I need latest pkgs and and pkgs like element-desktop and kde apps are missing sadly
<FossGuy[m]>I like gux so far, but these are holding me back
<FossGuy[m]> * I like guix so far, but these are holding me back
<lle-bout>However, Element can be used on a web browser so, it's no real blocker here
***apteryx is now known as Guest64152
***apteryx_ is now known as apteryx
<rekado_>roptat: ping latency is not all that interesting, I think. I asked for ICMP to be enabled, because it is also used to negotiate packet size and a failure to accomplish that can lead to packet loss and reduced bandwidth
<rekado_>roptat: so I’m really interested to see if *download speed* has improved.
***DiffieHellman_ is now known as DiffieHellman
<efraim>There's also the option of using the nix service or flatpaks
<lle-bout>how can we efficiently apply a single patch series with a particular version?
<lle-bout>civodul: trying to make use of generic-html updater, I am thinking we might need some extensibility like provide an actual function in properties to match the URL of the new version, for the sqlite case it doesnt use normal version numbers in the tarball name
<efraim>I'm trying to use autoconf-wrapper with autoconf-2.13 but having a hard time with the syntax ((@@ (gnu packages autoconf) make-autoconf-wrapper) autoconf-2.13))
<efraim>yay typos. it's in autotools, not autoconf
<lle-bout>civodul: does adding the release-monitoring-url property automatically turns the generic-html updater on? I have a case where the generic-html updater should clearly work and it does not
<thorwil>hi! inkscape fails to start with: `gnu/store/g75q5v1gqi4x08qcf1ydfl9xhp4slmxy-inkscape-1.0.2/bin/.inkscape-real: error while loading shared libraries: libMagickCore-6.Q16.so.6: cannot open shared object file: No such file or directory`
<thorwil>is there room for some local issue, or must there be something wrong with packagaing?
<rekado_>thorwil: is LD_LIBRARY_PATH set, perhaps?
<thorwil>thank you rekado and lle-bout for looking into this!
<Ikosit>Hello! I'm trying to submit a few packages, but when I try to build them on another architechture with qemu, I get the following error: „while setting up the build environment: executing `/gnu/store/…-guile-2.0.14/bin/guile': No such file or directory“
<Ikosit>It doesn't matter if i use the installed guix or guix of my repo with ./pre-inst-env
<rekado_>Ikosit: are you using the qemu-binfmt-service-type to emulate other architectures?
<PurpleSym>The first one looks innocent, since we don’t support that arch. Can’t find a reason for the second one, which is a red flag for grafting imo.
<lle-bout>PurpleSym: thanks for digging the commits couldnt find where the soname was defined, the grafting may fail but since it's temporary and we have no other viable alternative for fixing the security issues promptly..
<lle-bout>It would be possible to maintain ABI without doing that
<PurpleSym>Well, “no reason” means it’s not safe to graft, because we don’t know for sure the ABI is still the same. Especially given their sloppy commit messages and version management.
<lle-bout>PurpleSym: but we must fix the security issues somehow so if not grafting I'm open to other solutions but not fixing the security issue does not sound good to me
<lle-bout>We have another option here: backport each fix to each security fix to the version we have, but that's lots of work since we have lots of different CVEs on this particular one, and most certainly I wont be able to do it with all the other work I would have to do, plus I don't think we should ever do that, not viable unless we have more people committed to creating such patches
<lle-bout>For now, even with SONAME changing, it doesnt seem to break backwards compat (maybe only forward compat), so it would work fine
<lle-bout>Let's see if thorwil comes back with some Inkscape issues
<thorwil>lle-bout: so far it works as before. stable, unless one does certain things with gradient meshes, but that’s an entirely different story :)
<lle-bout>thorwil: gradient meshes is that related to ImageMagick here or not?
<lle-bout>I try to do it the best I can, I may cut some corners because I don't feel like we can do it otherwise but I wont break anything blatently that's never been the case, I try to do rigorous testing of any graft I make
<lle-bout>+ request reviews when things are hard or non-trivial
<lle-bout>instead of core-updates, master, staging, etc?
<pkill9>and change in process of getitng code to users, in general
<lle-bout>pkill9: yes security, well the real problem now is making changes to core packages.. or grafts.. but if we can somehow pre-buffer changes so substitutes can be made and then push them to users once substitutes are available and deprecate the idea that frequent rebuilds should be avoided for non-substitute users (be it official substitute servers or unofficial), when IPFS/GnuNet substitute sharing and better reproducibility comes to play
<lle-bout>I also value building everything from source so it's not easy but I also think concerns that require building everything from source yourself can be mitigated by better reproducibility and distributed substitutes sharing.
<nckx>If yes: manifests are just package objects. They aren't lists of names, even though that's how they're most conveniently used. You can define your own packages in-line, including (package (inherit foo) ... (inputs `((...) ,@(package ))).
<nckx>rhou[m]: Yes. They are just Scheme files that must evaluate to (‘return’) a list of package objects. You can do whatever you want to get there. (use-modules), (define stuff), run your own crazy procedures, ....
<rhou[m]>or asked in another question: what is a sensible way to structure a development environment inside a manifest file to commited to git?
<rhou[m]><nckx "rhou: Not ignoring you, just can"> 😄 no worries
<i1l>sneek: later tell raghavgururajan i heard that Fedora keeps some captured (literal) Gnomes to work on Gnome. need to run, or Gnomes will catch me.. be careful. your packaging attempts have had drawn their attention..
<nckx>bone-baboon: However, if a [transitive] input of one link changes, such as mrustc's zlib, then it and all subsequent ones will be rebuilt. Your chain won't last a year, and probably not half one either (if core-updates ever gets merged ☺).
<notcompnotsci>okay cool. Well I guess my question is as simple as, what does a valid transformation from a git url look like for a package (I just get errors replicating the docs)? Then does that flag override the hash in the .scm file (since you are cloning from a different repo)?
<nckx>I can answer the last bit: yes, it must, because Guix sources are content-addressed.
<notcompnotsci>okay, next step is me trying to figure out why I have an "invalid Git URL replacement specification"
<sneek>raghavgururajan, i1l says: i heard that Fedora keeps some captured (literal) Gnomes to work on Gnome. need to run, or Gnomes will catch me.. be careful. your packaging attempts have had drawn their attention..
<tracerte>Is anyone having issues with unlocking luks devices as of a recent guix system update? On second prompting for my password during boot I receive a "No key available with this passphrase" response. If I rollback to my 3/10/21 no problem exists. http://paste.debian.net/1189875/
<vagrantc>nckx: it means i'll need to backport all security and important patches to guix 1.2.0 for the debian package ... the security updates could happen in a timely manner, but non-security things happen with less frequency
<vagrantc>hopefully any high severity patches remain reasonably backportable
<nckx>raghavgururajan: Oh, mail-style. I'm not sure that works on IRC. We tend to write ‘<shortest unambigious extract of line so much shorter than this stupid example> Lol never mind.’, on one line.
<nckx>It was mainly the multi-line thing that triggered my spamdar, sorry.
<vagrantc>guix's rolling release nature is a bit at odds with debian's workflow ... i had assumed guix-daemon wouldn't need to be patched regularly
<nckx>This particular fix should be easy to backport.
<Whyvn>I was finally able to succesfully guix pull --fallback, guix package -u, and then guix system reconfigure
<nckx>I think you need to actually provide ‘build’ (the package), which the libxsd build system expects to find in ./build-0.3, and has nothing to do with the existing ‘build’ directory which is just their own build script.
<nckx>I.e. ./build is not the bundled copy of build-0.3 you think it is.
<nckx>(Again, ‘I think’, because I'm resisting this one's gravitational pull and not diving in. Baroque NIH build systems FTW. \o/ )
<muradm>looking at java packages and have some issues with understanding, in java.scm there is for instance openjdk11-jdk and openjdk11 packages. then one with -jdk suffix is private, so it can't be used. but openjdk11 simply does not expose javac (i.e. java compiler). what is the intension of java packages, are they JRE (java runtime env) or JDK but packed incorrectly?
<nckx>If it's a default configuration in the same output directory as the package (I don't know if that's a great practice, but it happens), use a phase to add/patch it during build. If it's in /etc, you're describing a service. And guix-home-manager manages ~. What's left? :)
<nckx>(Not just /etc, of course, all ‘system’ locations besides /gnu/store.)
<charles`>it is where the package is installed so /gnu/store/jibjab/...
<jx96>leoprikler: In that case, I need to create a new package for the cargo crate?
<lfam>lle-bout: Regarding ImageMagick, it's less easy to test grafts since it is often used via a "command-line API". That is, not as a dynamically loaded library. This is also the main reason we haven't updated to the new release series, because it's really not easy to test.
<lfam>The series we use is fully supported upstream, but it would be nice to eventually update
<lfam>It wasn't very long ago that ImageMagick could be changed directly on our master branch, without grafting. I guess it grew some more dependents
<lfam>We might see about reducing the number of dependents, if some of them don't absolutely require imagemagick. It's a program that should only be used with untrusted input when the user is sure
<charles``>I made an iso image but when I made a virtual machine out of it, it didn't install guix. How to debug?
<lambdanon>Hi, I decided to change over from guix SD to debian on my laptop, and I've found that, even when I add the relevant guix profile sourcing to /etc/profile.d, xfce4-whiskermenu-plugin still didn't see my guix config
<roptat>trying to reconfigure after the vuln was published, and I get "no more space on device" at the grafting stage of a python variant... ungrafting is important!
<lambdanon>Currently trying to get my guix installed programs to show up in xfce-popup-whiskermenu. When I use the embedded command line in XFCE, and echo GUIX_PROFILE, it looks right, but whisker menu doesn't see any of the apps I installed through guix
<roptat>lambdanon, probably because it doesn't share the environment with the shell ;)
<roptat>there's a possibility that the program doesn't have a .desktop file too
<roptat>or that you need to reload the menu / the window manager
<roptat>basically, sourcing etc/profile in the shell only affects that shell, nothing outside of it
<lambdanon>I thought as much.... Just need to find how to to configure xfce's environment.
<lambdanon>I would've assumed that xfce's environment would've sourced /etc/profile
<roptat>first, I'd check that the program actually has a .desktop
<lfam>Shall I email a notification to each of the committer, CC-ing guix-maintainers?
<nckx>Oh... ‘Exploitation is more difficult, but not impossible, on machines [with protected_hardlinks].’ I'd like to push a parallel change to (etc news) to reflect that unfortunate fact, but is it safe (not to mention moral) to retroactively do so?
<nckx>‘Well, nobody is affected after they pull’ - That's not true either.
<pinoaffe>nckx: if you're in a student town digging through that university's ewaste might be worthwhile
<nckx>They aren't affected after they reconfigure.
<Ikosit>Is it possible to use a layout from kbd with the operating systems keyboard-layout field?
<nckx>lfam: <The mistake is in describing the past, not the current reality> Not necessarily.
<pinoaffe>nckx: the physics, astronomy and chemistry departments o'er here (leiden, the netherlands) throw out some great stuff, from hard drives and thermal cameras to consumer electronics, entire test setups and on one occasion even a mass spectrometer
<lfam>I can send the message to oss-sec. Will someone else update the news.scm and the blog post?
<Ikosit>Would it be possible to let the keyboard-layout field of the os record recognize a string or an keyboard-layout specification? In the first case it would use a keyboard layout from kbd and in the second it would convert a layout from xkeyboard-config. Or would that complicate the record too much?
<PotentialUser-52>lfam: I didn't notice a breaking change incoming. Maybe I just did not see it in the news items where I would have expected it (even though I thought I've read everything). Or maybe it was announced way back when I didn't yet use guix. I now changed my config accordingly and it says "guix system: error: more than one target service of type 'udev'"