=== vibhav is now known as Guest42515 [02:55] Good morning === jamesh_ is now known as jamesh [02:56] apw: hm, I don't remember this at all [02:56] ogra_, apw: yes, systemd pid 1 mounts /proc and /sys, similarly to mountall in the upstart world [02:56] pitti: Hey. You have some tasks with your name on them on NewReleaseCycleProcess [02:57] pitti: retracer, ddebs, autopkgtest... [02:57] 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] infinity: hey [02:57] infinity: yeah, finally :) [03:04] infinity: did we already get any uploads to utopic? i. e. anything to catch up with on ddebs? [03:04] pitti: A few, yeah. [03:04] pitti: https://lists.canonical.com/archives/utopic-changes/2014-April/thread.html [03:11] infinity: ddebs set up; cron job starts in 30 mins, I'll check ddebs when I start my day for real [03:12] pitti: Lovely. I assume autopkgtest will be more effort. [03:13] infinity: I'll deal with that with jibel this morning [03:18] infinity: utopic retracers set up [03:41] pitti: Dude, I just realized what time it is. What sort of crazy person wakes up at 5am? [03:42] infinity: heh, you of all people complain about weird working hours? :-) [03:43] I woke up at 4, couldn't sleep any more, so I thought I could just as well do something useful [03:43] and maybe get tired over it :) [03:43] 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] 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] pitti: I feel your pain. [03:45] pitti: I make it through maybe one night a week, if I'm lucky. [03:45] urgh [03:46] (And it usually seems to be when I actually needed to be up early...) [03:46] Basically, I can't win. :P [06:35] good morning [06:35] hey dholbach [06:35] hey MacSlow [06:44] hello [06:55] hi ari-tczew [07:29] How can I become a maintainer of the Launchpad package I'm developing (upstream)? [07:38] who's the current maintainer? [07:41] "registry" https://launchpad.net/pitivi [07:41] I guess nobody [07:42] aleb: ask on #launchpad [07:42] aleb: wgrant or cprov should be able to help [08:24] 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] ogra_: oh, do we do this now? niiic! [08:25] /etc/mtab -> /proc/mounts [08:25] i wonder if we couldnt just leave it that way instead of having something create a file [08:25] I have it on my desktop, but I have a suspicion that's systemd, not ubuntu standard [08:25] iirc there were reasons to still have it [08:25] I guess to keep track of non-kernel mount options? [08:25] like tools parsing it and expecting a certain fromat that /proc/mounts doesnt give us [08:25] 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] me to [08:26] too [08:26] /etc/mtab has been a horrible horrible misconception [08:26] right, therewas info missing, but we might need to fix some external tools to not regress [08:27] (if they still expect a certain format) [08:28] ogra_: what's your /etc/mtab on your desktop? [08:29] its a file ... i'm on precise [08:29] oh, wow [08:29] i'm pretty sure its a file on trusty too [08:29] (not on the phone weher mountall is largely a no-op (all mounting happens in initrd there) [08:30] ok, so I guess systemd sets that up [08:30] is it a link under systemd? [08:30] yes [08:30] cool [08:31] * pitti tries something [08:31] ok, that works [08:31] uhelper=udisks2 [08:31] i think we can rely on tools to be fixed then [08:31] that's an userspace mount option that udisks uses so that you can call "umount" as user on auto-mounted drives [08:31] and that works [08:32] great [08:32] and that's the bit which is *not* in /proc/mounts [08:32] but "mount" does show it [08:32] so it keeps track of those someplace else now [08:32] hmm [08:32] hah! /run/mount/utab [08:33] SRC=/dev/sdb1 TARGET=/media/martin/PittiUSB ROOT=/ OPTS=uhelper=udisks2 [08:33] so util-linux had this fixed ages ago [08:33] not quite surprising, given how long Fedora etc. have run with /etc/mtab -> /proc/mounts [08:33] heh [08:33] so, user mount options: check [08:33] that was the only reason AFAIK why we still needed that [08:33] :) === mbiebl_ is now known as mbiebl [09:35] mardy: could I pick your brain about online accounts again? [09:40] ogra_: on the phone most mounting is done by mountall =) like the gazillions of bind mounts. [09:40] xnox, nope [09:41] its all done in the initrd [09:41] oh, wait, you are right, the binds are done by mountall [09:41] the actual mounts arent [09:42] pitti: i think we do need newer util-linux, we've been staggering behind for a while now.... [09:42] lamont: infinity: what's the status about getting newer util-linux? [09:42] xnox: we don't need it for this particular issue, but having a non-ancient one would be good nevertheless [09:42] jamesh: hi, sure [09:42] * xnox needs to check the partman/d-i bugs about it. [09:44] 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] 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] pitti: ok. imho everything should partse mountinfo, not mtab / mounts. but i guess loads of things will never learn. [09:44] 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] xnox: we certainly should keep the /etc/mtab symlink around for some time, yes [09:45] pitti: yeap, that should be fine. [09:45] 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] pitti: how is lightdm/plymouth integration with systemd? do i need to steal/port units over? [09:46] xnox: I have lightdm with a systemd unit in my PPA (and soon in utopic); there is no plymouth integration ATM [09:46] i. e. boot is just with a black screen until lightdm starts [09:46] jamesh: but then, if you go to the Online Accounts panel, you should see an exclamation mark next to the soundcloud account [09:46] not that I'd see it for a long time (it's just a second or so) [09:46] jamesh: which means it needs to be authenticated [09:46] jamesh: the reason is that we need to popup a UI in order to authenticate [09:47] xnox: plymouth integration certainly sounds like one of the more/most complicated bits in that transition [09:47] mardy: yes. I log in again in the control panel, rerun my program and get the same result [09:48] 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] jamesh: you might have to clear it from sensitive informations, maybe [09:48] mardy: okay. I'll give that a shot [09:49] 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] 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] xnox: but I think during the UDS session we said we'd want it for custom upstart jobs written by the admin? [09:51] pitti: right, have you seen https://code.launchpad.net/~upstart-devel/upstart/upstart-jobs ? [09:51] pitti: that branch has all upstart jobs, all initd scripts and all unit files present in ubuntu at the moment. [09:52] xnox: heh, no; is that somehow magically updated from all packages from the archive? [09:52] http://bazaar.launchpad.net/~upstart-devel/upstart/upstart-jobs/view/head:/fetch-contents.mk [09:52] nice [09:53] xnox: I added a link to that to https://blueprints.launchpad.net/ubuntu/+spec/core-1403-systemd-transition [09:56] hah! there, bluetooth fixed; it's quite nice, now it only starts up if you actually have a bluetooth adapter [09:57] pitti, not so sure about that ... how does it know ? [09:58] on the phone you might end up that you actually dont see all of the BT device [09:58] ogra_: it doesn't start by default; but there is this rule in /lib/udev/rules.d/99-systemd.rules: [09:58] SUBSYSTEM=="bluetooth", TAG+="systemd", ENV{SYSTEMD_WANTS}+="bluetooth.target" [09:58] ugh [09:58] then it starts bluetooth.target [09:58] * ogra_ hopes that will still work with the hardware being handled inside the container [09:58] ogra_: how can bluez work on the phone if there are no devices? [09:59] we have custom per-device BT upstart jobs atm [09:59] ogra_: in the worst case we put it back on "always start" on the phone [09:59] (thats about to change and the full logic will move into the container, on the ubuntu side only bluetootd should start) [09:59] ogra_: custom jobs? on the phone you mean? because on teh desktop we just always start it [10:00] yes, we run hciattach with the per device options atm ... but that will move into the container [10:01] note that we suppress starting of udev too [10:01] until after the container is up ... [10:01] 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] and as I said, if due to our weird hacks this is broken, we just enable it to always start [10:01] so the events get used by udeventd (android) instead of udev [10:02] ogra_: we don't run an udev coldplug? [10:02] you cant "just always start" BT on a phone [10:02] that might eat your battery ... [10:02] ogra_: well, or transition whichever custom upstart jobs we have (I didn't look at them yet) [10:02] but binding this to "I have BT hardware" sounds like the right thing in general? [10:03] 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] pitti, lxc-android-config has all of the custom jobs in one place [10:03] (well, everything container related at least) [10:04] (sorry, i'm a little over-cautious ... ) [10:05] ogra_: hm, I see a few udev rules which change permissions of BT devices, but no custom jobs? [10:05] ogra_: sure :) well, it's not like we'd dump that on the phone and don't check :) [10:05] oh, for BT they are in bluetooth-touch [10:05] i thought you wanted to see the udev side :) [10:06] bluetooth-touch-mako.conf just has a few setprop calls [10:08] yeah, looks at the others :) [10:08] *look [10:09] 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] really depends what chipset you have all devices with broadcom need to load some blob dynamically using brcm_patchram [10:09] ogra_: I don't actually see any change to bluez startup? [10:09] no, but to the device startup [10:09] yeah, that's fine [10:10] if udev doesnt run at that time ueventd might steal the event [10:10] 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] otherwise a lot more stuff will be broken anyway, so I suspect we already do that [10:11] hmm, i hope that doesnt slow us down ... [10:11] well, we have a lot of udev rules there, including the ones in lxc-android-config [10:11] they won't actually run if we don't coldplug udev :) [10:11] ok :) [10:12] 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] ah, right, that we do [10:13] (device permissions) [10:14] 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] ogra_: so in theeeory, if we write unit counterparts for the bluetooth-touch upstart jobs, it should just work [10:14] in practice, it'll all break horribly initially, of course :) === MacSlow is now known as MacSlow|lunch === alkisg is now known as work_alkisg [12:03] bdmurray, where are the “failed” colors used? [12:03] I don’t know if I’ve ever seen them before. [12:22] 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] xnox, i don't think you should even see that on the desktop [12:24] xnox: you are probably missing the U1 plugin. Let me see how it's called... [12:25] It's greyed out for me [12:25] kenvandine: i want to, though =) [12:25] oh... in uss, not unity-control-center :) [12:25] 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] 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] kenvandine: cause it's a pain to maintain python2-qt4-webkit on the dekstop images [12:26] indeed [12:26] xnox: it should just be account-plugin-ubuntuone [12:27] mardy: not installed. installing. Strange that "u1" was listed in the "add-account view" even though i don't have it =/ [12:27] mardy: now it "just works" even without restarting uss =) [12:27] xnox: yep, for some reason /usr/share/accounts/providers/ubuntuone.provider is provided by ubuntuone-credentials-common instead [12:29] mardy: excellent this works now, thanks. [12:29] Now on to the black magic of getting it to work with ucc [12:29] xnox: yep, I'm afraid you are entering a minefield [12:30] xnox: ucc is Gtk-based, so you'd have to use XEMBED [12:30] haha [12:30] mardy: that was my plan, indeed. [12:30] xnox: which we are also using BTW in other plugins :-) [12:30] mardy: oh really?! like which? [12:30] xnox, mardy: bug #1287640 is the "provider is installed in common which leads to buggy entries" [12:30] bug 1287640 in ubuntuone-credentials (Ubuntu) "UbuntuOne account plugin does not work" [Undecided,New] https://launchpad.net/bugs/1287640 [12:30] mardy: or is it the other way around to get gtk plugins to show up in the qml app? === MacSlow|lunch is now known as MacSlow [12:31] xnox: most of them, except the empathy ones. Basically all those which are authenticated via OAuth (facebook, google, flickr, twitter) [12:31] mardy: cool.... and u1 is not using OAuth because *reasons* [12:32] xnox: because U1 is using OAuth 1.0 (not 1.0a or 2.0), or a variant of it [12:33] 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] 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] xnox: your starting point should probably be http://bazaar.launchpad.net/~online-accounts/gnome-control-center-signon/trunk/files/head:/libaccount-plugin/ [12:35] 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] 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] mardy: and i have managed to complete oauth authentication with 1.0a client against launchpad, simply specify any string as verifier. [12:37] mardy: http://oauth.net/advisories/2009-1/ [12:39] 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] mardy: this mirrors the challenge - to verify that the same client that authorized access, exchanges the request-token. [12:41] xnox: please get in touch with the U1 guys (dobey?), they'll certainly know more [12:41] 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] mjt: suggests is fair game. [12:42] 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] mjt: main is closed set of (build-depends, depends, recommends) [12:43] so basically, one can use Suggests for everything, even for something not in archive? :) [12:43] mjt: it's against debian policy to suggest something that is not in the archive. Or suggest non-free things in main. [12:44] hm. Is it #ubuntu-devel, or #debian-devel? :) [12:44] 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] speaking of non-free things, suggests: is the only way to have, say, firmware [12:45] mjt: surprisingly, debian-policy is still a requirement in the ubuntu, sans were we explicitly diverged / applied changes. [12:45] sure, hence the smile at the end of my statement [12:46] mjt: firmware in ubuntu, can go into multiverse and/or restricted, since it's hardware-dependent blobs. And in ubuntu one can suggest those. === _salem is now known as salem_ [12:53] mardy: looking at account-plugins -> all of them are oauth2.0. is there support for 1.0 at all? [12:53] xnox: flickr and twitter use 1.0a [13:00] 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] cjwatson: jibel and I are working on that furiously :) [13:00] cjwatson: http://d-jenkins.ubuntu-ci:8080/view/Utopic/view/AutoPkgTest/ [13:00] cjwatson: still some fallout, I'm on that [13:00] like missing ddebs indexes for utopic-updates/security (just fixed), and some autopkgtest bugs [13:01] cjwatson: jibel sent an RT to publish that to the public jenkins, too [13:03] pitti: ah, right, thanks [13:05] man, everything related to the DC feels like a tarpit today; must be release time :) [13:12] 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. === bfiller_afk is now known as bfiller [13:16] xnox: launchpad doesn't use standard oauth 1.0 so much [13:16] 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] 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] mpt: here - https://errors.ubuntu.com/retracers-results/ [13:19] 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] dobey: e.g. launchpadlib and all scripts that drive launchpad use it (e.g. syncpackage, requestsync, import-bug-from-debian, etc.) [13:19] dobey: where is sso v1 api docs? [13:20] dobey: and how come sso v2 doesn't provide a normal oauth 1.0 api? [13:20] dobey: or oauth 2.0 api... [13:20] 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] xnox: oauth api is separate from sso api [13:20] xnox: sso just doesn't provide an oauth api at all [13:20] dobey: is oauth api available on sso.... oh *damn* [13:21] dobey: well, i may have a merge proposal against launchpad and python-requests-oauthlib to make it standard compliant ;-) [13:21] xnox: i'm not sure where sso v1 api docs are; it's discouraged to use it [13:22] 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] xnox: the problem with launchpad mostly, is that it doesn't use a consumer key, iirc [13:22] dobey: nah, that works just fine. One specifies any, with no secret. and launchpad just accepts any. [13:23] dobey: do you have that UOA plugin around? i wonna try it against my launchpad dev instance. [13:23] i don't know, i'll have to look [13:26] ideally canonical-sso would support oauth api for requesting a token. [13:27] xnox: no need to convince me. i would ♥ oauth2 support [13:27] dobey: no, no, no =) oauth1 api for requesting tokens ;-) [13:27] dobey: oauth2 is *evil* =) [13:28] no [13:28] oauth1 is evil [13:28] 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] dobey: a whole bunch of authors withdrew their names and association from oauth 2.0.... [13:29] dobey: oauth 2.0 has one benefit - easy client code. [13:30] oauth 2 has lots of benefits [13:30] not just easy client code [13:31] well, oauth any version is evil; but oauth 2 is slight less evil for what we're doing === arun is now known as arunpyasi [13:41] 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] sergiusens: yeah, i have reference to that. that's canonical-sso specific api to get u1 tokens. [13:43] sergiusens: although it returns an oauth 1.0 token, that's not how oauth 1.0 spec mandates to create tokens. [13:44] xnox: yeah; sso isn't fully oauth compliant; you can talk to nessita or pindonga for details I guess [13:47] xnox: it returns a token that is compatible with oauth 1.0; it is not an oauth token :) [13:47] it's an sso token [13:49] and signed requests are oauth compatible [13:49] dobey: the devil is in the details =) fun [13:49] dobey: duck-typing for the win =))) [13:50] 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] xnox: though, what are you trying to do? replace ubuntu-sso-client in 14.10 with the UOA stuff? [13:51] dobey: yeah. [13:52] dobey: at least such that login works, possibly without signup. I could refactor ubiquity's ubuntuone plugin into accounts plugin. [13:52] xnox: maybe fix the UOA gtk+ UI to allow embedding the qml plug-ins, and not require gtk+ ones [13:53] dobey: exploring that as well with xembed type of things. [13:53] dobey: but that is kind of against mir strategy.... or does xembed work under mir? =/ [13:53] xnox: well, afaik the webkit view for the oauth plug-ins is just xembedded [13:53] dobey: correct. [13:54] xnox: are we going to keep having two separate system settings apps when we swtich to mir? [13:54] xnox: or will we just use the ubuntu-system-settings then? [13:54] dobey: no idea... i just want to kill python2-qt4-webkit on the desktop, with least amount of effort possible. [13:55] xnox: port ubuntu-sso-client to qt5? :) [13:55] 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] 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] dobey: there was gtk+ UI?! where? [13:57] xnox: there used to be one yes. many releases ago [13:58] 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] dobey: do you at all recall which release? or like a package name or some such? [14:00] 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] dobey: well.... lenses replace software-center, no?! =) [14:01] dobey: but once ubuntuone stuff at the moment is the biggest python2 chunk on the desktop, which we have to sort out. [14:01] xnox: scopes? sure, when we switch to unity8 and only support click installs :) [14:02] 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] dobey: oh right. [14:02] dobey: and we have mvo back, and he can port software-center quickly =) or something-rather. [14:03] dobey: there is myon qt store in kubuntu, we can use that. [14:03] dobey: there is also kylin software-center in qt, which would fit on ubuntu desktop right in. [14:03] muon you mean? [14:03] hmm [14:04] do those both use ubuntu-sso-client? or do they do their own login thing? [14:05] pitti: autopkgtest> I see there's a testbed error of some kind on binutils/i386 [14:07] xnox: heh :) wasn't the plan to use unity exclusively instead of s-c ? [14:08] mvo: "the plan" is one thing, unicorns is a different thing =) [14:08] dobey: muon uses ubuntu-sso-client, kylin doesn't use anything i believe. [14:09] kylin doesn't support ratings/reviews? [14:10] dobey: hey support alternative archive with packages not from archive.ubuntu.com... [14:10] mvo: come back in two years, we de aren't installing debs any more :) [14:10] wtf i can't type [14:10] s/we de/when we/g [14:11] dobey, xnox: heh :) [14:12] dobey: http://goo.gl/vRCzkk [14:12] xnox: u-s-c supports alternative archives too; that's what PPAs are [14:12] dobey: you haven't seen kylin store yet, have you?! =) [14:13] dobey: i am not quite sure why a new one was written, let me paste you a screenshot. [14:13] no, but i'm also not in china :) [14:14] dobey: http://people.canonical.com/~xnox/kylin-store.png [14:18] xnox: woah [14:19] that looks... interesting [14:19] omg [14:20] lol @ dota though [14:20] * highvoltage hopes that's even in the archives but is afraid to ask [14:20] highvoltage: furthermore it installs packages not from the archive =) [14:23] it does *what*? [14:24] scary. [14:24] and weird considering that it's an official flavour? are they still? [14:25] xnox: where is it installing them from? [14:25] they have their own repo that was approved by the tech board [14:25] oh [14:25] doesn't ubuntu gnome do that as well, with a ppa? [14:26] bdmurray, I suggest using exactly the same colors for “(failed)” as for “(by 12.04 standards)” [14:26] cjwatson: yep, on my radar [14:26] * highvoltage frowns at ubuntu kylin and ubuntu gnome [14:27] cjwatson: it timed out, pretty much everything is dog slow today :/ [14:27] I'll see how to avoid that [14:28] makes me wonder why their http is listening on port http://archive.ubuntukylin.com:10006 but well :) [14:28] well, at least it has a roof ... so you wont get wet when it rains [14:28] pfff :P [14:30] anyway, that is too weird. [14:32] 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] mvo: yeah, 10006 was inquired about.... [14:56] 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] 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] It's supposed to be analogous to the Canonical partner archive [14:57] pitti: Hello [14:58] 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] pitti: I think you should consider to update the systemd PPA for Utopic Unicorn. What's your thoughts ? [14:59] highvoltage: I can't read the language to tell what that software centre is saying, I'm afraid [15:00] highvoltage: does software-center? [15:01] 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] highvoltage: well, the extras.ubuntu.com repo is enabled by default [15:02] and there's non-free stuff in there [15:04] There sure shouldn't be === doko_ is now known as doko [15:05] mdeslaur: when did exrtas.ubuntu.com start accepting non-free packages? [15:05] i thought extras went away [15:05] oh i guess not [15:06] well, maybe I'm wrong, one sec [15:07] mdeslaur: i'd think if non-free stuff was in extras, the ARB wold be failing at its job, no? [15:07] NikTh: no, I won't -- I'll upload the PPA contents to utopic :) [15:08] NikTh: I tested it quite a bit today with just upstart, and I didn't see any breakage [15:08] 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] 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] 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] highvoltage, dobey: ah, sorry, the non-free software isn't installed from extras [15:11] pitti: so , is there a plan for systemd as default system management daemon in 14.10 ? [15:12] pitti: and how you made that change "as pid 1" ? [15:12] NikTh: yes, https://blueprints.launchpad.net/ubuntu/+spec/core-1403-systemd-transition [15:12] NikTh: as I wrote in the blog, set init=/lib/systemd/systemd in grub [15:12] pitti: Ok, I have done this already :) [15:14] 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] mdeslaur: right. just partner and multiverse, no? [15:14] NikTh: please report such things and tag it with "systemd-boot", so that we have a nice list [15:14] NikTh: i. e. that it appears on https://bugs.launchpad.net/ubuntu/+bugs?field.tag=systemd-boot [15:15] NikTh: but please label the title with [systemd] to make it clear it doesn't affect default ubuntu [15:15] pitti: OK. [15:15] $ dpkg -c buildroot/pool/main/c/curl/curl-udeb_7.35.0-1ubuntu2_amd64.udeb [15:15] drwxr-xr-x root/root 0 2014-04-01 18:44 ./ [15:15] whoops [15:16] dobey: no, software-center installs specials PPAs for the non-free software that's in it [15:16] mdeslaur: oh, you mean for the "for purchase" apps? [15:16] dobey: yeah, or the for purchase $0 apps [15:16] right, yeah, those are all magical private PPAs [15:17] doesn't matter if the app is "free software" or not [15:17] right [15:38] seb128: what makes you think bug #1311488 is a freetype issue, rather than a driver issue? [15:38] bug 1311488 in freetype (Ubuntu) "Missing letters " [Undecided,New] https://launchpad.net/bugs/1311488 [15:39] " The problem is intermittent - I just rebooted and there are [15:39] no missing letters." [15:39] ^-- I'd be inclined to blame that on heat. [15:40] Overheating video cards do awesomely confusing things. [15:42] 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] 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] 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] 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] pitti: Yeah, I'd like to sort out why we're getting passes for fails before we just let things go. [15:46] pitti: Pretty please. :P [15:46] hm, and now on reload, lintian is gone altogether [15:46] infinity: yeah, sounds like the same old sorting bug that jibel was working on [15:46] pitti: passes fall off the display after a bit, IIRC. [15:46] infinity: they are not meant to, though [15:46]