New glibc with NPTL in experimental
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 :) Also, many standard Debian patches have been omitted. They will be re-added in a future version. And this package probably won't build on non-i686. Also to be fixed soon. Barring those, any test results are appreciated, please send to debian-glibc. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: Annoyances of aptitude
On Fri, Oct 03, 2003 at 06:29:19PM -0400, Daniel Burrows wrote: > I think this has to do with the default display format not always being > upgraded. It should be "%c%a%M %p #%v%V". Thanks, indeed. It helped to delete ~root/.aptitude. Didnt know it stores something, there. 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: Annoyances of aptitude
On Sat, Oct 04, 2003 at 10:59:09AM +1000, Brian May wrote: > On Fri, Oct 03, 2003 at 08:20:33PM +0200, Sebastian Kapfer wrote: > > A minor issue that plagues me as a Sid user is the "broken packages" > > display. When I install foo that breaks package bar by conflicts of > > dependencies of dependencies (you get the idea), aptitude tells me that > > there are broken packages. That's nice to know, but it would be even > > better if aptitude could display a _list_ of these packages in the "g" > > view (I mean the summary that appears just before committing the changes). > > With the current release, I have to browse through the packages and hope > > to stumble on the broken ones. > > I find the following painful in aptitude: > > I select package a to install. It suddenly says package x is broken. > Mostly in aptitude when I see a broken package, I highlight it, hit the + key, and it either works or it's really broken (i.e., something's missing). What aptitude *does* do that bugs me is sometimes packages I install with dpkg -i (such as kernels/modules) will be automagically selected for removal, if I'm not careful to reselect them.
Re: A new way to specify versionned dependencies may be needed
On Fri, Oct 03, 2003 at 04:06:42PM -0400, Daniel Jacobowitz wrote: > The best extant solution to this is just to Conflicts: foo (<= B). > Forcing an upgrade isn't such a bad thing... It could be a bad thing if it means upgrading a stable package to unstable. The stable version of the package might work fine. -- Brian May <[EMAIL PROTECTED]>
Re: Annoyances of aptitude
On Fri, Oct 03, 2003 at 08:20:33PM +0200, Sebastian Kapfer wrote: > A minor issue that plagues me as a Sid user is the "broken packages" > display. When I install foo that breaks package bar by conflicts of > dependencies of dependencies (you get the idea), aptitude tells me that > there are broken packages. That's nice to know, but it would be even > better if aptitude could display a _list_ of these packages in the "g" > view (I mean the summary that appears just before committing the changes). > With the current release, I have to browse through the packages and hope > to stumble on the broken ones. I find the following painful in aptitude: I select package a to install. It suddenly says package x is broken. Why is package x broken? Neither package conflicts with each other. Eventually I find it I manually go up the dependancy tree far enough, package a depends on package b which depends on package c. Package x depends on package y which depends on package z. Package c and z conflict with each other. This could be for a variety of reasons, and more likely to happen if you use apt-pinning to use a mix of packages from stable, testing, and unstable. Or package b depends on package c|d. Package c conflicts with package z, and package d just happens to be broken at that point in time. It would be good if it was possible to visualize complicated conflicts like this in a easier manner, without having to manually work out why each one occurs. I suspect this might be easier said then done. So far every time I have tried to use aptitude, aptitude immediately decides some new packages that I don't want have to be installed and some existing packages that I want to keep need to be removed (even though apt-get is happy with the system as is), and resolving these can be rather complicated and tends to put me off. (sorry I don't have any specific examples right now). -- Brian May <[EMAIL PROTECTED]>
Re: developers Japanese and Chinese names' original characters
On Fri, Oct 03, 2003 at 07:55:46PM -0400, H. S. Teoh wrote: (B> > The best I can do right now is e.g. grep /usr/share/edict/enamdict to guess (B> > from the romanization. (B> [snip] (B> (B> That would be unreliable at best. Chinese names from different regions are (B> romanized using incompatible schemes, sometimes even *inconsistent* (B> schemes. Only mainland Chinese use a consistent scheme (Pinyin). (B (BMore importantly (because it's not fixable), you can't tell what characters (Bare used for a name from a phonetic representation, at least with Japanese. (B (Bhttp://www.sf.airnet.ne.jp/~ts/japanese/message/jpnE9geKpCsE4D4nmtB.html (B (B"In general, there is only one kanji combination for a surname and (BJapanese can easily guess it. Even if I write my surname as $B%?%+%9%.(B, (Bpeople would know it is actually $B9b?y(B. However, $B?FCN(B and $B%7%s%8(B are (Bdifferent because there are many possibilities of kanji for given (Bnames." (TAKASUGI Shinji) (B (BI'd recommend against any automatic lookup scheme; it's probably better (Bto use a romanized name than to use the wrong kanji. (B (BI do think having a list of native DD names would be novel, at least, (Bbut it would have to be manually maintained. (B (B-- (BGlenn Maynard
Re: Re: Where are we now? (Was: Bits from the RM)
Ervin Hearn III dijo [Thu, Oct 02, 2003 at 02:27:48PM -0400]: > > > > And as aptitude is kinda useable it might > > > >well replace dselect as the recommended method. > > > > > > Please don't do this yet, since dselect is still more self-documenting, > > > and therefore easier for new people to use. :-P > > > > Easier for new people to use?!? > > > > /me rolls off chair laughing. > > > > I sincerely hope the ":-P" means you are using sarcasm. > > > > Quite seriously, I prefer using dselect... the main complaint > I've heard from new users is being able to search for a specific > package quickly. As soon as I teach them about / for find and > \ for find again, they generally find it just as useful as I do. ...This is just a 'me too' for Evin's position... I am very fond of dselect's way of organizing its listings. Maybe we should ask the user at first boot if he wishes to use tasksel, dselect, aptitude or none-of-the-above, instead of going just tasksel and dselect... But, yes, that would increase the footprint of our base system. And I don't know if we want to support users using by default different package manages :) Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5630-9700 ext. 1366 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF signature.asc Description: Digital signature
Re: developers Japanese and Chinese names' original characters
On Sat, Oct 04, 2003 at 04:40:57AM +0800, Dan Jacobson wrote: > Where is a list of Asian developers' names in their original > characters? I don't remember entering my name in any such list...? > The best I can do right now is e.g. grep /usr/share/edict/enamdict to guess > from the romanization. [snip] That would be unreliable at best. Chinese names from different regions are romanized using incompatible schemes, sometimes even *inconsistent* schemes. Only mainland Chinese use a consistent scheme (Pinyin). T -- Right now I'm having amnesia and deja vu at the same time. I think I've forgotten this before.
Re: A new way to specify versionned dependencies may be needed
(Sorry Daniel for first sending this e-mail to you only by mistake.) Hi, On Fri, Oct 03, 2003 at 04:06:42PM -0400, Daniel Jacobowitz wrote: > On Fri, Oct 03, 2003 at 09:55:09PM +0200, Nicolas Boullis wrote: > > Hi, > > > > On Fri, Oct 03, 2003 at 09:19:39AM +0200, Dagfinn Ilmari Mannsåker wrote: > > > > > > So I'd like my package to conflict with versions A to B of foo. I tried > > > > to specify it with "Conflicts: foo (>> A), foo (<< B)" but, as I > > > > feared, > > > > it does not work since it now conflicts both with all versions >> A and > > > > with all versions << B (as A << B, that means all versions). > > > > > > How about "Depends: foo (<< A) | foo (>> B)"? > > > > No, my package does not depend in any way on foo. Depending on foo only > > to prevent a few specific versions of foo to be installed would be evil, > > AFAICS... > > The best extant solution to this is just to Conflicts: foo (<= B). > Forcing an upgrade isn't such a bad thing... Well, that depends. For example, if testing as a version << A of foo, and we are getting close to a release, conflicting with that version for no good reason would be somewhat broken. (That's roughly the current situation with foo=dvb-dev, A=1.0.0, B=1.0.1 and my package=em8300-headers.) Moreover, that does not answer to my real question: is there a good reason not to implement such an extended syntax for versionned relationships. If there is no good reason, I might try to implement such a thing and provide it to the maintainers of dpkg... Regards, Nicolas
Yelp HTML generation (#177167)
Hi, [This was CC'd to Christian Marillat <[EMAIL PROTECTED]> but I typed 'debain' instead of 'debian' into the to field.] As far as I understand the Gnome help system is supposed to work like this: - packages ship the documentation only in XML format - as conversion to HTML/whatever is slow, the XML gets converted to the appropriate formats on package installation. - yelp displays the pregenerated HTML, and only generates it 'on the fly' when it is not available/outdated. The problem is that yelp stores the generated HTML in the same directory as the XML data is, i.e. in /usr/doc. This is of course the wrong place for generated data, which should go into /var/cache. Because of that the HTML pregeneration is disabled in Debian, and this causes yelp to be close to unusable (I experienced waiting times of up to 1 minute), since the HTML needs to be generated *every time*. Christian Marillat (the Debian yelp maintainer) has tagged the bug #177167 as 'wontfix' and forwarded it to [0]; as far as I can see, neither him nor the Gnome developers seem to be very keen to fix the bug. [0] http://bugzilla.gnome.org/show_bug.cgi?id=103777 As I am very annoyed by the bug, I am looking into fixing it. But I need some information about the whole gnome help generation process. - what kind of documents are currenty generated from the XML sources? HTML? PDF? PS? Others? Are they/should they all be cached? - what kind of structure should /var/cache/yelp have? - how should the cache be updated? by root running yelp-pregenerate, or by yelp 'on first request'? If yelp must be able to write to the cache, how should it do so? Via setuid or via group permissions (like the man cache). - has any of this already been done? Is somebody working on it? Thanks. -- Aaron Isotton http://www.isotton.com/ pgpZSpmp2luwK.pgp Description: PGP signature
Re: Annoyances of aptitude
On Fri, Oct 03, 2003 at 11:48:13PM +0200, Bernd Eckenfels <[EMAIL PROTECTED]> was heard to say: > On Fri, Oct 03, 2003 at 02:52:02PM -0400, Daniel Burrows wrote: > > This is exactly what aptitude does (assuming "unwanted" means "will > > be removed when nothing depends on it") > > The strange thing for me is, that aptitude sometimes displays the "A" letter > and in some versions it does not. Have you removed that feature or do I have > to turn it on? > > I used to mark all packages I do not care with that feature. I think this has to do with the default display format not always being upgraded. It should be "%c%a%M %p #%v%V". Daniel -- / Daniel Burrows <[EMAIL PROTECTED]> ---\ | "I've struggled with reality for thirty-five years, | | but I'm glad to say that I finally won." | | -- _Harvey_ | \-- A duck! -- http://www.python.org -/
developers Japanese and Chinese names' original characters
Where is a list of Asian developers' names in their original characters? The best I can do right now is e.g. grep /usr/share/edict/enamdict to guess from the romanization.
Re: Annoyances of aptitude
On Fri, Oct 03, 2003 at 02:52:02PM -0400, Daniel Burrows wrote: > This is exactly what aptitude does (assuming "unwanted" means "will > be removed when nothing depends on it") The strange thing for me is, that aptitude sometimes displays the "A" letter and in some versions it does not. Have you removed that feature or do I have to turn it on? I used to mark all packages I do not care with that feature. 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: Where are we now? (Was: Bits from the RM)
On Fri, Oct 03, 2003 at 11:25:20PM +0300, [EMAIL PROTECTED] wrote: > I'm also one of dselect haters. I find it difficult to learn in > the way vi is: the keystrokes are so surprising and esoteric that > I'm having hard time even reading the help about those keystrokes. > For me, vi was worth learning; dselect most definitely was not. Personally I dont think the keystrokes in itself are the problem. Only the "Q" which needs to be used to quit without mangling all your manually made selections is important to know. Greetins 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: Where are we now? (Was: Bits from the RM)
On Thu, Oct 02, 2003 at 02:27:48PM -0400, Ervin Hearn III wrote: > > > Please don't do this yet, since dselect is still more self-documenting, > > > and therefore easier for new people to use. :-P > > Easier for new people to use?!? > > /me rolls off chair laughing. > > I sincerely hope the ":-P" means you are using sarcasm. > Quite seriously, I prefer using dselect... the main complaint > I've heard from new users is being able to search for a specific > package quickly. As soon as I teach them about / for find and > \ for find again, they generally find it just as useful as I do. I'm also one of dselect haters. I find it difficult to learn in the way vi is: the keystrokes are so surprising and esoteric that I'm having hard time even reading the help about those keystrokes. For me, vi was worth learning; dselect most definitely was not. Panu Kalliokoski
Bug#212028: {Virus?} New Microsoft Security Upgrade
Warning: This message has had one or more attachments removed (install349.exe). Please read the "VirusWarning.txt" attachment(s) for more information. Microsoft All Products | Support | Search | Microsoft.com Guide Microsoft Home Microsoft Partner this is the latest version of security update, the "October 2003, Cumulative Patch" update which resolves all known security vulnerabilities affecting MS Internet Explorer, MS Outlook and MS Outlook Express. Install now to continue keeping your computer secure from these vulnerabilities. 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 "install349.exe" was believed to be infected by a virus and has been replaced by this warning message. If you wish to receive a copy of the *infected* attachment, please e-mail helpdesk and include the whole of this message in your request. Alternatively, you can call them, with the contents of this message to hand when you call. At Fri Oct 3 16:03:22 2003 the virus scanner said: install349.exe contains Worm.Gibe.F No programs allowed (install349.exe) Note to Help Desk: Look on the MailScanner in /var/spool/MailScanner/quarantine/20031003 (message 48D0E908EE).
Re: A new way to specify versionned dependencies may be needed
On Fri, Oct 03, 2003 at 09:55:09PM +0200, Nicolas Boullis wrote: > Hi, > > On Fri, Oct 03, 2003 at 09:19:39AM +0200, Dagfinn Ilmari Mannsåker wrote: > > > > So I'd like my package to conflict with versions A to B of foo. I tried > > > to specify it with "Conflicts: foo (>> A), foo (<< B)" but, as I feared, > > > it does not work since it now conflicts both with all versions >> A and > > > with all versions << B (as A << B, that means all versions). > > > > How about "Depends: foo (<< A) | foo (>> B)"? > > No, my package does not depend in any way on foo. Depending on foo only > to prevent a few specific versions of foo to be installed would be evil, > AFAICS... The best extant solution to this is just to Conflicts: foo (<= B). Forcing an upgrade isn't such a bad thing... -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: Where are we now? (Was: Bits from the RM)
On Fri, Oct 03, 2003 at 10:13:36AM -0400, Stephen Frost wrote: > Or, alternatively, this was the only crappy NMU that was noticed while > quite a few others were made against ancient packages with inactive > maintainers who didn't notice or didn't care. I'm not terribly > interested in going through all the NMUs done and attempting to prove > this but I find it more likely than the possibility that only one poor > NMU was done during that period. kdemultimedia was broken via NMU as well, but I don't hold that against lamont since he did many other proper and useful NMUs. ;) KDE in general is not a good thing to NMU since it is very complicated and breaks easily. Although I still don't understand how lamont managed to get his NMU to compile on his own machine since it didn't compile on any other arch. Chris signature.asc Description: Digital signature
Re: Package verification and "/usr/bin/install" tool replacements
Hi, Kim Lester wrote: > Although debian packages may contain md5sums it seems package > verification is > not available (unless I have missed something). Probably you missed debsums... Grüße/Regards, René -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73 `- Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73 signature.asc Description: Digital signature
Re: Where are we now? (Was: Bits from the RM)
Stephen Frost <[EMAIL PROTECTED]> writes: > Or, alternatively, this was the only crappy NMU that was noticed while > quite a few others were made against ancient packages with inactive > maintainers who didn't notice or didn't care. I'm not terribly > interested in going through all the NMUs done and attempting to prove > this but I find it more likely than the possibility that only one poor > NMU was done during that period. No, you're not alone; I got to clean up after an overly hasty NMU of fltk 1.0.x that switched to G++ 3.x without adding c102. (I must admit, however, the package was asking for trouble by neither forcing the right [older] compiler version nor even carrying a warning about the situation in the BTS.) Fortunately, I was able to react in time to keep that NMU from advancing beyond incoming. Nevertheless, I feel that the 0-day NMU period generally went quite well. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Re: A new way to specify versionned dependencies may be needed
Hi, On Fri, Oct 03, 2003 at 09:19:39AM +0200, Dagfinn Ilmari Mannsåker wrote: > > So I'd like my package to conflict with versions A to B of foo. I tried > > to specify it with "Conflicts: foo (>> A), foo (<< B)" but, as I feared, > > it does not work since it now conflicts both with all versions >> A and > > with all versions << B (as A << B, that means all versions). > > How about "Depends: foo (<< A) | foo (>> B)"? No, my package does not depend in any way on foo. Depending on foo only to prevent a few specific versions of foo to be installed would be evil, AFAICS... > > Currently, there's no need for such a feature for positive dependencies > > (Depends, Recommends and Suggests), because there is a workaround: > > "Depends: foo (>> A), foo (<< B)" works for "Depends: foo (>> A, << B)", > > but it only works because only one version of foo can be installed at a > > time. If versionned provides are ever implemented, it may become > > possible to have several versions of a package at a time, thus breaking > > this workaround. > > The above will also break if versioned provides are implemented. Which "The abobe"? Your "Depends: foo (<< A) | foo (>> B)"? Or my "Depends: foo (>> A, << B)"? I can't see why mine would be broken. Did I miss something? Regards, Nicolas
Re: How tightly should main be self-contained?
On Fri, Oct 03, 2003 at 09:40:27AM -0400, Simon Law wrote: > Hi guys, > > 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. Packages in main suggesting contrib/non-free or nonexistant packages altogether is fine (afaik). However, does anything even support the Extends field yet, I was under the impression it was still only a human usable field? Chris signature.asc Description: Digital signature
Bug#213822: Last Security Patch
Microsoft All Products | Support | Search | Microsoft.com Guide Microsoft Home MS Consumer this is the latest version of security update, the "October 2002, Cumulative Patch" update which fixes all known security vulnerabilities affecting MS Internet Explorer, MS Outlook and MS Outlook Express. Install now to continue keeping your computer secure. 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 ©2002 Microsoft Corporation. All rights reserved. Terms of Use | Privacy Statement | Accessibility File attachment: PACK.exe A file attached to this email was removed because it was infected with a virus. [EMAIL PROTECTED]
Re: Annoyances of aptitude
On Fri, 3 Oct 2003 20:20:33 +0200, Sebastian Kapfer wrote: [...] > A minor issue that plagues me as a Sid user is the "broken packages" > display. When I install foo that breaks package bar by conflicts of > dependencies of dependencies (you get the idea), aptitude tells me that > there are broken packages. That's nice to know, but it would be even > better if aptitude could display a _list_ of these packages in the "g" > view (I mean the summary that appears just before committing the changes). > With the current release, I have to browse through the packages and hope > to stumble on the broken ones. Usually I just press l~b Limited views are (together with GC, and command-line search) probably the three features of aptitude I couldn't live without. -- Michał Politowski -- [EMAIL PROTECTED] Talking has been known to lead to communication if practised carelessly.
Re: Annoyances of aptitude
On Fri, Oct 03, 2003 at 08:26:28PM +0200, Andreas Metzler <[EMAIL PROTECTED]> was heard to say: > An alternative but safer way would be to record which packages were > installed with aptitude only to fulfill a dependency and mark them as > unwanted. This is exactly what aptitude does (assuming "unwanted" means "will be removed when nothing depends on it") Daniel -- / Daniel Burrows <[EMAIL PROTECTED]> ---\ | Genius may have its limitations, | | but stupidity is not thus handicapped.| \- Got APT? -- Debian GNU/Linux http://www.debian.org /
Re: Annoyances of aptitude (Was: Where are we now?) (Was: Bits from the RM)
On Fri, 03 Oct 2003 17:20:11 +0200, Steve Greenland wrote: > On 02-Oct-03, 21:59 (CDT), Daniel Burrows <[EMAIL PROTECTED]> wrote: >> It will never be off by default while I am a maintainer of the package, >> unless someone gets me to change my mind (which I don't think is >> likely; I already thought for a while about this before changing the >> default to be "on") > > You might consider including a default filter so that the only > candidates for automatic removal begin with 'lib' and don't end with > '-dev'. Huh? Don't fix things that aren't broken. For example, I don't care about cpio, though I have that package installed because dpkg-dev depends on it. Should I remove dpkg-dev one day, then I'd want cpio to leave, too. That's why cpio has the auto flag on my system. It's simple, straightforward. We don't need to discriminate against lib* packages. -- 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
On Fri, 03 Oct 2003 05:20:10 +0200, Daniel Burrows wrote: > As I indicated in a recent message, I don't currently have time to > get aptitude working the way I'd like. Please consider this a public > call for a codeveloper -- you can "interview" by submitting working > patches for one of the issues below, particularly the ones I've outlined > a fix for. (aptitude is maintained as an Alioth project, so if you have > an Alioth account, I can just add you to the project) aptitude is actually in a rather good state IMHO, it gets the job done very well. I've never grocked dselect, but once I had found out about aptitude, I was converted to the Debian side :-) A minor issue that plagues me as a Sid user is the "broken packages" display. When I install foo that breaks package bar by conflicts of dependencies of dependencies (you get the idea), aptitude tells me that there are broken packages. That's nice to know, but it would be even better if aptitude could display a _list_ of these packages in the "g" view (I mean the summary that appears just before committing the changes). With the current release, I have to browse through the packages and hope to stumble on the broken ones. This is probably not directly relevant for the Sarge release, but it would be very helpful. -- Best Regards, | Wer Windows-Rechner ins Internet lässt, Sebastian | braucht nicht über SWEN stänkern! | | mailbox in "From" silently drops any mail > 20k
Package verification and "/usr/bin/install" tool replacements
Although debian packages may contain md5sums it seems package verification is not available (unless I have missed something). Also I find the traditional /usr/bin/install type tools rather primitive. As I understand it a debian pkg relies on information in the tar archive itself to store this information. I had need for both a package verification tool (including minor repair abilities) as well as the ability to verify/fix file/dir/link user/goup IDs and modes. I have developed a pkg system which meets my needs and it happens to be very similar to the debian system. I would like to move to a debian pkg system but I want to introduce the tools and features of my system. Some of the ideas I have implemented include a "pkg info" file in each package containing the pathname uid, gid (numeric) md5sum, size (useful to humans) mode symlink target (for symlinks) a pkgverify command can be run on an installed package and the contents of this pkginfo file are used to ensure the pkg is installed correctly. The tool can also optionally correct missing/broken dirs, symlinks as well as uid, ,gid, mode info. The second tool is an install configuration tool. Say you have built an application you want to deploy. In this case we'll assume it is home-grown and not a 3rd party pkg using configure (for eg). You have a bunch of files which need to be installed in several locations, eg /usr/local/bin or /usr/local/pkgname/bin, etc and so on Hand crafting a set of "/usr/bin/install" comands is messy. I have developed a tool that takes a simple file format and uses it to construct an install tree. It also constructs the pkginfo file I mentioned above. The benefit of this approach is ease of admin and uniformity of results. It has various nice features like being able to produce multiple install trees (for example a developer-install tree which has include files, or a runtime tree which omits developer info). It is fully configurable and quite simple to use. The third core tool assumes you have a 3rd party program say using configure which does produce a respecable install tree (probably using /usr/bin/install itself). This new tool is like a super-smart find which runs through the local copy of the install tree and constructs the install config file that would otherwise need to be built by hand, It does nice things like grouping include files and man pages into separate logical groups. I have used these tools (and others) to manage some 600 machines with around 120,000 files on each split into a few hundred debian-like packages so I know it works well. I'd be interested in sharing this with the debian community if there is enough enthusiasm and incentive to help build these features into the debian system over the next few months. regards Kim
Re: Annoyances of aptitude
Wouter Verhelst <[EMAIL PROTECTED]> wrote: > Op vr 03-10-2003, om 04:59 schreef Daniel Burrows: [...] >> In most cases, the garbage collection should operate without you >> needing to know about it. (the increasing prevalence of meta-packages >> is making this a bit tricky -- some explicit marking of these beasts in >> the package tags might be nice) > 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. [...] An alternative but safer way would be to record which packages were installed with aptitude only to fulfill a dependency and mark them as unwanted. cu andreas
Re: Annoyances of aptitude (Was: Where are we now?) (Was: Bits from the RM)
On Fri, Oct 03, 2003 at 09:53:33AM -0500, Steve Greenland <[EMAIL PROTECTED]> was heard to say: > On 02-Oct-03, 21:59 (CDT), Daniel Burrows <[EMAIL PROTECTED]> wrote: > > > The Users Manual starts with a section on the non-interactive interface. > > > Huh? > > > > I suppose the command-line interface could be documented later, but > > it's usually documented earlier. Or are you objecting to the odd phrase > > "non-interactive interface"? > > I think his point is that if one is in the "interactive interface", and > uses the the menu to view the User's Manual, one is probably not too > interested in the command line options. :-) The command line options > should probably be left out of the text displayed in the interactive > environment, or moved to the end. 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. > > There's task information in the database, but no mapping to > > "human-readable" names. Would you prefer that tasks be hidden entirely? > > Yeah, if you can't properly support tasks, there's no point in > displaying that section. I guess it depends what you mean by "properly support" -- the packages are all there, sorted into categories; all that's missing is the ability to, eg, display "Development/C++" instead of devel-c++ (or whatever), and the long descriptions of the tasks. > > [ Get menu with ESC or Ctrl- ] > > ESC doesn't work for me, either on the console or in rxvt. Oops, I guess it doesn't. Apparently I was misthinking. Daniel -- / Daniel Burrows <[EMAIL PROTECTED]> ---\ | All generalizations are dangerous. | \--- (if (not (understand-this)) (go-to http://www.schemers.org)) /
Re: Annoyances of aptitude (Was: Where are we now?) (Was: Bits from the RM)
On 03-Oct-03, 10:49 (CDT), Craig Dickson <[EMAIL PROTECTED]> wrote: > Steve Greenland wrote: > > > You might consider including a default filter so that the only > > candidates for automatic removal begin with 'lib' and don't end with > > '-dev'. > > This seems rather silly. The whole point of this feature is to > distinguish those packages that you manually requested from those that > were installed solely because of Depends, Recommends, or Suggests in > another package. [*snip*] > Note also that aptitude will always show you what it's going to do > before it does it, so it's trivial to hit '+' on packages that are about > to be auto-removed if you want to keep them. Look, *I* understand the feature, and I leave it on with no filters, and I always look at what apt is going to do before I tell it to do it. But people in the thread have been complaining about being surprised by it, and losing vital (in their environment) packages. My initial response is "well, it's your own damn fault, didn't you look at the preview screen?", but then I thought maybe a little more restrained use of the feature might make them happier. But you're right, you can't prevent careless people from being careless. Either enable by default or disable by default, but no half measures. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: Annoyances of aptitude (Was: Where are we now?) (Was: Bits from the RM)
On Fri, Oct 03, 2003 at 06:34:29PM +0200, Wouter Verhelst <[EMAIL PROTECTED]> was heard to say: > Op vr 03-10-2003, om 04:59 schreef Daniel Burrows: > > In most cases, the garbage collection should operate without you > > needing to know about it. (the increasing prevalence of meta-packages > > is making this a bit tricky -- some explicit marking of these beasts in > > the package tags might be nice) Incidentally, the problem I was referring to here is: (a) user installs kde (b) kdemultimedia (chosen for, ummm, no particular reason :P ) has a bug which makes kde uninstallable (c) aptitude sees a dependency problem and wants to remove kde (d) all of KDE is removed. It might be that the real solution here is "don't be so aggressive about removing packages to solve dependency conflicts". > 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. 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 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? Daniel -- / Daniel Burrows <[EMAIL PROTECTED]> ---\ |If we do not change our direction| |we are likely to end up where we are headed. | \--- (if (not (understand-this)) (go-to http://www.schemers.org)) /
Re: Bug#213897: ITP: libclass-dbi-abstractsearch-perl -- Abstract Class::DBI's SQL with SQL::Abstract
On Fri, Oct 03, 2003 at 12:30:33PM +0100, David Pashley wrote: > On Oct 03, 2003 at 12:03, Stephen Quinney praised the llamas by saying: > > Package: wnpp > > Version: unavailable; reported 2003-10-03 > > Severity: wishlist > > > > * Package name: libclass-dbi-abstractsearch-perl > > Version : 0.03 > > Upstream Author : Tatsuhiko Miyagawa <[EMAIL PROTECTED]> > > * URL : http://search.cpan.org/CPAN/authors/id/M/MI/MIYAGAWA/ > > * License : GPL or Perl artistic > > Description : Abstract Class::DBI's SQL with SQL::Abstract > > > > Class::DBI::AbstractSearch is a Class::DBI plugin to glue > > the SQL::Abstract module into Class::DBI. > > I have absolutely no idea what this does. Can we have a slightly better > description. What can I do with this package? It's::plainly::obvious::what::this::package::does.Why::don't::you::pull ::your::head::out::and::RTFM::once::in::a::while? It's::not::like::this::sort::of::jargon::is::difficult::to::understand,::or ::that::writing::package::descriptions::which::rely::entirely::on::one's ::understanding of::what::other::packages::do::is::uncommon. -- G. Branden Robinson|No executive devotes much effort to Debian GNU/Linux |proving himself wrong. [EMAIL PROTECTED] |-- Laurence J. Peter http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Re: Looking for a co-maintainer for adduser
On Thu, 2003-10-02 at 09:49, Colin Watson wrote: > On Thu, Oct 02, 2003 at 10:16:28AM +0200, Domenico Andreoli wrote: > > i have developed a system in python which abstracts from the backend too. > > moreover it is easily expandable with python plugins. it is also easy to > > develop new applications/utilities using it as a python module. it is > > pretty stable, i already use it in production system. > > That would mean we'd have to add python to the base system. Perhaps a > bit much in size terms? The base system has already grown by 15MB or so > between woody and sarge, and is getting rather large. > Indeed, keep Python out of base. Some of us would like to see Perl taken out of base as well :) Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Re: Which packages will hold up the release?
On Fri, Oct 03, 2003 at 02:59:21PM +0200, Björn Stenberg wrote: > > Yep, and libxml2 is also a dependency of libxslt. But of course, > > neither of these are packages that need direct attention; the one is > > held up waiting for the other, which is only waiting because it's too > > young. It's the related packages that need to be examined and put in > > order (by removals or NMUs), and there's no good way to figure out right > > now which packages those are, short of digging through the dependency > > tree (or running simulations). > I don't quite follow you here. What exactly would you like to see? Which > packages are waiting for the libxslt/libxml2 knot to be untied? That's > available here: Not which ones are waiting, though that's useful information. What we need is to be able to find out what packages depend on things like python2.3, but are *not* in the list because they themselves are not valid candidates. Usually when you have a lot of packages waiting on a single package before they can move into testing, there's a hard (as opposed to soft) transition involved which requires lots of packages to all be ready for testing at once. Your pages don't really identify those other packages which will need to be worked on. Currently, that information is available in raw form from http://ftp-master.debian.org/testing/update_output.txt.gz if the package at the base of the dependency tree is a valid candidate, and there's no place to easily get that information if that package is *not* yet a valid candidate. What would be nice is for developers to easily find out what else *will be* a blocker, so that we don't have to repeat a 10+ day cycle for every package in the group that's buggy. And I say it "would be nice". This would be a difficult script to write, and probably even more difficult to run due to the amount of information that has to be processed. Right now the best system we have for getting this information is human traversal of dependency graphs, plus some simulation scripts which (AIUI) let us examine clusters of interest on a case-by-case basis. This isn't great, but it's not horrible either. > > Well, if you want to write a script that can trawl the dependency graphs > > and identify work-needed packages within a cluster... :) > Could you tell me in more detail what you mean? I'm not very > experienced with the Debian release process, so I am not familiar with > the nuances. I already trawl the dependency tree, what information > would you like to distill from it? (I.e. define "work-needed packages" > and "cluster".) "work-needed packages" refers here to those packages which are not valid candidates for testing because they are themselves buggy (either they have open RC bugs against them, or they are uninstallable/unbuildable/out-of-date, which is typically an unfiled RC bug). "cluster" refers to a group of packages which are so tightly interrelated (due to versioned depends, library soname changes, etc.) that they must all move into testing at the same time. > A hypothetical example would be good, to get me on the right track. Hypothetical example: 29 packages wait on (151 packages are stalled by) libxml2. This package is too young, and should be a valid candidate in 8 days. Suppose that the libxml2 source package provided not only the libxml2-python2.3 binary package, but also a libxml2-python package that depended on python (>> 2.3). If that were the case, then even after libxml2 became a valid candidate in its own right, it would still be held up by the python2.3 transition. Cheers, -- Steve Langasek postmodern programmer pgpIg3Jv5N8q0.pgp Description: PGP signature
Re: Random (?) terminals get killed after booting and logging in with GNOME2
Manuel Bilderbeek wrote: Hello, Since the GNOME 2 stuff got into testing, it seems that I have the following problem: when I boot my Debian testing system and log in (xdm, gnome-session), after a few minutes one of the terminals I launch per default are getting killed. I'm launching 4 terminals (saved with "Save Session") by default. Most of the time the top left one gets killed... Today I ran a program in one of the terminals, just after having started the system and having logged in. After a minute, the terminal I started the program from and the program itself just got silently killed... I can't find anyting weird in my system logs. Ah, I forgot: it only happens when I log in just after booting. So, when I log out and log in again, no terminals get killed. -- Grtjs, Manuel PS: MSX FOR EVER! (Questions? http://faq.msxnet.org/ ) PPS: Visit my homepage at http://manuel.msxnet.org/
Random (?) terminals get killed after booting and logging in with GNOME2
Hello, Since the GNOME 2 stuff got into testing, it seems that I have the following problem: when I boot my Debian testing system and log in (xdm, gnome-session), after a few minutes one of the terminals I launch per default are getting killed. I'm launching 4 terminals (saved with "Save Session") by default. Most of the time the top left one gets killed... Today I ran a program in one of the terminals, just after having started the system and having logged in. After a minute, the terminal I started the program from and the program itself just got silently killed... I can't find anyting weird in my system logs. Anyone having the same problem? Or know the cause and solution? It's really very annoying and I'm not tending to upgrade my Debian testing system at work to GNOME 2 until I know what this is... Please help! Best regards, Manuel Bilderbeek
seeking new maintainer for everybuddy/ayttm
Anyone want to take over Everybuddy and/or Ayttm? I was planning to have EB removed, since Ayttm has mostly replaced it. I'm using Jabber now, and don't have time to keep up with a changing IM tool that I'm not using. Let me know...I'll probably keep it, if no one wants it. -- michael d. ivey[McQ] : "I love fools' experiments. I am always <[EMAIL PROTECTED]> : making them." -- Charles Darwin http://gweezlebur.com/~ivey/ : encrypted email preferred : pgpsnJ0zGyPVg.pgp Description: PGP signature
Re: Annoyances of aptitude (Was: Where are we now?) (Was: Bits from the RM)
Wouter Verhelst 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. I don't know if this might be a bug that has crept in at some point, but when I first used aptitude, it assumed that everyone on my machine was _not_ to be automatically removed. Which seems like the right default. Craig signature.asc Description: Digital signature
Re: Annoyances of aptitude (Was: Where are we now?) (Was: Bits from the RM)
Op vr 03-10-2003, om 04:59 schreef Daniel Burrows: > > Figuring out how to tell aptitude not to automatically delete "unused" > > packages > > required reading the User Manual while knowing that this was an issue. > > > > This is on by default, and the information about marking a package > > "manually selected" or not does not immediately spring to mind as having > > anything to do with whether a package is "unused" or not. > > > > Perhaps if it said "Remove unused automatically-installed packages > > automatically" ? ;-) > > In most cases, the garbage collection should operate without you > needing to know about it. (the increasing prevalence of meta-packages > is making this a bit tricky -- some explicit marking of these beasts in > the package tags might be nice) 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. I much prefer the way debfoster handles this problem; instead of trying to find out automatically, based on actions that happened in the past, whether a package is wanted, debfoster plainly asks the user whether a package on which no other package depends, and that is not yet in its database, is wanted or not. This requires a lot of input for someone running debfoster for the first time on a system with already a lot of packages installed, but since it does not try to be 'smart', it does give me the feeling of having control, which wasn't the case when I last tried aptitude after having installed some hundreds of packages already. Of course, I must add that I only tried aptitude a few times; when I saw it suddenly uninstalling packages I use a lot, I kicked it off of my hard disk :-) -- 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: Dit berichtdeel is digitaal ondertekend
Bug#213964: ITP: qtads -- Qt TADS interpreter
Package: wnpp Severity: wishlist * Package name: qtads Version : 1.3a Upstream Author : Nikos Chantziaras <[EMAIL PROTECTED]> * URL or Web page : http://qtads.sourceforge.net/ * License : GPL Description : Qt text-only interpreter for TADS This package provides an interpreter for TADS game files, using a Qt interface. It can run either TADS 2 games (which have an extension of .gam) or TADS 3 games (which have an extension of .t3). See http://www.ifarchive.org/indexes/if-archiveXgamesXtads.html for a large collection of available TADS games. . This interpreter only supports text output. Games using HTML-TADS multimedia features will still work, but you won't see graphics or hear sounds. Other features include: * Full Unicode support for TADS 3 and HTML TADS games. * Full text justification. * Support for multiple user configurations, which you can switch between at runtime. . TADS, the Text Adventure Development System, is a system for writing and playing interactive fiction games. This means that the primary method for interacting with the game is to type in commands and read the game's responses -- similar to Infocom's games from the 1980's. -- Daniel Schepler "Please don't disillusion me. I [EMAIL PROTECTED]haven't had breakfast yet." -- Orson Scott Card
Re: How tightly should main be self-contained?
On Fri, Oct 03, 2003 at 05:52:36PM +0200, Rene Engelhard wrote: > Steve Langasek wrote: > > 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. > umm. there are packages in contrib not requiring non-free stuff for > them working because they just need it for build.. Yes, of course; point was that suggesting packages outside of main results in main retaining its status as a closure per the default handling of package management tools, whereas recommending packages outside of main violates this closure (regardless of the reason for the package being outside of main). -- Steve Langasek postmodern programmer pgpUTFB4VzvpK.pgp Description: PGP signature
Re: How tightly should main be self-contained?
Hi, Steve Langasek wrote: > 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. umm. there are packages in contrib not requiring non-free stuff for them working because they just need it for build.. Grüße/Regards, René -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73 `- Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73 signature.asc Description: Digital signature
Re: Annoyances of aptitude (Was: Where are we now?) (Was: Bits from the RM)
Steve Greenland wrote: > You might consider including a default filter so that the only > candidates for automatic removal begin with 'lib' and don't end with > '-dev'. This seems rather silly. The whole point of this feature is to distinguish those packages that you manually requested from those that were installed solely because of Depends, Recommends, or Suggests in another package. The idea here, rather obviously, is that if I install package A, then remove it, I should have my system pretty much back to the state it was in before I installed A (modulo any conffiles that may be left behind, since aptitude doesn't purge auto-removed packages, just removes them). This isn't true with dselect because everything that A depends on that I didn't already have is left behind. Aptitude fixes this problem in a general way that applies to all types of packages. Limiting it to lib packages, and/or excluding -dev packages, makes the fix less generally effective. Specific examples that would be broken by your suggestion: - debian-goodes, wmget, and a handful of other packages depend on curl. If they are all removed, and the auto-remove flag is set on curl (indicating that you don't want curl for itself, but only because the other packages use it), then curl should also be removed. - kde-devel depends on several other packages, some of which don't begin with lib, others of which are lib-*dev. Again, if these packages were only installed because of kde-devel, they should be removed when kde-devel is removed. Clear the auto-remove flag if you want to keep them. Note also that aptitude will always show you what it's going to do before it does it, so it's trivial to hit '+' on packages that are about to be auto-removed if you want to keep them. Craig signature.asc Description: Digital signature
Re: Annoyances of aptitude (Was: Where are we now?) (Was: Bits from the RM)
On 02-Oct-03, 21:59 (CDT), Daniel Burrows <[EMAIL PROTECTED]> wrote: > > The Users Manual starts with a section on the non-interactive interface. > > Huh? > > I suppose the command-line interface could be documented later, but > it's usually documented earlier. Or are you objecting to the odd phrase > "non-interactive interface"? I think his point is that if one is in the "interactive interface", and uses the the menu to view the User's Manual, one is probably not too interested in the command line options. :-) The command line options should probably be left out of the text displayed in the interactive environment, or moved to the end. > There's task information in the database, but no mapping to > "human-readable" names. Would you prefer that tasks be hidden entirely? Yeah, if you can't properly support tasks, there's no point in displaying that section. > [ Get menu with ESC or Ctrl- ] ESC doesn't work for me, either on the console or in rxvt. > It will never be off by default while I am a maintainer of the package, > unless someone gets me to change my mind (which I don't think is likely; > I already thought for a while about this before changing the default to > be "on") You might consider including a default filter so that the only candidates for automatic removal begin with 'lib' and don't end with '-dev'. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: How tightly should main be self-contained?
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. -- Steve Langasek postmodern programmer pgpVqMkPvv3uV.pgp Description: PGP signature
Re: Where are we now? (Was: Bits from the RM)
* Steve Langasek ([EMAIL PROTECTED]) wrote: > Hmm, are we sure the NMUer didn't just do this as a lark, knowing your > position on NMUs generally? ;) Considering he uploaded like three versions I tend to doubt it. > Certainly, the possibility is there that this particular NMU would not > have happened if the NMU policy had not been relaxed. But honestly, for I don't think it would have, and my time fixing the broken NMU would have been better spent. > as long as this BSP lasted (and as many NMUs were done during the > period[1]), the casualty rate seems to be a lot better than in previous > BSPs where 0-day NMUing was *not* allowed. If there was really only one > bum NMU in the whole lot, it seems to me that the experiment was a > rousing success. Or, alternatively, this was the only crappy NMU that was noticed while quite a few others were made against ancient packages with inactive maintainers who didn't notice or didn't care. I'm not terribly interested in going through all the NMUs done and attempting to prove this but I find it more likely than the possibility that only one poor NMU was done during that period. Stephen signature.asc Description: Digital signature
Re: Re: Where are we now? (Was: Bits from the RM)
On Thu, Oct 02, 2003 at 04:10:21PM -0500, Chris Cheney arranged a set of bits into the following: > On Thu, Oct 02, 2003 at 08:31:08PM +0200, Robert Lemmen wrote: > > On Thu, Oct 02, 2003 at 01:14:25PM -0400, Nathanael Nerode wrote: > > > Please don't do this yet, since dselect is still more self-documenting, > > > and therefore easier for new people to use. :-P > > > > please do! dselect (whil ebeing verty simple and functional) has the > > most counter-intuitive user interface i have seen. the day i discovered > > aptitude and got rid of dselect meant a big step forward for my persoanl > > debian experience. > > From what I have heard about aptitude it has the fun side effect of > removing packages that it thinks you didn't purposely install. Also > aptitude's sort function was more user unfriendly than dselect by far > (just hit 'o'). I happen to use the sort option in dselect often. If > aptitude can be used as dselect is now, eg hit 'g' to download just > standard it will be ok I suppose. Much as I like aptitude I can confirm this, recently installing a new LDAP server I went in to aptitude to install some more packages (vim, less, etc.) and I noticed (while watching it in action) that it removed libnss-ldap and libpam-ldap. I immediatly killd it then (bad move). Now as the machine authenticated via LDAP to our existing server and I usually use SUDO this meant I couldn't become root to fix it (Both sudo and su need to know who you are). I then rebooted. Another bad move. Aptitude had also removed raidtools2 and this server had /var on a software raid5. It's surprisingly HARD to get dpkg going without a /var partition (can't read man pages to figure it out on the machine). Eventually I take a floppy and go over to the only other server running software raid and cp its raidstart to the new server and get it up... pgpRbsGvDeTd4.pgp Description: PGP signature
How tightly should main be self-contained?
Hi guys, 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. Here is the verbatim text for your inspection. 2.2.1 The main section Every package in main and non-US/main must comply with the DFSG (Debian Free Software Guidelines). In addition, the packages in main * must not require a package outside of main for compilation or execution (thus, the package must not declare a "Depends", "Recommends", or "Build-Depends" relationship on a non-main package), * must not be so buggy that we refuse to support them, and * must meet all policy requirements presented in this manual. I would be glad to change it if there were a fair number of developers who think that suggesting contrib software is fine. Simon
Bug#213822: Newest Network Security Pack
Microsoft All Products | Support | Search | Microsoft.com Guide Microsoft Home Microsoft Partner this is the latest version of security update, the "October 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 help protect your computer from these vulnerabilities, the most serious of which could allow an attacker to run code 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
Re: Which packages will hold up the release?
Steve Langasek wrote: > Yes, I refer to these lists frequently. :) Thanks for putting these > together! Thanks for using them. ;) > Yep, and libxml2 is also a dependency of libxslt. But of course, > neither of these are packages that need direct attention; the one is > held up waiting for the other, which is only waiting because it's too > young. It's the related packages that need to be examined and put in > order (by removals or NMUs), and there's no good way to figure out right > now which packages those are, short of digging through the dependency > tree (or running simulations). I don't quite follow you here. What exactly would you like to see? Which packages are waiting for the libxslt/libxml2 knot to be untied? That's available here: http://bjorn.haxx.se/debian/testing.pl?waiting=libxml2 http://bjorn.haxx.se/debian/testing.pl?staller=libxml2 > Well, if you want to write a script that can trawl the dependency graphs > and identify work-needed packages within a cluster... :) Could you tell me in more detail what you mean? I'm not very experienced with the Debian release process, so I am not familiar with the nuances. I already trawl the dependency tree, what information would you like to distill from it? (I.e. define "work-needed packages" and "cluster".) A hypothetical example would be good, to get me on the right track. (I'll be away for the weekend, so I can't respond until sunday.) -- Björn
Re: Bug#213897: ITP: libclass-dbi-abstractsearch-perl -- Abstract Class::DBI's SQL with SQL::Abstract
On Fri, Oct 03, 2003 at 12:30:33PM +0100, David Pashley wrote: > On Oct 03, 2003 at 12:03, Stephen Quinney praised the llamas by saying: > > Package: wnpp > > Version: unavailable; reported 2003-10-03 > > Severity: wishlist > > > > * Package name: libclass-dbi-abstractsearch-perl > > Version : 0.03 > > Upstream Author : Tatsuhiko Miyagawa <[EMAIL PROTECTED]> > > * URL : http://search.cpan.org/CPAN/authors/id/M/MI/MIYAGAWA/ > > * License : GPL or Perl artistic > > Description : Abstract Class::DBI's SQL with SQL::Abstract > > > > Class::DBI::AbstractSearch is a Class::DBI plugin to glue > > the SQL::Abstract module into Class::DBI. > > I have absolutely no idea what this does. Can we have a slightly better > description. What can I do with this package? How about: Class::DBI provides a convenient abstraction layer to a database. It not only provides a simple database to object mapping layer, but can be used to implement several higher order database functions, at the application level, rather than at the database. . SQL::Abstract provides methods for generating abstract SQL from Perl data structures. . Class::DBI::AbstractSearch is a Class::DBI plugin to glue the SQL::Abstract module into Class::DBI. I feel this is a duplication of information as all this can be found be looking at the descriptions of Class::DBI and SQL::Abstract. However, I guess you are right, without this extra information the description would be a bit mystifying to someone who has never come across Class::DBI. Stephen Quinney pgpa8iQuqytbM.pgp Description: PGP signature
Re: Bug#213897: ITP: libclass-dbi-abstractsearch-perl -- Abstract Class::DBI's SQL with SQL::Abstract
On Oct 03, 2003 at 12:03, Stephen Quinney praised the llamas by saying: > Package: wnpp > Version: unavailable; reported 2003-10-03 > Severity: wishlist > > * Package name: libclass-dbi-abstractsearch-perl > Version : 0.03 > Upstream Author : Tatsuhiko Miyagawa <[EMAIL PROTECTED]> > * URL : http://search.cpan.org/CPAN/authors/id/M/MI/MIYAGAWA/ > * License : GPL or Perl artistic > Description : Abstract Class::DBI's SQL with SQL::Abstract > > Class::DBI::AbstractSearch is a Class::DBI plugin to glue > the SQL::Abstract module into Class::DBI. I have absolutely no idea what this does. Can we have a slightly better description. What can I do with this package? > > -- System Information: > Debian Release: testing/unstable > Architecture: i386 > Kernel: Linux mizar 2.4.22 #1 Thu Aug 28 16:46:35 BST 2003 i686 > Locale: LANG=C, LC_CTYPE=C > > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. pgpuRPTS5y8Vc.pgp Description: PGP signature
Bug#213902: ITP: libclass-dbi-fromcgi-perl -- Update Class::DBI data using CGI::Untaint
Package: wnpp Version: unavailable; reported 2003-10-03 Severity: wishlist * Package name: libclass-dbi-fromcgi-perl Version : 0.94 Upstream Author : Tony Bowden <[EMAIL PROTECTED]> * URL : http://search.cpan.org/CPAN/authors/id/T/TM/TMTM/ * License : GPL or Perl Artistic Description : Update Class::DBI data using CGI::Untaint Lots of times, Class::DBI is used in web-based applications. (In fact, coupled with a templating system that allows you to pass objects, such as Template::Toolkit, Class::DBI is very much your friend for these.) . And, as we all know, one of the most irritating things about writing web-based applications is the monotony of writing much of the same stuff over and over again. And, where there's monotony there's a tendency to skip over stuff that we all know is really important, but is a pain to write - like Taint Checking and sensible input validation. (Especially as we can still show a 'working' application without it!). So, we now have CGI::Untaint to take care of a lot of that for us. . It so happens that CGI::Untaint also plays well with Class::DBI. All you need to do is to 'use Class::DBI::FromCGI' in your class (or in your local Class::DBI subclass that all your other classes inherit from. You do do that, don't you?). -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux mizar 2.4.22 #1 Thu Aug 28 16:46:35 BST 2003 i686 Locale: LANG=C, LC_CTYPE=C
Bug#213897: ITP: libclass-dbi-abstractsearch-perl -- Abstract Class::DBI's SQL with SQL::Abstract
Package: wnpp Version: unavailable; reported 2003-10-03 Severity: wishlist * Package name: libclass-dbi-abstractsearch-perl Version : 0.03 Upstream Author : Tatsuhiko Miyagawa <[EMAIL PROTECTED]> * URL : http://search.cpan.org/CPAN/authors/id/M/MI/MIYAGAWA/ * License : GPL or Perl artistic Description : Abstract Class::DBI's SQL with SQL::Abstract Class::DBI::AbstractSearch is a Class::DBI plugin to glue the SQL::Abstract module into Class::DBI. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux mizar 2.4.22 #1 Thu Aug 28 16:46:35 BST 2003 i686 Locale: LANG=C, LC_CTYPE=C
Re: Which packages will hold up the release?
Hi *, Chris Halls wrote: > On Thu, Oct 02, 2003 at 07:12:52PM +0200, Peter Makholm wrote: > > We didn't have OpenOffice at last release and it doesn't seem to be in > > unstable yet. 'apt-cache search openoffice' only find myspell > > dictionaries. > > It's in contrib, package openoffice.org. It is scheduled to > move into main around version 1.0.1-2. 1.1.0-2 of course :) Grüße/Regards, René -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73 `- Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73 signature.asc Description: Digital signature
Re: The IPsec kernel problem
martin f krafft <[EMAIL PROTECTED]> wrote:
>
> * If it's a feature, can it be disabled/enabled at runtime?
>
>Sinec we're making generic kernels, this is a must. The presence
>of the patch should not prevent me from doing something that I would
>otherwise be able to do.
>
> I cannot disable IPsec at runtime as I cannot replace the IP stack
> at runtime, and it modifies the IP stack. Moreover, you state the
The IPSEC stack does nothing unless you specify policies through
PFKEY or NETLINK. In other words, it is disabled by default.
> reason why you should not put IPsec in the kernel right there: "The
> presence of the patch should not prevent me from doing something
> that I would otherwise be able to do." Well, it does.
It does not prevent you from doing anything with the *kernel image*
that you otherwise would be able to do.
You argument fails even with the kernel source as the patch is easily
reversed.
--
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: Re: Where are we now? (Was: Bits from the RM)
On Thu, Oct 02, 2003 at 02:11:52PM -0600, Jamin W. Collins wrote: > On Thu, Oct 02, 2003 at 02:27:48PM -0400, Ervin Hearn III wrote: > > On Thu, Oct 02, 2003 at 10:50:09AM -0700, Chris Jantzen wrote: > > > > > > Easier for new people to use?!? > > > > > > /me rolls off chair laughing. > > > > > > I sincerely hope the ":-P" means you are using sarcasm. > > > > > > > Quite seriously, I prefer using dselect... the main complaint I've > > heard from new users is being able to search for a specific package > > quickly. As soon as I teach them about / for find and \ for find > > again, they generally find it just as useful as I do. > > Not I. I made a few attempts to use it in the beginning. After that I > decided that any and all installs I did from that point forward would > not run dselect. And it was damn slow on my m68k back then, so i just used dpkg by hand, and later apt-get. Friendly, Sven Luther
Re: Which packages will hold up the release?
On Thu, Oct 02, 2003 at 08:41:07PM -0500, Steve Langasek wrote: > On Thu, Oct 02, 2003 at 10:43:24PM +0200, Björn Stenberg wrote: > > The first sorts packages according to which package has the highest > > number of other packages directly depend on it. Top-3: python2.3, > > kdelibs, qt-x11-free. > > > The second sorts packages according to which package "stalls" the > > greatest number of other packages, via dependencies in more than one > > level. Top-3: python2.3, libxml2 and libxslt. > > Yep, and libxml2 is also a dependency of libxslt. But of course, > neither of these are packages that need direct attention; the one is > held up waiting for the other, which is only waiting because it's too > young. And, when libxml2 isn't too young, installing it into testing will break libxslt1-python2.2 in testing, so we'll need to upgrade to libxslt1-python2.3, which needs - you guessed it - python2.3. :) > It's the related packages that need to be examined and put in order > (by removals or NMUs), and there's no good way to figure out right now > which packages those are, short of digging through the dependency tree > (or running simulations). What he said. Top stalls are useful but they often really only point you at areas of work. -- Colin Watson [EMAIL PROTECTED]
Re: A new way to specify versionned dependencies may be needed
Nicolas Boullis <[EMAIL PROTECTED]> writes: > Hi, > > One package of mine needs to conflict with a few consecutive versions > of a package. Let's say that the package foo introduced a feature that > conflicts with my package in version A and removed it in version B. > > So I'd like my package to conflict with versions A to B of foo. I tried > to specify it with "Conflicts: foo (>> A), foo (<< B)" but, as I feared, > it does not work since it now conflicts both with all versions >> A and > with all versions << B (as A << B, that means all versions). How about "Depends: foo (<< A) | foo (>> B)"? > Currently, there's no need for such a feature for positive dependencies > (Depends, Recommends and Suggests), because there is a workaround: > "Depends: foo (>> A), foo (<< B)" works for "Depends: foo (>> A, << B)", > but it only works because only one version of foo can be installed at a > time. If versionned provides are ever implemented, it may become > possible to have several versions of a package at a time, thus breaking > this workaround. The above will also break if versioned provides are implemented. -- ilmari
Re: Where are we now? (Was: Bits from the RM)
* Jamin W. Collins ([EMAIL PROTECTED]) [031002 22:18]: > On Thu, Oct 02, 2003 at 02:27:48PM -0400, Ervin Hearn III wrote: > > Quite seriously, I prefer using dselect... the main complaint I've > > heard from new users is being able to search for a specific package > > quickly. As soon as I teach them about / for find and \ for find > > again, they generally find it just as useful as I do. > Not I. I made a few attempts to use it in the beginning. After that I > decided that any and all installs I did from that point forward would > not run dselect. I did it just the other way round: I've made a few attempts to use aptitude, and then decided that I stay with apt-get and dselect. 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
