Re: Regarding unresponsive Debian maintainers
* Cesar Martinez Izquierdo | I don't think co-maintenance needs to be a "must", but I totally | agree that is always possitive and it should be encouraged someway. No, it is not always positive. Co-maintainence means you have a way, way higher overhead at maintaining the package. I don't have to coordinate uploads, checkins and so on with myself, for packages with comaintainers, I do. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#274859: [help needed] RAID and /dev advice needed
also sprach Neil Brown <[EMAIL PROTECTED]> [2005.05.24.0258 +0200]: > > Neil? Is there a good reason for lstat here? It apparently breaks on > > devfs. (Ref. http://bugs.debian.org/274859) > > No, it is a bug. It should be 'stat', not 'lstat'. This seems trivial enough. I am running a test now. Thanks. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! "gilmour's guitar sounds good whether you've got a bottle of cider in your hand or a keyboard and a mouse." -- prof. bruce maxwell signature.asc Description: Digital signature
Re: Bug#274859: [help needed] RAID and /dev advice needed
also sprach martin f krafft <[EMAIL PROTECTED]> [2005.05.24.1028 +0200]: > This seems trivial enough. I am running a test now. Seems to work; thanks Peter! Rockin'! -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! "the perfect gun is an idealist without any ideal." -- mc 900 ft jesus signature.asc Description: Digital signature
Re: Regarding unresponsive Debian maintainers
On Tue, May 24, 2005 10:27, Tollef Fog Heen wrote: > No, it is not always positive. Co-maintainence means you have a way, > way higher overhead at maintaining the package. I don't have to coordinate > uploads, checkins and so on with myself, for packages with comaintainers, > I do. It does not have to be if you manage it the right way. One can think of several solutions where you don't have high overhead. The type of co-maintenance depends per package and per developer, but I'm positive there is a good way to be found for any package. Examples: - A situation where the maintainer has the full control, and co-maintainers are a kind of "helpers". Two forms of this: 1) The maintainer has full control over uploads, the co-maintainer(s) only do bug-triage, or commits to the repo. 2) An option is that the co-maintainer only uploads when the regular maintainer does not, ie is away for a week, or has indicated to be too busy. This of course requires the main maintainer to be active, the co-maintainers here serve to reduce the load on maintaining and as a second set of eyes. - You can have a situation where the maintainer in general does all the work, the co-maintainer just watches and only jumps in when the maintainer is temporarily unavailable (eg on a holiday, overloaded or missing). - When you known you can have quick contact with your co-maintainer, co-ordinating uploads is really easy (eg on irc, jabber or down the hallway), so here overhead is very minimal. For my packages I coordinate all uploads with the comaintainer because I have to (as a sponsor), but I notice that this doesn't take a lot of time at all. - The package is large and multiple (co)maintainers can do uploads, this needs more coordination but for larger packages this is time well spent. - A good situation is also where the co-maintainer is someone from upstream. The maintainer knows about Debian and its policies, packaging and the like. The upstream person follows up on bugreports, knows which have been fixed already, can provide patches from upstream or can fix the problem upstream right away. Concluding, I think the overhead can be minimal, is outweighed by the general improvement in package quality I expect. regards, Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Changes to the weekly WNPP posting
* Tollef Fog Heen <[EMAIL PROTECTED]> [2005-05-20 09:55]: > Throw in a link to the full list for RFA/O/RFH too? Apart from > that, I'd love to see it on d-d-a. I've done that now and will send the posting to -devel. I'm not sure about d-d-a yet but that can easily be changed later. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Regarding unresponsive Debian maintainers
On Tue, May 24, 2005 at 02:01:55AM +0300, Cesar Martinez Izquierdo wrote: > I think Debian would be healthier if tags were properly used in DBTS (as this > helps others to also fix bugs). I'd be really surprised if the major obstacle we're facing with regard to bug fixing were procedural things like this. Things like this can be helpful in locating things that might be interested in the BTS but they aren't a precondition for being able to do bugfixing work. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: depending on shared libbfd from binutils-dev
On Mon, May 23, 2005 at 07:54:53PM -0400, Daniel Jacobowitz wrote: > > Because libbfd does not have a stable ABI suitable for public use, nor is > > there currently a way to express a dependency on this library without > > things breaking (you can't depend on "binutils" and have any guarantee of > > getting the correct lib). > > Does make me wonder why we ship libbfd.so and libopcodes.so, instead of > just the static libraries. To reduce the size of the binutils package, iirc. It has about a dozen binaries, all of which need libbfd. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: Proposal: Bringing volatile in shape for sarge
Another package for the 'volatile' or 'volatile-sloppy' list would be iso-codes. One purpose of the iso-codes package is to separate out data that would change over the course of a distribution, such as country and currency names, from applications that may use that data. Some applications may break if a new currency name, for example, appears. As iso-codes contains only the data and translations of the data, it should be safe by design to upgrade. Regards Alastair McKinstry On Tue, 2005-05-24 at 10:31 +0200, Andreas Barth wrote: > Hi, > > finally, sarge is about to release. As that happens, we had some more > discussions with people as volatile is going to be really live soon; > volatile is also mentioned in the release notes. > > Some topics have been brought to our attention, and we plan to solve them > all in May, so that we are ready when sarge is ready. > > > gaim, ...: volatile-sloppy > ~~ > Once again, we were asked whether we would accept updated gaim packages > during sarges lifetime. Gaim (and similar applications) are punished by > trying to support special protocolls like Yahoo messenger, which are broken > by purpose from time to time. As the only fix to get them life again is > usually to upgrade to a fairly recent version, this is not acceptable for > volatile in the stricter definition; however, we believe that enough people > want such a package so that it should be supported somehow. > > For that reason, we intend to add a second part to the archive, called > "sloppy" for now (but we're still open to any change in the name). The > relevant criterias for "sloppy" will be the same as for the normal > volatile, just that we are not as strict regarding function enhancements. > > Matching to that, we plan to create a Release-file that pins that archive > down in apt, so that any administrator need to decide for himself what to > take. Other suggestions for the name include current and HEAD. > > For packages even unfitting for that category, we might send out > recommendations to update that package, and identify where to get > updated package, like backports.org; but of course, this can even be > decided after sarge is out. > > > announcements > ~ > Of course, that brings us the next questions: We need a proper list for > announcements, and we plan to also add an RSS-feed with the updates. Any > ideas, recommendations etc are welcome. > > > archive structure > ~ > well, the basic question is, what should the users add to > /etc/apt/sources.list. We currently tend to something like > deb http://$mirror/debian-volatile sarge/volatile main and for sloppy > deb http://$mirror/debian-volatile sarge/volatile/sloppy (and for the > proposed updates deb http://$mirror/debian-volatile sarge/volatile/proposed). > > Of course, feel free to cluebat us if you have better ideas. > > > timeline > > We want to make all decisions till Thursday evening (UTC), and the > implementations should be done at least to the stage users can use that > sources-lines by Friday evening, so that we can have proper testing. > > > example packages > > For some packages, the discussions are nearly finished on getting them into > volatile-sarge soon: > > - clamav-data: this package is for people who want the anti-virus pattern > as debian package, and not use clamav-freshclam. We tend to give Marc > Haber as maintainer the possibility to update the package by himself, and > this will probably happen once a day. As very large exception, that > package won't create any of the usual announcements. > > - gaim. Well, see above. > > > So, that's for now. We appreciate your feedback. > > > Cheers, -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Increase the length and girth of your penis^
Wanna be more man? Check this dude http://www.terima.net/ss/ Bro check out this awesome new product -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
bts ldap interface: future developments ...
Hi, I put some time into investigating possible tweaks to make the queries faster. Apart from getting sarges sldap installed, the main performance boost can be done by removing/hiding the archived bug reports. Also, by getting them removed from the db-file, the memory requirements will shrink drastically. For that reason, I consider to drop the old entries from the main file, and stick them to a text file so that searches in the archived bugs take even longer than today, but all others would be really fast. The problem with that is of course that bugs change their DN on archiving. If there is any idea to achieve these goals without that problem, I woudl appreciate very much to hear about them. Opinions, further suggestions? Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bts ldap interface: future developments ...
hi andreas, On Tue, May 24, 2005 at 05:14:50PM +0200, Andreas Barth wrote: > For that reason, I consider to drop the old entries from the main file, > and stick them to a text file so that searches in the archived bugs take > even longer than today, but all others would be really fast. The problem > with that is of course that bugs change their DN on archiving. i'm not convinced that changing the DN's for archived bugs is necessarily a bad thing (i know it usually is frowned upon) though if that were to happen, couldn't it be offloaded into a different base DN but still kept within the gateway? for example, say you have ou=bugs,dc=debian,dc=org adding a ou=archived,ou=bugs,dc=debian,dc=org and then changing the dn of bugs to point there would keep them out of the main bugs bucket, which would get the speed boost for people properly doing scope=one searches, and people who wanted to search everything could do a scope=sub on the base dn. > Opinions, further suggestions? - what are you currently doing wrt indexing? - what underlying db format are you using? sean -- signature.asc Description: Digital signature
Re: bts ldap interface: future developments ...
* sean finney ([EMAIL PROTECTED]) [050524 17:40]: > On Tue, May 24, 2005 at 05:14:50PM +0200, Andreas Barth wrote: > > Opinions, further suggestions? > - what are you currently doing wrt indexing? For the "fast one", indexing almost everything on equal and presence (Bugid, tags, status, Package, SourcePackage, Severity, MergedWith), and some (like Done) only on Presence. > - what underlying db format are you using? My tests were done with bdb. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: depending on shared libbfd from binutils-dev
On Tue, May 24, 2005 at 01:43:12PM +0100, Andrew Suffield wrote: > On Mon, May 23, 2005 at 07:54:53PM -0400, Daniel Jacobowitz wrote: > > > Because libbfd does not have a stable ABI suitable for public use, nor is > > > there currently a way to express a dependency on this library without > > > things breaking (you can't depend on "binutils" and have any guarantee of > > > getting the correct lib). > > > > Does make me wonder why we ship libbfd.so and libopcodes.so, instead of > > just the static libraries. > > To reduce the size of the binutils package, iirc. It has about a dozen > binaries, all of which need libbfd. No, that's why we ship libbfd-2.15.so; I was wondering why we need to ship the libbfd.so symlink. Yes, I'm familiar with how much space it saves to use a shared libbfd :-) -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Our service is user-friendly, discreet and completely confidential
Little magic. Perfect weekends. http://accessible.megaheals.info/?stabilextvuywadezvpprefaced Strong enough for a men, but made for a women -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
People Laugh at You? 16S
The Only Clinically Tested Penis En_Largement Products! - Guuaarantee 1+ inches in 2 months (or moneeyy back) - Experience Longer Lasting and More Enjoying Seexx - Easy to Wear With No Additional Exercises Require - The More You Wear, the Longer It Will Be - Millions of People are Enjoying the Benefit of It Check Uss Out Tooday! http://gallanted.com/extender/?ronn o-ut of mai-lling lisst: http://gallanted.com/rm.php?ronn z8IaDz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug in Radeon in kernel 2.6.8?
I have just finished compiling both the 2.6.6 and 2.6.8 kernels and there appears to be a bug in the radeon_state piece of code in the 2.6.8 kernel that is absent in the 2.6.6 kernel. I receive the following compilation errors (2.6.8) CC drivers/char/drm/radeon_state.o drivers/char/drm/radeon_state.c: In function `radeon_cp_cmdbuf': drivers/char/drm/radeon_state.c:2316: warning: implicit declaration of function `drm_alloc' drivers/char/drm/radeon_state.c:2316: warning: assignment makes pointer from integer without a cast drivers/char/drm/radeon_state.c:2416: warning: implicit declaration of function `drm_free' That are absent from the compilation of 2.6.6. This leads to drivers/built-in.o(.text+0x51d71): In function `radeon_cp_cmdbuf': : undefined reference to `drm_free' drivers/built-in.o(.text+0x51daf): In function `radeon_cp_cmdbuf': : undefined reference to `drm_free' drivers/built-in.o(.text+0x524a7): In function `radeon_cp_cmdbuf': : undefined reference to `drm_alloc' make: *** [.tmp_vmlinux1] Error 1 I can remove these errors by not using the CONFIG_DRM_RADEON option. In the make menuconfig proceedure, this amounts to just saying no to ATI Radeon in the Character devices menu that is under the Device Drivers option of the main menu. Art Edwards -- Art Edwards Senior Research Physicist Air Force Research Laboratory Electronics Foundations Branch KAFB, New Mexico (505) 853-6042 (v) (505) 846-2290 (f) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
sarge upgrade issue. perl 5.6->5.8 and libdb4
I just ran through a woody-sarge update, and (temporarilly) lost a number of perl databases that an unpackaged app had created. Took me quite a while to figure out exactly what happened, more time than a user should normally be expected to put into debugging I think. Woody's perl 5.6 uses libdb2. Sarge's uses libdb4. libdb4 cannot natively open databases created with libdb2, and while this point is stated in perl's changelog, I don't believe most users will read all 20 pages of changelog entries that have occured since then, and there appeared to be no notification in the process of the upgrade that such an issue would take place. There is an upgrade script available, but afaict it's only reference is buried deep in that changelog. Sounds like a perfect place to use a NEWS.gz file and apt-listchanges, if there's a way to enforce the installation of apt-listchanges. Comments? signature.asc Description: This is a digitally signed message part
Bug#310648: ITP: libchemistry-elements-perl -- Perl extension for working with Chemical Elements
Package: wnpp Severity: wishlist Owner: Carlo Segre <[EMAIL PROTECTED]> * Package name: libchemistry-elements-perl Version : 0.91 Upstream Author : brian d foy <[EMAIL PROTECTED]> * URL : http://www.cpan.org/authors/id/B/BD/BDFOY/ * License : GPL / Artistic Description : Perl extension for working with Chemical Elements Chemistry::Elements provides an easy, object-oriented way to keep track of your chemical data. Using either the atomic number, chemical symbol, or element name you can construct an Element object. Once you have an element object, you can associate your data with the object by making up your own methods, which the AUTOLOAD function handles. Since each chemist is likely to want to use his or her own data, or data for some unforesee-able property, this module does not try to be a repository for chemical data. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11-1-k7-smp Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: FW: Processing of tla-load-dirs_1.0.21ubuntu1_source.changes
On Sun, May 22, 2005 at 03:56:35PM -0500, John Goerzen wrote: > Can anyone tell me what this means, and who is trying to upload this to > Debian without even sending me a patch first? What it means: the Ubuntu maintainer for tla-load-dirs (sorry, don't know who) managed to send their package in the direction of the Debian upload queue instead of the Ubuntu one. I'm not sure why this happens, because an Ubuntu maintainer should (I presume) change their dput/dupload defaults to Ubuntu, and the dput/dupload packages in Ubuntu should probably have their defaults changed to Ubuntu, not Debian. As for the who, it should be easy enough to work out either from the given public key ID: > gpg: Signature made Sun May 22 14:24:08 2005 EDT using DSA key ID C5AA2301 or, alternately, using the packages.debian.org equivalent (it may have moved to packages.ubuntu.com by now; if not, it has been mentioned here in the past but I can't remember what the temporary URL is). If I were online at the moment I'd hunt up the info for you, but I'm in a train tunnel as I type. - Matt signature.asc Description: Digital signature
Huuge Penis mw
The Only Clinically Tested Penis En_Largement Products! - Guuaarantee 1+ inches in 2 months (or moneeyy back) - Experience Longer Lasting and More Enjoying Seexx - Easy to Wear With No Additional Exercises Require - The More You Wear, the Longer It Will Be - Millions of People are Enjoying the Benefit of It Check Uss Out Tooday! http://gallanted.com/extender/?ronn o-ut of mai-lling lisst: http://gallanted.com/rm.php?ronn G0td -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#310665: ITP: cl-rfc2388 -- an implementation of RFC 2388 in Common Lisp
Package: wnpp Severity: wishlist Owner: Peter Van Eynde <[EMAIL PROTECTED]> * Package name: cl-rfc2388 Version : x.y.z Upstream Author : Name <[EMAIL PROTECTED]> * URL : http://www.example.org/ * License : (GPL, LGPL, BSD, MIT/X, etc.) Description : an implementation of RFC 2388 in Common Lisp rfc2388 is an implementation of RFC 2388, which is used to process form data posted with HTTP POST method using enctype "multipart/form-data". . The main functions of interest are PARSE-MIME and PARSE-HEADER. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11.10-my7 Locale: [EMAIL PROTECTED], LC_CTYPE=it_IT (charmap=UTF-8) (ignored: LC_ALL set to it_IT.UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
