Re: pd-zexy: broken Build-Depends

[Thorsten Glaser]

IOhannes zmölnig dixit:

>>> Well, your puredata is from before stable... With the current build
>>> depends pd-zexy can be built in stable.
>
> as a matter of fact, i'm not entirely sure about this.

Mh. I’m just building to catch up, m68k had five thousand and then
some packages in Needs-Build one month ago (less than 2800 right
now). Then, those versioned Build-Depends are really helpful, as,
which is in my eyes a bug, wanna-build does not order the queue
by B-D actuality for such cases (at all), as long as a dependency
exists and is installable.

> configure is supposed to check both the new and the old header, but
> unfortunately stops checking after the check for the new header location 
> failed
> (due to the upstream bug i mentioned).

Mh. Then either fix that or bump the B-D version ;-)

So I did in fact spot a problem with it. Well, it’s no longer a
problem for me, as I mentioned that I just built the other package
first, but glad to be useful ;-)

bye,
//mirabilos
-- 
16:47⎜«mika:#grml» .oO(mira ist einfach gut)  23:22⎜«mikap:#grml»
mirabilos: und dein bootloader ist geil :)23:29⎜«mikap:#grml» und ich
finds saugeil dass ich ein bsd zum booten mit grml hab, das muss ich dann
gleich mal auf usb-stick installieren   -- Michael Prokop über MirOS bsd4grml

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: pd-zexy: broken Build-Depends

[IOhannes zmölnig]

On 01/17/2013 01:43 PM, Felipe Sateler wrote:

At some point (the changelog doesn't say) before squeeze the header
was moved from /u/include/m_pd.h to /u/i/pd/m_pd.h, which is where


for the record: the old header location is still available (symlinked)


modern packages expect it, which is why your build is failing.


configure is supposed to check both the new and the old header, but 
unfortunately stops checking after the check for the new header location 
failed (due to the upstream bug i mentioned).


gsdmrt
IOhannes

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: pd-zexy: broken Build-Depends

[IOhannes zmölnig]

On 01/17/2013 07:33 PM, Thorsten Glaser wrote:

Felipe Sateler dixit:


(CCing you because I don't know if you are suscribed)


I’m not, thanks.


Well, your puredata is from before stable... With the current build
depends pd-zexy can be built in stable.


as a matter of fact, i'm not entirely sure about this.


sdft
IOhannes

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: pd-zexy: broken Build-Depends

[IOhannes zmölnig]

On 01/17/2013 10:28 AM, Thorsten Glaser wrote:

Hi,

pd-zexy has alternative Build-Depends, however, they don’t work:

[…]
  pbuilder-satisfydepends-dummy : Depends: puredata-core which is a virtual 
package. or
   puredata (<  0.43) but it is not 
going to be installed.


hmm, any idea why "puredata-core" is named a "virtual package"?
it is as real as a package can get.


The following actions will resolve these dependencies:

   Install the following packages:
[…]
8)  puredata [0.41.4-1 (unstable)]
[…]
checking pd/m_pd.h usability... no
checking pd/m_pd.h presence... no
checking for pd/m_pd.h... no
configure: error: m_pd.h is desperately needed!
 install pd and/or use
 "--with-pd="
make: *** [debian/stamp-autotools] Error 1
dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2


ouch; you discovered an upstream bug.
i'll forward it, and could provide a patch that fixes the problem.


I think dropping the alternative on puredata is way to go.
I’ll just build its newer version, but due to the existence
of the alternative B-D, wanna-build considers pd-zexy to be
eligible for building.


ah btw, the B-D in question is really
 "puredata-dev | puredata (<< 0.43)"
rather than
 "puredata-core | puredata (<< 0.43)"
the latter is merely for runningthe test-suite.

gfmdsr
IOhannes

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: pd-zexy: broken Build-Depends

[Felipe Sateler]

On Thu, Jan 17, 2013 at 3:33 PM, Thorsten Glaser  wrote:
>
> Felipe Sateler dixit:
>
> >Well, your puredata is from before stable... With the current build
> >depends pd-zexy can be built in stable.
>
> Hmh. Strictly speaking, you need to version the B-D then.

It depends. We do not support skipping releases, so pre-stable depends
are not really needed.

>
> >I'm not sure complicating the build-depends line for oldstable is worthwile.
>
> By policy, you’d normally have to, but since this is an
> easily solved one-time issue, I refrain from calling it ;)
> But maybe in the future, keep things like this in mind,
> or something.

We do, that's why there is the puredata alternative (for squeeze
backports). What we don't go out of our way to do is to maintain
relationships that span all the way to oldstable.

>
> >I think you should just remove the current version of puredata from
> >m68k in the meanwhile (all rbuilddeps are likely to fail).
>
> Actually, I just built puredata, and in the meanwhile,
> pd-zexy also built. I just wanted to inform you of it.
>
> So, nothing that “must” be done any more, from my PoV,
> just an informative posting.

Good to hear m68k is making progress!

--

Saludos,
Felipe Sateler

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: pd-zexy: broken Build-Depends

[Thorsten Glaser]

Felipe Sateler dixit:

>(CCing you because I don't know if you are suscribed)

I’m not, thanks.

>Well, your puredata is from before stable... With the current build
>depends pd-zexy can be built in stable.

Hmh. Strictly speaking, you need to version the B-D then.

>I'm not sure complicating the build-depends line for oldstable is worthwile.

By policy, you’d normally have to, but since this is an
easily solved one-time issue, I refrain from calling it ;)
But maybe in the future, keep things like this in mind,
or something.

>I think you should just remove the current version of puredata from
>m68k in the meanwhile (all rbuilddeps are likely to fail).

Actually, I just built puredata, and in the meanwhile,
pd-zexy also built. I just wanted to inform you of it.

So, nothing that “must” be done any more, from my PoV,
just an informative posting.

bye,
//mirabilos
-- 
„nein: BerliOS und Sourceforge sind Plattformen für Projekte, github ist
eine Plattform für Einzelkämpfer“
-- dieses Zitat ist ein Beweis dafür, daß auch ein blindes Huhn
   mal ein Korn findet, bzw. – in diesem Fall – Recht haben kann

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: pd-zexy: broken Build-Depends

[Felipe Sateler]

Hi Thorsten,

(CCing you because I don't know if you are suscribed)


On Thu, Jan 17, 2013 at 6:28 AM, Thorsten Glaser  wrote:
>
> Hi,
>
> pd-zexy has alternative Build-Depends, however, they don’t work:

For some values of work ;)

>
> […]
>  pbuilder-satisfydepends-dummy : Depends: puredata-core which is a virtual 
> package. or
>   puredata (< 0.43) but it is not 
> going to be installed.
> The following actions will resolve these dependencies:
>
>   Install the following packages:
> […]
> 8)  puredata [0.41.4-1 (unstable)]
> […]
> checking pd/m_pd.h usability... no
> checking pd/m_pd.h presence... no
> checking for pd/m_pd.h... no
> configure: error: m_pd.h is desperately needed!
> install pd and/or use
> "--with-pd="
> make: *** [debian/stamp-autotools] Error 1
> dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2
>
>
> I think dropping the alternative on puredata is way to go.
> I’ll just build its newer version, but due to the existence
> of the alternative B-D, wanna-build considers pd-zexy to be
> eligible for building.

Well, your puredata is from before stable... With the current build
depends pd-zexy can be built in stable.
At some point (the changelog doesn't say) before squeeze the header
was moved from /u/include/m_pd.h to /u/i/pd/m_pd.h, which is where
modern packages expect it, which is why your build is failing.

I'm not sure complicating the build-depends line for oldstable is worthwile.

I think you should just remove the current version of puredata from
m68k in the meanwhile (all rbuilddeps are likely to fail).


--

Saludos,
Felipe Sateler

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: RFS pd-zexy (was Re: pd-zexy review)

[IOhannes m zmoelnig]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-10-10 21:02, Roman Haefeli wrote:
> On Mon, 2011-10-10 at 17:43 +0200, IOhannes m zmoelnig wrote:
> 
>>
>> to my knowledge i have fixed all the remaining issues of the "pd-zexy"
>> package.
>>
> 
> The packages includes a lintian override statement:
> 
> 
> # the upstream library format includes the license file in it, this library
> # has a unique license that is just a statement of public domain, so we just
> # leave the file in place, since there is no license file to symlink to.
> pd-zexy: extra-license-file usr/lib/pd/extra/zexy/LICENSE.txt
> 
> 
> But the file usr/lib/pd/extra/zexy/LICENSE.txt seems to be (almost[1]) 
> identical to GPL-2 from /usr/share/common-licenses
> 
> Either the included LICENSE.txt was meant to contain a different text or
> the license actually is meant to be GPL-2 and thus should be symlinked
> to /usr/share/common-licenses/GPL-2.

thanks for spotting that.
i retract the RFS (for now i changed the  target back suite to
UNRELEASED) until this is fixed.

fgmasd
IOhannes
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6UM68ACgkQkX2Xpv6ydvQOVACcCa/31EkbWCUBHMKv+yQPpk0Z
eqkAnRgJE4g3H8CCtibpTz4edjHjKhMT
=uqd1
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: RFS pd-zexy (was Re: pd-zexy review)

[IOhannes m zmoelnig]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-10-10 20:30, Roman Haefeli wrote:
> On Mon, 2011-10-10 at 17:43 +0200, IOhannes m zmoelnig wrote:
> 
>> to my knowledge i have fixed all the remaining issues of the "pd-zexy"
>> package.
> 
> Shouldn't pd-zexy depend only on puredata-core instead of puredata? Or
> is there a particular reason that it wants full puredata?

thanks for spotting.
fixed.

i should adhere to the rules that i suggest :-)

fgmasdr
IOhannes
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6UMTUACgkQkX2Xpv6ydvTnKQCgtaOrFYs7DHlBp4bWRQGd8xwN
hkIAnin5o11AnApylmqRwmtOc80UIk4Y
=/vWq
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: RFS pd-zexy (was Re: pd-zexy review)

[Roman Haefeli]

On Mon, 2011-10-10 at 17:43 +0200, IOhannes m zmoelnig wrote:

> 
> to my knowledge i have fixed all the remaining issues of the "pd-zexy"
> package.
> 

The packages includes a lintian override statement:


# the upstream library format includes the license file in it, this library
# has a unique license that is just a statement of public domain, so we just
# leave the file in place, since there is no license file to symlink to.
pd-zexy: extra-license-file usr/lib/pd/extra/zexy/LICENSE.txt


But the file usr/lib/pd/extra/zexy/LICENSE.txt seems to be (almost[1]) 
identical to GPL-2 from /usr/share/common-licenses

Either the included LICENSE.txt was meant to contain a different text or
the license actually is meant to be GPL-2 and thus should be symlinked
to /usr/share/common-licenses/GPL-2.

Roman


[1] It contains everything until the "END OF TERMS AND CONDITIONS"


___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: RFS pd-zexy (was Re: pd-zexy review)

[Roman Haefeli]

On Mon, 2011-10-10 at 17:43 +0200, IOhannes m zmoelnig wrote:

> to my knowledge i have fixed all the remaining issues of the "pd-zexy"
> package.

Shouldn't pd-zexy depend only on puredata-core instead of puredata? Or
is there a particular reason that it wants full puredata?

Roman


___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

RFS pd-zexy (was Re: pd-zexy review)

[IOhannes m zmoelnig]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

to my knowledge i have fixed all the remaining issues of the "pd-zexy"
package.

given that the new upload would fix an RC-critical bug, i would very
much appreciate it, if some DD could upload this package for me.

fgmasdr
IOhannes
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6TErUACgkQkX2Xpv6ydvQWkQCgw2E/AMkcvolJ/8pjriYRaSgx
9mAAoLl5divUiVLlnrinHNS7LaOVITYr
=e6Im
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: pd-zexy compilation improvements

[Felipe Sateler]

On 29/08/10 17:50, Hans-Christoph Steiner wrote:
> On Sun, 2010-08-29 at 21:35 +0200, Roman Haefeli wrote:
>> On Sun, 2010-08-29 at 14:44 -0400, Hans-Christoph Steiner wrote:
>>

 Also it seems as if dh_shlibdeps looks only for .so-files. I haven't
 figured out what trickery was used in the gem package to let it find
 also .pd_linux-files. But having a plain .pd-linux file in the temporary
 directory and running dh_shlibdeps doesn't produce anything useful.
>>>
>>> You can also check out debian/rules in pd-motex and pd-pmpd.  It passes
>>> the names of the .pd_linux files to dh_shlibdeps.
>>
>>
>> Actually, you're not passing the file names to dh_shlibdeps, but
>> directly to dpkg-shlibdeps. 
>> According to 4.4.3 of Debian's new maintainer's guide [1] the
>> recommended way would be to pass customized arguments to the debhelper
>> tools after " -- ", so that they get passed to the respective dpkg tools
>> (or whatever the dh_tool is a wrapper for).
>>  
>> However, this does not seem to work here for some reason.
>>
>> $ dpkg-shlibdeps /.pd_linux 
>>
>> actually creates a reasonable debian/substvars file.
>>
>> $ dh_shlibdeps -- /.pd_linux
>>
>> which is supposed to do exactly the same (according to the
>> documentation) does not seem to find a file to check for libraries. 
>>
>> So, I guess "dh_shlibdeps -- " is not passing _all_ arguments to
>> dpkg-shlibdeps? My perl skills are too limited to investigate the reason
>> for this behaviour myself. 
>>
>> Since the recommended way is not working, I guess it is OK to call
>> dpkg-shlibdeps directly in the pd-packages (as you, Hans, did in
>> pd-motex and pd-pmpd)? Or what do you (all) think?\
> 
> That sounds very familiar.  I think I tried dh_shlibdeps first also, and
> then went with dpkg-shlibdeps for that reason.
> 

Ah, yes, there is bug #35733 about it. I've pinged the bug report.

-- 
Saludos,
Felipe Sateler

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Re: pd-zexy compilation improvements

[Hans-Christoph Steiner]

On Sun, 2010-08-29 at 21:35 +0200, Roman Haefeli wrote:
> On Sun, 2010-08-29 at 14:44 -0400, Hans-Christoph Steiner wrote:
> 
> > > 
> > > Also it seems as if dh_shlibdeps looks only for .so-files. I haven't
> > > figured out what trickery was used in the gem package to let it find
> > > also .pd_linux-files. But having a plain .pd-linux file in the temporary
> > > directory and running dh_shlibdeps doesn't produce anything useful.
> > 
> > You can also check out debian/rules in pd-motex and pd-pmpd.  It passes
> > the names of the .pd_linux files to dh_shlibdeps.
> 
> 
> Actually, you're not passing the file names to dh_shlibdeps, but
> directly to dpkg-shlibdeps. 
> According to 4.4.3 of Debian's new maintainer's guide [1] the
> recommended way would be to pass customized arguments to the debhelper
> tools after " -- ", so that they get passed to the respective dpkg tools
> (or whatever the dh_tool is a wrapper for).
>  
> However, this does not seem to work here for some reason.
> 
> $ dpkg-shlibdeps /.pd_linux 
> 
> actually creates a reasonable debian/substvars file.
> 
> $ dh_shlibdeps -- /.pd_linux
> 
> which is supposed to do exactly the same (according to the
> documentation) does not seem to find a file to check for libraries. 
> 
> So, I guess "dh_shlibdeps -- " is not passing _all_ arguments to
> dpkg-shlibdeps? My perl skills are too limited to investigate the reason
> for this behaviour myself. 
> 
> Since the recommended way is not working, I guess it is OK to call
> dpkg-shlibdeps directly in the pd-packages (as you, Hans, did in
> pd-motex and pd-pmpd)? Or what do you (all) think?\

That sounds very familiar.  I think I tried dh_shlibdeps first also, and
then went with dpkg-shlibdeps for that reason.

.hc



___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Re: pd-zexy compilation improvements

[Roman Haefeli]

On Sun, 2010-08-29 at 14:44 -0400, Hans-Christoph Steiner wrote:

> > 
> > Also it seems as if dh_shlibdeps looks only for .so-files. I haven't
> > figured out what trickery was used in the gem package to let it find
> > also .pd_linux-files. But having a plain .pd-linux file in the temporary
> > directory and running dh_shlibdeps doesn't produce anything useful.
> 
> You can also check out debian/rules in pd-motex and pd-pmpd.  It passes
> the names of the .pd_linux files to dh_shlibdeps.


Actually, you're not passing the file names to dh_shlibdeps, but
directly to dpkg-shlibdeps. 
According to 4.4.3 of Debian's new maintainer's guide [1] the
recommended way would be to pass customized arguments to the debhelper
tools after " -- ", so that they get passed to the respective dpkg tools
(or whatever the dh_tool is a wrapper for).
 
However, this does not seem to work here for some reason.

$ dpkg-shlibdeps /.pd_linux 

actually creates a reasonable debian/substvars file.

$ dh_shlibdeps -- /.pd_linux

which is supposed to do exactly the same (according to the
documentation) does not seem to find a file to check for libraries. 

So, I guess "dh_shlibdeps -- " is not passing _all_ arguments to
dpkg-shlibdeps? My perl skills are too limited to investigate the reason
for this behaviour myself. 

Since the recommended way is not working, I guess it is OK to call
dpkg-shlibdeps directly in the pd-packages (as you, Hans, did in
pd-motex and pd-pmpd)? Or what do you (all) think?

Roman



[1] http://www.debian.org/doc/maint-guide/ch-dreq.en.html#s-customrules


___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Re: pd-zexy compilation improvements

[Hans-Christoph Steiner]

On Sat, 2010-08-28 at 00:18 +0200, Roman Haefeli wrote:
> On Fri, 2010-08-27 at 12:11 +0200, IOhannes zmölnig wrote:
> > On 08/24/2010 12:55 PM, Jonas Smedegaard wrote:
> > > On Mon, Aug 23, 2010 at 09:25:12AM +0200, IOhannes m zmoelnig wrote:
> > 
> > > Hmm. Do we then perhaps need to beware of this for helper tools like
> > > lintian and dh_shlibdeps?
> > > 
> 
> > the other point is of course, whether tools like dh_shlibdeps and
> > dh_strip work correctly.
> > i can only say from experience, that they do.
> > e.g. the binary Gem.pd_linux in the package "gem" is correctly stripped
> > and the package depends on all packages that provide libraries the
> > binary has been dynamically linked to.
> > debian/rules does not extra care of shlibs.
> > so it seems to "just work"
> 
> It seems it's not dh_strip who does the stripping. In the case of the
> gem package it seems to happen already at compile time. After putting an
> unstripped Gem.pd_linux in the temporary directory running dh_strip
> won't touch it all. 
> 
> Also it seems as if dh_shlibdeps looks only for .so-files. I haven't
> figured out what trickery was used in the gem package to let it find
> also .pd_linux-files. But having a plain .pd-linux file in the temporary
> directory and running dh_shlibdeps doesn't produce anything useful.

You can also check out debian/rules in pd-motex and pd-pmpd.  It passes
the names of the .pd_linux files to dh_shlibdeps.

.hc


___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Re: pd-zexy compilation improvements

[Roman Haefeli]

On Fri, 2010-08-27 at 19:24 -0400, Felipe Sateler wrote:
> On 27/08/10 18:18, Roman Haefeli wrote:
> > On Fri, 2010-08-27 at 12:11 +0200, IOhannes zmölnig wrote:
> >> On 08/24/2010 12:55 PM, Jonas Smedegaard wrote:
> >>> On Mon, Aug 23, 2010 at 09:25:12AM +0200, IOhannes m zmoelnig wrote:
> >>
> >>> Hmm. Do we then perhaps need to beware of this for helper tools like
> >>> lintian and dh_shlibdeps?
> >>>
> > 
> >> the other point is of course, whether tools like dh_shlibdeps and
> >> dh_strip work correctly.
> >> i can only say from experience, that they do.
> >> e.g. the binary Gem.pd_linux in the package "gem" is correctly stripped
> >> and the package depends on all packages that provide libraries the
> >> binary has been dynamically linked to.
> >> debian/rules does not extra care of shlibs.
> >> so it seems to "just work"
> > 
> > It seems it's not dh_strip who does the stripping. In the case of the
> > gem package it seems to happen already at compile time. After putting an
> > unstripped Gem.pd_linux in the temporary directory running dh_strip
> > won't touch it all. 
> 
> dh_strip doesn't strip anything it doesn't recognize (and it has no way
> of being forced into it). Add comments to bug #468333 to ask for support
> for this.

Thanks for confirming.

> In the meantime, you can call
> 
> strip --remove-section=.comment --remove-section=.note --strip-unneeded
>
> on each of the pd_linux files.

Ok.

> > Also it seems as if dh_shlibdeps looks only for .so-files. I haven't
> > figured out what trickery was used in the gem package to let it find
> > also .pd_linux-files. But having a plain .pd-linux file in the temporary
> > directory and running dh_shlibdeps doesn't produce anything useful.
> 
> You can pass additional arguments for dh_shlibdeps to process:
> 
> dh_shlibdeps -- $file1 $file2

Ah, so easy. Thanks for the hint.

Roman


___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Re: pd-zexy compilation improvements

[Felipe Sateler]

On 27/08/10 18:18, Roman Haefeli wrote:
> On Fri, 2010-08-27 at 12:11 +0200, IOhannes zmölnig wrote:
>> On 08/24/2010 12:55 PM, Jonas Smedegaard wrote:
>>> On Mon, Aug 23, 2010 at 09:25:12AM +0200, IOhannes m zmoelnig wrote:
>>
>>> Hmm. Do we then perhaps need to beware of this for helper tools like
>>> lintian and dh_shlibdeps?
>>>
> 
>> the other point is of course, whether tools like dh_shlibdeps and
>> dh_strip work correctly.
>> i can only say from experience, that they do.
>> e.g. the binary Gem.pd_linux in the package "gem" is correctly stripped
>> and the package depends on all packages that provide libraries the
>> binary has been dynamically linked to.
>> debian/rules does not extra care of shlibs.
>> so it seems to "just work"
> 
> It seems it's not dh_strip who does the stripping. In the case of the
> gem package it seems to happen already at compile time. After putting an
> unstripped Gem.pd_linux in the temporary directory running dh_strip
> won't touch it all. 

dh_strip doesn't strip anything it doesn't recognize (and it has no way
of being forced into it). Add comments to bug #468333 to ask for support
for this.

In the meantime, you can call

strip --remove-section=.comment --remove-section=.note --strip-unneeded

on each of the pd_linux files.

> 
> Also it seems as if dh_shlibdeps looks only for .so-files. I haven't
> figured out what trickery was used in the gem package to let it find
> also .pd_linux-files. But having a plain .pd-linux file in the temporary
> directory and running dh_shlibdeps doesn't produce anything useful.

You can pass additional arguments for dh_shlibdeps to process:

dh_shlibdeps -- $file1 $file2

-- 
Saludos,
Felipe Sateler

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Re: pd-zexy compilation improvements

[Jonas Smedegaard]

On Fri, Aug 27, 2010 at 12:11:16PM +0200, IOhannes zmölnig wrote:

On 08/24/2010 12:55 PM, Jonas Smedegaard wrote:

On Mon, Aug 23, 2010 at 09:25:12AM +0200, IOhannes m zmoelnig wrote:


Hmm. Do we then perhaps need to beware of this for helper tools like 
lintian and dh_shlibdeps?


I actually do not think that dh_shlibdeps has any role here, just 
mentioning it as an example: For Debian packaging we have a bunch of 
helper tools used either directly during packaging or during various 
tests and inspections, which rely on e.g. shared libraries ending in 
.so and located below /usr/lib.  When then unusual things are done, 
we might want to add hints for such tools to not hide potential 
problems from them.


Or expressed differently: Even if PureData works splendid with its 
unusual naming, we still might benefit in Debian (and derivatives) 
from using the classic .so extension if indeed it is technically the 
same.



i think there is no issue here at all.
we are talking about "modules" (binaries that can be dlopen()ed).

dlopen()ed modules are technically quite the same as shlibs (meaning, 
the way they are built), but are used in a different way, that makes 
issues such as installation path and/or rpath irrelevant (at least, as 
far as i understand it)


so from this perspective, we don't have to care about the extension.
(i guess this came from my confusing use of "shared library"; sorry for
that; anyhow, debian-policy is quite clear that "modules" need not have
an .so extension)

the other point is of course, whether tools like dh_shlibdeps and
dh_strip work correctly.
i can only say from experience, that they do.
e.g. the binary Gem.pd_linux in the package "gem" is correctly stripped
and the package depends on all packages that provide libraries the
binary has been dynamically linked to.
debian/rules does not extra care of shlibs.
so it seems to "just work"

i think that changing the default extension of pd-plugins only in
Debian, will make things unnecessary complicated, as it would require to
patch the module-loader of puredata as well as practically every single
build system for externals, only to find ourselves deviant from and
incompatible with virtually any other puredata distribution.

to sum up, i don't think the gain would outweigh the cost.
(esp. since there is currently no real gain, as  adhere to the
debian-policy and all tools work as expected)



Thanks for the long explanation.  I am thrilled to be around such 
knowledgeable folks here!



 - Jonas

--
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Re: pd-zexy compilation improvements

[Roman Haefeli]

On Fri, 2010-08-27 at 12:11 +0200, IOhannes zmölnig wrote:
> On 08/24/2010 12:55 PM, Jonas Smedegaard wrote:
> > On Mon, Aug 23, 2010 at 09:25:12AM +0200, IOhannes m zmoelnig wrote:
> 
> > Hmm. Do we then perhaps need to beware of this for helper tools like
> > lintian and dh_shlibdeps?
> > 

> the other point is of course, whether tools like dh_shlibdeps and
> dh_strip work correctly.
> i can only say from experience, that they do.
> e.g. the binary Gem.pd_linux in the package "gem" is correctly stripped
> and the package depends on all packages that provide libraries the
> binary has been dynamically linked to.
> debian/rules does not extra care of shlibs.
> so it seems to "just work"

It seems it's not dh_strip who does the stripping. In the case of the
gem package it seems to happen already at compile time. After putting an
unstripped Gem.pd_linux in the temporary directory running dh_strip
won't touch it all. 

Also it seems as if dh_shlibdeps looks only for .so-files. I haven't
figured out what trickery was used in the gem package to let it find
also .pd_linux-files. But having a plain .pd-linux file in the temporary
directory and running dh_shlibdeps doesn't produce anything useful.

Roman


___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Re: pd-zexy compilation improvements

[IOhannes zmölnig]

On 08/24/2010 12:55 PM, Jonas Smedegaard wrote:
> On Mon, Aug 23, 2010 at 09:25:12AM +0200, IOhannes m zmoelnig wrote:

> Hmm. Do we then perhaps need to beware of this for helper tools like
> lintian and dh_shlibdeps?
> 
> I actually do not think that dh_shlibdeps has any role here, just
> mentioning it as an example: For Debian packaging we have a bunch of
> helper tools used either directly during packaging or during various
> tests and inspections, which rely on e.g. shared libraries ending in .so
> and located below /usr/lib.  When then unusual things are done, we might
> want to add hints for such tools to not hide potential problems from them.
> 
> Or expressed differently: Even if PureData works splendid with its
> unusual naming, we still might benefit in Debian (and derivatives) from
> using the classic .so extension if indeed it is technically the same.


i think there is no issue here at all.
we are talking about "modules" (binaries that can be dlopen()ed).

dlopen()ed modules are technically quite the same as shlibs (meaning,
the way they are built), but are used in a different way, that makes
issues such as installation path and/or rpath irrelevant (at least, as
far as i understand it)

so from this perspective, we don't have to care about the extension.
(i guess this came from my confusing use of "shared library"; sorry for
that; anyhow, debian-policy is quite clear that "modules" need not have
an .so extension)

the other point is of course, whether tools like dh_shlibdeps and
dh_strip work correctly.
i can only say from experience, that they do.
e.g. the binary Gem.pd_linux in the package "gem" is correctly stripped
and the package depends on all packages that provide libraries the
binary has been dynamically linked to.
debian/rules does not extra care of shlibs.
so it seems to "just work"

i think that changing the default extension of pd-plugins only in
Debian, will make things unnecessary complicated, as it would require to
patch the module-loader of puredata as well as practically every single
build system for externals, only to find ourselves deviant from and
incompatible with virtually any other puredata distribution.

to sum up, i don't think the gain would outweigh the cost.
(esp. since there is currently no real gain, as  adhere to the
debian-policy and all tools work as expected)

fmgdft
IOhannes



signature.asc
Description: OpenPGP digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Re: pd-zexy compilation improvements

[Jonas Smedegaard]

On Mon, Aug 23, 2010 at 09:25:12AM +0200, IOhannes m zmoelnig wrote:

On 2010-08-22 20:06, Jonas Smedegaard wrote:


Indeed this looks weird.  If you consider it sane to use this 
approach then I guess it won't matter much.  But striving towards the 
ultimate, if this is a dirty hack then please elaborate on possible 
alternative approaches - even if tricky to achieve: others here might 
have ideas on how to reach a higher level of elegantry (or however 
that word is bent).




it's certainly in sync with the current puredata package in debian; the 
relevant patches (using the pd_linux extension for debian/hurd and 
debian/kFreeBSD) have even made it into upstream of puredata


other pkgs usually use ".so" as extension, which Pd for historical 
reasons does not, and instead uses it's own extension (varying across 
platforms).


Hmm. Do we then perhaps need to beware of this for helper tools like 
lintian and dh_shlibdeps?


I actually do not think that dh_shlibdeps has any role here, just 
mentioning it as an example: For Debian packaging we have a bunch of 
helper tools used either directly during packaging or during various 
tests and inspections, which rely on e.g. shared libraries ending in .so 
and located below /usr/lib.  When then unusual things are done, we might 
want to add hints for such tools to not hide potential problems from 
them.


Or expressed differently: Even if PureData works splendid with its 
unusual naming, we still might benefit in Debian (and derivatives) from 
using the classic .so extension if indeed it is technically the same.



One example issue we could be hiding is that of rpath usage: Everything 
works fine but Debian set higher standards than "works fine for *normal* 
use" and lintian checks was added at some point to warn if rpath was 
used in shared libraries.


Again, I do not say that rpath in particular is my concern - it is but 
an example: Could be some other similarly "pedantic" issue raised later, 
which none of us today know about, but will remain hidden if we use odd 
naming for a common file type.



Also, some archs have problems with fPIC, and I believe it is 
mentioned in Debian Policy that normal builds should *not* use fPIC 
while static libraries (unused here, just mentioning for 
completenes sake) *should* use it.




the fPIC flag is tested for during configure time, and it's only used
if the compiler supports it.
it was introduced, because x86_64 does require it.
it can be turned off by using "--disable-PIC", though of course this
has to exclude x86_64


Do others have more knowledge about this than me?


this sounds a bit ironic, but i miss the smiley, so i guess it's not.


It is not: I know Make, Perl, Bash, love regular expressions, and can 
juggle patches. But cannot do a helloworld in C or C++.


It takes more than a smiley to change that :-)



NB! Please do not cc me - I am subscribed, and it messes up my MUA.


 - Jonas

--
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Re: pd-zexy compilation improvements

[Jonas Smedegaard]

On Mon, Aug 23, 2010 at 10:32:55AM +0200, IOhannes m zmoelnig wrote:

On 2010-08-23 09:58, Reinhard Tartler wrote:

If they are indeed in non-standard paths such that the dynamic linker 
doesn't see it without setting LD_LIBRARY_PATH or similar, then 
you're right. But..



nevertheless, it complies with it...


even on amd64? There are some architectures that are pretty picky 
about position independent code.  BTW that's why there is this rule 
in debian policy in the first place.




pd-zexy compiles everything with "-fPIC" an ALL (including amd64)
platforms[1].
the discussion arose, because jonas wanted it to be compiled withOUT 
-fPIC (which is in contradiction to the debian policy afaict)


do i get something wrong?


No - I had it upside down.  Lucky you are upstream, not me, as it seems 
you actually know what you are talking about ;-)



 - Jonas

--
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Re: pd-zexy compilation improvements

[Reinhard Tartler]

On Mon, Aug 23, 2010 at 10:32:55 (CEST), IOhannes m zmoelnig wrote:

> On 2010-08-23 09:58, Reinhard Tartler wrote:
>
>> If they are indeed in non-standard paths such that the dynamic linker
>> doesn't see it without setting LD_LIBRARY_PATH or similar, then you're
>> right. But..
>> 
>>> nevertheless, it complies with it...
>> 
>> even on amd64? There are some architectures that are pretty picky about
>> position independent code.  BTW that's why there is this rule in debian
>> policy in the first place.
>> 
>
> pd-zexy compiles everything with "-fPIC" an ALL (including amd64)
> platforms[1].
> the discussion arose, because jonas wanted it to be compiled withOUT
> -fPIC (which is in contradiction to the debian policy afaict)
>
> do i get something wrong?

no, it was me who got it wrong. Leaving out -fPIC is not a clever idea
without really understanding what's going on.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Re: pd-zexy compilation improvements

[IOhannes m zmoelnig]

On 2010-08-23 09:58, Reinhard Tartler wrote:

> If they are indeed in non-standard paths such that the dynamic linker
> doesn't see it without setting LD_LIBRARY_PATH or similar, then you're
> right. But..
> 
>> nevertheless, it complies with it...
> 
> even on amd64? There are some architectures that are pretty picky about
> position independent code.  BTW that's why there is this rule in debian
> policy in the first place.
> 

pd-zexy compiles everything with "-fPIC" an ALL (including amd64)
platforms[1].
the discussion arose, because jonas wanted it to be compiled withOUT
-fPIC (which is in contradiction to the debian policy afaict)

do i get something wrong?


fgmasdr
IOhannes




[1] where the compiler accepts the -fPIC flag.



smime.p7s
Description: S/MIME Cryptographic Signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Re: pd-zexy compilation improvements

[Reinhard Tartler]

On Mon, Aug 23, 2010 at 09:35:24 (CEST), IOhannes m zmoelnig wrote:

> On 2010-08-22 20:06, Jonas Smedegaard wrote:
>> 
>> We should simply suppress the sse flag on 32bit x86, in my opinion.
>> 
>> Or if it really hurts, we should either a) offer to variants or b)
>> convince upstream to implement support for both and detect at runtime if
>> optimized code whould be used or not.
>> 
>> I notice that upstream intend to switch to autotools for next release. 
>> Perhaps you could convince upstream to add an option to add e.g. a
>> --no-optimize or --no-buildtime-featuredetect flag so we can ensure
>> compatibility generally for the archs we target - or if not too much to
>> ask then above described runtime detection?
>
>
> i thought it was there, but cannot find it anymore :-) (probably it's in
> some other lib of mine)
>
> as things stand now, pd-zexy has no runtime cpu-detection support, so
> the best bet is to completely disable the SSE2 code.

For now, I agree that would be best. There are some workarounds for
that, though.

> for future refernce i would like to ask (and i'm aware, that this is not
> the perfect place to ask such a question):
>
> the relevant flags are "-mfpmath=sse -msse" which do 2 things:
> - set some macros to allow the user add handcrafted sse-code
> - use sse optimization
>
> now #1 is clearly a problem, if the program is forced to use handwritten
> sse code (including sse instructions) if there is no sse unit available.
> this can be fixed with runtime checks.
>
> my question is more about the other possibility:
> #2 makes gcc emit sse-instructions; does anybody know whether it also
> automatically provides fallbacks for generic 486 instructions?
> or is any code compiled with "-mfpmath=sse -msse" known (or likely) to
> be incompatible with non-sse cpus?

No, gcc doesn't support this (yet [1]).

But *if* all code that is using SSE is implemented as shared libraries
(i.e., .so files and loaded via ld-linux.so, I didn't check that though)
then you could compile and install different flavors of the library, one
time with and one time without SSE instructions. The dynamic loader will
then at runtime query the kernel for installed harware capabilities and
load the "best" flavor on demand. See the libavcodec52 package as an
example.


[1] You might want to google on 'gcc binutils multiarch' for details; it
is a rather new development with an unfortunate naming, since it clashes
with debian's "multiarch" project which is related but with different
aims.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Re: pd-zexy compilation improvements

[Reinhard Tartler]

On Mon, Aug 23, 2010 at 09:38:42 (CEST), IOhannes m zmoelnig wrote:

> On 2010-08-23 09:25, IOhannes m zmoelnig wrote:
>> On 2010-08-22 20:06, Jonas Smedegaard wrote:
>> 
>> anyhow, i had a look at the debian policy, and it says (in chapter 10.2
>> Libraries on todays http://www.debian.org/doc/debian-policy/ch-files.html):
>> "If the package is architecture: any, then the shared library
>> compilation and linking flags must have -fPIC, or the package shall not
>> build on some of the supported architectures".
>
> reading on, i also noticed:
> "Shared object files (often .so files) that are not public libraries,
> that is, they are not meant to be linked to by third party executables
> (binaries of other packages), should be installed in subdirectories of
> the /usr/lib directory. Such files are exempt from the rules that govern
> ordinary shared libraries, except that they must not be installed
> executable and should be stripped [A common example are the so-called
> "plug-ins", internal shared objects that are dynamically loaded by
> programs using dlopen(3).]"
>
> i understand this as the "-fPIC" rule actually doesn't apply at all to
> Pd-externals.

If they are indeed in non-standard paths such that the dynamic linker
doesn't see it without setting LD_LIBRARY_PATH or similar, then you're
right. But..

> nevertheless, it complies with it...

even on amd64? There are some architectures that are pretty picky about
position independent code.  BTW that's why there is this rule in debian
policy in the first place.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Re: pd-zexy compilation improvements

[IOhannes m zmoelnig]

On 2010-08-23 09:25, IOhannes m zmoelnig wrote:
> On 2010-08-22 20:06, Jonas Smedegaard wrote:
> 
> anyhow, i had a look at the debian policy, and it says (in chapter 10.2
> Libraries on todays http://www.debian.org/doc/debian-policy/ch-files.html):
> "If the package is architecture: any, then the shared library
> compilation and linking flags must have -fPIC, or the package shall not
> build on some of the supported architectures".

reading on, i also noticed:
"Shared object files (often .so files) that are not public libraries,
that is, they are not meant to be linked to by third party executables
(binaries of other packages), should be installed in subdirectories of
the /usr/lib directory. Such files are exempt from the rules that govern
ordinary shared libraries, except that they must not be installed
executable and should be stripped [A common example are the so-called
"plug-ins", internal shared objects that are dynamically loaded by
programs using dlopen(3).]"

i understand this as the "-fPIC" rule actually doesn't apply at all to
Pd-externals.
nevertheless, it complies with it...

fbmasdr
IOhannes



smime.p7s
Description: S/MIME Cryptographic Signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Re: pd-zexy compilation improvements

[IOhannes m zmoelnig]

On 2010-08-22 20:06, Jonas Smedegaard wrote:
> 
> We should simply suppress the sse flag on 32bit x86, in my opinion.
> 
> Or if it really hurts, we should either a) offer to variants or b)
> convince upstream to implement support for both and detect at runtime if
> optimized code whould be used or not.
> 
> I notice that upstream intend to switch to autotools for next release. 
> Perhaps you could convince upstream to add an option to add e.g. a
> --no-optimize or --no-buildtime-featuredetect flag so we can ensure
> compatibility generally for the archs we target - or if not too much to
> ask then above described runtime detection?


i thought it was there, but cannot find it anymore :-) (probably it's in
some other lib of mine)

as things stand now, pd-zexy has no runtime cpu-detection support, so
the best bet is to completely disable the SSE2 code.

for future refernce i would like to ask (and i'm aware, that this is not
the perfect place to ask such a question):

the relevant flags are "-mfpmath=sse -msse" which do 2 things:
- set some macros to allow the user add handcrafted sse-code
- use sse optimization

now #1 is clearly a problem, if the program is forced to use handwritten
sse code (including sse instructions) if there is no sse unit available.
this can be fixed with runtime checks.

my question is more about the other possibility:
#2 makes gcc emit sse-instructions; does anybody know whether it also
automatically provides fallbacks for generic 486 instructions?
or is any code compiled with "-mfpmath=sse -msse" known (or likely) to
be incompatible with non-sse cpus?


fmasdr
IOhannes



smime.p7s
Description: S/MIME Cryptographic Signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Re: pd-zexy compilation improvements

[IOhannes m zmoelnig]

On 2010-08-22 20:06, Jonas Smedegaard wrote:
> 
> Indeed this looks weird.  If you consider it sane to use this approach
> then I guess it won't matter much.  But striving towards the ultimate,
> if this is a dirty hack then please elaborate on possible alternative
> approaches - even if tricky to achieve: others here might have ideas on
> how to reach a higher level of elegantry (or however that word is bent).
> 

it's certainly in sync with the current puredata package in debian; the
relevant patches (using the pd_linux extension for debian/hurd and
debian/kFreeBSD) have even made it into upstream of puredata

other pkgs usually use ".so" as extension, which Pd for historical
reasons does not, and instead uses it's own extension (varying across
platforms).

>> on other platforms (not x86 and x86_64) the flags should be no problems
>> (since they are not used)
> 
> This is bad! - i.e. I Am The Policy Police ;-)
>

somehow i expected this :-)

> We should not wait until someone gets hurt by pd-sexy not working on
> e.g. VIA boards *and* figure out the cause of the problem *and* file a
> bugreport about it.
> 
> We should simply suppress the sse flag on 32bit x86, in my opinion.

no problem.

> 
> I notice that upstream intend to switch to autotools for next release. 
> Perhaps you could convince upstream to add an option to add e.g. a
> --no-optimize or --no-buildtime-featuredetect flag so we can ensure
> compatibility generally for the archs we target - or if not too much to
> ask then above described runtime detection?

btw, upstream already uses a autoconf (with loads of m4 hacks...); the
intention is to switch to automake as well and get rid of the tweaks...

>>> Also, some archs have problems with fPIC, and I believe it is
>>> mentioned in Debian Policy that normal builds should *not* use fPIC
>>> while static libraries (unused here, just mentioning for completenes
>>> sake) *should* use it.
>>>
>>
>> the fPIC flag is tested for during configure time, and it's only used
>> if the compiler supports it.
>> it was introduced, because x86_64 does require it.
>> it can be turned off by using "--disable-PIC", though of course this
>> has to exclude x86_64
> 
> Do others have more knowledge about this than me?

this sounds a bit ironic, but i miss the smiley, so i guess it's not.

> 
> I suspect that it is not enough to simply test if -fPIC flag works -
> that it is more complicated than that, and more of a "Debian has decided
> to do it like this" rather than "this technically will certainly fail".
> 

i can only say that i know that all externals will fail to link on
x86_64 if the -fPIC flag is not present.

anyhow, i had a look at the debian policy, and it says (in chapter 10.2
Libraries on todays http://www.debian.org/doc/debian-policy/ch-files.html):
"If the package is architecture: any, then the shared library
compilation and linking flags must have -fPIC, or the package shall not
build on some of the supported architectures".

this seems to be exactly the opposite of what you suggest, as shared
libraries (and modules that are meant to be dlopen()ed _are_ shared
libraries) MUST have the "-fPIC" present.

i prefer if the build system tests, whether the compiler actually
accepts "-fPIC", just in case somebody uses an exotic compiler.


fmhsd
IOhannes












smime.p7s
Description: S/MIME Cryptographic Signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Re: pd-zexy compilation improvements

[Jonas Smedegaard]

Hi IOhannes,

On Fri, Aug 20, 2010 at 10:09:22PM +0200, IOhannes m zmölnig wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Please quote only relevant parts.  PGP signing hints are never relevant 
to quote.




On 08/20/2010 12:41 PM, Jonas Smedegaard wrote:
I finalized the packaging and uploaded to the NEW queue, where it is 
now waiting for ftpmasters to (hopefully) approve it.


cool.
i noticed that up till now, it has built everywhere but
- - linux/mips (scheduled)
- - hurd (scheduled)
- - kfreebsd (failed)


i expect the hurd build to fail as well, due to the same problem as the 
kfreebsd builds: the filename extension for the external (module) is 
not correctly autoguessed.


this can be easily fixed, by forcing a certain extension via configure 
flags (which i have just pushed).
the "puredata" package uses the "pd_linux" extension for all externals 
on Debian, so i just used that (even though it might seem uncorrect to 
use the "linux" extension on a hurd or freebsd kernel).


Indeed this looks weird.  If you consider it sane to use this approach 
then I guess it won't matter much.  But striving towards the ultimate, 
if this is a dirty hack then please elaborate on possible alternative 
approaches - even if tricky to achieve: others here might have ideas on 
how to reach a higher level of elegantry (or however that word is bent).




There are a few warnings like this:

  rawprint.c:45: warning: format '%X' expects type 'unsigned int', but
argument 4 has type 'struct t_gpointer *'


i never really understood what to use for pointers in fprintf.
anyhow, in the given function it is save to cast to uint, as it is only
for pretty printing...



This might cause problems on architectures where int is of "unusual"
size, if I understand it correctly.


i think the problem is more on x86_64 where the pointer is has the same
size as "long int"


Hmm - if only those warning affect some printf I guess it can't ever 
wreak havoc and we should simply ignore them.


If not then I hope others here with actual skills in coding C (not just 
looking at compiler warnings like I comprehend) will join this 
conversation :-)




Apparently the following compile options are used:

  -g -O2 -g -Wall -O2 -mms-bitfields -fPIC -mfpmath=sse -msse -g -O2 
-g -Wall -O2


This indicates that default compile options in upstream source is not 
overridden by CFLAGS declared by packaging which is generally bad 
(and a Policy violation, I believe - but too lazy to look it up right 
now), and especially may hurt emdebian and similar andvanced users 
depending on being able to override CFLAGS during packaging build 
time.


aye.
i think upstream will be switching to autoconf/automake which should fix
that.


Excellent (to me - I like autotools!).


More specifically, the upstream defaults include sse which I believe 
makes the resulting code require an i586 or even an i686 class 
machine. I did not look closer and this might simply be due to this 
compilation happening on amd64 which always has this instruction set.  
Just mentioning in case upstream assumes newer grades x64: Debian 
assumes i486.


aye.
the configure script does a test whether the compiler supports the 
sse-flags. i think this is the case with modern gcc on x86 regardless 
of the cpu used, so this might become a problem.


honestly, in the meantime i would wait till somebody complains (either 
a user or the policy police) or the policy changes...

the fix shouldn't be too complicated to do (needs a patch against
configure.ac however)

on other platforms (not x86 and x86_64) the flags should be no problems
(since they are not used)


This is bad! - i.e. I Am The Policy Police ;-)

We should not wait until someone gets hurt by pd-sexy not working on 
e.g. VIA boards *and* figure out the cause of the problem *and* file a 
bugreport about it.


We should simply suppress the sse flag on 32bit x86, in my opinion.

Or if it really hurts, we should either a) offer to variants or b) 
convince upstream to implement support for both and detect at runtime if 
optimized code whould be used or not.


I notice that upstream intend to switch to autotools for next release.  
Perhaps you could convince upstream to add an option to add e.g. a 
--no-optimize or --no-buildtime-featuredetect flag so we can ensure 
compatibility generally for the archs we target - or if not too much to 
ask then above described runtime detection?



Also, some archs have problems with fPIC, and I believe it is 
mentioned in Debian Policy that normal builds should *not* use fPIC 
while static libraries (unused here, just mentioning for completenes 
sake) *should* use it.




the fPIC flag is tested for during configure time, and it's only used 
if the compiler supports it.

it was introduced, because x86_64 does require it.
it can be turned off by using "--disable-PIC", though of course this 
has to exclude x86_64


Do others have more knowledge about this than me?

I suspect that it is not enough to

Re: pd-zexy (upstream copyright)

[IOhannes m zmölnig]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/20/2010 12:41 PM, Jonas Smedegaard wrote:
> I finalized the packaging and uploaded to the NEW queue, where it is now
> waiting for ftpmasters to (hopefully) approve it.

cool.
i noticed that up till now, it has built everywhere but
- - linux/mips (scheduled)
- - hurd (scheduled)
- - kfreebsd (failed)


i expect the hurd build to fail as well, due to the same problem as the
kfreebsd builds: the filename extension for the external (module) is not
correctly autoguessed.

this can be easily fixed, by forcing a certain extension via configure
flags (which i have just pushed).
the "puredata" package uses the "pd_linux" extension for all externals
on Debian, so i just used that (even though it might seem uncorrect to
use the "linux" extension on a hurd or freebsd kernel).


> 
> 
> There are a few warnings like this:
> 
>   rawprint.c:45: warning: format '%X' expects type 'unsigned int', but
> argument 4 has type 'struct t_gpointer *'

i never really understood what to use for pointers in fprintf.
anyhow, in the given function it is save to cast to uint, as it is only
for pretty printing...

> 
> This might cause problems on architectures where int is of "unusual"
> size, if I understand it correctly.

i think the problem is more on x86_64 where the pointer is has the same
size as "long int"

> 
> 
> Apparently the following compile options are used:
> 
>   -g -O2 -g -Wall -O2 -mms-bitfields -fPIC -mfpmath=sse -msse -g -O2 -g
> -Wall -O2
> 
> This indicates that default compile options in upstream source is not
> overridden by CFLAGS declared by packaging which is generally bad (and a
> Policy violation, I believe - but too lazy to look it up right now), and
> especially may hurt emdebian and similar andvanced users depending on
> being able to override CFLAGS during packaging build time.

aye.
i think upstream will be switching to autoconf/automake which should fix
that.

> 
> More specifically, the upstream defaults include sse which I believe
> makes the resulting code require an i586 or even an i686 class machine. 
> I did not look closer and this might simply be due to this compilation
> happening on amd64 which always has this instruction set.  Just
> mentioning in case upstream assumes newer grades x64: Debian assumes i486.

aye.
the configure script does a test whether the compiler supports the
sse-flags. i think this is the case with modern gcc on x86 regardless of
the cpu used, so this might become a problem.

honestly, in the meantime i would wait till somebody complains (either a
user or the policy police) or the policy changes...
the fix shouldn't be too complicated to do (needs a patch against
configure.ac however)

on other platforms (not x86 and x86_64) the flags should be no problems
(since they are not used)

> 
> Also, some archs have problems with fPIC, and I believe it is mentioned
> in Debian Policy that normal builds should *not* use fPIC while static
> libraries (unused here, just mentioning for completenes sake) *should*
> use it.
> 

the fPIC flag is tested for during configure time, and it's only used if
the compiler supports it.
it was introduced, because x86_64 does require it.
it can be turned off by using "--disable-PIC", though of course this has
to exclude x86_64



gmasdr
IOhannes
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxu4PEACgkQkX2Xpv6ydvTowwCeKY4fFuZQ9AabQbITCWQKd3/H
GjsAnilHytpPlrJAhj2c4yT0bT7ZSplp
=CtpI
-END PGP SIGNATURE-

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Re: pd-zexy (upstream copyright)

[Jonas Smedegaard]

On Thu, Aug 19, 2010 at 10:03:22PM +0200, IOhannes m zmoelnig wrote:

i manually fixed the FIXMEs and pushed.
so i guess we are almost there.


Indeed we are.

I finalized the packaging and uploaded to the NEW queue, where it is now 
waiting for ftpmasters to (hopefully) approve it.


I did spot a few details during compilations, though, whcih I'd like to 
discuss if they are relevant to improve for future releases:




There are a few warnings like this:

  rawprint.c:45: warning: format '%X' expects type 'unsigned int', but argument 
4 has type 'struct t_gpointer *'

This might cause problems on architectures where int is of "unusual" 
size, if I understand it correctly.



Apparently the following compile options are used:

  -g -O2 -g -Wall -O2 -mms-bitfields -fPIC -mfpmath=sse -msse -g -O2 -g -Wall 
-O2

This indicates that default compile options in upstream source is not 
overridden by CFLAGS declared by packaging which is generally bad (and a 
Policy violation, I believe - but too lazy to look it up right now), and 
especially may hurt emdebian and similar andvanced users depending on 
being able to override CFLAGS during packaging build time.


More specifically, the upstream defaults include sse which I believe 
makes the resulting code require an i586 or even an i686 class machine.  
I did not look closer and this might simply be due to this compilation 
happening on amd64 which always has this instruction set.  Just 
mentioning in case upstream assumes newer grades x64: Debian assumes 
i486.


Also, some archs have problems with fPIC, and I believe it is mentioned 
in Debian Policy that normal builds should *not* use fPIC while static 
libraries (unused here, just mentioning for completenes sake) *should* 
use it.



Regards,

- Jonas

--
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Re: pd-zexy (upstream copyright)

[IOhannes m zmoelnig]

On 2010-08-19 10:53, Jonas Smedegaard wrote:
> debian/copyright still needs to be maintained "by hand".  There is not
> yet any DEP5 validators or parsers, only the work-in-progress definition
> itself, at http://dep.debian.net/deps/dep5/ - so hava a go at reading
> that :-)

thanks for the clarification.

> 
> For the concrete FIXMEs I suggest we simply release the package as-is,
> and when next upstream release hopefully improves its copyright and
> licensing hints we may be able to sanely remove them.
> 

i manually fixed the FIXMEs and pushed.
so i guess we are almost there.

fgmasdr
IOhannes



smime.p7s
Description: S/MIME Cryptographic Signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Re: pd-zexy (upstream copyright)

[Jonas Smedegaard]

On Thu, Aug 19, 2010 at 10:29:12AM +0200, IOhannes m zmoelnig wrote:

On 2010-08-19 10:23, IOhannes m zmoelnig wrote:

On 2010-08-18 20:38, Jonas Smedegaard wrote:


After I stomped the topmost one about source URL (puredata.info was 
down earlier today, apparently), there are now 2 FIXMEs left.




ah i was so busy answering your questions, that i forgot to rephrase my 
original question (remember, i'm still trying to learn):

how are those FIXMEs to be fixed (apart from your questions).
i mean, can i just edit the debian/copyright file, or do i have to tell
cdbs somehow else how to FIX.
if i add the FIXMEs manually, how do i ensure that the format stays 
DEP5 compatible?


CDBS do not automagically maintain debian/copyright.  Instead it 
maintains a "shadow" file debian/copyright_hints.  At every build, 
source is scanned and a temporary debian/copyright_newhints generated 
and then diff'ed with debian/copyright_hints, and if the first contains 
additions compared to the latter, a warning is emitted (or the build 
fails, if DEB_MAINTAINER_MODE is enabled).


debian/copyright still needs to be maintained "by hand".  There is 
not yet any DEP5 validators or parsers, only the work-in-progress 
definition itself, at http://dep.debian.net/deps/dep5/ - so hava a go at 
reading that :-)



For the concrete FIXMEs I suggest we simply release the package as-is, 
and when next upstream release hopefully improves its copyright and 
licensing hints we may be able to sanely remove them.



 - Jonas

--
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Re: pd-zexy (upstream copyright)

[IOhannes m zmoelnig]

On 2010-08-19 10:23, IOhannes m zmoelnig wrote:
> On 2010-08-18 20:38, Jonas Smedegaard wrote:
>>
>> After I stomped the topmost one about source URL (puredata.info was down
>> earlier today, apparently), there are now 2 FIXMEs left.
>>

ah i was so busy answering your questions, that i forgot to rephrase my
original question (remember, i'm still trying to learn):
how are those FIXMEs to be fixed (apart from your questions).
i mean, can i just edit the debian/copyright file, or do i have to tell
cdbs somehow else how to FIX.
if i add the FIXMEs manually, how do i ensure that the format stays DEP5
compatible?

fgmadrt
IOhannes



smime.p7s
Description: S/MIME Cryptographic Signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Re: pd-zexy (upstream copyright)

[IOhannes m zmoelnig]

On 2010-08-18 20:38, Jonas Smedegaard wrote:
> 
> After I stomped the topmost one about source URL (puredata.info was down
> earlier today, apparently), there are now 2 FIXMEs left.
> 
> Upper one is obviously a typo, so not a show-stopper.  I would suggest
> you fix it upstream for your next release, though (if not claiming
> copyright in 22nd century is some artistic logo).

ah no, the date is the logo is somewhat inconsistent.
sometimes it reads YYY1:forum::für::umläute:YYY2 (if the copyright spans
YYY1-YYY2), and sometimes it reads DDMM:forum::für::umläute: (if the
file was done on a single day).
in the given case, i will change that to a year range, as it already
covers a time span :-)


> 
> Lower one I would appreciate if at least you could clarify - just here
> as an email on this mailinglist, so we have it for the record:
> 
> Under which license do Winfried Ritsch license his contributions to
> src/sfplay.c?
> 

GPL-2


fgamsdr
IOhannes



smime.p7s
Description: S/MIME Cryptographic Signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Re: pd-zexy (upstream copyright)

[Jonas Smedegaard]

On Wed, Aug 18, 2010 at 07:28:15PM +0200, IOhannes m zmoelnig wrote:

On 2010-08-18 14:27, Jonas Smedegaard wrote:

thanks for the hint.
i noticed that upstream's README.txt includes several more authors, 
which do not appear in any source file and definitely not (yet) in 
debian/changelog


Please have a look at the changes I pushed just now, especially the
FIXMEs in debian/copyright and the rephrasings in changelog.


aye.
debian/copyright looks good (apart from that it looks ugly, but i guess
this is the price for machine readability :-))


Yeah, that's a common first reaction to DEP5 format.  Often what is 
really the case, however, is that more info is added, which written 
old-style would have been even less readable.


Or perhaps I have simply grown used to this new format, having worked on 
it for don't know how long - a couple of years, I think.




does anything need to be done about the FIXMEs?


Yes.

After I stomped the topmost one about source URL (puredata.info was down 
earlier today, apparently), there are now 2 FIXMEs left.


Upper one is obviously a typo, so not a show-stopper.  I would suggest 
you fix it upstream for your next release, though (if not claiming 
copyright in 22nd century is some artistic logo).


Lower one I would appreciate if at least you could clarify - just here 
as an email on this mailinglist, so we have it for the record:


Under which license do Winfried Ritsch license his contributions to 
src/sfplay.c?




debian/changelog looks also very good.


Ahh, thanks.  I was worried you perhaps wouldn't appreciate it :-)


 - Jonas

--
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Re: pd-zexy (upstream copyright)

[IOhannes m zmoelnig]

On 2010-08-18 14:27, Jonas Smedegaard wrote:
>> thanks for the hint.
>> i noticed that upstream's README.txt includes several more authors,
>> which do not appear in any source file and definitely not (yet) in
>> debian/changelog
> 
> Please have a look at the changes I pushed just now, especially the
> FIXMEs in debian/copyright and the rephrasings in changelog.

aye.
debian/copyright looks good (apart from that it looks ugly, but i guess
this is the price for machine readability :-))
does anything need to be done about the FIXMEs?

debian/changelog looks also very good.

thanks for your efforts.

fgamsdr
IOhannes



smime.p7s
Description: S/MIME Cryptographic Signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Re: pd-zexy (upstream copyright)

[Jonas Smedegaard]

On Wed, Aug 18, 2010 at 11:57:18AM +0200, IOhannes m zmoelnig wrote:

On 2010-08-17 18:36, Jonas Smedegaard wrote:

It was just a suggestion (or, really, a recommendation), not a 
requirement (for you as upstream).


We (Debian) do need, however, to make sure that upstream copyright 
claims and licensing permissions are properly identified.


If the file headers do not (in our understanding of legal 
requirements for *redistributors* - not for *upstreams*) contain 
clear statements of both copyright and licensing, then we will need a 
written statement from those authors stating clearly the info we 
need.


This also, as I see it, implies that if e.g. a README file in the 
topmost directory of the upstream tarball claims that this project is 
Copyright authors A, B and C, but one file claims Copyright author D, 
then file takes presedence over README, and if then that file cannot 
be parsed reliably regarding *both* copyright and licensing, then 
that file is deemed unsatifiably licensed for redistribution.




thanks for the hint.
i noticed that upstream's README.txt includes several more authors,
which do not appear in any source file and definitely not (yet) in
debian/changelog


Please have a look at the changes I pushed just now, especially the 
FIXMEs in debian/copyright and the rephrasings in changelog.




You are free to not want to improve clarity of upstream copyright and 
licensing, but you risk some distributors then choosing not to want 
to redistribute your fine code.




just for the sake of completeness, i want to point out that pd-zexy has 
been distributed in Debian and derivatives for more than 5 years. the 
copyright did not seem to be such an issue until know.


this however can only mean that nobody had a look so close as you guys. 
upstream is happy about that close inspection and will incorporate 
changes based on the suggestion on this list in the next upstream 
release.


We seem to understand each other :-)


 - Jonas

--
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Re: pd-zexy (upstream copyright)

[IOhannes m zmoelnig]

On 2010-08-17 18:36, Jonas Smedegaard wrote:

> It was just a suggestion (or, really, a recommendation), not a
> requirement (for you as upstream).
> 
> We (Debian) do need, however, to make sure that upstream copyright
> claims and licensing permissions are properly identified.
> 
> If the file headers do not (in our understanding of legal requirements
> for *redistributors* - not for *upstreams*) contain clear statements of
> both copyright and licensing, then we will need a written statement from
> those authors stating clearly the info we need.
> 
> This also, as I see it, implies that if e.g. a README file in the
> topmost directory of the upstream tarball claims that this project is
> Copyright authors A, B and C, but one file claims Copyright author D,
> then file takes presedence over README, and if then that file cannot be
> parsed reliably regarding *both* copyright and licensing, then that file
> is deemed unsatifiably licensed for redistribution.
> 

thanks for the hint.
i noticed that upstream's README.txt includes several more authors,
which do not appear in any source file and definitely not (yet) in
debian/changelog

> 
> You are free to not want to improve clarity of upstream copyright and
> licensing, but you risk some distributors then choosing not to want to
> redistribute your fine code.
> 

just for the sake of completeness, i want to point out that pd-zexy has
been distributed in Debian and derivatives for more than 5 years.
the copyright did not seem to be such an issue until know.

this however can only mean that nobody had a look so close as you guys.
upstream is happy about that close inspection and will incorporate
changes based on the suggestion on this list in the next upstream release.


ghmasdf
IOhannes



smime.p7s
Description: S/MIME Cryptographic Signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Re: pd-zexy (debian/copyright)

[IOhannes m zmoelnig]

On 2010-08-17 18:36, Jonas Smedegaard wrote:
>
> So I dare ignore your "but" above and (parallel to continuing below
> discussion) I will start working on copyright-check and rewriting
> debian/copyright using DEP5 machine-readable format.
> 
> If you disagree with that, please shout, so I can stop wasting time on
> something that you will revert anyway afterwards :-)

please go ahead.
i'm happy if debian/copyright can be maintained easily and machine readable.


mfgasr
IOhannes



smime.p7s
Description: S/MIME Cryptographic Signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Re: pd-zexy

[IOhannes m zmoelnig]

On 2010-08-17 18:36, Jonas Smedegaard wrote:
> 
> So I dare ignore your "but" above and (parallel to continuing below

my "but" was really mostly their, as the discussion on debian/copyright
and the discussion on how the upstream copyright headers look like
intermingled.
they should be discussed separately.

mfgasdr
IOhannes



smime.p7s
Description: S/MIME Cryptographic Signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Re: pd-zexy

[Jonas Smedegaard]

On Tue, Aug 17, 2010 at 03:34:57PM +0200, IOhannes m zmoelnig wrote:

On 2010-08-17 14:56, Jonas Smedegaard wrote:



Would you mind me adding the CDBS copyright-check routine?


i don't object, but:



I can imagine how that may feel odd since you yourself are upstream 
for the code, but it does seem to me that you missed out some 
copyright and licensing pieces.  Not licensing conflicts, so nothing 
for you to worry about as upstream, but for Debian we care not only 
about that but also of properly recognizing all upstreams - not only 
main ones.


Please note that above is about redistribution for Debian and derived 
systems, i.e. debian/copyright and semi-automatically maintaining it.



Below is about upstream packaging, i.e. what might cause uncertainty for 
users and redistributors on what exactly thy are permitted to do with 
all the pieces that you offer them.



So I dare ignore your "but" above and (parallel to continuing below 
discussion) I will start working on copyright-check and rewriting 
debian/copyright using DEP5 machine-readable format.


If you disagree with that, please shout, so I can stop wasting time on 
something that you will revert anyway afterwards :-)



Upstream you might want to consider improving the licensing headers 
to (more clearly) declare copyright years.  Currently you state 
copyright like this:


 * copyleft (c) IOhannes m zmölnig
 *
 *   1999:forum::für::umläute:2004

There are multiple problems with this (IANAL, so YMMV):

  * the term "copyleft" have no legal meaning


but i guess that "(c)" is clear enough.


  * strings are expressed in latin1 (or latin13 or similar)


this is surely no legal requirement


  * it is unclear if the second string is copyright years

I recommend to instead use the following one-liner:

 * copyright 1999-2004, IOhannes m zmölnig


you translated it correctly :-)

the thing is, that this piece of software is also to be seen in an "art 
context" (phew!).

the entire copyright headers are in a way a "logo".
also the encoding confusion has a historic (for me) relevance.


I do not understand how that header is a logo, but that magic word "art" 
make me bow down in respect and not want to discuss any further.


It was just a suggestion (or, really, a recommendation), not a 
requirement (for you as upstream).


We (Debian) do need, however, to make sure that upstream copyright 
claims and licensing permissions are properly identified.


If the file headers do not (in our understanding of legal requirements 
for *redistributors* - not for *upstreams*) contain clear statements of 
both copyright and licensing, then we will need a written statement from 
those authors stating clearly the info we need.


This also, as I see it, implies that if e.g. a README file in the 
topmost directory of the upstream tarball claims that this project is 
Copyright authors A, B and C, but one file claims Copyright author D, 
then file takes presedence over README, and if then that file cannot be 
parsed reliably regarding *both* copyright and licensing, then that file 
is deemed unsatifiably licensed for redistribution.



You are free to not want to improve clarity of upstream copyright and 
licensing, but you risk some distributors then choosing not to want to 
redistribute your fine code.




i would hate to change these.


Ah, that is a language I understand :-D


 - Jonas

--
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Re: pd-zexy

[IOhannes m zmoelnig]

On 2010-08-17 15:45, Fabian Greffrath wrote:
> Am 17.08.2010 15:34, schrieb IOhannes m zmoelnig:
>> but i guess that "(c)" is clear enough.
> 
> According to lintian "(C) is not considered as a valid way to express
> the copyright ownership. The word Copyright or the © symbol should be
> used instead or in addition to (C). "
> 
> 

ok.

but still, we are talking about copyright notices in the upstream
sources and not about debian/copyright!

debian/copyright should of course be correctly formatted, and to my
knowledge already is:

This package was debianized by Guenter Geiger  on
Wed,  6 Nov 2002 12:38:33 +0100.

Downloaded from 

Copyright:
Copyright 1999-2010 IOhannes m zmoelnig

optimization (abs~, abssgn~, dirac~):
Copyright 2005-2006 Tim Blechmann

OSC-pattern matching:
Copyright 1998-2004 Matt Wright

This software is distributed under the GPL version 2
(see /usr/share/common-licenses/GPL-2).




smime.p7s
Description: S/MIME Cryptographic Signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Re: pd-zexy

[Fabian Greffrath]

Am 17.08.2010 15:34, schrieb IOhannes m zmoelnig:

but i guess that "(c)" is clear enough.


According to lintian "(C) is not considered as a valid way to express 
the copyright ownership. The word Copyright or the © symbol should be 
used instead or in addition to (C). " 



___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Re: pd-zexy

[IOhannes m zmoelnig]

On 2010-08-17 14:56, Jonas Smedegaard wrote:
> On Tue, Aug 17, 2010 at 12:55:37PM +0200, IOhannes m zmoelnig wrote:
>> ok,
>>
>> i think the pd-zexy package is almost ready for release.
>>
>> i rephrased the README.Debian, hopefully it's clearer now
>>
>> debian/changelog has better wording for quiltification
>>
>> maintainer is now pkg-multimedia-maintainers@ (at least in
>> debian/control.in; how do i update debian/control from that; shouldn't
>> it be done automagically?)
>>
>>
>> comments, uploads?
> 
> When you clean the source in cdbs "maintainer mode", control file is
> updated[1].  Like this:
> 
>   DEB_MAINTAINER_MODE=1 fakeroot debian/rules clean

right, i also found out about "DEB_AUTO_UPDATE_DEBIAN_CONTROL=1"

> Would you mind me adding the CDBS copyright-check routine?

i don't object, but:

> 
> I can imagine how that may feel odd since you yourself are upstream for
> the code, but it does seem to me that you missed out some copyright and
> licensing pieces.  Not licensing conflicts, so nothing for you to worry
> about as upstream, but for Debian we care not only about that but also
> of properly recognizing all upstreams - not only main ones.
> 
> Upstream you might want to consider improving the licensing headers to
> (more clearly) declare copyright years.  Currently you state copyright
> like this:
> 
>  * copyleft (c) IOhannes m zmölnig
>  *
>  *   1999:forum::für::umläute:2004
> 
> There are multiple problems with this (IANAL, so YMMV):
> 
>   * the term "copyleft" have no legal meaning

but i guess that "(c)" is clear enough.

>   * strings are expressed in latin1 (or latin13 or similar)

this is surely no legal requirement

>   * it is unclear if the second string is copyright years
> 
> I recommend to instead use the following one-liner:
> 
>  * copyright 1999-2004, IOhannes m zmölnig

you translated it correctly :-)

the thing is, that this piece of software is also to be seen in an "art
context" (phew!).
the entire copyright headers are in a way a "logo".
also the encoding confusion has a historic (for me) relevance.

i would hate to change these.

(for what it's worth, nowadays i most often use the more traditional
copyright clauses)

mfgasdr
IOhannes




smime.p7s
Description: S/MIME Cryptographic Signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Re: pd-zexy

[Jonas Smedegaard]

On Tue, Aug 17, 2010 at 12:55:37PM +0200, IOhannes m zmoelnig wrote:

ok,

i think the pd-zexy package is almost ready for release.

i rephrased the README.Debian, hopefully it's clearer now

debian/changelog has better wording for quiltification

maintainer is now pkg-multimedia-maintainers@ (at least in
debian/control.in; how do i update debian/control from that; shouldn't
it be done automagically?)


comments, uploads?


When you clean the source in cdbs "maintainer mode", control file is 
updated[1].  Like this:


  DEB_MAINTAINER_MODE=1 fakeroot debian/rules clean



Would you mind me adding the CDBS copyright-check routine?

I can imagine how that may feel odd since you yourself are upstream for 
the code, but it does seem to me that you missed out some copyright and 
licensing pieces.  Not licensing conflicts, so nothing for you to worry 
about as upstream, but for Debian we care not only about that but also 
of properly recognizing all upstreams - not only main ones.


Upstream you might want to consider improving the licensing headers to 
(more clearly) declare copyright years.  Currently you state copyright 
like this:


 * copyleft (c) IOhannes m zmölnig
 *
 *   1999:forum::für::umläute:2004

There are multiple problems with this (IANAL, so YMMV):

  * the term "copyleft" have no legal meaning
  * strings are expressed in latin1 (or latin13 or similar)
  * it is unclear if the second string is copyright years

I recommend to instead use the following one-liner:

 * copyright 1999-2004, IOhannes m zmölnig

I also recommend to encode using utf8, if that does not cause problems 
with the compiler or the resulting code.  But this is less important.



Regards,

 - Jonas


[1] True, that is lousily documented.  And no, I do not intend to offer 
that functionality separate from CDBS.


--
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Re: pd-zexy (was Re: request for membership, ITA)

[Jonas Smedegaard]

On Fri, Aug 13, 2010 at 12:22:30PM +0200, IOhannes zmölnig wrote:

On 08/13/2010 12:05 PM, Jonas Smedegaard wrote:


so i have now switched from using dh directly to cdbs, assuming that 
this fixes the issue and to get cdbs addicts back on board :-)


Awesome (for me).

For fairness sake, I should probably mention that I am the only one 
in this team strongly pro CDBS, while it seems (though we have no 
hard numbers) that several others are opposed to it...


i see.
the first reaction on #debian-multimedia was: " *sigh* more cdbs..."


He.  I am not that active on IRC so didn't see that.



README.Debian is wrongly encoded: Your name contain a non-ASCII
character not encoded as UTF-8 which is mandatory these days.


i'll try to fix that.
i never completely figured how to do the UTF-8 think correctly...
iconv should do the trickdone!


Yeah, I keep seeing iconv being used but I never found that intuitive.

Personally I am fan of recode, which perhaps you might find useful too:

recode latin1..utf8 debian/README.Debian


Changelog says the package is quilt'ified.  That seems a superfluous 
comment to me, since there is nothing in the package (not even 
infrastructure files) for patching.


well yes:
i started from the original pd-zexy package, which had patches and
quiltified them.
when upgrading to the latest upstream release, these patches became
superfluous (since they were already included).
however, source/format now reads "3.0 (quilt)", so i thought that was
quiltification enough.


I imagined something like that had happened :-)

I suggest to instead mention something like "Use dpkg source format 3.0 
(quilt)".




feel free to remove the line in the changelog.


thanks - I assumed I was allowed already (we do teamwork, right?), just 
wanted to discuss here both for the potential learning experience (of 
you or perhaps others following our conversation) and in case you 
actually had a different reason that the one I (correctly, it turns out) 
guessed. :-)



Now that you use CDBS, would you then mind me adding a couple of 
additional features of that - like auto-resolving build-dependencies, 
get-orig-source rule and copyright and licensing tracking?




sure, go ahead!


Will do.  ...in a little while - my girlfriend wants me to look at some 
Ikiwiki hacking now :-)



 - Jonas

--
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Re: pd-zexy (was Re: request for membership, ITA)

[Jonas Smedegaard]

On Fri, Aug 13, 2010 at 12:31:03PM +0200, IOhannes zmölnig wrote:

On 08/13/2010 12:22 PM, IOhannes zmölnig wrote:

are there any tools for handling the NEWS file?


obviously "dch --news"
done. pushed.


Ah, I thought you meant user tools - and the answer there is to install 
apt-listchanges.



 - Jonas

--
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Re: pd-zexy (was Re: request for membership, ITA)

[IOhannes zmölnig]

On 08/13/2010 12:22 PM, IOhannes zmölnig wrote:
> are there any tools for handling the NEWS file?

obviously "dch --news"
done. pushed.

fgmnsard
IOhannes



signature.asc
Description: OpenPGP digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Re: pd-zexy (was Re: request for membership, ITA)

[IOhannes zmölnig]

On 08/13/2010 12:05 PM, Jonas Smedegaard wrote:
>>
>> so i have now switched from using dh directly to cdbs, assuming that
>> this fixes the issue and to get cdbs addicts back on board :-)
> 
> Awesome (for me).
> 
> For fairness sake, I should probably mention that I am the only one in
> this team strongly pro CDBS, while it seems (though we have no hard
> numbers) that several others are opposed to it...

i see.
the first reaction on #debian-multimedia was: " *sigh* more cdbs..."

> 
> 
> README.Debian is wrongly encoded: Your name contain a non-ASCII
> character not encoded as UTF-8 which is mandatory these days.

i'll try to fix that.
i never completely figured how to do the UTF-8 think correctly...
iconv should do the trickdone!

> 
> Changelog says the package is quilt'ified.  That seems a superfluous
> comment to me, since there is nothing in the package (not even
> infrastructure files) for patching.

well yes:
i started from the original pd-zexy package, which had patches and
quiltified them.
when upgrading to the latest upstream release, these patches became
superfluous (since they were already included).
however, source/format now reads "3.0 (quilt)", so i thought that was
quiltification enough.

feel free to remove the line in the changelog.

> 
> It seems it could make sense to add a NEWS file mentioning the change of
> path, so that existing users get informed about the need to add to pd-path.

that's a good idea.
i'll do that.
are there any tools for handling the NEWS file?

> 
> Now that you use CDBS, would you then mind me adding a couple of
> additional features of that - like auto-resolving build-dependencies,
> get-orig-source rule and copyright and licensing tracking?
> 

sure, go ahead!

fgmadr
IOhannes




signature.asc
Description: OpenPGP digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Re: pd-zexy (was Re: request for membership, ITA)

[Jonas Smedegaard]

On Fri, Aug 13, 2010 at 11:05:52AM +0200, IOhannes zmölnig wrote:

On 08/13/2010 10:13 AM, IOhannes zmölnig wrote:




Aand... short-form dh7 seems to not work correctly. since there is a 
build directory, debian/rules build says that 'build' is up to date. 
And phony targets do not seem to work with dh7.
This means that the package ends up being built under root (in the 
binary stage), which is frowned upon by policy.




i'm not sure whether i fully understand this (i understand the part 
about the policy; i don't understand the part about dh7): is this a 
bug i can/should do something about or is it a bug in dh which has to 
be fixed in the debhelper-package?



so i have now switched from using dh directly to cdbs, assuming that 
this fixes the issue and to get cdbs addicts back on board :-)


Awesome (for me).

For fairness sake, I should probably mention that I am the only one in 
this team strongly pro CDBS, while it seems (though we have no hard 
numbers) that several others are opposed to it...



README.Debian is wrongly encoded: Your name contain a non-ASCII 
character not encoded as UTF-8 which is mandatory these days.


Changelog says the package is quilt'ified.  That seems a superfluous 
comment to me, since there is nothing in the package (not even 
infrastructure files) for patching.


It seems it could make sense to add a NEWS file mentioning the change of 
path, so that existing users get informed about the need to add to 
pd-path.


Now that you use CDBS, would you then mind me adding a couple of 
additional features of that - like auto-resolving build-dependencies, 
get-orig-source rule and copyright and licensing tracking?



 - Jonas

--
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers