headers
Frank Lichtenheld | 1 Nov 2005 01:04
Picon
Favicon
Gravatar

Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?

On Mon, Oct 31, 2005 at 06:56:44PM +0100, Frank Küster wrote:
> In my opinion this is not a bug (except if the package is crucial for
> the system to work and be reachable, like ssh) - the local admin simply
> has to review the changes to conffiles that dpkg requested, and have a
> look at NEWS.Debian and changelog.Debian.  If these files do not contain
> enough information to fix the system, then this is a bug, right?  But
> the simple fact that a postinst script fails because a change has been
> refused isn't - and for sure it is not a serious or grave bug,
> severities often used when a postinst fails.
> 
> Opinions?

There is one big problem with that scenario that I haven't seen
mentioned in this thread yet: If I make the dist-upgrade of a machine
from sarge to etch and the dist-upgrade fails right in the middle
of the installed 3000 packages I will be severly disappointed to
say the least if that didn't happen for a very good reason...
That's a fact that often gets lost when discussing such problem from
developer to developer that install sid on their machines and update
about 30 packages at once.

So if it is at all possible to avoid failing the postinst (which of
course also means to not break other packages installation as you
have pointed out) it should be done.

If it is at all possible in the case of tetex I can't tell, though.

Gruesse,
--

-- 
Frank Lichtenheld <djpig <at> debian.org>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Steve Langasek | 1 Nov 2005 01:08
Picon
Favicon

Re: Help: Bug#336469: pure-ftpd uninstallable : no pure-ftpd-common


On Mon, Oct 31, 2005 at 03:26:51PM -0500, Nathanael Nerode wrote:
> Henning Makholm wrote:

> > Such a construction ought to be used everytime one uses
> > =${Source-Version} to refer to an arch-independent package.
> > There really ought to be some stock magic in {dpkg-,dh_}gencontrol
> > for this, but currently there isn't.
> Hmm.  You're right.  Wishlist bug filed against debhelper, since it has more
> machinery to deal with substvars than anything else does.

No, it's a bug in dpkg-dev, which should know how to set ${Source-Version}
correctly for binNMUs.

--

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon <at> debian.org                                   http://www.debian.org/
Permalink | Reply | 4 comments |
headers
Darren Salt | 1 Nov 2005 01:19
Picon
Picon

/usr/lib/debug/usr/lib etc. in various packages [bug 336698]

I've noticed that several files which should be in /usr/lib/debug are in fact
in /usr/lib/debug/usr/lib. Checking via packages.d.o shows that as well as
this, debug data is showing up in /usr/lib/debug/usr/bin and
/usr/lib/debug/lib.

There is at least one bug (no. 324681) already reported concerning this; I've
not yet checked for others.

Affected maintainers have not yet been CC'd; bugs will be filed once a fixed
debhelper appears in unstable (or I'm told that I'm completely wrong :-) ).

The following binary packages are affected (sorted by maintainer), according
to packages.d.o (and a little script which is attached):

Aaron M. Ucko <ucko <at> debian.org>
	libfltk1.1-dbg
	libncbi6-dbg
	libvibrant6-dbg

Akira TAGOH <tagoh <at> debian.org>
	libatk1.0-dbg
	libatspi-dbg

Debian Boost Team <pkg-boost-devel <at> lists.alioth.debian.org>
	libboost-dbg

Debian GCC Maintainers <debian-gcc <at> lists.debian.org>
	libgcj6-dbg
	libstdc++6-4.0-dbg
(Continue reading)

Permalink | Reply | 1 comment |
headers
Steve Langasek | 1 Nov 2005 03:32
Picon
Favicon

Re: Bug#336698: dh_strip: debug data going to the wrong place

On Tue, Nov 01, 2005 at 12:19:07AM +0000, Darren Salt wrote:
> I've noticed that several files which should be in /usr/lib/debug are in fact
> in /usr/lib/debug/usr/lib. Checking via packages.d.o shows that as well as
> this, debug data is showing up in /usr/lib/debug/usr/bin and
> /usr/lib/debug/lib.

> There is at least one bug (no. 324681) already reported concerning this; I've
> not yet checked for others.

> Affected maintainers have not yet been CC'd; bugs will be filed once a fixed
> debhelper appears in unstable (or I'm told that I'm completely wrong :-) ).

Sorry, you're completely wrong.  The files installed in
/usr/lib/debug/usr/lib are detached symbol files, that are loaded
automatically by gdb -- *not* using LD_LIBRARY_PATH; and gdb looks for
detached symbol files by prepending /usr/lib/debug to the full path of the
original object file.  So there's no debhelper bug here.  If there are
detached symbol files that aren't working, that bug must lie elsewhere.

--

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon <at> debian.org                                   http://www.debian.org/
Permalink | Reply | 4 comments |
headers
Matthew Palmer | 1 Nov 2005 05:31
Picon
Favicon

Re: /usr/lib/debug/usr/lib etc. in various packages [bug 336698]

On Tue, Nov 01, 2005 at 12:19:07AM +0000, Darren Salt wrote:
> I've noticed that several files which should be in /usr/lib/debug are in fact
> in /usr/lib/debug/usr/lib. Checking via packages.d.o shows that as well as
> this, debug data is showing up in /usr/lib/debug/usr/bin and
> /usr/lib/debug/lib.

Further to Steve's comments, see section 15.2 of the GDB manual, "Debugging
Information in Separate Files".  It describes what actually goes on.  The
rationale for keeping full paths inside /usr/lib/debug is solid, too, once
you think about it -- without the hierarchy within /usr/lib/debug, you'd
have no way to store detached symbols for multiple executables with the same
name, unless the files were stored by some non-name-related scheme (ugly).

- Matt
Permalink | Reply | 0 comments |
headers
Steve Langasek | 1 Nov 2005 06:34
Picon
Favicon

Re: Transition time: KDE, JACK, arts, sablotron, unixodbc, net-snmp, php, ...

On Mon, Oct 31, 2005 at 02:54:49PM -0500, Nathanael Nerode wrote:
> The enormous ABI transitions have been particularly hard, of course.  If
> we can avoid ABI-breaking transitions in the future it would help.  :-)

Wholly unrealistic.  Libraries *do* undergo ABI changes; there are only a
handful of library upstreams who know how to write a library interface
that's proofed against future design decisions, and in most cases it's not
worth the effort to try to write libs this way -- and it wouldn't save us
from C++ ABI changes anyway.

> I think making a queue for transitions, so that they're basically one at a
> time, would solve most remaining problems.

Doesn't work when lib maintainers don't coordinate.

A better option is to make britney more resilient in dealing with library
transitions by keeping old binary packages around in testing instead of
requiring them to be removed at the same time as the new version enters,
which removes the need for all packages to be ready to enter testing at the
same time.  This has been on the TODO list since it was discussed this past
March in Vancouver, and is currently the top item on Anthony Towns' britney
hacking list at <http://www.erisian.com.au/market/>.

--

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon <at> debian.org                                   http://www.debian.org/
Permalink | Reply | 2 comments |
headers
Russ Allbery | 1 Nov 2005 06:49
Picon
Favicon
Gravatar

Re: localhost.localdomain

Gabor Gombas <gombasg <at> sztaki.hu> writes:
> On Fri, Oct 07, 2005 at 11:18:57AM -0700, Russ Allbery wrote:

>>  * Obtain the system host name with gethostname().
>>  * Look up an IP address for that host with gethostbyname().

> The bug is here. This is completely wrong but sadly very common
> practice. It is common because it is portable and works with some simple
> configurations (namely, single-homed machines with static IP address).

Well, I don't really agree with the statement that it's completely wrong,
but I do understand what you're saying about the semantic mismatch at work
here.

>>  * Look up the names associated with that address with gethostbyaddr().
>>  * Walk the alias list of the result and find the first name containing
>>    a period.

> The proper fix would be to enumerate all IP addresses of all network
> interfaces and select one that has an appropriate name. Unfortunately
> this is non-trivial and highly OS-dependent, although the libdumbnet1
> package provides a platform-independent API for this (among other
> things).

You've pretty much covered in that paragraph the reasons why INN can't
take that approach.  :)  I know how hard this is from watching MIT
Kerberos try to solve this problem and don't want to touch this
portability nightmare with a ten-foot pole.

--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Steve Langasek | 1 Nov 2005 07:22
Picon
Favicon

Re: Transition time: KDE, JACK, arts, sablotron, unixodbc, net-snmp, php, ...

On Mon, Oct 31, 2005 at 02:30:56PM +0100, Aurelien Jarno wrote:
> Steve Langasek a écrit :
> >source packages that need to be updated!  As a result, the release
> >team asks that the maintainers refrain from uploads of these packages for
> >any reason without coordination with the release team, until this
> >transition completes; uncoordinated uploads will most likely lead to your
> >package being removed from testing to let the transition complete.  

> On the other hand testing is a way for out users to have a 
> not-so-unstable, and not-so-outdated system. It is also a way to have 
> our distribution well tested. However, from what I heared, a lot of 
> users currently consider testing has broken, due to a lot of missing 
> packages. gimp-print for example has been removed from testing during 
> one month or so, rending the printing from gimp impossible.

That's not true.  There has been a gimp-print package present in testing
at all points since the sarge release; but for a period of time the version
did not match the version of gimp, and was not usable -- which was a bug in
gimp, as its dependencies should have prevented installation of gimp and
gimp-print in a broken combination.  It has always been a weakness of
testing that RC bugs that don't get reported against packages before they
reach testing take longer to resolve for testing users, and short of getting
rid of testing completely, the only way to address this is by doing a better
job of identifying RC bugs before packages reach testing.

> So I would like to propose to drop testing during a limited period of 
> time (let's say 4 months) after the release, to have the time to make 
> all the necessary big transitions. If the period of time is limited, the 
> stable distribution will not be too out-dated, so that it won't be a 
> problem for our users. Moreover, that will make them stopping
(Continue reading)

Permalink | Reply | 0 comments |
headers
Russ Allbery | 1 Nov 2005 08:15
Picon
Favicon
Gravatar

Re: Dependencies of -dev packages

Gabor Gombas <gombasg <at> sztaki.hu> writes:

> libkrb5-dev Conflicts: heimdal-dev
> ==================================

> The problem here is that this "Conflicts:" assumes that the system has
> just one user, which is simply not true.

Speaking as a co-maintainer of libkrb5-dev, no, this Conflicts assumes
that the two packages, er, conflict.  Namely, they provide
identically-named include files which define different ways of
implementing roughly the same API.  I'd love to have heimdal-dev and
libkrb5-dev peacefully coexist since I personally use both, but since they
both implement the same API, this is rather difficult to do.

Please note that using pbuilder works around this issue fairly well for
building Debian packages, although I realize that this is far from solving
every application.

> pkg-config comes handy again. If every package provides a .pc file, then
> conflicting libraries and headers can simply be moved to separate
> directories (/usr/lib/heimdal, /usr/lib/mit-krb5, /usr/include/heimdal,
> /usr/include/mit-krb5) and can peacefully coexist.

I don't consider this to be a good solution.  #include <krb5.h> is part of
the API, and forcing all packages that want to build with Kerberos to use
special compiler flags to find include files in non-standard locations
seems to me to defeat the entire point of the FHS.  (I didn't think
separating the libraries was necessary; don't they use non-conflicting
names already?)
(Continue reading)

Permalink | Reply | 3 comments |
headers
Russ Allbery | 1 Nov 2005 08:21
Picon
Favicon
Gravatar

Re: Bug#315059: Drop KRB4 support from HEIMDAL

Ben Pfaff <blp <at> cs.stanford.edu> writes:
> Brian May <bam <at> debian.org> writes:

>> Is it time to think about removing kerberos4kth from the archive
>> anyway?

> Stanford still uses Kerberos 4.  Would removing kerberos4kth be
> tantamount to dropping Kerberos 4 support?  When I've tried to use
> Debian's other implementations of Kerberos in the past at Stanford, I've
> had no luck at all.

We have another implementation available locally at Stanford for Debian
users here and I can point Ben at that.  We're starting our project to
retire K4 at Stanford the beginning of next year, so please don't maintain
K4 support in Debian on our account.  We have a handful of local packages
that do the bits that are necessary for us and that we'll drop as soon as
we finish our migration.

Note that I don't speak for SLAC, but I think they're mostly using Red
Hat.

--

-- 
Russ Allbery (rra <at> stanford.edu)             <http://www.eyrie.org/~eagle/>
Permalink | Reply | 0 comments |

Gmane