[00:00] <asac> e.g. how many alternative locations are managed by gnash etc. ;)
[00:00] <asac> anyway ... out.
[00:00] <asac> we can talk more on this if you need info
[00:01] <bdrung> the alternative system is not pretty (too many symlinks)
[00:01] <bdrung> asac: what do you think about a helper tool for installing the plugins?
[00:03] <asac> nice to have imo
[00:04] <asac> its kinda painful to ensure that all the plugins have all the right install/alternative locations
[00:04] <asac> and it would also allow us to deviate locations from debian more easily (if that ever would be needed)
[00:04] <asac> bdrung: the alternative system is bad as it doesnt allow user choice ;)
[00:05] <asac> especially for a non-admin centric ubuntu approach
[00:05] <asac> we could have a new alternative system that also allows users to do that in $HOME/bin ;)
[00:05] <asac> j.k.
[00:06] <bdrung> asac: i have a plan: let's change the install location back to /usr/share/ubufox (one line SRU) and work on a helper script for maverick to ease the plugin installation (not SRU-able)
[00:06] <asac> hmm
[00:06] <asac> you think thats going to fly?
[00:06] <asac> sounds good if someone excepts that ;)
[00:06] <asac> accept ... man i am typomaniac
[00:06] <DASPRiD> nini plushies!
[00:07] <bdrung> asac: who needs to accept what?
[00:07] <asac> bdrung: SRU team ;)
[00:08] <asac> needs to buy into a fh shuffle ;)
[00:08] <asac> but i guess they will
[00:08] <bdrung> fh?
[00:08] <asac> hopefully noone has picked the new location up yet and changed their packages etc ;)
[00:08] <asac> filesystem hierarchy
[00:08] <asac> e.g. like me who just created one that relies on the new location :-P
[00:09] <bdrung> that show that we need the helper script
[00:09] <bdrung> :P
[00:11] <asac> bdrung: well. this time its not a plugin, but a preference ;)
[00:11] <asac> defaults/preferences is also a potential hook dir
[00:11] <asac> but i think we can ignore that
[00:11] <asac> maybe we should rethink the concept of where what prefs are shipped
[00:11] <asac> and make all prefs from all firefox apps and extensions go into the same directory or directory tree
[00:12] <asac> so yeah. lets SRU this
[00:12] <asac> i will open a bug for you or maybe we should ruse the plugin alternative wizar doesnt work bug
[00:13] <asac> which i thought was just the db i wanted to update today/tomorrow
[00:31] <bdrung> asac: here is the proposed diff: http://pastebin.com/YJftRztX
[00:35] <micahg> chrisccoulson: so, do you just want to drop it then?
[00:36] <micahg> bdrung: didn't we discuss something for plugins similar to install-xpi?
[00:36] <bdrung> micahg: yes
[00:38] <bdrung> bug #516350 filed by you :)
[00:39]  * micahg agrees alternatives should die
[00:41] <asac> ccheney: chrisccoulson: whats the status on epiphany? ;)
[00:41] <asac> was the ball dropped again after we last talked?
[00:42] <chrisccoulson> asac - i'm working on that now
[00:42] <micahg> asac: after I apply chrisccoulson's fontconfig fix, and upload to firefox-stable hardy and it builds, firefox 3.6 should be good to backport
[00:43] <asac> micahg: great.
[00:44] <asac> micahg: is the porting table on xulrunner-list up-to-date?
[00:44] <asac> chrisccoulson: ok cool. what approach are you taking?
[00:44] <micahg> asac: the insecure one is, I'm getting back to that tonight
[00:44] <asac> ok
[00:45] <bdrung> asac: bug #516350 - i am not familiar with plugins. if you draft a way how a plugin should be installed, i can write a tool for it.
[00:45] <micahg> asac: BTW, seamonkey doesn't qualify for USNs, right, so would we use -security PPA for it?
[00:45] <asac> micahg: we use the -security PPA for it and try to gather testing. why not ;)
[00:45] <asac> but yeah. no USNs because its universe
[00:45] <asac> though security team review/push is needed
[00:46] <bdrung> micahg: btw, xul-plugin is the wrong name (see debian-devel ML)
[00:46] <micahg> asac: k, because they're targeting next week for 2.0.5, which I don't get since it's before 3.6.4 and 3.5.10
[00:46] <asac> micahg: i would think its probably late one minor cycle
[00:47] <chrisccoulson> asac - for the GtkEntry, we need to take the approach of copying the classes over (GtkEntry, GtkEntryBuffer and GtkEntryCompletion), but I can also remove some of the things that have already been copied over, by taking the approach of reverting some of the changes that pull in the new dependencies
[00:47] <asac> so equiv of 5.9 ... or are they saying the release .10 xulrunner?
[00:47] <micahg> asac: equiv of .10
[00:47] <chrisccoulson> eg, we pull in part of GtkStatusIcon because epiphany has been ported to non-deprecated API, but there's no need to do that in hardy
[00:47] <asac> chrisccoulson: very good ;)
[00:47] <micahg> asac: I'll check with them as that seems weird, the past few releases have been at the same time
[00:48] <asac> chrisccoulson: have you checked whether pulling in GtkEntry ... etc. will close the loop?
[00:48] <asac> or are you reverting parts of that?
[00:48] <chrisccoulson> asac - and, i think there's a few other things like that (such as gtk_show_url, which also requires us to pull in some gdk bits too)
[00:48] <bdrung> are you guys aware of this poll: http://www.doodle.com/guafbbhipwskzr8a
[00:49] <chrisccoulson> asac - i will find out next time i try to build it (tomorrow hopefully)
[00:49] <asac> bdrung: maybe that should be a UDS mini spec or something ;)
[00:49] <micahg> chrisccoulson: someone provided most of a patch for mediatomb, should we do one more upload for js support or SRU?
[00:49] <chrisccoulson> micahg - i'm not sure, i've not reviewed it yet
[00:49] <bdrung> asac: the poll? isn't that a little bit overkill?
[00:50] <micahg> chrisccoulson: I didn't test it either yet
[00:50] <asac> bdrung: plugin install for devsripts ;)
[00:50] <bdrung> asac: aha. yes, +1 for UDS
[00:50] <micahg> asac: is the mozilla version picker worth a UDS spec?
[00:51] <asac> chrisccoulson: i really think what ccheney did should have been really close. some cleanup is good, but we should finally get it to a "tesable" state
[00:51] <asac> chrisccoulson: who knows what copy bugs were introduced ;)
[00:51] <chrisccoulson> asac - it was in a buildable state, but very crashy ;)
[00:51] <asac> micahg: what is a mozilla version picker?
[00:51] <asac> chrisccoulson: yes. hopefully because of the GtkEntry thing
[00:51] <micahg> asac: remember we discussed a tool to select and enable PPAs depending on whether someone wanted daily/beta/stable
[00:52] <asac> chrisccoulson: did you see other crashes too ;)?
[00:52] <asac> i was only shown that Entry crash ;)
[00:52] <chrisccoulson> asac - i saw 2 different crashes as soon as i started using it
[00:52] <chrisccoulson> one was the GtkEntry crash, and i also saw an unhandled X error too
[00:54] <asac> ugh. ok
[00:55] <micahg> chrisccoulson: BTW, I'll keep trying tonight to get seamonkey approved
[00:55] <chrisccoulson> micahg - thanks
[00:55] <asac> approved?
[00:55] <micahg> asac: in queue
[00:55] <asac> you should get it in now ... its really getting super late
[00:56] <chrisccoulson> asac - i uploaded it earlier in the day, but nobody has approved it yet
[00:56] <micahg> asac: I've already pinged people on the release team, but will keep trying as I see them this eveninig
[00:56] <asac> chrisccoulson: at this time you need to actively go and beg ;)
[00:56] <asac> at least thats the only way you know they will take a serious look
[00:57] <asac> micahg: scottk is gone?
[00:57] <asac> thats bad ;)
[00:57] <asac> whoelse is from release team for universe?
[00:58] <micahg> asac: anyone on the team?
[00:58] <asac> well. some tend to do more universe than others. at least in the past
[00:58] <micahg> asac: k, I'll try the Chicago connection ;)
[01:00] <asac> micahg: was there a bug i was supposed to comment on? or was that just lightning?
[01:00] <micahg> asac: just lightning I think
[01:02] <asac> micahg: what is the testing status of that package? chrisccoulson confirmed? you confirmed? did you test mail etc.?
[01:02] <micahg> asac: which seamonkey, I tested the browser, that mail loaded, I guess I should have tested a little better
[01:03] <micahg> asac: had a few others test as well
[01:03] <asac> chrisccoulson: did you do more testing?
[01:03] <chrisccoulson> asac - i tested that i could send mail too
[01:05] <asac> heh
[01:05] <asac> ok
[01:06] <asac> ok i pinged scottk directly
[01:06] <asac> in -release
[01:06] <asac> he said he will be off for 9h which was 5h ago or something
[01:06]  * asac off
[01:06]  * micahg has been waiting in there for someone all day :)
[01:08] <micahg> chrisccoulson: did you want to file the drop bug for sunbird?
[01:08] <chrisccoulson> micahg - i will just talk to pitti in the morning, and will see how to go about it then
[01:09] <micahg> chrisccoulson: k, thanks
[02:13] <skierpage> Yo, any update on updating the thunderbird-3.1 packages in the PPA?  TB 3.1 beta has been out since March 10, PPA stuck at 2009-12-21.
[02:48] <ccheney> asac: sorry i was gone to dinner earlier, but it appears chrisccoulson filled you in better than i would have been able to anyway :)
[05:20] <micahg> chrisccoulson: firegpg has 155 installs for popcon in debian and 35 in Ubuntu for both xul-ext-firegpg and firegpg, should we drop this too?  I'm getting the FTBFS for xul192 fixed if you decide yes, it does need to be compiled
[05:24] <micahg> chrisccoulson: nevermind, I guess we should keep it and the FTBFS is getting fixed anyways
[07:48] <micahg> !apport > ddecator
[07:49] <ddecator> micahg: didn't do anything...
[07:50] <micahg> ddecator: wanted to give you the wiki page for apport as it's now disabled, so if you want a crash report, you should have people enable it one time
[07:51] <ddecator> micahg: yah, i just realized that today when i had to get a crash report myself. i'm guessing you saw the bug where i asked them to check /var/crash? that was because the bug started happening while apport was still enabled, so i thought there might be a crash log leftover from then
[07:51]  * micahg thinks he already gave you the apport crash text  :)
[07:51] <micahg> ddecator: yep
[07:51] <ddecator> micahg: you did, but i don't know if it generated a report or not, so i didn't close it and use the canned response =)
[07:51]  * ddecator thinks it probably did, but not sure
[08:06] <micahg> ddecator: about bug 569679, can you confirm if it happens when you launch Ubuntu One from another menu, from the command line, or when launching firefox in general
[08:07] <ddecator> micahg: haven't tested it yet. i was going to do more testing tonight, but i don't have time so i'll do it tomorrow night.
[08:08] <micahg> ddecator: k
[08:08] <ddecator> micahg: i talked to someone who works with u1 a lot and he said it might be due to a change in the way u1 handles creating an account, so i need to see if that's potentially what's going on
[08:09] <micahg> ddecator: yes, that's what I wanted to ascertain
[08:09] <micahg> that warning comes up if there's an existing lock in the profile
[08:09] <ddecator> micahg: yup, i plan on figuring that out tomorrow night
[08:09] <micahg> ddecator: thanks
[08:10] <ddecator> micahg: np =)
[08:34] <BUGabundo_remote> ping-pong, Moon-Sun \o/
[08:34] <BUGabundo_remote> fta no build of chromium ?
[08:37] <micahg> BUGabundo_remote: looks like they FTBFS
[08:40] <BUGabundo_remote> thought so micahg
[09:00] <fta2> BUGabundo_remote, i just fixed it
[09:01] <fta2> asac, which priority should i give to chromium for gnome-www-browser?
[09:01]  * micahg recalls asac wanting to get rid of alternatives :)
[09:05] <fta2> bug 571103
[09:06] <fta2> i already have x- set to 40
[09:07] <fta2> but epiphany uses 85 and is preferred
[09:08] <micahg> fta2: I think konqueror is set for 100, firefox is 40, you can't really have an alternatives war
[09:08]  * micahg recalls asac telling me this about a year ago
[09:14]  * micahg is off to sleep, good night
[09:14] <micahg> *morning
[09:14] <fta2> good night :)
[09:59] <chrisccoulson> yay, seamonkey is in \o/
[09:59] <chrisccoulson> micahg - thanks for fixinf firegpg too
[10:19] <fta2> asac, now that chromium is in debian, i have no idea how i'm supposed to work. we'll get it from the auto-merge pretty soon, trashing all my efforts
[10:31] <chrisccoulson> fta2 - can it not be blacklisted so that it doesn't auto-sync?
[10:32] <chrisccoulson> is the ubuntu packaging quite different to debian then?
[10:32] <asac> fta2: hmm
[10:32] <asac> fta2: in the past we used for non-default browser a higher than for the default browser
[10:32] <asac> so if ffox is 50 ... use 60
[10:35] <fta2> chrisccoulson, the problem is the debian package is based on my work, but i have no idea how to proceed now? who will prepare the releases, who will push, where, using which version number
[10:37] <asac> fta2: so Derevko is our debian guy now ... he made a branch that we can upload to debian
[10:37] <asac> then we initially sync and then only upload to debian
[10:37] <asac> so it syncs back (until import freeze tat is)
[10:37] <asac> however, i dont know if it will work because of the coreutils | ... build depends
[10:38] <asac> but we will see
[10:38] <fta2> well, his merge is still pending, and i just saw the ITP bug closed, so i'm lost
[10:49] <asac> fta2: huh?
[10:49] <asac> fta2: i think he maintains a .debian branch downstream from the main branch atm
[10:49] <asac> i think most stuff should be merged into our .head
[10:49] <asac> except the build depends i think
[10:50] <asac> http://ftp-master.debian.org/new.html
[10:50] <asac> its in ŃEW queue
[10:50] <asac> Maintainer: Debain Chromium Maintainers
[10:50] <asac> Derevko: ^^
[10:50] <asac> typo ;)
[10:50] <fta2> i think the dep is ok, it's coreutils >= 7.5 | ..
[10:51] <fta2> otoh, debhelper 7 is not
[10:51] <asac> fta2: yes. it works locally, but builders refuse
[10:51] <asac> to take the alternative
[10:51] <asac> for some reason
[10:51] <asac> fta2: i think he stopped using that
[10:51] <asac> at least he dropped compat 7
[10:51] <asac> in the last merge i saw
[10:53] <asac> i think https://code.edge.launchpad.net/~giuseppe-iuculano/chromium-browser/chromium-browser.iuculano is ment for merged into out package branch
[10:53] <asac> not sure why he keeps compat 7 in the .debian branch
[10:53] <asac> Derevko: ?
[10:53] <asac> lets wait till he is back
[10:53]  * asac has to run some errands
[11:50] <chrisccoulson> asac - did you see my message yesterday about bug 531882?
[11:52] <idrissdev> Hey all , is it possible to transform a firefox extension to a website
[11:52] <asac> chrisccoulson: yes. hmm.
[11:53] <asac> chrisccoulson: that needs an SRU against the ubuntu-artwork package
[11:53] <asac> basically the .css needs to get absolute paths
[11:53] <chrisccoulson> asac - so, there are 2 issues with the offline page:
[11:53] <asac> too bad this dropped off
[11:53] <asac> two?
[11:53] <chrisccoulson> yes, the css needs to be called with an absolute path
[11:53] <asac> right
[11:53] <asac> also in th e.css
[11:53] <asac> the image references etc.
[11:53] <chrisccoulson> and we need a small ubufox change to allow it to load the css (it's currently blocked by firefox security policy, in the about handler)
[11:53] <asac> i think i even had a patch for that ... not sure why i didnt upload :/
[11:53] <idrissdev> please  , is it possible to transform a firefox extension to a website
[11:54] <asac> most likely i was blocking on someone from the doc team
[11:54] <asac> idrissdev: that feels like an odd request ;)
[11:54] <asac> not sure how that would map
[11:54] <asac> you can print the install.rdf ;)
[11:55] <asac> chrisccoulson: hmm. let me think. have to ru nout  quick and get coffee ;)
[11:55] <chrisccoulson> asac - so, you can't think of any other way before i assign the bug to ubuntu-docs?
[11:55] <chrisccoulson> ok, no worries
[11:55] <asac> i know that i had it working ;)
[11:55] <asac> i remember having issues with security policy
[11:55] <asac> etc.
[11:55] <chrisccoulson> asac - the issue is that the flags for the protocol handler are URI_NORELATIVE and URI_DANGEROUS_TO_LOAD
[11:55] <chrisccoulson> (see https://developer.mozilla.org/en/nsIProtocolHandler)
[11:56] <chrisccoulson> but, ubufox can work around one of those flags, but the URI_NORELATIVE one will require a change to ubuntu-docs i think
[15:56] <micahg> nikolam: sorry, we fixed a few more bugs before we released the package, do you want me to backport what we did for lucid to hardy in my PPA?
[15:57] <nikolam> So you are saying that ppa is refreshed with new release?
[15:58] <nikolam> It would be nice to test it on Hardy too
[15:58] <nikolam> I will wet it on lucid today and see how it goes.
[15:59] <nikolam> I wasnt already because seems like newer version of vbox hilled my 9.10 install with dependable addons, so would need to reinstall 9.10
[15:59] <nikolam> and to get 10.04 and test it too
[16:00] <micahg> nikolam: not yet, only if you want it
[16:00] <nikolam> feel free to suggest testing steps for Sm. Think there is some page about that
[16:00] <nikolam> Would be great
[16:00] <micahg> I'll do it right now
[16:03] <chrisccoulson> asac - how do we handle things which need rebuild due to xulrunner security updates? do we do everything through -security?
[16:03] <chrisccoulson> gjs needs rebuilding for <IP_ADDRESS>
[16:03] <micahg> chrisccoulson: does gjs need a rebuild every update?
[16:03] <chrisccoulson> micahg - it does. it has a rpath to find libmozjs
[16:04] <micahg> chrisccoulson: can we fix that in an SRU?
[16:04] <micahg> chrisccoulson: is rpath compile time directory binding?
[16:04] <chrisccoulson> i'm not sure how fixable that is really, remembering that gjs in only a library. it might be possible to fix it in applications using gjs, by having a wrapper script with LD_LIBRARY_PATH set
[16:05] <chrisccoulson> the only thing using it currently is gnome-shell
[16:05] <chrisccoulson> i'm wondering if that might be the better way to do it
[16:05] <micahg> chrisccoulson: BTW, I suggested a wrapper for gxine, do you think that's a good idea
[16:05] <micahg> chrisccoulson: I would say yes :)
[16:05] <chrisccoulson> micahg - if it works, yes ;)
[16:05] <chrisccoulson> but i don't care too much for gxine ;)
[16:06] <micahg> chrisccoulson: someone does though (It got set to high :) )
[16:06] <chrisccoulson> heh
[16:06] <chrisccoulson> so, i'll look at doing a wrapper script in gnome-shell then and dropping the rpath in gjs
[16:06] <micahg> chrisccoulson: do you think a mozilla version picker (stable, daily, beta, latest stable) is worth discussion/possible session at UDS
[16:07] <chrisccoulson> then we'll just have to say "if you want to use gjs, you'll need to find libmozjs yourself"
[16:07] <chrisccoulson> micahg - possibly. did you have an implementation in mind at all (so i get an idea of what you'd want it to do)
[16:08] <micahg> chrisccoulson: this was discussed at the beginning of the lucid cycle but I don't think anyone had time, basically to use apt-pinning and the PPAs in a type of picker to determine which version of which mozilla app gets installed
[16:09] <chrisccoulson> yeah, that could be quite cool
[16:09] <micahg> chrisccoulson: should a file a blueprint and mark you approver?
[16:10] <chrisccoulson> yeah, can do. i'm not sure what my role is as approver just yet though, i'll have to speak to rick to find out ;)
[16:10] <chrisccoulson> i'm wondering if other teams might find such a tool useful too
[16:11] <chrisccoulson> perhaps something which isn't specific to just mozilla and could be extended
[16:11] <chrisccoulson> might be worth talking to mvo about that, in case something like that could be part of software-properties
[16:13] <micahg> chrisccoulson: seems like that would clutter software-properties, but maybe as an addon for it?
[16:13] <chrisccoulson> yeah, possibly
[16:14] <micahg> chrisccoulson: there's already a session about making daily builds more prolific
[16:15] <micahg> chrisccoulson: should I discuss with the people of that blueprint if they think a global picker is a good idea?
[16:16] <chrisccoulson> micahg - yeah, that would be good to do
[16:19] <micahg> chrisccoulson: I'm hoping the remaining 3 FTBFS xul apps we can SRU after they're fixed for maverick
[16:21] <chrisccoulson> micahg - yeah, should be fine. ftbfs applications are generally worth a SRU anyway
[16:22] <chrisccoulson> which apps are they btw?
[16:39] <micahg> chrisccoulson: 2 perl libs and pacparser
[16:39] <chrisccoulson> micahg - ok, the debian maintainer of pacparser mailed me privately asking why we don't have libmozjs as a system library any more
[16:40] <chrisccoulson> tbh, we probably should forget pacparser, as nothing in the archive uses it anyway
[16:40] <micahg> chrisccoulson: I'd suggest referring to 286906
[16:40] <micahg> bug 286906
[16:40] <chrisccoulson> micahg - yeah, i basically explained what is in that bug report
[16:49] <chrisccoulson> micahg - we should probably drop pacparser in maverick (it's getting a bit late in lucid to do that now)
[16:49] <micahg> chrisccoulson: I was going to ask you about that
[16:49] <chrisccoulson> but, if it doesn't build then the binaries will have already been removed anyway
[16:49] <chrisccoulson> so, that situation should be ok
[16:49] <chrisccoulson> i'll check if it was on slangasek's list of removed binaries
[16:50]  * micahg checks LP
[16:50] <chrisccoulson> hmmm, it's not on the list
[16:50] <micahg> chrisccoulson: no, I still see the binaries
[16:50] <chrisccoulson> i suppose i should just check the archive
[16:50] <chrisccoulson> ok, we should remove them then
[16:50] <micahg> chrisccoulson: did you talk to pitti about lightning?
[16:51] <chrisccoulson> micahg - it's gone already :)
[16:51] <micahg> chrisccoulson: k, good,
[16:51] <micahg> chrisccoulson: I suggest we add some release notes about lightning
[16:52] <chrisccoulson> if you think it's worth a release note, then feel free. do you know how to request a release note?
[16:53] <micahg> chrisccoulson: file a bug against the release notes project?
[16:53] <chrisccoulson> micahg - yeah, that's right
[16:53] <chrisccoulson> or add a release-notes task to an already open bug report
[16:53] <chrisccoulson> (probably the one requesting the lightning update)
[16:54] <micahg> chrisccoulson: do people do that?
[16:55] <chrisccoulson> micahg - yeah, i've done that in the past
[16:55] <micahg> chrisccoulson: k
[16:57] <micahg> chrisccoulson: done, requested a mention, do you need to ack?
[16:58] <micahg> chrisccoulson: BTW, should I take the gxine bug for SRU?
[16:59] <micahg> nikolam: builders were hijacked for release, so it'll be a while before it gets built
[16:59] <chrisccoulson> micahg - no, i don't need to do anything on the bug for the release note
[16:59] <chrisccoulson> yeah, we can do gxine as a SRU
[16:59] <chrisccoulson> micahg - bug 568778
[17:00] <chrisccoulson> so, the binaries are gone
[17:01] <chrisccoulson> i still think we should just drop it rather than fix it in a SRU. there's no point in us maintaining something using libmozjs when it's not used by anything else in the archive
[17:01] <micahg> chrisccoulson: k, good, wondering why doesn't show in publishing history
[17:01] <chrisccoulson> ah, that won't show in the publishing history if it's just the binaries
[17:01] <micahg> chrisccoulson: ah
[17:01] <chrisccoulson> all that has happened is the binaries were just deleted from the archive
[17:02] <micahg> chrisccoulson: I can still get the binaries for LP
[17:02] <micahg> *from
[17:02] <chrisccoulson> oh, that's probably expected
[17:02] <chrisccoulson> but they aren't available in the archive any more
[17:02] <chrisccoulson> http://archive.ubuntu.com/ubuntu/pool/universe/p/pacparser/
[17:03] <micahg> k
[17:17] <fta> anyone working with couchdb here?
[17:18] <fta> like with large volume of data
[17:19] <fta> rickspencer3, ^^ (iirc, you played with it, right?)
[17:20] <rickspencer3> fta, yes
[17:21] <fta> rickspencer3, how efficient is it?
[17:22] <rickspencer3> fta, depends on what you use it for
[17:22] <rickspencer3> and how
[17:22] <rickspencer3> couchdb is pretty quick once you've run a query a once
[17:22] <rickspencer3> so long as you store it
[17:22] <fta> i have ~1TB of data, and i need fast access
[17:22] <rickspencer3> if you craft a good query and run it
[17:23] <fta> so you're saying the 1st query is slow?
[17:23] <rickspencer3> the first time it runs will take a looong time
[17:23] <fta> hm
[17:23] <rickspencer3> because it will run the map function on each record and build a b-tree as it goes
[17:23] <rickspencer3> after that, it should be faster
[17:23] <rickspencer3> but I don't know if it will meet your perf. requirements
[17:25] <fta> my data is something like data[foo][bar][time] = { k1: v1, .... , k15: v15 }
[17:25] <fta> i know foo/bar and a range of time, and a subset of keys (like {k1, k3, k7})
[17:26] <fta> then i can reduce a bit based on time slots, or summing by foo/bar
[17:28] <fta> i have ~2k inserts per minute
[17:29] <fta> 24/7
[17:29] <fta> rickspencer3, ^^
[17:29] <rickspencer3> fta, well, I would try it on a subset of the data
[17:30] <rickspencer3> I don't know what you are trying to pull out, but if you can get a good map/reduce going, it could be quite efficient
[17:40] <fta> ok, thanks, i will experiment with it
[18:00] <Derevko> fta: asac: I forgot to revert the debhelper compat 7 commit, done and resubmitted the proposal to merge
[18:44] <pkramerruiz> Hi
[18:45] <pkramerruiz> Anyone there?
[18:45] <pkramerruiz> My name is Patrick
[18:46] <pkramerruiz> I write from Spain
[18:46] <pkramerruiz> I wanted to ask if anyone might explain me,  how I can make .deb packages from mozilla's xpi's for my launchpad repo
[18:55] <nikolam> pkramerruiz, I am not very skilled myself
[18:55] <nikolam> but you might take a look at this
[18:55] <nikolam> http://www.mozilla-enigmail.org/forum/viewtopic.php?f=12&t=598
[18:56] <nikolam> Its about making .xpi for enigmail for 64-bit seamonkey for Ubuntu
[18:56] <nikolam> If you make it, post it there , btw ;)
[18:56] <pkramerruiz> OMG! Many many thanks Nikolam
[18:58] <asac> pkramerruiz: talk to bdrung when he is back about how to make packages out of .xpi files
[18:58] <nikolam> that might be interesting for enigmail, too, yes
[18:59] <pkramerruiz> asac, thanks!
[18:59] <pkramerruiz> I write to you in german
[18:59] <pkramerruiz> at 19:09
[19:05] <asac> pkramerruiz: no time to answer ;) ... bdrung is better to answer that
[19:07] <asac_> pkramerruiz: we prefer not to communicate in public
[19:07] <asac_> err in private
[19:07] <asac_> unless its about secrets
[19:08] <asac_> pkramerruiz: read http://wiki.debian.org/mozilla-devscripts
[19:08] <asac_> to get started
[19:08] <pkramerruiz> okay
[19:08] <pkramerruiz> many thanks
[20:17] <micahg> pkramerruiz: does the eingmail build not work for Seamonkey in lucid?
[20:20] <pkramerruiz> @micahg: why are you asking me that? Who said that I would make an package for enigmail? I will create continuously the packages for all the addons I use in my firefox.
[20:20] <micahg> pkramerruiz: I thought I saw it being discussed in the backlog
[20:21] <micahg> ah, I misread, sorry
[20:21] <pkramerruiz> But I thougt this will only take me 5min (once I learnet it) from my free time. But nhandler said to me that this takes much more than 5min
[20:21] <pkramerruiz> and that's disgusting me a lot
[20:22] <micahg> pkramerruiz: https://wiki.ubuntu.com/Packaging/Training/Logs/2010-04-22
[20:22] <cwillu_at_work> who should I talk to if I can crash karmic's firefox consistently but slightly indeterministically with a webworker thread?
[20:23] <pkramerruiz> I thougt with http://wiki.debian.org/mozilla-devscripts it takes no more than a few minutes. But nhandler redirects me to: https://wiki.ubuntu.com/PackagingGuide/Complete and http://www.debian.org/doc/debian-policy/ .Beacuse he means that I will need all this for the other files of the package
[20:23] <micahg> pkramerruiz: yes, well, the extension install part is easy, the rest of the package might take a little bit
[20:25] <pkramerruiz> how much "little bit"?
[20:25] <micahg> pkramerruiz: idk, haven't tried, take a look at the link I gave you
[20:25] <micahg> pkramerruiz: bdrung would be the person to ask as he's done it before
[20:27] <pkramerruiz> but I dont wanna make a new package!
[20:27] <pkramerruiz> I only want to upload the new realease of an existing xpi package
[20:28] <micahg> pkramerruiz: is there a watch file?
[20:29] <pkramerruiz> I only want to regulary download the xpi from addons.mozilla.org and upload añthing to my repo
[20:29] <pkramerruiz> so that I can install these addons from the terminal/synaptic
[20:29] <micahg> pkramerruiz: well, you either have to create or update an existing package to do that
[20:30] <pkramerruiz> but I wont read 1000 manual pages, to only make this!
[20:30] <micahg> pkramerruiz: why not just use firefox's facility to install?
[20:30] <pkramerruiz> what do you mean with firefox facillity to install?
[20:31] <micahg> pkramerruiz: firefox can maintain and update the addons and they're self contained, why do you want to use synaptic?
[20:32] <pkramerruiz> because its posible that I reinstall my system or not?
[20:32] <micahg> pkramerruiz: have you considered mozilla weave
[20:32] <pkramerruiz> and I have an text file with programs like tomboy and rythmbox ... to purge on fisrt run and another with the programs I like to install
[20:33] <pkramerruiz> Like heikki said to me: it requires some work but this kind of policies make debian so high quality distribution
[20:33] <pkramerruiz> ;-)
[20:34] <micahg> pkramerruiz: if it's for others, I can understand, if it's just for you, why not make it easy on yourself
[20:35] <micahg> pkramerruiz: if you create an add-on collection on addons.mozilla.org, you can reinstall all your addons in one shot
[20:35] <pkramerruiz> okay, wait until I read what mozilla wave is
[20:35] <pkramerruiz> I dont know this until now
[20:35] <micahg> pkramerruiz: weave is basically an automated encrypted profile backup
[20:36] <pkramerruiz> and what good is that for me?
[20:36] <pkramerruiz> I cant install all these from the terminal or the synaptic, or can I?
[20:36] <micahg> pkramerruiz: once you set that up on a new system, everything is back the way you had it
[20:37] <micahg> pkramerruiz: well, I think we could consider packaging weave
[20:37] <pkramerruiz> hmmm
[20:37] <pkramerruiz> "once you set that up on a new system" set what up?
[20:38] <micahg> pkramerruiz: bug 246808 if you want to subscribe
[20:38] <micahg> pkramerruiz: weave
[20:39] <pkramerruiz> you mean: If I once set up wave on my running system, if I reinstall or want to have my personalized firefox on another machine I can have it?
[20:39] <micahg> pkramerruiz: correct
[20:40] <pkramerruiz> can you explain how it works and how to set it up? Becasue I really cant imagine that!
[20:41] <micahg> pkramerruiz: https://wiki.mozilla.org/Labs/Weave
[20:41] <pkramerruiz> you shoul know I have many many sources list for firefox on my sources.list
[20:41] <pkramerruiz> and nearly every day I update it
[20:42] <micahg> pkramerruiz: well, weave handles your profile and what you install through firefox
[20:42] <pkramerruiz> so, sometimes a message comes up, saying that an addon is no longer supported
[20:43] <micahg> pkramerruiz: ah, that's usually on major version upgrades and is less likely if you're using versions from addons.mozilla.org
[20:43] <pkramerruiz> and what is if I set it up with my 3.6.5pre and on the new system I have 3.5?? or 3.7?
[20:44] <micahg> pkramerruiz: 3.6.5pre is the daily build of the next minor release of 3.6 (3.6.4 is in the mozilla security PPA)
[20:45] <pkramerruiz> yes and then?
[20:45] <micahg> pkramerruiz: then what?
[20:45]  * micahg is missing something
[20:46] <pkramerruiz> what do you  want me to say?
[20:47] <pkramerruiz> micahg, do you want to see my sources.list? http://www.zumodrive.com/share/4ZuNYTU3Yj
[20:49] <pkramerruiz> got to: Related to Web Browser's
[20:49] <micahg> pkramerruiz: I don't suggest using this as it's a staging/testing PPA and stuff could be broken: http://ppa.launchpad.net/mozillateam/ffox35/ubuntu
[20:50] <pkramerruiz> so, you can see I have 4 sorces for my firefox on karmic
[20:50] <pkramerruiz> what I am currently running
[20:53] <pkramerruiz> and I want to say micahg, that I dont have your ppa, because you only packaged up to firefox-3.0
[20:53] <pkramerruiz> so far I can see
[20:53] <micahg> pkramerruiz: my mozilla PPAs are for testing
[20:54] <pkramerruiz> This PPA contains patches that  I'm testing for Mozilla Products. USE AT YOUR OWN RISK These are test builds for patches and not guaranteed to be stable. These are not recommended for production use.
[20:54] <micahg> :)
[20:54] <pkramerruiz> dindnt you see how much experimental ppa's I have??
[20:54] <micahg> I try to warn people :)
[20:54] <pkramerruiz> Laughing out loud
[20:55]  * micahg forgot the original question
[21:15] <DASPRiD> micahg, try the alternative question
[21:15] <pkramerruiz> Laughing out loud
[21:53] <fta> asac, list of bugs holding M5 as stable for linux: http://code.google.com/p/chromium/issues/list?can=2&q=os:linux+mstone:5
[21:56] <ddecator> micahg: looks like it's a problem with u1. if i let the preferences sit open, then firefox eventually launches and brings me to the u1 sign-in site
[21:58] <micahg> ddecator: can you move to ubuntuone-client-gnome
[21:58] <micahg> oops
[21:58] <ddecator> micahg: unless it's related to the fact that -no-remote doesn't work?
[21:59] <micahg> ddecator: is it passing -no-remote?
[21:59] <ddecator> micahg: not sure, just a thought
[21:59] <ddecator> micahg: let me find out
[22:02] <micahg> fta: is chromium-daily supposed to have dropped 1.7MB?
[22:04] <fta> micahg, eh?
[22:04] <micahg> fta: install size
[22:04] <fta> which one?
[22:05] <micahg> from 5.0.389.0 to 5.0.391.0 it's dropping 1737kb install size
[22:07] <fta> hmm; the deb is sure smaller
[22:07] <fta> -rw-r--r-- 1 root root 12492296 2010-04-27 06:56 /var/cache/apt/archives/chromium-browser_5.0.389.0~svn20100427r45661-0ubuntu1~ucd1_i386.deb
[22:07] <fta> -rw-r--r-- 1 root root 11687112 2010-04-28 13:10 /var/cache/apt/archives/chromium-browser_5.0.391.0~svn20100428r45775-0ubuntu1~ucd2_i386.deb
[22:09] <fta> nope, same files
[22:09] <micahg> fta: did they add soemthing to the install?
[22:09] <fta> nope
[22:10] <micahg> fta: k, just thought I'd mention it to you
[22:12] <ddecator> micahg: i guess it uses xdg-open, which i'm not familiar with
[22:13] <fta> -rwxr-xr-x root/root  38001392 2010-04-27 06:34 ./usr/lib/chromium-browser/chromium-browser
[22:13] <fta> -rwxr-xr-x root/root  34978544 2010-04-28 12:46 ./usr/lib/chromium-browser/chromium-browser
[22:13] <fta> micahg, ^^ that's why
[22:14] <fta> 38MB -> 35MB
[22:16] <kaushal> hi
[22:16] <kaushal> I have Mozilla/5.0 (X11; U; Linux i686; en-US; rv:<IP_ADDRESS>) Gecko/20100408 Ubuntu/9.04 (jaunty) Firefox/3.6.3
[22:16] <kaushal> it crashes intermittently
[22:16] <kaushal> how do i fix the issue ?
[22:26] <kaushal> checking in again for my query ?
[22:33] <micahg> a >30MB binary?
[22:33] <micahg> fta: ^^^ that would explain why it's so fast
[22:34] <fta> static libs
[22:35] <fta> upstream says shared build is slower, redhat/fedora disagrees
[22:36] <fta> i've experimented a bit but decided to stick with upstream's choice on that
[22:36] <micahg> kaushal: idk, can you get a backtrace?
[22:36] <fta> ok, i'm off, bye
[22:36] <micahg> fta: night
[22:51] <ddecator> micahg: we think we figured out the issue.
[22:51] <micahg> ddecator: k
[22:53] <ddecator> micahg: when u1 opens for the first time, it opens FF so the user can create an account. however, when u1 launches firefox, there is a delay long enough that someone can easily launch FF themselves (either to browse the web, by clicking Manage Account, or w/e) but then the two conflict (usually the u1 launch wins because it was initiated first). it's easy for it to happen on the first run, but not sure there is a way to prevent it cons
[22:54] <micahg> ddecator: so it is a U1 issue
[22:54] <ddecator> micahg: depends how you look at it, but yes
[22:55] <micahg> ddecator: I look at it as whether or not I have to fix it ;)
[22:55] <ddecator> micahg: then no, at this point there is nothing for you to fix =p
[22:56] <micahg> ddecator: I would suggest moving the bug to ubuntuone-client and put all this in tehre
[22:56] <ddecator> micahg: unless you want to make FF launch fast enough that there is no time to open it again while it loads ;)
[22:56] <micahg> ddecator: wait for 3.7 :)
[22:57] <ddecator> micahg: heh, i'm using it right now. still starts up slow for me at this point..
[22:57] <micahg> ddecator: they have a few things in the pipeline to improve start time
[22:57] <ddecator> micahg: good to hear =)
[23:33] <kaushal> micahg: sorry was away
[23:33] <kaushal> how do i get a backtrace ?
[23:37] <kaushal> is the 3.6.3 version a stable release on Ubuntu 9.04 ?
[23:42] <BUGabundo> (2010-04-28 23:41:25) EddieRingle: honestly, Chromium needs to support mp4 playback
[23:42] <BUGabundo> fta: ^^^^
[23:43] <micahg> kaushal: yes
[23:43] <micahg> !backtrace > kaushal
[23:44] <rbz> anyone have any suggestions for cross-packaging ff-3.6.4 for armel? or do you all just build them on armel hosts?
[23:45] <micahg> rbz: there should be a build in the security PPA
[23:46] <micahg> rbz: we build on armel hosts for archive releases
[23:46] <rbz> I can currently cross build standalone mozilla-1.9.2 trees; but packing it your way cleaning is... well major voodoo :)
[23:47] <rbz> I have additional changes on top of 1.9.2
[23:47] <rbz> *packing->packaging
[23:47] <micahg> rbz: you can throw patches in debian/patches
[23:47] <rbz> right; my thought too
[23:47] <micahg> rbz: just make sure you disable the official branding
[23:47] <micahg> if it's published
[23:48] <rbz> but currently not doing builds on device; only cross
[23:48] <micahg> rbz: anything upstream would be interested in?
[23:48] <rbz> thinking maybe best path would to just get a netbook
[23:48] <rbz> eventually quite possible
[23:48] <rbz> maybe first to the moz tree
[23:48] <rbz> *netbook arm of course :)
[23:49] <micahg> rbz: well, all patches go to trunk first
[23:52] <rbz> but to confirm my original question; the armel builds ppa/release etc are done on armel hosts right? never cross?
[23:53] <micahg> rbz: correct
[23:53] <micahg> rbz: AFAIK, all archive builds are native
[23:54] <rbz> that what I thought... thx for the confirmation


[07:19] <DanaG> mountall: Plymouth command failed
[07:20] <DanaG> ... repeated about 1000 times.
[07:23] <amitk> DanaG: are you using LVM?
[07:23] <DanaG> Nope.
[07:23] <DanaG> And I do dislike how plymouth refuses to show splash if a serial console is present.
[07:23] <amitk> yeah, that is a known plymouth bug
[07:24] <amitk> I hate it too, first this I disable is plymouth
[07:24] <amitk> s/this/thing
[07:58] <hrw> morning
[08:01] <DanaG> Nice thing: watchdog.
[08:01] <DanaG> Makes it so that omapdss reboot crash makes it still reboot anyway, instead of just dying.
[08:13] <sveinse> I'm about to do some kernel debugging on ARM target. Do you know of an decent GUI for gdb (-arm) which can run on host?
[08:27] <saeed> ogra: ping
[08:27] <ogra> hey saeed
[08:28] <saeed> hey ogra
[08:28] <saeed> the uboot on dove takes too long time to read the kernel image and initrd
[08:29] <saeed> the uboot sata driver is optimized (using DMA, upt to 128 sectors requests)
[08:29] <ogra> hmm, sounds like a case for ericm and NCommander
[08:29] <saeed> it looks to me that for some reason those files are too mush scattered on the disk
[08:30] <ogra> which installer is that ? GUI or text mode ? (the files live in different subdirs in either one)
[08:30] <saeed> GUI
[08:30] <saeed> the files under /boot/ dir
[08:30] <ogra> so the live in /casper/uI*
[08:31] <ogra> no, the live installer holds uImage and uInitrd in the /casper dir
[08:31] <ogra> though i know NCommander worte a rather complex uboot script that scans all devices before loading, do you install from USB or SD card ?
[08:32] <ogra> i think USB is scanned first, so using that should speed up the probing
[08:32] <saeed> I installed from USB
[08:33] <ogra> hmm, then the probing shouldnt have any effect i think
[08:33]  * ogra looks at the script
[08:34] <saeed> ogra: I problem that I notice is that when the script reads the images from the hdd, the read process takes too much time, maybe 10 seconds just to read ~3MB image
[08:35] <ogra> http://paste.ubuntu.com/420270/
[08:35] <ogra> hmm, the script seems to scan all devices regardless
[08:36] <saeed> right know I don't have a problem with the scan process of the uboot
[08:37] <saeed> the thing is that it takes too much time to read from sata hdd
[08:37] <ericm> saeed, still I guess it's a sata drive issue, as usb loading is pretty fast
[08:37] <ericm> either booting from /casper/ or any other image I wrote later to the USB disk
[08:37]  * ogra wonders where ${fs} ${interface} and ${device} come from for the first if in that script
[08:38] <ericm> I believe scatter status is no better from usb disk perspective
[08:38] <saeed> ericm: yes
[08:38] <ericm> maybe other part of u-boot introduces some delays?
[08:38] <saeed> I think also with ssd that won't be an issue
[08:38] <ogra> saeed, oh, you were talking about post-install ?
[08:38] <ogra> sorry, i didnt get that
[08:38] <saeed> ogra: yes
[08:39] <saeed> do you know about a method for allocating the kenrel and initrd images so they can be contiguous on the hard drive
[08:40] <ogra> oh, wait, the same script is used in inistalled systems
[08:40] <saeed> yes
[08:40]  * ogra looks at the flash-kernel source
[08:42] <ogra> and it definately initializes USB and IDE first, probes USB fat, then USB ext2 and only *then* switches to probe IDE fat and *last* it probes IDE ext2
[08:43] <ogra> imho the order is totally wrong here if we always expect the install to live on IDE ext2 it should be the other way round
[08:43] <ogra> so that gets probed first
[08:43] <ogra> have you monitored a boot in serial console to see what uboot actually does ?
[08:44] <ericm> ogra, saeed is seeking a way to contiguously write uImage and uInitrdto the hard drive
[08:44] <ogra> ericm, right, but still we use several seconds before the loading even starts
[08:44] <ericm> saeed, I guess the kernel strategy to write out a file (if not interrupted) is to write it as contiguously as possible
[08:45] <ericm> ogra, yeah - but that's something we can fix maybe, the loading speed of uImage/uInitrd binary - only Marvell can fix that :-)
[08:45] <ogra> its likely an additional issue i see here but it might cost valuable extra time in the boot
[08:45] <saeed> orga: yes ,I think the first "if" will be taken here
[08:46]  * ogra has no dove hardware to actually test or confirm anything sadly
[08:46] <saeed> ogra: see http://paste.ubuntu.com/420275/
[08:47] <ogra> yeah, line 1-41 are pointless on an installed system
[08:47] <ogra> (apart from initializing IDE actually)
[08:47] <ericm> saeed, the first part of the script is actually within u-boot
[08:47] <ericm> to look for a boot.scr
[08:48] <ogra> ericm, look at the paste
[08:48] <ogra> it scans everything before doing any load
[08:48] <ericm> ogra, yeah I'm looking
[08:48] <ericm> ogra, I guess we could move ide to first place as that's mostly used
[08:48] <saeed> ogra: why do you think the IDE is re-initialized?
[08:48] <ericm> installation is less frequently happening
[08:49] <saeed> ogra: are you talking about installation process?
[08:50] <ogra> saeed, no, about your serial capture
[08:51] <ogra> saeed, line 18-41 in your paste clearly show that the full script is executed before anything gets loaded at all
[08:51] <ogra> ericm, there is no difference between the installation boot.scr and the boot.scr after installation, they are identical
[08:52] <saeed> ogra: this the uboot default boot command
[08:52] <ogra> which costs a lot of extra scan time for nonexisting USB
[08:52] <ericm> ogra, I'm not talking about the installation boot.scr, I mean the u-boot builtin boot.scr
[08:52] <ogra> ericm, they appear to be identical
[08:53] <ericm> ogra, right so the improvement can be done to both version
[08:53] <ogra> the builtin boot.scr should bail out the moment it doesnt find USB
[08:53] <ogra> (as the installation one should)
[08:53] <ericm> ogra, right - and the builtin boot.scr should scan ide first as that's more commonly used
[08:53] <ogra> instead of trying to probe vfat and then ext2 additionally
[08:54] <ogra> ericm, no, then you cant install
[08:54] <ericm> ogra, ah well - that's the problem
[08:54] <ogra> it *should* check for USB ... but if it doesnt find a device it shouldnt try to fatload/ext2load
[08:54]  * ericm feels stumped
[08:54] <ericm> ogra, that's correct
[08:54] <ogra> currently it goes on trying to load stuff from a nonexisting device
[08:55] <ogra> which is nonsense and wastes a lot of time
[08:56] <saeed> ogra: if you need the uboot from usb disk if connected, then the flow is ok
[08:56] <ogra> saeed, it shouldnt try to load if there is no device
[08:57] <saeed> ogra: but maybe the sata disk connected, and it have proken kernel
[08:57] <saeed> broken
[08:57] <ericm> saeed, which means if "usb reset" returns failure, "fatload/ext2load" can be skipped
[08:58] <saeed> ericm: does usb reset fails if no usb device is connected?
[08:58] <ericm> ogra, ah - it seems fatload/ext2load combines the probing and reading all together unless you have a way to separate them into two commands
[08:58] <ogra> yes
[08:58] <ericm> saeed, nope
[08:58] <ogra> (though its "usb start"
[08:58] <ericm> saeed, sorry I over looked
[08:59] <ericm> ogra, yeah it is usb start and it takes a lot time for unknown reason, ide reset is fast enough
[08:59] <ogra> you could have something like  "if usb start; fatload/ext2load .... fi"
[09:00] <ogra> so it will not try to load if there is no usb device
[09:00] <ericm> ogra, but we are not sure if the current implementation of "usb start" returns what
[09:00] <ogra> test it :)
[09:00] <ogra> (i dont have the HW )
[09:00] <ericm> ogra, hope it's returning the number of usb storage devices found
[09:01] <ogra> well, the hush shell "if" will look if it exits 0 or nonzero
[09:01] <ogra> no matter what it returns
[09:01] <ogra> if usb start; .... fi should work fine as a wrapper for the load commands here
[09:02] <ogra> the prob with the existing script is that it is one big loop
[09:02] <ogra> it should be split into multiple conditional loops instead
[09:02] <ericm> ogra, it doesn't work with a quick test, we may need to modify "usb start" to return 0 if there are any storage devices, otherwise non-zero
[09:03] <ogra> if test -n usb start; then ... fi
[09:03] <ogra> try that
[09:03] <ericm> usb reset seems to return a true condition here whether a usb disk is plugged or not
[09:03] <ogra> err, hmm
[09:03] <ogra> -n wont help
[09:03] <ogra> but you should be able to use test properly here
[09:04] <ericm> ogra, only if it returns different value depending on how many storage devices are attached
[09:05] <saeed> ogra: usb start taked 5 seconds, and accessing usb does't take noticable time if no device found
[09:05] <ericm> ogra, and the "usb start" is really slow, which should be avoided during normal running (but then we need a way to tell uboot it's in installation mode and run 'usb start')
[09:06] <ericm> saeed, right - the most time consuming thing is "usb start"
[09:07] <ericm> but the problem is we don't do this automatically and everytime, installation isn't possible unless we tell u-boot explicitly
[09:07] <saeed> guys, I think that should be handled in productions systems, for example, the user shoud press on some button so the uboot will try boot from usb
[09:07] <ericm> like F12 in IBM thinkpad to tell BIOS to boot from CDROM
[09:07] <ericm> saeed, exactly what I'm thinking
[09:07] <ogra> saeed, ++
[09:07] <ericm> the problem is that: there is only the power button :-)
[09:07] <ericm> or the reset button ??
[09:08] <ericm> or introducing the keyboard (USB/HID) support in u-boot, which is super fantastic :-)
[09:09] <saeed> ericm: thats is not straightforward
[09:09] <ericm> saeed, I'm joking :-)
[09:09] <saeed> :)
[09:10] <ericm> saeed, a kexec -based soft loader, though, may really be helpful to solve this issue
[09:10] <ericm> esp. kexec seems rather stable on dove
[09:10] <saeed> yes
[09:10] <ericm> and it's loading uImage/uInitrd quick enough
[09:11] <saeed> ericm: yesterday I tried to use it, but it didn't work
[09:11] <saeed> the next boot the system complains that it can't find the initrd on address 0
[09:11] <saeed> where does the kexec allocate the initrd?
[09:12] <ericm> saeed, ah well - that's because you are still using the old kexec binary
[09:12] <ericm> which needs to be patched (a single line though)
[09:12] <saeed> mmm
[09:12] <ogra> ericm, if we have kbd support we only need to add framebuffer !
[09:12] <ericm> the uImage will decompress itself into some place in initrd, by placing initrd far away behind, it can be solved
[09:12] <ericm> ogra, that's right
[09:13] <saeed> can I just update it ?
[09:13] <ericm> saeed, it's not in repo yet, wait
[09:13] <ericm> saeed, check http://people.canonical.com/~ycmiao/kexec/, copy kexec and kdump to overwirte the original copioes
[09:18] <saeed> ericm: it didn't work!
[09:18] <ericm> saeed, .....
[09:18] <saeed> # kexec  --version kexec-tools: 2.0.1-git released 13th August 2009
[09:19] <ericm> saeed, let me re-upload my local version
[09:19] <saeed> ok
[09:20] <ericm> saeed, try again
[09:21] <ericm> saeed, btw bug 509006 - hibernation resuming failure, I was able to track that to swsusp_arch_resume() where when restoring pages on "restore_pblist", it caused data abort
[09:21] <ubot4> Launchpad bug 509006 in linux-mvl-dove (Ubuntu Lucid) (and 1 other project) "[dove] hibernation failed to resume (affects: 4) (heat: 22)" [High,Confirmed] https://launchpad.net/bugs/509006
[09:22] <saeed> ericm: kexec works, thanks alot
[09:22] <ericm> saeed, no problem
[09:22] <ogra> ericm, now get it working on omap and imx51 and we can actually make use of it :)
[09:23] <ericm> ogra, it should be working - but you remind me to put the patch to lp, which I should have done long time ago
[09:23]  * ericm is a slack
[09:23] <ogra> afaik kexec on imx51 breaks a bunch of currently working stuff
[09:24] <cooloney> ogra: really?
[09:24] <ogra> i cant remember what exactly but i think cooloney said suspend/resume
[09:24] <cooloney> kexec breaks many things?
[09:24] <ogra> oh, cooloney there are you :)
[09:24] <ogra> didnt you say it broke suspend ?
[09:25] <cooloney> ogra: hehe, actually, i did not found the root cause of the suspend/resume regression
[09:25] <ogra> iirc that was before you fiddled with fec
[09:25] <cooloney> ogra: it should be ok after the kexec patches
[09:25] <ogra> and suspend worked before you added the kexec patch
[09:25] <saeed> ericm: the fact that the system hangs at swsusp_arch_resume() doens't necessarly mean that the it's a kernel bug
[09:25] <ogra> ok, then i misunderstood
[09:26] <cooloney> ogra: and one patch fixed the suspend/resume issue from jk, who introduce that regression in the leds bug fixing
[09:26] <ogra> yeah
[09:26] <ogra> i remember that one
[09:26] <cooloney> then after that, the candidate should be me my fec driver
[09:26] <ogra> yup
[09:26] <cooloney> now i fixed that, it can suspend,
[09:26] <cooloney> but cannot resuem
[09:27] <cooloney> currently, my babbage board was dead totally,
[09:27] <cooloney> it cannot power on now
[09:27] <ogra> cooloney, btw, what became of the regulator disaster with your board ?
[09:27] <ogra> ah
[09:27] <ogra> snap
[09:27] <cooloney> ogra: i think i will fix them soon
[09:28] <ericm> saeed, yeah - but it's really weird that if hibernation resume is done earlier then it works all right
[09:28] <cooloney> ogra: the report from plars about the regulator testing kernel is reasonable
[09:28] <ericm> saeed, basically the initramfs does the resume by writing to /sys/power/resume and trigger the hibernation resume explicitly
[09:31] <saeed> ericm: if your swap on usb, then the resume will not be done earlier, and it should work
[09:33] <ericm> saeed, why is that - resume will not be done earlier?
[09:35] <saeed> ericm: because usb disk get discovered only at later point
[09:36] <ericm> saeed, the difference is that - one is done in rootfs_initcall() , the other is done in early user space
[09:41] <DanaG> how are you even supposed to wake an omap (beagle)?
[09:41] <saeed> ericm: sotware_resume is done from late_initcall
[09:42] <saeed> ericm: both methods should work
[09:42] <ericm> saeed, I expect so ... but the initramfs version just doesn't work :-(
[09:49] <saeed> ericm: iirc, beta2 succeeded to resume from initramfs, when resume= added to command line. can you please try that version?
[09:49] <saeed> you don't need to install it, you can try the usb live
[09:50] <ericm> saeed, I was able to resume with "resume=" I can confirm that
[09:51] <saeed> you meam the early resume, no the initramfs resume, right?
[09:51]  * saeed brb
[09:59] <ogra> ndec, im blazed ! (just had fedex here) :)
[09:59] <ndec> ogra: congrats!!!
[10:00] <ogra> its sooo sexy !
[10:00] <ndec> ogra: later today, I need to give you instructions to get the right kernel...
[10:00]  * ogra will put it under his pillow at night :)
[10:00] <ndec> ogra: but I am a little busy for now
[10:00] <ogra> yeah, no urgence before lucid anyway
[10:00] <amitk> ogra: just don't slobber all over it :)
[10:00] <ogra> i need to concentrate on the beagle image
[10:00] <ogra> amitk, hard to do :)
[10:02] <ndec> ogra: i am sure you will want to see it running, even before lucid ;-)
[10:02] <ogra> heh, indeed
[10:03] <ogra> ndec, what i love most is that it has the same color as one of my porsches ... how did you guys know that ? :)
[10:03] <amitk> show off!
[10:03] <ogra> nice bordeaux red :)
[10:07] <ogra> amitk, you know my porsche, dont you ? http://people.canonical.com/~ogra/2CAF65BCd01.jpg
[10:07] <amitk> i do, seen it in barcelona i think
[10:08] <ogra> (though thats the one sitting in the garage, i drive another one atm)
[10:08]  * amitk is so confused about UDS'
[10:08] <ogra> no, the one ion barcelona was the more powerful one :)
[10:08] <ogra> it'll take me to brussels too this time ... and its more loke firengine red
[10:08]  * ericm wonders how many porsche ogra has
[10:08] <ogra> ericm, two
[10:09] <ogra> which gets me regular stress with my GF :)
[10:09] <amitk> ericm: as I said - show-off :)
[10:09] <ericm> amitk, yeah indeed
[10:12] <ogra> amitk, hmm, so it seems we have issues with compcache on omap
[10:13] <ogra> if i swapoff and remove the two compcache modules my install finishes properly
[10:13] <ogra> if i dont, i end up with stuff like http://paste.ubuntu.com/419902/ in dmesg
[10:17] <ericm> ogra, amitk, possible to get a beagle and get it reimbursed? I'm thinking about getting another arm-v7 SoC for testing purpose
[10:17] <lool> ogra: Hey
[10:17] <lool> ogra: Did you reproduce the qemu-maemo beagleboard issue yesterday?
[10:17] <ogra> lool, what issue ?
[10:17] <lool> ogra: The kernel hang after uncompressing linux
[10:18] <ogra> no, i dont have qemu-maemo here, still fighting with the compcache issue on the netbook image
[10:18] <amitk> lool: the link you sent was regarding fw_setenv
[10:18] <lool> amitk: was not?
[10:19] <lool> ogra: Ok, nm, just confusion
[10:20] <ericm> ogra, amitk, or you guys have spare one that I borrow at UDS?
[10:24] <lool> ericm: Did the kexec issue affect dove?
[10:26] <ericm> lool, not dove specific
[10:27] <ericm> saeed, weird - JTAG stops at data abort when restoring page at 0x81044000 (with a copy at 0x98f00000), I'm seeing no speciality of this specific page
[10:27] <ericm> the weirdest thing is data abort happens in the middle of page restoring, which is unusual
[10:28]  * ericm be right back
[10:35] <lool> ericm, cooloney: Is one of you sending this bug upstream in kexec-tools?
[10:37] <cooloney> lool: oh, i think ericm is working on this
[10:38] <DanaG> oh yeah, random thing: I get spew of "Mountall: Plymouth Command Failed" at boot.
[10:38] <DanaG> It uses 100% of one cpu core on the HOST system when watching the serial console.
[10:38] <lool> Gah dpatch
[10:39] <lool> DanaG: strace it
[10:39] <lool> DanaG: might be https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/567964 ?
[10:39] <ubot4> Launchpad bug 567964 in mountall (Ubuntu) "mountall keeps on running (affects: 2) (heat: 12)" [Medium,Confirmed]
[10:39] <lool> just hit this this morning on my laptop myself
[10:39] <DanaG> How do I strace it during boot?
[10:39] <lool> DanaG: It's only during boot?
[10:39] <DanaG> Yeah.
[10:39] <DanaG> And it stops spewing after a while.
[10:39] <lool> DanaG: Ok; what's your image?
[10:40] <DanaG> Or perhaps it's spewing just after boot.
[10:40] <DanaG> Image as in file system, or as in picture?  Since I'm using serial console, it gives me no splash screen.
[10:40] <DanaG> Same thing happens on my host system (AMT serial console).
[10:41] <DanaG> https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/557161
[10:41] <ubot4> Launchpad bug 557161 in mountall (Ubuntu) "mountall: Plymouth command failed (dup-of: 559761)" [Undecided,Confirmed]
[10:41] <ubot4> Launchpad bug 559761 in mountall (Ubuntu Lucid) (and 1 other project) "mountall needs to flush plymouth message queue before emitting upstart events (affects: 26) (dups: 2) (heat: 152)" [High,Fix committed]
[10:41] <DanaG> anyway, bedtime now.
[10:42] <DanaG> I commented on a bug about "no splash as soon as console= is present", as well.
[10:42] <DanaG> Thu Apr 22 02:42:15 PDT 2010
[10:44] <ogra> it could also be bug 563618
[10:44] <ubot4> Launchpad bug 563618 in util-linux (Ubuntu Lucid) (and 3 other projects) "Ignoring a broken clock results in infinite reboots; not ignoring results in fsck failure; no solution to this problem (affects: 1) (heat: 14)" [High,Triaged] https://launchpad.net/bugs/563618
[10:45] <ogra> in combination with bug 516825
[10:45] <ubot4> Launchpad bug 516825 in plymouth (Ubuntu) "plymouth doesnt show any splash as soon as a console= commandline option is used on boot (affects: 2)" [Medium,Fix released] https://launchpad.net/bugs/516825
[10:46] <ogra> i think the latter one breaks in worse ways than at the time it was reported
[11:02] <NCommander> ~~~~A;2~
[11:04] <NCommander> sorry, cat
[11:04] <NCommander> saeed: ogra_cmpc: uboots abaility to be scripted is incredibly poor
[11:06] <saeed> NCommander: hey
[11:06] <NCommander> saeed: hola
[11:07] <saeed> are you talking about adding the if "usb start"
[11:08] <NCommander> saeed: theres no way to check if usb sstart ran successfully or not; it returns no error code nor is there a way to see how many devices were found
[11:08] <NCommander> saeed: I'd like to add such functionality as part of an optimization if I ever got the time, but the biggest holdup is just raw read speed
[11:09] <saeed> NCommander: anyway, I don't think that it will save a noticable time
[11:09] <saeed> NCommander: what do you mean by the raw read speed?
[11:11] <ericm> NCommander, since kexec is now available - we might want to speed up the softloader project
[11:11] <NCommander> saeed: if you look at the boot time, 10-20 seconds are just spent at ext2load ide
[11:12] <saeed> NCommander: yes, I agree
[11:12] <NCommander> ericm: maybe for 10.10, but dove ends with 10.04 :-/
[11:14] <saeed> NCommander: mayeb defrag of the boot partition could help
[11:14] <NCommander> saeed: hasn't beofre. the issue seems to be a lack of DMA on reading from SATA
[11:14] <NCommander> saeed: but I haven't looked at the code extensively to confirm
[11:14] <saeed> NCommander: the uboot ide driver is ok
[11:15] <NCommander> saeed: then I have no explination on the speed
[11:15] <saeed> just try "ide read 0x2000000 0 0x10000" and you will see that it completes very fast
[11:15] <saeed> the ide driver support DMA and requests up to 128 sectors (64K)
[11:16] <saeed> it could be unoptimized ext2 implementation
[11:16] <NCommander> saeed: that could be it
[11:17] <NCommander> saeed: the question is what can be done about it?
[11:17] <saeed> NCommander: I've had ssd disk, and the uboot read of images was fast
[11:18] <NCommander> saeed: not so much here, when I used a sata ssd, it wasn't much of a speed improvement
[11:18] <saeed> mabye writing the images are row date on known partition :)
[11:19] <NCommander> saeed: huh?
[11:20] <saeed> I mean to write the kernel image on /dev/sda1, then uboot will load the image from sector 63
[11:21] <saeed> without fs
[11:21] <lool> ericm, cooloney: Sorry, kept crashing hard a couple of times; will look into kexec-tools
[11:22] <ogra> stop crashing !Q
[11:22] <NCommander> saeed: we do tha tfor imx51, but its too late/difficult to change the behavior now for 10.04
[11:22] <NCommander> saeed: with a little luck, softbootloader will materialized for 10.10 and we'll have a GRUB like booting experience
[11:23] <ogra> well, there is also change that we actually get grub proted to ARM
[11:23] <ogra> *chance
[11:23]  * ogra still has that on this plate to make sure the grub guys get the HW they need
[11:24] <ericm> lool, no problem
[11:59]  * cwillu_at_work grumbles about usplash not building from source
[12:00] <lool> cwillu_at_work: Seriously?
[12:00] <lool> cwillu_at_work: What's the error?
[12:00] <cwillu_at_work> sec
[12:00] <cwillu_at_work> it's an asm constraint thingie
[12:01] <lool> cwillu_at_work: I dont see it on http://udd.debian.org/cgi-bin/ubuntu_ftbfs.cgi at least
[12:01] <cwillu_at_work> in the svgalib included
[12:01] <lool> ah on arm
[12:01] <lool> indeed we dont test rebuild armel ATM
[12:01] <dmart> lool, asac, ogra: can anyone with a dove do a quick test for me?
[12:01] <lool> dmart: I dont have one
[12:01] <dmart> Relates to bug 567956
[12:01] <ubot4> Launchpad bug 567956 in linux-fsl-imx51 (Ubuntu) "ARM: Incorrect prefetch abort handling can cause a spin instead of SIGSEGV (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/567956
[12:01] <hrw> saeed: what is 'softloader project'?
[12:02] <lool> saeed ^ dmart is looking for testers with dove hardware
[12:02] <lool> hrw: mukluk
[12:02] <cwillu_at_work> lool, did you still want the error message?
[12:02] <lool> hrw: https://launchpad.net/mukluk
[12:02] <lool> cwillu_at_work: Yes, file a bug actually
[12:03] <lool> cwillu_at_work: we have some binaries available for it https://launchpad.net/ubuntu/+source/usplash/0.5.51 but it's not rebuilt with latest toolchain
[12:03] <cwillu_at_work> lool, .../usplash-0.5.49/src/libvga.h:275(and294): error: impossible constraint in 'asm'
[12:03] <dmart> saeed: would you be able to do a qkick test for me?
[12:03] <lool> cwillu_at_work: Probably a thumb2 porting issue
[12:03] <lool> cwillu_at_work: Please do file a bug with the log
[12:03] <cwillu_at_work> lool, ya, I can't use the binaries;  I'm trying to hack out the /dev/.initramfs
[12:03] <lool> cwillu_at_work: thing is, we moved to plymouth and usplash is now in universe, so wasn't on our radar
[12:03] <saeed> dmart: hey
[12:03] <lool> it's pretty much being phased out I'm afraid
[12:04] <cwillu_at_work> lool, this is in karmic still, but ya
[12:04] <dmart> saeed: Hi there
[12:04] <lool> cwillu_at_work: Quick fix: try building with -marm in CFLAGS
[12:04] <saeed> dmard: sure which test
[12:04] <hrw> lool: like kexecboot from OE guys
[12:04] <cwillu_at_work> if lucid would install in qemu, I'd be on it already :)
[12:04] <lool> hrw: eh
[12:04] <cwillu_at_work> k, I'll give that a shot
[12:04] <dmart> saeed: I added the test case in bug 567956
[12:04] <ubot4> Launchpad bug 567956 in linux-fsl-imx51 (Ubuntu) "ARM: Incorrect prefetch abort handling can cause a spin instead of SIGSEGV (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/567956
[12:04] <lool> hrw: like other existing bootloaders, yes
[12:04] <dmart> saeed: you're running 2.6.32, yes?
[12:04] <lool> hrw: google for it and you should find a spec for it where this was discussed
[12:04] <saeed> yes
[12:04] <cwillu_at_work> ugh; how do I file a bug without using ubuntu-bug again?
[12:05] <amitk> cwillu_at_work: ubuntu-bug <package-name>
[12:05] <dmart> If you can try the test case, you should get a segfault, indicating that the bug isn't present in the dove kernel
[12:05] <cwillu_at_work> amitk, your reading comprehension leaves something to be desired :p
[12:05] <hrw> ok
[12:07] <amitk> cwillu_at_work: indeed :)
[12:08] <saeed> dmart: I just got Segmentation fault
[12:08] <dmart> saeed: cool, that's what I wanted to hear :)  Thanks for testing
[12:09] <cwillu_at_work> https://bugs.launchpad.net/ubuntu/+source/<packagename>/+filebug?no-redirect
[12:09] <saeed> dmart: the "ARM: 5728/1: Proper prefetch abort handling on ARMv6 and ARMv7" is applied into my kernel
[12:09] <dmart> saeed: I think it was merged into mailline 2.6.32
[12:10] <dmart> ...so that's what I expected
[12:10] <saeed> I see
[12:10] <dmart> Just wanted to make sure
[12:10] <dmart> thanks
[12:14] <cwillu_at_work> lool, adding -marm to CFLAGS in debian/rules didn't affect it
[12:17] <cwillu_at_work> lool, https://bugs.launchpad.net/ubuntu/+source/usplash/+bug/568337
[12:17] <ubot4> Launchpad bug 568337 in usplash (Ubuntu) "usplash fails to build from source (armel, karmic) (affects: 1)" [Undecided,New]
[12:20] <dmart> cwillu_at_work: can you add gcc version details to your bug report?  A source snippet of the relevant lines might be handy, but I expect the source won't change that rapidly...
[12:21] <cwillu_at_work> done
[12:21] <dmart> Thanks
[12:21] <dmart> Out of curiosity, are vga.c, libvga.h applicable to arm at all?
[12:22] <dmart> aH
[12:22] <dmart> We seem to be trying to build x86 inline asm here...
[12:23] <dmart> http://pastebin.ubuntu.com/420366/
[12:23] <NCommander> dmart: what do you need tested on dove?
[12:23] <dmart> NCommander: it's OK, saeed did it already
[12:23] <NCommander> dmart: oh good
[12:24] <dmart> cwillu_at_work: Maybe there's some wrong config or #ifdefs somewhere, or perhaps we shouldn't build those files on ARM--- normally graphics means X or framebuffer or nothing
[12:25] <cwillu_at_work> so, wrong backend?
[12:26]  * ogra_cmpc finds all that a bit weird, we definately shipped usplash on arm in karmic
[12:26] <ogra_cmpc> in both platforms
[12:26] <cwillu_at_work> yep, I'm using it right now
[12:27] <ogra_cmpc> i dont get why you cant recompile it then
[12:27] <ogra_cmpc> since it definatly built successfully in the archive back then
[12:29] <ogra_cmpc> i think it also should default to use bogl on arm, weird that it chooses vgalib
[12:29] <cwillu_at_work> debian/rules doesn't make any reference to bogl
[12:29] <cwillu_at_work> what is bogl?
[12:29] <ogra_cmpc> the other backend
[12:30] <cwillu_at_work> ...work via? :p
[12:30] <ogra_cmpc> no idea, i would have to dig in the code, i think plain framebuffer
[12:30] <cwillu_at_work> okay; trying to rebuild against that
[12:31] <ogra_cmpc> https://edge.launchpad.net/ubuntu/karmic/armel/usplash all karmic versions built
[12:31] <lool> dmart: You could check the build log for the version in lucid
[12:31] <lool> dmart: (of usplash)
[12:32] <lool> dmart: ISTR we're using the fb backend of usplash to draw; there's an embedded svgalib IIRC
[12:32] <ogra_cmpc> the last lucid build was before we changed the toolchain defaults though https://edge.launchpad.net/ubuntu/+source/usplash/0.5.51/+build/1373831
[12:33] <ogra_cmpc> but if you use a karmic toolchain that shouldnt matter
[12:33] <lool> ogra_cmpc: Yes, but it shows which files were built
[12:33]  * cwillu_at_work points out that the error is in the embedded svgalib
[12:35] <ogra_cmpc> in the buildlog it seems to ignore svgalib and only build bogl
[12:37] <cwillu_at_work> build completed with BACKEND="bogl"
[12:37] <ogra_cmpc> right
[12:37] <ogra_cmpc> but the package should select that automatically based on the arch
[12:38] <lool> cwillu_at_work: You build the package with dpkg-buildpackage, right?
[12:38] <lool> Not ./configure + make etc.
[12:38] <cwillu_at_work> lool, debian/rules binary
[12:38] <ogra_cmpc> hmm
[12:38] <lool> cwillu_at_work: That changes CFLAGS/LDFLAGS, but I wouldn't expect a big difference
[12:39] <cwillu_at_work> debian/rules has a check for i386 amd64 lpia, which sets BACKEND = "BACKEND=svga"
[12:39] <cwillu_at_work> the other branch sets it to BACKEND =
[12:39] <lool> ifeq ($(DEB_HOST_ARCH), $(findstring $(DEB_HOST_ARCH),i386 amd64 lpia)) BACKEND = "BACKEND=svga"
[12:39] <lool> else BACKEND =
[12:39] <lool> cwillu_at_work: ack
[12:39] <lool> endif
[12:40] <cwillu_at_work> lool, and for the crowning touch:  when I set backend to bogl, I did it in the i386/amd64/lpia branch, _not_ the else
[12:40] <cwillu_at_work> and that built successfully
[12:40] <lool> cwillu_at_work: So it should just build the bogl code on armel, not svga
[12:40] <cwillu_at_work> ifeq ($(DEB_HOST_ARCH), $(findstring $(DEB_HOST_ARCH),i386 amd64 lpia)) BACKEND = "BACKEND=bogl"
[12:40] <cwillu_at_work> is what I changed it to
[12:41] <lool> GAH
[12:41] <lool> nothing sets DEB_HOST_ARCH
[12:41] <ogra_cmpc> heh
[12:41] <lool> cwillu_at_work: You should REALLY use dpkg-buildpackage!
[12:41] <lool> cwillu_at_work: The bug is that the rules don't set DEB_HOST_ARCH properly, but dpkg-buildpackage always sets them
[12:42] <cwillu_at_work> so it's a lintian'ish thing
[12:42] <lool> It's a packaging bug, but one which will only affect people running debian/rules binary  :-)
[12:42] <cwillu_at_work> well, now you know :p
[12:43] <ogra_cmpc> and which it unlikely to be fixed at all ... since usplash will vanish
[12:43] <cwillu_at_work> it's disappearing from debian too?
[12:43]  * ogra_cmpc doubts anyone will put any time in that package
[12:43] <ogra_cmpc> debian uses it ?
[12:44] <ogra_cmpc> i thought they preferred splashy anyway
[12:44] <cwillu_at_work> well it's in universe
[12:45] <cwillu_at_work> it's not native to ubuntu is it
[12:45] <lool> cwillu_at_work: Pushed to bzr
[12:45] <ogra_cmpc> it was
[12:45] <lool> cwillu_at_work: Ubuntu is the upstream
[12:45] <ogra_cmpc> not sure if they pulled it into debian or not
[12:45] <lool> hence the abuse of native packaging
[12:45] <lool> It's definitely pulled in Debian
[12:45] <cwillu_at_work> ah, k
[12:45] <ogra_cmpc> ah
[12:45] <lool> for the same reason, it wont affect Debian too hard
[12:45] <lool> anyway, fixed
[12:47] <cwillu_at_work> <3
[13:16] <lool> ericm: I pushed a test package; would love if you could answer to the questions I asked on the bug
[13:16] <lool> as to have a test case documented by someone else than me
[13:21] <ericm> lool, ok - you updated on LP?
[13:22] <lool> ericm: Yes
[13:22] <ericm> lool, I'll take a look
[13:23] <lool> ericm: https://launchpad.net/~canonical-arm-dev/+archive/marvell-dove-public/+build/1702324
[13:24] <ericm> lool, ok - guess I could download the deb directly instead of adding the ppa to my dove
[13:24] <lool> ericm: Yes
[13:24] <lool> that's why I pointed you at this URL, and also because the PPA publishing might take up to 20 minutes
[13:25] <ericm> lool, no problem, I'll give it a run and update the LP
[13:25] <ericm> versatile & beagleboard, I'm afraid there are several kernel patches needed
[13:27] <ericm> https://bugs.launchpad.net/adana/+bug/517841
[13:27] <ubot4> ericm: Error: Bug #517841 is private.
[13:27] <lool> ericm: These didn't make it to the kernel?
[13:28] <lool> These are from March
[13:28] <ericm> lool, not in .32 I guess
[13:28] <ericm> lool, but should be sitting there if versatile&beagle kernel are built from latest
[13:28] <lool> What prevented them from being merged into our various ARM trees!?
[13:29] <lool> I dont see these commits in our master tree at least (from which versatile is built)
[13:30] <lool> nor in ti-omap, which is -33 based
[13:30] <ericm> lool, that's the problem, we are currently maintaining different branches for different ARM SoC so these patches do just get into each other branch
[13:30] <ericm> s/do/don't
[13:30] <lool> ericm: I've seen patches from master propagate into the other trees though
[13:31] <ericm> lool, but yeah - this is common and should go into master instead
[13:33] <lool> ericm: Do you mind if I make the bug public and affecting Ubuntu arm kernel branches?
[13:33] <lool> except fsl-imx51 which has the fixes of course
[13:33] <lool> in fact mvl-dove has them as well
[13:33] <lool> so linux-ti-omap and linux
[13:33] <ericm> lool, no problem, it should have been made public
[13:35] <NCommander> saeed: eggonlea you around?
[13:35] <saeed> NCommander: yep
[13:35] <asac> saeed: see msg
[13:35] <asac> or talk to NCommander ;)
[13:36] <lool> ericm: Could you help track / test it in other kernels?
[13:37] <ericm> lool, no problem
[13:37] <lool> asac: Would you put that on your SRU radar as well?
[13:37] <lool> will flag as stable updates candiates
[13:37] <lool> ericm: it's confirmed as needed for versatile and omap, right?
[13:37] <ericm> lool, btw - current kexec-tools has support for uImage right?
[13:37] <asac> lool: which?
[13:37] <lool> ericm: Dunno
[13:37] <lool> ericm: never tried uimage
[13:37] <asac> (sorry on call ... didnt read backlog)
[13:37] <lool> ericm: let me know :)
[13:37] <lool> asac: https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap/+bug/517841
[13:37] <ubot4> Launchpad bug 517841 in linux-ti-omap (Ubuntu) (and 2 other projects) "KEXEC support broken (affects: 2) (dups: 1)" [Undecided,New]
[13:37] <ericm> lool, we do need that for versatile and omap
[13:37] <lool> ericm: Ok thanks
[13:38] <ericm> lool, guess I need a beagleboard somewhere
[13:39] <lool> ericm: You should get one
[13:39] <lool> ericm: There are plenty of people here to test in the mean time
[13:43] <asac> lool: so assign to amitk? or ericm?
[13:43] <asac> and yes, its on SRU radar as its now targetted ;)
[13:44] <asac> feel a bit reluctant about fixing this in linux in SRU ... is that a safe patch`across the board?
[13:45] <ericm> asac, I think we should make the kexec work back into master - so every ARM branch will have it once rebased
[13:45] <ericm> including OMAP
[13:45] <asac> ericm: can you change your patch attachments to text/plain? my browser doesnt like text/x-diff ;)
[13:45] <asac> (not importnat)
[13:45] <asac> ericm: yes, but will this patch be good enough for lucid SRU? i see this for maverick for sure
[13:46] <ericm> asac, I was originally sending attachments in text/plain, but later found the checkbox that "The Attachment is a patch", I cannot resist to leave it unchecked :-)
[13:46] <ericm> asac, I don't think so, we don't have any existing user land stuffs, -M is a go as we move to soft bootloader
[13:47] <asac> ericm: heh. the patch i edited didnt hav that checkbox checked ;)
[13:47] <ericm> that really depends how quick NCommander is able to come up with it, NCommander ?! :-)
[13:47] <asac> still it was text/x-diff ... but i will survive
[13:48]  * NCommander reads backscroll
[13:48] <ericm> asac, .... yeah I know, with pain
[13:48] <ericm> NCommander, are we bringing forward the soft bootloader to -M?
[13:48] <asac> ericm: TBD
[13:48] <NCommander> ericm: softbootloader has working prototype. It might actually land for 10.10 at this point as kernel support landed for imx51 and dove
[13:48] <NCommander> ericm: we'll have yet another UDS session on it
[13:49] <ericm> NCommander, cool
[13:49] <NCommander> I mean, it won't be UDS without an ARM softbootloader session
[13:49] <asac> NCommander: we will have? i dont think one is scheduled and given that we had a bunch already, do you really think we need a session?
[13:49] <ericm> NCommander, hehe :-)
[13:49] <NCommander> asac: its traditional!
[13:49]  * ericm lol
[13:49] <asac> right. lets break traditions this cycle and get it actually done instead ;)
[13:49] <asac> rather than the tradition to just talk ;)
[13:49] <NCommander> asac: ouch.
[13:50] <ericm> NCommander, no worry - I'll see if I can help on that if I have time
[13:50] <ericm> :-)
[13:50] <NCommander> ericm: time is something that is always in short supply I find.
[13:50] <asac> ericm: so you cannot test kexec without a softbooloader? is that what you meant by being blocked on NCommander ?
[13:51] <ericm> asac, no I can test kexec with kexec-tools, that's fine
[13:51] <ericm> asac, I'm not blocked
[13:51] <ericm> NCommander, indeed
[13:52] <asac> ericm: great ;)
[13:52] <asac> ericm: so can we aim for an sru for linux-omap for lucid, but keep the "linux" fix for m?
[13:53] <ericm> asac, sure - just assign amitk then, I'll let him know this
[14:03] <ericm> lool, it's weird - I'm seeing no uImage support in kexec-tools source but the binary in the package does support uImage loading
[14:03] <ericm> lool, can you point me a URL for the source or bzr branch name?
[14:04] <ericm> for the exact package you built
[14:04] <lool> ericm: apt-get source kexec-tools will always give it to you; it might be in a patch in debian/patches/
[14:04] <lool> ericm: bzr branch lp:ubuntu/kexec-tools will give you the history of package uploads
[14:04] <amitk> lool: fsl and mvl are or different kernel version in lucid (re: propagating from master)
[14:05] <amitk> *on
[14:05] <lool> amitk: But you dont review the linux patches for the other trees?
[14:06] <amitk> lool: we try, but given the number of patches it is very hard to keep up.
[14:06] <lool> amitk: Ah I thought there was some kind of process to ensure no patch is lost
[14:06] <amitk> lool: you live in a perfect world :)
[14:07] <lool> amitk: Eh, I'm assuming you folks are reaching for the sky!!  ;-)
[14:07] <amitk> different people working on each of the branches, different deadlines, etc.
[14:08] <lool> amitk: I wish there would be some process to ensure we do fix issues in all trees   :-/
[14:10] <amitk> lool: if you come up with something, that will scale across different kernel versions, release deadlines, kernel configs, debian packaging, different people, different time for branching, I am sure we're all interested in following it.
[14:10] <amitk> :)
[14:12] <ogra> amitk, you forgot "different flavours of beer/wine"
[14:13] <amitk> :)
[14:14] <hrw> btw - is there a list of ubuntu/arm sessions for uds-m?
[14:14] <ogra> hrw, not yet, lool is a slacker !
[14:15]  * ogra hides
[14:15] <lool> hrw: an out of date one is public
[14:15] <lool> but we kind of suck on this front ATM
[14:17] <ogra> NCommander, how is gphoto doing ? already uploaded to the queue ?
[14:19] <dmart> asac: I see there's a fix committed for the firefox scrollbar bug now.  Did you get anywhere working out which object is getting miscompiled?
[14:24] <asac> dmart: far away from finding the module. i wanted to first see which optimization causes this
[14:24] <asac> dmart: but that dropped off the radar a bit because building everything -Os didnt evn build and then i got dragged into other stuff.
[14:25] <dmart> OK.  Well, let me know if you get any ideas ;)  if there is a miscompile somewhere it'd be good to track it down
[14:25] <asac> dmart: my opinion is that its probably not good to test non default optimizations in firefox
[14:25] <asac> dmart: its kinda understandable that none -O2 has issues
[14:25] <dmart> Do you think it may be a firefox issue instead?
[14:25] <asac> if we want to get toolchain stabilized for other optimizations we should think about starting with base packages and then work up
[14:26] <dmart> Yeah, I guess
[14:26] <asac> dmart: hard to say. given that we dont see it anywhere else, i doubt it
[14:26] <asac> also it goes away with -O2 and goes away when doiung a debug build
[14:26] <asac> so far only the mozila mix of different optimizations for different subtrees triggers it
[14:26] <asac> they use -O3, -Os and -O2 mix
[14:27] <dmart> interesting... there shouldn't be any ABI issues
[14:27] <asac> its not ABI i would think. it doesnt crash and is stable
[14:27] <dmart> well, don't worry about it right now, I guess
[14:27] <asac> just something with math is broken ;) ... my guess
[14:27] <NCommander> ogra: it should be in the queue, I haven't seen a reject or accept email
[14:28] <dmart> NCommander: I retried the OOo build on babbage3+lucid and got the same failure as before:
[14:28] <dmart> ../unxlngr.pro/bin/makedepend: symbol lookup error: ../unxlngr.pro/bin/makedepend: undefined symbol: cppsetup
[14:28] <dmart> any thoughts?
[14:28] <NCommander> dmart: er, that looks like a new one
[14:28] <NCommander> dmart: but my gut reaction is: OOo sucks?
[14:28] <dmart> The build always falls over this way, I haven't been able to get it any further for at least the last week or so...
[14:29] <NCommander> dmart: how are you building?
[14:29] <dmart> debian/rules build
[14:29] <dmart> But dpkg-buildpackage -B produced the same result previously
[14:29] <NCommander> dmart: odd ... that should work. It works on Dove I think
[14:29] <NCommander> dmart: i thought OOO was fully built though
[14:30] <dmart> Yes, that's why I'm confused.
[14:30] <NCommander> dmart: does it do it in a pbuilder instance?
[14:30] <dmart> This build was with the -marm workaround turned off, but I get the same failure either way.
[14:30] <dmart> This is not using pbuilder, just a manual build
[14:30] <lool> ericm: Please let me know when you test the kexec package and update the bug with a test case!  :-)
[14:31] <NCommander> dmart: it possible something in the build environment is breaking OOo. a clean chroot may be the way to go
[14:31] <ogra> NCommander, great !
[14:31] <lool> ericm: I see the test case actually now
[14:32] <ogra> asac, do you still plan to work on xserver-video-omapfb ? else i'll just upload the quick fix
[14:32] <dmart> NCommander: guess so.  I have the build-deps up to date, but it's a huge fs--- something else might be causing problems
[14:32] <ericm> lool, it doesn't actually have a test case indeed as you now see :)
[14:32] <asac> ogra: is archive open again?
[14:32] <ogra> asac, will open soon
[14:32] <ericm> lool, the binary from the package actually works
[14:32] <ogra> i think steve is in last stages for RC
[14:32] <NCommander> dmart: I can kick a build, or give you a shell on a Dove board
[14:33] <ericm> weird thing is it looks to me no uImage is supported yet it does work with uImage
[14:33] <NCommander> ogra: its there: https://edge.launchpad.net/ubuntu/lucid/+queue?queue_state=1&queue_text=
[14:33] <asac> ogra: your patch is probably ready and tested?
[14:33] <dmart> NCommander: it's not urgent.  Basically I wanted a build tree demonstrating the build-time segfault so I can poke at it.  Probably best if I try and reproduce it myself
[14:33] <asac> ogra: give me 3 hours ... if i dont give anything by then to test etc. go ahead
[14:34] <NCommander> dmart: well, if you want to rule out hardware, my shell on BBG 2.5 or Dove stands
[14:35] <dmart> Do we know whether it builds on dove?  It could be worth firing off a build there if not
[14:35] <NCommander> dmart: it should with -marm, thats where I did all my test builds.
[14:35] <lool> ericm: Which binary?
[14:35] <dmart> I mean with -mthumb
[14:36] <lool> ericm: the kexec one?  Cool
[14:36] <NCommander> dmart: no, it segfaults
[14:36] <dmart> Ah right, so it's not buildd-specific...
[14:36] <ericm> lool, wait - let me make sure I'm using the correct binary first, will get back to you later
[14:36] <dmart> A shell could be useful, though I won't be working on it right now.  I'll ping you later if I need access to something.
[14:37] <ogra> asac, my patch adds a 0 to /dev/fb (or XorA's patch now, since he committed it to the bug)
[14:39] <ericm> lool, it doesn't work - we may need to add uImage into kexec-tools
[14:39] <ericm> lool, or we may generate a kernel package with zImage or even vmlinux
[14:39] <ericm> NCommander, why don't we preserve zImage after flash-kernel?
[14:40] <NCommander> ericm: we do /boot/vmlinuz-*
[14:40] <ericm> /boot/vmlinuz-* == zImage?
[14:40] <NCommander> ericm: yeah
[14:40] <ericm> NCommander, got you
[14:40] <NCommander> that's why its vmlinuz
[14:40] <NCommander> decompressed images are traditional vmlinux
[14:42] <lool> ericm: Can you test with zImage?
[14:42] <ericm> lool, ok
[14:43] <lool> ericm: I think I saw the same as you did: vmlinuz doesn't work but vmlinux does
[14:43] <lool> ericm: I converted the file with a helper I wrote here
[14:43] <lool> http://people.canonical.com/~lool/vmlinuz-to-vmlinux
[14:44] <asac> ogra: well. go ahead ... i turned out to be busy most of the rest of the day ;)
[14:44] <NCommander> dmart: do you have IPv6 by any chance? :-)
[14:45]  * ericm is seeing mountall: Plymouth command failed printed out like crazy
[14:45] <dmart> NCommander: probably not...
[14:45] <NCommander> dmart: sudo apt-get install miredo will setup IPv6 over UDP. Then you can SSH into my boards if you need them
[14:45] <ogra> asac, ok, will do
[14:45]  * dmart makes a note
[14:45] <ericm> lool, vmlinuz seems all right
[14:53] <ericm> lool, both vmlinuz and converted vmlinux worked
[14:54] <ericm> the converted vmlinux has no decompressing, which should be slightly faster
[14:57]  * ericm needs some sleep
[15:21] <lool> ericm: Cool
[15:22] <lool> ericm: So we can push these kexec patches it seems
[15:59] <mopdenacker> Hi, I'm booting my Beagle with the LL image on http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-live/current/ . However, because of the "only-ubiquity" boot option, it doesn't start the live CD but directly the Ubiquity installer. Bug or feature?
[16:01] <lool> ericm: Pushed the pacakge to lucid; pending approval
[16:02] <lool> mopdenacker: that's intended
[16:02] <lool> ogra: ^
[16:02] <mopdenacker> It could be a bug because the Beagle has enough RAM to run the live CD (at least my rev C2). Could it be made for Rev A and B boards? Did they have 128 MB?
[16:03] <lool> mopdenacker: In theory they do, but apparently compcache support breaks this; ogra has the details
[16:07] <ogra> right
[16:08] <mopdenacker> lool: thanks! I don't see compcache in the kernel messages though...
[16:08] <ogra> compcache has issues on the beagle we couldnt solve anymore so it still causes OOM
[16:08] <mopdenacker> Ah, right.
[16:09] <ogra> you should see compcache with swapon -s
[16:09] <ogra> well, ramzswap
[16:11] <ogra> though we still saw malloc errors with that setup
[16:11] <ogra> the next image will not use compcache at all anymore
[16:12] <ogra> i just committed a fix and a new image build should happen as soon as initramfs-tools is in the archive
[16:12] <ogra> mopdenacker, i would suggest to use the netinst image though thats the text installer indeed
[16:13] <mopdenacker> ogra: thanks! Hope we will manage to make ramzswap work in the next release. That sounds attractive.
[16:13] <ogra> we will
[16:14] <ogra> the prob is (i suspect) that we use an old compcache implementation that was originally written for 2.6.28 ...
[16:14] <mopdenacker> Cool!
[16:14] <ogra> with 2.6.33 a rewrite entered staging but that requires a changed userspce handling
[16:15] <ogra> the omap image came in very very late in the cycle, so we couldnt rewrite the userspce bits in time and just took the old implementation
[16:15] <ogra> which is likely causing the different issues we see
[16:15] <ogra> for 10.10 we'll have a lot more time to make everything smooth and sort out all bugs
[16:16] <mopdenacker> Great, that's good to know that everything should be all right with mainline.
[16:16] <plars> mopdenacker: I've had some success installing from the netbook image by removing the swap on ramzswap0 and unloading ramzswap and xvmalloc, but certainly the d-i based image is going to be a more memory friendly install
[16:16] <cwillu_at_work> but what will I run on my arm-based server then?
[16:17]  * cwillu_at_work demands perfection from his lts
[16:17] <ogra> cwillu_at_work, the ubuntu-server image
[16:17] <ogra> cwillu_at_work, http://cdimage.ubuntu.com/ubuntu-server/ports/daily/current/
[16:18] <cwillu_at_work> "<ogra> for 10.10 we'll have a lot more time to make everything smooth and sort out all bugs"
[16:18] <ogra> oh
[16:18] <ogra> heh
[16:18] <cwillu_at_work> and then I was kinda making fun of the concept of using an arm board as a server
[16:18] <cwillu_at_work> despite the fact that I'm actually in that business :p
[16:19] <mopdenacker> Is there documentation for installing 10.04 on the Beagle besides the http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-live/current/ page? I'd like to help writing doc about this.
[16:20] <ogra> cwillu_at_work, yeah, i guess smoothstone would disagree about the joke part :)
[16:22] <mopdenacker> ogra, thanks for the tip for ubuntu-server! I plan to use it on my IGEPv2 board, with a home made kernel. That's a perfect board for a home server.
[16:22] <ogra> indeed
[16:25] <mopdenacker> Back to the Beagle install, my board doesn't automatically load the boot.scr file, while it did with someone else's board. Probably because I have my own U-boot in NAND flash.
[16:25] <mopdenacker> The documentation should tell which U-boot image to download and how to install it in NAND.
[16:26] <mopdenacker> That's why I propose to write this doc if it doesn't exist yet (I already have all the instructions).
[16:26] <cwillu_at_work> mopdenacker, the documentation should tell you which distribution to use, and how to install it
[16:27] <ogra> https://wiki.ubuntu.com/ARM/BeagleNetInstall
[16:27] <ogra> mopdenacker, ^^^
[16:27] <mopdenacker> cwillu_at_work: right! Do you know if such documentation exists somewhere, or should I create it?
[16:27] <mopdenacker> ogra: great, many thanks!
[16:27] <ogra> beyond that i'll create a page on the ubuntu wiki explaining how to get the ubuntu uboot-omap package, extract it and flash it to NAND
[16:28] <ogra> but if you already have *something* in NAND the above should get you going
[16:28] <ogra> (will work with all ubuntu images, they all use the same boot.scr (just different cmdlines))
[16:42] <saeed> NCommander, ogra
[16:42] <ogra> here
[16:42] <saeed> the slow read from sata seems to happen only on dove
[16:43] <saeed> I tried to read the same file on another arm board and it was fast
[16:43] <ogra> hmm, uboot issue ?
[16:43] <saeed> I'll check the boot
[16:43] <saeed> yes
[16:43] <ogra> seems a lot boards have issues with ext2 support in uboot
[16:44] <NCommander> hey saeed
[16:44] <saeed> which boards?
[16:44] <NCommander> saeed: if thats the case, we can look at using vfat over ext2 for the next release cycle of Dove, but when I tried fat, it wasn't much better
[16:44] <NCommander> saeed: vfat is also vey fragile :-/
[16:47] <ogra> saeed, omap beagle definately ...
[16:47] <ogra> saeed, and i had probs on imx51 too but we dont use uboot there
[16:47] <ogra> just when testing it
[16:47] <saeed> which uboot version?
[16:50] <ogra> relatively new ones
[16:50] <ogra> i need to look up the versions
[16:50] <ogra> 2009.01 for imx51
[16:53] <ogra> omap is 2010.3 (plus some omap specific git checkout)
[16:57] <NCommander> saeed: I know filesystem support in u-boot has been vastly expanded since 1.3.4
[16:58] <saeed> mm
[16:58] <saeed> I don't recall that this issue occured in early uboot versions of dove, do you?
[16:59] <NCommander> saeed: although it would be a downright pain to port a newer u-boot to Dove, won't it :-/
[17:00] <NCommander> saeed: I remember the speed sucking from day 1 unfortunately. Its possibly gotten worse just because our initramfs grew
[17:03] <Martyn> Oh boy
[17:03] <Martyn> Today is ARM rumor central ...
[17:03] <Martyn> Apple aquiring ARM?  Pffft .. neer
[17:03] <Martyn> never
[17:03] <ogra> Martyn, sure, you ddidnt hear that ?
[17:03] <Martyn> The industry wouldn't -let- that happen ...
[17:03] <ogra> will happen right after smoothstone aquired apple
[17:03] <Martyn> Freescale, Marvell, and others have direct stake in ARM .. and they would lose out if Apple locked out the industry
[17:04] <Martyn> So, I think it's just that .. speculation, rumor, driven by Apple's purchase of intrinsity .. no way would they spend >20% of their cash reserves
[17:04] <Martyn> ogra : Yep.
[17:06] <ogra> my suspicion is that they wanted to have something up against google buying Agnilux so they spread that roumor
[17:06] <NCommander> saeed: BTW, it seems the newest gstreamer-plugins-marvell we got FTBFS :-/
[17:06] <Martyn> maybe
[17:07] <saeed> NCommander: please make sure Li know about it
[17:08] <NCommander> saeed: will do, just happens our timezone skew really really sucks
[17:34] <GrueMaster> lrg: Ping.  I was told you are working on alsa bits for freescale and marvell.
[17:39] <NCommander> argh
[17:40]  * Martyn is twiddling with the tegra2
[17:43] <hrw> which image gives x11 on beagleboard?
[17:55] <persia> hrw: have you tried either of the omap netbook variants?
[17:58] <hrw> only when it did not support usb
[17:59] <persia> Well, either try again, or use an image you know works, and install some desktop environment (e.g. apt-get install ^ubuntu-netbook)
[18:03] <hrw> desktop rebooot time
[18:03] <hrw> /nick/
[18:13] <lrg> GrueMaster: yes
[18:13] <GrueMaster> If you get a chance, do you think you could enable jack detection?
[18:14] <GrueMaster> Not critical for Lucid, but would be nice to have,
[18:14] <lrg> GrueMaster: on which platform ?
[18:14] <GrueMaster> babbage 3 and dove.
[18:15] <lrg> I have niether
[18:15] <lrg> it's simple to add
[18:15] <lrg> grep for jack in sound/soc
[18:15] <lrg> there are quite a few examples
[18:16] <GrueMaster> Ok, that's what I thought.
[18:16] <GrueMaster> Thanks.
[18:16] <lrg> and there is still time before the next merge window :)
[18:16] <GrueMaster> It would have to go into an sru release.
[18:17] <GrueMaster> But if I get time, I'll look into it.  Thanks.
[18:21] <persia> GrueMaster: lrg: If it's only nice-to-have for lucid, it's still best to get it done, and pushed in this merge window, so that when the kernel team pulls for maverick, it's already there.
[18:22] <lrg> persia: I agree, although I have not free time for implementation, but I will review and upstream if GrueMaster can provide a patch.
[18:22] <GrueMaster> What is the time window?  I have a convention I am leaving for tomorrow, and won't be back until Monday.
[18:23] <lrg> GrueMaster: well we are at 2.6.34-rc5 atm, so I'd say another few weeks
[18:24] <GrueMaster> Ok.  I can probably work on it late next week.
[18:28] <GrueMaster> This could be interesting.  I've worked on HD Audio side of alsa before, but not the SOC or AC'97 stuff.
[18:30] <Martyn> plus one of the whole points of the new LTS system, is that it allows for real kernel updates
[18:30] <Martyn> which is a nice changed policy
[18:31] <persia> Well, kinda.
[18:32] <persia> There's issues with that, and how far it can go,etc.
[18:32] <persia> We'll see how it works, but *don't* expect that new upstream kernel releases will all magically drop into 10.04.x
[19:00] <Martyn> persia : That it was accepted at /all/ is a good thing
[19:00] <Martyn> because LTS releases are few and far between, they must be able to update and roll with the times
[19:24]  * GrueMaster stopped using Redhat after 7.2
[19:24] <GrueMaster> (before they said there was no future in Desktop Linux).
[20:19] <hrw|gone> I use Debian since 1999
[22:09] <jc_> hi
[22:09] <persia> Hey.
[22:10] <jc_> so is apple going to buy arm or not?
[22:11] <jc_> i hope it doesn't stiffle any dev on ubuntu and arm....
[22:12] <DanaG> Frankly, I don't trust Apple.
[22:12] <DanaG> \][p
[22:12] <DanaG> [iuaA-]
[22:12] <DanaG> P-P
[22:12] <DanaG> er
[22:12] <DanaG> sorry, wiping keyboard.\
[22:13]  * persia suspects there are better forums for speculation
[22:13] <DanaG> though P-P looks like a funky smiley.
[22:13]  * persia also suspects that it's unlikely that corporate ownership will significantly affect the ISA in the short term.
[22:54] <videorechner> Mhm I like the idea, mac minis with arm cortex a9 MP, low power consumption and ubuntu can still be installed
[22:59] <persia> Maybe.  There's issues related to that specific implementation of GPT in lucid, although they may be fixed in the future.
[23:13] <asac> bug 561874
[23:13] <ubot4> Launchpad bug 561874 in f-spot (Ubuntu) "NULL Reference exception in F-Spot (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/561874
[23:19] <sveinse> Is there any here now who happens to have worked with JTAG against TI OMAP?
[23:22] <persia> Anyone know if there is an existing bug number for both desktop-webmail and evolution being on ubuntu-netbook/armel ?


[05:15] <Kilos> hi all, who activates the cloaks for ubuntu members?
[05:15] <Kilos> i see pavlushka  without his cloak and his mebership expires in 2022
[05:16] <Kilos> mebership/membership