[yocto] opkg

[Phillip Warren]

Hi, I'm currently working on the pyro branch (2.3.4) and have a need
to support opkg list-upgradable; however, when I execute opkg
list-upgradable, I receive the following error:

Collected errors:
 * opkg_list_upgradable_cmd: list-upgradable command not available
with external solver enabled

The pyro opkg version is:
~# opkg --version
opkg version 0.3.4 (libsolv 0.6.26)

What is the simplest way to enable the list-upgradeable option for opkg?

1. Write a .bbappend to apply the patch to the 0.3.4 source that
enables this functionality? Where might I locate this patch?
2. Fast-forward opkg 0.3.4 to a newer version? What's the approved way
to do this within the yocto environment?

Thanks!
Phillip Warren
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] opkg behavior

[Gary Thomas]

I'm using opkg (IPK) packaging with my Yocto builds (using recent
master 633ad6c9f).  For the most part, this seems to work well,
but occasionally I'll rebuild a recipe along with the packaging
indexes on my build machine only to find that opkg doesn't want
to upgrade to the changes.  Here's an example:

* Update the package databases on the target board
  root@teton-p7621:~# opkg update
  Downloading http://192.168.1.12/teton-p7621-feeds/all/Packages.gz.
  Updated source 'poky_am-all'.
  Downloading http://192.168.1.12/teton-p7621-feeds/cortexa7hf-neon/Packages.gz.
  Updated source 'poky_am-cortexa7hf-neon'.
  Downloading http://192.168.1.12/teton-p7621-feeds/teton_p7621/Packages.gz.
  Updated source 'poky_am-teton_p7621'.

* Try to update the package I just rebuilt.  Normally, this does the right thing
  root@teton-p7621:~# opkg install production-tests
  No packages installed or removed.

* Odd, check the packaging
  root@teton-p7621:~# opkg list-installed | grep prod
  production-tests - 1.0-r0.74

* Force the install by removing the existing package, etc
  root@teton-p7621:~# opkg remove production-tests
  Removing production-tests (1.0) from root...
  root@teton-p7621:~# opkg install production-tests
  Installing production-tests (1.0) on root
  Downloading 
http://192.168.1.12/teton-p7621-feeds/teton_p7621/production-tests_1.0-r0.76_teton_p7621.ipk.
  Configuring production-tests.

So from this you can see that the package has been rebuilt (using
the PR server) and that I can indeed install the new version.  That
said, why did opkg not "upgrade" as expected.  Note: I often use
the 'opkg upgrade' command but I recently updated my Poky/Yocto
repository which caused nearly every package to be rebuilt and I
didn't want to have to download everything (none of which affected
my current program which is just a python script), so I chose the
'opkg install ...' method instead, which does seem to work sometimes.

Any ideas what I can look at or tweak to get this to work the way
I expect?

Thanks

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] opkg

[Khem Raj]

On Mon, Aug 20, 2018 at 2:41 PM Phillip Warren  wrote:
>
> Hi, I'm currently working on the pyro branch (2.3.4) and have a need
> to support opkg list-upgradable; however, when I execute opkg
> list-upgradable, I receive the following error:
>
> Collected errors:
>  * opkg_list_upgradable_cmd: list-upgradable command not available
> with external solver enabled
>
> The pyro opkg version is:
> ~# opkg --version
> opkg version 0.3.4 (libsolv 0.6.26)
>
> What is the simplest way to enable the list-upgradeable option for opkg?
>
> 1. Write a .bbappend to apply the patch to the 0.3.4 source that
> enables this functionality? Where might I locate this patch?

usually this is ok and upstreamable, but may not be always possible if
change is quite intrusive
you might look into opkg git here
http://git.yoctoproject.org/cgit/cgit.cgi/opkg

particularly this commit
http://git.yoctoproject.org/cgit/cgit.cgi/opkg/commit/?id=cc624806a6179c2d3d7b3eec4260e50ab0653c5d

be aware that it looks like it might need some other commits too.

> 2. Fast-forward opkg 0.3.4 to a newer version? What's the approved way
> to do this within the yocto environment?
>

sometimes this might be fine, we wont accept it upstream without a
solid reasoning but it could serve your
purpose and you can maintain it in your local project. Although be
aware that it has not been integrated with
older versions of yocto so there could be loose ends.

> Thanks!
> Phillip Warren
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] OPKG Spec

[Adi Malca]

Hello,

I'm looking for the current official OPKG spec with spelling and case
sensitive.
For example:

*Package*:

*Version*:

*Description*:

*Section*:

*Priority*:

*Maintainer*:

*License*:

*Architecture*:

*OE*:

*Homepage*:

*Depends*:

*Source*:

*Filename*:

*SHA1*:

*SHA256*:


Best Regards,
Adi

-- 
 

-- 
 

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] OPKG configuration questions

[Glenn Schmottlach]

I have several questions regarding configuring the OPKG package management
support in my target image.

1) I'm having difficulty getting the /var/lib/opkg directory to be created
and populated with a list of installed packages.

2) I can't figure out (e.g. can find no documentation) that describe what
the "lists_dir ext /var/lib/opkg" option in the opkg.conf file does. Does
this point to where the list of installed packages should be found?

3) What is the best/preferred approach (e.g. patch, *bbappend, new recipe,
etc...) to tailor or modify the opkg.conf file (specifically the opkg
source (src) paths) that are appended to /etc/opkg/opkg.conf file by the
opkg-collatoral.bb recipe.

This is what I have done to prepare my image to include package management:

1) My image recipe inherits from core-image

2) I've configured ONLINE_PACKAGE_MANAGEMENT = "full" and confirmed that is
it set correctly via "bitbake-env -r image-nitrogen6x
ONLINE_PACKAGE_MANAGEMENT"

3) I've confirmed that IMAGE_FEATURES = "debug-tweaks package-management"

4) PACKAGE_CLASSES = "package_ipk" is configured and I see packages in my
/build/tmp/deploy/ipk directory

The target boots fine and I have the appropriate opkg applications
installed (e.g. opkg, opkg-cl, opkg-key). I also have the default
/etc/opkg/opkg.conf and /etc/opkg/arch.conf installed.

There is *no* /var/lib/opkg directory and thus "opkg-cl list-installed"
returns with an error because the "opkg" directory is missing. If I
manually create it the program run successfully but doesn't list anything
(which is obvious since it is empty).

I read this post
https://lists.yoctoproject.org/pipermail/yocto/2013-June/016324.html

and confirmed that my setting are correct for IMAGE_FEATURES and
ROOT_POSTPROCESS_CMD (= "run_intercept_scriptlets;
license_create_manifest;  ssh_allow_empty_password;
rootfs_update_timestamp ;")

Can anyone offer any suggestions, recommendations, or answers to my
questions above?

Thanks for you help . . .
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] opkg Status Update

[Paul Barker]

Hi all,

This is fairly relevant to OpenEmbedded so I'd like to give you all a heads up.

I'll be releasing opkg v0.2.4 in around 2 weeks and will be following
that with v0.3.0 in the next month or two. The v0.3.0 release will
incorporate some useful features, including cache improvements and
package file extraction improvements. A dependency will be added on
libarchive which will replace the crufty manual handling of tar and
gzip formats which used to be in opkg. Due to these changes, I'd
definitely like to get this tested before the v0.3.0 release and so
I'll be tagging release candidates. If anyone would like to help with
testing please let me know! I have a meta-opkg layer
(https://bitbucket.org/opkg/meta-opkg) which makes it really easy to
test opkg release candidates and git commits in OpenEmbedded, it even
has a readme file with instructions.

Also, my circumstances are changing over the next few months. I've
come to the end of the 'active' part of my PhD research and I'm now
writing up my thesis part-time. I'm also starting full time employment
in January. This will make for a pretty busy schedule and I don't know
until I settle into the new routine how much free time I'll have to
work on opkg. This would be a great time for someone to step up and
help move things forward to v0.4.0 and beyond. I'll still be involved
in opkg development and I'm happy to continue my role as maintainer,
but I just want to make it clear that my time will be limited and any
help with development, patch review and bug triage would be much
appreciated!

Many thanks,

-- 
Paul Barker

Email: p...@paulbarker.me.uk
http://www.paulbarker.me.uk
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] opkg behavior

[Alejandro del Castillo]

On 04/11/2017 08:03 AM, Gary Thomas wrote:
> I'm using opkg (IPK) packaging with my Yocto builds (using recent
> master 633ad6c9f).  For the most part, this seems to work well,
> but occasionally I'll rebuild a recipe along with the packaging
> indexes on my build machine only to find that opkg doesn't want
> to upgrade to the changes.  Here's an example:
> 
> * Update the package databases on the target board
>   root@teton-p7621:~# opkg update
>   Downloading http://192.168.1.12/teton-p7621-feeds/all/Packages.gz.
>   Updated source 'poky_am-all'.
>   Downloading
> http://192.168.1.12/teton-p7621-feeds/cortexa7hf-neon/Packages.gz.
>   Updated source 'poky_am-cortexa7hf-neon'.
>   Downloading
> http://192.168.1.12/teton-p7621-feeds/teton_p7621/Packages.gz.
>   Updated source 'poky_am-teton_p7621'.
> 
> * Try to update the package I just rebuilt.  Normally, this does the
> right thing
>   root@teton-p7621:~# opkg install production-tests
>   No packages installed or removed.
> 
> * Odd, check the packaging
>   root@teton-p7621:~# opkg list-installed | grep prod
>   production-tests - 1.0-r0.74
> 
> * Force the install by removing the existing package, etc
>   root@teton-p7621:~# opkg remove production-tests
>   Removing production-tests (1.0) from root...
>   root@teton-p7621:~# opkg install production-tests
>   Installing production-tests (1.0) on root
>   Downloading
> http://192.168.1.12/teton-p7621-feeds/teton_p7621/production-tests_1.0-r0.76_teton_p7621.ipk.
> 
>   Configuring production-tests.
> 
> So from this you can see that the package has been rebuilt (using
> the PR server) and that I can indeed install the new version.  That
> said, why did opkg not "upgrade" as expected.  Note: I often use
> the 'opkg upgrade' command but I recently updated my Poky/Yocto
> repository which caused nearly every package to be rebuilt and I
> didn't want to have to download everything (none of which affected
> my current program which is just a python script), so I chose the
> 'opkg install ...' method instead, which does seem to work sometimes.
> 
> Any ideas what I can look at or tweak to get this to work the way
> I expect?

Opkg uses libsolv as it's solver backend. When you say 'opkg install
production-tests', the solver doesn't do anything since package
'production-tests' is already installed.

What you want is a targeted upgrade, which can be done by calling 'opkg
upgrade production-tests'. Another option is to do a by version install,
which can be done by calling 'opkg install production-tests=1.0-r0.76'


-- 
Cheers,

Alejandro
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] opkg-utils 0.3.6

[Alejandro del Castillo]

Hi all,

I am please to announce the 0.3.6 release of opkg-utils. In this 
release, we had 10 commits, contributed by 7 developers:


Jeffrey Pautler 3
Alejandro del Castillo  3
Zhu Mumu1
Adam Trhon  1
Jackie Huang1
Juro Bystricky  1

Jeffrey, Zhu, Adam, Jackie, Juro, thanks for your contributions!

Changes included on this release:

- opkg-build: make Section, Priority and Source fields optional
- opkg.py: add compatibility with ipks which outer is tar
- opkg-build{package}: fix error message
- opkg.py: remove brittle formatting of description field
- opkg-make-index: add option to include all fields on index file
- update-alternatives: fix the sed pattern in remove_alt
- update-alternatives: add support for link renames (issue 8344)
- opkg-build: improve package reproducibility (issue 11242)

looking forward to the 0.4.0 release cycle!

--
Cheers,

Alejandro
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] OPKG Spec

[Robert Joslyn]

On Sun, 2019-06-23 at 16:15 +0300, Adi Malca wrote:
> Hello,
> 
> I'm looking for the current official OPKG spec with spelling and case
> sensitive.
> For example:
> Package: 
> Version: 
> Description: 
> Section: 
> Priority: 
> Maintainer: 
> License: 
> Architecture: 
> OE: 
> Homepage:
> Depends: 
> Source: 
> Filename: 
> SHA1:
> SHA256:
> 
> Best Regards,
> Adi

I'm not sure if there is an official spec somewhere, but the structure
of the packages and server index files can be seen in the code. The
main opkg utility is here: 
http://git.yoctoproject.org/cgit/cgit.cgi/opkg/

The helper scripts are also useful: 
http://git.yoctoproject.org/cgit/cgit.cgi/opkg-utils/

You can see the structure of the metadata you mention, including
spelling, capitalization, etc, here:
http://git.yoctoproject.org/cgit/cgit.cgi/opkg/tree/libopkg/pkg.c#n552

You can also see it here (perhaps more concisely):
http://git.yoctoproject.org/cgit/cgit.cgi/opkg-utils/tree/opkg.py#n491

The Packages and Packages.gz index files use these variables. For
example, this is what shows up in the index for busybox on one of my
builds:

Package: busybox
Version: 1.30.1-r0
Depends: libc6 (>= 2.29), update-alternatives-opkg
Recommends: busybox-udhcpc
Section: base
Architecture: armv7vet2hf-neon
Maintainer: Poky 
MD5Sum: c0b45a09adec305b49153133a3392917
Size: 315406
Filename: busybox_1.30.1-r0_armv7vet2hf-neon.ipk
Source: busybox_1.30.1.bb
Description: Tiny versions of many common UNIX utilities in a single
small executable
OE: busybox
HomePage: http://www.busybox.net
License: GPLv2 & bzip2
Priority: optional

Packages can also use SHA256 rather than MD5.

Package: busybox
Version: 1.30.1-r0
Depends: libc6 (>= 2.29), update-alternatives-opkg
Recommends: busybox-udhcpc
Section: base
Architecture: armv7vet2hf-neon
Maintainer: Poky 
SHA256sum:
3ca8d2dd79759fa34bf04a0ee97fef5e354d97da76b03672544f3c4eeef76ac9
Size: 315406
Filename: busybox_1.30.1-r0_armv7vet2hf-neon.ipk
Source: busybox_1.30.1.bb
Description: Tiny versions of many common UNIX utilities in a single
small executable
OE: busybox
HomePage: http://www.busybox.net
License: GPLv2 & bzip2
Priority: optional

I'm not sure if anyone has any package feeds built by Yocto publicly
available, but OpenWRT uses opkg as well, with public feeds available.
For example:
https://downloads.openwrt.org/releases/18.06.2/packages/aarch64_cortex-a53/base/


Robert

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] OPKG Spec

[Adi Malca]

Thank you Robert, the last 2 links to the code were very helpful.

On Tue, Jun 25, 2019 at 8:28 AM Robert Joslyn <
robert.jos...@redrectangle.org> wrote:

> On Sun, 2019-06-23 at 16:15 +0300, Adi Malca wrote:
> > Hello,
> >
> > I'm looking for the current official OPKG spec with spelling and case
> > sensitive.
> > For example:
> > Package:
> > Version:
> > Description:
> > Section:
> > Priority:
> > Maintainer:
> > License:
> > Architecture:
> > OE:
> > Homepage:
> > Depends:
> > Source:
> > Filename:
> > SHA1:
> > SHA256:
> >
> > Best Regards,
> > Adi
>
> I'm not sure if there is an official spec somewhere, but the structure
> of the packages and server index files can be seen in the code. The
> main opkg utility is here:
> http://git.yoctoproject.org/cgit/cgit.cgi/opkg/
>
> The helper scripts are also useful:
> http://git.yoctoproject.org/cgit/cgit.cgi/opkg-utils/
>
> You can see the structure of the metadata you mention, including
> spelling, capitalization, etc, here:
> http://git.yoctoproject.org/cgit/cgit.cgi/opkg/tree/libopkg/pkg.c#n552
>
> You can also see it here (perhaps more concisely):
> http://git.yoctoproject.org/cgit/cgit.cgi/opkg-utils/tree/opkg.py#n491
>
> The Packages and Packages.gz index files use these variables. For
> example, this is what shows up in the index for busybox on one of my
> builds:
>
> Package: busybox
> Version: 1.30.1-r0
> Depends: libc6 (>= 2.29), update-alternatives-opkg
> Recommends: busybox-udhcpc
> Section: base
> Architecture: armv7vet2hf-neon
> Maintainer: Poky 
> MD5Sum: c0b45a09adec305b49153133a3392917
> Size: 315406
> Filename: busybox_1.30.1-r0_armv7vet2hf-neon.ipk
> Source: busybox_1.30.1.bb
> Description: Tiny versions of many common UNIX utilities in a single
> small executable
> OE: busybox
> HomePage: http://www.busybox.net
> License: GPLv2 & bzip2
> Priority: optional
>
> Packages can also use SHA256 rather than MD5.
>
> Package: busybox
> Version: 1.30.1-r0
> Depends: libc6 (>= 2.29), update-alternatives-opkg
> Recommends: busybox-udhcpc
> Section: base
> Architecture: armv7vet2hf-neon
> Maintainer: Poky 
> SHA256sum:
> 3ca8d2dd79759fa34bf04a0ee97fef5e354d97da76b03672544f3c4eeef76ac9
> Size: 315406
> Filename: busybox_1.30.1-r0_armv7vet2hf-neon.ipk
> Source: busybox_1.30.1.bb
> Description: Tiny versions of many common UNIX utilities in a single
> small executable
> OE: busybox
> HomePage: http://www.busybox.net
> License: GPLv2 & bzip2
> Priority: optional
>
> I'm not sure if anyone has any package feeds built by Yocto publicly
> available, but OpenWRT uses opkg as well, with public feeds available.
> For example:
>
> https://downloads.openwrt.org/releases/18.06.2/packages/aarch64_cortex-a53/base/
>
>
> Robert
>
>

-- 
 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] OPKG configuration questions

[Nicolas Dechesne]

On Wed, Oct 16, 2013 at 10:17 PM, Glenn Schmottlach
 wrote:
> 1) I'm having difficulty getting the /var/lib/opkg directory to be created
> and populated with a list of installed packages.

 i use that routinely. so there must be something wrong in your config ;-)
you didn't mention which release and layer set you are using, btw.

>
> 2) I can't figure out (e.g. can find no documentation) that describe what
> the "lists_dir ext /var/lib/opkg" option in the opkg.conf file does. Does
> this point to where the list of installed packages should be found?

yes, i think so. so that you can eventually control where they are.
e.g. if they need to be on a specific folder/file system. also, note
that the 2nd arg is simply ignored, see
https://code.google.com/p/opkg/issues/detail?id=73

>
> 3) What is the best/preferred approach (e.g. patch, *bbappend, new recipe,
> etc...) to tailor or modify the opkg.conf file (specifically the opkg source
> (src) paths) that are appended to /etc/opkg/opkg.conf file by the
> opkg-collatoral.bb recipe.

yes. .bbappend and provide 'src' file in your layer.

>
> This is what I have done to prepare my image to include package management:
>
> 1) My image recipe inherits from core-image

i do that too.

>
> 2) I've configured ONLINE_PACKAGE_MANAGEMENT = "full" and confirmed that is
> it set correctly via "bitbake-env -r image-nitrogen6x
> ONLINE_PACKAGE_MANAGEMENT"

that's the only thing I don't do... i don't think this is required,
looking throughout the sources, that shouldn't be needed, but that
shouldn't explain the error you gave neither..

>
> 3) I've confirmed that IMAGE_FEATURES = "debug-tweaks package-management"

did you get that with bitbake -e? also note that IMAGE_FEATURE *must*
be set before you inherit core-image, so either in a .conf file
(local.conf, distro.conf, ...) or if you do it in your image recipe,
you need to do it before.  so even if bitbake -e seems right, it might
be wrong...

one way to check is to get the value of the following vars:

ROOTFS_BOOTSTRAP_INSTALL

as it is set in image.bbclass like this:

ROOTFS_BOOTSTRAP_INSTALL = "${@base_contains("IMAGE_FEATURES",
"package-management", "", "${ROOTFS_PKGMANAGE_BOOTSTRAP}",d)}"


>
> 4) PACKAGE_CLASSES = "package_ipk" is configured and I see packages in my
> /build/tmp/deploy/ipk directory

looks ok.

>
> The target boots fine and I have the appropriate opkg applications installed
> (e.g. opkg, opkg-cl, opkg-key). I also have the default /etc/opkg/opkg.conf
> and /etc/opkg/arch.conf installed.
>
> There is *no* /var/lib/opkg directory and thus "opkg-cl list-installed"
> returns with an error because the "opkg" directory is missing. If I manually
> create it the program run successfully but doesn't list anything (which is
> obvious since it is empty).
>
> I read this post
> https://lists.yoctoproject.org/pipermail/yocto/2013-June/016324.html
>
> and confirmed that my setting are correct for IMAGE_FEATURES and
> ROOT_POSTPROCESS_CMD (= "run_intercept_scriptlets; license_create_manifest;
> ssh_allow_empty_password;  rootfs_update_timestamp ;")
>
> Can anyone offer any suggestions, recommendations, or answers to my
> questions above?

if you can pastebin the entire content of bibtake -e  , we
will get all the variables...
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] OPKG configuration questions

[Glenn Schmottlach]

See my feedback/comments below . . .

Thanks for your help . . .

On Wed, Oct 16, 2013 at 5:10 PM, Nicolas Dechesne
 wrote:
> On Wed, Oct 16, 2013 at 10:17 PM, Glenn Schmottlach
>  wrote:
>> 1) I'm having difficulty getting the /var/lib/opkg directory to be created
>> and populated with a list of installed packages.
>
>  i use that routinely. so there must be something wrong in your config ;-)
> you didn't mention which release and layer set you are using, btw.
>

]] I'm using Dylan-9.0.0 with several custom layers for an i.MX6
Nitrogen6x board.

>>
>> 2) I can't figure out (e.g. can find no documentation) that describe what
>> the "lists_dir ext /var/lib/opkg" option in the opkg.conf file does. Does
>> this point to where the list of installed packages should be found?
>
> yes, i think so. so that you can eventually control where they are.
> e.g. if they need to be on a specific folder/file system. also, note
> that the 2nd arg is simply ignored, see
> https://code.google.com/p/opkg/issues/detail?id=73
>
>>
>> 3) What is the best/preferred approach (e.g. patch, *bbappend, new recipe,
>> etc...) to tailor or modify the opkg.conf file (specifically the opkg source
>> (src) paths) that are appended to /etc/opkg/opkg.conf file by the
>> opkg-collatoral.bb recipe.
>
> yes. .bbappend and provide 'src' file in your layer.


]] That makes the most sense. Thanks for the suggestion,


>>
>> This is what I have done to prepare my image to include package management:
>>
>> 1) My image recipe inherits from core-image
>
> i do that too.
>
>>
>> 2) I've configured ONLINE_PACKAGE_MANAGEMENT = "full" and confirmed that is
>> it set correctly via "bitbake-env -r image-nitrogen6x
>> ONLINE_PACKAGE_MANAGEMENT"
>
> that's the only thing I don't do... i don't think this is required,
> looking throughout the sources, that shouldn't be needed, but that
> shouldn't explain the error you gave neither..
>
>>
>> 3) I've confirmed that IMAGE_FEATURES = "debug-tweaks package-management"
>
> did you get that with bitbake -e? also note that IMAGE_FEATURE *must*
> be set before you inherit core-image, so either in a .conf file
> (local.conf, distro.conf, ...) or if you do it in your image recipe,
> you need to do it before.  so even if bitbake -e seems right, it might
> be wrong...
>


]] I confirmed that with bitbake -e. It's configured in my local.conf file.


> one way to check is to get the value of the following vars:
>
> ROOTFS_BOOTSTRAP_INSTALL
>
> as it is set in image.bbclass like this:
>
> ROOTFS_BOOTSTRAP_INSTALL = "${@base_contains("IMAGE_FEATURES",
> "package-management", "", "${ROOTFS_PKGMANAGE_BOOTSTRAP}",d)}"
>
>

]] That variable isn't defined in my environment. All I see is the following:

 bitbake  -e image-nitrogen6x | grep ROOTFS_BOOTSTRAP_INSTALL
# "${IMAGE_INSTALL} ${LINGUAS_INSTALL} ${NORMAL_FEATURE_INSTALL}
${ROOTFS_BOOTSTRAP_INSTALL}"
#   " ${IMAGE_INSTALL} ${LINGUAS_INSTALL} ${NORMAL_FEATURE_INSTALL}
${ROOTFS_BOOTSTRAP_INSTALL}"
# $ROOTFS_BOOTSTRAP_INSTALL
# "${IMAGE_INSTALL} ${ROOTFS_BOOTSTRAP_INSTALL} ${FEATURE_INSTALL}"
#   "${IMAGE_INSTALL} ${ROOTFS_BOOTSTRAP_INSTALL} ${FEATURE_INSTALL}"

]] In my "image" recipe I inherit from core-image. Do I also need to
also inherit from "image" as well to get this expanded?

>>
>> 4) PACKAGE_CLASSES = "package_ipk" is configured and I see packages in my
>> /build/tmp/deploy/ipk directory
>
> looks ok.
>
>>
>> The target boots fine and I have the appropriate opkg applications installed
>> (e.g. opkg, opkg-cl, opkg-key). I also have the default /etc/opkg/opkg.conf
>> and /etc/opkg/arch.conf installed.
>>
>> There is *no* /var/lib/opkg directory and thus "opkg-cl list-installed"
>> returns with an error because the "opkg" directory is missing. If I manually
>> create it the program run successfully but doesn't list anything (which is
>> obvious since it is empty).
>>
>> I read this post
>> https://lists.yoctoproject.org/pipermail/yocto/2013-June/016324.html
>>
>> and confirmed that my setting are correct for IMAGE_FEATURES and
>> ROOT_POSTPROCESS_CMD (= "run_intercept_scriptlets; license_create_manifest;
>> ssh_allow_empty_password;  rootfs_update_timestamp ;")
>>
>> Can anyone offer any suggestions, recommendations, or answers to my
>> questions above?
>
> if you can pastebin the entire content of bibtake -e  , we
> will get all the variables...

]] Wish I could but it's too large for the non-PRO account. One thing
that did disturb me a little was that when I look in my
/build/tmp-eglibc/deploy/ipk is see the following:

  4 drwxr-xr-x 6 gschmottlach gschmottlach   4096 Oct 16 16:38 .
  4 drwxr-xr-x 8 gschmottlach gschmottlach   4096 Oct  3 05:53 ..
 12 drwxr-xr-x 2 gschmottlach gschmottlach  12288 Oct 16 16:38 all
176 drwxr-xr-x 2 gschmottlach gschmottlach 176128 Oct 16 16:38 armv7a-vfp-neon
 24 drwxr-xr-x 2 gschmottlach gschmottlach  24576 Oct 16 16:38 i686-nativesdk
 40 drwxr-xr-x 2 gschmottlach gschmottlach  36864 Oct 16 16:38 nitrogen6x
  0 -rw-rw-r-- 1 gschm

Re: [yocto] OPKG configuration questions

[Trevor Woerner]

On 16 October 2013 18:19, Glenn Schmottlach  wrote:
> One thing
> that did disturb me a little was that when I look in my
> /build/tmp-eglibc/deploy/ipk is see the following:
>
>   4 drwxr-xr-x 6 gschmottlach gschmottlach   4096 Oct 16 16:38 .
>   4 drwxr-xr-x 8 gschmottlach gschmottlach   4096 Oct  3 05:53 ..
>  12 drwxr-xr-x 2 gschmottlach gschmottlach  12288 Oct 16 16:38 all
> 176 drwxr-xr-x 2 gschmottlach gschmottlach 176128 Oct 16 16:38
armv7a-vfp-neon
>  24 drwxr-xr-x 2 gschmottlach gschmottlach  24576 Oct 16 16:38
i686-nativesdk
>  40 drwxr-xr-x 2 gschmottlach gschmottlach  36864 Oct 16 16:38 nitrogen6x
>   0 -rw-rw-r-- 1 gschmottlach gschmottlach  0 Oct 16 16:38 Packages
>   0 -rw-r--r-- 1 gschmottlach gschmottlach  0 Oct  3 00:24
Packages.flock
>   4 -rw-rw-r-- 1 gschmottlach gschmottlach 20 Oct 16 16:38 Packages.gz
>   0 -rw-r--r-- 1 gschmottlach gschmottlach  0 Oct 16 16:38
Packages.stamps

Yes, I'm seeing that too.

What happens if you run (on your build machine, from your
build location) (replace stuff in <> as required):

$ /sysroots//usr/bin/opkg-cl -o /workrootfs list

For example:

$ tmp-qemuarm/sysroots/x86_64-linux/usr/bin/opkg-cl -o
tmp-qemuarm/work/qemuarm-poky-linux-gnueabi/core-image-minimal/1.0-r0/rootfs
list

Does that print you a list of all the packages in your image?

Just out of curiosity, is it possible that you added "package-management"
to IMAGE_FEATURES after you already had a successful full build? Or is
it possible that you had already done a full build with "package_rpm" or
"_deb" before switching to "package_ipk"?

The reason I ask is (although I never confirmed this definitively but) when
I was playing with this stuff a while back I was sure that this package
stuff
would only get generated after adjusting these configurations when a full,
clean build was performed (i.e. removing  and ).

If you are making changes to your build which might affect your packages
you'll need to perform:

$ bitbake package-index

Have you had a look at:
http://www.yoctoproject.org/docs/1.5/mega-manual/mega-manual.html#using-runtime-package-management

Maybe something in there might help? But it certainly sounds like you're
doing everything correctly.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] OPKG configuration questions

[Khem Raj]

On Oct 16, 2013, at 1:17 PM, Glenn Schmottlach  wrote:

> I have several questions regarding configuring the OPKG package management 
> support in my target image.
> 
> 1) I'm having difficulty getting the /var/lib/opkg directory to be created 
> and populated with a list of installed packages.
> 
> 2) I can't figure out (e.g. can find no documentation) that describe what the 
> "lists_dir ext /var/lib/opkg" option in the opkg.conf file does. Does this 
> point to where the list of installed packages should be found?
> 
> 3) What is the best/preferred approach (e.g. patch, *bbappend, new recipe, 
> etc...) to tailor or modify the opkg.conf file (specifically the opkg source 
> (src) paths) that are appended to /etc/opkg/opkg.conf file by the 
> opkg-collatoral.bb recipe.
> 
> This is what I have done to prepare my image to include package management:
> 
> 1) My image recipe inherits from core-image
> 
> 2) I've configured ONLINE_PACKAGE_MANAGEMENT = "full" and confirmed that is 
> it set correctly via "bitbake-env -r image-nitrogen6x 
> ONLINE_PACKAGE_MANAGEMENT"
> 
> 3) I've confirmed that IMAGE_FEATURES = "debug-tweaks package-management"
> 
> 4) PACKAGE_CLASSES = "package_ipk" is configured and I see packages in my 
> /build/tmp/deploy/ipk directory
> 
> The target boots fine and I have the appropriate opkg applications installed 
> (e.g. opkg, opkg-cl, opkg-key). I also have the default /etc/opkg/opkg.conf 
> and /etc/opkg/arch.conf installed.
> 
> There is *no* /var/lib/opkg directory and thus "opkg-cl list-installed" 
> returns with an error because the "opkg" directory is missing. If I manually 
> create it the program run successfully but doesn't list anything (which is 
> obvious since it is empty).
> 
> I read this post
> https://lists.yoctoproject.org/pipermail/yocto/2013-June/016324.html
> 
> and confirmed that my setting are correct for IMAGE_FEATURES and 
> ROOT_POSTPROCESS_CMD (= "run_intercept_scriptlets; license_create_manifest;  
> ssh_allow_empty_password;  rootfs_update_timestamp ;")
> 
> Can anyone offer any suggestions, recommendations, or answers to my questions 
> above?
> 

something is not adding up.

either you have "remove_packaging_data_files" in ROOTFS_POSTPROCESS_COMMAND or 
'package-management' is missing in IMAGE_FEATURES

Can you paste output of bitbake -e 
somewhere ?

> Thanks for you help . . .
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] OPKG configuration questions

[Glenn Schmottlach]

>
> On 17 October 2013 11:20, Glenn Schmottlach  wrote:
>> > Just out of curiosity, is it possible that you added "package-management"
>> > to IMAGE_FEATURES after you already had a successful full build? Or is
>> > it possible that you had already done a full build with "package_rpm" or
>> > "_deb" before switching to "package_ipk"?
>> >
>>
>> I added "package-management" after a successful build.
>
> In that case, if you have the time, I would delete your tmp,
> sstate-cache, and cache directories, as well as your bitbake.lock and
> pseudodone files and rebuild. Does that make any difference?
>

Unbeknownst to me, the "init" script on the target platform was
mounting a tmpfs (ramdisk) filesystem over the top of "/var" thereby
hiding the fact that the opkg database had indeed been installed. So,
once I realized this it was clear why I wasn't see these files when
the target booted.

>> > The reason I ask is (although I never confirmed this definitively but) when
>> > I was playing with this stuff a while back I was sure that this package
>> > stuff
>> > would only get generated after adjusting these configurations when a full,
>> > clean build was performed (i.e. removing  and ).
>
>> After manually copying the /var/lib/opkg to my target the opkg-cl
>> command now seems to "work". Unfortunately I'm running into difficulty
>> specifying a a new ipkg repo that is mounted via NFS from my
>> development machine. How would I make it scan there as well?
>
> I've never tried that before. But maybe if you created a file (on the
> target) called, for example, /etc/opkg/nfs.conf which contained:
>
> src/gz nfs /path/to/nfs
>
> maybe that would work? Don't forget to perform an "# opkg update"
> after creating that file.
>

After some trial-and-error (and remembering to call opkg-cl update as
you suggested) I was able to get my alternative feed to work. So at
this point, I *think* I have it all figured out ;-)

Thanks to those on the list who offered their suggestions!


> There's also a remote chance adding this new repository doesn't appear
> to work because your target filesystem is full. I've noticed that in
> the past, and opkg doesn't provide much in the way of feedback if/when
> this happens.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] OPKG package management issue

[Abhishekh Awanti]

Hi,

I am trying to install *.ipk* with *opkg* in yocto.

 If i run below command

*opkg install *.ipk*

 I am getting the below error:-


* Collected errors: * opkg_conf_load: Could not create lock file
/var/lib/opkg/lock: No such file or directory.*

I did some research and followed this link

http://wiki.hioproject.org/index.php?title=Yocto:_Opkg_Package_Management_System_Set_Up

I came to know that one should add in the *conf/local.conf*

*EXTRA_IMAGE_FEATURES = "package-management"*
>
> *IMAGE_INSTALL_append = " opkg "*
>
> *PACKAGE_CLASSES = "package_ipk"*
>

Even though i am getting the same error.

*"/var/lib/opkg/"*  is existed in my image build directory, but after
installing the image to the target device the *"/var/lib/opkg/"* is not
appearing.

I am guessing that, the disappearance of the */var/lib/opkg* folder may be
causing the opkg error.

Can anybody please help me on this problem.

Thank you,
Abhishek
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] opkg list-installed is empty

[Seth Bollinger]

Hello All,

I'm having a problem with opkg.  When I run the image I've built with the
package-management feature and PACKAGE_CLASS equal to package_ipk, the
image has no installed packages.  They're obviously installed, because it's
running but "opkg list-installed" is empty.  I was expecting a large list
of installed packages.  I don't see anything I would expect to see in
/var/lib/opkg.  I must be missing something fundamental, but after
reviewing the documentation and code, I'm coming up empty.  Please
enlighten me!

Thanks,

Seth
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] opkg git and download hosting

[Paul Barker]

Hi all,

I'm looking at moving opkg away from Subversion hosted on Google Code
to Git hosted elsewhere. Google Code is also closing the downloads
service to new files after January so we'll need somewhere else to put
tarballs of opkg releases. It's previously been mentioned that The
Yocto Project may be able to help us with this. I've got a few
questions on how this would work if we can do it. Is there anyone in
particular I need to talk to or should we just discuss this on list?

Thanks,

-- 
Paul Barker

Email: p...@paulbarker.me.uk
http://www.paulbarker.me.uk
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] OPKG package management issue

[Hofemeier, Ulf]

Hi Abhishek,

Can you please create this directory and see if opkg will work after that?

Thanks,
Ulf


From:  on behalf of Abhishekh Awanti 

Date: Tuesday, April 18, 2017 at 4:15 AM
To: "yocto@yoctoproject.org" 
Subject: [yocto] OPKG package management issue

Hi,

I am trying to install .ipk with opkg in yocto.

 If i run below command

opkg install *.ipk

 I am getting the below error:-

 Collected errors:
 * opkg_conf_load: Could not create lock file /var/lib/opkg/lock: No such file 
or directory.

I did some research and followed this link

http://wiki.hioproject.org/index.php?title=Yocto:_Opkg_Package_Management_System_Set_Up

I came to know that one should add in the conf/local.conf
EXTRA_IMAGE_FEATURES = "package-management"

IMAGE_INSTALL_append = " opkg "

PACKAGE_CLASSES = "package_ipk"

Even though i am getting the same error.

"/var/lib/opkg/"  is existed in my image build directory, but after installing 
the image to the target device the "/var/lib/opkg/" is not appearing.

I am guessing that, the disappearance of the /var/lib/opkg folder may be 
causing the opkg error.

Can anybody please help me on this problem.

Thank you,
Abhishek



-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] opkg 0.3.0 or rootfs task

[Ahsan, Noor]

Hello,

I noticed that at the time of rootfs creation symbolic links of the ipk files 
present in deploy/ipk. The problem what have it while creation of symbolic link 
it take the full path till that ipk and remove slashes and convert them into 
underscores. Use that as the name of the symbolic link. This make a very long 
file names. If we have very long path then name of the symlink exceed from max 
filename limits. And we get following error

Collected errors:
* file_link: unable to stat 
`/var/jenkins/workspace/mel_cedar-main/buildhost/amd-ubuntu14-32b/buildtype/iot/machine/mel-dra7xx-evm/build_mel-dra7xx-evm/tmp/work/mel_dra7xx_evm-mel-linux-gnueabi/console-image/1.0-r0/rootfs//var/cache/opkg/volatile/file:_var_jenkins_workspace_mel_cedar-main_buildhost_amd-ubuntu14-32b_buildtype_iot_machine_mel-dra7xx-evm_build_mel-dra7xx-evm_tmp_deploy_ipk_mel_dra7xx_evm_kernel-module-lttng-ring-buffer-client-mmap-overwrite_2.6.2+git0+7a88f8b506-r0.0_mel_dra7xx_evm.ipk':
 File name too long.

Can anyone tell me why the addition of full path was added to the symlink name 
and can we remove it cause it is cause issues?

Noor
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] opkg-utils to move to git.yoctoproject.org

[Saul Wold]

Folks,

Currently opkg-utils is hosted on svn.openmoko.org, that host seems to 
be failing and is not a reliable upstream.  We have a copy of opkg-utils 
under git.yoctoproject.org (captured the last time svn.openmoko.org was 
up).  This move would also allow us to apply some pending patches.


We will make this change next week barring any major objections.


--
Sau!

Saul Wold
Yocto Component Wrangler @ Intel
Yocto Project / Poky Build System

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] opkg list-installed is empty

[Paul Eggleton]

Hi Seth,

On Monday 03 June 2013 06:49:06 Seth Bollinger wrote:
> I'm having a problem with opkg.  When I run the image I've built with the
> package-management feature and PACKAGE_CLASS equal to package_ipk, the
> image has no installed packages.  They're obviously installed, because it's
> running but "opkg list-installed" is empty.  I was expecting a large list
> of installed packages.  I don't see anything I would expect to see in
> /var/lib/opkg.  I must be missing something fundamental, but after
> reviewing the documentation and code, I'm coming up empty.  Please
> enlighten me!

If /var/lib/opkg is empty in your image, it can only be because its contents 
have been deleted; and that could be either because the value of 
IMAGE_FEATURES doesn't end up containing package-management, or alternatively 
remove_packaging_data_files is being added manually to 
ROOTFS_POSTPROCESS_COMMAND (as core-image-minimal does). I'd suggest using 
bitbake -e your-image | less and looking at the values of IMAGE_FEATURES and 
ROOTFS_POSTPROCESS_COMMAND to see what's really going on.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] opkg list-installed is empty

[seth bollinger]

   	   
   	Paul Eggleton  
  June 3, 2013 7:10
 47AM
  Hi Seth,If
 /var/lib/opkg is empty in your image, it can only be because its 
contents have been deleted; and that could be either because the 
value of IMAGE_FEATURES doesn't end up containing 
package-management, or alternatively remove_packaging_data_files is 
being added manually to ROOTFS_POSTPROCESS_COMMAND (as 
core-image-minimal does). I'd suggest using bitbake -e your-image | 
less and looking at the values of IMAGE_FEATURES and ROOTFS_POSTPROCESS_COMMAND
 to see what's really going on.Cheers,Paul

Thanks Paul!  As usual, you nailed it.  I missed the 
ROOTFS_POSTPROCESS_COMMAND that I pulled in when I copied 
core-image-minimal.

Seth


___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] opkg git and download hosting

[Trevor Woerner]

On 30 October 2013 11:47, Paul Barker  wrote:
> I'm looking at moving opkg away from Subversion hosted on Google Code
> to Git hosted elsewhere.

> It's previously been mentioned that The
> Yocto Project may be able to help us with this.

Does opkg (as a project) fall under the Yocto umbrella?
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] opkg git and download hosting

[Saul Wold]

On 10/31/2013 10:59 AM, Trevor Woerner wrote:

On 30 October 2013 11:47, Paul Barker  wrote:

I'm looking at moving opkg away from Subversion hosted on Google Code
to Git hosted elsewhere.



It's previously been mentioned that The
Yocto Project may be able to help us with this.


Does opkg (as a project) fall under the Yocto umbrella?


I don't see why not.

Paul:  Please check with Michael Halstead, I think he might be able to 
help answer your direct quesions, other issues can be discussed on the list.


Sau!


___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto



___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] opkg git and download hosting

[Philip Balister]

On 10/31/2013 11:19 AM, Saul Wold wrote:
> On 10/31/2013 10:59 AM, Trevor Woerner wrote:
>> On 30 October 2013 11:47, Paul Barker  wrote:
>>> I'm looking at moving opkg away from Subversion hosted on Google Code
>>> to Git hosted elsewhere.
>>
>>> It's previously been mentioned that The
>>> Yocto Project may be able to help us with this.
>>
>> Does opkg (as a project) fall under the Yocto umbrella?
> 

I like the use of the word "umbrella".

Philip

> I don't see why not.
> 
> Paul:  Please check with Michael Halstead, I think he might be able to
> help answer your direct quesions, other issues can be discussed on the
> list.
> 
> Sau!
> 
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>>
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
> 
> 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] opkg and gpg signed ipk packages

[Sona Sarmadi]

Hi,

Does opkg have support for gpg signed ipk packages? It seems like that opkg 
does not recognize gpg signed files. 

root@p2020rdb:~# opkg list-upgradable
curl - 7.35.0-r2.0 - 7.35.0-r3.0
curl-dbg - 7.35.0-r2.0 - 7.35.0-r3.0
libcurl5 - 7.35.0-r2.0 - 7.35.0-r3.0
root@p2020rdb:~# opkg upgrade curl
Upgrading curl on root from 7.35.0-r2.0 to 7.35.0-r3.0...
Downloading 
http://domain.com/tmp/ipk/ppce500v2/curl_7.35.0-r3.0_ppce500v2.ipk.asc.
Collected errors:
 * deb_extract: /tmp/opkg-tslkbd/curl_7.35.0-r3.0_ppce500v2.ipk.asc: invalid 
magic
 * opkg_install_pkg: Failed to unpack control files from 
/tmp/opkg-tslkbd/curl_7.35.0-r3.0_ppce500v2.ipk.asc.
root@p2020rdb:~#

I have updated the Package file manually:
Package: curl
Version: 7.35.0-r3.0
Depends: libcurl5 (>= 7.35.0), libz1 (>= 1.2.8), libc6 (>= 2.19)
Section: console/network
Architecture: ppce500v2
Maintainer: ENEA 
MD5Sum: 725f019d72b6f70845ae19299230738a
Size: 95616
Filename: curl_7.35.0-r3.0_ppce500v2.ipk.asc
Source: http://curl.haxx.se/download/curl-7.35.0.tar.bz2 
file://pkgconfig_fix.patch file://CVE-2014-3613.patch file://configure_ac.patch
Description:  Command line tool and library for client-side URL transfers  
Command line
 tool and library for client-side URL transfers.
OE: curl
HomePage: http://curl.haxx.se/
License: MIT
Priority: optional

Thanks
//Sona
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] opkg 0.3.0 or rootfs task

[Khem Raj]

> On Oct 16, 2015, at 5:47 AM, Ahsan, Noor  wrote:
> 
> Hello,
> 
> I noticed that at the time of rootfs creation symbolic links of the ipk files 
> present in deploy/ipk. The problem what have it while creation of symbolic 
> link it take the full path till that ipk and remove slashes and convert them 
> into underscores. Use that as the name of the symbolic link. This make a very 
> long file names. If we have very long path then name of the symlink exceed 
> from max filename limits. And we get following error
> 
> Collected errors:
> * file_link: unable to stat 
> `/var/jenkins/workspace/mel_cedar-main/buildhost/amd-ubuntu14-32b/buildtype/iot/machine/mel-dra7xx-evm/build_mel-dra7xx-evm/tmp/work/mel_dra7xx_evm-mel-linux-gnueabi/console-image/1.0-r0/rootfs//var/cache/opkg/volatile/file:_var_jenkins_workspace_mel_cedar-main_buildhost_amd-ubuntu14-32b_buildtype_iot_machine_mel-dra7xx-evm_build_mel-dra7xx-evm_tmp_deploy_ipk_mel_dra7xx_evm_kernel-module-lttng-ring-buffer-client-mmap-overwrite_2.6.2+git0+7a88f8b506-r0.0_mel_dra7xx_evm.ipk':
>  File name too long.
> 
> Can anyone tell me why the addition of full path was added to the symlink 
> name and can we remove it cause it is cause issues?

what does

getconf PATH_MAX /

show ?

> 
> Noor
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org 
> https://lists.yoctoproject.org/listinfo/yocto 
> 


signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] opkg 0.3.0 or rootfs task

[Ahsan, Noor]

From: Khem Raj [mailto:raj.k...@gmail.com]
Sent: Friday, October 16, 2015 9:54 PM
To: Ahsan, Noor
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] opkg 0.3.0 or rootfs task


On Oct 16, 2015, at 5:47 AM, Ahsan, Noor 
mailto:noor_ah...@mentor.com>> wrote:

Hello,

I noticed that at the time of rootfs creation symbolic links of the ipk files 
present in deploy/ipk. The problem what have it while creation of symbolic link 
it take the full path till that ipk and remove slashes and convert them into 
underscores. Use that as the name of the symbolic link. This make a very long 
file names. If we have very long path then name of the symlink exceed from max 
filename limits. And we get following error

Collected errors:
* file_link: unable to stat 
`/var/jenkins/workspace/mel_cedar-main/buildhost/amd-ubuntu14-32b/buildtype/iot/machine/mel-dra7xx-evm/build_mel-dra7xx-evm/tmp/work/mel_dra7xx_evm-mel-linux-gnueabi/console-image/1.0-r0/rootfs//var/cache/opkg/volatile/file:_var_jenkins_workspace_mel_cedar-main_buildhost_amd-ubuntu14-32b_buildtype_iot_machine_mel-dra7xx-evm_build_mel-dra7xx-evm_tmp_deploy_ipk_mel_dra7xx_evm_kernel-module-lttng-ring-buffer-client-mmap-overwrite_2.6.2+git0+7a88f8b506-r0.0_mel_dra7xx_evm.ipk':
 File name too long.

Can anyone tell me why the addition of full path was added to the symlink name 
and can we remove it cause it is cause issues?

what does

getconf PATH_MAX /

show ?


jenkins@amd-ubu14-32-3:~$ getconf -a | grep  PATH_MAX
PATH_MAX   4096
_POSIX_PATH_MAX4096

Noor
--
___
yocto mailing list
yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>
https://lists.yoctoproject.org/listinfo/yocto

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] opkg 0.3.0 or rootfs task

[Ahsan, Noor]

From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Ahsan, Noor
Sent: Friday, October 16, 2015 11:55 PM
To: Khem Raj
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] opkg 0.3.0 or rootfs task



From: Khem Raj [mailto:raj.k...@gmail.com]
Sent: Friday, October 16, 2015 9:54 PM
To: Ahsan, Noor
Cc: yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>
Subject: Re: [yocto] opkg 0.3.0 or rootfs task


On Oct 16, 2015, at 5:47 AM, Ahsan, Noor 
mailto:noor_ah...@mentor.com>> wrote:

Hello,

I noticed that at the time of rootfs creation symbolic links of the ipk files 
present in deploy/ipk. The problem what have it while creation of symbolic link 
it take the full path till that ipk and remove slashes and convert them into 
underscores. Use that as the name of the symbolic link. This make a very long 
file names. If we have very long path then name of the symlink exceed from max 
filename limits. And we get following error

Collected errors:
* file_link: unable to stat 
`/var/jenkins/workspace/mel_cedar-main/buildhost/amd-ubuntu14-32b/buildtype/iot/machine/mel-dra7xx-evm/build_mel-dra7xx-evm/tmp/work/mel_dra7xx_evm-mel-linux-gnueabi/console-image/1.0-r0/rootfs//var/cache/opkg/volatile/file:_var_jenkins_workspace_mel_cedar-main_buildhost_amd-ubuntu14-32b_buildtype_iot_machine_mel-dra7xx-evm_build_mel-dra7xx-evm_tmp_deploy_ipk_mel_dra7xx_evm_kernel-module-lttng-ring-buffer-client-mmap-overwrite_2.6.2+git0+7a88f8b506-r0.0_mel_dra7xx_evm.ipk':
 File name too long.

Can anyone tell me why the addition of full path was added to the symlink name 
and can we remove it cause it is cause issues?

what does

getconf PATH_MAX /

show ?

jenkins@amd-ubu14-32-3:~$ getconf -a | grep  PATH_MAX
PATH_MAX   4096
_POSIX_PATH_MAX4096


I think the issue is with file name not the path.

Secondly the googling which I did reveals that symlink creation can't be 
stopped. I just wanna confirm that is my findings correct?

Noor
--
___
yocto mailing list
yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>
https://lists.yoctoproject.org/listinfo/yocto

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] opkg 0.3.0 or rootfs task

[Paul Barker]

On Fri, Oct 16, 2015 at 07:38:19PM +, Ahsan, Noor wrote:
> On Oct 16, 2015, at 5:47 AM, Ahsan, Noor 
> mailto:noor_ah...@mentor.com>> wrote:
> 
> Hello,
> 
> I noticed that at the time of rootfs creation symbolic links of the ipk files 
> present in deploy/ipk. The problem what have it while creation of symbolic 
> link it take the full path till that ipk and remove slashes and convert them 
> into underscores. Use that as the name of the symbolic link. This make a very 
> long file names. If we have very long path then name of the symlink exceed 
> from max filename limits. And we get following error
> 
> Collected errors:
> * file_link: unable to stat 
> `/var/jenkins/workspace/mel_cedar-main/buildhost/amd-ubuntu14-32b/buildtype/iot/machine/mel-dra7xx-evm/build_mel-dra7xx-evm/tmp/work/mel_dra7xx_evm-mel-linux-gnueabi/console-image/1.0-r0/rootfs//var/cache/opkg/volatile/file:_var_jenkins_workspace_mel_cedar-main_buildhost_amd-ubuntu14-32b_buildtype_iot_machine_mel-dra7xx-evm_build_mel-dra7xx-evm_tmp_deploy_ipk_mel_dra7xx_evm_kernel-module-lttng-ring-buffer-client-mmap-overwrite_2.6.2+git0+7a88f8b506-r0.0_mel_dra7xx_evm.ipk':
>  File name too long.
> 
> Can anyone tell me why the addition of full path was added to the symlink 
> name and can we remove it cause it is cause issues?
> 
> what does
> 
> getconf PATH_MAX /
> 
> show ?
> 
> jenkins@amd-ubu14-32-3:~$ getconf -a | grep  PATH_MAX
> PATH_MAX   4096
> _POSIX_PATH_MAX4096
> 
> 
> I think the issue is with file name not the path.
> 
> Secondly the googling which I did reveals that symlink creation can't be 
> stopped. I just wanna confirm that is my findings correct?
> 

This looks like something we overlooked in opkg. When we added the caching code
we didn't think about how long the paths and filenames might get during the
rootfs step. It's not currently possible to reduce the length of the symlink
filenames, but it is possible to change the directory in which the symlinks are
created.

Currently the opkg cache dir can only be set in the opkg.conf file. I think we
should add a '--cache-dir' argument to opkg. If this is added you'll be able to
set the following in your local.conf file to change the cache location. Eg. to
use '/tmp/opkg' on the host during rootfs creation.

OPKG_ARGS = "--cache-dir=/tmp/opkg"

I'll submit a patch to opkg to add this option.

Thanks,

-- 
Paul Barker

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


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] opkg 0.3.0 or rootfs task

[Christopher Larson]

On Sun, Oct 18, 2015 at 2:57 AM, Paul Barker  wrote:

> On Fri, Oct 16, 2015 at 07:38:19PM +, Ahsan, Noor wrote:
> > On Oct 16, 2015, at 5:47 AM, Ahsan, Noor  noor_ah...@mentor.com>> wrote:
> >
> > Hello,
> >
> > I noticed that at the time of rootfs creation symbolic links of the ipk
> files present in deploy/ipk. The problem what have it while creation of
> symbolic link it take the full path till that ipk and remove slashes and
> convert them into underscores. Use that as the name of the symbolic link.
> This make a very long file names. If we have very long path then name of
> the symlink exceed from max filename limits. And we get following error
> >
> > Collected errors:
> > * file_link: unable to stat
> `/var/jenkins/workspace/mel_cedar-main/buildhost/amd-ubuntu14-32b/buildtype/iot/machine/mel-dra7xx-evm/build_mel-dra7xx-evm/tmp/work/mel_dra7xx_evm-mel-linux-gnueabi/console-image/1.0-r0/rootfs//var/cache/
> opkg/volatile/file:_var_jenkins_workspace_mel_cedar-main_buildhost_amd-ubuntu14-32b_buildtype_iot_machine_mel-dra7xx-evm_build_mel-dra7xx-evm_tmp_deploy_ipk_mel_dra7xx_evm_kernel-module-lttng-ring-buffer-client-mmap-overwrite_2.6.2+git0+7a88f8b506-r0.0_mel_dra7xx_evm.ipk':
> File name too long.
> >
> > Can anyone tell me why the addition of full path was added to the
> symlink name and can we remove it cause it is cause issues?
> >
> > what does
> >
> > getconf PATH_MAX /
> >
> > show ?
> >
> > jenkins@amd-ubu14-32-3:~$ getconf -a | grep  PATH_MAX
> > PATH_MAX   4096
> > _POSIX_PATH_MAX4096
> >
> >
> > I think the issue is with file name not the path.
> >
> > Secondly the googling which I did reveals that symlink creation can't be
> stopped. I just wanna confirm that is my findings correct?
> >
>
> This looks like something we overlooked in opkg. When we added the
> caching code
> we didn't think about how long the paths and filenames might get during the
> rootfs step. It's not currently possible to reduce the length of the
> symlink
> filenames, but it is possible to change the directory in which the
> symlinks are
> created.
>
> Currently the opkg cache dir can only be set in the opkg.conf file. I
> think we
> should add a '--cache-dir' argument to opkg. If this is added you'll be
> able to
> set the following in your local.conf file to change the cache location.
> Eg. to
> use '/tmp/opkg' on the host during rootfs creation.
>
> OPKG_ARGS = "--cache-dir=/tmp/opkg"
>
> I'll submit a patch to opkg to add this option.
>

This will only shorten the full path, not the filename length, so I doubt
this'll solve it. That said, I can't actually successfully test this today,
because cache_dir is made relative to offline_root, so setting such a path
as you suggest doesn't shorten the full path either.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] opkg 0.3.0 or rootfs task

[Christopher Larson]

On Tue, Oct 20, 2015 at 10:14 AM, Christopher Larson 
wrote:

>
> On Sun, Oct 18, 2015 at 2:57 AM, Paul Barker 
> wrote:
>
>> On Fri, Oct 16, 2015 at 07:38:19PM +, Ahsan, Noor wrote:
>> > On Oct 16, 2015, at 5:47 AM, Ahsan, Noor > noor_ah...@mentor.com>> wrote:
>> >
>> > Hello,
>> >
>> > I noticed that at the time of rootfs creation symbolic links of the ipk
>> files present in deploy/ipk. The problem what have it while creation of
>> symbolic link it take the full path till that ipk and remove slashes and
>> convert them into underscores. Use that as the name of the symbolic link.
>> This make a very long file names. If we have very long path then name of
>> the symlink exceed from max filename limits. And we get following error
>> >
>> > Collected errors:
>> > * file_link: unable to stat
>> `/var/jenkins/workspace/mel_cedar-main/buildhost/amd-ubuntu14-32b/buildtype/iot/machine/mel-dra7xx-evm/build_mel-dra7xx-evm/tmp/work/mel_dra7xx_evm-mel-linux-gnueabi/console-image/1.0-r0/rootfs//var/cache/
>> opkg/volatile/file:_var_jenkins_workspace_mel_cedar-main_buildhost_amd-ubuntu14-32b_buildtype_iot_machine_mel-dra7xx-evm_build_mel-dra7xx-evm_tmp_deploy_ipk_mel_dra7xx_evm_kernel-module-lttng-ring-buffer-client-mmap-overwrite_2.6.2+git0+7a88f8b506-r0.0_mel_dra7xx_evm.ipk':
>> File name too long.
>> >
>> > Can anyone tell me why the addition of full path was added to the
>> symlink name and can we remove it cause it is cause issues?
>> >
>> > what does
>> >
>> > getconf PATH_MAX /
>> >
>> > show ?
>> >
>> > jenkins@amd-ubu14-32-3:~$ getconf -a | grep  PATH_MAX
>> > PATH_MAX   4096
>> > _POSIX_PATH_MAX4096
>> >
>> >
>> > I think the issue is with file name not the path.
>> >
>> > Secondly the googling which I did reveals that symlink creation can't
>> be stopped. I just wanna confirm that is my findings correct?
>> >
>>
>> This looks like something we overlooked in opkg. When we added the
>> caching code
>> we didn't think about how long the paths and filenames might get during
>> the
>> rootfs step. It's not currently possible to reduce the length of the
>> symlink
>> filenames, but it is possible to change the directory in which the
>> symlinks are
>> created.
>>
>> Currently the opkg cache dir can only be set in the opkg.conf file. I
>> think we
>> should add a '--cache-dir' argument to opkg. If this is added you'll be
>> able to
>> set the following in your local.conf file to change the cache location.
>> Eg. to
>> use '/tmp/opkg' on the host during rootfs creation.
>>
>> OPKG_ARGS = "--cache-dir=/tmp/opkg"
>>
>> I'll submit a patch to opkg to add this option.
>>
>
> This will only shorten the full path, not the filename length, so I doubt
> this'll solve it. That said, I can't actually successfully test this today,
> because cache_dir is made relative to offline_root, so setting such a path
> as you suggest doesn't shorten the full path either.


Also, did a touch of just the cache filename and it gives the same filename
length error, so where the cache dir is really isn't going to matter, it's
the filename including the full path to a deep BUILDDIR, and therefore
DEPLOY_DIR_IPK, which is the problem.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] opkg 0.3.0 or rootfs task

[Ahsan, Noor]

We are hitting this issue on another BSP

file:_var_jenkins_workspace_ce-main_buildhost_SB64_buildtype_industrial_machine_zedboard-zynq7-mel_build_zedboard-zynq7-mel_tmp_deploy_ipk_zedboard_zynq7_mel_kernel-module-lttng-ring-buffer-client-mmap-overwrite_2.6.2+git0+7a88f8b506-r0.0_zedboard_zynq7_mel.ipk

need its solution quickly

Noor

From: kerg...@gmail.com [mailto:kerg...@gmail.com] On Behalf Of Christopher 
Larson
Sent: Tuesday, October 20, 2015 10:20 PM
To: Paul Barker
Cc: Ahsan, Noor; yocto@yoctoproject.org
Subject: Re: [yocto] opkg 0.3.0 or rootfs task


On Tue, Oct 20, 2015 at 10:14 AM, Christopher Larson 
mailto:clar...@kergoth.com>> wrote:

On Sun, Oct 18, 2015 at 2:57 AM, Paul Barker 
mailto:p...@paulbarker.me.uk>> wrote:
On Fri, Oct 16, 2015 at 07:38:19PM +, Ahsan, Noor wrote:
> On Oct 16, 2015, at 5:47 AM, Ahsan, Noor 
> mailto:noor_ah...@mentor.com><mailto:noor_ah...@mentor.com<mailto:noor_ah...@mentor.com>>>
>  wrote:
>
> Hello,
>
> I noticed that at the time of rootfs creation symbolic links of the ipk files 
> present in deploy/ipk. The problem what have it while creation of symbolic 
> link it take the full path till that ipk and remove slashes and convert them 
> into underscores. Use that as the name of the symbolic link. This make a very 
> long file names. If we have very long path then name of the symlink exceed 
> from max filename limits. And we get following error
>
> Collected errors:
> * file_link: unable to stat 
> `/var/jenkins/workspace/mel_cedar-main/buildhost/amd-ubuntu14-32b/buildtype/iot/machine/mel-dra7xx-evm/build_mel-dra7xx-evm/tmp/work/mel_dra7xx_evm-mel-linux-gnueabi/console-image/1.0-r0/rootfs//var/cache/opkg/volatile/file:_var_jenkins_workspace_mel_cedar-main_buildhost_amd-ubuntu14-32b_buildtype_iot_machine_mel-dra7xx-evm_build_mel-dra7xx-evm_tmp_deploy_ipk_mel_dra7xx_evm_kernel-module-lttng-ring-buffer-client-mmap-overwrite_2.6.2+git0+7a88f8b506-r0.0_mel_dra7xx_evm.ipk':
>  File name too long.
>
> Can anyone tell me why the addition of full path was added to the symlink 
> name and can we remove it cause it is cause issues?
>
> what does
>
> getconf PATH_MAX /
>
> show ?
>
> jenkins@amd-ubu14-32-3:~$ getconf -a | grep  PATH_MAX
> PATH_MAX   4096
> _POSIX_PATH_MAX4096
>
>
> I think the issue is with file name not the path.
>
> Secondly the googling which I did reveals that symlink creation can't be 
> stopped. I just wanna confirm that is my findings correct?
>

This looks like something we overlooked in opkg. When we added the caching code
we didn't think about how long the paths and filenames might get during the
rootfs step. It's not currently possible to reduce the length of the symlink
filenames, but it is possible to change the directory in which the symlinks are
created.

Currently the opkg cache dir can only be set in the opkg.conf file. I think we
should add a '--cache-dir' argument to opkg. If this is added you'll be able to
set the following in your local.conf file to change the cache location. Eg. to
use '/tmp/opkg' on the host during rootfs creation.

OPKG_ARGS = "--cache-dir=/tmp/opkg"

I'll submit a patch to opkg to add this option.

This will only shorten the full path, not the filename length, so I doubt 
this'll solve it. That said, I can't actually successfully test this today, 
because cache_dir is made relative to offline_root, so setting such a path as 
you suggest doesn't shorten the full path either.

Also, did a touch of just the cache filename and it gives the same filename 
length error, so where the cache dir is really isn't going to matter, it's the 
filename including the full path to a deep BUILDDIR, and therefore 
DEPLOY_DIR_IPK, which is the problem.
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] opkg 0.3.0 or rootfs task

[Alejandro del Castillo]

On 10/21/2015 02:49 AM, Ahsan, Noor wrote:

We are hitting this issue on another BSP

file:_var_jenkins_workspace_ce-main_buildhost_SB64_buildtype_industrial_machine_zedboard-zynq7-mel_build_zedboard-zynq7-mel_tmp_deploy_ipk_zedboard_zynq7_mel_kernel-module-lttng-ring-buffer-client-mmap-overwrite_2.6.2+git0+7a88f8b506-r0.0_zedboard_zynq7_mel.ipk

need its solution quickly


If you are in need of a quick workaround, try setting:

option cache_local_files 0

on opkg.conf. This will make a copy of your ipk's instead of creating 
symlinks (haven't try it myself, but that's my understanding).


Also, please open a bug report for opkg on 
https://bugzilla.yoctoproject.org to track the issue.



*From:*kerg...@gmail.com [mailto:kerg...@gmail.com] *On Behalf Of
*Christopher Larson
*Sent:* Tuesday, October 20, 2015 10:20 PM
*To:* Paul Barker
*Cc:* Ahsan, Noor; yocto@yoctoproject.org
*Subject:* Re: [yocto] opkg 0.3.0 or rootfs task

On Tue, Oct 20, 2015 at 10:14 AM, Christopher Larson
mailto:clar...@kergoth.com>> wrote:

On Sun, Oct 18, 2015 at 2:57 AM, Paul Barker mailto:p...@paulbarker.me.uk>> wrote:

On Fri, Oct 16, 2015 at 07:38:19PM +, Ahsan, Noor wrote:
 > On Oct 16, 2015, at 5:47 AM, Ahsan, Noor
mailto:noor_ah...@mentor.com><mailto:noor_ah...@mentor.com
<mailto:noor_ah...@mentor.com>>> wrote:
 >
 > Hello,
 >
 > I noticed that at the time of rootfs creation symbolic links
of the ipk files present in deploy/ipk. The problem what have it
while creation of symbolic link it take the full path till that
ipk and remove slashes and convert them into underscores. Use
that as the name of the symbolic link. This make a very long
file names. If we have very long path then name of the symlink
exceed from max filename limits. And we get following error
 >
 > Collected errors:
 > * file_link: unable to stat

`/var/jenkins/workspace/mel_cedar-main/buildhost/amd-ubuntu14-32b/buildtype/iot/machine/mel-dra7xx-evm/build_mel-dra7xx-evm/tmp/work/mel_dra7xx_evm-mel-linux-gnueabi/console-image/1.0-r0/rootfs//var/cache/opkg/volatile/file:_var_jenkins_workspace_mel_cedar-main_buildhost_amd-ubuntu14-32b_buildtype_iot_machine_mel-dra7xx-evm_build_mel-dra7xx-evm_tmp_deploy_ipk_mel_dra7xx_evm_kernel-module-lttng-ring-buffer-client-mmap-overwrite_2.6.2+git0+7a88f8b506-r0.0_mel_dra7xx_evm.ipk':
File name too long.
 >
 > Can anyone tell me why the addition of full path was added to
the symlink name and can we remove it cause it is cause issues?
 >
 > what does
 >
 > getconf PATH_MAX /
 >
 > show ?
 >
 > jenkins@amd-ubu14-32-3:~$ getconf -a | grep  PATH_MAX
 > PATH_MAX   4096
 > _POSIX_PATH_MAX4096
 >
 >
 > I think the issue is with file name not the path.
 >
 > Secondly the googling which I did reveals that symlink
creation can't be stopped. I just wanna confirm that is my
findings correct?
 >

This looks like something we overlooked in opkg. When we added
the caching code
we didn't think about how long the paths and filenames might get
during the
rootfs step. It's not currently possible to reduce the length of
the symlink
filenames, but it is possible to change the directory in which
the symlinks are
created.

Currently the opkg cache dir can only be set in the opkg.conf
file. I think we
should add a '--cache-dir' argument to opkg. If this is added
you'll be able to
set the following in your local.conf file to change the cache
location. Eg. to
use '/tmp/opkg' on the host during rootfs creation.

 OPKG_ARGS = "--cache-dir=/tmp/opkg"

I'll submit a patch to opkg to add this option.

This will only shorten the full path, not the filename length, so I
doubt this'll solve it. That said, I can't actually successfully
test this today, because cache_dir is made relative to offline_root,
so setting such a path as you suggest doesn't shorten the full path
either.


Also, did a touch of just the cache filename and it gives the same
filename length error, so where the cache dir is really isn't going to
matter, it's the filename including the full path to a deep BUILDDIR,
and therefore DEPLOY_DIR_IPK, which is the problem.
--

Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics




--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] opkg 0.3.0 or rootfs task

[Christopher Larson]

Not likely to help. The problem is the filename length, which will be the
same whether it's a file or a symlink.
On Sat, Oct 24, 2015 at 10:53 AM Alejandro del Castillo <
alejandro.delcasti...@ni.com> wrote:

>
>
> On 10/21/2015 02:49 AM, Ahsan, Noor wrote:
> > We are hitting this issue on another BSP
> >
> >
> file:_var_jenkins_workspace_ce-main_buildhost_SB64_buildtype_industrial_machine_zedboard-zynq7-mel_build_zedboard-zynq7-mel_tmp_deploy_ipk_zedboard_zynq7_mel_kernel-module-lttng-ring-buffer-client-mmap-overwrite_2.6.2+git0+7a88f8b506-r0.0_zedboard_zynq7_mel.ipk
> >
> > need its solution quickly
>
> If you are in need of a quick workaround, try setting:
>
> option cache_local_files 0
>
> on opkg.conf. This will make a copy of your ipk's instead of creating
> symlinks (haven't try it myself, but that's my understanding).
>
> Also, please open a bug report for opkg on
> https://bugzilla.yoctoproject.org to track the issue.
>
> > *From:*kerg...@gmail.com [mailto:kerg...@gmail.com] *On Behalf Of
> > *Christopher Larson
> > *Sent:* Tuesday, October 20, 2015 10:20 PM
> > *To:* Paul Barker
> > *Cc:* Ahsan, Noor; yocto@yoctoproject.org
> > *Subject:* Re: [yocto] opkg 0.3.0 or rootfs task
> >
> > On Tue, Oct 20, 2015 at 10:14 AM, Christopher Larson
> > mailto:clar...@kergoth.com>> wrote:
> >
> > On Sun, Oct 18, 2015 at 2:57 AM, Paul Barker  > <mailto:p...@paulbarker.me.uk>> wrote:
> >
> > On Fri, Oct 16, 2015 at 07:38:19PM +, Ahsan, Noor wrote:
> >  > On Oct 16, 2015, at 5:47 AM, Ahsan, Noor
> >  > <mailto:noor_ah...@mentor.com><mailto:noor_ah...@mentor.com
> > <mailto:noor_ah...@mentor.com>>> wrote:
> >  >
> >  > Hello,
> >  >
> >  > I noticed that at the time of rootfs creation symbolic links
> > of the ipk files present in deploy/ipk. The problem what have it
> > while creation of symbolic link it take the full path till that
> > ipk and remove slashes and convert them into underscores. Use
> > that as the name of the symbolic link. This make a very long
> > file names. If we have very long path then name of the symlink
> > exceed from max filename limits. And we get following error
> >  >
> >  > Collected errors:
> >  > * file_link: unable to stat
> >
>  
> `/var/jenkins/workspace/mel_cedar-main/buildhost/amd-ubuntu14-32b/buildtype/iot/machine/mel-dra7xx-evm/build_mel-dra7xx-evm/tmp/work/mel_dra7xx_evm-mel-linux-gnueabi/console-image/1.0-r0/rootfs//var/cache/opkg/volatile/file:_var_jenkins_workspace_mel_cedar-main_buildhost_amd-ubuntu14-32b_buildtype_iot_machine_mel-dra7xx-evm_build_mel-dra7xx-evm_tmp_deploy_ipk_mel_dra7xx_evm_kernel-module-lttng-ring-buffer-client-mmap-overwrite_2.6.2+git0+7a88f8b506-r0.0_mel_dra7xx_evm.ipk':
> > File name too long.
> >  >
> >  > Can anyone tell me why the addition of full path was added to
> > the symlink name and can we remove it cause it is cause issues?
> >  >
> >  > what does
> >  >
> >  > getconf PATH_MAX /
> >  >
> >  > show ?
> >  >
> >  > jenkins@amd-ubu14-32-3:~$ getconf -a | grep  PATH_MAX
> >  > PATH_MAX   4096
> >  > _POSIX_PATH_MAX4096
> >  >
> >  >
> >  > I think the issue is with file name not the path.
> >  >
> >  > Secondly the googling which I did reveals that symlink
> > creation can't be stopped. I just wanna confirm that is my
> > findings correct?
> >  >
> >
> > This looks like something we overlooked in opkg. When we added
> > the caching code
> > we didn't think about how long the paths and filenames might get
> > during the
> > rootfs step. It's not currently possible to reduce the length of
> > the symlink
> > filenames, but it is possible to change the directory in which
> > the symlinks are
> > created.
> >
> > Currently the opkg cache dir can only be set in the opkg.conf
> > file. I think we
> > should add a '--cache-dir' argument to opkg. If this is added
> > you'll be able to
> > set the following i

Re: [yocto] opkg 0.3.0 or rootfs task

[Paul Barker]

On Sat, Oct 24, 2015 at 06:54:16PM +, Christopher Larson wrote:
> Not likely to help. The problem is the filename length, which will be the
> same whether it's a file or a symlink.
> On Sat, Oct 24, 2015 at 10:53 AM Alejandro del Castillo <
> alejandro.delcasti...@ni.com> wrote:
> 
> >
> >
> > On 10/21/2015 02:49 AM, Ahsan, Noor wrote:
> > > We are hitting this issue on another BSP
> > >
> > >
> > file:_var_jenkins_workspace_ce-main_buildhost_SB64_buildtype_industrial_machine_zedboard-zynq7-mel_build_zedboard-zynq7-mel_tmp_deploy_ipk_zedboard_zynq7_mel_kernel-module-lttng-ring-buffer-client-mmap-overwrite_2.6.2+git0+7a88f8b506-r0.0_zedboard_zynq7_mel.ipk
> > >
> > > need its solution quickly
> >
> > If you are in need of a quick workaround, try setting:
> >
> > option cache_local_files 0
> >
> > on opkg.conf. This will make a copy of your ipk's instead of creating
> > symlinks (haven't try it myself, but that's my understanding).
> >
> > Also, please open a bug report for opkg on
> > https://bugzilla.yoctoproject.org to track the issue.
> >

I've just posted patches to the opkg-devel list which should fix this. I had
intended to give them a bit more testing before I sent them but a quick fix is
needed.

Thanks,

-- 
Paul Barker

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


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] opkg 0.3.0 or rootfs task

[Christopher Larson]

On Sat, Oct 24, 2015 at 12:19 PM, Paul Barker  wrote:

> On Sat, Oct 24, 2015 at 06:54:16PM +, Christopher Larson wrote:
> > Not likely to help. The problem is the filename length, which will be the
> > same whether it's a file or a symlink.
> > On Sat, Oct 24, 2015 at 10:53 AM Alejandro del Castillo <
> > alejandro.delcasti...@ni.com> wrote:
> >
> > >
> > >
> > > On 10/21/2015 02:49 AM, Ahsan, Noor wrote:
> > > > We are hitting this issue on another BSP
> > > >
> > > >
> > >
> file:_var_jenkins_workspace_ce-main_buildhost_SB64_buildtype_industrial_machine_zedboard-zynq7-mel_build_zedboard-zynq7-mel_tmp_deploy_ipk_zedboard_zynq7_mel_kernel-module-lttng-ring-buffer-client-mmap-overwrite_2.6.2+git0+7a88f8b506-r0.0_zedboard_zynq7_mel.ipk
> > > >
> > > > need its solution quickly
> > >
> > > If you are in need of a quick workaround, try setting:
> > >
> > > option cache_local_files 0
> > >
> > > on opkg.conf. This will make a copy of your ipk's instead of creating
> > > symlinks (haven't try it myself, but that's my understanding).
> > >
> > > Also, please open a bug report for opkg on
> > > https://bugzilla.yoctoproject.org to track the issue.
> > >
>
> I've just posted patches to the opkg-devel list which should fix this. I
> had
> intended to give them a bit more testing before I sent them but a quick
> fix is
> needed.


Thanks for your quick work on this, Paul, it's much appreciated. From some
initial testing, builds are completing now. We'll keep testing it out.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] opkg 0.3.0 or rootfs task

[Nicolas Dechesne]

On Mon, Oct 26, 2015 at 12:46 AM, Christopher Larson 
wrote:

>
>> I've just posted patches to the opkg-devel list which should fix this. I
>> had
>> intended to give them a bit more testing before I sent them but a quick
>> fix is
>> needed.
>
>
> Thanks for your quick work on this, Paul, it's much appreciated. From some
> initial testing, builds are completing now. We'll keep testing it out.



I just hit the same issue. I was pointed out to this thread on IRC today. I
found the patches on the 0.3.x branch in the opkg git tree. Apart from
applying these patches, do i need to do anything in any OE variables to use
the newly added options? I am not entirely sure after reading this thread
and looking at the patches..

thanks
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] opkg 0.3.0 or rootfs task

[Christopher Larson]

On Mon, Nov 2, 2015 at 8:25 AM, Nicolas Dechesne <
nicolas.deche...@linaro.org> wrote:

> On Mon, Oct 26, 2015 at 12:46 AM, Christopher Larson 
> wrote:
>
>>
>>> I've just posted patches to the opkg-devel list which should fix this. I
>>> had
>>> intended to give them a bit more testing before I sent them but a quick
>>> fix is
>>> needed.
>>
>>
>> Thanks for your quick work on this, Paul, it's much appreciated. From
>> some initial testing, builds are completing now. We'll keep testing it out.
>
>
>
> I just hit the same issue. I was pointed out to this thread on IRC today.
> I found the patches on the 0.3.x branch in the opkg git tree. Apart from
> applying these patches, do i need to do anything in any OE variables to use
> the newly added options? I am not entirely sure after reading this thread
> and looking at the patches..
>

No, there's nothing else you need to do. The patches fromPaul change the
opkg download cache to use checksums rather than the entire url as the
filename, which avoids the file name length problem.

I would not apply the first patch in the series, however, since that's not
related to this. The first patch (memory leak fix) caused double-free
failures in glibc in our testing.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] opkg 0.3.0 or rootfs task

[Alejandro del Castillo]

On 11/02/2015 09:31 AM, Christopher Larson wrote:
> 
> On Mon, Nov 2, 2015 at 8:25 AM, Nicolas Dechesne  > wrote:
> 
> On Mon, Oct 26, 2015 at 12:46 AM, Christopher Larson  > wrote:
> 
> 
> I've just posted patches to the opkg-devel list which should fix 
> this. I had
> intended to give them a bit more testing before I sent them but a 
> quick fix is
> needed.
> 
> 
> Thanks for your quick work on this, Paul, it's much appreciated. From 
> some initial testing, builds are completing now. We'll keep testing it out.
> 
> 
> 
> I just hit the same issue. I was pointed out to this thread on IRC today. 
> I found the patches on the 0.3.x branch in the opkg git tree. Apart from 
> applying these patches, do i need to do anything in any OE variables to use 
> the newly added options? I am not entirely sure after reading this thread and 
> looking at the patches..
> 
> 
> No, there's nothing else you need to do. The patches fromPaul change the opkg 
> download cache to use checksums rather than the entire url as the filename, 
> which avoids the file name length problem.

The patches are under review on the opkg mailing list: 
https://groups.google.com/forum/#!topic/opkg-devel/UzDigiuKBcs. I asked Paul 
for a small modification on one of the patches, once that's done, I will pull 
them into the opkg repo (and we'll need to update the opkg recipe).

> I would not apply the first patch in the series, however, since that's not 
> related to this. The first patch (memory leak fix) caused double-free 
> failures in glibc in our testing.

yes, the first patch needs to be dropped

-- 
Cheers,

Alejandro
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] opkg 0.3.0 or rootfs task

[Nicolas Dechesne]

On Mon, Nov 2, 2015 at 4:53 PM, Alejandro del Castillo
 wrote:
>
> > No, there's nothing else you need to do. The patches fromPaul change the 
> > opkg download cache to use checksums rather than the entire url as the 
> > filename, which avoids the file name length problem.
>
> The patches are under review on the opkg mailing list: 
> https://groups.google.com/forum/#!topic/opkg-devel/UzDigiuKBcs. I asked Paul 
> for a small modification on one of the patches, once that's done, I will pull 
> them into the opkg repo (and we'll need to update the opkg recipe).
>

thanks. It works, after I pulled these patches:

   file://0001-md5-Add-md5_to_string-function.patch \
   file://0002-sha256-Add-sha256_to_string-function.patch \
   file://0003-opkg_download-Use-md5sum-of-src-URI-as-cache-file-na.patch \

So, basically I took patches 2,3 and 4 from the series.

Any chance to get these patches in jethro? Or more generally what's
the plan to get them merged?

thanks a lot!

nico
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] opkg and gpg signed ipk packages

[Paul Barker]

On Thu, May 07, 2015 at 07:11:39PM +, Sona Sarmadi wrote:
> Hi,
> 
> Does opkg have support for gpg signed ipk packages? It seems like that opkg 
> does not recognize gpg signed files. 
>

opkg 0.2.x only has support for checking the package feed signature. To use
this, add the line 'option check_signature 1' to your opkg.conf file and place a
Packages.sig file next to the Packages file in your package feed. ASCII-armoured
signatures are not supported.

opkg-0.3.0-rc2 extends this. Signatures for each package are supported, add the
line 'option check_pkg_signature 1' to your opkg.conf file to use this. Then
for a package named package_v1.ipk you'd need to create a package_v1.ipk.sig
file in the same directory. ASCII-armoured signatures are used with the file
extension .asc instead of .sig if the line 'option signature_type gpg-asc' is
added to your opkg.conf file. The 'Filename' in the package feed should always
refer to the ipk file, the signature is detached rather than included with the
file.

I've not used these options in a while so I might have remembered something
wrong, but the general idea is right.

> root@p2020rdb:~# opkg list-upgradable
> curl - 7.35.0-r2.0 - 7.35.0-r3.0
> curl-dbg - 7.35.0-r2.0 - 7.35.0-r3.0
> libcurl5 - 7.35.0-r2.0 - 7.35.0-r3.0
> root@p2020rdb:~# opkg upgrade curl
> Upgrading curl on root from 7.35.0-r2.0 to 7.35.0-r3.0...
> Downloading 
> http://domain.com/tmp/ipk/ppce500v2/curl_7.35.0-r3.0_ppce500v2.ipk.asc.
> Collected errors:
>  * deb_extract: /tmp/opkg-tslkbd/curl_7.35.0-r3.0_ppce500v2.ipk.asc: invalid 
> magic
>  * opkg_install_pkg: Failed to unpack control files from 
> /tmp/opkg-tslkbd/curl_7.35.0-r3.0_ppce500v2.ipk.asc.
> root@p2020rdb:~#
> 
> I have updated the Package file manually:
> Package: curl
> Version: 7.35.0-r3.0
> Depends: libcurl5 (>= 7.35.0), libz1 (>= 1.2.8), libc6 (>= 2.19)
> Section: console/network
> Architecture: ppce500v2
> Maintainer: ENEA 
> MD5Sum: 725f019d72b6f70845ae19299230738a
> Size: 95616
> Filename: curl_7.35.0-r3.0_ppce500v2.ipk.asc
> Source: http://curl.haxx.se/download/curl-7.35.0.tar.bz2 
> file://pkgconfig_fix.patch file://CVE-2014-3613.patch 
> file://configure_ac.patch
> Description:  Command line tool and library for client-side URL transfers  
> Command line
>  tool and library for client-side URL transfers.
> OE: curl
> HomePage: http://curl.haxx.se/
> License: MIT
> Priority: optional
> 
> Thanks
> //Sona

Thanks,

-- 
Paul Barker

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


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] opkg and gpg signed ipk packages

[Sona Sarmadi]

Thanks Paul for your quick feedback .

> opkg 0.2.x only has support for checking the package feed signature. To use
> this, add the line 'option check_signature 1' to your opkg.conf file and 
> place a
> Packages.sig file next to the Packages file in your package feed. ASCII-
> armoured signatures are not supported.

Ok, even if we can't sign the individual .ipk files, by signing the Packages 
file we can achieve some
Level of authentication, e.g. if someone tampers with the .ipk files they can't 
change the matching 
checksum in the Packages.sig. The checksumming algorithm used for packages is 
MD5 now which is
 not really secure. Is it possible to use another algorithm. I guess if we use 
a better checksum for 
packages, there is no need for Signing each individual .ipk patches, signing 
package feed (Packages) 
would be enough. Right?

> opkg-0.3.0-rc2 extends this. Signatures for each package are supported, add
> the line 'option check_pkg_signature 1' to your opkg.conf file to use this.
> Then for a package named package_v1.ipk you'd need to create a
> package_v1.ipk.sig file in the same directory. ASCII-armoured signatures are
> used with the file extension .asc instead of .sig if the line 'option
> signature_type gpg-asc' is added to your opkg.conf file. The 'Filename' in the
> package feed should always refer to the ipk file, the signature is detached
> rather than included with the file.
> I've not used these options in a while so I might have remembered
> something wrong, but the general idea is right.
> 

//Sona
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] opkg and gpg signed ipk packages

[Paul Barker]

On Fri, May 08, 2015 at 02:26:26PM +, Sona Sarmadi wrote:
> Thanks Paul for your quick feedback .
> 
> > opkg 0.2.x only has support for checking the package feed signature. To use
> > this, add the line 'option check_signature 1' to your opkg.conf file and 
> > place a
> > Packages.sig file next to the Packages file in your package feed. ASCII-
> > armoured signatures are not supported.
> 
> Ok, even if we can't sign the individual .ipk files, by signing the Packages 
> file we can achieve some
> Level of authentication, e.g. if someone tampers with the .ipk files they 
> can't change the matching 
> checksum in the Packages.sig. The checksumming algorithm used for packages is 
> MD5 now which is
>  not really secure. Is it possible to use another algorithm. I guess if we 
> use a better checksum for 
> packages, there is no need for Signing each individual .ipk patches, signing 
> package feed (Packages) 
> would be enough. Right?
> 

SHA256 is also supported. In OpenEmbedded, use the PACKAGECONFIG 'sha256' then
ensure that your Packages file contains a 'SHA256sum: ...' line for each
package.

Again, these instructions are fairly rough as I haven't used them for a while.

Thanks,

-- 
Paul Barker

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


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [opkg-utils][PATCH 10/22] 2to3: print fixes

[Martin Jansa]

Signed-off-by: Martin Jansa 
---
 arfile.py|   20 ++--
 makePackage  |2 +-
 opkg-compare-indexes |6 +++---
 opkg-list-fields |2 +-
 opkg-make-index  |8 
 opkg-show-deps   |2 +-
 opkg-unbuild |2 +-
 opkg.py  |   24 
 8 files changed, 33 insertions(+), 33 deletions(-)

diff --git a/arfile.py b/arfile.py
index 92ffee0..320c9ca 100644
--- a/arfile.py
+++ b/arfile.py
@@ -20,7 +20,7 @@ class FileSection:
 self.seek(0, 0)
 
 def seek(self, offset, whence = 0):
-#print "seek(%x, %d)" % (offset, whence)
+#print("seek(%x, %d)" % (offset, whence))
 if whence == 0:
 return self.f.seek(offset + self.offset, whence)
 elif whence == 1:
@@ -31,11 +31,11 @@ class FileSection:
 assert False
 
 def tell(self):
-#print "tell()"
+#print("tell()")
 return self.f.tell() - self.offset
 
 def read(self, size = -1):
-#print "read(%d)" % size
+#print("read(%d)" % size)
 return self.f.read(size)
 
 class ArFile:
@@ -82,11 +82,11 @@ class ArFile:
 for field_len in ar_field_lens:
 descriptor.append(l[:field_len].strip())
 l = l[field_len:]
-#print descriptor
+#print(descriptor)
 size = int(descriptor[5])
 memberName = descriptor[0][:-1]
 self.directory[memberName] = descriptor + [self.f.tell()]
-#print "read:", memberName
+#print(("read:", memberName))
 if memberName == fname:
 # Record directory offset to start from next time
 self.directoryOffset = self.f.tell() + size
@@ -96,7 +96,7 @@ class ArFile:
 if size % 2:
 size = size + 1
 data = self.f.seek(size, 1)
-#print hex(f.tell())
+#print(hex(self.f.tell()))
 
 
 if __name__ == "__main__":
@@ -106,11 +106,11 @@ if __name__ == "__main__":
 
 ar = ArFile(f, fn)
 tarStream = ar.open("data.tar.gz")
-print ""
+print("")
 tarStream = ar.open("data.tar.gz")
-print ""
+print("")
 tarStream = ar.open("control.tar.gz")
-print ""
+print("")
 tarStream = ar.open("control.tar.gz2")
 
 sys.exit(0)
@@ -132,4 +132,4 @@ if __name__ == "__main__":
 #tarf.list()
 
 f2 = tarf.extractfile("control")
-print f2.read()
+print(f2.read())
diff --git a/makePackage b/makePackage
index 082a81f..ec76338 100755
--- a/makePackage
+++ b/makePackage
@@ -11,4 +11,4 @@ import opkg
 
 fn = sys.argv[1]
 pkg = opkg.Package(fn)
-print pkg
+print(pkg)
diff --git a/opkg-compare-indexes b/opkg-compare-indexes
index 2610987..e0933ce 100755
--- a/opkg-compare-indexes
+++ b/opkg-compare-indexes
@@ -38,12 +38,12 @@ for name in names:
 if pkgs2.packages.has_key(name):
 pkg2 = pkgs2.packages[name]
 if pkg1 and pkg2 and pkg1.version != pkg2.version:
-print "CHANGED: %s from version %s to %s (%s)" % (pkg1.package, 
pkg1.version, pkg2.version, pkg2.maintainer)
+print("CHANGED: %s from version %s to %s (%s)" % (pkg1.package, 
pkg1.version, pkg2.version, pkg2.maintainer))
 cmd = "opkg-diff %s %s > %s " % ((pkg_dir1 + pkg1.filename),  
(pkg_dir2 + pkg2.filename), (pkg1.package + '.diff'))
 print(cmd)
 subprocess.call(cmd)
 if not pkg1:
-print "NEW: %s version %s (%s)"% (pkg2.package, pkg2.version, 
pkg2.maintainer)
+print("NEW: %s version %s (%s)"% (pkg2.package, pkg2.version, 
pkg2.maintainer))
 if not pkg2:
-print "DELETE: %s version %s (%s)"% (pkg1.package, pkg1.version, 
pkg1.maintainer)
+print("DELETE: %s version %s (%s)"% (pkg1.package, pkg1.version, 
pkg1.maintainer))
 
diff --git a/opkg-list-fields b/opkg-list-fields
index da78d53..1fb7fd1 100755
--- a/opkg-list-fields
+++ b/opkg-list-fields
@@ -9,5 +9,5 @@ def usage():
 if (len(sys.argv) < 2):
  usage()
 
-print opkg.Package(sys.argv[1])
+print(opkg.Package(sys.argv[1]))
 
diff --git a/opkg-make-index b/opkg-make-index
index 7923f1e..c3a292b 100755
--- a/opkg-make-index
+++ b/opkg-make-index
@@ -125,12 +125,12 @@ for filename in files:
if opt_m:
 to_morgue(old_filename)
if opt_s:
-print pkg_dir + "/" + old_filename
+print(("%s/%s" % (pkg_dir, old_filename)))
  else:
   if opt_m:
to_morgue(basename)
   if opt_s:
-   print filename
+   print(filename)
   except OSError:
   sys.stderr.write("Package %s disappeared on us!\n" % (filename))
   continue
@@ -172,7 +172,7 @@ for name in names:
   continue
  if (verbose):
   sys.stderr.write("Writing info for

[yocto] [opkg-utils][PATCH 11/22] 2to3: dictionary fixes

[Martin Jansa]

Signed-off-by: Martin Jansa 
---
 arfile.py|2 +-
 opkg-compare-indexes |   10 +-
 opkg-make-index  |   18 +-
 opkg-show-deps   |   12 ++--
 opkg-update-index|2 +-
 opkg.py  |8 
 6 files changed, 26 insertions(+), 26 deletions(-)

diff --git a/arfile.py b/arfile.py
index 320c9ca..9149387 100644
--- a/arfile.py
+++ b/arfile.py
@@ -50,7 +50,7 @@ class ArFile:
 self.directoryOffset = self.f.tell()
 
 def open(self, fname):
-if self.directory.has_key(fname):
+if fname in self.directory:
 return FileSection(self.f, self.directory[fname][-1], 
int(self.directory[fname][5]))
 
 if self.directoryRead:
diff --git a/opkg-compare-indexes b/opkg-compare-indexes
index e0933ce..0c119e3 100755
--- a/opkg-compare-indexes
+++ b/opkg-compare-indexes
@@ -18,8 +18,8 @@ pkgs1.read_packages_file(pkg_dir1 + '/Packages')
 pkgs2 = opkg.Packages()
 pkgs2.read_packages_file(pkg_dir2 + '/Packages')
 
-names1 = pkgs1.packages.keys()
-names2 = pkgs2.packages.keys()
+names1 = list(pkgs1.packages.keys())
+names2 = list(pkgs2.packages.keys())
 
 ## union of the two names lists
 pkgs = {}
@@ -28,14 +28,14 @@ for name in names1:
 for name in names2:
 pkgs[name] = pkgs2.packages[name]
 
-names = pkgs.keys()
+names = list(pkgs.keys())
 names.sort() 
 for name in names:
 pkg1 = None
 pkg2 = None
-if pkgs1.packages.has_key(name):
+if name in pkgs1.packages:
 pkg1 = pkgs1.packages[name]
-if pkgs2.packages.has_key(name):
+if name in pkgs2.packages:
 pkg2 = pkgs2.packages[name]
 if pkg1 and pkg2 and pkg1.version != pkg2.version:
 print("CHANGED: %s from version %s to %s (%s)" % (pkg1.package, 
pkg1.version, pkg2.version, pkg2.maintainer))
diff --git a/opkg-make-index b/opkg-make-index
index c3a292b..2fc8a69 100755
--- a/opkg-make-index
+++ b/opkg-make-index
@@ -79,7 +79,7 @@ if old_filename:
   sys.stderr.write("Reading package list from " + old_filename + "\n")
  old_packages = opkg.Packages()
  old_packages.read_packages_file(old_filename)
- for k in old_packages.packages.keys():
+ for k in list(old_packages.packages.keys()):
   p = old_packages.packages[k]
   old_pkg_hash[p.filename] = p
  try:
@@ -100,8 +100,8 @@ for filename in files:
  basename = os.path.basename(filename)
  pkg = None
  fnameStat = os.stat(filename)
- if old_pkg_hash.has_key(basename):
-  if pkgsStamps.has_key(basename) and int(fnameStat.st_mtime) == 
pkgsStamps[basename]:
+ if basename in old_pkg_hash:
+  if basename in pkgsStamps and int(fnameStat.st_mtime) == 
pkgsStamps[basename]:
 if (verbose):
sys.stderr.write("Found %s in Packages\n" % (filename,))
 pkg = old_pkg_hash[basename]
@@ -113,7 +113,7 @@ for filename in files:
sys.stderr.write("Reading info for package %s\n" % (filename,))
   pkg = opkg.Package(filename)
  pkg_key = ("%s:%s" % (pkg.package, pkg.architecture))
- if (packages.packages.has_key(pkg_key)):
+ if (pkg_key in packages.packages):
   old_filename = packages.packages[pkg_key].filename
  else:
   old_filename = ""
@@ -139,7 +139,7 @@ for filename in files:
   continue
 
 pkgsStampsFile = open(stamplist_filename, "w")
-for f in pkgsStamps.keys():
+for f in list(pkgsStamps.keys()):
 pkgsStampsFile.write("%d %s\n" % (pkgsStamps[f], f))
 pkgsStampsFile.close()
 
@@ -152,7 +152,7 @@ if packages_filename:
  old_stdout = sys.stdout
  tmp_packages_filename = ("%s.%d" % (packages_filename, os.getpid()))
  sys.stdout = open(tmp_packages_filename, "w")
-names = packages.packages.keys()
+names = list(packages.packages.keys())
 names.sort()
 for name in names:
   try:
@@ -193,7 +193,7 @@ if packages_filename:
 if verbose:
  sys.stderr.write("Generate Packages.filelist file\n")
 files = {}
-names = packages.packages.keys()
+names = list(packages.packages.keys())
 names.sort()
 for name in names:
  try:
@@ -207,13 +207,13 @@ for name in names:
  for fn in fnlist:
   (h,t) = os.path.split(fn)
   if not t: continue
-  if not files.has_key(t): files[t] = name+':'+fn
+  if t not in files: files[t] = name+':'+fn
   else: files[t] = files[t] + ',' + name+':'+fn
 
 if filelist_filename:
  tmp_filelist_filename = ("%s.%d" % (filelist_filename, os.getpid()))
  sys.stdout = open(tmp_filelist_filename, "w")
- names = files.keys()
+ names = list(files.keys())
  names.sort()
  for name in names:
   print((name,files[name]))
diff --git a/opkg-show-deps b/opkg-show-deps
index 524d247..3f5899d 100755
--- a/opkg-show-deps
+++ b/opkg-show-deps
@@ -40,21 +40,21 @@ def split_list(str):
r.append(ii)
  return r
 
-for i in packages.packages.keys():
+for i in list(packages.packages.keys()):
  p = package

[yocto] [opkg-utils][PATCH 16/22] arfile: fix test

[Martin Jansa]

Signed-off-by: Martin Jansa 
---
 arfile.py |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/arfile.py b/arfile.py
index 3f797a8..88ace46 100644
--- a/arfile.py
+++ b/arfile.py
@@ -131,5 +131,8 @@ if __name__ == "__main__":
 tarf = tarfile.open("control.tar.gz", "r", tarStream)
 #tarf.list()
 
-f2 = tarf.extractfile("control")
+try:
+f2 = tarf.extractfile("control")
+except KeyError:
+f2 = tarf.extractfile("./control")
 print(f2.read())
-- 
1.7.8.5

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [opkg-utils] Asking for an old patch review

[Apelete Seketeli]

Hello,

I'm trying to get a patch for opkg-utils into oe-classic, and it seems
some of the changes of my patch were already submitted to yocto a
month ago:

https://lists.yoctoproject.org/pipermail/yocto/2012-March/007851.html

Since the opkg-utils recipe in oe-classic is using the yocto
repository as SRC_URI, the patch mentioned in the link above should be
applied to the yocto repository before I make further changes to
opkg-utils.

Could someone here do a review of the above mentioned patch please ?

Best regards.
-- 
Apelete
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [opkg-utils PATCH] update-alternatives: Installing fails for "["

[Liu Jian]

>From 6431466b7c3f5fe76720372593fc785b572db84c Mon Sep 17 00:00:00 2001
From: Jian Liu 
Date: Wed, 29 Oct 2014 09:58:14 +0800
Subject: [opkg-utils PATCH] update-alternatives: Installing fails for "["

Insalling packages using update-alternatives will give the following error lines:
sed: -e expression #1, char 41: unterminated address regex
sed: -e expression #1, char 42: unterminated address regex
This is caused by the script update-alternatives.
"[" can not be used directly in sed expression, which should be escaped
in sed expression.

Signed-off-by: Jian Liu 
---
 update-alternatives |6 +-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/update-alternatives b/update-alternatives
index c332309..8916cbd 100644
--- a/update-alternatives
+++ b/update-alternatives
@@ -68,6 +68,10 @@ protect_slashes() {
 	sed -e 's/\//\\\//g'
 }
 
+protect_special_character() {
+	sed -e 's/\[/\\\[/g'
+}
+
 remove_alt() {
 	[ $# -lt 2 ] && return 1
 	local name="$1"
@@ -75,7 +79,7 @@ remove_alt() {
 
 	[ ! -f $ad/$name ] && return 0
 
-	path=`echo $path | protect_slashes`
+	path=`echo $path | protect_slashes | protect_special_character`
 	sed -ne "/^$path\>.*/!p" $ad/$name > $ad/$name.new
 	mv $ad/$name.new $ad/$name
 }
-- 
1.7.0.5

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [opkg-devel] Stepping back from opkg maintenance

[Alejandro del Castillo]

HI Paul,

Thanks for leading the project during the past 18 months. You can tell 
from the features/bug fixes that opkg improved a lot. Regarding the future 
of opkg, I would like to put my name forward to step in and help maintain 
the project. I am really interested in the continued success of it, and 
will like to take a more active role on it. My employer agreed to let me 
spend time maintaining it, which should give me bandwidth to continue the 
work you have been doing. 

I have been following the list for some time now, and have played with the 
code on my own. However, I do need to ramp my knowledge up, which I intend 
to do (probably start tackling some of the defects, and testing of 0.3).

Thanks again for all your hard work,

-Alejandro




From:   Paul Barker 
To: opkg-devel , 
Cc: Yocto discussion list , OE Core 

Date:   03/01/2015 09:14 AM
Subject:[opkg-devel] Stepping back from opkg maintenance
Sent by:opkg-de...@googlegroups.com



Hi all,

I had a change of circumstances at the beginning of January. Previously I 
was a
full-time PhD student and maintaining opkg was my side project. Now I'm a
full-time software engineer and finishing up my PhD thesis is my side 
project.
I've been trying to find time to fit opkg in there as well but it's just 
not
happening. I had at least hoped that I could get opkg to a v0.3.0 release 
before
I had to step back from opkg development but as I haven't really made any
commits to opkg in 2 months now I don't think it's reasonable to expect 
that
I'll get this done any time soon.

I'll try to keep an eye on the opkg mailing list and contribute with 
answers and
suggestions when I can but I think someone else will have to take over as 
the
maintainer of opkg. I'll do whatever I can to ensure as smooth transition 
if
someone else wants to take up the job of moving opkg forward.

I'd like to thank everyone that's contributed to opkg, whether by sending
patches or just by reporting bugs or making suggestions. I've only been
maintainer for around 18 months but I'd like to think we've made some good
progress in that time and I hope that that can continue forwards under 
someone
else's leadership.

Once I've submitted my PhD thesis I'll hopefully find some time to get 
back
involved with open source projects, whether that's further work on opkg or
getting involved in a different project.

Many thanks again,

-- 
Paul Barker

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

-- 
You received this message because you are subscribed to the Google Groups 
"opkg-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an 
email to opkg-devel+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[attachment "signature.asc" deleted by Alejandro del Castillo/AUS/NIC] 

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [opkg-utils][PATCH 12/22] 2to3: exception handling fixes

[Martin Jansa]

Signed-off-by: Martin Jansa 
---
 arfile.py   |4 ++--
 opkg-make-index |4 ++--
 opkg.py |2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arfile.py b/arfile.py
index 9149387..3f797a8 100644
--- a/arfile.py
+++ b/arfile.py
@@ -54,11 +54,11 @@ class ArFile:
 return FileSection(self.f, self.directory[fname][-1], 
int(self.directory[fname][5]))
 
 if self.directoryRead:
-raise IOError, (2, "AR member not found: " + fname)
+raise IOError("AR member not found: " + fname)
 
 f = self._scan(fname)
 if f == None:
-raise IOError, (2, "AR member not found: " + fname)
+raise IOError("AR member not found: " + fname)
 return f
 
 
diff --git a/opkg-make-index b/opkg-make-index
index 2fc8a69..997f286 100755
--- a/opkg-make-index
+++ b/opkg-make-index
@@ -198,10 +198,10 @@ names.sort()
 for name in names:
  try:
   fnlist = packages[name].get_file_list()
- except OSError, e:
+ except OSError as e:
   sys.stderr.write("Package %s disappeared on us!\n" % (name))
   continue
- except IOError, e:
+ except IOError as e:
   sys.stderr.write("Package %s disappeared on us!\n" % (name))
   continue
  for fn in fnlist:
diff --git a/opkg.py b/opkg.py
index 75ad3d3..ae31794 100644
--- a/opkg.py
+++ b/opkg.py
@@ -176,7 +176,7 @@ class Package:
 elif name == 'size':
 return self._get_file_size()
 else:
-raise AttributeError, name
+raise AttributeError(name)
 
 def _computeFileMD5(self):
 # compute the MD5.
-- 
1.7.8.5

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [opkg-utils] Asking for an old patch review

[Martin Jansa]

On Wed, Apr 25, 2012 at 11:47:52PM +0200, Apelete Seketeli wrote:
> Hello,
> 
> I'm trying to get a patch for opkg-utils into oe-classic, and it seems
> some of the changes of my patch were already submitted to yocto a
> month ago:
> 
> https://lists.yoctoproject.org/pipermail/yocto/2012-March/007851.html
> 
> Since the opkg-utils recipe in oe-classic is using the yocto
> repository as SRC_URI, the patch mentioned in the link above should be
> applied to the yocto repository before I make further changes to
> opkg-utils.
> 
> Could someone here do a review of the above mentioned patch please ?

FWIW: I'm using all those changes squashed together
http://git.openembedded.org/openembedded-core-contrib/commit/?h=shr&id=b355502a48371cd7fb676eb01cf15c9b9c941352

and when that patchset get applied upstream we'll just change SRCREV and
drop shr.patch.. 

feel free to do it that way in oe-classic too, if it's not applied
soon..

Cheers,

-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


signature.asc
Description: Digital signature
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [opkg-utils] Asking for an old patch review

[Kristoffer Eriksson]

Any updates on this?

Apelete Seketeli skrev 2012-04-25 23:47:

Hello,

I'm trying to get a patch for opkg-utils into oe-classic, and it seems
some of the changes of my patch were already submitted to yocto a
month ago:

https://lists.yoctoproject.org/pipermail/yocto/2012-March/007851.html

Since the opkg-utils recipe in oe-classic is using the yocto
repository as SRC_URI, the patch mentioned in the link above should be
applied to the yocto repository before I make further changes to
opkg-utils.

Could someone here do a review of the above mentioned patch please ?

Best regards.


___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [opkg-utils] Asking for an old patch review

[Saul Wold]

On 05/04/2012 02:22 PM, Kristoffer Eriksson wrote:

Any updates on this?

Apelete Seketeli skrev 2012-04-25 23:47:

Hello,

I'm trying to get a patch for opkg-utils into oe-classic, and it seems
some of the changes of my patch were already submitted to yocto a
month ago:

https://lists.yoctoproject.org/pipermail/yocto/2012-March/007851.html

Since the opkg-utils recipe in oe-classic is using the yocto
repository as SRC_URI, the patch mentioned in the link above should be
applied to the yocto repository before I make further changes to
opkg-utils.

Could someone here do a review of the above mentioned patch please ?


Have you checked the opkg-utils git repo?  It seems they have been merged.

Sau!


Best regards.


___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto



___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [opkg-utils] Asking for an old patch review

[Apelete Seketeli]

Le 04-May-12, Saul Wold a écrit:
> On 05/04/2012 02:22 PM, Kristoffer Eriksson wrote:
> >Any updates on this?
> >
> >Apelete Seketeli skrev 2012-04-25 23:47:
> >>Hello,
> >>
> >>I'm trying to get a patch for opkg-utils into oe-classic, and it seems
> >>some of the changes of my patch were already submitted to yocto a
> >>month ago:
> >>
> >>https://lists.yoctoproject.org/pipermail/yocto/2012-March/007851.html
> >>
> >>Since the opkg-utils recipe in oe-classic is using the yocto
> >>repository as SRC_URI, the patch mentioned in the link above should be
> >>applied to the yocto repository before I make further changes to
> >>opkg-utils.
> >>
> >>Could someone here do a review of the above mentioned patch please ?
> >>
> Have you checked the opkg-utils git repo?  It seems they have been merged.

I'm aware they have been merged indeed, on April 26th, by Richard
Purdie precisely.
Thanks for the work.

Cheers.
-- 
Apelete
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [opkg-utils PATCH] update-alternatives: Installing fails for "["

[Liu Jian]

Insalling packages using update-alternatives will give the following
error lines:
sed: -e expression #1, char 41: unterminated address regex
sed: -e expression #1, char 42: unterminated address regex
This is caused by the script update-alternatives.
"[" can not be used directly in sed expression, which should be escaped
in sed expression.

Signed-off-by: Jian Liu 
---
update-alternatives | 6 +-
1 files changed, 5 insertions(+), 1 deletions(-)


- I add the head of this patch -




于 2014年10月30日 13:40, Liu Jian 写道:

-- 
Jian Liu
Email: jian@windriver.com
Office Phone: 86-10-84778539

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [opkg-utils PATCH] update-alternatives: avoid double slash problem

[Chen Qi]

Signed-off-by: Chen Qi 
---
 update-alternatives | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/update-alternatives b/update-alternatives
index 8916cbd..ca01d5d 100644
--- a/update-alternatives
+++ b/update-alternatives
@@ -97,7 +97,7 @@ find_best_alt() {
[ $# -lt 1 ] && return 1
[ ! -f $ad/$name ] && return 0
 
-   link=$OPKG_OFFLINE_ROOT/`head -n 1 $ad/$name`
+   link=$OPKG_OFFLINE_ROOT`head -n 1 $ad/$name`
 
prio=`sed -ne "1!p" $ad/$name | sed -e "s/\(.*\) \(.*\)/\2 \1/g" | sort 
-nr | head -n 1 | sed 's/ [^ ]*$//'`
if [ -z "$prio" ]; then
-- 
1.9.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [opkg-utils PATCH] opkg.py: Remove reformatting of description field

[Jeffrey Pautler]

The Debian Policy Manual describes the format of the description field.
This includes information about how lines might be wrapped by programs
displaying this information, how to mark lines to not be wrapped, how
to mark a line as blank, and how leading spaces on a multi-line
description might be deleted.

By reformatting the description field in opkg.py, we are breaking many
of these behaviors and taking control of formatting away from the
author of the control file. Instead, we should simply copy the
description field with no reformatting.

Signed-off-by: Jeffrey Pautler 
---
opkg.py | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/opkg.py b/opkg.py
index 9131755..c0cdcd5 100644
--- a/opkg.py
+++ b/opkg.py
@@ -230,7 +230,7 @@ class Package(object):
 name = lineparts.group(1).lower()
 value = lineparts.group(2)
 while 1:
-line = control.readline()
+line = control.readline().rstrip()
 if not line: break
 if line[0] != ' ': break
 value = value + '\n' + line
@@ -480,11 +480,7 @@ class Package(object):
 if self.installed_size: out = out + "InstalledSize: %d\n" % 
int(self.installed_size)
 if self.filename: out = out + "Filename: %s\n" % (self.filename)
 if self.source: out = out + "Source: %s\n" % (self.source)
-if self.description:
-printable_description = textwrap.dedent(self.description).strip()
-summary = printable_description.split('\n', 1)[0]
-printable_description = printable_description.split('\n', 
1)[-1].strip()
-out = out + "Description: %s\n%s\n" % (summary, 
textwrap.fill(printable_description, width=74, initial_indent=' ', 
subsequent_indent=' '))
+if self.description: out = out + "Description: %s\n" % 
(self.description)
 if self.oe: out = out + "OE: %s\n" % (self.oe)
 if self.homepage: out = out + "HomePage: %s\n" % (self.homepage)
 if self.license: out = out + "License: %s\n" % (self.license)
--
2.7.4
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [opkg-utils PATCH] update-alternatives: Fix link relocation support

[Niko Mauno]

Commit fcb2633921eb9bb711aa264247aebcfdd4ae which added Debian-style
support for link relocation tries to relocate symbolic link on host OS,
resulting in following-like error when two alternative packages have
symbolic link source located in different directories (/bin/rev ->
/bin/busybox.nosuid and /usr/bin/rev -> /usr/bin/rev.util-linux):

  update-alternatives: renaming rev link from /bin/rev to /usr/bin/rev
  mv: cannot stat '/bin/rev': No such file or directory

Fix the issue by prefixing 'olink' and 'link' variable references with
path to targeted root filesystem's root directory.

Signed-off-by: Niko Mauno 
---
 update-alternatives | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/update-alternatives b/update-alternatives
index 89a440b..d4fa7eb 100644
--- a/update-alternatives
+++ b/update-alternatives
@@ -58,7 +58,7 @@ register_alt() {
local link_str=`echo $link | protect_slashes`
sed -e "1s/.*/$link_str/" $ad/$name > $ad/$name.new
mv $ad/$name.new $ad/$name
-   mv $olink $link
+   mv $OPKG_OFFLINE_ROOT$olink $OPKG_OFFLINE_ROOT$link
fi
else
echo "$link" > "$ad/$name"
-- 
2.19.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [opkg-utils PATCH 1/2] migrate to python 3

[Alejandro del Castillo]

General fixes
* Add __future__ imports
* Use print function instead of print statement
* Use new style classes
* Iterate over list, instead of over object.keys()
* Use six.iteritems  instead of iteritems()

opkg.py:
* Add conditional to decode string if needed in Package:read_control

arfile.py
* Add seekable method to FileSection class (needed by tarfile)

Signed-off-by: Alejandro del Castillo 
---
 arfile.py| 10 --
 makePackage  |  2 ++
 opkg-compare-indexes |  2 ++
 opkg-graph-deps  | 39 +--
 opkg-list-fields |  2 ++
 opkg-make-index  |  2 ++
 opkg-show-deps   |  2 ++
 opkg-unbuild |  2 ++
 opkg-update-index|  1 +
 opkg.py  | 17 ++---
 10 files changed, 52 insertions(+), 27 deletions(-)

diff --git a/arfile.py b/arfile.py
index 88ace46..4bab526 100644
--- a/arfile.py
+++ b/arfile.py
@@ -5,12 +5,15 @@ Copyright (c) 2006-7 Paul Sokolovsky
 This file is released under the terms 
 of GNU General Public License v2 or later.
 """
+from __future__ import absolute_import
+from __future__ import print_function
+from builtins import object
 import sys
 import os
 import tarfile 
 
 
-class FileSection:
+class FileSection(object):
 "A class which allows to treat portion of file as separate file object."
 
 def __init__(self, f, offset, size):
@@ -30,6 +33,9 @@ class FileSection:
 else:
 assert False
 
+def seekable(self):
+return True 
+
 def tell(self):
 #print("tell()")
 return self.f.tell() - self.offset
@@ -38,7 +44,7 @@ class FileSection:
 #print("read(%d)" % size)
 return self.f.read(size)
 
-class ArFile:
+class ArFile(object):
 
 def __init__(self, f, fn):
 self.f = f
diff --git a/makePackage b/makePackage
index ec76338..4bdfc56 100755
--- a/makePackage
+++ b/makePackage
@@ -5,6 +5,8 @@
 #   Insert the filename, size, and md5 lines before the description.
 # Call it like this:
 #  find . -name \*.opk | xargs -n 1 makePackage > Packages
+from __future__ import absolute_import
+from __future__ import print_function
 
 import sys
 import opkg
diff --git a/opkg-compare-indexes b/opkg-compare-indexes
index 7bb3c69..b60d20a 100755
--- a/opkg-compare-indexes
+++ b/opkg-compare-indexes
@@ -1,4 +1,6 @@
 #!/usr/bin/env python
+from __future__ import absolute_import
+from __future__ import print_function
 
 import sys, os
 from glob import glob
diff --git a/opkg-graph-deps b/opkg-graph-deps
index d7f4fd2..6653fd5 100755
--- a/opkg-graph-deps
+++ b/opkg-graph-deps
@@ -1,18 +1,21 @@
 #!/usr/bin/env python
+from __future__ import absolute_import
+from __future__ import print_function
 
 import sys
 import os
 import getopt
 import pydot
 import opkg
+import six
 
 def usage(more=False):
-print >>sys.stderr, ( 'Usage: opkg-graph-deps '
+print(( 'Usage: opkg-graph-deps '
 '[-h] [-d] [-o feed.dot] '
 '[-u ] '
-'' )
+'' ), file=sys.stderr)
 if more:
-print >>sys.stderr, '\n'.join( [
+print('\n'.join( [
 '',
 'Generates a dot formatted dependency graph of an IPK feed.',
 '',
@@ -56,7 +59,7 @@ def usage(more=False):
 '  the alias != (to).',
 ' ipkBrokenDep: Set to "1" if (to) is missing from the feed.',
 '',
-] )
+] ), file=sys.stderr)
 exit(1)
 
 # optional args
@@ -76,19 +79,19 @@ for (optkey, optval) in opts:
 feed_url = optval
 
 if not index_files:
-print >>sys.stderr, 'Must specify a path to at least one Packages file'
+print('Must specify a path to at least one Packages file', file=sys.stderr)
 usage()
 
 def fatal_error(msg):
-print >>sys.stderr, ('ERROR: ' + str(msg))
+print(('ERROR: ' + str(msg)), file=sys.stderr)
 exit(1)
 
 def warn(msg):
-print >>sys.stderr, str(msg)
+print(str(msg), file=sys.stderr)
 
 def debug(msg):
 if enable_debug:
-print >>sys.stderr, ('DEBUG: ' + str(msg))
+print(('DEBUG: ' + str(msg)), file=sys.stderr)
 
 def split_dep_list(lst):
 '''
@@ -190,7 +193,7 @@ for indexFilePath in index_files:
 packages.read_packages_file(indexFilePath)
 
 # add each package
-for pkgKey in packages.keys():
+for pkgKey in list(packages.keys()):
 pkg = packages[pkgKey]
 
 # sanity check: verify important attributes are defined for
@@ -228,7 +231,7 @@ for indexFilePath in index_files:
 # provides the alias.
 # These packages are not added to the graph because their implementations
 # are already there.
-for pkgKey, pkg in real_pkg_map.iteritems():
+for pkgKey, pkg in six.iteritems(real_pkg_map):
 for alias in split_dep_list(pkg.provides):
 if alias not in active_pkg_map:
 # add it
@@ -260,7 +263,7 @@ for pkgKey, pkg in real_pkg_map.iteritems():
 virt_pkg_map[alias].append(pkg)
 
 # Print alternatives for virtual packages
-for pkgKey, pkgList in virt_pkg_map.iteritems():
+for pkgKey, pkgList in six.iter

[yocto] [opkg-utils PATCH 0/2] migrate to python 3

[Alejandro del Castillo]

First patch migrates all opkg-utils scrips to python 3. opkg-graph-deps
doesn't work on python 3 since it depends on pydot, which hasn't migrated
to python 3. Second patch fixes opkg-update-index, which was broken.

Alejandro del Castillo (2):
  migrate to python 3
  opkg.py/write_packages_file: call __str__ instead of __repr__

 arfile.py| 10 --
 makePackage  |  2 ++
 opkg-compare-indexes |  2 ++
 opkg-graph-deps  | 39 +--
 opkg-list-fields |  2 ++
 opkg-make-index  |  2 ++
 opkg-show-deps   |  2 ++
 opkg-unbuild |  2 ++
 opkg-update-index|  1 +
 opkg.py  | 19 +++
 10 files changed, 53 insertions(+), 28 deletions(-)

-- 
1.9.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [opkg-utils PATCH] arfile.py: remove dependency on python-future

[Alejandro del Castillo]

Python-future provides a python2 compatible object class (provides next
method). Since method is not used, remove dependency.

Signed-off-by: Alejandro del Castillo 
---
 arfile.py | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arfile.py b/arfile.py
index 4bab526..1c42bc7 100644
--- a/arfile.py
+++ b/arfile.py
@@ -7,7 +7,6 @@ of GNU General Public License v2 or later.
 """
 from __future__ import absolute_import
 from __future__ import print_function
-from builtins import object
 import sys
 import os
 import tarfile 
-- 
1.9.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [opkg-utils][PATCH 0/5] Import patches from oe-core

[Martin Jansa]

The following changes since commit 002d29bc605d7c2d02e4cf20a43c5277c15f5597:

  [opkg-utils] fix install fail problem  Thanks for khorben's patch :-)  
https://docs.openmoko.org/trac/attachment/ticket/2072/patch-opkg-utils_Makefile_install_path.diff
 (2008-11-03 03:59:59 +)

are available in the git repository at:
  git://github.com/shr-project/opkg-utils jansa/pull
  https://github.com/shr-project/opkg-utils/tree/jansa/pull

Christopher Larson (1):
  Use python via the PATH, rather than hardcoding /usr/bin/python

Enrico Scholz (1):
  opkg-make-index: convert mtime to int before comparing it

Khem Raj (1):
  opkg.py: Add knowledge about License field in ipk headers

Richard Purdie (1):
  opkg-make-index: don't error out when some package disappears

Scott Anderson (1):
  arfile.py: handle six digit UIDs

 arfile.py |7 ++-
 opkg-list-fields  |2 +-
 opkg-make-index   |   29 ++---
 opkg-show-deps|2 +-
 opkg-unbuild  |2 +-
 opkg-update-index |2 +-
 opkg.py   |8 
 7 files changed, 44 insertions(+), 8 deletions(-)

-- 
1.7.8.5

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [opkg-utils][PATCH 4/5] arfile.py: handle six digit UIDs

[Martin Jansa]

From: Scott Anderson 

* Essentially, the problem is that arfile.py is splitting the ar header with
  white-space instead of fixed-width fields, so two fields would get treated
  as a single field.  This makes things better than before as it now honors
  the fixed field widths.

Signed-off-by: Martin Jansa 
---
 arfile.py |7 ++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/arfile.py b/arfile.py
index 22548af..8291a2d 100644
--- a/arfile.py
+++ b/arfile.py
@@ -75,7 +75,12 @@ class ArFile:
 l = self.f.readline()
 if not l: break
 l = l.replace('`', '')
-descriptor = l.split()
+# Field lengths from /usr/include/ar.h:
+ar_field_lens = [ 16, 12, 6, 6, 8, 10, 2 ]
+descriptor = []
+for field_len in ar_field_lens:
+descriptor.append(l[:field_len].strip())
+l = l[field_len:]
 #print descriptor
 size = int(descriptor[5])
 memberName = descriptor[0][:-1]
-- 
1.7.8.5

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [opkg-utils][PATCH 04/22] arfile.py: handle six digit UIDs

[Martin Jansa]

From: Scott Anderson 

* Essentially, the problem is that arfile.py is splitting the ar header with
  white-space instead of fixed-width fields, so two fields would get treated
  as a single field.  This makes things better than before as it now honors
  the fixed field widths.

Signed-off-by: Martin Jansa 
---
 arfile.py |7 ++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/arfile.py b/arfile.py
index 22548af..8291a2d 100644
--- a/arfile.py
+++ b/arfile.py
@@ -75,7 +75,12 @@ class ArFile:
 l = self.f.readline()
 if not l: break
 l = l.replace('`', '')
-descriptor = l.split()
+# Field lengths from /usr/include/ar.h:
+ar_field_lens = [ 16, 12, 6, 6, 8, 10, 2 ]
+descriptor = []
+for field_len in ar_field_lens:
+descriptor.append(l[:field_len].strip())
+l = l[field_len:]
 #print descriptor
 size = int(descriptor[5])
 memberName = descriptor[0][:-1]
-- 
1.7.8.5

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [opkg] Problem with the package manager opkg on Intel Galileo

[Laurène Guelorget]

Hello,

I am using an Intel Galileo board with a linux distribution
(LINUX_IMAGE_FOR_SD_Intel_Galileo_v0.7.5)
and I want to install new packages. I think opkg is the package manager on
this OS but I don't know how
to use it. I have an internet connection on the Galileo but I don't know
how to add a repository url to have
more packages available. For example, I want to install openhab on the
board, where can I found it and
do I have to add it in the /etc/opkg/opkg.conf file?

Another issue I have is about java. Does this distribution have Java on it?
If not where can I get it to intall
it on the Galileo?

Sincerely,

p.s. Sorry this is my second email but I didn't realize I needed to put
[yocto][...] in the object line.
-- 

*Laurène GuelorgetElève ingénieur en 5ème année à Polytech'Grenoble
*

*Filière Réseaux Informatiques et Communication Multimédia Spécialité "**Réseau
et **Système"*
*Rejoignez moi sur LinkedIn.
*
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [opkg-utils PATCH] opkg-build: Add support for explicit pigz

[Mike Crowe]

From: Mike Crowe 

oe-core has stopped[1] installing pigz as gzip. This means that in order to
persuade opkg-build to use pigz it must be specified explicitly. Let's
teach opkg-build to deal with being passed pigz as a compressor. We can't
combine the check for whether -T is required because opkg-build calls both
$compressor and gzip explicitly.

Signed-off-by: Mike Crowe 
---
 opkg-build | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/opkg-build b/opkg-build
index 0050c2b..d5f5b8f 100755
--- a/opkg-build
+++ b/opkg-build
@@ -170,7 +170,7 @@ fi
 
 compressor_ext() {
 case $1 in
-   gzip)
+   gzip|pigz)
echo gz
;;
bzip2)
@@ -230,6 +230,10 @@ if gzip --help 2>&1 | grep -- "-T" > /dev/null; then
 fi
 if [ $compressor = "gzip" ] ; then
compressorargs=$zipargs
+elif [ $compressor = "pigz" ] ; then
+   if $compressor --help 2>&1 | grep -- "-T" > /dev/null; then
+   compressorargs="-9nT"
+   fi
 fi
 
 tsortargs=
-- 
2.11.0

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [opkg-utils PATCH] Makefile: fixed for-loop in install receipe

[Joshua DeWeese]

From: Joshua DeWeese 

The install receipe would have copied all the manpages to each of the
section folders. This change will do what I believe the original
author had intended.

Signed-off-by: Joshua DeWeese 
---
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 69a1c5a..817a8c1 100644
--- a/Makefile
+++ b/Makefile
@@ -23,7 +23,7 @@ install: all
for m in $(MANPAGES); \
do \
install -d $(DESTDIR)$(mandir)/man$${m##*.}; \
-   install -m 644 $(MANPAGES) $(DESTDIR)$(mandir)/man$${m##*.}; \
+   install -m 644 "$$m" $(DESTDIR)$(mandir)/man$${m##*.}; \
done
 
 .PHONY: install all
-- 
2.7.4

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [opkg-utils][PATCH 09/22] 2to3: use subprocess instead of commands

[Martin Jansa]

Signed-off-by: Martin Jansa 
---
 opkg-compare-indexes |6 +++---
 opkg-make-index  |5 ++---
 opkg-show-deps   |1 -
 opkg-update-index|1 -
 opkg.py  |2 +-
 5 files changed, 6 insertions(+), 9 deletions(-)

diff --git a/opkg-compare-indexes b/opkg-compare-indexes
index 6c68125..2610987 100755
--- a/opkg-compare-indexes
+++ b/opkg-compare-indexes
@@ -2,7 +2,7 @@
 
 import sys, os
 from glob import glob
-import commands
+import subprocess
 import opkg
 
 pkg_dir1 = sys.argv[1]
@@ -40,8 +40,8 @@ for name in names:
 if pkg1 and pkg2 and pkg1.version != pkg2.version:
 print "CHANGED: %s from version %s to %s (%s)" % (pkg1.package, 
pkg1.version, pkg2.version, pkg2.maintainer)
 cmd = "opkg-diff %s %s > %s " % ((pkg_dir1 + pkg1.filename),  
(pkg_dir2 + pkg2.filename), (pkg1.package + '.diff'))
-print cmd
-   commands.getstatusoutput(cmd)
+print(cmd)
+subprocess.call(cmd)
 if not pkg1:
 print "NEW: %s version %s (%s)"% (pkg2.package, pkg2.version, 
pkg2.maintainer)
 if not pkg2:
diff --git a/opkg-make-index b/opkg-make-index
index b65dc6e..7923f1e 100755
--- a/opkg-make-index
+++ b/opkg-make-index
@@ -2,7 +2,7 @@
 
 import sys, os, posixpath
 from glob import glob
-import commands
+import subprocess
 import opkg
 import getopt
 import string
@@ -186,8 +186,7 @@ if packages_filename:
  gzip_filename = ("%s.gz" % packages_filename)
  tmp_gzip_filename = ("%s.%d" % (gzip_filename, os.getpid()))
  gzip_cmd = "gzip -9c < %s > %s" % (tmp_packages_filename, 
tmp_gzip_filename)
- (rc, outtext) = commands.getstatusoutput(gzip_cmd)
- print outtext
+ rc = subprocess.check_output(gzip_cmd, shell=True)
  os.rename(tmp_packages_filename, packages_filename)
  os.rename(tmp_gzip_filename, gzip_filename)
 
diff --git a/opkg-show-deps b/opkg-show-deps
index 9de1aac..5ab5b4f 100755
--- a/opkg-show-deps
+++ b/opkg-show-deps
@@ -2,7 +2,6 @@
 
 import sys, os, posixpath
 from glob import glob
-import commands
 import opkg
 import getopt
 import string
diff --git a/opkg-update-index b/opkg-update-index
index 3864fa5..d9c9b43 100755
--- a/opkg-update-index
+++ b/opkg-update-index
@@ -2,7 +2,6 @@
 
 import sys, os
 from glob import glob
-import commands
 import opkg
 
 pkg_dir=sys.argv[1]
diff --git a/opkg.py b/opkg.py
index 31b847c..f37a68d 100644
--- a/opkg.py
+++ b/opkg.py
@@ -39,7 +39,7 @@ import glob
 import hashlib
 import re
 import string
-import commands
+import subprocess
 from stat import ST_SIZE
 import arfile
 import tarfile
-- 
1.7.8.5

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [opkg-utils][PATCH 13/22] opkg-make-index: show OSError/IOError

[Martin Jansa]

Signed-off-by: Martin Jansa 
---
 opkg-make-index |   20 ++--
 1 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/opkg-make-index b/opkg-make-index
index 997f286..e0844a7 100755
--- a/opkg-make-index
+++ b/opkg-make-index
@@ -131,11 +131,11 @@ for filename in files:
to_morgue(basename)
   if opt_s:
print(filename)
-  except OSError:
-  sys.stderr.write("Package %s disappeared on us!\n" % (filename))
+  except OSError as e:
+  sys.stderr.write("Package %s disappeared on us!\n(%s)\n" % (filename, e))
   continue
-  except IOError:
-  sys.stderr.write("Package %s disappeared on us!\n" % (filename))
+  except IOError as e:
+  sys.stderr.write("Package %s disappeared on us!\n(%s)\n" % (filename, e))
   continue
 
 pkgsStampsFile = open(stamplist_filename, "w")
@@ -173,11 +173,11 @@ for name in names:
  if (verbose):
   sys.stderr.write("Writing info for package %s\n" % (pkg.package,))
  print(pkg)
-  except OSError:
-  sys.stderr.write("Package %s disappeared on us!\n" % (name))
+  except OSError as e:
+  sys.stderr.write("Package %s disappeared on us!\n(%s)\n" % (name, e))
   continue
-  except IOError:
-  sys.stderr.write("Package %s disappeared on us!\n" % (name))
+  except IOError as e:
+  sys.stderr.write("Package %s disappeared on us!\n(%s)\n" % (name, e))
   continue
 
 if packages_filename:
@@ -199,10 +199,10 @@ for name in names:
  try:
   fnlist = packages[name].get_file_list()
  except OSError as e:
-  sys.stderr.write("Package %s disappeared on us!\n" % (name))
+  sys.stderr.write("Package %s disappeared on us!\n(%s)\n" % (name, e))
   continue
  except IOError as e:
-  sys.stderr.write("Package %s disappeared on us!\n" % (name))
+  sys.stderr.write("Package %s disappeared on us!\n(%s)\n" % (name, e))
   continue
  for fn in fnlist:
   (h,t) = os.path.split(fn)
-- 
1.7.8.5

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [opkg-utils][PATCH 21/22] opkg.py: use textwrap for description writing

[Martin Jansa]

* description field in oe-core sometimes has extra line-feeds and is long
* extra line-feeds breaks read_control, because empty line means next Package
* long descriptions should be wrapped and properly indented, so they are parsed 
back properly

Signed-off-by: Martin Jansa 
---
 opkg.py |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/opkg.py b/opkg.py
index ad3a695..2294160 100644
--- a/opkg.py
+++ b/opkg.py
@@ -42,6 +42,7 @@ import subprocess
 from stat import ST_SIZE
 import arfile
 import tarfile
+import textwrap
 
 class Version:
 """A class for holding parsed package version information."""
@@ -427,7 +428,9 @@ class Package:
 if self.installed_size: out = out + "InstalledSize: %d\n" % 
int(self.installed_size)
 if self.filename: out = out + "Filename: %s\n" % (self.filename)
 if self.source: out = out + "Source: %s\n" % (self.source)
-if self.description: out = out + "Description: %s\n" % 
(self.description)
+if self.description:
+printable_description = textwrap.dedent(self.description).strip()
+out = out + "Description: %s\n" % 
textwrap.fill(printable_description, width=74, initial_indent=' ', 
subsequent_indent=' ')
 if self.oe: out = out + "OE: %s\n" % (self.oe)
 if self.homepage: out = out + "HomePage: %s\n" % (self.homepage)
 if self.license: out = out + "License: %s\n" % (self.license)
-- 
1.7.8.5

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [opkg-utils][PATCH 23/23] opkg-make-index: generate complete filelist

[martin . jansa]

From: Martin Jansa 

* when '-l Packages.filelist' option is used together with '-r Packages.old',
  then only 'new' packages are processed to create Packages.filelist
  packages found in Packages.old doesn't have fn set so get_file_list()
  was returning empty
* now added get_file_list_dir() looks for filename in pkg_dir and if it
  finds correct .ipk file it will use that to read its filelist, but it
  also means that it will always unpack *all* Packages - very slow.
* it would be nice to add new param for Packages.filelist.old and then
  filter filelist for packages used from Packages.old and merge it
  together with new Packages.filelist, but that's more difficult because
  of files structure.

Signed-off-by: Martin Jansa 
---
 opkg-make-index |   64 +-
 opkg.py |   16 +
 2 files changed, 50 insertions(+), 30 deletions(-)

diff --git a/opkg-make-index b/opkg-make-index
index 02c425f..4425107 100755
--- a/opkg-make-index
+++ b/opkg-make-index
@@ -190,34 +190,38 @@ if packages_filename:
  os.rename(tmp_packages_filename, packages_filename)
  os.rename(tmp_gzip_filename, gzip_filename)
 
-if verbose:
- sys.stderr.write("Generate Packages.filelist file\n")
-files = {}
-names = list(packages.packages.keys())
-names.sort()
-for name in names:
- try:
-  fnlist = packages[name].get_file_list()
- except OSError as e:
-  sys.stderr.write("Package %s disappeared on us!\n(%s)\n" % (name, e))
-  continue
- except IOError as e:
-  sys.stderr.write("Package %s disappeared on us!\n(%s)\n" % (name, e))
-  continue
- for fn in fnlist:
-  (h,t) = os.path.split(fn)
-  if not t: continue
-  if t not in files: files[t] = name+':'+fn
-  else: files[t] = files[t] + ',' + name+':'+fn
-
 if filelist_filename:
- tmp_filelist_filename = ("%s.%d" % (filelist_filename, os.getpid()))
- f = open(tmp_filelist_filename, "w")
- names = list(files.keys())
- names.sort()
- for name in names:
-  f.write("%s %s\n" % (name, files[name]))
- f.close()
- if posixpath.exists(filelist_filename):
-  os.unlink(filelist_filename)
- os.rename(tmp_filelist_filename, filelist_filename)
+if verbose:
+sys.stderr.write("Generate Packages.filelist file\n")
+files = {}
+names = list(packages.packages.keys())
+names.sort()
+for name in names:
+try:
+if verbose:
+sys.stderr.write("Reading filelist for package '%s'\n" % name)
+#sys.stderr.write("Package for name '%s':\n'%s'\n" % (name, 
packages[name]))
+fnlist = packages[name].get_file_list_dir(pkg_dir)
+#sys.stderr.write("Filelist for package '%s': '%s'\n" % (name, 
fnlist))
+except OSError as e:
+sys.stderr.write("Package %s disappeared on us!\n(%s)\n" % (name, 
e))
+continue
+except IOError as e:
+sys.stderr.write("Package %s disappeared on us!\n(%s)\n" % (name, 
e))
+continue
+for fn in fnlist:
+(h,t) = os.path.split(fn)
+if not t: continue
+if t not in files: files[t] = name+':'+fn
+else: files[t] = files[t] + ',' + name+':'+fn
+
+tmp_filelist_filename = ("%s.%d" % (filelist_filename, os.getpid()))
+f = open(tmp_filelist_filename, "w")
+names = list(files.keys())
+names.sort()
+for name in names:
+ f.write("%s %s\n" % (name, files[name]))
+f.close()
+if posixpath.exists(filelist_filename):
+os.unlink(filelist_filename)
+os.rename(tmp_filelist_filename, filelist_filename)
diff --git a/opkg.py b/opkg.py
index 27cbc2a..707a882 100644
--- a/opkg.py
+++ b/opkg.py
@@ -325,8 +325,24 @@ class Package:
 def get_license(self, license):
 return self.license
 
+def get_file_list_dir(self, directory):
+if not self.fn:
+try:
+cmd = "find %s -name %s | head -n 1" % (directory, 
self.filename)
+rc = subprocess.check_output(cmd, shell=True)
+newfn = str(rc).split()[0]
+#sys.stderr.write("Package '%s' with empty fn and filename is 
'%s' was found in '%s', updating fn\n" % (self.package, self.filename, newfn))
+self.fn = newfn
+except OSError as e:
+sys.stderr.write("Cannot find current fn for package '%s' 
filename '%s' in dir '%s'\n(%s)\n" % (self.package, self.filename, directory, 
e))
+except IOError as e:
+sys.stderr.write("Cannot find current fn for package '%s' 
filename '%s' in dir '%s'\n(%s)\n" % (self.package, self.filename, directory, 
e))
+return self.get_file_list()
+
+
 def get_file_list(self):
 if not self.fn:
+sys.stderr.write("Package '%s' has empty fn returning empty 
filelist\n" % (self.package))
 return []
 f

[yocto] [opkg-utils] Splitting package feed directories and where to send patches

[Paul Barker]

I'm planning a patch to opkg-utils to add an option to split packages
into subdirectories in the same way as debian package feeds are often
laid out. So you'd have 'a*' in a subdirectory 'a', 'b*' in 'b', etc.
Packages beginning with 'lib' are put in 'liba', 'libb', etc as
appropriate and packages matching 'l*' but not 'lib*' stay in 'l'.
That's done to reduce the number of files in a single directory - I'm
having trouble mirroring over 7000 files in one directory to my
webserver. I shan't be changing the default, just want to add the
option if I can and then add a way of enabling this behaviour in a
distro config or local.conf.

However, I can't see any info on where to send packages for opkg-utils
and if there's a particular maintainer I need to CC on my emails. I'm
guessing they probably go to this list or someone on this list. So I'm
also going to propose adding a README file to opkg-utils with info on
who's maintaining it and where to send patches.

I now seem to be the de-facto maintainer of opkg itself so it would
make sense for me to co-ordinate with whoever is looking after
opkg-utils.

Thanks,

-- 
Paul Barker

Email: p...@paulbarker.me.uk
http://www.paulbarker.me.uk
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [opkg] Problem with the package manager opkg on Intel Galileo

[Paul Barker]

On 13 February 2014 08:01, Laurène Guelorget
 wrote:
> Hello,
>
> I am using an Intel Galileo board with a linux distribution
> (LINUX_IMAGE_FOR_SD_Intel_Galileo_v0.7.5)
> and I want to install new packages. I think opkg is the package manager on
> this OS but I don't know how
> to use it. I have an internet connection on the Galileo but I don't know how
> to add a repository url to have
> more packages available. For example, I want to install openhab on the
> board, where can I found it and
> do I have to add it in the /etc/opkg/opkg.conf file?

This sounds like a question about whatever the default OS is for the
Galileo not about opkg. I could tell you how to add feeds to opkg but
I can't tell you what URL you'd need for each feed.

Do you know what the default Linux distribution is? If so I might be
able to point you in the right direction at least.

-- 
Paul Barker

Email: p...@paulbarker.me.uk
http://www.paulbarker.me.uk
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [opkg-utils][PATCH 0/3] Patches to support hierarchical package feeds

[Paul Barker]

I'm posting these patches in the hope that someone other than me has some memory
of how the internals of opkg-utils work and can give me a quick review. I can
merge these myself but as they will affect all ipk feeds created by OpenEmbedded
I think it's worth at least trying to get a review on the changes first.

These changes are needed to support alternative feed layouts where package files
may not reside in the same directory as the 'Packages' index file. A patch to
add the option of creating such an alternative layout will also be posted to the
openembedded-core mailing list for comment.

These patches have been tested on qemuarm with opkg pointed at feeds created
with these patches applied. It has been confirmed that 'opkg update && opkg
install ncurses' works correctly where ncurses was not previously installed.

Paul Barker (3):
  opkg.py: Allow filename to be a relative path
  opkg-make-index: Recursively scan for packages
  opkg-update-index: Emit relative path to package file

 opkg-make-index   | 29 ++---
 opkg-update-index |  2 +-
 opkg.py   | 12 ++--
 3 files changed, 29 insertions(+), 14 deletions(-)

-- 
1.9.2

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [opkg-utils PATCH] detect ability to use --format=gnu with tar

[tom]

From: Thomas Ingleby 

If opkg-build is being used on a platform not using GNU tar, format=gnu will 
necessarily work.

Thomas Ingleby (1):
  opkg-build: add detection if using GNU tar.

 opkg-build | 17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

-- 
1.9.2

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [opkg-utils PATCH] opkg-build: add detection if using GNU tar.

[tom]

From: Thomas Ingleby 

* Some options of GNU tar do not exist on other implementations

Signed-off-by: Thomas Ingleby 
---
 opkg-build | 17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/opkg-build b/opkg-build
index e314712..8abc14d 100755
--- a/opkg-build
+++ b/opkg-build
@@ -159,6 +159,17 @@ ogargs=""
 outer=ar
 noclean=0
 opkext=0
+
+tarformat=""
+#Probably not the best way to detect if running on a system without full GNU 
tar
+set +e
+tar --help | grep "format" &> /dev/null
+if [ $? -eq 0 ]
+then
+tarformat="--format=gnu"
+fi
+set -e
+
 usage="Usage: $0 [-c] [-C] [-O] [-o owner] [-g group]  
[]"
 while getopts "cCg:ho:vO" opt; do
 case $opt in
@@ -233,8 +244,8 @@ tmp_dir=$dest_dir/IPKG_BUILD.$$
 mkdir $tmp_dir
 
 echo $CONTROL > $tmp_dir/tarX
-( cd $pkg_dir && tar $ogargs -X $tmp_dir/tarX -cz --format=gnu -f 
$tmp_dir/data.tar.gz . )
-( cd $pkg_dir/$CONTROL && tar $ogargs -cz --format=gnu -f 
$tmp_dir/control.tar.gz . )
+( cd $pkg_dir && tar $ogargs -X $tmp_dir/tarX -cz $tarformat -f 
$tmp_dir/data.tar.gz . )
+( cd $pkg_dir/$CONTROL && tar $ogargs -cz $tarformat -f 
$tmp_dir/control.tar.gz . )
 rm $tmp_dir/tarX
 
 echo "2.0" > $tmp_dir/debian-binary
@@ -249,7 +260,7 @@ rm -f $pkg_file
 if [ "$outer" = "ar" ] ; then
   ( cd $tmp_dir && ar -crf $pkg_file ./debian-binary ./control.tar.gz 
./data.tar.gz )
 else
-  ( cd $tmp_dir && tar -cz --format=gnu -f $pkg_file ./debian-binary 
./control.tar.gz ./data.tar.gz )
+  ( cd $tmp_dir && tar -cz $tarformat -f $pkg_file ./debian-binary 
./control.tar.gz ./data.tar.gz )
 fi
 
 rm $tmp_dir/debian-binary $tmp_dir/data.tar.gz $tmp_dir/control.tar.gz
-- 
1.9.2

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [opkg-utils PATCH] update-alternatives: fix the sed pattern in remove_alt

[jackie.huang]

From: Jackie Huang 

'\>' is to matches the end of a word, but the executable is
not always a 'word', e.g. /usr/lib64/busybox/usr/bin/[

then such alternatives can not be removed.

So change to use '\s' in the pattern since the following
character of the $path is whitespace.

Signed-off-by: Jackie Huang 
---
 update-alternatives | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/update-alternatives b/update-alternatives
index ffad853..ce7d66c 100644
--- a/update-alternatives
+++ b/update-alternatives
@@ -80,7 +80,7 @@ remove_alt() {
[ ! -f $ad/$name ] && return 0
 
path=`echo $path | protect_slashes | protect_special_character`
-   sed -ne "/^$path\>.*/!p" $ad/$name > $ad/$name.new
+   sed -ne "/^$path\s.*/!p" $ad/$name > $ad/$name.new
mv $ad/$name.new $ad/$name
 }
 
-- 
2.7.4

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [opkg-utils PATCH] update-alternatives: fix the sed pattern in remove_alt

[jackie.huang]

From: Jackie Huang 

'\>' is to matches the end of a word, but the executable is
not always a 'word', e.g. /usr/lib64/busybox/usr/bin/[

then such alternatives can not be removed.

So change to use '\s' in the pattern since the following
character of the $path is whitespace.

Signed-off-by: Jackie Huang 
---
 update-alternatives | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/update-alternatives b/update-alternatives
index ffad853..ce7d66c 100644
--- a/update-alternatives
+++ b/update-alternatives
@@ -80,7 +80,7 @@ remove_alt() {
[ ! -f $ad/$name ] && return 0
 
path=`echo $path | protect_slashes | protect_special_character`
-   sed -ne "/^$path\>.*/!p" $ad/$name > $ad/$name.new
+   sed -ne "/^$path\s.*/!p" $ad/$name > $ad/$name.new
mv $ad/$name.new $ad/$name
 }
 
-- 
2.7.4

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [opkg-utils PATCH] opkg-make-index: use ctime instead of mtime

[Stefan Agner]

From: Stefan Agner 

When using sstate, two parallel builds can produce two packages
with the same mtime but different checksums. When later one of
those two builds fetches the others ipk, the package index does
not get udpated properly (since mtime matches). This ends up with
messages such as:
  Downloading file:/../tmp/work/../image/...ipk.
  Removing corrupt package file /../sysroot/../var/cache/opkg/volatile/...ipk

However, in that case, ctime is different. Use ctime instead of
mtime to prevent failures like this.

Suggested-by: Khem Raj 
Signed-off-by: Stefan Agner 
---
This addresses the issue discussed here:
http://lists.openembedded.org/pipermail/openembedded-core/2018-October/156348.html

 opkg-make-index | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/opkg-make-index b/opkg-make-index
index 3227fc0..db7bf64 100755
--- a/opkg-make-index
+++ b/opkg-make-index
@@ -115,12 +115,12 @@ for abspath in files:
  pkg = None
  fnameStat = os.stat(abspath)
  if filename in old_pkg_hash:
-  if filename in pkgsStamps and int(fnameStat.st_mtime) == 
pkgsStamps[filename]:
+  if filename in pkgsStamps and int(fnameStat.st_ctime) == 
pkgsStamps[filename]:
 if (verbose):
sys.stderr.write("Found %s in Packages\n" % (filename,))
 pkg = old_pkg_hash[filename]
   else:
-   sys.stderr.write("Found %s in Packages, but mtime differs - 
re-reading\n" % (filename,))
+   sys.stderr.write("Found %s in Packages, but ctime differs - 
re-reading\n" % (filename,))
 
  if not pkg:
   if (verbose):
@@ -137,7 +137,7 @@ for abspath in files:
  else:
   old_filename = ""
  s = packages.add_package(pkg, opt_a)
- pkgsStamps[filename] = fnameStat.st_mtime
+ pkgsStamps[filename] = fnameStat.st_ctime
  if s == 0:
   if old_filename:
# old package was displaced by newer
-- 
2.13.6

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [opkg-devel] [PATCH] opkg-utils: Fix crash on dependency error

[Alejandro del Castillo]

On 05/21/2015 06:27 PM, Haris Okanovic wrote:
> Fix crash on exception in opkg-show-deps when generating an
> 'unsatisfied dependency' error. process_dep() function was
> referencing a missing parameter `pkg`.
> 
> Signed-off-by: Haris Okanovic 
> Reviewed-by: Alejandro del Castillo 
> Acked-by: Brad Mouring 
> Cc: Alejandro del Castillo 
> Cc: Paul Barker 
> ---
>  opkg-show-deps | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/opkg-show-deps b/opkg-show-deps
> index 3c3be6a..4694579 100755
> --- a/opkg-show-deps
> +++ b/opkg-show-deps
> @@ -58,7 +58,7 @@ def find_package(name):
>return provider_hash[name]
>   return None
>  
> -def process_dep(dep):
> +def process_dep(pkg, dep):
>   # Add a provider of the given dependency to the list of required 
> packages
>   # unless a provider is already present in this list.
>   dep = re.sub("\s*\(.*\)", "", dep)
> @@ -83,7 +83,7 @@ def recurse(pkg):
>   if pkg.depends:
>deps = split_list(pkg.depends)
>for dep in deps:
> -   process_dep(dep)
> +   process_dep(pkg, dep)
>  
>  for root in remaining_args:
>   pkgs = find_package(root)
> 

Pulled into master, apologies for the delay!

-- 
Cheers,

Alejandro
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [opkg-devel] [PATCH] opkg-utils: Fix crash on dependency error

[Khem Raj]

> On Sep 29, 2015, at 9:10 AM, Alejandro del Castillo 
>  wrote:
> 
> On 05/21/2015 06:27 PM, Haris Okanovic wrote:
>> Fix crash on exception in opkg-show-deps when generating an
>> 'unsatisfied dependency' error. process_dep() function was
>> referencing a missing parameter `pkg`.
>> 
>> Signed-off-by: Haris Okanovic 
>> Reviewed-by: Alejandro del Castillo 
>> Acked-by: Brad Mouring 
>> Cc: Alejandro del Castillo 
>> Cc: Paul Barker 
>> ---
>> opkg-show-deps | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>> 
>> diff --git a/opkg-show-deps b/opkg-show-deps
>> index 3c3be6a..4694579 100755
>> --- a/opkg-show-deps
>> +++ b/opkg-show-deps
>> @@ -58,7 +58,7 @@ def find_package(name):
>>   return provider_hash[name]
>>  return None
>> 
>> -def process_dep(dep):
>> +def process_dep(pkg, dep):
>>  # Add a provider of the given dependency to the list of required 
>> packages
>>  # unless a provider is already present in this list.
>>  dep = re.sub("\s*\(.*\)", "", dep)
>> @@ -83,7 +83,7 @@ def recurse(pkg):
>>  if pkg.depends:
>>   deps = split_list(pkg.depends)
>>   for dep in deps:
>> -   process_dep(dep)
>> +   process_dep(pkg, dep)
>> 
>> for root in remaining_args:
>>  pkgs = find_package(root)
>> 
> 
> Pulled into master, apologies for the delay!


can you also pull in

http://git.openembedded.org/openembedded-core/tree/meta/recipes-devtools/opkg/opkg/0001-libopkg-include-stdio.h-for-getting-FILE-defined.patch

> 
> --
> Cheers,
> 
> Alejandro
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [opkg-utils][PATCH 18/22] opkg.py: cast lines from controlfile as string

[Martin Jansa]

Signed-off-by: Martin Jansa 
---
 opkg.py |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/opkg.py b/opkg.py
index 84583be..6c39616 100644
--- a/opkg.py
+++ b/opkg.py
@@ -206,7 +206,7 @@ class Package:
 while 1:
 if not line: break
 line = line.rstrip()
-lineparts = re.match(r'([\w-]*?):\s*(.*)', line)
+lineparts = re.match(r'([\w-]*?):\s*(.*)', str(line))
 if lineparts:
 name = lineparts.group(1).lower()
 value = lineparts.group(2)
-- 
1.7.8.5

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [opkg-utils][PATCH 0/1] opkg-make-index: small fix for filelist

[Martin Jansa]

The following changes since commit 423ecd36b4782327c16f516885d1248249c7724a:

  Changed call to subprocess.check_output which isn't compatible with Python 
2.6 (2012-06-19 08:34:48 +0100)

are available in the git repository at:

  git://github.com/shr-project/opkg-utils master
  https://github.com/shr-project/opkg-utils/tree/jansa/pull

Marc Olzheim (1):
  opkg-make-index: fix mis-indented else:

 opkg-make-index | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
1.7.12

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [opkg-utils][PATCH 1/1] opkg-make-index: fix mis-indented else:

[Martin Jansa]

From: Marc Olzheim 

Signed-off-by: Martin Jansa 
---
 opkg-make-index | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/opkg-make-index b/opkg-make-index
index 1c3a8e1..44fa64d 100755
--- a/opkg-make-index
+++ b/opkg-make-index
@@ -213,7 +213,7 @@ if filelist_filename:
 (h,t) = os.path.split(fn)
 if not t: continue
 if t not in files: files[t] = name+':'+fn
-else: files[t] = files[t] + ',' + name+':'+fn
+else: files[t] = files[t] + ',' + name+':'+fn
 
 tmp_filelist_filename = ("%s.%d" % (filelist_filename, os.getpid()))
 f = open(tmp_filelist_filename, "w")
-- 
1.7.12

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [opkg-utils][PATCH 2/3] opkg-make-index: Recursively scan for packages

[Paul Barker]

The new 'relpath' argument to the initialiser of a Package object is used so
that file paths will be given relative to the base packages directory.

Paths are given relative to pkg_dir as that seems to make the most sense. It
certainly works when the 'Packages' file is written to pkg_dir. If the
'Packages' file is written elsewhere it is assumed that the user will know what
the paths are relative to. This is similar to debian feeds where the paths in a
'Packages' file is not stored in the packages pool but is stored in a separate
directory, yet paths are given relative to the common base of these directories.

Signed-off-by: Paul Barker 
---
 opkg-make-index | 29 ++---
 1 file changed, 18 insertions(+), 11 deletions(-)

diff --git a/opkg-make-index b/opkg-make-index
index 44fa64d..2fdf95c 100755
--- a/opkg-make-index
+++ b/opkg-make-index
@@ -1,7 +1,6 @@
 #!/usr/bin/env python
 
 import sys, os, posixpath
-from glob import glob
 import subprocess
 import opkg
 import getopt
@@ -92,32 +91,40 @@ if old_filename:
 
 if (verbose):
  sys.stderr.write("Reading in all the package info from %s\n" % (pkg_dir, 
))
-files=glob(pkg_dir + '/*.opk') + glob(pkg_dir + '/*.deb') + glob(pkg_dir + 
'/*.ipk')
+
+files=[]
+opkg_extensions=['.ipk','.opk','.deb']
+for dirpath, dirnames, filenames in os.walk(pkg_dir):
+for f in filenames:
+ext = os.path.splitext(f)[1]
+if ext in opkg_extensions:
+files.append(os.path.join(dirpath, f))
+
 files.sort()
-for filename in files:
+for abspath in files:
   try:
- basename = os.path.basename(filename)
+ filename = os.path.relpath(abspath, pkg_dir)
  pkg = None
- fnameStat = os.stat(filename)
- if basename in old_pkg_hash:
-  if basename in pkgsStamps and int(fnameStat.st_mtime) == 
pkgsStamps[basename]:
+ fnameStat = os.stat(abspath)
+ if filename in old_pkg_hash:
+  if filename in pkgsStamps and int(fnameStat.st_mtime) == 
pkgsStamps[filename]:
 if (verbose):
sys.stderr.write("Found %s in Packages\n" % (filename,))
-pkg = old_pkg_hash[basename]
+pkg = old_pkg_hash[filename]
   else:
sys.stderr.write("Found %s in Packages, but mtime differs - 
re-reading\n" % (filename,))
 
  if not pkg:
   if (verbose):
sys.stderr.write("Reading info for package %s\n" % (filename,))
-  pkg = opkg.Package(filename)
+  pkg = opkg.Package(abspath, relpath=pkg_dir)
  pkg_key = ("%s:%s" % (pkg.package, pkg.architecture))
  if (pkg_key in packages.packages):
   old_filename = packages.packages[pkg_key].filename
  else:
   old_filename = ""
  s = packages.add_package(pkg)
- pkgsStamps[basename] = fnameStat.st_mtime
+ pkgsStamps[filename] = fnameStat.st_mtime
  if s == 0:
   if old_filename:
# old package was displaced by newer
@@ -127,7 +134,7 @@ for filename in files:
 print(("%s/%s" % (pkg_dir, old_filename)))
  else:
   if opt_m:
-   to_morgue(basename)
+   to_morgue(filename)
   if opt_s:
print(filename)
   except OSError as e:
-- 
1.9.2

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [opkg-devel] Re: [opkg-utils PATCH] update-alternatives: Installing fails for "["

[Paul Barker]

On 31 October 2014 01:23, Liu Jian  wrote:
> Insalling packages using update-alternatives will give the following
> error lines:
> sed: -e expression #1, char 41: unterminated address regex
> sed: -e expression #1, char 42: unterminated address regex
> This is caused by the script update-alternatives.
> "[" can not be used directly in sed expression, which should be escaped
> in sed expression.
>
> Signed-off-by: Jian Liu 
> ---
> update-alternatives | 6 +-
> 1 files changed, 5 insertions(+), 1 deletions(-)

I've merged this to opkg-utils, many thanks!

I'm about to send a patch for openembedded-core which updates the
opkg-utils SRCREV to use this new commit.

-- 
Paul Barker

Email: p...@paulbarker.me.uk
http://www.paulbarker.me.uk
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [opkg-devel] [opkg-utils PATCH] update-alternatives: avoid double slash problem

[Paul Barker]

On 21 November 2014 at 10:11, Chen Qi  wrote:
> Signed-off-by: Chen Qi 
> ---
>  update-alternatives | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/update-alternatives b/update-alternatives
> index 8916cbd..ca01d5d 100644
> --- a/update-alternatives
> +++ b/update-alternatives
> @@ -97,7 +97,7 @@ find_best_alt() {
> [ $# -lt 1 ] && return 1
> [ ! -f $ad/$name ] && return 0
>
> -   link=$OPKG_OFFLINE_ROOT/`head -n 1 $ad/$name`
> +   link=$OPKG_OFFLINE_ROOT`head -n 1 $ad/$name`
>
> prio=`sed -ne "1!p" $ad/$name | sed -e "s/\(.*\) \(.*\)/\2 \1/g" | 
> sort -nr | head -n 1 | sed 's/ [^ ]*$//'`
> if [ -z "$prio" ]; then
> --
> 1.9.1
>

I've applied this with a quick description of the issue added to the
commit message. You can send a SRCREV update for opkg-utils in oe-core
now.

Cheers,

-- 
Paul Barker

Email: p...@paulbarker.me.uk
http://www.paulbarker.me.uk
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [opkg-utils PATCH] opkg-build*: fix empty package name in error message

[Adam Trhon]

When opkg-build detects illegal character in package name it prints an error
message with this name. Due to a wrong variable name the package name in the
error message is empty. The same error occurs in opkg-buildpackage as well.
This patch fixes both.

Signed-off-by: Adam Trhon 
---
 opkg-build| 2 +-
 opkg-buildpackage | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/opkg-build b/opkg-build
index e02eaca..0fe513a 100755
--- a/opkg-build
+++ b/opkg-build
@@ -108,7 +108,7 @@ You probably want to chown these to a system user: " >&2
[ "$?" -ne 0 ] && PKG_ERROR=1
 
if echo $pkg | grep '[^a-z0-9.+-]'; then
-   echo "*** Error: Package name $name contains illegal 
characters, (other than [a-z0-9.+-])" >&2
+   echo "*** Error: Package name $pkg contains illegal characters, 
(other than [a-z0-9.+-])" >&2
PKG_ERROR=1;
fi
 
diff --git a/opkg-buildpackage b/opkg-buildpackage
index 719c9a5..b7c0e8c 100755
--- a/opkg-buildpackage
+++ b/opkg-buildpackage
@@ -66,7 +66,7 @@ pkg_appears_sane_control() {
required_field Description >/dev/null
 
if echo $pkg | grep '[^a-z0-9.+-]'; then
-   echo "opkg-build: Error: Package name $name contains illegal 
characters, (other than [a-z0-9.+-])"
+   echo "opkg-build: Error: Package name $pkg contains illegal 
characters, (other than [a-z0-9.+-])"
PKG_ERROR=1;
fi
 
-- 
2.14.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [opkg-utils PATCH] opkg.py: Fix run-time error in call to ArFile

[Jeffrey Pautler]

Signed-off-by: Jeffrey Pautler 
---
opkg.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/opkg.py b/opkg.py
index 4d6f020..9131755 100644
--- a/opkg.py
+++ b/opkg.py
@@ -168,7 +168,7 @@ class Package(object):
 tar = tarfile.open(fn, "r", f)
 tarStream = tar.extractfile("./control.tar.gz")
 else:
-ar = ArFile(f, fn)
+ar = arfile.ArFile(f, fn)
 tarStream = ar.open("control.tar.gz")
 tarf = tarfile.open("control.tar.gz", "r", tarStream)
 try:
--
2.7.4
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [opkg-devel] [opkg-utils PATCH] opkg.py: Remove reformatting of description field

[Alejandro del Castillo]

Agreed, opkg-make-index spould not be formatting control files. 
Description should be treated as any other field.


merged

On 10/05/2017 09:05 AM, Jeffrey Pautler wrote:

The Debian Policy Manual describes the format of the description field.

This includes information about how lines might be wrapped by programs

displaying this information, how to mark lines to not be wrapped, how

to mark a line as blank, and how leading spaces on a multi-line

description might be deleted.

By reformatting the description field in opkg.py, we are breaking many

of these behaviors and taking control of formatting away from the

author of the control file. Instead, we should simply copy the

description field with no reformatting.

Signed-off-by: Jeffrey Pautler 

---

opkg.py | 8 ++--

1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/opkg.py b/opkg.py

index 9131755..c0cdcd5 100644

--- a/opkg.py

+++ b/opkg.py

@@ -230,7 +230,7 @@ class Package(object):

  name = lineparts.group(1).lower()

  value = lineparts.group(2)

  while 1:

-    line = control.readline()

+    line = control.readline().rstrip()

  if not line: break

  if line[0] != ' ': break

  value = value + '\n' + line

@@ -480,11 +480,7 @@ class Package(object):

  if self.installed_size: out = out + "InstalledSize: %d\n" % 
int(self.installed_size)


  if self.filename: out = out + "Filename: %s\n" % (self.filename)

  if self.source: out = out + "Source: %s\n" % (self.source)

-    if self.description:

-    printable_description = 
textwrap.dedent(self.description).strip()


-    summary = printable_description.split('\n', 1)[0]

-    printable_description = printable_description.split('\n', 
1)[-1].strip()


-    out = out + "Description: %s\n%s\n" % (summary, 
textwrap.fill(printable_description, width=74, initial_indent=' ', 
subsequent_indent=' '))


+    if self.description: out = out + "Description: %s\n" % 
(self.description)


  if self.oe: out = out + "OE: %s\n" % (self.oe)

  if self.homepage: out = out + "HomePage: %s\n" % (self.homepage)

  if self.license: out = out + "License: %s\n" % (self.license)

--

2.7.4

--
You received this message because you are subscribed to the Google 
Groups "opkg-devel" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to opkg-devel+unsubscr...@googlegroups.com 
.
For more options, visit https://groups.google.com/d/optout 
.


--
Cheers,

Alejandro
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [opkg-utils PATCH] update-alternatives: fix the sed pattern in remove_alt

[Huang, Jie (Jackie)]

Sorry I forgot adding opkg-devel, so I just re-sent with opkg-devel added in.

Thanks,
Jackie

> -Original Message-
> From: yocto-boun...@yoctoproject.org [mailto:yocto-
> boun...@yoctoproject.org] On Behalf Of jackie.hu...@windriver.com
> Sent: Friday, January 19, 2018 10:54
> To: yocto@yoctoproject.org
> Subject: [yocto] [opkg-utils PATCH] update-alternatives: fix the sed pattern 
> in
> remove_alt
> 
> From: Jackie Huang 
> 
> '\>' is to matches the end of a word, but the executable is
> not always a 'word', e.g. /usr/lib64/busybox/usr/bin/[
> 
> then such alternatives can not be removed.
> 
> So change to use '\s' in the pattern since the following
> character of the $path is whitespace.
> 
> Signed-off-by: Jackie Huang 
> ---
>  update-alternatives | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/update-alternatives b/update-alternatives
> index ffad853..ce7d66c 100644
> --- a/update-alternatives
> +++ b/update-alternatives
> @@ -80,7 +80,7 @@ remove_alt() {
>   [ ! -f $ad/$name ] && return 0
> 
>   path=`echo $path | protect_slashes | protect_special_character`
> - sed -ne "/^$path\>.*/!p" $ad/$name > $ad/$name.new
> + sed -ne "/^$path\s.*/!p" $ad/$name > $ad/$name.new
>   mv $ad/$name.new $ad/$name
>  }
> 
> --
> 2.7.4
> 
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [opkg-utils PATCH] opkg-make-index: use ctime instead of mtime

[richard . purdie]

On Fri, 2018-10-19 at 17:38 +0200, Stefan Agner wrote:
> From: Stefan Agner 
> 
> When using sstate, two parallel builds can produce two packages
> with the same mtime but different checksums. When later one of
> those two builds fetches the others ipk, the package index does
> not get udpated properly (since mtime matches). This ends up with
> messages such as:
>   Downloading file:/../tmp/work/../image/...ipk.
>   Removing corrupt package file
> /../sysroot/../var/cache/opkg/volatile/...ipk
> 
> However, in that case, ctime is different. Use ctime instead of
> mtime to prevent failures like this.
> 
> Suggested-by: Khem Raj 
> Signed-off-by: Stefan Agner 

Acked-by: Richard Purdie 

(I've been following this problem and this makes sense to me)

> ---
> This addresses the issue discussed here:
> 
http://lists.openembedded.org/pipermail/openembedded-core/2018-October/156348.html
> 
>  opkg-make-index | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/opkg-make-index b/opkg-make-index
> index 3227fc0..db7bf64 100755
> --- a/opkg-make-index
> +++ b/opkg-make-index
> @@ -115,12 +115,12 @@ for abspath in files:
>   pkg = None
>   fnameStat = os.stat(abspath)
>   if filename in old_pkg_hash:
> -  if filename in pkgsStamps and int(fnameStat.st_mtime) ==
> pkgsStamps[filename]:
> +  if filename in pkgsStamps and int(fnameStat.st_ctime) ==
> pkgsStamps[filename]:
>  if (verbose):
> sys.stderr.write("Found %s in Packages\n" %
> (filename,))
>  pkg = old_pkg_hash[filename]
>else:
> -   sys.stderr.write("Found %s in Packages, but mtime
> differs - re-reading\n" % (filename,))
> +   sys.stderr.write("Found %s in Packages, but ctime
> differs - re-reading\n" % (filename,))
>  
>   if not pkg:
>if (verbose):
> @@ -137,7 +137,7 @@ for abspath in files:
>   else:
>old_filename = ""
>   s = packages.add_package(pkg, opt_a)
> - pkgsStamps[filename] = fnameStat.st_mtime
> + pkgsStamps[filename] = fnameStat.st_ctime
>   if s == 0:
>if old_filename:
> # old package was displaced by newer

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [opkg-utils PATCH] opkg-make-index: use ctime instead of mtime

[Khem Raj]

On Sat, Oct 20, 2018 at 10:16 AM  wrote:
>
> On Fri, 2018-10-19 at 17:38 +0200, Stefan Agner wrote:
> > From: Stefan Agner 
> >
> > When using sstate, two parallel builds can produce two packages
> > with the same mtime but different checksums. When later one of
> > those two builds fetches the others ipk, the package index does
> > not get udpated properly (since mtime matches). This ends up with
> > messages such as:
> >   Downloading file:/../tmp/work/../image/...ipk.
> >   Removing corrupt package file
> > /../sysroot/../var/cache/opkg/volatile/...ipk
> >
> > However, in that case, ctime is different. Use ctime instead of
> > mtime to prevent failures like this.
> >
> > Suggested-by: Khem Raj 
> > Signed-off-by: Stefan Agner 
>
> Acked-by: Richard Purdie 
>

Yep, thats for following up with implementing it.

Acked-by: Khem Raj 

> (I've been following this problem and this makes sense to me)
>
> > ---
> > This addresses the issue discussed here:
> >
> http://lists.openembedded.org/pipermail/openembedded-core/2018-October/156348.html
> >
> >  opkg-make-index | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/opkg-make-index b/opkg-make-index
> > index 3227fc0..db7bf64 100755
> > --- a/opkg-make-index
> > +++ b/opkg-make-index
> > @@ -115,12 +115,12 @@ for abspath in files:
> >   pkg = None
> >   fnameStat = os.stat(abspath)
> >   if filename in old_pkg_hash:
> > -  if filename in pkgsStamps and int(fnameStat.st_mtime) ==
> > pkgsStamps[filename]:
> > +  if filename in pkgsStamps and int(fnameStat.st_ctime) ==
> > pkgsStamps[filename]:
> >  if (verbose):
> > sys.stderr.write("Found %s in Packages\n" %
> > (filename,))
> >  pkg = old_pkg_hash[filename]
> >else:
> > -   sys.stderr.write("Found %s in Packages, but mtime
> > differs - re-reading\n" % (filename,))
> > +   sys.stderr.write("Found %s in Packages, but ctime
> > differs - re-reading\n" % (filename,))
> >
> >   if not pkg:
> >if (verbose):
> > @@ -137,7 +137,7 @@ for abspath in files:
> >   else:
> >old_filename = ""
> >   s = packages.add_package(pkg, opt_a)
> > - pkgsStamps[filename] = fnameStat.st_mtime
> > + pkgsStamps[filename] = fnameStat.st_ctime
> >   if s == 0:
> >if old_filename:
> > # old package was displaced by newer
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [opkg-devel] [opkg-utils PATCH] update-alternatives: Fix link relocation support

[Alejandro Del Castillo]

good catch, thanks for the fix!

merged

On 11/11/18 8:19 AM, Niko Mauno wrote:
> Commit fcb2633921eb9bb711aa264247aebcfdd4ae which added Debian-style
> support for link relocation tries to relocate symbolic link on host OS,
> resulting in following-like error when two alternative packages have
> symbolic link source located in different directories (/bin/rev ->
> /bin/busybox.nosuid and /usr/bin/rev -> /usr/bin/rev.util-linux):
> 
>update-alternatives: renaming rev link from /bin/rev to /usr/bin/rev
>mv: cannot stat '/bin/rev': No such file or directory
> 
> Fix the issue by prefixing 'olink' and 'link' variable references with
> path to targeted root filesystem's root directory.
> 
> Signed-off-by: Niko Mauno 
> ---
>   update-alternatives | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/update-alternatives b/update-alternatives
> index 89a440b..d4fa7eb 100644
> --- a/update-alternatives
> +++ b/update-alternatives
> @@ -58,7 +58,7 @@ register_alt() {
>   local link_str=`echo $link | protect_slashes`
>   sed -e "1s/.*/$link_str/" $ad/$name > $ad/$name.new
>   mv $ad/$name.new $ad/$name
> - mv $olink $link
> + mv $OPKG_OFFLINE_ROOT$olink $OPKG_OFFLINE_ROOT$link
>   fi
>   else
>   echo "$link" > "$ad/$name"
> 

-- 
Cheers,

Alejandro
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [opkg-utils PATCH 2/2] opkg.py/write_packages_file: call __str__ instead of __repr__

[Alejandro del Castillo]

Commit b9eec00a67f13ad9f9526caf591578b40d73a391 correctly renamed
__repr__to __str__. A call site in write_packages_file was missed.

Signed-off-by: Alejandro del Castillo 
---
 opkg.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/opkg.py b/opkg.py
index fe6b9e0..2acc469 100644
--- a/opkg.py
+++ b/opkg.py
@@ -533,7 +533,7 @@ class Packages(object):
 names = list(self.packages.keys())
 names.sort()
 for name in names:
-f.write(self.packages[name].__repr__())
+f.write(self.packages[name].__str__())
 return
 
 def keys(self):
-- 
1.9.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [opkg-utils][PATCH] opkg-list-fields: fix to print the fields again

[Martin Jansa]

* printing opkg.Package directly doesn't return anything useful now
  

* we need to call Package.print() function and specify which checksums
  to print, we can include both md5 and sha256 for opkg-list-fields

* it was changed in this commit:
  commit 601d691dd80ef494aef069017edc5bf80aa883a1
  Author: Alejandro del Castillo 
  Date:   Wed Dec 19 11:40:15 2018 -0600

opkg-make-index: add sha256sum support

  which replaced the modified __str__ function with print(self, checksum)

Signed-off-by: Martin Jansa 
---
 opkg-list-fields | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/opkg-list-fields b/opkg-list-fields
index c14a90f..8a5a588 100755
--- a/opkg-list-fields
+++ b/opkg-list-fields
@@ -11,5 +11,4 @@ def usage():
 if (len(sys.argv) < 2):
  usage()
 
-print(opkg.Package(sys.argv[1]))
-
+print(opkg.Package(sys.argv[1]).print(('md5','sha256')))
-- 
2.17.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [opkg-devel] [PATCH][opkg] bug 13528 add SPDX id to opkg

[Alejandro Del Castillo]

Hi Yann,

Thanks again for adding the headers. Your patch looks good, except for
one line that has a duplicated header:

/core/26_prefer_arch_to_version.py
index 0a0d66b..82934c1 100755
--- a/tests/core/26_prefer_arch_to_version.py
+++ b/tests/core/26_prefer_arch_to_version.py
@@ -1,4 +1,5 @@
-#! /usr/bin/env python3
+#! /usr/bin/env python3# SPDX-License-Identifier: GPL-2.0-only
+# SPDX-License-Identifier: GPL-2.0-only
  #

could you send a v2? regarding m4 files, I looked around a bit and 
didn't find project adding SPDX identifiers to them

Cheers,

Alejandro

On 10/22/19 9:55 AM, Yann CARDAILLAC wrote:
> Hi,
> 
> I'm working on bug : 
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13528 
> 
>
>  I've a first patch proposal. Note that I didn't knew what to do with
>  m4/gpgme.m4 the license header seems pretty weird to me...
> 
> Regards,
> 
> -- SMILE 
> 
>
>  20 rue des Jardins 92600 Asnières-sur-Seine
> 
>  *Yann CARDAILLAC* Ingénieur Systèmes Embarqués
> 
> email yann.cardail...@smile.fr  url
> http://www.smile.eu 
> 
> 
> 
> 
> Twitter 
> 
>  Facebook 
> 
>  LinkedIn 
> 
>  Github 
> 
> 
> 
> 
> 
> 
> eco Pour la planète, n'imprimez ce mail que si c'est nécessaire
> 
> -- You received this message because you are subscribed to the Google
>  Groups "opkg-devel" group. To unsubscribe from this group and stop
> receiving emails from it, send an email to
> opkg-devel+unsubscr...@googlegroups.com 
> . To view this
> discussion on the web visit 
> https://groups.google.com/d/msgid/opkg-devel/CAA984JWqcX5oDhumXYBom%2BZyxD%2Bbo7oGmTzLx_tXejvPaR1UKQ%40mail.gmail.com
>  
> .

--
> 
Cheers,

Alejandro
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [opkg-devel] [PATCH][opkg] bug 13528 add SPDX id to opkg

[Yann CARDAILLAC]

Hi Alejandro,

Here's patch v2

Thanks for your sharpened eyes !

Regards,

On Thu, Oct 24, 2019 at 9:39 PM Alejandro Del Castillo <
alejandro.delcasti...@ni.com> wrote:

> Hi Yann,
>
> Thanks again for adding the headers. Your patch looks good, except for
> one line that has a duplicated header:
>
> /core/26_prefer_arch_to_version.py
> index 0a0d66b..82934c1 100755
> --- a/tests/core/26_prefer_arch_to_version.py
> +++ b/tests/core/26_prefer_arch_to_version.py
> @@ -1,4 +1,5 @@
> -#! /usr/bin/env python3
> +#! /usr/bin/env python3# SPDX-License-Identifier: GPL-2.0-only
> +# SPDX-License-Identifier: GPL-2.0-only
>   #
>
> could you send a v2? regarding m4 files, I looked around a bit and
> didn't find project adding SPDX identifiers to them
>
> Cheers,
>
> Alejandro
>
> On 10/22/19 9:55 AM, Yann CARDAILLAC wrote:
> > Hi,
> >
> > I'm working on bug :
> > https://bugzilla.yoctoproject.org/show_bug.cgi?id=13528
> > <
> https://urldefense.com/v3/__https://bugzilla.yoctoproject.org/show_bug.cgi?id=13528__;!fqWJcnlTkjM!4DVD9lP2UdCF5UedI8J-XjhQQuyDhmAiLaOXk8OW5KMCFRzG2ASP_BdrxnvBnCnb0TyYNQ$
> >
> >
> >  I've a first patch proposal. Note that I didn't knew what to do with
> >  m4/gpgme.m4 the license header seems pretty weird to me...
> >
> > Regards,
> >
> > -- SMILE
> > <
> https://urldefense.com/v3/__http://www.smile.eu/__;!fqWJcnlTkjM!4DVD9lP2UdCF5UedI8J-XjhQQuyDhmAiLaOXk8OW5KMCFRzG2ASP_BdrxnvBnCnfbDCHYw$
> >
> >
> >  20 rue des Jardins 92600 Asnières-sur-Seine
> >
> >  *Yann CARDAILLAC* Ingénieur Systèmes Embarqués
> >
> > email yann.cardail...@smile.fr  url
> > http://www.smile.eu
> > <
> https://urldefense.com/v3/__http://www.smile.eu__;!fqWJcnlTkjM!4DVD9lP2UdCF5UedI8J-XjhQQuyDhmAiLaOXk8OW5KMCFRzG2ASP_BdrxnvBnCmV9R4jPA$
> >
> >
> >
> >
> > Twitter
> > <
> https://urldefense.com/v3/__https://twitter.com/GroupeSmile__;!fqWJcnlTkjM!4DVD9lP2UdCF5UedI8J-XjhQQuyDhmAiLaOXk8OW5KMCFRzG2ASP_BdrxnvBnCkq-mFzcw$
> >
> >  Facebook
> > <
> https://urldefense.com/v3/__https://www.facebook.com/smileopensource__;!fqWJcnlTkjM!4DVD9lP2UdCF5UedI8J-XjhQQuyDhmAiLaOXk8OW5KMCFRzG2ASP_BdrxnvBnCk8LxW08A$
> >
> >  LinkedIn
> > <
> https://urldefense.com/v3/__https://www.linkedin.com/company/smile__;!fqWJcnlTkjM!4DVD9lP2UdCF5UedI8J-XjhQQuyDhmAiLaOXk8OW5KMCFRzG2ASP_BdrxnvBnCk5-3y08w$
> >
> >  Github
> > <
> https://urldefense.com/v3/__https://github.com/Smile-SA__;!fqWJcnlTkjM!4DVD9lP2UdCF5UedI8J-XjhQQuyDhmAiLaOXk8OW5KMCFRzG2ASP_BdrxnvBnClEOxUzoA$
> >
> >
> >
> >
> >
> >
> > eco Pour la planète, n'imprimez ce mail que si c'est nécessaire
> >
> > -- You received this message because you are subscribed to the Google
> >  Groups "opkg-devel" group. To unsubscribe from this group and stop
> > receiving emails from it, send an email to
> > opkg-devel+unsubscr...@googlegroups.com
> > . To view this
> > discussion on the web visit
> >
> https://groups.google.com/d/msgid/opkg-devel/CAA984JWqcX5oDhumXYBom%2BZyxD%2Bbo7oGmTzLx_tXejvPaR1UKQ%40mail.gmail.com
> >
> > <
> https://urldefense.com/v3/__https://groups.google.com/d/msgid/opkg-devel/CAA984JWqcX5oDhumXYBom*2BZyxD*2Bbo7oGmTzLx_tXejvPaR1UKQ*40mail.gmail.com?utm_medium=email&utm_source=footer__;JSUl!fqWJcnlTkjM!4DVD9lP2UdCF5UedI8J-XjhQQuyDhmAiLaOXk8OW5KMCFRzG2ASP_BdrxnvBnCn7bez8Tg$
> >.
>
> --
> >
> Cheers,
>
> Alejandro
>


-- 
[image: SMILE] 

20 rue des Jardins
92600 Asnières-sur-Seine
*Yann CARDAILLAC*
Ingénieur Systèmes Embarqués

[image: email] yann.cardail...@smile.fr
[image: url] http://www.smile.eu

[image: Twitter]  [image: Facebook]
 [image: LinkedIn]
 [image: Github]



[image: eco] Pour la planète, n'imprimez ce mail que si c'est nécessaire
From ba9298741fe993e663c88e642a9636dd9fa17a88 Mon Sep 17 00:00:00 2001
From: Yann CARDAILLAC 
Date: Tue, 22 Oct 2019 16:49:42 +0200
Subject: [PATCH] add SPDX License identifier

Signed-off-by: Yann CARDAILLAC 
---
 intercept/depmod | 1 +
 intercept/ldconfig   | 1 +
 intercept/update-modules | 1 +
 libopkg/cksum_list.c | 2 ++
 libopkg/cksum_list.h | 2 ++
 libopkg/conffile.c   | 2 ++
 libopkg/conffile.h   | 2 ++
 libopkg/conffile_list.c  | 2 ++
 libopkg/conffile_list.h  | 2 ++
 libopkg/file_list.c  | 2 ++
 libopkg/file_list.h  | 2 ++
 libopkg/file_util.c  | 2 ++
 libopkg/file_util.h  | 2 ++
 libopkg/hash_table.c | 2 ++
 libopkg/hash_table.h | 2 ++
 libopkg/list.h   |