[00:07] <jjohansen1> ghostcube: is that the windbond-840 module? or the winbond module in staging?
[00:10] <ghostcube> w83627ehf  kernel modul
[00:11] <ghostcube> W83667HG chipset on an asusu p5q-pro 
[00:11] <ghostcube> loads fine in rc5 but in rc6 is telling me device busy or not ready
[00:11] <jjohansen1> ghostcube: dkms?
[00:12] <ghostcube> no 
[00:13] <ghostcube> just wanted to mention it its not the biggest bug ever :) but i dont get why its not loading heh
[00:13] <jjohansen1> ghostcube: can you file a bug, and mark it as a regression
[00:14] <ghostcube> yeah i can do so where to file ? to l aunchpad ?
[00:15] <jjohansen1> ghostcube: yeah if you run ubuntu-bug -p linux
[00:15] <jjohansen1> it will gather all the information (logs, etc), and automate most of the bug filing process
[00:17] <ghostcube> ok so i will boot up into rc6 and do the command :) can this be tomorrow i dont know if i can file tonight
[00:17] <ghostcube> thx and see you 
[00:17] <jjohansen1> ghostcube: when ever is convenient for you
[00:18] <ghostcube> ok :)
[03:03] <praveen> hiii
[03:03] <praveen> can anyone tell me how do I find the offset from two given addresses. They both are void* and I can't subtract them
[03:25] <LeadingEdgeEntre> looking for 7 figure thinkers leadingedgeentrepreneurs.com
[05:28] <Fjodor> Hi guys. Does anyone know what happened to the gspca driver in the 2.6.31-rc series from http://kernel.ubuntu.com/~kernel-ppa ?
[07:05] <mcasadevall> apw, sparc patches resent, look for [patch] SPARC config patches
[08:24] <ameno> Fjodor: http://ubuntuforums.org/showthread.php?p=7794205
[08:25] <ameno> it has been confirmed, that the configs are not synced, but not if anyone is fixing it or when :/
[08:26] <ameno> i did not dare to whine too much though :)
[08:44] <apw> ameno, i am aware of he issue
[08:45] <apw> its not that the configs are not sync, but that the wrong series config is being used and mainline has changed the name of a couple of the main top level options
[08:45] <apw> which triggers whole subsystems to dissappear
[08:46] <ameno> ah ok, someone else here told me the "out of sync" story
[08:46] <ameno> so its not as trivial as i thought
[08:46] <ameno> can we help somehow?
[08:50] <smb> I guess we just need to find either a way to have a special mainline builds config for older kernels (not using kms by default) or switch to karmic configs instead. But that might prevent testing from Jaunty (and earlier) environments
[09:05] <apw> yeah the logical first step is to try a build using those karmic configs and see if that fixes the underlying issue
[09:05] <apw> as smb says that may trigger the kernels not being useful on jaunty without manual configuration
[09:06] <apw> in that case we would at minimum need hints on what to do when using them on the mainline builds wiki
[09:06] <NCommander> apw, bah, shoot me w.r.t. to the SPARC patches, something has gone freaking horribly wrong :-/
[09:06] <NCommander> apw, I don't get why it failed in the DC and not for me, I removed the modules it wanted ... *sigh*
[09:21] <apw> NCommander, its like that
[09:26] <NCommander> apw, ?
[10:30] <Q-FUNK> morning!
[11:06] <apw> NCommander, i was just saying life tends to go wrong
[11:06] <apw> Q-FUNK, morningg
[11:07] <laga> apw: don't mean to psuh anything, it'd just be nice to know for planning: will there be another kenrel upload with that AUFS config change before beta?
[11:10] <apw> the change is commited, so it'll be in the next kernel upload
[11:10] <apw> that'll likely be whenever the next -rc is out
[11:38] <Q-FUNK> apw: weren't we working on some old regression that affects SCx200 geodes, at some point?
[11:38] <apw> Q-FUNK, couldn't say any more, too long ago
[11:40] <Q-FUNK> apw: bug #241307
[11:40] <ubot3> Malone bug 241307 in linux "kernel oops during bootup in LTSP" [High,In progress] https://launchpad.net/bugs/241307
[11:41] <Q-FUNK> still unresolved
[11:45] <apw> indeed.  there are a number of bugs unresolved
[11:45] <apw> the issue there is that although we know the patch which triggered it, its not trivial to back out
[11:45] <apw> its the kind of thing where someone with the h/w would be in the best position to fix it
[11:46] <apw> to work out what in the new code is tripping the oops
[11:47] <apw> with that info we could then quirk the code for the machine i assume
[12:06] <Q-FUNK> apw: I have the hardware, but I lack the knowledge to hack on kernels.
[12:06] <apw> is that your bug?
[12:07] <Q-FUNK> yup
[12:52] <apw> Q-FUNK, what was the latest kernel you tried on this thing?
[12:52] <Q-FUNK> apw: good question.  some 2.6.28 IIRC
[12:56] <apw> migth be worth trying a karmic kernel, as there appear to be yet further a20 updates
[12:57] <apw> in the latest kernels, which seem to talk about issues on more embeded systems which don't have a keyboard controller
[12:57] <apw> and the bit you commented out included that controller setup
[12:59] <Q-FUNK> apw: noted. might be worth commenting that on the bug as well.  it'll make it easier for me to pass the info around.
[13:02] <apw> done
[13:10] <Q-FUNK> thanks!
[13:45] <apw> rtg is this valid:
[13:45] <apw> ifeq ($(disable_d_i),)
[13:45] <apw>         $(DEBIAN)/rules do-binary-udebs;
[13:45] <apw> endif
[13:46] <apw> as in .orig.gz + diff upload mode the rules is not going to executable
[13:46] <apw> normally we run things like perl <foo>
[13:46] <apw> so i'd expect us to be using make -F
[13:46] <rtg> apw, you could try $(MAKE) -f $(DEBIAN)/rules do-binary-udebs;
[13:47] <apw> right, that would seem appropriate replacement
[13:47] <smb> I try that immediately
[13:47] <apw> well with $(DEBIAN) too
[13:47] <apw> smb, take the one from main debian/rules file
[13:48] <apw> rtg in karmic we would be ok, as we have that file +x and we are still makeing -sa kernels
[13:48] <apw> but i think the issue will be there too
[13:48] <rtg> apw, how odd
[13:49] <apw> i have the feeling that buildd chmod +x debian/rules then run it
[13:49] <apw> so we have gotten away with it before hand
[13:50] <rtg> apw, how about debian/debian.env ? 
[13:50] <apw> that we generate during the build, so its got whatever perms it has when we make it
[13:51] <apw> so its unaffected by the -sa !-sa thing
[13:51] <rtg> apw, only if the 'clean' target is run
[13:51] <rtg> otherwise its part of the diff
[13:52] <apw> hrm yes you are right
[13:52] <apw> bum
[13:52] <apw> i wonder if it needs to be -x
[13:52] <rtg> apw, its likely the buildd runs 'clean' first, but I'd have to check for sure
[13:52] <smb> apw, I replaced that make call and am rerunning the build now
[13:52] <apw> oh yes they do
[13:53] <apw> rtg i'll confirm that by uploading netbook
[13:53] <smb> apw, btw, I run clean first as well
[13:53] <apw> yes but thats before the diff stage
[13:53] <apw> the -x on the master version is my fault
[13:53] <tseliot> amitk, mjg59: do you know why the touchpad resolution is reported as 1x1 in the kernel? Here's the relevant kernel commit which introduced the resolution: http://git.kernel.org/?p=linux/kernel/git/mingo/linux-2.6-x86.git;a=commitdiff;h=ec20a022aa24fc63d3ab59584cb1e5aa9a21d46c;hp=d7ed5d883c09c5474f842dcb148515dfaef2a567
[13:53] <apw> but it rasises an issue that an upload version won't work cause they get lost anyhow
[13:54] <apw> so it'll be like you are seeing
[13:54] <apw> even if its fixed in the git tree
[13:56] <smb> I will get to tun both variants, atm the patches change +x to debain/rules stub and -x on debian.master/rules. Probably debian/rules needs the +x
[13:57] <apw> i am pretty sure the the buildd process has to chmod +x debian/rules
[13:57] <apw> due to the orig+diff handling and there being on requiorement on language for debian/rules
[13:58] <smb> Sounds like a reasonable bet
[13:58] <apw> hense we have never noticed this internal connection before
[13:59] <apw> i only thought of it cause i am looking at the whines as i make the netbook upload to test
[13:59] <apw> dpkg-source: warning: executable mode 0775 of 'debian/debian.env' will not be represented in diff
[14:00] <smb> yeah, there has been much whining ever
[14:12] <lool> apw: dpkg-buildpackage will always chmod debian/rules; search for chmod in /usr/bin/dpkg-buildpackage
[14:12] <lool> That's the only executable file from the diff.gz
[14:12] <apw> lool, thanks, that meets my expectations
[14:26] <rtg> apw, whats that apt proxy/cacher package that you use?
[14:26] <apw> i use apt-cacher-ng, seems to be almost painless
[14:28] <smb> me too
[14:31] <apw> rtg, i was looking at the imx51 branch on karmic that you rebased
[14:31] <apw> it seemed you were deleting the whole of debian and debian.master then crteating debian.imx51
[14:31] <apw> that seems counter intuitive, is that just a hang over?
[14:32] <rtg> apw, no, it seemed the best way to avoid _any_ conflict in the debian directory
[14:32] <rtg> those commits will always be on top
[14:32] <apw> but by definition it creates a git conflict on the remove commit
[14:33] <apw> and i thought the point of the split was that the new stuff would always be in debian.<branch> and couldn't conflict
[14:33] <rtg> you know, I remember thinking about that yesterday, and now you've reminded me.
[14:34] <rtg> so if newfiles are created in debian.master, then we'll have issues with theremoval, right?
[14:34] <apw> or if they change too, i believe you will get a change/remove conflict
[14:34] <rtg> shit, guess I'd better fix that
[14:34] <apw> on the netbook branch i just left it in there
[14:34] <apw> and added the change to add DEBIAN=xxx
[14:35] <rtg> I use tab completion, so I try to get rid of duplicates
[14:35] <apw> rtg ahh i see, that is annoying for me too :/
[14:35] <rtg> apw, ok, thanks for spotting that
[14:35] <apw> its a work in progress all round
[14:36] <rtg> bjf, that means more mucking about in your dove branch
[14:36] <smb> You still might call it master.debian and master.whatever
[14:36] <smb> err
[14:36] <smb> dumb
[14:37] <smb> I meant master.debian and soemthing like arm.debian
[14:37] <rtg> smb, indeed, one could. 
[14:37] <bjf> rtg, i'm shocked!
[14:38] <rtg> I shocked that you're shocked!
[14:38] <smb> bjf, Hard to believe :)
[14:38] <bjf> smb, indeed :)
[14:38] <ogra> rtg, how is the imx51 renaming going, looks like i might have a livefs build server later today 
[14:39] <ogra> i'd like to build images with the properly named packages ;)
[14:39] <rtg> ogra, the kernel is renamed, but I have been ignoring the headers package naming issues for now.
[14:40] <rtg> ogra, I still need to do the -meta package as well
[14:40] <ogra> well, imx51 will have to replace the existing imx51 headers packages
[14:40] <ogra> else we end up with a massive mess
[14:40] <ogra> currently there exist header packages in the archive due to the fact that imx51 was built in karmic from the main package for quite a while
[14:41] <rtg> ogra, those packages should get reaped eventually
[14:41] <ogra> so we have to be cautious these get properly replaced ... and indeed however yu name them, dont forget upgrades ... 
[14:42] <ogra> it will likely be a hell of conflicts/replaces you need
[14:42] <ogra> for the kernel itself meta should take care as long a meta is named like in jaunty (which i think we agreed on)
[14:43] <ogra> so there noting special is needed
[14:44] <rtg> ogra, meta names are likely part of a LiveCD seed, aren't they?
[14:44] <ogra> not seed, but yes, they get used in the liveimage
[14:45] <ogra>         armel)  
[14:45] <ogra>                         case "$SUBARCH" in 
[14:45] <ogra>                                 imx51)
[14:45] <ogra>                                         LIST="$LIST linux-babbage"
[14:45] <ogra> thats the imx51 snipped from the livefs builde
[14:45] <ogra> r
[14:45] <ogra> *snippet
[14:45] <ogra> its just a matter of renaming it to linux-imx51, one line change 
[14:45] <rtg> ogra, didn't we switch from -babbage to -imx51 ?
[14:45] <ogra> the tricky part is debian-installer
[14:46] <rtg> ah, never mind
[14:46] <ogra> for A4 i tried linux-babbage :) 
[14:46] <ogra> but that ended up with a mess with the headers 
[14:58] <bjf> smb, where am I in your queue? (the FSL patch redo) (I'm not pushing, i'm just asking in case I get asked)
[14:58] <smb> bjf, Something around #2 or #3
[14:59] <bjf> smb, timewise, you think this week or next?
[14:59] <apw> ameno, the latest mainline daily was built with karmics config, perhaps you could see if that has the bits you expect in it
[14:59] <smb> bjf, I try to get the abstract stuff in place to use it with the arm branch too. Rather this
[15:00] <bjf> smb, ok
[15:01] <apw> smb, we gonna have as separate source upload for arm in jaunty like we do in karmic?
[15:01] <ameno> apw: yes, looks like drivers/media was compiled in \o/ will test it now...
[15:02] <smb> apw, Yes, it seems we need that too
[15:02] <apw> smb the patch stack in the abstracted-debian contains the changes to let the name come fromt he changelog
[15:02] <rtg> bjf, its actually also on my list of things todo, buts its lower down after Karmic and LTS backports stuff.
[15:02] <bjf> smb, is there anything I can help you with w.r.t. FSL
[15:02] <apw> but you want to get with rtg to make sure you have the latest naming jiggles right
[15:02] <smb> apw, Yeah, another reason to get that going first
[15:03] <smb> apw, Yep, my intention. I got an eye on his discussions too
[15:03] <apw> smb the netbook branch looks good with the new layout
[15:03] <bjf> rtg, what's on your todo?
[15:03] <rtg> bjf, Jaunty FSL
[15:03] <smb> bjf, Not that I can say now. I likely will run in issues when actually pulling your patches
[15:04] <smb> bjf, But I will get back to you then
[15:04] <bjf> rtg, oh :-)
[15:04] <apw> smb, just awaiting the PPA builds of it to confirm its a builder
[15:04] <bjf> smb, ack
[15:04] <apw> smb, thats with your little fixy applied for the udeb problem
[15:04] <smb> apw, Ok, mine here seems to run now for quite a while
[15:04] <smb> apw, So it looks somewhat good, but I wait for it to fionish
[15:05] <apw> smb, about 10 mins from done i'd say here.  and its buildng in a buildd env as a better test
[15:05] <smb> rtg, If you say Jaunty FSL, are we about to collide with things?
[15:05] <rtg> smb, yep, its gonna take some hackery and git futzing
[15:06] <rtg> I was gonna wait until netbook/master settled
[15:06] <smb> rtg, Actually it sounds as you are about to go for the same things as I wanted
[15:06] <apw> smb, yeah sounds like a 100% duplication rather than a clash
[15:06] <rtg> smb, if you've time, then feel free
[15:07] <rtg> I'm still working on Karmic dove, then -meta, then LTS, then ....
[15:07] <apw> smb, i can work with you based on my netbook experience here in theory
[15:07] <smb> rtg, Probably not the same. I get confused by the fact that the patchsets for imx51 are from fsl as well
[15:12] <_ruben> not sure if this is a -kernel thing, but any clues as to why a partition wouldnt show up under /dev/disk/by-label and by-uuid, it is present under by-id and by-path
[15:19] <apw> _ruben, it would depend on whether it has a uuid and label, they are often filesystem format specific
[15:20] <apw> it there needs to be space allocated to it in the fs format not all do
[15:21] <apw> those files are made by udev
[15:21] <Frank83> Greetings Guys. Yesterday my Update Manager downloaded a Kernel Update (uname -r = 2.6.28-15-generic) but now today the Update manager is showing me again that I should update the kernel to... 2.6.28-15? Is that normal or is this a fix of the previous kernel?
[15:22] <_ruben> apw: hmm .. it has both a label and uuid according to blkid, its an ext2 partition
[15:22] <apw> then its most likely an issue with udev
[15:25] <apw> hrm, can you paste the output of /sbin/blkid -o udev -p /dev/sdX1
[15:25] <apw> where X matches your disk
[15:26] <mjg59> Frank83: -15 is the ABI version, not the package version
[15:26] <mjg59> Frank83: Some updates may keep the same ABI
[15:26] <_ruben> Invalid output format udev. Choose from value, device, list, or full
[15:26] <apw> _ruben, what version of ubuntu are you on
[15:26] <smb> Frank83, Normal in the sense we had -15 accepted from proposed and today a now version from sercurity came, with the same abi number
[15:26] <Frank83> mjg59, Ah, Thanks. That I didn't know. I'll download it, then.
[15:27] <Frank83> mjg59, If I made a change to this kernel (Installed Compat-Wireless package to support my Wireless), will this update roll back those changes?
[15:28] <smb> mjg59, While you are around. Did you get the feedback about acpi_video and _DOD and _DOS? Though there seems to be much change upstream
[15:28] <_ruben> apw: fresh intrepid upgraded to jaunty (my pxe env doesnt do jaunty yet) .. but the problem was there in intrepid as well i think
[15:28] <mjg59> smb: Yes, there's a discussion in upstream bugzilla
[15:28] <smb> Frank83, No, it includes it
[15:28] <apw> Frank83, did you install compat-wireless by installing linux-backports-modules ?
[15:29] <Frank83> apw, Negative. I installed it from the source page of the project.
[15:29] <tseliot> mjg59: shall I take it as a no?
[15:29] <smb> Frank83, Oh, in that case it might replace it again
[15:30] <smb> Frank83, Have you tried backports-modules?
[15:30] <mjg59> tseliot: Sorry, I didn't highlight
[15:30] <Frank83> smb, Okay. I'll take that into account. No, I haven't tried those, didn't even know of their existence until you mentioned it. What do they do?
[15:30] <mjg59> tseliot: At a guess, the hardware doesn't support it?
[15:31] <smb> Frank83, That package contains the code from compat-wireless put into a separate dir, so it supersedes the normal kernel drivers
[15:31] <smb> Frank83, And is preserved on updates
[15:31] <tseliot> mjg59: is it possible that the kernel doesn't know about the resolution? (just asking)
[15:31] <apw> smb, my netbook build failed, seems the debug crapola isn't quite right
[15:32] <apw> working on it now
[15:32] <Frank83> smb, Wow, that will save me a lot of time! Thanks! Wonder why I didn't find / saw that in the project page
[15:33] <smb> apw, My build is still running, odd, as if the concurrency_level is wrong...
[15:34] <Frank83> smb, If this kernel update breaks up the compiled compat, then I will install the modules. Installing the modules over the compiled compat doesn't look like a good idea to me.
[15:35] <apw> rtg, this bit in the karmic stuff that handles the ddebs
[15:35] <smb> Frank83, You should find it it aptitude. or "sudo apt-get install linux-backports-modules-jaunty"
[15:35] <apw>         mv ../$(dbgpkg)_$(release)-$(revision)_$(arch).deb \
[15:35] <apw>                 ../$(dbgpkg)_$(release)-$(revision)_$(arch).ddeb
[15:35] <apw>         grep -v '^$(dbgpkg)_.*$$' $(DEBIAN)/files > $(DEBIAN)/files.new
[15:35] <apw>         mv $(DEBIAN)/files.new $(DEBIAN)/files
[15:35] <apw> rtg, that looks wrong to me... i think that bit should be debian/ throughout
[15:36] <apw> if you agree i'll fix it
[15:36] <Frank83> smb, I will search for those. Many thanks for the help. :-)
[15:36] <smb> Frank83, you're welcome :)
[15:37] <smb> mjg59, Do you happen to have the bugzilla number for that discussion?
[15:37] <mjg59> smb: Not offhand
[15:37] <rtg> apw, I think you're right. its the first time the debug packages have been built.
[15:38] <apw> yep ... will get this bugger built eventually, and fold the changes back to karmic
[15:38] <smb> mjg59, Ok, np. Just wanted to make sure you got the info that allowing _DOS or _DOD in both places as a valid video device got the backlight working for that one guy with the acer laptop
[15:38] <rtg> apw, test it locally by 'sudo mkdir /CurrretnBuilding ' in your chroot
[15:38] <rtg> but spell it right
[15:39] <apw> rtg heh, yeah
[15:39] <rtg> it makes  mammoth file foreach flavour, roughly 500MB
[15:39] <apw> yeeks
[15:39] <rtg> which is why I don't do it very often
[15:39] <mjg59> smb: http://bugzilla.kernel.org/show_bug.cgi?id=13577 I think
[15:40] <ubot3> bugzilla.kernel.org bug 13577 in Power-Video "Broken backlight control on Acer Aspire 8930G due to buggy DSDT/ACPI Video" [Normal,Resolved: code_fix] 
[15:45] <smb> mjg59, sounds similar. Though the reporter here had a 6920G, but Acer seems to be consistent in that respect
[15:45] <mjg59> Yes
[15:48] <smb> mjg59, In the case I had the problem were multiple definitions but only one had _DOD *and* _DOS defined as the code required. All others only had only one. So changing the if cases to allow one or the other in video and video_detect solved that
[15:54] <ameno> apw: the current vanilla image looks ok and the module i missed before works
[15:55] <ameno> the headers and source package seem broken though
[15:55] <ameno> 1,4kB is a bit small for a kernel source package ;)
[15:56] <ogra> its just good compression :P
[16:03] <mdz> ogasawara: bug 388923 needs to be unwound...looks like a lot of unrelated bugs have been marked as duplicates of that bug
[16:04] <ubot3> Malone bug 388923 in linux "package linux-image-2.6.28-13-generic 2.6.28-13.44 failed to install/upgrade: subprocess post-installation script returned error exit status 10" [High,Triaged] https://launchpad.net/bugs/388923
[16:04] <mdz> ogasawara: I've added code to apport to handle the nvidia-common case already
[16:04] <mdz> but there are some others mixed in there
[16:04] <ogasawara> mdz: ok thanks, I'll take a look
[16:05] <mdz> ogasawara: when I come across an apport-package bug, I generally try to extract the error message from DpkgTerminalLog.txt and put it into a comment, so it's easier to triage onward
[16:06] <mdz> ogasawara: eg, I just did bug 390905
[16:06] <ubot3> Malone bug 390905 in linux "package linux-image-2.6.28-13-generic 2.6.28-13.44 failed to install/upgrade: podproces post-installation script zwrócił kod błędu 1 (dup-of: 388923)" [Undecided,Invalid] https://launchpad.net/bugs/390905
[16:06] <ubot3> Malone bug 388923 in linux "package linux-image-2.6.28-13-generic 2.6.28-13.44 failed to install/upgrade: subprocess post-installation script returned error exit status 10" [High,Triaged] https://launchpad.net/bugs/388923
[16:09] <mdz> ogasawara: I'm using bug 386042 as the master bug for this one: /usr/share/debconf/confmodule: line 42: printf: write error: Broken pipe
[16:09] <ubot3> Malone bug 386042 in grub "package linux-image-2.6.28-13-generic 2.6.28-13.44 failed to install/upgrade: subprocess post-installation script returned error exit status 1" [Undecided,New] https://launchpad.net/bugs/386042
[16:12] <mdz> and 385771 for the update-grub merge failure
[16:15] <ogasawara> mdz: I'd been using bug 269539 for the update-grub merge failure
[16:15] <ubot3> ogasawara: Error: Could not parse data returned by Malone: The read operation timed out
[16:17] <mdz> ogasawara: oh, thanks. sorry about that
[16:25] <Q-FUNK> ogasawara: howdy! would you happen to have a kernel for me to test drive?
[16:25] <ogasawara> Q-FUNK: unfortunately not yet, fails to build and I haven't been able to dig through the log yet
[16:26] <Q-FUNK> ogasawara: oh?  just disabling that config option makes the build fail?  
[16:27] <ogasawara> Q-FUNK: I had to disable quite a few config options which turned that config option on
[16:27] <ogasawara> Q-FUNK: but I'm not sure why those would then result in a failed build
[16:27] <ogasawara> Q-FUNK: hence me needing to look at the build log
[16:28] <Q-FUNK> ogasawara: interesting.  something tells me that sending your logs to Al Viro might be a good idea, as it seems that his recent changes feature a number of interesting regressions, this panic on Geode being only a small fraction of the lot.
[16:29] <Q-FUNK> ogasawara: if nothing else, it could prevent some seriously broken code from being included in the 2.6.31 final release
[16:29] <Q-FUNK> keeping the LKML in the loop might also be appropriate, in this particular case, me thinks.
[16:30] <ogasawara> Q-FUNK: indeed
[16:30] <ogasawara> Q-FUNK: I was having some git issues yesterday so I just want to make sure the failed build wasn't a result of that
[16:44] <ret>  with kernels > 2.6.28-12 when I'm done installing them I continue to get `avc_has_perm_no_audit kernel panic not syncing'
[16:45] <ret> then the keyboard becomes nonresponsive.
[16:45] <ret> what ought i do
[16:46] <jjohansen> ret: do you have selinux enabled?
[16:46] <ret> jjohansen: I do
[16:46] <jjohansen> ret: my guess is you need updated policy
[16:47] <ret> jjohansen: how would I go about this?
[16:48] <jjohansen> ret: have you tried pulling in the latest policy, you could also try audit-to-allow
[16:49] <jjohansen> hrmm, or something like that its been a while since I looked at that
[16:49] <jjohansen> ret: ubuntu-hardened is a better channel to ask selinux questions in
[16:53] <mdz> bah, why is it kernel-team@lists instead of ubuntu-kernel@lists like everything else?
[16:55] <ret> jjohansen: eh, looking at the config shows that its been mucked with
[16:55] <ret> audit2allow --verbose returns nothing ;\
[16:56] <ret> looks like its fixed though.
[16:56] <ret> thanks
[17:04] <rtg> bjf, amitk: repushed Karmic fsl-imx51 with updated the debian abstraction according to apw.
[17:05] <rtg> hmm, garbled structure sentence
[17:06] <apw> s/according to/as suggested by'
[17:08] <ogra> so i can blame you for all the breakae now ? cool ;)
[17:09]  * ogra tickles apw 
[17:09]  * apw falls off his chair
[17:12] <mdz> ogasawara: do you have a master bug for the "missing /boot/grub" errors?
[17:12] <mdz> like bug 394729
[17:12] <ubot3> Malone bug 394729 in linux "package linux-image-2.6.28-13-generic 2.6.28-13.45 failed to install/upgrade: subprocess post-installation script returned error exit status 1 (dup-of: 388923)" [Undecided,New] https://launchpad.net/bugs/394729
[17:12] <ubot3> Malone bug 388923 in linux "package linux-image-2.6.28-13-generic 2.6.28-13.44 failed to install/upgrade: subprocess post-installation script returned error exit status 10" [High,Triaged] https://launchpad.net/bugs/388923
[17:14] <ogasawara> mdz: for that one I don't.  I've usually been going back and forth with bug reporters to find they've uninstalled grub somehow and mark them invalid
[17:15] <mdz> ogasawara: that's weird, uninstalling grub shouldn't remove /boot/grub I don't think
[17:15] <ogasawara> mdz: or I've seen the case where they don't have their /boot partition mounted and it fails with the same issue
[17:22] <ogasawara> mdz: have you started using a master bug?
[17:22] <mdz> ogasawara: no
[17:25] <mdz> ogasawara: are there any others which are common enough that we should add bugpatterns for them?
[17:25] <ogasawara> mdz: aside from what I have documented in that wiki, I haven't seen any
[17:26] <mdz> ogasawara: only a few of the ones on the wiki have bugpatterns that I see
[17:26] <mdz> ogasawara: thanks for adding 386042, I think that one warrants a bugpattern
[17:26] <ogasawara> mdz: I can do the bugpattern for that if you haven't already 
[17:27] <mdz> ogasawara: doing it now
[17:27] <ogasawara> mdz: awesome, thanks
[17:28] <mdz> ogasawara: done
[17:28] <amitk> rtg: ack
[17:29] <mdz> ogasawara: I'm not sure what to do with the --fsys-tarfile ones
[17:29] <mdz> those are definitely not kernel bugs, but it's hard to tell where they belong
[17:29] <mdz> I've been putting them on no package for now
[17:29] <mdz> but probably we should bugpattern them
[17:29] <mdz> getting more reports isn't helping
[17:30] <rtg> amitk, bjf: there are some more fsl packaging changes coming down the pipe. Steve L was not happy with libc-dev and headers package names.
[17:30] <ogasawara> mdz: what's the master bug for that one?
[17:30] <ogasawara> mdz: at least we can group them together first
[17:30] <mdz> ogasawara: I don't think there is one.  I think it means the disk filled up
[17:31] <mdz> ogasawara: we could set up a master bug, or we could just point people to a wiki page
[17:31] <mdz> a lot of these would have been redirected to grub or initramfs-tools if the user were running karmic
[17:31] <smb> rtg, I assume those will be in your preview branch at some point. Then I can pick those up when I do the dance for Jaunty
[17:32] <rtg> smb, I'll shove them into the core repo later today, as soon as I sort out the naming issues.
[17:32] <ogasawara> mdz: I'd maybe lean towards pointing to the wiki page
[17:32] <mdz> ogasawara: I've come across a few duplicates of bug 78478, which isn't on the wiki page yet and doesn't have a bugpattern
[17:32] <ubot3> Malone bug 78478 in grub2 "Package: linux-image-2.6.20-5-generic fails to install" [Undecided,Fix released] https://launchpad.net/bugs/78478
[17:33] <smb> rtg, Ok cool. I make sure I closely follow that lead
[17:33] <ogasawara> mdz: whoa, 2.6.20 :)  I actually hadn't seen that one yet.
[17:34] <ogasawara> mdz: I'll add it to the wiki and get the bugpattern
[17:34] <mdz> ogasawara: I believe that's the case where someone installs grub2 (pre-karmic)
[17:34] <mdz> and update-grub is /usr/sbin/update-grub
[17:34] <mdz> but /etc/kernel-img.conf still points to /sbin/update-grub
[17:37] <mdz> ogasawara: I think we need to write some code to automatically extract the error message from DpkgTerminalLog.txt before submitting the bug
[17:37] <ogasawara> mdz: that would be awesome to have it injected in the bug description
[17:41] <mdz> ogasawara: the fsys-tarfile error is a nasty one, because it can be legitimate
[17:41] <mdz> you get that error if a package is trying to overwrite a file in another package, e.g.
[17:41] <ogra> mdz, flash-kernel on armel uses the symlinks 
[17:41] <ogasawara> mdz: so we should have a master bug then
[17:42] <ogra> (just seeing your mail)
[17:42] <mdz> ogasawara: the actual error depends on what precedes that in the log
[17:42] <mdz> in this weird case we're seeing, there is no error message preceding it
[17:42] <mdz> just
[17:42] <mdz> Unpacking linux-image-2.6.28-13-generic (from .../linux-image-2.6.28-13-generic_2.6.28-13.44_i386.deb) ...
[17:42] <mdz> Done.
[17:42] <mdz> dpkg-deb: subprocess paste killed by signal (Broken pipe)
[17:42] <mdz> dpkg: error processing /var/cache/apt/archives/linux-image-2.6.28-13-generic_2.6.28-13.44_i386.deb (--unpack):
[17:42] <mdz>  subprocess dpkg-deb --fsys-tarfile returned error exit status 2
[17:43] <ogasawara> hrm, not exactly helpful
[17:45] <mdz> that "Done." indicates the preinst finished successfully (I don't know why the kernel preinst does that but it does)
[17:58] <ogasawara> mdz: I pushed a bugpattern for 78478 but used "Could not find postinst hook script [update-grub]." as the reg exp
[17:58] <ogasawara> mdz: but it seems it could also use "The provided postinst hook script [/sbin/update-grub] could not be run."
[17:59] <mdz> ogasawara: I've not had much luck making a bugpattern for the above...it's finicky about multiline patterns
[17:59] <mdz> ogasawara: did you test that pattern?
[18:00] <mdz> it contains square brackets, which are regex metacharacters
[18:00] <mdz> ./test-local <bug number> will tell you if it matches a particular bug
[18:00] <ogasawara> mdz: I'm going to uncommit it
[18:02] <Fjodor> ameno, apw: Thank you for explaining
[18:03] <Fjodor> apw: Is there any timeline for when it is resolved?
[18:04] <apw> Fjodor, for what to be resolved?
[18:05] <apw> Fjodor, too many threads going on
[18:05] <Fjodor> apw: Oh sorry, I should have mentioned :-$ The problem with 2.6.31-kernels from kernel-ppa not having a lot of media/video modules
[18:05] <apw> try the latest daily
[18:06] <apw> that i build with the karmic configs, ameno seemed to think it was better
[18:06] <Fjodor> apw: Ok, great! Thank you :-)
[18:06] <ameno> better yes, but did you read my two lines afterwards too? :)
[18:06] <ameno> apw: ^
[18:07] <apw> you'll ahve to repeat them
[18:07] <ameno> apw: the headers and source package seem broken though
[18:07] <ameno> apw: 1,4kB is a bit small for a kernel source package ;)
[18:07] <mdz> ogasawara: I've escalated bug 269539 with the foundations team because it has so many duplicates
[18:07] <ubot3> Malone bug 269539 in ucf "package linux-image-2.6.27-3-generic failed to install/upgrade: "Conflicts found! Please edit `/var/run/grub/menu.lst' and sort them out manually."" [Undecided,Confirmed] https://launchpad.net/bugs/269539
[18:08] <ogasawara> mdz: thanks
[18:08] <apw> ameno, yep aware of those, thats a systemic problem in karmic builds, am working on testing the fixes for that right now
[18:08] <mdz> ogasawara: bug 391519 is another of those weird "failed to run depmod" with no error messages. do you have a master for that?
[18:08] <ubot3> Malone bug 391519 in linux "package linux-image-2.6.28-13-generic 2.6.28-13.44 failed to install/upgrade: subprocess post-installation script returned error exit status 1 (dup-of: 388923)" [Undecided,Invalid] https://launchpad.net/bugs/391519
[18:08] <ubot3> Malone bug 388923 in linux "package linux-image-2.6.28-13-generic 2.6.28-13.44 failed to install/upgrade: subprocess post-installation script returned error exit status 10" [High,Triaged] https://launchpad.net/bugs/388923
[18:08] <mdz> we saw it during the sprint
[18:08] <mdz> cjwatson was looking at it
[18:09] <mdz> bug 330834 is another
[18:09] <ubot3> Malone bug 330834 in linux "Depmod segfaults when configuring linux-image-2.6.28-8-generic" [Undecided,New] https://launchpad.net/bugs/330834
[18:09] <Fjodor> apw: So hopefully the next daily could have those packages fixed? I don't care about the source, but I need the headers...
[18:09] <apw> Fjodor, hopefully yes
[18:09] <mdz> ogasawara: 407420 is the one that we found during the sprint; if you don't already have a master, I suggest we use that one
[18:10] <Fjodor> apw: Great :-)
[18:10] <ogasawara> mdz: nope I don't have a master bug for that, I'll add 407420 to the wiki
[18:11] <mdz> ogasawara: bzr commit -m 'Add bugpattern for bug 407420 (failed to run depmod)'
[18:11] <ubot3> Malone bug 407420 in linux ""Failed to run depmod", no clear reason why" [Undecided,Incomplete] https://launchpad.net/bugs/407420
[18:19] <mdz> ogasawara: we need a tool which scans open bugs for those which match apport bugpatterns and marks the duplicates automatically
[18:28] <apw> rtg, we have a bug in our abstracted stuff, which is stopping the headers and source being made correctly
[18:28] <apw> i have a fix in testing, which i'll push shortly to master
[18:28] <apw> but you will want to apply the same fix to your arm copies of debian.master
[18:28] <apw> as they are disconnected now right?
[18:29] <rtg> apw, fsl-imx51 is descended from master, but mvl-dove is not yet
[18:30] <apw> it has a complete copy of debian.master as debian.imx51 which will need fixing too
[18:30] <apw> will get the patches up shortly
[18:30] <dhillon-v10> hi guys
[18:30] <apw> hi
[18:31] <dhillon-v10> apw: how are you
[18:31] <apw> not bad, holidays soon :)
[18:32] <dhillon-v10> apw: so what are you working on now
[18:35] <apw> hrm
[18:40] <rtg> apw, guess he had no patience
[18:40] <apw> or no network :)
[18:41] <rtg> apw, so, what are the issues in Karmic debian.master ?
[18:42] <apw> there appear to be 3 issues
[18:42] <apw> 1) debian/files is always debian/files (the ddeb issue)
[18:42] <apw> 2) we cannot call $DEBIAN/rules for udebs
[18:42] <apw> 3) packages are built in debian/name, we broke the indep targets here
[18:42] <apw> i am just testing the indep one on karmic then will push them so you can see
[18:43] <apw> the last one is way my headers are empty on my mainline build
[18:43] <rtg> apw, the other thing we need to figure out is how to build libc-dev for armel from the distro kernel package
[18:44] <apw> why does it have to come from the distro one?
[18:44] <apw> hrm is that cause we need just one common one for armel?
[18:44] <rtg> apw, there can only be one libc-dev, and the distro kernel package is what userspace is built against
[18:47] <apw> rtg that looks like it may be a simple edit
[18:47] <apw> if you check out debian.master/control.stub.in
[18:47] <apw> its directly in there with a list of architectures
[18:48] <rtg> apw, perhaps, I was just looking at it. the other thing we shold change while we're at it is SRCPKGNAME-libc-dev, SRCPKGNAME-headers-PKGVER-ABINUM.
[18:48] <apw> yeah if there are names which must not change they should not have that in them
[18:49] <rtg> apw, correct
[18:49] <apw> did we decide what the _all name is for the headers on the brnaches?
[18:49] <rtg> apw, we;ll have to distinguish linux-headers ackage names through the ABI. for example, I've started fsl-imx51 at 100.
[18:50] <apw> oh nng.  so non-overlapping ABI for those branches?
[18:50] <rtg> yep
[18:50] <rtg> too many dependencies on the package name layout
[18:50] <apw> fair enough
[18:52] <apw> i hope 100 abi bumps is sufficient :)
[18:53] <rtg> you and me both!
[18:53] <apw> so 200 for dove, and onwards to victory
[18:53] <rtg> thats my plan
[19:08] <apw> rtg, ok those changes seem ok so i've pushed them to karmic master
[19:12] <rtg> apw, what does printdebian do for us?
[19:14] <rtg> perhaps stuff in debian*/scripts/misc ?
[19:20] <apw> rtg printdebian allows the build tools to find out where the debian directory is, ie. where the changelog is
[19:20] <rtg> apw, is that a standard target?
[19:20] <apw> did i push that, hrm, that was meant to go out as a patch on our list
[19:20] <rtg> s'ok, just wondered
[19:21] <apw> nope its meant to be something we are going to need for the buildscript.git stuff
[19:21] <apw> to find out which of the multiple debian*/changelogs are the real one in this tree
[19:21] <apw> so its can annotate it before build etc.
[19:22] <apw> i can pull that one out and email it, that was my intent
[19:22] <rtg> apw, no, go ahead and leave it
[19:22] <apw> we are going to have 'fun' every time we rebase master ... 
[21:59] <devinheitmueller> Hello all.  I popped in three weeks ago to see about getting the xc5000 firmware into Karmic (launchpad 403642), and was told it should happen in the next week.  Just wanted to see if I can poke somebody for a status on that (especially since a new version of linux-firmware was spun a couple of days ago and it wasn't in there)
[22:00] <devinheitmueller> (according to my notes, on 7/30, pgranger said it would be ready "next week")
[22:24] <bjf-afk> devinheitmueller, try posting an email to the ubuntu kerne-team mailing list
[22:24] <devinheitmueller> ok, worth a try.
[22:24] <devinheitmueller> Certainly the experience has me wondering if anybody is actually reading the launchpad bugs.
[22:25] <bjf-afk> devinheitmueller, we do our best, and we do get to as many as we can
[22:25] <devinheitmueller> (since, like most bugs, it appears to be in the exact same state it was when it was opened)
[22:25] <devinheitmueller> Yeah, I know you guys are understaffed.
[22:25] <bjf-afk> bug 403642
[22:25] <ubot3> Malone bug 403642 in linux-firmware "Include xc5000 firmware in Karmic (now properly licensed)" [Undecided,New] https://launchpad.net/bugs/403642