On 24 July 2011 16:09, Ray Rashif wrote:

On 24 July 2011 16:34, 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.

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.

Am 25.07.2011 15:57, schrieb Ray Rashif:

On 24 July 2011 21:52, Evangelos Foutras 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 25 July 2011 15:30, Evangelos Foutras 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

Am 27.07.2011 14:49, schrieb Tom Gundersen:

On Wed, Jul 27, 2011 at 2:42 PM, Evangelos Foutras wrote:

...

On 24 July 2011 11:34, 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.

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 27 July 2011 22:47, Pierre Schmitz 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.

On Fri, Jul 29, 2011 at 2:12 PM, Tom Gundersen wrote:

Hi Tobias,

On Sun, Jul 24, 2011 at 10: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.

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.

Am 29.07.2011 21:38, schrieb Tom Gundersen:

On Fri, Jul 29, 2011 at 9:21 PM, Dan McGee 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