Re: Thoughts on Debian quality, including automated testing

[Frank Küster]

Benjamin Seidenberg <[EMAIL PROTECTED]> wrote:

> Andrew Suffield wrote:
>
>>On Fri, Dec 23, 2005 at 02:31:19PM -0500, Benjamin Seidenberg wrote:
>>
>>> Instead, why not propose a Responsible-For: header for control that
>>> lists a person inside the project who the buck stops with in the
>>> case of an applicant or team maintained package?
>>>
>>
>>Because I don't see how it would be semantically different to the
>>Maintainer field. The distinction between them is not apparent (what
>>is Maintainer supposed to mean under this scheme?). And adding new
>>fields is more work, so you don't do it without a good reason.
>>
>>
> The difference is who does the work. 

I a well-team-maintained package, the work is actually done by "the
team", and decisions are made after finding a consensus solution in the
team.

> The Responsible field would be
> the one to talk to if the package does something bad from the
> project's perspective such as a deliberate security issue or it not
> being up to snuff. 

I don't see why you wouldn't want to talk to the list in this case.  We
don't need someone to put the blame on (we don't have and don't want any
"punishment"), rather we need someone to make the necessary changes, be
it in the package or in the minds of the people who maintain the package.

> They would also be the one to talk to if the
> maintainer or team doesn't respond to other complaints. The maintainer
> would be the one that users look to on a daily basis - manages bugs,
> does most of the work, etc.

I really can't see the difference, neither in a team-maintained package
nor with an applicant.  In the latter case, of course the sponsor is
responsible; but even then there's not much point in talking to the
sponsor if the applicant can just search a new one.

If a package is badly maintained and you get no response, the usual
procedure is to start with NMUs and proceed with orphaning the package
(or taking over); where's the difference here between a non-responsive
single maintainer and a non-responsive team?

And in case of complaints about a package, how should someone be able to
make good decisions if he does *not* receive the messages about it on a
daily basis, but instead has to dig through them afterwards?  Well,
there might be rare cases where this is the only way to get an outside
view of some quarrel, but we already have the TC for this.

> Basically, the Responsible field would be what you suggested - a
> Debian Developer in good standing who offers accountability for the
> project. 

Ah, so we're going to have two classes of DDs:  The ones with "good
standing", and the others who are not allowed to be in the Responsible
field? 

> The Maintainer would be the person or team doing the work,
> possibly a mailing list or someone who is not a DD. The key is that
> the Responsible-Person field would add accountability.

Accountability?  That only makes sense if there are consequences in case
that person  does bad work.  Either a "criminal action", or some sort of
private punishment like having to pay money.  All this does not exist in
Debian, and IMO it doesn't make sense to introduce them.

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: Bug#344626: ITP: svn2cl -- Convert Subversion logs to GNU-style ChangeLogs

[Florian Ragwitz]

On Fri, Dec 23, 2005 at 09:15:29PM -0800, Russ Allbery wrote:
> svn2cl generates a text GNU-style ChangeLog from a Subversion repository
> log by transforming the output of svn log.  It also has preliminary
> support for generating HTML ChangeLog files.  For CVS users, it is roughly
> equivalent to cvs2cl but for Subversion.

Is this tool somehow related to [0]gnuify-changelog.pl in the subversion
package? What can it do more?

0. /usr/share/doc/subversion/examples/gnuify-changelog.pl.gz


-Flo

-- 
BOFH excuse #310:
asynchronous inode failure


signature.asc
Description: Digital signature

Re: switching to vim-tiny for standard vi? -> which editor should be standard?

[Osamu Aoki]

Hi,

Since I have not seem posting from Miquel...

For this discussion of "Which editor should be installed as default on`
the each Debian system?", I think more technical discussion should be
done.  This is old topic. We can always install nano, nvi or vim-* later
as you wish by "sudo aptitude install " :-)

(Disclaimer: I use vim exclusively.)

> From: Stefano Zacchiroli <[EMAIL PROTECTED]>
> Hi Joey, vim-tiny is available in debian/unstable. There are still some
> minor bugs, but the package is fine. The installed-size of it and of
> vim-common are as I anticipated (776 + 232 on i386); the only additional
> dependencies are libc6 and libncurses5.

Well is this small?  By the way, we should also check nano too.

Let me review some status of small editors. (Listed by the size)

Package: elvis-tiny
Priority: optional
Installed-Size: 148
Maintainer: Miquel van Smoornburg <[EMAIL PROTECTED]>
Version: 1.4-20
Pre-Depends: libc6 (>= 2.3.2.ds1-21), libncurses5 (>= 5.4-1)
Size: 46090

Package: nano-tiny
Priority: optional
Installed-Size: 220
Source: nano
Version: 1.3.9-1
Depends: libc6 (>= 2.3.5-1), libslang2 (>= 2.0.1-1)
Size: 138512

Package: nvi
Priority: important
Installed-Size: 632
Version: 1.79-22
Depends: libc6 (>= 2.3.2.ds1-4), libncurses5 (>= 5.4-1)
Size: 288166

Package: vim-tiny
Priority: optional
Installed-Size: 776
Version: 1:6.4-006+1
Depends: vim-common (= 1:6.4-006+1), libc6 (>= 2.3.5-1), libncurses5 (>= 5.4-5)
Size: 377374

Package: vim-common
Priority: optional
Section: editors
Installed-Size: 228
Version: 1:6.4-006+1
Recommends: vim | vim-tiny
Size: 80504

--> This means vim-tiny, it took Installed-Size: 1004 and Size: 457878

Package: nano
Priority: important
Installed-Size: 1380
Version: 1.3.9-1
Depends: libc6 (>= 2.3.5-1), libncursesw5 (>= 5.4-5)
Size: 461694

So aside from vim-tiny, what we have in sid priority important, nvi and
nano, are not smallest editors for the job.  From technical point, we
should chose elvis-tiny and nano-tiny.  Both of these editor have
commands in /bin which is always with us. (What happens if you have NFS
mounted /usr ?)

In terms of updating editors which is installed as the default rescue
system, we should chose small ones: nano-tiny and elvis-tiny.
(elvis-tiny is another vi-clone.).

Sarge installer installs nano and nvi.  I thought it was sort of
overlooked bug of installer.  nano and nvi are in /usr/bin.

Cheers,

Osamu



signature.asc
Description: Digital signature

Re: switching to vim-tiny for standard vi? -> which editor should be standard?

[Frans Pop]

On Saturday 24 December 2005 14:15, Osamu Aoki wrote:
> Sarge installer installs nano and nvi.  I thought it was sort of
> overlooked bug of installer.  nano and nvi are in /usr/bin.

s/installer/debootstrap/

And debootstrap just installs the base system based on package 
characteristics (mainly priority), so it all boils down again to the 
definition of the base system.

Cheers,
FJP


pgp9NZmd3YKPx.pgp
Description: PGP signature

Re: Thoughts on Debian quality, including automated testing

[Benjamin Seidenberg]

Frank Küster wrote:


Benjamin Seidenberg <[EMAIL PROTECTED]> wrote:

 


Andrew Suffield wrote:

   


On Fri, Dec 23, 2005 at 02:31:19PM -0500, Benjamin Seidenberg wrote:

 


Instead, why not propose a Responsible-For: header for control that
lists a person inside the project who the buck stops with in the
case of an applicant or team maintained package?

   


Because I don't see how it would be semantically different to the
Maintainer field. The distinction between them is not apparent (what
is Maintainer supposed to mean under this scheme?). And adding new
fields is more work, so you don't do it without a good reason.


 

The difference is who does the work. 
   



I a well-team-maintained package, the work is actually done by "the
team", and decisions are made after finding a consensus solution in the
team.

 

Right. That was the biggest problem I had with Andrew's idea, he wanted 
to use the maintainer field for one person and only one person, who was 
a DD. As an applicant, I didn't particularly care for this, and 
suggested a "lesser-of-two-evils" approach.



The Responsible field would be
the one to talk to if the package does something bad from the
project's perspective such as a deliberate security issue or it not
being up to snuff. 
   



I don't see why you wouldn't want to talk to the list in this case.  We
don't need someone to put the blame on (we don't have and don't want any
"punishment"), rather we need someone to make the necessary changes, be
it in the package or in the minds of the people who maintain the package.

 

*shrug* I agree. At least in my suggestion, you still have the 
maintainer field, as opposed to it being a single DD in Andrew's proposal.



They would also be the one to talk to if the
maintainer or team doesn't respond to other complaints. The maintainer
would be the one that users look to on a daily basis - manages bugs,
does most of the work, etc.
   



I really can't see the difference, neither in a team-maintained package
nor with an applicant.  In the latter case, of course the sponsor is
responsible; but even then there's not much point in talking to the
sponsor if the applicant can just search a new one.

If a package is badly maintained and you get no response, the usual
procedure is to start with NMUs and proceed with orphaning the package
(or taking over); where's the difference here between a non-responsive
single maintainer and a non-responsive team?

 


Again, it was my way of tempering Andrew's proposal.


And in case of complaints about a package, how should someone be able to
make good decisions if he does *not* receive the messages about it on a
daily basis, but instead has to dig through them afterwards?  Well,
there might be rare cases where this is the only way to get an outside
view of some quarrel, but we already have the TC for this.
 

That was one of my points, under Andrew's proposal, the maintainer would 
become a DD and the team/applicant wouldn't recieve these emails.


 


Basically, the Responsible field would be what you suggested - a
Debian Developer in good standing who offers accountability for the
project. 
   



Ah, so we're going to have two classes of DDs:  The ones with "good
standing", and the others who are not allowed to be in the Responsible
field? 
 

I would assume all DD's are members in good standing of the project, if 
not, shouldn't they be kicked out?


 


The Maintainer would be the person or team doing the work,
possibly a mailing list or someone who is not a DD. The key is that
the Responsible-Person field would add accountability.
   



Accountability?  That only makes sense if there are consequences in case
that person  does bad work.  Either a "criminal action", or some sort of
private punishment like having to pay money.  All this does not exist in
Debian, and IMO it doesn't make sense to introduce them.

Regards, Frank
 

Again, this is partly a response to Andrew's proposal of only allowing a 
DD as a maintainer and having them as the person where "the buck stops 
here". The accountability he wants is the one refered to here.


Cheers,
Benjamin



signature.asc
Description: OpenPGP digital signature

Re: /run vs /var/run

[Goswin von Brederlow]

Russell Coker <[EMAIL PROTECTED]> writes:

> On Saturday 24 December 2005 11:35, Goswin von Brederlow 
>> Basicaly everything that needs /run doesn't use /var/run anyway,
>> e.g. mount. And one could link /var/run to /run on both / and /var and
>> then nothing needs to change even if it uses /var/run.
>
> You mean to say that nothing needs to change about from adding a new 
> directory 
> that's not in the FHS.

I mean that stuff that needs an early writebale dir doesn't/can't use
/var/run for technical reasons already. They use /etc or hack around
for themself or even already use /run. By picking /run over /var/run
probably no package will stop using /var/run if it now can use it
without hacks.

So by making /run official there is no extra fixing of package that
don't already need fixing anyway. I think that given the number of
users with a seperate /var partition buggy packages that use /var/run
too early will have been found already.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Priority=important: elvis-tiny & nano-tiny / Priority=optional: nvi, vim-tiny, nano, elvis, vim

[Osamu Aoki]

On Sat, Dec 24, 2005 at 02:13:25PM +0100, Frans Pop wrote:
> On Saturday 24 December 2005 14:15, Osamu Aoki wrote:
> > Sarge installer installs nano and nvi.  I thought it was sort of
> > overlooked bug of installer.  nano and nvi are in /usr/bin.
> 
> s/installer/debootstrap/

Yes, thast is more precise.

> And debootstrap just installs the base system based on package 
> characteristics (mainly priority), so it all boils down again to the 
> definition of the base system.


For things like editor, we can istill review priority based on the size
and technical merits.  

This should lead us to make elvis-tiny and nano-tiny important while
others should stay as optional.  We also have ed as important and cat is
always with us.  (None of the editor need to be required either.  So
removing them are also easy.)

We have system with mawk (Priority=required) but usually no gawk
(Priority=optional) nor original-awk(Priority=optional) installed.  Out
of these awk variants, original-awk seems to be the smallest.  Changing
this priority on awk just by size is something I do not want to see.
But we can still do that with editor.  

So instead of adding more editor to our base by boosting packasge"s
priority, we should have priority set to optional for most editors exept
nano-tiny and elvis-tiny.  (c)debootstrap should only install these 2
editors except talled otherwise.  That is my observation.

Osamu



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: /run vs /var/run

[Russell Coker]

On Sunday 25 December 2005 00:55, Goswin von Brederlow 
<[EMAIL PROTECTED]> wrote:
> Russell Coker <[EMAIL PROTECTED]> writes:
> > On Saturday 24 December 2005 11:35, Goswin von Brederlow
> >
> >> Basicaly everything that needs /run doesn't use /var/run anyway,
> >> e.g. mount. And one could link /var/run to /run on both / and /var and
> >> then nothing needs to change even if it uses /var/run.
> >
> > You mean to say that nothing needs to change about from adding a new
> > directory that's not in the FHS.
>
> I mean that stuff that needs an early writebale dir doesn't/can't use
> /var/run for technical reasons already.

Unless /var/run is a tmpfs.

> So by making /run official there is no extra fixing of package that
> don't already need fixing anyway.

By making /var/run a tmpfs there is no need to fix any package, and in 
addition we get things working better on flash memory systems (which I expect 
to become really popular soon - see the OLPC project for an example).

> I think that given the number of 
> users with a seperate /var partition buggy packages that use /var/run
> too early will have been found already.

A tmpfs on /var/run can work with a separate /var partition, I've already 
suggested a way of making it work.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#344675: ITP: libreturn-value-perl -- Polymorphic Return Values

[Krzysztof Krzyzaniak (eloy)]

Package: wnpp
Severity: wishlist
Owner: "Krzysztof Krzyzaniak (eloy)" <[EMAIL PROTECTED]>

* Package name: libreturn-value-perl
  Version : 1.30
  Upstream Authors: Casey West <[EMAIL PROTECTED]>, Ricardo Signes <[EMAIL 
PROTECTED]> 
* URL : http://www.example.org/
* License : Perl: Artistic/GPL
  Description : Polymorphic Return Values

 Polymorphic return values are really useful.  Often, we just want toknow if
 something worked or not.  Other times, we'd like to know what the error text
 was.  Still others, we may want to know what the error code was, and what the
 error properties were.  We don't want to handle objects or data structures for
 every single return value, but we do want to check error conditions in our 
 code because that's what good programmers do.
 .
 When functions are successful they may return true, or perhaps some useful
 data.  In the quest to provide consistent return values, this gets confusing
 between complex, informational errors and successful return values.
 .
 This module provides these features with a simple API that should get you what
 you're looking for in each contex a return value is used in.
 
-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14-1-686
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: kernel-package hooks transition

[Sven Luther]

On Sat, Dec 24, 2005 at 09:19:36AM -0600, Manoj Srivastava wrote:
> Hi,
> 
> In the recent 10.X series, kernel package has started
>  producing image packages whose maintainer scripts use debconf for
>  user interaction.  Unfortunately, this meant that any hook scripts
>  called in the maintainer scripts for the image package (update-grub
>  comes to mind), if they wrote anything at all to the STDout, would
>  cause debconf to throw hissy fits, since it was expecting commands on
>  STDOUT, not random chatter from the hook scripts.
> 
> One solution was to call db_stop before calling the hook
>  scripts, and redirecting stdout to stderr  in hte invocation of the
>  scripts. Unfortunately, this made any scripts that used debconf
>  impossible.

Notice that the debconf helper scripts provide stdout on &3, so any scripts
writing to stdout only need to redirect their output to &3, no ? 

Another idea would be to have some tag or something to declare if the script
uses debconf or not, and to do the redirection depending on that ? It could be
parsing for something like :

 KPKG-TAG: debconf

(where  is # for shell scripts, obviously).

This would allow for the most flexibility, and still work out fine, and
parsing would be a simple grep command, so rather cheap (if grep
KPKG-TAG.*debconf; then debconf stuff; else non-debconf stuff; fi)

Oh and BTW, 10.023 did not fix the mkvmlinuz problem, not sure if you saw me
reopening the bug reports. I will try to investigate this on tuesday, altough
i am really lost about this and help will be welcomed.

For powerpc users, a workaround is to remove the debconf stuff by hand. There
are two scripts : 

/etc/kernel/postinst.d/mkvmlinuz and /etc/kernel/prerm.d/mkvmlinuz

And the best way is to replace the lines : 

  . /usr/share/debconf/confmodule

  db_get mkvmlinuz/bootloaders
  bootloader="$RET"

by :

  bootloader=

Where  is yaboot on pmac and rs6k, and mkvmlinuz otherwise.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: kernel-package hooks transition

[Colin Watson]

On Sat, Dec 24, 2005 at 05:03:17PM +0100, Sven Luther wrote:
> Notice that the debconf helper scripts provide stdout on &3, so any
> scripts writing to stdout only need to redirect their output to &3, no
> ? 

No, that won't work; if you send something to fd 3, it will go to the
debconf frontend and be interpreted as a debconf protocol command. In
any case, it's only the shell confmodule that sets up fd 3 to go to the
frontend, and the kernel-package-generated postinst is written in Perl;
people may well have written postinst.d fragments in Perl too. Please
use stderr instead, or, if possible, just make the script quiet.

The fd 3 redirection (and the corresponding redirection of stdout to
stderr in the shell confmodule) was always acknowledged as a nasty hack
in debconf. At the time, as I understand it, Joey reckoned it was easier
to do that than to try to get everyone to change maintainer script code
that used stdout. It has various undesirable consequences, such as the
requirement to call db_stop before starting daemons that don't take care
to close down all their file descriptors, and some very weird
workarounds in the confmodule bindings for other languages (see the
changelog entry for debconf 0.3.74).

My impression is that these days maintainer scripts are much better
about not mixing up debconf interaction with normal use of stdout, and
so it's still possible that the fd 3 hack will be removed some day.

-- 
Colin Watson   [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#344626: ITP: svn2cl -- Convert Subversion logs to GNU-style ChangeLogs

[Russ Allbery]

Florian Ragwitz <[EMAIL PROTECTED]> writes:

> Is this tool somehow related to [0]gnuify-changelog.pl in the subversion
> package? What can it do more?

> 0. /usr/share/doc/subversion/examples/gnuify-changelog.pl.gz

It's completely different and has some additional functionaly, most
notably actually listing the files that were changed, combining entries
for a single day if desired, adding the revision number if desired, more
closely outputting the ChangeLog style, and support for generating HTML.
It uses svn log --xml and an XSLT transform.

Turns out that the maintainer is a Debian developer, so I'm going to point
him at my package and probably won't end up maintaining it myself.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#344675: ITP: libreturn-value-perl -- Polymorphic Return Values

[Krzysztof Krzyzaniak]

Krzysztof Krzyzaniak (eloy) wrote:

Package: wnpp
Severity: wishlist
Owner: "Krzysztof Krzyzaniak (eloy)" <[EMAIL PROTECTED]>

* Package name: libreturn-value-perl
  Version : 1.30
  Upstream Authors: Casey West <[EMAIL PROTECTED]>, Ricardo Signes <[EMAIL PROTECTED]> 
* URL : http://www.example.org/


Missed url:

http://search.cpan.org/~rjbs/Return-Value-1.30/



* License : Perl: Artistic/GPL
  Description : Polymorphic Return Values


--
[EMAIL PROTECTED]

   jak to dobrze, że są oceany - bez nich byłoby jeszcze smutniej


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Size matters. Debian binary package stats

[Adam Heath]

On Sat, 24 Dec 2005, Goswin von Brederlow wrote:

> It would require some buildd hacking to get it to use gzip only for
> those few debs so more human power.

debs are created by debian/rules.  So, only dependencies of dpkg would have to
be modified.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#344707: ITP: ispell-et -- Estonian dictionaries for ispell, aspell, myspell

[Martin-Éric Racine]

Package: wnpp
Severity: wishlist
Owner: "Martin-Éric Racine" <[EMAIL PROTECTED]>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Package name : ispell-et
Version  : 20030606
URL  : http://www.meso.ee/~jjpp/speller/
aspell-et  - Estonian dictionary for aspell
iestonian  - Estonian dictionary for ispell
myspell-et - Estonian dictionary for myspell
openoffice.org-hyphenation-et - Estonian hyphenation pattern for OpenOffice.org

The ispell affix and wordlists, as well as the OOo hyphenation were found as 
standalone files at the above URL, along with explanations in Estonian about 
the origin of all files. Everything else is generated by my own debian/rules.

The above version is timestamp of the last update produced by Jaak Pruulmann. 

I already have packages ready to upload. I however need to verify whether the 
software license of the Institute of the Estonian Language is considered free
according to Debian policies, before I proceed with the upload.

Copyright:
2003-2005, Jaak Pruulmann <[EMAIL PROTECTED]> (updated wordlist)
1996-1999, Institute of the Estonian Language <[EMAIL PROTECTED]> (original 
wordlist)
1993, Enn Saar <[EMAIL PROTECTED]> (TeX hyphenation, converted for OpenOffice 
by Jaak)

License:
   The present Licence Agreement gives the user of this Software Product
   (hereinafter: Product) the right to use the Product for whatever purpose
   (incl. distribution, copying, altering, inclusion in other software,
   and selling) on the following conditions:

   1. The present Licence Agreement should belong unaltered to each copy
  ever made of this Product;
   2. Neither the Institute of the Estonian Language (hereinafter: IEL)
  nor the author(s) of the Product will take responsibility for any
  detriment, direct or indirect, possibly ensuing from the application
  of the Product;
   3. The IEL is ready to share the Product with other users as we wish
  to advance research on the Estonian language and to promote the use
  of Estonian in IT-technology now rapidly developing, yet we refuse
  to bind ourselves to any further obligation, which means that the
  IEL is not obliged either to warrant the suitability of the Product
  for a concrete use, to improve the program, or to provide a more
  detailed description of the underlying algorithms.
  (Which does not mean, though, that we may not do it.)
   4. Whenever you use the Product, we request that you inform us by writing
  to the e-mail address [EMAIL PROTECTED] or to street address listed below.

   Institute of the Estonian Language
   Roosikrantsi 6
   10119 Tallinn
   ESTONIA

   Phone & Fax: +372-6411443

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

iD8DBQFDrd7IeXr56x4Muc0RAnEKAJ9yBg9y2pwQaULxdzXjUWsdUqOnBQCgpVkL
ZJZzDQ5A6Nb5WJ5I5gWok84=
=PeLM
-END PGP SIGNATURE-

Re: kernel-package hooks transition

[Sven Luther]

On Sat, Dec 24, 2005 at 05:30:26PM +, Colin Watson wrote:
> On Sat, Dec 24, 2005 at 05:03:17PM +0100, Sven Luther wrote:
> > Notice that the debconf helper scripts provide stdout on &3, so any
> > scripts writing to stdout only need to redirect their output to &3, no
> > ? 
> 
> No, that won't work; if you send something to fd 3, it will go to the
> debconf frontend and be interpreted as a debconf protocol command. In

Well, you are the expert, i said this, because the
/usr/share/debconf/confmodule script i use in mkvmlinuz and recomended by
debconf-devel says :

# Redirect standard output to standard error. This prevents common
# mistakes by making all the output of the postinst or whatever
# script is using this library not be parsed as confmodule commands.
#
# To actually send something to standard output, send it to fd 3.

which i read that &1 goes to debconf and &3 to stdout normally. But then i am
largely out of my depth here, and would greatly greatly appreciate someone
with a real clue (you or joeyh being likely candidates here :) to have a look
at this issue. Mmm, need to go and read the rest of your mail really, ...

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: kernel-package hooks transition

[Sven Luther]

On Sat, Dec 24, 2005 at 05:30:26PM +, Colin Watson wrote:
> On Sat, Dec 24, 2005 at 05:03:17PM +0100, Sven Luther wrote:
> > Notice that the debconf helper scripts provide stdout on &3, so any
> > scripts writing to stdout only need to redirect their output to &3, no
>
> My impression is that these days maintainer scripts are much better
> about not mixing up debconf interaction with normal use of stdout, and
> so it's still possible that the fd 3 hack will be removed some day.

Ok, now i read it all, shouldn't really be replying to email after the
christmas party ... :)

So, do you have any idea of what is going wrong here and how to fix it ? I
mean having hosed powerpc kernels over christmas is really not the nicest
thing to have happen, and i really don't understand the subtleties of what is
going on here.

k-p uses debconf (probably using the perl helpers you mentioned), and does a
db_stop before calling the script hooks.

The script hooks, of which only mkvmlinuz uses debconf, but using debconf
being the right thing to do probably given the debconf-related policy, so the
script hooks calls debconf itself, which checks that debconf is not yet
running and reruns it if not.

My belief is that somehow there is an inconsistency in the debconf helper,
maybe in the interaction of the perl debconf helper and especially the perl
db_stop, with the shell debconf helper. Can this be ? 

Do we have some kind of documented spec of how these helpers do handle the
debconf interaction, or something, which would enable to investigate this
issue without lengthy error-and-trial ?

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: kernel-package hooks transition

[Sven Luther]

On Sat, Dec 24, 2005 at 05:30:26PM +, Colin Watson wrote:
> On Sat, Dec 24, 2005 at 05:03:17PM +0100, Sven Luther wrote:
> > Notice that the debconf helper scripts provide stdout on &3, so any
> > scripts writing to stdout only need to redirect their output to &3, no
> > ? 
> 
> No, that won't work; if you send something to fd 3, it will go to the
> debconf frontend and be interpreted as a debconf protocol command. In
> any case, it's only the shell confmodule that sets up fd 3 to go to the
> frontend, and the kernel-package-generated postinst is written in Perl;
> people may well have written postinst.d fragments in Perl too. Please
> use stderr instead, or, if possible, just make the script quiet.

Oh, and merry christmas to you and thanks for your help in replying to this
even on christmas eve's, ok off to bed now.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: kernel-package hooks transition

[Adam Heath]

On Sun, 25 Dec 2005, Sven Luther wrote:

> Well, you are the expert, i said this, because the
> /usr/share/debconf/confmodule script i use in mkvmlinuz and recomended by
> debconf-devel says :
>
> # Redirect standard output to standard error. This prevents common
> # mistakes by making all the output of the postinst or whatever
> # script is using this library not be parsed as confmodule commands.
> #
> # To actually send something to standard output, send it to fd 3.
>
> which i read that &1 goes to debconf and &3 to stdout normally. But then i am
> largely out of my depth here, and would greatly greatly appreciate someone
> with a real clue (you or joeyh being likely candidates here :) to have a look
> at this issue. Mmm, need to go and read the rest of your mail really, ...

No, that says 1 goes to 2, 3 goes to stdout, and stdout is connected to
debconf.

I bet you'll find the debconf commands sending data to 3.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]