Bug#650248: ITP: pylibravatar -- Libravatar module for Python

[Francois Marier]

Package: wnpp
Severity: wishlist
Owner: Francois Marier 

* Package name: pylibravatar
  Version : 1.5
  Upstream Author : Francois Marier 
* URL : https://launchpad.net/pylibravatar
* License : MIT
  Programming Lang: Python
  Description : Libravatar module for Python

 Module to make use of the federated Libravatar.org avatar hosting service
 from within Python applications.



-- 
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/2028081617.3885.30461.report...@isafjordur.dyndns.org

Re: Re: The mingw* mess in Debian

[Fabian Greffrath]

To provide all the binaries in gcc-mingw32 it will have to depend on
{gcc,g++,gfortran}-mingw-w64-i686; its only contents will be the
compatibility symlinks you mention (and the usual /usr/share/doc contents).
It will pull in mingw-w64-i686-dev indirectly, and binutils-mingw-w64-i686
too.


This sounds like a lot of packages to get lost in. Will you still get 
*everything* if you install the mingw-w64 meta-package?



As I understand it having the mingw-w64 package produce a gcc-mingw32 package
will make the gcc-mingw32 source package disappear eventually...


A prior message to ftp-masters won't hurt, however. ;)

 - Fabian


--
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/4ed34778.1040...@greffrath.com

Bug#650250: ITP: txlibravatar -- Libravatar module for Twisted

[Francois Marier]

Package: wnpp
Severity: wishlist
Owner: Francois Marier 

* Package name: txlibravatar
  Version : 1.0
  Upstream Author : Francois Marier 
* URL : https://launchpad.net/txLibravatar
* License : MIT
  Programming Lang: Python
  Description : Libravatar module for Twisted

 Module to make use of the federated Libravatar.org avatar hosting service
 from within Twisted applications.
 .
 Libravatar is a free service for hosting profile images tied to an email
 address or an OpenID. Inspired by the elegant solution pioneered by
 Gravatar, Libravatar takes a federated approach to the problem and allows
 domain owners to specify the server that should host images for their
 organisation.



-- 
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/2028090234.17888.96372.report...@isafjordur.dyndns.org

Re: Lintian ERROR saying dpatch is obsolete

[Alexander Wirt]

Gergely Nagy schrieb am Sonntag, den 27. November 2011:

Hi,

> > Recently [1], dpatch's maintainer uploaded a new version indicating
> > that dpatch is now deprecated.  Following that, he filed a bug [2] so
> > that lintian might warn that dpatch's makefile has been deprecated
> > since 2003, and that dpatch itself is now deprecated.  However, he
> > also stated that he plans to keep dpatch for wheezy.
> 
> Just for the record, to reiterate what I have said previously[1], dpatch
> will be kept around until it can be removed safely: when all reverse
> build-depends have been migrated to something else.
> 
>  [1]: http://lists.debian.org/debian-devel/2011/08/msg00380.html
> 
> That certainly won't happen before wheezy, and is unlikely to happen for
> wheezy+1, too. My plan still is to phase out dpatch by wheezy+2, but
> until then, it's a legacy that should be migrated away from, and must
> not be used for new packages.
Since there is no proper alternative (no quilt is not) I will continue to use
dpatch for all of my packages. If neccessary I would volunteer to take over
upstream.

So if you are just going for leftover rdeps it will probably never be
removed.

Alex


-- 
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/2028103201.ga3...@hawking.credativ.lan

Bug#650261: ITP: thredds -- Data server (middleware) for scientific data

[Alastair McKinstry]

Package: wnpp
Severity: wishlist
Owner: Alastair McKinstry 

* Package name: thredds
  Version : 4.2.9
  Upstream Author : UCAR
* URL : http://www.unidata.ucar.edu/software/tds/ 
* License : MIT
  Programming Lang: Java
  Description : Data server (middleware) for scientific data

 The THREDDS Data Server (TDS) is a web server that provides metadata
 and data access for scientific datasets, using OPeNDAP, OGC WMS and
 WCS, HTTP, and other remote data access protocols. 



-- 
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/2028104337.19678.78864.report...@ailm.sceal.ie

Re: Lintian ERROR saying dpatch is obsolete

[Gergely Nagy]

Alexander Wirt  writes:

>> > Recently [1], dpatch's maintainer uploaded a new version indicating
>> > that dpatch is now deprecated.  Following that, he filed a bug [2] so
>> > that lintian might warn that dpatch's makefile has been deprecated
>> > since 2003, and that dpatch itself is now deprecated.  However, he
>> > also stated that he plans to keep dpatch for wheezy.
>> 
>> Just for the record, to reiterate what I have said previously[1], dpatch
>> will be kept around until it can be removed safely: when all reverse
>> build-depends have been migrated to something else.
>> 
>>  [1]: http://lists.debian.org/debian-devel/2011/08/msg00380.html
>> 
>> That certainly won't happen before wheezy, and is unlikely to happen for
>> wheezy+1, too. My plan still is to phase out dpatch by wheezy+2, but
>> until then, it's a legacy that should be migrated away from, and must
>> not be used for new packages.
> Since there is no proper alternative (no quilt is not) I will continue to use
> dpatch for all of my packages. If neccessary I would volunteer to take over
> upstream.

I'd rather figure out what makes dpatch better than quilt for your
use-cases, and go from there.

My goal is not to force people when they really don't have an
alternative - I want to find an alternative for these cases. The lintian
check is mostly there for those cases where an alternative exists, but
it wasn't migrated to out of, lets say, lack of motivation.

> So if you are just going for leftover rdeps it will probably never be
> removed.

Nope, I'm not going only for leftover rdeps. I'll investigate the harder
cases too, where migration is either non-trivial, or it involves finding
a suitable alternative (be that quilt, something built around quilt, or
something completely different).

I planned to do this by first getting rid of the easy ones, but if
people who prefer dpatch over other solutions step up and tell me up
front why they're happy with dpatch, and unhappy with the things I
consider alternatives, so much the better!

While you did mention on IRC that you're unhappy with quilt, and prefer
dpatch over it, I'm afraid I don't remember the reasons why that is
so. If you could share those, that would be very welcomed.

And anyone else, who dislikes my decision of deprecating dpatch: let me
know why you prefer dpatch over, say, quilt. The goal is not to make our
lives miserable, but to fix up the alternatives to be as good, or
better, than dpatch.

-- 
|8]


-- 
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/87sjl85xgz.fsf@algernon.balabit

Re: Lintian ERROR saying dpatch is obsolete

[Raphael Hertzog]

On Mon, 28 Nov 2011, Alexander Wirt wrote:
> Since there is no proper alternative (no quilt is not) I will continue to use
> dpatch for all of my packages. 

Is it only the fact that dpatch "patches" can be scripts that justify this
assertion?

If not, I would be interested to learn why quilt is not a proper
alternative.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/go/ulule-rh/


-- 
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/2028105525.gg3...@rivendell.home.ouaza.com

Bug#650266: ITP: jenkins-htmlunit -- Jenkins branch of HtmlUnit browser testing for web apps

[James Page]

Package: wnpp
Severity: wishlist
Owner: James Page 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: jenkins-htmlunit
  Version : 2.6-jenkins-6
* URL : http://github.com/jenkinsci/htmlunit
* License : Apache-2.0
  Programming Lang: Java
  Description : Jenkins branch of HtmlUnit browser testing for web apps

 HtmlUnit is a java GUI-Less browser, which allows high-level manipulation
 of web pages, such as filling forms and clicking links; just getPage(url),
 find a hyperlink, click() and you have all the HTML, JavaScript, and Ajax 
 are automatically processed.
 .
 This package is the branch used/maintained by the jenkins project.


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBCAAGBQJO02nvAAoJEL/srsug59jDlngP/AlrxFYV9ktmZG/g7tyB/Rvc
3/7CPX81PaqDF+ZGzSwoSjMC4HTKFvYYh5yYbaXoKVUyrLPMziTKZE9K2gK+cskP
3+qUSTxtncu6G2REu1cT45Wl4C14VeS1zRjoTbUa60o7bWZJQU5vdzAzxHq6uxNs
3RErWHnB75SR8XvvCWfq23n2hONugtjINxih6KZMoXTCaPvFQfi/UidKZ9McMvs6
Wg9xaaR51lXt/6hvxCfx4iSl5Ko7sn1eXIjw8pq9meGopepkmnkVhALl/y7HMud/
R3BbxCRF8uNf6UT5qQn0og6rLryRuWrd3SCsayLKRr2tGKLqzW3FDNh8Jbd2eYbM
jKyYXoKMi+JIQR6uLemr4kxHurnRbm3K2vpZwMi3nB5fowk8eL326iamMR/CPazI
ioYtEiw9bFz4eV10TmlrOjMDJVcxp2xgvsF35YFGQhFeYw1e1C0KvUcE480W6Y6f
EEURXqMwe+FvJ315vV0pwutlMRfjArokJSDLy2M0d5LG1tmdRlvJKOGv9IGYu5Sx
r+DNDhtgvQV0I9khDy/kLUFgRvmf7fix9a5NiK4BoPB+D/9zbtuqN91iu8BvYZpy
+2AnSFnsItkKRSQlzZqxFqwpjw9h89+/HUdYINaERYuu8k/DV/VTloZDIhg/Z5ad
gJHU1VZDeXO+8JvhyoIF
=3Vwt
-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/2028110106.3620.65784.reportbug@hendrix.shouse.local

Re: Lintian ERROR saying dpatch is obsolete

[Alexander Wirt]

Gergely Nagy schrieb am Montag, den 28. November 2011:

> Alexander Wirt  writes:
> 
> >> > Recently [1], dpatch's maintainer uploaded a new version indicating
> >> > that dpatch is now deprecated.  Following that, he filed a bug [2] so
> >> > that lintian might warn that dpatch's makefile has been deprecated
> >> > since 2003, and that dpatch itself is now deprecated.  However, he
> >> > also stated that he plans to keep dpatch for wheezy.
> >> 
> >> Just for the record, to reiterate what I have said previously[1], dpatch
> >> will be kept around until it can be removed safely: when all reverse
> >> build-depends have been migrated to something else.
> >> 
> >>  [1]: http://lists.debian.org/debian-devel/2011/08/msg00380.html
> >> 
> >> That certainly won't happen before wheezy, and is unlikely to happen for
> >> wheezy+1, too. My plan still is to phase out dpatch by wheezy+2, but
> >> until then, it's a legacy that should be migrated away from, and must
> >> not be used for new packages.
> > Since there is no proper alternative (no quilt is not) I will continue to 
> > use
> > dpatch for all of my packages. If neccessary I would volunteer to take over
> > upstream.
> 
> I'd rather figure out what makes dpatch better than quilt for your
> use-cases, and go from there.
Usability. Hacks like .pc, or the hacks/patches it has for finding this
directory. 

Dpatch is small and simple, quilt is a beast that trickled me several times
in other projects. 

> Nope, I'm not going only for leftover rdeps. I'll investigate the harder
> cases too, where migration is either non-trivial, or it involves finding
> a suitable alternative (be that quilt, something built around quilt, or
> something completely different).
> 
> I planned to do this by first getting rid of the easy ones, but if
> people who prefer dpatch over other solutions step up and tell me up
> front why they're happy with dpatch, and unhappy with the things I
> consider alternatives, so much the better!
Its simple and things like dpatch-edit-patch are just great. I now use dpatch
for round 8 years and it worked every time. I don't see any reason to move
away.

And I still like the "never touch a running system" approach. If dpatch works
without problems, why deprecate it?

Alex


-- 
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/2028115457.gb3...@hawking.credativ.lan

Re: Lintian ERROR saying dpatch is obsolete

[Alexander Wirt]

Raphael Hertzog schrieb am Montag, den 28. November 2011:

> On Mon, 28 Nov 2011, Alexander Wirt wrote:
> > Since there is no proper alternative (no quilt is not) I will continue to 
> > use
> > dpatch for all of my packages. 
> 
> Is it only the fact that dpatch "patches" can be scripts that justify this
> assertion?
> 
> If not, I would be interested to learn why quilt is not a proper
> alternative.
It has nothing to do with script. It is implementation and usability. 

And the problem that debians dpatchs is full of evil patches that makes it
just incompatible to other quilts on non-debian systems. 
 
Imho the whole 3.0 quilt thingy just went wrong, instead of hacking around an
existing system it would have been better to have a specialised set of tools
around dpkg. But I think I said this some time ago. 

Alex


-- 
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/2028120044.gc3...@hawking.credativ.lan

Re: libconfig9 for Wheezy?

[Andrey Ponomarenko]

The compatibility report for libconfig between libconfig8/1.3.2 and 
libconfig9/1.4.8 versions (see attachment) generated by the 
abi-compliance-checker [1] tool may be of help to upgrade this package.


[1] http://forge.ispras.ru/projects/abi-compliance-checker/files

On 11/15/2011 10:15 PM, Jonathan McCrohan wrote:

Hi,

libconfig [1] has not been updated since Squeeze, and is lagging
upstream by a major version.

Packaging the upstream release is not a problem, but an ABI change will
require a transition from libconfig8 to libconfig9.

The maintainer is aware of the problem, and this has been tracked as
wishlist bug #583528 since May 2010 [2].

Is there enough time left to have this updated before the Wheezy freeze
window?

Thanks,
Jon

[1]http://packages.qa.debian.org/libc/libconfig.html
[2]http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=583528




  -- Andrey Ponomarenko



abi_compat_report.html.tar.gz
Description: application/tgz

Re: Lintian ERROR saying dpatch is obsolete

[Arno Töll]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Raphaël,

On 28.11.2011 11:55, Raphael Hertzog wrote:
> On Mon, 28 Nov 2011, Alexander Wirt wrote:
>> Since there is no proper alternative (no quilt is not) I will continue to use
>> dpatch for all of my packages. 
> 
> Is it only the fact that dpatch "patches" can be scripts that justify this
> assertion?

that's exactly the problem I'm facing for a migration of dpatch to quilt
I'm working on. There is no possible solution to execute any code/rules
target before a 3.0 source package applies patches, right?

Given that, I'd need to --skip-patches and use quilt on my own again,
there is no smarter way then which makes the migration to 3.0/quilt not
really an improvement.

On the other hand, if dpkg would support a rules target to be executed
before applying patches, that would be a great improvement. Or,
alternatively most patches-which-are-scripts could be avoided if quilt
had better support for removing/copying/renaming files.

- -- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJO04IlAAoJEMcrUe6dgPNta9QQAKxwCA/+FA4uAe+zE5hdJSDF
UKOUnBXdx9mhciYSBoV1fTlEN5sbDXWoGOYOaNck8EMW7ojeD5T4N86ybNL91Yzm
40dGSspoRVKuXenAjLkmdvUwJSq3ZR3D+psmMPjcH7h/NiAqyGy+fDZ8XTsF6dwO
cHOEUuXGE3Zeq4p8inUEVxSzFMvac6Fr1AHm7+6aBjO53Fp8q90MKcNA3QcJRPth
vkp3wQ/9qPUujZzD4pxiz8SZJ4PanlMsaMRKHYg9Fs86xiHcUPMH36q7zv5CVe4H
L3Okcczz51U4wBWGcH0XGPt6zOLuwZp2jho2H+tq6uCtzpIGcMavgze+GYb8rs5p
CfzutFxoIZprAeLtSG5pOkFeU8TTq6yW1ar9yDkHcASy1XShGA9v0FwhccLjDuk7
comVmL245t1BkDOi4wtz6fjLsQb9CerDiWKDZ6x2ReF1J8Fjhynw05so3syFZkHt
SOEpXIujP0pJDGibBji2TEXpnj4EzAYoK1yZ871893ryGdsXfZZH9fZeS1wseK7Y
lRHLOaJGFs8d9nb77TCAvZQmXmSuyKsmwJic2i1TjfestwS058tE7CoYN3Uqdg3a
EO1N6h8owUr2v3h0N5TszfuseCgkm3ylTEiKaMPUZoFo8bBOqAEltwLL8a3VdrfJ
DTPK/mv+Wiy3IKH9pEdd
=NYXf
-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/4ed38225.1020...@toell.net

Re: Lintian ERROR saying dpatch is obsolete

[Ian Jackson]

Arno Töll writes ("Re: Lintian ERROR saying dpatch is obsolete"):
> On the other hand, if dpkg would support a rules target to be executed
> before applying patches, that would be a great improvement. Or,
> alternatively most patches-which-are-scripts could be avoided if quilt
> had better support for removing/copying/renaming files.

It's a fundamental problem with this approach which cannot be solved,
I'm afraid.  We want to be able to safely inspect a source package.
That means that unpacking it should not execute part of it.

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/20179.33945.377101.746...@chiark.greenend.org.uk

Re: Is anyone using the Units program in a script? [and 1 more messages]

[Ian Jackson]

Bob Proulx writes ("Re: Is anyone using the Units program in a script? [and 1 
more messages]"):
> For this type of question under discussion of a utility such as
> 'units' I would suggest using the bug-gnu-ut...@gnu.org mailing list.
> It is widely subscribed to by those interested in the utilities.  It
> seems like the perfect fit for this type of question and discussion.
> If anyone has similar questions in the future then bug-gnu-utils is a
> great place to have that discussion.

bug-gnu-utils is I'm afraid not a good place to have that discussion.
The people who need to know that a utility they have been relying on
might change incompatibly aren't on that list.

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/20179.34036.832595.236...@chiark.greenend.org.uk

Re: Lintian ERROR saying dpatch is obsolete

[Colin Watson]

On Mon, Nov 28, 2011 at 01:44:21PM +0100, Arno Töll wrote:
> that's exactly the problem I'm facing for a migration of dpatch to quilt
> I'm working on. There is no possible solution to execute any code/rules
> target before a 3.0 source package applies patches, right?

Good!  I want to be able to inspect source packages as they're going to
be built without running any code from them.  That's a major advantage
of 3.0 (quilt).

-- 
Colin Watson   [cjwat...@debian.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/2028131511.gc3...@riva.dynamic.greenend.org.uk

Re: Lintian ERROR saying dpatch is obsolete

[Raphael Hertzog]

Hi,

On Mon, 28 Nov 2011, Alexander Wirt wrote:
> And the problem that debians dpatchs is full of evil patches that makes it
> just incompatible to other quilts on non-debian systems. 

I assume you meant s/dpatchs/quilt/.

Can you back up that assertion? It's true that quilt has a lot of patches
applied but AFAIK there's only one new significant feature that is not in
the upstream git repository. We have certainly not changed anything that
would lead to a quilt tree being unusable by another quilt.

And FWIW the new feature I'm thinking about is "quilt shell" which you
should most certainly appreciate if you're a dpatch-edit-patch lover.

>From my point of view this assertion is thus wrong-headed. The number of
patches is more a sign of 1/ the Debian maintainer being too busy to do
his job properly 2/ the upstream authors who are not very active either
and haven't made a release in years with quite some changes in their git
repository.

FWIW the call for help is always open: #543541 The two persons who offered
help quickly dropped away too.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/go/ulule-rh/


-- 
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/2028133009.gb4...@rivendell.home.ouaza.com

Bug#650278: ITP: python-wordpress-library -- python module to connect to wordpress blogs using xml rpc

[Salvo Tomaselli]

Package: wnpp
Severity: wishlist
Owner: Salvo Tomaselli 

* Package name: python-wordpress-library
  Version : unknown?
  Upstream Author : Michele Ferretti 
* URL : http://code.google.com/p/wordpress-library/
* License : LGPL
  Programming Lang: Python
  Description : python module to connect to wordpress blogs using xml rpc
This module provides an interface to interact with wordpress blogs using the 
XML RPC interface.
Currently it allows to publish, edit and delete content; to get informations 
about users, upload files, and more.



-- 
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/2028140210.21735.67184.reportbug@hal9000

Bug#650285: ITP: python-openstack-compute -- bindings for the OpenStack API

[Julien Danjou]

Package: wnpp
Severity: wishlist
Owner: Julien Danjou 

* Package name: python-openstack-compute
  Version : git
  Upstream Author : Jacob Kaplan-Moss
* URL : https://github.com/jacobian/openstack.compute
* License : BSD
  Programming Lang: Python
  Description : bindings for the OpenStack API

This is a client for the OpenStack Compute API used by Rackspace Cloud and
others.



-- 
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/2028150350.3148.58057.report...@zelenka.enovance.com

Re: Lintian ERROR saying dpatch is obsolete

[Jon Dowland]

On Mon, Nov 28, 2011 at 12:54:57PM +0100, Alexander Wirt wrote:
> And I still like the "never touch a running system" approach. If dpatch works
> without problems, why deprecate it?

One reason is that the surface area of Debian development tools is too large
and daunting for newcomers. When alternatives for a given tool exist which are
relevant and known outside the Debian eco system and there might be some
practical use for learning those skills in other contexts, IMHO Debian-specific
solutions should need a strong argument *for* to keep, rather than *against* to
remove.


-- 
Jon Dowland


-- 
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/2028152209.GD9337@pris

Re: Lintian ERROR saying dpatch is obsolete

[Alexander Wirt]

Jon Dowland schrieb am Montag, den 28. November 2011:

> On Mon, Nov 28, 2011 at 12:54:57PM +0100, Alexander Wirt wrote:
> > And I still like the "never touch a running system" approach. If dpatch 
> > works
> > without problems, why deprecate it?
> 
> One reason is that the surface area of Debian development tools is too large
> and daunting for newcomers. When alternatives for a given tool exist which are
> relevant and known outside the Debian eco system and there might be some
> practical use for learning those skills in other contexts, IMHO 
> Debian-specific
> solutions should need a strong argument *for* to keep, rather than *against* 
> to
> remove.
imho it is that range of development tools that make us strong. I packaged
for nearly every package system in the past and it is mainly the great eco
system of debian specific tools that make debian just a joy to package.

Alex


-- 
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/2028153930.ga11...@hawking.credativ.lan

Re: Lintian ERROR saying dpatch is obsolete

[Goswin von Brederlow]

Alexander Wirt  writes:

> Jon Dowland schrieb am Montag, den 28. November 2011:
>
>> On Mon, Nov 28, 2011 at 12:54:57PM +0100, Alexander Wirt wrote:
>> > And I still like the "never touch a running system" approach. If dpatch 
>> > works
>> > without problems, why deprecate it?
>> 
>> One reason is that the surface area of Debian development tools is too large
>> and daunting for newcomers. When alternatives for a given tool exist which 
>> are
>> relevant and known outside the Debian eco system and there might be some
>> practical use for learning those skills in other contexts, IMHO 
>> Debian-specific
>> solutions should need a strong argument *for* to keep, rather than *against* 
>> to
>> remove.
> imho it is that range of development tools that make us strong. I packaged
> for nearly every package system in the past and it is mainly the great eco
> system of debian specific tools that make debian just a joy to package.
>
> Alex

and then you need to fix a build failure somewhere deep down in cdbs. :)

MfG
Goswin


-- 
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/87mxbgi6sa.fsf@frosties.localnet

Bug#650288: ITP: python-cloudfiles -- Python language bindings for Cloud Files API

[Julien Danjou]

Package: wnpp
Severity: wishlist
Owner: Julien Danjou 

* Package name: python-cloudfiles
  Version : git
  Upstream Author : Rackspace US, Inc
* URL : https://github.com/rackspace/python-cloudfiles
* License : BSD
  Programming Lang: Python
  Description : Python language bindings for Cloud Files API



-- 
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/2028155302.13698.33089.report...@zelenka.enovance.com

Bug#650290: ITP: lastfmfp -- Last.fm audio fingerprinting library

[Simon Chopin]

Package: wnpp
Severity: wishlist
Owner: Simon Chopin 

* Package name: lastfmfp
  Version : 1.6.0
  Upstream Author : Last.fm Ltd 
* URL : http://github.com/lastfm/FingerprinterL
* License : LGPL-2.1+
  Programming Lang: C++
  Description : Last.fm audio fingerprinting library

This library has been developed by Last.fm to calculate the audio
fingerprint of a PCM flux and return it in a format compatible with the
Last.fm Webservice API.

It is a dependency of the lastid plugin for beets.



-- 
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/2028155926.24684.24043.reportbug@beldin.wizards.local

Linux Mint 12 in Debian?

[Svante Signell]

Hi,

As many people (including me) are very disappointed in gnome3, switching
from a very configurable desktop environment in gnome2 to a almost not
configurable tablet one, is there any chance that Debian could supply
the Mint version too, with many goodies from gnome3 and a gnome2
look-and-feel?

Thank you for your time and efforts with Debian. Maybe this mail is more
appropriate in the debian-gtk-gnome mailing list, but as I am currently
subscribed to debian-devel, not the other one, please just tell me to
use the other list, and I'll subscribe and move my question there. 


-- 
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/1322506616.5597.533.ca...@s1499.it.kth.se

Re: Linux Mint 12 in Debian?

[Allison Randal]

On 11/28/2011 10:56 AM, Svante Signell wrote:
> Hi,
> 
> As many people (including me) are very disappointed in gnome3, switching
> from a very configurable desktop environment in gnome2 to a almost not
> configurable tablet one, is there any chance that Debian could supply
> the Mint version too, with many goodies from gnome3 and a gnome2
> look-and-feel?
> 
> Thank you for your time and efforts with Debian. Maybe this mail is more
> appropriate in the debian-gtk-gnome mailing list, but as I am currently
> subscribed to debian-devel, not the other one, please just tell me to
> use the other list, and I'll subscribe and move my question there. 

I'd suggest it needs to go one step further upstream, and contribute the
Linux Mint extensions for gnome3 to the GNOME project. I have already
put the MATE developers in touch with GNOME, happy to do the same for
Linux Mint if they don't already have contacts there.

Allison


-- 
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/4ed3e69e.9080...@lohutok.net

Re: Lintian ERROR saying dpatch is obsolete

[Alexander Wirt]

Goswin von Brederlow schrieb am Monday, den 28. November 2011:

> Alexander Wirt  writes:
> 
> > Jon Dowland schrieb am Montag, den 28. November 2011:
> >
> >> On Mon, Nov 28, 2011 at 12:54:57PM +0100, Alexander Wirt wrote:
> >> > And I still like the "never touch a running system" approach. If dpatch 
> >> > works
> >> > without problems, why deprecate it?
> >> 
> >> One reason is that the surface area of Debian development tools is too 
> >> large
> >> and daunting for newcomers. When alternatives for a given tool exist which 
> >> are
> >> relevant and known outside the Debian eco system and there might be some
> >> practical use for learning those skills in other contexts, IMHO 
> >> Debian-specific
> >> solutions should need a strong argument *for* to keep, rather than 
> >> *against* to
> >> remove.
> > imho it is that range of development tools that make us strong. I packaged
> > for nearly every package system in the past and it is mainly the great eco
> > system of debian specific tools that make debian just a joy to package.
> >
> > Alex
> 
> and then you need to fix a build failure somewhere deep down in cdbs. :)
such things happen and this may also happen for debhelper, dpkg, apt, and so
on.

Alex


-- 
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/2028201040.ga29...@smithers.snow-crash.org

ITP: ipmiutil -- Easy-to-use IPMI server management utilities

[Andy Cress]

Package: wnpp
Severity: wishlist
Owner: Andy Cress 


* Package name : ipmiutil
  Version : 2.8.0
  Upstream Author : Andy Cress  *
  URL : http://ipmiutil.sourceforge.net *
  License : BSD
  Programming Lang: C, C++
  Description : Easy-to-use IPMI server management utilities

The ipmiutil package provides easy-to-use utilities to view the SEL,
perform an IPMI chassis reset, set up the IPMI LAN and Platform Event
Filter entries to allow SNMP alerts, Serial-Over-LAN console, event
daemon, and other IPMI tasks.

-- System Information: Debian Release: 5.0.4
  APT prefers stable
  APT policy: (500, 'stable') Architecture: i386 (i686)


BACKGROUND INFO:

The ipmiutil project has been in use on various hardware platforms since
2001, so it is mature and has an established user community.

Other Linux distros that include ipmiutil:
 Fedora, openSuSE, Gentoo, RedFlag, MontaVista, RHEL6.3, etc.

For a detailed feature comparison of IPMI open-source software packages,
see http://ipmiutil.sourceforge.net/docs/ipmisw-compare.htm


--
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/40680C535D6FE6498883F1640FACD44D5A15BF@ka-exchange-1.kontronamerica.local

Re: ITP: ipmiutil -- Easy-to-use IPMI server management utilities

[Bastian Blank]

On Mon, Nov 28, 2011 at 11:50:17AM -0800, Andy Cress wrote:
> * Package name : ipmiutil

We already have at least two full ipmi suites. Please describe why
ipmiutil is better then freeipmi and ipmitool.

Bastian

-- 
Vulcans never bluff.
-- Spock, "The Doomsday Machine", stardate 4202.1


-- 
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/2028204033.ga11...@wavehammer.waldi.eu.org

Re: Lintian ERROR saying dpatch is obsolete

[Stefano Zacchiroli]

On Mon, Nov 28, 2011 at 12:54:57PM +0100, Alexander Wirt wrote:
> Its simple and things like dpatch-edit-patch are just great. I now use dpatch
> for round 8 years and it worked every time. I don't see any reason to move
> away.
> 
> And I still like the "never touch a running system" approach. If dpatch works
> without problems, why deprecate it?

Well, there is also the cost of diversity to take into account. I don't
doubt that for you, right now, dpatch is better than quilt. You are used
to it and you're happy with it. But in a project as large as Debian
diversity has a cost.

Think about learning packaging (which is an important use case, given
that we often lament we don't have enough people power in Debian). The
cost of package learning is proportional to the number of tools
involved. Multiplicating the number of tools that do the same thing adds
up to that number, for anyone who has to deal with packages maintained
by diverse teams with potentially different habits.

To name another use case, we have learned in the past release cycles
that the only way to keep up with Debian releases is to have a
significant number of people that do NMUs. Given that we need those
people, we should also try to apply a principle of least surprise from
one package to another. For the Squeeze release I've NMU-ed packages
maintained in yada. Not. Fun.

The maintainer surely had the right to maintain them in yada, but that
choice induced a cost on the release cycle of others who had to learn
yada in the unfortunate case the maintainers stopped doing her job
properly.

We have a tradition in Debian on standardizing on interfaces, which is
good. But also standardizing on tools has value, because it reduces the
cost of diversity throughout the archive. If standardizing on tools is
considered to be too much, we should at least encourage uniformity.
That, I believe, is what Gergely is doing, and I applaud the effort.

(The technical merits of quilt vs dpatch is a totally different matter,
 but Colin & Ian argument "thou-shall-not-exec-stuff-while-patching"
 alone make me score quilt way higher than dpatch, for sanity of the
 archive sake.)

Cheers.
-- 
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences   ..   http://upsilon.cc/zack   ..   . . o
Debian Project Leader...   @zack on identi.ca   ...o o o
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

RE: ITP: ipmiutil -- Easy-to-use IPMI server management utilities

[Andy Cress]

Bastian,

Having more than one IPMI package to cover different user-community preferences 
certainly has a number of precedents.  Think of all the SMTP packages, for 
instance.  
I believe ipmiutil is better, as described below, but some may disagree.  
Nevertheless, giving users the choice is a good position, IMO.  

IPMIUTIL

OS Support: Linux, Windows, FreeBSD, Solaris
Linux Distros:  Fedora, RHEL6.3, Gentoo, RedFlag, MontaVista, openSUSE 11.4
Upstream site:  http://ipmiutil.sourceforge.net

The ipmiutil package is an easy-to-use IPMI server management utility with an 
existing installed user community.  It provides IPMI functionality similar to 
ipmitool and freeipmi but it has certain advantages and additional features:
  * automates common IPMI management functions
  * interprets more event data than other packages
  * includes a severity with each IPMI event
  * allows easier configuration of the IPMI LAN channel
  * supports various drivers and driverless mode also
  * supports other OSs, like Windows, Solaris, FreeBSD, etc.
  * provides automated test cases

The ipmiutil project has been released since 2001 (originally named panicsel), 
so it has more longevity than the others.  
The ipmiutil project is much more active than ipmitool, which has not had 
upstream developer activity since Feb 2009.
It supports Windows servers, the others do not.  So users who have mixed OS 
environments would prefer ipmiutil.  

Andy

-Original Message-
From: Bastian Blank [mailto:wa...@debian.org] 
Sent: Monday, November 28, 2011 3:41 PM
To: Andy Cress
Cc: debian-devel@lists.debian.org
Subject: Re: ITP: ipmiutil -- Easy-to-use IPMI server management utilities

On Mon, Nov 28, 2011 at 11:50:17AM -0800, Andy Cress wrote:
> * Package name : ipmiutil

We already have at least two full ipmi suites. Please describe why
ipmiutil is better then freeipmi and ipmitool.

Bastian

-- 
Vulcans never bluff.
-- Spock, "The Doomsday Machine", stardate 4202.1

Re: The mingw* mess in Debian

[Stephen Kitt]

On Mon, 28 Nov 2011 09:34:00 +0100, Fabian Greffrath 
wrote:
> > To provide all the binaries in gcc-mingw32 it will have to depend on
> > {gcc,g++,gfortran}-mingw-w64-i686; its only contents will be the
> > compatibility symlinks you mention (and the usual /usr/share/doc
> > contents). It will pull in mingw-w64-i686-dev indirectly, and
> > binutils-mingw-w64-i686 too.
> 
> This sounds like a lot of packages to get lost in. Will you still get 
> *everything* if you install the mingw-w64 meta-package?

Yes; even though few people will use the Fortran or Ada compilers, the
mingw-w64 package description states that it provides the full environment
and it will keep on doing so. Users looking for a smaller set of packages
will be able to install gcc-mingw-w64 for example, or even just
gcc-mingw-w64-i686, and that will pull in the relevant mingw-w64-dev and
binutils packages (and g++ will pull in gcc and libstdc++6 etc.).

> > As I understand it having the mingw-w64 package produce a gcc-mingw32
> > package will make the gcc-mingw32 source package disappear eventually...
> 
> A prior message to ftp-masters won't hurt, however. ;)

Indeed, I'll do that before uploading!

Regards,

Stephen


signature.asc
Description: PGP signature

Re: ITP: ipmiutil -- Easy-to-use IPMI server management utilities

[Raf Czlonka]

On Mon, Nov 28, 2011 at 08:58:42PM GMT, Andy Cress wrote:
> It supports Windows servers, the others do not.  So users who have mixed OS 
> environments would prefer ipmiutil.  

If that's true it's enough of a reason for me for it to be packaged.

Regards,
-- 
Raf


-- 
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/2028223355.ga2...@linuxstuff.pl

Re: Lintian ERROR saying dpatch is obsolete

[Alexander Wirt]

Stefano Zacchiroli schrieb am Monday, den 28. November 2011:

> On Mon, Nov 28, 2011 at 12:54:57PM +0100, Alexander Wirt wrote:
> > Its simple and things like dpatch-edit-patch are just great. I now use 
> > dpatch
> > for round 8 years and it worked every time. I don't see any reason to move
> > away.
> > 
> > And I still like the "never touch a running system" approach. If dpatch 
> > works
> > without problems, why deprecate it?
> 
> Well, there is also the cost of diversity to take into account. I don't
> doubt that for you, right now, dpatch is better than quilt. You are used
> to it and you're happy with it. But in a project as large as Debian
> diversity has a cost.
> 
> Think about learning packaging (which is an important use case, given
> that we often lament we don't have enough people power in Debian). The
> cost of package learning is proportional to the number of tools
> involved. Multiplicating the number of tools that do the same thing adds
> up to that number, for anyone who has to deal with packages maintained
> by diverse teams with potentially different habits.
> 
> To name another use case, we have learned in the past release cycles
> that the only way to keep up with Debian releases is to have a
> significant number of people that do NMUs. Given that we need those
> people, we should also try to apply a principle of least surprise from
> one package to another. For the Squeeze release I've NMU-ed packages
> maintained in yada. Not. Fun.
> 
> The maintainer surely had the right to maintain them in yada, but that
> choice induced a cost on the release cycle of others who had to learn
> yada in the unfortunate case the maintainers stopped doing her job
> properly.
> 
> We have a tradition in Debian on standardizing on interfaces, which is
> good. But also standardizing on tools has value, because it reduces the
> cost of diversity throughout the archive. If standardizing on tools is
> considered to be too much, we should at least encourage uniformity.
> That, I believe, is what Gergely is doing, and I applaud the effort.
The question is: who decides? I have a bunch of packages and an established
workflow that served me well over the last years. I don't want to learn
another *censored* system, just because someone said its the new standard or
it is better. I can't remember that somebody asked about deprecating well
established and working tools.

Alex


-- 
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/2028224143.ga3...@smithers.snow-crash.org

Re: Linux Mint 12 in Debian?

[Josselin Mouette]

Le lundi 28 novembre 2011 à 19:56 +0100, Svante Signell a écrit : 
> As many people (including me) are very disappointed in gnome3, switching
> from a very configurable desktop environment in gnome2 to a almost not
> configurable tablet one, is there any chance that Debian could supply
> the Mint version too, with many goodies from gnome3 and a gnome2
> look-and-feel?

The Mint extensions for GNOME Shell look interesting, although I’m not
into nostalgic retrofeatures. Feel free to package them, people on
#debian-gnome can give you advice on this matter.

OTOH you will find vigorous opposition if you’re trying to package MATE
until this fork has shown strong commitment to a complete maintenance,
including that of components no one wants to touch, like gnome-vfs or
bonobo.

(Also, I don’t get the “tablet” mention. One of the weaknesses of GNOME
Shell compared to e.g. Unity is precisely its behavior on tablets -
which is why this is something upstream is working on.)

-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


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

Re: Is anyone maintaining (the ham radio tool) node?

[Jonathan Nieder]

Ian Jackson wrote:

> I think the best way to fix this is to prepare both renaming uploads
> in advance, and allow either of the two contending maintainers to
> upload both packages simultaneously.

Thanks, that sounds sensible to me.

Since this still seems to be stalled, I would like to hear from the
nodejs maintainers whether this approach would be okay with them and
whether there is anything others involved with Debian can do to help
with the migration.

(Yes, that includes helping talk with upstream to get nodejs accepted
as a synonym so scripts with "#!/usr/bin/env nodejs" can work
everywhere.  Yes, that includes changing policy, if you happen to have
a coherent proposal in mind.)

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/2028231624.ge20...@elie.hsd1.il.comcast.net

Re: ITP: ipmiutil -- Easy-to-use IPMI server management utilities

[tony mancill]

On 11/28/2011 02:33 PM, Raf Czlonka wrote:
> On Mon, Nov 28, 2011 at 08:58:42PM GMT, Andy Cress wrote:
>> It supports Windows servers, the others do not.  So users who have mixed OS 
>> environments would prefer ipmiutil.  
> 
> If that's true it's enough of a reason for me for it to be packaged.

I concur.  The more Debian can do to ease its introduction into mixed
and/or non-Debian environments, the more potentially attractive it is to
users.  Having impiutil part of Debian, provided that it is not buggy
and is well-maintained, means one less headache for sysadmins out there.

0.02,
tony



signature.asc
Description: OpenPGP digital signature

Re: Lintian ERROR saying dpatch is obsolete

[Michael Gilbert]

On Mon, Nov 28, 2011 at 5:41 PM, Alexander Wirt wrote:
> The question is: who decides? I have a bunch of packages and an established
> workflow that served me well over the last years. I don't want to learn
> another *censored* system, just because someone said its the new standard or
> it is better. I can't remember that somebody asked about deprecating well
> established and working tools.

Simple answer: the maintainer(s) of that tool.  If he/she/they think
it needs to go, then it should.

As an aside, the process of converting a package from dpatch to source
format 3 (quilt) is rather simple and straightforward.  It can be done
in less than 10 minutes per package (although the first one will
certainly take longer given learning curve/time).

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/CANTw=mnbfsyeoweawuuqp8kdr0jdxk0cln8nudj_hz8xzp9...@mail.gmail.com

Re: Lintian ERROR saying dpatch is obsolete

[Russ Allbery]

Michael Gilbert  writes:
> On Mon, Nov 28, 2011 at 5:41 PM, Alexander Wirt wrote:

>> The question is: who decides? I have a bunch of packages and an
>> established workflow that served me well over the last years. I don't
>> want to learn another *censored* system, just because someone said its
>> the new standard or it is better. I can't remember that somebody asked
>> about deprecating well established and working tools.

> Simple answer: the maintainer(s) of that tool.  If he/she/they think it
> needs to go, then it should.

If someone else is willing to be the maintainer of the tool (as is the
case here), I think it's a bit more complicated than that.  I find Zack's
argument persuasive, but I don't think the situation is as simple as
"whatever the dpatch maintainer says goes."

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/871usru5sl@windlord.stanford.edu

Re: [Pkg-javascript-devel] Is anyone maintaining (the ham radio tool) node?

[Jérémy Lal]

On 29/11/2011 00:16, Jonathan Nieder wrote:
> Ian Jackson wrote:
> 
>> I think the best way to fix this is to prepare both renaming uploads
>> in advance, and allow either of the two contending maintainers to
>> upload both packages simultaneously.
> 
> Thanks, that sounds sensible to me.
>
> Since this still seems to be stalled, I would like to hear from the
> nodejs maintainers whether this approach would be okay with them and
> whether there is anything others involved with Debian can do to help
> with the migration.

I can prepare a patch for nodejs package.

Those matters need help :
- All packages shipping files with a node shebang must also be patched.
Is there a simple way to search all packages having a node shebang ?

- I can't help but talk about "npm", an essential development tool distributed
in latest nodejs (can be compared to ruby's gem). It allows one to install and
publish npm packages to a common registry.
It will need a patch to rename shebangs on-the-fly, and maybe rename them back
when publishing. Npm author is working closely with nodejs authors.

> (Yes, that includes helping talk with upstream to get nodejs accepted
> as a synonym so scripts with "#!/usr/bin/env nodejs" can work
> everywhere.

Convincing upstream will obviously need treasures of diplomacy,
as it's easier for them to point their users to alternative debian packages.


> Yes, that includes changing policy, if you happen to have
> a coherent proposal in mind.)

I don't understand, could you explain why / which policy ?

Jérémy.


-- 
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/4ed425ff.6010...@edagames.com

Re: Lintian ERROR saying dpatch is obsolete

[Michael Gilbert]

On Mon, Nov 28, 2011 at 7:32 PM, Russ Allbery wrote:
> Michael Gilbert writes:
>> On Mon, Nov 28, 2011 at 5:41 PM, Alexander Wirt wrote:
>
>>> The question is: who decides? I have a bunch of packages and an
>>> established workflow that served me well over the last years. I don't
>>> want to learn another *censored* system, just because someone said its
>>> the new standard or it is better. I can't remember that somebody asked
>>> about deprecating well established and working tools.
>
>> Simple answer: the maintainer(s) of that tool.  If he/she/they think it
>> needs to go, then it should.
>
> If someone else is willing to be the maintainer of the tool (as is the
> case here), I think it's a bit more complicated than that.

That isn't quite the case.  The existing maintainer isn't stepping
down, he's consciously deprecating the tool (and will continue to
maintain it for years until the deprecation process is complete).

Anyway, from what I've seen in the past the utmost deference is always
been given to maintainers.  If one wants to second-guess maintainer
decisions, they need to appeal to the tech committee.

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/CANTw=MO4oFzR=T6rEfJaBSZFebKKbd_EQrytznWmN1vkquu�@mail.gmail.com

Re: Lintian ERROR saying dpatch is obsolete

[Russ Allbery]

Michael Gilbert  writes:
> On Mon, Nov 28, 2011 at 7:32 PM, Russ Allbery wrote:

>> If someone else is willing to be the maintainer of the tool (as is the
>> case here), I think it's a bit more complicated than that.

> That isn't quite the case.  The existing maintainer isn't stepping down,
> he's consciously deprecating the tool (and will continue to maintain it
> for years until the deprecation process is complete).

Yes, I know.  But that doesn't *intrinsically* mean that he's correct to
do so.  If, for example, Joey decided that debhelper was a bad idea and
everyone should switch to CDBS, I'm sure we'd all listen closely to the
reasoning, but I don't think his opinion would automatically win.  :)

> Anyway, from what I've seen in the past the utmost deference is always
> been given to maintainers.  If one wants to second-guess maintainer
> decisions, they need to appeal to the tech committee.

Invoking governance processes in volunteer organizations full of
opinionated people is inherently painful, and hence is the option to use
only when every other course of action is even more painful.  I think a
general project discussion about the future of dpatch is more useful than
a technical committee discussion of same.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87sjl7sq9p@windlord.stanford.edu

Re: [Pkg-javascript-devel] Is anyone maintaining (the ham radio tool) node?

[Jakub Wilk]

* Jérémy Lal , 2011-11-29, 01:23:

Is there a simple way to search all packages having a node shebang ?


http://lintian.debian.org/tags/unusual-interpreter.html
(Unfortunately, the list might be incomplete because the lintian lab is 
still a bit broken; see bug #641468.)


--
Jakub Wilk


--
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/2029010231.ga9...@jwilk.net

Re: Lintian ERROR saying dpatch is obsolete

[Steve Langasek]

On Sun, Nov 27, 2011 at 06:44:04PM +0100, Luk Claes wrote:
> Besides it would be great that everyone uploading has a big reminder to
> switch away from dpatch. Switching to v3 quilt should be easy.

There are several features of dpatch that can't be trivially migrated to v3
quilt.

 - Custom patch commands, as already discussed.  Yes, we should get rid of
   them, but that doesn't make it easy to convert them.

 - Conditional application of patches.  Some packages have patches that are
   only applied on a per-architecture or per-target-distribution basis.

 - Patches that don't unapply cleanly after build can be dealt with via
   'rm -rf' with a custom patch system, but must be made to unapply cleanly
   with v3 (quilt).

It's still probably worthwhile to push towards v3 as a standard for source
packages, but let's not ignore that there are some real challenges along the
way.

-- 
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


signature.asc
Description: Digital signature

Re: Is anyone maintaining (the ham radio tool) node?

[Jonathan Nieder]

Jérémy Lal wrote:

> I can prepare a patch for nodejs package.

Thanks!

[...]
> - I can't help but talk about "npm", an essential development tool distributed
> in latest nodejs (can be compared to ruby's gem). It allows one to install and
> publish npm packages to a common registry.
> It will need a patch to rename shebangs on-the-fly, and maybe rename them back
> when publishing. Npm author is working closely with nodejs authors.

Filed as bug#650345.

[...]
>> Yes, that includes changing policy, if you happen to have
>> a coherent proposal in mind.)
>
> I don't understand, could you explain why / which policy ?

Debian policy.  I was thinking of [1] as I said this.  But I do not
personally have any idea about how policy could be improved in this
area.

Sincerely,
Jonathan

[1] http://lists.debian.org/debian-devel/2011/11/msg00380.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/2029012236.gc28...@elie.hsd1.il.comcast.net

Re: Lintian ERROR saying dpatch is obsolete

[Jonas Smedegaard]

On 11-11-28 at 04:53pm, Russ Allbery wrote:
> If, for example, Joey decided that debhelper was a bad idea and 
> everyone should switch to CDBS, I'm sure we'd all listen closely to 
> the reasoning, but I don't think his opinion would automatically win.  
> :)

:-D


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature

Re: Lintian ERROR saying dpatch is obsolete

[Paul Wise]

On Tue, Nov 29, 2011 at 9:04 AM, Steve Langasek wrote:

>  - Custom patch commands, as already discussed.  Yes, we should get rid of
>   them, but that doesn't make it easy to convert them.
>
>  - Conditional application of patches.  Some packages have patches that are
>   only applied on a per-architecture or per-target-distribution basis.
>
>  - Patches that don't unapply cleanly after build can be dealt with via
>   'rm -rf' with a custom patch system, but must be made to unapply cleanly
>   with v3 (quilt).

All of these can be dealt with by rewriting the patch so that it is
acceptable to upstream and applied and released by them.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


--
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/caktje6ep7z+2z09dmyqpy6qah-pkvqvmy2izn39qcsaquep...@mail.gmail.com

Re: Linux Mint 12 in Debian?

[Thomas Goirand]

On 11/29/2011 02:56 AM, Svante Signell wrote:
> Hi,
>
> As many people (including me) are very disappointed in gnome3, switching
> from a very configurable desktop environment in gnome2 to a almost not
> configurable tablet one, is there any chance that Debian could supply
> the Mint version too, with many goodies from gnome3 and a gnome2
> look-and-feel?
>
> Thank you for your time and efforts with Debian. Maybe this mail is more
> appropriate in the debian-gtk-gnome mailing list, but as I am currently
> subscribed to debian-devel, not the other one, please just tell me to
> use the other list, and I'll subscribe and move my question there. 
>   
While I've read so many complain about the non-customizable aspects of
Gnome 3, I've seen very few people highlighting how fast gnome-shell is
in version 3 compared to version 2. If the MATE extensions are getting
into SID, then we'll have best of both worlds, which would be great.

How about convincing Mint guys to work together with Debian so that
it can be "upstreamed" to us?

Thomas


-- 
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/4ed45e20.7030...@debian.org

Re: ITP: ipmiutil -- Easy-to-use IPMI server management utilities

[martin f krafft]

also sprach tony mancill  [2011.11.29.0030 +0100]:
> I concur.  The more Debian can do to ease its introduction into mixed
> and/or non-Debian environments, the more potentially attractive it is to
> users.  Having impiutil part of Debian, provided that it is not buggy
> and is well-maintained, means one less headache for sysadmins out there.

Noone has argued that ipmiutil should not be packaged because there
are others already. But the package descriptions should help users
decide between them. Ideally, therefore, wishlist reports should be
filed against the other packages with suggestions to improve.

-- 
 .''`.   martin f. krafft   Related projects:
: :'  :  proud Debian developer   http://debiansystem.info
`. `'`   http://people.debian.org/~madduckhttp://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
"in the country of the blind,
 the one-eyed man is not king.
 he is taken to be a hallucinating lunatic."
 -marshall mcluhan


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: Lintian ERROR saying dpatch is obsolete

[Stefano Zacchiroli]

On Mon, Nov 28, 2011 at 11:41:43PM +0100, Alexander Wirt wrote:
> > We have a tradition in Debian on standardizing on interfaces, which is
> > good. But also standardizing on tools has value, because it reduces the
> > cost of diversity throughout the archive. If standardizing on tools is
> > considered to be too much, we should at least encourage uniformity.
> > That, I believe, is what Gergely is doing, and I applaud the effort.
>
> The question is: who decides? I have a bunch of packages and an established
> workflow that served me well over the last years. I don't want to learn
> another *censored* system, just because someone said its the new standard or
> it is better. I can't remember that somebody asked about deprecating well
> established and working tools.

Right, this is part of the issue. In fact, this is why in my reasoning
I've favored "encouraging uniformity" over "tool standardization". What
usually happen in these cases is that the ratio of people using the de
facto standard tool will increase while the ratio of people using
something else will decrease.

You are quite opinionated on dpatch and I'm sure you're not the only
one. But there are also many people who essentially don't care and who
will be happy to follow the tool they believe "is winning", for
uniformity sake. This, imho, is what explains the growing trend of dpkg
3.0 quilt over other patch systems that can be seen at
.

In many cases, widespread habits throughout the archive are enough to
convince everybody. But you're right that we don't have anyone who can
force *you* to change; after all you can just ignore the lintian error
or even override it. Eventually, the change will just happen. Or not.
And that is part of the reason why tool transitions in Debian might take
several years to complete.

-- 
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences   ..   http://upsilon.cc/zack   ..   . . o
Debian Project Leader...   @zack on identi.ca   ...o o o
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature