Re: Debian should not modify the kernels!

[Andreas Barth]

* Russell Coker ([EMAIL PROTECTED]) [030921 16:41]:
> Bad analogy.  Consider the way that the Harry Potter books have been modified 
> for the limited vocabulary of the American audience.

I hope that you're joking. (Well, I fear that you're not.)


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C

Re: Debian should not modify the kernels!

[martin f krafft]

also sprach Matthew Garrett <[EMAIL PROTECTED]> [2003.09.21.1614 +0200]:
> >FWIW, I basically agree. "goodies" are welcome, but backporting
> >things from the unstable branch migh= t not be that good idea.
> 
> Should we stop shipping security fixes backported from development
> code?

It always depends, doesn't it? We are backporting *security* fixes
to packages, but we take care not to introduce new features. I don't
oppose some small modifications to the kernel, fixes and security
backports, but including a 2.5 IPsec stack in 2.4.21 is kinda not in
accordance with that policy, now is it?

-- 
Please do not CC me when replying to lists; I read them!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer, admin, and user
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!


pgpM0WSZYEzOX.pgp
Description: PGP signature

Re: Debian should not modify the kernels!

[martin f krafft]

also sprach Mark Brown <[EMAIL PROTECTED]> [2003.09.21.1644 +0200]:
> This is very standard practice for distribution kernels.  It's
> fairly rare for users to notice negative effects and the positive
> effects (better hardware support, more features, better
> performance or what have we) are generally seen to be worthwhile.

... in addition to possibly more bugs and the inability of
interaction with the kernel and the rest of the world. linux-kernel
can not help you anymore, as you don't run the linux kernel anymore,
and third-party software may just fail.

I am not saying that all this shouldn't happen. I am just saying it
shouldn't be the default. Debian is about choice, isn't it? Well,
opt-in choice it should be!

-- 
Please do not CC me when replying to lists; I read them!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer, admin, and user
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!


pgpQ6krB4s05F.pgp
Description: PGP signature

Re: Debian should not modify the kernels!

[martin f krafft]

also sprach Domenico Andreoli <[EMAIL PROTECTED]> [2003.09.21.1647 +0200]:
> which features should be removed from grsec in order to make it
> patch the debian kernel?

IP randomisation, and there might well me more. This is where
I stopped.

-- 
Please do not CC me when replying to lists; I read them!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer, admin, and user
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!


pgpUoAAuYMa2b.pgp
Description: PGP signature

Bug#211991: ITP: libcamomile-ocaml-dev -- Unicode for OCaml

[Sylvain LE GALL]

Package: wnpp
Version: unavailable; reported 2003-09-21
Severity: wishlist


* Package name: libcamomile-ocaml-dev
  Version : 0.4.1
  Upstream Author : Yamagata Yoriyuki <[EMAIL PROTECTED]>
* URL : http://camomile.sourceforge.net/
* License : LGPL
  Description : Unicode for OCaml

Camomile is a comprehensive Unicode library for OCaml

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux grand 2.4.22 #3 sam sep 13 02:31:10 CEST 2003 i686
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED]

Re: Debian should not modify the kernels!

[John Hasler]

Andi writes:
> I hope that you're joking. (Well, I fear that you're not.)

It's not the American audience that has the limited vocabulary.  It's the
American publisher.
-- 
John Hasler
[EMAIL PROTECTED] (John Hasler)
Dancing Horse Hill
Elmwood, WI

Fw: coIIege naive girIs ready for H/\RD /\CTlON jBk LwO N F oV ZRE Akwya

[Pybofob]

Title: ctzgu DI


things do happen.  world OFFBEAT Open your
ïðèâåò in 1929 AtQ and make them better?XOpJ nlTNKLw the blackout Lovely day
Religion divides  in 1831  First or standart class? in 1953 It's nice

Fw: coIIege naive girIs ready for H/\RD /\CTlON Abt KNn Z z EH NqH fcBBd

[Pawisuhov]

Title: mKpTo MZ


in 1906  Small world! in 1845
Don't get excited! to sign here qJU in 1888 vagx tbTtTUg Take it easy! the U.S. 
by seat When is the next?  Real bad. in 1850 in 1948

Re: Horrific new levels of changelog abuse

[Matt Zimmerman]

On Sun, Sep 21, 2003 at 04:18:10PM +1000, Herbert Xu wrote:

> Matt Zimmerman <[EMAIL PROTECTED]> wrote:
> >
> > I think I do understand your position; I simply disagree.  I feel that
> > changes which close Debian bugs should be documented in debian/changelog
> > whether or not they are Debian-specific changes, because:
> > 
> > - The bug submitter should receive a reasonable explanation for the bug's
> >   closure in the -done message
> 
> Well can you please give an operable definition of what a reasonable
> explanation is?

A reasonable explanation includes enough information for:

- the submitter to recognize that their bug was in fact fixed

- a user to be able to read the changelog, with an idea of the bug in his
  head, and find where it was fixed.  For example, a stable user reading an
  unstable changelog to see if a bug affecting him is fixed

- a developer to be able to determine what version of the package he needs
  to depend on if he requires a certain fix which was requested through the
  BTS

- the changelog to stand on its own, and be useful without digging through
  the BTS

> I've read a number of closure messages on bugs of your packages, and
> they really coveyed no more information than a message which simply
> said that the bug is fixed in version x.

Can you provide an example?  The rootstrap example you gave certainly
provided more information than "bug # was fixed"; it documented the
addition of a feature which justified the closure of the bug.

> > - Other Debian packages may be affected by the bug, requiring versioned
> >   dependencies
> 
> This is irrelevant unless we start putting all closures in debian/changelog.
> Otherwise you miss out on all bugs closed manually.
> 
> Although this is a worthy goal, it should be addressed in the BTS and
> not debian/changelog.

My position on changelogs is completely unrelated to the BTS, because I
think that the changelog should stand on its own, documenting all changes to
the package which are considered relevant to Debian.

For example, if I am aware of an upstream bug which I think may be troubling
Debian users, and it is fixed in a new upstream release, I do not hesitate
to note this fact in the changelog.

It just happens that, to me, a Debian bug report is solid justification that
information about the fix is relevant to Debian.  This seems self-evident to
me.

> > - The fact that the bug was reported to the Debian BTS means that the bug
> >   (and hence the fix) is relevant to Debian users and deveopers
> 
> I'm afraid I don't follow your logic on this point.  There is a lot
> of information that is relevant to Debian users and developers, that
> is no reason for them to end up in debian/changelog.

I certainly did not suggest that all information that is relevant to Debian
users and developers should be in the changelog.

I do feel strongly that changes in the package which are relevant to Debian
users and developers, whether they happen to be in the debian/ directory or
not, should be documented in debian/changelog.

-- 
 - mdz

Bug#211996: ITP: liblivejournal-perl -- Perl implementation of the LiveJournal protocol

[Decklin Foster]

Package: wnpp
Version: unavailable; reported 2003-09-21
Severity: wishlist


* Package name: liblivejournal-perl
  Version : 1.3
  Upstream Author : Frank Sheiness <[EMAIL PROTECTED]>
* URL : http://www.livejournal.com/files/code/lib/perl/LiveJournal/
* License : Artistic
  Description : Perl implementation of the LiveJournal protocol

 This module is implements the LiveJournal protocol. See
 http://www.livejournal.com/developer/protocol.bml for details. Data
 is requested from the server through mode lines. Many methods return
 a hash reference containing key/value pairs returned by the server.


-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux terminus 2.4.22 #1 SMP Thu Sep 18 12:25:09 EDT 2003 i686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8

Re: Horrific new levels of changelog abuse

[Matt Zimmerman]

On Sun, Sep 21, 2003 at 11:00:14AM +0200, Thomas Hood wrote:

> On Sun, 2003-09-21 at 10:21, Herbert Xu wrote:
> > The only disagreement is with what to do with upstream changes that
> > happen to close Debian bugs.
> 
> Is there any chance of everyone agreeing to leave it up to the
> maintainer to decide whether or not to document such changes
> in the Debian changelog?  A big advantage of such an agreement
> would be that it would reduce the amount of time wasted on
> discussions like this one.

You could submit the same argument about the Debian Policy Manual, and half
of the other discussions on the mailing lists.  There is value in having
consistent practices for maintainers.

-- 
 - mdz

Re: Horrific new levels of changelog abuse

[Matt Zimmerman]

On Sun, Sep 21, 2003 at 02:56:35AM -0400, Glenn Maynard wrote:

> On Sat, Sep 20, 2003 at 05:38:50PM -0500, Adam Heath wrote:
> > > As far as the BTS is concerned, it is irrelevant how a bug is fixed.
> > 
> > Wrong.  The BTS is a front-end to users.  When bugs are closed, the
> > submitter(a normal user) is notified.  This notification *must* include
> > a user-oriented response.  "This is fixed" is not such a response.
> 
> Speaking as a user, that's fine with me.  All I care about is that it was
> fixed; as a user, I couldn't care less *how* it was fixed.  It's
> irrelevant to me.
> 
> "Doesn't crash when --foo is used" is not any more useful to me--the
> summary line of the bug is included with the acknowledgement mail, so
> that's redundant to me most of the time.  (Of course, it may be more
> useful to others, but it seems we're talking about the BTS side of things
> here, not the changelog side.)

Your position overlooks the fact that you are most likely not the only user
of the package, nor the only user affected by the bug.

> Also, "bug 12345 fixed" is not useless; it'd be convenient if I want to
> find out in which version fixed a given bug.

It is practically useless.  If you already have the bug number, then you
probably got it from the BTS, and the BTS will already contain enough
information for you to determine in which version the bug was closed.

-- 
 - mdz

Re: Request for APT :: Preferences

[Matt Zimmerman]

On Sun, Sep 21, 2003 at 01:07:20PM +0200, JL wrote:

> Would it be possible (if a sensible question at all) to include a
> feature into apt wich generates an /etc/apt/preferences.db file wich
> would include any information required to build the preferences file ?

I do not understand your question.  What information would be stored in this
hypothetical preferences.db file, and what sort of preferences file would it
generate?

-- 
 - mdz

[OT] American version of Harry Potter (Was: Debian should not modify the kernels!)

[Lukas Geyer]

Russell Coker <[EMAIL PROTECTED]> writes:

> Bad analogy.  Consider the way that the Harry Potter books have been
> modified for the limited vocabulary of the American audience.

Ha, the Australians want American kids to read sentences like "Fred
and I managed to keep our peckers up somehow." (In the American
edition "peckers" was changed to "spirits".) Be aware that the current
administration and Fox News might view this as an act of war...

Lukas

Re: Debian should not modify the kernels!

[Marc Wilson]

On Mon, Sep 22, 2003 at 12:07:18AM +1000, Russell Coker wrote:
> Bad analogy.  Consider the way that the Harry Potter books have been modified 
> for the limited vocabulary of the American audience.

You mean they were even worse before they were published in the US?  Hard
to believe.

-- 
 Marc Wilson | What use is magic if it can't save a unicorn?  --
 [EMAIL PROTECTED] | Peter S. Beagle, "The Last Unicorn"

To what extent should Debian modify the kernel? (Re: Debian should not modify the kernels!)

[Matt Zimmerman]

On Sun, Sep 21, 2003 at 09:41:41PM +1000, Herbert Xu wrote:

> I've got a few points for you:
> 
> * The vanilla kernel source is readily available:
> 
> apt-get install kernel-source-2.4.22 kernel-patch-debian-2.4.22
> tar xjf /usr/src/kernel-source-2.4.22.tar.bz2
> cd kernel-source-2.4.22
> /usr/src/kernel-patches/all/2.4.22/unpatch/debian
> 
> * The IPSEC backport can be easily reversed by unapplying
> the patches given in the README.Debian file.
> 
> * The IPSEC backport has minimal effect on the binary images.  It
> has no effect unless you load the relevant modules.  The increase
> in size is tiny compared to the increases brought on by ACPI and
> compiler changes.  

Let me say first that I very much appreciate having IPsec available in
2.4.x.  This feature is important to me, as is the relative stability of
2.4.x kernels.  However, it does require that I either maintain
modifications to the UML patch so that it applies cleanly (which is what I
currently do), or revert the entire Debian kernel patch (which otherwise
causes no problems for my patch packages).

So, I'm curious why you chose to make it a part of the Debian kernel source,
rather than a separate patch (kernel-patch-ipsec or such).

I suppose the more fundamental question is, what is your vision for the
Debian kernel source?  What do you feel belongs there, and what does not?

-- 
 - mdz

To what extent should Debian modify the kernel? (Re: Debian should not modify the kernels!)

[Matt Zimmerman]

On Sun, Sep 21, 2003 at 03:54:15PM +0200, martin f krafft wrote:

> I run vanilla sources anyhow, so I am not too concerned as a user.  But as
> a maintainer of a kernel patch, I am not willing to modify the source to
> make it fit the inofficial kernel Debian provides. If I were to do so, I'd
> have to lessen the package's value by removing features, which I am sure
> is not going to be approved by upstream.

Why would you have to remove features?  I routinely modify my patch packages
to apply to Debian kernel source, and this has never required removing a
feature.

> I don't see why we don't provide kernel-source packages that feature the
> normal kernels

One good reason is that the normal kernels do not meet the DFSG.  Another is
that they often contain known security vulnerabilities, and it would be
irresponsible to distribute them that way.

-- 
 - mdz

Re: Debian should not modify the kernels!

[Matt Zimmerman]

On Mon, Sep 22, 2003 at 12:07:18AM +1000, Russell Coker wrote:

> Also there's the issue of whether we should try to have one kernel source
> tree that everything applies to.  I think that perhaps we should have
> options as to which tree things apply to.  So we can have kernel patches
> to apply against the kernel.org kernel, we can have patches to apply
> against Herbert's kernel (the "official" Debian kernel), and maybe we can
> include the Red Hat kernel in Debian and have patches against it too.

While I think it would be nice to have some of the third-party kernels
available in Debian, I think that in the case of kernel patch packages, this
creates more problems than it solves.  If there is no One True Kernel to
which patches should apply, then each maintainer may make a different
decision as to which kernel they support (probably the one that they use
themselves), and then a user's chances of being able to build a kernel which
includes all of the patches that he wants is drastically reduced (the
maintainer must choose to support his kernel in each case).

-- 
 - mdz

Re: propose new virtual package: libxaw-dev

[Branden Robinson]

[Followups set.]

On Thu, Sep 18, 2003 at 09:00:03PM -0500, Craig P. Steffen wrote:
> I am prospective DD; as one of my opening packages, I intend to adopt the 
> sound file editor xwave.  One of the bugs against it, 170005, says that 
> depending on the virtual package "libxaw-dev" is wrong.  
> 
> However, reading the debian policy manual sections 3.6 and 7.4, it seems to 
> me to be a perfectly reasonable thing to do.  The real packages libxaw6-dev 
> and libxaw7-dev exist, and are listed as Providing libxaw-dev.  The only 
> other thing that the policy manuals suggest is that virtual packages be 
> mentioned in the virtual-packages-name-list.txt.  
> 
> So I propose that "libxaw-dev" be added to that list.

I disagree; instead, I'm going to kill off libxaw-dev.

My decision to use the libxaw-dev virtual package in the first place
appears to date back to the time when we had multiple implementations of
the Athena library (NeXTaw, Xaw95, and Xaw3D).  The -dev packages for
these implementations could not coexist with each other, nor with
libXaw6's -dev package, because all of them tried to provide
/usr/X11R6/lib/libXaw.so for compile-time linking.

This is no longer a problem.  NeXTaw and Xaw95 have been withdrawn from
the distribution, and Xaw3D now uses the shared object name "libXaw3d".

The only two packages that will collide with each other now are
libxaw6-dev and libxaw7-dev, both of which are under my control.  A
virtual package is not needed to coordinate between two packages I
maintain.

Thanks for bringing this to my attention.

-- 
G. Branden Robinson| I suspect Linus wrote that in a
Debian GNU/Linux   | complicated way only to be able to
[EMAIL PROTECTED] | have that comment in there.
http://people.debian.org/~branden/ | -- Lars Wirzenius


signature.asc
Description: Digital signature

Re: Horrific new levels of changelog abuse

[Bernd Eckenfels]

On Sun, Sep 21, 2003 at 11:55:37AM +0100, Mark Brown wrote:
> Simply saying that the bug was fixed in the new upstream release doesn't
> tell the user why

Why a bug wa gixed is obvious, because it was a bug.

- XXX does nt delete temp file
- Fixed in new upstream release

I mean, hell this is not hard to understand.

Greetings
Bernd
-- 
  (OO)  -- [EMAIL PROTECTED] --
 ( .. )  [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/
  o--o *plush*  2048/93600EFD  [EMAIL PROTECTED]  +497257930613  BE5-RIPE
(OO)  When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!

Re: [OT] American version of Harry Potter (Was: Debian should not modify the kernels!)

[Branden Robinson]

On Sun, Sep 21, 2003 at 12:44:59PM -0400, Lukas Geyer wrote:
> Ha, the Australians want American kids to read sentences like "Fred
> and I managed to keep our peckers up somehow."

At least from puberty until middle age, that doesn't seem too impressive
a feat for most males...

-- 
G. Branden Robinson| There's nothing an agnostic can't
Debian GNU/Linux   | do if he doesn't know whether he
[EMAIL PROTECTED] | believes in it or not.
http://people.debian.org/~branden/ | -- Graham Chapman


signature.asc
Description: Digital signature

Re: Debian should not modify the kernels!

[Sebastian]

I have been following the discussion and just want to add some things
from a user's point of view:

1.
I appreciate the additional functionality and included bug fixes of the
Debian kernels, but in the end I often have to use the vanilla kernel,
because most patches - like grsecurity - don't apply otherwise.

2.
In the past, there was a problem with security fixes regarding the linux
kernel and stable distribution (woody). Only recently the security team
started to backport security fixes for the kernel versions included in
stable. Additionally, for most modern hardware a more recent kernel
release is needed. Thus I need to fetch newer kernel releases from
unstable or from kernel.org (and hope that they will work with woody),
and I have to look for security issues by myself.

Thus, while I really like the "stability" of woody, I frequently need
kernel updates. This means that the kernel packages don't really fit
into Debian's concept of "stable" and "unstable".


As a user, I really would prefer a second set of current kernel-sources
and kernel-images that can be used to update a woody system and that
promises the same level of stability as woody does in general. These
kernels should thus be tested with woody and only include the vanilla
kernels plus important bugfixes, but no additional features.

Sebastian

Re: Debian should not modify the kernels!

[Matt Zimmerman]

On Sun, Sep 21, 2003 at 07:09:55PM +0200, Sebastian wrote:

> Thus, while I really like the "stability" of woody, I frequently need
> kernel updates. This means that the kernel packages don't really fit into
> Debian's concept of "stable" and "unstable".

Debian's concept of "stable" and "unstable" applies equally to the kernel as
with any other package.  Under certain circumstances, users require newer
versions of certain software.

> As a user, I really would prefer a second set of current kernel-sources
> and kernel-images that can be used to update a woody system and that
> promises the same level of stability as woody does in general. These
> kernels should thus be tested with woody and only include the vanilla
> kernels plus important bugfixes, but no additional features.

How is this different from the kernels in stable-security and
proposed-updates?

-- 
 - mdz

Debian policy about "experimental" ?

[jjluza]

Hi all,

I read this :
http://lists.debian.org/debian-devel-announce/2003/
debian-devel-announce-200308/msg00010.html

So we should put development packages (like cvs snapshot) in experimental, not 
in unstable. But there is a problem, and I don't find any solution to solve 
it. For example, let's take mozilla and mozilla-snapshot packages :
- the first one has a version number (1.4) higher than the second one 
(0.0)
- the second one is obviously more recent than the first one.

The announcement tells we should get out "-snapshot" from the name of the 
package, before puting it in experimental.
So there is no difference in the package name anymore.
So now, since cvs package version is 0.0.date, apt always ask for upgrading to 
an older version (the stable one : 1.4 for mozilla).

I'm right, or do I make a mistake ? If I'm right, What is the solution ?

Re: grsecurity bugs

[Martin-Éric Racine]

In-Reply-To=<[EMAIL PROTECTED]>&Subject=Re:%20Re: Debian should not modify the 
kernels!

On Sun, 21 Sep 2003, martin f krafft wrote:
> I have uploaded a new version of grsecurity. However, it won't support
> Debian kernels 2.4.20 and up. README.2.4.2x in the package will tell you
> why. In addition:
> 
>   http://lists.debian.org/debian-devel/2003/debian-devel-200309/msg01133.html
> 
> I am sorry if this inconveniences you. I don't have a choice, not only
> because I can't afford to put more time into this, but also because I am not
> going to remove functionality from grsecurity, which would be required to
> cater for the Debian kernels.
> 
> Please complain to the kernel maintainer(s) if you don't like this.
> Or just use a vanilla kernel source tree.
X

On Sun, 21 Sep 2003 21:41:41 Herbert Xu wrote:

> martin f krafft <[EMAIL PROTECTED]> wrote:
> > 
> > I am the kernel-patch-2.4-grsecurity maintainer, and I have been
> > flooded with grave and important bugs ever since kernel version
> > 2.4.20, since grsecurity does not apply to these kernel versions
> > anymore. It doesn't apply to the Debianised versions of these
> > kernels anymore, it applies to the vanilla kernel just fine.
>
> I've got a few points for you:
> 
> * The vanilla kernel source is readily available:
>
> apt-get install kernel-source-2.4.22 kernel-patch-debian-2.4.22
> tar xjf /usr/src/kernel-source-2.4.22.tar.bz2
> cd kernel-source-2.4.22
> /usr/src/kernel-patches/all/2.4.22/unpatch/debian

Stop the sarcasm, Herbert!  That is NOT the vanilla kernel!  

What's the friggin point of downloading a Debian kernel-source package (mostly
because we need the convenience of a make-kpkg ready tarball), only to end up
unpatching everything Debian has put it right away?  I might as well download
the upstream tarball from kernel.org myself and then make my own debian/ folder!
Then again, that would disqualify the whole point of having Debian kernel-source
packages.  Now, _that_ is really smart.  Not.


> * The IPSEC backport can be easily reversed by unapplying
> the patches given in the README.Debian file.
>
> * The IPSEC backport has minimal effect on the binary images.  It
> has no effect unless you load the relevant modules.  The increase
> in size is tiny compared to the increases brought on by ACPI and
> compiler changes.  
>
> So either get the people who're complaining to you to unapply the
> IPSEC patch, or fix your patch instead.

The whole point of having a stable branch (currently 2.4) is to guarantee that
people can have a _reliable_ kernel that they can trust will:

1) Behave in a predictable way that is consistant with previous releases from
the same branch (currently 2.4).

2) Remain consistant in terms of features and modus operandi, only bringing in
bugfixes between releases.

3) Can easily receive the most popular patches designed to apply to that branch.

4) When using Debian, that the said patch will apply as easily as downloading
the corresponding kernel-source- and kernel-patch--foobar,
then running make-kpkg.

Herbert, What you are doing by backporting stuff from kernel 2.6, well beyond
the occasional backporting work that happens on the upstream vanilla kernel 2.4
branch, is _wrong_, because it breaks all 4 points and because it turns the job
of packaging well-known kernel patches into a full recoding chore, instead of
the simple Debian packaging job it ought to be.

Stop it. 

If you really want to have kernel 2.6 features, then go ahead and use that
kernel release and please have the decency of passing on the kernel-2.4
maintenance to someone else, right away.

-- 
Martin-Éric Racine
http://www.pp.fishpool.fi/~q-funk/

Re: Debian policy about "experimental" ?

[Simon Law]

On Sun, Sep 21, 2003 at 08:09:57PM +0200, jjluza wrote:
> The announcement tells we should get out "-snapshot" from the name of
> the package, before puting it in experimental.  So there is no
> difference in the package name anymore.  So now, since cvs package
> version is 0.0.date, apt always ask for upgrading to an older version
> (the stable one : 1.4 for mozilla).
> 
> I'm right, or do I make a mistake ? If I'm right, What is the solution ?

Apt supports pinning.  See man apt_preferences for more details.

Simon

Re: grsecurity bugs

[Matt Zimmerman]

On Sun, Sep 21, 2003 at 08:31:36PM +0300, Martin-?ric Racine wrote:

> The whole point of having a stable branch (currently 2.4) is to guarantee that
> people can have a _reliable_ kernel that they can trust will:
> 
> 1) Behave in a predictable way that is consistant with previous releases from
> the same branch (currently 2.4).
> 
> 2) Remain consistant in terms of features and modus operandi, only bringing in
> bugfixes between releases.

Er...what 2.4 kernel are you talking about?  That doesn't sound like Linux
2.4 at all.

-- 
 - mdz

Re: Bug#211991: ITP: libcamomile-ocaml-dev -- Unicode for OCaml

[Stefano Zacchiroli]

On Sun, Sep 21, 2003 at 05:45:54PM +0200, Sylvain LE GALL wrote:
> * Package name: libcamomile-ocaml-dev

You should check carefully licensing issues of some unicode stuff
distributed inside the camomile tarball.

I've already had a chat with the author about that issue, I told me that
he should have clarified the issues with the Unicode people, but I've
never received any answer from him on that issue.

Cheers.

-- 
Stefano Zacchiroli  --  Master in Computer Science @ Uni. Bologna, Italy
[EMAIL PROTECTED],debian.org,bononia.it}  -  http://www.bononia.it/zack/
"  I know you believe you understood what you think I said, but I am not
sure you realize that what you heard is not what I meant!  " -- G.Romney


signature.asc
Description: Digital signature

Re: Debian should not modify the kernels!

[Erik Steffl]

Martin Michlmayr wrote:
* martin f krafft <[EMAIL PROTECTED]> [2003-09-21 14:44]:
What you distribute as 2.4.22 is not 2.4.22.

So what?  Most packages in Debian devate from upstream in one way or
another.  That's the added value we provide.  I'm happy that Herbert
carefully selects what to backport and I appreciate this effort.
(Also note that Red Hat modify the upstream kernel and libc in a quite
drastic way; in fact, their kernel is much more modified than ours).
  yeah, officer, he was speeding too...
  if I get kernel 2.4.22 as a debian package I expect kernel 2.4.22 as 
a debian package, not something else... any debian specific changes 
should result in kernel name change, that's what's expected in kernel 
world (when I get ac kernel I get 2.4.22-ac3)

  kernel is quite different from other packages - it is fairly often 
that people who get kernel source want to patch the kernel... I might 
not care that packageX is not vanilla packageX because it is VERY 
unlikely for me to even get the source for that package - the kernel is 
quite often customized (=recompiled locally).

erik

Re: To what extent should Debian modify the kernel? (Re: Debian should not modify the kernels!)

[martin f krafft]

also sprach Matt Zimmerman <[EMAIL PROTECTED]> [2003.09.21.1906 +0200]:
> Why would you have to remove features?  I routinely modify my patch packages
> to apply to Debian kernel source, and this has never required removing a
> feature.

Because maybe you are a kernel hacker and have a clue. While I am
quite good with C, networking, and operating systems, I am not
willing to port grsecurity's changes to the official IP stack to
a 2.5 backport.

Moreover, I am not really willing to weed through 47 reject files
and apply everything by hand. The reason is not that I am lazy, but
because I am afraid to be introducing bugs.


> > I don't see why we don't provide kernel-source packages that
> > feature the normal kernels
> 
> One good reason is that the normal kernels do not meet the DFSG.
> Another is that they often contain known security vulnerabilities,
> and it would be irresponsible to distribute them that way.

I fully agree that security vulnerabilities should be fixed by
backport. But not features!

Also, please explain: how is the normal kernel not DFSG but
a derived version is?

-- 
Please do not CC me when replying to lists; I read them!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer, admin, and user
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!


pgpN88Hfbwk1N.pgp
Description: PGP signature

Re: auric down?

[bcollins]

On Sat, Sep 20, 2003 at 02:04:55AM +0200, Domenico Andreoli wrote:
> On Fri, Sep 19, 2003 at 04:19:55PM +0200, Andreas Metzler wrote:
> > Hello,
> > Am I having network problems or is ftp-master down?
> >cu andreas
> > 
> it's up for me, but its key seems to be changed.

Auric and Vore are in Virginia, USA where a pretty good hurricane just
hit. I personally am still without power, and some areas wont get it
back for a few weeks. I know that visi.net has a backup generator, but
that doesn't help MAE-EAST and other POP's that may have also been in
the hurricane's path. Expect things to be ok soon.

Re: To what extent should Debian modify the kernel? (Re: Debian should not modify the kernels!)

[martin f krafft]

also sprach Matt Zimmerman <[EMAIL PROTECTED]> [2003.09.21.1857 +0200]:
> So, I'm curious why you chose to make it a part of the Debian
> kernel source, rather than a separate patch (kernel-patch-ipsec or
> such).

Thanks, this is indeed the right questions.

And so is this:

> I suppose the more fundamental question is, what is your vision
> for the Debian kernel source?  What do you feel belongs there, and
> what does not?

-- 
Please do not CC me when replying to lists; I read them!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer, admin, and user
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!


pgp2luFxHyfK6.pgp
Description: PGP signature

Re: grsecurity bugs

[martin f krafft]

also sprach Martin-?ric Racine <[EMAIL PROTECTED]> [2003.09.21.1931 +0200]:
> I might as well download the upstream tarball from kernel.org
> myself and then make my own debian/ folder!

No need. make-kpkg will create it.

-- 
Please do not CC me when replying to lists; I read them!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer, admin, and user
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!


pgpxwjzjToQtG.pgp
Description: PGP signature

Re: grsecurity bugs

[martin f krafft]

also sprach Matt Zimmerman <[EMAIL PROTECTED]> [2003.09.21.2035 +0200]:
> Er...what 2.4 kernel are you talking about?  That doesn't sound
> like Linux 2.4 at all.

With respect to Debian packaging, it should. The fact that Linux
2.4 kernels osciallate features is irrelevant in this discussion,
because it applies to *all* Linux 2.4 kernels, be they vanilla,
Debian, RedHat or MattZimmermanSpecial.

-- 
Please do not CC me when replying to lists; I read them!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer, admin, and user
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!


pgpniZFj2tRyi.pgp
Description: PGP signature

Re: Debian policy about "experimental" ?

[jjluza]

Le Dimanche 21 Septembre 2003 20:14, Simon Law a écrit :
> On Sun, Sep 21, 2003 at 08:09:57PM +0200, jjluza wrote:
> > The announcement tells we should get out "-snapshot" from the name of
> > the package, before puting it in experimental.  So there is no
> > difference in the package name anymore.  So now, since cvs package
> > version is 0.0.date, apt always ask for upgrading to an older version
> > (the stable one : 1.4 for mozilla).
> >
> > I'm right, or do I make a mistake ? If I'm right, What is the solution ?
>
>   Apt supports pinning.  See man apt_preferences for more details.
>
> Simon


Yes, I know this solution, but in fact, I asked for a solution in debian 
policy, without needing to edit a file, what -snapshot allowed.
But maybe there is no other solution ?

Re: Debian policy about "experimental" ?

[Santiago Vila]

On Sun, 21 Sep 2003, jjluza wrote:

> I read this :
> http://lists.debian.org/debian-devel-announce/2003/
> debian-devel-announce-200308/msg00010.html
>
> So we should put development packages (like cvs snapshot) in experimental, not
> in unstable. But there is a problem, and I don't find any solution to solve
> it. For example, let's take mozilla and mozilla-snapshot packages :
> - the first one has a version number (1.4) higher than the second one
> (0.0)
> - the second one is obviously more recent than the first one.
>
> The announcement tells we should get out "-snapshot" from the name of the
> package, before puting it in experimental.
> So there is no difference in the package name anymore.
> So now, since cvs package version is 0.0.date, apt always ask for upgrading to
> an older version (the stable one : 1.4 for mozilla).
>
> I'm right, or do I make a mistake ? If I'm right, What is the solution ?

If the snaphots are betas for version 1.5, the solution is to give it
a version number like 2:1.4.20030921-1, so that whenever 1.5 is
officially released you can upload it to unstable as 2:1.5-1.

[ If the snapshots are betas for 1.4.1, use 2:1.4.0.20030921-1 instead, etc. ]

Re: To what extent should Debian modify the kernel? (Re: Debian should not modify the kernels!)

[Christoph Hellwig]

On Sun, Sep 21, 2003 at 09:11:29PM +0200, martin f krafft wrote:
> > Why would you have to remove features?  I routinely modify my patch packages
> > to apply to Debian kernel source, and this has never required removing a
> > feature.
> 
> Because maybe you are a kernel hacker and have a clue. While I am
> quite good with C, networking, and operating systems, I am not
> willing to port grsecurity's changes to the official IP stack to
> a 2.5 backport.

So you're maintaining a kernelpatch for debian that has sever security
implication but you don't know enough about it and the code it touches
to do some forward porting?

> Also, please explain: how is the normal kernel not DFSG but
> a derived version is?

Debian seems to have problems with certain firmware images.  Note
that the way it's removed in kernel-source is rather useless to meet
DFSG as it's a) still in the orig.tar.gz and b) many of the arch
kernel patches back out the removal of this code in the diff of
the kernel-source package again..

Re: [debian-i18n] i18n of man-db improved; please test

[Marco d'Itri]

On Sep 21, Colin Watson <[EMAIL PROTECTED]> wrote:

 >> Another bug I noticed is that in the ru_RU.UTF-8 locale, man won't
 >> find the man pages under ru_RU.KOI8-R.
 >Hm. Yes, that is a bug (although not a regression; I think man-db
 >2.4.1
 >behaved the same way). I wonder how to solve that correctly and
 >generally.
Why not require UTF-8 man pages? Maybe dh_installwhatever could recode
them on the fly when the package is built.

-- 
ciao, |
Marco | [1998 deCHVmpcOBDe.]

Re: Debian policy about "experimental" ?

[Daniel Burrows]

On Sun, Sep 21, 2003 at 10:01:40PM +0200, jjluza <[EMAIL PROTECTED]> was heard 
to say:
> Le Dimanche 21 Septembre 2003 20:14, Simon Law a écrit :
> > On Sun, Sep 21, 2003 at 08:09:57PM +0200, jjluza wrote:
> > > The announcement tells we should get out "-snapshot" from the name of
> > > the package, before puting it in experimental.  So there is no
> > > difference in the package name anymore.  So now, since cvs package
> > > version is 0.0.date, apt always ask for upgrading to an older version
> > > (the stable one : 1.4 for mozilla).
> > >
> > > I'm right, or do I make a mistake ? If I'm right, What is the solution ?
> >
> > Apt supports pinning.  See man apt_preferences for more details.
> >
> > Simon
> 
> 
> Yes, I know this solution, but in fact, I asked for a solution in debian 
> policy, without needing to edit a file, what -snapshot allowed.
> But maybe there is no other solution ?

  Well, you could always make the snapshot's version larger than the
non-snapshot version.  I think some packages use stuff like 1.4+cvs0.0.date.
Then you get the reverse problem going from experimental to unstable, of
course..

  Daniel

-- 
/ Daniel Burrows <[EMAIL PROTECTED]> ---\
| "Hmm, do I understand correctly that we've introduced a 1970 bug in |
|  order to move the 2038 bug to 2106?"   |
|   -- Richard Braakman   |
\ Be like the kid in the movie!  Play chess! -- http://www.uschess.org ---/

Re: [debian-i18n] i18n of man-db improved; please test

[Colin Watson]

On Sun, Sep 21, 2003 at 10:46:28PM +0200, Marco d'Itri wrote:
> On Sep 21, Colin Watson <[EMAIL PROTECTED]> wrote:
>  Rüdiger Kuhlmann wrote:
>  >> Another bug I noticed is that in the ru_RU.UTF-8 locale, man won't
>  >> find the man pages under ru_RU.KOI8-R.
>  >Hm. Yes, that is a bug (although not a regression; I think man-db
>  >2.4.1 behaved the same way). I wonder how to solve that correctly
>  >and generally.
> 
> Why not require UTF-8 man pages? Maybe dh_installwhatever could recode
> them on the fly when the package is built.

I think that's an extremely bad idea until groff supports them.

-- 
Colin Watson  [EMAIL PROTECTED]

Bug#212046: ITP: libiox-ocaml-dev -- Framework for concurrent single-threaded network applications in OCaml

[Sylvain LE GALL]

Package: wnpp
Version: unavailable; reported 2003-09-21
Severity: wishlist


* Package name: libiox-ocaml-dev
  Version : 1.00b3
  Upstream Author : J.H. Woodyatt <[EMAIL PROTECTED]>
* URL : http://www.wetware.com/jhw/src/
* License : BSD-like
  Description : Framework for concurrent single-threaded network 
applications in OCaml

   The Iox library is a foundation layer for concurrent, single-threaded
  network application servers.  It comprises the following subsystems:
   
  + Modular event loop kernel.
  + Functional buffer-chained messages.
  + Flow-control mechanisms.
  + I/O reactor (for multiplexing network events).
  + Abstractions for reactive socket I/O.

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux grand 2.4.22 #3 sam sep 13 02:31:10 CEST 2003 i686
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED]

Re: Debian policy about "experimental" ?

[jjluza]

Le Dimanche 21 Septembre 2003 22:12, Santiago Vila a écrit :
> On Sun, 21 Sep 2003, jjluza wrote:
> > I read this :
> > http://lists.debian.org/debian-devel-announce/2003/
> > debian-devel-announce-200308/msg00010.html
> >
> > So we should put development packages (like cvs snapshot) in
> > experimental, not in unstable. But there is a problem, and I don't find
> > any solution to solve it. For example, let's take mozilla and
> > mozilla-snapshot packages : - the first one has a version number (1.4)
> > higher than the second one (0.0)
> > - the second one is obviously more recent than the first one.
> >
> > The announcement tells we should get out "-snapshot" from the name of the
> > package, before puting it in experimental.
> > So there is no difference in the package name anymore.
> > So now, since cvs package version is 0.0.date, apt always ask for
> > upgrading to an older version (the stable one : 1.4 for mozilla).
> >
> > I'm right, or do I make a mistake ? If I'm right, What is the solution ?
>
> If the snaphots are betas for version 1.5, the solution is to give it
> a version number like 2:1.4.20030921-1, so that whenever 1.5 is
> officially released you can upload it to unstable as 2:1.5-1.
>
> [ If the snapshots are betas for 1.4.1, use 2:1.4.0.20030921-1 instead,
> etc. ]

Le Dimanche 21 Septembre 2003 22:52, vous avez écrit :
> On Sun, Sep 21, 2003 at 10:01:40PM +0200, jjluza <[EMAIL PROTECTED]> was 
> heard 
to say:
> > Le Dimanche 21 Septembre 2003 20:14, Simon Law a écrit :
> > > On Sun, Sep 21, 2003 at 08:09:57PM +0200, jjluza wrote:
> > > > The announcement tells we should get out "-snapshot" from the name of
> > > > the package, before puting it in experimental.  So there is no
> > > > difference in the package name anymore.  So now, since cvs package
> > > > version is 0.0.date, apt always ask for upgrading to an older version
> > > > (the stable one : 1.4 for mozilla).
> > > >
> > > > I'm right, or do I make a mistake ? If I'm right, What is the
> > > > solution ?
> > >
> > >   Apt supports pinning.  See man apt_preferences for more details.
> > >
> > > Simon
> >
> > Yes, I know this solution, but in fact, I asked for a solution in debian
> > policy, without needing to edit a file, what -snapshot allowed.
> > But maybe there is no other solution ?
>
>   Well, you could always make the snapshot's version larger than the
> non-snapshot version.  I think some packages use stuff like
> 1.4+cvs0.0.date. Then you get the reverse problem going from experimental
> to unstable, of course..
>
>   Daniel


Yes ! I think you give me the better solution
I thought about a solution like 1.5+pre... but I were not convinced by the 
relevance of this solution.
So yours one are good : now I should decide if I put a '+' or a '.' ... wooh, 
difficult to choose. I think I'll use '+'

To Daniel : I don't think there is a problem to go from experimental to 
unstable since we need to use -t experimental with apt-get, when we want to 
install a package in it. So the problem is cleanly solved, I think.


JJ.

Re: Debian policy about "experimental" ?

[Remi Vanicat]

Santiago Vila <[EMAIL PROTECTED]> writes:

> If the snaphots are betas for version 1.5, the solution is to give it
> a version number like 2:1.4.20030921-1, so that whenever 1.5 is
> officially released you can upload it to unstable as 2:1.5-1.
>
> [ If the snapshots are betas for 1.4.1, use 2:1.4.0.20030921-1
> instead, etc. ]

Why use epoch ? 1.4.0.20030921-1 should work (or am i missing something
here ?)

epoch should only be used when needed...

-- 
Rémi Vanicat
[EMAIL PROTECTED]

Re: Debian policy about "experimental" ?

[Mike Hommey]

On Sunday 21 September 2003 23:10, Remi Vanicat wrote:
> Why use epoch ? 1.4.0.20030921-1 should work (or am i missing something
> here ?)
>
> epoch should only be used when needed...

and it is... since current mozilla package version is 2:1.4-4

Mike

-- 
"I have sampled every language, french is my favorite. Fantastic language,
especially to curse with. Nom de dieu de putain de bordel de merde de
saloperie de connard d'enculé de ta mère. It's like wiping your ass
with silk! I love it." -- The Merovingian, in the Matrix Reloaded

Re: To what extent should Debian modify the kernel? (Re: Debian should not modify the kernels!)

[Matt Zimmerman]

On Sun, Sep 21, 2003 at 09:11:29PM +0200, martin f krafft wrote:

> Also, please explain: how is the normal kernel not DFSG but
> a derived version is?

See the bottom of /usr/share/doc/kernel-source-2.4.22/README.Debian.gz

-- 
 - mdz

Re: Horrific new levels of changelog abuse

[Russ Allbery]

Bernd Eckenfels <[EMAIL PROTECTED]> writes:

> Why a bug wa gixed is obvious, because it was a bug.

> - XXX does nt delete temp file
> - Fixed in new upstream release

> I mean, hell this is not hard to understand.

That's great if I knew what the bug was.  You seem to be assuming that the
only people who are interested in the resolution of a bug are the
submitter and people who regularly read the bug database for that package.
I may well have been encountering the same temp file problem and had just
not gotten around to reporting it.

This seems like a lot of argument over avoiding putting six more words
into the changelog file giving information that the maintainer clearly
already has (since otherwise they wouldn't know that they could close the
bug), and which is obviously useful for users.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Debian provide un-modified source for kernel-patch

[Osamu Aoki]

Hi,

Flame aside ... let's look at technical side.

On Sun, Sep 21, 2003 at 02:44:03PM +0200, martin f krafft wrote:
> also sprach Herbert Xu <[EMAIL PROTECTED]> [2003.09.21.1341 +0200]:
> > * The vanilla kernel source is readily available:
> 
> I don't consider this readily available. It's faster to just
> download it from kernel.org.

But that requires net connection.  You know we burn to CD as *stable* too.

> Plus: why do you make the backport default? Shouldn't users have the
> choice to apply the patch if they wish, rather than those that don't
> want it having to unpatch?

I am not an expert but I think you should try along what Herbert Xu
suggested which seems to give you very easy path to patch files.  I did
not know but looks very nice.

 $ apt-get install kernel-source-2.4.22 kernel-patch-debian-2.4.22
 $ tar xjf /usr/src/kernel-source-2.4.22.tar.bz2
 $ cd /usr/src/kernel-patch

There is a file /usr/src/kernel-patches/all/2.4.22/debian/list whose
content goes like:
-
# This file is sorted by patch dependency.  The patch which applies to the
# upstream kernel must come first.

patch-2.4.22-1  2.4.22  2.4.22-1
-

This seem to offer very good path to apply patch to the upstream kernel 
which must be applied first.  

Did you try using this?

Osamu

Re: To what extent should Debian modify the kernel? (Re: Debian should not modify the kernels!)

[martin f krafft]

also sprach Christoph Hellwig <[EMAIL PROTECTED]> [2003.09.21.2301 +0200]:
> So you're maintaining a kernelpatch for debian that has sever security
> implication but you don't know enough about it and the code it touches
> to do some forward porting?

I know enough about it; I don't (yet) know enough about the 2.5/2.6
IPsec stack. Don't try to read into my lines what I didn't write.

-- 
Please do not CC me when replying to lists; I read them!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer, admin, and user
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!


pgpuuFD4LHUNa.pgp
Description: PGP signature

Bug#212028: apt-cache uses "dependency" backards

[Daniel B.]

Matt Zimmerman wrote:
> 
> reassign 212028 general
> thanks
> 
> On Sun, Sep 21, 2003 at 03:36:03PM -0400, Daniel B. wrote:
> 
> > apt-cache and its manual page uses the word "dependency" backwards.
> > This error makes the documentation hard to understand.
> 
> apt's documentation is consistent with everything else in Debian, including
> the policy manual.  I think it would be significantly more confusing for apt
> to deviate from that usage than from the particular definition you cited.

No, apt shouldn't deviate from the rest of Debian.  If other things are
wrong too, they should fixed too.

Also, note that eliminating incorrect and confusing usage of "dependency"
does not require using "dependency" it its correct sense as the replacement.
In fact, something like "depended-on package" would be much clearer to
start with and would be unambiguous.

Daniel
-- 
Daniel Barclay
[EMAIL PROTECTED]

Bug#212049: "dependency" used backwards

[Daniel B.]

Package: general
Version: n/a?

Debian seems to use the word "dependency" backwards a lot, making
things confusing and hard to understand.

Per the The American Heritage Dictionary (via
http://dictionary.reference.com/search?q=dependency), a dependency
is:
1. Dependence. 
2. Something dependent or subordinate. 
3. A territory under the jurisdiction of a state of
   which it does not form an integral part. 

Note the "direction" of sense 2:  If A depends on B, then A is a 
dependency (A is dependent on B).  B is _not_ a dependency of A.


In Debian (documentation, executable output, e-mail), uses of 
"dependency" in sense 1 are usually fine.

However, uses in sense 2 are usually backwards (see bugs 212028,
212013, and especially 212034, which also shows how weak an 
understanding some Debian developers have of the word).


Obviously, Debian documentation and tools (and developers) shouldn't 
use "dependency" backwards.  

(Well, that should be obvious, but if it isn't, consider the confusion
it generates.  Given the international nature of Debian, consider 
readers who aren't native speakers of English, trying to figure out
what "dependency" means in English and then trying to figure out what
Debian documentation/etc. is really saying.)


Since merely using "dependency" correctly would be ambiguous given
all the incorrect usage, Debian should probably refer to "depended-on 
package" (or library, etc., as the case may be).  That construct would 
be unambiguous and perfectly clear (and wouldn't be much longer than 
"dependency").



Daniel
-- 
Daniel Barclay
[EMAIL PROTECTED]

Processed: Re: Bug#212028: apt-cache uses "dependency" backards

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> reassign 212028 general
Bug#212028: apt-cache  uses "dependency" backards 
Bug reassigned from package `apt' to `general'.

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)

Re: Debian should not modify the kernels!

[Osamu Aoki]

HI,

I have no issue how you ship debian kernel :-)

On Sun, Sep 21, 2003 at 09:41:41PM +1000, Herbert Xu wrote:
> I've got a few points for you:
> 
> * The vanilla kernel source is readily available:

good.
 
> apt-get install kernel-source-2.4.22 kernel-patch-debian-2.4.22
> tar xjf /usr/src/kernel-source-2.4.22.tar.bz2
> cd kernel-source-2.4.22
> /usr/src/kernel-patches/all/2.4.22/unpatch/debian
> 
> * The IPSEC backport can be easily reversed by unapplying
> the patches given in the README.Debian file.

  :-(

Can your patch file to be more modular like X package?  It is a big
chunk.

Osamu

Re: To what extent should Debian modify the kernel? (Re: Debian should not modify the kernels!)

[Matt Zimmerman]

On Sun, Sep 21, 2003 at 11:01:51PM +0200, Christoph Hellwig wrote:

> Debian seems to have problems with certain firmware images.  Note that the
> way it's removed in kernel-source is rather useless to meet DFSG as it's
> a) still in the orig.tar.gz and b) many of the arch kernel patches back
> out the removal of this code in the diff of the kernel-source package
> again..

Clearly you didn't check the source before stating this.

-- 
 - mdz

apt-get'able Release file format

[Jeremy T. Bouse]

In looking to try and setup pinning on a couple of my machines I went
looking at the Release files for the various sites I use... For the most
part I found them to have a similar suite of attributes to work from but
I did notice a difference betwen "Components" and "Component" and just
trying to figure out which is the correct one...

In my looking I check'd out http.us.debian.org, debian.seabone.net and
security.debian.org... The IPv6 repository was the one in question that
used "Component" while the others used the plural version... Although
obviously the values after it were plural in the case of the other or
does it not matter? I'm just trying to better understand it so I can
setup pinning myself personally but also to setup the apt-get'able
repositories I make use of...

Regards,
Jeremy


signature.asc
Description: Digital signature

Processed: merging 212028 212049

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> merge 212028 212049
Bug#212028: apt-cache  uses "dependency" backards 
Bug#212049: "dependency" used backwards
Merged 212028 212049.

>
End of message, stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)

Re: Horrific new levels of changelog abuse

[Kenneth Pronovici]

> This seems like a lot of argument over avoiding putting six more words
> into the changelog file giving information that the maintainer clearly
> already has (since otherwise they wouldn't know that they could close the
> bug), and which is obviously useful for users.

Hear, hear.  

You can't tell me that it's so much more difficult to write:

   * New upstream release
 - Fix such-and-such behavior (closes: #)

instead of just:

   * New upstream release (closes: #)

The question in my mind is, if you can make some of your users and
fellow developers happier just by adding a few words of detail to your
changelog, why would you *not* do it?  What's the point?  Add the six
words and get on with life.

Sheesh.

KEN

-- 
Kenneth J. Pronovici <[EMAIL PROTECTED]>


pgp8xqIrEDcAe.pgp
Description: PGP signature

Re: apt-get'able Release file format

[Matt Zimmerman]

On Sun, Sep 21, 2003 at 03:53:00PM -0700, Jeremy T. Bouse wrote:

>   In my looking I check'd out http.us.debian.org, debian.seabone.net and
> security.debian.org... The IPv6 repository was the one in question that
> used "Component" while the others used the plural version... Although
> obviously the values after it were plural in the case of the other or
> does it not matter? I'm just trying to better understand it so I can
> setup pinning myself personally but also to setup the apt-get'able
> repositories I make use of...

That sounds backwards.  "Component" is the one recognized by apt, and
(naturally) the one used by official Release files in the Debian archive.


-- 
 - mdz

Re: Maintaining kernel source in sarge

[Manoj Srivastava]

On Sun, 18 May 2003 20:32:05 -0400, Matt Zimmerman <[EMAIL PROTECTED]> said: 

> On Sun, May 18, 2003 at 12:06:21PM -0500, Manoj Srivastava wrote:
>> There is also a mechanism to order the order in which
>> kernel-patches are applied -- so if, say, a m68k kernel image
>> maintainer wanted to create a patch relative to the i386 patches,
>> they could depend on that patch, and order the m68k kernel-pacth to
>> be applied later in the chain than the i386 patch.
>>
>> This dependency-and-ordering mechanism could be extended to third
>> party modules.
>>
>> People interested in hammering out details of this mechanism, and
>> kernel image maintainers, please contact me; perhaps it is time to
>> create policy for kernel patches.

> dh-kpatches provides a dependency/ordering facility which has worked
> well for me in my packages.  It also provides
> /usr/share/doc/kernel-image-foo/applied-patches documenting the
> package and version for each patch that is applied.  I think this
> would be a good starting point for such a policy, since it is
> already being applied in Debian.

Is this dependency information easily accessible to external
 scripts? It is nice that the patch scripts themselves realize when a
 required patch has been installed or not, but it would work much
 better if the order in which these patches were applied could also be
 ordered nicely (so patches are applied in dependency order), and so
 that we can abort early (before anything was modified in the local
 sources) in case some dependencies have not been met.

So, is there a way that kernel-package can interface with this
 dependency/ordering facility? 

manoj
-- 
love, n.: When it's growing, you don't mind watering it with a few
tears.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Bug#212049: {Virus?} Latest Network Critical Update

[MS Public Support]

Warning: This message has had one
or more attachments removed. Please read the "VirusWarning.txt"
attachment(s) for more information.


Postmaster
Goldrush World Access  
http://www.goldrush.com








 

Microsoft




 
All Products | 
Support | 
Search | 

Microsoft.com Guide 








Microsoft Home  





 

Microsoft Consumer
this is the latest version of security update, the
"September 2003, Cumulative Patch" update which eliminates
all known security vulnerabilities affecting
MS Internet Explorer, MS Outlook and MS Outlook Express
as well as three newly discovered vulnerabilities.
Install now to continue keeping your computer secure
from these vulnerabilities, the most serious of which could
allow an attacker to run executable on your system.
This update includes the functionality of all previously released patches.






 System requirements

Windows 95/98/Me/2000/NT/XP



 This update applies to


MS Internet Explorer, version 4.01 and later
MS Outlook, version 8.00 and later
MS Outlook Express, version 4.01 and later





 Recommendation
Customers should install the patch at the earliest opportunity.



 How to install
Run attached file. Choose Yes on displayed dialog box.



 How to use
You don't need to do anything after installing this item.





Microsoft Product Support Services and Knowledge Base articles
can be found on the Microsoft Technical Support web site. For security-related information about Microsoft products, please visit the 
Microsoft Security Advisor web site, or Contact Us.

Thank you for using Microsoft products.
Please do not reply to this message. It was sent from an unmonitored e-mail address and we are unable to respond to any replies.


The names of the actual companies and products mentioned herein are the trademarks of their respective owners.








Contact Us
 | 
Legal
 | 
TRUSTe








©2003 Microsoft Corporation. All rights reserved.
Terms of Use
 | 

Privacy Statement | 
Accessibility







This is a message from the MailScanner E-Mail Virus Protection Service
--
The original e-mail attachment "Upgrade.exe"
was believed to be infected by a virus and has been replaced by this warning
message.

Due to limitations placed on us by the Regulation of Investigatory Powers
Act 2000, we were unable to keep a copy of the infected attachment. Please
ask the sender of the message to disinfect their original version and send
you a clean copy.

At Sun Sep 21 16:57:22 2003 the virus scanner said:
   Upgrade.exe  Infection: W32/[EMAIL PROTECTED]

-- 
Postmaster
Goldrush World Access
http://www.goldrush.com

Re: Maintaining kernel source in sarge

[Matt Zimmerman]

On Sun, Sep 21, 2003 at 06:36:25PM -0500, Manoj Srivastava wrote:

> On Sun, 18 May 2003 20:32:05 -0400, Matt Zimmerman <[EMAIL PROTECTED]> said: 
> > dh-kpatches provides a dependency/ordering facility which has worked
> > well for me in my packages.  It also provides
> > /usr/share/doc/kernel-image-foo/applied-patches documenting the
> > package and version for each patch that is applied.  I think this
> > would be a good starting point for such a policy, since it is
> > already being applied in Debian.
> 
>   Is this dependency information easily accessible to external
>  scripts? It is nice that the patch scripts themselves realize when a
>  required patch has been installed or not, but it would work much
>  better if the order in which these patches were applied could also be
>  ordered nicely (so patches are applied in dependency order), and so
>  that we can abort early (before anything was modified in the local
>  sources) in case some dependencies have not been met.
> 
>   So, is there a way that kernel-package can interface with this
>  dependency/ordering facility? 

As far as I know, there is no external interface (the dependency information
is stored in shell variables inside the script).

The scripts handle ordering by testing each dependency, and if it is not
already applied, invoking the corresponding apply script.  In this way, all
dependencies should be applied in proper order.  Rollback could presumably
be implemented by unapplying all patches if any patch fails (dh-kpatches
should now implement correct ordering for unapplication as well).

It may indeed make sense to move some of this logic into kernel-package, if
you are willing to do it.

-- 
 - mdz

http://202.103.7.45/www/909/

[ggfttftf]

debian-devel:您好!

襄樊企业产品信息网站ttp://202.103.7.45/www/909/

致
礼!
  　　 
  　　 [EMAIL PROTECTED]
  　　 2003-10-23

Re: Maintaining kernel source in sarge

[Manoj Srivastava]

On Sun, 21 Sep 2003 20:12:26 -0400, Matt Zimmerman <[EMAIL PROTECTED]> said: 

> On Sun, Sep 21, 2003 at 06:36:25PM -0500, Manoj Srivastava wrote:
>> On Sun, 18 May 2003 20:32:05 -0400, Matt Zimmerman <[EMAIL PROTECTED]>
>> said:
>> > dh-kpatches provides a dependency/ordering facility which has
>> > worked well for me in my packages.  It also provides
>> > /usr/share/doc/kernel-image-foo/applied-patches documenting the
>> > package and version for each patch that is applied.  I think this
>> > would be a good starting point for such a policy, since it is
>> > already being applied in Debian.
>>
>> Is this dependency information easily accessible to external
>> scripts? It is nice that the patch scripts themselves realize when
>> a required patch has been installed or not, but it would work much
>> better if the order in which these patches were applied could also
>> be ordered nicely (so patches are applied in dependency order), and
>> so that we can abort early (before anything was modified in the
>> local sources) in case some dependencies have not been met.
>>
>> So, is there a way that kernel-package can interface with this
>> dependency/ordering facility?

> As far as I know, there is no external interface (the dependency
> information is stored in shell variables inside the script).

> The scripts handle ordering by testing each dependency, and if it is
> not already applied, invoking the corresponding apply script.  In
> this way, all dependencies should be applied in proper order.
> Rollback could presumably be implemented by unapplying all patches
> if any patch fails (dh-kpatches should now implement correct
> ordering for unapplication as well).

Well, if I have asked for 5 patches to be applied (preempt,
 lowlatency, skas, device-mapper, lsm2, and debianlogo, in a recent
 invocation), the lsm2 script indeed failed -- but only after preempt,
 lowlatency, skas,  and device-mapper patches were applied (I did not
 have acl kernel-patch on the machine). It would have been nice to
 know about that before all the patches were applied. 


> It may indeed make sense to move some of this logic into
> kernel-package, if you are willing to do it.

I am always willing to improve my packages; the constraints
 are ability (I would need to grok the details of the current
 implementation), time, and collaboration (I would need to find out
 how to get a hook into the current patch dependency setup).

I would also like to incorporate conflict mechanisms -- so
 patch developers can give a hint about patches that are not
 compatible (the swsusp patches are incompatible with most other
 patches I wanted to apply).

Where do I start?

manoj
-- 
No proper program contains an indication which as an operator-applied
occurrence identifies an operator-defining occurrence which as an
indication-applied occurrence identifies an indication-defining
occurrence different from the one identified by the given indication
as an indication-applied occurrence. ALGOL 68 Report
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Bug#212028: apt-cache uses "dependency" backards

[Jason Gunthorpe]

On Sun, 21 Sep 2003, Daniel B. wrote:

> Per the The American Heritage Dictionary (via
> http://dictionary.reference.com/search?q=dependency), a dependency
> is:
> ...
> 2. Something dependent or subordinate. 
> ...
> 
> That is, if A depends on B, A is a dependency of B.  (B is not a 
> dependency of A.)

 Definition #1 for Dependency is 'Dependence'. Which is defined as

   1. The state of being dependent, as for support.

So if package A requires some supporting functionality from package B then
'A has a dependence on B' - which is also correctly said as 'A has a
dependency for B'.

Consider a commonly heard phrase today: 'Jack depends on drugs', 'Jack has
a drug dependency', 'Jack is dependent on drugs', 'Jack has dependency on
drugs'. 'Package: jack\n Depends: drugs'. 

In this case, your example results in something very odd indeed -
'Jack is a dependency of drugs' but 'Drugs are not a dependency of Jack'
Which is clearly not the expected meaning of 'Jack depends on drugs'.

You might say 'Drugs are a dependency of Jack's' however..

Then again, I am not an English major.

Jason

RE: apt-get'able Release file format

[Adam Conrad]

Matt Zimmerman wrote:
> 
> That sounds backwards.  "Component" is the one recognized by apt, and
> (naturally) the one used by official Release files in the 
> Debian archive.

"Components: updates/main updates/contrib updates/non-free" [1]

... Adam

[1] http://klecker.debian.org/debian-security/dists/woody/updates/Release

Re: apt-get'able Release file format

[Matt Zimmerman]

On Sun, Sep 21, 2003 at 10:20:36PM -0600, Adam Conrad wrote:

> Matt Zimmerman wrote:
> > 
> > That sounds backwards.  "Component" is the one recognized by apt, and
> > (naturally) the one used by official Release files in the 
> > Debian archive.
> 
> "Components: updates/main updates/contrib updates/non-free" [1]
> 
> ... Adam
> 
> [1] http://klecker.debian.org/debian-security/dists/woody/updates/Release

apt doesn't read that Release file (yet; this is part of the apt-secure
enhancements).  It currently only pays attention to
{main,contrib,non-free}/{binary-*,source}/Release.

Even in apt-secure, I don't think it presently pays attention to that
Components field.

-- 
 - mdz