Re: Help needed debugging on ARM
On 08/29/2012 09:11 AM, Paul Wise wrote: > On Wed, Aug 29, 2012 at 2:57 PM, Michael Wild wrote: > >> I want to resolve a very strange build failure that is happening on all >> ARM architectures. The package builds some of its documentation images >> with asymptote, which fails [1]. > > This sounds like a bug in asymptote, if not then you might want to try > the debian-arm mailing list or IRC channel. > It does, but then I want to make sure :-) Thanks for the hints where to ask. Michael -- 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/503dc226.3000...@gmail.com
Help needed debugging on ARM
Dear all I want to resolve a very strange build failure that is happening on all ARM architectures. The package builds some of its documentation images with asymptote, which fails [1]. Since I don't have any ARM hardware, I tried to use QEMU. I tried both a full VM and a cowbuilder-dist environment. However, the asy executable just locks up and doesn't finish for hours. From looking at the verbose output, it looks like it's reading its basic module, plain.asy. However, I can't confirm this, since strace doesn't work in QEMU. So, I'm a bit stuck here and would like to ask whether anybody has an idea how I could investigate the build failure (I don't really care to resolve the QEMU issue, though ;-)) Thanks for any of your valuable help Michael [1] https://buildd.debian.org/status/fetch.php?pkg=freefoam&arch=armel&ver=0.1.0%2Bdfsg-1&stamp=1345145759 -- 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/503dbd4d.5040...@gmail.com
Re: How to write a machine-readable debian/copyright file?
On 08/27/2012 11:58 PM, Vincent Cheng wrote: > Hi Francesco, > > On Mon, Aug 27, 2012 at 2:54 PM, Francesco Poli > wrote: > >> So the question is: is there any general purpose tool that scans a >> directory tree, detects the copyright notice and license of each file, >> reorganizes and groups everything, and writes a machine-readable >> debian/copyright file? > > Is this what you are looking for? > > $ licensecheck --copyright -r . | /usr/lib/cdbs/licensecheck2dep5 > > debian/copyright > > You definitely still need to manually check the copyright file > afterwards for any errors, of course. > > Regards, > Vincent > > Also note that you might want to pass suitable -c options to licensecheck, since not only "common source files" contain copyright statements. The current default regex is \.(c(c|pp|xx)?|h(h|pp|xx)?|f(77|90)?|p(l|m)|xs|sh|php|py|rb|java|vala|el|sc(i|e)|cs|pas|inc|dtd|xsl|mod)$ which is by no means complete, IMHO. E.g. it completely misses source types commonly used for the documentation (.tex, .texi, .xml, .ent, .txt, .md, .rst, .svg, .asy, .fig and many more), but also less common source extensions are left out, such as .C and .H for projects that started off when cfront was all the rage and also build systems are ignored (e.g. Makefile, makefile, GNUmakefile, .mk, .cmake, etc.) and especially Debian maintainers should know the importance of the latter... *cough-cdrecord-cough*. Michael -- 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/503c776a.8020...@gmail.com
Re: libtool cannot create a file in /usr/lib/x86_64-linux-gnu/ within pbuilder environment
On 08/27/2012 11:35 PM, Alex Korobkin wrote: > On 27 August 2012 15:03, Paul Gevers wrote: >>> `/usr/lib/x86_64-linux-gnu/libcupsfilters.so.1.0.0': Permission denied >> >> You don't have permissions, obviously. This is because pbuilder runs >> under the pbuilder user, not under root. >> >>> drwxr-xr-x 37 root root 4096 Aug 27 18:30 /usr/lib >>> drwxr-xr-x 14 root root 24576 Aug 27 18:30 /usr/lib/x86_64-linux-gnu/ >> >> I think this actually catches an error. Why install in /usr/lib? I think >> it needs to install into your package, not in the pbuilder file >> structure. Probably some makefile or install script is installing into >> the wrong (hardcoded) location. > > Looks like adding this line to debian/rules helped to solve the problem. > DEB_MAKE_INSTALL_TARGET := install DESTDIR=$(CURDIR)/debian/tmp/ > > Thanks Paul! > > -Alex > > If you are using CDBS, use DESTDIR=$(DEB_DESTDIR) instead. However, this should happen automagically, so there must be something in your d/rules file that breaks this. Michael -- 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/503c7373.5040...@users.sourceforge.net
Bug#665354: RFS: viennacl/1.3.1+dfsg-1 (for experimental)
X-Debbugs-CC: debian-scie...@lists.debian.org Since the upstream project recently published the new version 1.3.1 of ViennaCL, I rebased the packaging I have done so far for viennacl/1.3.0+dfsg-1 onto the work I have done for 1.2.0-2 and uploaded the resulting viennacl/1.3.1+dfsg-1 to debian.mentors.net. The new upstream version contains all patches I submitted to the upstream project, so I was able to remove them all (except the one dealing with the DFSG-cleaning). As usual, you can find more info here: http://mentors.debian.net/package/viennacl And download the package with dget from this URL: http://mentors.debian.net/debian/pool/contrib/v/viennacl/viennacl_1.3.1+dfsg-1.dsc Michael -- 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/502df30c.20...@users.sourceforge.net
Bug#665354: RFS: viennacl/1.3.0+dfsg-1 (for experimental)
On 08/04/2012 09:08 AM, Bart Martens wrote:
> Hi Michael,
>
> About your package at mentors uploaded there on 2012-08-03 08:00. You wrote
> this in debian/copyright :
>
> | Source: http://sourceforge.net/projects/viennacl/files/
> | The repacked source as used in the upload of this package was obtained
> by
> | using git-import-orig(1) as follows:
> | $ git import-orig --uscan --filter-pristine-tar \
> | --filter="*/TU_Signet_CMYK.eps"
> | .
> | To obtain the exact same file, use the following:
> | $ git clone git://git.debian.org/debian-science/packages/viennacl.git
> | $ cd viennacl
> | $ git branch -t pristine-tar origin/pristine-tar
> | $ pristine-tar export ../viennacl_1.3.0+dfsg.orig.tar.gz
> | .
> | The equivalent repackaged source without using git and pristine-tar can
> be
> | created by following these steps:
> | $ wget
> http://sourceforge.net/projects/viennacl/files/1.3.x/ViennaCL-1.3.0-src.tar.gz
> | $ gunzip ViennaCL-1.3.0-src.tar.gz
> | $ tar --delete -f ViennaCL-1.3.0-src.tar
> ViennaCL-1.3.0-src/doc/manual/figures/TU_Signet_CMYK.eps
> | $ mv ViennaCL-1.3.0-src.tar viennacl_1.3.0+dfsg.orig.tar
> | $ gzip -9 viennacl_1.3.0+dfsg.orig.tar
>
> You write "using git-import-orig(1)" but then you write "$ git import-orig",
> not "$ git-import-orig".
Apparently you don't know squat about git. git-import-orig(1) names the
man-page, and the program is also called git-import-orig. But when using
git(1) the way I show, it will search some private directories and the
PATH for git-import-orig. This way it is possible to easily add helpers
and new utilities to git without recompiling it and still retain a
uniform syntax.
>
> The part about git.debian.org doesn't belong here because that is about
> getting
> the already repackaged upstream source code, not about retrieving the upstream
> source code from upstream and reproducing the repackaging.
It shows how to get the bit-wise identical DFSG-clean tar-ball.
>
> The last part doesn't include renaming the top directory as documented here:
> http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-origtargz
> "A repackaged .orig.tar.{gz,bz2,xz} should use
> packagename-upstream-version.orig as the name of the top-level directory in
> its
> tarball."
That's a best-practice recommendation and not mandated by the policy.
git-import-orig doesn't do it, and since that's the program I used to
create the DFSG-clean tar-ball, I chose to give instructions that are
the *equivalent* of what it does. If you still think that this is wrong,
feel free to file a bug against the git-buildpackage package.
>
> Regards,
>
> Bart Martens
>
I feel that this review process is degrading into nit-picking and I just
don't have the time and patience to engage in word-fencing over such a
small thing as the instructions on how to remove a *single* file from a
tar-ball!
If you can't find more substantial points to criticize, I ask you to
either sponsor me and upload the package to experimental, fix it
yourself, or let somebody else do it. Should this charade continue, I'll
have to orphan the package, simple as that.
Michael
--
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/501e8453.6020...@gmail.com
Bug#665354: RFS: viennacl/1.3.0+dfsg-1 (for experimental)
On 08/03/2012 08:46 AM, Bart Martens wrote:
> Hi Michael,
>
> About the package at mentors uploaded there on 2012-08-03 05:49 :
>
> You seem to have responded to my previous comment by writing this in
> debian/copyright :
>
> | Source: http://sourceforge.net/projects/viennacl/files/
> | To obtain the DFSG-free source, use the following option with
> git-import-orig:
> | --filter="*/TU_Signet_CMYK.eps" --filter-pristine-tar
> | .
> | Note that the upstream source tar-ball is called
> | ViennaCL-${VERSION}-src.tar.gz, not ViennaCL-${VERSION}.tar.gz.
>
> So I tried this :
>
> | $ git-import-orig --filter="*/TU_Signet_CMYK.eps" --filter-pristine-tar
> | gbp:error: No archive to import specified. Try --help.
>
> So the provided information is not detailed enough for someone not familiar
> with git-import-orig.
That was admittedly a bit terse. I now explain the exact command used,
plus how one can retrieve the pristine tar-ball from the git-repository
itself.
> Also, I read in "man git-import-orig" that git-import-orig is to import
> upstream source code in a local git repository. But I don't have a local git
> repository for this package.
>
> I suggest to simply write the following in debian/copyright :
>
> | The repackaged source can be reproduced by following these steps :
> | - download ViennaCL-1.3.0-src.tar.gz from
> http://sourceforge.net/projects/viennacl/files/1.3.x/
> | - tar xzf ViennaCL-1.3.0-src.tar.gz
> | - rm ViennaCL-1.3.0-src/doc/manual/figures/TU_Signet_CMYK.eps
> | - mv ViennaCL-1.3.0-src viennacl-1.3.0.orig
> | - tar cf viennacl_1.3.0+dfsg.orig.tar viennacl-1.3.0.orig
> | - gzip -9 viennacl_1.3.0+dfsg.orig.tar
I now also added instructions on obtaining an equivalent (although not
byte-by-byte identical) tar-ball.
The modified version is again available from mentors.debian.net.
Michael
--
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/501b853f.1020...@gmail.com
Bug#665354: RFS: viennacl/1.3.0+dfsg-1 (for experimental)
I fixed the issue of the misplaced information on obtaining the DFSG-clean sources; it is now in debian/copyright as the best practices require. Again, I uploaded to m.d.n. As usual, you can find more info here: http://mentors.debian.net/package/viennacl And download the package with dget from this URL: http://mentors.debian.net/debian/pool/contrib/v/viennacl/viennacl_1.3.0+dfsg-1.dsc Michael -- 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/501b672b.3040...@users.sourceforge.net
Bug#665354: RFS: viennacl/1.3.0+dfsg-1 (for experimental)
I re-imported a DFSG-clean upstream source of the 1.3.0 version by removing the file doc/manual/figures/TU_Signet_CMYK.eps containing PostScript code that is copyrighted by Adobe Inc. and unclear license status. The packaging has been rebased on top of that import, additionally the debian/watch file has been updated for the name mangling. Also, the file doc/manual/IEEEtran_v1.13.bst is now listed in debian/copyright. As usual, you can find more info here: http://mentors.debian.net/package/viennacl And download the package with dget from this URL: http://mentors.debian.net/debian/pool/contrib/v/viennacl/viennacl_1.3.0+dfsg-1.dsc Michael -- 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/501a3fbf.7050...@gmail.com
Bug#683500: RFS: freefoam/0.1.0+dfsg-1 [RC]
Hi Bart On 08/02/2012 07:35 AM, Bart Martens wrote: > Hi Michael, > > About your package "freefoam" at mentors uploaded there on 2012-08-01 08:37. > If nobody increases the bug severities to at least "important" then I suggest > that you reduce the changes to what is likely acceptable for an unblock. I.e. remove all changes that don't fix at least an "important" bug? How long should I wait for eventual severity changes? > Anyhow, my first impression is that you are doing good work on "freefoam". Thanks a lot Michael -- 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/501a347c.6060...@users.sourceforge.net
Bug#683500: RFS: freefoam/0.1.0+dfsg-1
On 08/01/2012 07:00 PM, Bart Martens wrote: > On Wed, Aug 01, 2012 at 12:15:18PM +0200, Michael Wild wrote: >> Some of the bugs are fixed in the upload at m.d.n are not RC, but still >> pretty annoying. To get a freeze-exception, would I need to remove those >> changes? > > What are the bug severities of these "pretty annoying" bugs ? I mostly estimated them as "normal" or "minor", but I'm not really experienced classifying bugs, so you or other reviewers could come to a different conclusion. That's why I asked for a review of these bugs. Specifically, these are: #682931: The freefoam-log utility fails on truncated logs #682932: The freefoam-log utility writes to $PWD/logs/ instead of /logs/ #682934: The -doc and -srcDoc options fail to find the Doxygen docs #683175: Template files /usr/share/freefoam/data/templates/* should be in /usr/share/freefoam/templates #683176: The /usr/share/freefoam/data/foamLog.db is in the wrong place and package #683369: The API documentation is unusable > >> Also, would this upload to to unstable, or to testing directly? > > I suggest to go via unstable, because this is possible for this package. > Please mark RFS 682893 as blocked by RFS 683500 to keep unstable available. Will do, thanks. > >> Lastly, what is the appropriate revision number? I chose to stick with 1 >> since I added the +dfsg suffix, but I'm not sure this is appropriate >> since it is also the second revision based on the 0.1.0 upstream version. > > Your choice 0.1.0+dfsg-1 is good. Thanks. > > Regards, > > Bart Martens > Michael -- 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/5019794b.50...@users.sourceforge.net
Bug#683500: RFS: freefoam/0.1.0+dfsg-1
Package: sponsorship-requests Severity: normal X-Debbugs-CC: debian-scie...@lists.debian.org Dear mentors, I am looking for a sponsor for my package "freefoam" * Package name: freefoam Version : 0.1.0+dfsg-1 Upstream Author : Michael Wild * URL : http://freefoam.sourceforge.net * License : GPL-3+ (+GFDL-NIV-1.2, permissive, PSF-2, LGPL-2.1+, BSD-4-clause, GPL-2) Section : science It builds those binary packages: freefoam - programs for Computational Fluid Dynamics (CFD) freefoam-dev-doc - software for Computational Fluid Dynamics - developers documentation freefoam-user-doc - software for Computational Fluid Dynamics - user documentation libfreefoam1 - libraries for Computational Fluid Dynamics (CFD) libfreefoam-dev - libraries for Computational Fluid Dynamics (CFD) - development files To access further information about this package, please visit the following URL: http://mentors.debian.net/package/freefoam Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/f/freefoam/freefoam_0.1.0+dfsg-1.dsc More information about FreeFOAM can be obtained from http://freefoam.sourceforge.net. Changes since the last upload: * [92ca47f] New upstream version 0.1.0+dfsg (Closes: #682928) * [e07e2f1] Removed d/p/copyright.diff. This information belongs into debian/copyright and the CHEMKIN ckinterp.f file has been removed by the 0.1.0+dfsg import. * [300a38d] Remove DFSG-deleted directories from the build system - Added d/p/remove-dfsg-deleted-directories-from-build-system.diff - Removed d/p/userd.diff. * [5ff801c] Update documentation and completion scripts for DFSG-cleaning - Added d/p/update-for-removed-apps.diff * [d813ede] Added missing build-deps: graphviz (Closes: #682940) * [6a280d2] Fix FTBFS with GCC-4.7 because of non-qualified template-dependent names - Added d/p/missing-qualifications-of-template-dependent-names.diff - Removed the -fpermissive flag from CXXFLAGS. (Closes: #682927) * [a669cc7] Fix bogus lintian override * [a414aa0] Make debian/copyright complete, cleanup (Closes: #682942) * [7f41940] Fix /usr/share/freefoam/DoxyDocIndex installation, fix name mangling - Install it into freefoam-dev-doc package instead of libfreefoam-dev - Add d/p/doxygen-generated-file-names-breakage.diff to fix the name mangling issue - Add d/p/fix-api-doc-location.diff to fix the API documentation location in DoxyDocIndex. (Closes: #682934) * [c14eda9] Fix error in freefoam-log when operating on truncated log files - Add d/p/handle-truncated-logs-in-freefoam-log.diff (Closes: #682931) * [f35bb9c] Fix freefoam-log to create logs/ directory in the case directory, not $PWD - Added d/p/correct-output-directory-for-freefoam-log.diff (Closes: #682932) * [6de0d22] Rename the libfreefoam package to libfreefoam1 - This is to be compliant with policy 8.2 - Also rename the plugins0 directory to plugins1 to honour the same policy (Closes: 682953) * [d2767a3] Install *.so links into the libfreefoam-dev package, not libfreefoam1 (Closes: #682943) * [a307676] Add Michael Wild to the uploaders * [199ae68] Escape meta-characters before creating doc/Doxygen/filter.py - Added d/p/escape-meta-chars-for-doxygen-filter.diff * [6f94315] Fix installation dirs for template files (Closes: #683175) * [b5cc1ea] Install foamLog.db into the freefoam binary package (Closes: #683176) * [149cf7e] Install Doxygen CSS and image resources, update FoamHeader.html - In d/freefoam-dev-doc.install install the css/ and img/ folders - Update doc/Doxygen/FoamHeader.hmtl to Doxygen version 1.8.1.2 (Closes: #683369) Gerber van der Graaf, who originally packaged the freefoam-0.1.0-1 package asked me to add myself directly to the uploaders and asking for sponsorship instead of going through him. I think with the modifications I made I fixed some important bugs, some of which I would consider to be RC. E.g. 0.1.0-1 contained some non-free source and documentation files. Also, the documentation as it is currently installed is pretty buggy and does not work as expected. Also, the *.so symlinks where not split off into the libfreefoam-dev package. Please review the bugs at http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=freefoam, and add comments or change the importance as required. Some of the bugs are fixed in the upload at m.d.n are not RC, but still pretty annoying. To get a freeze-exception, would I need to remove those changes? Also, would this upload to to unstable, or to testing directly? Lastly, what is the appropriate revision number? I chose to stick with 1 since I added the +dfsg suffix, but I'm not sure this is appropriate since it is also the second revision based on the 0.1.0 u
Bug#665354: RFS: viennacl/1.3.0-1 (for experimental)
I rebased the packaging for viennacl/1.3.0-1 onto the work I have done for 1.2.0-2 and uploaded the result to debian.mentors.net. As usual, you can find more info here: http://mentors.debian.net/package/viennacl And download the package with dget from this URL: http://mentors.debian.net/debian/pool/contrib/v/viennacl/viennacl_1.3.0-1.dsc Michael -- 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/5017c8dd.7040...@gmail.com
Re: Determine DEB_HOST_MULTIARCH without requiring dpkg-dev
On 07/31/2012 10:06 AM, Jakub Wilk wrote: > * Michael Wild , 2012-07-25, 11:50: >>>> How can I reliably (from a user-program) determine the >>>> multiarch-triplet/quadlet without depending on dpkg-dev? I found >>>> some talk of a lsb_architecture utility, but so far have found no >>>> trace of it... >>> >>> # gcc -print-multiarch >>> x86_64-linux-gnu >>> >> That's definitely better, but still not optimal since I don't want to >> require gcc either ;-) > > Not only suboptimal, but most likely also wrong. :) > > The whole idea of multi-arch is that you can have packages of different > architectures installed on a single system. So there's no single > "DEB_HOST_MULTIARCH" you could query at run-time. > > Perhaps if you explained what exactly you're trying to do, I could give > you a better answer. :) > > > p.s. Not subscribed. > Well, I have a launcher script in python that launches private executables in /usr/lib/foo/bin/. When porting to multi-arch I figured I should put the private executables into /usrl/lib//foo/bin, but then realised that this is probably the wrong thing to do ;-) Thanks for your help, though! Michael -- 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/5017a211.3000...@gmail.com
Bug#682968: RFS: viennacl/1.2.0-2 [RC]
Just uploaded a new version to m.d.n with the d/changelog entry. -- 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/5012fc57@users.sourceforge.net
Bug#682968: RFS: viennacl/1.2.0-2 [RC]
On 07/27/2012 09:28 PM, Bart Martens wrote: > user sponsorship-reque...@packages.debian.org > usertags 682968 fit-for-wheezy > stop > > > Hi Michael, > > I had a look at your package at mentors uploaded there on 2012-07-27 13:32. > The change to debian/gbp.conf is not mentioned in debian/changelog. > > Regards, > > Bart Martens > I excluded it via Git-Dch: Ignore as I think this change is more of a detail about the repository organization. Would you consider it to be essential that it is included? Michael -- 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/5012f897.2080...@users.sourceforge.net
Bug#682968: RFS: viennacl/1.2.0-2
Package: sponsorship-requests Severity: normal X-Debbugs-CC: debian-scie...@lists.debian.org, 682...@bugs.debian.org Dear mentors, I am looking for a sponsor for my package "viennacl" * Package name: viennacl Version : 1.2.0-2 Upstream Author : Karl Rupp * URL : http://viennacl.sf.net * License : Expat (+other-KHRONOS) Section : science It builds those binary packages: libviennacl-dev - Scientific computing library written in C++ based on OpenCL libviennacl-doc - ViennaCL API and user documentation To access further information about this package, please visit the following URL: http://mentors.debian.net/package/viennacl Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/contrib/v/viennacl/viennacl_1.2.0-2.dsc More information about ViennaCL can be obtained from http://viennacl.sf.net. Changes since the last upload: * [6c05cc0] Fix declaration order of prod_impl() and trans_prod_impl() - Added d/p/0004-Fix-declaration-order-of-prod_impl-trans_prod_impl.patch (Closes: 682410) This revision of the package fixes a FTBFS bug, so should be eligible for a freeze-exception. Regards, Michael Wild -- 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/50129ce8.9050...@users.sourceforge.net
Re: *.so symlinks in shared lib package
On 07/27/2012 10:34 AM, Russ Allbery wrote: > Michael Wild writes: > >> Do *.so development symlinks in a shared-library package constitute a >> policy violation? 8.1 Doesn't forbid them in the library package and 8.4 >> only says the "should" be in the -dev package. > > If the *.so development symlinks prevent two versions of the package with > different SONAMEs from coexisting, it's a violation of Policy 8.2: > > If your package contains files whose names do not change with each > change in the library shared object version, you must not put them in > the shared library package. Otherwise, several versions of the shared > library cannot be installed at the same time without filename clashes, > making upgrades and transitions unnecessarily difficult. > > Normally, the development symlinks will indeed violate this, since they'll > be of the form libfoo.so, which does not change with each change in the > library shared object version. > Thanks Ansgar and Russ That's just the answer I needed to make #682943 a RC bug ;-) Michael -- 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/50125de5.2090...@gmail.com
*.so symlinks in shared lib package
Hi all Do *.so development symlinks in a shared-library package constitute a policy violation? 8.1 Doesn't forbid them in the library package and 8.4 only says the "should" be in the -dev package. Thanks for the help in advance Michael -- 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/50124af6.2060...@users.sourceforge.net
Bug#682893: RFS: freefoam/0.1.2-1 (for experimental)
Package: sponsorship-requests
Severity: normal
Dear mentors,
I am looking for a sponsor for my package "freefoam"
* Package name: freefoam
Version : 0.1.2-1
Upstream Author : Michael Wild
* URL : http://freefoam.sourceforge.net
* License : GPL-3+ (+GFDL-NIV-1.2, permissive, PSF-2,
LGPL-2.1+, BSD-4-clause, GPL-2)
Section : science
It builds those binary packages:
freefoam - programs for Computational Fluid Dynamics (CFD)
freefoam-dbg - programs for Computational Fluid Dynamics (CFD) -
debugging symbols
freefoam-dev-doc - software for Computational Fluid Dynamics -
developers documentation
freefoam-user-doc - software for Computational Fluid Dynamics -
user documentation
libfreefoam - libraries for Computational Fluid Dynamics (CFD)
libfreefoam-dbg - libraries for Computational Fluid Dynamics (CFD) -
debugging symbols
libfreefoam-dev - libraries for Computational Fluid Dynamics (CFD) -
development files
python-freefoam - software for Computational Fluid Dynamics -
Python files
python3-freefoam - software for Computational Fluid Dynamics -
Python3 files
To access further information about this package, please visit the
following URL:
http://mentors.debian.net/package/freefoam
Alternatively, one can download the package with dget using this command:
dget -x
http://mentors.debian.net/debian/pool/main/f/freefoam/freefoam_0.1.2-1.dsc
More information about FreeFOAM can be obtained from
http://freefoam.sourceforge.net.
Changes since the last upload:
* [84c7923] New upstream version 0.1.2
* [162a878] Removed debian/patches/spelling.diff. Fixed in upstream.
* [881573d] Removed debian/patches/copyright.diff. This information
belongs into debian/copyright
* [d834177] Removed debian/patches/userd.diff, upstream removed that
part
* [86c646e] Build man-pages from source, remove pre-compiled copies in
debian/man1
* [0452a37] Build HTML version of UserGuide, depend on libjs-mathjax
* [e0e97d7] Added missing build-deps: graphviz
* [0a2c68d] Move to straight dh sequencer with parallel builds enabled
- The debhelper version present in Ubuntu precise doesn't contain
the fix for the CPPFLAGS variable being ignored by CMake
(#668813), so also add the manual workaround, just to make sure.
- Removed build-depends on cdbs
- Bumped minimum required version of debhelper to 7.0.50~.
- Keep dh_installchangelogs from trying to install doc/changes/ as
a file
* [63668d2] Split off Python module into python{,3}-freefoam, move to
dh_python*
- Changed build-dependency from python-all to simply python added
new
- Build-depends on python3
- Add X-Python{,3}-Version tags
* [59cd2fe] Install private binaries into /usr/lib/freefoam/bin
* [2a39577] Fix bogus lintian override
* [1240767] Cleanup debian/control, fix Homepage/Source entries
* [703e36b] Make debian/copyright complete, cleanup
* [b87d5f9] Do not version plugins directory
* [037f959] Properly assign files to correct package in
debian/*.install. Requires new build-depends on bash-completion.
* [2bdf7d5] Link docs of freefoam-{dev,user}-docs into
/usr/share/docs/freefoam
* [36a0288] Added debian/patches/disable-git-version-check.diff.
Instead of querying git about the build number, use the Debian
version.
* [981346d] Override warnings about useless ldconfig calls
* [e4c2b99] Add Michael Wild to the uploaders
* [02f2ab1] Added
debian/patches/fix-doc-urls-and-references-for-debian.diff.
Update the installation directories accordingly in
debian/freefoam-*-doc.install.
* [63e9652] Added
debian/patches/remove-hard-coded-python-modules-path.diff.
For the build to work it is now required to set the PYTHONPATH
environment variable in debian/rules.
* [06d66a3] Add multiarch support
* [658f053] Create debug-symbols packages {lib,}freefoam-dbg
* [13446a4] Build hardened libraries and executables. This requires
CMake/FOAMUtilities.cmake to be patched, otherwise it would be
impossible to pass the PIE flags to the executables only in CMake.
- Added d/p/add-DEB_EXE_COMPILE_LINKER_FLAGS-to-build-system.diff
- Added a build-depends on hardening-includes
Gerber van der Graaf, who originally packaged the freefoam-0.1.0-1
package asked me to add myself directly to the uploaders and asking for
sponsorship instead of going through him.
I think with the modifications I made I fixed some important bugs, some
of which I would consider to be RC. E.g. 0.1.0-1 contained some non-free
source and documentation files. Also, the documentation as it is
currently installed is pretty buggy and does not work as expected. Also,
the *.so symlinks where not split off into the libfreefoam-dev package
and the Python files where not separated into python* packages.
Some of these bugs I fixed directly in the u
Re: Help with gcc-4.7 needed (Was: poco: FTBFS with multiarch libmysqlclient-dev)
On 07/26/2012 07:26 PM, Andreas Tille wrote: > On Thu, Jul 26, 2012 at 04:55:02PM +0200, Michael Wild wrote: >> Hi Andreas >> >> Reading the error message, it seems that there is a forward-declaration >> of replaceInPlace(...) is missing before it is used in String.h:448. >> >> It seems like simply reversing the order of declaration should fix the >> problem: See the attached (modified) dpatch. > > This was my impression as well and so I reverted the order of some > somehow competing declarations (with different numbers of arguments). > After my try only the line numbers of the error and the note changed > (to reflect the reverse order). > > Than I gave up ... > > Any other hint? > > Kind regards > > Andreas. > Well, with my modified patch (attached to the last mail), it builds fine for me. Michael -- 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/501188fc.8080...@gmail.com
Re: Help with gcc-4.7 needed (Was: poco: FTBFS with multiarch libmysqlclient-dev)
Hi Andreas
Reading the error message, it seems that there is a forward-declaration
of replaceInPlace(...) is missing before it is used in String.h:448.
It seems like simply reversing the order of declaration should fix the
problem: See the attached (modified) dpatch.
Michael
On 07/26/2012 02:45 PM, Andreas Tille wrote:
> Hi,
>
> I tried to apply the patch that is supposed to solve the problem below
> but I was running in another problem which sounds quite familiar from
> other gcc-4.7 issues. I tried to fix the problem in Git
>
>git+ssh://git.debian.org/git/collab-maint/poco.git
>
> and created a branch NMU/1.3.6p1-1.1 where I created a dpatch file
> debian/patches/gcc-4.7.dpatch which unfortunately just reiterates
> the original problem and ends up in
>
> /tmp/buildd/poco-1.3.6p1/Foundation/include/Poco/String.h: In instantiation
> of 'S Poco::replace(const S&, const typename S::value_type*, const typename
> S::value_type*, typename S::size_type) [with S = std::basic_string;
> typename S::value_type = char; typename S::size_type = long unsigned int]':
> src/X509Certificate.cpp:175:55: required from here
> /tmp/buildd/poco-1.3.6p1/Foundation/include/Poco/String.h:448:2: error:
> 'replaceInPlace' was not declared in this scope, and no declarations were
> found by argument-dependent lookup at the point of instantiation
> [-fpermissive]
> /tmp/buildd/poco-1.3.6p1/Foundation/include/Poco/String.h:480:4: note:
> 'template S& Poco::replaceInPlace(S&, const S&, const S&, typename
> S::size_type)' declared here, later in the translation unit
>
>
> Unfortunately my C++ knowledge is to limited to find an easy clue how to
> fix this and would be more than happy if somebody could provide some fix.
>
> BTW, it seems to me that libpoco development only happens in experimental
> and unstable does not deserve the attention it would need. Please help
> fixing the problem to make sure the reverse depends can stay in testing.
>
> Kind regards
>
>Andreas.
>
> - Forwarded message from Andreas Tille -
>
> Date: Thu, 26 Jul 2012 14:23:26 +0200
> From: Andreas Tille
> To: Mathieu Malaterre , 680...@bugs.debian.org,
> Krzysztof Burghardt ,
> 650...@bugs.debian.org
> Subject: Re: Bug#680798: sitplus: FTBFS: build-dependency not installable:
>
> Hi Krzysztof,
>
> there is a long standing (>6 month) RC bug filed against poco including
> a patch for this problem. When applying the patch and trying to build
> the package I realised another FTBFS problem when building with gcc-4.7.
> I'm currently trying to fix this problem and if I succeede I will upload
> to DELAYED/2. Otherwise I'll ask for help on debian-mentors and will
> NMU-upload once the problem is solved.
>
> Kind regards
>
> Andreas.
>
> On Thu, Jul 26, 2012 at 11:52:33AM +0200, Mathieu Malaterre wrote:
>> 'lo
>>
>> On Thu, Jul 26, 2012 at 11:47 AM, Andreas Tille wrote:
>>> On Thu, Jul 26, 2012 at 11:38:24AM +0200, Mathieu Malaterre wrote:
I believe this is because libpoco-dev was removed from testing:
http://packages.qa.debian.org/p/poco/news/20120619T163916Z.html
>>>
>>> I came to the same conclusion but I have no idea how we (in terms
>>> of sitplus maintainers) could solve this.
>>
>> The patch looks straighfoward to apply but for some reason was never
>> applied. So I simply ping'd the maintainers again:
>>
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=650059#16
>>
>> We'll see.
>> --
>> Mathieu
>
#! /bin/sh /usr/share/dpatch/dpatch-run
## gcc-4.7.dpatch by Andreas Tille
##
## DP: Try to fix Build issue with gcc-4.7 ... but failed :-(
@DPATCH@
diff -urNad poco-1.3.6p1~/Foundation/include/Poco/String.h
poco-1.3.6p1/Foundation/include/Poco/String.h
--- poco-1.3.6p1~/Foundation/include/Poco/String.h
+++ poco-1.3.6p1/Foundation/include/Poco/String.h
@@ -451,12 +451,13 @@
template
-S& replaceInPlace(S& str, const S& from, const S& to, typename S::size_type
start = 0)
+S& replaceInPlace(S& str, const typename S::value_type* from, const typename
S::value_type* to, typename S::size_type start = 0)
{
- poco_assert (from.size() > 0);
-
+ poco_assert (*from);
+
S result;
typename S::size_type pos = 0;
+ typename S::size_type fromLen = std::strlen(from);
result.append(str, 0, start);
do
{
@@ -465,7 +466,7 @@
{
result.append(str, start, pos - start);
result.append(to);
- start = pos + from.length();
+ start = pos + fromLen;
}
else result.append(str, start, str.size() - start);
}
@@ -476,13 +477,12 @@
template
-S& replaceInPlace(S& str, const typename S::value_type* from, const typename
S::value_type* to, typename S::size_type start = 0)
+S& replaceInPlace(S& str, const S& from, const S& to, typename S::size_type
start = 0)
{
- poco_asser
Re: Determine DEB_HOST_MULTIARCH without requiring dpkg-dev
On 07/25/2012 11:16 AM, Igor Pashev wrote: > 25.07.2012 12:05, Michael Wild пишет: >> Hi all >> >> How can I reliably (from a user-program) determine the >> multiarch-triplet/quadlet without depending on dpkg-dev? I found some >> talk of a lsb_architecture utility, but so far have found no trace of it... > > # gcc -print-multiarch > x86_64-linux-gnu > > That's definitely better, but still not optimal since I don't want to require gcc either ;-) Michael -- 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/500fc155.4010...@gmail.com
Determine DEB_HOST_MULTIARCH without requiring dpkg-dev
Hi all How can I reliably (from a user-program) determine the multiarch-triplet/quadlet without depending on dpkg-dev? I found some talk of a lsb_architecture utility, but so far have found no trace of it... Thanks Michael -- 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/500fa8b2.7080...@users.sourceforge.net
Re: Help needed with dh_python2 and dh_python3
On 07/24/2012 12:12 PM, Stefano Rivera wrote:
> Hi Michael (2012.07.24_10:15:51_+0200)
>> I have a package that installs a few Python scripts and utility modules
>> which are compatible with both, python2 and python3. The build system
>> does not use distutils, it just copies the files into
>> /usr/share/pyshared//.
>
> That's probably not ideal. pyshared is almost an internal implementation
> detail of dh_python2 (although, one that's documented in the Python
> Policy [0]). Upstream build systems should not be installing there. They
> should install into the usual dist-packages directories, and dh_python2
> will de-duplicate between python versions.
My misunderstanding, obviously. Simple to fix, as I actually forced the
build system to install there ;-)
>
> dh_python2 supports .pyinstall files, to achieve the same thing.
>
> [0]:
> http://www.debian.org/doc/packaging-manuals/python-policy/ch-python.html#s-paths
>
> As to installing for python3, you should install to
> /usr/lib/python3/dist-packages in that binary package.
>
>> Now, I figured it would be as easy as
>>
>> * adding a build-dependency on python and python3
>> * adding X-Python-Versino and X-Python3-Version tags
>> * adding ${python:Depends} and ${python3:Depends} to the respective
>> binary packages dependencies
>> * invoking the dh sequencer with the option --with=python2,python3
>
> You also need to make sure the python modules go into the python-
> package, and the python3 modules go into the python3- package.
>
> With distutils, this means overriding dh_auto_*.
>
>> Anybody got a clue as to what I'm doing wrong here? Do I need to add an
>> extra binary python3-foo package?
>
> Yes.
>
> SR
>
Stefano, Vincent: thanks for the hints.
Michael
--
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/500e83f1.4090...@gmail.com
Help needed with dh_python2 and dh_python3
Hi all
I have a package that installs a few Python scripts and utility modules
which are compatible with both, python2 and python3. The build system
does not use distutils, it just copies the files into
/usr/share/pyshared//.
Now, I figured it would be as easy as
* adding a build-dependency on python and python3
* adding X-Python-Versino and X-Python3-Version tags
* adding ${python:Depends} and ${python3:Depends} to the respective
binary packages dependencies
* invoking the dh sequencer with the option --with=python2,python3
That, however, only seems to give the desired results for python2; the
files in /usr/share/pyshared/ are sym-linked to
/usr/lib/python2.7/dist-packages/. Although, in the build log I
do see that dh_python3 is being invoked, it simply doesn't seem to have
any effect.
Manually invoking dh_python3 then errors out that it detected python2
and that I should call dh_python2 instead.
Anybody got a clue as to what I'm doing wrong here? Do I need to add an
extra binary python3-foo package?
Michael
--
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/500e59b7.60...@gmail.com
Bug#665354: RFS: viennacl/1.3.0-1 (for experimental)
That is only there because the file has been created using Adobe Illustrator. It has nothing to do with the copyright of the actual artwork (unless, of course, the original author did not have a license to use the product in the first place). Michael -- 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/500ae791.90...@users.sourceforge.net
Re: how to document removed Build-Depends in debian/changelog (Re: viennacl at mentors)
On 07/15/2012 01:49 PM, Charles Plessy wrote: > Le Sun, Jul 15, 2012 at 11:25:14AM +, Bart Martens a écrit : >> >> I would mention this in debian/changelog : >> >> * debian/control: No longer Build-Depends: poppler-utils, asciidoc, lynx. >> >> But I don't know how detailed such information must be for debian-policy. >> Sometimes it is useful to also mention the reasons. I'm adding >> debian-mentors >> in cc so that other sponsors can comment if they want to. > > Hi all, > > Policy's section 4.4 indicates that "Changes in the Debian version of the > package should be briefly explained in the Debian changelog file > debian/changelog". In that sense, the entry "Remove unused build-deps" is > already quite informative as it provides the explanation for the change: the > entries were not used. > > For packages that I maintain in a Git repository, I tend to become brief like > this in my changelogs, and more verbose in the corresponding commits, for > which > the changelog mentions the first numbers of the hash ID. But this is a matter > of taste; all in all, it does not cost much to fill up the changelog line with > more information. > > Have a nice day, > Thanks Bart and Charles for the feedback. I uploaded a new version that now contains commit hashes for the entries of the new version and also explains what build dependencies have been removed. Further, a few commits with changes I considered to be covered by other entries are now also present in the changelog. Michael -- 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/5002e343.3070...@gmail.com
Re: Copyright problems for the opensource reimplementation of a closed-source library (ITP #679504)
On 07/06/2012 01:22 PM, Gergely Nagy wrote: > Christophe-Marie Duquesne writes: > >> I am the author of an opensource library that reimplements a >> closed-source library. > [...] >> PS: the project in question is more a "proxy" towards the closed >> source library than a real reimplementation, but technically I >> actually reimplement every function of their header. If you are >> interested, it is hosted here [2]. > > If it is a proxy, then it is not a reimplementation. That you add a > wrapper for every function, doesn't matter, you still call the original. > > If it would be a reimplementation, the best course of action would be to > start with a program that uses the library, and reimplement the > functionality based on what the program expects. > > If you base your work on existing headers, that's borderline derived > work. If you proxy, that *is* derived work, and the whole excercise is > rather pointless, as you will still be bound by the original > license. That you dlopen() and not directly link, is irrelevant. > > (At least, that is my understanding of legalities, but as always, I'm > not a lawyer.) > Also, just taking the proprietary header, kicking out all comments and "elaborating" the macros is IMHO not acceptable since it's copyrighted under a proprietary license. The only thing you *could* do is take the publicly available documentation (if there is any) and re-write the header based on that information. IANAL etc Michael -- 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/4ff6d1f6.80...@users.sourceforge.net
Bug#665354: RFS: viennacl/1.3.0-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "viennacl" * Package name: viennacl Version : 1.3.0-1 Upstream Author : Karl Rupp * URL : http://viennacl.sf.net * License : Expat (+other-KHRONOS) Section : science It builds those binary packages: libviennacl-dev - Scientific computing library written in C++ based on OpenCL libviennacl-doc - ViennaCL API and user documentation To access further information about this package, please visit the following URL: http://mentors.debian.net/package/viennacl Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/contrib/v/viennacl/viennacl_1.3.0-1.dsc More information about ViennaCL can be obtained from http://viennacl.sf.net. Changes since the last upload: * New upstream version 1.3.0 * Exclude editor backup file from dh_clean * Don't auto-generate changelog anymore, upstream added it * Remove get-orig-source target; upstream is clean * Remove erronous DMUA entry * Configure debian/libviennacl-doc.docs in override_dh_auto_configure * Remove unused build-deps * Add 0001-Add-virtual-dtor-to-abstract-result_of-class.patch * Add 0002-Fix-declaration-order-of-prod_impl-trans_prod_impl.patch * Add 0003-Generate-kernel-sources-in-build-tree.patch * Install headers from DESTDIR instead from source * Disable python-support in debian/rules Regards, Michael Wild -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJPxgcTAAoJEACl/dwsHZCQ92AQALQL/V99nGdm5nofh+gCUDA9 GEKkJmOZcLV2O+hDpv14Cenc+WllMi6TMjyzKJ88qDbUtAcD4fkTGSj+JiRQ5NMz AZdqFn8CQru/kbw8vO/ESil1wjKBmNJEs/nnL5zkKHMkW/tjt8QUaFwrLpNAwHJK RfR5HnHqxOWR4ew210zI7yoH9Y/WkORU6EKhptTUTCLabHrWo6MkmOkoGJnfeHw9 yUyVjFuWOErn/+OoFJbPk0xd3o657UdIKWXdTNbb8w+NI6uIT5o/n4gWts2hvYuI UXu1Db/XngVvexbSyIwVpXtYi5GyA1jyg2w+PrK0TEA6shjo9C/MWQk7z9oQ1pJb tHQNRVX0wn0mzk1C6jpR0pqyG+b6zySLAJlc0Bato9ikEx03ZilFJFpHSCRlZeeZ cfmJ6xbx65mQdw/n/n8eGA8qCg08Tk0dMo2Rx3y6hbqKDDbf5Slj47JU+N5bDPUJ 9p1rNNnaqS/oCf5HVX60xLbSSH6hsR0bWzv3Kcqh6L58MVc3aiiddqnUYrSeiHXH XOb/dlARcLD5pxHFEkM/SOjE/06CVpfTFgZcQNE7dJB+46UedMh3HzwnPQ4eb6ku LnxciAcygsxwnC8wuruCW7hXrnZ/cgPLFaJerRSXyKkwd7rRQCZCiT5gux10Pm2d VxxfgEprxrEDyGrqdu/V =lyhn -END PGP SIGNATURE- -- 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/4fc60713.7010...@users.sourceforge.net
Bug#665354: RFS: viennacl/1.2.1-1
On 05/26/2012 05:53 PM, Bart Martens wrote: > Hi Michael, > > Why not 1.3.0 ? > http://viennacl.sourceforge.net/ > http://sourceforge.net/projects/viennacl/files/ > > Regards, > > Bart Martens > > > Hi Bart 1. I didn't know that 1.3.0 has been released. Must have missed it on the list... 2. I filed the RFS long before 1.3.0 has been released. I will update the package to 1.3.0 as soon as I find the time. Michael -- 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/4fc204a5.6080...@users.sourceforge.net
Re: Sanlock - Looking for review
On 05/15/2012 09:29 AM, David Weber wrote: > Hi, > > I'm currently working on a sanlock[1] package for Debian. My current > attempts work good so far but some parts in the build process are > rather complicated (no ./configure; have to run make twice) so I > guess somebody more experienced should do a deeper review before > I can send a RFS. > > You can find my latest package here: > http://mentors.debian.net/package/sanlock > > Thanks! > > David > > > [1] https://fedorahosted.org/sanlock/ I'm far from being an expert (or a DD, for that matter), but I think you can simplify your build by using a patch that provides the top-level Makefile that is missing. E.g.: > --- /dev/null 1970-01-01 00:00:00.0 + > +++ sanlock-2.2/Makefile 2012-05-15 15:38:59.833362732 +0200 > @@ -0,0 +1,3 @@ > +clean all install: > + $(MAKE) -C wdmd $@ > + $(MAKE) -C src $@ Then you can simplify the debian/rules to: > #!/usr/bin/make -f > > DEB_BUILDDIR := $(CURDIR)/debian/build > > override_dh_makeshlibs: > dh_makeshlibs -X/usr/lib/sanlock > > override_dh_installinit: > dh_installinit -psanlock --name=wdmd --no-restart-on-upgrade > dh_installinit -psanlock --name=sanlock --no-restart-on-upgrade > > %: > dh $@ Also, you should possibly patch those spelling errors in ./src/paxos_lease.c that lintian warns about (s/commited/committed/g). HTH Michael -- 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/4fb25f82.7000...@users.sourceforge.net
Re: Help needed to fix gcc 4.7 bug in jellyfish package
On 05/03/2012 02:46 PM, Andreas Tille wrote: [...] > > Michael, I can confirm that I also tried to s/uint_t/int/ in > parse_dna.hpp with the same result (same error message) after I did my > initial posting (that's why I did not felt a real need to send another > mail). > The patch I included "works" (in the sense that I don't get any warnings/errors) for me, although I only tried with `g++-4.7 -Wall -I. -c jellyfish/jellyfish/parse_dna.cc`. I didn't run the whole build. Michael -- 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/4fa28633.5090...@gmail.com
Re: Help needed to fix gcc 4.7 bug in jellyfish package
On 05/02/2012 08:33 AM, Andreas Tille wrote:
> Hi,
>
> I tried to fix the problem in the jellyfish package but the general
> hints given did not helped me really. Any more precise help to fix
> this problem:
>
> parse_dna.cc:97:3: error: narrowing conversion of '-3' from 'int' to 'const
> uint_t {aka const long unsigned int}' inside { } is ill-formed in C++11
> [-Werror=narrowing]
>
> My first idea was to do
>
> --- jellyfish.orig/jellyfish/parse_dna.cc
> +++ jellyfish/jellyfish/parse_dna.cc
> @@ -57,7 +57,7 @@
> }
>}
>
> - const uint_t parse_dna::codes[256] = {
> + const int parse_dna::codes[256] = {
> -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -2, -3, -3, -3, -3, -3,
> -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3,
> -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -1, -3, -3,
> --- jellyfish.orig/jellyfish/parse_dna.hpp
> +++ jellyfish/jellyfish/parse_dna.hpp
> @@ -55,7 +55,7 @@
> static uint64_t mer_string_to_binary(const char *in, uint_t klen) {
>uint64_t res = 0;
>for(uint_t i = 0; i < klen; i++) {
> -const uint_t c = parse_dna::codes[(uint_t)*in++];
> +const int c = parse_dna::codes[(int)*in++];
> if(c & CODE_NOT_DNA)
>return 0;
> res = (res << 2) | c;
>
>
> because it makes no sense to initialise uint with negative numbers but
> this did not changed the error message which sounds totally strange to
> me.
>
> Kind regards
>
> Andreas.
>
You missed the declaration of parse_dna::codes in parse_dna.hpp.
diff --git a/jellyfish/parse_dna.cc b/jellyfish/parse_dna.cc
index ab3ec64..9ea5ae1 100644
--- a/jellyfish/parse_dna.cc
+++ b/jellyfish/parse_dna.cc
@@ -57,7 +57,7 @@ namespace jellyfish {
}
}
- const uint_t parse_dna::codes[256] = {
+ const int parse_dna::codes[256] = {
-3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -2, -3, -3, -3, -3, -3,
-3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3,
-3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -1, -3, -3,
diff --git a/jellyfish/parse_dna.hpp b/jellyfish/parse_dna.hpp
index 0435ae2..7ef8afd 100644
--- a/jellyfish/parse_dna.hpp
+++ b/jellyfish/parse_dna.hpp
@@ -46,7 +46,7 @@ namespace jellyfish {
* '\n': map to -2. ignore
* Other ASCII: map to -3. Skip to next line
*/
-static const uint_t codes[256];
+static const int codes[256];
static const uint_t CODE_RESET = -1;
static const uint_t CODE_IGNORE = -2;
static const uint_t CODE_COMMENT = -3;
@@ -55,7 +55,7 @@ namespace jellyfish {
static uint64_t mer_string_to_binary(const char *in, uint_t klen) {
uint64_t res = 0;
for(uint_t i = 0; i < klen; i++) {
-const uint_t c = parse_dna::codes[(uint_t)*in++];
+const int c = parse_dna::codes[(uint_t)*in++];
if(c & CODE_NOT_DNA)
return 0;
res = (res << 2) | c;
That said, assigning -3 to an unsigned int seems to be a pretty
conscious choice to me, so it might have been done on purpose to create
a wrap-around. Also, the same pattern shows up many other places (e.g.
parse_dna::CODE_RESET, parse_dna::CODE_IGNORE, ...). IMHO bad practice,
but plausible. Probably it's best to contact upstream about this and ask
what their original intention was.
Michael
--
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/4fa23929.3000...@gmail.com
Re: Bug#665354: RFS: viennacl/1.2.1-1
Dear mentors I am still looking for a sponsor for the upload of viennacl/1.2.1-1. My original sponsor, Michael Tautschnig, has not responded so far. Cheers Michael On 03/23/2012 11:42 AM, Michael Wild wrote: > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for my package "viennacl" > > * Package name: viennacl > Version : 1.2.1-1 > Upstream Author : Karl Rupp > * URL : http://viennacl.sf.net > * License : Expat (+other-KHRONOS) > Section : science > > It builds those binary packages: > > libviennacl-dev - Scientific computing library written in C++ based on > OpenCL > libviennacl-doc - ViennaCL API and user documentation > > To access further information about this package, please visit the > following URL: > > http://mentors.debian.net/package/viennacl > > > Alternatively, one can download the package with dget using this command: > > dget -x > http://mentors.debian.net/debian/pool/contrib/v/viennacl/viennacl_1.2.1-1.dsc > > More information about ViennaCL can be obtained from > http://viennacl.sf.net. > > Changes since the last upload: > > * New upstream version 1.2.1 > * Removed patches/*, everything fixed in new upstream > * Exclude editor backup file from dh_clean > * Don't auto-generate changelog anymore, upstream added it > * Remove get-orig-source target; upstream is clean > > Regards, > > > Michael Wild > > > -- 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/4f963fd5.2030...@gmail.com
Re: Bug#669585: RFS: bibtexconv/0.8.14-1 -- Looking for a Debian sponsor
Hi Thomas
In d/bibtexconv.install you are installing src/bibtexconv{,-odt}. I
don't understand that since they are already installed by the build system.
Also I'm not sure about overriding the compression of the example files.
Any decent text editor will display them correctly even if compressed,
and running `gunzip` is not really a major hurdle for users, especially
considering the audience this package is catering to.
Lastly I don't think you should be using the -k flag for the
dh_installchangelogs.
Cheers
Michael
On 04/20/2012 09:19 AM, Mathieu Malaterre wrote:
> Thomas,
>
> Couple of quick comments:
>
> * d/copyright does not contains copyrights for debian/* files. I
> found also suspicious that Copyright is "2010-2011 Thomas Dreibholz",
> shouldn't it be 2010-2012 ?
> * d/control lists an empty 'Recommends:'
> * d/rules I am not an autotools expert but I believe you want dh $@
> --with autotools_dev
>
> HTH
>
> On Fri, Apr 20, 2012 at 8:49 AM, Thomas Dreibholz
> wrote:
>> Package: sponsorship-requests
>> Severity: wishlist
>>
>> Dear mentors,
>>
>> I am looking for a sponsor for my package "bibtexconv". BibTeXConv is a
>> BibTeX
>> file converter which allows one to export BibTeX entries to other formats,
>> including customly defined text output. Furthermore, it provides the
>> possibility to check URLs (including MD5, size and MIME type computations)
>> and to verify ISBN and ISSN numbers. Examples are provided on the BibTeXConv
>> website at http://www.iem.uni-due.de/~dreibh/bibtexconv/index.html .
>>
>> * Package name: bibtexconv
>> Version : 0.8.14-1
>> Upstream Author : Thomas Dreibholz
>> * URL : http://www.iem.uni-due.de/~dreibh/bibtexconv/index.html
>> * License : GPL, version 3
>> Section : tex
>>
>> It builds those binary packages:
>>
>> bibtexconv - BibTeX Converter
>>
>> To access further information about this package, please visit the following
>> URL:
>>
>> http://mentors.debian.net/package/bibtexconv
>>
>>
>> Alternatively, one can download the package with dget using this command:
>>
>> dget -x
>> http://mentors.debian.net/debian/pool/main/b/bibtexconv/bibtexconv_0.8.14-1.dsc
>>
>> More information about bibtexconv can be obtained from http://www.iem.uni-
>> due.de/~dreibh/bibtexconv/.
>>
>>
>> Best regards,
>> Thomas Dreibholz
>
>
>
--
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/4f9127ea.9020...@users.sourceforge.net
Re: Debian-friendly upstream best practices?
On 03/28/2012 01:56 PM, Paul Wise wrote: [...] > > All the above is completely up to you as maintainer of the Debian packaging. > The only unpleasant side-effect I can think of is that git-dch will probably be a bit noisy. Haven't tried such a scheme myself, though, since my upstream doesn't have a public repository... Michael -- 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/4f730422.8070...@users.sourceforge.net
Bug#665354: RFS: viennacl/1.2.1-1
On 03/24/2012 02:40 PM, Paul Wise wrote: > On Fri, Mar 23, 2012 at 8:38 PM, Michael Wild wrote: > >> Oops, that's my mistake. No idea how that crept in, I'm pretty certain I >> don't have DMUA rights... Must have misunderstood the description of >> that field when I first created the control file. >> >> I will update the package at m.d.n ASAP. > > Both of the previous uploads had DMUA added. I wonder why Michael > Tautschnig uploaded the package to the archive in that state. DMUA > should never be added in the initial upload, only later and certainly > not on packages where the primary maintainer is not a DM. > Probably he missed it. Also Sylvestre Ledru had a look at the package (at least, for the last upload of version 1.2.0-1), and he also overlooked it. Michael -- 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/4f6dcf6f.5000...@users.sourceforge.net
Bug#665354: RFS: viennacl/1.2.1-1
On 03/23/2012 12:04 PM, Paul Wise wrote: > On Fri, Mar 23, 2012 at 6:42 PM, Michael Wild wrote: > >> I am looking for a sponsor for my package "viennacl" > > The package has DMUA on it, you should not need a sponsor. > Oops, that's my mistake. No idea how that crept in, I'm pretty certain I don't have DMUA rights... Must have misunderstood the description of that field when I first created the control file. I will update the package at m.d.n ASAP. -- 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/4f6c6ed4.9080...@users.sourceforge.net
Bug#665354: RFS: viennacl/1.2.1-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "viennacl" * Package name: viennacl Version : 1.2.1-1 Upstream Author : Karl Rupp * URL : http://viennacl.sf.net * License : Expat (+other-KHRONOS) Section : science It builds those binary packages: libviennacl-dev - Scientific computing library written in C++ based on OpenCL libviennacl-doc - ViennaCL API and user documentation To access further information about this package, please visit the following URL: http://mentors.debian.net/package/viennacl Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/contrib/v/viennacl/viennacl_1.2.1-1.dsc More information about ViennaCL can be obtained from http://viennacl.sf.net. Changes since the last upload: * New upstream version 1.2.1 * Removed patches/*, everything fixed in new upstream * Exclude editor backup file from dh_clean * Don't auto-generate changelog anymore, upstream added it * Remove get-orig-source target; upstream is clean Regards, Michael Wild -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJPbFOtAAoJEACl/dwsHZCQXlsP/0wvhD8t5jUJir7xae0yWzYk RojrZpEp5dhfL6lTpdxayu0iclU46VnP028mDH7owCV0AfC0icKwf5eMkFB9gym9 B8cs5QxsKi1q7s/pYpkEIj/cMGfFKbPANs9NvQIJAWUwS272bXhjTphMdmY9yUS9 03WyjlLhLNOCTbc04Qr8J8CAiG3qDqOwYYYwZtWhvMLcvB5+G8PdZR8vzS9VX8IT cUP1FkmXKGwK+ZO9o9HgrRaUa20nx0YtCk0Ux9Gc2aZrYLF+3nWjFhmTBQ7ezVtD SXQV0jjYqZ7mL3EM0U/R9orZs/kdpHPlRFYkcrPxrUavS/NbJ3MHI0pf3o9MTxBr mOUgRUX8wJm4b8LfYnYv8DY1rxJys9LLSqgfciZtg3w9Cn8uNHSu8LoY3oJQwRf3 oOMgWtWIfHiELoFvj9eb5PIU8ZRNRd9m/ZOSZVVRigsJafZv6uDQKa3Oxk8rRXUM TtH74LRxVHaRsW5KncC+3YqhLJDgmUYXiofOiBuPPeQ4Jrgo7ATIq5pfHGvOmlGy p0H5v75nAB0xBvb4Cc7UA0dBJ2SsZ7ph8wXJnlaf8Ck4vIGftFJQyVnJvHfddm8O C6pXHSSLpesv2TN5/Xt2GWK1yBL8l5VE5UVpfvKhTO4vhJqZ0sUsBrlMIUSPXnxG gCwXiGsWNxjwBlwyqtqc =NsGN -END PGP SIGNATURE- -- 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/4f6c53ad.6030...@users.sourceforge.net
Updating files list on packages.debian.org
Hi all My first package just made it into unstable. I and the upstream devs are pretty excited ;-) One thing we noticed, though, is that the file list at [1] is not available. Will it be automatically generated sometime in the near future, or do I have to do something to get it there? Thanks Michael [1] http://packages.debian.org/sid/all/libviennacl-dev/filelist -- 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/4e4b63f8.90...@users.sourceforge.net
Multiarch question
Hi all
I have a question concerning multiarch [1,2]. From what I read it is
conceivable to have something like this on a system:
/usr/{lib,include}/i386-linux-gnu
/usr/{lib,include}/x86_64-linux-gnu
/usr/{lib,include}/x86_64-kfreebsd-gnu
/usr/{lib,include}/sparc64-linux-gnu
Particularly, the case where both linux and kfreebsd directories are
present is of interest. How would one tell gcc to use the foreign kernel?
The background of this question is that at the moment Clang is
completely broken w.r.t. multiarch and I'm looking into fixing it.
Thanks for any hints
Michael
[1] http://wiki.debian.org/Multiarch
[2] https://wiki.ubuntu.com/MultiarchSpec)
--
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/4df09de8.3080...@users.sourceforge.net
Re: Upstream ChangeLog in PDF documentation
On 04/07/2011 10:46 AM, Paul Wise wrote: > Personally I would do one of the following, in decreasing order of > preference. You might find that whatever the PDF is built from is > easier to convert to plain text than the PDF itself. Check in the > Title/Producer/Creator fields of the PDF for some hints on what might > be the source code for the PDF. It's LaTeX, and I'm not sure it would be easier at all. > > Ask upstream to create plain text NEWS and ChangeLog files for their > next release. Will do. They also include a binary in their source distribution, so I will have to contact them anyways. > > Ignore the problem altogether. Naaahh... > > Create the files from the PDF in debian/rules build. No need for an > extra script nor a patch containing the results. > Can do, but then this will bloat the Build-Depends a bit... But probably, the cleanest solution. Thanks Michael -- 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/4d9d845f.9030...@gmail.com
Upstream ChangeLog in PDF documentation
Hi all I'm in the process of packaging a library that does not contain a ChangeLog file, but contains that information inside the user-guide which is either available as a PDF or the LaTeX source. Using some scripting (pdftotext, sed, asciidoc, lynx) I can extract a quite reasonable ChangeLog file from the PDF. Now, my question is: should I do this processing during the package build process, or is it OK if I maintain the script in debian/ and the generated ChangeLog as a patch? What would be preferred? Thanks for any advice. Michael -- 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/4d9d6688.50...@users.sourceforge.net
Re: dpkg-buildpackage -A vs make -f ./debian/rules build-indep
On 04.04.2011, at 11:40, Mathieu Malaterre
wrote:
> Dear all,
>
> I am trying to understand why dpkg-buildpackage -A is not simply
> calling make -f ./debian/rules build-indep. I tried turning
> DH_VERBOSE=1 but I do not see which rules imply runing the build-arch
> while I specifically tell dpkg-buildpackage to only run build-indep.
>
> Thanks
> --
> Mathieu
>
The problem is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=229357.
Essentially, the issue is that build-{arch,indep} are optional, and
there's no sane way for dpkg-buildpackage to determine whether they
exist or not, so it just calls the required build target. This issue has
been reported back in 2004, and still there is no consensus on how to
resolve it. Real bummer. (My original reply used much more creative
wording to describe the situation...)
Michael
--
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/4d99b6a2.9010...@gmail.com
Re: docs are generated on all build machines
On 04/02/2011 04:12 PM, The Fungi wrote: > On Sat, Apr 02, 2011 at 10:02:19AM -0400, Scott Howard wrote: >> I think his package is already Arch:all. > [...] > > Ahh, yes, I had missed the package name/source. I agree your > analysis sounds a far more likely scenario given the problem > description. Perfect, thanks for the pointers. I think I see the picture now. Michael -- 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/4d986227.7070...@gmail.com
Re: docs are generated on all build machines
On 04/01/2011 01:50 PM, Ben Finney wrote: > Michael Wild writes: > >> In my case, I would need to set different configure flags depending on >> whether the documentation should be built or not since the default >> target also builds the docs if enabled. > > Under what conditions should the documentation not be built? I'd like the docs only to be built *once* on the build server, not for every architecture, since they are architecture independent and building them for every architecture would waste hours of time. > >> I would like to avoid building the docs (as opposed to just not >> building the package), since it is a pretty lengthy process. > > You can patch the upstream build system to disable building parts that > you don't want to put into Debian. > > But perhaps you mean something else. > Yes, sorry about the unclear message. Michael -- 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/4d96dca5.6070...@gmail.com
Re: docs are generated on all build machines
On 04/01/2011 12:50 AM, Ben Finney wrote: > Mathieu Malaterre writes: > >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=619654 >> >> It says that I am building the doc package on all buildd machine, >> while I should not. I do not understand how i can achieve a portable >> solution. > > The bug report tells you what needs to be done: specify the build > targets correctly. > >> How do i detect that I am on a buildd machine and I should not rebuild >> the doc package ? > > That's not what is being requested; rather, your package should specify > that it doesn't need to be built on all architectures (and hence not on > all the buildd architectures). > Sorry for hijacking this thread, but I have a question very much related to this issue. I'm fairly new to packaging and just filed my first ITP, and was wondering about this problem too. In my case, I would need to set different configure flags depending on whether the documentation should be built or not since the default target also builds the docs if enabled. I would like to avoid building the docs (as opposed to just not building the package), since it is a pretty lengthy process. How would I achieve that? Separate build trees? Or moving the configure step into the various build steps, and just reconfigure every time? Thanks Michael -- 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/4d955d7f.1030...@gmail.com
