IRC channel logs
2023-10-05.log
back to list of logs
<podiki>hrm...not getting libxpm 3.5.17 from any of the mirrors.... <graywolf>"The one rated HIGH is probably the worst curl security flaw in a long time." <podiki>graywolf: we don't have any specific package maintainers, but thanks for noticing this. you could submit a bug report or email the security email list; probably we will do a quick graft update just as for the current ones <nckhexen>podiki: If it's ABI-compatible you're good to push. <nckhexen>What's with all the CVEs this ~month? It's supposed to be silly-spooky, not actually spooky. <nckhexen>podiki: Only other thing I can think of re: libXpm is to check that you changed the file extension, but you probably thought of that yourself. <podiki>nckhexen: i don't see a bz2 on x.org for 3.5.17 <podiki>abidiff for libx11 was clean, again as an amateur just doing abidiff on the .so <mekeor>nckhexen: with "project preference", you mean that this patch forces the guix conventions on all emacs users (who use guix)? personally, i think the .dir-locals.el of the guix repository should suffice for this. <nckhexen>So you think the current behaviour isn't broken? <mekeor>nckhexen: i don't know, tbh. but we don't want to fix all upstream bugs. where do we draw the line? personally, i believe, patches should fix problems that arise from packaging the software for guix; not for fixing general problems with the software package itself. <nckhexen>mekeor: Personally that's fine (I too, have preferences) but I don't think you'll find consensus for that to be made a Guix-wide limitation/policy. <podiki>nckhexen: i guess we find out who's been playing by the rules for linking with libxpm.... <nckhexen>I think the odds of this being an issue are tiny, and on the other side there's a CVE. Although I didn't check the severity, I think that justifies a test-and-push-and-fix-if-needed approach here. <nckhexen>Plus I think this bump merely puts us on par with most distroes that don't rebuild the world because a README changed. <nckhexen>(Is ‘-fixed’ the new thing? I preferred ‘/fixed’.) <nckhexen>(Because grafts are the shameful unauthorised slashfic of functional package management.) <podiki>nckhexen: the recent libx11 was libx11-fixed but I don't have a preference <podiki>i tested that it builds the new libxpm successfully, maybe let me try building something that depends on it too <nckhexen>I don't think build-testing suffices here. <graywolf>fwiw the glibc fix by Liliana Marie Prikler has /fixed <podiki>i see lots of grafts....random package builds and runs <nckhexen>Plus / puts it squarely outside of the (boring) package namespace, which is nice. <podiki>what's a favorite test? (i tried rofi) <podiki>emacs works too; i think anything through mesa, and gtk would be affected? <nckhexen>ACTION just ran a local guix gc --referrers $(guix build libxpm) <nckhexen>Then double-checked that it actually refers to the .so. <nckhexen>These ‘new’ ld.so.caches are a nice reference. <podiki>xterm works (as well as it does with my fancy prompt and needed fonts) <podiki>graywolf: i don't see the glibc fix, is it live or patch somewhere? <podiki>graywolf: thanks; looks like mumi frontend isn't in sync <mirai>apteryx: nice! thanks for the heads-up <graywolf>Hm, but why it isn't in Recent Activity section? <graywolf>I did not even searched, I just assumed it would not be there since last in "recent" is Oct 1 :/ <graywolf>ACTION bumbs the "get fancy font with emoticons" up in the todo list... <podiki>taking a quick look at curl, seems we are out of date by a major version number (if it matters here). maybe the cve won't affect us?? :) otherwise maybe we should take the week to see if we can/should update curl first <graywolf>One of those CVEs is over 8000 days old iirc, so let's hope it is the LOW one? :) <graywolf>Update would likely be good, no idea how much work it involves though; I assume if not much, it would be done already... <Guest10>what packagers usually do when package makes use of file modification time? <Guest10>i guess there is no way to set file modification time in /gnu/store? <arst>Hey everyone! I've been using Linux for several years now, but this is the first time I've used anything like Guix. Guix requires an internet connection to install, which is a problem because I need the nongnu package "rtl8821ce-linux-module" to get that. I've tried doing that using this article here: https://willschenk.com/howto/2019/installing_guix_on_nuc/, but it doesn't work. I created a <arst>guix image with wsl and booted it, but wasn't able to get wifi even though I put the needed package in "config.scm". Any ideas? <arst>Also, I don't really know lisp, so it could be a problem with my code, but I copied everything from the article and the Guix Manual, and was able to build the image just fine so idk. <graywolf>arst: You can also create an install image from that channel that shall not be named (discussing it here is offtopic) <graywolf>Oh, when I look at the release page for 1.4.0 on that unnamed channel, there even is an install iso <graywolf>So try searching the internets to find it. That is probably as much as I can say without breaking any rules. I guess? <arst>Oh sweet! Downloading it now. Sorry for unintentionally mentioning the "bad" stuff, but I can't really do anything without it. <graywolf>ACTION thinks this rule should be relaxed, running Guix on a real production hardware is nice, and especially in notebook sector it is pretty hard to do with just Guix proper... <Kolev>Isn't linking to that channel againdt the rules? <Kolev>Tethering wifi from phone works nicely <Kolev>Guest10: no proprietary software <Guest10>and since it's off topic i direct prople to where its not off topic <Kolev>I'm gonna stay out of this word game. <graywolf>Well, GNU's are pretty clear here afaik. But yeah, it does not really matter so let's just drop this. <lucypoo>hey there, does anyone present have a working pipewire setup? <arst>Okay I installed it but it looks like it didn't install the driver that was on the USB >:(. Now I have guix installed with no internet. <arst>Is there a way to pull the package from the bootable device? <arst>Wait, is there a guix command that puts a package onto a flash drive to install on a different device? <lucypoo>arst there is a method of sending packages between guix-s, lemme check <podiki>probably no changes on these, but just in case :) <lucypoo>so the package and it~s dependency-s can be exported to stdout with `guix archive --export -r <package>` and imported from stdin with `guix archive --import` <lucypoo>anyone here got working bluetooth without using a full de? <lucypoo>added ( service bluetooth-service-type ( bluetooth-configuration ( auto-enable? #true))) but still get an error about a .service file not being present and connection-s fail on blueman <arst>lucypoo Ok, I did guix archive --recursive --export realtek-firmware > realtek-wifi.pkg <arst>Then on the other computer I did guix archive --import --authorize < realtek-wifi.pkg <arst>Oh I also generated the keys before exporting. <arst>It's like "ice-9/boot-9.scm:1685:16: In procedure raise-exception:" <arst>"string contains #\nul character" <ddan>But yeah the backtrace occurs in the "ice-9/boot-9.scm" <podiki>lucypoo: i use bluetooth without full DE, let me see...I have bluetooth-service-type and blueman (dbus rules) and probably needed a relogin or restart to get it going <Kolev>Can I use `guix home` in place of `guix install`? <ddan>I can't import a guix package after exporting it using archive; I always get the same error on my machine. <ulfvonbelow>it seems like if one has an offload machine, and a local build hook is waiting on that offload machine's load to come down, and then on the offload machine a bunch of other builds are started that are a superset of the ones being offloaded to it, the local build hook will wait until the load comes back down before noticing that its jobs are already done. <Kolev>I did guix home reconfigure but new packages are not in PATH. <Zambyte>Kolev: Did you start a new shell after reconfiguring? <ddan>guix archive --export hello > hello.nar <ddan>guix archive --import --authorize < hello.nar <ddan>This produces an error in wsl Debian. <ddan>"string contains #\null character" <ddan>Followed by endless pages of garble. <ddan>Is there a way to debug this? <ddan>Can somebody reproduce this? <Zambyte>ddan FWIW I reproduced the issue on Guix proper <ddan>Ok I'll submit a bug report when I get around to it. Goodnight. <apteryx>cool, I removed the propagated gcc-toolchain from our phoronix-test-suite package <Kolev>Do I have to log out and log back in every time I do `guix home reconfigure`? <adanska>kolev: i dont think so? whats not working for you? <Kolev>adanska, installing new apps. <adanska>are they not showing up in your de's app launcher? <adanska>and are you running guix system or a foreign distro? <Kolev>adanska, apps don't show in launcher until I log in again. <adanska>whats the output of `echo $XDG_DATA_DIRS`? <adanska>Kolev, are you using any gnome extensions? <lilyp>Kolev, add pinentry-program /path/to/your/profile/bin/pinentry-gnome3 to gpg-agent.conf <adanska>alternately you can use the gpg agent home service which works seamlessly for me <adanska>you just have to specify pinentry-gnome3 as the pinentry program in the config record <efraim>I started to put my gparted.scm config in gnu/system/examples but when I took out some of my size optimizations it ballooned to 2.2 GB :/ <efraim>I had it down to about 850MB at fosdem but I wanted to take out a bunch of the custom minimized packages <efraim>looks like I'll be playing with it for a while to cut it down <efraim>I don't think I'll hit the 512MB of the official gparted image but I'd like to get it down to CD size <civodul>efraim: speaking of which, i noticed that system installation tests started failing a while back due to ENOSPC <efraim>I didn't see you apply the /var/guix/temproots patch before reconfiguring the build nodes <efraim>I might try parallel to run 'mount -t tmpfs none /var/guix/temproots' for now <civodul>i definitely didn’t apply a patch related to temproots <efraim>I tried to send it to bug-guix but I think I sent it to the wrong place <efraim>also I was thinking we should probably just add it as a default filesystem <civodul>did you write down somewhere what you diagnosed? <civodul>were there many files in there on the build nodes? <attila_lendvai>rekado, regarding pip trying to download while runnin the test suite of a package, and the use of a _custom-backend to avoid that: isn't there a simpler way to tell pip where the dependencies are? some python env variables? <lilyp>There is a simpler way: Don't call pip from check, dummy <efraim>civodul: I'll write it up in an email and send it to guix-sysadmin and then we can figure out where a good spot to document it should be <lilyp>but I suppose that's not how python works <attila_lendvai>a related issue is that the is_process_started_by_superserver call in python-daemon returns False in the build daemon. i suspect that this is true for some reason: is_socket_file(sys.__stdin__). could it be the case? it's trying to detect whether it was started by the "internet superserver". <rekado>civodul: uhm, what’s the problem with kreuzberg? <rekado>I could visit the data centre next week <civodul>rekado: it’s what i wrote on guix-sysadmin a while back, namely that i cannot login and that its Guix export key is not authorized (no longer) <civodul>the situation is fishy because i get an account expiration message when attempting to log in <civodul>something Guix System doesn’t support <rekado>okay, I’ll check when I’m there next week <rekado>I’m connected to kreuzberg right now <civodul>rekado: can you reenable my account somehow? <rekado>civodul: I’ll reset your password <civodul>with all this we have no excuse to leave a huge backlog :-) <cbaines>civodul, there's no shortage of patches that pass the QA checks at least <cbaines>I'd also like to get people to try out the QA review feature and get some feedback about how it works <cbaines>So let me know if you're interested? <cbaines>(this is most applicable to people without commit access) <euouae>cbaines: I'm also interested, what do you mean? <euouae>if you're interested in my interest <cbaines>so if you review an issue, you can use that form to mark it as being reviewed and looking like it's ready to merge <euouae>For whom is that feature? I'm not a maintainer <cbaines>euouae, anyone who wants to review patches, I think the only requirement is time <euouae>you can't review your own patches though right? this is a silly question <euouae>I might try to review some peoples patches! <cbaines>there's nothing technical preventing people from reviewing there own patches, but yes, this is meant for reviewing patches you're not involved in <euouae>do you need an account? should I have one? <cbaines>euouae, you don't, marking an issue as reviewed and looking good is done via email <euouae>It looks like there's a web interface only? <cbaines>that's the main feature being offered here, once you've done the hard work of checking the changes over, QA helps you send the email to mark the patch as being ready to merge <cbaines>euouae, try clicking on the "Prepare review" link, it'll take you to a page to send the email <euouae>isn't my name necessary for the review? where is it? <cbaines>your name/handle and email address will appear because of the email <cbaines>this is very similar to just emailing XXXXX@debbugs.gnu.org saying this patch looks good to me, except that QA prompts you to email control@debbugs.gnu.org as well and tag the patch as reviewed-looks-good <euouae>cool cbaines! I will give it a try later today <cbaines>euouae, great, and your questions are great, this is why I want people to try using this feature, so that it can be improved based on how people get on <euouae>IMHO cbaines the "Prepare review" button could be "View review" or "View review before submission." <euouae>I honestly thought it was going to do a non-reversible action like actually submitting my review <euouae>but perhaps that's just PTSD from airport wifi trick-opting me into marketing spam <cbaines>yeah, "View review before submission" sounds good <euouae>or even "View before submission" <Guest10>Hi, does anyone know how Icecat handles updates with its prebuilt addons? <lilyp>prebuilt addons should be updated together with icecat – it's the same source, no? <Guest10>well, the way Icecat works is: it copy extensions in profile <Guest10>it does so only if the addon timestamp has changed <Guest10>but it never changes since there is no timestamp in /gnu/store <lilyp>if you haven't used icecat in a long time it recommends to start from a clean profile <lilyp>other than that I assume it does nothing? <Guest10>oh, otherwise addons are not updated? <lilyp>I'm not an icecat user, so take this with a grain of salt <Guest10>i wonder what browser people here use <Lumine>Icecat, firefox for javascript heavy sites <Lumine>That is, when I need all the components to work <lilyp>speaking of which, we're really lacking in the webrtc department <Guest10>does epiphany have extensions, like adblocks? <lilyp>it has some built-in ad blocking, but nothing fancy like ublock <lilyp>Epiphany 43 an up will have extensions, but aren't in Guix yet – you can help by contributing to the gnome-team :) <Guest10>but, does ublock-origin work with an upstream Epiphany? <efraim>I'd like to propose adjusting the manual to say to *specifically* use the guix system installer for recovering a borked grub <efraim>I went through the steps with a debian installer and it installed the debian installer's grub instead :/ <apteryx>wow, building my profile is a grafting party <efraim>we should probably have an ungrafting branch <efraim>I think itoh, it looks like it's only about 10 ATM. It definately feels like a lot more <efraim>perhaps something about the recursiveness of it <apteryx>they are low in the graph I guess, to heavily linked libraries (x11) so it seems most things end up grafted <apteryx>looking perhaps moving to nomad at some point, it was fun playing with it <apteryx>there aren't a zillion choices when it comes to full featured web engines ^^' <Guest10>do you use Icecat's prebuilt addons? <Guest10>do you know if they happen to upgrade? <apteryx>they are upgraded with the browser I think <apteryx>but you can probably upgrade them manually as well, never tried <Guest10>well, that's not what I think, but i can be wrong <lilyp>ungrafting branch would be welcome <Guest10>and funnily enough: when you upgrade manually (by going to gnuzilla.gnu.org/mozzarella), it installs the xpi, which comes from addons.mozilla.org (it's a link), and then the so-installed addon upgrades directly through addons.mozilla.org <Guest10>so gnuzilla.gnu.org/mozzarella is just a fake store <euouae>cbaines: is there a way to find patches that have not been reviewed? <euouae>how many reviews are generally needed? <euouae>I also don't understand, what is the difference between <qa.guix.gnu.org> and <issues.guix.gnu.org>? <euouae>the latter does not have a review button <apteryx>do we accept the use of Texinfo generally in procedure docstrings, or just for where it's rendered (e.g. services documentation, package description, etc.) ? <apteryx>seems more conventional to use THE-VARIABLE than @var{the-variable} <cbaines>euouae, if you click through to issues.guix.gnu.org for a particular patch/issue and there's only emails from one person, then it probably hasn't been reviewed <cbaines>euouae, as for the difference between issues.guix.gnu.org and qa.guix.gnu.org, issues.guix.gnu.org is a bit of software called Mumi, and it's an interface to the Debbugs bug tracking system <cbaines>as for qa.guix.gnu.org, it's the qa-frontpage which is meant to help with QA things around Guix, including doing some automated testing of patches <podiki>on ungrafting: i was going to ungraft the libx11 and libxpm with the next mesa update, which should be real soon (technically 23.2.1 is not the first stable release but .2 will be out soon) <euouae>cbaines: great, thank you. a visual cue that an issue hasn't been reviewed would be nice, right? <podiki>for convenience I could ungraft more on that branch (mesa-updates), what would make sense? <euouae>cbaines: perhaps at the least show a visual cue if only the author messages are present <cbaines>euouae, indeed, I've been thinking that would be a good thing to highlight on the qa.guix.gnu.org list of patches, and I think it's possible to get that information from Mumi/issues.guix.gnu.org which is good <civodul>podiki: we considered it in the past but we need someone who can commit to doing that for a while <civodul>it should be a rotating position IMO <podiki>civodul: I assume that our security email list is active though right? so maybe someone from there (rotating sounds good) to help coordinate with a security team <Guest10>actually i was wrong: add-ons get updated on icecat update. when icecat version changes, it triggers an update for all bundled add-ons <podiki>speaking of CVEs: guix lint cve checker is timing out on name resolution of server for me <civodul>works for me, downloading the database ATM <civodul>probably because they’ve been there (and elsewhere) for too long <civodul>so i guess we need fine new people to replace them and a clear, fixed-term mandate <euouae>what qualifications do you need for that? <podiki>civodul: thanks, let me check network on my side (I do a lot of blocking and filtering) <civodul>euouae: i think it has to be established members of the community, committers <civodul>people with an understanding of the kind of issues we might see and the processes involved <civodul>not necessarily experts, but folks willing to learn <euouae>I'm not a committer yet -- I was not using guix much because of slow internet but I've upgraded just yesterday <civodul>(overall i think we should have more explicitly-named positions, each of which should have a fixed-term mandate) <euouae>I'm just looking for ways to be involved in the project in general so keep me in mind if there's anything <euouae>I wouldn't say I'm an expert but I know some low level stuff and I'm a mathematician by trade <civodul>one area that’s always lacking contributions is code review <euouae>yeah I'll try to do some of that today actually with that review button <podiki>a discussion on guix-devel, in light of the onslaught of CVEs this month? <podiki>non expert on the security side but i generally have time to help coordinate at the least <podiki>I think we need an expert on guix internals for guix-specific security, and then some people to coordinate/patch/review things like basic security grafts/updates <podiki>trying to update mangohud which now tries to bundle a specific vulkan-headers version <theesm>Maybe it'd be a good idea to also have folks on the OSS-Security linux-distros list (don't know how realistic that'll be as I don't know much about the list other than its purpose and that some distors are participating)? I can imagine that it could help reducing research/newstracking overhead for CVEs affecting software packaged for guix <podiki>since it is only needed for mangohud, better to use a bare origin as input? <civodul>podiki: help on coordination would be much welcome; and as you write, it’s primarily about security issues in packages <civodul>for issues in Guix itself, the team can ask core developers <civodul>would you like to start that thread? <podiki>civodul: sure. and I can volunteer for a spot as well (until around May when I'll be away for probably a month) <podiki>probably we'll want some internal discussion among maintainers and long time committers to get this rolling too <podiki>civodul: message sent, thanks for discussing here and getting us rolling <Guest10>would there be a way to force a file mtime that is not jan 1 1970 in /gnu/store files? <rekado>civodul: weird. I’ve built them all on my laptop before pushing. <Guest10>the mtime would be chosen based on the version so that it's still reproducible <Guest10>does the set-file-time guile procedure has any influence on the store files? <podiki>Guest10: I don't think so, I think everything in the store is set to dec 31 1969 <gabber>Guest10: it's necessary (for reproducibility's sake) <Guest10>well in my case i'd set it artificially so it'd still be reproducible <Guest10>for a software that checks mtime changes and triggers stuff accordingly <Guest10>i want mtime to change across versions <gabber>this sounds like a gross abuse of the POSIX specification (and is not what the store was designed for) <ted-ious>Isn't gross abuse of the posix specification how linux does all its fun things? :) <Guest10>well the store was not designed to work with some softwares that check mtime <- the other way to see things <Guest10>(ted-ious haha believe me it's not fun for me anymore) <Guest10>a workaround would be to copy the file *at package install time* somewhere else, and set mtime at that point <Guest10>are there packages that can run scheme procedures at install time? <Kolev>Posted gpg-agent issue to help-guix. <Guest10>gabber: actually i could set mtime corresponding to the time at which the version was released, which is not a posix abuse <gabber>Guest10: i sense that your intention is not that easily weldable with the guix sense of how things work. e.g. installing in guix means "adding something to some profile's PATH". that being said: pretty much everything is possible due to Guix's hackability <Guest10>well i guess that's the difference between "pretty much everything" and "everything" <ieure>Hold up, the argument that setting the mtime to... the time the file was modified is "a gross abuse of the POSIX specification?" But that setting it to 0 isn't? <ieure>Or is "version" here some kind of monotonic number, like version 1 = mtime 1, version 2 = mtime 2? I agree that's a gross abuse. <gabber>ieure: of course it is -- but a necessary one in this case <ieure>Why is it necessary? It's a content-addressible store, right? Since the mtime is metadata, how does that affect reproducability? <Guest10>if the version was produced on jan 10 2024, the mtime would be jan 10 2024 <gabber>IIRC in the nix monadic store example the timestamps were factors that needed to be dealt with to ensure reproducibility. systems were bit-by-bit the same - except for the timestamps. so they were set to UTC 0 to ensure reproducibility <ieure>Sure, it's valid, but it's not *correct*. <ieure>mtime of 0 is valid but not correct. <gabber>Guest10: WDYM "version was produced on"? <gabber>the source code? the package definition? a specific build for a specific target? <gabber>a specific build with a specific toolchain <ieure>Guest10, I'm on your side here, it's bizarre to me that the mtime is 0, because that's not when the file was modified. Neither I nor my computer existed at that time, it's impossible, a lie. <Guest10>the date, say, Linus Torvalds announces that Linux release, say, 10.0 is out. <Guest10>oh i understand ieure, you're saying the the Gross abuse is whatever Guix is doing <gabber>we all agree. we know and are aware of that fact (: <gabber>i wonder why you seem to be unwilling to recognize the necessity of that <ieure>Well, because it hasn't been explained? <ieure>For the record, I also think setting it to some notion of "release time" makes no sense. <gabber>ieure: i have tried to explain it in these comments <ieure>gabber, You said it's "necessary" and something about them being factors in the nix monadic store. But not why either of those are the case. <ieure>I accept that they may be necessary, I don't understand *why* they're necessary. <ieure>And it seems facially ludicrous. <Guest10>it probably makes things easier, but it's probably not necessary <ieure>Guest10, Touch every file in /gnu/store and see what breaks! <Guest10>touch: cannot touch 'zzyzh5s2l4h5g47b8rwvnv8r7h8l4656-libffi-3.4.4.drv': Permission denied <singpolyma>(do not do this) you would need to chattr -i first <Guest10>but it doesn't make sense to modify them manually, it needs to be done from the package procedure <old>anyone manage to add filesystem sharing with virt-manager? <ieure>Okay yeah, was wondering if they had the immutable bit set. <gabber>for bit-by-bit reproducibility. you have a checkout of a git repo and a package definition (with definitions for all the dependencies). every time you build that package you want to have exactly the same files <old>I get a: Error starting domain: operation failed: Unable to find a satisfying virtiofsd <Guest10>yes, but twice a valid mtime would work as well as twice a 0 mtime <gabber>that is true. but (currently) not the convention being used <ieure>gabber, The bits of the data are the same no matter what the mtime is. Why does the timestamp matter for reproducibility if the contents are bit-for-bit identical? That's what I'm not getting here. <gabber>ieure: we do not only do reproducible packages, but also reproducible systems. <ieure>Mmmmmm not sure I find that convincing. And if you're reproducing timestamps which are lies, is that a valuable thing to reproduce? Seems like not to me. <vagrantc>well, most of the time the other timestamps are lies too <vagrantc>most timestamps are less meaningful than people think ... and most build systems pick poor timestamps <vagrantc>i'll admit i find setting SOURCE_DATE_EPOCH=0 to be a rather heavy-handed option :) <vagrantc>in contrast, debian typically picks the last entry from the packaging changelog to set SOURCE_DATE_EPOCH to get a meaningful timestamp ... but i am not sure what meaningful timestamp guix should use for any particular derivation <gabber>the changelog of the package or the source checkout or ...? <vagrantc>the git commit that you happen to be building is too variable ... if i build with git commit N and then build with git commit N+1 .... but don't change anything in the package i am actually building ... it should not pick the timestamp from N+1 <vagrantc>because N modified package Y, and N+1 modified package Z, it should not change the results of building package Y <vagrantc>(and *which* timestamp from git do you use? :) <vagrantc>e.g. in a given commit, there may be multiple timestamps recorded in git <gabber>exactly :) so what changelog entry does debian use? <vagrantc>debian does not have one git repository for the entire distribution, so it can pick a meaningful one <vagrantc>each package has a distinct changelog entry for that particular version of the package <vagrantc>guix, for better or worse(in most cases, better, but perhaps not this one), uses a single git repository for all of the packages <Guest10>well guix could use upstream changelog <vagrantc>there are a few package definitions where a package will refuse to build with SOURCE_DATE_EPOCH=0 (or some other timestamp thingy) ... and an arbitrary timestamp needs to be picked for those ... <Guest10>instead of taking the timestamp from our package, we take it from upstream <vagrantc>Guest10: not every upstream produces a changelog with a timestamp and date <vagrantc>or some other file recording such information <Guest10>all packages don't have to use these >0 mtimes <vagrantc>numerous packages use some other timestamps <Guest10>files in /gnu/store have timestamps? <Guest10>well, i'm talking about files in /gnu/store with timestamps != 0 <vagrantc>git grep SOURCE_DATE_EPOCH gnu/packages ... numerous packages for one reason or another need to set SOURCE_DATE_EPOCH to something else ... as well as a few other s... e.g. MAN_DATE <vagrantc>Guest10: i do not think the underlying nar format even has a way to record timestamps <Guest10>yes, but they set timestamps during build, those timestamps are discarded after the build <vagrantc>what did you want the timestamps for in the first place? <Guest10>a software that look at them to know if there has been an update <podiki>i would say that is a very fragile way to find updates <Guest10>it always sees 0 timestamps so it thinks its plugin has not been updated <vagrantc>which then phones home to check for updates? <Guest10>it copies from the store to the home directory <gabber>now i get which angle you're coming from! <Guest10>so i'm fine if you are not on Icecat side, me neither <gabber>unfortunately these auto-update mechanisms are completely bogus in context of Guix <gabber>the way to go is to package the add-ons in guix, figure out (the hard way, by looking) whether/when updates happen, write patches, get them merged, `guix pull` and upgrade <Guest10>so if i put a plugin in the store, Icecat won't ever update it because it doesn't know the plugin was updated <Guest10>and Icecat will keep reading a copy of a plugin that is outdated <gabber>the store path (for the same version) will always stay the same (as will the timestamp) <gabber>icecat copies the plugin to somewhere in your homedir? <vagrantc>seems like it should only read the plugins from the store in your profile generation, rather than copying them from the store to your homedir <lilyp>why not read the file directly from the store then instead of the whole copying shenanigans? <Guest10>yes, that how icecat works, it copies stuff in ~/.mozilla/ <lilyp>though granted, wine is guilty of that too <vagrantc>at least, from the perspective of guix ... <gabber>maybe we can patch icecat to just simlink profile-paths into ~/.mozilla? <vagrantc>sounds like a task for guix home ... or to patch icecat to not do that. :) <Guest10>(for more context: my goal here is to package Icecat extensions within guix) <gabber>Guest10: would you mind filing an official Guix bug report? <vagrantc>it sounds like an incompatible behavior with the package as packaged in guix <gabber>we call them "Issues" around here ;) <gabber>Guest10: and cudos to you for your intentions to package IceCat extensions! <Guest10>i don't know if it copies the whole thing. Maybe it copies only metadata in ~/.mozilla, and in those metadata there are links to the old plugin in /gnu/store... the issue remains <podiki>how do I remove multiple flags when doing substitute-keyword-arguments? e.g. from make-flags <podiki>you can nest deletes but that is not so nice <podiki>yeah I guess filter, though that is maybe overkill to remove two strings <podiki>ah but in this case they are the only flags starting with "-D" <Guest10> Kolev: did you try to run: "gpg-connect-agent updatestartuptty /bye"? <Guest10>also, is SSH_AUTH_SOCK set to the gpg-agent sock? <Guest10>is SSH_AGENT_PID unset (or did you kill ssh-agent)? <Guest10>(and is your key in .gnupg/sshcontrol ?) <apteryx>Guest10: i'm pretty sure this was reported in the past, but I was not able to reproduce. <Guest10>apteryx: if you are talking about the upgrade of bundled addons upon Icecat upgrade, it works, yes, i checked. They don't update through web stores though <apteryx>Guest10: yes, the bundled addons, including the locales ones <Guest10>the local ones are upgraded when they are on the store, independently <vivien>apteryx, lilyp, sysconfdir is set to <prefix>/etc by default with autoconf. If we want /etc, we must set it with --sysconfdir=/etc. <apteryx>ah, and we need this so that at run time it looks there? <mirai>vivien: I've noticed this too and am unsure if I should explicitly set --sysconfdir & co. <vivien>For udev, we have the udev-service-type that makes sure a /etc/udev directory is present <vivien>In contrast, the eudev installation prefix is read-only so we can’t install more hwdb files there. <apteryx>vivien: I understand the need for --sysconfdir=/etc now; a comment in the code explaining would be nice <apteryx>maybe the etc files it wants installed could go to its own $prefix/etc instead of the other place you had selected though ($prefix/lib)( <vivien>apteryx, the udev-service-type would not see them when creating /etc. <vivien>It only collects file from <package>/lib/udev/hwdb.d <vivien>(since /etc/udev/hwdb.d is not supposed to exist) <apteryx>I mean, it could collect them from <package>/etc/udev/hwdb.d, no? <apteryx>and assemble the global hierarchy under /etc/udev/hwdb.d <vivien>That’s not a standard location, only /etc and <package>/lib/udev/hwdb.d <apteryx>ah! I see. That's good to know. Perhaps include in the comment requested :-) <lechner>Hi, after a recent update Emacs 29 seems to think my home folder is ~/.guix-home/profile/bin/ . Does anyone have the same issue? <mekeor>lechner: why do you think that emacs thinks so? M-x getenv RET HOME RET? <Kolev>Guest10, ran `gpg-connect-agent updatestartuptty /bye`. Set `SSH_AUTH_SOCK` to `""`. Key in `sshcontrol`. <vivien>I’ll check that the VM "works" and then I’ll send a v8. That will have to wait, as I have to compile the webkits again. <vivien>I check it by making sure the upower-provided hwdb file is included in /etc/udev/hwdb.d, and then I check that I can bit-for-bit reproduce /etc/udev/hwdb.bin from within the VM <vivien>I’m also checking a v3 for the dbus /var/run/dbus symlink <Guest10>Kolev well, SSH_AUTH_SOCK is not supposed to be "" <Guest10>it's supposed to be $(gpgconf --list-dirs agent-ssh-socket) <Guest10>that is, sth like /run/user/1000/gnupg/S.gpg-agent.ssh <vivien>I’ll disconnect from IRC, because when I’m doing heavy compiling, the connections time out <Kolev>Guest10, that's what it was before I changed it to comply with "is variable unset?" <Guest10>the variable was SSH_AGENT_PID not SSH_AUTH_SOCK <Guest10>SSH_AUTH_SOCK should be "$(gpgconf --list-dirs agent-ssh-socket)" <Guest10>Kolev: can you show the output of gpg -K and of .gnupg/sshcontrol <Guest10>can you try avec 1D8491A90EAAF79C2C4703847BD4B05F950655F8 instead? <Kolev>Guest10, but DE84748EB625295D3DA758528B0AAA3568A35C3C is the[A]uth key. <Kolev>Guest10, DE84748EB625295D3DA758528B0AAA3568A35C3C worked on Fedora. <Kolev>Maybe I should get back on Fedora and take a break. I'm frustrated when things don't work. <avalos>Kolev: I feel you, Guix System is something you do when you have enough time and patience. <avalos>I didn't have enough of both the first time I tried it (a week ago), so I switched to Trisquel. <avalos>However, I installed Guix as a foreign package manager, and I'm happier now. <Kolev>Trix (Trisquel+Guix) is a good combo. <apteryx>it seems your problem is a GnuPG problem rather than a Guix one, but I haven't followed the discussion <Kolev>apteryx, I posted it to the guix-help mailing list. <apteryx>I don't see "enable-ssh-support" in there <apteryx>perhaps a bug in home-gpg-agent-service-type? I don't use guix home <civodul>the hooks to trigger Cuirass are in place on Savannah \o/ <apteryx>? the log cuts in the middle of the unpack phase <civodul>apteryx: apparently this one is a genuine build failure (after 4s), but i wonder why the build log didn’t make it to the server <civodul>it might well be a problem when the worker tried to send the build log to the server <apteryx>i'm amazed at the sillyness of the conflicts when attempting to merge origin/master into core-updates; what's wrong? <apteryx>(i.e., why didn't git autoresolved the "conflicts" itself? I doubt there were changes both sides...) <apteryx>like, some of the conflicts are within .po files <apteryx>I'll abort the merge and try with 'git merge --strategy-option theirs' <podiki>apteryx: what's in core-updates these days? we need to make this a better defined branch <podiki>i'll be doing a mesa update, some ungrafts, soon on a branch, we could take anything related from core-updates too <apteryx>same definition as always minus what's covered by teams <apteryx>I'm looking at applying the docbook stuff from mirai for example <podiki>I think it would be nice to have a more active description (like updates to guix itself and low level system pieces) so it doesn't become a random grab bag again <podiki>and what would you say in trying to merge it before the end of the year, before it gets too big either way? <apteryx>sure, I agree we should not leave it amass huge amount of changes like in the past between merges <apteryx>but that's not exactly at risk at the moment (it sees little activity) <podiki>so my two pronged attack plan is 1. define what goes there and 2. merge more often <podiki>maybe a set number of months before we look to merge (or see the status at least)? <mirai>podiki: the answer to 1 seems evident. whatever that induces large amounts of rebuilds that isn't covered by any team <podiki>mirai: right, but that sort of "set of everything that isn't in another set" is prone to being random and hard to wrangle after some time <podiki>i guess the answer is more teams then :-) <apteryx>developers, developers developers!!! <podiki>on my end I'll be trying to take more things into the general mesa updates branch, as I think a lot of big rebuilds can be grouped there (if you rebuild mesa/it's inputs) <mirai>or maybe just merge more often? it makes the mess “smaller” <podiki>mesa tends to put new versions out regularly so it is a sort of clock for me <podiki>yes, that was my part 2 of plan :) <podiki>or at least let's remember to look at it on a regular time frame so it doesn't get too dusty <podiki>purely selfish reasons, of course :) <apteryx>hm, when building core-updates with the merged master, I get errors like: po/doc/guix-manual.fr.po:69580: duplicate message definition... <apteryx>that's from a pristine tree; anything I could have done wrong? <apteryx>there were conflicts in the .po files... which I've resolved in favor of master <apteryx>the errors were not fatal though... prehaps it's the current state of the translations <Guest10>Kolev: yeah the problem with Guix System is that if things don't work you are kinda stuck. Whereas if you use a foreign distro you often have a backup. I use ubuntu + guix + nix now, it's pretty nice <Guest10>nix for the things that aren't yet packaged by guix <Guest10>and it's good to compare, to have an idea of the different features <Kolev>I can't handle Guix on foreign distros. Fedora deprecated nscd so now it doesn't work as well. <Guest10>the installation on foreign distros is very easy <Kolev>Guest10, the installation script does not work well on Fedora. There are SELinux issues, for one, and then the nscd issue. <Kolev>Fedora does not have nscd at all. <Guest10>i might go away from ubuntu, it's getting worse and worse <Kolev>I'm just using Guix System on a spare computer. No way I'm using it for real work. <rekado>on Fedora: export LD_LIBRARY_PATH=$(guix build sssd)/lib <rekado>re SELinux: if you really do want to use it we’d appreciate a relevant section of the audit log to tweak the policy as needed. <rekado>if there are no actionable bug reports about “SELinux issues” there’s precious little we can be expected to fix. <Guest10>it's preinstalled now, and 'sudo apt purge snap' doesn't even remove it