[00:00] <nacc> mdeslaur: i've responded asking for clarification on that
[00:00] <mdeslaur> they didn't bump the other one, as you said
[00:00] <nacc> mdeslaur: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846385
[00:00] <ubottu> Debian bug 846385 in imagemagick "imagemagick: Potential ABI break upstream (without SONAME change)" [Normal,Open]
[00:00] <nacc> mdeslaur: yep
[00:00] <nacc> mdeslaur: looking at the history of both php-imagick and ruby-rmagick in debian, it's clear this broke in the update there to 6.9.*
[00:01] <mdeslaur> ah, thanks for the bug link
[00:01] <nacc> mdeslaur: and just been broken in autopkgtests for a long time now (afaict)
[00:02] <nacc> mdeslaur: i also have a handle on the remaining php-imagick bug; it might be an imagemagick regression (off by one somewhere) or it might just be a testcase error; I'm communicating with the php-imagick upstream on that one. So I think we have a handle on everything related to imagemagick, at least
[00:03] <mdeslaur> nacc: cool!
[00:04] <nacc> smoser: so i guess what one *could* do is see if there is a DSC file with the same upstream in the dsc branch? and if so, use the files entries there to know what to pull down, using pristine-tar first, and falling back to pull() if it failes?
[00:05] <nacc> mdeslaur: this seems to not be an uncommon issue, unfortunately, with imagemagick. And nobody has come up with a good solution (in debian or upstream, afaict)
[00:05] <mdeslaur> nacc: it's unfortunately a common problem with a bunch of libraries...the ABI tracking website I linked to earlier is quite depressing to browse
[00:05]  * sarnold hands nacc a jerry can of gasoline and some road flares
[00:06] <nacc> mdeslaur: sad :/
[00:06] <nacc> sarnold: appreciate it!
[01:10] <smoser> nacc, well, maybe i miss something.
[01:11] <smoser> but i'd have thought most of the time if you took this entry (top entry) and there was not something
[01:11] <smoser> but the next entry was same upstream, and there *was* a dsc you could probably use that.
[01:12] <smoser> i think that would work for all cases that asking launchpad would (in the event of an up to date dsc and pristine tar data in the git repo)
[01:27] <nacc> smoser: hrm, that's a good idea
[01:28] <nacc> smoser: i'll see if i can code that up tmrw
[03:07] <sarnold> nedbat in #ubuntu-server points out duplicated text on http://releases.ubuntu.com/xenial/ -- "Desktop image" is in there twice, and "Server install image" three times
[03:09] <sarnold> can anyone recall which project to report bugs against for the releases.ubuntu.com texts? I can't remember any more :(
[03:45] <krytarik> sarnold: 'ubuntu-cdimage' - and there is definitely something off there, yep.
[03:51] <sarnold> thanks krytarik, https://bugs.launchpad.net/ubuntu-cdimage/+bug/1646335  :)
[03:51] <ubottu> Launchpad bug 1646335 in Ubuntu CD Images "duplicated text on http://releases.ubuntu.com/xenial/" [Undecided,New]
[04:07] <krytarik> sarnold: There is also .img vs .iso on the server images there, btw - but then the 16.04.1 one is missing at the top, which is also indicated by the generic description on it in the directory tree - so yeah.. :P
[04:56] <masber> hi
[04:56] <masber> not sure if this is the right place to ask this
[04:56] <masber> the host key on 2 of my ubuntu servers have changed
[04:57] <masber> I saw that python-cryptography (1.2.3-1ubuntu0.1) has been updated by the unatended updates
[04:57] <masber> would that be the reason of the key changes?
[05:05] <krytarik> masber: Try #ubuntu-server and/or #ubuntu.
=== marcusto_ is now known as marcustomlinson
[05:13] <masber> I asked them too #ubuntu-server nobody replies and no one has any idea in #ubuntu
[05:13] <masber> krytarik, I was hoping that the devel channel may have an idea
[05:14] <masber> I also asked in the #canonical-sysadmin
[05:14] <masber> anyway let see if I am lucky
[06:53] <cpaelzer> good morning
[07:55] <pitti> Good morning
[07:55] <cpaelzer> hi pitti
[07:56] <pitti> hey cpaelzer, wie gehts?
[07:56] <cpaelzer> still fine, the day hasn't unleashed anything unexpected yet
[07:57] <pitti> haha
[07:57] <cpaelzer> pitti: you might have a qick answer for me, last week we discussed on rerolling a libvirt SRU to use an apparmor abtraction instead
[07:58] <cpaelzer> pitti: that all is done in zesty, ready for re-upload SRU into Xenial
[07:58] <cpaelzer> pitti: since the old was rejected in the queue - can I reuse the version number I had?
[07:58] <cpaelzer> I think yes
[07:58] <cpaelzer> and I asked the same a while ago for a different case - but --force always makes me feel uncomfortable :-)
[07:59] <pitti> cpaelzer: yes, you can
[07:59] <cpaelzer> thanks for the confirmation
[07:59] <pitti> cpaelzer: the version number only gets committed/taken once a package gets accepted
[07:59] <pitti> rejecting from the queue == it never happened
[07:59] <cpaelzer> yet dput complains except you --force it
[07:59] <pitti> you can even have multiple different uploads of the same versino number in a queue at the same time
[08:00] <pitti> which is utterly confusing (archive admins then usually take the youngest one and reject the older ones)
[08:00] <pitti> cpaelzer: complains how? dput can't  even read queues
[08:00] <cpaelzer> pitti: "Package has already been uploaded to ubuntu on upload.ubuntu.com"
[08:00] <cpaelzer> is that just a local file then
[08:00] <pitti> cpaelzer: oh -- delete your .upload stamp file
[08:02] <cpaelzer> nice, now I understand where this came from
[08:07] <cpaelzer> dholbach: good to see you, on the pilot'ing I got your mail but haven't received any "invitation" and can#t find myself in the calendar you linked
[08:07] <cpaelzer> dholbach: am I supposed to enter myself in there?
[08:08] <cpaelzer> dholbach: the other entries I see always have the pilot as guest in the event, so I'd have expected to also see a calendar invite
[08:08] <cpaelzer> dholbach: at least I found myself now (in Decmember 19th)
[08:08] <cpaelzer> 20
[08:09] <cpaelzer> dholbach: I can surely copy to my calendat or so, but did I miss an invite or would there conceptually be no invite the way the schedule is set up?
[08:29] <dholbach> cpaelzer, that's strange - you should have it in your calendar
[08:29] <dholbach> let me check
[08:30] <cpaelzer> dholbach: I copied it for now, but I wondered why it didn't show up on its own
[08:30] <dholbach> it should
[08:30] <dholbach> cpaelzer, I added your canonical.com address as guest to the event
[08:36] <cpaelzer> dholbach: maybe a typo somewhere?
[08:36] <dholbach> did you receive an email?
[08:36] <cpaelzer> dholbach: not one related to the invite
[08:36] <dholbach> bizarre
[08:37] <cpaelzer> but I got your invitation mail, so did the email you used for both come from the same source?
[08:59] <Saviq> seb128, can I do anything to speed http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity8 up? the current unity8 version in zesty now fails autopkgtests because part of the silo migrated already (and apparently we don't have enough Breaks: in our packages...)
[09:11] <pitti> Saviq: I think the correct reason would be "fails because it does not run its tests against other proposed packages", FTR; robru just discovered that the lockstep migration does not seem to work, but that comes after tests
[09:12] <pitti> Saviq: so I figure re-running the tests against all of -proposed should work
[09:12] <pitti> oh, it didn't even get that far
[09:12] <Saviq> pitti, well, yes, that's correct
[09:12] <pitti> it's uninstallable -- well, that needs to be fixed first, obviously
[09:13] <pitti> qml-module-qtqml-statemachine | 5.6.1-7ubuntu2~1 | zesty/universe   | amd64, arm64, armhf, i386, powerpc, ppc64el, s390x
[09:13] <Saviq> pitti, yup, there's a new Depends that's not in main
[09:13] <pitti> ^ needs to be moved to main
[09:14] <pitti> which is trivial, as the source is already in main
[09:14] <Saviq> yup :)
=== grumble is now known as BlockOfIce
[09:40] <Laney> did anyone notice / look into sbuild becoming slow on zesty lately?
[09:41] <Laney> It's taking on the order of 1 minute to even start installing build deps for me
[09:43] <pitti> Laney: for me it's bug 1626436, and I've heard from at least two other people that it was the same for them
[09:43] <ubottu> bug 1626436 in linux (Ubuntu Yakkety) "[4.8 regression] boot has become very slow" [High,In progress] https://launchpad.net/bugs/1626436
[09:44] <pitti> Laney: that bug has a test kernel, it's worth trying that
[09:44] <pitti> Laney: is booting and shutdown  also painfully slow for you?
[09:44] <pitti> but that got introduced around yakkety beta already
[09:44] <Laney> pitti: booting is always slow for me because I have a drive that fails to initialise the first 3-4 times, so hard to tell :-)
[09:45] <Laney> and as for shutting down, I'm out of the room already :P
[09:45]  * Laney will try the kernel though --- could have been slower in yakkety already
[09:45] <Laney> thanks for the tip
[09:47] <pitti> Laney: ah, I always wait so that I can flip the switch box off
[09:47] <pitti> nothing like an actual physical "power off" switch :)
[09:49] <Laney> I should probably replace that drive
[09:49] <Laney> "Startup finished in 1min 21.824s (kernel)"
[09:49] <Laney> /o\
[09:50] <pitti> ugh
[09:50] <pitti> Laney: when I disable lightdm and NM (which are fairly unpredictable), the 4.4 kernel boots in 6s, the 4.8 kernel boots in 25
[09:51] <Laney> pitti: trying the latest one from that bug
[09:53] <Laney> stupid wget respecting robots.txt :-)
[09:55] <jtaylor> :( virtualbox does not build its module with the 16.04 hwe-edge (4.8)
[10:02] <ginggs> Laney: not sure if this related to slowness, but i found https://launchpad.net/ubuntu/+source/blockdiag/1.5.3+dfsg-1 seems to start building and thendies without leaving a log
[10:04] <Laney> hey ginggs
[10:05] <Laney> I think the builders are on 4.4 kernels, and this is apparently a 4.8 regression
[10:05] <Laney> if it happens again after a retry then maybe go ask in #launchpad
[10:05]  * Laney reboots to shiny new kernel
[10:09] <Laney> pitti: certainly *seems* better
[10:09] <Laney> thanks for the tip!
[10:10] <pitti> Laney: yay
[10:11] <pitti> Laney: it's good to know that we don't have multiple different regressions in that regard
[10:13] <ginggs> thanks Laney I'll do that
[10:45] <pitti> Laney: oh btw, there's one thing which you might not yet be aware of and which we need to sort out
[10:46] <pitti> Laney: our CI infra doesn't run autopkgtest and autodep8 out of their anonscm.debian.org git branches, as there is no <censored> way to get to this from a Prodstack instance (you know the pain)
[10:46] <pitti> Laney: so I have some LP mirrors of these repos (https://code.launchpad.net/~pitti/+git)
[10:47] <pitti> Laney: right now I push to these manually, but as nobody else can, we should fix this
[10:47] <pitti> cjwatson: is it possible to have an automatic git branch import from a remote git branch in LP, similar to how we make automatic bzr imports of remote gits?
[10:47] <Laney> isn't this the thing that just got launched recently?
[10:48] <pitti> automatically mirroring https://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git on something like ~ubuntu-release/git/autopkgtest.git would be useful
[10:48] <Laney> http://blog.launchpad.net/code/git-to-git-imports
[10:48] <pitti> !
[10:48]  * pitti loves retroactively fulfilling our needs, you guys rock
[10:49] <pitti> when I wrote that stuff I checked for that and it didn't exist yet, so I resorted to this ugly manual method
[10:49] <pitti> meh, I don't have any control over https://launchpad.net/autopkgtest
[10:51] <Laney> pitti: you can do it under any team (https://code.launchpad.net/+code-imports/+new)
[10:51] <Laney> https://code.launchpad.net/~ubuntu-release/autopkgtest/+git/autopkgtest
[10:51] <pitti> cjwatson, wgrant: could we change the owner of https://launchpad.net/autopkgtest to ~ubuntu-release or ~ubuntu-core-dev? or at least make Laney and me an admin?
[10:52] <pitti> Laney: yay, thanks; want to flip that in the deployment scripts and on the actual deployments too, or want me to?
[10:52] <pitti> Laney: (I have time, just wondering about the hand-over aspect)
[10:54] <Laney> pitti: I can probably do it
[10:54] <pitti> Laney: https://code.launchpad.net/~ubuntu-release/autopkgtest/+git/autodep8
[10:54] <pitti> cjwatson: unping, and thanks for adding this feature!
[11:02] <Laney> pitti: just git remote set-url?
[11:02] <Laney> are these automatically pulled somehow?
[11:02] <pitti> Laney: yes, should work; no, so far I pull them on demand
[11:03] <pitti> Laney: but I wouldn't mind a cron job to pull that and the autopkgtest-cloud branch automatically
[11:03] <pitti> Laney: this is assuming that master never breaks :) (but that shouldn't happen that often)
[11:03] <pitti> Laney: thanks, now "git grep pitti" looks sane ;)
[11:04] <pitti> (in autopkgtest-cloud)
[11:05] <Laney> and if you hax0r into the VPN you can still SSH to things ;-)
[11:06] <pitti> /msg #nsa hey guys, how do I hack openvpn again?
[11:07] <pitti> Laney: I deleted the ~pitti branches
[11:07] <Laney> need to do the lxds and s390xs
[11:12] <Laney> & done
[11:12]  * Laney coffee &
[11:41] <jgdx> hey, could anyone take a look at these failures [1]? They seem unrelated, pass locally with silo 2194 (which is in proposed). [1] http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ubuntu-themes
[11:42] <jgdx> okay, and those tests are apparantly fixed in https://bileto.ubuntu.com/#/ticket/2244
=== alan_g is now known as alan_g|lunch
=== _salem is now known as salem_
=== __alecu__ is now known as alecu
[12:34] <jgdx> seb128, hey, could you take a look^? unity8 is stuck in proposed, which causes the unity8 test failures for u-themes and uss
[12:34] <seb128> wasn't pitti looking at it?
[12:34] <seb128> he discussed earlier with Saviq
[12:35] <Saviq> he said it was "trivial", kinda what you said yesterday, but not sure anybody actually acted on it :)
[12:36] <seb128> I'm still on xenial and trying to avoid looking at zesty atm
[12:36] <seb128> I though doko or somebody who usually watch component mismatch would pick it up
[12:38] <pitti> no, I didn't run the change-override; I'm trying to slowly wean myself off of archive admin
[12:38] <doko> seb128: sorry, this is not that easy anymore. previously these thing would show up as dep-wait. we don't have good information about component mismatches in update_excudes
=== BlockOfIce is now known as grumble
[12:39] <seb128> doko, is that due to the citrain workflow?
[12:39] <doko> no, archive reorg, having universe b-d's
[12:39] <Laney> it's because component-mismatches-proposed doesn't mail
[12:43] <seb128> doko, can you try to help Saviq and jgdx to unblock unity8? I don't have the auth keys on the machine I'm currently hacking from to run the commands
[12:44] <doko> seb128: well, if you tell me about what is the problem?
[12:45] <seb128> some new qt binary needs to be promoted but I forgot the name
[12:45] <seb128> Saviq, jgdx, ^ can you tell doko what needs to be moved out of universe?
[12:46] <Saviq> doko, qml-module-qtqml-statemachine
[12:46] <Saviq> it's a binary from qtdeclarative5-opensource-src, which is already in main, so there should be no controversy
[12:47] <jgdx> seb128, thanks for picking it up! But i'm not sure what you're asking? I'm trying to land 2194.
[12:47] <seb128> jgdx, Savig just gave the info needed it's ok
=== alan_g|lunch is now known as alan_g
[12:48] <jgdx> ok, thanks
[12:50] <doko> seb128, Saviq: done
[12:50] <seb128> doko, thanks
[12:50] <Saviq> doko, thanks!
[12:50] <doko> seb128: is there a plan to fix the qt* related build failures on i386? qtsvg-opensource-src and qtxmlpatterns-opensource-src
[12:52] <seb128> doko, no idea but maybe Saviq knows
[12:53] <Saviq> first I heard, we can have a look, doko, what do we look at?
[12:53] <doko> Saviq: as always: http://qa.ubuntuwire.com/ftbfs/  that shouldn't be news, or is it?
[12:54] <seb128> it's a pull thing
[12:54] <Saviq> doko, we're not as close to the archive as we should be ;)
[12:54] <seb128> you can't expect devs to regularly open random reports to see what issues might be listed
[12:57] <doko> and even if issues are opened as for location-service ...
[12:58] <Saviq> doko, AFAIU it's the same issue as everywhere else, it's a dependency wait on qtbase 5.7.1 - not sure why it's interpreted as build failure here, but depwaits on other arches
[13:01] <Saviq> basically none of it will move until we publish 5.7 of qtbase, qtdeclarative etc. - which Timo was preparing in https://bileto.ubuntu.com/#/ticket/1985
[13:43] <Laney> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#gdal what's it talking about there?
[13:44] <Laney> oh, just copied, maybe it was still in the wormhole
[13:49] <xnox> barry, ubiquity/misc.py:152:5: E741 ambiguous variable name 'l' -> it really isn't, because mark spent $$$ on ubuntu-monospace font that renders iI1l without albigiouties.
[13:57] <cjwatson> pitti: it's been a popular feature already :)
=== Pici` is now known as Pici
=== jamespag` is now known as jamespage
[14:38] <barry> xnox: yeah, that's a new one that's bitten at least one other person recently
[16:27] <nacc> mdeslaur: not sure what to do about imagemagick given debian's response?
[16:28] <mdeslaur> nacc: I'm not sure either...bumping the so just in ubuntu doesn't seem sane. The other thing we could do is manually add a versioned depends to the ruby-rmagick package
[16:28] <nacc> mdeslaur: but I guess this is why php-imagick and ruby-rmagick do all the (sort of odd) at runtime checking of imagemagick versions
[16:28] <mdeslaur> infinity: your infinite wisdom would be valuable ^
[16:39] <nacc> mdeslaur: ha! was it all a timing thing? that is, it passed on amd64 with the rebuild...
[16:39] <nacc> mdeslaur: i wonder if the backlog actually helped here?
[16:40] <mdeslaur> nacc: oh, how curious
[16:40] <mdeslaur> nacc: perhaps
[16:40] <mdeslaur> nacc: did you mash the retry buttons for the other archs?
[16:40] <nacc> mdeslaur: i'm trying one now
[16:42] <nacc> mdeslaur: so i think php-imagick would also need a rebuild / needs to be fixed up for that one testcase still.
[16:43] <mdeslaur> I guess so, yeah
[17:16] <nacc> mdeslaur: this is really strange: http://autopkgtest.ubuntu.com/packages/r/ruby-rmagick/zesty/amd64 there's no entry for build1?
[17:16] <nacc> mdeslaur: but excuses has a link to a passing test using build1?
[17:17] <nacc> mdeslaur: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/amd64/r/ruby-rmagick/20161201_091333_f7d6e@/log.gz
[17:17] <attente> would it be possible to backport the bubblewrap package to xenial?
[17:20] <nacc> mdeslaur: and if i retrigger, e.g. ruby-rmagick on armhf, it seems to succeed (although I don't see the request show up in the main autopkgtest page for the pkg, maybe expected; but then I don't have anyways to see the logs to verify?
[17:38] <mdeslaur> nacc: weird...maybe it takes a while to refresh
[17:43] <nacc> mdeslaur: yeah, could be
[17:44] <nacc> mdeslaur: i'll be more patient and see :)
[17:50] <nacc> mdeslaur: ok, i just verified manually that using -proposed, ruby-rmagick does pass on ppc64el at least
[17:50] <nacc> mdeslaur: will see if i can get autopkgtest to reflect that :)
[17:51] <mdeslaur> cool
[17:55] <doko> apw, ogasawara: is linux 4.9 ready to migrate, or will that still take some time? asking because I'd like to start a test rebuild tomorrow
[17:56] <ogasawara> doko: I will hand you to rtg and sforshee for that
[17:56] <coreycb> bdmurray, rbasak, hi could one of you do me a favor and reject the ironic-inspector upload to the yakkety queue from ~31 minutes ago?
[17:56] <ogasawara> doko: they are fixing build issue with our tools directory at the moment, but then should be ready to hopefully promote after that
[17:56] <rbasak> Sure
[17:57] <ogasawara> doko: but I don't now if that will be ready by tomorrow
[17:57] <rbasak> Done.
[17:57] <doko> ok, maybe I just copy it to a ppa, I'm only interested in linux-libc-dev
[17:57] <coreycb> rbasak, thanks
[18:21] <nacc> infinity: so i'm really confused by this: rubyrmagick 2.15.4+dfsg-2build1 succeeded on amd64 but not on any other archs. On amd64 it used the imagemagick in z-p to satisfy the deps (hence it passed). On all other archs it failed. But if I retrigger the run on the other archs, it still shows up as failed (and I'm not sure where to go for the logs for the rerun -- they don't show up in e.g.
[18:21] <nacc> http://autopkgtest.ubuntu.com/packages/r/ruby-rmagick/zesty/armhf)
[18:24] <infinity> nacc: That might mean someone manually retried it with proposed enabled for am64.
[18:24] <infinity> nacc: Except I don't see it succeeding?
[18:24] <infinity> http://autopkgtest.ubuntu.com/packages/ruby-rmagick/zesty/amd64
[18:24] <nacc> infinity: yes, it's very strange!
[18:24] <nacc> infinity: but look at excuses
[18:25] <nacc> infinity: it feels like some state is missing or lost? https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/amd64/r/ruby-rmagick/20161201_091333_f7d6e@/log.gz is the successful run (per excuses' link)
[18:25] <nacc> or maybe simply delayed, i'm not sure
[18:26] <infinity> Could be a delayed UI thing, yeah.
[18:26] <infinity> nacc: Anyhow, if the concensus is that we handwave past this, I can retry all the arches with all-proposed, ick.
[18:27] <nacc> infinity: if amd64 had been run with -proposed, would i be able to see that in the log? what i see is "'--env=ADT_TEST_TRIGGERS=ruby-rmagick/2.15.4+dfsg-2build1 imagemagick/8:6.9.6.6+dfsg-1ubuntu2'"
[18:27] <nacc> infinity: but nothing else (and that specific trigger combination seems to be what is missing on all the other archs?)
[18:28] <infinity> Ahh.
[18:28] <infinity> Yes, someone ran it with a double-trigger.
[18:28] <infinity> That would "fix" it.
[18:29] <nacc> infinity: i'm also happy to change the deps manually in both php-imagick and ruby-rmagick to depend on a more recent imagemagick, given debian's pushback on the ABI argument
[18:29] <nacc> infinity: i'm just not sure on the 'right' solution
[18:29] <infinity> nacc: Changing the deps manually in the rdeps is not right.
[18:30] <infinity> Where was the Debian discussion?
[18:30] <nacc> infinity: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846385
[18:30] <ubottu> Debian bug 846385 in imagemagick "imagemagick: Potential ABI break upstream (without SONAME change)" [Normal,Open]
[18:31] <nacc> infinity: so the double-trigger had to be run manually by someone? anyway to figure out who? as it wasn't me, given i don't know how :)
[18:33] <infinity> I think the queue probably logs somewhere, I'm not sure where. :P
[18:33] <nacc> infinity: ok :)
[18:33] <mdeslaur> oh, there's a new comment on the debian bug
[18:34]  * mdeslaur investigates
[18:34] <nacc> mdeslaur: afaict, debian saying there is no ABI breakage, except for interpreted languages, which should do more checking
[18:34] <mdeslaur> yeah, I'm looking now
[18:35] <nacc> coreycb: thanks for the feedback on python-django
[18:35] <nacc> jgrimm: --^ so i think we just need maas to provide input in that bug?
[18:36] <infinity> The problem with declaring it not an ABI break is that you can't really express it in dependencies.
[18:36] <infinity> So we're stuck with just telling people to upgrade wholesale or be broken.
[18:36] <jgrimm> nacc, agreed
[18:37] <nacc> infinity: right, it feels like these 3 packages now have to upgrade together or not at all
[18:37] <infinity> (Yes, we can say new ruby-rmagick depends on libimagickcore (>= foo), but preventing the old ruby-rmagick from using the new lib means adding Breaks to the new libimagickcore... Doable, but gross)
[18:37] <infinity> Anyhow, we also aren't hugely invested in partial upgrades being perfect (unlike, ironically, Debian), so we can probably handwave past this after I re-run the tests against proposed.
[18:38] <infinity> At least, for leafy packages like this.
[18:38] <infinity> Partial upgrades MUST work well enough to not blow up a machine *during* upgrade, but ruby/php-imagick probably don't count in that set.
[18:39] <nacc> infinity: that makes sense to me
[18:39] <nacc> infinity: so that can be run, if you're comfortable, for ruby-rmagick; I'll see if I can get a betterhandle on php-imagick
[18:39] <infinity> nacc: Yeah, tests retriggered for ruby-rmagick and ruby-gruff.
[18:39] <nacc> infinity: the -proposed run is needed there too, but also a fix is needed (working with upstream hopefully today on that)
[18:39] <nacc> infinity: thanks!
[18:41] <infinity> nacc: I'm not super happy with Debian's response here, but the exposure (a webapp might have a mild hissy fit during the upgrade window) also doesn't seem worth us violently diverging for.
[18:41] <nacc> infinity: agreed, I was surprised at the pushback
[18:51] <nacc> infinity: it does mean, I think, this kind of intervention should be expected going forward too, though :/ Is there a place to document cases like this?
[18:52] <infinity> nacc: In the uploader's head, I suspect. :P
[18:53] <nacc> infinity: heh, ok :)
[18:53] <nacc> infinity: would this be the sort of thing (let's say in a future merge?) to document in the changelog itself so it's known to all developers?
[18:53] <infinity> nacc: You could also fudge the deps, which would "document" it.
[18:53] <nacc> infinity: right
[18:53] <infinity> nacc: But only if you can manage to push that back to Debian, IMO.  Not worth a delta for.
[18:54] <infinity> ie: you could just make ruby-rmagick always depend on libmagickcore >= built-using-version, overriding the shlibs version.
[18:55] <infinity> Doesn't actually fix anything, but at least would sort the testing.
[18:55] <nacc> infinity: yep, I think that's what should be done -- i'll submit a patch to debian for both packages
[18:55] <infinity> Or, rather, doesn't actually fix the upgrade issues.
[18:56] <infinity> But I feel like asking the imagemagick maintainers to track these breaks and add "Breaks: php-imagick (<< foo), ruby-rmagick (<< foo)" to new imagemagick uploads is a thing that's not going to happen.
[18:56] <infinity> So meh.
[18:56] <nacc> right
[18:59] <nacc> infinity: is 'built-using-version' an actual thing? or would that be a hardcoded value for that specific build?
[18:59] <infinity> nacc: It's not an actual thing.  You'd have to divine it via dpkg at build time.
[18:59] <nacc> infinity: right
[19:00] <nacc> infinity: i think this is actually debian bug 591419
[19:00] <ubottu> Debian bug 591419 in ruby-rmagick "librmagick-ruby should not be installable with imagemagick" [Normal,Open] http://bugs.debian.org/591419
[19:01] <nacc> the last comment, sadly, from 6 years ago
[19:02] <infinity> nacc: Keeping it very strict, as suggested, might be a plan.
[19:03] <infinity> Doesn't help the past, but would improve the future.
[19:03] <infinity> For super funzies, to do this without any hardcoding, you'll need to emulate bits of dpkg-shlibdeps
[19:03] <nacc> infinity: ack
[19:04] <nacc> infinity: yeah, i was going to look at what it does under the cover :)
[19:04] <nacc> infinity: thanks again for all your help!
[19:04] <infinity> ie: "ldd path/to/new/plugin.so | grep magickcore | dpkg -S"
[19:04] <infinity> nacc: Well, it's much more clever than what I typed above, but that would get the job done.
[19:05] <nacc> infinity: yeah, makes sense
[19:05] <infinity> nacc: The key here being that you don't want to hardcode the package that contains the library because SONAME bumps will drive you batty.
[19:05] <nacc> infinity: right :)
[19:06] <bdmurray> Laney: Oh did your second upload of glib2.0 actually have Launchpad-Bugs-Fixed in it?
[19:07] <bdmurray> Laney: If so I rejected the wrong one. :-(
[19:08] <infinity> nacc: And if you care about cross-building, use 'readelf -d path/to.so | grep NEEDED' instead of ldd, but then you get to resolve the path by hand (or hope there's only one libfoo.so.N on the system).
[19:09] <nacc> infinity: thanks! jotting this all down
[19:09] <infinity> nacc: (ldd and just skipping the dep if the result is empty is probably the easier route, since neither we nor Debian build the official archive cross, and the dep being slightly wrong for home-built cross setups doesn't really matter)
[19:15] <infinity> nacc: For example: $ ldd /bin/mv | grep '/libc\.' | awk '{print $3}' | xargs dpkg -S | awk '{print $1}' | sed 's/:$//' | xargs dpkg -l | awk '/^.i/ {print $2 " (>= " $3 ")"}'
[19:15] <infinity> nacc: Ish.
[19:16] <infinity> nacc: Some of that can be squished into shorter awks without the greps and seds. :P
[19:17] <infinity> (Also, I'm a terrible person, no need to confirm)
[19:17] <infinity> Well, longer awks, shorter overall code.  You know what I mean.
[19:25] <mdeslaur> infinity: wouldn't it be better to just do a dpkg -l libmagickcore-dev, since it's those header files that it's actually using?
[19:25] <nacc> infinity: understood :) (sorry, was otp)
[19:26] <bdmurray> coreycb: aodh 3.0.1 isn't in Zesty yet .. bug 1645772
[19:26] <ubottu> bug 1645772 in nova (Ubuntu Yakkety) "[SRU] newton stable releases" [Undecided,New] https://launchpad.net/bugs/1645772
[19:26] <infinity> mdeslaur: You're assuming that package will always exist.
[19:27] <coreycb> bdmurray, ok thanks we'll get that in
[19:27] <infinity> mdeslaur: (given it's marked as a "transitional" right now, I'm skeptical)
[19:27] <infinity> mdeslaur: Well, also, the *dep* needs to be on the binary library package. :P
[19:27] <mdeslaur> I meant just to get the version string
[19:27] <infinity> mdeslaur: But the version string of what, exactly?
[19:27] <mdeslaur> yeah, if you're generating the package name too, I see what you mean
[19:27] <infinity> mdeslaur: We still need to know the binary package name.
[19:27] <mdeslaur> right
[19:28] <infinity>  ldd /bin/mv | awk '/\/libc\./ {print $3}' | xargs dpkg -S | awk '{print $1}' | sed 's/:$//' | xargs dpkg-query -W -f='${Package} (>= ${Version})\n'
[19:28] <infinity> nacc: ^-- There, cause I can't leave well enough alone once I start playing with a shell pipe.
[19:28] <infinity> I feel like that sed could turn into a gsub, but awk and I don't agree on how to find the end of a line.
[19:28] <infinity> Or, rather, I don't seem to recall how.
[19:28] <attente> is there a reason why 'apt-file search intltoolize' no longer works? i'm pretty sure this used to work up until very recently
[19:29] <infinity> attente: apt-file update?
[19:29] <attente> infinity: did that
[19:30] <infinity> It's possible we don't ship intltoolize. :P
[19:30] <infinity> It works for, say, libtoolize.
[19:31] <dobey> we ship intltoolize
[19:31] <dobey> it'well, we ship intltool
[19:31] <attente> infinity: if i do 'apt-file search libtoolize', it doesn't show /usr/bin/libtoolize either
[19:31] <attente> even though it shows a few other results
[19:32] <infinity> dobey: Yeah, we sure do.  I have it installed even.
[19:32] <infinity> attente: Curious.
[19:32] <attente> infinity: it's just me though? is apt-file working for you?
[19:32] <infinity> attente: Nope, same results here.
[19:33] <attente> infinity: i thought i was going mad for a while there :)
[19:33] <infinity> Our apt-file is also wildly out of date.
[19:33] <infinity> Perhaps it could use a kick.
[19:54] <coreycb> bdmurray, can you reject aodh 3.0.1 please?
[19:54] <bdmurray> coreycb: done
[19:54] <coreycb> bdmurray thanks
[20:00] <coreycb> bdmurray, sorry can you reject aodh 3.0.1 again?  i meant to use zesty.
[20:01] <bdmurray> coreycb: hmm, misclicked there.
[20:01] <coreycb> bdmurray, np
[20:14] <dobey> hmm
[20:14] <dobey> seems something in new glibc is causing stuff to crash? :(
[20:15] <infinity> dobey: There's a reason it's still in proposed.
[20:16] <infinity> dobey: Do you have specific stuff crashing?
[20:16] <infinity> dobey: I'm investigating, but more testcases won't hurt.
[20:16] <dobey> infinity: indicator-keyboard tests are crashing during build in PPA. i see segfaults in the gtk+3.0 autopkgtests on update_excuses too
[20:17] <dobey> (PPA that has proposed enabled)
[20:17] <doko> dobey: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1646064 is used for tracking
[20:17] <ubottu> Launchpad bug 1646064 in glibc (Ubuntu) "investigate autopkgtest regressions in 2.24-7ubuntu1" [Undecided,New]
[20:17] <infinity> I'm pretty sure I know the cause of most of them, and have test packages here that I'm about to kick the tires on.
[20:19]  * infinity gets to tire-kicking.
[20:20] <coreycb> bdmurray, ok aodh should be all set now, uploaded 3.0.1 to zesty and a new one to the yakkety queue
[20:35] <dobey> infinity: well i can't seem to get indicator-keyboard to crash locally. no idea why :-/
[20:36] <infinity> dobey: With a chroot updated to proposed?
[20:36] <infinity> dobey: Oh, try running in C.UTF-8 too, since I'm betting that's what's buggy. :P
[20:37] <dobey> hmm
=== salem_ is now known as _salem
=== _salem is now known as salem_
=== salem_ is now known as _salem
[20:55] <dobey> infinity: hrmm, ok, managed to get it to crash now (though not 100% sure how) and it's dying in a g_variant_get_uint32() call
[20:56] <dobey> infinity: http://pastebin.ubuntu.com/23564864/
[20:56] <dobey> (and that's inside vala-generated C)
[20:59] <dobey> so yeah, this crash makes no sense to me
[21:34] <infinity> dobey: If you can figure out how you reproduced, that would be nice.  I'm having a hard time reproducing some other regressions here too.
[21:35] <dobey> infinity: well, pulling lp:indicator-keyboard and running ./autogen.sh && make -j8 && make check results in a crash. but i'm not sure what would be possibly causing it. the last things i installed from proposed before it started crashing, were the systemd and sqlite3 updates
[21:35] <dobey> before that the tests would run just fine :-/
[21:36] <infinity> Huh.
[21:37] <dobey> hmm, oh actually i guess that trace is wrong. as it's the trace for a SIGTRAP on the client side of the dbus connection, and the server side crashed with a SEGV
[21:37] <dobey> grr
[21:38] <dobey> not sure how to gdb that side of it :-/
[21:44] <dobey> oh fun, so i need to tweak the service file to run it under gdb
[21:50] <dobey> how does one actually get a core file these days?
[21:54] <jtaylor> dobey: if apport does not spit one out (in /var/crash) you can change /proc/sys/kernel/core_pattern
[21:57] <dobey> jtaylor: how do i make apport work inside an lxc container, though?
[21:57] <jtaylor> dobey: no idea, I just turn of the apport indirection on containers hosts
[21:57] <jtaylor> you probably need apport installed in the container than it might work as usual
[21:57] <jtaylor> s/on/off/
[21:58] <dobey> i installed apport in the container, and ran /etc/init.d/apport start, and it didn't collect a core
[22:01] <jtaylor> do you have core files limited via e.g. ulimit?
[22:01] <dobey> i have whatever the defaults in ubuntu are
[22:01] <jtaylor> why do you need apport?
[22:01] <dobey> i don't. i need a core file from a dbus server process
[22:02] <jtaylor> and you can't change the core_pattern?
[22:02] <dobey> change it to what?
[22:02] <dobey> |/usr/share/apport/apport %p %s %c %P
[22:02] <dobey> that is the current value
[22:03] <jtaylor> e.g. core.%e.%u.%P
[22:03] <jtaylor> see man core
[22:03] <jtaylor> that just dumps a core in the cwd
[22:04] <jtaylor> also make sure its not limited, e.g. via ulimit -c unlimited, there is probably a systemd setting for that somewhere if its a service
[22:05] <dobey> i guess i have to do that on the host
[22:05] <jtaylor> changing the core pattern probably, the guest sees the same value but might not be able to change it
[22:06] <jtaylor> I don't think that is a thing that is namespaced
[22:06] <dobey> but no, that doesn't seem to help
[22:44] <dobey> infinity: ok, looks like it's glx causing a crash inside gdk: http://pastebin.ubuntu.com/23565173/
[22:44] <dobey> whee mesa
[22:46] <dobey> sscanf on a NULL, fun
[23:47] <nacc> mdeslaur: infinity: so this works, but isn't fully correct yet: http://paste.ubuntu.com/23565429/. I'm wondering if that's better than just calling dh_shlibdeps and appending to the file manually? (I tested that by hand earlier and it worked). For some reason (still debugging), even though dpkg-shlibdeps documents it, the debian/ruby-rmagick/DEBIAN/shlibs version just doesn't do anything.
[23:48] <nacc> infinity: your version is more generic, as it isn't tied to the soname and soversion itself (although I couldn't think of a better way to find the .so file to use than find itself, which ties us to a rmagick soversion)