<leoprikler>wait, python charges money for security updates? <nckx>leoprikler: No? Where would you get that idea? <leoprikler>oriansj's rant about "paying" was kinda misleading on that part <nckx>‘or pay another party to fix security issues in python2’. Not really. <leoprikler>I still would not trust anyone to exchange "security updates" against money. That opens the door for all kinds of weird business practises. <nckx>You expect them to give them away for free? How's that less suspicious 😛 <oriansj>leoprikler: People pay "employees" in exchange for $work. That also opens the door for ll kinds of weird business practices... <leoprikler>It significantly lowers the barrier for entry for those actually willing to audit said updates. <oriansj>also, there is nothing stopping a business from paying people for security updates and then publish them to the whole world <leoprikler>That's not what's going to happen in capitalism, though. <oriansj>leoprikler: define capitalism (if it is anything less than 80K pages long, it has never existed) <nckx>leoprikler: Are these audits free too? <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... <nckx>leoprikler: Why don't these competing teams not simply share their work? <oriansj>nckx: oh fuck no, hence why all of the people doing it now are quiting and moving to python3 <leoprikler>Fair enough, but I personally don't see the indefinite support of Python2 as a solution here. <nckx>It's not, that's the point. <oriansj>leoprikler: there are an infinite number of possible solutions: some terrible, some bad, some ok, some good and very very few amazing. <nckx>If you want that, pay a team to do it. <leoprikler>nckx: Because there'd be a monetary incentive against it and possibly contracts forcing them not to. <nckx>leoprikler: Saying ‘I by definition don't trust anyone I hire’ is weird and good luck finding ‘volunteers’ to exploit I guess (it's a valid and popular business model). <oriansj>leoprikler: there are monetary incentives to get extended support for languages (like Java 6 [shutter]) <nckx>But don't expect Python upstream to ‘volunteer’. <nckx>Then what do you mean by ‘I still would not trust anyone to exchange "security updates" against money’? <NieDzejkob>I can fix it by installing guile-next and guile3.0-{colorized,readline} but, ehh... <leoprikler>nckx, oriansj, the way I see it, there are many ways to exchange money for a (usually false) sense of security <leoprikler>in our current economy unknown exploits are also exchanged for money <oriansj>leoprikler: of course (like paying hookers to babysit one's kids) <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. <nckx>Someone is going to be writing those fixes even if they are published, and it's probably going to be a paid employee of $conservative_bank or whatever. <nckx>Then I don't understand your original objection. <nckx>leoprikler: Hire someone babysit your curves. Make sure nobody touches them. <oriansj>nckx: or hire hookers to discover the truth about the elliptic curves (like real spies do) <leoprikler>My personal opinion is, that people, who refuse to upgrade to Python 3, should suck it up and upgrade to Python 3 already. It's 2020 (current year argument). <nckx>Just cut out the middle(wo)man. <nckx>leoprikler: Suspicion that we all actually agree and some wires got seriously crossed above: confirmed. <leoprikler>I don't expect the Linux kernel version 2 to be supported indefinitely. Why would it be different for any other software? <oriansj>nckx, leoprikler: I love it when an open and honest discussion discovers shared truth. <nckx>This is the Internet. How. <nckx>Shouldn't one of you be swatting the other by now. <oriansj>like there are communties of people like trying to make the world a better place or something..... <oriansj>writing software for free and giving it away... <oriansj>such a strange strange place indeed... <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: volunteers offering binaries, always decline <leoprikler>patches in the form of source code diffs, of course <oriansj>leoprikler: or generated scheme code (looking at you guile) <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? <oriansj>leoprikler: hence the problem; one needs guile to build guile from human written sources. <oriansj>and until mes-m2 is able to be extended to be able to do that job; all scheme bootstrap roots have a risk of a trusting trust attack. <oriansj>Fortunately we have a C root of trust bootstrapped from hex0; already done and currently being ported to AArch64 and RISC-V shortly after <leoprikler>so the goal would be to have enough primitives in mes-m2 to be able to compile psyntax with out psyntax-pp? <oriansj>also have enough primitives to run MesCC and guix too but let us not get ahead of ourselves <leoprikler>i.e. is there no smaller set of syntax that can be used to compile psyntax? <oriansj>leoprikler: no one is currently working on that as far as I am aware <oriansj>One could in theory just write psyntax manually <oriansj>leoprikler: well if written by a human; 100% <oriansj>leoprikler: it just would require a shitload of work <leoprikler>It would seem like a truck factor of 100% as well. <oriansj>well written code, is easy to follow and understand. <oriansj>hence the rule I follow in stage0, any code which isn't obvious and easy to understand is a bug <oriansj>That way if my wife muderders me; or I get hit by a plane, it is easy for anyone else to pick up and carry it the rest of the way. <oriansj>They need only get on #bootstrappable to inform everyone and start pushing their work <leoprikler>Don't get me wrong, but I personally don't find hex ; assembly too readable. Though I admit, there might be more people who understand that than I am talking to. <leoprikler>I know it's a technical necessity, but so is psyntax-pp currently. <NieDzejkob>leoprikler: truck factor? That's usually not expressed in percentages O_o <oriansj>leoprikler: what would make it easier to understand? <NieDzejkob>leoprikler: do you find assembly itself readable? <leoprikler>Well, that's my problem, readability for me stops somewhere in C. <oriansj>leoprikler: well we do have C code versions of those steps as well <oriansj>and we do try to map to the C code when writing in Assembly to a good degree <leoprikler>Fair enough, I haven't gone to look at them yet. <reepca>on my most recent 'guix pull' attempt I got "guix/scripts/pull.scm:613:21: error: %default-modules: unbound variable". Any idea what's up with that? <oriansj>because guile doesn't require an escape and neither does C <lfam>Guix complains that the ampersand is an illegal character when it's used in a package definition <lfam>I guess this is why there are literally no ampersands in any source URIs in Guix <lfam>In that case it does this: <lfam>guix build: error: invalid character `\' in name `dl.php?id=source\x26version=2.14.23.drv' <lfam>With \x26 it's like this: <lfam>guix build: error: invalid character `&' in name `dl.php?id=source&version=2.14.23.drv' <nckx>lfam: Try using file-name. <lfam>That explains the error message <lfam>Thanks nckx, it's working now <reepca>anyone else encountered the %default-modules error? <nckx>lfam: It was the .drv that tipped me off that this was a store file name issue, not a URL one, so another point for ‘paste your full errors folks!’. <nckx>reepca: Not this afternoon. Lemme pull again. <nckx>That is as it should be. <nckx>reepca: Do you have more output, perchance? <nckx>(nitrosun: and Guix luves you.) <reepca>there was more at the end of the earlier pull that actually changed generations (I think), I'll grab that too <nckx>Ah, fnord, it failed… because of an unfinished commit in one of my channels. Now I have to start again. <reepca>although actually it may have been the "&& guix package -u" that I put after it that produced that larger error message <reepca>it said "1 pacakge in profile" and then produced the error, so it seems likely <nckx>reepca: Here it produced (far) more intermediate ‘Building …’ messages but you might have done that previously (‘nothing to be done’). <nckx>Well, I'll tell you when slowy mcslowdisc finished pulling again. <nckx>Uh oh. I did push a translation to news today. <nckx>But ‘guix pull && guix pull --news’ worked just fine. <nckx>reepca: ‘guix pull && guix pull -news’ still work here. Does ‘guix pull --news’ display the same error for you? <reepca>guix pull --news produces the same error. <nckx>reepca: Could you export COLUMNS=999999 or so to disable truncation? <nckx>Then try to reproduce the long one. <nckx>If 7628673 is to blame I can only guess it's because of my use of different quotes, but I don't understand how that could be unreproducible. <nckx>reepca: What's your locale? <reepca>nckx: en_US.utf8 is specified in config.scm and in $LANG <nckx>So no non-utf8 weirdness. Hm. <reepca>I'm checking it with GUIX_PACKAGE_PATH unset now <Blackbeard[m]>I've not been around much recently because I become homeless :/ <reepca>I should have thought of that earlier <nckx>Blackbeard[m]: Oh, that sucks. I hope you're OK, all things considered. <reepca>it seems it was something with my local packages <reepca>(@@ (guix build-system gnu) %default-modules) is still a thing, aye? <nckx>That changed with Guile 2 → 3. <nckx>I don't know exactly how, I just know that civodul removed some uses of @@ in Guix for exactly that reason. <reepca>hm, sounds like I need to re-read that section in the current manual then <reepca>although 'guix package -s guile' doesn't seem to show 3.0 as being available? <nckx>Turns out my self-inflicted failure to pull was also due to 2→3. <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>Okay, so I think I see where the error is: in `mv -f .deps/ofxdump.Tpo .deps/ofxdump.Po <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>it's probably not a guix package issue, though it's still a bug in guix since the package is not repeatable <peanutbutterandc>str1ngs, reproducible? In this context reproducible means if I get XYZ error, everyone else in the world in guixSD or any foreign distro gets the same error, I presume? <str1ngs>I it's prefered everyone gets the same successful build :P . but you get the idea <str1ngs>in this case there is probably an issue with the upstream's package build system. <peanutbutterandc>str1ngs, I see. Haha. What about guix running in BSDs and other OSes. Is it a possibility? <str1ngs>on BSD possible, though guix does use some Linux specific container technology . maybe it could still work without those features. on other OS's it would be much harder to make work. <peanutbutterandc>str1ngs, I see. So guix could truely be a universal package manager. That is super neat! <peanutbutterandc>str1ngs, Another question: Does HURD have these linux-specific container technologies, too? I know guix's ultimate goal is to become guixsd running on hurd <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> *raghav-gururajan thinks about POSIX <htgoebel1>I wonder how I can evaluate how many dependencies are affected when changing a build-system. <smithras>maybe grep for "(build-system xzy-build-system" in the gnu/packages folder? <smithras>I meant to type xyz but you get the idea <htgoebel1>smithras: ACK, but this does not give the dependencies. <htgoebel1>Concrete example: The qt-build-system is used by 90 package, 47 of which are libraries, used by other libraries, used by applications. <htgoebel1>Will this hit the 300 boundary for submitting to master ? Or even the 1200 boundary for submitting to staging? <smithras>ahh okay. Hmm I don't know of an easy way to find that info <bricewge>It's a post on how to inspect package in Guile if you haven't read it. <sneek>civodul, you have 2 messages. <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? <pkill9>what benefits does guile 3.0 have? <gnutec>They only need update emacs-guix. <htgoebel1>bricewge: Thanks for this pointer. This will actually challenge my guile-skills :-) <gnutec>guile 3.0 is not going to installed as a guile comand, but your don't need download to install. I will use "guix environment" with --ad-hoc. <pkill9>it would be good to be able to ignore failing builds when upgrading a profile <pkill9>so it just wouldn't upgrade those <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? <link2xt>should I have also filled a bugreport first? <jackhill>civodul: yes, I see it in guix processes (first time running that command ☺) <jackhill>I decided to do that, and indeed it worked. Thanks! Time to read about guix processes in the manual :) <jackhill>Oh, and I guess I left out that I may have made it worse by restarting the previously daemon to try to get the locks to clear… <civodul>link2xt: ah no, that's fine, your message clearly explains what this fixes <apteryx_>find-files at the Geiser REPL really brings it down to its knees. Wondering if emacs-so-long would help here. ***apteryx_ is now known as apteryx
<bricewge>Nevermind, I forgot logind got extracted from systemd. loginctl suspend works <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 <platoxia>NieDzejkob: If you think guix system reconfigure should work from a chroot I will try it again. <NieDzejkob>mount all the /proc's and /boot's and you should be fine <numerobis>Hi #guix! :) Is anyone here using biber on guix system? I'm having an issue with building the package at the moment, and I was wondering whether there was a workaround. <jasos_biba>Hi guys. Are there any plans to package Plasma? Or it's more like somebody's personal intention? <jackhill>huh, gdm doesn't seem to start for me with the latest guix <jackhill>I booted into the previous generation, and it works, but the weird thing is that, even with the working generation, I don't see gdm listed in `sudo herd status` <oriansj>jasos_biba: everything in Guix is somebody's personal intension. and boy do people around here have plans.. <efraim>desktop environments take more to package, it's not just the packages, it also needs a system service <jonsger>ice-9/boot-9.scm:1695:9: In procedure scm_lreadr: /etc/config/config.scm:52:22: illegal character in escape sequence: #\/ <jonsger>hmpf, guix doesn't like the nginx config for nextcloud in my config.scm :( <leoprikler>jackhill: could it be xorg-server or something along those lines instead? <NieDzejkob>Alternatively: congratulations, you have just graduated beyond the single-file-config. New abilities: [Git Repo Wizard] <jonsger>NieDzejkob: I still have only one file + ssh keys <jasos_biba>oriansj I get it. The reason I ask is that I see some repos with work being done but not completely. So I though that it's better to stick with something that is not being packaged yet. <oriansj>jasos_biba: alot of people here are open to cooperation; for example you could help them package any missing dependencies, thus speeding up the incorporation. <jackhill>leoprikler: indeed, it is xorg-server. I must have missed that when I was looking for gdm and display. I see that names come from gdm-shepherd-service in the code. Thanks! <jackhill>now just to figure out the apparent problem in newer guix <sirgazil>I just did guix pull and sudo system reconfigure, and GDM never started after waiting for about 10 minutes. This may be the same problem gnutec was having yesterday... <sirgazil>Ah, just read the logs, and jackhill has the same problem :) <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. <jackhill>I guess I could report something, but I don't have any useful debugging information yet. <leoprikler>You could start with `guix describe` of your current and previous guix generation. <leoprikler>If you want to locate a single commit, you can try check out the guix source, then git bisect in that commit range <leoprikler>compile guix from source, `sudo -E ./pre-inst-env guix system reconfigure /path/to/config.scm`, reboot, check, rinse and repeat <jackhill>yes, I should do that. I think I'm going to file a bug first to get something started <jackhill>sirgazil: mind if I quote you in the bug? <leoprikler>drakonis: pre-inst-env lives at the root of your local guix checkout after bootstrapping and configuring <reepca-laptop>how would one go about getting their hands on debugging symbols for the xorg-server package? <pkill9>why does the 'arguments' field of package definitions use "keywords" instead of being a record? <pkill9>it feels slightly inconsistent with the rest of the package definition, but i'm guessing it is more beneficial somehow <reepca-laptop>pkill9: different build systems can have different arguments. You'd need a different record type for each one. <reepca-laptop>and it's easy to process only the ones a given phase (of building or of lowering to a derivation+builder) is interested in by using define* with #:key and #:allow-other-keys. <pkill9>ah, does allow-other-keys prevent it from raising an error when the build system passes all those arguments to the phase? <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 <civodul>there are CRCs in the debug output that won't match <reepca-laptop>ah, that's too bad. The event I'm trying to debug takes from days to months to happen. <reepca-laptop>guess I'll reconfigure with my debug-friendly variant and wait it out <civodul>reepca-laptop: so you could still try to attach gdb to it <civodul>there's at least the symbol table, so the backtrace might give you useful hints <civodul>another option is to add a "debug" output to our xorg-server package, then you reconfigure, and in a few weeks you do a fancy debugging session <reepca-laptop>I hadn't thought of that. I guess I've been staring at obfuscated code too long... <reepca-laptop>the thought "maybe the people who built this didn't hate me" has become less natural than it should be :-/ <ngz>Hello. A test suite in a package tells me: "Tests fail with: "ModuleNotFoundError: No module named 'tests'".". Is it something I should care about, or is it upstream's fault? <ngz>Would it help to see a more complete backtrace? <reepca-laptop>;;; WARNING: loading compiled file /gnu/store/5bd6ywmfcxxa4gvpzg0pdbjwmf24cxkl-module-import-compiled/gnu/build/activation.go failed: <reepca-laptop>;;; In procedure load-thunk-from-memory: incompatible bytecode kind <civodul>reepca-laptop: how did you run "reconfigure"? <civodul>that sounds like a 3.0/2.2 .go file incompatibility <civodul>but the pulled guix should pick its own .go files <reepca-laptop>sneek: later tell civodul: ran as "sudo -E guix system reconfigure /etc/config.scm" <sirgazil>I did "sudo guix system reconfigure path/to/my-system-config.scm" <sirgazil>And it's weird because why would Guile 3 look for .go files in 2.2 paths? <sirgazil>The warnings in the screenshot above do not show paths to guile 2.2 .go files, but running "guix repl" does: <sirgazil>e.g.: ;;; WARNING: loading compiled file /run/current-system/profile/lib/guile/2.2/site-ccache/ice-9/readline.go failed: <sirgazil>But the REPL says it is running GNU Guile 3.0.0 <drakonis>a pull and rebuild does the trick it seems ***dddddd_ is now known as dddddd
***deesix_ is now known as deesix
<drakonis>sirgazil: i think my system's guile and guix is still on 2 