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