Re: Data updates in debian packages

[Russ Allbery]

Christian Seiler  writes:
> On 10/30/2016 10:20 AM, Ole Streicher wrote:

>> IETF is responsible for internet standards, not for leap seconds. They
>> will take the leap seconds from IERS. I would assume that this
>> connection is well-established to rely on it. I was not so much
>> questioning upstream here, but I worry a bit about the Debian package
>> for tzdata: how sure can I be that the tzdata is actual (wrt upstream)?

> Regular stable updates (via stable/updates, not only point releases)
> happen for that package, in addition to regular uploads to unstable.
> See the timeline in:
> https://tracker.debian.org/pkg/tzdata

> From what I can tell, this is probably the package that's updated in
> stable most consistently in the entirety of Debian. I would really
> recommend that you rely on tzdata directly, this will also save the
> release team a lot of work. (It's much easier for them to approve just a
> single package than 100 packages that need the time zone and/or leap
> second information.)

Speaking as a long-time lurker of the tz mailing list, I would recommend
confirming with upstream that they intend to be a timely (enough) source
for leap second information, as I believe that has been a bit
controversial.  Note that leap second information is used in the tzdata
package for a fairly ancillary purpose (the maintenance of the "right"
time zones, which almost no one uses), and is not a primary goal of the
project.

tzdata definitely just takes a copy of leap second information from IERS
(actually, I think they may pull the data from NIST, which gets it from
IERS).  IERS is the correct upstream source.

If many Debian packages want a high-quality, timely source of leap
seconds, it might be better to have a separate package devoted to that, so
that any update timeliness is not entangled with issues with tzdata.  That
said, tzdata is, as mentioned, a very reliably updated package in Debian
stable releases, so if upstream is willing, maybe it's fine to rely on
that.

The required timeliness depends a lot on what you're using leap seconds
for, and in particular if you need to know about them far in advance, or
if it's only necessary to have an updated table before the leap second
itself arrives.

-- 
Russ Allbery (r...@debian.org)   

RE: get 403 Forbidden when upload package to mentors.

[Xu, Guangxin]

Hi G.
Thanks for reply. You are right, now I can upload the file now. However, it 
still failed, seems I can only upload the .dsc file. The tar.gz will have HTTP 
503 error. Do you have any suggestion?



Command details:
gxxu@zion-debian:~/works/pbuild/libyami$ tsocks dput -f  mentors 
libyami_1.0.0-1_source.changes
Checking signature on .changes
gpg: Signature made Tue 18 Oct 2016 02:42:44 AM PDT using RSA key ID FF093896
gpg: Good signature from "Xu Guangxin "
Good signature on 
/home/gxxu/works/pbuild/libyami/libyami_1.0.0-1_source.changes.
Checking signature on .dsc
gpg: Signature made Tue 18 Oct 2016 02:42:40 AM PDT using RSA key ID FF093896
gpg: Good signature from "Xu Guangxin "
Good signature on /home/gxxu/works/pbuild/libyami/libyami_1.0.0-1.dsc.
Uploading to mentors (via http to mentors.debian.net):
  Uploading libyami_1.0.0-1.dsc: done.
  Uploading libyami_1.0.0.orig.tar.gz: Upload failed: 503 Service Unavailable

> -Original Message-
> From: Gianfranco Costamagna [mailto:locutusofb...@debian.org]
> Sent: Friday, October 28, 2016 4:56 PM
> To: Xu, Guangxin ; debian-mentors@lists.debian.org
> Cc: Yu, Jiankang ; Li, Jocelyn 
> Subject: Re: get 403 Forbidden when upload package to mentors.
> 
> Hi,
> 
> >I am trying to upload debian package to mentors.debian.net. However, I got
> some 403 error. I checked ftp://mentors.debian.net/. It have some zero size 
> file.
> >The entire directory just like this:
> >Oct 28 2016 06:320 libyami-utils_1.0.0-1.debian.tar.xz
> >Oct 28 2016 05:26 1562 libyami-utils_1.0.0-1.dsc
> >Oct 28 2016 07:100 libyami-utils_1.0.0-1_source.changes
> >Oct 28 2016 05:280 libyami-utils_1.0.0.orig.tar.gz
> 
> 
> you can't dcut on mentors, but when you upload the changes file, in some
> minutes the system picks it up and accept/rejects it.
> 
> So, just wait for them to disappear and try again with -f :)
> 
> G.

Re: Re: Finding the correct alignment for all architectures

[Thomas Weber]

Thanks guys, I went with _Alignof(double), which interestingly aligns to
8 bytes on amd64.

Thomas

Bug#842597: marked as done (RFS: [RC] pythonmagick/0.9.14-1)

[Debian Bug Tracking System]

Your message dated Sun, 30 Oct 2016 23:48:03 +
with message-id <20161030234801.qh4u2xsiwlo45...@chase.mapreri.org>
and subject line Re: Bug#842597: RFS: [RC] pythonmagick/0.9.14-1
has caused the Debian Bug report #842597,
regarding RFS: [RC] pythonmagick/0.9.14-1
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.)


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

Dear mentors,

  I am looking for a sponsor for my package "pythonmagick"

 * Package name: pythonmagick
   Version : 0.9.14-1
   Upstream Author : imagemagick team
 * URL : www.imagemagick.org
 * License : imagemagick (apache)
   Section : python

  It builds those binary packages:

python-pythonmagick - Object-oriented Python interface to ImageMagick

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

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


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

dget -x https://mentors.debian.net/debian/pool/main/p/pythonmagick/
pythonmagick_0.9.14-1.dsc

  More information about hello can be obtained from https://
www.imagemagick.org

  Changes since the last upload:


  pythonmagick (0.9.14-1) unstable; urgency=medium

  * Switch watch to .xz and add signature check
  * Add myself as uploader.
  * Switch to git-dpm.
  * Bump Standards-Version no changes.
  * New upstream release:
- Bug fix: "FTBFS with newer experimental version of imagemagick",
  thanks to Bastien ROUCARIES (Closes: #840428).

 -- Bastien Roucariès   Sun, 30 Oct 2016 
15:38:54 +0100



  Regards,
   bastien roucaries


signature.asc
Description: This is a digitally signed message part.
--- End Message ---
--- Begin Message ---
On Sun, Oct 30, 2016 at 09:03:33PM +0100, roucaries bastien wrote:
> > * switch to pybuild for building
> 
> 
> Do you have an example with autoconf ?

Followed up on IRC, uploaded now.

-- 
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
--- End Message ---

Bug#842597: RFS: [RC] pythonmagick/0.9.14-1

[roucaries bastien]

On Sun, Oct 30, 2016 at 6:36 PM, Mattia Rizzolo  wrote:
> control: tag -1 moreinfo
> control: owner -1 !
>
> On Sun, Oct 30, 2016 at 06:11:01PM +0100, Bastien ROUCARIÈS wrote:
>>   I am looking for a sponsor for my package "pythonmagick"
>
> o/
>
>>   Alternatively, one can download the package with dget using this command:
>>
>> dget -x https://mentors.debian.net/debian/pool/main/p/pythonmagick/
>> pythonmagick_0.9.14-1.dsc
>
> given this package is in dpmt I'll stick to git instead.
>
>>   * Switch watch to .xz and add signature check
>
> please instead make use of uscan's @ARCHIVE_EXT@ substitution variable.
Ok
>
>>   * Add myself as uploader.
>>   * Switch to git-dpm.
>>   * Bump Standards-Version no changes.
>>   * New upstream release:
>> - Bug fix: "FTBFS with newer experimental version of imagemagick",
>>   thanks to Bastien ROUCARIES (Closes: #840428).
>
> I find weird thanking yourself here :)
ok
> Also, the upstream bug that you linked in the debian bug is still open
> with no comments, how come?
Due to transient bug in toolchain fixed now. New upstream is needed

> moreover:
>
> * please bump debhelper compat level to 10
ok
> * switch to pybuild for building


Do you have an example with autoconf ?

> * README.source is now completely useless
ok
> * I wouldn't mind seeing the build-deps sorted
ok
> * merge the UNRELEASED changelog entry into yours
ok

>
> Then, does this package build with python3?  If so please add a python3-
> package.
>
> --
> 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  `-

Bug#832704: RFS: nixnote2

[Sean Whitton]

Dear Boyuan,

On Wed, Sep 21, 2016 at 07:25:22PM -0700, Sean Whitton wrote:
> I just reviewed the latest changes in your nixnote2 git repo, as part of
> confirming that nixnote2 works with the new qevercloud shlib.
> 
> I have the following remaining suggestions (none are "must fix"):

Are you waiting on qevercloud to make it through NEW to work on these?

I think it would be best to get nixnote2 into NEW sooner than that.  The
ftp-masters are probably planning to empty the queue before the soft
freeze, but there might not be enough time between the emptying of NEW
and the soft freeze to get nixnote in.  It would be a shame if
qevercloud went into stretch and nixnote2 didn't!

It's fine for packages that depend on other to be in NEW so long as the
dependency relationships are not complicated.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Non-NEW backports rejected with "ACL dm: NEW uploads are not allowed"

[Peter Colberg]

On Sun, Oct 30, 2016 at 12:04:16AM -0400, Peter Colberg wrote:
> Dear mentors,
> 
> I am trying to update the following packages in jessie-backports:
> 
> gbp clone --debian-branch=debian/jessie-backports 
> https://anonscm.debian.org/git/pkg-go/packages/golang-gopkg-cheggaaa-pb.v1.git
> gbp clone --debian-branch=debian/jessie-backports 
> https://anonscm.debian.org/git/pkg-go/packages/golang-github-fatih-color.git
> 
> Older versions of the packages already exist in jessie-backports. My
> key has been added to the backports ACL (and has worked for similar
> updates in the past), and I have DM upload rights for the packages.

With Distribution: jessie-backports, golang-gopkg-cheggaaa-pb.v1 has
now been accepted. But golang-github-fatih-color is still rejected
with the same error "ACL dm: NEW uploads are not allowed". I tried
uploading the latter both without and with an orig tarball.

I attached once more the (unsigned) .changes file.

Thanks,
Peter
Format: 1.8
Date: Sun, 16 Oct 2016 14:12:31 -0400
Source: golang-github-fatih-color
Binary: golang-github-fatih-color-dev
Architecture: source all
Version: 1.0.0-2~bpo8+1
Distribution: jessie-backports
Urgency: medium
Maintainer: Debian Go Packaging Team 

Changed-By: Peter Colberg 
Description:
 golang-github-fatih-color-dev - console colors for Go
Changes:
 golang-github-fatih-color (1.0.0-2~bpo8+1) jessie-backports; urgency=medium
 .
   * Rebuild for jessie-backports.
 .
 golang-github-fatih-color (1.0.0-2) unstable; urgency=medium
 .
   * Remove Built-Using field from -dev package
 .
 golang-github-fatih-color (1.0.0-1) unstable; urgency=medium
 .
   * New upstream release
   * Add watch file to track upstream releases
   * Update Standards-Version to 3.9.8
Checksums-Sha1:
 5b996758c17f623560220620f0d717d0507c31ef 1445 
golang-github-fatih-color_1.0.0-2~bpo8+1.dsc
 52e30378a7414b42871e029dd3c5133d92d4ce74 7173 
golang-github-fatih-color_1.0.0.orig.tar.gz
 5551c4686224c9ae75825e7581411186c1c745fd 2064 
golang-github-fatih-color_1.0.0-2~bpo8+1.debian.tar.xz
 420246a66f7f58d6f60c671c80b1944c110de0de 8320 
golang-github-fatih-color-dev_1.0.0-2~bpo8+1_all.deb
Checksums-Sha256:
 fa8896e3e25b0e02ae979718943b0d827e725365d691e913f5f16b20f9c34aa5 1445 
golang-github-fatih-color_1.0.0-2~bpo8+1.dsc
 035f20ae3e9940416433ba4c3d9cb55511608a1ac3927e371be61fe5d6052590 7173 
golang-github-fatih-color_1.0.0.orig.tar.gz
 04aaffed43585cac00ca71dd16301cda009bcded5277efcc4fb59c3adc89e825 2064 
golang-github-fatih-color_1.0.0-2~bpo8+1.debian.tar.xz
 d0033dd543faf9610aa00f699e91513845ce80bc9bfad2f5c8d88a9ab4b31ba2 8320 
golang-github-fatih-color-dev_1.0.0-2~bpo8+1_all.deb
Files:
 3eb405e3dc4552b0e8c7d62eb83a0daa 1445 devel extra 
golang-github-fatih-color_1.0.0-2~bpo8+1.dsc
 449000448b8dcc366b70258c29b36ea5 7173 devel extra 
golang-github-fatih-color_1.0.0.orig.tar.gz
 77b05e25cc020d700133304b586608e1 2064 devel extra 
golang-github-fatih-color_1.0.0-2~bpo8+1.debian.tar.xz
 d56de4160d4a4f7dbe7e056c370a8224 8320 devel extra 
golang-github-fatih-color-dev_1.0.0-2~bpo8+1_all.deb

Bug#842597: RFS: [RC] pythonmagick/0.9.14-1

[Mattia Rizzolo]

control: tag -1 moreinfo
control: owner -1 !

On Sun, Oct 30, 2016 at 06:11:01PM +0100, Bastien ROUCARIÈS wrote:
>   I am looking for a sponsor for my package "pythonmagick"

o/

>   Alternatively, one can download the package with dget using this command:
> 
> dget -x https://mentors.debian.net/debian/pool/main/p/pythonmagick/
> pythonmagick_0.9.14-1.dsc

given this package is in dpmt I'll stick to git instead.

>   * Switch watch to .xz and add signature check

please instead make use of uscan's @ARCHIVE_EXT@ substitution variable.

>   * Add myself as uploader.
>   * Switch to git-dpm.
>   * Bump Standards-Version no changes.
>   * New upstream release:
> - Bug fix: "FTBFS with newer experimental version of imagemagick",
>   thanks to Bastien ROUCARIES (Closes: #840428).

I find weird thanking yourself here :)
Also, the upstream bug that you linked in the debian bug is still open
with no comments, how come?

moreover:

* please bump debhelper compat level to 10
* switch to pybuild for building
* README.source is now completely useless
* I wouldn't mind seeing the build-deps sorted
* merge the UNRELEASED changelog entry into yours


Then, does this package build with python3?  If so please add a python3-
package.

-- 
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

Bug#841222: Acknowledgement (RFS: patat)

[Sean Whitton]

Hello Félix,

I noticed that you've published your patch-queue/master branch.  Since
that is a branch you will rebase, it's not a good idea to publish it
(the gbp documentation recommends against publishing it).  Anyone who
needs the branch can reconstruct it with `gbp pq import`.

Unfortunately, patat doesn't build against sid at present.  Hopefully
this will be resolved within the next week or so.  In the meantime,
there is some stuff you can improve:

On Tue, Oct 25, 2016 at 10:34:11PM +0200, Félix Sipma wrote:
> On 2016-10-23 11:51-0700, Sean Whitton wrote:
> > You should use "Forwarded: not-needed" (see DEP-3).
> 
> This does not seem to work with gbp-pq (see #785274), I propose to add this as
> soon as gbp-pq supports DEP-3.

Indeed.  Dmitry Bogatov pointed out to me that you can put the
Forwarded: header at the end of the patch description (just before the
---) and then gbp won't remove it.

I wanted to confirm that you'd forwarded your --version patch, but I
couldn't without this header :)

> >>> 2. You can fix all of these Lintian tags, except possibly
> >>> hardening-no-fortify-functions.  You should definitely deal with
> >>> the warnings.
> >>> 
> >>> W: patat-dbgsym: debug-file-with-no-debug-symbols
> >> 
> >> I've updated debian/rules to something matching
> >> stylish-haskell.

Your d/rules is fine, though I think that the override_dh_compress stanza
is not needed: policy says you should only compress files above a
certain size, and presumably dh_compress isn't compressing the README
because it is smaller than that size.

On the next upload of stylish-haskell I will probably remove that
stanza -- sorry to mislead you!

> >>> I: patat: spelling-error-in-binary usr/bin/patat Nam Name
> >>> I: patat: spelling-error-in-binary usr/bin/patat isn't isn't
> >>> I: patat: spelling-error-in-binary usr/bin/patat forward forward
> >>> I: patat: spelling-error-in-binary usr/bin/patat upto up to
> >>> I: patat: spelling-error-in-binary usr/bin/patat discontigous 
> >>> discontiguous
> >>> I: patat: spelling-error-in-binary usr/bin/patat uncomplete incomplete
> >>> I: patat: spelling-error-in-binary usr/bin/patat The The
> >> 
> >> Not sure about this one... Is "patat" too generic for lintian? I've
> >> added this to debian/lintian-overrides.
> > 
> > I don't understand.  It is pointing out misspellings, such as
> > 'uncomplete', somewhere in the upstream source.  You can add a quilt
> > patch to fix them, and forward it upstream.
> 
> As I didn't found anything matching these errors in the source, I thought it
> was a generic error message concerning the binary name.
> 
> Now, that I understood the purpose of this check, I can only found these
> mistakes in the binary itself, so I guess these are in the dependencies...

Okay.  In that case you should override them, with a comment in the
overrides file explaining why.

> >>> I: patat: hardening-no-bindnow usr/bin/patat I: patat:
> >>> hardening-no-pie usr/bin/patat
> >>> 
> >>> I think that in order to pass hardening options to gcc, if you're
> >>> willing to work on that, you'll need to abandon the CDBS build system
> >>> you're using at present.  See the Makefile for keysafe[1] (not yet in
> >>> Debian) to see how to pass the options, and the rules file for the
> >>> stylish-haskell package to see how to do without CDBS.
> >> 
> >> After reading this Makefile, I'm not sure how keysafe avoids
> >> hardening-no-bindnow and hardening-no-pie... Do you have any clue?
> > 
> > The Makefile propagates LDFLAGS, CFLAGS and CPPFLAGS through to ghc.
> > Then you enable all hardening in your d/rules,[1] and the right flags
> > get set by debhelper.
> > 
> > [1] https://wiki.debian.org/Hardening
> 
> I would like to wait a little before adding this: the default flags added to
> gcc seems quite new, so I propose to have a look again when things stabilize.

Fair enough.

FWIW keysafe's hardening is working fine, except for PIE, which has to
be disabled for Haskell atm.  https://git.spwhitton.name/keysafe

> >>> 3. Please run upstream's test suite during the package build.
> >> 
> >> Should be done now, I'm not sure about how I run tests... See
> >> debian/rules override_dh_auto_test

Okay.  I can't test this atm because patat can't be built in sid, but
what you did looks sane.

> > If help2man is insufficient, see again stylish-haskell where I use
> > asciidoctor.
> 
> I'll try to add a manpage using help2man.

A few of comments on your manpage:

1. Have you forwarded it upstream?

2. Did you generate it with help2man, in the end?  If so, there should
be a rule in d/rules to allow someone to regenerate the manpage for a
new upstream version (see the ocrmypdf package's rules file).  If
upstream introduces a new upstream version it should be easy to update
the manpage.

3. It might be nice to add a reference to the file in
/usr/share/doc/patat/examples to the manpage.  If I wanted to learn how
to use patat, the manpage alone wouldn't be much use.

> Concerning DHG's 

Bug#842597: RFS: [RC] pythonmagick/0.9.14-1

[Bastien ROUCARIÈS]

Package: sponsorship-requests
Severity: important

Dear mentors,

  I am looking for a sponsor for my package "pythonmagick"

 * Package name: pythonmagick
   Version : 0.9.14-1
   Upstream Author : imagemagick team
 * URL : www.imagemagick.org
 * License : imagemagick (apache)
   Section : python

  It builds those binary packages:

python-pythonmagick - Object-oriented Python interface to ImageMagick

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

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


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

dget -x https://mentors.debian.net/debian/pool/main/p/pythonmagick/
pythonmagick_0.9.14-1.dsc

  More information about hello can be obtained from https://
www.imagemagick.org

  Changes since the last upload:


  pythonmagick (0.9.14-1) unstable; urgency=medium

  * Switch watch to .xz and add signature check
  * Add myself as uploader.
  * Switch to git-dpm.
  * Bump Standards-Version no changes.
  * New upstream release:
- Bug fix: "FTBFS with newer experimental version of imagemagick",
  thanks to Bastien ROUCARIES (Closes: #840428).

 -- Bastien Roucariès   Sun, 30 Oct 2016 
15:38:54 +0100



  Regards,
   bastien roucaries


signature.asc
Description: This is a digitally signed message part.

Re: Non-NEW backports rejected with "ACL dm: NEW uploads are not allowed"

[Peter Colberg]

On Sun, Oct 30, 2016 at 11:19:41AM +0100, Christian Seiler wrote:
> I would recommend to use dput from dput-ng instead of plain old
> dput, because that will catch the discrepancy between the distribution
> in the changelog and the changes file. It prints a nice error message
> explaining the problem, before the package is even uploaded.

Thanks for the pointer!

Peter

Re: Non-NEW backports rejected with "ACL dm: NEW uploads are not allowed"

[Peter Colberg]

On Sun, Oct 30, 2016 at 10:11:06AM +, Mattia Rizzolo wrote:
> from the first .changes:
> 
> | Distribution: jessie
> 
> that's wrong, you are trying to upload to the stable distribution,
> instead of jessie-backports.
> 
> Am I right that you used sbuild with -D to build this package?

Thanks, that’s it. I was using --dist=jessie since the chroot is
named jessie-amd64-sbuild. I have added to the schroot config

aliases=jessie-backports-amd64-sbuild

so the chroot is now selected automatically.

Peter

Bug#842588: RFS: photo-booth/1.0.1~rc1-1 [ITP Bug#788954]

[Adam Wight]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "photo-booth"

 * Package name: photo-booth
   Version : 1.0.1~rc1-1
   Upstream Author : Adam Roses Wight 
 * URL : https://github.com/adamwight/photo-booth
 * License : GPL-3
   Section : graphics

It builds these binary packages:

  photo-booth - Self-serve photo booth software

To access further information about this package, please visit the
following URL:
https://mentors.debian.net/package/photo-booth

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/photo-booth/photo-booth_1.0.1~rc1-1.dsc

  More information about photo-booth can be obtained from
https://github.com/adamwight/photo-booth

  Changes since the last upload:

  * Fix most lintian warnings.

Thank you,
Adam Roses Wight

Bug#842160: marked as done (RFS: python-memory-profiler/0.41+git20161018-1 [RC])

[Debian Bug Tracking System]

Your message dated Sun, 30 Oct 2016 10:56:03 +
with message-id <20161030105601.jgoypavwgqqhd...@chase.mapreri.org>
and subject line Re: Bug#842160: RFS: python-memory-profiler/0.40-1 [RC]
has caused the Debian Bug report #842160,
regarding RFS: python-memory-profiler/0.41+git20161018-1 [RC]
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.)


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

Dear mentors,


I am looking for a sponsor for my package "python-memory-profiler":

* Package name: python-memory-profiler
  Version : 0.40-1
  Section : python

It builds those binary packages:

 python-memory-profiler - memory consumption analysis for Python programs 
(Python 2 build)
 python3-memory-profiler - memory consumption analysis for Python programs 
(Python 3 build)

Download the package with dget using this command:

dget -x 
https://people.debian.org/~cwryu/debian/python-memory-profiler_0.40-1.dsc

Or you can use the alioth git:

https://anonscm.debian.org/git/users/cwryu/python-memory-profiler.git


Changes since the last upload:

  * New upstream release
  * debian/*: Clean up the pybuild build (Closes: #804442)
  * debian/*: lintian fixes
- Standard-Version: 3.9.8
- Add missing source format
- Use new https addresses for Vcs-* fields
- Rename /usr/bin/mprof to /usr/bin/{python,python3}-mprof


My new gpg key is not in the keyring yet since the weak key 
removal so I can't upload this update myself. RFS.
--- End Message ---
--- Begin Message ---
On Sun, Oct 30, 2016 at 01:44:55AM +0900, Changwoo Ryu wrote:
> Here is the fixed/updated version:
> https://anonscm.debian.org/git/users/cwryu/python-memory-profiler.git/

there, uploaded, enjoy!

-- 
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
--- End Message ---

Re: Non-NEW backports rejected with "ACL dm: NEW uploads are not allowed"

[Christian Seiler]

On 10/30/2016 11:11 AM, Mattia Rizzolo wrote:
> On Sun, Oct 30, 2016 at 12:04:16AM -0400, Peter Colberg wrote:
>> Older versions of the packages already exist in jessie-backports. My
>> key has been added to the backports ACL (and has worked for similar
>> updates in the past), and I have DM upload rights for the packages.
>>
>> My uploads for both packages were rejected with "ACL dm: NEW uploads
>> are not allowed". I tried two times each, on October 16 and today, to
>> rule out temporary errors. Do you have any idea what I am missing?
>>
>> I attached the (unsigned) .changes files for the attempted uploads.
> 
> from the first .changes:
> 
> | Distribution: jessie
> 
> that's wrong, you are trying to upload to the stable distribution,
> instead of jessie-backports.

I would recommend to use dput from dput-ng instead of plain old
dput, because that will catch the discrepancy between the distribution
in the changelog and the changes file. It prints a nice error message
explaining the problem, before the package is even uploaded.
(I accidentally stumbled over that yesterday, due to sbuild -d sid
but changelog having unstable in it.)

Regards,
Christian

Re: Non-NEW backports rejected with "ACL dm: NEW uploads are not allowed"

[Mattia Rizzolo]

On Sun, Oct 30, 2016 at 12:04:16AM -0400, Peter Colberg wrote:
> Older versions of the packages already exist in jessie-backports. My
> key has been added to the backports ACL (and has worked for similar
> updates in the past), and I have DM upload rights for the packages.
> 
> My uploads for both packages were rejected with "ACL dm: NEW uploads
> are not allowed". I tried two times each, on October 16 and today, to
> rule out temporary errors. Do you have any idea what I am missing?
> 
> I attached the (unsigned) .changes files for the attempted uploads.

from the first .changes:

| Distribution: jessie

that's wrong, you are trying to upload to the stable distribution,
instead of jessie-backports.

Am I right that you used sbuild with -D to build this package?

-- 
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: Data updates in debian packages

[Ole Streicher]

On 30.10.2016 04:38, Paul Wise wrote:
> On Sat, Oct 29, 2016 at 8:45 PM, Ole Streicher wrote:
>> The update script itself could even be distributed with the casacore
>> package itself. And for simplicity I would make
>> casacore-data-autoupdater a binary package within the casacore source
>> package (since this is the main dependency anyway).
>>
>> Comments on that? What would be the best dependency specification then?
>> casacore-data-autoupdater "suggests" casacore-data-XXX and/ore vice-versa?
> 
> casacore-data-autoupdater Enhances: casacore-data-XXX

Isn't this redundant? I always thought that "Enhances" is just the
reverse of "Suggests" ("A enhances B  <=> B suggests A").
The disadvantage of "Enhances" would be that it would need to know which
packages there are -- so every time a new data package is added, we
would need to update the updater package.

> casacore-data-XXX Recommends: casacore-data-autoupdater

This would raise privacy concerns, since recommended packages are
installed by default, and this one would connect to some .mil domain
servers. Why not "suggests"?

>>> Make sure that any security/privacy consequences of the non-apt update
>>> method are dealt with.
>>
>> If you have comments on my proposal, please comment.
> 
> I don't know enough about the formats and the download processes to comment.

Formats, download processes and further processing are data dependent
(and therefore part of the casacore-data-XXX package). The autoupdater
would just execute the update scripts that need to be provided by the
individual packages.

Best regards

Ole

Re: Data updates in debian packages

[Christian Seiler]

On 10/30/2016 10:20 AM, Ole Streicher wrote:
> IETF is responsible for internet standards, not for leap seconds. They
> will take the leap seconds from IERS. I would assume that this
> connection is well-established to rely on it. I was not so much
> questioning upstream here, but I worry a bit about the Debian package
> for tzdata: how sure can I be that the tzdata is actual (wrt upstream)?

Regular stable updates (via stable/updates, not only point releases)
happen for that package, in addition to regular uploads to unstable.
See the timeline in:
https://tracker.debian.org/pkg/tzdata

>From what I can tell, this is probably the package that's updated in
stable most consistently in the entirety of Debian. I would really
recommend that you rely on tzdata directly, this will also save the
release team a lot of work. (It's much easier for them to approve
just a single package than 100 packages that need the time zone
and/or leap second information.)

Regards,
Christian

Re: Data updates in debian packages

[Ole Streicher]

On 30.10.2016 04:42, Paul Wise wrote:
> On Sun, Oct 30, 2016 at 4:36 AM, Ole Streicher wrote:
> 
>> The canonical source for leap seconds is the IERS. Our current plan was
>> to take the leap second list from there and build our package from this
>> (as it is done in the casacore-data upstream). This guaranteed that we
>> always have the actual definition (... as long as we do our updated
>> package ASAP).
>>
>> When we switch that to tzdata, then we get the leap second from a place
>> that is not strictly the original source, but may have some delay: first
>> the tzdata upstream package needs to be updated, and then it needs to be
>> packaged (... and possibly backported).
>>
>> So my question is: how safe is it to assum that this whole process is
>> quick (let's say: a few weeks)? If someone works later on Stretch and
>> has an outdated leap second, this could cause problems. Especially if he
>> has no direct information about the actuality of the leap second
>> definition (which he would have in the case of an leap second package
>> taking the value directly from IERS -- we could use the date of the
>> announcement as version number there).
> 
> Where does the IERS data come from?

IERS is the instance which actually decides about the leap second,
namely by this file:

ftp://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat

I couldn't find the original source now, but see f.e. wikipedia: "Among
its other functions, the IERS is responsible for announcing leap seconds."

> I think the tzdata version of the data comes from the IETF:

IETF is responsible for internet standards, not for leap seconds. They
will take the leap seconds from IERS. I would assume that this
connection is well-established to rely on it. I was not so much
questioning upstream here, but I worry a bit about the Debian package
for tzdata: how sure can I be that the tzdata is actual (wrt upstream)?

Best regards

Ole

Bug#837748: kpm core updates

[Jonathan Carter (highvoltage)]

I have the latest work of this in:
https://gitlab.com/highvoltage/kpmcore-packaging/tree/master/debian

I haven't figured out what the best way is to deal with the symbol
files, but I'll ask for help from the debian-kde team and also move that
repository to the KDE team if that's possible.

Bug#842531: RFS: gnome-shell-extension-impatience/0.4.3-1, ITP: 842014 -- speed up the gnome-shell animation speed

[Jonathan Carter (highvoltage)]

Package: sponsorship-requests
Severity: wishlist

Dear mentors (cc debian-python),

I am looking for a sponsor for my package "bundlewrap":

* Package name: gnome-shell-extension-impatience
  Version : 0.4.3-1
  Upstream Author : Tim Cuthbertson 
* URL : https://github.com/timbertson/gnome-shell-impatience
* License : GPL-3
  Programming Lang: Javascript
  Description : speed up the gnome-shell animation speed

It builds the following binary package:

gnome-shell-extension-impatience - speed up the gnome-shell animation speed

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

https://mentors.debian.net/package/gnome-shell-extension-impatience

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

dget -x
https://mentors.debian.net/debian/pool/main/g/gnome-shell-extension-impatience/gnome-shell-extension-impatience_0.4.3-1.dsc

You can also find me (highvoltage) on #debian-mentors.

Thanks for your time and patience!

-Jonathan