Bug#788418: Now resuming the packaging
Hi Gianfranco, Always a pleasure to have you as my reviewer for this package. I will fix your comments during the week. I will also take this opportunity to apply a few of the improvement you suggested on other reviews. So more work is needed, such as: - *not* to use a custom symlink for jquery on doxygen generated HTML docs, - split -arch and -indep targets, this package fits this requirement very nicely, - apply stricter hardening. Most of which I have already completed. Could you expand on the comment wrt the transition slot? This is something I am not familiar with. Many thanks, Ghis
Bug#792144: marked as done (RFS: cunit/2.1-3-dfsg-1 -- Unit Testing Library for C [ITA])
Your message dated Tue, 13 Oct 2015 08:19:23 + (UTC) with message-id <185683049.4291184.1444724364041.javamail.ya...@mail.yahoo.com> and subject line Re: Bug#792144: RFS: cunit/2.1-2.dfsg-3 -- Unit Testing Library for C [ITA] has caused the Debian Bug report #792144, regarding RFS: cunit/2.1-3-dfsg-1 -- Unit Testing Library for C [ITA] to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 792144: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792144 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "cunit" Package name: cunit Version : 2.1-2.dfsg-3 Upstream Author : Jerry St.Clair Anil Kumar URL : http://cunit.sourceforge.net/ License : LGPL-2.0+ Section : libs It builds those binary packages: libcunit1 - Unit Testing Library for C ibcunit1-dev - Unit Testing Library for C -- development files ibcunit1-doc - Unit Testing Library for C -- documentation ibcunit1-ncurses - Unit Testing Library for C (ncurses) ibcunit1-ncurses-dev - Unit Testing Library for C (ncurses) -- development files To access further information about this package, please visit the following URL: http://mentors.debian.net/package/cunit Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/c/cunit/cunit_2.1-2.dfsg-3.dsc More information about hello can be obtained from http://www.example.com. Changes since the last upload: * New maintainer. (Closes: #763096). * Fix pkg-config file is broken (Closes: #782366). * Bump Standards version to 3.9.6 * Bump debhelper to version 9 * Migrate to git * copyright: link to [L]GPL-2 instead of versionless [L]GPL * copyright: migrate to DEP-5 (machine-readable debian/copyright file) Regards, Azat Khuzhin --- End Message --- --- Begin Message --- Built&Signed&Uploaded, thanks for your contribution to Debian! cheers, G. Il Lunedì 12 Ottobre 2015 22:24, Azat Khuzhin ha scritto: On Mon, Oct 12, 2015 at 02:28:13PM +, Gianfranco Costamagna wrote: > Hi Azat, > > > last thing: can you please fix the autopkgtestsuite? > http://debomatic-amd64.debian.net/distribution#unstable/cunit/2.1-3-dfsg-1/autopkgtest > > seems that it is not finding the correct header file... > > thanks a lot! > > (this should be the last showstopper) Hi Gianfranco, Fixed and uploaded to mentors, thanks! (P.S. I've added autopkgtest to postbuild, along with lintian)--- End Message ---
Bug#788418: Now resuming the packaging
Hi, you should open a bug against release.debian.org https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=release.debian@packages.debian.org;tag=transition and ask for a transition slot test if the reverse dependencies still build fine https://release.debian.org/transitions/html/auto-nfft.html (maybe you have some other dependencies, please look at apt-cache rdepends library reverse-depends -b src:package outputs) cheers, G. Il Martedì 13 Ottobre 2015 9:42, Ghislain Vaillant ha scritto: Hi Gianfranco, Always a pleasure to have you as my reviewer for this package. I will fix your comments during the week. I will also take this opportunity to apply a few of the improvement you suggested on other reviews. So more work is needed, such as: - *not* to use a custom symlink for jquery on doxygen generated HTML docs, - split -arch and -indep targets, this package fits this requirement very nicely, - apply stricter hardening. Most of which I have already completed. Could you expand on the comment wrt the transition slot? This is something I am not familiar with. Many thanks, Ghis
Bug#788418: Now resuming the packaging
On Tue, Oct 13, 2015 at 08:57:27AM +, Gianfranco Costamagna wrote: > Hi, > > you should open a bug against release.debian.org > > https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=release.debian@packages.debian.org;tag=transition > > and ask for a transition slot > > test if the reverse dependencies still build fine > https://release.debian.org/transitions/html/auto-nfft.html > (maybe you have some other dependencies, please look at > apt-cache rdepends library > reverse-depends -b src:package > outputs) More at https://wiki.debian.org/Teams/ReleaseTeam/Transitions -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: http://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Architecture field based on another package Architecture field
Dear all,
I have a package (nfft) which builds a few binary packages. These binary
packages correspond to a build of the same library but for different
floating precisions (single, double, long-double).
For the long-double build, nfft requires the long-double version of fftw
which is not available for all architectures. Since the other
precisions are not affected, only the long-double version of the library
should have a restricted set of architectures via the Architecture field
in d/control.
Is there a way to simply tell the Architecture field of this binary
package (libnfft3-long2) that it should use the same architectures as
the libfftw3-long3 ? Something like:
Architecture: ${libfftw3-long3:Architecture}
maybe?
Or do I need to list them all manually?
Same question for d/rules, can I somehow query all the architectures
supported by libfftw3-long3 during the build (via dpkg?), so I can use
this list to restrict the build process of the long-double precision.
Many thanks,
Ghis
Bug#788418: Now resuming the packaging
On 13/10/15 10:33, Mattia Rizzolo wrote: On Tue, Oct 13, 2015 at 08:57:27AM +, Gianfranco Costamagna wrote: Hi, you should open a bug against release.debian.org https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=release.debian@packages.debian.org;tag=transition and ask for a transition slot test if the reverse dependencies still build fine https://release.debian.org/transitions/html/auto-nfft.html (maybe you have some other dependencies, please look at apt-cache rdepends library reverse-depends -b src:package outputs) More at https://wiki.debian.org/Teams/ReleaseTeam/Transitions According to Mattia's link, I should be in step 1 of the recommended workflow: "Upload your new version to experimental (and have it clear NEW)" Requesting a transition slot happens way further the line it seems, or am I missing something? Ghis
Bug#788418: Now resuming the packaging
Hi Ghislain, >"Upload your new version to experimental (and have it clear NEW)" > >Requesting a transition slot happens way further the line it seems, or >am I missing something? yes, you set target experimental, clear new queue and ask the slot. cheers, G.
Re: Architecture field based on another package Architecture field
Ghislain Vaillant writes:
> Architecture: ${libfftw3-long3:Architecture}
Alas, this won't work -- that information isn't available here, and I
don't think substitutions work in the Architecture field anyway.
However, debian/rules can conditionally invoke dh with a suitable -N
flag. I believe it should work to specify
ifeq "" "$(wildcard $(libdir)/libfftw3l.so)"
SKIP_NFFTL = -Nlibnfft3-long2
endif
%:
dh $@ --parallel --with autoreconf \
--dbg-package=libnfft3-dbg $(SKIP_NFFTL)
and then conditionalize other commands involving the nfftl tree on
ifneq "" "$(SKIP_NFTL)"
I am testing these changes now (against a checkout of your experimental
branch) and will follow up with a full patch if they work.
Good question!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Re: Architecture field based on another package Architecture field
"Aaron M. Ucko" writes: > I am testing these changes now (against a checkout of your experimental > branch) and will follow up with a full patch if they work. I meant $(shell dpkg-architecture -qDEB_HOST_MULTIARCH) and ifeq "" "$(SKIP_NFFTL)" Having fixed those typos, I produced the attached patch, which works for me. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu diff --git a/debian/rules b/debian/rules index e069e78..18a23c5 100755 --- a/debian/rules +++ b/debian/rules @@ -2,9 +2,15 @@ DH_VERBOSE = 1 +libdir := /usr/lib/$(shell dpkg-architecture -qDEB_HOST_MULTIARCH) + +ifeq "" "$(wildcard $(libdir)/libfftw3l.so)" +SKIP_NFFTL = -Nlibnfft3-long2 +endif + %: dh $@ --parallel --with autoreconf \ - --dbg-package=libnfft3-dbg + --dbg-package=libnfft3-dbg $(SKIP_NFFTL) override_dh_auto_configure: sh ./bootstrap.sh @@ -23,6 +29,7 @@ override_dh_auto_configure: --enable-single \ --program-suffix=f \ --disable-doxygen-doc +ifeq "" "$(SKIP_NFFTL)" dh_auto_configure --builddirectory=nfftl -- \ --disable-static \ --enable-all \ @@ -32,25 +39,32 @@ override_dh_auto_configure: --enable-long-double \ --program-suffix=l \ --disable-doxygen-doc +endif override_dh_auto_build: dh_auto_build --builddirectory=nfft dh_auto_build --builddirectory=nfftf +ifeq "" "$(SKIP_NFFTL)" dh_auto_build --builddirectory=nfftl +endif # make documentation in nfft build tree cd $(CURDIR)/nfft && make doc override_dh_auto_clean: dh_auto_clean --builddirectory=nfft dh_auto_clean --builddirectory=nfftf +ifeq "" "$(SKIP_NFFTL)" dh_auto_clean --builddirectory=nfftl +endif # clean main tree #dh_auto_clean --builddirectory=$(CURDIR) override_dh_auto_install-arch: dh_auto_install --builddirectory=nfft --package=libnfft3-double2 dh_auto_install --builddirectory=nfftf --package=libnfft3-single2 +ifeq "" "$(SKIP_NFFTL)" dh_auto_install --builddirectory=nfftl --package=libnfft3-long2 +endif override_dh_auto_test: dh_auto_test --builddirectory=nfft
Re: Architecture field based on another package Architecture field
On 13/10/15 17:15, Aaron M. Ucko wrote: "Aaron M. Ucko" writes: I am testing these changes now (against a checkout of your experimental branch) and will follow up with a full patch if they work. I meant $(shell dpkg-architecture -qDEB_HOST_MULTIARCH) and ifeq "" "$(SKIP_NFFTL)" Having fixed those typos, I produced the attached patch, which works for me. So the final solution is to manually list all supported architectures in d/control (same one as libfftw3-double3) and use your patch for d/rules? Ghis
Bug#801703: RFS: eclipse-titan/5.3-1 [ITP]
Package: sponsorship-requests Severity: normal Dear Mentors, I am looking for a sponsor for my package "eclipse-titan": Package name: eclipse-titan Version : 5.3-1 Upstream Author : Eclipse Foundation URL : www.eclipse.org License : Eclipse Public License - v 1.0 Section : utils It builds this binary package: eclipse-titan TTCN-3 is a standardized, modular language specifically designed for testing. Eclipse Titan offers a free and open source (FOSS) compiler both for TTCN-3 and for ASN.1 (Abstract Syntax Notation One). You can download the package with wget using this command: wget https://www.dropbox.com/s/qkzdjefpp2ura11/eclipse-titan_5.3.tar.gz More information about eclipse-titan can be obtained from https://github.com/eclipse/titan.core This is the first upload so there isn’t any changelog. Best Regards, Gergely Pilisi -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.0.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#786795: marked as done (RFS: dhcp-probe/1.3.0-11 -- network DHCP or BootP server discover)
Your message dated Tue, 13 Oct 2015 16:26:41 + with message-id and subject line closing RFS: dhcp-probe/1.3.0-11 -- network DHCP or BootP server discover has caused the Debian Bug report #786795, regarding RFS: dhcp-probe/1.3.0-11 -- network DHCP or BootP server discover 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.) -- 786795: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786795 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "dhcp-probe" * Package name: dhcp-probe Version : 1.3.0-11 Upstream Author : Irwin Tillman * URL : http://www.net.princeton.edu/software/dhcp_probe/ * License : Debian packaging is GPL-2 Section : net It builds those binary packages: dhcp-probe - network DHCP or BootP server discover To access further information about this package, please visit the following URL: http://mentors.debian.net/package/dhcp-probe Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/d/dhcp-probe/dhcp-probe_1.3.0-11.dsc More information about dhcp-probe can be obtained from http://www.net.princeton.edu/software/dhcp_probe/, Changes since the last upload: dhcp-probe (1.3.0-11) unstable; urgency=low * Upgrade to 3.9.6 Debian policy, * Fix startup depencies to suite LSB3.1, * Fix hardening options, * Fix deleted conffiles not purged from ucf (closes: #661795). -- Laurent Guignard Mon, 20 Apr 2015 11:13:17 +0200 Regards, Laurent Guignard --- End Message --- --- Begin Message --- Package dhcp-probe has been removed from mentors.--- End Message ---
Bug#801703: RFS: eclipse-titan/5.3-1 [ITP]
Control: tags -1 moreinfo Hi, I won't sponsor the package, but I'm sure you will find a sponsor on pkg-java, that is the best place to look for a sponsor http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers some issues: please open an ITP bug, please upload the sources on mentors.debian.net, and then fix the lintian warnings/errors that will show up (e.g. standard version and similar). after that a sponsor I guess will help you :) cheers, G. Il Martedì 13 Ottobre 2015 18:33, Gergely Pilisi ha scritto: Package: sponsorship-requests Severity: normal Dear Mentors, I am looking for a sponsor for my package "eclipse-titan": Package name: eclipse-titan Version : 5.3-1 Upstream Author : Eclipse Foundation URL : www.eclipse.org License : Eclipse Public License - v 1.0 Section : utils It builds this binary package: eclipse-titan TTCN-3 is a standardized, modular language specifically designed for testing. Eclipse Titan offers a free and open source (FOSS) compiler both for TTCN-3 and for ASN.1 (Abstract Syntax Notation One). You can download the package with wget using this command: wget https://www.dropbox.com/s/qkzdjefpp2ura11/eclipse-titan_5.3.tar.gz More information about eclipse-titan can be obtained from https://github.com/eclipse/titan.core This is the first upload so there isn’t any changelog. Best Regards, Gergely Pilisi -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.0.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Re: Architecture field based on another package Architecture field
Ghislain Vaillant writes: > So the final solution is to manually list all supported architectures > in d/control (same one as libfftw3-double3) and use your patch for > d/rules? You can leave Architecture: any in d/control; dpkg-genchanges will warn about the discrepancy, but proceed anyway. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#790412: RFS: circus/0.12.0-1
Control: owner -1 ! Hi David quick review: 1) control: runtime dependencies: please let python:Depends to its job I see in setup.py install_requires = ['iowait', 'psutil', 'pyzmq>=13.1.0', 'tornado>=3.0'] (also: why some dependencies are not listed here?) 2) rules/control: please consider using python3 3) rules: - why you remove examples from build? - "make -C docs" I would use $(MAKE) -C docs the other stuff looks good, but I didn't check carefully yet :) (and I didn't try a build&run) cheers, G.
Bug#787861: review: polyml
Control: owner -1 ! Control: tags -1 moreinfo Hi James, 1) please join the debian-science team and ask them an ack for the upload 2) please convert in team upload the package 3) please close 561763 in the changelog 4) please merge the two changelogs together 5) please remove rules.old 6) the polyml.install shouldn't have the static library, right? 7) "i386 sparc powerpc amd64 armel armhf" do you have any reason for not trying to build on "any"? 8) did you test reverse dependencies? apt-cache rdepends package reverse-depends -b src:package can give you some hints 9) licensecheck * -r shows many licenses not LGPL-2.1+ 10) debian/menu please remove (menu is deprecated since a month or two) 11) usr/share/man/man1/poly.1* usr/share/man/man1/polyc.1* usr/share/man/man1/polyimport.1* they belong to dh_installmanpages, not dh_install the other stuff might look good, I still need to check a build&run of the package. cheers, G. Il Mercoledì 7 Ottobre 2015 12:21, James Clarke ha scritto: Hi, I believe I have addressed the changes you mentioned in http://mentors.debian.net/debian/pool/main/p/polyml/polyml_5.5.2-0.2.dsc, and would be grateful if you could please review it. Thanks, James > On 6 Oct 2015, at 10:54, James Clarke wrote: > > Firstly sorry for not replying, I hadn’t subscribed to the bug so I was never > emailed a copy of your message. > > I figured it wasn’t really common to have NMUs like this, but given the fact > that the package is not orphaned but its maintainers have not replied to bug > reports, I thought this was one of the few options; I don’t really care how > the newer versions are uploaded, so long as they get uploaded eventually! > > As far as I can tell from `apt-cache depends`, nothing outside of the polyml > source package depends on any of the binary packages in it. > > 1) makes sense to go via experimental > 2,3,4) I shall see what I can do > > In case you couldn’t tell I’m very new to this, so thanks for taking the time > to go through the details. > > Thanks, > James > >> On 25 Sep 2015, at 17:32, Gianfranco Costamagna >> wrote: >> >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA256 >> >> Hi, this is really too much for an NMU. >> >> Did you test reverse dependencies? >> >> you are bumping shlibs, so you need to be sure to have requested a >> transition slot on release.debian.org (use reportbug against it to ask >> one). >> >> I would do rather a team upload instead, and I would appreciate: >> >> 1) an upload to experimental to test rebuilds >> 2) converting to dh format >> 3) use of autoreconf instead of autotools-dev >> 4) convert to multiarch? >> >> I can check the other things later if you still are interested. >> >> cheers, >> >> G. >> -BEGIN PGP SIGNATURE- >> Version: GnuPG v2 >> >> iQIcBAEBCAAGBQJWBXcZAAoJEPNPCXROn13Z3roP/2GHZv1CWdA2K4/74IfvY3/+ >> vfCcXVKLp31bgaa41tTvV2oV2dSbAiTlqSUwnZFJygFaqp6eXuweVVPdf0cT5IfV >> ZTG3w3n0JcK/u/cgu0nvHm6Cy/ENb9LD/YIRJ7ZTI8u5AiiVpGGAc+WY0j9150Bc >> NyWYw8HMFxav3tR6vPjh0R2I1QgN7WjHbZLmgIqlaJbZgjqMu1O4lYzhfn/wL3ub >> LcJYCHk0BI5pB48ABfx7fLs0DrvOaEoQ63l5mM1uX6BgpAiXdAQSY5qE5enUSH6a >> Aq60l7E3DxeKERUnTuGMRj3529abSDRxteAMMTP2IlXoKYV2h5XHCJlLmbjunKV1 >> KDAqwoZGQpia81jM6hKdZbbbOZfpzzevW14yj2x0qYQEVyMv+7lSDP6p1o7VHYyL >> zSNKGzquIGcCeTkDQ1pTeuYm3HPsuIjmXD1saG2qInE6F9ccie0n8AT8WEInGGMd >> UHcBu/cHhyyBiThUcZhgQEuU+Pf1kRy0f9SbPTibFtlvKf3HOgB2DD018WK7JFBB >> rF46I2Jr4V5TbHh3nmPhJhk46MFjDyxfOW9rE60jpeJcopMoK6xBUTBlM1mwQrud >> JGrjUztjgDd8BX+/LDzr4IZXPc67LcQghrYAUOgzNhe/jAI9gnsp0JTi7rwaEN82 >> hm7eOneGezYiwC18gEFH >> =tPZ/ >> -END PGP SIGNATURE- >> >
Bug#801711: RFS: osmo-trx/0~20150325gitf147b17+dfsg-1 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "osmo-trx" * Package name: osmo-trx Version : 0~20150325gitf147b17+dfsg-1 Upstream Author : Osmocom * URL : http://openbsc.osmocom.org/trac/wiki/OsmoTRX * License : AGPL-3+ Section : utils It builds those binary packages: osmo-trx - SDR transceiver that implements Layer 1 of a GSM BTS To access further information about this package, please visit the following URL: http://mentors.debian.net/package/osmo-trx Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/o/osmo-trx/osmo-trx_0~20150325gitf147b17+dfsg-1.dsc More information about osmo-trx can be obtained from http://openbsc.osmocom.org/trac/wiki/OsmoTRX Changes since the last upload: Initial release (Closes: #777303) Regards, Ruben Undheim
Re: Architecture field based on another package Architecture field
On 13/10/15 18:08, Aaron M. Ucko wrote: Ghislain Vaillant writes: So the final solution is to manually list all supported architectures in d/control (same one as libfftw3-double3) and use your patch for d/rules? You can leave Architecture: any in d/control; dpkg-genchanges will warn about the discrepancy, but proceed anyway. Successfully tested on my end too. Many thanks for your help on this. Cheers, Ghis
Bug#784898: RFS: duperemove/0.10-1 [ITP]
Hi, is there now anything missing for getting duperemove into Debian?
Detecting stray writes in cowbuilder
I've just had a FTBFS bug on a new upload caused by a debian/rules bug where I was running upstream's make install twice, once without setting PREFIX. This was causing the package to be installed to $HOME as will as to ./debian/tmp. This worked while doing the packaging, because it was silently getting installed in my home directory; and it worked in cowbuilder, because it was silently getting installed in the build's home directory and then discarded; but it was failing on the build servers because the build server's $HOME is read-only. Is there a way to make cowbuilder detect writes to places that shouldn't be written to so this doesn't happen again in the future? -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─ │ "There is nothing in the world so dangerous --- and I mean *nothing* │ --- as a children's story that happens to be true." --- Master Li Kao, │ _The Bridge of Birds_ signature.asc Description: OpenPGP digital signature
Bug#745126: RFS: passwordsafe/0.95.1+dfsg-1
Am Samstag, den 10.10.2015, 20:44 -0400 schrieb Bill Blough: > On Fri, Sep 25, 2015 at 10:38:14PM +0200, Tobias Frost wrote: > > > Issues with the translation files - When the .mo files get > > > generated, > > > the .po files get updated with a new timestamp, causing repeat > > > builds from > > > the same source to fail the dpkg-source check. > > > > That's ugly and I guess should be patched away... > > Probably you want to patch in a way that the po files are not > > updated: > > Those files are supposed to be sent to translators and the use to > > update them during build is limited. > > > > (I missed that additional note before: You should never use diff > > -ignore; if it'd be extend-diff-ignore (see dpkg-source(1)); > > otherwise > > e.g changes in the git repository will also break the build.) > > > > And as I saw a reference to the build date in one of the po's: > > To make the reproducible builds happen, those should be eliminated. > > (To find them, add temporarily -Werror=date-time to your compiler > > flags) > > Looking at it further, it's not just the timestamps, but rather, it's > rescanning all of the source for gettext strings, and then updating > the po > files. I'm not sure if this is intentional, or an oversight in the > way the > makefile is written. The simple fix seems to be to touch the po > files before > the build so make doesn't try to rebuild them. This is what I have > done for > now. > > > - d/patches are marked as Forwarded: no and not-needed. Are they > > > r eally > > > not upstreamable? > > > > > > The path patch is for compliance with the FHS, so I think it's > > > Debian > > > -specific > > > since not all distributions follow the FHS. > > > > Try it to send it upstream :) Every patch you do not need to carry > > around will reduce your work needed on the package... > > I forwarded the path patch and also another patch that I forgot about > relating > to compiler flags. > > > > > > The gcc5 fix is cherry picked from an upstream commit, so there's > > > no > > > need to > > > forward it. When the next upstream release is made for Linux, > > > I'll > > > be able to > > > remove it. > > > > Record that in the dep3 header "Origin" > > I had the info in the Applied-Upstream header, but also added it to > Origin as > you suggested. Ah, yes. However Applied-Upstream is to document when a patch have been applied upstream, not when cherry-picking from upstream; for the latter you use Origin. Please also note that Applied-Upstream should be either a URL or prefixed with "commit:". (See the dep3 spec) > > d/rules: DEB_BUILD_OPTIONS: With debhelper compat 9, it should not > > be > > necessary to specify hardening. > > I think this was left over from when I was troubleshooting build > issues. > Removed. > > > > As you are already repacking for dfsg reasons, you can also remove > > some > > other cruft: Codeblocks settings, CodeLite IDE settings, XCode, > > Visual > > Studio solutions file (the old-sln directory) ... > > Not having done a source repackage before, I tried to keep the > changes minimal. > But if it's acceptable to remove anything we don't need, I'm happy to > do it, > and have done so. > > > > > There is an embedded code copy: pugixml -- please use the packaged > > version if possible. > > I attempted to remove the embedded copy and use the packaged version, > but it > looks like the packaged version isn't compatible, as it's built for > char > instead of wchar_t. Trying to use it yields lots of undefined > references when > linking. I can talk to the maintainer about the possibility of > packaging both > versions of the library, but until that happens, the embedded version > may have > to stay. > Ok, but please file a wishlist bug against pugixml asking to provide an flavour with w_char enabled. Note that you should also inform the security team about the code copy and that there is currently no other way. See https://wiki.debian.org/EmbeddedCodeCopies > > The README for Linux developers tells something about Yubi-Key > > support when > > there is libykpers availbale. This package is available in Debian, > > but you do > > not build-depend on it. Is this intentional? > > Build-depends already includes libykpers-1-dev, but the docs say that > libyubikey-dev is also needed, so I've added that as well. > > > > > > d/copyright: > > > > Files: * Copyright: 2003-2014 Rony Shapiro > > License: > > Artistic-2.0 > > > > Files: Misc/maemo2pwsafe.pl Copyright: 2012-2014 Rony Shapiro > > License: Artistic-2.0 > > > > You can join such paragraphs, even if the email is different. > > > > > > Files: src/core/pugixml/* Copyright: 2003 Kristen Wegner < > > kris...@tima.net> > > 2006-2012 Arseny Kapoulkine > be > > 2006-2014 > > > Done. > > > > > There are files in src/core, which have previous copyright, like > > TwoFish.cpp, > > SHA1.cpp or SHA256.cpp (only files I checked, please check all > > files) > > > > (I know. Copyright check
Re: Detecting stray writes in cowbuilder
On Tue, Oct 13, 2015 at 09:43:39PM +0200, David Given wrote: > I've just had a FTBFS bug on a new upload caused by a debian/rules bug > where I was running upstream's make install twice, once without setting > PREFIX. This was causing the package to be installed to $HOME as will as > to ./debian/tmp. > > This worked while doing the packaging, because it was silently getting > installed in my home directory; and it worked in cowbuilder, because it > was silently getting installed in the build's home directory and then > discarded; but it was failing on the build servers because the build > server's $HOME is read-only. > > Is there a way to make cowbuilder detect writes to places that shouldn't > be written to so this doesn't happen again in the future? All this is pbuilder's bug https://bugs.debian.org/441052 (cc'ed) Don't be scared about the dates, pbuilder is now alive again. The change that setted HOME to a writable directory is since 2002, I wonder if I should revert that. If I'm going down that rout I'll add a variable in pbuilderrc that defaults to /nonexistent. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: http://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#745126: marked as done (RFS: passwordsafe/0.97+dfsg-1 [ITP] -- Simple & Secure Password Management)
Your message dated Tue, 13 Oct 2015 22:33:02 +0200 with message-id <1444768382.7111.16.ca...@debian.org> and subject line Re: Bug#745126: RFS: passwordsafe/0.95.1+dfsg-1 has caused the Debian Bug report #745126, regarding RFS: passwordsafe/0.97+dfsg-1 [ITP] -- Simple & Secure Password Management 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.) -- 745126: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745126 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "passwordsafe" * Package name: passwordsafe Version : 0.93+dfsg-1 Upstream Author : Rony Shapiro * URL : http://passwordsafe.sourceforge.net/ * License : Artistic 2.0 Section : utils It builds those binary packages: passwordsafe - Simple & Secure Password Management passwordsafe-common - architecture independent files for Password Safe To access further information about this package, please visit the following URL: http://mentors.debian.net/package/passwordsafe Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/p/passwordsafe/passwordsafe_0.93+dfsg-1.dsc More information about passwordsafe can be obtained from http://www.pwsafe.org/ Regards, Bill Blough --- End Message --- --- Begin Message --- Uploading... Thanks for your contribution. Tobi--- End Message ---
Bug#745126: RFS: passwordsafe/0.95.1+dfsg-1
On Tue, Oct 13, 2015 at 10:01:19PM +0200, Tobias Frost wrote: > > Looks good so far; > I still need to complete copyright review, I'll let you know when I > need something. Thanks! > > PS: You removed the signing key on purpose? Why? When upstream moved to Github, they stopped signing source packages, and started only signing binaries. I asked them to continue signing the sources, and they said they'd look into incorporating it back into their workflow. The missing sig was causing issues with uscan and git-import-orig, so I removed it for now. Once they start providing signatures again, I'll readd it. > > Tobi >
Bug#787861: review: polyml
Hi Gianfranco, Thank you for continuing to look at this. I have just uploaded the newest version (5.5.2-1~rc1) to https://mentors.debian.net/package/polyml. 1) I have sent a request to join debian-science. Presumably I should wait until the package is ready to be uploaded before requesting an upload? 2) By this do you mean change it from an NMU to a team upload in the changelog? If so, I have done that. 3) Added 4) Merged 5) Removed 6) It had it before (https://packages.debian.org/sid/amd64/polyml/filelist). It is in fact required by the new “polyc” compiler executable (a shell script; the output binary is linked against libpolymain) which is currently part of the “polyml” binary package. 7) I know it fails to build on hurd-i386 (due to a lack of PATH_MAX), which I plan to fix and submit upstream. However, I imagine it probably does build on a lot of the other architectures that aren’t listed. 8) There are no reverse dependencies as far as I can tell (other than the various packages built by this source package) > debian:polyml-5.5.2 james% apt-cache rdepends polyml libpolyml1 libpolyml-dev > polyml > Reverse Depends: > libpolyml1 > Reverse Depends: > polyml > libpolyml-dev > libpolyml-dev > Reverse Depends: > debian:~ james% reverse-depends -b src:polyml > No reverse dependencies found 9) The entirety of libffi/ is licensed under the MIT license, and is a copy of the source for https://sourceware.org/libffi/, apart from some unlicensed files in its test suite, and a few other files: > debian:polyml-5.5.2 james% licensecheck * -r | grep -v 'GENERATED FILE$' | > grep -v 'LGPL (v2.1 or later)$' | grep -v '^libffi/.* MIT/X11 (BSD like)$' | > grep -v '^libffi/testsuite/libffi\.call.*\*No copyright\* UNKNOWN$' > libffi/msvcc.sh: MPL (v1.1) GPL (unversioned/unknown version) > libffi/texinfo.tex: GPL (v3) > libffi/build-ios.sh: *No copyright* UNKNOWN > libffi/testsuite/libffi.special/ffitestcxx.h: *No copyright* UNKNOWN > libffi/testsuite/libffi.special/unwindtest.cc: *No copyright* UNKNOWN > libffi/testsuite/libffi.special/unwindtest_ffi_call.cc: *No copyright* UNKNOWN > libffi/ltmain.sh: GPL (v2 or later) > libffi/include/ffi_common.h: UNKNOWN > libffi/generate-osx-source-and-headers.py: *No copyright* UNKNOWN > libffi/src/m68k/ffi.c: *No copyright* UNKNOWN > libffi/src/dlmalloc.c: *No copyright* UNKNOWN > libffi/generate-ios-source-and-headers.py: *No copyright* UNKNOWN > libpolyml/realconv.cpp: UNKNOWN > ltmain.sh: GPL (v2 or later) > wininstall/polyicon/polyicon.c: *No copyright* UNKNOWN I have added an entry to debian/copyright listing libffi as MIT; is this sufficient? 10) Removed 11) Changed Thanks, James > On 13 Oct 2015, at 18:46, Gianfranco Costamagna > wrote: > > Control: owner -1 ! > Control: tags -1 moreinfo > > Hi James, > > 1) please join the debian-science team and ask them an ack for the upload > 2) please convert in team upload the package > > 3) please close 561763 in the changelog > 4) please merge the two changelogs together > > 5) please remove rules.old > 6) the polyml.install shouldn't have the static library, right? > 7) "i386 sparc powerpc amd64 armel armhf" do you have any reason for not > trying to build on "any"? > 8) did you test reverse dependencies? > > apt-cache rdepends package > > reverse-depends -b src:package > can give you some hints > > > 9) licensecheck * -r shows many licenses not LGPL-2.1+ > 10) debian/menu please remove (menu is deprecated since a month or two) > 11) > usr/share/man/man1/poly.1* > usr/share/man/man1/polyc.1* > usr/share/man/man1/polyimport.1* > > > > they belong to dh_installmanpages, not dh_install > > the other stuff might look good, I still need to check a build&run of the > package. > > cheers, > > G. > > > Il Mercoledì 7 Ottobre 2015 12:21, James Clarke ha > scritto: > Hi, > I believe I have addressed the changes you mentioned in > http://mentors.debian.net/debian/pool/main/p/polyml/polyml_5.5.2-0.2.dsc, and > would be grateful if you could please review it. > > Thanks, > James > > >> On 6 Oct 2015, at 10:54, James Clarke wrote: >> >> Firstly sorry for not replying, I hadn’t subscribed to the bug so I was >> never emailed a copy of your message. >> >> I figured it wasn’t really common to have NMUs like this, but given the fact >> that the package is not orphaned but its maintainers have not replied to bug >> reports, I thought this was one of the few options; I don’t really care how >> the newer versions are uploaded, so long as they get uploaded eventually! >> >> As far as I can tell from `apt-cache depends`, nothing outside of the polyml >> source package depends on any of the binary packages in it. >> >> 1) makes sense to go via experimental >> 2,3,4) I shall see what I can do >> >> In case you couldn’t tell I’m very new to this, so thanks for taking the >> time to go through the details. >> >> Thanks, >> James >> >>> On 25 Sep 2015, at 17:32, Gianfranco Costamagna >>> wrote
Bug#801650: RFS: edgar/1.21-1 [ITP]
Control: tags -1 - moreinfo Package is re-uploaded with fixes in place.
Bug#800966: RFS: kimchi/1.5.1-1 [ITP] -- HTML5 based management tool for KVM
On Wed, Oct 7, 2015 at 11:39 PM, Frederic Bonnard wrote: > interesting. I tried to build the package on amd64 too but in a schroot env > (unstable) and it built fine. > Could you explain or give some links on how to setup this sbuild env ? > Thanks a lot, Sbuild is simple to setup, please visit its wiki [1][2] to see how to build package with sbuild. Packages accepted by ftp-master are built with sbuild for all architecture and uploaded to debian archive. Beside sbuild, you may use pbuilder[3] to validate package build dependency. [1] https://wiki.debian.org/sbuild [2] https://wiki.ubuntu.com/SimpleSbuild [3] https://www.debian.org/doc/manuals/maint-guide/build.zh-cn.html#pbuilder -- Liang Guo
