Re: Debhelper 7
Re: Debhelper 7
Re: Debhelper 7
2009-12-14 13:02 UTC
On Mon, Dec 14, 2009 at 7:15 AM, Marius Vollmer
<marius.vollmer@nokia.com> wrote:
> On balance, I think it is better to just stick to debhelper 5 in
> Fremantle.
And from our experience in PyMaemo backporting various (but not that
many) packages from debhelper compatibility level 7 to 5, in most
cases you need just to change:
* debian/compat: 7 -> 5
* debian/control: Build-Depends: debhelper (>= 7) -> debhelper (>= 5)
* And maybe comment out a few dh_* calls from debian/rules, which
might not exist on level 5
Now things might get complex if the packaging already uses some new
features of level 7, like those CDBS-like helper rules. In such cases,
looking at versions prior to the compatibility level upgrade might
help doing the downgrade (and most Debian packages are kept in public
SCMs like svn.debian.org).
Regards,
--
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
<marius.vollmer@nokia.com> wrote:
> On balance, I think it is better to just stick to debhelper 5 in
> Fremantle.
And from our experience in PyMaemo backporting various (but not that
many) packages from debhelper compatibility level 7 to 5, in most
cases you need just to change:
* debian/compat: 7 -> 5
* debian/control: Build-Depends: debhelper (>= 7) -> debhelper (>= 5)
* And maybe comment out a few dh_* calls from debian/rules, which
might not exist on level 5
Now things might get complex if the packaging already uses some new
features of level 7, like those CDBS-like helper rules. In such cases,
looking at versions prior to the compatibility level upgrade might
help doing the downgrade (and most Debian packages are kept in public
SCMs like svn.debian.org).
Regards,
--
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
Re: Debhelper 7
2009-12-15 20:10 UTC
On Dec 14, 2009, at 14:02, Anderson Lizardo wrote:
> On Mon, Dec 14, 2009 at 7:15 AM, Marius Vollmer
> <marius.vollmer@nokia.com> wrote:
>> On balance, I think it is better to just stick to debhelper 5 in
>> Fremantle.
>
> And from our experience in PyMaemo backporting various (but not that
> many) packages from debhelper compatibility level 7 to 5, in most
> cases you need just to change:
>
> * debian/compat: 7 -> 5
> * debian/control: Build-Depends: debhelper (>= 7) -> debhelper (>= 5)
> * And maybe comment out a few dh_* calls from debian/rules, which
> might not exist on level 5
One of the huge advantages of moving to debhelper 7 compat is that you can have your debian/rules files look like this:
#!/usr/bin/make -f
%:
dh $@
Simple. You pass everything off to debhelper.
Jeremiah
> On Mon, Dec 14, 2009 at 7:15 AM, Marius Vollmer
> <marius.vollmer@nokia.com> wrote:
>> On balance, I think it is better to just stick to debhelper 5 in
>> Fremantle.
>
> And from our experience in PyMaemo backporting various (but not that
> many) packages from debhelper compatibility level 7 to 5, in most
> cases you need just to change:
>
> * debian/compat: 7 -> 5
> * debian/control: Build-Depends: debhelper (>= 7) -> debhelper (>= 5)
> * And maybe comment out a few dh_* calls from debian/rules, which
> might not exist on level 5
One of the huge advantages of moving to debhelper 7 compat is that you can have your debian/rules files look like this:
#!/usr/bin/make -f
%:
dh $@
Simple. You pass everything off to debhelper.
Jeremiah
Re: Debhelper 7
2009-12-16 07:12 UTC
On Tuesday 15 December 2009 22:10:39 ext Jeremiah Foster, you wrote:
> > * debian/compat: 7 -> 5
> > * debian/control: Build-Depends: debhelper (>= 7) -> debhelper (>= 5)
> > * And maybe comment out a few dh_* calls from debian/rules, which
> > might not exist on level 5
>
> One of the huge advantages of moving to debhelper 7 compat is that you can
> have your debian/rules files look like this:
>
> #!/usr/bin/make -f
> %:
> dh $@
>
> Simple. You pass everything off to debhelper.
That takes care of the packaging part, but not the building part or does it?
AFAICT, if you really want short and implicit rules, you could use CDBS. That
works fine with any debhelper from version 4 and up.
--
Rémi Denis-Courmont
Nokia Devices R&D, Maemo Software, Helsinki
> > * debian/compat: 7 -> 5
> > * debian/control: Build-Depends: debhelper (>= 7) -> debhelper (>= 5)
> > * And maybe comment out a few dh_* calls from debian/rules, which
> > might not exist on level 5
>
> One of the huge advantages of moving to debhelper 7 compat is that you can
> have your debian/rules files look like this:
>
> #!/usr/bin/make -f
> %:
> dh $@
>
> Simple. You pass everything off to debhelper.
That takes care of the packaging part, but not the building part or does it?
AFAICT, if you really want short and implicit rules, you could use CDBS. That
works fine with any debhelper from version 4 and up.
--
Rémi Denis-Courmont
Nokia Devices R&D, Maemo Software, Helsinki
Re: Debhelper 7
2009-12-17 21:50 UTC
On 16/12/2009 08:12, Rémi Denis-Courmont wrote:
> On Tuesday 15 December 2009 22:10:39 ext Jeremiah Foster, you wrote:
>>> * debian/compat: 7 -> 5
>>> * debian/control: Build-Depends: debhelper (>= 7) -> debhelper (>= 5)
>>> * And maybe comment out a few dh_* calls from debian/rules, which
>>> might not exist on level 5
>>
>> One of the huge advantages of moving to debhelper 7 compat is that you can
>> have your debian/rules files look like this:
>>
>> #!/usr/bin/make -f
>> %:
>> dh $@
>>
>> Simple. You pass everything off to debhelper.
>
> That takes care of the packaging part, but not the building part or does it?
> AFAICT, if you really want short and implicit rules, you could use CDBS. That
> works fine with any debhelper from version 4 and up.
>
That's not exactly the place to do a cdbs vs. debhelper debate, but
(with my debian hat on) I really prefer using debhelper 7 with override
stuff than cdbs. It's really easier to fine-tune.
Is there a reason why scratchbox is stuck with etch base system? In
Debian we usually build packages for unstable using unstable. I can
understand the distro hasn't exactly the same purposes, and that
tracking unstable would be too much work, but why not at least upgrading
too Lenny (which has debhelper 7, though not the version with dh_override_*)
Cheers,
--
Yves-Alexis
> On Tuesday 15 December 2009 22:10:39 ext Jeremiah Foster, you wrote:
>>> * debian/compat: 7 -> 5
>>> * debian/control: Build-Depends: debhelper (>= 7) -> debhelper (>= 5)
>>> * And maybe comment out a few dh_* calls from debian/rules, which
>>> might not exist on level 5
>>
>> One of the huge advantages of moving to debhelper 7 compat is that you can
>> have your debian/rules files look like this:
>>
>> #!/usr/bin/make -f
>> %:
>> dh $@
>>
>> Simple. You pass everything off to debhelper.
>
> That takes care of the packaging part, but not the building part or does it?
> AFAICT, if you really want short and implicit rules, you could use CDBS. That
> works fine with any debhelper from version 4 and up.
>
That's not exactly the place to do a cdbs vs. debhelper debate, but
(with my debian hat on) I really prefer using debhelper 7 with override
stuff than cdbs. It's really easier to fine-tune.
Is there a reason why scratchbox is stuck with etch base system? In
Debian we usually build packages for unstable using unstable. I can
understand the distro hasn't exactly the same purposes, and that
tracking unstable would be too much work, but why not at least upgrading
too Lenny (which has debhelper 7, though not the version with dh_override_*)
Cheers,
--
Yves-Alexis
Re: Debhelper 7
2009-12-18 12:39 UTC
ext Anderson Lizardo wrote:
> Now things might get complex if the packaging already uses some new
> features of level 7, like those CDBS-like helper rules. In such cases,
> looking at versions prior to the compatibility level upgrade might
> help doing the downgrade (and most Debian packages are kept in public
> SCMs like svn.debian.org).
You can also try the debian-squeeze devkit available from scratchbox.org.
Note that this is not (yet) supported by Fremantle SDK and you need to
create your scratchbox targets by hand instead of the installation
script, but should be enough to allow you to use debhelper 7.
Additionally, the devkit is a lot smaller, so the number of packages it
"shadows" is much less. For example, stuff like cdbs is solely left for
target as they properly should be.
Regards,
Jussi
> Now things might get complex if the packaging already uses some new
> features of level 7, like those CDBS-like helper rules. In such cases,
> looking at versions prior to the compatibility level upgrade might
> help doing the downgrade (and most Debian packages are kept in public
> SCMs like svn.debian.org).
You can also try the debian-squeeze devkit available from scratchbox.org.
Note that this is not (yet) supported by Fremantle SDK and you need to
create your scratchbox targets by hand instead of the installation
script, but should be enough to allow you to use debhelper 7.
Additionally, the devkit is a lot smaller, so the number of packages it
"shadows" is much less. For example, stuff like cdbs is solely left for
target as they properly should be.
Regards,
Jussi
Re: Debhelper 7
2009-12-18 13:46 UTC
Hi,
ext Jussi Hakala wrote:
> ext Anderson Lizardo wrote:
>> Now things might get complex if the packaging already uses some new
>> features of level 7, like those CDBS-like helper rules. In such cases,
>> looking at versions prior to the compatibility level upgrade might
>> help doing the downgrade (and most Debian packages are kept in public
>> SCMs like svn.debian.org).
>
> You can also try the debian-squeeze devkit available from scratchbox.org.
>
> Note that this is not (yet) supported by Fremantle SDK and you need to
> create your scratchbox targets by hand instead of the installation
> script, but should be enough to allow you to use debhelper 7.
But I think using something like that would require that Maemo
auto-builder supports it too...
- Eero
ext Jussi Hakala wrote:
> ext Anderson Lizardo wrote:
>> Now things might get complex if the packaging already uses some new
>> features of level 7, like those CDBS-like helper rules. In such cases,
>> looking at versions prior to the compatibility level upgrade might
>> help doing the downgrade (and most Debian packages are kept in public
>> SCMs like svn.debian.org).
>
> You can also try the debian-squeeze devkit available from scratchbox.org.
>
> Note that this is not (yet) supported by Fremantle SDK and you need to
> create your scratchbox targets by hand instead of the installation
> script, but should be enough to allow you to use debhelper 7.
But I think using something like that would require that Maemo
auto-builder supports it too...
- Eero
Re: Debhelper 7
2009-12-18 13:56 UTC
On Fri, Dec 18, 2009 at 9:46 AM, Eero Tamminen <eero.tamminen@nokia.com> wrote:
> ext Jussi Hakala wrote:
>> You can also try the debian-squeeze devkit available from scratchbox.org.
>>
>> Note that this is not (yet) supported by Fremantle SDK and you need to
>> create your scratchbox targets by hand instead of the installation script,
>> but should be enough to allow you to use debhelper 7.
>
> But I think using something like that would require that Maemo
> auto-builder supports it too...
I wonder if it is possible to dynamically select different devkits
from inside a target (using some SBOX_* environment variable), just
like it's possible for selecting a different compiler ? I've managed
to do something similar (using the SBOX_SCRATCHBOX_CONFIG as
documented on /scratchbox/doc/variables.txt) to dynamically change
compilers without requiring to change the target configuration, but I
don't know if tha's possible for devkits too.
If that would at all be possible, it would just be a matter of having
the devkits installed on the autobuilder, without changing the target
setup.
My two cents,
--
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
> ext Jussi Hakala wrote:
>> You can also try the debian-squeeze devkit available from scratchbox.org.
>>
>> Note that this is not (yet) supported by Fremantle SDK and you need to
>> create your scratchbox targets by hand instead of the installation script,
>> but should be enough to allow you to use debhelper 7.
>
> But I think using something like that would require that Maemo
> auto-builder supports it too...
I wonder if it is possible to dynamically select different devkits
from inside a target (using some SBOX_* environment variable), just
like it's possible for selecting a different compiler ? I've managed
to do something similar (using the SBOX_SCRATCHBOX_CONFIG as
documented on /scratchbox/doc/variables.txt) to dynamically change
compilers without requiring to change the target configuration, but I
don't know if tha's possible for devkits too.
If that would at all be possible, it would just be a matter of having
the devkits installed on the autobuilder, without changing the target
setup.
My two cents,
--
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
Re: Debhelper 7
2010-01-13 14:18 UTC
just found this old message:
Marius Vollmer wrote:
> That's the magic. You will likely need to update Perl as well, and then
> update many many Perl modules. This is what I have done for Harmattan,
> and now I am sitting on about 100 packages that I have updated... :-)
it is actually much less
http://www.maemory.com/N900/perl5.10/
http://www.maemory.com/N900/libperl/
but running it in the SDK is a hassle
(you need to move devkit perl away and fix all references)
> You can also backport debhelper 7 to Perl 5.8.
that's what I have done:
http://www.maemory.com/N900/build/
you'll have to move away the dh_* files from your devkits
otherwise it won't use the files from the package.
You could also try the SDK+ based on scratchbox 2
http://maemo-sdk.garage.maemo.org/
which make it easy to use the host perl with
export SBOX_REDIRECT_FORCE=/usr/bin/perl
cheers,
--
Thomas Tanner ------
email: tanner@gmx.de
GnuPG: 1024/5924D4DD
Marius Vollmer wrote:
> That's the magic. You will likely need to update Perl as well, and then
> update many many Perl modules. This is what I have done for Harmattan,
> and now I am sitting on about 100 packages that I have updated... :-)
it is actually much less
http://www.maemory.com/N900/perl5.10/
http://www.maemory.com/N900/libperl/
but running it in the SDK is a hassle
(you need to move devkit perl away and fix all references)
> You can also backport debhelper 7 to Perl 5.8.
that's what I have done:
http://www.maemory.com/N900/build/
you'll have to move away the dh_* files from your devkits
otherwise it won't use the files from the package.
You could also try the SDK+ based on scratchbox 2
http://maemo-sdk.garage.maemo.org/
which make it easy to use the host perl with
export SBOX_REDIRECT_FORCE=/usr/bin/perl
cheers,
--
Thomas Tanner ------
email: tanner@gmx.de
GnuPG: 1024/5924D4DD
> [...] Do you have any specific idea on why debhelper 7 does not run on
> Fremantle SDK (I suppose there's no need to run it on the device)? Is
> there any chance at all to get it working, by upgrading perl or some
> other magic?
Yes, there is a chance, but it is not pretty.
The Fremantle SDK, like all versions of the Maemo SDK, uses Scratchbox
with a specific set of devkits. One of the devkits is the debian-etch
one, and that devkit contains debhelper.
The nature of devkits is that they shadow whatever is in the target.
Thus, installing debhelper 7 in the target doesn't do anything: you will
still get the debhelper from the devkit.
You would either have to update the devkit itself, or somehow disable it
while building your package only.
You can disable the devkits with a snippet like this in debian/rules:
# Sanitize build environment when running inside Scratchbox 1
ifneq (,$(wildcard /targets))
export SBOX_REDIRECT_TO_DIRS=
export PATH=/scratchbox/compilers/bin:/bin:/usr/bin:/scratchbox/tools/bin
endif
This is a hack, and you have to assume responsibility for all the
fall-out that it produces. :)
That's the magic. You will likely need to update Perl as well, and then
update many many Perl modules. This is what I have done for Harmattan,
and now I am sitting on about 100 packages that I have updated... :-)
You can also backport debhelper 7 to Perl 5.8.
On balance, I think it is better to just stick to debhelper 5 in
Fremantle.