Re: ITH: basket ( was: About Basket packaging status)
Le Sam 23 Octobre 2004 02:18, José Luis Tallón a écrit : > Since i have not received any answer since Oct 5th, i prepare to > hijack Basket's ITP in 2 days' time barring > answer from the OP (101 days in preparation) > > I believe that Basket is an useful application to have in Debian, and > will take care of maintaining it as an official package. > > Best, > ~J.L. > > > Original Message > Subject: About Basket packaging status > Date: Tue, 05 Oct 2004 01:40:02 +0200 > From: José Luis Tallón <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > > > Hi, Luke! > > ~ How is the BasKet packaging status?? I thought it would be > wonderful to have it in Debian... have you already contacted upstream > and began packaging? how is everything going?? > > ~ If you need some help or feel than you'd like to relinquish > packaging to someone else, please contact me. > > > Best, > ~ J.L. you are completely wrong in your interpretation of the #259180 I changed it into an ITP, saying I was willing to package it. I've posted an RFS for basket [1] but nobody answered. and since you didn't Cc:-ed me on your mails to [EMAIL PROTECTED] it's a miracle I saw your mail on d-devel ... So please read [1] and if you can be my sponsor (I'm not one yet, still waiting for DAM), I'm interested :) So please, next time, read the whole bug more carefully. Again it's a real miracle I saw your mail http://lists.debian.org/debian-mentors/2004/09/msg2.html -- Pierre Habouzit http://www.madism.org/ -==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==- gpg : 1024D/A1EE761C 6045 409E 5CB5 2CEA 3E70 F17E C41E 995C C98C 90BE spam: [EMAIL PROTECTED] pgpYvSDUSQmu8.pgp Description: PGP signature
Re: Bug#293167: ITP: request-tracker3.4 -- Extensible trouble-ticket tracking system
Le Mer 2 Février 2005 09:52, Stephen Quinney a écrit : > On Wed, Feb 02, 2005 at 08:23:20AM +1100, Matthew Palmer wrote: > > On Tue, Feb 01, 2005 at 04:46:51PM +, Stephen Quinney wrote: > > > The changes between major versions of Request Tracker are > > > typically substantial and one usually wants the opportunity to > > > test an installation of the new version alongside the old > > > version. If a user has made lots of local alterations (via RT's > > > overlay system) they probably won't work without being updated to > > > the new API. This method gives people a much easier upgrade path. > > > > The same could be said of a lot of packages in Debian. Why can't > > users do roughly the same thing as they do for every other > > application in Debian -- test new releases of software separately > > before they go running around dumping them on production boxes? > > I don't think most Debian packages positively encourage their users > to extend and modify the interface in the way that RT does. some does. but a lot of the ones that do permit that have nice and kludgy mechanism to allow easy migrations from one version to the other. IIUC RT has some problems in ``BC'' between the version, and that is sth that I consider beeing a grave upstream problem. So for my part, I understand, and even support your point. -- ·O· Pierre Habouzit ··O OOOhttp://www.madism.org pgpkJxGw5ZiA0.pgp Description: PGP signature
Re: Bug#293167: ITP: request-tracker3.4 -- Extensible trouble-ticket tracking system
Le Mer 2 Février 2005 14:38, Florian Weimer a écrit : > As Andrew noted, we already do similar things for library packages. > There's a growing trend to provide different version which can be > installed in parallel for other infrastructure packages, too (IIRC, > PostgreSQL is heading in this direction, too). > > As a user, I think this is very convenient. The ability to switch > back to a known-to-work version by tweaking a few configuration files > is reassuring, even if you've tested the new software version on an > indepedent machine. sure, having two different versions can be great. though, I expect most of RT users to want having smooth upgrades from any stabke version of RT to the new one. and that's true for pgsql, mysql, or any app that live in debian. The two point of view have advantages. but there is a problem in having a lot of different versions : you have to maintain each of them, even wrt security and stuff like that. and expect most of the users to be confused by all thoses packages that look like beeing the same, but are not -- ·O· Pierre Habouzit ··O OOOhttp://www.madism.org pgpTL3TPvhJuv.pgp Description: PGP signature
Re: what is /.udev for ?
Le Mer 9 Février 2005 15:30, Maykel Moya a écrit : > I recently realized that I had /.dev, after that, I rm -fr it what > rendered my system unbootabled. > > Can somebody point me to info regarding /.dev. I have dig > in /usr/share/doc/udev and Google but found nothing. read your /etc/init.d/udev script -- ·O· Pierre Habouzit ··O OOOhttp://www.madism.org pgphjoY5ZdXwa.pgp Description: PGP signature
Re: mplayer, the time has come
Le Mar 15 FÃvrier 2005 03:02, Ken Bloom a Ãcrit : > On Mon, 14 Feb 2005 11:46:38 +0100, A Mennucc wrote: > > There have been two main problems keeping mplayer out of Debian: > > licenses and copyrights. > > > > Licenses: > > the upstream code contains some code that is protected by (more or > > less) actively enforced licenses: DeCSS code to decode encrypted > > dvd; ffmpeg and OpenDivx code to en/decode MPEG4. > > > > Solution: > > the DeCSS is deleted from the package proposed for Debian > > What functionality do we lose by doing this? we are unable to read encrypted DVD (quite all of them that means). *but* I guess that this mplayer (I've not tested it though) is able to dlopen the libdcss2 that is packaged on third party mirrors (e.g. on C. Marilliat's repo) -- ÂOÂ Pierre Habouzit ÂÂO OOOhttp://www.madism.org pgpQpg8Ca3bfT.pgp Description: PGP signature
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
Le Lun 21 Février 2005 11:38, Wouter Verhelst a écrit : > On Sun, Feb 20, 2005 at 05:21:50PM -0800, Brian Nelson wrote: > > Also, really huge stuff, like KDE, cannot be uploaded as frequently > > as perhaps the maintainers would like because it kills the slower > > buildd's for a few days. > > Hypothetical daily KDE builds would also insanely increase the amount > of network traffic being used by the mirror pulse and people > upgrading their home boxes, so it isn't just a buildd problem. that's true, though this is because partial uploads are not possible I mean that you have no way to say for huge source packages : you only need to build this , this, this and this pacakge. since the changes I've made won't affect the others. I know this raises practical problems (the worst of it not beeing able to construct the same packages that are on the archive when starting from source+diff). But if one day BW is critical, there is a path to explore here. -- ·O· Pierre Habouzit ··O OOOhttp://www.madism.org pgpXPKHIGiGGX.pgp Description: PGP signature
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
Le Lun 21 Février 2005 14:13, Peter Samuelson a écrit : > [Pierre Habouzit] > > > I mean that you have no way to say for huge source packages : you > > only need to build this , this, this and this pacakge. since the > > changes I've made won't affect the others. > > As far as mirror bandwidth goes (including end user bandwidth *from* > the mirrors), that's a problem for rsync/zsync to solve. yes and no because when you build a new package : 1- binary backages do not have the same name (so rsync/apt-get are lost) 2- if you build them for real, they won't be exactly the same (think of /usr/share/doc/your-package/changelog.Debian.gz e.g.) anyway, I'm not sure we really want to do such things ... -- ·O· Pierre Habouzit ··O OOOhttp://www.madism.org pgpMUWItfsl2T.pgp Description: PGP signature
Re: usbmount: udev script to automatically (un)mount USB mass storage devices: include in Debian?
Le Mardi 8 Mars 2005 16:15, martin f krafft a ÃcritÂ: > also sprach Steve Greenland <[EMAIL PROTECTED]> [2005.03.08.1423 +0100]: > > While not perfect, using autofs with a very short timeout (5 > > seconds, say) alleviates this problem. > > No it does not. You would be surprised how many people copy to and > remove the stick the same second that cp returns to the shell. > > Point being: there is no reliable unmounting of USB storage devices > short of user sensibilisation. mount -o sync ... is then a solution, especially if you only put small things, and that the performance loss is not too painfull. -- ÂOÂ Pierre Habouzit ÂÂO OOOhttp://www.madism.org pgp4OXkJx03q0.pgp Description: PGP signature
Re: Bug#299024: ITP: dh-zope -- debhelper script for zope packaging
Le Vendredi 11 Mars 2005 14:03, Gustavo Noronha Silva a ÃcritÂ: > Em Sex, 2005-03-11 Ãs 09:48 +0100, Fabio Tranchitella escreveu: > > The package contains the dh_installzope debhelper script used > > for zope packaging tasks. > > Any specific reason to not include this script in debhelper instead? maybe because it has unnecessary dependencies in order to be functionnal ? IIRC, there is some dh_* scripts that are not shiped within debhelper for such reasons [habouzit amaretto] apt-cache search dh-|grep dh dh-buildinfo - Debhelper addon to track package versions used to build a package dh-consoledata - Debhelper-based script to help packaging console data file dh-kpatches - Debhelper script to help packaging kernel patches dh-make - Debianizing Tool for debhelper dh-make-perl - Create debian packages from perl modules and it seems to be quite sensible. -- ÂOÂ Pierre Habouzit ÂÂO OOOhttp://www.madism.org pgpulbaBhDQqg.pgp Description: PGP signature
Re: The sarge release disaster - some thoughts
Le Mardi 15 Mars 2005 16:15, Martin Zobel-Helas a écrit : > I think the real problem within Debian is the lack of communication > of some people within the project. If the wanna-build admins and/or > the ftp-masters would have said: "stop, were are still missing , > without it you will not be able to release" everyone would have > understood. no, I disagree. this is not *the* problem, but *one of the* problems. everybody looks at *the* problem, whereas there is many (or some if you prefer) > Also i hoped the release team and the ftp-masters would have worked > on the current release instead of planing for the next on. Having all > these people together sitting in one room working on the current > release would have been much more prodcutive. IMHO, they should have done both. but don't get me wrong. I know people time in debian is free time wibble wibble wibble policy wibble wibble wibble ... consitution ... wibble .. you can't force me to work !! wibble wibble ... In fact, there is a lack in the debian constitution. it is ok not beeing able to force people to work. after all we (quite) all are volunteer. *but* constitution should if not enforce, at least encourage teams to communicate. there should be some 'priorities' in the work that we do for debian. some are relevant only for some kind of jobs (some tasks are not relevant for l10n but for packaging, and some is only for DSA e.g.) BUT some are relevant for everybody, and *should* be a duty. I don't say we should talk about every choice a team did. but every team which work has a lot of influence on debian should have a way to make some status updates, or some announces, to say 'hello, here is our current state'. nothing more. I agree with you, there is really communication problems (whatever the invoked reason is, no communication is evil, period). btw, I think that before making very huge plans, maybe an exhaustive problems that have blocked the sarge release (like Adrian did) *is* the way to go. If you, debian developpers that will read me, want to make a list (and not flame around the guilty ftp-master vs the release manager clan, the dam cabal, and the DSA bofh or whatever silly things we read about last days) and then delegate some teams (not only *one*, 3 to 5 teams of 6-7 persons each) ponders about those lists, and then present some real propositions addressing every issue that were listed .. that would be a rich, constructive, and I think effective idea. but what saddens me is that : * it will need that some not so communicative teams ack to recognize their internals failures, and talk about them (like said Adrian, there is no shame, we all are *human*, thus not perfect) * it will need that everybody will believe that all those issues are adressable, and that there is no cabal (the reason for the 3-5 parallele team), that nobody wants to perform a debian takeover, or whatever silly thing you may imagine do we want to act like grownups and make such an internal audit ? or do you still prefer flaming ? -- ·O· Pierre Habouzit ··O OOOhttp://www.madism.org pgpV01LQ93yhc.pgp Description: PGP signature
Re: procmail and Large File Support
Le Mer 16 Mars 2005 21:36, Ron Johnson a Ãcrit : > On Wed, 2005-03-16 at 21:18 +0100, Ola Lundqvist wrote: > > Hello > > > > On Fri, Feb 25, 2005 at 07:45:47PM -0600, Ron Johnson wrote: > > > On Sat, 2005-02-26 at 00:53 +0100, Santiago Vila wrote: > > > > Hello. > > > > > > > > I have several reports saying procmail does not support mbox > > > > folders larger than 2GB. Questions: > > > > > > OT here, but WTF are people smoking, to have 2GB mbox files? > > > > Some people tend to have really large inboxes. I have had a number > > of customers that have several GB inbox. They tend to get quite a > > lot of attachments (reports etc) and do not have the time to delete > > mail. > > File quotas will fix that in a hurry. that's definetely a (sorry) stupid answer. anyway, it feels not very sensible to use mbox flat file and not maildir for such big mailboxes ;) -- ÂOÂ Pierre Habouzit ÂÂO OOOhttp://www.madism.org pgpDscTu7I9Fr.pgp Description: PGP signature
Re: switching to vim-tiny for standard vi?
Le Mar 20 Décembre 2005 08:42, Stefano Zacchiroli a écrit : > On Mon, Dec 19, 2005 at 07:06:34PM -0500, Joey Hess wrote: > > A few places were identified where vim's defaults are particularly > > umcomfortable to people who expect a standard vi, these include > > autoindent being defaulted to on in the system wide vimrc, and > > nocompatible being turned on there also, which makes vim -C not > > behave as expected and enables lots of divergant behavior. vim's > > maintainer may want to consider documenting/otherwise dealing with > > these if vim-tiny goes into base and becomes the program people get > > when running "vi" by default. > > I have no objection in having a separate system-wide configuration > file (/etc/vim/virc) for vim when invoked as "vi", as implemented by > aj's patch. If the other members of the vim maintaince team (Cc-ed) > have neither as well I can apply the patch and come up with a > suitable configuration file which is more in the vi spirit. note that this is sth that quite a lot of distro already do : vi is a mostly vi-compatible thing, and vim is the one with the fancy features on. I personnally like this a lot. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpDdDTbjse2g.pgp Description: PGP signature
Re: debian "experimental"
Le Ven 30 Décembre 2005 17:06, Kurt Roeckx a écrit : > On Fri, Dec 30, 2005 at 04:48:06PM +0100, Michal Piotrowski wrote: > > Hi, > > > > deb http://ftp.debian.org/debian/ experimental main contrib > > non-free deb-src http://ftp.debian.org/debian/ experimental main > > contrib non-free > > So why do you use ftp.debian.org and not ftp.pl.debian.org for > experimental? > > > http://ftp.debian.org/debian/dists/experimental/main/binary-i386/Pa > >ckages.gz: 404 Not Found > > So ftp.debian.org seems to be broken. nope. use : http://ftp.$country.debian.org/debian/ ../project/experimental main contrib It'll work better ... -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpLESKdEdtx9.pgp Description: PGP signature
Re: Bug#348728: ITP: php-net-imap -- PHP PEAR module implementing IMAP protocol
Le Mer 18 Janvier 2006 20:58, Steffen Joeris a écrit : > > You should be aware that per the current REJECT_FAQ [1] > > your package will be automatically rejected because it uses the PHP > > License. Several weeks ago I emailed the FTP Masters[2], requesting > > that they accept the PHP Licence for all PHP Group software, backed > > up by extensive debian-legal discussion. They were explicitely > > invited to either modify their rejection criteria, or continue the > > debian-legal debate, both of which they have failed to do. I am now > > re-extending that invitation. > > > > Charles > > > >1. http://ftp-master.debian.org/REJECT-FAQ.html > >2. http://lists.debian.org/debian-legal/2006/01/msg00066.html > > Hi > > Thanks for the information. I haven't noticed it before because I saw > various packages in Debian using the PHP license. > I told my sponsor to wait with the upload. I will ask him for upload > when PHP license is DFSG compatible or tell him to drop it if the > project disagree with the PHP license. Nevertheless i think the > project should make a decision. Waiting for it now ... > > Greetings and thanks for info > Steffen the project decision is clear IMHO : read the php license, you'll see it can only apply to the main and official PHP distribution. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpVmPy4si1fc.pgp Description: PGP signature
Re: when and why did python(-minimal) become essential?
Le Jeu 19 Janvier 2006 22:47, Matt Zimmerman a écrit : > On Thu, Jan 19, 2006 at 09:23:30PM +, Martin Michlmayr wrote: > > * Matt Zimmerman <[EMAIL PROTECTED]> [2006-01-19 12:45]: > > > Please don't do this; it implies that python-minimal would be > > > part of base, but not full python, and this is something that > > > python upstream explicitly objects to. > > > > Why? Surely having a sub-set of python is better than nothing at > > all, no? > > One of the appealing things about the Python language is their > "batteries included" philosophy: users can assume that the standard > library is available, documentation and examples are written to the > full API, etc. When it's broken into pieces, they get complaints and > support requests from their user community when things don't work the > way they should. > > It is already a source of frustration to them that we don't install > python-dev with python. IMHO, python-minimal has not to be a developpement environment that is viable as-is, but only what is needed to run the scripts that need it. That has to be stated clearly in the description of the package, so that nobody would assume anything about it. Honnestly, I would be really surprised that we can't find a consensus here, if it's needed one day (which currently isn't in Debian if I've followed that thread correctly enough). Ubuntu does not AFAICT the same size requirements as debian do for base, and I really think that python upstream can understand that the *full* python suite on a embeded device just does not makes sense. To me, this looks like a bad excuse. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpcSotMgQyn8.pgp Description: PGP signature
Re: Bug#349064: ITP: flash-plugin -- installer for Macromedia Flash Plugin
Le Lun 23 Janvier 2006 10:39, Petter Reinholdtsen a écrit : > [Bart Martens] > > > The Debian package flash-plugin is meant as an alternative or as a > > replacement for flashplugin-nonfree. > > Why not just join forces with Takuo KITAME to maintain > flashplugin-nonfree, and update it to behave the way you want it? I > do not see the point of two installer packages for macromedia flash. > Please limit it to just one, and keep the old package name > flashplugin-nonfree to make it easier for custom debian distros and > upgrades. > > Please update > http://packages.qa.debian.org/f/flashplugin-nonfree.html> > instead of making another installer package. I agree here, there is no point in making two native packages that do the same, when the task is so small (and even if it's not small, it's prefered to concentrate the efforts in a team, rather than duplicating one's work over 3 distinct projects). -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpKyvMUuk4La.pgp Description: PGP signature
Re: Bug#353117: ITP: libphp-xajax -- A PHP library to develop Ajax applications
Le Jeu 16 Février 2006 11:21, David Gil a écrit : > Package: wnpp > Severity: wishlist > Owner: David Gil <[EMAIL PROTECTED]> > > * Package name : libphp-xajax should be : php-xajax. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpnY3LHmGfab.pgp Description: PGP signature
Re: NEW queue backing up again -- ftpmasters, any explanation or comment?
Le Lun 13 Mars 2006 10:38, martin f krafft a écrit : > also sprach Petter Reinholdtsen <[EMAIL PROTECTED]> [2006.03.13.0752 +0100]: > > Could be, but I believe I heard that most NEW processing is done > > by one of the assistants while the mirror split is done by someone > > else. > > The mirror split is a complicated endeavour. From what I understood, > the NEW queue was put on hold on purpose until the split is > complete. and of course such a useless information has been kept silent. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpbWOZ61ruQF.pgp Description: PGP signature
Re: Delayed ldconfig execution in postinst step
Le Lun 13 Mars 2006 18:38, Eduard Bloch a écrit : > #include > > * Goswin von Brederlow [Sun, Mar 12 2006, 03:35:42PM]: > > I think it would be a good idea to have a general dpkg hook to > > register a command to be run at the end of dpkg. The syntax would > > be something like this: > > > > dpkg-hook /usr/lib/man/update-manpages - run only once in total > > dpkg-hook --on-depends foobar ldconfig - run once before depends > > of foobar > > What is a depends? Do you mean dependency or dependents? > Further, I would not depend on package installation operations but > instead invent something like "dpkg-hook --execute ldconfig" to run > outstanding tasks noted under the name "ldconfig". you also need a way to enforce the run, e.g. if you change your libc, you may want to run the ldconfig ASAP, and to purge its entry from the cache of actions to perform at the end. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpJEtKioFzRd.pgp Description: PGP signature
Re: Delayed ldconfig execution in postinst step
Le Lun 13 Mars 2006 19:46, Eduard Bloch a écrit : > #include > > * Pierre Habouzit [Mon, Mar 13 2006, 07:16:22PM]: > > > What is a depends? Do you mean dependency or dependents? > > > Further, I would not depend on package installation operations > > > but instead invent something like "dpkg-hook --execute ldconfig" > > > to run outstanding tasks noted under the name "ldconfig". > > > > you also need a way to enforce the run, e.g. if you change your > > libc, you may want to run the ldconfig ASAP, and to purge its entry > > from the cache of actions to perform at the end. > > Why should I want this? What is so special about libc from dynamic > loader's point of view? Would any glibc maintainer second that? > > And of course the command is to be removed from the list of pending > task when the task is executed, why would we want to run the things > twice? well, I was pondering about it, and maybe for ldconfig it won't be needed. But I really think that we need 3 types of actions: * delayed execution * instantaneous execution (purges cache) * instantaneous execution if an operation is pending, nothing else (purge the cache). e.g. If a package uses tex to build some sort of documentation at install time (I know it's stupid, but it's just an example ok?) then the delayed operation of indexing the fonts has to be done before (thus my third option). btw, the two later options may be added to the tool later, until they are needed. > -- > OpenBSD fails miserably in this respect, and makes for an example of > how NOT to work with the community on security issues. Their > approach is, roughly, "we fixed this a while ago but didn't tell > anyone, so you're vulnerable and we're not, ha-ha-ha". -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp1aLqgr33fH.pgp Description: PGP signature
Re: removal of svenl from the project
Le Mer 15 Mars 2006 03:01, Andres Salomon a écrit : > Hi, > > I am going through the expulsion process to have Sven Luther removed > from the project. The process is outlined here: > <http://lists.debian.org/debian-devel-announce/2005/08/msg5.html> >, and I have already completed step 1. I strongly oppose to such an expulsion. what is wrong with you ? are you gone completely insane or what ? I know Sven may sometimes be a bit overpresent in some trolls, he also may answer too quick, without having read the mail he answers to correctly enough. But AFAICT, I've always seen him apologies when he did so (I can provide links if you can't believe me…). If you want to expulse any DD that taunts a release manager, a ftp-master or a debian sys-admin, hey, please begin with the recent thread about the NEW queue beeing stuck again. There is a lot of DDs that need you to rule about them. The project is really going insane. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpM2NFqme4Y5.pgp Description: PGP signature
Re: removal of svenl from the project
Le Mer 15 Mars 2006 15:05, Andres Salomon a écrit : > On Wed, 2006-03-15 at 11:25 +0100, Pierre Habouzit wrote: > > Le Mer 15 Mars 2006 03:01, Andres Salomon a écrit : > > > Hi, > > > > > > I am going through the expulsion process to have Sven Luther > > > removed from the project. The process is outlined here: > > > <http://lists.debian.org/debian-devel-announce/2005/08/msg5.h > > >tml> , and I have already completed step 1. > > > > I strongly oppose to such an expulsion. > > It amazes me that people oppose expulsion, but are perfectly happy to > allow the DAMs to decide whether or not a NM is to be let into the > project. Why do we trust the DAM's judgement in one scenario but not > the other? > > > what is wrong with you ? are you gone completely insane or what ? > > I'm tired of discussions immediately degrading into personal insults. just so that we are clear, I consider your first mail a personal insult already, especially given that your decision is based on irc logs. Using the irc logs of a pissed person for the ground of an expulsion process is either (I'll let you choose): * a complete lack of dignity ; * the result of a fascist mind (so that I can win my Godwin point) ; * that you are a saint, since you feel comfortable with blaming people that release pressure on IRC. oh and btw, as you noted it, I attacked you personnaly, maybe you should begin a procedure to expulse me. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpkCL9XKkyjq.pgp Description: PGP signature
Re: Bug#303366: ITP: vimcdoc -- Chinese Translation of Vim Online Help Documents
Le Mercredi 6 Avril 2005 13:08, Carlos Z.F. Liu a écrit : > 2. No commercial use of this software are allowed without written > permission from the author. For written permission, please contact > [EMAIL PROTECTED] at least this one means that vimdoc cannot be in main. that's sad. -- ·O· Pierre Habouzit ··O OOOhttp://www.madism.org pgpItKpZTkn6h.pgp Description: PGP signature
Re: Bug#302309: ITP: bcron -- Bruce's cron system
> I know, that's not accessible to users, only the admin. OTOH, I can't > think of any really good reason that user needs to do something > *automatically* on reboot. I see plenty : I have a mini daemon on one of my accounts that I really need. but since I'm not root on the machine, I need to be able to use @reboot to restart -- ·O· Pierre Habouzit ··O OOOhttp://www.madism.org pgpE3mm5q8tFq.pgp Description: PGP signature
Re: PHP/WebApp policy/mailing list
> So, I'm not sure such kind of list > will be useful for a long period. Of course, we could discuss about > the meaning of 'long' in Debian metrics... I disagree with that. A lot of people use webapps (through their browser) a lot more than all the others. I already explained my PoV about webapps in debian many times on d-devel@, and I still believe that debian should have a policy about webapps, but that's not the only point, and I don't see why such a list would die. a lot of packaging scripts have to be written (dbconfig eg), or enhanced (wwwconfig-common eg). That may look stupid, but webapps may need a lot of new concepts like asynchronous apt tasks : I don't know if you realize how many webapps upgrade will fail if their db server is down (and that happens a lot : every time the webapp is upgraded at the same time as your SGDB ... the DB server will be down during the webapp upgrade). that would need tools. THere is the security problems too (see all the discussion about include() e.g.), and a lot of things to speek about (PEAR packaging e.g. is not ruled by any policy ...). And there is a lot of maintainers that suffer from all those problems, and that would be happy to find some other developper that shares the same problems. so, maybe (and I hope so) it won't have d-devel traffic. but I really think it won't die. -- ·O· Pierre Habouzit ··O OOOhttp://www.madism.org pgpZSyXWTi4u0.pgp Description: PGP signature
Re: RFC: A new video-related section
Le Vendredi 27 Mai 2005 12:40, Philipp Kern a écrit : > Dear Debian fellows, > > when does a group of packages warrant the introduction of a new > section? At least I could request some comments without any > obligation. > > I know of some users which were distracted by our "graphics" section, > as they searched for multimedia or more precisely movie players and > found it in this section among other programs like image editors, > viewers and converters, actually there are also themes in it. > > I do not know if there were previous discussions on this topic, but > the new section I propose would seperate media players from image > processing tools. Plugins for those players which are currently put > into "libs" should also be put into this new section. So it would > probably be more "multimedia" than "video". Any thoughts on this? multimedia seems more appropriate. most of the video player actually are music player too, and some music player can show video with appropriate plugins (xmms e.g.) though, that would mean that 'sound' won't have that many package. so maybe we should rename sound into multimedia and populate it with video players too ? -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpLsYBochQId.pgp Description: PGP signature
Re: RFC: A new video-related section
Le Vendredi 27 Mai 2005 14:00, Philipp Kern a écrit : > Gergely Nagy wrote: > > Then media players are just fine in graphics or sound, depending on > > which is their main focus (or they could even be in gnome or kde, > > or whatever). > > Please see it from a user's point of view. If one wants a media > player why should (s)he look in "gnome" or "kde"? And I personally > would not expect it in graphics either. In fact some players are > currently in the section of their corresponding desktop environment. > > But following your statement all media players should go into > "sound", as they play sound files and movies (which also have a sound > track in them). the right thing to do would be to switch from sections, to keywords, so that kmplayer could live in sound + video + kde, instead of multimedia that is not very informative. the same holds for ogle or other DE front-ends to popular midia players. I agree kde and gnome sections are completely uninformative, though they are useful too in order to categorize apps that belongs to those desktops environments (not all kde apps begins with 'k' nor gnomes ones with a 'g'). -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpf890B48Zu0.pgp Description: PGP signature
Re: Bug#311150: ITP: twinkle -- VoIP Softphone
Le Dim 29 Mai 2005 11:38, Mark Purcell a écrit : > * URL : http://www.twinklephone.org/ I guess you meant .com ? the .org one does not exists. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpuJtrMA1PU6.pgp Description: PGP signature
Re: Example where testing-security was used?
> In any case, given the number of prospective ports waiting in the > wings, 11 is probably a roughly correct estimate even if we *do* drop > some architectures. (And since non-release ports are likely to stay > in unstable, and adding a release port adds three w-b databases where > dropping one only removes two w-b databases, it takes 1 1/2 dropped > archs to balance one added arch...) in all those debates about the lack of buildds, sth seems odd to me. I've always thought that moore's law was quite accurate... and my understanding (I may be wrong, it's only how I understand the whole thing) is that debian growth is quite linear, compared to the cpu speed, disk size, BW ... growth, the time passing, we should have less and less limitations. I'm aware that more's law is not appliable on some archs (like arm I believe) but the question is, well, who uses openoffice.org or kde on an arm (only to cite those) ? In fact, the point is, I don't understand how hardware limitations are really possible. I understand fully that many ports needs *a lot* of work for porters/security teams (it's a pity human brains does not follow moore's law) ... but I find hard to believe that hardware is the reason why we cannot manage many arches. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpdaVPkl87ui.pgp Description: PGP signature
Re: Example where testing-security was used?
> IOW, it doesn't (directly) give meaningful predictions about the rate > at which a given piece of hardware becomes obsolete. > > It also has no capacity to predict an organization's *ability* to > replace hardware. ok, true > > I'm aware that more's law is not appliable on some archs (like arm > > I believe) but the question is, well, who uses openoffice.org or > > kde on an arm (only to cite those) ? > > This mitigates the linear growth of the archive itself (assuming we > did subset the archive for slower archs), but it doesn't mitigate the > growth of software complexity that causes subsequent revisions of the > same software to run slower on the same hardware over time -- which, > if it's true of nothing else, is at least true of compilers. hmmm, if you don't give such monsters like openoffice or any big c++ application to build on slow/rare arches, I guess that will ease the autobuilders a lot too, not only the archive. maybe the solution is to write a [EMAIL PROTECTED] (like [EMAIL PROTECTED] or [EMAIL PROTECTED] does) in order to ease the autobuilders :D (kidding of course) -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpQCOiqDjrqK.pgp Description: PGP signature
Re: Example where testing-security was used?
> > maybe the solution is to write a [EMAIL PROTECTED] (like [EMAIL PROTECTED] > > or > > [EMAIL PROTECTED] does) in order to ease the autobuilders :D (kidding of > > course) > > wouldn't that just be like DistCC that all the Gentoo users rave > about? one can imagin a 'job' server that allow you to build bits of debian packages at home. not necessarily C source ;) and then debian servers only check it's coherent I know, this is completely ScFi -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpVjrxrAIGtZ.pgp Description: PGP signature
Re: Is Ubuntu a debian derivative or is it a fork?
Le Mer 1 Juin 2005 19:25, Matt Zimmerman a écrit : > On Wed, Jun 01, 2005 at 05:00:31PM +0200, Tollef Fog Heen wrote: > > * Stephen Birch > > > > | John Goerzen([EMAIL PROTECTED])@2005-06-01 00:06: > > | > Out of curiousity, do you have a rough estimate of the > > | > percentage that actually make it into Debian? Or the > > | > percentage that are held back with no good reason? > > | > > | I wonder if it would be an idea to write a tool that compares > > | Debian and Ubuntu packages and provides a web based view of the > > | delta so we can track divergence. > > > > You mean http://people.ubuntu.com/~scott/ongoing-merge/ which has > > been there for at least half a year? > > Or rather http://people.ubuntu.com/~scott/patches/ which even > provides separated patches. well, this is really nice on the paper (and I really think it). though I have many concerns with that page : (1) this is yet-another-page-to-look-at for packaging. for most of the packages, this make this number go from 2 (BTS + upstream) to 3. so it's not a big deal. But now consider it from my point of view : I'm a member of the QT-KDE packaging team, and we have very very hard work in splitting the package, make them FHS-compliant, follow the bloated bugs.kde.org page, the [EMAIL PROTECTED] list , our own BTS that grows at least exponentially, and yet-another-page-to-look-at just make it too many. A push method (wrt us) would be better than a pull (from us) one. We have not time to pull. (2) moreover, when I see patches like [1] I wonder what I can do and extract from a bloated 18M patch ! Note that this is not a "fork" from ubuntu pple, it's just that they have made a kde branch pull + some libtool bloating. But lost in the middle of those 10-15Mo patches, if there was something else, well, I believe everybody understand it's lost So it's not only a pull vs. push problem. I believe, we are in front of the same situation (in some points, not all) than the khtml developpers vs apple : yes ubuntu gives feedback, since they give their diffs. but like apple does with the khtml crew, we have bloated diffs, without *any* comments, and for packages like ours, it's simply unusable. IMHO a "saner" method would be to allow pple to easily hook into the SCM used by the Ubuntu developpers in order to receive the patches done *incrementaly* + the logs that are with them [2]. Other methods are nice, but really unusable when the package is a bit big, and that is those package that often need the more help and need always more manpower. [1] http://people.ubuntu.com/~scott/patches/kdelibs/ [2] there is a lot of ways to do that : rss feeds, ML's, ... -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpciUXFXKG1k.pgp Description: PGP signature
Re: Is Ubuntu a debian derivative or is it a fork?
> Sorry, Pierre, for hijacking your post into this direction, this > rather affects all the projects involved, not only KDE-QT. you have not to be sorry. it's only that every time someone says ubuntu does not collaborate "enough" there is someboty to shout : http://people.ubuntu.com/~scott/patches/. I used example from my experience (and also QT-KDE), but I didn't want my mail be only about KDE/QT packaging. I only wanted to say that this url isn't usable at all as soon as the packages are big, which OTOH are often the package that would benefit the most of any form of cooperation. If you want my personnal opinion wrt debian<->ubuntu : * there are some DD with pride that won't go themselves to Ubuntu ones because .. you know ubuntu crew "is just a bunch of nasty forkers" or just because they think that since unbuntu inherits so much work from debian, it's up to the ubuntu crew to take the first step (and maybe those are not completely wrong ) * OTOH, some ubuntu developper are not very talkative, and as DDs we never hear from their work, and when you go talk to them, the answer is "if I do sth important for your debs, you'll know it" and then, it's the total radio silence. And I won't talk about those that believe that because the DD that maintain the debs in Debian needs 3 days to answer a mail he is MIA ... (ok, that paragraph is exaggerated, but I guess you see the idea behind) The point is, to me, it feels like both "worlds" are waiting for the other to make the things be smooth. I really believe in full cooperation too. Not that long ago, the KDE team had nearly less DD's than non-DD in it (part of the team was in NM queue). I don't see why Ubuntu people would'nt be part of the debian teams, help to the packaging and BTS BSP, and maintain their ubuntu diffs in the same structure (alioth svn/arch/cvs repo) talking with the same tools (alioth maillist), ... The thing is, I just read on kubuntu.org that they already have 3.4.1 packages ready and uploaded, that they are preparing the gcc-4.0 transition, ... nice... I never saw anything like this on our lists, and we will have to go through the same road... but this has not been discussed ... I'm even not sure the migration will be debian-gcc-4-compatible. <:bitterness:> -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpWwCiO4fEzg.pgp Description: PGP signature
Re: Bug#311785: ITP: imlib+png2 -- ITP: imlib+png2 - mentoring applicant needing package
Le Ven 3 Juin 2005 12:56, John D. Hendrickson a écrit : > Package: wnpp > Severity: wishlist > > * Package name: imlib+png2 > Version : x.y.z > Upstream Author : Name <[EMAIL PROTECTED]> > * URL : http://www.example.org/ > * License : (GPL, LGPL, BSD, MIT/X, etc.) > Description : ITP: imlib+png2 - mentoring applicant needing > package are you kidding us ? those apps are in debian, you are flooding the list with irelevant mails. please stop -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpl2DI6lYDlp.pgp Description: PGP signature
Bug#312309: ITP: whitelister -- a Postfix Whitelister daemon
Package: wnpp Severity: wishlist Owner: Pierre Habouzit <[EMAIL PROTECTED]> * Package name: whitelister Version : 0.4 Upstream Author : Pierre Habouzit <[EMAIL PROTECTED]> * URL : https://projects.aaege.net/mailtools/wiki/Project.Whitelister * License : GPL v2 Description : a Postfix Whitelister daemon whitelister is a Postfix whitelister Policy Daemon aimed to whitelist mails that come from clean hosts wrt rbl/rhbl in order to let suspicious mails go through evil treatments like greylisting -- System Information: Debian Release: 3.1 Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11-9-amd64-k8 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: Planet Debian and Akregator
On Thu, Jun 09, 2005 at 07:13:45AM +0200, Marc Haber wrote: > Hi, > > as we all know, Planet Debian generates RSS feeds that Akregator > doesn't grok, and both packages point at the other one for being at > fault. > > Does Debian have something like an "xmltidy" program which can convert > the Planet Debian RSS feeds into something that Akregator can actually > read? > > Greetings > Marc try to ask planet develppers to fix it. the problem with planet (at least the debian one) is that when it meets & it puts an & in the feed it creates, instead of & AFAIK, it is a debianplanet bug since the source feeds it uses *are* correctly escaped. BTW, a feed is XML, not html, and it's not really akregator's fault not beeing tolerant. If you are not convinced, when akregator has a problem on debian planet, open the feed with konqueror or firefox, you'll see that the xml is not valid. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org signature.asc Description: Digital signature
Re: Planet Debian and Akregator
On Thu, Jun 09, 2005 at 12:54:06PM +0200, Marco d'Itri wrote: > On Jun 09, Marc Haber <[EMAIL PROTECTED]> wrote: > > > as we all know, Planet Debian generates RSS feeds that Akregator > > doesn't grok, and both packages point at the other one for being at > > fault. > Yes. The (former?) Planet Debian maintainer believes that aggregators > should deal with malformed XML streams and is not willing to reject > malformed entries instead of blindly copying them in the output. > Most aggregators maintainers tend to disagree... it's even worse : planet debian en-malform xml. create a blog entry with title "foo & bar" ... you'll see, your & will be translated as & in the rss feed of your blog entry, and as & in planet... -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org signature.asc Description: Digital signature
Re: Bug#312669: /sbin/ifconfig: Add ifconfig to user path
Le Vendredi 10 Juin 2005 10:40, Bernd Eckenfels a écrit : > The problem here is that ifconfig must be in sbin by FHS and by > history (would break too many scripts). So moving is not an option. I > can however put a symlink in /bin, however I am not sure how other > DDs think about it, as this will set a bad precedence. why that ? I don't understand what would be wrong with having a symlink in /bin ... -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpl5eq7YiuZQ.pgp Description: PGP signature
Re: Greylisting for @debian.org email, please
Le Jeu 16 Juin 2005 14:33, Santiago Vila a écrit : > Now that we have released sarge, I would like to ask debian-admin and > the Project Leader to consider seriously doing something to reduce > the level of spam we have to receive, store, and filter in our > @debian.org addresses. > > For example, we could use greylisting. Or we could reject messages > that are known to come directly from trojanized windows machines > acting as open proxies. Or even better, we could do both things. I fully disagree, greylisting is really painful, and I really hope this would never be used as a default rule for email filtering. I'd prefer to see some tools like dspam/bogofilter/... used instead of the heavy and not efficient enought SA. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org
Re: Greylisting for @debian.org email, please
Le Ven 17 Juin 2005 01:42, Wouter Verhelst a écrit : > On Thu, Jun 16, 2005 at 03:09:47PM +0200, Pierre Habouzit wrote: > > Le Jeu 16 Juin 2005 14:33, Santiago Vila a écrit : > > > Now that we have released sarge, I would like to ask debian-admin > > > and the Project Leader to consider seriously doing something to > > > reduce the level of spam we have to receive, store, and filter in > > > our @debian.org addresses. > > > > > > For example, we could use greylisting. Or we could reject > > > messages that are known to come directly from trojanized windows > > > machines acting as open proxies. Or even better, we could do both > > > things. > > > > I fully disagree, greylisting is really painful, > > What's painful about it? the delay it creates. For a ML it's often OK, and it may be benefic (since it will delay flames too, and also diminish their length and annoyance) but for our @debian.org addresses ... that sucks, I often rely on the fact that delivery is immediate on those. > It stops a lot of viruses and spam, with no false positives. What's > the problem? it can have false positive or at least be inefficient. e.g. : the alumni site of my school uses SRS rewriting since it does only mail forwarding (no real mailboxes) and that without that it would send to many bad mail wrt SPF. SRS changes the MAIL FROM for one user every 3 or 4 hours. so every 3 or 4 hours he comes stuck in greylisting server again and again. For such domains, greylisting sucks. though, I think greylisting is a quite good last barrier defense. I have recently written a policy [1] daemon for postfix (that has been accepted recently) that works like that : it looks RBL's, and checks SPF against mails. if any of those tests is suspicious, it answer 'DUNNO' (and also let the mail go through the next postfix filtering rule). if NONE of them was suspicious (no rbl hit, and clean SPF) then it answer 'OK' to postfix, and also validate the mail. My following filtering rule (and in fact last one) is a greylisting daemon. with this scheme, I don't greylist by default, and with the right RBLs and SPF settings, I have quite good results, combining a not to large growth of the greylist DB, and not too many delays, and no false positives. This is not an ad for my tool (it's called whitelister and just entered debian tonight ;p) but I think in such a scheme, greylisting is ok and also really effective. and after that, you can have your AVcheck and AS check, and you have a very robust, light, scalable queue. Don't forget also that MX of the planet that have a very big traffic list domains that are greylisted, and force mails delivered to such domains to wait 1h (if not more) in queue after any retry, in order to be really sure to retry *after* the greylist timeout. I'm sure of it, because I know admins of such MX's, and greylisting pulls the charge on their shoulder ... All the reasons I detail here are the one that make me think full, default, complete greylisting on a domain is *not* a good idea. [1] http://www.postfix.org/SMTPD_POLICY_README.html -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp9lHG4Z1Eyr.pgp Description: PGP signature
Re: Greylisting for @debian.org email, please
Le Ven 17 Juin 2005 14:13, Steve Greenland a écrit : > On 17-Jun-05, 01:41 (CDT), Pierre Habouzit <[EMAIL PROTECTED]> wrote: > > the delay it creates. [...] but for our @debian.org addresses ... > > that sucks, I often rely on the fact that delivery is immediate on > > those. > > Then you don't understand how the internet and SMTP works. There is > absolutely no guarantee the mail will be delivered immediately, and > no reasonable expectation of such. > > As a practical matter, the only time the delay is significant is when > trying to carry on an e-mail conversation, which by very definition > is not going to be delayed after the first exchange. I perfectly understand what SMTP is, and I perfectly *don't* understand why having a 30 minutes delay or even a 2 or 3 hours delay in some conditions is tolerable. > > SRS changes the MAIL FROM for one user every 3 or 4 hours. so > > every 3 or 4 hours he comes stuck in greylisting server again and > > again. For such domains, greylisting sucks. > > Yet another reason SRS is broken. I don't know any better solution in order to be SPF compliant when you have a redirection service. please tell me, I'll use it. but any method will require : * sender rewriting * time dependant hash in order to avoid open relay and will create such a problem. For the record, I don't like SRS, but I don't know anything else that would work with SPF. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpuMU3utzmOW.pgp Description: PGP signature
Re: Greylisting for @debian.org email, please
> > I perfectly understand what SMTP is, and I perfectly *don't* > > understand why having a 30 minutes delay or even a 2 or 3 hours > > delay in some conditions is tolerable. > > Come one. We're speaking on additional 5 minutes on the first > connection. Greylist works quite well for me, and I really hope that > we manage to deploy anti-spam-tools on Debian. you didn't read one of my first posts : when the mail you receive comes from a big big big MX, and that they see a greylisted domain, since the time is sometimes 5 minutes, somtimes 10 and sometimes 20, they choose to deliberately let those mail in the queue for 30 to 60 minutes. if there is 2 or 3 such MX that relay the mail before it arrives to its final destination, it can induce 2 to 3 hours delays (I already saw it) and it's painful. And don't tell me that those MX admins are idiots. If you have an MX farm that deal with Megs of mails per day, you can't afford useless requeuinf of mails. Greylisting should *not* be a default rule for incoming mail, it has to many nasty side effects. btw, I don't know how to help to deploy antispam tools for debian, but I can help if any help is welcomed/wanted/... -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpPR3tDl6dxw.pgp Description: PGP signature
Re: Greylisting for @debian.org email, please
Le Dim 19 Juin 2005 18:14, Frans Pop a écrit : > On Sunday 19 June 2005 17:48, Simon Richter wrote: > > Hi, > > > > Frans Pop wrote: > > > I think blocking mails based on an address being dynamic/static > > > sucks. > > > > Indeed, but the only systems that send out email from dynamic IP > > addresses are spam zombies (90%[1]) and people who run their own > > MTA, > > You are missing my point which was that you can not trust ISP's to > properly designate an address as being dynamic/static, so blocking on > that basis will also block people who actually _do_ have a static > address. exactly. e.g. I have a static IP, given by my french ISP (free.fr aka proxad.net). they even give me the possibility (without more charges) to set the reverse DNS on that IP. you can check it, the corresponding DNS name is : olympe.madism.org : [madcoder beacon] host olympe.madism.org olympe.madism.org has address 82.225.205.10 [madcoder beacon] host 82.225.205.10 10.205.225.82.in-addr.arpa domain name pointer olympe.madism.org. I know for sure that some rbls lists my IP as a dialup/dynamic IP address. which is wrong. and the reason why I do have an SMTP server on that IP is that I don't like the methods used by french ISP wrt a matter of antispam and antivirus policies. I only trust my methods, since some tests I ran showed that they dropped a too large amount of mails pretending it was spam. Though, I have configured my SMTP server to use smtp.free.fr (which is the SMTP server of my ISP) as the default route for my mail, since I've had too many problems wrt my IP. And believe me, it's *really* displeasing to be blacklisted as a dialup line. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpU4aRG5MIIC.pgp Description: PGP signature
Re: Greylisting for @debian.org email, please
Le Lun 20 Juin 2005 09:58, Russell Coker a écrit : > On Saturday 18 June 2005 01:33, Pierre Habouzit <[EMAIL PROTECTED]> wrote: > > you didn't read one of my first posts : when the mail you receive > > comes from a big big big MX, and that they see a greylisted domain, > > since the time is sometimes 5 minutes, somtimes 10 and sometimes > > 20, they choose to deliberately let those mail in the queue for 30 > > to 60 minutes. > > Do you have any evidence to support yout claim that big mail servers > are configured to handle gray-listing servers differently from other > mail servers? I do. I know personnaly some admins of big MX (not necessarily ISPs, french schools/universities in my case) that have a special rule for domain that they know practicing greylisting, and that *force* the delay to be of 30 to 60 minutes. and they increase that time if their queue is big > My experience from working at big ISPs is that queues can take 60 > minutes to process because they have many tens of thousands of > messages. A queue with more than 50,000 messages will take quite a > while to process even if you have a 100baseT full-duplex connection > to the Internet. well, greylisiting is done before any DATA is sent, and won't charge your connection that much. so the BW problem seems quite irrelevant. the latency will play a big role though. > > if there is 2 or 3 such MX that relay the mail before it > > arrives to its final destination, it can induce 2 to 3 hours delays > > (I already saw it) and it's painful. > > In what situation will you have three such mail servers? redirections : my debian account redirects to an adress I have from my alumni that is a redirection address garanteed for life that redirects to my real account. I do that because my alumni provides me really good AV and AS services, and all my ingoing mail comes through it. So maybe 3 is a bit exagerated, but I think 2 is pretty common. > > btw, I don't know how to help to deploy antispam tools for debian, > > but I can help if any help is welcomed/wanted/... > > You could help by listing the anti-spam measures that you consider to > be acceptable. Rejecting every suggestion for an improvement is not > helpful. I already did. I don't find blacklists, or greylists alone be of any good : too many false positives ofr r(h)bls, and too many delays for greylisting. IMHO, rbls, SPF and others techniques that induce false positives have to be used upside down : use the rbls, SPF, ... to clean mail. that means, that a mail that is 100% correct wrt dnsRBLs, SPF records, ... can come in. any other mail, then, can go through "evil" treatments like greylisting. It's a way to select mails that are suspicious, and let them be delayed. With that, it's quite easy to avoid greylisting if you are a real ISP/MX/... : you only have to try to be removed from RBLs, or fix your domain wrt SPF if you use it and use it badly. I've written a little postfix POLICY daemon that does what I explained here. it's called whitelister, and it's in the repo. Though, it has not been (AFAIK) used in a big queue, but I plan to. Cheers, -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpEWnV2IYoTa.pgp Description: PGP signature
Re: Greylisting for @debian.org email, please
Le Lun 20 Juin 2005 09:51, Russell Coker a écrit : > On Saturday 18 June 2005 01:07, Pierre Habouzit <[EMAIL PROTECTED]> wrote: > > I perfectly understand what SMTP is, and I perfectly *don't* > > understand why having a 30 minutes delay or even a 2 or 3 hours > > delay in some conditions is tolerable. > > Why is it tolerable to receive 200 spams in a day? On a bad day I > will receive over 100 spams even though I use most of the anti-spam > measures that some people in this discussion don't like. > > The more spam that people receive the less care they will take when > deleting the spam without reading it. This leads to legitimate > messages being deleted by mistake. Bad luck for you if your question > about my package appears in between a few spams in my inbox and I > accidentally delete it with the spam. > > The Debian servers send out a significant number of bounces for spam. > Some DDs have their mail server do in-line content filtering and > reject mail with a SMTP 55x code which is sent to them from the > Debian server because it was addressed to their @debian.org address. > This leads to spam bounces and delay messages from the Debian servers > going to innocent people. This means that when a non-spam message > bounces because a Debian server can't send it on it will probably be > ignored. I know that, but it does not (IMHO) justify the use of greylising for everybody by default. I prefer to receive spam (and I do a lot through my @debian.org address, despite the fact that it's quite recent) that is filtered by my personnal bogofilter quite well (even if not 100% accurate) than to have some QOS alteration. moreover, I believe there is better ways to use greylising, like I already explained in the thread 2 or 3 times already. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpYJ2gJBqwuQ.pgp Description: PGP signature
Re: Greylisting for @debian.org email, please
Le Lun 20 Juin 2005 10:02, Russell Coker a écrit : > On Thursday 16 June 2005 23:48, Kalle Kivimaa <[EMAIL PROTECTED]> wrote: > > I do _not_ want to have my debian.org mail forwarding go through a > > greylisting "service". I've had to deal with one too many user > > complaints due to greylisting. If it is a configurable service, > > then fine, other people may have different experiences, but if > > greylisting becomes a mandatory feature, I guess I have to start > > using non-greylisted (ie. non-Debian) addresses in my Debian > > correspondence. > > Why would it be such a problem if you use a non-Debian email address > for Debian correspondence? As far as I recall I have never used my > Debian email address in the From: field of an email or in a Debian > package maintainer field. from my "new debian maintainer account" mail : We strongly suggest that you use your [EMAIL PROTECTED] address for the maintainer field in your packages, because that one will be valid as long as you are a Debian developer, even if you change jobs, leave university or change Internet Service providers. I personnally use my @debian.org address in order to filter all my Debian related mail, including if not real time, at least quite fast discussion. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgplWFv6K51L6.pgp Description: PGP signature
Re: KDE apps up for adoption
Le Mer 22 Juin 2005 02:52, Ben Burton a écrit : > Hi all, > > Since my spare time is not what it used to be, I have put a few KDE > apps up for adoption this morning: > > kdbg (#315336) -- graphical debugger interface > kprof (#315337) -- visual tool to help analyse profiling results > kbear (#315340) -- graphical ftp client for KDE > > If anyone is willing to take these up it would be appreciated. More > detailed notes on each package are included below. I guess we (qt-kde team) could do it. and anybody interested in doing it too could join us (only having an alioth account is required) and maintain those inside our svn. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpSDhIi6ZIXr.pgp Description: PGP signature
Re: Greylisting for @debian.org email, please
Le Lun 27 Juin 2005 10:14, Stig Sandbeck Mathisen a écrit : > Pierre Habouzit <[EMAIL PROTECTED]> writes: > > I fully disagree, greylisting is really painful > > Since this is contrary to my experience with greylisting, I'd like to > hear more about your experiences with it, and why you consider > greylisting "really painful". I already did : for personnal use (and I use my @debian.org address for some debian related personnal discussions, like discussions with an uploader I sponsor or alike) I find that 30minutes delays are not acceptable (and I know that greylisting last only 5 minutes, but it's a fact that requeue of a mail is done 30 minutes after the first try for most of the SMTP server on the planet). I don't ask a <5s delay for every mail I send/receive, but if a mail takes more than 2-3 minutes to be delivered, then this is useless. > I'm also interested in hearing about the size of the mail platforms > you've used it on, and wether the mail platforms are list-heavy or > user-heavy, and mostly incoming or outgoing traffic. On a mail platform where you use greylisting, you generally have a boost in performances. *BUT* you punish all the MX that deliver mail to you. greylisting put the charge on the SMTP server before you, and those MX will deliver mails slower to you. like I said many times in that thread, greylist is a good solution to filter spam with quite no false positive, that's true. *BUT* it's a bad idea to use it for *every* mail. A mail that (e.g.) : - is SPF-clean - comes from hotst that are RBL-clean - should not suffer from greylisting. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgprvaRhFLTGO.pgp Description: PGP signature
Re: Greylisting for @debian.org email, please
Le Mar 28 Juin 2005 08:36, Bob Proulx a écrit : > Pierre Habouzit wrote: > > Le Lun 27 Juin 2005 10:14, Stig Sandbeck Mathisen a écrit : > > > Since this is contrary to my experience with greylisting, I'd > > > like to hear more about your experiences with it, and why you > > > consider greylisting "really painful". > > > > I already did : for personnal use (and I use my @debian.org address > > for some debian related personnal discussions, like discussions > > with an uploader I sponsor or alike) I find that 30minutes delays > > are not acceptable (and I know that greylisting last only 5 > > minutes, but it's a fact that requeue of a mail is done 30 minutes > > after the first try for most of the SMTP server on the planet). > > > > I don't ask a <5s delay for every mail I send/receive, but if a > > mail takes more than 2-3 minutes to be delivered, then this is > > useless. > > I think you misunderstand. Remember that only the first exchange > with a new address is delayed. After the initial exchange there is > no more delay. Your continuing conversations will not have a delay. and yet please rememeber one of my previous mails : some of my regular corespondant have mails that use SRS and that will also have a MAIL FROM that changes every 3/4 hours. > > like I said many times in that thread, greylist is a good solution > > to filter spam with quite no false positive, that's true. *BUT* > > it's a bad idea to use it for *every* mail. A mail that (e.g.) : > > - is SPF-clean > > - comes from hotst that are RBL-clean > > - > > should not suffer from greylisting. > > Remember that all subsequent messages after the first one are not in > any way delayed. The effect there is the same as not having > greylisting. even if that was true, I don't see why the first mail should be delayed when it's obviously a legitimate mail. and now think at the thing I just said. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpQmjqYulR2c.pgp Description: PGP signature
Re: multiarch?
Le Jeu 7 Juillet 2005 21:17, Josselin Mouette a écrit : > Le jeudi 07 juillet 2005 à 13:04 +0400, Nikita V. Youshchenko a écrit : > > Hello. > > > > Are multiarch ideas alive? > > Do they have any future in Debian? > > I was going to ask the same question ;) > > If we don't start the multiarch effort now, it won't be good for > etch. Are we postponing this to the next release? I hope not ... I'm a quite happy owner of amd64 machines, so happy that I've only amd64 machines for my desktops, and maintaining a chroot to use openoffice is quite annoying (same is true for quake/et but I assume it won't bother debian that much ;p) More seriously, with the popularity of amd64 and emt64 enabled PIV, there will be quite a big number of machines that would need such multiarch. and waiting for etch does not seems like a valid option, especially if etch isn't ready in the year (which seems not really sensible/possible/...). IMHO, either amd64/pure64/... will become a release arch and in that case we have to have a solution for multiarch, either amd64 is not a released arch .. and that bothers me. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpg8fCsM0Grd.pgp Description: PGP signature
Re: multiarch?
Le Ven 8 Juillet 2005 03:42, Bob Proulx a écrit : > (I am referring to those evil flash plugins, > acrobat, etc. in addition to the Quake mentioned by the previous > poster. But UT and Starcraft are more my style.) games and flash are not the only one : you cited acrobat (that is *really* helpfull sometimes for the 2/3 pdf that make xpdf go crazy), there is also skype (and this is a really popular app), opera (not for alldays use, but I do some web design, and sometimes I have to test if it works with that or that web browser), vmare (same as above to test with IE), ... and there is IMHO some benefit to use qemu (e.g.) in its 32bits version when it emulate a 32bits host (maybe I'm wrong, but it sounds sensible) ... so since it does not looks like only a gadget, and that IMHO it's even often needed ... we should have a solution for this. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpMQXt96VVUq.pgp Description: PGP signature
Bug#317751: ITP: proxsmtp -- multi purpose SMTP Proxy
Package: wnpp Severity: wishlist Owner: Pierre Habouzit <[EMAIL PROTECTED]> * Package name: proxsmtp Version : 1.2.1 Upstream Author : Nate Nielsen <[EMAIL PROTECTED]> * URL : http://www.example.org/ * License : BSD (http://memberwebs.com/nielsen/bsd_license.html) Description : multi purpose SMTP Proxy ProxSMTP is a flexible tool that allows you to reject, change or log email based on arbitrary critera. It accepts SMTP connections and forwards the SMTP commands and responses to another SMTP server. The 'DATA' email body is intercepted and filtered before forwarding. . You need to be able to write the filtering scripts that integrate it with your particular needs. If you're looking for something that does virus filtering, take a look at ClamSMTP which behaves similarly and uses a similar code base. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.11.6 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: lilypond and python
Le dim 30 juillet 2006 07:21, Thomas Bushnell BSG a écrit : > No, it requires *both* the newer Python pure speculation, upstream *AND* users on the list, claim it works with python2.3. so stop with that, it's tiresome. > *and* the newer Guile. In another mail <[EMAIL PROTECTED]>, you said: Le dim 30 juillet 2006 07:19, Thomas Bushnell BSG a écrit : > Josselin Mouette <[EMAIL PROTECTED]> writes: > > Thomas Bushnell BSG a écrit : > > > Pierre Habouzit <[EMAIL PROTECTED]> writes: > > > > it seems that guile 1.6.8 is buggy. people reported to have > > > > build lilypond with guile 1.6.7 and/or guile-1.8 correctly. And > > > > I suppose *HERE* is the real problem, […] > > > > > > Actually, way ahead of you on that. > > > > So what? If you know how to fix that issue, then why don't you > > upload a package based on Pierre's work with the fix? Why don't you > > do it RIGHT NOW and get DONE with this madness? > > I don't know a fix for that issue except to use Guile 1.8. So just to be clear, guile wont be fixed magically, Especially if you don't know guile/scheme... And what "surprises[1]" me is that the first public problem that you reported about that, was on the lilypond-devel mail list[2], in a mail that is 4h before mine on -devel (So I suppose that in American english far ahead is 4h before, I will keep that in mind in the future). So far, I've seen *no* bug report on guile from you. Because people reported to have it compile in 1.6.7 (I've found that in many posts on lylipond-* lists) and since it compiles with 1.8 it seems that it's a guile regression, so that it means that it can obviously be fixed in a 1.6.8 version. But that won't happen if you don't open a bug. Bug that (and I won't make a new explanation of that, I already did) you should have open *MONTHES* ago. [1] actually not that much sadly… [2] http://lists.gnu.org/archive/html/lilypond-devel/2006-07/msg00133.html -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpiGVKgVYACv.pgp Description: PGP signature
Python Transition, Mass Bug fill and NMUs…
Yesterday, a last round of bugs has been filled against packages that may need an upgrade to comply with the recent python policy[1]. Some developpers have raised concerns directly to me about the 0-day NMU policy warning in that report. This § has been added because /usr/bin/python beeing python2.4 is a release goal, and that migrating packages to that policy indeed helps to that. That's a statement for a fact, not a thread. If you don't want an NMU, just state it in an answer to the bug, that shows that you are aware, but that for some foo or bar reason you want to deal with that bug with a later upload. this is *OK*. So, dear developpers: if you don't want to be NMUed, just say it. If you don't want to be NMUed just for that, but want your next upload to deal with the python policy, and that you don't know how to handle that new policy correctly, just tag your bug + help, I do follow those bugs, and I've already prepared and sent (or am currently preparing) patches for those who already asked for some. If you want help, but already have a preference between python-support/python-central please state it also, so that the patch do follow your choice, else the one that helps will choose for you (if one or the other helper is indeed needed). So, dear NMUers: *DO* respect the wish of maintainers that ask not beeing NMUed. If you really feel a maintainer just procrastinates, sending a 'NMU patch' on the bug is OK though. If a bug is tagged + help, please do only send the patch, except if the maintainer explicitely allowed NMUs. That way this messy transition will be able to come to an end, peacefully. Thanks for caring. [1] yes I know this was not re-announced, but it was obvious to me that the repeated announces (at least 2 or 3 mails on d-d-a@) about the python transition were sufficient. that plus the fact that the bugs are /important/ and not RC (some may become, for packages that B-D upon python2.3 where they should on python-dev, but we are not here yet, and /that/ will be announced and coordinated with the RM team). -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp2zQWbWiz2x.pgp Description: PGP signature
Re: Python Transition, Mass Bug fill and NMUs...
Le mer 2 août 2006 11:23, Loïc Minier a écrit : > - status of the transition Wiki page: a summary of steps which are >in progress (pointer to python transition pseudo-bug, pointers to >the list of bugs to be fixed in the mass bug filing, description of >the step) that could have been more clear, but I do have such tools to follow the transition, I use[1]. The two rounds of mass bug have been package that build public modules and extensions, and then all the other ones (+ some missed one at the first stage). > - collection of things to do and no to do: this is both intended as >a reference of things that we have discussed and decided to be good >or wrong, and might help in defining the exact criteria prior to >e.g. a mass bug filing; this probably belong to the FAQ on the >Wiki this seems to be quite well documented on the DebianPython/NewPolicy pages, buxy added some full examples, and I added some more things about cdbs recenlty. The page was also updated for private modules before the second mass bug fill. > - test suite that misses, and this is IMHO *the* real thing that sucks here. the rest lacked some advertising, but exists. [1] http://bugs.debian.org/from:[EMAIL PROTECTED] -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpb7fqqKhHCp.pgp Description: PGP signature
Re: dh_python and python policy analysis
/usr/share/pycentral /usr/share/python-support -->8- § 2.2.2: Depends the depends algorithm is just wrong IMHO, dh_python does really curious and complicated things, and I really think it's broken. basically, Depends should be computed like that: (1) if any script uses /usr/bin/pythonX.Y, then the package *must* depend upon pythonX.Y (2) an added dependency on python (>= x0.y0), python (<< x1, y1) has to be used for the larger interval containing the current X.Y. If one of the boundary does not exists, it can be dropped. If any python version is supported, it shall use `python'. The rest is pure s**t from dh_python. as a "test suite", with current beeing 2.3, here are the deps generated by my rule #2: debian/pyversions | depends on python +--- 2.1- | python (>= 2.1) all| python current| python (>= 2.3), python (<< 2.4) | (I'm not 100% sure of that one "current" | semantics is a bit broken IMHO) 2.2-2.9| python (>= 2.2), python (<<2.10) 2.1-2.2,2.4- | *SHOULD NOT HAPPEN* BUT no package should use /usr/bin/python if it needs a python version strictly greater (or strictly lower, but that's IMHO never the case for known versions of python) than the current. It's IMHO broken for many packages. § 2.3.3, 2.4.2, 2.5.3, 2.6.2: *here* the python$version alternative is correct, because /extensions/ can be used with a '/usr/bin/python' as soon as the python current version is in their supported range. so take the previous algorithm, and add to (2): if current python version isn't in that range, add an alternative to the pythonX.Y corresponding to the range lower bound. Meaning that in my test cases, instead of *SHOULD NOT HAPPEN* you will get: python (>= 2.4) | python2.4 and in fact, wrt Depends, the algorithm for pure modules or extensions, private or public is the same. (except for the XB-P-V thingy and "current" but again, that seems broken to me, and in fact, even if I do consider XS-P-V as very useful, I still cannot see XB-P-V as anything else than a pycentral implementation choice) You should also mention that a package that mixes many of the previous items *SHOULD* depend of all the pythonX.Y from the (1) clauses, and the smallest range obtained from the (2)'s. and a python (>= X.Y) | pythonX.Y *IS* invalid as soon as scripts using /usr/bin/python are involved. You also totally miss the rtupdate thingy, that would IMHO need a chapter 3. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpDh3OtC4upv.pgp Description: PGP signature
Re: dh_python and python policy analysis
Le mar 8 août 2006 00:18, Pierre Habouzit a écrit : > § 2.3.3, 2.4.2, 2.5.3, 2.6.2: > *here* the python$version alternative is correct, > because /extensions/ can be used with a '/usr/bin/python' as soon > as the python current version is in their supported range. > > so take the previous algorithm, and add to (2): if current python > version isn't in that range, add an alternative to the pythonX.Y > corresponding to the range lower bound. Meaning that in my test > cases, instead of *SHOULD NOT HAPPEN* you will get: > > python (>= 2.4) | python2.4 > > and in fact, wrt Depends, the algorithm for pure modules or > extensions, private or public is the same. I forgot to explicitely mention that when extensions are in the package, then you have to restrict your 'python' range to the range of the python for which extensions have been built. That seems obvious, but it has to be stated in the policy very clearly. That means that if you ship a .so for e.g. 2.3, 2.4, then your python depends will be: python (>= 2.3), python (<< 2.5) even if the pyversions is 2.1- about debian/pyversions, unlike his brother XS-P-V it does not supports all/current. for python support you have to use sth like 2.1-. current explicitely says that the package is only built for the current python version, and not for any other supported in debian. But I don't like that value for the following reasons: * it says for what the package is built, whereas other values explain for which range of python versions the package is build-able, so semanticaly it's not homogenous ; * it prevents the packager to explain with which python versions the package is compatible, as saying 'current' suggests that the package is now compatible with the current python version, and will always in the future, wich may be wrong when (if that happen) some python 3.0 that is not 100% backward compatible should exists ; * it also give an information we already have as a package that is built for the current python version should depend upon python-dev and not python-all-dev ; * current has not a constant meaning, as it depends of the state of the package python-defaults, and not only of the state of the archive when the package was uploaded. This is IMHO the biggest flaw of that field value. so IMHO the "current" value should be documented as an internal pycentral value, and should not be recommended to be used for other ways of python packaging. OTOH, I thing "pysupport" should also support "all" as it's prettier than 2.1- and more explicit to the packager, and then it could go into the policy as a recomended value in that case. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpkEcXWLwifH.pgp Description: PGP signature
Re: dh_python and python policy analysis
Le mer 9 août 2006 01:33, Manoj Srivastava a écrit : > Hi, > > Another day, another draft. > > Here is the latest update for my take on the new Python > policy document. The current version, and future updates, are to be > found at http://www.golden-gryphon.com/software/manoj-policy/ very nice. I'm going to review it comparing it with the initial python policy by J.Wreschnig so that I'm sure we have not left anything apart, or contradicted vital points. Cheers, -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpPzCbUAbQy2.pgp Description: PGP signature
Re: VMware packaging
Le dim 13 août 2006 02:06, Peter Collingbourne a écrit : > Dear all, > > I found there were no VMware-related packages in the official > repository, nor any way of creating them. Thus I propose to create > a tool that will build (for example for VMware Server) vmware-server > and vmware-modules-source packages based on an installation tarball > (a la java-package). why would we need it when there is already quite plenty of good free alternatives (qemu, bochs e.g.) ? -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpg60wOF3UkG.pgp Description: PGP signature
WTF ? (Fwd: Your message to Yaird-devel awaits moderator approval)
maintainer addresses HAVE to accept bug reports and mails from non-subscribers. This setting is not correct, please fix it asap. -- Message transmis -- Subject: Your message to Yaird-devel awaits moderator approval Date: dim 13 août 2006 13:45 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Your mail to 'Yaird-devel' with the subject Bug#382788: yaird does not uses the kernel command like to find out the root partition Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: http://lists.alioth.debian.org/mailman/confirm/yaird-devel/6630258bb12 20323ec23b95a152b4359e0d0594b --- -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpYCv5QgUWGh.pgp Description: PGP signature
Re: VMware packaging
Le dim 13 août 2006 15:24, Adrian von Bidder a écrit : > On Sunday 13 August 2006 02:25, Pierre Habouzit wrote: > > Le dim 13 août 2006 02:06, Peter Collingbourne a écrit : > > > Dear all, > > > > > > I found there were no VMware-related packages in the official > > > repository, nor any way of creating them. Thus I propose to > > > create a tool that will build (for example for VMware Server) > > > vmware-server and vmware-modules-source packages based on an > > > installation tarball (a la java-package). > > > > why would we need it when there is already quite plenty of good > > free alternatives (qemu, bochs e.g.) ? > > vmware > * is quite fast > * does suspend/resume quite beautifully > * the integration with the guest OS via the vmware tools is quite > nice * as are shared folders if you're using a Windows guest > * using snapshots and clones based off them are quite useful > > Do qemu and/or bochs provide all of those? I use those features > regularly and would welcome such packages. Of course, I'd welcome a > Free alternative to vmware even more, but it's just not there atm. qemu + the accelerator can do all of that, maybe not with a so nice UI than vmware, but that is definitely writeable IMHO. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpyCgBGo3rdX.pgp Description: PGP signature
Re: Bug#382796: ITP: python-alsaaudio -- Alsa bindings for Python
Le dim 13 août 2006 16:02, martin f krafft a écrit : > also sprach Paul Brossier <[EMAIL PROTECTED]> [2006.08.13.1418 +0100]: > > * Package name: python-alsaaudio > > Sweet. An ITP for a package already in unstable... well I must be blind or sth, but apt-cache search python alsa answer nothing for me ... -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpPHKjOh5n8C.pgp Description: PGP signature
Re: dh_python and python policy analysis
Le sam 12 août 2006 17:34, Matthias Klose a écrit : > dh_pysupport doesn't > use this information, but requires the developer to explicitely pass > the directory containing the extension module. that's not completely true, it only searches in /usr/lib/$pkg, /usr/share/$pkg, /usr/lib/games/$pkg and /usr/share/games/$pkg. If he finds a .so in there, he uses objdump to find out if the .so is python related or not, and acts accordingly. It just dont need current/current_ext at all, and uses different implementations choices. that's all. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpfoLiO7xepj.pgp Description: PGP signature
Re: dh_python and python policy analysis
ython-defaults, and are ill > > suited for the debian/control file. > > again, there's nothing wrong about that, as you can use current > together with a list of support versions. same remark as above, that's our mistake, that § has to be removed too. > > 3.3.1. Supported versions > > > > If a script invokes /usr/bin/pythonX.Y, then the version > > supported by the source package (XS-Python-Version or > > debian/pyversions) should be restricted to X.Y, assuming that the > > field is being provided. Or else, it should be set to the list of > > python versions that the script can support, or "all". [36][6] If > > there are separate scripts that invoke different versions of > > Python, then all these versions must be in the Depends field -- if > > you still want to continue packaging instead of just shooting the > > upstream. > > > > No script must use /usr/bin/python if it needs a Python > > version strictly greater or strictly lower than the current > > version. > > see above (packages having foo, foo2.3, and foo2.4 scripts), that > requirement should not be hardcoded in that case. same answer ;) I do think it's up to the debian maintainer to merge those scripts if possible. Moreover a binNMU on the package (if 2.3 is not supported, and that the package uses pyversions -s) will fix that trivially anyway, wich remains quite acceptable. > > 3.5. Private Extension > > > > These are compiled files linked to python libraries, and kept > > in a > > no, in most cases, any extension needs to be linked against > libpython. sorry I miss that mistake by rereading manoj's doc, you're obviously right. > >by the binary package (XB-Python-Version field or the file > > .versions) is set to that version (copied from XS-Python-Version). > > > >If the current version is not supported, this field it set to > > the minimum version actually supported by the module. > > what do you mean? if the version range is e.g. 2.4- with current beeing 2.3, then ... then it's indeed wrong. at least I don't understand the rationale anymore here. needs a fix. > > Depending on the packaging utility used, the modules live in > > either /usr/share/python-central or in > > /usr/share/python-support/$package. > > that is wrong. 1) there's nothing wrong having these still in > /usr/lib/pythonX.Y/site-packages. 2) please avoid naming of these > directories in the document. these should be considered private > directories for the tools. For the case of pycentral, you can get the > directory name using "pycentral pycentraldir ". aggreed. > > Official pure Python modules generally live in a different set > > of > > official? like in upstream's is there any python modules that go in /usr/lib/python2.3/ directly ? > > 3.6.1. Byte compiling > > > > In the common case of pure Python modules in unversioned > > public module directories, tools exist to help byte compile the > > pure Python modules for all versions of Python installed on the > > target system. In case of pure Python modules in versioned public > > module directories, byte compilation is up to the package scripts. > > maybe that's not the best place to mention /etc/python/debian_config, > but scripts byte-compiling files should honor the byte-compile > property. packages should only byte-compile the files belonging to > the package, or else error message for byte-compilations are reported > for random packages. > > 3.8 missing: Packages using embedded python interpreters > (libapache2-pythonX.Y, which should not be collapsed as > libapache2-python), vim, and maybe other packages. agreed > > 4.1.1. rtupdate script invocation > > > > 1. in the pre-installation phase of the python package, the > > package supplied scripts are called with the parameter: > > pre-rtupdate > > > > A failure in any script results in the failure of the > >pre-installation script of the python package. > > > >[42]Note Whether or not all scripts are run, or the > > process aborts at the first failure, is still under flux > > > >Since such a failure of a script would leave all packages > > whose pre-rtupdate has been run in a dangling state, a bug in a > > pre-rtupdate will always be a critical bug. Be very very careful > > when working on a pre-rtupdate script. > > I'm adding a "failed-pre-rtupdate" hook for the next upload, which is > run, if the pre-rtupdate hook fails (to allow the package to go to a > sane state again). that's a good idea obviously. > I do have a different view on raising build and support information > to the Packages/Sources files; in other cases the document clarifies > things well. IMO the current section 3.6 makes things more confusing > than they are (at least for me). Would it be helpful to add > paragraphs starting with "Example:" in sections where they are > useful? I.e. most package maintainers won't need the rtupdate > scripts, and therefore could skip reading when they don't need these > scripts. I think the examples should be in an annex, that follow 3.6 TOC so that one can read the examples in front of the spec, without poluting the spec. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpMpm3c60npB.pgp Description: PGP signature
Re: dh_python and python policy analysis
Le dim 13 août 2006 22:17, Manoj Srivastava a écrit : > As to the BOF thing, I'll bite: Why one earth did the bof come > up with design decisiosn that require every single goldarned python > module package to be reuploaded every time a new version of python > is added or removed? actually,it's not truly needed, it's needed iff a package do needs the new provides or not. and those reuploads are kind of binNMUs, the real problem here is that tehre is no arch:all binNMU and maybe that's here the problem that need fixing. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp9uI8A3k8ar.pgp Description: PGP signature
Re: Bits from the DPL: Freedom and etch
Le lun 28 août 2006 20:35, Anthony Towns a écrit : > Hello, world! > > […] > > Note that both these polls are just an informal way of finding out > what people think, and while they will be considered and taken into > account, they won't necessarily be the final word on the matter. I'm very suprised by that mail that completely forgot to mention the ongoing discussions about a GR about firmwares. There is already three proposals for that GR[1] and I wonder why those have not been mentionned. I'm also worried that the debate seems to be presented as "relase etch in time and put firmwares in main" versus "care about firmware freeness and release later". That's not what has been discussed on debian-vote for one or two weeks already. The current amendments all have the corrolary that etch won't be delayed, either because an exception will be proposed (don's proposal) or because we don't care about firmware until we have a viable technical solution to do the split (joss's proposal) or because we decide that firmwares are not programatical things (steve's proposal). Given that, and that you are not able to assure the users that the result of their poll will be followed: * I fear that the issues of those polls would put pressure on the GR voters, * I also fear that if the GR issue is not what the polls showed that the user wanted, we will have a hard time to cope with our angry users, that will feel they have been made as a fool of that story. So question to the DPL: I really wonder why a formal announce of that unofficial poll has been made, instead of encouraging people to review the amendments that have been proposed, and even propose a new one if needed, so that that GR can come, and that we know where we are going instead of guessing. [1] http://lists.debian.org/debian-vote/2006/08/msg00032.html http://lists.debian.org/debian-vote/2006/08/msg00215.html http://lists.debian.org/debian-vote/2006/08/msg00185.html -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp5nZKmCUBrq.pgp Description: PGP signature
Re: The bigger issue is badly licensed blobs (was Re:Firmware poll
On Wed, Aug 30, 2006 at 09:00:27AM +0200, Raphael Hertzog wrote: > On Wed, 30 Aug 2006, Mike Hommey wrote: > > On Tue, Aug 29, 2006 at 07:17:47PM -0700, Steve Langasek <[EMAIL > > PROTECTED]> wrote: > > > On Tue, Aug 29, 2006 at 08:48:00PM -0400, Nathanael Nerode wrote: > > > > > > > Debian needs to make a decision on how it will deal with this legal > > > > minefield. That is higher priority than the entire discussion going on > > > > right now, because it determines whether Debian will distribute these 53 > > > > BLOBs *at all*, in 'main' or in 'non-free'. > > > > > > > Oddly enough nobody has proposed a GR addressing this, > > > > > > Because voting is an absurd means of settling questions of legal > > > liability. > > > It's the domain of the ftp team to determine whether we can legally > > > distribute a package on our mirrors. > > > > So, all in all, all this fuss for seven blobs ? waw, what a waste of > > time. > > 53 + 7 = 60. > > Please Mike, you have lately a tendency to inflame discussions for > nothing. You've used me to expect better from you. this dig is obviously meant to calm things down… Not to mention that *you* are wrong and that Mike is right, there is currently only 7 blob's that we can suppose to be distributable and sourceless at the same time. Mike's frustration cry would have been unoticed if you hadn't felt compelled to slosh your sanctimonious oil all over the fire. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org signature.asc Description: Digital signature
Re: claiming bugs, BTS delay, planning BSPs
Le dim 3 septembre 2006 12:16, Raphael Hertzog a écrit : > On Sat, 02 Sep 2006, martin f krafft wrote: > > Hi all, > > > > we're in the middle of the BSPMarathon[0]. Among the things new > > this year (as opposed to the sarge BSPs) are usertags for claiming > > bugs [1]. Unfortunately, the BTS is known to lag a bit these days, > > and it won't get better during a BSP, so I wonder how to best > > handle this. > > Hi Martin, > > the best would be to use a dedicated tracker... it might be the time > to try to use the result of Arnaud's summer of code: the > "Distribution wide tracker tool", codenamed "Working together made > easy". :-) > > http://netu.naquadah.org:8080/ seems nice, but very slow, not considerably faster than the BTS e.g. http://netu.naquadah.org:8080/tracker/python24 takes 15.576s to be generated, the same page on the bts is twice as fast to show up. the idea is brilliant, but it does not seems to be a major improvement yet. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpcn9sAfDA2j.pgp Description: PGP signature
Re: The debian boot dependency graph image
Le jeu 7 septembre 2006 15:11, Marco d'Itri a écrit : > On Sep 07, Petter Reinholdtsen <[EMAIL PROTECTED]> wrote: > > For some time now, the runtime dependencies of init.d scripts have > > been documented in the scripts, using the LSB convention. Now, > > enough scripts have this information present to make a useful graph > > of the dependencies in the debian boot. The current state of > > affairs in my sid chroot look like this: > > > >> http://user.skolelinux.no/~pere/debian/lsb-info-20060907.png > > > Now, try thinking about how many of the blocks which are not listed > as depending on udev actually do. your point beeing ? -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpI8Xm2X0357.pgp Description: PGP signature
Re: claiming bugs, BTS delay, planning BSPs
Le ven 8 septembre 2006 14:40, martin f krafft a écrit : > also sprach Christoph Berg <[EMAIL PROTECTED]> [2006.09.08.1233 +0200]: > > I don't think we need more than one tag per claim. > > So how to prevent deadlocks? With many people bug squashing at the > same time, we cannot rely on chaos anymore. you can't because the BTS is way too slow anyway. for 95% of the NMU I do, I receive the acks for message I send at least 15 minutes, often 30 minutes after my mails. most of the NMU I do take me less than 20 minutes from apt-get source to upload, with already too many administrative tasks to perform to avoid adding a new one. I don't claim my bugs, because it's too painful. and if someone worked on the same bug before me, then too bad, I've lost 20 minutes of my time. It happens rarely enough to not worth the added minute I would lost claiming the bug. Only a web form that instantaneously report that I claim the bug would have any chance to be usefull. Using the BTS (in its current reactivity and implementation at least) for interactive tasks is IMHO a bad idea. And please, don't propose yet-another-application to talk to to perform an upload. We have enough administrivia already. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpLLn3I9kiGt.pgp Description: PGP signature
Re: Request to mailing list Pkg-qof-maintainers rejected
Le lun 11 septembre 2006 10:59, Thijs Kinkhorst a écrit : > On Sun, 2006-09-10 at 21:22 -0700, Steve Langasek wrote: > > On Sun, Sep 10, 2006 at 02:26:52PM +0200, Thijs Kinkhorst wrote: > > > On Sun, 2006-09-10 at 11:48 +0200, Joerg Jaspert wrote: > > > > Any maintainer doing such a braindead stupid thing - do not > > > > wonder if I reject your package without any comment in the > > > > future. The maintainer address has to be open to receive mail. > > > > It is fucking annyoing already that the damn "Your post needs a > > > > moderator" messages get back, rejecting legal mail is even > > > > worse. > > > > For my part, I find it pretty offensive that a mailing list that's > > set as the maintainer of a package would have mail filters > > configured this way in the first place. > > It's your right to have such an opinion, but it's not the question at > hand. The point I raised is: is it appropriate to assume that a > fellow maintainer is "braindead" or "stupid", or rather assume that > he made an honest mistake? > > Is it appropriate to use terms like "fucking" and "damn" on a wide > audience mailinglist, or could you send them a polite message if you > don't agree with their way of configuring their lists? > > I'm pretty sure which path I'd take, and I'm also pretty sure which > path would be best to improve the atmosphere between Debian > developers. it's not the first time such a question is raised, I did that recently enough, for a foo-package I don't even remember (some python messages that bounced to me). that is completely inadequate, and whitelisting any @bugs.debian.org From address is trivial. I've already stated it, and I do it again: I do consider ok that the Maintainer field of some co-maintained package is a list, that really makes sense, but *that* list should never ever use sender-based moderation. When some bug report barfs at me with moderation messages, I just stop sending bug reports. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpoyyKkGsAwu.pgp Description: PGP signature
Re: Request to mailing list Pkg-qof-maintainers rejected
Le lun 11 septembre 2006 15:36, Tollef Fog Heen a écrit : > * Pierre Habouzit > > | I've already stated it, and I do it again: I do consider ok that > | the Maintainer field of some co-maintained package is a list, that > | really makes sense, but *that* list should never ever use > | sender-based moderation. > > Does this mean you don't consider using [EMAIL PROTECTED] > as the maintainer of the apache packages appropriate? I don't know, afaict, debian-apache does not block legitimate mails. so I've nothing against it. but such a list should not: * use filtering techniques that refuses legitimate mail * moderation mails (that the user always understand as "your mail has been stuck in some /dev/null moderation queue) * ... the same is indeed true for any address in the Maintainer: field of a package, because it's a duty that such an address work. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp5WCHZuHWFa.pgp Description: PGP signature
Re: /usr/bin/ld: cannot find -lraw1394
Le mar 12 septembre 2006 12:28, Martin Michlmayr a écrit : > A number of packages (at least three, but possibly more) fail to > build with the error: > /usr/bin/ld: cannot find -lraw1394 > Can someone investigate why this is the case. I've put built logs > (mbox file) at http://people.debian.org/~tbm/logs/1394.bz2 FWIW the package libraw1394 has been adopted by Ludovic Reslinger, and I sponsored its upload recently, it's currently in NEW, maybe that new upload fixes the problem ? -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpKhHx58Ehoh.pgp Description: PGP signature
Bug#387926: ITP: eaccelerator -- PHP opcode cacher and compilation optimizer
Package: wnpp Severity: wishlist Owner: Pierre Habouzit <[EMAIL PROTECTED]> * Package name: eaccelerator Version : 0.9.5~rc1 Upstream Author : Name <[EMAIL PROTECTED]> * URL : http://www.eaccelerator.net/ * License : GPL V2 Programming Lang: C Description : PHP opcode cacher and compilation optimizer eAccelerator is a free open-source PHP accelerator, optimizer, encoder and dynamic content cache. It increases the performance of PHP scripts by caching them in their compiled state, so that the overhead of compiling is almost completely eliminated. It also optimizes scripts to speed up their execution. eAccelerator typically reduces server load and increases the speed of your PHP code by 1-10 times. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#387926: ITP: eaccelerator -- PHP opcode cacher and compilation optimizer
Le dim 17 septembre 2006 16:11, Pierre Habouzit a écrit : > Upstream Author : Name <[EMAIL PROTECTED]> bah stupid template... reportbug should barf when such things are forgotten :| anyway the package is in NEW, and debian/copyright is ok -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpsvHPbGOnlp.pgp Description: PGP signature
Re: Bug#387926: ITP: eaccelerator -- PHP opcode cacher and compilation optimizer
Le dim 17 septembre 2006 19:35, Roberto C. Sanchez a écrit : > On Sun, Sep 17, 2006 at 06:07:57PM +0200, Pierre Habouzit wrote: > > Le dim 17 septembre 2006 16:11, Pierre Habouzit a écrit : > > > Upstream Author : Name <[EMAIL PROTECTED]> > > > > bah stupid template... > > > > reportbug should barf when such things are forgotten :| > > > > anyway the package is in NEW, and debian/copyright is ok > > Have you checked out these threads? > > http://lists.debian.org/debian-devel/2005/05/msg00681.html > http://lists.debian.org/debian-mentors/2005/05/msg00148.html > http://lists.debian.org/debian-mentors/2005/09/msg00440.html > http://lists.debian.org/debian-legal/2004/11/msg00078.html > http://lists.debian.org/debian-legal/2005/01/msg00130.html > > Basically, I tried to package this more than a year ago and was > basically not able to finish. So, unless the legal issues have been > resolved, this package will likely not be possible. The root of the > problem is that the GPL is not compatible with the PHP license. > There is no way around it, other than a clean rewrite of eacclerator > by people who have not seen the mmchache-derived code. hmm, right. the thing is, the code has been rewriten for the most part of it, so they are not tied with the turck-mmcache copyright holders anymore (afaict). so maybe it's possible to discuss it with upstream. so basically, what has to be done? they must just explain that they allow anyone to build their GPL software against php, is that it ? the situations changed in the sense that we are not tied because of the past anymore. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpSjEdGY3osK.pgp Description: PGP signature
Re: Bug#387926: ITP: eaccelerator -- PHP opcode cacher and compilation optimizer
Le dim 17 septembre 2006 19:57, Pierre Habouzit a écrit : > Le dim 17 septembre 2006 19:35, Roberto C. Sanchez a écrit : > > On Sun, Sep 17, 2006 at 06:07:57PM +0200, Pierre Habouzit wrote: > > > Le dim 17 septembre 2006 16:11, Pierre Habouzit a écrit : > > > > Upstream Author : Name <[EMAIL PROTECTED]> > > > > > > bah stupid template... > > > > > > reportbug should barf when such things are forgotten :| > > > > > > anyway the package is in NEW, and debian/copyright is ok > > > > Have you checked out these threads? > > > > http://lists.debian.org/debian-devel/2005/05/msg00681.html > > http://lists.debian.org/debian-mentors/2005/05/msg00148.html > > http://lists.debian.org/debian-mentors/2005/09/msg00440.html > > http://lists.debian.org/debian-legal/2004/11/msg00078.html > > http://lists.debian.org/debian-legal/2005/01/msg00130.html > > > > Basically, I tried to package this more than a year ago and was > > basically not able to finish. So, unless the legal issues have > > been resolved, this package will likely not be possible. The root > > of the problem is that the GPL is not compatible with the PHP > > license. There is no way around it, other than a clean rewrite of > > eacclerator by people who have not seen the mmchache-derived code. > > hmm, right. the thing is, the code has been rewriten for the most > part of it, so they are not tied with the turck-mmcache copyright > holders anymore (afaict). so maybe it's possible to discuss it with > upstream. here is the link that explains that: http://archive.eaccelerator.net/OldNews and that has been achieved since, if I'm correct. so if this is just a matter of exception to be done to the GPL, I'm really sure we can work on it nicely. > so basically, what has to be done? they must just explain that they > allow anyone to build their GPL software against php, is that it ? > > the situations changed in the sense that we are not tied because of > the past anymore. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpgN6ccUbTKs.pgp Description: PGP signature
Re: First call for vote on immediate vote under section 4.2.2
- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- 2808c3bb-6d17-49b6-98c8-c6a0a24bc686 [ 1 ] Choice 1: The DPL's withdrawal of the delegation remains on hold pending a vote [ ] Choice 2: The DPL's withdrawal of the delegation stands until a vote - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpr7FDmlCLrt.pgp Description: PGP signature
Re: First call for vote on immediate vote under section 4.2.2
On Sat, Oct 28, 2006 at 03:34:34PM +0200, Stefano Zacchiroli wrote: > On Sat, Oct 28, 2006 at 02:31:54AM +0200, Pierre Habouzit wrote: > > - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- > > Can I ask why you people (not only you Pierre, generic question) are > Cc-ing votes to debian-devel? Is it an error? that was a To: you have the mail, check that, that should be obvious to you … > If it is not I can only imagine that it is a "politic" Cc to let other > people know your opinion on that. Please don't, but even if you really > want to, then please use debian-vote. > > I'm trying hard these days to keep on my usual Debian work ignoring: > flames on DT, flames on childish people calling childish each other, > flames on the debate among AJ and Manoj, flames on .*. … that it was not political. I've way higher standards than that. > It would help if related votes would be kept out of debian-devel. it would help if you checked facts before insulting people doing an honnest mistake, due like Roland said, to the fact that there is both a reply-to and a M-F-T and that mutt honours (for some unknown reason) M-F-T before Reply-To. so, *back off*. Pierre, offended. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpPCeN1404Tt.pgp Description: PGP signature
Re: First call for vote on immediate vote under section 4.2.2
On Sat, Oct 28, 2006 at 08:27:30PM +0200, Pierre Habouzit wrote: > On Sat, Oct 28, 2006 at 03:34:34PM +0200, Stefano Zacchiroli wrote: > > It would help if related votes would be kept out of debian-devel. > honnest mistake, due like Roland said, to the fact that there is both a ^^ err Wouter -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpXvEISurTA4.pgp Description: PGP signature
Re: Conditionally applying an architecture-dependent patch
On Mon, Nov 27, 2006 at 07:21:53PM -0500, Daniel Jacobowitz wrote: > On Mon, Nov 27, 2006 at 04:04:41PM -0800, Steve Langasek wrote: > > I would normally recommend quilt, but I'm not sure it has a concept of > > conditional patches, which may make things awkward later if further patches > > are required. > > It doesn't. I think I've seen this done before by processing the > series file. But it's not pretty. well you also can have many series files, the basic one, and the extra one for architecture dependants files. I suppose one could hack quite esaily a makefile using quilt and debian/patches/series + debian/patches/series.$(arch) if it exists e.g. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgppiQDyMFMFD.pgp Description: PGP signature
Re: debian-private and Gmail
On Wed, Dec 06, 2006 at 03:34:49PM +0100, Pierre THIERRY wrote: > Scribit Andreas Tille dies 06/12/2006 hora 14:09: > > > Please ignore paranoid people. > > To be honest you have to regard any nonencrypted mail as world > > readable and you can be nearly sure that all your mails are recorded > > at a place where you have no control over it. > > I thought that very few ISP have really the will and disk space to > record everything that comes from and to their cusotmers. I think every ISP on the planet has the resource to do that for every text-only protocol. Just make the counts, you'll see that's only a few terabytes for a reasonnably sized ISP (if you track only mails, HTTP navigation and things like that) per month, wich on SATA drives costs sth like 500€. Please point me to an ISP that has not the cash to pay 6k€ (even debian can pay that for a RM nowadays) of disks, and maybe the same price for the servers that has them ? that's less than what costs a sysadmin for 3 monthes (from the employer PoV). the point is, ISP are: 1) unaware they have the resource to do it ; 2) don't know how to do it because oracle won't fit on only 1Tbyte hard drive ; 3) oracle is too slow to store all the mails they deal with in a day in less than a week. so I'd say, the real problem with google is that: 1) they are aware that they can log everything with very cheap material (compared to the value of the information stored), 2) they also know *how* to do it efficiently (without oracle) and have the skilled people to do that. 3) they know how to write the tools to analyze those contents and extract the valuable informations from it (not everybody knows how to deal with 1Tb of data). > The real problem with Google seems to be that 1) they have all the > infrastructure needed to keep and use it 2) they clearly state that > they will keep everything. > > Shouldn't that make a difference? no because my neighbour could spy my phone cable (magnetically) and read the ethernet packets to read debian-private when I get the mails arriving to my SMTP (clear text protocol). If someone wants to read debian-private, he just can, if he wants it hard enough. You want truly private debian-private ? then use gpg-encryption, through a mailing list system that would decrypt mails addressed to him with his public gpg-key, and recrypt them to every recipient with the appropriate key. But please, do we really need that ? in fact, if you *really* think debian-private has to be so much protected, then I think we should just close debian-private, because it begins to take too much importance in a project that has among its key principles: transparency and openess. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpDuAFeR1TB2.pgp Description: PGP signature
Re: Bug#403770: ITP: context -- A powerful TeX format
On Tue, Dec 19, 2006 at 07:08:45PM +0100, Norbert Preining wrote: > Hi Frank! > > On Die, 19 Dez 2006, Frank Küster wrote: > > > * Package name: context > > > > Fine :-) > > It is time to get it into Debian I think. It was clear that it wont go > into etch, but I want to see proper context support in lenny, and > neither texlive upstream nor tetex has this. > > Not that I care for ConTeXt, I am not a context user, but I want to have > everything TeX related more or less up2date. > > > > Use ConTeXt to create simple documents and complex layouts. > > > > To me this long description sounds too much like marketing blurb and has > > little information content. The most important question that it should > > answer is "what's the difference to the more known LaTeX?" > > You are heartly invited to write something better, it is all in our svn > repository. I am quite bad in writing stupid texts (better in writing > math) and I just copied the text from the website/description/doc. technically that's hard to do when you don't know it yet ;) the fact that the upstream's website is poorly worded is not a very good excuse. I've read the .pdf manual, and to me it's still unclear why context should be better than the good old latex distro ;) PS: you made a mistake the web site is .nl and not .com -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpRpV5TsTGqf.pgp Description: PGP signature
Re: Bug#403770: ITP: context -- A powerful TeX format
On Tue, Dec 19, 2006 at 09:25:59PM +0100, Stefano Zacchiroli wrote: > On Tue, Dec 19, 2006 at 07:53:30PM +0100, Pierre Habouzit wrote: > > technically that's hard to do when you don't know it yet ;) the fact > > Just googling around I stumbled on this document titled "LaTeX in proper > ConTeXt": > > http://www.berenddeboer.net/tex/LaTeX2ConTeXt.pdf > > It contains also side by side examples with both LaTeX and ConTeXt > sources. oh, good catch, so it appears that the tabular extensions of ConTeXt are even worse than the LaTeX ones, that is quite challenging, and I must say I'm not very convinced by the ConTeXt way to "rewrite" latex into a formatting syntax rather than an environment driven one. eeek. but well, YMMV. anyway, I suppose I'm OT here... -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpo3aWZocUnn.pgp Description: PGP signature
Explications needed...
I happened to have had access to the internet during my vacation, and I happened to read a backlog on #debian-release that frightens me: 15:52 aj | "# unilateral action to run an emulated buildd -- all arm changes sidelined until fixed." 15:52aba | oh, where? 15:52 aj | cron.unchecked, -> queue/delayed [...] 15:58aba | (and btw, I would expect that ftp-master send someone who runs such buildds mail to please stop it ...) [...] 16:18 aj | and now aurel32 will presumably fly off the handle 16:22aba | aj: I don't think that is a good idea either if the porters do uploads - i.e. blacklisting is probably better than whitelisting 16:23aba | aj: and please let e.g. people upload to non-free and experimental, e.g. tbm or kmuto 16:28 aj | aba: not at this time Aurelien mailed debian-arm, went to #debian-arm, had no response. He then warn about his intention [1] to run qemu-based autobuilders to fill the gap due to broken arm buildds. He did that on the open, and got ... zero answers. I must say I'm shocked to see he has not been contacted yet, to kindly ask him to stop. This looks like a petty personnal war, whereas aurelien did a wonderful work. So, why : * does aurelien initiative causes troubles ? * aurelien hasn't been contacted by the ftp-master team first ? aurelien is really easy to contact, so there is no excuse to this completely inadequate behavior. * do someone found the time to blacklist everybody except elmo, whereas no one found the time to fix the arm build daemons ? I also noted that now that only elmo can upload arm packages, the whole arch:any packages migration to testing can be stuck by a single man, I really really ask the DPL that took this decision to (1) reconsider, (2) explain himself about that. Kindly, [1] http://blog.aurel32.net/?p=33 -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp0e7FVPoKzu.pgp Description: PGP signature
Re: Explanations needed...
On Wed, Dec 20, 2006 at 05:03:35PM +0100, Pierre Habouzit wrote: > I happened to have had access to the internet during my vacation, and > I happened to read a backlog on #debian-release that frightens me: > > [...] > > So, why : > * does aurelien initiative causes troubles ? especially since the same is done with aranym for m68k, and it's going to save this port, according to [2] > * aurelien hasn't been contacted by the ftp-master team first ? > aurelien is really easy to contact, so there is no excuse to this > completely inadequate behavior. > * do someone found the time to blacklist everybody except elmo, > whereas no one found the time to fix the arm build daemons ? > > > I also noted that now that only elmo can upload arm packages, the > whole arch:any packages migration to testing can be stuck by a single > man, I really really ask the DPL that took this decision to (1) > reconsider, (2) explain himself about that. > > > Kindly, > > [1] http://blog.aurel32.net/?p=33 [2] http://buildd.debian.org/stats/graph-quarter-big.png -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpchj4imZIWk.pgp Description: PGP signature
Re: Explications needed...
On Thu, Dec 28, 2006 at 04:45:32PM -0800, Steve Langasek wrote: > On Thu, Dec 21, 2006 at 11:39:13AM +0100, Aurelien Jarno wrote: > > All started with this email: > > http://lists.debian.org/debian-arm/2006/08/msg00151.html > > > ARM was *in danger*, a lot of stuff (java, xulrunner, mono, ...) were > > not working correctly. People worked hard to fix that, but it was very > > difficult to get packages depending on fixed stuff to get requeued. Also > > a lot of "arch-specific compile errors" were actually due to build > > daemon problems. > > Yes, let's be clear here: ARM was in danger because of a large number of > packages that were *not buildable*, not just because they weren't built. > The call for help was in identifying the reasons for the build failures so > that the underlying problems could be fixed, *not* for hand-building > packages and ignoring the implications for security support. I feel it's deeper than that: now that aurélien completely stopped to upload non built packages at all (a thing he did on a regular basis before, and just automated with his "rogue" autobuilder) just look at [1], whereas every single arch is keeping up quietly, arm and sparc seem to go to the deepness of hell. I don't know who are the sparc buildd admins, but for sure, the arm port do not seem to be that well. [1] http://buildd.debian.org/stats/graph2-week-big.png -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpQfh48olDgF.pgp Description: PGP signature
Re: db.debian.org (and related infrastructure) updates
On Sat, Dec 30, 2006 at 05:14:30PM +0100, Francois Petillon wrote: > Marco d'Itri wrote: > >For a start that sites performing sender verification will partecipate > >in a DDoS on the mail infrastructure of domains forged by spammers. > [...] > > There are two things I really dislike in sender verification. First, you > are using someone else ressources to fight spam. Second, spammers may > adapt in an annoying way (either they will use domains who always answer > a 2xx to rcpt to, or they will use verified emails). that's true, and IMHO the real reason why sender verify is harmful (the latter, not the former). > >Also, sender verification when seen from the side of the victims is > >indistinguishable from a dictionary attack, and may cause deliverability > >issues to the hosts attempting it. > > I confirm it : we already have blacklisted IPs as they were issuing too > many rcpt-to on not existing emails. These were dued to sender > verifications... yeah, I know, you're very keen on blacklisting the whole earth :] On Sun, Dec 31, 2006 at 03:44:40AM +0100, Francois Petillon wrote: > Josip Rodin wrote: > >Yes. Just like any other large amount of traffic could be harmful on > >big domains. > > I will be more precise. Answering a rcpt-to is, in my case, around 20 to > 30% of the job of the "storage cluster" to deliver a mail (I am not > talking about CPU, just disks IOs). If the number of mails sent as from > our domains is equivalent to the number of mails we receive and if > everybody use sender verify, it would mean we have to increase our IOs > capacity by 20 to 30% (I know, there is 2 "if" and it is a very rough > figure). Then honestly, you have a big problem. On the mail servers I co-administrate, the database lookups that are performed at rcpt-to time are far less CPU-intensive than the clamav check, and the bayesian filter check that are done before our redirection service is activated. If your system is correctly sized, your recipients database should fit in RAM, and rcpt-to lookups costs 0 IO. So that argument is IMHO pointless. > > I guess the counter-argument could be - all those services are > > explicitly created in order to voluntarily serve requests, but > > nobody volunteered their server to answer sender verification > > requests. Yet, a sender verification request is nothing but a > > three-command SMTP conversation. If someone puts an SMTP server > > online, and connects it via DNS, it's not exactly strange that other > > people talk to it. > > No, a rcpt-to is not intended to verify an email but to deliver an mail. > You may use VRFY if you want to 1) verify an email and 2) check if you > are allowed to verify... :-) bwahahaha, I suppose you know the amount of bad faith in such an argument. Every serious SMTP server disables VRFY for obvious reasons. And technically, I don't see which specifical task RCPT-TO should do on your mail server than VRFY would not do. > IMHO, using rcpt-to to verify sender is just like using resume download > to do segmented/parallel downloads. It works but you are using the > command in an perverted/antisocial way. True, that's a perversion of the protocol. Though, you know, a lot of antispam measures are protocol perversions, and should not be used if you are so pure. For example, blacklisting someone because you /think/ he relays more than some fraction of spam[0], by shutting every connection attempt with a 500 error is a very bad RFC violation, specifically prohibited in the rfc 2821, whereas it's completely allowed to issue a QUIT at any point of the SMTP dialog. So sender verifying is at least 100% compatible with the RFC, even if diverting a command[1]. So if you see what I'm alluding to, maybe you should avoid to serve us the SMTP white knight's arguments, from you that seems quite beyond belief. [0] obviously without trying to reach their abuse@ or postmaster@ address before, that would not be enough fun else. [1] For the record, I don't like Sender Verify either, it has very poor properties, but the sole argument against it, that has some kind of value is that spammers can use it the same way to validate their databases. Hence it can make genuine hosts be considered as spammers, and that's A Bad Thing ™. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpEJhQcGOu1n.pgp Description: PGP signature
Re: Proposal for Lenny: Please avoid duplicated changelogs for binary packages sharing the same source package
On Tue, Jan 02, 2007 at 03:44:10PM +0200, Tshepang Lekhonkhobe wrote: > Hi, > > I find it wasteful to install the same changelogs (both Debian and > upstream) in binary packages which share the same sources. Why not > have symlinks in place of these and perhaps an extra /usr/share/doc > directory named the same as the source package in case a binary > package of the same name doesn't exist. > > Maybe this is not the right time but then maybe someone should > convince me that I'm proposing a bad idea. the problem is, you can only do that if you have one of the binary package that is always installed with any of the other, else you will have dangling symlinks, and it's prohibited by the policy (no to mention that it would be quite useless !) Though many packages that do have a foo-common and many foo-* binary packages already symlinks parts of /usr/share/doc/$package/* or even /usr/share/doc/$package itself. If the former has no other limitations than the depends rule, it's not true for the latter, as there is known issues with dpkg handlink migrations from a directory to a symlink (or the reverse I never remember). So when you choose to change your scheme, you need to do that carefully. Finally, TTBOMK debhelper that is the most widely used helper in debian packages do not offers ways to do that in a simple way. I mean you have to craft every symlinks by hand and specifically ask for different dh_installdocs arguments for each of your binary packages. Maybe what could be done is to write a new helper or extend dh_installdocs to have such a behaviour. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgppbnRMQNr90.pgp Description: PGP signature
Re: Proposal for Lenny: Please avoid duplicated changelogs for binary packages sharing the same source package
On Tue, Jan 02, 2007 at 04:28:59PM +0200, Tshepang Lekhonkhobe wrote: > On 1/2/07, Pierre Habouzit <[EMAIL PROTECTED]> wrote: > >On Tue, Jan 02, 2007 at 03:44:10PM +0200, Tshepang Lekhonkhobe wrote: > >> Hi, > >> > >> I find it wasteful to install the same changelogs (both Debian and > >> upstream) in binary packages which share the same sources. Why not > >> have symlinks in place of these and perhaps an extra /usr/share/doc > >> directory named the same as the source package in case a binary > >> package of the same name doesn't exist. > >> > >> Maybe this is not the right time but then maybe someone should > >> convince me that I'm proposing a bad idea. > > > > the problem is, you can only do that if you have one of the binary > >package that is always installed with any of the other, else you will > >have dangling symlinks, and it's prohibited by the policy (no to mention > >that it would be quite useless !) > > Why not have an extra /usr/share/doc/$source-name directory in case a > binary package of the same name doesn't exist or is not found to be > installed. This would be a problem when dependencies change, but on > package removal, /usr/share/doc/$source-name would be left alone if > there remains binary packages built from that source package. That's what $package-common packages are for. But just to hold the copyright and changelog that's an overkill because those packages would need some kind of garbage collection somehow and that i'm quite sure that it would use more mirror resources than the repeated changelogs. Well all in one it's not worth the effort, and has many drawbacks IMHO. I'd say that's a thing you may consider when you already need a $package-common for your packaging, but it's not necessarily a good idea. just to know what we are talking about, on my system: du /usr/share/doc/*/changelog.Debian.gz: 16M du /usr/share/doc/*/copyright: 15M du /usr/lib/iceweasel/firefox-bin: 15M so well, if it's not nothing, it's still quite small, and I can't imagine a system where 30M is an issue nowadays (well except PDA's or so, but here the whole /usr/share/doc is an issue at once anyway, like Don already explained it - on my system /usr/share/doc is 234M big). -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpgIcrXSxfjX.pgp Description: PGP signature
Re: RFC: Proposal for official screenshot repo
On Wed, Jan 03, 2007 at 05:32:52PM -0500, Roberto C. Sanchez wrote: > Today I was trying to explain to a friend the concept of using a package > management front end to search for and install packages. He liked the > idea of descriptions, but found it hard to imagine what some programs > looked like. It occurs to me that what is missing is screenshots. this idea has been discussed recently, I just can't remember when exactly though, I'd say in the late 6 monthes. Maybe you can grab some names of people that were involved in the first proposal there. It may have been proposed on -project rather than devel. But I suppose google will know about it. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpmMZTPILzeF.pgp Description: PGP signature
Re: RFC: Proposal for official screenshot repo
On Thu, Jan 04, 2007 at 12:05:03AM +0100, Nico Golde wrote: > Hi, > * Pierre Habouzit <[EMAIL PROTECTED]> [2007-01-03 23:53]: > > On Wed, Jan 03, 2007 at 05:32:52PM -0500, Roberto C. Sanchez wrote: > > > Today I was trying to explain to a friend the concept of using a package > > > management front end to search for and install packages. He liked the > > > idea of descriptions, but found it hard to imagine what some programs > > > looked like. It occurs to me that what is missing is screenshots. > > > > this idea has been discussed recently, I just can't remember when > > exactly though, I'd say in the late 6 monthes. Maybe you can grab some > > names of people that were involved in the first proposal there. It may > > have been proposed on -project rather than devel. But I suppose google > > will know about it. > > Maybe the following? > http://lists.debian.org/debian-devel/2006/04/msg00915.html > Some replies are not in the thread. > Kind regards > Nico yes, that was it, thanks. the following is on the next month archive, hence why those are missing :) http://lists.debian.org/debian-devel/2006/05/ that was older that what I thought btw :) -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpKSzgsVphxF.pgp Description: PGP signature
Re: FSG Packaging Summit in Berlin
On Thu, Jan 04, 2007 at 04:33:48PM -0700, Jonathan Corbet wrote: > Joey Hess <[EMAIL PROTECTED]> wrote: > > > I'm boycotting feeding any useful information to LWN anymore until they > > retract their latest blanket insult of all DD's and stop being so biased. > > Interesting. It's usually the Fedora folks who complain about bias at > LWN. > > Honestly, I don't see what the problem is here. The text in question is > (presumably): > > Debian will get the Etch release out this year. Honest. What > could possibly go wrong? Thereafter, the Debian developers will > go back to arguing about firmware in the kernel. > > So where is the insult? Certainly it wouldn't be "what could possibly > go wrong?" I don't think I am the only one to notice that Debian > releases do not always happen when people think they might. Remember > that I had previously predicted that the 2006 release date would hold. > > As for the firmware comment: correct me if I'm wrong, but I do believe > that the project, via general resolution, punted the firmware issue > until after the release of Etch. Of course it's going to come back, it > comes back every release cycle. Is it an insult to say that? I suppose the “problem” with the tone that is quite sarcastic. But who can blame you for that ? Not me, it even made me grin while reading it. I'd say some people should try to know how to laugh about themselves and/or grow a skin (not a _harder_ one, just having one should be enough to not feel insulted, merely itched by such a §). Moreover I'd even argue that after all that's a fair answer to some DD trying to pretend (when it was already so obvious to anyone that it would not happen) that we could still release on Dec 4th. One should be able to laugh about his own work, and have some hindsight on his failures. Sorry Joeyh, but Debian's overlong pointless discussions on various lists are what is the most visible from the outside of the project. It's displeasing to the least, but that's still what the people see. Get used to it, or do something to stop such discussions. But AFAICT the firmware one has not been our more brilliant discussion ever, and it's not really an isolated one. I know it seem unfair to be judged after this, but well, you can't blame people for judging the iceberg just looking at what is outside from the see. *shrug* > Honestly, it was not my intent to insult anybody. I'm sorry if I did. > But, being the socially-challenged person I am, I still don't understand > how that could be. heh ;) -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpE0dtK6qszw.pgp Description: PGP signature
Re: Best scheme for teams and Maintainer/Uploaders fields ?
On Mon, Jan 08, 2007 at 09:03:03AM +0100, Lucas Nussbaum wrote: > Hi, > > I'm a member of the pkg-ruby-extras team. In this team, we use the > following scheme for the Maintainer and Uploaders fields: > Maintainer: "main responsible person for the package" (ie best contact > point) > Uploaders: the team mailing list, + all the members of the team > (auto-generated using a cdbs rule) > > This is not optimal: > - this generates very long DDPO pages, with lots of packages people > don't care about: > http://qa.debian.org/[EMAIL PROTECTED] > - it's difficult to keep track of who is caring for that package (hint: > QA, MIA, ...) > > The perl team, on the other hand, uses the different scheme: > Maintainer: "main responsible person for the package" > Uploaders: the team mailing list, + members who actually care for the > package (who have touched it in the past, for example). > > This leads to much shorter and interesting DDPO pages, without any > drawback I can see (the "all packages from the team" DDPO page is still > available using the the team mailing list address). in the KDE Team we use: Maintainer , Uploaders . The list beeing [EMAIL PROTECTED] or [EMAIL PROTECTED] But that's roughly like the perl pkg group, and that's IMHO the sanest way. That do not mean that people from the team only work on "their" packages at all, that just set the name of those who worked the most on them, and that are responsible for QA and so on. In a packaging group, the rule that shall be implicit is that everybody can touch "everybody's" package, except if specifically documented so (with an excellent rationale, and I must say I don't see any that would be good enough ;p). So IMHO, yes, the perl approach is way better. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpWYcSQgsiFJ.pgp Description: PGP signature
Re: Your message to Pkg-ruby-extras-maintainers awaits moderator approval
On Mon, Jan 08, 2007 at 09:41:59AM +0100, [EMAIL PROTECTED] wrote: > Your mail to 'Pkg-ruby-extras-maintainers' with the subject > > Re: Best scheme for teams and Maintainer/Uploaders fields ? > > Is being held until the list moderator can review it for approval. > > The reason it is being held: > > Post by non-member to a members-only list > > Either the message will get posted to the list, or you will receive > notification of the moderator's decision. If you would like to cancel > this posting, please visit the following URL: > > > http://lists.alioth.debian.org/mailman/confirm/pkg-ruby-extras-maintainers/90c2cecc7206ab9c13d95ef7ea56388e54029c3c That becomes tiredsome. Once again, I really think that the list used as a primary contact for packaging shall not be moderated. Alioth has quite reasonable antispam measures, so that's really not needed. I know people say "well if the list is moderated quick enough blahblahblah..." but : - mailman does not sent 'your mail has been accepted' notifications, hence it looks like the mail stays there forever ; - that makes a mail the user does not really expect, and with the current spam rates, one-more-mail is painful ; - that looks very rough and disordered ; - ... PLEASE do NOT moderate lists that are listed as a Maintainer/Uploader. If you still want to do so, PLEASE STOP sending the notifications, those are useless, painful, Thanks... again. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpxg69fT4D5H.pgp Description: PGP signature
Re: Best scheme for teams and Maintainer/Uploaders fields ?
On Mon, Jan 08, 2007 at 11:24:50AM +0100, Stefano Zacchiroli wrote: > On Mon, Jan 08, 2007 at 09:03:03AM +0100, Lucas Nussbaum wrote: > > - it's difficult to keep track of who is caring for that package (hint: > > QA, MIA, ...) > > Uh? Why? Your maintainer field seems to address this issue. In our > scheme that's would be more a problem, but if the mailing list is > responsive it's enough. Think for example at the debian-release mailing > list: it's a list, but it's really responsive for all packages in the > archive. So IMO not being able to identify a single person is not > necessarily an indicator of unresponsiveness for a given package. What he means is that when people are listed automatically as Maitnainer/Uploader, the fact that the package is well maintained may hide that a particular DD do nothing at all, and is in fact MIA. Last-action of a DD is computed using many ways, uploads of package where he is in Maintainer/Uploader beeing among them, and it hides real MIAs from the mia tracking scripts, and that's bad, because it prevent good QA work, and generate more and more bitrot. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpnTSDsXuG1j.pgp Description: PGP signature
Re: Best scheme for teams and Maintainer/Uploaders fields ?
On Mon, Jan 08, 2007 at 09:42:11AM -0600, Gunnar Wolf wrote: > Pierre Habouzit dijo [Mon, Jan 08, 2007 at 11:58:49AM +0100]: > > > Uh? Why? Your maintainer field seems to address this issue. In our > > > scheme that's would be more a problem, but if the mailing list is > > > responsive it's enough. Think for example at the debian-release mailing > > > list: it's a list, but it's really responsive for all packages in the > > > archive. So IMO not being able to identify a single person is not > > > necessarily an indicator of unresponsiveness for a given package. > > > > What he means is that when people are listed automatically as > > Maitnainer/Uploader, the fact that the package is well maintained may > > hide that a particular DD do nothing at all, and is in fact MIA. > > > > Last-action of a DD is computed using many ways, uploads of package > > where he is in Maintainer/Uploader beeing among them, and it hides real > > MIAs from the mia tracking scripts, and that's bad, because it prevent > > good QA work, and generate more and more bitrot. > > Umh... Then, I think the MIA-calculation ways are the broken ones, not > the team maintainership options. Developer activity should be done > checking either who signed the package, or at the very least, who's > name is reported on each of the changelog's entries - But basing it on > the Uploaders field is just asking for trouble. Team maintainership is > just a way to make MIA people hurt Debian _less_, not more! :) technically that would be mean to a lot of person too. In the KDE team, there was very few DD once, and the people that signed the packages is always the same, and not necessarily the one that worked on it. Moreover, changelogs are not very easy to parse to find who contributed for real, the [ John Doe ] way is quite used, but it's not the sole one, and KDE does not uses it e.g. and I would not be surprised other package groups do not either. So that would be quite unreliable too ;) the problem is less easy that what it seems, and well, doing some cleansing in Uploaders/Maintainer is the right way. And if someone is offended to be removed from such a place, then it's that he's not _that_ MIA after all ;) -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpENrgQM0sBZ.pgp Description: PGP signature
amd64 uploads
It looks like that the archive has now been built, and that only newly uploaded packages, and packages that Dep-Wait on Failed builds remains. Maybe is it time to authorize amd64 uploads ? Moreover, looking at [1], there is a quite rather impressive list of package that FTBFS since ages, that are apparently unmaintained, and whose maintainer looks like to be MIA since more than a year (all packages are the same version as in stable, or NMU-ed, and a lot of important — or higher severities — opened bugs for more than a year, not to mention the ones that are tagged 'patch'). e.g. looking at the bugs which number is strictly less than #30 gives already a list of unmaintained and bitrotten packages. Some even don't deserve to be NMU-ed and should IMHO be removed from the archive. Some other are buggy enough to be barely usable, and would need a maintainer to fix them. I suppose there is some stubs here to do some MIA-hunt and cleaning of the archive. [1] http://buildd.debian.org/stats/?arch=amd64&state=Failed regards, -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp067b3rHxGu.pgp Description: PGP signature
Re: amd64 uploads
Le Ven 7 Avril 2006 20:33, Kurt Roeckx a écrit : > > A lot of the others simply need to desupport old versions of > > Python. > > python2.1 and 2.2 are supposed to be removed soon, but both > currently fail to build. There are lots of packages that build > depend on those that should get changed. They all have open > bugs. I'd welcome anyone that fixes a few of those. what's the policy about them ? should the packages be built for python 2.3 and 2.4 ? only for 2.3 ? only for 2.4 ? and currently bugs like #351145 are only normal bugs. is it okay to nmu in delayed/7 without warning ? If yes, you can count on me -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpUUDebxKOwj.pgp Description: PGP signature
Re: amd64 uploads
Le Dim 9 Avril 2006 14:18, Kurt Roeckx a écrit :
> On Fri, Apr 07, 2006 at 09:47:25PM +0200, Pierre Habouzit wrote:
> > Le Ven 7 Avril 2006 20:33, Kurt Roeckx a écrit :
> > > > A lot of the others simply need to desupport old versions of
> > > > Python.
> > >
> > > python2.1 and 2.2 are supposed to be removed soon, but both
> > > currently fail to build. There are lots of packages that build
> > > depend on those that should get changed. They all have open
> > > bugs. I'd welcome anyone that fixes a few of those.
> >
> > what's the policy about them ?
> >
> > should the packages be built for python 2.3 and 2.4 ? only for 2.3
> > ? only for 2.4 ?
>
> I guess it depends on the package. Currently the default seems
> to be 2.3, but if it supports multiple versions, adding 2.4
> probably won't hurt.
>
> > and currently bugs like #351145 are only normal bugs. is it okay to
> > nmu in delayed/7 without warning ?
>
> See:
> http://lists.debian.org/debian-release/2006/04/msg5.html
okay, I've send delayed/7 NMUs for python packages in Dep-Wait of
python2.{1,2}-dev. (actually I have still 5 to do, but that will be
soon OK).
I've not touched decompyle2.2, boot-floppies, libapache{,2}-mod-python,
that hadn't any bug open related to python2.1 and python2.2 drop. I've
(currently at least) not opened bugs to those 4 packages, feel free to
do so.
Cheers,
--
·O· Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org
pgpelhTGgTZ1q.pgp
Description: PGP signature
