[arch-general] Why taking so long?
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? Thanks
On 01/30/2010 07:11 AM, Andrea Crotti wrote:
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? Thanks
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
On Sat, Jan 30, 2010 at 07:13, pyther <pyther@pyther.net> 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.
Am Sat, 30 Jan 2010 13:11:26 +0100 schrieb Andrea Crotti <andrea.crotti.0@gmail.com>:
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
On 01/30/2010 01:37 PM, Heiko Baums wrote:
Am Sat, 30 Jan 2010 13:11:26 +0100 schrieb Andrea Crotti<andrea.crotti.0@gmail.com>:
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
On 31/01/2010, Andrea Fagiani <andfagiani@gmail.com> wrote:
On 01/30/2010 01:37 PM, Heiko Baums wrote:
Am Sat, 30 Jan 2010 13:11:26 +0100 schrieb Andrea Crotti<andrea.crotti.0@gmail.com>:
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
In the latest kernel, there is 'make localmodconfig' for precisely this problem. -- GPG/PGP ID: B42DDCAD
Ray Rashif <schivmeister@gmail.com> 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??
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. Greetings, Heiko
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
Am Mon, 01 Feb 2010 22:58:24 +1000 schrieb Allan McRae <allan@archlinux.org>:
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. 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. 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. 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? That would take too much time while building a static library doesn't take much more time and disk space. Greetings, Heiko
On Mon, 2010-02-01 at 14:59 +0100, Heiko Baums wrote:
Am Mon, 01 Feb 2010 22:58:24 +1000 schrieb Allan McRae <allan@archlinux.org>:
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.
Am Mon, 01 Feb 2010 15:14:27 +0100 schrieb Jan de Groot <jan@jgc.homeip.net>:
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.
Well, that's obvious.
When we switch to glibc-based initramfs, there shouldn't be any need for static compiled binaries anymore, ever.
Do you know, when this is planned? Nevertheless I don't think that this is always the choice of a package maintainer because if a software still requires statical libraries because upstream decides so like fbsplash then this hasn't much to do with the initramfs. I don't think that upstream cares much about an initramfs of a specific distro. But maybe I can ask spock to build a package without statical linking if this is possible in this case. But until then the static libraries are at least in some cases necessary.
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? Greetings, Heiko
On Mon, Feb 1, 2010 at 12:06 PM, Heiko Baums <lists@baums-on-web.de> 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>
Do you have a link to this PDF?
http://people.redhat.com/drepper/dsohowto.pdf -- Andrew Antle <andrew dot antle at gmail dot com>
Am Mon, 1 Feb 2010 12:16:09 -0500 schrieb Andrew Antle <andrew.antle@gmail.com>:
Do you have a link to this PDF?
Thanks for the links. Greetings, Heiko
On Mon, Feb 1, 2010 at 12:35 PM, Heiko Baums <lists@baums-on-web.de> wrote:
Am Mon, 1 Feb 2010 12:16:09 -0500 schrieb Andrew Antle <andrew.antle@gmail.com>:
Do you have a link to this PDF?
Thanks for the links.
No problem, Heiko. Cheers, Andrew
participants (9)
-
Allan McRae
-
Andrea Crotti
-
Andrea Fagiani
-
Andrew Antle
-
Daenyth Blank
-
Heiko Baums
-
Jan de Groot
-
pyther
-
Ray Rashif