IRC channel logs


back to list of logs

<cbaines>sneek, later tell civodul I've got a quick reproducer now for a Guile SQLite segfault, I haven't found a fix yet though...
<sneek>Got it.
<cbaines>sneek, later tell civodul here's the link
<sneek>Got it.
<luis-felipe>I noticed that the image used to promote GuixDays is kinda jaggy, is it intended to be like that?
<lfam>It would be nice to fix it
<roptat>oh yeah, I didn't pay attention to it before, now I see it ^^
<luis-felipe>Also, when publishing it in Mastodon or any other service that allows people to change GUI colors, it would be better to add a solid background to the image to avoid contrast problems.
<roptat>will keep that in mind
<luis-felipe>Changing the subject, anyone here that plays online games in Guix and uses some voice chat application that allows more than two people to chat? I'm looking for the latter.
<leoprikler>Not so big on the online game front, but Mumble is nice for chatting (assuming you mean voice).
<leoprikler>Downside is you need someone to host a server or host it on your own.
<luis-felipe>leoprikler: yes voice. I installed Mumble, but don't know how to use it. I don't know if one has to run its own server
<luis-felipe>Yeah, that's the problem :)
<leoprikler>There are also public servers out there, but I'm not sure whether this is an option for you.
<luis-felipe>The Mumble application displays a list of servers, but they seem like servers for some topics or communities only, so I didn't connect to any.
<luis-felipe>I tried jitsi and it worked for one game session, but then it seems that it started to cause Internet problems on the side of people using Windows.
<luis-felipe>Mumble seems nice because it is designed for what I want, but the server thing I don't understand well...
<leoprikler>I can guarantee you that Mumble is superb for gaming, but being a Qt app it's a little hard on those who expect 0 configuration to be meaningful.
<leoprikler>Hosting a mumble-server is not too difficult. You could even get it done locally in your Guix config.
<leoprikler>The problem is going to be hosting a server for everyone. I assume you don't already have a server out in the wild, that you have SSH access to, do you?
<leoprikler>[speaking of, I'll do some advanced SSH hopping to update mine real short]
<luis-felipe>No I don't, I just have a Guix System desktop with home internet, I don't know if I can open ports required for the server...
***trav27412 is now known as travankor
<OriansJ>apteryx: I've long since accepted the work as thankless (The death threat from a crypto-asshole was a little much) but it I do find it extremely fun and enables me to give people a complete understanding of how exactly everything works and how to fix it if anything breaks. It is a very low issue environment; were things do exactly what one would expect and breakages are quick to spot and easy to fix.
<OriansJ>It is the sort of fun development; I wish other people could also enjoy. Lots of small programs that do 1 thing and when an issue occurs; just look at the one thing and walk it to the problem.
<cbaines>sneek, later tell civodul so, I've stayed up far too late, but I think I figured it out
<sneek>Will do.
<mroh>sneek, later tell luis-felipe for a mumble server (murmur) running on your machine, you only need to forward one tcp and udp port (64738 standard) on your router.
<sneek>Got it.
<mroh>sneek: botsnack
<KE0VVT>What would be the best way to completely archive youtube-dl in both source and package forms?
<ryanprior>KE0VVT: the youtube-dl source is packaged in the Software Heritage Archive:
<ryanprior>The full dependency graph and build system are archived in Guix:
<ryanprior>If you want to make those even more durable, here's what I'd recommend: 1) download the source code; 2) guix pack --save-provenance youtube-dl; 3) make a torrent for the tarball with both those things included; 4) share the torrent on lots of trackers & convince people to seed it
<ryanprior>Donating time and money to the GNU project and Software Heritage also helps.
<ryuslash>hey everyone :) I'm having some trouble getting Guix System to run. When I try to boot up my system I just get "error in finalization thread: Success" and "udevd: no sender credentials received, message ignored"
<ryuslash>this is on a fresh install, I've tried both the stable and latest installation images
<ryuslash>any help in getting this to work would be greatly appreciated :) I'd really like to get Guix System to work
<nckx>ryuslash: Any other messages? Both lines are expected & harmless.
<ryuslash>well, there's a message about pcspkr already having been registered, but blacklisting it doesn
<ryuslash>doesn't help...
<nckx>Heh, another regular harmless message.
<nckx>I think there are 4.
<ryuslash>other than that nothing that indicates any error to me. loading
<nckx>Everyone gets them, but they aren't related to booting.
<nckx>ryuslash: So the installer booted and ran fine?
<ryuslash>loading /gnu/store/...-sysem/boot, making /gnu/store/...-system the current system, setting up setuid programs, populating /etc
<nckx>s/aren't related to/have no effect on/
<nckx>ryuslash: That's all good.
<ryuslash>nckx: yup, booted fine, ran it a few times because I couldn't get disk encryption to work at first
<nckx>ryuslash: I suggest you [also] send your question to help-guix at, if possible with a screenshot.
<ryuslash>will do :)
<nckx>I'm off to bed, it's 05:08 here. Ridiculous.
<nckx>Good night.
<ryuslash>have a good night / morning :)
<vits-test>Will 'patch-shebang replace for ex. "python" with /gnu/store/... in:
<vits-test>#!/bin/sh exec python ...
<vits-test>? Or one need to use env?
<xelxebar>vits-test: I guess you could look at guix/build/gnu-build-system.scm(patch-shebangs)
<xelxebar>It looks like it'll replace anything under /bin or /sbin...
<vits-test>xelxebar: tx
*vits-test what was max bang length, heh
*vits-test seem 127
<xelxebar>vits-test: See the execve(2) manual page, and search for "maximum length". It looks like 127 is the maximum for kernels before 5.1; however for >=5.1 it claims the maximum is increased to 255.
<xelxebar>vits-test: You could also be an experimentalist and set shebangs like #!/./././././././bin/foo until something breaks.
<vits-test>xelxebar: :)
<xelxebar>vits-test: And if you're into compiling your own kernels, you can change this by editing BINPRM_BUF_SIZE in include/uapi/linux/binfmts.h :)
<xelxebar>Pretty sure that limt is the same for the interpreter set using the binfmt-misc interpreters as well.
***apteryx is now known as Guest14481
***apteryx_ is now known as apteryx
<vits-test>xelxebar: heh, never edited any file, just switched the knobs of `make nconfig`.
<mfg>Hi guix :-)
<mfg>what is the difference between ~/.guix-profile and .config/guix/current ?
<mfg>the .config dir is also under ~
<efraim>anyone else just start having problems getting substitutes from berlin?
<janneke>mfg: ".config/guix/current" is the guix pull profile, "~/.guix-profile" are the user's packages
<mfg>Ah okay, thank you :)
<janneke>mfg: yw, try: guix package -p ~/.config/guix/current -l
<mfg>this gives me the correct output, i guess. I just tried to install guix on another distro which uses runit, it does work, though it's impossible to guix pull as root, because it takes forever and doesn't even start fetching anything from git. It definitively wasn't good to use the 1.1.0 binary tarball :'D
<mfg>As i understand it the guix-daemon that's run is the one from root's profile?
<mfg>so i have to pull as root to update the system guix-daemon?
<mfg>it's also possible that the network is unstable...
<janneke>yes, on a foreign distro that's probably the case
<mfg>i see
*civodul wonders whether they broke "guix publish"
<mfg>yep the network here is too unstable :|
<abralek>Hi Guix
<abralek>I was packaging zerotier, and have just realized that they changed the license from gpl3+ to bsl11 Busincess Source License 1.1
<erkin>Is it a free software licence?
<nckx>Morning Guix.
<nckx>erkin: No.
<vits-test>nckx: Hello. What, aren't gpl3+ protects from a such?
<nckx>‘If it weren’t for the problem of GPL-phobia we’d likely have stayed with the GPL (with a dual licensing model) or even considered the slightly stronger AGPL, but GPL-phobia prompted us to consider other options.’
<abralek>It was gpl3 not +
<nckx>Blame the GPL [misconceptions] for going non-free. Nice?
<mfg`>What exactly is GPL-phobia?
<sneek>mfg`, you have 3 messages!
<sneek>mfg`, nckx says: On Guix, use ‘-bios $(guix build ovmf)/share/firmware/ovmf_x64.bin’, don't muck about with file names at all. ☺
<sneek>mfg`, NieDzejkob says: I don't see why you'd want to do that. Either do parallel or don't, but setting the parallelism to a specific number per package makes no sense
<sneek>mfg`, NieDzejkob says: builds are parallel by default, but you can add #:parallel-build? #f to arguments to disable it
<erkin>Isn't MariaDB GPL?
<mfg`>lel i haven't noticed that i now have a backtick, argh, those messages seem to be rather old... But thanks anyways :-)
***mfg` is now known as mfg
<mfg>i have to reboot
<civodul>sneek: seen NieDzejkob
<sneek>civodul, you have 3 messages!
<sneek>civodul, cbaines says: I've got a quick reproducer now for a Guile SQLite segfault, I haven't found a fix yet though...
<sneek>civodul, cbaines says: here's the link
<sneek>civodul, cbaines says: so, I've stayed up far too late, but I think I figured it out
<sneek>NieDzejkob was in #guix one month and 14 days ago, saying: yeah, some usecase like cross-compiling to Hurd started failing. It looked like some substitute* started failing silently so I started working on #42146, and that *is* a rabbit hole.
<nckx>Zerotier's dishonesty seems to be deliberate, not merely bad writing: the author tries the same trick here but is at least called out on it:
<nckx>Maybe check out Nebula? 😉
<vits-test>nckx: funniest part is word "open" there and there, as if they never read about GPL.
*abralek sad
<abralek>I have never tried nebula, will give it a try
<abralek>nckx: Thanks!
<abralek>nckx: My emacs doesn't show that WINKING FACE =)
<abralek>but it does show white smiling face though
<nckx>☺ (U+263A) and 🙂 (U+1F642) look similar, but the latter is much older. The latter's an emojo, so is my 😉 (these are just string substitutions I've set up manually in HexChat). I think Emacs emojo support is known to be problematic.
<nckx>They don't show up in Guix's IceCat here either.
<nckx>s/but the latter is much older/but the former is much older/
<vits-test>also the former do not require google-noto, and the latter is a big square
<nckx>Other fine emojo fonts are available (but perhaps not in Guix).
*nckx changes their :- ) auto-replacement to ☺
<jlicht>hey guix!
<vits-test>sneek: botsnack, jlicht isn't intruder
<kmicu>( ^_^)/
<jlicht>What would be a good place for an example/default configuration file for a package? So this file would rather serve as documentation/inspiration, to be copied and modified by a user as needed
<vits-test>jlicht: for what package? For Sway WM, it's /etc/sway/config.
<jlicht>vits-test: skopeo. So in the sway example, this config file would just be there, but not loaded by default by sway?
<vits-test>jlicht: it is loaded
<vits-test>jlicht: nftables place same (/etc/packagename), but those do not.
<vits-test>honestly, both are /gnu/store/XXXX/etc/packagename.
<vits-test>also /share/doc/examples used..
<vits-test>* /share/doc/pkgname/examples
<nckx>* /usr/share/doc/,name-,version/examples
<jlicht>that seems more like what I had in mind
<nckx>(I just use /etc.)
<vits-test>doc/../examples seem to house things not ready to be loaded as is?
<nckx>I wouldn't expect any logic beyond /share/doc/.../examples containing examples, and I'm sure some packages violate even that ☺
<nckx>It's an unpoliced zone.
<jlicht>ah, that is a clear distinction then. Thanks vits-test nckx! I'll go for /etc/ for now, as it won't be loaded anyway.
<jlicht>Always nice to have a relaxed lunch over some bikeshedding ;-)
<nckx>Bon appetit ;-) I was just being honest about where I dump these things when doing so doesn't cause unexpected run-time behaviour; not giving an official recommendation. I'm not aware of a policy at all.
<nckx>rekado_: <> would greatly benefit from your time if you have any.
<nckx>How did that nongnu get in there? works too.
<zimoun>nckx: hehe!
<janneke>some non-gnus are more gnu than others
*nckx sends a friendly ‘Get best SEO now!!’ mail and CCs all lists.
<zimoun>who is planning to send something to LibrePlanet 2021 ?
<roptat>oh, I could do something, but I'm not sure what a "session" is for libreplanet. is it like a talk? or a room in Fosdem (with multiple talks)?
<leoprikler>Regarding those licensing things earlier: My personal intuition was, that you'd use the LGPL if you wanted "GPL, but less scary please", no?
<roptat>oh, a talk from the look of the second page in the form
<jlicht>leoprikler: are you talking about the zerotier-related stuff?
<leoprikler>yes, that
<jlicht>Any plausible deniability on their misapprehension regarding licensing subtleties goes right out of the window with the last paragraph of their blog post :/
<zimoun>roptat: yeah, I have been confused too, since “session” in academic is generally a block of talks. Here it seems only a talk.
<leoprikler>In my opinion, the name "Business Source License" already spells out the intent quite clearly, that being that they want to make money, not (free) software.
<jlicht>Painting a picture where you came up with a suboptimal compromise because you'd like your employees to have stable income is at least understandable, but once you start talking about the plight of investors, and then spin this very same compromise as a sustainable strategy for the future... count me out
<vits-test>jlicht: please use english :)
<Formbi>is it possible to use the xfce panel plugins?
<nckx>While abusing ‘free as in freedom vs. beer’ to do so.
<Formbi>I installed one, but I can't add it to the panel
<leoprikler>Also mushing in "open source" for extra points.
<jlicht>vits-test: I know English is not my native language, but were there that many mistakes in my text?
<vits-test>jlicht: too long lines :)
<jlicht>ah, loud and clear :-)
<vits-test>jlicht: use, (define compromise ...) and more .
<vits-test>there are much educated people violating my right to see simple english! no more! i'm protesting!
<leoprikler>wait, I'll translate
<nckx>It would have been a shame to lose jlicht's thoughts to brevity IMO.
<leoprikler>Not using GPL, because you need food: Maybe unethical, but understandable.
<leoprikler>Not using GPL, because you want more money: Yeah, that's bad.
<leoprikler>For a more theatrical read, I recommend Der gute Mensch von Sezuan (The Good Person of Szechwan).
<leoprikler>Or Saint Joan of the Stockyards.
<jonsger>lovely Bertold Brecht :)
<zimoun>mothacehe: some issue why CI? A lot of R packages are not available for substitution. Which is annoying… because of the coming-soon release, and mostly because I need them. ;-)
<mothacehe>zimoun: yes the build farm is really slow with more that 120.000 queued builds according to
<mothacehe>I need to investigate why.
<zimoun>do you think the substitutes could available the day we will release? Well, this issue constraint the release date. IMHO.
<mothacehe>cancelling the whole queue and adding a version-1.2.0 specification should help
<zimoun>mothacehe: branching is not done yet.
<shoxy>Hi everyone! I have a security question about guix: does someone have more infos for me about the security conception and security update policies in guix system? I am thinking about using it as a productive server, but am questioning how guix differs from e.g. centos in terms of security.
<civodul>mothacehe: i'll email my findings on the deadlock
<civodul>it's terrible!
<mothacehe>civodul: can't wait to read it anyway ;)
<civodul>don't hold your breath, i don't have any solution...
<zimoun>civodul: deadlock of CI?
<mothacehe>daemon deadlock
<zimoun>mothacehe: thanks. Really interesting… I have missed that
<vits-test>shoxy: any user can `for x in $(guix package -A); do guix build --cores $((nproc * 10)) $x; echo haha; done`
<janneke>yeah, it's terrible -- thanks for looking into this
<civodul>i just closed 44442
<civodul>e-hug to whoever gets #44444!
<zimoun>hard because Emacs dv (or any GNU packages using the debbugs instance) can stole the #44444. Snif!
<zimoun>“guix graph --manifest” or “guix size --manifest” are not implemented. Is it because no one did or is it because I am missing technical details?
<civodul>zimoun: because nobody did it, and maybe because it's not that useful
<civodul>hi shoxy!
<civodul>shoxy: Guix is basically a "rolling release", so we fix security issues in packages as they come and as volunteer time permits
<civodul>that's usually fast, but not always--help is welcome
<civodul>Guix has a mechanism called "grafts" that helps distribute security fixes quickly
<zimoun>about graph, useful ok. About size it is the third time it misses me.
<civodul>now you know what you've gotta do ;-)
<zimoun>yep! :-)
<zimoun>“guix pack -RR -m some-r-packages.scm“ and then unpack in an old cluster and I get *** caught segfault *** address 0x7f47120885d8, cause 'memory not mapped'. What could be wrong?
<rekado_>zimoun: while unpacking? Or when running? Run how?
<rekado_>which program is segfaulting?
<zimoun>rekado_: running. ./bin/R segfaults.
<rekado_>could you run it in gdb to see where it segfaults?
<zimoun>I am doing…
<shoxy>hey! ;)
<nckx>Hi shoxy.
<shoxy>thank you! would you use guix system for a server in production?
<rekado_>shoxy: I would and I do.
<zimoun>rekado_: /gnu/store/…-r-minimal-4.0.3/lib/R/library/grDevices/libs/ cannot open shared object file: Bad address For example
<zimoun>civodul: missed… :-)
<nckx>shoxy: I do too! I don't host high-risk hardened services (if I did I'd consider a different kernel anyway). But I've made implausibly few enemies on the Internet, as have my customers, and Guix made deploying servers almost fun.
<civodul>zimoun: heh, too bad
<vits-test>even me know env -S.
<zimoun>rekado_: hum? I guess it is because I have not done -S site-library.
<civodul>sneek: later tell cbaines congrats on the guile-sqlite bug hunt!
<sneek>Got it.
<nckx>vits-test: Then respond? ☺
<vits-test>nckx: just tried "leave comment" on issues.guix...
<nckx>I never have.
<nckx>Is it braken?
<vits-test>IDK, just pressed. Also bug is against coreutils.
<zimoun>civodul: what are the configuration where the offloading replies ‘postpone’? (#31785)
<nckx>Eh, what a weird bug report. I feel like I'm missing 7 kinds of context.
<vits-test>maybe it was a feature request "make -- work in shebang for env"
<shoxy>nckx: "few enemies" - what do you mean?
<nckx>Nobody trying to DDoS my portholes, or hack my cyber in general. So far anyway.
<shoxy>ah ok ;)
<divoplade>Hello, I'm using a local clone of guix, and when I run guix pull I get: guix pull: error: channel 'guix' lacks an introduction and cannot be authenticated
<nckx>divoplade: Does your channels.scm contain the introduction?
<civodul>zimoun: "guix offload" replies postpone when all the candidate machines are overloaded
<divoplade>nckx, it looks better. Where do I find a confirmation of the key fingerprint, BBB0 2DDF 2CEA F6A8 0D1D E643 A2A0 6DF2 A33A 54FA, for 9edb3f66fd807b096b48283debdcddccfea34bad (this ID literally ends with "bad")
<divoplade>Oh, the key is referenced in
<civodul>divoplade: it's up to the author of the fork to communicate the right "channel introduction"
<vits-test>i remember Python has something like x < y > z == a, rather than (and (< x y) (> x z) (= x a))
<vits-test>is core Guile has something like, at least for same operator?
<divoplade>civodul, I'm just mirroring the upstream repo, so I want to keep the upstream introductions :)
<divoplade>civodul, also, there's no "Channel authentication" section in
<divoplade>That's weird.
<civodul>ah, easier then :-)
<civodul>not weird: you're looking at the manual for 1.1.0, which didn't have that feature
<divoplade>Oh, right
<civodul>the /devel URL has the latest & greatest stuff
<divoplade>Also, with my local clone, I get error: Server does not allow request for unadvertised object 5e7cf66fb35780f930ad0bc5fe21ac330df4411d
<divoplade>And then
<divoplade>Failed to do a shallow fetch; retrying a full fetch...
<civodul>it's not an error, and how do you get it?
<civodul>when running "guix build something", right?
<divoplade>guix pull
<civodul>it's a message coming from Git though, not Guix, so that must be some build triggered by 'guix pull'
<civodul>oh prolly the guix-daemon build
<divoplade>But if I go to my local clone I can git show 5e7cf66fb35780f930ad0bc5fe21ac330df4411d
<civodul>yeah, this message just means that doesn't support shallow clones
<civodul>nothing to worry about :-)
<divoplade>Right, but I'm downloading at 152 Kio/s
<civodul>ah well, that's another story
<divoplade>I don't care if it's only for that time, but I'd rather it works for next guix pulls :)
<zimoun>civodul: I see. Tedious deadlock!
<divoplade>Or whatever the grammar should be for that sentence.
<divoplade>(if you know please tell me by the way)
<divoplade>So channel authentication ensures that the git hashes are signed. But, git hashes are sha-1 hashes, so the whole system is as secure as sha-1, right?
<divoplade>Or do the signatures sign guix hashes of the content of a commit?
<nckx>divoplade: GPG signs exactly what ‘git cat-file -p <commit>’ prints (try ‘git cat-file -p HEAD’ for an example). It does not sign the commit hash itself, or the diff.
<divoplade>nckx, so if I find a sha-1 collision for the tree git object, I can break the authenticated channels mechanism?
<nckx>You won't.
<divoplade>Google did a few years ago.
<blackbeard>hello guix! :)
<nckx>divoplade: Citation needed 😉
<divoplade>nckx, well, it made the news then
<nckx>There was SHAttered, which (IIRC, this is a long time ago) involved a pretty noisy PDF, not git, and git isn't even vulnerable to the entire approach.
<nckx>divoplade: I did a quick ^F ‘git’ on that page with no result.
<OriansJ>nckx: git commits with that PDF suggest differently
<nckx>Anyway, git is migrating away from sha-1 and should be ready well before it becomes a problem, but it's still nail-bitingly slow :-/
<divoplade>nckx, github seem to say it's a problem
<nckx>divoplade: Link?
<dustyweb>git-annex assistant pushed
<dustyweb>I'm so excited
<dustyweb>one of those times where you're helping someone else (Morgan's need for git-annex assistant) helps yourself (me not having git-annex assistant since switching to guix either for a few years, which is what used to auto-manage my org-mode and artwork repos
<nckx>divoplade: Or are they not made public?
<nckx>That would be... bad.
<divoplade>nckx, I don't understand
<civodul>divoplade: another link on this topic: :-)
<dustyweb>I look forward to the fun day that someone builds a git repo with a cycle in it :)
<divoplade>So since the security verification applies to each commit, it might be just as efficient to sign a guix hash of a commit, and not the sha-1 fingerprint.
<dustyweb>probably a few years out still
<nckx>divoplade: ‘github seem to say it's a problem’ but your link doesn't show that. They just respond to news of the attack by promising to monitor their site for collisions. That's (good) PR but I'm curious what they actually found in the past 3 years.
<nckx>I can't find any but my Web search game is pretty weak.
<nckx>It's weird because 3 years is a long time to prepare a successful attack, and it would be huge news.
<nckx>Almost suspicious ☺
<leoprikler>"We have not detected any SHA-1 collisions in our commit hashes yet."
<divoplade>nckx, too bad the link is dead, it would be fun maybe
<divoplade>That's a different story though.
<civodul>that sounds like a fun hack
<civodul>(not one i'd like to see in Guix tho :-))
<divoplade>We're better off, because inputs are hashed with guix hash
<divoplade>I don't know in fact.
<divoplade>The manual reads "The guix hash command computes the SHA256 hash of a file."
<leoprikler>I think Guix hash is more or less the same hashing Nix uses.
<divoplade>It should be
<leoprikler>you could do the same using a computed origin
<nckx><‘different stories’> Well yes, but SHAttered (‘the 2017 Google sha-1 collision’) doesn't apply to git because mitigated that... in 2017. Just because someone claims to have broken ‘SHA-1’ doesn't mean git is broken. Yet!
<zimoun>it could interesting to know if SWH see collision with SHA-1
<nckx>Nah, but I'd take that bet.
<zimoun>BTW, this sha-1 collision is not a viable attack. Too expensive *and* requires a lot of binary noisy blobs.
<nckx>divoplade: <link is dead> Shame, but last I checked Nix still used that hack. It's glorious.
<nckx>zimoun: We should implement a server-side hook that rejects non-GNU-format commit messages. Must contain foo: Bar. * foo/bar.scm: Blah! Chosen-prefix that, fiends.
<nckx>Two birds & what not.
<zimoun>nckx: it is already implemented. The hook name is reviewer. ;-)
<divoplade>zimoun, you can create a collision with any of the hashes, so commits, trees, sub-trees or blobs
<nckx>‘Hello here is my patch please ignore the 2-megabyte PDF commit message thank you’.
<civodul>zimoun: i think it's a bug that their lookup-commit RPC takes a SHA1 and returns a single element
<divoplade>Also if you accept a similar hack than the nix chromium thing, maybe it's for "legitimate" purposes or it's for a future collision
<divoplade>Let me add this blob, it's to check whether there's an update. Later: oh, woops, my bad, this is the correct blob.
<divoplade>And then you have a commit that you can attack, so all future commits too
<nckx>divoplade: It's by definition for a future collision. The object you want to fake has te be deliberately engineered to be ‘vulnerable’ (this is what Nix did). Another reason that impersonating a legitimate git commit isn't as trivial as that.
<nckx>divoplade: A good reason not to accept blobs.
<divoplade>I agree. Don't ever allow the nix chromium supposed hack.
<zimoun>civodul: ’their’ refers to SWH, right?
<civodul>zimoun: yes
<nckx>divoplade: Don't worry. I admire it, in a way, but that is not going to happen in Guix unless about 27 people get hit by one very suspicious-looking bus.
<jlicht>Now that you mention it, an unlucky CO-leak at the previous Guix-days would have been problematic for Guix :O
<OriansJ>I vote zero binary blobs in guix
<zimoun>civodul: yes, I agree about the ‘bug’. :-)
<divoplade>What would be really cool would be to fit the malicious blob on the (sha256 (base32 "...")) fields of the packages
<civodul>jlicht: true! though "fortunately" a bunch of key people were missing :-)
<jlicht>designated maintainers/committers :-)
<OriansJ>and the crazy paranoid bootstrapping people
<nckx>A tautology.
<nckx>(A good one.)
<divoplade>Still, if you were to guix hash -rx the commits, you wouldn't be vulnerable to anything.
<divoplade>Well, anything sha-1 related !
<nckx>A bit behind the topic, but I feel like I should note that Nix no longer uses the ultrahack <>
<nckx>divoplade: Until someone cracks base32.
<nckx>If they collide that, then we're really in trouble.
<divoplade>I'm almost sure it is provably non breakable ^^
<civodul>nckx: "passthru.updateScript"
<nckx>civodul: Does it still use a hash collision though?
<nckx>(If you just mean ‘it's still ugly’, well, all Nix code looks a bit ugly to me now, Python doubly so, so no comment.)
<civodul>no no, i'm just commenting on the change and the Nix tricks to get things done
<civodul>passthru.updateScript looks kinda inelegant to me but it surely gets the job done
<nckx>That's a better word. And it gets them all the packages.
<zimoun>nckx, I am not sure that the base matters much in cracking hash.
<civodul>all the packages?
<nckx>Enough to win over Guix users.
<zimoun>Is staging merged? If not, is it planned before branching?
<civodul>zimoun: i don't think we'll merge it in time for 1.2
<bavier[m]1>all the packages!
*civodul goes afk for a bit
<Bumblehorse>I want to package an emacs theme from github, but they have no license there. Do I need to inquire about one or just leave the license section of the package definition blank?
<Bumblehorse>It's already on melpa but there also is no license info there
<nckx>Bumblehorse: We need a licence grant from upstream. Ideally (very, very much so) as a file in the source tree.
<nckx>*file or header.
<Bumblehorse>Ok, I'll try and ask them about licensing it
<nckx>What's the theme?
<Bumblehorse>A high contrast zenburn (hc-zenburn)
<leoprikler>;; This program is free software; you can redistribute it and/or modify
<leoprikler>;; it under the terms of the GNU General Public License as published by
<leoprikler>;; the Free Software Foundation, either version 3 of the License, or
<leoprikler>;; (at your option) any later version.
<Bumblehorse>leoprikler: Geez I'm retarded I didn't even think to look at the elisp file. Sorry for wasting your time.
<leoprikler>Note, that this only applies to the elisp file, not to the python code adjacent to it.
<nckx>Projects don't have to include a copy of the licence text (COPYING, LICENSE, etc.) although it's a good idea. This is better than the opposite (no licence header, just a GPL3 COPYING file), since that's more ambiguous (is it GPL3? 3+? Can you assume it applies?) etc.
<mfg>has anyone tried to install emacs-pdf-tools when running on a foreign distro? For me it always segfaults, when i try to pdf-tools-install :|
<mfg>on guix system it works without a problem...
<vits-test>mfg: with same file?
<mfg>what do you mean by that? emacs crashes while pdf-tools-install is invoked, so on the foreign distro it doesn't even get installed :D
<mfg>the same just works on guix system and opens any file
<mfg>Or did i miss something?
<vits-test>mfg: ok, pdf-tools-install isn't a 'view-that-file, i got it now.
<zimoun>mfg: emacs-pdf-tools works for me.
<mfg>vits-test: yes, sry :)
<mfg>zimoun: are you on a foreign distro?
<zimoun>yes, Debian stable
<mfg>ok i know what's wrong, it needs font-gnu-freefont
<mfg>now it works
<mfg>should this be added to the inputs>
<divoplade>Does it work with another font package?
<divoplade>If it works with many (or any) font packages, it will be difficult to say which one should be the input
<zimoun>mfg, no because people use different fonts, I guess. I do not have font-gnu-freefont but font-dejavu.
<zimoun>divoplade: I guess it works for other font package
<mfg>hm, okay. So i had noto adobe source code pro and dejavu installed, when it crashed. That's interesting :D
<zimoun>well, I think it depends on the configuration, I guess
<mfg>yeah, it seems like that :/
<zimoun>civodul: bad day about NEWS. I could have a curfew this evening. Otherwise tomorrow, I work remotely, so I should not be bothered. If you do not have a curfew this evening… :-)
<apteryx>civodul: nice patch for glib! As Leo said, I think adding a monitor on /run/current-system is a also desirable.
<apteryx>I should reply on the ticket :-)
<Bumblehorse>The manual says that patches should contain only one set of related changes. It gives the example of adding multiple packages in one patch as an example of what not do to. But one patch that adds 3 emacs themes should be OK right?
<nckx>‘Related’ here is hard to define unambiguously, but it's not 3 packages with similar names or even roles. They're 3 separate packages, so 3 separate patches.
<nckx>Changing ‘GuixSD’ to ‘Guix System’ everywhere in one single commit would have been a related change, for example, because the alternative is noise. Same for renaming a variable: you need to do it all at once or things break. But when in doubt, separate.
<lfam>I'm struggling to build a package that uses some SDL2 libraries. I know that sdl-union exists to make this easier, but I'm still not succeeding.
<lfam>This is the package:
<Bumblehorse>nckx: Thank you for the clarification!
<lfam>It fails like this:
<lfam>Basically, it looks like something is reading the symlinks in the sdl-union and erroneously following them, "breaking out" of the union
<lfam>Is this a common failure case? How can I work around it?
<nckx>Silly question: does it have to be a union?
<lfam>I figure, or else we'd hit the very same bug
*lfam tries it
<nckx>("sdl2" ,sdl2) ("sdl2-ttf" ,sdl2-ttf) (...) can sometimes work.
<nckx>lfam: I don't understand the last remark.
<lfam>The point of sdl-union is that SDL libraries expect to be located in the same directories, and fail otherwise
<nckx>Yes, I think I do understand by now.
<lfam>By including the SDL libraries as separate packages, we guarantee that will happen ;)
<lfam>It does fail the same way when doing that
<nckx>So it's basically like packages that use different Qt modules, then look for all of them in the qtbase prefix.
<nckx>Got it.
<lfam>Maybe I need to build the union without symlinks. Or maybe there is some "special" code in these build scripts that is resolving the symlinks
<lfam>The Makefile is hand-written and very simple:
<lfam>I wonder if I need to edit the value LIBS
<lfam>The value of LIBS
<nckx>I don't think there's a general fix for this, and I do think the build system is being too ‘clever’ and needs some ‘help’.
<lfam>Well, (guix build union) is explicitly a union of symlinks, so there is no option to copy the files instead, IIUC
<nckx>lfam: (string-append "CXXFLAGS=-I" (assoc-ref inputs "sdl-union") "/include/SDL2 "))
<lfam>Thanks nckx
<lfam>I was thinking I'd have to do something like that
<nckx>(Weird trailing space because ripped out of a hacky substitute* call)
<nckx>ld: AircraftList.o:(.eh_frame+0x127): undefined reference to `__gxx_personality_v0'
<nckx>Hereifixedityoucanhaveitbacklfam *runs away*
<lfam>I guess I'll have to go back to walking outside and looking up
<nckx>That's with LIBS+=-L<sdl-union>/lib, too. Hmm.
<nckx>Those are no SDL symbols either.
<dannym>nckx: Did you use "g++" to compile it? Or "gcc" ?
<dannym>nckx: Usually it means that it was not compiled with a C++ compiler, but C
<nckx>Of course, cc-for-target isn't magic.
<nckx>(Is there a g++ equivalent?)
<dannym>Not yet, I think
<dannym>Copy&paste cc-for-target and adjust :)
<leoprikler>I don't know much about sdl, but isn't sdl-union rather a sdl1 kind of thing?
<nckx>I had g++ ‘hard-coded’ then my reptile brain took over because it complained about not finding ‘cc’ (sic).
<nckx>leoprikler: Both AFAIK.
<nckx>Needed, maybe not, used, a lot.
<nckx>dannym: Of course it links fine now (no -L needed either), thanks.
<dannym>nckx: you're welcome
<leoprikler>Ahh, okay, perhaps I got things wrong because guile-sdl2 isn't broken in that department ;)
<nckx>There's no install target (weird Makefile comment implying otherwise) and the README says you need to do some downloading at this point.
<nckx>Are OpenVPN private keys harmful to the owner if made public?
<civodul>apteryx: i'm testing the patch by strac'ing gnome-shell :-), and it has some effect!
<civodul>but i should test it in a full-blown VM and actually run "guix install"
*nckx falling asleep, good night Guix. Good luck lfam.
<mroh>gn8 nckx!
<jonsger>civodul: we have a critical bug in gnome?
<civodul>jonsger: critical is a strong word:
<civodul>certainly an annoyance tho
<rekado_>another Gnome bug:
<civodul>rekado_: ah yes! someone complained about GI_TYPELIB_PATH being set recently
<civodul>was it dannym?
<civodul>anyway, would be really nice to fix it
<apteryx>civodul: if you have a git-format'd patch to try, I'm happy to do so after my day. Could you include /run/current-system in the mix?
<dannym>civodul: Yep, it was me :)
<dannym>civodul: Gnome is really keeping sharp recently...
<apteryx>I figured out why our emails crossed yesterday; the merge for the two issues didn't succeed due to different importance level (I just noticed about the debbugs error today).
<dannym>civodul: Gnome is really keeping me sharp recently...
<civodul>apteryx: yeah i was prepraring a status update but i'm still waiting for "guix system vm-image" to complete
<civodul>it's been running for ages, uh
*civodul tries "disk-image -t qcow2" instead
<civodul>should be equivalent, right?
<civodul>hmm "disk-image -t qcow2" fails with (string-append "tmp-root" #f) in the build log of partition.img.drv
<civodul>i remember seeing someone mention that
<apteryx>did you graft glib?
<civodul>i did!
<civodul>i've just posted the patch
<apteryx>OK! 41298 is another duplicate of this.
<apteryx>The bounty is getting nice.
<vagrantc>had hoped to have pinebook pro working in guix by release, but ... still a lot of upstream kernel work left
<vagrantc>pinebook is working pretty nicely, though :)
<civodul>vagrantc: nice!
<civodul>apteryx: we can squash 3 bugs for the price of 1, woohoo!
<raingloom_>is `replace-store-references` not used anywhere? i can't find any calls to it, which seems impossible...
<raingloom_>also, i wanna modify it a bit to use a mapping function instead of a hash map. (because then it could be used to remove references in go and chicken build systems, and probably others)
***raingloom_ is now known as raingloom
<mbakke>raingloom_: perhaps 'remove-store-references' is better suited for your use case? 'replace-store-references' is mainly useful for grafting.