IRC channel logs
2023-09-07.log
back to list of logs
<Guest69>rekado: #+title misses a : at the end like this #+title: <civodul>it’s quite comparable to dockerd/the docker CLI <luke-jr>is there any way I can setup guix to run a script in the build dir after unpacking, but prior to running anything further, without affecting the output hashes? <tylerm>Does anyone know how to append a new phase to a inherited package without delete the inherited packages phases? <the_tubular>Yeah, releases seems pretty consistent then 1.3 happened :p <lechner>Hi, why would guile in a pure development environment not have access to (ice-9 readline) please? <efraim>tylerm: I would suggest a search in the guix repo using `git grep phases\ phases` <efraim>lechner: looks like guile-readline isn't an input for guix <bumble>I hope there will be a 1.5 release t-shirt and artwork <ulfvonbelow>how much storage do you reckon that a full-source distribution of guix would take? That is, a guix checkout, and the source of every package it could ever try building, including the hex0 bootstrap binary <luke-jr>ulfvonbelow: well, I'm not going continuously, but I just started on it today <luke-jr>I'm also doing it *fully* from source... no seed binaries <ulfvonbelow>I don't know how you can get much more "fully from source" than the full-source bootstrap rooted in that 357-byte program, but best of luck <luke-jr>I did try that first, but couldn't get anywhere <luke-jr>maybe it just lacks documentation on how to use it, idk <ulfvonbelow>Is it possible to run a (small-scale) software heritage archive locally? That sounds kind of like what I'm after <lilyp>at the very least you can run your own cuirass which will be queried before the actual SWH <lilyp>as for cloning SWH, I think you'd have to ask them on how to do that <lilyp>(interestingly there is #swh, but it appears quite empty) <ulfvonbelow>I know there have been times in the past where I used 'guix download' to download something and put it in the store, and then when an origin with the same hash was needed it re-downloaded it, presumably because the name used was different. <andreas-e>The configure flags look suspicious. There is nothing one could install into /gnu/store/lib or /etc. Although this is not precisely what the error message complains about. <impulse2000>Its because we cant modify other packages, once they are installed. i was just wondering if there was a way i could have the evolution-data-server pick up on the libraries. maybe a symlink? <andreas-e>What do you mean by "pick up on the libraries"? Adding packages as an input is usually enough so that newly compiled binaries can link with their libraries. <impulse2000>how evolution-ews works and the dataserver is that the dataserver needs the path to the evolution-ews package libraries in its /gnu/store/rsrqi4bbvc0c6ps8jzzs8n13gbsha999-evolution-data-server-3.46.4/lib/evolution-data-server/addressbook-backends/ folder. <impulse2000>So i was just thinking i need to modify the script to copy the files within its own namespace. instead of trying to overwrite the evolution-data-server. <andreas-e>Okay I see. Somehow you try to write to the folder belonging to a different package. This is indeed not possible. <impulse2000>Yea, so i am trying to make it only write the libraries to its namespace. i am using the nix package as a guide: <andreas-e>There is the "patches" field in the Nix package. The problem seems to be that the two packages depend on each other, which creates an impossible cycle. <andreas-e>Maybe you can simply add the patch to your recipe. There is also the following: <andreas-e>Unrelatedly: There is no need to add cmake to native-inputs, it is pulled in by the cmake build system. <andreas-e>So the package builds if you use only this for #:configure-flags : (list "-DFORCE_INSTALL_PREFIX=ON") <efraim>Fought off an invitation to hang with Debian folx during fosdem <efraim>Subverting the debianites to try guix <efraim>And got a joking invitation to run for DPL <andreas-e>efraim: What needs debugging in texlive? Risc64? The monolithic or the modular one? <andreas-e>DPL with the election platform of dropping Debian for Guix. <efraim>andreas-e: the monolithic one. Its too big to copy with 'guix copy' and 'guix archive' failed after it came up corrupted. I'm repairing it for the second time now <efraim>So less about monolithic texlive and more about copying large packages <andreas-e>efraim: Could it be a problem about signed and unsigned 32 bit ints? It should be less than 4GB, but it is bigger than 2GB. <rekado>ngz: congratulations on completing all this tedious TeX work! I would love to read a blog post about the process and your workflow. <jpoiret>roptat, pukkamustard: I've been looking at the coq patches (sorry for taking my sweet time). If we're dropping the coq-core coq-stdlib modularity, then we can also drop the env variables and the custom patch on coq I think. <jpoiret>Also, I've been packaging coq-lsp, and for that I need to update some jane street ppx packages. Is there a policy of updating all jane street packages at the same time? I'm extremely unfamiliar with ocaml and its ecosystem <Rovanion>pinoaffe: In 65 the comments "There has been no new release tag since july 2022" should probably be ammended with a timestamp of when you checked. <civodul>the texlive issue is on RISC-V, right? <efraim>using guix-copy to copy from riscv to x86_64 <civodul>i should say i haven’t been paying much attention to Guix mailing lists lately <civodul>ACTION seconds rekado for a blog post by ngz on getting all this TeX Live packages <efraim>I have to wonder about the number of .pdf files in the monolithic texlive source <efraim>I'll probably regret it but I think I'll take a look at it <Rovanion>On my Ubuntu machine there is 3.1GiB docs and 2,8GiB texlive in /usr/share. Just a hint :D <efraim>source was 3.7GB, unpacked to 7.3GB <efraim>big enough to have an ls-R file in the root directory <efraim>the doc subfolder in the root directory is 3.5GB <efraim>256MB of pdfs, 86MB of zips, and some more of .tgz and the like <efraim>another 2.6GB of fonts in multiple different formats <efraim>removing the docs folder and all the tarballs brought the source tarball from 3.7GB to 1.2GB <ngz>rekado: Thanks! Alas, the work is not complete yet. All the TeX Live packages are in, but I'd like to modularize `texlive-bin' further. <efraim>the log files store the compilation date ?! <nckx>civodul: Are there restrictions on importing (gnu build …) modules into host ones, like there are in the other direction? <nckx>Put differently: (why) should I hesitate to move (gnu compression) to (gnu build compression)? <nckx>There's a lot of hard-coded gzip I'd like to rip out. <jpoiret>nckx: imo i don't think there should be <jpoiret>is it because you want to use it from the build side? <nckx>I'd particularly like to use it in (gnu build linux-modules). <nckx>It's genuinely clever that we parse the ELF modules, but it currently mandates either gzip or no compression. <jpoiret>well apart from getting rid of those gexps it should be fine imo <jpoiret>huh, but (gnu compression) is really minuscule, what do you need in there? <nckx>I'm not sure how to answer that without sounding flippant. Everything. It's exactly what we need to enable transparent compression in many situations. <nckx>I mean having the entire module. <nckx>OK, there's another patch adding call-with-compressed-input-file, but still. <jpoiret>I don't think it's doable to do it on the build side, or you'd be pulling in all the compressors since you can't decide ahead of time <nckx>That's not something we can do much about, though. <nckx>I could make a smaller subset (currently, ‘compressors that Linux supports’), but I think it would cut out only lzip. <nckx>Maybe if I'd written ‘transparent decompression’ above it would have been clearer. While we can control our output, we often can't (reasonable) control our input. <jpoiret>well in that case I don't see why not, although maybe you'd need to refactor a bit just to have more control about how the inputs get in <nckx>ACTION nods. I'm currently unsure about how that will turn out. Thanks. <civodul>nckx: importing (gnu build …) into host modules is technically OK, but it needs some thought, notably so we don’t end up pulling loads of modules that’ll never be used <nckx>Segue: is there a sane way to graph that graph? <nckx>If say strace I will scream softly on the inside. <civodul>i won’t suggest “strace”, although that is always a good suggestion :-) <civodul>maybe you could hack it to allow for ‘guix graph -t module -e '(@ (gnu compression) %compressors)’ <nckx>jpoiret: Could you ELI5 what the problem is with those gexps? I'm quite ignorant about this stuff. My expectation is that it would pull all compressor packages into only those builders that import (gnu build compression). Is that correct? Naive? <nckx>Also, I'm looking at (gnu build chromium-extension). Should I be wary of its example? <jpoiret>it shouldn't be too bad to add support in guix graph to graph modules directly not just packages <jpoiret>nckx: i'd say it's naive. Basically the rule of thumb is that build-side modules should not use g-exps, because g-exps is an abstraction that's only available in the host Guix <jpoiret>in the build side, you just have bare Guile <jpoiret>g-exp are for staging code, but the code that runs in the builder is *already* the staged code <hwpplayer1>Does GNU Guix have a category like mentors like Debian ? <jpoiret>in the builder you should rather only reference the executables themselves, and ensure that if some builder code calls them, that the compressors should be available in the environment <jpoiret>that's why I was advocating for a bit of a rewrite, where you'd provide the functions in (gnu build compression) with the list of compressors it may use (with their paths), and also add some g-exps in (gnu compression) that wrap around that by providing something like #~(do-something-with-compressors #$(default-set-of-compressors)) and the <jpoiret>possibility to tweak them depending on what you want <jpoiret>that's a bit more involved than just moving stuff around though :p <jpoiret>hwpplayer1: there is a mentor team, if that's what you're asking <nckx>OK, that expanded version makes more sense to me. The ‘split rewrite’ point didn't make it through earlier. <nckx>Now I also understand your ‘what do you need?’ question. The answer clearly isn't ‘everything, duh’, but closer ‘to everything but the gexps I guess’, I guess. :) <nckx>s/‘to /to ‘/ — sorry, tired. <nckx>Still curious if chromium-extension is a good, bad, or simply irrelevant example. <civodul>hwpplayer1: you can see them in the etc/teams.scm.in file in the repo <civodul>the idea is that you can email guix-mentors@gnu.org for guidance <civodul>it never really came to fruition, but if you’re interested, you can contact us <lechner>hwpplayer1 / hi, debian also has a mentors IRC channel. it is kind of like this one here <lechner>Hi, will our emacs-no-x-toolkit (as opposed to emacs-no-x) work with EXWM? <nckx>I really want to say it should (the toolkit refers to only to how widgets are rendered inside windows, after all), but also computers. <lechner>nckx / i have to rebuild due to #63508, which would take several hours locally <nckx>lechner: Couldn't you test an upstream (substitutable) version first? <nckx>guix-mentors@ isn't a mailing list, it's just an alias that expands to a (literal) list of e-mail addresses. <lechner>hwpplayer1 / please feel free to pastebin, and post here <lechner>how may i trick guix into accepting my custom version of eudev (which supports MAC-based interface names that do not rely on BIOS enumeration)? <nckx>lechner: udev-configuration has a ‘udev’ field, but your use of ‘trick’ makes me nervous. Are you doing… shenanigans? <nckx>So modifying the running udev binary/package isn't enough? <lechner>after reconfiguring the SAS cards in my server, the equipment refused to start properly. i think one issue was that opensmtp uses the interface name in its config. the issue was that the BIOS had assigned another interface number (eno2 or so). upon reflection, i found that the use of BIOS-enumerated interfaces names is inconsistent with the declarative configuration we celebrate in Guix. To my surprise, we do not support MAC-based <nckx>This feature has value regardless, but wouldn't OpenSMTPd listening on an address rather than an if name be even more robust™? <lechner>sure, but at that point it became a philosophical issue <nckx>I don't see it that way, but also fine, because it doesn't affect the validity of your issue. <lechner>besides, i was still hoping for a static IPv6 prefix, as well <nckx>Oh, I reparsed ‘at that point it became’ and understand what you meant by it. We agree. <nckx>At first I read it as ‘whether to use “listen ::” or “listen enospc1” is an irrelevant matter of taste’ but then as ‘even if that would work [and be more robust] it's a matter of principle to support this use case’. <lechner>that's not what i meant. your suggestion is very valuable, and i'm thinking about it <lechner>never looked back. postfix, exim, msmtp and nullmailer users, please reconsider! <nckx>Re: duplication: you know you can use ‘VAR = value’ and ‘$VAR’ in smtpd.conf? It has some annoying limitations, like not working in quoted strings AFAIK (no ‘pki foo cert "/etc/tls/$DOMAIN.pem"’ ☹) but is still handy. <nckx>I think I use it for all hostnames. <lechner>nckx / i might reach for a quasiquote one day <nckx>That's cheating, but of course. <nckx>I still keep all my configuration files plain and native, just in case Guix ever gets bought by Microsoft and I have to switch. <nckx>So ‘V6 = :: … listen $V6’ is nice. <lechner>switch to what? there is nothing else <lechner>debian is more or less owned by google. nix nearly accept a sponsorship from anduril <rekado>speaking of postfix: the wip-postfix branch still hasn’t been merged. <rekado>I remember rebasing it every year <lechner>that's somewhat funny, although not really <nckx>rekado: What's blocking it? <nckx>Waiting for a second postfix user, I guess. <andreas-e>rekado: If it works for you, maybe you could just merge it? <andreas-e>A 4 years trial period sounds like a safe choice. <rekado>andreas-e: I’m not using it. I just wanted to help getting it merged. <rekado>I’ll rebase it again and hit the 1 year snooze button. <andreas-e>So it is waiting for the first user? Then indeed it becomes trickier... <lechner>guix has no stable branch, let's merge it! <rekado>just reread the discussion; something about setuid <rekado>it did compile when I had rebased it <rekado>I always compile after rebase, because I don’t trust myself <apteryx>mirai: we have time; you can send ot upstream first then we can apply a v3 :-) <lechner>does wip-postfix still drop HAS_DEV_URANDOM? it probably should use it instead of /dev/random, since it's likely to run on equipment without a lot of user events <janneke>i don't have a (pressing) need for running mailman and exim is working great, so... <tricon>lechner: you have me curious re: OpenSMTPd as someone that used to run Postfix (w/ Dovecot as MDA). <mirai>apteryx: right, its just that the last enblend release was years ago <mirai>though the repo seems to be getting activity I don't expect the situation to change anytime soon (there's also that their README says that autotools is the “standard” build-system and cmake is experimental yet cmake is what's getting the most attention) <mirai>I'm guessing they're planning to switch to cmake sometime in the future <mirai>nckx: re listening on an ip, there's one class of addresses you would be leaving out: the scoped/link-local ipv6 ones <peterpolidoro>I am trying to package a plugin for freecad, however freecad searches the package path for plugins, not the profile path. How do other programs with plugins handle this problem? <peterpolidoro>a search path on the plugin package or do I need to modify the freecad package? <podiki>peterpolidoro: perhaps needing to configure/do something to freecad so it searches there, sometimes packages follow an env variable <podiki>freecad would get a search-paths yes <podiki>welcome! you can search for some commits that added it for other packages (off the top of my head is a simple one I did a while ago, rofi, look for rofi or rofi-calc) <podiki>wone: failure of ansel i believe is because the custom phases of darktable now need to be modified (name change); doing that it builds, i'll update my definition and should just submit it here finally <apteryx>mirai: doesn't matter the amount of activity, what is important is to get the issue out there and add a reference to it :-) <apteryx>lilyp: is there anything I can do to help make Emacs 29 happen in Guix? <podiki>i'll submit a patch here Real Soon Now(tm) <martin2020>Guest69, I added the virtlog service, but still nothing seems to work for getting virt-manager to work <martin2020>I am curious, what have other people with guix system installed done to get virt-manager working? <jpoiret>abhiseck: i don't think we have it packaged <vivien>I’m holding my breath for Guix QA for my patch :) I mean that as a metaphor, if I did that for real I would turn green way before QA <cbaines>vivien, I have a suspicion that QA might be getting stuck somewhere, but unfortunately that's hard to confirm at the moment <cbaines>I can at least see that it has been checking some recent issues, and I've added some more metrics now so I can better track the progress <vivien>My patch was picked up 8 hours ago, and the revision started 6 hours ago <vivien>I was about to paste dates and then I remembered about the round earth and all that <cbaines>that sounds pretty good actually, data.qa.guix.gnu.org is quite short on resources and could do with some improvements on the software side as well to speed things up <bacs>just installed my first guix box and that was relatively painless :-) <lechner>tricon / i'd be happy to help you to possibly convert to OpenSMTPd, if you like. the configurations are super short and super clean, plus i have not seen any unexpected behavior---with minimal mental overhead for a year and a half, on six pieces of equipment <tricon>lechner: that's quite kind of you. i may take you up on that and pick your brain. i actually get to start from scratch since hackers wiped my VPS providers systems (tiny host overseas). going to self host now with some mini-PCs and multiple locations. <lechner>congrats! i just got rid of my final linode on Aug 31 <tricon>lechner: very nice! my current approach is to build these mini PC servers for friends to host and to offer a trade in the form of setting up offsite backups for them. do you have redundancy with your new setup? <lechner>which kind are you thinking of, please? <tricon>lechner: seems simpler than the Postfix setup i had. <tricon>ACTION owes nckx years of gratitude for the many pointers they've shared in this channel. to another one: \m/ <lechner>tricon / also, please write to felix.lechner@lease-up.com, if needed. i tune in and out on IRC <vivien>cbaines, the log is still progressing, so I don’t think QA is having trouble. <minima>hi, i have a file where i want to replace a string and save the result to the store; should i look at `computed-file'? <vivien>Ooops, I forgot to CC my patch to the team members <nckx>minima: Probably. I wouldn't recommend abusing plain-file. <distopico>vivien: that happens to me every time, I always forget some step <vivien>Should I reply to the patch with the team members in CC? Should I re-send the whole patch? <nckx>Not to say what's ‘proper’ but I'd do the former. <nckx>Make sure to clearly include the bug # somewhere for convenience. <andreas-e>cbaines: The queue seems to be getting longer nevertheless. I have been watching my hdf4 patch, and there seem to be more and more grey circles above it. <andreas-e>cbaines: I wonder if it is not the evaluation of the commits that is the bottleneck, not package building. <roptat>ACTION is trying to do some translation work :) <nckx>check-system is broken through ganeti. <lilyp>apteryx: I've got hako's emacs-compile-directory and Maxim's subdirs.el on my local branch <lilyp>once I push those it's testing and fixing remaining packages <apteryx>nckx: I saw that, we need to fix the build of ganeti <apteryx>vivien: cc team members is automatic if you use 'git send-email' <apteryx>(which also CCs people participating in the conversation) <vivien>I’m using magit to do the format-patch <lechner>apteryx / thanks for that same hint a few days ago! <apteryx>you can pass those to 'mumi send-email' <vivien>I use evolution to actually send the patches, it’s just that I have to remember adding the correct CC when creating the patches. Too bad I forgot :( <mirai>vivien: I hope you're not pasting the patches as text then <mirai>too often the MUA mangles everything (inserts invisible characters, sends as HTML, hardwraps the lines, etc.) <vivien>mirai, it wouldn’t work, because the email header would be in the body (subject, to, from, base commit etc) <mirai>I've went through the extra mile in the past to rescue someone <mirai>'s patch that was sent that way <mirai>the sheer amount of time it took to figure out and repair the thing is too high to be worth doing it regularly <vivien>Next time I’ll paste a screenshot in a Wor − uh, LibreOffice document and send it that way :) <mirai>don't forget to compress it with lzip too <vivien>I was thinking rar would be more cursed <ngz>sneek later tell andreas-e: I have an idea. At the moment it is not possible for `guix shell' to extend a TEXMF tree without providing a full tree. For example `guix shell texlive-foo -- pdflatex file.tex' will not add `texlive-foo' to the available packages. However `guix shell texlive-bin texlive-foo -- pdflatex file.tex' will. My suggestion is to add `texlive-libkpathsea' as a propagated input for all TeX Live packages. <mirai>to make it utterly useless with zcat/zless (unless you got zutils installed) <mirai>name it as online-pharmacy-cialis.tar.rar and see how far it will go <cage>Hi! I am trying to write a package definition but the upstream source needs a lot of tuning to works, I have found some patch files from debian that should fix the issues, my question is, there is a way (an is good practice) to apply the patches during the package building and where to store them? <apteryx>cage: hi! if the patch is useful and hasn't been merged upstream yet (has it been forwarded to them?) then it makes sense to carry it <apteryx>the <origin> record can take a 'patches' field <apteryx>(patches (search-patches "name-of-patch.patch")) <apteryx>the patch should go in gnu/packages/name-of-patch.patch and be registered in the gnu/local.mk file. <vivien>gnu/packages/patches/name-of-patch.patch <apteryx>It's nice to add metadata at the top of the patch to say what it is for, where it came from, what's the upstream status, etc. <vivien>It’s also more polite to prefix your file name with the package <vivien>I don’t know if "polite" is the correct word <apteryx>lilyp: sounds good; when the branch is up let us know and I'll be happy to give it a spin <vivien>debug: Starting acquiring advisory transaction lock: load-new-guix-revision-inserts :( <vivien>I think I’ll have to go to sleep before the evaluation finishes. <lechner>Hi, anyone here using software RAID? <cage>patching as you suggested works fine! :) <cage>just i have another unexpected problem, the C preprocessor is unable to find the zlib header in "/usr/include/zlib.h" <cage>i have added zlib as dependency in the scheme form <nckx>cage: If it's looking in /usr that won't matter, since that doesn't exist. Which package is that? <nckx>Define recovery? I regularly ‘test’ losing & resilvering a drive, because it happens several times a year. The machine is basically dying but stumbles on in blissful ignorance of this fact. <vivien>cage, is your package using pkg-config? What’s its build system? <nckx>It has a reputation for being solid AFAIK. One equal to ZFS, just without the features. <lechner>will you please share the raid-device stanza in your config, when you have a moment? <nckx>I'd love to but the machine is currently unreachable. This likely due to being at my parent's house behind a crappy SOHO router, not due to mdraid 😉 <nckx>I'll poke about in git but I don't think I have it there. <lechner>what happens when you boot with a drive missing, please? <nckx>Ah, well. In my case, the drive vanishes after a few months and gets kicked out, but it ‘reappears’ on reboot so that's not something I've personally tested. <nckx>I suspect you'll tell me it fails because Guix sets suboptimal options, and I'll eagerly believe you if so. <nckx>(There are also some bad sectors in the exact same spot on all 6 drives that were somehow *created* by Linux, because they are on a swap partition boundary, just to keep things weird. I have no idea how.) <lechner>bad sectors get remapped automatically unless that's an IDE drive from 1995 <nckx>They don't get remapped to the cloud, yet. <nckx>Trust me, I've done the required double-takes & staring at S.M.A.R.T. data. It's real, at least as far as the firmware is concerned, and I'm not going to reverse engineer *that*. <nckx>As someone whose / device is called ‘/dev/sda1:/dev/sdb2’, I've had my fill of arbitrary Guix limits. <nckx>It's how bcachefs denotes multi-device file systems, and it's a ‘file’ that doesn't exist. Guix used to really not like this. I've patched out the worst, now it merely demands ‘--skip-checks’ when reconfiguring. Sorry, this is becoming irrelevant to your point. <nckx>I'd like to encourage you to submit patches for any bugs/design flaws you think are present in the assembly code, even if you're not sure about them. <nckx>lechner: There wasn't really more. I just wanted to confirm that parts of early Guix System boot are still downright unfinish, janky, and even wrong, in case you were second-guessing yourself. <nckx>‘unfinish’ was not an intentional pun but I wish it had been. <lechner>actually, i have been working on them, but it's too early to share <lechner>my angle is to give secure boot to everyone <nckx>Even to those who don't want it? Scandalous. <vagrantc>if i run "guix time-machine" ... and then run it again ... should it cache the results? it seems to always "Computing Guix derivation for ..." regardless of weather anything has changed between invocations <cage>vivien: i do not think it is using pkg-config but it uses the gnu toolchain (autoconf, automake etc...) <cage>i am a bit rusty with C :( <nckx>cage: Can you share this package? <vivien>cage, can you upload configure.ac somewhere? <cage>the package is available on sourceforge, just a second <nckx>Your Guix package would be nice to have. <cage>i am patching the sources with the files availabe here <cage>lechner: no pun intended ^^; <cage>could be useful to know that the patch changes the path of the included header that raise the error <lechner>debian switched from the captive to the system library <nckx>cage: The error is saying that file doesn't exist, because it doesn't. It exists on Debian systems but not on Guix Systems. <nckx>The patch is introducing the error. <nckx>Replace it with #include <zlib.h> or so. <nckx>"…" = literal file name, <…> = use C include search paths. <nckx>This still relies on the build system setting those sanely, but that's a next step 😛 <cage>i think am starting to removing the rust layer from my C memories :) <cage>thanks again to everyone for your help! <lechner>nckx / cage / will the <zlib.h> reference find the Guix prerequisite or the file in ../compat? <lechner>or in other words, why did the Debian folks list the absolute path? <cage>lechner: actually i do not know the answer to the latter question <lechner>it may come down to the order of the -I parameters <cage>but i remove the directories containing the bundled library after the unpack phase just to be sure that the building system will not find them <cage>but i am not sure if it works because of the "#include" problem <cage>we'll see if it is a good idea, anyway :) <lechner>it should now, otherwise we can patch your autoconf file with CHECK_LIBS or whatever is current now <cage>my plan is to patch the debian sources with their patches, then modify the include directives (for zlib and i suspect for all the other libraries the package uses like libjpeg) and generate a new patch, finally try again with building <cage>but it is a lot of work and i am a bit tired now :) <lechner>i was going to say thank you for all that hard work <lechner>those bundle removals should really be a configuration option from upstream <lechner>cage / the idea there is you patch once and submit it upstream. then you make the job easier for all distribution, and the changes become upstream's responsibility <rekado>I made some obviously required changes to wip-postfix; still missing documentation and someone to test if this all works. <cage>in principle yes but the patch is a bit of an hack because it patches the configure script, i mean the script generated by the autoconf <cage>in my opinion the correct way to make the linking with bundled libraries optional would be to rewrite the configure.ac and makefile.am files <lechner>how about zapping ./contrib and then autoreconf -fi ? <cage>lechner: would be an excellent solution! <lechner>Sergei patched libjpeg/Makefile.in (there is no (*.am). Not sure why he went for the ./configure script. <lechner>you could also cooperate with Sergei. it would make upstream acceptance much more likely <cage>lechner: i have removed all the TEA_SOURCE macro from the configure.ac in the /libjpeg directory <cage>then ran autoreconf -fiv <cage>and seems to me that the changes to the generated configure script are the same as the results from the patched sources <cage>so seems that your idea is good! <lechner>okay! i am a bit surprised. why did you remove the TEA stuff? <cage>i just blindly copied what the patch does :) <cage>i think could be not to difficult to add command line switch (like --disable-bundled-libjpeg) to configure script to skips the TEA_SOURCE macro <cage>thanks but my day is terminating here where i live, maybe tomorrow would be too :) <lechner>cage / in autoconf terms you probably want --enable-bundled-libjpeg with a default of on <cage>oh, yes, i am always a bit confused by the autotools :) <lechner>good streaks often last for a little while <cage>anyway i think this kind of modifications to the configure.ac would be a more elegant solution than patching the configure script <cage>there is still the problem with the #include directive but maybe also this could be solved someway with autotools too <cage>lechner: thank you for this discussion it was very inspiring and helpful <cage>lechner: for me it is bedtime now :) but if you want to collaborate i am very happy to do so <lechner>cage / no problem. the include thing is in zlib/zlibtclDecls.h which is not a generated file <cage>we can clone the repositore somewhere <vivien>How do I fix the "patch lacks comment and upstream status" linter warning? <nckx>No, it just checks that it has a mail (actually: any) header before the diff/---/+++ part starts. <cage>i have to go, folks, thanks again for your support! <nckx>That header can just be some text explaining why the patch exists (almost any patch shipped with Guix should have a justification for why it's not upstream). <nckx>Or it can be a proper git format-patch style ‘From …’ header. <cage>lechner: i think i am going to clone the repository on codeberg, i'll paste the URL here so, if you want, we can work on the changes together or discuss the changes <lechner>sneek / later tell cage / i'm not here often, but you can find me as @lechner on codeberg <Sleep_Walker>is it possible to configure channels in system configuration so it can be used in `operating-system`? <Guest69>Docker works but it seems that docker-compose is broken. I get "docker.errors.DockerException: Error while fetching server API version: HTTPConnection.request() got an unexpected keyword argument 'chunked'". Do you have that problem as well? <the_tubular>You should give Podman a try if you're facing issue with Docker. <the_tubular>Or you could try tcpdump and check what's in that packet that the API doesn't like