IRC channel logs
2023-12-18.log
back to list of logs
<apteryx>nmeum: best would be to include everything you need in your guix.scm or manifest.scm file <nmeum>apteryx: yea, i am installing cabal via guix.scm (if that's what you mean) but it doesn't work out of the box and requires GHC_PACKAGE_PATH to be unset and I would also like to do that as part of the guix.scm <apteryx>(disclaimer: I'm not a knowledgeable GHC person, at all) <apteryx>nmeum: short answer is you can't with guix directly <singpolyma>Yeah, cabal not working in guix shell is a very unfortunate problem for haskell dev with guix <apteryx>you'll have to use a 3rd party solution like direnv or the likes <singpolyma>But you should be able to skip it and just use ghc directly <apteryx>nmeum: is there a guix bug for that issue? it seems worthy of reporting it if not <nmeum>I think it's well known guix itself unsets GHC_PACKAGE_PATH in the haskell build system procdeures <apteryx>nckx: nobody has made NFS mountable as a file-system record yet, that I know <apteryx>my hack is to the fstab created by a file-system declaration, but with (mount #f) or something <apteryx>so when your system has finished booting with network and all it's at least easier to 'mount the-thing' <apteryx>it'd be nice to have this fixed at last <singpolyma>nmeum: I'd suggest trying to get used to just using ghc directly. If your dependencies are in guix (and if they are not why are you in guix shell?) it works pretty well <nmeum>my dependencies are in guix shell but I still need a build system to invoke ghc <nmeum>I guess I could write a Makefile which invokes ghc directly but I would prefer not to do that <singpolyma>You don't really need a makefile. Just ghc Main.hs is often enough <singpolyma>If you have a lot of switches in your setup a one line shell script helper can be useful <nmeum>unfourtunately, my haskell project has reached a level of complexity where this is not really feasible <nmeum>I would rather want to come up with a fix for the cabal-install guix package so that it works by default without requiring any environment variables to be unset <singpolyma>nmeum: I'm curious what else your cabalbis doing? <nmeum>it's split into multiple executable and library components and there are also different test suites <singpolyma>Oh right, so there are a half dozen different ghc lines I guess not just one <singpolyma>Id probably still do a folder with a half done one line shell scripts, but I agree it would be more familiar for people coming in if cabal were guix aware <singpolyma>I think they are already nix aware so it may not be too hard to add to cabal <nmeum>shouldn't be too hard to implement really <apteryx>OK, it's under Edit -> Connection Details -> Virtual Networks tab <abrenon>is that a light saber fight (or are you just happy to seem me? ^^) <abrenon>(for the record and as a poor justification to my joke, your nicks render respectively as blue and red) <efraim>I should remove yellow as a sig color, it's really hard to read on my screen <abrenon>but it seems to backfire in an interesting way <abrenon>before reconfiguring my system, I checked that rmmoding the pcspkr module did fix the problem (i.e. no loud crack anymore anytime I don't something that would trigger a "bell") <abrenon>but after rebooting under the new configuration (with the blacklist in place) the loud sound is back <abrenon>despite the fact that lsmod confirms that the module is not activated <abrenon>and, for the backfire part, I can't add it to test whether removing it manually would fix things, because it's blacklisted in /proc/cmdline, so it won't let me <abrenon>is there a more recent way to deal with this kind of kernel module issue that I'm missing? <nckx>The 'backfire' part isn't as obvious as you think. A sudo modprobe should not care about the kernel command line. <nckx>ACTION puts on their testing pants. <nckx>So yeah, I can 'sudo modprobe floppy' despite 'modprobe.blacklist=floppy,...' in my /proc/cmdlinee <nckx>ACTION puts on regular pants. <abrenon>thanks for your answer, so that's actually additional information, good! <abrenon>I noticed that the modprobe.blacklist=pcspkr ended up appart from another bunch of modprobe.blacklisted modules <abrenon>I imagine the others are coming from the %default-kernel-arguments, but could that have anything to do with it? <nckx>As in, a separate argument without a comma? I didn't test that, but I'd be a bit surprised if there were a bug in upstream kmod. Then again I've been surprised before, it was awful. <abrenon>yes, I guess that's because we're simply `cons*`ing stuff into a list of strings, not performinig any clever insertion that would detect a pre-existing 'modprobe.blacklist=.*' in that list to merge instead of simply prepending a new block <abrenon>I grepped my grub.cfg, it looks like this: `modprobe.blacklist=pcspkr modprobe.blacklist=usbmouse,usbkbd ` <Kabouik>grep returns "grep: Perl matching not supported in a --disable-perl-regexp build" when I try to use grep -P, however I can't see this disabling flag when looking at `guix edit grep` (I wanted to edit the package to enable it). Any ideas? <abrenon>couldn't it be enabled by default (in the sources for grep)? <abrenon>have you tried looking at the sources directly with something like `guix build -S grep`, then copying the .xz archive somewhere, extracting and looking into that? <nckx>Kabouik: Use core-updates' grep. <Kabouik>I am looking at it right now, ripgreping "--disable-perl-regexp" to see if it might be used by default <Kabouik>How do I use that nckx? Is that a different package? <nckx>No, you'll have to use guix time-machine, or extract it into a separate file and install it from there. <nckx>Don't be fooled by the configure-flags, they don't affect the build. I added them only to detect the same regression in future. What matters is the pcre update. <Kabouik>So grep not supporting -P is expected in a default Guix installation, correct? I'll look into how to use time-machine, or maybe make my own package if using time-machine may cause issues with maintaining future updates (?). <nckx>My 'no' was not in response to abrenon, they are right about core-updates being a git branch. <nckx>Kabouik: Until core-updates is merged into master, it is expected, but it was never intentional. <Kabouik>So would a a simple `guix install grep --with-branch=grep=core-updates` work? <nckx>Time-machine (or its Scheme-code counterpart, inferiors) should not cause issues, although you'll have to use --do-not-upgrade=grep if you use 'guix upgrade'. <nckx>Kabouik: No, that would look for a core-updates branch in the *grep* repository, or at least it would if we built grep from git :) <nckx>What you want is guix time-machine --branch=core-update -- install grep, or something like that. <nckx>The part before the -- sends guix into a parallel timeline. The part after -- is the guix command to execute when you arrive. <nckx>And of course this will only upgrade your 'user' grep, not the 'system' one, but I hope that's enough for now? <Kabouik>Thank you. Trying that. Slightly annoyed by the extra mental charge in the next `guix upgrades` that will require me to `do-not-upgrade=grep` though. Maybe at some point it would be simpler if I just make my own package for my private branch, with grep built from git and core-updates branch. <nckx>If you used a manifest you could pin an 'inferior' grep, but now I must truly go o/ <Kabouik>You were not joking; it does take a while! <efraim>if you're just installing grep I'd create a package variant with the changes you want and install that in a manifest <Kabouik>Yes making a package variant was my initial idea, but I'm not sure about a manifest, I don't quite master the concept yet as I don't use it (I did use it once and I remember it somehow caused me issues later because the packages would not be updated with the others, or something; sorry, it's not clear anymore what the issue was, if it ever was). I was thinking about adding grep from git-checkout and core-updates branch to my private channel. <ekaitz>efraim: sent you the new qemu patch... qa says unknown <efraim>ekaitz: I had issues with a test on x86_64 under heavy load, was fine when I rebuilt it <efraim>looks like libc in rust-1.74.1 isn't new enough to have all the fixes for the hurd, no cross building there yet <ekaitz>i also talked with cbaines about this in the past, qemu is a weird package and tests not always pass in the qa <efraim>ekaitz: I read your most recent article, we should try to figure out something with bash and windows <ekaitz>efraim: I agree, I sent a bug report of bash-minimal long time ago, civodul told me that's probably a bug but that was forgotten in time <ekaitz>i think it's actually possible to build bash for windows <ekaitz>(doesn't git for windows do that?) <ekaitz>but i'm not sure about bash-minimal <efraim>I found a couple of old builds for bash for windows, and it looks like busybox might have support if configured correctly <ekaitz>or what kind of differences those packages have <efraim>I think "git bash" for windows uses cygwin <efraim>/gnu/store/s04wzr75lbksrv3qhjf1gnx65gp7dqk5-gccgo-11.3.0/bin/gccgo: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /gnu/store/57z58ayasqrzlwq95bv45m6jpx22j96k-glibc-2.37/lib/ld.so.1, for GNU/Hurd 0.0.0, stripped <efraim>there's a race condition when building gccgo@12 that libbacktrace.la isn't depended upon by libgo.la in the Makefiles, but is built first when using multiple cores <efraim>oops, looks like libunwind isn't necessary with make-rust-sysroot <ekaitz>lilyp: ^^ look the convo with efraim, do you want to research on this together? <efraim>I assume you mean the intersection of bash and windows and cross-compiling from guix <efraim>I'm in. Don't have a use for it yet but I'd like it to Just Work™ <ekaitz>i may tagged the wrong person though <ekaitz>great efraim i'll spend some time on it too <efraim>core-updates is a branch of guix <efraim>sneek: later tell civodul I think the last cross-libc I couldn't find with avr was make-rust-sysroot <roran>When I use guix package -i instead of specifying in my system file what packages I want, there is no reproducibility, right? <roran>Has there ever been work on auto-integrating something similar? Maybe I need to reread the manual <roran>To clarify, I mean that I can't reproduce my current system by just using the original system specification if I install stuff I want using guix package -i, right? What else would I need on top of that to recreate the system? <abrenon>roran: each call to guix package -i still yields a new generation, so you can still go backwards if you need to, export manifests, etc. <theesm>hi guix, what's currently a proper way to set environmental variables for all users/does guix have a way to append to /etc/profile? <ekaitz>theesm: there are configuration fields for that <ekaitz>theesm: session-environment-service-type <ekaitz>theesm: make a service like: (simple-service 'my-service session-environment-service-type '(("MY_VAR" . "my_value"))) <ekaitz>of course it did :) (i use it too haha) <gabber>i somehow broke an aarch64 Guix system that now claims "waiting for parition `<UUID>' to appear instead of booting. i have not specified any kind of UUID in my operating system and am a bit puzzled as of where to look for the bug? any ideas? <gabber>ACTION thought the correct way to address people here was `hi guix' ;) <futurile>Q: I have a guix repl question. In the repl I do (package-source nudoku) and it gives me "$10 = #<origin #<<git-reference> ...". What type is this? And how do I query/access it - I basically want the git-reference here <futurile>gabber: I'm trying to vary my greeting so it's clear I'm not a bot - I think the function I wrote with a set of greetings is really working well for me <gabber>futurile: i think you can do something like `(string->uri (origin-uri (package-source package)))' <gabber>by "want the git-reference" you meant the uri, right? <zilti>My `guix home reconfigure` wants to compile most things from source, is there an issue on guix' side? I have the substitute servers enabled. <gabber>zilti: you can check substitute availability with $(guix weather) <futurile>gabber: yes exactly - that's much better than trying to manipulate it directly. origin-uri part works, string->uri doesn't - but that's a great hint I'll look for those functions in the source <zilti>gabber: thanks, I forgot about that! I wouldn't mind, but it wants to compile half a dozen versions of Rust <gabber>zilti: also, you can use the -n switch with the reconfigure commands to see how much is built on your machine and how many substitutes are downloaded <zilti>That would be nice but I only get to see the lines that fit on my screen <gabber>you could pipe them to less, i.e. $(guix home reconfigure config.scm | less) <gabber>or redirect the output to a file to inspect later (with the `>' character) <zilti>Maybe a file could work, piping to less did not <gabber>ah, you might want (or need) to pipe both stdout and stderr to that file (or less) <AwesomeAdam54321>Is there an easy way to figure out what changes cause a world rebuild in my local Guix copy? <wingo>i have a funny bug. running guix shell foo bar baz -- ./path-to-env-script make foo. i press control-C and guix shell quits, but "make" stays on and prints things in the background <wingo>i have to manually find the "make" process and kill it <civodul>wingo: doesn’t ring a bell, but perhaps you’ve just hit an interesting bug <sneek>civodul, you have 1 message! <sneek>civodul, efraim says: I think the last cross-libc I couldn't find with avr was make-rust-sysroot <jpoiret>AwesomeAdam54321: I've been looking at it as well, you probably want to run `grep -Rl "<platform>" --include='*.go' . | xargs rm` first <jpoiret>there was a change to <platform> and you need to rebuild the files depending on it <ieure>Does guix home only work on GuixSD? I have guix installed on an Ubuntu VM (long story), and `guix home' says there's no such command. <ieure>Or maybe the better question is... is it intentional that guix home only works on GuixSD? <mwette>Any docs on how packages find patches? I'm using `guix build -f' and it looks like guix can't find my patch. <apteryx>would someone know why our GRUB can't find video in a QEMU VM? <trnry>ieure: Guix home definitely works on foreign distros. I'm using it on Fedora right now <trnry>Any chance your Guix binary is old, before <ieure>trnry, Could be! The guix package in Ubuntu is 1.3.0, but I thought `guix pull' would update that. <gabber>ieure: your problem most possible traces back to ubuntu resolving your `guix` command to the old (1.3.0) binary. what's the output of $(which guix) and $(guix --version)? <ieure>gabber, Okay, got it, yeah. It was using the system one, I sourced the profile and it's good now. <jackhill>yay, happy to see the webkitgtk branch merged. Of cource now there's 2.42.4. The treadmill doesn't stop I guess. I wonder if this one can be grafted. <podiki>lilyp and vivien: what's the latest on the gnome-team branch? <lilyp>I should push vivien's world rebuild soon™ <jackhill>looks like there's yet another webkitgtk release… <podiki>lilyp: gtk is failing on mesa-updates (not just i686 like I said in guix-devel email), trying locally with gnome-team updates to see if that fixes it (test failure) <podiki>though if you know off hand how to easily disable a single test that would be helpful too <lilyp>jackhill we should be able to graft that this time tho <jackhill>lilyp: cool! I was optimistic, but webkitgkt's still a little bit more complex than other grafts I've worked with. <podiki>lilyp: I'll let you know how the local build goes (it is...a lot) but would it make sense to put the mesa-updates (3 commits) on top of gnome-team? or vice versa <podiki>(4 commits actually: mesa, xwayland, curl, xorproto) <civodul>lemme know how well it builds for you :-) <rofrol>guix system image --system=aarch64-linux --image-type=uncompressed-iso9660 /gnu/store/271mkw93sqb3hc4ngszcjfsc2wsb6yc8-guix-1.4.0/share/guile/site/3.0/gnu/system/install.scm <rofrol>ls: cannot access '/gnu/store/271mkw93sqb3hc4ngszcjfsc2wsb6yc8-guix-1.4.0/share/guile/site/3.0/gnu/installer/aux-files/logo.txt': No such file or directory <mirai>What's the G-Exp equivalent of (assoc-ref %build-inputs "source") ? <mirai>had no idea #$source was a thing <euouae>I have a bare bones Guix install working and I'd like to get a WM now, I'm thinking of Sway. I want to ask a couple of questions: <euouae>1) If I want a declarative style of install, should I only edit /etc/config.scm or can I guix install and edit config.scm later? <euouae>2) If I install sway, is the setup then just following whatever instructions sway offers or do I need to do something more for guix? <vivien>1) You don’t need to guix install, but you need to edit config.scm and run guix system reconfigure /etc/config.scm <vivien>You should also make sure you have run guix pull at least once <euouae>yup I've done that a few times. I was surprised to find out that `guix pull` had work to do when I ran it twice in a row <vivien>(or rather, sudo guix system reconfigure /etc/config.scm) <vivien>Maybe you should be more explicit about “whatever instructions sway offers”, because if it instructs you to do systemd things for instance, then it does not apply <lilyp>podiki: depends how quickly you need them deployed; gnome-team is not ready for an MR yet <sneek>euouae, you have 2 messages! <sneek>euouae, lilyp says: basically, when distributing C software mixed with Guile, you have two options. Either, as you describe, the C software is a shared library which you load through Guile FFI, or it is an application that itself makes use of the Guile VM. Anyway, you can distribute it both compiled (i.e. binary/shared lib + guile code), or as source code. Typically, you'd use "make install" to set up the install directory in a more or <sneek>euouae, lilyp says: less FHS-conforming manner. <euouae>thanks lilyp. I was going with option (1) of what you said but mupdf-dev seemed to have issues on Debian so I'm going to Guix now and I'll try to see if I can develop it there. Otherwise I"m switching to Python <euouae>but finally putting in the work to set up my Guix <vivien>(I’m already watching a video so I can’t watch another one) <euouae>oh I don't need you to watch it don't worry :P <euouae>I just linked to it if anyone cared <vivien>It seems that the author is installing Sway on Guix System though, so the instructions should be relevant. I don’t know how recent the instructions are. <vivien>I don’t know how fast guix’ sway is evolving either, so you should be fine. <euouae>it's funny watching this guy struggle though lol <euouae>he keeps having to reboot and he set up encrypted boot and encrypted home <euouae>vivian, well what if I go with an easier path and just use gnome? should I just set up gnome-desktop-service-type? <Altadil>euouae: Yes, adding it to your services should be enough <euouae>after a system reconfigure, it ended with `In procedure fport_write: Input/output error` <euouae>this is an exception caught while executing eval on service root <euouae>hm, now I got a segfault trying to run sudo <euouae>`sudo: pam_open_session: Error in service module. sudo: policy plugin failed session initialization. Segmentation fault` <euouae>that's from trying to do `sudo herd power-off root` <ieure>Seems like the disk you're installing onto is failing. <euouae>did it? well it worked anyway, I rebooted into gnome just fine <euouae>maybe it was some weird error from upgrading from bare-bones to desktop <nckx>Since you rebooted dmesg'll be gone, but you can check /var/log/messages for errors correlated with the i/o error. Those are always logged. <davidl>Anyone who has thoughts or opinions about Ubuntu snaps security vs Guix packages security? Canonical's ubuntu is marching towards Corporate security compliance using Microsoft Intune, so Im wondering what would the closest thing Guix could possibly offer a corporate work laptop given some time and money investment that would compete and be up to the standards. <vivien>What’s the problem these things are trying to solve? <podiki>lilyp: ok, will keep you updated. there are security fixes for curl and xwayland, xwayland I don't know if it could be grafted (needs newer xorgproto which is what causes all the rebuilds) <ieure>davidl, It's very unlikely Guix would ever support Intune or junk like it, and in general isn't highly compatible with the kind of locked-down environments you tend to find in corporate IT dictatorships. That said, IMO its strong emphasis on a strong supply-chain are a better approach. <apteryx>ACTION revives a 3 year old small cookbook patch detailing how to configure a network bridge for QEMU/libvirt <vivien>I’m not sure there’s a big enough number of people who want a foreign corporation to control their devices <ieure>Well, I see this as a case of wanting to use Guix inside a corp that already does that stuff. <podiki>apteryx: I had to do that (pre-guix) for when I had vfio (to use another os with gpu) and had a couple of commands to do that....wonder if I have that script somewhere <podiki>anyone happen to be familiar with the tests in gtk? an easy way to just diable/not run one test? <davidl>vivien, ieure: there is an argument for non-pure adherence to FOSS due to the fact that tons of ppl must make a livelihood for their families and that currently this is not available to the number of ppl who wish they could go FOSS in their daily $jobs. Pushing things that direction as much as possible, like perhaps Canoncial does via MS Intune compatibility, may lead to approaching Linux in the corporate world, and if played well, pushes the <davidl>corporate world away from MS and Apple towards FOSS alternatives instead. It would be nice to have any idea about what Guix can offer in that direction of standards compliance - because that is at the heart of this - businesses wants compliance to standards so that Customers will choose them and not their competitors. <vivien>podiki, the #:test-options argument is a list of arguments that are passed to meson test <podiki>vivien: I saw that, but is there a standard for disabling a test by name? i see a gtk_tests list in meson.build but wasn't sure the format or if I just substute* on that file <ieure>davidl, I'm very familiar, since I'm a working programmer at a company that makes everyone use MacBooks. That said, I'm not convinced in your diagnosis of the problem, nor of "FOSS, but bolted to a proprietary thing" being compelling. <podiki>the test is gtk tools validate? something like that, which I don't see by that name <dansa>I'm studying on to make a first package. All examples I've seen (including the cookbook) always mention a git-fetched case. Can I keep things local while I'm in development? (I don't have a remote git repository, say, although I intend on getting one before I ask Guix to incorporate my package.) <ieure>davidl, It's been my experience that the largest blocker to adopting freeer systems in a corporate environment is getting the IT folks to sign off on it and do whatever work is required to suck them into the overbearing corporate spyware endpoint protection type systems which it's policy for all machines to run. <dansa>(Sorry. Suppose I've fixed my preposition woes above.) <ieure>dansa, What are you trying to package? Wherever its source is hosted is what dictates what fetch mechanism to use. <davidl>ieure: Id be interested to hear more about your perspective on this. I didn't fully understand the second part of the last sentence you wrote though. <dansa>ieure: I'd like to package something I myself wrote, so it's not available anywhere yet. <ieure>dansa, I'd package it up into a source tarball and use a file:/// url and the standard url download mechanism. <dansa>ieure: that sounds great, but what would the path be? where do I put the file? it's not clear me to how that works yet. <ieure>dansa, Put it wherever you want, then point your package recipe at that location. <davidl>Running Guix on some Ubuntu Flavor with Ubuntu Pro enabled would possible maintain Microsoft Intune enrolled endpoints while still allowing Guix users to stay Guixy in their dev workflows. If there were any FOSS analogue to microsoft intune, that would just be really interesting to know about. <ieure>davidl, What I mean is, companies pick some kind of endpoint protection platform, and have policies that any employee's laptop must run it, yes? Some of those systems don't support Linux, so you're busted right out of the gate. Some do, but IT has to do work to enable it: creating system images with it preinstalled, putting those on laptops, verifying that they work, etc. <dansa>ieure: oh, okay --- whatever absolute path I put there will work. okay. alright, that allows me go work on my next problems. (thanks so much!) <davidl>(maintain them being compliant*) <apteryx>podiki: would you be interested to be X-Debbugs-CC'd to that virtual machines new doc? <ieure>davidl, And even in IT orgs that are supportive of employees running Linux, most just don't have the time to prioritize the work. <ieure>davidl, The entire notion of stuff like Intune is pretty revolting to the sorts of people who want to run Linux. I don't think you're going to find much there there. Maybe Red Hat has something, since they're all IBM serfs now. <davidl>ieure: right the policies are there - but they are usually compliance based - so if Corp X has MS Intune, they need a Linux Profile which may or may not be worth the effort depending on stuff. I am aware about being the underdog in the situation :) however, talented staff is lost and Devs are a scarce resource, which is more and more evident to some businesses - providing Linux endpoint option while still being X-Compliant makes more sense than <davidl> ever. Canonical keeping up with MS Intune support is an interesting step in that direction, and even the ppl who want to run Linux would rather run an Ubuntu on their bare-metal than some MS or Apple system and Virtualize some Linux Dev VM. <vivien>(looks like use of microsoft intune use correlates with bad management practices if talented staff is lost) <rofrol>hello, I have logged in to guix on macos arm64 with virsh. I have build image myself from install.scm. <rofrol>For example `ls` works, but `herd status` just does not finish. I can press enter multiple times and it is not executed. <vivien>rofrol, this is the kind of things that happens when shepherd crashes <davidl>vivien: there are certainly talented MS folks and Apple folks, but the number of talented devs total are just scarce, so doing anything you can to maintain or attract employees has a higher weight to it than ever. <ieure>davidl, I don't think you're going to be able to square corporate locked down computing environments with Guix, since the former almost always violates Freedom Zero ("The freedom to run the program as you wish, for any purpose") <vivien>(as long as the solution involves microsoft intune) <ieure>I'm a pragmatist on this, not a Free Software absolutist, but the goals and designs of those systems are so wildly divergent that I think it's impossible to reconcile them. <davidl>ieure: you are probably right that I won't. If anyone learns of anything that pushes in that direction though Id be interested to hear about it. <ieure>Like: Guix lets any user install any software, as an explicit, fundamental goal. Corporate managed environments very frequently not only restrict what software a user may install, but what specific version of it. <apteryx>I guess Mark/Canonical long term strategy is maximizing their chances to be eventually bought for a bunch of billions from MS ;-) <rofrol>vivien: so what I can do? `virsh reboot guix` does not work. I need to run `virsh destroy --graceful guix`, but restart didn't help. <davidl>ieure: well, actually it can be things like if your endpoint protection software can no longer send you a guarantee that the endpoint is secure and running the latest versions of things, that endpoint X will no longer be allowed to connect to Corp Y VPN. For some compliance it might be enough with alert and response, rather than prevention, and there might also be room for creative solutions that are more FOSS adherent. <vivien>rofrol, I’m not sure I can help here. There are a lot of people familiar with shepherd that could maybe help you if you report this as a bug. <vivien>Well, not “a lot”, but a few very knowledgeable people :) <davidl>Plenty of businesses today are pretty much dangerously dependent on their developer teams. With some teams if they were to leave together for some new Corp, it would be a significant crisis for their current employer. This is power. Im saying that the playing field for FOSS enthusiasts keeps tilting in their favor in the Corporate world, and if there were efforts (which there are some of), things may eventually hit a tipping point making FOSS <davidl>the standard instead of MS or Apple. Compliance software, sandboxing features are current important obstacles in the path for that. <vivien>Are you also saying this to Microsoft, so that they implement a client for Guix? <ieure>I'm pretty jaded on FOSS becoming "the corporate standard." It already is for many, many things in the corporate world. Every company I've worked at for my whole career has run production on Linux, used numerous Free Software tools. But for the most part, it's a one-way relationship, they mine the value they can and contribute nothing back. <ieure>Now, that's fine under the terms of the license, but I certainly don't think "make it easier to ship proprietary SaaS junk" was a primary goal of FOSS licensing. <dansa>they contribute something: they're hiring skills <dansa>that's an important investment <dansa>they must be announcing that they need such skills <dansa>that's true, but they hire people who are skilled in free software <ieure>To build proprietary software. <graywolf>Is there some equivalent of --no-bootloader flag I could use in the (bootloader-configuration)? <dansa>in other words, they don't make the contribution we would like them to make, but they do make something that's positive for the free software world <dansa>yes, they build proprietary, but they're telling the market --- do learn how to use free software, otherwise I can't even hire you. <dansa>by the way, why do we say FOSS? <dansa>is that free open source software? <apteryx>does our Xfce or other desktops honor /etc/xdg/autostart scripts? <dansa>why don't we just say Free Software? <dansa>Open Source =/= Free Software <dansa>and Free Software implies Open Source. <singpolyma>Because there used to be a fight about it so people started saying both to shut that down <dansa>oh, but that's not a good thing <dansa>a good thing is clarifying things <dansa>blurrying the two different notions is not a competent thing to do <dansa>this is a technical world: we strive for clarity <podiki>apteryx: re: cc on vm networking: sure, though not sure I can be of much help unless I dig up my notes. But I can always take a general look. <podiki>vivien: re: gtk tests. thanks for the meson issue. I guess I can try removing from the test list in meson.build directly; once I figure out the actual name of the test :( <podiki>vivien: "gtk:tools / validate" test fails on gtk4 as well for me (on mesa-updates) so I guess I'll have to figure a workaround anyway <vivien>podiki, maybe the workaround is to switch to gnome-team :) <podiki>I mean I took your fine patches from gnome-team (all of them) on top of mesa-updates and sadly didn't fix it :( <podiki>but yes, this workaround will have to go to you as well <podiki>(thankfully I'm chilly so the "free" heat from compiling has some use) <podiki>yeah I was hoping newer gtk4 would pass, but whatever is wrong is still happening <podiki>any idea what "gtk:tools / validate" corresponds too in the tests? <podiki>sadly tools and validate are neither useful in my searches so far <podiki>ah found it I think, testsuite/tools/validate maybe <podiki>or no, that is just how tests are run :( <podiki>oh I thinkthat is the test and there is a meson.build in testsuite/tools <podiki>I will try removing 'validate' from testsuite/tools/meson.build... <podiki>so I used brctl (bridge control) but not sure what package that is if we have it <civodul>janneke: FWIW make-mesboot0 with v. 3.82 fails to build with “tcc: error: undefined symbol 'putenv'” <vivien>podiki, in the testlog-x11.txt, I read: libEGL warning: MESA-LOADER: failed to open zink: /gnu/store/zfaq6zl5xl419xy266mxl4am0mskafhs-mesa-23.3.1/lib/dri/zink_dri.so: cannot open shared object file: No such file or directory (search paths /gnu/store/zfaq6zl5xl419xy266mxl4am0mskafhs-mesa-23.3.1/lib/dri, suffix _dri) <podiki>ah good investigating, so it wants zink...not sure if we build it but we can <podiki>opengl on vulkan if i remember, if that means anything <podiki>someone was asking about if we should build that...can't remember who... <podiki>ah it did come up here recently, I should enable it in mesa then <podiki>this skips the test though: (substitute* "testsuite/tools/meson.build" (("'validate', ") "")) <podiki>i'm going to just guess that we can have zink everywhere we have vulkan....which i guess is just not arm32? <vivien>I’m not sure gtk wants zink, but maybe if you don’t enable it it’s not fully disabled <vivien>I have not found “zink” in the source code <vivien>(except in translations because it’s a part of a word in some languages lol) <podiki>the test log was just in the general tests run on x11? <podiki>someone here had an issue with mpv on ppc64le wanting zink <podiki>well I think I'll enable it everywhere and just see what happens, I think we'll want it (opengl on vulkan is becoming more needed as some devices don't support opengl directly) <vivien>In the log failure for gtk, after the summary of failures, there is this line: Full log written to /tmp/guix-build-gtk-4.8.1.drv-0/build/meson-logs/testlog-x11.txt <vivien>I just opened that and found the mention of zink <podiki>gotcha, forgot to look at full log <podiki>well I think it is good to enable zink anyway, so let me do that <vivien>We will let minimalists deal with the problems :) <podiki>well we do tend to be maximilists in enabling features in build :) <vivien>I love all these features, manuals and translations, I would be sad if we did not have them <podiki>ACTION builds mesa and gtk on this frankenstein branch and chases a cat <vivien>So, you’re going for another round of world rebuild I guess <podiki>just locally, is only a few packages (mesa, ..., gtk) <podiki>I'm guessing gtk uses zink when it can't use opengl <podiki>and that this failing test is something different, but only one way to find out <vivien>Yeah, if it can’t use opengl then enabling zink won’t help understand why unfortunately <podiki>but yeah, pushing a mesa change will do a bunch of rebuilds, but not bad compared to the xorgproto which rebuilds everything (via python I believe) <euouae>Hello I installed guix with gnome and in the near future I will reinstall because I didn't do the encrypted drive part <euouae>I was wondering if I can re-use the packages I downloaded. Can I save them somewhere and reuse them? (Is that another channel?) <vivien>Guix can be extremely pedantic and refuse to reuse a package if anything has been updated in its (recursive) dependencies. <euouae>that makes sense vivien, but can I still use the subtrees in the dependency tree that are left untouched? <euouae>I imagine not all of the packages get updated regularly <euouae>I guess you're saying it's not worth it? <vivien>Usually what you want is prevent the packages to be garbage-collected <vivien>If you install the package with guix install, then it won’t be garbage collected <euouae>yeah but in order to get an encrypted hard drive won't I have to reinstall from 0? <vivien>There are options to preserve virtual environments (made with guix shell) but I don’t exactly remember how <vivien>You could export all your package to an external drive, but I don’t know how you could later load them in the installation media <podiki>you could backup /gnu/store I guess <vivien>The guix-daemon won’t accept anything that has not been signed <euouae>vivien: I could start with a bare-bones install, then later mount the external hdd and load from there <podiki>is the goal to prevent redownloading due to bandwidth/time issues? <euouae>bandwidth is good here I get about 20MB/s <euouae>I was just wondering if that's easy to do, but maybe I shouldn't bothoer <podiki>it is pretty easy to reproduce the same packages/profiles, but as for the actual packages to use locally rather than downloading fresh, I'm not sure <vivien>Yeah, you will save more hair :) <vivien>ACTION ’s computer is on its knee applying grafts <dansa>I'm building a package that's failing on configure-phase because of: ``checking runas-user... xuser\nchecking runas-user uid... configure: error: user xuser does not exist. Please add this user before building.\n Most systems have man adduser or man useradd to tell you how to do this.'' However, the user does exist in the system. I suppose this user is not acessible in the chroot jail of the build system? How do you <dansa>guys work around something like that? <lispmacs[work]>hi, is there anyone here familiar with jupyter? I've installed the sbcl jupyter kernel, but I don't see a lisp kernel showing up as an option in the kernel list when I launch the notebook <vivien>dansa, this is a very rare case, most build systems don’t make such wild assumptions about the system <vivien>I guess you could try and find where this xuser is used, and if it’s for a test, you could then disable this test. <podiki>ACTION realizes "a few rebuilds" was more than "a few"... <apteryx>podiki: thanks! for a network bridge, the 'routed network' scheme covers wlan devices <vivien>(you should have the inkscape loop too) <vivien>(and maybe even some qt-base sprinkled on top) <podiki>yeah, inkscape built already.... <podiki>apteryx: I remember at the time it was very hard to find out how to bridge a wireless device, at least the basic consumer wireless, maybe easier with enterprise stuff <podiki>this was many years ago though, and I was new to all the vm stuff <dansa>vivien: it is fundamentally used by the software. It's a service, actually. The software runs as root but switches to a user if desired. I'm going to disable it and let it go for now. <vivien>I don’t understand why the xuser has to be present at build time but I have to go now, have a good night! <podiki>vivien: thanks for the gtk talk. I'll leave you some messages on how it all turns out