IRC channel logs
2026-08-10.log
back to list of logs
<noxi>After reading it through, I agree with the points raised (except 5). <noxi>... on the other hand, I think the community is also extremely adamant on this GCD. <ieure>noxi, 4 is the only point which has to do with the contents of the document at all. <ieure>noxi, And adamant or not, the GCD process allows a single veto to tank the whole process. And that is what happened. <noxi>ieure, "We are a project by people, for people". While you're right in the fact that the objections don't relate to the document themselves, this GCD is for people, and by people, and everything said there ultimately points to a failure in fostering unpopular opinions in the process (or a success? I suppose the objections were taken into account, since the GCD was withdrawn). <ieure>noxi, I don't know what point you're trying to make. <noxi>Yes, GCD008 took the fall for these objections, precisely because it was an almost-unanimous and heated subject. Yes, I would've been proud to see Guix make the GCD ruling against AI. Will this open us up to AI-related abuse? I don't think so. The current moritorium is effective, as far as I can tell. There could be an argument that the GCD should side-step the single veto, but I think this would be remarkably <ieure>noxi, I do not believe there is a moratorium at all, but the situation is very unclear and we were basically told to stop talking about it. <ieure>The result is clear, the GCD was rejected, there is no getting around it. Those who have proposed this have been unanimously shut down. <ieure>I would personally be in favor of revision the process to require a supermajority of plain yes/no votes to pass a GCD. But that is a separate effort. <ieure>The one veto rule is something I wasn't comfortable with at the time GCD001 passed. I think the last several GCDs have shown multiple weaknesses in the GCD process, which should all be addressed. <ieure>Things like centralizing discussions in one place, and tracking high-level issues which need to be resolved. gabber did request clearer definitions earlier on in the process, and that seems not to have happened. Some way to have a list of open issues with the GCD would prevent stuff like that from getting lost. <NateDoge>Right now Google is using their intel app access to give orders to hostile foreign agents to keep me distract because they are up to something. Mossod is. The guix website is in craft about how they are all up in my shit and how if i switch to suse and stop using chrome they are going to double down with the psyop stuff and targeting. <NateDoge>i just leaked about of redlight district tradecraft <NateDoge>they are using this billgates epstien stuff to talk in craft about being gay for space and the rona supreme <NateDoge>i watched mossad use youtube to do psyops on me while i was in finland <NateDoge>they just gave orders to foreign nationals while i was going through the asylum process <ieure>NateDoge, I hope you find the help you need and peace in your life. <NateDoge>you cant downplay and hide behind psychology anymore <NateDoge>you can discredit me by labelling me crazy. <NateDoge>all the google marketing has been very crafty and aggresive towards me as well as they have been doing psyops on me <NateDoge>SOMETHING IS GOING ON WITH THESE MOTHER FERS AT GOOGLE <NateDoge>origional developer is french, likely monoco influence. <apteryx>XWayland is still available, so it should be a matter of setting DISPLAY and XAUTHORITY, but I think this may need to happen early in the sessionu/ <mskiptr>hello! ever since June, reconfiguring my system breaks DNS resolution (tho stuff like mDNS still works) <mskiptr>I've been kicking this can down the road (rebooting into an older generation), but now I tried to reproduce it in a VM and it's still there <futurile>mskiptr: have a look at guix pull --news, there was a change of behaviour around network manager. I think you have to run a command (restart it?) to generate a file it requires <mskiptr>futurile: thanks! I thought I'be been looking through that carefully-enough but apparently I had missed stuff. <mskiptr>tho isn't it still a problem if a cleanly-generated VM image does not work out-of-the-box? <mskiptr>I'm generating it with =guix system image --image-type=qcow2 repro.scm=, and then running it with =guix shell qemu -- sudo qemu-system-x86_64 -m 2048 --enable-kvm --snapshot --hda /gnu/store/…-image.qcow2= <mskiptr>then, pining raw ip addresses works, but domain names do not resolve <untrusem>mskiptr: what are the contents of your /etc/resolv.conf ? <mskiptr>on a correct generation (from May), it's: <mskiptr>nameserver fe80::8615:71ff:fe8c:c300%wlp3s0 <mskiptr>and on an affected generation it's: (give me a minute to reboot) <mskiptr>Copying the old one over the new one fixes the issue, and so does =rm=ing it and restarting NetworkManager – just like the news entry suggests. <mskiptr>won't this be undone on a reboot or reconfigure tho? I thought /etc is regenerated from scratch each time… <untrusem>mskiptr: there are some issues about this on codeberg <mskiptr>so, does it affect everyone, or is that my setup just got unlucky? <untrusem>mskiptr: I use a vpn, so that's why i might be affected <mskiptr>btw, does deleting and garbage-collecting old generations also remove their provenance information? <untrusem>mskiptr: provenance information? can you elaborate a bit <untrusem>ArneBab: will try to reproduce, give me a bit <untrusem>ArneBab: damn so many locales to download, it takes time :p <untrusem>btw are you Arnebab of hyphanet/freenet fame? <mskiptr>untrusem: basically what =guix system list-generations= and =guix pull --list-generations= prints <ArneBab>untrusem: yes, doing release management and trying to stick to release management (and sometimes failing at that). <untrusem>yes it will delete the provenance info too if you delete the generations <ArneBab>untrusem: the world of FLOSS is a small world ;-) -- you’re welcome! <untrusem>ArneBab: yep I don't have sound too in icecat <untrusem>ArneBab: yeah and I also don't like how Ian stewarded the project <ArneBab>untrusem: #hyphanet or #freenet or #freenet-chat ☺ <anemofilia>I made a very small change to home-xdg-user-directories-service-type, if someone can take a time to review it: <ArneBab>untrusem: #freenet or #yphanet is both ok, more people are in #freenet. The preferred is to run FLIP locally and route your IRC over Hyphanet ☺ <untrusem>I just use xmpp for my irc needs, lets see <untrusem>I remember guix having a freenet service <PotentialUser-32>Hello. Channel guix-past gives me a warning with "not trusted when pulling. I have confirmed that the channel introduction and the pgp fingerprint are fine. What else can I do? <untrusem>PotentialUser-32: so does guix pull fail? <alexis>Hi ! guix mystery of the day: I have a personal channel failing to guix pull with recent changes in guix with the error log `(exception unbound-variable (value #f) (value "Unbound variable: ~S") (value (python-onetbb)) (value #f))`. But I don't nowhere do I use this python-onetbb and it seems to have no dependents anywhere that I can find. How do I <alexis>debug this? I've been desperately searching for the cause for at least an hour. <untrusem>alexis: is your channel available somewhere? <untrusem>alexis: is guix science being pulled okay? <alexis>untrusem: Yes a pull with just guix and guix-science succeeded <alexis>and trying with a previous commit of my channel resulted in the same issue <andreas-e>alexis: python-tbb was just deprecated in favour of python-onetbb. It is possible that I have made a mistake there. <andreas-e>Or maybe you use python-tbb in your channel? Then you should put python-onetbb instead and also change the module inclusion from (gnu packages tbb) to (gnu packages oneapi). <chipb>it tickles me that a presumptive successor to python-tbb is python-“one”tbb. c’mon, you’ve already failed! <andreas-e>They are the same thing. Just the package name was not correct. Or they changed it upstream, I do not know. <chipb>yeah, Intel was always so good at naming. sigh. <alexis>andreas-e: I've thought about that but I can't find any place in my packages that use python-tbb or tbb or uses the tbb module. This is probably through a dependency but I can't trace back where it comes from. <untrusem>it would be nice to have dependency graph for your channels <ieure>alexis, Create a channels.scm which has everything except your channel in it, with commits pinned to their HEADs at this moment. Then change geiser-guile-binary to run `guix time-machine -C channels.scm -- repl'. Then load files from your channel into the REPL until you get the error. <ieure>I suppose you could also `guix time-machine -C channels.scm -- build -L/path/to/your/channel ...' and repeat with package defs from your channel also. <untrusem>I am currently building their channel using time-machine. <untrusem>and it failed, alexis you should try what ieure said <untrusem>how hard it would be to have dependency graph for channels? <ieure>untrusem, That wouldn't help here. A "channel dependency graph" could only use the channel dependencies mechanism, but the problem isn't *directly* caused by that. And you can't create a graph of the packages across channels, because the channel containing the leaves of that tree doesn't build. <ieure>untrusem, You could time-machine back to the last working commit of the guix-arg channel and run `guix graph' in a loop, asking for the path from python-onetbb to a package defined in the channel. <ieure>untrusem, But this would only work for packages, it wouldn't help in cases where, say, a package moves from (other-channel packages foo) to (other-channel packages bar). <abbe>TIL Google contributed to Guix, courtesy: (C) Google LLC :) <alexis>ieure: does an ,import in the REPL enough? Not sure what you mean by "load files" <ieure>alexis, In Geiser, C-c C-k will load the current file into the REPL, I was thinking of using that. But using the module in your should also work. <alexis>I don't use emacs so this is not an option. But using the module function, no issues loading any of the files... <ieure>This is one of the very few channels where "everyone uses Emacs" is a pretty safe assumption. :) <PotentialUser-48>hello. i think it was mentioned before, but it seems that qutebrowser crashes on guix with a `GLOzone not found for unknown` any ideas how to fix it? i tried the `--temp-baseir --qt-args use-gl angle` options but it still crashes. <yelninei>alexis: Maybe you have cyclic module references with toplevel variables. These can be annyoing to debug <alexis>yelninei: Do you mean if two modules depend on each other? <yelninei>alexis: I tried to load your channel without guix-science and also got the onetbb error so the error might be misleading <untrusem>PotentialUser-48, which version are you using <alexis>Thanks for having a look, I'll try to investigate in this direction <PotentialUser-48>untrusem actually, this is odd...it seems like there is a 3.70, but it looks like the listing when using `guix search qutebrowser` only shows 3.6.3. weird. <untrusem>qutebrowser 3.7.0 commit was merged today I remember <untrusem>does guix proper's qutebrower does not have adblock? <andreas-e>aleix, ieure: I think the problem is somehow in Guix itself: <andreas-e>guix/ui.scm:1033:18: error: python-onetbb: unbound variable <andreas-e>The strange thing is that the CI bot has approved the pull request. I have also "guix pulled" to dbbd716, which is one commit after the deprecation. <ieure>What's the relationship between swig and python-onetbb? swig.scm doesn't reference tbb at all. <andreas-e>Exaxtly, that is the point! I wanted to look at swig, and it threw an error. This could be due to some circular module inclusion as yelninei suggested. I suppose that "guix show" needs to go through all the packages. <alexis>andreas-e: can confirm on my side everything is fine before commit cfa0e7da7a4488cfad9f4d8ea28e96de8c5f7bf5 on guix <andreas-e>But the data service managed to evaluate the latest commits. <ieure>Yeah, I'd expect channel evaluation to fail. <yelninei>andreas-e: python-ttb (is a macro that) references onetbb from a different module, if there is any path from oneapi to tbb guile will break trying to evaluate. <andreas-e>yelninei: Ah, I thought we needed something like define-deprecated/public-alias only when pointing to a package from a different module with the same name. <andreas-e>So are you saying we should use this macro here? <andreas-e>But why does it sometimes break and sometimes not? I could do a "guix pull". It breaks for "guix show swig", but it works for "./pre-inst-env guix show swig" or "guix package -A swig". <yelninei>I am not really familiar with the deprecation macros but doing cross module deprecations are tricky <andreas-e>I could try things out, but it is annoying if I cannot locally trigger the error with "./pre-inst-env"; then I also cannot know whether is is corrected. <andreas-e>Well, but I could pull to the problematic commit. So far the only command that does not work for me is "guix show swig" (whereas "guix show gmp" also works). <andreas-e>Actually nothing depends on either of these two packages. Both are just defined, and that it is. <ieure>andreas-e, Definitely points to a module cycle. <andreas-e>I added the onetbb module as an import to tbb, so that I could reference the replacement. So a cycle is quite possible. <andreas-e>So I suppose it should be possible to drop this module inclusion, and to then write "(define-deprecated-package (@ (gnu packages oneapi) python-tbb python-onetbb))" ? <andreas-e>I will try with "guix pull --url=$PWD", but that could take some time... <yelninei>but it still needs to evaluate the oneapi module for that to get the new binding which needs to evalutae ttb ... <PotentialUser-65>uh. it seems like even after updating to 3.7.0, qutebrowser still crashes. same GLOzone error too. hmm... <eikcaz>If I clean up the structure of a function as I add functionality, is it important that the structure cleanup be on a different commit than the added functionality? <eikcaz>cleanup is like 23 lines turned into 36 lines, so more than a couple line cleanup. <eikcaz>sorry, that's 36 lines turned into 23 <untrusem>PotentialUser-65: can you share the full error <untrusem>and you should search and then create a issue on codberg <untrusem>PotentialUser-65: you are using wayland right? <untrusem>interesting, I hahe 3.6.3 it opens fine for me <untrusem>can you try with `qutebrowser --temp-basedir --qt-arg use-gl=angle` <andreas-e>Ah, I can reproduce the problem with "guix show python-onetbb". That has a certain logic. <untrusem>andreas-e: works normally for me, maybe because I am behind the commit <untrusem>PotentialUser-65: sorry i am out of ideas <PotentialUser-65>untrusem thats ok. thanks for the help though. ill stay if anyone else can think of something. <untrusem>you can try with "guix shell libglvnd python-pygobject" just for luck <PotentialUser-65>yeah. ill have to do it later, but ill be sure to use the paste i sent you. <untrusem>its obviously something related to egl, display or something <untrusem>i have seen my fair share of these but not this one in particular <andreas-e>I just did a "guix shell qutebrowser", then started "qutebrowser" in it, and a browser window appears... <untrusem>its something to do with their environment <PotentialUser-65>hmm...i never had this issue before on other distros...and ill try xfce4. still have it installed. <untrusem>PotentialUser-65: you can take this to #nonguix as well <andreas-e>Yelninei: You were right, the problem still occurs. I will probably just drop the variable altogether - it is not referenced anywhere, it is quite likely that almost nobody actually uses it. <andreas-e>alexis: The problem should be solved, sorry for the annoyance! <alexis>andreas-e: no worries, thanks for the very quick fix! <ArneBab>I finally used it today and it’s really neat (and it would be cool to have something like that in ice-9 so it works without installing anything extra).