[01:14] <infinity> pitti: We'll want to probably turn that into an SSO-gated web service at some point, so we can keep the "if you can upload, you can retry tests" paradigm.  But it's probably fair to say that not many people do that right now (and it's also unfortunately limited to just Canonical), so we can live with a bit of a regression while we sort it.
[01:16] <infinity> pitti: Oh, and I see both Laney and slangasek already covered that.  Nevermind. :P
[04:18] <pitti> Good morning
[04:18] <pitti> bdmurray: I do, yes; I want to loo into bug 1474539 still
[04:18] <ubottu> bug 1474539 in apport (Ubuntu Wily) "FTBFS with Python 3.5" [High,In progress] https://launchpad.net/bugs/1474539
[04:19] <pitti> infinity: how is it a regression? non-canoncial folksk can only see the public jenkins which is read-only like autopkgtest.u.c.
[04:19] <infinity> pitti: It's a regression because now even fewer people have access than before.
[04:19] <pitti> infinity: and we can make run-autopkgtest available for everyone in canonical (if we widen the firewall to allow more hosts than just snakefruit)
[04:20] <infinity> pitti: Sure, if it was accessible from lillypilly or something, but then that would be a regression in another direction, if you're doing no authorization agaisnt LP creds, since now non-devs would be able to abuse it.
[04:20] <infinity> pitti: Ultimately, it should have the same permissions that "retry a build" has in LP itself, that is, anyone who can upload should be able to retry.
[04:21] <infinity> s/who can upload/who can upload that package/
[04:21] <pitti> I didn't do SSO yet; do you happen to know some doc pointers how to do that?
[04:22] <infinity> pitti: Not so much, no.  I'd probably ask William for pointers in the right direction.
[04:22] <pitti> well, I guess I'll ask on canonical-tech@ after my holidays
[04:23] <pitti> I have about three day's worth of stuff to catch up with today already anyway :)
[04:23] <infinity> pitti: Heh.  Yeah, this isn't critical, especially since it's running in parallel until you get back.
[04:23] <pitti> ok, gutenprint is being ridiculous: http://autopkgtest.ubuntu.com/packages/g/gutenprint/wily/i386/
[04:24] <pitti> I bumped the timeout three times, I introduced a "long tests" category yesterday with a timeout of ~ half a day
[04:24] <infinity> pitti: But we definitely don't want snakefruit-only people to become the gateway for this, and I'd rather not see "anyone with a lillypilly account can mangle any test" either.
[04:24] <pitti> and it's *still* not enough
[04:24] <pitti> infinity: ~ubuntu-core-dev sounds about right for now, I'd say
[04:24] <infinity> pitti: Though, having the "webapp" bit stay on snakefruit might not be awful.  And then a small CGI that does proper LP validation, and a CLI tool in ubuntu-dev-tools that talks to that?
[04:25] <pitti> Canonical folks in ~ubuntu-core-dev, I mean
[04:25] <infinity> pitti: It certainly doesn't need a pretty GUI.
[04:25] <pitti> we don't really want to open this up too wide, especially not once we start supporting PPAs
[04:25] <infinity> pitti: I disagree.
[04:26] <infinity> pitti: I had the very same knee-jerk reaction/argument that you did about resource usage and the "retry" button on LP.
[04:26] <pitti> we don't even yet have enough capacity to keep up with the flood at peak times now
[04:26] <wgrant> pitti: OpenID integration is pretty easy for you. Use python-openid (probably without a team restriction) against login.ubuntu.com, then use launchpadlib's lp.people.getByOpenIdIdentifier to look up a person which you can give to archive.checkUpload for permission checks.
[04:26] <infinity> pitti: But, in the end, it seems that people fall into a few groups: 1) people who know how it works and have access and don't abuse it, 2) people who don't know how it works and never press it, 3) people who abuse resources by retrying over and over.
[04:26] <infinity> pitti: The size of set 3 is tiny.
[04:26] <infinity> pitti: And when we find them abusing resources, we yell at them and carry on.
[04:27] <pitti> infinity: okay
[04:27] <pitti> checkUpload() seems fine to me
[04:27] <pitti> those are people who have been vetted at some point
[04:27] <infinity> pitti: Anyhow, since you're now sharing the same cloud as LP buildds, same rules applying also makes sense.  Jerks will be jerks, but they're actually amazingly rare.
[04:27] <pitti> I just really don't want to open this up to the whole world
[04:27] <infinity> pitti: And we employ most of them, so they already have access in the canonical+core-dev set. :P
[04:27] <infinity> *cough*
[04:29] <pitti> wgrant: ack, I'll look into that; I'll file a bug for now to record this
[04:30] <infinity> pitti: Of course, we'd all like to live in a world where the infra is so reliable that retries never need to happen, because a failure is always a real failure, but I'm pretty sure we'll never get there. :)
[04:30] <pitti> bug 1475491
[04:30] <ubottu> bug 1475491 in Auto Package Testing "provide web-based "retry test" functionality" [Undecided,New] https://launchpad.net/bugs/1475491
[04:30] <infinity> (We sure never got there with package builds)
[04:30] <pitti> yeah, for sure
[04:31] <pitti> we can do better than the current infra for "temp" failures (uninstallable, weird test bed boot/reboot failures), but there's enough left
[04:31] <pitti> right now I do most retries due to testbed failures
[04:31] <pitti> and that's what I'd like to reduce massively
[04:31] <infinity> pitti: Yeahp.  Temp/testbed failures not happening would be a huge help.
[04:31] <pitti> so that most retries should then be for flaky tests
[04:32] <pitti> like this pitti guy whose udisks2 tests are flapping *cough*
[04:32] <infinity> pitti: But then, the nature of autopkgtest being integration tests means that Package B will fail because Package A sucks, so fixing A means I need to retry B.  Putting that power in the hands of developers helps a lot.
[04:32] <pitti> so, what do I do about gutenprint..
[04:32] <infinity> pitti: Though, I suppose we could also be smarter about retriggering in such cases?
[04:32] <pitti> infinity: no, if you upload A, B will re-run automatically
[04:32] <infinity> pitti: remove-package -m "lolwut" gutenprint
[04:33] <pitti> I can't imagine that the DD is actually running these successfully
[04:33] <infinity> pitti: Only if A and B are hard interdependents.  Something, somewhere, will always be broken in an unexpected way.
[04:33] <pitti> oh, OdyX -- I'll ask him
[04:33] <infinity> pitti: Like, say, the "ddebs was bust, so crash tests failed" case.
[04:33] <pitti> infinity: right; transitive deps, etc.
[04:34] <pitti> infinity: I'm not arguing to take away the retry button :)
[04:34]  * infinity nods.
[04:34] <pitti> just saying that I didn't get to implementing one yet
[04:34] <infinity> MAKE IT BIG AND SHINY.
[04:34] <pitti> it's like systemd -- one-man show, too much to do, the less important stuff has to wait :)
[04:35]  * pitti does the daily libreoffice retry (speaking about flappy tests)
[04:36] <pitti> once the cloud stuff becomes primary in britney and it actually tells apart between always fail/regression, I'm really pondering to have britney retry a regression once
[04:36] <infinity> pitti: I wonder if we could do flap detection based on history.  ie: if a test's recent history is >> 33% fail (or some arbirtary number), retry a few times.
[04:37] <pitti> infinity: yes, britney can do that, it has the test history in a big dict
[04:37] <infinity> pitti: And once that creeps back up to 100% (fail or success), back off.
[04:37] <pitti> infinity: so "retry once after a regression" or retry more often based on pass percentage etc., but I figure the above simple thing should already help
[04:37]  * didrocks remembers to have been yelled to propose that to the QA team a couple of years ago (even if we still put a warning that this testsuite was flacky)
[04:37] <pitti> if it fails more often, then the dev should really do something about it
[04:37] <pitti> ooohh, a didrocks !
[04:37] <didrocks> for autopilot tests, not autopkgtests at the time
[04:38] <didrocks> hey pitti ;)
[04:38] <pitti> didrocks: bienvenue !
[04:38] <pitti> didrocks: as-tu eu des bonnes vacances ?
[04:38]  * pitti te donne une accolade
[04:38] <didrocks> pitti: merci ! oui, les vacances étaient superbes ;)
[04:38]  * didrocks donne une accolade en retour
[04:38] <infinity> didrocks: For tests originating from Ubuntu/Canonical, I think it's sane to set the bar higher.
[04:39] <infinity> didrocks: For tests we inherit from Debian, while we should certainly file bugs and ask them nicely to fix things, it's annoying to be "held hostage" by racy/flapping tests.
[04:39] <pitti> didrocks: well, we had higher standards back then indeed; but since then infinity's and my retry finger went sore
[04:39] <didrocks> infinity: yeah, but when it ends up on people doing the production to press "retry" because nobody fixes… :/
[04:39] <pitti> TBH a lot of the Debian tests we import just always fail, and they aren't that much of a problem
[04:39] <infinity> didrocks: I think "my finger hurts" is totally a good reason to yell at my coworkers to fix their *!^%! tests.
[04:39] <pitti> the biggest problem there is when they regress and nobody fixes them
[04:39] <infinity> didrocks: But for inherited tests, I'd rather build in some slop.
[04:40] <didrocks> agreed in some way. And yeah, the biggest risk is this "this should be a flaky tests", when actually, it started to be a flaky regression
[04:41] <infinity> didrocks: Quite.  If the test itself is working as advertised, but the code its testing has become nondeterministic/racey/whatever, that's harder to notice.
[04:42] <infinity> And, honestly, unless we start tracking metrics and hitting developers over the head with test *history*, it's not a thing we're currently dealing with.
[04:42] <infinity> Our test strategy is very binary.
[04:43] <didrocks> yeah, and sometimes random as well, just based on gut feeling if things needs to enter or not because of time-constraint
[04:43] <infinity> We certainly have the data to make it non-binary, though, we just need to figure out how to present that to people.
[04:43] <didrocks> and not hurt feelings
[04:43] <didrocks> while still showing up responsabilities (and the ownership feeling that people should have anyway)
=== Spads_ is now known as Spads
=== mnepton is now known as mneptok
=== ev_ is now known as ev
=== broder_ is now known as broder
=== salem_ is now known as _salem
[06:02] <Mirv> scaling stack builders broken? https://launchpadlibrarian.net/211871932/buildlog_ubuntu-wily-amd64.qtdeclarative-opensource-src-gles_5.4.2-0ubuntu5_BUILDING.txt.gz
[06:03] <Mirv> "long apt-get: relocation error: /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12: symbol _ZTVNSt7__cxx1119basic_istringstreamIcSt11char_traitsIcESaIcEEE, version GLIBCXX_3.4.21 not defined in file libstdc++.so.6 with link time reference"
[06:03] <Mirv> -long
[06:04] <Mirv> or I think this is related to the GCC5 silo only ^ doko
[06:09] <doko> urgh, let me look
[06:09] <doko> Mirv, argh, wrong config :-/ will fix
[06:43] <doko> Mirv, fixed gcc building
[06:43] <doko> Mirv, for local chroots, you might want to downgrade apt
[06:44] <Mirv> doko: thanks
[07:38] <doko> mvo, apt ping
=== marcusto_ is now known as marcustomlinson
[07:53] <mvo> doko: should I add a workaround for the miscomplication with gcc-5? I can do that and upload with a abi change to the ppa - or should we force -O2 everywhere?
[08:08] <doko> mvo, yes, please do. and forcing -O2 for now
=== Daviey_ is now known as Daviey
[10:47] <Mirv> mitya57: heya! any idea what's causing the pyqt5 autopkgtest regression? it's blocking a qtdeclarative landing, but failed already on Wednesday (last successful run on Saturday): https://jenkins.qa.ubuntu.com/job/wily-adt-pyqt5/ARCH=i386,label=adt/
[10:50] <Mirv> maybe it's related to recent python-apt uploads rebuilding for python3.5
[10:55] <doko> Mirv, gcc-5 fixed again in silo16 (armhf still building). if you upload before the build finishes, then b-d on gcc-5 (>= 5.1.2-11)
[10:56] <Mirv> doko: thanks! I'll just kick a rebuild as possible the one upload I already did.
[10:56] <Mirv> (wily got updated so therefore another upload to 016 too)
[11:03] <pete-woods> packaging question - my builds have started failing on wily very recently
[11:03] <pete-woods> an it looks like this bit of debian/rules that I didn't write is going wrong: http://paste.ubuntu.com/11892236/
[11:03] <pete-woods> it looks like it installs the .py stuff for the autopilot tests for the package (indicator-network)
[11:03] <pete-woods> this feels like copy/pasted code
[11:04] <pete-woods> so just wondered if there was a newer "canonical" version of this magic lump of stuff
[11:04] <pete-woods> or if it should be doing something different altogether
[11:05] <pitti> how does it go wrong?
[11:05] <pete-woods> pitti: https://launchpadlibrarian.net/211892414/buildlog_ubuntu-wily-amd64.indicator-network_0.5.2%2B15.10.20150717.1-0ubuntu1_BUILDING.txt.gz
[11:05] <pete-woods> + python3.5 setup.py install --root=/«BUILDDIR»/indicator-network-0.5.2+15.10.20150717.1/debian/tmp --install-layout=deb
[11:05] <pete-woods> /bin/sh: 3: python3.5: not found
[11:05] <pete-woods> (snip_
[11:05] <pitti> /bin/sh: 3: python3.5: not found
[11:05] <pete-woods> yeah
[11:06] <pitti> pete-woods: ah, the package most probably build-depends on python3-dev, but it needs python3-all-dev
[11:06] <pitti> pete-woods: or python3 where it needs python3-all
[11:06] <pete-woods> pitti: thanks, will try that :)
[11:06] <pitti> as it iterates over all supported versions
[11:06] <pitti> and we now have 3.4 and 3.5
[11:06] <pitti> this only works while there's just one supported version
[11:06] <pete-woods> yeah, just figured that variable would list what's actually installed
[11:06] <pete-woods> I guess it doesn't do that
[11:07] <pitti> no, what Ubuntu supports
[11:07] <pete-woods>                python3-dbusmock (>= 0.15),
[11:07] <pete-woods>                python3-setuptools,
[11:07] <pete-woods> is what we build-dep on
[11:07] <pitti> yeah, you need python3-all then
[11:07] <pete-woods> just add that in addition?
[11:07] <pitti> (all python packages should have this)
[11:08] <pitti> s/should/must/
[11:08] <pitti> pete-woods: yes
[11:08] <pete-woods> pitti: awesome, will get that changed :)
[11:09] <pete-woods> possibly worth a ubuntu-developers email about this, as I suspect it will have caught out a number of people
[11:09] <pitti> we've been through several ptyhon transitions; it should mostly affect new packages since we moved to 3.4
[11:10] <pete-woods> sure, I just mean that a bunch of people probably blindly copied and pasted this lump of debian rules
[11:10] <pete-woods>  / inherited it (in my case)
[11:10] <pitti> the rules are fine
[11:10] <pitti> it's debian/control's build-deps which are not :)
[11:10] <pete-woods> right, but if they didn't understand the rules
[11:10] <pete-woods> then they probably didn't do the control file right
[11:11] <pitti> well, it's actually questionable whether you need to install autopilot helpers for *all* supported python3 versions, as they should all be in teh same path
[11:11] <pete-woods> way outside my python expertise
[11:11] <pete-woods> I usually like to see nearly empty debian rules
[11:12] <pitti> yeah, this looks like a workaround of a broken upstream build system
[11:12] <pitti> with proper build systems and pybuild it should be near-empty
=== tvoss is now known as tvoss|test
=== tvoss|test is now known as tovss
=== tovss is now known as tvoss
[12:01] <lifeless> barry: / doko: so this https://bugs.launchpad.net/ubuntu/trusty/+source/python3.4/+bug/1367907
[12:01] <ubottu> Launchpad bug 1367907 in python3.4 (Ubuntu Trusty) "Segfault in gc with cyclic trash" [Undecided,Triaged]
=== MacSlow is now known as MacSlow|lunch
[12:03] <doko> lifeless, pending, waiting on slangasek to approve the upload in the queue
[12:07] <lifeless> \o/
[12:07] <lifeless> slangasek: anything we can do to help with that ?
[12:09] <lifeless> doko: thanks
=== psivaa is now known as psivaa-lunch
[12:37] <Mirv> cyphermox: I filed a wishlist item bug #1475633 about syncing wpa to at least Debian stable's 2.3, depending on what seems best for the next LTS
[12:37] <ubottu> bug 1475633 in wpa (Ubuntu) "New upstream version 2.4 / please merge with Debian 8's wpa 2.3" [Undecided,New] https://launchpad.net/bugs/1475633
=== tedg is now known as ted
=== _salem is now known as salem_
=== ted is now known as tedg
=== MacSlow|lunch is now known as MacSlow
=== sitter is now known as sitter_
=== sitter_ is now known as sitter
=== psivaa-lunch is now known as psivaa
[13:48] <smoser> cyphermox, http://archive.ubuntu.com/ubuntu/dists/trusty-proposed/main/installer-amd64/current/images/netboot/ubuntu-installer/amd64/
[13:48] <smoser> i think we need that kicked for bug 1402042, right ?
[13:48] <ubottu> bug 1402042 in MAAS 1.7 "console= parameters need to be added before -- on kernel cmdline" [High,Triaged] https://launchpad.net/bugs/1402042
[13:51] <smoser> maybe i'm wrong, but the timestamp on files there (jul 5) would seem to indicate that i can't verify that yet
[14:01] <infinity> smoser: d-i will need a rebuild for that, yes.  I'll do that today, along with bumping the kernel versions.
[14:02] <smoser> infinity, thnak you
[14:02] <infinity> smoser: You're wlecmoe.
[14:05] <infinity> smoser: We don't normally rebuild d-i for non-ltses, do we need this fix in utopic?
[14:09] <smoser> i'm personally fine to leave utopic broken.
[14:10] <smoser> but without fixing vivid maas has no stable release > trusty that it can expect sanity in installation.
[14:10] <infinity> smoser: vivid should be fine already.
[14:10] <infinity> smoser: It shipped with this fix.
[14:11] <smoser> right.
[14:12] <smoser> well, i'm ok leaving utopic broken, but you should check that with cyphermox  and slangasek .
[14:12] <smoser> especially as it would seem the upload of d-i has been done.
[14:12] <infinity> smoser: Althought, that said, utopic's had two d-i uploads post-release anyway, so why not one more.
[14:12] <smoser> cool.
[14:13] <infinity> smoser: No upload of d-i was done, just d-i-utils, but maybe that's what you meant.
[14:13] <smoser> sure
[14:14] <infinity> Hrm, a precise upload was done too.  Not sure I see the point in that, since precise doesn't use any of the affected kernels...
[14:14] <infinity> smoser: Did you request precise for consistency's sake on the maas side?
[14:14] <smoser> precise is a supported lts :).
[14:15] <infinity> smoser: Sure, but it's also not broken.
[14:15] <infinity> smoser: Since the bug here is newer kernels stripping '--', and precise doesn't run any of those kernels.
[14:16] <smoser> well maas has ot install precise.
[14:16] <smoser> and it would then have to either say "if i'm installing precise, then use -- otherwise use ---"
[14:16] <smoser> and i think its much nicer if it just uses ---
[14:17] <smoser> the code in maas that does this is not currently aware of the release that is being installed.
[14:17] <infinity> smoser: Okay, that's what I was asking.  It does mean altering d-i to use --- as well, which is a behaviour change for non-maas users, but maybe they won't notice or care.
[14:18] <cjwatson> The change to debian-installer-utils tolerates both, so it's a compatible change.
[14:19] <infinity> cjwatson: Oh, I guess the d-i change was just how d-i boots its own images, wasn't it?  /me goes looking for the commit.
[14:20] <infinity> http://launchpadlibrarian.net/199169893/debian-installer_20101020ubuntu366_20101020ubuntu367.diff.gz
[14:20] <cjwatson> Indeed.
[14:20] <infinity> Yeah, so I guess it's safe to not bother backporting that, since maas, I assume, boots linux/initrd with its own configs and doesn't use d-i's bootloader setup.
[14:21] <infinity> Alright.
[14:21] <infinity> smoser: Okay, I'll do a no-change d-i rebuild in precise and utopic for you for this as well, then.
[14:22] <smoser> thank you infinity . and yeah, the change sure seems to be backwards compatible. outside the case wehre someone wanted '---' to be on their command lines.
[14:22] <cjwatson> I think it might possibly be a good idea to backport that to avoid confusion with newer kernels, but it probably isn't required, indeed.
[14:22] <cjwatson> Certainly a smaller/slightly-safer change if you avoid that.
[14:22] <infinity> Oh, whee, that bug has the deleted tasks bug, so no d-i/precise task for me.  Oh well.
[14:23] <infinity> cjwatson: If people are installing >> 3.18 with precise d-i, they're also rebuilding d-i, and they can keep both pieces if they don't backport that change, IMO. :P
[14:23] <infinity> cjwatson: Certainly not a supported config from my POV.
[14:24] <infinity> Or 3.15... Whatever it was.
[14:25] <infinity> Hrm, if that really was 3.15, then utopic is broken too.  Neat how it never got noticed or reported until well into the wily cycle...
[14:26] <infinity> s/wily/vivid/
[14:26] <cjwatson> infinity: Yeah
[14:26] <cjwatson> I'm fairly sure it was reported
[14:27] <cjwatson> Just not tracked down
[14:27] <cjwatson> ICBW though
[14:27] <infinity> Earliest report I see is https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1411124
[14:27] <ubottu> Launchpad bug 1427252 in installation-guide (Ubuntu Utopic) "duplicate for #1411124 installer ignores preseeding settings added after --" [High,Triaged]
[14:31] <infinity> Hrm, yeah.  I'll backport that to utopic too.  Whee.
[14:34] <pitti> utopic? doesn't that die in like 2 weeks?
[14:34] <pitti> infinity: ^
[14:35] <infinity> pitti: Yeah, but may as well make it work anyway. :P
[14:47] <lolek> hi everybody, is this correct # for asking question related to dpkg features?
[14:48] <lolek> I'm trying to do something like conditional build similar to this: http://www.rpm.org/wiki/PackagerDocs/ConditionalBuilds
[14:53] <cjwatson> lolek: Very recent versions of dpkg have build profiles (https://wiki.debian.org/BuildProfileSpec), but it's new and not supported in all the higher-level pieces yet.
[14:54] <infinity> smoser: Okay, cyphermox has other reasons to do d-i/trusty today, so he'll cover that one.  I'll get utopic up in a bit.
[14:54] <infinity> smoser: And a no-change on precise.
[14:54] <cjwatson> lolek: Otherwise you can just pass environment variables down, but if it requires different build-dependencies and you don't want to modify the source package, then you need build profiles.
[14:54] <lolek> :/
[14:54] <lolek> so I need to somehow make my own way to make different rules file depends on some conditions?
[14:55] <cjwatson> If build profiles don't work for you, yes.  Sorry.
[14:55] <infinity> lolek: Assuming you only care about >= wily, BuildProfiles are the right way.
[14:56] <cjwatson> infinity: (well, they don't work in LP yet ... were you going to get round to those apt/python-apt SRUs?)
[14:56] <infinity> cjwatson: He never said anything about LP. :P
[14:56] <cjwatson> I know, but it's #ubuntu-devel :)
[14:56] <smoser> well, 1402042 was reported in vivid cycle.
[14:56] <cjwatson> most people around here at least end up in PPAs at some point.
[14:56] <infinity> cjwatson: And, erk.  I've almost entirely forgotten about apt SRUs.  Thanks for the reminder. :/
[14:57] <infinity> smoser: Right, all the bugs were reported in the vivid cycle, despite utopic, apparently, also having the bug.  That's what I was whining about. :P
[14:59] <pitti> so my friends, that's it -- holiday o'clock! see you in 10 days!
[14:59] <infinity> cjwatson: Yeah, but adding build-profile support to PPAs (as in, allowing people to set profiles) will be (a) work, and (b) a big can o' worms.
[14:59] <infinity> pitti: Have fun!
[14:59] <infinity> pitti: Don't do anything I wouldn't do!
[15:00] <infinity> pitti: Do ALL THE THINGS I would do!
[15:00] <pitti> infinity: like bicycling, tenting, and swimming?
[15:00] <infinity> pitti: I've done all those things.
[15:00] <pitti> infinity: as long as you've also eaten lots of ice cream, I'm good then!
[15:00] <infinity> pitti: Though, they're not my first choices when I think "how could I improve my happiness?" :P
[15:00] <cjwatson> infinity: Full support is non-trivial.  Not rejecting or failing to build packages that use that syntax in debian/control is much easier.
[15:01] <cjwatson> Right now, direct uploads are rejected, and imports from Debian work but fail to build.
[15:01] <infinity> cjwatson: Right, the backports to not break on syntax need to happen.  No dispute there.
[15:01] <cjwatson> pitti: enjoy :)
[15:01] <infinity> pitti: You staying on IRC and detached so you can get 2000 lines of nick highlights when you come back, or being sensible and logging off for once?
[15:02] <pitti> nah, during holidays I usually kill bip :)
[15:02] <infinity> pitti: Cause if you're staying around, I think I'll just prefix everything I say with your nick for the next week.
[15:02] <pitti> I'll feel terribly disconnected and lonely without IRC, but the heck.. /me pulls the plug and waves
[15:03]  * infinity sheds a tear.
[15:38] <smoser> barry, you marked bug 1398059 as opinion are you hard stuck on that opinion?
[15:38] <ubottu> bug 1398059 in python-virtualenv (Ubuntu) "virtualenv -p python2.6 fails with ValueError: zero length field name in format" [Low,Opinion] https://launchpad.net/bugs/1398059
[15:39] <barry> smoser: do you really need python 2.6? ;)
[15:40] <barry> smoser: it's a low impact change, so if you really do have a need for it, i'm not opposed to fixing it
[15:40] <smoser> barry, well, cloud-init 0.7.x does support 2.6, and i want to support with cloud-init 2.0
[15:41] <smoser> so being able to tox -e py26 is really nice (using deadsnakes repo)
[15:42] <barry> smoser: is wily enough or do you need it to be sru'd?
[15:44] <smoser> wonder if it works on trusty.
[15:45] <smoser> trusty + wily'd be enough for sure.
[15:45] <smoser> i absoultely agree that if there was a long stream of bugs on this, then it'd not be worth it.
[15:47] <barry> smoser: hopefully when and if i get back to virtualenv work, this should be much better in the latest upstream version.  no eta on that (lots of hairy yaks need shaving first)
[15:49] <barry> smoser: bug updated
[16:27] <slangasek> doko: sorry, I missed that you had responded to my questions on the SRU bug - accepting it now
[17:28] <slangasek> tyhicks: hmm why did you reassign bug #1473225 to pam? it looks to me that the submitter is right that this needs fixing in /etc/pam.d/login, which belongs to the login package, not pam
[17:28] <ubottu> bug 1473225 in pam (Ubuntu) "with encrypted home, /etc/legal is printed twice on every login" [Undecided,New] https://launchpad.net/bugs/1473225
[17:40] <tyhicks> slangasek: bah, I goofed up :)
[17:40]  * tyhicks changes it back
[17:41] <slangasek> tyhicks: ok :)
[18:16] <bdmurray> mvo: Do you plans to fix bug 1383214 in Trusty?
[18:16] <ubottu> bug 1383214 in wine1.6 (Ubuntu Vivid) "msiexec no longer works" [High,Fix committed] https://launchpad.net/bugs/1383214
[18:17] <mvo> bdmurray: I'm not sure if its affected, if it is its probably trivial to backport the fix for that
[18:19] <infinity> bdmurray: If the assumption that it's related to gcc-4.9 is correct, then trusty wouldn't be affected, just >= utopic
[18:19] <infinity> mvo: ^
[18:21] <mvo> infinity: ta
[18:22] <infinity> Unless the 4.9 change was backported to the 4.8 branch, of course.  Those GCC people are special.
[18:23] <mvo> :) it was a bit of a drive-by fix tbh, I don't know that much about wine. but it works for me(tm) :)
[18:29] <bdmurray> mvo: Okay, thanks
[19:55] <lifeless> slangasek: morning ?
[20:02] <slangasek> lifeless: good morning!
=== yofel_ is now known as yofel
[20:07] <lifeless> slangasek: I have a question for you
[20:07] <lifeless> 00:01 < lifeless> barry: / doko: so this https://bugs.launchpad.net/ubuntu/trusty/+source/python3.4/+bug/1367907
[20:07] <ubottu> Launchpad bug 1367907 in python3.4 (Ubuntu Trusty) "Segfault in gc with cyclic trash" [Undecided,Triaged]
[20:07] <lifeless> 00:01 < ubottu> Launchpad bug 1367907 in python3.4 (Ubuntu Trusty) "Segfault in gc with cyclic trash" [Undecided,Triaged]
[20:07] <lifeless> 00:01 -!- MacSlow is now known as MacSlow|lunch
[20:07] <lifeless> 00:03 < doko> lifeless, pending, waiting on slangasek to approve the upload in the queue
[20:07] <lifeless> 00:01 < lifeless> barry: / doko: so this https://bugs.launchpad.net/ubuntu/trusty/+source/python3.4/+bug/1367907
[20:07] <lifeless> 00:01 < ubottu> Launchpad bug 1367907 in python3.4 (Ubuntu Trusty) "Segfault in gc with cyclic trash" [Undecided,Triaged]
[20:07] <lifeless> 00:01 -!- MacSlow is now known as MacSlow|lunch
[20:08] <lifeless> 00:03 < doko> lifeless, pending, waiting on slangasek to approve the upload in the queue
[20:08] <lifeless> 00:07 < lifeless> slangasek: anything we can do to help with that ?
[20:08] <lifeless> but sufficient unto the porpoise :)
[20:08] <lifeless> 00:09 < lifeless> doko: thanks
[20:08] <lifeless> erm, double paste, single rainbow.
[20:12] <barry> lifeless: i think slangasek already approved it
[20:13] <lifeless> barry: I refreshed the bug, and couldn't see anything
[20:13] <lifeless> barry: perhaps I'm looking in the wrong place...
[20:15] <barry> lifeless: i could be wrong.  i think i saw a python3.4 package fly by, tho not sure the contents
[20:16] <infinity> He accepted the python backport of doom, yes.
[20:16] <infinity> https://launchpad.net/ubuntu/+source/python3.4/3.4.3-1ubuntu1~14.04
[20:17] <infinity> And if it ever finishes on armhf, I might even let it out of NEW.
[20:18] <lifeless> infinity: ahha, thanks
[20:18] <lifeless> slangasek: sorry for the ping-nag
[20:19] <slangasek> ah :)
[20:19] <slangasek> hmm yes, the bug didn't get updated, that's odd
[20:20] <slangasek> I know the bug was linked from the .changes file
[20:21] <infinity> slangasek: sru-accept after the fact?
[20:29] <bdmurray> slangasek: which bug? bug 1348954 was updated
[20:29] <ubottu> bug 1348954 in python3.4 (Ubuntu) "update Python3 for trusty" [Undecided,Confirmed] https://launchpad.net/bugs/1348954
[20:34] <slangasek> bdmurray: 1367907
[20:35] <infinity> slangasek: Yeah, that's not in the .changes.
[20:35] <infinity> Launchpad-Bugs-Fixed: 1264554 1348954
[20:36] <slangasek> hrm
[20:36] <slangasek> indeed not
[20:36] <slangasek> I did somehow see that bug while reviewing the sru though
[20:37] <slangasek> must've manually followed a changelog link
[20:37] <infinity> It's impressive that an upload with a 37PB diff only fixes two bugs.
=== G_ is now known as G
[21:18] <lifeless> infinity: 37 **P**B ?
[21:18] <Unit193> Well they do say Ubuntu got bloated... ;)
[21:19] <infinity> lifeless: That might have been hyperbole.
[21:47] <lifeless> infinity: just possibly :)
[22:05] <lifeless> infinity: so the builds all finished; is it in NEW still ? [I'm not sure where to check these days]
=== salem_ is now known as _salem
[22:56] <infinity> lifeless: It should be published in -proposed.
[23:22] <lifeless> infinity: it is, thanks. clarkb just tested the build