Re: Resigning from Debian

[Alexis Sukrieh]

* Sandro Tosi (mo...@debian.org) :
> Good luck for the future and thanks a lot for all your contributions!
> 
> > Feel free to orphan/adopt all of my packages.
> >
> > electricsheep[1] deserves a prioritary adoption: a major upstream
> > version has been released and Debian's is now deprecated.
> 
> I'm just handled all your packages as per MIA processes, expect
> electricsheep and tinymce that have already people interested in their
> adoption

Ok, I've seen that, thanks!

BTW, Sven Joachim also proposed to take over the package backup-manager.

He's been contributing to backup-manager's source for a while, so I
think he'll make a good Debian maintainer for that package.

He needs a sponsor to do so, as he's not a DD. Maybe someone here would
be willing to sponsor him.

Regards,

-- 
Alexis Sukrieh 

Chicago Transit Authority Rider's Rule #36:
Never ever ask the tough looking gentleman wearing El Rukn headgear
where he got his "pyramid powered pizza warmer".
-- Chicago Reader 3/27/81


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Resigning from Debian

[Sandro Tosi]

Hi Alexis,

On Wed, Jul 8, 2009 at 08:51, Alexis Sukrieh wrote:
> * Sandro Tosi (mo...@debian.org) :
>> Good luck for the future and thanks a lot for all your contributions!
>>
>> > Feel free to orphan/adopt all of my packages.
>> >
>> > electricsheep[1] deserves a prioritary adoption: a major upstream
>> > version has been released and Debian's is now deprecated.
>>
>> I'm just handled all your packages as per MIA processes, expect
>> electricsheep and tinymce that have already people interested in their
>> adoption
>
> Ok, I've seen that, thanks!

welcome :)

> BTW, Sven Joachim also proposed to take over the package backup-manager.

Yeah, I saw that, but the mail came after I've sent the bug.

> He's been contributing to backup-manager's source for a while, so I
> think he'll make a good Debian maintainer for that package.
>
> He needs a sponsor to do so, as he's not a DD. Maybe someone here would
> be willing to sponsor him.

The way to request for sponsorship is:

1. prepare a package
2. upload it to mentors.debian.net
3. write to debian-ment...@lists.debian.org asking for sponsorship.

Sven should follow this path.

Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#536234: ITP: haskell-regex-tdfa-utf8 -- Haskell library for the UTF8 version of the tagged DFA regex engine

[Erik de Castro Lopo]

Package: wnpp
Severity: wishlist
Owner: Erik de Castro Lopo 


* Package name: haskell-regex-tdfa-utf8
  Version : 1.0
  Upstream Author : Christopher Kuklewicz
* URL : 
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/regex-tdfa-utf8
* License : BSD
  Programming Lang: Haskell
  Description : Haskell library for the UTF8 version of the tagged DFA 
regex engine

 This combines regex-tdfa with utf8-string to allow searching over UTF8 encoded
 lazy bytestrings.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#536235: ITP: haskell-regex-tdfa -- Haskell library for a tagged DFA regex engine

[Erik de Castro Lopo]

Package: wnpp
Severity: wishlist
Owner: Erik de Castro Lopo 


* Package name: haskell-regex-tdfa
  Version : 1.1.2
  Upstream Author : Christopher Kuklewicz
* URL : 
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/regex-tdfa
* License : BSD
  Programming Lang: Haskell
  Description : Haskell library for a tagged DFA regex engine

 An alternative to GHC's Text.Regex module with some enhancements.
 .
 GHC's Text.Regex module marshalls the data back and forth to c-arrays to
 call libc and this is far too slow (and strict).
 .
 This module parses regular expression Strings using a Parsec parser and
 creates an internal data structure (Text.Regex.Lazy.Pattern). This is then
 transformed a DFA table for matching against the input String or
 FastPackedString. The input string is consumed lazily, so it may be an
 arbitrarily long or infinite source.
 .
 This package contains the libraries compiled for GHC 6.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Linking libxxx.so to libxxx_r.so? dpkg-shlibdep doesn't like it...

[Pierre Habouzit]

On Sun, Jul 05, 2009 at 11:01:21PM +0200, Christian Hammers wrote:
> Hello
> 
> To help packages like Apache which have some parts like libaprutil
> that wants to link against libmysqlclient16_r.so and some like PHP
> that wants to link against libmysqlcient.so, it was proposed that
> libmysqlclient.so should be made a symlink pointing to the thread safe
> *_r.so version.
> 
> (This change would be introduced for the upcoming new soname version 
> which is not yet into unstable! Performance issues were considered to
> be negligible as the client library only copies data from and to the
> server)
> 
> But when putting a corresponding symlink into
> debian/libmysqlclient16.links, the build process fails with:
> 
> dh_shlibdeps -a -l debian/libmysqlclient16/usr/lib -L libmysqlclient16
> 
> LD_LIBRARY_PATH=/usr/lib/libfakeroot:/usr/lib64/libfakeroot:/usr/lib32/libfakeroot:/debian/libmysqlclient16/usr/lib
> dpkg-shlibdeps -Tdebian/libmysqlclient16.substvars 
> -Sdebian/libmysqlclient16 
> debian/libmysqlclient16/usr/lib/libmysqlclient_r.so.16.0.0
> dpkg-shlibdeps: warning: dependency on libnsl.so.1 could be avoided if 
> "debian/libmysqlclient16/usr/lib/libmysqlclient_r.so.16.0.0" were not 
> uselessly linked against it (they use none of its symbols).
> dpkg-shlibdeps: warning: dependency on libcrypt.so.1 could be avoided if 
> "debian/libmysqlclient16/usr/lib/libmysqlclient_r.so.16.0.0" were not 
> uselessly linked against it (they use none of its symbols).
> 
> LD_LIBRARY_PATH=/usr/lib/libfakeroot:/usr/lib64/libfakeroot:/usr/lib32/libfakeroot:/debian/libmysqlclient16/usr/lib
> dpkg-shlibdeps -Tdebian/mysql-client-5.1.substvars 
> -Sdebian/libmysqlclient16 debian/mysql-client-5.1/usr/sbin/mysqlmanager 
> debian/mysql-client-5.1/usr/bin/mysqldump 
> debian/mysql-client-5.1/usr/bin/mysql_client_test_embedded 
> debian/mysql-client-5.1/usr/bin/mysql_waitpid 
> debian/mysql-client-5.1/usr/bin/mysqladmin 
> debian/mysql-client-5.1/usr/bin/mysqltest_embedded 
> debian/mysql-client-5.1/usr/bin/mysql 
> debian/mysql-client-5.1/usr/bin/mysqlshow 
> debian/mysql-client-5.1/usr/bin/mysqlcheck 
> debian/mysql-client-5.1/usr/bin/myisam_ftdump 
> debian/mysql-client-5.1/usr/bin/mysqlimport 
> debian/mysql-client-5.1/usr/bin/mysql_client_test
> dpkg-shlibdeps: warning: debian/libmysqlclient16/usr/lib/libmysqlclient.so.16 
> has an unexpected SONAME (libmysqlclient_r.so.16)
> dpkg-shlibdeps: error: no dependency information found for 
> debian/libmysqlclient16/usr/lib/libmysqlclient.so.16 (used by 
> debian/mysql-client-5.1/usr/bin/mysqldump).
> dh_shlibdeps: dpkg-shlibdeps returned exit code 2
> make: *** [binary-arch] Error 1
> 
> Before I start looking for a creative workaround - is this approach a good 
> idea
> in the first place?

You cannot do that:
diff -U0 =(nm -D /usr/lib/libmysqlclient.so.15.0.0 | cut -d' ' -f2- | sort -u) 
=(nm -D /usr/lib/libmysqlclient_r.so.15.0.0 | cut -d' ' -f2- | sort -u)|grep 
'^-'
--- /tmp/zshUjt2JU  2009-07-08 15:49:03.888491590 +0200
-B my_errno

Unless this big fat command yields nothing with the .16 version, libmysql_r.so
has *not* an ABI that includes the one of libmysqlclient.so.

IOW programs that would be built against libmysqlclient.so on other distros
will not work on Debian at all if you do that.

As of the dpkg-shlibdeps warning you can probably work it around with proper -x
arguments (ugly).

-- 
Intersec 
Pierre Habouzit 
Tél : +33 (0)1 5570 3346
Mob : +33 (0)6 1636 8131
Fax : +33 (0)1 5570 3332
37 Rue Pierre Lhomme
92400 Courbevoie


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Linking libxxx.so to libxxx_r.so? dpkg-shlibdep doesn't like it...

[Pierre Habouzit]

On Wed, Jul 08, 2009 at 03:53:58PM +0200, Pierre Habouzit wrote:
> On Sun, Jul 05, 2009 at 11:01:21PM +0200, Christian Hammers wrote:
> > Hello
> > 
> > To help packages like Apache which have some parts like libaprutil
> > that wants to link against libmysqlclient16_r.so and some like PHP
> > that wants to link against libmysqlcient.so, it was proposed that
> > libmysqlclient.so should be made a symlink pointing to the thread safe
> > *_r.so version.
> > 
> > (This change would be introduced for the upcoming new soname version 
> > which is not yet into unstable! Performance issues were considered to
> > be negligible as the client library only copies data from and to the
> > server)
> > 
> > But when putting a corresponding symlink into
> > debian/libmysqlclient16.links, the build process fails with:
> > 
> > dh_shlibdeps -a -l debian/libmysqlclient16/usr/lib -L libmysqlclient16
> > 
> > LD_LIBRARY_PATH=/usr/lib/libfakeroot:/usr/lib64/libfakeroot:/usr/lib32/libfakeroot:/debian/libmysqlclient16/usr/lib
> > dpkg-shlibdeps -Tdebian/libmysqlclient16.substvars 
> > -Sdebian/libmysqlclient16 
> > debian/libmysqlclient16/usr/lib/libmysqlclient_r.so.16.0.0
> > dpkg-shlibdeps: warning: dependency on libnsl.so.1 could be avoided if 
> > "debian/libmysqlclient16/usr/lib/libmysqlclient_r.so.16.0.0" were not 
> > uselessly linked against it (they use none of its symbols).
> > dpkg-shlibdeps: warning: dependency on libcrypt.so.1 could be avoided if 
> > "debian/libmysqlclient16/usr/lib/libmysqlclient_r.so.16.0.0" were not 
> > uselessly linked against it (they use none of its symbols).
> > 
> > LD_LIBRARY_PATH=/usr/lib/libfakeroot:/usr/lib64/libfakeroot:/usr/lib32/libfakeroot:/debian/libmysqlclient16/usr/lib
> > dpkg-shlibdeps -Tdebian/mysql-client-5.1.substvars 
> > -Sdebian/libmysqlclient16 debian/mysql-client-5.1/usr/sbin/mysqlmanager 
> > debian/mysql-client-5.1/usr/bin/mysqldump 
> > debian/mysql-client-5.1/usr/bin/mysql_client_test_embedded 
> > debian/mysql-client-5.1/usr/bin/mysql_waitpid 
> > debian/mysql-client-5.1/usr/bin/mysqladmin 
> > debian/mysql-client-5.1/usr/bin/mysqltest_embedded 
> > debian/mysql-client-5.1/usr/bin/mysql 
> > debian/mysql-client-5.1/usr/bin/mysqlshow 
> > debian/mysql-client-5.1/usr/bin/mysqlcheck 
> > debian/mysql-client-5.1/usr/bin/myisam_ftdump 
> > debian/mysql-client-5.1/usr/bin/mysqlimport 
> > debian/mysql-client-5.1/usr/bin/mysql_client_test
> > dpkg-shlibdeps: warning: 
> > debian/libmysqlclient16/usr/lib/libmysqlclient.so.16 has an unexpected 
> > SONAME (libmysqlclient_r.so.16)
> > dpkg-shlibdeps: error: no dependency information found for 
> > debian/libmysqlclient16/usr/lib/libmysqlclient.so.16 (used by 
> > debian/mysql-client-5.1/usr/bin/mysqldump).
> > dh_shlibdeps: dpkg-shlibdeps returned exit code 2
> > make: *** [binary-arch] Error 1
> > 
> > Before I start looking for a creative workaround - is this approach a good 
> > idea
> > in the first place?
> 
> You cannot do that:

This is poorly worded, you can do what you want, but it means that you
will break binary compatibility with other distributions. By bumping the
soname, you ensure that nothing will break with this change, so
Debian-wise it's probably fine.

Note though that openssl for example hasn't the same soname on RedHat
for example (where it's libssl.so.4 I think), so I'm not sure the whole
cross-distribution binary compatibility stuff is that much of a
concern. I'll let other people comment on it though.

-- 
Intersec 
Pierre Habouzit 
Tél : +33 (0)1 5570 3346
Mob : +33 (0)6 1636 8131
Fax : +33 (0)1 5570 3332
37 Rue Pierre Lhomme
92400 Courbevoie


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Tidying up packages

[Enrico Zini]

Hello,

I've recently had a serendipitous excuse[1] to look at my package list
and tidy up things a bit, orphaning a thing or two and publishing my
plans for another half-forgotten package.

I realised that while this tidying up is important and rather easy to
do, I often lack the trigger to do that instead of something else. Or if
I want to tidy up, I may forget to look into a place or two.

I just had a quick conversation on #debian-qa where these ideas have
been flying around:

 - create a checklist of things that one could do every once in a while
   to tidy up is/her package list. A crude starter is here:
   http://wiki.debian.org/TidyUpChecklist and it can be something that
   fits in a little section in the Developer's Reference;

 - decide a "tidy up your package list" day, say, twice a year, where
   such a checklist is announced with a post to planet or a mail to
   debian-devel-announce;

 - instead of a "tidy up your package day", the DPL can invite people to
   focus on one or two items, depending on the current state of affairs;

 - instead of a "tidy up your package day", DPN could suggest one item
   from the checklist on every issue, and point to the full checklist to
   find more.

Opinions?
Entries for http://wiki.debian.org/TidyUpChecklist ?


Ciao,

Enrico

[1] Namely, telling a NM applicant that he should attend to a few things
that have been bitrotting, and then looking at my own DDPO page, erhm.
-- 
GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: Digital signature

Bug#536245: RFH: graphviz -- rich set of graph drawing tools

[Cyril Brulebois]

Package: wnpp
Severity: normal

Heya folks.

I request assistance with maintaining the graphviz package. That might
also move to an RFA later on.

Given I'm slowly drifting to more porting, I'm currently lacking time to
maintain graphviz properly. If you're interested, you may want to be
aware of some points:
 - Upstream is very nice, but now ships a bundled debian/ directory in
   its tarball, and will continue to do so. Repacking is/will be needed.
 - There are libraries, with different sonames, and plugins. I guess
   there's very little point in splitting the current libgraphviz4
   library in more libraries (given it only has 3 rdeps last I checked)
   but you'll need to understand the library packaging issues here, and
   try hard not to break anything.
 - There are bindings for several languages, and some bugs open against
   them. These bindings were requested presumably for Ubuntu, and given
   that some aren't really used, or buggy, it might make sense to drop
   some. Note that obviously, upstream doesn't know how to use each of
   them, given they're swig-generated.

That's all I can think of right now. Packaging is in collab-maint's git
(debian-only, but I'm not opposed to seeing this evolve in some other
setup), patches can be pushed there in some branches, or even in
“unstable” if you know what you're doing.


The package description follows:
 Graph drawing addresses the problem of visualizing structural information
 by constructing geometric representations of abstract graphs and networks.
 Automatic generation of graph drawings has important applications in key
 technologies such as database design, software engineering, VLSI and
 network design and visual interfaces in other domains. Situations where
 these tools might be particularly useful include:
 .
   * you would like to restructure a program and first need to understand
 the relationships between its types, procedures, and source files
   * you need to find the bottlenecks in an Internet backbone - not only
 individual links, but their relationships
   * you're debugging a protocol or microarchitecture represented as a
 finite state machine and need to figure out how a certain
 error state arises
   * you would like to browse a database schema, knowledge base, or
 distributed program represented graphically
   * you would like to see an overview of a collection of linked documents
   * you would like to discover patterns and communities of interest in a
 database of telephone calls or e-mail messages


Thanks in advance.

Mraw,
KiBi.



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Is Christian Meder MIA?

[Walter Franzini]

Hi,

in the past months I've tryied without success to contact Christian
Meder (ch...@absolutegiganten.org), the maintainer of the aegis package,
offering my help.

As a Debian and Aegis user I'm a bit worried of state of the aegis
package.

He uploaded 4.24-1 (2008-04-20) and next packaging updates until 4.24-5
(2008-12-05) in the meantime the upstream team has done one stable
updates (4.24.1 released 2008-09-24).  Later (2009-06-29) the upstream
team has released another stable release (4.24.2).

thanks
-- 
Walter Franzini
http://aegis.stepbuild.org/


pgp95xTGubd1x.pgp
Description: PGP signature

Re: RFC: DEP-3: Patch Tagging Guidelines

[Guido Günther]

On Tue, Jul 07, 2009 at 12:56:26AM +0100, James Westby wrote:
> Guido Günther wrote:
> >> I am concerned that just allowing to use git-format-patch will result in
> >> people not making an effort to markup other metadata in DEP#3 format,
> >> like bug numbers or reviewers and leave those as free-form in the body.
> > We can have Forwarded:, Origin:, Received-by: in this format as well,
> > just like Signed-off-by: or Reviewed-by: or Thanks:.
> 
> They are difficult to update though. Say we collaborate in a VCS on the
> same package, and you create a patch and upload it, and then I later
> forward it.
> 
> I will then want to change the "Forwarded:" value in the patch, however
> this is in the commit message, so must I amend your commit in order to
> do that?
Which isn't a problem on patch-queue branches since you either can
recreate them anytime from what's in debian/patches or simply ammend the
commit. They're supposed to be rebased frequently anyway.
Cheers,
 -- Guido


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

New virtual package x-image-viewer?

[Jan Hauke Rahm]

Hello everybody,

I'd like to have a new virtual package 'x-image-viewer'. All packages
providing that virtual package should be able to view images in common
formats (png, jpeg etc.). I'm thinking but that's pretty much all I can
say... It's obvious that I would want all image viewers to provide that
virtual package then.

What do you think?

Hauke


signature.asc
Description: Digital signature

dh_nativejava warning

[Adrian Perez]

The latest lintian complains about dh_nativejava prepending paths to
maintainer scripts. I wish to know what's the status of fixing this
since it's affecting a package of mine. 
The bug report #511491 submitted a patch, I think.
-- 
Best regards, 

Adrian Perez 


signature.asc
Description: This is a digitally signed message part

Re: New virtual package x-image-viewer?

[Jakub Wilk]

* Jan Hauke Rahm , 2009-07-08, 19:36:

I'd like to have a new virtual package 'x-image-viewer'. All packages
providing that virtual package should be able to view images in common
formats (png, jpeg etc.). I'm thinking but that's pretty much all I can
say... It's obvious that I would want all image viewers to provide that
virtual package then.

And such a package is needed because...?

--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New virtual package x-image-viewer?

[Jan Hauke Rahm]

On Wed, Jul 08, 2009 at 07:55:59PM +0200, Jakub Wilk wrote:
> * Jan Hauke Rahm , 2009-07-08, 19:36:
> >I'd like to have a new virtual package 'x-image-viewer'. All packages
> >providing that virtual package should be able to view images in common
> >formats (png, jpeg etc.). I'm thinking but that's pretty much all I can
> >say... It's obvious that I would want all image viewers to provide that
> >virtual package then.
> And such a package is needed because...?

...I'm working on a QA upload of xcftools which recommends basically all
x-image-viewers. It contains a program that is a wrapper script that
flattens an XCF image and displays it using an external PNG/PPM viewer.

I thought there might be more cases out there and thus started this
thread. If you all scream no, I'm fine with that, too. Just tell me :-P

Hauke


signature.asc
Description: Digital signature

Re: RFC: DEP-3: Patch Tagging Guidelines

[James Westby]

Guido Günther wrote:
> Which isn't a problem on patch-queue branches since you either can
> recreate them anytime from what's in debian/patches or simply ammend the
> commit. They're supposed to be rebased frequently anyway.

"Supposed"?

That's not true in my opinion. It would tend to be hostile to people who
would like to collaborate on the patches wouldn't it?

Thanks,

James


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#536270: ITP: boost-numeric-bindings -- Numeric Library Bindings for Boost

[Teemu Ikonen]

Package: wnpp
Severity: wishlist
Owner: Teemu Ikonen 

* Package name: boost-numeric-bindings
  Version : 20081116
  Upstream Author : Kresimir Fresl et. al.
* URL : http://mathema.tician.de/software/boost-bindings
  https://svn.boost.org/trac/boost/browser/sandbox/numeric_bindings-v1
* License : Boost Software License - Version 1.0
  Programming Lang: C++
  Description : Numeric Library Bindings for Boost

 Boost Bindings is a bindings library (not just) for Boost.Ublas.
 It offers an easy way of calling BLAS, LAPACK, UMFPACK, MUMPS
 and many other mature legacy numerical codes from within C++.

Preliminary packages are at
git://git.debian.org/debian-science/packages/boost-numeric-bindings.git



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New virtual package x-image-viewer?

[Steve Langasek]

On Wed, Jul 08, 2009 at 08:00:26PM +0200, Jan Hauke Rahm wrote:
> On Wed, Jul 08, 2009 at 07:55:59PM +0200, Jakub Wilk wrote:
> > * Jan Hauke Rahm , 2009-07-08, 19:36:
> > >I'd like to have a new virtual package 'x-image-viewer'. All packages
> > >providing that virtual package should be able to view images in common
> > >formats (png, jpeg etc.). I'm thinking but that's pretty much all I can
> > >say... It's obvious that I would want all image viewers to provide that
> > >virtual package then.
> > And such a package is needed because...?

> ...I'm working on a QA upload of xcftools which recommends basically all
> x-image-viewers. It contains a program that is a wrapper script that
> flattens an XCF image and displays it using an external PNG/PPM viewer.

> I thought there might be more cases out there and thus started this
> thread. If you all scream no, I'm fine with that, too. Just tell me :-P

How does xcftools actually invoke the external viewer?  Does it have a long
list of commands to try?

A virtual package only makes sense if it will also provide a standard
interface that other packages will invoke.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New virtual package x-image-viewer?

[Jan Hauke Rahm]

On Wed, Jul 08, 2009 at 11:45:27AM -0700, Steve Langasek wrote:
> On Wed, Jul 08, 2009 at 08:00:26PM +0200, Jan Hauke Rahm wrote:
> > On Wed, Jul 08, 2009 at 07:55:59PM +0200, Jakub Wilk wrote:
> > > * Jan Hauke Rahm , 2009-07-08, 19:36:
> > > >I'd like to have a new virtual package 'x-image-viewer'. All packages
> > > >providing that virtual package should be able to view images in common
> > > >formats (png, jpeg etc.). I'm thinking but that's pretty much all I can
> > > >say... It's obvious that I would want all image viewers to provide that
> > > >virtual package then.
> > > And such a package is needed because...?
> 
> > ...I'm working on a QA upload of xcftools which recommends basically all
> > x-image-viewers. It contains a program that is a wrapper script that
> > flattens an XCF image and displays it using an external PNG/PPM viewer.
> 
> > I thought there might be more cases out there and thus started this
> > thread. If you all scream no, I'm fine with that, too. Just tell me :-P
> 
> How does xcftools actually invoke the external viewer?  Does it have a long
> list of commands to try?

Basically

egrep '^image/(png|x-portable-pixmap)\s*;\s*((\S*).*?)\s*($|;.*)' /etc/mailcap

> A virtual package only makes sense if it will also provide a standard
> interface that other packages will invoke.

It doesn't have such, it just chooses one out the list provided by the
command above (it's actually perl but anyways).

Hauke


signature.asc
Description: Digital signature

Re: New virtual package x-image-viewer?

[Michael Banck]

On Wed, Jul 08, 2009 at 09:07:54PM +0200, Jan Hauke Rahm wrote:
> egrep '^image/(png|x-portable-pixmap)\s*;\s*((\S*).*?)\s*($|;.*)' /etc/mailcap
> 
> > A virtual package only makes sense if it will also provide a standard
> > interface that other packages will invoke.
> 
> It doesn't have such, it just chooses one out the list provided by the
> command above (it's actually perl but anyways).

Try "see", maybe.


Michael


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New virtual package x-image-viewer?

[Jan Hauke Rahm]

On Wed, Jul 08, 2009 at 09:12:30PM +0200, Michael Banck wrote:
> On Wed, Jul 08, 2009 at 09:07:54PM +0200, Jan Hauke Rahm wrote:
> > egrep '^image/(png|x-portable-pixmap)\s*;\s*((\S*).*?)\s*($|;.*)' 
> > /etc/mailcap
> > 
> > > A virtual package only makes sense if it will also provide a standard
> > > interface that other packages will invoke.
> > 
> > It doesn't have such, it just chooses one out the list provided by the
> > command above (it's actually perl but anyways).
> 
> Try "see", maybe.

That is without doubt a cool tool but mime-support doesn't provide any
image viewer. So my initial problem isn't solved: I need to somehow
recommend image-viewers. Having a tool to read /etc/mailcap is not
enough.

Hauke


signature.asc
Description: Digital signature

Re: New virtual package x-image-viewer?

[Steve Langasek]

On Wed, Jul 08, 2009 at 09:07:54PM +0200, Jan Hauke Rahm wrote:
> Basically

> egrep '^image/(png|x-portable-pixmap)\s*;\s*((\S*).*?)\s*($|;.*)' /etc/mailcap

> > A virtual package only makes sense if it will also provide a standard
> > interface that other packages will invoke.

> It doesn't have such, it just chooses one out the list provided by the
> command above (it's actually perl but anyways).

Well, a mailcap entry would qualify as such a standard interface - though
you ought to be using 'see' (or 'run-mailcap') instead of parsing the file
directly, indeed.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New virtual package x-image-viewer?

[Frank Lin PIAT]

On Wed, 2009-07-08 at 17:59 -0700, Steve Langasek wrote:
> On Wed, Jul 08, 2009 at 09:07:54PM +0200, Jan Hauke Rahm wrote:
> > Basically
> 
> > egrep '^image/(png|x-portable-pixmap)\s*;\s*((\S*).*?)\s*($|;.*)' 
> > /etc/mailcap
> 
> > > A virtual package only makes sense if it will also provide a standard
> > > interface that other packages will invoke.
> 
> > It doesn't have such, it just chooses one out the list provided by the
> > command above (it's actually perl but anyways).
> 
> Well, a mailcap entry would qualify as such a standard interface - though
> you ought to be using 'see' (or 'run-mailcap') instead of parsing the file
> directly, indeed.

Freedesktop has a similar tool (less portable than mailcap, but it's
database probably more accurate... for instance my mailcap isn't aware
of image/x-xcf files).

$apropos xdg-open 
> xdg-open (1)- opens a file or URL in the user's preferred application


$aptitude show  xdg-utils | awk /^Descr/,/^$/
> Description: desktop integration utilities from freedesktop.org
>  xdg-utils contains utilities for integrating applications with the
>  desktop environment, regardless of which desktop environment is used.
>  They are part of freedesktop.org's Portland project.
>  .
>  The following utilities are included:
>  .
>   * xdg-desktop-menu - Install desktop menu items
>   * xdg-desktop-icon - Install icons on the user's desktop
>   * xdg-icon-resource - Install icon resources
>   * xdg-mime - Gather MIME information about a file
>   * xdg-open - Open a URL in the user's preferred application that
>handles the respective URL or file type
>   * xdg-email - Open the user's preferred email client, potentially with
> subject and other info filled in
>   * xdg-screensaver - Enable, disable, or suspend the screensaver



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org