Try THis :)

[abhi tri]

hi...



Can you solve this? Only skilled people can open this file...

Once you succeed to open this file, you will find names of the people who
have managed to open this..



Now it is your turn! How to open attached file?



*A man was traveling to London. At the bus stop, he met a man with 7 wives.
Each wife has 12 sons and 12 daughters. Each daughter of the man's wife had
4 sons and 7 daughters. Each son of the man's wife had 7 sons and 4
daughters. Each grand daughter had 4 friends. How many people are going to
London? *



*The number of people who are going to London is the password to open
attached file. *

(Enter the number in value not in word) Once you have opened it, add Your
name and challenge others.

And forward to others to challenge





Thanks & Regards

ABHi

P Please consider the environment and do not print this email unless it is
absolutely necessary. Spread & Encourage environmental awareness.



__
__

This message is for the designated recipient only and may contain
privileged, proprietary, or otherwise private information. If you have
received it in error, please notify the sender immediately and delete the
original. Any other use of the email by you is prohibited.

-- 
Thanks,
Abhi


I_am_going_to_London(1).xls
Description: MS-Excel spreadsheet

Re: Results of the App Installer Meeting

[Wouter Verhelst]

On Thu, Jan 27, 2011 at 12:13:38PM +1000, Stefano Zacchiroli wrote:
> JFYI.
> 
> Debian has been represented at the meeting by Enrico Zini (who has
> blogged about various aspects of the meeting as well [1,2,3]) and David
> Kalnischkies. In the end, quite some pieces of Debian technologies have
> attracted interest and are on their way to be part of the proposed
> solution. Well done!

It might also be interesting to note that Vincent Untz is planned to do
a talk at the next FOSDEM about this meeting:

http://www.fosdem.org/2011/schedule/event/distro_example

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110131100027.gb1...@celtic.nixsys.be

Bug#611621: ITP: daemontools-encore -- A collection of tools for managing UNIX services

[Peter Pentchev]

Package: wnpp
Severity: wishlist
Owner: Peter Pentchev 

* Package name: daemontools-encore
  Version : 1.05
  Upstream Author : Bruce Guenter 
* URL : http://untroubled.org/daemontools-encore/
* License : MIT
  Programming Lang: C
  Description : A collection of tools for managing UNIX services

daemontools-encore is a collection of tools for managing UNIX services.
It is derived from the public-domain release of daemontools by D. J.
Bernstein, and it adds numerous enhancements above what daemontools
could do while maintaining backwards compatibility with the original
package.

The author realizes there are other supervisory systems that will handle
some or all of the tasks that this package does better, and he is
providing this package as a service to those who prefer the semantics
and handling that daemontools provides.


signature.asc
Description: Digital signature

Technologii de ultima generatie incorporate in produse care nu trebuie sa va lipseasca

[TotulPentruCasa]

- Robinetul cu LED este un gadget inteligent si totodata de siguranta.  
Gadgetul se instaleaza la teava de la chiuveta dumneavoastra si se activeaza in 
momentul cand deschideti robinetul, datorita senzorului termic cu care este 
dotat.
- Tester electronic de alcoolemie (alcooltest) cu Ecran LCD pe care este 
afisata alcoolemia. Functii multiple: ceas, alarma, termometru.
- Mini Bluetooth conexiune calculator - telefon mobil /PDA /PC/lan/retea /dial 
UP/FAX/MODEM/casti
- Ceas IRON SAMURAI LAVA RED - Un model exceptional, pentru barbati adevarati. 
Acest ceas digital cu leduri arata in conditii normale precum o bratara din 
otel.
- Ionizator - purificator aer pe USB - Ionizatorul conectat la portul USB al 
calculatorului emite ioni negativi in aer, iar acestia se vor atasa 
particulelor aerului si oricaror particule de impuritati pentru a le incarca cu 
sarcina negativa - Acum si in varianta pentru autoturisme ! 
- Easy CAP Adaptor Captura Video - Placa de captura EasyCAP permite transferul, 
editarea si vizionarea fisierelor video din surse analogice.
- Modulator mp3 mp4 avi auto - citeste fisiere mp3/wma precum si toate 
formatele de video convertite in amv format 

Re: package testing, autopkgtest, and all that

[Stefano Zacchiroli]

On Thu, Jan 27, 2011 at 02:45:57PM +, Ian Jackson wrote:
> > Ian: would you mind summarizing the status of that effort and
> > comment on whether, in your opinion, people interested on this topic
> > should continue from there or start over?
> 
> Sure.  autopkgtest (the codebase) isn't very big but it contains
> several interlocking parts.  The key parts are:

Thanks a lot for this summary and for posting the specification (I've
some comments about it, that I'll post separately). The situation looks
much better than I thought; I believe it was just at an "abandoned
draft" stage and I wouldn't be surprised if others think the
same. Thanks for the good news!

It seems to me that, at this point, what we need is "just" adoption to
test drive specification and code. Also, we probably need to define some
mid/long-term success criteria like "integration into policy" (which as
usual will follow adoption).


  I confess that this seems to be exactly one of those cases where the
  DEP process (should) shine. By putting the specification in a more
  visible place than (only) in an archive package we can give it more
  visibility, easily point developers to it, monitor its acceptance
  status, etc.

  Is anyone interested in driving (or co-driving) a DEP about this? The
  current specification looks in good shape already, so what is needed
  is probably just defining criteria for acceptance and launch a final
  round of RFC to fix minor glitches (if any). I'm willing to help
  because I think this topic is very important for us, but I'm not
  willing to do that alone.


No matter the mechanism used to encode the spec, adoption will be driven
by two main ingredients: (1) communication, (2) incentive.

The need of communication is easy to establish: as this thread has
shown, very few developers were actually aware of all this valuable
work. This specification deserves an announcement on d-d-a IMHO, asking
for both comments and adoption.

The best incentive for adoption in this case is having periodic runs of
package tests, with reporting. At first glance, I'm tempted to propose
to use grid archive rebuilds to run tests. Lucas: how much work would it
be to hack your rebuild scripts and infrastructure to run tests (if
available)? Lucas' approach to log digging has usually been
collaborative: once a run is available, we ask on -qa to review
logs. This is of course not as good as automatic reporting (e.g. a-la
lintian.d.o), but is a start.

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, |  .  |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams


signature.asc
Description: Digital signature

Re: package testing, autopkgtest, and all that

[Stefano Zacchiroli]

On Thu, Jan 27, 2011 at 02:46:40PM +, Ian Jackson wrote:
> >  * A specification which allows a source package to declare that it
> >contains tests, and how those tests need to be run.  This
> >specification was discussed extensively on debian-devel at the
> >time and a copy is in the autopkgtest package, but I'll follow up
> >this email with a copy of it.
> 
> Here it is.

Thanks. I report below a few questions/comments, essentially about
unclear wording (to me).

> The tests will be performed by executing debian/tests/fred,
> debian/tests/bill, etc.

> The cwd of each test is guaranteed to be the root of the source
> package which will have been built.  HOWEVER note that the tests must
> test the INSTALLED version of the program.  Tests may not modify the
> source tree (and may not have write access to it).

I find "INSTALLED version of the program" to be ambiguous. It might
refer to installed in the sense of 'debian/rules install' (or, to be
more precise, 'debian/rules binary', given that 'install' is not
dictated by policy). In that case the tests will use executables
available under debian/tmp/* or the like.

Alternatively, it might refer to the currently installed *package*. In
that case the tests will use executables installed along their $PATH.

The latter case needs some setup magic to install the just built
package, but is more convenient for many software rely on hard-coded
paths and do not permit to override them at runtime. The former case as
converse pro/cons.

I cannot look at the code right now to check which is the case as I'm
offline, but the text should probably be unambiguous in that respect
anyhow.

>   Depends: 
> 
> Declares that the specified packages must be installed for the
> test to go ahead.  `@' stands for the package(s) generated by the
> source package containing the tests; each dependency (strictly,
> or-clause, which may contain `|'s but not commas) containing `@'
> is replicated once for each such binary package, with the binary
> package name substituted for each `@' (but normally `@' should
> occur only once and without a version restriction).

From this text alone, it's not clear to me how this work with source
packages which generate multiple binary packages. Are all binary
packages AND-ed together as a single dependency for the test?

Given that large source packages can easily generate non-co-installable
binary packages, in those cases the maintainer should cherry pick the
specific dependencies test-by-test, am I reading it right?

> If no Depends field is present, `Depends: @' is assumed.  Note
> that the source tree's Build-Dependencies are _not_ necessarily
> installed, and if you specify any Depends, no binary packages from
> the source are installed unless explicitly requested.

So, to specify no test dependencies at all, "Depends: " is the way to
go, right? (In one of the two scenarios I've described in the beginning
this is a completely useless corner-case scenario, while in the other it
is not).

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, |  .  |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams


signature.asc
Description: Digital signature

Re: package testing, autopkgtest, and all that

[Ian Jackson]

Stefano Zacchiroli writes ("Re: package testing, autopkgtest, and all that"):
> I find "INSTALLED version of the program" to be ambiguous. It might
> refer to installed in the sense of 'debian/rules install' (or, to be
> more precise, 'debian/rules binary', given that 'install' is not
> dictated by policy). In that case the tests will use executables
> available under debian/tmp/* or the like.
> 
> Alternatively, it might refer to the currently installed *package*. In
> that case the tests will use executables installed along their $PATH.

The latter.

> The latter case needs some setup magic to install the just built
> package, but is more convenient for many software rely on hard-coded
> paths and do not permit to override them at runtime. The former case as
> converse pro/cons.

No, autopkgtest will install (dpkg -i, ultimately) the relevant stuff.
The tests just need to execute it.

I'd be happy to take suggestions for how to improve the wording to
make this clearer.

> >   Depends: 
> > 
> > Declares that the specified packages must be installed for the
> > test to go ahead.  `@' stands for the package(s) generated by the
> > source package containing the tests; each dependency (strictly,
> > or-clause, which may contain `|'s but not commas) containing `@'
> > is replicated once for each such binary package, with the binary
> > package name substituted for each `@' (but normally `@' should
> > occur only once and without a version restriction).
> 
> From this text alone, it's not clear to me how this work with source
> packages which generate multiple binary packages. Are all binary
> packages AND-ed together as a single dependency for the test?

Each dependency or-clause is replicated for each binary package.
Since the or-clauses are anded by dpkg, that's very like anding
together all the packages.

> Given that large source packages can easily generate non-co-installable
> binary packages, in those cases the maintainer should cherry pick the
> specific dependencies test-by-test, am I reading it right?

Yes; otherwise the test dependencies would be unsatisfiable.

> > If no Depends field is present, `Depends: @' is assumed.  Note
> > that the source tree's Build-Dependencies are _not_ necessarily
> > installed, and if you specify any Depends, no binary packages from
> > the source are installed unless explicitly requested.
> 
> So, to specify no test dependencies at all, "Depends: " is the way to
> go, right? (In one of the two scenarios I've described in the beginning
> this is a completely useless corner-case scenario, while in the other it
> is not).

Specifying no test dependencies at all is definitely wrong, because
there would be no software installed to be tested.

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/19782.45420.877853.707...@chiark.greenend.org.uk

Re: package testing, autopkgtest, and all that

[Ian Jackson]

Stefano Zacchiroli writes ("Re: package testing, autopkgtest, and all that"):
> 
>   I confess that this seems to be exactly one of those cases where the
>   DEP process (should) shine. By putting the specification in a more
>   visible place than (only) in an archive package we can give it more
>   visibility, easily point developers to it, monitor its acceptance
>   status, etc.
> 
>   Is anyone interested in driving (or co-driving) a DEP about this? The
>   current specification looks in good shape already, so what is needed
>   is probably just defining criteria for acceptance and launch a final
>   round of RFC to fix minor glitches (if any). I'm willing to help
>   because I think this topic is very important for us, but I'm not
>   willing to do that alone.
> 

I think this would be a fine idea.  I'd be happy to help with this
(but my skills may lie elsewhere than what is essentially a form of
marketing ...)

> The need of communication is easy to establish: as this thread has
> shown, very few developers were actually aware of all this valuable
> work. This specification deserves an announcement on d-d-a IMHO, asking
> for both comments and adoption.

Perhaps I should have posted to d-d-a during development.

> The best incentive for adoption in this case is having periodic runs of
> package tests, with reporting. At first glance, I'm tempted to propose
> to use grid archive rebuilds to run tests. Lucas: how much work would it
> be to hack your rebuild scripts and infrastructure to run tests (if
> available)? Lucas' approach to log digging has usually been
> collaborative: once a run is available, we ask on -qa to review
> logs. This is of course not as good as automatic reporting (e.g. a-la
> lintian.d.o), but is a start.

I'd love to see autopkgtest being run on the archive again.  As I say
I do test automation quite a lot in my day job now so my desire to
babysit another test automation system is rather less.  But I'd be
happy to help and advise.

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/19782.45604.121249.744...@chiark.greenend.org.uk

Upstream "stable" branches and Debian freeze

[Max Kellermann]

Hi,

I'm the upstream maintainer of the Music Player Daemon project, and
receive a number of support requests / bug reports from Debian users
who use the outdated version 0.15.12 of "mpd", currently in testing.
These bugs were already fixed in newer maintenance releases.

I know that Debian does not upgrade upstream versions at this point.
However, I would like to know if upgrading within an upstream "stable"
branch like MPD's v0.15.x would be acceptable.

It seems common practice to cherry-pick upstream patches, and apply
them to the old Debian package.  That however seems like a waste of
time, since all commits in our stable branch are bug fixes which would
need to be picked, and in the end, you would essentially have version
0.15.15 which prints "0.15.12" on --version, just to fulfill Debian's
policy.

For me personally, this boils down to the question: shall I continue
to maintain the old branch v0.15.x?  (there is also v0.16.x which is
also in maintenance mode)

If Debian picks up my maintenance releases, then it's worth it to keep
on maintaining the branch, to ensure that Debian users get the most
stable MPD version.  If not, I'll drop the branch, and fix bugs only
on v0.16.x.

Regards,
Max Kellermann

(Please keep me on Cc, I'm not subscribed)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110131142511.ga18...@squirrel.blarg.de

Re: Upstream "stable" branches and Debian freeze

[Michal Čihař]

Hi

Dne Mon, 31 Jan 2011 15:25:11 +0100
Max Kellermann  napsal(a):

> I'm the upstream maintainer of the Music Player Daemon project, and
> receive a number of support requests / bug reports from Debian users
> who use the outdated version 0.15.12 of "mpd", currently in testing.
> These bugs were already fixed in newer maintenance releases.
> 
> I know that Debian does not upgrade upstream versions at this point.
> However, I would like to know if upgrading within an upstream "stable"
> branch like MPD's v0.15.x would be acceptable.

It's probably too late now, but you could definitely do it during
freeze if it did fix some important bug.

-- 
Michal Čihař | http://cihar.com | http://blog.cihar.com


signature.asc
Description: PGP signature

Re: Upstream "stable" branches and Debian freeze

[Samuel Thibault]

Michal Čihař, le Mon 31 Jan 2011 16:01:54 +0100, a écrit :
> Dne Mon, 31 Jan 2011 15:25:11 +0100
> Max Kellermann  napsal(a):
> 
> > I'm the upstream maintainer of the Music Player Daemon project, and
> > receive a number of support requests / bug reports from Debian users
> > who use the outdated version 0.15.12 of "mpd", currently in testing.
> > These bugs were already fixed in newer maintenance releases.
> > 
> > I know that Debian does not upgrade upstream versions at this point.
> > However, I would like to know if upgrading within an upstream "stable"
> > branch like MPD's v0.15.x would be acceptable.
> 
> It's probably too late now, but you could definitely do it during
> freeze if it did fix some important bug.

His question could be rephrased: will the 6.0.x updates be allowed to
pick up new upstream "stable" fixes releases?

Samuel


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110131150933.gn6...@const.bordeaux.inria.fr

Re: package testing, autopkgtest, and all that

[Lucas Nussbaum]

On 31/01/11 at 00:29 +0100, Stefano Zacchiroli wrote:
> The best incentive for adoption in this case is having periodic runs of
> package tests, with reporting. At first glance, I'm tempted to propose
> to use grid archive rebuilds to run tests. Lucas: how much work would it
> be to hack your rebuild scripts and infrastructure to run tests (if
> available)?

Hi,

If there's a packaged tool to run the test suite on a given package,
then it's quite easy to integrate it into my infrastructure. But I
clearly do not have the time to get autopkgtest's code back in shape
first.

> Lucas' approach to log digging has usually been
> collaborative: once a run is available, we ask on -qa to review
> logs. This is of course not as good as automatic reporting (e.g. a-la
> lintian.d.o), but is a start.

Well, it has rarely worked like that. Most of the time, I just do the
log analysis + bug filing alone. That means that the tool to run the test
suite must be built with filing bugs in mind: it should provide all the
needed info in the logfile, so that developers can easily reproduce the
failure without asking the bug reporter.

- Lucas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110131151326.ga2...@xanadu.blop.info

Bug#611641: ITP: fadecut -- Radio livestream to ogg/mp3 tool

[Marco Balmer]

Package: wnpp
Severity: wishlist
Owner: Marco Balmer 

* Package name: fadecut
  Version : 0.0.1
  Upstream Author : Marco Balmer 
* URL : https://www.github.com/micressor/fadecut
* License : GPL v3
  Programming Lang: bash
  Description : Radio livestream to ogg/mp3 tool

 This script handle mp3 files (-ripped by streamripper), fade in and
 out. It set stream tags: artist, title and your own decided genre. 
 If you have songs you do not like, move the ripped file to dontlike/ folder,
 so fadecut will no longer convert this song, if it was read on the livestream. 
 All processed files of fadecut are in new/ folder. The original files from 
 streamripper are in the orig/ folder after processing.

-- System Information:
Debian Release: 5.0.7
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'testing')
Architecture: amd64 (x86_64)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110131152428.1450.64780.report...@mbalmer.nine.ch

Re: package testing, autopkgtest, and all that

[Ian Jackson]

Lucas Nussbaum writes ("Re: package testing, autopkgtest, and all that"):
> If there's a packaged tool to run the test suite on a given package,
> then it's quite easy to integrate it into my infrastructure. But I
> clearly do not have the time to get autopkgtest's code back in shape
> first.

Yes, there is such a packaged tool, "adt-run".  It worked last time I
tried it.

The options are a bit complicated because you have to specify exactly
what you want to do; the script "adt-testreport-onepackage" is what
I was using to invoke adt-run, and it runs it in broadly speaking two
ways:

  adt-run --source  ---...
 to check that the source builds with dependencies satisfied
 from the archive, and if it contains tests, run those tests
 with the resulting binary packages

  adt-run --binaries=install --binary  ---...
 to check that the package in question is installable

But another useful one would probably be:

  adt-run --built-binaries-filter=_ --source  ---...
 to check that the package's tests pass with binary packages
 currently in the archive (which almost other things tests that
 the package's dependencies haven't changed so as to break it)

I've enclosed a copy of the formatted manpage for adt-run, below.  It
seems to be missing the --instantiate option, whose usage message is:
 instantiate testbed now (during testing phase) and install
 packages selected for automatic installation, even if this might
 apparently not be required otherwise

> Well, it has rarely worked like that. Most of the time, I just do the
> log analysis + bug filing alone. That means that the tool to run the test
> suite must be built with filing bugs in mind: it should provide all the
> needed info in the logfile, so that developers can easily reproduce the
> failure without asking the bug reporter.

It's possible that autopkgtest could do with some work in this area;
currently the relevant output might be in more than one logfile.

Ian.


adt-run(1) Linux Programmer's Manualadt-run(1)



NAME
   adt-run - test an installed binary package using the package's tests

SYNOPSYS
   adt-run options...  --- virt-server [virt-server-arg...]

DESCRIPTION
   adt-run  is  the  program  for invoking the autopkgtest package testing
   machinery.

   autopkgtest is a facility for testing binary packages, as installed  on
   a  system  (such as a testbed system).  The tests are those supplied in
   the source package.

   adt-run runs each test supplied by a particular package and reports the
   results.  It drives the specified virtualisation regime as appropriate,
   and parses the test description metadata, and arranges for data  to  be
   copied to and from the testbed as required.

   adt-run should be invoked (unless options to the contrary are supplied)
   in the top level directory of the built source tree, on the host.   The
   package should be installed on the testbed.


PROCESSING INSTRUCTIONS
   --built-tree directory
  Specifies that tests from the built source tree directory should
  be run.  Note that the packages that would normally be installed
  as a result of * in the tests' Depends field (which includes the
  case  where  the  Depends  field  is  not  specified)  are   not
  installed.   The  caller  must  explicitly  instruct  adt-run to
  install any relevant packages.

   --source dsc
  Builds dsc.  The resulting binaries will (by default) be used to
  satisfy  dependencies.  The tests from that built tree will also
  be run (by default).  The ordering is significant: each --source
  option  should precede options whose dependencies are to be sat-
  isfied by the binaries it produces.

   --unbuilt-tree directory
  Specifies that tests from  the  unbuilt  source  tree  directory
  should  be  run.   This  is  very  similar to specifing --source
  except that a directory tree (which should be pristine) is  sup-
  plied, instead of a source package.

   --binary deb
  Specifies  that  deb should be used.  By default it will be used
  to satisfy dependencies, both during building and  testing,  but
  not  necessarily installed.  The ordering is significant, as for
  --source.

   filename
  Bare  filename  arguments  are  processed  as  if  --built-tree,
  --source,  --unbuilt-tree  or --binary was specified; the nature
  of the argument is guessed from the form of  the  filename.   In
  the  case  of --built-tree, either the option must be specified,
  or the filename must end in a slash; two slashes at the end  are
  taken to mean --unbuilt-tree.

PROCESSING OPTIONS
   These  af

Re: Upstream "stable" branches and Debian freeze

[Michael Gilbert]

On Mon, 31 Jan 2011 15:25:11 +0100, Max Kellermann wrote:
> Hi,
> 
> I'm the upstream maintainer of the Music Player Daemon project, and
> receive a number of support requests / bug reports from Debian users
> who use the outdated version 0.15.12 of "mpd", currently in testing.
> These bugs were already fixed in newer maintenance releases.
> 
> I know that Debian does not upgrade upstream versions at this point.
> However, I would like to know if upgrading within an upstream "stable"
> branch like MPD's v0.15.x would be acceptable.
> 
> It seems common practice to cherry-pick upstream patches, and apply
> them to the old Debian package.  That however seems like a waste of
> time, since all commits in our stable branch are bug fixes which would
> need to be picked, and in the end, you would essentially have version
> 0.15.15 which prints "0.15.12" on --version, just to fulfill Debian's
> policy.
> 
> For me personally, this boils down to the question: shall I continue
> to maintain the old branch v0.15.x?  (there is also v0.16.x which is
> also in maintenance mode)

It's too late now to make any changes for the initial squeeze release,
but you (or the Debian maintainer) can propose an update for 6.0.1,
which will be reviewed by the release team.  If the changes have a low
chance of breaking things, which it sounds like in this case, they will
usually accept it.

Best wishes,
Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110131105511.73108247.michael.s.gilb...@gmail.com

Bug#611651: ITP: libpod-wordlist-hanekomu-perl -- Add words for spell checking POD

[Dominique Dumont]

Package: wnpp
Owner: Dominique Dumont 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libpod-wordlist-hanekomu-perl
  Version : 1.110090
  Upstream Author : Marcel Gruenauer 
* URL : http://search.cpan.org/dist/Pod-Wordlist-hanekomu/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Collection of stop-words for POD spell check

Pod::Wordlist::hanekomu contains a list of words commonly found in POD
docementation. When Pod::Wordlist::hanekomu is loaded, this words are added 
as stopwords to Pod::Spell. Which means that these words will be ignored by 
the spell checker.

Enhances: libpod-wordlist-perl, libpod-spell-perl

This is a dependency of future package 
libdist-zilla-plugin-podspellingtests-perl

Dominique
--
http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/
http://www.ohloh.net/accounts/ddumont -o- http://ddumont.wordpress.com/



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201101311811.38805.domi.dum...@free.fr

Re: tcl8.5 breaks dpkg-cross assumptions and multiarch

[Jonathan Nieder]

(please drop cc's other than debian-policy in replies if you want to
work on that)

Hi Wookey,

Wookey wrote:

> Debian policy (8.2) says:
> ---
> It is recommended that supporting files and run-time support programs
> that do not need to be invoked manually by users, but are nevertheless
> required for the package to function, be placed (if they are binary)
> in a subdirectory of /usr/lib, preferably under /usr/lib/package-name.
> If the program or file is architecture independent, the recommendation
> is for it to be placed in a subdirectory of /usr/share instead,
[...]
> For multiarch, or existing
> dpkg-cross cross-compiling, to work, arch-dependent needs to mean
> either form _or_ content (see below for elaboration).

I always had thought that it's content and that the "if they are
binary" is only a red herring.  I agree with you that the policy ought
to be clarified.  Thanks for bringing this up.

Regards,
Jonathan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110131174653.GA31826@burratino

tcl8.5 breaks dpkg-cross assumptions and multiarch

[Wookey]

tcl8.5-dev contains /usr/lib/tcl8.5/tclConfig.sh
which is a symlink pointing to /usr/share/tcltk/tcl8.5/tclConfig.sh

Currently dpkg-cross only copies symlinks across when crossing a
package if the symlink points to somewhere within /lib. symlinks
outside /lib are ignored because they are not arch-dependent so
shouldn't need to be crossed. 

The file /usr/lib/tcl8.5/tclConfig.sh is used by packages which build
extensions to tcl (such as sqlite), so that files does need to be
present.

The file is essentially a cache of the config options TCL was built
with so that extensions can make sure they match up. However it is not
arch-independent. e.g. Line 22 of that file is
TCL_CC='x86_64-linux-gnu-gcc' on the x86_64
version and TCL_CC='arm-linux-gnueabi-gcc' on the armel version.
Other options also differ between 32-bit and 64-bit arches for example. 

So this file is arch-dependent in that it's different for each arch it
is built-on but arch-independent in that it's just a shell file. 

Debian policy (8.2) says:
---
It is recommended that supporting files and run-time support programs
that do not need to be invoked manually by users, but are nevertheless
required for the package to function, be placed (if they are binary)
in a subdirectory of /usr/lib, preferably under /usr/lib/package-name.
If the program or file is architecture independent, the recommendation
is for it to be placed in a subdirectory of /usr/share instead,
preferably under /usr/share/package-name. Following the package-name
naming convention ensures that the file names change when the shared
object version changes.

Files and support programs only useful when compiling software against
the library should be included in the development package for the
library
---
A maintainer reading the above could reasonably decide that /usr/share
was the right place for this file, because the file itself (being just
shell) is arch-independent. The problem is that the contents are
arch-dependent. Policy is not at all clear on this distinction (It's
been making my head hurt all day). For multiarch, or existing
dpkg-cross cross-compiling, to work, arch-dependent needs to mean
either form _or_ content (see below for elaboration).

The original tcl build puts both tclConfig.sh and tcl.m4 in /usr/lib
but the debian packaging moves them to
/usr/share/tcltk/tcl8.5 and /usr/share/aclocal/ respectively

Currently the sqlite build fails because it looks for tclConfig.sh in
/usr//lib/tcl8.5/ and doesn't find it there, because
dpkg-cross didn't copy the symlink (or original) there.

So, the questions is - which of these is the correct fix:
1) make dpkg-cross copy over symlinks even when they point into
/usr/share
2) make tcl8.5 put tclConfig.sh in /usr/lib/tcl8.5 instead of
/usr/share/tcltk/tcl8.5
3) make sqlite (and similar packages) look in /usr/share/tcltk/tcl8.5
instead of /usr/lib/tcl8.5 when building

I note that the supplied tcl8.5.m4 file actually lists a whole pile of
possible locations for the file:
  for i in `ls -d ${libdir} 2>/dev/null` \
`ls -d ${exec_prefix}/lib 2>/dev/null` \
`ls -d ${prefix}/lib 2>/dev/null` \
`ls -d /usr/local/lib 2>/dev/null` \
`ls -d /usr/contrib/lib 2>/dev/null` \
`ls -d /usr/share/tcltk/tk8.5 2>/dev/null` \
`ls -d /usr/lib 2>/dev/null` \
`ls -d /usr/lib64 2>/dev/null` \

However that list doesn't include anything ending in tcl8.5
(i.e /usr//lib/tcl8.5 or /usr/share/tcltk/tcl8.5) and perhaps
should by way of 'back-up plan', although I haven't actually looked
into the detals of how that is used.

Consideration when deciding how to fix this include:
Squeeze will be released in a few days with this broken so we will be
stuck with the /usr/share/ file location for some time there. Any fix
going into Ubuntu should make Natty easily enough.

For Multiarch tcl-dev will be a Multiarch:same package (i.e a
'library' package) (despite the name, it contains nothing but headers,
libraries and the above config.sh and m4 files), so the two different
tclConfig.sh files supplied by the DEB_BUILD_ARCH and DEB_HOST_ARCH
packages (when cross-building) will clash and the 2nd package will not
be installable. This, it seems to me, is the clinching argument that
the correct fix is to change the tcl build to put these files in
/usr/lib.

This also implies that policy 8.2 needs to be clarified to explain
what 'arch-independent' means.

Are there other situations which expect to find the tclConfig.sh file
in /usr/share? Is so those need considering.

Does anyone disgree with the above conclusions? And do people agree
that policy 8.2 could be clearer on this point?

I've filed a bug containing some of the above discussion and a patch
for tcl8.5. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611650

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Ball

A request for those attending key signing parties

[Theodore Ts'o]

At the most recent Linux.conf.au pgp keysigning, I noticed a number of
Debian developers present.  Like me, they had new keys that they offered
up for signing, presumably so they could start replacing their 1024DSA
keys with stronger keys.

If you are signing keys where you've verified the identity of fellow
Debian developers at a key signing party, please do us all a favor and
don't just sign it with your brand-new key --- but *also* sign the DD's
key with whatever key you you currently have currently in the Debian
keyring.

Otherwise, you could end up with a situation where a whole group of DD's
have each other's keys certified, but only signed with their new keys
--- which isn't useful when they are submitting their keys to the Debian
keyring maintainer for inclusion.

What I did was I signed the keys that I verified with *both* my new key
and the key I currently have in the Debian keyring.  However, to date,
although I've received key signatures from multiple people whom I know
to be Debian developers, my new key is only signed by one key which is
currently in the debian keyring.  (Thanks to Brendan O'Dea!)  At the
moment my new 4096 bit RSA key is waiting until I get more signatures,
or some of the new DDs' keys that have signed my key get accepted into
the Debian keyring.

- Ted


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/E1PjyoY-0003xV-OQ@tytso-glaptop

Bug#611660: ITP: tomb -- crypto undertaker

[Jaromil]

Package: wnpp
Severity: wishlist
Owner: Denis Roio 


* Package name: tomb
  Version : 0.9.0
  Upstream Author : Denis Roio 
* URL : http://tomb.dyne.org/
* License : GPLv3
  Programming Lang: C, Shell
  Description : crypto undertaker

Tomb is a free and easy to operate desktop application for fairly
strong encryption of personal files. A tomb is like a locked folder
that can be transported and hidden in filesystems; its keys are
password protected and can be kept separate, for instance keeping the
tomb file in your computer's harddisk and the key file on a USB stick.




-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110131183012.ga5...@dyne.org

Re: A request for those attending key signing parties

[Stefano Zacchiroli]

On Mon, Jan 31, 2011 at 01:49:26PM -0500, Theodore Ts'o wrote:
> If you are signing keys where you've verified the identity of fellow
> Debian developers at a key signing party, please do us all a favor and
> don't just sign it with your brand-new key --- but *also* sign the DD's
> key with whatever key you you currently have currently in the Debian
> keyring.

As I've been recently hit by this gotcha and as a memo for others, note
that if you are using caff, the following is *not* enough to fulfill the
above requirement:

  zack@usha:~$ grep keyid .caffrc 
  $CONFIG{'keyid'}   = [ qw{D5CA9B04F2C423BC 9C31503C6D866396} ];

you also need something like:

  zack@usha:~$ grep keyid .caffrc 
  $CONFIG{'local-user'}  = [ qw{D5CA9B04F2C423BC 9C31503C6D866396} ];

... or you need to remember passing "-u $KEYID,$OLDKEYID" to caff (yes,
I've defined the two environment variable for the transition period and
they come pretty handy).

Cheers


PS too bad LCA's signing party was at the same time of Tridge's talk :-(

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, |  .  |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams


signature.asc
Description: Digital signature

Re: Upstream "stable" branches and Debian freeze

[Christian PERRIER]

Quoting Max Kellermann (m...@duempel.org):

> I'm the upstream maintainer of the Music Player Daemon project, and
> receive a number of support requests / bug reports from Debian users
> who use the outdated version 0.15.12 of "mpd", currently in testing.
> These bugs were already fixed in newer maintenance releases.
> 
> I know that Debian does not upgrade upstream versions at this point.
> However, I would like to know if upgrading within an upstream "stable"
> branch like MPD's v0.15.x would be acceptable.


I have about the same concern for samba..:-)
(except that I'm not samba upstream as most people know...)

For the lenny release cycle, we (samba maintainers...indeed often me)
pushed several upstream fixes for bugs reported in Debian with severity
"important". This, in addition, of course, to the security fixes.

This has been accepted by the Stable Release Team in each case.

However, upstream's policy in their "stable" branches is alway to only
fix "important" bugs (they don't call them this way...but the
definition is fairly close to Debian's). So, *in the case of samba*, I
can guarantee that the user's (indeed sysadmin's) experience is much
improved if (s)he can follow the upstream minor releases.

So, I'm strongly considering asking the SRT if it would be OK to track
samba 3.5 branch along the life of squeeze (we'll be releasing with
samba 3.5.6).

This is certainly a trade-off to do on a case-by-case basis. In the
case of samba, I'm as certain as one can be that upstream's policy is
strict enough for me to more or less blindly follow them (particularly
just right now as samba 3.5 has aged enough in the Samba Team
barrels...;-)). The situation may be different for other upstreams, of
course.







signature.asc
Description: Digital signature

Re: tcl8.5 breaks dpkg-cross assumptions and multiarch

[Loïc Minier]

 For this specific tcl issue, there was some discussion in Debian
 #599206; I didn't comment back on the bug, but I liked Goswin's
 proposal

-- 
Loïc Minier


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110131193005.gb14...@bee.dooz.org

Re: A request for those attending key signing parties

[Martin Zobel-Helas]

Hi, 

a more theoretical question quite related to this:

If one plans to have the key replaced in the keyring, and we have a
fellow DD in the keyring who's only trust path to other Debian
Developers goes via that key (this might become a real scenario when we
do a bigger round of key replacements) will that key replacement really
happen? Thus CCing keyring maintainers.

Cheers,
Martin
-- 
 Martin Zobel-Helas   | Debian System Administrator
 Debian & GNU/Linux Developer   |   Debian Listmaster
 Public key http://zobel.ftbfs.de/5d64f870.asc   -   KeyID: 5D64 F870
 GPG Fingerprint:  5DB3 1301 375A A50F 07E7  302F 493E FB8E 5D64 F870


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110131201818.gk13...@ftbfs.de

Re: tcl8.5 breaks dpkg-cross assumptions and multiarch

[Steve Langasek]

Hi Wookey,

On Mon, Jan 31, 2011 at 05:16:15PM +, Wookey wrote:

> Debian policy (8.2) says:
> ---
> It is recommended that supporting files and run-time support programs
> that do not need to be invoked manually by users, but are nevertheless
> required for the package to function, be placed (if they are binary)
> in a subdirectory of /usr/lib, preferably under /usr/lib/package-name.
> If the program or file is architecture independent, the recommendation
> is for it to be placed in a subdirectory of /usr/share instead,
> preferably under /usr/share/package-name. Following the package-name
> naming convention ensures that the file names change when the shared
> object version changes.

> Files and support programs only useful when compiling software against
> the library should be included in the development package for the
> library
> ---
> A maintainer reading the above could reasonably decide that /usr/share
> was the right place for this file, because the file itself (being just
> shell) is arch-independent. The problem is that the contents are
> arch-dependent. Policy is not at all clear on this distinction (It's
> been making my head hurt all day). For multiarch, or existing
> dpkg-cross cross-compiling, to work, arch-dependent needs to mean
> either form _or_ content (see below for elaboration).

I disagree that this would be a reasonable thing for the maintainer to do.
The current policy language talks about architecture-dependence of the
*file*, not of a file *format*, and there are obviously file formats that
are architecture-independent but contain architecture-specific data that
must therefore be part of an architecture: any package.

So I think this is a clear policy violation in the existing tcl8.5-dev
package; even if 8.2 doesn't prohibit the current behavior, the FHS surely
does.[1]  So I think your filing of bug #611650 was the correct course of
action and the maintainer appears to agree.

That said, I'm also happy to second patches to policy that clarify the
wording and save maintainers from thinking it's ok to ship such files under
/usr/share when it isn't.

> So, the questions is - which of these is the correct fix:
> 1) make dpkg-cross copy over symlinks even when they point into
> /usr/share
> 2) make tcl8.5 put tclConfig.sh in /usr/lib/tcl8.5 instead of
> /usr/share/tcltk/tcl8.5
> 3) make sqlite (and similar packages) look in /usr/share/tcltk/tcl8.5
> instead of /usr/lib/tcl8.5 when building

1+2: dpkg-cross should also copy over symlinks that point to /usr/share.
When such symlinks exist, it's almost invariably because *something is
looking for the information in that location*.  So as a general policy, they
should also be made available in a crossed package.

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.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org

[1] /usr/share : Architecture-independent data


signature.asc
Description: Digital signature

Re: Upstream "stable" branches and Debian freeze

[Tollef Fog Heen]

]] Samuel Thibault 

Hi,

| His question could be rephrased: will the 6.0.x updates be allowed to
| pick up new upstream "stable" fixes releases?

While I can't speak for the release team (neither the stable or the
«regular» one), I know that postgresql stable releases are generally
allowed into new stable releases, since they're about as picky and
conservative as we are with regards to what the backport to their stable
branches.

So, I think this depends on what the policy for the upstream branch is.
If it's just important fixes, it might be.  If it's a random mix of new
features, bug fixes and so on, it's less likely.

Best regards,
-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87k4hk964c@qurzaw.varnish-software.com

Bug#611679: ITP: node-postgres -- PostgreSQL client library for Node

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

* Package name: node-postgres
  Version : 0.2.6
  Upstream Author : Brian Carlson 
* URL : https://github.com/brianc/node-postgres
* License : Expat
  Programming Lang: JavaScript
  Description : PostgreSQL client library for Node

 Node is an event-based server-side JavaScript engine.
 .
 node-postgres is a non-blocking (async) pure JavaScript PostgreSQL
 client library for Node.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110131215431.2773.21508.reportbug@localhost.localdomain

Re: tcl8.5 breaks dpkg-cross assumptions and multiarch

[Neil Williams]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 31/01/11 20:18, Steve Langasek wrote:
> On Mon, Jan 31, 2011 at 05:16:15PM +, Wookey wrote:
>> So, the questions is - which of these is the correct fix:
>> 1) make dpkg-cross copy over symlinks even when they point into
>> /usr/share
>> 2) make tcl8.5 put tclConfig.sh in /usr/lib/tcl8.5 instead of
>> /usr/share/tcltk/tcl8.5
>> 3) make sqlite (and similar packages) look in /usr/share/tcltk/tcl8.5
>> instead of /usr/lib/tcl8.5 when building
> 
> 1+2: dpkg-cross should also copy over symlinks that point to /usr/share.

The reason not to copy is that the target of the symlink does not exist
in the -cross package and the one that exists in the native package in
/usr/share contains all the wrong paths. A dangling symlink would be
left if the -cross package is not installed. If the symlink is to be
copied over not into /usr/share but into /usr/arm-linux-gnueabi/share
then the native version of the file will still exist in /usr/share and
none of the existing tools will look into /usr/arm-linux-gnueabi/share
to find the correct version without a new wrapper. Nobody wins.

dpkg-cross cannot reliably identify which symlinks should be preserved
and how. dpkg-cross cannot copy across all symlinks which point to
/usr/share because a lot of those are unwanted.

The correct fix is 2.

The only possible thing dpkg-cross could do is reverse the symlink and
move the file from /usr/share into /usr/arm-linux-gnueabi/lib/ if a
symlink to /usr/lib/ exists and not create the symlink in
/usr/arm-linux-gnueabi/share at all - at which point the native version
of the package still contains the symlink from /usr/share to /usr/lib/
with the native paths. Is that what is actually being requested for 1.?
I don't see that it's reliable - it's masking the real bug with a
horrible hack, again. How does this help when the package itself is
buggy by not complying with the FHS and the cross-build looks in the
wrong place?

> When such symlinks exist, it's almost invariably because *something is
> looking for the information in that location*.

When is this not actually a bug in that package?

The maintainer has agreed to fix the actual bug by implementing option 2
above, which we all seem to agree is the appropriate and optimal fix for
the original issue. Under what circumstances would some other package
fall into this problem *without* also being buggy in exactly the same
way as tcl8.5?

Yes, let's clarify policy but I don't think it's correct to expect
dpkg-cross to handle packages which are simply buggy whilst risking
breaking other packages which do things properly. dpkg-cross doesn't
(and shouldn't) support package-specific exceptions in how -cross
packages are created.

>  So as a general policy, they
> should also be made available in a crossed package.

The /usr/share/ location *must* change in the cross package so that it
can be installed alongside the native, at which point any merit of
retaining /usr/share is lost in the cross package because a wrapper
script will still be needed to find the modified location, handle the
dangling symlink or risk getting the wrong data (because the data in
this case is clearly wrong for the cross build).

Either the file is in the wrong place (as in this case) or the change of
location is simply going to break without a package-specific wrapper
script anyway because the locations of things in /usr/share should not
(need to) change to support a cross-build.

- -- 


Neil Williams
=
http://www.linux.codehelp.co.uk/

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJNR0GdAAoJEPFn5DyBQ7aC2lcP/1K8gLDnYffSZSb9lVarDh89
Rmvk1FLIHzJQ29kWYLE29ybpLCma7ms4T+PloVv7KLWMvS36jkLiCuM+a/sP8eU3
3uPkZ5rFTflXy8q2H4MhF/CQa94QExxthpDHgeQntz9j+5dKp+Nj3uNQaHjdh6XC
aY+tyMulpwaR/B0gpQXtgAKffqvKtInLQDXnNd4YWEXbRgMndm9d37GyzYdVdOsz
/udBf57SpQXuLX2M4d1cX1QmbUpwMqD3P7PeZQj7gcwX0loupm6MNFb7VQJM6gKp
d6o/AYBBg2X3addJMDVQZdNsNYfFm0F6JfTlk0pgNyFUOGPFmyNFxOT3QjufloY9
ZH+xmvgC9UL6gSv5voQUIezn2MSLGblP648RwW8RgdHslNG60v6I22VcZSQDkcw4
BE2CUn/Y1w+q1A74MGSAPV7lB2b9QRnxjec1xfyo11as27mudlDKwFtrGI6mzDGk
oZf/SYGkCQ1cOscq1aVJGkJocfA4rlwbM67zfFybz5W9j8UZSYOVX9F1oh/OpRPF
UQNaWyiOF4lf/EUf3Ct7F6Dwz9TPKhxpRgwg3kfQqTlsgjLK/a1zIf4F1h1EjP4H
f0sAhgJrYQkFUW8w1LDhK92EEDZdHW7De0cA/7tx4h/8ay+NdrcpEOMWTFDoGrcy
QC4k9mp+Xwnaq78yHWaz
=clO0
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d4741a0.9040...@debian.org

Bug#611686: ITP: festvox-mbrola -- mbrola voices support for festival

[Samuel Thibault]

Package: wnpp
Severity: wishlist
Owner: Samuel Thibault 


* Package name: festvox-mbrola
  Version : 1.95
  Upstream Author : Centre for Speech Technology Research University of 
Edinburgh, UK
* URL : http://www.cstr.ed.ac.uk/projects/festival/
* License : BSD
  Programming Lang: scheme
  Description : mbrola voices support for festival

This package lets festival make use of the non-free mbrola sample-based
voices instead of its own synthesis voices, to improve its output.

This would go to contrib, of course.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110131230818.ga14...@const.famille.thibault.fr

Bug#611690: ITP: nautilus-image-manipulator -- Resize and send images from Nautilus

[Emilien Klein]

Package: wnpp
Severity: wishlist
Owner: Emilien Klein 


* Package name: nautilus-image-manipulator
  Version : 0.2
  Upstream Author : Emilien Klein 
* URL : https://launchpad.net/nautilus-image-manipulator
* License : GPL 3
  Programming Lang: Python
  Description : Resize and send images from Nautilus

This Nautilus extension lets you resize images and send them to friends
and family, right from Nautilus.

Just right-click on any photo or group of photos, and an option will
appear that launches Nautilus Image Manipulator.

It is highly inspirated by Nautilus Image Converter:
http://www.bitron.ch/software/nautilus-image-converter.php

Note: This is my first intent to create a Debian package. Any
comments are welcomed!



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110131232555.8661.26586.reportbug@tesla

CPE lists was Re: Equivalent packages between Linux distributions

[Silvio Cesare]

I created an automatically generated CPE list for Fedora13 packages. It only
has 300 or so packages in it, but this will improve as say Debian increase
the list of packages they track (they only track 1100 or so currently).

https://github.com/silviocesare/Equivalent-Packages/blob/master/CPE/Fedora13.CPE.generated

To generate the list I build a list of equivalent packages between Debian
and Fedora
https://github.com/silviocesare/Equivalent-Packages/blob/master/NearestNeighbour/Debian5_Fedora13_Matches.
I then use Debian's CPE list
http://svn.debian.org/wsvn/secure-testing/data/CPE/listto
document the equivalent packages in Fedora.

This should work fine for other Distributions also.

--
Silvio Cesare

Re: tcl8.5 breaks dpkg-cross assumptions and multiarch

[Wookey]

+++ Steve Langasek [2011-01-31 12:18 -0800]:
> > So, the questions is - which of these is the correct fix:
> > 1) make dpkg-cross copy over symlinks even when they point into
> > /usr/share
> > 2) make tcl8.5 put tclConfig.sh in /usr/lib/tcl8.5 instead of
> > /usr/share/tcltk/tcl8.5
> > 3) make sqlite (and similar packages) look in /usr/share/tcltk/tcl8.5
> > instead of /usr/lib/tcl8.5 when building
> 
> 1+2: dpkg-cross should also copy over symlinks that point to /usr/share.
> When such symlinks exist, it's almost invariably because *something is
> looking for the information in that location*.  So as a general policy, they
> should also be made available in a crossed package.

But if something is looking for arch-independent stuff in /lib then in
general that's wrong, and I'm not aware of any examples of
correctly-packaged packages that need this. Any arch-independent files
will be supplied by an arch all package that the build should depend
on if needed.

dpkg-cross has gone for 10 years without needing symlinks pointing into
/usr/share, so I'm reluctant to add them without some evidence that
it's actually correct. Its policy of only crossing arch-dependent
files is the right one, I believe.  (It does allow symlinks within
/usr/src which presumably has/had a good reason.)

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110201005222.gm4...@dream.aleph1.co.uk

Bug#611698: nodejs: conflicts with package node needlessly

[brian m. carlson]

Package: nodejs
Version: 0.2.6-1
Severity: serious
Tags: experimental

It appears that nodejs in experimental has acquired a Conflicts with
node.  According to the changes file for that release:

   * Use upstream binary names for node and node-waf,
 conflicts with node package. (Closes: #597571)

I still don't believe that is allowed by Debian Policy.  Section 10.1
states:

 Two different packages must not install programs with different
 functionality but with the same filenames.  (The case of two programs
 having the same functionality but different implementations is handled
 via "alternatives" or the "Conflicts" mechanism.  See Section 3.9,
 `Maintainer Scripts' and Section 7.4, `Conflicting binary packages -
 `Conflicts'' respectively.) If this case happens, one of the programs
 must be renamed.  The maintainers should report this to the
 `debian-devel' mailing list and try to find a consensus about which
 program will have to be renamed.  If a consensus cannot be reached,
 _both_ programs must be renamed.

#597571 had been marked wontfix, but then was mysteriously closed in
experimental.  If this isn't in contravention of Debian Policy (which is
possible, I suppose), then what's been done to resolve it so it isn't
should be put in README.Debian or NEWS.Debian.

-- System Information:
Debian Release: 6.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.37-trunk-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

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


signature.asc
Description: Digital signature