headers
Marc MERLIN | 1 Mar 2005 06:55

Re: 4.50 in unstable missing dlopen, possible error in EDITME patch?

On Mon, Feb 28, 2005 at 10:32:00PM +0100, Marc Haber wrote:
> Hi,
> 
> On Mon, Feb 28, 2005 at 08:10:42PM +0100, Andreas Metzler wrote:
> > The cause is this one:
> > $ grep DLOPEN_LOCAL debian/EDITME.exim*
> > debian/EDITME.exim4-light.diff:-DLOPEN_LOCAL_SCAN=yes
> > 
> > You are actively disabling dlopen in the EDITME patch after /enabling/
> > it in the dlopen patch. Get rid of this hunk in the EDITME patch and
> > we're set again. ;-)
> 
> So the dlopen patch was even enabled in the light daemon?

I've never used the light daemon, but IMO, it should be.
The idea is to allow to link code into exim core, but allowing that doesn't
make your exim binary any heavier.
In other words, exim-light should have this enabled IMO, it doesn't require
any more libs or dependencies if you turn it on, and only adds a few hundred
bytes to the binary I'm pretty sure

Marc
--

-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems & security ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/   |   Finger marc_f <at> merlins.org for PGP key
Permalink | Reply | 0 comments |
headers
Marc Haber | 1 Mar 2005 22:54
Picon

Why do we restart the daemon in -configs .config script?

Hi,

#297607 is caused by the restart of the daemon done in the .config. A
quick grep shows that we're the only package on my _big_ system that
uses invoke-rc.d in a .config script.

I have been told that dpkg-reconfigure also invokes postinst.

May I ask whether there is a reason for not doing the restart in
postinst?

Greetings
Marc

--

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835
Permalink | Reply | 8 comments |
headers
Marc Haber | 2 Mar 2005 09:08
Picon

Re: Why do we restart the daemon in -configs .config script?

On Tue, Mar 01, 2005 at 10:54:08PM +0100, Marc Haber wrote:
> #297607 is caused by the restart of the daemon done in the .config.

And caused by 10_daemon_close_fd not applying to 4.50 and dpatch not
complaining about this. Fixed in incoming.

Greetings
Marc

--

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835
Permalink | Reply | 6 comments |
headers
Andreas Metzler | 1 Mar 2005 20:46

Re: Build-Depends-Indep instead of Build-Depends.

On 2005-02-28 Marc Haber <mh+pkg-exim4-devel <at> zugschlus.de> wrote:
> On Mon, Feb 28, 2005 at 07:43:58PM +0100, Andreas Metzler wrote:
> > On 27 Feb 2005 Marc Haber wrote:
> > > Modified: eximdoc4/trunk/debian/changelog
> > [...]
> > >  * use Build-Depends-Indep instead of Build-Depends.
> > Please do not do that. Build-Depends-Indep should contain a list of
> > packages that are needed for dpkg-buildpackage -b _additionally_ to
> > the ones listed in Build-Depends (which lists the ones that are needed
> > for dpkg-buildpackage -B).

> Lintian complains about Build-Depends being used for an architecture
> independent package,

Yes, that complain is broken.

> and I have seen a fair share of packages with
> identical Build-Depends and Build-Depends-Indep.

Most of them probably being triggered by lintian ... :-(

> Which part of policy does support your thesis?

Policy is not correct in that respect. The behavior I decribed is the
one the buildds and dpkg-buildpackage enforce.
            cu andreas
--

-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"
(Continue reading)

Permalink | Reply | 7 comments |
headers
Andreas Metzler | 1 Mar 2005 20:42

Re: 4.50 in unstable missing dlopen, possible error in EDITME patch?

On 2005-02-28 Marc Haber <mh+pkg-exim4-devel <at> zugschlus.de> wrote:
[...]
> So the dlopen patch was even enabled in the light daemon?

Yes, that is correct.
         cu andreas
--

-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"
                                           http://downhill.aus.cc/
Permalink | Reply | 0 comments |
headers
Andreas Metzler | 5 Mar 2005 15:01

Re: Why do we restart the daemon in -configs .config script?

On 2005-03-01 Marc Haber <mh+pkg-exim4-devel <at> zugschlus.de> wrote:
> #297607 is caused by the restart of the daemon done in the .config. A
> quick grep shows that we're the only package on my _big_ system that
> uses invoke-rc.d in a .config script.

> I have been told that dpkg-reconfigure also invokes postinst.

> May I ask whether there is a reason for not doing the restart in
> postinst?

Hello,
I was unsure about this but it seems to be the correct way. We only
want to restart the daemon in exim4-config's maintainerscripts on
dpkg-reconfigure and only the .config script gets that information. -
On dpkg-reconfigure .config is started with reconfigure as $1, but
postinst still gets "configure".
                cu andreas
--

-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"
                                           http://downhill.aus.cc/
Permalink | Reply | 0 comments |
headers
Marc Haber | 11 Mar 2005 23:24
Picon

closing fds on startup causing bugs

On Wed, Mar 02, 2005 at 09:08:12AM +0100, Marc Haber wrote:
> On Tue, Mar 01, 2005 at 10:54:08PM +0100, Marc Haber wrote:
> > #297607 is caused by the restart of the daemon done in the .config.
> 
> And caused by 10_daemon_close_fd not applying to 4.50 and dpatch not
> complaining about this. Fixed in incoming.

We have had the 10_daemon_close_fd patch for ages now. However, it
looks like the patch breaks things. For example, #299051 looks like
being caused by our patched daemon closing a file descriptor that the
libnss-ldap library has previously opened to talk to the ldap daemon.
Thanks to Florian Weimer for being most insightful in debugging.

So, I am afraid that we need to back out the 10_daemon_close_fd_patch
which will recreate #297607.

(1) Call db_stop before invoke-rc.d in exim4-config.config. This is
the way recommended by debconf documentation, and it indeed works.
However, upgrades do not work any more since during upgrade, first the
new binary is unpacked, then the _old_ config script is invoked once
more, which will hang since the debconf fd will still be open. Any
ideas how to solve this?

(2) Florian suspects a race condition in the db_stop call and suggests
redirecting fd 3 from /dev/null when invoking the new daemon. I am not
sure whether this is the right thing to do since it assumes quite a
lot about debconf (which might be subject to change in the future).

What do you think about that?
(Continue reading)

Permalink | Reply | 5 comments |
headers
Marc Haber | 11 Mar 2005 23:43
Picon

Re: Build-Depends-Indep instead of Build-Depends.

On Tue, Mar 01, 2005 at 08:46:42PM +0100, Andreas Metzler wrote:
> On 2005-02-28 Marc Haber <mh+pkg-exim4-devel <at> zugschlus.de> wrote:
> > Lintian complains about Build-Depends being used for an architecture
> > independent package,
> 
> Yes, that complain is broken.

Is there a bugreport for that?

> > Which part of policy does support your thesis?
> 
> Policy is not correct in that respect. The behavior I decribed is the
> one the buildds

Why do buildds care about architecture-independent packages?

>  and dpkg-buildpackage enforce.

Can you elaborate on dpkg-buildpackage's behavior? I suspect that you
mean the -B switch?

Greetings
Marc

--

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835
(Continue reading)

Permalink | Reply | 6 comments |
headers
Florian Weimer | 11 Mar 2005 23:45
Picon

Re: closing fds on startup causing bugs

* Marc Haber:

> (2) Florian suspects a race condition in the db_stop call and suggests
> redirecting fd 3 from /dev/null when invoking the new daemon. I am not
> sure whether this is the right thing to do since it assumes quite a
> lot about debconf (which might be subject to change in the future).

> What do you think about that?

There's also (2') -- lobby for inclusion of a db_invoke directive into
/usr/share/debconf/confmodule which hides the details about
descriptor 3.

The transition problem is a different matter, though.
Permalink | Reply | 1 comment |
headers
Marc Haber | 11 Mar 2005 23:51
Picon

Re: closing fds on startup causing bugs

On Fri, Mar 11, 2005 at 11:45:36PM +0100, Florian Weimer wrote:
> * Marc Haber:
> > (2) Florian suspects a race condition in the db_stop call and suggests
> > redirecting fd 3 from /dev/null when invoking the new daemon. I am not
> > sure whether this is the right thing to do since it assumes quite a
> > lot about debconf (which might be subject to change in the future).
> 
> > What do you think about that?
> 
> There's also (2') -- lobby for inclusion of a db_invoke directive into
> /usr/share/debconf/confmodule which hides the details about
> descriptor 3.

I am afraid that it is virtually guaranteed that this will not be
happening before sarge.

> The transition problem is a different matter, though.

Any idea how to solve this in an elegant way?

Greetings
Marc

--

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835
(Continue reading)

Permalink | Reply | 0 comments |

Gmane