[01:26] <smoser`> anyone else having trouble using offlineimap or alpine with imap recently ?
[01:28] <smoser> i'm using both of those, configured with imapssl (alpine: mail.brickies.net/user=smoser@brickies.net/ssl/novalidate-cert)
[01:29] <smoser> offlineimap is similar configured (i have it actually expects a configured cert)
[01:29] <smoser> but i think something in the past 4 days caused issue
[01:30] <smoser> here is my recent apt history.log http://paste.ubuntu.com/6548782/
[01:31] <smoser> both gnutls and libssl wer updated in the queestionalbe time frame.
[01:36] <smoser> infinity, or mdeslaur ? you 2 are recently touched on those two (with doku) having a change also to libssl
[01:47] <sarnold> smoser: mdeslaur recently turned tls 1.2 back on in our openssl packages
[01:47] <sarnold> smoser: not everything is prepared to negotiate tls 1.2 and fail to handshake entirely
[01:48] <smoser> well it would appear that i have 2 things that fail. i'm getting connection reset by peer.
[01:48] <smoser> sarnold, do you have a suggestion ?
[01:48] <smoser> shal i file a bug on openssl ?
[01:48] <smoser> (i think i might be having deja vu on this)
[01:49] <sarnold> smoser: does offlineimap or alpine let you ask for tls1.1 or tls1.0 in their configs? that'd be my first shot..
[01:49] <smoser> i dont think so.
[01:49] <smoser> maybe though. i'll lok
[01:50] <smoser> http://docs.offlineimap.org/en/latest/MANUAL.html
[01:53] <sarnold> smoser: openssl's s_client also supports -tls1_2 -tls1 etc., it might be handy to debug if the clients don't support it easily...
[01:56] <smoser> sarnold, i dont know that i would have time to devote to debugging that. its not something i have any experience in.
[01:56] <sarnold> smoser: here's the bug tracking turning tls 1.2 back on: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1257877
[01:57] <sarnold> smoser: I tried to run: openssl s_client -host mail.brickies.net -port 443     to dump a pile of debugging information; try it out, add -tls1_2 or -tls1_1 or -tls1 to the command line and see if the output changes from run to run
[02:01] <smoser> sarnold, unless you object i'll at least comment in that bug to my issues
[02:01] <sarnold> smoser: no, please do, it'd be nice to collect experiences. (I don't know if that's the best place, but I can't nominate anything better. :)
[02:03] <smoser> sarnold, commented. fwiw, i'm pretty sure it is using port 993
[02:03] <smoser> not 443
[02:03] <smoser> yeah, duh :)
[02:04] <smoser> silly me. 993 makes sense in that /etc/services says 'imaps' but you made me question myself.
[02:04] <smoser> hope that did'nt sound rude. i iddn't mean to be.
[02:04] <smoser> thanks for your help.
[02:05] <sarnold> smoser: haha, no, not at all, chalk that up to my just being happy the offline imap folks had the port listed to "save me the time" from looking it up myself. :) heh.
[02:05] <sarnold> smoser: thanks
[04:15] <mdeslaur> smoser: yep, looks like your mail server dies when something tries to connect using tlsv1.2
[04:23] <mdeslaur> smoser: looks like xnox has a patch available to be able to set the ssl version for broken servers...see: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707252
[05:25] <pitti> good morning
[05:26] <pitti> shadeslayer: I remember some bug about adding the "version" thing to -shim, but it's tricky either way -- if we provide too much, upstream projects might be tricked into thinking that they are actually speaking to systemd pid 1?
[06:30] <hyperair> looks like gst1.0's bpmdetect element is hanging, while it works fine in gst0.10. does anyone know how to debug this issue?
[07:59] <dholbach> good morning
[09:20] <xnox> mdeslaur: smoser: honestly use git master from https://github.com/OfflineIMAP/offlineimap the release was pushed out but not uploaded into debian yet.
[09:36] <xnox> infinity: \o/ \o/ \o/ =))))
[09:36] <Laney> O_O
[09:39] <xnox> Laney: eglibc 2.18 uploaded into experimental =))))))
[09:39] <Laney> oh right
[09:39] <Laney> what's in that that's worthy of such joy? :P
[09:39] <xnox> Laney: thus unblocking libnih & upstart on kfreebsd among with many other things.
[09:39] <Laney> neat
[09:39] <xnox> and i totally thought i'm on #debian-devel =))))
[09:40] <RAOF> Oooh, neat.
[09:40]  * xnox is being gravitated to the coffee machine
[09:42] <Laney> are you a regular office goer now?
[09:44] <xnox> Laney: i don't know =) i am yesterday & today. better heating + lighting. Plus i have the new microfost ergonomic keyboard that fits into a standard laptop bag, so i feel good out here =)
[09:46] <seb128> xnox, but there is like people in there...
[09:46] <seb128> ;-)
[09:47] <xnox> seb128: i just put my headphones in, don't play music and eavesdrop =)
[09:47] <seb128> haha
[09:48] <xnox> seb128: Laney: https://plus.google.com/109160032876474505377/posts/Y3zk1Etqexu
[09:49] <Laney> :D
[09:49] <ogra_> xnox, don't we have to call you xnox_john now ?
[09:49] <ogra_> (and congrats !!!)
[09:49] <Laney> wait
[09:49] <Laney> no more ganja?
[09:50] <xnox> Laney: no more ganja, bought Lenovo Yoga in Clementine Orange color shortly after smokin abuse at Debconf.
[09:50] <xnox> it's metalic orange, and is very similar to ubuntu orage. i love it =) it's an "ideapad" instead of "thinkpad", so i still get light abuse about that.
[09:50] <Laney> :D
[09:51] <xnox> ogra_: haha =) I was thinking to add "Xnox" as a middle name, but i have settled for - Dimitri John Ledkov in the end.
[09:51] <ogra_> :D
[09:51]  * xnox should send a wider email about it.
[09:51] <ogra_> thats a beautiful thing you bought there
[09:51] <seb128> ogra_, hey, how is life out of work? ;-)
[09:52] <ogra_> seb128, so,so ... i cracked my back on my first vacation day ... slowly able to walk upright again today
[09:53] <seb128> ogra_, :-(
[09:53] <ogra_> beyond that sooo boring ... (i was planning to do a lot on the house ... without being able to move that is kind of delayed by a week now)
[09:53] <Laney> on the plus side, your s-c pet bug should be fixed
[09:53] <ogra_> hah, cool
[09:53] <Laney> (soon)
[09:54] <ogra_> yeah, i see the changelog entry
[09:54] <brendand> xnox, you got an ideapad too? nice hardware, requires a lot of hackery though
[09:54] <seb128> ogra_, I've a working fix in the desktop team ppa, but amd64 fails to build on the ppa builders so it's i386 only
[09:55] <seb128> ogra_, it seems to work for me (but it was not happening reliably before so I'm not sure), I'm going to upload to trusty once Laney manages to move the harfbuzz transition out of trusty-proposed
[09:55] <ogra_> cool, i'll test it then
[09:56] <ogra_> (only amd64 here ...)
[09:56] <xnox> brendand: yeah I should start writing about it, i have scripts to totate _both_ screen & touch screen, plus I want to push upstream patches to udev for it's custom keycodes that indicate orientation.
[09:56] <brendand> xnox, oh i'd love to get those
[09:56] <xnox> brendand: not sure what to do about wifi, i currently pull dkms module from github. Not sure if i should package it or not.
[09:56] <xnox> brendand: didn't get bluetooth to work.
[09:57] <brendand> xnox, i'm building the wifi module from source
[09:57] <xnox> brendand: do have fixed brightness keys, via xorg override.
[09:57] <brendand> xnox, are you suffering from losing the mouse pointer sometimes?
[09:57] <xnox> brendand: and the extra buttons do nothing (the one on the right which is "screen lock" and "the one-touch recovery" key
[09:58] <xnox> brendand: mouse pointer - not that i have noticed, then again I mostly use ergonomic wireless / usb mouse.
[09:58] <xnox> brendand: i do want touch apps to auto-appear and on-board to get auto-enabled.
[09:58] <brendand> xnox, yeah using a mouse might make it go away
[10:00] <seb128> oh, seems like webkit migrated
[10:00] <seb128> Laney, right?
[10:00] <seb128> just got email
[10:00] <Laney> oh man, you spoiled the surprise!
[10:00] <seb128> :-(
[10:01] <Laney> :P
[10:01] <Laney> yeah, looks good
[10:02] <brendand> xnox, btw what you said yesterday about dh_python3. how to use that properly - is --exclude expecting the name of the binary package, or a path? if it's a path, relative to what?
[10:02] <brendand> xnox, i can see in the logs that dh_python3 is renaming my .so file
[10:07] <xnox> brendand: man debhelper; common options -        -Xitem, --exclude=item
[10:07] <xnox>            Exclude an item from processing. This option may be used multiple times, to exclude more than one thing. The item is typically part of a filename, and any file containing the specified text will be excluded.
[10:08] <brendand> xnox, so --exclude='libgui-engine.so' should work
[10:08] <xnox> brendand: yeap.
[10:08] <xnox> brendand: or, i tend to call dh_python3 only on the python3 package, e.g. override_dh_python3: dh_python3 -ppython3-foo
[10:08] <xnox> brendand: such that it doesn't do anything to any other !python packages that I may have.
[10:09] <brendand> xnox, in this instance all the packages are python3 except this one
[10:09] <xnox> (obviously not always possible)
[10:09] <xnox> ah
[10:09] <brendand> xnox, would have been good to be able to exclude a whole package
[10:10] <brendand> xnox, btw is exclude available in the precise version of debhelper?
[10:10] <xnox> brendand: it's been available forever.
[10:10] <brendand> xnox, yeah. just someone mentioned the precise version of dh_python3 has fewer options
[10:11] <xnox> brendand: this is a debhelper common option, all dh_* must support it.
[10:12] <xnox> Laney: lovely gnome-terminal, when can we have it in trusty? =)
[10:13] <xnox> Laney: also does it work with e.g. emacs & byobu?
[10:15] <Laney> xnox: channel hopping?
[10:16] <Laney> also, larsu posted that :P
[10:16] <xnox> =)
[10:17] <Laney> see the bug I referenced and talk to M. Klose
[10:18] <Laney> or you can decide to do what Debian did and take the heat yourself :-)
[10:22] <infinity> brendand: You can exclude packages.
[10:22] <infinity> brendand: Same syntax as xnox showed, but -N instead of -p.  ie: dh_foo -Nnot-this-package
[10:23] <brendand> infinity, excellent
[10:24]  * infinity is not okay with this fire alarm at 3am business and wonder if he should put on pants.
[10:25]  * Laney goes blind, and then decides to stop reading that in British English
[10:26] <infinity> Laney: Trousers? :P
[10:26] <Laney> Much better ;-)
[10:27] <brendand> Laney, is it much better? :/
[10:27] <Laney> Whatever floats your boat
[10:28] <pitti> infinity: WDYT, should we release bug 1257211 now-ish? it's been less than 7 days (4 only), but people are nervous and keep prodding me
[10:29] <xnox> Laney: =)))))))
[10:29] <pitti> infinity: eek, I read that you are probably not really "here"; not that urgent
[10:33] <seb128> mardy, hey, did you see bug #1258578?
[10:36] <infinity> pitti: I'm okay with releasing it early if it has a comprehensive testsuite that passed on all arches and there's been some general testing and kicking the tires.
[10:36] <pitti> infinity: yes to both
[10:37] <pitti> infinity: upstream tests are run during package build (on all arches), and postgresql-common testsuite/autopkgtest has over 2000 system integration test cases, so I'm fairly confident
[10:37] <infinity> pitti: run, and build failed when they fail? :P
[10:38] <pitti> infinity: yes, of course; the only way to run them :)
[10:38] <infinity> pitti: (You'd think I wouldn't have to ask that, but... GCC)
[10:38] <pitti> I'm happy to do the actual button pushing, but I wanted to hear an SRU team member opinion
[10:38] <infinity> pitti: If you want to drive sru-release, you've got my approval to release the lot.
[10:39] <pitti> infinity: ack, thanks
[10:39] <infinity> pitti: Just remember the weird syntax, if it's been a while.
[10:39] <infinity> ("sru-release lucid postgresql-8.4", no -s, like every other archive tool...)
[10:40] <pitti> right
[10:40] <pitti> seems to have worked fine for saucy
[10:41] <pitti> https://launchpad.net/ubuntu/+source/postgresql-9.1/+publishinghistory and the bug followup
[10:42] <pitti> and another firefox tab gone, yay
[10:51] <pkern> Is there a page that shows mirror churn (bonus points for per-architecture) for Ubuntu?
[10:53] <infinity> pkern: Other than new arches, per-arch churn is the same on all arches anyway, since we don't do binNMUs.
[10:53] <infinity> pkern: But not sure if we have a nice graph that shows it regardless...
[10:53] <xnox> mhall119: dholbach: pitti: who is / are translation co-ordinators? I got an angry email from upstream that received a typo fix in translations they don't have, ubuntu langpack provided it.
[10:54] <xnox> and they are demanding for translations to be forwarded upstream, or some such.
[10:55] <pkern> infinity: Fair point. There might be size differences but small enough to not matter, I guess. I wouldn't even need a graph. A figure per month and distro would already be sufficient. ;)
[10:56] <infinity> wgrant / elmo: Does either of you know if we have mirror churn stats, or an easy way to generate some based on history?
[11:10] <pitti> xnox: we don't really have a coordinator any more
[11:11] <xnox> pitti: =/ a wiki page or some such. I've replied this: http://article.gmane.org/gmane.comp.version-control.git/239133
[11:14] <pitti> xnox: very considerate, thanks!
[11:15] <dholbach> xnox, https://launchpad.net/~ubuntu-translations-coordinators
[11:16] <xnox> dholbach: thanks.
[11:22] <infinity> pkern: Out of curiosity, if we were to try to artificially create churn stats from publishing history, what are you actually interested in?
[11:22] <infinity> pkern: Our actual ftpmaster, and its slaves (archive.ubuntu.com, security, archive.us, ports) update as often as every 5-15 minutes.
[11:22] <wgrant> infinity, pkern: I have no stats for that, but could quickly generate some from the DB.
[11:22] <infinity> pkern: While our downstream mirrors are rate-limited to 4h.
[11:23] <infinity> pkern: And that difference actually is quite a lot right there.
[11:24] <infinity> pkern: And, of course, churn gets less scary the wider your time granularity.  If you want to know the difference between snapshots in time between Jan1 and Feb1, that's a tiny number compared to the churn if you were updating every 24h, 4h, or 5m.
[11:26] <shadeslayer> pitti: I agree, which is why I was trying to figure out a way to solve this on Kubuntu
[11:27] <shadeslayer> talked a bit more with upstream, they use version numbers because they've personally guranteed that that a particular feature is working with that version
[11:27] <infinity> pkern: And, of course, every-six-months churn is the least scary (and easiest to calculate) of all, as you're then just calculating the size of a stable release. ;)
[11:28] <infinity> (Well, and all the updates/security to past releases in that time period)
[11:29] <infinity> wgrant: And suddenly, for no good reason at all, I actually want to see a graph of every-publisher-cycle versus 4h-trigger-throttling versus 24h versus 1w versus 1m versus 6m churn.  Just cause.
[11:30] <infinity> wgrant: I'm not sure this has any practical use for more than a handful of mirrors trying to pick the optimal update pattern, perhaps, but it would still be a pretty graph.
[11:33] <mardy> seb128: yep, I have a tentative fix ready, I'll ask Ken to review it
[11:34] <seb128> mardy, thanks, I just wanted to check, dunno if you read ubuntu bugs
[11:36] <xnox> infinity:  is the non-rate limitted mirror directly accessible?
[11:37] <infinity> xnox: I'm not sure I get what you're asking.
[11:37] <infinity> xnox: All of our downstream mirrors that are SSH triggered are only triggered once ever four hours.  That's what I meant by rate-limited.
[11:37] <xnox> ah, i see. so archive.ubuntu.com does update as-soon as.
[11:37] <infinity> xnox: All the Canonical hosted mirrors (gb.archive, us.archive, ports, security, us.ports) update every time ftpmaster does.
[11:38] <xnox> cool.
[11:38] <xnox> infinity: i have git archive of mostly all per 5min granularity of dists/ for most of trusty and some of raring. do you want that?
[11:39] <xnox> infinity: together with dctrl-grep one should be able to establish the throughput.
[11:39] <infinity> Nah, if we want to recreate history, we have much more accurate publishing history in psql.
[11:39] <xnox> infinity: cool.
[11:39] <xnox> infinity: it doesn't cache Releases.gpg does it?
[11:39] <infinity> "It"?
[11:40] <infinity> The database has no concept of on-disk formats at all.
[11:40] <infinity> It just knows when things were published and deleted.
[11:40] <xnox> infinity: postgres database... right.
[11:41] <infinity> So, no, we don't have a facility for a proper signed snapshot.ubuntu.com, if that was your followup. :)
[11:42] <infinity> We could write a thin librarian proxy that could produce an unsigned snapshot of just about anything, but we can't give you an ACTUAL snapshot because, as you point out, we don't have the exact Packages/Release files, nor the sigs.
[11:42] <xnox> infinity: i have a snapshotter, that does redirect to archive.u.c / ports / release or librarian, but apt-get freaks out when you do http (snapshoter) -> https redirect (launchpad librarian)
[11:43] <xnox> is launchpad librarian accessible over http at all?
[11:43] <wgrant> Yes
[11:44] <infinity> Yeah, the only reason the links in the LP UI are https is trusty path.
[11:44] <infinity> Since they're not coming from a signed repo.
[11:44] <infinity> GAH.
[11:44] <infinity> TRUST.
[11:44] <infinity> NOT TRUSTY.
[11:44] <infinity> Editing changelogs for this release has ruined me.
[11:47] <xnox> wgrant: i actually need https://launchpad.net/ubuntu/+archive/primary/+files/ I guess i should hit that path and get the launchpadlibrarian url.
[11:48] <wgrant> xnox: Or fix apt to not be terrible :)
[11:48]  * xnox ponders if there is API to query http url from that.
[11:48] <wgrant> https -> http redirects might be valid to complain about, but not http -> https...
[11:49] <xnox> well the full chain is http -> https -> http
[11:49] <xnox> so it does appear as a man-in-the-middle.
[11:50] <infinity> xnox: If you can get the https URL for something, you have the http URL...
[11:51]  * xnox ponders how to query 302 redirect without downloading the thing.
[11:51] <xnox> in python3.
[11:51] <xnox> aha follow_redirects=False.
[11:53] <infinity> ... why do I get a 200 on HEAD ...primary/+files/foo.deb?
[11:53] <infinity> Dear god, tell me this 302 isn't in the body.
[11:53] <infinity> This is 2013.
[11:53] <infinity> And not geocities.
[11:55] <wgrant> infinity: Where did you see that?
[11:55] <infinity> Oh, nevermind.  HEAD is lying to me.
[11:56] <wgrant> $ curl -I https://launchpad.net/ubuntu/+archive/primary/+files/dpkg_1.17.1ubuntu1_amd64.deb
[11:56] <wgrant> HTTP/1.1 302 Moved Temporarily
[11:56] <infinity> It's following the 302 and giving me the header of the ultimate location.
[11:56] <infinity> That's not at all what I want.
[11:57] <infinity> It's things like this that make me stop trusting fancy tools and I fall back to "telnet $host 80" for another decade.
[11:58] <infinity> Except that doesn't work too well if you don't speak fluent SSL/TLS binary goop.
[11:58] <infinity> In this case, anyway.
[12:02] <rbasak> infinity: "openssl s_client -connect launchpad.net:443 -CApath /usr/share/ca-certificates/mozilla" or something like that may help you here. Then you can speak HTTP yourself if you wish, with the SSL/TLS done for you.
[12:06] <xnox> muahaha, got it.
[12:08] <rbasak> Probably -verify 0 as well.
[12:08] <infinity> rbasak: Or, less typing, "apt-get install telnet-ssl && telnet -z ssl launchpad.net 443"
[12:09] <rbasak> Oh, thanks. I didn't know that existed.
[12:09] <infinity> Works a treat, just tried here. :)
[12:10] <infinity> You need to type fast, though, our squids drop your connection annoyingly quickly.
[12:10] <rbasak> Incidentally, wget always seems to do more sensible things in edge cases like this than curl does.
[12:10] <infinity> I resorted to copying and pasting my GET. :P
[12:10] <rbasak> (by default; I'm sure curl has options)
[12:36] <RAOF> Bah. Why don't we serve mirrors.ubuntu.com/mirrors.txt over https?
[12:40] <mcpierce> Morning, all. I'm looking for some guidance on becoming a package maintainer for Ubuntu. I've read a bit online about the contributor program, but would like a little guidance if possible.
[12:47] <rbasak> mcpierce: can you be more specific? Ubuntu doesn't really have package maintainers exactly, but if your focus is on one particular package you can build up a track record and then get upload rights to just that package.
[12:48] <rbasak> s/get/apply for/ I guess.
[12:48] <mcpierce> rbasak: Well, what I'm hoping to do is help to package up a few things from my projects (Qpid and Proton). I'm the package maintainer for them in Fedora and wanted to give the same assistance to Ubuntu as well.
[12:49] <rbasak> mcpierce: I see. Are these packaged up already, or would they be new packages? If new, have you read: https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages? If having Debian packages would also make sense, then we prefer to add new packages to Debian, and then Ubuntu will auto-import them.
[12:49] <mcpierce> rbasak: I see that what Ubuntu ships is way out of date from what we provide currently (we're releasing 0.26, but Ubuntu is still carrying 0.16 of Qpid, and no Proton that I saw).
[12:49] <mcpierce> rbasak: So, Ubuntu mostly works with Debian packages?
[12:50] <mcpierce> rbasak: What I mean is, Ubuntu only adds onto Debian as opposed to repackaging the Debian bits?
[12:51] <rbasak> mcpierce: correct. We only modify Debian packages if we have good reason for Ubuntu to need it. Sometimes it is time (to release ahead of Debian), and sometimes it is because we have some kind of specific reason to do something different. But in general, we try keep the delta against Debian small - ideally zero. So if you have no need for Ubuntu to carry a delta on the packages that you care about, the best first point of call is to get the packages a
[12:53] <rbasak> mcpierce: also see https://wiki.ubuntu.com/TrustyTahr/ReleaseSchedule and https://wiki.ubuntu.com/DebianImportFreeze to understand the automatic Debian import and the Ubuntu release schedule.
[12:53] <mcpierce> rbasak: kk - thanks for the info!
[12:53] <rbasak> mcpierce: np. We appreciate you caring for Ubuntu packages. Ask if you need any help.
[12:54] <apachelogger> pitti: got it all figured out now I think  ... kapplication crashes -> crash handler -> invokes drkonqi (GUI) -> drkonqi has checkbox to automagically submit crash report -> when ticked /var/crash/foo.drkonqi-accept is written on exit -> crash handler checks for file after drkonqi terminated -> if present it re-raises to apport -> if not it exists without forwarding to apport ... apport collects information -> kubuntu-notification-helper
[12:54] <apachelogger> (invokes apport-kde usually) looks for .drkonqi-accept for each pending crash -> if found custom script dervied from whoopsie-upload-all is executed to batch upload -> otherwise apport-kde notification is shown
[12:55] <apachelogger> long-term goal to get rid of the drkonqi file and use .upload with aggregation done inside whoopsie if something is missing from the report
[12:57] <mcpierce> rbasak: Will do. :D
[13:32] <pkern> infinity: We're pulling development every 20 minutes at the moment and archive for eternity. That's slightly inefficient, of course. But I'm more interested in LTS per month churn once it's stable.
[13:33] <mcpierce> y
[13:38] <tseliot> pitti: if I make a package recommend another and the user has the former already installed, will the user get the recommended package through the updates?
[13:48] <pitti> tseliot: yes
[13:50] <tseliot> pitti: ok, the problem is that I'd like to make nvidia-331 recommend nvidia-prime but I would also like to give users the chance to remove nvidia-prime and install bumblebee instead. This would work only if they don't update
[13:51] <pitti> tseliot: so perhaps recommends: prime | bumblebee ?
[13:52] <tseliot> pitti: I don't think bumblebee is in main
[13:52] <pitti> tseliot: that's ok, only the primary (preferred) alternative needs to be as it's the one which is installed by default
[13:52] <pitti> tseliot: with that, if an user already has bumblebee installed, it wouldn't additionally install prime for him
[13:53] <tseliot> pitti: ah, that would work. Thanks!
[13:53] <pitti> tseliot: I'm not saying that this is what you want (you know better what shoudl happen on upgrades), just that it's a possibility
[13:53] <tseliot> pitti: yes, it should be enough
[13:57] <tseliot> pitti: so, to double check, something like this would work, right? Recommends: nvidia-prime (>= 0.5) | bumblebee-nvidia
[13:57] <pitti> tseliot: users which have either installed won't get any package change on upgrades; users which have neither installed will get nvidia-prime
[13:58] <pitti> tseliot: if that's the semantics you want?
[13:58] <tseliot> pitti: yes, that's exactly what I need. Thanks :)
[14:01] <pitti> tseliot: great
[14:23] <mterry> @pilot in
[14:35] <pkern> xnox: Why don't you use https for the snapshotter?
[14:35] <pkern> No reason not to, these days. At least if APT knows SNI. (No clue if it does.)
[14:36] <mvo> pkern: libcurl is used by apt for the https so SNI should be fine
[14:38] <pkern> Yeah, well. Still unhappy with curl as the https provider. |;
[14:39] <mvo> pkern: oh? what do you suggest instead?
[14:40] <pkern> If I knew. I wanted to look at this stuff this quarter but didn't get to it. neon at least states that it does PKCS#11, but then apt is I think GPL without an OpenSSL exception and hence it still wouldn't be useful for distro purposes.
[14:41] <mvo> pkern: the status is a bit unclear, if we can reach jgg for a formal statement then it would be much easier
[14:46] <xnox> pkern: mvo: my problem was that I don't have an SSL sertificate on my domain, therefore my nginx redirector was causing http -> https (launchpad) -> 302 -> https launchpadlibrarian. This is all fine for wget, but not for apt-get it compliant that it couldn't verify something or that certs were changing.
[14:48] <xnox> pkern: mvo: i could get an ssl cert on my domain, but i'm not sure if that would have helped. and I really don't want to pay for traffic to fetch it on my server, just to stream it to the client. I want clients to connect / download from the upstream /pool/, and only fetch /dists/ from me.
[14:48] <xnox> pkern: mvo: i will set it up again and let you know.
[14:48] <pkern> mvo: http://search.gmane.org/?author=Jason+Gunthorpe&sort=date seems to list an email address.
[14:49] <pkern> xnox: redir shouldn't switch transport methods (but no, I didn't check if it works, we still serve everything directly)
[14:49] <pkern> From https to https I mean.
[14:50] <xnox> pkern: well, it will have to, to optimise bandwidth. So i'm continuously snapshotting /dists/ (such that I have real Releases.gpg), but /pool/ URLs are fallthrough provided by archive.ubuntu.com, ports.ubuntu.com, old-releases.ubuntu.com, and finally launchpadlibrarian.
[14:50] <xnox> pkern: all but librarian are http.
[14:51] <xnox> pkern: but now i worked out a way to make librarian urls also http.
[14:51] <xnox> pkern: there is no need for https, because one verifies archive gpg signatures
[14:52] <xnox> pkern: but I do understand that many people want to use https nonetheless to hide which packages are fetched / conseal the traffic.
[14:52] <xnox> pkern: that's why i will be making my data public, as a git repository such that one can set up their own redirector behind https / firewalled or as needed.
[14:58] <pkern> xnox: Or because they need authentication. Hence the problem of missing PKCS#11 support.
[14:58] <pkern> ;)
[14:59] <xnox> ;-) touche
[15:03] <zul> doko:  ping
[15:05] <zul> doko:  can you promote python-webtest please?
[15:25] <dholbach> cjwatson, robru: nice bug fixes in the newest click :)
[15:37] <doko> zul, promoted the dependencies
[15:37] <zul> doko:  cool thanks
[15:37] <doko> zul, re migrate: we won't promote sqlite again
[15:38] <doko> and nose needs some mir's
[15:38] <zul> doko:  yeah im not worried about migrate yet
[15:38] <Munchor> Guys, thank you for the GTK+ 3.10 on 14.04, it's great, great news, good job
[16:19] <shadeslayer> anyone have a clue why querying the version via python doesn't work but via the terminal works : http://pastebin.kde.org/pf3kgvn7u
[16:20] <Riddell> shadeslayer: system vs session bus?
[16:21] <shadeslayer> http://pastebin.kde.org/p0brmjotq
[16:23] <jodh> shadeslayer: http://bazaar.launchpad.net/~upstart-devel/upstart/trunk/view/head:/scripts/pyupstart.py#L327
[16:24] <Riddell> shadeslayer: if I use qdbus I get Rejected send message,
[16:24] <shadeslayer> Riddell: 0.o
[16:25] <shadeslayer> jodh: I /have/ to use Qt :)
[16:34] <stgraber> pitti: bug 1197395 and bug 1245189 appear to be missing the usual SRU paperwork (systemd sru)
[16:35] <jodh> shadeslayer: that's not what I referring to. FREEDESKTOP_PROPERTIES='org.freedesktop.DBus.Properties', so you've specified the wrong interface in your python example I think?
[16:36] <shadeslayer> >>> upstartinterface = QtDBus.QDBusInterface("com.ubuntu.Upstart", "/com/ubuntu/Upstart", "org.freedesktop.DBus.Properties",QtDBus.QDBusConnection.systemBus())
[16:36] <shadeslayer> >>> print(upstartinterface.property("version").toString())
[16:36] <shadeslayer> gives me nothing
[16:36] <shadeslayer> jodh: plus,QDBusInterface has a special function to read properties
[16:44] <pitti> stgraber: ah, keymaps have an SRU exception; I thought diwic made the SRU prep for the other one, hang on
[16:46] <pitti> stgraber: 1197395 has an SRU test case; you want a regression potential?
[16:48] <stgraber> pitti: oh, didn't know about the keymaps exception (I really need to learn the list by heart ;)), for the other one, I must have missed it. I think between the testcase and the comments, it's fine. I'll accept the upload then.
[16:49] <pitti> stgraber: the bug description is quite long indeed; I'm currently adding a pointer to the fix and a regression potential
[16:49] <stgraber> pitti: thanks!
[16:52] <pitti> stgraber: added; it actually makes some sense for this bug as the regression potential is nonzero (even though it's a bit academic) and there is an actual behaviour change
[16:53] <mterry> mvo, hello!  I was looking at command-not-found, and it's update-from-web.sh script is giving a 404 on http://ports.ubuntu.com/~mvo/command-not-found/scan.data-latest
[16:53] <pitti> stgraber: thanks for processing (nice to see SRUs not having large delays any more!)
[16:56] <stgraber> pitti: well, we didn't do so well the past few weeks because of the massive KDE SC SRUs in the saucy queue, but yeah, I think we're mostly keeping up for the past few months, that's good to see!
[17:00] <shadeslayer> could someone help me with the upstart dbus bug that I'm experiencing?
[17:17] <mvo> hey mterry! I can't unfortunately access this host anymore, but there used to be a script running there that extracts the command-not-found data from the local archive
[17:17] <mvo> mterry: I would love to fix it, not sure if (temporary?) access could be granted for this
[17:19] <mterry> mvo, or maybe we need to put it in some team account
[17:19] <mterry>  long-term
[17:19] <mvo> mterry: YES, definitely
[17:21] <seb128> mvo, hey, how are you?
[17:21] <mvo> seb128: good, thanks!
[17:21] <mvo> seb128: and you?
[17:21] <seb128> mvo, I'm good thanks
[17:22] <seb128> mvo, not sure if you saw my Cc on https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1258112
[17:22]  * mvo looks
[17:22] <seb128> mvo, it would be nice if you could comment, seems like Dylan is wanting to fix the issue but needs some guidance/background on why the code is this way
[17:23] <mvo> seb128: yeah, I need to look at the bzr log to remember :)
[17:23] <seb128> mvo, ;-)
[17:26] <mvo> seb128: I'm currently working on a apt bug - once that is done I check this one out
[17:26] <seb128> mvo, no hurry, I was just unsure if you noticed launchpad Ccs or if that would go to spam box
[17:27] <seb128> mvo, thanks ;-)
[17:28] <seb128> mvo, speaking about apt bug, that's not bug #957231 by any chance? ;-)
[17:28] <mvo> seb128: no :P - are you trying to trick me into fixing this one too ;)
[17:29] <seb128> mvo, lol, I wouldn't say no, just having a clean e.u.c obsession recently ;-)
[17:29] <seb128> mvo, joke aside, we got most of the top issues, including the webkit/software-center one that hits quite some users since saucy, just a few remaining (well on the high ranked ones)
[17:30] <seb128> mvo, that one being of those
[17:30] <mvo> seb128: nice!
[17:37] <mvo_> seb128: hrm, X crashed :/
[17:38] <mdeslaur> mvo_: watch out, or seb128 will trick you into fixing X too :)
[17:38] <mvo_> mdeslaur: lol - we should replace it with something better I guess :P -
[17:38] <mdeslaur> heh
[17:38] <seb128> hum, me or X?
[17:38] <seb128> ;-)
[17:38] <mdeslaur> lol
[17:39] <mvo_> seb128: there is nothing better you know
[17:39]  * seb128 hugs mvo
[17:39]  * mvo_ hugs seb128
[18:39] <comjf> can anyone help me resolve this isue when trying to apt-get update --fix-missing
[18:39] <comjf> W: A error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://us-east-1.ec2.archive.ubuntu.com precise-updates Release: The following signatures were invalid: BADSIG 40976EAF437D05B5 Ubuntu Archive Automatic Signing Key <ftpmaster@ubuntu.com>
[18:41] <sarnold> comjf: are you by any chance using apt-cacher-ng?
[18:42] <comjf> sarnold: not that I am aware of, just spun up a brand new AWS EC2 12.04.03 instance
[18:42] <comjf> and my automation tools run an apt-get install command
[18:43] <comjf> then it errored, when trying to manaully fix it, I get that error
[18:44] <sarnold> comjf: drat. try rm -rf /var/lib/apt/lists/  and then apt-get update && apt-get install ... again.
[18:46] <comjf> sarnold: giving it a whirl, thanks
[18:47] <comjf> sarnold: same error :( I ran W: GPG error: http://us-east-1.ec2.archive.ubuntu.com precise-updates Release: The following signatures were invalid: BADSIG 40976EAF437D05B5 Ubuntu Archive Automatic Signing Key <ftpmaster@ubuntu.com>
[18:48] <comjf> woops, I ran: sudo rm -rf /var/lib/apt/lists/ && sudo apt-get update
[18:48] <comjf> is there a way I can use a different mirror then the ec2 one... maybe they messed something up
[18:49] <sarnold> comjf: I don't know how the billing works out to use a different datacenter, just be aware of that...  edit /etc/apt/sources.list to use a different mirror
[18:50] <comjf> sarnold: hm good point. It couldn't cost that much to install a few packages.. at least I hope
[18:51] <comjf> are there any other debugging steps I should preform before trying that though?
[18:57] <comjf> sarnold: thanks for your help, I saw your post in the other channel, I'll monitor that chan now. I appreciate your quick response
[19:24] <d4c7> anyone familiar with default apache ciphersuite/ssl settings in precise that changed from previous releases?
[19:45] <mterry> @pilot out
[20:12] <barry> @pilot in
[21:29] <mterry> barry, sorry for leaving all those syncs for you to close...  I was waiting for emails from Launchpad that never seemed to have come
[21:30] <barry> mterry: no worries at all!
[21:30] <barry> mterry: thanks for actually doing the syncs :)
[22:37] <doko> infinity, any update on the state of glibc-2.18?
[22:38] <infinity> doko: I have the Ubuntu merge changelog written up, just going to give it one more test-build with the latest Debian changes and JFUI, I think.
[23:04] <barry> @pilot out