Dylan backports

Dylan backports

[Javier Viguera]

Hi all,

Bear with me if this has been already replied, but what is the procedure 
to get patches applied in maintenance branches (e.g. dylan)?

I sent a couple of patches some time ago:

<http://patchwork.openembedded.org/patch/57455/>
<http://patchwork.openembedded.org/patch/57475/>

that fixes broken builds in Dylan, but I'm not sure if this is the 
correct way because at the moment they have not made their way into the 
repo.

With the current status of dylan, cherokee cannot be downloaded (wrong 
SRC_URI) and net-snmp fails to build when not using 'systemd':

snmpd.c:459: undefined reference to `netsnmp_sd_listen_fds'

-
Javier Viguera
Software Engineer
Digi International® Spain S.A.U.

Re: Dylan backports

[Eric Bénard]

Hi Javier,

Le Thu, 10 Oct 2013 17:55:50 +0200,
Javier Viguera <javier.viguera@digi.com> a écrit :
> Bear with me if this has been already replied, but what is the procedure 
> to get patches applied in maintenance branches (e.g. dylan)?
> 
> I sent a couple of patches some time ago:
> 
> <http://patchwork.openembedded.org/patch/57455/>
> <http://patchwork.openembedded.org/patch/57475/>
> 
> that fixes broken builds in Dylan, but I'm not sure if this is the 
> correct way because at the moment they have not made their way into the 
> repo.
> 
both pushed to dylan-next for testing.

Thanks
Eric

Re: Dylan backports

[Javier Viguera]

Hi Eric, all,

On 10/10/13 21:31, Eric Bénard wrote:
> both pushed to dylan-next for testing.
>
> Thanks
> Eric

I appreciate you included the patches into 'dylan-next' for testing but 
it surprises me they are not in *dylan* yet.

Is this normal? I sent the patches a couple of months ago. They were 
included for testing almost one month ago and yet they are not in *dylan*.

For the moment i keep the patches as *bbappends* in our own layer, but i 
would like to get rid of them once they are included in 'meta-openembedded'.

Thanks for your help.

-
Javier Viguera
Software Engineer
Digi International® Spain S.A.U.

Re: Dylan backports

[Eric Bénard]

Hi Javier,

Le Thu, 7 Nov 2013 15:50:22 +0100,
Javier Viguera <javier.viguera@digi.com> a écrit :
> I appreciate you included the patches into 'dylan-next' for testing but 
> it surprises me they are not in *dylan* yet.
> 
> Is this normal? I sent the patches a couple of months ago. They were 
> included for testing almost one month ago and yet they are not in *dylan*.
> 
that's now pushed, thanks for the reminder.

Eric

cherokee wrong SRC_URI (was Dylan backports)

[Javier Viguera]

Hi Eric,

On 07/11/13 16:14, Eric Bénard wrote:
> that's now pushed, thanks for the reminder.
>
> Eric

Well I should have probably checked that the mirror was still working 
before sending my e-mail but you know ... Murphy's law.

The thing is that for cherokee the mirror I used to download the package 
from has removed it since i sent the patch a couple of months ago.

I'm sorry to have pushed you to merge the patches. Anyway from 
meta-openembedded point of view the status has *not* gone any worse. It 
was not working before (with old cherokee url) and it's not working now 
as well.

I've found a couple of sites with the original package (same md5sum and 
sha256sum):

<ftp://ftp.nluug.nl/pub/internet/cherokee/1.2/1.2.98/cherokee-1.2.98.tar.gz>
<ftp://ftp.heanet.ie/mirrors/cherokee/1.2/1.2.98/cherokee-1.2.98.tar.gz>

but at this moment I'm not sure whether it's worth to keep changing the 
SRC_URI time and time again.

Probably the way to go is to revert my patch leaving the original 
cherokee as a reference and include the package in any of the 
yoctoproject mirrors.

By the way the recipe is now broken not only in Dylan, but also in 
*Dora* and *master*.

Comments?

-
Javier Viguera
Software Engineer
Digi International® Spain S.A.U.

Re: cherokee wrong SRC_URI (was Dylan backports)

[Paul Eggleton]

On Thursday 07 November 2013 17:02:25 Javier Viguera wrote:
> Hi Eric,
> 
> On 07/11/13 16:14, Eric Bénard wrote:
> > that's now pushed, thanks for the reminder.
> > 
> > Eric
> 
> Well I should have probably checked that the mirror was still working
> before sending my e-mail but you know ... Murphy's law.
> 
> The thing is that for cherokee the mirror I used to download the package
> from has removed it since i sent the patch a couple of months ago.
> 
> I'm sorry to have pushed you to merge the patches. Anyway from
> meta-openembedded point of view the status has *not* gone any worse. It
> was not working before (with old cherokee url) and it's not working now
> as well.
> 
> I've found a couple of sites with the original package (same md5sum and
> sha256sum):
> 
> <ftp://ftp.nluug.nl/pub/internet/cherokee/1.2/1.2.98/cherokee-1.2.98.tar.gz>
> <ftp://ftp.heanet.ie/mirrors/cherokee/1.2/1.2.98/cherokee-1.2.98.tar.gz>
> 
> but at this moment I'm not sure whether it's worth to keep changing the
> SRC_URI time and time again.
> 
> Probably the way to go is to revert my patch leaving the original
> cherokee as a reference and include the package in any of the
> yoctoproject mirrors.
> 
> By the way the recipe is now broken not only in Dylan, but also in
> *Dora* and *master*.
> 
> Comments?

1) Let's get the file added to the OE source mirror, that will at least stop 
failures for all branches. Tom, could you please add the file from one of the 
above URLs to our source mirror?

2) Longer term the recipe should just be upgraded; last I checked we've fallen 
quite far behind the current version. Javier, if you're relying on Cherokee is 
that something you'd be prepared to do?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: cherokee wrong SRC_URI (was Dylan backports)

[Javier Viguera]

Hi Paul,

On 07/11/13 17:45, Paul Eggleton wrote:

> 2) Longer term the recipe should just be upgraded; last I checked we've fallen
> quite far behind the current version. Javier, if you're relying on Cherokee is
> that something you'd be prepared to do?

The problem is not the version, the problem is the main cherokee project 
uses those github autogenerated-from-tags tarballs. See:

<http://cherokee-project.com/downloads.html>

Some examples:

<https://github.com/cherokee/webserver/archive/v1.2.103.zip>
...
<https://github.com/cherokee/webserver/archive/v1.2.98.zip>

And as far as i know in this case we cannot rely the checksums remain 
stable.

Anyway at this moment I'm stuck on Dylan working on a BSP layer, so I 
don't have the time to play with other branches, sorry.

My preference at this moment would be to integrate the patch from Eric 
with the German mirror (once fixed in version 3) in all the branches and 
at the same time keep a copy of the tarball in one of the yoctoproject 
source mirrors.

-
Javier Viguera
Software Engineer
Digi International® Spain S.A.U.

Re: cherokee wrong SRC_URI (was Dylan backports)

[Paul Eggleton]

On Thursday 07 November 2013 18:12:46 Javier Viguera wrote:
> On 07/11/13 17:45, Paul Eggleton wrote:
> > 2) Longer term the recipe should just be upgraded; last I checked we've
> > fallen quite far behind the current version. Javier, if you're relying on
> > Cherokee is that something you'd be prepared to do?
> 
> The problem is not the version, the problem is the main cherokee project
> uses those github autogenerated-from-tags tarballs. See:
> 
> <http://cherokee-project.com/downloads.html>
> 
> Some examples:
> 
> <https://github.com/cherokee/webserver/archive/v1.2.103.zip>
> ...
> <https://github.com/cherokee/webserver/archive/v1.2.98.zip>
> 
> And as far as i know in this case we cannot rely the checksums remain
> stable.

This is something that would be worth trying to communicate upstream - these 
tarballs are just not useful as a release mechanism. Help them to understand 
that and we help ourselves.

> Anyway at this moment I'm stuck on Dylan working on a BSP layer, so I
> don't have the time to play with other branches, sorry.

OK, no problem.
 
> My preference at this moment would be to integrate the patch from Eric
> with the German mirror (once fixed in version 3) in all the branches and
> at the same time keep a copy of the tarball in one of the yoctoproject
> source mirrors.

It'll be the OpenEmbedded mirror in this instance, but yes.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre