Bug#701962: ITP: libsodium -- Library for build higher-level cryptographic tools

2013-03-01 Thread csosstudy E. 
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

Package name: libsodium
Version   : 0.3
Upstream Author: Frank Denis 
URL : https://github.com/jedisct1/libsodium
License   : ISC
Description : libsodium is a software library for
network communication, encryption,decryption, signatures, etc.
libsodium is a portable, cross-compilable, installable, packageable,
API-compatible version of NaCl.


-- 
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/CAMvSYRWyf1_2y0xTrYAeTNkUccYU3XF4ejFPjxYuy-gYzoc=m...@mail.gmail.com

Bug#701964: RFP: python-v8 -- python interface for the v8 javascript engine

2013-03-01 Thread Joost Yervante Damad 

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

--- Please fill out the fields below. ---

   Package name: python-v8
Version: 1.0-preview-r446
Upstream Author: Xiaohai Lu 
URL: http://code.google.com/p/pyv8/
License: APL2.0
Description: python interface for the v8 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/51306bf5.8080...@damad.be

Bug#701966: RFP: pyftgl -- python bindings for the ftgl opengl font rendering library

2013-03-01 Thread Joost Yervante Damad 

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

--- Please fill out the fields below. ---

   Package name: pyftgl
Version: 0.5c
Upstream Author: Anders Dahnielson 
URL: http://code.google.com/p/pyftgl/
License: GPLv2
Description: python bindings for the ftgl opengl font rendering library


--
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/51306ced.70...@damad.be

Unable to find RC bug targets to squash

2013-03-01 Thread Andreas Tille 
Hi,

when beeing at Debian Med sprint I explicitely recommended the
participants to also look above our fence for general bugs inside Debian
because also Debian Med development is somehow stalled in the times of
freeze.  However, when discussing this I found that other DDs made the
very same observation I did before:  It is really hard to find a
reasonable target to squash for some outsider.  In December I found some
targets for squashing and I tried to apply some "one RC bug per week
policy" onto myself (we also counted these in our Debian Med bug squash
calendar[1].)  However, I failed in keeping this 1 RC bug per week up
and running just because I realised that a there exist a lot of bugs
with at least one of the following features:

  1) technically hard to address without doing heavy research to
 update my knowledge in specific fields / programming languages
  2) unable to reproduce because lack of the specific hardware
  3) controverse discussion of different opinions and hard to
 decide who is "right" or "wrong"

There were other people in the face to face meeting and also signs
online (like [2]) that people made similar observations.  I agree wis
Niels[2] that it might be time for other means than just waiting for bug
squashers and it might be the time where release team (possibly in
contact with TC) should try to find decisions in cases like 3) in my
list above and make themselves unpopular for one part of the people
involved in the bug report discussion and draw some decision.

I wonder in how far I could do my share in the bug count reduction
business.  Perhaps in helping finding bugs belonging into such
categories to attract the right people to the right bug and help
reducing the time for people to detect a reasonable target for
squashing?

Kind regards

   Andreas.

[1] http://debian-med.alteholz.de/advent/
[2] https://nthykier.wordpress.com/2013/02/28/wheezy-release-progress-february/

-- 
http://fam-tille.de


-- 
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/20130301092949.gf7...@an3as.eu

Re: git dangerous operations on alioth

2013-03-01 Thread Holger Levsen 
On Donnerstag, 28. Februar 2013, Holger Levsen wrote:
> signed commits, so you can identify unwanted bits and clean up in the very
> care case that's actually needed?

^^ rare case


-- 
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/20130308.35957.hol...@layer-acht.org

Re: git dangerous operations on alioth

2013-03-01 Thread Thomas Goirand 
On 02/28/2013 08:33 PM, Andrew Shadura wrote:
> we'd have both hg and git in one unified interface. 
That is a very nice feature. I saw few sites having that, for example
bitbucket, unfortunatley, bitbucket doesn't allow git anonymous
checkout over http (it's only available with hg, if I understood well).
Or is there a hidden URL that I didn't find?

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/51308793.4080...@debian.org

Re: git dangerous operations on alioth

2013-03-01 Thread Thomas Goirand 
On 02/28/2013 06:07 PM, Stefano Zacchiroli wrote:
> On Thu, Feb 28, 2013 at 10:39:26AM +0100, Daniel Pocock wrote:
>> Has anybody had experience controlling access to git repositories, for
>> example, to give users access but prevent some of the following
>> dangerous operations?
> Related to this, there is also the risk that a user will ssh on alioth
> and rm the repository (accidentally or not). Do we have any kind of
> protection against that? (e.g. backups we can access to without
> bothering the alioth admins, or a way to give git access but not ssh
> access, or...)
Do we have a backup at all? If so, how often is the backup made, and how
much days of history do we have?

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/513088de.5070...@debian.org

Re: git dangerous operations on alioth

2013-03-01 Thread Dmitrijs Ledkovs 
On 1 March 2013 10:54, Thomas Goirand  wrote:
> On 02/28/2013 06:07 PM, Stefano Zacchiroli wrote:
>> On Thu, Feb 28, 2013 at 10:39:26AM +0100, Daniel Pocock wrote:
>>> Has anybody had experience controlling access to git repositories, for
>>> example, to give users access but prevent some of the following
>>> dangerous operations?
>> Related to this, there is also the risk that a user will ssh on alioth
>> and rm the repository (accidentally or not). Do we have any kind of
>> protection against that? (e.g. backups we can access to without
>> bothering the alioth admins, or a way to give git access but not ssh
>> access, or...)
> Do we have a backup at all? If so, how often is the backup made, and how
> much days of history do we have?

A backup of a git repository is a mirror that constantly does fetch
and never performs garbage collection.
In addition copying across push reflog and even keeping it committed
into git as welll makes sense, this way one can establish when / what
/ how the repository got updated with broken changes.

Regards,

Dmitrijs.


-- 
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/CANBHLUiRM1B9fji2=gqk8fhfvrzrk8wbryqvv4outwgkpby...@mail.gmail.com

Re: Unable to find RC bug targets to squash

2013-03-01 Thread Andrey Rahmatullin 
On Fri, Mar 01, 2013 at 10:29:49AM +0100, Andreas Tille wrote:
> However, I failed in keeping this 1 RC bug per week up
> and running just because I realised that a there exist a lot of bugs
> with at least one of the following features:
> 
>   1) technically hard to address without doing heavy research to
>  update my knowledge in specific fields / programming languages
>   2) unable to reproduce because lack of the specific hardware
>   3) controverse discussion of different opinions and hard to
>  decide who is "right" or "wrong"

I'm using an UDD bookmarked search [1] to find interesting RC bugs (not
pending or patch, applicable to wheezy main) for some time. It now has 55
bugs and for last several months the only bugs that I could anything about
were bugs reported recently. Everything else is either something I cannot
do anything about because I'm not familiar with the package (like
licensing problems or conffile/symlink/whatever else problems on upgrade),
impossible to test (like problems on non-x86 arches) or already worked on
(especially some months ago most interestingly looking bugs without patch
and pending tags already contained lengthy discussions or messages that
they will be fixed soon). This means while they say we have about 200 RC
bugs there is nothing for me to help.

Some more numbers: there are 178 bugs on the page provided by nthykier
[2]. If we ignore "packages not in main", "fixed in deferred/delayed", "RT
tag for wheezy: will-remove", "RT tag for wheezy: can-defer" and "marked
as done" we get 106 bugs. 

Out of those there are 30 bugs tagged patch, 16 bugs tagged
pending and 14 bugs tagged security. If we ignore those, we get 60 bugs. 

I've opened 4 random bugs:

#683188 API change in python-subversion breaks trac
"Testing already has SWIG 2.0.7, so rebuilding python-subversion should
fix this if SWIG is run during the build."

#701944 emacs23 fails to install due to /etc/emacs23 does exist for
byte-compilingclone -1 ccrypt
"Severity set to 'normal' from 'serious'; Added tag(s) moreinfo." (today)

#701134 php-soap: directory vs. symlink conflict: /usr/share/php/doc
"Added tag(s) patch." (today)

#684604 eclipse-rcp: eclipse 3.8 hangs on splash screen with "Loading
Workbench" after update from 3.7.2
I do not know anything about eclipse internals and there is already active
discussion with the maintainer so I don't see how can I help here.


[1] http://deb.li/3F9u1
[2] 
http://udd.debian.org/bugs.cgi?release=wheezy&merged=ign&fnewerval=7&rc=1&sortby=id&sorto=asc&chints=1&caffected=1

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: Unable to find RC bug targets to squash

2013-03-01 Thread Michael Stapelberg 
Hi Andreas,

I wholeheartedly agree. I have written about this in 2012-11¹, but in my
article, I complained about the way bugreports are handled, which, IMO,
are much too free-form to be useful for RC bug hunters.

Anyway, I definitely share your experience that many RC bugs are
hardware-specific or discussions with strong opinions.

Given that this is my first Debian release as a DD, I am somewhat
surprised by how this all works. It totally seems like black magic to go
from where we currently are to an actual release.

① http://people.debian.org/~stapelberg//2012/11/25/rc-bugs.html

-- 
Best regards,
Michael


--
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/x67glre2ps@midna.zekjur.net

Re: git dangerous operations on alioth

2013-03-01 Thread Thomas Goirand 
On 03/01/2013 07:21 PM, Dmitrijs Ledkovs wrote:
> On 1 March 2013 10:54, Thomas Goirand  wrote:
>> On 02/28/2013 06:07 PM, Stefano Zacchiroli wrote:
>>> On Thu, Feb 28, 2013 at 10:39:26AM +0100, Daniel Pocock wrote:
 Has anybody had experience controlling access to git repositories, for
 example, to give users access but prevent some of the following
 dangerous operations?
>>> Related to this, there is also the risk that a user will ssh on alioth
>>> and rm the repository (accidentally or not). Do we have any kind of
>>> protection against that? (e.g. backups we can access to without
>>> bothering the alioth admins, or a way to give git access but not ssh
>>> access, or...)
>> Do we have a backup at all? If so, how often is the backup made, and how
>> much days of history do we have?
> A backup of a git repository is a mirror that constantly does fetch
> and never performs garbage collection.
I wasn't discussing what can be done for backing up a Git repository,
I was asking what is *currently installed* in production as a backup
for Alioth.

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/5130ab96.7080...@debian.org

Re: git dangerous operations on alioth

2013-03-01 Thread Cyril Brulebois 
Thomas Goirand  (01/03/2013):
> I wasn't discussing what can be done for backing up a Git repository,
> I was asking what is *currently installed* in production as a backup
> for Alioth.

Why are you asking debian-devel@ instead of asking the actual admins?

(http://wiki.debian.org/Alioth#Maintenance)

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: git dangerous operations on alioth

2013-03-01 Thread Thomas Goirand 
On 03/01/2013 09:34 PM, Cyril Brulebois wrote:
> Thomas Goirand  (01/03/2013):
>> I wasn't discussing what can be done for backing up a Git repository,
>> I was asking what is *currently installed* in production as a backup
>> for Alioth.
> Why are you asking debian-devel@ instead of asking the actual admins?
Because I'm quite sure I wont be the only one interested by the answer.

Though, if you think I should have Cc: ad...@alioth.debian.org, well,
here you are...

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/5130c163.7040...@debian.org

needing sponsor for blt: am I at that stage?

2013-03-01 Thread Paul Johnson 
Hello,

Its me again.  Once again, I'm throwing myself on your mercy because
although I like programming and packaging, I am having a horrible time
finding my way through your web pages to adopt a package and keep it
up to date.

So far I have succeeded in declaring the ITP on the blt packages and
built the package.  In the changelog I inserted the declarations that
close the wnpp bug and the other blt-related bugs, like so:


blt (2.4z-6) unstable; urgency=normal

  * Closes: #664092
  * Closes: #524149
  * Closes: #636629
  * Version 2.4z-6 introduces quilt-3.0 patches.
  * 02-debian-all.diff includes all of the changes that were applied
to the source code by previous packager. Almost all of the changes
are corrections in spelling in the blt documentation and examples.
  * Apply 3 changes based on revisions developed by the fedora linux team.
+ 03-fedora-patch-2.diff
+ 04-fedora-tk8.5.6.patch.diff
+ 05-tk8.5-zoomstack.diff
   * Those patches are required to solve segmentation faults that are observed
when blt is used with tcltk 8.5. We have a substantial amount of
experience using this patched version of blt in the Swarm
Simulation System (www.swarm.org) and have observed no ill-effects.

I've tested programs that use blt, the ones that used to have
segmentation faults, and they are fine.

Next step: upload. I put the server settings in ~/.dput.cf, and here's
the result.


$ dput mentors blt_2.4z-6_amd64.changes
Checking signature on .changes
gpg: Signature made Sat 09 Feb 2013 08:25:16 PM CST using RSA key ID 8FE944B5
gpg: Good signature from "Paul E. Johnson (Debian Packaging)
"
Good signature on
/home/pauljohn/LinuxDownloads/Debian/sources/amd64/blt-2.4z-quilted/blt_2.4z-6_amd64.changes.
Checking signature on .dsc
gpg: Signature made Sat 09 Feb 2013 08:25:10 PM CST using RSA key ID 8FE944B5
gpg: Good signature from "Paul E. Johnson (Debian Packaging)
"
Good signature on
/home/pauljohn/LinuxDownloads/Debian/sources/amd64/blt-2.4z-quilted/blt_2.4z-6.dsc.
Uploading to mentors (via http to mentors.debian.net):
  Uploading blt_2.4z-6.dsc: done.
  Uploading blt_2.4z-6.tar.gz: done.
  Uploading blt-demo_2.4z-6_all.deb: done.
  Uploading blt_2.4z-6_amd64.deb: done.
  Uploading blt-dev_2.4z-6_amd64.deb: done.
  Uploading blt_2.4z-6_amd64.changes: done.
Successfully uploaded packages


That *seems* to say it worked, so what happens next?

I don't see the package yet on http://mentors.debian.net/, but I've
uploaded the whole directory to my own server as well, in case you
care to review my work:

http://pj.freefaculty.org/Debian/wheezy/amd64/blt-2.4z-quilted/

My pgp key for that is on the mentors website.

-- 
Paul E. Johnson
Professor, Political Science  Assoc. Director
1541 Lilac Lane, Room 504  Center for Research Methods
University of Kansas University of Kansas
http://pj.freefaculty.org   http://quant.ku.edu


-- 
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/CAErODj80CKCCGw2VYM-5jZ-eXBE-=nshvwnnczjaqkxnm40...@mail.gmail.com

Re: needing sponsor for blt: am I at that stage?

2013-03-01 Thread Daniel Hartwig 
On 2 March 2013 00:12, Paul Johnson  wrote:
> Hello,
>
> Its me again.  Once again, I'm throwing myself on your mercy because
> although I like programming and packaging, I am having a horrible time
> finding my way through your web pages to adopt a package and keep it
> up to date.
>
> So far I have succeeded in declaring the ITP on the blt packages and
> built the package.  In the changelog I inserted the declarations that
> close the wnpp bug and the other blt-related bugs, like so:

You properly want debian-ment...@lists.debian.org, redirecting there.

>
>
> blt (2.4z-6) unstable; urgency=normal
>
>   * Closes: #664092
>   * Closes: #524149
>   * Closes: #636629

Normally your changelog should present each of these in the same entry
as some information on how each is closed.  For example, if the first
one is the ITA:

  * New maintainer.  Closes: #664092

> I don't see the package yet on http://mentors.debian.net/,

That can take up to half an hour.

Regards


-- 
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/CAN3veReYmftBE0aVJ7q8vvbtxX=np+hkp1be7_aig1d1gz8...@mail.gmail.com

Re: Unable to find RC bug targets to squash

2013-03-01 Thread Russ Allbery 
Andreas Tille  writes:

> when beeing at Debian Med sprint I explicitely recommended the
> participants to also look above our fence for general bugs inside Debian
> because also Debian Med development is somehow stalled in the times of
> freeze.  However, when discussing this I found that other DDs made the
> very same observation I did before:  It is really hard to find a
> reasonable target to squash for some outsider.

Yes.  I've poked at the list a few times and it's actually rather
difficult even to find one that can be squashed by an insider!

There are also a lot of RC bugs that, really, at this point in the
release, are probably not reasonable targets to fix.  For example, I would
question whether #538822 and #540512 against dash are worth asking people
to spend time on right now; those are really the sorts of bugs that should
be worked on near the beginning of an upgrade cycle.  I realize that's
what we said last cycle, but it's still *true* even if it's frustrating
that people haven't had the time at the right point in the cycle.  (Also,
at this point, #538822 is arguably too old to worry too much about fixing;
people who were going to be bitten by that have probably already moved on
with their lives now.)

-- 
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/871ubzm1q0@windlord.stanford.edu

Bug#702029: ITP: patool -- portable archive file manager for the commandline console

2013-03-01 Thread Bastian Kleineidam 
Package: wnpp
Severity: wishlist
Owner: Bastian Kleineidam 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: patool
  Version : 1.0
  Upstream Author : Bastian Kleineidam 
* URL : http://wummel.github.com/patool/
* License : GPL
  Programming Lang: Python
  Description : portable archive file manager for the commandline console

Various archive formats can be created, extracted, tested, listed,
searched, compared and repacked by patool. The advantage of patool
is its simplicity in handling archive files without having to remember
a myriad of programs and options.

The archive format is determined by the file(1) program and as a
fallback by the archive file extension.

patool supports 7z (.7z), ACE (.ace), ADF (.adf), ALZIP (.alz), APE (.ape),
AR (.a), ARC (.arc), ARJ (.arj), BZIP2 (.bz2),
CAB (.cab), compress (.Z), CPIO (.cpio),
DEB (.deb), DMS (.dms), FLAC (.flac), GZIP (.gz), ISO (.iso), LRZIP (.lrz),
LZH (.lha, .lzh), LZIP (.lz), LZMA (.lzma), LZOP (.lzo), RPM (.rpm),
RAR (.rar), RZIP (.rz), SHN (.shn), TAR (.tar), XZ (.xz), ZIP (.zip, .jar)
and ZOO (.zoo) formats.
It relies on helper applications to handle those archive formats
(for example bzip2 for BZIP2 archives).

The archive formats TAR (.tar), ZIP (.zip), BZIP2 (.bz2) and GZIP (.gz)
are supported natively and do not require helper applications to be
installed.


[Note]
The package is inspired by the "atool" package. The advantages over atool
are:
- - Support for a lot more formats
- - Support for repacking
- - Support for comparing two archives
- - Support for searching in archives

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

iEYEARECAAYFAlExEgMACgkQeBwlBDLsbz5PkgCfRyCRJqrnE/kvlTUO2jtEe3Qw
2nUAn3bq8URVRLYsQTLVACP6aM4Mf5Pp
=ASwk
-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/20130301203938.1852.73288.reportbug@rum

Re: git dangerous operations on alioth

2013-03-01 Thread Andrew Shadura 
Hello,

On Fri, 01 Mar 2013 18:48:51 +0800
Thomas Goirand  wrote:

> On 02/28/2013 08:33 PM, Andrew Shadura wrote:
> > we'd have both hg and git in one unified interface. 
> That is a very nice feature. I saw few sites having that, for example
> bitbucket, unfortunatley, bitbucket doesn't allow git anonymous
> checkout over http (it's only available with hg, if I understood
> well). Or is there a hidden URL that I didn't find?

Seriously, I've never tried bitbucket with git. Actually, what I
usually do is exactly other way around: I use github with hg.

-- 
WBR, Andrew


signature.asc
Description: PGP signature

Re: Unable to find RC bug targets to squash

2013-03-01 Thread Andrey Rahmatullin 
On Fri, Mar 01, 2013 at 06:10:18PM +0600, Andrey Rahmatullin wrote:
> If we ignore those, we get 60 bugs. 
46 currently.

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: Unable to find RC bug targets to squash

2013-03-01 Thread Michael Gilbert 
> I wonder in how far I could do my share in the bug count reduction
> business.  Perhaps in helping finding bugs belonging into such
> categories to attract the right people to the right bug and help
> reducing the time for people to detect a reasonable target for
> squashing?

There are always security-related bugs:
http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=security
http://security-tracker.debian.org

They may seem intimidating, but they're usually fairly straightforward
with a little research.

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=MOf254XLVCb-v2=_du92MEn=9tbadk8n-zq-uvm6kn...@mail.gmail.com

Re: Unable to find RC bug targets to squash

2013-03-01 Thread Russ Allbery 
Michael Gilbert  writes:

>> I wonder in how far I could do my share in the bug count reduction
>> business.  Perhaps in helping finding bugs belonging into such
>> categories to attract the right people to the right bug and help
>> reducing the time for people to detect a reasonable target for
>> squashing?

> There are always security-related bugs:
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=security
> http://security-tracker.debian.org

> They may seem intimidating, but they're usually fairly straightforward
> with a little research.

While I certainly don't want to discourage people from working on
security-related bugs, note that security-related bugs don't block the
release (because they can be dealt with via an advisory after the
release).  So if the goal is to get wheezy out faster, helping with
security-related bugs doesn't really do much.

-- 
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/87y5e6d1lr@windlord.stanford.edu

Re: Unable to find RC bug targets to squash

2013-03-01 Thread Michael Gilbert 
On Fri, Mar 1, 2013 at 8:36 PM, Russ Allbery wrote:
>> They may seem intimidating, but they're usually fairly straightforward
>> with a little research.
>
> While I certainly don't want to discourage people from working on
> security-related bugs, note that security-related bugs don't block the
> release (because they can be dealt with via an advisory after the
> release).  So if the goal is to get wheezy out faster, helping with
> security-related bugs doesn't really do much.

Having so many unaddressed issues prior to the release is certainly
not desirable, and if they remain unaddress it means a lot of for an
already over-loaded security team.  Let's fix these now where its just
a matter of an upload, rather than a DSA.

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=mpgcxdtt9pw9g20ql+ln7uxrxejkas+pwac8o9nnte...@mail.gmail.com

Re: Unable to find RC bug targets to squash

2013-03-01 Thread Charles Plessy 
Le Fri, Mar 01, 2013 at 10:29:49AM +0100, Andreas Tille a écrit :
> 
> I wonder in how far I could do my share in the bug count reduction
> business.  Perhaps in helping finding bugs belonging into such
> categories to attract the right people to the right bug and help
> reducing the time for people to detect a reasonable target for
> squashing?

Hi Andreas and everybody,

I agree completely.

During this cycle, my attempts of fixing RC bugs outside our team's packages
have not gone beyond contemplating the list and finding either bugs that are
beyond my level, bugs that can be solved by removing the package from testing,
or bugs that are likely to be solved by the active maintainer of the pacakge.

In the previous release cycles, it looks like the main blocker was the Debian
Installer.  As soon as it was ready, lots of remaining buggy packages were
purged from Testing and release followed quite soon.  Is that the case for this
release cycle ?  If yes, I guess that the focus should be to help the Installer
team, and not to fix every RC bug.

If there could be a list of bugs that, in the opinion of the Release team, are
strictly impossible to solve by removing packages or dequalifying
architectures, then I think that it would motivate more people to block some
time in their agenda and work hard on these focused issues.

A bug sprint like in 2009 is an interesting alternative if there is no way to
prioritise bugs, as it ensures a more efficient dispatching of contributors on
the bugs, see http://wiki.debian.org/BugSprint. (And no, sorry, I do not have
time to organise one in 2013, but if people are interested and nobody steps up,
one could consider using a really random assignment of bugs to participants).
One intersting property of the bug sprint is that it provides incentives to
solve the bug by leadership when the participant does not have directly the
skills.

Have a nice week-end,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
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/20130302021723.ga12...@falafel.plessy.net

Re: needing sponsor for blt: am I at that stage?

2013-03-01 Thread Paul Wise 
Looks like you did everything correctly, except one thing:

On Sat, Mar 2, 2013 at 12:12 AM, Paul Johnson wrote:

>   * Closes: #664092
>   * Closes: #524149
>   * Closes: #636629

It is best to explain what is being closed, please read the devref
section on changelog best practices:

http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-debian-changelog

So you would write the above like this, but more verbose:

   * New maintainer (Closes: #664092)
   * Fix zooming (Closes: #524149)
   * Fix crash in wish (Closes: #636629)

-- 
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/CAKTje6G6ULKc7zFY_OH=e+3MxrYzwpPfDL6p9T9myDWTMSL=w...@mail.gmail.com

Re: needing sponsor for blt: am I at that stage?

2013-03-01 Thread John Paul Adrian Glaubitz 

On 03/02/2013 04:42 AM, Paul Wise wrote:

Looks like you did everything correctly, except one thing:


I'd like to disagree here. After having a quick glance at the package on 
mentors [1], there is lots of work to be done until the package is 
lintian-clean which is what I always prefer when sponsoring.


Cheers,

Adrian

> [1] http://mentors.debian.net/package/blt

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


--
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/51317597.2090...@physik.fu-berlin.de

Re: Unable to find RC bug targets to squash

2013-03-01 Thread Christian PERRIER 
Quoting Charles Plessy (ple...@debian.org):

> In the previous release cycles, it looks like the main blocker was the Debian
> Installer.  As soon as it was ready, lots of remaining buggy packages were
> purged from Testing and release followed quite soon.  Is that the case for 
> this
> release cycle ?  If yes, I guess that the focus should be to help the 
> Installer
> team, and not to fix every RC bug.


Not really. D-I has been mostly released on a well-handled schedule
and we now have an RC1 release which is (imho) suitable for
release. Far from perfect, surebut that's what we get for having a
quite inactive D-I team during the squeeze-wheezy release cycle
(/meincluded).

We are incredibly lucky that Cyril stepped up and did a tremendous job
releasing betas and RCs. It's definitely not a comfortable situation
because we fully depend on his level of involvment but, thankfully, he
did survive to all this and we have a quite functional installer for
wheezy.

D-I is not a blocker for the release. Hairy bug reports, lengthy
discussions and often our lack of decision is more a blocker. We
probably all need to be much much much mor eaggressive wrt RC bugs and
shouldn't leae this up to the release team.




signature.asc
Description: Digital signature

Re: needing sponsor for blt: am I at that stage?

2013-03-01 Thread Anton Gladky 
I think debian-devel is not quite a correct place to discuss such kind of
things. Please, use debian-mentors instead.

Thanks,

Anton


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