Skip to contentSkip to conversation

linux-yocto 3.0.1 upgrade broke PREFERRED_VERSION setting in BSPs

DISCUSSION Darren Hart 5 participants 10 messages Aug 18, 2011 – Aug 21, 2011

lore
Share & tools
lore

Darren Hart

author
#0 lore raw

We have just rolled out PREFERRED_VERSION="3.0+git%", and these now fail with messages like:

NOTE: preferred version 3.0+git% of linux-yocto not available (for item virtual/kernel)

I could patch everything really quick to use 3.0.1+git%... but 3.0.2 was just released and I'd have to do it again tomorrow. For 2.6.37, the LINUX_VERSION remained the same across point releases. I recommend we do the same for 3.0. I really don't want to have to go through and update all the PREFERRED_VERSIONs in addition to all the SRCREVs everytime a point release comes out.

Signature · 3 lines
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
#1 lore raw
Quoted 6 lines · Darren Hart

We have just rolled out PREFERRED_VERSION="3.0+git%", and these now fail with messages like:

NOTE: preferred version 3.0+git% of linux-yocto not available (for item virtual/kernel)

Quoted 6 lines

I could patch everything really quick to use 3.0.1+git%... but 3.0.2 was just released and I'd have to do it again tomorrow. For 2.6.37, the LINUX_VERSION remained the same across point releases. I recommend we do the same for 3.0. I really don't want to have to go through and update all the PREFERRED_VERSIONs in addition to all the SRCREVs everytime a point release comes out.

I made this change due to some other explicit requests about the kernel version not being obvious. I don't really see this as a big deal, I'm already updating SRCREVs, we are already updating the SRCREVs in the meta-* layers .. so I fail to see how this is much more load.

I'd argue that 2.6.37 was a mistake, and you shouldn't even need to set the preferred version anymore once the latest kernel works for your machines. It will always be selected and you shouldn't need to force it. We only needed this during the transition phase, and I'm about to change the default in meta-yocto .. so you definitely won't need it.

Cheers,

Bruce

Quoted 1 line
#2 lore raw
Quoted 20 lines · Bruce Ashfield
Quoted 6 lines · Darren Hart

We have just rolled out PREFERRED_VERSION="3.0+git%", and these now fail with messages like:

NOTE: preferred version 3.0+git% of linux-yocto not available (for item virtual/kernel)

Quoted 6 lines

I could patch everything really quick to use 3.0.1+git%... but 3.0.2 was just released and I'd have to do it again tomorrow. For 2.6.37, the LINUX_VERSION remained the same across point releases. I recommend we do the same for 3.0. I really don't want to have to go through and update all the PREFERRED_VERSIONs in addition to all the SRCREVs everytime a point release comes out.

I made this change due to some other explicit requests about the kernel version not being obvious. I don't really see this as a big deal, I'm already updating SRCREVs, we are already updating the SRCREVs in the meta-* layers .. so I fail to see how this is much more load.

Quoted 6 lines

I'd argue that 2.6.37 was a mistake, and you shouldn't even need to set the preferred version anymore once the latest kernel works for your machines. It will always be selected and you shouldn't need to force it. We only needed this during the transition phase, and I'm about to change the default in meta-yocto .. so you definitely won't need it.

Another thought on this is that we follow up on the discussion that we had when I first had to force some boards back to 2.6.37. We drop all the preferred version manipulations and control this via DEFAULT_PREFERENCE.

I can just set DEFAULT_PREFERENCE = -1 in the linux-yocto_<ver>.bb file, and as machines are tested/validated, they'll just set the DEFAULT_PREFERENCE_$MACHINE in their recipe/bbappend file. That saves us all the PREFERRED version fun.

Alternatively, we go back to just setting it to 3.0 and leaving it there and those folks that don't want to check the tags in the kernel I can put a comment in the recipe that lets them know the true version.

Cheers,

Bruce

Quoted 11 lines

Cheers,

Bruce

Quoted 1 line

_______________________________________________
yocto mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/yocto

author
#3 lore raw
Quoted 10 lines · Bruce Ashfield
Quoted 9 lines · Bruce Ashfield
Quoted 8 lines · Darren Hart

We have just rolled out PREFERRED_VERSION="3.0+git%", and these now fail with messages like:

NOTE: preferred version 3.0+git% of linux-yocto not available (for item virtual/kernel)

I could patch everything really quick to use 3.0.1+git%... but 3.0.2 was just released and I'd have to do it again tomorrow. For 2.6.37, the

and 3.0.3 is out...

Quoted 10 lines
Quoted 10 lines
Quoted 4 lines

LINUX_VERSION remained the same across point releases. I recommend we do the same for 3.0. I really don't want to have to go through and update all the PREFERRED_VERSIONs in addition to all the SRCREVs everytime a point release comes out.

I made this change due to some other explicit requests about the kernel version not being obvious. I don't really see this as a big deal, I'm already updating SRCREVs, we are already updating the SRCREVs in the meta-* layers .. so I fail to see how this is much more load.

Don't forget the -rt variant, it is still at 3.0.

Quoted 12 lines
Quoted 6 lines

I'd argue that 2.6.37 was a mistake, and you shouldn't even need to set the preferred version anymore once the latest kernel works for your machines. It will always be selected and you shouldn't need to force it. We only needed this during the transition phase, and I'm about to change the default in meta-yocto .. so you definitely won't need it.

Another thought on this is that we follow up on the discussion that we had when I first had to force some boards back to 2.6.37. We drop all the preferred version manipulations and control this via DEFAULT_PREFERENCE.

Quoted 4 lines

I can just set DEFAULT_PREFERENCE = -1 in the linux-yocto_<ver>.bb file, and as machines are tested/validated, they'll just set the DEFAULT_PREFERENCE_$MACHINE in their recipe/bbappend file. That saves us all the PREFERRED version fun.

It makes a lot more sense to me to specify the kernel to use in the machine config and not allow whatever recipe claim DEFAULT_PREFERENCE for the machines.

Quoted 5 lines

Alternatively, we go back to just setting it to 3.0 and leaving it there and those folks that don't want to check the tags in the kernel I can put a comment in the recipe that lets them know the true version.

It is a bit odd to have to specify a version that doesn't match the filename itself. But I guess we already have to do that in part with the "+git%" thing. What is the "%" by the way - is it a wildcard? If so, can we use a wildcard to include point releases?

Signature · 3 lines
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
#6 lore raw
In reply to Bruce Ashfield
Quoted 14 lines · Bruce Ashfield
Quoted 6 lines · Darren Hart

We have just rolled out PREFERRED_VERSION="3.0+git%", and these now fail with messages like:

NOTE: preferred version 3.0+git% of linux-yocto not available (for item virtual/kernel)

Quoted 6 lines

I could patch everything really quick to use 3.0.1+git%... but 3.0.2 was just released and I'd have to do it again tomorrow. For 2.6.37, the LINUX_VERSION remained the same across point releases. I recommend we do the same for 3.0. I really don't want to have to go through and update all the PREFERRED_VERSIONs in addition to all the SRCREVs everytime a point release comes out.

Quoted 6 lines

I made this change due to some other explicit requests about the kernel version not being obvious. I don't really see this as a big deal, I'm already updating SRCREVs, we are already updating the SRCREVs in the meta-* layers .. so I fail to see how this is much more load.

Maybe the extra load isn't a big deal, but at least the SRCREVs can change most of the time without breaking everything like this does.

Quoted 7 lines

I'd argue that 2.6.37 was a mistake, and you shouldn't even need to set the preferred version anymore once the latest kernel works for your machines. It will always be selected and you shouldn't need to force it. We only needed this during the transition phase, and I'm about to change the default in meta-yocto .. so you definitely won't need it.

It would be great not to have to set the preferred version at all - how do I get that to work?

Tom

Quoted 6 lines

Cheers,

Bruce

Quoted 1 line
#4 lore raw
In reply to Darren Hart
Quoted 56 lines · Darren Hart
Quoted 10 lines · Bruce Ashfield
Quoted 9 lines · Bruce Ashfield
Quoted 8 lines · Darren Hart

We have just rolled out PREFERRED_VERSION="3.0+git%", and these now fail with messages like:

NOTE: preferred version 3.0+git% of linux-yocto not available (for item virtual/kernel)

I could patch everything really quick to use 3.0.1+git%... but 3.0.2 was just released and I'd have to do it again tomorrow. For 2.6.37, the

and 3.0.3 is out...

Quoted 10 lines
Quoted 10 lines
Quoted 4 lines

LINUX_VERSION remained the same across point releases. I recommend we do the same for 3.0. I really don't want to have to go through and update all the PREFERRED_VERSIONs in addition to all the SRCREVs everytime a point release comes out.

I made this change due to some other explicit requests about the kernel version not being obvious. I don't really see this as a big deal, I'm already updating SRCREVs, we are already updating the SRCREVs in the meta-* layers .. so I fail to see how this is much more load.

Don't forget the -rt variant, it is still at 3.0.

Quoted 12 lines
Quoted 6 lines

I'd argue that 2.6.37 was a mistake, and you shouldn't even need to set the preferred version anymore once the latest kernel works for your machines. It will always be selected and you shouldn't need to force it. We only needed this during the transition phase, and I'm about to change the default in meta-yocto .. so you definitely won't need it.

Another thought on this is that we follow up on the discussion that we had when I first had to force some boards back to 2.6.37. We drop all the preferred version manipulations and control this via DEFAULT_PREFERENCE.

Quoted 4 lines

I can just set DEFAULT_PREFERENCE = -1 in the linux-yocto_<ver>.bb file, and as machines are tested/validated, they'll just set the DEFAULT_PREFERENCE_$MACHINE in their recipe/bbappend file. That saves us all the PREFERRED version fun.

It makes a lot more sense to me to specify the kernel to use in the machine config and not allow whatever recipe claim DEFAULT_PREFERENCE for the machines.

Quoted 5 lines

Alternatively, we go back to just setting it to 3.0 and leaving it there and those folks that don't want to check the tags in the kernel I can put a comment in the recipe that lets them know the true version.

Quoted 4 lines

It is a bit odd to have to specify a version that doesn't match the filename itself. But I guess we already have to do that in part with the "+git%" thing. What is the "%" by the way - is it a wildcard? If so, can we use a wildcard to include point releases?

It is a wildcard .. I tried briefly to get it to match the point release. I had the same problem here, and didn't get the right combination to match the point release. I'll look at it more today as well .. or if someone knows the matching semantics off the top of their head, feel free to speak up! :)

Bruce

Quoted 2 lines
#7 lore raw
In reply to Tom Zanussi
Quoted 33 lines · Tom Zanussi
Quoted 14 lines · Bruce Ashfield
Quoted 6 lines · Darren Hart

We have just rolled out PREFERRED_VERSION="3.0+git%", and these now fail with messages like:

NOTE: preferred version 3.0+git% of linux-yocto not available (for item virtual/kernel)

Quoted 6 lines

I could patch everything really quick to use 3.0.1+git%... but 3.0.2 was just released and I'd have to do it again tomorrow. For 2.6.37, the LINUX_VERSION remained the same across point releases. I recommend we do the same for 3.0. I really don't want to have to go through and update all the PREFERRED_VERSIONs in addition to all the SRCREVs everytime a point release comes out.

Quoted 6 lines

I made this change due to some other explicit requests about the kernel version not being obvious. I don't really see this as a big deal, I'm already updating SRCREVs, we are already updating the SRCREVs in the meta-* layers .. so I fail to see how this is much more load.

Maybe the extra load isn't a big deal, but at least the SRCREVs can change most of the time without breaking everything like this does.

Quoted 7 lines

I'd argue that 2.6.37 was a mistake, and you shouldn't even need to set the preferred version anymore once the latest kernel works for your machines. It will always be selected and you shouldn't need to force it. We only needed this during the transition phase, and I'm about to change the default in meta-yocto .. so you definitely won't need it.

Quoted 2 lines

It would be great not to have to set the preferred version at all - how do I get that to work?

We can get away from it without setting preferred version by either the default preference scheme, or by virtue of removing the default preferred version from poky.conf. I'm working on the latter right now (some final builds of boards are problematic).

Once we are in a stable state, this won't be required at all, since it is the default. But when we bump to the next kernel version, the same thing happens. The newest is picked by bitbake and you'd need to set the preferred version to what you want all over again. That's where default_preference comes into play and saves us any wildcard issues.

That all being said, I'm going to revert the part of the change that bumped the version string and send it out for merge. So leave your preferred version strings as they currently are. Post 1.1 we'll move to a scheme that makes more sense (and at a time when we can properly think about it).

Bruce

Quoted 11 lines

Tom

Quoted 6 lines

Cheers,

Bruce

Quoted 1 line
#5 lore raw
In reply to Bruce Ashfield
Quoted 62 lines · Bruce Ashfield
Quoted 56 lines · Darren Hart
Quoted 10 lines · Bruce Ashfield
Quoted 9 lines · Bruce Ashfield
Quoted 8 lines · Darren Hart

We have just rolled out PREFERRED_VERSION="3.0+git%", and these now fail with messages like:

NOTE: preferred version 3.0+git% of linux-yocto not available (for item virtual/kernel)

I could patch everything really quick to use 3.0.1+git%... but 3.0.2 was just released and I'd have to do it again tomorrow. For 2.6.37, the

and 3.0.3 is out...

Quoted 10 lines
Quoted 10 lines
Quoted 4 lines

LINUX_VERSION remained the same across point releases. I recommend we do the same for 3.0. I really don't want to have to go through and update all the PREFERRED_VERSIONs in addition to all the SRCREVs everytime a point release comes out.

I made this change due to some other explicit requests about the kernel version not being obvious. I don't really see this as a big deal, I'm already updating SRCREVs, we are already updating the SRCREVs in the meta-* layers .. so I fail to see how this is much more load.

Don't forget the -rt variant, it is still at 3.0.

Quoted 12 lines
Quoted 6 lines

I'd argue that 2.6.37 was a mistake, and you shouldn't even need to set the preferred version anymore once the latest kernel works for your machines. It will always be selected and you shouldn't need to force it. We only needed this during the transition phase, and I'm about to change the default in meta-yocto .. so you definitely won't need it.

Another thought on this is that we follow up on the discussion that we had when I first had to force some boards back to 2.6.37. We drop all the preferred version manipulations and control this via DEFAULT_PREFERENCE.

Quoted 4 lines

I can just set DEFAULT_PREFERENCE = -1 in the linux-yocto_<ver>.bb file, and as machines are tested/validated, they'll just set the DEFAULT_PREFERENCE_$MACHINE in their recipe/bbappend file. That saves us all the PREFERRED version fun.

It makes a lot more sense to me to specify the kernel to use in the machine config and not allow whatever recipe claim DEFAULT_PREFERENCE for the machines.

Quoted 5 lines

Alternatively, we go back to just setting it to 3.0 and leaving it there and those folks that don't want to check the tags in the kernel I can put a comment in the recipe that lets them know the true version.

Quoted 4 lines

It is a bit odd to have to specify a version that doesn't match the filename itself. But I guess we already have to do that in part with the "+git%" thing. What is the "%" by the way - is it a wildcard? If so, can we use a wildcard to include point releases?

Quoted 5 lines

It is a wildcard .. I tried briefly to get it to match the point release. I had the same problem here, and didn't get the right combination to match the point release. I'll look at it more today as well .. or if someone knows the matching semantics off the top of their head, feel free to speak up! :)

'%' can be used only at the end and it's expected to produce only 1 match

like 1.0+git%

if there is only one version starting '1.0+git' and we just don't know exact SRCPV/SRCREV used.

http://git.openembedded.org/cgit.cgi/bitbake/commit/?id=2d1203f446a3527e4d261828b3c10df249119007

Signature · 1 line
Martin 'JaMa' Jansa     jabber: [email protected]
#8 lore raw
In reply to Darren Hart
Quoted 6 lines · Darren Hart

We have just rolled out PREFERRED_VERSION="3.0+git%", and these now fail with messages like:

NOTE: preferred version 3.0+git% of linux-yocto not available (for item virtual/kernel)

Quoted 7 lines

I could patch everything really quick to use 3.0.1+git%... but 3.0.2 was just released and I'd have to do it again tomorrow. For 2.6.37, the LINUX_VERSION remained the same across point releases. I recommend we do the same for 3.0. I really don't want to have to go through and update all the PREFERRED_VERSIONs in addition to all the SRCREVs everytime a point release comes out.

In my understanding 2.6 has now become 3 and .40 became .0 making it 3.0
therefore versions should be 3.0+gitrXXXX 3.1+gitrXXXX etc. 3.0.1 is similar to naming scheme 2.6.39.1 in olden days

#9 lore raw
Quoted 15 lines · Khem Raj
Quoted 6 lines · Darren Hart

We have just rolled out PREFERRED_VERSION="3.0+git%", and these now fail with messages like:

NOTE: preferred version 3.0+git% of linux-yocto not available (for item virtual/kernel)

Quoted 7 lines

I could patch everything really quick to use 3.0.1+git%... but 3.0.2 was just released and I'd have to do it again tomorrow. For 2.6.37, the LINUX_VERSION remained the same across point releases. I recommend we do the same for 3.0. I really don't want to have to go through and update all the PREFERRED_VERSIONs in addition to all the SRCREVs everytime a point release comes out.

Quoted 3 lines

In my understanding 2.6 has now become 3 and .40 became .0 making it 3.0 therefore versions should be 3.0+gitrXXXX 3.1+gitrXXXX etc. 3.0.1 is similar to naming scheme 2.6.39.1 in olden days

Correct. The 3rd digit is the domain of the -stable udpates, just like the 4th digit used to be. So we'll expect 5 or 6 updates to this for each supported kernel.

Cheers,

Bruce

Quoted 4 lines

_______________________________________________
yocto mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/yocto