Re: debian (1.2.22-3~bpo8+1) package build failure
Olly Betts <[email protected]>
| Newsgroups | gmane.comp.search.xapian.devel |
|---|---|
| Message-ID | <[email protected]> |
On Tue, Aug 16, 2016 at 11:40:55PM +0000, Eric Wong wrote: > Olly Betts <[email protected]> wrote: > > On Sat, Aug 06, 2016 at 03:43:48AM +0000, Eric Wong wrote: > > > Eric Wong <[email protected]> wrote: > > > +#ifdef FD_CLOEXEC > > > + (void)fcntl(lockfd, F_SETFD, FD_CLOEXEC); > > > +#endif > > > > This is fixed in master and 1.4.0, which set CLOEXEC for all relevant > > FDs. Those changes weren't backported as they were rather pervasive > > and we'd had no user reports of issues due to this, but since the > > CLOEXEC changes we now we lock in process on a modern Linux kernel and > > that change got backported - as you've noticed that can cause more major > > issues without CLOEXEC, and I think we ought to backport CLOEXEC for the > > lock file to 1.2.x. > > Thanks for the response. Is this the svn/1.2 branch in > the git repo? Currently at: > > commit 76e09ea726d9666462567b5839899fc53f53cebe > ("Fix typo in POD docs for Search::Xapian") Yes - the name is a historical remnant at this point, but I'm slightly reluctant to tidy that up as it's referenced in various scripts, buildbot configuration, etc. I've backported the relevant CLOEXEC handling to there now. Not sure when the next 1.2.x will happen, but probably 1.4.1 is first. > Did you get a chance to look into the build failure? The build failure isn't something that rings a bell, and those packages built OK for me in a clean jessie/sid chroot (as appropriate) using sbuild before I uploaded them. I haven't try to reproduce as it seemed unlikely that would have changed, and I have a bit of todo pile already. Cheers, Olly