Bug#533872: ITP: sdop -- Simple DocBook Processor

[Andreas Metzler]

Package: wnpp
Severity: wishlist


* Package name: sdop
  Version : 0.52
  Upstream Author : Philip Hazel
* License : GPLv2+
  Programming Lang: C
  Description : Simple DocBook Processor

SDoP (Simple DocBook Processor) reads a DocBook XML file, processes it
into typeset pages, and outputs the result as PostScript (which can
easily be converted to a PDF). It is "simple" because it supports only
a subset of DocBook, and also because it does not make use of a DTD or
stylesheets or any other heavyweight apparatus. It is a single rogram.
SDoP is used to format the Exim reference manual.

cu andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'



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

Re: apt-get wrapper for maintaining Partial Mirrors

[Goswin von Brederlow]

Joseph Rawson  writes:

> On Saturday 20 June 2009 03:16:33 Goswin von Brederlow wrote:
>> But now you made me think about this too. So here is what I think:
>>
>> - My bandwidth at home is fast enough to fetch packages directly. No
>>   need to mirror at all.
>>
>> - I don't want to download a package multiple times (once per host) so
>>   some shared proxy would be good.
>>
> My idea would keep that from happening, at the expense of latency.  The 
> latency would be minimal, as it would just be dependant on reprepro 
> retrieving the package(s) and signalling the client that the package is 
> ready.  Using reprepro to add extra packages to the repository from upstream 
> without doing a full update may not be possible, but if it were, the latency 
> would certainly be minimum, and the bandwidth to the internet would also be 
> minimum.  I just looked at the manpage again, and this may be possible by 
> using the --nolistsdownload option with the update/checkupdate command.
>
>
>> - Bootstraping a chroot still benefits from local packages but a
>>   shared proxy would do there too.
>>
>> - When I'm not at home I might not have network access or only a slow
>>   one so then I need a mirror. And my parents computer has a Linux that
>>   only I use and that needs a major update every time I vistit.
>>
>> So the ideal setup would be an apt proxy that stores the packages in
>> the normal pool structure and has a simple command to create
>> Packages.gz, Sources.gz, Release and Release.gpg files so the cache
>> directory can be copied onto a USB disk and used as a repository of
>> its own.
>>
> Getting reprepro to do this would save a lot of the hassle, but getting 
> reprepro to act as an apt proxy is also tricky.  The current cache and proxy 
> methods in the apt-proxy and apt-cache packages don't work as well in making 
> a good repository, as opposed to reprepro.
>
> The Release could be signed using an rsign method with the machine(s) that 
> manage the repository, or it could be done locally on the server using 
> gpg-agent, or an unencrypted private key, depending on how the administrator 
> prefers to manage it.

The simplest implementation would be a tiny proxy applet that, when a
deb file is requested, checks if the file is in the local
archive. If it is then send it. If not then request file from
upstream and pipe it to apt (no latency) and a tempfile. When the
download has finished then reprepro --include suite deb. Doing the
same for source is a little more tricky as you needs the dsc and
related files as a group.

>> Optional the apt proxy could prefetch package versions but for me that
>> wouldn't be a high priority.
>>
>> Nice would be that it fetches sources along with binaries. When I find
>> a bug in some software while traveling I would hate to not have the
>> source available to fix it. But then it also needs to fetch
>> Build-depends and their depends. So that would complicate matters a
>> lot.
> I mentioned that part above.
>>
>> MfG
>> Goswin
>
> Overall, I think that reprepro does a good job of maintaining a local 
> repository, and we shouldn't reimplement what it does.  Reprepro also seems 
> flexible enough to implement most of the backend with simple commands and 
> options.  I've never tried to implement a new apt-method before, so I think 
> that would take a bit more research from me.

I totally agree that reprepro as the cache/storage backend would be
great use of existing software.

The problem I have with it being an apt method is that the apt method
runs on a different host than the reprepro. That would require ssh
logins from all participating clients or something to alter the
reprepro filter.

MfG
Goswin


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

Bug#533879: ITP: libstempel-java -- Universal algorithmic stemmer library

[Rail Aliev]

Package: wnpp
Severity: wishlist
Owner: Rail Aliev 


* Package name: libstempel-java
  Version : 1.0
  Upstream Author : Leo Galambos , Andrzej Bialecki 

* URL : http://www.getopt.org/stempel/
* License : Egothor Open Source License (Apache-style) and Apache 
License 2.0.
  Programming Lang: java
  Description : Universal algorithmic stemmer library

Stempel package consisting of high-quality stemming tables for Polish, and a
universal algorithmic stemmer, which operates using these tables. The stemmer
code is taken virtually unchanged from the Egothor project.



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

Bug#533882: ITP: libmorfologik-stemming-java -- Finite state automaton and stemming engine library

[Rail Aliev]

Package: wnpp
Owner: Rail Aliev 
Severity: wishlist

* Package name: libmorfologik-stemming-java
  Version : 1.1.4
  Upstream Author : Marcin Miłkowski , Dawid Weiss 

* URL : http://sourceforge.net/projects/morfologik
* License : BSD
  Programming Lang: Java
  Description : Finite state automaton and stemming engine library

Java based morfologik-stemming library provides the following fatures:
   - Finite state automaton traversal routines for Jan Daciuk's FSA package.
   - A stemming engine for the Polish language built on top of FSA traversal.
The library may be used for other languages as well.



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

Bug#533883: ITP: libjaminid-java -- Small and fast daemon for Java applications

[Rail Aliev]

Package: wnpp
Owner: Rail Aliev 
Severity: wishlist

* Package name: libjaminid-java
  Version : 0.99a
  Upstream Author : Constantinos Michael 
* URL : http://jaminid.sourceforge.net/
* License : LGPL
  Programming Lang: Java
  Description : Small and fast daemon for Java applications

 jaminid is a very small (and fast) daemon meant to embed in Java applications
 as an add-on HTTP interface.
 
 There are many advantages to using jaminid in your programs:
  * Couples the server as closely as possible to the application.
  * Can easily provide an elegant interface, in a style of programming that is
not at all harder than traditional console I/O.
  * May be used to attach a thin client interface to pre-existing applications
with ease.
  * Enables HTTP deployment without developing an HTTP daemon or knowledge of
the protocols.
  * The server can bundle with the application removing the need of a third
party server. This makes the application easier to distribute.
  * Does not require knowledge of any other scripting language.



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

Re: piuparts output wishlist?

[Jens Peter Secher]

2009/6/20 Lars Wirzenius :
>
> I'm thinking about changing the way piuparts outputs results. At the
> moment it outputs a log file that contains everything it does, and
> buried deep in that is the test results. This tends to work badly.
[...]
> How would _you_ like to see piuparts report results, and produce other
> output? Go wild, the sky is bright blue.

I: Reading database ... 5834 files and directories currently installed.
I: Removing bla bla ...
I: Purging bla bla ...
W: Suspicious action bla bla ...
E: dpkg: error processing ucf (--remove)
E: bla bla...

Alternatively

[I] Reading database ... 5834 files and directories currently installed.
[I] Removing bla bla ...
[I] Purging bla bla ...
[W] Suspicious action bla bla ...
[E] dpkg: error processing ucf (--remove)
[E] bla bla...


Cheers,
-- 
Jens Peter Secher.
_DD6A 05B0 174E BFB2 D4D9 B52E 0EE5 978A FE63 E8A1 jpsecher gmail com_.
A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?


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

What's wrong with meta-gnome2 ?

[Olivier Berger]

Hi.

http://release.debian.org/migration/testing.pl?package=meta-gnome2;expand=1 :

Why is package X not in testing yet?
Checking meta-gnome2
trying to update meta-gnome2 from 1:2.24.3~2 to 1:2.24.3~3 (candidate 
is 11 days old) 
Updating meta-gnome2 makes 1 non-depending packages uninstallable on 
i386: gnome-desktop-environment 
binary package gnome-desktop-environment is part of 
source package meta-gnome2 (explained above)

Uh... it's blocking itself ?

Maybe I'm not getting the point here, or there's something broken...

Hope this helps,
-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 1024D/6B829EEC
Ingénieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)


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

Bug#534048: ITP: libsegment-java -- Rule based text splitting library

[Rail Aliev]

Package: wnpp
Owner: Rail Aliev 
Severity: wishlist

* Package name: libsegment-java
  Version : 1.2.1
  Upstream Author : Jarek Lipski 
* URL : http://segment.sourceforge.net/
* License : MIT
  Programming Lang: Java
  Description : Rule based text splitting library

Segment library is used to split text into segments, for example sentences.
Splitting rules are read from SRX file, which is standard format for this
task.



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

Re: Bug#533838: ITP: rabbitsign -- free implementation of TI's application signing system

[brian m. carlson]

[Reformatted due to excessively long lines.]

On Sat, Jun 20, 2009 at 09:09:17PM +0200, Krzysztof Burghardt wrote:
>  It handles binary, sorted and unsorted hex, and GraphLink files,
>  automatically detects keys, checks the validity of important header
>  fields, can validate and re-sign previously signed apps, accepts all
>  valid keys, is highly portable, has no stupid limitations on file
>  names, application lengths, or header fields, is faster by an order
>  of magnitude than TI's software, and perhaps most importantly - it is
>  free software.

I don't think that you need to mention that it is free software.  If it
is in main or contrib, that can be safely assumed.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

BTS and the missing 'invalid' tag

[Tiago Bortoletto Vaz]

Hi,

#531002 made me bring this to -devel. It seems Debian BTS fails in not offering
an 'invalid' or 'notabug' tag for cases which are not covered by 'wontfix' [0].
I've found the following discussions about this issue:

http://bugs.debian.org/227511
http://bugs.debian.org/376594
http://lists.debian.org/debian-devel/2006/11/msg01091.html
http://lists.debian.org/debian-devel/2006/04/msg00793.html
http://lists.debian.org/debian-devel/2008/02/msg00863.html (just a comment)

For me it doesn't make sense to mark something as "I will not fix" if actually
there's nothing to fix. I'm curious to know how other maintainers have
addressed such cases in BTS.

Also, I don't think usertag covers this need. It's not a standard, and I guess*
'invalid' situations are so common which should deserve something more
consistent (useful for statistics, searches/filters etc).

We know other very popular bug tracking systems offer a standard way to deal
with bugs which are not in fact bugs. Surely it's not a reason to implement
this in BTS; on the other hand, Debian development is not that different from
other large free software projects. So we can at least consider they've got a
reason to offer this feature (the same reason *I* see for Debian).

* No, I don't have a proof as asked in #376594, that's the reason I would like
to know other's opinions here.

[0] http://www.debian.org/Bugs/Developer#tags

-- 
Tiago Bortoletto Vaz
http://tiagovaz.org
0xA504FECA - http://pgp.mit.edu


signature.asc
Description: Digital signature

Re: BTS and the missing 'invalid' tag

[Neil Williams]

On Sun, 21 Jun 2009 13:24:48 -0300
Tiago Bortoletto Vaz  wrote:

> #531002 made me bring this to -devel. It seems Debian BTS fails in
> #not offering
> an 'invalid' or 'notabug' tag for cases which are not covered by
> 'wontfix' [0]. I've found the following discussions about this issue:

Just put a comment in the message to $number-d...@bugs.debian.org that
you're closing the bug as invalid. Closing doesn't mean that the bug
has been accepted as valid. (That can be done with confirmed.)

> For me it doesn't make sense to mark something as "I will not fix" if
> actually there's nothing to fix. I'm curious to know how other
> maintainers have addressed such cases in BTS.

Nothing to fix? close the bug. I don't see we need two different ways
to close a bug. Invalid would still close the bug.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/



pgp5ODKOM1qrI.pgp
Description: PGP signature

Re: Bug#533872: ITP: sdop -- Simple DocBook Processor

[Hendrik Sattler]

Am Sonntag 21 Juni 2009 10:05:34 schrieb Andreas Metzler:
> Package: wnpp
> Severity: wishlist
>
>
> * Package name: sdop
>   Version : 0.52
>   Upstream Author : Philip Hazel
> * License : GPLv2+
>   Programming Lang: C
>   Description : Simple DocBook Processor
>
> SDoP (Simple DocBook Processor) reads a DocBook XML file, processes it
> into typeset pages, and outputs the result as PostScript (which can
> easily be converted to a PDF). It is "simple" because it supports only
> a subset of DocBook, and also because it does not make use of a DTD or
> stylesheets or any other heavyweight apparatus. It is a single rogram.
> SDoP is used to format the Exim reference manual.

Which DocBook version?
Is the "subset" standardized somwehere?
Has the program a webpage?

HS


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

Re: RFC: DEP-3: Patch Tagging Guidelines

[Raphael Geissert]

Raphael Hertzog wrote:

> On Sat, 20 Jun 2009, Raphael Geissert wrote:
>> All I see here is that the tools should be able to extract the
>> information from the changelog, which often includes a bug number and
>> other bits of information.
> 
> I would say the opposite. Once you have created your patch you should be
> able to do ˝dch -a --patch debian/patches/fix_typo.patch” and it would
> create the changelog entry for you.

(not that I use dch very often, but) okay, I see your point.

> 
> Converting structured content in non-structured content is easy, the
> opposite is more difficult.

But not impossible, this has been done before and I guess it will happen
again in the future :)

Back to the DEP...
> Description (required)
Why not simply consider all the free-form text the description? that would
make all the current patches with a comment insta DEP3-compliant.

> Origin (required)
Making this field mandatory doesn't sound like a good idea to me, as it
already clashes a bit with the forwarded and author fields. If the Origin
is upstream, then it doesn't need to be forwarded; and it doesn't cope very
well with the idea of patches by some John Doe user.

> Bug- or Bug (optional)
Like Paul Wise already said: it would be better to have a single field where
the urls to the bug trackers can be specified. It doesn't only make it
easier to find the final url, but it also requires zero extra
maintenance/updates on the parsing tools just to know about another bug
tracker.

Regarding other posts:
> > > +expected that tools like lintian will be modified to recommend adding
> > > +those information in patches. As the technical impact on package is
null,
> > 
> > Please do not decrease the usability of lintian even further. In linitan
> > speak, this should be a "pedantic" tag at most.
> 
> I will leave that up to lintian maintainers.

Although strictly speaking I'm not a "lintian maintainer", am the person who
implemented it. In this case I'd say it should be severity: wishlist,
pedantic is for things that are nice/better, but don't provide much or any
benefit.
It is as simple as: would you file a report to ask the maintainer to use the
DEP3 format? I'd say yes, because it provides the following benefits:
better structured documentation, allows automated tools to parse it and
<...>
Would you file a report to ask the maintainer to remove the CVS directories
from upstream's tarball? I'd say no, what benefit does it provide? none.

Cheers,
Raphael Geissert



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

Re: BTS and the missing 'invalid' tag

[Tiago Bortoletto Vaz]

On Sun, Jun 21, 2009 at 05:45:24PM +0100, Neil Williams wrote:
> On Sun, 21 Jun 2009 13:24:48 -0300
> Tiago Bortoletto Vaz  wrote:
> 
> > #531002 made me bring this to -devel. It seems Debian BTS fails in
> > #not offering
> > an 'invalid' or 'notabug' tag for cases which are not covered by
> > 'wontfix' [0]. I've found the following discussions about this issue:
> 
> Just put a comment in the message to $number-d...@bugs.debian.org that
> you're closing the bug as invalid. Closing doesn't mean that the bug
> has been accepted as valid. (That can be done with confirmed.)

This could be used for 'wontfix' as well, so why do we need these tags once we
can comment every situation? The thing is I consider important for a BTS making
difference between what is an accepted (valid) bug and what is not after it is
closed. Ok, you're right, this can be done with 'confirmed', but I'm not sure
it would cover everything 'invalid' would cover (thinking).

> > For me it doesn't make sense to mark something as "I will not fix" if
> > actually there's nothing to fix. I'm curious to know how other
> > maintainers have addressed such cases in BTS.
> 
> Nothing to fix? close the bug. I don't see we need two different ways
> to close a bug. Invalid would still close the bug.

No, it's not about two different ways to close a bug. It's about a standard
(extra) info which will be saved for future references, like 'wontifx' and
others tags do.

Regards,

-- 
Tiago Bortoletto Vaz
http://tiagovaz.org
0xA504FECA - http://pgp.mit.edu


signature.asc
Description: Digital signature

Re: BTS and the missing 'invalid' tag

[Neil Williams]

On Sun, 21 Jun 2009 14:05:09 -0300
Tiago Bortoletto Vaz  wrote:

> On Sun, Jun 21, 2009 at 05:45:24PM +0100, Neil Williams wrote:
> > On Sun, 21 Jun 2009 13:24:48 -0300
> > Tiago Bortoletto Vaz  wrote:
> > 
> > > #531002 made me bring this to -devel. It seems Debian BTS fails in
> > > #not offering
> > > an 'invalid' or 'notabug' tag for cases which are not covered by
> > > 'wontfix' [0]. I've found the following discussions about this
> > > issue:
> > 
> > Just put a comment in the message to $number-d...@bugs.debian.org
> > that you're closing the bug as invalid. Closing doesn't mean that
> > the bug has been accepted as valid. (That can be done with
> > confirmed.)
> 
> This could be used for 'wontfix' as well, so why do we need these
> tags once we can comment every situation?

wontfix does not close the bug - although maintainers differ on
whether a wontfix bug ever gets closed.

> The thing is I consider
> important for a BTS making difference between what is an accepted
> (valid) bug and what is not after it is closed. Ok, you're right,
> this can be done with 'confirmed', but I'm not sure it would cover
> everything 'invalid' would cover (thinking).

Any others can be covered within the comment.

> > Nothing to fix? close the bug. I don't see we need two different
> > ways to close a bug. Invalid would still close the bug.
> 
> No, it's not about two different ways to close a bug. 

Which is precisely what I don't think we need. There is no difference
between "invalid" and "this is an invalid bug, closing". I'm sure a
small shell script could generate a suitable command to bts to put the
longer string in if you really want it. The bug still needs to closed
with $number-d...@b.d.o.

As far as the BTS is concerned, a bug is either open or closed. I don't
see that there is a need for a third category. FTR, I think bugzilla
have got this wrong because, by distinguishing between CLOSED and FIXED
bugs, the need for INVALID becomes obvious. Closed in the BTS does not
have to mean FIXED in bugzilla speak, it just means closed - the problem
has been dealt with, to quote the BTS. Dealing with the problem doesn't
have to mean fixing it, it can mean telling the reporter that no such
problem ever actually existed.

Once you distinguish between 'closed' and 'fixed', 'invalid' becomes
redundant IMHO.

> It's about a
> standard (extra) info which will be saved for future references, like
> 'wontifx' and others tags do.

The bug comment is always available.

I've nothing a new invalid tag in the BTS per-se as long as it does
*not* close the bug report, although that is not a particular
improvement AFAICT over a combination of wontfix, unreproducible and
moreinfo.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/



pgpo9ZkQTuvAQ.pgp
Description: PGP signature

Re: BTS and the missing 'invalid' tag

[Don Armstrong]

On Sun, 21 Jun 2009, Tiago Bortoletto Vaz wrote:
> Also, I don't think usertag covers this need. It's not a standard,
> and I guess* 'invalid' situations are so common which should deserve
> something more consistent (useful for statistics, searches/filters
> etc).

In order for me to bother to add another tag,[1] people need to
demonstrate repeated use of the tag as a usertag along with a specific
rationale to go along with the tag. Further discussion is perfectly
fine, but I'm personally much more convinced by action.


Don Armstrong

1: At least, for tags that I'm not immediately convinced of their
utility, anyway.

-- 
It seems intuitively obvious to me, which means that it might be wrong
 -- Chris Torek

http://www.donarmstrong.com  http://rzlab.ucr.edu


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

Re: BTS and the missing 'invalid' tag

[Michael Banck]

On Sun, Jun 21, 2009 at 06:32:10PM +0100, Neil Williams wrote:
> Which is precisely what I don't think we need. There is no difference
> between "invalid" and "this is an invalid bug, closing". 

Of course there is.  After the closed bug got archived, it's no longer
displayed by default for a bug search.  So chances are that the next
user encountering this non-bug will file it again.  Keeping the bug open
as "invalid" might make it more prominent to users that there is
actually no bug to file.

I am not saying "invalid" should be introduced, just why somebody might
want to use it and what the difference to closing it is.


Michael


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

Re: Bug#533872: ITP: sdop -- Simple DocBook Processor

[Hendrik Sattler]

Am Sonntag 21 Juni 2009 20:32:07 schrieb Andreas Metzler:
> On 2009-06-21 Hendrik Sattler  wrote:
> > Am Sonntag 21 Juni 2009 10:05:34 schrieb Andreas Metzler:
> > > * Package name: sdop
> > >   Version : 0.52
> > >   Upstream Author : Philip Hazel
> > > * License : GPLv2+
> > >   Programming Lang: C
> > >   Description : Simple DocBook Processor
> > >
> > > SDoP (Simple DocBook Processor) reads a DocBook XML file, processes it
> > > into typeset pages, and outputs the result as PostScript (which can
> > > easily be converted to a PDF). It is "simple" because it supports only
> > > a subset of DocBook, and also because it does not make use of a DTD or
> > > stylesheets or any other heavyweight apparatus. It is a single rogram.
> > > SDoP is used to format the Exim reference manual.
> >
> > Which DocBook version?
> >
> > Is the "subset" standardized somwehere?
>
> According to the documentation: "Support for almost all the elements
> that are part of Simplified DocBook, as defined in the following URL:
>  
> http://docs.linux.cz/programming/markup/www.docbook.org/tdg/simple/en/html/
>sdocbook.html The main omissions are support for bibliographies, multiple
> authors, subtables within tables, and some element attributes. Chapter 7
> below contains a complete list of what SDoP does support."

That looks like http://www.docbook.org/schemas/sdocbook/ should fit the 
document. So maybe you want to mention the exact name "Simplified Docbook", 
maybe even the supported Version of that standard.
That would make it possible to use it as alternative to xsltproc/saxon/xalan 
and fop for such cases.

HS


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

Re: BTS and the missing 'invalid' tag

[Bart Martens]

On Sun, Jun 21, 2009 at 01:24:48PM -0300, Tiago Bortoletto Vaz wrote:
> (...)  It seems Debian BTS fails in not offering
> an 'invalid' or 'notabug' tag for cases which are not covered by 'wontfix' 
> [0].
> (...)
> For me it doesn't make sense to mark something as "I will not fix" if actually
> there's nothing to fix.

+1

> I'm curious to know how other maintainers have
> addressed such cases in BTS.

A workarond is using the tag "wontfix" combined with retitling the bug to
something general like "confusion about foo doing bar".

Regards,

Bart Martens


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

Re: piuparts output wishlist?

[Russ Allbery]

Jens Peter Secher  writes:
> 2009/6/20 Lars Wirzenius :
>>
>> I'm thinking about changing the way piuparts outputs results. At the
>> moment it outputs a log file that contains everything it does, and
>> buried deep in that is the test results. This tends to work badly.
> [...]
>> How would _you_ like to see piuparts report results, and produce other
>> output? Go wild, the sky is bright blue.
>
> I: Reading database ... 5834 files and directories currently installed.
> I: Removing bla bla ...
> I: Purging bla bla ...
> W: Suspicious action bla bla ...
> E: dpkg: error processing ucf (--remove)
> E: bla bla...

Lintian uses N: for informational messages that don't represent
problems.  That's not any kind of standard, of course, but it might be
worth copying it.

-- 
Russ Allbery (r...@debian.org)   


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

Re: Bug#533872: ITP: sdop -- Simple DocBook Processor

[Andreas Metzler]

On 2009-06-21 Hendrik Sattler  wrote:
> Am Sonntag 21 Juni 2009 10:05:34 schrieb Andreas Metzler:
> > * Package name: sdop
> >   Version : 0.52
> >   Upstream Author : Philip Hazel
> > * License : GPLv2+
> >   Programming Lang: C
> >   Description : Simple DocBook Processor
> >
> > SDoP (Simple DocBook Processor) reads a DocBook XML file, processes it
> > into typeset pages, and outputs the result as PostScript (which can
> > easily be converted to a PDF). It is "simple" because it supports only
> > a subset of DocBook, and also because it does not make use of a DTD or
> > stylesheets or any other heavyweight apparatus. It is a single rogram.
> > SDoP is used to format the Exim reference manual.

> Which DocBook version?

> Is the "subset" standardized somwehere?

According to the documentation: "Support for almost all the elements
that are part of Simplified DocBook, as defined in the following URL:
  
http://docs.linux.cz/programming/markup/www.docbook.org/tdg/simple/en/html/sdocbook.html
The main omissions are support for bibliographies, multiple authors,
subtables within tables, and some element attributes. Chapter 7 below
contains a complete list of what SDoP does support."

> Has the program a webpage?

No, just a freshmeat entry and a download location.

For clarity's sake this is primarily intersting for me since sdop and
xfpt are the canonical (and fastest) way for building exim's
documentation.

cu andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


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

cc vs gcc

[Peter Eisentraut]

There is a bit of discussion in bug #487546 about whether using cc or gcc as 
the compiler is appropriate.

Particular questions:

* Are Debian packages supposed to be built by default using /usr/bin/gcc (or 
whatever gcc is first in the path)?  Or is it valid to use cc?

* What interface is the "cc" alternative offering?  Is it a GCC-compatible 
compiler, or a POSIX/SUS-compatible compiler?

Currently, packages using cdbs will usually end up using CC=cc as their 
compiler, which is typically gcc, but doesn't have to.  The submitter of the 
bug isn't really telling what exactly he is doing, but I guess it's 
conceivable to have another compiler than gcc in use, at least unless there is 
a ruling to the contrary on the above questions.

Comments?


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

Re: cc vs gcc

[brian m. carlson]

On Sun, Jun 21, 2009 at 10:29:37PM +0300, Peter Eisentraut wrote:
> There is a bit of discussion in bug #487546 about whether using cc or gcc as 
> the compiler is appropriate.
> 
> Particular questions:
> 
> * Are Debian packages supposed to be built by default using /usr/bin/gcc (or 
> whatever gcc is first in the path)?  Or is it valid to use cc?

cc has traditionally been the system-default compiler for a Unix system.
Generally, it will support those options specified by POSIX for c99,
since those are a fairly barebones set of options, but it is not
mandated to (since it is not specified).

Since Debian has it specified as an alternative, I would assume that any
C compiler which implements those options would be satisfactory.
Whether cc is a valid choice depends on whether the code will work with
any such compiler.  If a program requires GCC, then it should specify
gcc; if any old compiler will work, then cc should be fine.

> * What interface is the "cc" alternative offering?  Is it a GCC-compatible 
> compiler, or a POSIX/SUS-compatible compiler?

If you want a POSIX-compatible compiler, then you need to use c99;
that's the interface that POSIX mandates.  I would assume that all C
compilers used for cc will at least support C89/C90 and the POSIX
options, since, as I said before, those are a very minimal set of
options.

Also note that POSIX specifies that "the -W (capital-W) option shall be
reserved for vendor options."

> Currently, packages using cdbs will usually end up using CC=cc as their 
> compiler, which is typically gcc, but doesn't have to.  The submitter of the 
> bug isn't really telling what exactly he is doing, but I guess it's 
> a ruling to the contrary on the above questions.

I would consider it a bug if a package that specified CC=cc (whether
intentionally or unintentionally) failed to build with a non-GCC
compiler.  I think the matter is really a package-specific matter.

I see it much like the /bin/sh issue: if a script requires bash, it
should specify bash.  If any /bin/sh will do, then /bin/sh is fine.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Bug#534125: ITP: latex2mathml -- LaTeX2MathML is a php5 written program which converts LaTeX math formulas to MathML presentation markup.

[Jeremy Oden]

Package: wnpp
Severity: wishlist
Owner: Jeremy Oden 


* Package name: latex2mathml
  Version : 0.1.0
  Upstream Author : Jeremy Oden 
* URL : https://sourceforge.net/projects/latex2mathml/
* License : BSD
  Programming Lang: PHP5
  Description : LaTeX2MathML is a php5 written program which converts LaTeX 
math formulas to MathML presentation markup.

 latex2mathml is a powerful php5 class that can be used to 
 convert LaTeX math formulas to Presentation MathML
 .
 This program can be used as command line, using php5-cli
 .



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

Re: BTS and the missing 'invalid' tag

[Ben Finney]

Neil Williams  writes:

> Which is precisely what I don't think we need. There is no difference
> between "invalid" [as a standard tag] and "this is an invalid bug,
> closing" [in a message on the report].

Adding my clarifications above to show that there clearly is a
difference: the proposal is that this semantic meaning can be indicated
through a standard ‘invalid’ tag with a defined meaning, like ‘wontfix’
and ‘unreproducible’, so automated tools can know about it.

-- 
 \“I installed a skylight in my apartment. The people who live |
  `\ above me are furious!” —Steven Wright |
_o__)  |
Ben Finney


pgpeNbmr3kXlQ.pgp
Description: PGP signature

Re: What's wrong with meta-gnome2 ?

[Aaron M. Ucko]

[Copying the original poster because I'm not certain he's subscribed;
apologies for any resulting duplication.]

Olivier Berger  writes:

> Updating meta-gnome2 makes 1 non-depending packages uninstallable on 
> i386: gnome-desktop-environment 
> binary package gnome-desktop-environment is part of 
> source package meta-gnome2 (explained above)

I agree that this message is not as clear as it could be.  In
practice, I believe the reason for the delay is that
gnome-desktop-environment has recently gained a conflict against
gstreamer0.10-gnomevfs, which is however still a dependency of several
packages.  Not all of these are necessarily problematic, but one
certainly is: gnome-dbg (which also comes from meta-gnome2) depends on
gstreamer0.10-plugins-base-dbg (from gst-plugins-base0.10), which
historically depended on gstreamer0.10-gnomevfs.  Version 0.10.23-3
has downgraded that to a suggestion, but only showed up as a
low-priority upload on June 17, so as things stand I wouldn't expect
the new meta-gnome2 to hit testing until at least the 27th.

See also http://bugs.debian.org/532469 .

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?...@monk.mit.edu


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

Re: What's wrong with meta-gnome2 ?

[Cyril Brulebois]

Aaron M. Ucko  (21/06/2009):
> [Copying the original poster because I'm not certain he's subscribed;
> apologies for any resulting duplication.]

[AFAICT, he is, since he replied in some threads previously. ;)]
> I agree that this message is not as clear as it could be.  In
> practice, I believe the reason for the delay is that
> gnome-desktop-environment has recently gained a conflict against
> gstreamer0.10-gnomevfs, which is however still a dependency of several
> packages.  Not all of these are necessarily problematic, but one
> certainly is: gnome-dbg (which also comes from meta-gnome2) depends on
> gstreamer0.10-plugins-base-dbg (from gst-plugins-base0.10), which
> historically depended on gstreamer0.10-gnomevfs.  Version 0.10.23-3
> has downgraded that to a suggestion, but only showed up as a
> low-priority upload on June 17, so as things stand I wouldn't expect
> the new meta-gnome2 to hit testing until at least the 27th.
> 
> See also http://bugs.debian.org/532469 .

Following Joss's mail to -release@, the following answer came:
http://lists.debian.org/debian-release/2009/06/msg00216.html

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#534144: ITP: opencore-amr -- libraries for Adaptive Multi Rate (AMR) OpenCORE implementation

[Andres Mejia]

Package: wnpp
Severity: wishlist
Owner: Andres Mejia 

* Package name: opencore-amr
  Version : 0.1.1
  Upstream Maintainer : Andres Mejia 
* URL : http://opencore-amr.sourceforge.net/
* License : Apache 2.0
  Programming Lang: C, C++
  Description : libraries for Adaptive Multi Rate (AMR) OpenCORE
implementation

This library contains an implementation of the 3GPP TS 26.073 specification for
the Adaptive Multi Rate (AMR) speech codec and an implementation of the 3GPP TS
26.173 specification for the Adaptive Multi-Rate - Wideband (AMR-WB) speech
decoder. The implementation is derived from the OpenCORE framework, part of the
Google Android project.



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

Lintian magic-arch-in-arch-list

[Shaun Jackman]

I have a source package with two binary packages. One binary package
is arch i386 amd64, the other is arch all containing the
architecture-independent data files. The resulting dsc file is
Architecture: amd64 i386 all
which lintan complains about:
E: eagle source: magic-arch-in-arch-list

I'm guessing that the architecture line should omit all:
Architecture: amd64 i386

What's gone wrong here?

I'm using
dpkg-dev 1.15.2
devscripts 2.10.50
debhelper 7.2.14
lintian 2.2.10

Please cc me in your reply. Thanks,
Shaun


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