Re: RFS: aegis (updated package, NMU)
Reinhard Tartler writes:
[...]
> OK, NMU is uploaded to DELAYED/2, this means that it should reach the
> archive on tuesday.
Looking at https://buildd.debian.org/~luk/status/package.php?p=aegis
there are some dependencies installability problem:
* on kfreebsd-* fhist is missing due to #414005 (still open after 2 years)
I'll contact the maintainer.
* on ia64 and mips:
aegis (= 4.24-5.1) build-depends on debhelper (>= 5) {debhelper (= 7.4.2)}
debhelper (= 7.4.2) depends on dpkg-dev (>= 1.14.19) {dpkg-dev (= 1.15.4)}
dpkg-dev (= 1.15.4) depends on perl-modules {perl-modules (= 5.10.1-4)}
How should I handle the above problem?
ciao
--
Walter Franzini
http://aegis.stepbuild.org/
pgpwDxtJK1PBW.pgp
Description: PGP signature
Re: RFS: aegis (updated package, NMU)
Walter Franzini writes:
>
> Looking at https://buildd.debian.org/~luk/status/package.php?p=aegis
> there are some dependencies installability problem:
>
> * on kfreebsd-* fhist is missing due to #414005 (still open after 2 years)
>
> I'll contact the maintainer.
I'm CC'ing the kfreebsd porter list. Maybe they want to do an porter
NMU, or can give at least input how to solve this?
> * on ia64 and mips:
>
> aegis (= 4.24-5.1) build-depends on debhelper (>= 5) {debhelper (= 7.4.2)}
> debhelper (= 7.4.2) depends on dpkg-dev (>= 1.14.19) {dpkg-dev (= 1.15.4)}
> dpkg-dev (= 1.15.4) depends on perl-modules {perl-modules (= 5.10.1-4)}
>
> How should I handle the above problem?
I guess this is a transitional problem that can be resolved by the
debian-wb-team. (also CC'ed).
@debian-wb-team, can you confirm my guess? Is there anything that we can
or should do about this?
--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
RFS: ktikz
Dear mentors, I am looking for a sponsor for my package "ktikz". * Package name: ktikz Version : 0.9-1 Upstream Author : [fill in name and email of upstream] * URL : [fill in URL of upstreams web site] * License : [fill in] Section : graphics It builds these binary packages: ktikz - Editor for the TikZ language The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/k/ktikz - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/k/ktikz/ktikz_0.9-1.dsc I would be glad if someone uploaded this package for me. Cheers, Florian Hackenberger PS: Please CC me, I am not subscribed to the list! -- DI Florian Hackenberger flor...@hackenberger.at www.hackenberger.at -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
RFS: ktikz
Dear mentors, Sorry for the incomplete template email, here is the 'fixed' version. I am looking for a sponsor for my package "ktikz". * Package name: ktikz Version : 0.9-1 Upstream Author : Florian Hackenberger * URL : http://www.hackenberger.at/blog/ktikz-editor-for-the-tikz-language/ * License : GPLv2 Section : graphics It builds these binary packages: ktikz - Editor for the TikZ language The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/k/ktikz - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/k/ktikz/ktikz_0.9-1.dsc I would be glad if someone uploaded this package for me. Cheers, Florian Hackenberger PS: Please CC me, I am not subscribed to the list! -- DI Florian Hackenberger flor...@hackenberger.at www.hackenberger.at -- DI Florian Hackenberger flor...@hackenberger.at www.hackenberger.at -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: aegis (updated package, NMU)
Reinhard Tartler writes: > Walter Franzini writes: >> >> Looking at https://buildd.debian.org/~luk/status/package.php?p=aegis >> there are some dependencies installability problem: >> >> * on kfreebsd-* fhist is missing due to #414005 (still open after 2 years) >> >> I'll contact the maintainer. > > I'm CC'ing the kfreebsd porter list. Maybe they want to do an porter > NMU, or can give at least input how to solve this? #414005 contains a patch that should fix the problem. basically s...@linux/sta...@sys/stat.h@ -- Walter Franzini http://aegis.stepbuild.org/ pgpNsWqZmp3uy.pgp Description: PGP signature
Re: RFS: ktikz
* Florian Hackenberger [090930 10:57]: > I am looking for a sponsor for my package "ktikz". > > http://mentors.debian.net/debian/pool/main/k/ktikz/ktikz_0.9-1.dsc Just the most obvious stuff from a cursory look: - DEB_BUILD_OPTIONS=noopt does not work (it still does -O2) - debian/copyright does not list copyright or license of src/lineedit.cpp - debian/menu has a pre-lenny section - debian/dirs has usr/sbin. I do not think you need that. - the manpage is a joke - if your README.Debian has nothing to say, delete the file Hochachtungsvoll, Bernhard R. Link -- "Never contain programs so few bugs, as when no debugging tools are available!" Niklaus Wirth -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Unit tests and application data
Hi all,
i am trying to package an Python application that ships unit tests and
application data. I am unsure how this should be handled on Debian.
The application contains some nose test scripts and data that are
installed into PREFIX/share/foo/test/{scripts,data}. Is this the
appropriate place in Debian?
Furthermore it also installs application data into
PREFIX/share/foo/data. The data is unlikely to change, but could be
replaced by newer versions whenever the system administrator decides to
do so. Is '/usr/share/foo/data' correct for data like this?
thanks for all the fish
Wolodja Wentland
signature.asc
Description: Digital signature
Re: Unit tests and application data
Wolodja Wentland writes:
> The application contains some nose test scripts and data that are
> installed into PREFIX/share/foo/test/{scripts,data}. Is this the
> appropriate place in Debian?
Probably the unit test suite and its data is inappropriate for
installation by the binary package, since regular users won't use it and
anyone intending to understand how the program operates or to modify it
will want the source package anyway. Keep it in the source package, but
omit it from the binary.
If the distribution is done using Python's Distutils, then this should
be configured by upstream: the configuration of ‘setup.py’ should
include all files for the ‘sdist’, but deliberately omit the test suite
and its data from installation.
> Furthermore it also installs application data into
> PREFIX/share/foo/data. The data is unlikely to change, but could be
> replaced by newer versions whenever the system administrator decides
> to do so. Is '/usr/share/foo/data' correct for data like this?
Yes. Newer package releases can of course replace files installed by
older releases of the package (exception: conffiles), and for files that
don't change during the lifetime of a particular release,
‘/usr/share/foo/’ is correct.
You might want to consult the latest versions of FHS and Debian Policy
to get more details on the appropriate places for files by their
intended purpose.
--
\ “I busted a mirror and got seven years bad luck, but my lawyer |
`\thinks he can get me five.” —Steven Wright |
_o__) |
Ben Finney
pgp9vgPLGibMX.pgp
Description: PGP signature
Re: Unit tests and application data
On Wed, Sep 30, 2009 at 20:10 +1000, Ben Finney wrote: > Wolodja Wentland writes: > If the distribution is done using Python's Distutils, then this should > be configured by upstream: the configuration of ‘setup.py’ should > include all files for the ‘sdist’, but deliberately omit the test suite > and its data from installation. Thanks for the explanation! A short question though: Running the tests would entail that all python-modules used by any given library or application would end up as build dependencies of the package. The dependencies of the application in question here are very modest (python-progressbar) but this could be problematic if the test suite requires a lot of other modules or even running and configured services (DB, Web server, ...). How is this usually handled? > > Furthermore it also installs application data into > > PREFIX/share/foo/data. The data is unlikely to change, but could be > > replaced by newer versions whenever the system administrator decides > > to do so. Is '/usr/share/foo/data' correct for data like this? > Yes. Newer package releases can of course replace files installed by > older releases of the package (exception: conffiles), and for files that > don't change during the lifetime of a particular release, > ‘/usr/share/foo/’ is correct. > You might want to consult the latest versions of FHS and Debian Policy > to get more details on the appropriate places for files by their > intended purpose. I already read the FHS and am unsure whether '/usr/share/foo' or '/var/lib/foo' is the appropriate place. There might even be a better one :-) The data is not necessarily needed by the application/library but significantly enhances its functionality. It is therefore packaged by upstream as an additional foo-data distribution and will be packaged in Debian as an additional package. The data *might* change during the lifetime of the release which is unlikely but possible. A system administrator might want to update these data files without having a new release from upstream. I think this is unlikely to happen but it is a possible scenario. /var/lib/foo-data does not seem to be the appropriate place for these files as the data is not state information that is modified while the application/library is used. /usr/share/foo-data looks more promising if it were not for the fact that an administrator could want to update these files without having a corresponding upstream release of foo-data. My intuition tells me that /usr/share/foo-data is the appropriate place and that updated information should be considered a bug which, once filed and processes, will trigger a new release of foo-data. Is this more or less correct? kind regards Wolodja Wentland signature.asc Description: Digital signature
Re: Unit tests and application data
Wolodja Wentland writes: > The data is not necessarily needed by the application/library but > significantly enhances its functionality. It is therefore packaged by > upstream as an additional foo-data distribution and will be packaged > in Debian as an additional package. > > The data *might* change during the lifetime of the release which is > unlikely but possible. A system administrator might want to update > these data files without having a new release from upstream. I think > this is unlikely to happen but it is a possible scenario. The system administrator *might* decide to change any file they like; that doesn't affect the decision of where the operating system should install those files. The question is how those files are treated by the operating system. If the files are static data that the programs should not modify (with the already noted exception of package installation and upgrade), then ‘/usr/share/foo/’ is a good place for them. > /var/lib/foo-data does not seem to be the appropriate place for these > files as the data is not state information that is modified while the > application/library is used. Correct, ‘/var/’ is not the right place for static data files. > My intuition tells me that /usr/share/foo-data is the appropriate > place and that updated information should be considered a bug which, > once filed and processes, will trigger a new release of foo-data. Is > this more or less correct? You've said that the ‘foo-data’ package will be data solely intended for use with the ‘foo’ package. In that case, they should not be installed to ‘/usr/share/foo-data/’ since that implies they're conceptually separate from ‘foo’. Rather, ‘/usr/share/foo/’ seems the right place to me. -- \ “Yesterday I parked my car in a tow-away zone. When I came back | `\ the entire area was missing.” —Steven Wright | _o__) | Ben Finney pgpL4AFFOgCGj.pgp Description: PGP signature
Re: Unit tests and application data
Le Wed, Sep 30, 2009 at 12:43:38PM +0200, Wolodja Wentland a écrit : > > A short question though: Running the tests would entail that all > python-modules used by any given library or application would end up as > build dependencies of the package. > > The dependencies of the application in question here are very modest > (python-progressbar) but this could be problematic if the test suite > requires a lot of other modules or even running and configured services > (DB, Web server, ...). How is this usually handled? Dear Wolodja, I think that having test results in the build logs is very valuable, and that it is worth enlarging the build dependencies to acheive that. Note however that the network is not always accessible from our build daemons. Tests requiring the network have to be disabled, but I strongly recommend that you run them locally before you upload your package. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: qwit (updated package)
On Tue, Sep 29, 2009 at 6:28 PM, Patrick Matthäi wrote: > Hello, Hello Patrick. Thanks for your help. > there are some issues: > 1) interdiff states much more changes as you described in your changelog > (e.g. debian/rules). There are big upstream changes, but debian dir doesn't change very much. Find attached a diff file comparing the new debian dir with the previous one How do you find changes in debian/rules? This particular file is untouched. Interdiff seems to think that *everything* is new...I'm a little lost here. > 2) It is not a new upstream version, it is a new svn snapshot and please > describe the upstream issue in your changelog, like: > * New upstream svn snapshot. > - Fixes issue X, where it does not update bar. > * Next entry. You're right. With 'new version' I meant 'first package built from the future stable branch' :). I've rephrased and detailed changes in a new package already uploaded to mentors. [1] > 3): > make[1]: Entering directory `/tmp/buildd/qwit-1.0+svn255' > /usr/bin/uic-qt4 src/MainWindow.ui -o var/ui_MainWindow.h > make[1]: svnversion: Command not found > for every line, is this wanted? It replaces the 'revision' property with the svn 'head' revision number for each file. I guess this is not _needed_ but _wanted_ either by the upstream or by the IDE. Obviously, 'subversion' should be added to Build-depends in order to fix this errors (not done yet), but I don't find this is very elegant. The other option is to talk with upstream about "how much does he need it" and come to an agreement with him (he is quite nice and responsive). Regards. [1] http://mentors.debian.net/debian/pool/main/q/qwit/qwit_1.0+svn255-1.dsc -- --- Carlos Galisteo GPG keys & fingerprints: 0x8E0076E9 -> 939E 3D10 EAA2 A972 3AF2 E25C 26B7 D8E3 8E00 76E9 0x69ADBE65 > F888 6FBA 9145 B5A2 C187 66D6 5B8C 027A 69AD BE65 --- Only in debian/: README.source diff -ru /tmp/qwit-0.9/debian/changelog debian/changelog --- /tmp/qwit-0.9/debian/changelog 2009-09-29 18:35:03.0 +0200 +++ debian/changelog 2009-09-30 12:13:22.0 +0200 @@ -1,3 +1,17 @@ +qwit (1.0+svn255-1) unstable; urgency=low + + * New upstream svn snapshot providing some bug fixes and new features: +- Upstream moved to 1.x branch. +- Fixes 'Twitpocalypse' related bugs (int limit reached). +- Url shorteners support. +- Multiple accounts support. +- Identi.ca and other twitter-compatible services support. + * Updated Standards-Version to 3.8.3 No change needed. + * Added README.source file. + * Crystal Project Icons license detailed in debian/copyright. + + -- Carlos Galisteo Tue, 29 Sep 2009 16:58:18 +0200 + qwit (0.9-1) unstable; urgency=low * Initial release (Closes: #528189) diff -ru /tmp/qwit-0.9/debian/control debian/control --- /tmp/qwit-0.9/debian/control 2009-09-29 18:35:03.0 +0200 +++ debian/control 2009-09-29 17:00:24.0 +0200 @@ -3,7 +3,7 @@ Priority: extra Maintainer: Carlos Galisteo Build-Depends: debhelper (>= 7), quilt, txt2man, qt4-qmake, libqt4-dev -Standards-Version: 3.8.2 +Standards-Version: 3.8.3 Homepage: http://code.google.com/p/qwit/ Package: qwit diff -ru /tmp/qwit-0.9/debian/copyright debian/copyright --- /tmp/qwit-0.9/debian/copyright 2009-09-29 18:35:03.0 +0200 +++ debian/copyright 2009-09-30 11:17:29.0 +0200 @@ -20,6 +20,9 @@ TwitPicDialog.cpp, TwitPicDialog.h: Copyright (C) 2009 Roopesh Chander +Crystal Project Icons: +Copyright (C) 2009 Everaldo Coelho + License: This program is free software; you can redistribute it and/or modify @@ -38,6 +41,14 @@ the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. +The Crystal Project Icons are released under LGPL: + +You should have received a copy of the GNU General Public License with +your Debian GNU system, in /usr/share/common-licenses/LGPL, or with the +Debian GNU hello source package as the file COPYING. If not, write to +the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, +Boston, MA 02110-1301 USA. +
Re: RFS: qwit (updated package)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Carlos Galisteo schrieb: > On Tue, Sep 29, 2009 at 6:28 PM, Patrick Matthäi wrote: >> Hello, > > Hello Patrick. Thanks for your help. > >> there are some issues: >> 1) interdiff states much more changes as you described in your changelog >> (e.g. debian/rules). > > There are big upstream changes, but debian dir doesn't change very much. > > Find attached a diff file comparing the new debian dir with the previous one Hm right, interdiff blows up :o diff is clear now against your changes. > > How do you find changes in debian/rules? This particular file is > untouched. Interdiff seems to think that *everything* is new...I'm a > little lost here. > >> 2) It is not a new upstream version, it is a new svn snapshot and please >> describe the upstream issue in your changelog, like: >> * New upstream svn snapshot. >>- Fixes issue X, where it does not update bar. >> * Next entry. > > You're right. With 'new version' I meant 'first package built from > the future stable branch' :). > I've rephrased and detailed changes in a new package already uploaded > to mentors. [1] Now it is fine. > >> 3): >> make[1]: Entering directory `/tmp/buildd/qwit-1.0+svn255' >> /usr/bin/uic-qt4 src/MainWindow.ui -o var/ui_MainWindow.h >> make[1]: svnversion: Command not found >> for every line, is this wanted? > > It replaces the 'revision' property with the svn 'head' revision > number for each file. > > I guess this is not _needed_ but _wanted_ either by the upstream or > by the IDE. Obviously, 'subversion' should be added to Build-depends > in order to fix this errors (not done yet), but I don't find this is > very elegant. > > The other option is to talk with upstream about "how much does he > need it" and come to an agreement with him (he is quite nice and > responsive). Try it out :) > > Regards. > > [1] http://mentors.debian.net/debian/pool/main/q/qwit/qwit_1.0+svn255-1.dsc > > Uploaded. - -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org Comment: Always if we think we are right, we were maybe wrong. */ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkrDfHMACgkQ2XA5inpabMdIegCeIU5ZrOi1gPa/exzuSNvkYV2r syAAn1Wk3WHLgfFmhocj5kXDLbV3qoMP =j4F7 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: qwit (updated package)
On Wed, Sep 30, 2009 at 5:42 PM, Patrick Matthäi wrote: > Uploaded. Great, I'll talk with upstream about svnversion, but in the meanwhile don't you think it should build-depends on subversion? Thanks again. -- --- Carlos Galisteo GPG keys & fingerprints: 0x8E0076E9 -> 939E 3D10 EAA2 A972 3AF2 E25C 26B7 D8E3 8E00 76E9 0x69ADBE65 > F888 6FBA 9145 B5A2 C187 66D6 5B8C 027A 69AD BE65 --- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: qwit (updated package)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Carlos Galisteo schrieb: > On Wed, Sep 30, 2009 at 5:42 PM, Patrick Matthäi wrote: > >> Uploaded. > > Great, I'll talk with upstream about svnversion, but in the meanwhile > don't you think it should build-depends on subversion? It would be nice but it does not seem to be needed, it also does not FTBFS. - -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org Comment: Always if we think we are right, we were maybe wrong. */ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkrDhccACgkQ2XA5inpabMcQOQCeO8n4JT7ZwQfiCNIEdyf6ijP6 EngAoIwiV/1gfYp/peiodG+yz7q/55HH =+EgQ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: qwit (updated package)
On Wed, Sep 30, 2009 at 6:22 PM, Patrick Matthäi wrote: >> Great, I'll talk with upstream about svnversion, but in the meanwhile >> don't you think it should build-depends on subversion? > > It would be nice but it does not seem to be needed, it also does not FTBFS. OK. Thank you one more time. -- --- Carlos Galisteo GPG keys & fingerprints: 0x8E0076E9 -> 939E 3D10 EAA2 A972 3AF2 E25C 26B7 D8E3 8E00 76E9 0x69ADBE65 > F888 6FBA 9145 B5A2 C187 66D6 5B8C 027A 69AD BE65 --- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: aegis (updated package, NMU)
On Wed, Sep 30, 2009 at 10:14:20AM +0200, Reinhard Tartler wrote:
> > * on ia64 and mips:
> >
> > aegis (= 4.24-5.1) build-depends on debhelper (>= 5) {debhelper (= 7.4.2)}
> > debhelper (= 7.4.2) depends on dpkg-dev (>= 1.14.19) {dpkg-dev (= 1.15.4)}
> > dpkg-dev (= 1.15.4) depends on perl-modules {perl-modules (= 5.10.1-4)}
> >
> > How should I handle the above problem?
>
> I guess this is a transitional problem that can be resolved by the
> debian-wb-team. (also CC'ed).
perl is currently uninstallable on those arches. It will
automaticly be build when perl is installable again.
Kurt
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Upload of a non-latest upstream version?
Hi, On Mon, 28.09.2009 at 15:50:28 -0700, Ludovico Cavedon wrote: > the latest upstream version (0.8.2) depends on python-iniparse, which > has been in ITP for quite a long time. Version 0.8, instead, has not > such dependency. Moreover I had to repackage 0.8 to make it > debian-policy compliant, while future versions (from 0.8.1) will not > need the repackaging. you can also try to prod the person who filed the ITP on python-iniparse, or suggest to him to take it over, to get it finally into Debian. Kind regards, --Toni++ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Upload of a non-latest upstream version?
On Wed, Sep 30, 2009 at 9:23 AM, Toni Mueller wrote: > you can also try to prod the person who filed the ITP on > python-iniparse, or suggest to him to take it over, to get it finally > into Debian. Yes, I also following this path in parallel... Thanks, Ludovico -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
