<lfam>You might have to package this the old-school way... by hand ;) <lfam>It should not be difficult, because its only non-stdlib dependency is github.com/chzyer/logex <lfam>Hopefully that program is similarly minimal <lfam>In that case, I don't know <cybersyn>roptat: I spoke too soon unfortunately, mistaking terminals I had open; openjdk didn't install. I've tried earlier versions and else, but it keeps failing during profile generation. <lfam>It fails while generating the profile? Not while building openjdk? <lfam>I missed the earlier part of this story. Did you share the error messages? <cybersyn>guix/build/union.scm:144:11: union-build: collision between file and directories ((files ("/gnu/store/7iqki0wjj5l3j99432nb5rjfw78pchw6-openjdk-12.33/lib/modules")) (dirs ("/gnu/store/5i2yr3ds202jg6w4h7x2d5hi6ik3wflp-wireguard-linux-compat-1.0.20201221/lib/modules"))) <cybersyn>builder for `/gnu/store/z38wn33h3flpsq7q2p5y93cjhpqxbs65-profile.drv' failed with exit code 1 <cybersyn>(sorry, just remembered I should have debian/pasted that) <lfam>You'll have to use separate profiles for these two packages <cybersyn>this error is from 12.33, which i just tried, but its the same with 14 <lfam>"collision between file and directories" <lfam>It's saying that the openjdk package has a file named 'lib/modules', whereas the wireguard package has a directory with that name <lfam>When creating the symlink union of these packages, it can't combine these two things <cybersyn>yeah i noticed that, but it seemed lib/modules would be too common of a path to create conflict <lfam>It's atypical for it to be a file and not a directory <lfam>I would even say it's really weird :) <cybersyn>cool, i'll get on it. thanks for the help troubleshooting! <lfam>Don't hesitate to come back with more questions <lfam>I am building / downloading openjdk to look at this weird file <lfam>It's too weird to not gawk at :) <cybersyn>thanks, wish I had more questions there wasn't a ready solution for. I've been on guix as my primary system since november but unfortunately I haven't had too many issues that a search of irc and mail logs didnt solve :) <lfam>I'm very sorry to hear that đ€Ł <lfam>Usually I feel like the opposite thing is true, so I'm glad it's going okay for you <cybersyn>but i still haven't attempted any complex packages yet. which reminds me, is anyone here packaging Kubernetes / does it meet guix standards? <lfam>It should meet our standards (it's free software and not malware) <lfam>We have some Go support but it's in the process of being overhauled to fully / easily support Go modules <cybersyn>cool. if nobody has started on it, it could be a good project for me <lfam>I would search the mailing lists (guix-devel, help-guix, and guix-patches mainly). I'm sure it's been discussed <lfam>Complex Go software tends to have gigantic dependency graphs. So it may be that you'll want to wait for our tooling to improve, or help with that effort <pineapples>How do I tell sneek to send a message to somebody when they are back? <lfam>sneek: later tell pineapples: Like this <sneek>Welcome back pineapples, you have 1 message! <sneek>pineapples, lfam says: Like this <lfam>It also knows 'later ask', if you are a grammarian <cybersyn>lfam: I might join in! I just started Kernighan's book on it and if I decide I dig it, i'd be happy to join in on the efforts <lfam>I didn't know that Kernighan wrote a book on Go! <lfam>He's seen so much in his career <lfam>That's insane that he wrote K&R C and a book on Go <pineapples>sneek: later ask raghavgururajan: Any tips regarding updating the Telegram package recipe? I would like to do it :) <lfam>That's inspiring. Never stop learning! <vagrantc>lfam: marvell's u-boot/atf infrastructure is really ... tricky <vagrantc>that's actually part of what got me messing with u-boot in guix at all ... to support another marvell board ... i gave up eventually <vagrantc>lfam: there does appear to be support in mainline u-boot and atf, see u-boot doc/README.marvell ... but it may require some other non-free parts <vagrantc>lfam: if it is possible at all, it might be the opposite of what other atf platforms in guix use ... e.g. atf embeds u-boot rather than u-boot embeds atf <vagrantc>the marvel boards do a fun combinatorial explosion of permutations that you need an individual build for <cybersyn>just recieved Sussman & Hansons Software Design for Flexibility! <cybersyn>anyone here started digging in yet? thoughts? <lfam>sneek: later tell vagrantc: Thanks for the notes! <aecepoglu[m]>lI'm trying to figure out how to use `pre-inst-env` script. I have created a new environment using `guix environment` and `./pre-inst-env guile` works correctly. However `./pre-inst-env guix ...` fails because no such executable exists. <lfam>The make is necessary, the check is recommended <Aurora_v_kosmose>bzcat '/var/log/guix/drvs/qm/y8ywgkhf09piwjv28giwcllhnpb8dh-module-import-compiled.drv.bz2' | less <samplet>Huh. I get the same error. I just pushed two commits -- let me double check everything. <jackhill>fossdev: I don't know if I'll have the answers to them, but I'm here :) <samplet>So my last commit (that I pushed!) has broken âguix pullâ. :( <samplet>I presume I should revert it and discuss a fix, right? <lfam>Yeah, you can revert it and locally test with `guix pull --url=/path/to/git/repo --commit=$commit` and then push if it works <lfam>It fails for me too with "no code for module (json)", I think from 'guix/swh.scm' <samplet>Yeah. Itâs because #:autoload doesnât work and guix/self.scm does not include Guile-JSON when compiling core modules. <lfam>Do you know how to revert multiple commits (if necessary)? <samplet>I donât, but itâs not necessary. :) <lfam>Something like `git revert --no-commit 4f59ef3edb9ad72ea6f0b2856b4a3336a9654c90^..66b14dccdd0d83c875ce3a8d50ceab8b6f0a3ce2 && git add -u && git commit -v` <lfam>It's handy when you need it <samplet>For the record, I thought I had tested âguix pull --url=...â earlier, so I was over-confident. <lfam>Thanks anyways for taking care of it <jackhill>samplet: such is life. Thank you for working on this feature!! ***sneek_ is now known as sneek
<hassan>Hello everyone, I hope you're doing well. <hassan>I used the graphical installer to install guix i686 with i3 <hassan>but there seems to be a problem with PolicyKit <hassan>It says "error getting polkit authority" <hassan>when I checked, there was no PolicyKit server installed, I assume that's the source of the problem. <hassan>Although I had (services %desktop-services) in the config <rekado>hassan: IIRC window managers should be called through a policykit wrapper (I forgot the name of the executable) <rekado>Iâm probably wrong about this; in the past people were supposed to launch window managers with ck-launch-session <hassan>Rekado, thank you. I will try to avoid DM altogether and start X directly on login <cybersyn>sneek tell fossdev "you can already run the Hurd as a service! check out 'childhurd' in the guix blogs. if you're generally interested in microkernels, perhaps take a look at Genode, which is probably the most active user-oriented microkernel system" <sneek>fossdev, cybersyn says: "you can already run the Hurd as a service! check out 'childhurd' in the guix blogs. if you're generally interested in microkernels, perhaps take a look at Genode, which is probably the most active user-oriented microkernel system" <cybersyn>sneek can you repeat that message for fossdev when they return? <tissevert>cybersyn: I think the syntax is «later tell blablabla» <cybersyn>thanks! it was my first sneek attack but had to try in order to learn <tissevert>it also answers the «help» command which is very convenient when you want to help but don't remember the commands too well yourself ^^ I always private message it to help ***zap1 is now known as zzappie
*raghavgururajan peeps in <sneek>Welcome back raghavgururajan, you have 1 message! <sneek>raghavgururajan, pineapples says: Any tips regarding updating the Telegram package recipe? I would like to do it :) <jbv1[m]>Hello guix ! I am looking into packaging julia-1.6 and for that I need to apply patches to the source some that require the "-p1" flag and some the "-p2" any tips on how to do that ? thx ! <civodul>jbv1[m]: hi! you should arrange so that they all need either -p1 or -p2, you can't mix both <jbv1[m]>Problem is that they are not my patches, they are patches that julia needs to be applied to llvm <civodul>maybe you could edit the patches by stripping the extra directory component, just like -p2 would do <civodul>that's for the 'llvm-julia' package, right? <rekado>you can also provide (patch-flags '("-p2")) <rekado>this might make it simpler to update the patches in the future. <jbv1[m]>I am thinking maybe the best is to make llvm-julia depend on the source of julia <jbv1[m]>that way it is also possible to extract the list of patches automatically <PotentialUser-29>What exactly does "guix system reconfigure" do? Does it only change the global configuration? Can I make it recreate users? <leoprikler>You can not exactly make it "recreate" users, but it can create new ones. <PotentialUser-29>So if I want to wipe all user-installed packages from profiles, I have to write a script? <leoprikler>If you are nefarious, however, go ahead, run su and invoke whatever guix command under another user. <PotentialUser-29>Lol, I'm just looking for a quick way to get my system to match the exact state defined in a config while keeping all user documents. I don't like gunk build-up. <leoprikler>user profiles are not regarded as part of the system in Guix <Formbi>how to handle Go subprojects in go repositories? <Formbi>it says «can't load package: package github.com/shurcool/httpfs/vfsutil: no Go files in (âŠ)» <apteryx>hello! It seems overdrive1 is down? It's at least unreachable via SSH. <apteryx>it seems it's only a problem *from* berlin <irfus>rekado: the emacs-exwm pkg adds a launcher that uses 'dbus-launch --exit-with-session ...'. Is that different from or preferable to using ck-launch-session? <irfus>The above is how it seems to be launched from gdm when selected <efraim>I test built an iso9660 image of gnu/system/install.scm, came out to 647M <avalenn>Formbi: you must play with #:unpack-path I think. <avalenn>Formbi: regarding the behaviour of the importer you asked about yesterday it relies at the moment on GOPROXY (proxy.golang.org) which synthetize go.mod for project which don't have one. <irfus>is it possible to replace the pulseaudio server with pipewire on guix-sd? <raghavgururajan>sneek, later tell pineapples: Shoot! I was updating telegram locally few days ago. I yet to clean up some stuff. I'll type out steps to update Telegram and send it you, so that you can update it for upcoming release. Sounds good? <zzappie>anyone has an idea ho can this be that response-code is a procedure when eval it in repl but it's syntax-transofmer when i use it in gexp!? <zzappie>I use same (web responce) module in both environments ***ChanServ sets mode: -o nckx
<sneek>Welcome back vagrantc, you have 1 message! <sneek>vagrantc, lfam says: Thanks for the notes! <raghavgururajan>folks, whats the syntax to build a package using the variable name instead of package name? <civodul>raghavgururajan: you can run "guix build -e '(@ (gnu packages guile) guile-3.0)'" or similar <raghavgururajan>I think its good to put this syntax in 'Invoking guix build' section of manual. <civodul>there are several examples, for "guix package", "guix environment", etc. <civodul>apteryx: hi! "make assert-binaries-available" passes on version-1.3.0! \o/ <fnstudio>hey guix! :) i wanted to give itk-snap a try but i see this when trying "guix environment: error: build of `/gnu/store/y69sa1nw5qzkinl6irc5drzzjvbf8ja7-itk-snap-3.8.0.drv' failed" <fnstudio>anyone knows whether that's normal in certain circumstances or if it should be reported as a bug? <civodul>apteryx: so if you're available, now would be a good time to start "make release" <fnstudio>it's probably worth to mention that this happened on a foreign distro <civodul>hi fnstudio! probably "guix environment" printed "View build log at ...", right? <civodul>mothacehe: congrats on the UEFI stuff, well done <mothacehe>this part of this installer is ... sensitive <civodul>perhaps you can cherry-pick to version-1.3.0? <civodul>i'll have to test on real hardware because it's 100% reliable in a VM :-/ <fnstudio>civodul: not only the path to the log file was printed... it's also bold! sorry :) <civodul>yes and it behaves as intended from what we can see with strace <fnstudio>i can pastebin the rest of the log if relevant of course <civodul>fnstudio: so it seems to be a build failure, perhaps introduced by some changes to dependencies <civodul>could you report it to bug-guix@gnu.org? <civodul>you need to include the output of "guix describe", the command you ran, and the tail of the build log <pineapples>raghavgururajan: Hello! I don't know if you saw the message that sneek relayed, but I've changed my mind and am going to wait with updating Telegram Desktop a little longer <sneek>Welcome back pineapples, you have 1 message! <sneek>pineapples, raghavgururajan says: Shoot! I was updating telegram locally few days ago. I yet to clean up some stuff. I'll type out steps to update Telegram and send it you, so that you can update it for upcoming release. Sounds good? <davexunit>anyone updating guile-3.0-latest to 3.0.6 yet? <davexunit>curious if that's something I could update and push without major rebuilding <raghavgururajan>pineapples: sneek gave me only this: "Any tips regarding updating the Telegram package recipe? I would like to do it :)" <mothacehe>civodul: you can run "guix system image -t uncompressed-iso9660 gnu/system/install.scm" to speed-up ISO creation. *mothacehe reboots to test the layout issue <pineapples>raghavgururajan: This is the message, yeah! My IRC client wouldn't light up my nick in the message in which you asked sneek to relay your message to me, and I assumed you hadn't seen it, or had forgotten to reply to it <pineapples>Either way, a huge update is up ahead, and it'd be a waste of our limited resources to update to 2.7.x <pineapples>I will notify you when it's out, and will get on board with helping you update it :) <apteryx>civodul: phew, guix 1.3.0rc1 was built for armhf-linux <civodul>apteryx: yay! so you launched "make release"? <apteryx>I'm running the './pre-inst-env guix build guix' manually for now, making sure it has substitutes <apteryx>svn had to be built overnight (the test suite takes a loong time -- a nod at svn itself ;-)) <civodul>a bit ridiculous when you think about it :-) <civodul>git-svn is much less useful these days, we should make it a separate package <civodul>though i guess it's easier said than done <civodul>sounds like a request from someone who's been suffering from it :-) <roptat>he, LFS finally switch to git recently :) <roptat>well, not my doing, the lfs devs decided to change server and they changed everything: the website, the repository, they added https support, the mailing list, etc... <vagrantc>pretty much any build which could conceivable be removed for core functionality hurts when on aarch64 and armhf <roptat>lfs finally entered the 21st century it feels like :) <roptat>well, the website is still stuck in the past, but otherwise, great improvements :) <vagrantc>making huge progress on pinebook-pro, by the way ... got patches to linux-libre for master to get it pretty functional with only a few lines of code, and u-boot 2021.07-rc1 + 1 patch that even makes you able to see and interact with the bootloader <vagrantc>(with something other than serial console) <vagrantc>getthe the display to work requires disabling the alternate display via usb-c, but that's no loss since it doesn't work yet <vagrantc>oh, still have to figure out what's up with the trackpad... <mothacehe>civodul: I can confirm the layout switch is ineffective on my laptop for the version-1.3.0 installer <mothacehe>according to strace, the layout request made its way to kmscon though <apteryx>could it be due to the the file system used? <davexunit>civodul: is it okay to push a commit that updates guile-3.0-latest to 3.0.6? <civodul>davexunit: no, i'm working on it, but there'll have to be additional changes <civodul>mothacehe: yes, i've also reproduced it on the metal :-/ <civodul>davexunit: hopefully soon, though i'm context-switching a bit too frequently to be efficient :-) <pineapples>raghavgururajan: Anyways, that's great to hear! >=2.7.2 contains a fix for lib_ui, which should reduce the number of wakeups, thus resulting in lower power consumption under Linux <dongcarl>I built and installed version-1.3.0 (2d086def643f) from source on Ubuntu hirsute and ran a build of a complex manifest afterwards. Quick summary: Guile-zlib required a newer version than is currently packaged in apt, Guile-lib problem reported as #47924 (already solved), coreutils problem reported as #47935 (easily solvable by mounting a tmpfs on <Ikosit>Is there a particular reason for signal-desktop not being packaged for guix? <dongcarl>leoprikler: is electron blobby or just yet-unpackaged? *Ikosit once tried to create a nodejs importer for guix <rekado>we already have npm importers, but none of them are part of Guix <Ikosit>You never know how many stones lay in your way <Ikosit>rekado: Where do i find the importer? <apteryx>civodul: guix built for powerpc64le :-) *vagrantc sits on the edge of vagrant's seat <apteryx>by the way, does *removing* stuff from the manual breaks the string freeze on version-1.3.0? If so, c59cc2383d should be reverted (Remove Nix importer) <vagrantc>shouldn't, unless it ends up re-wrapping some of the strings... <bavier[m]>I think civodul considered the string freeze and decided it was alright for that commit. <vagrantc>looks like it only removes strings, so ... with my expert skill at barely understanding i18n/l10n ... :) <mhj[m]>Hilo all. Glad to be back on Guix on a new computer. I'm using an Intel NUC and everything works fine so far. <tricon>mhj[m]: Welcome back to the club. <mhj[m]>I want to thank the devs for making such a cool system. I'm still learning everything, but I'd like to have btrfs /home snapshots easily implemented as an option in the installer. I dunno if encryption works with btrfs either in the installer... in any case, I just find the possibility of rolling everything back, whether it's the system itself, the home partition or the packages installed to be amazing. My internet connection <mhj[m]>isn't flaky, so I don't often have to worry about broken packages even on standard distros like Arch, Debian or Void, but I just dislike the fact that one broken upgrade can hose your system on those distros. <lfam>I agree, some kind of btrfs-snapshot / backup service configured at the system level would be really nice <lfam>Maybe we can learn from what OpenSUSE does <lfam>I think it would require some form of garbage collection / retention policy, so it might not be completely trivial <mhj[m]>I bought a System76 system and I knew that Guix was the right fit for it :D <mhj[m]>How ya been? I'm working on a school paper right now but just wanted to drop in and see what's new on the Guix front <lfam>We are trying to finish up the 1.3.0 release <lfam>Beyond that, I dunno! Guix is always busy :) ***qyliss_ is now known as qyliss
<mdevos>is there some way to mark bugs as low-priority in debbugs? <lfam>"minor" or "wishlist" I guess <mdevos>I guess the issue (to be submitted) is 'minor' <lfam>I mean, "by sending", not "but sending" <mdevos>(At least for me, it could be serious for someonoe else) <lfam>Well, anyone can change the severity. So, they can raise the level if they want to :) <civodul>apteryx, bavier[m]: indeed, removing strings is OK for the string freeze <nckx>mdevos: Uh, why can't I reproduce it? file $(guix build ustr --target=aarch64-linux-gnu)/lib/libustr-debug-1.0.so.1.0.4 â ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), statically linked, not stripped <nckx>I edited only (string-append "CC=" ,(cc-for-target)). <mdevos>nckx: lemme try on a âcleanâ branch <mdevos>nckx: do you have transparant qemu emulation enabled? Looking at the output of the configure script, it seems that might matter. <nckx>OK, I failed at disabling binfmt_misc (the sysctl interface is a special little boy), second time's the charm. I got the same error you quoted in your mail... autoconf_64b is an aarch64 binary, why... <nckx>...some NIH nonsense of course. <nckx>Yes, it's the Dunning-Kruger build system. <jonsger>can someone share me a working coredump config which collects coredumps? mine is not working <nckx>mdevos: I don't see how the existing Makefile can be used for cross-compiling. If only the author spent half as much time fixing their own broken mess as they do calling others âretardedâ and âcrapâ. <bavier[m]>pretty sure there's an autoconf check already for what they want <bavier[m]>oops, nvm, confused by the "autoconf" strings there. that's not autoconf :) <nckx>It's a horrible broken parody. And I'm 100% sure the author is the kind of person who would call GNU autoconf âbloatedâ. <lfam>Those for whom "other people's use cases" are "bloat" <lfam>Do they really say those awful things nckx? <nckx>This from the person who can't write a Makefile. <nckx>The âuâ is a (very) poor man's mu. <lfam>The longer I'm involved in the world of software, the less kindly I look upon complaints about "bloat" <nckx>Oh: vsnprintf support should be 1; initially I just copied the output of their test proggy. <vagrantc>without bloat, many animals wouldn't survive winter <nckx>I'll fix up the indentation and submit the patch. <lfam>This person would complain about all that unecessary blubber in July <mdevos>I wasn't actually planning to fix the bug (except the CC=(cc-for-target) part) <rekado>(isnât blubber only the insulating fat layer in marine mammalsâŠ?) <rekado>Iâm all for responding to âbloat?â with âblubber!â, of course. <nckx>Is there a less heuristic heuristic than my string-contains? <nckx>I can probably call some part of the toolchain at build time to give me a canonical result but I don't know what. <mdevos>nckx: something like a hypothetical (system-bits TARGET) procedure? <mdevos>nckx: Not that I know of, but you could implement it in (guix utils), and do something like (or (assoc-ref `(("x86_64" . 64) ("aarch64" . 64) ("i686" . 32)) ARCHITECTURE) (error "please define the bits of ARCHITECTURE!")) <nckx>Maybe, or maybe just $ARCH-gcc --gimme-info=bitness. Or... I could make my fix less trivial and patch the makefile to use non-target âgccâ to compile the autoconf_* probes. <nckx>After some reconsideration, I'm going to try my latter idea first. <lfam>Can we drop 2.29 from %default-locale-libcs yet? <Noisytoot>mdevos, Why are you using assoc-ref/or instead of case? <mdevos>reminder: when in doubt, use ,(string-append "CC=" (cc-for-target)) instead of "CC=gcc"! This is important when cross-compiling. However, in some rare very cases, "CC=gcc" is actually correct. <mdevos>Noisytoot: (eqv? "a" (string-copy "a")) --> #f <mdevos>'case' compares stuff with eqv?, not equal? <mdevos>and copies of strings are equal?, but not eqv? to each other <mdevos>assoc-ref uses equal?, assq-ref eq?, assv-ref eqv? <Noisytoot>Is there a version of case that used equal?? <mdevos>Noisytoot: not that I know of, but it should be easy to define using syntax-rules, cond and string=? <mdevos>nckx: IIUC, that code detects 64-bitness for the system being compiled on, instead of the target. Most likely, the latter is needed <nckx>I forgot to credit you directly, since I don't usually use âFixes: <URL>â. Sorry about that. *nckx usually types âReported by rando on #guixâ :) <Noisytoot>mdevos, What is the difference between string=? and equal?? <nckx>mdevos: Great! Can I count on you to close the bug? <mdevos>Noisytoot: try string=? on two booleans in a guile REPL <Noisytoot>mdevos, What's the point of having string=? then? <mdevos>Noisytoot: for when you know the two arguments are strings. <Noisytoot>Is there an advantage of using string=? if you know if the two arguments are strings? <mdevos>Then if you accidentally somehow pass two other objects, you get an exception informing you did something wrong, e.g. you misunderstood some code <mdevos>maybe there is a tiny performance benefit as well <nckx>There is the possibility of optimisation, even if Guile might not take advantage of it (I don't know; civodul might). <mdevos>e.g., if (string=? X Y) returns something (whether #t or #f), then guile can optimise (string? X) to #t and (string? Y) to #t <mdevos>I recommend #guile if you want to know more <guest00000>Hello. How can I vew guix output logs on a systemd system? <mdevos>guest0000: I guess using journalctl, but I don't know the details <lfam>guest00000: Which logs are you looking for? <mdevos>or maybe there are some logs under /var/log/ as well, like on Guix System <guest00000>lfam: running guix system image errors out at disk-image build. The output logs are at /var/log/guix/drvs. When I less/cat the log file, it's all binary <nckx>guest00000: If the name ends in .bz2, use bzcat. <lfam>Oh. Those logs are compressed, so you need to copy them out of /var/log/guix/drvs, decompress them, and then read them. Vim opens the compressed files transparently <nckx>guest00000: Or bzless/zless of course. <nckx>If you like âscrollingâ like a âmodern humanâ. <lfam>I often do `vim $(guix build --log-file foo)` <lfam>It doesn't work anymore for logs from ci.guix.gnu.org, sadly. It used to work with hydra.gnu.org <lfam>I guess there is a MIME type not being set somewhere <nckx>How would vim $(guix build --log-file foo) pass through MIME info. <nckx>It would use naive extension sniffing or fancy libmagic/file. <nckx>That sounds like something worth fixing, lfam. <lfam>I've only been complaining about it since we ditched hydra.gnu.org :) <lfam>I'd guess the HTTP response includes some MIME data, but I really have no clue about these things <sss>i have problem with guix environment, i trying to create isolated dev environment to do some coding, but i got linking somehow wrong <nckx>Noisytoot: Because it predates gzip. The âzâ stands for the â.Zâ from the obsolete compress utility. <guest00000>oh one more thing, how do I specify image output location? The log file says no space left on device, but the location it is writing to is /tmp/ <nckx>*obsolete and entirely incompatible, so presumably there was a zcat that sniffed the exact format once. Maybe GNU zcat still does that. Wouldn't surprise me. <lfam>With systemd, that means something like 'Environment=TMPDIR=/home/lfam/tmp/guix-build' in guix-daemon.service <Noisytoot>nckx, It does (it can view a file compressed with compress) <nckx>I think that's mandated by POSIX (of course, GNU is not POSIX, but still). <nckx>Well, I think POSIX says âzcatâ has to read the output of âcompressâ, so you could just ln -s gzip compress đ <nckx>No, it's a different format. I just meant that if my recollection is correct (and it may well not be), the actual format isn't defined, just that compress | zcat has to work. Anyway, irrelevant by decades. <Noisytoot>Why does Guix use lzip rather than xz for substitutes? <Noisytoot>(or ZStandard, which Arch GNU/Linux switched to) <nckx>Noisytoot: zstd support is available. <nckx>XZ and lzip are the same core (LZMA), just a different container format (which lzip claims is superior, but meh). lzip is GNU. <Noisytoot>nckx, The lzip website is on nongnu.org, not gnu.org <nckx>It support gzip, lzip, and most recently zstd. <nckx>The gzip is only for compatibility with older installations. <nckx>There's no reason to use it. <nckx>Whatever you request. I'm not sure what the client default is now. <roptat>I think the client defaults to "whatever is best", it has a magic formula to know the best compression/bandwidth ratio <roptat>and then choose the best out of the available substitutes <mdevos>I'm trying to make libtommath cross-compilable. I set CC=(cc-for-target) and set CROSS_COMPILE=TARGET- (specific to libtommath) in #:make-flags. It starts compiling just fine, using the cross-compiler, but then, when linking, it used the native compiler! (libtool: link: gcc -shared -fPIC -DPIC THE-.o-FILES), resulting in: 'ld: .libs/SOME-.o-FILE: error adding symbols: file in wrong format". Any idea? <terpri>oh nifty, i didn't realize lzip did (or could) support zstd <terpri>now i just have to wait for the next grub release for btrfs+zstd support... <nckx>terpri: lzip doesn't support zstd. <nckx>For substitutes, at least. <terpri>oh, i misinterpreted you, whoops <jonsger>Guix is where the future didn't arrived yet :P <lfam>Also, I'm using btrfs+zstd now on Guix System <lfam>In my file-system's options I have "compress-force=zstd" <nckx>terpri: zstd âsupportsâ decompressing lzma (xz), lz4, gzip etc. if you let it (we don't). It's horribly confused at what it should be, awesome algorithm or some Windows-style âarchive managerâ. <nckx>terpri: Guix's GRUB has supported it for almost a year, I think? <nckx>On Guix, the future is here today. <roptat>sss, I found that running programs compiled outside a guix package doesn't work well when looking for libraries, but using LD_LIBRARY_PATH fixed the issue for them (in your case I'd run LD_LIBRARY_PATH=$GUIX_ENVIRONMENT/lib ./client/X11/xfreerdp) <roptat>I'm not sure what's so different between a local build and a build by the guix daemon though, so maybe there's a better solution <terpri>oh. i'm really behind on release notes, i guess :p i'll enable compress=zstd and then 'btrfs fi defrag -czstd ...' should do the trick <roptat>i.e. bringing the two builds closer to one another, so it works immediately <Frosku>How can I remove network-manager-applet from desktop-services? I want to replace it with nm-dmenu <mdevos>It seems the linker is hard-coded into libtool, during the configuration of libtool itself. <nckx>terpri: I double-checked (didn't want to find out I was using a forgotten fork through your failure to boot...) and it's been supported since July 2019. So zstd away. <sss>roptat: problem is what program also does not work inside container itself <sss>and only hack which is working for me is LD_PRELOAD for libgcc_s in both container environment and foreign host os <mdevos>the issue is more complicated than first though, it will have to wait for now *nckx sets table for more BIND CVEs. <lfam>I'm getting a chance to use Debian as a development environment... ahen <lfam>It's good to be reminded of the good points of Guix :) <lfam>It's clear why things like Docker were invented <Formbi>have you encountered a dependency loop yet? ;) <lfam>I'm not used to build instructions being basically undocumentable <lfam>Maybe I give up and just use a precompiled copy of this thing <nckx>Package it for Guix, install Guix, profit? <lfam>It's the bootloader / firmware for the macchiatobin <lfam>It's basically undocumented outside of some copy / pasted commands that might have worked at one point on some Debian installation <nckx>It has nothing to do with Pale Moon. Disappoint. <apteryx>/gnu/store/6iar03pdw42w0p738m401cczbmqx08s5-guix-1.3.0rc1.drv takes forever to build on our POWER9 VM <civodul>apteryx: perhaps you should see with cbaines if the Coordinator agents can be temporarily stopped, or one of them <cbaines>civodul, Coordinator agents on a powerpc64le machine? <lfam>The compilation instructions for this bootloader all say to use the master branch đ <cbaines>regardless, they can probably be stopped <zzappie>what is record-abi-mismatch-error? o.O recompilation needed? Anyone knows what is this thing? <lfam>zzappie: It means that you need to run `make clean-go` :) <lfam>Some ABI (application binary interface) changed, but some of your compiled files are still using the old one <lfam>I assume you're seeing this in your development repository <lfam>nckx: Remember that we should fix the bundled BIND in isc-dhcp too (I've done it) <nckx>Meh, I'll try to remember but it's unlikely I will, since I knew that. <zzappie>lfam: It seem to have gone after clearing .cache/guile *nckx ties another knot in the ol' snotrag. <lfam>Oh yeah, that too zappie :) <lfam>nckx: There's a comment right above the version of BIND :) <nckx>It's filthy, but the make rule could rm -rf ~./cache/guile it âjust in caseâ. <lfam>It's not exactly "Beware of the leopard" territory <lfam>Maybe we can stop using a bundled BIND <nckx>I *know* that comment is there. <lfam>Figuring that out has been on the bottom of my todo list for a long time <nckx>using <marquee> in scheme comment howto <lfam>Maybe some eye-catching emojis <nckx>lfam: I a$$umed that it had to be a different (stable?) series from what we ship. <nckx>lfam: That's actually... tempting. <lfam>Well, maybe it does? That package predates me, so maybe something has changed by now <nckx>đ đ„ this comment is for nckx đ„ đ *nckx hates peaches so that is a very scary comment. <lfam>That must be because you aren't in the US <lfam>I think of peaches as supremely USAmerican <nckx>There's that song about going down to the country and eating a lot of peaches but I wasn't aware of them otherwise being a cultural phenomenon. <lfam>Mainly in the southeast areas of the county <nckx>I already watch baseball and drink root beer, what else do you people want from me. <lfam>That's enough for one lifetime