[08:48] <mlankhorst> can someone approve xxv-intel? ^
[10:01] <smb> Sorry if that is repeating a known fact which is going away with the final release. Just noting that right now with the daily iso the "release notes" link is pointing to the ubuntu.com main page.
[10:12] <LocutusOfBorg1> can anybody please give a feedback to me about bug 1382848?
[10:12] <ubot2> bug 1382848 in ettercap (Ubuntu) "[FFe] Sync ettercap 1:0.8.1-1 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1382848
[10:13] <LocutusOfBorg1> I really would like to see it in the upcoming utopic, the current kernel spot a race condition in one of the core parts of ettercap
[10:39] <apw> smb, i _think_ that the link doesn't actually point there, i think it points to something "dynamic" which webops have to sort ... but best to let someone else confirm
[10:51] <smb> apw, Yeah, I just wanted to bring it up in the case this needs something done in the installer, too. maybe I could copy the link to find out what exactly it is. Its not obvious by hovering over it or when firefox comes up
[12:14] <cjwatson> smb,apw: I can confirm this is not a problem with the installer; web team (not webops) needs to fix it
[12:15] <smb> cjwatson, Ok, thanks.
[12:45] <M-Saunders> Hi everyone. Was the 14.10 RC released on the 16th? I can't find a trace of it
[12:47] <stgraber> M-Saunders: we don't do RCs
[12:48] <infinity> Or, rather, we don't "release" them.
[12:49] <M-Saunders> Ah, thanks. I was going on this: https://wiki.ubuntu.com/UtopicUnicorn/ReleaseSchedule
[12:49] <infinity> It's logically nonsensical to release a release candidate.
[12:49] <M-Saunders> I'm making a coverdisc for a magazine (Linux Voice), and my deadline is Friday
[12:49] <infinity> M-Saunders: Click the ReleaseCandidate link there, it explains it.
[12:50] <infinity> M-Saunders: The real release is Thursday, that's the ISO you'll want to be using.
[12:50] <M-Saunders> infinity: Yeah. For testing in the meantime, would you recommend using the nightlies?
[12:50] <infinity> M-Saunders: Yep.
[12:50] <M-Saunders> Great, thanks
[12:51] <M-Saunders> And as far as you know, should the release happen on Thursday? I haven't seen any talk of slippage
[12:51] <infinity> M-Saunders: It's been years since we slipped, I don't anticipate it.
[12:52] <M-Saunders> Yep, you guys have been reliable in recent years indeed. Ta!
[13:25] <Riddell> #
[13:26] <knome> Riddell, the number you have dialed cannot be reached.
[13:27] <Riddell> it's the ultimate twitter hashtag
[14:03] <Laney> Where are we with accepting stuff / britney blocks / respins?
[14:26] <infinity> Laney: britney block should happen.  Happy to have you do that, if you'd like.
[14:26] <infinity> Laney: There's a guaranteed respin tomorrow for a kernel issue, so we can squeeze some other bits in in the meantime if they seem sane.
[14:27] <Laney> Kewl
[14:27] <Laney> I'll do a mega block and we can block-all source later on
[14:27]  * Laney stabs this latency
[14:28] <mdeslaur> can someone please accept xchat-gnome so I can start sruing it, thanks
[14:29] <infinity> mdeslaur: Looking.
[14:48] <Laney> the world is blocked
[15:06] <mdeslaur> infinity: sooooo many packages in the archive force sslv3... /me cries
[15:08] <infinity> mdeslaur: Sadness and loss.
[15:50]  * Laney collides with stgraber 
[16:09] <mdeslaur> infinity: same fix, but for xchat ^
[16:23] <infinity> mdeslaur: Having fun with this one yet? :P
[16:24] <mdeslaur> infinity: I don't think we have the same definition of "fun" :)
[16:24] <infinity> mdeslaur: Do you have a list of still-affected packages?
[16:25] <infinity> mdeslaur: And can you prioritise stuff that's on images (as seen by seeded-in-ubuntu(1)), so they get into respins?
[16:30] <mdeslaur> infinity: I don't have a list yet...I started, but then got depressed and switched to looking for beer.
[16:33] <mdeslaur> infinity: I'll try and see after lunch
[17:36]  * cjwatson updates ubiquity-slideshow-ubuntu translations
 debconf-updatepo... also known as "I'm feeling unproductive today.
[17:36] <cjwatson>         Please give me a huge diff to check in"
[18:06] <jibel> infinity, bug 1381766 and bug 1378735
[18:06] <ubot2> bug 1378735 in syslinux (Ubuntu) "Unable to use PXE boot with 14.10 (Utopic Unicorn) Daily Build: "Failed to load ldlinux.c32"" [Undecided,New] https://launchpad.net/bugs/1378735
[18:15] <cjwatson> possibly same as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=750586
[18:15] <ubot2> Debian bug 750586 in debian-installer "syslinux-common: Boot fails. Failed to load ldlinux.c32. File must be in /. Upstream bug" [Important,Open]
[18:16] <cjwatson> http://paste.ubuntu.com/8604733/
[18:18] <cjwatson> pretty sure CPing that will do the job
[18:20] <cjwatson> jibel: fix committed
[18:25] <pitti> hello all
[18:26] <jibel> cjwatson, thanks
[18:26] <pitti> bdmurray pointed me to bug 1372665, which is because we currently run *both* /etc/init.d/apport (unintentinoally) and /etc/init/apport.conf (intentionally) during boot
[18:26] <ubot2> bug 1372665 in apport (Ubuntu) "apport reports suspend/resume failure twice on boot (apportcheckresume)" [High,Fix committed] https://launchpad.net/bugs/1372665
[18:26] <pitti> I just committed a trivial fix for that to trunk, is that something which we still want in the release, or as SRU at this point?
[18:46] <mdeslaur> infinity: ok, my search only found spamassassin in the seeded list: bug 1383415
[18:46] <ubot2> bug 1383415 in spamassassin (Ubuntu) "Incorrect use of SSL options" [Undecided,New] https://launchpad.net/bugs/1383415
[18:47] <mdeslaur> infinity: all the others aren't seeded
[18:47] <mdeslaur> (that's just searching for the same type of issue as xchat-gnome had...)
[18:47] <mdeslaur> infinity: and it's not important enough for a quick fix
[18:47] <pitti> cjwatson, all: we have an idea what changed last Friday -- the old distro-info said that utopic was released at that day; this can't be a coincidence, there's surely something in the autopkgtest machinery that still uses that
[18:48] <pitti> until that, test runs are stalled, I'll request those manually while we investigate
[18:48] <kenvandine> pitti, thx
[18:51] <jibel> pitti, actually the problem is not what I thought but an SSL issue http://paste.ubuntu.com/8605136/
[18:53] <pitti> jibel: FTR, manually running tests doesn't help -- they are available in jenkins with the right version, but britney doesn't pick those up; consistent with the SSL prob?
[18:59] <jibel> pitti, yes the error comes from the job that consumes the queue
[19:02] <jibel> pitti, it should be unblocked. The SSL errors happens when it fetches changes from LP to find latest uploader. I disabled notification of the uploader for the moment.
[19:05] <cjwatson> jibel,pitti: I bet this coincides with SSLv3 being turned off on Launchpad frontends
[19:06] <cjwatson> due to the recent catastrophic vulnerability in it
[19:06] <cjwatson> what is trying to use SSLv3?
[19:06] <cjwatson> jenkins/adtnotify.py
[19:10] <cjwatson> Probably ought to be ssl.PROTOCOL_TLSv1_2 nowadays
[19:11] <cjwatson> http://paste.ubuntu.com/8605356/ maybe (untested)
[19:12] <cjwatson> hmm
[19:13] <cjwatson> I wonder if we should retain the fallback in case in future LP upgrades to TLSv1.3
[19:13] <mdeslaur> please use ssl.PROTOCOL_SSLv23 for everything
[19:13] <mdeslaur> that will negotiate the best
[19:13] <cjwatson> Not clear that ssl.PROTOCOL_TLSv1_2 would interop with that, but ssl.PROTOCOL_SSLv23 tries everything
[19:13] <mdeslaur> cjwatson: ^
[19:13] <cjwatson> mdeslaur: right except it's failing here
[19:14] <cjwatson> the log is really misleading but when it says "Trying SSLv3" it's actually falling back to trying ssl_version=ssl.PROTOCOL_SSLv23
[19:14] <pitti> cjwatson, mdeslaur: but SSLv23 is the one that is failing, no?
[19:14] <cjwatson> so maybe it's just that the fallback doesn't work
[19:14] <cjwatson> I bet it needs to reopen the socket from scratch
[19:14] <mdeslaur> perhaps you can't try a different wrap_socket
[19:15] <mdeslaur> cjwatson: yeah
[19:15] <cjwatson> since it's probably already done some negotiation
[19:15] <pitti> oh, right http://paste.ubuntu.com/8605136/ doesn't actually show an SSLError
[19:15] <cjwatson> so yeah, just use ssl_version=ssl.PROTOCOL_SSLv23 across the board and drop the override; that's what httplib does itself anyway, so you can just drop this whole misguided thing
[19:15] <pitti> so PROTOCOL_SSLv3 succeeded, but then fails later on
[19:15] <cjwatson> no, the SSLError was swallowed by the except
[19:16] <cjwatson> and then the fallback attempt failed because it was in the wrong place in the protocol to restart ssl.wrap_socket
[19:16] <pitti> can we apply that locally on snakefruit to test it before we commit it to lp:britney2?
[19:16] <cjwatson> I am reasonably sure that you can just do http://paste.ubuntu.com/8605402/
[19:17] <cjwatson> python2.7's httplib uses the ssl_version we want
[19:17] <cjwatson> pitti: this isn't on snakefruit
[19:17] <cjwatson> it's somewhere that has /var/lib/jenkins/QA/
[19:17] <cjwatson> tachash?
[19:17] <cjwatson> and it's not in britney2, it's in lp:auto-package-testing
[19:17] <pitti> ah, I don't have access to that
[19:17] <jibel> on tachash
[19:17] <pitti> oh
[19:17] <pitti> cjwatson: cheers
[19:18] <mdeslaur> cjwatson: I think you still need that to specify the certs, or it defaults to no cert checking
[19:18] <cjwatson> really?  I didn't see that when comparing the code
[19:18]  * cjwatson looks again
[19:19] <cjwatson> no, that's passed to the constructor and the default implementation passes it through
[19:19] <cjwatson>             self.sock = ssl.wrap_socket(sock, self.key_file, self.cert_file)
[19:19] <cjwatson> from the default impl
[19:20] <pitti> yay, I'm getting jenkins-failed mails again, so I suppose it's working again
[19:20] <pitti> (with the degraded notifications)
[19:21] <cjwatson> mdeslaur,jibel: so I don't think I see a reason to keep that; but should clean up a bit more, http://paste.ubuntu.com/8605441/
[19:25] <cjwatson> urllib2 certainly works against LP without any of that stuff, although I don't have an easy way to confirm what TLS version it's using
[19:28] <cjwatson> mdeslaur: (if you could confirm at some point that would be good ...)
[19:29] <mdeslaur> cjwatson: yeah, sorry, that the client cert...I don't think urllib2 does any sort of server cert verification at all, actually
[19:29] <cjwatson> it doesn't look like it.  but the code in adtnotify doesn't appear to help with that
[19:30] <mdeslaur> cjwatson: is this python2 or python3?
[19:30] <cjwatson> mdeslaur: python2
[19:30] <cjwatson> mdeslaur: actually, ssl.py in python2.7 appears to default to CERT_REQUIRED when in client mode
[19:31] <mdeslaur> cjwatson: ok, so no cert verification in there
[19:31] <cjwatson> see create_default_context
[19:31] <cjwatson> or do you need ca_certs= to make that work?
[19:40] <cjwatson> pitti: apport> looks fine, accepted, thanks
[19:42] <mdeslaur> cjwatson: where can I get the whole adtnotify.py file?
[19:44] <pitti> mdeslaur: http://bazaar.launchpad.net/~auto-package-testing-dev/auto-package-testing/trunk/view/head:/jenkins/adtnotify.py
[19:44] <mdeslaur> pitti: thanks
[19:47] <mdeslaur> pitti, cjwatson: right, so no server cert verification in there, and the removed code had no impact on that
[20:01] <Laney> arges: I'd appreciate it if you could consider the e-d-s I just uploaded so we can get both versions in at once
[20:08] <arges> Laney: ok i'll take a look
[20:09] <Laney> thanks
[20:09] <Laney> sorry for forgetting that one initially
[20:09] <Laney> but the bug sucks a bit
[20:15] <wxl> um, are there supposed to be new images in daily? i see everything's old again.
[20:16] <infinity> wxl: Shouldn't be anything new, no.
[20:16] <wxl> infinity: ok, cool. thanks :)
[20:16] <arges> Laney: ok just to confirm, that e-d-s upload overrides 3.10.4-0ubuntu1.4 and is a superset of fixes?
[20:16] <Laney> arges: It's another patch on top, yeah
[20:17] <arges> Laney: ok yea looked like it, just wanted to make sure i wasn't missing anything
[20:17] <Laney> sure, no worries
[20:20] <Laney> w00t