https://bugzilla.novell.com/show_bug.cgi?id=271712 locilka@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|locilka@novell.com |bnc-team-screening@forge.provo.novell.com ------- Comment #2 from locilka@novell.com 2007-05-11 05:35 MST ------- 1.) The bug status is unclear because it hasn't been said how this had happened. Online Update? YaST System Update? Update via booting from CD/DVD? Adding a new source and using Software Installation module? 2.) I'm not responsible for ZYPP and evaluating which package is newer It seems YaST logs are actually needed. (/var/log/YaST2/ directory) -> back to screening team -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.

https://bugzilla.novell.com/show_bug.cgi?id=271712 chrubis@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO Info Provider| |ihudak@usoftinc.com ------- Comment #4 from chrubis@novell.com 2007-05-11 06:36 MST ------- Please attach y2logs. If you are in doubt follow: http://en.opensuse.org/Bugs/YaST Thanks! -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.

https://bugzilla.novell.com/show_bug.cgi?id=271712 ihudak@usoftinc.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW Info Provider|ihudak@usoftinc.com | ------- Comment #6 from ihudak@usoftinc.com 2007-05-11 07:47 MST ------- Created an attachment (id=139357) --> (https://bugzilla.novell.com/attachment.cgi?id=139357&action=view) YaST2 logs (part1 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.

https://bugzilla.novell.com/show_bug.cgi?id=271712 ------- Comment #8 from ihudak@usoftinc.com 2007-05-11 08:07 MST ------- (In reply to comment #2) YaST2 -> Software Management -> Search "kernel" Look at versions: Installed kernel was - 2.6.21_rc7 On installation DVD kernel was 2.6.21_rc5 On web kernel was 2.6.21.3 Installation source for kernel - http://ftp.opensuse.org/pub/opensuse/distribution/SL-OSS-factory/inst-source... rc5 and rc7 were newer then 2.6.21.3 in the versions list. YaST logs are attached. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.

https://bugzilla.novell.com/show_bug.cgi?id=271712 jkupec@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|yast2-maintainers@suse.de |ma@novell.com ------- Comment #9 from jkupec@novell.com 2007-05-11 12:18 MST ------- Indeed, given these two editions: Edition e1("2.6.21_rc7"); Edition e2("2.6.21-3"); expression (e1 > e2) evaluates to true (meaning _rc7 is newer than -3). So if such version strings are OK, then this needs to be dealt with in libzypp. Michael, you will know better. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.

https://bugzilla.novell.com/show_bug.cgi?id=271712#c12 --- Comment #12 from Jeff Mahoney 2007-06-19 09:30:54 MST --- Ok, so what's the solution here? The kernel can have a number of "official" version specs, like so, in order of "newer:" Major.Minor.Patch-rcX Major.Minor.Patch-rcX-gitY Major.Minor.Patch Major.Minor.Patch.StablePatch We can't truncate either the rc or git to just a number, due to the stable patch series using the fourth number legitimately. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=271712#c14 Jeff Mahoney changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |agruen@novell.com --- Comment #14 from Jeff Mahoney 2007-07-14 13:33:40 MST --- Will anything break horribly if we start naming kernels as follows: RELEASEMINOR=`echo $PRERELEASE_VERSION | tr - _` Major.Minor.Patch<.StablePatch>-Release.$RELEASEMINOR For example, we'd get 2.6.22-1.rc7_git3 rather than 2.6.22_rc7_git3-1 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=271712#c18 --- Comment #18 from Michael Schröder 2007-07-18 02:29:46 MST --- Too bad that rpm doesn't support '~' like debian does. 2.6.21~rc7 would be a good solution. Maybe we should implement it in our rpm and our solver, but then the people using other installers like smart would complain. Sigh. Adding the rc as a hint to the release number is not really supported, you could do that with a custom "get_release_number.sh" script in autobuild but it doesn't work in the build service. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=271712#c20 Michel Salim changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |michel.sylvan@gmail.com --- Comment #20 from Michel Salim 2007-08-18 12:03:21 MST --- Patching the build server so that it uses a different release number scheme for non-final vs. final packages would be nice. FYI, the Fedora convention is to start non-final versions with a 0, so in this case 0.rc7.1, 0.rc7.2, etc. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=271712#c22 Michael Schröder changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW Info Provider|mls@novell.com | --- Comment #22 from Michael Schröder 2007-10-30 15:48:40 MST --- Well, you can certainly define your own release number scheme in your build service project. E.g., adding 'Release: .rc2.' to the project configuration will create release with 'rc2' in the middle. Dunno if that would help in your case. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=271712#c24 Michael Schröder changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |coolo@novell.com AssignedTo|mls@novell.com |agruen@novell.com --- Comment #24 from Michael Schröder 2007-10-30 18:00:11 MST --- Well, I can easily implement it in our rpm and our solver, but other solvers like smart wouldn't understand it. I don't know if we really should do this. CC coolo for comments. And it would be only SL11.0/SLE11 or higher, there's no chance we can backport it to SLE10. I think Michel Salim's proposal was to move the 'rc' stuff into the release, i.e. convert '2.6.24_rc1-<release>' into '2.6.24-rc1.<release>', which would also work, as numbers are always newer than alphas. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=271712#c26 Andreas Gruenbacher changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO Info Provider| |ro@novell.com --- Comment #26 from Andreas Gruenbacher 2007-10-31 05:35:39 MST --- Comment 24: I agree about SLE10. We can continue playing tricks with the version. We could also try modifying the release number, but that could confuse Autobuild, because it may not know how to get from one arbitrary release number like 0.rcX.1 to the next. But these things are just ugly hacks, and if we could somehow define that 1.2.3~rc1 comes before 1.2.3, that would be much more obvious to users. We would nee to hack this into at least rpm, smart, zypper, libzypp, and perhaps in the SuSE any YUM metadata generators as well. I think the critical question is whether this approach will get support within the RPM maintainers. Comment 25: break in that context means tools which will get the package order wrong. So this more or less should belimited to tools for installing packages. Hacking the release number is a pretty crappy approach, but I expect most tools to implement rpm version comparisons correctly, so the only potential problem I'm aware of right now is with build environments (Autobuild, build service).

how about Release: rc1.0

That would work; even only incrementing the trailing numeric part without requiring a specific separator would do. We have the release number synchronization hack via kernel-dummy though; I don't think we can override the release number that kernel-dummy uses at the moment. Rudi, any ideas for that perhaps? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=271712#c28 Ruediger Oertel changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW Info Provider|ro@novell.com | --- Comment #28 from Ruediger Oertel 2007-11-28 10:40:15 MST --- for autobuild I can offer something in get_release_number.sh, no idea right now what's possible in the build service. added 3 parameter for get_release_number.sh: $1 BUILD_BASENAME (the distribution, e.g. 10.1-i386) $2 ORIG_RELEASE (the release-number the package would get without a get_release_number.sh) new: $3 PACKAGE_NAME so get_release_number.sh could look like: ------------------------------------------ case $3 in kernel-dummy) echo "RC3.$2" ;; *) echo "pkg: kernel-dummy" ;; esac ----------------------------------------- -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=271712 User jeffm@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=271712#c30 --- Comment #30 from Jeff Mahoney 2008-02-23 15:57:19 MST --- We're in -rc land again, so I'd like to revisit this and maybe even fix it permanently. Rudi, does that work for mbuild too? I have a get_release_number.sh.in that gets processed as part of tar-up.sh, but it looks like it gets ignored. For the current head kernel, the processed version looks like: #! /bin/sh case $3 in kernel-dummy) echo "0.rc2.git6.$2" ;; *) echo "pkg: kernel-dummy" ;; esac .. but I end up with kernel-default-2.6.25-4.$arch.rpm instead of kernel-default-2.6.25-0.rc2.git6.4.$arch.rpm as I expected. Michael, is it possible to use that trick in a spec file? Checking in an updated project.conf requires an extra step outside of the normal tar-up.sh process. I was hoping I could do something like this in the spec file: Version: @RPMVERSION@ %if 0%{?opensuse_bs} Release: @OBSRELEASE@ %else Release: 0 Where, processed for 2.6.25-rc2-git6, it would look like: Version: 2.6.25 %if 0%{?opensuse_bs} Release: 0.rc2.git6.. %else Release: 0 %endif When the builds are no longer based on release candidates, it would just evaluate to ., automatically generating a release major higher than 0. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=271712 User mls@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=271712#c32 --- Comment #32 from Michael Schröder 2008-02-25 04:19:19 MST --- Regarding CI_XXX: No, it doesn't work in a specfile. But it's an interesting idea for an enhancement. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=271712 User gregkh@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=271712#c34 --- Comment #34 from Greg Kroah-Hartman 2008-03-07 09:15:37 MST --- I do not think the fix is close, I would much rather have people start testing on the .25 kernel series than have to wait for this, that is much more important. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=271712 User jeffm@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=271712#c36 --- Comment #36 from Jeff Mahoney 2008-03-07 16:46:34 MST --- Created an attachment (id=199631) --> (https://bugzilla.novell.com/attachment.cgi?id=199631) Logfile.kernel-default.spec -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=271712 User jblunck@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=271712#c38 Jan Blunck changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jblunck@novell.com --- Comment #38 from Jan Blunck 2008-05-09 13:47:13 MST --- Grr, this is insane. For every update of a project, say Kernel:HEAD. all projects that link to that project need to update their configuration. So I won't be able to build customized kernels anymore. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=271712 User jblunck@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=271712#c40 --- Comment #40 from Jan Blunck 2008-05-15 09:16:05 MST --- I reverted the hunk from the previous comment. The former version actually works in the buildservice and is necessary since otherwise the package provides the "kernel = version-release" without the release prefix part. The fixes in the CVS are not based on a new workaround in the buildservice: if the Release: tag has the pattern <RELEASE> only this gets updated with . by the build script. The rest is left as it is. Since our internal Autobuild is completely replacing the Release: tag this work for both. Anyway I think is could only be a temporary fix since still kernel versions like 2.6.25-git2 are before 2.6.25 which isn't true. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.