[06:18] <fabbione> morning
[11:59] <jes-o-mat> kylem: your changes made it into git - thnx
[12:02] <jes-o-mat> now I'm just wondering how to compile your tree
[12:18] <jes-o-mat> a lot of files are missing in the debian/ directory
[12:22] <jes-o-mat> BenC: maybe you know some points that will get me further?
[12:50] <\sh> which script generates the initrd for the linux-image package in postinstall? I don't see it in debian/* of linux-source-*, could be that I'm blind ;)
[12:54] <Mithrandir> kernel-package
[12:58] <\sh> yes...I see it now ;) make-kpkg generates postinst
[01:51] <cjwatson> BenC: https://launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/76341 is quite a nasty issue. Do you think you/kyle could have a look at it with the lkml reference I gave?
[02:17] <BenC> cjwatson: sure
[02:17] <BenC> cjwatson: Ah, I talked to Keybuk about this, and I'm not sure we've concluded whether it was a udev or a kernel bug
[02:17] <BenC> the kernel code hasn't changed
[02:18] <cjwatson> the lkml thread seemed to reckon that it was a kernel bug due to MODALIAS=i82365
[02:19] <cjwatson> but I couldn't find anything outside that thread
[02:19] <cjwatson> I tried to work around it in udev rules, but haven't succeeded yet
[02:38] <jes-o-mat> BenC: no idea regarding my problem?
[02:40] <BenC> jes-o-mat: The URL in the topic has a link to compiling custom kernels
[02:41] <zul> hey
[02:41] <jes-o-mat> BenC: yes and I was using the commands as written
[02:42] <BenC> jes-o-mat: Without some context, I can't give you any more info
[02:42] <jes-o-mat> but there are a lot files missing in kylem's git tree
[02:42] <BenC> Like what files
[02:43] <jes-o-mat> basic things like copyright e.g.
[02:43] <BenC> what git tree are you using?
[02:44] <jes-o-mat> I have taken some of them from the linux-source package, but now I got to a point where the build scripts needs some debian/d-i/shared/firmware/* files which are not present
[02:44] <jes-o-mat> ubuntu-dapper-updates.git
[02:44] <jes-o-mat> from kyle
[02:44] <BenC> on kernel.org?
[02:45] <jes-o-mat> yes
[02:45] <jes-o-mat> http://www.kernel.org/git/linux/kernel/git/kyle/ubuntu-dapper-updates.git
[02:45] <jes-o-mat> I fetched it as supposed via rsync
[02:46] <BenC> I get 404 on that url
[02:47] <jes-o-mat> Generating......
[02:48] <jes-o-mat> http://www.kernel.org/git/?p=linux/kernel/git/kyle/ubuntu-dapper-updates.git;a=summary
[02:48] <jes-o-mat> sorry
[02:49] <jes-o-mat> mixed up http and rsync url's a bit
[02:49] <BenC> http://www.kernel.org/git/?p=linux/kernel/git/kyle/ubuntu-dapper-updates.git;a=tree;f=debian;h=1690c1d0bf1d38ebd708df29599ae4195871d490;hb=HEAD
[02:49] <BenC> shows the copyright file, and others
[02:49] <BenC> must be your lock tree
[02:50] <BenC> s/lock/local/
[02:51] <jes-o-mat> I used the following to fetch the tree:  git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/kyle/ubuntu-dapper-updates.git ubuntu-dapper-updates
[02:55] <BenC> All I know is, the tree on kernel.org is fine...not sure why yours is having problems
[02:55] <BenC> git-checkout -f
[02:55] <BenC> see if that helps
[02:56] <jes-o-mat> ini get a lot of "unable to read sha1 file of ..."
[02:56] <jes-o-mat> maybe the argument "ubuntu-dapper-updates
[02:56] <jes-o-mat> " is false
[02:56] <jes-o-mat> I just guessed it
[02:57] <jes-o-mat> cuase the wiki is only talking about linux-2.6
[02:57] <jes-o-mat> oh
[02:57] <jes-o-mat> that's for the local directory :)
[02:59] <BenC> jes-o-mat: my guess is that git isn't following the alternative objects to my tree
[02:59] <BenC> jes-o-mat: Best bet is to clone my tree, then pull from kyle's
[02:59] <kylem> it probably doesn't if you use rsync.
[02:59] <kylem> use git://
[03:00] <BenC> jes-o-mat: Telling me about the missing sha1 messages would have been helpful before :)
[03:03] <jes-o-mat> BenC, kylem: I'll try using git://
[03:03] <jes-o-mat> BenC: the list was *very* long :)
[03:04] <kylem> jes-o-mat, my repository shares objects with ben's so that it doesn't take a long time to mirror. the downside is you need to use a git-aware protocol for fetching it.
[03:04] <jes-o-mat> kylem: is the host still rsync.kernel.org?
[03:05] <jes-o-mat> or is there some git.k.o host?
[03:05] <kylem> it's the same pair of machines either way
[03:05] <kylem> a CNAME by any other name would resolve as sweet.
[03:06] <tepsipakki> kylem: I see the upload to dapper-proposed as rejected?
[03:06] <jes-o-mat> sweet CNAME ... I need to remember that :)
[03:06] <kylem> tepsipakki, one of them was rejected, there were two.
[03:08] <tepsipakki> kylem: should it be built by now and available on a.u.c?
[03:09] <kylem> tepsipakki, i'd have thought so, i'm new to this whole game though so i'm not really sure what the process is once i upoad.
[03:10] <tepsipakki> kylem: I've searched the dapper queues and I can see only the rejected one :)
[03:10] <kylem> possibly one of the archive folks needs to be cattle proded.
[03:11] <tepsipakki> heh
[03:15] <jes-o-mat> *grml* git:// is blocked by firewall
[03:16] <Mithrandir> jes-o-mat: ssh -D 1234 wherever, then use tsocks on localhost:1234
[03:17] <Mithrandir> ssh -D is like the best invention since the internet.
[03:19] <jes-o-mat> Mithrandir: great! didn't knew the -D flag - I always had used -L or -R
[03:19] <kylem> Mithrandir, hah.
[03:19] <zul> i thought slice bread was a pretty good invention myself
[03:21] <Mithrandir> sliced bread is a _horrible_ invention.
[03:24] <zul> i disagree
[03:27] <kylem> i hate sliced bread.
[03:28] <kylem> i much prefer carving out a quadrant of a nice big loaf of pumpernickle
[03:30] <thom> i am lazy. all dutch bread is horrific, so it makes no odds to me
[03:30] <jes-o-mat> hrhr
[03:30] <Mithrandir> thom: make it yourself and you can have it however you want.
[03:31] <thom> Mithrandir: see my leading sentence
[03:31] <Mithrandir> thom: bread making machine.
[03:31] <Mithrandir> pour ingredients, set timer, wake up to a fresh loaf of bread.
[03:31] <thom> had one, hardly ever used it
[03:33] <zul> heh if i cook something there is a pretty good chance that it will implode or explode
[04:49] <jes-o-mat> kylem: seem that the changes does not solve #37452 :/
[04:50] <jes-o-mat> everything compiled well but after creating the hw-raid the kernel cannot access sda
[04:52] <kylem> well, someone who actually has the hw will have to hunt down the changeset which fixes it. i can't test it.
[05:02] <cjwatson> BenC: did /proc/cpuinfo change on i386/amd64 recently (.20) for multiprocessor machines? I see why bug 79109 is happening, but apparently it didn't happen with Herd 1 and the relevant code in base-installer hasn't changed at all
[05:02] <BenC> bug #79109
[05:03] <BenC> cjwatson: It's possible, what portion is it using?
[05:05] <BenC> cjwatson: diff'ing the cpuinfo from my 2.6.20 coreduo and 2.6.17 core2duo doesn't show anything changing other than values of the cpu itself
[05:06] <BenC> I can try a boot into 2.6.20 for the core2duo and see about same cpu changes
[05:14] <BenC> cjwatson: The only thing I see different is that in 2.6.20 it recognizes the difference between physical cpu's and cores
[05:15] <BenC> so on .17 it would show physical_id={0,1} and core_id=0 for the two, and on .20 it shows physical_id=0 and core_id={0,1}
[05:15] <cjwatson> BenC: it's grepping for 'cpu family' lines, and forgot to do head -n1
[05:16] <cjwatson> BenC: if older kernels had only one cpu family line, but current ones have two (which current ones do), then that would explain it
[05:17] <BenC> I show two lines in both
[05:17] <BenC> so that didn't change
[05:17] <BenC> does it use siblings?
[05:18] <BenC> or "cpu cores"?
[05:18] <cjwatson>         FAMILY=`grep '^cpu family' "$CPUINFO" | cut -d: -f2`
[05:18] <cjwatson>         case "$VENDOR" in
[05:18] <cjwatson>                 " AuthenticAMD"*)
[05:18] <cjwatson>                         case "$FAMILY" in
[05:18] <cjwatson>                                 " 6"|" 15")     echo k7 ;;
[05:18] <cjwatson> just that sort of thing
[05:19] <cjwatson> dunno, maybe it was always broken - I was just curious
[05:19] <cjwatson> oh, unless vendor_id changed similarly - it greps for that too
[05:20] <cjwatson> nothing else, not siblings or cpu cores
[05:20] <BenC> still shows GenuineIntel
[05:21] <BenC> On i386 and amd64 there shouldn't any of this anyway
[05:21] <BenC> it should always install -generic
[05:22] <cjwatson> -generic is built for 586, so it's needed for 486 systems
[05:22] <cjwatson> most of the code is inherited, but still
[05:23] <BenC> true, -386 is the side case
[05:23] <cjwatson> on amd64, in practice it makes no difference - it installs -generic regardless
[05:23] <cjwatson> it's not vendor_id contents I'm thinking about, but whether it appears once or twice
[05:23] <jes-o-mat> kylem: I just digged into the source and the suggested patchset from Cedric Schieli did not made it into your git
[05:24] <BenC> it appears twice on .17 and .20
[05:24] <cjwatson> anyhow, I have a fix now
[05:24] <cjwatson> ok, thanks
[05:24] <BenC> cjwatson: Do you want my cpuinfo's for reference?
[05:25] <BenC> cjwatson: emailed, can't hurt to have it
[05:27] <cjwatson> sure, thanks
[05:38] <cjwatson> BenC: ah, fjp pointed me in the direction of the answer - between Herd 1 and 2, we switched the installer from 386 to generic, and 386 doesn't have SMP alt so the second core didn't show up in cpuinfo
[05:42] <kylem> jes-o-mat, which kernel image do you need?
[05:43] <jes-o-mat> kylem: -server
[05:43] <kylem> amd64 or i386?
[05:44] <jes-o-mat> i386 (for now)
[05:45] <kylem> alright
[05:53] <BenC> cjwatson: The d-i installer, or the livecd installer?
[05:53] <BenC> I thought the installer for the alt CD was going to remain 386
[05:54] <cjwatson> for edgy, it did, but I elected to change that for feisty and just retain the netboot install as 386
[05:54] <cjwatson> I think I mentioned that possibility in mail to you pre-edgy
[05:55] <cjwatson> it simplifies the desktop seed rather a lot, because we can just slam linux-headers-generic in there and not worry about which installer is in use
[05:55] <BenC> so the bug was always there, it just never showed up because the -386 installer didn't see the extra cpu's?
[05:55] <cjwatson> https://lists.ubuntu.com/archives/ubuntu-devel/2006-December/023036.html
[05:55] <cjwatson> right
[05:55] <cjwatson> I should probably have CCed you on that mail about the installer change
[05:57] <BenC> well, the cpu checking is still pretty moot, because if they boot the live or alt cd's, they don't need -386 anyway
[05:57] <BenC> but it certainly can't hurt to have it, since the end result is the same :)
[05:58] <cjwatson> that's true, but the same code is used for the netboot installer where it might conceivably matter
[05:59] <cjwatson> I realise it's all a tiny corner case - I just prefer fixing mostly-working code over removing it :)
[10:30] <Red_Herring|ugh> yo
[10:30] <Red_Herring|ugh> anyone around?
[10:32] <Red_Herring|ugh> guess not.
[10:32] <Red_Herring|ugh> anyways ill ramble on about my problems
[10:32] <Red_Herring|ugh> so i got an edgy amd64 kubuntu install
[10:32] <Red_Herring|ugh> and one day
[10:33] <Red_Herring|ugh> i boot up
[10:33] <Red_Herring|ugh> and get a kernel panic
[10:33] <Red_Herring|ugh> the "Aiee, killing interrupt handler!" kind
[10:33] <Red_Herring|ugh> so i boot from livecd
[10:33] <Red_Herring|ugh> chroot in
[10:33] <Red_Herring|ugh> recompile the kernel
[10:33] <Red_Herring|ugh> and boot again
[10:34] <Red_Herring|ugh> and it complains about missing modules
[10:34] <Red_Herring|ugh> so
[10:34] <Red_Herring|ugh> im runnin a livecd now
[10:34] <Red_Herring|ugh> chrooted into the thing
[10:35] <Red_Herring|ugh> and am wondering
[10:35] <Red_Herring|ugh> whats the best solution
[10:35] <Red_Herring|ugh> i'd really hate to install
[10:35] <ivoks> make modules_install ?
[10:35] <Red_Herring|ugh> ?
[10:35] <ivoks> but this is development channel, not support
[10:36] <Red_Herring|ugh> ok
[10:37] <Red_Herring|ugh> but can you at least tell me how to diagnose it?
[10:44] <Red_Herring|ugh> ... thanks