Re: "The Debian exim 4 packages suck badly" on exim-users@exim.org

[Tore Anderson]

* Tollef Fog Heen

 > It's also a nice way for other packages to update exim's configuration
 > -- I'm considering shipping files for mailman, for instance.  It would
 > be nice if SA did the same and so on.

  But you'd do it so that the routers/transports you add are disabled by
 default, right?  I would consider it outright evil to change the generated
 configuration the Exim binary use, when you cannot be sure if the user has
 changed other files under conf.d/.

-- 
Tore Anderson


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

Re: "The Debian exim 4 packages suck badly" on exim-users@exim.org

[Tore Anderson]

* Tollef Fog Heen

 > No.  If you have exim4 installed and install mailman, it's a
 > reasonable expectation that you want to use those two together.

  But you cannot know if I have changed, added, or removed files under
 conf.d/ in such a way which would make your drop-in routers and
 transports break the entire configuration.  The files are after all
 configuration the user is allowed to change as he pleases.

  Policy 10.7.3 says:

Configuration file handling must conform to the following behavior:

* local changes must be preserved during a package upgrade, [..]

  Even though you're not strictly changing _a_ configuration file by
 dropping files under conf.d, you're changing the configuration that
 Exim ends up reading.  I've always felt that the general principle
 that requirement is there for is something like "the user should be
 able to trust us not to fuck around with his custom configuration
 behind his back".  And unless you ensure that the snippets belonging
 to exim4-config isn't changed [in a significant way], you certainly
 will violate that principle.

 > It will be documented in NEWS.Debian ifwhen I get around to it.

  As far as I know NEWS.Debian is only displayed on upgrades, so that
 isn't sufficient.  That said, documenting that you're doing something
 undesireable isn't really an excuse for doing it in the first place.

  Please consider putting the snippets somewhere else, like under
 /etc/mailman/, and rather tell the user where to symlink them under
 /etc/exim4/conf.d/.

-- 
Tore Anderson


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

Re: "The Debian exim 4 packages suck badly" on exim-users@exim.org

[Tore Anderson]

* Marc Haber

 > If people change the configuration, they will have to bear with
 > breakage this has caused.

  If the users cannot safely change Exim's configuration (save using the
 Debconf scripts), it cannot be considered "configuration" by any Debian
 standard I have ever seen.  And if so, /etc is certinly not the right
 place for it.

  I really hope you didn't mean it the way I interpreted you..

-- 
Tore Anderson


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

Re: rebooting, non-root raid, udev

[Tore Anderson]

* Brian May

 > 4. /etc/init.d/raid2 attempts to initialise the other RAID
 > partitions but fails to do so because the /dev/md* entries do not
 > exist.

  I believe that if you use mdadm to assemble your arrays, and ensure it
 is passed the --auto parameter, it should work.

-- 
Tore Anderson


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

Re: Debconf or not debconf

[Tore Anderson]

* Julien LEMOINE

 >  I received a bug report on stunnel package from an user [1] that
 > complained about the fact that I didn't warning about the new
 > /etc/default/stunnel file introduced in package (thereis a note in
 > README.Debian and in changelog).
 >
 >  Since debconf is not really appreciated for this use, what is the
 > best solution ? Inform users with debconf or give them informations only
 > in changelog and README.Debian ?

  I'd say you stick it in debian/NEWS and leave it at that.

  If you're in doubt of whether or to use debconf for anything:  don't.
 Far too many packages has become far too loquacious of late, and the
 (mis)use of debconf seem to be misinterpreted as a carte blanche for
 doing so, unfortunately.

-- 
Tore Anderson

Re: [custom] Some issues for custom debian distributions

[Tore Anderson]

* Petter Reinholdtsen

 >  - Preconfigure the packages we install
 >
 >  Using two different approaches: (1) Load answers into the debconf
 >  database before the packages are installed using some home-make
 >  scripts, and (2) rewrite/replace configuration files using
 >  cfengine at the end of the installation if the package is unable
 >  to configure what we want using debconf.  I'm fairly satisfied
 >  with this solution, but am not sure if the method used to feed
 >  the debconf database is the best available.  I believe the best
 >  option would be to extend all the packages we use to make it
 >  possible to configure everything we need using debconf answers.

  God, No!  There's far too many Debconf questions being asked by
 various Debian packages already, IMNSHO.

  If something like this should be implemented, I'd like to see these
 questions only be asked at reconfigure time, or not asked at all.
 That way Skulelinux could preseed the Debconf database and get the
 package working the way you want, while I can install Debian without
 going nuts about all the questions I'm asked.

  However, the best solution I can think of right now would be to
 implement diversion support for conffiles in dpkg, so you could
 create a 'skolelinux-config' package which contained (or generated)
 configuration files attuned to Skulelinux, where necessary.

-- 
Tore Anderson

Re: [custom] Some issues for custom debian distributions

[Tore Anderson]

* Tore Anderson

 >> God, No!  There's far too many Debconf questions being asked by
 >> various Debian packages already, IMNSHO.

* Petter Reinholdtsen

 > There is no reason for you to get religious over this question.
 >
 > The nice thing about debconf is that there is no _need_ to present all
 > options as questions.  One can like ntp fetch the value from debconf
 > without asking the question first.  This will make it possible to
 > control the details of the package configuration without needing to
 > ask a lot of questions to the user while installing it.

  Which is why I suggested these "questions" should not be shown to the
 user at all, but merely exist as default values that could be
 over-ridden by custom distributions such as Skulelinux.

  However, doing so would remove the conffile status of many configuration
 files, which I firmly (perhaps not religious, though) believe is a bad
 thing.  If a configuration file *can* be a conffile, it should.

  I am sceptical to endorsing use of Debconf for packages that can be
 shipped with sane defaults (even though these might not suit Skulelinux
 well), as I've seen far too many packages which ask Debconf questions
 way out of proportion, carelessly ignore policy 11.7.3 (cf. the "manage
 with Debconf madness" thread), etc.  So even though it is possible to
 configure as much as possible through Debconf without actually asking
 too many questions and still caring for user modifications,  I seriously
 this is the way it actually will be done.

  Thus I would rather see Skulelinux divert away unfitting conffiles.

-- 
Tore Anderson

Bug#203862: ITP: beneath-a-steel-sky -- a science fiction adventure game

[Tore Anderson]

Package: wnpp
Version: unavailable; reported 2003-08-02
Severity: wishlist

* Package name: beneath-a-steel-sky
  Upstream Author : Revolution Software, Inc. 
* URL : http://www.scummvm.org/
* License : Probably not DFSG-free at the moment, hoping
to rectify that.
  Description : a science fiction adventure game

  A science-fiction thriller set in a bleak post-apocalyptic vision
 of the future, Beneath a Steel Sky revolves around "Union City",
 where selfishness, rivalry, and corruption by its citizens seems to
 be all too common, those who can afford it live underground, away
 from the pollution and social problems which are plaguing the city.

  You take on the role of Robert Foster, an outcast of sorts from the
 city since a boy who was raised in a remote environment outside of
 Union City simply termed "the gap".  Robert's mother took him away
 from Union City as a child on their way to "Hobart" but the helicopter
 crashed on its way, unfortunately Robert's mother dies, but he
 survives and is left to be raised by a local tribe from the gap.
 
  Years later, Union City security drops by and abducts Robert, killing
 his tribe in the process; upon reaching the city the helicopter taking
 him there crashes with him escaping, high upon a tower block in the
 middle of the city he sets out to discover the truth about his past,
 and to seek vengeance for the killing of his tribe.
 
  The game is playable with ScummVM 0.5.0, which I'll upload shortly.

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux void 2.6.0-test2 #1 Sun Jul 27 22:06:22 CEST 2003 i686
Locale: LANG=C, LC_CTYPE=no_NO.ISO-8859-1

Re: SURVEY: Is the GNU FDL a DFSG-free license?

[Tore Anderson]

* Branden Robinson

 > Part 1. DFSG-freeness of the GNU Free Documentation License 1.2
 >
 >   Please mark with an "X" the item that most closely approximates your
 >   opinion.  Mark only one.
 >
 >   [ X ]  The GNU Free Documentation License, version 1.2, as published
 >  by the Free Software Foundation, is not a license compatible
 >  with the Debian Free Software Guidelines.  Works under this
 >  license would require significant additional permission
 >  statements from the copyright holder(s) for a work under this
 >  license to be considered Free Software and thus eligible for
 >  inclusion in the Debian OS.
 >
 >   [   ]  The GNU Free Documentation License, version 1.2, as published
 >  by the Free Software Foundation, is a license compatible
 >  with the Debian Free Software Guidelines.  In general, works
 >  under this license would require no additional permission
 >  statements from the copyright holder(s) for a work under this
 >  license to be considered Free Software and thus eligible for
 >  inclusion in the Debian OS.
 >
 >   [   ]  The GNU Free Documentation License, version 1.2, as published
 >  by the Free Software Foundation, can be a license compatible
 >  with the Debian Free Software Guidelines, but only if certain
 >  restrictions stated in the license are not exercised by the
 >  copyright holder with respect to a given work.  Works under
 >  this license will have to be scrutinized on a case-by-case
 >  basis for us to determine whether the work can be be considered
 >  Free Software and thus eligible for inclusion in the Debian OS.
 >
 >   [   ]  None of the above statements approximates my opinion.
 >
 > Part 2. Status of Respondent
 >
 >   Please mark with an "X" the following item only if it is true.
 >
 >   [   ]  I am a Debian Developer as described in the Debian
 >  Constitution as of the date on this survey.

-- 
Tore Anderson

Re: tmda: Challenge-response is fundamentally broken

[Tore Anderson]

severity 207300 grave
quit

* Karsten M. Self

 > Briefly:  challenge-response (C-R) spam fighting systems are
 > fundamentally broken by design.

 > I am recommending that TMDA be dropped from Debian.

* Adam McKenna

 > I will not respond to this bug other than to state that I don't believe it
 > meets the requirements for filing a grave bug, and I will not remove TMDA 
 > from Debian just because you and a few others don't like it, or don't 
 > like this particular class of software.
 >
 > I do not intend to play BTS games here; if you change the severity back to 
 > grave, or to any other RC state, I will consider it to be abuse of the BTS 
 > and report your actions to the BTS maintainer, and your ability to use the
 > BTS will be taken away.
 >
 > Before you respond to this I suggest you re-read Debian's Social Contract 
 > and the section of the Maintainer's Guide pertinent to bug severities.

  You just spammed me with one of your "challenges", Adam.  I do not
 think I have ever before sent you an e-mail, and I am 100% certain I
 have never sent you any trojan horse designed to break Microsoft
 Outlook.  Upon inspection of the headers, I see you did so even after
 the message scored >10 in your SpamAssassin filter.  Surely you are
 aware of the fact that such junk mail tend to have forged From:
 headers?

  How many other innocent third parties have you spammed through the use
 of this broken program?  How many of these are Debian users, do you
 think?

  How many Debian users have installed this package, and has as a result
 begun sending junk mail to innocent third parties, without even being
 aware of it?

  Think about it for a while, then you go read up on the Social contract,
 more specifically the clause stating what our priorities are.

  This program is no better than the brain-damaged content filters that
 has plauged debian-devel and countless mailboxes with the idiotic
 "you have attempted to send [EMAIL PROTECTED] a virus!"-allegations.
 Although it may relieve the junk mail flow to your and other
 TMDA/content filter users' mailboxes, it does nothing but add to the
 problem for other e-mail users around the globe.

  In fact, I find the use of this program about as disgusting as the
 sending of the original unsolicited message -- in both cases you send
 other e-mail users junk mail for your own personal benefit.

  Therefore I join the original submitter in the recommendation that
 TMDA should be removed from Debian, or failing that, it should carry
 a prominent notice in the description that it will send junk mail to
 random third parties and will thus not remove the junk mail problem,
 but simply transfer it (very rudely, I might add) to someone else.

  I'm Cc'ing debian-devel for comments, as you do not seem to be
 interested in having any sensible discussion regarding this issue,
 and amazingly enough instead go on threatening the submitter that you
 will go to the BTS guys and have him blacklisted from the BTS.  Not
 very polite to one of our users, I'd say.  Feel free to attempt having
 me blacklisted, though.
  
-- 
Tore Anderson

Re: tmda: Challenge-response is fundamentally broken

[Tore Anderson]

[ Please do not send me CC's, as I have not explicitly asked for them. ]

* Stephen Stafford

 > Sorry, but I do NOT see how this is a grave bug.  It's wishlist (at best).
 >
 > YOU might not agree that C-R systems are good (personally I detest them),
 > but that does NOT mean that we shouldn't release one.  If the package is in
 > good shape and functions as advertised, then it IS fit for release.  

  I do not have anything against C-R systems per se, and I do not care if
 others use them, or if we distribute them.  What I -do- have a problem
 with is that the C-R system in question ignores the fact that SMTP
 headers are trivially (and regulary) forged.  I believe this is deliberate,
 and that TMDA does not attempt to verify that the recipient of the
 challenge truly was the sender of the original e-mail.  (If it did, I
 would have no problem with it at all.)

  Therefore third-party users, who had nothing to do with the original
 sending of the mail, will receive unsolicited e-mail, and that even
 from a program which is designed to stop such junk.

 > Hey, how about if I decide that emacs is a huge bloaded piece of shit?
 > Does that mean we shouldn't release it?
 >
 > Or if I decide that CUPS is rubbish and lprng is the One True Printer
 > Daemon?
 >
 > Or that Gnome is a steaming pimple on the arse of desktop managers?

  None of these are comparable - that one user installs Gnome on his
 system does not hurt you in any way.  You can simply ignore it and
 go on with your life.  You do not even have to know -- Gnome will not
 send you unsolicited junk mail, regardless of it being a 'steaming
 pimple' or no.

-- 
Tore Anderson

Re: Bug#207300: tmda: Challenge-response is fundamentally broken

[Tore Anderson]

[ Please do not send me CC's, as I have not explicitly asked for them. ]

* Tore Anderson

 >>   How many other innocent third parties have you spammed through the use
 >>  of this broken program?  How many of these are Debian users, do you
 >>  think?

* Peter Makholm

 > I think we could just as well remove postfix[0] on this account. I have
 > received a lot of so called bounces because some silly postfix
 > installation believes that I have send mail to some non-existant
 > account.

  I fully agree, and I would not hesitate to submit a RC bug on the
 Postfix (or any other MTA) package, if it by default came with the
 broken configuration you speak of.

  However, a quick test shows that this is not the case (as Postfix
 appears to reject the SMTP RCPT command for non-existent accounts),
 so I fail to see how it is relevant.

-- 
Tore Anderson

Re: tmda: Challenge-response is fundamentally broken

[Tore Anderson]

* Mark Brown

 > You do realise that all parts of SMTP are generally completely
 > unauthenticated and can be trivially forged?

  Yes.  It's indeed very sad that it is so.

  However, my main issue still remains -- the difference (for the user)
 between

 «I'm installing this package and accept that my correspondents
 must jump through a few hoops to get in touch with me»

  and

 «I'm installing this package and accept that my correspondends must
 jump through a few hoops to get in touch with me -and- that it is
 overwhelmingly likely that I will send unsolicited junk mail to third
 parties so that they will have to deal with the problem instead of
 myself»

  is, in my opinion, vast.

  If TMDA warned the user that it'll take the latter approach, I'd
 probably be happy with that.   (It would have been even better if
 there were some tutorial included, that could give a crash course
 in how to make TMDA -not- send challenges to e-mail SpamAssassin and/or
 ClamAV classified as junk mail.)

-- 
Tore Anderson

Re: Bug#207300: tmda: Challenge-response is fundamentally broken

[Tore Anderson]

* Adam McKenna

 > #0, #1, #2 and #11 are basically opinion and rhetoric.

  Well.  Let's take a look at what Karsten had to say about point #2,
 "Misplaced burden":

[...] «C-R may place the burden on third parties either inadvertently
(via spoofed sender spam or virus mail), or deliberately (see Joe-job
below).»  [...]

  You dismiss this as "basically opinion and rhetoric".  Yet, I see a
 unsolicited junk mail from you, yes - *you* Adam, in my mailbox.  I'd
 be very interested in hearing how that could've been a result of
 'opinion and rhetoric', so please, let me know.

  Earlier, you've stated that your time is precious.  Well, so is mine.
 How dare you assume that the time I spent reviewing *your* callenge mail
 and deciding it was junk is less precious than the time you (could have)
 spent reviewing the mail that spurred the challenge in the first place?

  I admit my first email was written in hot blood, but if TMDA actually
 endorses this selfish behaviour, I still feel it is something that do
 not belong in Debian.  On the other hand, if the junk mail in my
 inbox was a result of a misconfiguration on your part, then I'm
 sorry for yelling so loud.  Errare humanum est.

-- 
Tore Anderson

"non-free" installer packages in our supposedly Free sections.

[Tore Anderson]

  I've noticed there's quite a few almost-empty packages lurking in
 the archive, whose sole purpose seems to be to download non-free
 software and install it on a users' systems.

  I don't like the fact that these seem to be (randomly) scattered
 over main and contrib.  Although the installer packages themselves
 certainly are Free, I feel the social contract is being violated
 when I have main and contrib in my sources.list file, but after
 having completed the installation of a package from these sections,
 non-free software is installed on my system.

  Here's a quick list of suspected packages:

vtkdata-installer   optional
acl-installer   contrib/devel
acl-pro-installer   contrib/devel
atokx   contrib/utils
daemontools-installer   contrib/misc
djbdns-installercontrib/net
f-prot-installercontrib/utils
flashplugin-nonfree optional
hyperspec   optional
ibm-jdk1.1-installercontrib/devel
int-fiction-installer   contrib/games
lw-per-installercontrib/devel
lw-pro-installercontrib/devel
msttcorefonts   contrib/graphics
nvidia-kernel-src   contrib/x11
nvidia-glx-src  contrib/x11
qmailanalog-installer   contrib/mail
quake2-data contrib/games
roxen-ssl   contrib/web
roxen2-ssl  contrib/web
sdic-edict  contrib/text
sdic-gene95 contrib/text
setiathome  contrib/misc
realplayer  net

  I've not verified all of these being such installer packages for
 non-free software, nor do I claim it to be complete.  Just to give
 you a rough idea.  Also, they're of different nature -- some install
 the non-free software from their post-installation scripts, while
 others install a script in /usr/sbin/ which will do the installation
 of the non-free software when run.

  I'd like to submit bugs on these, asking them to move to non-free.
 So consider this email an invitation to discussion before a mass-bug
 filing.

  If the list agrees that bugs are warranted, which severity should I
 use?  In my opinion it's a violation of the social contract and thus
 serious, but I've been recently told I should probably not use my
 own opinion as a justification for using the RC levels, so mayhaps
 wishlist would be better?

-- 
Tore Anderson

Re: "non-free" installer packages in our supposedly Free sections.

[Tore Anderson]

* Ola Lundqvist

 > Contrib is a perfectly ok place for installers.

  I disagree.  If I have contrib in my sources.list file, and try
 to install a package from there, I expect only Free software to
 be installed on my system.  That means I should get either:

1) A fully-functional package, which might have been built
   with non-free tools, for instance OpenOffice, or
2) A package which does require me to install additional
   software to be of use, for instance UAE, or
3) A 'could not be installed' error from apt-get, which would
   suggest that the package placed a strict Depends on a
   package outside of main or contrib.

  In none of these cases I have gotten non-free software on my
 system.  In the case of the installer packages, especially the
 ones which does the installation from their post-installation
 scripts, I get non-free software on my system from installing
 packages from the sections that should be DFSG-Free software
 only.

 >> flashplugin-nonfree optional
 >
 > This is in contrib!
 >
 >> hyperspec   optional
 >
 > Also in contrib!
 >
 >> realplayer  net
 >
 > I can not find this in the archives.

  Quite right, I've messed up these.  Thanks for correcting me.

-- 
Tore Anderson

Re: "non-free" installer packages in our supposedly Free sections.

[Tore Anderson]

* Tore Anderson

 >>   Although the installer packages themselves certainly are Free,
 >>  I feel the social contract is being violated when I have main and
 >>  contrib in my sources.list file, but after having completed the
 >>  installation of a package from these sections, non-free software
 >>  is installed on my system.

* Anthony DeRobertis

 > Clearly, we have not violated the Social Contract: Contrib does not,
 > per the social contract, need to follow the DFSG (policy imposes
 > greater requirements, which is fine).

  Oh, er, yes.  Policy is indeed what I was thinking about.

 > I think it is reasonable to require that installer packages inform the
 > user they are about to install non-free software and give the user an
 > opportunity to review the license of that software before proceeding,
 > though.

  At the very least.

  Well, anyway I see that most people seem to disagree that it's a dubious
 use of contrib, so I'll probably just forget about submitting any bugs on
 the installer packages.

-- 
Tore Anderson

Re: Mass-filing bugs based on piuparts?

[Tore Anderson]

* Petter Reinholdtsen

> Can you do upgrade testing as well.  It would be great to know what
> packages fail to upgrade properly from woody to sarge, and from sarge
> to etch.

  Indeed.  And if you can, Lars, please include a test to see which
 packages which modify their own conffiles so the user is presented with
 a dpkg conffile changed dialogue during the upgrade.  It would also be
 very interesting to see how many packages leave behind orphaned
 conffiles after purging a newer version which does not contain the
 files anymore.

Regards
-- 
Tore Anderson


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

Bug#456640: RFA: munin -- network-wide graphing framework (grapher/gatherer)

[Tore Anderson]

Package: wnpp
Severity: normal

I don't have time to maintain the Munin packages any more (and haven't
for quite a while either, truth to be told).  So there's a bunch of bugs
reports that hasn't yet been looked at, and although the packages
themselves are in quite good condition there's lots of reports of
upstream bugs that needs to be triaged and fixed/forwarded.

The packages are currently maintained in the upstream SVN repository,
and the new maintainer(s) will be given write access there.  The 1.2
stable branch is de-facto maintained by the Debian maintainer at the
moment, so you'll be free (or even encouraged) to make new upstream
releases instead of carrying patches in the Debian diff.

The new major upstream release is still under developement, but it's
still some months away I believe.

The package description is:
 Munin is a highly flexible and powerful solution used to create graphs of
 virtually everything imaginable throughout your network, while still
 maintaining a rattling ease of installation and configuration.
 .
 This package contains the grapher/gatherer. You will only need one instance of
 it in your network. It will periodically poll all the nodes in your network
 it's aware of for data, which it in turn will use to create graphs and HTML
 pages, suitable for viewing with your graphical web browser of choice.
 .
 It is also able to alert you if any value is outside of a preset boundary,
 useful if you want to be alerted if a filesystem is about to grow full, for
 instance.  You can do this by making Munin run an arbitrary command when you
 need to be alert it, or make use of the intrinsic Nagios support.
 .
 Munin is written in Perl, and relies heavily on Tobi Oetiker's excellent
 RRDtool. To see a real example of Munin in action, you can follow a link
 from  to a live installation.

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-5-k7
Locale: LANG=nn_NO.UTF-8, LC_CTYPE=nn_NO.UTF-8 (charmap=UTF-8)



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

Re: nethack popularity contest - number_pad?

[Tore Anderson]

* Joshua Kwan

 > Searching for a general consensus here...
 >
 > These days Debian's nethack packages contain default nethackrcs which
 > enable number_pad style controls (instead of hjkl keys) by default, due
 > to a bug filed on the packages a long time ago. Of course, there are some
 > who like it and some who don't. It's too trivial to ask a debconf question
 > about it upon install so it boils down to a popularity contest.
 > 
 > Which is better? I like the default keys because you learn how to use
 > nvi very efficiently knowing the hjkl-style keys :) I'm searching for as
 > many opinions as possible so please speak up!

  I'd like it to be hjkl, for several reasons.  For once, it's the
 default upstream behaviour, and I see no compelling reason to deviate
 from that.  Apart from that, I personally like the normal way better,
 because my laptop doesn't even have a number pad, and it's much easier
 to do other commands, such as check the armour status with "[", when
 my right hand is normally resting over the hjkl keys, as opposed to
 the number pad.

-- 
Tore Anderson

Re: exim4-config and exim4-base installed on systems with non-exim-MTA

[Tore Anderson]

* Marc Haber

 > The way -config does the configuration is something that is questioned
 > by a lot of people. Most conservative eximists hate the configuration
 > being split out in several files,

  Absolutely, this is a slight convenience for the packagers which causes
 a major inconvenience to the users.  Well, in my opinion anyway.

  The Apache 2 packages does much of the same, sadly.

 > and having the separate -config package allows people to throw away
 > the entire -config magic.

  How?  (Short of creating a empty replacement -config package.)

-- 
Tore Anderson

Re: exim4-config and exim4-base installed on systems with non-exim-MTA

[Tore Anderson]

* Marc Haber

 > Well, I am only paid to work on the exim4 package if my employer gets
 > to use the package as well. Since we don't want debconf questions to
 > pop up during installation and we found the pre-fabricated -config too
 > inflexible for our needs, -config needs to be split out.

  So I take it you roll your own exim4-config-marchaber or something
 which provides exim4-config?

  If so, that does in no way explain the reasoning behind splitting
 up the default configuration file in a million tiny files, nor why
 simply creating a exim4-base-marchaber with the customized scheme
 isn't adequate for you.

  I'm glad to hear you're paid to work on Debian, as that certainly
 makes it even more fun.  :)

* Marc Haber 

 > and having the separate -config package allows people to throw away
 > the entire -config magic.

* Tore Anderson

 >  How?  (Short of creating a empty replacement -config package.)

* Marc Haber

 > The source package holds infrastructure for three possibilities:
 >
 > - A script is included that splits out -config source from the source
 >   package, allowing the debconf stuff to be modified independently
 > - A script is included that creates a debconf-less -config source
 >   package that uses split config.
 > - A script is included that creates a -config source package with 
 >   monolithic config.

  In other words, «people» must be familiar with the process of building
 Debian packages, and must be willing to spend time learning this Debian-
 specific infrastructure to be able to manage their Exim installation in
 a generic and non-Debian-specific manner.  I don't really see that as
 being advantageous to a more than a select few users.

  Furthermore, I still don't see the reasoning behind and/or advantages
 incurred by splitting off the exim4-config package and splitting the
 config file into all those tiny conf.d-snippets.

  I would suggest something like this:

- A exim4-base package containing the default debconf scripts,
  which installs a (monolithic) configuration file.
- The source package could then, to cater for power users such as
  yourself, contain scripts to
  1) split out the -base source from the source package, allowing
 the debconf stuff to be modified independently, and
  2) create a debconf-less -base source package that uses
 monolithic config, and possibly
  3) create a debconf-less -base source package that uses
 split config, and possibly
  4) create a -base source package that uses split config.
- exim4-daemon-whatever declares a dependency on
  exim4-base-custom | exim4-base, or exim4-base-custom declares a
  provides for exim4-base.
- exim4-daemon-whatever declares a provides for exim4-daemon, and
  exim4-base[-custom] declares a depends on this virtual package.

  What point have I missed that makes this inferior to the way the Exim
 packages are currently structured?

  As an added bonus, implementing this will also make the problem you
 initially inquired about go away.

-- 
Tore Anderson

Re: exim4-config and exim4-base installed on systems with non-exim-MTA

[Tore Anderson]

* Marc Haber

 > Splitting up the config file in small files was necessary to do
 > debconf support, which is a Debian requirement.

  Debconf support is now required?  I'm flabbergasted.  Could you
 please point me to this section of our policy?  I certainly cannot
 find it.

* Tore Anderson

 >- A exim4-base package containing the default debconf scripts,
 >  which installs a (monolithic) configuration file.

* Marc Haber

 > Please state how you intend to fulfill policy with that approach. Give
 > code examples.

  An existing code example from the top of my head would be the current
 xserver-xfree86 package's config and postinst scripts.  Another package
 which does much of the same thing, albeit in quite a different manner,
 is proftpd.  I'm sure there's many more.

  Would you and Andreas seriously consider modifying the Exim packages
 to the layout I suggested in my former post?  If so, I would be happy
 to spend some time developing a patch for this purpose.

-- 
Tore Anderson

Re: exim4-config and exim4-base installed on systems with non-exim-MTA

[Tore Anderson]

* Marc Haber

 > Splitting up the config file in small files was necessary to do
 > debconf support, which is a Debian requirement.

* Tore Anderson
 
 >   Debconf support is now required?  I'm flabbergasted.

* Joey Hess

 > debconf support is a requirement if you want to be supported
 > (reconfigured) by base-config, which is a requirement for our default
 > MTA.

  Quite.  However, as far as I know, base-config does not require the
 resulting configuration to be lots of tiny files as opposed to a single
 file, nor does it require the configuration to be split into a package
 of its own.  Policy does not require any of this either.

  These two issues are my main griefs with the Exim packages.  The
 existing debconf scripts are just fine;  I certainly do not wish to see
 them replaced with something akin to the old eximconfig script.

-- 
Tore Anderson

Re: exim4-config and exim4-base installed on systems with non-exim-MTA

[Tore Anderson]

* Tore Anderson

 > * Andreas Metzler
 >
 >  >  Would you and Andreas seriously consider modifying the Exim packages
 >  > to the layout I suggested in my former post?  If so, I would be happy
 >  > to spend some time developing a patch for this purpose.

  Apologies for this misattribution, I was of course the author or the
 above paragraph, not Andreas.

-- 
Tore Anderson

Re: exim4-config and exim4-base installed on systems with non-exim-MTA

[Tore Anderson]

* Andreas Metzler

 >  Would you and Andreas seriously consider modifying the Exim packages
 > to the layout I suggested in my former post?  If so, I would be happy
 > to spend some time developing a patch for this purpose.

* Andreas Metzler

 > No, I am sorry (and thanks for the offer). You effectively proposed
 > repacking from scratch, which requires amounts of work and testing I
 > am not willing to invest.

  I suspected as much.  Likewise I am not willing to do that work if the
 patch was stillborn irregardless of its quality.

* Andreas Metzler

 > If you think conf.d sucks like hell (where did I get this idea from? ;-)

  No Shit, Sherlock.  :)

 > try providing a patch for exim4-config-sane, [...]

  I thought about it for a while, but I don't really think that'd be a
 good idea.  Although I'd certainly use such a package myself, I believe
 it's not worth bloating the archive with yet another config package.
 Afterall, I would rather see the one that's already there removed and
 its functionality merged into exim4-base[0].

 > [2] Or simply do without making separate packages, making conf.d
 > yes/no a medium debconf-question.

  Low.  But other than that, I think this is an excellent idea,
 see below.

* Andreas Metzler (in <[EMAIL PROTECTED]>)

 > All they have to do is to install their configuration as
 > /etc/exim4/exim4.conf.

  I'm truly glad this is possible, and makes the conf.d stuff much
 more bearable.  However, it is still subpar, in my opinion, for if
 the user wants to do this, and implement minor modifications to
 the default config, he is totally on his own and won't get
 suggestions and fixes from you (as the maintainer) whenever the
 default configuration file changes.

  I got this idea that certainly will make me happy and which I
 think you might be inclided to consider for inclusion, though:

  We add a new option in update-exim4.conf.conf (and perhaps with
 a matching question in the debconf scripts, too) which, when
 enabled, would modify update-exim4.conf's behaviour to something
 like the following:

* Enables --keepcomments
* Suppresses the "generated dynamically" warning
* After the concatination, it installs /v/l/e/config.autogenerated
  into /e/e/exim4.conf, with the appropriate checks for user
  modifications (ucf could be used for this)

  (Alternatively, replace /v/l/e/c.a with $(tempfile) and set
   --output to the latter.)

  ..and I would be able to modify /etc/exim4/exim4.conf as I'm used to,
 and still have the full power of your debconf scripts at my disposal,
 in addition to being automatically notified (and given the opportunity
 to attempt a merge) of changes and (security) fixes to the default
 configuration.

  conf.d could still be the default.  No, wait, it -must- be the
 default if ucf is to be used.

  What do you think?

 [0] I might be dense, but I still don't see why it was split out from
 exim4-base in the first place.

-- 
Tore Anderson

Re: exim4-config and exim4-base installed on systems with non-exim-MTA

[Tore Anderson]

* Tollef Fog Heen

 > It also makes it possible for packages such as clamav, spamassassin
 > and mailman to seamlessly drop in support in a fairly clean way.

  Which (possibly) makes the configuration break in a whole new way, if
 you decide to actually change the logic of stuff inside conf.d/.

  Suddenly you have a new spamassassin/clamav/whatever router inside
 the concatinated configuration that makes Exim route your email
 somewhere it shouldn't.

  As far as I know there is no way of telling the Exim packages "do not
 modify my customized configuration without asking me" as usually is the
 default elsewhere in Debian (and "configuration" here is of course the
 complete configuration as used by Exim, not the individual files in
 conf.d/), short of ignoring the Debian-provided default configuration
 entirely, by using /e/e/exim4.conf or setting conftype to none.

* Tore Anderson

 >   The Apache 2 packages does much of the same, sadly.

* Tollef Fog Heen

 > For the same reason, mostly.

  The good thing about the Apache 2 packages is that my resulting
 configuration won't be changed merely by downloading a new package
 (for it will put its snippet in the -available directories).  They
 don't split the configuration suff out from the -common/-base package,
 either.

 The -enabled directories/symlink farms and /etc/vhosts/* stuff is
 what's seems a tad strange and excessively Debian-specific to me;  I
 have preferred if the reccomended way for packages was to drop their
 example httpd.conf snippets in a single, standardized directory, and
 then the standard way of enabling these would be to simply Include 
 them from the main httpd.conf.  KISS and all that, y'know.

  But that's anyway just aesthetics to me.  Just ignore my ranting
 until I submit patches or constructive suggestions.  (I certainly
 would, if I were you.  :)

-- 
Tore Anderson

Re: RFC: OpenLDAP and TLS/SSL

[Tore Anderson]

Torsten Landschoff <[EMAIL PROTECTED]> writes:

> Today I was convinced by Stephen Frost that I can just enable SSL support
> in the OpenLDAP packages I maintain. No problem so far, but:
> 
> - libldap2 is Priority: important
> - this change will make it depend on libssl0.9.6
> - libssl0.9.6 is Priority: standard
> 
> So - what should I do to handle this? Can the priority of libssl0.9.6 be
> easily changed? Or should I rather provide libldap2{,-ssl}? Technically
> it would not be a big deal since the interface of libldap2 does not
> change if you enable ssl. Also I wonder if a slapd package without 
> ssl would be in order. After all there are still people using Debian
> who are not allowed to import all that crypto stuff from the US.

As far as I know, exim is the only package with priority: important that
depend on libldap2. Howevery, the basic configuration generated by exim's
postinst doesn't use the LDAP functionality (AFAIK). So, I think exim
should be fixed so that it doesn't depend on libldap2 anymore.

Then lildap2 wouldn't need to be important anymore - your problem
would be solved, and base would shrink. :)

We could instead have an exim-bloated package with full
LDAP/MySQL/PostgreSQL/SSL functionality as priority extra.

-- 
Tore Anderson

Re: Proposed handling of generated configuration files (Re: stop the "manage with debconf" madness)

[Tore Anderson]

* Matt Zimmerman

 > There was a more recent discussion about the same idea.  A summary of the
 > goals:
 >
 > - Don't try to parse every program's configuration file format
 >
 > - Notice that a non-conffile, autogenerated configuration file has been
 >   modified by the user, and don't lose their changes
 >
 > - Provide 3-way merge functionality to incorporate changes without losing
 >   modifications in the common case (I hear this is coming for conffiles as
 >   well)
 >
 > - Use debconf for prompting
 >
 > - Have all packages do this using a standard toolset, so that all prompting
 >   is consistent and well-translated, and certain defaults can be set
 >   globally (see the threads below for more discussion about this)

  Hey, you just described how how ucf can be used.  Here's a crash course on
 how to use it in package "fnord"'s maintainer scripts:

  fnord.config:
db_input fnord/something_that_has_no_good_default_answer
db_go

  fnord.postinst:
db_get fnord/something_that_has_no_good_default_answer
cat << _eof > /usr/share/fnord/managed-conffiles/fnord.cf
# configuration file for fnord.

setting_with_acceptable_default1 = quux
setting_with_acceptable_default2 = zoot

# this variable hasn't got any good default.
variable_with_no_good_default = $RET
_eof
db_stop
ucf /usr/share/fnord/managed-conffiles/fnord.cf /etc/fnord.cf < /dev/tty

  Lo and behold!  We've just achieved your goals, using tools already in
 the archive!

  If /usr/share/fnord/managed-conffiles/fnord.cf changes, because of
 a dpkg-reconfigure where the user gives another answer, or a upgrade
 where the template has been changed by the maintainer (or a combination),
 and the user has changed /etc/fnord.cf, ucf will pop up a question which
 closely resembles dpkg's counterpart:

Configuration file `/void/home/tore/ucftest/cf'
 ==> File on system created by you or by a script.
 ==> File also in package provided by package maintainer.
   What would you like to do about it ?  Your options are:
Y or I  : install the package maintainer's version
N or O  : keep your currently-installed version
  D : show the differences between the versions
(...)

  Local modification will be kept, if the user wants them to be!  So
 there's no reason anyone to supply configuration files with comments
 such as "## don't edit this file; it belongs to the maintainer scrips!",
 even if the file is dynamically created.  The user doesn't need to know
 that whether or not not a conffile or a ucf-handled configuration file.

  But wait!  There's more! -- if you supply the --three-way option to ucf
 in your postinst, the rest of ucf's question looks like this:

3 or T  : show a thre way difference between current, older,
  and new versions of the file
  M     : Do a 3 way merge between current, older,
  and new versions of the file [Very Experimental]

  Exactly what you wanted, yes?

-- 
Tore Anderson

Re: Proposed handling of generated configuration files (Re: stop the "manage with debconf" madness)

[Tore Anderson]

* Matt Zimmerman

 > Did you read my sample configuration scenario (xserver-xfree86),
 > or the threads that I referenced?  They explain in more detail.

  I did, and I can't see why ucf can't be done for this purpose,
 too;

 > As I said, I am suggesting we mimick the conffile mechanism.  conffiles
 > are not parsed, but their modification is noticed.  My proposed system
 > would not prevent the user from using the menu-driven configuration; it
 > would simple offer them a choice about whether to generate a new
 > configuration using the dialogs, or to preserve their existing configuration.
 > This choice would only be necessary if the file had been modified by hand.

  As far as I know, ucf is created exactly for this purpose; to mimic dpkg's
 conffile handing.  I assume you want to know if the configuration file is
 unmodified prior to asking all the debconf questions, and making use of such a
 command in the ucf package would unfortunately require a pre-dependency.
 However, such a test would be very simple (basically just checking if the
 md5sum of the configuration file matches the one recorded in ucf's hashfile),
 so it could easily be included in the config script.

  After you've conclusided that you can overwrite the configuration
 file (possibly by asking the user if the not modified check was
 negative), you just write the configuration file outside of /etc
 and call ucf on it.  Possibly with UCF_FORCE_CONFNEW if you've
 asked explicit permission.

  What am I missing?

-- 
Tore Anderson

Re: Proposed handling of generated configuration files (Re: stop the "manage with debconf" madness)

[Tore Anderson]

* Matt Zimmerman

 > As was explained in detail, in order to do anything useful with that
 > information, it is necessary to be able to show the user the proposed
 > changes to the configuration file.  It is completely unhelpful to say:
 >
 > "You have modified this configuration file, and it has also been updated
 > by the package maintainer.  Do you want to replace it with the version
 > provided by the package maintainer?"
 >
 > Without showing the user the new version.

  Of course, this question will be shown in the postinst, if the generated
 file differs from the previously generated one and the user has modified
 the one in /etc.

  I was more thinking along the lines of a question such as:

You are upgrading from version 1.23 of package foo.  Starting from this
   version, the configuration file layout has changed drastically, and your
   old one cannot be used.  May I generate a new file based on your previous
   answers and autodetection tools, overwrite your old configuration file,
   and save the old one to /etc/foorc.dpkg-old?

  but I realise that's probably not what you had in mind.

* Tore Anderson

 >>   What am I missing?

* Matt Zimmerman

 > Generating configuration files using non-Essential tools (including tools
 > contained in the package being configured), the preference to ask all
 > questions at preconfiguration time, and the necessity of displaying
 > proposed changes before asking the user to confirm them.

  I see your problem when you insist on asking on asking all questions at
 the configure stage -- personally, I don't think delaying the actual
 generating of the configuration file (and asking the question about
 overwriting the old file) to the postinst stage is *that* bad.

  All the other questions can be asked at configure phase, though.

-- 
Tore Anderson

Re: Proposed handling of generated configuration files (Re: stop the "manage with debconf" madness)

[Tore Anderson]

* Tore Anderson

 >>  I see your problem when you insist on asking on asking all questions
 >>  at the configure stage -- personally, I don't think delaying the actual
 >>  generating of the configuration file (and asking the question about
 >>  overwriting the old file) to the postinst stage is *that* bad.

* Matt Zimmerman

 > This is the sort of input that I was soliciting.  Personally, I think that
 > preconfiguration is very important, since it _greatly_ simplifies initial
 > installation and upgrades (where a large number of questions are asked) and
 > allows the rest of the installation to proceed unattended in the absence of
 > errors.

  I fully agree that as many questions as possible should be asked before
 unpacking the package.  And I also agree it would better if the "replace
 the configuration file" questions also came at that point of the upgrade,
 but unfortunately, that isn't the status quo.

  dpkg asks for permission to overwrite conffiles *after* having unpacked
 the package in question -- and therefore you cannot dist-upgrade 300
 packages, answer all questions, then take lunch and expect it to be
 finished when you're back.  The upgrade will most likely stop after
 unpacking a package with a new conffile.

  As you probably know, preconfiguration is handled by apt-extracttemplates,
 while the conffile mechanism is dpkg's turf.  Therefore it would require
 major changes to apt/dpkg to make those conffile questions appear at the
 same time as all the other questions asked by apt-extracttemplates.  I
 don't see that change happening in the near future.

  So, where does that leave us?  dpkg's "Can I overwrite this conffile?"
 questions are asked some time between the package is unpacked and the
 postinst is started.  ucf's equivalent questions is asked in the
 postinst, which of course is slightly later in the process, but I
 highly doubt that a regular user would notice any difference.

  Hence, as ucf isn't especially worse than dpkg itself when it comes
 to interrupting upgrades after apt-extracttemplates has preconfigured
 packages, I don't think ucf's prompt in the postinst is that much of
 a problem.  YMMV.

-- 
Tore Anderson

Re: Bug#189370: acknowledged by developer (irrelevant)

[Tore Anderson]

* Atsuhito Kohda

> I don't know how you create texmf.cnf but it would be enough
> if you create it in Debian and distribute it to other machines

  Jesus.  You still haven't got the point.  Repeat after me:
 "I am *NOT* permitted to make that decision on behalf of the user."

 > On the other hands, in Debian which is an association of 
 > volunteers, a developer can package any DFSG-free TeX components 
 > or DFSG-free extra fonts packages freely so we need an infra-structure
 > which provides dynamic texmf.cnf etc. so that every such extra 
 > packages can modify texmf.cnf in order that they could be installed and 
 > work without problem.  I believe this is our (tetex-mantainers') duty.

  I'm not a TeX user, but why can't you have a /etc/texmf.d/ directory
 where the other packages can drop their texmf.cnf fragments (like
 logrotate has, for instance), which is then included from the static
 texmf.cnf?

-- 
Tore Anderson