[02:20] <cjwatson> pitti: http://d-jenkins.ubuntu-ci:8080/view/Utopic/view/AutoPkgTest/job/utopic-adt-kde-runtime/ARCH=i386,label=adt/45/console - we could really use "apt-get update || { sleep 15; apt-get update; }" or something in the adt setup
[02:32] <hallyn> xnox: hey, late in your tz, so probably not, but...  are you around?
=== _salem is now known as salem_
[04:00] <pitti> cjwatson: curious, adt-run is already using that in most places (we talked about it a few months ago); apparently I forgot one place, I'll have a look
[04:00] <pitti> Good morning
[04:24] <pitti> slangasek: hey Steve!
[04:24] <pitti> slangasek: do you think it's ok to upload the sysvinit to -proposed and keep it there with a block-proposed bug? that way we can already run all the testing against it
[04:25] <pitti> slangasek: it's a relatively harmless effective change, after all
=== timrc is now known as timrc-afk
[04:34] <pitti> cjwatson: oh -- that log already *does* retry, and the second apt-get update succeeds; the BADSIG is bug 1345877
[04:34] <ubottu> bug 1345877 in ubuntu-archive-publishing "Invalid GPG signature http://ddebs.ubuntu.com/dists/trusty/Release.gpg" [Undecided,Confirmed] https://launchpad.net/bugs/1345877
[04:34] <slangasek> pitti: I'd rather not deliberately put stuff into -proposed that we don't expect to get out immediately
[04:34] <slangasek> pitti: but I guess it's your call
[04:35] <pitti> slangasek: ah, I postponed it as the other day you said that there are some things you didn't like in the new versino, and you wanted to review
[04:35] <pitti> slangasek: also, I don't want to land it in traincon-0
[04:35] <pitti> cjwatson: ah no, the badsig is from the main archive, not from ddebs; so I guess this is a case where apt-get update failed twice in a row :/
[04:35] <slangasek> pitti: correct, I want to review the merge before it goes in, on account of some vexing upstream changes
[04:36] <pitti> slangasek: ok, then I won't upload it for now
[04:36] <slangasek> (and it's easier for me to review it than to give an accounting of all the things that have recently been wrong with sysvinit maintenance in Debian)
=== salem_ is now known as _salem
=== doko_ is now known as doko
[06:08] <doko> pitti, jibel: could you restart the plv8 and pgagent autopkg tests? seem to be qemu issues
[06:08] <pitti> doko: no, pgagent is an actual bug; I just uploaded the transition to 9.4 to Debian, will auto-sync
[06:08] <doko> gwenview did fail before tpp
[06:08] <doko> ahh, ok
[06:08] <pitti> doko: plv8 as well, there's something wrong with the transition (it tries to pull in 9.3)
[06:08] <doko> well, blocking gcc-4.9 ...
[06:08] <pitti> doko: it's on my list for today, too
=== evfool__ is now known as evfool
[06:54] <doko> Riddell, can you or #kubuntu have a look at the gwenview autopkg test failure?
[06:54] <dholbach> good morning
[07:01] <doko> dobey, ubuntu-sso-client ping, could you have a look at the autopkg test failure?
[07:16] <pitti> doko: ah, the fixed plv8 is still stuck in Debian binNEW
[07:16] <pitti> doko: I'll do an Ubuntu upload to unblock
=== tvoss is now known as tvoss|test
=== tvoss|test is now known as tvoss
[08:20] <cjwatson> pitti: oh, right, ugh.  ok
[08:22] <cjwatson> doko: I already applied a force-badtest hint to gwenview; no idea why it's still showing there
[08:22] <cjwatson> oh, p-m can only take one hint for any given package
[08:22] <cjwatson> doko: once everything else is fixed, tell me and I'll force-skiptest gcc-4.9
=== vrruiz_ is now known as rvr
[08:45] <pitti> doko: plv8 is good now; I just removed the NBS, it should promote in the next cycle; (and unblock gcc)
[08:51] <doko> pitti, cjwatson: that leaves gcc-4.9 with pgagent (which will be synced from debian soonish), and gwenview
[08:52] <pitti> as the gwenview regression was introduced with 4:4.13.90-0ubuntu1 in -proposed, we could also just remove that package from -proposed
[08:53] <cjwatson> pitti: no
[08:53] <cjwatson> pitti: we've seen failures with earlier versions too; also please don't do anything to interfere with the megatransition
[08:53] <cjwatson> pitti: ScottK has already forwarded it upstream, and we think the failures are ignorable for now
[08:53] <cjwatson> hence my hint
[08:54] <pitti> ack
[08:54] <pitti> wrt. history, http://d-jenkins.ubuntu-ci:8080/job/utopic-adt-gwenview/20/ was an infrastructure problem, otherwise http://d-jenkins.ubuntu-ci:8080/job/utopic-adt-gwenview/? looks fairly stable (pass/fail)
[08:54] <cjwatson> oh, maybe the alleged failures with earlier versions are just adt-britney being confused
[08:55] <pitti> but override WFM, it's clearly not a gcc regressino in this case
[08:55] <cjwatson> notice how update_excuses says "autopkgtest for gwenview 4:4.13.2-0ubuntu2: Regression" in places
[08:56] <pitti> indeed; looks like it says the release version number there instead of the proposed version?
[08:57] <cjwatson> I guess the cause is wrong in the various control files, but argh that stuff hurts my brain
[08:57] <cjwatson> doko,pitti: ok, so I've hinted "force-skiptest gcc-4.9/4.9.1-3ubuntu2"
[08:57] <pitti> not a biggie right now either way
[08:57] <pitti> cjwatson: thanks
[08:58] <pitti> if it's any urgent, you can also skip the pgagent test; I suppose it'll still be a few hours until it gets imported and synced
[08:58] <cjwatson> "force-skiptest" skips all tests hung off a given upload
[08:58] <cjwatson> "force-badtest" skips just tests for a given failing package
[08:58] <pitti> ah
[08:59] <cjwatson> So in this case I meant to say "everything done, ignorable, or being fixed"
[09:00] <cjwatson> And none of it caused by gcc in any event, as far as I understand it
[09:11] <mlankhorst> cjwatson: fglrx won't be available for some time when I release xorg-server 1.16, in that case could fglrx be temporarily dropped or something?
[09:11] <seb128> shouldn't we hold on 1.16 until all drivers are ready instead?
[09:13] <cjwatson> mlankhorst: that seems questionable given that it's widely-used
[09:14] <cjwatson> mlankhorst: but seems that needs wider discussion rather than just asking me, a non-fglrx user :)
[09:14] <mlankhorst> there's radeon still available as alternative
[09:14] <seb128> -1 for letting users down this way
[09:15] <seb128> we decided some cycle ago to not do that anymore no?
[09:15] <mlankhorst> but we won't receive upgrades for radeon until very near final release :/
[09:23] <mlankhorst> and flipping the whole xorg-server near release sounds like a  bad idea, while some of the other changes are definitely needed
[09:24] <seb128> needed for what?
[09:24] <seb128> well, you should talk to other teams, maybe email ubuntu-devel@ with the plan and why we need the update even if we don't have all drivers
[09:24] <mlankhorst> I have mailed a CFT to ubuntu-devel@
[09:30] <cjwatson> Riddell: Can we slow down the KDE uploads for a bit?  I think libav might just have landed if not for the gwenview upload just now
[09:31] <cjwatson> argh, which is dep-wait
[09:31] <cjwatson> on something not uploaded yet!
[09:31] <cjwatson> tempted to remove that and copy the old one back
[09:34] <xnox> well, anything that would make britney transition things or give us a sensible list of things to fix is good.
[09:36] <cjwatson> xnox: I've got a sensible list and it says "gwenview"
[10:11] <cjwatson> libav migrating!
[10:11] <rbasak> \o/
[10:11] <cjwatson> publisher on manual to ensure that all the copies go in one batch
[10:20] <cjwatson> publisher on auto
[10:39] <mlankhorst> cjwatson: what about a solution where we upload xorg-server and all the packages to -proposed near feature freeze, and keep it there until the next fglrx release, hopefully in a week or 2 later?
[10:40] <cjwatson> I guess that's one option but be careful of things that might end up blocked on that
[10:40] <cjwatson> honestly I'd rather not be the decision-maker here - I'm going to have a lot to do with phone RTM
[10:42] <mlankhorst> well not requiring a FFe for xorg-server would be ok with me too
[10:51] <pitti> mlankhorst: so perhaps testing from a PPA would be better for now? (FWIW, I have no idea how important the fglrx driver is these days -- back then, radon worked just fine for me, but it's been years since I had something non-intel)
[10:51] <pitti> radeon even
[10:52] <mlankhorst> pitti: we have a ppa, but that doesn't get NEARLY as much testing as the archive does..
[10:52] <mlankhorst> I'll be lucky to get 10 people testing..
[10:52] <pitti> xorg-edgers how how that was called?
[10:53] <pitti> mlankhorst: OOI, in which regards is fglrx better than radeon these days?
[10:53] <mlankhorst> no idea, I tend to use radeon more. presumably fglrx has some features radeon lacks
[10:56] <pitti> I mean, if it doesn't work on some hardware, that's a good reason to not break utopic; if it's just marginally slower or eating a bit more power, temporarily dropping it seems just fine to me
[10:57] <pitti> (assuming that it automatically falls back to radeon)
[10:57] <pitti> comparing the vendor/product ID lists might help there?
[11:12] <mlankhorst> not really, mostly newer HW works minus radeon bugs
[11:12] <mlankhorst> it's just that the latest might not, no idea tbh
=== pete-woods is now known as pete-woods|lunch
=== MacSlow is now known as MacSlow|lunch
=== Trewas666 is now known as trewas
[11:25] <rbasak> Looking at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752796, it looks like a Perl 5.20 transition is due to hit sid on 12 August.
[11:25] <ubottu> Debian bug 752796 in nginx "nginx: hardcodes /usr/lib/perl5" [Serious,Open]
[11:26] <rbasak> That's before our feature freeze. Are we going to take that?
[11:26] <rbasak> I'm wondering whether to cherry-pick the fix for nginx that is in VCS but not uploaded to unstable yet.
=== ycheng is now known as ycheng-afk
[11:27] <mdeslaur> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur
=== tvoss is now known as tvoss|lunch
[11:34] <mlankhorst> pitti: oh and without xorg-server radeon will actually work worse, because it will lack the glamor updates
[11:56] <mvo_> jibel: can you confirm in the lap or on your test vm (when you have a moment) that #1347964 is no longer appearing?
[11:58] <jibel> mvo_, without any specific repo?
[12:01] <rbasak> pitti: the 'current specification' link from http://dep.debian.net/deps/dep8/ is broken.
[12:03] <mvo_> jibel: yeah, it should be fixed in the main repo already
[12:03] <mvo_> jibel: fingers crossed :)
=== pete-woods|lunch is now known as pete-woods
=== pipe_dream is now known as lisca
[12:05] <jibel> mvo_, upgrade in progress ...
[12:09] <mvo_> jibel: you rock
=== MacSlow|lunch is now known as MacSlow
[12:20] <juliank> slangasek: Is the patch debian/patches/gcc46-compatibility for gnu-efi still needed (what's the reason for building with gcc 4.6 these days?) or can this be synced from unstable to the new upstream release now?
[12:22] <juliank> If it can be dropped, a "syncpackage -s juliank gnu-efi" would be nice
[12:23] <pitti> rbasak: yeah, I fixed it in svn a few weeks ago and asked for updating it, but that didn't happen yet :/
[12:23] <rbasak> No worries
=== _salem is now known as salem_
[12:54] <doko> jamespage, maven fun in proposed ... libcommons-logging-java and tomcat8 ...
[12:54] <jamespage> doko, joy joy
[12:54] <doko> can you have a look? http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
[12:55] <doko> objenesis?
[12:55] <jamespage> doko, not right now - dealing with some other things today
[12:55] <jamespage> doko, as we doing tomcat8 for main this cycle?
[12:56] <jamespage> are we rather
[12:56] <doko> jamespage, you tell me ...
[12:56]  * jamespage thinks
[13:01] <doko> zul better should subscribe ubuntu-mir when filing MIR's ...
[13:02] <xnox> doko: should i make 3.5 default for llvm-default on ppc64el only? or should I instead fix powerpc build failure and work out if/when/can we switch to 3.5 by default?
[13:02]  * xnox looks at release schedule.
[13:04] <doko> xnox, I'd say make it the default on all architectures after checking that mesa is fine with it
[13:05] <xnox> doko: ack. this also means fixing powerpc build then.
[13:07] <doko> dholbach, you sponsored python-wsme, hangs now in component mismatches ... please file the 30 MIR which are required, or drop the build deps ...
[13:11] <dholbach> Noskcaj, ^
[13:12] <dholbach> doko, I followed up on the sponsoring bug - thanks - I thought I had checked all the build-deps and verified they were in main
[13:12] <dholbach> I must have missed something
[13:14] <dobey> doko: re: ubuntu-sso-client, do you have a link? i didn't get any e-mail about it failing
[13:15] <doko> dobey, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
[13:16] <doko> tvoss|lunch, can you take care about https://bugs.launchpad.net/ubuntu/+source/libjsoncpp/+bug/1349834 ?
[13:16] <ubottu> Ubuntu bug 1349834 in libjsoncpp (Ubuntu) "[MIR] flask-script and libjsoncpp (b-d's for net-cpp)" [Undecided,Incomplete]
[13:16] <dholbach> doko, I reopened the bug as well
[13:18] <dobey> sigh, why is squid not starting
[13:24] <apachelogger> mardy: heya, any chance of getting a new signon upload for utopic? we are currently porting kde-accounts and it appears as though the cmake config installed by the current package has a bit of a divergent name from what is in git (namely SignOnQtConfig.cmake vs. SignOnQt5Config.cmake)
[13:35] <jibel> mvo_, upgrade from 12.04.4 desktop + Trusty HWE stack -> Trusty is successful on amd64
[13:36]  * jibel hugs mvo_
[13:43]  * mvo_ hugs jibel
[13:44] <mvo_> thanks for confirming
=== tvoss|lunch is now known as tvoss
[13:46] <tvoss> doko, on my list
[13:48] <cjwatson> rbasak: perl 5.20> I'm considering it if the rest of -proposed is quiet enough at that point
[13:50] <rbasak> cjwatson: OK, thanks. I didn't cherry-pick it for now, but the patch (for nginx) is there for us to grab if we need it.
[13:55] <arges> jamespage: hello. I see ceph/nova are in teh trusty review queue. Is it alright if I review these and potentially accept into proposed? I don't want to mess up any plans you already have
[13:56] <dholbach> shadeslayer, ready for the hangout in ~1h?
[13:56] <shadeslayer> yep
[13:56]  * shadeslayer is excited and nervous
[14:13]  * dholbach hugs shadeslayer
[14:13] <dholbach> all will be fine :)
[14:14] <shadeslayer> :D
[14:16] <doko> component-mismatches-proposed is frustrating ...
[14:23] <bzoltan> mitya57:  ping
[14:28] <bzoltan> mitya57:  I would need a friendly licensed maintainer who could review and approve an MR from us against the QtCreator packaging branch: https://code.launchpad.net/~kubuntu-packagers/kubuntu-packaging/qtcreator. The patch is rather simple -> https://code.launchpad.net/~zeller-benjamin/kubuntu-packaging/qtcreator-ubuntudevice-qmlprojects/+merge/228665 It enables ubuntu devices to be Run targets for QML apps.
[14:35] <hallyn> pitti: do i understand right that cgmanger will start so long as there is a sysv init job but no systemd job;  and if i create a cgmanager.service disabled by default, then it won't start?
[14:38]  * hallyn tries
[14:44] <doko> apw, infinity, ogasawara: I assume we need a MIR for  linux-exynos5 ?
[14:45] <pitti> hallyn: yes, but the init.d and unit names need to be identical
[14:47] <hallyn> can do - thanks
[14:47] <jamespage> arges, +1 please go ahead
[14:48] <arges> jamespage: ok cool. thanks
[14:48] <infinity> doko: No.
[14:48] <infinity> doko: It shouldn't be in main.
[14:48] <infinity> doko: component-mismatches is lying to you.
[14:50] <arges> tinoco: jamespage : one concern of the nova upload are if bugs 1219658, 1267191 are fixed in the utopic version of nova (its not entirely clear)
[14:50] <ubottu> bug 1267191 in nova (Ubuntu) " openstack-nova-compute service fails with - libvirtError: internal error: CPU feature `avx' specified more than once" [Undecided,New] https://launchpad.net/bugs/1267191
[14:50] <ubottu> bug 1219658 in nova (Ubuntu) "Wrong image size using rbd backend for libvirt" [Undecided,In progress] https://launchpad.net/bugs/1219658
[14:50] <jamespage> arges, lemme check
[14:51] <tinoco> arges: checking
[14:54] <hallyn> pitti: sorr, one more q - is there a .target representing "virtual filesystems (i.e. proc and sys) are mounted" ?
[14:55] <hallyn> local-fs is probably too much / too late;  oh, but maybe fine for cgmanager under systemd, as it's not needed for init there, duh
[14:57]  * xnox loves C++11 static_assert
[14:57] <xnox> __linux is not defined, ftw! =)
[15:02] <pitti> hallyn: that's already defined by basic.target, unless you specify DefaultDependencies=no all units can rely on those
[15:04] <tinoco> arges: rbd issue is applied
[15:05] <tinoco> checking other
[15:07] <tinoco> arges: other fix (cpu feature) is included but in a different source file (test_libvirt* changed to test_config)
[15:09] <tinoco> arges: i would say both are already applied to utopic nova-2014.2~2
[15:10] <hallyn> pitti: I want it to start as early as possible
[15:10] <pitti> hallyn: so not depending on anything will do that
[15:10] <pitti> hallyn: see man systemd.special: "Usually this should pull-in all mount points, swap devices, sockets, timers, and path units and other basic
[15:11] <hallyn> pitti: sys and proc will still be mounted?
[15:11] <pitti>            initialization necessary for general purpose daemons."
[15:11] <pitti> hallyn: I suppose you want all those
[15:11] <hallyn> the systemd manpages are hard to find :)  not found on my sid or trusty systems;  /me goes to manapges.ubuntu.com
[15:11] <pitti> err?
[15:11] <hallyn> still not
[15:12] <pitti> "man systemd.special"
[15:12] <pitti> oh, on utopic
[15:12] <hallyn> No manual entry for systemd.special
[15:12] <pitti> yes, we didn't have systemd on trusty
[15:12] <hallyn> yeah my utopic system is dead
[15:12] <hallyn> but also not found on unstable
[15:12] <hallyn> oh no, there it is
[15:13] <hallyn> didn't find dh_systemd_enable though
[15:13] <pitti> that's the dh-systemd build dep
[15:14] <hallyn> ok cool, so now i just need to figure out how to do some scripting before the service starts
[15:15] <pitti> hallyn: you can do stuff in ExecStartPre=
[15:15] <pitti> (man systemd.service for daemons, man systemd.unit for fields which apply to all units)
[15:15] <hallyn> pitti: thx
[15:17] <arges> tinoco: ok
=== timrc-afk is now known as timrc
[15:17] <doko> Noskcaj, dholbach: MIR's for jquery needed (or better get rid off this b-d)
[15:17] <dholbach> doko, that's for python-wsme?
[15:18] <doko> dholbach, no, that's a separate sync you sponsored
[15:18] <doko> http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
[15:18] <dholbach> doko, sorry, which package was that?
[15:18] <doko> jquery
[15:19] <dholbach> huh?
[15:19] <dholbach> I can't see it here: https://launchpad.net/ubuntu/+source/jquery
[15:20] <doko> dholbach, https://launchpad.net/ubuntu/+source/jquery/1.7.2+dfsg-3ubuntu1
[15:21] <dholbach> ah, I was just surprised, because you said "sync" - let me take a second look
[15:21] <doko> sorry, merge
[15:23] <hallyn> pitti: is there a way for a ExecStartPre to tell systemd to simply skip this service (contingnet on output of the command)?  like exit 2 or something?  I don't see it in the manpage
[15:23] <arges> tinoco: where is the testcase for bug 1219658 ?
[15:23] <ubottu> bug 1219658 in nova (Ubuntu) "Wrong image size using rbd backend for libvirt" [Undecided,In progress] https://launchpad.net/bugs/1219658
[15:25] <tinoco> arges: i changed description for "to be provided". i'll create my own tests. bugs were cloned from fedora. i put them together for a ppa (large install) and relied on real tests (fixed both bugs).
[15:25] <xnox> doko: https://bugs.launchpad.net/ubuntu/+source/gcc-4.9/+bug/1349907
[15:25] <ubottu> Ubuntu bug 1349907 in gcc-4.9 (Ubuntu) "gcc, powerpc with C++11 standard does not define __linux" [Undecided,New]
[15:26] <xnox> doko: looks like that's the root cause for llvm-3.5/powerpc build failure, and affects debian and ubuntu. And also looks like complete obscure.
[15:26] <arges> tinoco: can you describe the test case in that SRU section ? it doesn't have to be a script, but some explainination of what steps are required to see the issue
[15:27] <tinoco> arges: will do. gimme some minutes, i'll get back to you on this
[15:27] <doko> xnox, please use __linux__
[15:28] <xnox> doko: sure, but __linux and linux is defined on all other arches, and with a default standard on powerpc.
[15:29] <doko> xnox, and?
[15:29] <xnox> doko: any preference for __linux__ vs __linux preference? I personally see __linux used for the first time.
[15:30] <doko> <doko> xnox, please use __linux__
[15:30] <xnox> doko: and? -> well it causes FTBFS on powerpc of other packages, and it's not clear to me weather gcc-4.9 with C11 standard enabled is backwards incompatible here on powerpc only, or wether all code is wrong.
[15:31] <xnox> doko: why is __linux defined at other standards, and on other arches including C11 standard level?
[15:32] <xnox> right, I found https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28314
[15:32] <ubottu> gcc.gnu.org bug 28314 in target "cpp: x86/powerpc inconsistency for the __linux macro" [Normal,New]
[15:32] <xnox> which is good enough reference for me.
[15:33] <xnox> doko: which looks like reported by you =)
[15:33] <mitya57> bzoltan1: approved
[15:34] <xnox> thanks a lot!
[15:34] <doko> xnox, yes, and I won't change it on the package level
[15:34] <xnox> doko: excellent.
=== charles_ is now known as charles
[15:39] <doko> xnox, what is problem fixing llvm?
[15:42] <xnox> doko: no problem, wrote a patch, test building and will submit upstream.
[15:42] <xnox> (and upload into ubuntu)
[15:44] <mdeslaur> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
[15:51] <tinoco> arges: changed 1267191 [testcase]. could you please tell bugs 1319710 and 1303536 they are a duplicate of 1267191 ? I keep getting timeouts to mark them duplicate.
[15:51] <ubottu> bug 1319710 in OpenStack Compute (nova) "Live-migration failed with OpenStack Icehouse and Ubuntu 12.04 " [Undecided,New] https://launchpad.net/bugs/1319710
[15:51] <ubottu> bug 1303536 in OpenStack Compute (nova) "Live migration fails. XML error: CPU feature `wdt' specified more than once" [Medium,Fix released] https://launchpad.net/bugs/1303536
[15:52] <arges> tinoco: technically they aren't targeted to ubuntu/nova, so we don't really need to mark them duplicates
[15:53] <tinoco> arges: ah ok, perfect
[15:53] <tinoco> checking the rbd testcase (it will be the same as the previous bug since it is a fix to a regression patch)
[15:54] <arges> tinoco: ok can you update that too please
[15:54] <tinoco> ok
[15:57] <tinoco> arges: done.
[15:57] <dholbach> doko, followed up on the merge proposal - thanks
[15:57] <tinoco> arges: i think both are ok now, let me know if you need anything else on this. tks!
[16:00] <arges> tinoco: ok one more thing... did you change the urgency= field in the changelog?
[16:00] <tinoco> checking
[16:00] <arges> or rather why did you do it
[16:01] <tinoco> urgency=high
[16:01] <tinoco> there were some outages because of these... P1 bug was created to provide fix
[16:01] <arges> why was it changed from urgency=medium?
[16:01] <tinoco> i had to provide this fix in few hours to avoid outage
[16:04] <arges> tinoco: i don't think that translates to updating the changelog urgency field
[16:07] <rbasak> Is it just me, or has dch's default changed recently or something?
[16:07] <rbasak> I've seen much more variance in the urgency field recently
[16:08] <xnox> default is medium these days.
[16:08] <xnox> used to be low.
[16:08] <xnox> makes zilch of a difference. (like +/- a couple of build score points, in build queuing in ubuntu)
[16:09] <arges> tinoco: anyway yea shouldn't make any difference editing that field. no need to modify it now
[16:09] <tinoco> arges: ok, tks chris
[16:10] <xnox> tinoco: yeah, but that field is not the semantic meaning you are guessing it has =)
[16:10]  * xnox ponders why i like yoda speak
[16:10] <tinoco> xnox: yep. totally agree now. tks guys
[16:11] <arges> tinoco: np thanks for the fix, its been accepted
[16:12] <mpt> ev, any progress on the database migration?
[16:13] <tinoco> arges: great, updating here. tks!
=== psivaa is now known as psivaa-bbl
[16:26] <ev> mpt: the priority had to be dropped as IS just had to pick up a big project. We're working to make sure we don't put the existing data at risk as this gets put on hold.
[16:52] <rbasak> caribou or arges: please could you take a look at https://bugs.launchpad.net/ubuntu/+source/backuppc/+bug/1349031? Is this a botched merge?
[16:52] <ubottu> Ubuntu bug 1349031 in backuppc (Ubuntu) "ping6 is not configurable over web ui" [Wishlist,New]
[16:54] <arges> rbasak: i know caribou is away on holiday. and i'm trying to remember this one...
[16:56] <arges> rbasak: looking at the diff i don't see 'ping6' or 'ipv6' or anything of that sort
[16:57] <rbasak> arges: http://paste.ubuntu.com/7896530/ is what I see
[16:57] <rbasak> That's debdiff backuppc_3.3.0-1.dsc backuppc_3.3.0-1ubuntu1.dsc|pastebinit
[16:58] <arges> ok i was looking at http://launchpadlibrarian.net/162543633/backuppc_3.2.1-4ubuntu2_3.3.0-1ubuntu1.diff.gz
[16:58] <rbasak> Yeah that diff is against the previous Ubuntu package.
[16:58] <arges> yup yup. ok
[16:59] <arges> so that merge added functionality; why do you think it was botched?
[16:59] <shadeslayer> ev: https://errors.ubuntu.com/?user=kubuntu-bugs&period=month still doesn't work
[16:59] <arges> added the ping6 functionality
[17:00] <ev> shadeslayer: bdmurray just arranged for a deployment containing that change
[17:00] <ev> should be up soon
[17:00] <shadeslayer> thx :)
[17:00] <rbasak> arges: it's not mentioned on the changelog
[17:00] <rbasak> arges: it looks to me (superficially, anyway) that Debian or upstream changed something about it, and what Ubuntu had before got carried forward, instead of taking upstream changes.
[17:01] <arges> rbasak: yup which is why the diff from the previous ubuntu version doesn't show that change. its a specific ubuntu patch somewhere
[17:02] <rbasak> arges: right, but were upstream changes in this area considered for this merge? The missing changelog entry suggests not.
[17:02] <rbasak> arges: are we sure that this cannot just be dropped?
[17:02] <rbasak> arges: because I see no mention of an addition of anything to do with ping6 in the previous changelog.
[17:03] <rbasak> arges: say for example that there was a bug, and upstream fixed it. If we carry forward what we had before, then we'll exclude that.
[17:04] <rbasak> arges: that seems to be the simplest explanation to me (at a cursory glance). Either that or a delta was introduced and I haven't found it documented anywhere.
[17:04] <bdmurray> ev: i think it has landed but the cronjob may not have run yet
[17:04] <arges> rbasak: so I'm not sure with this. I would look at the full changelog to see if this is documented anyway (in the Ubuntu version or Debian version). And if not try dropped it and test to see if we have the same functionality and it fixes that bug
[17:06] <bdmurray> ev, shadeslayer: it runs once a day so should work tomorrow
[17:07] <shadeslayer> bdmurray: thx
=== Ursinha-afk is now known as Ursinha
=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
=== roadmr is now known as roadmr_afk
[18:05] <sarnold> Trevinho: smells like a duplicate of something else recently: 1349953
[18:06] <sarnold> Trevinho: and another instance of the password going into a previously active client: 1349961
[18:41] <doko> zul, commented on python-keystonemiddleware. there are a lot more missing MIR's
=== Ursinha-afk is now known as Ursinha
[18:42] <zul> doko:  thanks
=== psivaa-bbl is now known as psivaa
=== roadmr_afk is now known as roadmr
=== Logan__ is now known as Logan_
=== juliank0 is now known as juliank
=== salem_ is now known as _salem
=== _salem is now known as salem_
=== salem_ is now known as _salem
[21:59] <Noskcaj> ScottK, Could you help me with python-wsme's component missmatches?
[22:02] <Noskcaj> A few releases ago the debian maintainer added build-depends on a few things in universe, which got dropped without a changelog entry when you merged it. I have since had the package synced, and now i can't get the package to build from source because of some tarball strangeness
=== Guest83948 is now known as Adri2000