openMSX: opengl builtin or split package?

[Yves Junqueira M. Teixeira]

Hi,

openMSX supports opengl output, which improves its quality considerably.
Should I compile it with opengl support (that would make it run-depend on 
xlibmesa-gl, right?) or should I split it in two packages, an openmsx and an 
openmsx-opengl? 

The first scenario requires everybody to get opengl libs even if the user can't 
run that (like me, actually). He/She will just get strange error messages if 
h/she tries to run it with opengl output.

The second would be a tuff job to a beginner like me. Not that I am afraid of 
challanges, though :)

Thanks in Advance.

Yves 'nictuku'.

RFS: update to libchipcard

[Thomas Viehmann]

Hi.

I'm maintaining the libchipcard package and would be very pleased if
someone could sponsor a the following bug-fix update:

libchipcard (0.9.1-4) unstable; urgency=low

  * Don't let father (in daemon mode) remove pid file after spawn.
(closes: #225137)
  * Include copyright in copyright.

 -- Thomas Viehmann <[EMAIL PROTECTED]>  Wed, 31 Dec 2003 15:02:25 +0100

libchipcard (0.9.1-3) unstable; urgency=low

  * Improved package description spelling.
  * Bump standards version.
  * Add reload to init.d-script. (Suggested by Joerg Sommer.)
  * Lower priority of -dev-package to extra (policy 2.5 and dependency
on libpcsclite-dev).

 -- Thomas Viehmann <[EMAIL PROTECTED]>  Tue, 25 Nov 2003 21:15:36 +0100

Further information on libchipcard can be obtained by executing
apt-cache show libchipcard20, one notable indirect dependency is
gnucash. I don't think I need to mention it's lintian/linda cleanness
(save the standards version too new for the former).

Of course any suggestions for improvement are welcome as well.

Kind Regards

Thomas


pgpEU9B1g7MNn.pgp
Description: PGP signature

Re: RFS: update to libchipcard

[Thomas Viehmann]

Thomas Viehmann wrote:
> [an attempt at an elaborate sponsorship request]

If I could only learn to include the URL:
.

Cheers

Thomas



pgpNyoyUiBBVH.pgp
Description: PGP signature

Re: pbuilder ${shlibs:Depends} yields libc6-2.2.4-4 ???

[Bob Proulx]

Rene Engelhard wrote:
> Bob Proulx wrote:
> > Why does building a package with pbuilder generate the seemingly wrong
> > version for Depends: of 2.2.4-4 regarldless that 2.2.5-11.5 is the
> > installed library?  What am I doing wrong?
> 
> Nothing.
> 
> [EMAIL PROTECTED]:~$ sudo chroot chroots/stable cat 
> /var/lib/dpkg/info/libc6.shlibs
> libc 6 libc6 (>= 2.2.4-4)

Thanks for taking the time to answer.  I am not unappreciative but
unfortunately I did not find this very informative to me.  Even that
reference to the libc6.shlibs file, while correct, was obtuse to me.
So before the mailling list archive gets split into the new month I
decided I would get another in with an update with an expansion of
this topic.

Digging through the dpkg-shlibdeps perl script and I can see where it
is reading the file you referenced.  Therefore it appears that shared
library packages can specify an ABI version separate from their
installed package version.  The glibc package specifies 2.2.4-4 as the
ABI so that even though version 2.2.5-11.5 is installed.  The
installed value is overridden with the libc6 package specified version
from the shlibs file.

Digging into the glibc package I see that they manually set the ABI
version to 2.2.4-4 in the debian/rules.d/shlibs.mk file.

Now knowing a little more about what to look for I was able to locate
documentation on the process.  Here is the pointer.

  
http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-shlibdeps

Thanks again,
Bob


pgps4sIwm0slr.pgp
Description: PGP signature

Sponsor sought for resolvconf

[Thomas Hood]

I have a new version of resolvconf ready but my current sponsor
isn't finding the time to upload it.  Is there a resolvconf-using
DD out there who can help?

--
Thomas Hood

Re: openMSX: opengl builtin or split package?

[Goedson Teixeira Paixao]

* Yves Junqueira M. Teixeira ([EMAIL PROTECTED]) wrote:
> Hi,
> 
> openMSX supports opengl output, which improves its quality considerably.
> Should I compile it with opengl support (that would make it run-depend on 
> xlibmesa-gl, right?) or should I split it in two packages, an openmsx and an 
> openmsx-opengl? 
> 
> The first scenario requires everybody to get opengl libs even if the user 
> can't run that (like me, actually). He/She will just get strange error 
> messages if h/she tries to run it with opengl output.

I'm in favour of having two packages so people without opengl support
can still use openmsx.


-- 
Goedson Teixeira Paixao



pgphVETLcbQOP.pgp
Description: PGP signature

Re: Sponsor sought for resolvconf

[Paul Cupis]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wednesday 31 December 2003 22:04, Thomas Hood <[EMAIL PROTECTED]> 
wrote:
> I have a new version of resolvconf ready but my current sponsor
> isn't finding the time to upload it.  Is there a resolvconf-using
> DD out there who can help?

Where are your files?

If no-one can help before then, I should be able to have a look tomorrow 
evening.

Paul Cupis
- -- 
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)

iEYEARECAAYFAj/zU/cACgkQIzuKV+SHX/m36ACeIIODoyMI7QciJKXRCDi51+9G
T0AAmgOH6aauHc/ScBG3awFKBu4iGFqs
=jHyJ
-END PGP SIGNATURE-

Re: openMSX: opengl builtin or split package?

[Keegan Quinn]

On Wed, Dec 31, 2003 at 05:12:56AM -0200, Yves Junqueira M. Teixeira wrote:
> openMSX supports opengl output, which improves its quality considerably.
> Should I compile it with opengl support (that would make it run-depend on 
> xlibmesa-gl, right?) or should I split it in two packages, an openmsx and an 
> openmsx-opengl? 

I think this is more of a matter of preference than anything; neither solution
is definitively more correct than the other.

It doesn't seem to me that this openMSX software is currently in main,
so some background might be helpful...  Does it require X anyway,
regardless of OpenGL support?

If so, it probably doesn't hurt too much to depend on xlibmesa3-gl;
x-window-system-core depends on it already.  

> The first scenario requires everybody to get opengl libs even if the user 
> can't run that (like me, actually).

Do you run X?  Even though you have no hardware support, is xlibmesa3-gl
installed on your machine?  (Did you install it to experiment with this
or was it already there?)

HTH,

 - Keegan



signature.asc
Description: Digital signature

openMSX: opengl builtin or split package?

[Yves Junqueira M. Teixeira]

Hi,

openMSX supports opengl output, which improves its quality considerably.
Should I compile it with opengl support (that would make it run-depend on xlibmesa-gl, 
right?) or should I split it in two packages, an openmsx and an openmsx-opengl? 

The first scenario requires everybody to get opengl libs even if the user can't run 
that (like me, actually). He/She will just get strange error messages if h/she tries 
to run it with opengl output.

The second would be a tuff job to a beginner like me. Not that I am afraid of 
challanges, though :)

Thanks in Advance.

Yves 'nictuku'.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

RFS: update to libchipcard

[Thomas Viehmann]

Hi.

I'm maintaining the libchipcard package and would be very pleased if
someone could sponsor a the following bug-fix update:

libchipcard (0.9.1-4) unstable; urgency=low

  * Don't let father (in daemon mode) remove pid file after spawn.
(closes: #225137)
  * Include copyright in copyright.

 -- Thomas Viehmann <[EMAIL PROTECTED]>  Wed, 31 Dec 2003 15:02:25 +0100

libchipcard (0.9.1-3) unstable; urgency=low

  * Improved package description spelling.
  * Bump standards version.
  * Add reload to init.d-script. (Suggested by Joerg Sommer.)
  * Lower priority of -dev-package to extra (policy 2.5 and dependency
on libpcsclite-dev).

 -- Thomas Viehmann <[EMAIL PROTECTED]>  Tue, 25 Nov 2003 21:15:36 +0100

Further information on libchipcard can be obtained by executing
apt-cache show libchipcard20, one notable indirect dependency is
gnucash. I don't think I need to mention it's lintian/linda cleanness
(save the standards version too new for the former).

Of course any suggestions for improvement are welcome as well.

Kind Regards

Thomas


pgp0.pgp
Description: PGP signature

Re: RFS: update to libchipcard

[Thomas Viehmann]

Thomas Viehmann wrote:
> [an attempt at an elaborate sponsorship request]

If I could only learn to include the URL:
.

Cheers

Thomas



pgp0.pgp
Description: PGP signature

Re: pbuilder ${shlibs:Depends} yields libc6-2.2.4-4 ???

[Bob Proulx]

Rene Engelhard wrote:
> Bob Proulx wrote:
> > Why does building a package with pbuilder generate the seemingly wrong
> > version for Depends: of 2.2.4-4 regarldless that 2.2.5-11.5 is the
> > installed library?  What am I doing wrong?
> 
> Nothing.
> 
> [EMAIL PROTECTED]:~$ sudo chroot chroots/stable cat /var/lib/dpkg/info/libc6.shlibs
> libc 6 libc6 (>= 2.2.4-4)

Thanks for taking the time to answer.  I am not unappreciative but
unfortunately I did not find this very informative to me.  Even that
reference to the libc6.shlibs file, while correct, was obtuse to me.
So before the mailling list archive gets split into the new month I
decided I would get another in with an update with an expansion of
this topic.

Digging through the dpkg-shlibdeps perl script and I can see where it
is reading the file you referenced.  Therefore it appears that shared
library packages can specify an ABI version separate from their
installed package version.  The glibc package specifies 2.2.4-4 as the
ABI so that even though version 2.2.5-11.5 is installed.  The
installed value is overridden with the libc6 package specified version
from the shlibs file.

Digging into the glibc package I see that they manually set the ABI
version to 2.2.4-4 in the debian/rules.d/shlibs.mk file.

Now knowing a little more about what to look for I was able to locate
documentation on the process.  Here is the pointer.

  http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-shlibdeps

Thanks again,
Bob


pgp0.pgp
Description: PGP signature

Sponsor sought for resolvconf

[Thomas Hood]

I have a new version of resolvconf ready but my current sponsor
isn't finding the time to upload it.  Is there a resolvconf-using
DD out there who can help?

--
Thomas Hood


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: openMSX: opengl builtin or split package?

[Goedson Teixeira Paixao]

* Yves Junqueira M. Teixeira ([EMAIL PROTECTED]) wrote:
> Hi,
> 
> openMSX supports opengl output, which improves its quality considerably.
> Should I compile it with opengl support (that would make it run-depend on 
> xlibmesa-gl, right?) or should I split it in two packages, an openmsx and an 
> openmsx-opengl? 
> 
> The first scenario requires everybody to get opengl libs even if the user can't run 
> that (like me, actually). He/She will just get strange error messages if h/she tries 
> to run it with opengl output.

I'm in favour of having two packages so people without opengl support
can still use openmsx.


-- 
Goedson Teixeira Paixao



pgp0.pgp
Description: PGP signature

Re: Sponsor sought for resolvconf

[Paul Cupis]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wednesday 31 December 2003 22:04, Thomas Hood <[EMAIL PROTECTED]> 
wrote:
> I have a new version of resolvconf ready but my current sponsor
> isn't finding the time to upload it.  Is there a resolvconf-using
> DD out there who can help?

Where are your files?

If no-one can help before then, I should be able to have a look tomorrow 
evening.

Paul Cupis
- -- 
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)

iEYEARECAAYFAj/zU/cACgkQIzuKV+SHX/m36ACeIIODoyMI7QciJKXRCDi51+9G
T0AAmgOH6aauHc/ScBG3awFKBu4iGFqs
=jHyJ
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: openMSX: opengl builtin or split package?

[Keegan Quinn]

On Wed, Dec 31, 2003 at 05:12:56AM -0200, Yves Junqueira M. Teixeira wrote:
> openMSX supports opengl output, which improves its quality considerably.
> Should I compile it with opengl support (that would make it run-depend on 
> xlibmesa-gl, right?) or should I split it in two packages, an openmsx and an 
> openmsx-opengl? 

I think this is more of a matter of preference than anything; neither solution
is definitively more correct than the other.

It doesn't seem to me that this openMSX software is currently in main,
so some background might be helpful...  Does it require X anyway,
regardless of OpenGL support?

If so, it probably doesn't hurt too much to depend on xlibmesa3-gl;
x-window-system-core depends on it already.  

> The first scenario requires everybody to get opengl libs even if the user can't run 
> that (like me, actually).

Do you run X?  Even though you have no hardware support, is xlibmesa3-gl
installed on your machine?  (Did you install it to experiment with this
or was it already there?)

HTH,

 - Keegan



signature.asc
Description: Digital signature