irclog regarding sarge release with 2.6.8 on #debian-devel
short summary:
* ~10mb changes from 2.6.7 to 2.6.8
* to about 70% that's bugfixes
* cd writing is broken both in 2.6.7 and 2.6.8 in different ways
* told since almost a month that the debian kernel team really wanted
to have 2.6.8 for sarge.
* as do the folks at redhat and suse that are at 2..8 aswell for FC3 and
Suse9.1
* actually there was an acpi merge
* given that 263753 looks rather relevant to the installer, it seems
we're going to want an update to the kernel in d-i regardless; and
2.6.8 certainly seems to be closer to being ready than a fixed 2.6.7.
-- snipp log
20:25 <svenl> vorlon: as it happened, the problem was that arm had still the old binutils, the new one should fix the build.
20:25 <svenl> vorlon: well, it is a many hours build on the slower arches, so i thought i would ask first.
20:26 <svenl> vorlon: BTW, as of today, all 2.6.8 kernels have been uploaded, except sparc, and joshk is still working on it.
20:26 <Beowulf> vorlon: hi
20:26 -!- sts [~sts@hermes.ncsaut.net] has joined #debian-devel
20:27 <Beowulf> vorlon: trying to debug the gnomemeeting problem (#266111) we found a different bug (#266442)
20:27 <Beowulf> vorlon: so right now we're quite lost about what steps take
20:29 <nchip> what should I apt-get to get printing up easily?
20:30 <Np237> nchip: cupsys-bsd and cupsys-driver-gimpprint
20:30 -!- don_peppino [~giskard@gmoboutz2.net.vodafone.it] has quit [Read error: 110 (Connection timed out)]
20:30 <Beowulf> cupsys cupsys-client
20:30 <Beowulf> and foomatic
20:31 <Beowulf> :)
20:31 <Np237> nchip: foomatic-filters-ppds can also be useful
20:31 <Beowulf> that one
20:31 <Beowulf> nchip: and if you use gnome, gnome-cups-manager
20:31 <sts> hey folks
20:33 -!- aroldan [~aroldan@200.124.172.25] has quit [Read error: 60 (Operation timed out)]
20:36 -!- simonrvn [simon@simonrvn.cloaked] has joined #debian-devel
20:36 -!- Keybuk [~scott@canonical.conference] has joined #debian-devel
20:37 -!- _lamont [~lamont@canonical.conference] has quit [Read error: 113 (No route to host)]
20:38 <vorlon> svenl: ok. I've talked to the security team, and they don't really think 2.6.8 vs. 2.6.7 is going to make much difference in the long term.
20:39 -!- nyu [~rmh@86.Red-80-24-13.pooles.rima-tde.net] has quit ["leaving"]
20:41 <ij> is there something that needs a recompile on mips?
20:41 <ij> well, the packages listes as needs-build, but... ;)
20:41 <Madkiss> vorlon!
20:41 <ij> listed even
20:42 -!- godog [~filo@host57-150.pool21345.interbusiness.it] has joined #debian-devel
20:42 <Madkiss> ij: there are some more packages left, I will go and have a look.
20:42 <svenl> vorlon: you mean, that it is not worth it to go for 2.6.8 over 2.6.7 ?
20:42 <vorlon> Beowulf: well, if we can get gnomemeeting fixed in unstable, that's the best solution.
20:42 <ij> Madkiss: paco is running and wants to get testet
20:42 <ij> -t+d
20:42 <Madkiss> ij: will go for it.
20:42 <Madkiss> vorlon: can you update the tiff-transition-status-DB?
20:42 <vorlon> svenl: they don't feel it's worth extraordinary effort to make 2.6.8 the default kernel.
20:42 <svenl> vorlon: does that mean that all the fixes which have gone in the 2.6.8 should be backported to 2.6.7 ?
20:43 <Beowulf> vorlon: anyway, I'm trying to test some situations for gnomemeeting in hppa, but don't having root on any hppa box don't let me mix versions
20:43 <vorlon> Madkiss: yes, what changes?
20:43 -!- sight [~siekala@62.85.88.238] has quit [Remote closed the connection]
20:43 <Madkiss> vorlon: wait, I will see. Is the current file up to date?
20:43 <vorlon> svenl: yes.
20:43 <vorlon> Madkiss: that's the live copy.
20:43 <svenl> vorlon: well, this sucks.
20:43 <Zugschlus> Which program does create debian/$PACKAGE.substvars?
20:43 <Madkiss> vorlon: wroah, you are such a bomber ;)
20:43 <dilinger> vorlon: i disagree. 2.6.8 includes a *lot* of fixes.
20:43 <Madkiss> vorlon: Mind to get me the URL again?
20:44 <dilinger> vorlon: we can backport the security stuff, but we're left w/ a fairly buggy 2.6.7 kernel
20:44 <Beowulf> Zugschlus: dpkg-*
20:44 <svenl> vorlon: Maybe we could upload a 2.6.7.isreally.2.6.8 or something such.
20:44 <Beowulf> Zugschlus: of dh_shlibs perhaps
20:44 <Zugschlus> ah, openssl hacks on that file in debian/rules. Which doesn't work on woody
20:44 <vorlon> svenl: why the hell would that be any better?
20:45 <vorlon> dilinger: ok, so far the arguments being made to me have all concerned the security aspects.
20:45 -!- otavio_ [~otavio@otavio.registered] has joined #debian-devel
20:45 -!- Arvind-NL [~Arvind@ip503d4396.speed.planet.nl] has quit [Read error: 104 (Connection reset by peer)]
20:45 <svenl> vorlon: the argument about the security aspect is that the security team wants only one kernel-source package for 2.6.
20:45 -!- otavio [~otavio@otavio.registered] has quit [Remote closed the connection]
20:45 -!- otavio_ [~otavio@otavio.registered] has quit [Remote closed the connection]
20:45 <svenl> vorlon: once sparc uploads 2.6.8, we are ready to drop 2.6.7.
20:45 -!- otavio [~otavio@otavio.registered] has joined #debian-devel
20:46 <svenl> vorlon: 20:54 < hch> svenl: well, tell them we're not gonna support 2.6.7 anymore
20:46 -!- kov [~kov@kov.registered] has joined #debian-devel
20:46 <svenl> vorlon: 20:54 < hch> svenl: we've invested enormous amounts into 2.6.8
20:46 <dilinger> vorlon: there are quite a few bugs in the BTS where people are forced to use 2.6.6 because 2.6.7 wouldn't work for them. there are a bunch of those types of fixes in 2.6.8, as well as many sparse fixes. the sparse fixes may or may not be classified as security fixes, but there's a good chance that there are some that are actual security problems that were passed over/not publicized as such
20:46 <vorlon> svenl: who's "we"? :P
20:47 <svenl> 20:55 < hch> and I'm not gonna backport all the fixes ontop of 2.6.8 to 2.6.7 anymore
20:47 <svenl> 20:55 < hch> nevermind the fixes in 2.6.8
20:47 -!- hch [~hch@verein.lst.de] has joined #debian-devel
20:47 <svenl> 20:55 < hch> svenl: too crowded
20:47 <svenl> vorlon: the debian-kernel maintainer team, hch, wli, dilinger, me, 18 people in total.
20:47 -!- mdz_ [~mdz@canonical.conference] has quit [Remote closed the connection]
20:48 <mjg59> What is it with people's desires to get the latest crack into sarge?
20:48 <dilinger> mjg59: see my comment above about 2.6.7 being buggy.
20:48 <mjg59> All software is buggy
20:48 <hch> mjg59: we have ~10mb changes from 2.6.7 to 2.6.8
20:48 -!- Evaso [~yellow@ppp-224-132.24-151.libero.it] has joined #debian-devel
20:48 <mjg59> Yes. Why do you have 10mb of changes from 2.6.7 to 2.6.8?
20:48 <dilinger> mjg59: the sky is blue. saying all software is buggy is irrelevant.
20:49 <hch> mjg59: and to about 70% that's bugfixes
20:49 <vorlon> svenl: well the good news is, Debian has no reason to expect that any maintainer will support their packages once they're in a stable release, so it doesn't seem to much matter from a security standpoint. :P
20:49 <Evaso> hi guys, anybody had take a look to the fbslpash path?
20:49 <kylem> mjg59, because 10mb of shit changed, obviously. :)
20:49 <claviola> infinity: okay, so it isn't a hack anymore. I figured out that I shouldn't be using /usr/share/<package> at all; instead, I must put everything in /usr/lib/<package>. That makes the wrapper script less hideous, too. :-)
20:49 <hch> mjg59: that's the upstream diff
20:49 <dilinger> Evaso: post-sarge.
20:49 * nutmeg would love to se only 2.6.8. A kernel with broken cd-writing support is less work for me. ;-)
20:49 <hch> mjg59: our local changes went down quite a bit
20:49 -!- helen [~helen@81-86-103-218.dsl.pipex.com] has joined #debian-devel
20:49 <mjg59> hch: Sure. But at some point you draw the line between acceptable levels of buggyness and actually having code that's well enough tested to release with
20:49 <hch> nutmeg: cd writing is broken both in 2.6.7 and 2.6.8 in different ways
20:49 <Evaso> dilinger: i'm talking about this one: http://dev.gentoo.org/%7Espock/projects/gensplash
20:50 <hch> nutmeg: but we're gonna fix it for 2.6.8
20:50 <hch> mjg59: right
20:50 <claviola> $(shell find . | egrep -v '/debian') <-- is this correct syntax?
20:50 <mjg59> hch: How are you going to fix it for 2.6.8?
20:50 <hch> mjg59: and for that we have decided on 2.6.8
20:50 <claviola> or $(shell find $(CURDIR) | egrep -v '/debian')
20:50 <dilinger> vorlon: i'm look at this from an installation standpoint. people are going to want to use 2.6 for various pieces of hardware, and if 2.6.7 blows up horribly during install..
20:50 <mjg59> (Out of interest - I haven't seen any consensus reached on linux-kernel yet)
20:50 <nutmeg> hch: How is it broken in 2.6.7? (I don't remember.)
20:50 <claviola> for a makefile
20:50 <hch> mjg59: we've fixed the memlea now, and we're gonna work around the cdrecord bug in cooperation with upstream
20:50 <dilinger> Evaso: i know. we'll figure it out post-sarge. right now, there are other things to do
20:51 <hch> nutmeg: huge memory leak
20:51 <nutmeg> hch: That ones is fixed in .8? Great.
20:51 <vorlon> dilinger: like what? 2.6.7 is the 2.6 kernel for d-i rc1, and I don't remember hearing of any significant problems.
20:51 <claviola> chirp chirp
20:51 <dilinger> vorlon: look through the misc. bugs against kernel-image-2.6.7-i386, kernel, etc. unfortunately, they're scattered across many packages, which makes going through them kind of annoying..
20:52 <svenl> vorlon: like the g4 errata patch which didn't went into 2.6.8, and means unstability while moving files around ?
20:52 <svenl> vorlon: and we have told you since almost a month that the debian kernel team really wanted to have 2.6.8 for sarge.
20:53 -!- hozer [hozer@kalmia.hozed.org] has joined #debian-devel
20:53 -!- Q-FUNK [~q-funk@gw-5.suomicom.fi] has joined #debian-devel
20:53 <svenl> hello hozer.
20:53 <hozer> hello
20:53 <vorlon> svenl: and the rationale being given to me was that it's better for the security team. The security team doesn't care, and I don't see any evidence that 2.6.7 is too buggy to release.
20:53 <Q-FUNK> to which e-mail do I send a request to have a package removed from unstable and definitely prevented from entering testing?
20:53 <hozer> I saw some discussion about 2.6.8 vs 2.6.7
20:54 <vorlon> I also don't see any evidence that 2.6.8 *isn't* too buggy to release, because it's too damn new for us to know this yet.
20:54 <Mithrandir> Q-FUNK: file a bug against ftp.d.o or mail -release?
20:54 <vorlon> Q-FUNK: ftp.d.o to get it removed; file an RC bug to keep it getting into testing.
20:54 <Beowulf> Q-FUNK: you don't need to remove a package to prevent it to enter testing
20:55 <Q-FUNK> in this case, I think that both getting it removed and blacklisted from testing is necessary.
20:55 <hch> vorlon: you know we have a big team fixing bugs all day
20:55 <Robot101> otavio: removing it from the archive means it will disappear from testing too
20:55 <svenl> vorlon: 2.6.8 has had at least two weeks of intensive work gone into that didn't go into 2.6.7.
20:55 <hch> vorlon: as do the folks at redhat and suse that are at 2..8 aswell for FC3 and Suse9.1
20:55 <Robot101> Q-FUNK: erm, I meant you
20:56 <Q-FUNK> sorry, removed from unstable and blacklisted from replacing an older good release currently in testing
20:56 <hch> so we have a huge community fixing any bugs on a 2.6.8 baase right now
20:56 <hch> while no one is at 2.6.7
20:56 -!- otavio [~otavio@otavio.registered] has quit [Remote closed the connection]
20:56 -!- ema [~ema@adsl-241-231.38-151.net24.it] has joined #debian-devel
20:56 -!- otavio [~otavio@200-203-056-015.pltce7001.dsl.brasiltelecom.net.br] has joined #debian-devel
20:56 <Robot101> Q-FUNK: oh, you need to upload an epoch'd one to unstable to guarantee that
20:56 <hozer> what is the issue with moving to 2.6.8?
20:56 <Robot101> Q-FUNK: or file an RC bug on the one in unstable saying "HORRIBLY BROKEN"
20:56 -!- isaac [~isaac@11.Red-213-97-14.pooles.rima-tde.net] has quit [Remote closed the connection]
20:56 <svenl> hozer: well, it is too late for the freeze.
20:57 <hozer> Are we just afraid something will break, or is there something I'm not understanding that will cause a lot of work
20:57 <svenl> vorlon: and consider half of the whole stuff uploaded this last month is untested.
20:57 <Q-FUNK> ok, then how should this be handled? the problme is Esound. the package in testing works flawlessly, while everything that recently entered unstable to replace it is broken sick.
20:57 <calc> 2.6.9 or 2.6.10 will likely be out by the time the buildds are caught up
20:57 <nutmeg> hozer: The former, afaict.
20:57 <hch> calc: we're not going any further for sarge
20:57 -!- mornfall [~mornfall@213.151.217.129] has quit ["the old ways are lost"]
20:58 <hch> calc: I'm currently spending lots of time getting 2.6.8 through all kinds of testing and grabbing safe fixes from everywhere
20:58 -!- lamont [~lamont@canonical.conference] has joined #debian-devel
20:58 <hch> aka, doing real release managment
20:58 <vorlon> hozer: for one thing, I'm being asked to commit to 2.6.8 without even having all of the binary packages uploaded that are needed to get us in sync on this architecture.
20:58 <hch> I could have done that with 2.6.7, but then we should have started earlier, and it would have been lots more work
20:58 <calc> btw are we planning to update kernels for sarge after its released, or will it become like woody where its not installable on new machines a few months after release?
20:59 <svenl> vorlon: as of tomorrow, exept sparc, all will be uploaded. Well, probably in the NEW queue.
20:59 -!- Np237 [~joss@tc2.perso.ens-lyon.org] has quit [Remote closed the connection]
20:59 <hch> calc: I'm gonna provide updated kernels, but I'm the one to decided whether they'll go into sarge
20:59 <svenl> and we have s390 in addition that didn't exist for 2.6.7
20:59 <hozer> vorlon : what arch are you on?
20:59 <hch> calc: so probably no
20:59 <vorlon> and when is sparc going to be ready?
20:59 <dilinger> is sparc just awaiting ide testing?
20:59 <vorlon> hozer: i386/alpha/powerpc? :)
20:59 <svenl> not today.
20:59 <calc> telling people to run stable and not providing a way for them to install it isn't a particularly good thing ;)
20:59 -!- amck [~alastair@194.46.89.4] has joined #debian-devel
21:00 <svenl> vorlon: you should ask joshk, it seemed a question of days though.
21:00 <hozer> aieee, I need to test those ;)
21:00 <mjg59> calc: Then we'll just have to release faster
21:00 <calc> but if debian releases more often perhaps it won't be a big issue like with woody :)
21:00 <Stric> mjg59: New release every month? :)
21:00 <calc> iirc within 6mo of official woody release i already couldn't install using the b-f kernels
21:00 <doogie> calc: release more often?
21:00 <Stric> "October Debian"
21:00 <hch> mjg59: given hardware development speed that's unrealistic
21:00 <doogie> what drugs are you on?
21:00 <hozer> or just release more kernels
21:01 <mjg59> calc: The Woody release was badly timed from that point of view
21:01 <hch> mjg59: allowing to sneak in new drivers in security updates would certainly help, but I'll leave those policy discussions to others
21:01 <svenl> joshk: you here ? Can you answer vorlon about sparc 2.6.8 ?
21:01 <hozer> most of th etime all you need is a new kernel
21:01 <mjg59> We suddenly had widespread use of stuff like USB and firewire that just hadn't been there before
21:01 <doogie> hozer: then new detection scripts to enable the drives
21:01 <doogie> drivers
21:01 <mjg59> There's not really anything like that appearing in the immediate future
21:01 -!- Np237 [~joss@tc2.perso.ens-lyon.org] has joined #debian-devel
21:02 <hch> doogie: for modern hardware you don't
21:02 <Md> mjg59: this is not relevant... the woody kernels just stopped booting on modern hardware
21:02 <hch> doogie: well, if you use the right scripts
21:02 <Md> or did not see ATA disks, etc
21:02 <hch> with detect1 that doesn't work of course
21:02 <hch> discover
21:02 <calc> mjg59: in my case it didnt support the main system chipset
21:03 <hch> mjg59: example, in septermber intel will start shipping prerelease of express-card notebooks
21:03 <claviola> cp -R $(shell find $(CURDIR) | egrep -v '/debian') debian/(...) <-- can someone tell me the right way to do this, i.e. copy everything from the package's build dir to its install dir in debian/ without trying to copy the debian/ subdir itself? (Yes, I do need to do that.)
21:03 <hch> mjg59: they haven't released a driver yet, but you can be sure most intel-based notebooks will have that by early next year
21:03 -!- Q-FUNK [~q-funk@gw-5.suomicom.fi] has left #debian-devel []
21:03 <claviola> how does $(shell ... ) handle pipes?
21:03 <calc> well in several of the cases anyway, i've had access to a lot of systems since woody release and some of them were simply driver issues, others were chipset level issues with the kernel, etc
21:03 -!- aroldan [~aroldan@200.124.172.25] has joined #debian-devel
21:03 <doogie> claviola: use tar
21:03 <mjg59> hch: Uh, I'd be surprised if it doesn't present as cardbus
21:04 <doogie> claviola: the contents of $(shell) is passed to sh -c
21:04 <dieman> calc: most of it is kernel shit though.
21:04 <hch> mjg59: it does to the driver
21:04 <dieman> calc: ive not had major reworking needs until this sata stuff
21:04 <hch> mjg59: card driver, that is
21:04 <Wile_E> hch: and why _not_ allowing newer kernels into sarge then?
21:04 <claviola> doogie: hm, tar
21:04 <dieman> calc: which is going to push me to something newer soon
21:04 <hch> mjg59: for for insertation/injection it doesn't
21:04 <doogie> tar -C $srcdir --exclude foo | tar -C $targetdir
21:04 <hch> Wile_E: personally I think that's good idea
21:04 <calc> dieman: yea it was all kernel issues, if the kernel on the installer was updated it would be fine
21:04 -!- darkersatanic [~hugo@mina.ecs.soton.ac.uk] has quit [Read error: 110 (Connection timed out)]
21:04 <hozer> I would agree..
21:05 <doogie> claviola: could use rsync too, but then you have to build-depend on rsync
21:05 <hch> Wile_E: discuss that with the release managers :)
21:05 <Wile_E> hch: <hch> calc: I'm gonna provide updated kernels, but I'm the one to decided whether they'll go into sarge
21:05 <dilinger> it would be nice to have that
21:05 <Wile_E> mising a "not" then?
21:05 <hozer> a new sarge-kernel every 3 months or so would ease a lot of the reasons people always bitch about debian being old
21:05 <hch> Wile_E: sorry, should have been ... but I'm NOT the one to decide ...
21:05 <doogie> hozer: so would faster releases
21:05 <Wile_E> hch: ahhh ;-)
21:05 <mjg59> hch: The NT4 world managed without working insert/eject for years
21:05 <dilinger> i mean, what ends up happening anyways is the release will become stale after 6-12 months, people will start creating installation disks w/ their own custom kernels anyways..
21:05 -!- netstat [~netstat@netstat.registered] has joined #debian-devel
21:05 <calc> hozer: not that much, but it would at least allow them to install it at all ;)
21:06 <hch> mjg59: never used that :)
21:06 <hch> and I have no interest to be as backwards
21:06 <hch> mjg59: that was just a random example anyway
21:06 <dilinger> and it would also put this to concern about 2.6.7 vs 2.6.8 to rest
21:06 <hch> dilinger: not really
21:06 <dilinger> we could release w/ 2.6.7 and have 2.6.8 in woody in a month
21:06 <hozer> dilinger: if we have a new 'stable' kernel every 3 months nobody needs to create their own installation disks anymroe
21:06 <dilinger> er, sarge
21:06 <dilinger> :)
21:06 <mjg59> hch: There's obviously hardware that won't be taken full advantage of with older kernels, but I expect there to be far less of a problem as far as installation goes this time round
21:06 <hch> dilinger: getting 2.6.7 into a shape the 2.6.8 packages are right now would be a lot of effort
21:07 <hch> mjg59: well, we saw how all this "worked" with woody
21:07 <hch> mjg59: but hey, I have better things to do with my time than to discuss that issue the nth time
21:07 -!- haggai [~challs@canonical.conference] has joined #debian-devel
21:08 <hch> try the model again with sarge and we'll see whether woody was a one-off
21:08 <dilinger> hozer: right. the problem is, how is this handled wrt security updates? force people to upgrade to the latest kernel, and provide security fixes for only those? provide security fixes for all "stable" kernels? that'd be a bitch..
21:08 <doogie> if we had client-side compiling of kernels ...
21:08 <hch> dilinger: don't move to new upstream release
21:09 <hch> dilinger: backport hardware support to the kernel we've freezed on
21:09 <mjg59> hch: With the new kernel development model, backporting drivers is going to become increasingly hard
21:09 <nobse> anyone from here plans to come to the linux kongress in erlangen?
21:09 <peterS> yeah, that's what I was gonna say - next time a kernel security issue comes out, if there are a dozen different sarge kernels in the wild, *somebody* is gonna have some real fun
21:09 <nobse> erks, wrong channel
21:09 <hch> mjg59: bullshit
21:09 <hch> mjg59: we're smart enough to make API changes in a way that makes backporting easily possible
21:09 <doogie> hch: there's a much higher chance of new features being added to the baseline kernel, that new drives will then use
21:10 <claviola> doogie: will make accept a pipe?
21:10 <doogie> claviola: huh? what are you trying to do?
21:10 <hozer> okay: how about this...
21:10 <claviola> I'm guessing at tar -cf --exclude=debian - $(CURDIR)/* | tar -xf debian/
21:10 <dilinger> hch: heh, for *3 years*?
21:10 <doogie> claviola: did you miss what I said?
21:10 <hozer> freeze on 2.6.8 or whatever
21:10 <peterS> doogie: well, there's the issue that even with the new development model, it seems 2.6 kernels are holding a line on stability at least as good as what 2.4 has had
21:10 <doogie> 2.6.8.1
21:11 <claviola> doogie: no, I just didn't really understand it.
21:11 <hch> dilinger: I though we tried to get a shorted release cycle
21:11 <hch> doogie: of course
21:11 <doogie> claviola: just do it
21:11 <hch> doogie: but in general it is possible
21:11 <dilinger> hch: plan for the worst case..
21:11 <hch> doogie: e.g. rh still backports lots of hw support to 2.4.9
21:11 <doogie> claviola: and why are you passing that to $(shell)? shouldn't it be a normal make line?
21:11 <hozer> and 1 'newer' kernel release every couple months
21:11 <claviola> doogie: I'm not anymore
21:11 <hch> and most vendors do to either 2.4.18 or 2.4.12 or both
21:11 <hch> 2.4.21
21:12 <hch> so if we're lucky certain commercial vendors will do lots of work for us anyway
21:12 <hozer> if you stick with 2.6.8, you get security updates
21:12 <svenl> hch: we wish a shorter release cycle, but we also did that for the past two or three releases, that i can remember, so ...
21:12 <hch> svenl: *grin*
21:12 <Madkiss> vorlon?
21:12 <hozer> if you move to a 'newer' kernel, you are forced to upgrade the next time another 'newer' rev kernel comes out
21:12 <hch> well, anyway
21:12 <hch> changing general policies would be welcomed by me, but that wasn't the discussion I'm here for
21:13 <vorlon> Madkiss: ?
21:13 <hozer> heh
21:13 * hozer needs to figure out why his debian mirror quit working and then test the latest kernel packages
21:13 <Md> anyway, debian kernels without support for 3D video cards or tg3 are not much useful for many people...
21:14 <hch> Md: we support tg3
21:14 <calc> svenl: well needing to rewrite an installer takes some time
21:14 <hch> Md: and thanks to ati and nvidia we don't have recent 3d drivers
21:14 -!- helen [~helen@81-86-103-218.dsl.pipex.com] has quit [Connection timed out]
21:14 <hch> not much we can do about it
21:15 <Md> hch: we /used/ to have 3D drivers for cards <= ATI 9200
21:15 <Evaso> Md: there is a way to change joystics default permission in udev? actually with the default installation joysticks can only be used by root
21:15 <dieman> hch: at least the nvidia drivers are supportable if you have to use them
21:15 <dieman> ive not found an easy way to deal with the ati drivers
21:15 <dieman> they require a full kernel tree
21:15 <hch> Md: and we still do
21:15 <hozer> Md: yep, and then ATI stopped doing open source
21:15 <dieman> to build
21:15 <mjg59> Argh why the fuck does qemu keep losing the ability to do keyboard input
21:15 -!- helen [~helen@81-86-208-69.dsl.pipex.com] has joined #debian-devel
21:15 <Md> hch: last time I looked, their were disabled because they load a binary firmware
21:15 <hch> hozer: actually, ati _is_ doing opensource
21:16 <hch> hozer: the 2d driver for the ati cards gets large contributions from ati
21:16 <hozer> ah
21:16 <hch> hozer: the 3d driver for older ati cards wasn't written by ati
21:16 <joshk> vorlon: sparc needs testing, i just built it for the very first time
21:16 <hch> Md: at least in 2.6 they aren't
21:16 <hch> md: we have an open bug against that, though
21:17 <hch> but after the sarge GR we stopped that silly firmware removal
21:17 <hch> still not sure what to do with the ones removed when herbert was still in charge
21:17 <Md> hch: s/stopped/postponed/
21:17 <hch> e.g. lack of qlogic drivers hurts
21:17 <hch> Md: yes
21:17 <doogie> let's never release debian, and tell everyone to run unstable
21:18 <dilinger> doogie: we already are.
21:18 <darksatanic> doogie: Everyone does anyway... where's the difference?
21:18 <doogie> make it official
21:18 <dilinger> doogie: well, actually, we're telling everyone to run testing.. and don't worry about those silly little security update things :)
21:18 <doogie> or make everyone run testing
21:18 <Md> let's releases to commercial distributions...
21:19 <hch> well, that's what's happening already
21:19 <Md> let's leave...
21:19 <dilinger> i still have about 10 boxes on our network running woody
21:19 -!- Vainikka [~tvainikk@jt7-336.tky.hut.fi] has quit ["..."]
21:19 <dilinger> i'm not looking forward to upgrading those, they're all pretty critical infrastructure :/
21:20 -!- Lancelot_ [~netwalker@48.110.203.62.cust.bluewin.ch] has quit ["www.bind.ch"]
21:20 <vorlon> hch, dilinger: so there's no intention of fixing 263753 and 263420 for 2.6.7?
21:21 <Madkiss> vorlon: query
21:21 -!- Lancelot [~netwalker@48.110.203.62.cust.bluewin.ch] has joined #debian-devel
21:21 <hch> vorlon: 263753 seems to be waiting for feedback
21:22 -!- Netsplit calvino.freenode.net <-> irc.freenode.net quits: HE, pollux
21:22 <mjg59> dilinger: It shouldn't be too bad except for the poor 386 users
21:22 -!- Evaso- [~yellow@ppp-115-139.24-151.libero.it] has joined #debian-devel
21:22 <svenl> Package: bug :)
21:22 <dilinger> vorlon: and 263420, i actually needed to talk to hch about..
21:22 <mjg59> (Of course, the poor 386 users will probably be spending the next two years or so performing the upgrade)
21:22 <hch> and 263420 is the pci-noacpi shit
21:23 <hch> acpi is buggy as hell
21:23 <hch> we could put in a dmi trigger to force that for that box
21:23 <dilinger> vorlon: also, 263753 was in 2.6.6 as well; if it's not fixed in 2.6.8, i'll dive in and see if i can figure it out
21:23 <dilinger> vorlon: so, it'll be fixed in 2.6.8 (and if necessary, backported to 2.6.7; although we hadn't intended on doing further 2.6.7 releases)
21:24 <hch> hmm, wli says 263420 is fixed in linus' bk
21:24 <hch> and since there's been no commits since 2.6.8 we should have the fix
21:24 <hch> still waiting for the submitters' feedback, though
21:24 -!- godog [~filo@host57-150.pool21345.interbusiness.it] has quit ["Each new user of a new system uncovers a new class of bugs."]
21:24 <hch> actually there was an acpi merge
21:25 <dilinger> hch: yea, i think it's fixed in the acpi merge
21:25 <mjg59> The acpi merge is by and large a good one, though it seems to manage to break suspend on various systems
21:25 <mjg59> That's the lack of sysdev resume ordering
21:25 <dilinger> mjg59: figure it wouldn't be an acpi merge if it didn't break *omething*
21:25 <hch> mjg59: yes, the usual acpi brekages
21:25 <dilinger> something, even
21:26 -!- Netsplit over, joins: HE, pollux
21:26 <hch> I'm so happy I don't have an x86 laptop
21:26 <dilinger> heh, my x86 laptop does acpi just fine. it's our hp servers that seem to have acpi problems..
21:26 <mjg59> hch: It only worked by accident before in this case, so I don't really blame them
21:26 <hch> mjg59: and acpi merge right now is for example something I'd consider risky
21:26 <hozer> heh.. now if I could only get the damn 802.11g stuff to work on my new shinybook
21:27 <hch> mjg59: well, when I still did release engineering for a commercial distro vendor we had shitloads of problems with acpi
21:27 <mjg59> hozer: Broadcom hate you (personally)
21:27 -!- pabl0 [~pabl0@201.129.196.57] has joined #debian-devel
21:27 <mjg59> hch: It seems to be settling down now compared to how entirely fucked it was this time last year
21:27 <hch> yes, it seems to slowly get better
21:27 <liw> I wish I had acpi (or sleep/hibernation) working properly on my laptop, rebooting twice a (work)day is irritating
21:28 <hch> but looking at the codebase and how much it has to trust bios vendors I wonder whether that's by accident
21:28 <liw> otoh, my 3com 802.11g-pcmcia-card was really easy to get to work
21:28 <hch> btw, RH has an interesting hack
21:28 <hch> they claim to ACPI that they're WinXP
21:29 <mjg59> hch: The core ACPI code claims to be Windows now, too
21:29 <hch> looks like some biossses have a if (WinXP) do_the_right_thing() else /* win98 of course */ broken_workarounds() logic
21:29 <hch> mjg59: hmm, in 2.6.8 it doesn't yet
21:29 <mjg59> Possibly it should be tweaked to claim that it's XP
21:29 <hch> I can import that patch
21:30 <hch> but as I don't have x86 I felt a little uncomfortable just commiting it
21:30 <mjg59> It's probably the right thing to do
21:30 <hch> okay, I'll commit it and assign all bugreports to you :)
21:31 <mjg59> But the proportion of machines where acpi will work without fiddling is still tiny
21:31 <mjg59> I spend a couple of days last week playing with a pile of machines
21:31 <trippeh> all my non-blacklisted machines do acpi just fine nowadays, no tweaking needed
21:31 <trippeh> thats about 15 machines
21:32 <dieman> mjg59: my laptop worked fine for a while
21:32 <dieman> mjg59: i think suspend is broken again
21:32 <mjg59> The "best" ones didn't even have the power and sleep buttons listed as wakeup devices
21:32 <mjg59> Worked under XP, but under Linux there was no way to generate a sleep event
21:32 <trippeh> (no laptops however)
21:32 <mjg59> I didn't pull out the DSDT to check whether they did the right thing for XP, but that might well have helped
21:32 <mjg59> trippeh: Yeah, laptops are harder
21:33 <vorlon> given that 263753 looks rather relevant to the installer, it seems we're going to want an update to the kernel in d-i regardless; and 2.6.8 certainly seems to be closer to being ready than a fixed 2.6.7.
21:33 <mjg59> trippeh: The main problem is getting the video reinitialised. ACPI leaves that up to the OS - we have no idea how to do that in the general case
21:34 <vorlon> joshk: when do you expect to have time to test the sparc kernels? They do still have to go through NEW processing...
21:34 <joshk> vorlon: well, 2.6 is newly stalled, waiting on an initrd-tools bug
21:34 <joshk> 2.4 should hit NEW tomorrow if all goes well
21:34 <joshk> (hopefully jbailey should have found the problem by tonightish)
21:35 -!- piotr [~pedro@FW-30-241.go.retevision.es] has joined #debian-devel
21:35 -!- jdmetz [~Josh_Metz@dsl103.21.ic.net] has joined #debian-devel
21:35 <hch> joshk: which initrd-tools bug?
21:36 <joshk> hch: 263216, i posted an alternate case in which this handling is a problem
21:36 <joshk> /usr/sbin/mkinitrd: add_modules_dep_2_5: modprobe failed
21:36 <joshk> FATAL: Module sun3x_esp not found.
21:36 <joshk> FATAL: Module mca_53c9x not found.
21:36 <joshk> FATAL: Module mac_esp not found.
21:36 <joshk> FATAL: Module jazz_esp not found.
21:37 <joshk> FATAL: Module dec_esp not found.
21:37 <joshk> Failed to create initrd image.
21:37 <joshk> that's a nono. mac_esp, dec_esp, and jazz_esp on sparc? fat chance
21:37 <hch> hmm
21:37 <hch> and all those drivers are fucked on 2.6 anyway
21:37 <joshk> i was thinking a ARCH_ESP variable
21:37 <hch> joshk: or we'll fix the drivers up to have uniqueue names
21:37 <joshk> but wondered: this support sucks anyway
21:38 <hch> joshk: were does mkinited check for the names?
--
maks
kernel janitor http://janitor.kernelnewbies.org/
personal weblog http://www.sternwelten.at/weblog.shtml
Reply to: