Re: Re: [RFC] How to review RFS package
> On 8 Feb 2017, at 14:49, Gianfranco Costamagna > wrote: >>> apt build-dep (dsc-file) to build-dependencies> > >> I remember "apt build-dep " is only for package already > >> exists in archive. > > > > when the argument is a dsc file, apt parses the dependency list. > (IIRC this is a feature since apt 1.0 or 1.1) You can also give it the path to an unpacked source package; I often do "apt-get build-dep $PWD" on porterboxen. Regards, James
Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP]
> On 18 May 2016, at 14:15, James Clarke wrote: > >> On 18 May 2016, at 13:44, lumin wrote: >> * add debian/upstream/metadata , but lintian says >> >>> W: caffe source: upstream-metadata-yaml-invalid >> >> Is there anything wrong with this file? I have no idea >> >> ``` >> Homepage: http://caffe.berkeleyvision.org/ >> Name: Caffe >> Reference: >> Author: Jia, Yangqing and Shelhamer, Evan and Donahue, Jeff and Karayev, >> Sergey and Long, Jonathan and Girshick, Ross and Guadarrama, Sergio and >> Darrell, Trevor >> Title: Caffe: Convolutional Architecture for Fast Feature Embedding > > You need to quote the colon in "Caffe:”. The entire field, that is (you can’t quote a subset of it afaik), i.e. Title: 'Caffe: Convolutional Architecture for Fast Feature Embedding' > https://wiki.debian.org/UpstreamMetadata recommends > http://yaml-online-parser.appspot.com/ for validation. Regards, James signature.asc Description: Message signed with OpenPGP using GPGMail
Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP]
> On 18 May 2016, at 13:44, lumin wrote: > * add debian/upstream/metadata , but lintian says > >> W: caffe source: upstream-metadata-yaml-invalid > > Is there anything wrong with this file? I have no idea > > ``` > Homepage: http://caffe.berkeleyvision.org/ > Name: Caffe > Reference: > Author: Jia, Yangqing and Shelhamer, Evan and Donahue, Jeff and Karayev, > Sergey and Long, Jonathan and Girshick, Ross and Guadarrama, Sergio and > Darrell, Trevor > Title: Caffe: Convolutional Architecture for Fast Feature Embedding You need to quote the colon in "Caffe:". https://wiki.debian.org/UpstreamMetadata recommends http://yaml-online-parser.appspot.com/ for validation. Regards, James signature.asc Description: Message signed with OpenPGP using GPGMail
Bug#787861: review: polyml
Hi Gianfranco, >> I have uploaded 5.5.2-2 to mentors (and updated my git repository) enabling >> all hardening flags. I also realised that the new polyc shell script >> requires gcc and >libffi-dev to produce standalone executables, so I have >> added those as dependencies for polyml. > > wonderful, I'll upload again then :) Great, thanks. >> Should I push my changes to debian-science/packages/polyml.git (especially >> since that’s the repository in debian/control)? Also, going forwards, if I >> want to get a >new version uploaded, do I need to file a new RFS “bug” >> against sponsorship-requests, or should I instead just email debian-science >> asking for a team upload >(subject to a review of the package)? > > yes, and if you can't do it I can do it for you :) Pushed. > For another upload you can ping me directly or add an RFS bug, as you prefer. Ok, I’ll probably come to you first then seeing as creating an RFS bug can be a nuisance; having the same uploader would make sense, rather than some new person having to start from scratch with the package every time. Of course, if you ever want me to find someone else, please say so; I’ll understand :) Thanks, James signature.asc Description: Message signed with OpenPGP using GPGMail
Bug#787861: review: polyml
Hi Gianfranco, > I sponsored the package Thank you again for all your help. > (BTW I was intending to subscribe to debian-science, but also debian-devel is > nice to be subscribed) I have subscribed to debian-science as well. > However, I would appreciate a fix for the following missing flags in a future > release: > CXXFLAGS missing (-fPIE): > LDFLAGS missing (-Wl,-z,now) > CFLAGS missing (-fPIE): > LDFLAGS missing (-fPIE -pie -Wl,-z,now) > you can see the full log here [1] or by using blhc tool > > > [1] http://debomatic-i386.debian.net/distribution#unstable/polyml/5.5.2-1/blhc I have uploaded 5.5.2-2 to mentors (and updated my git repository) enabling all hardening flags. I also realised that the new polyc shell script requires gcc and libffi-dev to produce standalone executables, so I have added those as dependencies for polyml. Should I push my changes to debian-science/packages/polyml.git (especially since that’s the repository in debian/control)? Also, going forwards, if I want to get a new version uploaded, do I need to file a new RFS “bug” against sponsorship-requests, or should I instead just email debian-science asking for a team upload (subject to a review of the package)? James signature.asc Description: Message signed with OpenPGP using GPGMail
Bug#787861: review: polyml
Hi Gianfranco, Apologies for the duplicate message, but I forgot to Cc the bug and debian-science. > well, for sure I suggest you to subscribe to debian-devel mail list and to > the package [1] at the bottom of the page. Done (although to the digest for debian-devel!) > you can also contact MIA team to know if the maintainers are really MIA, in > that case the package will be orphaned and you will be able to take it over. Email sent > the problem actually is that the package is not building fine on amd64 and > i386. > > "configure.ac:410: error: possibly undefined macro: LT_SYS_SYMBOL_USCORE > If this token and others are legitimate, please use m4_pattern_allow. > See the Autoconf documentation.” I was able to reproduce this when building with pbuilder (just set it up). LT_SYS_SYMBOL_USCORE is defined in m4/ltdl.m4, which needs libltdl-dev to do so, so I added it to Build-Depends. I never actually installed libltdl-dev myself; it was pulled in by libtool as a recommended package, but it seems pbuilder/debootstrap only pulls in dependencies, which is how I managed to miss this dependency. > BTW you need to add libffi-dev to build-dependencies and enable it in > configure script. Done (upstream’s configure.ac forces libffi to be configured and is apparently needed, even in this case, so don’t be alarmed by that being mentioned in the logs!) I have re-uploaded 5.5.2-1 to mentors. I have also forked debian-science/packages/polyml.git to http://anonscm.debian.org/cgit/users/jrtc27-guest/polyml.git/ and pushed all my changes there. Thanks, James Clarke signature.asc Description: Message signed with OpenPGP using GPGMail
Bug#787861: review: polyml
Hi Gianfranco, > On 15 Oct 2015, at 10:56, Gianfranco Costamagna > wrote: > > Hi James > > >> I have uploaded 5.5.2-1~rc2 to mentors. > > > > please call it 5.5.2-1 and nothing more :) > you can push the same version many times on mentors with no problems. Changed >> 1) Do I need to send a separate email to this then? I also filed #801793 for >> a transition, but that has already been closed as unnecessary since there >> are no rdeps. > > > true, nevermind I didn't test carefully rdeps > (so we might go directly on unstable then) Changed to unstable > >> I hardly think linking against this static library is an issue. > > > ok >> 7) I have added arm64, ppc64el and ppc64 > > > what about the "any" keyword? I don't like specifying manually architectures, > specially because it makes > porters people angry :) > > porters needs a build failure instead of a build that didn't start at all, > except when there is a good > reason to not build on a particular architecture > e.g. systemd on kfreebsd-* and hurd-* Changed to "any" > >> 9) Added (libffi/msvcc.sh is MPL-1.1, GPL-2.0+ or LGPL-2.1+) > > > wonderful >> 11) It doesn’t seem to work without the debian/tmp/ prefix. The manpage for >> dh_install specifically mentions falling back to debian/tmp/, but there is >> no such >statement in dh_installman, so I believe you have to specify that >> manually. > > > well, no problem >> 12) I unused-file-paragraph-in-dep5-copyright: Fixed by reordering entries >> 13) I vcs-field-not-canonical: Changed to Vcs-Browser: >> https://anonscm.debian.org/cgit/debian-science/packages/polyml.git/ and >> Vcs-Git: git://anonscm.debian.org/debian-science/packages/polyml.git >> 14) W shlib-with-executable-stack: This is because libpolyml has one >> assembly file[1] for x86 (other architectures don’t have any assembly). I >> have added a patch under debian/patches which I have also submitted upstream >> to fix this. >> > >> [1] GNU as defaults to having an executable stack, unlike with GCC etc, and >> you have to explicitly tell it to not do so. You can either do this by >> adding the magic >'.section .note.GNU-stack, "", @progbits' statement, or by >> passing it a command-line argument. The former is apparently generally >> preferred (and is what libffi >does in its assembly files). > nice to learn something new! thanks a lot > > > > I guess we are mostly ready, just go on unstable (urgency=low might be better) > think about arch:any Urgency changed to low (other points addressed above) > > and I guess I'll prepare the upload. > > cheers, > > G. I have uploaded the latest version to mentors. Currently, the old maintainers are still listed in debian/control. I’m happy to assume responsibility for bug reports etc, so do I need to add myself to Uploaders? I don’t want to tread on anyone’s toes though if that’s bad form. James signature.asc Description: Message signed with OpenPGP using GPGMail
Bug#787861: review: polyml
Hi Gianfranco,
I have uploaded 5.5.2-1~rc2 to mentors.
1) Do I need to send a separate email to this then? I also filed #801793 for a
transition, but that has already been closed as unnecessary since there are no
rdeps.
2) Added
6) The compiler is indeed forcing your code to be linked against a static
library. I would argue that the compiler *should* be included in the polyml
package along with the interpreter. The libpolyml-dev package provides access
to the internal library used by polyml, whereas the static libpolymain.a
library provides an entry point stub for your compiled code. It contains the
single libpolymain/polystub.c file, defining main (or WinMain if you happen to
compile on Windows…) which calls through to polymain, contained in the *shared*
libpolyml.so.6 library, like so:
> int main(int argc, char *argv[])
> {
> return polymain(argc, argv, &poly_exports);
> }
These are the symbols in libpolymain.a:
> debian:polytest james% nm /usr/lib/x86_64-linux-gnu/libpolymain.a
>
> polystub.o:
> T main
> U poly_exports
> U polymain
I hardly think linking against this static library is an issue.
7) I have added arm64, ppc64el and ppc64
9) Added (libffi/msvcc.sh is MPL-1.1, GPL-2.0+ or LGPL-2.1+)
11) It doesn’t seem to work without the debian/tmp/ prefix. The manpage for
dh_install specifically mentions falling back to debian/tmp/, but there is no
such statement in dh_installman, so I believe you have to specify that manually.
New Points:
12) I unused-file-paragraph-in-dep5-copyright: Fixed by reordering entries
13) I vcs-field-not-canonical: Changed to Vcs-Browser:
https://anonscm.debian.org/cgit/debian-science/packages/polyml.git/ and
Vcs-Git: git://anonscm.debian.org/debian-science/packages/polyml.git
14) W shlib-with-executable-stack: This is because libpolyml has one assembly
file[1] for x86 (other architectures don’t have any assembly). I have added a
patch under debian/patches which I have also submitted upstream to fix this.
[1] GNU as defaults to having an executable stack, unlike with GCC etc, and you
have to explicitly tell it to not do so. You can either do this by adding the
magic '.section .note.GNU-stack, "", @progbits' statement, or by passing it a
command-line argument. The former is apparently generally preferred (and is
what libffi does in its assembly files).
Thanks,
James
> On 14 Oct 2015, at 16:46, Gianfranco Costamagna
> wrote:
>
> Hi James,
>
>
>
>> 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.
>
>
> thanks to you for caring!
>> 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?
>
>
> nope, I'm member of debian-science, I can sponsor it because I'm part of the
> team already.
> (maybe we can cc debian-science too, I'm doing it right now)
>
>
> and this is a package that has only *one* maintainer upload dated 2009 and an
> NMU dated 2012,
> if somebody complains they should start maintain the package instead of
> making them outdated :)
>
>
>> 2) By this do you mean change it from an NMU to a team upload in the
>> changelog? If so, I have done that.
>
> correct, but you need to start with a "* Team Upload"
> dch --team does this for you
>
>> 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.
>
> well, and then you are forcing people to link against a static library? I
> would expect the package polyml to depend on the -dev package, and allowing
> people to choose their favourite library version
> (or moving the polyc inside the -dev package, since it is useful for
> developing stuff)
>
> 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.
>
> yes, there is no need to restrict where not necessary.
> specially for ppc64* and arm64 archs I guess it should build cleanly
>
> 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$'
>>
>> I have added an entry to debian/copyright listing libffi as MIT; is this
>> sufficient?
>
>
> I guess you should add also them (at least)
>
> libffi/msvcc.sh: MPL (v1.1) GPL (unvers
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 `
Bug#787861: review: polyml
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- >> > signature.asc Description: Message signed with OpenPGP using GPGMail
Bug#787861: review: polyml
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- > signature.asc Description: Message signed with OpenPGP using GPGMail
Bug#787861: RFS: polyml/5.5.2-0.1 [NMU]
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "polyml" * Package name: polyml Version : 5.5.2-0.1 Upstream Author : David Matthews * URL : http://www.polyml.org * License : LGPL-2.1+ Section : interpreters It builds these binary packages: libpolyml-dev - development files for Poly/ML, a compiler for Standard ML libpolyml6- runtime files for Poly/ML, a compiler for Standard ML polyml- interpreter and interactive compiler for Standard ML To access further information about this package, please visit the following URL: http://mentors.debian.net/package/polyml Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/p/polyml/polyml_5.5.2-0.1.dsc More information about polyml can be obtained from http://www.polyml.org. Changes since the last upload: * Non-maintainer upload * New upstream version * Removed libtool .la files * Rename libpolyml1 to libpolyml6 * Bump up Standards-Version to 3.9.6 * Bump up debian/compat to 9, and use dh_prep over dh_clean -k * Enabled build hardening with dpkg-buildflags * Made descriptions more consistent The maintainer has not updated this package in years. Various people including myself have attempted to contact the maintainer (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561763), but these have failed, so I have packaged it myself to hopefully move things along. Regards, James Clarke -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/c847a3f3-7ad6-492e-9def-6411c2edb...@jrtc27.com
