Ben Pfaff <[EMAIL PROTECTED]> writes:
> Brian May <[EMAIL PROTECTED]> 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
> Deb
Gabor Gombas <[EMAIL PROTECTED]> 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 as
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, unt
Gabor Gombas <[EMAIL PROTECTED]> 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
> practi
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 o
On Tue, Nov 01, 2005 at 12:19:07AM +, 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/l
On Tue, Nov 01, 2005 at 12:19:07AM +, 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/l
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 concerni
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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 st
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.Deb
On Mon, Oct 31, 2005 at 07:21:48PM +0100, Peter Eisentraut wrote:
> I have been in a discussion with a fellow developer about the exact
> meaning of the "0-day NMU policy" that is currently in effect.
> Questions:
Ok, I've tried to answer the questions as good as possible.
I think this aren't t
Florian Weimer wrote:
> * Steve Langasek:
>
>> Frank Lichtenheld has already posted an announcement[4] detailing the
>> release team's plans for the question of non-DFSG documentation in main.
>
> Just to clarify, is technical documentation that is only available in
> non-editable formats (e.g.
Thomas Bushnell BSG wrote:
> Nathanael Nerode <[EMAIL PROTECTED]> writes:
>
>> The enormous ABI transitions have been particularly hard, of course. If
>> we can avoid ABI-breaking transitions in the future it would help. :-)
>> I think we have a poor image of the effectiveness of 'testing' bec
Benjamin Mesing <[EMAIL PROTECTED]> writes:
> Hello
>
>
>> assume that an update to a package brings in a changed conffile, and
>> because the local admin had changed the conffile, he is asked, and he
>> refuses to accept the changed version.
> This brings up an issue that is bothering me as a use
After the feedback of the recent d-d thread, I've adapted the section I wrote
on the best practices related to system users and groups, it is currently
available at:
http://www.debian.org/doc/manuals/developers-reference/ch-best-pkging-practices.en.html#s-bpp-lower-privs
I would like developers t
On Mon, 31 Oct 2005, Henrique de Moraes Holschuh wrote:
The principle of least surprise, and the meaning of "meta" are good enough
reasons for me to never have ANYTHING but debian/control in a meta package.
If the package packages something, it is NOT a meta-package, it is a
package. IMHO anywa
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
Nathanael Nerode <[EMAIL PROTECTED]> writes:
> The enormous ABI transitions have been particularly hard, of course. If
> we can avoid ABI-breaking transitions in the future it would help. :-) I
> think we have a poor image of the effectiveness of 'testing' because *both*
> of the last two relea
On 10/31/05, Benjamin Mesing <[EMAIL PROTECTED]> wrote:
> This brings up an issue that is bothering me as a user since a long
> time. Whenever I change a config file, I have to take care and examine
> changes of the config file in its pacakge. Because most times those
> provide some enhancments (e.
Benjamin Mesing <[EMAIL PROTECTED]> wrote:
> Now I have two questions: Is such a feature generally desirable? Is
> there someone willing to give it some thought and implement it (I am
> currently short in time) or should I file a wishlist bug against dpkg?
Yes, I think it *is* desirable; and in
Hello
> assume that an update to a package brings in a changed conffile, and
> because the local admin had changed the conffile, he is asked, and he
> refuses to accept the changed version.
This brings up an issue that is bothering me as a user since a long
time. Whenever I change a config file,
Aurelien Jarno wrote:
> I know that it is to late for etch, but that could apply for etch + 1.
> What do you think?
I think this is the wrong way to go.
The major problem which has caused major clogs in 'testing' is that
different transitions have been getting tied up with each other. This has
a
sean finney <[EMAIL PROTECTED]> wrote:
> On Mon, Oct 31, 2005 at 07:52:27PM +0100, Frank Küster wrote:
>> You mean the postinst script should succeed even if the program is not
>> able to work? This doesn't fit with the meaning of "Depends", because
>
> what i meant was that if you're running som
On Mon, Oct 31, 2005 at 07:52:27PM +0100, Frank Küster wrote:
> You mean the postinst script should succeed even if the program is not
> able to work? This doesn't fit with the meaning of "Depends", because
what i meant was that if you're running some utility in the
postinst that might fail for s
"Roberto C. Sanchez" <[EMAIL PROTECTED]> wrote:
> On Mon, Oct 31, 2005 at 07:52:27PM +0100, Frank Küster wrote:
>>
>> You mean the postinst script should succeed even if the program is not
>> able to work? This doesn't fit with the meaning of "Depends", because
>> other packages declare a Depend
Hi,
to make it clear to everybody: The package that brought this up is
teTeX, but I think the point is more general
Thijs Kinkhorst <[EMAIL PROTECTED]> wrote:
> On Mon, 2005-10-31 at 18:56 +0100, Frank Küster wrote:
>> Because one of the changes in the new version was crucial for the
>> functio
On Mon, Oct 31, 2005 at 07:52:27PM +0100, Frank Küster wrote:
>
> You mean the postinst script should succeed even if the program is not
> able to work? This doesn't fit with the meaning of "Depends", because
> other packages declare a Depends exactly because they want to use the
> program, they
On Mon, 2005-10-31 at 18:56 +0100, Frank Küster wrote:
> Because one of the changes in the new version was crucial for the
> function of the program, the postinst script fails to initialize it, and
> the whole installation process fails.
Would it be possible to modify the program so that it is mor
sean finney <[EMAIL PROTECTED]> wrote:
> On Mon, Oct 31, 2005 at 06:56:44PM +0100, Frank Küster wrote:
>> 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.
>>
>>
I have been in a discussion with a fellow developer about the exact
meaning of the "0-day NMU policy" that is currently in effect.
Questions:
1. Does the 0-day policy only apply to RC bugs or to all bugs?
2. Does the "0 day" apply to the delay after the upload or to the delay
between the subm
On Mon, Oct 31, 2005 at 06:56:44PM +0100, Frank Küster wrote:
> 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?
without knowing more about "package
Hi,
Eduard Bloch schrieb:
> Yep. What about another crazy idea... why not check the expected impact
> from a certain package update before a package has been accepted in
> _Unstable_? So katie could just veto a version change automaticaly
> before it too much mess is created, even (or especially)
Hi,
assume that an update to a package brings in a changed conffile, and
because the local admin had changed the conffile, he is asked, and he
refuses to accept the changed version.
Because one of the changes in the new version was crucial for the
function of the program, the postinst script fail
Package: wnpp
Severity: wishlist
Owner: Sune Vuorela <[EMAIL PROTECTED]>
* Package name: kommando
Version : 0.2
Upstream Author : Daniel Stoeckel
* URL : http://www.kde-look.org/content/show.php?content=29514
* License : GPL
Description : A wheel menu f
#include
* Christoph Berg [Mon, Oct 31 2005, 03:04:53PM]:
> Re: Aurelien Jarno in <[EMAIL PROTECTED]>
> > 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.
>
> Is
Aurelien Jarno wrote:
>> 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 like
> Steve Langasek a écrit :
> 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 t
On Monday 31 October 2005 09:54 am, Henning Makholm wrote:
> Scripsit Steve Langasek <[EMAIL PROTECTED]>
>
> > For the first time over the past months, we are now able to get a
> > comprehensive look at just which packages are involved in this
> > transition -- around 300 source packages that need
Scripsit Steve Langasek <[EMAIL PROTECTED]>
> For the first time over the past months, we are now able to get a
> comprehensive look at just which packages are involved in this
> transition -- around 300 source packages that need to be updated!
> As a result, the release team asks that the maintai
Re: Aurelien Jarno in <[EMAIL PROTECTED]>
> 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.
Isn't that what has effectively happened? Now unstable is in shape,
and t
* Aurelien Jarno ([EMAIL PROTECTED]) [051031 14:31]:
> So it seems that unstable is again, as before the release, half-frozen.
> Maybe we could change its name?
>
> Seriously, I begin to consider that as a real problem. I am not blaming
> you, release maintainers, you are doing your job. From my
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
Brian May <[EMAIL PROTECTED]> writes:
> Hello,
>
> I consider this a bug; reports sent to @packages.debian.org
> should go straight through to a maintainer or list of maintainers...
>
> However, this appears to be sent to an upstream development mailing
> list, and it would appear my mail has no
Hi Florian,
On Mon, Oct 31, 2005 at 09:33:53AM +0100, Florian Weimer wrote:
> Given kasserver.com's recent connectivity issues, I wouldn't consider
> that admissable evidence. 8-P
I thought these were resolved as of 24 October. Were there
problems afterwards?
And then there is still this 5 and a
This one time, at band camp, Florian Weimer said:
> * Jochen Voss:
>
> > Hello,
> >
> > On Sat, Oct 29, 2005 at 07:04:02PM +0200, Frank Küster wrote:
> >> There were also some bugs for tetex-* that were never sent to the
> >> Maintainer: field, namely the debian-tetex-maint mailing list.
> > Here
* Jochen Voss:
> Hello,
>
> On Sat, Oct 29, 2005 at 07:04:02PM +0200, Frank Küster wrote:
>> There were also some bugs for tetex-* that were never sent to the
>> Maintainer: field, namely the debian-tetex-maint mailing list.
> Here is another one. The following message (related to bug #335689)
>
46 matches
Mail list logo
