Dustin Kirkland | 1 Aug 01:17
Favicon

Mass bug filing: init script "status" action

Howdy debian-devel-

The LSB 3.1 specification [1] defines a 'status' action for
LSB-compliant init scripts.  Some high-availability (HA) packages
included in Debian expect to use a 'status' action as provided by the
init script [2] to query daemon status.  In general, such 'status'
actions in Debian would be broadly useful to both system administrators
and users.

The lsb-base 3.2-14 package adds a new library function
to /lib/lsb/init-functions; namely, status_of_proc() [3,4].  This
function can be used in the vast majority of init scripts to generically
provide an interface to gathering and reporting status.  Individual init
script patches often look something like:

+  status)
+       status_of_proc -p "$PIDFILE" "$DAEMON" "$NAME" && exit 0 || exit $?
+       ;;

As an example, see Debian Bug #492138 against rsync and the associated
patch [5].

Bug #208010 suggests LSB-compliance of all init scripts in Debian [6].
And Bug #291148 suggests a debian-policy change requiring 'status'
actions for all init scripts [7].  I believe that the new functionality
present in lsb-base provides a healthy framework for advancing such
'status' actions in a vast number of Debian init scripts.

In Ubuntu, we have undertaken an effort to patch as many such init
scripts as possible [8].  In most of these cases, we would like to
(Continue reading)

Russ Allbery | 1 Aug 01:44
Picon
Favicon

Re: Should the X packages pre-depend on awk?

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

> BTW, the packages backupninja, dlocate, gt5, linuxdoc-tools, and
> lsb-core appear to have spurious dependencies on either 'awk' or 'mawk |
> gawk'.

awk is spurious.  mawk | gawk *probably* is, but it's possible that the
semantics there are intentional ("relies on features provided explicitly
by mawk and gawk but not by a generic awk implementation").

--

-- 
Russ Allbery (rra <at> debian.org)               <http://www.eyrie.org/~eagle/>

Russ Allbery | 1 Aug 01:54
Picon
Favicon

Re: Mass bug filing: init script "status" action

Dustin Kirkland <kirkland <at> canonical.com> writes:

> Bug #208010 suggests LSB-compliance of all init scripts in Debian [6].
> And Bug #291148 suggests a debian-policy change requiring 'status'
> actions for all init scripts [7].

Just to say explicitly, these aren't reasons for mass-filing bugs.  These
are unadopted Policy proposals and hence have no authority or weight.

However, if your goal is to unblock those proposals, getting the archive
to convert over is the best next step.  Then the Policy proposal can go
through without making lots of packages instantly buggy.

> In Ubuntu, we have undertaken an effort to patch as many such init
> scripts as possible [8].  In most of these cases, we would like to
> contribute this functionality back to the Debian package.  I believe
> this flow of bugs and patches would qualify as a 'mass bug filing' [9].
> So far, we filed a few bugs before it was suggested that we propose this
> on the debian-devel mailing list:
>  * 492126, 492131, 492138, 492541, 492625  
>
> Is it ok to continue filing these requests as wishlist bugs, or is
> another approach preferred?

I think it's reasonable to file a wishlist bug with a patch to every
package that you've modified in this fashion since you're also providing
tested custom patches for each package.

Mass-filing bugs *without* patches, though, I don't think is a good
approach, since you'd be filing bugs against nearly every package with an
(Continue reading)

Peter Samuelson | 1 Aug 02:15

Re: Mass bug filing: init script "status" action


[Russ Allbery]
> I think it's reasonable to file a wishlist bug with a patch to every
> package that you've modified in this fashion since you're also providing
> tested custom patches for each package.

Tested?  I thought he just said they were patching them in Ubuntu.
--

-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
Russ Allbery | 1 Aug 02:50
Picon
Favicon

Re: Mass bug filing: init script "status" action

Peter Samuelson <peter <at> p12n.org> writes:
> [Russ Allbery]

>> I think it's reasonable to file a wishlist bug with a patch to every
>> package that you've modified in this fashion since you're also
>> providing tested custom patches for each package.

> Tested?  I thought he just said they were patching them in Ubuntu.

Yes, the slight semantic change between what he said and what I said was
intentional.  :)

--

-- 
Russ Allbery (rra <at> debian.org)               <http://www.eyrie.org/~eagle/>

Peter Samuelson | 1 Aug 02:57

Re: Mass bug filing: init script "status" action


[I wrote]
> Tested?  I thought he just said they were patching them in Ubuntu.

While we don't have a code of conduct or anything, somebody chided
me out-of-band for making an unhelpful comment.  He's right, and I
apologize.  Russ already made the relevant point better than I did:
that patches should be tested before being posted in a MBF.
--

-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
Paul Wise | 1 Aug 03:27
Picon
Favicon
Gravatar

Re: Needs help: CJK Debian users will not be able to read PDF with poppler-data in default Debian Desktop in Lenny

On Thu, Jul 31, 2008 at 8:43 AM, Hideki Yamane <henrich <at> debian.or.jp> wrote:

>  But evince was changed. We need poppler package (depends on libpoppler-glib3)
>  to view PDF files, and if you want to view Japanese PDF file, you
>  also need to install poppler-data - but it is NOT in Debian yet.

Debian lenny is frozen, it is too late to get new packages in.

> How do we deal with this issue?

The first two solutions proposed in #481134 sound fine, just someone
to make the required changes.

--

-- 
bye,
pabs

http://wiki.debian.org/PaulWise

wnpp | 1 Aug 08:27
Picon
Favicon

Work-needing packages report for Aug 1, 2008

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 461 (new: 6)
Total number of packages offered up for adoption: 118 (new: 0)
Total number of packages requested help for: 50 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.

------------------------------------------------------------------------

The following packages have been orphaned:

   dnotify (#492504), orphaned 5 days ago
     Description: Execute a command when the contents of a directory
       change
     Installations reported by Popcon: 167

   eterm (#492496), orphaned 5 days ago
     Description: Enlightened Terminal Emulator
     Reverse Depends: debroster gsetroot
     Installations reported by Popcon: 1910

   feh (#492503), orphaned 5 days ago
     Description: imlib2 based image viewer
     Installations reported by Popcon: 1367

   libast (#492497), orphaned 5 days ago
     Description: the Library of Assorted Spiffy Things
(Continue reading)

Stefano Zacchiroli | 1 Aug 09:53
Picon
Favicon

Re: Mass bug filing: init script "status" action

On Thu, Jul 31, 2008 at 04:54:03PM -0700, Russ Allbery wrote:
> I think it's reasonable to file a wishlist bug with a patch to every
> package that you've modified in this fashion since you're also providing
> tested custom patches for each package.

I personally agree on this approach and welcome the initiative. As an
additional technical detail I suggest to tag the bugs with an
appropriate usertag, so that we can easily follow the evolution of the
implementation.

Cheers.

--

-- 
Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
I'm still an SGML person,this newfangled /\ All one has to do is hit the
XML stuff is so ... simplistic  -- Manoj \/ right keys at the right time
Christian Perrier | 1 Aug 08:54
Picon
Favicon
Gravatar

Re: Mass bug filing: init script "status" action

Quoting Russ Allbery (rra <at> debian.org):

> I think the combination of a Lintian check plus filing wishlist bugs with
> patches for each init script where you've tested the modifications is a
> good combination.

The Lintian check could include a small example of what to do in case
this can be generic enough.

Of course, doing so *will* lead to maintainers copying/pasting the
example to their init scripts so the example has to be generic and
functional enough.

But I really agree, anyway, that a lintian check is certainly the best
way to achieve this.

Indeed, this would perfectly qualify as a lenny+1 release goal...:-)

Back to the topic: one of the mentioned "initial" bug reports was sent
against samba (#488275) with very good interaction with the bug
submitter (he proposed a patch, we^WSteve criticized it, and we nearly
converged on something we could decide to implement post-lenny).


Gmane