headers
Koen Kooi | 30 Nov 2009 19:22
Picon

Re: tagging opkg 0.1.7

On 27 nov, 08:55, Graham Gower <graham.go...@...> wrote:
> Hi all,
>
> I intend to tag opkg 0.1.7 and make a release tarball towards the end
> of next week. I will not make any changes on trunk until then except
> to address issues that arise.

OE is using r402/trunk now, so if people don't start bitching on the
OE lists soon, it looks pretty good.

> If there are any problems that need to be addressed or any patches
> floating around the web that you think I should look at, please speak
> up.

There were some patches for u-a on the oe-devel list that could go in.

regards,

Koen

--

You received this message because you are subscribed to the Google Groups "opkg-devel" group.
To post to this group, send email to opkg-devel@...
To unsubscribe from this group, send email to opkg-devel+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/opkg-devel?hl=en.
Permalink | Reply |
headers
John Willis | 2 Dec 2009 12:46
Favicon

Re: tagging opkg 0.1.7

Hi All,

> OE is using r402/trunk now, so if people don't start bitching on the
> OE lists soon, it looks pretty good.

There seem to be a number of small issues that have surfaced with opkg
(in it's -native OE form) since the SRC bump that are showing up when
building the rootfs for images (in both reported cases, big images, >
200meg rootfs size and lots of packages).

These manifest themselves as opkg errors in the rootfs log (and the
respective package failing leading to the rootfs build failing).

The errors look something like below but the packages very from image
to image (in my case udev seems a constant failure across images but
others have reported that there 'package issues' list is different for
there environment).

"
Installing udev (141-r15.5) to root...
Downloading file:/oe/omap3evm-oe/tmp/deploy/glibc/ipk/omap3-pandora/
udev_141-r15.5_omap3-pandora.ipk
omap3-pandora.ipk
omap3-pandora.ipk
(offline root mode: not running udev.preinst)
omap3-pandora.ipk
(offline root mode: not running udev.preinst)
omap3-pandora.ipk
(offline root mode: not running udev.preinst)
opkg: Cannot create symlink from ./lib/udev/rules.d to '/etc/udev/
(Continue reading)

Permalink | Reply |
headers
Graham Gower | 2 Dec 2009 21:48
Picon

Re: Re: tagging opkg 0.1.7

2009/12/2 John Willis <John.Willis@...>:
> Hi All,
>
>> OE is using r402/trunk now, so if people don't start bitching on the
>> OE lists soon, it looks pretty good.
>
> There seem to be a number of small issues that have surfaced with opkg
> (in it's -native OE form) since the SRC bump that are showing up when
> building the rootfs for images (in both reported cases, big images, >
> 200meg rootfs size and lots of packages).
>
> These manifest themselves as opkg errors in the rootfs log (and the
> respective package failing leading to the rootfs build failing).

Please see libbb/unarchive.c: extract_archive() and let me know if any
of the failures there which set "err = -1" should be downgraded to
warnings. Previously these conditions were not failure conditions only
because they could not be *by design*.

Maybe you want more sanity checks (e.g. Issue 28) instead of fewer?

-Graham

--

You received this message because you are subscribed to the Google Groups "opkg-devel" group.
To post to this group, send email to opkg-devel@...
To unsubscribe from this group, send email to opkg-devel+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/opkg-devel?hl=en.
(Continue reading)

Permalink | Reply |
headers
Koen Kooi | 3 Dec 2009 09:39
Picon

Re: tagging opkg 0.1.7

On 2 dec, 21:48, Graham Gower <graham.go...@...> wrote:
> 2009/12/2 John Willis <John.Wil...@...>:
>
> > Hi All,
>
> >> OE is using r402/trunk now, so if people don't start bitching on the
> >> OE lists soon, it looks pretty good.
>
> > There seem to be a number of small issues that have surfaced with opkg
> > (in it's -native OE form) since the SRC bump that are showing up when
> > building the rootfs for images (in both reported cases, big images, >
> > 200meg rootfs size and lots of packages).
>
> > These manifest themselves as opkg errors in the rootfs log (and the
> > respective package failing leading to the rootfs build failing).
>
> Please see libbb/unarchive.c: extract_archive() and let me know if any
> of the failures there which set "err = -1" should be downgraded to
> warnings. Previously these conditions were not failure conditions only
> because they could not be *by design*.
>
> Maybe you want more sanity checks (e.g. Issue 28) instead of fewer?

I think for 0.1.7 I'd like them to be warnings, we can change them to
errors afterwards.

regards,

Koen
(Continue reading)

Permalink | Reply |
headers
jlc | 4 Dec 2009 21:44
Picon

Re: tagging opkg 0.1.7

Would it be better to have an option to opkg to change the errors into
warnings instead of making them warnings now and errors later?

On Dec 3, 3:39 am, Koen Kooi <koen.k...@...> wrote:
> On 2 dec, 21:48, Graham Gower <graham.go...@...> wrote:
>
>
>
> > 2009/12/2 John Willis <John.Wil...@...>:
>
> > > Hi All,
>
> > >> OE is using r402/trunk now, so if people don't start bitching on the
> > >> OE lists soon, it looks pretty good.
>
> > > There seem to be a number of small issues that have surfaced with opkg
> > > (in it's -native OE form) since the SRC bump that are showing up when
> > > building the rootfs for images (in both reported cases, big images, >
> > > 200meg rootfs size and lots of packages).
>
> > > These manifest themselves as opkg errors in the rootfs log (and the
> > > respective package failing leading to the rootfs build failing).
>
> > Please see libbb/unarchive.c: extract_archive() and let me know if any
> > of the failures there which set "err = -1" should be downgraded to
> > warnings. Previously these conditions were not failure conditions only
> > because they could not be *by design*.
>
> > Maybe you want more sanity checks (e.g. Issue 28) instead of fewer?
>
(Continue reading)

Permalink | Reply |
headers
Graham Gower | 4 Dec 2009 21:49
Picon

Re: Re: tagging opkg 0.1.7

I already made the commit to ignore the errors from extract_archive().
I'll revert that one liner after release.

Opkg needs less options! Less is more.

--

You received this message because you are subscribed to the Google Groups "opkg-devel" group.
To post to this group, send email to opkg-devel@...
To unsubscribe from this group, send email to opkg-devel+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/opkg-devel?hl=en.
Permalink | Reply |
headers
Koen Kooi | 6 Dec 2009 09:55
Picon

Re: tagging opkg 0.1.7

On 4 dec, 21:49, Graham Gower <graham.go...@...> wrote:
> I already made the commit to ignore the errors from extract_archive().
> I'll revert that one liner after release.

I'm not sure if that's a good idea, I ran into this scenario:

/tmp in base-files.ipk is a symlink to /var/tmp
I delete the symlink and create a proper dir for /tmp
opkg upgrade base-files

*boom*

unarchive raises an error and I'm without /etc/fstab, /etc/profile,
etc

I'm not sure what the right behaviour should be, but this isn't. I
suspect opkg should 'roll back' and reinstate the old files on
failure, but I don't know how hard it is to add that.

regards,

Koen

--

You received this message because you are subscribed to the Google Groups "opkg-devel" group.
To post to this group, send email to opkg-devel@...
To unsubscribe from this group, send email to opkg-devel+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/opkg-devel?hl=en.
(Continue reading)

Permalink | Reply |
headers
Graham Gower | 6 Dec 2009 22:15
Picon

Re: Re: tagging opkg 0.1.7

2009/12/6 Koen Kooi <koen.kooi@...>:
> I'm not sure what the right behaviour should be, but this isn't. I
> suspect opkg should 'roll back' and reinstate the old files on
> failure, but I don't know how hard it is to add that.

If you roll back old files then you need to keep the old files around
while you extract the new ones. Current design has avoids this to save
space.

Can you think of an acceptable compromise that would allow us to not
double the required space for a package installation?

-Graham

--

You received this message because you are subscribed to the Google Groups "opkg-devel" group.
To post to this group, send email to opkg-devel@...
To unsubscribe from this group, send email to opkg-devel+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/opkg-devel?hl=en.
Permalink | Reply |
headers
Graham Gower | 7 Dec 2009 01:26
Picon

Re: Re: tagging opkg 0.1.7

0.1.7 has been tagged. Release tarball here:
http://opkg.googlecode.com/files/opkg-0.1.7.tar.gz

Enjoy.
-Graham

--

You received this message because you are subscribed to the Google Groups "opkg-devel" group.
To post to this group, send email to opkg-devel@...
To unsubscribe from this group, send email to opkg-devel+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/opkg-devel?hl=en.
Permalink | Reply |

Gmane