[02:55] <pitti> Good morning
[02:56] <pitti> apw: hm, I don't remember this at all
[02:56] <pitti> ogra_, apw: yes, systemd pid 1 mounts /proc and /sys, similarly to mountall in the upstart world
[02:56] <infinity> pitti: Hey.  You have some tasks with your name on them on NewReleaseCycleProcess
[02:57] <infinity> pitti: retracer, ddebs, autopkgtest...
[02:57] <pitti> ogra_, apw: but not sure what these have to do with mtab -- /etc/mtab is a zombie which never quite dies sufficiently to get rid of it :/ but either way, at the time when we mount /proc and /sys it's definitively too early to even consider (or read) /etc/mtab
[02:57] <pitti> infinity: hey
[02:57] <pitti> infinity: yeah, finally :)
[03:04] <pitti> infinity: did we already get any uploads to utopic? i. e. anything to catch up with on ddebs?
[03:04] <infinity> pitti: A few, yeah.
[03:04] <infinity> pitti: https://lists.canonical.com/archives/utopic-changes/2014-April/thread.html
[03:11] <pitti> infinity: ddebs set up; cron job starts in 30 mins, I'll check ddebs when I start my day for real
[03:12] <infinity> pitti: Lovely.  I assume autopkgtest will be more effort.
[03:13] <pitti> infinity: I'll deal with that with jibel this morning
[03:18] <pitti> infinity: utopic retracers set up
[03:41] <infinity> pitti: Dude, I just realized what time it is.  What sort of crazy person wakes up at 5am?
[03:42] <pitti> infinity: heh, you of all people complain about weird working hours? :-)
[03:43] <pitti> I woke up at 4, couldn't sleep any more, so I thought I could just as well do something useful
[03:43] <pitti> and maybe get tired over it :)
[03:43] <infinity> pitti: Ahh, kay.  *That* happens to me all the time.  I was afraid this might have been an intentional wakeup, and was going to send nice men in pretty white coats to take you away.
[03:44] <pitti> heh; I'd give a lot for being able to sleep through a whole night; I've had some trouble with that for a year or so
[03:45] <infinity> pitti: I feel your pain.
[03:45] <infinity> pitti: I make it through maybe one night a week, if I'm lucky.
[03:45] <pitti> urgh
[03:46] <infinity> (And it usually seems to be when I actually needed to be up early...)
[03:46] <infinity> Basically, I can't win. :P
[06:35] <dholbach> good morning
[06:35] <MacSlow> hey dholbach
[06:35] <dholbach> hey MacSlow
[06:44] <ari-tczew> hello
[06:55] <dholbach> hi ari-tczew
[07:29] <aleb> How can I become a maintainer of the Launchpad package I'm developing (upstream)?
[07:38] <mlankhorst> who's the current maintainer?
[07:41] <aleb> "registry" https://launchpad.net/pitivi
[07:41] <aleb> I guess nobody
[07:42] <jamesh> aleb: ask on #launchpad
[07:42] <jamesh> aleb: wgrant or cprov should be able to help
[08:24] <ogra_> pitti, mtab gets linked to /proc/mounts very very early in the initrd (pretty much the first thing the /init script does there)
[08:24] <pitti> ogra_: oh, do we do this now? niiic!
[08:25] <pitti> /etc/mtab -> /proc/mounts
[08:25] <ogra_> i wonder if we couldnt just leave it that way instead of having something create a file
[08:25] <pitti> I have it on my desktop, but I have a suspicion that's systemd, not ubuntu standard
[08:25] <ogra_> iirc there were reasons to still have it
[08:25] <pitti> I guess to keep track of non-kernel mount options?
[08:25] <ogra_> like tools parsing it and expecting a certain fromat that /proc/mounts doesnt give us
[08:25] <pitti> it's mostly the same format, but /proc/mounts doesn't retain userspace options
[08:26]  * ogra_ would love if we could just keep it a link now
[08:26] <pitti> me to
[08:26] <pitti> too
[08:26] <pitti> /etc/mtab has been a horrible horrible misconception
[08:26] <ogra_> right, therewas info missing, but we might need to fix some external tools to not regress
[08:27] <ogra_> (if they still expect a certain format)
[08:28] <pitti> ogra_: what's your /etc/mtab on your desktop?
[08:29] <ogra_> its a file ... i'm on precise
[08:29] <pitti> oh, wow
[08:29] <ogra_> i'm pretty sure its a file on trusty too
[08:29] <ogra_> (not on the phone weher mountall is largely a no-op (all mounting happens in initrd there)
[08:30] <pitti> ok, so I guess systemd sets that up
[08:30] <ogra_> is it a link under systemd?
[08:30] <pitti> yes
[08:30] <ogra_> cool
[08:31]  * pitti tries something
[08:31] <pitti> ok, that works
[08:31] <pitti> uhelper=udisks2
[08:31] <ogra_> i think we can rely on tools to be fixed then
[08:31] <pitti> that's an userspace mount option that udisks uses so that you can call "umount" as user on auto-mounted drives
[08:31] <pitti> and that works
[08:32] <ogra_> great
[08:32] <pitti> and that's the bit which is *not* in /proc/mounts
[08:32] <pitti> but "mount" does show it
[08:32] <pitti> so it keeps track of those someplace else now
[08:32] <ogra_> hmm
[08:32] <pitti> hah! /run/mount/utab
[08:33] <pitti> SRC=/dev/sdb1 TARGET=/media/martin/PittiUSB ROOT=/ OPTS=uhelper=udisks2
[08:33] <pitti> so util-linux had this fixed ages ago
[08:33] <pitti> not quite surprising, given how long Fedora etc. have run with /etc/mtab -> /proc/mounts
[08:33] <ogra_> heh
[08:33] <pitti> so, user mount options: check
[08:33] <pitti> that was the only reason AFAIK why we still needed that
[08:33] <ogra_> :)
[09:35] <jamesh> mardy: could I pick your brain about online accounts again?
[09:40] <xnox> ogra_: on the phone most mounting is done by mountall =) like the gazillions of bind mounts.
[09:40] <ogra_> xnox, nope
[09:41] <ogra_> its all done in the initrd
[09:41] <ogra_> oh, wait, you are right, the binds are done by mountall
[09:41] <ogra_> the actual mounts arent
[09:42] <xnox> pitti: i think we do need newer util-linux, we've been staggering behind for a while now....
[09:42] <xnox> lamont: infinity: what's the status about getting newer util-linux?
[09:42] <pitti> xnox: we don't need it for this particular issue, but having a non-ancient one would be good nevertheless
[09:42] <mardy> jamesh: hi, sure
[09:42]  * xnox needs to check the partman/d-i bugs about it.
[09:44] <jamesh> mardy: I put together .provider and .service files for SoundCloud via the desktop.  I put together this short test program to try and retrieve the access token, but it seems to log me out again: http://bazaar.launchpad.net/~jamesh/unity-scope-soundcloud/go-port/view/head:/accounts/accounts.c
[09:44] <pitti> xnox: there are some attempts to moving to a newer version by some community members, but as it doesn't have broken-out patches it's quite a mess I'm afraid
[09:44] <xnox> pitti: ok. imho everything should partse mountinfo, not mtab / mounts. but i guess loads of things will never learn.
[09:44] <jamesh> I get the error "GDBus.Error:com.google.code.AccountsSSO.SingleSignOn.Error.UserInteraction: userActionFinished error: 10" and a notification bubble saying I've been logged out
[09:44] <pitti> xnox: we certainly should keep the /etc/mtab symlink around for some time, yes
[09:45] <xnox> pitti: yeap, that should be fine.
[09:45] <jamesh> I used the signon-ui logging environment variables you gave me before to see that an access token was retrieved correctly, so I would have thought it would just be provided to me directly
[09:45] <xnox> pitti: how is lightdm/plymouth integration with systemd? do i need to steal/port units over?
[09:46] <pitti> xnox: I have lightdm with a systemd unit in my PPA (and soon in utopic); there is no plymouth integration ATM
[09:46] <pitti> i. e. boot is just with a black screen until lightdm starts
[09:46] <mardy> jamesh: but then, if you go to the Online Accounts panel, you should see an exclamation mark next to the soundcloud account
[09:46] <pitti> not that I'd see it for a long time (it's just a second or so)
[09:46] <mardy> jamesh: which means it needs to be authenticated
[09:46] <mardy> jamesh: the reason is that we need to popup a UI in order to authenticate
[09:47] <pitti> xnox: plymouth integration certainly sounds like one of the more/most complicated bits in that transition
[09:47] <jamesh> mardy: yes.  I log in again in the control panel, rerun my program and get the same result
[09:48] <mardy> jamesh: OK, this is weird then. Can you enable the logging in /etc/signond.conf, try again (both from the control center and from your app) and send me the syslog?
[09:48] <mardy> jamesh: you might have to clear it from sensitive informations, maybe
[09:48] <jamesh> mardy: okay.  I'll give that a shot
[09:49] <xnox> pitti: also re:utopic-plans-of-running-system-upstart-as-pid2 do we want that at all? i was still unsure how to achieve that.
[09:49] <pitti> xnox: I don't think we want it for anything packaged; just ensuring that for every upstart-only job that we have (i. e. no init.d script) we add an accompanying unit seems easier to me
[09:50] <pitti> xnox: but I think during the UDS session we said we'd want it for custom upstart jobs written by the admin?
[09:51] <xnox> pitti: right, have you seen https://code.launchpad.net/~upstart-devel/upstart/upstart-jobs ?
[09:51] <xnox> pitti: that branch has all upstart jobs, all initd scripts and all unit files present in ubuntu at the moment.
[09:52] <pitti> xnox: heh, no; is that somehow magically updated from all packages from the archive?
[09:52] <pitti> http://bazaar.launchpad.net/~upstart-devel/upstart/upstart-jobs/view/head:/fetch-contents.mk
[09:52] <pitti> nice
[09:53] <pitti> xnox: I added a link to that to https://blueprints.launchpad.net/ubuntu/+spec/core-1403-systemd-transition
[09:56] <pitti> hah! there, bluetooth fixed; it's quite nice, now it only starts up if you actually have a bluetooth adapter
[09:57] <ogra_> pitti, not so sure about that ... how does it know ?
[09:58] <ogra_> on the phone you might end up that you actually dont see all of the BT device
[09:58] <pitti> ogra_: it doesn't start by default; but there is this rule in /lib/udev/rules.d/99-systemd.rules:
[09:58] <pitti> SUBSYSTEM=="bluetooth", TAG+="systemd", ENV{SYSTEMD_WANTS}+="bluetooth.target"
[09:58] <ogra_> ugh
[09:58] <pitti> then it starts bluetooth.target
[09:58]  * ogra_ hopes that will still work with the hardware being handled inside the container 
[09:58] <pitti> ogra_: how can bluez work on the phone if there are no devices?
[09:59] <ogra_> we have custom per-device BT upstart jobs atm
[09:59] <pitti> ogra_: in the worst case we put it back on "always start" on the phone
[09:59] <ogra_> (thats about to change and the full logic will move into the container, on the ubuntu side only bluetootd should start)
[09:59] <pitti> ogra_: custom jobs? on the phone you mean? because on teh desktop we just always start it
[10:00] <ogra_> yes, we run hciattach with the per device options atm ... but that will move into the container
[10:01] <ogra_> note that we suppress starting of udev too
[10:01] <ogra_> until after the container is up ...
[10:01] <pitti> ogra_: in theory this should be fine; bluetooth needs to see a device to actually work; and once you see it, udev ought to see it as well
[10:01] <pitti> and as I said, if due to our weird hacks this is broken, we just enable it to always start
[10:01] <ogra_> so the events get used by udeventd (android) instead of udev
[10:02] <pitti> ogra_: we don't run an udev coldplug?
[10:02] <ogra_> you cant "just always start" BT on a phone
[10:02] <ogra_> that might eat your battery ...
[10:02] <pitti> ogra_: well, or transition whichever custom upstart jobs we have (I didn't look at them yet)
[10:02] <pitti> but binding this to "I have BT hardware" sounds like the right thing in general?
[10:03] <ogra_> pitti, udev starts in initrd ... then gets shot down, once the container starts ueventd grabs the events ... once the container is up we start udev normally
[10:03] <ogra_> pitti, lxc-android-config has all of the custom jobs in one place
[10:03] <ogra_> (well, everything container related at least)
[10:04] <ogra_> (sorry, i'm a little over-cautious ... )
[10:05] <pitti> ogra_: hm, I see a few udev rules which change permissions of BT devices, but no custom jobs?
[10:05] <pitti> ogra_: sure :) well, it's not like we'd dump that on the phone and don't check :)
[10:05] <ogra_> oh, for BT they are in bluetooth-touch
[10:05] <ogra_> i thought you wanted to see the udev side :)
[10:06] <pitti> bluetooth-touch-mako.conf just has a few setprop calls
[10:08] <ogra_> yeah, looks at the others :)
[10:08] <ogra_> *look
[10:09] <pitti> ogra_: I did, but they all just seem to fiddle with the killswitches or poke some bits into the android side, or load firmware
[10:09] <ogra_> really depends what chipset you have all devices with broadcom need to load some blob dynamically using brcm_patchram
[10:09] <pitti> ogra_: I don't actually see any change to bluez startup?
[10:09] <ogra_> no, but to the device startup
[10:09] <pitti> yeah, that's fine
[10:10] <ogra_> if udev doesnt run at that time ueventd might steal the event
[10:10] <pitti> ogra_: we need to do an udev coldplug run after starting udev (just like on the desktop/server if you have an initramfs)
[10:11] <pitti> otherwise a lot more stuff will be broken anyway, so I suspect we already do that
[10:11] <ogra_> hmm, i hope that doesnt slow us down ...
[10:11] <pitti> well, we have a lot of udev rules there, including the ones in lxc-android-config
[10:11] <pitti> they won't actually run if we don't coldplug udev :)
[10:11] <ogra_> ok :)
[10:12] <pitti> so it would be very weird if we don't do that already; also for device permissions, creating persistent storage/usb/etc. links
[10:13] <ogra_> ah, right, that we do
[10:13] <ogra_> (device permissions)
[10:14] <pitti> ogra_: yeah, they will also run during coldplug, as on the phone all the devices are already there when you start udev (i. e. no hotplugging)
[10:14] <pitti> ogra_: so in theeeory, if we write unit counterparts for the bluetooth-touch upstart jobs, it should just work
[10:14] <pitti> in practice, it'll all break horribly initially, of course :)
[12:03] <mpt> bdmurray, where are the “failed” colors used?
[12:03] <mpt> I don’t know if I’ve ever seen them before.
[12:22] <xnox> kenvandine: mardy: hey! i'm poking ubuntu-system-settings, online-accounts, on the unity7 desktop. When i open-up "add u1 account" i just see a blank screen =(
[12:24] <kenvandine> xnox, i don't think you should even see that on the desktop
[12:24] <mardy> xnox: you are probably missing the U1 plugin. Let me see how it's called...
[12:25] <Laney> It's greyed out for me
[12:25] <xnox> kenvandine: i want to, though =)
[12:25] <kenvandine> oh... in uss, not unity-control-center :)
[12:25] <pitti> doko_, xnox: please ignore the utopic-adt failures for now; we are currently setting up autopkgtest for utopic, and will fix/retry these
[12:26] <xnox> kenvandine: yeap, i want to see if qml/qt5 u1 works and try to somehow re-use it in the ucc with black magic.
[12:26] <xnox> kenvandine: cause it's a pain to maintain python2-qt4-webkit on the dekstop images
[12:26] <kenvandine> indeed
[12:26] <mardy> xnox: it should just be account-plugin-ubuntuone
[12:27] <xnox> mardy: not installed. installing. Strange that "u1" was listed in the "add-account view" even though i don't have it =/
[12:27] <xnox> mardy: now it "just works" even without restarting uss =)
[12:27] <mardy> xnox: yep, for some reason /usr/share/accounts/providers/ubuntuone.provider is provided by ubuntuone-credentials-common instead
[12:29] <xnox> mardy: excellent this works now, thanks.
[12:29] <xnox> Now on to the black magic of getting it to work with ucc
[12:29] <mardy> xnox: yep, I'm afraid you are entering a minefield
[12:30] <mardy> xnox: ucc is Gtk-based, so you'd have to use XEMBED
[12:30] <kenvandine> haha
[12:30] <xnox> mardy: that was my plan, indeed.
[12:30] <mardy> xnox: which we are also using BTW in other plugins :-)
[12:30] <xnox> mardy: oh really?! like which?
[12:30] <seb128> xnox, mardy: bug #1287640 is the "provider is installed in common which leads to buggy entries"
[12:30] <xnox> mardy: or is it the other way around to get gtk plugins to show up in the qml app?
[12:31] <mardy> xnox: most of them, except the empathy ones. Basically all those which are authenticated via OAuth (facebook, google, flickr, twitter)
[12:31] <xnox> mardy: cool.... and u1 is not using OAuth because *reasons*
[12:32] <mardy> xnox: because U1 is using OAuth 1.0 (not 1.0a or 2.0), or a variant of it
[12:33] <mardy> xnox: indeed, if it used OAuth, making it work would be just a matter of setting the right data in the provider XML file
[12:33] <mardy> xnox: I had this discussion several time with the U1 folks, but the idea was that migrating to a standard OAuth would be too much work
[12:34] <mardy> xnox: your starting point should probably be http://bazaar.launchpad.net/~online-accounts/gnome-control-center-signon/trunk/files/head:/libaccount-plugin/
[12:35] <mardy> xnox: the oauth-plugin.c file implements a subclass of ApPlugin, which authenticates via OAuth by embedding the window which will be created by signon-ui
[12:36] <xnox> mardy: but not implementing 1.0a means that both U1 and Launchpad are vulnerable to the session-fixaction attack.
[12:36]  * mardy googles, never heard of that thingie
[12:37] <xnox> mardy: and i have managed to complete oauth authentication with 1.0a client against launchpad, simply specify any string as verifier.
[12:37] <xnox> mardy: http://oauth.net/advisories/2009-1/
[12:39] <xnox> mardy: essentially to exchange request-token for an access-token, one should supply "oauth_verifier" which is returned to the user upon authorizing request (and/or in the callback url)
[12:41] <xnox> mardy: this mirrors the challenge - to verify that the same client that authorized access, exchanges the request-token.
[12:41] <mardy> xnox: please get in touch with the U1 guys (dobey?), they'll certainly know more
[12:41] <mjt> Hello.  Is it okay to add a package to Suggests: if it is only available in universe?  I remember it is not good to Recommend a package from universe, but how about Suggests?
[12:42] <xnox> mjt: suggests is fair game.
[12:42] <xnox> mjt: we drop things from recommends to suggests all the time, when we want to keep certain stacks in universe, and not get pulled into main.
[12:42] <xnox> mjt: main is closed set of (build-depends, depends, recommends)
[12:43] <mjt> so basically, one can use Suggests for everything, even for something not in archive? :)
[12:43] <xnox> mjt: it's against debian policy to suggest something that is not in the archive. Or suggest non-free things in main.
[12:44] <mjt> hm. Is it #ubuntu-devel, or #debian-devel? :)
[12:44] <xnox> mjt: so if you do that, you'll get an RC bug in debian. But in ubuntu we don't have a concept of RC bugs, so although we have reports we don't currently have people actively investing time to enforce that part of debian policy.
[12:45] <mjt> speaking of non-free things, suggests: is the only way to have, say, firmware
[12:45] <xnox> mjt: surprisingly, debian-policy is still a requirement in the ubuntu, sans were we explicitly diverged / applied changes.
[12:45] <mjt> sure, hence the smile at the end of my statement
[12:46] <xnox> mjt: firmware in ubuntu, can go into multiverse and/or restricted, since it's hardware-dependent blobs. And in ubuntu one can suggest those.
[12:53] <xnox> mardy: looking at account-plugins -> all of them are oauth2.0. is there support for 1.0 at all?
[12:53] <mardy> xnox: flickr and twitter use 1.0a
[13:00] <cjwatson> pitti: Are you able to set up autopkgtest for utopic?  Would be nice to get results for the runs that were triggered by binutils
[13:00] <pitti> cjwatson: jibel and I are working on that furiously :)
[13:00] <pitti> cjwatson: http://d-jenkins.ubuntu-ci:8080/view/Utopic/view/AutoPkgTest/
[13:00] <pitti> cjwatson: still some fallout, I'm on that
[13:00] <pitti> like missing ddebs indexes for utopic-updates/security (just fixed), and some autopkgtest bugs
[13:01] <pitti> cjwatson: jibel sent an RT to publish that to the public jenkins, too
[13:03] <cjwatson> pitti: ah, right, thanks
[13:05] <pitti> man, everything related to the DC feels like a tarpit today; must be release time :)
[13:12] <xnox> mardy: right, so it looks like canonical-sso and launchpad-oauth are two different beasts. launchpad-oauth uses standard 1.0 way to request token, whereas canonical-sso does not.
[13:16] <dobey> xnox: launchpad doesn't use standard oauth 1.0 so much
[13:16] <dobey> xnox: and the u1 plug-in isn't using the oauth plug-in, it's a custom plug-in that talks to the sso v2 api
[13:18] <dobey> xnox: the gtk+ online-accounts UI requires providing a plug-in written in gtk+ for UI, and we only have a qml UI, so it doesn't work under unity-control-center; you have to use system-settings to add/manage a u1 account in uoa
[13:18] <bdmurray> mpt: here - https://errors.ubuntu.com/retracers-results/
[13:19] <xnox> dobey: under https://launchpad.net/~xnox/+oauth-tokens one totally uses bog standard oauth 1.0 with https://launchpad.net/+request-token , https://launchpad.net/+authorize-token, https://launchpad.net/+access-token OAuth 1.0 endpoints.
[13:19] <xnox> dobey: e.g. launchpadlib and all scripts that drive launchpad use it (e.g. syncpackage, requestsync, import-bug-from-debian, etc.)
[13:19] <xnox> dobey: where is sso v1 api docs?
[13:20] <xnox> dobey: and how come sso v2 doesn't provide a normal oauth 1.0 api?
[13:20] <xnox> dobey: or oauth 2.0 api...
[13:20] <dobey> xnox: yes, but launchpad doesn't quite follow the oauth spec exactly. the oauth plug-in in UOA doesn't work with getting a token on launchpad.net (i made a plug-in to try it :)
[13:20] <dobey> xnox: oauth api is separate from sso api
[13:20] <dobey> xnox: sso just doesn't provide an oauth api at all
[13:20] <xnox> dobey: is oauth api available on sso.... oh *damn*
[13:21] <xnox> dobey: well, i may have a merge proposal against launchpad and python-requests-oauthlib to make it standard compliant ;-)
[13:21] <dobey> xnox: i'm not sure where sso v1 api docs are; it's discouraged to use it
[13:22] <xnox> dobey: at the moment +access-token page must use "body" signature type, instead of header. And i have merge proposal to fix that.
[13:22] <dobey> xnox: the problem with launchpad mostly, is that it doesn't use a consumer key, iirc
[13:22] <xnox> dobey: nah, that works just fine. One specifies any, with no secret. and launchpad just accepts any.
[13:23] <xnox> dobey: do you have that UOA plugin around? i wonna try it against my launchpad dev instance.
[13:23] <dobey> i don't know, i'll have to look
[13:26] <xnox> ideally canonical-sso would support oauth api for requesting a token.
[13:27] <dobey> xnox: no need to convince me. i would ♥ oauth2 support
[13:27] <xnox> dobey: no, no, no =) oauth1 api for requesting tokens ;-)
[13:27] <xnox> dobey: oauth2 is *evil* =)
[13:28] <dobey> no
[13:28] <dobey> oauth1 is evil
[13:28] <xnox> dobey: "When compared with OAuth 1.0, the 2.0 specification is more complex, less interoperable, less useful, more incomplete, and most importantly, less secure." http://hueniverse.com/2012/07/26/oauth-2-0-and-the-road-to-hell/
[13:29] <xnox> dobey: a whole bunch of authors withdrew their names and association from oauth 2.0....
[13:29] <xnox> dobey: oauth 2.0 has one benefit - easy client code.
[13:30] <dobey> oauth 2 has lots of benefits
[13:30] <dobey> not just easy client code
[13:31] <dobey> well, oauth any version is evil; but oauth 2 is slight less evil for what we're doing
[13:41] <sergiusens> xnox: I'm an oauth newbie, but are you looking for something like this? curl -H "Content-Type: application/json" -X POST -d '{"mail": "email", "password": "password", "token_name": "mytokenname", "otp": "2fa"}' https://login.ubuntu.com/api/v2/tokens/oauth
[13:42] <xnox> sergiusens: yeah, i have reference to that. that's canonical-sso specific api to get u1 tokens.
[13:43] <xnox> sergiusens: although it returns an oauth 1.0 token, that's not how oauth 1.0 spec mandates to create tokens.
[13:44] <sergiusens> xnox: yeah; sso isn't fully oauth compliant; you can talk to nessita or pindonga for details I guess
[13:47] <dobey> xnox: it returns a token that is compatible with oauth 1.0; it is not an oauth token :)
[13:47] <dobey> it's an sso token
[13:49] <dobey> and signed requests are oauth compatible
[13:49] <xnox> dobey: the devil is in the details =) fun
[13:49] <xnox> dobey: duck-typing for the win =)))
[13:50] <dobey> oauth 2 would be great though, so i can throw away 90% of the code in ubuntuone-credentials, and we can avoid having a consumer_secret on the client, and etc etc
[13:51] <dobey> xnox: though, what are you trying to do? replace ubuntu-sso-client in 14.10 with the UOA stuff?
[13:51] <xnox> dobey: yeah.
[13:52] <xnox> dobey: at least such that login works, possibly without signup. I could refactor ubiquity's ubuntuone plugin into accounts plugin.
[13:52] <dobey> xnox: maybe fix the UOA gtk+ UI to allow embedding the qml plug-ins, and not require gtk+ ones
[13:53] <xnox> dobey: exploring that as well with xembed type of things.
[13:53] <xnox> dobey: but that is kind of against mir strategy.... or does xembed work under mir? =/
[13:53] <dobey> xnox: well, afaik the webkit view for the oauth plug-ins is just xembedded
[13:53] <xnox> dobey: correct.
[13:54] <dobey> xnox: are we going to keep having two separate system settings apps when we swtich to mir?
[13:54] <dobey> xnox: or will we just use the ubuntu-system-settings then?
[13:54] <xnox> dobey: no idea... i just want to kill python2-qt4-webkit on the desktop, with least amount of effort possible.
[13:55] <dobey> xnox: port ubuntu-sso-client to qt5? :)
[13:55] <dobey> xnox: fwiw, i don't think it's using anything that is no longer in qt5, but i don't really know where to begin with porting a python app from qt4 to qt5
[13:56] <dobey> xnox: alternatively, we could possibly bring back the gtk+ UI instead, and then kill the qt UI
[13:57]  * dobey thinks the gtk+ UI was much nicer anyway
[13:57] <xnox> dobey: there was gtk+ UI?! where?
[13:57] <dobey> xnox: there used to be one yes. many releases ago
[13:58] <xnox> dobey: ubuntu-sso-client porting to qt5 is not going to happen, because that needs python3 porting as well, which falls apart in twisted not twisting well under python3.
[13:58] <xnox> dobey: do you at all recall which release? or like a package name or some such?
[14:00] <dobey> xnox: i was wondering about the python3 thing. i saw mark's blog mentioned "finally dropping python2" but i don't see that happening unless we pull software-center out of the default install
[14:01] <xnox> dobey: well.... lenses replace software-center, no?! =)
[14:01] <xnox> dobey: but once ubuntuone stuff at the moment is the biggest python2 chunk on the desktop, which we have to sort out.
[14:01] <dobey> xnox: scopes? sure, when we switch to unity8 and only support click installs :)
[14:02] <dobey> xnox: right, software-center and ubuntu-sso-client is the sticking python2 bit, afaik (not sure if there's anything else using it still)
[14:02] <xnox> dobey: oh right.
[14:02] <xnox> dobey: and we have mvo back, and he can port software-center quickly =) or something-rather.
[14:03] <xnox> dobey: there is myon qt store in kubuntu, we can use that.
[14:03] <xnox> dobey: there is also kylin software-center in qt, which would fit on ubuntu desktop right in.
[14:03] <dobey> muon you mean?
[14:03] <dobey> hmm
[14:04] <dobey> do those both use ubuntu-sso-client? or do they do their own login thing?
[14:05] <cjwatson> pitti: autopkgtest> I see there's a testbed error of some kind on binutils/i386
[14:07] <mvo> xnox: heh :) wasn't the plan to use unity exclusively instead of s-c ?
[14:08] <xnox> mvo: "the plan" is one thing, unicorns is a different thing =)
[14:08] <xnox> dobey: muon uses ubuntu-sso-client, kylin doesn't use anything i believe.
[14:09] <dobey> kylin doesn't support ratings/reviews?
[14:10] <xnox> dobey: hey support alternative archive with packages not from archive.ubuntu.com...
[14:10] <dobey> mvo: come back in two years, we de aren't installing debs any more :)
[14:10] <dobey> wtf i can't type
[14:10] <dobey> s/we de/when we/g
[14:11] <mvo> dobey, xnox: heh :)
[14:12] <xnox> dobey: http://goo.gl/vRCzkk
[14:12] <dobey> xnox: u-s-c supports alternative archives too; that's what PPAs are
[14:12] <xnox> dobey: you haven't seen kylin store yet, have you?! =)
[14:13] <xnox> dobey: i am not quite sure why a new one was written, let me paste you a screenshot.
[14:13] <dobey> no, but i'm also not in china :)
[14:14] <xnox> dobey: http://people.canonical.com/~xnox/kylin-store.png
[14:18] <mvo> xnox: woah
[14:19] <sergiusens> that looks... interesting
[14:19] <dobey> omg
[14:20] <dobey> lol @ dota though
[14:20]  * highvoltage hopes that's even in the archives but is afraid to ask
[14:20] <xnox> highvoltage: furthermore it installs packages not from the archive =)
[14:23] <mvo> it does *what*?
[14:24] <highvoltage> scary.
[14:24] <highvoltage> and weird considering that it's an official flavour?  are they still?
[14:25] <dobey> xnox: where is it installing them from?
[14:25] <mdeslaur> they have their own repo that was approved by the tech board
[14:25] <dobey> oh
[14:25] <dobey> doesn't ubuntu gnome do that as well, with a ppa?
[14:26] <mpt> bdmurray, I suggest using exactly the same colors for “(failed)” as for “(by 12.04 standards)”
[14:26] <pitti> cjwatson: yep, on my radar
[14:26]  * highvoltage frowns at ubuntu kylin and ubuntu gnome
[14:27] <pitti> cjwatson: it timed out, pretty much everything is dog slow today :/
[14:27] <pitti> I'll see how to avoid that
[14:28] <mvo> makes me wonder why their http is listening on port http://archive.ubuntukylin.com:10006 but well :)
[14:28] <ogra_> well, at least it has a roof ... so you wont get wet when it rains
[14:28] <mvo> pfff :P
[14:30] <dobey> anyway, that is too weird.
[14:32] <xnox> highvoltage: see tech-board resolutions, it's installing from a ppa mirror, thus packages are build in a ppa singed by a canonical key, which is stored in launchpad.
[14:32] <xnox> mvo: yeah, 10006 was inquired about....
[14:56] <highvoltage> xnox: yeah but it just doesn't feel right, it's like it goes against the Ubuntu way (if that's even a thing)
[14:56] <highvoltage> xnox: for example, they have non-free software in their main repository: http://archive.ubuntukylin.com:10006/ubuntukylin/pool/main/w/wps-office/
[14:57] <Laney> It's supposed to be analogous to the Canonical partner archive
[14:57] <NikTh> pitti: Hello
[14:58] <highvoltage> Laney: does the system make it even vaguely easy for the users to identify that they're installing non-free software when installing from that archive?
[14:59] <NikTh> pitti: I think you should consider to update the systemd PPA for Utopic Unicorn. What's your thoughts ?
[14:59] <Laney> highvoltage: I can't read the language to tell what that software centre is saying, I'm afraid
[15:00] <mdeslaur> highvoltage: does software-center?
[15:01] <highvoltage> mdeslaur: that's why I very carefully chose the word "vaguely", at least in software-center you have to enable the partner archive manually and you can read up on what it's about
[15:02] <mdeslaur> highvoltage: well, the extras.ubuntu.com repo is enabled by default
[15:02] <mdeslaur> and there's non-free stuff in there
[15:04] <Laney> There sure shouldn't be
[15:05] <highvoltage> mdeslaur: when did exrtas.ubuntu.com start accepting non-free packages?
[15:05] <dobey> i thought extras went away
[15:05] <dobey> oh i guess not
[15:06] <mdeslaur> well, maybe I'm wrong, one sec
[15:07] <dobey> mdeslaur: i'd think if non-free stuff was in extras, the ARB wold be failing at its job, no?
[15:07] <pitti> NikTh: no, I won't -- I'll upload the PPA contents to utopic :)
[15:08] <pitti> NikTh: I tested it quite a bit today with just upstart, and I didn't see any breakage
[15:08] <pitti> NikTh: I'm now also running my workstation with systemd as pid 1, also working quite well; this exposes problems much better (I fixed bluetooth, lxc is broken, etc.)
[15:10] <NikTh> pitti: Yes, you have fixed it I guess. I added the PPA again today and I did not notice the problem. I upgraded to Utopic yesterday and I added your PPA manually ;)
[15:10] <pitti> NikTh: yep, just keep the PPA source as "trusty", it'll work fine on utopic (the only real change is base-files so far..)
[15:10] <mdeslaur> highvoltage, dobey: ah, sorry, the non-free software isn't installed from extras
[15:11] <NikTh> pitti: so , is there a plan for systemd as default system management daemon in 14.10 ?
[15:12] <NikTh> pitti: and how you made that change "as pid 1" ?
[15:12] <pitti> NikTh: yes, https://blueprints.launchpad.net/ubuntu/+spec/core-1403-systemd-transition
[15:12] <pitti> NikTh: as I wrote in the blog, set init=/lib/systemd/systemd in grub
[15:12] <NikTh> pitti: Ok, I have done this already :)
[15:14] <NikTh> pitti:  Now I want to test nvidia drivers , I had a problem on install. Installation should be done in upstart mode. I guess the packaging should be change, because it requires upstart.
[15:14] <dobey> mdeslaur: right. just partner and multiverse, no?
[15:14] <pitti> NikTh: please report such things and tag it with "systemd-boot", so that we have a nice list
[15:14] <pitti> NikTh: i. e. that it appears on https://bugs.launchpad.net/ubuntu/+bugs?field.tag=systemd-boot
[15:15] <pitti> NikTh: but please label the title with [systemd] to make it clear it doesn't affect default ubuntu
[15:15] <NikTh> pitti: OK.
[15:15] <directhex> $ dpkg -c buildroot/pool/main/c/curl/curl-udeb_7.35.0-1ubuntu2_amd64.udeb
[15:15] <directhex> drwxr-xr-x root/root         0 2014-04-01 18:44 ./
[15:15] <directhex> whoops
[15:16] <mdeslaur> dobey: no, software-center installs specials PPAs for the non-free software that's in it
[15:16] <dobey> mdeslaur: oh, you mean for the "for purchase" apps?
[15:16] <mdeslaur> dobey: yeah, or the for purchase $0 apps
[15:16] <dobey> right, yeah, those are all magical private PPAs
[15:17] <dobey> doesn't matter if the app is "free software" or not
[15:17] <mdeslaur> right
[15:38] <slangasek> seb128: what makes you think bug #1311488 is a freetype issue, rather than a driver issue?
[15:39] <infinity> " The problem is intermittent - I just rebooted and there are
[15:39] <infinity> no missing letters."
[15:39] <infinity> ^-- I'd be inclined to blame that on heat.
[15:40] <infinity> Overheating video cards do awesomely confusing things.
[15:42] <infinity> Well, heat or bad driver that corrupts video memory the same fun ways that heat does (the Intel driver has been infamous for this in the past)
[15:43] <pitti> cjwatson: binutils is PASS now, so http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html is now only complaining on the freeze and some unblock request version mismatch
[15:44] <pitti> jibel: hm, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html has "lintian PASS", but it actually failed (on an actual error)
[15:45] <pitti> it's fine to let it propagate in that case, it's certainly not a binutils regression; but formally it should hold it back
[15:45] <infinity> pitti: Yeah, I'd like to sort out why we're getting passes for fails before we just let things go.
[15:46] <infinity> pitti: Pretty please. :P
[15:46] <pitti> hm, and now on reload, lintian is gone altogether
[15:46] <pitti> infinity: yeah, sounds like the same old sorting bug that jibel was working on
[15:46] <infinity> pitti: passes fall off the display after a bit, IIRC.
[15:46] <pitti> infinity: they are not meant to, though
[15:46] <infinity> (Though, not sure why)
[15:47] <infinity> pitti: I've certainly seen that with eglibc in the past, where my list starts out with hundreds and ends up with only a few.
[15:47] <pitti> infinity: right, but it's still not meant to fall off, AFAIK
[15:47] <NikTh> pitti: https://bugs.launchpad.net/ubuntu/+source/nvidia-prime/+bug/1312255 (done) :)
[15:48] <pitti> NikTh: thanks
[15:48] <infinity> pitti: Kay, so.  Blocking opening on this is probably silly, if none of these bugs are regressions, but we really need to make fixing the autopkgtest<->britney interface a top priority.
[15:48] <pitti> infinity: fully agreed
[15:48] <infinity> pitti: Since the whole point of that integration is lost if it doesn't work.
[15:49] <infinity> (see the two doko-induced breakages last cycle that should have been caught)
[15:49] <infinity> Not to pick on doko, he just happened to be the lucky one who tricked adt-britney twice. :P
[15:50] <pitti> it has happened way more often, just with less catastrophic results
[15:50] <infinity> pitti: Indeed, I don't doubt that for a second.
[16:03] <infinity> kirkland: Your vigpg.1 manpage appears to be for wifi-status...
[16:14] <doko> barry, could you point mvo to the way how to install into the system dist-packages using a virtual env?
[16:17] <stokachu> stgraber: ping
[16:17] <stgraber> stokachu: pong
[16:17] <stokachu> stgraber: is it even remotely possible to access /dev/kvm for something like nova-compute running inside an lxc container?
[16:18] <stokachu> nova-compute provides an lxc virt-type but i haven't researched that yet
[16:18] <stgraber> stokachu: have you been talking with zul? :)
[16:18] <stokachu> stgraber: haha yea
[16:18] <stokachu> stgraber: he's helping me with some openstack specifics for a project
[16:18] <stgraber> getting the same question twice in 30s seemed like too much of a coincidence :)
[16:18] <stokachu> haha
[16:18] <stokachu> zul: :)
[16:19] <stgraber> so as I was telling him, so long as the kvm module is loaded on the host, /dev/kvm should be accessible from the container by default
[16:19] <stgraber> I suspect you may have more problems with libvirt than kvm itself
[16:19] <stokachu> so /dev/kvm exists on the host
[16:19] <stgraber> I believe hallyn did get that all to work in the past, unfortunately he's not around this week
[16:19] <stokachu> should i install the virt specfici stuff
[16:19] <stgraber> stokachu: ah, if it doesn't exist in the container, just mknod it
[16:19] <stokachu> ok lemme try that
[16:23] <stokachu> stgraber: ok it added it and i got a little farther
[16:23] <stokachu> back to the charm stuff, thanks
[16:23] <stgraber> np
[16:47] <seb128> slangasek, lack of knowledge of the font rendering stack?
[16:47] <seb128> slangasek, I though that those issues were more likely to be freetype/fontconfig problems
[16:47] <slangasek> seb128: ok, well when glyphs randomly go missing, I've only ever seen that be a video driver problem
[16:47] <seb128> but that was poor guess from my part maybe, so feel free to reassign where you see fit
[16:47] <seb128> k, good to know
[17:10] <infinity> slangasek: driver, or random memory corruption from heat (as I mentioned above).
[17:11] <infinity> slangasek: The user probably just needs to remove the gum from his fan. :P
[17:11] <slangasek> infinity: I'll let tseliot sort that out
[17:55] <barry> infinity: are you SRU'ing a backport of debootstrap into trusty (for the utopic symlink)?
[18:00] <infinity> barry: I hadn't prepped one but, yes, I should do so for all supported releases.
[18:01] <barry> infinity: cool, thanks
[18:01] <infinity> barry: (Though, doing it to lucid is a bit of an unfortunate lie, as you can't debootstrap trusty on lucid right now, so maybe I'll leave that one out)
[18:01] <barry> infinity: i mostly only care about trusty anyway :)
[18:01] <infinity> s/right now/ever/ since debootstrap doesn't look at post-release pockets, so fixing the packages that aren't gzip in trusty base is something we can't do now. :/
[18:02] <infinity> Oh, wait.  Yeah.  lucid is probably already a lie if someone added the trusty link.  My brain wasn't even thinking utopic.
[18:02] <infinity> barry: I'll do utopic symlinks for precise->trusty now.
[18:02] <barry> infinity: rock on
[18:03]  * infinity curses himself for having let the gzip base thing fall off his TODO before release, since it's literally unfixable now.
[18:04] <slangasek> the what?
[18:04] <infinity> slangasek: When dpkg started defaulting to xz, there was a rough concensus that packages in the debootstrap set should be compressed with gzip, which requires manual intervention.  Some were fixed, some were not.
[18:05] <slangasek> hmm
[18:05] <infinity> slangasek: The argument was so that debootstrap on other OSes would be less painful to use, but the other side effect is that lucid can't debootstrap trusty.
[18:05] <slangasek> ah
[18:09] <infinity> slangasek: Anyhow, can't fix it now, without overhauling deboostrap to understand post-release pockets (perhaps a good thing to do anyway, but not something worth backporting to lucid), so just a bit of an "oh darn", I guess.
[18:10] <slangasek> yeah, not seeing the cost/benefit there coming out in our favor
[18:43] <doko> barry, you told me that you were able to install with pip into the system location
[18:45] <barry> doko: that was with system pip in a virtualenv
[18:45] <barry> i.e. if ensurepip's pip wasn't used
[18:47] <doko> barry, so using system pip in a virtualenv lets you install packages into the system location, not into the virtualenv?
[18:47] <barry> doko: right.  that's why we can't use system pip in an venv
[18:47] <barry> we have to use ensurepip's pip
[18:48] <barry> doko: also, https://bugs.launchpad.net/ubuntu/+source/python3.4/+bug/1290847/comments/15
[18:48] <doko> but people *can* do that now, so we should disable that
[18:49] <barry> doko: i think the most reasonable thing is to re-enable ensure pip, so that bundled pip gets installed in the venv.  then people will use that instead of trying to use system pip
[18:50] <barry> if they activate the vm
[18:50] <barry> if they don't, then they're not in a venv ;)
[18:50] <doko> barry, sure, we have to build the wheels for that
[18:50] <barry> doko: read dstufft's comment.  that's not going to work
[18:51] <doko> barry, read the debian policy, including the wheels is not going to work
[18:52] <barry> doko: we had a long discussion about that over in #d-p yesterday.  i'm not so sure it's a clear violation of policy, especially if dstufft gives us a script to rebuild the bundled whls, which he promised to do
[18:53] <barry> doko: specifically, it probably doesn't violate $4.13 of policy
[18:54] <barry> the whls are just zips of the source, and with dstufft's promised script, we can always recreate them if we need to
[18:54] <barry> dstufft makes a compelling argument for why rewheeling + unvendorizing is never going to work
[18:56] <doko> barry, wheels are not data
[18:56] <doko> and we have to remove the windows binaries, so source code included
[18:57] <barry> doko: can we take this over to #d-p and pull dstufft in?
[20:18] <infinity> pitti: Did we get anywhere on adt-britney sadness?
[20:18] <infinity> pitti: Everything now seems to be stuck in RUNNING, which is just as confusing...
[20:43] <zyga> xnox: are debian syncs now open again?
[20:44] <infinity> zyga: autosyncing will happen soonish.
[20:45] <zyga> infinity: thanks
[21:12] <hggdh> bdmurray: hi, you might want to have a look at https://bugs.launchpad.net/bugs/1311895
[21:13] <hggdh> bdmurray: it will only affect people trying to build coreutils from git source on 14.04. Not very usual, but might be bothersome when it happens
[21:58] <infinity> hggdh: Looks like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=730321
[22:00] <hggdh> infinity: indeed, thank you. I wil add the debian bug to the report
[22:01] <infinity> hggdh: http://paste.ubuntu.com/7325581/ <-- This was the Debian fix.
[22:01] <infinity> hggdh: The upstream fix ignores one more, so maybe that's better to pull in.
[22:03] <hggdh> infinity: thanks. I will try to work on it this weekend
[22:04] <infinity> hggdh: I can do it right now, if you want to validate it.
[22:04] <hggdh> infinity: perfect, for that I do have the time :-)
[22:11] <infinity> hggdh: Fix uploaded.
[22:11] <infinity> bdmurray: If you're around, want to review that gettext in the trusty queue so hggdh can go verification-happy?
[22:28] <infinity> hggdh: And uploaded to utopic as well (by way of a merge).
[22:32] <hggdh> infinity: right now installing two trusty VMs, one trusty itself, and one that will go utopic
[22:33] <infinity> arges: *poke*