<mbakke>janneke: do you expect more low-level changes for Hurd, or can we merge the full-rebuild bits and start working on merging core-updates?
<janneke>thanks! i've been "playing" with cross_cplus_include_path for wxwidgets, but the real understanding is still missing here...i'm in the "it works!" phase (esp. re -system vs -I, cross_, cpath, not easy!)
<janneke>mbakke: i am not planning more low-level changes; the lowest level that i have pending is commenting-out failing tests for guile on the Hurd
<janneke>current wip-hurd should be a nice basis to do initial hurd system image devolopment on, i think
<mbakke>janneke: right, I suppose that change can be "spliced" so it does not affect other architectures
<civodul>janneke: BTW, if there are changes we can apply in Guile proper, lemme know!
<guix-vits>raghavgururajan: when i'd seen delta-updates in Fedora, they were the less efficient the less frequently i'd updates installed (less than %5 traffic difference, usually). But for frequent updates, idk.
<janneke>ah, and my emacs-guix uses guile-2.2 -- i finally see some errors; that helps
<janneke>there was a talk on lp about "sugar" the desktop environment (distro?) that incubated in olpc; and i learned they have something like "show-lossage" for everything -- kinda alike why i love exwm so much except when i need to use a gui/browser
<mbakke>it probably does not make sense to update %guile-static on master, because I get "incompatibly bytecode" warnings during boot on core-updates due to the Guile version mismatch
<mbakke>janneke: what do you mean by "show-lossage"?
<janneke>mbakke: ah, apparently i meant: M-x view-lossage; i.e. the promis of reading back the program you wrote/are writing while interacting with your computer
<janneke>and then, of course, modifying and parameterizing it
<mbakke>janneke: huh, neat, didn't know about view-lossage, sounds like a nice feature for a DE
<janneke>yes, it seems to me that would be where you /start/ (next to integrating an interpreter; sugar chose python but yeah)
<janneke>i'm not sure how we'd get there (Guix 2.0); exwm is nice, guile-wm might be nice -- the most pressing problem seems browsers (possibly non-emacs shell terminals?) but possibly nomad can help out (str1ngs?)
<mbakke>arf, guile-linux-syscalls.patch applies on 3.0, but breaks pretty bad. I'm not enough of a Guile/C hacker to fix it. :-/
<guix-vits>(nomad) "Couldn't connect to DBus for name org.gnu.nomad.webview" -- do i need some service running?
<janneke>mbakke: on wip-hurd, i have patch that /reverts/ %guile-static to 2.0...
<janneke>yeah, the build starts for me; fails in configure
<andydarcyjewell>janneke: the script goes off and checks for utilities existing, and also downloads some dependencies (but not all)
<lapinot>nckx: i remember doing `guix pull` and it working, but then i tried `guix package -u cryptsetup` but i didn't do anything. Actually i think i more or less understand the guix concepts (from reading the manual), but now if there's a simple tutorial/cheatsheet lying around that would be awesome
<andydarcyjewell>guix-vits: if I can do that, the I'll be happy, but it (build.sh) pulls in sources from outside of the guix ecosystem
<mbakke>andydarcyjewell: there is no network access inside the build container, so you'll likely have to do it the "hard way"
<andydarcyjewell>janneke: I don't think it's too old, as it's a fresh install from last week, with substitutes
<mbakke>janneke: I found it difficult to parse some of the (if (member (or ...))) lines, could you add the (package-supported-systems) clause on a line of its own instead of trailing the second argument to OR?
<brendyyn>civodul: meet.jit.si is good i think. your work can simply click a link that will work best in their google chrome. since it uses urls you could even set up your own node and use that, they will be none the wiser
<mbakke>andydarcyjewell: the last line should just be 'factor' without parens
<andydarcyjewell>is there a way to stop patch-source-shebangs from trying to patch bogus shebangs in the factor source? I'm seeing errors like this: patch-shebang: ./unmaintained/lambda/lambda.factor: warning: no binary for interpreter `An' found in $PATH
<mbakke>andydarcyjewell: you can safely ignore those warnings
<andydarcyjewell>mbakke: well, not if it actually patches a factor source file accidentally
<abralek>I build guix today in guix environment guix and got this zsh: /home/aabramov/.config/guix/current/bin/guix: bad interpreter: /gnu/store/0awhym5h0m890n0wq87y0dxznh14rk88-guile-next-3.0.1/bin/guile: no such file or directory
<nckx>lapinot: ‘guix install cryptsetup’ would probably have worked. On the installer all packages are ‘system packages’ (taken from the system .scm) which you can't upgrade using ‘guix package -u’, but you can install your own copy which takes precedence.
<abralek>execve("/gnu/store/0awhym5h0m890n0wq87y0dxznh14rk88-guile-next-3.0.1/bin/guile", ["/gnu/store/0awhym5h0m890n0wq87y0dxznh14rk88-guile-next-3.0.1/bin/guile"], 0x7fff3fe63cd8 /* 99 vars */) = -1 ENOENT (No such file or directory)
<mbakke>maybe AppArmor made some of these libraries invisible to 'guix gc'?
<mbakke>hopefully there are other Ubuntu users around here who can chime in if some special care needs to be taken
<marmulak>hmm apparently the .desktop files that appear in my gnome launcher do this thing where if I pin them to favorites, and then launch them, the window that opens doesn't show as belonging to that app but showing up as a separate item
<marmulak>so chromium could open from the launcher but then the launcher shows two chromiums
<guix-vits>marmulak: i'd seen something similar (before followed twohot and switched to sway); can you test this with KDE (it has window-list on the panel) or the other something?
<nckx>I use Guix on (someone else's) Ubuntu machine (19.10 I believe) and have never had any such weirdness.
<marmulak>guix-vits: I can, I'll need some time to install KDE on this sytem
<abralek>nckx: Me too actually, but this is the second time I get this.
<marmulak>for now the most obvious thing I see right now is that the launcher calls the app "Chromium" (the titles shows when I hover over), but when launched the resulting window is labeled "Chromium-browser" so it probably thinks they're different programs for having different names or titles somehow
<nckx>I don't use or GC it often, I'll try that. Have to wait for them to switch it on so I can SSH into it though 🙂
<str1ngs>janneke: I did not know about view-lossage. but this would be a good feature for emacsy I think. my guess is this does not exist right now. baring that you can script with nomad but that's not the same as view-lossage in terms of recording a session.
*raghavgururajan requests to consider XMPP over Matrix
<str1ngs>janneke: also with nomad I've added limited support for browser extensions. not to be confused with browser plugins. so theoretically in the future nomad should better support DOM introspection. so say using something like view-lossage you could do form automation etc.
<str1ngs>guix-vits: I can't replicate your error. have you tried starting nomad with a new terminal. assuming you just installed nomad
<mbakke>raghavgururajan: intesting... however AFAICT the issues raised there are present on pretty much XMPP server you'll find in the wild, too.
<guix-vits>str1ngs: same error in another tty with sway; but i'm using `guix environment --ad-hoc nomad -- nomad` with and without --pure. Also a week ago i'd tried to install it. Probably i miss some service running.
<str1ngs>guix-vits: ahh that makes more sense. nomad had some experimental support for dbus which is probably not available with your session. nomad from git probably won't suffer from this issue.
<mbakke>raghavgururajan: the person who wrote that document has nothing else on their github, and is working for a company that appears to sell competing solutions
<nckx>raghavgururajan: That person is certainly doing their best to shoot their own message in the foot by being an insufferable tool, but maybe they're right. Are you simply recommending [m]-folks here consider XMPP, or that Guix should do something? AFAIK we don't recommend Matrix anywhere. Our on-ramp for newbies is Web IRC.
<nckx>I'm also sceptical of the security of the average XMPP implementation/deployment in practice.
*vagrantc runs xmpp on a device with dubious security but sort of respecting user freedoms
<guix-vits>str1ngs: as i'd seen the "patching shebang" line, i'm assume that this is webkit2gtk compiling now.
<nckx>Not a dig at XMPP by the way. It's almost 20 years old.
<vagrantc>i like that xmpp has good multi-platform support and reasonbly good end-to-end encryption options
<vagrantc>and interfaces that many not-highly-techie people might actually use
<str1ngs>guix-vits: hmm wibkitgtk2 should have a substitute. are you using substitutes?
<jsoo_>can i use emacs-minimal if i only use terminal emacs?
<str1ngs>guix-vits: oh one sec, what branch are you on webkitgtk-unstable should not be needed now
<str1ngs>guix-vits: ahh sorry use feature-windows. I need to merge that into feature-g-golf
<guix-vits>str1ngs: it'd builded to 50%, or should i cancel it?
<str1ngs>guix-vits: cancel it's not worth building since guix proper has webkitgtk 2.28 now
<mroh>for fixing https://bugs.gnu.org/40015 (which was reported from a female, so i picked that one), I updated docker-compose to 1.25.4. should I send the patch to 40015@debbugs or guix-patches (for a new issue/bug) or (i guess) to both?
<bricewge>mroh: Send an email to guix-patches and insert a link to the bug you fixed in your commit.
<efraim>I think I found a good vim commit, just want to test it again
<mbakke>efraim: is vim really so fragile that it breaks on different architectures with every other version?
<nckx>More personally: S-V isn't the kind of ‘Y-V + feature foo’ fork that I'd use inheritance for. They're separate projects that are already drifting apart. But if the author starts cross-porting patches, sure, maybe. Let's see if Y-V even survives.
<bavier`>nckx: hmm.. I'm looking closer now at the inputs and arguments and realize they're *slightly* different
<mroh>mbakke: yes, it is, i have seen these kind problems also in gentoo and debian/sid
<bavier`>btw, how much more work is needed for the S-V gtk gui?
<nckx>bavier`: If you really think it adds value go for it. I'm going to maintain Guix's S-V going forward but have no interest in cross-checking with Y-V development every time to find out what the ‘right place’ to add new inputs is, though.
<nckx>bavier`: Package Perl's GTK module to find out 🙂
<nckx>I was quite suprised that we don't have it yet.
<bavier`>nckx: I agree with you on maintaining s-v going forward; the api-key issue in y-v makes it a hard-sell for maintenance
<bavier`>I was hoping another os project would create a "public" api key we could use.
<efraim>mbakke: sometimes. We've also had a string of bad luck with versions not working on all the architectures
<nckx>bavier`: That's exactly what I did for NixOS in days bygone, but that's exactly what Google's cracking down on now. They sent me some mails about that old key and this <https://stackoverflow.com/a/60264537> is exactly their attitude. It's not worth it, and asking a random Guixer/community member to sacrifice their freedom seems, while very rms, wrong.
<mbakke>is there a git command to grep ALL the branches at once? :P
<nckx>Are push notifications those super-annoying ‘Would you like randomnewssiteyouclickedonfromddg to show notifications?’ things? Because I've never seen them on IceCat. And I'm sure they haven't just gone away.
<apteryx>nckx: yes, they tend to be annoyed; I used to see them before the 62 or 64 releases IIRC.
<NieDzejkob>my paraphrasing is not exactly accurate when I've been fighting bugs for too long
<sirgazil>Veera: I think https://guix.gnu.org/videos/ is a good way to get started with guix and packaging. And it has an example of packaging R packages, which may be relevant for your contribution period.
<nckx>It's just that the contents are, apparently, inaccurate.
<nckx>Veera: Not better, not worse, just the usual trade-off. --pure gives you tighter control over what's in the environment, at the cost of having to add every single dependency you might need (bash, coreutils, <random tool you forget you use>, …) which are otherwise inherited from your normal environment.
<alextee[m]>yeah seems pretty basic, thanks for the advice :-)
<str1ngs>alextee[m]: basically you add a token and then you substitute the token for the full path. ie in script.in you woudl add GSETTINGS_SCHEMA_DIR=@DATADIR@ . then you substiute that with PREFIX/share
<str1ngs>alextee[m]: script.in will generate script . generally you can just use sed for this
<alextee[m]>str1ngs: oh okay, yeah i was planning on doing that
<alextee[m]>it's pretty trivial to do with meson. it has configure_file where you pass a hash of things to replace, and an input/output file
<str1ngs>it's easier to do this with autotools and AC_CONFIG_FILES. so you'll have to figure out the meson way
<nckx>Like str1ngs said you *could* use Guix substitution to do this, but a lot of work has gone into making standards-conforming packages ‘just work’ on Guix. And they'll work on all other distros too. The ones that break are the ones that make assumptions like ‘$sysconfdir is always in $prefix’. Noes. Don't.
<nckx>str1ngs: Absolutely, that's the [sane] default. With Guix it's sometimes easier to set sysconfdir to something wildly different (vs. patching the makefile to not install example config files, for instance) and it's a pain if that breaks because ‘why would you do that I am clever package uwu’.
<str1ngs>generally though you want a uniform disto share directory due to XDG_DATA_DIRS
<str1ngs>but guix does not count here of course :P
<alextee[m]>XDG_DATA_DIRS is the reason i have to do this hack btw lol
<str1ngs>I wonder why GTK moved from autotools to meson. I kinda feel haveing so many build systems seems so NIH
<alextee[m]>i was using autotools before too, meson is such a breeze to work with
<alextee[m]>everything is so simple and easy and makes you do the right thing
<alextee[m]>actually it was the GTK people that made me switch to meson lol
<alextee[m]>also makes it easier to switch later on if you already use free software
<daviid>fwiw, I use msys2 (when I have to port something for win users), which provides the right 'settings' to compile/use 64bits app/libs. It has a complete autotoolchain and guile 2.2.6, with posix support (for what it can support) which includes threads