IRC channel logs


back to list of logs

<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
<lfam>Hopefully that program is similarly minimal
<Formbi>but kinda works and it doesn't have a go.mod either
<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.
<cybersyn>also re: emacs-as-a-service, sweet!
<lfam>It fails while generating the profile? Not while building openjdk?
<cybersyn>lfam: yeah, but others install fine
<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>ohhhh thats what I was missing
<lfam>The --profile argument to `guix package` is the thing to read about: <>
<cybersyn>cool, i'll get on it. thanks for the help troubleshooting!
<lfam>Cheers :)
<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
<cybersyn>word. will do
<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>If you're curious about our guidelines of what can be included in Guix, we follow the Free System Distribution Guidelines:
<lfam>sneek: later tell pineapples: Like this
<pineapples>Thanks, lfam!
<sneek>Welcome back pineapples, you have 1 message!
<sneek>pineapples, lfam says: Like this
<lfam>sneek: botsnack
<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
<cybersyn>oh yeah! why i suddenly got interested
<pineapples>sneek: later ask raghavgururajan: Any tips regarding updating the Telegram package recipe? I would like to do it :)
<sneek>Got it.
<lfam>That's inspiring. Never stop learning!
<cybersyn>*high five*
*lfam afk
<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>lfam: also need to package
<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!
<sneek>Will do.
<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.
<aecepoglu[m]>What else do I need to setup?
<aecepoglu[m]>(oh I think I need a `make` and `make check`)
<lfam>The make is necessary, the check is recommended
<fossdev>when u release Hurd version
<fossdev>i sick of Linux
<fossdev>really they going to use rust
<Aurora_v_kosmose>I'm getting a build failure on guix pull.
*donotshake[m] < >
<Aurora_v_kosmose>Exactly that, yes.
<donotshake[m]>curious. Down to the hash on module-import-compiled.drv?
<Aurora_v_kosmose>bzcat '/var/log/guix/drvs/qm/y8ywgkhf09piwjv28giwcllhnpb8dh-module-import-compiled.drv.bz2' | less
<Aurora_v_kosmose>I closed the terminal, but that was the log file generated.
<samplet>Huh. I get the same error. I just pushed two commits -- let me double check everything.
<fossdev>when hurd version releases
<fossdev>anyone here
<fossdev>i have questions
<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>Alright :)
<samplet>Thanks for the tip, though!
<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.
<samplet>Sorry again to everyone!
<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
<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>I mean no PolicyKit service*
<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
<tissevert>hi guix
<hassan>Rekado, thank you. I will try to avoid DM altogether and start X directly on login
<hassan>Hello Tissevert
<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
<raghavgururajan>Hello Guix!
<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?
<jbv1[m]>ok so that's what I'll do.
<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>A good sysadmin doesn't do such a thing.
<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
<PotentialUser-29>Ah, got it. Thanks for the help
<Formbi>how to handle Go subprojects in go repositories?
<Formbi>like this for example:
<Formbi>I have this and it doesn't work:
<Formbi>it says «can't load package: package no Go files in (…)»
<apteryx>hello! It seems overdrive1 is down? It's at least unreachable via SSH.
<apteryx>oh, I was able to login now.
<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 ( 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?
<Formbi>but now a test fails…
<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?
<sneek>Will do.
<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
<nckx>Good morning, Guix.
<nckx>Hi pascallor.
***ChanServ sets mode: -o nckx
<vagrantc>hello guix
<sneek>Welcome back vagrantc, you have 1 message!
<sneek>vagrantc, lfam says: Thanks for the notes!
<vagrantc>sneek: botsnack thanks
<raghavgururajan>Morning nckx! Hello vagrantc!
<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>it's in the manual... somewhere
<civodul>lemme see
<civodul>there are several examples, for "guix package", "guix environment", etc.
<civodul>and at
<raghavgururajan>Ah, its under 'additional build options'.
<raghavgururajan>yes that.
<raghavgururajan>Never mind then. :D
<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>i'm still investigating but that can wait
<civodul>hi fnstudio! probably "guix environment" printed "View build log at ...", right?
<civodul>what does that build log show?
<civodul>mothacehe: hi!
<fnstudio>let me see...
<mothacehe>civodul: hey!
<civodul>mothacehe: congrats on the UEFI stuff, well done
<mothacehe>thanks, hopes its regression free
<mothacehe>this part of this installer is ... sensitive
<civodul>perhaps you can cherry-pick to version-1.3.0?
<civodul>so that'll make it into the RC
<mothacehe>sure I'll do it now
<civodul>i'm looking at the weird keyboard switching issue:
<mothacehe>yeah that's my next stop
<civodul>i'll have to test on real hardware because it's 100% reliable in a VM :-/
<mothacehe>your patch seemed fine to me though
<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>civodul: it seems to mention "error" here
<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
<fnstudio>thanks v much civodul
<civodul>you need to include the output of "guix describe", the command you ran, and the tail of the build log
<fnstudio>good to know
<civodul>great, thank you, fnstudio
<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>the compression takes quite some time
*mothacehe reboots to test the layout issue
<civodul>oh nice
<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
<apteryx>now trying for powerpc64le
<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>it's easier to debug
<apteryx>svn had to be built overnight (the test suite takes a loong time -- a nod at svn itself ;-))
<civodul>ah good
<civodul>oh, svn?
<apteryx>for git I guess
<apteryx>not sure
<civodul>ah yes, possibly
<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
<apteryx>I agree!
<civodul>though i guess it's easier said than done
<civodul>i vaguely recall past attempts
<vagrantc>yes please
<civodul>sounds like a request from someone who's been suffering from it :-)
<roptat>he, LFS finally switch to git recently :)
<civodul>meanwhile is still on CVS
<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
*civodul nods
<roptat>lfs finally entered the 21st century it feels like :)
<roptat>svn on armhf :/
<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>testing in a VM now
<mothacehe>according to strace, the layout request made its way to kmscon though
<mothacehe>and works in a VM, strange :(
<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?
<raghavgururajan>pineapples: I see. I am almost done with the update. :D
<civodul>davexunit: no, i'm working on it, but there'll have to be additional changes
<civodul>in Guix
<civodul>mothacehe: yes, i've also reproduced it on the metal :-/
<davexunit>civodul: oh, okay.
<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
<pineapples>..or should I say, it uses an updated lib
<pineapples>_ui version that has the fix
<raghavgururajan>I see.
<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?
<leoprikler>or Electrum
<leoprikler>big JS stuff anyway
<dongcarl>leoprikler: is electron blobby or just yet-unpackaged?
<leoprikler>Old but relevant:
*Ikosit once tried to create a nodejs importer for guix
<Ikosit>I actually got pretty far
<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?
<rekado>I don’t know
<Ikosit>visible confusion
<mbakke>Ikosit: there is one in the 'wip-node-importer' branch:
<Ikosit>So it's binary only :/
<apteryx>civodul: guix built for powerpc64le :-)
<apteryx>I'll let 'make release' run
*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.
<mhj[m]>i3, 16 GB of RAM
<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]>Hiyo lfam, nice to seeya again!
<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 :)
<mhj[m]>That's awesome!
***qyliss_ is now known as qyliss
<mdevos>is there some way to mark bugs as low-priority in debbugs?
<lfam>mdevos: You can set the 'severity':
<lfam>"minor" or "wishlist" I guess
<lfam>And you do it, as described at <>, but sending a message with "severity $bugnumber $severity-level" to <>
<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)
<mdevos>lfam: thanks!
<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
<civodul>that commit is a strict removal
<nckx>mdevos: Uh, why can't I reproduce it? file $(guix build ustr --target=aarch64-linux-gnu)/lib/ → 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.
<mdevos>here's the full log: <>
<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?
<Noisytoot>The author of what?
<mdevos>Noisytoot: ustr
<nckx>This from the person who can't write a Makefile.
<lfam>I'll remember this
<nckx>It makes me angry.
<Noisytoot>The United States Trade Representative:
<nckx>Noisytoot: Unrelated :)
<nckx>The ‘u’ is a (very) poor man's mu.
<nckx>I think this hack fixes it, mdevos <>.
<rekado><3 the comment
<lfam>The longer I'm involved in the world of software, the less kindly I look upon complaints about "bloat"
<nckx>It is a smell.
<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
<mdevos>nckx: Perhaps you could submit it as a patch? <>
<nckx>I'll fix up the indentation and submit the patch.
<nckx>Yes, good idea 😉
<vagrantc>oh wait, that's blubber
<lfam>Same difference
<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…?)
<mdevos>it was just something I noticed
<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>or (bits-for-target)
<bavier[m]>I think there is a procedure for that.
<bavier[m]>I guess I'm doing a lot of wishing lately.
<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.
<bavier[m]>oh, this: target-64bit?:
<nckx>Thanks all.
<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=?
<nckx>So <> works... but is more fragile. I'm not wild about using target-64bit? here but it might be less bad after all.
<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've pushed the result.
<mdevos>nckx, that commit LGTM <>
<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??
<mdevos>no problem
<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>nckx: done
<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.
<nckx>They are compressed.
<nckx>If it's .gz, use zcat.
<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, sadly. It used to work with
<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.
<Noisytoot>Why is it called zcat rather than gzcat?
<nckx>That sounds like something worth fixing, lfam.
<lfam>I've only been complaining about it since we ditched :)
<guest00000>It works. Thanks!
<lfam>I'd guess the HTTP response includes some MIME data, but I really have no clue about these things
<sss>hi all
<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>guest00000: Set TMPDIR in the context of the guix-daemon:
<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 😛
<Noisytoot>nckx, file says: compress'd data 16 bits
<Noisytoot>So I think it's not gzip-compressed
<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.
<Noisytoot>Does support it?
<nckx>XZ and lzip are the same core (LZMA), just a different container format (which lzip claims is superior, but meh). lzip is GNU.
<nckx>Noisytoot: Yes.
<Noisytoot>nckx, The lzip website is on, not
<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.
<Noisytoot>What is the default?
<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
<lfam>Relevant blog post:
<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...
<lfam>Does lzip support zstd?
<nckx>terpri: lzip doesn't support zstd.
<nckx>Guix does!
<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.
<sss> - any ideas how to properly solve it ?, if i add libdir like /lib , /usr/lib it will cause problems because of conflicts with other system libraries of runing outside container, and still failing inside
<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>I think I found the issue (with libtommath and libtool). <>, <>.
<mdevos>It seems the linker is hard-coded into libtool, during the configuration of libtool itself.
<mdevos>I'll open an issue
<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 :)
<civodul>sudo apt install guix
<lfam>It's clear why things like Docker were invented
*lfam sweats
<Formbi>have you encountered a dependency loop yet? ;)
<lfam>No, not that
<lfam>I'm not used to build instructions being basically undocumentable
<lfam>Guix has spoiled me
<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 😭
<civodul>cbaines: yup!
<civodul>not you?
<cbaines>that's more lle-bout's area
<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
<zzappie>this is the firt thing I did...
<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’.
<nckx>lfam: That's my point.
<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>If not, great.
<nckx>lfam: That's actually... tempting.
<lfam>Well, maybe it does? That package predates me, so maybe something has changed by now
<lfam>That's my hope
<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
<lfam>I know they aren't
<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>They are
<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