Bug#796395: RFS: rolldice/1.14-1 ITA
Hi, I've uploaded a new version to mentors fixing all the problems described above/below. Thanks, Thomas. On 22/08/15 02:40 AM, Gianfranco Costamagna wrote: Did you mean to close the bug? nope, sorry About the dep5 copyright issue, yes, I accidentally left out the header. no problem I will fix the use-flag patch as you described. ok (this shouldn't change anything, since LDFLAGS in this case are the Debian flags, and for sure they do not add libraries to link, so the risk of stripping them is 0) About the man page, the reason I didn't have it be installed by dh_manpages is the man page is edited in the Makefile, adding the version number (see make target 'man'). Should I add the version number myself and have it be installed by dh? nope, it is good that way, just I really do not like custom Makefiles :) Would you add a cmake file if I provide one to you? cheers, G. signature.asc Description: OpenPGP digital signature
Re: Questions before my first upload attempt
Hi,
i worked a bit more on my local libburn package.
Shall/can i replace my yesterday upload by help of dput -f ?
Regarding http://mentors.debian.net/package/libburn ,
i have hoepfully solved the complaints under
Package closes bugs in a wrong way
- Bugs #702621 and #746254 got reassigned to libburn4.
- Closes: #751501 was moved from libburn changelog to libisofs
changelog.
(Good catch. Is this check available locally before upload ?)
The failure of debuild -b with compat 9 still riddles me.
With 9 it finally complains
dh_install: libburn4 missing files (debian/tmp/usr/lib/libburn.so.4*),
aborting
It seems to have outsmarted itself by previous
./configure ... --libdir=\${prefix}/lib/x86_64-linux-gnu ...
With 8, the configure option --libdir is not used.
After debuild -b with compat 9 i have:
$ ls debian/tmp/usr/lib
x86_64-linux-gnu
$ ls debian/tmp/usr/lib/x86_64-linux-gnu
libburn.a libburn.la libburn.so libburn.so.4 libburn.so.4.93.0 pkgconfig
The complete ./configure line of 8 is:
./configure --build=x86_64-linux-gnu --prefix=/usr
--includedir=\${prefix}/include --mandir=\${prefix}/share/man
--infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var
--disable-silent-rules --libexecdir=\${prefix}/lib/libburn
--disable-maintainer-mode --disable-dependency-tracking
Of 9:
./configure --build=x86_64-linux-gnu --prefix=/usr
--includedir=\${prefix}/include --mandir=\${prefix}/share/man
--infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var
--disable-silent-rules --libdir=\${prefix}/lib/x86_64-linux-gnu
--libexecdir=\${prefix}/lib/x86_64-linux-gnu --disable-maintainer-mode
--disable-dependency-tracking
Do i have to make a kindof cleanup when switching from
compat 8 to 9 ?
Have a nice day :)
Thomas
Bug#796043: marked as done (RFS: clblas/2.6-2)
Your message dated Sun, 23 Aug 2015 11:59:42 +0200
with message-id 20150823095942.ga3...@synchrotron-soleil.fr
and subject line done
has caused the Debian Bug report #796043,
regarding RFS: clblas/2.6-2
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
796043: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796043
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
---BeginMessage---
Package: sponsorship-requests
Severity: normal
Dear mentors,
I am looking for a sponsor for my package clblas
* Package name: clblas
Version : 2.6-2
Upstream Author : Advanced Micro Devices, Inc.
* URL : https://github.com/clMathLibraries/clBLAS
* License : Apache version 2
Section : science
It builds those binary packages:
libclblas-bin - OpenCL BLAS library (executables)
libclblas-dev - OpenCL BLAS library (development files)
libclblas-doc - OpenCL BLAS library (documentation)
libclblas2 - OpenCL BLAS library (shared library)
libclblas2-dbg - OpenCL BLAS library (debugging symbols)
To access further information about this package, please visit the
following URL:
http://mentors.debian.net/package/clblas
Alternatively, one can download the package with dget using this command:
dget -x http://mentors.debian.net/debian/pool/main/c/clblas/clblas_2.6-2.dsc
Changes since the last upload:
* d/control: remove ${shlibs:Depends} substitution from debug package
* d/*-dev.install: use more generic expressions
* d/rules: use stricter hardening
* d/p: add patch to use Boost dynamic libraries
* d/p: add patch fixing missing inclusion of stdlib
Best regards,
Ghislain Vaillant
---End Message---
---BeginMessage---
done---End Message---
Re: Questions before my first upload attempt
Hi, i was able to fix debuild -b with compat 9 by changing the content of debian/libburn4.install from debian/tmp/usr/lib/libburn.so.4* usr/lib to debian/tmp/usr/lib/x86_64-linux-gnu/libburn.so.4* usr/lib/x86_64-linux-gnu Next i wanted to ask: Is this remedy a valid solution ? But now i see that Niels Thykier wrote: If your package is simple, you can use: usr/lib/*/file instead of usr/lib/file Duh. Of course there's not only amd64 in the world. (At least i did find the right files on my own.) So this in libburn4.install: debian/tmp/usr/lib/*/libburn.so.4* and in libburn-dev.install: debian/tmp/usr/include/libburn/libburn.h debian/tmp/usr/lib/*/libburn*.a debian/tmp/usr/lib/*/libburn.so debian/tmp/usr/lib/*/pkgconfig/libburn-1.pc Works fine on amd64. = Remaining questions: - Shall i dput -f now ? - What to do about the complaint: The uploader is not in the package's Maintainer or Uploaders fields Add myself to Uploaders ? Am i entitled ? = New question: I would like to add an argument buildstamped to the make run of libisoburn. Where to read about how to achieve this ? - Have a nice day :) Thomas
Re: Questions before my first upload attempt
On 2015-08-23 12:48, Thomas Schmitt wrote:
Hi,
Hi Thomas,
i worked a bit more on my local libburn package.
[...]
The failure of debuild -b with compat 9 still riddles me.
With 9 it finally complains
dh_install: libburn4 missing files (debian/tmp/usr/lib/libburn.so.4*),
aborting
It seems to have outsmarted itself by previous
./configure ... --libdir=\${prefix}/lib/x86_64-linux-gnu ...
With 8, the configure option --libdir is not used.
After debuild -b with compat 9 i have:
$ ls debian/tmp/usr/lib
x86_64-linux-gnu
$ ls debian/tmp/usr/lib/x86_64-linux-gnu
libburn.a libburn.la libburn.so libburn.so.4 libburn.so.4.93.0
pkgconfig
Yes, this is caused by bumping to compat 9. Please have a look at:
man 7 debhelper
Which (among other things) will list:
COMPATIBILITY LEVELS
[...]
v9 This is the recommended mode of operation.
Changes from v8 are:
- Multiarch support. In particular, dh_auto_configure
passes multiarch directories to autoconf in --libdir
and --libexecdir.
If your package is simple, you can use:
usr/lib/*/file
instead of
usr/lib/file
Alternatively, please consider using dh-exec. This requires three steps:
Add dh-exec to Build-Depends
Insert #!/usr/bin/dh-exec in the top of debian/package.install
chmod a+x debian/package.install
Note this only works in compat 9 and later
Thanks,
~Niels
Re: Questions before my first upload attempt
On 2015-08-23 16:08, Thomas Schmitt wrote: Remaining questions: - Shall i dput -f now ? Yes. I don't know if you have to remove the package first (eg via the web interface). Can someone more familiar with mentors.debian.net add some enlightenment here? - What to do about the complaint: The uploader is not in the package's Maintainer or Uploaders fields Add myself to Uploaders ? Am i entitled ? Orphaning a package means that there is no maintainer anymore; therefore, you would normally set yourself as Maintainer. However: it appears that this package is team-maintained. In that case, you leave the Maintainer as-is, and add yourself to Uploaders. There's an alioth [1] project, with mailing list and all: https://alioth.debian.org/projects/pkg-libburnia/ As you can see, there are a number of committers there, and the current Uploaders field of the package lists one of them. IMHO, taking over this package correctly would mean to also take over the alioth project as admin by 1. Requesting to join the team 2. Having the current admin set your new account as admin 3. Removing the old admin Once you have completed the above, add yourself to Uploaders. Then, add an entry to debian/changelog, such as: * Add myself to Uploaders. Closes: #XX The XX refers to the bug number with which the package was orphaned, and which you still need to retitle and of which you still need to claim ownership :-) Alternatively, if you no longer wish to team-maintain it, and if the remaining uploader is OK with this, you could set yourself to Maintainer, remove the Uploaders, and add the following entry to debian/changelog: * New Maintainer. Closes: #XX However, you should then get the alioth project removed, to avoid confusion. [1] https://wiki.debian.org/Alioth
how to use pbuilder without .dsc files?
Hi, I am using pbuilder for the first time and I was wondering: How does one build a package in pbuilder if they haven't generated .dsc files? I am trying to build a package on my stable system that has dependencies which are only satisfiable in sid. I have not built this particular version yet, so there are no .dsc or .changes files. what should I do? Thanks, --Shawn
Re: how to use pbuilder without .dsc files?
Hi Shawn, On Sun, Aug 23, 2015 at 5:07 PM, Shawn Sörbom sh...@sorbom.com wrote: Hi, I am using pbuilder for the first time and I was wondering: How does one build a package in pbuilder if they haven't generated .dsc files? I am trying to build a package on my stable system that has dependencies which are only satisfiable in sid. I have not built this particular version yet, so there are no .dsc or .changes files. what should I do? Use pdebuild from within your unpacked source directory. Alternatively, use debuild -S to generate a source package, then pass the .dsc file to pbuilder. Regards, Vincent
Bug#795771: RFS: dblatex/0.3.7-1
control: retitle RFS: dblatex/0.3.7-2 Gianfranco Costamagna costamagnagianfra...@yahoo.it wrote: Hi Gianfranco, thanks again for your review. I have uploaded dblatex-0.3.7-2 to mentors: http://mentors.debian.net/package/dblatex Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/d/dblatex/dblatex_0.3.= 7-1.dsc Regarding your findings: let's review: 1) please use a machine-readable copyright file Sorry to disagree with your first suggestion (terrible start, I know): Using a machine-readable copyright file is optional according to section 12.5.1 of the Debian Policy Manual. In contrast to this idea I prefer to keep as close to the upstream copyright file as possible, thus simply diffing the upstream with the Debian file is enough to keep the latter synchronized with the former. http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ 2) d/compat: please bump to 9 Happy to comply, done. 3) d/control: you might want to run wrap-and-sort to clean the formatting= up, to bump debhelper to =3D9 and to remove some already satisfied in oldsta= ble version constraints. Thanks for pointing me to wrap-and-sort, it's a nice tool. Done. 4) d/rules: please prepend comments in overrides with a tab instead of = spaces (vim is really showing them in a bad way) That means sending the comments to the shell for evaluation, which is superfluous (although it does no harm). When doing so, the lines look bad in emacs, as they are marked in warning style (that is pink background with my color scheme). The reason for the warning as found in make-mode.el.gz: ;; Highlight shell comments that Make treats as commands, ;; since these can fool people. Anyway, I'm happy to comply and have changed according to your suggestion. 5) d/rules: I do not see the reason for get-orig-source target. if uscan works, what is the pourpose of it? I have moved the retrieval of the examples tarball to the watch file and eliminated the get-orig-source target and all related stuff. Indeed this simplifies the rules file remarkably. 6) d/rules: examples should belong to dh_installexamples not to dh_instal= ldocs (unless I'm missing something) You're right, done. 7) d/rules: I would add something like --buildsystem=3Dpybuild to the d= efault dh call. Done. 8) if the examples are the reason for the get-orig-source target, and if = upstream ships them in a different source tarball, please then consider a package split Here I disagree again: dblatex-examples.tar.bz2 has been uploaded one time (in 2009) to SourceForge and hasn't changed since then, the archive is not versioned at all. Thus IMHO it's overkill to use a separate package for this small, static add-on. 9) d/rules: mv debian/dblatex/usr/share/doc/dblatex/xhtml debian/dblatex/= usr/share/doc/dblatex/html it is nice to current don't break existing installations, but I would ins= tead create a symlink, rather than breaking the new installations (assuming some users might hav= e compiled the documentation on their own. man dh_link might be useful there Good idea, done. would you mind fixing the above? As you see, I've been happy to implement many of your findings, however I disagree with your vote on the machine-readable copyright file and on the package split. I hope that you will nevertheless consider to sponsor this upload, although I would also understand if you forbear From=20sponsoring as you don't agree with my packaging decisions. However you decide, thank you honestly for your review time and for your valuable feedback, I have enjoyed improving dblatex's packaging. Regards, Andreas -- Andreas Hoenen andr...@hoenen-terstappen.de GPG: 1024D/B888D2CE A4A6 E8B5 593A E89B 496B 82F0 728D 8B7E B888 D2CE signature.asc Description: PGP signature
