| 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 | 00:07 |
| === ben_r_ is now known as ben_r | ||
| 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:31 |
| cpaelzer | well actually that might be part of a full kde transition reading the pkg names | 07:32 |
| 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:33 |
| 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:34 |
| 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:38 |
| 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:42 |
| mwhudson | cpaelzer, paride: i haven't looked at qtbase-opensource-src specifically but my impression is that everything is horrendously tangled together | 07:44 |
| paride | mwhudson, I will try to have a look today | 08:09 |
| 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:10 |
| 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:12 |
| 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 | 08:13 |
| === 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 | ||
| 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:22 |
| mwhudson | yeah i'm not sure either | 08:34 |
| mwhudson | i think i can see why the autopkgtest is failing with 0.1-7-1ubuntu1 | 08:38 |
| 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:43 |
| doko | cpaelzer: deepin-terminal is the same category/error as terminator, a package providing x-terminal-emulator | 08:45 |
| cpaelzer | yes doko | 08:46 |
| cpaelzer | a false positive, but we should find a way to get it out of the reports | 08:46 |
| 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 | 08:48 |
| mwhudson | RikMills, paride, doko: ok uploaded a fixed r-cran-lwgeom | 09:01 |
| mwhudson | it's a bandaid though | 09:01 |
| RikMills | \o/ | 09:05 |
| mwhudson | the tests will probably fail initially, can someone retrigger them with all-proposed=1 when they get the chance? | 09:14 |
| RikMills | mwhudson: will do if I am by a PC when results come | 09:17 |
| mwhudson | ty | 09:17 |
| RikMills | mwhudson: poked the tests, and so far retries seem to be passing. proj is now a valid candidate | 12:42 |
| RikMills | also poked a couple that were stopping perl being a valid candidate (stuck in test in progress status, but never did get run) | 12:44 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| cjwatson | that would seem like the ideal option | 13:26 |
| cjwatson | but since it doesn't exist ... | 13:26 |
| 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:53 |
| 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:54 |
| 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. | 16:55 |
| bdmurray | marcustomlinson: I'm working on another update-manager bug so let's coordinate our uploads / SRUs. | 18:30 |
| marcustomlinson | bdmurray: sure I’ll ping you tomorrow | 19:05 |
| === genii_ is now known as genii | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!