<pmikkelsen>I always used to have working sound on my guixSD system, but now it doesn't seem to work anymore. Problem is, I have no idea when it stopped, since I haven't used it for a while. <OriansJ>pmikkelsen: bisection would be the easiest way to search that space. For example you have state 0-100; checkout 50 and if it works try 75, etc until you find when it broke <OriansJ>It should only take 10 or less attempts at worst for 1024 changes <pmikkelsen>OriansJ thanks for the idea! Will do one of the days ;) ***az is now known as Guest41838
***Guest73083 is now known as sturm
<cogrendel>In a package declaration it appears that several different module namespaces occur. <cogrendel>For example, in the origin reference section of the manual it is noted that one may supply a list of modules to be loaded during the patching process. <cogrendel>Also I see that some packages supply a list of modules in the "arguments" field, although I can't find documentation on this. <cogrendel>Can someone shed some light on how this works for me? Are there different module namespaces in one package declaration? If so why? <buenouanq>functionality beyond the very core is contained in modules <buenouanq>you read modules to be able to utilize the things they define <cogrendel>buenouanq: Hello, thanks for responding. I understand the purpose of modules. What I meant by my question was that it appears that modules loaded at the beginning of the scheme file are not available in certain portions of the package declaration. I was unable to find documentation on this behavior and am looking to learn more. <cogrendel>For instance in the gnuzilla file I linked above (ice-9 match) is loaded in the top of the file, then separately in (arguments ...) <cogrendel>Futhermore I am unable to find documentation on the `#:modules` keyword for `(arguments ..)`. I am assuming that it makes these packages available in the `#:phases` arguments, but I haven't seen this documented. I am just guessing. <cogrendel>buenouanq: No problem, thanks for trying to help. <buenouanq>qtox is missing a bunch of gui icons on gnome <buenouanq>is this a qt problem, a gnome problem, or a the guix packaging of qtox itself problem? <mbakke>cogrendel: the reason why some packages specify #:modules explicitly is because they need modules not implicitly provided by the build system. <mbakke>buenouanq: try installing qtsvg. The lack of qt icons is a known problem. <cogrendel>mbakke: Thanks for the reply. Sure, some packages need additional modules. My question is not why modules exist, it is how the namespacing works. It was a surprise to me that modules imported at the top level are not available anywhere in the package declaration. <cogrendel>I gave an explicit example above from the gnuzilla module. <mbakke>cogrendel: I see. The reason is that package builders are evaluated in a different context. The resulting .drv needs to declare imports up-front because the store does not know anything about the module the package was declared in (only how to build it). <buenouanq>mbakke: thank you! took a restart, but it worked <mbakke>I suppose it may be possible to make module imports implicit inputs. <mbakke>sneek: later tell buenouanq glad it worked :) there is an ancient bug to make search paths of dependencies available to the "end package". I know "krita" has specific provisions to work around this problem. <cogrendel>mbakke: I see - that makes sense. Thank you for your reply. <sneek>buenouanq, you have 1 message. <sneek>buenouanq, mbakke says: glad it worked :) there is an ancient bug to make search paths of dependencies available to the "end package". I know "krita" has specific provisions to work around this problem. <mbakke>Wait, it's almost 6am here. Why am I not asleep. <buenouanq>mbakke: push through, third wind certainly comming your way <enderby>shoutout to whoever packaged monero ;-P <rekado>NewGnuGuy: we offer a bunch of different versions. <NewGnuGuy>Which version is included on the install iso? <efraim>I don't think anyone's worked on that so far <rekado>CharlieBrown: what do you mean by “do Flatpak”? Install Flatpak applications or export a bunch of packages in the Flatpak format (like we do now for Docker images)? <CharlieBrown>rekado: I mean, will someone running GNOME on GuixSD be able to install a Flatpak in GNOME Software? <CharlieBrown>I know some people think Flatpak is against the goals of Guix, but I think Guix should be able to package everything -- IceCat extensions, Emacs extensions, Python packages... <wigust->CharlieBrown: There is no reason not to include this. Nobody just did this. <rekado>CharlieBrown: it would not be managed by Guix, though. Flatpak software would be managed by GNOME Software, which would be installable through Guix. <rekado>just like you can install pip through Guix and then install Python things with pip. <CharlieBrown>Though I thought Guix tried to handle all these foreign package managers. <buenouanq>other package managers no longer need to exist (-‿‿ - ) <NewToGuix>Hello All, is it possible to package & distribute commercial software binaries to the customers via Guix? <efraim1>NewToGuix: if yout mean proprietary sofware, not in the main repository, but it should be possible in your GUIX_PACKAGE_PATH, but we don't discuss packaging and distributing proprietary software on this channel <CharlieBrown>NewToGuix: Yes. Just charge them money before giving them the source code and the Guix recipe. <CharlieBrown>I love commercial free software. I use it every day. It's way better than commercial proprietary software. <rekado>CharlieBrown: Guix cannot possibly use any other package manager as a backend, so it cannot be a meta package manager. <adfeno>Hi #guix! Parviz at #gnu-health wants to know: is it possible to install GNU Guix (package manager) in Raspberry Pi? <adfeno>pokoli Parviz: I already asked just now, let's wait ;) <efraim>Guix can be installed on the RPi3 but currently it's not possible to install GuixSD on the RPi3 <Parviz>Most recently boot through flash memory on Pi 3 <adfeno>I guess he meant: "What about Flash boot on RPi 3?" <adfeno>Parviz: GNU Guix is only package manager. Can be installed in any distro which has GNU packages (I think even in Windows 10 Development-Mode-Enabled these days, but I'm not sure) <adfeno>ACTION doesn't like Windows, not even the new one with development mode option. <adfeno>.... and I never used it, so this is why I said that "I'm not sure" <adfeno>Parviz: On the other hand GuixSD (did you notice the "SD" part?) is a system distribution that uses the GNU Guix package manager by default, and also uses GNU Shepherd as service manager. <adfeno>Parviz: The nice thing about both GNU Guix and GuixSD is that you have the possibility of doing roll-backs in case an update/upgrade breaks something. <adfeno>There are also othr awesome things about both, but I'll leave this to another moment. <adfeno>(by "upgrade/update" I meant: package upgrade/update) <adfeno>But the roll-backs are an awesome feature, specially when dealing with professional setups. <Parviz>Dear adfeno Sure , But this now I want to choose the best OS for Install and Setup Gnu-Health <adfeno>For the GNU Health server... ... I'm checking now if other free/libre distro supports Raspberry Pi 3 too. <Parviz>I'm sure the Guix is very good Tool <Parviz>And I have to learn more about it <Parviz>But this now I want to choose the best OS for Install and Setup Gnu-Health <Parviz>for Example : Raspian Or OpenSuse for gnuhealth on Raspberry pi? <adfeno>So currently we have a server that will, unfortunatelly, be in Raspberry Pi 3, then the clients will be everywhere in other platforms... hm.... <Parviz>or Debian & Ubuntu??? or Fedora& CentOS Or??? for 86-64 Bit Server System??? <Parviz>what the Best OS for install and Setup gnu-health??? <adfeno>So the general recommendation is: Install any GNU+Linux distro, and install GNU Guix on top of it to have the features of GNU Guix with GNU Health. <adfeno>The recommendation mostly goes until "install GNU Guix on top of distro", the part about GNU Health is an addition to your case. ;) <Parviz>Dear adfeno thanks alot for guide me, <Parviz>I was very happy to meet you, Hope I learn more from you in the future <adfeno>I think there's still work to be done for the GNU Health package definition, but the message I gave still holds: currently the only hope for being sure that you are using mostly free/libre software in Raspberry Pi (and perhaps even version 3), is to install the Guix package manager on top of an existing distro. <Parviz>Like installing Guix on openSuse in Raspberry Pi 3? <Parviz>Dear adfeno and, Friends all, have a nice day <catonano>adfeno: do you mean this one ? health.gnu.org <catonano>adfeno: I did what I could in order to port Tryton in Guix. Tryton is the base for GNUHealth <thomassgn>buenouanq: derp, just rebooted and remembered and found there is something that takes away keyboard and trackpad input. Not sure what it is, but trying to fix it. Will let you know what how I fix it if I figure it out. :) no time right now though. <buenouanq>I like being able to use my keyboard and mouse... <efraim>is curl-7.58.0 supposed to be a public variable? <catonano>adfeno: now that Danny Milosavljevic made a service for Tryton, Guix is a perfectly fine Trytond dev platform. As for deploying, it might be different. Bt ofr development it's ok <catonano>adfeno: okk, thhere are no modules yet. But it shouldn't be too hard to package them. They are just python packages <adfeno>Better than Odoo/OpenERP though ;) <catonano>you think so ? I might be interrested in knowin why, but we'd be off topic ;-) <adfeno>ACTION prefers Tryton and CiviCRM for usage in organizations. <catonano>when the tryton modules will be packaged, it will be possible to start porting GNUHealth in Guix <catonano>as ar as I understand, GNUHealth is just a bunch of Tryton modules, some off them depending on other Tryton modules <kete>ACTION thinks about starting a config.scm to replace Trisquel on laptop. <rekado>ACTION had some first successes with an SELinux policy for the daemon <rekado>I’m writing it in the S-expression-based CIL instead of the old default language. <rekado>the SELinux documentation is horrible. <rekado>much of what you can find is Fedora or Gentoo specific. <rekado>and they all use the old m4 macro language. <civodul>thanks for diving into it, it's always sounded scary to me :-) <rekado>using symlinks for profiles is a bit problematic as SELinux has labels per file (including symlinks) <rekado>so a link to a file with type guix_daemon_exec_t won’t have that same type <rekado>I can of course label /gnu/store/…-profile/bin/guix.* as guix_daemon_exec_t, but technically that’s not okay. <apteryx_>civodul: what is the difference between builds made with qemu-binfmt support (--system) vs cross compiled-packages with --target? <apteryx_>like, the gcc producing x86 binaries will be used, but through some QEMU layer magic it will be turned to ARM, say? <efraim>qt-5.9.4 released, that sounds like a fun update <efraim>means I can put off figuring out the 5.10 sqlite issues <bavier`>apteryx_: binaries for system are run directly on the native machine on top of qemu <apteryx_>I think I can understand the run part (instruction are translated through binfmt support in QEMU/kernel?), but I still don't get how the binaries produced targetting say ARM without a cross-compiler? <apteryx_>*binaries can be produced for ARM (when the host is x86) without a cross-compiler <apteryx_>is QEMU detecting that GCC is outputting x86 instructions and translating those to ARM on the fly? <bavier`>apteryx_: the compiler produces ARM instructions <bavier`>it's an arm-system compiler with --system=arm* <apteryx_>I see! Thanks for explaining. Which approach should be fastest? <bavier`>apteryx_: idk what qemu's emulation speed is like, re arm-emulated-on-x86 vs native arm <bavier`>it would obviously depend on the arm processor <apteryx_>oh, I was thinking of comparing arm-emulated-on-x86 vs cross-compilation <apteryx_>guix build --system vs guix build --target <bavier`>oh, I would assume --target would be faster <apteryx_>any GNU triplets I could try to emulate armv7? I tried armv7-gnu-linux but that ain't a thing. <apteryx_>I tried "guix build --system=arm-linux-gnuabihf hello" and I get: guix build: error: could not find bootstrap binary 'tar' for system 'arm-linux-gnuabihf <efraim>for --system you'd want 'armhf-linux' <apteryx_>If I try: guix build --target=arm-linux-gnuabihf hello I get: ERROR: dynamic linker name not known for this system "arm-linux" <efraim>gnuabihf or gnueabihf? with the 'e' <apteryx_>efraim: with the 'e', it works :) thanks! <apteryx_>any way to 'discover' what those gnu triplets can be? The cross-ref section from autoconf doesn't seem to exist anymore in our manual <apteryx_>should be: '(autoconf)Specifying Target Triplets' (note the capitals). I'll send a patch tonight. <rumplestiltskin>hello guix! What is the best way run a binary that is not from guix? <bavier`>rumplestiltskin: does it not just run? <bavier`>rumplestiltskin: I've only tried this once: 1) use 'guix environment --container --ad-hoc ...' with all the packages/libraries required, 2) `echo $GUIX_ENVIRONMENT && exit`, then 3) do 'guix envrironment' again and use the --expose option to bind the profile to /usr or such <civodul>apteryx_: the manual in current master hopefully better explains the difference between --target and --system (and binfmt) <civodul>efraim: do you know the story with QGLWidget? it was there in our qtbase@5.9.1 but it's not in 5.9.3 <civodul>i wonder if it's on purpose or if it's a packaging issue <vagrantc>ACTION still lurks, shown by the occasional typo <bavier`>dustyweb: congratulations on the ActivityPub announcement <rekado>ACTION fixes the selinux packages on core-updates. <jonsger[m]>civodul: did you see my patch for the website on guix-devel? I wasn't sure what the correct place is... <civodul>i saw it and thought you were too fast ;-) <civodul>but yeah, i'll send an update on this topic <civodul>i don't think this has been discussed on the list yet <rekado>huh, I switched to a different worktree for core-updates, ran “make clean-go”, bootstrapped, reconfigured, and now make prints this: <rekado>happens when loading guix/scripts/pack.scm <civodul>this has been reported a few times, but i had no idea what was going on <rekado>so, I had an error in one seemingly unrelated module (gnu packages selinux) <rekado>there I used git-fetch without using (guix git-download) <rekado>after adding the missing use-modules line “make” gets past loading guix/scripts/pack.scm <civodul>unless you find a way to reproduce it <rekado>I’ll try again after doing what I tried to do in the first place. <lfam>civodul: Do you know if it's okay for me to start a new core-updates evaluation? There's not too many changes but it would be nice to have a substitute for linux-libre <lfam>civodul: Okay, done! (I think!) <civodul>i wanted to look at the ICU issues but i got distracted <lfam>I still didn't get a chance to look into the ICU stuff <lfam>Huh, looks like someone tried a core-updates evaluation only a few minutes before me, but it timed out <lfam>I guess we both wanted to avoid building a kernel ;) <taohansen>Any Guixers able to get Xpra up on their GuixSD machines?