[00:36] <tlp> Hi. Apparently my Lucid filesystem contains inconsistencies and requires me to run fsck manually. The problem is, I can't ssh in and I have no option for a command prompt. Is there any way to get one, or do I have to use a LiveCD?
[00:36] <tlp> I've got Plymouth, apparently.
[00:38] <Sarvatt> holding shift while booting will bring up the grub menu where you can pick recovery
[00:38] <tlp> cool. thanks
[00:46] <tlp> heh. fsck is caught in an endless loop. The process dies because it wants me to run it manually, and then Ubuntu runs the command again. So no command prompt in recovery mode either.
[00:51] <slangasek> for which filesystem?
[00:52] <slangasek> what's supposed to happen is that mountall exits with an error, triggering the mountall-shell job
[00:52] <tlp>  /dev/sda1
[00:52] <tlp> that's the behavior I expect, yeah
[00:52] <slangasek> I mean, what's the mountpoint
[00:52] <tlp> I think it
[00:52] <slangasek> is this the root filesystem?
[00:52] <tlp> er, it's /
[00:52] <tlp> yes
[00:53] <slangasek> so as a workaround, I would suggest setting init=/bin/sh and manually running the fsck
[00:53] <slangasek> and then rebooting
[00:53] <tlp> ok. seems like something worthy of a bug report
[00:54] <slangasek> after you've done that, please file a bug on mountall, yes
[00:55] <ion> tlp: Did i get this right, you have Plymouth, but it doesn’t ask (graphically, that is, along with the Ubuntu logo) whether to fix the filesystem problems?
[00:56] <tlp> I may have been confused, because I wasn't sure what bheavior to expect, but I'll reboot now to confirm that's true.
[00:56] <tlp> when I got home, the Ubuntu boot logo was on the screen and nothing else. I imagine there was a power outage or something and it stalled on fsck.
[00:58] <ion> Things not quite working well when Plymouth isn’t available is a known problem and will be fixed for Lucid. I was under the impression things like what you’re encountering should work by now when Plymouth is available. I haven’t tested that myself, though.
[00:58] <tlp> oh. No, Plymouth doesn't seem to do anything special
[00:59] <slangasek> in cases where interaction is needed, mountall is supposed to exit, triggering mountall-shell, triggering plymouth to exit
[01:00] <tlp> I see what looks like a loading bar briefly, which then disappears. If I press escape to make Plymouth die, I see the fsck error
[01:00] <slangasek> chances are you'd get better output if text display wasn't broken in the version of plymouth in the archive
[01:01] <ion> Looking at the source, the current version of mountall should tell Plymouth to say ‘%s filesystem has errors [SIFM]’ and if the user hits F(ix), it should run fsck again with mnt->fsck_fix = TRUE.
[01:01] <slangasek> that'll be fixed soon, but I wanted to give Keybnz a chance to review it before uploading
[01:02] <ion> But yeah, as i said, i haven’t actually tried any situation where mountall asks plymouth to output text.
[01:03] <slangasek> ion: are you interested in building plymouth out of bzr and putting it through its paces, to see whether my changes are OMGbroken?
[01:03] <slangasek> I'm not sure Keybuk will have a chance to review before next week, and I don't really want to upload straight to the archive without getting other eyeballs on it
[01:03] <ion> slangasek: I’ll do that today, after some sleep.
[01:03] <slangasek> ok :)
[01:04] <ion> tlp: So, assuming Plymouth text rendering is broken, perhaps try hitting F blindly instead of escape and see if it magically runs fsck with the right flags to fix the filesystem. :-)
[01:05] <tlp> k, will do
[01:06] <slangasek> zul: finished my analysis of nmbd upstart conversion - bug #513035 is a blocker
[01:07] <tlp> ion: nope, doesn't seem to do anything
[01:09] <ion> tlp: Anyway, booting with init=/sbin/sulogin (or init=/bin/sh for a works-for-sure but less friendly shell) and running fsck -C0 -y /dev/<device> manually should work.
[01:10] <tlp> yeah, I think I can fix it. Just wanted to test your theory; thanks for the help everyone. Wasn't sure where to take this question/report, since I know this isn't a support channel.
[01:10] <slangasek> tlp: I'm afraid we're well into "development" territory here, so it's clearly on-topic :)
[01:13] <tlp> that was my rationale :p
[01:14] <zul> slangasek: cool...interesting
[01:17] <slangasek> zul: that's actually the /lesser/ blocker; the /greater/ blocker is the one I allude to in the description, that 'start on event1 and net-device-up' will cause 'ifup' to hang in some cases... I need to dig into eucalyptus to make a solid case for making that event asynchronous
[01:20] <zul> ah
[01:26] <ion> slangasek: Unless i remember incorrectly, Keybuk has already said the blocking behavior was a mistake that should be fixed. :-)
[01:26] <slangasek> ion: the blocking behavior of /etc/network/if-up.d/upstart?   that's not what he told me last
[01:26] <ion> Hm, ok, i must have mixed that up with something sadmac@#upstart said.
[01:27] <slangasek> well, he may have told you something different, perhaps based on new information he didn't have when he talked to me :)
[01:27] <ion> I think it’s most probable i remembered incorrectly.
[01:29] <ion> Oh, sorry, i misread your initial line. I must be tired. :-) I missed the part about ifup blocking and thought you were talking about event1 blocking until net-device-up just because $randomjob has that ‘start on’ stanza.
[01:30] <slangasek> well - fixing that would make it irrelevant whether ifup is blocking or non-blocking, but that's the *hard* bug that we know's not being fixed in lucid
[01:30] <ion> As for ifup blocking, hmm. That *is* a problematic case indeed.
[01:37] <InvaderZim> help. i patched uvcvideo module for a webcam to work, and it worked, but the module was at /extra/ and the old one at the kernel tree. so after rebooting it stopped working. dmesg now gives errors typical of a module requiring a newer kernel... now i cant revert back to the old error message before patching (which was just one line of error)... I think depmod or someth has cached the problematic uvcvideo module symbols, and doesnt matter which driver 
[01:53] <InvaderZim> no one?
[03:44] <tlp> slangasek: Looks like someone beat me to it with bug #501801
[06:04] <pitti> Good morning
[06:06] <pitti> asac: argh, now firefox does it again
[06:06] <pitti> it worked yesterday, hrm
[06:14] <pitti> asac: hacking extensions.{ini,rdf} is a bit inconsistent, but I think it's either the  langpacks (which are currently broken anyway and need to be updated to 3.6) or vimperator
[06:21] <pitti> asac: ok, got it again, and I didn't have vimperator installed this time
[06:21]  * pitti blames the outdated langpacks
[07:00] <dholbach> good morning
[07:04]  * pitti hugs dholbach
[07:05]  * dholbach hugs pitti back
[08:56] <lifeless> cjwatson: ~cjwatson/debian-installer/main/.bzr is deprecated ...
[08:56] <lifeless> cjwatson: can I convince you to upgrade it ? :)
[09:10] <tseliot> pitti: my upload of ia32libs got stuck at 606673k/606674k for the 2nd time now (and it takes hours for me to upload it). Any ideas of what's going on?
[09:10] <pitti> tseliot: LP just went down
[09:10] <pitti> for upgrade
[09:10] <pitti> argh, you're doing that at home? poor you
[09:11] <pitti> tseliot: I did ia32-libs updates on a porter box (ronne) in the DC
[09:11] <tseliot> pitti: ok, but it failed last night too
[09:11] <pitti> build binaries there, and scp them to my box for testing
[09:11] <pitti> tseliot: no idea about last night, though
[09:11] <tseliot> pitti: can you explain me how I can do that (in private) please?
[09:11] <pitti> tseliot: perhaps you can rsync it against the current versino to chinstrap and dput from there?
[10:00] <asac> pitti: do you have xul-ext-greasemonkey?
[10:02] <pitti> asac: not right now; that one might actually have been the culprit indeed
[10:02] <seb128> re
[10:02] <asac> pitti: i can reproduce ffox not starting twice with that
[10:03] <asac> and seb too ;)
[10:03] <seb128> une daily chart is 17.5 seconds
[10:03] <seb128> asac, do you know if somebody opened a bug btw?
[10:03]  * asac hopes its just greasmonkey and not system extensions in general
[10:04] <pitti> seb128: uh, with 2.6.32-11?
[10:04] <pitti> I can't get it below 20 with that kernel
[10:05] <seb128> pitti, no, still -10
[10:05] <pitti> ah
[10:05] <seb128> I don't know how you get linux upgraded
[10:05] <pitti> the one with broken suspend
[10:05] <seb128> I use update-manager daily
[10:05] <pitti> I reinstalled yesterday
[10:06] <pitti> but usually I'm just using apt-get dist-upgrade
[10:06] <pitti> since jaunty, update-manager doesn't appear any more in the tray, so that's faster
[10:06] <seb128> urg
[10:06] <seb128> I though we were on #u-d ;-)
[10:08] <pitti> seb128: we are..
[10:08] <pitti> the other -d?
[10:08] <seb128> yeah ;-)
[10:29] <pitti> yay, upload works again
[10:29] <pitti> tseliot: ^ FYI
[10:48] <tseliot> pitti: \o/
[10:51] <tseliot> pitti: it only took 16 seconds to upload ia32-libs (it took ~6 hours here...)
[10:54] <pitti> yay phat pipes
[11:26] <geser> could an archive-admin please remove the old texlive-base-bin package (it's in NBS now)? texlive-binaries provides texlive-base-bin and all packages on http://people.canonical.com/~ubuntu-archive/NBS/texlive-base-bin have an unversioned dependency on texlive-base-bin so they continue to be installable with texlive-binaries. the only exception is jadetex but ther is bug #511399 waiting on sponsoring
[11:26] <geser> to get it fixed.
[11:27] <geser> this should get some FTBFS resolved caused by the TeXLive update as the buildds try to install the old (now uninstallable) texlive-base-bin instead of texlive-binaries and complain about it
[11:50] <directhex> Riddell, was it you who OK'd chromium-browser?
[11:55] <Riddell> directhex: yes
[11:56] <directhex> Riddell, how does one go about getting an exception to the usual "no bundled $everything please" rules that are widely understood to govern getting things accepted?
[11:57] <Riddell> directhex: there is no such rule for getting into the archive
[11:57] <Riddell> you're probably thinking of main inclusion requests
[11:57] <Riddell> which aren't my area
[12:00] <directhex> Riddell, so an upload with 40 meg of bundled source wouldn't get rejected on principle?
[12:00] <directhex> assuming a valid debian/copyright of course
[12:02] <asac> directhex: there we want to provide a great experience. software like chromium firefox without bundled third party wouldnt be able to exist given how the system libs progress/regress in different ubuntu releases
[12:04] <Riddell> directhex: as an archive admin I care about licencing, namespace pollution and making sure the package actually has some source code and was ment to be uploaded, how it builds it's interesting.  it will cause problems for the MIR though if the security guys have anything to do with it
[12:08] <directhex> Riddell, roger. i'll take that as a green light
[12:29] <apw> pitti, where we have blueprints with no work items, what do you think of faking an item on the owner for the blueprint of 'specifiy initial tasks' or similar
[12:29] <apw> such that we end up with something in there
[12:38] <pitti> apw: usually you should get a mail with "this bp has no WIs"
[12:39] <pitti> but sure, a fake WI works, too
[12:39] <pitti> I need to leave for ~ 1.5 hours
[12:39] <apw> ack
[12:50] <rah> is changing the default search engine of redistributed firefox binaries permitted by the firefox license?
[12:53] <directhex> rah, it wouldn't be Free Software if it wasn't permitted
[12:55] <rah> directhex: you mean this software which isn't distributed by Debian, wouldn't be free software? :)
[12:56] <directhex> rah, trademarks & software licensing are distinct issues. the former drove the decision to produce an unbranded version in debian
[12:56] <rah> directhex: both are also cognate issues; they are both issues of intellectual property licensing
[12:57] <rah> directhex: but none of this addresses the issue of whether changing the default search engine in redistributed firefox binaries is permitted by the mozilla foundation?
[12:57] <directhex> rah, "intellectual property" is a made-up term designed to confuse different sections of law. but, regardless, the software license for firefox absolutely cannot say "this section is invariant, i.e. you may not change it" without it becoming non-free
[12:58] <rah> the idea of the default search engine being some "section" of the software seems odd
[12:59] <rah> it seems more odd than considering the firefox branding images to be a "section" of the software
[12:59] <directhex> see also: http://popey.com/blog/2010/01/26/yahoobuntu/#comment-1905
[13:04] <directhex> the default search engine is absolutely a question of source. a Yahoo search provider is already upstream, in mozilla/browser/locales/en-US/searchplugins/yahoo.xml
[13:05] <directhex> so it's changing 1 line to make that one the default rather than google.xml
[13:21] <apw> pitti, the update process for the work-items db, how does that work, do you just write over the original db?  I seem to be getting partial db's at cirtain times of the hour
[13:22] <apw> pitti, it also appears to be completing between :40 and :50 now when it used to be done between :10 and :20 normally
[13:25] <Riddell> ev: for kubuntu netbook we need to enable the netbook workspace at bootup of the live environment which I know how to do in casper and also for the installed environment, how do I do that?
[13:29] <ev> Riddell: one option would be to put a script to do it in /usr/lib/ubiquity/target-config
[13:36] <Riddell> ev: that looks like just the thing, thanks
[13:36] <ev> sure thing
[13:43] <d1b> ok what's with the move to yahoo?
[13:44] <soren> d1b: Don't know. What /is/ with it?
[13:44] <d1b> https://lists.ubuntu.com/archives/ubuntu-devel/2010-January/030065.html
[13:44] <soren> Yes...
[13:45] <d1b> seems like a short sighted move.
[13:45] <soren> d1b: Rick explains what and why pretty well, I think.
[13:45] <d1b> soren: i don't.
[13:45] <soren> Hence my question:
[13:45] <soren> 14:44:10 < soren> d1b: Don't know. What /is/ with it?
[13:46] <d1b> soren: well this is funding microsoft
[13:46] <d1b> which contributes to bug 1
[13:47] <ogra> d1b, what makes you think that ?
[13:48] <d1b> ogra: yahoo uses bing for its search engine now
[13:48] <d1b> that costs yahoo and microsoft gets paid for it
[13:48] <ogra> d1b, wrong
[13:48] <d1b> ogra: yahoo pays ms
[13:48]  * soren has a difficult time getting worked up about the whole one proprietary web service by default vs. another proprietary web service by default
[13:49] <ogra> d1b, you should inform yourself before ranting :)
[13:49] <d1b> ogra: i have
[13:49] <ogra> d1b, they share the revenue from ads
[13:49] <soren> ogra: Yahoo search engine is backed by Bing. Since around 6 months ago.
[13:49] <ogra> soren, thats right
[13:49] <ogra> soren, i just say the assumption that yahoo pays for it is wrong
[13:49] <d1b> ogra: ok fine they don't pay ms, but ms still profits
[13:50] <soren> ogra: Ah.
[13:51] <ari-tczew> soren: have you got time for sponsoring?
[13:51] <ari-tczew> note: small merges
[13:52] <soren> ari-tczew: Depends on what it is. I've got a pretty hefty fever today, I'm not exactly clearheaded, so if you can find someone else... :)
[13:52] <ogra> d1b, well, effectively yahoo pays for ubuntu development through the mentioned agreement in the mail, i wouldnt say that raises MS market share in any way
[13:53] <ogra> i'D rather say it lowers :)
[13:53] <ari-tczew> soren, I'm looking for any sponsor too long
[13:53] <soren> ari-tczew: For which package?
[13:53] <d1b> http://www.chuckfrain.net/blog/2010/01/26/forced-changes-in-my-browser/
[13:53] <highvoltage> yes I'm with soren on this one. it's just one proprietary search engine for another. big deal.
[13:53] <ari-tczew> soren, bug 503136
[13:53] <highvoltage> (yahoo's home page is way more sleezy though, showing me ads to work from home and make lots of money)
[13:54] <soren> ari-tczew: I have /no/ clue about dmraid.
[13:54] <d1b> highvoltage: yes but ubuntu is then funding ms.
[13:54] <ari-tczew> soren, maybe this? bug 499671
[13:54] <ogra> by earning money from ms ?
[13:55] <soren> d1b: Microsoft pays Yahoo. Yahoo pays Canonical.
[13:55] <ogra> how is that funding
[13:55] <ogra> its lowering their income ...
[13:55] <soren> ari-tczew: sorry, I'm not your man today. I'm trying to focus on super simple things I know all about already. :)
[13:55] <lool> Does someone know which kernel configs upstart needs?
[13:56] <lool> I'm trying to figure out why I get Event failed errors when using a qemu armel versatile kernel
[13:56] <d1b> ogra: microsoft pays yahoo sure, by using yahoo microsoft profits.
[13:56] <ari-tczew> thanks for all sponsor for main. I always know that you are very helpful team.
[13:57] <micahg> d1b:  a little more funding for MS won't make them any bigger...a little more funding for Canonical probably will, also IMHO, bug 1 is to get MS out of first place, not crush them entirely
[13:57] <Riddell> ev: committed to casper, could you do a quick check?  bash is so easy to make mistakes in
[13:57] <ogra> in any case thats a totally offtopic discussion for this channel :)
[13:58] <lool> Riddell: You mean busybox?  ;)
[13:58] <d1b> next up on the mailing list, ubuntu to use the windows kernel, "we were paid for it"
[13:58] <Riddell> lool: mm, even more easy to make mistakes in
[13:59] <d1b> erh sorry, it just seems that way to me atm.
[13:59] <d1b> i know ubuntu needs revenue.
[13:59] <d1b> just if it was handled better (gui that suggests yahoo and has other options)
[14:00] <ion> pitti: Great work with desktop-lucid-startup-speed, btw.
[14:00] <lool> Riddell: You need to +x the scripts
[14:01] <Riddell> lool: thanks, fixed
[14:06] <lifeless> pitti: if I have a bunch of tracebacks, do you know of somthing that will group them?
[14:10] <ev> Riddell: did you commit to lp:ubuntu/casper?
[14:11] <pitti> slangasek: tkamppeter mentioned that GSoC project, but it won't land in time for lucid
[14:12] <pitti> apw: update process> it's one big transaction, so most of the time it's just writing its journal
[14:12] <pitti> apw: between 40 and 50? that rather sounds like the one on macaroni? people updates at :05, as before
[14:12] <pitti> ion: \o/
[14:13] <apw> pitti, hrm ... ok sounds like i am getting my data from the wrong place
[14:13] <pitti> lifeless: if they get submitted as apport-generated bugs, they will be auto-duplicated
[14:13] <tseliot> pitti: can I upload jockey after I (successfully) test it or shall I wait?
[14:13] <ev> Riddell: context> 16:51 <cjwatson> superm1,pitti,ev: please note for future commits that casper is in lp:ubuntu/casper now rather than lp:caspper
[14:13] <pitti> lifeless: in theory that functionality is available in python-apport as well, but it's not a two-liner to set it up; do you need this locally for something?
[14:14] <pitti> tseliot: go ahead; please just ensure that you commit the changes to trunk, and merge from that
[14:14] <Riddell> ev: hmm, I did not
[14:14] <pitti> tseliot: like, the do_blacklist change, etc.
[14:15] <tseliot> pitti: ah, ok, I won't apply the changes directly to ubuntu-core-dev. The handlers will still need to be updated manually I guess
[14:15] <tseliot> as the ones in trunk are older than the ones in ubuntu-core-dev
[14:17] <Riddell> ev: merged, how confusing
[14:17] <apw> pitti, however i just updated and got the same partial update i get from the macaroni one
[14:17] <apw> i bet i get a fuller update at 20 past
[14:17] <pitti> apw: right, people is currently running
[14:18] <pitti> apw: just weird that it already commits stuff
[14:18] <pitti> it's one big transaction
[14:18] <apw> pitti, is this thing updateing these db's in place, ie direct to lucid.db, and not to lucid.db.new then renaming
[14:18] <pitti> apw: yes, in-place
[14:18] <pitti> sqlite handles locking itself usually
[14:18] <apw> right but thats no use if one is copying the db over wget
[14:18] <pitti> apw: grabbing the people db at :30 should work fine; it's usually taking until :15 or so
[14:19] <apw> and the db is appearing empty
[14:19] <ev> Riddell: looks good
[14:19] <apw> it might be nice to just have; cp lucid.db lucid.db.tmp; mv lucid.db.tmp lucid.db.stable
[14:19] <apw> and then people who need to do what i am can just take .stable and get a complete clean db always at any time
[14:19] <Riddell> ev: groovy, I'll upload
[14:20] <apw> and not have to know when you are updating
[14:20] <lifeless> pitti: yeah, we're categorising udd package import failures
[14:21] <lifeless> pitti: e.g. http://package-import.ubuntu.com/failures/wine
[14:23] <pitti> lifeless: python -c 'import apport.crashdb; help(apport.crashdb)' describes the CrashDatabase of apport
[14:23] <lifeless> pitti: thanks
[14:23] <pitti> lifeless: in essence, you init it with a .db filename (sqlite), and keep calling check_duplicate()
[14:23] <lifeless> pitti: does it really need a db ?
[14:24] <pitti> lifeless: well, you need to store the "known" master signatures somewhere
[14:24] <pitti> lifeless: the sqlite usage is pretty well woven into this
[14:24] <pitti> lifeless: the downside is that it is designed to work with a "crash database"
[14:24] <pitti> lifeless: apport has an in-memory one, so you don't need Launchpad
[14:25] <pitti> lifeless: if you neither want a sqlite db, then perhaps it's better to just reimplement it
[14:25] <pitti> it's not rocket science, after all
[14:25] <lifeless> pitti: :)
[14:25] <lifeless> I shall poke at it - thanks!
[14:25] <pitti> lifeless: look at /usr/share/pyshared/apport/report.py, def crash_signature()
[14:26] <apw> pitti, so what do you think about making a stable copy of the db available at the end of the run
[14:26] <pitti> lifeless: that turns a traceback (or signal crash, etc.) into a "primary key" which the retracer uses for identifying dupes
[14:27] <pitti> lifeless: so you need to store those signatures somewhere (that's the sqlite db that I mentioned), and for every incoming exception you calculate the signature and look it up
[14:27] <lifeless> pitti: does your code do fuzzy matching?
[14:27] <lifeless> I guess you mask our variables while making the key
[14:27] <lifeless> s/our/out/
[14:27] <pitti> lifeless: no, it just chains the top 5 function names and the exception name
[14:28] <pitti> which seems to work well for "general" crashes
[14:28] <pitti> i. e. ignoring arguments
[14:28] <pitti> but after that, only strict matching
[14:30] <lifeless> pitti: thanks a lot; we may not end up doing anything but thats a really good pointer.
[14:35] <BenC> I'm loving this new enforcement of being identified to be in certain channel
[14:41] <lool> Ok so my upstart issue might be that udev wasn't starting due to lack of inotify support
[14:42] <lool> What I was seeing was the "mounted /dev" event being generated but then nothing at all and a /core from /sbin/init but init still running
[14:56] <micahg> pitti: do you remember on hardy if you can use apport for packages from PPAs?
[14:57] <lool> Bah my kernel is 2.6.30 and I need 2.6.32 for devtmpfs
[14:58] <pitti> micahg: independently of the release, apport generally disallows filing bugs for PPA packages
[14:58] <pitti> micahg: some package hooks (like ubuntuone) overwrite that, though
[14:58] <micahg> pitti: so I can disable it in the firefox hook if I want to get bugs?
[14:59] <pitti> micahg: yes; I don't think that worked in hardy yet, though
[14:59] <micahg> pitti: ok, it'll be useful for future and current testing in Karmic and up though
[15:00] <pitti> micahg: ISTR that asac already asked me about that; not sure, perhaps the current daily PPAs already have that
[15:01] <micahg> it doesn't seem to work for the firefox 3.6 package we made, but I can look at ubuntuone as an example
[15:02] <micahg> thanks pitti
[15:06] <asac> pitti: we are concerned about hardy-jaunty too ...
[15:06] <asac> or will hardy just always work?
[15:07]  * ogra is mr superbrave and runs update-manager -d now
[15:08] <mvo> ogra: ohhh, http://people.ubuntu.com/~mvo/automatic-upgrade-testing/current/
[15:08]  * ogra looks
[15:09] <mvo> ogra: it will probably go ok, its mostly file overwrite issues that are left and the gui upgrade runs with --force-overwrite
[15:09] <ogra> looks ok i only have ubuntu
[15:09] <ogra> we'll see
[15:09] <ogra> if i encounter probs i'll moan loudly :)
[15:36] <zul> pitti: ping
[15:36] <pitti> pong
[15:37] <zul> pitti: for the psycopg2 MIR i split of the testsuite into a seperate package like when did for puppet
[15:37] <pitti> zul: oh, why that?
[15:37] <zul> so it can be integrated in to the qa-regression testsuite
[15:37] <pitti> I thought it was just part of the source
[15:37] <pitti> ah, I see
[15:37] <pitti> nice
[15:38] <zul> pitti: so I think that one can be promoted now if you agree
[15:38] <ogra> pitti, hmm, i see a workitem for a spec of mine on the tracker listed twice (one time its done the other its todo)
[15:39] <ogra> http://people.canonical.com/~pitti/workitems/canonical-mobile.html "Move uboot-imx to main to use it from the image build machines"
[15:39] <pitti> ogra: weird; can you please file a bug about it?
[15:39] <ogra> err, sorry, todo and postponed
[15:39] <ogra> will do, whats the product ?
[15:39] <pitti> ogra: ah, nevermind
[15:40] <pitti> ogra: there _are_ two work items on https://blueprints.edge.launchpad.net/ubuntu/+spec/mobile-lucid-imx51-debian-cd-to-uboot
[15:40]  * ogra checks 
[15:40] <pitti> one as todo, one as postponed
[15:40] <ogra> there shouldnt be
[15:40] <pitti> that's a side effect of duplicating WIs
[15:40] <ogra> oh A3 vs overall
[15:40] <pitti> they won't dupe on teh per-milestone chart, but of course they will on the "entire release" one
[15:41] <ogra> yeah
[15:41] <ogra> sorry for the noise
[15:41] <pitti> np :)
[15:41] <randomaction> Do I need to file a sync request for a package recently added to Debian (now in testing)? It's not in Ubuntu yet.
[15:41]  * ogra really hates the CSS layout of the spec pages ... the whiteboard became totally unreadable with that column setting
[15:44] <dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek Day 3 starting in #ubuntu-classroom (on irc.freenode.net) in 16 minutes
[15:46] <pitti> randomaction: those regularly get imported, so now you don't need to yet
[15:46] <randomaction> pitti: ok thank you
[15:51] <dholbach> kirkland, DktrKranz: if you hop into #ubuntu-classroom now, I'll op you
[15:51] <kirkland> dholbach: done
[15:51] <dholbach> kirkland: thanks
[15:54] <lool> I dont get why "initctl emit mounted MOUNTPOINT=/dev" fails; I reduced the script to an echo and a MAKEDEV fd
[15:58] <ogra> seb128, could bug 512959 be caused by the fact that libgtk2.0-common was upgraded on armel but libgtk2.0 itself wasnt yet due to ftbfs (it just built now buit isnt published yet)
[15:58] <seb128> ogra, no
[15:58] <seb128> ogra, libgtk2.0-common is empty basically
[15:59] <seb128> ogra, it has translations on debian but those move to langpacks
[15:59] <ogra> oh, k
[15:59] <seb128> ogra, and some gtkrc which didn't change for years
[15:59] <ogra> i just didnt see the issue yet and doing a dist-upgrade doesnt update nautilus
[15:59] <ogra> http://paste.ubuntu.com/363941/ is all i get
[16:00] <ogra> gnome-session was ftbfs as well i had to give it back today
[16:00] <seb128> ogra, well upgrade and see if you get the issue
[16:00] <seb128> or if that's a one box issue
[16:00] <ogra> right
[16:00] <DktrKranz> dottedmag: there I am
[16:00] <ogra> well, we also have different silicon, plars is on a babbage 3.0 i'm on a 2.5
[16:01] <DktrKranz> dottedmag: sorry, bad ping :)
[16:01] <DktrKranz> dholbach: there I am
[16:01] <ogra> so it could even be HW version related (though thats rare)
[16:01] <dholbach> DktrKranz: opped you
[16:01] <plars> ogra: I'm also seeing it on imx51 now
[16:01] <plars> err
[16:01]  * DktrKranz hugs dholbach 
[16:01]  * dholbach hugs DktrKranz back
[16:01] <plars> ogra: sorry, meant to say that I see it on both dove and imx51
[16:01] <seb128> ogra, try upgrading by steps maybe
[16:01] <seb128> ogra, ie apt-get install the new libglib2.0-0 first
[16:01] <seb128> try with that
[16:01] <seb128> etc
[16:02] <ogra> to late
[16:02] <seb128> ogra, ok
[16:03]  * ogra reboots to see if it shows up
[16:06] <ogra> yup, seems i have it too now though that looks more like gnome-session, nothing comes up at all
[16:06] <ogra> i have a wallpaper
[16:06] <ogra> and spinning cursor
[16:07] <plars> ogra: yeah, that's nautilus in a restart loop in the background
[16:07] <ogra> ogra@babbage2:~$ tail -1 .xsession-errors
[16:07] <ogra> *** stack smashing detected ***: nautilus terminated
[16:07] <ogra> yup
[16:17] <slangasek> ion: any luck with bzr plymouth?
[16:18] <ion> slangasek: Sorry, didn’t get around to testing yet.
[16:19] <slangasek> ion: no worries.  when do you think you would have a chance?  should I find some other victi^W volunteers?
[16:19] <ion> slangasek: I’m still going to test it today. Perhaps in 30 minutes or so.
[16:19] <slangasek> ok, cool :)
[16:24] <_Groo_> hi/2 all
[16:24] <_Groo_> guys what is the proper channel for networkmanager bugs?
[16:31] <ogra> plars, neither downgrading glib nor gnome-session fixes it :(
[16:53] <mathiaz> cr3: hey - re bug 512632 - kirkland confirmed it
[16:53] <mathiaz> cr3: which version of lucid have you used to run the test?
[16:57] <cr3> mathiaz: crap, it was an older version because the iso wasn't being extracted after rsync. I need to look into that
[16:59] <mathiaz> cr3: ok
[16:59] <mathiaz> cr3: kirkland said it was working correctly a week ago
[17:16] <ion> slangasek: The splash didn’t appear in initramfs. Most of the startup seemed to happen in the 80×24 text mode (not 1280×800), then the mode changed and the Ubuntu logo appeared and almost immediately after that X started and the mouse cursor appeared on top of the logo.
[17:16] <slangasek> ion: "most of the startup" - so the initramfs wasn't notably more brief?
[17:17] <slangasek> ion: aside from mouse cursor on the logo, did X start up ok?
[17:18] <ion> slangasek: I don’t know about the speed of initramfs, but the usual after-initramfs startup stuff such as the mountall stuff etc. happened without a KMS mode and without splash. The KMS mode change and the splash appeared a fraction of a second before X. X works fine.
[17:20] <slangasek> oh, hmm
[17:21] <slangasek> perhaps we should force plymouth to finish starting before invoking mountall
[17:21] <slangasek> ion: I think 'or starting mountall' in /etc/init/plymouth.conf should achieve this?
[17:23] <ion> slangasek: I’ll do a bit of debugging and testing. Shouldn’t the splash have started in initramfs already, btw?
[17:24] <slangasek> ion: no, /fixing/ that is what I specifically want testing on :)
[17:24] <slangasek> ion: starting the splash in the initramfs slows down the boot
[17:25] <ion> slangasek: What about the ‘/bin/plymouth --show-splash’ line in /usr/share/initramfs-tools/scripts/init-top/plymouth? I seem to be missing something.
[17:26] <slangasek> ion: that script is only included in the initramfs if the 'FRAMEBUFFER' option is set; plymouth was setting this in order to work around a race condition with gdm, the changes in bzr remove this
[17:26] <ion> Ah
[17:27] <slangasek> ion: could you verify that adding the 'or starting mountall' to the start condition gives you more reasonable post-initramfs behavior?
[17:28] <ion> Yeah, i’ll try that. bbl, rebooting and testing.
[17:43] <dupondje> https://bugs.launchpad.net/ubuntu/+source/aptitude/+bug/391035 => can somebody check to sponsor this ?
[17:55] <ion> slangasek: plymouthd seems to be started very early, but for some reason, it takes a long time for the actual splash to get started. I installed bootchart now, let’s see whether it reveals anything interesting. Oh, btw, X doesn’t start correctly every time. Sometimes the splash appears and disappears quickly just as X starts, and i’m left with a mouse cursor on a blank screen. At that point, the startup of the X stuff seems to hang and when i try to ...
[17:55] <ion> ... type anything, it seems as if raw keycodes or soemthing like that get printed to a virtual console. The mouse cursor is still active over that screen.
[17:56] <slangasek> ion: ah, doh :/ well, I'll hold off on uploading this until Keybnz can look at it
[17:57] <slangasek> delayed starting of the splash relative to starting plymouthd is expected, that's largely the race condition that I was trying to fix (but it sounds like I didn't get it completely)
[18:12]  * ogra hugs Keybnz 
[18:13] <ogra> thats the fastest boot i've every seen !
[18:13] <ogra> sad that it makes gdm feel really slow
[18:16] <ogra> i just could reboot the whole day :)
[18:20] <slangasek> ogra: to avoid any accidental productivity increases from not having to wait for boot? :-)
[18:20] <ogra> heh
[18:21] <ogra> well, i actually catch myself waiting for that darn slow gdm greeter now
[18:21] <ogra> its 3sec to X here (i got a really fast SSD that didnt actually speed anything up in karmic)
[18:21] <ogra> so i'm sitting for 7 sec after drumroll and cursor are there and wait for the greeter
[18:22] <slangasek> 7msg Keybnz 3 seconds?  I was promised instant-on!!!1!
[18:22] <ogra> haha
[18:23] <Viper550> Why. Yahoo.
[18:23] <Viper550> It's pretty much just going to be making Bing the default search engine.
[18:31] <ogra> http://people.canonical.com/~ogra/osiris-lucid-20100127-3.png
[18:31] <ogra> i wonder why the greeter takes so long to map something ... its actually starting at 5.5 sec
[18:33] <ion> slangasek: Initramfs is very fast, yes. It seems the main problem with splash coming up late is that it has to wait for udev events, while udev has to wait for mountall to emit virtual-filesystems and mountall has to wait for ureadahead (i have a HDD). But anyway, even if i boot without ureadahead, it takes an annoyingly (that’s subjective, of course) long time for the splash to appear.
[18:34] <slangasek> hmm, ok
[18:34] <slangasek> ion: pre-splash performance is a question I'm going to have to defer to Keybnz; I know plymouth is not intended to be included in the default initramfs, and I saw the impact it had on the benchmark when we had to start including it
[18:48] <ion> slangasek: With no ureadahead, the splash only seems to be active for three seconds. http://heh.fi/tmp/bootchart/no-ureadahead.png
[18:49] <ion> slangasek: This is the bootchart from a boot with plymouth flashing quickly and then X being broken. Plymouth starts awfully close to X – a race condition? http://heh.fi/tmp/bootchart/ureadahead-and-broken-x.png
[18:50] <dupondje> ion: with what tool tou make that bootchart ?
[18:50] <slangasek> meh need text search on boot charts
[18:50] <ion> dupondje: bootchart
[18:54] <slangasek> ion: mountall seems to finish in <2 sec on this system; why does it take udev so long to finish after that?
[18:56] <zul> pitti: python-pastedeploy should be ok now as well
[19:01] <ion> slangasek: In my bootchart, mountall seems to finish in one second and it seems to take less than two seconds from udev to gdm. What do you mean by “so long”? The most curious thing in my bootchart is ureadahead taking so long with low disk throughput. I’ll have to investigate that.
[19:06] <slangasek> ion: the no-ureadahead.png?  I see mountall starting at 4s, finishing at < 6s; then I don't see plymouth called for the first time until 13s, and plymouth-splash.conf should in the worst case start up as soon as plymouth has started and udevtrigger has finished
[19:08] <ion> slangasek: The no-ureadahead bootchart is just to demonstrate that ureadahead delays the splash. Of course, everything will be generally slower without ureadahead having warmed up the cache, that’s the point of ureadahead’s existence. :-)
[19:10] <slangasek> ion: fair enough
[19:14] <directhex> Viper550, because it's a revenue stream for canonical which in real terms is low-impact on users
[19:14] <Viper550> I know, but couldn't mozilla just share its Google earnings with them
[19:15] <directhex> presumably not
[19:19] <slangasek> ion: well, the only way to get the splash screen started sooner is to have the fb device up sooner, and that waits for udev, which isn't slow at all in your second chart - just blocked on ureadahead.  Not sure there's anything we can improve on here (aside from the race condition problem!) that won't negatively impact performance for others
[19:20] <ion> slangasek: Yeah, it’s a tricky thing.
[19:34] <kees> pitti: can we keep lxc out of main for now?  it's very young still and every time I use it I find security issues.
[19:34] <kees> pitti: especially for an LTS
[19:35] <slangasek> who was talking about soyuz sync oopses the other day?
[19:35] <slangasek> seems mono can't sync due to one :/
[20:58] <doko> ccheney: which version of the ubuntu-arm-thumb patch is in the OOo upload? The one with -O2 or the updated one with -fno-schedule-insns?
[21:02] <ccheney> doko: the ones with O2 that were on the bug report as you mentioned in the email
[21:02] <ccheney> when did you change it to -fno-schedule-insns?
[21:02] <doko> today this morning, please could you update it in ooo-build?
[21:02] <ccheney> ok
[21:03] <doko> thanks
[21:08] <ccheney> doko: done