=== rsalveti_ is now known as rsalveti
[01:32] <Logan_> siretart: probably as early in the cycle as possible
=== negronjl-afk is now known as negronjl
=== broder_ is now known as broder
=== TheDrums is now known as DalekSec
=== inaddy is now known as tinoco
[04:32] <mitya57> cjwatson: Thanks, will try to do something.
[05:00] <pitti> Good morning
[05:01] <pitti> mapreri: or try on IRC? (ping u-studio)
[05:01] <pitti> mapreri: and if they don't answer soon, just upload; I can't imagine that this is that important for them, this was mostly from the ancient days of Ubuntu itself
[05:05] <pitti> erk -- gnome-packagekit provides a transitional update-notifier now --- no!?
[05:07]  * pitti removes it, but now we have to bump our u-n's version
[06:41] <dholbach> good morning
=== rodarvus` is now known as rodarvus
=== mpt_ is now known as mpt
[08:21] <dpm> hi xnox, good morning. When you've got a minute, could you review https://code.launchpad.net/~dpm/reminders-app/fix-1317977-openssl-exception/+merge/219037 ?
[08:22] <dpm> we're trying to do a release of Reminders with the new design today, and that's the latest branch that needs review before we generate the .click
[08:28] <ev_> pitti: thanks for adding systemd support to whoopsie!
=== ev_ is now known as ev
[08:31] <pitti> ev: heh, yw; it was the first I stumbled across, so it became my guinea pig :)
[08:33] <ev> :D
=== Sweetsha1k is now known as Sweetshark
=== doko_ is now known as doko
[09:46] <pitti> xnox: hey Dimitri, how are you?
[09:46] <pitti> xnox: FYI, I locally fixed the insserv path in update-rc.d (that's the only delta compared to the merge I uploaded to people.c.c on Friday)
[09:46] <pitti> xnox: did you change anything else since then?
[09:47] <pitti> xnox: I also uploaded a pure backport of systemd support for invoke-rc.d and service to utopic-proposed, so that the full merge doesn't block the other enablement work
[09:47] <pitti> (and sent two patches to Debian's sysv-rc for invoke-rc during that)
[10:17] <pitti> bdmurray: FYI, I uploaded an apport trusty SRU for bug 1282349 and bug 1316841
[10:17] <ubottu> bug 1282349 in apport (Ubuntu Trusty) "Crashes on invalid/broken core dumps when using "Show details..."" [High,In progress] https://launchpad.net/bugs/1282349
[10:17] <pitti> seb128: ^ FYI
[10:17] <ubottu> bug 1316841 in apport (Ubuntu Trusty) "apportcheckresume does not create a duplicate signature" [Undecided,In progress] https://launchpad.net/bugs/1316841
[10:17] <seb128> pitti, danke!
=== vrruiz_ is now known as rvr
[10:46] <pitti> cjwatson: I think https://code.launchpad.net/~jibel/britney/fix_missing_results/+merge/218467 is ready to go now
[10:46] <pitti> cjwatson: would you be the best person to review this, and have some time for this, or someone else from the release team?
[10:47] <cjwatson> That'd be me.  I'll have a look shortly, thanks
[10:48] <pitti> thanks
=== MacSlow is now known as MacSlow|lunch
[11:00] <cjwatson> pitti: Would it be helpful if I merged your old test suite branch first (TBH I had basically just forgotten about it) or would that just confuse matters at this point?
[11:06] <cjwatson> pitti: Oh, I didn't merge it because there was still a failing test
[11:06] <cjwatson> (I guess)
[11:09] <bulletxt> hi, what can we do to get ExifTool package update from 9.40 (november 2013) to a way more updated one ? Newer version supports plenty of more stuff and cameras. Thanks a lot
[11:10] <bulletxt> I meant 9.46 sorry (jan 11 2014)
[11:11] <cjwatson> It's at 9.60 in utopic.  We don't normally do wholesale upstream updates in stable releases.
[11:11] <cjwatson> See https://wiki.ubuntu.com/StableReleaseUpdates if there are specific fixes that need to be applied to stable releases - but they probably ought to be done by selective backports, not by a wholesale update.
[11:11] <cjwatson> Or https://wiki.ubuntu.com/UbuntuBackports is possible too.
[11:14] <bulletxt> ok I guess I should ask for a backport then
[11:59] <dpm> hi, could someone with experience with licenses help us review an easy MP? It seems xnox is not around today, and we're blocking on this one to do a release for Reminders today, so any help would be welcome: https://code.launchpad.net/~dpm/reminders-app/fix-1317977-openssl-exception/+merge/219037
[11:59] <dpm> thanks!
=== MacSlow|lunch is now known as MacSlow
[12:03] <pitti> cjwatson: it would actually help, yes; otherwise we'd need to remove the tests from jibel's branch again and re-apply it to my tests branch
[12:03] <pitti> cjwatson: yes, there's a failing test; it's not the end of the world, it's just a case I thought of when writing those; but I'm fine with adding an @expectedFailure for now
[12:04] <cjwatson> pitti: Yeah, please xfail, I don't want to merge something with failing tests in general as it'll cause people to assume the tests are broken and not run them :)
[12:05] <pitti> cjwatson: pushed
[12:05] <cjwatson> ta
[12:05] <pitti> cjwatson: to https://code.launchpad.net/~canonical-platform-qa/britney/tests/+merge/207982
[12:05] <pitti> cjwatson: sorry for delay; weechat notifications apparently broke, will check after lunch
=== josepht_ is now known as josepht
[12:22] <Mirv> arm64 porters might be interested in "gcc: internal compiler error: Segmentation fault (program cc1)" in the latest qtbase upload
[12:22] <Mirv> it did build for trusty with the same patch for all archs, and the previous utopic upload built fine, that's why I did a direct dput this time
[12:23] <cjwatson> doko: ^-
[12:26] <doko> Mirv, can you check with gcc-4.9 please?
[12:28] <Mirv> doko: the way for me to test arm64 would be to use a CI Train landing silo, but there are so few available that I wouldn't want to take one of those for testing as the first option.
[12:29] <doko> ok
[12:30] <Mirv> doko: arm64 only anyhow, ppc64el/powerpc seem fine: https://launchpad.net/ubuntu/utopic/+source/qtbase-opensource-src/5.2.1+dfsg-1ubuntu16
[12:36] <Mirv> I filed bug #1318635 for it
[12:36] <ubottu> bug 1318635 in gcc (Ubuntu) "qtbase failed to build on arm64 on utopic" [Undecided,New] https://launchpad.net/bugs/1318635
[12:41] <doko> Mirv, when did you enable pch?
[12:41] <doko> Mirv, this is something that should not be enabled for package builds, makes debugging compiler bugs nearly impossible
[12:43] <doko> Mirv, any reason to use the bundled pcre?
=== _salem is now known as salem_
[12:45] <cjwatson> pitti: Thanks, merged that now, so I guess the next step is to rebase jibel's branch on top of that
[12:45] <cjwatson> We probably shouldn't have two nearly-identical test suites :-)
[12:48] <Mirv> doko: it was always enabled, but there is an optional no_pch_architectures which currently includes armel, armhf and ia64 (comes from Debian)
[12:48] <Mirv> doko: I'm not sure if anyone has checked pcre, usually as much of system libraries are used as can be enabled
[12:52] <Mirv> I'm checking with Debian packagers if they've tried -system-pcre and disabled it for a reason
[12:54] <pitti> cjwatson: jibel's branch started off from the tests/ branch, so it shuold just merge cleanly
[12:57] <cjwatson> pitti: It appears to add a slightly different file name, tests/test_autopkgtest.py rather than tests/autopkgtest.py
[12:58] <cjwatson> pitti: Though perhaps LP isn't rescanning it due to the "Work in progress" status?
[12:58] <cjwatson> pitti: Can you set this to "Needs review" if it's ready to land?
[12:58] <pitti> jibel: ^
[12:58] <pitti> cjwatson: yes, jibel's branch had to rename it to avoid an import name conflict
[12:59] <pitti> jibel: I think you ought to merge from trunk again, to pick up the exfail
[12:59] <cjwatson> Ah, if it's just a renaming I'll be fine with that
[12:59] <pitti> or just bzr merge and look at the diff locally
[12:59] <pitti> cjwatson: the renaming is already in teh LP MP; this is just missing the @exfail addition
[13:02] <jibel> pitti, cjwatson I merged from trunk
[13:03] <cjwatson> Thanks.  I'll meditate on the diff for a while :)
=== tedg is now known as ted
[13:35] <tsdgeos> tkamppeter: is there any change we can get http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=3c4cfba8 in ubuntu packages of gs9.14 ?
[13:55] <doko> Mirv, this works for me disabling pch, at least on arm64
[14:21] <bdmurray> pitti: ah, thanks for that. maybe the changelog should reference bug 1316845?
[14:21] <ubottu> bug 1316845 in apport (Ubuntu) "apportcheckresume does not contain package version" [High,New] https://launchpad.net/bugs/1316845
[14:21] <pitti> bdmurray: ah, I didn't see a bug ref in the MP; will reupload
[14:22] <bdmurray> pitti: thanks
[14:27] <cjwatson> +            i = iter(linebits[3:])
[14:27] <cjwatson> +            for trigsrc, trigver in zip(i, i):
[14:27] <cjwatson> jibel: ^- is that meant to be a "take two elements at a time" gadget or something?  It seems rather opaque
[14:28] <jibel> cjwatson, it is
[14:28] <cjwatson> jibel: I don't see any reason to suppose that it's well-defined which order zip fetches from the two copies of the same iterator
[14:29] <pitti> bdmurray: reuploaded
[14:34] <cjwatson> jibel: You could use the "grouper" recipe from https://docs.python.org/2/library/itertools.html - but perhaps it would be clearer to just pop two at a time the way the previous code did?
[14:35] <cjwatson> Oh, https://docs.python.org/2/library/functions.html#zip does say the ordering is guaranteed
[14:35] <cjwatson> Mm, OK
[14:35] <debfx> ScottK: the bug subscription is missing for the new backports projects
[14:36] <jibel> cjwatson, I can revert that part if you think it's clearer.
[14:37] <cjwatson> I don't mind too much now that I've worked through it
[14:44] <pitti> \o/
[14:44] <pitti> thanks cjwatson for the review
[14:44] <pitti> so that means, no propagations of stuff which is known-broken any more?
[14:44] <pitti> and propagating stuff with broken tests
[14:44] <pitti> thanks jibel
[14:49] <wschmidt> xnox: infinity suggested that you might be interested in this:  https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1318690
[14:49] <ubottu> Launchpad bug 1318690 in emacs24 (Ubuntu) "emacs aborts for ppc64el in 14.04" [Undecided,New]
[14:50] <wschmidt> thanks for any help!
[15:01] <cjwatson> pitti: Let's hope so :)
[15:03] <cjwatson> jibel,pitti: I think we might still have tests stuck in RUNNING?  See e.g. apport under sysvinit
[15:03] <jibel> cjwatson, thanks for your review.
[15:05] <jibel> cjwatson, we still have tests stuck in 'RUNNING'. That's a problem in the reconciliation of  the results from the new autopkgtest in Utopic. I'm on it
[15:05] <cjwatson> Right
[15:06] <hkraal> When having trouble rebuilding my own version of a Ubuntu package where can I drop my question better here or in regular #ubuntu?
=== tgm4883_ is now known as tgm4883
=== iulian_ is now known as iulian
=== pete-woods is now known as pete-woods-lunch
[15:15] <dobey> hkraal: #ubuntu-packaging perhaps
[15:16] <hkraal> alright, gonna try there, thnx
[15:23] <ScottK> debfx: Fixed.  Thanks.
[15:32] <bdmurray> barry: could you add some SRU details to bug 1317660?
[15:32] <ubottu> bug 1317660 in pexpect (Ubuntu) "[SRU] Bug: AttributeError: 'error' object has no attribute 'errno'" [High,In progress] https://launchpad.net/bugs/1317660
[15:32] <barry> bdmurray: yep
[15:32] <bdmurray> barry: thanks, let me know and I'll accept it
[15:34] <pitti> jodh, xnox: ah, so in bug 1312836 I discovered that we generally don't call update-rc.d to enable rc?.d/ symlinks for init.d scripts when there's a corresponding upstart job
[15:34] <ubottu> bug 1312836 in ifupdown (Ubuntu) "[systemd] /etc/init.d/networking not enabled" [Undecided,Triaged] https://launchpad.net/bugs/1312836
[15:34] <pitti> jodh, xnox: in this case, we don't have an S??networking to call /etc/init.d/networking as there's /etc/init/networking.conf
[15:35] <pitti> jodh, xnox: would upstart try to run /etc/rc*/S??foo if there's an /etc/init/foo.conf?
[15:35] <pitti> i. e. could we add these init.d symlinks without harm, or would upstart then run both?
[15:38] <mmazing> does unity in 14.04 still use dbus for the panel icons?
[15:39] <bdmurray> superm1: Do you want to use bug 1309553 (referenced by a mythbuntu-common uploaded) instead of bug 1290460 for the bytes password issue?
[15:39] <ubottu> bug 1309553 in mythbuntu-live-autostart (Ubuntu Trusty) "Mythbuntu Installer Crash enabling VNC" [Medium,In progress] https://launchpad.net/bugs/1309553
[15:39] <ubottu> bug 1290460 in mythbuntu-common (Ubuntu Trusty) "Mythbuntu Installer Crashes: File "/usr/lib/python3/dist-packages/mythbuntu_common/vnc.py", line 58, in create_password ValueError: Password should be passed as bytes" [High,In progress] https://launchpad.net/bugs/1290460
[15:40] <superm1> bdmurray: either way is fine with me
[15:40] <bdmurray> rather, than change the upload I'll mark bug 1290460 as a duplicate of the other
[15:41] <pitti> xnox, jodh: I posted the question on that bug and sub'ed you; probably better to keep the disussion there
[15:45] <pitti> jibel: ah, shiny colors on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html :)
[15:45] <pitti> jibel: is the wrong "running" a result of that ordering fix? it seems unlikely as this sohuldn't affect the format or writing of the results files
[15:47] <pitti> jibel: I uploaded two sysvutils this morning in relatively quick succession and they both triggered half of the world; that might have confused it?
[15:50] <cjwatson> pitti: 16:05 <jibel> cjwatson, we still have tests stuck in 'RUNNING'. That's a problem in the reconciliation of  the results from the new autopkgtest in Utopic. I'm on it
[16:13] <pitti> xnox: I did the first testing/followup on bug 1316712
[16:13] <ubottu> bug 1316712 in plymouth (Ubuntu) "systemd unit support needs testing from -proposed" [Undecided,In progress] https://launchpad.net/bugs/1316712
[16:21] <cjwatson> jibel: For autopkgtest regression detection, do we carry over history from series to series?
[16:22] <jibel> cjwatson, no, that was one of the comment from pitti, it must be done manually when opening a new release.
[16:23] <cjwatson> Might be worth putting that in NewReleaseCycleProcess
[16:23] <jibel> cjwatson, right, I'll update the wiki
=== fginther is now known as fginther|lunch
=== fginther|lunch is now known as fginther
[16:44] <ogra_> slangasek, do you happen to know why resize2fs just blindly resizes images even though its manpage claims it will not touch underlying partitions ? ... i.e. why does something like http://paste.ubuntu.com/7453165/ work without resizing the physical img ... is that a bug or a feature ?
[16:47] <slangasek> ogra_: well, you have no partition; if resize2fs knows you're working with a file rather than a partition, why should it refuse to extend it?
[16:47] <ogra_> dunno, i find the manpage entry confusing then
[16:47] <ogra_> The resize2fs program does not manipulate the size of partitions.  If you wish to enlarge a filesystem, you must make sure
[16:47] <ogra_>        you  can expand the size of the underlying partition first.
[16:47] <ogra_> effectively the img file is a partition in my view
[16:48] <ogra_> (i mean, it is nice that it works, but it would even be nicer if the manpage would tell me about it :) )
[16:49] <slangasek> it's not a partition, there's no partitioning
[16:50] <ogra_> ah, so it recognizes that ? ok
=== schmidtm_ is now known as schmidtm
=== pete-woods-lunch is now known as pete-woods
[17:45] <sergiusens> is it possible to rebuild in a different builder? seeing a weird trace while building on ross https://launchpad.net/ubuntu/+source/nuntium/0.1-0ubuntu2/+build/6002151
[17:46] <ScottK> sergiusens: retry the build and see if you get lucky.  They only way to reliably do it is to shut down the builder.
[17:49] <sergiusens> it's already been rebuilt once; failed the same way; seems the gccgo-go tool is crashing
=== roadmr is now known as roadmr_afk
[18:01] <ScottK> sergiusens: Running on adare.
=== roadmr_afk is now known as roadmr
[18:05] <barry> bdmurray: https://bugs.launchpad.net/ubuntu/+source/pexpect/+bug/1317660/comments/1
[18:05] <ubottu> Launchpad bug 1317660 in pexpect (Ubuntu) "[SRU] Bug: AttributeError: 'error' object has no attribute 'errno'" [High,In progress]
[18:08] <sergiusens> thanks ScottK, sadly it still fails; I wonder how it worked on the first package  build :-/
[18:08] <ScottK> No idea, but at least you know it's not buildd specific.
[18:08] <bdmurray> barry: are the files supposed to be attached to the bug or are they part of the upload?
[18:09] <sergiusens> yeah, no I only need powerpc hw :-)
[18:10] <infinity> sergiusens: You have access to a porter machine.
[18:14] <infinity> Doesn't look like gccgo-go has changed in that time either, so I'd guess it's GCC itself that's introduced some new fun.
[18:14] <infinity> But I'll try building it on the machine where it worked last time for kicks.
[18:14] <sergiusens> in the last 3 days though?
[18:15] <sergiusens> it would be surprising if it worked :-)
[18:15] <infinity> 3 days?  Oh, it really was only 3 days.
[18:15] <infinity> Weird.
[18:16] <sergiusens> yeah, it may have worked out of luck, but now I get stuck on proposed (at least that's what I read from excuses)
[18:17] <infinity> Not a big fan of the idea that that only works sometimes because we're lucky. :P
[18:18] <sergiusens> well it was the first build ever on powerpc, so it was 50/50 :-)
[18:18] <barry> bdmurray: d'oh!  attached
[18:20] <infinity> sergiusens: Built fine on sagari.  So, other than being a much newer machine, the most obvious difference there would be 24G of RAM instead of 2G.  Is it possible that process was OOMing on ross and adare?
[18:20] <sergiusens> I am seeing that the gccgo-go tool has been stripped which may be the reason I see a panic on panic in the build
[18:21] <sergiusens> infinity: the stack trace is incomplete to know, but it seems the gccgo-go tool was trying to access/deref some nil pointer
[18:21] <infinity> sergiusens: Fun.  Well, worth experimenting with some time, but you're unstuck for now.
[18:22] <sergiusens> thanks, I'll see if I can get better traces from these crashes
[18:23] <sergiusens> rsalveti: ^^ built fine with more ram btw
[18:23] <rsalveti> interesting
[19:06] <infinity> sergiusens: Well, "more RAM" is a guess, it could also be the type of CPU.  Maybe gccgo on ppc is making faulty assumptions about the port baseline and compiling things for POWER7 instead of older CPUs.
[19:07] <infinity> sergiusens: Though, one would expect a SIGILL in such cases.
=== salem_ is now known as _salem
[20:50] <bekks> hi
[20:51] <bekks> Out of curiousity, I want to know how automated (since I doubt that THAT number of packages is being built manually almost JIT) package building for utopic actually is being managed/done?
[20:54] <mwhudson> is it the case that the ubuntu and debian packaging of libvirt are very diverged?
=== _salem is now known as salem_
[20:56] <dobey> bekks: what do you mean exactly?
=== apachelogger is now known as jellyfish
[20:58] <bekks> I guess building the packages for any new release is being done automagically somehow. The sheer number of package (>30k) would make it impossible to "edit the build instructions manually, compile the package, package it, release it) while utopic isnt event in beta state would take ages.
[20:58] <bekks> So I assume this is being done automagically, while taking trusty as "base", and automagically "port" the trusty packages to utopic, so further work on them can take place.
[20:59] <Unit193> bekks: If the package isn't blacklisted and contains no Ubuntu delta, it's sync'd from Debian.
[20:59] <dobey> right, the base is debian
[21:00] <bekks> So in first place, the "debian upstream" is taken, automatically adapted to the new release. And all packages containing ubuntu deltas are being built/adapted manually?
[21:09] <dobey> no, packages that have ubuntu deltas are not automatically synced from debian
[21:10] <dobey> they are copied from the stable release to the new development release when the new dev archive is opened
=== lisca is now known as klubko
[21:43] <bdmurray> pitti: ltrace version 0.7.3-4ubuntu5.1 is missing from ddebs
[21:52] <cjwatson> bekks: For the majority of packages, no "adaptation" is needed - the source package from Debian builds without modifications on Ubuntu
[21:52] <cjwatson> This is indeed rather essential for us being able to scale
[21:53] <cjwatson> bekks: And we don't rebuild everything from trusty to utopic - if there's no new source package then it isn't rebuilt
[21:55] <cjwatson> bekks: Our archive (like Debian's) supports having the exact same source+binaries published in more than one place - so for trusty, utopic, etc.  Some rarely-modified packages are published at the same versions all the way back for many releases
=== TheMuso` is now known as TheMuso
=== jono is now known as Guest3239
[23:41] <bekks> dobey, cjwatson: thanks for the information :)
[23:45] <cjwatson> bekks: http://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/view/head:/auto-sync is the top-level script we run every six hours (when not frozen) to copy non-Ubuntu-modified packages from Debian, although of course that relies on a bunch of other infrastructure in Launchpad