Bug#752027: marked as done (RFS: ocrodjvu/0.7.18-1 -- (Python-apps) tool to perform OCR on DjVu documents)
Your message dated Wed, 25 Jun 2014 23:17:34 -0700 with message-id and subject line Re: Bug#752027: RFS: ocrodjvu/0.7.18-1 -- (Python-apps) tool to perform OCR on DjVu documents has caused the Debian Bug report #752027, regarding RFS: ocrodjvu/0.7.18-1 -- (Python-apps) tool to perform OCR on DjVu documents to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 752027: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752027 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: normal Hi, I am seeking for an uploader for my new package of the useful Ocrodjvu. It appears to be Lintian clean. For that, please cf: http://anonscm.debian.org/viewvc/python-apps/packages/ocrodjvu/trunk/ svn://anonscm.debian.org/python-apps/packages/ocrodjvu/trunk/ Mentors upload: http://mentors.debian.net/package/ocrodjvu http://mentors.debian.net/debian/pool/main/o/ocrodjvu/ocrodjvu_0.7.18-1.dsc Buildlog: http://www.danielstender.com/buildlogs/ocrodjvu_0.7.18-1_amd64.build Thank you very much, Daniel Stender -- http://www.danielstender.com/blog/ PGP key: 2048R/E41BD2D0 C879 5E41 1ED7 EE80 0F2E 7D0C DBDD 4D96 E41B D2D0 --- End Message --- --- Begin Message --- On Wed, Jun 18, 2014 at 1:45 PM, Daniel Stender wrote: > Package: sponsorship-requests > Severity: normal > > Hi, > > I am seeking for an uploader for my new package of the useful Ocrodjvu. > It appears to be Lintian clean. > > For that, please cf: > http://anonscm.debian.org/viewvc/python-apps/packages/ocrodjvu/trunk/ > svn://anonscm.debian.org/python-apps/packages/ocrodjvu/trunk/ > > Mentors upload: > http://mentors.debian.net/package/ocrodjvu > http://mentors.debian.net/debian/pool/main/o/ocrodjvu/ocrodjvu_0.7.18-1.dsc > > Buildlog: > http://www.danielstender.com/buildlogs/ocrodjvu_0.7.18-1_amd64.build > Built, signed, and uploaded; thanks for your contribution to Debian! Regards, Vincent--- End Message ---
Bug#751534: RFS: crunch/3.6-1 [ITP] -- tool for creating wordlist
>That's better. But let's remove “at line 75”.
Removed.
>I found more misspellings:
>exponentail -> exponential
>swedish -> Swedish
>outout -> output
>supress -> suppress
>varible -> variable
>calcualated -> calculated
>gernerate -> generate
>explaination -> explanation
>recommneds -> recommends
>instad -> instead
>japanese -> Japanese
>Some of the above are also in debian/changelog.upstream.
Fixed errors in changelog.upstream.
Including crunch.1 file to patch fix_speeling. And fixed spelling errors.
Fixed spelling errors in crunch.c.
>I would write it in a similar way upstream did:
>Copyright: 2004 mima...@aciiid.ath.cx
I put now in copyright: Copyright: 2004 mima...@aciiid.ath.cx
>If it's really that important for end users to know (I don't think it is, but
>I'm not going to argue about it either), then more >obvious place this is
>information is the changelog file itself.
>Or alternatively, you could extract changelog from crunch.c comments,
>therefore making it “official”.
I extracted the changelog of crunc.c, now "official" rs.
In a future I will use only the changelog to indicate that it is not official.
>Minor nitpick about error handling in upstream code:
>status = rename(fpath, outputfilename); /* rename from START to user
> specified name */
>if (status != 0) {
> fprintf(stderr,"Error renaming file. Status1 = %d Code =
> %d\n",status,errno);
> fprintf(stderr,"The problem is = %s\n", strerror(errno));
> exit(EXIT_FAILURE);
>}
>rename() always returns either 0 or -1, so there's little point in printing
>the return code.
>errno value could change between after the first call to printf(). If you want
>to use the same errno in two library calls, you need to save it to a temporary
>variable.
>(There are more instances of similar code.)
>This is nothing serious of course, but you may want to forward it upstream.
Thanks, I'll forward to the upstream
>The program can use lzma(1), bzip2(1), and 7z(1), so the package should
>probaby have “xz-utils | lzma, bzip2, p7zip-full” in >Suggests.
Added.
Thanks for the help.
Regards,
--
Marcio Souza
pgpV8HOi2od9c.pgp
Description: PGP signature
Bug#752729: RFS: djvusmooth/0.2.14-2 -- (Python-apps) graphical editor for DjVu
Package: sponsorship-requests Severity: normal Hi people, I'm looking for an uploader for my new package of Djvusmooth. There are only minor changes and it appears to be Lintian clean. Mentors upload: http://mentors.debian.net/package/djvusmooth http://mentors.debian.net/debian/pool/main/d/djvusmooth/djvusmooth_0.2.14-2.dsc Svn: http://anonscm.debian.org/viewvc/python-apps/packages/djvusmooth/trunk/ svn://anonscm.debian.org/python-apps/packages/djvusmooth/trunk/ Build log: http://www.danielstender.com/buildlogs/djvusmooth_0.2.14-2_amd64.build Thank you very much, Daniel Stender -- http://www.danielstender.com/blog/ PGP key: 2048R/E41BD2D0 C879 5E41 1ED7 EE80 0F2E 7D0C DBDD 4D96 E41B D2D0 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53ab4f37.4080...@danielstender.com
Bug#752690: RFS: ledgersmb/1.3.40-1 [RC] -- financial accounting and ERP program
severity -1 important submitter -1 Robert James Clay tags 749347 + pending block 749347 by 752690 thanks Sorry; accidentally sent a draft instead of the final... On 06/25/2014 11:48 AM, RJ Clay wrote: Package: sponsorship-requests Severity: normal [important for RC bugs, wishlist for new packages] Severity: important * Package name: ledgersmb Version : 1.3.40-1 Upstream Author : [fill in name and email of upstream] * URL : [fill in URL of upstreams web site] * License : [fill in] Upstream Contact : Chris Travers * URL : http://www.ledgersmb.org * License : GPL-2+ Regards, Robert James Clay
Bug#751534: RFS: crunch/3.6-1 [ITP] -- tool for creating wordlist
* Marcio de Souza Oliveira , 2014-06-20, 19:12:
I: Crunch: hyphen-used-as-minus-sign usr/share/man/man1/crunch.1.gz: 75
I changed the description to:
Description: Added backslash before the hyphen option -s at line 75
That's better. But let's remove “at line 75”. :-)
I changed the name of the patch to fix_spelling.
I found more misspellings:
exponentail -> exponential
swedish -> Swedish
outout -> output
supress -> suppress
varible -> variable
calcualated -> calculated
gernerate -> generate
explaination -> explanation
recommneds -> recommends
instad -> instead
japanese -> Japanese
Some of the above are also in debian/changelog.upstream.
Copyright: 2004 ?
What's up with this question mark?
Not possible identify the name of first author.
The email mima...@aciiid.ath.cx not exist.
Then as we could not identify it put that way.
I would write it in a similar way upstream did:
Copyright: 2004 mima...@aciiid.ath.cx
I put now GPL-2.0+ in debian/copyright
But that's not what upstream says. They say explicitly “version 2 only
of the License”.
Why is README.source shipped in the *binary* package?
So that the end user knows the changelog did not come from the upstream
source code, so I sent along the binary package.
If it's really that important for end users to know (I don't think it
is, but I'm not going to argue about it either), then more obvious place
this is information is the changelog file itself.
Or alternatively, you could extract changelog from crunch.c comments,
therefore making it “official”. :-)
Minor nitpick about error handling in upstream code:
status = rename(fpath, outputfilename); /* rename from START to user
specified name */
if (status != 0) {
fprintf(stderr,"Error renaming file. Status1 = %d Code =
%d\n",status,errno);
fprintf(stderr,"The problem is = %s\n", strerror(errno));
exit(EXIT_FAILURE);
}
rename() always returns either 0 or -1, so there's little point in
printing the return code.
errno value could change between after the first call to printf(). If
you want to use the same errno in two library calls, you need to save it
to a temporary variable.
(There are more instances of similar code.)
This is nothing serious of course, but you may want to forward it
upstream.
The program can use lzma(1), bzip2(1), and 7z(1), so the package should
probaby have “xz-utils | lzma, bzip2, p7zip-full” in Suggests.
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140625193552.ga6...@jwilk.net
Bug#752520: RFS: lilyterm/0.9.9.4-1 [ITP]
* Yavor Doganov , 2014-06-25, 19:02: Lintian issues a warning if the data in /usr/share is more than 4 MB or more than 2 MB *and* more than 50% of the package. It is not the case for your package so splitting it does more harm than good, IMO. Aye, lilyterm-data is only 76K. Even when multiplied by 12 architectures, that's still less than a megabyte. And now for something completely different: You must not remove the alternative in "prerm upgrade". See bug #71621 for gory details. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140625183408.ga4...@jwilk.net
Bug#747816: RFS: openalpr - libopenalpr1
-Ursprüngliche Nachricht- Gesendet:So 11.05.2014 21:34 Betreff:Bug#747816: RFS: openalpr - libopenalpr1 An:sub...@bugs.debian.org; > Dear mentors, > > I am looking for a sponsor for my new package "openalpr" Ping. Stefan
Bug#752520: RFS: lilyterm/0.9.9.4-1 [ITP]
ChangZhuo Chen (陳昌倬) wrote: > On Wed, Jun 25, 2014 at 03:20:46PM +0200, Jakub Wilk wrote: > > The third case (likely most common one) is when an arch:any > > package would otherwise contain huge /usr/share. Which doesn't > > seem to be the case here either. > > Actually this is the reason for lilyterm-data. You should take into account the archive clutter, that's also a perfectly valid concern. Lintian issues a warning if the data in /usr/share is more than 4 MB or more than 2 MB *and* more than 50% of the package. It is not the case for your package so splitting it does more harm than good, IMO. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87y4wlf04u.GNUs_not_UNIX!%ya...@gnu.org
Bug#752690: RFS: ledgersmb/1.3.40-1 [RC] -- financial accounting and ERP program
Package: sponsorship-requests Severity: normal [important for RC bugs, wishlist for new packages] Dear mentors, I am looking for a sponsor for my package "ledgersmb" * Package name: ledgersmb Version : 1.3.40-1 Upstream Author : [fill in name and email of upstream] * URL : [fill in URL of upstreams web site] * License : [fill in] Section : web It builds those binary packages: ledgersmb - financial accounting and ERP program To access further information about this package, please visit the following URL: http://mentors.debian.net/package/ledgersmb Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/l/ledgersmb/ledgersmb_1.3.40-1.dsc More information aboutPackage: sponsorship-requests Severity: normal [important for RC bugs, wishlist for new packages] Dear mentors, I am looking for a sponsor for my package "ledgersmb" * Package name : ledgersmb Version : 1.3.40-1 Upstream Contact : Chris Travers * URL : http://www.ledgersmb.org * License : GPL-2+ Section : web It builds those binary packages: ledgersmb - financial accounting and ERP program To access further information about this package, please visit the following URL: http://mentors.debian.net/package/ledgersmb Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/l/ledgersmb/ledgersmb_1.3.40-1.dsc More information about ledgersmb can be obtained from http://www.ledgersmb.org. Changes since the last upload: * New upstream release. - 'Duplicate entry' error fixed in the locale/po/es_AR.po file. * Rewrite the 'purge' stanza in the debian/ledgersmb.postrm script. * Correct package version for the mv_conffile stanzas in maintainer scripts. * Add debian/ledgersmb.doc-base.database to register database information. * Correct errors installing the httpd configuration files for Apache v2.2 and v2.4. (Closes: #749347) Regards, Robert James Clay
Bug#752520: RFS: lilyterm/0.9.9.4-1 [ITP]
On Wed, Jun 25, 2014 at 03:20:46PM +0200, Jakub Wilk wrote: > * Michael Tokarev , 2014-06-25, 16:27: > >> lilyterm - Light and eazy-to-use terminal emulator for X > > Typo: eazy -> easy Thank for the review, just uploading a new one. > The third case (likely most common one) is when an arch:any package would > otherwise contain huge /usr/share. Which doesn't seem to be the case here > either. Actually this is the reason for lilyterm-data. -- ChangZhuo Chen (陳昌倬) http://czchen.info/ Key fingerprint = EC9F 905D 866D BE46 A896 C827 BE0C 9242 03F4 552D signature.asc Description: Digital signature
Bug#752520: RFS: lilyterm/0.9.9.4-1 [ITP]
At Wed, 25 Jun 2014 16:27:51 +0400, Michael Tokarev wrote: > You may need extra -data in two cases -- when that -data comes from > a separate source, or when you have several different variations of > your term package (say, gtk2 and gtk3 versions) which all use a > common set of data files. Apparently neither of the two cases > applies here. There's also a third case -- when the arch-indep data is big enough to warrant a separate arch:all package. Apparently this doesn't apply here as well; the -data package contains only the translations and the icon. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87zjh1f7pk.GNUs_not_UNIX!%ya...@gnu.org
Bug#752520: RFS: lilyterm/0.9.9.4-1 [ITP]
On Wed, Jun 25, 2014 at 04:27:51PM +0400, Michael Tokarev wrote: > Besides, why did you create lilyterm-data? Can't you just swallow > it by main lilyterm package? You may need extra -data in two cases -- > when that -data comes from a separate source, or when you have several > different variations of your term package (say, gtk2 and gtk3 versions) > which all use a common set of data files. Apparently neither of the > two cases applies here. To save space for debian servers. The lilyterm-data contains architecture independent files like i18n. Because they are architecture independent, putting them into lilyterm-data can make it serves all architectures (12 IIRC) in debian. If these files are in lilyterm, which is architecture dependent, debian will have 12 copies of these data. -- ChangZhuo Chen (陳昌倬) http://czchen.info/ Key fingerprint = EC9F 905D 866D BE46 A896 C827 BE0C 9242 03F4 552D signature.asc Description: Digital signature
Bug#752520: RFS: lilyterm/0.9.9.4-1 [ITP]
[I don't intend to sponsor this package. Sorry!] * Michael Tokarev , 2014-06-25, 16:27: lilyterm - Light and eazy-to-use terminal emulator for X Typo: eazy -> easy why did you create lilyterm-data? Can't you just swallow it by main lilyterm package? You may need extra -data in two cases -- when that -data comes from a separate source, or when you have several different variations of your term package (say, gtk2 and gtk3 versions) which all use a common set of data files. Apparently neither of the two cases applies here. The third case (likely most common one) is when an arch:any package would otherwise contain huge /usr/share. Which doesn't seem to be the case here either. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140625132046.ga6...@jwilk.net
Bug#752520: RFS: lilyterm/0.9.9.4-1 [ITP]
24.06.2014 16:41, ChangZhuo Chen (陳昌倬) wrote: > Package: sponsorship-requests > Severity: wishlist > > Dear mentors, > > I am looking for a sponsor for my package "lilyterm" > > Package name: lilyterm > Version : 0.9.9.4-1 > Upstream Author : Lu, Chao-Ming (Tetralet) > URL : http://lilyterm.luna.com.tw/ > License : GPL-3+ > Section : x11 > > It builds those binary packages: > > lilyterm - Light and eazy-to-use terminal emulator for X > lilyterm-data - Data files for lilyterm > lilyterm-dbg - Debug symbols for lilyterm What is the advantage of lilyterm over a gazzilion of other *terms debian already ships? What's wrong with, say, roxterm? Besides, why did you create lilyterm-data? Can't you just swallow it by main lilyterm package? You may need extra -data in two cases -- when that -data comes from a separate source, or when you have several different variations of your term package (say, gtk2 and gtk3 versions) which all use a common set of data files. Apparently neither of the two cases applies here. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53aac047.6060...@msgid.tls.msk.ru
Bug#750592: Urgently looking for sponsor
Hi, I am urgently looking for a sponsor willing to help with uploading my packages. The old pyfomrex-0.8.6-4 packages currently in testing/sid (besides being obsolete) do not build anymore. See bug #750351. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=750351 Anybody interested in helping me to keep pyformex in Debian? Can the bug title be changed for this purpose, e.g. adding "Fixes bug #750351" ? Benedict -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53aac04e.8060...@ugent.be
Re: I would like to renew my request to delay the removal of maitreya from testing.
[Cc-ing #749974 since that's the relevant bug] Thanks for your work on this, Paul. On Wed, Jun 25, 2014 at 12:40:15AM -0500, Paul Elliott wrote: > BUT! I have just checked packages.debian.org and I find that > libwxsqlite3-3.0-dev which the new version of maitreya will depend on > is still in experimental! Uploading libwxsqlite3 to unstable would start the transition, so we're currently waiting for the reverse dependencies to be ready. Since codelite has been ready for while, that means we're waiting for guayadeque and ... you. There's a partial patch from dmn for guayadeque, but no maintainer response so far. > Even if it were released to unstable > immeadiately, it would take at least 10 days, by my understanding, for > it to reach testing, and then 10 days for maitreya to follow. As Niels says, the default urgency is now medium, which means 5 days, and both packages could age concurrently rather than consecutively, so it could actually just be 5 days if both were uploaded simultaneously. As he also says, the timer gets reset if you post a status update to the ticket. > I plan to grab the source for libwxsqlite3-3.0-dev from > testing and see if I can get it to build under unstable. ^experimental? You should just be able to build maitreya in an unstable chroot set up to use experimental for packages which can't be provided by unstable (due to a versioned BD or unstable not having the package). Exactly how to set that up depends on what tool you're using to do the building in a clean chroot. Cheers, Olly -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140625070423.gl8...@survex.com
