Hey, debian-devel-italian
Hi, debian-devel-italian
Re: c2a transition: libraries still needing transition
#include hallo.h * Nathanael Nerode [Tue, Dec 20 2005, 04:59:46PM]: rlog -- old version is in testing Depends on the update of fuse. I am waiting for any reaction from Bartosz and I am going to NMU fuse next week or so if nothing happens. Eduard. -- pearl auf tetrinet.debian.net sind leute, die ich noch nie da sah pearl paco_guanta, mamen pearl die sprechen nur französisch =) pearl paco_guarda estamos esperando a un colega -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: c2a transition: libraries still needing transition
On Tue, Dec 20, 2005 at 04:59:46PM -0500, Nathanael Nerode wrote: The following libraries still need to be uploaded with name changes for the c2a transition (http://lists.debian.org/debian-devel-announce/2005/11/msg00010.html): Most are not in testing at the moment. alps-light1 aqsis gnuift -- old version is in testing ivtools -- orphaned, also hadn't undergone c2 transition properly libsigcx libterralib log4cxx omnievents plptools qgis rlog -- old version is in testing sqlxx xalan -- old version is in testing vtk zipios++ -- old version is in testing The following packages appear to have deliberately skipped the renaming, so check what's up with debian-release before uploading: atlas-cpp This should be fixed now. Cheers, Michael -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: c2a transition: libraries still needing transition
On Wed, Dec 21, 2005 at 08:58:08AM +0100, Eduard Bloch wrote: rlog -- old version is in testing Depends on the update of fuse. I am waiting for any reaction from Bartosz and I am going to NMU fuse next week or so if nothing happens. I'm working on it, but in the same time I'm going to remove whole debconf stuff, so it needs more tests than usual. I hope that'll be enough to put information in NEWS.Debian that administrator has to clean up mess after previous fuse packages himself/herself. Because of many debconf configuration issues it's not possible to do it automatically, and trying to determine it can lead to non-working system, so I prefer to leave it as is. BTW: there are in bts some translations of fuse's debconf templates... may I close these bugs with the upload which will remove templates at all or should I close them manually with explanation that there won't be any questions since now? regards fEnIo -- ,''`. Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | irc:fEnIo : :' : 32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Poland `. `' phone:+48602383548 | proud Debian maintainer and user `- http://skawina.eu.org | jid:[EMAIL PROTECTED] | rlu:172001 signature.asc Description: Digital signature
ITP: gifsicle -- Powerful tool for manipulating GIF images
Package: wnpp Severity: wishlist * Package name: gifsicle Version : 1.44 Upstream Author : Eddie Kohler [EMAIL PROTECTED] * URL : http://www.lcdf.org/gifsicle/ * License : See below Description : Powerful tool for manipulationg GIF images This is a powerful tool for manipulating GIF image files. Extensive options let you control what exactly it does. It has good support for transparency and colormap manipulation, simple image transformations (cropping, flipping), and creating, deconstructing, and editing GIF animations, which it can also optimize for space. . Homepage: http://www.lcdf.org/gifsicle/ COPYRIGHT/LICENSE - All source code is Copyright (C) 1997-2005 Eddie Kohler. IF YOU PLAN TO USE GIFSICLE ONLY TO CREATE OR MODIFY GIF IMAGES, DON'T WORRY ABOUT THE REST OF THIS SECTION. Anyone can use Gifsicle however they wish; the license applies only to those who plan to copy, distribute, or alter its code. If you use Gifsicle for an organizational or commercial Web site, I would appreciate a link to the Gifsicle home page on any 'About This Server' page, but it's not required. This code, with the exception of the GIF compression code in gifwrite.c, is distributed under the GNU General Public License, Version 2, or, at your discretion, any later version. The GNU General Public License is available via the Web at http://www.gnu.org/licenses/gpl.html The following alternative license may be used at your discretion. Permission is granted to copy, distribute, or alter gifsicle, whole or in part, as long as source code copyright notices are kept intact, with the following restrictions. 1. Unisys Corp. holds a patent on the Lempel-Ziv-Welch compression algorithm used by GIF images. When this first became an issue several years ago, Unisys stated that programs available at no cost to the user, like Gifsicle, could use LZW compression in the context of GIF images without obtaining a license. If you plan to distribute GIF writing code in a shareware or commercial product, you will need to worry about obtaining a license. (Many people believe that LZW decompression is not covered by the Unisys patent, so GIF reading code is probably all right.) 2. Developers or distributors who plan to use Gifsicle code, whole or in part, in a product whose source code will not be made available to the end user -- more precisely, in a context which would violate the GPL -- MUST contact the author and obtain permission before doing so. -- System Information: Debian Release: testing/unstable Architecture: i686 Kernel: GNU/kFreeBSD gnu 5.4-1-686 #0 Mon Dec 5 20:14:28 CET 2005 i686 i386 AMD Sempron(tm) 3000+ GNU/kFreeBSD Locale: LANG=POSIX, LC_CTYPE=POSIX -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
URLs for usertags in the BTS
Hi, I'd like to use usertags to track the status of bugs in testing vs. unstable, but I cannot find the trick in the URL to restrict the displayed bugs to those that are still open in testing. For example, http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=pdfoutput;[EMAIL PROTECTED];dist=testingarchive=no Shows four Archived bugs of normal severity. As an example, look at the last one: http://bugs.debian.org/322353 closed with , | From: Manoj Srivastava [EMAIL PROTECTED] | To: [EMAIL PROTECTED] | Subject: Bug#322353: fixed in make 3.80-11 | Date: Wed, 10 Aug 2005 19:33:00 -0700 | | Source: make | Source-Version: 3.80-11 | | We believe that the bug you reported is fixed in the latest version of | make, which is due to be installed in the Debian FTP archive: ` This version is already in testing. The same is true for the second Serious bug that is shown. How can I specify an URL that correctly shows only bugs open in testing? TIA, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: New make is breaking several packages
2005/12/20, Anthony Towns aj@azure.humbug.org.au: So the old behaviour's POSIX compatible as long as the Makefile doesn't specify the .POSIX target. The real question is, is there a way to allow the old supported-for-years syntax. With large makefiles it uglyfies the file somewhat. And interestingly, in the changelog it's listed as a bugfix. -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/
Hey, debian-devel
Hi, debian-devel
Re: Thoughts on Debian quality, including automated testing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lars Wirzenius [EMAIL PROTECTED] writes: Automated testing of program functionality == Automatic testing needs to happen in various contexts: * When the package has been built, but before it is uploaded. This is similar to testing with lintian, linda, and piuparts. The difference from build-time tests is that the tests are run when the package is installed onto a system (possibly a chroot or a virtual system). For this task, you might find schroot(1) useful. It's a means of accessing chroot environments, but it supports LVM snapshots as one method. This is a very quick method to create and destroy a test environment (on my system, 2 seconds to create and 5 to destroy). This is quite a low overhead compared with the alternatives (untarring a tarfile, or copying a filesystem, or running cdebootstrap), and the low cleanup overhead is also advantageous. I also hope to add support for Xen on top of LVM snapshots as well. I'm just waiting for Xen to work on powerpc so I can actually use it. If anyone is interested who would like this, please get in touch. sbuild is also partially integrated with sbuild (the Debian package), though I haven't added session handling for LVM snapshots yet. Once tests become standardised with a debian/rules target, it would be fairly simple to add this to sbuild. [schroot has received some minor criticism for being written in C using GLib/GObject. I have however spent the last week converting it to C++, and I'm just finishing that up now.] Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ http://mailcrypt.sourceforge.net/ iD8DBQFDqS5QVcFcaSW/uEgRAvZUAKCcIgh8QL33CEJO24/A9669KkvF6ACgpYdC 2s5xPCXcfUkYNZZIRCFY2so= =huA9 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ITP: gifsicle -- Powerful tool for manipulating GIF images
Gürkan Sengün writes: * Package name: gifsicle #212193, if anyone is thinking this sounds vaguely familiar. * URL : http://www.lcdf.org/gifsicle/ Which reads, in part: As of July 2004, all of Unisys's LZW/GIF patents have expired, but IBM has a remaining patent. There may be reason to believe that Gifsicle avoids these issues[1]; I have no position on that. Gifsicle is not distributed with a patent license. You are responsible for obtaining a license, deciding not to obtain a license... [1] http://www.danbbs.dk/~dino/whirlgif/disclaimer.html Some commentary on this should certainly be included with your ITP. Even if you believe we can now distribute this code, you should probably discuss the matter on -legal first (I'm not going to make any claims about it here). P.S. Please use X-Debbugs-Cc:. -- things change. [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: switching to vim-tiny for standard vi?
On Tue, 20 Dec 2005, Steve Greenland wrote: On 20-Dec-05, 09:56 (CST), Gabor Gombas [EMAIL PROTECTED] wrote: On Tue, Dec 20, 2005 at 08:57:08AM -0600, Steve Greenland wrote: [1] Dark blue on black. Need I say more? The reality is that visibility of color combinations is heavily dependent on all kinds of things that vim can't determine, from the font being used and the default background color, to the ambient lighting of the room and the vision capability of the user (not just color blindness, but very fine variances in the color sensitivity of the user, or even how tired the person is, which can affect their ability to focus.) Color really needs to be tuned to the needs of the individual user. The color depends a lot more on the monitor in question, rather than the user. Nearly all of us with full color vision have roughly the same sensitivity to all colors -- but, monitors of different manufacturers and of different age vary a lot. But, it's trivial to fix this issue. On Linux console, PuTTY and a good deal of terminal emulators: echo -ne '\e]P4ff' (ESC ] P color num (0..f) RRGGBB color code) You can put your palette into /etc/issue, bash prompt or anywhere else. On real xterms, you can mess with X resources. On gnome-terminal and konsole, you waddle through the GUI. If you happen to use CRT monitors that are more than a couple years old, improving the color palette is pretty much a must. -- /---\ Shh, be vewy, vewy quiet, | [EMAIL PROTECTED] | I'm hunting wuntime ewwows! \---/ Segmentation fault (core dumped) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: URLs for usertags in the BTS
On Wed, Dec 21, 2005 at 10:40:59AM +0100, Frank Küster wrote: http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=pdfoutput;[EMAIL PROTECTED];dist=testingarchive=no Shows four Archived bugs of normal severity. As an example, look at the last one: http://bugs.debian.org/322353 This version is already in testing. The same is true for the second Serious bug that is shown. Yes, they're also listed as resolved. How can I specify an URL that correctly shows only bugs open in testing? Adding ;pend-exc=done,absent should do what you want, I think. Cheers, aj signature.asc Description: Digital signature
Re: switching to vim-tiny for standard vi?
On Tue, 20 Dec 2005, Henning Makholm wrote: Scripsit Gabor Gombas [EMAIL PROTECTED] Now, if your terminal pretends to be xterm but does not use the color scheme of xterm, how should vim know that? You can't. real console: TERM='linux' xterm: TERM='xterm' gnome-terminal: TERM='xterm' konsole: TERM='xterm' PuTTY: TERM='xterm' rxvt: TERM='rxvt' aterm: TERM='rxvt' wterm: TERM='rxvt' I would suggest that the right solution is that every program that sets foreground colors should also, as its default behavior, make sure to set a background color that goes well with the chosen foreground. The if you pick one color, pick them all maxim of web design works for non-web user interfaces, too. Good idea. Just stick \e[40m into the program's color codes and suddenly the scheme becomes XXX-on-black. Use \e[47m and you get XXX-on-white. And, if termcap/terminfo claim the terminal doesn't support \e[4Xm, it's termcap which is wrong -- according to my data, Win3.1..ME telnet.exe was the last terminal emulator in existence which can't handle these. Even with a genuine xterm users can and do set their personal color scheme preferences in X resources. But if you're going to override the foreground color you might as well also override the background one. Of course any good program should offer per-user customization of its color scheme, and offer default as an option for background color, in case the user's preferred background is not among the ones that can be set with ordinary setb/setab strings. Few fancy terminal emulators obey X resources, but you're right. While the way to set the color palette differs, all of the terminals I named in this message provide a way to do so. However, you're wrong if you believe setb/setab are good for anything. Since termcap and terminfo are based on the value of TERM, they assume some random settings which are hardly ever valid. The list I put in the beginning shows that even terminals which use completely different code bases and have little coverage of common standards tend to claim they're xterm. And that's only several terminals included in Debian. If you go outside, things get a lot worse; the most spectacular example happens if you log on into a SunOS machine using any of three terminals shipped with IRIX (as of ~7 years ago). The failure mode includes removingallcolorsandallspaces. It may sound strange, but if you want portability, you can't use termcap, terminfo or *curses -- but on the other hand, using lowest-common- denominator vt100 codes, \e[ foo m and ioctl(TIOCGWINSZ) makes things work perfectly everywhere I tested save for the damned telnet.exe. -- /---\ Shh, be vewy, vewy quiet, | [EMAIL PROTECTED] | I'm hunting wuntime ewwows! \---/ Segmentation fault (core dumped) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: URLs for usertags in the BTS
Anthony Towns aj@azure.humbug.org.au wrote: How can I specify an URL that correctly shows only bugs open in testing? Adding ;pend-exc=done,absent should do what you want, I think. Thank you, fine. Archived bugs are still displayed, but only in the separate resolved categories. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Thoughts on Debian quality, including automated testing
ke, 2005-12-21 kello 10:28 +, Roger Leigh kirjoitti: For this task, you might find schroot(1) useful. It's a means of accessing chroot environments, but it supports LVM snapshots as one method. Does this require the user to set up LVM somehow before using schroot? This is a very quick method to create and destroy a test environment (on my system, 2 seconds to create and 5 to destroy). For me, unpacking a tar file takes about 4 seconds (from a cold cache, machine had just been rebooted) and afterwards less than a second to remove (but then it was all in the cache). This is a small part of the whole process, which for piuparts can take several minutes, if it tests upgrades from stable via testing to unstable. -- Debian is a beast that speaks with many voices -- R.B. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Thoughts on Debian quality, including automated testing
First, thanks to Lars for drawing our attention to an important topic and for taking an initiative that is long overdue. Lars, I agree fully with what you say. When it comes to team maintenance I would go even further than you do. You say: Mandatory teams for packages seems ridiculous to me. Lots of packages are so small that having to arrange a team for them, even if it is only the effort to set up and subscribe to a team mailing list, is wasteful. Not everyone likes to work in a close team, either, and we shouldn't exclude them. I don't think that it is ridiculous to require that every package have a team behind it---i.e., at least two maintainers. First, if someone can't find ONE other person willing to be named as a co-maintainer of a given package then I would seriously doubt that that package (or that person) is an asset to Debian. Second, putting packages in the custody of a team makes it easy for a tired maintainer to relinquish control. If the team works via an alioth project then there are many benefits. Code is kept under version control and thus backed up; the change history can be easily viewed by anyone; the mailing list becomes an easily browsed history of package development. Team maintainership is working very well for some other distributions. I would support requiring team maintainership because TM will be beneficial in almost all cases and making it a requirement it cuts off a lot of useless discussion. There are several packages in Debian that are notoriously undermaintained and whose maintainers have mused from time to time about getting help, but haven't bothered to do it. They should be forced to get help, or to give up maintaining those packages. Consistent with this view, I have just created teams for all my packages even though most of them are mature. I am glad to have the help; having new people to work with has given me some new ideas. Combined with the principle of non-responsibility (constitution §2.1), the institution of exclusive solitary package ownership has made some Debian packages into bastions of untended bugs. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Thoughts on Debian quality, including automated testing
On Wed, Dec 21, 2005 at 02:07:30AM +0200, Lars Wirzenius wrote: Sloppiness tends to result in real problems sooner or later. possible slogan for volatile-sloppy ? :) Several ideas have been floating around for years on how to improve this situation, of which I'd like to mention three. While I've here used the number of bugs as the measure of a package's quality, the same ideas might help with other aspects, like getting new upstream versions packaged soon after they're released. * Team maintenance. snip * Less strong ownership of packages. snip * Abolishing package ownership completely. snip It might be implied in one of the above, but what about: * competitive maintenance Sorry, I couldn't resist. Regards, Paddy -- Perl 6 will give you the big knob. -- Larry Wall -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /run vs. /lib/run
Anthony Towns wrote: On Mon, Dec 19, 2005 at 08:45:45PM -0800, Russ Allbery wrote: (TBH, I'd be much happier just making the technical changes necessary to ensure /var is mounted early -- keeps the filesystem sane, and it's just a simple matter of programming, rather than arguing over what's ugly. Yeah, I agree with this too. So why don't we go with this? Thomas? The proposal looks like it could work. I would take the proposal, simplify it (it can be made more complex later if there is a need for more flexibility), and carry it out in at least two steps. To simplify the first step we take the early run fs which is needed in some cases, mount it unconditionally with a fixed fs type and at a fixed location. This alone will be useful for several purposes. Bind-mounting this directory under /var/run in a race-free manner can be implemented in a second stage. Someone should submit a wish report and provide a patch, plus testimony from maintainers who need this enhancement and the reasons why they must be able to write to /var/run/, per se, so early. -- Thomas Hood ;) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian GNU/Linux 3.1 updated (r1)
Martin Schulze [EMAIL PROTECTED] writes: The Debian Projecthttp://www.debian.org/ Debian GNU/Linux 3.1 updated (r1) [EMAIL PROTECTED] December 20th, 2005 http://www.debian.org/News/2005/20051220 Debian GNU/Linux 3.1 updated (r1) Following the official point release the Debian-amd64 team is currently preparing the Inofficial Debian-amd64 GNU/Linux 3.1r1 point release to sync back with Debian. It will take a short while to move all the security updates in place and to build the remaining sarge updates, possibly lengthened by people being on X-Mas holidays, so please bear with us. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: switching to vim-tiny for standard vi?
On Tue, Dec 20, 2005 at 01:53:07PM -0600, Steve Greenland wrote: On 20-Dec-05, 12:54 (CST), Graham Wilson [EMAIL PROTECTED] wrote: I've found vim's defaults are unreadable except on a white background, since that is what vim assumes you have by default. Actually, I do use a white background. Apparently your tolerance for yellow on white is higher than mine. (Not meant sarcastically, it's quite possible that you do see that combo better than I do.) FWIW I have been using this for years on a white background and it's much more readable: if background == dark hi Commentterm=bold ctermfg=Cyan guifg=#80a0ff hi Constant term=underline ctermfg=Magenta guifg=#ffa0a0 hi Specialterm=bold ctermfg=LightRed guifg=Orange hi Identifier term=underline cterm=bold ctermfg=Cyan guifg=#40 hi Statement term=bold ctermfg=Yellow guifg=#60 gui=bold hi PreProcterm=underline ctermfg=LightBlue guifg=#ff80ff hi Type term=underline ctermfg=LightGreen guifg=#60ff60 gui=bold hi Ignore ctermfg=black guifg=bg else hi Commentterm=bold ctermfg=DarkCyan guifg=Blue hi Constant term=underline ctermfg=DarkBlue guifg=Magenta hi Specialterm=bold ctermfg=DarkRed guifg=SlateBlue hi Identifier term=underline ctermfg=DarkGreen guifg=DarkCyan hi Statementterm=bold ctermfg=DarkMagenta gui=bold guifg=Brown hi Statement term=bold ctermfg=DarkMagenta guifg=Brown hi PreProcterm=underline ctermfg=Brown guifg=Purple hi Type term=underline ctermfg=DarkGreen guifg=SeaGreen gui=bold hi Type term=underline ctermfg=DarkGreen guifg=SeaGreen hi Ignore ctermfg=white guifg=bg endif hi Error term=reverse ctermbg=Red ctermfg=White guibg=Red guifg=White hi Todo term=standout ctermbg=Yellow ctermfg=Black guifg=Blue guibg=Yellow highlight link Typedef Special highlight link StorageClass Special Insert in ~/.vim/syntax.vim and make sure your ~/.vimrc has: if has(syntax) let mysyntaxfile = ~/.vim/syntax.vim let myscriptsfile = ~/.vim/scripts.vim let myfiletypefile = ~/.vim/filetype.vim syntax on endif -- Typed slowly for those who cannot read fast. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Thoughts on Debian quality, including automated testing
On Wednesday 21 December 2005 12.23, Thomas Hood wrote: I don't think that it is ridiculous to require that every package have a team behind it---i.e., at least two maintainers. First, if someone can't find ONE other person willing to be named as a co-maintainer of a given package then I would seriously doubt that that package (or that person) is an asset to Debian. The problem is: do you honestly want to force people who don't want to have comaintainers on their packages to leave Debian? Or do you want people who really don't want to have comaintainers for their packages to put somebody in just so they are following the rules, while they regard anything done by this comaintainer on his own like they would regard an intrusive NMU? Don't misunderstand me: team maintenance is great, and I think it makes sense even for small and trivial packages. But trying to force anybody to do anything is no productive in Debian (and we'd have to modify the constitution for this, anyway :-) -- vbi -- Every religion is about absolute belief in its own superiority and the divine right to impose its version of truth upon others. -- Pervez Amir Ali Hoodbhoy, Prospect Magazine Feb 2002 pgp9ONltQgrDx.pgp Description: PGP signature
Re: Thoughts on Debian quality, including automated testing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lars Wirzenius [EMAIL PROTECTED] writes: ke, 2005-12-21 kello 10:28 +, Roger Leigh kirjoitti: For this task, you might find schroot(1) useful. It's a means of accessing chroot environments, but it supports LVM snapshots as one method. Does this require the user to set up LVM somehow before using schroot? Yes. You would create a separate logical volume (LV) for each distribution you want to support, set them up with debootstrap. Once done, you add a configuration stanza like this: [sid] type=lvm-snapshot description=Debian sid snapshot priority=3 groups=root,sbuild root-groups=root,sbuild device=/dev/hda_vg/sid_chroot mount-options=-o atime,sync,user_xattr lvm-snapshot-options=--size 2G run-setup-scripts=true run-session-scripts=true I plan to add support for tar(.gz|.bz2) and zip files as well once I've finished the C++ conversion (the other alternatives are currently directories and any mountable block device), then when combined with sbuild, you'll have a system almost but not quite entirely unlike pbuilder. It's all nicely modular, so adding a new chroot type is trivial. The other advantage is that it uses PAM in a similar manner to sudo, so you can grant certain users access to root privs (root-groups) in the chroots, which allows them to install/upgrade/remove packages in the chroots. Obviously this is quite simple to abuse if you know what you're doing, so you would only grant it to folks you could trust. When it supports Xen, you could also grant root privs to folks you /don't/ trust, since they would be entirely self-contained. This is a very quick method to create and destroy a test environment (on my system, 2 seconds to create and 5 to destroy). For me, unpacking a tar file takes about 4 seconds (from a cold cache, machine had just been rebooted) and afterwards less than a second to remove (but then it was all in the cache). The difference for a minimal chroot is not too great. The main advantage of schroot LVM snapshotting is that the time is constant irrespective of the size of the LV (it's copy-on-write), whereas for tar it is linear. For slow machines and older architectures, this is an advantage. This is a small part of the whole process, which for piuparts can take several minutes, if it tests upgrades from stable via testing to unstable. OK. - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ http://mailcrypt.sourceforge.net/ iD8DBQFDqWRvVcFcaSW/uEgRAqbKAJ9Oy4S1TT8FaHq7aZVzX7CJhpsoNQCfRZo0 3kX9PCMU7X/FZf9a8tSbLkA= =RcKK -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to our ftp-master team
Anand Kumria [EMAIL PROTECTED] writes: On Fri, Dec 16, 2005 at 03:56:30PM +0100, Goswin von Brederlow wrote: Anand Kumria [EMAIL PROTECTED] writes: I'd like to congratulate our ftp-master team on their ability to timely process packages progressing through the NEW queue. http://ftp-master.debian.org/new.html [1] I think you are an excellent example of people who are too busy for Debian. I must say that I am particularly impressed that you've managed to frustrate our users for over 1 year with the package 'xvidcap'. Guessing by the name alone I would say this is a patent issue like mplayer and therefore a problem package that is not likely to get resolved anytime soon. But that is just a guess. And it is an incorrect guess. xvidcap itself uses libraries already in Debian. But thanks for playing guess the mind of the ftp-masters. Was it fun? Yes and I guessed right it seems. The ffmpeg library in debian is a problem case and probably should not be in there. That issue hasn't been decided yet and till then anything using it stays stuck. And yes, that should be documented or at least communicated to the maintainer. For non problem cases the NEW queue was never as fast as now so congratulation of improving the NEW queue so much already. Giving your past month performance I'm sure the few remaining issues can be resolved in time as well. Ignoring anything 2 weeks or newer I count only 7 packages. This is great. Maybe you are a fan of being left in limbo, or like the perverbial Schrödinger's cat, but even a bad process can benefit from assurances. A simple assurance that your package will be rejected from the NEW queue if no ftp-master approves it within 2 weeks would actually be a benefit. And would result in mplayer being uploaded again and again everytime someone forgets it was there before. Beter to have it stuck but documented why. Anand MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: switching to vim-tiny for standard vi?
On 20.12. 08:36, Steve Greenland wrote: I'm still missing the incentive. Joey Hess wrote in his earlier message that It's now only marginally larger than nvi. It achieves that by removing many of the features that distinguish vim from nvi, to the point that my guess is that most of those who prefer vim will need to install the full vim anyway, while those that prefer nvi will just fell vaguely dissastified by the change. If the result of this is that a) base is not smaller, and b) vim users still have to install vim-nottiny, and c) nvi users now have to install nvi, I don't think it's a net win. As much as I personally prefer vim, I feel your arguments a) b) and c) are the strongest I've read so far in this thread and therefore I also have to agree on the conclusion: Keep nvi as default. Cheers, Christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Thoughts on Debian quality, including automated testing
Lars Wirzenius [EMAIL PROTECTED] wrote: * Less strong ownership of packages. (snip) This idea hasn't been tested. It could be tested if some group of maintainers declared that some or all of their packages were part of the experiment, that anyone could NMU them for any reason whatsoever, as long as they take proper care not to mess the package up. It's not something that's been tested in Debian, but it's the standard way of getting things done in Ubuntu. So far, it seems to have worked fairly well. The two situations aren't directly analagous since Ubuntu has a smaller and more cohesive group of people involved, but I think it's possibly indicative that this proposal would work. I think I've said this before, but I have no objections to anyone uploading any of my packages. I'd be even happier if anyone who did so was willing to enter into some sort of reciprocal agreement. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Checking package builds on hppa/arm/m68k?
Andreas Fester [EMAIL PROTECTED] writes: Benjamin Mesing wrote: Please (re)check, if the package can be built by g++ 3.4 on [hppa/arm/m68k]? Do I simply remove the explicit build dependency on g++, upload the package and wait if it succeeds (and probably create another package version with the build dependencies re-added again if it still fails)? As Matthias Klose in his announce [1], this workaround is no longer needed (if you are speaking about the issue affecting a lot of QT/KDE My issue was the ICE which occured on these platforms for (also non-Qt/KDE) c++ builds (I think this is not related to the mt_alloc issue): http://lists.debian.org/debian-gcc/2005/11/msg00123.html Since this bug seems to be solved now, and Matthias also said Please (re)check, if the package can be built I was just wondering what the proper way of checking is. Best Regards, Andreas Normaly you have 3 choices: 1. log into the Debian systems for each arch and check 2. upload and reupload if it still fails Only if the problem should be gone now, e.g. the gcc ICE bug got closed. You should probably 'Build-Depends: g++-3.4 (= fixed-version) [arch]' to force a g++ update before build. 3. ask the porters As non DD (1) becomes difficult and (2) can be tiresome to your sponsor and yourself. (3) on the other hand is also work. MfG Goswin PS: I would upload the package to be build with the normal g++-3.4 and leave it failed on some archs unless it is something critical. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: switching to vim-tiny for standard vi?
On Wed, Dec 21, 2005 at 03:31:26PM +0100, Christian Fromme wrote: On 20.12. 08:36, Steve Greenland wrote: I'm still missing the incentive. Joey Hess wrote in his earlier message that It's now only marginally larger than nvi. It achieves that by removing many of the features that distinguish vim from nvi, to the point that my guess is that most of those who prefer vim will need to install the full vim anyway, while those that prefer nvi will just fell vaguely dissastified by the change. If the result of this is that a) base is not smaller, and b) vim users still have to install vim-nottiny, and c) nvi users now have to install nvi, I don't think it's a net win. As much as I personally prefer vim, I feel your arguments a) b) and c) are the strongest I've read so far in this thread and therefore I also have to agree on the conclusion: Keep nvi as default. I don't think it's easily possible to count on people contributing to this thread to be representative, but I do think (b) is certainly less than it seems: Even vim-tiny would I think be liked more than nvi -- because vim-tiny invoked as 'vim' can be configured easily to be pretty much like the real vim, only lacking such features as systax hilighting which you can do without easily, if you're working on a small-editor environment. Looking at popcon, vim has about twice the amount of users as nvi, while nvi is the default vi, and vim is merely optional. I think this is an excellent question to phrase with a few options in a devotee-poll, and have people vote on it -- results being purely advisory, the poll just being informative, and any results updated live, rather than only after a delay. I think it'd be good to representative polls on a reasonably regularly basis -- close to the same representativeness, and stil much much more lighter than a GR, so easier to just do when some people feel a more clear idea of what the average DD thinks is needed than what one can gather from a mailinglist thread. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: switching to vim-tiny for standard vi?
On Wed, Dec 21, 2005 at 03:31:26PM +0100, Christian Fromme wrote: vaguely dissastified by the change. If the result of this is that a) base is not smaller, and b) vim users still have to install vim-nottiny, and c) nvi users now have to install nvi, I don't think it's a net win. As much as I personally prefer vim, I feel your arguments a) b) and c) are the strongest I've read so far in this thread and therefore I also have to agree on the conclusion: Keep nvi as default. Your conclusion is of course to be considered as all the others. Still, we already discussed that (b) is not true: vim users will be happier with vim-tiny than with vim even without vim-nottiny/vim-runtime. Since my feeling is that we have more vim users than nvi ones, installing the former instead of the latter per default is a net win. Assuming my feeling is correct of course ... -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Re: buildd administration
Russ Allbery [EMAIL PROTECTED] writes: Goswin von Brederlow [EMAIL PROTECTED] writes: Russ Allbery [EMAIL PROTECTED] writes: Funny, I just did a Google search for site:www.debian.org cvs repository www.debian.org and there it was, plain as day. That implies that you already know/suspect it is in cvs. Goswin, with all due respect, you really either have no idea what you're talking about here or you're rather bad at using Google. A search on: Point was that there is no source repository link on www.debian.org itself. See, what you keep missing is that, regardless of the willingness of the current buildd maintainers to work with you, you are using the openness or not of your work as a bargaining point. I have serious philosophical problems with that. Where did I ever say We must use this because it is free? You didn't. If you were saying that, I'd actually have more respect for your position. You are instead saying our stuff is proprietary and we'll only release the source if the buildd.debian.org maintainers agree to play ball. That's deeply messed up, and as far as I'm concerned that stops the conversation cold. I don't care how messed up the current stuff is -- I'm very nervous about software written by someone with that attitude coming anywhere near Debian core infrastructure. That is not at all what was said. When I first used buildd.net I wanted to have graphs and some other features for it so I just went on irc ans asked IJ for the scripts so I could patch them. 5 minutes later I was patching in gnuplot scriplets. You just try to make a point out of buildd.net not having a direct source link which is completly irelevant imho. Both buildd.d.o and buildd.net are in exactly the same state regarding openness: You have to ask the maintainer for the scripts personaly. And that's not sufficient for any replacement. I don't think it's great for the existing scripts either, but they have a few huge advantages: they're already in place and they're already working. If we're looking at giving up those advantages and replacing them with something else, then the *least* that the new stuff should do is be free software. If you (as in buildd.d.o) want to add a source link then do it. That is debians decision ultimately. So far Debian hasn't made that addition and Ingo didn't want to make it. That is your/his choice and changes nothing on the freeness of the software. It just changes the propagation medium. My argument is that is has better functionality not better idiology. If you want more people to support your argument, produce better ideology too. Otherwise, you can keep whining about this on debian-devel until the end of time and as far as I'm concerned the right thing for everyone involved in Debian to do is ignore you. DFSG free is good enough for me. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
Steinar H. Gunderson [EMAIL PROTECTED] writes: On Sun, Dec 18, 2005 at 12:34:56PM +0100, Gürkan Sengün wrote: I've run some scripts to find out the size of binary pakcages in debian and how theycould be made smaller, here's the results: My comments are about the same as on IRC: - Disk space is cheap, bandwidth is cheap. Spare disk space isn't available to add amd64 to mirrors. Spare bandwith isn't available to add amd64 to mirrors. Users disk space might be cheap but they have the unpacked binaries anyway. Users bandwith might be cheap but often very limited due to infrastructure. A lot of analog modems are still out there. - CPU doesn't grow nearly as fast as those three. Any arch where cpu speed still grows has plenty of cpu time to spare anyway. Only old archs (and the embedded stuff) have cpu problems. But do they want a 200MB OpenOffice? - Human power grows even slower. - The administrative overhead of transitioning to a new .deb format would be huge. Where do you get this from? Where is this relevant? The overhead to change to a new deb format is small. A very few packages have to change (dpkg, apt, DAK, mini-dinstall). A few man hours of work and compared with the amount of changes in debian every day that is miniscule. The transition itself would go completly unadministered. Once dpkg is switched to default to a different compression all freshly build packages use it and the archive transitions itself over time. All the transition needs, after the initial infrastructure change, is a lot of time. At least one stable release to get stable dpkg to cope with differently compressed unstable packages and then time for every package to get a new upload. Thus, anything sacrificing lots of human power and CPU power to save on disk or bandwidth just doesn't make sense. Don't forget CD/DVD space. With better compression you could probably fit Sarge i386 on a dual layer dvd again. The businesscard and netboot images would also shrink alowing some more debs on them, e.g. a graphical installer. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
Olaf van der Spek [EMAIL PROTECTED] writes: On 12/18/05, Steinar H. Gunderson [EMAIL PROTECTED] wrote: On Sun, Dec 18, 2005 at 02:56:10PM +0100, Olaf van der Spek wrote: Why would this be huge? Why is it that hard to plugin another codec? You'd have to rewrite about every single tool in the world handling .debs, make up a transition plan and upgrade from that. Not to mention that you'd Why is the knowledge of how to decode a .deb distributed over so many tools? have to make sure it works on all kinds of obscure platforms actually using the thing. (And yes, I have used ar and tar to extract debs, and consider it a quite useful feature.) Why would that stop working if you switch compression schemes? I guess tar is coded to use gzip with -z and bzip2 with -j, but why is there no generic way to add coders/decoders (codecs) to tar (and other applications that wish to use compression filters)? uncompressor file.tar.whatever | tar -x The .deb format is _fixed_ -- this isn't AVI where you just plug in another codec and hope it works. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /run vs. /lib/run
[Petter Reinholdtsen] One user is bootlogd, needing before init is started to store stats about the boot. That is before both these points in the boot. I managed to write bootlogd when I intended to write bootchartd. That is the package making statistics about the boot process. [Anthony Towns] So how do you log the failure of mounting /run rw? Given this is supposed to be a tmpfs, and not something permanent anyway, having bootlogd store the output it's meant to be logging, and dump it to /var/log when it's ready seems fine anyway. Adding that to init would even seem pretty straightforward, along with an addition to telinit to, uh, tell init to dump the logs somewhere. Sorry for the confusion. bootchartd is a shell script collecting information into a tmpfs area during boot, and packing it together in /var/log/ when the boot is over. It have no other way to store the stats before other file systems are available but to put it in a tmpfs area. Sure, those were mentioned above (/ local, /var an NFS mount, or if /var is a tmpfs or similar, / and /var local). In LTSP, / is a readonly NFS mount (and /var is on /, also readonly). Because of this, I did not consider / local and your description did not match my understanding of LTSP. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
Raphael Hertzog [EMAIL PROTECTED] writes: On Sun, Dec 18, 2005 at 12:34:56PM +0100, Gürkan Sengün wrote: Hi I've run some scripts to find out the size of binary pakcages in debian and how theycould be made smaller, here's the results: http://www.linuks.mine.nu/sizematters/ FWIW : https://wiki.ubuntu.com/Dpkg7Zip Actual maintainer of dpkg is evaluating the possibility to use 7zip. Even if the decision of using 7zip by default is far from being taken, it looks likely that dpkg will at least start supporting it. Cheers, It can't be the default unless stable dpkg has support for installing such debs. That means not before etch+1 or more likely etch+2. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run
[EMAIL PROTECTED] [EMAIL PROTECTED] writes: Peter Samuelson wrote: Given the need, and now the reality, of /run, is there any need for a separate /var/run? Need is probably too strong, but it's certainly convenient if we don't have to change the way we currently use /var/run/. How about mount --bind /run /var/run? I think we should allow/plan for that, i.e. forbid name conflicts between the two and such. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
On 12/21/05, Goswin von Brederlow [EMAIL PROTECTED] wrote: uncompressor file.tar.whatever | tar -x $ uncompressor -bash: uncompressor: command not found This solution doesn't look usable in scripts and user have to use a more complex syntax.
Re: switching to vim-tiny for standard vi?
Hi, While I'm a addicted vim user, the build-dependencies of vim(-tiny) is a bit scary for a base package. While we do not have requirements of base packages of being easily buildable, changing to vim-tiny will make bootstrapping a basic debian system again a little bit harder. nvi: Build-Depends: debhelper, libncurses5-dev vs vim-tiny: Build-Depends: debhelper (= 4.2.21), dpkg ( 1.7.0), bzip2, perl (= 5.6), libgpmg1-dev [!hurd-i386] | not+linux-gnu, libperl-dev (= 5.6), tcl8.4-dev [!hurd-i386] | tcl8.3-dev [!hurd-i386], python-dev, libncurses5-dev, ruby, ruby1.8-dev | ruby-dev, libgtk2.0-dev (= 2.2) | libgtk1.2-dev, libgnomeui-dev [!hurd-i386], lesstif2-dev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: apt PARALLELISM
Michelle Konzack [EMAIL PROTECTED] writes: Am 2005-12-12 13:23:01, schrieb Goswin von Brederlow: Actualy one thing apt could do: [EMAIL PROTECTED]:~% host security.debian.org security.debian.org A 82.94.249.158 security.debian.org A 128.101.80.133 security.debian.org A 194.109.137.218 Why not open 3 connections one to each host? I have tested the Mirrors and there is a problem with my 8 MBit ADSL. Singel download or parallel I get all the time the same speed. 7616 kBitor780 kByte/s Who need PARALELISM and who has a bandwidth of more then 8 MBit? I have 10240kBit downstream and get way less from security.debian.org. Especialy when there is a security release of X or latex. I have written a small apt-get wraper which use --print-uris and have piped it to the same number of wget processes backgrounded and disowned it... (it download all the files into /var/cache/apt/archives and after this I install from this directory. Same resultat. No performance plus. No chance for the hell! - The Debian servers are faster. If there is a slowdown it usualy is somewhere between debian and the user. Connection speeds to various servers might widely vary. Greetings Michelle MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: apt PARALLELISM
Michelle Konzack [EMAIL PROTECTED] writes: Am 2005-12-06 09:53:43, schrieb Ivan Adams: Hi again, in my case: I have slow internet connection. BUT I have friends with the same ^^^ connection in my local area network, who have apt-proxy. My goal is: When I need to install new system (Debian) on new user, or dist-upgrade on entire system, I need the unstable packets from site. In this case I need to wait some HOURS. If apt have *PARALLELISM* , I could use my connection and at the same time the connections of apt-proxy. In that case I will download the packets twice (or more) faster. ??? Do you have two Dial-In line? 1) You = Internet = Debian-Server 2) You = your friends apt-proxy More like ppp0 and eth0 I guess. You should think about using cron-apt to download debian updates during the night when you sleep (download, not install). That way the apt-proxy will always have all your packages ready when you decide to actualy install. You might also switch to squid and setup your friends squid as peer so they share the downloads they have. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: apt PARALLELISM
On 12/21/05, Goswin von Brederlow [EMAIL PROTECTED] wrote: Who need PARALELISM and who has a bandwidth of more then 8 MBit? I have 10240kBit downstream and get way less from security.debian.org. Especialy when there is a security release of X or latex. But parallel downloads won't solve that.
Re: Thoughts on Debian quality, including automated testing
* Thomas Hood [EMAIL PROTECTED] [2005:12:21 12:23 +0100]: I don't think that it is ridiculous to require that every package have a team behind it---i.e., at least two maintainers. First, if someone can't find ONE other person willing to be named as a co-maintainer of a given package then I would seriously doubt that that package (or that person) is an asset to Debian. I disagree. There are plenty of people who are maintaining packages alone that are doing an excellent job, they just don't happen to get shout-outs on the -qa list. Quite a lot of people in Debian are responsible enough to go it alone as well as to know when it's time to pass the torch. Forcing team maintenance on people would result in very few technical enhancements for such maintainers and would probably engender quite a bit of resentment (nevermind the fact that they'd likely resist altogether). It just seems to me like telling responsible DDs who've done a stellar job that they need a babysitter is a bit... insulting. Second, putting packages in the custody of a team makes it easy for a tired maintainer to relinquish control. Is that always true though? For example, I can see how that could benefit some of the more isolated members of Debian who aren't in constant communication with other developers, but the ones who are -- half of the time they just say anyone want this package? and that's about all there is to it. Team maintainership is working very well for some other distributions. That may be true, but it's not a good argument for forcing such a situation in Debian. -- off the chain like a rebellious guanine nucleotide -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
Olaf van der Spek [EMAIL PROTECTED] writes: On 12/21/05, Goswin von Brederlow [EMAIL PROTECTED] wrote: uncompressor file.tar.whatever | tar -x $ uncompressor -bash: uncompressor: command not found This solution doesn't look usable in scripts and user have to use a more complex syntax. You have to replace uncompressor with whatever tool is the right to uncompress the format. Just like you have to use -z or -j depending on gzip or bzip2 compression. For a generic uncompressor the mailcap programs are probably best suited for adopting it. E.g. add an action dump to run-mailcap that outputs the uncompressed data. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
On Wed, 2005-12-21 at 16:12 +0100, Goswin von Brederlow wrote: Steinar H. Gunderson [EMAIL PROTECTED] writes: On Sun, Dec 18, 2005 at 12:34:56PM +0100, Gürkan Sengün wrote: [snip] The transition itself would go completly unadministered. Once dpkg is switched to default to a different compression all freshly build packages use it and the archive transitions itself over time. Because a .deb would know whether it is compressed or not, and dpkg would dynamically determine whether it needed to decompress or not? -- - Ron Johnson, Jr. Jefferson, LA USA A man can't be too careful in the choice of his enemies. Oscar Wilde
Re: Thoughts on Debian quality, including automated testing
[Thomas Hood] I don't think that it is ridiculous to require that every package have a team behind it---i.e., at least two maintainers. First, if someone can't find ONE other person willing to be named as a co-maintainer of a given package then I would seriously doubt that that package (or that person) is an asset to Debian. [Adrian von Bidder] The problem is: do you honestly want to force people who don't want to have comaintainers on their packages to leave Debian? I'm having a hard time trying to understand the thinking of people refusing to co-maintain packages, but am aware that there are a few of those. These seem to be the same with issues regarding cooperating with the rest of the project as well, so yes, I guess I am am willing to force them to leave Debian. But perhaps we should not do this. Perhaps the co-maintainer requirement should only be implemented on high-profile packages? Perhaps something like all packages used by more then 10% of the debian population (as measured using popularity-contest) should be required to have co-maintainers? This way the people with co-maintainer issues can do the little used packages, and the more used (and presumably more important) packages will have a team of people working on them. At the very minimum, I believe all base packages (those installed by debootstrap by default) should have co-maintainers. If the package is important for Debian, it is too important to leave in the hand of only one person. People go tired, get occupied with real life or are run over by a bus. The maintenence of important packages in Debian should not stop when any of these things happen, and because of this I seriously believe all packages in Debian should have co-maintainers. Or do you want people who really don't want to have comaintainers for their packages to put somebody in just so they are following the rules, while they regard anything done by this comaintainer on his own like they would regard an intrusive NMU? That would not be co-maintenence, but lying to the project about how they follow the project rules. Should we trust these people to maintain packages in Debian? And yes, we would probably need to change the constitution to make this happen, so it will take a while. :/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Thoughts on Debian quality, including automated testing
On Wed, 2005-12-21 at 17:08 +0100, Petter Reinholdtsen wrote: At the very minimum, I believe all base packages (those installed by debootstrap by default) should have co-maintainers. This sounds like a good compromise between the two sides of this discussion. Thijs signature.asc Description: This is a digitally signed message part
Re: Thoughts on Debian quality, including automated testing
On Wed, Dec 21, 2005 at 11:00:15AM -0500, Erinn Clark wrote: * Thomas Hood [EMAIL PROTECTED] [2005:12:21 12:23 +0100]: Team maintainership is working very well for some other distributions. That may be true, but it's not a good argument for forcing such a situation in Debian. I agree that we shouldn't force teams on anyone, but I'd like to see more large-scale teams encompassing loosely connected smaller packages[0]. If, for no other reason, than for developers to claim ownership of (and by extension responsibility for) the whole project rather than their little package feifdom. It might help overcome the sense that key people aren't communicating, as well as provide more easy avenues for NM's to get involved that don't simply involve packaging some crap little script from freshmeat. - David Nusinow [0] A Debian Games team would be a perfect hypothetical example of this. So is the Debian libruby extras team I helped create. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Thoughts on Debian quality, including automated testing
I wrote: I don't think that it is ridiculous to require that every package have a team behind it---i.e., at least two maintainers. First, if someone can't find ONE other person willing to be named as a co-maintainer of a given package then I would seriously doubt that that package (or that person) is an asset to Debian. Erinn Clark wrote: There are plenty of people who are maintaining packages alone that are doing an excellent job True. However, the issue in question is whether or not it would be better if they maintained in teams. Forcing team maintenance on people would result in very few technical enhancements for such maintainers How do you know? I would expect most packages to benefit. Every person brings different expertise to the table. It just seems to me like telling responsible DDs who've done a stellar job that they need a babysitter is a bit... insulting. This is not a fair characterization of what the introduction of a two-maintainer rule would be doing. No one should be insulted by general rule changes designed to make Debian work better. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Thoughts on Debian quality, including automated testing
True. However, the issue in question is whether or not it would be better if they maintained in teams. I imagine that it would not be better. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Thoughts on Debian quality, including automated testing
* Thomas Hood [EMAIL PROTECTED] [2005:12:21 17:32 +0100]: Erinn Clark wrote: There are plenty of people who are maintaining packages alone that are doing an excellent job True. However, the issue in question is whether or not it would be better if they maintained in teams. Forcing team maintenance on people would result in very few technical enhancements for such maintainers How do you know? I would expect most packages to benefit. Every person brings different expertise to the table. For maintainers who are doing a lot of good work, there's simply not enough to justify more people. Once there's already a certain level of efficiency, adding another person is not going to increase it, and will likely decrease it. I can't see the point of enforcing this as a rule, which, luckily, was not proposed by Lars. It just seems to me like telling responsible DDs who've done a stellar job that they need a babysitter is a bit... insulting. This is not a fair characterization of what the introduction of a two-maintainer rule would be doing. No one should be insulted by general rule changes designed to make Debian work better. Bureaucracy is often designed to do lots of things better and it often doesn't achieve them. It creates needless hassle, more 'paperwork', and has very few benefits besides making people feel like they've done something useful when they haven't. Of course, we're both starting from entirely different premises (yours that all packages are better maintained by more than one person, mine that this is not universally true and can be worse in some cases) so there's probably not a lot of wiggle room for agreement here. -- off the chain like a rebellious guanine nucleotide -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Thoughts on Debian quality, including automated testing
On Wed, Dec 21, 2005 at 05:32:21PM +0100, Thomas Hood wrote: This is not a fair characterization of what the introduction of a two-maintainer rule would be doing. No one should be insulted by general rule changes designed to make Debian work better. I think a two-maintainer rule is a bit artificial and perhaps the wrong solution. Taking a cue from teams that work well in Debian (Gnome, d-i, etc) indicates that somewhat larger teams with a common goal and a fairly large set of packages under their umbrella will work in practice. This provides the opportunity for autonomy (someone can take ownership of a package within the team) but also a cohesiveness and a known set of people to turn to when you're in need. It's pretty simple to found such a team too. All it takes is some interested people and an alioth project. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
Goswin von Brederlow [EMAIL PROTECTED] writes: You just try to make a point out of buildd.net not having a direct source link which is completly irelevant imho. Hey, I don't care if there's a direct link or not. I care if the source is available for anyone to go download. If it's available from some obscure place, great, that's new information in this thread. Where is it? I'll go link to it and make it less obscure and then we can have more interesting discussions. If you (as in buildd.d.o) want to add a source link then do it. That is debians decision ultimately. So far Debian hasn't made that addition and Ingo didn't want to make it. That is your/his choice and changes nothing on the freeness of the software. It just changes the propagation medium. This may sound heretical to you, but I don't consider software to be DFSG-free unless there's actually a copy somewhere that people can get to. If the source is unavailable, the software isn't free, regardless of what theoretical license is attached to the theoretical source that no one has access to. If you only want to distribute the software via e-mail, fine, send me a copy of it, I'll put it up on my public web site, and then it will be free. And then one could have a more meaningful conversation about where it should fit into buildd.debian.org. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Thoughts on Debian quality, including automated testing
Thijs Kinkhorst [EMAIL PROTECTED] writes: On Wed, 2005-12-21 at 17:08 +0100, Petter Reinholdtsen wrote: At the very minimum, I believe all base packages (those installed by debootstrap by default) should have co-maintainers. This sounds like a good compromise between the two sides of this discussion. packages.qa.debian.org already bugs you to find a co-maintainer if the package is priority standard or higher. It's a good hint but not mandatory, which feels about right to me. I don't really understand what requiring a package to have a co-maintainer looks like. Do you remove the package from Debian if there's no co-maintainer? Surely not for base packages. Do you force a co-maintainer on the package somehow? How? What if someone is just listed as a co-maintainer but never does anything? Also, I think this is a little silly for small packages. My experience with this sort of volunteer work in other areas is that if one person does nearly all the work on a regular basis, you're not gaining that much by having a backup. The person who is theoretically the backup isn't up to speed on the package anyway and is going to be starting roughly as cold as any other random person out there. And there simply isn't enough work for two people for a lot of packages. I think that the energy used to define these sorts of procedures is probably better used finding a package with a large bug count and volunteering to work with the maintainer to try to get the bug count down. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#279983: general: /dev/cdrom does not work.
Package: general Followup-For: Bug #279983 The cdrom doesnot work too. One of them randomly works. This happend with two computers with about same debain version, but different cdrom boxes. chypre:~# mount /cdrom/ mount: wrong fs type, bad option, bad superblock on /dev/sr0, missing codepage or other error In some cases useful info is found in syslog - try dmesg | tail or so chypre:~# dmesg | tail sr0: rw=0, want=68, limit=4 isofs_fill_super: bread failed, dev=sr0, iso_blknum=16, block=16 SMB connection re-established (-5) SMB connection re-established (-5) attempt to access beyond end of device sr0: rw=0, want=68, limit=4 isofs_fill_super: bread failed, dev=sr0, iso_blknum=16, block=16 attempt to access beyond end of device sr0: rw=0, want=68, limit=4 isofs_fill_super: bread failed, dev=sr0, iso_blknum=16, block=16 chypre:~# cat /etc/fstab | grep cdrom /dev/sr0/cdrom iso9660 ro,user,noauto 0 0 chypre:~# ls -l /dev/cdrom lrwxrwxrwx 1 root root 4 2005-12-09 19:06 /dev/cdrom - scd0 chypre:~# mount /dev/scd0 /cdrom/ mount: you must specify the filesystem type chypre:~# sudo mount -t iso9660 /dev/scd0 /cdrom/ mount: block device /dev/scd0 is write-protected, mounting read-only mount: wrong fs type, bad option, bad superblock on /dev/scd0, missing codepage or other error In some cases useful info is found in syslog - try dmesg | tail or so chypre:~# ls /dev/disk/* /dev/disk/by-id: ata-Maxtor_6Y080L0_Y2LT5GPEata-Maxtor_6Y080L0_Y2LT5GPE-part2 ata-Maxtor_6Y080L0_Y2LT5GPE-part4 ata-Maxtor_6Y080L0_Y2LT5GPE-part6 ata-Maxtor_6Y080L0_Y2LT5GPE-part1 ata-Maxtor_6Y080L0_Y2LT5GPE-part3 ata-Maxtor_6Y080L0_Y2LT5GPE-part5 ata-Maxtor_6Y080L0_Y2LT5GPE-part7 /dev/disk/by-label: DONNEESWIN /dev/disk/by-path: pci-:00:1f.1-ide-0:0pci-:00:1f.1-ide-0:0-part2 pci-:00:1f.1-ide-0:0-part4 pci-:00:1f.1-ide-0:0-part6 pci-:00:1f.1-ide-0:0-part1 pci-:00:1f.1-ide-0:0-part3 pci-:00:1f.1-ide-0:0-part5 pci-:00:1f.1-ide-0:0-part7 /dev/disk/by-uuid: 40447DC2447DBB6C F4DF-2018 f533c798-c5a0-4670-a10b-a5b7f88715a0 6b7529e3-1f18-4f28-a04d-a06ff4db5d57 f501c01a-7fbe-4dcb-bed1-8cd737c930ae chypre:~# cat /proc/scsi/sg/device_strs TSSTcorpDVD-ROM TS-H352ATS03 chypre:~# cat /proc/ide/hdc/model TSSTcorpDVD-ROM TS-H352A chypre:~# cat /proc/ide/hdc/driver ide-scsi version 0.92 cypre:~# cat /proc/scsi/scsi Attached devices: Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: TSSTcorp Model: DVD-ROM TS-H352A Rev: TS03 Type: CD-ROM ANSI SCSI revision: 02 chypre:~# cat /proc/scsi/sg/version 30533 3.5.33 [20050328] chypre:~# cat /proc/scsi/sg/devices 0 0 0 0 5 1 5 0 1 chypre:~# cat /proc/scsi/sg/device_hdr hostchanid lun typeopens qdepth busyonline chypre:~# cat /proc/scsi/sg/device_hdr chypre:~# ls -F /dev adsp mixer1ptyc0 ptyec ptyr8 ptyu4 ptyx0 ptyzc tty18 tty58 ttyc2 ttyee ttyra ttys4 ttyu2 ttywe ttyza agpgart net/ ptyc1 ptyed ptyr9 ptyu5 ptyx1 ptyzd tty19 tty59 ttyc3 ttyef ttyrb ttyS4 ttyu3 ttywf ttyzb audio null ptyc2 ptyee ptyra ptyu6 ptyx2 ptyze tty2 tty6 ttyc4 ttyp0 ttyrc ttyS40 ttyu4 ttyx0 ttyzc audio1parport0 ptyc3 ptyef ptyrb ptyu7 ptyx3 ptyzf tty20 tty60 ttyc5 ttyp1 ttyrd ttyS41 ttyu5 ttyx1 ttyzd cdrom@parport1 ptyc4 ptyp0 ptyrc ptyu8 ptyx4 ram0tty21 tty61 ttyc6 ttyp2 ttyre ttyS42 ttyu6 ttyx2 ttyze console parport2 ptyc5 ptyp1 ptyrd ptyu9 ptyx5 ram1tty22 tty62 ttyc7 ttyp3 ttyrf ttyS43 ttyu7 ttyx3 ttyzf core@ parport3 ptyc6 ptyp2 ptyre ptyua ptyx6 ram10 tty23 tty63 ttyc8 ttyp4 ttys0 ttyS44 ttyu8 ttyx4 urandom disk/ port ptyc7 ptyp3 ptyrf ptyub ptyx7 ram11 tty24 tty7 ttyc9 ttyp5 ttyS0 ttyS45 ttyu9 ttyx5 vcs dsp ppp ptyc8 ptyp4 ptys0 ptyuc ptyx8 ram12 tty25 tty8 ttyca ttyp6 ttys1 ttyS46 ttyua ttyx6 vcs1 dsp1 psaux ptyc9 ptyp5 ptys1 ptyud ptyx9 ram13 tty26 tty9 ttycb ttyp7 ttyS1 ttyS47 ttyub ttyx7 vcs2 dvd@ ptmx ptyca ptyp6 ptys2 ptyue ptyxa ram14 tty27 ttya0 ttycc ttyp8 ttyS10 ttys5 ttyuc ttyx8 vcs3 fd@ pts/ ptycb ptyp7 ptys3 ptyuf ptyxb ram15 tty28 ttya1 ttycd ttyp9 ttyS11 ttyS5 ttyud ttyx9 vcs4 fd0 ptya0 ptycc ptyp8 ptys4 ptyv0 ptyxc ram2tty29 ttya2 ttyce ttypa ttyS12 ttys6 ttyue ttyxa vcs5 full ptya1 ptycd ptyp9 ptys5 ptyv1 ptyxd ram3tty3 ttya3 ttycf ttypb ttyS13 ttyS6 ttyuf ttyxb vcs6 hda ptya2 ptyce ptypa ptys6 ptyv2 ptyxe ram4tty30 ttya4 ttyd0 ttypc ttyS14 ttys7 ttyv0 ttyxc vcs7 hda1 ptya3 ptycf ptypb ptys7 ptyv3 ptyxf ram5
Re: Thoughts on Debian quality, including automated testing
On Wed, Dec 21, 2005 at 02:07:30AM +0200, Lars Wirzenius wrote: Several ideas have been floating around for years on how to improve this situation, of which I'd like to mention three. While I've here used the number of bugs as the measure of a package's quality, the same ideas might help with other aspects, like getting new upstream versions packaged soon after they're released. * Team maintenance. If a package is maintained by a team, there are more people sharing the work. When a team works well, more people look at the package, and finding and fixing problems is more effective. There is less work per person, so things don't lag as much. A well-working team is a good thing. As an example, the Debian GNOME team seems to work really well. Transitions to the next upstream version happen quite smoothly these days. OTOH, sometimes team maintenance means no one takes responsibility for the package. I've dealt with release critical bugs on packages where the Maintainer field pointed to a team mailing list, there were several Uploaders listed for the package, and the bug sat unattended for well over a month for no apparent reason. I've also *been* part of maintainer teams where all the members of the team were busy people, and bugs tended to linger because they were somebody else's problem. Anyway, I agree that team maintenance can be a force for good. I also agree with the rest of your mail, including the call for a more proactive QA team. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
ITP: thunar -- Xfce File Manager
Package: wnpp Owner: Debian Xfce Maintainers [EMAIL PROTECTED] Severity: wishlist * Package name: thunar Version : 0.1.4svn+r1885 Upstream Author : Benedikt Meurer [EMAIL PROTECTED] * URL : http://thunar.xfce.org * License : GPL Description : Xfce File Manager Thunar is the file manager designed to be the default one for Xfce 4.4. It's GTK based and integrates well with Xfce, but can be used anywhere. It's lightweight and powerful. This version is a pre-alpha release, and thus may contains bugs, and may not provide all the features of a file manager. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-rc5 Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 (charmap=ISO-8859-15) -- Yves-Alexis Perez signature.asc Description: OpenPGP digital signature
ITP: orage -- Calendar for Xfce Desktop Environment
Package: wnpp Owner: Debian Xfce Maintainers [EMAIL PROTECTED] Severity: wishlist * Package name: orage Version : 4.3.1.22svn Upstream Author : Mickaël Graf [EMAIL PROTECTED] * URL : http://foo-projects.org/~korbinus/orage/ * License : GPL Description : Calendar for Xfce Desktop Environment Orage is a calendar which integrates nicely in Xfce, is highly configurable and support alerts based on dates. It stores its own data in iCal format, can import and export calendars based on this format. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-rc5 Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 (charmap=ISO-8859-15) -- Yves-Alexis Perez signature.asc Description: OpenPGP digital signature
Re: Thoughts on Debian quality, including automated testing
Em Qua, 2005-12-21 às 14:34 +, Matthew Garrett escreveu: I think I've said this before, but I have no objections to anyone uploading any of my packages. I'd be even happier if anyone who did so was willing to enter into some sort of reciprocal agreement. So do I, but I would be really happy if the uploader knows how I maintain the packages (I mean, using CVS, SVN or such) and cooperate using such tools. Maybe it would be interesting to have some information in the package saying how the package is managed and the preferrable way of doing an NMU (I actually, think that it's desirable to self-include in the Uploaders field, to acquire responsability also)... daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Thoughts on Debian quality, including automated testing
Erinn Clark wrote: For maintainers who are doing a lot of good work, there's simply not enough to justify more people. Once there's already a certain level of efficiency, adding another person is not going to increase it, and will likely decrease it. I can't see the point of enforcing this as a rule, There is a point if it helps more than it hurts. That is how rules have to be judged. Now, you might say that rules are stupid and those people who need help should just go and get it. But experience has shown that, too often, they don't. How much would this rule hurt those lone ranger maintainers you are talking about, the ones who package everything perfectly and cannot possibly do any better? It turns out that there is no need for them to be hurt at all. Lone can carry on working as before and find a co-maintainer who won't get in his way. But when Lone falls off his horse he'll be glad that Tonto is nearby. In other words, this rule can have only positive effects. :) This is not a fair characterization of what the introduction of a two-maintainer rule would be doing. No one should be insulted by general rule changes designed to make Debian work better. Bureaucracy is often designed to do lots of things better and it often doesn't achieve them. It creates needless hassle, more 'paperwork', and has very few benefits besides making people feel like they've done something useful when they haven't. You are saying that requiring people to find co-maintainers is bureaucracy? Someone I know well recently got co-maintainers for three of his packages by posting a single message to debian-devel. That's less of a burden than that imposed by many another Debian rule. Fortunately for your position, it probably won't take arguments to kill this idea. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: switching to vim-tiny for standard vi?
Jeroen van Wolffelaar wrote: I don't think it's easily possible to count on people contributing to this thread to be representative, but I do think (b) is certainly less than it seems: Even vim-tiny would I think be liked more than nvi -- So do I. As others have said, vim users can run vim-tiny and type text without constantly having to delete their acciental hjkl and strangely uppercased characters. Compared to that, not having syntax highlighting when I run visudo is pretty minor. -- see shy jo signature.asc Description: Digital signature
Re: buildd administration
On Wed, Dec 21, 2005 at 10:12:56AM -0800, Russ Allbery wrote: This may sound heretical to you, but I don't consider software to be DFSG-free unless there's actually a copy somewhere that people can get to. If the source is unavailable, the software isn't free, regardless of what theoretical license is attached to the theoretical source that no one has access to. http://www.buildd.net/index.html - at the end of the page it states: This service is donated to the Developers of the Debian Project by Ingo Juergensmann. It's a service, not a software. So please stop the discussion about redistributing a *software*. If you don't like it, don't use it. It's that simple. Thanks. -- Ciao...//Fon: 0381-2744150 Ingo \X/ SIP: [EMAIL PROTECTED] gpg pubkey: http://www.juergensmann.de/ij/public_key.asc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Thoughts on Debian quality, including automated testing
David Nusinow wrote: I agree that we shouldn't force teams on anyone, but I'd like to see more large-scale teams encompassing loosely connected smaller packages[0]. If, for no other reason, than for developers to claim ownership of (and by extension responsibility for) the whole project rather than their little package feifdom. It might help overcome the sense that key people aren't communicating, as well as provide more easy avenues for NM's to get involved that don't simply involve packaging some crap little script from freshmeat. - David Nusinow [0] A Debian Games team would be a perfect hypothetical example of this. So is the Debian libruby extras team I helped create. That's a terrific idea, and I think a games team is, besides being a good eample, worth doing. -- see shy jo signature.asc Description: Digital signature
Experiment: poll on switching to vim-tiny for standard vi?
(Please followup to -project if you're replying on the subject of holding polls like this -- the discussion on holding polls is not technical, so does not belong to -devel. For opinions on nvi versus vim, please reply elsewhere in the current thread, this subthread isn't the place for it) For the full discussion leading up to this, please start at http://lists.debian.org/debian-devel/2005/12/msg00796.html To repeat myself from http://lists.debian.org/debian-devel/2005/12/msg01066.html: On Wed, Dec 21, 2005 at 03:45:51PM +0100, Jeroen van Wolffelaar wrote: ] I don't think it's easily possible to count on people contributing to ] this thread to be representative, [...] Looking at popcon, vim has ] about twice the amount of users as nvi, while nvi is the default vi, ] and vim is merely optional. ] ] I think this is an excellent question to phrase with a few options in a ] devotee-poll, and have people vote on it -- results being purely ] advisory, the poll just being informative, and any results updated live, ] rather than only after a delay. I think it'd be good to representative ] polls on a reasonably regularly basis -- close to the same ] representativeness, and stil much much more lighter than a GR, so easier ] to just do when some people feel a more clear idea of what the average ] DD thinks is needed than what one can gather from a mailinglist thread. Because this is certainly not the first time I was curious on the opinion of the so called Silent majority (if such beast exists at all), I decided to simply try out this idea. Therefore, I've set up devotee (thanks to Manoj for writing it!) on [EMAIL PROTECTED], with results updated near realtime on http://master.debian.org/~jeroen/polls/. To participate in the context of the nvi vs vim-tiny discussion, please fill in the below ballot, sign it, and submit it to [EMAIL PROTECTED] It's currently only available to DD's, for practical reasons more than for any fundamental reason -- being a poll, I do think that opinions of non-DD's is certainly good to have too, possibly simply both tallied for DD only and for 'all'. This polling thingy works just like a real vote, except: - It is a poll, a query to the opinion of people. - As such, results will be public, - and updated in near realtime - There is no real deadline per se, as this is not intended as a decision making instrument, at best a decision-making support instrument. Some polls will simply stop being relevant at some point, or maybe will remain of continued relevance. I'm curious how this pans out. I intend to launch more polls when I get good idea's to hold one, so let me know if you have one. BALLOT (Also found on http://master.debian.org/~jeroen/polls/vi/ballot) This is an informal poll, conducted with DeVoteE much like the way GR's and elections are done. Do not erase anything between the lines below and do not change the choice names. Please fill in, and send to [EMAIL PROTECTED] - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- f811dfe7-4e13-423c-8062-8dae621caf0c [ ] Choice 1: Keep nvi as the default vi in base [ ] Choice 2: Replace nvi by vim-tiny [ ] Choice 3: Further discussion - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- /BALLOT --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Thoughts on Debian quality, including automated testing
On Wednesday 21 December 2005 13:33, David Nusinow wrote: I agree that we shouldn't force teams on anyone, but I'd like to see more large-scale teams encompassing loosely connected smaller packages This will also bring the side effect of making it easier for non-DDs: Now instead of finding a sponsor for my package, I'd have the chance to talk directly to a group related to my package, and (ideally) get a quicker response. -- Felipe Sateler pgpzQwa1hNB8T.pgp Description: PGP signature
Re: c2a transition: libraries still needing transition
Nathanael Nerode [EMAIL PROTECTED] writes: aqsis It would be nice if whoever uploads this could also address #324025 (64-bit FTBFS, patch available). It would be very nice to finish these off. Once all these libraries are transitioned, the remaining C++ programs using the old ABI can be queued for automatic binNMUs by the release team, so these are the only source uploads still needed just for the transition (not including uploads to fix FTBFSes, RC bugs, etc.) It's not quite that simple, as some applications will also need sourceful uploads because tight dependencies between binary-all and binary-arch packages yielded broken binNMUs: cinepaint kgeography pingus (maybe others, those are just the ones I've run into that haven't been fixed yet). Surprisingly, only pingus has a bug open about the matter (#342231). -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: udev event completion order
I demand that Alexander E. Patrakov may or may not have written... Kay Sievers wrote: There is also the plan to do parallel device probing inside the kernel some day, that will make the situation of relying on kernel names even more fragile. Right, this means that the way of passing root=/dev/hdc2 will no longer work because /dev/hdc will sometimes become /dev/hde. I'd call that broken, just as I consider udev (076) to be broken given that it breaks expectations wrt device naming. (Here, it swapped the names of the DVD drives (drivers are built-in) and sound devices (drivers are modular).) If the parallel probing is done such that the naming remains predicatable, that's good. Whether it's faster doesn't matter - userspace isn't affected and doesn't require modification, and that's a good thing. If you are serious about going to implement this, first add (to linux-2.6.16?) a boot-time warning if the kernel is booting without initramfs. The warning should say something like this: WARNING: you have booted the kernel without initramfs and passed an explicit root device name. I see no problem with booting like that. I've always used the root device name; why should I forced to change should a kernel upgrade become necessary just because of some should-be-in-2.7.x [1] breakage? This will no longer work when the kernel will probe devices in parallel (i.e., since linux-2.6.??) because device ordering will be random. Please create an initramfs that mounts the root device using some stable attribute, like label or UUID. That'd be stable and duplicatable, and I fully expect somebody to run into that sooner or later... [1] Heated discussion, anybody? ;-) -- | Darren Salt | nr. Ashington, | d youmustbejoking,demon,co,uk | Debian, | Northumberland | s zap,tartarus,org | RISC OS | Toon Army | @ | Kill all extremists! I've got 256K of RAM, so why can't I run Windows 3.1? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
On Mon, Dec 19, 2005 at 09:56:27AM +0100, Olaf van der Spek wrote: On 12/19/05, Andrew Suffield [EMAIL PROTECTED] wrote: On Sun, Dec 18, 2005 at 08:27:36PM +0100, Florian Weimer wrote: * Steinar H. Gunderson: My comments are about the same as on IRC: - Disk space is cheap, bandwidth is cheap. Depends. Decent IP service costs a few EUR per gigabyte in most parts of the world. I wish we could get it that cheap for my day job. What we have to pay to get useful bandwidth has more zeros in it. Are you paying 10 $/gb? Heck yes, you can't get it that cheap unless you have no SLA (or one of those insulting SLAs that come with residential service, claiming that it doesn't have to work at all). And you can't get that at all on a pipe of any significant size (unless you're big enough to work out a peering agreement). We pay per month though, not per byte. Where is it that expensive? UK. As a general rule, UK bandwidth prices are roughly five to ten times those of equivalent service in other EU countries. Not that you can get equivalent service. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: /run vs /var/run
In article [EMAIL PROTECTED] you wrote: aren't really there anyway, I have never heard of non-swappable in-memory filesystems. the ram disks, afaik. Those are: Solaris, *BSD and The Hurd. Solaris and all of the BSDs can do VM-based filesystems that are nearly identical to tmpfs. I don't know about The Hurd. tmpfs is old in solaris and pretty new in Linux. Gruss Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Thoughts on Debian quality, including automated testing
ke, 2005-12-21 kello 14:19 +, Roger Leigh kirjoitti: The difference for a minimal chroot is not too great. The main advantage of schroot LVM snapshotting is that the time is constant irrespective of the size of the LV (it's copy-on-write), whereas for tar it is linear. For slow machines and older architectures, this is an advantage. Right. I'll postpone adding support for this until later, then. For the time being, I assume piuparts will mostly be run on relatively fast machines. Once slow machines become more relevant for piuparts, I'll return to this issue and will look at schroot in more detail. Thanks for pointing it out, I didn't know about it before. (Likewise, UML/Xen support will probably happen only later.) -- Never underestimate the power of a small tactical Lisp interpreter. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Experiment: poll on switching to vim-tiny for standard vi?
On Wed, Dec 21, 2005 at 09:14:16PM +0100, Jeroen van Wolffelaar wrote: (Please followup to -project if you're replying on the subject of Because this is certainly not the first time I was curious on the opinion of the so called Silent majority (if such beast exists at all), I decided to simply try out this idea. Therefore, I've set I have no sympathy for the notion of a silent majority. If you have an opinion, speak it. What I believe we we really have, most of the time, is a vocal minority trying to inflate their ranks with a non-existant silent majority. up devotee (thanks to Manoj for writing it!) on [EMAIL PROTECTED], with results updated near realtime on http://master.debian.org/~jeroen/polls/. To participate in the context of the nvi vs vim-tiny discussion, please fill in the below ballot, sign it, and submit it to [EMAIL PROTECTED] It's currently only available to DD's, for practical reasons more than for any fundamental reason -- being a poll, I do think that opinions of non-DD's is certainly good to have too, possibly simply both tallied for DD only and for 'all'. Voting on decisions is always disturbing to me: it always seems to be small steps away from the point where decisions are made based on uninformed popularity rather than technical merit. Too often, in various contexts, I've seen people who had an ill-formed opinion and losing an argument demand a vote, in the hopes that there will be more people who will vote for that opinion based on what seems obvious than those spending the time to understand the issue. This remains a problem regardless of how loudly one asserts that a poll is not a decision making instrument. That's the general case, of course--this issue is simple enough that it could be summarized neatly within the poll, I think. I have to wonder how many people will vote for nvi bacause nvi is more like regular vi than vim. This is important even for an informal poll; a vote is useless if it's heavily skewed, whether it's a poll or a GR. - vim-tiny is not much bigger than nvi (numbers?) - even vim-tiny is much preferable to vim users over nvi, even without vim-runtime - vim can behave just like old vi (as nvi does), and will do so when invoked as vi I think a poll might be a lot more useful if it was required that people had to offer, in a sentence or two, their rationale for their vote. If you can't even express in brief terms why you think nvi or vim should be the default, then your opinion is not interesting; and it would let people get an idea if a lot of people are voting based on rationale that has been discussed and disproven (eg. vim is huge and vim differs too much from vi). (I wish people had to write a few paragraphs justifying their votes for government elections. Votes in essay format. One can dream ...) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Thoughts on Debian quality, including automated testing
On Wed, Dec 21, 2005 at 12:23:32PM +0100, Thomas Hood wrote: I would support requiring team maintainership because TM will be beneficial in almost all cases and making it a requirement it cuts off a lot of useless discussion. Cute theory, gaping hole. Making a group of people responsible for something, rather than a single person, means that they can all spend all their time passing the buck and hoping that one of the others takes care of it, with the result that nobody does. Debian is a great example of this problem in practice. Most of the more significant teams show this problem to one degree or another. Common places where it appears are ftp-master, debian-admin, and scud. You get a lot of people able to meddle with something but none of them responsible for actually seeing that it gets done - and so some of it just doesn't get done. The NEW queue used to get backed up all the time for exactly this reason. The problem went away when one person became responsible for processing it. Replacing teams with individuals usually works better, where it's actually possible. When it isn't, you probably need to break up the task more until it is. We would all be much worse off with the abolition of individual responsibility. If I were feeling in a conspiracy-theorist mood then I'd suggest that those who are promoting team maintainance are trying to gain power while evading responsibility. But frankly I think that's giving them too much credit. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: apt PARALLELISM
On Wed, 21 Dec 2005, Olaf van der Spek wrote: On 12/21/05, Goswin von Brederlow [EMAIL PROTECTED] wrote: Who need PARALELISM and who has a bandwidth of more then 8 MBit? I have 10240kBit downstream and get way less from security.debian.org. Especialy when there is a security release of X or latex. But parallel downloads won't solve that. Yes, sometimes they do. Those of us who experience it can tell you that, and in fact, we did. The question is whether it is *desired* to try to fix that with parallel downloads. -- 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Thoughts on Debian quality, including automated testing
On Wed, Dec 21, 2005 at 08:10:03PM +0100, Thomas Hood wrote: It turns out that there is no need for them to be hurt at all. Lone can carry on working as before and find a co-maintainer who won't get in his way. But when Lone falls off his horse he'll be glad that Tonto is nearby. ... You are saying that requiring people to find co-maintainers is bureaucracy? It seems to me that if you're talking about a lip service approach like the above being OK then the focus isn't really on solving the problem any more, it's on having people jump through a given set of hoops. This doesn't really achieve the end result you're looking for. Someone I know well recently got co-maintainers for three of his packages by posting a single message to debian-devel. That's less of a burden than that imposed by many another Debian rule. Conversely, the reason I ended up maintaining the NIS package is that I'm the only person who stepped up and actually did anything when the previous maintainer asked for help. -- You grabbed my hand and we fell into it, like a daydream - or a fever. signature.asc Description: Digital signature
Re: Experiment: poll on switching to vim-tiny for standard vi?
Glenn Maynard [EMAIL PROTECTED] I have no sympathy for the notion of a silent majority. If you have an opinion, speak it. [...] Hard if you can't hear the question above the NOISE. wonder how many people will vote for nvi bacause nvi is more like regular vi than vim. This is important even for an informal poll; I think that will be dwarfed by the we love vim effect. a vote is useless if it's heavily skewed, whether it's a poll or a GR. - vim-tiny is not much bigger than nvi (numbers?) Current unstable Installed-Size: vim-tiny ranges from 696 to 1852 with a median of 898k. nvi ranges from 560 to 1040 with a median of 648k vim-tiny depends on the 200k-ish vim-common too, so nvi seems about half the total size of a vim-tiny today. - even vim-tiny is much preferable to vim users over nvi, even without vim-runtime - vim can behave just like old vi (as nvi does), and will do so when invoked as vi - vim-tiny is on fewer platforms than nvi, which seems as important as size or accuracy of emulation. -- MJ Ray - personal email, see http://mjr.towers.org.uk/email.html Work: http://www.ttllp.co.uk/ irc.oftc.net/slef Jabber/SIP ask -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Thoughts on Debian quality, including automated testing
Andrew Suffield wrote: Cute theory, gaping hole. Making a group of people responsible for something, rather than a single person, means that they can all spend all their time passing the buck and hoping that one of the others takes care of it, with the result that nobody does. This is a legitimate objection. I was assuming that the main reason for undermaintenance is lack of time and reluctance to give up control, rather than lack of motivation. If the problem is lack of motivation, and the chief motivator is a sense of responsibility, then you don't want to diffuse that. We would all be much worse off with the abolition of individual responsibility. The constitution already abolished it -- at least, if you interpret article 2.1 the way some people have. Maybe it would be useful to reinforce a sense of responsibility in Debian. If I were feeling in a conspiracy-theorist mood then I'd suggest that those who are promoting team maintainance are trying to gain power while evading responsibility. Well, you do suggest it here. And what you suggest makes no sense, so let's not rule out the possibility that you are in fact paranoid. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: switching to vim-tiny for standard vi?
On Wed, Dec 21, 2005 at 04:56:35PM +0200, Riku Voipio wrote: While I'm a addicted vim user, the build-dependencies of vim(-tiny) is a bit scary for a base package. While we do not have requirements of base packages of being easily buildable, changing to vim-tiny will make bootstrapping a basic debian system again a little bit harder. Urgh. Yes. Until now I was in favour of vim-tiny, but these build-deps are just too scary. Unless we put vim-tiny in another source package, I guess we'd better stick with nvi. -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#344345: ITP: musmap -- Musmap is a web mapping interface with an advanced users/profile management system
Package: wnpp Severity: wishlist Owner: Mathieu Parent [EMAIL PROTECTED] * Package name: musmap Version : 0.9.0 Upstream Author : Mathieu Parent [EMAIL PROTECTED] * URL : http://musmap.sf.net/ * License : GPL Description : Advanced web mapping interface Musmap is a web mapping interface which has an advanced users/profiles management system. . Features: Can open all file formats supported by UMN Mapserver (shapefiles, PostGIS, OGR, OracleSpacial, ...) Can open Rasters (geotiff, ecw, jpeg, ...) tile-indexed Management of display properties (via profiles) Users Profiles (aka maps) data (alpha or shape or raster) classes (=legend elements) styles (colors, symbols, ...) labels (...) Overviews (reference maps) Extents (to quickly zoom) ... Easy administration: give a list of connections, Musmap will find all the data! Adding/removing users Adding/removing data-sources Importing or changing metadata (data labels, joins, ...) Tools (build spacial indexes, automatic metadata creation, ...) Tested with many browsers (Requires Javascript): Gecko (Mozilla Suite, Firefox, Netscape, ...), KHTML (Konqueror, Safari, ...), Internet explorer 5, ... Under GNU General Public License (GPL). Free as beer and free as speech ! -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Thoughts on Debian quality, including automated testing
On 21-Dec-05, 13:10 (CST), Thomas Hood [EMAIL PROTECTED] wrote: How much would this rule hurt those lone ranger maintainers you are talking about, the ones who package everything perfectly and cannot possibly do any better? It turns out that there is no need for them to be hurt at all. Lone can carry on working as before and find a co-maintainer who won't get in his way. Or, the Lone Ranger can say screw this crap and orphan all her packages. In other words, this rule can have only positive effects. :) That doesn't sound too positive to me. If you think it's acceptable, under the must have a co-maintainer rule, to have a co-maintainer who doesn't actually do anything except have their name in the control file, it's pretty clear that the rule is pure bureaucracy. Yes, there are some maintainers and/or some packages for which co-maintenance is a good idea. Luckily, they seem to be figuring it out on their own. If you have some particular packages in mind, go offer to help. 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Experiment: poll on switching to vim-tiny for standard vi?
On 21-Dec-05, 16:11 (CST), MJ Ray [EMAIL PROTECTED] wrote: Current unstable Installed-Size: vim-tiny ranges from 696 to 1852 with a median of 898k. nvi ranges from 560 to 1040 with a median of 648k Ranges? Over what? Architectures? vim-tiny depends on the 200k-ish vim-common too, so nvi seems about half the total size of a vim-tiny today. Okay, so that's not about the same. Stefano? If the above numbers are correct, then the best case is a (696+200-560)==336K increase. Last I heard, the CD builders considered that a non-trivial amount of space. Or am I confusing the boot image with base? 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Experiment: poll on switching to vim-tiny for standard vi?
On Wed, Dec 21, 2005 at 10:11:14PM +, MJ Ray wrote: - vim-tiny is on fewer platforms than nvi, which seems as important as size or accuracy of emulation. Vim still runs in 16-bit DOS, and I think it even has a functioning OS/2 build, but it won't run on all of the platforms Debian supports? -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /run vs. /lib/run
In article [EMAIL PROTECTED], Anthony Towns aj@azure.humbug.org.au wrote: /var/run has always been the right place in the namespace; it's just not been usable for technical reasons. If we fix the technical reasons, all is good. Well there is on more technical solution that might have been overlooked. Why not create /var/run on the root file system even if /var is mounted over it later on. You can do something like: - at bootup: mount -t tmpfs tmpfs /var/run - S01, S02, S10 .. - then: cd /var/run ( cd /; mount -a ) if ! [ . -ef /var/run ] then mount --move . /var/run fi cd / This works at least on 2.6. It keeps the shell process' working directory in /var/run. Even if mount -a mounts something over it, the shell process' working directory is still the tmpfs. Then you just move the mount to the real /var/run . This means that /var/run is always writable. Postinst can create a /var/run under /var in a number of ways- for example by mounting the root file system a second time somewhere, or by calling a process that uses clone(CLONE_NEWNS), umounts /var and mkdirs /var/run. Mike. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Experiment: poll on switching to vim-tiny for standard vi?
Glenn Maynard [EMAIL PROTECTED] On Wed, Dec 21, 2005 at 10:11:14PM +, MJ Ray wrote: - vim-tiny is on fewer platforms than nvi, which seems as important as size or accuracy of emulation. Vim still runs in 16-bit DOS, and I think it even has a functioning OS/2 build, but it won't run on all of the platforms Debian supports? Who knows? It's not currently built for as many. For hurd-i386, hppa and s390, nvi is a working editor and vim-tiny isn't. I can't remember what counts as support right now (URL anyone?) That's an incentive for nvi over vim-tiny, but nvi is the current anyway and I don't see many benefits of a change. The -devel thread seems to have started with two dubious claims: that vim-tiny isn't much bigger and more prefer vim. I've questioned the size claim in another subthread and surely vim users won't be satisfied by vim-tiny. Please cc me on replies. Thanks, -- MJ Ray - personal email, see http://mjr.towers.org.uk/email.html Work: http://www.ttllp.co.uk/ irc.oftc.net/slef Jabber/SIP ask -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Experiment: poll on switching to vim-tiny for standard vi?
Steve Greenland [EMAIL PROTECTED] On 21-Dec-05, 16:11 (CST), MJ Ray [EMAIL PROTECTED] wrote: Current unstable Installed-Size: vim-tiny ranges from 696 to 1852 with a median of 898k. nvi ranges from 560 to 1040 with a median of 648k Ranges? Over what? Architectures? Yes, architectures. vim-tiny depends on the 200k-ish vim-common too, so nvi seems about half the total size of a vim-tiny today. Okay, so that's not about the same. Stefano? If the above numbers are correct, then the best case is a (696+200-560)==336K increase. Last I heard, the CD builders considered that a non-trivial amount of space. Or am I confusing the boot image with base? The increase is between 101% for ia64 and 58% for i386. vim-tiny+vim-common is smallish by current standards, but neither about the same as nvi, nor only marginally larger. Was there a maths error near the top of this thread? Workings (rounded down, to be generous): nvi alpha 328.6 760 vim-tinyalpha 471 1072 vim-common alpha 79.9 232 =total alpha 550.91304 CHANGE alpha +67% +71% nvi amd64 288.3 668 vim-tinyamd64 433.1 900 vim-common amd64 79.5 232 =total amd64 512.61132 CHANGE amd64 +77% +69% nvi arm270.3 600 vim-tinyarm376.4 760 vim-common arm 79.2 228 =total arm455.6 988 CHANGE arm+68% +64% nvi i386 281.4 632 vim-tinyi386 368.4 776 vim-common i38678.8 228 =total i386 447.21004 CHANGE i386 +58% +58% nvi ia64 390.21040 vim-tinyia64 687 1852 vim-common ia6482 240 =total ia64 769 2092 CHANGE ia64 +97% +101% nvi m68k 255.6 560 vim-tinym68k 339.5 696 vim-common m68k78.3 228 =total m86k 417.8 924 CHANGE m68k +63% +65% nvi mips 302.7 824 vim-tinymips 457.31200 vim-common mips79.2 232 =total mips 536.51432 CHANGE mips +77% +73% nvi mipsel 302.4 824 vim-tinymipsel 457.51200 vim-common mipsel 79.2 232 =total mipsel 536.71432 CHANGE mipsel +77% +73% nvi powerpc289.3 648 vim-tinypowerpc408.8 896 vim-common powerpc 79.1 228 =total powerpc487.91124 CHANGE powerpc+68% +73% nvi sparc 272.6 628 vim-tinysparc 376.4 804 vim-common sparc 78.9 228 =total sparc 455.31032 CHANGE sparc +67% +64% no vim-tiny for: nvi hppa 302.6 652 nvi hurd-i386 281.4 632 nvi s390 285.1 648 Hope that helps and please cc me on replies, -- MJ Ray - personal email, see http://mjr.towers.org.uk/email.html Work: http://www.ttllp.co.uk/ irc.oftc.net/slef Jabber/SIP ask -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Thoughts on Debian quality, including automated testing
On Wed, Dec 21, 2005 at 12:23:32PM +0100, Thomas Hood wrote: I don't think that it is ridiculous to require that every package have a team behind it---i.e., at least two maintainers. First, if someone can't Sorry, but I'm having an issue with the word require here. Call me idealistic, but I think a more basic requirement here is to expect maintainers to act responsibly. Let them recognize the best ways to maintain a package for themselves. Telling them they must work in a certain manner is disparaging. If there are cases where team maintainership would clearly solve a problem yet the maintainer will refuse to turn over the package to TM, then it is valid to question whether that maintainer is acting responsibly. But otherwise, team maintainership is a solution looking for a problem. I'm not against advocating for TM, but please do so in a case by case basis. Other than that, enable, don't force. If you think that TM is great try to convince people, set an example and show people how it can be done but don't set rules. The goal of Debian remains to create a free operating system and it doesn't matter how we get there. signature.asc Description: Digital signature
Re: Experiment: poll on switching to vim-tiny for standard vi?
On Thu, Dec 22, 2005 at 02:28:23AM +, MJ Ray wrote: Who knows? It's not currently built for as many. For hurd-i386, hppa and s390, nvi is a working editor and vim-tiny isn't. I can't remember what counts as support right now (URL anyone?) I'll have to punt on that one, since I know nothing about those platforms and why vim might not work on them. I can't imagine it's anything major if those are viable platforms at all, though. That's an incentive for nvi over vim-tiny, but nvi is the current anyway and I don't see many benefits of a change. The -devel thread seems to have started with two dubious claims: that vim-tiny isn't much bigger and more prefer vim. I've questioned the size claim in another subthread and surely vim users won't be satisfied by vim-tiny. I much prefer vim-tiny over nvi, others have agreed (at least Frans Pop and Joey Hess), and not one person so far has actually said they prefer nvi over vim--just that they prefer its defaults, which has been addressed. I don't know how you can possibly call the claim that more prefer vim over nvi dubious; it's a pretty clear-cut one. It seems like a mindset I've seen elsewhere: if you can't get 100%, settle for 0%. I'm 75% with vim-tiny, 95% if I'm not programming (which I'm probably not, if vim-tiny is installed), and 0% with nvi, and one doesn't always have the ability to install packages. Please cc me on replies. This is the only time I'll do so, to remind you to set Mail-Followup-To. It's your job to set headers expressing your preferences (which you only have to do once, in your mailer configuration), not everyone else's job to manually set your CC every time. (You've been on these lists for quite a while; I'm pretty sure you know this ...) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Experiment: poll on switching to vim-tiny for standard vi?
Glenn Maynard [EMAIL PROTECTED] writes: I much prefer vim-tiny over nvi, others have agreed (at least Frans Pop and Joey Hess), and not one person so far has actually said they prefer nvi over vim--just that they prefer its defaults, which has been addressed. Just to be completely unambiguous about my earlier message, I do indeed prefer nvi over vim, regardless of how vim is configured. It's smaller and it does what I expect, which neither vim in its default mode nor vim in its compatible mode does. Also, I prefer not to have to configure my vi to behave like vi, but maybe that will be changed. It's not a matter of just configuring it on one host, like it is with XEmacs. I only use XEmacs for major editing and can customize it extensively on the small handful of systems that I use all the time. I use vi for routine system administration, configuration file editing, and all small edits, and I use it on a ton of different Debian machines from a variety of different accounts that don't all share a single configuration or set of home directories. (I realize that other people feel the same way about vim. I'm just stating a personal preference, not arguing that other people's preferences are wrong.) On the other hand, I don't consider it a major issue and can live with whatever decision people come to, which is why I voted both alternatives above further discussion in the straw poll experiment. :) -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#344359: ITP: flowscan-cuflow -- Flowscan module combining CampusIO and SubNetIO
Package: wnpp Severity: wishlist Owner: Russell Stuart [EMAIL PROTECTED] * Package name: flowscan-cuflow Version : 1.5 Upstream Author : Johan Andersen [EMAIL PROTECTED], Matt Selsky [EMAIL PROTECTED] * URL : http://www.columbia.edu/acis/networks/advanced/CUFlow * License : GPL Description : Flowscan module combining CampusIO and SubNetIO The packaging has been done. The packages can be found here: http://www.stuart.id.au/russell/files/debian/sarge/flowscan-cuflow Package: flowscan-cuflow Architecture: any Depends: flowscan Recommends: flowscan-cugrapher Description: Flowscan module combining CampusIO and SubNetIO CUFlow is a FlowScan module designed to combine the features of CampusIO and SubNetIO and to process data more quickly. CUFlow allows you to differentiate traffic by protocol, service, TOS, router, and network and then generate TopN reports over 5 minutes periods and over an extended period of time. Package: flowscan-cugrapher Architecture: any Depends: flowscan-cuflow Description: A CGI interface for flowscan-cuflow CUGrapher is a Web CGI program which generates images on the fly based on user input with data supplied by CUFlow. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.11-7-lube-686-smp Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: udev event completion order
On Thu, 22 Dec 2005 06:29, Darren Salt wrote: I demand that Alexander E. Patrakov may or may not have written... Kay Sievers wrote: There is also the plan to do parallel device probing inside the kernel some day, that will make the situation of relying on kernel names even more fragile. Right, this means that the way of passing root=/dev/hdc2 will no longer work because /dev/hdc will sometimes become /dev/hde. That will also break scripts/apps that manipulate disks/partitions. This could easily result in some-one restoring a backup over the wrong disk. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Thoughts on Debian quality, including automated testing
On Wed, 21 Dec 2005 12:23:32 +0100, Thomas Hood [EMAIL PROTECTED] said: Mandatory teams for packages seems ridiculous to me. Lots of packages are so small that having to arrange a team for them, even if it is only the effort to set up and subscribe to a team mailing list, is wasteful. Not everyone likes to work in a close team, either, and we shouldn't exclude them. I don't think that it is ridiculous to require that every package have a team behind it---i.e., at least two maintainers. While opinions are fine, I personally do not share yours in this regards. First, if someone can't find ONE other person willing to be named as a co-maintainer of a given package then I would seriously doubt that that package (or that person) is an asset to Debian. Hmm. The question is, can I find someone whose judgement I can trust, who has the time to spend on it, and who would not require me to change my methodology to the extent that would make managing my packages to burdensome for me. Well, so far, I have not gotten co-maintainers. I am not sure I am going to spend a whole lot of effort to garner any, anyway, since I am not yet convinced that diluting responsibility for my packages would be a net win for my users. And if you are saying that you consider me and my packages not to be an asset to Debian, than all I can respond with is amusement. Second, putting packages in the custody of a team makes it easy for a tired maintainer to relinquish control. When I get that tired, I'll follow the established mechanisms for relinquishing control. I do not need to carry bureaucratic baggage for years in order to facilitate letting go when I need to. If the team works via an alioth project then there are many benefits. Code is kept under version control and thus backed up; the change history can be easily viewed by anyone; the mailing list becomes an easily browsed history of package development. Team maintainership is working very well for some other distributions. None of this requires a team. (take a look at http://arch.debian.org/arch/private/srivasta before you think of refuting this statement). I would support requiring team maintainership because TM will be beneficial in almost all cases and making it a requirement it cuts off a lot of useless discussion. Silly requirements like this would just be crying to be flouted. I, for one, have absolutely no intention of listening to such. Personally, a board is made of wood, and bureaucratic ossification and dilution of responsibility when doing a task is someone elses responsibility don't always improve matters. manoj -- Why use Windows, since there is a door? (By [EMAIL PROTECTED], Andre Fachat) Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Thoughts on Debian quality, including automated testing
On Wed, 21 Dec 2005 17:52:21 -0600, Steve Greenland [EMAIL PROTECTED] said: On 21-Dec-05, 13:10 (CST), Thomas Hood [EMAIL PROTECTED] wrote: How much would this rule hurt those lone ranger maintainers you are talking about, the ones who package everything perfectly and cannot possibly do any better? It turns out that there is no need for them to be hurt at all. Lone can carry on working as before and find a co-maintainer who won't get in his way. Or, the Lone Ranger can say screw this crap and orphan all her packages. Or, say screw this crap, and proceed to ignore the dictum. manoj -- Love your enemies: they'll go crazy trying to figure out what you're up to. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: QPL and non-free
On Wed, 21 Dec 2005 02:08:13 +, Matthew Garrett [EMAIL PROTECTED] said: Francesco Poli [EMAIL PROTECTED] wrote: That is completely irrelevant. The FSF doesn't use the DFSG as freeness guidelines. But the DFSG are intended to be a more detailed description of what free software (a term initially defined by the FSF) is. Whatever gave you the idea? The DFSG are supposed to define what _Debian_ means by free in the social contract. The FSF is over there. If the DFSG are wildly divergent from the FSF's viewpoint, we need to figure out how and why. Err, that's simple. We are not the BORG. We have different views -- just look at us hosting non-free software, which made the FSF unable to recommend us. And the GFDL, which we call non-free. Different bodies. Different goals. Different optinons. Different views. Gee, I would be surprise if our definition of free software was identical, actually. Having two different definitions of free software does nothing to help the community. Diversity of opinions harms the community? How fragile it must be, in your view. manoj -- I cannot believe that God plays dice with the cosmos. Albert Einstein, on the randomness of quantum mechanics Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /run vs. /lib/run
Miquel van Smoorenburg wrote: mount --move . /var/run mount --move only works in 2.6, not in 2.4. I think something similar was suggested earlier in the thread and it is a nice solution for linux 2.6 systems. -- see shy jo signature.asc Description: Digital signature
Re: Experiment: poll on switching to vim-tiny for standard vi?
MJ Ray wrote: Who knows? It's not currently built for as many. For hurd-i386, hppa and s390, nvi is a working editor and vim-tiny isn't. I can't remember what counts as support right now (URL anyone?) Oh, come on. vim-tiny entered the archive this week. The fact that we have some slow buildds and ports like hurd-i386 that are perennially behind is irrelevant to this discussion unless you can point to a build failure log. -- see shy jo signature.asc Description: Digital signature
Re: switching to vim-tiny for standard vi?
Steve Greenland wrote: Okay, so that's not about the same. Stefano? If the above numbers are correct, then the best case is a (696+200-560)==336K increase. Last I heard, the CD builders considered that a non-trivial amount of space. Or am I confusing the boot image with base? Anything over a kilobyte matters for certian d-i boot images. Anything under a half megabyte is pretty much noise for CD building. And vim is already on the main CD anyway due to its popularity. I would not have proposed replacing nvi with vim-tiny if it were not fully technically feasable. (BTW, spot the 7 mb package that entered standard recently with no prior discussion.) -- see shy jo signature.asc Description: Digital signature
Re: Experiment: poll on switching to vim-tiny for standard vi?
MJ Ray wrote: The increase is between 101% for ia64 and 58% for i386. vim-tiny+vim-common is smallish by current standards, but neither about the same as nvi, nor only marginally larger. Was there a maths error near the top of this thread? The very top of this thread contained a forwarded message containing the text (776 + 232 on i386). If you're trying to imply some sort of error it might help if you pointed to a message-id. -- see shy jo signature.asc Description: Digital signature
Re: /run vs /var/run
On Monday 19 December 2005 11:49, Bernd Eckenfels [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED] you wrote: If /run is tmpfs, it means everything stored there eats virtual memory. So a musch metter strategy would be to move everything from /run to /var/run at the end of the boot process. tmpfs stores run ressources in vm more efficiently (since they are otherwise in th buffercache and the filesystem). And you cant really move the run ressources. I vote for having run a tmpfs and having /var/run - symlinked to /run. tmpfs also doesn't require any writes to a disk. Flash storage is getting larger and cheaper and we should expect that the number of systems with no moving parts will keep increasing. On such a system you want to put all the small data that is written often on a RAM disk of some sort. The Familiar distribution (based on Debian and used on iPaQ hand-held machines) used RAM disks for /var/run and many other things. I think it's generally a good idea to make the main Debian development tree work well with flash storage whenever it doesn't hurt other areas of performance. Also as for sym-links, there's no reason why /var/run couldn't be used all along. Imagine we have a system where /var is mounted from an LVM volume (or something else that can't be mounted early on). So we start with a /var mount-point which has a /var/run mount-point under it and we mount our tmpfs there. We then use the --bind option of mount to have it also mounted as /etc/run (or whatever). Then we have daemons started etc which do things under /var/run without any modification to their previous operation. When the real /var file system is mounted mount --bind or --move is used to put the file-system back on /var/run from /etc/run. Optionally we could have special-case code in the script that does mount -a to have it umount /var/run first. I believe that this idea is significantly better than the /run suggestion. It requires changing no other programs, gives the potential of performance benefits (RAM being faster than disk) and system reliability benefits on flash storage systems, and doesn't require breaking the FHS. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Thoughts on Debian quality, including automated testing
On Thu, 22 Dec 2005 04:32, David Nusinow wrote: On Wed, Dec 21, 2005 at 05:32:21PM +0100, Thomas Hood wrote: This is not a fair characterization of what the introduction of a two-maintainer rule would be doing. No one should be insulted by general rule changes designed to make Debian work better. I think a two-maintainer rule is a bit artificial and perhaps the wrong solution. Taking a cue from teams that work well in Debian (Gnome, d-i, etc) indicates that somewhat larger teams with a common goal and a fairly large set of packages under their umbrella will work in practice. This provides the opportunity for autonomy (someone can take ownership of a package within the team) but also a cohesiveness and a known set of people to turn to when you're in need. It's pretty simple to found such a team too. All it takes is some interested people and an alioth project. - David Nusinow I was about to suggest exactly that. Thanks David Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run
On Monday 19 December 2005 23:04, Gabor Gombas [EMAIL PROTECTED] wrote: On Mon, Dec 19, 2005 at 01:49:37AM +0100, Bernd Eckenfels wrote: tmpfs stores run ressources in vm more efficiently (since they are otherwise in th buffercache and the filesystem). Quite the contrary. tmpfs needs vm space even if nobody needs the data (thus, it could be evicted from the page cache if it were on a disk-backed fs). Whether it's on ext3 or tmpfs the end result is that it's in RAM if it's being used and on disk if it hasn't been used for a while. The only difference is whether on disk means a swap partition or an ext3 file system. On Tuesday 20 December 2005 10:47, Gabor Gombas [EMAIL PROTECTED] wrote: On Mon, Dec 19, 2005 at 07:40:24PM +0100, Bernd Eckenfels wrote: Yes, we are talking about a few pages in swap space at most. It's 55 pages (220k) on this machine (368k on ext3). And it's a simple desktop with not much running state. The iPaQ machines I bought a few years ago have 64M of RAM. Every desktop machine produced in the last 6 years has significantly more than 64M. Currently I have some Pentium machines with 64M of RAM that I can't give away (they are so small that no-one wants them for free). 368K is an issue on a machine with 8M of RAM, it's an annoyance if you have 16M, beyond about 32M it stops being a problem. Incidentally if 368K of memory is a problem for you then you should probably stop using Ext3. Ext2 uses less RAM (and that's RAM for non-pagable data). -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /run vs. /lib/run
On Wednesday 21 December 2005 01:27, Gabor Gombas [EMAIL PROTECTED] wrote: On Tue, Dec 20, 2005 at 10:09:43PM +1000, Anthony Towns wrote: The other aspect is that /var's the place for stuff that varies during normal use; introducing some other place for the same thing is redundant and thus more complex. The more I think about it, the usage of /run matches /tmp much better than /var. It is for _temporary_ storage until a better place becomes available. Putting system directories under /tmp is a really bad idea, it opens possibilities of race condition attacks by unprivileged users against system processes. Generally for almost everything we should be looking to reduce usage of /tmp rather than increase it. I think that the only time /tmp should be used is when a user of the system specifically requests that a file be stored there - then the user is making the choice and race conditions are difficult to exploit as an attacker usually doesn't know when a user is about to create a file or what the name will be. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: switching to vim-tiny for standard vi?
Riku Voipio wrote: While I'm a addicted vim user, the build-dependencies of vim(-tiny) is a bit scary for a base package. While we do not have requirements of base packages of being easily buildable, changing to vim-tiny will make bootstrapping a basic debian system again a little bit harder. As far as I know, bootstrapping Debian from scratch is a process of getting the build-essential packages and their build dependencies to build and then building everything else. What packages are in the base system should be irrelevant to that process. -- see shy jo signature.asc Description: Digital signature
Re: Thoughts on Debian quality, including automated testing
On Wednesday 21 December 2005 19.24, Russ Allbery wrote: [mandatory comaintainers] I think that the energy used to define these sorts of procedures is probably better used finding a package with a large bug count and volunteering to work with the maintainer to try to get the bug count down. Amen. -- vbi -- Wir Menschen lieben nicht, um zu hassen; aber wohl hassen wir, um zu lieben. -- Jean Paul pgpqUT6LT3ZXe.pgp Description: PGP signature
Re: Thoughts on Debian quality, including automated testing
On Wednesday 21 December 2005 20.10, Thomas Hood wrote: It turns out that there is no need for them to be hurt at all. Lone can carry on working as before and find a co-maintainer who won't get in his way. But when Lone falls off his horse he'll be glad that Tonto is nearby. Except that Tonto won't be efficient, because he doesn't know more than Joe Random Developer (remember, the reason why Lone picked him was that he 'doesn't get in the way', which will frequently mean that he'll not be interested in the package anymore by the time his attention would be needed.) -- vbi -- featured product: SpamAssassin - http://spamassassin.org pgpj7v9gDPrYw.pgp Description: PGP signature
