[12:29] <zul> evening
[12:50] <zul> cool...my crappy usb camera just works
[06:41] <fabbione> morning
[09:04] <fabbione> dilinger: testing the patch now :-)
[09:07] <fabbione> ah he is not here
[02:37] <zul> morning
[02:38] <fabbione> hey zul
[02:38] <zul> hey fabbione how is it going?
[02:39] <zul> oh how i hate windows media player
[02:41] <jbailey> You don't have access to a better media player
[02:41] <jbailey> ?
[02:41] <zul> yeah but its windows that im on at work though as my main pc
[02:42] <zul> if i run winamp the windows media player just starts at the same time
[02:43] <zul> *sigh* i dont think you need to put your full address in your wiki page ;)
[02:43] <zul> http://www.ubuntulinux.org/wiki/DongCalmada
[02:46] <jbailey> Ah, I was thinking winamp, but couldn't remember what it was called. =)
[02:51] <zul> T-Bone disapeared?
[02:52] <zul> i havent seen him all weekend
[03:00] <jbailey> He may have for a bit.  He's really pissed.
[03:00] <zul> oh?
[03:00] <jbailey> He's been working his brains out to try and get ia64 into a release state for Hoary because he was told that if he met certain requirements it would be let in.
[03:00] <jbailey> Basically without any further discussion during the dev meeting, he was told otherwise.
[03:00] <zul> oh right
[03:00] <jbailey> Clearly and publiclly.
[03:00] <fabbione> zul: i am ok thanks. please see /t
[03:01] <zul> fabbione: ok will do
[03:01] <fabbione> jbailey: clearly and public the point is that if it wasn't for me pushing him to start testing ia64
[03:01] <fabbione> nobody was going to do so
[03:01] <fabbione> i don't have an ia64 myself and even tho i did take care of producing an ia64 kernel
[03:02] <fabbione> so clearly he did ask for the buildd & co
[03:02] <fabbione> and he expected us to do the rest
[03:02] <fabbione> well that was not the original agreement
[03:02] <fabbione> so he has nothing to be pissed
[03:03] <jbailey> fabbione: As if emotions are clearly ruled by logic. =)
[03:04] <jbailey> He simply had his heart set on it, and beleived that if he met a couple requirements, it would be accepted.  It didn't happen that way and he's angry about it.
[03:04] <fabbione> well he didn't meet the requirement
[03:04] <jbailey> Right.
[03:04] <fabbione> so there is noone to blame
[03:05] <fabbione> i was hoping to get sparc for hoary, but i can see it myself that it won't make
[03:05] <fabbione> but that doesn't mean that i am pissed about it
[03:05] <fabbione> i know that i have been doing a lot of work
[03:05] <fabbione> and that it will all flow in bendy
[03:05] <fabbione> (and note that i don't even have the buildds at the dc)
[03:06] <fabbione> (so it took me ages more to get stuff in place)
[03:06] <jbailey> Sure.  But we don't all react the same way to things.
[03:06] <fabbione> to be hounest i think he is a bit too impulsive
[03:06] <fabbione> but that's just my opinion
[03:07] <fabbione> jbailey: but yes. i fully agree with you. we don't react all the same way
[03:07] <jbailey> We need impulsive people in the world to suggest the things that us stodgy people would never otherwise consider. =)
[03:07] <jbailey> But it probably sucks to be impulsive and to run against brick walls all the time. =)
[03:07] <fabbione> jbailey: STFU! ARE YOU GOING TO CONSIDER THIS? :P
[03:08] <zul> now now :)
[03:08] <fabbione> just kidding ;)
[03:08] <fabbione> zul: jb and i know each other
[03:08] <fabbione> from DC3 and DC4
[03:08] <zul> i know i was be kidding as well
[03:08] <jbailey> zul: Don't worry.  There's nothing in the SC keeping Fabio and I from getting drunk and slugging it out in a bar at UDU. ;)
[03:08] <fabbione> (tho he still needs to sign my gpg key)
[03:08] <zul> jbailey: i would pay to see that ;)
[03:09] <fabbione> jbailey: at UDU it will be the 3rd time we meet :-)
[03:09] <zul> *sniff* im the outsider :)
[03:09] <fabbione> jbailey: it's time for you to consider to sign my key ;)
[03:09] <jbailey> fabbione: Yeah, I know.  I have to find that folder. =(
[03:09] <fabbione> nah don't worry
[03:09] <jbailey> fabbione: I left it too long, and have moved everything.  I'm not sure where it is.
[03:09] <fabbione> let's do it at UDU
[03:09] <fabbione> jbailey: also because since DC4 i have a new key too
[03:09] <fabbione> for ubuntu/canonical
[03:10] <jbailey> at UDU I'll probably have met people enough times that it'll be worth just playing along with the keysigning and dropping the occasional person out.
[03:10] <jbailey> I think I'll actually know most people there.
[03:10] <fabbione> jbailey: yeah
[03:10] <fabbione> that's the easiest
[03:10] <jbailey> I've been trying to decide whether to do that.
[03:10] <jbailey> (a new key for Ubuntu/Canonical)
[03:10] <fabbione> i did.
[03:10] <fabbione> for one simple reason
[03:10] <jbailey> I don't like the idea of putting work email addresses on my home keys.
[03:10] <fabbione> i don't like to mix private/debian/work stuff
[03:11] <fabbione> exaclty
[03:11] <jbailey> That's why I use the imap server instead of having stuff forwarded to my home account, too.
[03:11] <fabbione> we all remember when lamont had to revoke his hp uid
[03:11] <zul> well not all 
[03:11] <fabbione> i use an imap server at home for speed reasons, but separate folders/accounts
[03:11] <fabbione> zul: there a huge shake in WOT
[03:12] <fabbione> that was tracked by all the graphers around
[03:12] <zul> ah ok
[03:12] <fabbione> i think he lost something like 20 positions in the WOt in one shot
[03:12] <fabbione> that is quite a lot
[03:13] <jbailey> fabbione: Yeah, I just figured out the local synchronisation bits in evolution.
[03:13] <jbailey> fabbione: I did it while working at the web caf last week so I could read my email at home.
[03:14] <fabbione> tbh i would still be using pine but i wanted to try a GUI application and i landed with thunderbird
[03:14] <fabbione> but i can switch anytime
[03:14] <fabbione> since all the filtering is done on the server
[03:14] <fabbione> i just have to resub to the different mailboxes
[03:15] <jbailey> I started using evo when my wife switched from mutt (she had been using elm at her school)
[03:15] <jbailey> She wanted a graphical interface, and I wanted to be able to answer her questions.
[03:15] <zul> isnt that sweet 
[03:16] <jbailey> zul: It's marriage-preserving ;)
[03:16] <fabbione> eehhehe
[03:16] <zul> mine doesnt work like that
[03:17] <fabbione> humpf i have almost finished the sync with debian 2.6.10-5
[03:17] <fabbione> and i still miss another release to check
[03:18] <fabbione> but now we have the 31337 abi checker to help us
[03:20] <zul> debian's hotplug is suppose to fix a bunch of firmware issues apparently
[03:21] <fabbione> i am pretty sure it would need merge to be ported
[03:33] <zul> oooh...are linux sys admin upgraded to hoary
[03:33] <fabbione> ???
[03:34] <zul> sorry our linux sys admin here at work upgraded to hoary
[03:34] <fabbione> ah
[03:34] <zul> still too early in the morning
[03:34] <fabbione> you should have told them to wait a sec
[03:34] <zul> too late
[03:35] <fabbione> tomorrow we are going out with this big fat kernel
[03:35] <zul> with all the security updates
[03:35] <fabbione> yup
[03:35] <fabbione> and a few tons of bug fixes
[03:35] <fabbione> zul: btw.. your patches?
[03:35] <zul> yep getting them ready now
[03:35] <fabbione> i can't wait forever to get them
[03:36] <fabbione> ok
[03:45] <zul> fabbione: http://zulinux.homelinux.net/ubuntu/kernel/2.6.10-28/
[03:46] <fabbione> hmmmmmm
[03:46] <fabbione> 6492 - no support for dell's version of sound blaster em101k
[03:46] <fabbione> how bad is this one?
[03:46] <fabbione> 55K of patch....
[03:46] <fabbione> are you sure it works?
[03:46] <fabbione> i remember the bk commit to head
[03:46] <fabbione> and it was pretty intrusive on the emu10k1 too
[03:46] <zul> havent tested it but it was pulled from bitkeeper and applies cleanly and compile cleanly
[03:47] <zul> dont have to include it if you want but it works with 2.6.11 apparenly
[03:47] <fabbione> did you pull only the emu10k1x patch or did you grab it from 2.6.11?
[03:47] <fabbione> sory let me rephrase
[03:47] <zul> only the emu101kx from bitkeeper
[03:48] <fabbione> did you take that patch from the first commit or from 2.6.11 or from bk (like today)?
[03:48] <fabbione> ok
[03:48] <fabbione> hmmm
[03:48] <fabbione> i need to check on that
[03:48] <fabbione> i am not happy to add new drivers now
[03:48] <fabbione> specially because none of us can test them
[03:48] <zul> thats cool
[03:49] <zul> http://linux.bkbits.net:8080/linux-2.5/gnupatch@41d9223fXVy6-SVqQ9fPagcX9jSi8Q
[03:50] <zul> but the other patches should be ok?
[03:50] <fabbione> did you check if there were any updates from the first commit?
[03:50] <zul> havent been updated in 13weeks
[03:50] <fabbione> so it has been stable since first commit...
[03:51] <zul> afaik yes
[03:51] <fabbione> can you please triple check?
[03:51] <fabbione> i don't mind to add it
[03:51] <fabbione> i know it compiles
[03:51] <zul> yes i can do that when i get home tonight
[03:51] <fabbione> we saw that in 2.6.11-pre
[03:51] <fabbione> well i guess i can just check with bk here
[03:53] <lamont> fabbione: from 13 to > 100 is not 20 positions...
[03:53] <lamont> morning all
[03:53] <zul> hey lamont
[03:54] <fabbione> hey lamont 
[03:54] <zul> but the other patches should be fine
[03:54] <fabbione> lamont: well i couldn't really remember
[03:54] <fabbione> keyboard-i8042 has a possible ABI change
[03:54] <fabbione> anyway we need to bump the abi
[03:55] <zul> bleah..when you bump the abi put the inotify 0.20 stuff back in
[03:55] <lamont> fabbione: that was also about the time that they actually started paying attention to the revokations in the WoT graphs - I wasn't solely responsible for the dip
[03:55] <lamont> zul: was it just inotify that was bad?
[03:55] <zul> lamont: yep looks like it
[03:56] <lamont> inotify sure seems to be shooting for most cursed status
[03:56] <zul> by the time everything got compiled on saturday fabbione already uploaded a new kernel
[03:57] <fabbione> http://svn.debian.org/wsvn/kernel/trunk/kernel/source/kernel-source-2.6.10-2.6.10/debian/patches/087-ext3_graceful_corruption_fixes.dpatch?op=file&rev=0&sc=0
[03:57] <lamont> ouc
[03:57] <lamont> h
[03:57] <fabbione> this is the patch that breaks the ABI
[03:57] <lamont> ah, ok
[03:57] <fabbione> tell me if it is worth the troubles according to your opinion
[03:57] <zul> er..no
[03:57] <zul> fo inotify
[03:57] <fabbione> zul: did you read the patch name or the entire changelog?
[03:58] <zul> i was talking about inotify
[03:58] <fabbione> ah ok
[03:58] <fabbione> please guys look at that patch and give me your opinion
[03:58] <fabbione> a yes here means changing the ABI
[03:59] <fabbione> there might more patches that can do that
[03:59] <zul> well how often does ext3 fail?
[03:59] <fabbione> i am not sure yet
[03:59] <fabbione> i only synced up to 2.6.10-5 in debian
[03:59] <fabbione> zul: ENOCLUE
[03:59] <fabbione> i really have no idea how often it can happen
[03:59] <mjg59> fabbione: Did you get my b44 patch
[04:00] <fabbione> mjg59: i read it in the mail yes..
[04:00] <fabbione> mjg59: haven't check it 100% yet
[04:00] <fabbione> mjg59: i have a pile of security updates under check right now.. sorry
[04:00] <fabbione> it might be for -29
[04:00] <mjg59> fabbione: No problem
[04:00] <zul> ++
[04:00] <fabbione> mjg59: what is your opinion on the above ext3 patch?
[04:01] <fabbione> zul: ++ to what?
[04:01] <zul> fabbione: i say go for it
[04:01] <zul> belt and suspenders
[04:01] <zul> bumping the abi anyways so go for it
[04:01] <fabbione> hmmmm
[04:02] <fabbione> why anyway?
[04:02] <fabbione> this is the only patch atm that breaks the ABI
[04:02] <fabbione> #   This is easily reproduced with a sample ext3 fs image containing an inode
[04:02] <fabbione> #   whose direct and indirect blocks refer to a block bitmap block.  Allocating
[04:02] <fabbione> #   new blocks and then deleting that inode will BUG() with:
[04:02] <fabbione> #   
[04:02] <fabbione> #   Assertion failure in journal_forget() at fs/jbd/transaction.c:1228:
[04:02] <fabbione> #   "!jh->b_committed_data"
[04:02] <fabbione> no
[04:02] <fabbione> we can skip it
[04:02] <fabbione> even if it is an annoying problem
[04:02] <fabbione> it is not necessary to have
[04:02] <fabbione> but let see lamont and mjg59 
[04:06] <lamont> seems pretty innocuous
[04:07] <mjg59> I think it's generally preferable to avoid corrupt filesystems breaking the kernel...
[04:07] <mjg59> It's better to bump the ABI now than to find we need to again later on
[04:08] <Mithrandir> mjg59: did you talk to Naima last night?
[04:08] <Mithrandir> mjg59: she had some "interesting" experiences where she did a suspend, boot normally, use the box for a little, then boot with resume.
[04:08] <fabbione> ok so we will go for it and break the ABI
[04:09] <lamont> Mithrandir: that would be, um, interesting. to be sure
[04:09] <lamont> fabbione: btw, you ROCK.
[04:09] <mjg59> Mithrandir: Yeah, I talked to her about that.
[04:10] <Mithrandir> lamont: yeah; think it should then say "lalala, you've booted in the meantime, I won't resume, lalala" or something.
[04:10] <mjg59> The swapon script should check whether the swap partition has a suspend signature, and if so mkswap it
[04:10] <fabbione> lamont: what i did NOT do this time to rock? ;)
[04:10] <Mithrandir> mjg59: I think it should refuse to resume if you've booted in the meantime.
[04:10] <mjg59> Mithrandir: How could it know?
[04:10] <mjg59> We can't touch the filesystem at that point
[04:10] <Mithrandir> you can touch the filesystem before suspending
[04:11] <Mithrandir> and remove the file when booting normally
[04:11] <mjg59> But we can't read from the filesystem
[04:11] <Mithrandir> or something like that.
[04:11] <Mithrandir> hm, that sucks.
[04:11] <mjg59> If we mount the filesystem, the journal gets replayed
[04:11] <Mithrandir> even r/o?
[04:11] <mjg59> Yes
[04:11] <Mithrandir> that sucks.
[04:11] <mjg59> Indeed
[04:12] <mjg59> mkswapping over the resume partition on boot fixes all but the most pathological cases
[04:12] <Mithrandir> true enough
[04:12] <lamont> fabbione: I finally got to my email and read your replies to pitti
[04:12] <fabbione> lamont: ah eheheh
[04:12] <fabbione> lamont: wait to do a baz update :-)
[04:13] <mjg59> fabbione: The sooner the b44 patch can go in the better from the dealing with HP point of view, but feel free to leave it to -29 if it's a problem
[04:13] <lamont> fabbione: you mean wait until I do? or that I should wait before I do?
[04:15] <fabbione> mjg59: i think i can make it for -28 given that we will break the ABI
[04:15] <fabbione> lamont: just wait a couple of more minutes
[04:15] <mjg59> fabbione: Ok, thanks
[04:17] <fabbione> mjg59: does it work for you?
[04:19] <mjg59> fabbione: It stops the machine from freezing when HAL starts, yes
[04:20] <mjg59> It means that mii ioctls won't do anything until the interface has been brought up
[04:20] <fabbione> yes i see
[04:20] <mjg59> I'm not sure if that's the best approach, but it works
[04:20] <fabbione> it looks sane to me
[04:20] <fabbione> if the iface is down .. no ioctl
[04:20] <mjg59> It may mean that we don't get auto-interface up on cable plug in that chipset, but I don't think we support that anyway yet
[04:21] <fabbione> no we don't
[04:22] <fabbione> mjg59: queued
[04:22] <fabbione> guys you can baz update now ;)
[04:22] <fabbione> no ABI bump done at packaging level YET
[04:22] <mjg59> fabbione: Rocking. Thanks.
[04:22] <fabbione> no problem
[04:23] <fabbione> upload will be tomorrow after 14:00 UTC
[04:24] <zul> none of my stuff made it in?
[04:25] <fabbione> zul: hell gimme a break
[04:25] <fabbione> i am working on it
[04:25] <fabbione> this is the work of the last 3 hours of merging
[04:25] <zul> fabbione: heh sorry
[04:26] <zul> sorry mybad
[04:26] <fabbione> eheh
[04:26] <fabbione> at least now we know 100% that the abi checker is working properly
[04:28] <fabbione> who feel like preparing l-r-m for tomorrow?
[04:29] <fabbione> actually we need to tell Kamion too
[04:29] <zul> i need to get my baz archive setup eventually
[04:30] <lamont> zul: any home machines have apache running on them?
[04:30] <zul> yep
[04:30] <lamont> because that's the simplest way to publish
[04:31] <zul> its the same machine where i put my patches for you guys
[04:32] <lamont> it can either be your actual repository (and you use an sftp:// url while we use http://), or it could be a mirror of your actual repository
[04:33] <zul> ok...i did a little reading about it this weekend
[04:33] <zul> it will probably be something like http://zulinux.homelinux.net/Archive or somthing im not sure yet
[04:34] <fabbione> zul: anything is fine for us
[04:34] <fabbione> sftp would require us to have access to your box
[04:34] <fabbione> while with http we can just merge from you
[04:35] <zul> its going to be http i dont trust you fabbione ;)
[04:35] <fabbione> that's a good point to start from
[04:35] <fabbione> considering i have kernel privileges on your machine :-)
[04:35] <zul> yeah i want to sleep at night :)
[04:35] <lamont> LOL
[04:37] <Mithrandir> fabbione: you're assuming he runs _your_ kernel on his box.. he might be... running NetBSD! :P
[04:37] <zul> and it might be chrooted
[04:37] <fabbione> Mithrandir: i still have commit access to XORG CVS :-) 
[04:38] <fabbione> shhh
[04:38] <fabbione> zul: other than the emu10kx.. are the other patches from HEAD or did you grab them around?
[04:38] <Mithrandir> zul: chroots won't help you if he has your kernel
[04:38] <zul> fabbione: grabbed them around. the keyboard is from 2.6.10-ac9 
[04:38] <fabbione> but i would have access to the main host even from a chroot that has proc mounted
[04:39] <zul> the nforce one is from linux-usb ml and the via-oops is from head
[04:39] <zul> fine ill just turn my box OFF then 
[04:39] <fabbione> ok
[04:46] <zul> bwaha...its alive! its alive!! sorry
[04:48] <fabbione> ehehhe
[04:53] <fabbione> zul: baz update :-()
[04:53] <fabbione> your bits are merged
[04:53] <fabbione> other than the emu10k1x
[04:53] <fabbione> i want to look at it again
[04:53] <fabbione> time to merge mjg59 
[04:56] <zul> sweet
[04:56] <fabbione>   Changes by Matthew Garrett:
[04:56] <fabbione>   * b44 should not accept ioctls if the interface is down:
[04:56] <fabbione>     - Add patch fix-b44.dpatch.
[04:56] <fabbione>     (Closes: #7490)
[04:57] <fabbione> mjg59: ok for you? or do you want me to change something else?
[04:57] <zul> you can ask the guy who requested the em101kx to test it
[04:57] <fabbione> zul: there won't be time for that
[04:57] <fabbione> i can't release binary image before tomorrow
[04:57] <zul> oh yes...time 
[04:57] <fabbione> not even for testing
[04:57] <mjg59> fabbione: No, that's fine
[04:58] <fabbione> mjg59: ok
[04:58] <lamont> fabbione: one more thing for -28...
[04:58] <lamont>         kernel-wedge find-dups 2.6.10-4-hppa64
[04:58] <lamont> find: lib: No such file or directory
[04:58] <lamont> nfs-modules-2.6.10-4-hppa32-di will be empty
[04:59] <fabbione> uh weird...
[04:59] <lamont> hrm.. wonder how many more there were before you removed the || true
[05:00] <fabbione> oh that's easy
[05:00] <fabbione> nfs is compiled in on hppa
[05:00] <fabbione> there are no modules
[05:00] <lamont> nfs-modules... is the only one that says it'll be empty
[05:00] <fabbione> yes
[05:01] <fabbione> and it is empty
[05:01] <fabbione> it's enough to remove nfs-modules.lnk
[05:01] <fabbione> in debian/d-i/hppa/modules/hppa/
[05:01] <fabbione> this is thanks to our super alligned configs
[05:02] <fabbione> that 2 persons (one of which in this chan right now) should have analized for hoary
[05:03] <fabbione> we don't make names
[05:03] <fabbione> only surnamed
[05:03] <fabbione> surnames
[05:03] <fabbione> eh Short?
[05:03] <fabbione> doesn't it ring a bell?
[05:03] <zul> someone called my name?
[05:03] <fabbione> eheheh
[05:03] <lamont> fabbione: maybe he didn't analyze the bastard stepchildren
[05:04] <fabbione> yeah
[05:04] <lamont> the find: lib: No such file or directory is kind of interesting as well.. or is that normal?
[05:04] <fabbione> it is normal
[05:04] <fabbione> since debian/nfs-modules-<whatever>/lib isn't there at all
[05:05] <fabbione> no modules -> no need to create the dir
[05:07] <fabbione> applying patch fix-b44 to ./ ... failed.
[05:07] <fabbione> doh!
[05:08] <fabbione> ah yeah
[05:09] <fabbione> mjg59: note for the next time: send me a dpatch :-)
[05:35] <fabbione> baz commit -s'Merge mjg59' -- changelog patches/fix-b44.dpatch patches/00list-28
[05:35] <fabbione> These files would be source but lack inventory ids (`baz add' perhaps?):
[05:35] <fabbione> patches/stolen-from-head_ppp-no-dos.dpatch
[05:35] <fabbione> M  changelog
[05:35] <fabbione> make-changeset-files: file missing from ORIG tree (patches/fix-b44.dpatch)
[05:35] <fabbione> what the hell is wrong with baz?
[05:38] <fabbione> hey
[05:38] <ddaa> hey
[05:38] <fabbione> i am getting a really strange error with baz
[05:38] <fabbione> baz commit -s'Merge mjg59' -- changelog patches/fix-b44.dpatch patches/00list-28
[05:39] <fabbione> make-changeset-files: file missing from ORIG tree (patches/fix-b44.dpatch)
[05:39] <fabbione> but the file has been added
[05:40] <ddaa> you cannot do partial commit (yet) when the inventory was changed
[05:40] <ddaa> hu... not right
[05:40] <fabbione> i did partial commits before and it was working fine
[05:40] <ddaa> you cannot do partial commit for new/removed/renamed files
[05:40] <fabbione> ah
[05:40] <fabbione> suckage
[05:40] <fabbione> ok
[05:40] <ddaa> That can be fixed.
[05:40] <ddaa> The issue is that currently partial commit does not do inventory, so it cannot tell if the file is really new or just renamed.
[05:41] <ddaa> probably it will be time to fix it when there will be a "baz edit" to make life livable with kernel-sized trees.
[05:42] <ddaa> But i suggest you file a bug for the obscure error message.
[05:42] <fabbione> ddaa: malone or bugzilla?
[05:42] <ddaa> IIRC we are officially in malone again
[05:42] <ddaa> mark's fault
[05:42] <fabbione> ahhh
[05:43] <fabbione> i don't want to know :-)
[05:44] <fabbione> thanks ddaa.. that was it :-)
[05:44] <ddaa> be my guest
[05:46] <fabbione> lamont: hppa ftbfs is fixed
[05:46] <fabbione> or it should be at least
[05:47] <zul> lunch
[05:48] <lamont> fabbione: thansk
[05:48] <fabbione> no problem
[05:48] <fabbione> lamont: do you still have -27 on your buildd?
[05:48] <fabbione> or did you trash it?
[05:49] <fabbione> well actually.. no
[05:49] <fabbione> it's pointless
[05:49] <fabbione> nevermind
[05:49] <lamont> head build-hoary/chroot-hoary/build/buildd/linux-source-2.6.10-2.6.10/debian/changelog 
[05:49] <lamont> linux-source-2.6.10 (2.6.10-27) hoary; urgency=low
[05:50] <lamont> uh, yeah. :-)
[05:50] <fabbione> i was going to ask you for the abi files, but we already know they will change
[05:50] <fabbione> so it's useless :-)
[05:53] <lamont> ah, ok
[05:56] <fabbione> zul: the emu10k1x driver has been updated regularlly. and the last commit is from 4 days ago.
[05:56] <fabbione> zul: just FYI.
[05:56] <fabbione> i am going to see if it can be built
[06:06] <lamont> fire call
[06:19] <svenl> fabbione: hi you.
[06:21] <fabbione> re
[06:21] <fabbione> i was checking the code...
[06:21] <fabbione> i don't really understand why you use arch_initcall() in the beginning
[06:21] <fabbione> but i need to look trough all the code
[06:22] <fabbione> just gimme a few secs.. i need .11 orig tar.gz
[06:22] <fabbione> oh there is no orig in the archive...
[06:22] <fabbione> humpf...
[06:24] <fabbione> `linux-2.6.11.tar.gz' at 1826600 (3%) 76.9K/s eta:10m [Receiving data]   
[06:31] <fabbione> svenl: getting there.. slowly :-)
[06:32] <svenl> fabbione: well, code is not from me, at first it was to initialize the arch-specific part, which should not be in the drivers/net/mv643xx_eth.c driver (see other marvell patch)
[06:33] <svenl> fabbione: i had some code doing OF device-tree probing in place which worked, but hch suggested doing pci_find_device instead.
[06:36] <fabbione> svenl: ok.. let's see one thing at a time
[06:36] <fabbione> this is a network driver right?
[06:38] <svenl> fabbione: sure, a mips-and-ppc driver.
[06:38] <fabbione> so in the first place i would move it to drivers/net/<where_appropriate> and do a proper Kconfig entry for it
[06:38] <fabbione> because a network card is initialized much later than the arch specific code
[06:39] <svenl> fabbione: Dale Fornsworth from montavista isolated all the arch independent code and moved them into arch/ppc|mips.
[06:39] <svenl> fabbione: the only thing i am really doing is setting a couple of arch-specific info, like where the NB chip is mapped, and what interrupt to use, in the ad-hoc structure that the arch-indep driver then uses.
[06:40] <fabbione> hmmmm
[06:40] <fabbione> i think it is a bad idea because it will spread the code all over the place
[06:40] <fabbione> but anyway
[06:41] <svenl> fabbione: so my only problem is to detect the northbridge through its pci id, and then set the stuff with platform_add_devices.
[06:42] <svenl> arch_initcall is called before the pci tree is filled, but there should be a way to have mv643xx_eth_add_pds executed later, after the pci tree has been filled.
[06:42] <fabbione> arch_initcall is a synonimous for module_init() btw
[06:42] <fabbione> #define arch_initcall(fn)               module_init(fn)
[06:43] <fabbione> from include/linux/init.h
[06:43] <fabbione> the problem is that pci code is initizialized as driver later in the boot process
[06:44] <svenl> yep, guessed such as pci_devices was empty :/
[06:45] <fabbione> hmmmmm
[06:46] <zul> fabbione: cool moe d
[06:46] <fabbione> i think you will also hit another problem.. PCI IRQ are assigned after PCI is initialized..
[06:46] <fabbione> this is my best guess
[06:47] <svenl> fabbione: this is no problem, as we only tell the arch-indep code which pci irq to use, and it is dicted by what the open-firmware initializes at a lower level though.
[06:47] <svenl> fabbione: so, i understand you don't know either, and i should better wait for hch and ask him ? :)
[06:48] <fabbione> svenl: well i am trying to help.. not knowing the arch doesn't make it easier
[06:50] <svenl> fabbione: it was no critic.
[06:51] <svenl> fabbione: actually, my only question is if there is a equivalent to arch_initcall that will happen after the pci initialization step.
[06:51] <svenl> fabbione: but i will go ask other people later if i don't find it by myself.
[06:53] <fabbione> svenl: i think you cannot call pci_find_device at all there
[06:54] <fabbione> if do a couple grep in platform/
[06:54] <fabbione> you will notice that the only driver that does it
[06:54] <fabbione> is a mobo driver
[06:54] <fabbione> chestnut.c
[06:54] <svenl> fabbione: yep.
[06:55] <fabbione> in a special call only that is used to fix a pci parameter if a cache is set in a certain way
[06:55] <fabbione> so it basically happens after the mobo and pci are initialized
[06:55] <svenl> fabbione: don't worry, i am going to ask hch as soon as he is back,
[06:55] <fabbione> i think you really can't call it there
[06:55] <fabbione> nah it's ok.. it's not like killing my time :-)
[06:56] <svenl> fabbione: i am not sure, since the code is only linked in, and its only link to the call is rge arch_initcall.
[06:56] <svenl> fabbione: so the code could be anywhere.
[06:57] <fabbione> yes but i am more thinking in terms of code execution order
[06:57] <svenl> fabbione: the other places the code is initialized is in arch/ppc/platforms/mv64360.c, but it is a mobo driver.
[06:57] <fabbione> yes i saw that
[06:58] <fabbione> i think it would thousand times easier to just move it drivers/net
[06:58] <svenl> and same for mips, but those don't probe, they are configured at toplevel Kconfig.
[06:58] <fabbione> when the pci bus is initialized
[06:58] <svenl> fabbione: after Dale just removed all arch calls from there and it just got accepted upstream ? 
[06:59] <fabbione> well he is not God you know :-)
[06:59] <fabbione> if something cannot be done in platform/
[06:59] <fabbione> ... you can guess what i mean
[06:59] <mdz> fabbione: wow, how was the kernel build time reduced for powerpc?
[06:59] <svenl> fabbione: yep, but he, hch, benh and Mark Greer told me that it was not a good idea. I guess benh is God where ppc/linux is concerned.
[07:00] <mdz> fabbione: CONCURRENCY_LEVEL?
[07:00] <svenl> fabbione: and to add to this the marvell is no pci device, it is not present in the pci tree.
[07:00] <fabbione> svenl: ah hold on!
[07:01] <fabbione> svenl: check the call to pci_:find_device in chestnut.c
[07:01] <fabbione> it wants a dev structure as last parameter
[07:01] <fabbione> not a NULL
[07:01] <fabbione> mdz: yeps :-)
[07:01] <fabbione> mdz: i set CONCURRENCY_LEVEL as Num of cpu * 2
[07:01] <fabbione> mdz: i could go further since the code is ccached
[07:02] <fabbione> pro = code ccached = tons of times faster
[07:02] <fabbione> cons = no ccache = kill buildd for a little while
[07:02] <mdz> I usually do num_cpu + 1
[07:02] <mdz> did you do some tests?
[07:02] <svenl> fabbione: nope.         n = from ? from->global_list.next : pci_devices.next;
[07:03] <fabbione> mdz: yes. locally.
[07:03] <svenl> it it is null, it will searcg at the root.
[07:03] <fabbione> mdz: num_cpu * 2 is fine
[07:04] <fabbione> svenl: yes. i didn't say it must be a filled struct..
[07:04] <fabbione> but it might expect one there as parameter
[07:04] <fabbione> tho i am not 100% sure..
[07:04] <fabbione> but i would still try for the sake of it
[07:04] <svenl> fabbione: ok, thanks.
[07:05] <fabbione> sorry that i can't help more :(
[07:05] <mdz> fabbione: do you use getconf to query the number of CPUs?
[07:05] <svenl> fabbione: i think that i need to investigate with Dale and/or hch about this issue, and what their intention is.
[07:05] <svenl> fabbione: no problem.
[07:06] <fabbione> mdz: no. cat /proc/cpuinfo |grep ^processor 
[07:06] <mdz> fabbione: getconf should be more portable across architectures
[07:06] <fabbione> mdz: so is /proc/cpuinfo for our arches :-)
[07:06] <mdz> and centralizes the code
[07:07] <fabbione> i will check it tomorrow
[07:07] <mdz> ok
[07:07] <fabbione> it's 13 hours that i am here
[07:07] <fabbione> and i am kinda tired
[07:10] <fabbione> mdz: did you ever used getconf ?
[07:11] <fabbione> i can't see anything that tells me how many processors there are in the system.. well i must be very tired
[07:17] <mdz> fabbione: apt has used it forever
[07:17] <mdz> for the same purpose
[07:17] <mdz> getconf _NPROCESSORS_ONLN
[07:19] <fabbione> usr/bin/getconf                                             base/libc6
[07:19] <fabbione> interesting
[07:20] <fabbione> fabbione@concordia:~ $ getconf _NPROCESSORS_ONLN
[07:20] <fabbione> -bash: getconf: command not found
[07:20] <fabbione> wow :-)
[07:20] <fabbione> mdz: what does it returns on hiperthreaded proc?
[07:20] <fabbione> 1 proc
[07:20] <fabbione> or 2 (if the hyper is 2)
[07:20] <fabbione> ?
[07:31] <lamont> morning T-Bone 
[07:31] <T-Bone> hey ladude!
[07:31] <fabbione> hey T-Bone 
[07:31] <T-Bone> konichiwa!
[07:32] <T-Bone> ola fabbione
[07:33] <fabbione> T-Bone: i did some syncing with Debian, including ia64 patches (up to 2.6.10-5)
[07:33] <fabbione> i am going to parse 2.6.10-6 tomorrow morning
[07:33] <T-Bone> cool
[07:33] <fabbione> let me know if you need more stuff that what i took
[07:33] <T-Bone> don't think so
[07:33] <fabbione> we are going to bump the ABI
[07:33] <fabbione> i didn't take all the debian patches
[07:33] <fabbione> that's why i am asking
[07:34] <fabbione> if you have time give it a check
[07:34] <T-Bone> ia64 is mostly -ENOTMYPROBLEM lately
[07:34] <fabbione> i did try to level to important fixes
[07:34] <fabbione> dude.. i understand that it won't make it for hoary
[07:34] <fabbione> but that's not a good reason to give up
[07:35] <T-Bone> i have reasons
[07:35] <fabbione> hoary kernel will be the base for bendy
[07:35] <T-Bone> it's not only a problem of making for hoary or not
[07:35] <fabbione> well it's not up to me to convince you or anything
[07:35] <crimsun> fabbione: are we backporting from 2.6.11.3?
[07:36] <fabbione> crimsun: we are porting whatever fix we can :-)
[07:36] <crimsun> fabbione: or will that just end up being too much of a hassle?
[07:36] <crimsun> fabbione: ok
[07:36] <fabbione> crimsun
[07:36] <fabbione> it depends what..
[07:36] <zul> hey T-Bone 
[07:36] <fabbione> i am not going to backport a new VM right now :-)
[07:36] <fabbione> if that's what you are asking for
[07:36] <fabbione> anyway
[07:36] <fabbione> dinner is ready
[07:36] <crimsun> fabbione: I'm looking at critical ones, like "sis900 kernel oops fix"
[07:37] <fabbione> crimsun: go ahead and gimme a patch before tomorrow 12:00 UTC
[07:37] <fabbione> crimsun: send it via email or send me the mail with a url
[07:37] <fabbione> and i am off for the evening
[07:37] <crimsun> fabbione: great, have a good one.
[07:37] <fabbione> i am just too tired even to concentrate
[07:37] <T-Bone> fabbione: it's more a question of "not having reasons to continue"
[07:37] <fabbione> T-Bone: bendy :-)
[07:38] <T-Bone> have a nice evening anyway :)
[07:38] <fabbione> it's the same here for sparc...
[07:38] <fabbione> i have hard time to keep it up
[07:38] <fabbione> but i still do it becuase i love sparc
[07:38] <fabbione> it will make it for hoary+1 :-)
[07:38] <zul> crimsun: heh i forgot to send fabio that patch
[07:38] <T-Bone> trouble is i don't like ia64
[07:38] <fabbione> even if i will have to buy a cluster myseld
[07:38] <fabbione> cya
[07:40] <svenl> fabbione: the response to my problem was late_initcall, seems the various initcall are called at various moments ot the init.
[07:40] <zul> c ya fabbione 
[07:44] <mdz> fabbione: please review the new kernel changes with me prior to upload
[07:44] <mdz> fabbione: are you applying the release criteria to them?  currently we are only fixing high-impact bugs and simple, safe fixes
[09:21] <zul> heh down to 19 majors for the kernel
[09:57] <zul> later