<wdkrnls>I just looked at the dmenu_path script to focus on stest <roptat>ok, from a guix environment, dmenu_path lists lots of binaries <NieDzejkob>hmm, I'm getting this error when running alsamixer: ALSA lib dlmisc.c:285:(snd_dlobj_cache_get0) Cannot open shared library /gnu/store/f9ywcwdyg39hhjjcf88br8h0f7hspxwa-alsa-plugins-1.1.9-pulseaudio/lib/alsa-lib/libasound_module_ctl_pulse.so ((null): /gnu/store/f9ywcwdyg39hhjjcf88br8h0f7hspxwa-alsa-plugins-1.1.9-pulseaudio/lib/alsa-lib/libasound_module_ctl_pulse.so: cannot open shared object file: No such file or directory) <wdkrnls>I just tried to run $(guix environment --ad-hoc dmenu) and saw the same issue, but maybe I need to add an additional package to give me ls and such. <wdkrnls>I was impressed how you found out which package owned a file. <wdkrnls>I know I could do that from pacman, but didn't think that functionality was built into guix yet. <wdkrnls>I guess through finding it in the store <drakonis>that's a relatively decent rate of commits <mehlon>it's... over a certain large amount...!! <mehlon>what, 2^13? there's no way that can be right! <drakonis>where they get a thousand commits a week <drakonis>the scariest part is that they're at nearly 2000 open pull requests <drakonis>and they can never go below it, its like a monkey's paw wish <mehlon>to be fair, half of those commits are "merge pull request" <mehlon>I guess they didnt figure out how at first and now they dont want to just break the pattern <mehlon>I think rebase-merging is rebasing (setting the patch parent to HEAD) and then committing it directly <mehlon>oh, also rebase can squash together multiple commits into a single commit <leoprikler>It lets you drop evil commits of your past, rewrite messages in a nice format, and so on and so forth. <leoprikler>Plus it's better to iteratively resolve merge conflicts in my experience. <mehlon>ludovic made some patches but I think they're not done yet <leoprikler>there are timeouts in the CI so that packages don't build endlessly <kirisime>NieDzejkob: I've seen the odd cutoff too, on packages that at the time failed to build for me too. <mehlon>I guess you can try guix build python2-django-rq -s i686-linux <mehlon>I was going to but I dont want to wait to download all the deps <pat_h>NieDzejkob I'll give it a shot when I get a chance but it might be an issue specific to your system. What kind of machine are you using and what does the build log say? <NieDzejkob>it's x86_64, IIRC some process aborts during the install phase <pat_h>Can you copy the text from the log? <pat_h>Perhaps there is a fix necessary <pat_h>This super recent one (just finished basically) succeeded though, maybe `guix pull` and then retry the build after the associated commit is in master *mjw learns about qemu-binfmt-service-type <mjw>amazing... guix build --system=aarch64-linux ... it is super slow, but it just works... <mjw>ok, some of my ptrace tricks don't work, but I guess that is expected. Pretty cool though. <mjw>good night hackers. /me dreaming about virtual arches <roptat>NieDzejkob, I built racket without any issue from a guix from january 8 <roptat>drakonis, they're doing maintenance, it will take some time <roptat>there was a warning for a few days on framagit already :) they're doing some maintenance that will take a long time (at least 12 hours) <roptat>it started 7 hours ago, so at least 5 more hours to wait before they're back online <drakonis>was doing a pull and home-manager was unavailable <drakonis>you're the developer of home-manager aren't you? <roptat>home-manager is a channel that adds a new guix home command *raghav-gururajan --> Zzz. Bye Guix! <roptat>it makes your home a profile, so you can manage your configuration with guix, have roll-backs, etc <roptat>but it also means your home is read-only, which is not always very practical ^^' <drakonis>ah, regarding the issues with pulseaudio and read only home directories, it'd be worth a shot to replace it with pipewire <vagrantc>the entirety of your user homedir is read-only with home-manager? <drakonis>it can act as a drop-in replacement for pulseaudio <roptat>you can "punch holes" in your home for software that's not supported, as well as for xdg directories (.cache and .local) <drakonis>"If you want to run PipeWire without installing it on your system, there is a script that you can run. This puts you in an environment in which PipeWire can be run from the build directory, and ALSA, PulseAudio and JACK applications will use the PipeWire emulation libraries automatically in this environment." *raghav-gururajan now really goes to Zzz. <roptat>ok, that's definetly something I should consider :) <drakonis>have all pulseaudio consumers default to pipewire, worth an experiment <drakonis>i can't wait to see ambrevar's fosdem talk, as it appears he's taking on adding package metadata for customization and tagging <roptat>atw, you could try to set "security.sandbox.content.read_path_whitelist" to "/gnu/store/" in about:config and restart icecat <roptat>atw, you can comment by sending an email to 38670@debbugs.gnu.org <roptat>try to keep the subject line too <atw>thanks on both counts! my uncertainty about debbugs was if anyone would notice comments on a closed issue. I'll do as you say in the future <drakonis>ohhhh it works with "/gnu/store/" but not "/gnu/store" <roptat>/gnu/store means the file, /gnu/store/ means the directory, recursively <atw>+1, that option works for me too :) <roptat>so now we know what option should be there by default <roptat>but I have no idea how to set it <drakonis>the icecat shell script shows how to set options by default <atw>that was gonna be my next question: "is it possible to do this OotB?" :P <roptat>can you come up with a patch? I'll try something tomorrow otherwise <drakonis>actually, now i'm curious about how nix avoids this issue <efraim>where is the keyring that make authenticate uses? <vagrantc> ~/.config/guix/keyrings/channels/guix.kbx <vagrantc>it downloads the individual keys from the unreliable keyserver network :/ <vagrantc>i manually had to add some keys: gpg --no-default-keyring --keyring ~/.config/guix/keyrings/channels/guix.kbx --import ~/guix-keyring.gpg <vagrantc>efraim: which you apparently replied to :) <efraim>I remember now :) I was getting more unknown key errors <vagrantc>seems like it's high time to package guix-keyring ... *vagrantc could then upload it to Debian :) <efraim>i have a lazy package for it that I never get around to updating <vagrantc>yeah, i thought i recalled something like that <str1ngs>efraim: question. I'm just about to post a patch for python-pyqtwebengine and an upgraded qutebrowser with qtwebengine supp port. can python-pyqtwebengine go in qt.scm or is should it go in a python module instead? <efraim>qt.scm is probably a good choice. Assuming no issues it's probably better than python-web.scm <str1ngs>efraim: I thought so too. thanks for the feedback <str1ngs>efraim: also I did not create a qutebrowser-qtwebengine. which was my initial thought. becuase qtwekit is not recommened even by the author of qutebrowser. so I think it's better to just upgrade qutebrowser and have it use qtwebengine. I'm just worried about the impact for existing qutebrowser users. WDYT? <efraim>I'd go ahead and change it to qtwebengine. We don't want out of date web browsers <alextee[m]>can the results of guix pack be placed on a USB and the program used "live"? <g_bor[m]>I've sent a new blog draft for the Outreachy post. ***ng0_ is now known as ng0
<kmicu>Not people but a conda user uses confirmation bias to justify their choices. :) *kmicu replaces ‘docker’ term with ‘bucket’ in such discussions and some folks really like to put everything in buckets and call it reproducible. ‘Look! It’s in a bucket!’. <efraim>sounds like the cloud->butt browser addon <civodul>alextee: sure! well, it's not bootable, but yeah <civodul>g_bor[m]: i'll take a look, but anyhow, if it has all the info, you can feel free to push in a few hours <g_bor[m]>I will try to find out what is going on with the installer failure in the mean while. <g_bor[m]>I believe we could do an additional layer of abstraction instead, and move functionality out from the newt part of the instller, leaving onyl the ui stuff there. <kmicu>git rev-list --count --branches ^refs/tags/v1.0.1 → 9343 … my git is clearly drunk <g_bor[m]>that way the ui, the test driver and possible a pre-seeded installer can all be the clients of the same backend. <civodul>g_bor[m]: re testing, we could, but i'm looking for a simple solution that can be quickly implemented :-) <civodul>g_bor[m]: re the 'guix substitute' error that you see: i'd expect to also happen in other contexts, outside of the installer <g_bor[m]>in the report there is a simple gexp that triggers it. <civodul>so it happens outside of the installer too? <civodul>i mean, without the relatively complex setup you described? <str1ngs>g_bor[m] hello, I have recently been working on making UI in nomad generic. currently it supports GTK but I've started to con cider ncurses as well. it's possible with your ideas here we could potentially create a graphical installer as well. <g_bor[m]>nckx had the idea to see if guix build guix triggers it. <g_bor[m]>civodul: you can trigger the error using guix build guix in the installer image. I will see if this also outside <g_bor[m]>still, it is working if you run it again... <civodul>g_bor[m]: can you try "rm -rf /var/guix/substitute/ && guix build guix"? <str1ngs>civodul is there an easier way to invalidate the substitute cache? <civodul>str1ngs: nope, but you normally don't need to worry about that <civodul>does it happen also with a "normal" setup, i.e., not in that VM? <str1ngs>civodul I tend only need it when I'm testing a publish server. so that makes sense. I'm fine with rm -rf was just curious. <g_bor[m]>civodul: I could not reproduce it on my dev machine. <g_bor[m]>but I don't have a bare metal to test on right now. <g_bor[m]>I was trying to find a way to trigger this faster tha builing an installer iso, but I failed so far. <deploy-user>Heya, I'm trying to build a guix deploy proof of concept for Hetzner VPS, but am stumbling at what seems the last hurdle: Initial "infection" works well, but when running the guix deploy command GSSH errors out because the SSH session is already closed when guix deploy tries to remote eval against it. Anyone run into something similar? <civodul>hi deploy-user, i haven't experience anything like that <civodul>would be good to see if it's the server that closed the SSH session prematurely, and why, or if it's a bug on the client side <str1ngs>deploy-user: is the remote machine a foreign distro? <deploy-user>It was a debian-10 distro. I ran a modified infect-network script from the digital-ocean module on it to turn it into a guix deployment. <str1ngs>okay that's good then. I notice with foreign distros and offloading you need to provide a PATH to guix <str1ngs>unfortunately I have not used deploy just offloading which I think is similar concepts. but maybe someone else knows more <str1ngs>deploy-user: what I do with offloading is test something like this. ssh <remote> guix describe <str1ngs>that could give an indicator of why the connection is closing <deploy-user>SSH asked me to confirm the fingerprint, then guix describe ran ok (though emitted an error because it's still a 1.0.1 version of guix pull). I'm pulling to a later version now, just in case. <str1ngs>deploy-user: also try with ssh <remote> guix repl --version to see if the repl is working <deploy-user>civodul: I'd be happy to try to figure this out, but how would I go about doing this? Is there a convenient way to override the deploy code only on the client for instance? <deploy-user>str1ngs: reconfigure just completed, so will do now! <deploy-user>hmm… after guix pull and reconfigure guix describe and repl went from 1.0.0.1 to 1.0.0 … seem to be going backwards, not forwards? <str1ngs>deploy-user: what about ssh <remote> which -a guix <str1ngs>deploy-user: try with ssh orion .config/guix/current/bin/guix repl --version <deploy-user>So that suggests the PATH env needs to be set… in… profile? <str1ngs>because these are non interactive shells you might need to add ~/.config/guix/current/bin to your path <str1ngs>check if your .bashrc is test for [[ $- != *i* ]] <str1ngs>though I think this should just work on a guix system. I've only had issues like this on foreign distros <str1ngs>unless you have a custom .bashrc or something <str1ngs>hmmm the skeleton .bashrc does check for interactive shell <deploy-user>Sourcing the guix profile skeleton (/etc/profile) as .bashrc for the user has fixed the path. It's now referencing the correct version of guix (under ~/.config/guix/current/bin/guix <deploy-user>OK — so the issue was a stray remaining ~/.bashrc, and missing guix skeleton profile, which caused the PATH env to not pick the right guix <deploy-user>Yeah, looking good now. Thanks for your help str1ngs! <kirisime>`guix environment --ad-hoc package' is quite a long way to say that I want to try out `package' before installing it. <civodul>g_bor[m]: do you know if other projects are already promoting their participation? <civodul>on a quick glance we seem to be the only ones <g_bor[m]>But I had the feeling that last time we were late. <g_bor[m]>There was a big change in the application process, and I was slow to adopt. <lxsameer>hey folks, for building graal vm from source, I need to download an specific version of jdk which i'm going to throw away after build. is it ok just to download it as part of build process ? <g_bor[m]>I believe we should do another round once the initial applications actually open. <civodul>but it's fine to be ahead of time :-) <civodul>yes, we could promote it some more at that time, if you want <NieDzejkob>lxsameer: It's not acceptable to download binaries in any way. I would create a separate package for this specific jdk. It's probably easy enough to do so with (inherit normal-jdk-package) <lxsameer>NieDzejkob: so compile a jvm from source to compile another jvm from source ? <mjw>civodul, will there be some session on guix (sub)packages, inputs, outputs, etc. goals at Guix Days. I like to get a better feeling for what the project as a whole expects. When updating elfutils I was proud that it comes with lots on new features, including a http client/server. But obviously one maintainers cool new feature is another packagers bloat nightmare :) <mjw>Also are people working on more consistent debug outputs? I am crying a little trying to debug anything on guix... <civodul>mjw: for the Guix Days, most topics will be proposed by participants as we go, so why not! <civodul>re debugging output, what kind of debugging are you referring to? <lxsameer>hey folks, i have a package which is written is python but doesn't follow the python packaging conventions (no setup.py and it's no on pypi) it only requires a certain python version and to install it it should be on the path <lxsameer>what should i use as the build-system for such a package ? <mjw>civodul, just that there is no debug for anything (well, almost anything). <mjw>civodul, well, it simply means if I run a debugger, tracer of profiler against anything build for or against libraries in guix I basically get not very far. I basically have to rebuild the world by hand. And that obviously doesn't help if the bug seems to be in the packaged binary, but not the one I build by hand... <civodul>mjw: oh you're talking about debug info of Guix *packages* <mjw>civodul, and it seems that because of reproducibility of builds this should be an easier thing for guix than for any other distro. Someone must have thought about this issue before. Is it just not enough CI/disk resources? <civodul>i thought you were talking about debugging traces for Guix itself <mjw>well, how to debug guile programs is also something I would like to learn *mjw being a guile noob means he gets obscure backtraces all the time that seem like they make my issue even worse :) <mjw>civodul, yes. I was wondering if that means this is a solved problem already, just needs some extra resources and then it all just works (tm) <mjw>and how come you can do anything without build-ids <mjw>I understand things are better/easier because the store in immutable, so you won't have the issue other distros have that running programs/libraries can disappear from disk. But not having core dumps with build-ids do seem to make things somewhat more difficult unless you are examining them on the actual running system themselves. <mjw>So having to teach each and every tool to use ~/.guix-profile/lib/debug seems less than ideal. Especially if you are debugging something that was running in a different profile. <mjw>But then, that might just me still being confused about environments and profiles *mjw might just show up at Guix Days and propose to talk all this through. I am just afraid I still don't have the right (guix) frame of mind to fully understand these issues. <civodul>mjw: separate debug info is used in most distros, i don't think Guix is doing something very different here <civodul>that said, it'd be great to have a talk/workshop by you on these topics, with a toolchain developer's viewpoint! <civodul>i'm sure there's room for improvement in these areas <NieDzejkob>lxsameer: everything on guix is built from source, tracing back to a few megabytes of root binaries. So if you need OpenJDK foo.bar to compile BazJVM, then you need to compile OpenJDK foo.bar from source <NieDzejkob>lxsameer: re: python, I'd use trivial-build-system <civodul>raghav-gururajan: could you make sure gnome-initial-setup and other packages you contributed really are "GPLv2-only"? they're very likely "GPLv2-or-later", so their 'license' field would need to be adjusted <mjw>civodul, I think there is actually great improvement possible, because of the reproducible guix deploy, it should be possible to do almost transparent "remote" debugging (where your debugging tools run outside your vm, container, remote system, etc. or examining a core file captured somewhere else). <civodul>mjw: oh right, sounds like there are opportunities for fun stuff :-) <civodul>note that currently GDB isn't quite happy when debugging a process that lives in a separate namespace <mjw>BTW. I was pretty impressed with how seamless qemu-binfmt-service-type works with guix build. <mjw>It is somewhat slow, but that is expected. <mjw>And some of the ptrace trickery I tried doesn't work. I should look into that. Because I think it can be made to work. <efraim>interesting thought: even if we could drop librsvg@2.46 (the rust version) in for librsvg@2.40 it would tie up many rust crates at their current versions and they couldn't be upgraded except in core-updates *efraim told bayfront to build gnome --with-inputs=librsvg@2.40=librsvg@2.46 <civodul>mjw: anyway if you want to give a talk or even better a workshop about the toolchain & Guix, that'd be great <efraim>of course we could just leave the vendored crates in place :/ <civodul>efraim: we could have several versions of the relevant crates <efraim>define rust-foo-0.2-core-updates <civodul>drakonis: there'll be few talks, the goal is to have interactive chat/hack sessions ***ng0_ is now known as ng0
<sirgazil>I can't access issues.guix.gnu.org since yesterday <lxsameer>hey folks, i was wondering is there any function to copy the source directory to `out` ? <efraim>(copy-file-recursively (assoc-ref %build-inputs "source") (assoc-ref %outputs "out")) <civodul>sirgazil: it's back to life... until next time <alextee[m]>is it taht the .nar in the servers is not built yet or something? <NieDzejkob>is there a reason guix doesn't clear stale files from /etc? <nckx>NieDzejkob: For example? <nckx>NieDzejkob: Or better: define ’stale’. There's potentially lots of precious admin-written data in /etc. <alextee[m]>i guess i should do guix pull and then wait a few days before doing guix upgrade to let the new stuff build <NieDzejkob>I've just hit a really nasty bug: When I first installed guix, I used %desktop-services, but later decided to use %base-services and build on top of that. I didn't need alsa-service-type to make sound work, so I didn't add it. Turns out that /etc/asound.conf exists pretty much by accident. <NieDzejkob>this became a problem because alsa-service-type writes paths to /gnu/store into the config <NieDzejkob>and when a dep of alsa-plugins got updated and I ran guix gc, the path stopped existing, which created a hard-to-debug error when running alsamixer <nckx>alextee[m]: You can also use ‘guix pull --commit=<a commit you like, or returned good ‘guix weather’ results>’ for the same effect without actually waiting yourself. <nckx>NieDzejkob: Interesting. <NieDzejkob>What would a good fix be here? Do a tree-diff between generations when activating a system to know what to remove? Is that practical? <nckx>NieDzejkob: Ick. I don't think it's anything. <nckx>Why is asound.conf a plain file and not a symlink to /gnu/store? <nckx>NieDzejkob: Your question is an interesting one, thanks. Something to think about whilst running 🙂 <NieDzejkob>gnu/build/activation.scm:207: ;; Things such as /etc/sudoers must be regular files, not <NieDzejkob>;; symlinks; furthermore, they could be modified behind our <NieDzejkob>;; back---e.g., with 'visudo'. Thus, make a copy instead of <jayspeer>How can I rename program provided by package? It seemed to work previously but now packages are named are set to default. here's package definition: https://paste.debian.net/1125841/ - I want terraform to be named terraform_0.11.7, but it is named terraform instead <NieDzejkob>the NAME field of a PACKAGE is the name of the package, i. e. what you use to refer to the package in, say, `guix install' <jayspeer>NieDzejkob: A month ago it worked how I wanted it to. I had both terraform{0.12.10,0.11.7}. Has something changed? <NieDzejkob>nckx: I just realised that this might also break rollbacks, if some program uses defaults when it doesn't find a config file <NieDzejkob>(like, apart from the fact that rollbacks are already broken in that they don't bother to run activation hooks at all) <NieDzejkob>jayspeer: I think the binary name is the last part of the #:import-path <jayspeer>NieDzejkob: so if #import-path is "github.com/hashicorp/terraform", then binary name will be terraform? <lfam>jayspeer: The name of the binary executable has no relation to the import path <lfam>If you want to change the name of the binary that is installed, you can use the rename-file procedure. There are lots of examples of this in 'gnu/packages/ <lfam>jayspeer: There are also examples of how to use the version string. Grep for ',version' <potential-alex>Heya, I'm trying to deploy the mysql service, but the mariadb package used by the service instantiation is missing some required files. These seem to no longer be located in the mariadb package but in the mariadb:lib output. How can I tell mysql service about this? <potential-alex>Or, more generally, how do I specify output variants in system configuration files? <civodul>roptat: ↑ does the above ring a bell? :-) <civodul>it could be a bug introduced by the mariadb "lib" split <roptat>I thought mariadb would be able to find its libraries… <roptat>Does the lib output have more thanqlibraries? <potential-alex>It contains some SQL files that the service relies on to setup the initial dbs <potential-alex>NieDzejkob : that works as a specification indeed — doesn't fix mariadb though :-( <roptat>The service uses the mysql package both for the binary and for the sql files <roptat>But they are teparate packages noo <roptat>The fix should be easy, but I can't do that before another 6 hours or so <roptat>We woull need one more option to specify the output that contains the sql file, and use it in the service definition <roptat>Thanksfully, no need to revert the mariadb split <potential-alex>roptat: if I understand correctly, add an extra argument to the mysql service which feeds it the lib output and get the files from there? <roptat>Actually, tge issue is already in a mariadb specific part of the config <roptat>So maybe simply replace one #$mysql with a #$mysql:lib would work, where it's using the sql files <roptat>At least if they are indeed in theqlib output <roptat>They might be in dev actually, but I don't have a system with guix atm, can you check? <vertigo_38>Hi guix! Does anyone know if/how and Atheros AR9271 USB Wifi dongle can influence a gnome session? Since I plugged it in (worked instantly), I every now and then get a 'system freeze'. What I mean by that is that the gnome session seems to run properly, but I can't access it with mouse and keyboard anymore. The mouse pointer moves, but clicking is no longer possible and switching to another tty doesn't work. It's not going instantly, <vertigo_38>instead it's kind of fading away -- first my wireless keyboard quits reacting, then also the laptop's built in one... Any ideas? <NieDzejkob>anything interesting in dmesg or /var/log/messages when a freeze happens? <nckx>vertigo_38: Do you have to hard-reboot your system or does it still respond to, say, a normal power button press? <vertigo_38>NieDzejkob: just checking /var/log/messages -- dmesg doesn't really help, as I have to hard-reboot, once this happens... <vertigo_38>nckx: well, it's a hard reboot, once this happens... <nckx>vertigo_38: If there's nothing in /var/log/messages you could try the SysRq + REISUB trick to flush as much as possible to storage when this happens again. <nckx>On laptops this is usually: <hold Alt> <Press and releas Print Screen> <Press and release the letter key> <Release Alt>. You can try SysRq+Space while dmesg --tail is running now to see if that works on your system. <nckx><hold Alt> <Press and release Print Screen> <Press and release R,E,I,S,U,B in order> <Release Alt> even. <nckx>vertigo_38: What does ‘cat /sys/module/pstore/parameters/backend’ say? <nckx>alextee[m]: libguestfs (not in Guix). <nckx>vertigo_38: Pstore is a mechanism for saving kernel backtraces to the system firmware, even when the kernel panics (impossible to save to disc). If you're interested in setting it up it might help debug the next crash. <nckx>It should be as simple as ‘modprobe efi_pstore’ and making sure that /sys/module/pstore/parameters/backend = ‘efi’ and /sys/module/efi_pstore/parameters/pstore_disable = ‘N’. <nckx>But you have to do or script this to run at every boot. <nckx>alextee[m]: And there's a simple fix for that 😉 <alextee[m]>nckx: it sounds complicated to build but i'll try lol <nckx>alextee[m]: I wasn't planning on doing it when I wrote it, but guess what I'm doing now. <nckx>Suck(er)ed into packaging once again! <potential-alex>roptat: alas the lib version, which contains the sql files for setup does not contain the binaries the service needs to run mariadb. <potential-alex>So it looks like we need both outputs. Is there a way to create a union on the fly? <nckx>efraim: Hmm, now does this go into toys.scm, file-systems.scm, or enterprise-cloud-solutions.scm? <roptat>Do we? Can't we use #$mysql to get the binary and #$mysql:lib for the sql files? <efraim>nckx: I was thinking file-systems <potential-alex>roptat: yes we can, but the configuration only has a slot for one mysql package — so adding both would require adding a second slot to `mysql-configuration` (as you previously suggested right?) <roptat>Yes, but then I found that there was only one place that is specific to mariadb where this is needed <potential-alex>roptat: or can you reference all outputs attached to a single package using #$ syntax, even if only one of the outputs is specified? (sorry my knowledge of outputs is limited!) <roptat>So we can simply use the output, without specifying it in the config <roptat>I think what you specify is a package object, so you could specify any output with #$ <roptat>Of course I'd need to check that, and if it's not ppssible, then adding a configuration option is fine <potential-alex>roptat: I see. I think it is indeed possible. I'll confirm in a second, but if so, then as you say, the patch should be trivial: just add :lib to the #$mysql dereference at line 527 <sneek>Welcome back peanutbutterandc, you have 1 message. <peanutbutterandc>nckx, I see. Sorry I was a little nervous about my first contribution. I hope it is normal that there hasn't been any reviews so far, with all the patches the maintainers have to go through <nckx>peanutbutterandc: Yeah, entirely normal ☹ <nckx>Everyone can review, not just maintainers! <peanutbutterandc>nckx, I see. Thank you. I was wondering if something was wrong. But I'm relieved to know that. :) <nckx>‘checking which of /usr/sbin /sbin /usr/bin /bin is a real directory... configure: error: non-symlink binary directory not found’ <potential-alex>roptat: sorry, I couldn't get this to work — hope you have better luck whenever you have a chance to look at it! <NieDzejkob>efraim: are we really going to put joke packages into guix? I feel like that fits into a separate, independent channel more <nckx>Asking people to add a separate channel just to install GNOME is bad UX. <efraim>NieDzejkob: I wasn't actually planning on sending them on to Guix, but I do have (some of them) packaged in my personal channel <efraim>on the other hand, we do have a toys.scm for some fun packages <peanutbutterandc>While we are talking about packages: I understand that there must be something about mozilla regarding firefox not being in gnu distribution but gnu icecat. However, I can't seem to find any gnuzilla version of thunderbird anywhere (not just in guix gnu distribution)... is there something that I am missing or is it just that nobody has gotten around to packaging it yet? <nckx>peanutbutterandc: The latter. <terpri_>peanutbutterandc, debian had an icedove fork, which is no longer maintained <peanutbutterandc>Another question: Say a drive-by contributor packages and contributes thunderbird. Are the maintainers now burdened with the responsibility of keeping the package updated? <peanutbutterandc>terpri_, Debian 10 has firefox again. Does that mean guix can also have firefox? Is the trademark-related issue all resolved? <nckx>peanutbutterandc: s/maintainers/contributors/ for clarity but yeah, pretty much. If nobody steps up to keep it working with updated dependencies or patch CVEs, then it will likely be removed again, no matter how many users it has. <nckx>Updates are less important as long as the package works. <peanutbutterandc>Also, if I find a bug in packaging, is it okay to `git blame` the packager and notify them of the bug? <nckx>peanutbutterandc: I consider it fine to CC them in the bug-guix@ report. <str1ngs>nckx: a gtk-next or qt-next channel might not be a bad idea though. <peanutbutterandc>nckx, I see. Would just mentioning it here in IRC be considered bad practice? Or discussing, rather? <str1ngs>peanutbutterandc: just report the but or the technical issue. thee is no need to mention the git blame <str1ngs>peanutbutterandc: if you need to reference git, just reference the commit in question. <peanutbutterandc>str1ngs, Oh I meant that instead of directly going and filing a bug report, would just discussing the matter with the packager in question beforehand here would be acceptable <nckx>peanutbutterandc: If you actually have a question for them, I think that's fine. <str1ngs>peanutbutterandc: if there is a bug, it's good to report it yes. <nckx>peanutbutterandc: Social commons sense applies. Does it matter *who* wrote the bug? If not, why blame. <peanutbutterandc>nckx, str1ngs - I see. That makes sense. I'm sorry I'm a n00b. Still learning. <terpri_>peanutbutterandc, guix could have firefox now, IIUC, but prefers to distribute icecat with minor customizations (librejs, hard-to-access extensions store, etc.) <peanutbutterandc>I have run into issues with the TuxGuitar package. It does not produce any sound. And a quick comparison to flatpak-installed (working-correctly) version shows that guix-supplied tuxguitar is missing a MIDI port, and a few installed-by-default plugins. <peanutbutterandc>But it is possible that there is some other way of getting the sound to work - by installing another MIDI server, possibly, and setting the associated ports <peanutbutterandc>So if there's anyone here who has been able to use guix-installed tuxguitar and could guide me, I'd be very grateful <peanutbutterandc>terpri_, I see... hard-to-access extensions store for security I presume <nckx>peanutbutterandc: It's good that you're thinking about this but you might be over-thinking. I quite often pop into #guix to ask nick: hi, why did you x? or (more often) could you take a look a y it breaks z? I've never intended it as public blaming or shaming, quite the opposite. I'm quite shy & actually prefer a quick IRC poke when I screw up, so I can push a quick fix myself, rather than A PUBLIC BUG discussion on THE WEB. 😮 This is probably personal <NieDzejkob>Oh, any idea how to make Firefox Screenshots work in IceCat? <terpri_>peanutbutterandc, no, to keep users from installing proprietary extensions (because it's not clear from the extensions directory which are freely licensed) <nckx>peanutbutterandc: This sounds familiar. Did you bring it up here before? <peanutbutterandc>nckx, I see. Thank you. It's the same reason with me too. I think quickly asking around here is better than a thread over there. :) <terpri_>these are issues where gnu probably could reach a compromise with mozilla, but they chose to fork instead <peanutbutterandc>nckx, I don't remember you being around. But yes, I was talking about this issue with someone else before <nckx>I try to keep an eye on discussion here even when not participating. <nckx>And I use TG myself so remembered it. <peanutbutterandc>terpri_, I see... So the extensions-manager is set to a default of 'only FSF-approved licenses' in iceweasel, I presume? <terpri_>peanutbutterandc, IIRC there is some kind of FSF extensions directory that is not properly integrated with icecat <peanutbutterandc>nckx, You do use Tuxguitar too? Does it work for you? Any particular configuration that I am missing? <nckx>peanutbutterandc: Yes but not on this box. I'm installing it now. <terpri_>what does work is visiting addons.mozilla.org directly and installing extensions from there (being careful to only install free ones, natch) <nckx>peanutbutterandc: Snort. <peanutbutterandc>nckx, I was initially going to ask something like "hey can you install it and see if the same error exists for you too" but then realized that defeats the whole purpose of guix's way of package management - reproducible builds and all. So I am suspecting if I might not have the necessary MIDI Server. But then again, perhaps that should be an (propagated) input of the package? <nckx>peanutbutterandc: Unix is fundamentally designed around environments and state, Guix only fixes a tiny portion of that. To compound that I run TuxGuitar from ‘guix pack’ so it's absolutely possible that my environment masks a bug with the package. <vertigo_38>nckx: I checked '/var/log/messages' pretty thoroughly now and start thinking that the Wifi-dongle isn't the guilty one. It seems to be a GPU-hang (i915/DRM) that sometimes appears since a kernel upgrade. Funny enough it rolled in at pretty same time, as I first used the dongle. Setting up libdrm and xf86-video-intel right now, maybe this makes things better ;) <nckx>vertigo_38: Oh, fingers crossed 🖖 <terpri_>imo it would be much better for firefox to have a "really really free mode" install option, which would preinstall librejs, disable drm, and hide non-free extensions in the store <terpri_>much less work than maintaining a full fork <terpri_>and mozilla's interest in tor integration shows that they're willing to consider "special editions" like that <peanutbutterandc>terpri_, You make me want to install icecat via guix. (And also re-ignite the fire to read up about libreboot, Intel ME, HURD -- all of which I want to get to the point of doing someday, eventually. :) ] <terpri_>yes there is, though i don't know if it's usable yet <terpri_>and don't forgot guix-on-power, where it will be possible to reproducibly build the whole system from the cpu firmware on up <peanutbutterandc>I see. It would be great to have a RISC-V open-hardware 3d printable laptop, libre-booted to run guix/hurd. That'd be the day. <peanutbutterandc>wait... guix-on-power? I don't think I have heard about that? CPU firmware as in the Intel ME thingy? (Sorry I'm a n00b, still) <terpri_>power as in powerpc, the architecture is fully open these days <terpri_>a system comes with full schematics, even <terpri_>$$$$$ though, because all the hardware is manufactured in the usa, presumably in very small batches <nckx>peanutbutterandc: I can confirm. No sound in a freshly-installed tuxguitar, nor a MIDI output port. <peanutbutterandc>nckx, ... and it lacks a few plugins installed by default, too. Thank you for the confirmation. <peanutbutterandc>terpri_, I see. That is so very cool. Why isn't it mainstream if it is that open? <peanutbutterandc>terpri_, Also, can guix compile any software for powerpc too? Even if has not been written for that architecture? (Or is this a really stupid question?) <KE0VVT>Hm. So far, Plasma has been giving me less lag than GNOME. <nckx>peanutbutterandc: It isn't. <nckx>peanutbutterandc: Guix still needs to be ported to power and there have been a few bugs holding that back. But once that's done the vast majority of Guix packages should just work. <terpri_>peanutbutterandc, yes, guix has full cross-compilation support. something like guix build hello --target=powerpc64-linux-gnu <nckx>We've been given access to a power machine but so far ‘we’ is just ‘me’, I still need to add interested parties. <nckx>terpri_: Yes, but there are IIRC some bugs preventing that from actually working. <peanutbutterandc>nckx, Wow. That is so very cool. Does that mean that, vast majority of linux-software would also work on hurd just so, too? Also, does it mean that if guix were ported to bsd and friends, it would become the one true universal package manager? <str1ngs>peanutbutterandc: btw I'm current look at issues with jack and fluidsynth. I will look at the tuxguitar issue as well <terpri_>nckx, are there channels or lists where that work in ongoing? i have a talos box and would like to run guix on it :) <str1ngs>peanutbutterandc: as far as I can see tuxguitar can we call it tuxguixtar? :P does not have the tux software synthesis. so you might need to used something else <str1ngs>peanutbutterandc: have you tried with timidity and vmpk? you may need to use aconnect to connect the two channels <peanutbutterandc>str1ngs, I did install timidity++ but nothing happened. I should probably try vmpk too <nckx>terpri_: Not that *I* know of, but I've been unable to devote as much time to Guix (and hence reading all list mail) as I'd like since Dec. Please, do not hesitate to volunteer if you're interested in helping out. If you're just impatient to use it that's also nice to know, I guess 😛 <terpri_>peanutbutterandc, some compatibility data is available from debian gnu/hurd porting efforts. 75% of packages work (or at least build?) with presumably minimal porting effort <peanutbutterandc>I see. It'd really be great to be able to use an entirely open modern computer. I looked up 'powerpc' on youtube and most of the results were old ibm thinkpads. <str1ngs>peanutbutterandc I think vmpk is broken too. do you specifically need tuxguitar to make tabs? or do you just want to play music with a keyboard. IIRC you do not have a MIDI device correct? <terpri_>the power architecture has continued development, it's just used in servers and supercomputers rather than consumer devices <peanutbutterandc>str1ngs, yes, sir. I use tuxguitar to make tabs. I don't have a MIDI device, however no. Another thing that does not work with Tuxguitar in guix: I can't input fretboard numbers using numeric keys (which is possible in flatpak and was possible with the dpkg supplied from the website too) <str1ngs>peanutbutterandc: okay seems you need tuxguitar for sure. can you at least click the fretboard? <terpri_>peanutbutterandc, risc-v is very promising as well, and should be well-suited for phones, laptops, etc. it remains to be seen whether manunfacturers will have the same committment to freedom as talos/ibm/etc <str1ngs>peanutbutterandc mercurial check phase it taking forever or I'd be testing tuxguitar already :( <nckx>peanutbutterandc: POWER9 is modern and up to par with x86. Just not in price, and probably not in power efficiency. <nckx>These are not obsolete chips. 🙂 <peanutbutterandc>terpri_, nckx : I see. That makes sense. I wonder - perhaps the FSF should buy a powerpc laptop for Mr. Stallman, if it is indeed that open. With Guix running on top of it - he might actually use it. <brown121407>Hi Guix! Anyone here working with mariadb? I put mariadb in my system packages list and (mysql-service) in my services list but mysql is giving me ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/run/mysqld/mysqld.sock' (2 "No such file or directory") <nckx>They are powerful but I don't know if they're laptop-friendly. It might make more sense to put much slower but less hungry chips in laptops. Didn't rms use a Loongson MIPS machine? <str1ngs>brown121407: check with sudo herd status that the mysql service is running <cbaines_>brown121407, the default socket directory is wrong I think, I think the actual socket is somewhere in /var/run maybe? You can pass the socket with the -S option I think. ***terpri_ is now known as terpri
<brown121407>str1ngs: it looks like mysql is stopped and disabled. <brown121407>cbaines_: I can't find anything MySQL related in /var/run <cbaines_>ah, well you'll need to get it running first <cbaines_>if you can't get it enabled and started, checking the logs might help <brown121407>Forgot to mention that when I sudo herd start mysql it says the service is currently disabled and it fails <str1ngs>brown121407: when you do sudo herd enable mysql; then sudo herd start mysql does it then start? <roptat>There's a bug that was reported not so long ago with the mysql service. I'll try to fix that when I can <roptat>Not suse if it's related to the bug though, the service should start despite it I think <brown121407>If it enable it and then start, it shows as started when checking status ***cbaines_ is now known as cbaines
<mehlon>sneek: later tell efraim: hey I heard you were working on updating the gnunet package? <mehlon>sneek: later tell efraim: if not, I can contribute a patch to update it to 0.12.2 <sneek>From what I understand, love is a very complicated thing. <mehlon>I just tried out tails. I feel very private now <nckx>Nobody knows you're mehlon now. <nckx>mehlon: Do you mean you already have a 0.12.2 patch ready? <mehlon>uhhh yeah but I gotta fire up my other pc first to fetch it <mehlon>all I did was change the version number and disable tests because theyre borked <mehlon>actually I updated to 0.12.1 but the very next day 0.12.2 came out 