[11:58] <cjwatson> vitalylook: multi-catalog CD with both BIOS and UEFI boot blocks.  but it only works on some models of Mac.  Hopefully for 12.10 we'll have something a bit broader.
[21:18] <jamin> I'm hoping that someone here can enlighten me to what I'm doing wrong with the following lvm crypto recipe for use on a Mac: http://paste.ubuntu.com/1143737/.  As I understand it, EFI booting requires a /boot to be FAT, but the referenced recipe results in this partitioning layout: http://paste.ubuntu.com/1143739/.  The SanDisk is the installation media.


[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*


[00:10] <ochosi> Noskcaj: btw, did you refresh the xubuntu-artwork tarball yet?
[00:56] <jjfrv8> bluesabre, are you about?
[01:02] <jjfrv8> bluesabre, I've been testing the new version of menulibre and it's working well except there's still one thing I don't understand
[01:03] <jjfrv8> i.e., what's the correlation between 'hide from menus' in menulibre and 'show' in alacarte?
[01:03] <jjfrv8> for some launchers, there seems to be a direct correlation but not for others
[01:09] <jjfrv8> e.g., under Accessories, I can click Show for Accessibility in alacarte and it will show in whiskermenu...
[01:09] <jjfrv8> then if I click Hide from menus in menulibre, it will disappear from whiskermenu...
[01:10] <jjfrv8> but if I unhide it in menulibre, it does not come back.
[01:11] <jjfrv8> to get it to show again, I have to go back into alacarte. Am I missing something?
[01:46] <bluesabre> jjfrv8: that is bizarre
[01:46] <bluesabre> I notice that it happens with accessibility, but not with gnome-calculator
[01:46] <bluesabre> I wonder if its some issue with items that are also in the settings manager
[01:48] <jjfrv8> hmmm, maybe so. I didn't check to see where the launchers were, I was just trying to get some of the ones that were in the list to show up.
[01:55] <bluesabre> since you were also experimenting with alacarte, does it fare any better?
[01:56] <jjfrv8> as far as showing and hiding things, yes, it seems to.
[01:56] <bluesabre> ok, I might have to look into that
[01:57] <jjfrv8> I just tried Gigolo, which is not in Settings Manager, and it too only seems to work with alacarte
[01:58] <bluesabre> showing and hiding that app seems to work for me
[01:58] <jjfrv8> hmm
[02:00] <bluesabre> I suppose one thing you can try
[02:00] <bluesabre> remove ~/.config/menus/xfce-applications.menu
[02:00] <bluesabre> and then try it again
[02:00] <bluesabre> might be an issue left over from the previous menulibre
[02:01] <jjfrv8> wilco
[02:04] <jjfrv8> no joy. I saw menulibre recreate the file but when I turned Hide from menus off, gigolo still did not show up.
[02:04] <jjfrv8> I had to turn it back on with alacarte
[02:08] <bluesabre> and I assume you're saving after the change?
[02:09] <jjfrv8> yes
[02:09] <bluesabre> ok, I'll take a look at that
[02:09] <bluesabre> maybe I can make some sense of it
[02:09] <bluesabre> or add a hack-tastic fix :)
[02:10] <jjfrv8> :)
[02:48] <Noskcaj_school> ochosi: I refreshed it on saturday. Check the bug to see if there's been changes since my last tarball
[02:48] <Noskcaj_school> Still waiting for sponsors for it
[02:49] <bluesabre> Noskcaj_school: I sent in my request to join PAPT last night
[02:51] <bluesabre> not sure how long that takes to get approved
[02:52] <bluesabre> if you're eager, I released mugshot 0.2.1 over the weekend as well
[02:52] <bluesabre> https://launchpad.net/mugshot/0.2/0.2.1
[02:52] <bluesabre> heh
[03:10] <Noskcaj_school> bluesabre: I'll package it when i get home. Going to the #debian-python channel in OFTC and asking one of the PAPT admins should help you
[06:02] <Noskcaj> mugshot 0.2.1 packaged, the d/watch appears to need work though
[06:05] <Noskcaj> bluesabre, The people you have to ping to get PAPT access: scottk, p1otr, bzed. Some of them are in ubuntu channels too
[12:15] <bluesabre> ochosi, lderan: added a method for light-locker restarting here: https://bazaar.launchpad.net/~light-locker-settings-team/light-locker-settings/trunk/revision/42
[12:15] <bluesabre> if you want to utilize that to make it so you no longer have to restart your session for settings to take place
[12:16] <bluesabre> requirements: python-psutil
[14:44] <brainwash> bluesabre: bug 1165266
[14:44] <brainwash> fix released, correct?
[14:50] <ali1234> that reminds me of something
[14:50] <ali1234> xfce bug 10630
[14:52] <ochosi> lderan, bluesabre (and everyone else i guess): light-locker-settings just got uploaded to the archive!
[14:52] <lderan> \o/
[14:55] <knome> ochosi, thanks for taking care
[14:55] <ochosi> well, i got lucky
[14:56] <ochosi> this could've also taken days
[14:59] <ochosi> brainwash: yup, that fix should be released already
[15:01] <brainwash> I leave it to bluesabre then to close the report :)
[15:04] <ochosi> lazy brainwash
[15:04] <brainwash> ochosi: looks like we can drop these files
[15:04] <brainwash> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/xubuntu-default-settings/trusty/files/head:/etc/skel/
[15:04] <brainwash> or keep them for people who like to switch back to xscreensaver?
[15:04] <ochosi> i'd say keep them for now
[15:04] <ochosi> i don't see a reason to remove them
[15:05] <ochosi> there are ppl who might prefer the locking of xscreensaver
[15:05] <brainwash> we dropped xscreensaver
[15:05] <brainwash> yes, right :)
[15:05] <ochosi> apart from it being butt-ugly, it works fine
[15:05] <brainwash> and it's very light
[15:06] <brainwash> lighter than light-locker :P
[15:06] <ochosi> as is light-locker
[15:06] <ochosi> so what's the diff of the two processes running then?
[15:09] <brainwash> both processes are light I guess
[15:10] <brainwash> but lightdm-gtk-greeter has a bigger footprint
[15:10] <ochosi> well luckily that's not the part that keeps running in the background ;)
[15:11] <koegs> will we be able to drop light-locker and use xscreensaver instead?
[15:11] <brainwash> of course
[15:12] <ochosi> i'll probably write a blog-post for xubuntu.org about the switch
[15:14] <brainwash> ochosi: any idea regarding bug 998649 ? the mythbuntu package conflicts with the xubuntu one starting with 13.04, can we mark it as "won't fix" then?
[15:15] <brainwash> a fix for precise/quantal seems to be very unlikely
[15:16] <ochosi> yup, very
[15:17] <brainwash> ok
[15:18] <brainwash> knome: ^
[15:20] <brainwash> so fix for precise/quantal very unlikely -> mark xubuntu-default-settings as "won't fix"
[15:26] <brainwash> ochosi: did you read bug 1286846 ?
[15:28] <brainwash> I like the idea of moving the search field and action buttons to the top, but making it the default.. not sure about that
[15:29] <brainwash> please comment on this request
[15:35] <koegs> what about changing the order of the buttons?
[15:36] <koegs> if you have the whiskermenu on the right, the order is not ideal
[15:37] <brainwash> ochosi: thanks for commenting
[15:37] <ochosi> koegs: we're only talking the default setup here
[15:38] <ochosi> ppl who can move the menubutton to a different position can also change the settings
[16:27] <brainwash> pleia2, slickymaster: is bug 1255835 still occurring?
[16:32] <slickymasterWork> brainwash: As I'll have to set a new VM box to confirm it, and right now I'm sort of stuck with a prblem ina database at work, I'll have to get back to you on that tomorrow
[16:32] <slickymasterWork> s/prblem ina/problem in a
[16:32] <brainwash> slickymasterWork: but the information dialog is nothing special, or is it?
[16:34] <brainwash> do the (missing) language packages usually get installed during the actual xubuntu installation?
[16:38] <slickymasterWork> brainwash: no, the language packages aren't installed during the xub install
[16:39] <slickymasterWork> brainwash: to what information dialog are you referring?
[16:39] <brainwash> about the incomplete language support
[16:42] <brainwash> bluesabre: seeing that you did the latest changes to xubuntu-meta, could you also please take a look at bug 1279470
[16:42] <slickymasterWork> brainwash: back then I didn't gave it to much importance since not only the install went through successfully but also it allowed to afterwards install the languages packages
[16:43]  * slickymasterWork apologizes for the delay in the responses, but he's with an eye on the channel and the other in a server log
[16:44] <brainwash> slickymasterWork: thanks for answering :) I'm just trying to clean up launchpad
[16:44] <brainwash> so nothing of importance :P
[16:44] <slickymasterWork> brainwash: no problem. And thanks for taking care ;)
[17:41] <pleia2> brainwash: yeah, I think so :( I won't have time to test this week though (not at home)
[17:42] <Unit193> bluesabre: If you look at the bug brainwash linked to, the key is in ship-live.
[17:43] <brainwash> pleia2: no worries! :)
[17:45] <elfy> ochosi: I thought that we were having -messages and -network in the indicator panel, or is today's daily just not up to date
[17:48] <ochosi> elfy: i'm not sure whether micahg merged everything for the seed and uploaded it yet
[17:48] <ochosi> and -network is misleading
[17:48] <elfy> ok - wasn't sure
[17:48] <ochosi> we're not actually using indicator-network
[17:48] <ochosi> we're using nm-applet, which uses indicator-application
[17:49] <elfy> oh - ok
[17:49] <ochosi> which is still buggy (known issues of gtk3 indicators)
[17:49] <ochosi> so it mostly falls back to a trayicon
[17:49] <elfy> mmm - seems to be ok here - if that's what I've actually got :)
[17:50] <Unit193> Downgrading indicator-application worked fine when I did it in VM.
[17:50] <elfy> whatever I've got - is sitting in indicator plugin
[17:53] <ochosi> Unit193: downgrading to what?
[17:54] <Unit193> The saucy one.
[17:54] <ochosi> yeah, that's not really an option
[17:54] <Unit193> For xubuntu?  No.  For elfy? Maybe. :P
[17:54] <brainwash> we are still waiting for the ubuntu guy(s) to fix it =S
[17:55]  * Unit193 is reminded of the "still waiting for" meme...
[17:55]  * elfy has been downgrading elfy for a long time - he's looking to get to the 25 year old version and pin it ...
[17:56] <brainwash> The amount of launchpad bug reports is too damn high!
[18:13] <ali1234> elfy: it works for you because you applied the workaround...................
[18:15] <elfy> ali1234: aah - ok - I'm completely lost with the whole shebang
[18:16] <ali1234> i could be thinking of someone else, but it's the ALLOW_NO_WATCHERS thing
[18:16] <Unit193> #!
[18:18] <elfy> ali1234: I'd assume so - now I remember it
[18:59] <ali1234> ochosi: bodhi switched to lightdm with gtk-greeter :)
[18:59] <ochosi> ali1234: oh nice :)
[18:59] <ali1234> http://jeffhoogland.blogspot.co.uk/2014/03/bodhi-linux-300-alpha-release.html
[19:02] <ochosi> they're also using greybird it seems
[19:02] <ali1234> yes
[19:02] <ochosi> and it looks like they're missing a session-badge
[19:03] <ali1234> for the login screen - they use e for the desktop
[19:03] <ochosi> for whatever session they're running (i guess e17)
[19:04] <ochosi> yeah, but for gtk apps they still seem to be using greybird: http://www.enlightenment.org/ss/e-53125f5c5e1919.84283754.jpg
[19:05] <elfy> ochosi: do you have any idea why the mail reader in whiskermenu is a different size?
[19:05] <ali1234> the icon?
[19:05] <elfy> yea - helps if I write whole sentences ...
[19:05] <ali1234> also http://www.reddit.com/r/xfce/comments/1zfvve/giant_icons/
[19:06] <ochosi> elfy: depending on what icon-size you're using that size might be missing from elementary-xfce
[19:06] <elfy> livesession
[19:07] <ochosi> well, i have no idea what the default setting is right now
[19:07] <ochosi> you can show me a screenshot, then i can tell you
[19:07] <ochosi> the size we'll be using in xubuntu is "smaller"
[19:07] <ochosi> (aka 24px)
[19:08] <elfy> http://imagebin.org/297220
[19:10] <ochosi> as soon as xubuntu-artwork has been uploaded, this will be fixed
[19:11] <elfy> cool - I shall pass that on :)
[19:11] <elfy> thanks ochosi
[19:11] <ochosi> no problem
[19:12] <ochosi> and feel free to set whiskermenu to use the "smaller" appicons
[19:12] <ochosi> in the properties
[19:12] <ochosi> as that'll be our default
[19:12] <elfy> was pqwoerituytrueiwoq on the forum asking that
[19:13] <elfy> my default is smaller already for the menu here
[19:13] <ochosi> ok
[19:13] <ochosi> that guy should probably hang out on irc more
[19:13] <ochosi> he submits many bugreports
[19:13] <ochosi> most of them valid and useful
[19:14] <ochosi> feel free to encourage him
[19:14] <elfy> yep
[19:14] <elfy> I do - I mentioned the meeting Thursday there - as he was also asking about Software Centre being a default
[19:15] <Unit193> "being a default"?
[19:15] <elfy> in the list you see
[19:17] <Unit193> [13:12:26] queuebot:#ubuntu-release: New: accepted light-locker-settings [i386] (trusty-proposed) [1.0.0-0ubuntu1]
[19:17] <elfy> is that going to be in the seed - I assume it is
[19:17] <Unit193> (Yes, I read the words above that.)
[19:18] <elfy> the now known as words?
[19:18] <ochosi> Unit193: yup, i know
[19:18] <ochosi> Unit193: 15:52  ochosi$ lderan, bluesabre (and everyone else i guess): light-locker-settings just got uploaded to the archive!
[19:19] <Unit193> ochosi: Heh, knew you knew, backlog there says as much.  Didn't happen to see that here.
[19:20] <ochosi> :)
[19:20] <ochosi> but yeah, i'm happy it landed finally
[19:21] <elfy> I'd not read the backlog - but I did then
[22:07] <Unit193> Sooo, I'm going to call the upgrade a fail, fglrx doesn't work.
[23:40] <ochosi> Unit193: having xorg problems?
[23:42] <Unit193> Terrible res, bit fuzzy, and lag as if I was running mir.  Somehow I got fglrx to work, not really sure how... (Had reinstalled, swapped it out for -updates, and many others which all left me with a black screen, removing would get me the terrible display.)
[23:42] <ochosi> and radeon doesnt work for you?
[23:44] <Unit193> That was the first bit, terrible.
[23:44] <Unit193> But, fglrx is fixed somehow.
[23:44] <bluesabre> brainwash: re https://launchpad.net/bugs/1279470, need an answer to gilir's question first... and...
[23:45] <bluesabre> *buntu-meta are auto-generated from the current seed, so also dependant on that
[23:54] <Unit193> bluesabre: See my ping?
[23:56] <bluesabre> Unit193: yes, but that didn't make it clear as to what needs to be added to ship-live, unless I should actually look at ones that do work...
[23:59] <Unit193> bluesabre: * shim-signed [amd64]  and   * grub-efi-amd64-signed [amd64]


[00:28] <neurre> base system 64%
[00:28] <neurre> been forever
[00:28] <neurre> Configurring ca-certificates...
[00:56] <neurre> doh
[00:56] <neurre> still 62%
[01:37] <neurre> tada
[01:38] <neurre> yeah it took a while
[04:48] <royu> Hi all
[04:49] <royu> Can somebody tell me, please, is there some significant difference between ARM and ARMEL ?
[09:22] <lool> amitk: You might have to enable stuff in fconfig to have networking available
[09:24] <amitk> lool: ok
[12:22] <neure> suihkulokki, ping
[12:50] <ogra> https://lists.ubuntu.com/archives/ubuntu-users/2009-July/191184.html
[12:50] <ogra> nice
[12:54] <neure> uh
[12:54] <neure> i feel like i want some arm box myself
[12:55] <ogra> dont ge ARM11 though :)
[12:55] <ogra> *get
[12:56] <neure> what should i get?
[12:56] <neure> whats the matter with arm11?
[12:56] <ogra> beagleboard should be good for a start
[12:56] <ogra> we will only support ARMv6/v7 in the future arm11 is ARMv5
[12:57] <neure> oh
[12:57] <neure> hmm
[12:57] <neure> i thought qemu was only ARMv5 though?
[12:58] <ogra> no, it can support cortex-a8 (ARMv7) its just that there is no kernel for it
[12:58] <ogra> there is a hack for beagleboard support, google for it :)
[12:58] <ogra> and there is https://lists.ubuntu.com/archives/ubuntu-mobile/2009-May/002485.html
[13:02] <neure> i wonder if someone has prebuilt qemu, realview rfs also
[13:02] <neure> kernel is pointed there..
[13:21] <neure> erm
[13:21] <neure> i trid rootfilesystemfrom scracth
[13:21] <neure> well it didn't give me network in qemu :/
[13:21] <ogra> during build ?
[13:21] <neure> after build
[13:21] <ogra> or do you mean the resultin image
[13:21] <neure> resulting image
[13:22] <ogra> well, you need to configure it in the image
[13:22] <neure> how?
[13:22] <neure> sudo ifconfig only shows lo
[13:22] <ogra>  /etc/netwrok/interfaces
[13:22] <ogra> ah, well, manually do the following:
[13:22] <ogra> sudo ifconfig eth0 up
[13:23] <ogra> sudo dhclient eth0
[13:24] <ogra> if you configure it in /etc/netwrok/interfaces it will come up automatically on boot
[13:25] <neure> ah
[13:25] <neure> thanks
[13:25] <neure> that helped
[13:25] <neure> my linux skills are rusty
[13:25] <neure> i tried sudo ifup eth0
[13:25] <neure> it complained something funny :D
[13:25] <ogra> ifup looks in /etc/network/interfaces for an entry ;)
[13:26] <neure> heh
[13:27] <neure> what does eth0 line there look like?
[13:28] <neure> googled
[13:30] <neure> openssh-server package is a bit funny
[13:30] <neure> i dont understand why it needs all that libx* stuff
[13:30] <neure> oh way, for X11 forwarding_
[13:30] <ogra> right
[13:33] <neure> maybe i should have used dropbear instead
[13:55] <neure> hmm
[13:55] <neure> i dont seem to be able to ssh to the qemu server though
[13:55] <neure> i installed openssh-server
[13:55] <neure> according to ifconfig the qemu is <IP_ADDRESS>
[13:56] <neure> but i can not connect to that from host
[13:56] <ogra> yes, but thats internal
[13:56] <neure> internal to.. qemu_
[13:56] <neure> ?
[13:56] <ogra> someone added a reciepe for setting up network forwarding to the wikipage
[13:57] <neure> where is the wikipage?)
[13:58] <ogra>  /topic :)
[13:59] <neure> cant see :(
[14:00] <neure> i mean anything about network
[14:00] <neure> sorry
[14:00] <neure> i was looking at the wrong page :D
[14:04] <neure> erm
[14:04] <neure> that bridge thing didnt quite work
[14:04] <neure> sudo ifup br0
[14:04] <neure> add bridge failed: Package not installed
[14:04] <neure> and more
[14:05] <lool> Install bridge-tools
[14:05] <lool> Sorry bridge-utils
[14:05] <neure> ugh
[14:05] <neure> i misread the instructions
[14:05] <ogra> and please correct the wiki if thats not mentioned there
[14:05] <neure> i was doing the host stuff inside qemu :D
[14:05] <neure> my host is windows..
[14:06] <ogra> tricky
[14:07]  * ogra wonders if his rootstock test with cortex-a8 just hangs or is simply slow
[14:08] <ogra> i probably shouldnt hide kernel messages
[14:08] <neure> probably not :D
[14:08] <ogra> oh ! it moved
[14:09] <neure> wtf
[14:10] <neure> i right client on bat file to edit the script to lauch qemu and windows claims that "Open File - Security Warning. The publisher could not be verified.  Name: ubuntu_run.bat ..."
[14:11] <neure> ah that was because i edited the file on network drive :D
[14:11] <neure> wrong one
[14:14] <rjune_wrk> !o
[14:14] <ubot4> Factoid 'o' not found
[14:15] <rjune_wrk> oh yeah, wrong room
[14:15] <rjune_wrk> ogra!
[14:15] <ogra> heh
[14:15] <rjune_wrk> HOw goes it?
[14:19] <ogra> busy working on rootstock
[14:22] <neure> oh well
[14:22] <neure> i can use -redir to get ssh connection to host
[14:23] <neure> hmm
[14:23] <neure> is it normal to get packages cannot be authenticated error?
[14:23] <neure> gdb causes at least
[14:24]  * ogra grins ... i just googled for project rootstock ... second hit after the LP page: "PROJECT: Rootstock Effects on Mango Productivity"
[14:24] <ogra> neure, sudo apt-get update
[14:25] <ogra> your packagelist in the image is likely outdated
[14:25] <neure> funny i thought i already did apt-get update
[14:26] <neure> oh dear
[14:26] <neure> i installed ubuntu arm
[14:26] <neure> in qemu
[14:26] <neure> i tried netinstall and rootfsfromscratch
[14:26] <ogra> call it rootstock :) less typing :)
[14:27] <neure> does it have a new name?)
[14:27] <ogra> (and the new name for it)
[14:27] <neure> :D
[14:27] <neure> well the thing is.. qemu doesnt multithread very well :/
[14:28] <neure> same issue with all linux i've tried so far.. if i create a new thread which busyloops like for(;;), pthread_create / clone never returns :(
[14:28] <neure> in fact, the system hangs
[14:28] <neure> on some setups, i can break the offending program, but on this ubuntu, i cant do anything
[14:29] <ogra> well i think lool tried it yesterday and it worked on HW
[14:29] <neure> yeah
[14:29] <neure> so i think its some funny thing with QEMU
[14:30] <neure> which is bad, because i need to get it work in QEMU
[14:30] <neure> :(
[14:30] <ogra> well, it might even work in qemu if its not running under windows
[14:30] <ogra> who knows
[14:30] <neure> i've tried that too
[14:30] <ogra> ah, so you know :)
[14:30] <neure> didn't work any better in linux :/
[14:31] <neure> well i tried in in VMWare which was running on top of windows..
[14:31] <neure> and i only used qemu-system-arm
[14:32] <suihkulokki> neure: which compiler are you using to test your threading testcase?
[14:32] <neure> gcc
[14:32] <neure> my qemu just hang so i cant check the version
[14:32] <neure> 4.3 i think
[14:32] <neure> suihkulokki, i'd really like to know which kernel and rfs you are using
[14:32] <suihkulokki> a gcc from the same distro?
[14:33] <neure> yes
[14:33] <suihkulokki> that was just debian lenny armel
[14:33] <neure> i tried with debian lenny arm
[14:33] <neure> i tried with debian lenny armel
[14:33] <neure> i tried with ubuntu armel
[14:33] <neure> with their own kernels and packages
[14:34] <neure> and they all behave more or less the same
[14:34] <neure> on lenny i was able to break the offending thread
[14:34] <neure> and if i run with gdb, it worked
[14:34] <neure> on ubuntu i only did first try with gdb
[14:34] <neure> i wasnt able to break
[14:35] <neure> i also tried in windows qemu, and linux qemu (althought that linux run inside vmware on top of windows)
[14:36] <neure> and i have absolutely no clue what is causing this :(
[14:42] <neure> and i'm running out of things to try :/
[17:07] <Sarvatt_> is there a specific platform the arm port is designed around right now or is it targetting hardware that isnt out yet? wondering what options I have right now besides a beagleboard.. I'm guessing sheeva wont be supported much longer in karmic when things move up to armv6+?
[17:11] <neure> Sarvatt, the targets are listed on the qemu page
[17:11] <neure> oh
[17:11] <neure> sorry
[17:11] <neure> this is ubuntu :)
[17:11] <neure> wrong #
[17:20] <ogra> Sarvatt, btw, rootstock is fixed, that your image ended up in /tmp was a bug
[17:21] <Sarvatt> ohh thank you ogra
[17:23] <lool> mcasadevall, ogra: So on these lzma slowness thing
[17:23]  * ogra is just working on cortex-a8 support for the karmic version :)
[17:23] <lool> mcasadevall, ogra: Did we benchmark it/profile it?
[17:23] <ogra> lool, i thought mcasadevall did
[17:23] <lool> It might be that there's a bug in lzma simply; unaligned access or something
[17:24] <mcasadevall> lool, it works (slowly) on my Babbage boards
[17:24] <Sarvatt> heres my log if it helps anything http://sarvatt.com/downloads/rootstock-200907121533.log.txt
[17:24] <mcasadevall> lool, and I fed a few test files through lzma -9 on rimu, no issue
[17:24] <mcasadevall> expect speed
[17:24] <lool> mcasadevall: I had in mind that perhaps lack of VFP or unaligned accesses could slow it down
[17:24] <mcasadevall> lool, VFP didn't make a difference
[17:24] <ogra> lool, in any case if the majority of packages makes actual use of the 10h timeout thats not feasable
[17:24] <lool> mcasadevall: You rebuilt it with softfp?
[17:24] <mcasadevall> lool, yeah
[17:25] <mcasadevall> lool, there are no floats in the code
[17:25] <lool> mcasadevall: Do you think it could be unaligned access?
[17:25] <mcasadevall> lool, the buildds are set to mode 0: do nothing
[17:25] <mcasadevall> unaligned access would cause a sigill
[17:25] <lool> mcasadevall: Perhaps you could oprofile it?  or gprof, dunno what exposes the issue best
[17:25] <lool> mcasadevall: Well that depends on the system setup AFAIK
[17:25] <lool> Also v7 handles unaligned accesses
[17:25] <mcasadevall> lool, the buildds are v5
[17:25] <ogra> Sarvatt, oh, thats a different issue but its fixed since some days ... the reboot command was missing because new upstart didnt build
[17:26] <mcasadevall> and rimu is setup the same way as the buildds
[17:26] <lool> mcasadevall: Oh really?  I didn't know that  :)
[17:26] <ogra> heh
[17:26] <mcasadevall> lool, :-)
[17:26] <lool> I wouldn't have imaginated we're running v5 buildds really  :)
[17:26] <mcasadevall> Ok, stupid point
[17:26]  * mcasadevall dons the dunce cap
[17:26] <mcasadevall> :-P
[17:27] <mcasadevall> lool, on my tests, compressing a 13MB tar file takes 48 seconds with lzma -9
[17:27] <mcasadevall> But that doesn't max out the RAM
[17:27] <mcasadevall> you run into problems when compressing with lzma on 512MB
[17:27] <lool> Ah
[17:27] <ogra> yay
[17:27] <mcasadevall> lool, then the system starts paging out
[17:27] <Sarvatt> can you change the compression level on an arch specific basis for dpkg-builddeb globally?
[17:27] <lool> Perhaps we can configure lzma in a less expensive mode where it uses less memory?
[17:27] <mcasadevall> lool, you can guess what happens next
[17:27]  * ogra has a cortex-a8 build with all features we need for qemu
[17:28] <mcasadevall> lool, that was is a possibility
[17:28] <suihkulokki> lol, lzma -9
[17:28] <mcasadevall> lool, I'm not in love w/ it though. lzma in almost any mode is going to guzzle down memory faster than anything else
[17:28] <lool> mcasadevall: Could you check how much that helps and if yes how to make that the default on armel?
[17:28] <lool> suihkulokki: It's to run KDE anyway    :-P
[17:28]  * mcasadevall has run KDE on ARM
[17:28] <mcasadevall> :-)
[17:28] <Sarvatt> even just -7 would be half the memory required or less
[17:28] <lool> Sarvatt: I think that's what we'd want to look into, yes
[17:29] <lool> (re: compression level in dpkg-bd)
[17:29] <ogra> hmm, i thought i saw an rtc patch in lool's patchset ... weird
[17:29]  * mcasadevall grabs dpkg's source
[17:30] <lool> I don't see any flag passed to lzma by dpkg-dev stuff though
[17:30] <suihkulokki> lzma -9 gives, what, 1% size reduction over lzma -5ish and takes twice as long and multiple times the ram
[17:30]  * mcasadevall is looking now at the dpkg-deb code
[17:30] <lool> ogra: Just enabling the RTC kernel CONFIG_ I guess?
[17:31] <ogra> lool, yeah
[17:31] <ogra> but it doesnt seem to work, it moans on shutdown
[17:31] <ogra> but ...
[17:31] <ogra> cat /proc/cpuinfo |grep Processor
[17:31] <ogra> Processor	: ARMv7 Processor rev 0 (v7l)
[17:31] <ogra> :D
[17:31]  * ogra hugs qemu
[17:32]  * neure curses qemu
[17:32] <ogra> inotify and tcp.syncookies added
[17:32] <ogra> as well as sysfs deprecated dropped
[17:32] <neure> apparently it messes up guest scheduling when run in windows :(
[17:32] <neure> due to crappy timers
[17:32] <lool> The default compression in lzma is 7
[17:33] <mcasadevall> lool, and that's what we use
[17:33] <mcasadevall> we don't pass -9 on lzma
[17:33]  * mcasadevall just checked the source
[17:33] <lool> mcasadevall: I just said that earlier
[17:33] <mcasadevall> oh
[17:33] <lool> mcasadevall: Could you see what lzma level is acceptable on 512m of RAM?
[17:34] <mcasadevall> TBH, I would consider not using lzma at all on that little RAM
[17:34] <ogra> -0 :)
[17:34] <lool> mcasadevall: Well I find it a bit ugly to patch a bunch of patches not to use lzma, or to patch dpkg-dev to map lzma to something else
[17:35] <lool> While I find it decent to set the default lzma level in dpkg-dev or in lzma itself to something reasonnable depending on the arch
[17:35] <lool> s/a bunch of patches/a bunch of packages
[17:36] <mcasadevall> lool, well, changing the code in dpkg to remap lzma to bz2 looks simple enough. Its a case switch that needs to be conditionally overridden
[17:36] <mcasadevall> I'll see on RAM usage
[17:36] <suihkulokki> forget bz2
[17:36] <mcasadevall> suihkulokki, ?
[17:36] <lool> mcasadevall: I find it ugly really
[17:37] <lool> dh_foo --I-want-lzma => you get something else; that's a nono
[17:37] <lool> --I-want-lzma-but-I-dont-care-which-compression-pick-it-for-me sounds nicer
[17:38] <suihkulokki> mcasadevall: among other things, it's slower to decompress than lzma
[17:38] <mcasadevall> suihkulokki, its not to bad on +1Ghz boards
[17:38] <mcasadevall> suihkulokki, and decompression isn't quite so RAM hungry
[17:38] <suihkulokki> ...
[17:39] <mcasadevall> lool, well, the other idea I had, depending on how crazy I am, is we could write a distlzma-like program and offload the compression :-)
[17:39] <mcasadevall> (probably not something we want to do, but worth throwing the idea around before its shot down)
[17:40] <lool> mcasadevall: Situation at hand: packages FTBFS due to a timeout; we don't care about the packages being compressed (we don't use -dbg)
[17:40] <mcasadevall> lool, I get the point
[17:40] <suihkulokki> mcasadevall: did you read the benchmark link I gave you yesterday?
[17:40] <lool> So I think a light touch and simple change is a better choice than inventing a new tool, integrating it etc.
[17:41] <mcasadevall> suihkulokki, I did, but it didn't give a great overview of RAM usage per notch
[17:41]  * lool loads http://tukaani.org/lzma/benchmarks
[17:41] <mcasadevall> er
[17:41] <mcasadevall> wait
[17:41] <mcasadevall> sorry
[17:41] <mcasadevall> Wrong benchmark
[17:41]  * mcasadevall had a bunch of google links open to this
[17:43] <lool> suihkulokki: The page underlines the relatively low gain in compression ratio of using higher lzma modes but the high cost in memory
[17:43] <lool> So I think it kind of speaks for changing the default mode of lzma or the default lzma mode which dpkg-dev uses
[17:43] <lool> suihkulokki: Don't you have issues building KDE packages in Debian as a result of this?
[17:44] <suihkulokki> lool: I don't think we've gone lzma
[17:45] <mcasadevall> the lzma change is only because we can't fit KDE4 on the CD anymore
[17:45] <mcasadevall> *sigh*
[17:45] <lool> mcasadevall: So it's 100% Ubuntu specific?
[17:45] <mcasadevall> lool, at the moment, I'm not sure if pkg-kde plans to adapt it or not
[17:46] <lool> I find it ugly, but it's the KDE folks' decision
[17:46] <lool> mcasadevall: So are we in agreement over the proposed changes?
[17:46] <ogra> lool, mesa seems to use lzma for dbgsym or dbg packages
[17:46]  * ogra isnt sure which
[17:46] <lool> ogra: -dbg
[17:46] <ogra> right it was one of the two
[17:47] <mcasadevall> ogra, I think they simply set the dpkg-deb line to build all of them as lzma, and the -dbg just gets compressed. I'm not even sure if you can set per-packaging compression options with the standard rules foo
[17:47] <suihkulokki> even lzma -2/-3 beat bzip2 -9 ratios and doesn't really use much more ram (and compressess faster)
[17:47] <mcasadevall> lool, just a matter of determing which -X option we want
[17:47] <ogra> i think thats the only other package with probs currently on the ftbfs list
[17:47] <ogra> (which doesnt mean there arent others)
[17:47] <lool> mcasadevall: So you agree we should just change the default compression ratio on armel somewhere?
[17:47] <ogra> mcasadevall, but other packages arent that huge
[17:48] <mcasadevall> ogra, when you fighting for every kilobyte on the CD, it makes the difference
[17:48] <suihkulokki> ofcourse, to be systematic, one would measure the different levels directly with the problematic -dbg package and pick a level that gives the best compression ratio/ram usage ratio
[17:48] <mcasadevall> lool, best cost/effort ratio I can see
[17:48] <mcasadevall> lool, we're not as concerned with the image size as everyone else since ARM is .img and not iso
[17:48] <lool> mcasadevall: Could you bring this up either with dpkg or lzma upstream or both and see what they think of it?
[17:49] <lool> About -dbg: sorry folks, I have been misleading: builds timeout when packing these because cdbs packs packages separately, but it's an option which is used on all .debs built by a source which is why it gives space savings on the CD and why it makes the build globally longer
[17:50] <lool> It's not an option passed only to -dbg as I might have implied
[17:50] <mcasadevall> lool, er, I can understand lzma upstream, but why dpkg upstream? This is a very ubuntu-specific change we're considering
[17:51] <lool> mcasadevall: Don't you think dh_builddeb -Zlzma would behave equally as bad under Debian?
[17:51] <Sarvatt> mesa built fine on 06-30 in 3 hours and failed to build even after 10 hours starting 07-07.. dpkg was updated between the two to 0.15.2 and they switched dpkg-builddeb to add format=gnu and drop all TAR_OPTIONS, was it using format=posix by default on arm before? thats really a long shot but it seems to me like the lzma problems started after a certain date
[17:51] <mcasadevall> suihkulokki, unless you think such a change it worthwhile for debian-armel?
[17:52] <mcasadevall> Sarvatt, I didn't look at mesa in depth. I saw the problem crop up w/ KDE packages at first
[17:53] <lool> Sarvatt: It didn't build on 06-30?! https://launchpad.net/ubuntu/+source/mesa/7.5~rc4-1ubuntu1/+build/1100008
[17:53]  * mcasadevall needs to rule something out
[17:53] <Sarvatt> that was a debian/rules error tjaalton did
[17:53] <Sarvatt> 1ubuntu2 built fine
[17:54] <lool> Sarvatt: Indeed it built with lzma recently
[17:54] <mcasadevall> O_o;
[17:54] <mcasadevall> That's strange to say the least
[17:54] <mcasadevall> the lzma package itself hasn't been touched since intrepid
[17:54] <mcasadevall> I ruled that out
[17:54] <lool> The TAR_OPTIONS removal was at my request because some users had -z exported in TAR_OPTIONS and were createing source packages with this set
[17:54] <Sarvatt> the only change between 1ubuntu2 and 1ubuntu3 was a patch added that only touches the intel driver in mesa that doesnt even get built on arm
[17:56] <lool> mcasadevall: Could you try downgrading dpkg-dev and see whether you get a faster lzma again?
[17:56] <lool> I'm confused about the change in speed too
[17:56] <mcasadevall> lool, I can't reproduce locally
[17:56] <mcasadevall> lool, I setup launchpad-buildd on a Babbage board with latest chroots when this issue popped up
[17:56] <mcasadevall> The package build successfully after many hours, and the recent change in KDE was lzma compression
[17:57] <lool> mcasadevall: Check with mesa
[17:57] <lool> mcasadevall: You have a reference speed of 3 hours in earlier versions
[17:57] <mcasadevall> lool, I haven't reproduced that build failure yet though
[17:57] <mcasadevall> Alright
[17:57] <mcasadevall> let me start that now
[17:58] <lool> Which bumps to more than 14 afterwards
[17:58] <lool> Sarvatt: Good catch, thanks!
[17:58] <Sarvatt> definitely looks like something in the environment that changed in that case to me
[17:59] <mcasadevall> lool, my hardware it slower than the buildds, but if it hangs in the same place after ~5 or so hours, I think we can call it reproduced
[17:59] <mcasadevall> If not, I think we have a bigger problem
[17:59]  * ogra enables preempt for fun on his test kernel
[18:04] <mcasadevall> meh
[18:04] <mcasadevall> uboot fat reading is very slow
[18:04] <ogra> dont use fat :)
[18:04] <ogra> use ext2
[18:04] <mcasadevall> how?
[18:04] <ogra> no idea
[18:04] <ogra> you got the hardware, i dont :)
[18:05] <mcasadevall> oh bah
[18:05] <mcasadevall> I gave the wrong offset
[18:05] <mcasadevall> you need physical addresses in u-boot or BAD THINGS(tm) happen
[18:05] <ogra> hmm, preempt seems to speed it up
[18:06]  * ogra wonders what the drawback is
[18:08] <ogra> lool, did you try to enable smp when you played with the v7 kernel ?
[18:08]  * ogra wonders if that would be worth a try
[18:15] <Sarvatt> i should have just bought a beagleboard a year ago, been holding off because its been sounding like theres going to be better released any time now since november but still cant find anything.. sheevaplug is looking alot better but i'm sure karmic will switch to armv6+ as soon as it gets here :D
[18:16] <Sarvatt> i thought jaunty was going to be armv7 from the start going by the press releases
[18:18] <ogra> we tried to keep jaunty close to debian
[18:18] <ogra> since it was our first release and v7 hardware is rare
[18:18] <ogra> at least the v7 HW we support
[18:20]  * mcasadevall would love to know why u-boot takes 30 seconds to load a kernel image
[18:21] <Sarvatt> my efika is begging to be upgraded with something arm :)
[18:24] <ogra> hrm
[18:24] <ogra> why does /etc/init.d/sendsigs not finish
[18:46] <dirk2> I used ARM/RootfsFromScratch from https://wiki.ubuntu.com/ARM to create a rootfs. If I understood correctly, this takes the pre-build binary packages and creates the rootfs from it. Now I wonder how are the armel binary packages created from source? That is, how is Uuntu ARM cross compilation done?
[18:46] <ogra> not at all :)
[18:47] <ogra> the packages are all build natively
[18:47] <dirk2> orga: Native compile?
[18:47] <ogra> https://launchpad.net/builders
[18:47] <ogra> there are three armel build machines at the bottom
[18:48] <dirk2> ah, I see. Any info what hardware is behind this?
[18:48] <ogra> some 800MHz 512M boards
[18:49] <ogra> i dont know the exact SoC names
[18:49] <dirk2> uuuhi, ARM @ 800MHz
[18:49] <ogra> yeah :)
[18:49] <ogra> well thats the avreage HW we also target with the distro build
[18:50] <ogra> *average
[18:50] <dirk2> Is it possible for a user (e.g. me ;) ) to use these machines to compile something?
[18:51] <ogra> no, sadly not, there is work going on to set up a cloud based buildsystem though
[18:51] <ogra> but that will use qemu
[18:51] <ogra> and should make PPAs possible
[18:51] <ogra> or something similar to PPAs
[18:52] <dirk2> sometihng like OpenSuseBuild System for ARM?
[18:52] <ogra> something like that, yes
[18:52] <dirk2> sorry, PPA?
[18:52] <ogra> well, and indeed you can upload packages to ubuntu if you like ... through REVU and sponsoring
[18:52] <dirk2> ok ;)
[18:52] <ogra> https://help.launchpad.net/Packaging/PPA
[18:53] <dirk2> ok, thanks
[20:49] <rjune_wrk> ogra: are you around?
[20:57] <NCommander> lool, so if this test passes, what is our next step?
[20:57] <NCommander> (I had a previous pass with some the KDE packages, so I'm leaning that this will pass too)
[20:59] <lool> NCommander: Which test?
[20:59] <lool> :-P
[20:59] <lool> ogra: We don't have SMP support in emulated qemu boards
[20:59] <lool> ogra: But yes, I did try this out
[20:59] <lool> Actually I tried the v6 realview SMP one
[21:00] <lool> But realview is in a poor state of emulation/upstream support in that there's no PCI support in upstream linux and qemu expects one and actually needs one to offer network and SCSI hard disk...
[21:00] <NCommander> lool, building mesa w/ the launchpad-buildd setup
[21:00] <lool> NCommander: Well if it's fast, we need to find out why it's not on the buildds; with IS probably
[21:01] <lool> NCommander: But I would expect it's slow and we need to find which package changed (e.g. try downgrading dpkg-dev)
[21:01] <ogra> lool, yeah, i found that out myself ... would also need kernel hacking, SMP is no option with versatile
[21:01] <ogra> rjune_wrk, whats up ?
[21:02]  * ogra has to go in 5 min, if its important, shot now or never
[21:02] <rjune_wrk> ogra: can I get you to try something for me?
[21:02] <ogra> *shoot even


[01:53] <frojasg> hi guys
[01:54] <bdmurray> hello frojasg
[01:54] <frojasg> i have a question
[01:55] <bdmurray> okay
[01:57] <frojasg> recently i following  this guide for install cyrus imap in hardy
[01:57] <frojasg> https://help.ubuntu.com/community/Cyrus
[01:57] <frojasg> and don't work .... i can't make a connection with the server
[01:59] <frojasg> i thinks maybe be a bug for hardy .... because in gutsy work without problem
[02:00] <frojasg> but i don't know very well, what it's the problem
[02:02] <bdmurray> hmm
[02:03] <bdmurray> so you can't telnet to the local host?
[02:04] <frojasg> no ... throw this error "BYE Fatal error: can't write proc file"
[02:08] <bdmurray> hmm, I'll try and recreate it in a bit
[02:11] <frojasg> thanks a lot bdmurray
[02:38] <frojasg> bdmurray: i fix the problem
[02:44] <frojasg> anyway ... the package have a bug ... have the wrong privilege  in /var/spool/cyrus and /var/lib/cyrus
[03:38] <danage> hey, can someone fix the firefox-crash-on-flash bug please?
[03:47] <crimsun> danage: 192888?
[03:49] <danage> yes!
[03:49] <crimsun> danage: for hardy, about as much as can be done already has been.
[03:50] <danage> oww
[03:50] <danage> deinstalling pulseaudio doesn't help though i read?
[03:50] <crimsun> danage: you need to tell me more about your specific configuration.
[03:50] <danage> i have ff3 b5 plus libflashsupport
[03:51] <crimsun> that bug has way too many responses; most of them are completely irrelevant to the issue at hand (which is the symptom described in the subject of the bug report)
[03:51] <crimsun> and is your install amd64 or i386?
[03:51] <danage> i386
[03:51] <crimsun> you have several options, then.
[03:52] <danage> yes i agree and that's why i never started to try solving is, because a lot of the solutions seemed to contradict each others
[03:52] <crimsun> 1) remove libflashsupport and change pulseaudio's /etc/pulse/default.pa config.
[03:52] <crimsun> 2) use the modified nspluginwrapper deb with support for i386.
[03:52] <crimsun> 3) remove flashplugin-nonfree altogether.
[03:53] <danage> what would you recommend?
[03:53] <danage> i do want flash
[03:53] <danage> doesn't have to be nonfree
[03:53] <danage> if you say the oss flash is ok, i can use that
[03:53] <crimsun> um, well, I'm a bit biased, since I've spent a tremendous amount of time triaging that bug and making workarounds.
[03:53] <danage> not biased, but the best person to ask i would say
[03:54] <crimsun> the one with the least amount of fallout is likely (2).
[03:54] <danage> ok to you have url with instructions?
[03:54] <crimsun> no, but there's bound to be one in that bug report
[03:55] <crimsun> frankly I think that the instability is unfortunate and that we should work around it by adapting pulseaudio's /etc/pulse/default.pa config.
[03:56] <danage> i can't find it
[03:56] <crimsun> a great many applications broke by way of our having PA grab raw hw:
[03:56] <danage> i saw a blueprint "solve linux sound woes altogether once and for all"
[03:56] <danage> i would TOTALLY support that :)
[03:56] <crimsun> yeah, that's utter bunk, because no one can do that.
[03:56] <danage> why not?
[03:57] <crimsun> we already have to support legacy systems - both OSS/Free, and ALSA, and OSSv4.x - and regardless how one considers it, any approach will break someone's install.
[03:57] <danage> well, we all have to make sacrifices
[03:58] <danage> people with "legacy" install will have to adapt
[03:58] <crimsun> it's very simple to say that when one doesn't have to make the choice or triage the bugs.
[03:58] <danage> haha, yes
[03:59] <crimsun> I'll be committing backend packaging changes to bzr pretty soon that make it possible to drop in any one of OSSv4.x and ALSA and have things work fairly well (i.e., some stuff will break, but I'll try to clean up the mess as much as possible)
[04:00] <danage> cool
[04:00] <danage> sounds like a good solution
[04:00] <crimsun> no, it sounds like a PITA.
[04:00] <crimsun> unfortunately, there will never be One True Way.
[04:01] <danage> compromise, then
[04:01] <danage> btw, can you enlighten me on backports? is that the way to keep hardy updating?
[04:01] <bdmurray> frojasg: it'd be good to report that then if it hasn't been reported already
[04:01] <crimsun> danage: "the" way?  I don't know.
[04:02] <crimsun> danage: I don't know your use cases or requirements, for starters.
[04:02] <danage> for the average user that wants to benefit from continuing bugfixes and development
[04:02] <danage> (=my case) :)
[04:02] <frojasg> bdmurray: ok, now i going to report it ... again  thanks a lot :D
[04:04] <crimsun> danage: i.e., you plan to retain 8.04 but wish to have newer versions of packages from what-will-become-8.10?  Then yes, backports is probably your best bet.
[04:05] <danage> or can i do distro upgrade already?
[04:05] <crimsun> I really, strongly recommend that you do not dist-upgrade to intrepid currently.
[04:06] <danage> :) ok
[04:06] <danage> then, backports it is for now
[04:09] <gravemind> hey, this bug is keeping me from upgrading to hardy, what should I do? https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/222278
[04:09] <danage> thanks crimsun
[06:12] <tbielawa> does bughelper work for anyone running hardy?
[08:47] <iulian> G'morning
[10:19] <nikolaj> Hi, I'm total new... So is this forum too add the bug you find in Ubuntu?
[10:21] <jpatrick> nikolaj: you can file one at https://bugs.launchpad.net/ubuntu/+filebug
 Thanks I will read it now
 it say's that you must be loged on
[10:24] <jpatrick> nikolaj: yes, register on Launchpad first
[10:56] <nikolaj> The bug I found Bug #226073
[11:20] <qense> hello
[11:21] <iulian> Hey qense
[11:27] <qense> are there already many new important bugs reported in hardy after the release?
[13:28] <qense> do you think bug 225326 contains enough information? I can't find that much in kern.log Maybe it would be good to try the debuggin mode
[15:38] <mrooney> bdmurray: around, by any chance?
[17:04] <Salumu> hi persia, could you make any comments about how gdb works when attached on a running process?
[17:05] <persia> Salumu: I'm not deeply familiar with that, but I'm haoppy to answer questions.
[17:07] <Salumu> persia, right, I was attending the OpenWeek session you made, and I wanted to know more about how to prevent a program from being debugged
[17:07] <persia> Preventing a program from being debugged?  Why would you want to do that?
[17:08] <Salumu> In case I'd like to prevent people from reverse engineering it for instance
[17:09] <Salumu> I heard that some people use debuggers to learn more about how a program works
[17:09] <awalton__> Salumu, anything they could learn from a debugger they could learn from the code itself.
[17:09] <awalton__> code armoring/obfuscation is completely a different issue.
[17:09] <pochu> unless he doesn't intend to release the code...
[17:10] <Salumu> pochu is right, I assume that I didn't intend to release the code indeed
[17:11] <Salumu> awalton__, do you have any hints on code armoring?
[17:11] <awalton__> other than google is your friend, not really.
[17:12] <awalton__> it's not a very widely practiced thing I don't think.
[17:12] <awalton__> you see it more in .net/java/byte-code interpreted languages though
[17:14] <Salumu> awalton__, thanks for the hints :)
[17:14] <afflux> morning
[17:26] <afflux> waaaaaaaaaaaaaah. I gotta end my life :(. I just lost my old home partition by backing it up on an encrypted partition and formatting the partition that contained the keyfile. That's the price for working while actually sleeping.
[17:30] <persia> afflux: Are you sure you're encryption is that annoying?  You might be able to recover your data with about six months of brute-force analysis (unless you picked a truly huge key size), and you might get lucky.
[17:31]  * persia is guessing that your current life expectancy > 6 months, as part of the relative cost/benefit analysis
[17:31] <afflux> hehe
[17:31] <afflux> persia: not sure. It's aes-lrw-benbi using a password longer than 20 chars and all kind of special chars (in the ASCII range though)
[17:33] <afflux> note that I have a password in it, but didn't use it since about 2 years (because of the keyfile) so I just can't recall it
[17:33] <persia> That's likely less than 160 bits.  About 10^16 permutations.  Depends on how many permutations your hardware can do a second: there's about 6/7 of 10^5 seconds in a day, so if you can get 10^10 permutations, you ought get in within a week or so.
[17:33] <persia> (errr...  10^10 permutations/sec)
[17:34] <afflux> could be worth a try
[17:34] <persia> Umm.  Sorry, 10^19.  You want to get at last 10^12 permutations/second to get back in a reasonable timeframe.
[17:35] <persia> (or maybe it's late for me, and I can't do math: ask a calculator how long it will take once you find out how fast you can hack it)
[17:35] <afflux> will do
[17:40] <afflux> persia: ugh. did 50 test runs, took ~90secs :(
[17:40] <persia> afflux: That's not fast enough :(
[17:41] <afflux> not really
[17:41] <persia> (unless you get really lucky)
[17:42] <persia> You might get more speed by digging out the handler, and using that as a code base, rather than scripting something.  Feed the challenge-response directly, and pull any timeout or delay code.
[19:04] <nealmcb> bdmurray: re: https://wiki.ubuntu.com/MeetingLogs/openweekhardy/ReportBugs2 - there is  link there to https://bugs.edge.launchpad.net/ubuntu/+source/reportbug-ng/+bug/175508 - perhaps the wiki writer thought the session would be about the tool, which I guess was not the case, but can someone change the importance of that bug?  As several have pointed out, it isn't a wishlist item
[19:07] <bdmurray> nealmcb: interesting, thanks
[19:08] <nealmcb> bdmurray: thanks for your talk!
[19:09] <bdmurray> nealmcb: thanks, I hope it was useful


[01:56] <dobey> anyone around?
[02:05] <dobey> i'll take that as a no
[02:21] <charlie-tca> dobey: this is kind of quiet on the weekend


[22:49] <ChinnoDog> hi peeps
[22:49] <ChinnoDog> oh. It is 50min past meeting time. Did people actually go?


[23:38] <xnox> i've uploaded usb-creator 0.2.59 into utopic twice now, but that upload is not visible anywhere and i didn't receive any email about it either.
[23:49] <stgraber> xnox: the queue processing script is blowing up on all uploads apparently
[23:50] <xnox> stgraber: sexy =) and wgrant says librarian has sniffles. So I guess I should sleep then =( *boring*
[23:52] <stgraber> cjwatson, wgrant: hey, we're getting "DataError: integer out of range" at the time process-upload tries to create a queue entry. Last good was 21:39, first bad was 21:49, seems to affect all uploads.
[23:52] <stgraber> oh, and looking at other IRC channels, it's probably related to some other LP problems :)
[23:53] <wgrant> yes.


[23:02] <marcusrussi> is basic ideals going to be the intrepid theme?
[23:24] <DanaG> Wow, Fedora sure does boot slowly.
[23:24] <DanaG> Especially in a VM with only 256 megs of RAM.
[23:30] <DanaG> OOps, wrong channel; totally irrelevant to here.
[23:30] <DanaG> Tabs do that to me, sometimes.