[arch-dev-public] [signoff] kernel26 2.6.28-2
Hi guys, new kernel adresses the following things: just a quick rebuild fixing karma support and bumped depend on mkinitcpio 0.5.20. please signoff for both arches I would like to move in kernel, klibc, mkinitcpio,module-init-tools and binary modules on tuesday to core if you are all fine with it. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
On Sun, Jan 4, 2009 at 1:59 PM, Tobias Powalowski <t.powa@gmx.de> wrote:
Hi guys, new kernel adresses the following things: just a quick rebuild fixing karma support and bumped depend on mkinitcpio 0.5.20.
please signoff for both arches
I would like to move in kernel, klibc, mkinitcpio,module-init-tools and binary modules on tuesday to core if you are all fine with it.
The wireless regulatory stuff has to go as well, right? What is our upgrade path for this, as most users won't just know they need to install the new packages (but making them a depend is not correct either)? optdepends might work here as a warning would be shown in the pacman output, but I would definitely include this in the news item as well. -Dan
On Sun, Jan 4, 2009 at 1:59 PM, Tobias Powalowski <t.powa@gmx.de> wrote:
Hi guys, new kernel adresses the following things: just a quick rebuild fixing karma support and bumped depend on mkinitcpio 0.5.20.
please signoff for both arches
I would like to move in kernel, klibc, mkinitcpio,module-init-tools and binary modules on tuesday to core if you are all fine with it.
The wireless regulatory stuff has to go as well, right? What is our upgrade path for this, as most users won't just know they need to install the new packages (but making them a depend is not correct either)? optdepends might work here as a warning would be shown in the pacman output, but I would definitely include this in the news item as well.
-Dan Hrm, Thomas some input on this please. All crda and depends should move to core right? Could you post a little summary, how the new stuff works. I use wireless but don't need this regulatory stuff at all.
Am Sonntag 04 Januar 2009 schrieb Dan McGee: thanks. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
Tobias Powalowski schrieb:
The wireless regulatory stuff has to go as well, right? What is our upgrade path for this, as most users won't just know they need to install the new packages (but making them a depend is not correct either)? optdepends might work here as a warning would be shown in the pacman output, but I would definitely include this in the news item as well.
-Dan Hrm, Thomas some input on this please. All crda and depends should move to core right? Could you post a little summary, how the new stuff works. I use wireless but don't need this regulatory stuff at all. thanks.
Without the regulatory stuff, some default channels will be enabled (like 1-11) and the old hardcoded US, JP and EU domains (via the cfg80211_regdom module parameter) still work (the latter will be removed upstream in .29). However, to make the kernel use the correct information, you need crda. That is only necessary if you use channels 12-14 or 802.11a, although it would be best if everyone would set his regulatory domain so nobody accidently transmits on a prohibited channel. I'd say we add optdepends on crda, wireless won't break for most people anyway. After crda is installed, all you need to do is uncomment the right regdom in /etc/conf.d/wireless-regdom and add wireless-regdom to DAEMONS.
On Mon, Jan 5, 2009 at 2:38 AM, Thomas Bächler <thomas@archlinux.org> wrote:
Tobias Powalowski schrieb:
The wireless regulatory stuff has to go as well, right? What is our upgrade path for this, as most users won't just know they need to install the new packages (but making them a depend is not correct either)? optdepends might work here as a warning would be shown in the pacman output, but I would definitely include this in the news item as well.
-Dan
Hrm, Thomas some input on this please. All crda and depends should move to core right? Could you post a little summary, how the new stuff works. I use wireless but don't need this regulatory stuff at all. thanks.
Without the regulatory stuff, some default channels will be enabled (like 1-11) and the old hardcoded US, JP and EU domains (via the cfg80211_regdom module parameter) still work (the latter will be removed upstream in .29).
However, to make the kernel use the correct information, you need crda. That is only necessary if you use channels 12-14 or 802.11a, although it would be best if everyone would set his regulatory domain so nobody accidently transmits on a prohibited channel.
I'd say we add optdepends on crda, wireless won't break for most people anyway. After crda is installed, all you need to do is uncomment the right regdom in /etc/conf.d/wireless-regdom and add wireless-regdom to DAEMONS.
And I'm not sure you even have to add anything to daemons at all- when I installed these packages on my laptop, the udev rule seemed to take care of everything and called crda all on its own. -Dan
On Mon, Jan 5, 2009 at 8:01 AM, Dan McGee <dpmcgee@gmail.com> wrote:
On Mon, Jan 5, 2009 at 2:38 AM, Thomas Bächler <thomas@archlinux.org> wrote:
Tobias Powalowski schrieb:
The wireless regulatory stuff has to go as well, right? What is our upgrade path for this, as most users won't just know they need to install the new packages (but making them a depend is not correct either)? optdepends might work here as a warning would be shown in the pacman output, but I would definitely include this in the news item as well.
-Dan
Hrm, Thomas some input on this please. All crda and depends should move to core right? Could you post a little summary, how the new stuff works. I use wireless but don't need this regulatory stuff at all. thanks.
Without the regulatory stuff, some default channels will be enabled (like 1-11) and the old hardcoded US, JP and EU domains (via the cfg80211_regdom module parameter) still work (the latter will be removed upstream in .29).
However, to make the kernel use the correct information, you need crda. That is only necessary if you use channels 12-14 or 802.11a, although it would be best if everyone would set his regulatory domain so nobody accidently transmits on a prohibited channel.
I'd say we add optdepends on crda, wireless won't break for most people anyway. After crda is installed, all you need to do is uncomment the right regdom in /etc/conf.d/wireless-regdom and add wireless-regdom to DAEMONS.
And I'm not sure you even have to add anything to daemons at all- when I installed these packages on my laptop, the udev rule seemed to take care of everything and called crda all on its own.
-Dan
Both systems booted fine. Signoff both arches.
2009/1/5, Eric Bélanger <snowmaniscool@gmail.com>:
Both systems booted fine. Signoff both arches.
The system booted fine. Signoff for x86_64 -- Arch Linux Developer (voidnull) AUR & Pacman Italian Translations Microdia Developer http://www.archlinux.it
Dan McGee schrieb:
And I'm not sure you even have to add anything to daemons at all- when I installed these packages on my laptop, the udev rule seemed to take care of everything and called crda all on its own.
Of course. The problem is that the kernel doesn't know what the correct regulatory domain is. I think some drivers can notify it if they have a country code in their EEPROM, and starting with 2.6.29, a code can be received from an AP. I had to set the domain. If you look at the daemon script, all it does is "iw reg set XX". The kernel seems to use US by default (although it should probably use 00).
On Mon, Jan 5, 2009 at 4:18 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Dan McGee schrieb:
And I'm not sure you even have to add anything to daemons at all- when I installed these packages on my laptop, the udev rule seemed to take care of everything and called crda all on its own.
Of course. The problem is that the kernel doesn't know what the correct regulatory domain is. I think some drivers can notify it if they have a country code in their EEPROM, and starting with 2.6.29, a code can be received from an AP. I had to set the domain. If you look at the daemon script, all it does is "iw reg set XX". The kernel seems to use US by default (although it should probably use 00).
Ahh, being on this side of the pond I just assumed it was smart. Didn't realize it wasn't pulling that country code from the config file but it just happened to pick US. -Dan
Hi guys (especially tpowa and JGC), the new Kernel has GEM. Shall we try to compile xf86-video-intel-2.5.x against it because it makes sense now and see if it creates trouble b4 we release it to core? Just a guess. -T
On Mon, Jan 5, 2009 at 5:04 PM, <tobias@justdreams.de> wrote:
Hi guys (especially tpowa and JGC),
the new Kernel has GEM. Shall we try to compile xf86-video-intel-2.5.x against it because it makes sense now and see if it creates trouble b4 we release it to core?
Just a guess.
I'd say get the kernel to [core] first, then maybe put this through testing if possible. No need to hold up the kernel for this. -Dan P.S. I can test this driver as well on my Eee, let me know.
On Tue, 2009-01-06 at 00:04 +0100, tobias@justdreams.de wrote:
Hi guys (especially tpowa and JGC),
the new Kernel has GEM. Shall we try to compile xf86-video-intel-2.5.x against it because it makes sense now and see if it creates trouble b4 we release it to core?
Just a guess.
-T
I'm running the 2.6 prerelease series for a while on my laptop now. My first impressions: - EXA is even slower than it was with 2.4.3 - UXA is much faster - XAA not tested - 3D is horribly slow - Compiz doesn't draw window decorations due to some breakage in libdrm If we want to use 2.5.x or 2.6 when it comes out, we have to grab a mesa snapshot from git master to get GEM support in mesa also. As xorg-server 1.6 shouldn't be far away anymore, I think we can wait for the next stable release of mesa that has GEM support.
Quoting Jan de Groot <jan@jgc.homeip.net>:
I'm running the 2.6 prerelease series for a while on my laptop now. My first impressions: - EXA is even slower than it was with 2.4.3 - UXA is much faster - XAA not tested - 3D is horribly slow - Compiz doesn't draw window decorations due to some breakage in libdrm
If we want to use 2.5.x or 2.6 when it comes out, we have to grab a mesa snapshot from git master to get GEM support in mesa also.
As xorg-server 1.6 shouldn't be far away anymore, I think we can wait for the next stable release of mesa that has GEM support.
Just as I thought you have much more insight on this. I totally agree to stick with 2.4.x for now. Thanks, -T
participants (7)
-
Dan McGee
-
Eric Bélanger
-
Giovanni Scafora
-
Jan de Groot
-
Thomas Bächler
-
Tobias Powalowski
-
tobias＠justdreams.de