*vagrantc wonders a bit too <jlicht>would anybody /w subscribtion to guix-devel be so kind as to tell me if an email of mine reached the list? It's the "Re: Flag day for simplified package inputs" thread, message on 13/12/21. <jlicht>I don't see it in the online archives, which is why I'm asking! <vagrantc>jlicht: i got one with Message-ID: <865yrsa612.fsf@fsfe.org> <jlicht>thanks! Perhaps the web-based archive is lagging behind a bit <jlicht>It seems the thread split in two at an earlier message from Ludo', sorry for crying wolf <nckx>Checked for obvious repetition with sort | uniq -c, didn't catch any. <nckx>I do read it as being definitely the -certs that are the problem, which is info. <nckx>What I don't understand is why ./pre-inst-env from the same checkout I have in channels.scm, works. <jgart>I feel like this would be an excellent use case for guix if it works to pull in the python deps for the cl ffi all with one tool, guix <vagrantc>nckx: hmm... seems like xz is better compression than zstd, but at a massive speed cost <nckx>I think this is the very first application where I don't have a massive pro-zstd opinion, but I don't really have a strong opinion either way. <vagrantc>i hadn't really looked much at lzip before, but with the plzip it seems like an interesting candidate <vagrantc>i recall that lzip support was added for nar files a while back <nckx>Doesn't xz do parallel compression just as well? <nckx>‘Threaded decompression hasn't been implemented yet.’ Dunno about lzip. <vagrantc>pixz, plzip, pigz implement parallel compression of their respective compressors ... some don't do decompression ... zstd and lz4 implemented "native" compression/decompression <vagrantc>not sure how much parallelism matters for compressing log files... <nckx>I meant vanilla xz by the way, not a parallel (no pun intended) implementation. <nckx>I really think it's micro-optimising but then what is IRC for. <nckx>vagrantc: Unless they are first saved in their entirety and only then compressed, it's irrelevant. <vagrantc>just hadn't seen bzip2 being used anywhere else in a while <nckx>At lest the compressors I know don't do parallel streaming. <singpolyma>Switching from xz to plzip just saved me a lot of time moving nars from my CI to prod. That's the only place I use it so far <nckx>So yeah, replacing (package-version/package-source nss) in nss-certs with their literal counterparts makes guix show nss work again. <vagrantc>the "guix" package failing to build on aarch64 :( <singpolyma>Hey all: today I did guix pull and then ran some importer and they now produce inputs/native inputs without the string literals. Is this a new way things should be done now? <singpolyma>Is the input name just inferred from the package name with this format? <vagrantc>FAIL: tests/gremlin FAIL: tests/pypi FAIL: tests/guix-system <singpolyma>> Yes, we just changed how each of the 20K packages plus those in third-party channels can declare their dependencies. <singpolyma>nckx is a big fan of the wording in this blog post 😉 <podiki[m]>for what it is worth, Arch is (was?) using xz to compress their packages, parallizes well (not sure if vanilla or not) <nckx>I'm a bit dense tonight, I'm afraid I don't follow, singpolyma. <podiki[m]>but that was for the full package, not just text <nckx>I thought Arch switched to zstd. <nckx>I thought that was a Thing. <podiki[m]>and probably "switch" means changed the default, you could change compression options, on, off, core number in their package manager anyway <nckx>Actually it's a very specific mis-use of the word that triggers me so, it's hard to explain. I didn't notice it here. Perhaps I have mellowed with age since, er, yesterday. <nckx>I remember because, being Arch, of course there were people decrying the change. <kwjc>haven't had this build successfully for 2 days now building /gnu/store/fpcan04yfvcip6prnd6v6lcs9x41cy4r-icecat-91.4.0-guix0-preview1.drv... <podiki[m]>it is amazing how quick guix has supplanted my arch knowledge (even though still run 2 computers with it) <kwjc>yeah so 'guix package --upgrade . --do-not-upgrade icecat' completes the upgrade perfectly <vagrantc>oooh, search-input-file and search-input-dir! <kwjc>but regular 'guix package -u' it just hangs up with icecat <nckx>In my quest to fix the module cycle I have broken things harder \o/ <kwjc>nckx: building /gnu/store/fpcan04yfvcip6prnd6v6lcs9x41cy4r-icecat-91.4.0-guix0-preview1.drv... <nckx>And it's not building anything? <kwjc>it'll go from unpack, to the next phase, to the next phase, and then it crashes my system <nckx>Okay, it needs a lot of RAM. <nckx>I don't know exactly how much. <nckx>Also make sure you're not trying to build in a tmpfs /tmp. <kwjc>yeah I don't have that much only 4gb I think <nckx>Because that will use gigabytes more. <nckx>I doubt that's enough, sorry kwjc. <nckx>I wouldn't try with anything less than 16. But I haven't tested 8. ***Server sets mode: +Ccntz
<kwjc>nckx: *shrugs* guix install icecat; guix package -u <nckx>If it didn't take hours that's a ‘no’. <kwjc>welp that sucks. no fancy browser for me I guess *nckx notices grunewald is still idle. Not today, Satan. <kwjc>nckx: well, thanks for clearing that up. I don't actually mind using something simpler like lynx, or w3m, or epiphany <nckx>Epiphany hides it's complexity behind WebKit (which I would not call ‘simpler’ than IceCat, in fact I think it's the opposite) but there might well be a substitute for it, making it more suitable to your short-term browser needs. <KE0VVT>hint: Did you forget a `use-modules' form? <nckx>I think both are examples of poor questions: (1) vaguely claims you have to do something without explaining what, (2) omits any error that could be used to help you. <nckx>You're making it needlessly difficult to respond. <flatwhatson>I'm getting a "staging" commit from channel-with-substitutes-available. Looking at the API JSON, seems we should pass an extra parameter jobset=guix in the latest-builds routine in guix/ci.scm? <KE0VVT>nckx "/etc/config.scm:28:12: error: make: unbound variable" but I have (use-package-modules curl admin emacs vim ed tmux screen fonts version-control gnuzilla base python web-browsers) <nckx>It's also called gnumake I believe. <nckx>You're mixing package name strings with variables in your list, which is fine and works, but using e.g. (map specification->package "nss-certs" "make" "etc") is easier. Guix will import any needed modules for you. <nckx>And you'd use the package names as shown in the Guix CLI, not variable names, which can differ as you found out. <KE0VVT>nckx I was going by (use-package-modules curl admin emacs vim ed tmux screen fonts version-control gnuzilla base python web-browsers) <nckx>I don't understand what you mean by that. <KE0VVT>location: gnu/packages/base.scm:489:2 <nckx>‘Going by’, and to what? <nckx>Right, but the variable is gnu-make, not make. <nckx>The CLI doesn't give you that information directly (it probably could) but if you look at that file and that line, define-public <this> is the variable name. <nckx>Using specification->package side-steps that by looking the package up by the ‘name’ field a few lines down. <nckx>It's not efficient but it's friendly. <KE0VVT>Oh! I didn't know specification->package took mult. package names! :D <KE0VVT>Do I still need to (use-package-modules vim)? <nckx>KE0VVT: It doesn't, but that's what map does. I made a stupid typo though. <nckx>I meant (map p->s (list "a" "b" …)) <nckx>I forgot the list, sorry. <nckx>KE0VVT: If you add "vim" (quoted) to the list of strings passed to p->s and remove the unquoted vim from the list, you shouldn't need it. <KE0VVT>So, (package->specification (list "emacs" "vim" "tmux")) nckx? <nckx>(map PROC LIST) returns a new list with PROC applied to each individual element of LIST. <nckx>E.g. (map string-upcase (list "a" "b" "c")) <nckx>Here, it will turn your list of strings into a list of real package objects by looking them up by their (name "foo") field. <KE0VVT>nckx: I think so. I will edit it to correspond to what you said. <nckx>It will run (=call, invoke, …) p->s on each string in the list. I'm not sure I understand the question though. <nckx>And apologies if I made any more typos in my examples. I'm distracted. <KE0VVT>OK, so it will run the thing it creates. Good. <nckx>(map …) returns a list, not a single package; which is convenient but don't forget to adjust the surrounding code. For example (packages (append (map stuff we discussed) (list any remaining package variables or delete this list) %base-packages)). <nckx>If you move everything to name strings, it would look like (packages (append (map specification->package "nss-certs" "emacs" "vim" "ed" … "cowsay" "torsocks") %base-packages)). <nckx>Oh, and the failing to deal nss has been ‘fixed’ but not well. <flatwhatson>i sent in a patch for channel-with-substitutes-available returning a staging commit <Zambyte>I think the tcc package might be broken right now. Can someone do a sanity check with `guix build tcc` for me? <the_tubular>Longuest guix system reconfigure in a while, closing in to 10 hours <nckx>That checks only guix (to speed up ‘guix pull’ itself, which can be pricey), not other packages. <vldn[m]>is it possible with some guile magic to make it Aware of all packages? <nckx>I know it's not good, but considering icecat's unbuildability on a wide range of hardware & its importance, I'm starting a build manually… <nckx>Well, you could use ‘guix weather’, but that can only answer ‘how many of these packages are available as substitutes’, not ‘which commit has over N% of these packages substitutable’. <nckx>Modifying find-latest-commit-with-substitutes to return a commit that has >N% of *all* packages substitutable looks easy, but having it do so for a specific subset (like your manifest) less so. You'd have to make one HTTP request per package and manually calculate a good-enough commit… <nckx>Actually the former isn't that easy either because N has to be 100 for that to work, never mind. <flatwhatson>weather for icecat and ungoogled-chromium seems like a reasonable heuristic <nckx>It'll be different for everyone. <nckx>It can check whatever commit you like with time-machine, but it's relatively expensive (not something you want to run in your channels.scm). <nckx>I think you're better off iterating over a queried list of Cuirass evaluations at that point. <nckx>To do, er, something, with, like, maths. <nckx>icecat hasn't even started building yet because the head node is still sending mozilla-locales to the build node. <apteryx>nckx: what's happened to the substitutes? they wen't from like 53% to 5% earlier today <apteryx>no, that wasn't it; master was already in c-u-f, and c-u-f itself had 53% <nckx>I don't know otherwise, I wasn't here for the messing-with-broken-cuirass part of the programme. <nckx>That would match ‘5% earlier today’ and ~20% now. <nckx>I don't mean the commit it happened to pull to then. <nckx>mothacehe erased the database (all of it? some? no idea) so Cuirass might not be aware of all store items. However, I'd expect rediscovering them to be I/O busywork that shouldn't take 24 hours… even on I/O starved berlin. <nckx>I'm veering into guessing and will stop. <nckx>It took 20 minutes to copy all missing icecat build inputs to the build node. <nckx>Oh god, this is just the makeicecat part. I hope icecat itself won't be built on another node… <apteryx>that's the time it takes to build icecat on a ryzen 3900x <nckx>As well as on these build nodes (some kind of Ryzen too). What a waste. <nckx>At least it's running sed, like, *really* fast. 😒 <apteryx>seems most of our problems come down to Berlin's poor IO <nckx>I'm pretty sure the LAN is gigglebit if not more. <apteryx>perhaps it'd be a good investment to go full solid state storage on berlin <apteryx>being the head node amassing tons of stuff it'd pay back I'm sure. <nckx>another strategy is adding so much storage that we never need to GC. <apteryx>that day will come closer than you think, and when it comes, it'll be 1 month of GC instead of 12 h <nckx>Either way pudding the DB and possibly everything not /gnu/store on SSD is absolutely a good idea. <nckx>apteryx: I mean literally never, to be clear. Like Chris was discussing for bordeaux. But it is not trivial, sure. <nckx>You add several tens of terabytes of storage? <apteryx>and then you extend the array is it grows? <nckx>I think a full world is about ~100G now. Guix is big but not so big that throwing a 50TB array (or whatever) at it now won't buy you many years. <nckx>Maybe a bit bigger by now, but that order of magnitude. <nckx>I was just pointing out an alternative to expensive high-quality storage, not saying I prefer either. <apteryx>yeah. I prefer the simplicity/versatility of having a workable GC around. But I should try to experiment with Btrfs deduplication again. zstd compression makes a lot of sense for berlin <apteryx>perhaps btrfs dedup would outperform our primitive solution (which is turned off in nix I've heard) <nckx>I don't see how an external service that has to re-read all data could outperform it. <nckx>You'd have to win all that back just by faster deletions. <nckx>Well, fragmentation is magic, so who knows, perhaps you actually would. <apteryx>I'm hoping that btrfs keeps enough metadata abouts its block to do so cheaply, but that's just me hoping <nckx>I don't know enough about btrfs internals to know if their integrity checksums could be reused for that, but it would make sense. <nckx>‘Caution: Don't run this [mode], if you don't know what you are doing’ seems to apply to that, but hey. <nckx>Otherwise, ‘it uses the fideduperange call, which asks the kernel to verify given regions byte-by-byte, and only perform dedupe when they match.’ <nckx>I wonder if it matters, since that's only for the actual deduplication. *nckx → bed. Try to substitute icecat in about half an hour, flatwhatson, if you want. It should be done by then—or failed. *vagrantc wonders if these tests are entropy-bound <podiki[m]>i can share parts of /dev but would like to just have the whole thing in there... <podiki[m]>ah, I guess it shares part of dev no matter what, so can't just do --share=/dev <taterbase>I have a makefile that relies on the python executable. When I install python from the guix packages I get a binary called python3 but not just python. What is the proper way in guix to create a symbolic link for python to python3? <taterbase>Oh looks like python-wrapper takes care of it <mroh>taterbase: try the package python-wrapper <bdju>can anyone recommend a program on guix for opening .ics files? it's something calendar-related. if opened in nvim it mentions microsoft exchange. I got one in an email <bdju>I'm running Sway, so I'd rather not pull in a GNOME thing if I can help it <jackhill>bdju: https://lostpackets.de/khal/ perhaps? Are ics files plain text? I use a paper planner, so my expericne has mostly been starting at the text reprentation of events until I could make sense of the data format and then writing it down on paper :) <jackhill>(and that might give you some other options to try) <guixy>I'm trying to use tools in my guix home profile to learn things like autotools and ncurses. The program appears to compile correctly with the gnu build system, but ldd reveals the binary doesn't specify where the ncursesw.so.6 file is supposed to be. <guixy>Is there something I'm supposed to include when I `./configure` or `make`? <guixy>by "my guix home profile" I mean ~/.guix-home/profile <guixy>At least I'm happy to report this is not the case in a container shell with the usual bash coreutils sed gcc-toolchain ncurses gawk grep and make packages <apteryx>so the error that caused failure to SSH in my remote box is this at the end of 'guix deploy' is this: sshd[29578]: error: PAM: pam_open_session(): Module is unknown <apteryx>beware if you are going to 'guix delpoy' to a remote machine you only have SSH access to. <guixy>apteryx: I've seen that. PAM is not installed by default. I can't add the PAM service with `guix deploy` :( <guixy>Or at least, PAM is not installed to a guix server config by default. <apteryx>pretty sure the config I'm deploying to has PAM; it's a full-fledged GNOME desktop machine. <apteryx>perhaps it just needs a reboot in my case <guixy>You aren't removing it, are you? <apteryx>shouln't; I haven't touched the config <apteryx>just using a recent guix post c-u-f merge <apteryx>well, it seems it didn't update the bootloader, so it rebooted in the previous generation, which works and allows me to SSH <apteryx>the core-updates-frozen branch, but you don't need to care about it anymore (it's been merged into master and deleted) <flatwhatson>in another distro this might be considered something like a point release <apteryx>but people using 'guix pull' are essentially already on it <apteryx>perhaps using (use-pam? #f) would be a good idea in general for openssh <timmy>is anyone using seatd and sway? i'm trying to figure out a clean way to set it up after upgrading sway and it breaking due to the new seatd dependency <apteryx>the default UsePAM defaults to no upstream, but in Guix we set it to #t. <apteryx>guixy: if UsePAM is set to 'no' for the remote sshd, then it succeeds :-) <apteryx>I'll propose having UsePAM disabled out of the box on Guix, as it's the way it's supposed to be according to 'man sshd_config' <taterbase>is it possible to install two versions of the gcc-toolchain? I'm looking to install a 32 bit one alongside my 64 bit toolchain <taterbase>I really just need to point CC=$(which 32-bit-gcc) <guixy>After recent merge, `guix pack synfig` revealed synfig conflicts with itself... <guixy>I'm tempted to put the guix package in my guix home profile so the packages only update every version bump. That would make it more stable, but I'd miss major security updates. <guixy>My main user is not in wheel though. <guixy>And I don't have anything worth stealing in ~ <apteryx>guixy: that's an anti-pattern and would probably break something <sozuba>jpoiret, disabling the systemd-reolved.service or any other dynamic dns configuration tool and specifying a working nameserver in /etc/resolv.conf would solve that network issue when installing guix in qemu vm. Thought i would share those, so this could serve as a work around for people who face the issue. This could be mentioned in the docs/wiki <sozuba>too for the timebeing if that might help. <sozuba>Another bug i noticed was that, despite having chosen not to install any desktop service and cups, these packages appear in the generated configuration file by the installer. I could see cups, xorg and desktop. Just thought you should know, so you can raise a bug if you have time. <guixy>apteryx: I found out the hard way putting guix in my guix home profile isn't the best idea. Packages added after the most recent version bump are unavailable, as are the security updates I mentioned. But it's an interesting idea to contemplate. <guixy>I had to alias guix=~/.config/guix/current/bin/guix to fix a home that was configured between bumps. <taterbase>Regarding my earlier question about installing another gcc-toolchain for 32 bit systems, I found this worked guix build --system=i686-linux gcc-toolchain <bdju>I seem to get instantly disconnected when sshing to my computer running guix system. any ideas what could cause that? it lets me in but then disconnects me <bdju>`sudo herd restart networking` didn't seem to change anything <podiki[m]>bdju: that came up the other day here, unless that was you maybe search the logs over what was found <bdju>worked before I ran updates I think. I was on an 11-days-old guix before <bdju>probably shouldn't have updated right before bed, I guess. expected to be able to control my music on my pc over ssh from my phone <bdju>must be a system config change because I haven't gotten my manifest upgrade to go through yet (keeps hitting errors) <lfam>Dang, that's no good. We'll have to get to the bottom of it soon <bdju>it might be. I'm not using guix deploy, but considering the timing it's somewhat likely <bdju>well, setting use-pam to false didn't seem to do the trick <bdju>will check back tomorrow I guess <lfam>Yeah, the deploy thing could be a red herring <lfam>Did you definitely deploy the usepam=no sshd? <lfam>Like, reconfigure and `herd restart ssh`? <lfam>You can also do `ps aux | grep sshd` and read the configuration file that is named there <dhruvin>Hello. In recent guix we might have introduced something that requires guix pull to be run inside a terminal. I thinks this breaks automated guix image builds, as the function terminal-window-size raises "Inappropriate ioctl for device" when not running in PTY. <dhruvin>correction: reading the error message: have we had a downgrade in channel? <podiki[m]>maybe depending on what branch/commit you were on befor the big <dhruvin>update: by allowing downgrades, I saw that display-hint wasn't called. which made guix pull run successfully without terminal. display-hint seems to be assuming that we're running inside a terminal. <podiki[m]>your commits look funny though, it was trying to pull into a commit from june <dhruvin>podiki[m]: fwiw, the builds are running nightly, so I must be on one of the commits a day before. <podiki[m]>maybe it ran in the middle of the merge or something? <dhruvin>i just ran it, see my messages above (of [un]successful build) <podiki[m]>650459 was also trying to go backwards (2 weeks) <dhruvin>podiki[m]: you're right. it ran several hours ago, it failed, I assumed it'd be due to pending merge (what you suggested), then ran the job again. it failed again. <podiki[m]>maybe just got in a funny commit somehow? could have gone back to a previous guix pull generation first <dhruvin>Sorry I coudn't understand what you said. <eyJhb>I heard that the guix store has security/is not world readable. But I can't find any documentation on it/how it works. Anyone able to help me out? <cehteh>it is readable just not writeable <cehteh>looks like its just a bind mount with readonly flag <jgart>Does anyone happen to know the amount of work involved to port GNU/Guix to run on musl? <eyJhb>So there's still the same issue in Guix as in Nix, that stuff in store can be read by all users, and therefore don't put secret stuff in there? <jgart>I remember there was a netbsd packager/developer that was working on it <jgart>They also contributed to Guix regularly some years ago <jgart>I think if GNU Emacs can run on musl then so should GNU Guix ;) <podiki[m]>dhruvin: i meant you could roll back guix pull to something older before whatever happened, then could update from there; but no matter <cehteh>i wonder if one could add normal unix permissions to protect certain store things from reading by normal users no idea if thats even implmented <dhruvin>podiki[m]: okay, that clarified. thanks. I'm actually looking into what went wrong, as soon as I discover it, I'll try to do what you said. <eyJhb>AwesomeAdam54321: Passwords? Ie. wifi configuration files that you would like to manage using Guix, and not just point at <cehteh>AwesomeAdam54321: i tihnk currently its meant to be public, but i could imagine a future system that may store secrets there as well <podiki[m]>dhruvin: guix pull having it's own generations is pretty neat, you can look there to see the progression of commits (list-generations) <cehteh>i havent looked at guix-home but imagine you can store your .ssh in the store <dhruvin>podiki[m]: the ci build will only have 1 generation. since the images are built from scratch. <cehteh>which prolly needs a lot work to be sane, you dont want your guixd as substitute server to blow your ssh keys into the world <dhruvin>I think I found the problem. This was mind blowing. My channels.scm asks for a commit (of guix channel) for which `guix' is prebuilt on official servers. Somehow, the official guix servers returned a commit several months ago. This prevented guix upgrade, because it essentially is a downgrade. <dhruvin>to summarize: my guix channels is configured to pull to a commit for which `guix' is pre-built on ci. CI returned a commit that is dated several months ago (issue 1). guix pull recognized the downgrade and tried to tell me to allow downgrades if that's what I intend. To do so, it called display-hint, which assumes that we're in term (issue 2). <Kolev>It's hard to edit Lisp in Nano. Unmatched parentheses everywhere. <rekado>jgart: not going to happen. There’s no good reason for us to revamp the bootstrap to work with musl instead of glibc. And doing both is just a waste of resources in development, maintenance, and compute time. <dhruvin>It'd be great if someone from ci team can confirm weather channel-with-substitutes-available (from (guix ci)) returns latest commit or not. <rekado>jgart: ng0 had many dreams of doing things differently, but few of them ever led to code, so there’s nothing you could continue. <rekado>dhruvin: it uses find-latest-commit-with-substitutes <rekado>it uses latest-build to check the substitute server’s API for the most recent build of guix.* derivations <rekado>apteryx: is IO really that bad on ci.guix.gnu.org? <rekado>there isn’t that much I could possibly do to improve it. <rekado>the storage array is attached over just one of the two HBAs <rekado>if we had multipathd in the initrd we could use both HBAs for redundancy or round robin access <rekado>that’s the only medium impact change we could perform without having to replace disks <rekado>if you have a workable, reliable btrfs config: we could use that. But note that someone would have to migrate all the existing files. And that takes space and lots of time. <rekado>(we could probably copy things over to a SAN, but it would not be fast, and during the final sync we wouldn’t be able to use the system) <rekado>re SSDs: someone’s got to buy them. <rekado>we’re waiting for a response on funds <rekado>but if our request is denied we can’t *just* go ahead and buy a lot of SSDs and have them shipped to the MDC. <rekado>this stuff is expensive, but less so when purchased through institute contracts <rekado>and the reimbursal process with the FSF makes it difficult for us to just go and spend 30kEUR <cehteh>rekado: do you run some test server (development workstation/personally)? ... you may play with dmcache and see if that gives any significant improvement, That would be a good opportunity to save some money with less SSD's <cehteh>here with dmcache my workstation can walk 200Mio files 5TB in just about 1hr, and i am still optmizing the directory walk code <rekado>I really don’t have the free time needed to play with systems. <rekado>if someone has a patch for maintenance.git I’d gladly apply it <rekado>and if that requires stuffing some SSDs in some empty server slots, I’ll do that too <bricewge>How do you handle patches in your own channel, to avoid putting them all at the root of the channel? <rekado>dhruvin: I don’t see any restrictions on spec in latest-builds <cehteh>rekado: i am more a software guy too .. and i am working on implementing the rmrfd as sketched some days ago, guix gc may eventually benefit from that too <rekado>would be worth checking if you could get a build of guix.* for any spec (e.g. core-updates, or master, etc) <bricewge>I know I can parametrize %patch-path on a module by module basis (or package). But can it be adjusted channel wise? <dhruvin>rekado: Thanks for looking into it. I'll follow your suggestion. <jgart>has anyone tried running Guix on alpine linux? *jgart is no glibc/musl expert <rekado>it comes with its own copy of the libc <jgart>rekado, so it would run fine then on alpine linux if I just download the binary is what you're saying? <jgart>Could I use musl-nscd for the application setup instructions regarding the Name Service Switch? <civodul>jgart: it depends on whether musl-nscd implements the same protocol as GNU nscd <civodul>there were discussions about this and it would seem the answer is "yes" <civodul>now, if /etc/nsswitch.conf contains the default settings ("files", "dns", etc.), glibc embeds everything it needs to make it work <civodul>rekado: i'm preparing a call for an "infrastructure hackathon", say on Dec. 21 <jgart>civodul, thnx Are those discussions on the mailing list? <jgart>Ok, I'll try grepping my way to that <fiesh>`guix pull` made `guix` result in an immediate segfault... :/ <civodul>fiesh: what command segfaulted? 'guix pull' itself or some command afterwards? <civodul>IOW, does "unset LD_LIBRARY_PATH" make a difference? <fiesh>if I could install gdb, I could get a backtrace ;) <fiesh>hmm but then it's in root's profile <fiesh>ah hmm loging in anew fixes the issue for some reason <civodul>fiesh: oh, so it would seem like some env var led Guix to load the wrong thing somehow <AwesomeAdam54321>fiesh: Even though it might not be as comprehensive as gdb, if you ever need a trace you can use a trace program, like for example strace <rekado>civodul: infra hackathon sounds good, but I’m not sure if I’ll be able to hack on that day. Will get my booster jab and I guess I’ll be a bit of a wreck then. <rekado>NicholasvonKlitz: typescript can be transpiled with esbuild. <rekado>but dependencies that are installed via npm are usually very, very messy <rekado>it’s not a simple package, though <fiesh>AwesomeAdam54321: oh yes, good point <civodul>rekado: yes, and it's a busy time of the year; but we can have that first one and a second one in January when we're all locked down at home ***zimoun` is now known as zimoun
<NicholasvonKlitz>Another question... there are several rust-gtk packages (Fractal, Authenticator, Shortwave, etc.) built with meson, that would be great to package. I'm looking through the various build system, but I'm not sure there is one that is well suited for this. With the current meson-build-system I have no idea how one would declare cargo-inputs or cargo-dev-inputs. Is it necessary to make an additional meson-build-system based of the <NicholasvonKlitz>I guess you could also just scrap meson and use the bare cargo-build-system and add a gtk-wrap phase <civodul>NicholasvonKlitz: efraim and others would know better, but i think you can look at librsvg@2.50 for inspiration <civodul>ah maybe not, i thought it was built with Meson but apparently not <civodul>but yeah, you could choose cargo-build-system and then add meson as an input and replace the 'build' phase <NicholasvonKlitz>makes sense. I just see quite a few apps using this setup, so it might make sense to have a build system like this sometime in the future (cargo+gtk+meson) <rekado>got pretty far in building icedtea 2 directly (skipping the build of icedtea 1), but there’s an error when the built JDK is to be used to compile something. <rekado>I’m hopeful that I can work around this. Would be lovely to get rid of the earliest icedtea package. <jlicht>rekado: is there any additional benefit to this, besides having a shorter (and more easily maintainable) bootstrap path for java going forward? ***hollowman6 is now known as hollowman
<civodul>which already sounds like a great selling point to me :-) ***hollowman is now known as hollowman186
***hollowman186 is now known as hollowman
<clemens3>rekado/jlicht.. just finished bootstrapping rustc for my linux setup.. very much into doing the same for java later on, i hope you leave some document trace somewhere, also for people not knowleadgable about guile <rekado>clemens3: do you mean outside of Guix? <rekado>jlicht: I just don’t like icedtea6. It takes a long time to build, requires a lot of patches, and the package definition is just so long and makes me dizzy. I want it gone. <rekado>clemens3: generally, the code is the documentation. It’s very easy to follow. There’s also a big picture comment at the top of the file, and some comments whenever something tricky happens. <rekado>clemens3: where would you use it? <clemens3>i couldn't reproduce the guile java bootstrap thingy complitely, got till classpath dev step <clemens3>i could of course setup a guix vm for experimentation.. <clemens3>but is generic for most linuxes, i think <clemens3>anyway, i know who to ask about java later on.. <clemens3>many years ago i once head the sun java source code, back in the day it relied only on cc <rekado>you can ask me, of course. But I can only poorly transcribe what the code says we’re doing. <clemens3>got it compiled, but when openjdk was released, it was already circular <clemens3>yeah, no obligation, just good if I know someone <attila_lendvai>guix build issues a *warning* for this: "guix build: warning: failed to load '(nongnu tests swarm)'". now, this is less than useful. shouldn't this be an error (and preferrably with a backtrace)? <attila_lendvai>tried to add #:on-error 'backtrace to the load* calls in (guix script build), but this is coming from somewhere deeper <roptat>2.15.0 was discovered to be an incomplete fix, so I updated to 2.16.0. Hopefully, it fixes the CVE for good :) <tschilptschilp23>Sry, I'm only talking about 'unzip' as dependency. So it might not be related to the link above. I just encountered it with those... <attila_lendvai>FTR, the issue is not in guix build, but in the system tests manifest file (explicitly asks for warnings only... bug why???) this things are wasting so much time... <civodul>it's crazy that a printf-with-non-literal-format-string kind of vulnerability shows up in 2021, and that it takes several iterations to fix it <vivien>(all my printfs have a gettext of something as their format strings) <vivien>Wasn’t someone working on a scheme syntax for the opensmtpd configuration? How did that end? <mothacehe>pankow went offline soon after i restarted the cuirass-remote-worker service rekado, any idea why? <rekado>mothacehe: kreuzberg says “latest handshake: 1 hour, 12 minutes ago” <rekado>I restarted the cuirass-remote-worker <rekado>on pankow: latest handshake: 18 minutes, 20 seconds ago <rekado>restarted the cuirass-remote-worker <vivien>Are all those handshakes covid-safe? <rekado>the problem with these is that I cannot really reboot into the reconfigured system <mothacehe>ok thanks. for some reason the arm workers do not perform as well as the intel workers. <rekado>because of that weird ’guix deploy’ behavior <rekado>I think the problem is still with the OS config; they don’t keep the wireguard connection alive <rekado>I used “guix deploy” to update them with the new config, but I can’t reboot into the new system as ’guix deploy’ pushes some x86_64 binaries to them. <mothacehe>oh that's bad, is there an open ticket about it? <civodul>ah i need to resume debugging on that one <rekado>mothacehe: there’s only a discussion with the sysadmins; Message-ID: <87k0gosbbr.fsf@elephly.net> <rekado>I wasn’t sure if it’s just a matter of me holding it wrong <paxton>sorry if this has been mentioned before, but suddenly after a guix system pull & reconfigure, the font size on gtk programs is *very* large <paxton>does anyone know what could be causing that? trying to set the font in .gtkrc doesn't seem to work <rekado>paxton: I see some … unusual font rendering on my system as well. <jpoiret>does this happen in Xorg or Wayland? <paxton>jpoiret, this is in xorg, in openbox <jpoiret>seems to me that GTK3 has its config in .config/gtk-3.0/settings.ini <jpoiret>although it's weird that this is happening after a reconfigure. Are these programs using GTK3 or 4? <paxton>the strange thing is that i've also set it there! that file contains: <paxton>jpoiret, i'm not quite sure how to tell which gtk version a program is using <jpoiret>you may be aware that there was a big merge 3 days ago with a lot of updates <paxton>right, yeah; i pulled those in yesterday <jpoiret>paxton: if you do `guix size /gnu/store/the-derivation-output/ | grep gtk` on the store directory containing your program, what do you see? <paxton>i only pulled and reconfigured the system guix, not my user's guix, which makes it stranger <jpoiret>to find out where your program actually is, use "readlink -f $(which theprogram)" <paxton>curioser and curioser, guix size says the two programs i tried that on are not in the store, e.g. "guix size: error: path `/gnu/store/f85hm0xsh98z757vfci1476pa8lj032x-keepassxc-2.6.6/' is not in the store <civodul>paxton: does it work if you remove the trailing slash? <paxton>civodul, whoops! yes, it does. thanks for that <paxton>jpoiret, it seems these programs are using gtk+-3.24.24 <jpoiret>hmmm, so it's not that at least. Maybe something has changed in DPI calculation? <jpoiret>does xdpyinfo report the proper dpi? I remember GTK also ignoring that DPI, using its own, not sure how though <jpoiret>do you have a "nonstandard" dpi? eg small 1440/4k monitors <paxton>that might be it, as i had to bump my preferred emacs font down two sizes because it was big, too (Monospace 10 -> 8) <jpoiret>it's near impossible to have a proper dpi scaling under either XOrg or Wayland, since some applications completely disregard it <paxton>this laptop has a 1280x800 screen, which is probably nonstandard / weird by this point <paxton>we're at 1280x800 with 114 dpi, according to xdpyinfo <jpoiret>was emacs bumped along with your reconfigure? <jpoiret>27 uses harfbuzz instead of the older font rendering, something might have changed there (although 27 is pretty old at this point) <paxton>jpoiret, actually, no. only the user has emacs installed, and i didn't pull/upgrade the user's guix <jpoiret>I'd upgrade my user packages as well at least <paxton>i'll see what happens. the build was failing on lagrange, a program i have installed (for unrelated reasons, i'm sure) <jpoiret>mothacehe: do newt programs work in a graphical terminal? *paxton pulls and upgrades <jpoiret>i'm wondering if we could instrument installer tests without qemu: my specific use case is adding a screen to manually configure things that might not be configured by DHCP, eg DNS if the server doesn't have one, or even the whole networking thing. To test that, we'd need to have a TUN/TAP interface so that we can run our own DHCP server, since <jpoiret>QEMU's built-in SLIRP includes a non-configurable DHCP server <jpoiret>so I was thinking of using network and user namespaces so that we could still run the tests unpriviledged <mothacehe>jpoiret: yes newt programs work in a terminal. In fact I developed the installer on my host machine in a terminal. Just never took the time to integrate this mode properly. <mothacehe>But doing so would definitely be great for people developing on the installer. <jpoiret>oh, nice! do you think it would be useful to be able to test the installer in a container, rather than in a VM? I reckon we won't be able to test devices (or maybe we could, i'm not sure if we can emulate devices using disk images, qemu-nbd comes to mind) <mothacehe>even if the installer tests are super fragile and hard to maintain, they have the benefit of an almost full integration <mothacehe>but that doesn't mean we cannot have a guix command running the installer in a terminal for debug/devel purposes <jpoiret>sure. I'll first look into adding the manual networking page first (maybe even just the DNS config one) as that was a blocker for a user. Maybe we could also document it in the manual for the manual installation process? It goes from `dhclient` straight to the install, maybe a heads up for common networking pitfalls could be great? <civodul>this reminds me: we should remove the "GNOME" choice from the installer when on i686-linux <mothacehe>jpoiret: yup, network configuration is definitely one of the cruxes with partitioning in the manual installation mode <paxton>hmm, upgrading my user's packages doesn't seem to have done anything to fix the font size / dpi <paxton>i might be stuck with that new way of calculating it, although i guess i could revert, see what dpi it was before, and try to force that somehow <tralala_shalala>I need some help and would greatly appreciate it. I get an exit-status 2 for iptables-restore services ("start" command) when running guix system reconfigure. I've pretty much copy pasted the suggested iptables configuration as is from the guix info manual. http://ix.io/3IAU. Not sure what the issue could be <kwjc>all my icons in xfce are messed up now? <tralala_shalala>At some point i vaguely remember (but couldn't capture) saying that :input is an invalid argument <kwjc>tralala_shalala: might take many hours, but someone knowledgable enough will prob help if you stick around long enough. trust <nckx>I can't help, but if you simply copied (and it looks like you did, correctly) the manual example and it fails, that's a bug. <unmatched-paren>wayfire's latest release was in all the way back in june, should i use the latest git commit? <tralala_shalala>nckx: thank you, I'll look into the firewall service& syntax. all the best <nckx>unmatched-paren: Not unless there are more pressing arguments. <unmatched-paren>ok, i'll just put a nightly version in my channel for personal use then :) <nckx>‘The easiest way to install Wayfire, wf-shell and WCM to get a functional desktop is to use the install scripts’ bodes super well. <nckx>unmatched-paren: I didn't mean to discourage you, I just meant that we don't package git snapshots merely because the release is a few months old. <nckx>However, if it's unreasonably buggy, or if the surrounding software (wlroots etc.) have moved on making it hard to build with the versions in Guix, etc., those would be good reasons. <unmatched-paren>the script is basically just 'clone, check for libs, run meson build, then install the binary and configs and stuff' <nckx>In those situations we'd expect upstream to make a release, though, but sometimes they don't… <nckx>unmatched-paren: Clone latest master? <unmatched-paren>hmm, is there a way to install the config to ~/.config in the recipe? <nckx>So the recommended way (and what the developers actually dogfood) is not to use the release. Bah. No wonder they're not bothered to keep it up to date. <nckx>unmatched-paren: This isn't usually a problem? Does it not fall back to sane defaults if there's no user configuration (yet)? That's how all other software manages. <dissent>hey guix, anyone else having trouble with php after the recent updates? also having trouble with volumeicon (of all things) -- it won't launch. <nckx>That's just not very nice. <nckx>Off the top of my head, you could wrap wayfire in a bash script that copies $out/share/blah/wayfire.init to $HOME/.config/wayfire.ini if the latter doesn't exist, then execs wayfire. <nckx>But better than mysterious failure. <rekado>dissent: what does “trouble with php” mean? Fails its test suite perhaps? <attila_lendvai>my gedit is old, but i can't find out where it is coming from. guix package --profile=/run/current-system/profile/ --list-installed | grep gedit comes back empty. gnome, that lists gedit as its dependency, is v41.0, i.e. new. which gedit => /run/current-system/profile/bin/gedit <attila_lendvai>i know i can install gedit explicitly, and it will (probably) update it... but shouldn't this happen automatically when i guix system reconfigure (and have gnome as a system package)? <nckx>dissent: Is it supposed to look incomplete? <attila_lendvai>hrm. my user sees gedit 3.34.1 while root sees 40.1 (as per gedit --version). but guix package --list-installed doesn't list gedit anywhere (my user, root, /run/system/profile). <nckx>PHP failures are usually test-suite related, not at the beginning of the build phase. <nckx>attila_lendvai: What does root see for ‘which gedit’ then? <nckx>Make sure you're running guix package -I as root (not just sudo) to rule out spooky environment variable action. <attila_lendvai> /run/current-system/profile/bin/gedit --version comes back as 40.1 <nckx>Oh, so your user has an older gedit. <nckx>* What does [user] see for ‘which gedit’ then? :) <dissent>nckx: no but it seems its so long that termbin cuts it off. <nckx>dissent: Try sharing the tail instead of the head. <attila_lendvai>no, it's not the user either. it's something with terminals being open from before the update. although, i have sourced my user's profile and closed/reopened terminal windows multiple times. probably i confused myself, but i only had two terminals open. <nckx>That's been reported… somewhere… <nckx>(Hm, x509… Could it be a system time issue?) <attila_lendvai>nckx, i had two xterms open. then i did a `sudo -E guix system reconfigure`, which installed a new version of gedit. but in those two terminals `gedit --version` was still invoking the old gedit binary. <nckx>I don't understand why, though. PATH isn't versioned. Unless you added gedit to a profile that previously lacked it. *nckx tries building PHP with the test disabled. <nckx>libgl is a generic name for ‘the system GL driver’ but I think the only one Guix provides is Mesa's. <nckx>Not having ‘vendor drivers’ or any of that crap. <unmatched-paren>right, wayfire's readme says it depends on libgl, but that makes sense :) <unmatched-paren>has cargo-inputs been updated to the new style btw? i'm just changing my channel to use the new style, but it has a couple of crates <nckx>Uh, good question, I don't know. Old style should still work everywhere though. There's a generous grace period. Many packages in Guix still need manual conversion. <unmatched-paren>is cargo-inputs even necessary anymore? i think i remember some branch to unify it with inputs, but i'm not sure if it's been merged yet <unmatched-paren>i demo all packages i want to contribute in my channel, so that i can use them while the patch is unmerged, and i just noticed that it still uses old inputs <vldn[m]>mhh i added a specification to my cuirass server via the webinterface but it doesn't start the job automatically after addaing.. <vldn[m]>do i have to do more then just add the specificaton to start it? <kwjc>*raging at cd-drive for not opening* *nckx , an old: do they still accept paperclips? <unmatched-paren>can i do --no-substitutes but for only one package? trying to do guix build [...] --no-substitutes tries to build the entire distro (coreutils, gash, bash, binutils, gcc, etc.) <nckx>You can download the development inputs with substitutes (guix environment foo -- true, or now guix shell -D foo --true, I guess), then guix build foo without substitutes. <roptat>that might not work properly with graft <roptat>I think you'll need the same with --no-grafts too <nckx>Possible. It's always worked for me. <nckx>I tend to use --no-grafts a lot in my daily work. <nckx>…that sounded worse than I meant. <nckx>I like to have the ungrafted versions in my store, is what I meant. <unmatched-paren>nvm, i was trying to figure out if you still needed to use #:cargo-development-inputs <PotentialUser-30>It would be nice if there was a REPL workflow documentation / blog post about how to define a package, because sure, the new syntax introduced by https://guix.gnu.org/en/blog/2021/the-big-change/ is nicer, but I tried on and off to define a package in guix, and it's hard. Way harder than building directly from bash. Because with bash, when a step <PotentialUser-30>of your build fails, you get a feedback about the error, then you can try fixing until it works, and once this step resolved, you can go to the next step of the build and repeat this debug process until achieving to build the package. Sadly I don't know how to do this noob friendly workflow in guix. When I try and fail to define or tweak a package <PotentialUser-30>definition in Guix, I have no idea what I should fix or why it failed (except for missing libraries, where they give us a hint). Either I get everything right from the first try or I can't manage to build the package. <nckx>I have a very different (even ‘ideal’) workflow from yours so I can't really say more. <podiki[m]>I also haven't tried to figure out a REPL workflow, but that would be nice to have <ss2>Nice post about the big change. I like these moments when a big git commit happens. <podiki[m]>I tend to just copy lots of pieces from other packages to get the basic idea, and then lots of guix build -K -f thefile.scm to see messages or the build environment to debug <PotentialUser-30>know how to replicate my bash build with guix & scheme functions. (I was really at lost with all this “declarative config” that uses so many replace without never telling how to know what it did) <nckx>Glad I could help a bit :) <nckx>Maybe we should promote the cookbook more/better. <podiki[m]>PotentialUser-30: and do look at the source of packages, that's how I learned stuff beyond the basics, just find one that has what you want to copy :) <opalvaults>hello! is there a way to get the file /etc/ssl/ca-bundle.crt? certain programs such as isync need it <nckx>I don't have that file and isync (mbsync) works perfectly. <opalvaults>home/opal/Dotfiles/.config/mbsync/mbsyncrc:7: CertificateFile '/etc/ssl/certs/ca-bundle.crt': No such file or directory <nckx>This is on Guix System by the way. <nckx>That is what I have too, opalvaults. <nckx>lfam: It's mentioned above. <lfam>However, grunewald is working, which is great <nckx>I just forgot the conclusion. <opalvaults>but obviously mbsync needs the ca-bundle.crt. Is there a good way to get it? <unmatched-paren>how do i copy files from a checked out repo/untarred archive into $out/blah? <unmatched-paren>oh, i'm stupid, i could just look at the definition of copy-build-system :P <lfam>You could replace the phases of gnu-build-system, or use trivial-build-system <lfam>Not sure why you'd avoid copy-build-system though <lfam>It will help us give advice if you explain your situatoin <nckx>opalvaults: I don't think that assertion is true or obvious at all. <jpoiret>apteryx, civodul: to further complicate matters about the dbus/elogind issue, i don't think the Credentials error is actually related to what we're experiencing: the strace output from elogind shows that it successfully authenticated on with the dbus server, and the credential byte is read at the beginning of the authentication <unmatched-paren>because the package is built with meson, but it needs a file copied somewhere <opalvaults>nckx I mean that according to the error message. Sorry that was a miscommunication. <nckx>I also don't override it in my .mbsyncrc (thanks for the reminder to move it to .config :) <PotentialUser-30>podiki[m] If you use emacs and geiser, how does you connect to `guix --repl`, because my geiser only connects to by foregin distro's guile (And in the past I tried to use the guile from guix, but I think to remember that it didn't have the guix modules) ? <unmatched-paren>i know how to insert phases, but i don't know how to copy it, that's all -.o.- <nckx>Maybe a certain code path hard-depends on that file, I'm just having trouble believing that (not: ‘you’). <lfam>unmatched-paren: Grep in the packages for 'copy-recursively' or 'copy-file' <opalvaults>nckx so you mean the mbsyncrc being in my .config would potentially make mbsync want to look for /etc/ssl/certs/ca-bundle.crt? <nckx>Just that you probably use different options (and maybe protocols) than I do. But I do use TLS. <podiki[m]>PotentialUser-30: I do use emacs but haven't played with geiser yet (on my list!). Might try also searching the IRC logs or the help/devel lists (or asking there) <opalvaults>hmm, let me read mbsync and see if there's a switch for that nckx. I was using mbsync -a -c ~/Dotfiles/.config/mbsync/mbsyncrc (I use GNU stow to symlink). <opalvaults>btw nckx do you have a bitcoin wallet? you've helped me like 5 times this month <nckx>The isync sources don't mention ca-bundle at all (I didn't really expect them to, this is ‘obviously’ a library taking care of TLS, very likely openssl). <nckx>opalvaults: Ha, no, maybe I should 😃 <nckx>Thank you for the kind words. They're not quite cold hard bitcoin but they warm the heart. <opalvaults>nckx happy to buy you a beverage if you ever do get one. pm me anytime. and to your point about openssl, that is actually the only thing different about this install that I've done. I explicitely installed openssl <nckx>I'm afraid I must go AFK, but I'll catch up on any more findings later. I'll do some poking around of my own if I have time, because I want to learn more about how SSL cert bundles ‘work’ (often: don't) anyway. <opalvaults>Does anyone know if simply symlinking ca-certificate.crt to ca-bundle would work? <podiki[m]>opalvaults: I don't know, but I do use mbsync on Guix system without change from my Arch system <podiki[m]>CertificateFile /etc/ssl/certs/ca-certificates.crt <podiki[m]>is in my mbsync file, I believe a default; and same on both Arch and Guix setups <lfam>I also have CertificateFile /etc/ssl/certs/ca-certificates.crt <lfam>I'm using mbsync from Guix on Debian <opalvaults>ah! podiki[m]! That's it you've cracked the case :D <opalvaults>I set it to be ca-bundle in the mbsyncrc file because it was how system crafters had it <podiki[m]>you can follow symlinks to see that file comes from ca-certificate-bundle, but I'm guessing that comes from some default somewhere (or nss-certs being installed in a system?) <opalvaults>podiki[m] gotcha, that's good to know. I'm not sure if it was pulled in as a dep on another system. This is my first time with a successful guixSD install so I'm getting used to where things are and how guix-package works in regards to dependencies <podiki[m]>the certs are a bit mysterious to me, but all I have (if I remember) is nss-certs in the system config, which I've seen everywhere <podiki[m]>likely looking at %base-services or %desktop-services can give you an idea of what is pulled in too, in common setups <lfam>If you want to use TLS or any derivation protocols like IMAPS or HTTPS, then you should have nss-certs available at the system level <opalvaults>Yeah that's what I have too. Strange. I wonder if explicitly installing openssh maybe did it? <lfam>I mean, derivative protocols <opalvaults>which is also weird my base install didn't have ssh despite it being in the config.scm as a pulled in module <lfam>SSH is totally unrelated to this discussion <opalvaults>like i said I'm still learning how guix package words <podiki[m]>lfam: do you know what pulls in the other ones, like ca-certificate-bundle? (or is that via nss-certs) <lfam>Sure, just want to clarify, SSH and SSL / TLS are unrelated. OpenSSH and OpenSSL are also unrelated and are not even developed by the same team <lfam>They don't use the same technology <podiki[m]>opalvaults: in general, packages only make available to a user themselves (e.g. on PATH), while dependencies are there for them to run with; some do "propagate" inputs, essentially the same as you having also installed them to your profile <lfam>If you want the certificate bundle, then you should make nss-certs available at the system level. That is, by adding it to the 'packages' field of config.scm and reconfiguring <opalvaults>lfam I have nss-certs in my config.scm and I don't have that file? <opalvaults>well..I have specification->package "nss-certs" at least <lfam>Did you reconfigure your system since adding nss-certs to config.scm? <lfam>My Guix System has '/etc/ssl/certs/ca-certificates.crt', and it's ultimately provided by nss-certs *nckx returns earlier than expected. <opalvaults>oh! I think we're misunderstanding each other. sorry! I think the problem ultimately lied in that mbsyncrc was pointing at /etc/ssl/cert/ca-bundle.crt <nckx>opalvaults: Explicitly installing openssl is fine, I do so too. <lfam>ca-bundle.crt isn't going to exist on Guix System, opalvaults <lfam>We use ca-certificates.crt <nckx>Hah! ‘Why'd I get weird errors about missing ca-bundle.crt?’ ‘Oh also I explicitly ask for ca-bundle.crt in my .msyncrc’ —you must forgive me a giggle 🤭 All's well that ends well! <opalvaults>right, it was part of a tutorial I followed. hence my saying before that I deserve the mishap for blindly copy and pasting someone elses mbsynrc <lfam>There is no convention about these things across different operating systems <opalvaults>so that always worked, but that's good to know there's no standard. <lfam>There is not even a convention between different programs that provide TLS <lfam>Not even a convention for the format of the certificates <nckx>Well, there is a standard, use the environment variables. <lfam>Even that is not standard across TLS libraries. Which is why one has to set multiple variables :) <nckx>More work, more flexible, trade-off. <podiki[m]>I see '/etc/ssl/certs/ca-certificates.crt' coming from ca-certificate-bundle, btw <lfam>Yeah podiki[m]. I think it happens "under the hood" <opalvaults>podiki[m], i have that installed and I do have a ca-certificate.crt file! sorry if I didn't mention that before <florhizome[m]>* is running xfce with gala as a wm and fealing pretty savage (: <lfam>The bundle is like a meta-package created in guix/profiles.scm <nckx>lfam: Obviously you can specify the correct environment variable names in an environment variable. <nckx>export SSL_VARIABLE=SSL_FOO <lfam>Fixing the tower of babel <lfam>""Return a derivation that builds a single-file bundle containing the CA <lfam>certificates in the /etc/ssl/certs sub-directories of the packages in <lfam>MANIFEST. Single-file bundles are required by programs such as Git and Lynx."" <nckx>Release notes: starting with OpenSSL 4.0, SSL_CERT_VARIABLE can contain JavaScript that evaluates to the name of the desired variable. <jpoiret>mroh: yes, I just sent a followup email <lfam>You know it would be `eval` in the shell <mbakke>diffoscope gives 'magic.MagicException: b"Bad magic format `version %#x (MVP)' (bad format char: #)"' on ...-ublock-origin-1.39.2.crx{,-check} <lfam>How could the magic be bad <lfam>Like, it either recognizes the magic number or not <nckx>Could it be an error in the DB? <kwjc>the magic number *chuckle* <lfam>Or maybe it just doesn't handle unrecognized magic numbers? <nckx>Or if (magic_matches(crx)) do_more_stuff_without_actually_validating_the_crx_is_valid(); <lfam>unmatched-paren: It depends entirely on whether or not the dependent program keeps a reference to wayland-protocols <lfam>`guix gc --references $(guix build foo) | grep wayland-protocols` <lfam>In other words, is wayland-protocols a run-time dependency? Or only a build-time dependency? <nckx>Or maybe the crx happens to match magic for a totally unrelated file type. <lfam>unmatched-paren: Just run that command and you'll have your answer <lfam>There *are* cases where a program keeps a reference, but doesn't actually use the dependency. But we still should use 'inputs' in that case <lfam>References are literally just strings that point to a store item <lfam>After building, Guix scans the store output for these strings and records them in the Guix database <lfam>This is how run-time dependencies are handled <lfam>When in doubt, use 'inputs' <mbakke>unmatched-paren: wayland-protocols is typically only needed at build time, so you can use native-inputs <lfam>mbakke: Do you think we should add it to the "should be native" linter? <mbakke>nckx: I would guess the crx is eerily similar to zip ... will dig a little <unmatched-paren>i'd assume wayland-protocols is like the opengl xml spec, in that it's used to generate code from the wayland specifications? *lfam feels like they added another one to the linter recently, but doesn't see it in the Git history <podiki[m]>I have to try the linter, but on the native-inputs does it know about testing frameworks (that seems to often be native-inputs right?)? <nckx>‘…or if the surrounding software (wlroots etc.) have moved on making it hard to build with the versions in Guix…’ I hate being psychic. <lfam>Hm, wayland-protocols is an 'input' in a lot of packages. I think I'll wait to add it to the linter <lfam>I don't really know anything about wayland so I don't feel qualified to make a judgement <rekado>lfam: the aarch64 machines here on my desk are running an older system configuration which doesn’t keep the wireguard connection alive. <rekado>I want to use a more recent version, but “guix deploy” appears to have a bug, which pushes x86_64 binaries to these machines. <jpoiret>but, didn't we make it clear that native-inputs =/= build-time inputs? <rekado>grunewald was reconfigured but not rebooted, so I think that’s why it’s still visible. <jpoiret>wayland-protocols should be an input rather than a native-input, since it's a library used for building a program <nckx>lfam: Do they keep references, at least? <rekado>speaking of the cookbook: I guess we need to update the tutorial to the new style. <nckx>jpoiret: Could you elaborate a bit? As written it's a just-so story that I don't follow. <lfam>The 'package Reference' manual section says "native-inputs is typically used to list tools needed at build time, but not at run time, such as Autoconf, Automake, pkg-config, Gettext, or Bison." <jpoiret>well, the difference is: do we need a host version or a target version, to me the answer is clearly that we need a target version (in theory) but there won't even be a difference between a host and source version <unmatched-paren>ok so wf-config builds correctly, can't say the same about wayfire itself <nckx>Oh, the protocol is/can be arch-specific? <jpoiret>native-inputs is just for "things that have to be compatible with host, not target" <lfam>In practice, this is where the cross-compiling distinction comes into play <jpoiret>nckx: it's not I think, I was just checking for that reason <lfam>Built-time only vs build and run-time <jpoiret>it's really just a bunch of xml files, no templating involved! <podiki[m]>right, so testing frameworks should "always" be in native-inputs since that is typically run by the host only <jpoiret>yes, although I think cross-building disables tests but I'm not sure <nckx>Did they move again or ‘forget’ to add the release there? <jpoiret>I mean, you won't be able to even execute the target binary so how would you test it <jpoiret>unless you rewrite upstream tests to support qemu_binfmt properly I'd say <podiki[m]>I don't know enough about how various test suites work...some would check generated docs for instance <podiki[m]>(haskell ones do that, but not sure what they operate on exactly) <opalvaults>"Unless you’re using Guix System, the guix install command must have printed this hint:" GUIX_PROFILE="$HOME/.guix-profile" <opalvaults> . "$GUIX_PROFILE/etc/profile". -- It appears as though this message still pops up in guix system. Do I need to set this anyways or is this a message I can silence? <opalvaults>Or does the documentation just need a patch on that part? <podiki[m]>jpoiret: but either way, no point in including test frameworks as regular inputs if it is only to be executed at build; target won't need them <unmatched-paren>Dependency wlroots found: NO found 0.14.1 but need: '>=0.15.0' ; matched: '<0.16.0' <nckx>Well, ‘0.15’ doesn't exist. <podiki[m]>opalvaults: I see that on guix system too, my guess is that some search-paths were added, so it wasn't sourced in the current shell <jpoiret>maybe it needs an unreleased version (: <nckx>That was the rather explicit implication. <podiki[m]>opalvaults: e.g. you install a package that wants to provide a new env variable in the profile <opalvaults>podiki[m], okay. I'll explicitly add it to my shell env variables to hopefully silence it :) <nckx>unmatched-paren: Try packaging the wayfire commit directly preceding the commit bumping the wlroots requirement to 0.15. <podiki[m]>opalvaults: what I mean is that you are sourcing anyway, but only on login (.profile) so right now your shell won't know the new variables <nckx>Or a few commits earlier, if said commit is an ‘oops, we seem to be using 0.15 features now’-style fixup. <podiki[m]>opalvaults: what I do is just do that sourcing after install in case I need it in taht shell, but otherwise I know it'll be there on next login <opalvaults>podiki[m], that makes sense. thank you for the heads up :) <nckx>unmatched-paren: I'm speaking from the context of what you'd do in upstream Guix. If this is just for your personal channel, do whatever you prefer. <podiki[m]>opalvaults: it is a bit confusing, especially since I use both guix system and on foreign distro; just keep an eye out if you were expecting an env variable that it won't magically be available anywhere right away <unmatched-paren>i'm doing it for guix, but i put my patches in my channel too because it generally takes a bit of time to merge stuff into guix <nckx>It does. Sorry about that. *podiki[m] takes a lunch, hopeful booster break, etc. see you guixers later! <florhizome[m]>I have a package to that uses wlroots git ;) we can do a channel together^^ <unmatched-paren>no it's fine, it's a rather large project, so you're bound to miss a few <unmatched-paren>judging from the commit history they seem to keep needing to change stuff when wlroots updates :) <florhizome[m]>yes but they decided they will stop that now.... for my package ;P <nckx>You can do a channel together, just not the way you thought. <bdju>okay, so my ssh problem from last night is just logging in in general. happens in a second TTY as well. I see some relevant stuff on the mailing list I haven't read all of yet <mbakke>unmatched-paren: for testing, you may be able to use 'guix build foo --with-branch=wlroots=master' <florhizome[m]>The thing with wayfire is, 0.72 is really a long time ago and since then some things have come along pretty well, especially you won’t get the swayfire plug-in. <unmatched-paren>would you be willing to send me the recipe on paste.debian.net or something? <florhizome[m]>So if I commit 0.72 I will still build from my machine anyways. <bdju>I restarted the tty services and that fixed logging in on other ttys. I restarted ssh and then was able to ssh in, but I see some odd errors after sshing in. `error: XDG_RUNTIME_DIR not set in the environment.` and `Failed to connect to a Wayland server`. I just use base-services and don't have gdm/sddm. <unmatched-paren>i've already published my channel, so i guess it would be easier to add it there (with appropriate permission and credit ofc) <nckx>So is Swayfire like Sway with more eye-candy? <apteryx>a seemingly rare, but really annoying bug <bdju> apteryx: in my case ssh wasn't working either, it logged me out immediately. I had to restart the service for it. (last night I mistakenly restarted networking instead of ssh and was worried when it didn't work) <florhizome[m]>it's a better tiling plugin for wayfire ;) not necessarily exactly like sway. <unmatched-paren>wayfire's entire appeal is basically eye candy + extensibility; it was apparently originally concieved as a compiz clone for xorg <nckx>Hah, ‘compiz clone for [Wayland]’ was my first thought. <unmatched-paren>gnome is really pretty too, but it's quite slow, so i'm going to try wayfire with plugins and see if it's good enough to replace gnome <unmatched-paren>then the developer got frustrated with the xorg api and switched to making a wl compositor instead <nckx><i like eye candy> Same, I'd switch to Sway+cuuubes in an instant if it didn't lack anything vital. <nckx>I guess I know which channel to add soon. <jpoiret>whenever someone references wayfire I look at the website and demos and think "oh, it looks great, time to switch" and forget about it all over again. I've done that at least 3 times now <jpoiret>it even seems to have touchscreen gestures, which would be very useful on my 2-in-1 *nckx has a touchscreen too. <singpolyma>raghavgururajan: there is also jabber.el for lispy <florhizome[m]>there is a DE that bridges gnome to it, too and a light qt one. haven't built thosse, though. *raghavgururajan is enjoying CLI irc client for first time <jpoiret>florhizome[m]: heads up, try to use git-fetch rather than autogenerated github release tarballs, as they can change over time, along with their hash <nckx>florhizome[m]: Thank you! Important: what's the licence of all three? <nckx>unmatched-paren: Thanks. Where did you find that? <unmatched-paren>i'll upload wayfire to codeberg as soon as i make a few changes (change inputs to new style, modify formatting, etc <jpoiret>so, is it missing the 0.15 wlroots update for it to be packaged into guix proper? <nckx>I meant of florhizome[m]'s code, not the packaged software. <nckx>we should discuss this stagnation! <nckx>(I think it used to be one, some placeholder, so at least they fixed that.) <nckx>florhizome[m]: Sorry to be a nag, but unless you licence your pastes somehow, they are technically non-free and non-redistributable. And legally, ‘technically’ means ‘practically’ ☹ <nckx>You could sue me for all my bitcoin. <nckx>But in this case, since I'll be using them verbatim, I care ☺ *nckx has 0 bitcoin, it was a backref witz. <unmatched-paren>florhizome[m]: the problem with carbonos is that it uses flatpak and only flatpak for application installation <jpoiret>florhizome[m]: but flatpak is the solution of the future, so that's great news! <jpoiret>what do you mean it's just containers but different? <unmatched-paren>flatpak annoys me mostly because the second thing in the list of packages in flathub is spotifiy <jpoiret>given the current state of pipewire/wireplumber and xdg-desktop-portal, I don't think it would be production-ready yet <jpoiret>they're still figuring out how to do permissions properly (which is hard, for sure!) <unmatched-paren>at least it isn't as bad as snap ;) i remember from my dark ubuntu days that ubuntu-software actively promoted a ton of non-free stuff *nckx not sure what they did to deserve that… 🐷 <unmatched-paren>pretty sure there were more non-free thngs in the recommended panel than free things <mbakke>nckx: diffoscope/python-magic does not crash with file 5.41, but I had to patch both packages to work with it :/ <florhizome[m]>it's just fedora silverblue without rpm in the end. but i find intresting he came from nix and went for ostree as system basis. since ostree is way more pluggable for distros it could become a quasi standard for easy system maintenance. so my question is if guix could be compatible with it in the system part. <mbakke>well, diffoscope mainly because it runs tests that are sensitive to the file version, and thus needed to get 'file-next' as an input to select the correct tests for the patched python-magic (which needed an actual patch) <unmatched-paren>didn't they replace the package manager with a transactional (but still binary) one? <nckx>unmatched-paren: I'm miss what other primary purpose Flatpak has beyond making it easy to redistribute proprietary binaries. <nckx>That seems like its #1 (mis)feature. <unmatched-paren>i installed fedora on someone else's computer for them, and i noticed that the package manager mentioned transactions <nckx>drakonis: You haven't tried Flatpak, have you 😃 <nckx>florhizome[m]: Several; and no. <drakonis>i thought you were talking about rpm-ostree <nckx>I used to have chickens. <jpoiret>nckx: there's isolation as well, using namespaces I believe <unmatched-paren>i used to use flatpak, not for any technical benefits, but because some things simply weren't available with apt -.o.- <jpoiret>so to open external files, the flatpak app has to ask for permissions to xdg-desktop-portal, which should open a prompt via the proper implementation for the DE <florhizome[m]>flatpak uses ostree inside somehow so it could be possible it can do transactional upgrades whatever that is exactly <unmatched-paren>but now that i'm running guix instead of ubuntu/debian i can just add new packages whenever i want :D <unmatched-paren>so, nckx, to declare their paste as having a license, what would florhizome[m] need to do? reupload it with a copyright notice? <florhizome[m]>flatpak is attractive bc it's crossdistro compatible, bubblewrapped and it's pushed heavily. <florhizome[m]>we could put a red hat on the guix logo, maybe that ould help <unmatched-paren>it probably wouldn't be too hard to make a simple gnome-software plugin for it, just that nobody here really seems to care about gui frontends <nckx>unmatched-paren: Either. Adding it to a new paste would be vastly better of course. <unmatched-paren>but i've never made a gnome-software plugin, so it could be unnecessarily hard for no reason, idk <nckx>I just don't like relying on code that I can't legally distribute. <florhizome[m]>i herefore publish my previously pasted code under the "i don't care what you do with it nor what an umweltsau says" license. <unmatched-paren>gnome-software plugins sound like one of those things that shouldn't be hard but is <nckx>florhizome[m]: Could you stop. It's not funny, if it ever was. *unmatched-paren hides behind... something ***lprndn- is now known as lprndn
<nckx>I just don't know you well enough to know if it's ironic (which I dig) or not. <nckx>unmatched-paren: That is not my intention. <nckx>Ich bin ja super Deutsch. <nckx>florhizome[m]: I guess ☺ As long as it's a witz we cool. *nckx goes to train the chickens to ride the motorbikes. <unmatched-paren>nckx: no worries, i guess i'm just kinda used to the internet being a place where fights break out at random for no reason <florhizome[m]>i think i misgermanned nckx and i'm eternally sorry. a thing noone should be acclaimed of falsely. <florhizome[m]>unmatched_paren: wlroots is getting a vulkan backend but it's not really needed for wayfire. <unmatched-paren>florhizome has committed the ultimate crime: laying out lisp parens like this: ((stuff) \n more stuff \n) instead of ((stuff) \n more stuff)) :P <nckx>That's OK. The first ban for that is only a week. <florhizome[m]>next time i will publish my paste with the "do what you want but don't be a smartass" license ;P <nckx>How am I supposed to use your code then ☹ <jpoiret>that would be non-free (to criticize) <jpoiret>is that right guaranteed by the FSF? <nckx>florhizome[m]: <i think i> That was truly your greatest crime. Apology accepted, but you have to publicly admit that Belgian beer is better as punishment. <nckx>florhizome[m]: Not my style. <nckx>CC-BY-SA-NO-DUMBASSES-4.0 <raghavgururajan>florhizome[m]: If you want your code to be freest, choose GPLv3 and close the deal. <singpolyma>unmatched-paren: to be fair, the bad way the list community uses whitespace is sometimes worse than the parens <unmatched-paren>it doesn't really matter anyway, since they're basically sharing it so i can put it in my channel, which is licensed under gpl-3.0-or-later <florhizome[m]>i'm actually from a whine region but i like bavarian helles over most. <singpolyma>raghavgururajan: plagiarism is a useless concept from academia. You probably meant "copyright infringement" <singpolyma>In this case I expect they have an implicit license but IANAL <nckx>Well, if the code was explicitly shared in response to a ‘could you share your code so I can put it in my channel?’ that would be enough, but it's not much to rely on and you've have to prove the convo happened and oh god just licence your non-trivial code properly everyone. <unmatched-paren>it's amazing how difficult copyright makes sharing a little snippet so difficult <nckx>It's definitely copyrightable I'd say. <florhizome[m]>nckx are you brussels or are you tossing out sanctions that nobody cares about? <unmatched-paren>florhizome[m]: can you please reupload the code with a license header? then we can be done with this :P <nckx>florhizome[m]: Can't I be both? <nckx>If I'd known it would lead to all this I wouldn't have asked. <raghavgururajan>florhizome[m]: Please stop wasting valuable time of others. Do the simple thing and get it over with. <unmatched-paren>to be fair, it's not they who are wasting my time, it's me who is wasting their time <nckx>Let's all remain calm and have a fine Belgian beer for those who partake. <nckx>This message totally not brought to you by the bitcoin-backed Belgian beer lobby. <florhizome[m]>i actually really have never/barely seen s.o. paste stuff with a license here? *raghavgururajan just hope nobody sues Guix Corp. for copyright infringement <unmatched-paren>i meant 'their' as referring to florhizome in my 'to be fair' message, to be clear, not referring to me as in "they're wasting their time" <nckx>That's certainly true, florhizome[m], but it doesn't negate the more general point, which seems to have got a bit out of hand. <nckx>Any unlicenced non-trivial snippet is proprietary code, we didn't invent that horrible status quo. <unmatched-paren>"Any unlicensed code..." <- why the actual unlicense license needs a better name <nckx>Don't let's get started on that 😃 <singpolyma>If we wanna be picky now we have to ask where you work and if maybe your employer actually owns your snippets... 🤦♂️ <jackhill>I also came across some channel the other day that lifted some code out of guix, and then removed the copyright headers. I thought it was unfortunate for a while, but decided I had better things to do than complain. Hopefully for the best, and we can all strive to do better in the future :) <florhizome[m]>*has thought about contacting wayfire maintainer to switch to the apache license <nckx>Imagine a lawyer barging into a hackathon, writing a clearly broken piece of code on the whiteboard, scoffing ‘there, you nerds, I've solved the halting problem’, and leaving before anyone knows what to say. <nckx>This is what programmers like to do with licences for some reason. <nckx>So do I, but I haven't found out what I do well yet. *nckx performs an action. <attila_lendvai>nckx, i realized what was the cause of my gedit issue: cached profile by .envrc <nckx>I'm not familiar with whatever .envrc rc's. <nckx>But very glad you found it! I wouldn't have. <attila_lendvai>nckx, basically it's just a tool to automatically execute a `guix shell ...` whenever you change into a directory <nckx>Is it dotenv by any chance? <unmatched-paren>anyway... florhizome, i'll upload a gpl3 header with lisp-style ;; comments to paste.debian.net, and you can paste that into the top of your wayfire file, k? <nckx>Oh, that's not it, I thought we had a package of that name. <florhizome[m]>unmatched_paren you ping me when wayfire is up ? :) i will post it to their channel <nckx>Yay, community co-op (distinct from coop)! Thanks. <florhizome[m]>also: multiple tiling or decoration plugins often don't work together and maybe you get a crash after flipping swayfire on bc it's essentially alpha code or what not. <nckx>The world is not yet ready for the truth. <unmatched-paren>i wouldn't contribute to guix if i had to give my real name in the header <unmatched-paren>i guess you don't need to put in your email for my channel, not sure what guix's policy is tho <nckx>We do expect a working e-mail address. <unmatched-paren>it's best to make your username a nickname for everything, just in case <unmatched-paren>i'm really glad that my system username is 'paren' now, so i don't have to scrub my name from any logs i share :) <unmatched-paren>before guix, it was my real name, so i had to sanitize every log i posted for support *nckx went the opposite path or radical self-doxxing. <singpolyma>nckx: radical self doxxing is awesome. Highly approve. I don't think it's in fashion at all anymore... <nckx>Yes. Post-cards welcome. <nckx>Well, there are certain things I wouldn't do under my .well-known nick name, of course, and I don't disapprove at all of pseudonyms, but I personally don't see the point in cases like these. <nckx><don't disapprove at all of pseudonyms> I don't think they're legally valid in copyright headers, but that ship has sailed and sunk by this point. <nckx>It doesn't impede redistribution but it would make GPL enforcement hard. <nckx>But what do I know, IANAL. <unmatched-paren>a project that does not allow pseudonyms in their copyright attribution would not get many contributors <singpolyma>Copyright headers are dead outside if GNU anyway. Most projects have no names *directly* attached to the licensing at all and rely on eg commit attribution. Probably need expert testimony about industry practise to make anything stick, but in practise no one sues so it's all pretty meh *nckx looks at Linux, seems to be doing ‘O.K.’. <nckx>(They don't accept pseudonymous contributions. Which is different from not having any, because there's no paperwork such as with, e.g., the FSF.) <singpolyma>If the conservancy 3PB case gets legs we won't even need to own the copyright to enforce anymore <jgart>singpolyma, Are you interested in using purescript and purescript libraries with guix? <nckx>It's in the ‘industry’s interest to make GPL enforcement hard and to have experts testify that it's too hard & never happens. <nckx>singpolyma: Yes, following that one. <unmatched-paren>how many average free software programmers, of the kind that often does not wish to give away their real name (i.e. people not associated with linux or any of the companies that support it like ibm, google, etc) actually contribute to linux tho? i'm guessing not that many, i'd suppose it's quite a complex codebase for your average person to just contribute to casually <unmatched-paren>obviously i have no idea, but 'not many' would be my first instinct guess <singpolyma>jgart: probably. I have exactly one purescript project right now <nckx>Corporate contributions dwarf individual ones, but I have a hard time blaming a real-name policy for even a fraction of that. <nckx>It's a valid question but I don't think the answer can be determined either way. <jgart>Cool, I have exactly 0 but I'm trying to pick it up <jgart>singpolyma, Do you have you purescript project online? *nckx spins up a completely independent control kernel, waits for contributors to make it, er, boot and stuff. <nckx>I'd joke it's the Hurd but they probably also require paperwork. <nckx>I don't actually know if FSF copyright assignment applies there. <nckx>I'd just be mildly surprised if it didn't. <jgart>singpolyma, thanks! I'll take a look, much appreciated <unmatched-paren>hyperbola might be hostile to a guix port because they believe rust is nonfree, and rust is in guix <jackhill>jgart: I'm slightly interested. I think it would be super need to have guix on additional kernels than linux-libre and hurd, but relize the cost/benefit analysis might be off. I have not particular thoughts about hyperbola, but think it could be interesting to add an additional kernel that is more mature than hurd. <nckx>unmatched-paren: That is indeed one of their opinions. <jgart>singpolyma, How did you get slim templates working with purescript? <nckx>I agree a port would be unlikely to be well-supported upstream. <nckx>Most of th—no, I'll sit this one out. <jackhill>jgart: you could probably convince me that illumos would be an interesting target as well <unmatched-paren>(neither of those are a thing yet, which just makes the challenge all the more interesting >:)) <singpolyma>jgart: I build the slim using slimrb right now, they just import the js generated by purescript <patched[m]><unmatched-paren> "hyperbola might be hostile to..." <- Hmm, I thought rust had the same freedom issues as mozilla software, and that was why forks were used in guix <nckx>Neither Rust nor Firefox have freedom issues. Firefox doesn't follow the FSDG by directly suggestion non-free (or non-vetted) add-ons, so we use an FSDG fork. <unmatched-paren>a rust fork would be a much more difficult endevour than a firefox/thunderbird fork is <nckx>There's a weird reasoning going around that trademarks somehow make software non-free but it's bul—bogus. <singpolyma>unmatched-paren: depends what the point of the fork was. A small-changes rust fork might actually be easier <unmatched-paren>so hyperbola's rules are stricter than the fsdg, i thought they just had a vastly different interpretation <patched[m]>Doesn't the mozilla license disallow forks from using the same name? Which could be problematic esp. for proglangs <nckx>unmatched-paren: Possibly and likely both. <singpolyma>But they allow small forks like what Debian ships <jgart>Is rust currently useable for development with guix? <nckx>I think their distinct interpretation of free feeds back into how they read the FSDG, since the FSDG is a very broad, yet short, high-level ‘spirit of the thing’ document. <singpolyma>jgart: you can package rust packages even, and there is an importer <nckx>If you claim Rust is non-free, then the FSDG tells you you can't redistribute Rust. It doesn't make your premise valid though. <jgart>I remember Maxim mentioning that it was too slow or something <jgart>jk, I've been warming up to rust actually <unmatched-paren>wayfire-git is nearly in my channel, i'm just doing some formatting clean-ups <singpolyma>jgart: rust is on my very short list of languages I will use when I have a choice <unmatched-paren>but guix has shown me how amazingly difficult it makes packaging sometimes <singpolyma>unmatched-paren: you mean the bootstrap issue specifically? <jgart>It seems like rust is in a league of its own for solving certain types of issues <unmatched-paren>it's really, really tedious to package a crate that isn't on crates.io <singpolyma>Big dependency trees are nice, that's why we have guix :) <singpolyma>unmatched-paren: well, that just means we need to improve the importer <f1refly>I'm sorry if this is annoying, but I have no idea where I could ask for help besides here: my clipboards don't work and it's very cumbersome. I tried setting both the primary selection and the clipboard with xclip manually, but nothing happens. I never encountered this behaviour before and no search engine returned anything useful yet. has anyone here any idea what can cause this? <f1refly>I also searched the guix doc for pointers but there is nothing special mentioned regarding clipboards <singpolyma>Most of the importers rely on an upstream package repo, but they don't need to <nckx>f1refly: Are you using Wayland? xclip stopped working for me when I switched, now I use wl-clipboard's wl-copy command. <singpolyma>unmatched-paren: right. The importer could just read the cargo metadata from git <nckx>It works at least between native Wayland clients. <f1refly>nckx: no, I'm using herbstluftwm which is an xorg-only wm currently <nckx>Then I haven't a clue, sorry. <jackhill>unmatched-paren, singpolyma: it's not just the importer. Guix can't track reference and inputs in the same way it does for other languages for reasons that I don't unserstand, but it makes some of Guix's neat tricks not work <jpoiret>f1refly: so you can't even ctrl-c + ctrl-v? <nckx>f1refly: This is definitely the right place though. As is filing a bug at bug-guix at gnu dot org if nobody here can help. <f1refly>selecting stuff + middle click does nothing as well <unmatched-paren>jackhill: fairly sure the need to separate cargo-inputs and inputs has been fixed with the c-u-f merge <singpolyma>jackhill: can't be worse than go where guix currently includes the source in the store for libs, or ruby where every damn gem is propagated <jpoiret>singpolyma: it's a language tooling shortcoming, upstream doesn't care about packagers and maintainers, only devs <f1refly>is the issue mailing list preferred or should i open a ticket at the issue tracker? <unmatched-paren>also you can now do (list foo bar) in inputs instead of '(("foo" foo) ("bar" bar)) in case you'd missed that too <jpoiret>seeing how android source code is supposed to be fetched/compiled, you can really see how google expect people to operate <singpolyma>(I want to fix gem propagation, I'm like over halfway there just need time to do it all) <jackhill>unmatched-paren: thanks for the reminder, I think I was aware of that one. I need to `guix style` all my WIP stuff <jpoiret>you need to send to bug-guix@gnu.org, which will create a debbugs issue, for which issues.guix.gnu.org is a frontend (mumi) <unmatched-paren>well, no, google intends android to be preinstalled on everyone's phones with all sorts of proprietary-ness preinstalled, that's how they expect people to operate <jackhill>singpolyma: is ruby worse than python and guile in that reguard? <unmatched-paren>'just use the system package manager' sounds great, but sadly most languages care about mac and windows ***KE0VVT80 is now known as Kolev
<Kolev>singpolyma Will JMP run on Guix some day? <jpoiret>nckx: wsl2 on wine on debian on wsl2 <nckx>Win Subsystem for Loss yes. <singpolyma>Kolev: we are migrating everything to guix-on-debian at the moment <singpolyma>So all our dependencies we hope to get into guix upstream at the very least <Kolev>nckx: I could not get (map (package->specification "emacs" "vim")) to work last night, <nckx>(map package->specification (list "emacs" "vim")) <Kolev>nckx: OK. I'll give config.scm and the resulting outpoot soon. <nckx>I might even be around. o/ <winning-luser>stallman forgive me for i have sinned, i have guix (and GUI X11 emacs) running on wsl2. this is quite disgusting but what is done is done <singpolyma>winning-luser: that's a very good step for world domination <singpolyma>I know this is a worse question, but how absolutely insane would it be to run guix on macos directly? <Kolev>I wish Guix would run on MacOS too. <jpoiret>unmatched-paren: just (list glib "bin") <jpoiret>so (inputs (list gnome (glib "bin") guile) for example <Kolev>unmatched-paren I finally figured out how to avoid unmatched parens in Leafpad and handwritten Lisp: Indent all the things. <jpoiret>ehm, no, that would not make it work because glib would be quoted <jpoiret>eg evaluating to a symbol rather than the value bound to the glib symbol <unmatched-paren>nix actively supports macs, so i guess if you want a transactional functional package manager there, use nix <Kolev>No Lisp. I knew Macs were evil. <Kolev>Apple once used Lisp, called Dylan. <nckx>Kolev: I just noticed that I copy/pasted a typo: specification->package, although you'd have got an error message. <f1refly>well, I just updated and I'll make sure I'm running the latest software after rebooting. if I still don't have a clipboard I'll submit a ticket. <nckx>Nix has some extremely gross low-level-bootstrap-graph-choppery-fuckery stuff going on to support the Macintosh. <nckx>Don't let us emulate such things. <nckx>(*IIRC*, you have to use the system libc, which of course is a binary blob.) <daviid>Kolev: MCL (Macintosh CL, which preceeds Dylan ... <daviid>and Dylan is/was not a lisp dialect anymore, iirc <Kolev>Dylan is no more, both the programming language and my ex. <apteryx>(a correct expression given the last messages) <nckx>Almost. (packages (append (map specification->package "icecat" "emacs" "vim") %base-packages)) <nckx>s->p looks up strings as package names & returns tho package object. %base-packages is already a list of package objects, not strings. <nckx>And you're still missing the list call I suggested earlier. <nckx>I wouldn't say you have to be able to ‘programme’ in Guile to use Guix, but following a very basic tutorial to get to know basic language concepts might be in order here. If you just randomly slap () around things you don't quite understand (a logical and common way to start), you could be slapping for a rather long time. *nckx slaps Kolev around with a large unmatched-paren. <unmatched-paren>i recommend you use a good linter or you will indeed have unmatched-paren problems <mbakke>I'm amazed by how fast the time-machine cache is. *nckx s/logical/understandable/ whilst no one's looking. <unmatched-paren>for some reason, the input passed to #:configure-flags needed to be quoted, even though the list that contains it was already quasiquoted <nckx>Can we please add the list now. <nckx>(packages (append (map specification->package (list "icecat" "emacs" "vim")) %base-packages)) ***taylan2 is now known as taylan
<nckx>Don't copy/paste things from me, le typomaster. <nckx>Debugging one person's code is enough, I don't want to deal with my crap. <Kolev>nckx: It works with list, but I think I messed up when I ^C'd reconfigure earlier. guix system: error: symlink: Permission denied: "/var/guix/profiles/system-3-link.new" <nckx>Are you running reconfigure as root? <nckx>With sudo is fine, for the record. <jpoiret>I wonder if adding a hint in that case would be easy to do <jpoiret>(although I'd say the message is pretty clear already) <nckx>I get where you're coming from but, really, ‘Permission denied’…? <Kolev>Great. I'm in trouble because I took out nss-certs. guix system: error: symlink: Permission denied: "/var/guix/profiles/system-3-link.new" <Kolev>I mean Git error: the SSL certificate is invalid <nckx>I don't see the connexion. <nckx>Is this produced by ‘guix system reconfigure’? And yeah, I guess, worth a try. *Kolev duckduckgoes 'roll back guix' <nckx>sudo guix system roll-back <nckx>It's basically the search term with sudo in front of it. <florhizome[m]>that should be committable actually though, on the other side it’s just a fork. <unmatched-paren>==2707==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD. <nckx>Let's not compile with libasan for a release package. <podiki[m]>has anyone used guix containers much? or know about udev? having issues accessing a device from a container <nckx>It seems like we're doing so, in $CXXFLAGS and/or $CPPFLAGS (see src/meson.build). Never mind then. <nckx>‘The average slowdown of the instrumented program is ~2x’ is why I suggested disabling it at first, but I don't know much about it. <nckx>I'm looking at wayfire, not wf-shell. <nckx>cxx_flags_asan = run_command('/bin/sh', '-c', 'echo $CXXFLAGS $CPPFLAGS | grep fsanitize') <nckx>‘Guix told me to, mummy.’ <nckx>Could you share your channel? <unmatched-paren>it's already on codeberg, but i haven't pushed wayfire yet, i'll push it once i fix wf-shell <Kolev>Installing everything globablly now, until I figure out Guix Home. <nckx>You don't need guix home to install user packages, but nor will it hurt to install most things as system packages for now. <nckx>Just note that, e.g., an IceCat rebuild can keep a kernel upgrade hostage since the system is built as a whole. <Kolev>With Guix Home, I get a nice list in a text file of all the packages. <florhizome[m]><unmatched-paren> "i'm having problems with wf-..." <- Which? <nckx>Kolev: You get those with manifests as well. <nckx>But if you'd rather go straight for guix home, that's cool. <nckx>But I don't see where that's added… <nckx>This sounds like wonderfully written high-quality soft wares so far. <unmatched-paren>just paste the default config from the repo into ~/.config/wayfire.ini <Kolev>Is gcc-toolchain the package that has GCC and other things needed to build stuff? <florhizome[m]>I once had that in wayfire itself but i thought i purged it. <florhizome[m]>It was in the very beginning and i was told it might improve debugoutput <nckx>That's what it's paid to do. <nckx>And why globally enabling it on an end-user build is generally a bad thing. Because they can't fix the problem but are stuck with a crash. <jacereda>how can I add some module to linux-libre in config.scm? <jacereda>I have a server with a crappy matrox card that isn't built by default and Xorg refuses to start... <nckx><It's a meson thingy> No wai. For real? 