<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... <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. <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 <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. <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. <KE0VVT>What would be the best way to completely archive youtube-dl in both source and package forms? <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 <nckx>Heh, another regular harmless message. <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 gnu.org, if possible with a screenshot. <nckx>I'm off to bed, it's 05:08 here. Ridiculous. <vits-test>Will 'patch-shebang replace for ex. "python" with /gnu/store/... in: <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 what was max bang length, heh <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. <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>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 *civodul wonders whether they broke "guix publish" <mfg>yep the network here is too unstable :| <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? <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.’ <nckx>Blame the GPL [misconceptions] for going non-free. Nice? <mfg`>What exactly is GPL-phobia? <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 <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
<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>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>Maybe check out Nebula? 😉 <vits-test>nckx: funniest part is word "open" there and there, as if they never read about GPL. <abralek>I have never tried nebula, will give it a try <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>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: nftables place same (/etc/packagename), but those do not. <vits-test>honestly, both are /gnu/store/XXXX/etc/packagename. <nckx>* /usr/share/doc/,name-,version/examples <jlicht>that seems more like what I had in mind <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 ☺ <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>How did that nongnu get in there? gnu.org works too. <janneke>some non-gnus are more gnu than others *nckx sends a friendly ‘Get best SEO now!!’ mail and CCs all gnu.org lists. <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? <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 <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 <jlicht>vits-test: I know English is not my native language, but were there that many mistakes in my text? <vits-test>jlicht: use paste.debian.net, (define compromise ...) and more . <vits-test>there are much educated people violating my right to see simple english! no more! i'm protesting! <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). <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. ;-) <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>don't hold your breath, i don't have any solution... <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 <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>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>“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? <zimoun>rekado_: running. ./bin/R segfaults. <rekado_>could you run it in gdb to see where it segfaults? <shoxy>thank you! would you use guix system for a server in production? <zimoun>rekado_: /gnu/store/…-r-minimal-4.0.3/lib/R/library/grDevices/libs/grDevices.so: cannot open shared object file: Bad address For example <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. <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! <nckx>vits-test: Then respond? ☺ <vits-test>nckx: just tried "leave comment" on issues.guix... <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. <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 <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") <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 :) <civodul>not weird: you're looking at the manual for 1.1.0, which didn't have that feature <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>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? <civodul>it's a message coming from Git though, not Guix, so that must be some build triggered by 'guix pull' <divoplade>But if I go to my local clone I can git show 5e7cf66fb35780f930ad0bc5fe21ac330df4411d <civodul>yeah, this message just means that git.sv.gnu.org doesn't support shallow clones <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>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>divoplade: Citation needed 😉 <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 :-/ <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? <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. <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. <leoprikler>"We have not detected any SHA-1 collisions in our commit hashes yet." <civodul>(not one i'd like to see in Guix tho :-)) <divoplade>We're better off, because inputs are hashed with guix hash <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. <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. <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? <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 <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 <divoplade>Still, if you were to guix hash -rx the commits, you wouldn't be vulnerable to anything. <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 ^^ <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. <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 *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. <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 <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... <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? <mfg>ok i know what's wrong, it needs font-gnu-freefont <mfg>should this be added to the inputs> <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. <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>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 <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. <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>I wonder if I need to edit the value 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>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>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>Needed, maybe not, used, a lot. <nckx>dannym: Of course it links fine now (no -L needed either), thanks. <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. <jonsger>civodul: we have a critical bug in gnome? <civodul>rekado_: ah yes! someone complained about GI_TYPELIB_PATH being set recently <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: 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 tries "disk-image -t qcow2" instead <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>OK! 41298 is another duplicate of this. <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>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.