On Sat, Jan 30, 2010 at 07:13, pyther wrote:

Likely everything is being compiled in the kernel. The idea behind this is so you can take the binary and distribute it to anyone and have it work on their systems (with different hardware).

if you want to use your own config and select what you want have a look at this wiki guide: http://wiki.archlinux.org/index.php/Custom_Kernel_Compilation_with_ABS

~pyther

I don't think this wiki page has been updated since the big PKGBUILD rewrite. It should be *much* simpler now than that guide implies. The page needs a total overhaul by someone who knows this inside and out.

On 01/30/2010 01:37 PM, Heiko Baums wrote:

Am Sat, 30 Jan 2010 13:11:26 +0100 schrieb Andrea Crotti:

...

Sometimes (only twice actually) I had to recompile the kernel with ice support from aur. Now compiling the kernel is not a short job, but it looks like it really compiles EVERYTHING!

Maybe putting my .config somewhere it will not do it, how do you manage it?

I guess this is the easiest way to compile your own kernel:

1. cp -R /var/abs/core/kernel26 /var/abs/local/kernel26-<yourkernelname>

2. Edit these variables in the PKGBUILD: pkgbase (to your package name) pkgname (copy the original one and replace kernel26* with kernel26-<yourkernelname>*)

3. Add the patches you like to the PKGBUILD.

4. Remove the comments of these lines: #make menuconfig # CLI menu for configuration (or the other options) #msg "Stopping build" #return 1

5. Run makepkg -g and replace the md5sums in the PKGBUILD.

6. Run makepkg and configure your kernel. (You don't need to change CONFIG_LOCALVERSION, this is done by the PKGBUILD automatically.)

7. cd /var/abs/local/kernel26-<yourkernelname>/src/linux-<kernelversion> diff -u .config.old .config cd ../.. Make the changes to the files config and config.x86_64 manually.

or

cd /var/abs/local/kernel26-<yourkernelname> cp src/linux-<kernelversion>/.config ./config or cp src/linux-<kernelversion>/.config ./config.x86_64 (depending on your CPU)

8. Run makepkg -g and replace the md5sums in the PKGBUILD.

9. Edit the PKGBUILD and comment the lines from 4.

10. Run makepkg and install the built package.

11. Finished!

If you want to publish your kernel package in AUR then you unfortunately need to revert the PKGBUILD from a split to a single package.

Greetings, Heiko

Or, you could just edit the kernel26-ice PKGBUILD and enable the /menuconfig/ variable so that it triggers menuconfig in the build() section, there you can either modify the configuration on the run or load an alternate config file; just be sure to save the edited config to /.conf/ig . Andrea

Ray Rashif writes:

In the latest kernel, there is 'make localmodconfig' for precisely this problem.

Thanks to all of you, I recorded everything so I'll try next time. By the way I had to mask the kernel26 build (even if I don't use it) because broadcom-wl is always a bit too late and it wouldn't work with the new kernel. Could I just tell arch that I want to use the other kernel instead??

On 01/02/10 22:11, Heiko Baums wrote:

Hi,

I had this issue only twice by now, but I think this is a general problem.

In the recent times libraries in the repos are only built dynamically while the statical versions are disabled.

This can lead to several problems if someone needs to compile a program and needs to link statically against a library. This is not possible with only dynamical libraries. So people are not able to compile their programs unless they rebuild the necessay libraries from ABS.

This is much worse with AUR packages which are compiled and installed by several other people.

This issue was at least in freetype2 and is now in libjpeg. In freetype2 this was fixed. I hope in libjpeg this will also be fixed.

See these feature requests: http://bugs.archlinux.org/task/11016 http://bugs.archlinux.org/task/18106

I could file such a feature request for every single package I find, but I think this should be a general rule to build libraries not only dynamically but also statically. This would avoid breakages of other packages even if AUR is unofficial and save time. And it doesn't take much disk space because it's usually only a small additional file.

I disagree. Static libraries generally suck and hide rebuilds needed for security issues. So unless something specifically needs the static library, I think it should be removed. Allan

On Mon, 2010-02-01 at 14:59 +0100, Heiko Baums wrote:

Am Mon, 01 Feb 2010 22:58:24 +1000 schrieb Allan McRae :

...

I disagree. Static libraries generally suck and hide rebuilds needed for security issues. So unless something specifically needs the static library, I think it should be removed.

Such rebuilds are only hidden if a program is linked statically against a library even if it can be linked dynamically, which should be avoided anyway. If a program is linked dynamically it doesn't touch the static library.

If a program is built static against an insecure library, upgrading the insecure library means the static binary is still vulnerable. That's what Allan means.

So if a dev, TU or AUR maintainer builds a package which depends on a library. This package should usually be linked dynamically against this library. In this case the static library isn't needed. But if such a package like fbsplash needs to be statically linked against a library it's only possible if the static version is available.

When we switch to glibc-based initramfs, there shouldn't be any need for static compiled binaries anymore, ever.

And other people who probably just want to write software for their own, who want to build a portable app or to learn programming or whatever and want or need to use statical linking can't do this without the static libraries.

Static binaries are everything but portable. Static linking to glibc can freak out when you're using nss_* libraries for uid and gid resolving.

And do you want everybody who needs the static version of a library for whatever reason to file a bug report for every single case and to explain why he needs this static version?

No, they shouldn't need those libraries.

That would take too much time while building a static library doesn't take much more time and disk space.

Static libraries are bad. Besides taking up diskspace, they're just bad to use. Ulrich Drepper has a nice PDF about this.

On Mon, Feb 1, 2010 at 12:06 PM, Heiko Baums wrote:

...

Static libraries are bad. Besides taking up diskspace, they're just bad to use. Ulrich Drepper has a nice PDF about this.

Do you have a link to this PDF?

http://people.redhat.com/drepper/no_static_linking.html Cf. http://sta.li/faq -- Andrew Antle <andrew dot antle at gmail dot com>

Am Mon, 1 Feb 2010 12:16:09 -0500 schrieb Andrew Antle :

...

...

Do you have a link to this PDF?

http://people.redhat.com/drepper/no_static_linking.html

Cf. http://sta.li/faq

http://people.redhat.com/drepper/dsohowto.pdf

Thanks for the links. Greetings, Heiko