Re: Bug#397939: Lintian: outdated-autotools-helper-file

[Bas Wijnen]

On Mon, Feb 18, 2008 at 12:39:29PM -0800, Chris Waters wrote:
> But honestly, I think our job is to deliver full source and binaries.
> I _don't_ think we necessarily have to exercise every bit of the
> source (e.g. the .am files) on every build.  In fact, my primary
> objections to the java example would be a) that it confounds user
> expectations, and b) that it would result in huge diffs.  I'm not sure
> that either of those objections would apply to the autoconf case.

At least the huge diff does, that's one of the documented (in
autotools-dev's README.Debian) downsides of not running autotools during
package build.

> > The fact that there exist packages which work properly without
> > recompiling from source doesn't mean it's a good default.  IMO the
> > default should be to always compile from source.  Yes, that means hassle
> > for the packager; it's pretty much the whole task of packaging.
> 
> I think there's a big difference between recompiling from source as an
> end user would do and (re)generating _everything_ as an upstream might
> do.  I suspect the ultimate question here is: does Debian serve as a)
> a proxy for the user, generating binaries so they don't have to, or b)
> as a proxy for upstream?  I tend to lean towards the former position;
> it sounds like you lean towards the latter.

Probably, although I'm not sure who we're proxying from and to then. ;-)

I think providing binary packages which work to users is certainly a
very important part of Debian.  However, that's not everything.  We also
want to keep it free, and one important aspect of that is that we
provide source packages which work as well.

To me, a "working" source package is the complete source plus build
rules (which work ;-) ) for that source.  And that's all the source, not
just a part of it.

Of course, the suggestion to add a debian/rules target which does this
which doesn't have to be run during the normal build process would work
for this as well.  One problem I have with that is that it'll be much
less tested.  This can be fixed by running automated testing, as also
suggested, but I think it will still mean that we will have packages
which can't be compiled from source.  Another problem is that the normal
build rules will still generate a huge and unreadable diff.gz.

I would therefore still prefer to build everything from source.  However
a recommended (or even mandatory) extra target to at least be able to do
it would be acceptable to me.  That doesn't solve the "what should the
clean target do exactly" problem, though.  Is "remove all files which
have been changed during the build" an acceptable answer to that?  If
that means autotools must be rerun during normal build (which I think
will be the case sometimes), is that acceptable to most people?

As a sidestep, I think this target may actually be legally required for
GPL (at least 2 and 3) licenced code.  They say

For an executable work, complete source code means all the
source code for all modules it contains, plus any associated
interface definition files, plus the scripts used to control
compilation and installation of the executable.
(version 2), and
The "Corresponding Source" for a work in object code form means
all the source code needed to generate, install, and (for an
executable work) run the object code and to modify the work,
including scripts to control those activities.
(version 3).

In other words, build rules to generate the binary from source must be
present.

If upstream doesn't normally ask from users that they regenerate all
files, that doesn't mean that we should make it as hard for the users as
well.  Because that's the main result of not running autotools IMO: it
makes it harder for the user to make use of the sources.  I think this
also has to do with:

> Well, I see one big difference.  I often get patches from downstream
> to configure.

Perhaps this is because when running debian/rules that's the file that
is used as the source.  If any other file would be changed, they should
include instructions for how that change can be made part of the
package.  (In the simplest case a list of extra build-depends.)

> But to me, this indicates that downstream often considers the
> configure file to be a readable source format.  This cannot be said of
> a uuencoded binary.  I think that's an important distinction.

I do agree with this, though. :-)

> Bottom line: it sounds like you think the java example is
> fundamentally wrong;

Indeed.

> I merely see it as flawed, awkward and hard to maintain: a bad idea in
> general, but not necessarily wrong.

Interesting...  I didn't expect Debian people to disagree with me on
that...  (Just to be clear, that's saying something about my
expectations, not about your opinion being wrong or anything. ;-) )

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a bet

Re: RFS: nettee

[Cyril Brulebois]

On 19/02/2008, Paul Wise wrote:
> debian/docs: No need to distribute empty files nor a HTML copy of
> the manual page.

As for the HTML copy of the manual page, I wouldn't advise skipping it
as a rule of thumb. When it's a long manpage, it might make sense to
keep a nice-to-read copy around. I'm also thinking of git manpages,
with cross-references and the like, where it's very handy to have them
in HTML format. I don't know whether that applies to nettee, though.

Cheers,

-- 
Cyril Brulebois


pgpmzSNLxsM18.pgp
Description: PGP signature

Re: The get-orig-source target as stated in Policy 4.9

[Eddy Petrișor]

Andres Mejia wrote:

On Tuesday 19 February 2008 12:21:09 am Alexander Schmehl wrote:

Hi!

* Andres Mejia <[EMAIL PROTECTED]> [080218 17:54]:

I've been told that the policy for the get-orig-source target states that
it "...fetches the most recent version of the original source
package...". However, I've seen others using the get-orig-source target
to regenerate the orig tarball for their packages at a particular
version. I've been doing this as well. Some packages doing this are
warsow, ogre, fretsonfire, bulletml, and warzone2100.

And I've people jumping a red light.  That doesn't mean that it's legal
;)


So my question is, when Policy states "the most recent version", is it
"the most recent version _in Debian_" or "the most recent version
_upstream_"?

Well... beside that getting the most recent version in Debian would be
quite boring (just fetch it from a mirror and compare a checksum), I
don't know how policy section 4.9 could be read to mean something else
than the most recent upstream version:

=
4.9 Main building script: debian/rules
[..]

get-orig-source (optional)

This target fetches the most recent version of the original source
package from a canonical archive site (via FTP or WWW, for example),
does any necessary rearrangement to turn it into the original source
tar file format described below, and leaves it in the current
directory.

[..]
=

Nowhere in this paragraph is Debian or it's archive mentioned; and while
it mentiones the term "source package" it specifically mentions the
"original source package", and the original is made by upstream, isn't
it?


Alright, let's remember that Debian Policy 4 is talking about "Source 
Packages". If you start reading from the beginning, it becomes clear 
that "source package" signifies the source package used in Debian. This may 
lead to the confusion with the get-orig-source target.


Not if you think of the purpose of the target.

Furthermore, if we want to get literal about the get-orig-source policy and 
look at the term "...the most recent version...", then we must start 
factoring in development versions of packages when we consider writing the 
get-orig-source target.


What I would like to know is, what was the original purpose for the 
get-orig-source target. Maybe that would clear up what the get-orig-source 
target is supposed to do.


It supposed to let you, as a developer, upgrade the source package 
easier to the next upstream release (or non-release, see "from svn" 
snapshots or similar).


This is especially useful  when you have to purge the upstream source of 
non-free material or when you do repackage the orig tarball.


--
Regards,
EddyP
=
"Imagination is more important than knowledge" A.Einstein


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

RFS: beef and rhinote (new versions)

[Andrea Bolognani]

Hi mentors,

since my usual sponsor is too busy to keep sponsoring me, I'm searching for
someone who can review and upload the new versions of my packages.
I'd like to find someone interested in sponsoring future uploads, but a
one-time sponsorship if fine too.

Here are the URLs you can use to grab the packages, long description of both
packages follows.

dget http://www.kiyuko.org/debian/beef_0.0.6-2.dsc
dget http://www.kiyuko.org/debian/rhinote_0.7.0-2.dsc

Both the packages are already in the archive, they build fine in pbuilder and
appear to be lintian clean.


Package: beef
Description: flexible Brainfuck interpreter
 beef is a Brainfuck interpreter, a program which executes Brainfuck
 code on the fly.
 .
 Its behavior is configurable using command-line options. This enables
 you to run most Brainfuck programs, even ones written for other
 interpreters/compilers without modifications.
 .
 beef is not affected by some historical Brainfuck limitations. For
 example, the length of the memory tape's only limit is the amount of
 memory your computer has.
 .
 beef's aim is not to be incredibly small or optimized (although it is
 quite fast), but to be a flexible and pleasant-to-work-with
 interpreter.

Package: rhinote
Description: virtual sticky-notes for your desktop
 Rhinote is a small program that provides virtual sticky-notes. It's handy
 for jotting down quick notes or holding copied text that you plan to paste
 elsewhere later.
 .
 Notes can be saved as plain text for later viewing/editing with Rhinote or
 any other text editor.
 .
 Rhinote is designed to be "keyboard friendly", that is, every single action
 is bound to a specific keystroke.


Thank you for your time.

-- 
KiyuKo 
Resistance is futile, you will be garbage collected.


pgpEQNy0gHIxl.pgp
Description: PGP signature

Re: Bug#397939: Lintian: outdated-autotools-helper-file

[Bas Wijnen]

On Mon, Feb 18, 2008 at 10:14:24PM +, Mark Brown wrote:
> > Then I still don't understand your statement above.  What is the thing
> > that you prefer to check outside the normal build process?
> 
> That we can regenerate the autotools products.

I answered this in another reply.  Sorry for not merging it with this
one.

> > Does everyone agree that it would in theory be better to run autotools
> > during the build process?  In other words, if you don't have to do
> > anything to your packages for it, would you have a problem with this?
> 
> If I didn't have to do anything - but the maintainer is at least going
> to have to upload changes to run autotools.

What I mean is that I make the required changes to the packages and send
patches to everyone.  All the maintainers need to do then is apply the
patch (and maintain the result, but I'm also happy to help with that).

> > Build-depending on versioned automake doesn't look really nice, though.
> > This is how it currently should be done, AFAIK, but it might be better
> > to recommend against it.  However, in that case great care must be taken
> > when increasing its version, similar to increasing the default gcc
> > version.
> 
> Of course, doing this introduces all the work that was causing people to
> raise concerns about this...

Yes, and I share those concerns, which is why I didn't recommend this.
However, thinking more about it, it really is the Right Thing.  And when
doing it the same way as we handle gcc, I think it shouldn't be causing
too much trouble, even.

> > Of course this is a separate point.  IMO clean should remove any file
> > which was changed during the build.  And secondly, I think build should
> > regenerate everything it can.  Combined, these can be formulated as
> > "clean should remove all non-source files", because every shipped
> > non-source file must be updated (and thus changed) by the build.
> 
> Right, half the thing for me is that I don't see this as being something
> that we need to check on each and every single build.

If we build separate infrastructure to test it, it would likely also try
to do this for every upload.  And preferrably on different (or even all)
architectures we support.  So if we make this whole extra check work
right, it isn't actually costing any less computing time.  Assuming that
is what you have against doing it on every build, that is...

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html


signature.asc
Description: Digital signature

RFS: Perl packages update.

[Francesco Cecconi]

Hi DD,

I'm looking a sponsor for update my perl packages: 

Package Name: libconfig-general-perl
Short description: Generic Configuration Module
Release: 2.37-2
Source: http://mentors.debian.net/debian/pool/main/l/libconfig-general-perl

Package Name: libemail-find-perl
Short description: Find RFC 822 email addresses in plain text
Release: 0.10-dfsg-2
Source: http://mentors.debian.net/debian/pool/main/l/libemail-find-perl

Package Name: libhtml-fromtext-perl
Short description: Mark up text as HTML
Release: 2.05-6
Source: http://mentors.debian.net/debian/pool/main/l/libhtml-fromtext-perl

Package Name: texi2html
Short description: Convert Texinfo files to HTML
Release: 1.78-2
Source: http://mentors.debian.net/debian/pool/main/t/texi2html

Many Thanks :)!

Cheers,
Francesco
-- 
 .''`.  ** Debian GNU/Linux **  | Francesco Cecconi ' |BrAnD| '
: :'  :   The Universal O.S.| [EMAIL PROTECTED]
`. `'`  | GPG Key ID: 11F6E468
  `-*Debian Pkg Maintainer* | JID [EMAIL PROTECTED]


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

Re: RFS: Perl packages update.

[David Bremner]

> "Francesco" == Francesco Cecconi <[EMAIL PROTECTED]> writes:

Francesco> Hi DD, I'm looking a sponsor for update my perl
Francesco> packages:

Dear Francesco:

It would be great if you would join the pkg-perl team. The DDs there
are are very helpful about uploading packages. 

See http://alioth.debian.org/projects/pkg-perl/

With your 4 packages, the team would maintain 664, the neighbour of the
beast :-)


David


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

Re: The get-orig-source target as stated in Policy 4.9

[Alexander Schmehl]

Hi!

* Andres Mejia <[EMAIL PROTECTED]> [080219 07:38]:

[ discussion about the get-orig-source target of the policy ]

> Furthermore, if we want to get literal about the get-orig-source policy and 
> look at the term "...the most recent version...", then we must start 
> factoring in development versions of packages when we consider writing the 
> get-orig-source target.
> 
> What I would like to know is, what was the original purpose for the 
> get-orig-source target. Maybe that would clear up what the get-orig-source 
> target is supposed to do.

I still fail to read the policy as you do; perhaps we should just agree
to disagree and ask the policy team to rephrase that paragraph.


Yours sincerely,
  Alexander


signature.asc
Description: Digital signature

Bug#466550: Please clarify the get-orig-source target stated in Policy 4.9

[Alexander Schmehl]

Package: debian-policy
Version: 3.7.3.0
Severity: wishlist
X-Debbugs-CC: debian-mentors@lists.debian.org, [EMAIL PROTECTED]

Dear policy team,

recently the get-orig-source target of debian/rules has been discussed
on the debian-mentors list (see the threads starting with [1] and [2]).

It seems the get-orig-source specific paragraph of section 4.9 should be
improved to a bit more clearly and answer some open questions, too.

Basically it boils down to two or three open questions:

The first one being, if get-orig-source is intendedn to fetches the most
recent version of the original source upstream wise or if it should
fetch the most recent version debian wise.

If the later is the case and of a package has a version in
experimentatl, should get-orig-source fetch the version of experimental
or from unstable?

And last questions:  Where should tools used in get-orig-source (e.g.
bzip2 or unzip to repacke a tarball) be declared?  As Build-Dependency?
Anywhere else?


Links:
  1: http://lists.debian.org/debian-mentors/2008/02/msg00402.html
  2: http://lists.debian.org/debian-mentors/2008/02/msg00455.html


Yours sincerely,
  Alexander



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

RFS: yamdi

[Thorsten Schmale]

Dear mentors,

I am looking for a sponsor for my package "yamdi".

  Package name: yamdi
  Version : 1.2-1
  Upstream Author : Ingo Oppermann
  URL : yamdi.sourceforge.net
  Section : misc

It builds these binary packages:
yamdi  - metadata injector for FLV files

The package appears to be lintian clean.

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/y/yamdi
- Source repository: deb-src http://mentors.debian.net/debian unstable main 
contrib non-free
- dget http://mentors.debian.net/debian/pool/main/y/yamdi/yamdi_1.2-1.dsc

I would be glad if someone uploaded this package for me.

Kind regards
 Thorsten Schmale



signature.asc
Description: Digital signature

Handling values with db_get in case of translation

[Olivier Berger]

Hi.

I'm wondering how would one write postinst script tests, in the case of
"select" debconf configuration values, which are translated in the
templates.

Let's say that a package's template contains something like :

 Template: sympa/db_authtype
 Type: select
 Choices: Ident-based, Password
 ...
 Choices-fr.UTF-8: Basée sur ident, Mot de passe

If issueing 'db_get sympa/db_authtype', and wanting to test the results, I 
would expect some code like the following to be correct :

 db_get sympa/db_authtype
   if [ "$RET" = "Ident-based" ]; then
   ...

However, it seems that the db_get results depend on the locale, and return 
"Basée sur ident" instead of "Ident-based" when with french locale...

How can one write scripts, which will not depend on translation of the 
templates ?

Is this a bug in debconf ?

Btw, that's a real case example in the sympa package, and testing distro (and 
see bug #466530).

Thanks for your comments.

Best regards,
-- 
Olivier BERGER <[EMAIL PROTECTED]> (*NEW ADDRESS*)
http://www-inf.it-sudparis.eu/~olberger/ - OpenPGP-Id: 1024D/6B829EEC
Ingénieur Recherche - Dept INF
Institut TELECOM / TELECOM & Management SudParis (http://www.it-sudparis.eu/), 
Evry

Re: Bug#466550: Please clarify the get-orig-source target stated in Policy 4.9

[Andres Mejia]

I would like to add what Russ Allbery wrote.

On Tuesday 19 February 2008 1:47:25 am Russ Allbery wrote:
. . . 
> Personally, I've always read it has emphasizing an entirely different part
> than what people are talking about here.  Rather than focusing on the
> current version bit, I always focused on the "does any necessary
> rearrangement to turn it into the original source tar file format
> described below" bit.  I provide this target only for my packages that
> require repackaging of the upstream source as a way of automating that
> repackaging.
. . .

When considering the phrase in policy "...does any necessary rearrangement to 
turn it into the original source tar file format...", it makes more sense 
when it refers to the original source tar file of the source package in 
Debian (or will be in Debian), and the original source tarball would be at a 
particular version, and thus the get-orig-source should generate that 
particular version of the original source tarball of the source package in 
Debian.

-- 
Regards,
Andres


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

Re: Bug#466550: Please clarify the get-orig-source target stated in Policy 4.9

[Kapil Hari Paranjape]

Hello,

Perhaps the following elaborate statement can be condensed (once
sufficient cooling has occurred :-))

1. Once pkg_ver.orig.tar.gz enters the Debian archive this is
considered the authoritative Debian version from which all the binary
Debian packages will be built (for that version of the package). A
signature/checksum is used (in the upload and the Sources.gz file) so
as to detect any "contamination".

2. If re-packaging of upstream sources was required in order to create
this .orig.tar.gz, then this should be documented in the copyright
file (with some further explication in README.Debian-source perhaps).

3. Whenever upstream releases a new version, one needs to create a
pkg_nver.orig.tar.gz for the newer version.

In case this is merely a matter of downloading and renaming an
upstream tar.gz, the "uscan" and "uupdate" programs are adequate and
there is no significant need for a get-orig-source target.

In the case when re-packaging has been done as in (2), it is
a non-trivial convenience if these steps are automated by such
a program or target. Such a program further clarifies the statements
in the copyright file and the README.Debian-source file. (Program as
documentation!)

In the last case, someone who wishes to verify the accuracy of the
statements in the copyright file may also wish to re-generate
pkg_ver.orig.tar.gz to compare it with the Debian version. This
can also be provided for to the extent possible.

If there is any reason to suspect that the pkg_ver.orig.tar.gz was
not in fact created as documented then this constitutes a bug whose
severity would depend on the extent of the discrepancy.

Regards,

Kapil.
--


signature.asc
Description: Digital signature

Re: Bug#466550: Please clarify the get-orig-source target stated in Policy 4.9

[Daniel Leidert]

Am Dienstag, den 19.02.2008, 15:16 +0100 schrieb Alexander Schmehl:
> Package: debian-policy
> Version: 3.7.3.0
> Severity: wishlist
> X-Debbugs-CC: debian-mentors@lists.debian.org, [EMAIL PROTECTED]
> 
> Dear policy team,
> 
> recently the get-orig-source target of debian/rules has been discussed
> on the debian-mentors list (see the threads starting with [1] and [2]).
> 
> It seems the get-orig-source specific paragraph of section 4.9 should be
> improved to a bit more clearly and answer some open questions, too.
> 
> Basically it boils down to two or three open questions:
> 
> The first one being, if get-orig-source is intendedn to fetches the most
> recent version of the original source upstream wise or if it should
> fetch the most recent version debian wise.

That should be done by uscan invoking "debian/rules get-orig-source" as
suggested several times. This won't make the situation more complicated.
It just requires that any variables necessary to create the tarball
(e.g. upstream version, svn version number, ...) can be overwritten by
uscan (already explained it in this thread)

> If the later is the case and of a package has a version in
> experimentatl, should get-orig-source fetch the version of experimental
> or from unstable?

It should IMO fetch the version by parsing debian/changelog. That's
simple and logical. uscan can overwrite these variables.

> And last questions:  Where should tools used in get-orig-source (e.g.
> bzip2 or unzip to repacke a tarball) be declared?  As Build-Dependency?
> Anywhere else?

I don't think, they should be declared in Build-Depends, because they
are simply not necessary to build the package. No target in debian/rules
invokes get-orig-source during a build and people invoking this target
should be able to check debian/rules, if something goes wrong. But to be
honest: This target normally requires only bzip2/gzip/tar, wget (maybe
we can drop this, if uscan invokes get-orig-source) and rm + sometimes
$VCS-command.

Regards, Daniel


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

RFS: bouncy (new Debian revision)

[Ansgar Burchardt]

Hi,

I'm looking for a sponsor for the new Debian revision of "bouncy".

It builds these binary packages:
bouncy - eat the yummy veggies in the garden - game for small kids

Description:
 You play Bouncy the Hungry Rabbit. You're in a garden with yummy veggies
 and a farmer who's not keen on you eating them. You can hide (and move
 around) under the ground.

Homepage: http://www.pyweek.org/e/bouncy/

Vcs-Svn: svn://svn.debian.org/svn/pkg-games/packages/trunk/bouncy/
Vcs-Browser: http://svn.debian.org/wsvn/pkg-games/packages/trunk/bouncy/?op=log

Lintian v1.23.45 reports nothing.

The upload would fix an important bug:
 #461275: bouncy declares relation to ttf-bitstream-vera 

The new revision also makes the menu entries work by moving the start script
to /usr/games.  There are some more changes to comply to current policy.

The package can be found on mentors.debian.net:
 - URL: http://mentors.debian.net/debian/pool/main/b/bouncy
 - Source repository: deb-src http://mentors.debian.net/debian unstable main 
contrib non-free
 - dget 
http://mentors.debian.net/debian/pool/main/b/bouncy/bouncy_0.6.20071104-2.dsc

I would be glad if someone uploaded this package for me.

Regards,
Ansgar
-- 
pgp: 0xF1F477C02BE4 CE2A E9CB 27D3 29F4  502E 53B1 6D9C F1F4 77C0



signature.asc
Description: Digital signature

Re: Bug#466550: Please clarify the get-orig-source target stated in Policy 4.9

[Alexander Schmehl]

Hi!

* Daniel Leidert <[EMAIL PROTECTED]> [080219 18:11]:

> That should be done by uscan invoking "debian/rules get-orig-source" as
> suggested several times.

Thanks for your input, but the question of this supthread is not "How"
but "What" ;)



> > And last questions:  Where should tools used in get-orig-source (e.g.
> > bzip2 or unzip to repacke a tarball) be declared?  As Build-Dependency?
> > Anywhere else?
> I don't think, they should be declared in Build-Depends, because they
> are simply not necessary to build the package. [..]

I agree.  But shouldn't needed packages be documented somewhere?


Yours sincerely,
  Alexander


signature.asc
Description: Digital signature

RFS: qdevelop

[Guillaume Martres]

Dear mentors,

I am looking for a sponsor for my package "qdevelop".

* Package name: qdevelop
* Version: 0.25.2-1
* Upstream Author : Jean-Luc Biord <[EMAIL PROTECTED]>
* URL  : http://qdevelop.org
* License: GPLv2+
* Section: devel

It builds this binary package:
qdevelop   - A development environment entirely dedicated to Qt4

The package appears to be lintian clean.

The upload would fix these bugs: 415311, 427835

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/q/qdevelop
- Source repository: deb-src http://mentors.debian.net/debian unstable main 
contrib non-free
- dget 
http://mentors.debian.net/debian/pool/main/q/qdevelop/qdevelop_0.25.2-1.dsc

I would be glad if someone uploaded this package for me.

Cheers,
Guillaume Martres


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

RFS: QA Upload -- kguitar - Stringed instrument tablature editor for KDE (Try2)

[Barry deFreese]

Barry deFreese wrote:

Hi,

Here is a QA upload for kguitar.  Fixes 2 bugs and standards update, 
etc. if someone has time to review/upload.


http://mentors.debian.net/debian/pool/main/k/kguitar/kguitar_0.5-3.dsc


Description: Stringed instrument tablature editor for KDE
Kguitar is basically a guitar tablature editor for K Desktop Environment.
.
It's much more than just a tab editor. It's features are:
 * Powerful and convenient tablature editing, including
   many effects and classical note score editing for classic instrument
   players;
 * Full and very customizable MIDI to tablature import and export;
 * Support of extra data formats, such as ASCII tablatures, MusicXML or
   popular programs' format, such as Guitar Pro's or TablEdit;
 * Chord fingering construction tools - chord finder and chord analyzer;
 * Many additional facilities to ease tabbing work,
   including rhythm and lead construction tools;
 * Highly customizable to suit a lot of possible instruments
   (not only 6-string guitars, and even not only guitars),
   including drum tracks, lyrics and other MIDI events.



Thank you,

Barry deFreese

Hi folks,

Other than hearing from Tim, I haven't heard anything more on this 
package.  Any chance anyone would have time to review and/or upload?


Thank you!

Barry deFreese


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

RFS: ee (updated package)

[Mauro Lizaur]

Dear mentors,
I am looking for a sponsor for the new version 1:1.4.6-1 of my package "ee".

It builds these binary packages:
ee - An "easy editor" for novices and compuphobics

The package appears to be lintian clean.
The upload would fix these bugs: 392671, 457162

dget http://mentors.debian.net/debian/pool/main/e/ee/ee_1.4.6-1.dsc

I would be glad if someone uploaded this package for me.

Thanks,
Mauro Lizaur

-- 
BEGIN GEEK CODE BLOCK
Version: 3.12
GCM/O d->dpu$ s-:- a-->a+++$ C+++
LU P+ L++ E W+++ N !o K w O !M !V
PS+ PE Y+ PGP t 5– X R tv++ b- DI D++ G+ e
h!>h-- r>r+++ y+
END GEEK CODE BLOCK

Re: Bug#397939: Lintian: outdated-autotools-helper-file

[Kurt Roeckx]

On Tue, Feb 19, 2008 at 10:50:23AM +0100, Bas Wijnen wrote:
> As a sidestep, I think this target may actually be legally required for
> GPL (at least 2 and 3) licenced code.  They say
> 
>   For an executable work, complete source code means all the
>   source code for all modules it contains, plus any associated
>   interface definition files, plus the scripts used to control
>   compilation and installation of the executable.
> (version 2), and
>   The "Corresponding Source" for a work in object code form means
>   all the source code needed to generate, install, and (for an
>   executable work) run the object code and to modify the work,
>   including scripts to control those activities.
> (version 3).
> 
> In other words, build rules to generate the binary from source must be
> present.

The GPL does not require us to build anything.  Just that the source
are available.

I would also like to point out this exception from the autoconf license:

| As a special exception, the Free Software Foundation gives unlimited
| permission to copy, distribute and modify the configure scripts that
| are the output of Autoconf.  You need not follow the terms of the GNU
| General Public License when using or distributing such scripts, even
| though portions of the text of Autoconf appear in them.  The GNU
| General Public License (GPL) does govern all other use of the material
| that constitutes the Autoconf program.


Kurt


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

Re: Bug#397939: Lintian: outdated-autotools-helper-file

[Mark Brown]

On Tue, Feb 19, 2008 at 10:59:10AM +0100, Bas Wijnen wrote:

> If we build separate infrastructure to test it, it would likely also try
> to do this for every upload.  And preferrably on different (or even all)
> architectures we support.  So if we make this whole extra check work
> right, it isn't actually costing any less computing time.  Assuming that
> is what you have against doing it on every build, that is...

It's not just the computing resources required that concern me, it's
also the effort involved in doing it and the disruption that could be
caused, especially if we were to do things like changing autotools
versions underneath the package.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


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

Re: RFS: libhugetlbfs

[Mel Gorman]

Sorry for the long delay in responding. When I posted first, I thought
things would be quiet for a while but I got bogged down fixing bugs in
kernel 2.6.24-rc8. It curtailed free time :/ It's not much better now
but I thought I would kick it once before heading to FOSDEM.

On (15/01/08 00:53), Cyril Brulebois didst pronounce:
> On 14/01/2008, Mel Gorman wrote:
> > The documentation is pretty decent but there is a lot of it.
> 
> Rome wasn't built in a day? ;-)
> 

Indeed not. I expect the documentation will sink in eventually.

> > > W: libhugetlbfs: shlib-with-executable-stack usr/lib/libhugetlbfs.so
> > 
> > I give up, whats the right way of fixing this? Searching around says I
> > should be able to pass -Wa,--execstack via the compiler to the
> > assembler but it does not appear to be supporting by the binutils in
> > Debian testing. This is very likely a build issue in the upstream
> > package as well.
> 
> Actually, I don't know. My first guess would be to ask upstream whether:
> it's wanted, and if so, if it's needed. Either they have to fix it, or
> you'll have to investigate how to deal with it.
> 

They weren't aware of the issue. For the moment, I'm going to see what
is required to make things work for Debian in 1.2 and then forward-port
that to the development version. When it releases, I'll update the
Debian package to match.


> For those who didn't build this package, lintian outputs:
> | N:   The listed shared libraries declares the stack as executable.
> | N:   
> | N:   Executable stack is usualy an error as it is only needed if the code
> | N:   contains GCC trampolines or similar constructs which uses code on the
> | N:   stack. One possible source for false positives are object files built
> | N:   from assembler files which don't define a proper .note.GNU-stack
> | N:   section.
> 
> And there are assembler files:
> | $ find -name '*.S'
> | ./elf_i386.S
> | ./elf32ppclinux.S
> | ./elf64ppc.S
> | ./elf_x86_64.S
> 
> Looks to me that it probably will only work on: i386, amd64, powerpc,

i386, amd64 and ppc64 actually. The naming is confusing and while it
might work on 32 bit ppc, I know it has not been tested in a long time.
I updated the Architecture in the control file to read

Architecture: i386 amd64 ppc64

> you should ask upstream if support for more architecture is planned, and
> eventually change ???Architecture: any??? to an explicit list of supported
> architectures.
> 

No wider support is planned. IA-64 support is a remote possibility but I
know it is not high on the list of priorities.

> Anyway, asking upstream to double-check that .note.GNU-stack thing
> should help.
> 
> > I removed the shlibs file as it should have been possible to use
> > dh_makeshlibs. The rules file now calls it but it's still not
> > generating the shlibs file correctly (-v shows the script to be doing
> > nothing). The lintian error is
> > 
> > E: libhugetlbfs: no-shlibs-control-file usr/lib/libhugetlbfs.so
> > N:
> > N:   Although the package includes a shared library, the package does not
> > N:   have a shlibs control file. If this is intentional, please override
> > N:   this error.
> > N:   
> > N:   Refer to Policy Manual, section 8.6 for details.
> 
> AFAICT, dh_makeshlibs might work better if you had proper library
> versioning (using SONAME).
> 

Tracking the development version at the moment, I know the next major
release will be significantly different to what the current version
does. While I can fix the stack and Makefile fixes backported, I think
adding proper versioning just for debian would be a mistake. The proper
thing is to fix it upstream and do a another package release later. This
would keep the Debian version of libhugetlbfs consistent with whats in
RHEL, Fedora and SuSE.

This would impact proper versioning in this package though but as future
versions of the library are likely to be incompatible anyway, it likely
isn't a problem

It's worth noting that the main function of hte library is to provide
functionality with LD_PRELOAD or during application start-up time. There
is no expectation for any API to be called.

> > I think that is a global override which doesn't feel like the right
> > thing to be doing. I suspect I'm missing something in the control file
> > or some other file is missing that tells dh_makeshlibs what to do.
> 
> That would rather be ???dh_makeshlibs -V??? (but that is *only* to give you
> an idea of what you need to do, and not the final word on this. -V
> without parameters is dangerous and error-prone). But again, please take
> that to upstream and ask them for proper versioning (in case I didn't
> say that in my first mail, that would permit having a foo application
> linked against libhugetlbfs1 to keep on working while having another bar
> application linked against libhugetlbfs2, so that upgrades are as smooth
> as possible).
> 

I'll be kicking upstream but it won't happen quickly. The version of
libhugetlbfs that will have versioning assuming I k

Re: RFS: lynis

[Francisco García]

Hello Patrick, Paul, 

I have made the changes that you suggest me. I think
the package is better now.

Please, I would like you take a look at the package. 
And anyone who wants to review it.

Thank you for your help.


* Package name: lynis
  Version : 1.0.8-1
  Upstream Author : Michael Boelen <[EMAIL PROTECTED]>
* URL : http://www.rootkit.nl/projects/lynis.html
* License : GPL v3
  Section : utils

It builds these binary packages:
lynis  - Security auditing tool for Unix based systems

Long Description:
 Lynis is an auditing tool for Unix. It scans the system
 configuration and create an overview of system information
 and security issues usable by professionals auditors.
 It can assist in automated audits.
 .
 Lynis can be used in adition to other software, like security
 scanners, system benchmarking and finetunning tools.


The package appears to be lintian clean.

The upload would fix these bugs: 465538

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/l/lynis
- Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- dget
http://mentors.debian.net/debian/pool/main/l/lynis/lynis_1.0.8-1.dsc

I would be glad if someone uploaded this package for me.



Best regards,
Francisco.


-- 
Francisco M. García Claramonte <[EMAIL PROTECTED]>
GPG: public key ID 556ABA51


signature.asc
Description: Esta parte del mensaje está firmada	digitalmente

RFS: fluid-soundfont -- Fluid (R3) General MIDI SoundFont

[Toby Smithe]

Dear mentors and Debian Multimedia Team,

I am looking for a sponsor for my package "fluid-soundfont".

* Package name: fluid-soundfont
  Version : 3-1
  Upstream Author : Frank Wen <[EMAIL PROTECTED]>
* URL :
http://tsmithe.users.ubuntustudio.org/fluid-soundfont_r3.tar.gz
* License : MIT
  Section : sound

It builds these binary packages:
fluid-soundfont-gm - Fluid (R3) General MIDI SoundFont (GM)
fluid-soundfont-gs - Fluid (R3) General MIDI SoundFont (GS)

The package is lintian clean.

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/f/fluid-soundfont
- Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- dget 
http://mentors.debian.net/debian/pool/main/f/fluid-soundfont/fluid-soundfont_3-1.dsc

The upload would fix these bugs: 466612, and enable a hell of a lot of
functionality in MIDI-related packages. I would like to quote from my
Ubuntu Feature Freeze Exception request[0]:

"As you can probably tell, to provide a SoundFont in the Ubuntu
archives will be a vast increase in usability in all software dealing
with MIDI synthesis, as previously we were unable to offer an
out-of-the-box functioning system. Whilst we have freepats, that
leaves a lot to be desired, and a SoundFont is far more desirable than
the mass of old patch files.

Inclusion of fluid-soundfont will enable users to play back MIDI files
with any number of software synthesisers (and, if gstreamer-midi is
enabled, this will include gstreamer-based software) and compose music
(with packages such as mscore or rosegarden), to list just two tasks."

I am very keen to improve the state of MIDI applications in Debian and
Ubuntu, and fluid-soundfont will definitely aid in that.

I hope this can be swiftly uploaded, as the longer it waits, the less
likely it will be allowed into Ubuntu Hardy.

Thanks,

--Toby Smithe


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

Re: RFS: fluid-soundfont -- Fluid (R3) General MIDI SoundFont

[Henrique de Moraes Holschuh]

On Wed, 20 Feb 2008, Toby Smithe wrote:
> I am looking for a sponsor for my package "fluid-soundfont".
> 
> * Package name: fluid-soundfont
>   Version : 3-1
>   Upstream Author : Frank Wen <[EMAIL PROTECTED]>
> * URL :
> http://tsmithe.users.ubuntustudio.org/fluid-soundfont_r3.tar.gz
> * License : MIT
>   Section : sound

I have been burned by soundfonts before, does Frank Wen have a site or
somesuch, describing how he made the soundfount, where he got the
instruments, etc?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: RFS: ee (updated package)

[Paul Wise]

On Feb 20, 2008 6:27 AM, Mauro Lizaur <[EMAIL PROTECTED]> wrote:

> It builds these binary packages:
> ee - An "easy editor" for novices and compuphobics

What are compuphobics? Sounds like a word that should not be in a
short description.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: RFS: ee (updated package)

[Kapil Hari Paranjape]

Hello,

On Wed, 20 Feb 2008, Paul Wise wrote:
> On Feb 20, 2008 6:27 AM, Mauro Lizaur <[EMAIL PROTECTED]> wrote:
> 
> > It builds these binary packages:
> > ee - An "easy editor" for novices and compuphobics
> 
> What are compuphobics? Sounds like a word that should not be in a
> short description.

Apparently the "correct" word is "cyberphobic people" (which could 
probably be shortened to "cyberphobics"):

Cyberphobia - Fear of computers or working on a computer.
(from www.phobialist.com)

Though why someone who has this fear would be using an editor on a
computer is not clear...

Regards,

Kapil.
--



signature.asc
Description: Digital signature

RFS: QA Upload - muine 0.8.8-1 - Simple playlist based music player

[Barry deFreese]

Hi,

I have prepared a QA upload for the orphaned package muine which 
includes an new upstream that fixes RC bug #440817, and fixes a few 
other bugs. 
(#415419, #427263, #449835, and probably several of the bugs posted 
against the 0.6.x versions).  If someone could please review and/or 
upload I would appreciate it.


http://mentors.debian.net/debian/pool/main/m/muine/muine_0.8.8-1.dsc

Description: Simple playlist based music player
Muine is an innovative music player. It has a simple interface designed to
allow the user to easily construct playlists from albums and/or single 
songs.

Its goal is to be simply a music player, not to become a robust music
management application.  It includes a plugin interface.
.
The package includes the CIL assemblies to access the D-BUS interface
to Muine and to compile plugins for Muine.

Thank you,

Barry deFreese


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

Re: RFS: ee (updated package)

[Mauro Lizaur]

On Feb 20, 2008 1:38 AM, Kapil Hari Paranjape <[EMAIL PROTECTED]> wrote:
> Hello,
>
> On Wed, 20 Feb 2008, Paul Wise wrote:
> > On Feb 20, 2008 6:27 AM, Mauro Lizaur <[EMAIL PROTECTED]> wrote:
> >
> > > It builds these binary packages:
> > > ee - An "easy editor" for novices and compuphobics
> >
> > What are compuphobics? Sounds like a word that should not be in a
> > short description.
>
> Apparently the "correct" word is "cyberphobic people" (which could
> probably be shortened to "cyberphobics"):
>
> Cyberphobia - Fear of computers or working on a computer.
> (from www.phobialist.com)
>
> Though why someone who has this fear would be using an editor on a
> computer is not clear...
>
> Regards,

Paul, Kapil,
To be sincere i left that field just like they were when i adopted this package.
I've just improved this a little bit:

---
Description: A terminal-based text editor for novice users.
 This editor ('ee', easy editor) is intended to be a simple, easy to use
 terminal-based screen oriented editor that requires no instruction to
 use.  Its primary use would be for people who use computers for simple
 tasks like e-mail.
 .
 Its simplified interface is highlighted by the use of pop-up menus which
 make it possible for users to carry out tasks without the need to
 remember commands.  An information window at the top of the screen shows
 the user the operations available with control-keys.
---

Opinions are (more than) welcome.

Regards,
Mauro

-- 
BEGIN GEEK CODE BLOCK
Version: 3.12
GCM/O d->dpu$ s-:- a-->a+++$ C+++
LU P+ L++ E W+++ N !o K w O !M !V
PS+ PE Y+ PGP t 5– X R tv++ b- DI D++ G+ e
h!>h-- r>r+++ y+
END GEEK CODE BLOCK

Re: RFS: ee (updated package)

[Mauro Lizaur]

> To be sincere i left that field just like they were when i adopted this 
> package.
> I've just improved this a little bit:

err.
To be sincere i left this field just like it was when i adopted it.

sorry for my english


Mauro.


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

Re: The get-orig-source target as stated in Policy 4.9

[Manoj Srivastava]

On Mon, 18 Feb 2008 22:47:25 -0800, Russ Allbery <[EMAIL PROTECTED]> said: 

> Andres Mejia <[EMAIL PROTECTED]> writes:
>> What I would like to know is, what was the original purpose for the
>> get-orig-source target. Maybe that would clear up what the
>> get-orig-source target is supposed to do.

If my memory serves me correctly, it was meant to do what uscan
 does now -- I recall doing this when using cvs-buildpackage to
 re-create ../foo_X.Y.orig.tar.gz

> It's been in Policy from before upgrading-checklist was started and
> there's no mention of it in the changelog, so my guess is that you'd
> have to go rather far back in time to find the original discussion.

> Personally, I've always read it has emphasizing an entirely different
> part than what people are talking about here.  Rather than focusing on
> the current version bit, I always focused on the "does any necessary
> rearrangement to turn it into the original source tar file format
> described below" bit.  I provide this target only for my packages that
> require repackaging of the upstream source as a way of automating that
> repackaging.

> It's a weird target in various respects.  For example, should you
> declare the programs it needs in Build-Depends?  I don't think so, and
> it would feel weird to me to do so, but as a result I use software in
> get-orig-source for which there's no hint in the source package
> control file might be needed (wget is the most common).

Frankly, all this dicsussion and lack of clarity about what the
 policy directive means seems like an excellent opportunity to  remove
 crift from policy.  After all, if people don't know what the policy
 directive means, there are no critical integration needs being served
 by this policy dictum, and it can be safely removed.

manoj
-- 
You will probably marry after a very brief courtship.
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: RFS: xiterm+thai

[Paul Wise]

On Feb 19, 2008 2:44 AM, Neutron Soutmun <[EMAIL PROTECTED]> wrote:

> - - dget
> http://mentors.debian.net/debian/pool/main/x/xiterm+thai/xiterm+thai_1.07-1.dsc

Some comments:

Unless you need new features of debhelper compat 6, please leave it at
the latest compat level available in stable.

Description suggestion:

Description: X terminal program with Thai languague support
 xiterm+thai is an X terminal emulator program with Thai language
 support. It has built-in Thai keyboard input support. You could
 also use the X11 XKB extension to input Thai characters.
 .
 A Thai font is needed to display Thai characters.

Probably don't need README installed since it is about building, I'm
guessing README.thai too. Same for COPYRIGHT.HISTORY (copied in
debian/copyright), doc/README.rxvt.greek - Thai != greek :), and maybe
the README.xvt too.

Perhaps README.thai should be reencoded in UTF-8?

What is the reason for having two entries in the menu file? Also, it
would be good to add a desktop file to support GNOME since by default
it now doesn't show the Debian menu IIRC.

The README.Debian needs to be checked and maybe rewritten.

txiterm manual page:

This isn't really needed "This manual page documents briefly the
txiterm command".

OPTIONS section needs filling out.

Very nice changelog entry, good work on the package :)

Shame the package got removed, thanks for working on getting it back in.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: RFS: thailatex (updated package)

[Norbert Preining]

On Mo, 18 Feb 2008, Theppitak Karoonboonyanan wrote:
> Would this be OK? Should it be uploaded?

Uploaded.

Best wishes

Norbert

---
Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of Technology
Debian Developer <[EMAIL PROTECTED]> Debian TeX Group
gpg DSA: 0x09C5B094  fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
---
JARROW (adj.)
An agricultural device which, when towed behind a tractor, enables the
farmer to spread his dung evenly across the width of the road.
--- Douglas Adams, The Meaning of Liff


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