Re: RFS: QTM - Qt4 blogging client
There was an error in the debian/rules file. I temporarely hardcoded: rm -f obj-i486-linux-gnu/qtm.1.gz And forgot to change it to: rm -f $(DEB_BUILDDIR)/qtm.1.gz However, I felt it will be better to use simple-patchsys.mk instead and patch CMakeLists.txt to remove .gz before generating it. So now here's a corrected version: http://kadu.net/~patryk/qtm/qtm_0.5.8.2-1.dsc http://kadu.net/~patryk/qtm/qtm_0.5.8.2-1.diff.gz http://kadu.net/~patryk/qtm/qtm_0.5.8.2.orig.tar.gz -- Patryk Cisek signature.asc Description: This is a digitally signed message part.
RFS: QTM - Qt4 blogging client
Package name: QTM Version: 0.5.8.2 Upstream author: M.J. Smith indigojo_uk AT yahoo DOT co DOT uk Home page: http://qtm.blogistan.co.uk License: GPLv2 or later Section: x11 Location of the package: http://kadu.net/~patryk/qtm/qtm_0.5.8.2-1.dsc http://kadu.net/~patryk/qtm/qtm_0.5.8.2-1.diff.gz http://kadu.net/~patryk/qtm/qtm_0.5.8.2.orig.tar.gz QTM is a blogging client based on Qt4 library. It's presently capable of composing, formatting and submitting blog entries to a weblog. QTM works with blogs based on most of the major blogging systems available today, including Wordpress (e. g. wordpress.com), Movable Type and Drupal. It's robust, stable and actively developed upstream. signature.asc Description: This is a digitally signed message part.
Re: stripping by upstream
On Monday 13 August 2007 19:38:35 Russ Allbery wrote: Kevin Coyner [EMAIL PROTECTED] writes: Such is the case with my packages. Upstream does strip in the Makefile. Aside from editing the Makefile using dpatch, is there anything else that is easily done to correct this? I know this seems straightforward, but I just wanted to ask before I start editing upstream where before it was left untouched. If upstream does something nice like use a STRIP variable to hold the path to strip, you can run: make install STRIP=: in your debian/rules (or make, whichever is appropriate). You can use similar tricks to remove -s from install if upstream puts such things into makefile variables. If they don't, you have to patch the Makefile. Or patch the configure script in autotools project. For example in kadu package configure checks if it was run with --enable-debug. If not, it adds -s to $CFLAGS/$CXXFLAGS. This of course results in stripping when g++ links kadu binary. So I patched configure. -- Patryk Cisek pgpwmgiBifO6f.pgp Description: PGP signature
Re: RFS: Kadu
Dnia czwartek, 3 maja 2007, Piotr Ożarowski napisał:
s,kadu.net,kadu.net
or:
s,kadu.net,kadu.net/
(remove quotation mark)
Copy - Paste syndrome. ;)
Done.
Few more comments I missed last time:
* kadu.desktop file: Comment[pl]=Klient protocołu Gadu-Gadu
^
should be protokołu, IMHO ;-)
Definitely. :) Fixed.
* kadu-themes package: Recommends: kadu (= ${Source-Version})
how about: Recommends: kadu or: Recommends: kadu (= 0.5.0-1)
It's now Recommends: kadu
* /usr/share/kadu/themes/icons/kadu.xpm - why not install it into
/usr/share/pixmaps/ ?
Yeah, Good idea, since this directory holds other applications icons.
* please add info about your packaging copyrights to debian/copyright,
something like:
| The Debian packaging is (C) 200X-2007, Patryk Cisek [EMAIL PROTECTED]
| and is licensed under the GPL.
Done.
I'm project's packages maintainer a year now, but this package has been
rewritten, also debian/changelog and README.Debian indicate, that this
package has been debianized on May 2., so I decided to put (C) for only 2007.
please put a link to .dsc file next time (yeah, I'm lazy and I use dget
to download sources ;-)
Sure thing. :)
http://kadu.net/~patryk/debian/kadu_0.5.0-1.dsc
--
Patryk Cisek
pgp92xGTU1r9x.pgp
Description: PGP signature
Re: RFS: Kadu
Dnia środa, 2 maja 2007, Piotr Ożarowski napisał:
* is there a reason why you don't use libgadu-dev package and
--with-existing-libgadu option? libgadu3 package has a newer version
of libgadu than the one shipped with kadu
Not really, actually I've always linked staticly against libgadu shipped with
Kadu, since it's default. However it's a good idea to link libgadu from
Debian package, besides it also resolves the problem of libgadu.h and
libgadu.a in kadu-dev.
So I've added --with-existing-libgadu
* clean_remaining_cruft.sh, line 14: rm -rf /dev/null ?
Well, it should be 2 /dev/null, but anyway since I use tarball.mk for some
time now, this script is not needed anymore. I've removed it.
* clean rule does not work (reverse patch failure)
Yeah, it took me several hours today to investigate this issue. It looks like
#387103 still occurs (it was opposed to be fixed in version 0.4.48 of cdbs).
Hal, gnome-volume-manager and postgresql-8.1 don't use tarball.km anymore,
but alsojack-audio-connection-kit (from #400290) still is. I've checked if
the problem still occurs (in jack). Well, it does, so I guess it's a good
idea to reopen #400290/#387103. Anyway it looks like a problem in cdbs.
* checkbashisms didn't find any errors in *.sh files, why not use
sh instead of bash in debian/rules?
I was sure that tricks like ${string1%%string2} are bash specific. However
I've also tested the scripts with /bin/dash and it works fine. So I've
changed bash do sh. :)
* please replace See project's home page at:\n http://kadu.net; with
Homepage: http://kadu.net; in long description (notice 2 leading
spaces)
Done.
* why there's an empty line in changelog after line 10?
That's a very good question... ;) Well, I must have added this line by
mistake.
Removed.
* add Section: libdevel to kadu-dev
Done.
* why kadu-dev depends on kadu?
Yeah, it shouldn't depend on Kadu. I've changed it to Recommends.
* is there a reason to keep uncompressed about-changes-tab.txt and
changelog.gz file? Why did you forbid compressing other docs?
Well, constructor of About class (which represents About... dialog) reads
directly from AUTHORS, THANKS, LICENSE and about-changes-tab.txt files.
Contents of these are put in About... dialogs tabs. So we need these files
uncompressed. Since it's not obvious, I've also added this explanation to
debian/changelog -- ftp-masters might also want to ask this question. :)
Package is in the same place as before:
http://kadu.net/~patryk/debian/
--
Patryk Cisek
pgpyRnx3jvfRr.pgp
Description: PGP signature
RFS: Kadu
Hi, I'm looking for a sponsor Kadu. It's a very popular graphical client of Gadu-Gadu instant messenger protocol (one of the most popular IM protocol in Poland). Kadu's been developed for several years now, and I'm responsible for creating binary packages for Debian and Ubuntu. However I think it would be great to have Kadu in Debian and Ubuntu. You can download the source package from http://kadu.net/~patryk/debian * Package name: Kadu * Description: Client for Gadu-Gadu instant messenger protocol (very popular in Poland) * Version: 0.5.0 * Home page: http://kadu.net * Source package: http://kadu.net/~patryk/debian * License: Gnu/GPL -- Patryk Cisek pgpkZ6WPvlsgD.pgp Description: PGP signature
RFS: doorman -- Port knocking daemon for SSH and other servers.
Name: doorman Version: 0.81 ITP number: 305584 Section: admin License: GPL-2 Doorman allows a server which is not intended for general public access to run with most (or even all) of it's TCP ports closed to the outside world. It admits only recognized parties, that properly introduce themselves by knocking to a specific closed port on the server. The door-knocker, knock, can be run under Unix, GNU/Linux, or Microsoft Windows. This particular implementation deviates a bit from his original proposal (described by Martin Krzywinski in Sysadmin magazine and linuxjournal.com), in that the doorman watches for only a single UDP packet. To get the doorman to open up, the packet must contain an MD5 hash which correctly hashes a shared secret, salted with a 32-bit random number, the identifying user or group-name, and the requested service port-number. Currently doorman can only protect TCP services. The project's home page is at: http://doorman.sourceforge.net/ You can get the source and i386 binary packages from: http://poczta.prezu.one.pl/doorman/ -- Regards, Patryk Cisek pgpj8mvBCOVZR.pgp Description: PGP signature
Re: RFS: xmms-musepack - input plugin for playing mpc music files.
On Tuesday 13 of September 2005 01:05, Ben Finney wrote: On 13-Sep-2005, Christoph Berg wrote: debian/copyright: [...] | License: | Copyright (c) The Regents of the University of California. | All rights reserved. I'm sure this is wrong :) Corrected. :) Apart from that, no source file includes a (C) statement. You might want to ask upstream to include that in the next release. I'll do that. A useful copyright statement has one of these forms: Copyright , , CopyrightHolderName Copyright © , , CopyrightHolderName The list of publication years is essential (since copyright is theoretically not held forever). In a copyright notice, the word Copyright, the abbreviation Copr., and the © copyright symbol are all interchangeable; but the sequence '(C)' is legally null, so use the proper symbol instead. I've used the template from: /usr/share/common-licenses/BSD or: http://www.opensource.org/licenses/bsd-license.php like meny other packages. -- Regards, Patryk Cisek pgpwHqIcbD2os.pgp Description: PGP signature
Re: RFS: I'm looking for a sponsor for xlogmaster (an orphaned kackage).
Anibal Monsalve Salazar agreed to sponsor the package. -- Regards. pgp0IkNARuqdw.pgp Description: PGP signature
Re: RFS: I'm looking for a sponsor for xlogmaster (an orphaned kackage).
Anibal Monsalve Salazar agreed to sponsor the package. Certainly if he decides the package is all right. :) -- Regards. pgpm5rGUpZSw4.pgp Description: PGP signature
Re: RFS: I'm looking for a sponsor for xlogmaster (an orphaned kackage).
What's the point of this? For example, why would one want the README to stick around after the package has been removed? (c.f. 10.7.3) Unless the README is actually a configuration file, it should be in /usr/share/doc, perhaps named as README.configuration if there's a different README already there. I've moved READMEs to /usr/share/doc/ and changed their names to: README.entries.etc and README.scripts.etc. The files are at: http://poczta.prezu.one.pl/xlogmaster -- Regards. pgp10fLiScdwB.pgp Description: PGP signature
Re: RFS: I'm looking for a sponsor for xlogmaster (an orphaned kackage).
* Why don't you want these files to be conffiles ? Because they're not a configuration files and I think they definitly shouldn't be listed in conffiles. If for example the READMEs change in the future, dpkg will ask the user if he/she wants the newer version of them, but that shouldn't be questionable. * If they really mustn't be, they maybe don't belong to /etc (a README might be more appropriate in /usr/share/doc) Yes, maybe they should be in /usr/share/doc, however it's good to have them in /etc. That's why I asked if it's a good idea. :) If it's not, I'll leave READMEs only in /usr/share/doc. -- Regards. pgpmriRbIhon9.pgp Description: PGP signature
Re: RFS: I'm looking for a sponsor for xlogmaster (an orphaned kackage).
I thought the user would only be prompted if the file changed *and* they had made local modifications to the old file. The last is fairly unlikely for READMEs. Yes that's true. I've included these READMEs to conffiles now. Changed package files are at: http://poczta.prezu.one.pl/xlogmaster/ -- Regards. pgp9VJpHkEXHQ.pgp Description: PGP signature
RFS: I'm looking for a sponsor for xlogmaster (an orphaned kackage).
Hello all. I've ITAd it (see #192676) and looking for a sponsor. I have fixed some warnings and bugs that lintian reported. The errors were: E: xlogmaster binary:E: xlogmaster binary: file-in-etc-not-marked-as-conffile /etc/xlogmaster/entries/README E: xlogmaster binary: file-in-etc-not-marked-as-conffile /etc/xlogmaster/scripts/README I've fixed them by moving their installation to postinst script. A'd like someone experienced to look at this and say if this is elegant enough. :) The source package (.dsc diff and .orig.tar.gz) and binary (.deb with .changes) are at: http://poczta.prezu.one.pl/xlogmaster/ -- Regards. -- Pozdrawiam. pgpvHzgkxk5A4.pgp Description: PGP signature
