[09:53] <tsdgeos> Saviq: that "just remove it" it's not a good enough solution tbh
[09:53] <tsdgeos> i want to have both unity8 and unity7 installed
[09:53] <tsdgeos> why do i need to have two network indicators in unity7?
[09:53] <Saviq> tsdgeos, because indicator-network doesn't yet implement everything nm-applet does
[09:54] <tsdgeos> Saviq: sure, then indicator-network should be blacklisted for the desktop
[09:54] <tsdgeos> or whatever mechanism makes me not have a ugly unity7 experience
[09:54] <tsdgeos> Saviq: sent you the email with the crash-tester btw
[09:54] <Saviq> tsdgeos, thanks
[09:55] <Saviq> tsdgeos, we could potentially disable the network indicator in the desktop profile, but then unity8 on the desktop would lose it, too... I'm not sure nm-applet is good enough with unity8
[09:55] <Saviq> tsdgeos, but anyway
[09:55] <tsdgeos> sure, not my biggest problem :D
[09:56] <Saviq> tsdgeos, yes, my replies were more to the "I don't know where that came from"
[09:56] <tsdgeos> was just giving my opinion
[09:56] <Saviq> rather than this is the right solution
[09:56] <seb128> tsdgeos, Saviq: you can edit /usr/share/unity/indicators/com.canonical.indicator.network and drop the desktop section, we should probably do that by default seeing the number of people complaining about it
[09:57] <seb128> then people who want to test the indicator on the desktop would need to edit to add back
[09:57] <Saviq> seb128, yeah, but as said above, is nm-applet working good enough under the desktop unity8 session?
[09:57] <seb128> but opt-in probably makes sense, most people get the indicator through other depends, not because they want to use it
[09:58] <Saviq> yeah sure
[09:58] <seb128> I've not tried it
[09:58] <seb128> but nm-applet is indicator-application
[09:58] <seb128> does that work under unity8?
[10:01] <Saviq> seb128, it does, somewhat
[10:02] <Saviq> hmm it actually seems to work fine
[10:02] <Saviq> can't enable cellular, though
[10:03] <Saviq> hmm or maybe that's actually indicator-network in desktop profile, not nm-applet
[10:03] <Saviq> btw, the list of things that get removed:
[10:04] <Saviq> with indicator-network:
[10:04] <Saviq> account-plugin-ubuntuone* indicator-network* ubuntu-system-settings* ubuntu-system-settings-online-accounts* unity-scope-click*
[10:04] <Saviq> not great
[10:07] <seb128> Saviq, just drop the sections from /usr/share/unity/indicators/com.canonical.indicator.network to make sure it's not it
[10:07] <Saviq> seb128, yeah, no nm-applet under unity8, but that's probably fine (i.e. if you want unity8 and network, you need indicator-network), as long as ↑ those deps get fixed - like account-plugin-ubuntuone depending on the indicator network? what gives?
[10:09] <seb128> Saviq, it doesn't depends on it, it depends on ubuntu-system-settings-online-accounts
[10:09] <seb128> which depends on u-s-s
[10:10] <seb128> which depends on i-n since it's the backend used for the wifi panel
[10:12] <Saviq> seb128, why does it depend on u-s-s, don't we have a desktop version of that?
[10:13] <seb128> mardy, ^
[10:13] <seb128> mardy, well I guess we could maybe have a | gnome-control-center-signon
[10:13] <seb128> ups
[10:13] <seb128> Saviq, ^
[10:13] <seb128> but I'm unsure, I didn't look at potential differences
[10:14] <Saviq> seb128, right
[10:15] <mardy> Saviq: removing ubuntu-system-settings-online-accounts on the desktop is fine
[10:15] <mardy> Saviq: not sure about account-plugin-ubuntuone
[10:15] <Saviq> mardy, yeah, I didn't think that one would be fine
[10:17] <Saviq> yeah, "online accounts" → no Ubuntu One account (I can actually add one (???), but that just shows a grey screen - probably plugins cached somewhere and not reloaded on removal)
[10:17] <Saviq> mardy, ↑ bug, btw?
[10:18] <mardy> Saviq: IIRC, plugins are not cached
[10:18] <seb128> Saviq, mardy: if "removing ubuntu-system-settings-online-accounts on the desktop is fine" we should probably have account-plugin-ubuntuone depends on "u-s-s-o-a | g-c-c-s"
[10:18] <Saviq> so yeah, we need to solve the deps somehow, otherwise people will end up with indicator-network on their unity8-less desktops
[10:19] <mardy> seb128: I think so, unless they have a different package for the U1 plugin on the desktop
[10:19] <Saviq> mardy, I mean "cached" in signond or somewhere - in memory basically
[10:20] <mardy> Saviq: I don't think so, but the OA UI is coming from the online-accounts-ui D-Bus service, which exits after a few seconds of inactivity
[10:20] <mardy> Saviq: if you just briefly closed and re-opened it, it may be that the old process was reused
[10:20] <Saviq> hmm on second look it seems that online-accounts-ui doesn't even work on the desktop
[10:20] <Saviq> seb128, ↑
[10:20] <seb128> Saviq, you mean?
[10:20] <Saviq> for U1
[10:21] <Saviq> seb128, I mean I can't add a U1 account through g-c-c
[10:21] <Saviq> http://pastebin.ubuntu.com/7032274/
[10:21] <seb128> right, I noticed that recently as well
[10:21] <seb128> it works through ubuntuone-control-panel-qt though
[10:22] <mardy> seb128, Saviq: actually, IIRC we never had a U1 account plugin for the desktop
[10:22] <seb128> mardy, but it's showing in the list of "protocols" in the u-c-c UI
[10:22] <Saviq> seb128, mardy, yeah, so in fact it's probably fine for the plugin to not be there either
[10:22] <seb128> mardy, which is confusing
[10:22] <Saviq> (there == on the desktop)
[10:22] <Saviq> it is
[10:23] <mardy> seb128: it definitely shouldn't be listed, but I think it will go away if you remove the plugin
[10:24] <seb128> mardy, not sure how I got the plugin installed, I guess that's because of touch stuff
[10:25] <seb128> but yeah, still a bug
[10:25] <mardy> seb128: yep
[10:25] <Saviq> mardy, actually I can't get it to disappear from g-c-c...
[10:25] <Saviq> removed he plugin, killed signon*
[10:25] <Saviq> it's still there...
[10:25]  * Saviq files bugs
[10:26] <seb128> Saviq, do you have ubuntuone-credentials-common installed?
[10:26] <seb128> Saviq, that ships /usr/share/accounts/providers/ubuntuone.provider
[10:26] <Saviq> seb128, yeah
[10:27] <seb128> if I move that file away it stops being listed
[10:27] <Saviq> seb128, +1
[10:27]  * Saviq not sure where to file bug... the provider shouldn't be there if the plugin isn't there, should it...
[10:27] <Saviq> and it shouldn't be listed in g-c-c anyway, as it's incompatible with it apparently
[10:28] <seb128> Saviq, open on gnome-control-center-signon and let mardy reassign if needed I guess? ;-)
[10:29] <Saviq> seb128, ;)
[10:34] <Saviq> seb128, mardy, bug #1287640
[10:34] <seb128> Saviq, thanks
[10:34] <mardy> Saviq: thanks
[11:03] <mzanetti> Saviq: in here https://code.launchpad.net/~mzanetti/unity-api/new-screenshot-and-focusing-api/+merge/199810
[11:03] <mzanetti> Saviq: line 157, is this enough?
[11:04] <Saviq> mzanetti, should be
[11:04] <mzanetti> thanks
[11:04] <Saviq> mzanetti, the resulting .pc file has it as the version?
[11:05] <Saviq> mzanetti, unity-mir needs an update of Provides, and unity8 needs and update of Depends (and unity8-fake-env of Provides:, too)
[11:05] <mzanetti> yep, its in there
[11:05] <mzanetti> right...
[11:28] <mzanetti> Saviq: ok... I think we can start reviewing the right edge stuff... there's quite a bit stuff to fix for sure, but I think feedback from reviewers would help me a lot in this stage
[11:29] <Saviq> mzanetti, any dep or conflict with new-scopes?
[11:29] <mzanetti> Saviq: yes. it'll conflict with new-scopes as is right now... but as I don't know how long new-scopes will still take I based everything on trunk, hoping that the right edge would land first
[11:30] <Saviq> mzanetti, ok, let's see that race ;)
[11:31] <mzanetti> Saviq: we also could agree on an order... but I'd need an ETA for new-scopes then
[11:31] <mzanetti> and last time I asked you weren't sure about that => I went for trunk
[11:32] <mzanetti> in any case. the stuff that conflicts is 90% dropping the new-scopes stuff and using the right-edge stuff
[11:32] <mzanetti> and I can obviously do/help with the merge, regardless who comes first
[11:33] <Saviq> mzanetti, yup, well we'd like new-scopes to land asap, they basically need a review soon, too
[11:33] <Saviq> mzanetti, but probably some cleanup first
[11:35] <Saviq> mzanetti, could you look into dropping the HUD (just the integration part in Shell.qml for now) and skip the hud tests in autopilot?
[11:35] <mzanetti> Saviq: ack.
[11:39] <Saviq> mzanetti, btw, https://wiki.ubuntu.com/Process/Merges/Checklists/Unity-Mir
[11:39] <mzanetti> Saviq: ?
[11:40] <Saviq> mzanetti, on your merge for unity-mir, please add the checklists
[11:40] <Saviq> -s
[11:40] <mzanetti> huh? isn't it there? /me checks
[11:40] <Saviq> mzanetti, ah, I meant -api
[11:40] <Saviq> mzanetti, and yeah, it's there
[11:40] <Saviq> mzanetti, sorry for the noise
[11:41] <mzanetti> np
[11:41] <mzanetti> so yeah, you start from here https://code.launchpad.net/~mzanetti/unity8/right-edge-2/+merge/204798 and all the related ones are listed in the checklist
[11:43] <Saviq> mhr3_, what do we do about:
[11:43] <Saviq> 24	-Recommends: ${unity-default-masterscopes},
[11:43] <Saviq> 25	+ unity-scope-scopes,
[11:43] <Saviq> 26	+ unity-scope-onlinemusic,
[11:43] <Saviq> 27	+ unity-scope-mediascanner2,
[11:43] <Saviq> 28	+ unity-scope-click,
[11:44] <Saviq> ETOOMANYmhr3s
 mhr3_, what do we do about:
[11:44] <Saviq>  24 -Recommends: ${unity-default-masterscopes},
[11:44] <Saviq>  25 + unity-scope-scopes,
[11:44] <Saviq>  26 + unity-scope-onlinemusic,
[11:44] <Saviq>  27 + unity-scope-mediascanner2,
[11:44] <Saviq>  28 + unity-scope-click,
[11:45] <mhr3> Saviq, hmmm
[11:45] <mhr3> we don't really have desktop vs phone now
[11:45] <mhr3> so if we keep it as hard recommends it'd be fine imo
[11:45] <mhr3> for now anyway
[11:46] <Saviq> mhr3k
[11:53] <tsdgeos> hmmm
[11:53] <tsdgeos> don't know what i did but my unity8 indicators area is now empt
[11:53] <mzanetti> Saviq: when you said disable the hud, you really meant to get rid of the hud completely? as in: if you drag from the bottom edge the hud button would not appear any more?
[11:53] <tsdgeos> any idea why that may be happening?
[11:53] <mzanetti> tsdgeos: same here
[11:53] <tsdgeos> oh really?
[11:54] <mzanetti> tsdgeos: I merged with tnrunk and they appeared again
[11:54] <tsdgeos> that's really unfortunate when i'm trying to fix a crash in indicators :D
[11:54] <mzanetti> :D
[11:54] <tsdgeos> mzanetti: hmmm, i'm up to date with trunk
[11:54]  * tsdgeos does a clean build
[11:54] <mzanetti> tsdgeos: well, I did a run_on_device on my right-edge-stuff and they were gone as of today, I did some merging, rebooting, rebuilding and they appeard again
[11:56] <tsdgeos> ok
[11:56] <tsdgeos> this is on the desktop fwiw
[11:56] <tsdgeos> nope, nothing
[11:57] <tsdgeos> what, i'm getting the fake scopes
[11:57]  * tsdgeos puzzled
[11:58] <tsdgeos> i must have broken something with the ppa purge :-/
[11:59] <Saviq> mzanetti, yes, get rid of it
[11:59] <mzanetti> my pleasure, sir
[11:59] <Saviq> mzanetti, it's going "somewhere else", but we don't know where yet
[12:00] <tsdgeos> and they are back
[12:00] <tsdgeos> after installing unity8
[12:00] <tsdgeos> that brought lots of packages that build -c didn't
[12:00] <tsdgeos> weird
[12:00] <Saviq> tsdgeos, build -c doesn't
[12:00] <Saviq> tsdgeos, build -s does
[12:00] <tsdgeos> ahhhh righto
[12:01] <mzanetti> Saviq: that pCell stuff is crazy (the cool way) :)
[12:18] <Saviq> mzanetti, indeed!
[12:27] <mzanetti> Saviq: is this how you imagined it? https://code.launchpad.net/~mzanetti/unity8/disable-hud/+merge/209226
[12:27] <Saviq> mzanetti, nah, just remove it from Shell altogether
[12:27] <Saviq> mzanetti, so that we don't even instantiate it
[12:27] <mzanetti> ok
[12:27] <Saviq> mzanetti, we can easily bring it back with bzr
[12:28] <Saviq> /food
[12:28] <mzanetti> ok
[12:30] <mzanetti> tsdgeos: the BottomBar is only there for revealing the hud, right?
[12:30] <tsdgeos> mzanetti: yes
[12:30] <mzanetti> ok. /me removes the BottomBar too
[13:53] <Saviq> dednick, what can we do about the "unity8 exiting kills indicators" thing? ;) it's getting annoying ;D
[13:54] <mhr3> saviq, thoughts about adding an activityindicator to a scope view when there are no results visible and the one in the search bar isn't visible either? ie for surfacing
[13:54] <dednick> Saviq: um. check if it's being run on desktop i guess.
[13:55] <Saviq> mhr3, I think it could fit somewhere in the new header
[13:55] <davidcalle> mhr3, on a slightly related topic, could we have somehting like "pull to reload", to update surfacing? (eg. news scope)
[13:55] <Saviq> mhr3, like replace the looking glass icon
[13:55] <Saviq> davidcalle, nothing to do with mhr3 ;D
[13:55] <mhr3> saviq, so basically needs design :)
[13:55] <mhr3> davidcalle,  ^^
[13:55] <Saviq> yup
[13:56] <mhr3> i'll talk with mike
[13:56] <mhr3> but tbh i'd like the pull to reload too
[13:56] <mhr3> would mean caching == solved :)
[13:57] <dednick> Saviq: i'll take a look
[13:57] <Saviq> dednick, don't worry, was just a I-got-annoyed-by-this-right-now issue ;)
[13:58] <mhr3> saviq, same for my indicator issue btw ^ :)
[14:01] <Saviq> mhr3, ENOUNDERSTOOD
[14:01] <mhr3> saviq, no activityindicator -> also I-got-annoyed-by-this-right-now
[14:01] <Saviq> mhr3, ah ;)
[14:06] <Saviq> MacSlow, hey, can I steal you for some investigation on notification ap tests?
[14:06] <Saviq> MacSlow, i.e. http://ci.ubuntu.com/smokeng/trusty/touch/mako/219:20140304:20140304/6967/unity8/848175/
[14:06] <MacSlow> Saviq, looking...
[14:07] <Saviq> MacSlow, somehow the assertion fails, even though I can see the notification correctly and the icon is there
[14:07] <Saviq> so iconSource is definitely != ""
[14:07] <Saviq> MacSlow, so it might be something with ap
[14:08] <MacSlow> Saviq, most likely
[14:10] <MacSlow> Saviq, I'm still wondering, if those could somehow be moved to pure qmltests... what keeps me away from porting them, is the missing interaction with the real backend
[14:11] <Saviq> MacSlow, right, these are of the kind that should stay this way - they're integration tests
[14:11] <Saviq> MacSlow, *maybe* less extensive
[14:13] <MacSlow> Saviq, I don't know enough of AP's internals to provide a better (non-string based) test there... which might be more robust
[14:15] <mhr3> saviq, btw qtry_compare sucks - i replaced it with qsignalspy and shaved off almost 3seconds from make test
[14:18] <MacSlow> Saviq, these AP-tests for snap-decisions "failing" have held back jenkins-approvals many times
[14:20] <Saviq> MacSlow, yeah, but not that one, I'm getting 100% fail on that
[14:20] <Saviq> MacSlow, where before it was just flaky
[14:20] <Saviq> MacSlow, and the only failures that we look over currently are unity8 crashes, which that one isn't
[14:21] <MacSlow> Saviq, it's not new notification-code at fault I bet, as I'm still waiting on some reviews :)
[14:22] <Saviq> MacSlow, yeah I know ;) nothing ours changed recently - while autopilot did
[14:22] <Saviq> MacSlow, so ok, I'm looking into it further
[14:23] <MacSlow> Saviq, is there maybe a "state" that AP stores, which is not in sync with the real notification?
[14:29] <Saviq> MacSlow, not sure, but just confirmed old autopilot passes this test, upgrading 1 by 1 now
[14:29] <MacSlow> Saviq, bisecting the other way ;)
[14:31] <tsdgeos> @unity: standup?
[14:48] <Saviq> mzanetti, bug #1287689 is already marked as dupe of the non-rotating shell
[14:48] <Saviq> mzanetti, or maybe we just multiplexed - I was clearing it up with Jamie in #ubuntu-touch
[14:48] <mzanetti> Saviq: ok. sorry. missed that
[14:49] <Saviq> mzanetti, don't be :)
[14:49] <mzanetti> but in any case, Jamie's report seems a dupe of some bug :)
[14:49] <Saviq> mzanetti, also
[14:49] <Saviq> plugins/Utils/easingcurve.h	UNKNOWN	*No copyright*
[14:49] <Saviq> plugins/Utils/easingcurve.cpp	UNKNOWN	*No copyright*
[14:49] <Saviq> qml/Stages/SwitchingApplicationImage.qml	UNKNOWN	*No copyright*
[14:49] <Saviq> qml/Stages/SpreadDelegate.qml	UNKNOWN	*No copyright*
[14:49] <Saviq> qml/Stages/TransformedSpreadDelegate.qml	UNKNOWN	*No copyright*
[14:49] <mzanetti> meh...
[14:49] <mzanetti> thanks. I'll fix
[14:50] <mzanetti> Saviq: doing a hangout on air now for an hour. so if possible, ping me again after 5pm :)
[14:50] <Saviq> mzanetti, will do
[16:08] <Saviq> mterry, qt is crashing on startup some 5-10% of the runs
[16:08] <mterry> Saviq, :(  that makes tests hard to rely on
[16:09] <Saviq> mterry, is fixed with 5.2
[16:09] <mterry> Saviq, ah!  OK, I saw you all talking about that in emails
[16:09] <Saviq> mterry, yup
[16:10] <mterry> Saviq, well, that branch is ready, I think
[16:11] <Saviq> mterry, please chase reviewers, then :)
[16:12] <tsdgeos> Mirv: we need https://codereview.qt-project.org/#change,79857 in 5.2.1
[16:16] <Saviq> fixes bug #v
[16:16] <Saviq> 1277206
[16:16] <Saviq> bug #1277206 grr
[16:32] <mhr3_> saviq, how do we want to deal with gotoScope / openScope that wants to define the search string / filter/department state?
[16:32] <mhr3_> saviq, should i be passing that somehow to the signals, or try to deal with it internally?
[16:33] <mhr3_> saviq, basically i'm pretty sure that if i set a .searchString on the scope, you're going to invalidate it as soon as you create the visual component
[16:34] <mhr3_> or am i wrong?
[17:07] <Mirv> tsdgeos: Saviq: luckily weekly meeting now, pushing a build so that I check it compiled fine in the morning and copy the landing PPA
[22:18] <kdub> mterry, is there a command line way to start usc?
[22:19] <mterry> kdub, not really, it heavily relies on its two-way communication with lightdm
[22:19] <mterry> kdub, if you want to insert yourself
[22:19] <mterry> kdub, edit /usr/share/ubuntu-touch-session/usc-wrapper
[22:20] <kdub> mterry, alright, thanks
[22:31] <tedg> mterry, So, it seems we did similar work...
[22:31] <mterry> tedg, on volume/mute?  bummer
[22:31] <tedg> mterry, I've got a bunch of stuff going into account service.
[22:31] <tedg> mterry, But not volume/mute
[22:31] <mterry> tedg, the source package?
[22:31] <tedg> mterry, But I set up nice proxies and stuff :-)
[22:32] <tedg> mterry, https://code.launchpad.net/~ted/indicator-sound/account-service-support/+merge/205891
[22:35] <mterry> tedg, interesting.  Shouldn't conflict with my stuff though
[22:36] <tedg> mterry, Yes, but the volume/mute should probably go into sound settings.
[22:36] <mterry> tedg, also, these policykit permissions keep being duplicated around.  We might want to consolidate on com.ubuntu.AccountService.GreeterReadAny and GreeterModifyAny
[22:36] <mterry> tedg, settings?
[22:36] <tedg> +1
[22:36] <tedg> mterry, The account service schema
[22:37] <mterry> tedg, like this?  https://code.launchpad.net/~mterry/gsettings-ubuntu-touch-schemas/volume/+merge/209158
[22:38] <mterry> tedg, that also can provide the generic polkit actions
[22:38] <tedg> mterry, It should go in the one installed by indicator-sound
[22:38] <tedg> It seems they're more about indicator-sound than touch.
[22:38] <mterry> tedg, why necessarily?  That package above already contains lots of sound related settings
[22:38] <mterry> tedg, they are trying to remove the touch namespace wherever possible
[22:39] <mterry> tedg, they renamed the binaries, and will rename source
[22:39] <tedg> mterry, [22:40] <mterry> tedg, that's because com.ubuntu.touch.AccountsService.Sound.xml with the other sound settings exists, but they haven't migrated them to non-touch namespaces yet
[22:40] <tedg> Who is setting those?
[22:40] <mterry> tedg, telephony-service and ubuntu-system-settings look at the other settings like ringtones and silentmode
[22:41] <mterry> tedg, it's true that indicator-sound is the only one that currently needs to look at volume/mute, but they seemed like system-y settings that indicator-sound was just an implementation detail of
[22:42] <mterry> tedg, but I'd be happy to move them over if you feel like that's where they ought to live
[22:42] <tedg> mterry, Well, I didn't realize that we had an entire repo of random settings… still deciding how I feel about that.
[22:43] <tedg> What I'd really like is that they're stored in ALSA and the greeter and user session both read from there.
[22:43] <tedg> That's probably a minor pipe dream right now.
[22:43] <mterry> tedg, does ALSA have the per-user permission structure to allow that?
[22:43] <tedg> I think that's what logind is setting the permissions of using the ACLs.
[22:44] <tedg> The stuff we're getting around with the audio group.
[22:44] <mterry> tedg, but for storing settings?  And we'd need to be able to adjust settings when user isn't logged in by logind
[22:44] <tedg> We'll they're not settings. They're state.
[22:45] <tedg> logind thinks that the greeter is a login session :-)
[22:45] <mterry> tedg, fair.  "but for storing state?  And we'd need to be able to adjust state when user isn't logged in by logind"
[22:45] <tedg> Yes, it does. It's reading/writing that state to the audio chips. Really it's stored there.
[22:46] <mterry> tedg, how does that work for multiple users?
[22:47] <tedg> mterry, Well, you only have one set of speakers. So the audio chip doesn't really understand multiple users. Logind gives permission to modify the driver based on who as the active session.
[22:48] <mterry> tedg, I get that.  But how does volume setting normally work in that environment?  Like, if I have two users open, who sets the volume when I switch from one session to another?
[22:48] <tedg> mterry, I believe it's who ever is the active session. So when you switch, you trade control.
[22:49] <tedg> Fast user switching volume fight, go!
[22:49] <mterry> tedg, sure, but which component is changing the volume is my interest
[22:49] <mterry> tedg, because the correct volume to set must be saved somewhere for that user
[22:50] <tedg> mterry, I don't  know how Pulse behaves there, but I'd hope it doesn't reset it when you change. You wouldn't want to take your laptop to a coffee shop, mute it, and then switch users to music blaring.
[22:51] <mterry> tedg, I thought volume setting was per-user today.  Just not shared with greeter
[22:51] <tedg> mterry, It could be. Each user has a Pulse daemon.
[22:52] <tedg> mterry, I think the issue is that logind isn't giving access to lightdm?
[22:52] <mterry> tedg, ok, so theoretical ideal place for greeter to talk to would be pulse
[22:52] <mterry> tedg, but it doesn't have per-user outside-of-home support for accessing/setting state
[22:52] <tedg> Well, no, pulse is per-user. ALSA.
[22:53] <mterry> tedg, but then when they logged in, pulse would override that state, right?
[22:53] <mterry> either pulse holds the right user volume state or it doesn't
[22:53] <tedg> mterry, I'm not sure on that, but I don't think it should.
[22:53] <tedg> We really need diwic here for this.
[22:53] <tedg> Perhaps tomorrow morning would be a better time :-)
[22:54] <mterry> tedg, anyway, I restarted the design discussion, but the design has been and still is per-user volume state
[22:54] <mterry> tedg, hence keeping it in AS
[22:55] <tedg> mterry, Hmm, where is that discussion?
[22:56] <mterry> tedg, there was some in email, but mostly in long-standing bug 840777
[22:56]  * tedg subscribes
[22:57] <mterry> tedg, the bug description outlines what design (JohnLea) wants.  I recently re-confirmed with him that it's correct.  But mpt and laney disagree
[23:01] <tedg> We have a bunch of multi-user issues. Need to put design time there.
[23:01] <mterry> tedg, not too much time!
[23:02] <tedg> mterry, We wouldn't want to take away from redesign v10 of the notifications ;-)
[23:04] <mterry> tedg, :)  I was more worried about 14.04
[23:04] <tedg> mterry, We've got at least 6 weeks before final designs are due for that!
[23:05] <tedg> ;-)
[23:05] <mterry> :)


[00:21] <elwood> hi
[00:22] <elwood> i've a broken usb-port on my pc, the kernel.log is full of "garbage" about it. There is a way to stop the scan for this port? it'a kernel or udev question?
[00:23] <IntuitiveNipple> A port or a host controller?
[00:23] <IntuitiveNipple> short of disconnecting it physically, there's no way to disconnect a port from a host... often the ports are shared by multiple host controllers, too.
[00:24] <elwood>  hub 1-0:1.0: unable to enumerate USB device on port 4
[00:24] <elwood> this is the log, just and always the port 4
[00:25] <elwood> with hal i can drop all the log to /dev/null? this is the first thing that pop-ups in my mind :)
[00:26] <IntuitiveNipple> no, the report is from the kernel module.
[00:26] <elwood> ok, and i suppose there is no parameter for the module
[00:26] <IntuitiveNipple> maybe try repairing or disconnecting the port?
[00:27] <elwood> so i can remove it physically, this is the way
[00:27] <IntuitiveNipple> maybe not 'remove' it but electrically disconnect it so the hub doesn't try to select it... but that would require some in-depth systems knowledge. There's no way to isolate it from the kernel that I know of.
[00:28] <elwood> IntuitiveNipple, even if i recompile without log info for the kernel?
[00:28] <IntuitiveNipple> That's rather a drastic approach - what if something else happens and there's no reports?
[00:29] <elwood> a disaster, well thanks IntuitiveNipple
[00:29] <IntuitiveNipple> You could add a rule to syslog.conf
[00:29] <elwood> uhm
[00:29] <elwood> a filter on this warning
[00:30] <IntuitiveNipple> no, you can't filter on text, but you can set a rule so it doesn't log messages from particular facilities.priorities
[00:30] <elwood> this is what i means with "filter", well you make me find a reasonable solution, thanks again IntuitiveNipple
[00:50] <dandel> apw, you there?
[01:03] <IntuitiveNipple> He's probably fast asleep in bed this time of morning
[01:12] <dandel> uck... i need a rebuilt copy of the 2.6.25 mainline
[01:13] <dandel> the one that is on the ubuntu mainline section won't boot enough to help with generating a git disection.
[01:14] <dandel> i keep having 2.6.25 stall just after saying done on the section, Begin: Running /scripts/local-premount ...
[01:16] <IntuitiveNipple> You could use break=top to drop into the initrd and poke around
[01:16] <dandel> add that where?
[01:17] <IntuitiveNipple> kernel command line
[01:17] <dandel> ok
[01:17]  * dandel checks
[01:17] <IntuitiveNipple> In the /init script is loads of calls to maybe_break XXXXX and if XXXX matches the command-line's break= it'll stop
[01:17] <IntuitiveNipple> Or, use just "break" and it'll stop at top anyhow
[01:18] <IntuitiveNipple> You can break at other places; need to look in the /init script (in the initrd) to decide which ones to use)
[01:19] <dandel> it appears that it gets stuck mounting
[01:20] <dandel> 2.6.24 and 2.6.26 work, but 2.6.25 stalls out
[01:20] <IntuitiveNipple> What I sometimes do is add "set -x" to the top of the /init script so I can see all the script commands executing... if it pauses/gets stuck the last ones on screen are a bug clue
[01:20] <dandel> ?
[01:21] <IntuitiveNipple> It causes the shell to write out all commands it is about to execute
[01:21] <dandel> where do i put that exactly?
[01:22] <IntuitiveNipple> 2nd or later lines in /init, in the initrd. You'll need to extract and then repackage the initd image
[01:22] <dandel> ><;
[01:23] <IntuitiveNipple> I've got some documentation on how to do that as part of a laret article
[01:23] <IntuitiveNipple> http://tjworld.net/wiki/Linux/Ubuntu/NetbootPxeLiveCDMultipleReleases#ExtractInitrd
[01:24] <IntuitiveNipple> To extract the image see the section "Extract Initrd" and after changing the script, see "Rebuild Initrd"
[01:24] <dandel> ok...
[01:26] <dandel> ok.
[01:27] <dandel> add set -x just after...  #!/bin/sh ?
[01:27] <IntuitiveNipple> Yes
[01:29]  * dandel boots to see what happens.
[01:31] <dandel> oops lol... forgot to add it to grub.
[01:32] <IntuitiveNipple> :p
[01:32] <IntuitiveNipple> did it spew the commands though?
[01:33] <dandel> i'll find out
[01:35] <dandel> it's not finding it ><;
[01:38] <IntuitiveNipple> which 'it' is not finding what 'it' ?
[01:39] <dandel> the custom initrt... found the issue tho
[01:40] <dandel> although, i wish i could flat out disable system beep on a lot of things
[01:40] <dandel> hmm
[01:40] <dandel> interesting
[01:41] <dandel> stops at the command... mount -w -t ntfs -o locale=en_US ( ya get the rest )
[01:42] <dandel> it appears it's running the mount commands wrong
[08:18] <maxb> smb_tp_: Hi, ubuntu-intrepid-lbm.git doesn't contain the final debian/changelog update and tag for the latest package, did it remain accidently unpushed locally with you, perhaps?
[08:19] <smb_tp_> maxb, hi, let me check
[08:20] <smb_tp_> maxb, Yeah, sorry. Pushing in a sec
[08:21] <smb_tp_> done
[08:21] <maxb> thanks :-)
[08:23] <maxb> Hmm. my git is claiming there is no tag for this release?
[08:25] <smb_tp> maxb, Too early in the morning to do two steps...
[08:25] <maxb> heh
[08:25] <smb_tp> Now
[08:25] <maxb> I guess that answers my next question: the insertchanges/commit/tag isn't automated anywhere?
[08:26] <smb_tp> maxb, No, has to be done manually. And it has to be pushed separately (it least I had problems doing it in one go)
[08:27] <smb_tp> So This time the tag was created, but I had to "push --tags"
[08:28] <maxb> Yeah, git's a bit mystical to me. I don't really understand when you do and don't need --tags
[08:29] <smb_tp> To me it looks like a extra thing just for tags. So git fetch --tags just updates the local tags and git push --tags sends them
[08:30] <smb_tp> Without tags it seems only to do the actual contents
[08:31] <maxb> the fetch/push documentation hints that it tries to transfer tags relating to commits that are being transferred. But I have a feeling that's not always worked as claimed for me.
[08:32] <maxb> or I've not quite understood the algorithm, anyway
[08:32] <smb_tp> Same with me. So I use it in that way that seems to work with my thinking (if I do not forget the steps)
[09:44] <_ruben> bugger .. dkms isnt picking up my second make command as specified in dkms.conf :(
[09:49] <IntuitiveNipple> syntax issue?
[09:53] <_ruben> could very well be .. but im not seeing it .. lemme pastebin my conf
[09:55] <_ruben> http://paste.ubuntu.com/136597/ .. i tried both MAKE[1] and MAKE[10] .. as the result of the 2nd make are marked with [10] directives
[09:56] <IntuitiveNipple> _ruben: Why not simply use a Makefile and call it once?
[10:01] <IntuitiveNipple> _ruben: but, to use MAKE[10] you need a MAKE_MATCH[10] rule too
[10:18] <_ruben> IntuitiveNipple: hmm .. didnt think of the MAKE_MATCH directive .. but i can think i can solve it at makefile level indeed
[10:18] <IntuitiveNipple> MAKE_MATCH is required if you use MAKE[>0]
[10:20] <_ruben> then there's a bug in the docs:
[10:20] <_ruben> https://help.ubuntu.com/community/Kernel/DkmsDriverPackage#Configure%20DKMS
[10:20] <_ruben> it mentions just a MAKE[1]
[10:21] <IntuitiveNipple> _ruben: man dkms
[10:27] <apw> IntuitiveNipple, hey ... bug #331415 ... have you a current status on that one, its on our regressions list :)
[10:27] <ubot3> Malone bug 331415 in linux "request_firmware() fails on resume from suspend" [Medium,Triaged] https://launchpad.net/bugs/331415
[10:28] <IntuitiveNipple> apw: WIP it's a biggie. I'll update it later on
[10:29] <apw> IntuitiveNipple, thanks ... be good to sync up on it before the meeting this evening
[10:31] <IntuitiveNipple> It's a time-consumer! every driver has to be examined and figured out... I'm doing a little bit at a time
[10:36] <IntuitiveNipple> apw: I think it can loose it's regression-potential since it's always been like that :)
[10:36] <IntuitiveNipple> apw: removed tag
[10:37] <apw> IntuitiveNipple, thanks for that ... one less to worry about
[10:37] <IntuitiveNipple> yeah... I was combing the list yesterday, managed to find a few that moved closer to a resolution
[11:02] <amitk> hehe... Linus' 2.6.29 release mail got flagged as SPAM in gmail :)
[11:04] <amitk> apw: can you pull the levers on a new mainline build?
[11:04] <amitk> apw: or tell me how to
[11:04] <apw> amitk, which one you missing.  there is a build in progress right now, so its probabally the one you wanted
[11:05] <amitk> apw: 2.6.29 final?
[11:05] <apw> i think i saw it doing a .27 and a .28 ...
[11:05] <apw> ok will check when these finish
[11:05] <apw> and i will get the thing running out of cron this week
[11:05] <apw> the triggers are automatic in theory
[11:07] <apw> amitk, yeah its just done 27.21, its on 28.9 and will do .29 next i believe
[11:07] <apw> so in the next hour or so
[11:07] <amitk> cool, thanks apw
[11:08] <TheMuso> c
[11:08] <apw> i have been monitoring the builds, and so hand triggering what is meant to be a cron job
[11:08] <apw> so its a simple matter of shoving it in cron (or should be)
[11:11] <dandel> apw, the bug i'm on is stuck until the 2.6.25 kernel gets fixed on boot ><; (it gets stuck on mounting )
[11:11] <amitk> apw: do you do a allmodconfig?
[11:11] <apw> nope, they are built using our ubuntu configs
[11:11] <apw> make oldconfig from those
[11:11] <apw> we can override config options where neceessary
[11:13] <apw> like for hardy we reenable some wireless stuff which is in lbm
[11:14] <amitk> ok
[11:17]  * Kamping_Kaiser gazes at the wall
[12:42] <amitk> apw: bug #322311 and bug #338316 marked as 'Won't Fix' for the two arm flavours
[12:42] <ubot3> Malone bug 322311 in qcontrol "orion5x armel flavour should provide input-modules" [Undecided,New] https://launchpad.net/bugs/322311
[12:42] <ubot3> Malone bug 338316 in linux "Please add a MV78XX0 arm flavour" [Wishlist,Won't fix] https://launchpad.net/bugs/338316
[12:42] <apw> amitk, cool
[12:44] <rtg> apw, amitk: were there other bug fixes besides VFP for those flavours that we can remove?
[12:46] <apw> i don't recall doing any
[12:52] <amitk> rtg: I mentioned ce65d39bbcfaa3c0150891122df79f5ab2db550d needed to be reverted
[12:53] <rtg> amitk: see 14b2f940288288774f74414a0902d578d29d9076
[12:54] <rtg> amitk: oops, nm
[12:56] <amitk> hehe
[12:56] <rtg> amitk: ok, you're right. tehre were 2 VFP patches and I missed the second.
[12:58] <rtg> amitk: I'm not familiar with all of the ARM model names. To which flavour does the Feroceon CPU belong? orion5x or mv78xx0 ?
[12:59] <amitk> rtg: mv78xx0
[12:59] <rtg> amitk: thanks
[13:27] <_ruben> http://paste.ubuntu.com/136726/ .. i forgot skipabi=true on the first run .. do am i missing here? or is a clean+rebuild needed or something?
[13:53] <cooloney> bradF, did you boot up with your own rootfs
[13:54] <cooloney> bradF, amitk i also boot up my own kernel.
[13:56] <cooloney> as bradF said, we need to download the kernel to 0x00100000
[13:57] <cooloney> that is the entry point of the kernel image
[13:58] <amitk> right
[14:00] <cooloney> amitk, how about the kernel command line of your board?
[14:00] <cooloney> i try to mount the rootfs with my own kernel
[14:02] <cooloney> after replacing the kernel of ogra image with my own, the kernel cannot mount rootfs
[14:04] <amitk> root=/dev/sda2
[14:04] <amitk> i use root on a usb stick
[14:05] <cooloney> OK, i will try, thx
[14:11] <cooloney> it is so weird
[14:12] <cooloney> http://pastebin.ubuntu.com/136755/
[14:12] <cooloney> amitk, what kind filesystem are you using on the usb stick?
[14:13] <amitk> cooloney: ext2
[14:14] <rtg> amitk: is ext3 built in?
[14:15] <amitk> rtg: yes, i think so
[14:16] <amitk> yes, it is
[14:16] <rtg> amitk: it even says so
[14:16] <amitk> rtg: what does?
[14:17] <cooloney> rtg, yes, ext3 built in
[14:18] <rtg> amitk: No filesystem could mount root, tried:  ext3 ext2 cramfs vfat msdos
[14:18] <amitk> aah, right
[14:18] <amitk> cooloney: do you have initramfs loaded?
[14:18] <rtg> amitk: noinitrd on the command line
[14:18] <cooloney> amitk, currently no
[14:19] <cooloney> RedBoot> fconfig
[14:19] <cooloney> Run script at boot: true
[14:19] <cooloney> Boot script:
[14:19] <cooloney> .. clock 800
[14:19] <cooloney> .. fis load kernel
[14:19] <cooloney> .. exec -c "console=ttymxc0,115200 console=tty1 root=/dev/sda2 rootdelay=10 ro noinitrd"
[14:19] <amitk> USB_STORAGE is built-in. Is your usb disk supported w/o modules?
[14:20] <amitk> and is the rootfs on /dev/sda2?
[14:20] <cooloney> amitk, do you think i should add "fis load initramfs"
[14:20] <cooloney> sorry, what is "w/o modules?"
[14:20] <rtg> yeah, shouldn't root be /dev/sda1 ?
[14:21] <amitk> cooloney: do you need any special modules besides usb-storage
[14:21] <cooloney> OK, let me try it.
[14:21] <anubhav> cooloney: can you append "rootwait" to your command line
[14:22] <cooloney> anubhav, i will try it
[14:25] <cooloney> amitk, rtg anubhav thanks, i found root is sda1 as ext3 on my usb stick
[14:26] <rtg> cooloney: makes sense to me
[14:26] <cooloney> since this usb stick is from colleague freeflying
[14:26] <cooloney> i did change it's content at all
[14:26] <cooloney> amitk, should i build my own rootfs from scratch?
[14:27] <amitk> cooloney: you don't have to
[14:27] <cooloney> i just need to boot the board to command line console over serial for development, i guess
[14:27] <amitk> right
[14:27] <rtg> cooloney: babbage?
[14:27] <cooloney> rtg, yes
[14:28] <cooloney> babbage early version
[14:28] <rtg> cooloney, amitk: does it work with SATA yet? I'cve got one, but the USB drive is _really_ slow.
[14:29] <cooloney> rtg, i dont have sata on my side, just know SD and USB stick is ok
[14:30] <rtg> cooloney: looks like you build the kernel? Our Freescale port using the cross compiler tools?
[14:31] <amitk> rtg: it was native built
[14:31] <cooloney> rtg, right, i cross compiler our jaunty kernel to zImage
[14:31] <amitk> rtg: but you can replace the kernel with a cross-compiled one
[14:31] <rtg> amitk: Sourcery G++ Lite 2008q3-72
[14:31] <cooloney> and downloaded the zImage to boot up now
[14:32] <amitk> rtg: yeah, good enough
[14:32] <cooloney> amitk, i replaced the kernel from ogra image with my own kernel from cross-compiled one
[14:32] <rtg> amitk: its interesting because its the first time I've seen the cross compiled kernel booted. Its just verification that it works taht way.
[14:34] <amitk> rtg: you mean the first time you've seen cross-compilation used for something other than build verification?
[14:34] <rtg> amitk: in this particular case, yes
[14:35] <amitk> rtg: I've been using cross compiled kernels for the last month or so while we were integrating and testing the babbage flavour
[14:35] <rtg> amitk: its certainly a much faster way to build, isn't it?
[14:36] <amitk> rtg: hell yeah! I'd go nuts doing this in Qemu or natively
[14:36] <rtg> the babbage was taking several hours per flavour
[14:36] <bradF> cooloney: haven't tested my own rootfs yet, just the kernel
[14:37] <amitk> rtg: it takes about 15-20 minutes on my rather old desktop machine for the babage kernel
[14:37] <rtg> amitk: :) I can beat that by 15 minutes.
[14:38] <cooloney> amitk, rtg are you talking about cross-compiling babbage kernel on x86 machine?
[14:38] <amitk> rtg: showoff!
[14:38] <amitk> cooloney: yes
[14:38] <rtg> cooloney: dual quad core w/18GB RAM.
[14:39] <bradF> cooloney: that's how I am building my kernels
[14:40] <bradF> cooloney: rtg likes to brag :-)
[14:40] <cooloney> rtg, really cool
[14:40] <cooloney> bradF, lol
[14:40] <cooloney> guys, let me test on my side
[14:40]  * rtg thinks bradf has computer envy.
[14:40] <amitk> cooloney: you were _not_ cross-compiling until now?
[14:41] <bradF> rtg feels sad for rtg
[14:41] <cooloney> i always cross built
[14:41]  * bradF feels sad for rtg
[14:41] <cooloney> but dont know the time
[14:41] <rtg> amitk: that was the whole point of this discussion, e.g., I noticed that he booted a cross compiled kernel.
[14:41] <cooloney> hehe, let me collect the timing info
[14:42] <amitk> right...
[14:43] <bradF> amitk: what's the word on the 'securityfs' for AA? should I chase that?
[14:44] <bradF> amitk: just saw your email...will try it
[14:45] <rtg> is there still an AA upstream to send it to ?
[14:45] <amitk> bradF: it certainly seems worth a shot to see if enabling securityfs is all thats needed. Though I vaguely recall having tried that.
[14:46] <amitk> rtg: If there isn't, then what're we doing carrying around that patch and letting it bitrot?
[14:46] <rtg> amitk: Its a topic for UDS, but I'm thinking this is the last release with AA.
[14:47] <amitk> interesting
[14:48] <cooloney> can i reproduce this bug on my side?
[14:48] <cooloney> if bradF needs help, i can join in
[14:48] <bradF> cooloney: are you talking about the apparmor bug?
[14:48] <cooloney> right
[14:48] <cooloney> AA = apparmor, if i am not wrong?
[14:48] <rtg> cooloney: correct
[14:49] <bradF> it's easy to repro, just go into your config and change the CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE from 0 to 1
[14:49] <bradF> cooloney: then if you don't have my patch, it will oops
[14:50] <rtg> bradF: with your latest patch (which I have not applied), how does it behave? Just the usual VFS can't find root halt?
[14:50] <cooloney> ok, booting oops?
[14:50] <bradF> cooloney: yes, booting oops, every time
[14:51] <cooloney> great, i will try
[14:59] <bradF> rtg: yes on "can't find root"
[15:00] <cooloney> cross-compiling imx51 deb package on my side nees 13m
[15:00] <rtg> bradF: so, we're just trading on oops for another? albeit a bit more understandable.
[15:00] <rtg> one*
[15:00] <bradF> rtg: going to hook up a rootfs and see if it comes all the way up (looks like cooloney will probably try this as well)
[15:01] <bradF> rtg: are you talking about the securityfs?
[15:01] <rtg> bradF: yes
[15:01] <cooloney> bradF, yes, i plan to do it. but it seems that it will take too much time to build a root fs on my side
[15:02] <amitk> rtg: if AA truly needs securityfs, then it should be a autoselected dependency
[15:02] <bradF> rtg: the missing securityfs doesn't cause an oops, just that AA is not doing anything
[15:03] <rtg> bradF: ok, thats what I wanted to know. With the patch you can boot a rootfs, but without AA support, correct?
[15:03] <bradF> rtg: let me run a couple of tests, but yes that is what I believe
[15:04] <rtg> bradF: ok, when you're comfortable send me a pull request.
[15:06] <bradF> rtg: will do
[15:07] <bradF> amitk: i understand your point and depending on my testing my submit another patch
[15:07] <bradF> s/my/may/
[15:07] <amitk> bradF: sure, take your time.
[15:08] <charlie-tca> I downloaded today's images, they passed md5sums. I burned the Xubuntu jaunty-alternate-i386.iso to a cd-r. It passes the cd integrity check with no errors. I attempt to install to a hardware system. It fails with
[15:08] <charlie-tca> Warning: file:///cdrom/pool/main/x/xkeyboard-config/xkb-data_1.5-2ubuntu9_all.deb was corrupt
[15:09] <charlie-tca> (I burned another cd-r that works) Should I report this as a bug?
[15:09] <amitk> charlie-tca: this is best reported on #ubuntu-devel
[15:09] <charlie-tca> Okay, thanks
[15:11] <bradF> amitk: the kernel I just booted with the securityfs enabled seems to be working!
[15:11] <amitk> interesting
[15:12] <amitk> so it _is_ a dependency
[15:12] <bradF> amitk: [42949373.670000] AppArmor: AppArmor Filesystem Enabled
[15:12] <bradF> amitk: yup
[15:12] <rtg> bradF: so I should expect some config changes along with the oops prevention?
[15:14] <bradF> rtg: they are independent of each other but the config change is necessary to run AA on imx51 (and all other flavours)
[15:14] <apw> the oops prevention is moot if its a dependancy and so recorded in the config
[15:15] <amitk> bradF: this kernel is w/o your oops prevention patch?
[15:15] <bradF> amitk: it has both
[15:15] <bradF> amitk: however, it should work without my oops patch, will test
[15:15] <rtg> bradF: see if it works with just the config change
[15:15] <amitk> bradF: yeah, that would be interesting
[15:16] <bradF> apw: I see your point
[15:16] <apw> it does sounds like an unrecorded interdependancy to me
[15:18] <amitk> though the oops prevention is what triggered the securityfs config light-bulb if I understood bradF correctly.
[15:18] <bradF> apw: it still seems like it should handle a missing securityfs a little better than an oops
[15:18] <bradF> amitk: yes
[15:18] <apw> bradF, not if its a depanancy, it should just be linked in the Kconfig magic
[15:19] <apw> and then become impossible to enable without the securityfs enabled
[15:29] <cooloney> bradF, is this boot oops?
[15:29] <cooloney> [42949373.670000] AppArmor: Error creating AppArmor securityfs
[15:29] <cooloney> [42949373.700000] AppArmor: AppArmor protection removed
[15:30] <bradF> cooloney: after that you should get am actual oops and a backtrace
[15:30] <cooloney> bradF, right, i reproduce it
[15:31] <cooloney> thx
[15:31] <bradF> cooloney: http://pastebin.ubuntu.com/136819/
[15:35] <bradF> cooloney: it looks like you just need to enable the security fs and you don't need the patch I put out
[15:36] <cooloney> bradF, thx, i can test your method on my side
[15:43] <apw> cking, any idea waht a bcdDevice means in the context of usb?
[15:43] <Keybuk> apw: device id in binary coded decimal
[15:44] <Keybuk> USB is *all about* bcd
[15:44] <apw> hrm, so something above and beyond its normal id's
[15:44] <apw>   idVendor           0x04ce ScanLogic Corp.
[15:44] <apw>   idProduct          0x0002 SL11R-IDE IDE Bridge
[15:44] <apw>   bcdDevice            0.78
[15:44] <apw> so that is a triplet in usb land?
[15:45] <Keybuk> i think so yea
[15:45] <Keybuk> it's basically the version number
[15:46] <_ruben> hmm .. recompiling kernel is taking up a fair amount of cpu sys % .. i'd expect just usr .. then again, havent rebuilt kernels in ages :p
[15:46]  * apw learns yet another new thing today
[15:46] <cooloney> apw, IMO, it is right,
[15:46] <cooloney> idVendor           0x05ac Apple, Inc.
[15:46] <cooloney>   idProduct          0x8242
[15:46] <cooloney>   bcdDevice            0.16
[15:47] <apw> Keybuk, any  idea what waht base the output is in
[15:47] <apw> is it decimal, or hex or?
[15:47] <cooloney> it is just a version number as Keybuk said
[15:47] <apw> right but the output of the lsusb command what base is it in there
[15:48] <cooloney> yes, lsusb will convert the binary code to such version number
[15:48] <IntuitiveNipple> apw: decimal
[15:48] <Keybuk> apw: binary coded decimal
[15:48] <cooloney> it should be 0x1600
[15:49] <cooloney> right?
[15:49] <Keybuk> http://en.wikipedia.org/wiki/Binary-coded_decimal
[15:49] <apw> hrm, i see, so its literally in hex in some sense
[15:49] <Keybuk> right you literally read the hex
[15:49] <Keybuk> 0110 is read is 1.10
[15:50] <Keybuk> 0206 is 2.06
[15:50] <Keybuk> etc.
[15:50] <apw> ok, so yeah bcd is hex format but you arn't allowed to use some of the combos
[15:50] <apw> thanks
[15:50]  * apw puts USB on his idiot idea list
[15:51] <rtg> IntuitiveNipple: I'm just looking at your RCU backport. Is that patch in response to smb_tp's RFC on boot pauses?
[15:52] <Keybuk> apw: USB is great!
[15:52] <Keybuk> it's ALL about the ids ;)
[15:52] <Keybuk> every gadget has a vendor and a product id
[15:52] <cooloney> Keybuk, really, it should be 1.10 = 1001
[15:52] <Keybuk> and a device version number
[15:52]  * apw slaps Keybuk ... get a grip man :)
[15:53] <Keybuk> and each device may have multiple configurations
[15:53] <cooloney> 2.06 = 0602
[15:53] <apw> cooloney, that _all_ depends on your endiannes
[15:53] <IntuitiveNipple> rtg: Yes, it is backported from the upstream commit
[15:53] <Keybuk> depending on the configurations, you then have multiple interfaces
[15:53] <cooloney> apw, for usb it should be lsb little endian
[15:54] <rtg> IntuitiveNipple: I got that part. I was wondering _why_ you did the backport.
[15:54] <Keybuk> and only then do you actually find out what the device *is* :p
[15:54] <Keybuk> cooloney: err, is it?
[15:55] <Keybuk> I'm pretty sure it's big endian
[15:55] <IntuitiveNipple> rtg: Ingo Monar in the upstream bug thought the commit may solve the issue, so I figured we should try it against our tree
[15:55] <IntuitiveNipple> s/Monar/Molnar/
[15:55] <apw> the kernel is behaving as if 0074 -> 0.74
[15:56] <rtg> IntuitiveNipple: is there a repeatable test case that you know of?
[15:56] <sconklin> maria/join #ubuntu-meeting
[15:56] <cooloney> idVendor           0x1d6b Linux Foundation
[15:56] <cooloney>   idProduct          0x0002 2.0 root hub
[15:56] <cooloney>   bcdDevice            2.06
[15:57] <cooloney> 0x002 = 2.0
[15:57] <Keybuk> cooloney: right, and if you cat the usb device's bcdDevice
[15:57] <IntuitiveNipple> rtg: No - I was waiting for Stefan to produce some test kernels for the users reporting on the bug
[15:57] <Keybuk> you'll see 0206 in there
[15:57] <Keybuk> 0206 -> 2.06
[15:57] <rtg> IntuitiveNipple: ok, I'll annoy smb_tp
[15:57] <IntuitiveNipple> rtg: :)
[15:58] <smb_tp> rtg, I am not listening
[15:58] <Keybuk> idVendor and idProduct are 32-bit words
[15:58] <BUGabundo> hi
[15:58] <Keybuk> idVendor assigned by a central naming authority
[15:58] <Keybuk> idProduct assigned by the vendor
[15:58] <rtg> smb_tp: take your hands off your ears, I can't hear you.
[15:58] <Keybuk> then for each product, you have a bcdDevice which supplies its version number
[15:58] <BUGabundo> 6 out of 10 resumes my laptop gets so slow that I'm required to reboot it
[15:58] <Keybuk> err 16-bit words
[15:58] <BUGabundo> how can I debug this?
[15:58] <smb_tp> rtg, Huh?
[15:59] <Keybuk> bcdDevice is 4 4-bit bcd numbers, representing the version number of the device
[15:59] <BUGabundo> I noticed that setting cpu to performance "fixes" this
[15:59] <rtg> smb_tp: kind of wrecks your mind, huh?
[15:59] <BUGabundo> but once I set it back to OnDemand slowness returns
[15:59] <cooloney> Keybuk, but we should firstly receive lsb until msb
[16:00] <Keybuk> cooloney: ?
[16:00] <smb_tp> rtg, Not _that_. But to answer, yeah aÍ wanted to do that, I'll write it down to remember as soon as I am finished with what I am doing right now
[16:00] <cooloney> Keybuk, first receiv 06 then 02 for 2.06 bcdDevice
[16:01] <rtg> smb_tp: k, just note that the window for Jaunty is closing.
[16:01] <Keybuk> cooloney: why?
[16:01] <BUGabundo> ok, you guy are busy... I'll come back latter
[16:02] <smb_tp> rtg, yeah, I hope I am done with that stupid thing in a little
[16:02] <cooloney> Keybuk, usb device should send out 06 firstly then 02
[16:06] <Keybuk> cooloney: err, why?
[16:08] <IntuitiveNipple> Spec 8.1 Byte-order is LSb
[16:08] <Keybuk> bcdDevice is not specified as a byte
[16:09] <Keybuk> the things specified as a byte are the ones beginning b, like bNumInterfaces
[16:09] <cooloney> Keybuk, you are right, i confused bcdDevice with some values like wLength
[16:09] <Keybuk> the entire bcd field is sent in reverse, yes
[16:09] <Keybuk> but as one unit
[16:09] <cooloney> right,
[16:11] <Keybuk> wLength is a word, so that entire word would be sent in reverse
[16:11] <Keybuk> not each individual byte
[16:11] <cooloney> exactly, cause i met a bug before which took me last of time
[16:11] <cooloney> right, for wLength we need so le16 helper function to get their value
[16:11] <cooloney> s/so/some
[16:11] <Keybuk> (I could be massively wrong, but I'm fairly sure I'm not :p)
[16:11] <cooloney> Keybuk, you're right on bcdDevice
[16:12] <IntuitiveNipple> all bits and fields are sent least-significant _bit_ first according to the spec
[16:12] <Keybuk> right, it's a serial bus ;)
[16:12] <IntuitiveNipple> multi-byte packets travel LSB wise
[16:13] <IntuitiveNipple> s/packets/fields/
[16:13] <Keybuk> LSB or LSb? :p
[16:14] <cooloney> 0x00, 0x02, /*  __le16 bcdUSB; v2.0 */
[16:14] <cooloney> we need set lower byte to 0x00 and higher one to 0x02
[16:14] <IntuitiveNipple> both... bits are LSb fields are LSB
[16:15] <cooloney> when we initialize a usb2_rh_dev_descriptor in drivers/usb/hcd.c
[16:15] <cooloney> right
[16:15] <cooloney> IntuitiveNipple, right
[16:16] <cooloney> wLength  = le16_to_cpu (cmd->wLength);
[16:19] <cooloney> we need le16_to_cpu for word value,
[16:19] <cooloney> drivers/usb/core/hcd.c:	0x00, 0x02, /*  __le16 bcdUSB; v2.0 */
[16:19] <cooloney> drivers/usb/core/devices.c:	u16 bcdUSB = le16_to_cpu(desc->bcdUSB);
[16:22] <Keybuk> that could be the HCI bit
[16:22] <Keybuk> it all gets complicated ;)
[16:22] <Keybuk> bus sends it one way, the host in the computer turns that around and sets it another way, but then the CPU in the computer turns it around and sends it yet another
[16:24] <cooloney> i think we just need take care of those 16bits field in usb descriptor structures.
[16:25] <cooloney> usb le16_to_cpu to help us out
[16:25] <cooloney> s/usb/use
[16:25] <Keybuk> depends where in the kernel you're looking
[16:26] <Keybuk> everything above the hcd uses CPU ordering, I think
[16:26] <Keybuk> so bcdDevice=0x0110 -> 1.10
[16:26] <Keybuk> might be wrong on that one
[16:27] <Keybuk> the hcd spec might end up needed that as Intel-CPU ordering (since Intel wrote it :p)
[16:28] <Keybuk> so that becomes 0x10, 0x01  (0001 0000, 0000 0001)
[16:28] <Keybuk> but then the bus spec says the entire field is LSB, so over the wire it's 0000 1000 1000 0000 I thijnk
[16:28] <Keybuk> feel free to go mad any point
[16:29] <cooloney> i guess so,
[16:30] <cooloney> hcd is a driver which should take care of this order
[16:30] <Keybuk> (bearing in mind of course that on an Intel machine, bcdDevice=0x0110 ends up as 0x10, 0x01 in memory *but* 0x01, 0x10 in memory on something MSB)
[16:30] <cooloney> but the order from usb hardware controller should be fixed as spec said
[16:31] <Keybuk> the kernel doesn't talk to such a device
[16:31] <Keybuk> the kernel talks to the Host Controller
[16:31] <Keybuk> which is a different spec
[16:31] <Keybuk> the host controller does the wire stuff
[16:31] <cooloney> right, host controler is a hardware which take case of the data transfer
[16:31] <Keybuk> anyway, if there was an original question here, we've strayed a long way from an answer to it ;)
[16:32] <cooloney> but hcd is host controller driver which is a software driver in kernel to handle that data from hardware
[16:32] <cooloney> yes,
[16:32] <cooloney> but i do like to discuss something with you guys here
[16:32] <Keybuk> no, the host controller is the pci device
[16:32] <Keybuk> the host controller driver talks to the host controller
[16:33] <Keybuk> the host controller talks to the hardware
[16:33] <cooloney> oh, pci stuff is in pc domain
[16:33] <cooloney> if in SOC like iMX51, the usb host controller is directly memory mapped
[16:34] <cooloney> hcd controls it directly.
[16:34] <Keybuk> sure, but they talk the hcd protocol, not the usb protocol
[16:34] <Keybuk> so you'd have to pick up the xhci, ehci, ohci or uhci spec and see what that says for data transfer ;)
[16:34] <Keybuk> if mucking around with the hcd driver
[16:35] <Keybuk> everything about the hcd driver, ie. when writing usb drivers, just do what the Linux kernel docs say
[16:35] <cooloney> right,
[16:37] <cooloney> for imx51 or other soc, the usb host controller does not support ehci/ohci/uhci
[16:37] <Keybuk> it doesn't?
[16:37] <cooloney> they use their own register layout and need a new driver
[16:37] <cooloney> drivers/usb/musb
[16:37] <cooloney> it is a usb driver for Davinci/omap/Blackfin
[16:37] <cooloney> mentor graphic ip
[16:37] <Keybuk> it at least vaguely pretends to be ehci
[16:38] <Keybuk> not that I can get my imx51 to boot today
[16:39] <cooloney> oh, imx51 does includes EHCI host and USB OTG from ARC
[16:39] <cooloney> the host mode driver in USB OTG should not be EHCI
[16:44] <Keybuk> oh yeah, I remember why I hate this thing
[16:44] <cooloney> usb is always my headache.
[16:44] <cooloney> -:))
[16:45] <cooloney> especially in embedded world
[16:47] <Keybuk> yeah, this has that silly fsl-ehci thing that's a platform device
[16:53] <cooloney> Keybuk, sorry, my mistake
[16:53] <cooloney> the USB OTG of imx51 also supports EHCI
[16:54] <cooloney> drivers/usb/host/ehci-arc.c
[16:54] <cooloney> drivers/usb/host/ehci-fsl.c is for the EHCI host
[19:21] <Turl> hi
[19:21] <Turl> can you suggest any other information for https://bugs.launchpad.net/bugs/348093 ?
[19:21] <ubot3> Malone bug 348093 in linux "Brightness keys ACPI events are not translated to keycodes" [Undecided,New]
[19:22] <Turl> (and confirm & set priority maybe?)
[21:44] <sourcemaker> are there known problems with the 2.6.29 kernel?
[22:13] <Kano> hi rtg , could you fix at least the linux-headers package when you dont add my aufs fix?
[22:13] <Kano> there are some missing files
[22:14] <Kano> acpi/acpica/ dir is missing
[22:15] <Kano> there are 3 headers in it
[22:18] <Kano> well there are more, but fglrx needs 3
[22:18] <Kano> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-karmic.git;a=tree;f=include/acpi;h=5ef3a2cd591223bf069be60037f2c576023752aa;hb=HEAD
[22:18] <Kano> this is not in the headers