Re: How tightly should main be self-contained?
On Fri, Oct 03, 2003 at 10:05:17AM -0500, Steve Langasek wrote: > On Fri, Oct 03, 2003 at 09:40:27AM -0400, Simon Law wrote: > > > Some users have approached me about my packaging on tvtime, which lives > > in main. It benefits greatly from libdscaler, a contrib package. They > > are asking that tvtime Suggests libdscaler. I thought that the > > appropriate thing to do was to have libdscaler Extends tvtime. > > > My impressions of the spirit of Policy 2.2.1 is that main should > > stand alone, and should not recommend any non-free software. > > Well, that's correct -- and it /doesn't/ recommend any non-free > software, it would merely /suggest/ it. :) > > With the exception of the recent aptitude bug, this makes all the > difference between pulling in non-free packages by default, and > informing the user by default that a non-free package is available which > complements the chosen package. Excellent. I shall change this behaviour then. Simon
RE: Package verification and "/usr/bin/install" tool replacements
debsums only does part of the job. File permissions and ownerships are just as important to completely verify a package. It may not matter to "the guy at home with a linux box" but it greatly matters to "the admin managing a large system". Debian does not appear to cater for this latter group My solution does. regards kim > -Original Message- > From: Rene Engelhard [mailto:[EMAIL PROTECTED] > Sent: Saturday, October 04, 2003 5:45 AM > To: debian-devel@lists.debian.org > Subject: Re: Package verification and "/usr/bin/install" tool > replacements > > > Kim Lester wrote: > > Although debian packages may contain md5sums it seems package=20 > > verification is > > not available (unless I have missed something). > > Probably you missed debsums... > > Gr=FC=DFe/Regards,
Re: Annoyances of aptitude
On Fri, 03 Oct 2003 21:40:06 +0200, MichaÅ Politowski wrote: [locating broken packages] > Usually I just press l~b Cool, thanks. I didn't know that trick. (The German translation of the "l" feature is misleading, no it's actually totally wrong... It never occurred to me that this keybinding could be useful. Bug report filed.) > Limited views are (together with GC, and command-line search) probably > the three features of aptitude I couldn't live without. Does my feature request still make some sense? -- Best Regards, | Wer Windows-Rechner ins Internet lÃsst, Sebastian | braucht nicht Ãber SWEN stÃnkern! | | mailbox in "From" silently drops any mail > 20k
Re: Annoyances of aptitude (Was: Where are we now?) (Was: Bits from the RM)
On Fri, Oct 03, 2003 at 02:07:00PM -0400, Daniel Burrows wrote: > > The way this garbage collection is implemented is one of the main > > dislikes I have about aptitude. Aptitude contains a database with > > packages that have been installed through aptitude; as such, it contains > > no information on packages that were installed through a different > > dpkg-frontend. Which is no problem in itself, except that aptitude > > assumes a package which has not been installed through aptitude is not > > wanted; this makes a transition from a different dpkg-frontend to > > aptitude cumbersome, to say the least. > > This behavior is obviously terrible, which is why aptitude doesn't > try to implement it. Ah. Oh. > Of course, as ccheney pointed out recently, there > are always bugs. Can you show me a case where, starting with no > aptitude state information, you run aptitude and get any package on > the system marked as "automatically installed"? (one exception is stuff > that really is automatically installed in order to perform the > upgrade-on-start) I can't. As said, I tried it only once, and it was a while ago. > I just tested this on my computer and it behaves as I expect. I > wonder if you somehow accidentally marked everything as automatic the > first time you used aptitude (or used a buggy version, although I don't > remember any released version with this particular bug), then saved > those states and forgot about it? That is possible. If what happened to me is not the intended behaviour, then please ignore my last mail :-) -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org "Stop breathing down my neck." "My breathing is merely a simulation." "So is my neck, stop it anyway!" -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. signature.asc Description: Digital signature
迎国庆大优惠[特卖]
尊敬的debian-devel： 迎国庆大优惠[特卖] ！ 因艾商城为了答谢新老顾客的厚爱！决定在2003年09月25日―2003年10月30日 VP-RX阴茎增大疗程装 9 折大优惠。欢迎新老顾客光临选购！注册会员订购有产品增送！ 详细介绍和图片请看：http://www.yinlove.net 电话订购：021-56728806 联系人： 李小姐 QQ咨询： 202963
Re: Annoyances of aptitude (Was: Where are we now?) (Was: Bits from the RM)
On 2003-10-03, Daniel Burrows <[EMAIL PROTECTED]> wrote: > I see. It's a lot simpler, from the point of view of maintainability, > to have a single user's manual for both offline and online perusal. > > One nice way to make this less of an issue would be to rewrite the > documentation in a structured format (eg, texinfo or docbook) and add a > reader for that format to aptitude. Unfortunately, writing the reader > could be a lot of work. Why not use the 'info' reader? It's not optimal, but almost anything is better than paging through a long text file. Peace, Dylan
Re: Package verification and "/usr/bin/install" tool replacements
Kim Lester wrote:
Although debian packages may contain md5sums it seems package
verification is
not available (unless I have missed something).
Although your proposition seems more complete, have you try
debsums and checksecurity? debsums with the following
feature in /etc/apt/apt.conf
DPkg::Post-Invoke {
"debsums --generate=nocheck -sp /var/cache/apt/archives";
};
Can be very handy in creating md5sums (BTW, I think it's a bug
against policy to include md5sums in control files).
Ciao!
Fabien
Re: Looking for a co-maintainer for adduser
On Fri, 03 Oct 2003 18:49:40 +0100, Scott James Remnant <[EMAIL PROTECTED]> wrote: >Some of us would like to see Perl taken out of base as well :) That would be an awfully nice thing to have. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
Re: Re: Where are we now? (Was: Bits from the RM)
On Thu, Oct 02, 2003 at 06:18:58PM -0500, Steve Greenland wrote: > Aptitude is nice power tool for dealing with 6000+ packages (or > whatever it is now) try twice that: $ apt-cache search .\* | wc -l 12204 -- gram, who wonders if this could be getting out of hand signature.asc Description: Digital signature
Re: Looking for a co-maintainer for adduser
Scott James Remnant wrote: > Some of us would like to see Perl taken out of base as well :) Marc writes: > That would be an awfully nice thing to have. But it would not be nice to not have the things that would leave with it. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI
Re: Debian should not modify the kernels!
Hi, thanks the good maintenance by Herbert, On Sun, Sep 28, 2003 at 08:12:43AM +1000, Herbert Xu wrote: > Andreas Metzler <[EMAIL PROTECTED]> wrote: > > martin f krafft <[EMAIL PROTECTED]> wrote: > > What I'd really like to hear is a reaction from Herbert to: > > Osamu Aoki <[EMAIL PROTECTED]> in <[EMAIL PROTECTED]> > > | Can your patch file to be more modular like X package? It is a big > > | chunk. > > > > Which could make both sides happy. Instead of one big patch containing > > bugfixes, security fixes and feature additions to make them separately > > available in the kernel-source-package. > > Again this is something that I have already stated my position on. > This is simply unmaintainable due to the complex relationships between > patches. Interesting :-) My use of word "modular" may have mislead you as I see above. Just to avoid confusion: 1) I like default kernel get good maintenance including IPsec if the expert Herbert Xu decides to do so. (No argument here from me.) 2) I was not suggesting very fine grained "modular" patch for each issues. I was expecting something like 3-4 stage patches. * 1st big patch: cramfs etc. which are essential to be Debian kernel * 2nd big patch: basic bug fixes. (No feature change, something you may have got from upstream pre release patch.) * 3rd big patch: basic feature fix. (IPsec and all others which is generally good and nice for most users.) * 4th big patch: Whatever you did at last minutes :-) The order of above is not essential for me. It should apply clean though. > In any case, the kernel-source package's README file should contain all > the information you need to extract any particular patch that you're > interested in. If you make your patch somewhat more split into "staged" manner (yes, I am not asking "modular"), then it is easier for specialty patch maintenance become easy. After all those specialty patch user may no need features needed by most user but he certainly expects having cramfs and other standard features of Debian. If you claim making simple 3-4 stage patch maintenance "unmaintainable due to the complex relationships between patches", it is certainly unmaintainable for other "patch" package maintainer or any one try to apply patch to keep up with you. I know you maintain position that other patch maintainer can do 1st and 2nd stage patch himself using vanilla source after unpatch. But, to me, it is waisted resources. I did not understand why you want to document how you build package only in the text of documentation but not in source package itself. Cheers, Osamu PS: I once wanted to apply ACPI patch and hit similar issues as Martin. It was too much for me and I gave up :-( Now Debian version of kernel is 2.4.21 and I am happy.
Discussion - Free the Debian Open Use logo
Debian Open Use Logo License Copyright (c) 1999 Software in the Public Interest -This logo or a modified version may be used by anyone to refer to the -Debian project, but does not indicate endorsement by the project. +This logo or a modified version may be used by anyone, but does not +indicate endorsement by the Debian project. Note: we would appreciate that you make the image a link to http://www.debian.org/ if you use it on a web page. + +Note: this copyright license does not grant a trademark license. If +it is applied to a trademark, you should be sure that you are not +violating trademark rights. Rationale: The old Open Use logo was not DFSG-free, so we really shouldn't be shipping it in main. The proposed license keeps the spirit of the old one, while not restricting the logo's use. It seems that the Open Use Logo is not DFSG-free and there has been no objection to this claim on debian-legal. http://lists.debian.org/debian-legal/2003/debian-legal-200309/msg00823.html http://lists.debian.org/debian-legal/2003/debian-legal-200309/msg00842.html http://lists.debian.org/debian-legal/2003/debian-legal-200309/msg00877.html The current Open Use license prevents modification if it is not used to refer to the Debian project. This fails DFSG 8. Simon pgppfJXyGtUjj.pgp Description: PGP signature
Re: Debian should not modify the kernels!
Osamu Aoki <[EMAIL PROTECTED]> wrote:
>
> 2) I was not suggesting very fine grained "modular" patch for each issues.
>I was expecting something like 3-4 stage patches.
>
>* 1st big patch: cramfs etc. which are essential to be Debian kernel
>* 2nd big patch: basic bug fixes. (No feature change, something you
> may have got from upstream pre release patch.)
>* 3rd big patch: basic feature fix. (IPsec and all others which is
> generally good and nice for most users.)
>* 4th big patch: Whatever you did at last minutes :-)
>
> The order of above is not essential for me. It should apply clean
> though.
No this is still a lot of work for very little gain.
The problem is that everytime a change is made in the first patch, all
the other three will have to be fixed and rengenerated.
> If you make your patch somewhat more split into "staged" manner (yes, I
> am not asking "modular"), then it is easier for specialty patch
> maintenance become easy. After all those specialty patch user may no
> need features needed by most user but he certainly expects having cramfs
> and other standard features of Debian.
Very few people really need cramfs if they're building custom kernels.
This is because initrd only makes sense when you're building for a
large number of machines. If you're building a custom kernel, just
compile in all the drivers you need for mounting root and that's that.
On the other hand, the security fixes are usually easy to extract and
well documented.
> If you claim making simple 3-4 stage patch maintenance "unmaintainable
> due to the complex relationships between patches", it is certainly
> unmaintainable for other "patch" package maintainer or any one try to
> apply patch to keep up with you.
Keeping up with the Debian tree is much the same as keeping up with
any other kernel tree. The answer is to use a proper revision control
system.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Package verification and "/usr/bin/install" tool replacements
On Sat, Oct 04, 2003 at 01:42:36PM -0400, Fabien Ninoles wrote:
> Although your proposition seems more complete, have you try
> debsums and checksecurity? debsums with the following
> feature in /etc/apt/apt.conf
>
> DPkg::Post-Invoke {
> "debsums --generate=nocheck -sp /var/cache/apt/archives";
> };
>
> Can be very handy in creating md5sums (BTW, I think it's a bug
> against policy to include md5sums in control files).
Is there some way you can do the same thing for packages installed with
dpkg only and without apt-get? The apt-get layer would appear to be the
wrong layer for this task IMHO.
--
Brian May <[EMAIL PROTECTED]>
Re: New glibc with NPTL in experimental
On Fri, Oct 03, 2003 at 11:21:21PM -0400, Daniel Jacobowitz wrote: > I've just placed a new glibc package for experimental in incoming. > libc6-i686 is new, so it may be a few days before it shows up in the > archive. These packages should be considered _extremely experimental_, as > neither the NPTL libraries (requires 2.6.0; I don't think it will behave > right if you have 2.6.0 on an i386; that's on the TODO list to fall back to > LinuxThreads) nor the i686 optimized libraries (requires 2.4.18; will > misbehave on non-cmov processors) have been well tested. Do not build and > upload packages against them. Some intelligence, please :) I gather NPTL is (yet-another) threading library in 2.6.0? Do programs need to be modified / recompiled in anyway? What are the benifits of one over the other? -- Brian May <[EMAIL PROTECTED]>
Re: New glibc with NPTL in experimental
On Sun, Oct 05, 2003 at 09:49:17AM +1000, Brian May wrote: > On Fri, Oct 03, 2003 at 11:21:21PM -0400, Daniel Jacobowitz wrote: > > I've just placed a new glibc package for experimental in incoming. > > libc6-i686 is new, so it may be a few days before it shows up in the > > archive. These packages should be considered _extremely experimental_, as > > neither the NPTL libraries (requires 2.6.0; I don't think it will behave > > right if you have 2.6.0 on an i386; that's on the TODO list to fall back to > > LinuxThreads) nor the i686 optimized libraries (requires 2.4.18; will > > misbehave on non-cmov processors) have been well tested. Do not build and > > upload packages against them. Some intelligence, please :) > > I gather NPTL is (yet-another) threading library in 2.6.0? > > Do programs need to be modified / recompiled in anyway? > > What are the benifits of one over the other? New POSIX Threads Library, or somesuch. As for benefits... try "real POSIX threading", "doesn't choke and die on large numbers of threads", and "brings Linux remotely close to most of the rest of the world in terms of threading"... Now to get NetBSD to release 2.0 :) -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU NetBSD/i386 porter: :' : `. `' `- pgpCgUvB1o4mm.pgp Description: PGP signature
Package.gz signing
I've been doing some research into the current state of GPG signing official apt sources. I've found a few conversations on this mailing circa 2000-2001 about creating a Packages.gpg and a seperate update procedure for updating this file, and then verifying Packages.gz against it. I cannot find any information beyond this. What is the current status of this? Do we hope to have this implemented for Sarge? It would be a wonderful addition. It's something most other distro's have that we don't. Cheers. -- Jerry Haltom <[EMAIL PROTECTED]> Feedback Plus, Inc.
Re: New glibc with NPTL in experimental
On Sun, Oct 05, 2003 at 09:49:17AM +1000, Brian May wrote: > On Fri, Oct 03, 2003 at 11:21:21PM -0400, Daniel Jacobowitz wrote: > > I've just placed a new glibc package for experimental in incoming. > > libc6-i686 is new, so it may be a few days before it shows up in the > > archive. These packages should be considered _extremely experimental_, as > > neither the NPTL libraries (requires 2.6.0; I don't think it will behave > > right if you have 2.6.0 on an i386; that's on the TODO list to fall back to > > LinuxThreads) nor the i686 optimized libraries (requires 2.4.18; will > > misbehave on non-cmov processors) have been well tested. Do not build and > > upload packages against them. Some intelligence, please :) > > I gather NPTL is (yet-another) threading library in 2.6.0? > > Do programs need to be modified / recompiled in anyway? Hopefully, no, except for programs which work around or assume the non-POSIX deficiencies of LinuxThreads. For instance, getpid() is no longer different between threads. Signal handling has also changed substantially. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: Package.gz signing
* Jerry Haltom <[EMAIL PROTECTED]> [2003-10-04 20:24]: > I've been doing some research into the current state of GPG signing > official apt sources. > > I've found a few conversations on this mailing circa 2000-2001 about > creating a Packages.gpg and a seperate update procedure for updating #203741, http://monk.debian.net/apt-secure/ -- Martin Michlmayr [EMAIL PROTECTED]
