RFS: gtklp-1.0pre1
Thanks, Andreas, for pointing out the copyright liability in gtklp-0.9, and for Tobias for fixing it up :) So, here's the brand-new gtklp-1.0pre1 signed changes file: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 29 Aug 2004 22:14:31 +0800 Source: gtklp Binary: gtklp Architecture: source i386 Version: 1.0pre1-1 Distribution: unstable Urgency: low Maintainer: Zak B. Elep <[EMAIL PROTECTED]> Changed-By: Zak B. Elep <[EMAIL PROTECTED]> Description: gtklp - Frontend for CUPS written in GTK2 Changes: gtklp (1.0pre1-1) unstable; urgency=low . * New upstream release * Finally got upstream to fix the copyright issues. Now the copyright file can be properly filed :). Modified debian/copyright to reflect this (Thanks Andreas! ;) * Removed debian/watch as it doesn't work (Need to resolve this in the near future, though :( learn uscan... Files: bfd9ed390ba409b25fa0591994022cbc 635 x11 optional gtklp_1.0pre1-1.dsc c5532acb7c0546df6648088ab87d2102 1021034 x11 optional gtklp_1.0pre1.orig.tar.gz 98308b083c48b30ed7465c715722291e 4602 x11 optional gtklp_1.0pre1-1.diff.gz 0f4310b15c380d834ea86b236b2b786a 145262 x11 optional gtklp_1.0pre1-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBMeXAV4ex/fpThR0RAih6AKCK5/Fc1GZA2WRig0CAawa00EkLGwCeLymQ zHCzS7r3KaKZcmTP4341gnk= =nJ5q -END PGP SIGNATURE- Now, the only immediate goal now is to fix debian/watch. Help is greatly appreciated. Again, thanks to all, and more power to Free Software! Cheers, Zakame -- |=-ZAK B. ELEP (Registered Linux User #327585)-=| || Web: http://zakame.spunge.org GPG ID: 0xFA53851D || || http://zakame.homelinux.orgICQ UIN: 33236644 || || Location: Daet, Camarines Norte Running Linux 2.6 || |=--1486 7957 454D E529 E4F1 F75E 5787 B1FD FA53 851D--=| Debian - When you've got better things to do than to fix a borken system pgpfMVqgv6VEK.pgp Description: PGP signature
Re: RFH: gradm2
On Sun, Aug 15, 2004 at 11:15:05PM +0200, Geert Stappers wrote: > On Sun, Aug 15, 2004 at 10:23:23PM +0200, Laszlo 'GCS' Boszormenyi wrote: > > Hi, > > > > I can not reach my sponsor for a while now, who is Martin F. Krafft. > > Can someone help me out instead, and look up gradm2 package for me? It > > was newly uploaded last month, and more than two weeks passed since > > then, but no sign if it is accepted or rejected. > > I rephrase that as "What is the status of NEW?" > I do have the same question. > FWIW there is the Debian Archive Kit[1] but I don't where to start. http://developer.skolelinux.no/~pere/debian-NEW.html My thank goes to fEnIo for posting that URL on this mailinglist. > > Cheers > Geert Stappers > > [1] http://cvs.debian.org/dak/?cvsroot=dak pgpSZF0ZGQsWy.pgp Description: PGP signature
Re: RFS: gtklp-1.0pre1
On 2004-08-29 "Zak B. Elep" <[EMAIL PROTECTED]> wrote: > gtklp (1.0pre1-1) unstable; urgency=low [...] I would not use this version number. You'd be forced to either use a epoch for the real 1.0 or "1.0rel" $ dpkg --compare-versions 0.9u-1 '<<' '1.0pre1-1' || echo not ok $ dpkg --compare-versions 1.0-1 '>>' '1.0pre1-1' || echo not ok not ok $ dpkg --compare-versions 1.0rel-1 '>>' '1.0pre1-1' || echo not ok I'd go for 0.9u+1.0pre1-1: $ dpkg --compare-versions 0.9u-1 '<<' '0.9u+1.0pre1-1' || echo not ok $ dpkg --compare-versions 1.0-1 '>>' '0.9u+1.0pre1-1'|| echo not ok Which will give you a clean start for 1.0, otherwise you'll have difficulties if upstream releases 1.0a after 1.0. cu andreas -- "See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in "Snow Crash"
Re: RFH lintian too hush
On Tue, Aug 17, 2004 at 12:09:10PM +0200, Geert Stappers wrote: > On Tue, Aug 17, 2004 at 03:35:14AM -0400, Randall Donald wrote: > > hi, > Hello ftpmaster, > (Hello ftpmasters, ;-) > Hello debian-mentors, > > > E: conglomerate: no-copyright-file > > W: conglomerate: non-standard-dir-perm usr/ 0775 != 0755 > > W: conglomerate: non-standard-dir-perm usr/bin/ 0775 != 0755 > > > > E: conglomerate; No changelog.Debian installed for package. > > > > > > W: conglomerate-common: non-standard-dir-perm usr/ 0775 != 0755 > > W: conglomerate-common: non-standard-dir-perm usr/share/ 0775 != 0755 > > W: conglomerate-common: non-standard-dir-perm usr/share/locale/ 0775 != 0755 > > W: conglomerate-common: non-standard-dir-perm usr/share/locale/az/ 0775 != > > 0755 > > W: conglomerate-common: non-standard-dir-perm > > usr/share/locale/az/LC_MESSAGES/ 0775 != 0755 > > etc etc etc etc > > > > Please fix these. > For the permission warnings on the directories, I have a clue how to fix it. Those permission warnings are fixed. > See below for the request for help. That is the reason for this "resend" > > The no copyright file and changelog are quite important. > > you can just use a symlink from /usr/share/doc/conglomerate -> > > /usr/share/doc/conglomerate-common. > > That symbolic link is meanwhile available in 0.7.14-3. > > > Randall Donald > > > > If you don't understand why your files were rejected, or if the > > override file requires editing, reply to this email. > > I'm surprised that your lintian procedures more information then mine. > According to packages.qa.debian.org is the most recent version 1.23.2, > I use that version also. The linda program does report also > the missing manpage, but not the permissions on directories warning. > > Which tool do I have to use to make these warnings visible? According the manual page of lintian is there a check for "huge /usr/share". Conglomerate 0.7.14-1[1] is about 1.4 Mb with a 1.2Mb /usr/share, but lintian didn't complain about that huge /usr/share. IMNSHO it makes sense to at least warn about a u.s. of more one megabyte. Did I use lintian incorret or is it triggered at a larger /usr/share ? (then please tell me at which size ) > > > Cheers > Geert Stappers Bye pgpZEnPFzXufS.pgp Description: PGP signature
Re: RFH lintian too hush
On Sun, Aug 29, 2004 at 05:10:21PM +0200, Geert Stappers wrote: > On Tue, Aug 17, 2004 at 12:09:10PM +0200, Geert Stappers wrote: > > I'm surprised that your lintian procedures more information then mine. > > According to packages.qa.debian.org is the most recent version 1.23.2, > > I use that version also. The linda program does report also > > the missing manpage, but not the permissions on directories warning. > > > > Which tool do I have to use to make these warnings visible? lintian > According the manual page of lintian is there a check for "huge /usr/share". > Conglomerate 0.7.14-1[1] is about 1.4 Mb with a 1.2Mb /usr/share, > but lintian didn't complain about that huge /usr/share. > IMNSHO it makes sense to at least warn about a u.s. of more one megabyte. > > Did I use lintian incorret > or is it triggered at a larger /usr/share ? > (then please tell me at which size ) Please tell use HOW you use lintian if you want to know IF you used it incorrect, I cannot magically see how you use lintian. Regarding this check, see /usr/share/lintian/checks/huge-usr-share, and note that due to its new, experimental nature, it is only displayed when you enable informative checks, by means of lintian -I. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl pgp7xbD5fFAug.pgp Description: PGP signature
Looking for a sponsor: Limewire 4.0.6
Hello, I have already built limewire 4.0.6 from the previous verision's makefile and would like to maintain. I am looking for a sponsor as I am new to development. Thanks, James
Re: RFH Re: conglomerate_0.7.14-2_powerpc.changes REJECTED
On Tuesday 17 August 2004 04:09, Geert Stappers wrote:
> I'm surprised that your lintian procedures more information then
> mine. According to packages.qa.debian.org is the most recent version
> 1.23.2, I use that version also. The linda program does report also
> the missing manpage, but not the permissions on directories warning.
>
> Which tool do I have to use to make these warnings visible?
I don't know if this is related to what happened in this case, but often
running lintian against the binary package (*.deb) will give different
results than running lintian against the source package (*.dsc) and
changes file (*.changes).
I generally use
$ lintian *.{deb,dsc,changes}
for normal checking, or
$ lintian -Iv *.{deb,dsc,changes}
if I want it to be more verbose. =)
--
Wesley J. Landaker <[EMAIL PROTECTED]>
OpenPGP FP: 4135 2A3B 4726 ACC5 9094 0097 F0A9 8A4C 4CD6 E3D2
pgpLmkWi5opLR.pgp
Description: PGP signature
Re: Looking for a sponsor: Limewire 4.0.6
On Sun, 2004-08-29 at 13:29, james wrote: > Hello, > I have already built limewire 4.0.6 from the previous verision's > makefile and would like to maintain. I am looking for a sponsor as I am > new to development. It generally helps to link to the packages you've created so that potential sponsors can take a look. -- Chris Anderson <[EMAIL PROTECTED]> ICQ: 72021847 Jabber: [EMAIL PROTECTED] 20B2 CB34 8AA5 05BC A90C 2CDD 2768 D4B4 2B93 424B signature.asc Description: This is a digitally signed message part
Re: RFH Re: conglomerate_0.7.14-2_powerpc.changes REJECTED
On Sun, Aug 29, 2004 at 11:44:57AM -0600, Wesley J Landaker wrote:
> On Tuesday 17 August 2004 04:09, Geert Stappers wrote:
>
> > I'm surprised that your lintian procedures more information then
> > mine. According to packages.qa.debian.org is the most recent version
> > 1.23.2, I use that version also. The linda program does report also
> > the missing manpage, but not the permissions on directories warning.
> >
> > Which tool do I have to use to make these warnings visible?
>
> I don't know if this is related to what happened in this case, but often
> running lintian against the binary package (*.deb) will give different
> results than running lintian against the source package (*.dsc) and
> changes file (*.changes).
>
> I generally use
>
> $ lintian *.{deb,dsc,changes}
Lintian has three type of checks: source checks (dsc), binary checks
(deb) and udeb checks (udeb). While some checks share code, and some
problems are reported in both, most problems can only be detected in
either the binary, or the source.
Running lintian on a .changes file will simply run in on those files
named in it, it isn't needed to also seperately list the .deb and .dsc's
if they are already also in the .changes.
> for normal checking, or
>
> $ lintian -Iv *.{deb,dsc,changes}
>
> if I want it to be more verbose. =)
-v isn't very useful imho usually, but the two option you should
consider are indeed -I, for some checks we didn't dare to enable by
default, and -i, which will give you an explanation for each problem
detected, possible with a hint how to fix it.
--Jeroen
--
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl
Re: RFH Re: conglomerate_0.7.14-2_powerpc.changes REJECTED
On Sunday 29 August 2004 11:50, Jeroen van Wolffelaar wrote:
> On Sun, Aug 29, 2004 at 11:44:57AM -0600, Wesley J Landaker wrote:
> > I generally use
> >
> > $ lintian *.{deb,dsc,changes}
> Running lintian on a .changes file will simply run in on those files
> named in it, it isn't needed to also seperately list the .deb and
> .dsc's if they are already also in the .changes.
You're right; thanks for the clairification. In that case, it might make
sense to change my habit to "lintian *.changes" and save a few
keystrokes. =)
--
Wesley J. Landaker <[EMAIL PROTECTED]>
OpenPGP FP: 4135 2A3B 4726 ACC5 9094 0097 F0A9 8A4C 4CD6 E3D2
pgpafEmnpHdEh.pgp
Description: PGP signature
Re: RFH Re: conglomerate_0.7.14-2_powerpc.changes REJECTED
On Sun, Aug 29, 2004 at 12:08:54PM -0600, Wesley J Landaker wrote:
> On Sunday 29 August 2004 11:50, Jeroen van Wolffelaar wrote:
> > On Sun, Aug 29, 2004 at 11:44:57AM -0600, Wesley J Landaker wrote:
> > > I generally use
> > >
> > > $ lintian *.{deb,dsc,changes}
>
> > Running lintian on a .changes file will simply run in on those files
> > named in it, it isn't needed to also seperately list the .deb and
> > .dsc's if they are already also in the .changes.
>
> You're right; thanks for the clairification. In that case, it might make
> sense to change my habit to "lintian *.changes" and save a few
> keystrokes. =)
Which is exactly what debuild by default does for you. In addition, it
will also add the proper fakeroot magic to dpkg-buildpackage, and, eh,
it's shorter to type than dpkg-buildpackage, so I prefer this one-in-all
script for building my stuff :)
(Package devscripts, in case you're wondering)
--Jeroen
--
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl
Re: RFH Re: conglomerate_0.7.14-2_powerpc.changes REJECTED
On Sunday 29 August 2004 12:11, Jeroen van Wolffelaar wrote: > > You're right; thanks for the clairification. In that case, it might > > make sense to change my habit to "lintian *.changes" and save a few > > keystrokes. =) > > Which is exactly what debuild by default does for you. In addition, > it will also add the proper fakeroot magic to dpkg-buildpackage, and, > eh, it's shorter to type than dpkg-buildpackage, so I prefer this > one-in-all script for building my stuff :) Actually, I like debuild, but since I use subversion to manage all of my packages, I generally just use svn-buildpackage, which does some of what debuild does... In fact, now that you got me thinking about it, I just checked the man page and realized I can add a "builder=debuild" and/or "svn-lintian" in my ~/.svn-buildpackage.conf, and have either have debuild used instead of dpkg-buildpackage, or have the lintian checks run automatically without giving a bunch of long flags on the command line... Well, that's handy! Thanks for getting me thinking this morning. ;) -- Wesley J. Landaker <[EMAIL PROTECTED]> OpenPGP FP: 4135 2A3B 4726 ACC5 9094 0097 F0A9 8A4C 4CD6 E3D2 pgpzS9Ztt0VFR.pgp Description: PGP signature
Re: RFS: kst: A KDE data analysis program
On Fri, 27, Aug, 2004 at 06:49:47AM -0600, Wesley J Landaker spoke thus.. > Sounds good; posts the links to your packages when you feel that they're > ready and I'll take a look at them. Unfortunately, like a quantum > particle, I'll be popping in and out of existance this week, but I > should have time to look over your package and sponsor the upload if > there are no problems in the next day or two. =) Hi, I think the package is ready for upload now. I've made a few changes since the last version you saw. Unfortunately, I can't upload to mentors.debian.net again because I want to start in debian proper with 0.99-1 and, stupidly, I didn't use 0.99-0 for the initial mentors upload; I'll know better in future. Also, our local server at work has died (and I haven't had a chance to look at it yet as it's the weekend) so I've uploaded the source package to my University webspace. It can be found at: http://www.students.ncl.ac.uk/mark.hymers/kst/ (kst_0.99-1.diff.gz, kst_0.99-1.dsc and kst_0.99.orig.tar.gz). Both the source packages and the .deb packages which build from this are lintian -Ii clean and work well. Rough changes from the last test version: * Added some examples which I generated and a brief doc on how to use them * Renamed the libkst package to 0 instead of 1 (as binary compatibility is likely to change in version 1.0). * Fixed a really obscure lintian warning (only appears with -I) to do with hyphens and minus signs in manpages * Fixed the installation of the KDE KST documentation so that it appears in khelpcenter and works properly (part of kst-doc) Hope that give you enough information. If you have any more questions, please let me know. Cheers, Mark -- Mark Hymers, University of Newcastle Medical School Intercalating Medical Student (MBBS / PhD)
Re: RFH lintian too hush
On Sun, Aug 29, 2004 at 07:26:35PM +0200, Jeroen van Wolffelaar wrote: > On Sun, Aug 29, 2004 at 05:10:21PM +0200, Geert Stappers wrote: > > According the manual page of lintian is there a check for "huge /usr/share". > > Conglomerate 0.7.14-1[1] is about 1.4 Mb with a 1.2Mb /usr/share, > > but lintian didn't complain about that huge /usr/share. > > IMNSHO it makes sense to at least warn about a u.s. of more one megabyte. > > > > Did I use lintian incorrect Oops, indeed I didn't tell that I didn't provide any optional flags. > > or is it triggered at a larger /usr/share ? > > (then please tell me at which size ) > > Please tell use HOW you use lintian if you want to know IF you used it > incorrect, I cannot magically see how you use lintian. ( wget http://www.stappers.nl/gst/pool/main/c/conglomerate/conglomerate_0.7.14-1_powerpc.deb ) lintian conglomerate_0.7.14-1_powerpc.deb So no extra flags. That is based on lintian manual page. -c, --check Run all checks over the specified packages. This is the default action. The idea is the use the default action to get _all_ checks. But I was looking for the hugh /usr/share so I tried lintian -C hus conglomerate_0.7.14-1_powerpc.deb Two snippets from the lintian manual page -C chk1,chk2,..., --check-part chk1,chk2,... Run only the specified checks. You can either specify the name of the check script or the abbreviation. For details, see the CHECKS section below. huge-usr-share (hus) Checks whether an architecture-dependent package does have a significantly big /usr/share. Big amounts of architecture inde- pendent data in architecture dependent packages waste space on the mirrors. But still no sign of the hugh /usr/share > Regarding this check, see /usr/share/lintian/checks/huge-usr-share, and > note that due to its new, experimental nature, it is only displayed when > you enable informative checks, by means of lintian -I. Hey a -I flag, lets try it: $ lintian -I conglomerate_0.7.14-1_powerpc.deb I: conglomerate: arch-dep-package-has-big-usr-share 4448kB 86% Okay, I found what I was looking for What is a constructive way to solve our different expections of _all_ checks and "forceing hus check" versus the -I flag? (next is dutch, native language for me and probably also for Jeroen Wat is een opbouwende manier om ons verschil in verwachtingen bij _alle_ test en de "geforceerde hus test" tegenover de -I optie op te lossen?) > --Jeroen Cheers Geert Stappers
Re: RFH lintian too hush
Diverting to lintain-maint, where this is more appropriate... On Sun, Aug 29, 2004 at 10:26:13PM +0200, Geert Stappers wrote: > On Sun, Aug 29, 2004 at 07:26:35PM +0200, Jeroen van Wolffelaar wrote: > > On Sun, Aug 29, 2004 at 05:10:21PM +0200, Geert Stappers wrote: > > > > According the manual page of lintian is there a check for "huge > > > /usr/share". > > > Conglomerate 0.7.14-1[1] is about 1.4 Mb with a 1.2Mb /usr/share, > > > but lintian didn't complain about that huge /usr/share. > > > IMNSHO it makes sense to at least warn about a u.s. of more one megabyte. > > > > > > Did I use lintian incorrect > Oops, indeed I didn't tell that I didn't provide any optional flags. > > > > or is it triggered at a larger /usr/share ? > > > (then please tell me at which size ) > > > > Please tell use HOW you use lintian if you want to know IF you used it > > incorrect, I cannot magically see how you use lintian. > > ( wget > http://www.stappers.nl/gst/pool/main/c/conglomerate/conglomerate_0.7.14-1_powerpc.deb > ) > > lintian conglomerate_0.7.14-1_powerpc.deb > > So no extra flags. That is based on lintian manual page. > >-c, --check > Run all checks over the specified packages. This is the default > action. > > The idea is the use the default action to get _all_ checks. It hides the ones that are more likely to be incorrect and annoying than to actually be useful... > But I was looking for the hugh /usr/share so I tried > > lintian -C hus conglomerate_0.7.14-1_powerpc.deb (...) > But still no sign of the hugh /usr/share -C will limit the number of tests done, rather than doing all. Note that in both of the above cases, the test is performed, but just hidden for you. > > Regarding this check, see /usr/share/lintian/checks/huge-usr-share, and > > note that due to its new, experimental nature, it is only displayed when > > you enable informative checks, by means of lintian -I. > > Hey a -I flag, lets try it: > > $ lintian -I conglomerate_0.7.14-1_powerpc.deb > I: conglomerate: arch-dep-package-has-big-usr-share 4448kB 86% > > > Okay, I found what I was looking for > What is a constructive way to solve our different expections > of _all_ checks and "forceing hus check" versus the -I flag? Dunno, -C et al are IMHO to be discouraged, are only for very rare, specialized uses. I'm actually in favour of dropping them from the --help, and in manpage, maybe even move all that advanced stuff to a different manpage/chapter. Regular maintainers shouldn't ever need that option, it's only needed if you're doing some QA stuff or mass-checking, and then you need to read the code anyway... > (next is dutch, native language for me and probably also for Jeroen > Wat is een opbouwende manier om ons verschil in verwachtingen > bij _alle_ test en de "geforceerde hus test" tegenover > de -I optie op te lossen?) I understood the English part fine :), indeed, Dutch is my native language, as you have guessed from my .nl email. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: RFS: kst: A KDE data analysis program
On Sunday 29 August 2004 14:37, Mark Hymers wrote: > I think the package is ready for upload now. I've made a few changes > since the last version you saw. > Also, our local server at work has died (and I haven't had a chance > to look at it yet as it's the weekend) so I've uploaded the source > package to my University webspace. It can be found at: > > http://www.students.ncl.ac.uk/mark.hymers/kst/ > > (kst_0.99-1.diff.gz, kst_0.99-1.dsc and kst_0.99.orig.tar.gz). > > Both the source packages and the .deb packages which build from this > are lintian -Ii clean and work well. I'll will look these over this afternoon. If there are any concerns, I'll e-mail you privately and we can work out the details to get it finished off and uploaded. =) -- Wesley J. Landaker <[EMAIL PROTECTED]> OpenPGP FP: 4135 2A3B 4726 ACC5 9094 0097 F0A9 8A4C 4CD6 E3D2 pgpqusjpqRZcG.pgp Description: PGP signature
Looking for a sponsor: unace-nonfree 2.20
Hello, I'm looking for a sponsor for the unrar-nonfree. The Debian packages can you find on http://www.proesdorf.de/uploads/unace-nonfree/. Some infos about this package. There is a free version of unace in Debian but this version 1.2b don't support newer ACE archives (the same like unrar and unrar-nonfree). The upstream company only supports the decompressing of newer archives with a static linked binary. So I've build a Debian packages from this binary. By, Dirk signature.asc Description: Digital signature
Re: Looking for a sponsor: unace-nonfree 2.20
On Sun, 2004-08-29 at 20:20, Dirk Prösdorf wrote: > Hello, > > I'm looking for a sponsor for the unrar-nonfree. s/unrar/unace/ > The Debian packages can > you find on http://www.proesdorf.de/uploads/unace-nonfree/. > > Some infos about this package. There is a free version of unace in > Debian but this version 1.2b don't support newer ACE archives (the same > like unrar and unrar-nonfree). The upstream company only supports the > decompressing of newer archives with a static linked binary. So I've > build a Debian packages from this binary. I find it peculiar that your .orig.tar.gz doesn't contain anything but the two files, but I checked upstream and they indeed only distributed those two. Odd of them not to place at least a license document with it. -- Chris Anderson <[EMAIL PROTECTED]> ICQ: 72021847 Jabber: [EMAIL PROTECTED] 20B2 CB34 8AA5 05BC A90C 2CDD 2768 D4B4 2B93 424B signature.asc Description: This is a digitally signed message part
RFS: gtklp-1.0pre1
Thanks, Andreas, for pointing out the copyright liability in gtklp-0.9, and for Tobias for fixing it up :) So, here's the brand-new gtklp-1.0pre1 signed changes file: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 29 Aug 2004 22:14:31 +0800 Source: gtklp Binary: gtklp Architecture: source i386 Version: 1.0pre1-1 Distribution: unstable Urgency: low Maintainer: Zak B. Elep <[EMAIL PROTECTED]> Changed-By: Zak B. Elep <[EMAIL PROTECTED]> Description: gtklp - Frontend for CUPS written in GTK2 Changes: gtklp (1.0pre1-1) unstable; urgency=low . * New upstream release * Finally got upstream to fix the copyright issues. Now the copyright file can be properly filed :). Modified debian/copyright to reflect this (Thanks Andreas! ;) * Removed debian/watch as it doesn't work (Need to resolve this in the near future, though :( learn uscan... Files: bfd9ed390ba409b25fa0591994022cbc 635 x11 optional gtklp_1.0pre1-1.dsc c5532acb7c0546df6648088ab87d2102 1021034 x11 optional gtklp_1.0pre1.orig.tar.gz 98308b083c48b30ed7465c715722291e 4602 x11 optional gtklp_1.0pre1-1.diff.gz 0f4310b15c380d834ea86b236b2b786a 145262 x11 optional gtklp_1.0pre1-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBMeXAV4ex/fpThR0RAih6AKCK5/Fc1GZA2WRig0CAawa00EkLGwCeLymQ zHCzS7r3KaKZcmTP4341gnk= =nJ5q -END PGP SIGNATURE- Now, the only immediate goal now is to fix debian/watch. Help is greatly appreciated. Again, thanks to all, and more power to Free Software! Cheers, Zakame -- |=-ZAK B. ELEP (Registered Linux User #327585)-=| || Web: http://zakame.spunge.org GPG ID: 0xFA53851D || || http://zakame.homelinux.orgICQ UIN: 33236644 || || Location: Daet, Camarines Norte Running Linux 2.6 || |=--1486 7957 454D E529 E4F1 F75E 5787 B1FD FA53 851D--=| Debian - When you've got better things to do than to fix a borken system pgpO6SudlzAkk.pgp Description: PGP signature
Re: RFH: gradm2
On Sun, Aug 15, 2004 at 11:15:05PM +0200, Geert Stappers wrote: > On Sun, Aug 15, 2004 at 10:23:23PM +0200, Laszlo 'GCS' Boszormenyi wrote: > > Hi, > > > > I can not reach my sponsor for a while now, who is Martin F. Krafft. > > Can someone help me out instead, and look up gradm2 package for me? It > > was newly uploaded last month, and more than two weeks passed since > > then, but no sign if it is accepted or rejected. > > I rephrase that as "What is the status of NEW?" > I do have the same question. > FWIW there is the Debian Archive Kit[1] but I don't where to start. http://developer.skolelinux.no/~pere/debian-NEW.html My thank goes to fEnIo for posting that URL on this mailinglist. > > Cheers > Geert Stappers > > [1] http://cvs.debian.org/dak/?cvsroot=dak pgposvlvRubRK.pgp Description: PGP signature
Re: RFH lintian too hush
On Tue, Aug 17, 2004 at 12:09:10PM +0200, Geert Stappers wrote: > On Tue, Aug 17, 2004 at 03:35:14AM -0400, Randall Donald wrote: > > hi, > Hello ftpmaster, > (Hello ftpmasters, ;-) > Hello debian-mentors, > > > E: conglomerate: no-copyright-file > > W: conglomerate: non-standard-dir-perm usr/ 0775 != 0755 > > W: conglomerate: non-standard-dir-perm usr/bin/ 0775 != 0755 > > > > E: conglomerate; No changelog.Debian installed for package. > > > > > > W: conglomerate-common: non-standard-dir-perm usr/ 0775 != 0755 > > W: conglomerate-common: non-standard-dir-perm usr/share/ 0775 != 0755 > > W: conglomerate-common: non-standard-dir-perm usr/share/locale/ 0775 != 0755 > > W: conglomerate-common: non-standard-dir-perm usr/share/locale/az/ 0775 != 0755 > > W: conglomerate-common: non-standard-dir-perm usr/share/locale/az/LC_MESSAGES/ > > 0775 != 0755 > > etc etc etc etc > > > > Please fix these. > For the permission warnings on the directories, I have a clue how to fix it. Those permission warnings are fixed. > See below for the request for help. That is the reason for this "resend" > > The no copyright file and changelog are quite important. > > you can just use a symlink from /usr/share/doc/conglomerate -> > > /usr/share/doc/conglomerate-common. > > That symbolic link is meanwhile available in 0.7.14-3. > > > Randall Donald > > > > If you don't understand why your files were rejected, or if the > > override file requires editing, reply to this email. > > I'm surprised that your lintian procedures more information then mine. > According to packages.qa.debian.org is the most recent version 1.23.2, > I use that version also. The linda program does report also > the missing manpage, but not the permissions on directories warning. > > Which tool do I have to use to make these warnings visible? According the manual page of lintian is there a check for "huge /usr/share". Conglomerate 0.7.14-1[1] is about 1.4 Mb with a 1.2Mb /usr/share, but lintian didn't complain about that huge /usr/share. IMNSHO it makes sense to at least warn about a u.s. of more one megabyte. Did I use lintian incorret or is it triggered at a larger /usr/share ? (then please tell me at which size ) > > > Cheers > Geert Stappers Bye pgp6rcJqtxlpY.pgp Description: PGP signature
Re: RFH lintian too hush
On Sun, Aug 29, 2004 at 05:10:21PM +0200, Geert Stappers wrote: > On Tue, Aug 17, 2004 at 12:09:10PM +0200, Geert Stappers wrote: > > I'm surprised that your lintian procedures more information then mine. > > According to packages.qa.debian.org is the most recent version 1.23.2, > > I use that version also. The linda program does report also > > the missing manpage, but not the permissions on directories warning. > > > > Which tool do I have to use to make these warnings visible? lintian > According the manual page of lintian is there a check for "huge /usr/share". > Conglomerate 0.7.14-1[1] is about 1.4 Mb with a 1.2Mb /usr/share, > but lintian didn't complain about that huge /usr/share. > IMNSHO it makes sense to at least warn about a u.s. of more one megabyte. > > Did I use lintian incorret > or is it triggered at a larger /usr/share ? > (then please tell me at which size ) Please tell use HOW you use lintian if you want to know IF you used it incorrect, I cannot magically see how you use lintian. Regarding this check, see /usr/share/lintian/checks/huge-usr-share, and note that due to its new, experimental nature, it is only displayed when you enable informative checks, by means of lintian -I. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl pgpkOzyKeOO0m.pgp Description: PGP signature
Looking for a sponsor: Limewire 4.0.6
Hello, I have already built limewire 4.0.6 from the previous verision's makefile and would like to maintain. I am looking for a sponsor as I am new to development. Thanks, James -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFH Re: conglomerate_0.7.14-2_powerpc.changes REJECTED
On Tuesday 17 August 2004 04:09, Geert Stappers wrote:
> I'm surprised that your lintian procedures more information then
> mine. According to packages.qa.debian.org is the most recent version
> 1.23.2, I use that version also. The linda program does report also
> the missing manpage, but not the permissions on directories warning.
>
> Which tool do I have to use to make these warnings visible?
I don't know if this is related to what happened in this case, but often
running lintian against the binary package (*.deb) will give different
results than running lintian against the source package (*.dsc) and
changes file (*.changes).
I generally use
$ lintian *.{deb,dsc,changes}
for normal checking, or
$ lintian -Iv *.{deb,dsc,changes}
if I want it to be more verbose. =)
--
Wesley J. Landaker <[EMAIL PROTECTED]>
OpenPGP FP: 4135 2A3B 4726 ACC5 9094 0097 F0A9 8A4C 4CD6 E3D2
pgpPL0Xqz6PvG.pgp
Description: PGP signature
Re: Looking for a sponsor: Limewire 4.0.6
On Sun, 2004-08-29 at 13:29, james wrote: > Hello, > I have already built limewire 4.0.6 from the previous verision's > makefile and would like to maintain. I am looking for a sponsor as I am > new to development. It generally helps to link to the packages you've created so that potential sponsors can take a look. -- Chris Anderson <[EMAIL PROTECTED]> ICQ: 72021847 Jabber: [EMAIL PROTECTED] 20B2 CB34 8AA5 05BC A90C 2CDD 2768 D4B4 2B93 424B signature.asc Description: This is a digitally signed message part
Re: RFH Re: conglomerate_0.7.14-2_powerpc.changes REJECTED
On Sun, Aug 29, 2004 at 11:44:57AM -0600, Wesley J Landaker wrote:
> On Tuesday 17 August 2004 04:09, Geert Stappers wrote:
>
> > I'm surprised that your lintian procedures more information then
> > mine. According to packages.qa.debian.org is the most recent version
> > 1.23.2, I use that version also. The linda program does report also
> > the missing manpage, but not the permissions on directories warning.
> >
> > Which tool do I have to use to make these warnings visible?
>
> I don't know if this is related to what happened in this case, but often
> running lintian against the binary package (*.deb) will give different
> results than running lintian against the source package (*.dsc) and
> changes file (*.changes).
>
> I generally use
>
> $ lintian *.{deb,dsc,changes}
Lintian has three type of checks: source checks (dsc), binary checks
(deb) and udeb checks (udeb). While some checks share code, and some
problems are reported in both, most problems can only be detected in
either the binary, or the source.
Running lintian on a .changes file will simply run in on those files
named in it, it isn't needed to also seperately list the .deb and .dsc's
if they are already also in the .changes.
> for normal checking, or
>
> $ lintian -Iv *.{deb,dsc,changes}
>
> if I want it to be more verbose. =)
-v isn't very useful imho usually, but the two option you should
consider are indeed -I, for some checks we didn't dare to enable by
default, and -i, which will give you an explanation for each problem
detected, possible with a hint how to fix it.
--Jeroen
--
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl
Re: RFH Re: conglomerate_0.7.14-2_powerpc.changes REJECTED
On Sunday 29 August 2004 11:50, Jeroen van Wolffelaar wrote:
> On Sun, Aug 29, 2004 at 11:44:57AM -0600, Wesley J Landaker wrote:
> > I generally use
> >
> > $ lintian *.{deb,dsc,changes}
> Running lintian on a .changes file will simply run in on those files
> named in it, it isn't needed to also seperately list the .deb and
> .dsc's if they are already also in the .changes.
You're right; thanks for the clairification. In that case, it might make
sense to change my habit to "lintian *.changes" and save a few
keystrokes. =)
--
Wesley J. Landaker <[EMAIL PROTECTED]>
OpenPGP FP: 4135 2A3B 4726 ACC5 9094 0097 F0A9 8A4C 4CD6 E3D2
pgpwKQlQVAIRO.pgp
Description: PGP signature
Re: RFH Re: conglomerate_0.7.14-2_powerpc.changes REJECTED
On Sun, Aug 29, 2004 at 12:08:54PM -0600, Wesley J Landaker wrote:
> On Sunday 29 August 2004 11:50, Jeroen van Wolffelaar wrote:
> > On Sun, Aug 29, 2004 at 11:44:57AM -0600, Wesley J Landaker wrote:
> > > I generally use
> > >
> > > $ lintian *.{deb,dsc,changes}
>
> > Running lintian on a .changes file will simply run in on those files
> > named in it, it isn't needed to also seperately list the .deb and
> > .dsc's if they are already also in the .changes.
>
> You're right; thanks for the clairification. In that case, it might make
> sense to change my habit to "lintian *.changes" and save a few
> keystrokes. =)
Which is exactly what debuild by default does for you. In addition, it
will also add the proper fakeroot magic to dpkg-buildpackage, and, eh,
it's shorter to type than dpkg-buildpackage, so I prefer this one-in-all
script for building my stuff :)
(Package devscripts, in case you're wondering)
--Jeroen
--
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl
Re: RFH Re: conglomerate_0.7.14-2_powerpc.changes REJECTED
On Sunday 29 August 2004 12:11, Jeroen van Wolffelaar wrote: > > You're right; thanks for the clairification. In that case, it might > > make sense to change my habit to "lintian *.changes" and save a few > > keystrokes. =) > > Which is exactly what debuild by default does for you. In addition, > it will also add the proper fakeroot magic to dpkg-buildpackage, and, > eh, it's shorter to type than dpkg-buildpackage, so I prefer this > one-in-all script for building my stuff :) Actually, I like debuild, but since I use subversion to manage all of my packages, I generally just use svn-buildpackage, which does some of what debuild does... In fact, now that you got me thinking about it, I just checked the man page and realized I can add a "builder=debuild" and/or "svn-lintian" in my ~/.svn-buildpackage.conf, and have either have debuild used instead of dpkg-buildpackage, or have the lintian checks run automatically without giving a bunch of long flags on the command line... Well, that's handy! Thanks for getting me thinking this morning. ;) -- Wesley J. Landaker <[EMAIL PROTECTED]> OpenPGP FP: 4135 2A3B 4726 ACC5 9094 0097 F0A9 8A4C 4CD6 E3D2 pgpNoHyNMzRRY.pgp Description: PGP signature
Re: RFS: kst: A KDE data analysis program
On Fri, 27, Aug, 2004 at 06:49:47AM -0600, Wesley J Landaker spoke thus.. > Sounds good; posts the links to your packages when you feel that they're > ready and I'll take a look at them. Unfortunately, like a quantum > particle, I'll be popping in and out of existance this week, but I > should have time to look over your package and sponsor the upload if > there are no problems in the next day or two. =) Hi, I think the package is ready for upload now. I've made a few changes since the last version you saw. Unfortunately, I can't upload to mentors.debian.net again because I want to start in debian proper with 0.99-1 and, stupidly, I didn't use 0.99-0 for the initial mentors upload; I'll know better in future. Also, our local server at work has died (and I haven't had a chance to look at it yet as it's the weekend) so I've uploaded the source package to my University webspace. It can be found at: http://www.students.ncl.ac.uk/mark.hymers/kst/ (kst_0.99-1.diff.gz, kst_0.99-1.dsc and kst_0.99.orig.tar.gz). Both the source packages and the .deb packages which build from this are lintian -Ii clean and work well. Rough changes from the last test version: * Added some examples which I generated and a brief doc on how to use them * Renamed the libkst package to 0 instead of 1 (as binary compatibility is likely to change in version 1.0). * Fixed a really obscure lintian warning (only appears with -I) to do with hyphens and minus signs in manpages * Fixed the installation of the KDE KST documentation so that it appears in khelpcenter and works properly (part of kst-doc) Hope that give you enough information. If you have any more questions, please let me know. Cheers, Mark -- Mark Hymers, University of Newcastle Medical School Intercalating Medical Student (MBBS / PhD) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFH lintian too hush
On Sun, Aug 29, 2004 at 07:26:35PM +0200, Jeroen van Wolffelaar wrote: > On Sun, Aug 29, 2004 at 05:10:21PM +0200, Geert Stappers wrote: > > According the manual page of lintian is there a check for "huge /usr/share". > > Conglomerate 0.7.14-1[1] is about 1.4 Mb with a 1.2Mb /usr/share, > > but lintian didn't complain about that huge /usr/share. > > IMNSHO it makes sense to at least warn about a u.s. of more one megabyte. > > > > Did I use lintian incorrect Oops, indeed I didn't tell that I didn't provide any optional flags. > > or is it triggered at a larger /usr/share ? > > (then please tell me at which size ) > > Please tell use HOW you use lintian if you want to know IF you used it > incorrect, I cannot magically see how you use lintian. ( wget http://www.stappers.nl/gst/pool/main/c/conglomerate/conglomerate_0.7.14-1_powerpc.deb ) lintian conglomerate_0.7.14-1_powerpc.deb So no extra flags. That is based on lintian manual page. -c, --check Run all checks over the specified packages. This is the default action. The idea is the use the default action to get _all_ checks. But I was looking for the hugh /usr/share so I tried lintian -C hus conglomerate_0.7.14-1_powerpc.deb Two snippets from the lintian manual page -C chk1,chk2,..., --check-part chk1,chk2,... Run only the specified checks. You can either specify the name of the check script or the abbreviation. For details, see the CHECKS section below. huge-usr-share (hus) Checks whether an architecture-dependent package does have a significantly big /usr/share. Big amounts of architecture inde- pendent data in architecture dependent packages waste space on the mirrors. But still no sign of the hugh /usr/share > Regarding this check, see /usr/share/lintian/checks/huge-usr-share, and > note that due to its new, experimental nature, it is only displayed when > you enable informative checks, by means of lintian -I. Hey a -I flag, lets try it: $ lintian -I conglomerate_0.7.14-1_powerpc.deb I: conglomerate: arch-dep-package-has-big-usr-share 4448kB 86% Okay, I found what I was looking for What is a constructive way to solve our different expections of _all_ checks and "forceing hus check" versus the -I flag? (next is dutch, native language for me and probably also for Jeroen Wat is een opbouwende manier om ons verschil in verwachtingen bij _alle_ test en de "geforceerde hus test" tegenover de -I optie op te lossen?) > --Jeroen Cheers Geert Stappers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFH lintian too hush
Diverting to lintain-maint, where this is more appropriate... On Sun, Aug 29, 2004 at 10:26:13PM +0200, Geert Stappers wrote: > On Sun, Aug 29, 2004 at 07:26:35PM +0200, Jeroen van Wolffelaar wrote: > > On Sun, Aug 29, 2004 at 05:10:21PM +0200, Geert Stappers wrote: > > > > According the manual page of lintian is there a check for "huge /usr/share". > > > Conglomerate 0.7.14-1[1] is about 1.4 Mb with a 1.2Mb /usr/share, > > > but lintian didn't complain about that huge /usr/share. > > > IMNSHO it makes sense to at least warn about a u.s. of more one megabyte. > > > > > > Did I use lintian incorrect > Oops, indeed I didn't tell that I didn't provide any optional flags. > > > > or is it triggered at a larger /usr/share ? > > > (then please tell me at which size ) > > > > Please tell use HOW you use lintian if you want to know IF you used it > > incorrect, I cannot magically see how you use lintian. > > ( wget > http://www.stappers.nl/gst/pool/main/c/conglomerate/conglomerate_0.7.14-1_powerpc.deb > ) > > lintian conglomerate_0.7.14-1_powerpc.deb > > So no extra flags. That is based on lintian manual page. > >-c, --check > Run all checks over the specified packages. This is the default > action. > > The idea is the use the default action to get _all_ checks. It hides the ones that are more likely to be incorrect and annoying than to actually be useful... > But I was looking for the hugh /usr/share so I tried > > lintian -C hus conglomerate_0.7.14-1_powerpc.deb (...) > But still no sign of the hugh /usr/share -C will limit the number of tests done, rather than doing all. Note that in both of the above cases, the test is performed, but just hidden for you. > > Regarding this check, see /usr/share/lintian/checks/huge-usr-share, and > > note that due to its new, experimental nature, it is only displayed when > > you enable informative checks, by means of lintian -I. > > Hey a -I flag, lets try it: > > $ lintian -I conglomerate_0.7.14-1_powerpc.deb > I: conglomerate: arch-dep-package-has-big-usr-share 4448kB 86% > > > Okay, I found what I was looking for > What is a constructive way to solve our different expections > of _all_ checks and "forceing hus check" versus the -I flag? Dunno, -C et al are IMHO to be discouraged, are only for very rare, specialized uses. I'm actually in favour of dropping them from the --help, and in manpage, maybe even move all that advanced stuff to a different manpage/chapter. Regular maintainers shouldn't ever need that option, it's only needed if you're doing some QA stuff or mass-checking, and then you need to read the code anyway... > (next is dutch, native language for me and probably also for Jeroen > Wat is een opbouwende manier om ons verschil in verwachtingen > bij _alle_ test en de "geforceerde hus test" tegenover > de -I optie op te lossen?) I understood the English part fine :), indeed, Dutch is my native language, as you have guessed from my .nl email. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: kst: A KDE data analysis program
On Sunday 29 August 2004 14:37, Mark Hymers wrote: > I think the package is ready for upload now. I've made a few changes > since the last version you saw. > Also, our local server at work has died (and I haven't had a chance > to look at it yet as it's the weekend) so I've uploaded the source > package to my University webspace. It can be found at: > > http://www.students.ncl.ac.uk/mark.hymers/kst/ > > (kst_0.99-1.diff.gz, kst_0.99-1.dsc and kst_0.99.orig.tar.gz). > > Both the source packages and the .deb packages which build from this > are lintian -Ii clean and work well. I'll will look these over this afternoon. If there are any concerns, I'll e-mail you privately and we can work out the details to get it finished off and uploaded. =) -- Wesley J. Landaker <[EMAIL PROTECTED]> OpenPGP FP: 4135 2A3B 4726 ACC5 9094 0097 F0A9 8A4C 4CD6 E3D2 pgpqiq4A18aNt.pgp Description: PGP signature
Looking for a sponsor: unace-nonfree 2.20
Hello, I'm looking for a sponsor for the unrar-nonfree. The Debian packages can you find on http://www.proesdorf.de/uploads/unace-nonfree/. Some infos about this package. There is a free version of unace in Debian but this version 1.2b don't support newer ACE archives (the same like unrar and unrar-nonfree). The upstream company only supports the decompressing of newer archives with a static linked binary. So I've build a Debian packages from this binary. By, Dirk signature.asc Description: Digital signature
Re: Looking for a sponsor: unace-nonfree 2.20
On Sun, 2004-08-29 at 20:20, Dirk Prösdorf wrote: > Hello, > > I'm looking for a sponsor for the unrar-nonfree. s/unrar/unace/ > The Debian packages can > you find on http://www.proesdorf.de/uploads/unace-nonfree/. > > Some infos about this package. There is a free version of unace in > Debian but this version 1.2b don't support newer ACE archives (the same > like unrar and unrar-nonfree). The upstream company only supports the > decompressing of newer archives with a static linked binary. So I've > build a Debian packages from this binary. I find it peculiar that your .orig.tar.gz doesn't contain anything but the two files, but I checked upstream and they indeed only distributed those two. Odd of them not to place at least a license document with it. -- Chris Anderson <[EMAIL PROTECTED]> ICQ: 72021847 Jabber: [EMAIL PROTECTED] 20B2 CB34 8AA5 05BC A90C 2CDD 2768 D4B4 2B93 424B signature.asc Description: This is a digitally signed message part
