[00:16] nacc: ugh :( [00:22] mdeslaur: yeah, i went through this before too -- i'll keep hacking at it [00:23] fun, swig upstream got php7 support [00:24] mdeslaur: one issue (present in debian too), seems to be an off by one somewhere (0-255 is expected, but 1-256 is being used, maybe?) [01:00] mdeslaur: i wonder if it's a comlete thinko on my part and these two need nochange rebuilds! let me test [01:24] mdeslaur: yep that was it (still the one failure i need to figure out) [01:42] mdeslaur: and that fixes the ruby-rmagick regression too [04:44] sarnold you are absolutely correct. Shame on me for trying to rush it before the EOD... I'll re-work it tomorrow, as it's on my laptop, and that's downstairs. [04:45] chiluk: eod, very good idea :) just about time for me to go find tacos... [04:46] sarnold where are you at that you have tacos? [04:46] chiluk: portland [04:46] hmm not what I was expecting. [04:46] :) [04:46] well have a good night... I'll harass people tomorrow about yakkety. [04:47] there's a hole-in-the-wall style of fast-food-iksh taco place less than a mile from home. it's dangerous. :) [04:47] thanks, you too [06:56] Good morning [08:13] wgrant, hey, do you think we could start langpack exports for zesty? [08:13] tuesday might be a good day for those [08:13] looking at looking at https://dev.launchpad.net/Translations/LanguagePackSchedule === fabo_ is now known as fabo [09:04] zyga: good morning! I just filed bug 1646036; I'm happy to just upload it to Ubuntu, but that would introduce a delta; i. e. it would be better (also for Debian) if you would fix that straight in Debian and we'll let it sync? [09:04] bug 1646036 in plainbox-provider-checkbox (Ubuntu) "Drop useless Recommends: pm-utils" [Undecided,New] https://launchpad.net/bugs/1646036 [09:09] Laney: hm, I really wonder why the amqp queues are so heavily lopsided towards i386 -- perhaps it helps if we shuffle "arches" in the worker? [09:10] my best guess is that each time a worker restarts (and these days they do that very often, apparently some cloud instability again) they grab the next 70 i386 requests, and this adds up [09:10] so if we randomize the arches array first, it should equalize a bit [09:12] pitti: I read the code last time and couldn't really tell why it prefers one queue over another [09:12] maybe the server always delivers the queue you connect to first? [09:12] Laney: my best guess is that "architectures = i386 amd64" in the config and we connect to the queues in that order [09:13] and that order somehow matters in the round-robin [09:16] Laney: I committed https://git.launchpad.net/~ubuntu-release/+git/autopkgtest-cloud/commit/?id=38331c768 and deployed it [09:16] Laney: in the best case it works, and in the worst case it's a no-op [09:18] pitti: I was RTFMing [09:18] sounds like it might be prefetching (that's what you were saying?) and so it could help to lower the count [09:19] Laney: I read the amqp docs a while ago, and I couldn't spot anything relevant; infinity already pointed this out at the previous glibc update, and I didn't find a "proper" solution back then [09:19] Laney: prefetch count is 1 [09:19] meh [09:19] queue.basic_qos(0, 1, True) [09:19] I see [09:20] but the only assymmetry that I can see is the ordered architecture list [09:21] that probably works around it [09:21] Laney: so the elaborate answer would be "By randomizing the input values, assymmetric distribution in the AMQP implementation is rendered irrelevant" [09:21] (real answer: "NFC, let's hack around it") [09:22] seb128, hey, need a bit of help with the migration of our last silo - can you please recycle the two reds (we're looking into why we didn't get those failures before) http://people.canonical.com/~ubuntu-archive/proposed-migration/zesty/update_excuses.html#ubuntu-settings-components [09:23] seb128, and I need guidance on what to do with unity8 just below, we have a new dependency (qml-module-qtqml-statemachine) that's in universe (it comes from qtdeclarative-opensource-src), do I need a MIR? [09:23] Saviq, clicked them, let's see how it's working out [09:24] thanks [09:24] Saviq, you don't need a MIR if the source is already in main, just land it and it's going to be listed on component mismatch and then an archive admin needs to promote the new binary [09:25] but we usually wait for the depends to land [09:25] because otherwise component mismatch lists it for demotion because then it's in main without reason [09:25] seb128, right, it's here then http://people.canonical.com/~ubuntu-archive/proposed-migration/zesty/update_excuses.html#unity8 [09:25] already waiting for the promotion [09:26] k, so your side is done [09:26] but I suppose it's waiting for the others from that silo, too [09:26] seb128, ack, thanks! [09:26] yw! [09:26] well, tests retried, let's see [09:55] pitti: looking [09:55] pitti: good morning :) [09:56] pitti: this is just more stale stuff in checkbox, I'll have someone remove it [09:56] zyga: thanks [09:56] ideally we'd be able to completely remove the package, but powernap is the only hard dependency left [09:56] kirkland: ^ who maintains that these days? [09:57] spineau, kissiel: ^^ hey, can one of you guys look at https://bugs.launchpad.net/ubuntu/+source/plainbox-provider-checkbox/+bug/1646036 please [09:57] Launchpad bug 1646036 in ubuntustudio-meta (Ubuntu) "Drop obsolete pm-utils from Ubuntu" [Undecided,In progress] [09:57] zyga: ack [09:58] kissiel: please fix it upstream and in debian, I can assist with debian side if required [09:58] Laney: I'm considering to remove the remaining amd64 glibc test requests; it's been tested on the other architectures, and realistically we won't get it all to green anyway; WDYT? [10:01] and the regressions look rather consistent on the other arches anyway, so we have enough data to go through already [10:06] sakrecoer: hey Set, how are you? I sent https://code.launchpad.net/~pitti/ubuntu-seeds/ubuntustudio.zesty.drop-pm-utils/+merge/312134 (trivial), would you have a minute to merge/pull it? [10:07] pitti: ok - will they stay as in progress forever? [10:07] Laney: yes; but I expect we'll need a force-skiptest after reviewing the regessions anyway; there are definitively some unrelated ones (I didn't review all of them yet) [10:08] the apt one looks suspicious, it started failing with new glibc [10:08] Laney: I already ran a mass-retry on armhf and s390x yesterday to weed out the flaky ones, FYI [10:10] the history on http://autopkgtest.ubuntu.com/packages/a/apt/zesty/armhf looks pretty unambiguous, but I'm confused how [10:10] - - Filesize:3 [weak] [10:10] + - Checksum-FileSize:3 [weak] [10:10] can be glibc related [10:10] pitti, tah. [10:11] xnox: good morning; WDYM? :-) [10:12] pitti, I have highlights on s390x =) and you said you mass-retried it. [10:12] oh [10:12] pitti, also i suspect that autopkgtest-build-vm does not work on s390x properly =/ as i'm failing to build a vm for qemu adt test runs. However, it might be me and my network proxy at fault. [10:12] will dig deeper into that. [10:13] xnox: ack, thanks; I don't have any machine to try this on [10:15] xnox: with pitti I got some of the blockers out of the way about 3 weeks ago, but not all [10:15] xnox: I still fixed up the tty spawning manually [10:15] ah, the serial console stuff [10:15] cpaelzer, yes that's what i have blocking me i believe. [10:15] pitti: I think we documented in the bug what would have to be done [10:15] but so far only did manually [10:15] cpaelzer, and i had to fix before, in e.g. curtin test-suite [10:16] let me search the bug for you [10:16] (use -no-defaults, specify everything "by-hand") [10:16] i'm sure things can be copy&pasted from curtin test-suite fixes i did a while back. [10:16] could this be fixed in qemu itself, that defaults and a thing like "-serial unix:..." would actually work? [10:16] xnox: bug 1630909 [10:17] seems odd having to work around this in every qemu consumer [10:17] pitti, i think it should, i have not raised it with upstream. The problem is that with x86 - qemu supports multiple consoles and that flag creates a new console. [10:18] with s390x qemu there is no multi-console support, and the one is already defined as defaults, and flags like -serial do not supplement/override the default behaviour. [10:18] i guess i should raise this with upstream. [10:18] (again) [10:18] we added extra virtio-serial back then [10:18] I think you een suggested that xnox [10:18] the bug holds all notes I had with my WIP on this [10:19] if you want to leverage anything - but it seems your own old notes covered just as much [10:19] tah! will look more into it. [10:19] ubottu net split =) === ubott2 is now known as ubottu [10:22] Laney, infinity: FTR, remaining glibc amd64 test requests killed === zbenjamin_ is now known as zbenjamin [10:27] pitti: I expected that to kill a bigger percentage of the queue :) [10:27] Laney: well, 2600 → 800 isn't to be sneezed at :) === BrAsS_mOnKeY is now known as g2 [10:30] Laney, infinity: I went through, and these cannot be trivially excluded to be unrelated: apt gnome-color-manager gspell mercurial why [10:30] * pitti creates a bug === Zic is now known as Guest2508 [10:33] infinity1: bug 1646064 === Guest2508 is now known as Zic [10:50] pitti: gtk+3.0 segfaults too [10:50] hmm [10:50] HMM [10:50] it did that with mesa also [10:52] Laney: right, but happy to add it to the list, to be safe [10:52] should at least compare a local run against -release and -proposed [10:52] bug updated [10:53] it passed when triggered by itself anyway [10:53] worrying === sil2100_ is now known as sil2100 === sil2100_ is now known as sil2100 === _salem is now known as salem_ === alan_g is now known as alan_g|lunch === alan_g|lunch is now known as alan_g === freyes__ is now known as freyes [13:19] seb128: Hey! If I have a binary package that I want in main, do all Recommends of that package have to be in main as well or is it just Depends? [13:20] ChrisTownsend, main is depends, pre-depends, recommends, built-using [13:21] xnox: Ok, thanks! [14:54] sarnold: fixed https://bugs.launchpad.net/ubuntu/+source/virt-manager/+bug/1634304 ... looks like I accidently built the sources against oringal sources that I had accidently rebuilt with newer versions... That was the reason for it being malformed. [14:54] nacc: looks like you need to rebuild php-imagick with the new imagemagick. Some of the tests rely on functions that are missing because it was built with the old version. [14:54] Launchpad bug 1634304 in virt-manager (Ubuntu) "Unable to complete install: 'Couldn't find hvm kernel for Ubuntu tree" [Undecided,Confirmed] [14:54] sarnold: rather built the debdiff against bad originals. [14:58] pitti: I suppose that's roaksoax and myself [14:58] pitti: though neither of us have touched it in forever. [14:58] pitti: what needs to be done? [14:59] kirkland: wean it off pm-utils (see bug 1646036) [14:59] bug 1646036 in ubuntustudio-meta (Ubuntu) "Drop obsolete pm-utils from Ubuntu" [Undecided,In progress] https://launchpad.net/bugs/1646036 [14:59] kirkland: we haven't used pm-utils since 15.04, it's just dead weight and its quirks can even be detrimental these days [14:59] kirkland: suspend quirks, I mean [15:00] kirkland: so for the most part it should be an exercise in sed'ing s/pm-suspend/systemctl suspend/g and the like, but I haven't checked what else it does with pm-utils [15:02] kirkland: or directly use /sys/power/state, if you don't care about userspace inhibitors (which aren't really a server thing anyway) [15:07] pitti: oh, okay -- that sounds very doable [15:08] pitti: can you stash just such a bug away against pad.lv/u/powernap ? [15:08] pitti: and I'll get to it? [15:08] kirkland: that bug already has a powernap task [15:11] pitti: cool -- #? [15:11] kirkland: bug 1646036 [15:11] bug 1646036 in ubuntustudio-meta (Ubuntu) "Drop obsolete pm-utils from Ubuntu" [Undecided,In progress] https://launchpad.net/bugs/1646036 [15:11] pitti: thanks. [15:28] pitti: could you please take a look at bug 1642966? I suspect a systemd race (as well as cups doing something possibly unnecessary). [15:28] bug 1642966 in cups (Ubuntu) "package cups-daemon 2.1.3-4 failed to install/upgrade: subprocess new pre-removal script returned error exit status 1" [High,Confirmed] https://launchpad.net/bugs/1642966 [15:28] Details in the bug. [15:28] rbasak: meeting now, queueing [15:28] ack === Guest96457 is now known as karstensrage [15:45] hello pitti! :) i'm fine, you? Thanks! Let me inform the team first, not that i don't trust you, but you know where my skills at (an inch above the bottom) :D === JanC is now known as Guest103 === JanC_ is now known as JanC [16:01] barry: thanks for your interest wrt. RFH autopkgtest! I added it to our sprint agenda next week [16:02] pitti: +1 [16:02] pitti: been thinking about doing that anyway. wish it were under happier (for us ;) circumstances [16:03] barry: so, a *python* tool for you for a change! :) [16:04] * barry can't wait to get his grubby little hands on it :) [16:05] pitti, rbasak any of you could accept https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1432935 for Trusty series? [16:05] Launchpad bug 1432935 in ntp (Ubuntu) "ntpd -x steps clock on leap second (upstream bug: 2745)" [Undecided,Fix released] [16:05] niedbalski: my queue is overflowing at the moment :-( [16:07] rbasak, it's just the series nomination, no patch yet :) [16:07] Oh. I can do that :) [16:07] Done. [16:08] rbasak, thanks! [16:37] so clearly I'm missing something (or it was too late last night when I thought of it). If I have two packages that need to be rebuilt using deps (all binary-pkgs from one specific src-pkg's in -proposed), do I need an AA to help do that? [16:38] submitting a no-change rebuild re-used what is in the release pocket [16:39] in this case, i'm referring to imagemagick + php-imagick + ruby-rmagick -- although i'm still debugging a testcase failure, the latter two need to be rebuilt agains the imagemagick in z-p [17:03] sforshee: How do you feel about having the linux-firmware package update the initramfs on install/update? There was a fair bit of "sticky" behavior that made this hard to debug and seen non-deterministic because it doesn't? [17:03] I'm testing your package now. [17:06] dmj_s76: that might be okay, linux-firmware generally isn't updated that frequently anyway [17:07] nacc: You probably need patience, not an AA. [17:08] nacc: All builds in proposed happen against proposed (if they didn't we'd never get transitions of any sort done), but you can't build against a binary until it exists in the archive, published. [17:08] nacc: ie, make sure rmadison says it's there. === infinity1 is now known as infinity [17:13] nacc, what is yakkety-devel ? [17:13] https://git.launchpad.net/~usd-import-team/ubuntu/+source/ifupdown/refs/heads?h=ubuntu/yakkety-proposed [17:25] smoser: it's the equivalent of "pull-lp-source yakkety". IIRC, that's the highest of release,security,updates. So I can base a branch from where without having to look it up. [17:26] s/where/there/ [17:26] rbasak, thats nice. kind of what i expecred, but i didnt think about security [17:26] so didnt' realize difference from -proposed [17:27] smoser: also, if there has never been a stable update, then the package won't exist in the other pockets. So you'd have to look up or get an error. [17:33] rbasak, usd build-source -v [17:33] ... [17:33] 11/30/2016 12:32:57 - DEBUG:Checking if upstream version of publish 0.7.48.1ubuntu8 matches 0.8.10ubuntu1.2 [17:33] 11/30/2016 12:32:57 - DEBUG:Checking if upstream version of publish 0.7.48.1ubuntu7 matches 0.8.10ubuntu1.2 [17:33] ... [17:33] what is that ? [17:33] Not sure. nacc? ^ [17:33] tseliot: Could you have a look at bug 1639663? [17:33] bug 1639663 in nvidia-graphics-drivers-304 (Ubuntu Xenial) "vdpau permissions incorrect in 304.132-0ubuntu0.16.04.2" [High,Confirmed] https://launchpad.net/bugs/1639663 [17:41] infinity: yeah, that's why i was confused; oh i wonder if it's because of this message about imagemagick: old binaries left on amd64: imagemagick-dbg, libmagick++-6.q16-5v5 (from 8:6.8.9.9-7ubuntu10) ? [17:42] smoser: the algorithm for caching is: [17:43] nacc: Generally not. Which package failed to pick up the new imagemagick? [17:43] smoser: for dist in ubuntu, debian: for published versions in dist, see if upstream of publish matches upstream of version to build [17:43] infinity: ruby-rmagick 2.15.4+dfsg-2build1 [17:44] infinity: oh wait! [17:44] infinity: hrm, the build used the right deps, but the autopkgtest is using the release version? [17:45] nacc: Yes, that's generally correct. [17:45] nacc: If there was an undeclared ABI break, that would indeed, break. [17:45] infinity: ok, it's a hard-dependency, though (and using the wrong imagemagick will lead to segfaults) [17:45] infinity: yeah, i think that's what's going on -- i'll see if i can suss it out in debian [17:46] infinity: in theory, then, though, could I force the dep in the tests to be the same that is built against? [17:47] nacc: We can force that on the infra side. However, that doesn't solve the bug. :P [17:47] nacc: Forcing it in the packaging means making your dependencies more strict. [17:48] nacc: If it's a question of ABI breaking, the SONAME should be bumping. If it's some more nefarious "versions must always match because $obscure_reason", dependencies need to reflect that. [17:49] nacc: Fudging any of this on the test side is the wrong way of thinking about it. The tests are rightly testing that your declared deps work. And they don't. [17:50] infinity: so, my understanding of both php-imagick and ruby-rmagick, is they link to a specific version of imagemagick's -dev libraries. That defines some ABI dependency, clearly. It only make sense (and is only possible) to test the resulting binary package using the same imagemagick to satisfy the dependencies. [17:50] infinity: I understand what you are saying, but this is probably why the autopkgtests have rarely passed on Debian :) [17:51] infinity: every imagemagick upload needs to rebuild these two packages, and only test against that version, if that makes sense [17:51] infinity: which i think implies the test dependency is wrong (too broad) [17:51] nacc: If every imagemagick upload breaks ABI, but the rdeps don't have a dependency that reflects that, imagemagick's shlibs are wrong. [17:51] nacc: The *test* dependency is correct. [17:52] nacc: If you can install the packages in this broken state, the packages are broken, not the test. [17:52] (Indeed, the test is doing its job of exposing broken packages) [17:53] infinity: yes, I see what you mean now [17:56] it's not an ABI issue [17:56] php-imagick is parsing the imagemagick version string both during compilation and during the tests and there's a mismatch [17:57] nacc, so i [17:57] so i'm confused. i did: usd build-source [17:57] mdeslaur: right, but i think ruby-rmagick's failure is different [17:57] mdeslaur: in that it's a segmentation fault in imagemagick, afaict [17:57] and it is doing all this network traffic ? [17:57] oh, perhaps, I didn't look at that one [17:58] maybe this is because its a native package [17:58] smoser: `usd build-source` is a wrapper around dpkg-buildpackage. But it needs an orig tarball, etc. to build. In the case of a native package, that algorithm may be wrong [17:59] smoser: which src pkg? [17:59] mdeslaur: so maybe there are two cases here :) one is an ABI dependency (I think) and one is a symbol dependency (of sorts -- the symbol being the version of imagemagick as defined by MagickLibVersion or whatever) [18:00] ifupdown [18:00] smoser: the algorithm also does break if it's a fully new upstream publish, as it wont' find a common ancestor (but that is also expected) [18:01] right, but it broke in that i got tired of sitting there after 60+ seconds [18:01] smoser: well, that's a usability issue :) [18:01] maybe recognize native package (no '-' in version) and special case that ? [18:02] smoser: i'm not sure it should matter, actually [18:02] smoser: ah you're right [18:03] smoser: is that check sufficient? [18:06] i'm not certain [18:07] smoser: http://paste.ubuntu.com/23559120/ or so [18:08] smoser: does that speed up your case, at least? i'll do some resarch into native package detection === robru_ is now known as robru [18:17] nacc, yes. your logging.info is missing a stirng fwiw [18:17] smoser: ack :) [18:18] smoser: sorry, this is a thinko on my part, i even documented it but forgot to put it in [18:19] smoser: i think that will trigger false positives for '-' in upstrema versions [18:20] ? [18:20] i dont think so [18:20] if there is *no* '-' in the full version, then it is a native package. [18:21] if there is a dash, then there is no upstream version to have a '-' in its version [18:21] as it is a native package. [18:21] er..we... let me re-say that. [18:21] if there is a dash, then it is not native version [18:21] smoser: err, right [18:22] smoser: yeah, ok, i think this is sufficient for now, at least [18:22] nacc: smoser, Debian policy, and dpkg all agree. Our archive disagrees occasionally (lol, linux), but those cases should be rare, and the uploaders know they're breaking the rules. :P [18:23] infinity: thanks! [18:23] nacc, [18:23] https://www.debian.org/doc/debian-policy/ch-binary.html [18:23] If punctuation is desired between the date components, remember that hyphen (-) cannot be used in native package versions. [18:23] yep [18:23] thanks! [18:24] so i guess that is not the same as what we're saying here... [18:24] hyphens cannot exist in native packages != if it does not have a -, then it is a native package. [18:24] smoser: right, it's one subset [18:25] smoser: It's indeed an exclusive rule. [18:25] smoser: so a hyphen being present means it's not native, but there is still no positive detection of native packages (beyond maybe looking debian/source/format?0 [18:25] non-native *must* have a '-' [18:25] native *must not* have a '-' [18:26] Our archive has rule-breakers (as I said), but they're few. [18:26] And totally unimportant packages, like kernels. [18:26] oh. ok. [18:26] infinity: ah you're right! [18:27] nacc, so why did that go looking on the internet (via launchpad) for a orig tarball or dsc rather than checking my nicely local lpusip/importer/debian/dsc branch [18:27] smoser: because we said all along the tooling would not rely on that [18:27] smoser: it didn't necessarily exist [18:28] well, it idd. [18:28] smoser: you're welcome to make coding changes too :) [18:28] inded [18:28] smoser: or file a feature request [18:28] ya. [18:28] smoser: but our original goal with that tool was *just* to wrap `pull-lp-source` appropriately [18:28] smoser: we added the dsc and pristine-tar branches later [18:28] right [18:29] smoser: so we could use those, now that we've decided to keep them, it seems like [18:29] and fallback to pull-lp-source/pull-debian-source when that fails to get us the rigth tarball [18:30] smoser: also not all packages have been re-imported with the DSC branch for older imports -- so it was going to complicate the code to try to use file that may or may not exist in the repo first, etc. -- not to say we can't or won't, just not a first step [18:31] smoser: lastly, i was worried about having two ways of doing things / relying on our repository to be correct for orig tarballs. I'm much more comfortable trusting Launchpad itself :) === nitesh is now known as Nitesh [18:33] smoser: pushed then native pkg fix up [18:34] nacc, and i' [18:34] and i'm sure that launchpad appreciates you pounding its api :) [18:34] for data that you had locally, all nicely and cleanly collected once. [18:35] smoser: you seem to care more about launchpad than correctness :) [18:35] smoser: i get your point, though, i think the new functionality is more stable now [18:54] hey... question [18:54] we have an 'all' arch package (curtin) and we'd like to add a dependency on a package only on one arch [18:54] info at https://code.launchpad.net/~ltrager/curtin/lp1640519/+merge/310604 [18:55] i'd like to have a depends on flash-kernel on arm64 and armhf, but not on others. [18:55] but i guess since we're only building one deb, thats not possible. [18:55] is there a solution for that ? [18:55] ltrager, ^ fyi [18:58] smoser: does this look useful? https://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps search for "restricted" [18:59] smoser: right, could you specify flash-kernel [arm64 armhf] ? [19:00] nacc, well, you cant. because it is only building one deb [19:01] ie, i'm pretty sure that is build-time not runtime [19:01] ah yes [19:01] "This means that architecture restrictions must not be used in binary relationship fields for architecture-independent packages (Architecture: all)." [19:01] yeah [19:01] thats what ltrager was seeing [19:02] i guess you're making it explicitly not architecture-independent at this point, though [19:07] infinity: mdeslaur: for ruby-rmagick, I think I see the issue, but still figuring out how to resolve it (i don't know much about ruby packaging). During the build, it prints: 'Ruby 2.3.3 (x86_64-linux-gnu) and ImageMagick 6.9.6' (which implies a dependency). And the test builds that way. But when the control file is generated later, "Depends: ruby (>= 1:2.3~0), libc6 (>= 2.14), libmagickcore-6.q16-2 [19:07] (>= 8:6.8.8.9), libruby2.3 (>= 2.3.0~preview2)" [19:10] aww :( [19:13] nacc: it's autogenerating that from the symbols file in the imagemagick package. Let me see what the failure is, one sec [19:18] nacc: nothing looks specific to the imagemagick version in ruby-rmagick. Do the ruby-rmagick tests work locally for you? [19:21] mdeslaur: right, so looking at: https://launchpadlibrarian.net/295471663/buildlog_ubuntu-zesty-amd64.ruby-rmagick_2.15.4+dfsg-2build1_BUILDING.txt.gz. The package builds against (using) the version of imagemagick in z-p. But the resulting binary packages have a dep against the imagemagick (well, at least that upstream version). You can see during the build, the tests pass (against the z-p imagemagick), [19:21] but the autopkgtests end up using the one from release, due to the dep specification? [19:22] mdeslaur: iiuc, that dep is coming from dh_shlibdeps? [19:23] sforshee: The test package works. One question, do you know why rebooting after updating the initramfs doesn't work, but a complete shutdown and cold boot does? [19:23] nacc: ah, yes, you're right, the tests are passing with the new one [19:23] nacc: yeah, that's what's adding the dep [19:26] dmj_s76: I'd guess that there's some state of the hardware that isn't getting reset on a reboot but does on a cold boot [19:29] nacc: More specifically, the dep comes from the symbols file. [19:29] nacc: In that, if all the symbols encountred are delcared at 6.8.8.9, that's the dep you get. [19:30] nacc: If some of those *changed*, that's a hard ABI break (needs a new SOVER), if new ones were added with the wrong version tag, that's just a bug in the symbols file. [19:30] infinity: i see! [19:30] infinity: Using symbols file /var/lib/dpkg/info/libmagickcore-6.q16-2:amd64.symbols for libMagickCore-6.Q16.so.2 [19:30] and that contains 6.8.8.2, 6.8.8.9, etc., but not the latest version [19:31] Well, it shouldn't contain the latest version unless the latest version introduced new symbols. [19:31] oh it does have some, you're right [19:31] so the symbols are properly version [19:31] So, that's the thing. Is your crash an attempt to call a symbol that doesn't exist in the old version? [19:32] If so, the symbols file is wrong. [19:32] If your crash is an attempt to call a symbol that exists in both, but CHANGED, then the SONAME is wrong. [19:33] i don't think it can be the former, as the ruby-rmagick source isn't changing (so it is calling a symbol that exists before and now, afaict?) [19:33] Not necessarily true. [19:33] infinity: can you explain, I don't follow the 'doesn't exist in the old version' if it worked with the old version? [19:35] nacc: When you build and link against the new version, you may pick up references to symbols that didn't exist in the old version. Your source doesn't have to change for that to happen. [19:35] nacc: Looking at the two binaries in question would help here. [19:35] * infinity grabs them quickly. [19:36] infinity: ah, of course [19:36] infinity: for my own edification, what are you looking for? symbol changes between the two binaries? what do you use to determine that? [19:43] the security team uses http://bazaar.launchpad.net/~ubuntu-security/ubuntu-security-tools/trunk/view/head:/package-tools/debcompare as part of our update process [19:44] sarnold: thanks for the pointer! [19:45] size of the GradientInfo struct changed, which then offset DrawInfo->text [19:45] nacc: FWIW, I see no meaningful differences in RMagick2.so [19:46] mdeslaur: Ew, in libmagickcore? [19:46] looks like it [19:46] That sounds like an ABI break. [19:46] magick/draw.h [19:46] which possibly explains GetTypeMetrics: Assertion `draw_info->text != (char *) NULL' failed. [19:48] mdeslaur: did you get that from debcompare? [19:49] sorry for pestering about it, but want to be able to figure this out on my own in the future, if possible :) [19:49] nacc: no, just looking at the diff between the old imagemagick and the new one [19:53] cyphermox, can you give me an example kernel cmdline that you'd expect to use with your isc-dhcp/initramfs-tools changes ? [19:54] mdeslaur: so how should/would this normally be detected/resolved? Should that symbol have been tracked? Or does it get added to an appropriate symbols file? or is the correct fix to bump the SONAME? [19:55] smoser: if you were to bring things up in an ipv6 only network; "ip=off ip6=dhcp", for example [19:57] nacc: upstream developer is either supposed to be careful it doesn't happen, or bump the so number [19:57] nacc: https://abi-laboratory.pro/tracker/compat_report/imagemagick/6.9.1-10/6.9.2-10/67f2f/abi_compat_report.html [19:57] looks like it broke in 6.9.2 [19:57] looking at all the brokenness here https://abi-laboratory.pro/tracker/timeline/imagemagick/ [19:57] doesn't inspire much confidence [19:59] mdeslaur: and the last time the debian ABI was bumped was 6.9.1.2-1 (iiuc) [20:00] https://anonscm.debian.org/git/collab-maint/imagemagick.git/commit/?h=debian/6.9.1.2-1&id=392cce49e2bfa28daff8d8de18dd62468f39fda4 [20:01] nacc: ok, that's odd...that should have worked [20:02] mdeslaur: well, shouldn't it have been bumped again when 6.9.2 was picked up (note the above is 6.9.1-2 upstream, iiuc) [20:02] nacc: yes, it should [20:02] nacc: but we went from 6.8.something to 6.9.something [20:02] so we should have gotten that bump [20:04] mdeslaur: sorry, i'm confused -- i meant, shouldn't debian have had to do more ABI bumps if upstream is changing the ABI? I see no commits in debian's VCS after 6.9.1.2-1 that change the symbols file(s)? [20:04] nacc: yes, debian should have bumped it again [20:04] nacc: _but_ debian did bump it in 6.9.1 [20:04] we went from 6.8.x to 6.9.x so we should have at least gotten _that_ bump [20:06] mdeslaur: yes, i think we did -- but if the issue you found occurred in 6.9.2, wouldn't we still hit it (the gradientinfo change)? [20:06] we would hit it if we had 6.9.1 and went to 6.9.2, yes [20:06] since we never had 6.9.1, meh [20:06] ah i see what you're saying, i think [20:07] we're lacking one of the bumps, but we have the previous one, which is newer than our previous package [20:09] ok, so debian bumped the libmagick++-6.q16-6.symbols file, but they didn't bump the libmagickcore-6.q16-2.symbols file [20:09] ah, because upstream didn't bump that library [20:10] man, this package is complicated [20:10] how many packages needed to be fixed up to switch to graphicsmagick? [20:11] sarnold: is that a (saner?) fork? [20:11] nacc: the main guy sure feels more sane; many of the issues in imagemagick he's already fixed by rewriting the ugly bits. but not all obviously or everyone would have moved over by now.. [20:12] nacc: he at least understands email and participates in oss-security mail list :) [20:12] mdeslaur: given the report you found, shouldn't upstream have bumped the core lib too? I guess they didn't want to? [20:12] sarnold: interesting -- src:imagemagick has a lot of rdeps [20:12] nacc: they should have, yes [20:13] mdeslaur: ok, so i'm guessing the right fix here is to contact debian and see if they agree and if they want to bump due to ABI breakage? [20:14] nacc: I'm not sure what the right approach is, but the struct change does affect all libraries [20:14] nacc: sounds like something to discuss with the maintainer [20:15] mdeslaur: ack, i'll start there [20:15] mdeslaur: infinity: sarnold: thank you for your patience and help! [20:16] check these beautiful commit messages, not a single "..." in sight! https://sourceforge.net/p/graphicsmagick/code/ci/default/tree/ [20:26] oi hg [20:27] heh, my first thought was "ugh sourceforge" but each their own, I guess [20:27] but seriously look at all these "..." checkins https://github.com/ImageMagick/ImageMagick/commits/master [20:27] even sourceforage _and_ hg are easier to deal with than "..." [20:29] lol [20:29] surprised they even bother with vccs [20:29] err, vcs [20:35] it sure feels like they've got their IDE or whatever configured to check in automatically after a few minutes of idle time or something [20:35] an astonishing number of commits have a chunk or two that reverts previous commits [20:35] which feels a lot like multi-level undo backing things out === salem_ is now known as _salem [22:28] hi, after latest update, which included the kernel, ssd is not recognized as bootable anymore. any help on how to resolve/diagnose appreciated [22:32] 16.10... do not remember kernel package versions... [22:32] kw1234: I think you want #ubuntu [22:34] nacc: desperate times. trying everywhere. sorry for inconvenience. [22:54]