Re: Bug#509685: ITP: hardlink -- Hardlink multiple copies of the same file
On Fri, 26 Dec 2008, John Goerzen wrote: Julian Andres Klode wrote: Hardlink is a tool which detects multiple copies of the same file and replaces them with hardlinks. . The idea has been taken from http://code.google.com/p/hardlinkpy/, but the code has been written from scratch and licensed under the MIT license. Do we really need another tool like this? We already have these packages: fdupes perforate Hi John I think that's a little harsh. There are lots of apps in Debian that provide similar functionality to other apps in Debian. I do agree that iff hardlink is only duplicating functionality available in finddup, then there is no point in maintaining both. I wasn't aware of finddup before this thread. Since faster-dupemerge [0] breaks with the upgrade to lenny I thought I'd give finddup a try. However finddup is too limited for my use case. My home server stores dirvish (think rsync --link-dest) backups for 2 other machines that dual boot windows and linux. Each partition is backed up separately, with the windows partitions having separate backups from both windows and linux. In addition the linux partitions sometimes contain chroots , and the Windows partitions have games installed, then copied to a different dir and modded. That means there is a lot of duplicate files that rsync --link-dest doesn't hardlink. Hardlinking files afterwards enables me to get over 1 TB of used disk space X 60 days onto a single 1 TB disk. Finddup assumes that the file list will fit in memory. This is a showstopper for me. Attempting to run finddup on my home server over a partial backup set of a single day (1,898,219 files) resulted in unacceptable memory usage (739MB after 4 hours on a machine with 512MB physical ram. This resulted in swap usage of over 600MB, and a 30 sec ssh login time). Findup lacks an option to require matching timestamps before hardlinking. This discards info that can be useful in a backup, and results in rsync thinking that the files have changed, and retransmitting them anyway. Finddup's syntax for specifying directories to link is clumsy when what I really want to link is /srv/dirvish/*/2009.01.1*/tree. In addition faster-dupemerge's ability to pass options to find means that I can do a quick partial run by limiting find to files large than 1MB, something that is often enough to recover 10+ GB after installing a couple of games. Cheers Andrew V. [0] http://www.furryterror.org/~zblaxell/projects/dupemerge/dupemerge.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Mailing list code of conduct, again
On Monday 19 May 2008 18:10, Bernhard R. Link wrote: People already CCed are a different beast. But CCing the creator of a mail by default is not reasonable. Unfortunately that doesn't work with Kmail's reply-to-list, which means manual attention is needed when the thread is being intentionally cc-ed to eg a bug report. I've seen too many arguments on this subject. My 2 c as a Debian user / reader of Debian lists is that perhaps the CoC should be softened to say eg, Note that it is considered best practice on Debian mailing lists to use the reply-to-list function of your email program, and to not cc someone who appears to be subscribed (unless they request otherwise). Andrew V. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#427697: Is sbackup maintained? If not, what to do?
On Friday 16 May 2008 10:20, Charles Plessy wrote: Since the revitalisation of sbackup is expected after the freezing of Lenny, we have to solve the most important bugs of the current version of sbackup. I do not know enough of python for helping on bug #427697 (the gid of the backups). If Aziz provides a patch, I can prepare a NMU for this one, #479826 (using su-t-root-X as su wrapper) and #431936 (tranlations). I can also make the package non-native (as it has anyway been suggested on this list for NMUs). By the way, can somebody suggest an appropriate gid ? There is the adm group, but please think very carefully about the security of private/privileged information. I'm not familiar with sbackup, but if its backuping mode 0600 files, then the resulting backups should be readably only by the original owner or root, unless explicitly configured otherwise. HTH Have a nice day, -- Charles -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#466728: ITP: python-trio -- RDF utilities
Hi On Thursday 21 February 2008 19:07, Noah Slater wrote: On Thu, Feb 21, 2008 at 08:44:00AM +0100, Christian Perrier wrote: Sorry, this is precisely rationale I fight against. Just saying if you don't know what this is, you don't need this defeats the purpose of packages descriptions. Fully agree. In the general case maybe but for this I disagree. For highly specialised development tools such as RDF there is really no need to be verbose about what the name actually means because those who would be interested already know. sarcasm mode on I know what RDF means. RDF is an abbreviation for radio direction finder. I guess there are digital RDFs now, and you're packaged python utils for dealing with then. Or maybe it's python utils for manipulating a Reuters Data Feed. Or for a Radial distribution function. Or one of half a dozen other possible meanings for RDF. [0] /sarcasm mode off Even though a package is highly specialised, you should make a package description as understandable as possible by everyday users. Consider the following (made up) example. feamodel-utils - utils for manipulating FEA models Utilities for manipulating FEA models. It supports ABACA, FEDME and FrEA format models. feamodel-utils - utils for manipulating Finite Element Analysis (FEA) models Utilities for manipulating Finite Element Analysis (FEA) models. It supports ABACA, FEDME and FrEA format models. The first is pure gobbledygook to anyone who does not recognise the key acronym. Because they can't understand what you're talking about, you run the risk of alienating them. By expanding the key acronym, the second is much more understandable. As such it's much less alienating. By limiting the key sentence is to words everybody can understand, it provides all users with sufficient information to decide whether the package is interesting to them/someone they know. I took a look at the current state of affairs w/r to RDF: [EMAIL PROTECTED]: ~ $ apt-cache search rdf | grep rdf liblrdf0 - a library to manipulate RDF files describing LADSPA plugins Short and long descriptions use RDF in context. liblrdf0-dev - liblrdf0 development files Short description refers to liblrdf0, long description provides context. librdf-perl - Perl language bindings for the Redland RDF library Qualifies RDF in short description, expands RDF in long description. librdf-ruby - Ruby 1.8 language bindings for the Redland RDF library Qualifies RDF in short description, expands RDF in long description. librdf0 - Redland Resource Description Framework (RDF) library RDF expanded and qualified in short description. librdf0-dev - Redland RDF library development libraries and headers Qualifies RDF in short and long descriptions. php5-librdf - PHP5 language bindings for the Redland RDF library Qualifies RDF in short description, expands RDF in long description. python-librdf - Python language bindings for the Redland RDF library Qualifies RDF in short description, expands RDF in long description. python-rdflib - RDF library containing an RDF triple store and RDF/XML Short and long descriptions provide context. Only one of these packages is expanding the acronym RDF. All of the above either provide context or qualify RDF. Most expand RDF in the long description. If you are going to use an acronym from a specialised field as a central part of the package description, you should either expand or explain the acronym. At the absolute least, you need to provide enough context so that the acronym won't be confused with other possible meanings. Anything less is just begging to be misunderstood. I really don't see the use case here. Package descriptions should as clear as possible to all users. Resource Description Framework is plain English that all readers can understand. They may not be familiar with the subject matter, but at least they can understand the words that you're using. That way you avoid alienating them with unnecessary jargon. Andrew V. [0]. http://en.wikipedia.org/wiki/Rdf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Correct spelling/capitalisation of project names
On Monday 21 January 2008 07:45, Russ Allbery wrote: Josselin Mouette [EMAIL PROTECTED] writes: Le mercredi 09 janvier 2008 à 11:19 +0100, Stefano Zacchiroli a écrit : Regarding the list above I would guess that what you want is something like the following: * glib - GLib * Glib - GLib glib is a regular English word, so I'll leave that one off in fear of false positives. I now have the rest. Whilst glib is an English word, it's not a word that's likely to be used in package descriptions. Andrew
Re: electronics-menu REJECTED (discussion)
[Sorry for the late reply] On Wednesday 16 January 2008 08:18, Hamish Moffatt wrote: It appears that the Technical menu should include at least; - Science - Engineering - Math - HamRadio - Electronics [snip] I thought that Science fit under Technical, if the offer was for one additional main menu. However it's clearly big enough to have its own main menu (there are lots of Science sub-categories in the standard). Math is an interesting case in that it's obviously a science, yet the tools are also used in engineering and also education. Hence your point about different user views. (On the other hand, putting everything under Technical helps too :)). As a user technical seems awkward and unintuitive to me. I would rather it was called Science and Engineering. Andrew V -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Flash player?
Hi On Sunday 18 March 2007 10:09, Gabriel Molina wrote: Hello, I've recently installed debian on a MAC Power PC G4 but I have not been able to find a flash player to work on it.. The one I found (gnash) did not work. Is there anything out there that I've over looked? Thank you for your help, Gabe. There's also libflash (binary package libflash-mozplugin and libflash-swfplayer). I use the non-free Adobe player, so I've never tried it. Good luck Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: apt hangs for ever
On Monday 27 November 2006 11:55, Brian May wrote: Hello, Is this a bug in apt? pbuilder update --override-config --configfile /tmp/pbuilder-local.SvMNy19452 W: /home/brian/.pbuilderrc does not exist Upgrading for distribution etch Building the build Environment - extracting base tarball [/var/cache/pbuilder/base-etch.tgz] - creating local configuration - copying local configuration - mounting /proc filesystem - mounting /dev/pts filesystem - policy-rc.d already exists - Installing apt-lines Refreshing the base.tgz - upgrading packages Get:1 http://ftp.au.debian.org etch Release.gpg [378B] Get:2 http://ftp.au.debian.org etch Release [74.4kB] Get:3 http://ftp.au.debian.org etch/main Packages/DiffIndex [2038B] Get:4 http://ftp.au.debian.org etch/main Packages [5579kB] Get:5 http://ftp.au.debian.org etch/main Packages [5579kB] 99% [5 Packages gzip 0] (hangs for ever) I have tried waiting for it to timeout, but it doesn't. Don't know whether its related, I stopped using ftp.au.debian.org. IIRC it was replying to package requests with a 302 redirect, which apt-proxy seemed to be unable to handle. Is this a 302 redirect something debian package management/archive mirroring tools are expected to handle, or are mirrors not expected to use redirects? ftp.iinet.net.au/debian/ also seems to be intermittent partially updated. I wonder whether they're mirroring from ftp.au.debian.org, and also having problems with the 302 responses. HTH Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How can the OS autodetect that a user is a newbie and offer help?
On Friday 20 October 2006 08:06, Peter Samuelson wrote: [Sander Marechal] True, but I meant that an app can kill X, requiring it to be restarted. Newbies get very confused at that point. Look, if you typed startx once, you can type it again. If you didn't, it means you're using a display manager like xdm, and xdm will restart X when it dies. If X just _freezes_ rather than dies, you don't get a shell prompt anyway. What you get is the opportunity to hit Ctrl-Alt-Backspace, so that X will die, and then you're back to the previous cases. I see no case where it is useful to alias startx to start-desktop. I agree. Unless X dies and then xdm _also_ dies. Does this ever happen? Even if it does, that should be recoverable by, at worst, power cycling the machine. The real problem is when someone who has never used the command line before, possibly never even seen the command line, is stranded in a vt because X didn't start during boot, started and immediately crashed, or crashes every time they login. They don't know how to do anything from the command-line. They don't even know how to read a man page/edit a file. They're the users who need basic cli help. A motd message saying type `help-me' for help, and a 3-4 page doc explaining some useful basic commands (man, less, nano, cd, cp, rm, startx etc) and how to reconfigure X might be enough to prevent some of them having to re-install. Just my 2 cents Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How can the OS autodetect that a user is a newbie and offer help?
On Wednesday 18 October 2006 05:41, you wrote: On 2006-10-17, Goswin von Brederlow [EMAIL PROTECTED] wrote: [snip] Anyway, the usual way to detect a newbie and give help to them seems to be to assume everyone a newbie and give little hints, startup tips, ... till they learn enough to turn them off. For examples see gimp or mc. PS: One of the hints better be how to turn the hints off. :) Someone suggested to me off-list that perhaps all we need is to provide a pointer to more newbie help in /etc/issue. Perhaps that would be the easiest to implement, and the easiest for users to disable :-), no? As already suggested, desktop environments could/should have a help/tips display that's turned on by default for new users. What's really needed is better help for newbies dumped unexpectedly at the command-line because X wasn't installed/properly configured/didn't start. I'd suggest only 1-2 lines of login help in /etc/issue, and command-line help (equal to 1-2 lines of text saying type xxx for help) in /etc/motd. xxx might display a help file/command line guide, or start a basic tutorial, or a special newbie shell environment. At its simplest it could just show a 80x24 page of help text containing basic commands and pointers to more help. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why does Ubuntu have all the ideas?
On Saturday 29 July 2006 04:42, Katrina Jackson wrote: Hardware supported by Ubuntu 6 months ago, should be supported by Debian by now. Just out of interest, what hardware in particular? Which Debian distribution? (Stable, testing, or unstable) Also remember that non-free drivers typically aren't installed automatically in Debian, whereas IIRC they are automatically installed in Ubuntu. Andrew V. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package Selection for Debian Live
On Tue, May 30, 2006 at 09:51:18PM +0200, Daniel Baumann wrote: at the moment, we have two types of Live CD images: * the small one which contains only packages of standard priority, * and three larger ones, each of which contains one of the common desktop-environments on it (gnome, kde, xfce). Please consider making the small one suitable as a generic backup/rescue/recovery disk. ie include some lower priority tools such as ntfsprogs, xfsprogs, parted, partimage and dar. Andrew V. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Testing excuses question
On Monday 26 June 2006 23:08, Jiri Palecek wrote: Sorry, I do not understand. You mean the breaks xx packages thingy? I have already said, that of these 74 packages, 15 are dependent, and they are more or less prepared to enter testing along with neon. The rest only depends on those 15, and seem (I have not checked all) to be OK if the 15 go in (eg. they don't have to go in). Upgrading neon breaks subversion (and other packages), but subversion is waiting for both neon and perl. Perl FTBFS on hppa and mips. HTH Andrew V. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#374607: ITP: mlmmjadmd -- a networked daemon for remote administration of mlmmj
On Tuesday 20 June 2006 18:26, Søren Boll Overgaard wrote: mlmmjadmd is a TCP based server that allows clients to remotely administer an mlmmj installation. Currently, almost all mlmmj tunables and actions are supported. mlmmjadmd makes it easy to construct synchronous adminitratitive UI's. Please include a one sentence description of mlmmj. eg. (taken from freshmeat) mlmmj (Mailing List Managing Made Joyful) is a mail server-independent reimplementation of the ezmlm mailing list manager.
Re: Getting rid of circular dependencies, stage 4
On Thursday 11 May 2006 01:25, Frank Küster wrote: The only things that should be installed separately are probably aptitude, apt and dpkg, then just dist-upgrade. From memory, upgrading apt + friends seperately isn't possible whilst synaptic is installed. In sarge, the gnome meta package depends on synaptic, so this probably applies to a lot of desktop systems. In sarge, synaptic depends on libapt-pkg-libc6.3-5-3.3, which is provided by apt. In etch, apt provides libapt-pkg-libc6.3-6-3.11, which matches the depends of synaptic in etch. Adding CC to APT Development Team deity@lists.debian.org since I'm wondering whether the changes to apt really required dropping the provides of libapt-pkg-libc6.3-5-3.3? For the future, could apt provide a real library, hence solving this problem for etch+1? Andrew V.
Re: Bug#354803: ITP: stx2any -- A converter from structured plaintext to multiple formats
Hi On Wed, 1 Mar 2006 19:23, Panu Kalliokoski wrote: Description : A converter from structured plaintext to multiple formats What formats? Please be a little more verbose. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#347617: ITP: itrans -- Converts romanised Indic text to LaTeX, HTML Postscript
On Fri, 13 Jan 2006 00:58, Frank Küster wrote: Yves-Alexis Perez [EMAIL PROTECTED] wrote: Frank Küster wrote: Baishampayan Ghose [EMAIL PROTECTED] wrote: How did you manage to download the sources from there? I get: ftp://ftp%40aczoom%2Ecom:[EMAIL PROTECTED]/itrans/53/itrans53 .zip That's exactly what I tried - it doesn't matter which password or username I send. The error message points to a screwed up setup of the FTP server, according to Google; but if it works for you it's obviously more complicated... Regards, Frank The ftp: url at http://www.aczoom.com/itrans/#download works just fine in Konqueror. From the console $ftp ftp.aczoom.com Name (ftp.aczoom.com:andrew): [EMAIL PROTECTED] Password:aczoom.com is also fine. Andrew
Re: No 2.6 kernels for 586 in Sarge and up
Hi
On Tue, 3 Jan 2006 02:55, Frans Pop wrote:
On Monday 02 January 2006 16:40, Jérôme Warnier wrote:
I wonder why there is no 2.6 kernel package for 586 in Sarge while
there is for 2.4?
I can find 386-486-686 and k7, but no 586.
Try linux-{source,image,headers}.
(on sarge, long lines trimmed)
$ apt-cache search 586 |grep image
kernel-image-2.4-586tsc - Linux kernel image for version 2.4 on Pentium-Clas
kernel-image-2.4.27-2-586tsc - Linux kernel image for version 2.4.27 on Pent
As Jérôme said, no 2.6 kernel compiled for 586 in sarge.
Andrew
Re: How to Increase Contributions from Volunteers
On Tue, 3 Jan 2006 11:52, Manoj Srivastava wrote: Given the choice between having to double check work done by potentially inexperienced folks, and ensuring that the package is done by people who can do some of the double checking on their own, and make less errors, I'd go for the latter every time. Debugging/proof reading other peoples work is always more thankless, error prone, and often less thorough than following good practices and minimizing errors the first time around. And that comes with experience. Now, if you had a bunch of actual peers we were talking about, then sure, more eyes do make for lighter work. But that is not what we are discussing. We are talking about letting almost anybody commit, and hope that the experienced person will catch all the mistakes. I am not convinced that the mistake shall not grow in the end product in this case. Yes, but it's only by doing the work, either maintaining their own package, or submitting patches / directly committing to team maintained packages that people gain the skills they need to become DDs. Whats needed is a genuine team of 2-5 suitable new maintainer 'peers' co-maintaining half a dozen similar or related small packages (or one-two medium packages) plus one DD reviewing changes and sponsoring uploads every few weeks. Beginners can start off sending patches by mail, either to a mailing list, or to bug reports. (I do agree there should be some sort of control over commit access). If they don't know enough to contribute they will either learn, or drop out. (It worth pointing out that handling bug reports can be a useful contribution.) Once they have shown that they can contribute they can be given commit access. The one of the goals of this sort of team maintenance should be team members helping each other learn. The end result in terms of package quality should be less bugs than the current process of each individual new maintainer maintaining a couple of packages and a DD sponsoring the occasional upload. Yeah, there will probably will be more bugs committed to version control, but their will (hopefully) be more sets of eyes catching them. The apprentice maintainers don't need to maintain important packages. There are plenty of priority optional/extra packages, many with alternative packages with similar functionality. The DD does not have to do any more work per upload than they would under the current system. The main point is that this sort of team lowers the bar to entry. Someone who lacks the skills to create their own package can still contribute. And by contributing they can learn new skills. Just my 2 cents Andrew V. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Listmaster] Seeking petsupermarket
On Tue, 3 Jan 2006 09:25, Cord Beermann wrote: Someone who is subscribed to d-devel forwards the mails to petsupermarket. petsupermarket itself is not subscribed to any of our mailinglists. If you have seen those c-r-responses outside of the debian-lists, or in the last days on other lists than debian-devel, then this information is maybe helpful to identify the address. debian-user is also affected Andrew V. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: udev event completion order
On Thu, 22 Dec 2005 06:29, Darren Salt wrote: I demand that Alexander E. Patrakov may or may not have written... Kay Sievers wrote: There is also the plan to do parallel device probing inside the kernel some day, that will make the situation of relying on kernel names even more fragile. Right, this means that the way of passing root=/dev/hdc2 will no longer work because /dev/hdc will sometimes become /dev/hde. That will also break scripts/apps that manipulate disks/partitions. This could easily result in some-one restoring a backup over the wrong disk. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Thoughts on Debian quality, including automated testing
On Thu, 22 Dec 2005 04:32, David Nusinow wrote: On Wed, Dec 21, 2005 at 05:32:21PM +0100, Thomas Hood wrote: This is not a fair characterization of what the introduction of a two-maintainer rule would be doing. No one should be insulted by general rule changes designed to make Debian work better. I think a two-maintainer rule is a bit artificial and perhaps the wrong solution. Taking a cue from teams that work well in Debian (Gnome, d-i, etc) indicates that somewhat larger teams with a common goal and a fairly large set of packages under their umbrella will work in practice. This provides the opportunity for autonomy (someone can take ownership of a package within the team) but also a cohesiveness and a known set of people to turn to when you're in need. It's pretty simple to found such a team too. All it takes is some interested people and an alioth project. - David Nusinow I was about to suggest exactly that. Thanks David Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel 2.6.14
Hi On Thu, 15 Dec 2005 22:34, Richard Fojta wrote: Hi, I've recently try to install new kernel. Somethings go wrong and I cannot found solution. There is some problem with configuration. It seems to me, that this problem is not unique. Does anybody know how to solve ti? [This is probably more appropriate for -users, attempting to move there. Reply to set to debian-user@lists.debian.org, Richard Fojta [EMAIL PROTECTED] Bcc-ed to -devel] You don't give enough info be sure, but this sounds like it might be the same problem. On Thu, 15 Dec 2005 06:18, Andrei Popescu wrote: [EMAIL PROTECTED] wrote: Today I upgraded my system. It wouldn’t boot up. Instead it give me this error: Waiting 2 seconds /sys/block/hda/dev to show up. /bin/cat:/sys/block/hda/dev: no such file or directory. Is this fixable or do I have to set up my complete system again? Hope not. Pascal. Here is what worked for me: http://lists.debian.org/debian-user/2005/12/msg01408.html http://lists.debian.org/debian-user/2005/12/msg01406.html post your steps if you get stuck Andrei HTH Andrew V.
Re: Debian and the desktop
On Tue, 13 Dec 2005 21:08, Bill Allombert wrote: On Tue, Dec 13, 2005 at 10:28:28AM +0100, Moritz Muehlenhoff wrote: This is beyond tasksel, but Bob User would profit immensely from generic menu entries. SuSE does this and I think it's very helpful. Most people don't care, which web browser they are using and if they're browsing through their application menu, they're confused by an entry called Kopete, while an entry called Instant Messaging Program is a lot more helpful. So maybe menu should be extended to keep both forms, so that the generic form can be chosen during installation. Once Bob User has turned into Bob Hacker he can switch back to the detailed form. Hello Moritz, There are several people interested with this. As far as the Debian menu system is concerned, I am no objection implementing this proposal. What is needed at this point is a draft policy defining what will be the new layout and what will be the generic titles. However that will not affect the KDE and GNOME main menu, only the Debian submenu. On my sarge system KDE already does this. (Installed from sarge Installer beta 1 IIRC). Menu-Internet-Download Manager (KGet) FTP Client (KBear) etc Not all programs are properly classified eg. Mozilla, Thunderbird, most of the Development tools sub-menu, the Debian sub-menu. Andrew V. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Automatic closing of bugs
On Sat, 3 Dec 2005 03:03, Kevin B. McCarty wrote: Simon Richter wrote: Matthew Palmer wrote: Your mission, should you choose to accept it, is dig through the Perl code in merkel:/org/bugs.debian.org/scripts and work out how to add this functionality. grin You can use package foo as a command to control@ to tell it ignore everything that does not affect bugs against foo. I am unsure whether comma notation is allowed (so katie could generate package bar,wnpp at the beginning of bug closing emails). Yes, but for multi-binary source packages, the package changelog doesn't specify which binary package the bug applies to, so katie would have no way of knowing whether to say (e.g.) package bar, package libbar1, or package libbar-dev. I think this functionality would have to be implemented on the BTS side. Logically package foo should work where foo is a source package. (Because its quite common to eg tag multiple bugs pending at the same time). Andrew V. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: texlive-basic_2005-1_i386.changes REJECTED
On Mon, 28 Nov 2005 22:28, Thiemo Seufer wrote: FWIW, Debian package names prefer e.g. foo-en-uk-doc over foo-documentation-ukenglish. This allows to filter documentation packages by name (doc-* or *-doc), and following the standardized ISO abbreviations also seems to be better than using yet another scheme. As a user, I much prefer foo + libfoo + foo-doc-en + foo-doc-fr rather than foo + libfoo + foo-en-doc + foo-fr-doc To me the hierarchy tree package-sub-package-type-language/locale is much more natural than package-language/locale-sub-package-type Cheers Andrew V. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: texlive-basic_2005-1_i386.changes REJECTED
On Tue, 29 Nov 2005 00:40, Thiemo Seufer wrote: Andrew Vaughan wrote: On Mon, 28 Nov 2005 22:28, Thiemo Seufer wrote: FWIW, Debian package names prefer e.g. foo-en-uk-doc over foo-documentation-ukenglish. Can you provide a reference/stats to back this up. (on sarge) $ apt-cache search doc |grep -e'-doc-[a-z][a-z] ' |wc -l 12 $ apt-cache search doc |grep -e'-[a-z][a-z]-doc ' |wc -l 5 Examination of the first set shows 1 false positive: gmt-doc-ps - PostScript docs for the Generic Mapping Tools The other 11 translated docs Examination of the second set shows: adduser-ng-doc - Documentation for AddUser-NG users gnome-db-doc - frontend to the GDA architecture for GNOME -- documentation gri-ps-doc - PostScript manual for gri, a language for scientific graphics. libinti-gl-doc - GtkGLExt bindings for Inti - shared libraries proj-ps-doc - PostScript docs for cartographic projection filters and library Also look at the output to apt-cache search firefox |grep locale This allows to filter documentation packages by name (doc-* or *-doc), and following the standardized ISO abbreviations also seems to be better than using yet another scheme. snip To me the hierarchy tree package-sub-package-type-language/locale is much more natural than package-language/locale-sub-package-type It may look more natural, but it makes pattern matching harder (e.g. python-docutils is a false positive for the naive approach). Probably any approach will yield false positives with naive search strings. However a few false positives don't matter in the typical use case of an interactive user searching for a package. Thiemo Package naming should be about what makes most sense to the users. For me, that means increasing specialisation (of package) means tacking additional suffixes on the end of the packagename. package foo. add a doc package foo, foo-doc add translated docs foo, foo-doc-en, foo-doc-jp, foo-doc-fr etc. (Regardless of which way is considered better, this sort of thing should be standardised and defined in policy IMO). Why do you need to filter for *-doc packages anyway? If you are looking for say Japanese doc packages, filtering on say *-doc-jp is as easy as *-jp-doc isn't it? If you want all doc packages, regardless of language/formatting/encoding, then filtering for doc-* and *-doc is not enough anyway. In order to find *-doc-html, *-doc-ps you need you need to add *-doc-* anyway. (i) You are going to miss packages which don't contain doc in the name. (eg ada-reference-manual, apt-dpkg-ref, docbook-defguide). (ii) In order to find *-doc-html, *-doc-ps etc packages you need to add *-doc-* anyway. (eg exim4-doc-html, exim4-doc-info, r-doc-html, r-doc-pdf etc. Note that renaming these to say exim4-info-doc suggests naive users that this is the documentation for the exim4-info package.) (iii) So you need to search for doc-* *-doc and *-doc-* anyway. eg. apt-cache search doc | grep -e'^doc-\|-doc-\|-doc ' or apt-cache search doc | grep -e'^doc-\|-doc\b' Cheers Andrew V. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: problem installing libmotif-dev on debian sarge stable
On Thu, 28 Jul 2005 05:17, Alexander Wirt wrote: Frederico Rodrigues Abraham schrieb am Mittwoch, den 27. Juli 2005: i am using debian stable... (sarge) Then I'm sorry, I tried to reproduce the problem, here my results on a fresh installed sarge chroot: [EMAIL PROTECTED]:/# apt-get install libmotif-dev Reading Package Lists... Done Building Dependency Tree... Done Package libmotif-dev is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source However the following packages replace it: lesstif2-dev lesstif-dev E: Package libmotif-dev has no installation candidate [snip] Works no problem. And for completeness my sources.list: [EMAIL PROTECTED]:/# cat /etc/apt/sources.list deb http://ftp.de.debian.org/debian/ sarge main deb-src http://ftp.de.debian.org/debian/ sarge main deb http://security.debian.org/ sarge/updates main libmotif-dev is in non-free. So you should really check your sources list and if you really have a sarge system and not sid/etch. Best wishes Alex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: packages missing from sarge
Hi all, The following two packages are the only ones not in testing that I currently use. Note that both are in woody, so it would be good they also shipped with sarge. (packages maintainers cced, in the hope they might fix these themselves). (Note: I'm not a dd, so I can't fix these myself.) apt-proxy Bug: #304182 apt-proxy-v1tov2 generates empty timeout value. (Tags: patch, pending - has been pending for 2 weeks now.) Synopsis: The script that upgrades old conf file to the new conf file generates fault config. partimage Bug: #294953 partimage - refuses to restore image on i386 which is created on s390. Synopsis: partimage seems to be i386 only, yet is still built for other arches. The changelog for 0.6.4-10 says: partimage (0.6.4-10) unstable; urgency=low * Change to i386 only! Closes: #268248 -- Sergio Rua [EMAIL PROTECTED] Wed, 13 Oct 2004 12:16:25 +0100 So it seems that the changes in 0.6.4-10 were insufficient to really fix #268248. Thanks Andrew V. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: Re: partimage-server]
Hi Martin On Mon, 18 Apr 2005 10:51 pm, Martin Kos wrote: hi everbody i'm forwarding this to the list and perhaps somebody could close the bug for partimage-server, please? greets KoS ps.: i am NOT a subscriber of the list so please take me on the CC Original Message Subject: Re: partimage-server Date: Fri, 15 Apr 2005 11:34:57 +0200 From: Sergio Rua [EMAIL PROTECTED] To: Martin Kos [EMAIL PROTECTED] References: [EMAIL PROTECTED] Hello, i just wanted to install partimage-server on a testing/sarge system and i've seen that its not moving from unstable to testing because of a WOODY-bug-report? as i've seen the bug is tagged as woody, shouldn't than the package go in testing automatically? AIUI all packages from the same source package migrate to testing together. Partimage-server is built from the partimage source package. This source package has 2 RC bugs. - #210611 tagged woody which should be irrelevant for testing migration - #294953 which will block all of partimage from testing. snip -- Cheers Andrew V. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
