ipk zImage in master-next

ipk zImage in master-next

[Trevor Woerner]

When packaging a zImage kernel for IPK in master-next the following
error shows up:

| kernel-image-zImage-4.1.2-fslc+g95d9e15
| *** Error: Package name  contains illegal characters, (other than
[a-z0-9.+-])

It looks like the newer kernel.bbclass is much more sophisticated about
generating package names than before.

Has anyone else seen this? Is there a simple way of saying "the type is
zimage where packaging for ipk is concerned but zImage otherwise"?

Best regards,
	Trevor

Re: ipk zImage in master-next

[Paul Barker]

[-- Attachment #1: Type: text/plain, Size: 999 bytes --]

On Fri, Aug 07, 2015 at 09:19:45AM -0400, Trevor Woerner wrote:
> When packaging a zImage kernel for IPK in master-next the following
> error shows up:
> 
> | kernel-image-zImage-4.1.2-fslc+g95d9e15
> | *** Error: Package name  contains illegal characters, (other than
> [a-z0-9.+-])
> 
> It looks like the newer kernel.bbclass is much more sophisticated about
> generating package names than before.
> 
> Has anyone else seen this? Is there a simple way of saying "the type is
> zimage where packaging for ipk is concerned but zImage otherwise"?
> 
> Best regards,
> 	Trevor

I believe this check is present in opkg-build just to ensure compatibility with
the Debian Policy Manual. I don't remember this being an actual restriction of
opkg.

You could try patching the opkg-build script (in opkg-utils) to remove this
check and see if opkg is happy to install the resulting package.

Thanks,

-- 
Paul Barker

Email: paul@paulbarker.me.uk
http://www.paulbarker.me.uk

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 501 bytes --]

Re: ipk zImage in master-next

[Trevor Woerner]

On 08/09/15 06:07, Paul Barker wrote:
> On Fri, Aug 07, 2015 at 09:19:45AM -0400, Trevor Woerner wrote:
>> When packaging a zImage kernel for IPK in master-next the following
>> error shows up:
>>
>> | kernel-image-zImage-4.1.2-fslc+g95d9e15
>> | *** Error: Package name  contains illegal characters, (other than
>> [a-z0-9.+-])
>>
>> It looks like the newer kernel.bbclass is much more sophisticated about
>> generating package names than before.
>>
>> Has anyone else seen this? Is there a simple way of saying "the type is
>> zimage where packaging for ipk is concerned but zImage otherwise"?
>>
>> Best regards,
>> 	Trevor
> 
> I believe this check is present in opkg-build just to ensure compatibility with
> the Debian Policy Manual. I don't remember this being an actual restriction of
> opkg.
> 
> You could try patching the opkg-build script (in opkg-utils) to remove this
> check and see if opkg is happy to install the resulting package.

Yes, this works. Removing the check from opkg-build causes my build to
succeed, and the resulting image boots with this kernel (meaning opkg is
happy to install the package into the image).

Normally this is the part where I'd ask if you want me to send a patch,
but if that check is there for a reason, simply removing it isn't a
proper solution.

Thoughts?

Best regards,
	Trevor

Re: ipk zImage in master-next

[Alejandro del Castillo]

On 08/10/2015 08:49 AM, Trevor Woerner wrote:
> On 08/09/15 06:07, Paul Barker wrote:
>> On Fri, Aug 07, 2015 at 09:19:45AM -0400, Trevor Woerner wrote:
>>> When packaging a zImage kernel for IPK in master-next the following
>>> error shows up:
>>>
>>> | kernel-image-zImage-4.1.2-fslc+g95d9e15
>>> | *** Error: Package name  contains illegal characters, (other than
>>> [a-z0-9.+-])
>>>
>>> It looks like the newer kernel.bbclass is much more sophisticated about
>>> generating package names than before.
>>>
>>> Has anyone else seen this? Is there a simple way of saying "the type is
>>> zimage where packaging for ipk is concerned but zImage otherwise"?
>>>
>>> Best regards,
>>> 	Trevor
>>
>> I believe this check is present in opkg-build just to ensure compatibility with
>> the Debian Policy Manual. I don't remember this being an actual restriction of
>> opkg.
>>
>> You could try patching the opkg-build script (in opkg-utils) to remove this
>> check and see if opkg is happy to install the resulting package.
> 
> Yes, this works. Removing the check from opkg-build causes my build to
> succeed, and the resulting image boots with this kernel (meaning opkg is
> happy to install the package into the image).
> 
> Normally this is the part where I'd ask if you want me to send a patch,
> but if that check is there for a reason, simply removing it isn't a
> proper solution.
> 
> Thoughts?

Looks like the dpkg back-end should be broken too. Sounds to me like the problem
is not on opkg-build but on the new changes to the kernel class, maybe is
missing a call to legitimize_package_name?.

-- 
cheers,

Alejandro

Re: ipk zImage in master-next

[Paul Barker]

[-- Attachment #1: Type: text/plain, Size: 1790 bytes --]

On Mon, Aug 10, 2015 at 09:49:47AM -0400, Trevor Woerner wrote:
> On 08/09/15 06:07, Paul Barker wrote:
> > On Fri, Aug 07, 2015 at 09:19:45AM -0400, Trevor Woerner wrote:
> >> When packaging a zImage kernel for IPK in master-next the following
> >> error shows up:
> >>
> >> | kernel-image-zImage-4.1.2-fslc+g95d9e15
> >> | *** Error: Package name  contains illegal characters, (other than
> >> [a-z0-9.+-])
> >>
> >> It looks like the newer kernel.bbclass is much more sophisticated about
> >> generating package names than before.
> >>
> >> Has anyone else seen this? Is there a simple way of saying "the type is
> >> zimage where packaging for ipk is concerned but zImage otherwise"?
> >>
> >> Best regards,
> >> 	Trevor
> > 
> > I believe this check is present in opkg-build just to ensure compatibility with
> > the Debian Policy Manual. I don't remember this being an actual restriction of
> > opkg.
> > 
> > You could try patching the opkg-build script (in opkg-utils) to remove this
> > check and see if opkg is happy to install the resulting package.
> 
> Yes, this works. Removing the check from opkg-build causes my build to
> succeed, and the resulting image boots with this kernel (meaning opkg is
> happy to install the package into the image).
> 
> Normally this is the part where I'd ask if you want me to send a patch,
> but if that check is there for a reason, simply removing it isn't a
> proper solution.
> 
> Thoughts?
> 

I'd suggest removing it if the latest version of opkg can install the resulting
package. It's either an old limitation or there purely to comply with the Debian
Policy Manual (which we don't need to comply with).

Thanks,

-- 
Paul Barker

Email: paul@paulbarker.me.uk
http://www.paulbarker.me.uk

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 501 bytes --]