Okay, here''s the first draft of spec changes to alter the kernel rpm version and release fields to more closely match what the actual upstream kernel base is. Its heavily commented at the moment to try to explain what''s going on. The basic approach is this: 1st fedora build of 2.6.21.5: kernel-2.6.21.5-1.fc7 2nd fedora build of 2.6.21.5: kernel-2.6.21.5-2.fc7 1st fedora build of 2.6.22-rc6-git3: kernel-2.6.22-0.rc6.git3.1.fc8 2nd fedora build of 2.6.22-rc7: kernel-2.6.22-0.rc7.2.fc8 ...and so on. Added bonus on rc/git builds: you set the rc and git revisions near the top of the spec, and the needed patches are automagically generated in the right place. At least from spectool''s point of view, I''ve got this working perfectly from the generated n-v-r standpoint for all of the above combos and then some. A test build of kernel-2.6.22-0.rc7.1.fc8 just finished building with one error, which I''ve traced the source of -- debug files come from the source tree, which is still versioned with the base kernel version. This should be fixed in the attached diff, but the build is still underway to verify that. Regardless of that, I''d like some feedback before going much further down the current path. Everything between "hey, that looks good!" and "what in the blue hell are you thinking?" welcomed. :) (Even better if you have suggestions for improvement). -- Jarod Wilson jwilson@redhat.com
I think this is what will fix the kernel-vanilla-debuginfo-common problem.
--- kernel-2.6.spec 2 Jul 2007 17:07:41 -0000 1.3245
+++ kernel-2.6.spec 2 Jul 2007 20:28:13 -0000
@@ -1473,10 +1477,10 @@ BuildKernel %make_target %kernel_image k
%global __debug_package 1
%files debuginfo-common
%defattr(-,root,root)
-/usr/src/debug/%{name}-%{version}/linux-%{kversion}.%{_target_cpu}
+/usr/src/debug/kernel-%{version}/linux-%{kversion}.%{_target_cpu}
%if %{includexen}
%if %{with_xen}
-/usr/src/debug/%{name}-%{version}/xen
+/usr/src/debug/kernel-%{version}/xen
%endif
%endif
%dir /usr/src/debug
What about before the first -rcN tag?
Roland McGrath wrote:> I think this is what will fix the kernel-vanilla-debuginfo-common problem. > > --- kernel-2.6.spec 2 Jul 2007 17:07:41 -0000 1.3245 > +++ kernel-2.6.spec 2 Jul 2007 20:28:13 -0000 > @@ -1473,10 +1477,10 @@ BuildKernel %make_target %kernel_image k > %global __debug_package 1 > %files debuginfo-common > %defattr(-,root,root) > -/usr/src/debug/%{name}-%{version}/linux-%{kversion}.%{_target_cpu} > +/usr/src/debug/kernel-%{version}/linux-%{kversion}.%{_target_cpu} > %if %{includexen} > %if %{with_xen} > -/usr/src/debug/%{name}-%{version}/xen > +/usr/src/debug/kernel-%{version}/xen > %endif > %endif > %dir /usr/src/debugYup, same conclusion I came to. -- Jarod Wilson jwilson@redhat.com
Roland McGrath wrote:> What about before the first -rcN tag?I presume you''re referring to the likes of say kernel 2.6.21-gitX, which was post-2.6.21, but pre-2.6.22-rc1? Crap. Hadn''t thought about that case. Okay, will have to do some further twiddling to cover that case... -- Jarod Wilson jwilson@redhat.com
> I presume you''re referring to the likes of say kernel 2.6.21-gitX, which > was post-2.6.21, but pre-2.6.22-rc1? Crap. Hadn''t thought about that > case. Okay, will have to do some further twiddling to cover that case...Yes, that''s what I meant. Faking it as "rc0" might be the easiest thing to keep the scheme''s release numbers increasing.
Roland McGrath wrote:>> I presume you''re referring to the likes of say kernel 2.6.21-gitX, which >> was post-2.6.21, but pre-2.6.22-rc1? Crap. Hadn''t thought about that >> case. Okay, will have to do some further twiddling to cover that case... > > Yes, that''s what I meant. Faking it as "rc0" might be the easiest thing to > keep the scheme''s release numbers increasing.It winds up being a touch out of phase with reality, since 2.6.21-git1 ends up being called 2.6.22-rc0-git1, but the updated attached patch does account for this case now in that fashion. If we call it anything else, its out of N-V-R order. Ughlay, but still much closer than we''ve been, and outside of that window, it should be spot-on to see what exactly we''re packaging. Oh, and this version does result in a fully-completed rpm build (also has the kernel-vanilla fix). -- Jarod Wilson jwilson@redhat.com
Roland McGrath wrote:> What''s Patch5?D''oh. Meant to nuke that. Inserted for testing purposes -- ''spectool kernel-2.6.spec -p 5 -d "somemacro value"'' to verify expected N-V-R''s being set properly. Disregard the -v2 patch, use this guy instead. :) (or just drop the Patch5 line out of the resulting spec). -- Jarod Wilson jwilson@redhat.com
Jarod Wilson wrote:> Roland McGrath wrote: >> What''s Patch5? > > D''oh. Meant to nuke that. Inserted for testing purposes -- ''spectool > kernel-2.6.spec -p 5 -d "somemacro value"'' to verify expected N-V-R''s > being set properly. Disregard the -v2 patch, use this guy instead. :) > (or just drop the Patch5 line out of the resulting spec).At davej''s behest, went ahead and checked this version in, and started up a build in koji. Keeping an eye on the build (http://koji.fedoraproject.org/koji/taskinfo?taskID=55435) so as to fix any possible breakage asap. One buglet with make prep already found and fixed, yell loudly if anything else crops up. Otherwise, looking good so far, koji is starting in on building binaries now... -- Jarod Wilson jwilson@redhat.com
On Tue, Jul 03, 2007 at 11:56:27AM -0400, Jarod Wilson wrote:
> Jarod Wilson wrote:
> > Roland McGrath wrote:
> >> What''s Patch5?
> >
> > D''oh. Meant to nuke that. Inserted for testing purposes --
''spectool
> > kernel-2.6.spec -p 5 -d "somemacro value"'' to
verify expected N-V-R''s
> > being set properly. Disregard the -v2 patch, use this guy instead. :)
> > (or just drop the Patch5 line out of the resulting spec).
>
> At davej''s behest, went ahead and checked this version in, and
started
> up a build in koji. Keeping an eye on the build
> (http://koji.fedoraproject.org/koji/taskinfo?taskID=55435) so as to fix
> any possible breakage asap. One buglet with make prep already found and
> fixed, yell loudly if anything else crops up.
>
> Otherwise, looking good so far, koji is starting in on building binaries
> now...
Ick...
$ rpmvercmp kernel-2.6.22-0.rc7.git1.2.fc8 kernel-2.6.22-0.rc7.2.fc8
name: kernel = kernel
verson: 2.6.22 = 2.6.22
release: 0.rc7.git1.2.fc8 < 0.rc7.2.fc8
kernel-2.6.22-0.rc7.git1.2.fc8 < kernel-2.6.22-0.rc7.2.fc8
Dave
--
http://www.codemonkey.org.uk
On Tue, 2007-07-03 at 12:33 -0400, Dave Jones wrote:> On Tue, Jul 03, 2007 at 11:56:27AM -0400, Jarod Wilson wrote: > > Jarod Wilson wrote: > > > Roland McGrath wrote: > > >> What''s Patch5? > > > > > > D''oh. Meant to nuke that. Inserted for testing purposes -- ''spectool > > > kernel-2.6.spec -p 5 -d "somemacro value"'' to verify expected N-V-R''s > > > being set properly. Disregard the -v2 patch, use this guy instead. :) > > > (or just drop the Patch5 line out of the resulting spec). > > > > At davej''s behest, went ahead and checked this version in, and started > > up a build in koji. Keeping an eye on the build > > (http://koji.fedoraproject.org/koji/taskinfo?taskID=55435) so as to fix > > any possible breakage asap. One buglet with make prep already found and > > fixed, yell loudly if anything else crops up. > > > > Otherwise, looking good so far, koji is starting in on building binaries > > now... > > Ick... > > $ rpmvercmp kernel-2.6.22-0.rc7.git1.2.fc8 kernel-2.6.22-0.rc7.2.fc8 > name: kernel = kernel > verson: 2.6.22 = 2.6.22 > release: 0.rc7.git1.2.fc8 < 0.rc7.2.fc8 > kernel-2.6.22-0.rc7.git1.2.fc8 < kernel-2.6.22-0.rc7.2.fc8This is why Fedora adopted the pre-release versioning scheme that we did: http://fedoraproject.org/wiki/Packaging/NamingGuidelines#PreReleasePackages In the Fedora scheme, this would be 0.%{X}.%{alphatag} Or, in your specific example: kernel-2.6.22-0.2.rc7.git1.fc8 vs kernel-2.6.22-0.1.rc7.fc8 [root@dhcp-32-74 ~]# /usr/bin/fedora-rpmvercmp Epoch1 :0 Version1 :2.6.22 Release1 :0.2.rc7.git1.fc8 Epoch2 :0 Version2 :2.6.22 Release2 :0.1.rc7.fc8 0:2.6.22-0.2.rc7.git1.fc8 is newer Note that for this to work, you need to increment %{X} upon every new package. ~spot
On Tue, Jul 03, 2007 at 11:47:18AM -0500, Tom spot Callaway wrote:
> This is why Fedora adopted the pre-release versioning scheme that we
> did:
>
>
http://fedoraproject.org/wiki/Packaging/NamingGuidelines#PreReleasePackages
>
> In the Fedora scheme, this would be
>
> 0.%{X}.%{alphatag}
>
> Or, in your specific example:
>
> kernel-2.6.22-0.2.rc7.git1.fc8 vs kernel-2.6.22-0.1.rc7.fc8
Ok, that looks fixable by doing this..
Jarod, want to give this a quick once-over?
Index: kernel-2.6.spec
==================================================================RCS file:
/cvs/pkgs/rpms/kernel/devel/kernel-2.6.spec,v
retrieving revision 1.3257
diff -u -p -r1.3257 kernel-2.6.spec
--- kernel-2.6.spec 3 Jul 2007 16:45:36 -0000 1.3257
+++ kernel-2.6.spec 3 Jul 2007 18:45:22 -0000
@@ -15,7 +15,7 @@ Summary: The Linux kernel (the core of t
# fedora_build defines which build revision of this kernel version
we''re building. In the
# non-kernel world, this is analogous to the Release: field, and is formatted
similarly.
-%define fedora_build 2%{?dist}
+%define fedora_build 2
# base_sublevel is the kernel version we''re starting with and patching
# on top of -- for example, 2.6.22-rc7-git1 starts with a 2.6.21 base,
@@ -107,7 +107,7 @@ Summary: The Linux kernel (the core of t
# pkg_release is what we''ll fill in for the rpm Release: field
%if %{released_kernel}
-%define pkg_release %{fedora_build}%{?buildid}
+%define pkg_release %{fedora_build}%{?dist}%{?buildid}
%else
%if 0%{?rcrev}
%define rctag .rc%rcrev
@@ -118,7 +118,7 @@ Summary: The Linux kernel (the core of t
%define rctag .rc0
%endif
%endif
-%define pkg_release 0%{?rctag}%{?gittag}.%{fedora_build}%{?buildid}
+%define pkg_release 0.%{fedora_build}%{?buildid}%{?rctag}%{?gittag}%{?dist}
%endif
# The kernel tarball/base version
> Note that for this to work, you need to increment %{X} upon every new
> package.
It''s non-obvious to me what %{?buildid} is, but it seems to
auto-increment.
Dave
--
http://www.codemonkey.org.uk
> It''s non-obvious to me what %{?buildid} is, but it seems to > auto-increment.buildid is the "please set this to .me" one. fedora_build is the one to bump on commit.
On Tue, Jul 03, 2007 at 11:52:00AM -0700, Roland McGrath wrote:> > It''s non-obvious to me what %{?buildid} is, but it seems to > > auto-increment. > > buildid is the "please set this to .me" one. > fedora_build is the one to bump on commit.Can''t %{fedora_build} be set based on the $Revision$ keyword, to be incremented automatically on commit, just like %{specrelease} was auto-incremeted previously? -- Eduardo
On Tue, Jul 03, 2007 at 03:56:45PM -0300, Eduardo Habkost wrote:
> On Tue, Jul 03, 2007 at 11:52:00AM -0700, Roland McGrath wrote:
> > > It''s non-obvious to me what %{?buildid} is, but it
seems to
> > > auto-increment.
> >
> > buildid is the "please set this to .me" one.
> > fedora_build is the one to bump on commit.
>
> Can''t %{fedora_build} be set based on the $Revision$ keyword, to
be
> incremented automatically on commit, just like %{specrelease} was
> auto-incremeted previously?
Yes, it can. With..
%define fedora_build %(R="$Revision: 1.3125 $"; RR="${R##:
}"; echo %${RR%%?} | sed s/1\.//)
Which would yield..
kernel-2.6.22-0.3125.rc7.fc8
Dave
--
http://www.codemonkey.org.uk
Dave Jones wrote:> On Tue, Jul 03, 2007 at 11:47:18AM -0500, Tom spot Callaway wrote: > > > This is why Fedora adopted the pre-release versioning scheme that we > > did: > > > > http://fedoraproject.org/wiki/Packaging/NamingGuidelines#PreReleasePackages > > > > In the Fedora scheme, this would be > > > > 0.%{X}.%{alphatag} > > > > Or, in your specific example: > > > > kernel-2.6.22-0.2.rc7.git1.fc8 vs kernel-2.6.22-0.1.rc7.fc8 > > Ok, that looks fixable by doing this..Damn, I looked at that particular case and everything was just fine with it in my head... Stupid head.> Jarod, want to give this a quick once-over?Yup.> Index: kernel-2.6.spec > ==================================================================> RCS file: /cvs/pkgs/rpms/kernel/devel/kernel-2.6.spec,v > retrieving revision 1.3257 > diff -u -p -r1.3257 kernel-2.6.spec > --- kernel-2.6.spec 3 Jul 2007 16:45:36 -0000 1.3257 > +++ kernel-2.6.spec 3 Jul 2007 18:45:22 -0000 > @@ -15,7 +15,7 @@ Summary: The Linux kernel (the core of t > > # fedora_build defines which build revision of this kernel version we''re building. In the > # non-kernel world, this is analogous to the Release: field, and is formatted similarly. > -%define fedora_build 2%{?dist} > +%define fedora_build 2I might change the comment here slightly, since w/o %{?dist} right there, its not quite the same as Release: anymore, but that''s neither here nor there for actually fixing the problem... :)> # base_sublevel is the kernel version we''re starting with and patching > # on top of -- for example, 2.6.22-rc7-git1 starts with a 2.6.21 base, > @@ -107,7 +107,7 @@ Summary: The Linux kernel (the core of t > > # pkg_release is what we''ll fill in for the rpm Release: field > %if %{released_kernel} > -%define pkg_release %{fedora_build}%{?buildid} > +%define pkg_release %{fedora_build}%{?dist}%{?buildid} > %else > %if 0%{?rcrev} > %define rctag .rc%rcrev > @@ -118,7 +118,7 @@ Summary: The Linux kernel (the core of t > %define rctag .rc0 > %endif > %endif > -%define pkg_release 0%{?rctag}%{?gittag}.%{fedora_build}%{?buildid} > +%define pkg_release 0.%{fedora_build}%{?buildid}%{?rctag}%{?gittag}%{?dist} > %endif > > # The kernel tarball/base version > > > Note that for this to work, you need to increment %{X} upon every new > > package. > > It''s non-obvious to me what %{?buildid} is, but it seems to > auto-increment.The %buildid is for one-off builds, there''s a blurb at the top of the spec where we request people to set it for their own custom builds for identifying non-official kernels. Never set in official fedora builds. The order of it in pkg_release probably doesn''t matter too much, though I personally like it at the very end. Otherwise, the changes look fine to me. The other crazy idea I had was to call 2.6.22-rc7 2.6.22-0.rc7.git0.1.fc8. Making fedora_build auto-increment is probably cleaner, though it''d be nice to also have it reset on a kernel major version rebase (either manually or automagically). -- Jarod Wilson jwilson@redhat.com
On Tue, Jul 03, 2007 at 03:01:16PM -0400, Jarod Wilson wrote: <snip>> > The other crazy idea I had was to call 2.6.22-rc7 > 2.6.22-0.rc7.git0.1.fc8. Making fedora_build auto-increment is probably > cleaner, though it''d be nice to also have it reset on a kernel major > version rebase (either manually or automagically).I was going to propose something similar[1], but the proposal of using 0.%{fedora_build}.rc7 sounded much better to me and I dropped it before sending to the list. [1] My idea was using something like this: 2.6.22-rc7 => kernel-2.6.22-0.rc7.0.%{something else} 2.6.22-rc7-git1 => kernel-2.6.22-0.rc7.1.git1.%{something else} 2.6.22 => kernel-2.6.22-%{something else} -- Eduardo
> On Tue, Jul 03, 2007 at 03:56:45PM -0300, Eduardo Habkost wrote: > > On Tue, Jul 03, 2007 at 11:52:00AM -0700, Roland McGrath wrote: > > > > It''s non-obvious to me what %{?buildid} is, but it seems to > > > > auto-increment. > > > > > > buildid is the "please set this to .me" one. > > > fedora_build is the one to bump on commit. > > > > Can''t %{fedora_build} be set based on the $Revision$ keyword, to be > > incremented automatically on commit, just like %{specrelease} was > > auto-incremeted previously? > > Yes, it can. With.. > > %define fedora_build %(R="$Revision: 1.3125 $"; RR="${R##: }"; echo %${RR%%?} | sed s/1\.//) > > Which would yield.. > > kernel-2.6.22-0.3125.rc7.fc8%define fedora_cvs_origin 3120 %define fedora_build %(R="$Revision: 1.3125 $"; R="${R%% \$}"; R="${R##: 1.}"; expr $R - %{fedora_cvs_origin}) Change fedora_cvs_origin to current $Revision$ s/1.// when you change sublevel.
On Tue, Jul 03, 2007 at 12:26:06PM -0700, Roland McGrath wrote:
> > On Tue, Jul 03, 2007 at 03:56:45PM -0300, Eduardo Habkost wrote:
> > > On Tue, Jul 03, 2007 at 11:52:00AM -0700, Roland McGrath wrote:
> > > > > It''s non-obvious to me what %{?buildid} is,
but it seems to
> > > > > auto-increment.
> > > >
> > > > buildid is the "please set this to .me" one.
> > > > fedora_build is the one to bump on commit.
> > >
> > > Can''t %{fedora_build} be set based on the $Revision$
keyword, to be
> > > incremented automatically on commit, just like %{specrelease}
was
> > > auto-incremeted previously?
> >
> > Yes, it can. With..
> >
> > %define fedora_build %(R="$Revision: 1.3125 $";
RR="${R##: }"; echo %${RR%%?} | sed s/1\.//)
> >
> > Which would yield..
> >
> > kernel-2.6.22-0.3125.rc7.fc8
>
> %define fedora_cvs_origin 3120
> %define fedora_build %(R="$Revision: 1.3125 $"; R="${R%%
\$}"; R="${R##: 1.}"; expr $R - %{fedora_cvs_origin})
>
> Change fedora_cvs_origin to current $Revision$ s/1.// when you change
sublevel.
I''m guessing the idea here is that it starts counting from 0 again each
time we rebase? Sounds admirable, but it doesn''t seem to work when I
try it with your change.
Dave
--
http://www.codemonkey.org.uk
On Tue, Jul 03, 2007 at 03:32:51PM -0400, Dave Jones wrote:
> On Tue, Jul 03, 2007 at 12:26:06PM -0700, Roland McGrath wrote:
> > > On Tue, Jul 03, 2007 at 03:56:45PM -0300, Eduardo Habkost
wrote:
> > > > On Tue, Jul 03, 2007 at 11:52:00AM -0700, Roland McGrath
wrote:
> > > > > > It''s non-obvious to me what
%{?buildid} is, but it seems to
> > > > > > auto-increment.
> > > > >
> > > > > buildid is the "please set this to .me"
one.
> > > > > fedora_build is the one to bump on commit.
> > > >
> > > > Can''t %{fedora_build} be set based on the
$Revision$ keyword, to be
> > > > incremented automatically on commit, just like
%{specrelease} was
> > > > auto-incremeted previously?
> > >
> > > Yes, it can. With..
> > >
> > > %define fedora_build %(R="$Revision: 1.3125 $";
RR="${R##: }"; echo %${RR%%?} | sed s/1\.//)
> > >
> > > Which would yield..
> > >
> > > kernel-2.6.22-0.3125.rc7.fc8
> >
> > %define fedora_cvs_origin 3120
> > %define fedora_build %(R="$Revision: 1.3125 $";
R="${R%% \$}"; R="${R##: 1.}"; expr $R -
%{fedora_cvs_origin})
> >
> > Change fedora_cvs_origin to current $Revision$ s/1.// when you
change sublevel.
>
> I''m guessing the idea here is that it starts counting from 0
again each
> time we rebase? Sounds admirable, but it doesn''t seem to work
when I
> try it with your change.
never mind, I got bitten by the ''thou shalt not comment out macros with
#''
bug yet again. I committed this change, thanks.
Dave
--
http://www.codemonkey.org.uk
> On Tue, Jul 03, 2007 at 03:01:16PM -0400, Jarod Wilson wrote: > <snip> >> The other crazy idea I had was to call 2.6.22-rc7 >> 2.6.22-0.rc7.git0.1.fc8. Making fedora_build auto-increment is probably >> cleaner, though it''d be nice to also have it reset on a kernel major >> version rebase (either manually or automagically). >=20 >=20 > I was going to propose something similar[1], but the proposal of using > 0.%{fedora_build}.rc7 sounded much better to me and I dropped it > before sending to the list. >=20 >=20 > [1] My idea was using something like this: >=20 > 2.6.22-rc7 =3D> kernel-2.6.22-0.rc7.0.%{something else} > 2.6.22-rc7-git1 =3D> kernel-2.6.22-0.rc7.1.git1.%{something else} > 2.6.22 =3D> kernel-2.6.22-%{something else} >=20Well, we''ve already done something to address this, but for giggles, I''ll throw out one more idea that would have worked: 2.6.22-0.rc7.1.fc8 < 2.6.22-0.rc7_git2.1.fc8 But eh. What''s there now worksforme, and it actually lines up better with the official fedora packaging guidelines (we''ll just ignore the bazillion other things the kernel spec does that don''t ;). /me heads out the door for a mini-vacation, back Saturday... --=20 Jarod Wilson jwilson@redhat.com
On Mon, Jul 02, 2007 at 04:22:24PM -0400, Jarod Wilson wrote:> Okay, here''s the first draft of spec changes to alter the kernel rpm > version and release fields to more closely match what the actual > upstream kernel base is. Its heavily commented at the moment to try to > explain what''s going on. > > The basic approach is this: > > 1st fedora build of 2.6.21.5: > kernel-2.6.21.5-1.fc7 > > 2nd fedora build of 2.6.21.5: > kernel-2.6.21.5-2.fc7 > > 1st fedora build of 2.6.22-rc6-git3: > kernel-2.6.22-0.rc6.git3.1.fc8 > > 2nd fedora build of 2.6.22-rc7: > kernel-2.6.22-0.rc7.2.fc8I''d suggest kernel-2.6.22-1.rc6.git3.fc8 kernel-2.6.22-2.rc7.fc8 an no resetting of the buildtag (the first integer) when rc6 becomes rc7 and the like o The shove-the-zero-in-front method is a method from the past when a third party would assume the vendor to start using Release tags starting with "1" and needed to make the package auto-overridable. But it makes no sense whatsoever to have the vendor himself do that ... (yes, it''s part of the current guideline, but worth fixing and this could be a motivation to do so, not that many packages use non-released upstream - the kernel is the very exception here) o The buildtag doesn''t mix well with the upstream extra version. "Is it rc6.git3 or rc6.git3.1?" "Are there rc7.2 upstream releases?" o indepdendence of the rpm-ordering of upstream''s extra versioning, e.g. not basing the versioing scheme on facts that "git" < "rc", so "we''re lucky this time"- ;) The don''t-reset-buildtag-on-prereleases allows upstream to do anything they like and you''re safe. o It also fits well with the non rc packaging scheme, e.g. going form git28 to rc1, then rc2.git1 etc. You just increase the buildtag and let upstream put the steam off wth any sub versioning they like. Yes, finally you''ll end up with kernel-2.6.22-23.f8 That''s OK, we''ve been in 4 figure integers already. And if someone really needs the first 2.6.22 build to be called kernel-2.6.22-1.f8, then modify the above to using "0.integer", e.g. kernel-2.6.22-0.1.rc6.git3.fc8 kernel-2.6.22-0.2.rc7.fc8 Still better to prepend the upstream''s extra version part than to suffix it due to the ordering issues and the semantic mixing effects. -- Axel.Thimm at ATrpms.net