RFC on MBF (non-freeness of The Software shall be used for Good, not Evil)
Hi, Ansgar has recently made an MBF against all packages including the problematic JSON license term The Software shall be used for Good, not Evil. From what I've seen, most - if not all - of the affected packages are using in-source libraries copyright JSON.org, which AFAIK means convincing a single author to relicense would be enough (though IANAL, of course). Thomas Koch tried solving this issue more than two years ago[0] and upstream was apparently unwilling. Should we maybe try again? As Ansgar mentioned in one bugreport, the license is considered non-free not only by us, but by Fedora as well[1] (and it's also notOSI-recognized), so I'm hoping we might have some leverageif we try again with enough finesse and persuasion. This affects a lot of packages and at least in my case (transmission) itseems impracticable to replace the library for wheezy and it's unfortunately too deeply wound with transmission itself to be simply removed. So I'll probably be forced to move the package to non-free, which would really be a shame (specially considering its big popcon). Anyone interested in giving this another try? DPL, you're pretty eloquent and your voice may carry some extra weight? ;) Cheers [0] http://lists.debian.org/debian-legal/2010/03/msg00064.html [1] http://fedoraproject.org/wiki/Licensing:Main#Bad_Licenses signature.asc Description: OpenPGP digital signature
Bug#677750: RFH: gnokii -- Datasuite for mobile phone management
Package: wnpp Severity: normal Hi, I haven't had the need to use gnokii for years and am currently a bit too swamped with Real Life™ to dedicate the necessary time to its packaging, even though it's relatively low-maintenance. If there's anyone out there who still uses gnokii and has the time to lend a hand, your help would be really appreciated! Cheers Leo -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120616173614.3778.98541.reportbug@inertia.local
Re: on the use of chmod/chown in maintainer scripts
Hi, On 12/05/12 12:23, Peter Palfrader wrote: This may not be entirely trivial to solve. find | xargs constructs at best mitigate this to a race. While chown does have a --no-derefence flag, this does not protect us in the case of hardlinks. chmod has no such flag, and it'd useful only for symlinks anyway. Neither tool has a --only-if-link-count-is-one flag. From find(1): -links n File has n links. So I guess this specific problem could theoretically be solved this way. However, I'm actually also for a more general solution, as being discussed for dpkg or at least debhelper. Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/joogrv$go4$1...@dough.gmane.org
Re: Bug#663017: ITP: transmission-remote-cli -- ncurses interface for the Transmission BitTorrent daemon
On 08/03/12 13:59, Jonathan McCrohan wrote: Shouldn't it be included in the transmission-cli package instead? I guess it could be included in transmission-cli. I thought transmission-remote-cli would be better suited to its own package because it a third-party transmission tool, and not part of the transmission project itself [1]. I agree it's probably better to have its own package. I also have an ITP for transmission-remote-gtk, which is in a similar situation. That being said: I haven't checked the source, but I'm a bit curious about its use of transmission-remote. Does it depend on specific input/output formats? Did upstream at some point declare a stable API for using transmission-remote in scripts? I'm just worried this might be a small nightmare to maintain in the long run... Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f58c0e5.4070...@debian.org
Bug#660654: ITP: binwalk -- tool for searching binary images for embedded files and executable code
Package: wnpp Severity: wishlist Owner: Leo 'costela' Antunes cost...@debian.org * Package name: binwalk Version : 0.4.2 Upstream Author : Craig Heffner heffne...@gmail.com * URL : http://code.google.com/p/binwalk/ * License : Expat Programming Lang: C Description : tool for searching binary images for embedded files and executable code Binwalk is a tool for searching a given binary image for embedded files and executable code. Specifically, it is designed for identifying files and code embedded inside of firmware images. Binwalk uses the libmagic library, so it is compatible with magic signatures created for the Unix file utility. . Binwalk also includes a custom magic signature file which contains improved signatures for files that are commonly found in firmware images such as compressed/archived files, firmware headers, Linux kernels, bootloaders, filesystems, etc. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120220163751.28342.16700.reportbug@motion.local
Re: /var/lib/transmission-daemon directory ownership
Hi, On 01/11/11 11:09, Дмитрий Матросов wrote: Now in debian squeeze ownership of /var/lib/transmission-daemon folder is set to 'root:root' snip but, i think, it should be set to 'debian-transmission:debian-transmission'. Also, i think that home folder of user 'debian-transmission' should also be set to '/var/lib/transmission-daemon' instead of '/home/debian-transmission'. Unless you see a security risk, I don't see this being changed for squeeze. As for the sid/experimental, what's your reasoning for the change? The idea behind this is not logging in as debian-transmission (hence the shell:/bin/false), so there is little incentive for having an existing home dir, specially since transmission-daemon should really only create files in the directory passed with --config-dir (otherwise, we'd have /var/lib/transmission-daemon/.config, which IMHO isn't a good idea). I am, however, open for suggestions. Cheers PS.: was it really necessary to include d-devel on this discussion? I hardly see it as a subject worthy of open discussion or as a point of contention. -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4eafe6c6.2090...@debian.org
Call for testing: libevent 2.* in experimental
Hi all, There's been a new version of libevent in experimental for a while (2.0.*) and I'd like to upload it to unstable as soon as possible (and green-lighted by the release team). To achieve that I'd like to ask all maintainers of packages depending on libevent to test their packages against the new version and report any problems. I've taken the liberty of CC'ing maintainers whose packages had FTBFSs with the new version (tested in a clean experimental pbuilder; see below for details). There's also a transition bug[0] open to keep track of the issues, so please CC it when appropriate. Only 7 from the 32 fail to build(tests performed a couple of weeks ago): beanstalkd:syntax error; maybe using some changed define? ladvd: builds correctly, fails on 1 of 6 tests (HTTP request failed) forked-daapd: [already discussed with maintainer; next version will drop dependency] python-event: bona fide build failure (I couldn't grok the underlying reason just by looking at the log) memcached: ditto lua-event: ditto honeyd:doesn't seem related (configure: error: Couldn't figure out how to access libc; maybe related to multiarch) More details about what's changed in the 2.* series and might cause problems can be seen in the whatsnew-2.0.txt file in libevent-dev's docs. Cheers [0] http://bugs.debian.org/631018 -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e0f4f27.5070...@debian.org
Bug#630789: ITP: transmission-remote-gtk -- GTK remote control for the Transmission BitTorrent client
Package: wnpp Severity: wishlist Owner: Leo 'costela' Antunes cost...@debian.org * Package name: transmission-remote-gtk Version : 0.5.1 Upstream Author : Alan Fitton a...@eth0.org.uk * URL : http://code.google.com/p/transmission-remote-gtk/ * License : GPL-2+ Programming Lang: C Description : GTK remote control for the Transmission BitTorrent client [from the site:] transmission-remote-gtk is a GTK application for remote management of the Transmission BitTorrent client via its RPC interface. * remotely add (file/url), start, stop, remove, remove delete, verify, reannounce torrents. * works as a .torrent handler (eg. from a web browser). * set torrent properties such as speed, seed, peer limits, file priorities, add/edit/remove trackers. * change remote settings like global limits, download directory, and connectivity preferences. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110617114349.29186.24551.reportbug@motion.local
RFH with a couple of packages
Hey, I've recently been having some problems keeping up with my basic debian duties, being overwhelmed by Real Life™ issues, so I thought it would be a good idea to ask for co-maintainers for a couple of my packages. I still very much want to keep maintaining them and would also accept team-maintenance, but I'll admit I'm a bit wary of big teams - where the responsibility can be pushed around too much - and would therefore prefer small teams if possible. The biggest problem is transmission[0]. It's not a complicated package, but it has a few FTBFSs for which I simply don't have the time right now. Upstream is very responsive, friendly and even proactive about debian bugs, so it's really just a matter of man-power. The second item in my list is the statusnet ITP[1]. It has a relatively long story, including a packaging attempt by upstream (Evan is a DD), but it's been kinda stuck lately. The git repo in collab-maint included upstream's repo, so I decided it would be cleaner to create a new one with just debian stuff, which is currently here[2]. AFAICS the only thing missing for a first upload is the debian/copyright file, but since I've been pulling some late shifts for debian work lately, the chance is pretty high I forgot something important. And since I'm already on the subject: I also have a couple of RFAs for packages which probably deserve removal in the long run, but in case there's anyone interested... Cheers [0] http://packages.qa.debian.org/t/transmission.html [1] http://bugs.debian.org/491723 [2] git://git.debian.org/~costela/public_git/statusnet.git -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4db5664c.20...@debian.org
Re: Bug#621833: System users: removing them
On 12/04/11 22:43, Scott Kitterman wrote: Also, we need to provide a way for sysadmin to know they can safely remove a stale system user. If we could do that, we could just remove them automatically and not bother the sysadmin. Not necessarily. We can't be sure there aren't any files lying around (at least not efficiently enough) to cause problems with UID reuse etc, but we may inform the admin that at least from the packaging point of view, the user/group isn't needed anymore. He can then decide to take appropriate action if he feels the house-keeping is necessary. It could simply be a matter of using the User Name/Comment field to write something like formerly used by package X; may be removed. Admittedly not strictly necessary, but nice for those cases where you check your /etc/passwd a few years later and ask yourself where that user came from. Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4da61068.8000...@debian.org
Re: chromium-browser is taking over all URLs
On 11/02/11 16:49, Norbert Preining wrote: On Fr, 11 Feb 2011, Cyril Brulebois wrote: $ grep x-scheme-handler/http /usr/share/applications/mimeinfo.cache x-scheme-handler/http=midori.desktop;chromium-browser.desktop; x-scheme-handler/https=midori.desktop;chromium-browser.desktop; And it takes precedence over what you quoted. Thanks a lot!!! Ahhh, and how does one fix that? This is misbehaviour. Whom should this bug reported to? mime or chromium? I noticed the same issue here a few days ago. Adding the x-scheme-handler/http;x-scheme-handler/https; entries to iceweasel.desktop doesn't really solve the issue, because there doesn't seem to be a mechanism to define priorities in update-desktop-database, so gvfs-open uses the first entry in mimeinfo.cache. I'd say it should probably be reported as a minor bug in gvfs-open, to respect gnome settings before falling back to mimeinfo.cache. Thoughts? Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ij3n4d$jes$1...@dough.gmane.org
Re: Essentiality of Bash
On 12/06/10 21:00, Magnus Holmgren wrote: Beyond making dash the default /bin/sh, which has already happened, is it (still) a long-time goal to make bash not Essential, or did I dream that? Because if it is, getting there means adding a lot of Depends: bash first, and so Lintian should probably add an exception to the (build-)depends-on- essential-package-without-using-version check. AFAIK it's been demoted as the standard script-shell, but it's still the standard login-shell, so I don't see it being demoted from the essential set anytime soon. At least not in Debian, but that may be the case in some sub-projects, as Petter pointed-out. Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/hv0olk$ve...@dough.gmane.org
Re: Is archive this list?
Andrzej Borucki wrote: Exists archive debian-devel@lists.debian.org ? I assume from your email that you are Polish, right? This page might be of interest to you: http://www.debian.org/international/Polish/index.pl.html Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: gnokii stall
Norbert Preining wrote: is there any plan or timeline when the gnokii stall in sid will be fixed? It looks like that gnome-phone-manager and the kdepim suite still depend on the old libgnokii library. Do the maintainers of these packages plan to upload fixed packages soon? This is my fault for uploading a new soname without trying to coordinate with the other maintainers or asking the release team. I forgot that since the last soname bump, libgnokii now doesn't have a versioned -dev package, so I needlessly opened bugs for the depending packages instead of simply requesting binNMUs. My bad. In the meantime gnome-phone-manager has been binNMUed, so kaddressbook seems to be the only missing piece. I'm sending an email to d-release requesting that, just in case. Cheers and sorry for the noise -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Packages that download/install unsecured files
Hi, Patrick Matthäi wrote: Maybe we should also think about the downloaded files itself. A firmware for Linux or a plugin for firefox could do realy bad things. In the case of geoip it is just a data file (like a .svg etc) with no attacking vector. The attacker could only inject a corrupted database and geoip will throw errors/false positions. Is this realy a vector for it? GeoIP's database is AFAICT a binary format, which means the library could theoretically suffer from buffer-overflows and such. If this is indeed correct, you'd just need apache's mod-geoip, for instance, to put your server in potential trouble. Being strict, almost any format can be an attack vector in some way (phishing sites are another extreme example, and obviously one we shouldn't try to solve through the packaging system), but I somewhat agree with Christoph that we could draw the line on packages that perform automatic installations of binaries from external unchecked sources. Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Explicitely Cc bug reporters
Sandro Tosi wrote: Do others feel we should enable emailing the submitter by default? there are some reasons not to? As raised by Berhard[0], this could bother some reporters, OTOH - as Kumar said[1] - other posters would actually like being more closely involved with their bugs. Why not include a pseudo-header to subscribe to bugreports on submit? This way reportbug could include a question asking if the user wants to follow the bug closely or just fire-and-forget. Should leave the choice to the submitter and still leave the option of explicitly using nnn-submit...@b.d.o Disclaimer: I have no idea how feasible this is. I never even looked at the BTS code. Cheers [0] http://lists.debian.org/msgid-search/20090910142150.ga15...@pcpool00.mathematik.uni-freiburg.de [1] http://lists.debian.org/msgid-search/20090910143253.ga11...@146653177.ece.utexas.edu -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#544539: RFP: Linux Unified Kernel
Ivan Borzenkov wrote: If you support Windows drivers, you will support kernel-mode Windows trojans as well. trojans also need root access to system - in windows it's standart, in linux not I'm not familiar with LUK, but by the description it seems you might be missing the point: it doesn't matter if the _user_ has root access per default or not, if the driver is running in kernel-mode - which seems to be the case for LUK - you're opening up to the same security problems. Unless you have something like ndiswrapper, which has its own set of problems and limitations. Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian @Linuxtag 2009 - Last call for help
Alexander Wirt wrote: I think that two people are not enough to run a booth. If this call for help does not succeed I'll have to cancel the booth. So if you are in Berlin during June 24th - 27th please be so kind and participate to the Debian booth. You don't have to be a Linux/Debian expert, just a little bit motivated :). Would a foreigner whose German's not exactly top notch help? I live in NRW, but could gladly spend a few days in Berlin if you think it would be of any assistance. I owe some friends a visit anyway... :) Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Proposal of new control field: Date
Enrico Zini wrote: If anyone can suggest me a decent heuristics to spot a 'rotting' package (like, for example standards-version older than X, but you need to tell me what X), I can automatically mine it and turn it into a debtags tag. I would propose something like freshness of bugs vs. freshness of last non-binary upload, possibly weighted. This would let old but non-problematic packages off the radar. Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513846: ITP: pidgin-awayonlock -- pidgin plugin to set as away on screensaver activation
Package: wnpp Severity: wishlist Owner: Leo costela Antunes cost...@debian.org * Package name: pidgin-awayonlock Version : 0.1 Upstream Author : Leo costela Antunes l...@costela.net * URL : http://costela.net/projects/awayonlock * License : GPL-3 Programming Lang: C Description : pidgin plugin to set as away on screensaver activation Away-on-Lock is a simple plugin for pidgin (or any other libpurple-based IM client) to change your status when the screensaver gets activated. It currently supports only gnome-screensaver. -- System Information: Debian Release: 5.0 APT prefers unstable APT policy: (500, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
RFH: who should get this bug?
Hey, I have no idea which package should get this minor bug[0] about some characters covering the underscore that marks an activation key. My best guess would be either libpango or libgtk2.0, but I'm at a loss here. Opinions? Cheers [0] http://bugs.debian.org/501864 -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFH: who should get this bug?
[no need for CC] Josselin Mouette wrote: That would be libgtk2.0-0, but I can’t reproduce that. The underscore is displayed further down over the g here (both GTK+ 2.12 and 2.14). What font are you using? I can reproduce the problem here using Sans size 9, but it doesn't happen using Nimbus Sans, for instance. Anyway, I'll reassign the bug. Thanks! Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502799: ITP: python-beepy -- implementation of the Blocks Extensible Exchange Protocol (BEEP)
Package: wnpp Severity: wishlist Owner: Leo costela Antunes [EMAIL PROTECTED] * Package name: python-beepy Version : 0.6.2 Upstream Author : Justin Warren [EMAIL PROTECTED] * URL : http://beepy.sourceforge.net/ * License : MIT Programming Lang: Python Description : implementation of the Blocks Extensible Exchange Protocol (BEEP) BEEPy is a python implementation of the Blocks Extensible Exchange Protocol. It makes use of the twisted framework to provide low-level socket communication over TCP. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Screenshots of GUI applications (again)
Hi, Christoph Haas wrote: - Propose a new optional debian/control field X-Screenshot: pointing to an URL serving an image file (PNG, JPG) I don't think this is needed and could significantly bloat Packages.gz - Create a new tree on hg.debian.org to host screenshots. - Alternatively provide a web service that hosts screenshots so that packages can point to it (e.g. http://screenshots.debian.net/PACKAGE). The service should also scale down the pictures to a reasonable size suitable for thumbnail display (max 150x150). (I can program that if needed. The only problem is probably authenticating the maintainer. Maybe a simple email interface checking PGP signatures will do. Needs further brainstorming.) - Change packages.debian.org to show the thumbnail from the package's control file. I will work on a patch if desired. - Add this feature to package managers (synaptic, kpackage, ...). I don't know enough about GUI programming yet that I could possibly help here. Instead of all that, why not creating this infrastructure under a debian.net (like screenshots.debian.net) domain and when it's ready asking for it to be linked from the PTS, for instance? Package managers could - after the solution is sufficiently stable - fetch from it when browsing packages. You could adopt a standard url syntax for referring to specific packages (like screenshots.d.n/bin-package-name) and create a way for maintainers to upload screenshots to it (via email, as you suggested, perhaps). This way we don't have to change anything in our infrastructure and still have a semi-official place to put this sort of information. Cheers -- Leo costela Antunes [insert a witty retort here] signature.asc Description: OpenPGP digital signature
Re: Include on first iso: m-a, build essential, kernel headers
Hi, [EMAIL PROTECTED] wrote: They are free, do not take up space, but without them (on a wireless only computer) you hit a vicious circle; Needing internet to be able to get internet. Avoiding the free vs. non-free firmware issue, most of these packages are available on Debian CDs/DVDs, just perhaps not on the first installation media. The choice of which software to put on the first CD is a correlation between software importance and target audience size, so it's not so easy to determine. If I understand your problem correctly, the packages you need (atl2-modules) aren't even available in Etch, so you're probably talking about Lenny CDs, right? If not, I guess this might be a problem. If what you mean is madwifi-source, then the problem is the non-free status, which means we simply can't distribute it on CDs. If the package you need isn't a victim of any of the above mentioned problems, you can find the CDs which contain it here[0]. I have backups (via aptoncd) for all of the aforementioned tools and dependencies for Etch, Lenny and Sid. However, I ythink that their inclusion is far more important than, say... renaming Firefox or including Mono in the gnome desktop. Mono is not included in the first CD, just as the tools you need. The renaming of Firefox is not a matter of taste (as could be argued about the order of packages on CDs), and had to be done because of the reasons explained here[1] (lots of mail-list archive reading...). So neither of those are arguments have any relevance to the matter at hand. Cheers [0] http://atterer.net/jigdo/jigdo-search.php [1] http://lists.debian.org/debian-legal/2004/12/msg00328.html -- Leo costela Antunes [insert a witty retort here] signature.asc Description: OpenPGP digital signature
Re: Policy question - deleting files belonging to another package
Mike Bird wrote: It seems to me that it ought to be against policy to use a maintainer script to delete files belonging to another non-conflicting non-replacing package, but I haven't found such a policy. Does anyone have the answer so I can give it to reportbug? If I understood your question correctly, I guess you're looking for policy 7.6.1 [0]. Cheers [0]http://www.debian.org/doc/debian-policy/ch-relationships.html#s7.6.1 -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-cups-devel] cupsddk - stolen WNPP - policy violation
[removing non-related maillists and recipients, this is a purely devel comment] Patrick wrote: Till did never deal with my correspondence so far, which is why I think he should not maintain it - apart from that I am a CDBS fan, and things look far cleaner than with his debian/rules. A bit of - hopefully constructive - nit-picking: Just because a rules file with CDBS *looks* clean that doesn't necessarily imply any direct improvement in package quality. I'm playing devil's advocate here because I also use CDBS in many of my packages, but I still think it's important to keep the distinction in mind. Cheers -- Leo costela Antunes [insert a witty retort here] signature.asc Description: OpenPGP digital signature
Re: debian-multimedia-keyring/debian-backports-keyring in official debian repository?
Peter Jordan wrote: but the repositories does not need to be official debian services, only the keyrings should be available over the official debian repository. That may make some sense, but you do understand that by making them available they wouldn't be any more official and any more trusted, right? If we provide them as packages, it may be misunderstood for our users as a recommendation, at best, which IMHO isn't worth the hassle. Better to keep the key-adding just as manual as the sources.list editing. This, of course, from the perspective that there is no official trust relationship. If there is one that I'm unaware of, then by all means, file an RFP! Cheers -- Leo costela Antunes [insert a witty retort here] signature.asc Description: OpenPGP digital signature
Re: Debian mirror CDN had launched.
[No need to CC me, I'm subscribed. Keeping the other CCs since I don't know about their subscription status.] Hi ARAKI Yasuhiro wrote: I announce I start cdn.debian.net. You could have announced work on this before, we could have joined forces! :-) But I wonder, how do you guys deal with partial mirrors (in terms of provided archs)? Do you support only full mirrors? You don't have any architecture information, so I assume you can only use mirrors which could provide all archs, right? This CDN checks your hosts DNS query to retrive your national location. - If your located country has Debian Mirror, return this mirror site IP address. - If your located continent has Debian Mirror, return this mirror site IP address. I don't think this is a good logic for many situations. For instance: Brazil is in South America, but it doesn't have good links to any other South American country. You'd most probably get better results from a North American mirror instead of any other South American mirror outside Brazil. I think this situation might occur too often in other countries. - If CDN can not find your location, return one of Japan mirror. - This CDN checks debian rsync mirror process. If mirror site is mirroring, CDN hides this site. This is a good idea. I had intended to plug this information into my solution as well, though I'm not sure about hiding current mirroring sites... Though I couldn't find where you get this info from, and how. Is it in the SVN you supplied? Furthermore, why don't you guys use the info from the Mirrors.masterlist[0] file to generate your country/continent information? This way you can work closely with the mirror-admins to keep your info up-to-date. Cheers -- Leo costela Antunes [insert a witty retort here] signature.asc Description: OpenPGP digital signature
Re: Debian mirror CDN had launched.
Kurt Roeckx wrote: And it looks to me like the mirror should also be available via /debian. Oh-oh... I hadn't thought about this problem too. Well, I guess it's something that could be asked of the local mirror-admin. If they want their mirror to be a part of the automatic rotation they could change the virtual host, for instance, to adapt to a standard directory structure. But it's a problem, nonetheless. Cheers -- Leo costela Antunes [insert a witty retort here] signature.asc Description: OpenPGP digital signature
Re: QUESTION: Debian Policy: Manual pages
Hi Firstly, this kind of question would be better suited in the debian-mentors list. Harshula wrote: Here's the example: 1) a.tar.gz - a.deb 2) b.tar.gz - b.deb 3) c.tar.gz - c.deb Are they really distributed in three separate upstream tarballs? If they are, perhaps it would be better to generate a single tarball, if not, there's no need to split it. A single tarball can - and most do - generate many separate debs. Take a look at the New Maintainer Guide[0] or get the sources of some existing packages to get the hang of it. This should solve the manpage issue. Cheers [0] http://www.debian.org/doc/maint-guide/ -- Leo costela Antunes [insert a witty retort here] signature.asc Description: OpenPGP digital signature
Re: [update] Automatic mirror selection - feedback appreciated
Leo costela Antunes wrote: I don't think it's a cache problem on PDNS, firstly because it doesn't seem to be caching anything (based on log output) and secondly because the answer is changing between requests inside a small time-frame. But I could be wrong. Thanks to the help of Michal Cihar this problem has been fixed. If anyone is still interested, please help by running a few more test 'apt-get update apt-get upgrade', for instance. Cheers -- Leo costela Antunes [insert a witty retort here] signature.asc Description: OpenPGP digital signature
Re: [update] Automatic mirror selection - feedback appreciated
Michal Čihař wrote: This server was the place where I tried the lookup and it is really in Czech. It has own DNS server which does not use any proxy and I flushed it's cache before each attempt. Just tested it again to be sure: [snip] Okay let's try it also another way - ask directly your server without anything on the way. It seems that last reply is somehow cached even for different source addresses. If I do query first here in Japan and then over there in Czech, I get few results pointing to Japan mirror before it updates to Czech one. The same happens when I then start resolving in Japan - I get again the Czech server on first attempts. Log follows, the time difference 8 hours is time zone shift: Are you sure there's no redirection of port 53 going on there? Or perhaps a load-balancing between two separate outbound IPs (one of which could be wrong in the GeoIP database)? I don't mean to say you don't know how your servers work, it's just that this seems a bit odd, given that nobody else reported similar problems and how simple the setup is. I don't think it's a cache problem on PDNS, firstly because it doesn't seem to be caching anything (based on log output) and secondly because the answer is changing between requests inside a small time-frame. But I could be wrong. Can you hop on to IRC to coordinate some queries while I watch the log? Cheers -- Leo costela Antunes [insert a witty retort here] signature.asc Description: OpenPGP digital signature
Re: unknown-field-in-control homepage
Jonas Meurer wrote: I: cryptsetup-udeb udeb: unknown-field-in-control homepage Quick guess: could this be a case-sensitivity issue? Should be Homepage:... Cheers -- Leo costela Antunes [insert a witty retort here] signature.asc Description: OpenPGP digital signature
[update] Automatic mirror selection - feedback appreciated
Hi,
Thanks to the help of Adam Borowski we now got a working solution for an
automatic mirror selection scheme.
Please help us test this infrastructure so that I can convince the DSA
to add it to our servers or at least give us a delegation from a
debian.{net,org} subzone! ;)
Again: I have no intention of supplanting any current structure, only
adding some more functionality to what we already have.
How to make it work:
Simply change whatever mirror you're currently using on
/etc/apt/sources.list to:
arch-geomirror.debian.net
Where arch is the output of dpkg --print-architecture.
Please make sure the DNS propagation has hit you, since the debian.net
aliases were all created earlier today.
How it works:
-
The arch-geomirror.d.n addresses are manually added CNAMEs to a
PowerDNS server that manages the zone geomirror.angband.pl (helpfully
loaned by Adam Borowski). This server is running pdns-backend-pipe,
which simply runs a script to determine the best mirror based on the
contents of Mirrors.masterlist[0], the IP that originated the request
and the requested architecture.
The current logic for selecting mirrors is very crude and only makes
sure the selected mirror is on the user's country and has the selected
arch, prioritizing mirrors that are called 'ftp.*.debian.org' and leafs
over push mirrors.
One possible improvement would be fetching information from DMC[1] to
help the prioritizing of hosts based on freshness (this could also help
avoid temporarily downed mirrors).
The source code for the backend script is available at[2].
The name 'geomirror' was picked for lack of a better suggestion. Please
feel free to give one! ;)
Known problems:
--
Since it's based on CNAMEs, a mirror that works on a separate virtual
host than the server's default won't be usable by this scheme.
In a quick test scan (ignoring all non-related errors), about 84 of the
358 archive mirrors are affected by this issue, 9 of which are top-level
country mirrors (BR, CL, HK, IS, IT, PT, TR, UK and 2 of the 4
round-robins for CA).
Simply adding:
ServerAlias *.geomirror.debian.org
(or whatever the official address ends up being) to apache-based mirrors
should suffice, so I hope getting a delegation from DSA would be enough
to ask the mirror admins to add this alias to their mirrors. Please
correct me if I'm wrong and there's some other big problem I'm not seeing.
Another minor problem is that the use of some DNS resolver that's not on
the same country as the user (OpenDNS, for instance) will result in a
incorrect guess by the server.
Cheers
[0]
http://cvs.debian.org/*checkout*/webwml/english/mirror/Mirrors.masterlist
[1] http://www.de.debian.org/dmc/today/
[2] git://git.debian.org/~costela/mirror_picker.git
--
Leo costela Antunes
[insert a witty retort here]
signature.asc
Description: OpenPGP digital signature
Re: Automatic mirror selection
Raphael Geissert wrote: Besides that I'm interested in how your script works at DNS level and if it wouldn't be more suitable to just setup a server with BIND + GeoDNS[1]. That's exactly the idea, but I chose to use pdns-backend-pipe + libgeo-perl, so that I could grep the Mirrors.masterlist file for info on our mirrors and use other methods of prioritizing aside from just geolocation, namely the type of mirror, architectures available and the domain name of the mirror (assuming that mirrors that got promoted to ftp.*.debian.org are somehow better than the rest). Check the announce I just made[0] and the git repo for the script[1] for more info. Feel free to send any feedback. Cheers [0] http://thread.gmane.org/gmane.linux.debian.devel.general/124340 [1] git://git.debian.org/~costela/mirror_picker.git -- Leo costela Antunes [insert a witty retort here] signature.asc Description: OpenPGP digital signature
Re: Automatic mirror selection
Guillem Jover wrote: You might want you use «dpkg --print-architecture» instead, so you avoid a dependency on dpkg-dev. Good point. Cheers -- Leo costela Antunes [insert a witty retort here] signature.asc Description: OpenPGP digital signature
Re: Automatic mirror selection
Hi, Raphael Geissert wrote: I'm not an expert on the subject, but wouldn't anycast be more suitable? It's been suggested on the referred thread[0]. I've never worked with it myself, but my limited understanding is that it would need work from all mirror admins and even if that was feasible, there are bound to be mirrors that are (technically, bureaucratically, etc) unable to perform the needed changes to integrate their infrastructure with anycast. Cheers [0] http://thread.gmane.org/gmane.linux.debian.user.mirrors/311/focus=312 -- Leo costela Antunes [insert a witty retort here] signature.asc Description: OpenPGP digital signature
Re: Automatic mirror selection
Adam Borowski wrote: you can also get a geoip-city-lite database which appears to be dfsg free once you purge nondistributable parts about ISPs (city and ISP data is intermingled in a single file). That could perhaps provide some better resolution than just country. I thougth about this too, but we don't currently have reliable city information for the mirrors, so it would demand more work and wouldn't bring big benefits, since it's already not certain that the user's country's mirror will actually be any faster than an inter-country link, I decided that going for a country based approach was the best middle-ground bet. We'd have even less certainty about the user's city's mirror performance. Uhm, and how exactly do you get the arch? At DNS time you don't have anything but the requester's or his ISP's IP. This would have to be placed inside sources.list at some point, then I figure the automatic or manual process responsible should stick dpkg-architecture -qDEB_BUILD_ARCH somewhere in there, so you just have to query arch.geomirror.d.net, for instance, to get the best mirror for your country which contains your arch. It could be during D-I, if the D-I people like the idea and no big problems arise from a testing period. Would a vserver, one IP and a NS delegation for a test subdomain be enough for your tests? No fallover or anything, though. Yes, certainly. Do you have one available? The only needed things are: - pdns-backend-pipe - libgeo-ip-perl What about this: ftptest.debian.net CNAME debian.XXX debian.XXX NS your_vserver.XXX (where XXX is any domain you can control without bothering the DSA for every change) I don't think that'll work. Since the Debian nameserver won't find a break in the SOA line (introduced with a NS entry), it'll try to find YYY.ftptest.d.net directly. A CNAME entry on an upper-level domain won't be enough to redirect the lower-level domains. But I'm no DNS specialist, so if you (or anyone) have a more specific way of making this work, I'm all ears! Thanks for the feedback! Cheers -- Leo costela Antunes [insert a witty retort here] signature.asc Description: OpenPGP digital signature
Re: Automatic mirror selection
Adam Borowski wrote: Ah, right. Yet at least in some cases, it could be tricky to have the arch, so I think you would need a generic mirror anyway. I don't see any scenario where getting the arch would be tricky, do you have any in mind? Even if there is such a case, we have many mirrors that don't support all arches, so - to avoid problems - we'd have to filter the list to have only complete mirrors, drastically diminishing its utility, therefore I think it would be best to ignore the very few - if any - corner cases in which it's a little harder to get the arch, in the name of maintained utility. (Details sent privately). Too bad, I just learned it can possibly go down somewhere in the near future... Thanks a lot anyway! If not, we can always do a brief test on a random subdomain, and then toss a working config to the DSA guys. Cheers -- Leo costela Antunes [insert a witty retort here] signature.asc Description: OpenPGP digital signature
Automatic mirror selection
Hey there,
As an incredibly late follow-up to this [0] small thread, I created a
small script to act as backend for pdns and return a mirror for the
user's country.
It's a simple DNS based geographic mirror selection idea.
It works by:
- using logic based on D-I to select a mirror from a copy of
Mirrors.masterlist[1], making it behave like a user that selects his own
country during installation.
- filtering by country and arch, with a fallback host if the country
isn't found or no mirrors provide the needed arch.
- applying a _very_ simple priority scheme to the mirrors that match,
giving top points to hosts that match ftp{1,2}.{2}.debian.org and also
preferring leaf over push mirrors.
This last point is something I am still reluctant about: the logic was
leafs will tend to be less loaded, but this is really not true;
perhaps some priority like secondary primary leaf, to offload
primaries, but keep leafs as a last resort would be better.
I'd like to put this to use for Debian, but I face two small problems:
- I currently don't have access to any server in which I could host this.
- our d.net domains apparently[2] can't contain NS records, which means
I couldn't have anything more integrated without DSA's approval, even
if I had a machine.
So, which friendly soul could I ask about getting this running on a
Debian server with a d.net domain, assuming there's some interest in it
aside from my own? The DSA through a ticket?
Please fire away if you have any comments on the idea, but keep in mind
it's not intended to supplant anything we currently have and it's
obviously not intended for every scenario.
Cheers
[0] http://thread.gmane.org/gmane.linux.debian.user.mirrors/311
[1]
http://cvs.debian.org/*checkout*/webwml/english/mirror/Mirrors.masterlist
[2] http://db.debian.org/doc-mail.html
--
Leo costela Antunes
[insert a witty retort here]
signature.asc
Description: OpenPGP digital signature
Re: Bug#457318: ITP: qmail -- a secure, reliable, efficient, simple message transfer agent
Turbo Fredriksson wrote: So what changed? Did Bernstein change his licence!? According to[0], yes. And can't the qmail-src maintainer just upload a binary package? I suppose so, yes. Opinions are like a butt - everyone got one (sorry, couldn't remember the English equivalence of this old Swedish saying - but I asume that the point isn't lost :). We got the same saying in Portuguese, but I never thought it made much sense! :-) The English version is Opinions are like assholes: everyone has them and they usually stink[1]. Never really heard any native English speaker use it, though. Cheers [0] http://cr.yp.to/qmail/dist.html [1] http://en.wikiquote.org/wiki/English_proverbs#O -- Leo costela Antunes [insert a witty retort here] signature.asc Description: OpenPGP digital signature
Re: Bug#457353: gdome2-xslt: should not be a Debian-native package
Luk Claes wrote: Stefano Zacchiroli wrote: Sorry, but I disagree with this interpretation. For me a Debian native package is a package which contains the official debian packaging stuff in the upstream tarball. Since I'm also upstream for gdome2-xslt and the software has been used historically always as a Debian package, to me that is a native Debian package. I couldn't find any better and more direct references, but according to [0] and [1] your interpretation is wrong. I thought this consensus was already a fact and that some maintainers just disagree and nobody forced them to change yet... Indeed, I think this should be more directly stated at least on dev-ref. Policy only contains an oblique reference[0] to this. The reasons why it shouldn't be a native package IMHO: * it's not specific to Debian * it wastes bandwidth as every upload contains all the sources * it's confusing for newcomers * it's error prone for NMUs and security updates Agreed. Additionally it complicates maintainer migration, but your second point is perhaps the most important. Cheers [0] http://www.debian.org/doc/debian-policy/ch-binary.html#s3.2.1 [1] http://www.debian.org/doc/maint-guide/ch-update.en.html#s-orig-tar -- Leo costela Antunes [insert a witty retort here] signature.asc Description: OpenPGP digital signature
Re: Bug#457353: gdome2-xslt: should not be a Debian-native package
brian m. carlson wrote: It is my impression that this is the case already, but Policy is silent on the issue; I checked before I filed the bug. Perhaps if a consensus can be reached a guideline should be placed in Policy so that people are not further confused. Please see [0], on this same thread. Cheers [0] http://lists.debian.org/debian-devel/2007/12/msg00632.html -- Leo costela Antunes [insert a witty retort here] signature.asc Description: OpenPGP digital signature
Re: Bug#457318: ITP: qmail -- a secure, reliable, efficient, simple message transfer agent
John H. Robinson, IV wrote: Joerg Jaspert wrote: There are *way* better MTAs [than qmail] out there that dont need tons of patches applied just to fulfill basic requirements for a MTA. No, there are not. There are certainly many others that don't need patches to fulfill basic requirements for an MTA, but whether they are better or not is irrelevant for us, given Qmail's level of widespread adoption. There's no discussion that there are still many people interested in having it available. After all, it's not like it's a 100 line C program with 10 totally compatible alternatives... unfortunately! :-) Cheers. -- Leo costela Antunes [insert a witty retort here] signature.asc Description: OpenPGP digital signature
Re: Bug#457318: ITP: qmail -- a secure, reliable, efficient, simple message transfer agent
Steinar H. Gunderson wrote: How widespread is this anyway? I hardly see any new qmail installations anymore, and the ones I see are largely because it's a pain to migrate away from. Of course, the plural of “anecdote” is not “data”... Well, I have too agree with you that almost all my personal examples are based on the hard to migrate from argument. The usage surveys I could find[0][1][2] have somewhat conflicting usage patterns, but all indicate Qmail is not the most used MTA out there. Please note that I don't personally like Qmail either, but I still think we should (but don't *have* to) provide it, if possible (I don't know what's the outcome of the putting it in public domain story). Cheers [0]http://www.securityspace.com/s_survey/data/man.200707/mxsurvey.html [1]http://www.oreillynet.com/pub/a/sysadmin/2007/01/05/fingerprinting-mail-servers.html [2]http://cr.yp.to/surveys/smtpsoftware6.txt (not up-to-date, but perhaps interesting nonetheless) -- Leo costela Antunes [insert a witty retort here] signature.asc Description: OpenPGP digital signature
Re: Please don't list available translations in the package description
cobaco (aka Bart Cornelis) wrote: Almost no packages currently do this, hence relying on the package description to check wether a package is localized for your language is completely unreliable. Agreed. For a list of localised packages check http://www.debian.org/intl/l10n/po/ for your language, true it only cover's gettext localisations but that's 99% of all localisation in free software anyway (this misses some localised webapps but that's about it AFAIK) For a specific package you can also use apt-file or packages.debian.org to check for the presence of a lang-code.po file for your language. These are hardly practical solutions from a user perspective, even though they are very helpful for developers. What I meant is that I believe in the need for a way to tell users which languages the package they intend to install supports (which doesn't include greping for the package in a separate huge list of for files in the source ;-) ) Cheers -- Leo costela Antunes [insert a witty retort here] signature.asc Description: OpenPGP digital signature
Re: Please don't list available translations in the package description
Stephen Gran wrote: At the moment, I'm inclined to agree with Enrico. I don't think it's all that helpful to have some small subset of all the programs actually translated into a given language returned in a search for that language string. It's both an incomplete list (since many other programs will be localized, but just not mention it in the package description) and also useless clutter when you're looking for things related to actually working in the language. Don't get me wrong, I agree with your assessment, I just think we could come up with a better place to put this information _before_ filling bugs. They may not be in the right place, but it's useful information that IMHO should be accessible somewhere so that our users don't have to go hunting for it on the web or are forced to install packages to check it out. Cheers -- Leo costela Antunes [insert a witty retort here] signature.asc Description: OpenPGP digital signature
Re: Please don't list available translations in the package description
Enrico Zini wrote: I'm thinking of filing bugs, but I'd like to get some feedback here first. While I agree it's an issue (albeit a small one), I think we shouldn't file bugs for it while there's no better place to put this information. It may reduce the objectiveness of some searches, but it is still valuable information. Couldn't debtags support this sort of information in a good enough way (not via culture::*, but something like translated-in::*)? Or perhaps - if stricter solution is desired - implementing a new control field that could be filled on build-time by a dh script (which should support po files natively, but could also support regex based searching of translation files, for alternative translation schemes)? IMHO the debtags solution looks simpler and better, but it doesn't hurt to keep our options open! :-) Cheers -- Leo costela Antunes [insert a witty retort here] signature.asc Description: OpenPGP digital signature
Re: Packages with httpd needs
Steve Langasek wrote: On Tue, Nov 27, 2007 at 07:57:44PM +0100, Leo costela Antunes wrote: THTTPD doesn't (AFAIK) support PHP Does THTTPD not support CGI or FastCGI? Oops, you're right. But would the apps run out of the box with php-cgi? If so, then yes, these bugs could be filed in the appropriate packages. (even if not, probably related wishlist bugs could also be filed, asking for CGI compat) Cheers -- Leo costela Antunes [insert a witty retort here] signature.asc Description: OpenPGP digital signature
Re: Packages with httpd needs
Hans-J. Ullrich wrote: Well, I wondered, whenever an application needs a http-demon (for example phpgroupware, egroupware, prelude and many others), all packages force to install apache. There is no way, to get rid of this. As we say Small is beautifull or KISS = Keep it simple stupid , IMO there is no need, to install mighty apache ! A simple http demon (I prefer thttpd) would do the same but would be more secure. THTTPD doesn't (AFAIK) support PHP, so the applications you mentioned can't be use with it. Thanks for the interest in helping out, but please file bugs to specific packages when you are certain they could use a suggestion such as yours. I don't dismiss your suggestion completely, but bear in mind that given the number of people and packages in debian, a non-specific email to debian-devel is hardly likely to generate any sort of positive outcome. Cheers -- Leo costela Antunes [insert a witty retort here] signature.asc Description: OpenPGP digital signature
Re: RFC: cups as default printing system for lenny?
[not subscribed to -policy, just keeping original cross-posting] Marc 'HE' Brockschmidt wrote: I think we may want to start thinking about getting rid of the whole thing and switching to something which allows us to express more complex importance measurements for packages. In fact, d-i and its task system have been a step in that direction, so we maybe should evaluate if we want to formalize it a bit more and get it into policy to replace priorities. Seconded. A use-case based priority system is clearly - IMHO - a better suited system then the Priority: paradigm for a distribution as broad reaching as Debian. Whether by extending the tasks system, the Priority paradigm (by perhaps including a [use-case] tag, for instance: Priority: standard [!embeded]) or another wholly different approach, this seems like a worthwhile idea. One of the possible advantages for a different paradigm would be for reduced CDDs, such as Emdebian, whose standard set of packages might divert considerably by having _less_ packages, in which case the current task system would fall short, AFAICT. Cheers -- Leo costela Antunes [insert a witty retort here] signature.asc Description: OpenPGP digital signature
Re: Compiz-fusion question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [Sean, sorry for the uncalled CC, just wanted to make sure you got this] Julien Cristau wrote: On Sun, Oct 21, 2007 at 15:36:38 +0300, [EMAIL PROTECTED] wrote: Hi! I have found that compiz-fusion in official debian repository is not complete (or is not compiz-fusion at all). It misses such things as ccsm (seems like compizconfig-settings-manager?). I believe there is some reason for this (why it is not included). What is the reason? :) Mostly, lack of manpower. Sean Finney has started working on those packages, but AIUI there's some work left. Is this the only problem barring compiz-fusion ? Could I help with anything ? Cheers - -- Leo costela Antunes [insert a witty retort here] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHG1YxImLTb3rflGYRAp77AJ9pRMmmQgYYe94MHjgNEJsw6nEjxwCgop1m aEWyNnNyrVlpwiWoUIX2uKU= =EVD9 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Handling of poorly maintained and useless packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Josselin Mouette wrote: Some additional info might also be useful: - age of last upload - WNPP status (O, RFH, RFA) (for how long?) - Maintainer's MIA status - number of packages maintained by the maintainer - number of maintainers for the package - is the package team maintained? - are there better maintained packages with similar functionality? - - upstream status: dead, unresponsive, very active (since useless packages can become useful very fast in the case of new software), normal, etc ACK to all the rest. Cheers - -- Leo costela Antunes [insert a witty retort here] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHD2BbImLTb3rflGYRAhfNAKC/bJM9rbdU+DHc4g1UUp5J8TqeDgCeK2fW PYUh93wWg7B6hRcd2M6GsNc= =j9bE -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
ITP: gnome-velocity -- A light file manager for GNOME2
Package: wnpp Version: unavailable; reported 2003-04-30 Severity: wishlist * Package name: gnome-velocity Version : 0.1alpha Upstream Author : Kyle Davis [EMAIL PROTECTED] * URL : http://velocity.sf.net * License : GPL Description : A light file manager for GNOME2 Velocity is a file manager for the GNOME 2 Desktop environment. It is designed to be fast, efficient, and very powerful. As a file manager it offers many advanced and unique features such as: View profiles, Context menu image previewing, Plugins, and much more.
RE: ITP: gnome-velocity -- A light file manager for GNOME2
severity #191420 wishlist thanks I don't know why it was filled as Normal... it didn't recognize wishlist as a valid value for the Severity pseudo-header... Any hints? Cheers PS.: CC me, I'm not on d-devel -- Leo Costela [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] Key Fingerprint: 8AE6CDFF6535192FB5B659212262D36F7ADF9466 you must cut down the mightiest tree in the forest... with... a herring! signature.asc Description: This is a digitally signed message part
