[pkg-go] Bug#799128: ITP: golang-github-juju-ratelimit -- Efficient token-bucket-based rate limiter module for Go

2015-09-15 Thread Potter, Tim (Cloud Services) 
Package: wnpp
Severity: wishlist
Owner: Tim Potter 
X-Debbugs-CC: pkg-go 

* Package name: golang-github-juju-ratelimit
 Version : 0.0~git20150619
 Upstream Author : Roger Peppe
* URL : https://github.com/juju/ratelimit
* License : LGPL-3 with static linking exception
 Programming Lang: Go
 Description : Efficient token-bucket-based rate limiter module for Go

The ratelimit package provides an efficient token bucket
implementation in Go. The token bucket algorithm implements a
method for ensuring a reader or writer does not exceed a
specified rate limit when reading or writing.

___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

Re: [pkg-go] Various problems with packages in the group

2015-09-15 Thread Dmitry Smirnov 
On Tuesday 15 September 2015 11:28:01 Martín Ferrari wrote:
> On 14/09/15 12:25, Dmitry Smirnov wrote:
> > My solution to that supper-annoying problem is to keep Debian packaging
> > (i.e. "debian/*" files) and upstream files apart, unmerged. Therefore
> > "master" branch will contain only debian packaging and "upstream" branch
> > holds
> > upstream changes. Simply add the following to your "debian/gbp.conf" 
file:
> The problem with this (apart that I find it much more annoying not to
> have the source), is inconsistency. I think the team should either keep
> all the sources or none. Otherwise, one has to deal with N different
> packaging workflows, and that does not scale.

What is the problem with minor inconsistency if there is no difference in how 
package is built? It is the same git repository and most of actions will be 
the same (unlike SVN repositories for example). Besides merging upstream 
sources is separate effort that have little to do with packaging. If we want 
learning curve to be less steep we need to avoid require maintainer to be 
profoundly experienced with git. I still remember my frustration when I got 
my first merge error on importing upstream tarball and hours I wasted in 
order to resolve the problem instead of doing meaningful work on package.

What do we achieve by having upstream sources in "master"?

Besides we are all have our preferences and I do not wish to impose mine on 
others. There is such thing as Maintainer's comfort and convenience -- I 
believe it matters more than minor inconsistency. We already have those 
inconsistencies -- like you've said some packages need two upstream branches 
and some don't. I'd argue that when `uscan` works one needs no "upstream" 
branch at all but of course there is no harm to have local upstream branch or 
to push DFSG-compliant upstream branch (if it is not too heavy) to shared 
repository. It should be decided on case-to-case basis by maintainers.

I want to mention KDE team again -- they have to work with non-DFSG packages 
with over 20_000 files (e.g. Calligra) and it is such a hassle to import 
upstream sources that they've decided to make it a team's policy to track 
only packaging. As result their repositories are very small.

Once again, I believe we should allow small variations in repository layout 
for best maintainer's convenience.


> For repackaging, what I do instead is to keep an upstream branch that
> follows upstream git history, and from there create a 'repackaged'
> branch that has all the needed removals. It has some work when merging
> in an extra version, but in general it is pretty straightforward and
> keeps a record of how the source was changed.

I think it is a labour intensive, and requires you to track non-DFSG changes 
as well as repackaged ones. I do not want to have non-DFSG stuff in 
repositories at all. Also to avoid bloating public repository I do not want 
to store upstream history -- not everyone needs upstream branch unless of 
course there are no formal upstream releases...

-- 
All the best,
 Dmitry Smirnov.

---

Few people are capable of expressing with equanimity opinions which
differ from the prejudices of their social environment. Most people are
even incapable of forming such opinion.
-- Albert Einstein, from "Aphorisms for Leo Baeck;
   Opinions of Albert Einstein"


signature.asc
Description: This is a digitally signed message part.
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

Re: [pkg-go] Various problems with packages in the group

2015-09-15 Thread Martín Ferrari 
On 14/09/15 13:07, Dmitry Smirnov wrote:

> However most of Perl packages are superior to Golang packages. The latter 
> bundle build-dependencies very often while Perl packages rarely need to 
> undergo DFSG-repackaging. Almost all Perl packages (I can't recall even a 
> single exception) have formal version, probably because CPAN require modules 
> to be versioned. Packaging Perl software is usually easier and takes less 
> maintenance effort.
> 
> Golang software exhibit bad practices all over as far as I can tell...
> Unfortunately this have implications to our workflows because of frequent 
> version mocking and DFSG cleanup.

That's true. CPAN upstreams are the best! Still, go packaging is not as
bad as -say- java or the likes. Basically the biggest hurdle is
repackaging, and that does not need to affect our workflow much (see my
other mail).

> I've already experienced permissions problem twice and I wonder if we can ask 
> admins (whom specifically?) to fix this problem for all repositories...

I asked in #alioth, but got no answer so far. In the meantime I worked
around the issue by copying the repos with my UID, and fixing
permissions. The old repos are still there, with a '_perm_problems'
suffix, until they can be removed.

>> S: Always use debcommit -r, which will create the tag automatically,
>> when the package is about to be uploaded.
> 
> What do you suggest to do with tag if package is rejected?

If you reupload, just force push a new tag. Otherwise, remove the tag.

> I've made it a personal policy to tag only once package is accepted...

It is not a big issue, but it means it is more difficult to track
packages that need to be sponsored. There are a few non-DDs in the team,
and I would like to make it easier for them to work on packages, and for
DDs to sponsor them.

-- 
Martín Ferrari (Tincho)

___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

[pkg-go] golang-github-azure-azure-sdk-for-go_1.2~git20150611.0.97d9593-2_amd64.changes ACCEPTED into unstable, unstable

2015-09-15 Thread Debian FTP Masters 


Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Mon, 14 Sep 2015 19:19:55 -0700
Source: golang-github-azure-azure-sdk-for-go
Binary: golang-github-azure-azure-sdk-for-go-dev
Architecture: source all
Version: 1.2~git20150611.0.97d9593-2
Distribution: unstable
Urgency: medium
Maintainer: pkg-go 
Changed-By: Tianon Gravi 
Description:
 golang-github-azure-azure-sdk-for-go-dev - Microsoft Azure SDK for Go
Changes:
 golang-github-azure-azure-sdk-for-go (1.2~git20150611.0.97d9593-2) unstable; 
urgency=medium
 .
   * Note that core/* is BSD-3-clause and copyright of "The Go Authors"; thanks
 Thorsten!
Checksums-Sha1:
 0093f52ab791817a8c31c39d98e06ee713565121 2566 
golang-github-azure-azure-sdk-for-go_1.2~git20150611.0.97d9593-2.dsc
 9e64a2abd998f9ff75ef4634a756d7ff0f6ab20e 282107 
golang-github-azure-azure-sdk-for-go_1.2~git20150611.0.97d9593.orig.tar.bz2
 568a7088efb78ad3e7223a35369af947e2d31889 2564 
golang-github-azure-azure-sdk-for-go_1.2~git20150611.0.97d9593-2.debian.tar.xz
 2ae85d0934436e826b2b856df5f2566070461fea 274194 
golang-github-azure-azure-sdk-for-go-dev_1.2~git20150611.0.97d9593-2_all.deb
Checksums-Sha256:
 487bc2e391506afa0bb4183e3dd42252b587417d583dbb320e3b098c2b96060d 2566 
golang-github-azure-azure-sdk-for-go_1.2~git20150611.0.97d9593-2.dsc
 6dec2d432e4d9775727223b0e643e1e0ad965ffd6c7f35bcf0332457fdad643f 282107 
golang-github-azure-azure-sdk-for-go_1.2~git20150611.0.97d9593.orig.tar.bz2
 352cd74c76d488a3d83bb71ae2d0436ac9c4377fc46f5c4ae65789e8bc60bc72 2564 
golang-github-azure-azure-sdk-for-go_1.2~git20150611.0.97d9593-2.debian.tar.xz
 4b7198732c80c83274e368e09fd91b620ff5b3ecd38048e99a48a98959a44e6e 274194 
golang-github-azure-azure-sdk-for-go-dev_1.2~git20150611.0.97d9593-2_all.deb
Files:
 4fee183cbaf33879b3783d9cfff1af4a 2566 devel extra 
golang-github-azure-azure-sdk-for-go_1.2~git20150611.0.97d9593-2.dsc
 137f0c04c884ec9f23f98220c58b7897 282107 devel extra 
golang-github-azure-azure-sdk-for-go_1.2~git20150611.0.97d9593.orig.tar.bz2
 171907376a451e0cc441308b2940e34b 2564 devel extra 
golang-github-azure-azure-sdk-for-go_1.2~git20150611.0.97d9593-2.debian.tar.xz
 a74a3b4433177414911164cf99a1d753 274194 devel extra 
golang-github-azure-azure-sdk-for-go-dev_1.2~git20150611.0.97d9593-2_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJV94UbAAoJEANqnCW/NX3Uz4UP/2bpLWmqVc4slsfnJ4XCCO0F
p7+uzRv6ZBxk9xYsnoIrOb0byDDv5J3nm7F3xLlxSWiKCWYgjcC11zuTIkaUKqqe
57xe7gu+DGO2V08asNH+ort/slhZthVWoQvGhOQMwpBsN9i/OzFcdRN8H3wSFrXy
x1HWykd4R5elTFyKE7z0No2yw4eYP/AxsLU1TR2mrJ+94Yt9rJX0XHBl/W0dFnB9
UWdOjSmHWpXnpFR4mM4Vbm+9sSi0wWA7eIMX+LxdAKcq2sM1UGgWco+E73Uc0Zul
DobR36+a6RgN9X32jxK6aVw07McZYE/fW24t2BuRtXY/zgdnDEUXfcDN+ePpgR++
XNJ/ZKHS3fVGe1/+I7F2n/D1hzULutDLoHspJyP2NPHoongRbmByWWCiLyqajyEA
8YnfM+gdDzhfcvbhf0I655AnMp5fHPNLj+3P2dV8SoVOaUnRV7ytrBZTy5hqbSZD
rDawfV0Qp/HcK8daiasceCZvn9rabe9o46tNTbG967loqI7RfvmjGZCWXrGeVUSP
N4qdRSYGRg9botc4yiJ7+byiYZjEsOxuPzNV5I97YH2ZykMcayUcDxa1x5kOh544
fqcL5nHd7xaY+Q9mGpFAuhvGAEMETUj6PoYng09zAgoTdbWkMYah+WEtkT4rwN6L
PkXlUD45ckeUhXbqejAQ
=chEg
-END PGP SIGNATURE-


Thank you for your contribution to Debian.

___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

[pkg-go] golang-mreiferson-httpclient REMOVED from testing

2015-09-15 Thread Debian testing watch 
FYI: The status of the golang-mreiferson-httpclient source package
in Debian's testing distribution has changed.

  Previous version: 0.0~git20140425-2
  Current version:  (not in testing)
  Hint: Package not in unstable

The script that generates this mail tries to extract removal
reasons from comments in the britney hint files. Those comments
were not originally meant to be machine readable, so if the
reason for removing your package seems to be nonsense, it is
probably the reporting script that got confused. Please check the
actual hints file before you complain about meaningless removals.

-- 
This email is automatically generated once a day.  As the installation of
new packages into testing happens multiple times a day you will receive
later changes on the next day.
See https://release.debian.org/testing-watch/ for more information.

___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers