headers
Manoj Srivastava | 1 Dec 01:24
X-Face
Face
Picon
Favicon

Triaging bugs

Hi,

        I think I am coming up on a period where I have time again to
 devote to Debian, and am beginning to start to triage some policy bugs,
 to chime in and help out russ, who has mostly been carrying the torch
 the last few months.

        Following his example, I have created usecategories to help me
 triage the policy issue, and  be more efficient while working on the
 policy package; and I figured that if I share it with y'all maybe I
 could sucker^H^H^H^H^H^Hentice afew people to pitch in help move the
 process along.

        Once we have some experience working with this, and figuring out
 the right granularity of the categories, perhaps we'll create a
 debian-policy <at> lists.debian.org usercategory for the official state of
 the policy  process.

        So, here is my classification of policy issues, with the
 unclassified bugs bubbling to the top. Enjoy.

http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&users=srivasta <at> debian.org&ordering=policy

        manoj
--

-- 
Cheer Up!  Things are getting worse at a slower rate.
Manoj Srivastava <srivasta <at> debian.org> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C
(Continue reading)

Permalink | Reply | 1 comment |
headers
Martín Ferrari | 1 Dec 06:11
Picon
Gravatar

Re: Bug#451799: new evince cannot display Japanese characters correctly

(Dropping -legal from the cc)

On Nov 27, 2007 3:56 PM, Josselin Mouette <joss <at> debian.org> wrote:

> The new poppler version needs some specific files that contain some
> mappings between Unicode and other encodings, which are in a separate
> package.

That's all that it contains? can't that be reproduced with data from
iconv or similar?

--

-- 
Martín Ferrari
Permalink | Reply | 1 comment |
headers
Manoj Srivastava | 1 Dec 07:29
X-Face
Face
Picon
Favicon

Draft new policy document format

Hi,

        At Debconf earlier this year, I gave a talk about the benefits
 of creating language for a lintian/linda check whenever we introduce a
 new policy rule (when appropriate, and feasible, of course).  Not only
 do we get a  instant Lintian check, but it would also tend to focus the
 discussion and design of the policy rule.

        There a re a number of bits and pieces of policy scattered
 across several documents, not all of which can be found in the policy
 package.  These documents cover different areas, Menu, Python, Perl, X,
 etc. They also are at different places in the spectrum from release
 critical measures to best practice recommendations.

        Also, there are various levels at which people tend to approach
 the policy document;  some people prefer reading the document by
 topics; which is useful is one is packaging something  in a topic area
 covered by multiple policy documents; others just want to see the
 "hard" policy rules, and defer best practices until later, to prevent
 being drowned in a flood of information.

        Then there is the dimension of Debian sub projects and
 Derivatives, who would perhaps benefit from deriving from Debian
 policy, but adding some specialized directives of their own.

        One solution that enables all these use cases is doing a set of
 books,  each book being a separate entity, with different author sets,
 but all using a common schema; each rule is an entity, has title,
 severity, normative section, rationale, informative section, and
 lintian psuedo-code.  Each book can have separate copyrights, SCM
(Continue reading)

Permalink | Reply | 14 comments |
headers
Christian Perrier | 1 Dec 07:55
Picon
Favicon
Gravatar

Re: old homepage pseudo-field (future mass-bug filing?)

Quoting Stefano Zacchiroli (zack <at> debian.org):
> Hi, at http://sockmel.bononia.it/~zack/homepage-field/ I'm collecting
> some numbers about the usage of the new homepage field in debian/control
> vs that of the old pseudo-field in package description.
> 
> There should be all the info needed for a wish-list mass-bug filing ([1]
> is a direct link to a dd-list, so that people can check for false
> positives), though right now is probably too early (4'000 packages to
> go), but I'm not sure about the current policies for mass-bug filings.

I updated http://wiki.debian.org/DpkgHomepageFieldTransition with a
link to zack's pages as well as updated status for the various steps
described there.

With Manoj starting some cleaning work on policy's bug reports, I
expect the Policy part to be updated quite soon as well (would be good
for me to send a patch)
Permalink | Reply | 0 comments |
headers
Stefano Zacchiroli | 1 Dec 12:03
Picon
Favicon

Re: old homepage pseudo-field (future mass-bug filing?)

On Fri, Nov 30, 2007 at 05:55:43PM +0100, Christian Perrier wrote:
> May I point you to http://wiki.debian.org/DpkgHomepageFieldTransition ?

Yes, and thanks for this. As it was evident, I was not aware of that
page. And thanks to Russ for mentioning my stats there.

Cheers.

--

-- 
Stefano Zacchiroli -*- PhD in Computer Science ............... now what?
zack@{cs.unibo.it,debian.org,bononia.it} -%- http://www.bononia.it/zack/
(15:56:48)  Zack: e la demo dema ?    /\    All one has to do is hit the
(15:57:15)  Bac: no, la demo scema    \/    right keys at the right time
Permalink | Reply | 0 comments |
headers
Olaf van der Spek | 1 Dec 12:24
Picon
Gravatar

Re: net-tools maintenance status

On Aug 2, 2005 6:45 PM, Olaf van der Spek <olafvdspek <at> gmail.com> wrote:
> Hi,
>
> What's the maintenance status of the net-tools package?
> It has 88 bugs:
>
> A lot older than a year, 17 with patch a lot even without a single response.

Hi list,

I'm sorry to ask again, but:
What's the maintenance status of the net-tools package?
Is there any chance Lenny will ship with for example working IPv6
support in netstat?
I emailed MIA about this, but MIA went MIA itself, no response anymore. :(

The bug count is up to 112.
Only two NMU translation uploads have been done in the past two years.
No other uploads at all.

Please CC me, I'm not subscribed.

Greetings,

Olaf

http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=net-tools
http://packages.qa.debian.org/n/net-tools.html
(Continue reading)

Permalink | Reply | 8 comments |
headers
Guus Sliepen | 1 Dec 12:52
Picon
Favicon
Gravatar

Re: net-tools maintenance status

On Sat, Dec 01, 2007 at 12:24:58PM +0100, Olaf van der Spek wrote:

> I'm sorry to ask again, but:
> What's the maintenance status of the net-tools package?
> Is there any chance Lenny will ship with for example working IPv6
> support in netstat?
> I emailed MIA about this, but MIA went MIA itself, no response anymore. :(
> 
> The bug count is up to 112.
> Only two NMU translation uploads have been done in the past two years.
> No other uploads at all.

Hm, looks bad indeed. I'll try to see if Bernd Eckenfels is still alive
but if I can't reach him in a week I'll adopt the package.

--

-- 
Met vriendelijke groet / with kind regards,
      Guus Sliepen <guus <at> debian.org>
Permalink | Reply | 5 comments |
headers
Roger Leigh | 1 Dec 13:48

Re: net-tools maintenance status

"Olaf van der Spek" <olafvdspek <at> gmail.com> writes:

> I'm sorry to ask again, but:
> What's the maintenance status of the net-tools package?

Looking at the changelog in unstable, pretty much the same as last
time you wrote, aside from the two minor NMUs you mentioned.

> Is there any chance Lenny will ship with for example working IPv6
> support in netstat?
> I emailed MIA about this, but MIA went MIA itself, no response anymore. :(
>
> The bug count is up to 112.
> Only two NMU translation uploads have been done in the past two years.
> No other uploads at all.

Maybe time for a hijack of the package, or at least an NMU to get the
bugs fixed.

Regards,
Roger

--

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.
Permalink | Reply | 1 comment |
headers
Roger Leigh | 1 Dec 15:03

Re: xinetd is a viable inet-superserver

md <at> Linux.IT (Marco d'Itri) writes:

> On Nov 29, Roger Leigh <rleigh <at> whinlatter.ukfsn.org> wrote:
>
>> - create a /etc/inetd.d directory
> Wrong approach. Write an update-inetd replacement which can maintain its
> own database and can compare it to an existing configuration to know if
> the local admin changed something.

I don't see a great difference here, to be honest, since both achieve
the same end.

- Your approach is opaque to the user, allowing direct editing of the
  non-conffile /etc/inetd.conf with rather complex parsing and
  comparison code.
- My approach is non-opaque to the user, requiring editing of a
  inet.d/service file for each service, but with a trivial parser
  which will be both understandable and maintainable.

The former approach is nicer in theory, but I do have to wonder why we
haven't done so already.  My guess is that it's rather difficult and
no one cared enough to devote the effort.  But, we do need to do
something--the current approach is not good enough IMO.

>> IIRC I did mention something along these lines for consideration
> So I probably already told you that you were wrong.

A detailed explanation of why would be helpful.  I'd like to
understand your rationale.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Roger Leigh | 1 Dec 15:25

Re: xinetd is a viable inet-superserver

Steve Langasek <vorlon <at> debian.org> writes:

> On Thu, Nov 29, 2007 at 10:17:22PM +0000, Roger Leigh wrote:
>> The main problem (as I see it) is that the current update-inetd is too
>> complex, and can't migrate configurations between different inetd
>> config file formats.
>
> Why should that be the job of the current update-inetd?

My opinion here is that one should be able to install any package
Providing inet-superserver and expect the configuration to be carried
over in some working form and get a working system.  The Provides
should be indicating some basic level of equivalence in functionality
between the packages.

>> And every maintainer script has to call update-inetd to make it write
>> package-specific information, which is fragile
>
> Fragile in what sense?

You can break the configuration of packages registering their services
with update-inetd depending upon the specific order of installation
and removal, particularly when combined with the replacement of one
inet-superserver package with another.

>> it only gets done when you install the package, and if you screw up
>> inetd.conf, too bad.
>
> Er?  Screw it up how?  Why would it not be fixable with dpkg-reconfigure
> $package?
(Continue reading)

Permalink | Reply | 0 comments |

Gmane