Bug#719794: RFA: update-inetd -- inetd configuration file updater
Package: wnpp Severity: normal I request an adopter for the update-inetd package. The package description is: This package provides a program used by other packages to automatically update /etc/inetd.conf, the configuration file shared by all implementations of the Internet super-server. . Note that xinetd is not supported by this package. update-inetd is a native package, implemented in perl, and with system tests in python. update-inetd has serious design flaws and is meant to be replaced by another tool, as described in DEP9 (http://dep.debian.net/deps/dep9/) The adopter should look at DEP9, and consider also adopting reconf-inetd (also RFA'd, see #719792). -- 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/20130815122454.24989.5467.reportbug@mobee
Bug#673600: RFS: nyancat/1.0+git20120519.5fe3de9-1
quoting Jakub Wilk: But next reconf-inetd run can happen a month later. (Or never.) In the mean time, nyancat server won't be running, will it? Or did I misunderstand something? That's right. I take responsibility for that; I didn't realise that the postinst script would run after the reconf-inetd trigger. In any case, the solution is simple: invoke reconf-inetd right after update-inetd in postinst. On a different topic, nyancat/1.0+git20120519.5fe3de9-1 checks for only a specific release: if [ $2 = 0.1+git20120401.5a88b86-1 ]; then whereas ideally it'd take action on any release less than or equal to that. (perhaps that's not relevant to nyancat, but it'd be nice to get it right, because I suspect that other maintainers will copy from it) thanks, sez -- Every great idea is worthless without someone to do the work. --Neil Williams -- 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/20120602112901.GA19589@mobee
Bug#673600: RFS: nyancat/1.0+git20120519.5fe3de9-1
On Sat, Jun 02, 2012 at 05:27:30PM +, Jakub Wilk wrote [edited]: [..] I would add -x/--line-regexp to the fgrep call. Wouldn't it be nice if the postinst also take care of the case when the user enabled the service? the line I'm suggesting in dep9 is: if fgrep -q '^exact entry previously added by update-inetd$' /etc/inetd.conf \ which is not really concerned with whether the line is disabled or not. I think both cases are valid for removal, as long as they have not been locally modified (hence the '^...$' pattern). -x is a fine suggestion. thanks again to both of you. -- Every great idea is worthless without someone to do the work. --Neil Williams -- 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/20120602180437.GC19589@mobee
Bug#673600: RFS: nyancat/1.0+git20120519.5fe3de9-1
On Sat, Jun 02, 2012 at 07:03:33PM +, Jakub Wilk wrote: * Jonathan McCrohan jmccro...@gmail.com, 2012-06-02, 19:27: I would add -x/--line-regexp to the fgrep call. Wouldn't it be nice if the postinst also take care of the case when the user enabled the service? Couldn't both of these issues be addressed by removing '#off# ' from the grep? I think we do need -x (or an equivalent of it). If the user appended some options to nyancat-server command-line, we must not remove such entry. agreed. I'd keep it simple and use two fgrep -x invocations; one with and another without '#off# ' BTW, shouldn't you use --pattern (instead of, or maybe in addition to, --multi)? --patern is not implemented for --remove. I guess I should add support for it. -- Every great idea is worthless without someone to do the work. --Neil Williams -- 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/20120602193111.GD19589@mobee
Bug#673600: RFS: nyancat/1.0+git20120519.5fe3de9-1
On Sat, Jun 02, 2012 at 07:33:31PM +, Serafeim Zanikolas wrote: On Sat, Jun 02, 2012 at 07:03:33PM +, Jakub Wilk wrote: * Jonathan McCrohan jmccro...@gmail.com, 2012-06-02, 19:27: BTW, shouldn't you use --pattern (instead of, or maybe in addition to, --multi)? --patern is not implemented for --remove. I guess I should add support for it. fwiw update-inetd 4.43, which adds support for --pattern in remove mode, has just been accepted to unstable so you could try: update-inetd --multi --pattern nyancat --remove telnet -- Every great idea is worthless without someone to do the work. --Neil Williams -- 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/20120602230130.GE19589@mobee
Re: Report from the debconf11 sponsoring/mentors BoF.
David, thanks for the report. Another issue that was mentioned during the QA is that debian-mentors is a misnomer and should ideally be called smth like debian-packaging. debian-mentors should become a discussion list for people that care about mentoring in Debian. Nitpicking aside, I care about mentoring but I don't have time for RFS calls (other then the people I already sponsor) so it'd be wasteful to subscribe to -mentors and I would rather have this discussion in -project instead. I suspect I'm not the only one like that. On Sun, Sep 11, 2011 at 08:44:23AM -0300, David Bremner wrote [edited]: Sponsor guidelines and tracking --- Up to now, sponsor metrics do not exist yet. For now we rely on static lists, giving people hints whom they shall ask for sponsoring if the general RFS procedure on debian-mentors did not yield any success (or, also along the usual RFS procedure). I (Arno) am currently staging a patch to Debexpo introducing limited support for sponsor metrics. It does not (and will not) feature the whole idea, but will allow developers, who are sponsoring packages to publish their personal sponsor guidelines in a more or less structured way. This will allow sponsored maintainers to learn about potentially interested developers more reasily, as the information is being coll- ected on a central, common place. Please stay tuned, I will announce this feature on behalf of the Debexpo team when it is deployed. Mean- while you are invited to test it and give feedback on it. Please contact Arno [6] if you want to have an exclusive look. Please note, no further matching is effectuated, in particular we are not trying to guess the right sponsor for a package. A sponsored main- tainer is on its own to find the best sponsor for his package. Nonethe- less it is hopefully still an improvement and can be used as starting point for further work. Arno, Janos (Cc'ed) expressed interest during DebConf in helping out as well, but I haven't had the time to ping him about it. I understand that there's two sides in this effort: debexpo plugins that produce additional info about certain package features, and a repository of sponsors' interests/preferences/requirements. Do I understand correctly that you implement both things within debexpo? Are DDs expected to enter their preferences via the debexpo web ui? My idea instead was to maintain DDs' preferences via an ikiwiki instance (using something structured like yaml), and make the wiki data accessible to debexpo via a REST interface. At the end of the day, it's up to whoever will do the work, but it's wise to remember that geeks prefer their favourite text editor than a web browser. Anyhow, thanks for stepping up, and whatever your approach, please share any code you have with Janos and see whether/how you could work together. cheers, sez -- Every great idea is worthless without someone to do the work. --Neil Williams -- 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/20110911215606.GD3458@mobee
Re: RFS: apt-listbugs (updated package)
Hi, I am looking for a sponsor for the new version 0.1.4 I'll look at it this evening. Cheers, Serafeim ps. with apologies for breaking the thread (the web client I'm using doesn't seem to have a way to set in-reply-to) -- 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/AANLkTi=sM-D==nt8wrkn4atx-0qtzne_0sty42fnr...@mail.gmail.com
Re: RFS: morse (updated package)
On Sat, May 15, 2010 at 12:09:58PM +0300, Nanakos Chrysostomos wrote [edited]: i think that now is fine according to your proposed changes. Uploaded. Thank you for your contribution to Debian! -- debtags-organised WNPP bugs: http://members.hellug.gr/serzan/wnpp -- 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/20100521190558.ge2...@mobee
Re: RFS: morse (updated package)
Chris, In debian/copyright * please replace: This work was packaged for Debian by: Nanakos Chrysostomos nana...@wired-net.gr on Thu, 12 May 2010 20:45:18 + This package was debianized by Joop Stakenborg pa3...@debian.org on Tue, 21 Feb 2006 23:36:14 +0100 with: This package was debianized by Joop Stakenborg pa3...@debian.org on Tue, 21 Feb 2006 23:36:14 +0100, and is currently maintained by Nanakos Chrysostomos nana...@wired-net.gr. * the packaging license should match the upstream license, ie. The Debian packaging is (C) 2006, Joop Stakenborg pa3...@debian.org and is licensed under the GPL, see `/usr/share/common-licenses/GPL'. should become: The Debian packaging is © 2006, Joop Stakenborg pa3...@debian.org and is licensed under the same terms as the upstream software. * I already mentioned to replace all occurrences of (C) with ©; lintian reports this as copyright-with-old-dh-make-debian-copyright * finally, the placeholder below should be removed from debian/copyright (again, lintian reports this as copyright-contains-dh_make-todo-boilerplate): # Please also look if there are files or directories which have a # different copyright/license attached and list them here. debian/patches/03morse: * the second hunk in there is redundant; please remove it Finally, switching to minimal dh rules would be nice, but I understand if you'd rather leave it for the next upload. Cheers, Serafeim -- debtags-organised WNPP bugs: http://members.hellug.gr/serzan/wnpp -- 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/20100516135403.ga3...@mobee
Re: RFS: morse (updated package)
[please cc me as I'm not on the list] Hi again Chris, On Thu, May 13, 2010 at 09:12:15PM +0300, Nanakos Chrysostomos wrote: On 13/5/2010 20:10, Serafeim Zanikolas wrote: debian/copyright: ``it is currently maintained by Chris...'' should be part of the very first sentence that talks about the debianisation; where it's now gives the impression that you are the *upstream* maintainer! please revise the file to be more like the example given in the New Maintainer's Guide, section 4.2 (pay attention to headers, indentation and using © instead of (c)) Please read the above and revise debian/copyright accordingly. Perhaps you could use the template from the NM guide as a basis, and fill in the details from the existing copyright file. Finally, please extract all changes to upstream files to patches (eg. with I should clarify that the changes should be grouped into patches based on their function, eg. a patch for fixing includes across files, another for the configure/make plumbing, and so on. -S -- debtags-organised WNPP bugs: http://members.hellug.gr/serzan/wnpp -- 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/20100514183455.ga2...@mobee
Re: RFS: morse (updated package)
[please cc me as I'm not on the list]
Hi Chris,
On Thu, May 13, 2010 at 06:02:11PM +0300, Nanakos Chrysostomos wrote [edited]:
P.S: I had already increased the version in Build-Depends for debhelper
Not in the version I reviewed :)
( debhelper 5.0.0)
``x'' means strictly higher than x, whereas you want ``=x'' (at least x);
see policy 7.1
OK here's a few more remarks (some of which I should have mentioned in my
first email).
debian/changelog:
* Added ${misc:Depends} to rules file. -- ``... to debian/control file''
* Updated debian/compat to version 5.
* Changed debhleper version to control file so to correspond
the new changes.
--
The latter is quite ambiguous. How about:
* Bumped debhelper versioned Build-Depends to 5, and updated debian/compat
debian/copyright:
``it is currently maintained by Chris...'' should be part of the very first
sentence that talks about the debianisation; where it's now gives the
impression that you are the *upstream* maintainer!
please revise the file to be more like the example given in the New
Maintainer's Guide, section 4.2 (pay attention to headers, indentation and
using © instead of (c))
debian/dirs:
debian/dirs lists usr/sbin even though the package puts nothing under
/usr/sbin. You could have found that out with lintian :)
Finally, please extract all changes to upstream files to patches (eg. with
quilt; see http://wiki.debian.org/UsingQuilt):
$ lsdiff -z ../morse_2.1-4.diff.gz | grep -v '\/debian\/'
morse-2.1/Makefile
morse-2.1/morseX11.1
morse-2.1/morse.d/Makefile
morse-2.1/morse.d/morse.c
morse-2.1/qso.d/QSO.c
morse-2.1/qso.d/grammar.c
You'll know you've done all that's required once the above command's output is
empty. It is important that debian-originated changes are explicitly
identified (and can thus be more easily shared, eg. via patch-tracking.d.o)
Cheers,
Serafeim
--
debtags-organised WNPP bugs: http://members.hellug.gr/serzan/wnpp
--
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/20100513171003.gh2...@mobee
Re: RFS: morse (updated package)
[please cc me as I'm not on the list]
Hi Chrysostomos,
First, there's a bunch of (co)authors apart from ESR that are currently missing
from debian/copyright. Please go through all source files, might have to dig
into the HISTORY file as well, and update accordingly debian/copyright.
Also, add to the packaging copyright: ``... and is currently maintained by
your name your email''
Other issues:
- uncommenting ``-$(MAKE) clean'' is not the proper way to fix the
debian-rules-ignores-make-clean-error lintian warning. Please read the
output of ``lintian-info -t debian-rules-ignores-make-clean-error'' for the
recommended way
- please document in debian/changelog every single change you make, including
the addition of ${misc:Depends}, update of debian/compat, addition of
debian/source/format
- you've updated debian/compat to 5, but you must also increase the versioned
Build-Depends for debhelper; please also consider switching to the latest
version (7)
Cheers,
Serafeim
--
debtags-organised WNPP bugs: http://members.hellug.gr/serzan/wnpp
--
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/20100511190454.gb2...@mobee
RFS: libbeanstalkclient-ruby (client library to a msg queueing service)
[Please CC me on replies as I'm not subscribed in d-mentors] - Forwarded message from Serafeim Zanikolas ser...@hellug.gr - Date: Sun, 6 Dec 2009 11:13:07 +0100 From: Serafeim Zanikolas ser...@hellug.gr To: debian-r...@lists.debian.org Subject: RFS: libbeanstalkclient-ruby (client library to a msg queueing service) Hello debian rubyists! I seek sponsorship for a ruby client library to beanstalkd [0] http://members.hellug.gr/serzan/tmp/deb/libbeanstalkclient-ruby_1.0.2-1.dsc The packaging is done the standard way, is lintian-clean, and has been tested with pbuilder. I've tested the basic functionality of the library with [1] in a clean sid root [2] I'd be more than happy to maintain the debian dir in the pkg-ruby-extras svn, if I were given access (my alioth id is sez-guest). Cheers, Serafeim [0] beanstalkd is a simple message queueing server, ITP #557128, pending upload from my regular sponsor [1] http://members.hellug.gr/serzan/tmp/deb/test.rb [2] if you'd like to reproduce the test, grab beanstalkd from http://members.hellug.gr/serzan/tmp/deb/beanstalkd_1.4.3-1.dsc - End forwarded message - ps. beanstalkd has already been uploaded will hit the archive within a week -- debtags-organised WNPP bugs: http://members.hellug.gr/serzan/wnpp -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: update-inetd (98% popcon; closes ITA and 10 other bugs)
Hi Patrick, On Mon, Aug 31, 2009 at 08:46:08PM +0200, Patrick Matthäi wrote [edited]: W: update-inetd: manpage-has-errors-from-man usr/share/man/man8/update-inetd.8.gz 200: warning [p 3, 6.0i]: can't break line not much I can do about this, it's just a long line that gives a syntactic example so I'd rather refrain from reformatting it (it'd add confusion) I: update-inetd: hyphen-used-as-minus-sign usr/share/man/man8/update-inetd.8.gz:14 [..] fixed I: update-inetd: unused-debconf-template update-inetd/title I: update-inetd: unused-debconf-template update-inetd/ask-several-entries I: update-inetd: unused-debconf-template update-inetd/ask-entry-present I: update-inetd: unused-debconf-template update-inetd/ask-remove-entries I: update-inetd: unused-debconf-template update-inetd/ask-disable-entries These are false positives (I've added an override): $ lintian-info -t unused-debconf-template ... N: In some cases, the template is used but Lintian is unable to determine N: this. Common causes are: ... N: - the template is not used by the maintainer scripts but is used by a N: program in the package ... N: If any of the above apply, please install an override. BTW I took this opportunity to make the xinetd warning less ugly: --- a/update-inetd +++ b/update-inetd -print STDERR Note: xinetd seems to be installed but update-inetd does not\n; -print STDERR currently support it. For more information see\n; -print STDERR /usr/share/doc/xinetd/README.Debian and itox(8).\n; +print STDERR Note: xinetd currently is not fully supported by update-inetd.\n; +print STDERR Please consult /usr/share/doc/xinetd/README.Debian and itox(8).\n; The .dsc url remains the same. Cheers, Serafeim -- debtags-organised WNPP bugs: http://members.hellug.gr/serzan/wnpp -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
RFS: update-inetd (98% popcon; closes ITA and 10 other bugs)
[please CC me on replies, I'm not subscribed] Hi, I need a sponsor for my adoption of update-inetd. This upload closes 11 bugs, a couple of which are a decade old(!), and adds a rather extensive test suite. dget http://members.hellug.gr/serzan/tmp/deb/update-inetd_4.32.dsc FYI I plan to migrate update-inetd to triggers, based on input from Roger Leigh (see #541872 msg35 onwards), but that's long-term (over a stable release), so this upload is just bug fixing. Cheers, Serafeim -- debtags-organised WNPP bugs: http://members.hellug.gr/serzan/wnpp -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
FYI: script to query WNPP bugs using debtags
Hi, As a way of encouraging QA uploads and package adoption, I've written a python script to query WNPP bugs (minus RFPs) using debtags. Try: git clone g...@github.com:sez/wnpp-by-tags.git cd wnpp-by-tags/ # read the manpage make view-man # look for orphaned and RFA'd packages implemented in python that don't use gtk ./wnpp_by_tags.py -t o,rfa -m implemented-in::python -x uitoolkit::gtk # list debtags you can query against ./wnpp_by_tags.py -l Enjoy, Serafeim -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: FYI: QA uploads primer
Or you can point people who don't want to learn how to package things properly I don't care about those either -- the intended audience was those that could use a tutorial to get a feel for the process before they make up their mind about how to package things properly and to eventually adopt packages. And if that wasn't clear enough in the primer, no argument in the world would convince me that it's not possible to make it as clear as it needs to be ... I still can't believe that you two guys, instead of making concrete suggestions for improvement, conclude that one less tutorial will make for higher-quality RFSs ... *sigh* -S ps. Please DON'T CC me on replies, I've had enough of this -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: FYI: QA uploads primer
Sandro, in your first reply, you suggested 3 alternatives, one of which was fix it. You seem to be quite upset despite me taking into account your specific suggestions for improvements. I'm just curious, what more would it take for you to consider it fixed? I see your point about low-quality RFSs and the limited time of DDs, but your thesis basically boils down to let's have less documentation so that the wrong people won't even try. On Tue, Jun 16, 2009 at 08:13:03AM +0200, Sandro Tosi wrote [edited]: it will be your fault to keep spreading damn wrong suggestions. Have you looked at wiki.d.o/HowToPackageForDebian? Here are some damn wrong suggestions from that page: This HowTo is intended to show that Debian packaging is not that hard. Since Debian packaging is not that hard, why shouldn't plain beginners understand and do it, too? [..] Since the Debian Policy and the Debian New Maintainers' Guide sometimes are too big to read for people who prefer a more pragmatic approach to problems, this HowTo will focus on a pragmatic approach to learning how to create Debian packages. Pragmatic approach? Too big to read? Crazy talk, huh? I say let's remove that wiki page too. In fact, let's drop the whole wiki and replace it with your great suggestion: Read the policy, devref, and newmaint ... and use your brain. -S ps. I've removed all wiki links to the QAUploadsPrimer; feel free to delete the page -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: FYI: QA uploads primer
On Tue, Jun 16, 2009 at 10:48:07PM +0200, Sandro Tosi wrote [edited]: On Tue, Jun 16, 2009 at 22:19, Serafeim Zanikolasser...@hellug.gr wrote: re-evaluating your contributions it's a complete waste of time, so That was the whole point: my contributions weren't good enough and I asked what contributions *you* would consider good enough. But it doesn't matter now that I know that HowToPackageForDebian isn't good enough for you either. no man, you lack reasoning: you're just compiling a long list of items to avoid to read those docs. We have formal documents, and people willing to do packaging MUST read them, no excuses, EVER. I've obviously read the docs, but not all 3 front-to-cover before my first upload. and who cares? I'm not the editor of the wiki, and I don't review all the pages. Now, since you spotted it, please fix it. I've deleted my page but I won't go about fixing what I don't find broken. By all means, contact its author and ask them to stop spreading damn wrong suggestions mmm... I stopped myself to call you bad words after this affirmation. Sadly, same here, for the best part of this exchange. -S -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: FYI: QA uploads primer
Thanks for the feedback Sandro. I've written the primer for technical-minded debian users that (a) want to contribute to debian, but are uncertain about their long-term time-commitment; and (b) given their uncertain commitment, won't read the whole policy, devref, and newmaint guide just for the sake of trying out the water. Of course anyone seriously interested in packaging should eventually read all 3 docs, but it helps if there's a shorter cheatsheet (with appropriate pointers) to get started. On Mon, Jun 15, 2009 at 08:33:57AM +0200, Sandro Tosi wrote [edited]: 1. QA uploads are nothing different from a normal upload except for the Maintainer field; does it worth a full wiki page? A paragraph in some other QA page would be enough Technically yes, but they are different in terms of expected time-commitment from the person preparing the upload. For that reason alone, it's worth having a guide for potential not-yet-committed contributors. 2. read or skim through the table of contents of the Debian new maintainer's guide (so that you know where to lookup things you might need) ??? policy and devref are just a waste of time? this is a wrong suggestion (without mentioning the other 2 docs). The debian developer's guide is mentioned two bullets below the one you cite. I've added after that: * eventually you must also become familiar with the debian policy (but for now you might get away with using lintian, described below) Bear in mind that the point of the primer is to get people started asap, instead of discourage them by saying ``we don't want to even hear from you until you finish these 3 long docs'' And frankly, I think that lintian does a very good job at catching most policy violations, so until one gets serious enough about packaging to actually read the whole policy, we should at least make sure that they use lintian. 3. an orphaned package has its Maintainer set to Debian QA Group packa...@qa.debian.org what for those that are orphaned but never received a QA upload? qa.debian.org/orphaned.html to have such list adapted phrasing and added the above url at the next bullet 4. it's NOT okay to edit any upstream file; for that, you'll have to use a patch management system (such as quilt [2]) too strong requirement IMO. if an orphaned package already does direct upstream code changes, might be ok to keep doing them in the qa upload. I've made the statement milder (added typically), feel free to edit more yourself 5. the first entry in debian changelog should be QA upload dch does the right thing without specify anythinh (just update maintainer field first to QA if it's not yet) fixed 6. if the package is team-maintained (see the Maintainer field in debian/control, you might have to commit your changes to the team's repository; but this shouldn't be the case because we said that you'd work on an orphaned package ) so why mention it?? this is wrong. It's orphaned, no need to commit anythin to the ex-team. removed 7. repeat steps 3-4 there are no numbers in your doc. fixed 8. check that your newly-built .deb installs, uninstalls, and re-installs without problems (you did choose a non-critical package, so this should be okay even if your package is horribly broken) what?? never mind, removed the stuff in parens 9. if you have modified the package's dependencies, use pbuilder to confirm that the package builds successfully USE PBUILDER IN ANY CASE BEFORE UPLOAD TO MENTORS!!! fixed btw I've added a link to the QA wiki from DebianDevelopment (it seemed completely isolated from the rest of the wiki) Cheers, Serafeim -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: FYI: QA uploads primer
On Tue, Jun 16, 2009 at 12:01:30AM +0200, Sandro Tosi wrote: On Mon, Jun 15, 2009 at 23:00, Serafeim Zanikolasser...@hellug.gr wrote: Thanks for the feedback Sandro. I've written the primer for technical-minded debian users that (a) want to contribute to debian, but are uncertain about their long-term time-commitment; and (b) given their uncertain commitment, won't read the whole policy, devref, and newmaint guide just for the sake of trying out the water. No, that's again wrong: you can't do a quality work without ready those documents (with this order: policy, devref, NM Guide). This is a false statement you're making and I'm stopping here reading your email. There's a tradeoff: encouraging potential new contributors (in the hope that they'll eventually read all the docs) at the cost of initially lower-quality RFS requests, or making it clear from the start that packaging is hard and time-consuming and they shouldn't even bother until they've read all 3 docs in full [1] If you want pursuit this road, you'll drive apart potential future contributors because the moment they'll send the RFS and they'll get scolded very heavy due to their lack of basic knowledge, they do really wasted their and our time. The primer repeatedly mentions lintian, which catches most policy violations, and (if you would have read the previous email, you'd know that it) by now also mentions policy as a must in the preparation section ... I honestly don't mind dropping the page, but I haven't been convinced that the issues you raise can't be addressed by adding more references and warning flags in the doc. -S [1] the successor of mentors.d.n, which can easily automatically reject packages with lintian errors, would eliminate this problem -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
FYI: QA uploads primer
Hi, Those interested in packaging, but not certain about making a long-term commitment might be interested in a practical primer for QA uploads: http://wiki.debian.org/QAUploadsPrimer (A QA upload is a one-off maintenance act of an orphaned package (as opposed to an upload that declares one's adoption of the package)) Cheers, Serafeim ps. please CC me on replies as I'm not subscribed to d-mentors -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
prerm/postinst scripts failing silently(?)
Hi all,
I'm adopting a package that produces several binaries, and I need to adapt it
so that every binary will have its own prerm and postinst scripts (issue
#315318). I tried calling the scripts debian/binaryX.{prerm,postinst}, but
they seem to be ignored when installing the binary packages (postinst calls
update-alternatives but there is no sign of it actually being called), and I
don't see any error messages when installing the package by hand). Attached
are the scripts for one of the binaries.
Any hints on how I could debug this?
Cheers,
Serafeim
ps. please CC me as I'm not on the list
#!/bin/sh
set -e
utils=bogofilter bogoupgrade bogotune bf_copy bogolexer bogoutil bf_compact
bf_tar
man1_dir=/usr/share/man/man1
case $1 in
configure|abort-upgrade)
for util in $utils; do
#update-alternatives --quiet --install \
update-alternatives --verbose --install \
/usr/bin/$util $util /usr/bin/${util}-bdb 20 \
--slave $man1_dir/${util}.1 ${util}.1 $man1_dir/${util}-bdb.1
done
;;
*)
echo postint called with unknown argument \`$1' 2
exit 1
;;
esac
#!/bin/sh
set -e
utils=bogofilter bogoupgrade bogotune bf_copy bogolexer bogoutil bf_compact
bf_tar
case $1 in
remove|deconfigure)
for util in $utils; do
# this won't run when upgrading from version 1.2.0-2
if [ -e /etc/alternatives/$util ]; then
update-alternatives --quiet --remove $util
/usr/bin/${util}-bdb}
fi
done
;;
*)
echo prerm called with unknown argument \`$1' 2
exit 1
;;
esac
Re: prerm/postinst scripts failing silently(?)
Thanks for the response Patrick. It turns out that I was omitting to copy the prerm/postinst scripts (to debian/X/DEBIAN/). I'm used to debhelper which does this automatically, but in this case I'm dealing with a bare bones makefile. -S -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#496544: RFS: reportbug-ng (closes RC #496544)\
On Wed, Aug 27, 2008 at 11:14:55AM +0200, Thijs Kinkhorst wrote [edited]: On Wednesday 27 August 2008 09:09, Serafeim Zanikolas wrote: For future reference, where is this information recorded? http://packages.qa.debian.org/r/reportbug-ng.html shows: [..] Thanks Thijs. I must have only checked the package's bts page, where the cited bug isn't listed because it's archived. I find it counter-intuitive that a bug with such a significance to the package's fate is archived. -S -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: I want to contribute to Debian
Hello Fabio, On Wed, Aug 27, 2008 at 08:14:06PM +0200, Fabio Balzano wrote [edited]: Hello, I am Fabio Balzano, I write from Italy, I use debian sinc 1999 and currentli I am system administrator of different systems for my customers all debian based. I also made VOIP systems asterisk based with custom modifications and c modules. I want to help Debian and [..] Check out a couple of recent posts for newcomers: http://lists.debian.org/debian-mentors/2008/08/msg00385.html http://lists.debian.org/debian-mentors/2008/08/msg00395.html Cheers, Serafeim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: I adopted a package but nobody seems to want to upload it
Hi Noel, On Fri, Jul 11, 2008 at 04:21:03PM +0200, Noel David Torres Taño wrote: Hello all: I've adopted wmaker-data which was Orphaned, and adapted it to actual Policy. It's in mentors.debian.net but it seems that nobody wants to upload it. Can somebody upload it and help me a (very little bit) to make next version lintian-clean and updated? IANADL but here's some feedback: - you've built it as a native package when instead it should be a non-native one (see sect 5.4. in the developer's reference and sect 2.4. in the new maintainer's guide); your additions/changes should instead be in a separate .diff.gz - the short description should start with a lower-case letter - in debian/copyright after this package was debianized by [...], add and is currently maintained by your name and email here - in debian/changelog, s/to fill actual Policy requirements/to comply with Policy/ - there's a stale debian/debhelper.log Cheers, Serafeim ps. these are pretty basic mistakes; consider at least skimming through the cited docs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[OFF TOPIC] pgp signing (was: RFS: ucblogo ... )
Hi Joe, On Wed, Jun 11, 2008 at 01:25:15AM -0400, Joe Smith wrote [edited]: A preferable system is the multipart/signed mimetype's application/pgp-signature protocol, that most people here who use OpenPGP signatures seem to use. A few User Agents (most notably some of Microsoft's) get that wrong, but most get it right. OF course the old fallback of text/plain with PGP plaintext signatures always work, although does make the message more visibly cluttered, and harder to automatically validate. I've been using the following macro in mutt, and changed it to text/*; Any suggestions for how to switch to multipart/signed are welcome. macro compose S Fgpg --sign --armor --textmode --clearsign\ny^T^Uapplication/pgp; format=text; x-action=sign\n 'clearsign the message' Cheers, Serafeim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [OFF TOPIC] pgp signing (was: RFS: ucblogo ... )
On Wed, Jun 11, 2008 at 10:14:44PM +0200, Ansgar Burchardt wrote: Mutt supports PGP directly. When composing a message, just before sending it on its way, press p to enter the PGP menu, and select s to sign your message. Thanks Ansgar! BTW I still need sponsors for the following package updates: http://members.hellug.gr/serzan/debian/gnuplot_4.2.2-1.1.dsc http://members.hellug.gr/serzan/debian/apt-howto_2.0.2-3.1.dsc -S -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: apt-howto (package update; fixes RG bug 484372)
Hi Michal, On Tue, Jun 10, 2008 at 02:55:25PM +0200, Michal Čihař wrote: Maybe you should put it to mentors.debian.net to have reliable place for others to download... Sorry for the inconvenience, it seems to be up now. -S -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: ucblogo (updated package that fixes RC bug #484448)
pgptug7FJS2gB.pgp Description: PGP message
Re: RFS: ucblogo (updated package that fixes RC bug #484448)
On Sun, Jun 08, 2008 at 06:48:48PM +0800, Paul Wise wrote: On Sun, Jun 8, 2008 at 6:06 PM, Serafeim Zanikolas [EMAIL PROTECTED] wrote: Please put some text in your emails with details of the package to be sponsored. RFS: ucblogo (updated package that fixes RC bug #484448) #484448 is a RG (release goal) bug not an RC one. Ah okay. Where can we find your package? This should download everything required, right? dget http://members.hellug.gr/serzan/debian/ucblogo_5.5-2.1.dsc -S -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: gnuplot (package update; fixes RG bug 484389)
pgp78XBhLWrZr.pgp Description: PGP message
RFS: apt-howto (package update; fixes RG bug 484372)
pgpSOJvZdCITB.pgp Description: PGP message
Re: Request for comments (before I file a RFS)
Hi Sveinung, Here's some quick feedback but bear in mind that IANADD or any other two letter acronym. On Fri, May 02, 2008 at 07:46:04PM +0200, Sveinung Kvilhaugsvik wrote [edited]: I have a few questions I hope someone can answer: Should I install the examples? In that case, should they be in doc? Yes, in doc/examples. Use dh_installexamples. Should I run the tests during the build? Yes, assuming the tests don't take too long to run. (If you have time to take a look at the package:) Are there things in it that I should improve? Have I made any mistakes? This is the first lintian gives several warnings, please fix them. The one-line synopsis should not be capitalised and not end with a period. The current standards version is 3.7.3 but your package states 3.7.2. See /usr/share/doc/debian-policy/upgrading-checklist.txt.gz Cheers, Serafeim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
