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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] has quit [Read error: 60 (Operation timed out)] 20:36 -!- simonrvn [EMAIL PROTECTED] has joined #debian-devel 20:36 -!- Keybuk [EMAIL PROTECTED] has joined #debian-devel 20:37 -!- _lamont [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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_ [EMAIL PROTECTED] has joined #debian-devel 20:45 -!- Arvind-NL [EMAIL PROTECTED] 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 [EMAIL PROTECTED] has quit [Remote closed the connection] 20:45 -!- otavio_ [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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_ [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] has joined #debian-devel 20:53 -!- Q-FUNK [EMAIL PROTECTED] 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 [EMAIL PROTECTED] has quit [Remote closed the connection] 20:56 -!- ema [EMAIL PROTECTED] has joined #debian-devel 20:56 -!- otavio [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] has quit ["..."] 21:19 <dilinger> i'm not looking forward to upgrading those, they're all pretty critical infrastructure :/ 21:20 -!- Lancelot_ [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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- [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] has joined #debian-devel 21:35 -!- jdmetz [EMAIL PROTECTED] 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
