[00:07] <bryce> mwhudson, https://bugs.launchpad.net/ubuntu/+source/php-horde/+bug/1880776
[00:07] <ubottu> Launchpad bug 1880776 in php-horde (Ubuntu) " Please blacklist and remove php-horde and php-horde-* from groovy" [Undecided,New]
[00:07] <mwhudson> bryce: thanks
=== ben_r_ is now known as ben_r
[07:31] <cpaelzer> paride: on +1 maintenance if you could check with the others if one is looking at qtbase-opensource-src that would be great
[07:31] <cpaelzer> it entangles a few other things, it looks desktop'ish but I'm unsure - so checking if one is looking at it would be kind
[07:31] <cpaelzer> all tests are good but https://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt reports some uninstallabilities if I read that correctly
[07:32] <cpaelzer> well actually that might be part of a full kde transition reading the pkg names
[07:33] <cpaelzer> wgrant: from your experience on update_output is riscv listed so often because it is actual issues on riscv - or is it just because it reports just one arch (avoiding duplication) and riscv happens to be the one picked?
[07:34] <cpaelzer> hmm "Arch order is: amd64, arm64, armhf, i386, ppc64el, riscv64, s390x"
[07:34] <cpaelzer> does that mean if risc islisted it would have worked on the others before it?
[07:38] <wgrant> cpaelzer: The problem with e.g. yara looks riscv64-specific, unless I'm misinterpreting the output
[07:38] <wgrant> start: 111+0: a-7:a-7:a-8:i-2:p-7:r-72:s-8
[07:38] <wgrant> orig: 111+0: a-7:a-7:a-8:i-2:p-7:r-72:s-8
[07:38] <wgrant> skipped: yara yara-python (0, 0, 32)
[07:38] <wgrant>     got: 138+0: a-7:a-7:a-8:i-2:p-7:r-99:s-8
[07:38] <wgrant> But I'd expect that to be broken on all arches; libguestfs needs a rebuild for libyara4 afaict
[07:42] <mwhudson> transform: couldn't project point (-81.4728 36.2344 0): No such file or directory (2)
[07:42] <mwhudson> how can this possibly happen
[07:44] <mwhudson> cpaelzer, paride: i haven't looked at  qtbase-opensource-src specifically but my impression is that everything is horrendously tangled together
[08:09] <paride> mwhudson, I will try to have a look today
[08:10] <RikMills> mwhudson et al. : yes, the Qt transition is entangled via qgis (depending on proj etc). also entangled with re2/perl transition due to a QtWebEngine rebuild in proposed for re2, while QT was still not migrated.
[08:12] <RikMills> webengine could perhaps be rolled back by an AA to the unentangled version for a brief time if that helped the rest (Qt + proj) migrate
[08:13] <mwhudson> heh i have my head in proj right now
[08:13] <doko> paride: better fix the failing proj test
[08:13] <doko> or r-cran-lwgeom, triggered by proj
[08:13] <paride> ack doko
=== sadin999_ is now known as sadin999
=== niedbalski_ is now known as niedbalski
=== ijohnson_ is now known as ijohnson
=== nickv1985_ is now known as nickv1985
=== dupondje1 is now known as dupondje
[08:22] <RikMills> mwhudson paride: FYI, in case you had not seen, the original r-cran-lwgeom s390x issue with version 0.2-3-1 was reported as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961211
[08:22] <ubottu> Debian bug 961211 in src:r-cran-lwgeom "r-cran-lwgeom: autopkgtest failures on s390x" [Serious,Open]
[08:22] <RikMills> I don't know which is the worst evil. that or the 0.1-7-1ubuntu1 we have now
[08:34] <mwhudson> yeah i'm not sure either
[08:38] <mwhudson> i think i can see why the autopkgtest is failing with  0.1-7-1ubuntu1
[08:43] <mwhudson> (master)mwhudson@anduril:~/src/pkg/plus_one/r-cran-lwgeom$ git diff upstream/0.1-7 upstream/0.2-4 | wc -l
[08:43] <mwhudson> 47401
[08:43] <mwhudson> yay!
[08:45] <doko> cpaelzer: deepin-terminal is the same category/error as terminator, a package providing x-terminal-emulator
[08:46] <cpaelzer> yes doko
[08:46] <cpaelzer> a false positive, but we should find a way to get it out of the reports
[08:48] <cpaelzer> I haven't looked at the code yet (not even which code it exactly is), but I have a feeling this will go into the guts of things and not be nice&easy
[09:01] <mwhudson> RikMills, paride, doko: ok uploaded a fixed r-cran-lwgeom
[09:01] <mwhudson> it's a bandaid though
[09:05] <RikMills> \o/
[09:14] <mwhudson> the tests will probably fail initially, can someone retrigger them with all-proposed=1 when they get the chance?
[09:17] <RikMills> mwhudson: will do if I am by a PC when results come
[09:17] <mwhudson> ty
[12:42] <RikMills> mwhudson: poked the tests, and so far retries seem to be passing. proj is now a valid candidate
[12:44] <RikMills> also poked a couple that were stopping perl being a valid candidate (stuck in test in progress status, but never did get run)
[13:20] <mdeslaur> I need to package a new upstream version of something as a security update, it's going to be newer than what debian has, but it's a dfsg package, so I'll likely collide with debian's tarball when it comes out...is there any good practice for this, or do I collide away and sync back up with the next upstream release?
[13:21] <rbasak> I'm not aware of anything apart from trying to coordinate with the Debian maintainer
[13:21] <mdeslaur> I thought about just not adding the dfsg suffix to the package version, but it will need to be removed from the symbols files too, so I don't really want to do that
[13:22] <rbasak> Yeah not worth it IMHO
[13:22] <rbasak> Too much potential for confusion
[13:22] <cjwatson> if the Debian maintainer is active then sometimes you can manage to agree a tarball
[13:22] <cjwatson> which I guess is what rbasak said
[13:23] <mdeslaur> ok thanks rbasak, I'll send him an email see if he responds
[13:23] <mdeslaur> cjwatson: thanks, I'll try that
[13:23] <cjwatson> also I don't suppose that uscan's mangling is reproducible?
[13:23] <rbasak> Even if it is, it seems unlikely it pass through tar and the compression reproducibly?
[13:24] <mdeslaur> he just refactored all the code that does that, so I'm not even sure we'd be using the same code
[13:24] <mdeslaur> I'll ask the maintainer
[13:25] <cjwatson> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807270   rats
[13:25] <ubottu> Debian bug 807270 in devscripts "mk-origtargz: create reproducible tarballs and --mtime option" [Wishlist,Open]
[13:26] <cjwatson> that would seem like the ideal option
[13:26] <cjwatson> but since it doesn't exist ...
[16:53] <rbasak> bryce: I've injected a reimport request for logwatch. Let's see if that works OK. Assuming it does, I'll do the same for coreutils and php7.4.
[16:54] <rbasak> ^ FYI to anyone else interested, the git-ubuntu branches for these packages will be rewritten shortly.
[16:54] <rbasak> I'll announce more widely when I start doing bulk reimports.
[16:55] <rbasak> If all goes well, we'll reimport everything just once, and then the branches (and tags) for the unapplied part of the imports will be stable.
[18:30] <bdmurray> marcustomlinson: I'm working on another update-manager bug so let's coordinate our uploads / SRUs.
[19:05] <marcustomlinson> bdmurray: sure I’ll ping you tomorrow
=== genii_ is now known as genii