Re: mosh ITP not done, just package name taken over

[David Banks]

Hi list,

On 25/03/12 21:00, Joey Hess wrote:
> The appropriate thing to do when confronted with a months-old ITP
> for a package with the same content or name as your package is almost
> certianly to ignore old "intent" and get on with it.

In the specific case of mosh, I have posted three RFS messages to
debian-mentors since filing the ITP, in addition to the creation of the
RFS bug after the sponsorship-requests procedure was announced, so the
package was certainly being worked on.  However I did not CC the RFS
messages to the ITP bug, so they weren't recorded there.  Would this be
a recommended practice?  How should it interact with the new
sponsorship-requests process?

My first RFS to debian-mentors was posted two days after filing the
initial ITP.

As a post-script, although I am sad to see this furore, I am selfishly
happy to see my package finally get some attention after languishing in
-mentors for months and months.   ;)

Cheers,
David


-- 
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/jkrqmu$p45$1...@dough.gmane.org

Re: init systems and Policy

[Simon McVittie]

On 27/03/12 07:20, Tollef Fog Heen wrote:
>> It is not clear to me the status of similar policy work for systemd,
>> although I see that systemd maintainers are participating in
>> #591791. Again, if you're interested in Debian switch to systemd,
>> please contribute to that work rather than arguing on -devel.
> 
> It's not entirely clear to me that we need any policy changes at all for
> packages to ship systemd unit files.

As far as I understand it, the particular feature of systemd that makes
it unproblematic to ship systemd unit files is that systemd will
normally run sysvinit scripts, but will ignore /etc/init.d/foo if it
sees a foo.service in its own format - so packages without specific
systemd support still work (systemd runs the sysvinit scripts) and
packages with a systemd unit file also work, without running the service
twice (it runs the systemd unit and ignores the corresponding sysvinit
script).

Ubuntu's version of debhelper includes changes to maintainer scripts to
avoid calling update-rc.d for sysvinit scripts when there is a
corresponding Upstart job, from which I infer that Upstart does not do
the same as systemd? If that's the case, then that's why Upstart needs
special and careful handling in Policy. It also makes Ubuntu's debhelper
patches unsuitable for use in Debian in their current form, since the
patch effectively assumes that if there is an Upstart job, it will be
run, and that's not true on non-Upstart systems.

I'm inclined to think Upstart's sysvinit compatibility layer should do
the same as systemd's, unless there's some compelling reason not to -
then specific support for systemd and/or Upstart would only require
adding /lib/systemd/system/foo.service and/or /etc/init/foo.conf, which
would automatically make the corresponding init implementation ignore
/etc/init.d/foo.

S


-- 
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/4f71796d.9030...@debian.org

Re: init systems and Policy

[Andrey Rahmatullin]

On Tue, Mar 27, 2012 at 09:25:17AM +0100, Simon McVittie wrote:
> Ubuntu's version of debhelper includes changes to maintainer scripts to
> avoid calling update-rc.d for sysvinit scripts when there is a
> corresponding Upstart job, from which I infer that Upstart does not do
> the same as systemd? If that's the case, then that's why Upstart needs
> special and careful handling in Policy. It also makes Ubuntu's debhelper
> patches unsuitable for use in Debian in their current form, since the
> patch effectively assumes that if there is an Upstart job, it will be
> run, and that's not true on non-Upstart systems.
dh_installinit(1) in unstable already prefers debian/package.upstart to
debian/package.init and doesn't install both when both are present.

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Bug#665939: ITP: ruby-capistrano-colors -- Capistrano helper for colorizing output

[Taku YASUI]

Package: wnpp
Severity: wishlist
Owner: Taku YASUI 

* Package name: ruby-capistrano-colors
  Version : 0.5.5
  Upstream Author : Mathias Stjernstrom
* URL : https://github.com/stjernstrom/capistrano_colors
* License : MIT
  Programming Lang: Ruby
  Description : Capistrano helper for colorizing output

 capistrano_colors is a helper for Capistrano to colorize its output.
 This package is used with capistrano.

I already created the package using gem2deb.
Please look at following source URLs.

svn://svn.debian.org/svn/collab-maint/deb-maint/ruby-capistrano-colors
http://anonscm.debian.org/viewvc/collab-maint/deb-maint/ruby-capistrano-colors



-- 
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/20120327083535.9856.49132.report...@desire.arege.jp

Re: mosh ITP not done, just package name taken over

[Jon Dowland]

On Mon, Mar 26, 2012 at 05:11:54AM +0200, Goswin von Brederlow wrote:
> Chris Knadle  writes:
> > There's a flip-side to this story, which is what happens when an ITP is 
> > filed 
> > and left-for-dead.  This then turns into a situation where a prospective 
> > new 
> > packager then needs to figure out how to re-assign the ITP to someone else, 
> > (because hijacking an ITP is just rude)
> 
> Then you send a mail to the ITP CCing the submitter and if he doesn't
> respond in a reasonable timeframe you take over.

There seem to be some pretty good (if perhaps not fully automated/consistent)
QA processes for stale ITPs. I've just taken over one that had been auto-reset
to a RFP due to inactivity of the original packager.


-- 
Jon Dowland


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

Re: usefulness of ITPs (Re: mosh ITP not done, just package name taken over)

[Jon Dowland]

On Mon, Mar 26, 2012 at 05:06:55PM +0200, Goswin von Brederlow wrote:
> "Eugene V. Lyubimkin"  writes:
> > e) useful to prevent a duplicate work.
> 
> Pointless if the package is uploaded the moment the BTS responds with
> the bug number for the ITP, which was the hypotetical.

That was Joey's hypothetical, iirc, and I don't really agree with his
supposition that initial packaging is such quick work that the ITP
delay is significant.

Not all developers are as hyper-efficient as Joey Hess, for some of us
preparing a package is not a 5 minute job. Filing an ITP *before* embarking on
the initial packaging work at least minimizes the risk of two developers doing
independent work at the same time.  If one developer spots the ITP, they can
either cede to the person who got the ITP in first, or offer to help.

> In the simple case:
> 
> 1) file ITP with the infos you put in debian/control
> 2) dh_make
> 3) write debian/control (cut&paste the description, homepage, ... from the 
> ITP)
> 4) write debian/copyright
> 5) remove some example files
> 6) build, test, upload
> 
> If you have a BTS turnaround time of 2h then there certainly is enough
> time to finish.

For rock stars such as yourself and Joey ☺ I rarely have a straight run of two
hours to spare, even if it were to take that long and not longer.


-- 
Jon Dowland


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

Re: mosh ITP not done, just package name taken over

[Jon Dowland]

On Tue, Mar 27, 2012 at 08:36:58AM +0100, David Banks wrote:
> As a post-script, although I am sad to see this furore, I am selfishly
> happy to see my package finally get some attention after languishing in
> -mentors for months and months.   ;)

I think Christine sponsoring your package would be karmic re-balancing
for hijacking your package name.  What do you think, Christine? ☺


-- 
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/20120327084803.GC25378@debian

Re: init systems and Policy

[Svante Signell]

On Tue, 2012-03-27 at 14:31 +0600, Andrey Rahmatullin wrote:
> On Tue, Mar 27, 2012 at 09:25:17AM +0100, Simon McVittie wrote:
> > Ubuntu's version of debhelper includes changes to maintainer scripts to
> > avoid calling update-rc.d for sysvinit scripts when there is a
> > corresponding Upstart job, from which I infer that Upstart does not do
> > the same as systemd? If that's the case, then that's why Upstart needs
> > special and careful handling in Policy. It also makes Ubuntu's debhelper
> > patches unsuitable for use in Debian in their current form, since the
> > patch effectively assumes that if there is an Upstart job, it will be
> > run, and that's not true on non-Upstart systems.
> dh_installinit(1) in unstable already prefers debian/package.upstart to
> debian/package.init and doesn't install both when both are present.

How would that work on non-linux systems, service not started? Or should
every non-linux system support their own package.init file? What about
if systemd is preferred for a linux user? 


-- 
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/1332838092.8013.56.ca...@hp.my.own.domain

Bug#665941: ITP: ruby-capistrano-colors -- Capistrano helper for colorizing output

[Taku YASUI]

Package: wnpp
Severity: wishlist
Owner: Taku YASUI 

* Package name: ruby-capistrano-colors
  Version : 0.5.5
  Upstream Author : Mathias Stjernstrom
* URL : https://github.com/stjernstrom/capistrano_colors
* License : MIT
  Programming Lang: Ruby
  Description : Capistrano helper for colorizing output

 capistrano_colors is a helper for Capistrano to colorize its
 output.
 This package is used with capistrano.

I already created the package using gem2deb.
Please look at following source URLs.

svn://svn.debian.org/svn/collab-maint/deb-maint/ruby-capistrano-colors
http://anonscm.debian.org/viewvc/collab-maint/deb-maint/ruby-capistrano-colors



-- 
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/20120327084901.21549.30470.report...@desire.arege.jp

Re: init systems and Policy

[Andrey Rahmatullin]

On Tue, Mar 27, 2012 at 10:48:12AM +0200, Svante Signell wrote:
> On Tue, 2012-03-27 at 14:31 +0600, Andrey Rahmatullin wrote:
> > On Tue, Mar 27, 2012 at 09:25:17AM +0100, Simon McVittie wrote:
> > > Ubuntu's version of debhelper includes changes to maintainer scripts to
> > > avoid calling update-rc.d for sysvinit scripts when there is a
> > > corresponding Upstart job, from which I infer that Upstart does not do
> > > the same as systemd? If that's the case, then that's why Upstart needs
> > > special and careful handling in Policy. It also makes Ubuntu's debhelper
> > > patches unsuitable for use in Debian in their current form, since the
> > > patch effectively assumes that if there is an Upstart job, it will be
> > > run, and that's not true on non-Upstart systems.
> > dh_installinit(1) in unstable already prefers debian/package.upstart to
> > debian/package.init and doesn't install both when both are present.
> How would that work on non-linux systems, service not started? Or should
> every non-linux system support their own package.init file? What about
> if systemd is preferred for a linux user? 
Huh?

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: init systems and Policy

[Simon McVittie]

On 27/03/12 09:31, Andrey Rahmatullin wrote:
> dh_installinit(1) in unstable already prefers
> debian/package.upstart to debian/package.init and doesn't install
> both when both are present.

Right, that'd have to be reverted or otherwise avoided to support
Upstart being optional. I still prefer the systemd approach...

S


-- 
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/4f717fe0.5010...@debian.org

Bug#665942: ITP: ruby-capistrano-colors -- Capistrano helper for colorizing output

[Taku YASUI]

Package: wnpp
Severity: wishlist
Owner: Taku YASUI 

* Package name: ruby-capistrano-colors
  Version : 0.5.5
  Upstream Author : Mathias Stjernstrom
* URL : https://github.com/stjernstrom/capistrano_colors
* License : MIT
  Programming Lang: Ruby
  Description : Capistrano helper for colorizing output

 capistrano_colors is a helper for Capistrano to colorize its
 output.
 This package is used with capistrano.

I already created the package using gem2deb.
Please look at following source URLs.

svn://svn.debian.org/svn/collab-maint/deb-maint/ruby-capistrano-colors
http://anonscm.debian.org/viewvc/collab-maint/deb-maint/ruby-capistrano-colors



-- 
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/20120327085106.22967.35061.report...@desire.arege.jp

Re: On init in Debian

[Luca Capello]

Hi there!

On Mon, 19 Mar 2012 20:45:20 +0100, Vincent Bernat wrote:
> Writing configuration files  with the shell is not  going to be anywhere
> simple. In  two years, it will be  the same mess as  now: everybody will
> have extended  the "configuration" with  its own functions  and somebody
> will come up and say those functions should be put into some library. We
> already have  /lib/lsb/init-functions and start-stop-daemon.   Almost no
> daemon stick to /etc/init.d/skeleton.

And some of our init scripts should already be adapted to not abuse LSB
"internal" functions (NB, openvpn is just the first case I stumbled on):

  

Thx, bye,
Gismo / Luca


pgpabPwO4E9m2.pgp
Description: PGP signature

Re: mosh ITP not done, just package name taken over

[Andrei POPESCU]

On Ma, 27 mar 12, 08:36:58, David Banks wrote:
> 
> In the specific case of mosh, I have posted three RFS messages to
> debian-mentors since filing the ITP, in addition to the creation of the
> RFS bug after the sponsorship-requests procedure was announced, so the
> package was certainly being worked on.  However I did not CC the RFS
> messages to the ITP bug, so they weren't recorded there.  Would this be
> a recommended practice?  How should it interact with the new
> sponsorship-requests process?

Block the ITP bug by the RFS bug?

Kind regards,
Andrei
-- 
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic


signature.asc
Description: Digital signature

Re: init systems and Policy

[Tollef Fog Heen]

]] Simon McVittie 

> On 27/03/12 07:20, Tollef Fog Heen wrote:
> >> It is not clear to me the status of similar policy work for systemd,
> >> although I see that systemd maintainers are participating in
> >> #591791. Again, if you're interested in Debian switch to systemd,
> >> please contribute to that work rather than arguing on -devel.
> > 
> > It's not entirely clear to me that we need any policy changes at all for
> > packages to ship systemd unit files.
> 
> As far as I understand it, the particular feature of systemd that makes
> it unproblematic to ship systemd unit files is that systemd will
> normally run sysvinit scripts, but will ignore /etc/init.d/foo if it
> sees a foo.service in its own format - so packages without specific
> systemd support still work (systemd runs the sysvinit scripts) and
> packages with a systemd unit file also work, without running the service
> twice (it runs the systemd unit and ignores the corresponding sysvinit
> script).

Correct.  You can also have dependencies between LSB init scripts and
systemd units (both ways).

The only case I've seen this cause problems is when you have an init
script that provides other verbs than systemctl does, since
/etc/init.d/foo $verb is translated into systemctl foo.service $verb

> Ubuntu's version of debhelper includes changes to maintainer scripts to
> avoid calling update-rc.d for sysvinit scripts when there is a
> corresponding Upstart job, from which I infer that Upstart does not do
> the same as systemd? If that's the case, then that's why Upstart needs
> special and careful handling in Policy. It also makes Ubuntu's debhelper
> patches unsuitable for use in Debian in their current form, since the
> patch effectively assumes that if there is an Upstart job, it will be
> run, and that's not true on non-Upstart systems.

Yes, upstart needs a transition that needs to be handled carefully and
this is why Steve Langasek has been working on getting this right and
into policy for quite a while.  It's not trivial, particularly not if
you upgrade from a non-upstart-job to a package providing an upstart
job.

> I'm inclined to think Upstart's sysvinit compatibility layer should do
> the same as systemd's, unless there's some compelling reason not to -
> then specific support for systemd and/or Upstart would only require
> adding /lib/systemd/system/foo.service and/or /etc/init/foo.conf, which
> would automatically make the corresponding init implementation ignore
> /etc/init.d/foo.

I think that would be a much better course of action for upstart, but
it's not the direction they've chosen.

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


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

Preinstalled package manager(s) for PCs (wheezy)

[Filipus Klutiero]

Hi,
3 days ago I installed wheezy on my laptop. The day after I realized 
that no graphical APT front-end was installed. Usually, I just install 
Synaptic as a habit, but this time I was surprised I had to do that as I 
was specifically testing the completeness of our KDE meta-packages and 
had installed kde-standard ("KDE Plasma Desktop and standard set of 
applications"). I discovered that even if one installs kde-full, no 
graphical package manager is installed. This is kind of a problem for 
wheezy...


Synaptic is no longer in the desktop task since tasksel 2.43: 
http://packages.debian.org/changelogs/pool/main/t/tasksel/current/changelog#version2.43



* Add kpackage to kde-desktop.
* Move synaptic to gnome-desktop.


Replacing Synaptic with kpackage was certainly not a great move in 2006, 
but the situation got worst with tasksel 2.79: 
http://packages.debian.org/changelogs/pool/main/t/tasksel/current/changelog#version2.79



   * Remove kpackage from kde-desktop. kdeadmin depends on it.


and kdeadmin 4:4.4.2-1: 
http://packages.debian.org/changelogs/pool/main/k/kdeadmin/current/changelog#version4:4.4.2-1



* KPackage dead, remove it. (Closes:#523450  
)


Now, KDE merely recommends update-notifier-kde (via kde-standard).

When I realized this, I thought Synaptic should be added to the desktop 
task. But the situation outside KDE is not what I thought.
In squeeze, gnome depended on synaptic. But GNOME metapackages no longer 
depend on Synaptic following 
http://anonscm.debian.org/viewvc/pkg-gnome?view=revision&revision=29732
It is not clear how intentional that is, but since then GNOME seems to 
only bring in gnome-packagekit.


As for LXDE and Xfce, it seems they do not bring in any front-end. I 
imagine these should bring in Synaptic.


If the above is right, I think desktop tasks should install Synaptic, 
but I am not sure about GNOME.  In fact, I haven't been following the 
new front-ends drafted since I started using Debian (2004). GNOME 
PackageKit seems to claim a certain maturity, so I tried it. My very 
first impression is that although it's neat/shiny and apparently not too 
buggy, it's far from matching Synaptic in completeness. I hardly picture 
myself only using GNOME PackageKit, and I doubt it's a good idea to 
replace Synaptic with GNOME PackageKit.


Before going further, I apologize if I missed a previous discussion of 
the topic, I'm hardly keeping up these days. The only somewhat related 
discussion I found is "A Debian sprint for package management GUIs?", in 
November: http://lists.debian.org/debian-gtk-gnome/2011/11/msg7.html

Unfortunately that discussion seems to be halted.

I have been using Synaptic for nearly 8 years and I watched it being 
maintained, but evolving very slowly. We simply have very little 
manpower working on APT front-ends, beyond the occasional attempts to 
write something new halted mid-way and a few projects that did produce 
interesting alternatives for specific use cases (such as upgrading). I 
would be very happy if some cross-distribution project could bring us a 
successor to Synaptic for free.


But I don't know if PackageKit (and front-ends) is ever going to match 
Synaptic's flexibility. And more importantly, I'm not sure that will be 
the case in time for wheezy. I would be inclined to "encourage" an 
alternative if we agreed it should be the long-term replacement, but not 
at any cost, and from what I saw, shipping GNOME PackageKit instead of 
Synaptic would have an important cost in the short term.


GNOME PackageKit entered testing in April 2011. Making it replace 
Synaptic would be replacing Synaptic with software that didn't go in 
stable yet.
"gnome-packagekit is not ready to be in the default install" according 
to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=649014
That was however filed in November, and the only argument spelled out 
was a bug now fixed. I do not consider a lack of features as a reason to 
exclude software from the default install (unless the lack of a 
"feature" constitutes a bug), however it *is* a reason not to make that 
software *replace* another piece of software which is more complete.


In fact, if GNOME PackageKit is mature enough but still overall inferior 
to Synaptic, nothing prevents us from shipping both. Synaptic is 
lightweight. There is much redundancy between Synaptic and GNOME 
PackageKit, so this will bloat the interface, but I don't think shipping 
both would be worst than shipping only GNOME PackageKit overall. I saw a 
couple of things GNOME PackageKit has that Synaptic doesn't.



So what do others think? The current situation in KDE, LXDE and Xfce 
appears to be unintentional, but for GNOME, I'm wondering how 
intentional the situation is, and how desirable it is. Depending on the 
perceptions of GNOME PackageKit and Synaptic, I may ask that Synaptic be 
added to task-desktop, or that Synaptic be added to only KDE and maybe 
to LXDE and Xfce

Re: init systems and Policy

[Russ Allbery]

Tollef Fog Heen  writes:

> The only case I've seen this cause problems is when you have an init
> script that provides other verbs than systemctl does, since
> /etc/init.d/foo $verb is translated into systemctl foo.service $verb

It would be nice to say, in Policy, that systemd unit files can be shipped
now and to caution about this, but I agree that it's not required before
starting to ship unit files.

-- 
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/8762dpucqa@windlord.stanford.edu

Bug#666010: ITP: nvidia-texture-tools -- image processing and texture manipulation tools

[Lennart Weller]

Package: wnpp
Severity: wishlist
Owner: Lennart Weller 


* Package name: nvidia-texture-tools
  Version : 2.0.8
  Upstream Author : Ignacio Castano  
* URL : http://code.google.com/p/nvidia-texture-tools/
* License : MIT/Expat, BSD-2-clause 
  Programming Lang: C++ 
  Description : image processing and texture manipulation tools

  NVIDIA Texture Tools is a collection of image processing and texture
  manipulation tools, designed to be integrated in game tools and asset
  conditioning pipelines.  The primary features of the library are mipmap and
  normal map generation, format conversion and DXT compression.

  The sourcecode contains algorithms protected by US patent 5,956,431 aka S3TC.
  Though from what I've read on debian-legal this should be okay as the patent
  is not actively enforced.



-- 
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/20120327191527.2568.48901.reportbug@silverline

Bug#666022: ITP: nfacct -- command line tool to create/retrieve/delete netfilter accounting objects

[Laurence J. Lane]

Package: wnpp
Severity: wishlist
Owner: "Laurence J. Lane" 

* Package name: nfacct
  Version : 1.0.0
  Upstream Author : Pablo Neira Ayuso 
* URL : 
http://www.netfilter.org/projects/libnetfilter_acct/downloads.html
* License : GPL
  Programming Lang: C
  Description : netfilter accouting tool

command line tool to create/retrieve/delete netfilter accounting objects



-- 
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/20120327213025.26440.6.report...@nymn.home

Bug#666026: ITP: libnetfilter_acct -- nfacct library files

[Laurence J. Lane]

Package: wnpp
Severity: wishlist
Owner: "Laurence J. Lane" 

* Package name: libnetfilter_acct
  Version : 1.0.0
  Upstream Author : Pablo Neira Ayuso 
* URL : http://www.netfilter.org/projects/libnetfilter_acct/
* License : GPL
  Programming Lang: C
  Description : nfacct library files


 Userspace library providing interface to extended netfilter accounting 
infrastructure.



-- 
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/20120327213701.6897.83653.report...@nymn.home

Re: usefulness of ITPs (Re: mosh ITP not done, just package name taken over)

[Joey Hess]

Jon Dowland wrote:
> That was Joey's hypothetical, iirc, and I don't really agree with his
> supposition that initial packaging is such quick work that the ITP
> delay is significant.

The typical package is fairly trivial to create. Often the rules file
doesn't need modifications anymore, so unless a man page has to be
written (which can be put off anyway), the control and copyright file
are probably what takes the longest. 

But, writing an ITP requires looking up most of the control file data,
and requires researching the copyright too. For that matter, I'll bet
that many developers do some basic compiling and running of the program
before sending off the ITP -- why ITP something that you've never used?
So the package can easily be half way complete before the ITP is sent.

Running reportbug WNPP, filtering the existing reports to find a
duplicate, and filling in basic data with cut-n-paste takes two or three
minutes. Add the several minutes it takes to get a number back, add the
interrupt needed to go check mail and get the bug, avoid getting dragged
into some thread on debian-devel while doing it, and you've spent 10
minutes on the ITP if you're lucky, and I would guess, more likely half
an hour.

The best way to become "hyper-efficient" is to avoid this kind of
overhead, automate everything, and be prepared to fail quickly and
iterate.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: usefulness of ITPs (Re: mosh ITP not done, just package name taken over)

[Jean-Christophe Dubacq]

On 28/03/2012 00:46, Joey Hess wrote:
> Jon Dowland wrote:
>> That was Joey's hypothetical, iirc, and I don't really agree with his
>> supposition that initial packaging is such quick work that the ITP
>> delay is significant.
> 
> The typical package is fairly trivial to create. Often the rules file
> doesn't need modifications anymore, so unless a man page has to be
> written (which can be put off anyway), the control and copyright file
> are probably what takes the longest. 
> 
> But, writing an ITP requires looking up most of the control file data,
> and requires researching the copyright too. For that matter, I'll bet
> that many developers do some basic compiling and running of the program
> before sending off the ITP -- why ITP something that you've never used?
> So the package can easily be half way complete before the ITP is sent.
> 
> Running reportbug WNPP, filtering the existing reports to find a
> duplicate, and filling in basic data with cut-n-paste takes two or three
> minutes. Add the several minutes it takes to get a number back, add the
> interrupt needed to go check mail and get the bug, avoid getting dragged
> into some thread on debian-devel while doing it, and you've spent 10
> minutes on the ITP if you're lucky, and I would guess, more likely half
> an hour.
> 
> The best way to become "hyper-efficient" is to avoid this kind of
> overhead, automate everything, and be prepared to fail quickly and
> iterate.
> 
What about a dev. script that would be run in debian/ and would parse
debian/control and send the ITP? I can write that!


-- 
Jean-Christophe Dubacq



signature.asc
Description: OpenPGP digital signature