leechcraft (closes ITP bug)
Dear mentors, I am still looking for a sponsor for my package "leechcraft". This is repeated message. It have passed: - 3 months from the first message (03 Oct 2011) - 2 months from the last repeated message (05 Nov 2011) You can look at package rules here: https://github.com/tehnick/leechcraft-debian/tree/master/debian/ Further information about this package can be found here: http://mentors.debian.net/package/leechcraft Direct link: http://mentors.debian.net/debian/pool/main/l/leechcraft/leechcraft_0.4.97-1.dsc I would be glad if someone uploaded this package for me. LeechCraft is a free open source cross-platform modular internet-client. It consists of a core which defines common plugin interfaces and a lot of plugins for different purposes. User can install any combination of them to achieve the necessary functionality. The main advantage of such approach is that modules could interact more closely than standalone programs in usual Desktop Environments. Thus, plugins can also rely on functionality provided by each other. Plugins could also have their own plugins: for example, support for different protocols or chat window styles in an IM client. Also developers don't reinvent the wheel for each protocol. They use existing solutions (rasterbar libtorrent for BitTorrent or QXmpp for XMPP protocol for example) if possible. And they contribute back their patches to the upstream in these cases. Best regards, Boris -- 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/887731326183...@web53.yandex.ru
Re: Help with java package (beast-mcmc) needed
Hi Andreas, Le dimanche 08 janvier 2012 à 21:42 +0100, Andreas Tille a écrit : > Hi, > $ logcombiner > Exception in thread "main" java.lang.NoClassDefFoundError: > jam/console/ConsoleApplication Usually, this kind of problem is due to the CLASSPATH not containing jam.jar Cheers, Sylvestre -- 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/1326172193.9917.28.ca...@pomegues.inria.fr
Re: Help with java package (beast-mcmc) needed
Hi Sylvestre, On Tue, Jan 10, 2012 at 06:09:53AM +0100, Sylvestre Ledru wrote: > > Exception in thread "main" java.lang.NoClassDefFoundError: > > jam/console/ConsoleApplication > Usually, this kind of problem is due to the CLASSPATH not containing > jam.jar $ grep jam debian/rules export CLASSPATH := $(DEBJAR)/itext.jar:lib/beagle.jar:lib/mpj.jar:lib/org.boehn.kmlframework_20090320.jar:$(DEBJAR)/junit4.jar:$(DEBJAR)/figtree.jar:lib/colt.jar:lib/options.jar:lib/mtj.jar:$(DEBJAR)/jam.jar:$(DEBJAR)/jdom1.jar:$(DEBJAR)/jebl.jar:$(DEBJAR)/commons-math.jar As far as I understood you do not need to explicitely set CLASSPATH at runtime (and it would not explain why the other executables are perfectly finding the needed jars. Any further hints? Kind regards and thanks anyway Andreas. -- http://fam-tille.de -- 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/20120110095920.ge28...@an3as.eu
Re: Help with java package (beast-mcmc) needed
Le 1/10/12 10:59 AM, Andreas Tille a écrit : > Hi Sylvestre, > > On Tue, Jan 10, 2012 at 06:09:53AM +0100, Sylvestre Ledru wrote: >>> Exception in thread "main" java.lang.NoClassDefFoundError: >>> jam/console/ConsoleApplication >> Usually, this kind of problem is due to the CLASSPATH not containing >> jam.jar > $ grep jam debian/rules > export CLASSPATH := > $(DEBJAR)/itext.jar:lib/beagle.jar:lib/mpj.jar:lib/org.boehn.kmlframework_20090320.jar:$(DEBJAR)/junit4.jar:$(DEBJAR)/figtree.jar:lib/colt.jar:lib/options.jar:lib/mtj.jar:$(DEBJAR)/jam.jar:$(DEBJAR)/jdom1.jar:$(DEBJAR)/jebl.jar:$(DEBJAR)/commons-math.jar > > As far as I understood you do not need to explicitely set CLASSPATH at > runtime (and it would not explain why the other executables are > perfectly finding the needed jars. For classpath, at runtime, all depends on how jar is generated. If it contains a MANIFEST file with the classpath defined, it will be able to find the JARS (supposing that libraries path are the same). If it dies not contains the classpath in the MANIFEST file, classpath must be set explicitly to each jar file in the command line (usually via a wrapper shell) Olivier > Any further hints? > > Kind regards and thanks anyway > > Andreas. > -- Olivier Sallou IRISA / University of Rennes 1 Campus de Beaulieu, 35000 RENNES - FRANCE Tel: 02.99.84.71.95 gpg key id: 4096R/326D8438 (pgp.mit.edu) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438 -- 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/4f0c1aa5.5090...@irisa.fr
RFS: stopmotion 0.6.2-1.2 (NMU to fix RC bugs)
Dear mentors,
I am looking for a sponsor for my NMU of "stopmotion". it fixes #565056,
#606721, and #612762.
To access further information about this package, please visit the
following URL:
http://mentors.debian.net/package/stopmotion
Alternatively, one can download the package with dget using this command:
dget -x
http://mentors.debian.net/debian/pool/main/s/stopmotion/stopmotion_0.6.2-1.2.dsc
I would be glad if someone uploaded this package for me.
Kind regards,
Mahyuddin Susanto
http://bugs.debian.org/565056
http://bugs.debian.org/606721
http://bugs.debian.org/612762
--
[ Mahyuddin Susanto ] - http://udienz.web.id
GPG: 4096R/90B36C5B
diff -u stopmotion-0.6.2/debian/rules stopmotion-0.6.2/debian/rules
--- stopmotion-0.6.2/debian/rules
+++ stopmotion-0.6.2/debian/rules
@@ -20,6 +20,7 @@
echo "QMAKE_STRIP=:" | cat >> stopmotion.pro.in
endif
CFLAGS="$(CFLAGS)" ./configure --prefix=/usr
+ sed -i '/^LIBS/s/$$/ -lX11 -lm/' Makefile
build: build-stamp
diff -u stopmotion-0.6.2/debian/changelog stopmotion-0.6.2/debian/changelog
--- stopmotion-0.6.2/debian/changelog
+++ stopmotion-0.6.2/debian/changelog
@@ -1,3 +1,13 @@
+stopmotion (0.6.2-1.2) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * debian/rules: add math and x11 library to fix FTBFS, Patch from Matthias
+Klose . (Closes: #565056, #606721)
+ * Fix Crash when read single jpg files. Patch from Ying-Chun Liu (PaulLiu)
+. (Closes: #612762)
+
+ -- Mahyuddin Susanto Tue, 10 Jan 2012 19:26:27 +0700
+
stopmotion (0.6.2-1.1) unstable; urgency=high
* Non-maintainer upload.
only in patch2:
unchanged:
--- stopmotion-0.6.2.orig/src/application/modelhandler.cpp
+++ stopmotion-0.6.2/src/application/modelhandler.cpp
@@ -97,7 +97,7 @@
QStringList::Iterator it = names.begin();
while (it != names.end() ) {
QString fileName = *it;
- char *f = new char[fileName.length()];
+ char *f = new char[fileName.length()+1];
strcpy(f, fileName.toLatin1().data());
fNames.push_back(f);
++it;
signature.asc
Description: OpenPGP digital signature
Re: Help with java package (beast-mcmc) needed
On Tue, Jan 10, 2012 at 12:01:57PM +0100, Olivier Sallou wrote: > >> Usually, this kind of problem is due to the CLASSPATH not containing > >> jam.jar > > $ grep jam debian/rules > > export CLASSPATH := > > $(DEBJAR)/itext.jar:lib/beagle.jar:lib/mpj.jar:lib/org.boehn.kmlframework_20090320.jar:$(DEBJAR)/junit4.jar:$(DEBJAR)/figtree.jar:lib/colt.jar:lib/options.jar:lib/mtj.jar:$(DEBJAR)/jam.jar:$(DEBJAR)/jdom1.jar:$(DEBJAR)/jebl.jar:$(DEBJAR)/commons-math.jar > > > > As far as I understood you do not need to explicitely set CLASSPATH at > > runtime (and it would not explain why the other executables are > > perfectly finding the needed jars. > > For classpath, at runtime, all depends on how jar is generated. If it > contains a MANIFEST file with the classpath defined, it will be able to > find the JARS (supposing that libraries path are the same). If it dies > not contains the classpath in the MANIFEST file, classpath must be set > explicitly to each jar file in the command line (usually via a wrapper > shell) Apropos MANIFEST: I formerly fiddled around with packaging using jh_manifest and there is also some alternative packaging method at http://people.debian.org/~tille/packages/beast-mcmc-help-wanted/manifest/ featuring a debian/beast-mcmc.manifest file. Believe it or not it shows the very same behaviour. The most strange fact for me is that the two executables loganalyser and logcombiner are very similar but only one of them runs and the other fails. Do you think I should simply add a CLASSPATH variable to those scripts that are failing without understanding why the others are working? Kind regards Andreas. -- http://fam-tille.de -- 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/20120110131155.ga1...@an3as.eu
Gettext and $DESTDIR$prefix
Hi!
I am making a package (which I am upstream of) translatable using
gettext - It is using a simple Makefile as build system, no autotools.
Is there a way to come around the necessity to get LOCALEDIR (Which
is basically ${DESTDIR}{$prefix}/share/locale) from the Makefile to
the C source?
In other words - is there any simpler way to decide whether the
package should load translations from /usr/... or /usr/local/... ?
I am using bindtextdomain(PACKAGE,LOCALEDIR) where both PACKAGE and
LOCALEDIR is defined in the makefile and sent to the source simply in
this way:
-DLOCALEDIR=\"$(LOCALEDIR)\"
Is this an acceptable way of doing it, or am I missing some gettext
magic that I should be using instead? - This feels a bit "hackish"...
Complete Makefile at
https://raw.github.com/gusnan/devilspie2/master/Makefile
Also - I could use hints on where to get gettext support - I cannot
find any mailinglist, nor IRC-channel that is really suitable for this
kind of question...
Help and suggestions would be much appreciated
/Andreas
signature.asc
Description: PGP signature
Re: RFS: proofgeneral
[Stephane: I am moving the discussion to debian-mentors, because I got a reply from Mike Dupont there.] Hi, Thanks for your comments, Mike and Stephane! I am sorry for the missing build-dependencies. I somehow expected it takes much longer until somebody would try my package and that I therefore would have some time for fixes. I believe the build dependencies are right now, at least, I get a clean build in pbuilder. There are still some known issues, see far below. Stéphane Glondu writes: It's good that you take care of that! I've put Pierre Letouzey, who expressed interest in having PG in Debian (and also a Coq developer), in CC. I hope you don't mind. No, I don't mind. A few remarks: - in debian/changelog, put #554263 on its own line, with an explicit statement that you are adopting the package Done. - in debian/changelog, there are two extraneous blank lines after the first entry; don't do that Done. - consider using debhelper 8 compat level Done. - consider using http://dep.debian.net/deps/dep5/ for debian/copyright Done. (Nevertheless, I ask myself, why I got the compat level and the copyright format wrong when following precisely the guidelines in the new maintainers guide.) - what is the rationale of fix-package-name-in-install-path.patch? (sorry if it's a stupid question, shame on me if it's policy :) The package name is ``proofgeneral'' and therefore it should use subdirectories named ``proofgeneral''. The upstream installation procedure creates various subdirectories ``ProofGeneral''. - in general, there are too many patches, and they look written in a Debian-specific way. Please consider writing an upstreamable patch (it seems that you have commit access to PG) to make things more generic, so that there are less Debian-specific patches. Those are a pain to maintain in the long run Yes, I plan to incorporate some of the changes in the upstream release. But this would be step 2. I would first like to concentrate on getting an up-to-date version into Debian. - there is an extraneous TAGS in the upstream tarball Yes, that contains tags for the elisp code for developing Proof General. I don't think this should appear in a Debian package. - isn't emacs23-nox enough, as dependency of the binary package? I use now emacs23-nox | emacs23 | emacs23-lucid in the dependencies. - the compilation fails in a clean sid chroot with the following error: fixed with Build-Depends: debhelper (>= 8), texinfo, texlive-latex-base, texlive-generic-recommended, texi2html, emacs23-nox | emacs23 | emacs23-lucid Known issues: - upgrading from version 3.7 asks whether to preserve the changes in /etc/emacs/site-start.d/50proofgeneral.el even when nobody ever changed that. I believe the reason is that version 3.7 writes that file without registering it with dpkg. Bye, Hendrik -- 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/6xvcoj1u8t@blau.inf.tu-dresden.de
Re: RFR: chromaprint (Adoption)
On Mon, Jan 09, 2012 at 02:07:42PM +0100, Jakub Wilk wrote:
> * Simon Chopin , 2012-01-09, 13:38:
> >>As a side note, for extra safety it'd be good to make sure that
> >>if ever these symbols are used, the generated dependency is
> >>either unsatisfiable or strictly versioned. Unfortunately, the
> >>latter option is currently a bit difficult to implement; see bug
> >>#615940.
> >>
> >I don't understand how I could generate an unsatisfiable
> >dependency: if I write an enormous version, it just gets
> >overwritten:
> >
> >- (regex|optional)"^_ZN?St.*@Base$" 99
> >+ (regex|optional)"^_ZN?St.*@Base$" 0.6-1
> >
> >Note that it would solve the "strictly versioned" bit, at the cost
> >of a systematic lintian error. A bit too ugly for my taste.
>
> The dependency generated by dpkg-shlibdeps doesn't necessarily be in
> the " (>= )" format.
>
> In fact, by "strictly versioned" I meant "(= )" not
> "(>= )".
>
> You could take a look at these packages:
> - libvigaimpex3 ("strict" approach),
> - libdrm-radeon1 ("unsatisfiable" approach).
Thanks for that. I have used the unsatisfiable approach, as I find it
easier to understand how it works (no need to read the debian/rules).
I will go and ask the previous maintainer for sponsorship, assuming
there's no other element that needs fixing.
Regards,
Simon
signature.asc
Description: Digital signature
Re: RFS: xiterm+thai (updated)
On Tue, Jan 10, 2012 at 2:59 PM, Neutron Soutmun wrote: > Please review again > dget -x > http://mentors.debian.net/debian/pool/main/x/xiterm+thai/xiterm+thai_1.10-2.dsc More on txiterm.1: - It should be better to wrap the file at 80 columns. - Using .br to break lines manually in paragraphs is bad typography. Note that you can also use .PP if you mean to break it into new paragraph. - Wording could be improved. (See attached patch for example.) - Please update the date in the .TH line every time you revise the man page. And it should be in -MM-DD format. (See "man man-pages" for more info.) - You may also remove comment lines in the man page as Paul previously suggested. Regards, -- Theppitak Karoonboonyanan http://linux.thai.net/~thep/ --- txiterm.1.orig 2012-01-11 01:25:56.409459181 +0700 +++ txiterm.1 2012-01-11 01:49:15.697505464 +0700 @@ -25,20 +25,20 @@ .\" TeX users may be more comfortable with the \fB\fP and .\" \fI\fP escape sequences to invode bold face and italics, .\" respectively. -\fBtxiterm\fP is a wrapper around the \fBxiterm+thai(1)\fP program that invokes the latter program with Thai support and also loads the Thai font. -.br -All arguments to \fBtxiterm\fP are passed to xiterm+thai without processing; -.br -the \-fn option should not be specified because it is used by the wrapper. +\fBtxiterm\fP is a wrapper around the \fBxiterm+thai(1)\fP program that +invokes the latter program with proper Thai environment and font setup. +.PP +All arguments to \fBtxiterm\fP are passed as-is to xiterm+thai with additional +preset \-fn option, so that you do not need to set it again. .sp -See the xiterm+thai manual page for more information on \fIxiterm+thai-options\fP. +See the xiterm+thai manual page for more information on +\fIxiterm+thai-options\fP. .sp \fBNote: txiterm\fP needs \fBnectec18\fP - Thai TIS-620 X font from the -.br -\fBxfonts-thai-nectec\fP package to allow the program to render the proper Thai text in the terminal. +\fBxfonts-thai-nectec\fP package to allow the program to render Thai TIS-620 +text properly in the terminal. .SH SEE ALSO .BR xiterm+thai(1) -.br .SH AUTHOR txiterm was written by Chanop Silpa-Anan . .PP
Re: Gettext and $DESTDIR$prefix
On Tue, Jan 10, 2012 at 10:56 PM, Andreas Rönnquist
wrote:
> I am making a package (which I am upstream of) translatable using
> gettext - It is using a simple Makefile as build system, no autotools.
>
> Is there a way to come around the necessity to get LOCALEDIR (Which
> is basically ${DESTDIR}{$prefix}/share/locale) from the Makefile to
> the C source?
You would need to do that even if you switch from a Makefile to autotools.
> In other words - is there any simpler way to decide whether the
> package should load translations from /usr/... or /usr/local/... ?
Since $prefix is determined at build time, no there is not.
> Is this an acceptable way of doing it, or am I missing some gettext
> magic that I should be using instead? - This feels a bit "hackish"...
Thats the right way to do it, even in autotools based projects.
> Also - I could use hints on where to get gettext support - I cannot
> find any mailinglist, nor IRC-channel that is really suitable for this
> kind of question...
http://www.gnu.org/software/gettext/FAQ.html#general_mailinglist
I guess gettext is either on-topic in #gnu or you will find someone to
redirect you to the right place.
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAKTje6GK=U-qSFKM-e=r32dhybwf41z7kzwige55_sr5mwh...@mail.gmail.com
RFS: rhinote (new upstream version)
Dear mentors, I am looking for a sponsor for my package "rhinote". * Package name: rhinote Version : 0.7.4-1 Upstream Author : Marv Boyes * URL : http://rhinote.tuxfamily.org/ * License : GPL-2+ Section : x11 It builds those binary packages: rhinote- virtual sticky-notes for your desktop The package is already present in the archive; this new upload would bring Debian up to speed with upstream development, along a bunch of packaging improvements. To access further information about this package, please visit the following URL: http://mentors.debian.net/package/rhinote Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/r/rhinote/rhinote_0.7.4-1.dsc I would be glad if someone uploaded this package for me. -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Re: RFS: proofgeneral
I wrote: - the Proof General splash screen misses the picture (still investigating) Fixed now with the latest upload. - proofgeneral-coq, proofgeneral-minlog and proofgeneral-misc are not deleted when proofgeneral is upgraded. Would Replaces: proofgeneral-coq, ... fix this? Also fixed using Replaces and Conflicts. Bye, Hendrik -- 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/6xr4z719m5@blau.inf.tu-dresden.de
Re: RFS: phing (Another try...)
Hi Nicolas, On Fri, Jul 22, 2011 at 10:08 AM, Nicolas wrote: > Hi Arno, > > many thanks for you report. I will update my packaging for theses cosmetics > changes as you said ! I'd have interest in having this package in Debian, please let me know when the package is ready for the review. Cheers! -- Alessio Treglia | www.alessiotreglia.com Debian Developer | ales...@debian.org Ubuntu Core Developer | quadris...@ubuntu.com 0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A -- 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/camhuwoxuktwsxq0uw_3rxskaz9fejrgng4-p75kanvzfoyc...@mail.gmail.com
RFS: googlefontdirectory-tools
Hi,
I am looking for a sponsor for my package "googlefontdirectory-tools".
My reason for packaging these tools is that they contain several
reasonably general scripts which can be useful for most fonts.
Current VCS-git version of the package "fonts-play" (I'm not sure this
change is big enough to warrant a re-upload) makes use of gfd-tools as
a build-dependency, these tools were previously (somewhat excessively)
included in fonts-play itself. c.f.
http://anonscm.debian.org/gitweb/?p=pkg-fonts/fonts-play.git;a=summary
* Package name: googlefontdirectory-tools
Version : 20120111.1-1
Upstream Authors: Dave Crossland
: Khaled Hosny
* URL :
http://code.google.com/p/googlefontdirectory/source/browse/tools/
* License : Apache-2.0
Section : fonts
Description: various tools for generating, analysing and manipulating font files
This package contains a collection of tools used by the Google Font Directory
to work with fonts.
.
The package includes scripts to:
* Generate ttf and otf fonts from sfd source files
* Generate sfd source files from ttf fonts
* Generate font files with a subset of characters
* Generate namelist files
* Convert otf elements to ttf equivalents
* Auto-set and analyse PREP hinting and hinting tables
* Setting GASP tables in font files
* Analyse bounding boxes
* Compare Unicode points and glyph names
Worth noting is that I do not use, nor know how and why to use about
half of these features, sfd -> ttf is the only one I'm really familiar
with, I'm including the rest since they sound useful :)
The package is available at debexpo/mentors:
http://mentors.debian.net/package/googlefontdirectory-tools
dget -x
http://mentors.debian.net/debian/pool/main/g/googlefontdirectory-tools/googlefontdirectory-tools_20120111.1-1.dsc
Alternatively the source is kept in git at:
http://anonscm.debian.org/gitweb/?p=pkg-fonts/googlefontdirectory-tools.git;a=summary
git clone git://git.debian.org/pkg-fonts/googlefontdirectory-tools.git
debian/rules has a get-orig-source target which you may want to avoid
on a slow connection (the GFD mercurial repo is > 400MB)
+++ lintian output +++
P: googlefontdirectory-tools source: unversioned-copyright-format-uri
http://dep.debian.net/deps/dep5
# I prefer this until the final URI
P: googlefontdirectory-tools: no-upstream-changelog
# I don't think there will be, and I don't think piping mercurial log
to a file makes sense either
N: FontForge scripts are also scripts, they can't help being special.
N:
O: googlefontdirectory-tools: unusual-interpreter usr/share/googlefontdirectory-
tools/tools/bbox/vmet.pe #!/usr/bin/fontforge
# I have requested lintian to support fontforge as an interpreter
I would be glad if someone uploaded this package for me.
Kind regards,
--
Martin Erik Werner ("arand")
signature.asc
Description: This is a digitally signed message part
Re: RFS: xiterm+thai (updated)
On Wed, Jan 11, 2012 at 2:05 AM, Theppitak Karoonboonyanan wrote: > On Tue, Jan 10, 2012 at 2:59 PM, Neutron Soutmun > wrote: > >> Please review again >> dget -x >> http://mentors.debian.net/debian/pool/main/x/xiterm+thai/xiterm+thai_1.10-2.dsc > > More on txiterm.1: > > - It should be better to wrap the file at 80 columns. Wrapped. > - Using .br to break lines manually in paragraphs is bad typography. > Note that you can also use .PP if you mean to break it into new > paragraph. Recorded. > - Wording could be improved. (See attached patch for example.) The example patch is applied. > - Please update the date in the .TH line every time you revise the > man page. And it should be in -MM-DD format. (See "man > man-pages" for more info.) Updated and corrected the formatting. > - You may also remove comment lines in the man page as > Paul previously suggested. Removed. Please review again dget -x http://mentors.debian.net/debian/pool/main/x/xiterm+thai/xiterm+thai_1.10-2.dsc Thanks in advance. Best regards, Neutron Soutmun -- 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/camqp0snv8zjzguznrwghthaxdmvvkxehn_wwc3fyvk21nfv...@mail.gmail.com
Re: RFS: xiterm+thai (updated)
On Wed, Jan 11, 2012 at 11:33 AM, Neutron Soutmun wrote: > Please review again > > dget -x > http://mentors.debian.net/debian/pool/main/x/xiterm+thai/xiterm+thai_1.10-2.dsc Uploaded. Cheers, -Thep. -- Theppitak Karoonboonyanan http://linux.thai.net/~thep/ -- 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/CACvhRiuq_DsxD2EpUXBwMOf05urnJR3eQHTftJksHjX=hmd...@mail.gmail.com
Re: RFS: proofgeneral
Le 10/01/2012 15:56, Hendrik Tews a écrit : > - in debian/changelog, there are two extraneous blank lines after the > first entry; don't do that > > Done. I was talking about the lines *between* changelog entries, not inside the last one. > - consider using http://dep.debian.net/deps/dep5/ for > debian/copyright > > Done. (Nevertheless, I ask myself, why I got the compat level and > the copyright format wrong when following precisely the > guidelines in the new maintainers guide.) I think paths in the Files field should be relative to the root of the unpacked *source* package. I've just noticed that there are files under CC-BY-NC-SA-3. This is not free (the "NC" part). Is the current package shipping these files? If it is (and it looks like it is), this is a severe violation of Debian policy, and the package should be removed. I've added Debian FTP Masters in CC to have their opinion. Is it possible to remove these files from the package? The upstream tarball should be repackaged to remove them. If the package is useless without the images, the package should target the non-free archive instead. Of course, the best solution would be to ask upstream to remove that NC clause. > - the compilation fails in a clean sid chroot with the following error: > > fixed with > Build-Depends: debhelper (>= 8), texinfo, texlive-latex-base, > texlive-generic-recommended, texi2html, emacs23-nox | emacs23 | emacs23-lucid OK, now it builds. Cheers, -- Stéphane -- 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/4f0d30ce.30...@debian.org
Re: RFS: Please sponsor NMU for python-markdown
Update: mentors.debian.net seems to allow re-uploads, so I fixed two issues I wrote about in previous message. Updated diff can be found here at http://paste.ubuntu.com/800258/. -- 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/cakimphvffjeber-160mnybwk-apmzu3umkhy1ka3-lwtvbp...@mail.gmail.com
Re: [Pkg-fonts-devel] RFS: googlefontdirectory-tools
Quoting Martin Erik Werner (martinerikwer...@gmail.com): > Hi, > > I am looking for a sponsor for my package "googlefontdirectory-tools". I added this to my TODO list. As usual with /me, it might take some time to be processed (take time for builds, checks, etc.) but I have no other objection to this package to be uploaded in the archive. Not even package name changes suggestions..:-) signature.asc Description: Digital signature
