[04:53] <Gemmers> Hello
[04:55] <Gemmers> I'm considering putting ubuntu on my laptop but I have concerns about power management and battery life
[04:58] <Gemmers> I've currently got 512MB ram and a 1.5GHz processor so that should be fine right?
[05:00] <Gemmers> Nevermind I'll try XP
[07:09] <xGismox> Çäðàâñòâóéòå
[16:42] <pihhan> hello
[16:43] <pihhan> what can i do to make hibernating to disk working?
[16:44] <pihhan> it does not work on my new Sony VAIO FZ210CE


[17:37] <toddc> hi
[17:56] <pleia2> hello
[17:58] <toddc> I was just saying hi to mike but he left but hello pleia2 have a good thanksgiving?
[17:58] <pleia2> hi toddc, yes :) I went to the zoo! how about you?
[17:59] <toddc> large family days till today
[18:02] <toddc> zoo sounds fun--note to self buy family pass for Xmas
[18:03]  * pleia2 nods
[18:20] <pleia2> I'm heading over to berkeleylug today, but this event is also happening today in San Mateo: http://loco.ubuntu.com/events/ubuntu-california/2124/detail/
[18:20] <darthrobot> Title: [Let's Build Some 12.04 Desktops! | Ubuntu LoCo Team Portal]
[20:30] <pleia2> at berkeleylug \o/


[06:40] <type3> Hello, I've been on this chat before and have expressed that I'd like to contribute
[06:40] <type3> I was directed by a kind contributor to look at learning GTK
[06:42] <cjbayliss> cool, did you learn GTK?
[07:21] <elfy> ali1234: sorted -- purging and reinstalling systemd-sysv and upstart boots/reboots properly now


[09:57] <zameltout> hallo
[19:17] <Linna> Hi, Does anybody knows why Ubuntu and Kubuntu 12.04 logs out randomly?


[03:39] <spasticteapot> I've got a somewhat snaggeltoothed Ubuntu problem, and I figure I should bring it up here, since I've tried asking just about everywhere else on Freenode.
[03:40] <spasticteapot> I've even offered free beer to whoever can help me fix it on the LUG chatroom. (Admittedly, I myself cannot buy said beer, but I can pay for it at least.)
[03:40] <spasticteapot> Under Ubuntu, as a default, the Gnome applet Network-Monitor has some nifty features relating to wifi - it has the "5 bars" when you're connected, and when you click on it, a drop-down menu appears of various wifi connections. However, after accidentally removing the applet and adding another network-manager applet to my panel, my wifi connection (eth1) is treated as an ethernet connection. Perhaps I could rename eth1 to wlan0
[03:40] <spasticteapot> ? Or fix the applet?
[03:44] <spasticteapot> Also, why is IFrename not in Ubuntu?
[03:45] <wasabi> Believe udev deals with renaming hte interfaces.
[03:45] <wasabi> Also, sound slike a bug. File it.
[03:45] <spasticteapot> udev?
[03:45] <spasticteapot> How do I file it?
[03:45] <spasticteapot> And, more importantly, how do I FIX it?
[03:46] <wasabi> https://launchpad.net/malone/+filebug
[03:46] <wasabi> and I have no idea how to fix it. sounds like a bug.
[03:46] <spasticteapot> I was told to try this for renaming my wireless card:  ifrename - -i eth1 -n wlan0 < /dev/null
[03:46] <spasticteapot> How do I do that with udev?
[03:47] <wasabi> Hurm. I don't think that's related.
[03:47] <wasabi> Also, this isn't the appropiate place to ask, as the topic states.
[04:12] <Amaranth> wasabi: actually his probably was he replaced NetworkManager with network-monitor, from what i can tell :)
[04:26] <wasabi> oh?
[04:26] <wasabi> Oh yeah I see.
[04:45] <spasticteapot> Does anyone know where the list of default applets in the dock in Ubuntu is?
[05:59] <fabbione> morning
[07:40] <pitti> Good morning
[07:41] <Burgundavia> hey pitti
[07:41] <Burgundavia> congrats on getting tribe 1 out
[07:44] <pygi> morning pitti, Burgundavia
[07:46] <pitti> hi Burgundavia
[07:46] <pitti> hey pygi
[07:46] <pitti> thanks
[07:47] <StevenK> pitti: Do you know anything about packages not registering builds?
[07:47] <StevenK> pitti: Hi, by the way. :-)
[07:47] <pitti> StevenK: no, I don't; when was it uploaded?
[07:48] <StevenK> pitti: There are three; the oldest was uploaded just over 24 hours ago.
[07:48] <pitti> StevenK: and published?
[08:20] <StevenK> pitti: All three are published, yes.
[08:20] <pitti> StevenK: hm, you should ask cprov once he gets online
[08:21] <pitti> StevenK: can you tell me an example package?
[08:21] <StevenK> pitti: It appears to be a wider problem with crimsun also just mentioning in -motu
[08:21] <StevenK> pitti: Take your pick of python-qt4, scim-qtimm or libwibble.
[08:22] <crimsun> (yes, was asked about ruby-gnome2)
[08:22] <pitti> at least all buildds are busy
[08:24] <StevenK> pitti: From what I saw, they *look* to be busy, but they aren't updating the logs that show where the build is up to on LP.
[08:26] <pitti> StevenK: oh, hmm; can you please drop by #canonical-sysadmin and ask there? they might know something
[08:29] <StevenK> pitti: About both issues or just the latter?
[08:30] <pitti> StevenK: they might be related
[08:35] <superm1> mdke, ping
[08:35] <mdke> superm1: (In case I'm not around at the moment, please provide a bit of information about what you want and I will respond when I get back)
[08:35] <Hobbsee> yay, contentlessping.pl - the modified version
[08:35] <superm1> mdke, I wanted to poke about our mailing list, we still haven't heard anything more about it from rt or anything
[08:36] <superm1> Hobbsee,  rather than contentless pongs version?
[08:36] <Hobbsee> superm1: sorry?
[08:36] <superm1> Hobbsee, the one that responds something like "You've sent me a contentless ping and this is a contentless pong"
[08:36] <superm1> or something to that effect?
[08:37] <Hobbsee> that's the original contentlessping.pl, iirc
[08:37] <Hobbsee> You sent me a contentless ping.  This is a contentless pong.  Please provide a bit of information about what you want and I will respond when I am around.
[08:37] <superm1> ah
[08:37] <Hobbsee> ^ almost that
[08:37] <mdke> superm1: hi. I'll try chasing by email. What's your mailing list?
[08:37] <superm1> mdke, ubuntu-mythtv was what we were looking to get setup
[08:38] <superm1> mdke, do you want the rt # that we had opened up back in april?
[08:38] <superm1> to include
[08:38] <mdke> yeah, thanks
[08:38] <mdke> email me the details
[08:39] <superm1> okay will do
[08:39] <superm1> thanks mdke
[08:47] <mdke> superm1: got it, thanks
[09:03] <dholbach> good morning
[09:04] <Fujitsu> Hi dholbach.
[09:04] <dholbach> heya Fujitsu
[09:12] <pygi> morning dholbach
[09:13] <dholbach> heya pygi
[09:13] <pygi> dholbach, wanna try something? :)
[09:13] <pygi> (if you have time ofcourse ^_^)
[09:14] <dholbach> what is it?
[09:15] <pygi> that telepathy ncurses IM client? :)
[10:24] <cjwatson_> persia: I put rather a lot of work into reducing the number of questions asked by default way back in Warty, as it happens.
[10:24] <cjwatson> shawarma: I don't think it's written down anywhere. It was one of Mark's mandates right at the start.
[10:25] <persia> cjwatson: My apologies.  I wasn't following the lists as closely then, and missed the changes.
[10:26] <shawarma> cjwatson: Alright, thanks. I was considering deviating from it and was hoping the policy's wording or rationale would provide justification for that, but I may have worked around it now.
[10:28] <cjwatson> persia: (though it's true that the introduction of ubiquity made a big dent)
[10:28] <persia> cjwatson: That's the one I remember :)
[10:28] <cjwatson> yeah, it wasn't a new policy then though
[10:31] <Burgundavia> shawarma: for the server installer, we can treat things a bit differently
[10:31] <Burgundavia> we are targetting a different audience, one that probably knows a bit more
[10:32] <shawarma> Burgundavia: That's what I was thinking, too.
[10:33] <shawarma> Burgundavia: I just need to test this a little bit more. Launchpad says it's a 25 minute build, so it's not that bad.
[10:49] <Fjodor> Does anyone know if Bug #110585 is caused by something in kernels > 2.6.18 and that's why we hit it?
[10:49] <ubotu> Launchpad bug 110585 in debian-installer "7.04 Server install fails on Compaq Proliant DL360" [Undecided,Unconfirmed]  https://launchpad.net/bugs/110585
[10:49] <cjwatson> well, our parted is essentially the same as Debian's
[10:50] <Fjodor> cjwatson: I think the raid controller driver spits some nasty things in dmesg and that's why we can't see anything on it
[10:53] <cjwatson> that should be easy to verify by checking the logs from a second console
[10:53] <cjwatson> parted> (there are differences, but not relevant ones here)
[10:53] <cjwatson> which basically leaves either udev (seems unlikely, as apparently the device node does exist) or the kernel
[10:54] <Keybuk> the power management in gutsy is definitely futzed
[10:54] <cjwatson> Fjodor: you can copy /var/log/syslog to another machine by doing 'anna-install openssh-client-udeb' and then you'll have scp
[10:55] <Keybuk> laptop usually crashes when AC power is disconnected or reconnnected
[10:55] <cjwatson> then please attach it to the bug
[10:55] <Keybuk> and laptop goes to standby when the lid is closed for a while, even though that's marked as "Never" in prefs
[10:57] <Burgundavia> Keybuk: some of it might be related to the new code for profiling batteries
[10:57] <Keybuk> Burgundavia: that code and I are not friends; it decided my battery only lasted for 20mins and shut down my computer!
[10:57] <Fjodor> cjwatson: Actually, the problem is described on the forums (only saw that now). Have a look at http://ubuntuforums.org/showthread.php?t=384319&highlight=dl360 and http://ubuntuforums.org/showthread.php?t=384319&page=2
[10:57] <Burgundavia> Keybuk: tell me about it
[10:57] <Burgundavia> anyway, is 2am here, time to sleep
[10:57] <shawarma> Burgundavia: right, but your battery actually does only last for 20 minutes.. There's a difference.
[10:58] <shawarma> Burgundavia: :-P
[10:58] <Keybuk> oh, and something about NM/dchdbdbdbdbdbd/ipw3945 is broken too
[10:58] <Keybuk> it won't associate with any network until I toggle the hardware switch
[10:58] <Keybuk> (wonder if this is something to do with HAL gaining knowledge of these)
[11:00] <fabbione> Keybuk: you are not the only one that reported this hw switch issue with some wireless cards.. IIRC they were mentioning something in the kernel
[11:01] <Keybuk> could be kernelish, though running dhclient itself just works
[11:01] <Keybuk> (but then that doesn't check such things)
[11:03] <pygi> hey Zdra
[11:05] <cjwatson> Fjodor: thanks; I've added a pointer to the relevant post to the bug
[11:07] <Zdra> hello pygi
[11:07] <pygi> Zdra, have time for trying things? :)
[11:08] <Zdra> not really right now, maybe this evening ;)
[11:08] <Zdra> sorry
[11:08] <pygi> Zdra, evil you :P Oki doki :)
[11:28] <hunger> Are there freenx debs in ubuntu?
[12:58] <pitti> hi thekorn_
[12:59] <thekorn_> hi pitti
[01:01] <pitti> thekorn_: curious, is there an API for deleting attachments in p-lp-bugs now?
[01:02] <thekorn_> pitti: sorry, not now, you need that as soon as possible, right?
[01:02] <pitti> thekorn_: before we can enable apport again for gutsy, yes (and to clean up the existing core dumps)
[01:03] <pitti> thekorn_: is it hard to do? it's just another page scraping/button click, I figure?
[01:04] <thekorn_> pitti: my problem is, that I'm stilll working on changing the API, I started with other parts
[01:05] <pitti> thekorn_: ah, I see; well, then rather do it right, and I'll use a temporary hack if I need it before
[01:05] <thekorn_> pitti: ok cool, thanks
[01:09] <Fujitsu> pitti: What magical stuff is apport going to do this cycle?
[01:09] <fabbione> StevenK: i am looking at your sparc buildd hangs....
[01:10] <pitti> Fujitsu: I finished https://wiki.ubuntu.com/ApportBetterRetracing except for the wine stuff; currently working on https://wiki.ubuntu.com/ApportCrashDuplicates
[01:10] <pitti> Fujitsu: and we urgently need to do https://wiki.ubuntu.com/CrashReporting
[01:10] <pitti> Fujitsu: the approved gutsy specs list has some more apport stuff
[01:15] <Fujitsu> pitti: Looks pretty good; a lot more manageable for triagers.
[01:15] <pitti> Fujitsu: right, that was the idea
[01:17] <Fujitsu> I don't like the working around the lack of version tracking in Malone, though. Why doesn't Malone grow that feature like it should have ages ago?
[01:18] <pitti> Fujitsu: I don't know
[01:19] <Fujitsu> It's more than a bit annoying
[01:39] <StevenK> fabbione: Ahhhh, great. Thanks. You got me there for a moment, I couldn't recall what you were refering to. :-)
[01:40] <fabbione> StevenK: tig builds fine.. i am somewhere in lyx
[01:40] <StevenK> fabbione: I'm not so sure it's a sparc-only problem, to be honest.
[01:40] <fabbione> StevenK: i suggest you talk to one of our sysadmins to get a manual build of tig (since it's small)
[01:40] <StevenK> fabbione: Couldn't we first just requeue it?
[01:40] <fabbione> i don't think the problem is tig.. it might be that the build exercises some very well hidden bug somewhere
[01:41] <fabbione> StevenK: yes.. that's a possibility, but if it hangs forever, it means killing a buildd
[01:41] <fabbione> StevenK: requeue -> manual build -> build test with a different kernel
[01:41] <fabbione> that's the sequence i would do for testing
[01:41] <StevenK> fabbione: Surely it also allows us/you to keep a close eye on the requeued build?
[01:43] <fabbione> me? no.. i don't have access to the buildd.. it needs to be somebody like infinity2 or one of our admins
[01:43] <fabbione> if it hangs, grab some info... what the hell the machine is doing.. etc..
[01:53] <jmg> anyone know about acpi here?
[01:53] <jmg> i managed to boot windows and reenable wireless after gutsy broke it, but i really really want to fix this bug.
[02:13] <fabbione> StevenK: i am going to finish the lyx build, but it's going fine so far
[02:14] <pitti> StevenK: btw, buildd congestion should be fixed now
[02:15] <StevenK> pitti: Yay! What was the problem, in small words?
[02:16] <pitti> StevenK: <elmo> meh
[02:37] <supervillain> hi, anyone knows what 09_double_text.patch does to slab?
[02:37] <Hobbsee> supervillain: did the changelog say?
[02:37] <supervillain> no..
[02:37] <supervillain> it's just right in there
[02:38] <supervillain> but it cannot be applied
[02:38] <supervillain> seems it's for libslab, not slab
[02:39] <supervillain> I get it, slab and libslab are different package now..
[02:39] <Hobbsee> try asking the person who's done the last few updates of slab, i guess.
[03:25] <Hobbsee> pitti: are you on archive duty today?
[03:25] <pitti> Hobbsee: no, Mithrandir would be, but he's on vac
[03:25] <Hobbsee> pitti: i'm wondering how to tell who's done a reject
[03:26] <Hobbsee> or, alternatively, whether b5i2iso is still in the NEW queue
[03:26] <Hobbsee> (uploaded twice, got one reject ~20 mins ago)
[03:26] <pitti> http://people.ubuntu.com/~ubuntu-archive/queue/gutsy/new/
[03:26] <Hobbsee> and i was under the impression that launchpad discarded the old version silently, if it had the same version number.
[03:26] <pitti> it's there
[03:27] <Hobbsee> ....
[03:27] <bhale> https://launchpad.net/ubuntu/gutsy/+queue
[03:27] <bhale> i like this page better.
[03:27] <pitti> Hobbsee: no, it'll be in the NEW queue twice
[03:27] <Hobbsee> pitti: ah right.  cool.  that was the answer to the non-stupid part of the question, then :)
[03:27] <Hobbsee> thankyou
[03:28] <pitti> Hobbsee: ISTR cleaning up the NEW duplicates this morning
[03:28] <Hobbsee> ISTR == i seem to remember?
[03:28] <Hobbsee> pitti: fair enough.
[03:28] <pitti> Hobbsee: that's how you got the reject mail
[03:28] <Hobbsee> yep
[03:28] <pitti> Hobbsee: so if the versions were exactly identical, that's fine
[03:29] <Hobbsee> my brain was working along the lines of "so, if i've got a reject, how do i find out what the problem was?"  But as for forgetting to check the NEW queue...i'll blame work for that one.
[03:29] <Hobbsee> or impending exams
[03:29] <Hobbsee> versions were identical, yes
[03:29] <liri> I've migrated to use Ubuntu Dapper LTS from old Debian Sarge and I'm getting errors to compile my code: In function LKb_RETURN OS_MutexInit(LK_MUTEX*): error: union pthread_mutexattr_t has no member named __mutexkind     The makefile is running with: -D_LINUX -D_REENTRANT -march=i586 -I/usr/include -Wall -pipe -DPTHREADS_SUPPORTED -D_UNIX_THREADS_SUPPORTED -O3 -fforce-addr
[03:30] <liri> and my kernel is 2.6.17-11-generic #2 SMP
[03:30] <pitti> Hobbsee: ok, so all is fine now
[03:30] <Hobbsee> pitti: yeah, thanks
[03:30] <liri> any clues on these libraries? could it be that some functions got deprecated?
[04:07] <shawarma> liri: If your kernel is 2.6.17, you're not running Sarge nor Dapper.
[04:10] <ogra> pitti, ltsp-client was split into ltsp-client and ltsp-client-core, the latter will show up in NEW soon, can you wave it through ?
[04:10] <pitti> ogra: can do; please ping me when you uploaded it
[04:10] <ogra> just did :)
[04:11] <pitti> nothing yet, apparently it missed the :10 run
[04:11] <pitti> in 5 minutes then
[04:11] <ogra> ah
[04:11] <ogra> should be 5.0.11
[04:15] <mvo> racarr: do you have some minutes to help me with https://bugs.launchpad.net/compiz/+bug/119199 ? it seems to be a bug in the gconf plugin of compiz, but I need some hints how to debug it efficiently
[04:15] <ubotu> Launchpad bug 119199 in compiz "[gutsy] latest compiz update causes sytem to lockup when enabling compiz" [High,Confirmed]
[04:18] <pitti> ogra: still nothing
[04:18] <ogra> hmm, i got the mail from drescher
[04:18] <ogra> its on -changes as well
[04:18] <pitti>   225575 | S- | ltsp                 | 5.0.11               | nine minutes
[04:18] <pitti> ^ in accepted
[04:19] <ogra> ah, indeed, its a new binary
[04:19] <pitti> ogra: oh, you mean there's just a new binary package, no new source
[04:19] <StevenK> The source isn't NEW, the binaries are.
[04:19] <StevenK> ogra: Snap.
[04:19] <pitti> ogra: so, it needs to get built first
[04:19] <ogra> :)
[04:25] <pitti> thekorn: hmm, p-lp-bugs doesn't support marking a bug as dup of another one? or is there a trick to it?
[04:27] <liri> shawarma: true, I was trying it on both dapper and feisty
[04:27] <StevenK> liri: 2.6.17 isn't the kernel version from Feisty either.
[04:27] <pitti> liri: 2.6.17 is the edgy kernel
[04:27] <liri> shawarma: anyway I solved the problem by using pthread_mutexattr_settype(&MutexAttr, PTHREAD_MUTEX_RECURSIVE_NP);
[04:30] <thekorn> pitti: I'm sorry, that's still not supported,
[04:30] <thekorn> and I don't know odf any trick
[04:31] <pitti> thekorn: ok, so my preliminary implementation of close_duplicate() will be to just add a comment which points to the master bug
[04:33] <pitti> thekorn: sorry, yet another question: if I get a list of all bugs with a certain tag, does this traverse through all batch pages or just the first one?
[04:40] <dholbach> pitti: all of them
[04:40] <pitti> dholbach: cool, thanks
[04:40] <hunger> Why does "mount -o remount,rw /usr" no longer work on gutsy?
[04:40] <hunger> Reports that /usr is already mounted...
[04:49] <mathiaz> I was going through UbuntuMainInclusionQueue wiki page. I was wondering what is the state of libnss-ldap, libpam-ldap and libpam-mount reports ?
[04:49] <pitti> mathiaz: it didn't get much attention since noone prodded us for them so far
[04:49] <mathiaz> It is stated that they should be rewritten first.
[04:50] <mathiaz> what's wrong with the current reports ?
[04:50] <pitti> mathiaz: they do not match the template and thus are lacking some information
[04:53] <mathiaz> pitti: they seem to follow the template.
[04:53] <cjwatson> they follow the template a little too exactly, IIRC ;-)
[04:53] <cjwatson> unless I misremember
[04:54] <ogra> yeah
[04:54] <ogra> i wanted to rewrite the reports if i need them ... feel free to take them :)
[04:55] <Hobbsee> twitch.  i should write a couple.
[04:55] <ogra> uh
[04:55] <ogra> Hobbsee, have fun :)
[04:55] <Hobbsee> ogra: i believe "delegation" is the term that applies.
[04:56] <pitti> Hobbsee: erk, two KDEs in main? fun
[04:56] <Hobbsee> ogra: but then again...as for how much of it would be new upstream versions of the same apps...
[04:56] <ogra> since we cant script them anymore thats a lot of work ....
[04:56] <pitti> Hobbsee: I'm fine with replacing kdexxx with kde4xxx without an MIR
[04:57] <pitti> Hobbsee: however, having both in main at the same time is a question that deserves to be discussed at least in the distro team meeting
[04:57] <hunger> mathiaz: libpam-mount basically works for me, but it lost some functionality in feisty (for encrypted partitions).
[04:58] <Hobbsee> pitti: you couldnt promote dolphin then, without a MIR, then, i assume?  *g*
[04:58] <Hobbsee> pitti: yeah, true that
[04:58] <Hobbsee> pitti: that's a later discussion - including the one about LTS's and such.
[05:00] <Riddell> no need for kde4 in main any time soon
[05:01] <Riddell> but a main inclusion review of strigi and clicene-libs would be lovely if pitti is looking to do some
[05:01] <Hobbsee> morning Riddell
[05:01] <mathiaz> I guess that libpam-mount is heavily used in edubuntu.
[05:11] <pitti> dholbach, thekorn: hmm, so the BugList ctor takes all those attributes, but if I set the status field to 'Needs Info' I still get all bugs rather than just the needsinfo bugs
[05:11] <pitti> i. e. BugList(Struct(url = 'https://launchpad.net/ubuntu/+source/apport/+bugs', upstream = None, minbug = None, filterbug = None, status = 'Needs Info', importance = '', lastcomment=''))
[05:11] <dholbach> pitti: can you file a bug with a small test case?
[05:12] <pitti> oh, this is only done for 'if opt.upstream and opt.sourcepackage:'; hmm
[05:12] <pitti> I don't want just upstream bugs
[05:12] <pitti> dholbach: can do
[05:12] <dholbach> pitti: rock on - thanks a lot
[05:21] <pitti> dholbach: done; I'll just go ahead and file bugs for the other stuff I need for apport
[05:21] <dholbach> pitti: thanks a lot
[05:23] <pitti> dholbach: hm, noone is subscribed to python-launchpad-bugs
[05:23] <pitti> thekorn: ^ maybe you want to subscribe to that package?
[05:23] <dholbach> bughelper-dev is subscribed to upstream bugs
[05:23] <dholbach> I'll make them subscribed for ubuntu packages too
[05:25] <dholbach> pitti: done
[05:25] <pitti> cool, thanks
[05:25] <pitti> dholbach: so you guys probably just missed my three bug reports, but maybe someone looks at the bug page occasionally :)
[05:27] <dholbach> pitti: will look at them
[05:35] <afflux> hunger: I suppose it's a spelling mistake that your crypttab contains a reference to /dev/vg0/ub_tmp_c and you create the cryptdevice in /dev/vg0-ub_tmp_c? (see your latest cryptsetup bug)
[05:39] <hunger> afflux: That does not matter. both are a symlink to the same /dev/dm-XX
[05:39] <afflux> eh. does dmsetup support mapping a mapped device?
[05:40] <hunger> afflux: I have 7 crypted partitions on that VG, all using the same syntax to address it.
[05:40] <afflux> ah. okay.
[05:40] <hunger> afflux: The other 6 are luks ones and work fine.
[05:40] <afflux> do you get any error messages from cryptsetup?
[05:40] <hunger> afflux: the cryptdisks init script fails... that's all.
[05:40] <afflux> cool. :/
[06:26] <ogra> pitti, ltsp-client-core should be there now
[06:26] <ogra> (at least it built on all arches)
[06:37] <wasabi> Keybuk: you once said this: "Any filesystem that processes file operations out of order is BUGGY!"   In regards to XFS.  Doesn't ZFS do the same thing?
[06:48] <Keybuk> wasabi: operations on a given file should be processed in sequence
[06:48] <wasabi> On a given file, sure, but on two different files?
[06:48] <wasabi> Oh I see what you're saying.
[06:48] <Keybuk> two different files - who cares
[06:48] <wasabi> I think I finally realized where I was hung up.
[06:49] <ogra> pitti, hrm, it needs the xfonts-base dep ...
[06:49] <wasabi> The conversation was about ... XFS not working right during crashes of update-alternatives because it doesn't flush the file before proceeding
[06:49] <Keybuk> right
[06:50] <pitti> ogra: oh, that might be unjustified; I was more concerned about the dependencies/debconf stuff
[06:50] <wasabi> trying to reparse it.
[06:50] <Keybuk> what XFS does is process a rename() call on a given file before all queued write()s on that file have been processed
[06:50] <Keybuk> so you do
[06:50] <Keybuk> open (file, O_RDWR)
[06:50] <Keybuk> write (...)
[06:50] <Keybuk> write (...)
[06:50] <Keybuk> close (...)
[06:50] <Keybuk> rename (...)
[06:50] <Keybuk> and you end up with something on disk that isn't fully written
[06:50] <wasabi> So the writes don't go through, but the rename does.
[06:50] <ogra> pitti, right, inputattach is a bug
[06:50] <Keybuk> yeah
[06:51] <wasabi> But still, shouldn't you be forced to fsync the file if you want to be sure that the contents are on disk, irregardless of order of operations?
[06:51] <Keybuk> I don't think so
[06:51] <wasabi> Does a rename guarentee an implicite sync?
[06:51] <pitti> ogra: nothing too serious, if you fix them in the next version, that's fine
[06:51] <wasabi> Who says that?
[06:51] <ogra> pitti, the debconf stuff must come from a debian merge, we dont use debcof in ltsp-server ... checking where that comes from
[06:51] <Keybuk> I think that certain operations should be guaranteed
[06:51] <pitti> ogra: I just want to wait for sparc
[06:51] <Keybuk> nobody says that
[06:51] <ogra> pitti, ok
[06:51] <Keybuk> it's just the way everything behaved until XFS came along :p
[06:51] <wasabi> Heh.
[06:51] <ogra> i have a 0.12 here anyway already, i'll add the fixes
[06:52] <wasabi> But still, an app that DOESN"T rename, would still have to fsync before moving on.
[06:52] <Keybuk> theoretically that app doesn't care whether it's on the disk or not
[06:53] <wasabi> Depending on the app, it might.
[06:53] <Keybuk> the rename() case is special, since the app is clearly trying to do something atomic
[06:53] <wasabi> u-a seems to be an appropiate situation for that. Since it is basically part of the dpkg transaction.
[06:53] <wasabi> dpkg can't consider the package really completely installed until it's sure all the files are commited.
[06:54] <wasabi> If ti does, then you're talking about corrupt/missing metadata between files (dpkg's database and the installed files themselves)
[06:54] <Keybuk> actually, fsync() doesn't guarantee that either
[06:54] <Keybuk> it just guarantees that the kernel filesystem is in sync
[06:54] <wasabi> It guarentees as much as the kernel can know.
[06:55] <Keybuk> it's an interesting point
[06:56] <wasabi> Anyways, it seems wrong that a crash after dpkg says a package is installed could result in corrupt files being installed because they weren't flushed.
[06:56] <wasabi> At least, it seems as if we're not doing what we can do about it, regardless of hardware caches.
[06:56] <Keybuk> a crash?
[06:56] <wasabi> power failure.
[06:56] <Keybuk> power failure has the same problem though
[06:56] <Keybuk> because of the hardware
[06:56] <wasabi> Yes, but sme people can guarentee the hardware does not cache.
[06:56] <wasabi> For good reason they buy hardware like that.
[06:57] <Keybuk> dpkg could say the status is installed, because that reached the hardware, but the files themselves might not have
[06:57] <wasabi> Or, they can guarentee the hardware is battery backed.
[06:57] <iwj> IMO all of these cases are bugs in the filesystem.
[06:57] <wasabi> If their software is undermining that.
[06:57] <Keybuk> wasabi: if they can guarantee that, they can guarantee the same things from the filesystem, no?
[06:57] <wasabi> Hmm. Thinkging. One sec. ;0
[06:57] <iwj> You use fsync if you mean `this data needs to hit the disk because I am about to promise someone else that we're not going to forget it'.
[06:57] <iwj> That's quite different from the general requirement of the filesystem not to fuck up.
[06:58] <wasabi> No... because we're still talking about, two different files.
[06:58] <iwj> Saying `you must fsync if you want the fs not to fuck up' will just lead to every application having to fsync which is obviously daft.
[06:58] <Keybuk> wasabi: if you can guarantee that writes always reach the hardware ...
[06:58] <wasabi> iwj: Never said that.
[06:58] <Keybuk> wasabi: ... then you can guarantee that they always reach the filesystem ...
[06:58] <wasabi> And how can you do that?
[06:58] <Keybuk> "sync"
[06:58] <wasabi> u-a doesn't sync it though.
[06:59] <Keybuk> reaching the filesystem is intrinsically uninteresting, except for the case of file handover
[06:59] <wasabi> You want me to manually type sink between running u-a?
[06:59] <Keybuk> no, I mean mount the filesystem with "sync" as the option!
[06:59] <wasabi> Oh. Hah.
[06:59] <wasabi> Do you really consider taht the solution?
[06:59] <Keybuk> power outage => you care about writes reaching the hardware
[06:59] <Keybuk> which means that you need them to reach the filesystem *and* hardware
[06:59] <wasabi> Destroy all performance improvements of your hardware and file system when there are other appropiate solutions?
[07:00] <Keybuk> since we can only guarantee the later in special cases where the user has made attempt to secure that, it is not unreasonable to expect them to make attempts to secure the same for the intermediate filesystem
[07:00] <wasabi> If you want to ensure a file is written, you call fsync. That is the convention, no?
[07:00] <Keybuk> no
[07:00] <wasabi> That exists for a reason, no?
[07:00] <iwj> I think it's a bug if after a power outage the filesystem has left the disk in a state that doesn't correspond to any of the states which would have been visible to a user process before the crash.
[07:00] <Keybuk> if you want to ensure that the file is available for other processes to read, you call fsync()
[07:00] <iwj> Keybuk: What ?
[07:00] <Keybuk> it does not guarantee that it is written
[07:00] <wasabi> Eh?
[07:00] <iwj> Other processes are supposed to see the file straight away regardless of any fsync.
[07:01] <Keybuk> iwj: then what's the XFS bug?
[07:01] <mjg59> Keybuk: It guarantees it's hit disk. It doesn't guarantee it's hit the filesystem.
[07:01] <iwj> The XFS bug ?  You mean the one where you get a file full of zeroes ?
[07:01] <Keybuk> there's a write()/close()/rename() bug with XFS
[07:01] <wasabi> Keybuk: It happens when there is a power failure after writing two files and renaming.
[07:01] <Keybuk> due to a missing fsync()
[07:01] <wasabi> Because nobody calls fsync.
[07:01] <iwj> Err, earlier you said ZFS.
[07:01] <wasabi> write(); write(); rename(); crash.
[07:01] <Keybuk> ok, well clearly I'm even more confused about all of this than I thought :-)
[07:02] <iwj> Oh, no, I misread.
[07:02] <wasabi> Heh.
[07:02] <wasabi> I just wanted to question what you said in the bug report a year ago... because I find it fundamentally contrary to everything I've been taught. :0
[07:02] <Keybuk> wasabi: I now don't understand why this doesn't work on XFS
[07:02] <iwj> wasabi: It is my view that dpkg does the right thing and if the filesystem causes what dpkg does not to work properly (including in the case of a crash during package installation) then that's a bug in the filesystem.
[07:03] <wasabi> Which is that fsync is to be used to guarentee that at a given point in time something has or has not been commited to the best of the knoweldge of the kernel
[07:03] <wasabi> Keybuk: u-a writes a file, then renames the old file to the new, but nothing ever calls fsync to ensure the first write happend.
[07:03] <iwj> Keybuk: There are bugs in many journalling filesystems which have a tendency to write out the metadata to disk before the data.  The result is that if you crash at an unfortunate moment, the file you renamed over the top of the old data turns out to contain zeroes (or even garbage).
[07:03] <wasabi> But the renames DOES go through.
[07:03] <Keybuk> wasabi: but why does that matter?
[07:03] <wasabi> So you have a properly named file pointing at invalid data.
[07:03] <Keybuk> any application reading the file would get it from the cache, no?
[07:04] <iwj> Keybuk: No, after a crash.
[07:04] <Keybuk> (assuming no intermediate power outage)
[07:04] <Keybuk> right
[07:04] <wasabi> We're talking about power outages.
[07:04] <Keybuk> so that's just a bug in the filesystem
[07:04] <wasabi> Haha.
[07:04] <Keybuk> stupid filesystem, etc.
[07:04] <wasabi> Why do you think that? That's what boggles my mind.
[07:04] <Keybuk> application did a perfectly reasonable set of syscalls
[07:04] <Keybuk> write(), write(), close(), rename()
[07:04] <Keybuk> it's up to the filesystem to ensure record of those aren't lost
[07:04] <Keybuk> and record them in the journal
[07:04] <mjg59> Why would you then expect the data to be on disk?
[07:04] <mjg59> We don't journal data
[07:04] <mjg59> Because otherwise performance is dreadful
[07:04] <iwj> mjg59: We don't care whether the data are on disk or not.
[07:05] <wasabi> Keybuk: The thing is dpkg moves on, and writes in it's status file that the installation is done.
[07:05] <Keybuk> mjg59: the alternative is to fsync() everything on close though, no?
[07:05] <mjg59> Keybuk: If you want to guarantee that something is on disk, yes
[07:05] <wasabi> Keybuk: So when recovering from the crash, dpkg says it's "done".
[07:05] <iwj> What we care about is that after a crash (or other problem) _either_ the situation is as was before, or as it was after.
[07:05] <wasabi> But in realitity, a few files are corrupt.
[07:05] <iwj> Ie, either the writes should have taken effect or the rename shouldn't.
[07:05] <Keybuk> mjg59: in what circumstances would I want to guarantee that something is on disk?
[07:05] <wasabi> Before dpkg registers that it's done, it should fsync the files it just modified.
[07:05] <wasabi> That's common transactional programming.
[07:05] <iwj> No, fsync is not for making transactions.
[07:05] <Keybuk> wasabi: so we should fsync() everything?
[07:05] <Keybuk> why don't we patch the kernel to fsync() on close() ?
[07:06] <Keybuk> (I'm not being annoying, I seriously do not understand)
[07:06] <wasabi> No, not everything. Only things that form some sort of transactional isolation.
[07:06] <mjg59> Keybuk: Because that would also suck
[07:06] <Keybuk> why is this a special case?
[07:06] <wasabi> a) do file modifications b) record that we did file modifications
[07:06] <pitti> Keybuk: that has acttually been proposed
[07:06] <Keybuk> wasabi: so make close fsync?
[07:06] <wasabi> Do you not think something should happen before b?
[07:06] <mjg59> iwj: Is that assumption codified anywhere?
[07:07] <pitti> Keybuk: http://www.ussg.iu.edu/hypermail/linux/kernel/0512.3/0050.html
[07:07] <wasabi> Keybuk: No, again, only for things which are transactional. dpkg is that.
[07:07] <Keybuk> wasabi: why is dpkg transactional?
[07:07] <pitti> Keybuk: that was for an entirely different context, though (more sane handling of removable devices)
[07:07] <mjg59> iwj: If you're journalling metadata, it's unsurprising that a crash will result in your metadata/data being out of sync
[07:08] <iwj> mjg59: It's an assumption inherent in the way that EVERY PROPER PROGRAM SINCE THE DAWN OF TIME HAS UPDATED A FILE.
[07:08] <wasabi> Keybuk: It's a good question, and the only answer I have is because that's how people expect it to be. It tells the user "yes, you're install is done."
[07:08] <iwj> The _standard official approach_ is open(".tmp") write rename
[07:09] <Keybuk> wasabi: so should all instances of write()/close()/rename() be transactional?
[07:09] <Keybuk> if so, maybe rename needs to sync the files?
[07:09] <iwj> You use fsync if you want to synchronise with some real-world thing outside the computer.
[07:09] <mjg59> No, nothing should implicitly sync the files
[07:09] <wasabi> Maybe it does. Except I don't think that guarentee is codified anywhere is it
[07:09] <iwj> Like if you're receiving mail.
[07:10] <wasabi> iwj: You mean like a user? heh
[07:11] <wasabi> APPLICATION USAGE    The fsync() function should be used by programs which require modifications to a file to be completed before continuing; for example, a program which contains a simple transaction facility might use it to ensure that all modifications to a file or files caused by a transaction are recorded.
[07:12] <Keybuk> except it doesn't
[07:12] <Keybuk> it just ensures that the kernel has finished with it, and it's heading somewhere near the hardware
[07:12] <wasabi> yes yes yes, we know, hardware will subvert it Sometime.
[07:12] <mjg59> Keybuk: No, fsync() guarantees that it's hit hardware
[07:13] <mjg59> Whether it's hit platters may be another issue
[07:13] <Keybuk> NOTES
[07:13] <Keybuk>        If the underlying hard disk has write caching enabled,  then  the  data
[07:13] <Keybuk>        may  not  really  be  on  permanent  storage when fsync() / fdatasync()
[07:13] <Keybuk>        return.
[07:13] <Keybuk> right, hit platters
[07:13] <wasabi> Yes, we know that.   There is a right answer here and it's that fsync should guarantee that everything relevant to that file up to that point will survive future crashes etc.
[07:14] <iwj> And if it fails to guarantee that it's a bug.  Consumer hardware in buggy shocker.
[07:14] <wasabi> iwj: "as best it can"
[07:14] <iwj> But that's not relevant.
[07:14] <iwj> wasabi: No, _guarantee_.  But if the hardware is buggy then the machine is buggy.  But this is all irrelevant.
[07:14] <wasabi> Sure. But we fail on non-buggy hardware. The only question is whether the FS is buggy.
[07:15] <iwj> Because dpkg doesn't need to know that the changes it makes with write have it the disk before it calls rename.
[07:15] <wasabi> dpkg should know that before it records in it's status file that they did.
[07:15] <iwj> It doesn't mind at all if the machine crashes and everything is as if the writes and rename never happened.
[07:15] <wasabi> So that upon resuming the machine, the user can identify which packages might be in an inconsistant state.
[07:16] <iwj> No, because that's all internal to the machine.
[07:16] <iwj> dpkg doesn't mind if the whole machine is rewound.
[07:16] <wasabi> Oh, sure. But the thing is dpkg is never marking what needs to happen in what order. =/
[07:16] <iwj> And indeed allowing that possibility makes it possible for dpkg to run much faster because it doesn't need to constantly stop and prat about with fsync.
[07:16] <wasabi> So it can't be rewound. It just gets scrambled.
[07:17] <iwj> wasabi: Yes it is, it makes system calls in that order.
[07:17] <wasabi> And all file operations should happen in order, always?
[07:17] <iwj> A filesystem is buggy if any sequence of system calls results in scrambled data.
[07:17] <wasabi> Even for independent files?
[07:17] <iwj> wasabi: Yes.  That's the whole point of the unix file api.
[07:17] <wasabi> So why are we mounting things async?
[07:18] <wasabi> In fact who invented that?
[07:18] <iwj> I don't know.  The fs authors seem to have made it the default because it goes faster.
[07:18] <iwj> Who cares if it breaks, eh ?
[07:18] <mjg59> We mount thinks async because the alternative is stupid
[07:18] <wasabi> Double infact, how does dpkg know if it's using two file systems?
[07:18] <wasabi> And how does it know they are both in order? heh
[07:18] <iwj> mjg59: We should write data and metadata together rather than deliberately writing one and not the other.
[07:18] <iwj> wasabi:
[07:19] <mjg59> iwj: ext3 optionally has that behaviour, but it kills performance
[07:19] <iwj> If you like, mount everything sync and see how long your installs take.
[07:19] <wasabi> I think at some point we introduced "points of atomicity", and that's worked great. Except when people forget to mark their points.
[07:19] <iwj> wasabi: That's not what fsync ever did and furthermore what you're doing is not introducing "points of atomicity" but removing them.
[07:19] <Keybuk> wasabi: I suspect it's more that people forget to tell anybody they introduced the requirement to mark their points in the first place, and what kinds of places they should
[07:19] <mjg59> iwj: I think an argument that does make sense is that metadata in the journal should be flagged as to whether it refers to changes that haven't hit disk
[07:20] <iwj> mjg59: I don't care how it's implemented.  I just care that after a crash I see a filesystem that looks vaguely like something reasonable.
[07:20] <Keybuk> I do tend to agree with Ian here
[07:20] <Keybuk> if a filesystem has been told to do A, B and then C
[07:21] <mjg59> Well, the argument is that it's reasonable (ie, consistent)
[07:21] <Keybuk> and does C, without even recording that A and B haven't happened and need to, then that's a filesystem issue
[07:21] <wasabi> Alright. I agree now. Ya'll win.
[07:21] <mjg59> I suspect the XFS authors have different ideas about what "reasonable" means
[07:21] <Keybuk> it's reasonable for it to process things out of order *if* there's a filesystem transaction API
[07:22] <iwj> Keybuk: Right.  And you'd have to ask applications to turn it on explicitly.
[07:22] <Keybuk> which guarantees that all or none of the transaction hits disk
[07:22] <iwj> And applications which didn't say "I'm using the new transaction api" would get the original semantics.
[07:23] <iwj> Or even just an explicit sequence points API.  I don't have objections to that.
[07:23] <Keybuk> for example
[07:23] <Keybuk> how do I fsync() a rename? :p
[07:23] <iwj> I do object to changing the meaning of the existing calls so as to break every previously-reliable program.
[07:23] <Keybuk> or an unlink?
[07:23] <iwj> But I have to go and have dinner.
[07:23] <iwj> Keybuk: Keep up the good fight :-).
[07:23] <wasabi> iwj: thanks for setting me straight. :0
[07:24] <iwj> Any time :-).
[07:25] <desrt> Keybuk; sup?
[07:25] <Keybuk> desrt: hey
[07:25] <desrt> wasabi; word
[07:25] <wasabi> desrt: sentence
[07:25] <desrt> iwj; goodday :)
[07:26] <desrt> mjg59; if my ata_piix module has usecount 4 and my ahci module has usecount 0 does that mean that linux is ignoring my bios setting of "ahci mode"?
[07:27] <mjg59> Yes
[07:27] <mjg59> dmesg?
[07:27] <desrt> hold on a sec.
[07:27] <desrt> i can't do too much for you right now since it's my home machine and i'm at work, but i can ssh
[07:27] <desrt> what part of dmesg do you need?
[07:27] <mjg59> /var/log/dmesg
[07:28] <desrt> oh.  whole thing.  k :)
[07:28] <desrt> http://desrt.mcmaster.ca/random/dmesg
[07:29] <Hobbsee> hiya desrt
[07:29] <desrt> Hobbsee; hello.  what's up?
[07:30] <Hobbsee> desrt: i'm pondering uploading to main.
[07:30] <desrt> if you're looking for something to do, acpi-support could use a NMU
[07:32] <Hobbsee> i wasnt....neither can i upload to debian.
[07:32] <desrt> i mean ubuntu's :)
[07:33] <geser> are new source packages still pulled regularly from Debian?
[07:33] <Hobbsee> desrt: that means i'd have to understand what's going on with it
[07:33] <desrt> Hobbsee; it was a joke :)
[07:33] <Hobbsee> :P
[07:34] <mjg59> desrt: Can I have an lspci?
[07:34] <desrt> mjg59; of course
[07:35] <desrt> http://desrt.mcmaster.ca/random/lspci-for-mjg59
[07:35] <Hobbsee> (damn the ' and enter being so close)
[07:35] <thekorn> pitti:  I just added a patch to fix bug 119872
[07:35] <ubotu> Launchpad bug 119872 in python-launchpad-bugs "BugList's filters do not work" [Undecided,Fix committed]  https://launchpad.net/bugs/119872
[07:36] <pitti> thekorn: ooh, rock
[07:36] <mjg59> desrt: Your BIOS isn't setting your chipset to AHCI mode
[07:36] <desrt> mjg59; silly bios.
[07:37] <desrt> mjg59; it has an option for it and i've selected AHCI
[07:37] <mjg59> Well, your jmicron controller is set to AHCI
[07:37] <mjg59> Maybe it's only doing it for that
[07:37] <cjwatson> geser: yes, up to Debian import freeze == 21 June (GutsyReleaseSchedule)
[07:37] <desrt> hmm.  that seems likely
[07:37] <desrt> ich8 is ahci capable with a few bits flipped, i suppose?
[07:37] <mjg59> Yes
[07:37] <cjwatson> though apparently nobody's done it for a few days, so I will
[07:38] <mjg59> Try the patch I posted
[07:38] <desrt> (see your blog for the appropriate patch)
[07:38] <desrt> nod.
[07:38] <desrt> (having a 100%-lrm-free machine reduces the pain quite a lot...)
[07:40] <desrt> mjg59; a rather direct indication of workingness of ahci vs. piix mode is that in ahci hotswap will work and in piix it will not?
[07:41] <mjg59> desrt: Just check dmesg and see if your drives are coming up on ata_piix or not
[07:42] <desrt> (again)
[07:45] <mjg59> Or just make sure the drives are on the jmicron
[08:05] <cjwatson>   * Handle architectures in all dependency fields in debian/control,
[08:05] <cjwatson>     even those of binary packages. Closes: #252657, #324741, #347819
[08:05] <cjwatson> whoa, I never knew that had been done in dpkg
[08:05] <thom> oh, nice
[08:05] <thom> no more arch: any insanity just to get platform deps
[08:06] <cjwatson> well
[08:06] <cjwatson> no, it's done in dpkg-gencontrol
[08:07] <cjwatson> so only applies to architecture: any
[08:36] <nomeata> hi. Has anyone tried to use upstart initscripts to create standard sys-V-init-script from them?
[08:43] <nomeata> Keybuk: Hi. Are you coming to debconf?
[09:04] <Keybuk> nomeata: no, why?
[09:05] <nomeata> Keybuk: Id like to abuse the upstart init script file format :-)
[09:05] <nomeata> Keybuk: I just wrote a mail to upstart-devel
[09:05] <Keybuk> nomeata: the main difference between upstart and Debian's init script format is what will bite you
[09:05] <Keybuk> upstart you specify the daemon to exec, that remains in the foreground
[09:06] <Keybuk> Debian init scripts run the daemon in the background, then return, with some other way of finding the daemon again
[09:06] <nomeata> That is true.
[09:07] <nomeata> Maybe the generated init script could still use a foreground daemon, and handle it through start-stop-daemon
[09:07] <Keybuk> the other problem is that the "when the init script is run" stuff varies so wildly, there's no way to make it common
[09:07] <Keybuk> e.g. Debian uses numbered runlevels, with numbered sequences
[09:08] <Keybuk> others use comments in the generated init script to seed those
[09:08] <Keybuk> other things like initNG use "dependencies"
[09:08] <Keybuk> Upstart uses eventgs
[09:08] <Keybuk> etc.
[09:08] <nomeata> But dont 90% of the daemon have non-specific requirement?
[09:08] <nomeata> ok, the number is just a rough guess.
[09:09] <nomeata> And the solution is not intended to work for every single daemon, just those where init scripts are just repetition.
[09:11] <Keybuk> no idea
[09:11] <nomeata> The big plus would be of course that those daemons would suddently have a real upstart script shipped.
[09:11] <Keybuk> in theory, anyway, in "start" you'd the pre-start script, fork the daemon, then run the post-start script
[09:11] <Keybuk> and in "stop" would run the pre-stop script, kill the daemon, then run the post-stop script
[09:11] <nomeata> right
[09:12] <Keybuk> and then just shim for things like env/umask/chdir/etc.
[09:13] <nomeata> tomorrow well have a BOF on the idea. Do you want to be kept in the loop?
[11:17] <pygi> Zdra, poke
[11:40] <TheMuso> doko: Just replied to your email with the state of espeak. I'm happy for you to do the merge, but I also don't mind doing it, with your work as a basis. I meant to push my changes to Debian very soon anyway, as I am working with him on other projects.
[11:41] <doko> TheMuso: cool, I wouldn't mind if you go ahead with the upload
[11:41] <TheMuso> doko: Ok. I'll get to it later today. Thanks again
[11:41] <doko> not that urgent ...
[11:41] <TheMuso> Yep I know.
[11:42] <TheMuso> I'm assuming portaudio19 has made its way to main by now?
[11:42] <crimsun> portaudio19 | 19+svn20070125-1ubuntu1 | gutsy/universe | source
[11:43] <TheMuso> crimsun: Yeah I saw that yesterday, which is why I am wondering, as I saw arequest to move it to main the other day...
[11:43] <TheMuso> Haven't had time yet to update my gutsy chroot and look myself.
[11:45] <crimsun> ogra: do you mind if I handle alsa-plugins (after alsa-lib 1.0.14-1ubuntu1 builds)?
[11:46] <geser> TheMuso: have you tried rmadison from devscripts? (rmadison -u ubuntu portaudio19)


[00:06] <rsalveti> GrueMaster: can you also try to update to the latest kernel?
[00:06] <rsalveti> the rc4 based one should be available already
[00:07] <GrueMaster> I didn't see it in the pool yet, but I'll check launchpad.
[00:08] <rsalveti> https://launchpad.net/ubuntu/+source/linux/2.6.38-3.30/+buildjob/2252836
[00:10] <GrueMaster> Yea, finished 16 minutes ago.  That's why.
[00:10] <GrueMaster> Heh.
[00:10] <rsalveti> hehe
[00:11] <persia> Hrm?  Says finished 7 hours ago for me.
[00:11] <GrueMaster> https://launchpad.net/ubuntu/+source/linux-meta/<IP_ADDRESS>.17/+buildjob/2255077
[00:12] <GrueMaster> That's what is currently published (or in the que).
[00:12] <persia> Ah.  That's probably still stuck in the publisher.
[00:12] <persia> But it finished enough before the hour that it ought be in this run, rather than waiting until the next run.
[00:13] <GrueMaster> Right, but last I was told, the publishing run starts at ~:05 and finishes at :40.
[00:13]  * npitre sees a pending interrupt for himself here
[00:13] <GrueMaster> So I only have to wait another 30 minutes.
[00:14] <persia> npitre, I've been trying to package an imx51 kernel tree with sascha's tree + patches from rtp + ubuntu sauce.  lool advised me you were the gatekeeper for linux-linaro-imx51, and I should send you patches and use your package.
[00:15] <persia> npitre, Since the last upload is 2.6.37, I'll try to sort out what patches I have that are relevant to the efika boards, and prepare a tree for your review.
[00:15] <npitre> persia: no problem
[00:16] <persia> npitre, For reference, rtp's work is a quilt patchset at git://git.rtp-net.org/efika.git
[00:16] <npitre> persia: what is rtp?
[00:17] <persia> npitre, Arnaud Patard
[00:17] <npitre> persia: fyi, the linaro tree should move to 2.6.38-rc5 once released
[00:18] <persia> npitre, Excellent.  If your 2.6.37 boots on the hardware, I'll postpone sending you patches until after the move.  If not, I may send you a few in advance.
[00:19] <npitre> persia: OK, as lool hinted I'm not that good at tracking irc so feel free to send me an email if you have something you want included in the linaro kernel
[00:20] <persia> npitre, Absolutely :)  I'm not that good at tracking email: thanks for having the initial discussion with me here.
[00:21] <npitre> persia: you may try to ping me on irc, but sometimes this might take hours before I notice
[00:22] <persia> npitre, I'll send you email once I have something substantive.  For now, I'm waiting on a test report for the Efika MX with your kernel.
[00:22] <npitre> persia: OK
[01:08] <rsalveti> cooloney: hey, are you back already?
[01:11] <cooloney> rsalveti: yeah, man
[01:11] <cooloney> rsalveti: how's going?
[01:11] <rsalveti> cooloney: good, and you?
[01:11] <rsalveti> refreshed?
[01:12] <cooloney> rsalveti: heh, actually a little bit tired
[01:12] <cooloney> rsalveti: any news?
[01:12] <rsalveti> cooloney: well, weekend ahead :-)
[01:12] <rsalveti> cooloney: well, some :-)
[01:12] <rsalveti> we got a ti-omap4-dev branch
[01:12] <rsalveti> as you probably know already
[01:13] <rsalveti> cooloney: one thing I'd like to ask you is if you can test and merge the DVI patches for panda
[01:13] <rsalveti> for 2.6.38
[01:13] <rsalveti> so we can have a working display with this kernel
[01:13] <rsalveti> as my panda has a broken dvi, can't test atm
[01:13] <rsalveti> look at l-o for [PATCH] OMAP4: PandaBoard: Adding DVI support
[01:14] <cooloney> rsalveti: sure, i will do it today
[01:14] <cooloney> i got that HDMI-DVI cable
[01:15] <rsalveti> cooloney: cool
[01:15] <cooloney> rsalveti: is this one?
[01:15] <rsalveti> but even the hdmi cable should work
[01:15] <cooloney> [PATCH] OMAP4: PandaBoard: Adding DVI support
[01:15] <rsalveti> cooloney: yup
[01:15] <rsalveti> rcn-ee said it worked fine for him
[01:15] <rsalveti> so it should just work
[01:15] <rsalveti> if it's the case, try sending it to this branch
[01:15] <cooloney> it's from Raghuveer Murthy<EMAIL_ADDRESS>[01:15] <rsalveti> ti-omap4-dev
[01:15] <rsalveti> cooloney: yup, that's the one
[01:16] <cooloney> OK, i got it
[01:16] <cooloney> so will we get .38 patches soon?
[01:17] <rsalveti> cooloney: not directly from serbjan, probably from linaro
[01:18] <rsalveti> or something like that
[01:18] <cooloney> rsalveti: right, i know Andy Green is working with sebjan on that
[01:18] <rsalveti> yeah
[01:19] <cooloney> rsalveti: thx a lot for this info.
[01:19] <cooloney> i will test that DVI patch and try to push to ti-omap4-dev
[01:21]  * cooloney just update his machine, needs reboot, brb
[02:18] <cooloney> rsalveti: does our ti-omap-dev branch kernel supports graphic, since i wanna test that DVI patch.
[02:18] <persia> It should.
[02:18] <rsalveti> cooloney: probably
[02:19] <rsalveti> cooloney: you just need to check if you have all the dependencies, like described at the patch
[02:19] <cooloney> rsalveti: i think it is based on 2.6.38-rc kernel which miss some graphic support.
[02:19] <rsalveti> but as we're basically using the same one as master (rc4), and rcn-ee said it worked fine for him, I expect this patch to be enough to get the display working
[02:20] <cooloney> rsalveti: OK, I will try it soon
[04:17] <rcn-ee> rsalveti, did you get the display working on the panda with 2.6.38-rc4?
[04:18] <persia> rcn-ee, backscroll reports that rsalveti is having issues with the DVI port : cooloney had volunteered to look at the relevant patch.
[04:20] <rcn-ee> ah, interesting..  Could be something with the  monitors i have here..
[04:21] <persia> No, it's something with rsalveti's hardware
[04:22] <persia> quoting "as my panda has a broken dvi, can't test atm"
[04:22] <persia> Unless you had a HW hack to fix that?
[04:22] <cooloney> rcn-ee: yeah, i am working on that
[04:22] <rcn-ee> ah i see, (working my back in the scroll log.. )
[04:22] <cooloney> rcn-ee: so mainline 2.6.38-rc4 kernel does support graphic things on Panda?
[04:23] <rcn-ee> mainline + plus the patches posted on wednesday..
[04:24] <rcn-ee> cooloney, these work on my panda a1.. http://dev.omapzoom.org/?p=anand/linux-omap-usb.git;a=shortlog;h=refs/heads/display-patches-for-v2.6.38-rc4  and they don't seem to break my c4 beagle board with the same uImage
[04:24] <cooloney> rcn-ee: right, i pull the branch from Anand's display-patches-for-v2.6.38-rc4
[04:24] <cooloney> rcn-ee: yeah, exactly
[04:24] <cooloney> rcn-ee: what's kind of root fs you are testing for this?
[04:25] <rcn-ee> the one thing i haven't tested is the edid stuff, so i did a "1024x768" value on the bootargs...  on that boot test, maverick...
[04:31] <lilstevie> is anyone here good at fbdev :p
[04:36] <persia> lilstevie, Try asking the question you'd ask if someone said "yes".  Someone might not consider themselves good, but may know the answer to your specific question.
[04:36] <lilstevie> heh well I have no idea what is wrong
[04:36] <lilstevie> the screen blinks the backlight on and off
[04:38] <persia> What board?  Which image?
[04:41] <lilstevie> rootstock made image
[04:41] <lilstevie> and not a usual board :p
[04:41] <lilstevie> galaxy tab
[04:43] <persia> Heh, that makes it tricky :)
[04:44] <persia> I'm not even sure what question would be useful to ask next (I know I don't know the solution to your problem, but I can usually get a bit further in the script :) )
[04:46] <lilstevie> heh
[04:46] <lilstevie> I do have logs
[04:46] <lilstevie> and interactivity over ssh
[04:50] <cooloney> rcn-ee: sorry, i was dropped
[04:52] <rcn-ee> np cooloney, i believe i tested it on maverick, (defined the video x/y in the bootargs, didn't do edid).. but it might have been lucid/squeeze, i was testing other userspace things at the time..
[04:53] <cooloney> rcn-ee: great, i am testing it with our natty userspace and wanna apply those patches to our ubuntu 2.6.38 based kernel
[04:53] <rcn-ee> is this for the ppa one mentioned on the ubuntu-kernel list earlyier this week?
[04:54] <cooloney> rcn-ee: from Anand Gadiyar's branch, i found 35+ patches on top of 2.6.38-rc4
[04:55] <cooloney> rcn-ee: yeah, it is our ti-omap4-dev branch which is 2.6.38 based branch
[04:55] <cooloney> i think for ti-omap4 stuff, it is almost the same as mainline
[04:56] <rcn-ee> that's pretty strange, shouldn't have been that much..
[04:56] <rcn-ee> i know there's 4-5 omap specfic ones that were merged in the rc3-rc4 so that wouldn't add up either..
[04:57] <rcn-ee> (crap wrong patchset... it's 35..)
[04:57] <cooloney> rcn-ee: from Raghuveer Murthy's description in DVI patch, it is only depends on 6 patches
[04:58] <cooloney> rcn-ee: but i think pure 2.6.38-rc4 does not include DSS patches which is required for graphic on OMAP4 like panda
[05:00] <rcn-ee> yeah, 2.6.38-rc4 only has the omap4 ehci/musb bits, nothing really else.. those 35 on top of that were enough for my dvi port to correctly work on the panda...
[05:04] <cooloney> rcn-ee: so how did you test that DVI patch? apply those 6+1 patches on 2.6.38-rc4 kernel?
[05:05] <rcn-ee> i applied the 35 on top of my current 2.6.38-rc4 tree.. https://github.com/RobertCNelson/2.6.38-devel/blob/master/patch.sh#L160
[05:11] <cooloney> rcn-ee: ok, cool, man
[05:12] <rcn-ee> yeah, rereading it on the linux-omap archive, Murthy does mention the other 6 patches, but it looks like Anand Gadiyar merged those 6 depencies into the group of 35..
[08:05] <sebjan> rsalveti, cooloney: I already have a branch with the DVI patches working
[08:06] <cooloney> sebjan: thanks a lot
[08:06] <cooloney> sebjan: i'm just trying the DVI branch from Raghuveer Murthy
[08:07] <cooloney> wanna apply those 35 patches in Anand Gadiyar's branch, but it failed on our ti-omap4-dev branch
[08:07] <cooloney> some conflict
[08:10] <sebjan> cooloney: I did not try yet to apply them on the ti-omap4-dev branch, I currently work on mainline (.38-rc4)
[08:11] <cooloney> sebjan: yeah, i know some conflicts there, will try to solve them
[08:11] <cooloney> and prepare a branch to test
[08:11] <cooloney> sebjan: but i am not sure about those patches from Anand Gadiyar's branch, will they be merged into mainline?
[08:12] <cooloney> it's about 35 patches
[08:13] <sebjan> cooloney: they are reviewed on LO, but not sure about their status
[08:13] <cooloney> sebjan: ok, so how about your patches?
[08:13] <cooloney> DVI patches?
[08:14] <sebjan> cooloney: let me clean and retest my branch and I send it to you (but tis shall be very similar to Anand's one)
[08:14] <cooloney> sebjan: great, I will try Anand's soon after i solve those conflicts
[08:17] <sebjan> cooloney: here is my git / tag: git://github.com/sebjan/linux-2.6.git topic-wlan-iv1-2.6.38-rc4 (https://github.com/sebjan/linux-2.6/tree/topic-wlan-iv1-2.6.38-rc4)
[08:18] <sebjan> I have DVI working (from DVI connector P1)
[08:19] <sebjan> and can choose the screen definition with these bootargs for ex: omapfb.mode=dvi:1024x768MR-24@60 omapdss.def_disp=dvi
[10:30] <NishanthMenon> slnr, hi
[10:30] <slnr> hi
[10:30] <NishanthMenon> slnr, can you share the issue with gst-launch with mp3 decoder and filesink with ndec
[10:30] <NishanthMenon> ndec, ping
[10:31] <slnr> gst-launch filesrc location=test.mp3 ! mad ! filesink location=test.pcm
[10:31] <slnr> this is working fine
[10:31] <slnr> gst-launch filesrc location=test.mp3 ! omx_mp3dec ! filesink location=test.pcm
[10:31] <slnr> this is not working
[10:31] <NishanthMenon> slnr, this is for OMAP4 rt?
[10:31] <slnr> yes
[10:32] <NishanthMenon> slnr, one more place to ping is #gst_ti
[10:32] <slnr> thanks
[10:32] <NishanthMenon> slnr, np
[10:32] <slnr> we will try to join that channel
[10:32] <NishanthMenon> ndec, know anything about this pipe failing with ubuntu?
[10:32] <persia> slnr, You have the omx packages installed, right?  (just for confirmation)
[10:33] <NishanthMenon> persia, good Q -> slnr try gst-inspect | grep omx_mp3dec
[10:33] <slnr> it is there
[10:33] <NishanthMenon> slnr, does fakesink work?
[10:33] <slnr> yes
[10:34]  * NishanthMenon out of cookies :( defers to ubuntu experts
[10:34] <slnr> yes
[10:34] <slnr> we will try this and let you know
[10:35] <NishanthMenon> slnr, ?? did you mean, you are now going to try gst-launch filesrc location=test.mp3 ! omx_mp3dec ! fakesink ?
[10:35] <slnr> yes we tried
[10:35] <slnr> with fakesink
[10:35] <cooloney> sebjan: do you have the kernel config file for dvi patches testing?
[10:35] <slnr> it works properly
[10:36] <NishanthMenon> slnr, k.. /me out of ideas here..
[10:36] <slnr> one sec
[10:36] <slnr> we will cross check this pipeline once
[10:36] <NishanthMenon> and alsasink works?
[10:36] <sebjan> cooloney: yes, I have 2: one is minimal, and the other is an Ubuntu-like one. They are located into arch/arm/configs/omap4_panda_* (the 'full' one is an Ubuntu like)
[10:37] <slnr> with alsasink it is working
[10:37] <slnr> we just checked fakesink
[10:37] <slnr> it fails
[10:37] <persia> fakesink fails and alsasink works?
[10:37] <sebjan> cooloney: the minimal one also boots with an Ubuntu FS (issue was: not devtmps + .38 issue with omap2plus and ARMv7 SMP)
[10:37] <cooloney> sebjan: is it in the github?
[10:37] <slnr> yes
[10:38] <slnr> persia: yes
[10:38] <sebjan> cooloney: yes shall be. let me cross-check
[10:38] <persia> slnr, That's unexpected.  If fakesink fails, nothing ought to work, or something is very odd.
[10:38] <slnr> ok
[10:39] <NishanthMenon> slnr, can you post the log on pastebin.mozilla.org and provide us a link of what you see with gst-launch filesrc location=test.mp3 ! omx_mp3dec ! fakesink
[10:39] <slnr> persia: gst-launch filesrc location=test.mp3 ! omx_mp3dec !  fakesink/filesink fails
[10:39] <sebjan> cooloney: confirmed, they are in my branch on github
[10:39] <persia> Or paste.ubuntu.com :)  Lots of choices.
[10:39] <slnr> persia: gst-launch filesrc location=test.mp3 ! omx_mp3dec ! alsasink works
[10:40] <persia> Then it's beyond what I know about gstreamer.  I've always believed that fakesink was a no-op.
[10:40] <NishanthMenon> slnr, might help us to see the log. dont post the log straight here, instead post it to the paste.ubuntu.com and provide us the link
[10:40] <slnr> NM: ok
[10:40] <slnr> sure
[10:41] <NishanthMenon> persia, i agree, I'd think of it as cat file>/dev/null fails and /dev/dsp works! hmm.. mebbe some weird handshaking requirements?
[10:42] <persia> Heh, yeah, that's my thought.  But there are plenty of people more knowledgeable about gstreamer than I (although at this time of day, it may be a long wait until they are awake)
[10:42] <slnr> NM: we are capturing the log and we will provide the link on pastbin in few mins
[10:42] <NishanthMenon> slnr, thx.. mebbe you should check with #gstreamer as well in addition to #gst_ti.. u'd get a bunch of gstreamer experts there
[10:43] <slnr> NM: ok
[10:43]  * NishanthMenon suspects it might have something to do with ti gstreamer omx implementation
[10:43] <NishanthMenon> some caps negotiation or something "implicitly expected by ducati"..
[10:44] <NishanthMenon> sebjan, know who can help?
[10:44]  * NishanthMenon hopes france folks not away on lunch yet ;)
[10:44] <sebjan> NishanthMenon: not yet :)
[10:45] <NishanthMenon> sebjan, :D gstreamer issue pretty much needing someone knowing gstreamer and omx_ti :( know anyone lurking arnd?
[10:45] <cooloney> sebjan: i think we need enable the graphic driver for the DVI testing
[10:45] <cooloney> sebjan: but it is disabled in your config
[10:47] <ndec> NishanthMenon: hi
[10:47] <slnr> NM: http://pastebin.mozilla.org/1047108
[10:47] <NishanthMenon> ndec, good afternoon :)
[10:47] <ndec> NishanthMenon: sorry was in meeting.. what's the problem?
[10:47] <ndec> NishanthMenon: well, technically it's not noon yet ;-)
[10:47] <ndec> NishanthMenon: where are u?
[10:47] <NishanthMenon> ndec, slnr has this problem with gstreamer
[10:47] <slnr> NM: you can see the logs
[10:47] <NishanthMenon> ndec, blore atm
[10:48] <NishanthMenon> slnr, yep
[10:48] <NishanthMenon> ndec, can you glance at the log from slnr? looks like swapping the sink to fakesink instead of alsasink fails
[10:48] <ndec> NishanthMenon: slnr: for audio MP3 we do not support OMX anymore. that was only on OMAP3
[10:49] <NishanthMenon> ndec, how come alsasink works then?
[10:50] <slnr> NM: we have run a video pipeline and
[10:50] <ndec> NishanthMenon: ok.. too much backlog. can you summarize which pipeline fail?
[10:50] <NishanthMenon> and looking at the log, it seems to go to GstOmxH264Dec:omxh264dec0!
[10:50] <slnr> we have pasted the logs
[10:50] <NishanthMenon> slnr, do u have any mp3 logs?
[10:50] <NishanthMenon> not mp4 logs
[10:50] <ndec> slnr: for gst-launch filesrc location=test.mp3 ! omx_mp3dec ! filesink location=test.pcm
[10:51] <slnr> ndec: we will test mp3 too and paste
[10:51] <NishanthMenon> slnr, the log you pasted is for video h264_dec!
[10:51] <ndec> slnr: this is not expected to work. in fact we should removed the omx_mp3dec element for OMAP4 since it's not supported. on OMAP4 audio is thourhg ffmpeg, mad, libaac only
[10:51] <slnr> ndec: ok
[10:51] <NishanthMenon> slnr, have you really tested it?
[10:52] <ndec> for the video pipeline using omx_h264dec element and fakesink, I think it's failing because the sink is expected to be 'tiler aware' which fakesink isn't
[10:52] <slnr> ndec: can you analyse the video log
[10:52] <ndec> slnr: does the video pipeline work with v4l2sink?
[10:52] <slnr> NM: the log we capture fir video is now
[10:52] <slnr> yes
[10:52] <NishanthMenon> ndec, so no go for filesink or fakesink? sad..
[10:52] <slnr> ndec: yes
[10:52] <sebjan> cooloney: right, I just see Idid not upgrade the 'full' config with the display... The minimal one is up to date. Check the last commit for the relevant changes (otherwise, the minimal config can boot on a Ubuntu FS)
[10:52] <NishanthMenon> slnr, yeah.. wondering how you claimed mp3 worked before
[10:53] <NishanthMenon> quote "<slnr> persia: gst-launch filesrc location=test.mp3 ! omx_mp3dec ! alsasink works"
[10:53] <slnr> NM: that was one ex
[10:53] <slnr> NM: our colleague quoted as saying
[10:53] <NishanthMenon> k, looks like it is wrong info
[10:53] <slnr> NM: we were looking to video mainly
[10:53] <NishanthMenon> ndec, any chance of looping video output to a file?
[10:54] <NishanthMenon> some tileraware component that can route data to file/fakesink?
[10:55] <slnr> i am unable to route video output to fakesink/filesink
[10:55] <NishanthMenon> slnr, if you notice what ndec said, your sink should be tile aware. obviously file/fakesink is not and hence it fails
[10:55] <NishanthMenon> v4l2sink is probably aware and should work
[10:56]  * NishanthMenon wonders if there is something to route the video data to a file, helps for debugging usually - e.g. ssim comparison etc.
[10:57] <slnr> NM: yes v4l2sink works, how to make filesink tile aware?
[10:57] <cooloney> sebjan: https://github.com/sebjan/linux-2.6/blob/topic-wlan-iv1-2.6.38-rc4/arch/arm/configs/omap4_panda_defconfig also disabled DSS drivers
[10:57] <ndec> NishanthMenon: to do this you need to copy the tiler buffer in a regular buffer, robclark would know more about this, he did it in gst-ducati. so with gst-ducati you can have a filesink. the plugin will check for the capabilities of the sink, and will do the necessaru
[10:57] <ndec> /necessaru/necessary/
[10:57] <NishanthMenon> ndec, ok.. looks like a few more hrs before robclark appears
[10:58] <ndec> NishanthMenon: so for ex, with gst-ducati you can do video transcoding which you can't do with OMX ;-)
[10:58] <NishanthMenon> ndec, thx for the tip ;) I get the message - "more limitations of OMX" yet again :P
[10:58] <NishanthMenon> ndec, do you package gst-ducati with ubuntu?
[10:59] <slnr> NM: can this be downloaded from the net??
[10:59] <sebjan> cooloney: please look at my iv2 tag: https://github.com/sebjan/linux-2.6/tree/topic-dvi-iv2-2.6.38-rc4
[11:00] <sebjan> cooloney: DSS and DPI are activated here: https://github.com/sebjan/linux-2.6/blob/topic-dvi-iv2-2.6.38-rc4/arch/arm/configs/omap4_panda_defconfig
[11:00] <NishanthMenon> ndec, dunno.. u need to catch robclark when he comes online
[11:00] <NishanthMenon> s/ndec/slnr
[11:02] <slnr> NM: so my pipeline will look like omx_h264dec ! gst-ducati ! filesink location=test.yuv
[11:02] <slnr> NM: is this assumption correct??
[11:02] <cooloney> sebjan: thanks a lot, i looked at iv1 tag
[11:03] <sebjan> cooloney: np
[11:03] <cooloney> sebjan: so generally, it needs to enable DPI and Generic panel, right?
[11:03] <NishanthMenon> slnr, i dont think it will be gst-ducati.. it probably will have different component name - ask robclark
[11:03] <sebjan> cooloney: yes
[11:04] <persia> janimo, So, the nature of omap4 only specifies booting from MMC: it doesn't specify whether that is SD or eMMC or what.  As a result, depending on the final retail design, it's perfectly conceivable that you'd end up writing internal flash when writing to MMC on some device.
[11:04] <slnr> NM:  Thanks for the information
[11:05] <janimo> persia, well I am not sure what else can be done to make this safer, short of not implementing the spec, but I am open to suggestions :)
[11:05] <persia> janimo, But if you're special-casing only development boards, and won't be doing anything for retail devices, it's probably safe (and most developers like to be able to use newer bootloaders anyway)
[11:05] <janimo> persia, I don't know anytihng about retails devices. You mean future tables and ARM based OEM sutff?
[11:06] <janimo> If so they are tweaked by OEM anyway to prevent all kinds of snafu I hope
[11:06] <persia> janimo, Doesn't have to be future, if you consider OMAP3
[11:06] <persia> And if you presume that some OSV will tweak the OS, you are presuming nobody will want to run Ubuntu regularly, which I think is an unfortunate presumption.
[11:07] <janimo> persia, rsalveti and ogra know more about the rationale and potential drawbacks than I do
[11:07] <janimo> persia, I am not presuming but this is what I understood from the stories regarding OEM customization of Ubuntu
[11:07] <janimo> that almost all are not quite vanilla images
[11:07] <persia> janimo, I'm not suggesting you don't implement: just asking for care to make sure it only affects the development boards.  Retail shoppers don't tend to be as adept at recovering from bricked devices.
[11:08] <janimo> persia, sure
[11:09] <janimo> that is why probabaly the spec stated it should not be automatic
[11:09] <persia> Most likely :)
[11:12] <alf__> Hi! Any idea if Ubuntu can be run on Archos 101 tablets? It can supposedly run Angstrom, so I guess in the worst case someone can use the kernel from that.
[11:14] <persia> alf__, Which processor do they use?
[11:15] <alf__> persia: They only say "ARM Cortex A8 at 1 GHz with DSP"
[11:15] <persia> alf__, Should work fine.  Needs investigation to ensure you can get a working kernel, but userspace ought have no issues.
[11:16] <janimo> persia, in the meantime if you have suggestions about how to best solve the notification part of this BP I'd appreciate it. So far I was told about update-motd, jockey and debconf notes
[11:17] <persia> What's the BP URL?
[11:17] <janimo> https://blueprints.launchpad.net/ubuntu/+spec/other-arm-n-handle-core-boot-files-update
[11:17] <alf__> persia: aha, some more investigation reveals it is OMAP 3630, so it should be fine
[11:17] <persia> And here I was hoping that was about porting coreboot :(
[11:18] <janimo> persia, do you think that woudl make sense for these boards?
[11:18] <persia> janimo, Reading the spec makes me feel a lot more comfortable in general.
[11:18] <persia> Looks like we use the normal package update mechanism to update files, but never actually change the boot process.
[11:18] <janimo> right
[11:19] <persia> And then there is a tool that allows the user to install new boot files, if they like.
[11:19] <janimo> although the installation of packages was questioned by ogra recently
[11:19] <janimo> but then I am not sure if getting them is not much more hassle
[11:19] <janimo> I'd rather apt&co would take care of that part
[11:19] <persia> I like packages.  We know how to deal with packages.  That we don't actually deploy the delivered code is not so important.
[11:20] <janimo> persia, I agree
[11:20] <persia> I'd suggest using the update-notifier mechanism to suggest to the user that they run the update tool.
[11:20] <persia> And maybe jockey to select the correct bootloader package to track, which would trigger the tool
[11:21] <persia> (if the bootloaders all stuff things in /usr/share/bootloaders/... and the package in question has a trigger on the directory, and that trigger enables update-notifier, etc.
[11:22] <persia> Because for a beagle A2, it would be nice to update the bootloader, but for the Archos 101 above, it's probably risky, at best, while we otherwise probably support the hardware reasonably.
[11:22] <cooloney> sebjan: that's great, i saw our Natty Unity graphic via DVI port now
[11:22] <cooloney> sebjan: i applied the patches on top of our ti-omap4-dev branch
[11:22] <janimo> persia, do the above work just as well in headless mode?
[11:23] <persia> triggers do.  I don't know about update-notifier.  You might want to have the trigger leverage both update-notifier and update-motd to handle both cases.
[11:24] <persia> Nothing is going to handle remote X terminals well, but that's significantly less common than ssh sessions, console logins, or GUI environments.
[11:35] <ogra> persia, the prob is that we cant seed it ... i'm not against packages
[11:35] <persia> I'd be against seeding as well :)  Thanks for the clarification.
[11:36] <ogra> i dont care how we get the binaries as long as we do get them in the right place with a single command
[11:36] <ogra> if there are packages involved or if someone just dpkg -x'es them to /tmp, i totally dont care
[11:36] <janimo> ogra, what about sort-of seeding via livecd-rootfs?
[11:37] <ogra> fine with me as well
[11:37] <janimo> ogra, as wgetting and figuring out version and generally doing apt's job is not too useful
[11:37] <janimo> great
[11:37] <ogra> apt-get -d <packagename>
[11:37] <ogra> ;)
[11:37] <persia> I'd prefer jockey to livecd-rootfs
[11:37] <ogra> no wget needed
[11:38] <persia> Just because, if things go as I hope, we'll see a wider variety of devices capable of using a common image.
[11:38] <ogra> jockey doesnt really fell like it would fit the task
[11:38] <ogra> *feel
[11:38] <janimo> persia,  have no idea how jockey can be used here, do you have some pointers?
[11:38] <janimo> does it not already know about packages being available?
[11:39] <ogra> jockeys backend probably has checks and stuff
[11:39] <ogra> but i wouldnt use the frontend here
[11:40] <persia> jockey has a means to determine what hardware is present, and then encourage the installation of specific packages that help.
[11:40] <ogra> iirc it talks about third party drivers and enabling additional HW in its UI
[11:40] <persia> But, as ogra points out, it's probably only good to use the backend to get the data packages: the front-end is too inviting for the easily confused, and too annoying for the bare-metal types.
[11:40] <ogra> we do neither here
[11:43] <kish> hi.. i have a minimal maverick filesystem that works with arm.. it does not have dpkg.. and i want to install additional debian packages..
[11:44] <persia> Install dpkg :)
[11:44] <kish> only if i know how i can install it..
[11:44]  * ogra wonders how you can have an ubuntu rootfs without dpkg in the first place
[11:44] <persia> Hrm.  That gets tricky.  Do you know that your userspace is entirely compatible with Ubuntu?  If so, which release?
[11:45] <persia> ogra, Careful manual hacking of the rootfs post-construction.
[11:45] <ogra> heh, but very careful with much effort
[11:46] <persia> kish, Do you have ar and tar available?  Alternately, do you have filesystem access to the rootfs from another device.
[11:46] <persia> ogra, Yes: the sort performed by the most annoying class of OSV
[11:46] <kish> yes.. i have tar ball available.. i access the rootfs from OMAP3430 using nfs..
[11:47] <persia> NOTE: the following is disrecommended, dangerous, and incomplete
[11:48] <kish> yeah.. fine..
[11:48] <persia> I'd probably unpack the armel dpkg .deb (make sure you have the Pre-Depends working first), and install the files manually.
[11:48] <persia> The run the preinst and postinst manually.
[11:49] <persia> Note that dpkg may not work as expected when this is complete, as /var/lib/dpkg is likely not properly populated.
[11:49] <persia> Mind you, the above is risky, and not in any way sure to achieve your goal.
[11:50] <persia> In most cases, if you have the ability to replace the rootfs, you'd do better creating a new one from scratch.
[11:51] <kish> i got that rootfs from someone else.. well then I'd probably try to create a new rootfs..
[11:51] <persia> Easiest is probably to use the release image.  If that doesn't work, some people are happy with rootstock.
[12:03] <lilstevie> how the hell do you get an ubuntu, or any debian variant for that manner without dpkg 0.o
[12:06] <premkiran> Hi
[12:06] <premkiran> Did anyone try arecord on ubuntu on OMAP4 blaze board
[12:06] <persia> !ohmy | lilstevie
[12:06] <ubot2> lilstevie: Please remember that all Ubuntu IRC channels share the same attitude of providing friendly and polite interaction with all users of all ages and cultures. Basically, this means no foul language and no abuse towards others.
[12:07] <premkiran> We observe that the arecord on ubuntu is not working for blaze
[12:07] <persia> lilstevie, Consider that someone could create a rootfs, and then delete individual files.
[12:11] <premkiran> NM: we see arecord has a problem with ubuntu on blaze
[12:58] <slnr> hi NM
[13:03] <slnr> NishanthMEnon: we were discussing about the issue of http://pastebin.mozilla.org/1047108
[13:25] <RBT> rob: gst-launch filesrc location=Angelina.mp4 ! qtdemux ! nal2bytestream_h264 ! omx_h264dec ! filesink location=test.yuv
[13:25] <RBT> this pipeline fails
[13:25] <RBT> rob: unable to dump in yuv file
[13:26] <persia> RBT, Is this different than the issue with not supporting untiling buffers identified before?
[13:27] <RBT> persia/rob: gst-launch filesrc location=Angelina.mp4 ! qtdemux ! nal2bytestream_h264 ! omx_h264dec ! v4l2sink
[13:27] <slnr> persia: me and RBT are together
[13:27] <RBT> this pipeline works fine on blaze
[13:28] <persia> I thought ndec said this was expected behaviour.  If it's a bug, then it's worth reporting a bug, but if it's expected, then use gst-ducati
[13:28] <slnr> persia: we installed gst-ducati
[13:29] <slnr> persia: we do not have pointers of how to fix the pipeline with gst-ducati
[13:29] <persia> Doesn't that have a different gstreamer bit than omx_h264dec ?
[13:30] <persia> I'd think you'd want ducatih264dec
[13:30] <persia> But i'm just guessing, really.
[13:30] <persia> (based on http://bloggingthemonkey.blogspot.com/2010/11/announcing-libdce-and-gst-ducati.html )
[13:30] <slnr> persia: did not get
[13:31] <persia> If you want to use a different decoder, you need to change the gstreamer pipeline.  Just installing a different package gives you the capability to use a different decoder, but doesn't actually use it.
[13:32] <slnr> persia: yes we understand
[13:32] <slnr> persia: so you say we can replace the omx_h264dec with ducati plugin and check ??
[13:32] <RBT> persia: we are looking for both playback and capture. for eg gst-launch omx_camera mode=1 exposure=1 awb=1 nsf=1 device=secondary output-buffers=2 name=cam cam.src ! "video/x-raw-yuv-strided, format=(fourcc)NV12, width=864, height=480, framerate=15/1" ! ffmpegcolorspace ! omx_h264enc input-buffers=3 output-buffers=2 bitrate=4000000 profile=1 level=2048 ! qtmux ! filesink location=/home/blaze/test_
[13:32] <RBT> 1.mov
[13:33] <persia> That's what I'd do if I was having that problem, but I'm just guessing.  I have no deep knowledge about the issue.
[13:33] <ndec> RBT: capture? our public ducati firmware does not support capture and encode.
[13:33] <slnr> # looking into capabilities of ducati plugin
[13:33] <persia> RBT, From the backscroll, I have the impression that if you're working on an OMAP4 platform, you want to use the ducati* plugins, rather than the omx_* plugins.  Change your pipeline.
[13:34] <persia> Ah, if no capture, then no capture :)
[14:17] <kish> hi.. i use a minimal maverick filesystem on OMAP3. whenever i execute any command I get an illegal instruction error..
[14:21] <persia> kish, Are you sure you're using an armel filesystem with armel packages?
[14:21] <kish> yes.. the same file system works well in omap4..
[14:22] <persia> Very odd.
[14:32] <vstehle> kish: does your kernel support thumb2 ?
[14:39] <kish> i see "# CONFIG_THUMB2_KERNEL is not set" and CONFIG_AEABI=y" in my .config
[14:40] <vstehle> kish, not sure if 'CONFIG_THUMB2_KERNEL' means "kernel supports thumb2 user space" or "kernel compiled in thumb2 (experimental)"
[14:40] <kish> ok i'll give a try..
[14:40] <lool> vstehle: I don't think there's a tunable to disable Thumb 2; I think this is to build your kenrel as a Thumb 2 binary
[14:41] <vstehle> lool: I think you can disable support for thumb2
[14:42] <vstehle> Lxr says thumb2_kernel means kernel compiled in thumb2. kish, this is not this one
[14:42] <vstehle> http://lxr.linux.no/#linux+v2.6.35/arch/arm/Kconfig#L1194
[14:42] <kish> err.. crashed when i set CONFIG_THUMB2_KERNEL
[14:42] <lool> CONFIG_THUMB2_KERNEL is definitely to have a kernel using thumb itself
[14:42] <apw> ogra, is ubuntu-mobile@lists still valid ?
[14:43]  * apw notes that is where he is sending natty upload notificaions to ...
[14:43] <ogra> apw, nope
[14:43] <lool> vstehle: I don't see the option to disable thumb in arch/arm/Kconfig
[14:43] <apw> do you get those?  i am not getting an error
[14:43] <vstehle> lool, yeah me neither. I should have mistaken with NEON, sorry.
[14:44] <ogra> apw, not sure, they might get /dev/null'ed
[14:44] <apw> ogra, now that has to be the silliest idea ever
[14:44] <ogra> i dont get any mails from that list anymore
[14:45] <ogra> to be honest i have no idea whats IS policy of shutting down a list
[14:51] <sebjan> lool, vstehle, kish: are you looking for CONFIG_ARM_THUMBEE?
[14:52] <vstehle> nope. Thumb2
[14:52] <vstehle> (thumbee is more "java")
[15:14] <dmart> vstehle: did you solve your problem?
[15:15] <vstehle> dmart, you mean kish's problem ? :)
[15:15]  * dmart scrolls back
[15:15] <dmart> vstehle: ummm, yeah
[15:16] <dmart> looks like he's gone anyhow
[15:38] <rsalveti> janimo: how did your x-loader/u-boot update testing go?
[15:38] <rsalveti> janimo: did it work fine? or did it break?
[15:38] <janimo> rsalveti, well it seesm copying works, but not all the time. It may not be the copy itslef but rather the version of the firmware?
[15:39] <janimo> should versions of x-loader and u-boot be independent?
[15:39] <janimo> tried xloader 1.41 and would not start (Xloader hung)
[15:39] <ogra> they are not aligned atm
[15:39] <rsalveti> janimo: but what version did you use?
[15:39] <janimo> but I am testing
[15:39] <rsalveti> not aligned
[15:39] <janimo> defaults from natty and those from an angrstrom page
[15:39] <rsalveti> because if you get it quite frequently, then it'll be good to change the tool to recreate the first partition
[15:40] <janimo> ok not aligned but can they be incompatible? like uboot require a minimum version of xloader?
[15:40] <janimo> rsalveti, indeed, let's see how testing goes
[15:40] <rsalveti> janimo: well, it should be fine if you test the maverick's x-loader/u-boot with natty's one
[15:40] <janimo> ok
[15:41] <rsalveti> janimo: and also, you set the create the wiki page to done, but it's still a work in progress
[15:41] <janimo> well it is created
[15:41] <rsalveti> :-)
[15:41] <janimo> it reflects the current status :)
[15:41] <rsalveti> yeah, not the best word used there
[15:42] <janimo> the rest is bugfixing/polish.
[15:42] <janimo> I just need to figure out which of the many proposed notification solutions is the simplest and most effective
[15:43] <janimo> without having to explicitly differnetiate between gui and headless if at all possible
[15:43] <rsalveti> yeah, true
[16:31] <alf__> rsalveti: (sorry to repeat this, I am not sure if it got through because of the netsplit)
[16:31] <alf__> rsalveti: Any luck with clutter and the shaders?
[16:33] <rsalveti> alf__: http://bazaar.launchpad.net/~rsalveti/clutter/gles/view/head:/debian/patches/defining-correct-shader-precision-gles.patch
[16:33] <rsalveti> then it worked fine
[16:34] <alf__> rsalveti: so the precision is needed in the vertex shader, too... interesting
[16:35] <rsalveti> yup, otherwise it still break
[16:35] <alf__> rsalveti: the question is whose fault this is? Is sgx not following the standard?
[16:35] <rsalveti> yeah, I'd say yes, but still need more debugging
[16:36] <rsalveti> will also try with latest sgx drop as soon I get it working with natty
[16:36] <rsalveti> this version I'm using is not supported anymore
[16:37] <alf__> rsalveti: From the standard: The vertex language has the following predeclared globally scoped default precision statements:
[16:37] <alf__> precision highp float;
[16:38] <alf__> ...
[16:38] <alf__> The fragment language doesn't have that
[16:39] <alf__> The fragment language has no default precision qualifier for floating point types
[16:39] <rsalveti> alf__: well, this is clearly not the case for sgx
[16:39] <rsalveti> at least the patch is not going to break others
[16:39] <rsalveti> but should be fixed inside sgx
[16:40] <rsalveti> alf__: as soon I can test the new pvr driver I'll report that to imagination
[16:41] <alf__> rsalveti: what puzzles me is that glmark2 should fail, too, (because it doesn't declare float precision in vertex shaders)
[16:41] <rsalveti> alf__: probably
[16:41] <rsalveti> did you test that with omap 4?
[16:42] <alf__> rsalveti: but last time I tried it it worked (on the SDP)
[16:42] <rsalveti> hm
[21:00] <lool> persia: I wrote u-boot-linaro-efikamx and an uImage created with mkimage -A arm -O linux -T kernel -C none -a 0x90008000 -e 0x90008000 -n Linux from linux-linaro-mx51, and could boot up to a kernel panic looking for rootfs
[21:01] <lool> persia: seems to work fine on efikamx; I see USB EHCI, consoles, MMC... and obviously serial
[22:42] <persia> lool, Thanks for checking that.  I'm filled with new confidence.  After the 2.6.38-rc5 release, I'll identify specific patches to add to improve things.
[22:47] <Lopi> Does anyone have any recommendations for virtual keyboards?
[22:47] <Lopi> I made a custom keyboard layout for matchbox-keyboard and it works decent


[00:01] <Unit193> Looks good.
[00:03] <pleia2> thank you!
[04:39] <JoseeAntonioR> pleia2_: hey, would you mind a PM?
[04:43] <Unit193> Good luck in this weather. :P
[05:11] <pleia2_> JoseeAntonioR: any time
[23:39] <pleia2> askubuntu script fixed \o/ hooray for Oli
[23:39] <pleia2> (I'll upload new one to code repo after I release)