Bug#752897: (no subject)

[Gianfranco Costamagna]

Hi again, according to 
https://github.com/luceneplusplus/LucenePlusPlus/issues/69#issuecomment-48609594
there is no more license issues.

For this reason I put a unicode.LICENSE file into debian directory, and 
documented this on the copyright file.

 

thanks for reading,




Gianfranco


--
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/1405674090.30043.yahoomail...@web171802.mail.ir2.yahoo.com

Bug#752339: marked as done (RFS: dbuskit/0.1.1-1 [ITP] -- GNUstep framework that interfaces with D-Bus)

[Debian Bug Tracking System]

Your message dated Fri, 18 Jul 2014 11:16:28 +0200
with message-id <53c8e5ec.3040...@wollumbin.marsaxlokk.dhcp.io>
and subject line Re: Bug#752339: Some questions about RFS: dbuskit/0.1.1-1 [ITP]
has caused the Debian Bug report #752339,
regarding RFS: dbuskit/0.1.1-1 [ITP] -- GNUstep framework that interfaces with 
D-Bus
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.)


-- 
752339: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752339
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "dbuskit".

 * Package name: dbuskit
   Version : 0.1.1-1
   Upstream Author : Niels Grewe 
 * URL : http://download.gna.org/gnustep/
 * License : LGPL-2.1+ (library)
 GPL-3+ (tools + examples)
 FDL-1.3+ (manual)
   Section : libs
   Language: Objective-C

It builds these binary packages:

libdbuskit-dev -  GNUstep framework that interfaces with D-Bus
  (development files)
libdbuskit0 - GNUstep framework that interfaces with D-Bus (runtime
  library)
libdbuskit0-dbg - GNUstep framework that interfaces with D-Bus
  (debugging symbols)

To access further information about this package, please visit the
following URL:

  http://mentors.debian.net/package/dbuskit

Alternatively, one can download the package with dget using this
command:

dget -x http://mentors.debian.net/debian/pool/main/d/dbuskit/dbuskit_0.1.1-1.dsc

The ITP bug is #675962.
--- End Message ---
--- Begin Message ---
On 16-07-14 23:05, Yavor Doganov wrote:
> Yes, because GNUmakefile includes config.make and it's missing in a
> clean tree, the rule to rebuild it is triggered which runs configure
> which in turn generates the libtool script.  Easily fixable upstream.
> 
> I just switched to dh-autoreconf so it doesn't happen anymore (since
> configure is deleted the rule fails).

Build, signed and uploaded.

Paul



signature.asc
Description: OpenPGP digital signature
--- End Message ---

Bug#754463: RFS: pdf2htmlex/0.11+ds-1

[Johannes Schauer]

Hi,

Quoting Jakub Wilk (2014-07-17 13:36:47)
> export HOME=`mktemp --dry-run`
> 
> This sets HOME literally to `mktemp --dry-run`. I think you wanted to 
> say:
> 
> export HOME=$(shell mktemp --dry-run)

oh shoot it's not shell, it's make... while that method will surely also yield
a nonexistant home directory I see why that method is inferior ^^

> But there's a good reason --dry-run is described as “unsafe” in the mktemp
> manpage.

What is the reason? I thought the reason for it being called "unsafe" was that
if you use --dry-run first and then create the directory with that name
yourself then somebody else could hijack that location in the meantime. But
this is no problem for this use case.

> So how about something like this instead:
> 
> export HOME=$(CURDIR)/nonexistent

This is a good solution. As we have control about the directories in $(CURDIR)
we can guarantee that no directory named like that exists during build time.
I'll use it.

cheers, josch


--
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/2014071810.31130.24913@hoothoot

Bug#754202: Gamera/3.4.1-1

[Daniel Stender]

On 14.07.2014 08:21, Dmitry Smirnov wrote:

All right,


Although debian/copyright is almost comprehensive it still misses some
organisations, notably "2007 INRIA" (AKA Dolphin?), "2006 LIFL" (AKA OPAC?).
Worth to clarify.

Besides copyright file feels not very human-readable and therefore it is hard
to review. I understand the effort that will be necessary but I still hope
that eventually (when convenient) the following improvements can be made:

  * Sorting (please alphabetise copyright holders)
  * Padding with spaces (to make lists appears more like tables i.e. add spaces
between copyright year and name if necessary to make all names begin from the
same column). This will increase readability.
  * Ideally it will be nice to have contact emails listed as well. Many of them
can be harvested from source files.
  * I prefer to be more precise regarding years of copyright so I would remove
trailing commas after copyright years. When year of copyright written like
"2007," it may create wrong impression that person is still actively
contributing which is not true on many occasions. I believe it is better to
write "2007-2011" and never use ambiguous trailing commas.


I've improved the copyright file throughout, sorted, padded, removed 
trailing commas, enriched.



I've noticed that package is not using dh_python2. I do not have enough
experience with Python to say whether it is a good or bad thing. I also think
that package could use more debhelper functionality. This is not a problem but
I'd prefer someone (other than me) who have more Python experience to review
and upload. Hopefully someone from Python team could help?


In addition to the exchange of python_support with dh_python2 I've now 
changed also "XS-Python-Version" to "X-Python-Version" in deb/control.



Gamera_gui exposes its modules globally which may be unnecessary. I understand
that according to Python policy it is desirable to install application's
modules privately. In that sense "python-gamera" obviously should be exposed
in global name space but "gamera-gui" may be better to hide its modules.


I've build with the gamera-gui modules in /usr/share/gamera-gui/ but 
there a deeper module import problems. I don't know if that could be 
solved w/o getting dirty, but I'll keep to that issue.



`cme check dpkg-control` (from "libconfig-model-dpkg-perl") reported
unnecessary versioned dependencies. This is the opportunity to clean
"debian/control".


Yes, right. I've checked against cme check dpkg-control and removed the 
needless b-ds.



Finally my biggest concern is new dependency on wxwidgets2.8.
There is on-going transition to wxwidgets3.0:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748169

So if I understand situation properly your package will be blocking this
transition (if uploaded as is) and therefore it will be affected by yet-to-be-
filed "serious" bug. IMHO it will be ideal to migrate to wxwidgets3.0 before
upload.


If wxpython3.0 becomes available when this bug is still open changes on 
that could be pushed quickly. Otherwise I'm going to prepare another 
package immediately after it is available.


Greetings,
Daniel

--
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/53c908d2.5030...@danielstender.com

Bug#746369: marked as done (RFS: downtimed/0.6-2 [ITA])

[Debian Bug Tracking System]

Your message dated Fri, 18 Jul 2014 16:24:17 +
with message-id 
and subject line closing RFS: downtimed/0.6-2 [ITA]
has caused the Debian Bug report #746369,
regarding RFS: downtimed/0.6-2 [ITA]
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.)


-- 
746369: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746369
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sponsorship-requests
  Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "downtimed"

 * Package name: downtimed
   Version : 0.6-2
   Upstream Author : Janne Snabb 
 * URL : http://dist.epipe.com/downtimed/
 * License : Simplified BSD License
   Section : admin

  It builds those binary packages:

downtimed  - monitor of downtime, shutdown, and crashes

  To access further information about this package, please visit the following 
URL:

  http://mentors.debian.net/package/downtimed


  Alternatively, one can download the package with dget using this command:

dget -x 
http://mentors.debian.net/debian/pool/main/d/downtimed/downtimed_0.6-2.dsc

  More information about hello can be obtained from http://www.example.com.

  Changes since the last upload:

* New Maintainer (Closes: #745711)
   

  Regards,
   Stefan Bauer
--- End Message ---
--- Begin Message ---
Package downtimed version 0.6-2 is in unstable now.
http://packages.qa.debian.org/downtimed--- End Message ---

Bug#755201: RFS: libopenshot-audio/0.0.2-1

[Jonathan Thomas]

Package: sponsorship-requests
Severity: normal

Dear mentors,
I am looking for a sponsor for my package "libopenshot-audio"

* Package name: libopenshot-audio
Version : 0.0.2-1
Upstream Author : Jonathan Thomas 
* URL : http://www.openshot.org
* License : GPLv3
Section : libs

It builds those binary packages:

libopenshot-audio-dev - Development files for libopenshot-audio
libopenshot-audio1 - Audio library used by OpenShot

To access further information about this package, please visit the
following URL:
http://mentors.debian.net/package/libopenshot-audio

Alternatively, one can download the package with dget using this command:
dget -x
http://mentors.debian.net/debian/pool/main/libo/libopenshot-audio/libopenshot-audio_0.0.2-1.dsc

Changes since the last upload:
libopenshot-audio (0.0.2-1) unstable; urgency=low

  * New release w/ updated JUCE source code and new license

 -- Jonathan Thomas   Tue, 15 Jul 2014 13:52:16 -0500

Regards,
Jonathan Thomas

Bug#755200: RFS: libopenshot/0.0.2-1

[Jonathan Thomas]

Package: sponsorship-requests
Severity: normal

Dear mentors,
I am looking for a sponsor for my package "libopenshot"

* Package name: libopenshot
Version : 0.0.2-1
Upstream Author : Jonathan Thomas 
* URL : http://www.openshot.org
* License : LGPLv3
Section : libs

It builds those binary packages:

libopenshot-dev - Development files for libopenshot
libopenshot1 - Library for creating and editing videos
python-libopenshot1 - Python bindings for libopenshot

To access further information about this package, please visit the
following URL:
http://mentors.debian.net/package/libopenshot

Alternatively, one can download the package with dget using this command:
dget -x
http://mentors.debian.net/debian/pool/main/libo/libopenshot/libopenshot_0.0.2-1.dsc

Changes since the last upload:
libopenshot (0.0.2-1) unstable; urgency=low

  * New release w/ updated licensing to LGPL

 -- Jonathan Thomas   Tue, 15 Jul 2014 13:54:27 -0500

Regards,
Jonathan Thomas

Bug#754962: RFS: tiptop/2.2 [ITP] -- performance monitoring for Linux via hardware counters

[Vincent Legout]

Hi Tomasz,

Tomasz Buchert  writes:

> I am looking for a sponsor for my package "tiptop":

I'm interested in sponsoring tiptop, I just have some comments:

The package doesn't provide the tiptoprc file from upstream. I think it
would make sense to install it somewhere even if it is not used, maybe
in /usr/share/doc/tiptop.

It seems the git repository and the dsc on mentors differ. I think the
git version is correct, you only need to close #754932. The descriptions
are also different.

According to the source files in src/, the copyright is 2011-2014
Inria. Thus I believe you should also add Inria in debian/copyright.

In debian/copyright, tiptop is GPL-2 but you used the text for GPL-2+
(i.e. with or (at your option) any later version). You also have 2
identical paragraphs for the debian/ directory.

I can't build the package twice in a row. Not sure why, but maybe
because these files are not deleted by dh clean: Makefile, config.h,
config.log, config.status and src/Makefile. I didn't investigate too
much but it also seems that running debclean twice in a row fails
because ./configure is removed by dh_autoreconf_clean and is needed in
Makefile.

I think there is a typo in the manpage: s/if forked/is forked/

Could you please fix this and I'll be happy to upload tiptop.

Thanks,
Vincent


-- 
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/871ttiqwxf@cecht.legt.fr

Bug#755210: RFS: gnustep-sqlclient/1.7.3-2 -- SQL client library for GNUstep

[Yavor Doganov]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "gnustep-sqlclient".  It
failed to build an all architectures for a reason that should be
something specific to the sbuild/buildd setup.
It builds these binary packages:

libsqlclient-dev - SQL client library for GNUstep (development files)
libsqlclient1.7 - SQL client library for GNUstep (runtime library)
libsqlclient1.7-dbg - SQL client library for GNUstep (debugging symbols)

To access further information about this package, please visit the
following URL:

http://mentors.debian.net/package/gnustep-sqlclient

Alternatively, one can download the package with dget using this
command:

dget -x 
http://mentors.debian.net/debian/pool/main/g/gnustep-sqlclient/gnustep-sqlclient_1.7.3-2.dsc

Changes since the last upload:

* debian/rules (override_dh_auto_test): Explicitly set the permissions
  of test.conf to 0644.
* debian/control (Vcs-Browser): Typo fix.


-- 
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/87iomuigq4@yavor.doganov.org

Re: Autoreconfing guide

[Wookey]

+++ Russ Allbery [2014-07-15 23:55 -0700]:
> Yavor Doganov  writes:
> 
> > I also wonder why debian/autoreconf is needed given that autoreconf
> > is recursive.
> 
> I don't think autoreconf can always figure out what to do when the files
> are buried in some random subdirectory without anything at the top level.

Correct. It's generally when the source is in a subdir and there is
nothing autotooly at all at the top level. Or when the package
effectively contains two separate autoconf source trees in it.

It's not very common but certainly have some of these. 

There are also packages that put all the auto* files, including
configure.ac, in a subdir, but put configure itself at the top
level. I don't know if it's possible to explain this layout to
autotools, or if it's just something we should be telling upstream to
stop doing? (I've been dealing with it by backing-up
the top-level configure, running autoconf in the subdir, copying the
resulting configure up to the top, and building. Then put the old,
shipped, configure back manually on clean. Which is just ugly).

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


-- 
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/20140718212059.gi22...@stoneboat.aleph1.co.uk

Re: Autoreconfing guide

[Yavor Doganov]

Wookey wrote:
> +++ Russ Allbery [2014-07-15 23:55 -0700]:
> > I don't think autoreconf can always figure out what to do when the
> > files are buried in some random subdirectory without anything at
> > the top level.
> 
> Correct. It's generally when the source is in a subdir and there is
> nothing autotooly at all at the top level.

Sure, but the wiki page leaves the impression that you must add
debian/autoreconf in almost all cases, it says "plain dh_autoreconf
will often not work".  Such cases should be relevantly rare, I think,
as most packages have a top-level configure and use AC_CONFIG_SUBDIRS.


-- 
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/87bnsmib7o.GNUs_not_UNIX!%ya...@gnu.org

Re: Autoreconfing guide

[Henrique de Moraes Holschuh]

On Fri, 18 Jul 2014, Wookey wrote:
> +++ Russ Allbery [2014-07-15 23:55 -0700]:
> > Yavor Doganov  writes:
> > 
> > > I also wonder why debian/autoreconf is needed given that autoreconf
> > > is recursive.
> > 
> > I don't think autoreconf can always figure out what to do when the files
> > are buried in some random subdirectory without anything at the top level.
> 
> Correct. It's generally when the source is in a subdir and there is
> nothing autotooly at all at the top level. Or when the package
> effectively contains two separate autoconf source trees in it.

Indeed.  In most cases, there will be a shell script somewhere (one of the
usual names is "autogen.sh") that will call autoreconf with the appropriate
options.

> level. I don't know if it's possible to explain this layout to
> autotools, or if it's just something we should be telling upstream to
> stop doing? (I've been dealing with it by backing-up

Well, as long as there is an "autogen.sh"-style script somewhere in the
build tree that does this...

We ought to document locating and using these autogen scripts as a preferred
substitute to running autoreconf directly (this assumes upstream does use
the autogen script :-p).  There is no way to automate adding this to the
package, you have to customize debian/rules in a case-by-case basis, though.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
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/20140718225529.ga14...@khazad-dum.debian.net

Re: Autoreconfing guide

[Russ Allbery]

Henrique de Moraes Holschuh  writes:

> Indeed.  In most cases, there will be a shell script somewhere (one of
> the usual names is "autogen.sh") that will call autoreconf with the
> appropriate options.

Be careful of those scripts.  Often they do other things that you don't
actually want done, and they don't always regenerate everything.

-- 
Russ Allbery (r...@debian.org)   


-- 
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/87y4vq9smm@windlord.stanford.edu

Re: Autoreconfing guide

[Wookey]

+++ Henrique de Moraes Holschuh [2014-07-18 19:55 -0300]:
> On Fri, 18 Jul 2014, Wookey wrote:
> > +++ Russ Allbery [2014-07-15 23:55 -0700]:
> > > Yavor Doganov  writes:
> > > 
> > > > I also wonder why debian/autoreconf is needed given that autoreconf
> > > > is recursive.
> > > 
> > > I don't think autoreconf can always figure out what to do when the files
> > > are buried in some random subdirectory without anything at the top level.
> > 
> > Correct. It's generally when the source is in a subdir and there is
> > nothing autotooly at all at the top level. Or when the package
> > effectively contains two separate autoconf source trees in it.
> 
> Indeed.  In most cases, there will be a shell script somewhere (one of the
> usual names is "autogen.sh") that will call autoreconf with the appropriate
> options.
> 
> > level. I don't know if it's possible to explain this layout to
> > autotools, or if it's just something we should be telling upstream to
> > stop doing? (I've been dealing with it by backing-up
> 
> Well, as long as there is an "autogen.sh"-style script somewhere in the
> build tree that does this...
> 
> We ought to document locating and using these autogen scripts as a preferred
> substitute to running autoreconf directly (this assumes upstream does use
> the autogen script :-p).  There is no way to automate adding this to the
> package, you have to customize debian/rules in a case-by-case basis, though.

I'd like to have some info on when to use an upstream autogen.sh vs
autoreconfing (possibly with options). The one instance I've seen of a
package where the maintainer used the upstream-supplied autogen.sh
didn't work well at all (FTBFS on new arches), whilst autoreconfing
_and_ dh-autotools-deving worked fine. That was libgc which was an
interesting case:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732349
and most relevantly:
https://lists.debian.org/debian-devel/2014/04/msg00459.html

I forget exactly why the autogen.sh in that package wasn't
sufficient/correct, but my understanding is that autogen.sh is usually
designed to set up the package for a developer to build from a fresh
VCS checkout, which may not be quite the same as setting up a released
'tarball' to build on the current system. ('maintainer mode',
etc). But my understanding is vague here.

This is all the stuff that needs writing down in comprehensible form
for baffled maintainers.

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


-- 
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/20140718231628.gm22...@stoneboat.aleph1.co.uk

Re: Autoreconfing guide

[Henrique de Moraes Holschuh]

On Fri, 18 Jul 2014, Russ Allbery wrote:
> Henrique de Moraes Holschuh  writes:
> > Indeed.  In most cases, there will be a shell script somewhere (one of
> > the usual names is "autogen.sh") that will call autoreconf with the
> > appropriate options.
> 
> Be careful of those scripts.  Often they do other things that you don't
> actually want done, and they don't always regenerate everything.

True.  At some point you have no choice but to either pester upstream, or
document in README.source the stuff that needs to be verified manually at
every new upstream release :-(

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
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/20140718231753.gb14...@khazad-dum.debian.net