<leoprikler>You'll have competing software development teams develop competingly bad versions of the same product, each of which will not be willing to share with any other until all of them are bought by Google.
<oriansj>NieDzejkob: like grsecurity and the Linux kernel crap
<oriansj>leoprikler: hence, go GPL or get fucked (it is what usually happens anyway)
<nckx>leoprikler: oriansj's point was entitlement. People demanding free support or updates or audits, which is what people complaining about Python 2's demise do. Nobody's stopping you from distributing free security patches or audit reports on an EOL language though.
<oriansj>nckx: or becoming the maintainer of Python2 forever...
<leoprikler>I'd rather have a hooker babysit my kid than the NSA suggesting elliptic curves to use.
<oriansj>leoprikler: fair, but can you imagine a set of incentives that might minimize the risks?
<leoprikler>But alas, I don't have a kid and the NSA suggests curves regardless.
<nckx>leoprikler: You might've found oriansj's point misleading (I didn't) but I don't see yours at all. So people who refuse to upgrade to Python 3 shouldn't hire someone to (security-)maintain Python 2, but expect ‘someone’ to do it for free? And this person will be more reliable because they rang the bell and offer to patch you good for free Sir? That's not plausible with or without capitalism.
<leoprikler>One note on volunteers: I would trust volunteers offering patches "for free" over $hady_corp, but in this case, the volunteers have collectively decided to not do that and I'd like to respect their decision.
<oriansj>leoprikler: psyntax.pp if one wanted to be precise
<nckx>leoprikler: In reality it's either $hady_corp, $we_charge_so_much_we_really_dont_care_about_scamming_you_twice_consulting, or poor Alice from IT who gets to fix the stack overflow on Friday afternoon. That's also ‘pay for support’.
<nckx>$hady_corp (please stop doing business with them by the way) is a bit of a straw man, but sure, exists.
<oriansj>it is one of the bootstrapping pieces we need to solve (a hard one at that)
<leoprikler>Alice "why the fuck has my company not yet upgraded to Python3" from IT
<nckx>Ask Bob ‘why does my 2nd yacht only have one minibar??’ not-from-IT.
<nckx>(A business expense. Those IoT dentures don't sell themselves.)
<leoprikler>Bob's very busy working during meetings and dinners.
<leoprikler>what's the deal with psyntax-pp? Is psyntax from the source tree pre-processed with an already existing guile?
<nckx>pkill9: Understood. I thought guix pull --news printed more kinds of things than guix pull already does, but it simply prints more of the same things. Cool.
<reepca>well, I read section 6.20.9 of the manual and I still can't figure out why it doesn't work. 6.20.2 ends with "See Declarative Modules, for some limitations on the use of ‘@@’", but I don't see any limitations on it there.
<reepca>specifically, it says "To users, whether a module is declarative or not is mostly immaterial: besides normal use via ‘use-modules’, users can reference and redefine public or private bindings programmatically or interactively. The only difference is that changing a declarative definition may not change all of its uses."
<jackhill>hmmm, "waiting for locks or build slots..." has been shown for a long time. I wonder if it is making progress
<reepca>ah, I see now, it's because guix compiles with -O3 most likely and that now enables -Oseal-private-bindings, which makes such bindings disappear entirely.
<peanutbutterandc>str1ngs, Just a small info: the .asoundrc file changes from yesterday caused - on reboot - my user's sound to be disabled: no playback, no audio device detected from the settings. I got it back by renaming the file to .asoundrc.disabled and logging out and logging in again.
<peanutbutterandc>It renames .deps/ofxdump.Tpo to .deps/ofxdump.Po (twice, for some reason) and then complains it cannot stat '.deps/ofxdump.Tpo'
<peanutbutterandc>But since I see nothing in the package definition that might be causing it (`guix edit libofx`), I wonder if it is an error in the makefile. In which case, perhaps this should be reported upstream. If anyone sees this, please do test it. It's a dependancy of gnucash.
<str1ngs>peanutbutterandc try building with --cores=1
<str1ngs>peanutbutterandc the .asoundrc issue is discouraging for foreign distro. not sure how to best resolve that.
<peanutbutterandc>str1ngs, Whoa! Whoa!!! How does this work? What does --cores=1 do that resolves this issue (I know it only uses 1 core, but how!? This is curious. Thank you, BTW. It passed that phase
<str1ngs> mv: cannot stat '.deps/ofxdump.Tpo': No such file or directory` might indicate a race condition.
<peanutbutterandc>str1ngs, Also, I had this (probably stupid) question in my mind: is it (theoritically) possible to have guile run on the BSDs? And while we're on that, on whatever other obscure operating systems out there (ReactOS, Haiku-OS, etc)?
<str1ngs>peanutbutterandc: --cores=1 tell it to build single threaded it's like make -j1 . be cause it's single threaded it can't hit the race condition.
<peanutbutterandc>str1ngs, I see. So, this race condition, it must be coming from upstream, I presume. And not because of guix packaging...
<str1ngs>for things like guix build it should work on UNIX systems since as far as I can tell it is using chroot. but for things like guix container and guix environment --container. it uses Linux namespaces. which as far as I know would not work on HURD>
<sneek>civodul, rlb says: even though the (touch (future ...)) is entirely within the with-fluids form? It looked to me (naively) like the second future's thread "remembered" the altered fluid value, which I thought might be due to the pool, i.e. thread re-use. That might make sense if say threads capture the current non-thread-local-fluid values at creation and aren't influenced by subsequent changes to (say restoration of) the fluid
<sneek>civodul, rlb says: I suspect my misunderstanding is that I was thinking in terms of clj dynamic vars, where a sub-thread (often) sees the exact same "fluid" as the parent, but in guile, the current *value* of the fluid conveys, not the actual fluid?
<civodul>link2xt: the first one, "guix", is for bug reports, while the second one is for patches
<jackhill>Hi, I had an offload job fail because my laptop which initiated it suspended, and now everythime I try to build the failed package guix gets stuck after printing "waiting for locks or build slots..."
<jackhill>how can I clear it, so guix will attempt the build again
<link2xt>civodul: should patches for bug reports be sent to guix-patches or in reply to bug reports?
<civodul>link2xt: rather in reply to the bug report
<civodul>jackhill: can you check with "guix processes" what's still running?
<platoxia>his question came up after the problem I linked too in the mailing list.
<NieDzejkob>platoxia: What commands have you tried using when you did a reconfigure from the install iso? What do you mean by "I can't get it to work"? What error are you getting?
<platoxia>NieDzejkob: something about not being able to access a file system that I didn't mount before chrooting in to the partition...I didn't realize at the time I wrote the post to the mailing list that I should have just mounted it an tried again. To that point, however, I wasn't (still not) sure I could reconfigure the system that way in the first plac
<drakonis>guix pull --news doesnt list changes to services, this should probably be included
<leoprikler>The last commit that mentioned gdm was in december, though.
<leoprikler>This would include commits to the service, so something else must have changed in-between.
<jackhill>sirgazil: yes, that sounds like the same problem
<jackhill>my disk is quite slow, so I wasn't sure if it was timing related somehow (usually, I see dbus triggered services fail to start because of timeout, but then suceed the next time), but I guess not.
<pkill9>does guile 3.0 speed up compilation times when compiling guix?
<civodul>pkill9: i haven't done any real measurement but it'd be nice to do it
<reepca-laptop>hm... I tried getting xorg-server debugging symbols by simply building a variant package that adds a "debug" output but its contents end up looking like "/gnu/store/m0zvh2n1np76y588m7n5p2hs8x5p4143-my-xorg-server-1.20.7-debug/lib/debug/gnu/store/pdx94n8xvlmalxllzsa3qykd3hzm69xf-my-xorg-server-1.20.7/...", which doesn't look quite right.
<pkill9>emacs magit is so slow when handling a compiled guix repository
<civodul>reepca-laptop: it's actually all right :-)
<reepca-laptop>civodul: my main concern is that I'd rather like to get symbols that will work for the currently-stuck-in-an-infinite-loop xorg-server, which the differing hashes lead me to believe wouldn't work
<civodul>reepca-laptop: you cannot take the "debug" output of one derivation and use it for the "out" output of another derivation