[arch-dev-public] kernel 3.0 enters testing
Hi guys, first try with 3.0 kernel, nvidia legacy is not building, due to some makefile conftest restriction, patches are welcome. Have fun and find issues. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
On 07/24/2011 11:34 AM, Tobias Powalowski wrote:
Hi guys, first try with 3.0 kernel, nvidia legacy is not building, due to some makefile conftest restriction, patches are welcome.
nvidia-173xx updated to 173.14.31 and built fine against linux 3.0.
Have fun and find issues.
greetings tpowa
-- Ionuț
On 24 July 2011 16:34, Tobias Powalowski <tobias.powalowski@googlemail.com> wrote:
Hi guys, first try with 3.0 kernel, nvidia legacy is not building, due to some makefile conftest restriction, patches are welcome.
Have fun and find issues.
Like I mentioned on IRC, I'd like for the PKGBUILD to be cleaner (it has collected much inconsistency in style over the years). I suppose it's mainly a lack of motivation (no-one wants to read through the entire thing just to fix how the PKGBUILD looks), so I motivated myself to do it: http://paste.pocoo.org/show/445356/ Just proper spacing, organising, quoting and bracing of variables, some blank lines, indents..stuff that makes the PKGBUILD _not_ look like a mess; allows for easier duplication/modification. -- GPG/PGP ID: 8AADBB10
On 24 July 2011 16:09, Ray Rashif <schiv@archlinux.org> wrote:
On 24 July 2011 16:34, Tobias Powalowski <tobias.powalowski@googlemail.com> wrote:
Hi guys, first try with 3.0 kernel, nvidia legacy is not building, due to some makefile conftest restriction, patches are welcome.
Have fun and find issues.
Like I mentioned on IRC, I'd like for the PKGBUILD to be cleaner (it has collected much inconsistency in style over the years).
I suppose it's mainly a lack of motivation (no-one wants to read through the entire thing just to fix how the PKGBUILD looks), so I motivated myself to do it: http://paste.pocoo.org/show/445356/
Just proper spacing, organising, quoting and bracing of variables, some blank lines, indents..stuff that makes the PKGBUILD _not_ look like a mess; allows for easier duplication/modification.
That's quite an improvement. :) One thing I noticed; some variables still use the $var syntax after your patch, although ${var} seems to be much more prevalent in the PKGBUILD. I think it'd be a good idea to change them all to use the same syntax.
On 24 July 2011 21:52, Evangelos Foutras <foutrelis@gmail.com> wrote:
One thing I noticed; some variables still use the $var syntax after your patch, although ${var} seems to be much more prevalent in the PKGBUILD. I think it'd be a good idea to change them all to use the same syntax.
I didn't want to touch anything that'd fall under "personal preference", but I suppose those aren't personal preference since they're not consistent with the rest of the PKGBUILD. I probably missed that. Updated: http://paste.pocoo.org/show/446030/ -- GPG/PGP ID: 8AADBB10
Am 25.07.2011 15:57, schrieb Ray Rashif:
On 24 July 2011 21:52, Evangelos Foutras <foutrelis@gmail.com> wrote:
One thing I noticed; some variables still use the $var syntax after your patch, although ${var} seems to be much more prevalent in the PKGBUILD. I think it'd be a good idea to change them all to use the same syntax.
I didn't want to touch anything that'd fall under "personal preference", but I suppose those aren't personal preference since they're not consistent with the rest of the PKGBUILD. I probably missed that.
Updated: http://paste.pocoo.org/show/446030/
-- GPG/PGP ID: 8AADBB10 Sorry your patch is listed as already applied. greetings tpowa
-- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
On 26 July 2011 00:21, Tobias Powalowski <tobias.powalowski@googlemail.com> wrote:
Sorry your patch is listed as already applied. greetings tpowa
Oops. I didn't know the changes would be merged (so fast), so I just updated the initial changeset. Anyway, this one is minor but you can still apply for the sake of consistency: http://paste.pocoo.org/show/446137/ -- GPG/PGP ID: 8AADBB10
On Sun, 24 Jul 2011 10:34:35 +0200, Tobias Powalowski wrote:
Hi guys, first try with 3.0 kernel, nvidia legacy is not building, due to some makefile conftest restriction, patches are welcome.
Have fun and find issues.
greetings tpowa
Also note that the current version is 3.0.0-ARCH instead of 3.0-ARCH. This means external modules like nvidia etc. need to be rebuilt on every minor kernel update. But we would need to check if tools would accept a short version like 3.0 if we want to change that. Greetings, Pierre -- Pierre Schmitz, https://users.archlinux.de/~pierre
On 25 July 2011 13:13, Pierre Schmitz <pierre@archlinux.de> wrote:
On Sun, 24 Jul 2011 10:34:35 +0200, Tobias Powalowski wrote:
Hi guys, first try with 3.0 kernel, nvidia legacy is not building, due to some makefile conftest restriction, patches are welcome.
Have fun and find issues.
greetings tpowa
Also note that the current version is 3.0.0-ARCH instead of 3.0-ARCH. This means external modules like nvidia etc. need to be rebuilt on every minor kernel update. But we would need to check if tools would accept a short version like 3.0 if we want to change that.
I suggest we go for 3.0-ARCH; didn't notice any issues doing that [1] on my desktop. :] [1] http://pkgbuild.com/~foutrelis/remove-sublevel.patch
On 25 July 2011 15:30, Evangelos Foutras <foutrelis@gmail.com> wrote:
I suggest we go for 3.0-ARCH; didn't notice any issues doing that [1] on my desktop. :]
I take that back (the "didn't notice any issues" part, not the push for 3.0-ARCH :p). procps will need a small patch to not complain with only two digits: https://bugzilla.redhat.com/show_bug.cgi?id=711192
On 25 July 2011 16:26, Evangelos Foutras <foutrelis@gmail.com> wrote:
On 25 July 2011 15:30, Evangelos Foutras <foutrelis@gmail.com> wrote:
I suggest we go for 3.0-ARCH; didn't notice any issues doing that [1] on my desktop. :]
I take that back (the "didn't notice any issues" part, not the push for 3.0-ARCH :p).
procps will need a small patch to not complain with only two digits:
I noticed that Tobias changed the kernel release to '3.0-ARCH', so I applied Fedora's patch and pushed procps 3.2.8-4 to [testing].
On 24 July 2011 11:34, Tobias Powalowski <tobias.powalowski@googlemail.com> wrote:
Hi guys, first try with 3.0 kernel, nvidia legacy is not building, due to some makefile conftest restriction, patches are welcome.
Have fun and find issues.
One more patch [1], this time to set the default console loglevel to 4. This solves the issue I brought up in the initscripts signoff thread. Check the comments added to the PKGBUILD for some extra details. [1] http://pkgbuild.com/~foutrelis/shush-kernel-messages.patch
On Wed, Jul 27, 2011 at 2:42 PM, Evangelos Foutras <foutrelis@gmail.com> wrote:
On 24 July 2011 11:34, Tobias Powalowski <tobias.powalowski@googlemail.com> wrote:
Hi guys, first try with 3.0 kernel, nvidia legacy is not building, due to some makefile conftest restriction, patches are welcome.
Have fun and find issues.
One more patch [1], this time to set the default console loglevel to 4. This solves the issue I brought up in the initscripts signoff thread.
Check the comments added to the PKGBUILD for some extra details.
[1] http://pkgbuild.com/~foutrelis/shush-kernel-messages.patch
+1 for this. In the future this should be a configure option, as Dave just sent off a patch to lkml, but until then it would be nice if we did not have to work around this in rc.sysinit. -t
Am 27.07.2011 14:49, schrieb Tom Gundersen:
On Wed, Jul 27, 2011 at 2:42 PM, Evangelos Foutras <foutrelis@gmail.com> wrote:
On 24 July 2011 11:34, Tobias Powalowski <tobias.powalowski@googlemail.com> wrote:
Hi guys, first try with 3.0 kernel, nvidia legacy is not building, due to some makefile conftest restriction, patches are welcome.
Have fun and find issues.
One more patch [1], this time to set the default console loglevel to 4. This solves the issue I brought up in the initscripts signoff thread.
Check the comments added to the PKGBUILD for some extra details.
[1] http://pkgbuild.com/~foutrelis/shush-kernel-messages.patch
+1 for this.
In the future this should be a configure option, as Dave just sent off a patch to lkml, but until then it would be nice if we did not have to work around this in rc.sysinit.
-t Shall I apply this now or is the rule, don't change upstream here? greetings tpowa
-- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
On Wed, 27 Jul 2011 21:31:49 +0200, Tobias Powalowski wrote:
Am 27.07.2011 14:49, schrieb Tom Gundersen:
On Wed, Jul 27, 2011 at 2:42 PM, Evangelos Foutras <foutrelis@gmail.com> wrote:
On 24 July 2011 11:34, Tobias Powalowski <tobias.powalowski@googlemail.com> wrote:
Hi guys, first try with 3.0 kernel, nvidia legacy is not building, due to some makefile conftest restriction, patches are welcome.
Have fun and find issues.
One more patch [1], this time to set the default console loglevel to 4. This solves the issue I brought up in the initscripts signoff thread.
Check the comments added to the PKGBUILD for some extra details.
[1] http://pkgbuild.com/~foutrelis/shush-kernel-messages.patch
+1 for this.
In the future this should be a configure option, as Dave just sent off a patch to lkml, but until then it would be nice if we did not have to work around this in rc.sysinit.
-t Shall I apply this now or is the rule, don't change upstream here? greetings tpowa
I'd say you may apply it once Linus has pulled this patch into his tree. -- Pierre Schmitz, https://users.archlinux.de/~pierre
On 27 July 2011 22:47, Pierre Schmitz <pierre@archlinux.de> wrote:
I'd say you may apply it once Linus has pulled this patch into his tree.
This is not the same patch as the one Dave submitted upstream. This patch changes the default console loglevel to 4, while Dave's patch makes it configurable via a .config setting. My thinking was to apply this patch temporarily while the other one is considered for inclusion upstream, allowing us to move forward without waiting for upstream's decision.
Hi Tobias, On Sun, Jul 24, 2011 at 10:34 AM, Tobias Powalowski <tobias.powalowski@googlemail.com> wrote:
Hi guys, first try with 3.0 kernel, nvidia legacy is not building, due to some makefile conftest restriction, patches are welcome.
I have not looked into this at all, so take this with a grain of salt. On my office computer my nfs share fails to mount after upgrading to linux-3.0-2. Looking at the logs, it looks like linux-3.0-1 works fine, now that I downgraded to kernel26 from core it also works. The error I get (from memory) is: "mount.nfs: segfault in libc-2.14.so" or something along those lines. I tried reinstalling glibc, rebooting a few times, but the bug was always reproducible. Sorry that I don't have more info, but I'm in a bit of a hurry so didn't have time to debug further. Cheers, Tom
On Fri, Jul 29, 2011 at 2:12 PM, Tom Gundersen <teg@jklm.no> wrote:
Hi Tobias,
On Sun, Jul 24, 2011 at 10:34 AM, Tobias Powalowski <tobias.powalowski@googlemail.com> wrote:
Hi guys, first try with 3.0 kernel, nvidia legacy is not building, due to some makefile conftest restriction, patches are welcome.
I have not looked into this at all, so take this with a grain of salt.
On my office computer my nfs share fails to mount after upgrading to linux-3.0-2. Looking at the logs, it looks like linux-3.0-1 works fine, now that I downgraded to kernel26 from core it also works.
Same as this? https://bugs.archlinux.org/task/25306 Anyway, I'm seeing exactly the same on my machine- server is running 3.0-1, but client machine is running 3.0-2 and my share does not mount. Pretty critical issue, I'd say. Perhaps it is this since we did not patch? Absolutely bullshit that it causes a segfault but: http://comments.gmane.org/gmane.linux.nfs/41830 $ dmesg | grep nfs [ 19.346820] FS-Cache: Netfs 'nfs' registered for caching [ 19.365979] Installing knfsd (copyright (C) 1996 okir@monad.swb.de). [ 19.777763] mount.nfs4[1187]: segfault at 0 ip 00007fc8cf6b75f4 sp 00007fff20038b20 error 4 in libc-2.14.so[7fc8cf67f000+157000]
The error I get (from memory) is: "mount.nfs: segfault in libc-2.14.so" or something along those lines. I tried reinstalling glibc, rebooting a few times, but the bug was always reproducible.
Sorry that I don't have more info, but I'm in a bit of a hurry so didn't have time to debug further.
On Fri, Jul 29, 2011 at 9:21 PM, Dan McGee <dpmcgee@gmail.com> wrote:
Same as this? https://bugs.archlinux.org/task/25306
Yes. Exactly the same.
Perhaps it is this since we did not patch? Absolutely bullshit that it causes a segfault but: http://comments.gmane.org/gmane.linux.nfs/41830
Yup, that's almost certainly it. As expected, user-space tools will fail if we only have two digits in our kernel version. This is of course beyond ridiculous, but that's life. Maybe it is worth releasing this kernel as 3.0.0, and try again with 3.1? Hopefully nfs and others will be fixed by then? Or we could just try to patch whatever breaks :-) -t
Am 29.07.2011 21:38, schrieb Tom Gundersen:
On Fri, Jul 29, 2011 at 9:21 PM, Dan McGee <dpmcgee@gmail.com> wrote:
Same as this? https://bugs.archlinux.org/task/25306
Yes. Exactly the same.
Perhaps it is this since we did not patch? Absolutely bullshit that it causes a segfault but: http://comments.gmane.org/gmane.linux.nfs/41830
Yup, that's almost certainly it. As expected, user-space tools will fail if we only have two digits in our kernel version. This is of course beyond ridiculous, but that's life. Maybe it is worth releasing this kernel as 3.0.0, and try again with 3.1? Hopefully nfs and others will be fixed by then? Or we could just try to patch whatever breaks :-)
-t I'll try to fix this, but new nfs-utils don't like libtirpc 0.2.2 have to figure out why. greetings tpowa
-- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
Am 29.07.2011 22:08, schrieb Tobias Powalowski:
Am 29.07.2011 21:38, schrieb Tom Gundersen:
On Fri, Jul 29, 2011 at 9:21 PM, Dan McGee <dpmcgee@gmail.com> wrote:
Same as this? https://bugs.archlinux.org/task/25306
Yes. Exactly the same.
Perhaps it is this since we did not patch? Absolutely bullshit that it causes a segfault but: http://comments.gmane.org/gmane.linux.nfs/41830
Yup, that's almost certainly it. As expected, user-space tools will fail if we only have two digits in our kernel version. This is of course beyond ridiculous, but that's life. Maybe it is worth releasing this kernel as 3.0.0, and try again with 3.1? Hopefully nfs and others will be fixed by then? Or we could just try to patch whatever breaks :-)
-t I'll try to fix this, but new nfs-utils don't like libtirpc 0.2.2 have to figure out why. greetings tpowa
Ok new libtirpc nfs-utils and libgssglue is in testing, all should work now again. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
participants (7)
-
Dan McGee
-
Evangelos Foutras
-
Ionut Biru
-
Pierre Schmitz
-
Ray Rashif
-
Tobias Powalowski
-
Tom Gundersen