[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
=== klebers_ is now known as klebers
[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:08] <ubottu> Launchpad bug 1960464 in mysql-5.7 (Ubuntu) "mysql breaks apt, system, can't even be uninstalled" [Undecided, New] https://launchpad.net/bugs/1960464
[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:46] <ubottu> All versions of Samba prior to 4.13.16 are vulnerable to a malicious client using an SMB1 or NFS race to allow a directory to be created in an area of the server file system not exported under the share definition. Note that SMB1 has to be enabled, or the share also available via NFS in order for this attack to succeed. <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-43566>
[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.
=== genii-core is now known as genii
[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
=== pizza is now known as pizzaiolo
=== pizzaiolo is now known as piz
[20:57] <utkarsh2102> lena: thank you!