Re: PostgreSQL admin tools (Was: Upcoming removal of orphaned packages)
On Tue, 15 Apr 2003, Carl B. Constantine wrote: http://pgadmin.postgresql.org/pgadmin2.php?ContentID=1 which only runs under non-free operating system. The closest I've found for *nix is pgaccess http://www.pgacess.org/ which is a tcl/tk app and works quite well. I use it at work on my solaris system. Please check the whole functionality of pgaccess before you call it close to PgAdmin. I think everybody who knows PostgreSQL knows pgaccess - as well as its constraints and drawbacks. Kind regards Andreas. -- Mankind must put an end to war before war puts an end to mankind. John F. Kennedy
Re: ITP: build-common -- common build system for Debian packages
Colin Walters [EMAIL PROTECTED] writes: So, CBS was an experiment, and I learned a lot from it. build-common is a lot better. It even uses itself to build itself :) Once it's in the archive I'll write up something about it here. Cool. I switched most of my packages to CBS, so I wonder how much work it would/will be to switch to build-common? Regards, Andy -- Andreas Rottmann | [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62 Packages should build-depend on what they should build-depend.
Bug#189249: ITP: ddrescue -- Like dd, dd_rescue does copy data from one file or block device to another
Package: wnpp Version: unavailable; reported 2003-04-16 Severity: wishlist * Package name: dd_rescue Version : 1.0.2 Upstream Author : Kurt Garloff [EMAIL PROTECTED] * URL : http://www.garloff.de/kurt/linux/ddrescue/ * License : GPL Description : dd_rescue does copy data from one file or block device to another From homepage: The latter three features make it suitable for rescuing data from a medium with errors, i.e. a hard disk with some bad sectors. Why? * Imagine, one of your partitions is crashed, and as there are some hard errors, you don't want to write to this hard disk any more. Just getting all the data off it and retiring it seems to be suitable. However, you can't access the files, as the file system is damaged. * Now, you want to copy the whole partition into a file. You burn it on CD-Rom, just to never loose it again. You can setup a loop device, and repair (fsck) it and hopefully are able to mount it. * Copying this partition with normal Un*x tools like cat or dd will fail, as those tools abort on error. dd_rescue instead will try to read and if it fails, it will go on with the next sectors. The output file naturally will have holes in it, of course. You can write a log file, to see, where all these errors are located. * The data rate drops very low, when errors are encountered. If you interrupt the process of copying, you don't loose anything. You can just continue at any position later. The output file will just be filled in further and not truncated as with other Un*x tools. * If you have one spot of bad sectors within the partition, it might be a good idea, to approach this spot from both sides. Reverse direction copy is your friend. * The two block sizes are a performance optimization. Large block sizes result in superior performance, but in case of errors, you want to try to salvage every single sector. So hardbs is best be set to the hardware sector size (most often 512 bytes) and softbs to a large value, such as the default 16k. It will be uploaded soon by my sponsor Gerfried Fuchsalfie!debian.org. Regards Ayman -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux matrix 2.4.18-bf2.4 #1 Son Apr 14 09:53:28 CEST 2002 i686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] -- +-+ .~. .~. / O \ / ^ \ (| |) /| |\ '\ /` `\ /` ^`^ ^`^ Ayman Negm gpg-Key: 0x63E8BE82 +-+
Re: curl, testing and gcc-3.2 (?) (was Re: Debian curl package depends on gcc-3.2?)
Colin Watson wrote: forcing other packages to always depend on the latest version of them No, that's not what shlibdeps do. Right, it does not force the latest, only the version that is installed on the machine it runs on. But isn't the effect essentially the same, since most people/robots that build for unstable will likely have farily recent library versions? If whatever library versions are present at the time of building are defined as the minimum requirements, doesn't that mean that packages which are in stable today would not even be accepted into testing if they were rebuilt? -- Björn
Re: Bug#189249: ITP: ddrescue -- Like dd, dd_rescue does copy data from one file or block device to another
On Wednesday 16 April 2003 11:11, Ayman Negm wrote: Description : dd_rescue does copy data from one file or block device to another I guess a better Description: would be 'dd clone which ignores read errors'. But I see in the dd man page: conv=KEYWORDS convert the file as per the comma separated keyword list [...] Each KEYWORD may be: [...] noerror continue after read errors [...] So perhaps an explanation what dd_rescue does differently should be in the (long) description. cheers -- vbi -- To spot the expert, pick the one who predicts the job will take the longest and cost the most. pgpVXQmkY65Z2.pgp Description: signature
Re: Bug#189249: ITP: ddrescue -- Like dd, dd_rescue does copy data from one file or block device to another
On Wed, Apr 16, 2003 at 11:11:17AM +0200, Ayman Negm wrote: * Package name: dd_rescue Version : 1.0.2 Upstream Author : Kurt Garloff [EMAIL PROTECTED] * URL : http://www.garloff.de/kurt/linux/ddrescue/ * License : GPL Description : dd_rescue does copy data from one file or block device to another Please don't repeat the package name in the description. Instead: Description : copy data from one file or block device to another Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: curl, testing and gcc-3.2 (?) (was Re: Debian curl package depends on gcc-3.2?)
On Wed, Apr 16, 2003 at 12:46:07PM +0200, Bj?rn Stenberg wrote: Colin Watson wrote: forcing other packages to always depend on the latest version of them No, that's not what shlibdeps do. Right, it does not force the latest, only the version that is installed on the machine it runs on. No, that's not what shlibdeps do either. See: http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-shlibdeps -- Colin Watson [EMAIL PROTECTED]
Bug#189271: ITP: fcitx -- Free Chinese Input Toy for X
Package: wnpp Version: unavailable; reported 2003-04-16 Severity: wishlist * Package name: fcitx Version : 1.8.3 Upstream Author : YuKing [EMAIL PROTECTED] * URL : http://www.fcitx.org/ * License : GPL Description : Free Chinese Input Toy for X fcitx is a X Input Server based on XIM, including WuBi, PinYin, and QuWei input method for Simplified Chinese. It is many persons' favorite input program in China. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux winter 2.4.20-686 #1 Mon Jan 13 22:22:30 EST 2003 i686 Locale: LANG=zh_CN, LC_CTYPE=zh_CN (ignored: LC_ALL set)
Re: Debian Developer LDAP
* Oohara Yuuma [EMAIL PROTECTED] [2003-04-15 07:50]: On Mon, 14 Apr 2003 10:24:44 -0400, Mark Bucciarelli [EMAIL PROTECTED] wrote: (3) is the email gateway used? I tried but failed to change my latitude/longitude data. None of the following worked. RTFM instructions welcome. RTFM http://db.debian.org/doc-mail.html. From db.debian.org frontpage - Documentation - Mail gateway Lat: +0334500., Long: +1303000. The , must have been the problem. Lat: 33:45:00.000 N Long: 130:30:00.000 E --- Lat: 33n45. Long: 130e30. --- Lat: +0334500 Long: +1303000 Those are simply in wrong format. The error message was: == Message Error: Positions were found, but they are not correctly formed Command is not understood. Halted The mail gateway should include the above URL to the documentation to avoid such questions in the future. Who can add it, please? So long! Alfie -- Nachdem es SuSE nun endlich geschafft hat, Linux so sehr zu verunstalten, daß es schlechter als Windows ist, bootet es nun also sogar schon auf der Hardware von Microsoft. -- realborg zu http://futurezone.orf.at/futurezone.orf?read=detailid=129360 pgpDnpiXbSF5X.pgp Description: PGP signature
Re: curl, testing and gcc-3.2 (?) (was Re: Debian curl package depends on gcc-3.2?)
Colin Watson wrote: No, that's not what shlibdeps do either. See: http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-shlibdeps Lovely, so it's simply the other way around (as Adam Conrad said already). Thanks. However, it still means packages get bogus dependencies that keep them out of testing. Even if the package in question was already accepted in stable. Let me be blunt and ask: Is this a we don't care, go away issue or why is this so difficult to discuss? If it was a frequently asked (and answered) question, I would expect a ton of list archive links to have been dumped on me by now. I have no qualms about squeezing blood from stone, but it doesn't exactly speed the discussion nor minimize my annoying questions. -- Björn
Re: [desktop] Draft proposal for a new debian menu system
On Thu, Apr 10, 2003 at 08:21:03PM +0200, Bernhard R. Link wrote: With all the new anvances in Linux Desktop tecnologies, it seems like the current menu system needs some redesign to keep up and integrate with the other existing systems. Please explain this phrase. Ecspecially the other existing systems. Debian menu-system has many disadvantages, though I've not heared of any other system at all. We have at least three parallel menu systems around: the Debian Menu, the Gnome Foot Menu and the KDE menu. open Desktop Menu Specification found here: http://www.freedesktop.org/standards/menu/draft/menu-spec/menu-spec.html Seems to be both for the desktop and the menus. I do not see what they have in common. Menus are things that are also used in the desktop. Or didn't I understand your question? It seems to miss some things, most important in my eyes a possibility to switch window managers. (I doubt it is usable for anything than KDE or Gnome) We now acheive the possibility to switch window managers by generating, from a single metadata source, the menu data for the various window managers or menu-using applications we package. We could keep doing the same, but using the freedesktop format for our metadata source instead of the one we're using now. Bye, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini [EMAIL PROTECTED]
Re: [desktop] Draft proposal for a new debian menu system
On Thu, Apr 10, 2003 at 10:38:57PM +0200, Michael Banck wrote: I would like to propose that we switch to the freedesktop.org .menu format for desktop entries, and we keep providing menu informations for applications that do not provide one on their own. Wasn't Chris Lawrence working on this? Or maybe he was working on the older menu format. Hopefully he can elaborate. Unfortunately, he seems to be MIA WRT Debian. I tried to dig up his menu code somewhere on the web, but to no avail. After posting the message, I realized there was a cvs repository mentioned in the debian-desktop pages, with an ongoing menu rewrite. It didn't seem active, though: last commit appeared to be5 months ago. There's also a policy proposal in there that looks very similar to the one I made here, and we could merge them. I've just written to Chris asking for his current situation wrt the menu system. If he's still in, I hope he joins the discussion. If he can't work on it anymore, I'd suggest we take on from where he left. In both cases, shall we assemble a working team? Is there someone interested in joining Chris(maybe) and me? Bye, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini [EMAIL PROTECTED] pgpcuLUSiduD0.pgp Description: PGP signature
Re: W3C recommendations
On Mon, Apr 14, 2003 at 07:38:00AM +0200, J.H.M. Dassen (Ray) wrote: (Personally, I'd vote against a proposal to make it mandatory. We have more than enough release-critical issues at the moment - cleaning up documentation to conform completely to W3C standards and recommendations is probably one of those 80/20 things, taking a lot of development effort for little user-visible gain) It depends on what kind of users you use to measure user-visibility, since W3C recommendations also have something to do with accessibility. Bye, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini [EMAIL PROTECTED]
SASL2 negotation failes with DIGEST-MD5 mech, but succeeds with CRAM-MD5
Hi all, I have some difficulties with SASL2 and the use of the DIGEST-MD5 mechanism. To test the SASL2 behaviour I've downloaded the cyrus-sasl-2.1.13 distribution and compiled the sample-server and sample-client. I'm running a Debian sarge (testing) system with the following SASL packages installed: libsasl2 2.1.2-2 libsasl2-digestmd5-plain 2.1.2-2 libsasl2-modules-plain 2.1.2-2 libsasl7 1.5.27-3.3 sasl2-bin 2.1.2-2 With the sample server and sample client I can test if the SASL negotiation can be successful completed. I've set up a sasldb2 with one user called durk. defaultsarge:~/cyrus-sasl-2.1.13/sample# sasldblistusers2 [EMAIL PROTECTED]: userPassword I've created a file called /usr/lib/sasl2/sample.conf: defaultsarge:~/cyrus-sasl-2.1.13/sample# cat /usr/lib/sasl2/sample.conf pwcheck_method: auxprop Now if I try to make a SASL negotiation using the CRAM-MD5 mechanism the negotiation completes successful, but if I try DIGEST-MD5, the negotiation fails. Here are the details of the testing: Command used to start the sample server: ./sample-server Command used to start the sample client with CRAM-MD5: ./sample-client -a durk -m CRAM-MD5 Command used to start the sample client with DIGEST-MD5: ./sample-client -a durk -m DIGEST-MD5 The errornous output of the DIGEST-MD5 test is as follows: defaultsarge:~/cyrus-sasl-2.1.13/sample# ./sample-client -a durk -m DIGEST-MD5Waiting for mechanism list from server... S: TE9HSU4gQU5PTllNT1VTIFBMQUlOIENSQU0tTUQ1IERJR0VTVC1NRDU= recieved 41 byte message Forcing use of mechanism DIGEST-MD5 Choosing best mechanism from: DIGEST-MD5 Using mechanism DIGEST-MD5 Sending initial response... C: RElHRVNULU1ENQ== Waiting for server reply... S: bm9uY2U9IlVVRVJURU9PSjdXSmhBYjRWdGYycGRZVjhEaE1oOFpVKzBGWVJqTW9Sem89IixyZWFsbT0iZGVmYXVsdHNhcmdlIixxb3A9ImF1dGgsYXV0aC1pbnQiLGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNzrecieved126 byte message returning OK: durk Password: Sending response... C: dXNlcm5hbWU9ImR1cmsiLHJlYWxtPSJkZWZhdWx0c2FyZ2UiLG5vbmNlPSJVVUVSVEVPT0o3V0poQWI0VnRmMnBkWVY4RGhNaDhaVSswRllSak1vUnpvPSIsY25vbmNlPSJPRkExbCt5YmlFR2I4OEt0UCsrOG9CKzVRMENBZ3M3VU5sNHQwVzhmU3U4PSIsbmM9MDAwMDAwMDEscW9wPWF1dGgtaW50LGNoYXJzZXQ9dXRmLTgsZGlnZXN0LXVyaT0icmNtZC8iLHJlc3BvbnNlPTUyYjVmYjkxYjM5NTVhOGY2M2MzOWVlYjY3ZDc2MTFkWaitingfor server reply... S: cnNwYXV0aD0xYTk0ZTc3ZjlmNjNlNTRmMzQyMmY4YzJlZDc2YzhmZA== recieved 40 byte message lt-sample-client: SASL Error: attempting client step after doneflag lt-sample-client: Performing SASL negotiation: generic failure defaultsarge:~/cyrus-sasl-2.1.13/sample# Well as you see a generic failure, I have no clue how to fix this... Anyone idea's? Thanks in advance, Durk (this is posted on [EMAIL PROTECTED] and debian-devel@lists.debian.org)
Re: curl, testing and gcc-3.2 (?) (was Re: Debian curl package depends on gcc-3.2?)
On Wed, 16 Apr 2003, Björn Stenberg wrote: However, it still means packages get bogus dependencies that keep them out of testing. Even if the package in question was already accepted in stable. The issue is: Define BOGUS. Most of the time, the maintainers of the -dev packages know very well why they have changed the versioned dependencies. It is also a no-granularity solution, for which the only alternative is full-blown symbol versioning as done by glibc (i.e. you keep old ABIs around, even!). Let me be blunt and ask: Is this a we don't care, go away issue or why is this so difficult to discuss? If it was a frequently asked (and answered) The shlib dep system is well explained in the developer documentation, and it is almost never a matter of curiosity of non-developers... it is also the best that can be done AFAIK. Only people building packages need to direct interact with it, and only if they are responsible for a library package, even... otherwise it is all automatic. As for shlib information keeping stuff out of testing, that's the wrong POV. THAT *is* the entire charter of testing: if we don't know it will work, don't let it in. The system is working as designed. If you want the packages to flow in testing, you need to make sure their dependencies do. I pay little attention to testing, so I don't know exactly what is freezing it right now, but the truth is: people who care about testing are encouraged to clean up the bugs *in unstable* that are holding things from testing, or to go away (fixing the bugs are the ONLY desired way to get things into testing). Sometimes the bugs are not in packages, but in infrastructure or something else... but that's rare. There isn't much else we can do, really. We have to keep the distribution in testing and stable coherent, so that means fix stuff in unstable, and only let it get to testing when dependencies are satisfied (and new bugs not added, subject to some manual control by aj). If you need to live in the bleeding edge (I do), then use unstable and take the proper precautions to not get caught in major breakages just when you needed your system working the most... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh pgpmDdFc1myA5.pgp Description: PGP signature
Re: curl, testing and gcc-3.2 (?) (was Re: Debian curl package depends on gcc-3.2?)
On Wed, Apr 16, 2003 at 02:56:21PM +0200, Bj?rn Stenberg wrote: Colin Watson wrote: No, that's not what shlibdeps do either. See: http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-shlibdeps Lovely, so it's simply the other way around (as Adam Conrad said already). Thanks. However, it still means packages get bogus dependencies that keep them out of testing. Even if the package in question was already accepted in stable. The dependencies aren't bogus (apart from the occasional mistake in a library's shlibs files). The reason why a library's shlibs get changed is that binaries built against one version of the library can't be guaranteed to run correctly against older versions. Stable is irrelevant here, because the package built for stable was built against an older version of the library. Binary dependencies are not the same as source dependencies. Let me be blunt and ask: Is this a we don't care, go away issue or why is this so difficult to discuss? The only practical and correct way that I know of to improve the situation would be to figure out some way to calculate package dependencies from symbol versions in certain libraries. That's very difficult and would probably involve a lot more work on the part of the maintainers of those libraries even if it could be implemented, though. I think it is much more productive to try to get infrastructure packages into a good enough state that major upgrades can move into testing more quickly: that is, fix real bugs! Mailing package maintainers asking them to loosen their shared library dependencies is not useful and is sometimes actively counterproductive (I've seen maintainers messing around trying to upload packages built against testing, not realizing that the autobuilders all build against unstable so this won't do any good anyway, which increases the time their package has to wait over what would have happened if they'd just left well alone). Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: [desktop] Draft proposal for a new debian menu system
* Enrico Zini [EMAIL PROTECTED] [030416 15:38]: With all the new anvances in Linux Desktop tecnologies, it seems like the current menu system needs some redesign to keep up and integrate with the other existing systems. Please explain this phrase. Ecspecially the other existing systems. Debian menu-system has many disadvantages, though I've not heared of any other system at all. We have at least three parallel menu systems around: the Debian Menu, the Gnome Foot Menu and the KDE menu. We have one menu system: the Debian menu. And we have several programs with menus, like Gnome, KDE, fvwm, icewm, wmaker, What makes KDE different from fvwm in that regard. (Other that they did not implement a working debian-menu-imput for KDE, so that I had only the possibilities to removing KDE, disabling menus in it at all, or keep my users beeing confused. open Desktop Menu Specification found here: http://www.freedesktop.org/standards/menu/draft/menu-spec/menu-spec.html Seems to be both for the desktop and the menus. I do not see what they have in common. Menus are things that are also used in the desktop. Or didn't I understand your question? The desktop also uses a dynamic linker to work. Linkers are also somewhat compliated over architectures. Shouldn't there be a good specification for usage of linkers placed in there, too. (And in a way, too, that one can not seperate them easily from the rest?) It seems to miss some things, most important in my eyes a possibility to switch window managers. (I doubt it is usable for anything than KDE or Gnome) We now acheive the possibility to switch window managers by generating, from a single metadata source, the menu data for the various window managers or menu-using applications we package. I do not meant switch in the sense of making them more similar. I meant in the meaning of making another run where one in running quite now. We could keep doing the same, but using the freedesktop format for our metadata source instead of the one we're using now. So instead of using a system that works and can do what we need (with the exception of generating KDE-menus, though I do not see the fault in our system here), we should adopt another metadata not even able to describe the things we already have and are used? Hochachtungsvoll, Bernhard R. Link -- Sendmail is like emacs: A nice operating system, but missing an editor and a MTA.
Bug#189299: ITP: libgringotts -- encapsulate data in an encrypted and compressed file
Package: wnpp Version: unavailable; reported 2003-04-16 Severity: wishlist * Package name: libgringotts Version : 1.2.0 Upstream Author : Germano Rizzo [EMAIL PROTECTED] * URL : http://devel.pluto.linux.it/projects/libGringotts/index.php * License : GPL Description : encapsulate data in an encrypted and compressed file This is a subsequent ITP for gringotts, which needs libgringotts. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=170431 for the gringotts ITP. libGringotts is a small, easy-to-use, thread-safe C library originally developed for Gringotts; its purpose is to encapsulate data (generic: ASCII, but also binary data) in an encrypted and compressed file. It uses strong encryption algorythms, to ensure the data are as safe as possible, and allow the user to have the complete control over all the algorithms used in the process. . For encryptions, libGringotts makes use of the MCrypt and MHash libs by Nikos Mavroyanopoulos, two really powerful and easy to use C libraries. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux treasure 2.4.20-treasure2 #1 Thu Mar 27 01:05:22 CET 2003 i686 Locale: LANG=C, [EMAIL PROTECTED]
Re: curl, testing and gcc-3.2 (?) (was Re: Debian curl package depends on gcc-3.2?)
On Wed, Apr 16, 2003 at 12:46:07PM +0200, Björn Stenberg wrote: Right, it does not force the latest, only the version that is installed on the machine it runs on. Not quite. The shlibs file just declares that a package which includes a program linking against, say, libfoo.so.0 should depend on a package called, say, libfoo0. The possibility to version that dependency exists and is actively used. A common example is when a library fixes a bug affecting its clients. A versioned dependency is added to make sure that the newly compiled packages can't be installed with the buggy versions of the library. That's just one example. There are only a few pathological cases where the shlibs file forces newly compiled packags to use the lastest release of the library package. If whatever library versions are present at the time of building are defined as the minimum requirements, doesn't that mean that packages which are in stable today would not even be accepted into testing if they were rebuilt? That could happen, yes. Some hours ago I uploaded a package which is for all _practical_ purposes an identical copy of the package in stable. It will probably remain stuck in unstable for a long while. Marcelo
Bug#189313: general: tcsh displays erroneous limit data
Package: general Version: 20030416 Severity: normal I have tcsh version 6.11.00-2.2 installed and after running unlimit, the shell reports back: mkd /tmp 0 - limit cputime 0:0-1 filesize4194303 kbytes datasize4194303 kbytes stacksize 4194303 kbytes coredumpsize4194303 kbytes memoryuse 4194303 kbytes vmemoryuse 4194303 kbytes descriptors 1024 memorylocked4194303 kbytes maxproc 4095 openfiles 1024 mkd /tmp 0 - However, I can write files over 4G on the machine, so I'm suspicious this is just a display problem. I have not tested the rest of the shell limits. Let me know if you have any further questions. -- System Information Debian Release: testing/unstable Kernel Version: Linux radio 2.4.18mkd.ax25.1 #1 Sun Oct 6 21:17:43 EDT 2002 i686 unknown unknown GNU/Linux
Bug#189313: general: tcsh displays erroneous limit data
On Wed, Apr 16, 2003 at 01:21:47PM -0400, [EMAIL PROTECTED] wrote: filesize4194303 kbytes on bash umlimit -f is in blocks, perhaps thats the problem?
Processed: Re: Bug#189313: general: tcsh displays erroneous limit data
Processing commands for [EMAIL PROTECTED]: reassign 189313 tcsh Bug#189313: general: tcsh displays erroneous limit data Bug reassigned from package `general' to `tcsh'. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Re: [desktop] Draft proposal for a new debian menu system
On Wed, 2003-04-16 at 11:10, Bernhard R. Link wrote: So instead of using a system that works and can do what we need (with the exception of generating KDE-menus, though I do not see the fault in our system here), The current menu system doesn't support i18n for one thing. Anyways, there was a dicussion of the current menu system versus the freedesktop.org one a while back, and the general consensus was definitely to go with the freedesktop.org one. Unless you have a new compelling reason not to switch, I think that's the plan.
New packages taking over config files from old packages, depends, order
I have split up sysvinit into three packages: - sysvinit - initscripts - sysv-rc This is so that BSD and the Hurd can easier replace just the parts they need, probably just initscripts and sysv-rc, and so that alternative systems like file-rc can be dropped in easier. Initscripts now contains the files in /etc/init.d/* that used to be in sysvinit. They are conffiles. However if you then install the new packages, and you install the new sysvinit first, sysvinit will 'orphan' the former conffiles in /etc/init.d (fortunately they are not deleted) and when you then install initscripts, it will start complaining about 'file already exists created by you or a script' which is not what the user would expect. If initscripts is installed first, all is well since it Replaces: sysvinit so it takes over the /etc/init.d/* files from sysvinit, and there are no problems. So I made sysvinit Pre-Depend on initscripts. But that results in the following installation problem: # dpkg -i *.deb Unpacking initscripts (from initscripts_2.85-1_i386.deb) ... Replacing files in old package sysvinit ... Selecting previously deselected package sysv-rc. Unpacking sysv-rc (from sysv-rc_2.85-1_i386.deb) ... Replacing files in old package sysvinit ... dpkg: regarding sysvinit_2.85-1_i386.deb containing sysvinit, pre-dependency problem: sysvinit pre-depends on initscripts initscripts is unpacked, but has never been configured. dpkg: error processing sysvinit_2.85-1_i386.deb (--install): pre-dependency problem - not installing sysvinit How should I solve this .. will apt get this right, and am I just seeing this error because dpkg by itself is not smart enough ? Or is there something I'm missing ? Mike.
stop the manage with debconf madness
Package: laptop-net Severity: serious I just installed laptop-net, becuase it looked similar to something I'd like to work on. The first thing it asked me was whether I wanted to manage its configuration file with Debconf, and it defaulted to yes! This behavior needs to stop, now. It is a violation of Policy, section 11.7.3, which states that local changes must be preserved during a package upgrade. Debconf is NOT a license to overwrite user's configurations! Yes, I am quite aware that XFree86 does this. We as a project have accepted that XFree86 does it because parsing XF86Config perfectly and preserving changes is very difficult. But that doesn't mean that every package can do it. And hopefully the X maintainer is working on a solution for XFree86. First of all, these questions CANNOT default to yes. If my debconf priority is higher than the question, then I won't even see it, and I won't know that I've just given the package a license to destroy my local changes. I propose a different solution to this problem, which conforms much more with policy, while still allowing debconf to be used as much as possible. In my fontconfig packages, /etc/fonts/local.conf is a configuration file (not a conffile). When the in fontconfig.config, I check to see whether that file exists. If it does, then I don't ask any questions at all. That way we never overwrite their config file. Now, I also have special support for dpkg-reconfigure. Inside fontconfig.conf, I check to see if $1 is reconfigure. If it is, and /etc/fonts/local.conf exists, then I warn the user that continuing will overwrite all their changes. The default is no. Now, it might be nice to have generic support in debconf for handling configuration file overwriting. So I could say like: db_overwrite_warning /etc/fonts/local.conf And debconf would handle the prompt, so we wouldn't have to have to handle it individually in each package. Or maybe we could have a separate file like debian/fontconfig.debconf_config_files. But that's just making things a bit nicer. In the meantime, I will be filing serious bugs against packages which have manage with debconf prompts (except XFree86), ESPECIALLY the ones which default to yes. signature.asc Description: This is a digitally signed message part
alioth.debian.org - http connection refused
I can't connect to alioth.debian.org via http. Anyone know what's up? Peter
Re: PostgreSQL admin tools (Was: Upcoming removal of orphaned packages)
On Tue, Apr 15, 2003 at 07:51:59PM -0300, Andre Luis Lopes wrote: [EMAIL PROTECTED]:~$ apt-cache show rhdb-admin Package: rhdb-admin What is wrong here? rhdb-admin echo $? 1 I assume it is meant to do more then just emulate the false command? ;-) -- Brian May [EMAIL PROTECTED]
Bug#189347: stop the manage with debconf madness
Date: 16 Apr 2003 19:08:17 -0400 From: Colin Walters [EMAIL PROTECTED] Package: laptop-net Severity: serious I just installed laptop-net, becuase it looked similar to something I'd like to work on. The first thing it asked me was whether I wanted to manage its configuration file with Debconf, and it defaulted to yes! This behavior needs to stop, now. It is a violation of Policy, section 11.7.3, which states that local changes must be preserved during a package upgrade. Debconf is NOT a license to overwrite user's configurations! I agree. A simple look at the list of bugs for laptop-net should make it clear that the configuration management has some real problems. The root of the problem is that the config files are badly designed -- or rather, not designed at all. This is just programming by example gone bad. I have planned to fix this for some time, but it needs a few days of concentrated effort, and until recently that wasn't possible. First of all, these questions CANNOT default to yes. Agreed. I propose a different solution to this problem, which conforms much more with policy, while still allowing debconf to be used as much as possible. [...] I'd rather fix this properly; what you suggest is a workaround. What I consider a proper fix is to redefine the configuration files so that they can be parsed. I have learned, the hard way, that using shell scripts for configuration files is a bad idea. Now, all I need is enough time... Chris
Re: alioth.debian.org - http connection refused
On Wed, Apr 16, 2003 at 07:55:01PM -0400, Peter S Galbraith wrote: I can't connect to alioth.debian.org via http. Anyone know what's up? Read Wiggy's mail on d-d-a and use https. -- Christian Surchi, [EMAIL PROTECTED], [EMAIL PROTECTED] | ICQ www.debian.org - www.softwarelibero.it - www.firenze.linux.it| 38374818 Who needs friends when you can sit alone in your room and drink?
Re: Bug#189347: stop the manage with debconf madness
On Wed, 2003-04-16 at 20:21, Chris Hanson wrote: I'd rather fix this properly; what you suggest is a workaround. What I consider a proper fix is to redefine the configuration files so that they can be parsed. I have learned, the hard way, that using shell scripts for configuration files is a bad idea. That's true, it's definitely a workaround. The way I did it in fontconfig is the way I think it should be done in packages which can't (or can't easily) losslessly parse their configuration files.
Re: [desktop] Draft proposal for a new debian menu system
On Wed, Apr 16, 2003 at 05:10:58PM +0200, Bernhard R. Link wrote: We have at least three parallel menu systems around: the Debian Menu, the Gnome Foot Menu and the KDE menu. We have one menu system: the Debian menu. And we have several programs with menus, like Gnome, KDE, fvwm, icewm, wmaker, I'm sorry: sid is currently shipping at least three parallel menu hierarchies: the Debian one, the Gnome one and the KDE one. If you open your Gnome foot menu, you can see all three, and you don't know which one to use to look for the application you want to launch. The desktop also uses a dynamic linker to work. Linkers are also somewhat compliated over architectures. Shouldn't there be a good specification for usage of linkers placed in there, too. (And in a way, too, that one can not seperate them easily from the rest?) I'm sorry, I still do not get your point: what do linker have to do with launcher menus? We now acheive the possibility to switch window managers by generating, from a single metadata source, the menu data for the various window managers or menu-using applications we package. I do not meant switch in the sense of making them more similar. I meant in the meaning of making another run where one in running quite now. Yes, the other menus do not have a facility for changing the window manager on the fly. It could be argued that this is a task that do not necessarily belong to the menu system. In fact, switching WM is different than launching an application, both in terms of operations you need to do and in terms of user perception and user goals. Maybe a separate tool can be developed for WM switching (and possibly also to set the default WM for the Debian X session). Gnome does it through its preferences window, and I think that it's a good idea. We could ship a generic preferences window to customize the Debian session when running without Gnome or KDE. So instead of using a system that works and can do what we need (with the exception of generating KDE-menus, though I do not see the fault in our system here), we should adopt another metadata not even able to describe the things we already have and are used? This is interesting: could you please make some example of metadata information that can be represented with the current format and cannot be represented by the Desktop Menu Specification found at freedesktop.org? Yours truly, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini [EMAIL PROTECTED] pgpdhZqYi8VvB.pgp Description: PGP signature
Bug#189362: ITP: mozilla-mozgest -- Mouse gesture support for the mozilla webbrowser
Package: wnpp Version: unavailable; reported 2003-04-17 Severity: wishlist * Package name: mozilla-mozgest Version : 0.3.5.1 Upstream Author : David Illsley [EMAIL PROTECTED] * URL : http://optimoz.mozdev.org/ * License : (MPL, GPL) Description : Mouse gesture support for the mozilla webbrowser Mouse gestures are mouse movements in combination with a click-hold and optionally a modifier that execute some browser functions. You press mouse button, draw a gesture, and release mouse button (you can choose which button to use in advanced preferences). This gesture is recognized and appropriate action is triggered. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux einstien 2.4.20 #1 Fri Feb 21 16:25:56 GMT 2003 i686 Locale: LANG=C, LC_CTYPE=C
