[00:39] <greearb> I have what may be a squashfs bug in ubuntu 8.0.4:  I am building a custom image, and when I view certain files inside of the chroot, everything looks fine.
[00:40] <greearb> But, when I make a squashfs and iso image, and then mount that with -o loop, certain files in squashfs image give IO errors when I try to read them.
[00:40] <greearb> I am not sure this is anything other than bad luck, but the files are: /var/lib/scrollkeeper/TOC/16544 - 1651
[00:41] <greearb> I have not found any others, but it's possible they exist.
[00:41] <greearb> I'm open to suggestions if anyone has any ideas on how to further debug this
[02:24] <newz2000> ok, confirmed. `/etc/init.d/kvm stop` did allow virtualbox to run
[02:24] <newz2000> thanks for the help
[07:56] <elmargol> Someone knows how I get the virtualbox 1.6 module running on the current ubuntu version
[13:39] <rtg__> Ng: http://ppa.launchpad.net/timg-tpi/ubuntu has the e1000 eeprom patch.
[13:39] <Ng> rtg__: thanks
[15:04] <emgent> heya
[16:21] <Riddell> linux-image-2.6.25-1-386, main or universe?
[17:04] <BenC> amitk, rtg__, cking, pgraner: ping
[17:05] <cking> Hi
[17:05] <BenC> Riddell: universe
[17:06] <BenC> Riddell: all other packages from linux-ports are main
[17:06] <rtg__> BenC: pong
[17:07] <pgraner> BenC: pong
[17:08] <amitk> BenC: pong
[17:08] <BenC> Ok, the ubuntu-kernel-team meeting is now in session
[17:09] <BenC> No real agenda is in order, but just to update on the status for intrepid...
[17:10] <BenC> linux-ports => New package, uploaded and built already. This package contains all the architectures/flavours that are community supported
[17:10] <BenC> This basically means != i386/amd64
[17:11] <BenC> With the exception of the -386 flavour, which is mostly kept for things LTSP
[17:11] <BenC> *like LTSP
[17:11] <BenC> It's 2.6.25 based, and will probably remain that way for intrepid
[17:12] <BenC> The community port teams are expected to maintain proper configs and patches in that package
[17:12] <amitk> BenC: I recall Oliver (ogra) mentioning that LTSP used -generic now. rtg__ do you remember?
[17:12] <rtg__> amitk: yep - all default installs use generic.
[17:13] <BenC> amitk: some of the older hardware uses -386, but it's an option, not the default
[17:14] <BenC> There are some LTSP boxes that fit in the palm of your hand, which use the -386 kernel (at $100 a box, they are economical)
[17:14] <amitk> ok
[17:14] <BenC> atleast I remember being told that, hehe
[17:15] <BenC> ﻿Next, we have some UDS topics that will affect the kernel maint infrastructure...
[17:15] <rtg__> ogra said that there are no modern LTSP devices that _require_ -386.
[17:15] <BenC> linux-ubuntu-modules is moving to the main linux source tree (in our git, not upstream)
[17:16] <BenC> This will be done by placing the third party modules in an ubuntu/ subdirectory, and should alleviate problems we've had with separate ABI/headers for third party modules
[17:16] <BenC> (e.g. alsa)
[17:16] <BenC> This is the same way we did things prior to feisty
[17:17] <BenC> linux-backports-modules will remain the same
[17:18] <BenC> linux-restricted-modules will get a huge face lift. First, fglrx and nvidia will be moved to DKMS packaging, to remove the need to update them on ABI bumps (recompiles of the kernel module will happen on the local machine)
[17:19] <BenC> Next, we'll ditch a lot of old drivers that are unused, and we'll perform the usual driver refresh...linux-restricted-modules will then be converted to use the same build infrastructure as lbm/lum/linux
[17:19] <rtg__> You can read the UDS discussion results at https://wiki.ubuntu.com/KernelTeam/UDS/May2008. I should have published this awhile ago.
[17:20] <BenC> lbm and lrm will only support the main architectures (x86/x86_64)...port maintainers should create their own infrastructure for third-part/restricted modules
[17:21] <BenC> Considering that most hardware related to the ports are supported in the kernel, I don't see this being a problem
[17:21] <BenC> The only exception being aufs, which ports will need if they want a livecd for their architecture
[17:22] <BenC> The other major change, is that what we used to have as binary-custom in-tree builds (xen/rt) will be moved to external packages, which will build-dep and patch linux-source-2.6.xx to build their respective binaries
[17:22] <BenC> The same will happen to -virtual
[17:23] <BenC> rtg__: Thanks, that should fill in some gaps for questions
[17:23] <BenC> So, that leaves i386=>generic,server and amd64=>generic,server as the only things left in the main kernel tree
[17:24] <BenC> We are hoping that narrowing our scope will improve our focus and quality on supported architectures
[17:24] <BenC> Any questions?
[17:25] <BenC> Anything anyone wants to add to the discussion?
[17:25] <BenC> Meeting adjourned then :)
[17:25] <maks_> i'd have 2 points
[17:26] <BenC> maks_: Ok, just in time...whatcha got?
[17:27] <maks_> 1) the SAUCE patches, i guess those are on the way to upstream?
[17:27] <rtg__> maks_: most of them.
[17:27] <BenC> maks_: Actually, some are pushed upstream, and others will never be accepted
[17:27] <BenC> and some are in progress...SAUCE will be a never ending endeavor
[17:28] <maks_> 2) initramfs-tools sync
[17:28] <maks_> as sauce is rebased should be easy to submit the blacklist ones
[17:28] <BenC> maks_: the initramfs-tools sync should be done as part of our normal merge-o-matic from Debian
[17:29] <BenC> maks_: but I'll be sure to give it personal attention :)
[17:29] <BenC> maks_: Is there anything we have locally in ubuntu that isn't merged in Debian?
[17:29] <maks_> yep
[17:29] <BenC> Do you know what they are off-hand?
[17:29] <maks_> 1sec
[17:30] <maks_> firmware detection differs
[17:30] <maks_> mountroot fail hooks
[17:30] <maks_> loop support
[17:31] <BenC> maks_: meaning we have loop support and debian doesn't?
[17:31] <maks_> old ps3 support
[17:31] <maks_> the old ps3 stuff that didn't go into linux-2.6
[17:32] <maks_> BenC: yes
[17:32] <BenC> right, but we released ps3 support, so we need to maintain that backwards compatibility
[17:32] <maks_> sure but not in hardy irc
[17:32] <BenC> we can probably ditch it in intrepid
[17:33] <maks_> trigger support landed
[17:33] <BenC> gutsy was first release with old driver names, hardy maintained for upgrades, and intrepid can ditch them
[17:34] <maks_> MODULES=dep got /sys walking logic in debina
[17:34] <maks_> plus bunch of nfs root fixes
[17:34] <BenC> nice
[17:34] <BenC> maks_: Ok, I'll personally review the initramfs-tools sync
[17:35] <maks_> ok cool
[17:35] <maks_> Luke was helping out for merging bits and pieces
[17:35] <maks_> but seemed silent lately
[17:35] <maks_> once sync happen i'll see what i can do on my side to reduce too
[17:36] <BenC> Sure thing....ok, so _now_ meeting is adjourned
[17:36] <maks_> :)
[17:36] <maks_> cya
[17:36] <BenC> Thanks everyone
[17:36] <BenC> maks_: thanks
[18:03] <infinity> rtg__, BenC : I just read scrollback, and when Ogra said "we use -generic by default and I get no complaints", he and I later discussed that further and, yes, the 386 kernel flavor is still required, even if not the default.
[18:04] <infinity> rtg__: I meant to catch up with you that same day in Prague (when we also did the 486/586 toolchain discussion), but didn't get around to it. :)
[18:04] <rtg__> infinity: there are LTSP devices that are not i586 or better?
[18:05] <infinity> rtg__: There's no such thing as an "LTSP device" but, yes, plenty of people are running LTSP on 486-class hardware still.
[18:06] <rtg__> infinity: do you think the community port for -386 is sufficient for those users?
[18:06] <infinity> rtg__: We have two distinct (and very different) target markets for LTSP installations.  The corporate thin-client users are all on reasonably new and speedy hardware (and they'll also be keen on us finally having ARM support), and then the "poor schools and communities recylcing hardware as terminals" have a lot of older kit lying around.
[18:07] <infinity> rtg__: If -386 moves to linux-ports, that should be fine.  It just shouldn't go away entirely.
[18:07] <rtg__> infinity: ok, then I think we're fine. We did not plan to remove -386, only move it.
[18:08] <infinity> rtg__: Kay.  In Prague, it sounded more like outright removal.  Not like adding it back would be hard, but... Best not to remove it in the first place. :)
[18:09] <rtg__> infinity: to be honest, it was my original intention to remove it. I quickly changed my mind :)
[18:23] <esox> Hi, when one compiles a vanilla kernel do one need to apply patches ? I eared about ubuntu patches
[18:24] <rtg__> esox: start here: https://wiki.ubuntu.com/KernelMaintenance
[18:26] <esox> rtg__: is this how to compile vanilla kernels ? because I want to build a 2.6.25-rt kernel... I did it but no wifi, no alsa, and gdm start issues
[18:27] <esox> the systems starts but with those issues
[18:27] <rtg__> esox: that page describes how to build the Ubuntu kernel. For other stuff you're on your own.
[18:28] <esox> rtg__: ok... so you dont know if there are ubuntu patches available somwhere ?
[18:29] <rtg__> esox: there are no patches for 2.6.25, but there are a number in the Ubuntu kernel git repository for 2.6.24.
[18:29] <esox> rtg__: cool, thanks
[18:29] <esox> I go for that
[18:29] <maks_> esox: start from a working .config
[18:30] <esox> maks_: you mean re-build a 2.6.22-rt as a beginning ?
[18:30] <maks_> no
[18:31] <maks_> you probably goffed on .config settings thus go from a working /boot/config-2.6.24-whatever
[18:32] <esox> maks_: I'm on gutsy ubuntustudio, so it's 2.6.22 and that version
[18:33] <maks_> a lot happened since, anyway good luck
[18:33] <esox> maks_: well i have too many issues with 8.04...
[20:00] <rtg__> BenC: did you want that mmc fix in Hardy before I upload?
[21:23] <Bari_> anyone have any idea why a 2.6.22.2 kernel may have problems initializing and assigning irq's to VIA USB controllers? irq's get assigned and the get disabled since "nobody cared"   cat /proc/interrupts show  10:     100000    XT-PIC-XT        uhci_hcd:usb3, uhci_hcd:usb4   11:     100000    XT-PIC-XT        uhci_hcd:usb1, uhci_hcd:usb2   seconds after booting,  serial debug output: http://pastebin.com/m3320b15f
[22:15] <BenC> rtg__: does it apply to hardy? If so, yes
[22:15] <rtg__> BenC: already done and pushed.