[01:06] <mwhudson> waveform: "Is it possible to "grep" the archive
[01:06] <mwhudson> for any package which mentions --no-restart-after-upgrade, --no-restart-
[01:06] <mwhudson> on-upgrade, or --no-stop-on-upgrade in its d/rules" you want sarnold for that :)
[01:17] <amurray> mwhudson: you can use debian codesearch to get a rough approximation - https://codesearch.debian.net/search?q=--no-%28stop%7Crestart%29-%28on%7Cafter%29-upgrade&literal=0
[01:18] <amurray> but this also includes results from debian/changelog as well as debian/rules
[01:18] <amurray> and if you want something a bit easier to parse - use the codesearch-cli snap
[02:19] <sarnold> mwhudson, waveform, https://termbin.com/gjc2
[08:01] <eoli3n> Hi
[08:01] <eoli3n> with snap packages i randomly get "cannot open path of the current working directory: Permission denied"
[08:01] <eoli3n> we mount nfs homes on /home/$user
[08:02] <eoli3n> ubuntu 20.04 up to date with snap up to date
[08:02] <eoli3n> its pretty annoying
[08:02] <eoli3n> the problem is related to the host
[08:02] <eoli3n> some hosts work, some don't
[08:03] <eoli3n> permissions and owner are properly set on the homedir
[08:04] <eoli3n> codium is installed with --classic
[08:05] <eoli3n> i have that problem with codium and sublime
[09:22] <eoli3n> where can I get help on snap packages
[09:23] <seb128> eoli3n, try asking your question maybe?
[09:24] <eoli3n> i just did
[09:24] <eoli3n> you weren't connected
[09:24] <eoli3n> seb128 https://x0.at/Dz_i.txt
[09:25] <eoli3n> we authenticate users with email adress, so home owner is that account, but we create groups dismatching the username, would it be related to this ?
[09:25] <eoli3n> https://x0.at/GxCy.txt
[09:25] <seb128> eoli3n, https://forum.snapcraft.io/ is probably the best place to ask such questions
[09:33] <schopin> mwhudson: vorlon: yup, I indeed volunteered. Since the tests fail on migration-reference/0 this won't block glibc
[10:02] <waveform> sarnold, excellent -- very useful, thanks!
[10:08] <utkarsh2102> lenavoytek, racb: can you please take a look at LP: #1960464, is it a similar bug that you've been working on? I saw some activities on similar bugs by Lena, so I'd rather have Lena take a look once, at least.
[10:58] <schopin> anyone here knows common-lisp packaging? pgloader is broken because cl-plus-ssl doesn't support openssl 3.0. Sadly, CL is quite foreign to me so fixing it won't be trivial
[11:35] <ricotz> doko, hi, please don't do no change builds of libreoffice, there is a 7.3.1~rc1 which I waited for :(
[11:36] <ricotz> doko, I leaning torwards cancelling the remaing running builds
[11:37] <ricotz> didrocks, seb128, hi, any thoughts? ^
[11:39] <ricotz> libreoffice 7.3.1.1 got tagged a few minutes ago, and I am going to upload it later
[11:45] <didrocks> ricotz: I would say indeed the new upload is better as the previous one will stay stuck in proposed due to its dep on universe
[11:46] <Laibsch> Hello, I just noticed that focal has a more recent package for samba than jammy.  The reason for the newer package in focal is among others CVE-2021-43566 to which jammy is still vulnerable.  That left me wondering what the security policy is for ubuntu+1.  No security support or would this be considered a bug?  I was just wondering if I should open a ticket.  Obviously, I didn't think I'd open myself up to security pro
[11:46] <Laibsch> ting out ubuntu+1 before it's release.
[11:49] <ricotz> didrocks, doko, I will stop the remaining builds in favour of the upcoming 7.3.1~rc1 build
[12:29] <ahasenack> hi, I have a question for the MIR (Main Inclusion Request) team members,
[12:30] <ahasenack> nfs-utils upstream (src:nfs-utils in main) pulled in code from another upstream project, for which we have a package in universe: src:libnfsidmap-regex
[12:30] <ahasenack> would this require another MIR review? I mean, in general, once a package is in main, we don't apply the MIR guidelines to it anymore, and they can usually change the code as the project seems fit
[12:31] <ahasenack> the actual code is one .c file but I can't just ignore the fact that we have it as a src package in universe currently
[12:31] <ahasenack> (or can I?)
[12:32] <ahasenack> my options are basically a) build src:nfs-utils as usual, and remove src:libnfsidmap-regex from the archive; or b) build src:nfs-utils, don't install the regex bit, and keep building src:libnfsidmap-regex and package the regex bit in there as is done today
[12:32] <ahasenack> (b) will incurr in delta with debian
[12:33] <ahasenack> debian will eventually remove src:libnfsidmap-regex from their archive
[12:55] <tjaalton> ahasenack: btw, sssd 2.6.3-1 is now in debian
[12:55] <ahasenack> so it is
[12:55] <ahasenack> can we sync? I briefly looked, looks like some of our delta was adopted
[12:56] <tjaalton> I haven't looked at the delta
[12:56] <ahasenack> k
[12:56] <tjaalton> will check
[12:57] <ahasenack> hm, i386, lto
[13:03] <tjaalton> committed lto to git
[13:03] <tjaalton> but no, it's not syncable
[13:06] <doko> ricotz, it's a bad idea to cancel the amd64 build, while there are already successful builds in the archive
[13:14] <ricotz> doko, I known, still it is the same situation as usual that the ppc64el/s390x are finished a couple of hours before the other archs
[14:25] <lena> utkarsh2102: I took a look at the bug you sent to me. I haven't seen anything like it with the other bugs I've been working on, although I've only been working on mysql8.0 rather than mysql5.7. I'll see if I can reproduce it in Bionic
[15:01] <utkarsh2102> lena: hey, I couldn't reproduce.
[15:12] <lena> utkarsh2102: neither can I. Although there are some error messages in the output that are similar to ones I have seen when working with mysql-8.0. So it may be related to some other bugs I haven't reproduced yet
[18:12] <utkarsh2102> lena: ah, gotcha! Do you think you can reply to the bug, please?
[18:18] <soren> I'm building a package where the original tarball contains two separate libraries, liba and libb. libb depends on liba. I've installed liba into debian/tmp, but libb's configure checks for liba by building a lib with "gcc [...] -la" which obvs doesn't look in debian/tmp. Is there a common way to solve this?
[18:19] <soren> Should I be setting a LD_LIBRARY_PATH when running libb's configure?
[18:22] <soren> No, wait, that's a runtime setting. Ugh.
[18:25] <ahasenack> you mean it build-depends on itself?
[18:29] <soren> ahasenack: You could say that. In a sense. It doesn't specify it in d/control. Also, this is a new package, so I'd still have the bootstrapping challenge.
[18:31] <ahasenack> tricky
[18:32] <soren> Surprisingly so.
[18:33] <sergiodj> usually upstream handles this themselves (i.e., a top-level configure which is responsible for building liba and then libb with -la and the proper linking incantation needed)
[18:33] <sergiodj> e.g., some packages bundle gnulib and build things like this
[18:34] <soren> I can force it, no problem. Like, say, adding "-I$(DESTDIR)$(includedir) -L$(DESTDIR)$(libdir)" in CFLAGS, etc., but it feels like there should be a straightforward way to do this.
[18:35] <soren> sergiodj: There wasn't a top-level configure. I'm writing one and I'm getting stuck on this one problem.
[18:36] <soren> DESTDIR should only be a "make install" time setting, not a configure time one.
[19:14] <lena> utkarsh2102: done
[20:57] <utkarsh2102> lena: thank you!