IRC channel logs
2025-02-16.log
back to list of logs
<craigbro>it also adds a surrogate identity to the circle of trust, which unlike keys is not explicitely mapped to an individual. That's a significant change to the social contract -- as least by my reading of guix manual, I have not auditing signing keyring <Gooberpatrol66>"/home/nathan/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq/etc/news.scm:40:1: error: invalid channel news entry" <craigbro>all keys in the origin/keyring branch appear to belong to individuals <civodul>ieure: it’s not possible on Codeberg AFAIK, and it’d be a security risk <civodul>Gooberpatrol66: this is fixed now; you can try ‘guix pull’ again <weary-traveler>just did a guix pull and seeing this error: $HOME/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq/etc/news.scm:40:1: error: invalid channel news entry <civodul>i don’t know why “make check-channel-news” didn’t fire <luca>So are codeberg PRs meant to make it easier for contributers? Or for maintainers? Is it significantly easier for maintainers to merge from codeberg, as opposed to git pull/rebase/push? <lfam>luca: From my point of view, it could be easier to keep track of contributions, and to understand what to pay attention to. Currently my guix-patches inbox has >7000 emails in the last 10 months, and if a patch series is accepted, it doesn't disappear from the inbox. So, it's not easy to look at it and get started <lfam>So, even just having a contribution disappear from a queue that I can work in would help me <lfam>Some people have claimed that it's worthless to try to make a change in tooling and workflow, that it won't help handle the flood of contributions. But I think that's too defeatist <craigbro>and you're handling security updates too right? <lfam>I did it for many years and then I burned out <lfam>I would do it again if my life situation changes (way more free time) or as part of a job <lfam>weary-traveler: Does the patch work for you? Do you see any outstanding problems with it? <weary-traveler>lfam: it works fine on this end. i think the entire racket ecosystem needs an overhaul, but that's outside the scope. i haven't encountered any obvious issues, but my testing has been limited. i can say with some confidence that it improves on current state <lfam>Great. Can you send a revised patch that includes a brief description of the problem and solution in the 'racket-launcher-config-dir.patch' file itself? <weary-traveler>lfam: sure. will be taking a break for supper in a few. okay if i add you to x-debugs-cc when i send it? <graywolf>I am getting %exception #<inferior-object #<&service-not-found-error service: system-log>> when trying to update my system, is that expected? <lfam>Are you using inferiors? <lfam>Just minutes ago, a change regarding system-log was pushed <graywolf>Well I guess back to syslog for me it is. <lfam>I think it's a bug in the new code <lfam>If it were me, I'd rollback and wait for a fix <graywolf>well, previous generation still works, and guix pull --roll-back as well, will try this again in few days. <lfam>One of those two recent commits touching 'services' <graywolf>Sent, but since it is almost 2 am, it is pretty bare bone. I do not really have the energy to put together things like reproducer, sorry :/ <lfam>sneek: later tell graywolf: I'm sure it will suffice <vagrantc>wow. i forgot how long make dist on guiux takes. :A) <vagrantc>lets see if it can run in parallel ... it used to require make -j1 <apteryx>sneek: later tell zimoun I think we need a blog post about the new GCD process, to dissiminate the information more widely. I know it's been a tough time for your recently (sending warm thoughts!), but when you feel like you have the energy/bandwidth, is this something that you could draft? I'd be happy to review it. <vagrantc>does recent dot no longer support PDF output? <vagrantc>Format: "pdf" not recognized. Use one of: canon cmap cmapx cmapx_ ... make[2]: *** [Makefile:7627: doc/images/bootstrap-graph.pdf] Error 1 <craigbro>I'm running a make dist from a commit a few days ago, so I can tell you when it dies, if I don't fall asleep before... <craigbro>i just started it, but I didn't update before doing do <vagrantc>maybe make dist uses graphviz-minimal, but it need full graphviz? <craigbro>no, it says graphviz in the manifest... did you guix shell pure? <craigbro>at least as of Feb 8, commit 494f72490a1e747f237d04a27502f6ef24ac8ae5 <vagrantc>guix shell --container --pure --development guix guix git imagemagick perl less <vagrantc>i do not see where the instructions for running make dist even are ... so i am just cobbling together how to set it up from my previous make dist related bug reports :) <vagrantc>I am using 1afbf48b250f667ce45de40a6c275e3e42ade67c <craigbro>I presumed it was same isntructions as building from a repo clone, so Building from Git section of manual,, with "make dist" as target <vagrantc>it requires a few additional packages apparently ... <craigbro>I'm a newb digging a rabbit hole in several directions, a warren perhaps, so put little weight in my words assumptions, heh <vagrantc>ah yeah, graphviz-minimal is used in guix's native-inputs <craigbro>oh, so in gnu/packages/package-management ... I see now. also, just reproduced the fail hehe <craigbro>seems like eps and png, maybe svg is sufficient for that documentation? <vagrantc>just needed regular graphviz instead of graphviz-minimal <vagrantc>thankfully it picked the "right" one, as i suspect i had both in the environment <vagrantc>well, without further patching, it is required to generate the bootstraph-graph.pdf <vagrantc>you would think the three other formats were sufficient... <vagrantc>so either graphviz-minimal needs to gain PDF support without pulling in the world, or guix maybe needs to drop it from their dependency graph ... or at least the dependencies for make dist need to be documented <vagrantc>well, going to take that victory and call it a day. <jakef>for the source of python packages, do we prefer pypi or a release tag from the repo? <lfam>jakef: I would use pypi unless there is a reason not to <lilyp>note: missing tests would be a reason not to <ekaitz>sneek: yeah baby the mighty ekaitz is back in town <ekaitz>hi! i'm trying to import the hackage package `text` and it explodes, but the output is undebuggable, can anyone help? <ekaitz>Syntax error: unexpected token : OR (at line 144, column 65) <ekaitz>it doesn't even say what file has that problem :( <csantosb>I have a weird issue here ... `guix lint emacs-parsebib` performs as expected <csantosb>However, `cd guix && guix shell -CPW` followed by `./pre-inst-env guix build emacs-parsebib` complains <csantosb>`guix lint emacs-parsebib`, I meant, in both cases <csantosb>The message is `guix lint: warning: while connecting to Software Heritage: host lookup failure: Servname not supported for ai_socktype` <marmar>how would I extend `home-shell-profile-configuration` in guix home? I want to add home-manager startup file to .profile, but I'm not sure how <jlicht>csantosb: do you have network access in the guix shell container? if not, makes sense that it doesn’t work no? <ekaitz>csantosb: i'm trying to make the package but there are so many dependencies, many of them outdated... <csantosb>jlicht: agghh ... the network ... thanks ! <csantosb>ekaitz: this is exactly the kind of topics I don't fully understand about packaging stuff in distributions, it may become a hell if you have to do things manually <futurile>csantosb: it will also fail if it can't find the ssl certificates - so for `guix lint` I think you either have to add them or share /etc/ssl <csantosb>futurile: trying with `guix shell -CPWN`, so far, so good <csantosb>If I understand it correctly, it probably depends on if sources are already local; if not, you need to git clone them, and then you're right, the certs are needed <futurile>Q: anyone know how to fix the 'change-id' stuff not triggering? I've created a new clone from git.savannah.. and now when I create a commit the change-id isn't being triggered <futurile>It's missing the commit hook in ~/.git, but I don't think I'm supposed to manually copy it in there - there's nothing in the docs about doing that <ekaitz>futurile: you need to setup the hooks for this, i think some of the build scripts sets them up automagically <futurile>ekaitz: yeah I'm confused about the 'automation' part - I found references in the mailing list archives to people copying the hooks in - but I definitely never did that in the past - there must be a magic step I've *not* done this time that's somehow meant it's not there. I'll try going back through all my steps heh heh <ekaitz>csantosb: no fu^W way to package gitit, it requires more recent packages than the ones we have and when i update them something explodes <ekaitz>at least it made me fix a minibug in guix <futurile>Ah found it, you have to build the main source as the Makefile installs the hooks. I'm using git worktrees so had missed that out. <apteryx>sneek: later tell civodul if you have a chance, could you please look at patch v6 4/4 of bug#55231 ? It touches (guix derivations) <mra>:O is 55231 finally cracked? just saw the emails <graywolf>civodul: Hi :) I think there is a problem with the system-log :/ #76315 <sneek>graywolf, you have 1 message! <sneek>graywolf, lfam says: I'm sure it will suffice <graywolf>(Previous generation worked, so no rush, just wanted to make sure you are aware.) <ekaitz>efraim: looking forward to the next release... what's the status of the riscv bootstrap? <orahcio>Hi, someone has a problem with virtlogd service, when I shutdown or restart my laptop the service do not stop and the system shows a message like it, "waiting to stop the service" each second <dariqq>orahcio: Is this the same problem as #76338 i reported earlier today? <graywolf>It is probable that this issue surfaced due to same changes in shepherd <graywolf>orahcio: Can you try to modify the service to depend on user-processes and see it that helps? <dariqq>virtlogd also does not depend on user-processes. It would be good to find out which services currently dont <orahcio>yes dariqq, peanuts and graywolf, is the same problem <orahcio>hahahaha graywolf, almost everything here is new for me <orahcio>graywolf: you mean, instead call the system service, I need to make a simple home service with virtlogd? <dariqq>graywolf: there were also some changes to user-processes service directly : ba9af3e151db8f0f86aeaea681a937e995b5b265 but no idea why this would suddenly surface the problem <graywolf>I am far from expert but I do not see why the linked commit would cause issues :/ But then again, I do not see why the system-log shepherd chagnes would prevent me from booting, so I will leaves ths to more qualified people to comment on :) <sneek>civodul, you have 1 message! <sneek>civodul, apteryx says: if you have a chance, could you please look at patch v6 4/4 of bug#55231 ? It touches (guix derivations) <graywolf>How do I do bind-mount using the (file-systems) field? <graywolf>civodul: 1. My system refused to boot after update to system-log ; 2. dariqq reported (and I have noticed it as well) that shutdown hangs unless shepherd service depends on 'user-processes <civodul>graywolf: do you have details about “refused to boot”? <graywolf>There is no error, it just hangs during the boot process :/ <civodul>graywolf: you’re very good at finding shepherd bugs BTW :-) <graywolf>ACTION is not sure whether to laugh or cry... <vhns>Would it be okay to submit a package for an older version of a program, later submit patches to bump its dependencies and then submit an up-to-date version of it? <vhns>As in, the dependencies available in the current repositories can only build an older version of the application. <ngz>vhns: what about first updating dependencies, and once they have hit default branch, provide the up to date package? <vhns>ngz: I could try that, but I already got the former done <ngz>vhns: I think what you suggest is ok, but it sounds suboptimal. <the_tubular>guix pull: error: Git error: unexpected http status code: 502 <noob-cannot-boot>Hiall...I have a Problem booting guix...It stays at "/dev/sda1:87 files, 109108/153290 clusters" ...then the blinking cursor... <noob-cannot-boot>i encountered it first afer 6.12.13. update. "halt" did not clearly halt the system but had to physically power off via button. Same with "reboot" command <noob-cannot-boot>did a chroot into the system and via "--alow-downgrades" "fixed" the situation ...at least so i thought... <noob-cannot-boot>but no...after another guix pull, package --upgrade and system reconfigure the same Problem <noob-cannot-boot>Can you show me a way to use previoux 6.12.12 Kernel...aaah...btw...yes i am using non-guix channel...hope this is no problem here <graywolf>noob-cannot-boot: Maybe you got hit by 76315, can you try downgrading to b99df83c591104655a6b387817d8f7bb3c50204c? <noob-cannot-boot>Actually never downgraded to specific version...is this described somewhere? <graywolf>I think you can just guix pull --commit=b99df83c591104655a6b387817d8f7bb3c50204c and reconfigure from that. <graywolf>(You should be able to boot using the previous generations in GRUB menu) <noob-cannot-boot>aaah wait...using non-guix chanel...do i have to be cautious with pulling b99df83c591104655a6b387817d8f7bb3c50204c? <noob-cannot-boot>lol....i am in the chroot that i created from last installation and when doing the "--allow-downgrades" it rolls back to b99df83c591104655a6b387817d8f7bb3c50204c from 6dd.... versionit currently uses <ieure>Is it possible to access the arguments field of a package from within a build phase? <mirai>the lambda function within any build phase has more keyword-arguments <ieure>Looks like `package-arguments' is what I need for that. <mirai>or ungexping within a phase? <ieure>Do the contents of the arguments field of the package get applied to the build phase lambdas? <mirai>I think you can inspect what kind of args are available in the build-system files <ieure>I want to add an argument to the package, then access it in a build phase. <mirai>or if you want to do the hacker/dirty way, try crafting a lambda args, (display args) (throw 'whatever-throw-expects) in a build phase and see if it shows up <noob-cannot-boot>graywolf Reverting to the commit worked. https://smalldev.tools/share-bin/Lgrhaexi But still problem when doing reboot. Does not reboot but hang. I know what happens once i turn it off it will claim at next boot that dirty bit was set but removed and then hang with message ""/dev/sda1:87 files, 109108/153290 clusters" <graywolf>That is weird. If you successfully reconfigured using the previous version, it should boot. When you are running the previous version (the one you are using to reconfigure the system), what does guix describe tell you? <vagrantc>ACTION packaged a git snapshot and of course has plenty typo commits to push... <ieure>Ah, I can't add arbitrary kwargs to arguments, the build-system complains. Too bad. <noob-cannot-boot>graywolf I have to correct myself. I had to power-off physically but my nightmare-scenario did not show. It booted passed point "/dev/sda1:87 files, 109108/153290 clusters" and shows greetd...however..it does not start sway anymore but drop to shell but i can start sway manually <ieure>noob-cannot-boot, Yes, append the version to the end, ex. linux-libre-6.11 (or whatever) <graywolf>And there also is linux-libre-lts, is you do not care about precise version and just want something little more stable <graywolf>ugh, excuse my French, (kernel linux-libre-6.1) <noob-cannot-boot>as i'm using non-guix channel for wifi issues i use the kernel from there i guess... <graywolf>yeah yeah me too, but nonguix is a thing that is not allowed to be discussed here :) <noob-cannot-boot>aaah...no prob...I did ask in the beginning...citing myself "btw...yes i am using non-guix channel...hope this is no problem here" <civodul>graywolf: it is okay to discuss it here, it’s just that support for nonguix should be on #nonguix <civodul>(in this case it wasn’t even discussed) <graywolf>Oh that is news to be (good news). I thought the rules are to keep any talks of non-free software out of official channels, to the point where I saw people using almost riddles to guide newcommers to nonguix to avoid saying the name out loud <civodul>it’s clear that it’s not the right place to promote non-free software, but there’s a difference between that and “hi i use linux from nonguix” <vagrantc>hrm. make dist produced a tarball without po/doc/po4a.cfg for some reason <podiki>i think a problem is also that often people (esp newcomers) don't know what is a guix specific question/problem and what is something actually to do with another channel <vagrantc>sure would be nice if make dist was checked more often than when people get around to working on a release :P <podiki>(and even if you aren't new, if you aren't familiar with what is in a channel it can be easy to not realize from e.g. a guix pull error of a missing symbol) <vagrantc>anyone know how to get make check (building guix) just test a single test? <vagrantc>and now, to disable assumptions about bootstrap binaries being available... <vagrantc>oooooh, which also points out SCM_LOG_DRIVER_FLAGS="--brief=no" <vagrantc>i most desperately wish there was a way to only record verbose logs for tests that fail ... the successful tests kind of become awfully noisy when you're looking through 12 failures out of mostly passed or skipped tests <vagrantc>so, pretty much doing my usual "package a random git snapshot of guix for Debian" workflow ... struggle to remember how to run "make dist" ... build it as a debian package without running tests and not typos that lintian finds ... run with tets, and disable all the tests that assume network or bootstrap binaries of one kind or another <vagrantc>A fresh batch of "This packages" this harvest, as well as a handful of others that ought to be caught by guix lint :/ <civodul>many thanks for updating the Debian package <vagrantc>makes for some esoteric poetry, at least :) <vagrantc>going to try it in debian experimental and then see how bold i will be to try and actually get it into the upcoming debian release <vagrantc>1.4.0 is getting awfully long in the tooth :) <vagrantc>looks like only 15 failures out of ~2500 tests, so that is at least not madness