Preparation of the next stable Debian GNU/Linux update [Oct 8th]
Preparation of the next stable Debian GNU/Linux update == An up-to-date version is at http://people.debian.org/~joey/3.0r3/. I am sorry for not being able to send out the entire document, but the preparation efforts list has grown so much that the large mail is rejected at the Debian listserver due to its sheer size. I am preparing the third revision of the current stable Debian distribution (woody) and will infrequently send reports so people can actually comment on it and intervene whenever this is required. If you disagree with one bit or another, please reply to this mail and explain why these things should be handled differently. There is still time to reconsider. The plan is to release this revision at some time in the future, hopefully before the release of sarge. It may be the last update if no updates to 3.0 are possible after sarge has been released. An ftpmaster still has to give the final approval for each package since ftpmaster are responsible for the archive. However, I will try to make their work as easy as possible in the hope to get the next revision out properly and without too much hassle. The regulations for updates to the stable Debian release are quite conservative. The requirements for packages to get updated in stable are: 1. The package fixes a security problem. An advisory by our own Security Team is required. Updates need to be approved by the Security Team. 2. The package fixes a critical bug which can lead into data loss, data corruption, or an overly broken system, or the package is broken or not usable (anymore). 3. The stable version of the package is not installable at all due to broken or unmet dependencies or broken installation scripts. 4. All released architectures have to be in sync. 5. The package gets all released architectures back in sync. It is (or (and (or 1 2 3) 4) 5) Regular bugs and upgrade problems don't get fixed in new revisions for the stable distribution. They should instead be documented in the Release Notes which are maintained by Rob Bradford mailto:[EMAIL PROTECTED] and are found at http://www.debian.org/releases/woody/releasenotes. Packages, which will most probably be rejected: . Packages that fix non-critical bugs. . Misplaced uploads, i.e. packages that were uploaded to 'stable unstable' or `frozen unstable' or similar. . Packages for which its binary packages are out of sync with regard to all supported architectures in the stable distribution. . Binary packages for which the source got lost somehow. . Packages that fix an unusable minor part of a package. If you would like to get a package updated in the stable release, you are advised to talk to the stable release manager first (see http://www.debian.org/intro/organization). This is probably the last update to the current stable Debian release since updates are impossible when a new suite is labelled stable. It's also possible that the current stable Debian release won't be updated at all. ChangeLog - 2004/10/08 12:28 MET * Accepted lesstif1-1 * Accepted libapache-mod-dav * Accepted net-acct * Accepted netkit-telnet * Accepted rp-pppoe Disclaimer -- This list intends to help the ftp-masters releasing 3.0r3. They have the final power to accept a package or not. If you want to comment on this list, please send a mail to Martin Schulze [EMAIL PROTECTED]. Last updated 2004/10/08 12:28 MET -- Unix is user friendly ... It's just picky about its friends. Please always Cc to me when replying to me on the lists. signature.asc Description: Digital signature
Re: RFC: best practice creating database
On Thu, Oct 07, 2004 at 05:19:07PM +0200, Uwe Steinmann wrote: On Thu, Oct 07, 2004 at 03:38:59PM +0200, Philipp Matthias Hahn wrote: Hello! What is consideres best practice when a package uses a SQL database (mysql, postgresql) and needs to create its own catalog and/or tables? [ ] Disable the package until someone has manually setup the database? [ ] Ask a lot of questions via debconf and try to setup in postconf? I'd go for the second option. [snip] Setting up a database is somewhat errorprune but still something achievable in a postinst script. Methinks we need something like wwwconfig-common, but for databases... regards Andrew
Common set of debconf templates (was: Re: RFC: best practice creating database)
if you think that it would be too complicated/flaky, i'd add a debconf note (of _low_ priority!) and put something in README.Debian. While we are at it : Could *please* maintainers of packages interacting with RDBMS establish a set of *common* debconf templates for prompting users ? While translating the debconf templates for packages, we have found dozens of similar questions such as: -Database host (wrong Englishthis should probably be Database *server* or something similar) -Database user -Password for this user -Database administrator username -Database administrator password -Database name -Should the database be purge on package purge? and so on Depending on the maintainer's English skills, these templates are more or less well writtenor often not clear about involved concepts (the database user is often the database *owner*). All such templates should probably go into a common set of debconf templates, provided by a very small package, which all these packages should depend upon, instead of constantly reinvent the wheeland make up, translators, do damn boring work. Such common debcon templates set in a separate package could be an interesting thing to work on for the next release of Debian.
Re: ITP: cddb.bundle -- CDDB Bundle for GNUstep
* Jeff Teunissen [Thu, 07 Oct 2004 03:52:37 -0400]: What DOES bug me is mindlessly adding gnustep- to the names of all packages that use it, because most of the developers of those packages have dick to do with some mythical GNUstep desktop, which itself does not exist. but note that adding gnustep- or gstep- as prefix to these packages is/was (from what I've seen so far): (a) the preferred solution by a high majority of DD, as to what benefits most to archive namespace clutter. *and* (b) what can be regarded as most useful for our users (I, at lest, think it is, and some other people will as well, I hope). In addition to Debian and QuakeForge, I'm involved in a project to create a user environment that happens to use the GNUstep libraries. That project is called Backbone, and most of what we have done so far is included in Debian (the packages preferences.app, terminal.app, and textedit.app). We're not GNUstep. One of us is also a member of the GNUstep project, but that's not particularly relevant. but there must be a close relationship to GNUstep when you have: preferences - GNUstep Preferences application terminal - Terminal Emulator for GNUstep textedit.app - Basic text editor for GNUstep Why should packages that are part of the Backbone desktop (I use quotes because putting a desktop on the root menu makes no sense from our perspective), or packages that are simply useful (or not) programs that use the GNUstep libraries, be advertised as being GNUstep programs? That's silly. see above. I'd rather see: gstep-preferences - GNUstep Preferences application from the Backbone project gstep-terminal - Terminal Emulator for GNUstep from the Backbone project gstep-textedit - Basic text editor for GNUstep from the Backbone project what I fail to see is the reluctance to put gstep- in the name *of* *the* *Debian* *package* when (a) GNUstep is already there in the short description *and* (b) is what most other members of the project has been asking for. [btw, the mail I'm replying to is the *first* (that I can find) containing the Backbone word. if this had been mentioned earlier, I'm sure it would had made people happier packages with names like backbone-$whatever or $whatever-backbone that the current $foo.app.] enlightenment appreciated, -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 When you don't know what to do, walk fast and look worried.
Re: Updating scanners and filters in Debian stable (3.1)
On Thu, Oct 07, 2004 at 02:58:05PM -0700, Thomas Bushnell BSG wrote: I assume you mean use unstable? see below. No, you can simply use private repositories, or backports, or whatever else. There need be no Debian-branding of it in any way. What Debian gives people is some kind of assurance about the stability and care that goes in to it, and so far, what I have heard is that you want to be entirely unrestricted. Except that those private repositories and backports have no policy and no maintenance. My proposal is to create a policy for a repository with maintenance, security updates which introduces new packages and provides new functionality on outdated or useless packages from stable, and is built against stable. Puting a debian branding and effort on having such idea would make Debian only better. For those who want to use such infrastructure. And some people have already outlined a policy draft on the list. We can take them and try to make policy out of them. -- Jesus Climent info:www.pumuki.org Unix SysAdm|Linux User #66350|Debian Developer|2.4.27|Helsinki Finland GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69 It's called a change-over. The movie goes on and nobody knows the difference. --Narrator (Fight club)
Re: spam checking and CPU time
On Fri, Oct 08, 2004 at 11:24:18AM +1000, Brian May wrote: Jesus Indeed the latest version of CRM114 managed to eat my CPU, Jesus but i downgraded to the previous one and everything went Jesus back to more than fine. What version did you downgrade to? In fact I cannot say it, because it was several months ago before i started testing SA3 in my mail box (eating my own dog food) and another sysadm updated it to the latest. After that i have not deared to downgrade it again and start using it again. -- Jesus Climent info:www.pumuki.org Unix SysAdm|Linux User #66350|Debian Developer|2.4.27|Helsinki Finland GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69 Jack, please, I'm only an elected official here, I can't make decisions by myself! --Mayor (The Nightmare Before Christmas)
Re: Common set of debconf templates (was: Re: RFC: best practice creating database)
(crossposted to -devel and -i18n...feel free to followup on the appropriate place...it probably belongs to both currently) Quoting Andreas Tille ([EMAIL PROTECTED]): On Fri, 8 Oct 2004, Christian Perrier wrote: All such templates should probably go into a common set of debconf templates, provided by a very small package, which all these packages should depend upon, instead of constantly reinvent the wheeland make up, translators, do damn boring work. IMHO this is a brilliant idea but I doubt that it would be realized if noone of the translators team would start building this package. You people seem to have the best knowledge of it and thus I would start providing such a package and start filing wishlist bug reports against the relevant packages. [Feel free to quote me anywhere, but I wanted to avoid ACK-messages ...] Indeed, this is a long time since I think about such common debconf templates package. So, your remark about translators is probably a very good one.:-) The only problem is that I'm damn unable to find a 25th hour in the day for working on this. Would any of the i18n people start working on such a package ? Let me resume the situation shortly: Several packages use some kind of very usual debconf templates for prompting about common things. For instance, most packages creating a database in a RDBMS ask for: -Database server hostname -Database server port -Database name -Database owner username (sometimes called Database user) and so on... I imagined that a very small package named debconf-rdbms could include common templates for this. Then packages needing such templates can just Depend on it (or Pre-Depend, I'm not sure) and use db_register and similar stuff for using the common template for prompting... This would save us translators a lot of boring task translating always the same things. This would also save some space in /var/lib/dpkg/info as templates would not be replicated with their translations. Several other parts could also benefit from this...which would need creating a few debconf-whatever packages... The current way of handling common templates by the use of shared/* is not optimal ATM, as all packages using shared/* templates must define them. They must have the same text...but nothing enforces this...and there is no mechanism for reusing the translations which are replicated many times. So, all this is just a matter of creating a first preliminary very small package targeted at database stuff. Just start with one question and, in the same time, work with a package which could make use of it. This could be used as a live demo and then be generalized among other packages using and creating a database during their configuration.
Re: ITP: cdplayer.app -- Small audio CD player for GNUstep
Am Fr, den 08.10.2004 schrieb Seo Sanghyeon um 3:54: Please rename planner to gnome-planner immediately. Please rename netspeed to gnome-netspeed immediately. You do realize that both planner and netspeed are much less general program names than cdplayer or terminal? -- |=| Michael Piefel |=| Member of the Debian project
Re: Common set of debconf templates (was: Re: RFC: best practice creating database)
On Fri, 8 Oct 2004, Christian Perrier wrote:
The only problem is that I'm damn unable to find a 25th hour in the
day for working on this.
Once I've read a childresn book where a damn bad guy had stolen the
Wednesday. The good boy in this book reconstructed the day the following
way:
- the hours in a scool are only 45minutes so take the remaining
15 minutes
- take the waiting hours when the bus is late
- take the minutes when you are in fear - these minutes are
longer than normal ones - so make them equal to normal ones
and you have some additional time
-- add these times and you get an extra day. ;-)
Several other parts could also benefit from this...which would need
creating a few debconf-whatever packages...
I really like this idea. Most Zope products are using shared debconf
questions and Custom Debian Distributions uses this trick as well.
The current way of handling common templates by the use of shared/* is
not optimal ATM, as all packages using shared/* templates must define
them. They must have the same text...but nothing enforces this...and
there is no mechanism for reusing the translations which are
replicated many times.
I doubt I understand what you mean. At least in the packages I mentioned
above the template is not mentioned in the packages. They just use
the variable in {post,pre}{inst,rm} scripts.
So, all this is just a matter of creating a first preliminary very
small package targeted at database stuff. Just start with one question
and, in the same time, work with a package which could make use of it.
This would be really great.
This could be used as a live demo and then be generalized among other
packages using and creating a database during their configuration.
Having a working example is the first step for a good solution.
Kind regards
Andreas.
Re: RFC: best practice creating database
On Thu, 7 Oct 2004, Peter Eisentraut wrote: I say, create the tables when the package starts for the first time. As an analogy, programs using Berkeley-type databases normally set up their databases automatically when they run and don't require postinst processing. Hmmm, I doubt I understand this right. I will package GnuMed which contains a server package (more or less SQL scripts which are feeded into PostgreSQL) and a client package which accesses the GnuMed database on the server. I see no chance to create the database outside of the postinst script. Did I missunderstood something? Kind regards Andreas.
Re: Package name for GNOME panel applets
On Fri, 2004-10-08 at 12:09 +0900, Seo Sanghyeon wrote: This was discussed before: http://lists.debian.org/debian-gtk-gnome/2003/07/msg00176.html Mailing to d-g-g, CCing d-d. My comments below. And see also Debian GNOME Packaging Policy: http://www.burtonini.com/computing/gnome-policy-20030502-1.html Quote: Panel Applets. TODO: Panel applets -- gnome-applet-foo or foo-applet or gnome-foo-applet? I ran apt-rdepends on libpanel-applet2-0 and weeded out full applications which happened to provide applets. The result follows: foo style: apt-watch bubblemon flink glunarclock gxmms netapplet netspeed teatime foo-applet style gtodo-applet imhangul-status-applet lock-keys-applet mboxcheck-applet netmon-applet quick-lounge-applet rhythmbox-applet seti-applet xpenguins-applet gnome-foo-applet style: gnome-cpufreq-applet gnome-netstatus-applet gnome-randr-applet gnome-swallow-applet foo-gnome style: verbiste-gnome oooqstart-gnome gnome-foo style: gnome-blog gnome-pilot foo-applet-gnome style: uim-applet-gnome Which is, not consistent. I don't like netspeed package name, which is too generic, while its upstream name is netspeed_applet. See http://mfcn.ilo.de/netspeed_applet/ . Personally, I prefer gnome-foo-applet. In the cases where the applet name contains gnome or applet it can be re-arranged. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF signature.asc Description: This is a digitally signed message part
Re: ITP: cddb.bundle -- CDDB Bundle for GNUstep
Adeodato Simó wrote: * Jeff Teunissen [Thu, 07 Oct 2004 03:52:37 -0400]: What DOES bug me is mindlessly adding gnustep- to the names of all packages that use it, because most of the developers of those packages have dick to do with some mythical GNUstep desktop, which itself does not exist. but note that adding gnustep- or gstep- as prefix to these packages is/was (from what I've seen so far): (a) the preferred solution by a high majority of DD, as to what benefits most to archive namespace clutter. I've only seen a few highly-vocal people whenever this comes up, and this suggests to me that few people even /care/ -- but those few that do are in violent disagreement. (b) what can be regarded as most useful for our users (I, at lest, think it is, and some other people will as well, I hope). I don't really see how it's useful -- it doesn't matter what libs are used by an app. Why should, for example, TalkSoup (an IRC client) be called g[nu]step-talksoup? It's the only program with that name, it's not generic, it's not part of the GNUstep project, and it's not even written by a member of the GNUstep project. It has a somewhat-different interface, but you expect that from most apps that work on X. So what's the difference? About the most that's reasonable is to stick .app on the end to tell people that it's not run in the usual manner (unless there's a script included to start it up, in which case no differentiation ought to be made). In addition to Debian and QuakeForge, I'm involved in a project to create a user environment that happens to use the GNUstep libraries. That project is called Backbone, and most of what we have done so far is included in Debian (the packages preferences.app, terminal.app, and textedit.app). We're not GNUstep. One of us is also a member of the GNUstep project, but that's not particularly relevant. but there must be a close relationship to GNUstep when you have: preferences - GNUstep Preferences application terminal - Terminal Emulator for GNUstep textedit.app - Basic text editor for GNUstep Those descriptions are the result of Debian maintainer malfunctions. None of those applications is for GNUstep; they're part of, and for, Backbone. So far they still work with vanilla GNUstep, but that will not always be so and we don't feel any need to ensure that. Why should packages that are part of the Backbone desktop (I use quotes because putting a desktop on the root menu makes no sense from our perspective), or packages that are simply useful (or not) programs that use the GNUstep libraries, be advertised as being GNUstep programs? That's silly. see above. I'd rather see: gstep-preferences - GNUstep Preferences application from the Backbone project gstep-terminal - Terminal Emulator for GNUstep from the Backbone project gstep-textedit - Basic text editor for GNUstep from the Backbone project And I'd rather see: backbone - Dependency package for the Backbone user environment backbone-sysapps - Core applications for Backbone backbone-sysframeworks - Core frameworks for Backbone backbone-systools - Core utilities for Backbone backbone-* (a la carte things from the currently-empty Common set) where -sysapps contains Preferences, Terminal, TextEdit, and eventually our workspace manager; -systools contains open, the openapp diversion, bbterm, and panel (a command-line program for popping up various types of panels [dialog boxes] -- this may not be what it is eventually called, of course); and -sysframeworks contains the PrefsModule and HelpPanel frameworks. That would be the Backbone System (equivalent to the GNOME or KDE core), which we plan to make more integrated over time. Additionally, we'll have other sections for optional components (much like Debian's optional and extra priorities) which can be cherry-picked. [snip] [btw, the mail I'm replying to is the *first* (that I can find) containing the Backbone word. if this had been mentioned earlier, I'm sure it would had made people happier packages with names like backbone-$whatever or $whatever-backbone that the current $foo.app.] Take that up with the Debian maintainers of the Backbone packages. While I am a DD, I have nothing to do with their packaging (since all of the GNUstep stuff I have is source-built and usually from cvs, I wouldn't be using my own packages). -- | Jeff Teunissen -=- Pres., Dusk To Dawn Computing -=- deek @ d2dc.net | GPG: 1024D/9840105A 7102 808A 7733 C2F3 097B 161B 9222 DAB8 9840 105A | Core developer, The QuakeForge Projecthttp://www.quakeforge.net/ | Specializing in Debian GNU/Linux http://www.d2dc.net/~deek/
Re: ITP: cdplayer.app -- Small audio CD player for GNUstep
On Fri, Oct 08, 2004 at 10:54:59AM +0900, Seo Sanghyeon wrote: On Thu, Oct 07, 2004 at 09:25:45PM -0400, sean finney wrote: i know this has been beaten to death, i really do. but i can't help it... On Fri, Oct 08, 2004 at 01:24:00AM +0100, G?rkan Seng?n wrote: Description : cdplayer.app -- Small audio CD player for GNUstep then why not gnustep-cdplayer? you don't see the gnome people doing this with their cdplayer, or kde folks with their pdf viewer... (/me puts on his asbestos suit) Please rename planner to gnome-planner immediately. Please rename netspeed to gnome-netspeed immediately. This is not the appropriate place to be filing bugs; direct them to [EMAIL PROTECTED] -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
PROPOSAL: debian-mozilla@lists.debian.org (was: Transitioning to Mozilla Firefox 1.0PR)
[Cc and reply-to debian-devel] Am 2004.10.08 06:49 schrieb(en) Mike Hommey: On Fri, Oct 08, 2004 at 12:24:07AM +0200, Aurelien Jarno wrote: I remarked that mozilla-firefox is built on hppa using gcc-3.2 (I [...] Dear all, due to the ever increasing number of mozilla-based packages I wonder if it would be a good thing to have a separate debian-mozilla mailing list. Personally I have big difficulties understanding the hacked way how mozilla extensions etc are being repackaged for Debian and I would be very happy if there was a place to discuss such matters. Looking forward to any comments opinions, Johannes
Re: possible mass bug filing: spamassassin 3
On Wed, Oct 06, 2004 at 07:37:42PM +0200, martin f krafft wrote: Now it's running at -m5 (the suggested value) and I have not had problems since. Of course, now I only get half the throughput, and my queue has not emptied for a whole day because SA is unable to keep up. I had -m2 and each child canibalized up 20M of VM in just a few minutes. With 128M that makes difference. I'm now quite happily using razor with only very few false positives and a very high success rate in filtering spam. -- Francesco P. Lovergine
Re: Terminal - a good terminal?
Eduard Bloch wrote: * Jeff Teunissen [Thu, Oct 07 2004, 09:10:56AM]: [snip] Who said that the linux console is a good kind of terminal emulation? It's what's expected. By whom? By people who spend a lot of time at the console? We could do just about any other type, including graphics terminals, but TERM=linux is decent and simple. And primitive. And unuseable or not so comfortable when opening a shell on non-Linux system. Primitive? heh. And as for the rest, I haven't had trouble -- it's just an infocmp away. In any case, switching the emulation is trivial -- it's not like terminal emulation is complicated. meta-keys in UTF-8 mode? Only after manual configuration. Not true -- OpenStep has an extra modifier key. Command is bound to the Alt_L keysym by default in gnustep-gui. Alternate is by default bound to Alt_R. A different program lets you easily set which keysyms get bound to the various modifiers. Alternate always does meta. Command usually is grabbed for key equivalents in the menus. The option to set Command as meta overrides this. The option was created because on some configurations the right Alt key changed its keysym to ISO_Level3_Shift or some other such nonsense. I do not know which nonsence you mean but I do not have something special, just default Debian GNU/Linux environment and there it did not work. I had to set this switch. Yeah, it was implemented for broken environments. ( /me grins and hides from overfiend :) ) Did you try using the right Alt key? If you did try it and it didn't work, then X isn't reporting it as Alt_R, so -gui isn't telling the app that the Alternate modifier is set. Again, it's not an X program, it just happens to work when rigged with a GUI backend that uses X. And there's no such thing as a default X config. [snip] It does not print anything useful when executed with -h or --help. It just ignores these options, that is not a very userfriendly behaviour, IMHO. Because you're not supposed to execute it directly -- that's why it's not in the PATH. There are plenty of options when creating a new window, but they are not available from the commandline (and won't be, until I create the tool to exercise them). [snip] UTF-8 support? Lousy or none. One has to choose it manually (and it supports only few encoding anyways). It can support more by just adding a couple of lines to the popup button; GNUstep does all of its string handling in UTF-16 internally. Add more? It does not support UTF-8 well. It supports UTF-8 fine, as long as it can get the glyphs. [snip] Yeah. And a sane Unicode compatible terminal would try fallback to similar fonts. That is what Rxvt-Unicode or Gnome-Terminal do. Of course you can use the missing in this font excuse, but then you should made at least the font selector work. Currently, I see only four fonts there, and the selecting another one is either not stored, or has no effect. I only get a few bad-glyph markers when I cat the UTF-8-demo. Well, except for the Ethiopian sample, for which my 10646-1 terminal font has no glyphs. And it's not the terminal, it's the GNUstep GUI backend (gnustep-back) that's failing to do glyph substitution and coercion. Of course, there are problems with font substitution that make it a pain in the ass when you have a PostScript display model. e.g. since it's supposed to be WYSIWYG throughout, doing substitution in the app isn't always going to result in the same thing going onto the paper, so to DTRT means a lot more work. But hey, who cares about that? I WANT MY TEXT. It's not my fault that or whoever did the font setup for gnustep-back didn't set the default fixed-width font to something reasonable for Unicode...but then, the default character coding is Latin 1. The ART backend graphics target's glyph generator doesn't currently do glyph combining or font substitution, though the latter is apparently in progress. Then please don't call it UTF-8 capable before it really supports most of it. It does, and many other Unicode systems don't handle UTF-8 glyph-combining either. But it's being worked on. Choosing the Handle widht-chars option has broken the output completely. Works here, what backend and font were you using? What is a backend? I just assumed what other people said and started it with defaults. Well, I don't know what the default gnustep-gui backend is on Debian. [snip] Italic font support? No. For what? There isn't an italic display command. Though I suppose we could overload the blink bit to set italic, it hardly seems proper. Some applications (vim) support it with proper terminfo entry (not linux). Maybe it would help if you gave me the name of a sane terminfo entry that has an italic/oblique display command. -- | Jeff Teunissen -=- Pres., Dusk To Dawn Computing -=- deek @ d2dc.net | GPG: 1024D/9840105A 7102 808A 7733 C2F3 097B 161B 9222 DAB8 9840
Re: Updating scanners and filters in Debian stable (3.1)
On Wed, Sep 15, 2004 at 09:37:57AM +0200, Marc Haber wrote: On Mon, 13 Sep 2004 16:13:25 +0200, Javier Fernández-Sanguino Peña [EMAIL PROTECTED] wrote: On Mon, Sep 13, 2004 at 03:40:51PM +0200, Martin Schulze wrote: Have you thought about keeping these packages out of sarge or did you develop a solution so that users can get their databases updated outside of the stable Debian release? I can talk as Nessus co-maintainer. Stable uses have 'nessus-update-plugins' just for this. It still can be improved (for example, it will not check GPG signatures for you), however. It will also happily write to /usr which is IMO a no-no for user binaries. Marc, Where should it write to ? Would /var/lib or /usr/local be right ? Regards, Paddy
Re: possible mass bug filing: spamassassin 3
* Emilio Jesús Gallego Arias | For me sa work well: That doesn't help me. | Can you give some steps to reproduce such memory comsuption. Yeah, receive the mail/spam I get and you'll see it within twenty minutes. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: possible mass bug filing: spamassassin 3
* Duncan Findlay | A lot of that is shared, but not reported as such by top/ps due to | changes in how the kernel reports shared memory. The kernel only | reports memory that is used in shared libraries, I believe. More | memory is shared between spamd and it's children. My system ran out of swap, with 768MB memory and half a gig of swap. Problems went away when I downgraded to SA2. If SA uses more than 100 MB shared memory, I'd say something is seriously wrong anyhow. | Other than that I don't know what to say. It doesn't seem like it | should take up that much memory... | | FWIW, I can't really reproduce that. I can reproduce it within twenty minutes of starting SA3. I run SA smtp-time and I get enough mail that I'm not sure I'm going to start tracking down where the problem is. (Given that I don't know perl and SA well enough.) -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: Terminal - a good terminal?
Jeff Teunissen [EMAIL PROTECTED] wrote: Maybe it would help if you gave me the name of a sane terminfo entry that has an italic/oblique display command. He's not able to because the feature does not exist in terminfo. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net
Re: Terminal - a good terminal?
Jeff Teunissen [EMAIL PROTECTED] wrote: Primitive? heh. And as for the rest, I haven't had trouble -- it's just an infocmp away. In any case, switching the emulation is trivial -- it's not like terminal emulation is complicated. Judging by the variety of poor implementations, I'd say that's incorrect. Even linux emulation - how many implement its savable colors? -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net
Re: Updating scanners and filters in Debian stable (3.1)
On Wed, Oct 06, 2004 at 11:32:05PM +0200, Andreas Barth wrote: * Thomas Bushnell BSG ([EMAIL PROTECTED]) [041006 23:25]: Unfortunately, most of what I have seen has been an attempt to have a new place that involves no actual backporting and publicity work, rather than volunteering to take that load on. Actually, I'm considering very much to pick the task up (and have also already volatile.d.n ;), but there are some issues that needs to be considered before doing a public announcement. Andreas, Great! I see volatile.debian.net. But, It took me forever to find this email :) Three questions: What issues? Anything the list can help with? (excessively curious and eager mind wishes to know ;) Would it be good to indicate on the web-page where communication about this is going on (inspired by my hunt-the-email saga)? How are packages added to the list of candidates? On a related-but-unrelated note, I'm interested, for myself, in the possibility of automatically packaging upstream releases. I'm already under the impression that this is contrary to the debian philosophy of hand-maintained packaging, so I suppose this interest is purely personal. Can anyone offer me any pointers? Regards, Paddy
Re: Terminal - a good terminal?
Thomas Dickey [EMAIL PROTECTED] wrote: Jeff Teunissen [EMAIL PROTECTED] wrote: Maybe it would help if you gave me the name of a sane terminfo entry that has an italic/oblique display command. He's not able to because the feature does not exist in terminfo. hmm - amend that. italic is terminfo, and oblique is not. (yes, they're usually the same ;-) -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net
Re: Redirections and noclobber
Hi Nils, hi all (remember to take -devel out if applicable, I'm getting the mail through the bug address), Bill Allombert [EMAIL PROTECTED] wrote: On Thu, Oct 07, 2004 at 10:18:09AM +0200, Frank Küster wrote: But if I start apt-get upgrade or whatever from my interactive shell with noclobber set, all childs will inherit it. That's how the problem came up. How ? noclobber is not part of the environment so is not carried out by fork() and shells launched by dpkg should not be interative. bash-2.05a$ set -C bash-2.05a$ echo a bar bash-2.05a$ echo b bar bash: bar: cannot overwrite existing file bash-2.05a$ ./test.sh b bash-2.05a$ cat test.sh #! /bin/sh echo a foo echo b foo cat foo So I am really interested to know what happens here. Nils wrote in his bug report: , | The postinst script: | /var/lib/dpkg/info/tetex-base.postinst | fails if you set bash's noclobber (say in your .bashrc via set -o noclobber). | (yes, I set noclobber in root's .bashrc -- I'm careful) ` Therefore I assumed that the set -o options get inherited as the environment does. Which is wrong, according to Bill's test which I can reproduce here. This is also correct according to POSIX (http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_12) Nils, is it possible that your ~/.bashrc is read somehow by noninteractive shells? I am not very used to the details of bash invocation; according to the manpage it seems that non-interactive non-login shells only source $BASH_ENV; I am not sure about /etc/profile, however. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Updating scanners and filters in Debian stable (3.1)
Thomas, Jesus, I feel I owe you both and the list an apology for my last post here. It falls below the standard I would aspire to achieving in terms of courtesy, and that I'm sure you both deserve. Additionally, I have not only completely missed the point, but done no more than interupt in your conversation. Doubtless, I will now go on to add to the damage ;) On Thu, Oct 07, 2004 at 11:41:49PM +0100, paddy wrote: Thomas, On Thu, Oct 07, 2004 at 02:58:05PM -0700, Thomas Bushnell BSG wrote: paddy [EMAIL PROTECTED] writes: On Thu, Oct 07, 2004 at 02:22:18PM -0700, Thomas Bushnell BSG wrote: If you want something which is simply unrestricted, you have that now, no need for any changes to anything. I assume you mean use unstable? see below. No, you can simply use private repositories, or backports, or whatever else. Yeah, sorry. I realised this after I'd hit send. There need be no Debian-branding of it in any way. IANADD. As I said earlier, I'll doing the work either way. If I thought I was alone, I wouldn't bother anyone with it. As I re-read the thread Jesus, you do indeed seem to be advocating something that is hard to distinguish from backports but 'Debian-branded'. My earlier unease about lumping 'out-dated' together with 'needs-to-be-timely-to-function', is begining to crystalise. I don't yet see what is so special about the problem of an outdated mozilla in stable (for example), that it is _cannot_ best be addressed through security.d.o, testing/sid and backports. (my own pet concerns, are, of course, completely different ;) The idea of a backports but with a more structured/formal policy that enables it to become 'Debian-branded', which Thomas, you seem almost to be suggesting, is an interesting one: perhaps it might solve a host of problems. But it is way beyond me. I can only imagine others have already put far more into backports than I'm ever likely to. Indeed, perhaps I'm simply tilting at windmills and backports already has what I need. I _will_ go and look. If not, then perhaps volatile.d.n could really help to scratch that itch. Regards, Paddy
Re: Updating scanners and filters in Debian stable (3.1)
On Wed, Oct 06, 2004 at 11:32:05PM +0200, Andreas Barth wrote:
Actually, I'm considering very much to pick the task up (and have also
already volatile.d.n ;), but there are some issues that needs to be
considered before doing a public announcement.
Andi,
Another observation:
Three months is a long time in virus scanning.
Our use-case is a battery of virus-scanners over email before it is
delivered to windows workstations equipped with various windows
virus scanners. In the worst case the windows scanners have left
the workstation vulnerable for one week, perhaps two at the outside.
I realise we are not talking about virus definitions that are three
months out of date, but all the same.
I will see what I can do to help better characterise and quantify what
timeliness is for various software and use-cases and report back if you
like.
I doubt that all these software move at the same speed.
I wonder if it would make more sense to gear the process of promotion
from staging to release against yardsticks other than time.
(I already assume three months would be: about three months, but when
its ready)
What are the pros and cons for volatile-{stable,release,or-whatever-you-call-it}
as an all-at-once release model, rather than a rolling-when-its-ready
model more like security.d.o ?
Does anybody want to use a three month old clamav ?
(with up-to-date definitions of course)
Why?
Regards,
Paddy
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Updating scanners and filters in Debian stable (3.1)
* paddy ([EMAIL PROTECTED]) [041008 15:10]:
What are the pros and cons for
volatile-{stable,release,or-whatever-you-call-it}
as an all-at-once release model, rather than a rolling-when-its-ready
model more like security.d.o ?
well, not exactly an all at once, but having not just a random minor
update to pop up every day is IMHO a great feature for system
administrators - they're not forced into additional update rounds.
Does anybody want to use a three month old clamav ?
(with up-to-date definitions of course)
Why?
I do. Why: Because there is no reason to update it more often.
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Common set of debconf templates (was: Re: RFC: best practice creating database)
hi christian, On Fri, Oct 08, 2004 at 06:59:50AM +0200, Christian Perrier wrote: All such templates should probably go into a common set of debconf templates, provided by a very small package, which all these packages should depend upon, instead of constantly reinvent the wheeland make up, translators, do damn boring work. something i've been messing around with a bit in my free time is a dh_installdb add-on to debhelper. it's not in a presentable state yet, but could be made so with sufficient prodding. basically, debian/$package.databases contains a list of database servers that the package supports, and all the package maintainer has to do is put a dh_installdb in his/her debian/rules. one of the things i haven't been able to completely address yet is this debconf templating issue. to this point my tool has required the questions to already exist in the templates file, but in an ideal world this would not be a requisite. i like the idea of having the templates provided by a third-party package, though gracefully handling different usernames/passwords/hosts/etc on a per package basis would be a little tricky. the idea i had been running with up to this point was to have these templates pre-defined and pre-translated as part of debhelper, and patch debhelper to do $package.templates the same way it does $package.*inst (wrt #DEBHELPER#), though i'm not convinced that this is the right way. sean -- signature.asc Description: Digital signature
Re: RFC: best practice creating database
On Fri, Oct 08, 2004 at 03:45:26PM +1000, Andrew Pollock wrote: On Thu, Oct 07, 2004 at 05:19:07PM +0200, Uwe Steinmann wrote: On Thu, Oct 07, 2004 at 03:38:59PM +0200, Philipp Matthias Hahn wrote: Hello! What is consideres best practice when a package uses a SQL database (mysql, postgresql) and needs to create its own catalog and/or tables? [ ] Disable the package until someone has manually setup the database? [ ] Ask a lot of questions via debconf and try to setup in postconf? I'd go for the second option. [snip] Setting up a database is somewhat errorprune but still something achievable in a postinst script. Methinks we need something like wwwconfig-common, but for databases... wwwconfig-common does most of what needs to be done for setting up a database. What are you missing? Uwe -- MMK GmbH, Universitaetsstr. 11, 58097 Hagen [EMAIL PROTECTED] Tel: +2331 840446Fax: +2331 843920 signature.asc Description: Digital signature
Re: RFC: best practice creating database
On 07-Oct-04, 10:19 (CDT), Uwe Steinmann [EMAIL PROTECTED] wrote: On Thu, Oct 07, 2004 at 03:38:59PM +0200, Philipp Matthias Hahn wrote: Hello! What is consideres best practice when a package uses a SQL database (mysql, postgresql) and needs to create its own catalog and/or tables? [ ] Disable the package until someone has manually setup the database? [ ] Ask a lot of questions via debconf and try to setup in postconf? I'd go for the second option. But please make sure that the postinst doesn't actually contain the code, but instead calls an external script, so that when it fails (and it will), it's possible to run it externally by hand. Ditto upgrade scripts. Also, make sure the README.Debian has the correct instructions for performing these actions: script name, and any arguments that must be passed on the command line, or info that might be prompted for. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: possible mass bug filing: spamassassin 3
On Fri, Oct 08, 2004 at 12:24:18PM +0200, Tollef Fog Heen wrote: | Can you give some steps to reproduce such memory comsuption. Yeah, receive the mail/spam I get and you'll see it within twenty minutes. Unless you're offering to provide relevant samples of the messages in question, that response is quite worthless from a troubleshooting perspective.
Re: Updating scanners and filters in Debian stable (3.1)
Andi,
On Fri, Oct 08, 2004 at 03:15:29PM +0200, Andreas Barth wrote:
* paddy ([EMAIL PROTECTED]) [041008 15:10]:
What are the pros and cons for
volatile-{stable,release,or-whatever-you-call-it}
as an all-at-once release model, rather than a rolling-when-its-ready
model more like security.d.o ?
well, not exactly an all at once, but having not just a random minor
update to pop up every day is IMHO a great feature for system
administrators - they're not forced into additional update rounds.
On providing a mechanism to limit the rate at which updates present,
I agree. I would hope that could be acheived having a structure parallel
to upstream release structure.
If volatile-stable included as a criterion time-served three months
(pick a number, archive wide or perhaps per source package),
I believe it could prove a wise choice of mechanism: familiar,
cheap to implement, and a good proxy for some desirable qualities.
I don't understand 'forced into additional update rounds'.
Choice is good, information is good, freedom from choice can also be good.
But if I had to choose between these, then, yes, a good spot between the
spring and the sea.
Does anybody want to use a three month old clamav ?
(with up-to-date definitions of course)
Why?
I do. Why: Because there is no reason to update it more often.
My reason for the converse (for me that is) is simple:
clamav may (and does) catch something that other scanners do not.
up-to-date-ness can be critical in this case, and thus represents
a substantial portion of the whole value.
I certainly don't wish to pry, and I can't fault don't fix it if
it ain't broken. I'm explaining what I do with clamav, and thus,
I hope, my appetite for up-to-date-ness. So,
In what use-cases is a three-month clamav good, a two-year-old clamav
not, and newer not interesting? What does it do?
I hope that by asking and answering such questions, light could
usefully be shed on a volatile.d.n. endeavour.
Regards,
Paddy
Re: possible mass bug filing: spamassassin 3
On Fri, Oct 08, 2004 at 12:24:18PM +0200, Tollef Fog Heen wrote: * Emilio Jesús Gallego Arias | For me sa work well: That doesn't help me. | Can you give some steps to reproduce such memory comsuption. Yeah, receive the mail/spam I get and you'll see it within twenty minutes. Do you limit the size of the messages you sacn? -- Duncan Findlay signature.asc Description: Digital signature
Re: possible mass bug filing: spamassassin 3
also sprach Greg Norris [EMAIL PROTECTED] [2004.10.08.1601 +0200]: Unless you're offering to provide relevant samples of the messages in question, that response is quite worthless from a troubleshooting perspective. Yes, please forward your spam to debian-devel so that we can all feel it. Not. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: Updating scanners and filters in Debian stable (3.1)
Hi,
* paddy ([EMAIL PROTECTED]) [041008 16:05]:
On Fri, Oct 08, 2004 at 03:15:29PM +0200, Andreas Barth wrote:
* paddy ([EMAIL PROTECTED]) [041008 15:10]:
What are the pros and cons for
volatile-{stable,release,or-whatever-you-call-it}
as an all-at-once release model, rather than a rolling-when-its-ready
model more like security.d.o ?
well, not exactly an all at once, but having not just a random minor
update to pop up every day is IMHO a great feature for system
administrators - they're not forced into additional update rounds.
If volatile-stable included as a criterion time-served three months
(pick a number, archive wide or perhaps per source package),
I believe it could prove a wise choice of mechanism: familiar,
cheap to implement, and a good proxy for some desirable qualities.
Yes, that is exactly what I mean. Not too many updates to mechanismns,
except if really required. And of course, the daily update of e.g.
clamavs files, should be done by a cronjob from clamavs site, and not by
installing a new deb every day.
I don't understand 'forced into additional update rounds'.
A lot of admins (including me) use tools that tell them Hey, you forgot
to update your packages if they are not current. And, if the last
update fixed a security bug, this is actually needed.
In what use-cases is a three-month clamav good, a two-year-old clamav
not, and newer not interesting? What does it do?
Well, as I said above: If there is a good reason for an update, it
should be in. But - don't fix it if it is not broken, and who wants to
use the very newst development version could just use some backports,
e.g. from backports.org. volatile is IMHO more a it is more current
than stable, but otherwise, we change as less as possible.
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Bug#275494: ITP: backup-manager -- A really simple to use backup manager.
Package: wnpp Severity: wishlist * Package name: backup-manager Version : 0.2.1 Upstream Author : Alexis Sukrieh [EMAIL PROTECTED] * URL : http://www.sukria.net/index.php?p=410 * License : GPL Description : A really simple to use backup manager. The idea is to list all the important directories of the system. backup-manager will generate tarballs (or zipped files) of all the specified directories. Archives can be uploaded daily to a list of remote hosts. Cleaning is done with purging each too old archive according to a specified number of days. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.6-1-686 Locale: LANG=fr_FR, LC_CTYPE=fr_FR
Re: RFC: best practice creating database
On Thu, Oct 07, 2004 at 06:36:27PM -0400, sean finney wrote: - don't store the pw in debconf, or at least ask the admin first That's no problem. Debconf is, by default, configured correctly to not store passwords /anywhere/ -- at least not if you use a password type of template, which you should be doing anyway. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune signature.asc Description: Digital signature
Re: RFC: best practice creating database
On Thu, 2004-10-07 at 23:36, sean finney wrote: On Thu, Oct 07, 2004 at 03:38:59PM +0200, Philipp Matthias Hahn wrote: What is consideres best practice when a package uses a SQL database (mysql, postgresql) and needs to create its own catalog and/or tables? I am the postgresql maintainer. I am replying to this because I did not see the original post. this is a very good question, which has not been conclusively answered and is still the subject of debate. there have been a few threads about it, but i don't imagine anything solid will come from them while everyone's still focused on sarge. There are a lot of issues related to database access and security. What machine is the database on? You should not assume that it is on the local machine. (That has implications for dependencies too; if the database can be remote, you don't want your package to depend on postgresql, but only on libpq3 (or possibly postgresql-client).) What port are you to connect to? (The default is 5432, but there could be multiple PostgreSQL postmasters on different ports.) Which user is to access the database during the package installation? That user must be (or have been) defined as a database user. Is the database administrator the same person as the system administrator? If not, should the sysadmin create a new database user? (Obviously, he has the power to assume the necessary id to do this, at least on the local machine.) If a database is to be created, the user needs database creation privilege. Which users will use the database? If the database security is well implemented, they will have to be GRANTed suitable access to every object (preferably by adding them to a group and giving access to that group). Does the package provide a method of doing this? What is the access method? PostgreSQL's default authentication will reject anyone attempting to access under any name other than the Unix login id, which automatically excludes web-server based access. We do not want to have packages rewriting the database authentication setup, especially not when some recommend using trust authentication to get round access problems. It seems to me that we need some kind of policy for database-using packages to follow. Do others agree about that? [ ] Disable the package until someone has manually setup the database? [ ] Ask a lot of questions via debconf and try to setup in postconf? i'd suggest the latter if it's not too complicated. a few things to keep in mind though: - ask if they want to delete the database on purge - make a backup of the database during upgrades, Just In Case ...using the correct utility: pg_dump for PostgreSQL. - don't store the pw in debconf, or at least ask the admin first if you think that it would be too complicated/flaky, i'd add a debconf note (of _low_ priority!) and put something in README.Debian. -- Oliver Elphick olly@lfix.co.uk Isle of Wight http://www.lfix.co.uk/oliver GPG: 1024D/A54310EA 92C8 39E7 280E 3631 3F0E 1EC0 5664 7A2F A543 10EA Let no man say when he is tempted, I am tempted of God; for God cannot be tempted with evil, neither tempteth he any man; But every man is tempted, when he is drawn away of his own lust, and enticed. James 1:13,14
Re: possible mass bug filing: spamassassin 3
* Duncan Findlay | On Fri, Oct 08, 2004 at 12:24:18PM +0200, Tollef Fog Heen wrote: | * Emilio Jesús Gallego Arias | | | For me sa work well: | | That doesn't help me. | | | Can you give some steps to reproduce such memory comsuption. | | Yeah, receive the mail/spam I get and you'll see it within twenty | minutes. | | Do you limit the size of the messages you sacn? I can't see any such option in the shipped SA configuration, no, but I tend not to receive very large mail either. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: Updating scanners and filters in Debian stable (3.1)
PLAN FOR MAINTENANCE OF A VOLATILE ARCHIVE == There is a 'list of packages' for the archive. Packages going onto the list must satisfy the criteria: utility is very sensisitive to and derives from, in a very great part, it's timeliness - how up-to-date it is. AND is security software Please include [1] OR has arch-independent data which depend on the contents of the release itself. 1. http://lists.debian.org/debian-devel/2004/09/msg00951.html pgpnzOP3cWOAB.pgp Description: PGP signature
Re: Package name for GNOME panel applets
On Thursday 07 October 2004 11:09 pm, Seo Sanghyeon wrote: apt-watch The next version of apt-watch will be neither Gnome nor a panel applet, and I don't want to go through renaming the package twice. Daniel -- /--- Daniel Burrows [EMAIL PROTECTED] --\ |A: No. See http://www.netmeister.org/news/learn2quote.html | |Q: Should I include quotations after my reply? | \- A duck! -- http://www.python.org / pgpjSL3bILNFl.pgp Description: PGP signature
about volatile.d.o/n
Hi all, we had some discussion about volatile, and I'm more and more considering to pick this task up. I think some issues are quite obvious: - packages should only go in in cooperation with the maintainers; - volatile is not just another place for backports, but should only contain changes to stable programs that are necessary to keep them functional; - Good candidates are clamav (including spin-offs), spamassassin, chkrootkit; - It should allow any administrator to just use volatile, as they just use security.d.o, and they should be confident that nothing is broken by that; - for bugs, the normal debian bug tracking system should be used. Some things are not so obvious: - security support: There should be security support for volatile. However, security.d.o is probably not the right place for that, and adding another task to the security-team is IMHO also not the way to go. So, this needs to be placed on the burden of the volatile team. - releases of volatile: One could consider to seperate volatile into a release and a staging area. An advantage would be that system administrators would only need to update on some times. However, if we restrict volatile, only upload required changes and don't have more than 10 packages in it, we don't need that. - adding volatile packages to point releases: Though it may be seen as good idea to add volatile packages at the next point release, this is currently a no-go. I can see the good reasons for that, and I accept them. Two technical questions remain open for now, and needs to be solved independend of the policy questions above. - ftp-server: Should volatile be a normal part of the debian ftp-server, or be setup independently (like e.g. security.d.o is)? Normal part would of course be nicer for our users (and especially mirroring is free), but requires some more work initially. However, this decision is in the domain of the ftp-masters. - architectures/buildd support (partly connected with ftp-server): Which architectures should be supported? Perhaps starting with a smaller number is a good idea, and adding more if they can cope with the updates. I added http://volatile.debian.net/ to be a placeholder for the current discussions. Also, there is a archive present on http://volatile.debian.net/debian-volatile, so if maintainers want to start adding packages, they may contact me. That's all for now. Comments and suggestions are welcome. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Terminal - a good terminal?
#include hallo.h * Thomas Dickey [Fri, Oct 08 2004, 10:17:11AM]: Jeff Teunissen [EMAIL PROTECTED] wrote: Maybe it would help if you gave me the name of a sane terminfo entry that has an italic/oblique display command. He's not able to because the feature does not exist in terminfo. rxvt-unicode Eduard. -- Kleini Warum ist dann das Netscape auf Hyperion deutlich stabiler? Knopper Weil dort ne ältere Version der glibc drauf ist, nicht etwa, weil SuXE besser ist. ;)
Re: Terminal - a good terminal?
On Fri, Oct 08, 2004 at 05:43:16PM +0200, Eduard Bloch wrote: #include hallo.h * Thomas Dickey [Fri, Oct 08 2004, 10:17:11AM]: Jeff Teunissen [EMAIL PROTECTED] wrote: Maybe it would help if you gave me the name of a sane terminfo entry that has an italic/oblique display command. He's not able to because the feature does not exist in terminfo. rxvt-unicode yes (and no: its terminfo contains different errors - sometime when there's a _stable_ version of rxvt-unicode I'll take the time to test it). but for italic (my fingers were faster than my brain). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpLrgJvF8xxE.pgp Description: PGP signature
Re: Package name for GNOME panel applets
On 08-Oct-04, 01:39 (CDT), Ross Burton [EMAIL PROTECTED] wrote: On Fri, 2004-10-08 at 12:09 +0900, Seo Sanghyeon wrote: This was discussed before: http://lists.debian.org/debian-gtk-gnome/2003/07/msg00176.html Mailing to d-g-g, CCing d-d. My comments below. Which is, not consistent. I don't like netspeed package name, which is too generic, while its upstream name is netspeed_applet. See http://mfcn.ilo.de/netspeed_applet/ . Personally, I prefer gnome-foo-applet. In the cases where the applet name contains gnome or applet it can be re-arranged. g-f-a is fine for new stuff, but please *don't* rename existing packages, it just causes upgrade problems, and/or more dummy packages. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: possible mass bug filing: spamassassin 3
On Fri, Oct 08, 2004 at 04:10:14PM +0200, martin f krafft wrote: also sprach Greg Norris [EMAIL PROTECTED] [2004.10.08.1601 +0200]: Unless you're offering to provide relevant samples of the messages in question, that response is quite worthless from a troubleshooting perspective. Yes, please forward your spam to debian-devel so that we can all feel it. Not. Exactly where did I say please send it to the list?
Re: Updating scanners and filters in Debian stable (3.1)
Jesus Climent [EMAIL PROTECTED] writes: Except that those private repositories and backports have no policy and no maintenance. My proposal is to create a policy for a repository with maintenance, security updates which introduces new packages and provides new functionality on outdated or useless packages from stable, and is built against stable. So all of that could be done on backports but the very first. WHY do we want security updates which ... provide[] new functionality? What about that is a security update? Suppose a nifty new emacs feature is developed; why should that new functionality be excluded from this repository you are speaking of, merely because it isn't a security update? In other words, it sounds like the whole virus-scanner bit is a red herring, and what you actually want is just a repository that doesn't have the stability restrictions that Debian normally has. Maybe that's a good idea, but it needs to be argued for by something other than oooh, virus scanners!
Re: Updating scanners and filters in Debian stable (3.1)
Will Lowe [EMAIL PROTECTED] writes: My argument is just that even if you backport the important features of a new release into an old codebase, it's hard to make any valuable claims about the resulting product if the backport changes more than a few lines of code. This is true if you don't know what you just did. If you know what you did, you may well be able to make a claim like no new command line features are added.
Re: Updating scanners and filters in Debian stable (3.1)
Thomas Bushnell BSG [EMAIL PROTECTED] - Fri, Oct 08, 2004: My proposal is to create a policy for a repository with maintenance, security updates which introduces new packages and provides new functionality on outdated or useless packages from stable, and is built against stable. Suppose a nifty new emacs feature is developed; why should that new functionality be excluded from this repository you are speaking of, merely because it isn't a security update? Because the nifty new emacs feature doesn't render the emacs from stable useless. But I think your talking in loops. Regards, [ Please don't Cc me, I read this list. ] -- Loïc Minier [EMAIL PROTECTED]
Re: about volatile.d.o/n
Andreas Barth [EMAIL PROTECTED] writes: - volatile is not just another place for backports, but should only contain changes to stable programs that are necessary to keep them functional; I think your proposal looks good, but I would like to see this particular item fleshed out more fully. In particular, what kinds of changes are being considered here? In other words, would it count as necessary to say new upstream major release provides a new feature which keeps the virus scanner useful, and also changes a bajillion unrelated things? In my book, the new virus definitions would be necessary, but not the bajillion unrelated things, and I would like to see a rule that you could not just put in the new upstream major release merely to get the new virus definitions. That is, some kind of minimal change to preserve utility rule, which might require the volatile-managers or whoever to be Real Programmers and not just compilers. Thomas
Bug#275515: ITP: matanza -- Multiplayer space ascii game
Package: wnpp Severity: wishlist * Package name: matanza Version : 0.13.1 Upstream Author : Alejandro Forero Cuervo [EMAIL PROTECTED] * URL : http://bachue.com/matanza/matanza-0.13.tar.gz * License : GPL Description : Multiplayer space ascii game Matanza is a multiplayer game. In it, every player controls a ship cruising in space, aiming to destroy the other players (and, eventually, ships controled by the computer). -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (100, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.8.1 Locale: LANG=C, LC_CTYPE=C
Re: Updating scanners and filters in Debian stable (3.1)
* Thomas Bushnell BSG ([EMAIL PROTECTED]) [041008 18:20]: In other words, it sounds like the whole virus-scanner bit is a red herring, and what you actually want is just a repository that doesn't have the stability restrictions that Debian normally has. Maybe that's a good idea, but it needs to be argued for by something other than oooh, virus scanners! This repository exists, and it's called backports.org. For the volatile archive, there _is_ one difference: The volatile archive is only for the packages that have some regression due to the fact that some time has passed - and e.g. virus scanners typically have this behaviour. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Updating scanners and filters in Debian stable (3.1)
Loc Minier [EMAIL PROTECTED] writes: Thomas Bushnell BSG [EMAIL PROTECTED] - Fri, Oct 08, 2004: My proposal is to create a policy for a repository with maintenance, security updates which introduces new packages and provides new functionality on outdated or useless packages from stable, and is built against stable. Suppose a nifty new emacs feature is developed; why should that new functionality be excluded from this repository you are speaking of, merely because it isn't a security update? Because the nifty new emacs feature doesn't render the emacs from stable useless. But I think your talking in loops. But the original text sounded like if I call part of this a security update, then I can make arbitrary other changes. In other words, only the changes necessary to keep the program useful for its purpose should get in (whether security updates or not)--that I can agree with. But doing other new functionality, which is not actually necessary, this I cannot agree with. And this means that the maintainer/whoever must do the potentially hard work of backporting particular changes and not others from upstream releases; merely including a new upstream release is not good enough. Thomas
Re: about volatile.d.o/n
* Thomas Bushnell BSG ([EMAIL PROTECTED]) [041008 18:25]: Andreas Barth [EMAIL PROTECTED] writes: - volatile is not just another place for backports, but should only contain changes to stable programs that are necessary to keep them functional; I think your proposal looks good, but I would like to see this particular item fleshed out more fully. In particular, what kinds of changes are being considered here? In other words, would it count as necessary to say new upstream major release provides a new feature which keeps the virus scanner useful, and also changes a bajillion unrelated things? In my book, the new virus definitions would be necessary, but not the bajillion unrelated things, and I would like to see a rule that you could not just put in the new upstream major release merely to get the new virus definitions. Agreed. So, this means: Backport the necessary changes. Sometimes, it's just not enough to only update the virus scanner definitions, because new functionality is needed to scan the files (just consider that a very new archive format gets so popular that it needs to be supported, just like zip now). And, if there are changes that should be available on stable, but not be the default (like e.g. the current spamassassin3), than they might get in as new package, not disturbing the users of the old one, but giving more choices. (Of course, even then, the package needs to be a bit more mature than the curent spamassassin3, but that's a different thing. ;) That is, some kind of minimal change to preserve utility rule, which might require the volatile-managers or whoever to be Real Programmers and not just compilers. Of course it requires them to be Real Programmers. The job is _not_ mechanically compiling something on stable. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: about volatile.d.o/n
Andreas Barth [EMAIL PROTECTED] writes: Agreed. So, this means: Backport the necessary changes. Sometimes, it's just not enough to only update the virus scanner definitions, because new functionality is needed to scan the files (just consider that a very new archive format gets so popular that it needs to be supported, just like zip now). Certainly; that makes sense. Good, I'm comfortable with this if it can get written in to whatever official policy document in the right way. Thomas
Re: Updating scanners and filters in Debian stable (3.1)
On Fri, Oct 08, 2004 at 09:17:44AM -0700, Thomas Bushnell BSG wrote: Suppose a nifty new emacs feature is developed; why should that new functionality be excluded from this repository you are speaking of, merely because it isn't a security update? Because, even if they are not security updates (*) the new functionality adds a value to an obsolete package which is better not to have anymore in the repository, unlike the new emacs functionality, which does provide an update to a perfectly working package. In other words, it sounds like the whole virus-scanner bit is a red herring, and what you actually want is just a repository that doesn't have the stability restrictions that Debian normally has. Maybe that's a good idea, but it needs to be argued for by something other than oooh, virus scanners! I have been trying to put my point that way... (*) The idea is a repository which does not have the restrictions that stable has, with a policy that restricts the inclusion of random packages but allows packages to be included based on some critera, and has security updates applied to them (is a package X has a security bug, a new package would be uploaded with a security fix). [ Again, your MUA is broken, since you have sent me a copy of the mail sent to a list which i am subscribed to, and i have told you not to alread FOUR times ] -- Jesus Climent info:www.pumuki.org Unix SysAdm|Linux User #66350|Debian Developer|2.4.27|Helsinki Finland GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69 And then he ran into my knife... he ran into my knife ten times. --June (Chicago)
Re: ITP: cddb.bundle -- CDDB Bundle for GNUstep
* Jeff Teunissen [EMAIL PROTECTED] [041008 10:11]: (b) what can be regarded as most useful for our users (I, at lest, think it is, and some other people will as well, I hope). I don't really see how it's useful -- it doesn't matter what libs are used by an app. In my experience many users (including me) prefer to use applications, which use libraries, which the allready have installed. I use xfce4 and have therefore gtk installed. I try to aboid KDE and qt applications, since I don't like to clutter my notebook harddisk even more. Having a hint if a package contains a KDE, GNOME, gnustep, simple X or textmode app would be a benefit for those users, but it wouldn't hurt the other users who don't care about that. Yours sincerely, Alexander signature.asc Description: Digital signature
Re: possible mass bug filing: spamassassin 3
Tollef Fog Heen [EMAIL PROTECTED] writes: * Duncan Findlay | On Fri, Oct 08, 2004 at 12:24:18PM +0200, Tollef Fog Heen wrote: | * Emilio Jess Gallego Arias | | | For me sa work well: | | That doesn't help me. | | | Can you give some steps to reproduce such memory comsuption. | | Yeah, receive the mail/spam I get and you'll see it within twenty | minutes. | | Do you limit the size of the messages you sacn? I can't see any such option in the shipped SA configuration, no, but I tend not to receive very large mail either. spamc -s, if you use spamc. I use Exim4 with the Exiscan ACL patch, and have an exim rule that accepts mail 80k before the scans for spam. Rotty -- Andreas Rottmann | [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://yi.org/rotty | GnuPG Key: http://yi.org/rotty/gpg.asc Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62 To iterate is human; to recurse, divine.
Re: about volatile.d.o/n
Scripsit Andreas Barth [EMAIL PROTECTED] Some things are not so obvious: Should volatile include updates of packages such as debian-keyring? debian-policy and developers-reference? -- Henning Makholm Al lykken er i ét ord: Overvægtig!
Re: about volatile.d.o/n
This one time, at band camp, Henning Makholm said: Scripsit Andreas Barth [EMAIL PROTECTED] Some things are not so obvious: Should volatile include updates of packages such as debian-keyring? debian-policy and developers-reference? I could see (possibly) debian-keyring, but policy and the reference should be essentially frozen with the release - if policy X is in effect at release time, all packages that are targeted at that release must use policy X, unless I'm mistaken. The reference is, I suppose, less frozen, but updates that address things like new packaging procedures that are not present in stable would be problematic. Also, since these are all arch: all packages, it's not like they're a big deal to just grab if you need a newer copy for some reason. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgpOj2QZ2byW4.pgp Description: PGP signature
Re: about volatile.d.o/n
On Fri, Oct 08, 2004 at 06:31:56PM +0200, Andreas Barth wrote: Agreed. So, this means: Backport the necessary changes. Sometimes, it's just not enough to only update the virus scanner definitions, because new functionality is needed to scan the files (just consider that a very new archive format gets so popular that it needs to be supported, just like zip now). When spamassassin is upgraded, it's more than just the rules. Often the method of parsing the message is changed -- leading to better results, or support for different tests is added, etc. It would be very difficult to only backport the appropriate changes, and the result would be less stable than the version from which backporting was taking place. On the other hand, each new version makes minor changes to functionality. (Ignore 3.0.0 right now, it's got different issues all together.) To require backported changes would simply be a waste of effort and would defeat the purpose to a certain extent. And, if there are changes that should be available on stable, but not be the default (like e.g. the current spamassassin3), than they might get in as new package, not disturbing the users of the old one, but giving more choices. (Of course, even then, the package needs to be a bit more mature than the curent spamassassin3, but that's a different thing. ;) That is, some kind of minimal change to preserve utility rule, which might require the volatile-managers or whoever to be Real Programmers and not just compilers. Hmm.. -- Duncan Findlay signature.asc Description: Digital signature
Re: Updating scanners and filters in Debian stable (3.1)
On Fri, Oct 08, 2004 at 09:25:33AM -0700, Thomas Bushnell BSG wrote: Loïc Minier [EMAIL PROTECTED] writes: Thomas Bushnell BSG [EMAIL PROTECTED] - Fri, Oct 08, 2004: My proposal is to create a policy for a repository with maintenance, security updates which introduces new packages and provides new functionality on outdated or useless packages from stable, and is built against stable. Suppose a nifty new emacs feature is developed; why should that new functionality be excluded from this repository you are speaking of, merely because it isn't a security update? Because the nifty new emacs feature doesn't render the emacs from stable useless. But I think your talking in loops. But the original text sounded like if I call part of this a security update, then I can make arbitrary other changes. Indeed, spamassassin is on the v.d.n. list, but is it a security program at all ? (Funnily enough I overlooked that until now, intended it included in my suggestion 'is security software', but I don't think it is.) Whereas MailScanner would seem to me an obvious candidate. In other words, only the changes necessary to keep the program useful for its purpose should get in (whether security updates or not)--that I can agree with. But doing other new functionality, which is not actually necessary, this I cannot agree with. We think I agree here, almost. This seems the natural endpoint, and starting the journey well without finishing well would be bad. But, I can see the case, as I describe before, where achieving the function of a package places great pressure on the time to package, so much so that if an interim, first cut package can achieve this most effectively (ie: quickest) by shipping upstream 'important fixes/features' mixed with 'other new functionality, which is not actually necessary' then that can be a win too. But I could agree: only with the proper follow-up. And this means that the maintainer/whoever must do the potentially hard work of backporting particular changes and not others from upstream releases; merely including a new upstream release is not good enough. Getting results is more important than any dogma about how it should be done, and I suspect that repeated warnings against overlooking the importance of hard work are very good at getting results. Regards, Paddy -- Perl 6 will give you the big knob. -- Larry Wall
Re: about volatile.d.o/n
Hi Andreas, On Friday, 08 Oct 2004, you wrote: That's all for now. Comments and suggestions are welcome. i would like to see some policy, what, when and under which circumstances gets included to volatile.d.n. Is for example a package whois also a candidate for volatile? Regestries change from time to time; i just consider .org changed within the last 2,5 years... Greetings Martin -- Martin Zobel-HelasPGP-Key: 0xF7AC3AF0 signature.asc Description: Digital signature
Re: about volatile.d.o/n
also sprach Martin Zobel-Helas [EMAIL PROTECTED] [2004.10.08.2019 +0200]: Is for example a package whois also a candidate for volatile? Regestries change from time to time; i just consider .org changed within the last 2,5 years... I would say that a new version of whois could be included in volatile if it becomes useless. I don't think anything should be in volatile from the start. And I certainly don't think it should be volatile.debian.*net*. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: about volatile.d.o/n
* Henning Makholm ([EMAIL PROTECTED]) [041008 19:50]: Scripsit Andreas Barth [EMAIL PROTECTED] Some things are not so obvious: Should volatile include updates of packages such as debian-keyring? debian-policy and developers-reference? Pros: Well, these updates don't break any thing. Cons: There is no need to treat them special, or do security updates. Furthermore, it's easy to get them from backports.org. Perhaps, adding some information about how easy it's to get them from there would however be a good idea. (And, of course, if someone does a developers backport collection, including keyring, developers-reference, dpatch, debhelper etc, this might also be a good collection - but this has than a different target group than volatile.) Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: about volatile.d.o/n
Hi Martin, On Friday, 08 Oct 2004, you wrote: also sprach Martin Zobel-Helas [EMAIL PROTECTED] [2004.10.08.2019 +0200]: Is for example a package whois also a candidate for volatile? Regestries change from time to time; i just consider .org changed within the last 2,5 years... I would say that a new version of whois could be included in volatile if it becomes useless. I don't think anything should be in volatile from the start. whois was just an example. i agree with you to not include all packages from the begining in volatile. But we need to clarify under which conditions such a package gets added. And I certainly don't think it should be volatile.debian.*net*. agreed. Martin -- Martin Zobel-HelasPGP-Key: 0xF7AC3AF0 signature.asc Description: Digital signature
Re: about volatile.d.o/n
* Duncan Findlay ([EMAIL PROTECTED]) [041008 20:10]: On Fri, Oct 08, 2004 at 06:31:56PM +0200, Andreas Barth wrote: Agreed. So, this means: Backport the necessary changes. Sometimes, it's just not enough to only update the virus scanner definitions, because new functionality is needed to scan the files (just consider that a very new archive format gets so popular that it needs to be supported, just like zip now). When spamassassin is upgraded, it's more than just the rules. Often the method of parsing the message is changed -- leading to better results, or support for different tests is added, etc. It would be very difficult to only backport the appropriate changes, and the result would be less stable than the version from which backporting was taking place. On the other hand, each new version makes minor changes to functionality. Well, I think, it's in the end a case-by-case decision whether it's better to take more or less a current package, und perhaps weed out some definitly unrelated changes, or to take the old package and backport some changes. Of course, in the end, the goal needs to be to make the package as useable as possible - and of course, above all, do no harm, and don't break things. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: about volatile.d.o/n
* martin f krafft ([EMAIL PROTECTED]) [041008 20:30]: And I certainly don't think it should be volatile.debian.*net*. I'm open to changing this; however, for the start, it's easier with debian.net - same as planet that also came to life as planet.debian.net. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: about volatile.d.o/n
On Oct 08, martin f krafft [EMAIL PROTECTED] wrote: I would say that a new version of whois could be included in volatile if it becomes useless. I don't think anything should be in Is looking up .org domains in the wrong whois server enough to be considered useless? What about .pw domains? What about IP addresses in 24.192.0.0/14? -- ciao, | Marco | [8429 imdW2er9vJsQ.] signature.asc Description: Digital signature
Re: about volatile.d.o/n
also sprach Marco d'Itri [EMAIL PROTECTED] [2004.10.08.2029 +0200]: Is looking up .org domains in the wrong whois server enough to be considered useless? I found it rather useless in woody when the .org registrar changed. What about .pw domains? What's that? :) -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: about volatile.d.o/n
Hi, * Martin Zobel-Helas ([EMAIL PROTECTED]) [041008 20:25]: Is for example a package whois also a candidate for volatile? Regestries change from time to time; i just consider .org changed within the last 2,5 years... Well, I would start small (and this means to exclude whois), and revisit policy after some time to see what we should add or remove to it. And, furthermore, why not do the next release of whois in a way that it's possible to dynamically only update the zones (quite similar to the virus scanners definitions), perhaps downloading from some debian site once a month? Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: about volatile.d.o/n
* martin f krafft ([EMAIL PROTECTED]) [041008 20:50]: also sprach Marco d'Itri [EMAIL PROTECTED] [2004.10.08.2029 +0200]: Is looking up .org domains in the wrong whois server enough to be considered useless? I found it rather useless in woody when the .org registrar changed. There are more packages that I consider rather useless than that should be included in volatile - the criterion should be what almost everybody considers useless. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: about volatile.d.o/n
also sprach Andreas Barth [EMAIL PROTECTED] [2004.10.08.2051 +0200]: Well, I would start small (and this means to exclude whois), and revisit policy after some time to see what we should add or remove to it. And, furthermore, why not do the next release of whois in a way that it's possible to dynamically only update the zones (quite similar to the virus scanners definitions), perhaps downloading from some debian site once a month? There is some network tool in the archive that does something similar. The name evades me right now... it asks with debconf how often to download, kinda like a news client. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: about volatile.d.o/n
On Friday 08 October 2004 22:03, martin f krafft wrote: also sprach Andreas Barth [EMAIL PROTECTED] [2004.10.08.2051 +0200]: Well, I would start small (and this means to exclude whois), and revisit policy after some time to see what we should add or remove to it. And, furthermore, why not do the next release of whois in a way that it's possible to dynamically only update the zones (quite similar to the virus scanners definitions), perhaps downloading from some debian site once a month? There is some network tool in the archive that does something similar. The name evades me right now... it asks with debconf how often to download, kinda like a news client. [pointer] that's slrn updating the group descriptions. -- pub 4096R/0E4BD0AB 2003-03-18 keyserver.bu.edu ; pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB
Re: about volatile.d.o/n
I'll add a few my consideration already discussed in IRC with Andi and others. Feel free to fill the gaps :) On Fri, Oct 08, 2004 at 05:51:48PM +0200, Andreas Barth wrote: Hi all, we had some discussion about volatile, and I'm more and more considering to pick this task up. I think some issues are quite obvious: - packages should only go in in cooperation with the maintainers; - volatile is not just another place for backports, but should only contain changes to stable programs that are necessary to keep them functional; So no new styles of packaging: no dpatch introduction from scratch, for instance. - Good candidates are clamav (including spin-offs), spamassassin, chkrootkit; I'd add IDS like snort. - It should allow any administrator to just use volatile, as they just use security.d.o, and they should be confident that nothing is broken by that; In some context volatile would be not useful, so separating the two things is definitively The Good Thing To Do. - for bugs, the normal debian bug tracking system should be used. ... adding a volatile tag probably as for experimental? But if nothing would be broken by volatile pkgs, probably BTS is superfluous ;-) Some things are not so obvious: - security support: There should be security support for volatile. However, security.d.o is probably not the right place for that, and adding another task to the security-team is IMHO also not the way to go. So, this needs to be placed on the burden of the volatile team. Unfortunately I think so too. - releases of volatile: One could consider to seperate volatile into a release and a staging area. An advantage would be that system administrators would only need to update on some times. However, if we restrict volatile, only upload required changes and don't have more than 10 packages in it, we don't need that. - adding volatile packages to point releases: Though it may be seen as good idea to add volatile packages at the next point release, this is currently a no-go. I can see the good reasons for that, and I accept them. Indeed, I think we could have a few time post sarge release to buildup the thing. -- Francesco P. Lovergine
Re: about volatile.d.o/n
Hi, * Francesco Paolo Lovergine ([EMAIL PROTECTED]) [041008 21:15]: On Fri, Oct 08, 2004 at 05:51:48PM +0200, Andreas Barth wrote: - for bugs, the normal debian bug tracking system should be used. ... adding a volatile tag probably as for experimental? But if nothing would be broken by volatile pkgs, probably BTS is superfluous ;-) After sarge, the BTS is able to track versions. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: about volatile.d.o/n
Henning Makholm wrote: Scripsit Andreas Barth [EMAIL PROTECTED] Some things are not so obvious: Should volatile include updates of packages such as debian-keyring? debian-keyring? Absolutely. Out-of-date versions of this are tediously useless. debian-policy and developers-reference? Probably not. Out-of-date versions of Policy are still useful for stable releases (reflecting the version of policy in stable). Also the up-to-date versions of these are easily used in their web form (unlike debian-keyring). -- This space intentionally left blank.
Re: Please -- more DFSG-free font packages, if you can maintain them well
Branden Robinson wrote: On Fri, Sep 17, 2004 at 02:44:49PM -0400, Jim Gettys wrote: The issue with fonts is lots of people like to *design* fonts, and few want to do the very laborious job of hinting the glyphs. Acknowledged. FWIW, I'm told that the manual labor involved in doing the hinting of a glyph is approximately $10 US; there are people willing to be paid to do this task. I'm told it is mind-numbingly boring by those who do it for a living. I'm not yet convinced on this score. There's plenty of tedious, mind-numbingly boring work that gets done in the FLOSS community. Our best and brightest (and, occasionally, those who have simply managed to pass themselves off as such) make the headlines, but in my experience there's a fair amount of tedium in FLOSS development taken as a whole. Where is my intellectual edification in fixing spelling errors in my packages, or retitling dozens of bug reports from the tiresome and useless teh X server don't work[sic] subjects that they are so frequently saddled with? Just to chime in, I have spent a fair amount of time cleaning up Makefiles and autoconf scripts. Most of this consists of removing dead and obsolete code, simplifying logic, and adding comments. Most people consider this tedious and mind-numbingly boring; nevertheless it's quite popular and everyone is very appreciative. And I rather like doing it, personally. If there were a font-hinting tool, I'd probably do occasional hinting. Sometimes it's actually rather fun to do tedious tweaking work. -- This space intentionally left blank.
Re: about volatile.d.o/n
On Friday 08 October 2004 22:10, Francesco Paolo Lovergine wrote: --cut-- - Good candidates are clamav (including spin-offs), spamassassin, chkrootkit; I'd add IDS like snort. I'd add packages like ca-certificates. Perhaps it would be usefull to group them in some manner... -- pub 4096R/0E4BD0AB 2003-03-18 keyserver.bu.edu ; pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB
Re: about volatile.d.o/n
On Fri, 08 Oct 2004, Nathanael Nerode wrote: Henning Makholm wrote: Scripsit Andreas Barth [EMAIL PROTECTED] Some things are not so obvious: Should volatile include updates of packages such as debian-keyring? debian-keyring? Absolutely. Out-of-date versions of this are tediously useless. However, there are problems with updating the debian-keyring, and deleted signatures and the ilk will keep files from being verifiable if someone wants to check signatures on them. [I haven't made up my mind if this is a good thing or not... but...] Note as well, that you can trivially get the updated debian keyring by pointing gpg at keyring.debian.org. Don Armstrong -- For a moment, nothing happened. Then, after a second or so, nothing continued to happen. -- Douglas Adams http://www.donarmstrong.com http://rzlab.ucr.edu signature.asc Description: Digital signature
Re: about volatile.d.o/n
On Friday 08 October 2004 11:51 am, Andreas Barth wrote: - volatile is not just another place for backports, but should only contain changes to stable programs that are necessary to keep them functional; I generally have to resort to backports or unstable when installing Debian on recent hardware, because we don't update hardware drivers in stable. Would the kernel and X be candidates for volatile? Daniel -- /--- Daniel Burrows [EMAIL PROTECTED] --\ | Of course you can't see the guards. They DON'T EXIST! | | Oh my god, we're surrounded! Run away, run away! | | -- Fluble| \ The Turtle Moves! -- http://www.lspace.org ---/ pgpO6Btx1gOpR.pgp Description: PGP signature
Re: Common set of debconf templates (was: Re: RFC: best practice creating database)
On Fri, 8 Oct 2004 06:59:50 +0200 Christian Perrier [EMAIL PROTECTED] wrote: if you think that it would be too complicated/flaky, i'd add a debconf note (of _low_ priority!) and put something in README.Debian. While we are at it : Could *please* maintainers of packages interacting with RDBMS establish a set of *common* debconf templates for prompting users ? While translating the debconf templates for packages, we have found dozens of similar questions such as: -Database host (wrong Englishthis should probably be Database *server* or something similar) -Database user -Password for this user -Database administrator username -Database administrator password -Database name -Should the database be purge on package purge? This last question should be asked at purge time and _not_ at installation time. Bye Racke -- Debian maintainer of Courier, Pure-FTPd, Interchange, Sympa LinuXia Systems = http://www.linuxia.de/ Expert Interchange Consulting and System Administration
Re: RFC: best practice creating database
On Fri, 8 Oct 2004 15:26:41 +0200 [EMAIL PROTECTED] (Uwe Steinmann) wrote: On Fri, Oct 08, 2004 at 03:45:26PM +1000, Andrew Pollock wrote: On Thu, Oct 07, 2004 at 05:19:07PM +0200, Uwe Steinmann wrote: On Thu, Oct 07, 2004 at 03:38:59PM +0200, Philipp Matthias Hahn wrote: Hello! What is consideres best practice when a package uses a SQL database (mysql, postgresql) and needs to create its own catalog and/or tables? [ ] Disable the package until someone has manually setup the database? [ ] Ask a lot of questions via debconf and try to setup in postconf? I'd go for the second option. [snip] Setting up a database is somewhat errorprune but still something achievable in a postinst script. Methinks we need something like wwwconfig-common, but for databases... wwwconfig-common does most of what needs to be done for setting up a database. What are you missing? First of all documentation. Bye Racke -- Debian maintainer of Courier, Pure-FTPd, Interchange, Sympa LinuXia Systems = http://www.linuxia.de/ Expert Interchange Consulting and System Administration
Re: about volatile.d.o/n
In article [EMAIL PROTECTED] [EMAIL PROTECTED] writes: --gKMricLos+KVdGMg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable also sprach Andreas Barth [EMAIL PROTECTED] [2004.10.08.2051 +0200]: Well, I would start small (and this means to exclude whois), and revisit policy after some time to see what we should add or remove to it. And, furthermore, why not do the next release of whois in a way that it's possible to dynamically only update the zones (quite similar to the virus scanners definitions), perhaps downloading from some debian site once a month? There is some network tool in the archive that does something similar. The name evades me right now... it asks with debconf how often to download, kinda like a news client. hinfo optionally periodicly updates a couple of files using wget. Never, once, weekly and monthy are the current options. (Daily would be easy to add, but I considered it inappropriate for how often the hinfo data changes.) -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature.
Re: about volatile.d.o/n
On Fri, Oct 08, 2004 at 03:51:29PM -0400, Daniel Burrows wrote: On Friday 08 October 2004 11:51 am, Andreas Barth wrote: - volatile is not just another place for backports, but should only contain changes to stable programs that are necessary to keep them functional; I generally have to resort to backports or unstable when installing Debian on recent hardware, because we don't update hardware drivers in stable. Would the kernel and X be candidates for volatile? Uhm, if I'm remembering right at potato time we had kernel upgrades, at least 2.2.17 - 2.2.19. Unfortunately new kernels imply new big security concerns in many cases. Anyway, kernel and X are not typical targets for volatile: we are not proposing new stable releases, but only very localized changes for a few programs which are inerently subject to fast obsolescence (i.e. short-life applications). For those kind of things backports.org is the right answer. -- Francesco P. Lovergine
Re: about volatile.d.o/n
Andi, On Fri, Oct 08, 2004 at 05:51:48PM +0200, Andreas Barth wrote: I think some issues are quite obvious: - packages should only go in in cooperation with the maintainers; - volatile is not just another place for backports, but should only contain changes to stable programs that are necessary to keep them functional; - Good candidates are clamav (including spin-offs), spamassassin, chkrootkit; - It should allow any administrator to just use volatile, as they just use security.d.o, and they should be confident that nothing is broken by that; - for bugs, the normal debian bug tracking system should be used. It suddenly strikes me that the link between, say, clamav and spamassassin is co-evolving enemies I think an explicit mention of the above as an ecological viewpoint is worthwhile if only in this mail. (but only because I'm the only one to whom it wasn't previously patently obvious :) The balance of the risk of introducing bugs into such software has to be seen in the context of a potentially large monoculture. I would like to think that such a risk could be mitigated sufficiently to enable the 'as-fast-as-possible' emphasis I have advocated, but I see that good intentions alone cannot achieve that : substantial quantities of 'hard work' may eventually get me there. Incidentally, Great work ! Regards, Paddy -- Perl 6 will give you the big knob. -- Larry Wall
Re: about volatile.d.o/n
This one time, at band camp, paddy said: Andi, On Fri, Oct 08, 2004 at 05:51:48PM +0200, Andreas Barth wrote: I think some issues are quite obvious: - packages should only go in in cooperation with the maintainers; - volatile is not just another place for backports, but should only contain changes to stable programs that are necessary to keep them functional; - Good candidates are clamav (including spin-offs), spamassassin, chkrootkit; - It should allow any administrator to just use volatile, as they just use security.d.o, and they should be confident that nothing is broken by that; - for bugs, the normal debian bug tracking system should be used. It suddenly strikes me that the link between, say, clamav and spamassassin is co-evolving enemies I think an explicit mention of the above as an ecological viewpoint is worthwhile if only in this mail. (but only because I'm the only one to whom it wasn't previously patently obvious :) This is precisely why I am interested in such a repository. the modern internet is an arms race, and relying on tools several years out of date is a poor solution. Thanks to Andi for your work - I will be in touch about how to work with you on this. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgp99nNzo72sN.pgp Description: PGP signature
Smooth Debian Installer Experience
Hi All, since I'm not a DD I don't know, if this is the right place to report, but anyway... I just experienced a very nice Smooth Debian Installer Experience (TM) on a Fujitsu Siemens Lifebook E Series using a pre-rc2 businesscard CD image and starting linux26. Pretty impressing! Just one remark: When I was asked to enter a package server I would have liked to enter my local package repository (with all the base stuff in it), but either I couldn't or I didn't see it. But, never mind ... Regards, Tilo
Re: Updating scanners and filters in Debian stable (3.1)
Jesus Climent [EMAIL PROTECTED] writes: On Fri, Oct 08, 2004 at 09:17:44AM -0700, Thomas Bushnell BSG wrote: Suppose a nifty new emacs feature is developed; why should that new functionality be excluded from this repository you are speaking of, merely because it isn't a security update? Because, even if they are not security updates (*) the new functionality adds a value to an obsolete package which is better not to have anymore in the repository, unlike the new emacs functionality, which does provide an update to a perfectly working package. This is an argument for why we ought to do what makes the package useful (keep the virus definitions up-to-date, and add what new things are necessary for that purpose), but is no argument for making other unrelated changes. Thomas
Re: Updating scanners and filters in Debian stable (3.1)
paddy [EMAIL PROTECTED] writes: But, I can see the case, as I describe before, where achieving the function of a package places great pressure on the time to package, so much so that if an interim, first cut package can achieve this most effectively (ie: quickest) by shipping upstream 'important fixes/features' mixed with 'other new functionality, which is not actually necessary' then that can be a win too. But I could agree: only with the proper follow-up. No, no, no. If nobody is around to devote that time to the package, then it should not be released. It is not ok to release it, and then say, I don't have the time to do it right! and then do it wrong. Thomas
Re: about volatile.d.o/n
Duncan Findlay [EMAIL PROTECTED] writes: When spamassassin is upgraded, it's more than just the rules. Often the method of parsing the message is changed -- leading to better results, or support for different tests is added, etc. It would be very difficult to only backport the appropriate changes, and the result would be less stable than the version from which backporting was taking place. On the other hand, each new version makes minor changes to functionality. (Ignore 3.0.0 right now, it's got different issues all together.) To require backported changes would simply be a waste of effort and would defeat the purpose to a certain extent. Nonsense. It would be harder work, and maybe there is nobody around to do the hard work. But it is hardly impossible. This is what stability is about. What you are calling for is abandoning Debian's stability judgment to upstream's, in a situation where upstream isn't making any stability promises at all. So backport the appropriate changes only, and find programmers who can do a good enough job not to screw it up and destabilize it. Thomas
Re: about volatile.d.o/n
On Fri, Oct 08, 2004 at 08:19:24PM +0200, Martin Zobel-Helas wrote: Is for example a package whois also a candidate for volatile? Regestries change from time to time; i just consider .org changed within the last 2,5 years... Perhaps... if it renders it unusable for getting whois answers... -- Jesus Climent info:www.pumuki.org Unix SysAdm|Linux User #66350|Debian Developer|2.4.27|Helsinki Finland GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69 Gentlemen, you can't fight in here! This is the War Room. --President Merkin Muffley (Dr. Strangelove)
Re: about volatile.d.o/n
On Fri, Oct 08, 2004 at 03:51:29PM -0400, Daniel Burrows wrote: I generally have to resort to backports or unstable when installing Debian on recent hardware, because we don't update hardware drivers in stable. Would the kernel and X be candidates for volatile? I dont see any reason why not, if they can be marked as NotAutomatic. -- Jesus Climent info:www.pumuki.org Unix SysAdm|Linux User #66350|Debian Developer|2.4.27|Helsinki Finland GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69 Why must I be surrounded by frickin' idiots? --Dr. Evil (Austin Powers: International Man of Mystery)
Re: Updating scanners and filters in Debian stable (3.1)
On Fri, Oct 08, 2004 at 04:43:03PM -0700, Thomas Bushnell BSG wrote: This is an argument for why we ought to do what makes the package useful (keep the virus definitions up-to-date, and add what new things are necessary for that purpose), but is no argument for making other unrelated changes. As explained by Duncan and for my experience with SA, it is not obvious how to make backports of chunks of SA code without changing essential parts of the core engine. My point is that v.d.o is _optional_ so changes should be allowed by v.d.o policy, to certain extent and following some consens and some rules defined there. You want your system stable and rock solid? dont point your sources.list to v.d.o and work done. But right now, i have 3 machines with backported SA 2.64-1, clamav, amavisd-new and many other software... and i suffer. I cannot keep those machines with sid, or even sarge, but i cannot keep them with SA 2.20, either. J -- Jesus Climent info:www.pumuki.org Unix SysAdm|Linux User #66350|Debian Developer|2.4.27|Helsinki Finland GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69 London. You know... fish, chips, cup o' tea, bad food, worse weather, Mary-fucking-Poppins... London! --Avi (Snatch)
Re: about volatile.d.o/n
On Fri, Oct 08, 2004 at 04:45:57PM -0700, Thomas Bushnell BSG wrote: Nonsense. It would be harder work, and maybe there is nobody around to do the hard work. But it is hardly impossible. This is what stability is about. What you are calling for is abandoning Debian's stability judgment to upstream's, in a situation where upstream isn't making any stability promises at all. So backport the appropriate changes only, and find programmers who can do a good enough job not to screw it up and destabilize it. Just another thought... You think that people looking at the code to backport a given set of features has a better clue about stability than the long time experienced upstream programers? I believe that a backport of many parts of the actual SA3 and even 2.64 or earlier would result on a much more unstable version of SA (forked and unsupported by upstream) than, say, 2.64. And what about security review? A backported set of code integrated into an old core might have a better integration? I doubt it. I would rather have a 2.64 version in volatile (not a 3.0, right now) which has been tested and used by thousands of users and postmasters than 2.20 or a crippled version specific to Debian with all that possible but hard work done. -- Jesus Climent info:www.pumuki.org Unix SysAdm|Linux User #66350|Debian Developer|2.4.27|Helsinki Finland GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69 It's a soldier's duty. You wouldn't understand. --The Colonel (Akira)
Re: about volatile.d.o/n
On Fri, 08 Oct 2004, Thomas Bushnell BSG wrote: This is what stability is about. What you are calling for is abandoning Debian's stability judgment to upstream's, in a situation where upstream isn't making any stability promises at all. I can speak only for myself, but I can guarantee you that this is *NOT* how I will deal with Cyrus backports, and I am certainly not doing it for amavisd-new as a co-maintainer, either. There are packages and packages, and there are upstreams and upstreams. If that means Cyrus IMAPd and amavisd-new are not good enough for volatile.d.o, well, then I will keep the backports elsewhere (such as in backports.org)... But really, stability MUST be the name of the game for volatile.d.o (which really suggests to me that we should have volatile/stable and volatile/unstable, which do *NOT* track sid, but rather work a bit like what sid - testing does, but with grace times on the other of a month. And always based on debian stable). This still has nothing to do with no new upstream versions. So backport the appropriate changes only, and find programmers who can do a good enough job not to screw it up and destabilize it. Often, upstream IS good enough not to screw up and destabilize things. Often, trying to backport things in pieces IS going to be much harder and riskier (in stability terms) than doing a full new upstream version upgrade. This is by no means the general rule, but those of us who have such an upstream, know it. -- 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
Re: Updating scanners and filters in Debian stable (3.1)
Thomas == Thomas Bushnell BSG [EMAIL PROTECTED] writes: Thomas And this means that the maintainer/whoever must do the Thomas potentially hard work of backporting particular changes Thomas and not others from upstream releases; merely including a Thomas new upstream release is not good enough. The tradeoff here, is that the maintainer/whoever in doing the back-porting might make mistakes, causing unnoticed breakage, or not port all security fixes (especially if code was rewritten upstream). -- Brian May [EMAIL PROTECTED]
Re: about volatile.d.o/n
On Fri, Oct 08, 2004 at 04:45:57PM -0700, Thomas Bushnell BSG wrote: Duncan Findlay [EMAIL PROTECTED] writes: When spamassassin is upgraded, it's more than just the rules. Often the method of parsing the message is changed -- leading to better results, or support for different tests is added, etc. It would be very difficult to only backport the appropriate changes, and the result would be less stable than the version from which backporting was taking place. On the other hand, each new version makes minor changes to functionality. (Ignore 3.0.0 right now, it's got different issues all together.) To require backported changes would simply be a waste of effort and would defeat the purpose to a certain extent. Nonsense. It would be harder work, and maybe there is nobody around to do the hard work. But it is hardly impossible. Well, it's possible, but it wouldn't be stable. A version that consists only of backports is not going to have as many users, and as a result will have little testing before releasing to volatile.d.o. Unless you're saying you can find perfect programmers, a version consisting only of backports will be less stable than a new upstream version. I can understand the logic to a certain extent when there is a small set of changes, but it really doesn't work on a larger scale. This is what stability is about. What you are calling for is abandoning Debian's stability judgment to upstream's, in a situation where upstream isn't making any stability promises at all. Not really. I'm just saying that there's necessarily a tradeoff and you can't have the best of both worlds. So backport the appropriate changes only, and find programmers who can do a good enough job not to screw it up and destabilize it. Given a large enough subset of upstream changes, any programmer will screw it up, especially in the absence of many users testing. -- Duncan Findlay signature.asc Description: Digital signature
Accepted r-cran-psy 0.6-2 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 8 Oct 2004 00:06:32 -0500 Source: r-cran-psy Binary: r-cran-psy Architecture: source all Version: 0.6-2 Distribution: unstable Urgency: low Maintainer: Chris Lawrence [EMAIL PROTECTED] Changed-By: Chris Lawrence [EMAIL PROTECTED] Description: r-cran-psy - GNU R procedures for psychometrics Changes: r-cran-psy (0.6-2) unstable; urgency=low . * Rebuild for R 2.0.0. Files: ea4236894926e029b30b06dcc5ca7390 606 math optional r-cran-psy_0.6-2.dsc 3a1b220b01670270717d6ce4b7344f0a 1751 math optional r-cran-psy_0.6-2.diff.gz 0245269ecc8152496e8971a66126dfad 60162 math optional r-cran-psy_0.6-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBZiqY2wQKE6PXubwRAp/4AKDG8pOVHF5b0hUmVb4e+14kx2hUnQCeNByY Q/7ciFUhc60FJp2Lq79gR9k= =SISb -END PGP SIGNATURE- Accepted: r-cran-psy_0.6-2.diff.gz to pool/main/r/r-cran-psy/r-cran-psy_0.6-2.diff.gz r-cran-psy_0.6-2.dsc to pool/main/r/r-cran-psy/r-cran-psy_0.6-2.dsc r-cran-psy_0.6-2_all.deb to pool/main/r/r-cran-psy/r-cran-psy_0.6-2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted r-cran-mnp 1.2-1-2 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 8 Oct 2004 00:03:57 -0500 Source: r-cran-mnp Binary: r-cran-mnp Architecture: source i386 Version: 1.2-1-2 Distribution: unstable Urgency: low Maintainer: Chris Lawrence [EMAIL PROTECTED] Changed-By: Chris Lawrence [EMAIL PROTECTED] Description: r-cran-mnp - GNU R package for fitting multinomial probit (MNP) models Changes: r-cran-mnp (1.2-1-2) unstable; urgency=low . * Upload to unstable. Files: 1c02d0dfa9c14417e2ee956126aaac5d 606 math optional r-cran-mnp_1.2-1-2.dsc 9ea9ba22dcbc58b3eff70b18e5764437 2063 math optional r-cran-mnp_1.2-1-2.diff.gz 9dbfb6ec2bbade2f89ae42e1877c 66598 math optional r-cran-mnp_1.2-1-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBZiqf2wQKE6PXubwRAhULAKCqQl5ep6j/vfqcL0MCg0RI7Iv9JACfU88M lXVwGPBazbJltcwJmfvTNdA= =RVSg -END PGP SIGNATURE- Accepted: r-cran-mnp_1.2-1-2.diff.gz to pool/main/r/r-cran-mnp/r-cran-mnp_1.2-1-2.diff.gz r-cran-mnp_1.2-1-2.dsc to pool/main/r/r-cran-mnp/r-cran-mnp_1.2-1-2.dsc r-cran-mnp_1.2-1-2_i386.deb to pool/main/r/r-cran-mnp/r-cran-mnp_1.2-1-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
