Re: LDAP gateway broken?
On Mon, 8 Dec 2003, John Goerzen wrote: > I just sent my first-ever message to the LDAP gateway to reset my > password. I got the below message back. BTW, my clock is accurate. > > I used the exact "echo" command given in the docs. > > Also, I received no other reply. There is a small bug in the script, if for some reason the LDAP sever is unreachable then it adds the signature of your message to the replay cache and returns TEMPFAIL to exim which retries your message and then fails it because the replay cache already has it.. Try again. Be sure to make a new sigature. Jason
password setting via db.debian.org working?
Following the instructions on https://db.debian.org/password.html, I have tried to get a new password. This has had no apparent effect, although I've tried it a few times now. I haven't received a bounce or a reply. Anyone else experienced this? (Not a huge deal, because I can still log in with my DSA key set via the db email interface. But I can't log into, e.g., the db.debian.org webpage to update my personal info with a DSA key.) -- "The road to hell is paved with convenient shortcuts." --Peter da Silva
compromised servers.
Is there a scheduled time to see the compromised servers up again? sincerely.
Re: password setting via db.debian.org working?
Ben Pfaff wrote: Following the instructions on https://db.debian.org/password.html, I have tried to get a new password. This has had no apparent effect, although I've tried it a few times now. I haven't received a bounce or a reply. Anyone else experienced this? Use the "| mail [EMAIL PROTECTED]", and don't use as sender your "[EMAIL PROTECTED]". Yesterday I had problems, then I logged in a my remote machine to do the "cat - | mail" and it solved the problem. I don't make tests, just changed and it worked, So IMO the cause can be ONE of this: * 'chpasswd' is confused by MUA headers and it send or not the reply (but it is processed) * 'chpasswd' is confused by debian.org and it send or not the reply (but it is processed) * debian.org route from 'chpasswd' is slw. (But I received other mails via @debian.org ciao giacomo
Re: recovery status update
On Fri, Dec 05, 2003 at 01:51:54AM +, James Troup wrote: > Where can I login? > -- > > There's been a fair bit of talk post-compromise about restricting > access to machines running (core) services. At the moment, the only > thing I'm (personally) doing is not enabling non-services accounts on > auric (ftp-master) and klecker (security, non-US, qa, nm, www-master) > immediately. Obviously, it's useful for random developers to have > access to e.g. the postgres database of the archive, so the current > plan if the restricted nature of auric becomes permanent is to mirror > the system daily to another box that would be unrestricted. [This > would have the added bonus of giving us a hot spare for > disasters/arson attacks etc.] > > Basically the whole issue of what, if anything, to restrict is still > up in the air. I'm looking for input/opinions/discussion on this. If > you need access to the machines running the archives, please tell me > (or probably better yet, start a thread on debian-devel) why. It makes a lot of sense to restrict auric permanently and have an up-to-date mirror for general access purposes. The issues I can think of are: - how to run the DELAYED queue (to give the possibility of deleting things from it or to see what's in it) - how to give developers the possibility of seeing what's in the queue (daily rsyncs are not good enough for this; I've frequently pulled packages from the accepted queue to check that bug fixes have been correctly applied) Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, website: http://www.polya.uklinux.net/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry
APT-Fu 0.2.3 (was: Re: Building Debian Completely From Source)
Eric Wong <[EMAIL PROTECTED]> wrote: > John Goerzen <[EMAIL PROTECTED]> wrote: > > On Fri, Dec 05, 2003 at 05:48:21PM -0800, Eric Wong wrote: > > I have one feature request: I'd like to have an option so that I can ask > > it to rebuild arch-indep packages just like it rebuilds other packages. > > In other words, a "never download any .deb, ever" option :-) > > Rebuilding arch-indep packages is no problem, and I'll gladly add an > option for that. An option for 100% source packages will also be added, > but I'll also put a fat warning in there about circular dependencies. Check. --source-only / APT::Fu::SourceOnly > > > Though it takes some configuring. > > > > I'd like to be able to set that one, too... just do the upgrade for all > > packages. But that effect can be simulated now with dpkg > > --get-selections. > > OK, I'll add an option for that. Check. --source-upgrade-all / APT::Fu::SourceUpgradeAll > OK, I'll do my best to have all the changes you requested done and > tested by tomorrow. Let me know if you have any other feature requests > and/or bug reports. Sorry I took so long, but the 0.2.3 release should have everything you wanted. deb http://www.yhbt.net/normalperson/debian ./ deb-src http://www.yhbt.net/normalperson/debian ./ It passes lintian. Feedback/comments/bug reports on the package would be greatly appreciated, thanks! -- Eric Wong[EMAIL PROTECTED] Petta Technology, Inc [EMAIL PROTECTED]
Re: Backport of the integer overflow in the brk system call
On Tue, Dec 09, 2003 at 11:45:58PM +1100, Russell Coker wrote: > > As for acting like a Jackass, the Johnny Knoxville and his colleagues are > very > talented entertainers who work hard. I wouldn't compare them to you in any > way. Oh, I dunno. I got *your* attention. But chill the hell out. I'm disengaging. My point (such as it is) is accomplished. Nothing but technical matters from me from here on. Save the bitching for next time.
Re: Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Tue, Dec 09, 2003 at 02:06:48PM +0100, Moritz Moeller-Herrmann wrote: > freedesktop entry features > debian menu file features > > Therefore you can do a lossless transition from .desktop to menu, but not > the other way around. It makes sense to use the .desktop standard. I know what you mean, but don't you mean "lossless transition from menu to .desktop" ? .desktop is the one that has more features, so a transition from .desktop to menu would lose. It's trivial but I might not understand the issues if its the opposite.
Re: Backport of the integer overflow in the brk system call
On Tue, 9 Dec 2003 22:52, Tom <[EMAIL PROTECTED]> wrote: > On Tue, Dec 09, 2003 at 01:12:13AM +, Colin Watson wrote: > > . Could you please try > > to keep debian-devel posts to well-thought-out [1] technical content, > > Sure. I'd also ask everyone to keep their anti-American, anti-Bush SIGs > and random comments out of both lists. I have acted like a jackass on > purpose -- to give you a taste of what it feels like to put up with > incessant opinions which you find illogical. > > How about a cease-fire on both sides of the idological debate? There is no idological debate, there is no side that you are claiming to be against. I don't recall any messages in this thread that were anti-USian (*) or anti-Bush. As for acting like a Jackass, the Johnny Knoxville and his colleagues are very talented entertainers who work hard. I wouldn't compare them to you in any way. (*) I don't recall anyone writing anything on this list that could be anti-central-America, anti-south-America, or anti-Canada. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Scripsit Andrew Suffield <[EMAIL PROTECTED]> > On Tue, Dec 09, 2003 at 02:51:53AM +0100, Moritz Moeller-Herrmann wrote: > > You do realize that the desktop standard has more features than the debian > > menu system? Like i18n, icon theming, dynamic construction of a menu > > hierarchy based on user /Desktop system preferences and so on? [...] > Because you gain *nothing* Are you claiming that everyone who says that .desktop has technical advantages is a liar? These features actually do not exist in the desktop format? (It may be so; I have no firsthand information, but it does sound far out). -- Henning Makholm "Ambiguous cases are defined as those for which the compiler being used finds a legitimate interpretation which is different from that which the user had in mind."
Re: Backport of the integer overflow in the brk system call
On Dec 8, 2003, at 07:14, Julian Mehnle wrote: Apart from that, as soon as the use of IPv6 broadens, dynamically assigned IP addresses will diminish. Stateless autoconfig + privacy extensions means quite the opposite is likely to occur.
http://bugs.debian.org/release-critical/
The page says: 733 release-critical bugs were closed and NONE were opened. Is it a problem in the script, or there is something I haven't listen to? -- GNU GPL: csak tiszta forrásból
Re: password setting via db.debian.org working?
On Mon, Dec 08, 2003 at 10:17:44PM -0800, Ben Pfaff wrote: > Following the instructions on > https://db.debian.org/password.html, I have tried to get a new > password. This has had no apparent effect, although I've tried > it a few times now. I haven't received a bounce or a reply. > Anyone else experienced this? > > (Not a huge deal, because I can still log in with my DSA key set > via the db email interface. But I can't log into, e.g., the > db.debian.org webpage to update my personal info with a DSA key.) I only get a reply from any of the userdir-ldap addresses if I send using mutt, not mail(1). I can't figure out what the significant headers are - afaict, the interesting ones are the same. Helpfully, changes@ can only parse mails I send with mail(1), not those I send with mutt, so I have to do it blind. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Andrew Suffield wrote: > On Tue, Dec 09, 2003 at 02:51:53AM +0100, Moritz Moeller-Herrmann wrote: >> You do realize that the desktop standard has more features than the >> debian menu system? Like i18n, icon theming, dynamic construction of a >> menu hierarchy based on user /Desktop system preferences and so on? And >> that this information would be lost? Why not run it the other way around, >> convert the existing debian menu entries to .desktop files and work from >> there? I think that this way would help debian on the desktops. > > Because you gain *nothing* and introduce a pointless transition. The question to solve is: In which format shall application packages store their menu information. Users and developers propose following the freedesktop standard and using this. Freedesktop standard supporting systems are probably used by 90% of all Debian desktop users. Now you say: "No let's use the debian menu system, which only we use and which is not the default of any major WM". This means losing i18n, dynamic construction of menus and icon theming in 90 % of the desktop, because Debian menu items do not support these features. How is this logical? How does the freedesktop standard not "gain" us features? > None of which is the problem of the menu package. It just has to read > the fields and pass them to the methods, which then write out suitable > data files for the frontend. In the case of kde/gnome, that would be a > .desktop file; for everything else, yes, the data is thrown > away. Nothing else supports those features, and this is again not our > problem. freedesktop entry features > debian menu file features Therefore you can do a lossless transition from .desktop to menu, but not the other way around. It makes sense to use the .desktop standard. Then those desktops who support it (KDE+Gnome+??) can use the desktop files directly. For other (older or simpler) desktops the debian menu system has to be adapted to use the .desktop files (addditionaly or instead of the menu files). I don't understand how anyone can not support this change. -- Moritz Moeller-Herrmann [EMAIL PROTECTED] wiss. Mitarbeiter, IMGB La loi, dans un grand souci d'égalité, interdit aux riches comme aux pauvres de coucher sous les ponts, de mendier dans les rues et de voler du pain. (ANATOLE FRANCE)
Re: Assurance measures: ALC (The hidden treasure of Debian)
Magosányi Árpád wrote: > (Well, the word "confidentality" is not applicable in our > case. Otherwise there are numerous measures.) It is, Debian has decided to hide security bugs systematically from its users (albeit for a limited time only, but the process is there).
Re: LDAP gateway broken?
On Mon, Dec 08, 2003 at 10:52:31PM -0700, Jason Gunthorpe wrote: > Try again. Be sure to make a new sigature. Now I get: Error: An error occured while performing the LDAP lookup ==> Message Error: Key not found I signed with my normal Debian key: You need a passphrase to unlock the secret key for user: "John Goerzen <[EMAIL PROTECTED]>" 1024-bit DSA key, ID 6021F84B, created 2002-01-16 (main key ID 8A1D9A1F) -- John
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Tue, Dec 09, 2003 at 01:57:29PM +, Henning Makholm wrote: | > Because you gain *nothing* | | Are you claiming that everyone who says that .desktop has technical | advantages is a liar? These features actually do not exist in the | desktop format? (It may be so; I have no firsthand information, but it | does sound far out). Most of the advantages of .desktop that I am aware of are currently vapourware - i.e. they're in the specs on the freedesktop.org site, but not yet implemented in KDE and Gnome. However, since both KDE and Gnome developers helped to write the specs in question, it seems not altogether unreasonable to expect some kind of implementation of them in the future. Internationalisation is the big one that's here already, and IMHO should be added to the Debian menu system regardless of any outcome w.r.t. freedesktop. The relevant pages on the freedesktop.org site are: http://freedesktop.org/Standards/desktop-entry-spec/desktop-entry-spec-0.9.4.html http://freedesktop.org/Standards/menu-spec/menu-spec-0.8.html Cameron.
Re: LDAP gateway broken?
An added note: When I forced gpg to not use the subkey for the sig, it worked. -- John On Tue, Dec 09, 2003 at 08:22:16AM -0600, John Goerzen wrote: > On Mon, Dec 08, 2003 at 10:52:31PM -0700, Jason Gunthorpe wrote: > > Try again. Be sure to make a new sigature. > > Now I get: > > Error: An error occured while performing the LDAP lookup > ==> Message Error: Key not found > > I signed with my normal Debian key: > > You need a passphrase to unlock the secret key for > user: "John Goerzen <[EMAIL PROTECTED]>" > 1024-bit DSA key, ID 6021F84B, created 2002-01-16 (main key ID 8A1D9A1F) > > -- John > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
Re: Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Andrew Suffield ([EMAIL PROTECTED]): > It's "pass a few more text fields through to the menu methods, and use > them to generate .desktop files" versus "rewrite everything". You sure it's "rewrite everything"? A script to parse all .desktop files in /usr/share/applications and output the same as 'update-menus --stdout' seems pretty simple and sufficient. Am I wrong? -Billy
Re: Backport of the integer overflow in the brk system call
On Tue, Dec 09, 2003 at 01:12:13AM +, Colin Watson wrote: > . Could you please try > to keep debian-devel posts to well-thought-out [1] technical content, Sure. I'd also ask everyone to keep their anti-American, anti-Bush SIGs and random comments out of both lists. I have acted like a jackass on purpose -- to give you a taste of what it feels like to put up with incessant opinions which you find illogical. How about a cease-fire on both sides of the idological debate? But I decided to cut down on the opinion posts; these are just reverberations from people catching up.
Re: Building Debian Completely From Source
On Dec 8, 2003, at 11:48, Matt Zimmerman wrote: On Sun, Dec 07, 2003 at 04:10:36PM +, Scott James Remnant wrote: make? You'll need make installed to make make. There are a huge number of legitimate circular build dependencies, outlawing them won't help. There are quite a few, but make is a bad example, as it has included a shell script to build itself for just this purpose. Which requires bash/dash/whatever, which require make. It's a slightly larger circle, but a circle no less.
Re: Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Tue, Dec 09, 2003 at 02:06:48PM +0100, Moritz Moeller-Herrmann wrote: > Andrew Suffield wrote: > > > On Tue, Dec 09, 2003 at 02:51:53AM +0100, Moritz Moeller-Herrmann wrote: > > >> You do realize that the desktop standard has more features than the > >> debian menu system? Like i18n, icon theming, dynamic construction of a > >> menu hierarchy based on user /Desktop system preferences and so on? And > >> that this information would be lost? Why not run it the other way around, > >> convert the existing debian menu entries to .desktop files and work from > >> there? I think that this way would help debian on the desktops. > > > > Because you gain *nothing* and introduce a pointless transition. > > The question to solve is: In which format shall application packages store > their menu information. Users and developers propose following the > freedesktop standard and using this. Freedesktop standard supporting > systems are probably used by 90% of all Debian desktop users. I doubt that is true. > Now you say: "No let's use the debian menu system, which only we use and > which is not the default of any major WM". This means losing i18n, dynamic > construction of menus and icon theming in 90 % of the desktop, because > Debian menu items do not support these features. Straw man. We can fairly easily add that stuff. > How is this logical? How does the freedesktop standard not "gain" us > features? Because it's not necessary in order to get those features, and they can be added more easily in another way. It's "pass a few more text fields through to the menu methods, and use them to generate .desktop files" versus "rewrite everything". -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: http://bugs.debian.org/release-critical/
On Tuesday 09 December 2003 15:56, Colin Watson wrote: > > 733 release-critical bugs were closed and NONE were opened. > master ran out of disk space, which confused it. I've fixed it now. Too bad. I wanted to believe it ;) Raphael
Re: http://bugs.debian.org/release-critical/
On Tue, Dec 09, 2003 at 02:11:08PM +0100, Magosányi Árpád wrote: > The page says: > > 733 release-critical bugs were closed and NONE were opened. > > Is it a problem in the script, or there is something I haven't > listen to? master ran out of disk space, which confused it. I've fixed it now. Thanks, -- Colin Watson [EMAIL PROTECTED]
Re: Initrd rocks! (was Re: Backporting 2.4.23 kernel packages)
Brian May <[EMAIL PROTECTED]> writes: > On Sun, Dec 07, 2003 at 02:02:10PM +1100, Russell Coker wrote: > > The recent versions of the package have significant problems if you want to > > convert to or from devfs. The Debian mkinitrd has become too complex to > > manage so I have chosen not to bother. > > This seems strange, perhaps the process is not entirely obvious, > but I wouldn't have thought it be too difficult. > > However, I have been disappointed with the initrd script for Debian in > that support for autodetecting software RAID1 is poor (read: > non-existant), and while RAID1 will work if the harddisks are plugged in > exactly the same way each time, the fact remains that the configuration > is hardcoded in the initrd script so if you move all harddisks on one > RAID set to different busses (for instance), it will stop working. > > This is distinct from the autodetection in the kernel that is capable of > automatically scanning all harddisks on all busses to find RAID devices. Why can't you use the kernel autoconfig or does that only work with build-in drivers? > So yes, maybe initrd/initramfs is the way of the future (I have read > proposals that would make loading modules in an initramfs compulsory for > all systems), but I think there are still a few issues that need to be > resolved first. Loading the modules won't help you getting raid or lvm configured. MfG Goswin
Re: Building Debian Completely From Source
On Tue, Dec 09, 2003 at 08:54:45AM -0500, Anthony DeRobertis wrote: > > On Dec 8, 2003, at 11:48, Matt Zimmerman wrote: > > >On Sun, Dec 07, 2003 at 04:10:36PM +, Scott James Remnant wrote: > > > >>make? You'll need make installed to make make. There are a huge > >>number > >>of legitimate circular build dependencies, outlawing them won't help. > > > >There are quite a few, but make is a bad example, as it has included a > >shell script to build itself for just this purpose. > > Which requires bash/dash/whatever, which require make. ...which require a kernel, and a C library, and a computer, and some memory. Yes, you need an actual, working Unix system in order to compile Unix programs. -- - mdz
Re: Building Debian Completely From Source
Matt Zimmerman <[EMAIL PROTECTED]> writes: > On Tue, Dec 09, 2003 at 09:52:39AM +1100, Herbert Xu wrote: > > > Matt Zimmerman <[EMAIL PROTECTED]> wrote: > > > > > > There are quite a few, but make is a bad example, as it has included a > > > shell script to build itself for just this purpose. > > > > But its debian/rules is a makefile since the policy requires it > > to be so, right? :) > > Yes, but building the complete Debian package is hopefully not necessary for > bootstrapping purposes, only to get a working make binary. Say I have bootstraped manually and installed all basic stuff (hey, we have 32 bit apps for everything on amd64 and the biarch compiler works fine :). Now I would like to compiled base, build-essential and bootstrap-essential debs from source (bootstrap-essential being debs needed to compiled everything from source). To rebuild all those every source package containing at least one of them has to be rebuild. Providing all the Build-Depends for all the debs build by a source quickly grows to quite a big bootstrap-essential set. Further more every library package that is build needs to be touched currently. Keeping a single lib out of the bootstrap-essential set means a lot of time is saved to get base + build-essential recompiled. For finishing a bootstraping or for a scorched earth rebuild it would be good if it where clear what deb requires which Build-Depends and if one could build only some debs of a source. I will describe an idea that came up talking about the problem now. Let me know what you think: Each deb (of a source) that can be build on its own (without building the other debs) gets a debian/package.control file which is just a reduced copy of the control file. The Build-Depends are reduced to whats required for this deb. If a debian/package.control file exist the debian/rules file must have a "binary-package:" target that will build the deb with the reduced Build-Depends from debian/package.control. The existance of debian/package.control is completly optional and suggested for cases where the Build-Depends for different Packages make a big difference for bootstrapping. Packages that cause the bootstrap-essential list to grow a lot (like things needing X11) are then singled out and patches send. MfG Goswin
Bug#223469: ITP: qca -- The Qt Cryptographic Architecture (QCA), cryptographic algorithmns for Qt programs
Package: wnpp Severity: wishlist * Package name: qca Version : not yet released, currently CVS only Upstream Author : Justin Karneges <[EMAIL PROTECTED]> * URL : http://psi.affinix.com/ * License : LGPL Description : The Qt Cryptographic Architecture (QCA) This library provides an easy Qt-compatible API for the following features: SSL/TLS X509 SASL RSA Hashing (SHA1, MD5) Ciphers (BlowFish, 3DES, AES) Functionality is supplied via plugins. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux sirith 2.4.22 #1 Sat Aug 30 16:40:19 CEST 2003 i686 Locale: LANG=C, [EMAIL PROTECTED] signature.asc Description: Digital signature
How to avoid multiple dependencies with shlibdeps
Hi,
I maintain a program which needs to depend on certain version of some
library (the earlier ones are incompatibile, despite soname wasn't
changed), but I would also like to use shlib:Depends for other
libraries.
Now I use:
Depends: libtlen1 (>= 20021117), ${shlibs:Depends}
But it generates duplicate dependency upon libtlen1, causing:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=171847
Is it possible to fix this in a simple way, or should I write my
dependencies manually, not using dh_shlibdeps?
If you answer, PLEASE CC to me, as I don't read debian-devel
regularly.
Regards
Adam
--
_.|._ |_ _. : Adam Byrtek /alpha [EMAIL PROTECTED]
(_|||_)| |(_| : pgp 0xB25952C0
|
密码更新了
密码大赠送的密码又更新了 http://film.wx-e.com/
Re: APT-Fu 0.2.3 (was: Re: Building Debian Completely From Source)
On Tuesday 09 December 2003 12:20, Eric Wong wrote: > Eric Wong <[EMAIL PROTECTED]> wrote: --cut-- > > OK, I'll do my best to have all the changes you requested done and > > tested by tomorrow. Let me know if you have any other feature requests > > and/or bug reports. First of all, thank you very much for the nice piece of perl. I've tested it for a while ... works like a charm ! It has a lot of features, although I havent tested them all. > Sorry I took so long, but the 0.2.3 release should have everything you > wanted. > > deb http://www.yhbt.net/normalperson/debian ./ > deb-src http://www.yhbt.net/normalperson/debian ./ > > It passes lintian. Feedback/comments/bug reports on the package would > be greatly appreciated, thanks! Hmm, none, for the time being. Have a look at http://www.debtoo.org/ and their struggle at implementing USE flags feature ? You may share some code/ideas with them. I guess this could be achieved thru the optFile(5) routine or am I missing something here. p.s. why Apt-Fu ? Is that 'APT Kung-Fu' or what ? Hmm, after apt-src, apt-build, and similar 'build that debian source package' tools, I've been expecting for 'apt-too' ;-) -- pub 4096R/0E4BD0AB 2003-03-18 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB
Re: How to avoid multiple dependencies with shlibdeps
On Tue, Dec 09, 2003 at 07:44:48PM +0100, Adam Byrtek / alpha wrote:
> Hi,
>
> I maintain a program which needs to depend on certain version of some
> library (the earlier ones are incompatibile, despite soname wasn't
> changed), but I would also like to use shlib:Depends for other
> libraries.
>
> Now I use:
>
> Depends: libtlen1 (>= 20021117), ${shlibs:Depends}
>
> But it generates duplicate dependency upon libtlen1, causing:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=171847
>
> Is it possible to fix this in a simple way, or should I write my
> dependencies manually, not using dh_shlibdeps?
You can use debian/shlibs. You will find documentation about this
in the man page for dpkg-shlibdeps.
> If you answer, PLEASE CC to me, as I don't read debian-devel
> regularly.
Greetings,
Oliver
--
.''`.
: :' :Oliver Kurth [EMAIL PROTECTED]
`. `' Debian GNU/Linux maintainer - www.debian.org
`-
today in my TODO list: prove the Goldbach conjecture
signature.asc
Description: Digital signature
Re: How to avoid multiple dependencies with shlibdeps
On Tue, Dec 09, 2003 at 07:44:48PM +0100, Adam Byrtek / alpha wrote: > I maintain a program which needs to depend on certain version of some > library (the earlier ones are incompatibile, despite soname wasn't > changed), but I would also like to use shlib:Depends for other > libraries. Shared library dependencies need to be fixed in the shared library package. If the information it supplies is wrong, then it must be fixed. Don't work around it in dependent packages. -- - mdz
Re: recovery status update
Julian Gilbey <[EMAIL PROTECTED]> writes: > It makes a lot of sense to restrict auric permanently and have an > up-to-date mirror for general access purposes. The issues I can think > of are: Although I agree that there is definitely something to be said for this approach, I would like to note an additional issue with it: - how to verify that katie will process uploads as expected (I'd been running dinstall -n, via dput -D; I suppose it would be possible to upload separately to the mirror and test there, but that's awkward.) > - how to run the DELAYED queue Extra ftp upload directories? sftp access to the full queue area? > - how to give developers the possibility of seeing what's in the queue I believe http://incoming.debian.org/ is functioning as usual (though it's a bit hard to tell shortly after a dinstall run ;-) ). Other queues, especially queue/new, can also be interesting to inspect, but mirror delay there would hardly be the end of the world. -- 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: Integrate Knoppix in Debian (was: Re: Debian Enterprise?)
On Wed, Nov 26, 2003 at 02:38:38PM +0100, Javier FernÃndez-Sanguino PeÃa wrote: > Ummm... You are wrong here. Knoppix (or Knoppix-derived versions) provide > three things: > ... > 4- a system to duplicate this live Cd into hard disk, making the necessary > changes based on what was auto-detected. Interesting. Point 4 of 3. :-) Anyway, one should notice that Klaus Knopper himself did not write these install scripts. His goal hasn't been to install the CD. The scripts are all contributed by other people. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
Re: RFS: phpgroupware
Jamin W. Collins wrote [in a different order]: > I've given most of the packages a cursory look. I do have a few > suggestions and may be willing to sponsor them. Thanks. > Packaging concerns: > - In several locations throughout the debconf questions you use "DBMS", > this should probably be replaced with simply "database". > - The wording of phpgroupware/postrm should probably be completely > redone. > - README.Debian currently contains a blurb about changing of package > maintainers. This file should contain the information/instructions > a user may need to configure the package. I've changed the debconf messages as suggested and added a pointer to the web based setup to README.Debian. However, I'd prefer to have a "work in progress" blurb in README.Debian, partially to acknowledge that there are still some things to be smoothed out. (The reason I believe an update is appropriate in spite of regarding this as "work in progress" is that the version fixes many errors (some severe and security) of the package currently in unstable.) > - The database admin password is stored in debconf. This should not be > done. Ask for it, use it, and then remove it from the database. What does this mean for the removal of the database upon purging the package? I don't have the impression that people will be very happy with debconf prompts in the postrm. (Of course, debconf might already have been removed in the postrm...) Should I just not drop the database? > Application concerns: > - When logged in as Setup/Config Admin >- configuration steps listed as completed, but values are blank or > point to non-existent directories. For example, step 2 > "Configuration" the value of "Enter the location of phpGroupWare's > URL." is blank by default and yet the configuration is completed. >- Wording of the second half of Step 2 is misleading. It indicates > all accounts will be deleted (none exist at first) and that it > _will_ create 1 admin and 3 demo accounts, but the demo accounts > are optional. The first point needs to be fixed, I'll look into it shortly. I'm not too sure that I'd want to muck with the wording too much, though. (e.g. I'm not too sure about what to do with the translations.) > - When logged in as Header Admin: >- all passwords are displayed in plaintext This is a difficult one. In particular, I don't think that changing the plaintext fields to password ones helps: Then the user might get the false impression that his passwords are not transferred over the net. On the other hand, I'd not trick the user into accidentially erasing his passwords. I'll look into transferring (and checking for) bogus passwords. Thanks for the comments. Regards T. pgpnwryzKHh0I.pgp Description: PGP signature
Re: Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Tue, 9 Dec 2003, Moritz Moeller-Herrmann wrote: > Andrew Suffield wrote: > > On Tue, Dec 09, 2003 at 02:51:53AM +0100, Moritz Moeller-Herrmann wrote: > > >> You do realize that the desktop standard has more features than the > >> debian menu system? Like i18n, icon theming, dynamic construction of a > >> menu hierarchy based on user /Desktop system preferences and so on? And > >> that this information would be lost? Why not run it the other way around, > >> convert the existing debian menu entries to .desktop files and work from > >> there? I think that this way would help debian on the desktops. > > > > Because you gain *nothing* and introduce a pointless transition. > > The question to solve is: > In which format shall application packages store > their menu information. It doesn't matter, software can make anything look like anything else... the question should be, "what requires more work: adding features to the existing menu system, or changing the entire menu system." > Users and developers propose following the > freedesktop standard and using this. Users and developers are also resisting the proposal. > Freedesktop standard supporting > systems are probably used by 90% of all Debian desktop users. Unsubstantial, and probably bullshit. > Now you say: "No let's use the debian menu system, which only we use and > which is not the default of any major WM". This means losing i18n, dynamic > construction of menus and icon theming in 90 % of the desktop, because > Debian menu items do not support these features. > > How is this logical? How does the freedesktop standard not "gain" us > features? Because nobody but KDE and Gnome use those features and they already support .desktop files. > > None of which is the problem of the menu package. It just has to read > > the fields and pass them to the methods, which then write out suitable > > data files for the frontend. In the case of kde/gnome, that would be a > > .desktop file; for everything else, yes, the data is thrown > > away. Nothing else supports those features, and this is again not our > > problem. > > freedesktop entry features > debian menu file features > > Therefore you can do a lossless transition from .desktop to menu, but not > the other way around. It makes sense to use the .desktop standard. True, but everyone except KDE and Gnome will toss out the freedesktop features. Processing bloated .desktop files just to toss the results is a waste of resources. > Then those desktops who support it (KDE+Gnome+??) can use the desktop files > directly. For other (older or simpler) desktops the debian menu system has > to be adapted to use the .desktop files (addditionaly or instead of the > menu files). older -> stability simpler -> faster, less resources hungry > I don't understand how anyone can not support this change. Because: Nobody benefits from the transition... not even KDE or Gnome, since they already support the features the freedesktop standard brings to the table. also There is currently no way to provide system-wide alternates to the distributed .desktop files. Only having per-user customisation available really, really, sucks, imo. and I regularily use KDE, UWM, pdmenu, and Fluxbox, I also have twm, xfce and mwm installed... processing the menues takes too much time and resources as it is, and you want to use up more, for what gain? - Bruce
Re: Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Tue, 9 Dec 2003, Tom wrote: > On Tue, Dec 09, 2003 at 02:06:48PM +0100, Moritz Moeller-Herrmann wrote: > > freedesktop entry features > debian menu file features > > > > Therefore you can do a lossless transition from .desktop to menu, but not > > the other way around. It makes sense to use the .desktop standard. > > I know what you mean, but don't you mean "lossless transition from menu > to .desktop" ? .desktop is the one that has more features, so a > transition from .desktop to menu would lose. > > It's trivial but I might not understand the issues if its the opposite. It is a metter of perspective. A transition from .desktop to menu only loses if the subsystems using the menu entries are capable of using the lost data. HTH - Bruce
Re: recovery status update
On Tue, Dec 09, 2003 at 03:37:55PM -0500, Aaron M. Ucko wrote: > - how to verify that katie will process uploads as expected (I'd been > running dinstall -n, via dput -D; I suppose it would be possible to > upload separately to the mirror and test there, but that's awkward.) Seems to me that, with proper checks before upload and a properly done upload itself, dinstall -n is superfluous. I can't remember when was the last time I got my stuff rejected by e.g. a competing upload, mistaken number, or anything like that... And even if something does get rejected, you only have to wait around five minutes to find out. -- 2. That which causes joy or happiness.
Re: RFS: phpgroupware
On Tue, Dec 09, 2003 at 09:06:02PM +0100, Thomas Viehmann wrote: > Jamin W. Collins wrote [in a different order]: > > However, I'd prefer to have a "work in progress" blurb in > README.Debian, partially to acknowledge that there are still some > things to be smoothed out. (The reason I believe an update is > appropriate in spite of regarding this as "work in progress" is that > the version fixes many errors (some severe and security) of the > package currently in unstable.) Why not request the removal of the version that is in unstable and put the "work in progress" version into experimental? Then as the kinks are worked out of the packages they could be moved over into unstable. This might mean that a few of the modules don't make it in right away, but would probably make for a smoother transition. > > - The database admin password is stored in debconf. This should not be > > done. Ask for it, use it, and then remove it from the database. > What does this mean for the removal of the database upon purging the > package? > I don't have the impression that people will be very happy with debconf > prompts in the postrm. (Of course, debconf might already have been > removed in the postrm...) > Should I just not drop the database? Dropping user entered data blindly isn't usually a good thing. While a prompt during postrm isn't great, IMHO it's better than storing a DB admin password in debconf. -- Jamin W. Collins Facts do not cease to exist because they are ignored. --Aldous Huxley, "Proper Studies", 1927
零租金香港百货特价拍卖场隆 重 招 商
零 香港百货特价拍卖场 租金隆 重 招 商 主办：致富深港有限公司 开展地点：华能大厦西区6F 为迎接圣诞新年的到来，加速深港两地小商品的流通。为大众节前购物提供一个优惠大平台，致富中国深港有公司特承办该项活动，本次活动荟萃香港最新最全的各类特价商品，会展面积约1800平方米，规模之大，品种之全在深圳沿属首次。余部分铺位，诚邀下列招商范围内中国大陆厂商进驻（港式管理）凡2003－12－18号前入场者，一律零租金。 招商范围：衣、食、住、行 咨询热线：83774985 ，83774986业务专线：13714794035，13714317640 咨询热线：83774985 ，83774986 业务专线：13714794035，13714317640
走！！一起去泡温泉~~
南昆山、龙门温泉活动召集（超级腐败~~~） 【时 间】2003-12-13 07：30― 2003-12-14 18：00 【大致行程】 D1：周六早上7.30在深圳市体育馆集合，前往有广东黄山之称的――南昆山国家森林公园，地处惠州市龙门县，是一个森林覆盖率为96.6%的巨大绿色宝库，有“北回归线上的绿洲”之称。到达南昆山欣赏南昆山奇景―一线天，午餐后游川龙瀑布、石河奇观，之后于观音潭里尝试这里的天然按摩池，享受独特的自然理疗（太FB了~~），更能欣赏独一无二的奇松――蛇松、南昆竹海等~~晚饭后自由活动！ D2：早餐后沿着林阴小径拾级登山，一路山，朦胧远山，入云碧峰，深幽峡谷、苍劲古松，撑天云杉、笔挺修竹，相映成趣。经测试，这里的负氧离子含量极高，空气可以装罐头出售（嘿嘿，够神~~）。这时，你会对“深呼吸”有更好的体会吧？~~~登神鹰石，体验“天人合一”（人在雾中）的感觉吧。。~~午餐后可前往龙门温泉（费用自理），该温泉为目前广东最大的山水园林温泉，有“亚洲第一泉”之称！！ 【费用】 来回车费+住宿+吃饭+森林公园门票+保险费+集体装备=290元 【报名方式】建议直接电话报名： 13809893309QQ12435028 报名格式：真实姓名/身份证号码/联系手机 以报名者先后顺序为主要依据 ！
Re: recovery status update
Josip Rodin <[EMAIL PROTECTED]> writes: > On Tue, Dec 09, 2003 at 03:37:55PM -0500, Aaron M. Ucko wrote: >> - how to verify that katie will process uploads as expected (I'd been >> running dinstall -n, via dput -D; I suppose it would be possible to >> upload separately to the mirror and test there, but that's awkward.) > > Seems to me that, with proper checks before upload and a properly done > upload itself, dinstall -n is superfluous. I can't remember when was the > last time I got my stuff rejected by e.g. a competing upload, mistaken > number, or anything like that... And even if something does get rejected, > you only have to wait around five minutes to find out. Hm, yeah, I must admit that there's much less call for this now that automatic feedback occurs every 15 minutes rather than only once a day. >> I believe http://incoming.debian.org/ is functioning as usual (though >> it's a bit hard to tell shortly after a dinstall run ;-) ). Yep. -- 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.
Assurance measures: ATE (well, ehhrmm)
Hi! The open source development method have a very different approach to tests from the commercial development method: Testing is a largely uncoordinated effort, driven by the individual needs of users. That means that zero to none evidence is gathered on tests actually ran, and no structured approach can be claimed on it. Not if testing would not be made, just the depth and coverage of them cannot be establised. Of course there are examples on the contrary, like some packages which run elaborate tests on 'make test' or www.linuxtestproject.org, but they are still enough only to EAL2, which is close to nothing. My favourite example is happydoc: the author first writes test cases, and the code _after_ that. It might even enough for ATE_DPT.3, which requires tests against the implementation representation (code). ATE_COV.2 Analysis of coverage (EAL3-EAL5) ATE_COV.2.1D The developer shall provide an analysis of the test coverage. (www.linuxtestproject.org) ATE_COV.2.1C The analysis of the test coverage shall demonstrate the correspondence between the tests identified in the test documentation and the TSF as described in the functional specification. (See ADV_FSP to realize that this is the second step to take) ATE_COV.2.2C The analysis of the test coverage shall demonstrate that the correspondence between the TSF as described in the functional specification and the tests identified in the test documentation is complete. (Writing tests is boring, eh?) ATE_DPT.1 Testing: high-level design (EAL3, EAL4) ATE_DPT.1.1D The developer shall provide the analysis of the depth of testing. (the lack of this may be the root cause that SLES got only EAL2) ATE_DPT.1.1C The depth analysis shall demonstrate that the tests identified in the test documentation are sufficient to demonstrate that the TSF operates in accordance with its high-level design. (Writing tests is still boring.) ATE_FUN.1 Functional testing (EAL2-EAL5) ATE_FUN.1.1D The developer shall test the TSF and document the results. (If one is writing tests, it is relatively easy to comment them.) ATE_FUN.1.2D The developer shall provide test documentation. (...and write some pages about their structure.) ATE_FUN.1.1C The test documentation shall consist of test plans, test procedure descriptions, expected test results and actual test results. (The test script with comments, plus an overview doc is the test plan, and the proc. description, the expected test results are some files with the expected output, and actual test results can be gained by running the test suite.) ATE_FUN.1.2C The test plans shall identify the security functions to be tested and describe the goal of the tests to be performed. (Nice objective for the comments of the test scripts.) ATE_FUN.1.3C The test procedure descriptions shall identify the tests to be performed and describe the scenarios for testing each security function. These scenarios shall include any ordering dependencies on the results of other tests. (The code does that, the scenario is "run make;make tests":) ATE_FUN.1.4C The expected test results shall show the anticipated outputs from a successful execution of the tests. (Easy, if we talk about test scripts.) ATE_FUN.1.5C The test results from the developer execution of the tests shall demonstrate that each tested security function behaved as specified. (the diff command helps a lot:) ATE_IND.3 Independent testing - complete (EAL7) ATE_IND.3.1D The developer shall provide the TOE for testing. (apt source) ATE_IND.3.1C The TOE shall be suitable for testing. (seems easy, if the other requirements are fulfilled) ATE_IND.3.2C The developer shall provide an equivalent set of resources to those that were used in the developer's functional testing of the TSF. (an account on the designated devel machine) -- GNU GPL: csak tiszta forrásból
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Tue, Dec 09, 2003 at 01:57:29PM +, Henning Makholm wrote: > Scripsit Andrew Suffield <[EMAIL PROTECTED]> > > On Tue, Dec 09, 2003 at 02:51:53AM +0100, Moritz Moeller-Herrmann wrote: > > > > You do realize that the desktop standard has more features than the debian > > > menu system? Like i18n, icon theming, dynamic construction of a menu > > > hierarchy based on user /Desktop system preferences and so on? > > [...] > > > Because you gain *nothing* > > Are you claiming that everyone who says that .desktop has technical > advantages is a liar? These features actually do not exist in the > desktop format? (It may be so; I have no firsthand information, but it > does sound far out). No. I'm claiming that everyone who says that "only by using .desktop exclusively can we do these things" is a liar. Alternate approaches (that involve significantly less work) have been sketched out several times now. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Tue, Dec 09, 2003 at 09:49:54AM -0600, Billy Biggs wrote: > Andrew Suffield ([EMAIL PROTECTED]): > > > It's "pass a few more text fields through to the menu methods, and use > > them to generate .desktop files" versus "rewrite everything". > > You sure it's "rewrite everything"? A script to parse all .desktop > files in /usr/share/applications and output the same as 'update-menus Straw man, again. The proposal was to rewrite all menu entries as .desktop files - yeah, I'm sure that means rewriting them all. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Assurance measures: AVA (There should be some white hats around also)
Hi! Vulnerability assessment is continously happening. It is a common estimation that the public sees its results with some two months delay in average. Actually the other assurance measures are invented to have as few facts to be found by AVA, as possible. AVA_CCA.1 Covert channel analysis (EAL5) I do not cover this topic here, as one can get even EAL4 without it. Hopefully firewall vendors will realise sooner or later, that their products have no protection without doing their homework in this area. (I count myself as one of them.) AVA_MSU.2 Validation of analysis (EAL4, EAL5) AVA_MSU.2.1D The developer shall provide guidance documentation. (See AGD) AVA_MSU.2.2D The developer shall document an analysis of the guidance documentation. (This is the new one. I doubt that any OSS products have it) AVA_MSU.2.1C The guidance documentation shall identify all possible modes of operation of the TOE (including operation following failure or operational error), their consequences and implications for maintaining secure operation. (An often lacking element of docs.) AVA_MSU.2.2C The guidance documentation shall be complete, clear, consistent and reasonable. (It is everyone's long term goal:) AVA_MSU.2.3C The guidance documentation shall list all assumptions about the intended environment. (As stated in AGD, and shall be found in ST.) AVA_MSU.2.4C The guidance documentation shall list all requirements for external security measures (including external procedural, physical and personnel controls). (This is drawn from the list of objectives against te non-it environment from the ST.) AVA_MSU.2.5C The analysis documentation shall demonstrate that the guidance documentation is complete. (hmm..) AVA_SOF.1 Strength of TOE security function evaluation (EAL2-EAL7) AVA_SOF.1.1D The developer shall perform a strength of TOE security function analysis for each mechanism identified in the ST as having a strength of TOE security function claim. (Fortunately it is a well-researched area. One can find research papers analysing the strength of the cryptographic functions widely used. The minimum pasword complexity/key lengths should only be set according to them, which can be made a requirement against the environment and documented in the guidance.) AVA_SOF.1.1C For each mechanism with a strength of TOE security function claim the strength of TOE security function analysis shall show that it meets or exceeds the minimum strength level defined in the PP/ST. (see above) AVA_SOF.1.2C For each mechanism with a specific strength of TOE security function claim the strength of TOE security function analysis shall show that it meets or exceeds the specific strength of function metric defined in the PP/ST. (See above) AVA_VLA.2 Independent vulnerability analysis (EAL4) AVA_VLA.2.1D The developer shall perform a vulnerability analysis. (We all think about ways to overcome the defence of our program. Let's call it vulnerability analysis:) AVA_VLA.2.2D The developer shall provide vulnerability analysis documentation. (Write down what did you thought about.) AVA_VLA.2.1C The vulnerability analysis documentation shall describe the analysis of the TOE deliverables performed to search for ways in which a user can violate the TSP. The vulnerability analysis documentation shall describe the disposition of identified vulnerabilities. (look ad docs, fix if you find something, and document it.) AVA_VLA.2.2C The vulnerability analysis documentation shall show, for all identified vulnerabilities, that the vulnerability cannot be exploited in the intended environment for the TOE. The vulnerability analysis documentation shall justify that the TOE, with the identified vulnerabilities, is resistant to obvious penetration attacks. (This is the type of security advisory that claims that "our system is not vulnerable", or "our system is not intended for that type of use", but in the docs this time.) This time I list an evaluator action element, as this is the main point: AVA_VLA.2.3E The evaluator shall perform an independent vulnerability analysis. (We have plenty of evaluators, they perform it, but often fail to tell it to others:) Nonetheless there are plenty of position papers telling that a strength of open source is opennes to independent vulnerability analysis. And they are true.) -- GNU GPL: csak tiszta forrásból
Re: Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Andrew Suffield ([EMAIL PROTECTED]): > On Tue, Dec 09, 2003 at 09:49:54AM -0600, Billy Biggs wrote: > > Andrew Suffield ([EMAIL PROTECTED]): > > > > > It's "pass a few more text fields through to the menu methods, and > > > use them to generate .desktop files" versus "rewrite everything". > > > > You sure it's "rewrite everything"? A script to parse all .desktop > > files in /usr/share/applications and output the same as > > 'update-menus > > Straw man, again. The proposal was to rewrite all menu entries as > .desktop files - yeah, I'm sure that means rewriting them all. Agreed on that, but it's not rewriting all of the menu package, which is what I felt your post implied. Rewriting all menu files is fairly trivial and does not have to be done all at once. -Billy
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Scripsit Andrew Suffield <[EMAIL PROTECTED]> > Straw man, again. The proposal was to rewrite all menu entries as > .desktop files - Yes. That is a straw man. -- Henning Makholm"Nej, hvor er vi altså heldige! Længe leve vor Buxgører Sansibar Bastelvel!"
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Scripsit Andrew Suffield <[EMAIL PROTECTED]> > On Tue, Dec 09, 2003 at 01:57:29PM +, Henning Makholm wrote: > > Are you claiming that everyone who says that .desktop has technical > > advantages is a liar? > No. I'm claiming that everyone who says that "only by using .desktop > exclusively can we do these things" is a liar. Then there are no liars on this list. Let's rejoice! -- Henning Makholm "Uh ... a picture of me with my hair pinned up in a towel and standing in front of a grid without a trace of makeup? *Are you out of your rock-happy mind?*"
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Scripsit Bruce Sass <[EMAIL PROTECTED]> > On Tue, 9 Dec 2003, Moritz Moeller-Herrmann wrote: > > In which format shall application packages store > > their menu information. > It doesn't matter, If you don't think the problem being discussed matters, why are you participating in the discussion? > the question should be, "what requires more work: adding features to > the existing menu system, or changing the entire menu system." Is there a difference? The changes being contemplated consist in adding features, and any addition of features constitute a change. > > Users and developers propose following the > > freedesktop standard and using this. > Users and developers are also resisting the proposal. With few or no actual arguments about what would go bad. > > How is this logical? How does the freedesktop standard not "gain" us > > features? > Because nobody but KDE and Gnome use those features and they > already support .desktop files. Yes, but that does not buy KDE and Gnome users anything unless the .desktop files are in the .debs for the applications they use. We're discussions how to allow the .debs to contain them without duplication of information and needless redundancy. > > freedesktop entry features > debian menu file features > True, but everyone except KDE and Gnome will toss out the freedesktop > features. Processing bloated .desktop files just to toss the > results is a waste of resources. The fraction of Debian users who use KDE and Gnome is probably less than 90%, but I don't believe that it is small enough that it makes sense to oppose on principle their getting the information they want. > Nobody benefits from the transition... not even KDE or Gnome, since > they already support the features the freedesktop standard brings to > the table. Having a .desktop infrastructure is worth nothing if you dont have the data it works with. KDE and Gnome users would certainly benefit from having .desktop files in the .debs of the packages they use. > I regularily use KDE, UWM, pdmenu, and Fluxbox, I also have twm, xfce > and mwm installed... processing the menues takes too much time and > resources as it is, and you want to use up more, for what gain? Just how much more time and resources would it take to convert .desktop files to Debian menu definitions? How often does it have to be done? -- Henning Makholm"I have seen men with a *fraction* of your trauma pray to their deity for death's release. And when death doesn't arrive immediately, they reject their deity and begin to beg to another."
Re: recovery status update
> - how to run the DELAYED queue (to give the possibility of deleting > things from it or to see what's in it) > > - how to give developers the possibility of seeing what's in the queue > (daily rsyncs are not good enough for this; I've frequently pulled > packages from the accepted queue to check that bug fixes have been > correctly applied) - how to run madison and wanna-build
Re: Initrd rocks! (was Re: Backporting 2.4.23 kernel packages)
On Tue, Dec 09, 2003 at 06:31:19PM +0100, Goswin von Brederlow wrote: > > This is distinct from the autodetection in the kernel that is capable of > > automatically scanning all harddisks on all busses to find RAID devices. > > Why can't you use the kernel autoconfig or does that only work with > build-in drivers? I believe the kernel raid1 autodetection only works if raid1 is compiled into the kernel. In anycase, initrd images generated from mkinitrd in Debian do not autodetect. IIRC, There is a parameter to mdadm (--scan?) that could be used for this, but when I asked the initrd maintainer I was given a good reason why it was not used (sorry; I can't remember what this was now; it might simply be that the mdadm code is unreliable, inefficient, or buggy). -- Brian May <[EMAIL PROTECTED]>
Re: Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Tue, Dec 09, 2003 at 05:18:21PM -0600, Billy Biggs wrote: | Agreed on that, but it's not rewriting all of the menu package, which | is what I felt your post implied. Rewriting all menu files is fairly | trivial and does not have to be done all at once. It should also be fairly easy to get it mostly, if not entirely, automated. q.v. what KDE and Gnome already do in their menu methods. Cameron.
Re: recovery status update
Clint Adams <[EMAIL PROTECTED]> writes: > - how to run madison and wanna-build I thought the idea was for the unrestricted mirror to include a read-only copy of the database madison consults. wanna-build presumably needs more real-time access, though. -- 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: APT-Fu 0.2.3 (was: Re: Building Debian Completely From Source)
George Danchev <[EMAIL PROTECTED]> writes: > p.s. why Apt-Fu ? Is that 'APT Kung-Fu' or what ? Hmm, after apt-src, > apt-build, and similar 'build that debian source package' tools, I've been > expecting for 'apt-too' ;-) FWIW, the `fu' in kung-fu means something like style or technique, so apt-fu sort of makes sense if you think of as a tool for doing cool things using the power of apt... :-) -Miles -- "I distrust a research person who is always obviously busy on a task." --Robert Frosch, VP, GM Research
[no subject]
debian-devel，您好！ 致 礼！ 佳能影音器材有限公司 [EMAIL PROTECTED] 2003-12-10
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Tue, Dec 09, 2003 at 09:49:25PM +, Andrew Suffield wrote: | Alternate approaches (that involve significantly less work) That's the bit that I (and presumably others) am not convinced about. You keep making this assertion, but with little to back it up. Have you, e.g., looked at the Categories definitions for .desktop files? I don't believe that mapping them onto the section field of our menu system (and vice versa) without losing any information would be trivial. Cameron.
