Taking over different packages with a single source package

[韓達耐]

Hi list!

I'm nearly finished with my /magnum opus/, latex-cjk (a LaTeX macro
that allows you to insert Chinese, Japanese, Korean, Thai and
Vietnamese text in a LaTeX document), which you can find at

  deb http://chinese.alioth.debian.org latex-cjk/
  deb-src http://chinese.alioth.debian.org latex-cjk/

I only need to (re)package some bitmap fonts (which is not necessary
to run the packages since I also provide better-quality Type1 fonts,
but is nice to have, esp. for CNS).
These fonts can be found at ftp://ctan.tug.org/tex-archive/fonts/CJK/.

The thing is that Anthony Fok has already packaged a few of these
fonts (hbf-cns40-[1-7], hbf-cns40-b5, hbf-jfs56 and hbf-kanji48), each
with their own changelog (having only two or three entries each
though) and with their own Debian source package.

I find it too bothersome and clumsy to have a source package for each
and every font, so I would like to use only 1.  Debian lacks the
Korean (han*.tar.gz), another Japanese (jisksp40.tar.gz) and a Chinese
font (ntukai48.tar.gz) anyway.

My questions: 
 - What to do about the old changelogs if I want to use a single
   Debian source for all packages?
 - Do I just put dummy entries in the changelog up to version 1.0.4?
 - Do I put the content of the old changelogs altogether in one
   changelog entry?
 - What about the name of the Debian source packages ("hbf-cns40-1",
   "hbf-jfs56", etc. in comparison with the new source package
   "hbf-fonts")?
 - Should I put the old packages on the "Replace:" line?  Or even set
   "Conflicts: hbf-foo1 (<=1.0.3), hbf-foo2 (<=1.0.2), etc."?

FWIW:
The new Debian source package "hbf-fonts" will be a repackaged tarball
containing all the .tar.gz files from above FTP site.  debian/rules
will automatically remove prior build directories and extract all
these packages.

Thank you for your advice.


Kind regards


Danai SAE-HAN
韓達耐

-- 
题目:《书愤》
作者:陆游（１１２５－１２１０）

早岁那知世事艰，中垢北望气如山。
楼船夜雪瓜洲渡，铁马秋风大散关。
塞上长城空自许，镜中衰鬓已先斑。
出师一表真名世，千载谁堪伯仲间。


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

RFS: gmysqlcc -- GTK+ client for mysql databases

[Carlos C Soto]

Package name: gmysqlcc
Version : 0.2.5-1
ITP : 344594
URL or Web page : http://gmysqlcc.thepozer.org/
License : GPL
Description : GTK+ client for mysql databases
It will help you to use your MySQL servers, do requests on them, manage 
their configuration (users, process, etc.), dump datas and structure and 
more.


About gmysqlcc:
 gmysqlcc is a very nice application based on gtk+ for use mysql
 databases, this version also can manage the mysql users.
 Interesting features include:
 * Edit value directly in the result's table
 * Dump SQL table|database|serveur|request into SQL, XML and CSV files
 * Translation (via locales) to french and spanish

Personal repository with packages:
 - deb http://eclipxe.com.mx/debian/ ./
 - http://eclipxe.com.mx/debian/gmysqlcc/

Sponsors site:
 - http://sponsors.debian.net/viewpkg.php?id=162

I hope this package could be on unstable

Carlos C Soto :: eclipxe


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

Re: RFS: libjavascript-rpc-perl -- Perl module to process Remote procedure

[Russ Allbery]

Jonas Genannt <[EMAIL PROTECTED]> writes:

> Ok, this is I think an better solution.

> I have updated the packages:
> http://jonas.capi2name.de/debian-upload/libjavascript-rpc-perl/

> (I have make a comment in the debian/copyright, that I have renamed and
> repackaged it)

> So, now I need someone how could sponsor my package.

The package looks fine, except that you didn't need to repackage the
upstream source.  The package build tools don't care in the slightest what
directory the upstream source unpacks into; they just care that the tar.gz
file be named appropriately.  So you should be able to just rename the
tar.gz with the appropriate version and everything should be happy.

If you could rebuild the package with the virgin upstream tarball, I'd be
happy to sponsor it.  (While you're rebuilding it, you may want to fix the
last two changelog entries -- I think you meant debian/copyright as the
file modified, not debian/changelog.)

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: RFS vamps (ITP #320067)

[Claudio Moratti]

On Friday 23 December 2005 21:01, Stephen Gran wrote:
> This one time, at band camp, Claudio Moratti said:
> > Hi *!
> > I'm looking for a sponsor for vamps package:
[cut]
> > The package (lintian errors free) is available here:
> > http://www.knio.it/debian/vamps/
>
> My first impresion is that it looks quite good.  On reading the
> play_cell manpage, I am not quite clear on what it does, but at least
> you have written manpages for both binaries.
Play_cell plays a single cell, selected by parameters "vts pgc cell"...
I'll write this in the next version of vamps package (after 4/01/2006)


> If no one else has stepped forward, I should be able to upload this
> tomorrow(ish) - tonight I just don't have time to properly QA it, but I
> don't see any issues on my first run through.
Thx you for your interest!!!

> Thanks,
Cheers,
 Claudio

-- 
   ~~>MaXeR <~~
Home: http://www.knio.it
Community http://www.debianizzati.org - http://guide.debianizzati.org
GnuPG Key: 0x34337C08


pgph4VYGvLEIQ.pgp
Description: PGP signature

Re: RFS vamps (ITP #320067)

[Claudio Moratti]

On Friday 23 December 2005 20:57, Neil McGovern wrote:
> On Fri, Dec 23, 2005 at 12:36:41AM +0100, Claudio Moratti wrote:
> > Hi *!
> > I'm looking for a sponsor for vamps package:
>
> Hi there,
>
> Thanks for packaging this, uploaded :)
Thx a lot!

> Neil
Cheers,
 Claudio


-- 
   ~~>MaXeR <~~
Home: http://www.knio.it
Community http://www.debianizzati.org - http://guide.debianizzati.org
GnuPG Key: 0x34337C08


pgpIRTc33EBf2.pgp
Description: PGP signature

Re: Lintian error about missing debconf dependency (which is not missing)

[Michael Hanke]

Hi!

On Fri, Dec 23, 2005 at 12:37:20PM +0100, Joost van Baal wrote:
> Op vr 23 dec 2005 om 02:31:16 -0800 schreef Steve Langasek:
> > 
> > I don't know what minimum version of cdebconf (if any) you should specify to
> > get support for settitle.
> 
> From the changelog:
> 
>  cdebconf  (0.43)
>   "Add new command SETTITLE"
Thanks.

I added cdebconf (>= 0.43) as an alternative to the debconf dependency.
Now, all should be fine -- lintian is.

Cheers,

Michael




-- 
GPG key:  1024D/3144BE0F Michael Hanke
http://apsy.gse.uni-magdeburg.de/hanke
ICQ: 48230050


signature.asc
Description: Digital signature

Re: RFS vamps (ITP #320067)

[Stephen Gran]

This one time, at band camp, Neil McGovern said:
> On Fri, Dec 23, 2005 at 12:36:41AM +0100, Claudio Moratti wrote:
> > Hi *!
> > I'm looking for a sponsor for vamps package:
> > 
> 
> Hi there,
> 
> Thanks for packaging this, uploaded :)

Hrm, beat me to it :)

Thanks again,
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: RFS vamps (ITP #320067)

[Stephen Gran]

This one time, at band camp, Claudio Moratti said:
> Hi *!
> I'm looking for a sponsor for vamps package:
> 
> --
> Package: vamps
> Section: graphics
> License: GPL
> Description: Tool to recompress and modify the structure of a DVD
>  Vamps reduces the size of DVD compliant MPEG2 program streams by
>  selectively copying audio and subpicture tracks and by resizing
>  the embedded elementary video stream.
>  The shrink factor may be either specified for the video elementary
>  stream only or for the video ES only or for the full PS.
>  .
>  http://sourceforge.net/projects/vamps/
> --
> 
> The package (lintian errors free) is available here:
> http://www.knio.it/debian/vamps/

My first impresion is that it looks quite good.  On reading the
play_cell manpage, I am not quite clear on what it does, but at least
you have written manpages for both binaries.

If no one else has stepped forward, I should be able to upload this
tomorrow(ish) - tonight I just don't have time to properly QA it, but I
don't see any issues on my first run through.

Thanks,
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: RFS vamps (ITP #320067)

[Neil McGovern]

On Fri, Dec 23, 2005 at 12:36:41AM +0100, Claudio Moratti wrote:
> Hi *!
> I'm looking for a sponsor for vamps package:
> 

Hi there,

Thanks for packaging this, uploaded :)

Neil
-- 
   __   
 .`  `. [EMAIL PROTECTED] | Application Manager
 : :' !  | Secure-Testing Team member
 '. `-  gpg: B345BDD3| Webapps Team member
   `-   Please don't cc, I'm subscribed to the list


signature.asc
Description: Digital signature

Re: Lintian error about missing debconf dependency (which is not missing)

[Joey Hess]

Russ Allbery wrote:
> I hate to say this, since actually implementing it is a lot of work in
> supporting programs like debhelper, but if the debconf-2.0 pseudopackage
> was introduced prior to a new feature in the debconf interface there needs
> to be a debconf-2.1 or debconf-3.0 as well.  If cdebconf implements that
> protocol, it can provide that pseudopackage as well.

Any later version 2.x of the debconf protocol is intended to be backwards
compatible with 2.0. In practice, new commands such as SETTITLE and the
PROGRESS stuff can be added to the protocol without increasing the
version number since earlier versions of debconf can skip doing anything
for these commands with no undue effects (although if you want this to
work, you'll need to || true your db_settitle commands in a shell
script). The CAPB interface also allows for larger change to the protocol
without increasing the version number.

I wouldn't object to a version 2.1 being added to the protocol, but
getting anything into the policy manual has become to much of a pain for
me to bother with myself.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Bug#321808: ping of ITA ecb

[Zak B. Elep]

On 12/23/05, Javier Ballesteros <[EMAIL PROTECTED]> wrote:
> Hi!
>
>   I'm interesting in adopting this package or help to get this package
> out from orphaned packages. I'm trying to adopt as much packages I
> can, and it seems that this package is still orphaned, so please let
> me know if I can help or I can be Co-Manteiner. Maybe I can get a
> sponsor to upload the package.

Actually, all I really need is a sponsor to check ECB and upload it to
the archive.  The newest upstream is already packaged[1] , but I'd
like your comment.

[1]  http://zakame.spunge.org/pub/debian/ecb/

Cheers,

Zakame

--
Zak B. Elep  ||  http://zakame.spunge.org
[EMAIL PROTECTED]  ||  [EMAIL PROTECTED]
1486 7957 454D E529 E4F1  F75E 5787 B1FD FA53 851D

Re: Rationale behind script-not-executable lintian warning

[Frank Küster]

Ben Finney <[EMAIL PROTECTED]> wrote:

> On 23-Dec-2005, Frank Küster wrote:
>> Ben Finney <[EMAIL PROTECTED]> wrote:
>> > A shebang line is more than documentation: it is a strong
>> > indication that the script will be executable from the command
>> > line. To have that expectation not be matched by the file's
>> > permission mode is a recipe for confusion.
>> 
>> The fact that the script is not in the path isn't enough for you
>> here?
>
> There are many executables, that I can invoke from the command line by
> typing their explicit location, that are not in the default executable
> path on a Debian system.

That's correct.

>> And don't you think that anyone who knows that a shebang lines
>> indicates executability from the command line would easily solve the
>> problem of a "permission denied"?
>
> The confusion I refer to is not "how do I fix this?" but rather "why
> is there a mismatch, and what is the intended behaviour?" That there
> is a mismatch at all is the confusion.

Okay, so the rationale for the lintian warning would be:

"If a script starts with `#!/path/to/interpreter', this indicates that
it is intended to be directly executed, therefore it should have have
the executable bits set."

However, for me, this sounds like a reason not to make the script
executable in *my*case*.  Most of the scripts in question in the
tetex-base package are from ConTeXt, a software also distributed on its
own, but for Debian integrated into teTeX by the teTeX upstream
maintainer.

It might well be that teTeX's upstream has deliberately decided not to
make these scripts executable - for example because he wants his
software to work with "./configure; make; make install", whereas calling
the scripts directly would require to set some environment variables
(which on teTeX are passed to the scripts by the programs that
indirectly call them).  

An other possible rationale for upstream's decision is that the scripts
are originally meant to be in the path by the ConTeXt authors, but for
the integration into teTeX it was necessary to create a wrapper script
(in fact such a script does exist).  In this case the scripts are no
longer meant to be executable in teTeX.

I think Debian should stick to (teTeX's) upstream's decision, which will
simply work.  On the other hand, I see no reason to remove the shebang
lines (of a couple of scripts).

Does this sound sensible, would it warrant a lintian override?  Or what
do you think I should do?

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: Rationale behind script-not-executable lintian warning

[Frank Küster]

"cobaco (aka Bart Cornelis)" <[EMAIL PROTECTED]> wrote:

> On Friday 23 December 2005 10:24, Frank Küster wrote:
>
>> The fact that the script is not in the path isn't enough for you here?
>> And don't you think that anyone who knows that a shebang lines indicates
>> executability from the command line
>
> shebang line does _not_ indicate executability, it's the magic number that 
> indicates it's a script instead of machine code (see e.g 
> http://foldoc.org/?shebang)
>
> if it's meant to be executable it should have the executable bit set, this 
> is unrelated from the shebang line (if not what do you do with a script 
> that's executable for the owner but not for anyone else? automatically 
> remove the shebang depending on who opens it?)

You are right, but this makes me doubt even more whether having a
non-executable file with a shebang line is a bug, because this
information is also interesting for human beings.

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: Rationale behind script-not-executable lintian warning

[cobaco (aka Bart Cornelis)]

On Friday 23 December 2005 10:24, Frank Küster wrote:

> The fact that the script is not in the path isn't enough for you here?
> And don't you think that anyone who knows that a shebang lines indicates
> executability from the command line

shebang line does _not_ indicate executability, it's the magic number that 
indicates it's a script instead of machine code (see e.g 
http://foldoc.org/?shebang)

if it's meant to be executable it should have the executable bit set, this 
is unrelated from the shebang line (if not what do you do with a script 
that's executable for the owner but not for anyone else? automatically 
remove the shebang depending on who opens it?)
-- 
Cheers, cobaco (aka Bart Cornelis)
  
1. Encrypted mail preferred (GPG KeyID: 0x86624ABB)
2. Plain-text mail recommended since I move html and double
format mails to a low priority folder (they're mainly spam)


pgpDZ4t6HM856.pgp
Description: PGP signature

Re: Rationale behind script-not-executable lintian warning

[Ben Finney]

On 23-Dec-2005, Frank Küster wrote:
> Ben Finney <[EMAIL PROTECTED]> wrote:
> > A shebang line is more than documentation: it is a strong
> > indication that the script will be executable from the command
> > line. To have that expectation not be matched by the file's
> > permission mode is a recipe for confusion.
> 
> The fact that the script is not in the path isn't enough for you
> here?

There are many executables, that I can invoke from the command line by
typing their explicit location, that are not in the default executable
path on a Debian system.

> And don't you think that anyone who knows that a shebang lines
> indicates executability from the command line would easily solve the
> problem of a "permission denied"?

The confusion I refer to is not "how do I fix this?" but rather "why
is there a mismatch, and what is the intended behaviour?" That there
is a mismatch at all is the confusion.

-- 
 \  "We must become the change we want to see."  -- Mahatma Gandhi |
  `\   |
_o__)  |
Ben Finney <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: RFS: libjavascript-rpc-perl -- Perl module to process Remote procedure

[Jonas Genannt]

Don Armstrong wrote:
>Or you could just say that the version is 0.10-1; which is what
> apparently upstream means anyway.

Ok, this is I think an better solution.

I have updated the packages:
http://jonas.capi2name.de/debian-upload/libjavascript-rpc-perl/

(I have make a comment in the debian/copyright, that I have renamed and 
repackaged it)

So, now I need someone how could sponsor my package.


Greets,
Jonas


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

Re: Remove an ITP

[Thijs Kinkhorst]

On Thu, 2005-12-22 at 22:14 -0500, Justin Pryzby wrote:
> It was deliberate, but not a joke.  My point is that there's no
> difference between such names; "Public Flood Software", "FSF", and,
> for example, the "the Debian Installer team" [0].

This is getting a bit off-topic, but from a legal point of view there's
a clear difference between "FSF" on the one hand and "Public Flood
Software","the Debian Installer team" on the other hand. The former is a
formal legal entity and thus can actually hold copyrights itself, while
the latter are informal groups with no more status than the collection
of authors has.


Thijs


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

Re: Lintian error about missing debconf dependency (which is not missing)

[Joost van Baal]

Op vr 23 dec 2005 om 02:31:16 -0800 schreef Steve Langasek:
> 
> I don't know what minimum version of cdebconf (if any) you should specify to
> get support for settitle.

From the changelog:

 cdebconf  (0.43)
  "Add new command SETTITLE"

Bye,

Joost



signature.asc
Description: Digital signature

Re: Lintian error about missing debconf dependency (which is not missing)

[Steve Langasek]

On Thu, Dec 22, 2005 at 09:36:57AM +0100, Michael Hanke wrote:
> > If you depend on newer features than those guaranteed by the debconf-2.0
> > interface, you will need to depend on the providers of those features
> > explicitly, *without* an or on "debconf-2.0".
> Thanks. I did'nt realize this fact. So if I get you right the solution
> would be to get rid of the debconf-2.0 dependency. If I do so lintian is
> fine, but I guess Joey Hess is not:

> http://lists.debian.org/debian-devel/2005/08/msg00136.html
> (and follow-ups)

> This post was the reason why I included this dependency in the first
> place.

> As the debconf-2.0 package's purpose is to allow transition to cdebconf,
> is depending on cdebconf explicitely as an alternative to debconf an
> option? How compatible are those 'alternatives' currently. 

Yes, the best solution available today would be to use

 Depends: debconf (>= 1.3.22) | cdebconf (>= ??)

I don't know what minimum version of cdebconf (if any) you should specify to
get support for settitle.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: Rationale behind script-not-executable lintian warning

[Frank Küster]

Ben Finney <[EMAIL PROTECTED]> wrote:

> On 22-Dec-2005, cobaco (aka Bart Cornelis) wrote:
>> On Wednesday 21 December 2005 18:41, Bas Wijnen wrote:
>> > If it is meant to be executed, it should be executable.  
>> > If it is not, it should not have the shebang line. 
>> 
>> I disagree, there's nothing wrong with clearly documenting what
>> shell variant a script is written in, on the contrary IMHO
>
> A shebang line is more than documentation: it is a strong indication
> that the script will be executable from the command line. To have that
> expectation not be matched by the file's permission mode is a recipe
> for confusion.

The fact that the script is not in the path isn't enough for you here?
And don't you think that anyone who knows that a shebang lines indicates
executability from the command line would easily solve the problem of a
"permission denied"?

Regards, Frank

-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer