Bug#725232: ITP: python-cornice -- provides helpers to build & document Web Services with Pyramid

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python-cornice
  Version : 0.13
  Upstream Author : Alexis Metaireau 
* URL : https://github.com/mozilla-services/cornice
* License : Mozilla Public License 2.0 (MPL 2.0)
  Programming Lang: Python
  Description : provides helpers to build & document Web Services with 
Pyramid

 Cornice provides helpers to build & document REST-ish Web Services with
 Pyramid, with decent default behaviors. It takes care of following the HTTP
 specification in an automated way where possible.


-- 
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/20131003065209.30764.77024.report...@buzig.gplhost.com

Bug#725229: ITP: ruby-nfc -- ruby wrapper for the libnfc

[Nobuhiro Iwamatsu]

Package: wnpp
Severity: wishlist
Owner: Nobuhiro Iwamatsu 

* Package name: ruby-nfc
  Version : 3.0.0
  Upstream Author : Aaron Patterson 
* URL : https://github.com/tenderlove/nfc
* License : MIT/X
  Programming Lang: C, Ruby
  Description : ruby wrapper for the libnfc

  ruby-nfc is a ruby wrapper for the Near Field Communication library (libnfc).
  The Near Field Communication library works with many USB RFID readers,
  so this lets you read RFID tags.


-- 
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/20131003053708.6799.88197.report...@xps-iwamatsu.hsdv.com

Bug#725220: ITP: jatl -- Java Anti-Template Language

[Emmanuel Bourg]

Package: wnpp
Severity: wishlist
Owner: Emmanuel Bourg 

* Package name: jatl
  Version : 0.2.2
  Upstream Author : Adam Gent 
* URL : http://code.google.com/p/jatl/
* License : Apache-2.0
  Programming Lang: Java
  Description : Java Anti-Template Language

JATL is an extremely lightweight efficient Java library to generate
XHTML or XML in a micro DSL builder/fluent style.

This package is a build dependency or Gradle 1.5


-- 
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/524ca660.30...@apache.org

Re: how do deal with versionless mercurial software ?

[Jerome BENOIT]

Hello All,

I did not expected to initial such a thread: thanks a lot for all the messages

On 02/10/13 20:24, David Prévot wrote:
> Hi,
> 
>> Wookey  (2013-10-02):
> 
>>> It would be good if this 0~ trick
>>> was mentioned there too
> 
> Already in the New Maintainers' Guide:
> 
> http://www.debian.org/doc/manuals/maint-guide/first#namever

I guessed I was too focused on the mercurial aspect of my stuff
to forget the basics.

> 
> Regards
> 
> David, kinda ashamed to add a message to that longish nitpicking thread
> 
> 
> 
Best wishes,
Jerome


-- 
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/524cb58b.6040...@rezozer.net

Re: Results of the porter roll call (Was: Roll call for porters of architectures in sid and testing)

[Axel Beckert]

Him

Julien Cristau wrote:
> On Wed, Oct  2, 2013 at 11:44:44 +0200, Axel Beckert wrote:
> > Yesterday I tried to setup a sparc64 chroot on a second disc in one of
> > my Sparcs, but the currently documented way[1] to do so failed[2] due
> > to outdated packages. On a first glance it looks like missing BinNMUs
> > for the Perl 5.14 to Perl 5.18 transition.
> 
> Part of the porter's job is to take care of that kind of things.

Definitely.

> If that's not happening for sparc64 because nobody's actually taking
> care of the port, I don't see it as a viable candidate for the
> archive...

*nod* One of the reasons why I'm trying to improve that...

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-|  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5


-- 
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/20131002230600.gi3...@sym.noone.org

Bug#725215: ITP: node-multiparty -- Multipart/form-data parser for Node.js

[Jérémy Lal]

Package: wnpp
Severity: wishlist
Owner: "Jérémy Lal" 

* Package name: node-multiparty
  Version : 2.1.8
  Upstream Author : Andrew Kelley 
* URL : https://github.com/superjoe30/node-multiparty
* License : Expat
  Programming Lang: JavaScript
  Description : Multipart/form-data parser for Node.js

node-multiparty is a well-tested multipart/form-data parser for
requests sent by HTTP clients. Files uploads are properly handled
as streams, and are not written to disk by default.
.
This module is a fork, and replaces, node-formidable.
.
Node.js is an event-based server-side javascript engine.


-- 
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/2013100810.7817.86095.reportbug@imac.chaumes

Re: ports and multiarch

[Ben Hutchings]

On Wed, Oct 02, 2013 at 12:56:51PM +0100, Jonathan Dowland wrote:
> On Mon, Sep 30, 2013 at 09:22:06PM +, Bill Allombert wrote:
> > We should add official support for ppc64 and maybe sparc64 at least for use
> > as a multiarch extension to ppc/sparc, even if we do not have time to make 
> > a full
> > port. Otherwise the introduction of multiarch will likely result in a 
> > regression
> > of functionnality on ppc system.
> > 
> > Indeed, lib64* packages are superceded by multiarch and often are removed
> > due to file conflict with the multi-arch equivalent. However this leads
> > to a regression for nominally-32bit but 64bit-capable architectures that
> > do not have a 64bit suit to draw from. 
> 
> I think a true 64 port may take the oxygen out of the 32 bit port,
> potentially, which would be a shame for powerpc 32 bit users (G4,
> like mac minis, powerbooks etc.). A multiarch solution would be
> nicer for them imho.  Actually I wonder how many 32 bit powerpc
> users there are compared to 64 bit. IN the mac world, I'd wager
> more G4s than G5s (the mac pro or xserves), not sure about other
> powerpc worlds.

I don't think Debian development should be driven by retro-computing.

I'm not saying we should drop support for perfectly usable machines,
but most of those 32-bit Macs are soon going to be too slow or too
broken for practical use (if they aren't already).

Ben.

-- 
Ben Hutchings
Beware of bugs in the above code;
I have only proved it correct, not tried it. - Donald Knuth


-- 
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/20131002194409.gp7...@decadent.org.uk

Re: how do deal with versionless mercurial software ?

[Ben Finney]

Jerome BENOIT  writes:

> I am packaging a versionless library software maintained via a
> mercurial repository. Is there any custom for this case ?

I have had a surprising rate of success simply asking upstream to make
versioned release tarballs, or at least VCS tags for release versions.

-- 
 \“No one ever went broke underestimating the taste of the |
  `\   American public.” —Henry L. Mencken |
_o__)  |
Ben Finney


-- 
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/7wd2nnqxa3@benfinney.id.au

Re: ports and multiarch

[Steven Chamberlain]

Hi.

On 02/10/13 12:56, Jonathan Dowland wrote:
> Actually I wonder how many 32 bit powerpc
> users there are compared to 64 bit. IN the mac world, I'd wager
> more G4s than G5s (the mac pro or xserves), not sure about other
> powerpc worlds.

Maybe these figures from popcon are indicative;  it seems to agree with
what you said, only about a quarter of total powerpc systems seem to
have a 64-bit kernel installed:

wheezy kernels:
http://qa.debian.org/popcon-graph.php?packages=linux-image-3.2.0-4-powerpc+linux-image-3.2.0-4-powerpc-smp+linux-image-3.2.0-4-powerpc64&show_installed=on&want_legend=on&want_ticks=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1

squeeze kernels:
http://qa.debian.org/popcon-graph.php?packages=linux-image-2.6.32-5-powerpc+linux-image-2.6.32-5-powerpc-smp+linux-image-2.6.32-5-powerpc64&show_installed=on&want_legend=on&want_ticks=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.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/524c7081.6010...@pyro.eu.org

Bug#725205: ITP: libpath-isdev-perl -- Perl module to determine if a given Path resembles a development source tree

[Florian Schlichting]

Package: wnpp
Severity: wishlist
Owner: Florian Schlichting 

* Package name: libpath-isdev-perl
  Version : 0.4.0
  Upstream Author : Kent Fredric 
* URL : https://metacpan.org/release/Path-IsDev
* License : GPL-1+, Artistic
  Programming Lang: Perl
  Description : Perl module to determine if a given Path resembles a 
development source tree

Path::IsDev is more or less a bunch of heuristics for determining if a
given path is a development tree root of some kind.  This has many
useful applications, notably ones that require behaviours for
"installed" modules to be different to those that are still "in
development"


-- 
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/20131002190420.9617.68895.reportbug@thinkpad

Bug#725204: ITP: libpath-finddev-perl -- Perl module to find a development path somewhere in an upper hierarchy

[Florian Schlichting]

Package: wnpp
Severity: wishlist
Owner: Florian Schlichting 

* Package name: libpath-finddev-perl
  Version : 0.4.0
  Upstream Author : Kent Fredric 
* URL : https://metacpan.org/release/Path-FindDev
* License : GPL-1+, Artistic
  Programming Lang: Perl
  Description : Perl module to find a development source tree somewhere in 
an upper hierarchy

Path::FindDev provides an easy and platform-independent way to find the
root of a development source tree in some parent directory, irrespective
of which test you put it in, and regardless of what $CWD happens to be
when you call it.  Path::FindDev is mostly a glue layer around
Path::IsDev with a few directory walking tricks.


-- 
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/20131002190229.9564.5098.reportbug@thinkpad

Re: how do deal with versionless mercurial software ?

[David Prévot]

Hi,

> Wookey  (2013-10-02):

>> It would be good if this 0~ trick
>> was mentioned there too

Already in the New Maintainers' Guide:

http://www.debian.org/doc/manuals/maint-guide/first#namever

Regards

David, kinda ashamed to add a message to that longish nitpicking thread





signature.asc
Description: OpenPGP digital signature

Re: Results of the porter roll call (Was: Roll call for porters of architectures in sid and testing)

[Julien Cristau]

On Wed, Oct  2, 2013 at 11:44:44 +0200, Axel Beckert wrote:

> Yesterday I tried to setup a sparc64 chroot on a second disc in one of
> my Sparcs, but the currently documented way[1] to do so failed[2] due
> to outdated packages. On a first glance it looks like missing BinNMUs
> for the Perl 5.14 to Perl 5.18 transition.
> 
Part of the porter's job is to take care of that kind of things.  If
that's not happening for sparc64 because nobody's actually taking care
of the port, I don't see it as a viable candidate for the archive...

Cheers,
Julien


signature.asc
Description: Digital signature

Re: Bug#725170: ITP: python-clamd -- clamd is a portable Python module to use the ClamAV anti-virus engine on Windows, Linux, MacOSX and other platforms. It requires a running instance of the clamd da

[Daniel Wozniak]

This is a fork of code in the package available currently. As far as I 
can tell this one is being actively worked on but the other is not. A 
little background, my primary motivation for wanting this package is 
that it the newest upstream of w3af requires it as a dependency.


http://packages.debian.org/sid/w3af

~Daniel

On 10/02/2013 05:11 AM, Scott Kitterman wrote:

On Wednesday, October 02, 2013 08:50:31 Daniel Wozniak wrote:

Package: wnpp
Severity: wishlist
Owner: Daniel Wozniak 

* Package name: python-clamd
   Version : 1.0.1
   Upstream Author : Thomas Grainger 
* URL : https://github.com/orvant/debian-python-clamd
* License : LGPL
   Programming Lang: Python
   Description : clamd is a portable Python module to use the ClamAV
anti-virus engine

  clamd is a portable Python module to use the ClamAV anti-virus engine on
  Windows, Linux, MacOSX and other platforms. It requires a running instance
of the clamd daemon.
  .
  This is a fork of pyClamd v0.2.0 created by Philippe Lagadec and published
on his website: http://www.decalage.info/en/python/pyclamd which in turn is
a slightly improved version of pyClamd v0.1.1 created by Alexandre Norman
and published on his website: http://xael.org/norman/python/pyclamd/

We already have pyclamd 0.2.2 in the archive:

http://packages.qa.debian.org/p/pyclamd.html

Although it looks like at least the binary package name should change, I think
it would make sense to have only one actively maintained version of this in
the archive instead of two.

Scott K



--
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/524c4e95.9050...@woz.io

Re: Bug#725170: ITP: python-clamd -- clamd is a portable Python module to use the ClamAV anti-virus engine on Windows, Linux, MacOSX and other platforms. It requires a running instance of the clamd da

[Scott Kitterman]

Daniel Wozniak  wrote:
>On 10/02/2013 05:11 AM, Scott Kitterman wrote:
>> On Wednesday, October 02, 2013 08:50:31 Daniel Wozniak wrote:
>>> Package: wnpp
>>> Severity: wishlist
>>> Owner: Daniel Wozniak 
>>>
>>> * Package name: python-clamd
>>>Version : 1.0.1
>>>Upstream Author : Thomas Grainger 
>>> * URL : https://github.com/orvant/debian-python-clamd
>>> * License : LGPL
>>>Programming Lang: Python
>>>Description : clamd is a portable Python module to use the
>ClamAV
>>> anti-virus engine
>>>
>>>   clamd is a portable Python module to use the ClamAV anti-virus
>engine on
>>>   Windows, Linux, MacOSX and other platforms. It requires a running
>instance
>>> of the clamd daemon.
>>>   .
>>>   This is a fork of pyClamd v0.2.0 created by Philippe Lagadec and
>published
>>> on his website: http://www.decalage.info/en/python/pyclamd which in
>turn is
>>> a slightly improved version of pyClamd v0.1.1 created by Alexandre
>Norman
>>> and published on his website: http://xael.org/norman/python/pyclamd/
>> We already have pyclamd 0.2.2 in the archive:
>>
>> http://packages.qa.debian.org/p/pyclamd.html
>>
>> Although it looks like at least the binary package name should
>change, I think
>> it would make sense to have only one actively maintained version of
>this in
>> the archive instead of two.
>>
>> Scott K
>This is a fork of code in the package available currently. As far as I 
>can tell this one is being actively worked on but the other is not. A 
>little background, my primary motivation for wanting this package is 
>that it the newest upstream of w3af requires it as a dependency.
>
>http://packages.debian.org/sid/w3af
>

As long as it's reasonably backwards compatible, we should definitely replace 
the unmaintained code with the maintained fork.

Scott K


-- 
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/a2d19402-b30d-4e11-934f-1a25940f9...@email.android.com

Re: libravatar in the BTS [Re: bugs.debian.org: something's wrong...]

[Don Armstrong]

On Wed, 02 Oct 2013, Jakub Wilk wrote:
> * Don Armstrong , 2013-10-01, 17:10:
> >The avatars are now fully federated, and all caching and retrieval
> >is now done from debian.org resources, which should mitigate the
> >privacy concerns.
> 
> Iceweasel users who want to mitigate the annoyance can put this
> snippet into their ~/.mozilla/firefox/*/chrome/userContent.css file:
> 
> img[src^="http://bugs.debian.org/cgi-bin/libravatar.cgi?";]
> {
>   display: none !important;
> }

If you do this, I'd also suggest dropping in a rule for
http://bugs.debian.org/libravatar, as I will eventually be moving the
image urls there.
 

-- 
Don Armstrong  http://www.donarmstrong.com

Cheop's Law: Nothing ever gets built on schedule or within budget.
 -- Robert Heinlein _Time Enough For Love_ p242


-- 
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/20131002171158.gm9...@rzlab.ucr.edu

Re: trove is already a source package in Debian and a Python module in PyPi

[Didier 'OdyX' Raboud]

Le mardi, 1 octobre 2013 23.45:53 Thomas Goirand a écrit :
> On 10/01/2013 10:02 PM, Jonathan Dowland wrote:
> > Ask ftp masters to reject the package and re-upload with the source
> > package renamed to have an openstack prefix/suffix/infix.
> 
> Thanks but no thanks. I need to have the python namespace (eg, the
> egg-info and such) to match the package name, otherwise there will be
> no correct automatic ${python:Depends} substitution.

That's why Jonathan proposed to have the _source_ package renamed, which 
has nothing to do with the ${python:Depends} substition.

Renaming source packages to be in their own namespace is frankly a quite 
minor annoyance; just do it once (adapt your debian/watch parsing and 
processing tools) and be done with it. Paul also pointed out the 
possibility to namespace the openstack source packages set, which makes 
them easier to cluster; I concur with this suggestion.

Cheers,

OdyX
-- 
OdyX


--
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/4254485.D7SOGf3E2V@gyllingar

Re: Results of the porter roll call (Was: Roll call for porters of architectures in sid and testing)

[Patrick Baggett]

I'm interesting in helping on ia64. I'm not fluent in ia64 assembly, but I
can get around pretty well. I'm very experienced in C/C++/Java and
debugging. I've got a fully functional system running Xorg/Mesa3D/sound, so
I can reproduce, test, and fix issues as time permits.

Patrick Baggett


On Wed, Oct 2, 2013 at 2:45 AM, Niels Thykier  wrote:

> Hi,
>
> The final results are in:
>
> Summary table:
> Arch   || DDs || NMs/DMs || Other || Total
> ---++-++-++---++--
> armel  ||  3  ||   0 || 1 ||4
> armhf  ||  3  ||   1 || 2 ||6
> hurd-i386  ||  5  ||   0 || 3 ||8
> ia64   || *0* ||   0 || 3 ||3
> kfreebsd-amd64 ||  4  ||   0 || 2 ||6
> kfreebsd-i386  ||  4  ||   0 || 2 ||6
> mips   ||  1  ||   0 || 1 ||2
> mipsel ||  1  ||   0 || 1 ||2
> powerpc[1] || (1) ||   0 || 2 ||   2.5?
> s390x  || *0* ||   0 || 0 ||   *0*
> sparc[2]   ||  1  ||   0 || 0 ||1
>
> [1] The (1) and .5 is from a "I am not primarily a porter [...]"-remark,
> so I wasn't sure how to count it.
>
> [2] By the looks of it, if sparc was replaced by sparc64, we could be
> looking at 3 in the "Other"-column rather than 0.
>
> NMs/DMs include DMs and people currently in NM process.  The "Other"
> column may include people who said they would like to become porters
> (but would need to be introduced to the job) and thus may imply some
> active recruiting from the current porters.  This is at least true for
> hurd-i386.
>
>
>
> The current policy says that we require "5 developers" (i.e. DDs) for
> release architectures[AP], so based on that only amd64, i386 and
> hurd-i386 would pass this requirement.  It is quite possible we need to
> revise that requirement, but most of the architectures would (still) do
> well to attract a few more (DD) porters.
>   I have attached a file with my notes of who are behind those numbers.
>  If your name is missing or you believe I have miscounted something[CD]
> for an architecture listed in the table above, please reply to this
> email *promptly* (CC'ing me explicitly is fine) with your concerns or
> corrections.
>
> At this time, I have *not* updated the arch qualification table yet.  I
> will do that in a couple of days.  We will also follow up on this in the
> next bits from the release team.
>
> ~Niels
>
> [AP] http://release.debian.org/jessie/arch_policy.html
>
> [CD] I may (or may not) have been caffeine-deprived when I did the
> counting.  You are free to make assumptions about whether that has
> affected my ability to do addic^Htion or parsing your email(s) properly.
>
>

Re: how do deal with versionless mercurial software ?

[Dominik George]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

>A packager is not required to serve users with such specific needs.

Hmm, I last saw that attitude when being explained "the Arch way".

I established an advantage for the user using my proposal - go get me a 
disadvantage for the packager.

That said, what's the point in NOT being verbose?

- -nik
-BEGIN PGP SIGNATURE-
Version: APG v1.0.8-fdroid

iQFNBAEBCgA3BQJSTEDPMBxEb21pbmlrIEdlb3JnZSAobW9iaWxlIGtleSkgPG5p
a0BuYXR1cmFsbmV0LmRlPgAKCRAvLbGk0zMOJdszB/sFTL5LyhKjXavXzGRU7OdR
0Kp2yKKmShyGI+ElOmzF/1bDAD38UrQRJ+DvIYTLeLm3zJ51DeYA//svFKrKWs7J
SDIuzUx6vGJgcDdEwxm2oY11emgrd9YDyVuRi06/b9kh7T0kff1jy/PxiAB4IMAm
WVc5zH4+frgLlP3yw7pWwUZsfgXmJ6jOdHrX9SvupBF3FWtuZOi6ocwDI7wFZO8L
ZbT97lUk7vSIB/BPwyhr2G8TAoQSnyUVp18Wtq8WKfJogX3IBjXwlE+hEqtICqGm
9cGQNTCKqkJEHcWsu1/ZQITw4qedFz/gRl3BxXorAbhIVMl6iZXirrGXqkOtsMSi
=LX+C
-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/629e8051-c748-4f03-9218-6d683206a...@email.android.com

Re: how do deal with versionless mercurial software ?

[Jonas Smedegaard]

Quoting Dominik George (2013-10-02 16:39:09)
> Wookey  schrieb:
>>+++ Dominik George [2013-10-02 16:23 +0200]:
>>>
0~MMDD

 should be fine.
>>>
>>> It isn't, it is not a unique identifier for the one "release" you 
>>> are packaging.
>>
>> No, but it can be a sufficient identifier so long as you don't make 
>> more than one release a day.
>>
>> Which exact tag/branch/hash/whatever was used for the orig tarball 
>> can be recorded elsewhere in the release. It doesn't have to go in 
>> the version number - that's a decision for the packager.
>>
>> Wookey
> 
> From a power-user point of view, I want to see what version of a 
> package is in Debian by looking through the package lists, without 
> having to download the source package or some other awkward steps.
> 
> A packager might package a 3 year old commit now, and use today's date 
> as version. You see that it does not serve identifying upstream 
> version in any way, it's just a useless piece of information.

A packager is not required to serve users with such specific needs.

That said, I recommend to use the date of newest commit, not packaging 
date.


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

Re: Results of the porter roll call (Was: Roll call for porters of architectures in sid and testing)

[Dave Jones]

Hello, all.

I am not currently a porter but I would like to be one for the s390x
architecture.


I am familiar with zSeries system programming and have a lot of
experience in running Linux in virtual environments, mostly z/VM on
large IBM processors..  I use Linux for 11 year, family with cross
compiling tool chain.

I am not a DD/DM. and I am somewhat surprised not to see Philiip Kern
(pk...@debian.org) on the list.

DJ

On 10/02/2013 02:45 AM, Niels Thykier wrote:
> Hi,
> 
> The final results are in:
> 
> Summary table:
> Arch   || DDs || NMs/DMs || Other || Total
> ---++-++-++---++--
> armel  ||  3  ||   0 || 1 ||4
> armhf  ||  3  ||   1 || 2 ||6
> hurd-i386  ||  5  ||   0 || 3 ||8
> ia64   || *0* ||   0 || 3 ||3
> kfreebsd-amd64 ||  4  ||   0 || 2 ||6
> kfreebsd-i386  ||  4  ||   0 || 2 ||6
> mips   ||  1  ||   0 || 1 ||2
> mipsel ||  1  ||   0 || 1 ||2
> powerpc[1] || (1) ||   0 || 2 ||   2.5?
> s390x  || *0* ||   0 || 0 ||   *0*
> sparc[2]   ||  1  ||   0 || 0 ||1
> 
> [1] The (1) and .5 is from a "I am not primarily a porter [...]"-remark,
> so I wasn't sure how to count it.
> 
> [2] By the looks of it, if sparc was replaced by sparc64, we could be
> looking at 3 in the "Other"-column rather than 0.
> 
> NMs/DMs include DMs and people currently in NM process.  The "Other"
> column may include people who said they would like to become porters
> (but would need to be introduced to the job) and thus may imply some
> active recruiting from the current porters.  This is at least true for
> hurd-i386.
> 
> 
> 
> The current policy says that we require "5 developers" (i.e. DDs) for
> release architectures[AP], so based on that only amd64, i386 and
> hurd-i386 would pass this requirement.  It is quite possible we need to
> revise that requirement, but most of the architectures would (still) do
> well to attract a few more (DD) porters.
>   I have attached a file with my notes of who are behind those numbers.
>  If your name is missing or you believe I have miscounted something[CD]
> for an architecture listed in the table above, please reply to this
> email *promptly* (CC'ing me explicitly is fine) with your concerns or
> corrections.
> 
> At this time, I have *not* updated the arch qualification table yet.  I
> will do that in a couple of days.  We will also follow up on this in the
> next bits from the release team.
> 
> ~Niels
> 
> [AP] http://release.debian.org/jessie/arch_policy.html
> 
> [CD] I may (or may not) have been caffeine-deprived when I did the
> counting.  You are free to make assumptions about whether that has
> affected my ability to do addic^Htion or parsing your email(s) properly.
> 

-- 
Dave Jones
V/Soft Software
www.vsoft-software.com
Houston, TX
281.578.7544


-- 
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/524c3ab0.2020...@vsoft-software.com

Re: how do deal with versionless mercurial software ?

[Dominique Dumont]

On Wednesday 02 October 2013 17:31:02 Andrew Shadura wrote:
> > dpkg --compare-versions 1.hg2012 '<=' 1.git2013 || echo 'false'
> 
> Weren't we talking about 0~20131002.hg2efc4fcd vs 0~20131002.git67ed491a?

Sorry, I confused between Jerome original mail and Dominik's proposal. 

Dominik's idea raises no issue at all.

Sorry for the trouble.

-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.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/7851424.dI8Gh107z1@ylum

Re: how do deal with versionless mercurial software ?

[Andrew Shadura]

Hi,

On 2 October 2013 17:27, Dominique Dumont  wrote:
>> If you deem it unlikely that two commits are made in the same day (which
>> happens all the time), how likely is it that upstream switches VCSs and
>> does an important commit on the same day?

> that's not the issue. Try that:

> dpkg --compare-versions 1.hg2012 '<=' 1.git2013 || echo 'false'

Weren't we talking about 0~20131002.hg2efc4fcd vs 0~20131002.git67ed491a?

-- 
WBR, Andrew


-- 
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/cacujmdnhtmpsh7f3gcqnbc90vtab2zlholda5j-82f2gsez...@mail.gmail.com

Re: how do deal with versionless mercurial software ?

[Dominique Dumont]

On Wednesday 02 October 2013 16:51:09 Dominik George wrote:
> >well, you proposed a version like 'hg'. if upstream switches to
> >git, you
> >can't use a version like 'git' because it sorts before hg. I grant
> >you
> >that is easy to work around.
> 
> If you deem it unlikely that two commits are made in the same day (which
> happens all the time), how likely is it that upstream switches VCSs and
> does an important commit on the same day?

that's not the issue. Try that:

dpkg --compare-versions 1.hg2012 '<=' 1.git2013 || echo 'false'


-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.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/5009015.R4oBotHMLD@ylum

Re: Results of the porter roll call (Was: Roll call for porters of architectures in sid and testing)

[Steve McIntyre]

On Wed, Oct 02, 2013 at 04:07:25PM +0100, Wookey wrote:
>+++ Niels Thykier [2013-10-02 09:45 +0200]:
>> Hi,
>> 
>> The final results are in:
>> 
>> Summary table:
>> Arch   || DDs || NMs/DMs || Other || Total
>> ---++-++-++---++--
>> armel  ||  3  ||   0 || 1 ||4
>> armhf  ||  3  ||   1 || 2 ||6
>
>> armel: Wookey (DD), Gatis Visnevskis (!DD), Nobuhiro Iwamatsu (DD), Steve 
>> McIntyre (DD)
>> armhf: Jeremiah Foster (!DD, but NM?), Wookey (DD), Justus Winter (!DD), 
>> Lennart Sorensen (!DD), Nobuhiro Iwamatsu (DD), Steve McIntyre (DD)
>
>I am surprised not to see Riku Voipio and Hector Oron on this list as
>I know they help manage the buildds and Riku signs uploads. I don't
>know if they are trying to escape, or just being too slack to send
>mail :-)
>
>>   arm64: Wookey (DD), Steve McInture (DD)
>
>There are other DDs working on this too (Doko and Riku
>particularly), but again they are probably trying to avoid getting
>any more formal responsibilities. :-)

*grin* I guess so...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
You raise the blade, you make the change... You re-arrange me 'til I'm sane...


-- 
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/20131002151044.gk14...@einval.com

Re: Results of the porter roll call (Was: Roll call for porters of architectures in sid and testing)

[Wookey]

+++ Niels Thykier [2013-10-02 09:45 +0200]:
> Hi,
> 
> The final results are in:
> 
> Summary table:
> Arch   || DDs || NMs/DMs || Other || Total
> ---++-++-++---++--
> armel  ||  3  ||   0 || 1 ||4
> armhf  ||  3  ||   1 || 2 ||6

> armel: Wookey (DD), Gatis Visnevskis (!DD), Nobuhiro Iwamatsu (DD), Steve 
> McIntyre (DD)
> armhf: Jeremiah Foster (!DD, but NM?), Wookey (DD), Justus Winter (!DD), 
> Lennart Sorensen (!DD), Nobuhiro Iwamatsu (DD), Steve McIntyre (DD)

I am surprised not to see Riku Voipio and Hector Oron on this list as
I know they help manage the buildds and Riku signs uploads. I don't
know if they are trying to escape, or just being too slack to send
mail :-)

>   arm64: Wookey (DD), Steve McInture (DD)

There are other DDs working on this too (Doko and Riku
particularly), but again they are probably trying to avoid getting
any more formal responsibilities. :-)

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/20131002150724.ge32...@stoneboat.aleph1.co.uk

Re: how do deal with versionless mercurial software ?

[Cyril Brulebois]

Wookey  (2013-10-02):
> The 'use an ISO date as version' idea comes from advice in the
> developer packaging docs somewhere. It would be good if this 0~ trick
> was mentioned there too so one could decide whether to use it or not
> at the time of initial packaging.

http://www.debian.org/doc/debian-policy/ch-binary.html#s3.2.1

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: how do deal with versionless mercurial software ?

[Dominik George]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



Dominique Dumont  schrieb:
>On Wednesday 02 October 2013 16:05:18 Dominik George wrote:
>> >You should use a version derived from the date only. This way, you
>> >won't be in
>> >trouble if upstream switches to git.
>>
>> I absolutely do not see why this should be an issue.
>
>well, you proposed a version like 'hg'. if upstream switches to
>git, you
>can't use a version like 'git' because it sorts before hg. I grant
>you
>that is easy to work around.

If you deem it unlikely that two commits are made in the same day (which 
happens all the time), how likely is it that upstream switches VCSs and does an 
important commit on the same day?

- -nik
.
-BEGIN PGP SIGNATURE-
Version: APG v1.0.8-fdroid

iQFNBAEBCgA3BQJSTDLdMBxEb21pbmlrIEdlb3JnZSAobW9iaWxlIGtleSkgPG5p
a0BuYXR1cmFsbmV0LmRlPgAKCRAvLbGk0zMOJZcSB/0Y0qa176+WM6I+lR+62QUY
lEN9SW1gAAUpz5NV+1UJlqbgIz8VbxvHVEXcfAtVhYqVzYdQ6XLrbAHwAuQb7lKK
ge7iV0GGLRlBJl97n9c5gqNMKCScEkVG4d1nDO4rn1o/7ghBfaz+yGlFt9woODQn
ByDGB907Ng9fF7FrQ+rn+XH6ROI0OQBbDDNFTUEpst3lLoaVuMUxXUWQKimt0Kcq
6rVwhA5itJFA59zOufxME2OuUJe5surrfnhJApDZq2+Rzsy0E6PuwGCr8qtzepER
B5uZ9BqVPEUj0UdMty9YreZnz2oNNUgifM2IKg7je5ZmVo7qsh10Opl1Y/68bkr4
=bC2y
-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/06c8759a-1922-4d0e-b157-feb9e165c...@email.android.com

Re: how do deal with versionless mercurial software ?

[Steve McIntyre]

Wookey wrote:
>+++ Dominik George [2013-10-02 15:49 +0200]:
>> Jerome BENOIT  schrieb:
>> >Hello,
>> >
>> >I am packaging a versionless library software maintained via a
>> >mercurial repository.
>> >Is there any custom for this case ?
>
>> I tend to use:
>> 
>> 0~MMDD+hgXX
>> 
>> It sorts just below anything upstream might invent later (I don't like 
>> epoch).
>
>This is good advice. I've been bitten by just using MMDD as the
>version on unversioned code, and then upstream eventually inventing a
>version number, which of course is much smaller than 20 million, so I
>had to put in an epoch. Which doesn't really matter but just seems
>kind of annoying and unnecessary.
>
>The 'use an ISO date as version' idea comes from advice in the
>developer packaging docs somewhere. It would be good if this 0~ trick
>was mentioned there too so one could decide whether to use it or not
>at the time of initial packaging.

Another point to make - please chase the upstream to at least tag
things from time to time to help people trying to release and use
their code. It seems that releasing tarballs isn't cool enough for the
'leet github generation, but tags and reproducibility still matter.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Support the Campaign for Audiovisual Free Expression: http://www.eff.org/cafe/


-- 
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/e1vrngh-0001zv...@mail.einval.com

Re: how do deal with versionless mercurial software ?

[Dominique Dumont]

On Wednesday 02 October 2013 16:05:18 Dominik George wrote:
> >You should use a version derived from the date only. This way, you
> >won't be in
> >trouble if upstream switches to git.
> 
> I absolutely do not see why this should be an issue.

well, you proposed a version like 'hg'. if upstream switches to git, you 
can't use a version like 'git' because it sorts before hg. I grant you 
that is easy to work around. 


-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.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/1513720.o6RvIdZZlo@ylum

Re: how do deal with versionless mercurial software ?

[Dominik George]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



Wookey  schrieb:
>+++ Dominik George [2013-10-02 16:23 +0200]:
>>
>> >0~MMDD
>> >
>> >should be fine.
>>
>> It isn't, it is not a unique identifier for the one "release" you are
>packaging.
>
>No, but it can be a sufficient identifier so long as you don't make
>more
>than one release a day.
>
>Which exact tag/branch/hash/whatever was used for the orig tarball can
>be
>recorded elsewhere in the release. It doesn't have to go in the
>version number - that's a decision for the packager.
>
>Wookey

>From a power-user point of view, I want to see what version of a package is in 
>Debian by looking through the package lists, without having to download the 
>source package or some other awkward steps.

A packager might package a 3 year old commit now, and use today's date as 
version. You see that it does not serve identifying upstream version in any 
way, it's just a useless piece of information.

- -nik
- --
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
-BEGIN PGP SIGNATURE-
Version: APG v1.0.8-fdroid

iQFNBAEBCgA3BQJSTDANMBxEb21pbmlrIEdlb3JnZSAobW9iaWxlIGtleSkgPG5p
a0BuYXR1cmFsbmV0LmRlPgAKCRAvLbGk0zMOJXyZB/9MYekwEsdPMe/RC7QuaDUa
CxsSvL0wXVTn/MhA52cTv2VLJb8TTLnlNywc0yJPL0yMTrj2cZJzi2kcpWX7WXZX
vawbjy4UY+pk4GqCUWdU1lcCFhjz9Lr5FNUIZ56UbYPbv9OFYpsNeoUCxUU4ITUp
UF14dAf4kYAsC/H0ECvEuPcauFqRQSo11Nrjdx0QA3N19EETA4FMcmB05muhVUTM
ux2ePdDmfEPPk2alnNyErQUDgfVhKPCO8S1FUz32iTqhnjQcIRyEElC1Y8HrTiUH
C1c7UxASQR1H3+SdSEdVqZvXvb/Hpa2g3JyUM2xnyjHDNW8AF8DcolHu80pA3AIe
=ocrV
-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/9ca73438-e12d-428b-b337-8c5f76330...@email.android.com

Re: how do deal with versionless mercurial software ?

[Wookey]

+++ Dominik George [2013-10-02 16:23 +0200]:
> 
> >0~MMDD
> >
> >should be fine.
> 
> It isn't, it is not a unique identifier for the one "release" you are 
> packaging.

No, but it can be a sufficient identifier so long as you don't make more
than one release a day.

Which exact tag/branch/hash/whatever was used for the orig tarball can be
recorded elsewhere in the release. It doesn't have to go in the
version number - that's a decision for the packager.

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/20131002142741.ga32...@stoneboat.aleph1.co.uk

Re: how do deal with versionless mercurial software ?

[Wookey]

+++ Dominik George [2013-10-02 15:49 +0200]:
> Jerome BENOIT  schrieb:
> >Hello,
> >
> >I am packaging a versionless library software maintained via a
> >mercurial repository.
> >Is there any custom for this case ?

> I tend to use:
> 
> 0~MMDD+hgXX
> 
> It sorts just below anything upstream might invent later (I don't like epoch).

This is good advice. I've been bitten by just using MMDD as the
version on unversioned code, and then upstream eventually inventing a
version number, which of course is much smaller than 20 million, so I
had to put in an epoch. Which doesn't really matter but just seems
kind of annoying and unnecessary.

The 'use an ISO date as version' idea comes from advice in the
developer packaging docs somewhere. It would be good if this 0~ trick
was mentioned there too so one could decide whether to use it or not
at the time of initial packaging.

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/20131002142447.gz32...@stoneboat.aleph1.co.uk

Re: how do deal with versionless mercurial software ?

[Dominik George]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

>0~MMDD
>
>should be fine.

It isn't, it is not a unique identifier for the one "release" you are packaging.

- -nik
-BEGIN PGP SIGNATURE-
Version: APG v1.0.8-fdroid

iQFNBAEBCgA3BQJSTCxtMBxEb21pbmlrIEdlb3JnZSAobW9iaWxlIGtleSkgPG5p
a0BuYXR1cmFsbmV0LmRlPgAKCRAvLbGk0zMOJfo8B/9A3TT7GJcYern0/bNeVWZu
YQwYkS/7G9M6890zSB01ACW8Ieh8LUz3Zqo6jAlyJciw5eiokF6ueAA32dgetusj
tgv3jexN5zIWBn6fBmOIBjFtvVPDY5k8lW0UMdkjXbfLxuucUUGPnQB2QQRDw8lg
s+TGfZEnzlkgP5K0+vu1uTd2GsI20MlRKhQn7nM9TEcCO8ElB3E8Ojp1czDgQAvh
qdeRBc1Fk2BQ142FSxmGb0vVvjmSrNU/ByMrwK1xTn6Yl4elVKYQIdo9L0zQuWxm
RpsYfo4EXG6nW0OSs2jvEeYEikx3XCHh9BOW7kLEYFaGIGQZALqhho2yieYCmZJq
=afA2
-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/ca481637-535b-4a10-8483-73c89c847...@email.android.com

Re: how do deal with versionless mercurial software ?

[Jerome BENOIT]

Hello,

On 02/10/13 16:05, Dominik George wrote:
> Hi,
> 
>> What does 'XX' stand for ?
> 
> The short commit hash, as proposed in your initial mail.

In my first email, what you read as a commit hash was meant to be the date.

To summarise:

0~MMDD

should be fine.

Thanks,
Jerome

> 
>> You should use a version derived from the date only. This way, you
>> won't be in
>> trouble if upstream switches to git.
> 
> I absolutely do not see why this should be an issue. Using just a date is not 
> uniquely idemtifiable.
> 
> -nik
> 


-- 
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/524c2bc3.3010...@rezozer.net

Re: how do deal with versionless mercurial software ?

[Dominik George]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

>What does 'XX' stand for ?

The short commit hash, as proposed in your initial mail.

>You should use a version derived from the date only. This way, you
>won't be in
>trouble if upstream switches to git.

I absolutely do not see why this should be an issue. Using just a date is not 
uniquely idemtifiable.

- -nik
- --
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
-BEGIN PGP SIGNATURE-
Version: APG v1.0.8-fdroid

iQFNBAEBCgA3BQJSTCgeMBxEb21pbmlrIEdlb3JnZSAobW9iaWxlIGtleSkgPG5p
a0BuYXR1cmFsbmV0LmRlPgAKCRAvLbGk0zMOJeL5B/9SdDXgBzfNxRFvUrC9BEJN
YQu8FwLcGRXhKYPVezCWkqV+yNocO7w7UZg3bgfFJgEOWhp3Yzt1xLKhtOMdcuqk
7TV6M3/hvWqujGeDPRoLmYKr0OSUMR9pVRlpzWcWS9g24Mw1fFj5iifCv36hOK3M
ZwPjTpu38B02UcvNJ0LJsbYeLk1FEFz/9gouqYGEHx8llJwe6g33OVpIqEzK3dBP
0FuRMlPn7KTmnZSnODtdcEz6WIWZ0cwihWdgiRWnUuB+V+VLhWbuuycivIv0h62E
RV6/JLf5NU3tCuKr6+VzxjZeaGNfjf9SvkA9wsDMMKoVpVyGWE3aDE4zCp37clSL
=4zTf
-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/8e227d40-46a1-4b67-a34f-9b1d46ffb...@email.android.com

Re: how do deal with versionless mercurial software ?

[Jerome BENOIT]

Hi Nik,

thanks for your quick reply.

On 02/10/13 15:49, Dominik George wrote:
> 
> 
> Jerome BENOIT  schrieb:
>> Hello,
> 
>> I am packaging a versionless library software maintained via a
>> mercurial repository.
>> Is there any custom for this case ?
>> If not, can we use the version format 'hgMMDD' ?
> 
> 
>> Best regards,
>> Jerome
> 
> I tend to use:
> 
> 0~MMDD+hgXX
> 
> It sorts just below anything upstream might invent later (I don't like epoch).

Ok.

What does 'XX' stand for ?

Thanks in advance,
Jerome

> 
> -nik
> 


-- 
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/524c2653.8060...@rezozer.net

Re: how do deal with versionless mercurial software ?

[Dominique Dumont]

On Wednesday 02 October 2013 15:21:48 Jerome BENOIT wrote:
> I am packaging a versionless library software maintained via a mercurial
> repository. Is there any custom for this case ?
> If not, can we use the version format 'hgMMDD' ?

As a user, I don't care about upstream repo. 

You should use a version derived from the date only. This way, you won't be in 
trouble if upstream switches to git.

HTH

-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.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/6009516.5IaAEo4kzY@ylum

Re: how do deal with versionless mercurial software ?

[Dominik George]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



Jerome BENOIT  schrieb:
>Hello,
>
>I am packaging a versionless library software maintained via a
>mercurial repository.
>Is there any custom for this case ?
>If not, can we use the version format 'hgMMDD' ?
>
>
>Best regards,
>Jerome

I tend to use:

0~MMDD+hgXX

It sorts just below anything upstream might invent later (I don't like epoch).

- -nik
- --
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
-BEGIN PGP SIGNATURE-
Version: APG v1.0.8-fdroid

iQFNBAEBCgA3BQJSTCRcMBxEb21pbmlrIEdlb3JnZSAobW9iaWxlIGtleSkgPG5p
a0BuYXR1cmFsbmV0LmRlPgAKCRAvLbGk0zMOJai+B/wIpL0jbgsUcu8ISj/yEFe9
EjhMAld0veQnETq6yZhXrWM32h1Y70N/4BDVrt4NySM+kqn3wFZcQ3EAuEpYACg8
d4HxdVhvEfz8XO9nxVHXCwXoDl1pYvKkOHPJTxjDOWrwvNnxWjJklzfep2TdlefO
Tj64mQB81IBB+ayKgy+VkSBPUZFj2TzHznteTHllkPTV5HTj0+dw/lqaq3P9oz3R
1C8a8Oi8k6v8YmyEN46H9PM7MSfuS7q41CU4Ri8NAEPjqsTBlQfLpnc3YdLVBtz5
P4hKEVkCob5pQYXKEng7EGFe0QNxPD+NQlZV7W2UOuuIkU6iPsodxnGtt4YPd0vR
=aq9p
-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/d4f88f68-a946-4b6b-bace-e5e52e00d...@email.android.com

how do deal with versionless mercurial software ?

[Jerome BENOIT]

Hello,

I am packaging a versionless library software maintained via a mercurial 
repository.
Is there any custom for this case ?
If not, can we use the version format 'hgMMDD' ? 


Best regards,
Jerome


-- 
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/524c1dec.5070...@rezozer.net

Re: Results of the porter roll call (Was: Roll call for porters of architectures in sid and testing)

[Jonathan Dowland]

On Wed, Oct 02, 2013 at 02:17:31PM +0200, Jonas Smedegaard wrote:
> Quoting Jonathan Dowland (2013-10-02 13:51:06)
> > On a related note, I idly wonder whether anyone is interested
> > in an official ARMv6 hf port. The rpi community is massive.
> > To be clear I'm not volunteering to be involved, merely curious.
> 
> Are you aware of any other hardware that would benefit from such 
> architecture?

No. Stuff using armhf now could run a v6+hf port, and I think it's a
shame we baselined on v7 for this reason, but that decision has passed.
Raspbian seems to be fine, I kind-of think it's a shame that Debian
doesn't have the exposure and mindshare it would have had if it was
the blessed port for rPi itself… but like I said, I'm not going to be
working on it either way.

> The info at https://wiki.debian.org/RaspberryPi#Raspberry_Pi_issues 
> indicates RPi specifically not relevant to spend Debian resources on.

Last I checked I don't have the source for the microcode for my Intel
amd64 CPU, either.

> If you disagree with the bleak picture that text draws, please consider 
> adding more info there.

I don't disagree (although I think the bottom-most bullet point is
superfluous.)


-- 
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/20131002125310.GA8584@debian

Re: Results of the porter roll call (Was: Roll call for porters of architectures in sid and testing)

[Bastien ROUCARIES]

Add me for armel.

Bastien
Le 2 oct. 2013 09:46, "Niels Thykier"  a écrit :

> Hi,
>
> The final results are in:
>
> Summary table:
> Arch   || DDs || NMs/DMs || Other || Total
> ---++-++-++---++--
> armel  ||  3  ||   0 || 1 ||4
> armhf  ||  3  ||   1 || 2 ||6
> hurd-i386  ||  5  ||   0 || 3 ||8
> ia64   || *0* ||   0 || 3 ||3
> kfreebsd-amd64 ||  4  ||   0 || 2 ||6
> kfreebsd-i386  ||  4  ||   0 || 2 ||6
> mips   ||  1  ||   0 || 1 ||2
> mipsel ||  1  ||   0 || 1 ||2
> powerpc[1] || (1) ||   0 || 2 ||   2.5?
> s390x  || *0* ||   0 || 0 ||   *0*
> sparc[2]   ||  1  ||   0 || 0 ||1
>
> [1] The (1) and .5 is from a "I am not primarily a porter [...]"-remark,
> so I wasn't sure how to count it.
>
> [2] By the looks of it, if sparc was replaced by sparc64, we could be
> looking at 3 in the "Other"-column rather than 0.
>
> NMs/DMs include DMs and people currently in NM process.  The "Other"
> column may include people who said they would like to become porters
> (but would need to be introduced to the job) and thus may imply some
> active recruiting from the current porters.  This is at least true for
> hurd-i386.
>
>
>
> The current policy says that we require "5 developers" (i.e. DDs) for
> release architectures[AP], so based on that only amd64, i386 and
> hurd-i386 would pass this requirement.  It is quite possible we need to
> revise that requirement, but most of the architectures would (still) do
> well to attract a few more (DD) porters.
>   I have attached a file with my notes of who are behind those numbers.
>  If your name is missing or you believe I have miscounted something[CD]
> for an architecture listed in the table above, please reply to this
> email *promptly* (CC'ing me explicitly is fine) with your concerns or
> corrections.
>
> At this time, I have *not* updated the arch qualification table yet.  I
> will do that in a couple of days.  We will also follow up on this in the
> next bits from the release team.
>
> ~Niels
>
> [AP] http://release.debian.org/jessie/arch_policy.html
>
> [CD] I may (or may not) have been caffeine-deprived when I did the
> counting.  You are free to make assumptions about whether that has
> affected my ability to do addic^Htion or parsing your email(s) properly.
>
>

Re: Results of the porter roll call (Was: Roll call for porters of architectures in sid and testing)

[Jonas Smedegaard]

Quoting Jonathan Dowland (2013-10-02 13:51:06)
> On a related note, I idly wonder whether anyone is interested
> in an official ARMv6 hf port. The rpi community is massive.
> To be clear I'm not volunteering to be involved, merely curious.

Are you aware of any other hardware that would benefit from such 
architecture?

The info at https://wiki.debian.org/RaspberryPi#Raspberry_Pi_issues 
indicates RPi specifically not relevant to spend Debian resources on.

If you disagree with the bleak picture that text draws, please consider 
adding more info there.

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

Re: Bug#725170: ITP: python-clamd -- clamd is a portable Python module to use the ClamAV anti-virus engine on Windows, Linux, MacOSX and other platforms. It requires a running instance of the clamd da

[Scott Kitterman]

On Wednesday, October 02, 2013 08:50:31 Daniel Wozniak wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Daniel Wozniak 
> 
> * Package name: python-clamd
>   Version : 1.0.1
>   Upstream Author : Thomas Grainger 
> * URL : https://github.com/orvant/debian-python-clamd
> * License : LGPL
>   Programming Lang: Python
>   Description : clamd is a portable Python module to use the ClamAV
> anti-virus engine
> 
>  clamd is a portable Python module to use the ClamAV anti-virus engine on
>  Windows, Linux, MacOSX and other platforms. It requires a running instance
> of the clamd daemon.
>  .
>  This is a fork of pyClamd v0.2.0 created by Philippe Lagadec and published
> on his website: http://www.decalage.info/en/python/pyclamd which in turn is
> a slightly improved version of pyClamd v0.1.1 created by Alexandre Norman
> and published on his website: http://xael.org/norman/python/pyclamd/

We already have pyclamd 0.2.2 in the archive:

http://packages.qa.debian.org/p/pyclamd.html

Although it looks like at least the binary package name should change, I think 
it would make sense to have only one actively maintained version of this in 
the archive instead of two.  

Scott K


-- 
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/3386894.0XJyM6E3MB@scott-latitude-e6320

Re: ports and multiarch

[Jonathan Dowland]

On Mon, Sep 30, 2013 at 09:22:06PM +, Bill Allombert wrote:
> We should add official support for ppc64 and maybe sparc64 at least for use
> as a multiarch extension to ppc/sparc, even if we do not have time to make a 
> full
> port. Otherwise the introduction of multiarch will likely result in a 
> regression
> of functionnality on ppc system.
> 
> Indeed, lib64* packages are superceded by multiarch and often are removed
> due to file conflict with the multi-arch equivalent. However this leads
> to a regression for nominally-32bit but 64bit-capable architectures that
> do not have a 64bit suit to draw from. 

I think a true 64 port may take the oxygen out of the 32 bit port,
potentially, which would be a shame for powerpc 32 bit users (G4,
like mac minis, powerbooks etc.). A multiarch solution would be
nicer for them imho.  Actually I wonder how many 32 bit powerpc
users there are compared to 64 bit. IN the mac world, I'd wager
more G4s than G5s (the mac pro or xserves), not sure about other
powerpc worlds.


-- 
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/20131002115651.GB6224@debian

Re: Results of the porter roll call (Was: Roll call for porters of architectures in sid and testing)

[Jonathan Dowland]

On a related note, I idly wonder whether anyone is interested
in an official ARMv6 hf port. The rpi community is massive.
To be clear I'm not volunteering to be involved, merely curious.


-- 
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/20131002115106.GA6224@debian

Bug#725179: ITP: isrcsubmit -- extract ISRCs from audio CDs and submit them to MusicBrainz

[Sebastian Ramacher]

Package: wnpp
Severity: wishlist
Owner: Sebastian Ramacher 

* Package name: isrcsubmit
  Version : 2.0.0-beta.4
  Upstream Author : Jonny Dewender
* URL : http://jonnyjd.github.io/musicbrainz-isrcsubmit/
* License : GPL-3+
  Programming Lang: Python
  Description : extract ISRCs from audio CDs and submit them to MusicBrainz

 isrcsubmit is a command line utility to extract International Standard
 Recording Codes (ISRC) from audio CDs. It allows one to submit the extracted
 data to MusicBrainz. ISRCs are used to uniquely identify sound and music video
 recordings.
 .
 A valid MusicBrainz account is required to submit ISRCs.
-- 
Sebastian Ramacher


signature.asc
Description: Digital signature

Re: Results of the porter roll call (Was: Roll call for porters of architectures in sid and testing)

[Jon Ward]

On Wed, Oct 02, 2013 at 04:18:58PM +0800, Paul Wise wrote:
> On Wed, Oct 2, 2013 at 3:45 PM, Niels Thykier wrote:
> > The final results are in:
> >
> > Summary table:
> > Arch   || DDs || NMs/DMs || Other || Total
> > ---++-++-++---++--
> > armel  ||  3  ||   0 || 1 ||4
> > armhf  ||  3  ||   1 || 2 ||6
> Today we had Jon Ward (Aardvark) (non-DD) from ARM Ltd show up on the
> #debian-arm IRC channel. He is still getting up to speed but plans to
> work on armhf stuff.

I was just about to pipe up here. I have to state for the record that I will
not be working on Debian stuff as an ARM employee, but in my own time.

But yes, I have the keen to start contributing to armhf. I have been a Debian   
user (and occaisionally sysadmin) since 1995.

Jon Ward
~


-- 
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/20131002093203.ga2...@fnord.org.uk

Re: Results of the porter roll call (Was: Roll call for porters of architectures in sid and testing)

[Axel Beckert]

Hi,

[I've replaced debian-ports with debian-sparc in the recipients list]

Niels Thykier wrote:
> Arch   || DDs || NMs/DMs || Other || Total
> ---++-++-++---++--
[…]
> sparc[2]   ||  1  ||   0 || 0 ||1
[…]
> [2] By the looks of it, if sparc was replaced by sparc64, we could be
> looking at 3 in the "Other"-column rather than 0.

Ansgar Burchardt wrote:
> So it might make sense to drop sparc in any case and add sparc64 if
> there are enough people interested.

Well, count me in for sparc64 in general, too. I expect, too, that's
where we're heading to anyway, and I don't expect too many
differences. I though fear that we're not yet there:

Yesterday I tried to setup a sparc64 chroot on a second disc in one of
my Sparcs, but the currently documented way[1] to do so failed[2] due
to outdated packages. On a first glance it looks like missing BinNMUs
for the Perl 5.14 to Perl 5.18 transition.

[1] https://wiki.debian.org/Sparc64#Bootstrapping_sparc64
[2] https://lists.debian.org/debian-sparc/2013/10/msg1.html

OTOH such issues were present in the past[3] of sparc64, too, back
then with the transition from Perl 5.10 to Perl 5.12.

[3] https://lists.debian.org/debian-sparc/2011/05/msg00030.html

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-|  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5


signature.asc
Description: Digital signature

Re: libravatar in the BTS [Re: bugs.debian.org: something's wrong...]

[Paul Wise]

On Wed, Oct 2, 2013 at 4:58 PM, Sune Vuorela wrote:

> Next up I guess is finding a way to have DSA setting up something to
> host avatars for @debian.org addresses. hint hint :)

I guess they would want to replace the current db.debian.org code with ud first:

https://github.com/LucaFilipozzi/ud/

-- 
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/CAKTje6G1wgbhzOSt9MSorwQSZxU3WAXB2q7HVoWHv74jZ=c...@mail.gmail.com

Bug#725170: ITP: python-clamd -- clamd is a portable Python module to use the ClamAV anti-virus engine on Windows, Linux, MacOSX and other platforms. It requires a running instance of the clamd daemon

[Daniel Wozniak]

Package: wnpp
Severity: wishlist
Owner: Daniel Wozniak 

* Package name: python-clamd
  Version : 1.0.1
  Upstream Author : Thomas Grainger 
* URL : https://github.com/orvant/debian-python-clamd
* License : LGPL
  Programming Lang: Python
  Description : clamd is a portable Python module to use the ClamAV 
anti-virus engine

 clamd is a portable Python module to use the ClamAV anti-virus engine on
 Windows, Linux, MacOSX and other platforms. It requires a running instance of
 the clamd daemon.
 .
 This is a fork of pyClamd v0.2.0 created by Philippe Lagadec and published on
 his website: http://www.decalage.info/en/python/pyclamd which in turn is a
 slightly improved version of pyClamd v0.1.1 created by Alexandre Norman and
 published on his website: http://xael.org/norman/python/pyclamd/


-- 
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/20131002085031.14365.31527.reportbug@devbox1

Re: Results of the porter roll call (Was: Roll call for porters of architectures in sid and testing)

[Ansgar Burchardt]

On 10/02/2013 09:45, Niels Thykier wrote:
> Summary table:
> Arch   || DDs || NMs/DMs || Other || Total
> ---++-++-++---++--
[...]
> sparc[2]   ||  1  ||   0 || 0 ||1
> 
> [2] By the looks of it, if sparc was replaced by sparc64, we could be
> looking at 3 in the "Other"-column rather than 0.

In addition gcc no longer supports 32bit sparc according to the
architecture qualification notes for Squeeze[1] and Wheezy[2].

  [1] 
  [2] 

So it might make sense to drop sparc in any case and add sparc64 if
there are enough people interested.

Ansgar


-- 
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/524be06e.2000...@debian.org

Re: libravatar in the BTS [Re: bugs.debian.org: something's wrong...]

[Sune Vuorela]

On 2013-10-02, Don Armstrong  wrote:
> The avatars are now fully federated, and all caching and retrieval is

Yay!

> Anyone who wants to set up their own
> http://wiki.libravatar.org/running_your_own/, or you can use libravatar
> or gravatar if you do not wish to do so (or you can do nothing, and no
> image will be displayed for you.)

Next up I guess is finding a way to have DSA setting up something to
host avatars for @debian.org addresses. hint hint :)

/Sune


-- 
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/slrnl4no1k.j8.nos...@sshway.ssh.pusling.com

Re: Bug#724980: ITP: trove -- Database as a Service for OpenStack

[Jonathan Dowland]

On Tue, Oct 01, 2013 at 10:46:38PM +0800, Thomas Goirand wrote:
> Well, you have included in your "36 ITP" the 22 packages which have
> already passed the NEW queue...

So I did. I figured it was too simple to be right ☺ I'm glad that the
figure is much lower.

> Though, I agree with you, I could open a few RFS:

I think it sends a stronger signal that others are welcome (indeed,
actively wanted!) to help with the effort.

> I don't think it's that hard to update, though I believe one would need
> upload rights for it (because unfortunately, it would take as much time
> for me to do the work as for sponsoring it).

I guess that's because you do a judicious review of packages you
sponsor, to ensure they are high enough quality, as well we all should…
What I think you're suffering from here is something I think a lot of
teams have problems with and it's actually a management issue. You need
help, but you also need people who's quality of work you can trust,
otherwise you have to double-check everything and it's no quicker. On
the other hand, the system won't create people you can trust until
someone invests the time to do the sponsor work, so that people have
the opportunity to learn, and you have the opportunity to learn the
quality of someone's work, and in time trust their quality. And so the
adage "you have to spend money to make money" springs to mind: you have
to invest time in sponsorship to hope to get high quality help.

-- 
Jonathan 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/20131002084847.GA30031@debian

Re: libravatar in the BTS [Re: bugs.debian.org: something's wrong...]

[Jakub Wilk]

* Don Armstrong , 2013-10-01, 17:10:
The avatars are now fully federated, and all caching and retrieval is now 
done from debian.org resources, which should mitigate the privacy concerns.


Iceweasel users who want to mitigate the annoyance can put this snippet into 
their ~/.mozilla/firefox/*/chrome/userContent.css file:


img[src^="http://bugs.debian.org/cgi-bin/libravatar.cgi?";]
{
display: none !important;
}

--
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/20131002082315.ga4...@jwilk.net

Re: Results of the porter roll call (Was: Roll call for porters of architectures in sid and testing)

[Paul Wise]

On Wed, Oct 2, 2013 at 3:45 PM, Niels Thykier wrote:

> The final results are in:
>
> Summary table:
> Arch   || DDs || NMs/DMs || Other || Total
> ---++-++-++---++--
> armel  ||  3  ||   0 || 1 ||4
> armhf  ||  3  ||   1 || 2 ||6

Today we had Jon Ward (Aardvark) (non-DD) from ARM Ltd show up on the
#debian-arm IRC channel. He is still getting up to speed but plans to
work on armhf stuff.

I'm guessing we may get more people from ARM, IBM/open-power.org and
other hardware industry organisations showing up over time.

-- 
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/CAKTje6G4UaFVN6Erfyege7XBS18eh4zyjeJ-hus=ddw+p2g...@mail.gmail.com

Results of the porter roll call (Was: Roll call for porters of architectures in sid and testing)

[Niels Thykier]

Hi,

The final results are in:

Summary table:
Arch   || DDs || NMs/DMs || Other || Total
---++-++-++---++--
armel  ||  3  ||   0 || 1 ||4
armhf  ||  3  ||   1 || 2 ||6
hurd-i386  ||  5  ||   0 || 3 ||8
ia64   || *0* ||   0 || 3 ||3
kfreebsd-amd64 ||  4  ||   0 || 2 ||6
kfreebsd-i386  ||  4  ||   0 || 2 ||6
mips   ||  1  ||   0 || 1 ||2
mipsel ||  1  ||   0 || 1 ||2
powerpc[1] || (1) ||   0 || 2 ||   2.5?
s390x  || *0* ||   0 || 0 ||   *0*
sparc[2]   ||  1  ||   0 || 0 ||1

[1] The (1) and .5 is from a "I am not primarily a porter [...]"-remark,
so I wasn't sure how to count it.

[2] By the looks of it, if sparc was replaced by sparc64, we could be
looking at 3 in the "Other"-column rather than 0.

NMs/DMs include DMs and people currently in NM process.  The "Other"
column may include people who said they would like to become porters
(but would need to be introduced to the job) and thus may imply some
active recruiting from the current porters.  This is at least true for
hurd-i386.



The current policy says that we require "5 developers" (i.e. DDs) for
release architectures[AP], so based on that only amd64, i386 and
hurd-i386 would pass this requirement.  It is quite possible we need to
revise that requirement, but most of the architectures would (still) do
well to attract a few more (DD) porters.
  I have attached a file with my notes of who are behind those numbers.
 If your name is missing or you believe I have miscounted something[CD]
for an architecture listed in the table above, please reply to this
email *promptly* (CC'ing me explicitly is fine) with your concerns or
corrections.

At this time, I have *not* updated the arch qualification table yet.  I
will do that in a couple of days.  We will also follow up on this in the
next bits from the release team.

~Niels

[AP] http://release.debian.org/jessie/arch_policy.html

[CD] I may (or may not) have been caffeine-deprived when I did the
counting.  You are free to make assumptions about whether that has
affected my ability to do addic^Htion or parsing your email(s) properly.

Summary table:
Arch   || DDs || NMs/DMs || Other || Total
---++-++-++---++--
armel  ||  3  ||   0 || 1 ||4
armhf  ||  3  ||   1 || 2 ||6
hurd-i386  ||  5  ||   0 || 3 ||8
ia64   || *0* ||   0 || 3 ||3
kfreebsd-amd64 ||  4  ||   0 || 2 ||6
kfreebsd-i386  ||  4  ||   0 || 2 ||6
mips   ||  1  ||   0 || 1 ||2
mipsel ||  1  ||   0 || 1 ||2
powerpc[1] || (1) ||   0 || 2 ||   2.5?
s390x  || *0* ||   0 || 0 ||   *0*
sparc  ||  1  ||   0 || 0 ||1

[1] Roger Leigh: "I am not primarily a porter [...]".

armel: Wookey (DD), Gatis Visnevskis (!DD), Nobuhiro Iwamatsu (DD), Steve 
McInture (DD)
armhf: Jeremiah Foster (!DD, but NM?), Wookey (DD), Justus Winter (!DD), 
Lennart Sorensen (!DD), Nobuhiro Iwamatsu (DD), Steve McInture (DD)
hurd-i386: Samuel Thibault (DD), Barry deFreese (DD), Thomas Schwinge (!DD), 
Pino Toscano (DD), Svante Signell (!DD), Michael Banck (DD), Guillem Jover 
(DD), Zhang Cong (!DD)
kfreebsd-amd64: Christoph Egger (DD), Axel Beckert (DD), Petr Salinger (!DD), 
Robert Millan (DD), Steven Chamberlain (!DD), Guillem Jover (DD)
kfreebsd-i386: Christoph Egger (DD), Axel Beckert (DD), Petr Salinger (!DD), 
Robert Millan (DD), Steven Chamberlain (!DD), Guillem Jover (DD)
mips: Graham Whaley (!DD), Andreas Barth (DD)
mipsel: Graham Whaley (!DD), Andreas Barth (DD)
powerpc: [Roger Leigh (DD)], Geoff Levand (!DD), Lennart Sorensen (!DD)
sparc: Axel Beckert (DD)

Maybes for ia64 (?): Martin Lucina (!DD), Émeric MASCHINO (!DD), Mark Wickens 
(!DD)


(Some inaccuracies can occur in the (xN) below; /me got confused and may have 
lost count for some of them)

Items suggested in the roll call:
* test packages: armel (x3), armhf (x4), hurd-i386 (x4), kfreebsd-amd64 (x6), 
kfreebsd-i386 (x6), mips, mipsel, powerpc (x3), sparc
* fix toolchain issues: armel, armhf (x3), hurd-i386 (x3), mips, mipsel, 
powerpc (x2)
* triage arch-specific bugs: armel (x3), armhf (x4), hurd-i386 (x4), 
kfreebsd-amd64 (x5), kfreebsd-i386 (x5), mips (x2), mipsel (x2), powerpc (x2), 
sparc
* fix arch-related bugs: armel (x2), armhf (x4), hurd-i386 (x5), kfreebsd-amd64 
(x5), kfreebsd-i386 (x5), mips (x2), mipsel (x2), powerpc (x2)
* maintain buildds: armhf, hurd-i386 (x2), kfreebsd-amd64, kfreebsd-i386, mips, 
mipsel

Items suggested by porters in their mails:
+ test d-i "when needed": hurd-i386, powerpc (x3)
+ maintain arch-related pkgs: kfreebsd-amd64, kfreebsd-i386
+ maintain non-DSA porter box: hurd-i386 (x2), kfreebsd-amd64
+ maintain production system of $arch: sp

Bug#725163: RFP: kivy -- kivy

[Bastian Venthur]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

   Package name: kivy
Version: 1.7.2
Upstream Author: The kivy authors
URL: http://kivy.org
License: MIT
Description: Open source Python library for rapid development of
applications that make use of innovative user interfaces, such as
multi-touch apps.

With kivy you can implement Python applications which will run on
Windows, Mac, Linux, iOS and Android.


-- 
Bastian Venthur  http://venthur.de
Debian Developer venthur at 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/524bce82.80...@debian.org