[03:58] <pitti> Good morning
[03:59] <pitti> infinity: ah, so the linux -2.2 efi thing could just be rejected? thanks for cleaning up
[04:01] <infinity> pitti: if by rejected, you mean accepted, then yes.
[04:02] <pitti> infinity: ok
[05:12] <Mirv> would there be a core dev around to ack UITK packaging changes? it seems mainly using more default Qt build options and some more documentation/examples. https://ci-train.ubuntu.com/job/ubuntu-landing-013-2-publish/lastSuccessfulBuild/artifact/ubuntu-ui-toolkit_packaging_changes.diff
[05:12] <pitti> +export CFLAGS := $(shell dpkg-buildflags --get CFLAGS) $(shell dpkg-buildflags --get CPPFLAGS)
[05:12] <pitti> is that actually necessary? this looks redundant
[05:13] <pitti> or does the build system not respect CPPFLAGS?
[05:14] <pitti> moving the mkdir/cp stuff from dh_install to dh_build seems wrong
[05:14] <pitti> this is installation, thus happening under fakeroot; it's only to debian/tmp/, but it still feels like the wrong direction
[05:14] <pitti> --fail-missing is now specified twice
[05:15] <pitti> Mirv: ^ so, I don't see anything which I'd consider a blocker, just several things which look odd
[05:16] <infinity> pitti: The point of the core-dev review is to block on odd. :)
[05:16] <infinity> pitti: Don't let 'em be sloppy.
[05:17] <pitti> Mirv: oh, and don't call dh_auto_build in override_dh_install (not a change from this version, but that's most definitively wrong)
[05:18] <pitti> this might all "work" by chance, but it's utterly confusing and unnecessarily hard to maintain and understand
[05:24] <Mirv> pitti: thanks for all the input, I'll bring them to bzoltan/zbenjamin and discuss
[05:26] <Mirv> pitti: I'm sure their next question would be "but it was QA granted, can we publish it and fix the issues later by filing a bug now?"
[05:26] <Mirv> so I'm just saving time by asking at this point
[05:27] <pitti> I'm actually more concerned why this was moved around without giving a rationale in the changelog
[05:27] <pitti> building docs in dh_install and installing docs in dh_build is just wrong
[05:28] <pitti> so, we know how the "we'll fix it later" goes, but if there's a way to file a bug that will actually stick (milestoning, or assigning to someone, or what not), ok for me
[05:30] <Mirv> ok. I'll get answers but file and assign the bug already now for all those question marks.
[05:30] <pitti> Mirv: thanks
[05:30] <Mirv> thanks to you.
[05:35] <Mirv> bug #1481584 filed
[06:00] <infinity> pitti: Did autopkgtest chroots used to have deb-src URIs in sources.list?
[06:01] <infinity> pitti: Trying to figure out if the apport regression in vivid is an infrastructure regression or test regression.
[06:01] <pitti> infinity: where "used to have" == pre-cloud or the ancient stuff that we had in saucy/trusty?
[06:01] <pitti> ah, vivid; hang on
[06:02] <infinity> pitti: Although, it passed on cloud infra on Jul 14, started failing on Jul 17...
[06:03] <pitti> we used to have deb-src, but this test is for a "sandbox" with its own apt sources, so it shouldn't even matter
[06:03] <pitti> infinity: I'll have a closer look
[06:03] <infinity> pitti: Not so sure about that.  The logs show deb-src being the difference here, I think.
[06:03] <infinity> pitti: The successful logs have Source in the initial update, the failures don't.
[06:04] <infinity> pitti: Still arguably a broken test, mind you, but yeah.
[06:04] <pitti> infinity: ah, so that sounds like a plausible reason then
[06:05] <infinity> pitti: Not sure if the spec gives any reason to assume deb-src would be available, but I've not read it end-to-end.
[06:05] <pitti> I added this to userdata some weeks ago:
[06:05] <pitti> apt_sources:
[06:05] <pitti> - source: deb \$MIRROR \$RELEASE restricted multiverse
[06:05] <pitti> - source: deb-src \$MIRROR \$RELEASE restricted multiverse
[06:05] <pitti> apparently that dropped the main apt sources
[06:06] <pitti> (which is supposed to add additional ones only)
[06:06] <infinity> pitti: Actually, weirder still, the succesful logs show an apt-get update to start, the newer logs don't.
[06:07] <infinity> pitti: So even if deb-src was in sources.list, the lists wouldn't have been downloaded.  Unless that's happening before the log starts now.
[06:08] <infinity> pitti: Oh.  But an update happens way later, and does include Sources.  Now I'm just confused.
[06:08] <infinity> pitti: and too tired to make sense.
[06:08] <infinity> pitti: So I'll go to bed instead. :P
[06:11] <pitti> infinity: so e. g. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-vivid/vivid/amd64/a/apport/20150730_003039@/log.gz
[06:11] <pitti> Sources is part of apt-get update at the very top, and that's the only update that I see
[06:11] <pitti> so, not that
[06:13]  * pitti queues for investigation
[06:15] <pitti> wah wah cmake
[06:57] <dholbach> good morning
[08:44] <pitti> infinity, slangasek: hm, are you binNEWing stuff before builds on all arches are done? (e. g. I was waiting for gmsh/armhf before newing them)
[08:47] <om26er> pitti, Hi! is there a way to include and install pypy package along with debs for autopkg test run ?
[08:47] <pitti> om26er: your test can do whatever it wants to, including calling pypy or pip install
[08:48] <pitti> (not sure what a "pypy package" is)
[08:49] <om26er> pypi
[08:49] <pitti> ah, ok
[08:49] <pitti> om26er: pypy is an actual thing (compiled python), hence my confusion :)
[08:50] <om26er> pitti, so the way you temporary install packages on the phone in /tmp ? I was hoping if I could do the same for a source that is not in ubuntu yet.
[08:50] <pitti> om26er: pip has a mode to install to $HOME/.local, doesn't it?
[08:51] <om26er> pitti, I didn't look into that. Will take a look.
[09:03] <ochosi> dpm: ping
[09:22] <doko> pitti, when you reassign to release, please set the severity to normal as well
[09:22] <pitti> doko: oh, ok; I'll adjust the ones I sent today
[09:22] <doko> do you upload these too to unstable?
[09:22] <doko> also: block <this issue> by 790756
[09:23] <pitti> doko: no, so far I'm just sending patches and tagging
[09:23] <pitti> doko: I included the "block" thingy
[09:24] <pitti> doko: I could upload them as 2-day NMUs I figure
[09:24] <doko> pitti, but then please don't yet reassign ... the release team wonders what happens, and the package owner doesn't see things anymore
[09:24] <pitti> doko: right, I don't reassign (as per our IRC chat a few days ago)
[09:24] <doko> yep doing the NMUs would be nice, if all other b-d's are ready
[09:25] <pitti> tag 791079 confirmed patch
[09:25] <pitti> user release.debian.org@packages.debian.org
[09:25] <pitti> usertag 791079 + transition
[09:25] <pitti> block 791079 by 790756
[09:25] <pitti> that's what I'm doing right now
[09:25] <doko> ahh, I see
[09:25] <dpm> hi ochosi, please feel free to ping questions directly
[09:25] <pitti> doko: ack, I'll NMU the 6 I did so far; but it's all delayed/2, so I think we should still upload them directly to wily?
[09:25] <doko> sure
[09:25] <pitti> doko: (and sync them back later) to avoid another 3 days delay
[09:25] <ochosi> dpm: sure, just wanted to make sure i don't disturb you doing anything else, also i wanted to quickly pm you if you don't mind (since it's not really a u-dev matter)
[09:26] <dpm> ochosi, sure, no need to ask permission to pm, feel free to go ahead :)
[09:27] <doko> seb128, Laney: please tell LazyShark that libreoffice is done (armhf build pending)
[09:30] <seb128> doko, k
[09:32] <Laney> doko: can you please note in the pad when you see things fixed in debian/NEW?
[09:32] <Laney> no point us working on them then
[09:33] <doko> Laney, will try, but will be away 'til Monday
[09:35] <doko> pitti, Laney: so all transitions were at least tried once until now?
[09:35] <pitti> "all transitions"?
[09:35] <Laney> I uploaded the rest of the ones from your debian build logs that didn't have symbols files
[09:36] <Laney> but we saw yesterday that some things were missing from there
[09:36] <Laney> so I can't say it is "all"
[09:36] <doko> yeah, but it should be safe, to remove the block-proposed from gcc-5 and see what happens. everything else should be blocked by the new packages
[09:36] <pitti> doko: oops, my important->normal change was probably wrong -- this should only be done when reassinging to release@, but we don't do that?
[09:37] <Laney> I've been reassigning to release
[09:37] <doko> pitti, yep, sorry for the confusion
[09:37] <Laney> because the bug told me to
[09:37] <Laney> is that not good?
[09:37] <doko> if you NMU yes
[09:37] <Laney> haven't been
[09:37] <pitti> I just NMUed libvsqplitepp (and about to do some others)
[09:37] <Laney> and didn't forward the scripted deltas that I uploaded yesterday
[09:38] <Laney> doing that individually seems quite daunting :/
[09:38] <pitti> should the bugs be reassigned now? and why? (still sounds a bit strange)
[09:38] <Laney> might save that as a debconf task or something
[09:38] <pitti> Laney: yeah, I'm only forwarding patches after I fixed the FTBFS, i. e. package specific changes; forwaring a thousand scripted patches seems a bit pointless
[09:38] <Laney> NMUing them to speed the transition along in Debian feels like it would be useful though
[09:39] <Laney> but there's a risk of false positives without analysis
[09:39] <doko> you are allowed to do 2day delayed NMUs. so NMUing and reassigning would be the best
[09:39] <doko> be sure that all b-d's are ready
[09:40] <pitti> doko: OOI, why reassign in this case?
[09:41] <Laney> did someone prune the "appear to be transitioned in Debian" list?
[09:41] <pitti> Laney: yes, for the bits that I synced/built/NEWed
[09:41] <Laney> ah, great
[09:41] <pitti> Laney: there's 3 left which we can't do yet
[09:42] <pitti> I left a comment
[09:42] <pitti> two of them should be syncable this afternoon
[09:42] <Laney> yeah, I see those, just wondered about the rest
[09:42] <pitti> well, it's a TODO list -- stuff that's done should just disappear
[09:42] <Laney> 05/08 08:35:57 <doko> GCC 5 stuff in NEW: rtmidi rtaudio tinyxml guichan
[09:42] <pitti> I'm also pruning the FTBFS and others
[10:08] <willcooke> Laney, sladen - hi, did you manage to get that font zip file sorted?
[10:09] <pitti> doko: this (ipe) does not look like an ABI break to me: http://paste.ubuntu.com/12005903/ - WDYT?
[10:10] <pitti> doko: or is that the __cxx114 thingy?
[10:10] <pitti> doko: I was wondering because a rebuild in sid still generates libstdc++6 (>= 4.6) only, not >= 5
[10:11] <Laney> willcooke: not yet I'm afraid, still standing by
[10:11] <doko> pitti: the bumped dependency on libstdc++ only appears if you reference any of the new symbols in libstdc++.
[10:12] <doko> but the library defines some cxx11 symbols on its own, so yes, I'd say an ABI break
[10:12] <pitti> doko: ok, thanks for checking
[10:12] <willcooke> Laney, thanks.
[10:12]  * pitti goes on with NMUing then
[10:24] <sladen> willcooke: no, was prioritising other actual _potential to block_ stuff
[10:26] <willcooke> sladen, nw, any idea of an ETA, or if you can let me or Laney know what needs doing we can have a stab at it
[10:32] <doko> wtf, onboard manually depends on every single shared library???
[10:39] <pitti> some build systems just outsmart themselves
[10:40] <sidi> Is this the right channel for Unity development?
[10:40] <Laney> sidi: #ubuntu-unity
[10:40] <sidi> thanks Laney
[10:40] <pitti> ah, d-shlibmove -- apparently that needs a --suffix=v5 or so, /me tries
[10:43] <doko> pitti, I fixed d-shlibmove, needs --v5
[10:43] <pitti> doko: ah, I used --suffix=v5
[10:44] <doko> hmm, I tried that too ... anyway
[10:46] <pitti> /usr/bin/d-shlibmove: [--suffix=v5] is not a valid shared library file name
[10:46] <pitti> meh
[10:47] <seb128> hum
[10:47] <seb128> grub-efi-amd64 fails to configure on my wily test laptop
[10:47] <seb128> it bails out on
[10:47] <seb128> "ERROR: cannot determine partition label for rootfs"
[10:47] <seb128> does anyone has an idea how to solve it?.
[10:50] <pitti> doko: ah, --v5 is in wily only; I'm trying to fix sid too
[10:50] <doko> pitti: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794561
[10:52] <seb128> hum
[10:52] <seb128> it's upgrade-gru
[10:52] <seb128> it's upgrade-grub which fails on that error
[10:52] <pitti> doko: ah, thanks; reading the code, --suffix should work as well; maybe only "--suffix v5", not "--suffix=v5", trying with the former
[10:54] <pitti> doko: ah! --suffix v5 works! \o/
[10:55] <doko> I love Jonas too
[10:56] <pitti> debian/control.in.in, yummy ;)
[10:58] <doko> rbasak, https://bugs.launchpad.net/bugs/1481333 is this seen in -proposed as well?
[11:19] <doko> pitti: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794587
[11:23]  * Laney sees d-shlibmove for the first time
[11:23] <doko> don't take a second look
[11:24] <Laney> heh
[11:25] <Laney> hm, control.in.in too - pitti, were you talking about ucommon?
[12:04] <pitti> Laney: no, libsass
[12:05] <pitti> doko: argh, thanks; I'll upload a Conflicts:/Replaces:
[12:06] <doko> pitti, as a break to the library uploads, could we walk throught the failing autopkg tests triggered by gcc-5?
[12:09] <doko> Laney, pitti: http://autopkgtest.ubuntu.com/packages/a/autopilot-gtk/wily/amd64/  this was triggered before the GCC change. could you have a look?
[12:16] <pitti> doko: looks "just" flaky at first sight, I'll retry a few times
[12:18] <pitti> doko: uploaded C/R for vpb-driver, thanks for pointing out
[12:21] <pitti> Laney, doko: BTW, do you know whether it's normal that ftp://ftp-master.debian.org/pub/UploadQueue/DELAYED/2-day/ is empty?
[12:22] <pitti> dput -e 2 ftp-master succeeded, but I never got any kind of mail from ftpmaster
[12:25] <doko> pitti, beware, exiv2 in debian NEW with a different library name. maybe we should merge that (new upstream)
[12:30] <pitti> doko: ah yes, quite a bunch of rdepends
[12:30] <pitti> doko: we can't download stuff from Debian new, but I can piece it together from packaging svn
[12:31] <doko> pitti, please update rdeps in main too after that
[12:31] <pitti> ack
[12:31] <doko> I'm already running a wily-proposed desktop
[12:32] <pitti> added to pad
[12:36] <pitti> doko: meh -- they didn't commit 0.25-1 to svn :(
[12:37] <pitti> doko: so I guess we'll have to wait for Debian NEW
[12:37] <doko> pitti, will appear in incoming soonish
[12:37] <pitti> we might get a few rebuilds against v5 by then, so we'll just have to do it again
[12:37] <pitti> *shrug*
[12:37] <pitti> doko: oh, was it just NEWed?
[12:37] <doko> yes
[12:37] <pitti> nice
[12:38] <pitti> ok, postponing that until it hits incoming, and continuing FTBFS fixing by then
[12:39] <pitti> Laney: ok, you stole my color, I switched to red now :)
[12:45] <bzoltan_> pitti: infinity: refering to the UITK packaging issues -> I have addressed all your comments in this MR -> https://code.launchpad.net/~bzoltan/ubuntu-ui-toolkit/packaging_fixes_lp1481584/+merge/267012 The  CFLAGS exports I used straight from the Qt packages. It is like that in all debian packages too.
[12:46] <pitti> bzoltan_: ah, that looks nicer already, thanks
[12:47] <pitti> bzoltan_: I still don't understand why this CFLAGS dance is necessary, though
[12:47] <bzoltan_> pitti:  thank you for point out ... The CFLAGS I do not get either.
[13:08] <Laney> pitti: no mail from DELAYED - I just check https://ftp-master.debian.org/deferred.html after a bit
[13:08] <Laney> don't know where the files end up living
[13:08] <pitti> Laney: aah! that's what replaces https://people.debian.org/~djpig/delayed.html, thanks!
[13:08] <Laney> showing your age there :P
[13:08] <pitti> Laney: great timing! at the very second you say that I asked in #debian-release :)
[13:09] <Laney> ha
[13:16] <pitti> Laney: libdynamicedt3d1.6 wasn't renamed in the octomap source; on purpose, or doesn't the script get along multiple libs?
[13:17] <seb128> slangasek, cjwatson, cyphermox, hey, who is looking after grub issues nowadays?
[13:18] <Laney> pitti: The script tries to rename only the packages with changed symbols
[13:18] <pitti> Laney: ah, cool
[13:19] <pitti> Laney: I'll verify in the (fixed) builds, but good to know
[13:19] <Laney> if the test rebuild is to be believed then this looks right
[13:19] <Laney> (octomap & octovis)
[13:20] <cjwatson> seb128: cyphermox
[13:20] <cjwatson> (afaik)
[13:20] <seb128> cjwatson, thanks
[13:37] <pitti> Laney: ah! all tmpfails fixed :)
[13:38] <Laney> :-O
[13:38] <Laney> even n-m/vivid?
[13:38] <pitti> Laney: this morning we had tmpfails for all packages with "network" in the name
[13:38] <pitti> Laney: *all*
[13:38] <pitti> Laney: well, vivid is just a "real" failure now
[13:38] <pitti> (it needs the same "disable 80211.a" change that cyphermox applied to wily)
[13:39] <pitti> Laney: that was a funny parsing bug of "nova show" (for finding the IP)
[13:39] <doko> pitti, http://incoming.debian.org/debian-buildd/pool/main/e/exiv2/
[13:39] <pitti> I wish nova had some --machine-readable thingy instead of having to parse ascii art tables
[13:39] <pitti> doko: yay, fake-syncing
[13:40] <pitti> doko: I'll upload rebuilds after it published
[13:43] <doko> slangasek, Laney, pitti: so geos, spatialite, postgis, gdal have a build-dependency cycle now ...
[13:44] <doko> was looking at these to fix autopkg test failures for gcc-5, but running out of time now
[13:44] <pitti> doko: geos built fine, WDYM?
[13:45] <pitti> oh, you mean the latter 3 have not co-installable build-deps now?
[13:46] <doko> yes
[13:53] <Laney> doko: looks like you can turn off spatialiate in gdal
[14:01] <pitti> meh, exiv2 FTBFS on 32 bit arches
[14:01] <pitti> ah, just symbols madness
[14:06] <rbasak> doko: that bug doesn't affect MySQL in Ubuntu yet (AFAIK). Upstream reported it - we'll need to wait for them to reply I think.
[14:07] <doko> Laney, thanks. and found: https://launchpad.net/ubuntu/+source/opencv/2.4.9+dfsg-1ubuntu5
[14:07] <doko> rbasak, thanks for checking
[14:07] <Laney> joyous
[14:07] <doko> rbasak, is anybody checking for image installability using wily-proposed?
[14:08] <rbasak> doko: I don't think so, no.
[14:09] <doko> rbasak, I asked smoser in the past, but never got a reply
[14:25] <pitti> Laney: do you happen to know how to untangle a C++ per-arch symbols mismatch like https://launchpadlibrarian.net/213670636/buildlog_ubuntu-wily-armhf.exiv2_0.25-1_BUILDING.txt.gz ?
[14:26] <pitti> Laney: if so, quick tutorial appreciated (I've never done this)
[14:26] <pitti> or anyone C++ savvy ^
[14:38] <rbasak> doko: matsubara is the QA contact on our team. Maybe he knows? He'd be the person to speak to about it anyway but I don't see him online right now.
[14:43] <Laney> pitti: ah, is that size_t?
[14:43] <pitti> Laney: it's in some "string" class obviously, but apart from that this is just gobbledigok to me :(
[14:44] <pitti> Laney: size_t in a string class sounds plausible, though
[14:44] <pitti> at least it fails on the three 32 bit arches and succeeds on the three 64
[14:44]  * Laney runs it through c++filt
[14:44] <Laney> GET https://launchpadlibrarian.net/213670636/buildlog_ubuntu-wily-armhf.exiv2_0.25-1_BUILDING.txt.gz | zcat | c++filt | vim - # or so
[14:44]  * pitti uploads the next FTBFS fix in teh meantime
[14:45] <pitti> Laney: do you need a hand with ucommon? (that hasn't changed in a while)
[14:45] <Laney> I got confused about it
[14:46] <Laney> now d-shlibmove is failing and I didn't get to the bottom of why yet
[14:46] <Laney> yeah these look like size_t
[14:47] <Laney> I think the state of the art, unless it changed while I wasn't looking, is to use pkgkde-symbolshelper for those
[14:47] <Laney> you can do some subst thing so it substitutes the right type per-arch with that
[14:47] <Laney> or you can include two versions with the right arch= for each one
[14:47] <Laney> (which is obviously more brittle but easier to get going now)
[14:48] <pitti> Laney: the .symbols doesn't have any arch=, nor size_t, I wonder how previous versions did that
[14:49] <pitti> oh! all symbols say "0.25", so apparently they just added that
[14:49] <pitti> isn't there some sane way to put demangled symbols into *.symbols instead of this arch specific mess?
[14:51] <Laney> it still demangles to the actual type and not size_t
[14:51] <Laney> but yes, you can c++filt them
[14:52] <Laney> (c++)"<c++filted thing>"
[14:52] <pitti> ah, so that wouldn't even help
[14:53] <pitti> Laney: as this is totally new in 0.25-1, would it be okay to drop it temporarily for us and let the DD sort out the symbols?
[14:53] <pitti> "this" -> the .symbols file
[14:53] <Laney> I saw an example yesterday or so where doko split 32/64 bit specific symbols out into different files and included them
[14:54] <Laney> but I can't find it now :(
[14:56] <doko> pitti, look if this is managed with the kde symbols helper
[14:56]  * pitti looks at omnievents -- no reverse deps, last upload 2011, obsolete stuff -- shouldn't we rather just remove this?
[14:57] <pitti> (I fixed it in wily, wondering whether to NMU or not)
[14:57] <pitti> doko: I'd say no, nothing "kde"ish in debian/rules or control
[14:58] <pitti> they just added the .symbols file without any changes to debian/rules
[15:00] <Laney> pitti: meh, new d-shlibs breaks ucommon
[15:00] <Laney> it's added some new and wrong quoting
[15:01] <pitti> Laney: new in Ubuntu or new in Debian?
[15:01] <pitti> Laney: I tried "--suffix v5" (which works in Debian, for NMUing), and that works; I didn't try the ubuntu specific --v5
[15:02] <Laney> it's a call to objdump which dies
[15:02] <Laney> and doesn't with 0.58
[15:58] <hallyn> dannf: when you ran test-qemu.py ,did you first go into the scripts/qemu and scripts/libvirt subdirectories and wget the files the readmes say to get?
[15:59] <hallyn> maybe i'll post a MR to do that automatically
[15:59] <dannf> hallyn: yeah.
[15:59] <hallyn> hm
[15:59] <hallyn> not good
[15:59] <Laney> xnox: did you fix the moc/BOOST_JOIN thing?
[15:59] <dannf> its weird - it complained the file wasn't there - but it was
[15:59] <dannf> and then the tests ran
[15:59] <dannf> w/o the file they didn't
[16:00] <dannf> hallyn: i also think its funny that it downloads the key insecurely, the tarball insecurely, then verifies the tarball w/ the key... but i guess it doesn' tmake things *worse* :)
[16:03] <hallyn> i assume someone had intended to embed a public key into the bzr tree and neve got around to it
[16:04] <dannf> yeah, i guess i could MP that instead of whining
[16:04] <hallyn> dannf: fwiw i wont' be able to look at that today i don't think;  if you still have trouble tomorrow pls shout
[16:05] <dannf> hallyn: ok
[16:29] <pitti> doko, Laney: just in case you wonder, removing libsass from wily-proposed; the DD does not want this transitioned, and there are no rdepends
[16:30] <pitti> (also cancelled the NMU)
[19:03] <doko> rbasak, please could you merge libecap? background: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791117
[19:03] <rbasak> Should logrotate scripts be using invoke-rc.d? Or is the service wrapper acceptable?
[19:03] <rbasak> doko: looking
[19:04] <doko> soonish would be good, then we don't need to rename the library package
[19:04] <rbasak> kickinz1: Blocking fix for 794536: squid3: FTBS on GCC-5
[19:05] <rbasak> doko: arges is taking it.
[19:05] <doko> ta
[19:05] <kickinz1> rbasak, thanks
[19:12] <doko> slangasek, Laney, pitti: so renaming all libs first, without rebuilding all rdeps is a good way to find cyclic dependencies ;-P
[19:12] <doko> now coming to a solution for postgis/spatialite/gdal
[19:12] <doko> Laney, did you make progress with opencv?
[19:18] <rbasak> In case it got missed: should logrotate scripts be using invoke-rc.d? Or is the service wrapper acceptable?
[19:18] <rbasak> infinity: ^^ any opinion on that please?
[19:19] <rbasak> I'm leaning towards invoke-rc.d but am wondering if there's any existing best practice on that
[19:21] <infinity> rbasak: Not sure there's a policy or even established best practice, but in my mind, anything a *maintainer* does should use invoke-rc.d, so a sysadmin can override with policy-rc.d
[19:21] <infinity> rbasak: So, that's not just dpkg maintainer scripts, but any script you ship that wants to fiddle with services, including logrotate.
[19:22] <infinity> rbasak: Policy might say something sort of like that somewhere, but I don't recall seeing it.
[19:23] <infinity> rbasak: /etc/network/if-up.d/ntpdate seems to follow this, for instance.
[19:23] <infinity> And openssh-server.
[19:23] <rbasak> infinity: understood, with the reasoning. Thanks!
[19:23] <infinity> rbasak: So, yeah.  invoke away.
[19:24] <arges> cyphermox: i see you are having a productive SRU day
[19:24] <arges> cyphermox: reviewing a lot of your packages now
[19:24] <infinity> rbasak: So, on my system, that would make the logrotate scripts for samba and rsyslog buggy.  And probably rightfully so.
[19:24] <infinity> rbasak: Eww, and speech-dispatched double-buggy, it calls /etc/init.d/foo directly.
[19:25] <infinity> Gross.
[19:25] <infinity> rbasak: Thanks, I didn't want to know this.
[19:25] <cyphermox> arges: yeah, those are all special magic, don't hesitate to include infinity, he was delegating to me ;)
[19:26] <infinity> cyphermox: Half the reason to delegate to you was so I could do the reviews.
[19:26] <infinity> arges: So, yeah, if you're not comfy reviewing ppc64-diag, I'll hit it up after breakfast.
[19:32] <rbasak> infinity: well, I didn't ask you to look :)
[19:33] <rbasak> infinity: rcj is just fixing this kind of thing in freeradius and so I just wanted to make sure that we fix it the right way.
[19:33] <infinity> rbasak: I can't help looking.
[19:33] <infinity> rbasak: And now I know the world is a little bit less shiny than I hoped.
[19:34] <barry> infinity: ping re python-apt and apt (since mvo isn't around and you did the last upload to apt in wily)
[19:35] <infinity> barry: I feel like your ping lacks content.
[19:36] <barry> infinity: python-apt b-d's on apt (>= 1.0.10) but 1.0.9.10ubuntu6 is in w-p
[19:36] <barry> infinity: what's the eta for 1.0.10 in wily?
[19:36] <barry> infinity: (sorry, was clicking around ;)
[19:37] <infinity> barry: Man, David only uploaded it to unstable two days ago!
[19:37] <barry> infinity: it == apt?
[19:37] <arges> infinity: ok either way I was just about to look at ppc64-diag
[19:37] <infinity> barry: I hadn't had any intention of taking over the merges there, so no ETA.  Why did we merge python-apt?
[19:37] <arges> infinity: in fact i'll just handle that
[19:38] <barry> infinity: dunno!  i just started looking at this, and mvo isn't around
[19:39] <barry> infinity: ok, no worries, i'll figure something out
[19:39] <infinity> barry: Huh.  That's fishy.  We had a delta, so the sync would have been forced, but I see no mail to -changes telling me who did it. :/
[19:40] <infinity> barry: If it was mvo, I'd expect he plans to do apt as well.
[19:40] <barry> infinity: probably/hopefully so
[19:41] <infinity> barry: Oh, the delta might be tiny anyway.
[19:41] <infinity> barry: Lemme look at it after I (finally) eat breakfast.
[19:41] <barry> infinity: ack, thx
[19:42] <infinity> barry: Based on David's changelog, 1.0.10 might just be the C++ transition, no scary.  Unless his changelog is a lie.
[19:42] <barry> infinity: and there's a changelog in pyapt for the gcc transition too
[19:43] <infinity> barry: Right.  I'll poke this bear with a stick in ~1h.
[19:43] <infinity> When my stomach stops with the hate.
[19:43] <barry> infinity: i'll wait for the tonal change from stomach roar to bear roar
[19:45] <doko> rbasak, arges: accepted libecap. please schedule building the rdepends once the package is published
[19:47] <arges> ok
[19:47] <doko> infinity, mvo comes back next week. this should have time
[19:49] <arges> doko: just to confirm, I need to no-change rebuild on any libecap rdepends
[19:52] <doko> arges, yes, but only once you see/can install the package in your own chroot
[19:54] <barry> infinity: fwiw, i bump the bd's down to 1.0.9 and python-apt built locally just fine
[19:56] <infinity> barry: Yeah, I assumed it would, but may as well keep the sync if merging apt isn't too painful.
[19:56] <barry> infinity: +1
[19:56] <infinity> barry: If apt thwarts my efforts, I'll just introduce a python-apt delta.
[20:51] <infinity> ypwong: You around?
[20:53] <infinity> ypwong: cyphermox and I are considering respinning ubuntukylin 14.04.3 ISOs to fix https://bugs.launchpad.net/ubuntukylin/+bug/1380981 but only if you guys are happy with another build.
[21:01] <Laney> doko: didn't look at opencv
[21:02] <doko> Laney, I did =) openexr wasn't rebuilt. took the new upstream from experimental
[21:02] <Laney> nice
[21:29] <rbasak> infinity: logrotate postrotate script: silently ignore failure on sending reload signal? Logic: if daemon isn't running, failure to send re-open signal isn't a problem.
[21:29] <rbasak> infinity: some logrotate scripts do this, but the logrotate manpage examples don't seem to.
[21:34] <infinity> rbasak: Been a while since I wrote logrotate stuff, but it really depends on what cron spam you think is justified.
[21:34] <infinity> rbasak: If a failed reload could actually be a failure, the admin might like to know that his daemon died overnight.
[21:35] <infinity> rbasak: So, sort of depends on the init setup and what you do or don't know about state.
[21:35] <rbasak> infinity: for freeradius then, I think the answer is to not fail silently. Though if the sysadmin deliberately wants the service to remain stopped, then he'll get spam. I think that's OK.
[21:38] <infinity> rbasak: The canonical example of this from my years in the trenches was fighting with apache logrotate scripts that had to stop/start because of $reasons (reload/graceful didn't DTRT and close all the logs), but because it can take several months to stop a heavily-loaded apache, it might fail to start again.
[21:38] <infinity> rbasak: In that case, having the cron spam was invaluable, both to frustrated sysadmins who needed to fix it, and to us because we got notified that our packages sucked. :P
[21:42] <Laney> LocutusOfBorg1: You want to use your new powers to transition lucene++ for GCC5? :)
[21:43]  * Laney cooks up a diff anyways
[23:05] <hallyn> dannf: fwiw on my system all tests passed with your debdiff
[23:05] <hallyn> something funky going on with your vm probably