Re: RFC: Using git/collab-maint/PET for debian-mentors.
Hi, Ben Finney ben+deb...@benfinney.id.au writes: Paul Wise p...@debian.org writes: As said on IRC, cue anti-git flamage. In debian we use a multitude of version control systems and we shouldn't impose choice of a specific VCS nor force people to use a VCS. I personally maintain packages in git, in SVN and in no VCS and prefer either no VCS or SVN for teams. +1. There's no need to impose any particular VCS onto maintainers, even by default. It falls into the domain of allowing the maintainer to make their own decisions concerning their own work. I started working on a version of PET that supports several VCS backends, even for a single instance: all packages show up on a single package no matter in which of the known VCS they live in. For now it supports Git and SVN as I use those myself. It still needs some work, but is slowly getting usable. ,A (B ,A (B ,A (B* Optionally co-ordinating on IRC in #debian-mentors, as well as ,A (B ,A (B ,A (B ,A (Bvia notes at the top of debian/changelog. I imagine this happens already? I'm not sure what $B!H(Bcoordinating via notes at the top of debian/changelog$B!I(B means. Bear in mind that the changelog is primarily for communicating package changes *to users* of those packages. The Perl Group makes use of this: in the unreleased version of packages, we add notes to d/changelog telling what must still be done for the next upload, weather the package needs to wait for other binaries to be uploaded first, or when a upstream release does not need to be uploaded as there are no changes relevant for Debian. PET also supports this: IGNORE-VERSION: will tell PET that this version does not need to be uploaded, WAITS-FOR: [package] [version] tells PET to only show the packages in a waits for other packages until the listed packages have been uploaded to the archive. All of these notes are removed before the upload so they do not show up in the released packages. I think this is a very good method to communicate with other team members about the current state of packages. Regards, Ansgar -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wru25f9w@marvin.43-1.org
Re: RFC: Using git/collab-maint/PET for debian-mentors.
Ansgar Burchardt ans...@43-1.org writes: Ben Finney ben+deb...@benfinney.id.au writes: I'm not sure what “coordinating via notes at the top of debian/changelog” means. Bear in mind that the changelog is primarily for communicating package changes *to users* of those packages. The Perl Group makes use of this: in the unreleased version of packages, we add notes to d/changelog telling what must still be done […] All of these notes are removed before the upload so they do not show up in the released packages. I think this is a very good method to communicate with other team members about the current state of packages. I don't see the benefit of overloading the ‘debian/changelog’ file for this. Wouldn't it be better to keep the purpose of that file as is, and use a separate file (perhaps ‘debian/TODO’) for this separate purpose of intra-team-only communication? -- \ “If you do not trust the source do not use this program.” | `\—Microsoft Vista security dialogue | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wru22juv@benfinney.id.au
Re: RFC: Using git/collab-maint/PET for debian-mentors.
On 14 June 2010 02:20, Ben Finney ben+deb...@benfinney.id.au wrote: Paul Wise p...@debian.org writes: As said on IRC, cue anti-git flamage. In debian we use a multitude of version control systems and we shouldn't impose choice of a specific VCS nor force people to use a VCS. I personally maintain packages in git, in SVN and in no VCS and prefer either no VCS or SVN for teams. +1. There's no need to impose any particular VCS onto maintainers, even by default. It falls into the domain of allowing the maintainer to make their own decisions concerning their own work. I was only suggesting what I would change in my particular workflow. I don't see that I'm actually forcing anyone to use git - just saying that I myself would nudge my mentees towards it. There are always other sponsors. Now, I'm open to the idea of SVN collab-maint as well. I spent yesterday testing out Ansgar's version of PET, which supports both git and SVN. There are some teams who make use of both (e.g. the debian-games team, off the top of my head). We all have our individual preferences. I'm not particularly attached to the choice of VCS; but what I do think is important is that people /do/ choose a VCS. If we do not train prospective maintainers in the way that packages are actually managed in most teams, then we are doing them a disservice; there will be a steeper learning curve when they come to join a team. It will also bring the same benefits to sponsored packages that it does elsewhere, namely collaboration and a public record of the history, and allow us to use the same tools to facilitate communication that we have in other teams. I believe Ansgar's got your other point about debian/changelog covered; see how the Perl team works - the notes are never released, and just serve as a place for keeping review notes in the same repository as the code. -- Tim Retout t...@retout.co.uk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktilpf7bvuncckyyodl9fzhdyczwzheaip0xam...@mail.gmail.com
Indicator applets and related packages
[ Bcc debian-mentors as some prospective DD might be interested in packaging those ] Hello, I would like to be able to use ubuntu's indicator applets in Debian but very few of the required packages are in Debian (only libindicator is available). Here are some of the design pages if you don't know what this is all about: https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationIndicators https://wiki.ubuntu.com/MessagingMenu https://wiki.ubuntu.com/MeMenu The missing source packages are AFAIK: - libdbusmenu https://launchpad.net/ubuntu/+source/libdbusmenu (no RFP/ITP known) - libindicate https://launchpad.net/ubuntu/+source/libindicate RFP: http://bugs.debian.org/560122 - indicator-applet https://launchpad.net/ubuntu/+source/indicator-applet RFP: http://bugs.debian.org/534556 - indicator-messages https://launchpad.net/ubuntu/+source/indicator-messages (no RFP/ITP known) - indicator-application https://launchpad.net/ubuntu/+source/indicator-application (no RFP/ITP known) - indicator-session https://launchpad.net/ubuntu/+source/indicator-session (no RFP/ITP known) - indicator-me https://launchpad.net/ubuntu/+source/indicator-me (no RFP/ITP known) - indicator-sound https://launchpad.net/ubuntu/+source/indicator-sound (no RFP/ITP known) - in the near future: indicator-network https://launchpad.net/indicator-network And also several plugins/extensions to various piece of software: - evolution-indicator https://launchpad.net/ubuntu/+source/evolution-indicator And some of those in Qt/KDE variants: - libindicate-qt https://launchpad.net/ubuntu/+source/libindicate-qt - https://launchpad.net/plasma-widget-message-indicator I contacted Ted Gould of Ubuntu/Canonical to ask him whether he would like to maintain some of those packages within Debian. If yes, I'll sponsor him (if you want to be the sponsor instead of me, please say so). I hope we can find maintainers for all those. Should they be maintained within the Debian Gnome team ? Cheers, -- Raphaël Hertzog Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/ My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100614073602.ga25...@rivendell
Re: RFC: Using git/collab-maint/PET for debian-mentors.
Tim Retout t...@retout.co.uk writes: I'm not particularly attached to the choice of VCS; but what I do think is important is that people /do/ choose a VCS. Rather, I think it's important (for the good reasons you explained) that a package maintainer *use* a VCS for their packaging work. They don't have to choose one VCS for all their work, though, which is what your suggestions so far have implied. If you didn't intend that implication, so much the better; but apparently I'm not the only one reading your words that way. -- \ “Any intelligent fool can make things bigger and more complex… | `\It takes a touch of genius – and a lot of courage – to move in | _o__)the opposite direction.” —Albert Einstein | Ben Finney -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ocfe2fxp@benfinney.id.au
Re: RFS: debsigs (packaging updates, DMUA candidate)
On Wed, Jun 02, 2010 at 02:20:41PM +0300, Peter Pentchev wrote: Dear mentors, I am looking for a sponsor for the new version 0.1.16 of my package debsigs. This is a packaging update to bring it to the latest-and-greatest standards available :) See below for the full changelog entry. Just for the record, this package has been uploaded by Laszlo Boeszoermenyi (gcs). Thanks! G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 signature.asc Description: Digital signature
Re: RFC: Using git/collab-maint/PET for debian-mentors.
Ansgar Burchardt ans...@43-1.org writes: All of these notes are removed before the upload so they do not show up in the released packages. I think this is a very good method to communicate with other team members about the current state of packages. Leaving notes is a good communication method? Seriously? How about *talking* to each other? * Ben Finney ben+deb...@benfinney.id.au, 2010-06-14, 16:45: I don't see the benefit of overloading the ‘debian/changelog’ file for this. Wouldn't it be better to keep the purpose of that file as is, and use a separate file (perhaps ‘debian/TODO’) for this separate purpose of intra-team-only communication? That would be equally bad. -- Jakub Wilk signature.asc Description: Digital signature
RFS: vttest (updated package)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear mentors, I am looking for a sponsor for the new version 2.7+20100528-1 of my package vttest. (Programming language: C) The package is lintian clean. It builds the binary package: vttest vttest (2.7+20100528-1) unstable; urgency=low . * New upstream release * Update debian/copyright * Switch debian/rules to new dh format - update Build-Depends debhelper (= 7.0.50) - update debian/compat to level 7 * Bump Standards-Versions to 3.8.4 Description: tool for testing VT100 compatibility of terminals This package provides a program designed to test the functionality of a VT100 terminal (or emulator). It also supports analysis of VT220, VT420, and xterm. . The program is menu-driven and contains full on-line operating instructions. It tests both display (escape sequence) and keyboard handling. The package can be found on mentors.debian.net: - - dget http://mentors.debian.net/debian/pool/main/v/vttest/vttest_2.7+20100528-1.dsc I would be glad if someone uploaded this package for me. :-) Kind regards Wen-Yen Chuang - -- My GPG key is signed by Debian Developer Masayuki Hatta. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwWHAMACgkQdEpXpumNYVn05QCfRM1BgZNYY/5wMeSA7H1SsA3q IfYAnR6yvrRF9NZUvmwIOOVzTshTl9g5 =jwZy -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c161c03.5080...@calno.com
Re: RFC: Using git/collab-maint/PET for debian-mentors.
On Mon, Jun 14, 2010 at 12:25:07PM +0200, Jakub Wilk wrote: Ansgar Burchardt ans...@43-1.org writes: I think this is a very good method to communicate with other team members about the current state of packages. Leaving notes is a good communication method? Seriously? How about *talking* to each other? This only works if there's someone appropriate to talk to and the timeframe is good - for things where you're basically just parking a bit of work for pick up by some unknown person at some ill defined point in the future then writing some notes can be a very effective way of letting whoever next looks at the package know the current state of play. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100614123715.ga10...@sirena.org.uk
Re: question about debian/watch
Unrelated to the problem you're reporting, but a minor point: Your regex could be tighter (it's best to be as specific as feasible in a regex). I suggest: http://sf.net/radiotray/radiotray-(.+)\.tar\.gz Ok, thanks people. -- Elías -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktin59lg_piozml5-cglgtwtluujkqhivslike...@mail.gmail.com
RFS: squidguard (updated package, many fixes, DMUA candidate) (3nd try)
Dear mentors, I am looking for a sponsor for the new version 1.4-1 of my package squidguard. it supplants the very old version 1.2. And I would be most grateful if a kind sponsor would set the DM-Upload-Allowed (DMUA) flag before uploading :) It builds these binary packages: squidguard - filter and redirector plugin for Squid squidguard-doc - filter and redirector plugin for Squid - Documentation The package appears to be lintian clean. The upload would fix these bugs: 372709, 385093, 403875, 491673, 514636, 535158, 541602, 548489, 576169 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/s/squidguard - Source repository: deb-src http://mentors.debian.net/debian unstable main - dget http://mentors.debian.net/debian/pool/main/s/squidguard/squidguard_1.4-1.dsc I have created a git repository: - Vcs-Git: git://git.debian.org/git/collab-maint/squidguard.git - Vcs-Browser: http://git.debian.org/?p=collab-maint/squidguard.git Some more infos about squidguard: - Homepage: http://www.squidguard.org I would be glad if someone uploaded this package for me. FYI, here is the last changelog entry: squidguard (1.4-1) unstable; urgency=medium * New upstream release. (Closes: #372709, #491673, #535158) * New Debian maintainer. (Closes: #576169) * Bump DH compatibility level to V7. * debian/control: - Set debhelper version to = 7.0.15. - Bump Standards-Version to 3.8.4. - Add build dependency libdb4.7-dev. (Closes: #548489) - Remove suggestion to chastity-list. (Closes: #514636) - Add Vcs Git and Browser URLs. - Add Upstream homepage URL. * Move to source format 3.0 (quilt). * Update path in debian/watch. * Update and formatting debian/copyright. * Update 'update-squidguard' for use with Squid3. (Closes: #541602) * debian/README.Debian: - Update hints about Squid / Squid3 configuration. (Closes: #403875) - Remove old hint to chastity-list. - Update and refine some information and use headlines. * debian/patches: - Patch for use of $DESTDIR in Makefile. - Security: Patch for buffer overflow in sgLog.c (Fixes: CVS-2009-3700). - Security: Patch for buffer overflow in sgDiv.c (Fixes: CVS-2009-3826). - Patch for update links in documentation. * Add debian/postrm for removing etc/default/squidguard. (Closes: #385093) * Add 'set -e' in debian/postinst. * Remove unusable and old manpages in debian directory. * Add new (rewritten) manual pages. * Some changes in package configuration files. * Split package: add config for squidguard-doc package. * Use simple DH-syntax for debian/rules. * Set debhelper version to = 7.0.50. -- Joachim Wiedorn ad_deb...@joonet.de Wed, 02 Jun 2010 22:18:45 +0200 Kind regards Joachim Wiedorn signature.asc Description: PGP signature
Re: A lot of pending packages
Le samedi 12 juin 2010, Johan Van de Wauw a écrit : 2010/6/11 Tanguy Ortolo tanguy+deb...@ortolo.eu: * dokuwiki, a PHP-based wiki, that I co-maintain with a DD that has almost no time to sponsor me and suggested me to find another sponsor: such a package (PHP, web application) seems to interest nobody. Which should not really come as a surprise. First of all, not many people actually use packaged php applications. According to popcon, drupal6 has only 444 installations, with only 13 'recent' users[1]. The number will be an underestimation as many servers won't have popcon installed, but still... Well, at least I know that my package is enough used to trigger some bugs that are interresting both for me and for upstream. And some nasty packaging bugs that are caused by strange spurious modifications made by the user. Not many webapplications have an upstream which supports legacy versions, which means that it is up to the sponsor/maintainer to do so. While the same is true for many packages in debian, the security consequenses are usually more severe for a web app than for most desktop applications. Yes indeed. I know that I will have to backport some patches. And I also know that, as I am neither DD nor DM, they will take a longer time to be uploaded to Debian, but this is independant of my will. -- Tanguy Ortolo signature.asc Description: Digital signature
Asking for DMUA: Yes while seeking first sponsor
Hi! I noticed that recently some people seem to seek first time sponsors while asking for setting the DM-Upload-Allowed: yes flag at the very same time. While I can certainly understand Maintainers want to upload their packages ASAP themselves, I would like to point out that I consider that quite against the spirit of the Debian Maintainer Concept. The idea is, that you convince an (experienced) Developer, that you can do your work on your own on a per package basis. As Debian Maintainers don't need to pass the regular procedures to check their technical capabilities (so to speak), the idea is to select the packages you are allowed to upload on a case by case basis. Or to give you an example: Just because you can package simple game doesn't necessarily mean you can package and maintain a shared library. So I think asking for DMUA:Yes while seeking an initial sponsor is just plain wrong, as convincing a DD shouldn't be a one timer. I therefore ask DMs not to ask to set this flag on the first upload, and DDs not to do so. Best regards, Alexander -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c165527.20...@debian.org
Re: A lot of pending packages
Le dimanche 13 juin 2010, Thomas Goirand a écrit : I don't agree with you on the reasons. The thing is, PHP applications in Debian aren't made to support multiple instance. The result being that it doesn't make sense to use them, because you wont be able to have more than a single site with it. Some of them are. gallery2, for instance, has a multisite support. If there was a move toward multiple instances using a single package, I am quite sure that the situation would be different. Their is a move, at least with DokuWiki. Their is a semi-official way to build a multisite installation (they call that “farming”), that used some non-free (CC-BY-NC-SA) scripts. I wrote to ask for a license change some months ago, and I have just received a reply: these scripts are now free (GPLv2), so I am now able to work on multisite support. But I think that packaged webapps can be very useful, because: - they allow anyone to simply “aptitude install dokuwiki” to get a working installation without worrying about file system paths, rights and so one; - they often result in a cleaner, more secure setup (remember that many webapps install guides are written for users of mutualized hosting, and thus suggest to chmod -R 777 webapp_directory); - they can interact with the web server(s) configuration, allowing to get a working installation without having to define an Alias or a VirtualHost (based on the suggestion of an installation guide that was written for an Apache HTTPD with monolithic configuration, and that was never written for [insert here your favorite web server]); - they can integrate configuration options with debconf, providing a single interface. In fact, I know that at least some users do use at least one packaged webapp: mine. Because I get bug reports, some of them being my fault, and I sincerly regret being only able to write the fix and not to upload it to Debian or have it quickly uploaded, thus leaving my users with a bug that I have corrected, but that they cannot apply automatically. -- Tanguy Ortolo signature.asc Description: Digital signature
RFS: nautilus-clamscan RC bug
The attached debdiff fixes the RC bug (BTS #539813) against nautilus-clamscan as well as all other bugs against the package. nautilus-clamscan (0.2.2-2.1) unstable; urgency=low * Non-maintainer upload. * debian/watch: Fix broken watch file. (Closes: #550765) * debian/control: - Add missing misc:Depends. - Don't depend on clamav directly. (Closes: #529186) * debian/nautilus-clamscan.install: - Install to correct nautilus extensions directory. (Closes: #539813). * debian/source/format: Declare package as 1.0 format. I'd appreciate if someone would sponsor this upload. Perhaps to Delayed? The bug itself is almost a year old, but it was only promoted to grave a few days ago. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/n/nautilus-clamscan - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/n/nautilus-clamscan/nautilus-clamscan_0.2.2-2.1.dsc Thanks! - Andrew Starr-Bochicchio diff Description: Binary data
RFS: dokuwiki (updated package)
Dear mentors, I am looking for a sponsor for the new version 0.0.20091225c-4 of my package dokuwiki. It builds these binary packages: dokuwiki - standards compliant simple to use wiki The package appears to be lintian clean. The upload would fix these Debian bugs: 404353, 572377, 572502 (plus these Ubuntu bugs: 219414, 205908, 489987, 325013). Some of these bugs are related to the initial configuration of the wiki, that was incomplete and did not cover all the needs of the users. Hence many of the changes listed in the changelog. I also made several changes and enhancements to the package, cf. the Debian changelog (or the Git changelog). The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/d/dokuwiki - Source repository: deb-src http://mentors.debian.net/debian unstable main - dget http://mentors.debian.net/debian/pool/main/d/dokuwiki/dokuwiki_0.0.20091225c-4.dsc - source control: git://git.debian.org/collab-maint/dokuwiki.git/ The Debian Developper that was in charge of this package, adn, has little time to review my work and upload it. In addition, he does not have a connection to Internet currently. You may notice that this new version of the package swaps Maintainer and Uploaders fields, promoting me as the Maintainer: this change was suggested by adn himself. I would be glad if someone uploaded this package for me. -- Tanguy Ortolo signature.asc Description: Digital signature
Re: RFS: dokuwiki (updated package)
Hi Tanguy,
I noticed two things :
- a warning : unused substitution variable ${perl:Depends}
- an unused string in debconf template : dokuwiki/wiki/failpass
Theses warnings are reported by lintian but it's certainly not valuable because
lintian currently only understand shell script.
Why do you use a perl script for config ? Is it for historical reasons ?
Nicolas
Le 14 juin 2010 20:01, Tanguy Ortolo lt;tanguy+deb...@ortolo.eugt; a écrit :
Dear mentors,
I am looking for a sponsor for the new version 0.0.20091225c-4
of my package dokuwiki.
It builds these binary packages:
dokuwiki nbsp; - standards compliant simple to use wiki
The package appears to be lintian clean.
The upload would fix these Debian bugs: 404353, 572377, 572502
(plus these Ubuntu bugs: 219414, 205908, 489987, 325013).
Some of these bugs are related to the initial configuration of the wiki,
that was incomplete and did not cover all the needs of the users. Hence
many of the changes listed in the changelog. I also made several changes
and enhancements to the package, cf. the Debian changelog (or the Git
changelog).
The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/d/dokuwiki
- Source repository: deb-src http://mentors.debian.net/debian unstable main
- dget
http://mentors.debian.net/debian/pool/main/d/dokuwiki/dokuwiki_0.0.20091225c-4.dsc
- source control: git://git.debian.org/collab-maint/dokuwiki.git/
The Debian Developper that was in charge of this package, adn, has
little time to review my work and upload it. In addition, he does not
have a connection to Internet currently. You may notice that this new
version of the package swaps Maintainer and Uploaders fields, promoting
me as the Maintainer: this change was suggested by adn himself.
I would be glad if someone uploaded this package for me.
--
Tanguy Ortolo
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
iQIcBAEBCgAGBQJMFm6BAAoJENbvpqxLENhHoQUQAKcWkPfqDfkd4ZrrS1uAcRLq
CHTFXrMDYv1GtGrqu2LZXgfVoCYH6Nneybn+0eayU03XA+SwqEw1S5Skk9FuamdT
0JhHzRIKMZVNodRymooLZzCXk+jkItCMZNQu4qvBSt+wjBY6ANHWUm75GsIqrHGK
2ARm+EF4xpXcMNFXaF7p0c7OxnqTznJVzir5WVCDkn2O/TyfSFCqOY4vqUNSmVQI
H/81usW2KjwWNWksayQd+k+BG5U9HF0SmwukJ+yz7PGfDJzZl17+KbOk4iXLFmG4
TYAm2ycDQbyr3cAF6N9zlC/W0byFzPKk7gx1MlEtI5MQ3vQ5MOqobFmAdOP94Vnw
TOQE15JYHrZCpxJ9J4RsDiJCRmHngm8jnSK13JPVWMXxXv7fe6AS7VUO5AoE6dnW
o4+I0xlkJAgz0Brj3BGI2oQcoiD6ZBM9rWbXWqgnr8x1Hz9w2WtxNf8bOjBW4gUR
FGoKnZ1/xoGwqmc0aOJbUi6Sj19W6vv0LorILQkBwgXB5yQspVJpkNYOBtgZc33+
RLdzn+5LhFESPPQqNhIBQtjQWUqvpEZGeJPS03/Ae/h1AiPt4YDNqlT7AQXm4PgR
gmSCAZiOxaHRxVH3zyN1sxjlPEtt5IW52zHk94pt1RhdJskOofosp7bm9uJhyVfg
3cJypnW6ciqomuErt4/e
=F5Cb
-END PGP SIGNATURE-
signature.asc
Description: OpenPGP digital signature
Re: RFS: dokuwiki (updated package)
Le lundi 14 juin 2010, nikro...@gmail.com a écrit :
I noticed two things :
- a warning : unused substitution variable ${perl:Depends}
- an unused string in debconf template : dokuwiki/wiki/failpass
Theses warnings are reported by lintian but it's certainly not valuable
because lintian currently only understand shell script.
Yes indeed. Perl is used in the config script, as you saw it, and
failpass is used on it to warn the user if he failed to confirm his new
wiki administrator password.
Why do you use a perl script for config ? Is it for historical reasons ?
Yes, indeed. This script was written in Perl by a previous maintainer,
and I did not feel the need to rewrite it, as I think it is easier to
maintain such a script in Perl, because it contains a real logic,
contrary to the other maintainer scripts, roughly.
--
Tanguy Ortolo
signature.asc
Description: Digital signature
Re: RFC: Using git/collab-maint/PET for debian-mentors.
Ben Finney ben+deb...@benfinney.id.au writes: Ansgar Burchardt ans...@43-1.org writes: All of these notes are removed before the upload so they do not show up in the released packages. I think this is a very good method to communicate with other team members about the current state of packages. This works brilliantly, btw, and I've used it in other packaging teams. Unlike e-mail, the notes don't get lost even if the issue isn't addressed for several months. I don't see the benefit of overloading the ‘debian/changelog’ file for this. Wouldn't it be better to keep the purpose of that file as is, and use a separate file (perhaps ‘debian/TODO’) for this separate purpose of intra-team-only communication? debian/TODO doesn't have to be modified for an upload, so it's easy to miss notes there. debian/changelog is used for things that have to be fixed before the next upload, and since debian/changelog has to be modified to *do* the upload (to change UNRELEASED to unstable or experimental), this method ensures that no one misses the notes. You could do something complicated involving failing the build if there was something in debian/TODO, but just using debian/changelog is nice and simple and already works. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k4q1we9r@windlord.stanford.edu
Re: RFS: webfs (updated package)
Dear Christoph, söndag den 13 juni 2010 klockan 15:59 skrev Christoph Egger detta: Mats Erik Andersson mats.anders...@gisladisker.se writes: I am looking for a sponsor for the new version 1.21+ds1-5 of my package webfs. Uploaded My honest thanks for the help in uploading. That bugreport has been bugging me until a magic moment of inspiration came upon me! Mats Erik Andersson, fil. dr 2459 41E9 C420 3F6D F68B 2E88 F768 4541 F25B 5D41 Abonnerar på: debian-mentors, debian-devel-games, debian-perl, debian-ipv6, debian-qa -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100614222638.gd6...@mea.homelinux.org
Re: RFS: xpdf (updated package)
On Sun, 6 Jun 2010 00:45:31 +0400 Stanislav Maslovski wrote: On Sat, Jun 05, 2010 at 12:24:15PM -0400, Michael Gilbert wrote: On Sat, 5 Jun 2010 02:20:22 +0400 Stanislav Maslovski wrote: On the other hand, xpdf opens all files without any problems, but can be a bit slower in scrolling sometimes. The last is not a problem. I am simply afraid that with your change xpdf will follow evince's path and there will be no reliable pdf viewer in the repository anymore. If you can pinpoint some example files that crash evince but work fine in xpdf, I will test them. So far, I have not encountered any issues myself. Gentoo has been shipping xpdf-poppler for a few years now, and I haven't seen any complaints of your nature there (although I have not done an exhaustive search). See, for example evince bug #584711: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=584711 I've just tested this file. It does not crash my version of xpdf. In fact, it doesn't crash evince or evince-gtk for me. Mike -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100614194213.0d8cb657.michael.s.gilb...@gmail.com
Re: RFS: xpdf (updated package)
On Sat, 5 Jun 2010 21:34:13 +0200 Tanguy Ortolo wrote: Le samedi 05 juin 2010, Michael Gilbert a écrit : If you can pinpoint some example files that crash evince but work fine in xpdf, I will test them. So far, I have not encountered any issues myself. Gentoo has been shipping xpdf-poppler for a few years now, and I haven't seen any complaints of your nature there (although I have not done an exhaustive search). I never saw any file that made Evince crash, but I saw some files that Xpdf renders perfectly and where Evince does not display at all some fonts. For instance the LaTeX fontspec package's documentation, that you can find at http://tanguy.ortolo.eu/tmp/fontspec.pdf. I have often used Xpdf as a fallback when Evince was unable to correctly display a file. Making them use the same renderer would just leave me completely unable to read those files, so if it happens, I would try very hard to keep an old version of Xpdf as long as I can. :-/ I just tested fontspec.pdf, which revealed a couple issues with the xpdfrc file and language resources, which I've now fixed. I also believe this fixes the Japanese language problem that Charles Plessy encountered. I've uploaded a new version to mentors for testing/review: http://mentors.debian.net/debian/pool/main/x/xpdf I would be very appreciative if someone were able to review and sponsor this package. I think it is rather important to get a supportable xpdf shipped with squeeze :) Thanks, Mike -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100614205309.362012ce.michael.s.gilb...@gmail.com
RFS: googlecl (now uploaded to mentors repo)
Dear mentors, I am looking for a sponsor for my package googlecl. * Package name: googlecl Version : 0.9-2 Upstream Author : Tom H. Miller tom.h.mil...@gmail.com * URL : http://code.google.com/p/googlecl * License : Apache 2.0 Section : python It builds these binary packages: googlecl - Command-line access to (some) Google services The package appears to be lintian clean. My motivation for maintaining this package is: I'm one of the authors. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/g/googlecl - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/g/googlecl/googlecl_0.9-2.dsc I would be glad if someone uploaded this package for me. Kind regards Jason Holt
Re: RFC: Using git/collab-maint/PET for debian-mentors.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 13/06/10 10:05, Tim Retout wrote: Proposal I am considering creating a new workflow for my sponsoring: * Maintaining packages in git in collab-maint. (I don't think we want a separate pkg-mentors repository, because once people graduate from mentors they would feel compelled to move away.) * Using PET or similar to show which packages need review, and keep track of bugs/upstream versions. (Minor issue: I don't know how easy this is without putting the whole of collab-maint into PET.) * Optionally co-ordinating on IRC in #debian-mentors, as well as via notes at the top of debian/changelog. This would then require my mentees to do some things they don't do at the moment: * Register for an alioth account. * Learn how to maintain packages in a VCS. * Use the 'UNRELEASED/unstable' method of changelog management (and probably stop bothering with the RFS mails). It would also allow potential contributors to collaborate on packaging work in a team, rather than every sponsored package being worked on by exactly one person. I would most likely enforce the use of short dh7 rules files as well, and go all out on the 'lintian -iI --pedantic' warnings, same as I do with regular sponsorship. And of course, any packages which belong in other teams should be sent there - the steps above should have lowered the barrier to entry to the rest of Debian. Information that is likely to become relevant for different sponsors (like VCS in use, debian/rules style [dh/cdbs/debhelper]) could be shown on the PET page. Different sponsors are likely to have different requirements. The only problem I see is that PET does not really scale well to lots of packages, the page gets quite cluttered. So I don't know if pulling the whole collab-maint area will be of any use. - -- Saludos, Felipe Sateler -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJMFtQMAAoJEKO6uuJAjdbPKioP/0P8ufyVc//HTliJ8Xs+K4Do HZ7we1v+a5WnsIaBLDsIaZuDUfwJ5BfnGmL+kmVIv4f/XkAkkhQVHmqDm0EnqSvQ Luob721sr6QlROsRkVNWsKXZ/D9AOjF/KBFcgUjVnvpOvEDjgcCoqTpRQ9CIvQWl WMDNQ0J5gdBWNyP94TQ9pxAOfbnGOgVKKGeZvIn8/WoO2xiSpa+4stupQlrA/DZk EQL/QFfHoBhfIQ+7zogRy/jydedZp+9Cig5ijLXvTrIjbuKzRVSNaNhmUs5D0jbu 1zQaGPAY1x5i3UNKwGKnvEgZEqinuJG+k72l/ctFpXmxhR/OqlCcO/RkslqopTNy u8+KVSzSACLy6cg8QSqYpZ8Dc7rar9JW8wb3J2PJ/HM+pQRBFQyKQpnt+vLiU2We ekVrSB7tudvbOtv4hbCEeBm6fvdDtkQYeQCL1wZx33B3CUiQLCXcByS+WAz6qZBu wB+KUnO+qwmE256zCizFemiwuKdXwMh/vgl08cQ7axbnbr8SjUMlPn45IlhpLaLh Ze/qmaD7xnUTR6h2myQdgWwnwNl+/DavR09T6didMRmSeNmReueSXaUOVQIGFPb+ H3WyDhuZvULrBtorihxJxkppgvz/kMYwG01gj/T6jnIHgCvByEBTp9Gr+xG/ffCX /P7q+B9PhJVtYURKT/Vr =zlkJ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/hv6k6n$aa...@dough.gmane.org
Re: RFC: Using git/collab-maint/PET for debian-mentors.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 14/06/10 01:55, Ansgar Burchardt wrote: I started working on a version of PET that supports several VCS backends, even for a single instance: all packages show up on a single package no matter in which of the known VCS they live in. For now it supports Git and SVN as I use those myself. It still needs some work, but is slowly getting usable. Is that available somewhere? - -- Saludos, Felipe Sateler -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJMFtfnAAoJEKO6uuJAjdbPAjIP/iJuvKuG0kgdtdt/9V55Tq7Q NV779UIlJh5b5vBoA0dsYAZg8MKlRNpRhAv2QgTauqhsERdWbxarG57tLD00BUGQ 94OQr/3mizXqX1VsYyru890UyJ7r0CBdYYfNGMkoXIMjrYIbNoiY0TtwQKG6UMyf qgkDNPab1Tqq59AdrrhcbLYik9AbTUnfzbBeeX5/oFdyvUWmicBER/iOPNbccMro OCf0X9oRDz76eB8fW30KFM5w/PgtNU9Xmgc5t2ovCHo7AGeBx0xZKRLwU1rfvHP5 fIkjeIPev+cqnKNBWc8g6c9XaMrQ4Ppe411j7uZpcXLSvN73HH4/DStebz/bBHwp G5m/Wp/pevx1FY33vgfEXqJx1rNfxwbG4MzNRpGoLPVESK3Vhwo1V7eOjace7Bb4 q0Fk6ygsk+P4kv46RiPaLyzwesT9rU8yvVXdr0lrFv13qz66n7dxshgo0upvFMY8 VId7xwpYrs54+W6YncvWUHOFWcLSRf8Wfb4PtnEF2Arl32fBTbdzhUuWDS0kNnhk AJZDBM1a9GTStQI5HGNcT+RmAaizs3LPm7s+vXFNpzaOqnq3pkv4f/aabfXWyUKS Zmlr5XIbltZz4Yk1LaAis+3q1qV4mCTpSq8tn/Dg83E1UhnW0g2qdo/mqdEJQZ25 fvEcaCgKgi/nRxjgVVu6 =shof -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/hv6l59$ce...@dough.gmane.org
Re: RFS: marave - 2nd Attempt (Question: Royalty Free License)
Hi folks - Per the inspection from Paul, I mailed the folks at Partners In Rhyme about the use of the audio files from the email titled: Re: RFS: marave - 2nd Attempt There was some questioning about the copyrights that they have on their website so I thought I might try to pin down something a bit more exact. Here it the exchange posted. I hope this clears up the use of the files. If not, please let me know! I'll continue to work on a completed package by the weekend. Of course, all comments are welcome! Thanks everyone! Best regards, Chris - Begin forwarded message: Date: Mon, 14 Jun 2010 10:21:36 +0200 From: Partners In Rhyme partnersinrhyme@gmail.com To: Chris Silva rac...@makeworld.com Subject: Re: Question: Royalty Free License Any of those three GPLs is fine. Regards, Mark Lewis Partners In Rhyme www.partnersinrhyme.com www.musicloops.com www.sound-effect.com On Sat, Jun 12, 2010 at 8:54 PM, Chris Silva rac...@makeworld.com wrote: *Question from Partners In Rhyme Site,* *Subject Of Inquiry:* Royalty Free License *Name:* Chris Silva *Email:* rac...@makeworld.com *Question:* I am a package maintainer for Debian. I am currently working on a package called Marave (it\'s an editor for writing). The author included some sound effects (clicks and beeps) from your site. In order to meet Debian copyright rules, I need to know what copyright to include in our Copyright file. For example, Open Source code generally falls under GPL, GPL-2, and GPL-3. Please provide this information so I can continue working on this package and include your files. Thank you! Any of those three GPLs is fine.Regards,Mark LewisPartners In Rhymewww.partnersinrhyme.comwww.musicloops.com www.sound-effect.com On Sat, Jun 12, 2010 at 8:54 PM, Chris Silva rac...@makeworld.com wrote: Question from Partners In Rhyme Site, Subject Of Inquiry: Royalty Free License Name: Chris Silva Email: rac...@makeworld.com Question: I am a package maintainer for Debian. I am currently working on a package called Marave (it\s an editor for writing). The author included some sound effects (clicks and beeps) from your site. In order to meet Debian copyright rules, I need to know what copyright to include in our Copyright file. For example, Open Source code generally falls under GPL, GPL-2, and GPL-3. Please provide this information so I can continue working on this package and include your files. Thank you!
Re: Asking for DMUA: Yes while seeking first sponsor
On Tue, Jun 15, 2010 at 12:13 AM, Alexander Reichle-Schmehl toli...@debian.org wrote: I noticed that recently some people seem to seek first time sponsors while asking for setting the DM-Upload-Allowed: yes flag at the very same time. This isn't the only misuse of DMUA that exists, some people set it in their package instead of asking the sponsor to set it. Others go further and do not mention that in debian/changelog nor in their RFS mail. While I can certainly understand Maintainers want to upload their packages ASAP themselves, I would like to point out that I consider that quite against the spirit of the Debian Maintainer Concept. The idea is, that you convince an (experienced) Developer, that you can do your work on your own on a per package basis. As Debian Maintainers don't need to pass the regular procedures to check their technical capabilities (so to speak), the idea is to select the packages you are allowed to upload on a case by case basis. Or to give you an example: Just because you can package simple game doesn't necessarily mean you can package and maintain a shared library. So I think asking for DMUA:Yes while seeking an initial sponsor is just plain wrong, as convincing a DD shouldn't be a one timer. I therefore ask DMs not to ask to set this flag on the first upload, and DDs not to do so. Perhaps the problem here is one of communication? Maybe Debian isn't communicating the above to new DMs properly? As an aside, I'd personally like to see DMUA move from source packages to a mail bot or LDAP or something else. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktik-xtptbh5938oxujyvabgoqax4oanngczto...@mail.gmail.com
Re: RFS: googlecl (now uploaded to mentors repo)
Please do not use HTML email on Debian lists: http://www.debian.org/MailingLists/#codeofconduct -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimw5uzcov6mz7w0ijncq1ao0hu92n_a7emdp...@mail.gmail.com
Re: RFC: Using git/collab-maint/PET for debian-mentors.
On Tue, Jun 15, 2010 at 9:15 AM, Felipe Sateler fsate...@gmail.com wrote: The only problem I see is that PET does not really scale well to lots of packages, the page gets quite cluttered. So I don't know if pulling the whole collab-maint area will be of any use. I suppose that depends on how much or little work the team does on their packages? As an aside: I'd personally like PET to be available to any maintainer/uploader address from qa.d.o and pull stuff from Vcs-* fields, in addition to the per-team instances that exist now. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikmnehuggsepllvh39fr9qdl5we3b-jtcyf_...@mail.gmail.com
