Re: Getting rid of circular dependencies, stage 6

[Manoj Srivastava]

On Wed, 25 Oct 2006 07:01:22 +0200, Christian Perrier <[EMAIL PROTECTED]> said: 

>> install time are indeed buggy, but I see no indication that the
>> jihad against circular dependencies is making any such
>> distinctions.

> Is the word "jihad" meant to mean "holy, and aggressive, war to
> spread out a religion" here?

It also means, at least in farsi, and urdu,  a war fought with
 passion on a principle or belief.  Lots of crusades and wars foought
 for religion (though not necessarily to spread the religion) do fit
 the definition.

> I recently had an argument with another maintainer who also used tha
> word with that meaning, which it doesn't have in the muslim culture
> (I'm personnally a bit sensitive about that, for reasons I would
> have much difficulties to explain). I felt it to be pretty offensive
> to my muslim friends.

They felt offended by the term that roughly translates into
 "holy war"?  how ...  strange.

> It that's the case, I'm not sure this is the best way to make the
> point. I'm actually following this thread and I try to understand
> whether the circular dependencies used by console-common (for which
> I act as co-maintainer with Alastair McKinstry) are Good or Bad.

I do think that there is a whift of dogma around the current
 crusade against all circular dependencies, whther or not the
 installation phase actually cares about the dependency or not. Oh
 dear -- have I now offended all Christians?

> I appreciate the work done by Bill on that issue and I currently do
> not have the feeling that it is run with the intents you seem to put
> in the word "jihad".

One can appreciate work done to reduce un-needed circular
 dependencies without bying the cool aid that all circular
 dependencies are bad and must be eliminated at all costs.

I appreciate the former, I think the latter is a bad idea.

manoj
-- 
A bird in the hand is worth what it will bring.
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Bug mass filling

[Jean-Christophe Dubacq]

On Wed, Oct 25, 2006 at 01:48:02AM -0400, Kevin Mark wrote:
> So certain bugs can be marked $STABLE-ignore to allow transient rc
> issues to be ignored for a release and will become no-ops after release.
> Are you suggesting that each package can have a related list of
> non-transient bugs that should be marked (with a new tags called )
> ignore-this-policy-violation where this can be attached to any package
> related bug for any length of time until the issues is deemed
> worthy/necessary to be addressed?

If a rule defining a bug ended in the policy document, it certainly is
worthy of being addressed. As Manoj expressed several times, if a bug
can be ignored for an arbitrary length of time, it certainly should be
a note in the developer reference and not a sentence in the policy
document.


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

Re: Bug mass filling

[Andreas Barth]

* Manoj Srivastava ([EMAIL PROTECTED]) [061024 23:53]:
> If you are aware of issues that are violations of muSt
>  directives that are never going to be RC, there should be a bug
>  opened on policy with severity important for every one of them.

I hope to have time post-etch-release to do that (that is what I meant
with "syncing between policy and release-policy").



Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


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

Re: First draft of review of policy must usage

[Andreas Barth]

* Manoj Srivastava ([EMAIL PROTECTED]) [061025 08:04]:
> [...]

Manoj, I'm seriously asking you if we can delay this discussion until
after Etch is out. I'm very interessted in takeing part in the
discussion, but I really have already to many open very urgent tasks at
my hands.


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


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

Re: Getting rid of circular dependencies, stage 6

[Henning Glawe]

On Wed, Oct 25, 2006 at 02:18:44AM -0500, Manoj Srivastava wrote:
> One can appreciate work done to reduce un-needed circular
>  dependencies without bying the cool aid that all circular
>  dependencies are bad and must be eliminated at all costs.
> 
> I appreciate the former, I think the latter is a bad idea.

well, as long APT gets fixed once and for all.

-- 
c u
henning


signature.asc
Description: Digital signature

should, ought, must (was: Bug mass filling)

[Frank Küster]

Manoj Srivastava <[EMAIL PROTECTED]> wrote:

> On Tue, 24 Oct 2006 17:15:55 -0700, Steve Langasek <[EMAIL PROTECTED]> said: 
>> Is the word "generally" here an error?  I read this as implying the
>> normal meaning of "should" -- that not everything which violates a
>> "should" mandate is a bug.
>
> I am of the opinion that it is. We can replace non-buggy
>  instances of should by 'ought to be', if needed.

But please don't forget a "legal definition" of those terms.  For me, as
a non-native speaker, I have no idea whether "ought to" is weaker or
stronger than "should", or just something different (and what).

Regards, Frank
-- 
Dr. Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: arches and etch

[Raphael Hertzog]

On Tue, 24 Oct 2006, Reinhard Tartler wrote:
> The only clean way to do this is IMO a dedicated upgrader tool. This
> tool could then have special rules for the following issues:

I don't know if we need such a tool, but it would be definitely helpful if
we had a mechanism to give "hints" to aptitude/apt-get in order to let
them know important changes in the packaging:

It could be new fields like:
Package: python-something
Supersedes: python2.3-something, python2.4-something
Renders-Useless: python-something-common

It could be some generic regexps:
Hint: python\d.\d-(.*) -> python-$1

We could have some priorities associated to hints so that very specific
hints overrides global ones.

> This is of course an etch+1 thing, and really specific for a given
> release.
>
> You can of course imagine that these ideas don't come out of the
> blue. In fact, such a tool is already deployed in ubuntu. I think we
> could port it to debian as well, if enough people see a need for it.

I've never evaluated it but such a tool should try to be generic: for
example it should detect priority changes and proposes for example the
replacement of netkit-inetd by openbsd-inetd.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


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

Re: Bug mass filling

[Frank Küster]

Manoj Srivastava <[EMAIL PROTECTED]> wrote:

> On Tue, 24 Oct 2006 16:04:54 -0700, Steve Langasek <[EMAIL PROTECTED]> said: 
>
>> Because your choice of mapping blurs the distinction between
>> one-time exceptions for RCness (e.g., due to GRs for DFSG issues),
>> vs. policy violations that the release team does not believe should
>> be promoted to RC status at any time in the foreseeable future.
>> "etch-ignore" is most useful as a tag if its use is restricted to
>> those bugs whose *non*-release-criticality is transient in nature --
>> the alternative is that the release team is stuck going through the
>> BTS after each release and re-adding new tags to those bugs about
>> policy violations whose severity does not justify exclusion from the
>> release.
>
> That does not make sense. After etch is released, etch-ignore
>  tags are no-ops -- so there is no need to go back and untag anything.

The work would be to change the tag to "whatever-ignore".

> And if there are anyissues that are policy must directives
>  that the release team has take upon itself to say are policy
>  directives it is not worth following, then they should file important
>  bugs against polocuy to either have the requirements removed, or the
>  issue resovled by the tech ctte.

I don't like your wording of "not worth following".  A policy dictum
might well be important to follow, but non-conformance may still (always
or in particular cases) not be a reason to exclude it from the release.

But you're of course right that Policy and the release-policy should be
synchronized... 

Regards, Frank
-- 
Dr. Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: Getting rid of circular dependencies, stage 6

[Jean-Christophe Dubacq]

On Wed, Oct 25, 2006 at 07:01:22AM +0200, Christian Perrier wrote:
> >  install time are indeed buggy, but I see no indication that the jihad
> >  against circular dependencies is making any such distinctions.
> 
> It that's the case, I'm not sure this is the best way to make the
> point. I'm actually following this thread and I try to understand
> whether the circular dependencies used by console-common (for which I
> act as co-maintainer with Alastair McKinstry) are Good or Bad.

During my switch to aptitude instead of debfoster/apt-get, I recently
thought that:
aptitude markauto '~i(!~M)((~R(~i))|(~Rrecommends:(~i!~M)))'
or even
aptitude markauto '~i(!~M)~R(~i)'
should be an idempotent operation. And that once this is done, I could
not mark any more packages as automatic (ok, you have to refine a bit to
hold in account the fact that recommends is as good as depends for
aptitude in default mode ; I did not include the more complicated search
for the sake of simplicity).

Once I have selected console-data to be marked manual and the rest
(console-tools, console-common) to be automatic, I expect it would
see that everything holds. Instead of that, it just finds the circular
dependency loop and says that since they only depend on themselves,
those packages are probably a useless loop.

As a matter of fact, I can live with a few exceptions. But this way
(with a more complicated search in aptitude that accounts for the
Recommends dependency) is a quick way to find circular dependencies.

On my system, there is a dependency loop for 
console-* packages, {sys,}klogd packages and
fortune-* packages, at least.


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

Re: First draft of review of policy must usage

[Raphael Hertzog]

Hi,

On Wed, 25 Oct 2006, Andreas Barth wrote:
> * Manoj Srivastava ([EMAIL PROTECTED]) [061025 08:04]:
> > [...]
> 
> Manoj, I'm seriously asking you if we can delay this discussion until
> after Etch is out. I'm very interessted in takeing part in the
> discussion, but I really have already to many open very urgent tasks at
> my hands.

Andreas, I understand your feeling but you have to accept that you can't
be on all fronts at the same time.

I understand we need to make concessions towards a release (like
concentrating on fixing bugs instead of introducing new major upstream
changes) but it shouldn't block Debian's progress in all areas.
You must understand that if Manoj is not fixing the policy, he probably
won't use that time to fix RC bugs.

And in that particular case, I have the feeling that Manoj has taken into
account the remarks of the RM since he removed the problematic parts
for now, and loosened some must into should in order to better fit
the RM conception of 'release critical'.

Manoj, I have reviewed your patch and it looks ok for me. I haven't
checked its completeness (wrt etch_release_policy.txt) however.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


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

Re: First draft of review of policy must usage

[Joerg Jaspert]

On 10818 March 1977, Luk Claes wrote:

> Can everyone please focus on the release and discuss things that don't help to
> release on December 4th at all till after that date?

No, the release is no reason to stop everything else.

-- 
bye Joerg
 Snow-Man: Please don't talk to me. You have demonstrated yourself
  sufficiently. There is a serious matter being talked.
 exa: It's hardly serious, it's about you.


pgpIgTtmtEa1Q.pgp
Description: PGP signature

Re: RFP: tinymce -- Web based Javascript HTML WYSIWYG editor

[Alexis Sukrieh]

* Moritz Muehlenhoff ([EMAIL PROTECTED]) :
> That would be much appreciated. 

The package "tinymce" has just been uploaded to the NEW queue. FYI it's
the first package handled by the Webapps Team.

You can grab the sources form our SVN repository:
http://svn.debian.org/wsvn/webapps-common/packages/tinymce/?rev=0&sc=0

Regards,

-- 
Alexis Sukrieh <[EMAIL PROTECTED]>
0x1EE5DD34
Debian   http://www.debian.org
Backup Manager   http://www.backup-manager.org


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

debian kernels and APM poweroff

[Henning Glawe]

Moin,
there is one issue with the newer debian kernels, as they have SMP enabled:
as documented in bugs #376089 and #378323, apm poweroff does not work
anymore.

A possible solution is to put

options apm poweroff


somewhere under /etc/modprobe.d/ and regenerate the initrd. IMHO it would be
a good idea to enable apm poweroff by default (as it worked before, when there
were separate uniprocessor kernels).

The most obvious place to put this would be 
module-init-tools:/etc/modprobe.d/arch/i386
which is a bit hard to change now, as base is frozen...

-- 
c u
henning


signature.asc
Description: Digital signature

Re: should, ought, must (was: Bug mass filling)

[Andreas Barth]

* Frank Küster ([EMAIL PROTECTED]) [061025 09:49]:
> Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> 
> > On Tue, 24 Oct 2006 17:15:55 -0700, Steve Langasek <[EMAIL PROTECTED]> 
> > said: 
> >> Is the word "generally" here an error?  I read this as implying the
> >> normal meaning of "should" -- that not everything which violates a
> >> "should" mandate is a bug.
> >
> > I am of the opinion that it is. We can replace non-buggy
> >  instances of should by 'ought to be', if needed.
> 
> But please don't forget a "legal definition" of those terms.  For me, as
> a non-native speaker, I have no idea whether "ought to" is weaker or
> stronger than "should", or just something different (and what).

I think we should (hehe) use the same definitions as the RFCs - or is
this text non-DFSG-free?

Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


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

Re: debian kernels and APM poweroff

[Henning Glawe]

On Wed, Oct 25, 2006 at 11:01:04AM +0200, Henning Glawe wrote:
> A possible solution is to put
> 
> options apm poweroff
> 

argh. stupid typo. should be:
options apm power_off

-- 
c u
henning


signature.asc
Description: Digital signature

libc6 2.5 and Etch

[Ron Johnson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

Is there any reasonable possibility that it will make it into Etch?

Thanks

- --
Ron Johnson, Jr.
Jefferson LA  USA

Is "common sense" really valid?
For example, it is "common sense" to white-power racists that
whites are superior to blacks, and that those with brown skins
are mud people.
However, that "common sense" is obviously wrong.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFPzAqS9HxQb37XmcRAjgZAKC3dYy5e9XE9wb+K8O2xwh31a808QCglzSs
p+Pmg1YDH9LnaS/HLTayG2w=
=4rrZ
-END PGP SIGNATURE-


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

Re: libc6 2.5 and Etch

[Steinar H. Gunderson]

On Wed, Oct 25, 2006 at 04:36:42AM -0500, Ron Johnson wrote:
> Is there any reasonable possibility that it will make it into Etch?

libc6 is frozen (at 2.3.x -- I assume you mean 2.4, not 2.5?), so no.

/* Steinar */
-- 
Homepage: http://www.sesse.net/


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

Re: libc6 2.5 and Etch

[Martin Michlmayr]

* Ron Johnson <[EMAIL PROTECTED]> [2006-10-25 04:36]:
> Is there any reasonable possibility that it will make it into Etch?

No, of course not.  We cannot put a copletely new and untested libc in
at this point of the release cycle.  In fact, we don't even have 2.4
because there are a number of architectures that still need
LinuxThreads.
-- 
Martin Michlmayr
http://www.cyrius.com/


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

Re: libc6 2.5 and Etch

[Martin Michlmayr]

* Steinar H. Gunderson <[EMAIL PROTECTED]> [2006-10-25 11:48]:
> > Is there any reasonable possibility that it will make it into Etch?
> libc6 is frozen (at 2.3.x -- I assume you mean 2.4, not 2.5?), so no.

2.5 came out a few days ago.
-- 
Martin Michlmayr
http://www.cyrius.com/


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

Re: libc6 2.5 and Etch

[Andreas Barth]

* Ron Johnson ([EMAIL PROTECTED]) [061025 11:37]:
> Is there any reasonable possibility that it will make it into Etch?

No.


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


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

Re: libc6 2.5 and Etch

[Ron Johnson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/25/06 04:53, Martin Michlmayr wrote:
> * Ron Johnson <[EMAIL PROTECTED]> [2006-10-25 04:36]:
>> Is there any reasonable possibility that it will make it into Etch?
> 
> No, of course not.  We cannot put a copletely new and untested libc in
> at this point of the release cycle.

That's what I figured, but 2.5 has been sitting in experimental for
"a while", and I didn't know whether it was just waiting for final
release to be dropped into Sid just before the freeze.

> In fact, we don't even have 2.4
> because there are a number of architectures that still need
> LinuxThreads.

Then how will 2.5 be adopted?

- --
Ron Johnson, Jr.
Jefferson LA  USA

Is "common sense" really valid?
For example, it is "common sense" to white-power racists that
whites are superior to blacks, and that those with brown skins
are mud people.
However, that "common sense" is obviously wrong.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFPzv5S9HxQb37XmcRAisnAKDQg7Tko2ljAZCrHM2nptXzGUMacQCfeLyN
H7JMdWAtz6XSgttmLNATnWA=
=ev7a
-END PGP SIGNATURE-


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

Re: On including 64-bit libs in 32-bit packages (see #344104)

[Goswin von Brederlow]

Matthew Garrett <[EMAIL PROTECTED]> writes:

> Hamish Moffatt <[EMAIL PROTECTED]> wrote:
>
>> That might explain some trouble with X on obscure video chipsets
>> recently reported on debian-amd64 then.
>
> On any architecture other than i386, Xorg builds use the x86emu backend
> rather than the vm86 one. In theory that should let things work happily,
> but there's no guarantee that the x86emu emulation is strictly accurate.

I still get the vm86 warning in dmesg when X starts up on amd64. So it
at least tries to use it directly before falling back.

MfG
Goswin


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

Re: On including 64-bit libs in 32-bit packages (see #344104)

[Goswin von Brederlow]

Matthew Garrett <[EMAIL PROTECTED]> writes:

> Juliusz Chroboczek <[EMAIL PROTECTED]> wrote:
>
>> If I'm reading the function int10LinuxLoadSubModule in
>> os-support/linux/int10/linux.c right, it shouldn't matter.  vm86 will
>> return ENOSYS, which will cause vm86_tst to fail, which will cause the X
>> server to use x86emu instead of vm86.
>> 
>> Or am I missing something?
>
> The x86emu code doesn't get built on i386, does it? It doesn't look like 
> the INT10_VM86 and INT10_X86EMU conditionals can both be set 
> simultaneously.

That would be a reason to write a bug to X about it but not a reason
to exclude 64bit kernels. :)

MfG
Goswin


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

Re: Getting rid of circular dependencies, stage 6

[Goswin von Brederlow]

Frank Küster <[EMAIL PROTECTED]> writes:

> Don Armstrong <[EMAIL PROTECTED]> wrote:
>
>> On Tue, 24 Oct 2006, Petter Reinholdtsen wrote:
>>> [Ian Jackson]
>>> > The only argument I've heard against circular dependencies as a
>>> > general rule is that they can trigger a particularly stupid (and
>>> > probably not very hard to fix) bug in apt,
>>> 
>>> You seem to have missed the argument that packages with circular
>>> dependencies are impossible to install and configure in the correct
>>> (dependency) order, and thus will end up being installed and
>>> configured in a nondeterministic order instead. It is documented
>>> that dpkg try its best to find a sensible order for the packages,
>>> but it is bound to fail one way or another if two packages really do
>>> need each other to be configured before they are configured.
>>
>> Packages which have circular dependencies and depend on the other
>> package being configured are buggy; at most they can depend on the
>> other package being unpacked. Since there is no way to specify this
>> kind of dependency, Depends: is as close as you can get.
>
> It seems to me that the solution in such situation shouldn't be a
> circular dependency with its "nondeterministic" behavior, but instead to
> separate one of the packages into two.  For example if package b needs
> package a unpacked, but not configured, separate package a in a-data and
> a-therest, where a-data provides all that package b needs: Now b can
> depend on a-data, and a-therest can depend on b.
>
> Regards, Frank

You can have an arch:any package and arch:all package that depend on
each other. It can also not make sense to further split them due to
size.

Now say that the depends is only that at usage time some binaries need
shared scripts and the shared scripts need arch specific data (closing
the depends cycle). No dependency is there when configuring. It is
perfectly save for dpkg to break the cycle at any point.

Should there really be a further package split with a few K big
package?


The only problem with such cycles is that apt screws up its ordering
and cycle breaking and sometimes tries to configure A without B, which
dpkg then refuses. Maybe someone should fix apt to use the command-fd
interface to dpkg to get rid of the command line length limit that
causes this random spliting of cycles.

Some cycles are better left as such.

MfG
Goswin


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

Re: First draft of review of policy must usage

[Frank Küster]

Raphael Hertzog <[EMAIL PROTECTED]> wrote:

> I understand we need to make concessions towards a release (like
> concentrating on fixing bugs instead of introducing new major upstream
> changes) but it shouldn't block Debian's progress in all areas.
> You must understand that if Manoj is not fixing the policy, he probably
> won't use that time to fix RC bugs.

That's quite correct, but it seems strange that resynchronizing of two
documents takes place while the group who authored one of them is too
busy to take part in that process.  

I would hope that in this process, not only policy is improved, but also
the release-policy (if not in meaning then at least in wording and
clearness), but we can't expect this to happen right now.

Regards, Frank
-- 
Dr. Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: libc6 2.5 and Etch

[Aurelien Jarno]

Ron Johnson a écrit :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 10/25/06 04:53, Martin Michlmayr wrote:
>> * Ron Johnson <[EMAIL PROTECTED]> [2006-10-25 04:36]:
>>> Is there any reasonable possibility that it will make it into Etch?
>> No, of course not.  We cannot put a copletely new and untested libc in
>> at this point of the release cycle.
> 
> That's what I figured, but 2.5 has been sitting in experimental for
> "a while", and I didn't know whether it was just waiting for final
> release to be dropped into Sid just before the freeze.
> 
>> In fact, we don't even have 2.4
>> because there are a number of architectures that still need
>> LinuxThreads.
> 
> Then how will 2.5 be adopted?
> 

We plan to upload it right after the release of etch.

This version works on all architectures, but m68k, hurd and hppa which
don't have TLS support.

For hppa the work is almost done, I am currently building the packages
(but on a slow machine) to test them.

For m68k and hurd, I have sent a mail to the porters a few months ago, I
haven't received any answer. Maybe we should have to drop those
architectures, at least temporarily.

-- 
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian developer   | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net


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

Re: libc6 2.5 and Etch

[Ron Johnson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/25/06 06:27, Aurelien Jarno wrote:
> Ron Johnson a écrit :
>>
>> On 10/25/06 04:53, Martin Michlmayr wrote:
>>> * Ron Johnson <[EMAIL PROTECTED]> [2006-10-25 04:36]:
[snip]
> For m68k and hurd, I have sent a mail to the porters a few months ago, I
> haven't received any answer. Maybe we should have to drop those
> architectures, at least temporarily.

m68k was dropped from Etch last week. :(

- --
Ron Johnson, Jr.
Jefferson LA  USA

Is "common sense" really valid?
For example, it is "common sense" to white-power racists that
whites are superior to blacks, and that those with brown skins
are mud people.
However, that "common sense" is obviously wrong.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFP2TjS9HxQb37XmcRAudzAJ9ifXc19sv2sRizUNgHxmXfisqMPACfQAhV
NkwEjreLLR0K65wc1+8uuU8=
=p7Gy
-END PGP SIGNATURE-


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

Re: First draft of review of policy must usage

[Margarita Manterola]

On 10/25/06, Manoj Srivastava <[EMAIL PROTECTED]> wrote:


I have replaced some uses of the word must when it was
 intended to be non-normative with alternate and equivalent wording,
 which makes it easier to grep for "must".  This still needs to be
 done for should (which I often replace with 'ought to').


It would be nice to have a comment, footnote or similar thing that
explains the differences between all these indicators:

Something like this:

* must / have to: you have to do this, no matter what.
* should / ought to: it's a very good idea to do this, but in some
special cases you might have a reason not to.

I don't know if these are the meanings intended.  All these verbs
sound the same to me, but it seems they are intended to have different
meanings, and I think it's better to make things as clear as possible.

--
Besos,
Marga


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

Re: First draft of review of policy must usage

[Manoj Srivastava]

On Wed, 25 Oct 2006 09:35:13 +0200, Andreas Barth <[EMAIL PROTECTED]> said: 

> * Manoj Srivastava ([EMAIL PROTECTED]) [061025 08:04]:
>> [...]

> Manoj, I'm seriously asking you if we can delay this discussion
> until after Etch is out. I'm very interessted in takeing part in the
> discussion, but I really have already to many open very urgent tasks
> at my hands.

You do not have to worry about any action being taken on this
 issue; by FTP master action, uploads to policy are now verboten until
 post etch anyway.  Is there any harm in refining the changes and
 building consensus over time? The change document can exist as a
 talking point, and you can still come in and provide us your input
 when you have time (post etch).

manoj
-- 
"I couldn't remember things until I took that Sam Carnegie course."
Bill Peterson, former Houston Oiler football coach
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: First draft of review of policy must usage

[Frank Küster]

Manoj Srivastava <[EMAIL PROTECTED]> wrote:

>  Is there any harm in refining the changes and
>  building consensus over time? The change document can exist as a
>  talking point, and you can still come in and provide us your input
>  when you have time (post etch).

Personally, I would see it as a waste of time to take part in a
discussion in which one of the involved parties is not involved (due to
time constraints).  And that's going to be my last public mail about
this topic...

Regards, Frank
-- 
Dr. Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: First draft of review of policy must usage

[Manoj Srivastava]

On Wed, 25 Oct 2006 10:35:07 -0300, Margarita Manterola <[EMAIL PROTECTED]> 
said: 

> On 10/25/06, Manoj Srivastava <[EMAIL PROTECTED]> wrote:
>> I have replaced some uses of the word must when it was intended to
>> be non-normative with alternate and equivalent wording, which makes
>> it easier to grep for "must".  This still needs to be done for
>> should (which I often replace with 'ought to').

> It would be nice to have a comment, footnote or similar thing that
> explains the differences between all these indicators:

> Something like this:

> * must / have to: you have to do this, no matter what.
> * should / ought to: it's a very good idea to do this, but in some
> special cases you might have a reason not to.

> I don't know if these are the meanings intended.  All these verbs
> sound the same to me, but it seems they are intended to have
> different meanings, and I think it's better to make things as clear
> as possible.

The only normative words are MUST, SHOULD, MAY, and
 RECOMMENDED.  I am considering using upper case where we expect
 conformance.

"ought to" is a phrase used when doing something is a good
 idea, but not doing so does not result in a bug on a
 package. Consider the case when a ftp repository pool contains more
 than one source version of a package.  If you get a diff.gz file from
 one version, and an orig.tar.gz file from another version, the
 results might not be something that builds. 

  As it exists on the FTP site, a Debian source package
- consists of three related files.  You must have the right
+ consists of three related files.  You need to have the right
  versions of all three to be able to use them.


The use of must could have been confusing, changing the phrase
 to you have to tells the user that not following the "get all files
 from the same source version" is a great idea, butif a user does not
 do so, no serious bug needs to be filed :)

manoj
-- 
lisp, v.: To call a spade a thpade.
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: First draft of review of policy must usage

[Luk Claes]

Manoj Srivastava wrote:
> Dear Luk,
> 
> On Wed, 25 Oct 2006 08:16:59 +0200, Luk Claes <[EMAIL PROTECTED]> said: 
> 
>> Manoj Srivastava wrote:
>>> Hi,
> 
>> Hi Manoj
> 
>> Can everyone please focus on the release and discuss things that
>> don't help to release on December 4th at all till after that date?
> 
>> Thank you very much.
> 
> The next time you feel the urge to be patronizing, ponder on
>  these:
>   a) what gives you the right to pontificate and  tell people what to
>  do from your high horse?

Look who's talking...

>   b) Why do you think getting on a soap box is likely to help
>  anything, including  a dialogue on this list?

I don't understand this sentence: 'getting on a soap box'?

>   c) that for some of us doing things right trumps releasing on some
>  arbitrary deadline hands down?

Same for 'trumps' in previous sentence.

> Part of doing things right it to lick the technical policy in
>   shape; reviewing the must directives for bloat has been long
>   overdue. If the policy is so far from reality that release managers
>   do not consider violation of must directives as something that would
>   compromise the high standards of what Debian considers fit for
>   release, then it seems to me we need to fix policy.

You keep putting things in the release managers' mouth... It's not because in
some cases the must in policy isn't considered RC that release managers think
violation of must directives is ok to release with in general...

> Now, if you can stop lecturing and review the changes, and
>  provide feedback on whether my judgement for thechanges is on the
>  right path, you would be helping. If noit, could you please let the
>  rest of us work on getting a better technical policy out? 

I don't like the timing at all. As you said above it's long overdue, so I
don't see why it should happen near release time?

Cheers

Luk

-- 
Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D
Fingerprint:   D5AF 25FB 316B 53BB 08E7   F999 E544 DE07 9B7C 328D



signature.asc
Description: OpenPGP digital signature

Re: First draft of review of policy must usage

[Luk Claes]

Joerg Jaspert wrote:
> On 10818 March 1977, Luk Claes wrote:
> 
>> Can everyone please focus on the release and discuss things that don't help 
>> to
>> release on December 4th at all till after that date?
> 
> No, the release is no reason to stop everything else.
> 

It was not meant that way at all. I just don't like that people start to
discuss topics that are long overdue near release time...

Cheers

Luk

-- 
Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D
Fingerprint:   D5AF 25FB 316B 53BB 08E7   F999 E544 DE07 9B7C 328D



signature.asc
Description: OpenPGP digital signature

Re: First draft of review of policy must usage

[Manoj Srivastava]

On Wed, 25 Oct 2006 16:08:36 +0200, Frank Küster <[EMAIL PROTECTED]> said: 

> Manoj Srivastava <[EMAIL PROTECTED]> wrote:
>> Is there any harm in refining the changes and building consensus
>> over time? The change document can exist as a talking point, and
>> you can still come in and provide us your input when you have time
>> (post etch).

> Personally, I would see it as a waste of time to take part in a
> discussion in which one of the involved parties is not involved (due
> to time constraints).  And that's going to be my last public mail
> about this topic...

I see this as a long process, and by no means do I want to
 exclude any one.  There are a number of low hanging errors that can
 be eliminated before we get to the more complex cases where we need
 to get the input of everyone.

Also, consider the fact that in a project this size, there is
 probably no time that is good enough for every one. By starting the
 refinement now, and taking our time to get it right (I do not have an
 arbitrary deadline before which policy must be fixed and rushed out
 of the door), we are more likely to get a document that is in good
 shape.

If you think you can only participate in the process after
 Etch is released, that is fine. Policy is not going anywhere.

manoj
-- 
You don't move to Edina, you achieve Edina. Guindon
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Getting rid of circular dependencies, stage 6

[Christian Perrier]

> I do think that there is a whift of dogma around the current
>  crusade against all circular dependencies, whther or not the
>  installation phase actually cares about the dependency or not. Oh
>  dear -- have I now offended all Christians?

Well, dunno...:-)

Seriously speaking, I think that any word that could sound rude is,
especially with e-mail, best avoided in arguments. Back to the point:

> 
> > I appreciate the work done by Bill on that issue and I currently do
> > not have the feeling that it is run with the intents you seem to put
> > in the word "jihad".
> 
> One can appreciate work done to reduce un-needed circular
>  dependencies without bying the cool aid that all circular
>  dependencies are bad and must be eliminated at all costs.
> 
> I appreciate the former, I think the latter is a bad idea.


Well, we probably agree on that matter. But my understanding about
this action is that it is not conducted as to eliminate these circular
dependencies at all costs (maybe the "getting rid" is not the best
choice of words for that).

Which indeed, does not yet make it clear to me about what could be
corrected in the circular dependency which console-common is involved
in, anyway.




signature.asc
Description: Digital signature

Re: First draft of review of policy must usage

[Kurt Roeckx]

On Wed, Oct 25, 2006 at 01:03:11AM -0500, Manoj Srivastava wrote:
> Next, I removed clauses that said that all the requirements of
>  policy must be met  for a package to be in main or contrib; we know
>  that is not true.
> 
> I have replaced some uses of the word must when it was
>  intended to be non-normative with alternate and equivalent wording,
>  which makes it easier to grep for "must".  This still needs to be
>  done for should (which I often replace with 'ought to').

So, you changes some things from must to needs, because we don't
consider them RC anymore.  But then also remove the requirement 
to comply with the policy for us to distribute it?

I think you're trying to do the same thing twice.  I don't think we
should remove the requirement to comply with all the requirements.

> @@ -986,7 +891,7 @@
> particular version of that package.
>  
>Essential is defined as the minimal set of functionality
> -  that must be available and usable on the system even
> +  that have to be available and usable on the system even
>when packages are in an unconfigured (but unpacked)
>state.  This is needed to avoid unresolvable dependency
>loops on upgrade.  If packages add unnecessary

Why do you downgrade this?  Maybe this should be reworded though.

This seems to be the only place in the policy that says that an
essential package must have all it's functionality when it's in an
unpackaged state.  I think that should atleast be moved to the part
about essential (3.8) instead of a footnote about Dependencies.


> @@ -1931,7 +1848,7 @@
>  
>   
> The build, binary and
> -   clean targets must be invoked with the current
> +   clean targets need to be invoked with the current
> directory being the package's top-level directory.
>   
>  

I don't see why you want to change that.  I think packages rely on it
that it's called with a proper current working directory.

> @@ -3195,8 +3112,8 @@
>  
>Additionally, packages interacting with users using
>debconf in the postinst script should
> -  install a config script  in the control area,
> -  see  for details.
> +  usually install a config script in the control
> +  area, see  for details.
>  
>  
>   

You seem to have changed "should" to "should usually", and I don't
see what the real difference is.

>
> - Packages involving shared libraries should be split up into
> + Packages involving shared libraries ought to be split up into
>   several binary packages. This section mostly deals with how
>   this separation is to be accomplished; rules for files within
> - the shared library packages are in  instead.
> + the shared library packages are in 
> + instead.
>
>  
>

I think the "should" there was good.

> @@ -4722,7 +4640,7 @@
>  
>   
> If a package contains a binary or library which links to a
> -   shared library, we must ensure that when the package is
> +   shared library, we have to ensure that when the package is
> installed on the system, all of the libraries needed are
> also installed.  This requirement led to the creation of the
> shlibs system, which is very simple in its design:

I have no idea why you want to change that.  If it's linked to a shared
library, it really needs that library and won't work without it.  So
this should be a "must".

Also, if you really want to change that, you might want to change the
"This requirement" too.

> @@ -4748,7 +4666,7 @@
> determined by calling ldd, but now
> objdump is used to do this.  The only
> change this makes to package building is that
> -   dpkg-shlibdeps must also be run on shared
> +   dpkg-shlibdeps also has to be run on shared
> libraries, whereas in the past this was unnecessary.
> The rest of this footnote explains the advantage that
> this method gives.

It really must be run on it, or things will break.

> @@ -4865,7 +4783,7 @@
>   determine whether foo-prog's library
>   dependencies are satisfied by any of the libraries
>   provided by libfoo2.  For this reason,
> - dpkg-shlibdeps must only be run once
> + dpkg-shlibdeps has to be run only once
>   all of the individual binary packages'
>   shlibs files have been installed into the
>   build directory.

If you remove that requirement, I think you need to another one.
foo-runtime really needs to have a dependency on libfoo2, one way or
another.

> @@ -6736,10 +6654,10 @@
> the LSB anyway.
> 
> Thus, shell scripts specifying /bin/sh as
> -   interpreter must only use POSIX features

Re: First draft of review of policy must usage

[Manoj Srivastava]

On Wed, 25 Oct 2006 18:51:26 +0200, Luk Claes <[EMAIL PROTECTED]> said: 

> Joerg Jaspert wrote:
>> On 10818 March 1977, Luk Claes wrote:
>> 
>>> Can everyone please focus on the release and discuss things that
>>> don't help to release on December 4th at all till after that date?
>> 
>> No, the release is no reason to stop everything else.
>> 

> It was not meant that way at all. I just don't like that people
> start to discuss topics that are long overdue near release time...

In a project this size, not all activities come to a dead end
 every couple of years for a few months. Consistent with releasing,
 activities geared towards improving the infrastructure, subsystems,
 and packages can and should still be on going.

The reason I have initiated this at this point is that I was
 not aware that policy is perceived to be so far out of whack with the
 project processes that violations of MUST directives in policy are
 considered to be unrelated to bugs serious enough to warrant
 fixing -- and that policy directives linking ciolations to bug
 severities are now considered an unreported bug in policy itself.

I realized that there never has been a comprehensive review
 of the MUST/SHOULD/MAY  dictums in policy, and also, policy has grown
 organically, since until recently there was no single cohesive
 editor -- the old piecemeal approach of any small group of developers
 just adding language for each policy change leads to a disjoint,
 incoherent document. It is about time we started looking at policy
 holistically.  That was the trigger.

Also, consider the fact that we are all (for the most part),
 volunteers.  there a re number of demands on our time. Real life
 intervenes. Private and pet projects go hot or cold. the release
 process is just one such drain on our timel but there are others.
 For a process like a broad review of policy, where one needs to get
 the buy in and eye balls of a large group of developers, it is
 impossible to pick a time that is convenient for every one.

Unlike Etch, there is no pressing directive that policy review
 be all done by Dec 4rth; we can and should take our time and do
 this _right_.  Correctness and completeness should be preferred over
 speed at this point.

manoj
-- 
"Can you program?"  "Well, I'm literate, if that's what you mean!"
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: libc6 2.5 and Etch

[Felipe Augusto van de Wiel (faw)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/25/2006 11:21 AM, Ron Johnson wrote:
> On 10/25/06 06:27, Aurelien Jarno wrote:
> 
>>>Ron Johnson a écrit :
>>>
On 10/25/06 04:53, Martin Michlmayr wrote:

>* Ron Johnson <[EMAIL PROTECTED]> [2006-10-25 04:36]:
> 
> [snip]
> 
>>>For m68k and hurd, I have sent a mail to the porters a few months ago, I
>>>haven't received any answer. Maybe we should have to drop those
>>>architectures, at least temporarily.
> 
> 
> m68k was dropped from Etch last week. :(

But I hope it is going to be back for etch+1. :-)


Kind regards,

- --
Felipe Augusto van de Wiel (faw)
"Debian. Freedom to code. Code to freedom!"
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Debian - http://enigmail.mozdev.org

iD8DBQFFP5zeCjAO0JDlykYRAo6CAKCkkNr4GhTfd0X44ORaJ1V1youQBACeOWTg
TFl/0VOFZbRuyrBc3a6xuTA=
=CfOA
-END PGP SIGNATURE-


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

Re: First draft of review of policy must usage

[Manoj Srivastava]

On Wed, 25 Oct 2006 20:01:32 +0200, Kurt Roeckx <[EMAIL PROTECTED]> said: 

> On Wed, Oct 25, 2006 at 01:03:11AM -0500, Manoj Srivastava wrote:
>> Next, I removed clauses that said that all the requirements of
>> policy must be met for a package to be in main or contrib; we know
>> that is not true.
>> 
>> I have replaced some uses of the word must when it was intended to
>> be non-normative with alternate and equivalent wording, which makes
>> it easier to grep for "must".  This still needs to be done for
>> should (which I often replace with 'ought to').

> So, you changes some things from must to needs, because we don't
> consider them RC anymore.  But then also remove the requirement to
> comply with the policy for us to distribute it?

> I think you're trying to do the same thing twice.  I don't think we
> should remove the requirement to comply with all the requirements.

Well, we know that packages are in Debian that do not comply
 with all directives in policy right now. The wording is poor -- 'all
 directives; include SHOULD and MAY as well, and we don not throw
 packages out of Debian (or even a stable release) based on even MUST
 criteria -- so those bits in policy are just plain wrong.

> @@ -986,7 +891,7 @@
> particular version of that package.
>  
>Essential is defined as the minimal set of functionality
> -  that must be available and usable on the system even
> +  that have to be available and usable on the system even
>when packages are in an unconfigured (but unpacked)
>state.  This is needed to avoid unresolvable dependency
>loops on upgrade.  If packages add unnecessary

> Why do you downgrade this?  Maybe this should be reworded though.

This is a foto note. Foot notes are not normative.

> This seems to be the only place in the policy that says that an
> essential package must have all it's functionality when it's in an
> unpackaged state.  I think that should atleast be moved to the part
> about essential (3.8) instead of a footnote about Dependencies.

I think there is language elsewhere about that, though.

> @@ -1931,7 +1848,7 @@
>  
>   
> The build, binary and
> -   clean targets must be invoked with the current
> +   clean targets need to be invoked with the current
> directory being the package's top-level directory.
>   
>  

> I don't see why you want to change that.  I think packages rely on
> it that it's called with a proper current working directory.

This is advice to the user, and thus not a normative directive
 for packaging.


> @@ -3195,8 +3112,8 @@
>  
>Additionally, packages interacting with users using
>debconf in the postinst script should
> -  install a config script  in the control area,
> -  see  for details.
> +  usually install a config script in the control
> +  area, see  for details.
>  
>  
>   

> You seem to have changed "should" to "should usually", and I don't
> see what the real difference is.

Not all packages have to install config files or be buggy --
 for example, packages that only ask questions based on information
 available only after unpacking, for instance. Such packages may or
 may not ask questions, and the question they ask may need values
 gathered by programs that are contained in the package itself. In
 this case, there can be no config file -- and all the questions are
 conditionally asked in the postinst.

Since this is not the default, I use the term "should usually"
 provide.  not an unconditional should provide.

>
> - Packages involving shared libraries should be split up into
> + Packages involving shared libraries ought to be split up into
>   several binary packages. This section mostly deals with how
>   this separation is to be accomplished; rules for files within
> - the shared library packages are in  instead.
> + the shared library packages are in 
> + instead.
>
>  
>

> I think the "should" there was good.

This is something I want to discuss further. Consider the case
 where there is a package with a set of, say, 20 binaries with a lot
 of common code, and upstream decided to abstract it out into a shared
 lib. This is a shred lib used by anyone else, and it is changing
 rapidly enough that there is the equivalent of a soname change on
 every upload. There is no interest in supporting older versions, or
 even having multiple versions of that lib. In this case, either we
 can make packaging that software hard (since moving the lib out of
 /usr/lib etc may involve some work), or we allow some packages to
 include share libs in the package.

I don't know which way one should lean, so I decided to go the
 route of fewer bugs.


> @@ -4722,7 +4640,7 @@
>  
>   
> If a package contain

Re: First draft of review of policy must usage

[Kurt Roeckx]

On Wed, Oct 25, 2006 at 01:49:03PM -0500, Manoj Srivastava wrote:
> >
> > -   Packages involving shared libraries should be split up into
> > +   Packages involving shared libraries ought to be split up into
> > several binary packages. This section mostly deals with how
> > this separation is to be accomplished; rules for files within
> > -   the shared library packages are in  instead.
> > +   the shared library packages are in 
> > +   instead.
> >
> >  
> >
> 
> > I think the "should" there was good.
> 
> This is something I want to discuss further. Consider the case
>  where there is a package with a set of, say, 20 binaries with a lot
>  of common code, and upstream decided to abstract it out into a shared
>  lib. This is a shred lib used by anyone else, and it is changing
>  rapidly enough that there is the equivalent of a soname change on
>  every upload. There is no interest in supporting older versions, or
>  even having multiple versions of that lib. In this case, either we
>  can make packaging that software hard (since moving the lib out of
>  /usr/lib etc may involve some work), or we allow some packages to
>  include share libs in the package.
> 
> I don't know which way one should lean, so I decided to go the
>  route of fewer bugs.

If it's not supposed to be used by an other package, it should be moved
to /usr/lib/package/.  If it doesn't contain any other libraries in
/usr/lib, it shouldn't provide a -dev package.  So there really isn't a
need for a seperate lib package either.

Anyway, that's why it says "should" in the first place, and I don't see
why it needs to be changed.


Kurt


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

Re: First draft of review of policy must usage

[Luk Claes]

Manoj Srivastava wrote:
> On Wed, 25 Oct 2006 18:51:26 +0200, Luk Claes <[EMAIL PROTECTED]> said: 
> 
>> Joerg Jaspert wrote:
>>> On 10818 March 1977, Luk Claes wrote:
>>>
 Can everyone please focus on the release and discuss things that
 don't help to release on December 4th at all till after that date?
>>> No, the release is no reason to stop everything else.
>>>
> 
>> It was not meant that way at all. I just don't like that people
>> start to discuss topics that are long overdue near release time...
> 
> In a project this size, not all activities come to a dead end
>  every couple of years for a few months. Consistent with releasing,
>  activities geared towards improving the infrastructure, subsystems,
>  and packages can and should still be on going.

Indeed, though starting such discussions near release time is unfortunate at
the least...

> The reason I have initiated this at this point is that I was
>  not aware that policy is perceived to be so far out of whack with the
>  project processes that violations of MUST directives in policy are
>  considered to be unrelated to bugs serious enough to warrant
>  fixing -- and that policy directives linking ciolations to bug
>  severities are now considered an unreported bug in policy itself.

I rather see policy as a guideline for long term compliance, but the etch RC
policy for short term compliance. Of course there are some bugs in policy and
it's indeed a good idea to review the consitency, but I think you overreact
when you say that must directives in policy are unrelated to serious bugs...

> Also, consider the fact that we are all (for the most part),
>  volunteers.  there a re number of demands on our time. Real life
>  intervenes. Private and pet projects go hot or cold. the release
>  process is just one such drain on our timel but there are others.

Right, though a release should be a common goal. It should be a joined effort...

>  For a process like a broad review of policy, where one needs to get
>  the buy in and eye balls of a large group of developers, it is
>  impossible to pick a time that is convenient for every one.

Sure, but that's something else than not a really good time for anyone...

> Unlike Etch, there is no pressing directive that policy review
>  be all done by Dec 4rth; we can and should take our time and do
>  this _right_.  Correctness and completeness should be preferred over
>  speed at this point.

This is true for release work too, but the time between releases should be
manageable. If we release on Dec 4th with nasty bugs, I'd rather have we
release at middle or end of december without these nasty bugs...

Sorry if my message came across too harsh, but I do think quality of the
release is more important than quality of the policy at the moment and not
only because I'm on the release team, but because I as a user want to still be
proud to be part of Debian after Dec 4th :-)

Cheers

Luk

-- 
Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D
Fingerprint:   D5AF 25FB 316B 53BB 08E7   F999 E544 DE07 9B7C 328D



signature.asc
Description: OpenPGP digital signature

Re: First draft of review of policy must usage

[Roland Mas]

Luk Claes, 2006-10-25 18:51:26 +0200 :

> It was not meant that way at all. I just don't like that people
> start to discuss topics that are long overdue near release time...

Topics that are long overdue should, by definition, be discussed and
worked on *now*, regardless of whether "now" happens to be (presented
as) close to release time.

Roland.
-- 
Roland Mas

LinkedIn profile: http://www.linkedin.com/in/rolandmas


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

Re: First draft of review of policy must usage

[Andreas Barth]

* Roland Mas ([EMAIL PROTECTED]) [061025 22:38]:
> Luk Claes, 2006-10-25 18:51:26 +0200 :
> 
> > It was not meant that way at all. I just don't like that people
> > start to discuss topics that are long overdue near release time...
> 
> Topics that are long overdue should, by definition, be discussed and
> worked on *now*, regardless of whether "now" happens to be (presented
> as) close to release time.

Changing the release policy is obviously a non-possibility now.


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


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

Re: Bug mass filling

[Steve Langasek]

On Wed, Oct 25, 2006 at 01:48:02AM -0400, Kevin Mark wrote:
> Are you suggesting that each package can have a related list of
> non-transient bugs that should be marked (with a new tags called )
> ignore-this-policy-violation where this can be attached to any package
> related bug for any length of time until the issues is deemed
> worthy/necessary to be addressed?

No.  Why would anyone want this when downgrading these bugs to "important"
has the same effect in all respects and doesn't require changing code in 20
different places to account for a change in semantics?

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


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

Re: Getting rid of circular dependencies, stage 6

[Steve Langasek]

On Wed, Oct 25, 2006 at 02:18:44AM -0500, Manoj Srivastava wrote:
> > I appreciate the work done by Bill on that issue and I currently do
> > not have the feeling that it is run with the intents you seem to put
> > in the word "jihad".

> One can appreciate work done to reduce un-needed circular
>  dependencies without bying the cool aid that all circular
>  dependencies are bad and must be eliminated at all costs.

> I appreciate the former, I think the latter is a bad idea.

FWIW, I think this is very much like turning on -Wall -Werror when
compiling.  It will complain about things which aren't errors, but,
*because they are not mechanically distinguishable from things that are
errors*, they should be reported anyway.

Removing a non-buggy circular dependency may be worthwhile for the same
reason fixing non-bug compiler warnings may be worthwhile -- so that the
real bugs aren't drowned out by the noise.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


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

Re: Bug mass filling

[Manoj Srivastava]

On Wed, 25 Oct 2006 09:31:42 +0200, Andreas Barth <[EMAIL PROTECTED]> said: 

> * Manoj Srivastava ([EMAIL PROTECTED]) [061024 23:53]:
>> If you are aware of issues that are violations of muSt directives
>> that are never going to be RC, there should be a bug opened on
>> policy with severity important for every one of them.

> I hope to have time post-etch-release to do that (that is what I
> meant with "syncing between policy and release-policy").

Thanks. Your input shall be appreciated -- in the mean while,
 those of us with time and the inclination  can work on fixing the low
 hanging errors, so you may find your work later reduced a bit.

manoj
-- 
The more complex the mind, the greater the need for the simplicity of
play. Kirk, "Shore Leave", stardate 3025.8
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: First draft of review of policy must usage

[Manoj Srivastava]

On Wed, 25 Oct 2006 22:39:14 +0200, Andreas Barth <[EMAIL PROTECTED]> said: 

> * Roland Mas ([EMAIL PROTECTED]) [061025 22:38]:
>> Luk Claes, 2006-10-25 18:51:26 +0200 :
>> 
>> > It was not meant that way at all. I just don't like that people
>> > start to discuss topics that are long overdue near release
>> > time...
>> 
>> Topics that are long overdue should, by definition, be discussed
>> and worked on *now*, regardless of whether "now" happens to be
>> (presented as) close to release time.

> Changing the release policy is obviously a non-possibility now.

Quite so.  But getting a handle on policy flaws and creating a
 list of issues that need clarification can start now -- assuming, of
 course, that the people working on this do not let it hamper their
 efforts directed at improving release quality.

manoj
-- 
No question is so difficult as one to which the answer is obvious.
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: cmake build-depends

[Enrico Zini]

On Mon, Oct 23, 2006 at 01:43:56PM +0200, Fathi Boudra wrote:

> we have a cmake class, proposed for inclusion in cdbs:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=377524
> I use it at least on strigi and kde4 packages.

Dunno if it's the same, but I have one that is working on libwibble-dev
and libept-dev.


Ciao,

Enrico

-- 
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Is something wrong to XGL, Compiz, Cgwd be packaged?

[eduardo.oliva barruzi]

Hi, I just wanna know if there are any problems regarding the License or something else that make these packages actually unavailable?
 
Thanks

Re: Is something wrong to XGL, Compiz, Cgwd be packaged?

[Ron Johnson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/25/06 18:50, eduardo.oliva barruzi wrote:
> Hi, I just wanna know if there are any problems regarding the License or
> something else that make these packages actually unavailable?

$ wajig policy compiz
compiz:
  Installed: (none)
  Candidate: 0.2.0-1
  Version table:
 0.2.0-1 0
500 ftp://mirrors.kernel.org unstable/main Packages


- --
Ron Johnson, Jr.
Jefferson LA  USA

Is "common sense" really valid?
For example, it is "common sense" to white-power racists that
whites are superior to blacks, and that those with brown skins
are mud people.
However, that "common sense" is obviously wrong.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFP/spS9HxQb37XmcRAhL5AJ9xLTGp3uaSNkaZlB/2BHbH8G6roACg0Ytq
45Ri+C+lC/0yDFG8U1muQbo=
=7nSZ
-END PGP SIGNATURE-


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

Re: openssh packages with updated selinux patch

[Frans Pop]

On Tuesday 24 October 2006 23:18, Manoj Srivastava wrote:
> Either of these would be fine (though looking at the size of
>  libselinux1, I wonder if there are any numbers behind  the burden
>  theory?), but that would be a more intrusive change for openssh than
>  I am willing to make as a non-maintainer at this stage of the game.

We don't need any "numbers". The installer runs fully in memory, sometimes 
on systems with very little memory, and a lot of it runs before swap 
is/can be enabled. This means that _every_ byte is worth saving.

Call it a design goal.

Cheers,
FJP


pgp8UvXF83xpQ.pgp
Description: PGP signature

Re: First draft of review of policy must usage

[Anthony Towns]

On Wed, Oct 25, 2006 at 09:20:34AM -0500, Manoj Srivastava wrote:
> The only normative words are MUST, SHOULD, MAY, and
>  RECOMMENDED.  I am considering using upper case where we expect
>  conformance.

Didn't the definitions of MUST/SHOULD/MAY get removed in your patch though?

Cheers,
aj



signature.asc
Description: Digital signature

Re: First draft of review of policy must usage

[Kevin Mark]

On Wed, Oct 25, 2006 at 10:39:14PM +0200, Andreas Barth wrote:
> * Roland Mas ([EMAIL PROTECTED]) [061025 22:38]:
> > Luk Claes, 2006-10-25 18:51:26 +0200 :
> > 
> > > It was not meant that way at all. I just don't like that people
> > > start to discuss topics that are long overdue near release time...
> > 
> > Topics that are long overdue should, by definition, be discussed and
> > worked on *now*, regardless of whether "now" happens to be (presented
> > as) close to release time.
> 
> Changing the release policy is obviously a non-possibility now.
> 
Hi,
there is the policy manual and release policy. Is not Manoj discussing
changes to the former?  if the policy manual is in a document
repositories, anyone can reference a certain version from the past as
applying to release policy while changes are introduced.
cheers,
Kev
-- 
|  .''`.  == Debian GNU/Linux == |   my web site:   |
| : :' :  The  Universal | debian.home.pipeline.com |
| `. `'  Operating System| go to counter.li.org and |
|   `-http://www.debian.org/ |be counted! #238656   |
| my keysever: pgp.mit.edu   | my NPO: cfsg.org |


signature.asc
Description: Digital signature

Re: libc6 2.5 and Etch

[Kevin Mark]

On Wed, Oct 25, 2006 at 08:21:39AM -0500, Ron Johnson wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 10/25/06 06:27, Aurelien Jarno wrote:
> > Ron Johnson a écrit :
> >>
> >> On 10/25/06 04:53, Martin Michlmayr wrote:
> >>> * Ron Johnson <[EMAIL PROTECTED]> [2006-10-25 04:36]:
> [snip]
> > For m68k and hurd, I have sent a mail to the porters a few months ago, I
> > haven't received any answer. Maybe we should have to drop those
> > architectures, at least temporarily.
> 
> m68k was dropped from Etch last week. :(
> 
When Sarge was released, amd64 was not officially released but had an
unofficial release. why not do the same with the hopes tha etch+1 will
see m68k in relase shape?
-- 
|  .''`.  == Debian GNU/Linux == |   my web site:   |
| : :' :  The  Universal | debian.home.pipeline.com |
| `. `'  Operating System| go to counter.li.org and |
|   `-http://www.debian.org/ |be counted! #238656   |
| my keysever: pgp.mit.edu   | my NPO: cfsg.org |


signature.asc
Description: Digital signature

Re: First draft of review of policy must usage

[Steve Langasek]

On Wed, Oct 25, 2006 at 01:49:03PM -0500, Manoj Srivastava wrote:
> > @@ -3195,8 +3112,8 @@
> >  
> >Additionally, packages interacting with users using
> >debconf in the postinst script should
> > -  install a config script  in the control area,
> > -  see  for details.
> > +  usually install a config script in the control
> > +  area, see  for details.
> >  
> >  
> > 

> > You seem to have changed "should" to "should usually", and I don't
> > see what the real difference is.

> Not all packages have to install config files or be buggy --
>  for example, packages that only ask questions based on information
>  available only after unpacking, for instance. Such packages may or
>  may not ask questions, and the question they ask may need values
>  gathered by programs that are contained in the package itself. In
>  this case, there can be no config file -- and all the questions are
>  conditionally asked in the postinst.

> Since this is not the default, I use the term "should usually"
>  provide.  not an unconditional should provide.

However, I think it's important that policy outline those cases in which
it's not a bug to omit a .config script.  Doesn't the absence of the .config
script require additional by-hand handling of the templates which is
otherwise done automatically through apt?

> >
> > -   Packages involving shared libraries should be split up into
> > +   Packages involving shared libraries ought to be split up into
> > several binary packages. This section mostly deals with how
> > this separation is to be accomplished; rules for files within
> > -   the shared library packages are in  instead.
> > +   the shared library packages are in 
> > +   instead.
> >
> >  
> >

> > I think the "should" there was good.

> This is something I want to discuss further. Consider the case
>  where there is a package with a set of, say, 20 binaries with a lot
>  of common code, and upstream decided to abstract it out into a shared
>  lib. This is a shred lib used by anyone else, and it is changing
>  rapidly enough that there is the equivalent of a soname change on
>  every upload. There is no interest in supporting older versions, or
>  even having multiple versions of that lib. In this case, either we
>  can make packaging that software hard (since moving the lib out of
>  /usr/lib etc may involve some work), or we allow some packages to
>  include share libs in the package.

This tells me that the guidelines for when shared library packages must be
split up are still ill-defined in some corner cases.  I don't think we
should be gutting such an important requirement from policy just because
there may be corner cases that need sorting, when the cost of non-compliance
with this requirement is so high.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


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

Re: Getting rid of circular dependencies, stage 6

[Manoj Srivastava]

On Wed, 25 Oct 2006 01:43:34 -0700, Steve Langasek <[EMAIL PROTECTED]> said: 

> On Wed, Oct 25, 2006 at 02:18:44AM -0500, Manoj Srivastava wrote:
>> > I appreciate the work done by Bill on that issue and I currently
>> > do not have the feeling that it is run with the intents you seem
>> > to put in the word "jihad".

>> One can appreciate work done to reduce un-needed circular
>> dependencies without bying the cool aid that all circular
>> dependencies are bad and must be eliminated at all costs.

>> I appreciate the former, I think the latter is a bad idea.

> FWIW, I think this is very much like turning on -Wall -Werror when
> compiling.  It will complain about things which aren't errors, but,
> *because they are not mechanically distinguishable from things that
> are errors*, they should be reported anyway.

> Removing a non-buggy circular dependency may be worthwhile for the
> same reason fixing non-bug compiler warnings may be worthwhile -- so
> that the real bugs aren't drowned out by the noise.

In both cases, I am all for stripping the low hanging
 fruit. But if a circular dependency normally exits, I am suggesting
 we keep an eye on the contortions required to remove the dependency
 loop. For some cases, it might not be worth the effort -- some times
 the cure for the noise is worse than the noise itself.

manoj
-- 
Genius is ten percent inspiration and fifty percent capital gains.
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: First draft of review of policy must usage

[Manoj Srivastava]

On Wed, 25 Oct 2006 19:44:38 -0700, Steve Langasek <[EMAIL PROTECTED]> said: 

> On Wed, Oct 25, 2006 at 01:49:03PM -0500, Manoj Srivastava wrote:
>> > @@ -3195,8 +3112,8 @@
>> >  
>> >Additionally, packages interacting with users using
>> >debconf in the postinst script
>> >should
>> > - install a config script in the control area,
>> > - see  for details.
>> > + usually install a config script in the control
>> > + area, see  for details.
>> >  
>> >  
>> >

>> > You seem to have changed "should" to "should usually", and I
>> > don't see what the real difference is.

>> Not all packages have to install config files or be buggy -- for
>> example, packages that only ask questions based on information
>> available only after unpacking, for instance. Such packages may or
>> may not ask questions, and the question they ask may need values
>> gathered by programs that are contained in the package itself. In
>> this case, there can be no config file -- and all the questions are
>> conditionally asked in the postinst.

>> Since this is not the default, I use the term "should usually"
>> provide.  not an unconditional should provide.
 
> However, I think it's important that policy outline those cases in
> which it's not a bug to omit a .config script.

I don't think I know _all_ use cases in which it is ok not to
 add a .config file. I can provide a few use cases. I think the reader
 should be allowed to make their own judgement calls, in case they
 have a use case we might miss.

> Doesn't the absence of the .config script require additional by-hand
> handling of the templates which is otherwise done automatically
> through apt?

No. From debconf-devel (7):
,
|  A question is an instantiated template. By asking debconf to display  a
|  question,  your  config script can interact with the user. When debconf
|  loads a templates file (this happens  whenever  a  config  or  postinst
|  script is run), it automatically instantiates a question from each tem‐
|  plate. It is actually possible to instantiate several independent ques‐
|  tions  from the same template (using the REGISTER command), but that is
|  rarely necessary. 
`


>> >
>> > - Packages involving shared libraries should be split up into
>> > + Packages involving shared libraries ought to be split up into
>> >several binary packages. This section mostly deals with how
>> >this separation is to be accomplished; rules for files within
>> > - the shared library packages are in 
>> >instead.
>> > + the shared library packages are in 
>> > + instead.
>> >
>> >  
>> >

>> > I think the "should" there was good.

>> This is something I want to discuss further. Consider the case
>> where there is a package with a set of, say, 20 binaries with a lot
>> of common code, and upstream decided to abstract it out into a
>> shared lib. This is a shred lib used by anyone else, and it is
>> changing rapidly enough that there is the equivalent of a soname
>> change on every upload. There is no interest in supporting older
>> versions, or even having multiple versions of that lib. In this
>> case, either we can make packaging that software hard (since moving
>> the lib out of /usr/lib etc may involve some work), or we allow
>> some packages to include share libs in the package.

> This tells me that the guidelines for when shared library packages
> must be split up are still ill-defined in some corner cases.  I
> don't think we should be gutting such an important requirement from
> policy just because there may be corner cases that need sorting,
> when the cost of non-compliance with this requirement is so high.

Making a SHOULD directive a suggestion is hardly what I call
 gutting. However, since this is one area I was fuzzy about, and now I
 have seen two strong negative reactions, and none in favour, this
 seems like something that may be reverted.

manoj
-- 
"The Nazis have no sense of humor, so why should they want
television?" Philip K. Dick
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: First draft of review of policy must usage

[Manoj Srivastava]

On Thu, 26 Oct 2006 10:44:53 +1000, Anthony Towns  
said: 

> On Wed, Oct 25, 2006 at 09:20:34AM -0500, Manoj Srivastava wrote:
>> The only normative words are MUST, SHOULD, MAY, and RECOMMENDED.  I
>> am considering using upper case where we expect conformance.

> Didn't the definitions of MUST/SHOULD/MAY get removed in your patch
> though?

It did in the first draft. Based on feedback, a modified
 version was re-introduced in the second draft, which ought to meet
 the flexibility requirements mentioned by the release managers.

manoj
-- 
Backed up the system lately?
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: libc6 2.5 and Etch

[Warren Turkal]

On Wednesday 25 October 2006 20:42, Kevin Mark wrote:
> When Sarge was released, amd64 was not officially released but had an
> unofficial release. why not do the same with the hopes tha etch+1 will
> see m68k in relase shape?

AMD64 is a modern architecture. M68k is an architecture that saw its prime 
many years ago. AMD64 also has a much larger user base considering that most 
of the m68k machines I know of are more toys than workhorses. Also, I think it 
could be that the Debian folks saw a strategic advantage is shipping a more 
normal version of Debian for the AMD64 arch.

wt
-- 
Warren Turkal


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

Getting package build dependencies

[Ross Boylan]

I am interested in getting build-dependencies for a source package on
a system using aptitude.  In the past I've used apt-get build-dep, but
that was on systems managed with apt-get.  I think aptitude won't know
about apt-get's selections, and may toss the packages at the first
chance (or perhaps get confused in some other way).

Is this analysis correct?  If so, is there a good solution?

The two other routes I see are to use dpkg-checkbuilddeps (but then I
still need to get the output into aptitude) or to use one of the
autobuilders that work in a chroot (which seems kind of heavy weight).

Thanks.

Ross Boylan

cc's appreciated.

P.S. apt-get build-dep has always made me a bit uncomfortable, since I
presume it goes by the installed binary package.  If you want to build
some other version (e.g., system is testing but you want to build
unstable) the dependencies aren't necessarily quite right.  So I'd be
happy to discover an alternative.


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