[00:00] flexiondotorg: hmmm, maybe I'm wrong... nevermind. sorry for offtopic. [00:00] np [00:09] slangasek: so i think, unfortunately,we might also need to sync php-memcached for it to be installable. Woudl it make more sense for us to remove php-defualts from proposed? [00:26] nacc: didn't we need some fixes from that version of php-defaults? [00:26] I thought there were changes we cared about; and having reviewed the diff before syncing it, I certainly got the impression that upgrading to 35 now would save us pain later in terms of upgrade paths [00:31] flexiondotorg: done. the fresh plank release uploaded, as well. [00:31] ari-tczew, Fantastic! Many thanks for your help :-) [00:32] flexiondotorg: You're welcome. Thanks for contributing. [00:32] slangasek: it will, you're right, let me look at what is causing hte version to change on php-memcache & others [00:34] slangasek: but it's going to break a bunch of versioned deps (php-imagick, php-memache, php-memcached, etc) [00:39] slangasek: oh hai, I need an adult^W^Wa techboard member [00:39] cjwatson: I may be one of those today [00:41] slangasek: we've fixed the apt bug that meant xz was broken on ftpmaster. could you please "lp-shell production devel" and then https://paste.ubuntu.com/15388428/ to add xz support? [00:43] cjwatson: done [00:43] slangasek: Great, thanks. I'll watch the next publisher run to make sure it works this time. [00:46] nacc: php-memcache> syncing; this could also be handled by adjusting the Breaks: version from php-defaults, but the php-memcache sync is safe and takes an item off the todo list for later [00:47] nacc: you also opened a task against php-memcached, but I don't see any details about it in the bug [00:47] cjwatson: I assume we plan to kill bzip2 with fire before release? [00:48] cjwatson: (if the xz bugs shake out) [00:48] cjwatson: s/I assume we plan to/Oh god, please let's/ [00:50] nacc: nah, nevermind, found the breaks: for php-memcached [00:52] infinity: Yes, certainly. [00:53] infinity: Where "before release" probably = "later this week". No obvious reason to keep it around as long as xz works and updates are working for people. [00:54] infinity: But I want to check that assumption first ... === rbanffy_ is now known as rbanffy [00:57] slangasek: yeah, sorry, i created the task, and then saw how many i might need to file [00:57] so was checking them all out before going further [00:57] slangasek: so i think what's happening is that php-defaults-35 is going to require having roughly the same snapshot of the php7.0 packages as ondrej did when he made it [00:57] slangasek: i'm still checking [01:00] nacc: ah. ok, I've uploaded a 35ubuntu1 with the php-memcached I knew about, and if you want to give me a debdiff of other version changes for php-defaults I'm happy to upload that [01:01] nacc: meanwhile, I am resubmitting several of the failed autopkgtests just to confirm that they're fixed with the new xdebug [01:01] there is a DMB again! as of today [01:01] oops, was scrolled back [01:01] i love it when i look into ftbfs's and find upstream bugs that i filed 9 months ago https://github.com/matttproud/golang_protobuf_extensions/issues/9 [01:02] slangasek: ok, yeah, it looks like there's several, let me do that real quick [01:03] slangasek: i'll check with ondrej on if they are real breaks or not -- as the debian git tree doens't have that version, even though it's in unstable [01:05] slangasek: i *think* he's done it this way, because those are the version in debian that have been rebuilt for php7 w/ dh_php [01:05] slangasek: but we get that from our rebuilds too [01:09] slangasek: debdiff posted, your ubuntu1 hadn't hit the repo yet, so it's my own, but i think you can make the change up for ubuntu2 easily enough [01:09] slangasek: i'll probably be afk for a while now, but will do my best to check proposed/excuses again before bed [01:17] xz files are there for xenial now and the publisher seems happy. [01:21] pitti: we now have image and CI runners for powerpc, ppc64el and s390x online in the upstream jenkins. The first round of powerpc, ppc64el and s390x images for Ubuntu are building now so you'll be able to use them with adt when you wake up. [02:29] this is hilarious. [02:30] trying to print a PDF from chrome and it breaks cups (have to remove /var/spool/cups and restart) [02:30] tried printing it from evince and teh printer spit out "PCL XL error subsystem: Kernel error: IllegalTag" [02:30] tried printing it to another PDF or a PS file, no luck [02:30] CRASHED EVINCE trying to print the resulting .ps file [02:31] http://www.zeroglide.com/electric-guitars/ printing the sizing chart, if anyone wants to try breaking 15.10 or 16.04 === juliank is now known as Guest90211 === juliank_ is now known as juliank [02:40] Bluefoxicy: printing fine here; must be your printer drivers [02:40] k [02:41] fortunately 16.04 will be ready soon. === BenC_ is now known as BenC === pepee- is now known as pepee [03:56] nacc: php-defaults ubuntu2 uploaded. fwiw as far as "hasn't hit the archive" is concerned, there's pull-lp-source for that [04:15] slangasek: hrm, at the time, p-l-s didn't find it either, sorry! [06:44] good morning [06:46] stgraber: you rock, thanks! [06:47] * pitti re-runs the lxc/ppc64el/xenial test for linux-meta [06:47] apw: ^ [06:53] nacc, slangasek: I mass-retried php-defaults tests last night, now that looks muuuuch better :) [07:15] hi, q regarding FFE, if a package introduces one new symbol to .symbols: [07:15] + usbredirhost_set_buffered_output_size_cb@Base 0.7.1 [07:15] does that qualify as 'new api' ? [07:18] hallyn: formally yes, but if it's just that it's still fairly harmless [07:18] (this is for nacc's usbredir sync request :) [07:18] hallyn: it's more about "what impact and potential regression does that new version have" [07:18] stgraber, apw: very good, http://autopkgtest.ubuntu.com/packages/l/lxc/xenial/ppc64el/ is green again [07:19] pitti: ok.... https://wiki.ubuntu.com/FeatureFreeze suggests some leeway also in decidding waht is an 'api break' [07:19] so i guess i'll sync. [07:19] hallyn: that's not an ABI break, just new ABI [07:19] hallyn: ABI break would be a soname change, i. e. changing or removing existing ABI [07:19] ok [07:19] hallyn: so that reverse dependencies must be ported [07:20] right [07:20] merely adding a new function doesn't break existing users [07:20] right, i'm just trying to parse the ffe page :0 [07:20] hallyn: thanks for being thorough! [07:21] maybe best to test in a vm [07:22] apw: I was about to restart lxc for other triggers too, but it's not marked as regression on http://people.canonical.com/~kernel/status/adt-matrix/ ? [07:33] good morning [07:38] slangasek, nacc: so I think the only regression that's left is php-sabre-http-3, I'll deal with/retry/hint the other spurious ones [08:33] sil2100, fyi: https://launchpad.net/ubuntu/+source/unity-scopes-api/1.0.3+16.04.20160209-0ubuntu2 === spineau is now known as spineau_afk [08:43] pitti, demoted tcl8.5 and tk8.5. there still seem to be references in main [08:45] doko: thanks [08:47] sil2100, it might be good to update zmqpp as well (now at version 4.1.2) [09:01] doko: nothing on c-m about them yet? [09:02] not yet [09:04] pitti, could you merge again puppet? but it's universe ... [09:04] doko: sure, merging [09:05] fyi, I found http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818259 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818261 [09:05] Debian bug 818259 in src:ruby-fog-atmos "git usage in gemspec" [Serious,Open] [09:05] Debian bug 818261 in src:ruby-github-markdown "git usage in gemspec" [Serious,Open] [09:05] resulting in packages without a gemspec. maybe worth failing the build for those [09:06] pitti, right it has been hinted skip to allow me to release the kernels with that regression [09:08] pitti, would you like me to top the hints so the red comes back ? [09:08] apw: I think we do want ppc64el to succeed again from now on, yes [09:09] pitti, its only for those kernel versions, not in perpetuity [09:09] pitti, but let me rip them then the retry commands will come out [09:10] xnox, wgrant: just out of interest, where is "scalingstack support for s390x images" on a scale from "bwahahahaLOLgoodone" to "sure, will work next week"? [09:11] pitti: scalingstack bos02 will happen at some point Soon™, and is likely to be xenial/mitaka, so we should have software support for s390x in the next scalingstack. [09:12] Then it's a simple matter (famous last words) of turning the buildd LPARs into Ubuntu KVM hosts. [09:12] Since AIUI xnox has made OpenStack work. [09:13] wgrant: I was just about to ask, the LPAR stuff to create zVMs seems radically differerent from invoking QEMU, so teaching all that to a nova compute node seems no small task [09:13] pitti: That's a) OpenStack's problem and b) not a problem, since we'll run normal KVM instances on an Ubuntu LPAR. [09:13] It'll look very similar to POWER in that respect. [09:14] ah, so it's qemu *within* LPAR, not LPAR *being* an openstack instance [09:14] Right. [09:14] I don't know if OpenStack LPAR support is a thing. [09:14] Not at the moment, at least. [09:14] OpenStack on z is exclusively various KVM distributions, I believe. [09:14] wgrant: thanks for the heads-up [09:14] pitti: So from your perspective it should just be like normal, except with bootloaders that are less amusingly broken. [09:16] doko: oh, universe now, so we can drop some delta [09:17] pitti: There are a few autopkgtests that have been running for more than 45 minutes, stuck on creating nova instances. Is that likely to be scalingstack flakiness? [09:17] lcy01's not working at all for LP atm, so I guess autopkgtest might be similar. [09:18] wgrant: yeah, I also got a few timeout emails from died workers; looking in a bit === spineau_afk is now known as spineau [09:29] doko: puppet uploaded, debdiff sent to debian, tests succeed locally [09:30] wgrant: my lcy01 also has tons of "ERROR" instances indeed [09:30] and several instances are hanging in"BUILD" [09:30] xnox, gunradio tests hang on s390x. do you care, or should I disable these? [09:31] wgrant: lgw and bos look okay to me [09:32] pitti: Yeah, it's just lcy01 as usual. [09:33] * wgrant requests stabbery. [09:37] nacc: seems php-imagick is still unhappy on the 32 bit arches (i386 and armhf); should I ignore these or do you want to look? [10:09] pitti: lcy01 is fixed. [10:10] wgrant: cool, thanks [10:12] tumbleweed, https://launchpad.net/ubuntu/+source/pyzmq/15.2.0-0ubuntu1 updated, but now seems to fail everywhere [10:12] however a local amd64 build and test did succeed [10:15] pitti, for some reason tk8.5-dev was seeded. now removed [10:21] stgraber: I uploded lxd for the wrong pyflakes test dep (https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/l/lxd/20160315_001840@/log.gz) [10:55] zequence: many thanks for sorting out dvdstyler → devede; removed dvdstyler and wxsvg now [11:05] nacc: I see php-imagick autopkgtest is still failing on armhf with the strange timeout [11:10] mdeslaur: cjwatson: WRT SHA1 hashes, I just invented a way for apt methods to print a warning in that case, so we are going to warn about them. [11:18] juliank: Thanks; I imagine that will make the transition a bit softer. [11:18] cjwatson: Yeah, I think so. Example: [11:18] W: gpgv:/var/lib/apt/lists/repository.spotify.com_dists_stable_InRelease: The repository is insufficiently signed by BBEBDCB318AD50EC6865090613B00F1FD2C19886 (weak digest) [11:20] cjwatson: Theoretically we need a freeze exception for the new string we add; but in practice language pack support is broken anyway AFAICT, so it's not going to help much... [11:26] The first part may be translated though, but the "weak digest" part not [11:26] reason being that users might want to forward this to their repository providers, and they need something they can understand [11:27] German: Das Repository ist unzureichend signiert von BBEBDCB318AD50EC6865090613B00F1FD2C19886 (weak digest) [11:27] Maybe I should add a reason: to the translate part [11:31] nacc: just reproduced the armhf test failure on porter-armhf.c.c. The test is definitely buggy - at minimum the error message - because it didn't hit a timeout at all, it failed immediately [11:32] nacc: http://paste.ubuntu.com/15391035/ === _salem is now known as salem_ [11:45] nacc: strace of a test run shows the timer is being delivered early by the kernel, but I have no idea why that would be. I wouldn't think php is the only thing using setitimer() on armhf... [12:52] \pilot in [12:53] whoops [12:53] @pilot in === udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur [13:38] * dholbach huds mdeslaur [13:43] is it intended that linux-image-generic-lts-vivid is in the wily archive ? [13:43] (and -wily) [13:46] smoser: it ought to be a trasnitional package to linux-image-generic (up until xenial) [13:47] pitti, yeah, you're right [13:47] Unpacking linux-image-generic-lts-wily (4.4.0.12.13) ... [13:47] duh [14:50] slangasek: ugh, we might also need to update php-defaults version check on php-redis [14:54] doko: fyi, upstream remctl (debian/upstream) is going to try and integrate my patch with ifdefs. Let me know how you'd like to proceed === Karibou is now known as caribou === caribou_ is now known as caribou === fginther` is now known as fginther [15:39] @pilot out === udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [15:40] pitti: hmm, wll, that pyflakes dependency wasn't wrong until a day ago when barry synced the new pyflakes from Debian which splits pyflakes3 out of pyflakes... [15:40] stgraber: right; sorry, that wasn't meant as a blame, just a FYI in case I made some packaging git out of date [15:41] not sure why that change was made without carrying a recommends or something for a while so that folks that were using pyflakes3 from pyflakes aren't left with it missing... [15:41] stgraber: (it was blocking lxcfs) [15:42] stgraber: i think that's just a bug. it should have included a recommends [15:43] i'll fix that when i get a chance [15:46] barry: thanks [15:53] slangasek: just filed a bug to fix php-sabre* in proposed (LP: #1557599) and I think we should ignore failure on the php-imagick armhf one for now (same timeout as before) [15:53] Launchpad bug 1557599 in php-sabre-http (Ubuntu) "php packages: add php-mbstring dependency" [Undecided,New] https://launchpad.net/bugs/1557599 === kickinz1_ is now known as kickinz1 [16:04] nacc: agreed, overriding that hint since it's not a regression from what we've already let through; but based on what I'm seeing in debugging that test, it looks like there's a real problem with php-imagick on armhf, which warrants figuring out [16:04] slangasek: yeah, I am happy to do look into it today. What's the best way for me to debug an armhf failure? This would be my first exposure to it. [16:04] nacc: did someone get you added to the 'porters' team, so you have access to porter-armhf.c.c? [16:07] slangasek: probably not? :) [16:08] stgraber: ah, it was a Suggests. bumping to Recommends [16:09] why is lynx-cur gone from the archive? [16:11] mdeslaur: https://launchpad.net/ubuntu/+source/lynx-cur/+publishinghistory [16:11] mdeslaur: "ROM; renamed to and replaced by lynx" [16:12] but lynx isn't there to replace it yet [16:12] grr [16:12] guess I just need to sync it [16:12] thanks nacc [16:13] * mdeslaur looks in queue [16:13] mdeslaur: oh i see what you're saying ... hrm, yeah, that seems like it's likely what is missed, but not sure [16:17] pitti: Do you think you could teach ddeb-retriever about Packages.xz etc. in xenial (but not in older series)? I'd like to be able to drop Packages.bz2 soon. [16:30] hallyn: would you be able to review/sponsor LP: #1318317 for me? [16:30] Launchpad bug 1318317 in openipmi (Ubuntu) "openipmi startup script removes kernel modules" [High,In progress] https://launchpad.net/bugs/1318317 [16:30] hallyn: we'd like to merge (or consider for merging), but i'd like to get that fix in, so I can file the SRU [16:35] cjwatson: yeah, that shouldn't be too hard; on a (virtual) sprint this week, but making a note [16:38] nacc: you're just talking about the short debdiff? (not an upstream merge) [16:38] bug is kinda long - is the need to unload modules at all justified in any of the comments? [16:40] hallyn: yeah, just the short debdiff, tested by the bug reporter @ IBM w/ 16.04 [16:40] hallyn: i looked for a while, and the ipmi.init script upstream hasn't been touched since ... 2010 :) [16:40] doko: Is there any intent to drop openjdk6/openjdk7 before xenial release? [16:41] doko: (Asking because we dropped tzdata-java in sid, and I can either reinstate it just for xenial, or you need to fix openjdk{6,7} [16:41] tdaitx: ^ [16:42] hallyn: and it's not well documented. The unload has been present since 2005. [16:42] nacc: looks good, will push, thx [16:43] hallyn: i did send an inquiry & the same patch upstream [16:44] hallyn: thank you very much! [16:46] except your debdiff is out of date? hm [16:46] hallyn: i can refresh, let me check [16:46] :) s'ok i'll do it [16:47] hallyn: ah yes, looks like a minor release happened in-between, sorry! [16:50] nacc: apparently that one was just published today [16:53] infinity: openjdk 6 will be dropped, not sure about 7 (but I believe we will keep it) [16:53] hallyn: yep, i see it now; shouldn't conflict with my changes at all, afaict [17:00] pitti: thanks [17:01] tdaitx: why keep around openjdk 7? [17:01] isn’t it eol? [17:02] Son_Goku: only Oracle Java 7 is EOL, OpenJDK 7 is still being supported [17:02] tdaitx: Kay, if we're keeping 7, I'll reinstate tzdata-java for it. Though, if you want to have a talk with Steve and Matthias and confirm that before I do, that would be nice. ;) [17:02] infinity: sure, we need to check that with doko [17:03] tdaitx: if we will have openjdk-8 as the default, I see no reason we would keep -7 for 16.04 [17:03] however, there's surely work yet to be done to get it removed [17:04] pitti, infinity, stgraber, mdeslaur, kees: tb meeting? [17:04] (or is my calendar wrong?) [17:05] no, it's right [17:06] slangasek: Your calendar is right, my brain is wrong. [17:07] slangasek: http://paste.ubuntu.com/15393373/ <-- That's the work needed. If you can commit doko/tdaitx to that before release, yay, if not, I might just assume we're keeping it. [17:09] stgraber: *poke* [17:09] seb128: hey! I was told you were looking into the issue of the ubuntu-system-settings translations being reverted - did you manage to find the cause? [17:09] infinity: right, so these packages are all stupid and buggy and hard-code a specific version of java instead of using the metapackages, check ;) [17:09] sil2100, hey, sorry got busy on other things but now is actually an ok time to look at it, let me do that [17:10] seb128: since I wanted to look into it but didn't know if you didn't already :) [17:10] slangasek: Or they use hardcoded paths to the jars and may actually be incompatible with new versions. [17:10] slangasek: Likely a mix of both. [17:10] infinity: still stupid and buggy ;) [17:10] sil2100, I've an idea where to poke, let me have a look [17:10] seb128: ok, thanks o/ [17:11] yw! [17:11] slangasek: I feel that way about all things Java. === vrruiz_ is now known as rvr [17:32] slangasek: argh, sorry; forgot over the sprint [17:32] pitti: it's ok, we gave you all the action items [17:41] @pilot in === udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: seb128 [17:43] slangasek: sorry, made a dumb typo in php-sabre-http, follow-on debdiff posted in LP: #1557599 [17:43] Launchpad bug 1557599 in php-sabre-http (Ubuntu) "php packages: add php-mbstring dependency" [Undecided,Fix committed] https://launchpad.net/bugs/1557599 [17:45] slangasek: php-sabre-dav-2.1's failure might be real, i'm going to look at the older build samples [17:48] doko: https://paste.ubuntu.com/15393693/ [17:55] nacc: php-sabre-http reuploaded [17:56] slangasek: thanks! and apologies [17:57] nacc: well I was the reviewer, clearly not doing my job either ;) [17:59] nacc: oh. also just noticed that the failing package in p-m is php-sabre-http-3, not the php-sabre-http we just uploaded [17:59] slangasek: i'm thinking the sabre-dav is possibly an issue for php7 on s390 ... i'm tempted for us to turn on the tests during build [17:59] not sure why a separate php-sabre-http-3 is needed, it has no revdeps [18:00] rationale from changelog is * Rename as php-sabre-http-3 so that php-sabre-dav-2.1 will be [18:00] co-installable with more recent versions of php-sabre-dav. [18:01] but the php-sabre-dav-2.1 we have in the archive depends on php-sabre-http, not php-sabre-http-3 [18:02] nacc: there's a newer php-sabre-dav-2.1 in unstable, looks like we need that and to apply test fixes for php-sabre-http-3 [18:03] slangasek: i'l investigate that nnow [18:10] slangasek: ok, looks like php-sabre-dav-2.1 from debian has the same chagnes we do, but needs the d/test/control still, will send a debdiff for that, looking at the others now [18:39] nacc: was there still an outstanding debdiff for php-imagick? I see that the tests for -1ubuntu3 in -proposed are still failing on amd64/ppc64el, with the rounding problem [18:42] slangasek: uhhh! That's super weird, they passed here! Let me reconfirm after i figure out this sabre stuff [18:42] ok [18:43] pitti, you set https://bugs.launchpad.net/ubuntu/+source/php-doctrine-data-fixtures/+bug/1544318 to "fix commited" but didn't upload, was that an overlook? [18:43] Launchpad bug 1544318 in php-doctrine-data-fixtures (Ubuntu) "php-doctrine-data-fixtures: update to PHP7.0 dependencies" [Wishlist,Fix committed] [18:44] seb128: hm, I don't remember that, probably pilot error [18:46] pitti, k [18:48] @pilot out === udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [18:52] seb128: ping, if you don't mind me picking your brain for a moment [18:52] (see PMs0 [18:57] mterry, cinder appears to be stuck in proposed because of python-googleapi, but we've since abandoned that MIR and moved the dependency to Suggests in the control file. have any tips on how to move that along? [18:58] slangasek: ok, i think sabre fixes are done, and make sense. Might still trip the s390 failure, as it might be real, as mentioned [18:58] slangasek: i'll look at php-imagick right after lunch, that result makes no sense to me [19:06] coreycb: you mean migration-proposed says it's blocking on python-googleapi, but it shouldn't be? [19:17] Odd_Bloke: When linux_4.4.0-14.30 migrates, your powerpc cloud images should be bootable. [19:17] stgraber: ^ [19:17] cjwatson: ^ [19:19] infinity: \o/ [19:21] Odd_Bloke: Really oddly subtle bug. Thankfully, IBM had already fixed it in linux-next, so it just needed a cherrypick. Finding it was less fun. [19:23] mterry, well I'm looking at update-excuses and component-mismatches [19:27] coreycb: I'm not sure why that would happen, honestly [19:27] mterry, ok yeah it seems like it's gating on old status [19:31] infinity: yay, looking forward to finally having a kernel with proper seccomp support :) [19:34] infinity, would you happen to have any tips on how to move cinder along? (re: question above to mterry) [19:39] coreycb: Yes. Upload a fixed package. [19:39] coreycb: Turns out that britney isn't smart enough to act on intentions, only actions. :) [19:39] coreycb: (Hint, the package still depends on python-googleapi) [19:40] coreycb: I assume being auto-filled by ${python:Depends} [19:41] infinity, ok that may be it, although I thought dh_python didn't guess deps anymore [19:42] infinity, I'll patch it out nonetheless and see how that goes [19:42] coreycb: Also, is cinder/opts.py meant to work? [19:42] coreycb: Cause without the dep, it sure won't. [19:43] infinity, it's an optional backup option [19:44] infinity, so we should be ok [19:44] nacc: some thinking-out-loud about php-sabre-dav-2.1 on the bug report now [19:44] coreycb: Well, what I meant is that without the Suggest installed, opts.py won't work AT ALL. Which seems subopt(hah!)imal. [19:45] coreycb: You might want to make the google import and usage optional. [19:45] infinity, yeah I see your point, I'll see about opening a bug upstream about that [19:45] nacc: namely, php-mbstring *should* have been picked up from composer.json as a runtime dependency for the package, which would have let us sync from Debian. But it's not, so there's a bug somewhere beneath pkg-php-tools [19:45] infinity, and fixing the package [19:45] coreycb: If upstream wants to make the whole thing modular, all the better. Google isn't special there, I assume. [19:46] coreycb: Importing every possible binding for every possible backup backend seems mad anyway. [19:46] infinity, I agree, I need to dig into this file a bit more [19:49] nacc: same issue for php-sabre-http [19:52] infinity, fyi, we're not using that file yet. it's used for config file generation. we'll be moving to that eventually. [19:54] coreycb: Fair enough. If you never actually run it, not shipping it would seem the best option to fix the python autodepends issue. [19:56] infinity, ok [19:56] coreycb: (Stab in the dark, I don't do much python packaging, but if it's generating the dep based on that import, it stands to reason that if there's no import, there's no dep :P) [19:57] coreycb: Alternately, you could just patch out the two references to google entirely, and drop the Suggests too. Not much point suggesting a module that never gets used. [19:59] infinity, well it is used in cinder/backup/drivers/google.py so I think it should be an option for users. also I think that if dh_python generates the dep it's based on requirements files not imports. [19:59] coreycb: Oh, probably indeed. [20:00] infinity, appreciate the discussion! off I go.. [20:25] pitti: where's the right place to file bugs about update_excuses output? [20:26] slangasek: https://bugs.launchpad.net/britney I think [20:26] ok [20:26] I tried to find 'proposed-migration', because ISTR 'britney' is deprecated as a name ;) [20:28] slangasek: https://bugs.launchpad.net/auto-package-testing/ works too [20:28] that's the umbrella project [20:34] pitti: Yo. [20:34] https://launchpadlibrarian.net/248258284/buildlog_ubuntu-xenial-armhf.nginx_1.9.12-0ubuntu1_BUILDING.txt.gz [20:35] pitti: pkg-create-dbgsym bug, or would you rather blame debian/rules? [20:35] pitti: teward says this is racy and nondeterministic, and retries generally succeed. [20:36] * teward was pinged :) [20:36] infinity: looks like dh_strip is being called in parallel four times, so I guess some missing locking indeed [20:37] override_dh_strip: $(foreach flavour,$(FLAVOURS),strip.arch.$(flavour)) [20:37] strip.arch.%: [20:37] dh_strip --package=nginx-$(*) --dbg-package=nginx-$(*)-dbg [20:37] So, yeah. They could force that to be serial to work around it. But I'd say it's our bug that it doesn't work. [20:38] Though, I'm still wary of anyone setting MAKEFLAGS=-j in debian/rules. [20:39] teward: Tearing out that and switching to dh --parallel would likely clear it up at the expense of slowing down the non-build parts a bit. [20:39] Maybe. [20:42] infinity: at first sight I don't see anything which would write into shared files (i. e. write things other than to the per-binary package dir) [20:42] unless it calls pkg_create_dbgsym *twice* for the same binary package somehow [20:43] Wait... [20:44] pitti: This almost looks like strip and gencontrol are running in parallel, which doesn't seem possible. [20:45] pitti: Or does pkg-create-dbgsym's dh_strip call dpkg-gencontrol? [20:45] infinity: no, but it diverts dpkg-gencontrol [20:45] err, dh_gencontrol [20:46] nacc: confirmed that php-sabre-dav-2.1 still failing on s390x [20:47] pitti: No, it totally calls dpkg-gencontrol. [20:47] for the -dbgsym, yes [20:47] slangasek: ah, i wondered, let me investigate what isn't generating the right dep [20:50] pitti: So, yeah, that's the race, I think. dpkg-gencontrol locks, but you rm -f dhstrip-dummy-debian-files outside the lock, which could whack it at exactly the wrong time. [20:51] pitti: I wonder if -f/dev/null works. That would be less sketchy, perhaps. [21:00] Nope, /dev/null wouldn't work, since it would try to write to /dev/null.new [21:00] Brilliant. [21:01] Perhaps I need to fix dpkg first, then pkg-create. [21:01] * infinity makes a note for later and abandons this for today. [21:01] infinity: -fdhstrip-dummy-debian-files.${pkgname} ? [21:01] pitti: Oh, or indeed, using per-package files would also work. [21:02] slangasek: i think i found it [21:02] slangasek: in my build logs, i see: [21:02] pitti: Probably quicker than me fixing dpkg. :) [21:02] slangasek: Override: require:pear-pecl.php.net/mbstring -> require:__override__/builtin. [21:02] slangasek: but in debian, that does not happen [21:02] pitti: (Though, I think having a "none" option for -f would be sane as well) [21:02] infinity: sorry, diverted (vsprint going on), but that seems easiest? [21:02] slangasek: trying to figure out why [21:02] pitti: Yup, concur. I'll upload that (and drop -is -ip while I'm there to cut down on log noise) [21:03] infinity: cheers [21:09] teward: Fixed. If the problem recurrs, let us know so we can see if we missed another race. :P [21:10] pitti: http://launchpadlibrarian.net/248264461/pkg-create-dbgsym_0.70_0.71.diff.gz [21:10] yay [21:11] pitti: And fixed just in time for us to switch to Debian's dh-based solution, I guess. :P [21:11] pitti: (Is that on your roadmap for 16.10?) [21:11] slangasek: ok, i see what's happened [21:11] slangasek: debian has made more changes to pkg-php-tools under 1.32 [21:11] infinity: that requires some Launchpad changes at least, as debian uses .deb as extension at least (not sure if there's some other subtleties) [21:12] pitti: We can just patch debhelper to use ddeb for us, surely. [21:12] yeah, I guess [21:12] pitti: I'm not keen on changing the extension to match Debian, personally, I think their choice was wrong. ddebs aren't policy-compliant debs. [21:12] nacc: uhhm? we have 1.32ubuntu1; was that not based on a 1.32 package that was uploaded to Debian? [21:12] slangasek: want me to provide debdiff to get us merged up? [21:13] slangasek: no, it was versioned as 1.32 in debian but it was a WIP, apparently [21:13] nacc: IOW this was a merge from git but it wasn't in the archive? [21:13] slangasek: yeah [21:13] nacc: ok; in the future please avoid using a version number like 1.32ubuntu1 for something not yet in Debian unstable, to avoid this problem of invisible Debian deltas :) [21:14] slangasek: yep, my fault cmpletely [21:14] nacc: and yes please I'll take a debdiff for pkg-php-tools [21:14] 1.32ubuntu1->1.32ubuntu2 [21:14] yep [21:16] slangasek: and the delta we have is in the git tree (debian's) but after 1.32, so i'll continue to carry it as a delta, and eventually (16.10), we'd be able to sync easily [21:16] pitti: Oh, lolz. Testsuite fails due to the deprecation of DH_COMPAT << 5 [21:16] pitti: La la la. [21:19] pitti: Does dhtest.compat1 make sense at all given debhelper will fail, or should I just remove it? [21:19] * infinity leans toward the latter. [21:20] infinity: we still had compat 1 packages at the time when I wrote that [21:20] infinity: if those are now FTBFS, I'm all for killing that code and these tests [21:20] pitti: Right, and we may still have some, but they'll FTBFS regardless. [21:20] * infinity nods. [21:20] pitti: Killing the test then. [21:20] And test building before I upload this time. Grr. [21:25] slangasek: testing the updated build and will post in just a sec [21:32] slangasek: debdiff posted in LP: #1557599 [21:32] Launchpad bug 1557599 in pkg-php-tools (Ubuntu) "php packages: add php-mbstring dependency" [Undecided,New] https://launchpad.net/bugs/1557599 === salem_ is now known as _salem [21:35] nacc: pulling. any thoughts on the mb_stripos() empty delimiter issue on s390x? [21:37] slangasek: i'm trying to figure out how that could happen only on one architecture ... it feesl like it must be a utf8 bug on s390, but i have no experience debugging it. Is it possible for me to spin up an instance that I can reproduce the failure on? [21:38] slangasek: pointing me to a wiki page would be fine :) [21:38] nacc: I think the server team should have access to some s390x resources that you should be able to get onto [21:40] slangasek: you're right, i'll ask around [21:44] pitti: http://paste.ubuntu.com/15396968/ <-- Bigger, badder diff that now passes the testsuite. Look sane to you? [21:45] infinity: yay, I'm glad to see that old junk go, thanks [21:46] pitti: I'll read that as a +1 [21:51] slangasek: as to php-pear's excuses, i just subscribed you to a bug to fix php-cache-lite and i believe php-html-safe just needs to be kicked back off now that we've fixed php-xml-htmlsax3] [21:56] infinity: I guess a glibc update is not going to be done anymore? [22:02] jtaylor: infinity said earlier today that he's working on glibc updates to address 1529486 (among others) [22:05] infinity: good to hear, thanks for the heads up [22:12] infinity, tdaitx: openjdk-6 should be removed; we can prepare security updates in ppa's as well. ideally 7 should be removed as well, but it's in universe, and we still have b-d's. having certified versions in main is more important than removing 7 from my point of view [22:13] jtaylor: it's on the way. [22:13] doko: Alright, I'll operate on the assumption that 7 is surviving and fix tzdata to accomodate. [22:13] doko: (FWIW, 6 and 7 are both uninstallable in sid) [22:14] infinity, I would appreciate a tzdata-java for experimental; it's way easier to prepare packages in experimental, and then backport [22:15] or I'll have to add a variant to use the internal tzdata [22:15] doko: Not sure how experimental relates. I can just reintroduce tzdata-java in sid if openjdk-7 is sticking around for a while. [22:16] doko: aurel32 dropped it because we were using default-jre, that's all, I'll just switch to using 7 explicitly. [22:16] would like to get it out of testing first; but then, you can't build tzdata-java anymore in testing [22:17] doko: I'm a bit lost. Why would we remove it from testing? [22:17] because there should be one version only [22:18] and you can't use 8 to build it; 8 using a different format again [22:20] doko: I guess I'm very confused by what you're asking for. The tzdata-java in testing and xenial was built with openjdk-7. I'm just proposing reintroducing that same thing so your deps don't break. [22:21] (Because openjdk-6-jre-headless and openjdk-7-jre-headless depend on tzdata-java) [22:35] slangasek: ok, super weird about php-imagick; it's pretty clear that s390x is giving 32768 (as it failed with ubuntu2 for that reason) ... so why didn't teh change work for amd64 & ppc64el? setting up an env to debug in [22:46] slangasek: ok, but i did reproduce this here, so let me debug. I swear i got this test to pass on my system when i submitted the debdiffs before...sigh [23:15] infinity: which package(s) got updated to include the fix for that race condition, if I may ask? *is curious what the core cause was, and lost all his scrollback* [23:16]