[arch-dev-public] [signoff] kernel26 2.6.27.9-1
Hi guys, new kernel adresses the following things: - bump to latest version please signoff for both arches, greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
Tobias Powalowski wrote:
Hi guys, new kernel adresses the following things: - bump to latest version
please signoff for both arches,
greetings tpowa
Hours using it, done everything I normally do, and all is fine. signoff i686
Am Sonntag 14 Dezember 2008 22:11:26 schrieb Tobias Powalowski:
Hi guys, new kernel adresses the following things: - bump to latest version
please signoff for both arches,
greetings tpowa
Are you sure those files should be in the package: kernel26: /lib/modules/2.6.27-ARCH/modules.alias.bin existiert im Dateisystem kernel26: /lib/modules/2.6.27-ARCH/modules.dep.bin existiert im Dateisystem kernel26: /lib/modules/2.6.27-ARCH/modules.symbols.bin existiert im Dateisystem -- Pierre Schmitz Clemens-August-Straße 76 53115 Bonn Telefon 0228 9716608 Mobil 0160 95269831 Jabber pierre@jabber.archlinux.de WWW http://www.archlinux.de
Am Sonntag 14 Dezember 2008 22:11:26 schrieb Tobias Powalowski:
Hi guys, new kernel adresses the following things: - bump to latest version
please signoff for both arches,
greetings tpowa
Are you sure those files should be in the package:
kernel26: /lib/modules/2.6.27-ARCH/modules.alias.bin existiert im Dateisystem kernel26: /lib/modules/2.6.27-ARCH/modules.dep.bin existiert im Dateisystem kernel26: /lib/modules/2.6.27-ARCH/modules.symbols.bin existiert im Dateisystem
Am Montag 15 Dezember 2008 schrieb Pierre Schmitz: hrm you are right those files are new. Which package do your files belong, which already exist? greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
Tobias Powalowski wrote:
Am Montag 15 Dezember 2008 schrieb Pierre Schmitz:
Am Sonntag 14 Dezember 2008 22:11:26 schrieb Tobias Powalowski:
Hi guys, new kernel adresses the following things: - bump to latest version
please signoff for both arches,
greetings tpowa
Are you sure those files should be in the package:
kernel26: /lib/modules/2.6.27-ARCH/modules.alias.bin existiert im Dateisystem kernel26: /lib/modules/2.6.27-ARCH/modules.dep.bin existiert im Dateisystem kernel26: /lib/modules/2.6.27-ARCH/modules.symbols.bin existiert im Dateisystem
hrm you are right those files are new. Which package do your files belong, which already exist?
greetings tpowa
No package owns them. They're being produced by depmod since the 3.5 update of module-init-tools. I could be wrong, but I think the kernel is the only package that calls depmod in the build function - other packages that need depmod call it in post_install, which is why these files are not owned.
Tom K schrieb:
No package owns them. They're being produced by depmod since the 3.5 update of module-init-tools.
I could be wrong, but I think the kernel is the only package that calls depmod in the build function - other packages that need depmod call it in post_install, which is why these files are not owned.
That is okay. We call depmod in the PKGBUILD so kernel26 will own those files and they will be properly uninstalled when the kernel is removed or updated. After the m-i-t 3.5 update, those .bin files were generated on your system, but were not contained in the kernel package yet. The new package is generated with the new m-i-t, thus contains them. We have to force-upgrade that one so pacman will again be able to track those files and delete them when appropriate.
Am Montag 15 Dezember 2008 schrieb Thomas Bächler:
Tom K schrieb:
No package owns them. They're being produced by depmod since the 3.5 update of module-init-tools.
I could be wrong, but I think the kernel is the only package that calls depmod in the build function - other packages that need depmod call it in post_install, which is why these files are not owned.
That is okay. We call depmod in the PKGBUILD so kernel26 will own those files and they will be properly uninstalled when the kernel is removed or updated.
After the m-i-t 3.5 update, those .bin files were generated on your system, but were not contained in the kernel package yet. The new package is generated with the new m-i-t, thus contains them. We have to force-upgrade that one so pacman will again be able to track those files and delete them when appropriate. Are you guys fine with moving kernel package to core, with this possible file conflict and make a announcement that forcing is ok?
greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
On Mon, Dec 15, 2008 at 1:32 PM, Tobias Powalowski <t.powa@gmx.de> wrote:
Am Montag 15 Dezember 2008 schrieb Thomas Bächler:
Tom K schrieb:
No package owns them. They're being produced by depmod since the 3.5 update of module-init-tools.
I could be wrong, but I think the kernel is the only package that calls depmod in the build function - other packages that need depmod call it in post_install, which is why these files are not owned.
That is okay. We call depmod in the PKGBUILD so kernel26 will own those files and they will be properly uninstalled when the kernel is removed or updated.
After the m-i-t 3.5 update, those .bin files were generated on your system, but were not contained in the kernel package yet. The new package is generated with the new m-i-t, thus contains them. We have to force-upgrade that one so pacman will again be able to track those files and delete them when appropriate. Are you guys fine with moving kernel package to core, with this possible file conflict and make a announcement that forcing is ok?
Yeah, just make sure we indicate that users should -Sf kernel26, not -Sfyu, which would be a poor recommendation on our part.
Aaron Griffin wrote:
On Mon, Dec 15, 2008 at 1:32 PM, Tobias Powalowski <t.powa@gmx.de> wrote:
Am Montag 15 Dezember 2008 schrieb Thomas Bächler:
Tom K schrieb:
No package owns them. They're being produced by depmod since the 3.5 update of module-init-tools.
I could be wrong, but I think the kernel is the only package that calls depmod in the build function - other packages that need depmod call it in post_install, which is why these files are not owned. That is okay. We call depmod in the PKGBUILD so kernel26 will own those files and they will be properly uninstalled when the kernel is removed or updated.
After the m-i-t 3.5 update, those .bin files were generated on your system, but were not contained in the kernel package yet. The new package is generated with the new m-i-t, thus contains them. We have to force-upgrade that one so pacman will again be able to track those files and delete them when appropriate. Are you guys fine with moving kernel package to core, with this possible file conflict and make a announcement that forcing is ok?
Yeah, just make sure we indicate that users should -Sf kernel26, not -Sfyu, which would be a poor recommendation on our part.
Why not solve it the right way, by creating a correct package? Glenn
On Mon, Dec 15, 2008 at 2:41 PM, RedShift <redshift@pandora.be> wrote:
Why not solve it the right way, by creating a correct package?
I think you're missing why this is impossible. Anyone that has m-i-t 3.5 on their system now has the .bin files that are owned by no package. pacman correctly does not overwrite these files. What "correct package" are you suggesting?
Aaron Griffin wrote:
On Mon, Dec 15, 2008 at 2:41 PM, RedShift <redshift@pandora.be> wrote:
Why not solve it the right way, by creating a correct package?
I think you're missing why this is impossible. Anyone that has m-i-t 3.5 on their system now has the .bin files that are owned by no package. pacman correctly does not overwrite these files.
What "correct package" are you suggesting?
Yeah I was missing why this is impossible, I thought tpowa was including some files by accident and opted to forgo the whole build upload signoff release cycle for this minor change. But I wasn't fully understanding what was going on with module-init-tools untill I re-read the thread, so you can ignore me. My bad. Glenn
On Mon, 2008-12-15 at 14:42 -0600, Aaron Griffin wrote:
On Mon, Dec 15, 2008 at 2:41 PM, RedShift <redshift@pandora.be> wrote:
Why not solve it the right way, by creating a correct package?
I think you're missing why this is impossible. Anyone that has m-i-t 3.5 on their system now has the .bin files that are owned by no package. pacman correctly does not overwrite these files.
What "correct package" are you suggesting?
As these files are generated by module-init-tools whenever it is run for your kernel, why not solve this using post_* functions? Whenever the kernel gets installed/upgraded, depmod is run from post_install/upgrade. Whenever the kernel is removed, the files created by depmod for this kernel get removed from post_remove. Shouldn't be hard to do, the result is the same and no file conflicts will exist. BTW: Please remove the -v flag from depmod in kernel26.install, it's stupid to make depmod print verbose messages while redirecting output to /dev/null.
Am Dienstag 16 Dezember 2008 schrieb Jan de Groot:
On Mon, 2008-12-15 at 14:42 -0600, Aaron Griffin wrote:
On Mon, Dec 15, 2008 at 2:41 PM, RedShift <redshift@pandora.be> wrote:
Why not solve it the right way, by creating a correct package?
I think you're missing why this is impossible. Anyone that has m-i-t 3.5 on their system now has the .bin files that are owned by no package. pacman correctly does not overwrite these files.
What "correct package" are you suggesting?
As these files are generated by module-init-tools whenever it is run for your kernel, why not solve this using post_* functions? Whenever the kernel gets installed/upgraded, depmod is run from post_install/upgrade. Whenever the kernel is removed, the files created by depmod for this kernel get removed from post_remove. Shouldn't be hard to do, the result is the same and no file conflicts will exist. Well depmod is already called in .install file. Why to make a remove in PKGBUILD and create untraced files on the system? This bug affects only people who run testing and installed new external modules. This should be not a big part of the community, mostly noone runs testing ;)
BTW: Please remove the -v flag from depmod in kernel26.install, it's stupid to make depmod print verbose messages while redirecting output to /dev/null. fixed
Before releasing .10 kernel I would like to have a clear answer on how to handle this. My suggestion would be the --force option, the other thing is a workaround which is imho not needed here. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
On Sun, 2008-12-21 at 09:48 +0100, Tobias Powalowski wrote:
Am Dienstag 16 Dezember 2008 schrieb Jan de Groot:
On Mon, 2008-12-15 at 14:42 -0600, Aaron Griffin wrote:
On Mon, Dec 15, 2008 at 2:41 PM, RedShift <redshift@pandora.be> wrote:
Why not solve it the right way, by creating a correct package?
I think you're missing why this is impossible. Anyone that has m-i-t 3.5 on their system now has the .bin files that are owned by no package. pacman correctly does not overwrite these files.
What "correct package" are you suggesting?
As these files are generated by module-init-tools whenever it is run for your kernel, why not solve this using post_* functions? Whenever the kernel gets installed/upgraded, depmod is run from post_install/upgrade. Whenever the kernel is removed, the files created by depmod for this kernel get removed from post_remove. Shouldn't be hard to do, the result is the same and no file conflicts will exist. Well depmod is already called in .install file. Why to make a remove in PKGBUILD and create untraced files on the system? This bug affects only people who run testing and installed new external modules. This should be not a big part of the community, mostly noone runs testing ;)
BTW: Please remove the -v flag from depmod in kernel26.install, it's stupid to make depmod print verbose messages while redirecting output to /dev/null. fixed
Before releasing .10 kernel I would like to have a clear answer on how to handle this. My suggestion would be the --force option, the other thing is a workaround which is imho not needed here.
If someone runs testing, they better be able to figure out "pacman -Sf kernel26", especially if we make posts about it. I'm anxious for 2.6.27.10, it's supposed to fix my hibernate regression. Dale
participants (9)
-
Aaron Griffin
-
Dale Blount
-
Eduardo Romero
-
Jan de Groot
-
Pierre Schmitz
-
RedShift
-
Thomas Bächler
-
Tobias Powalowski
-
Tom K