| === vibhav is now known as Guest42515 | ||
| pitti | Good morning | 02:55 |
|---|---|---|
| === jamesh_ is now known as jamesh | ||
| 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:56 |
| 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 :) | 02:57 |
| 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:04 |
| pitti | infinity: ddebs set up; cron job starts in 30 mins, I'll check ddebs when I start my day for real | 03:11 |
| infinity | pitti: Lovely. I assume autopkgtest will be more effort. | 03:12 |
| pitti | infinity: I'll deal with that with jibel this morning | 03:13 |
| pitti | infinity: utopic retracers set up | 03:18 |
| infinity | pitti: Dude, I just realized what time it is. What sort of crazy person wakes up at 5am? | 03:41 |
| pitti | infinity: heh, you of all people complain about weird working hours? :-) | 03:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| infinity | (And it usually seems to be when I actually needed to be up early...) | 03:46 |
| infinity | Basically, I can't win. :P | 03:46 |
| dholbach | good morning | 06:35 |
| MacSlow | hey dholbach | 06:35 |
| dholbach | hey MacSlow | 06:35 |
| ari-tczew | hello | 06:44 |
| dholbach | hi ari-tczew | 06:55 |
| aleb | How can I become a maintainer of the Launchpad package I'm developing (upstream)? | 07:29 |
| mlankhorst | who's the current maintainer? | 07:38 |
| aleb | "registry" https://launchpad.net/pitivi | 07:41 |
| aleb | I guess nobody | 07:41 |
| jamesh | aleb: ask on #launchpad | 07:42 |
| jamesh | aleb: wgrant or cprov should be able to help | 07:42 |
| 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:24 |
| 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:25 |
| * 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:26 |
| ogra_ | (if they still expect a certain format) | 08:27 |
| pitti | ogra_: what's your /etc/mtab on your desktop? | 08:28 |
| 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:29 |
| 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:30 |
| * 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:31 |
| 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:32 |
| 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_ | :) | 08:33 |
| === mbiebl_ is now known as mbiebl | ||
| jamesh | mardy: could I pick your brain about online accounts again? | 09:35 |
| xnox | ogra_: on the phone most mounting is done by mountall =) like the gazillions of bind mounts. | 09:40 |
| ogra_ | xnox, nope | 09:40 |
| 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:41 |
| 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:42 | |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| pitti | xnox: but I think during the UDS session we said we'd want it for custom upstart jobs written by the admin? | 09:50 |
| 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:51 |
| 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:52 |
| pitti | xnox: I added a link to that to https://blueprints.launchpad.net/ubuntu/+spec/core-1403-systemd-transition | 09:53 |
| pitti | hah! there, bluetooth fixed; it's quite nice, now it only starts up if you actually have a bluetooth adapter | 09:56 |
| ogra_ | pitti, not so sure about that ... how does it know ? | 09:57 |
| 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:58 |
| 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 | 09:59 |
| ogra_ | yes, we run hciattach with the per device options atm ... but that will move into the container | 10:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| ogra_ | (sorry, i'm a little over-cautious ... ) | 10:04 |
| 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:05 |
| pitti | bluetooth-touch-mako.conf just has a few setprop calls | 10:06 |
| ogra_ | yeah, looks at the others :) | 10:08 |
| ogra_ | *look | 10:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| ogra_ | ah, right, that we do | 10:13 |
| ogra_ | (device permissions) | 10:13 |
| 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 :) | 10:14 |
| === MacSlow is now known as MacSlow|lunch | ||
| === alkisg is now known as work_alkisg | ||
| mpt | bdmurray, where are the “failed” colors used? | 12:03 |
| mpt | I don’t know if I’ve ever seen them before. | 12:03 |
| 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:22 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:29 |
| 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 |
| ubottu | bug 1287640 in ubuntuone-credentials (Ubuntu) "UbuntuOne account plugin does not work" [Undecided,New] https://launchpad.net/bugs/1287640 | 12:30 |
| xnox | mardy: or is it the other way around to get gtk plugins to show up in the qml app? | 12:30 |
| === MacSlow|lunch is now known as MacSlow | ||
| 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:31 |
| mardy | xnox: because U1 is using OAuth 1.0 (not 1.0a or 2.0), or a variant of it | 12:32 |
| 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:33 |
| mardy | xnox: your starting point should probably be http://bazaar.launchpad.net/~online-accounts/gnome-control-center-signon/trunk/files/head:/libaccount-plugin/ | 12:34 |
| 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:35 |
| 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:36 | |
| 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:37 |
| 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:39 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| === _salem is now known as salem_ | ||
| 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 | 12:53 |
| 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:00 |
| pitti | cjwatson: jibel sent an RT to publish that to the public jenkins, too | 13:01 |
| cjwatson | pitti: ah, right, thanks | 13:03 |
| pitti | man, everything related to the DC feels like a tarpit today; must be release time :) | 13:05 |
| 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:12 |
| === bfiller_afk is now known as bfiller | ||
| 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:16 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| xnox | ideally canonical-sso would support oauth api for requesting a token. | 13:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| dobey | oauth 2 has lots of benefits | 13:30 |
| dobey | not just easy client code | 13:30 |
| dobey | well, oauth any version is evil; but oauth 2 is slight less evil for what we're doing | 13:31 |
| === arun is now known as arunpyasi | ||
| 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:41 |
| xnox | sergiusens: yeah, i have reference to that. that's canonical-sso specific api to get u1 tokens. | 13:42 |
| xnox | sergiusens: although it returns an oauth 1.0 token, that's not how oauth 1.0 spec mandates to create tokens. | 13:43 |
| sergiusens | xnox: yeah; sso isn't fully oauth compliant; you can talk to nessita or pindonga for details I guess | 13:44 |
| 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:47 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| dobey | xnox: alternatively, we could possibly bring back the gtk+ UI instead, and then kill the qt UI | 13:56 |
| * 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:57 |
| 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? | 13:58 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| dobey | do those both use ubuntu-sso-client? or do they do their own login thing? | 14:04 |
| cjwatson | pitti: autopkgtest> I see there's a testbed error of some kind on binutils/i386 | 14:05 |
| mvo | xnox: heh :) wasn't the plan to use unity exclusively instead of s-c ? | 14:07 |
| 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:08 |
| dobey | kylin doesn't support ratings/reviews? | 14:09 |
| 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:10 |
| mvo | dobey, xnox: heh :) | 14:11 |
| 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:12 |
| 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:13 |
| xnox | dobey: http://people.canonical.com/~xnox/kylin-store.png | 14:14 |
| mvo | xnox: woah | 14:18 |
| sergiusens | that looks... interesting | 14:19 |
| dobey | omg | 14:19 |
| 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:20 |
| mvo | it does *what*? | 14:23 |
| highvoltage | scary. | 14:24 |
| highvoltage | and weird considering that it's an official flavour? are they still? | 14:24 |
| 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:25 |
| 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:26 | |
| pitti | cjwatson: it timed out, pretty much everything is dog slow today :/ | 14:27 |
| pitti | I'll see how to avoid that | 14:27 |
| 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:28 |
| dobey | anyway, that is too weird. | 14:30 |
| 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:32 |
| 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:56 |
| Laney | It's supposed to be analogous to the Canonical partner archive | 14:57 |
| NikTh | pitti: Hello | 14:57 |
| 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:58 |
| 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 | 14:59 |
| mdeslaur | highvoltage: does software-center? | 15:00 |
| 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:01 |
| mdeslaur | highvoltage: well, the extras.ubuntu.com repo is enabled by default | 15:02 |
| mdeslaur | and there's non-free stuff in there | 15:02 |
| Laney | There sure shouldn't be | 15:04 |
| === doko_ is now known as doko | ||
| 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:05 |
| mdeslaur | well, maybe I'm wrong, one sec | 15:06 |
| 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:07 |
| 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:08 |
| 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:10 |
| NikTh | pitti: so , is there a plan for systemd as default system management daemon in 14.10 ? | 15:11 |
| 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:12 |
| 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:14 |
| 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:15 |
| 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:16 |
| dobey | doesn't matter if the app is "free software" or not | 15:17 |
| mdeslaur | right | 15:17 |
| slangasek | seb128: what makes you think bug #1311488 is a freetype issue, rather than a driver issue? | 15:38 |
| ubottu | bug 1311488 in freetype (Ubuntu) "Missing letters " [Undecided,New] https://launchpad.net/bugs/1311488 | 15:38 |
| 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:39 |
| infinity | Overheating video cards do awesomely confusing things. | 15:40 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| ubottu | Launchpad bug 1312255 in nvidia-prime (Ubuntu) "[systemd] nvidia-prime package failed to install due to missing upstart service" [Undecided,New] | 15:47 |
| 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:48 |
| 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:49 |
| 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. | 15:50 |
| infinity | kirkland: Your vigpg.1 manpage appears to be for wifi-status... | 16:03 |
| doko | barry, could you point mvo to the way how to install into the system dist-packages using a virtual env? | 16:14 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:23 |
| === bfiller is now known as bfiller_afk | ||
| 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 | 16:47 |
| infinity | slangasek: driver, or random memory corruption from heat (as I mentioned above). | 17:10 |
| 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:11 |
| === roadmr is now known as roadmr_afk | ||
| === roadmr_afk is now known as roadmr | ||
| === sz0 is now known as sz0` | ||
| === sz0` is now known as sz0 | ||
| barry | infinity: are you SRU'ing a backport of debootstrap into trusty (for the utopic symlink)? | 17:55 |
| infinity | barry: I hadn't prepped one but, yes, I should do so for all supported releases. | 18:00 |
| 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:01 |
| 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:02 |
| * infinity curses himself for having let the gzip base thing fall off his TODO before release, since it's literally unfixable now. | 18:03 | |
| 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:04 |
| 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:05 |
| 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:09 |
| slangasek | yeah, not seeing the cost/benefit there coming out in our favor | 18:10 |
| doko | barry, you told me that you were able to install with pip into the system location | 18:43 |
| barry | doko: that was with system pip in a virtualenv | 18:45 |
| barry | i.e. if ensurepip's pip wasn't used | 18:45 |
| 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:47 |
| barry | doko: also, https://bugs.launchpad.net/ubuntu/+source/python3.4/+bug/1290847/comments/15 | 18:48 |
| ubottu | Launchpad bug 1290847 in python3.4 (Ubuntu) "pyvenv fails due to mising ensurepip module" [Undecided,Confirmed] | 18:48 |
| doko | but people *can* do that now, so we should disable that | 18:48 |
| 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:49 |
| 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:50 |
| doko | barry, read the debian policy, including the wheels is not going to work | 18:51 |
| 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:52 |
| barry | doko: specifically, it probably doesn't violate $4.13 of policy | 18:53 |
| 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:54 |
| doko | barry, wheels are not data | 18:56 |
| doko | and we have to remove the windows binaries, so source code included | 18:56 |
| barry | doko: can we take this over to #d-p and pull dstufft in? | 18:57 |
| === bfiller_afk is now known as bfiller | ||
| === roadmr_ is now known as roadmr | ||
| === elopio_ is now known as elopio | ||
| 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:18 |
| === sz0 is now known as sz0` | ||
| zyga | xnox: are debian syncs now open again? | 20:43 |
| infinity | zyga: autosyncing will happen soonish. | 20:44 |
| zyga | infinity: thanks | 20:45 |
| hggdh | bdmurray: hi, you might want to have a look at https://bugs.launchpad.net/bugs/1311895 | 21:12 |
| ubottu | Launchpad bug 1311895 in gettext (Ubuntu) "0.18.3.1 can fail when tracing due to missing files" [Medium,Triaged] | 21:12 |
| 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:13 |
| === salem_ is now known as _salem | ||
| infinity | hggdh: Looks like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=730321 | 21:58 |
| ubottu | Debian bug 730321 in autopoint "autopoint: bootstrapping coreutils: autopoint from gettext 0.18.3.1 fails" [Important,Fixed] | 21:58 |
| hggdh | infinity: indeed, thank you. I wil add the debian bug to the report | 22:00 |
| 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:01 |
| hggdh | infinity: thanks. I will try to work on it this weekend | 22:03 |
| 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:04 |
| 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:11 |
| infinity | hggdh: And uploaded to utopic as well (by way of a merge). | 22:28 |
| hggdh | infinity: right now installing two trusty VMs, one trusty itself, and one that will go utopic | 22:32 |
| infinity | arges: *poke* | 22:33 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
