=== sforshee_ is now known as sforshee
[08:18] <schopin> I'm sponsoring a SRU, and the debdiff has some patch refreshes in there (only offsets, no fuzz). I personally wouldn't include those as it's just noise for the reviewers, but is it actually frowned upon, and if so documented?
[08:21] <seb128> schopin, it doesn't seem to be documented on the wiki, I think the smaller the diff is the easier it is to review for the SRU team so I would also avoid refreshing patches but I don't think it is considered as a blocker
[08:21] <seb128> would perhaps be nice to have the SRU team to add a note about that on the wiki guidelines
=== bigon_ is now known as bigon
=== sem2peie- is now known as sem2peie
[11:11] <rbasak> schopin: I agree it's just noise for reviewers. When training up/sponsoring new uploaders, I ask that quilt refreshes only take place when strictly required (ie. for casees where something doesn't apply or applies with fuzz only). And I ask that the quilt settings given at https://wiki.debian.org/UsingQuilt be used, to minimise noise in the future. I think this is all a basic uploader thing, rather
[11:11] <rbasak> than anything SRU-specific.
[11:43] <schopin> Could a core dev click on the links pasted at https://paste.ubuntu.com/p/MR3Mmxrdkt/ ? TIA!
[11:48] <seb128> question for those who use grab-merge, is the unpacked dir it is giving supposed to be buildable once the conflict resolved?
[11:49] <seb128> taking wget as an example which only has a change in debian/control and debian/rules, the control conflicts, but once resolved that isn't building because there are diffs in .po files
[11:49] <seb128> is that expected?
[12:17] <rbasak> seb128: your issue reminds me of https://people.canonical.com/~cjwatson/dpkg-quilt-setup. I think that might be a solution - is it something to do with quilt patches applied but without a .pc directory?
[12:21] <seb128> rbasak, I don't think so, the patches don't touch the .po dir
[12:58] <ginggs> schopin: doesn't look like anybody else did, so doing now...
[14:06] <sergiodj> tjaalton: hey there, just checking if you're aware of/working on certmonger's FTBFS: https://launchpad.net/ubuntu/+source/certmonger/0.79.15-1
[14:07] <sergiodj> I stumbled upon it while doing a test rebuild for the upcoming openldap 2.6 transition
[15:53] <dbungert> May I get assistance with a retest? retry-autopkgtest-regressions|grep trigger=squashfs-tools
[15:53] <vorlon> dbungert: doing
[15:54] <dbungert> vorlon: thanks!
[15:54] <vorlon> dbungert: done
[15:58] <vorlon> ogayot: fwiw my usual approach for a proxy issue like requests is to simply unset the proxy env vars from the test script in debian/tests.  If upstream decides not to take this patch, that's what I think we would fall back to - though hopefully they will agree that their test suite should pass regardless of the environment
[15:58] <vorlon> anyway, sponsored, thanks!
[16:05] <ogayot> vorlon: thanks, I'll take that approach going forward
[16:05] <vorlon> ogayot: it doesn't work in cases that the autopkgtest is autogenerated by autodep8 :) (common for perl and ruby packages)
[16:07] <ogayot> as in Testsuit: autopkgtest-pkg-perl in d/control?
[16:07] <ogayot> s/Testsuit/Testsuite/
[16:07] <vorlon> ogayot: exactly
[16:07] <ogayot> thanks!
[16:07] <vorlon> in those cases, there's nothing in debian/tests to be patched
[16:07] <vorlon> (it would be nice to have an interface to autodep8 to override the environment, but this doesn't exist today!0
[18:12] <tjaalton> sergiodj: I heard about it, but debian isn't affected so I'm not sure what caused it
[18:14] <sergiodj> tjaalton: yeah, I noticed that as well.  I haven't investigated it (yet)
[18:14] <sergiodj> currently I'm dealing with other FTBFSes
[18:15] <tjaalton> at least current upstream git doesn't seem to have anything useful
[18:16] <sergiodj> yeah...  I'm foreseeing some fun times ahead
[19:02] <dbungert> another retest please? retry-autopkgtest-regressions|grep package=chkrootkit
=== ckie is now known as cookie