Bug#837650: RFS: cf-python/1.3.1+dfsg.1-1 [ITP]

[Klaus Zimmermann]

Hi Gianfranco, hi Bas,

Am 01.10.2016 um 20:35 schrieb Gianfranco Costamagna:
> (additional review, on top of Sebastiaan's one)
> * Requires a python version from 2.6 up to, but not including, 3.0.
> 
> Sebastiaan, I'm not sure we can build Python3 version, but I leave this
> check to the maintainer :p
Indeed, regrettably python3 is not supported upstream at the moment.
I am also working on that, but, you know, one step at a time.

>> If it's preferable to keep the package in the GIS team, I will also be
>> happy to do that. I am inexperienced in Debian politics and submit to
>> your better judgment.
> 
> not needed, it is fine this way
Ok, so also in light of what Bas wrote, let's keep it in DPMT.

> review:
> 1)
> ./docs/source/ttt/cloud_sptheme/themes/redcloud/static/redcloud.css_t: * 
> :license: BSD
> ./docs/source/ttt/cloud_sptheme/themes/cloud/static/jquery.cookie.js: * Dual 
> licensed under the MIT and GPL licenses:
> ./docs/source/ttt/cloud_sptheme/themes/cloud/static/jquery.cookie.js: * 
> http://www.opensource.org/licenses/mit-license.php
> ./docs/source/ttt/cloud_sptheme/themes/cloud/static/jquery.cookie.js: * 
> http://www.gnu.org/licenses/gpl.html
> ./docs/source/ttt/cloud_sptheme/themes/cloud/static/cloud.js_t: * :license: 
> BSD
> ./docs/source/ttt/cloud_sptheme/themes/cloud/static/cloud.css_t: * :license: 
> BSD
> ./docs/source/ttt/cloud_sptheme/themes/cloud/layout.html::license: BSD
> 
> missing licenses ^^
> 2) grep copyright . -Ri
> 
> some missing copyrights :)

I removed most of the offending content and added the information for the 
remaining stuff, namely two files of static sphinx content.


> 3)
> 
> something about: 
> cf/um/umread/c-lib/Makefile
> 
> CC=gcc
> 
> such stuff is a no-go for my personal policy.
> People might want to export CC=clang or whatever, and see it build with it.
> 
> Changing
> CC=gcc
> to CC?=gcc fixes this
> (set if not already set)
> the same applies to other stuff in that file.
I incorporated all of the above.


> $(LDFLAGS)<-- this should be at the end of the line, not at the begin, 
> otherwise
> you might see some libraries stripped just because the .o files needing them
> are put after (this happens when wl-asneeded is used/default)
Hm, GNU make disagrees with you here. The built-in rule for linking is
$(CC) $(CFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_ARCH) $^ $(LOADLIBES) $(LDLIBS) 
-o $@

Anyway, I think the Makefiles are improved now, thanks for all the help!
This also allowed for adding the hardening features to the build.

 
> 4) 
> Depends:
> libudunits2-0,
> 
> please avoid this because it means a sourceful uploads each time that package
> has a soname bump.
> 
> e.g. you can avoid that by having a dependency on the -dev package,
> and for runtime... don't know, you don't link it, do you?
> 
> ./cf/units.py:_udunits = ctypes.CDLL('libudunits2.so.0')
> 
> 
> probably that is the best way, at least a sourceful upload is needed
> anyway, to check if the code still works.
I am sorry, but I don't understand: So we are talking about the '-0' at the 
end, right?
My first question is: Why is that there in the first place?
Why is the package not simply called libudunits2?
I will be happy to change the dependencies, but at the moment I don't 
understand how,
since I never need the -dev package, and it seems the libudunits2-0 is the only 
possibility
for the binary package, right?

> 5)
> http://debomatic-amd64.debian.net/distribution#unstable/cf-python/1.3.2+dfsg.1-1/lintian
It lists five errors. For the specifics I refer to the above link. Just for 
reference I repeat the first couple of words:
5.1) X: python-cf-doc: duplicate-files
 There is only one sphinx template. I have the nagging feeling that those 
templates aren't even used,
 but at the moment I don't know sphinx enough to make that call.
 If you know this, I would gladly remove them.
 Anyway it is just three lines of text, so I think we can ignore it for now.

5.2) X: python-cf: library-package-name-for-application
5.3) X: python-cf: application-in-library-section
 These are correct, i.e. unavoidable since the applications are merely small 
helper scripts for the library that is the main work.

5.4) I: python-cf: hardening-no-bindnow
5.5) I: python-cf: hardening-no-fortify-functions
 Thanks to the above Makefile improvements, hardening has now been added and 
those should be gone.
 
> something might be addressed, something is not worth a fix
> also blhc complains
> http://debomatic-amd64.debian.net/distribution#unstable/cf-python/1.3.2+dfsg.1-1/blhc
This should also be clear now, thanks to hardening.

> 6) isn't 1.3.1+dfsg1-1 a better versioning? I don't like too much that "."
I took it from some guide on how to do the dfsg cleaning,
but since I don't feel strongly about it I changed it.

> I think this is all for now :)
Thanks!

Klaus




signature.asc
Description: OpenPGP digital signature

Version comparison with "+repack"

[Ole Streicher]

Hi,

my package "saods9" has currently a RC release in experimental that is
named

7.5~rc+repack-1

Now, upstream released a second RC which I want to upload as well:

7.5~rc2+repack-1

However, it turns out that this release is actually *smaller* than the
first RC release? I originally thought that the "+" is chosen because it
will not interfere with the upstream versioning?

dpkg --compare-versions 7.5~rc+repack  lt 7.5~rc2+repack && echo lt || echo ge
ge

What is the best way to fix this?

Best regards

Ole

Bug#839833: RFS: gkeyring/0.4-1 [ITP]

[SOUBEYRAND Yann - externe]

Hi!

Thank you for your interest in sponsoring this package ;-)

I uploaded a new version which should address the most important
concerns you raised

https://mentors.debian.net/debian/pool/main/g/gkeyring/gkeyring_0.4-1-gf4ce4c7-1.dsc

Regards

Yann

Le jeudi 06 octobre 2016 à 12:49 +0800, un expéditeur inconnu a écrit :
> Control: owner -1 !
> Control: tags -1 + moreinfo
> 
> On Wed, Oct 5, 2016 at 10:46 PM, Yann Soubeyrand wrote:
> 
> >   dget -x 
> > https://mentors.debian.net/debian/pool/main/g/gkeyring/gkeyring_0.4-1.dsc
> 
> I intend to sponsor this.
> 
> These issues block the upload of this package:
> 
> Neither the upstream tarball nor debian/ contain a copy of the AGPLv3.
> I see upstream has one in their repository, so they just need to tag a
> new release and you need to update to it, or you could package the
> commit that adds it. The debian/copyright file should also contain a
> full copy of the AGPLv3.
> 
> These issues would be nice to fix:
> 
> The watch file is broken (see below).
> 
> I think you probably only need python rather than python-all?
> 
> The Vcs-Browser field points at the upstream repository instead of the
> Debian one, please remove it or replace it.
> 
> The Vcs-Git field should be present when Vcs-Browser is pointing at a
> git repository browser.
> 
> The Homepage field should point at github because of this on the launchpad 
> page:
> 
> The project is now hosted here:
> https://github.com/kparal/gkeyring
> This Launchpad site is used for its Answers discussion forum only.
> 
> Remove the word Python from the description, the implementation
> language isn't relevant to end users.
> 
> This command will make diffs of debian/ easier to read:
> 
> wrap-and-sort --short-indent --wrap-always --sort-binary-packages
> --trailing-comma
> 
> The debian/ directory is usually licensed under the same license as upstream.
> 
> Please add some upstream metadata:
> 
> https://wiki.debian.org/UpstreamMetadata
> 
> Please get the manual page included upstream, or get documentation
> included in gkeyring.py and have the manual page generated from it
> using sphinx and sphinxcontrib-autoprogram/sphinx-argparse.
> 
> Please ask upstream about switching to or supporting Python 3 and then
> switching to it in Debian.
> 
> Upstream is using an image for flattr, I'd suggest they drop it and
> only use the existing link, otherwise HTML versions of the README.rst
> will violate the privacy of people who load those HTML files. github
> is mitigating that by serving all external images from github.com but
> it could still occur if someone were to render the document to HTML.
> 
> Upstream may want to use signed commits tags and releases:
> 
> https://mikegerwitz.com/papers/git-horror-story
> https://wiki.debian.org/Creating%20signed%20GitHub%20releases
> https://wiki.debian.org/debian/watch#Cryptographic_signature_verification
> 
> Upstream may want to read our guide for upstreams:
> 
> https://wiki.debian.org/UpstreamGuide
> 
> Once the package reaches Debian, add debtags and screenshots:
> 
> https://debtags.debian.org/
> https://screenshots.debian.net/
> 
> Automated checks:
> 
> lintian:
> 
> P: gkeyring source: debian-watch-may-check-gpg-signature
> 
> check-all-the-things:
> 
> $ env PERL5OPT=-m-lib=. cme check dpkg
> ...
> Warning in 'control source Build-Depends:0' value 'debhelper (>= 9~)':
> should be (>= 9) not (>= 9~) because compat is 9
> ...
> you can try 'cme fix dpkg' to fix the warnings shown above
> 
> # check if these can be switched to https://
> $ grep -rF http: .
> ./gkeyring.py:# http://www.gnu.org/licenses/agpl-3.0.html
> ./gkeyring.py:#
> http://blogs.codecommunity.org/mindbending/bending-gnome-keyring-with-python-part-2/
> ./README.rst:You can install this tool from `PyPI
> `_ (using `pip
> `_, `setuptools
> `_ or `distutils
> `_)::
> ./README.rst:This program is a free software, licensed under `GNU AGPL
> 3+ `_.
> ./README.rst:.. image:: http://api.flattr.com/button/flattr-badge-large.png
> ./debian/copyright: along with this program. If not, see
> .
> ./debian/copyright: along with this program. If not, see
> .
> 
> # Note the missing / at the end of the URL
> $ env PERL5OPT=-m-lib=. license-reconcile
> FormatSpec: Cannot recognize format: Format:
> https://www.debian.org/doc/packaging-manuals/copyright-format/1.0 at
> /usr/share/perl5/Debian/LicenseReconcile/App.pm line 222,  line
> 3.
> 
> # This command checks style. While a consistent style
> # is a good idea, people who have different style
> # preferences will want to ignore some of the output.
> # Do not bother adding non-upstreamable patches for this.
> $ find -type f -iname '*.py' -exec pep8 --ignore W191 {} +
> 
> 
> $ find -type f -in

Bug#837650: RFS: cf-python/1.3.1+dfsg.1-1 [ITP]

[Klaus Zimmermann]

Hi Guys,

one more thing:
In a private exchange Ross agreed to me taking over.

Thanks
Klaus



signature.asc
Description: OpenPGP digital signature

Re: Version comparison with "+repack"

[Santiago Vila]

On Fri, Oct 07, 2016 at 11:00:17AM +0200, Ole Streicher wrote:

> my package "saods9" has currently a RC release in experimental that is
> named
> 
> 7.5~rc+repack-1
> 
> Now, upstream released a second RC which I want to upload as well:
> 
> 7.5~rc2+repack-1
> 
> However, it turns out that this release is actually *smaller* than the
> first RC release? I originally thought that the "+" is chosen because it
> will not interfere with the upstream versioning?
> 
> dpkg --compare-versions 7.5~rc+repack  lt 7.5~rc2+repack && echo lt || echo ge
> ge
> 
> What is the best way to fix this?

The best way I don't know, but I would put the RC number at the end,
i.e. 7.5~rc+repack2 for RC2, 7.5~rc+repack3 for RC3 and so on.

The problem is that it's too late to call "7.5~rc+repack" as "7.5~rc1+repack".

Thanks.

Re: Version comparison with "+repack"

[Ole Streicher]

Santiago Vila  writes:
> On Fri, Oct 07, 2016 at 11:00:17AM +0200, Ole Streicher wrote:
>> dpkg --compare-versions 7.5~rc+repack  lt 7.5~rc2+repack && echo lt || echo 
>> ge
>> ge
>> 
>> What is the best way to fix this?
>
> The best way I don't know, but I would put the RC number at the end,
> i.e. 7.5~rc+repack2 for RC2, 7.5~rc+repack3 for RC3 and so on.

IMO this is not a good idea since it suggests that we now have the
second repack of the RC.

> The problem is that it's too late to call "7.5~rc+repack" as "7.5~rc1+repack".

In any case, I would like to stay as close to the original versioning as
possible, so that the users can easily see where it originates from.

Cheers

Ole

Bug#838495: RFS: python-cartopy/0.14.2-1 [ITP]

[Ghislain Vaillant]

Hi Frederic,

I have uploaded a new version of python-cartopy/0.14.2+dfsg1-1 [1] for
you to review and sponsor.

I ended up doing a dfsg-repack of the source to exclude the files you
suggested, for which the copyright was either missing, non-free or
ambiguous.


[1] https://mentors.debian.net/debian/pool/main/p/python-cartopy/python
-cartopy_0.14.2+dfsg1-1.dsc

Please let me know whether you have any other comments.

Best regards,
Ghis

Re: Version comparison with "+repack"

[Mattia Rizzolo]

On Fri, Oct 07, 2016 at 12:26:09PM +0200, Ole Streicher wrote:
> Santiago Vila  writes:
> > On Fri, Oct 07, 2016 at 11:00:17AM +0200, Ole Streicher wrote:
> >> dpkg --compare-versions 7.5~rc+repack  lt 7.5~rc2+repack && echo lt || 
> >> echo ge
> >> ge
> >> 
> >> What is the best way to fix this?
> >
> > The best way I don't know, but I would put the RC number at the end,
> > i.e. 7.5~rc+repack2 for RC2, 7.5~rc+repack3 for RC3 and so on.
> 
> IMO this is not a good idea since it suggests that we now have the
> second repack of the RC.

agreed.  What about
7.5~rc.2+repack
?

The full stop is ugly at my eyes, but does the work and there are worse
things in the world.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: Version comparison with "+repack"

[Ole Streicher]

Mattia Rizzolo  writes:
> On Fri, Oct 07, 2016 at 12:26:09PM +0200, Ole Streicher wrote:
>> Santiago Vila  writes:
>> > On Fri, Oct 07, 2016 at 11:00:17AM +0200, Ole Streicher wrote:
>> >> dpkg --compare-versions 7.5~rc+repack lt 7.5~rc2+repack && echo
>> >> lt || echo ge
>> >> ge
>> >> 
>> >> What is the best way to fix this?
>> >
>> > The best way I don't know, but I would put the RC number at the end,
>> > i.e. 7.5~rc+repack2 for RC2, 7.5~rc+repack3 for RC3 and so on.
>> 
>> IMO this is not a good idea since it suggests that we now have the
>> second repack of the RC.
>
> agreed.  What about
> 7.5~rc.2+repack
> ?
>
> The full stop is ugly at my eyes, but does the work and there are worse
> things in the world.

This is probably the best compromise; hopefully an RC will not remain
there for long anyway.

I am however wondering about this case since it shows a descripancy
between the common usage of "+" (being the delimiter between original
upstream version and debian specific removals) and the ordering
procedure... I will probably file a bug against the Debain Policy :-)

Best regards

Ole

Re: Version comparison with "+repack"

[Adam Borowski]

On Fri, Oct 07, 2016 at 11:23:45AM +, Mattia Rizzolo wrote:
> agreed.  What about
> 7.5~rc.2+repack
> ?
> 
> The full stop is ugly at my eyes, but does the work and there are worse
> things in the world.

What about rc-2+repack?  A matter of taste but I'd call this somewhat less
ugly.

-- 
A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, 1kg
raspberries, 0.4kg sugar; put into a big jar for 1 month.  Filter out and
throw away the fruits (can dump them into a cake, etc), let the drink age
at least 3-6 months.

Re: Version comparison with "+repack"

[Ole Streicher]

Adam Borowski  writes:
> On Fri, Oct 07, 2016 at 11:23:45AM +, Mattia Rizzolo wrote:
>> agreed.  What about
>> 7.5~rc.2+repack
>> ?
>> 
>> The full stop is ugly at my eyes, but does the work and there are worse
>> things in the world.
>
> What about rc-2+repack?  A matter of taste but I'd call this somewhat less
> ugly.

I already uploaded...

FYI, the bug is https://bugs.debian.org/840002

Best regards

Ole

Bug#838870: RFS: nbsphinx/0.2.9+ds-1 [ITP] -- Jupyter Notebook Tools for Sphinx

[Frederic Bonnard]

Thanks Benoit for all the documentation work.
The package looks good to me.
Good catch for the audio link ; indeed lintian does not seem to handle 
element (I sent a patch : https://bugs.debian.org/840009 )

As a side node, I'd advise you consider (report from check-all-the-things tool) 
:
- adding some upstream metadata: https://wiki.debian.org/UpstreamMetadata
- asking upstream to sign their release (debian-watch-may-check-gpg-signature)
  : https://wiki.debian.org/Creating%20signed%20GitHub%20releases
I still have to follow those advises for my packages :)

F.

On Fri, 7 Oct 2016 00:58:08 +0100, Jerome BENOIT  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Hello,
> 
> On 05/10/16 13:26, Frederic Bonnard wrote:
> > Thanks Benoit/Ghislain,
> > indeed with experimental archive it's much better :)
> > 
> > Benoit,
> > my last point would be about privacy-breach-generic lintian.
> > You overrided it with :
> > --
> > N: The involved links are meant to illustrate URL examples, so it is 
> > meaningless
> > N: to bring the involved material in a local folder.
> > --
> > 
> > I agree that bringing stuff locally (as it is advised in the lintian
> > description) is useless when the goal is to show the code for how to embed
> > content of remote images/videos URLs.
> > Though I still think there's a breach, as loading the documentation makes 
> > your
> > browser connect to the internet, load images but also javascripts and so 
> > on, which
> > is originally the reason of this lintian definition (or let me know if I'm 
> > wrong).
> > Even if you point to DFSG-free ressources, you'll have your browser that 
> > will still
> > connect outside, and that's the issue in my understanding.
> > 
> > I've been thinking about this and reading your discussion with Paul Wise,
> > I came to the following idea : why not changing after generation the html 
> > (sed...) :
> > 
> > For images :
> > ---
> > -https://www.python.org/static/img/python-logo-large.png"/>
> > +https://www.python.org/static/img/python-logo-large.png should be 
> > displayed, but it got removed because of 
> > https://lintian.debian.org/tags/privacy-breach-generic.html.";
> > ---
> > 
> > and for the embedded video :
> > 
> > ---
> >   >  width="400"
> >  height="300"
> > -src="https://www.youtube.com/embed/WAikxUGbomY";
> > +src="about:blank"
> >  frameborder="0"
> >  allowfullscreen
> > +srcdoc="This video : https://www.youtube.com/embed/WAikxUGbomY should 
> > be displayed, but it got removed because of 
> > https://lintian.debian.org/tags/privacy-breach-generic.html.";
> >  >
> > ---
> > 
> > That way, you'll keep the source code example clean, and despite the fact 
> > the html
> > is modified, the user reading the documentation will still understand the 
> > example, what
> > it should do, what is displayed and altered and why.
> > Ok the documentation html code is modified but the goal of the doc is to get
> > the idea of the use (source code) and visual result (rather than html 
> > output that got modified)
> > I also thought of playing with Content-Security-Policy in  of the 
> > document to block
> > all outside connections but, I'm not sure all browser implement this 
> > correctly.
> > It's also less understable for the reader to understand why things 
> > disappeared (except
> > if this "framework" have information facilities). But it would be very good 
> > to fix
> > all the privacy-breach-generic in a general manner.
> 
> 
> When I wrote the lintian override, I have in mind beside the HTML output the 
> ipynb input,
> only the former is taken into account by lintian.
> Meanwhile, I relized that lintian was not able to point out an audio 
> privacy-breatch..
> 
> Anyway, I brought the suggested material. The hard part was the refreshment 
> of the debian/copyright file:
> it is getting large.
> 
> I hope the package is fine now.
> 
> Thanks,
> Jerome
> 
> 
> 
> > 
> > 
> > F.
> > 
> 
> - -- 
> Jerome BENOIT | calculus+at-rezozer^dot*net
> https://qa.debian.org/developer.php?login=calcu...@rezozer.net
> AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B
> -BEGIN PGP SIGNATURE-
> 
> iQQcBAEBCgAGBQJX9uUQAAoJED+SGaZ/NsaL7W8f/i7CCIYZzleqbHqaCn1Hhz7V
> rCfXDVGuIfVsYoRQrFZX/w7DMOX6teiwwlOTiD4kwZc8YcwX+4E+ZkaHx4zCvqii
> QqFIXUWiVgJ+Z0+ZMdMi1X+ef708K5M/92iAKWBPFp6F2Kri7qJQsTwkrsVRMt7k
> RaldggeFiNTJfKqZFp6kLlh8acSFHOdccQ8/EAnBUT1Uz6xByWRofl1JA09zncZ/
> 4U7SaOH6p9Cfa3xa9SAN++BFDmOMjJ/J6NlJ6ieXg9+LV213l7WbU/hxD+YANtRu
> hICHZhvTNmX66S95nZKuPqCwla+CIEByO9p/973ocrrtQPktdyg+b8AV0vrkkxDA
> JmBxKiR3rwQs9oaN7er9zj2H97jMMJhH5THBbdWxXTSAAE645+x9G7M8sIq3CAxB
> feTaaXVElye8sKAU4PyI9smJrHs8GBKxmBWzf3hwsc+f11FjT7vgnt3NRTLs5oFH
> xN2xy/tvWAucnJXH7he7fJ+M9yh7jDidXlhS5NbzNrB5JeUdWkZL4mUGKS7sloXh
> KsGzaQ3OyaILpq4o79KGzl0vvYpxGLngTOlb+IITqsZVEVIwcW9CN4mr9bH7hLKt
> vzn9mEteOG3nADvQdUaBmJveuT5TcsHLE87rofCCjyo5LXzdzC0Ydtiph9UfDNX+
> pxBoEC/gCDSgEzQXSWGCbpkme3ZOlC1HK6vvp3g9lmoK0PO+a3yXvuxb+L36ixxL
> esWs92+kZUjPVcECd

Bug#840011: RFS (on ITP): node-typescript/2.0.5-1

[Julien Puydt]

Package: sponsorship-requests
Severity: wishlist

  Dear mentors,

  I am looking for a sponsor for my package "node-typescript"

 * Package name: node-typescript
   Version : 2.0.5-1
   Upstream Author : Microsoft Corp.
 * URL : http://typescriptlang.org/
 * License : Apache-2.0
   Section : web

  It builds those binary packages:

node-typescript - TypeScript is a language for application scale 
JavaScript develop


  To access further information about this package, please visit the 
following URL:


  https://mentors.debian.net/package/node-typescript


  Alternatively, one can download the package with dget using this command:

dget -x 
https://mentors.debian.net/debian/pool/main/n/node-typescript/node-typescript_2.0.5-1.dsc


  It is packaged within the Debian Javascript Maintainers' repository:
Vcs-Git: https://anonscm.debian.org/git/pkg-javascript/node-typescript.git
Vcs-Browser: 
https://anonscm.debian.org/cgit/pkg-javascript/node-typescript.git


 It is a new build-depend of my node-esprima package.

 Cheers,

Snark on #debian-js

Bug#840011: RFS (on ITP): node-typescript/2.0.5-1

[Gianfranco Costamagna]

control: owner -1 !
control: tags -1 moreinfo
>   I am looking for a sponsor for my package "node-typescript"



missing licenses?

cat ThirdPartyNoticeText.txt worries me

missing copyrights
Ecma, Sputnik and probably more

other stuff LGTM

G.

Bug#838679: marked as done (RFS: cysignals/1.1.1+ds-1 [ITP] -- interrupt and signal handling for Cython)

[Debian Bug Tracking System]

Your message dated Fri, 07 Oct 2016 22:36:42 +
with message-id 
and subject line closing RFS: cysignals/1.1.1+ds-1 [ITP] -- interrupt and 
signal handling for Cython
has caused the Debian Bug report #838679,
regarding RFS: cysignals/1.1.1+ds-1 [ITP] -- interrupt and signal handling for 
Cython
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.)


-- 
838679: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838679
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sponsorship-requests
Severity: wishlist

Dear Sponsor,

I am looking for sponsorship for the Debian package cysignals [0].
This package brings cysignals to Debian on behalf of the Debian
Python Modules Team. This is my very first Debian Python Module
package, so it might certainly be subject to some gross mistakes.
Its Alioth Git repository [1] has an experimental[-sage] branch
beside the master branch: the master branch is meant for the unstable
distribution, that is, to be exposed to a large audience; the
experimental[-sage] branch is meant to the Debian Sage[Math] Team [2].
More information can be found in d/README.source and d/README.Debian
as expected.

Thanks in advance,
Jerome

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834232
[1] https://anonscm.debian.org/git/python-modules/packages/cysignals.git
[2] https://wiki.debian.org/DebianScience/Sage

-- System Information:
Debian Release: Jessie*
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.7-ckt20-0001-mbp62 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
--- End Message ---
--- Begin Message ---
Package cysignals version 1.1.1+ds-1 is in unstable now.
https://packages.qa.debian.org/cysignals--- End Message ---

Bug#838679: [Debian-science-sagemath] Bug#838679: Fwd: Bug#838679: RFS: cysignals/1.1.1+ds-1 [ITP] -- interrupt and signal handling for Cython

[Jerome BENOIT]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Ximin, thanks for the upload.

Unfortunately an RC bug arised [1]. I have just resolved it [2].
Can review the new material and eventually upload it ?
Or give me the necessary privileges to uploas as DM ?

Thanks in advance,
Jerome


On 04/10/16 00:04, Ximin Luo wrote:
> Jerome BENOIT:
>> Hi Ximin, thanks again for the review and the suggestions.
>>
>> [..]
>>
>> For now I am looking for sponsorship, signed tagging the pertinent commit
>> makes thing clear.
>>
> 
> Built and uploaded, thanks for all the work! We should get some notification 
> emails from FTP soon.
> 
> X
> 

- -- 
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B
-BEGIN PGP SIGNATURE-

iQQcBAEBCgAGBQJX+FvaAAoJED+SGaZ/NsaLfjof/2fYa4/FFT5JNpkDFCbqTHwI
eZzUb24bNBvqui/7B3NMwktSm7RehDqgMt4aYT6RTpayB7NSYNA/+BFVzsQJI6OE
vR1lVBQ7veJTE7+5LqVNDUQO+dWtlQp68QKI6sSS63+IToHPNbx0CCTKKCCc7d5T
rOhNMV5AUSkdFxQeNfT4zKfjptNYgzzyZZ3Q8O0txUGLimqJcTBMgWQ3SRDkq2xd
KzlROMiHuoYS8k/sEUTLRdBgW7oTj4tqml5ucrEmHdCslOGEyzlH6QjE2fRj8FVH
daTv6epiQT4okYNWKQNziiehUI4xj2kmA+6sA11BzntE5fymh4Za9gy6l0C+WoHp
7fpKLBfPR316/4c30OsyLSL6i6oh7Mtq1RxSmTxDU1cLLt6dsan24LqTjCBPdEHW
9+wvFHzCFofjNTiU7eboft9O03xsk168hVPviG+kj5uDDo7Izm8L9uRrZkeyE2iq
AKR0pD4L8Cv+cCOL6D6+MC+NULWOk6VaAyiTO9Ehd04g14SK8GBJPL092JhCo+0P
Fj3HQslQb+R+MGe9iXplXuiq/KQkfqDIyKMS3Ha20TVI3Fgh1JkD16U4Alu6Xz/w
wiLGBISAw4tmDT8HYekhfiWbDm044iyPjfy3Pe63sckANYQ5A/URol6dkB8cSiOn
Dzse5JmAo+rQ2yf8/m4gkCB4cEHJxJwRxS7cs3UZlBk12mJBzSaXJ55yS1fcsTBe
Gh8CJWW6E9G33zzRVXupEWTGBnLe1vO41fFRNkUsPB150+aXBeicvo3k7rqrvRYj
qqB4Ybc7bYEY1Pn3gGZH865QFOs4hvEjebXNghc/03Vg9xjj1BVUW96V3sNDcmM9
xNnt2KLvMrMwB7v38yqK8gcFP8SJqr9cMvE1PZf8oBjNtabA1HGWwTsBnJaKyi/R
mBUevHmgMdR7qtXNcegK8tUjkCV6wPeAgSlKClvwDF/qEeFMgB9v4nYIfm33jinB
VT6hAPGiF4WgSbhWSevM6vIlvxeVAMIvWiI7HNqWGQKB7J0IUIe4lNZcJD1Cd7a7
98khuursS5fh0nNvH4hmOnCrqYohAU5UVDwXK7dYQu9NT+gErjMj6XMzWlptFNH4
skapLUCPOdHnxR1SHmW9qM8FXN52fmIsXNKyc5xVZzNpLGi7m8p+24ek2gFVALe+
3+NHBXotfBBnBbyXoDRnd5ZzWYFolzOgUdLhM42uLua3KxoqERRakOQ68hFTZDRf
/9gCXOgpQHlRZPCTCzHCj6sxry3En6vJY/exZ1+qa0FHq/wmXeaTOPOeUH7sN+JJ
w1Tikymk8LvudwV5ytB9TbPJBbiZks7l56FoGPDcaIEvni+7mPru8/sqvvCu0Tc=
=Y4lX
-END PGP SIGNATURE-

Bug#839833: marked as done (RFS: gkeyring/0.4-1-gf4ce4c7-1 [ITP])

[Debian Bug Tracking System]

Your message dated Sat, 8 Oct 2016 11:26:56 +0800
with message-id 

and subject line Re: Bug#839833: RFS: gkeyring/0.4-1 [ITP]
has caused the Debian Bug report #839833,
regarding RFS: gkeyring/0.4-1-gf4ce4c7-1 [ITP]
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.)


-- 
839833: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839833
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 "gkeyring"

* Package name: gkeyring
  Version : 0.4-1
  Upstream Author : Kamil Páral
* URL : https://github.com/kparal/gkeyring
* License : AGPL-3.0+
  Section : gnome

It builds those binary packages:

  gkeyring   - Tool for shell access to GNOME keyring

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/gkeyring

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/g/gkeyring/gkeyring_0.4-1.dsc

Changes since the last upload:

  * Initial release. (Closes: #711344)

Regards,

Yann Soubeyrand
--- End Message ---
--- Begin Message ---
On Fri, Oct 7, 2016 at 5:14 PM, SOUBEYRAND Yann - externe wrote:

> Thank you for your interest in sponsoring this package ;-)

No, thank you for being willing to package and maintain it!

> I uploaded a new version which should address the most important
> concerns you raised

Great, built, signed and uploaded it to NEW:

http://ftp-master.debian.org/new.html

Once the package reaches Debian, please add debtags and screenshots:

https://debtags.debian.org/
https://screenshots.debian.net/

For future updates, please file an RFS bug as usual.

> Vcs-Git: https://github.com/yann-soubeyrand/gkeyring.git

Please upload your Debian packaging to this repository.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise--- End Message ---