Bug#690707: marked as done (ITA: hiredis -- minimalistic C client library for Redis)
Your message dated Sun, 11 Nov 2012 19:02:42 + with message-id e1txcnq-0007ad...@franck.debian.org and subject line Bug#690707: fixed in hiredis 0.11.0-2 has caused the Debian Bug report #690707, regarding ITA: hiredis -- minimalistic C client library for Redis 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.) -- 690707: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=690707 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: wnpp Severity: normal I request an adopter for the hiredis package since I've lost interest in it and I'm not using it that much anymore. If needed I'm open to sponsoring uploads. It's IMO in a pretty good state. The git repository can be found at: http://anonscm.debian.org/gitweb/?p=collab-maint/hiredis.git;a=summary The package description is: Hiredis is a minimalistic C client library for the Redis database. It is minimalistic because it just adds minimal support for the protocol, but at the same time it uses an high level printf-alike API in order to make it much higher level than otherwise suggested by its minimal code base and the lack of explicit bindings for every Redis command. . Apart from supporting sending commands and receiving replies, it comes with a reply parser that is decoupled from the I/O layer. It is a stream parser designed for easy reusability, which can for instance be used in higher level language bindings for efficient reply parsing. . Hiredis only supports the binary-safe Redis protocol, so you can use it with any Redis version = 1.2.0. . The library comes with multiple APIs. There is the synchronous API, the asynchronous API and the reply parsing API. Cheers ---End Message--- ---BeginMessage--- Source: hiredis Source-Version: 0.11.0-2 We believe that the bug you reported is fixed in the latest version of hiredis, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 690...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Tom Lee deb...@tomlee.co (supplier of updated hiredis package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 10 Nov 2012 19:54:08 -0800 Source: hiredis Binary: libhiredis0.10 libhiredis-dev libhiredis-dbg Architecture: source amd64 Version: 0.11.0-2 Distribution: unstable Urgency: low Maintainer: Tom Lee deb...@tomlee.co Changed-By: Tom Lee deb...@tomlee.co Description: libhiredis-dbg - minimalistic C client library for Redis (debug) libhiredis-dev - minimalistic C client library for Redis (development files) libhiredis0.10 - minimalistic C client library for Redis Closes: 690707 Changes: hiredis (0.11.0-2) unstable; urgency=low . [ Alessandro Ghedini ] * Bump Standards-Version to 3.9.4 (no changes needed) . [ Tom Lee ] * New maintainer (Closes: #690707) * Bump version in the pkg-config file * Update debian/watch to point to new upstream URL * Update debian/control to point to new upstream URL * Update debian/copyright to point to new upstream URL * Add pkg-config/cmake patch * libhiredis-dev.install no longer needs +x Checksums-Sha1: 69b509f6531a293485faa54bdb4d58df1a277e5a 1981 hiredis_0.11.0-2.dsc fa91e81c0abc4896d435d155c07e448fb44760e8 6475 hiredis_0.11.0-2.debian.tar.gz 9fd2bd346f96e2a3455564a7553243f0f5c90ca7 24558 libhiredis0.10_0.11.0-2_amd64.deb ccb6491cb9aa293f45e8f387f11cbad9c973140f 38236 libhiredis-dev_0.11.0-2_amd64.deb cac180d6059d6d8b099bc78fba0176340aa8efbc 50586 libhiredis-dbg_0.11.0-2_amd64.deb Checksums-Sha256: e3c8cbaf7b94304f8060bc1090cb988a2a438943d13ed7b4bdd9db47772e3862 1981 hiredis_0.11.0-2.dsc 05c43acb6068937131c23e28e7d26d55cfea6e47c8e78adad9c7c69378bb6ba2 6475 hiredis_0.11.0-2.debian.tar.gz 184b5ccb3a35f019f50461bdec30c40299094e67878a4969ef280f648fe122ad 24558 libhiredis0.10_0.11.0-2_amd64.deb 5ad9d3dd0dad899dc3bc4cd41274ef40fb74bc42ee5cc3ccc28c7a3fdd0fce65 38236 libhiredis-dev_0.11.0-2_amd64.deb d4f79f2694bf0f1e941bc2b163fcf88cbad282602ff98bb6edfec5be9caf096d 50586 libhiredis-dbg_0.11.0-2_amd64.deb Files: 3cfe0db7ee7b59e70a0061243fc8561f 1981 libs optional hiredis_0.11.0-2.dsc 0d5c0ff739dc6ea6baff57bfb3607ea2 6475 libs optional
Bug#690707:
Alright, I've submitted a pull request upstream with the pkg-config
and CMake config files:
https://github.com/redis/hiredis/pull/129
Note that I've modified the location to which the cmake config file is
installed: /usr/share/cmake/Modules/FindHiredis.cmake by default (on
Debian, this will wind up being something like
/usr/share/cmake-2.8/Modules/FindHiredis.cmake). Our current scripts
install it to /usr/share/cmake/hiredis/hiredis-config.cmake.
I did it this way so it will automatically get picked up by CMake's
find_package macro. Makes the integration a little nicer. I intend to
port that over for our existing set of packaging stuff later this
weekend too.
Anyway, let me know if you need anything more from me in relation to
the adoption bug. :)
On Mon, Oct 22, 2012 at 10:45 PM, Tom Lee deb...@tomlee.co wrote:
You probably saw the email, but my collab-maint membership has been
approved. Thanks for all your help, and for the bite-size suggested
first bugs.
* probably the pkg-config one needs an update too (the version number).
* updating the d/watch file to point to the new upstream URL on GitHub.
Both done pushed to the got repo. Noticed a couple of other places
that referenced the old antirez/... URL (d/copyright, d/control) --
updated those too.
I also changed the Maintainer: field in the control file per the ITA process.
Noticed too late that these first couple of commits use my github@...
email address -- I've modified my git config so that future commits
will reflect the email address in the Maintainer field (i.e.
debian@...).
* forwarding upstream the pkg-config and cmake configurations. This includes
updating the upstream Makefile to install them.
I've got a busy couple of days ahead of me, but I'll get onto this
later this week. :)
Cheers,
Tom
On Mon, Oct 22, 2012 at 5:19 AM, Alessandro Ghedini al3x...@gmail.com wrote:
On 10/21, Tom Lee wrote:
You can join the collab-maint group following the procedure at [0].
Basically
you need an account on alioth.debian.org, send a request to join the
group and
then tell me so I can support your request.
Alioth account created (thomaslee-guest) collab-maint request sent.
Can I trouble you with the next step below?
Ask a DM or DD, with whom you are going to work, to send a *signed*
email to n...@debian.org saying Please accept the request of
FIRSTNAME LASTNAME USERNAME-guest to join collab-maint. We are going
to work together on project PROJECTNAME.
Yep, that was the plan :) I just sent the request to nm@d.o
While you wait for the approval there are a couple of tasks you may want to
look
into:
* forwarding upstream the pkg-config and cmake configurations. This includes
updating the upstream Makefile to install them.
* probably the pkg-config one needs an update too (the version number).
* updating the d/watch file to point to the new upstream URL on GitHub.
Cheers
--
perl -E '$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'
--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAKwFPQ9DjesAJBKZUErf4YoS=K_wMJF9=0_6713sq6nbbnx...@mail.gmail.com
Bug#690707:
On 10/21, Tom Lee wrote:
You can join the collab-maint group following the procedure at [0].
Basically
you need an account on alioth.debian.org, send a request to join the group
and
then tell me so I can support your request.
Alioth account created (thomaslee-guest) collab-maint request sent.
Can I trouble you with the next step below?
Ask a DM or DD, with whom you are going to work, to send a *signed*
email to n...@debian.org saying Please accept the request of
FIRSTNAME LASTNAME USERNAME-guest to join collab-maint. We are going
to work together on project PROJECTNAME.
Yep, that was the plan :) I just sent the request to nm@d.o
While you wait for the approval there are a couple of tasks you may want to look
into:
* forwarding upstream the pkg-config and cmake configurations. This includes
updating the upstream Makefile to install them.
* probably the pkg-config one needs an update too (the version number).
* updating the d/watch file to point to the new upstream URL on GitHub.
Cheers
--
perl -E '$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'
signature.asc
Description: Digital signature
Bug#690707:
You probably saw the email, but my collab-maint membership has been
approved. Thanks for all your help, and for the bite-size suggested
first bugs.
* probably the pkg-config one needs an update too (the version number).
* updating the d/watch file to point to the new upstream URL on GitHub.
Both done pushed to the got repo. Noticed a couple of other places
that referenced the old antirez/... URL (d/copyright, d/control) --
updated those too.
I also changed the Maintainer: field in the control file per the ITA process.
Noticed too late that these first couple of commits use my github@...
email address -- I've modified my git config so that future commits
will reflect the email address in the Maintainer field (i.e.
debian@...).
* forwarding upstream the pkg-config and cmake configurations. This includes
updating the upstream Makefile to install them.
I've got a busy couple of days ahead of me, but I'll get onto this
later this week. :)
Cheers,
Tom
On Mon, Oct 22, 2012 at 5:19 AM, Alessandro Ghedini al3x...@gmail.com wrote:
On 10/21, Tom Lee wrote:
You can join the collab-maint group following the procedure at [0].
Basically
you need an account on alioth.debian.org, send a request to join the group
and
then tell me so I can support your request.
Alioth account created (thomaslee-guest) collab-maint request sent.
Can I trouble you with the next step below?
Ask a DM or DD, with whom you are going to work, to send a *signed*
email to n...@debian.org saying Please accept the request of
FIRSTNAME LASTNAME USERNAME-guest to join collab-maint. We are going
to work together on project PROJECTNAME.
Yep, that was the plan :) I just sent the request to nm@d.o
While you wait for the approval there are a couple of tasks you may want to
look
into:
* forwarding upstream the pkg-config and cmake configurations. This includes
updating the upstream Makefile to install them.
* probably the pkg-config one needs an update too (the version number).
* updating the d/watch file to point to the new upstream URL on GitHub.
Cheers
--
perl -E '$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'
--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAKwFPQ880mE9JOvo6V_F1BVmY=WqkN_5u5Du2C0ggyw=2cg...@mail.gmail.com
Bug#690707:
On 10/20, Tom Lee wrote:
I'll attempt to update this bug to reflect its ITA status, though I'm not sure
if permissions on the bug tracker will prevent me from doing that. I'll nudge
this ticket again if it seems like I can't. Once that's done, I'll check out
the code from git amp; update the control file etc.
There are no restrictions in using the BTS, so you can go ahead without
problems.
I'm assuming I won't have access to push to that repository even after I take
over as maintainer, correct? Is it typical for somebody in my position to
continue maintaining the package using third-party infrastructure (e.g.
github)? If so, I'll update the Vcs-* fields, too.
You can join the collab-maint group following the procedure at [0]. Basically
you need an account on alioth.debian.org, send a request to join the group and
then tell me so I can support your request.
Last of all, you mentioned that you're willing to sponsor uploads. I guess I
can just build new packages amp; put them up somewhere, then ping you when
there's something that needs your attention?
The usual procedure would be to upload those packages somewhere like
mentors.debian.net, but I prefer to work directly from git, so, when you are
done you ping me and I'll review the modifications directly via git, and build
and upload the package if everything is ok.
As for the git part, you may want to have a look at the git-buildpackage package
which provides a few tools to help in the maintainance of packages using git.
There's a nice manual at [1].
Another tool you may want to look into is pbuilder [2] which can be used in
conjunction with git-buildpackage. I think they are both covered in the New
Maintainer's Guide somewhere.
Cheers
[0] https://lists.debian.org/debian-devel-announce/2012/01/msg6.html
[1] http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.html
[2] http://www.netfort.gr.jp/~dancer/software/pbuilder-doc/pbuilder-doc.html
--
perl -E '$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'
signature.asc
Description: Digital signature
Bug#690707:
You can join the collab-maint group following the procedure at [0]. Basically
you need an account on alioth.debian.org, send a request to join the group and
then tell me so I can support your request.
Alioth account created (thomaslee-guest) collab-maint request sent.
Can I trouble you with the next step below?
Ask a DM or DD, with whom you are going to work, to send a *signed*
email to n...@debian.org saying Please accept the request of
FIRSTNAME LASTNAME USERNAME-guest to join collab-maint. We are going
to work together on project PROJECTNAME.
The usual procedure would be to upload those packages somewhere like
mentors.debian.net, but I prefer to work directly from git, so, when you are
done you ping me and I'll review the modifications directly via git, and build
and upload the package if everything is ok.
That sounds great. I'm somewhat familiar with git-buildpackage, but
I'll take a look at pbuilder too.
Thanks again!
Cheers,
Tom
On Sun, Oct 21, 2012 at 8:29 AM, Alessandro Ghedini al3x...@gmail.com wrote:
On 10/20, Tom Lee wrote:
I'll attempt to update this bug to reflect its ITA status, though I'm not
sure
if permissions on the bug tracker will prevent me from doing that. I'll nudge
this ticket again if it seems like I can't. Once that's done, I'll check out
the code from git amp; update the control file etc.
There are no restrictions in using the BTS, so you can go ahead without
problems.
I'm assuming I won't have access to push to that repository even after I take
over as maintainer, correct? Is it typical for somebody in my position to
continue maintaining the package using third-party infrastructure (e.g.
github)? If so, I'll update the Vcs-* fields, too.
You can join the collab-maint group following the procedure at [0]. Basically
you need an account on alioth.debian.org, send a request to join the group and
then tell me so I can support your request.
Last of all, you mentioned that you're willing to sponsor uploads. I guess I
can just build new packages amp; put them up somewhere, then ping you when
there's something that needs your attention?
The usual procedure would be to upload those packages somewhere like
mentors.debian.net, but I prefer to work directly from git, so, when you are
done you ping me and I'll review the modifications directly via git, and build
and upload the package if everything is ok.
As for the git part, you may want to have a look at the git-buildpackage
package
which provides a few tools to help in the maintainance of packages using git.
There's a nice manual at [1].
Another tool you may want to look into is pbuilder [2] which can be used in
conjunction with git-buildpackage. I think they are both covered in the New
Maintainer's Guide somewhere.
Cheers
[0] https://lists.debian.org/debian-devel-announce/2012/01/msg6.html
[1] http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.html
[2] http://www.netfort.gr.jp/~dancer/software/pbuilder-doc/pbuilder-doc.html
--
perl -E '$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'
--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/cakwfpq-f6zr-ffalajzykaiaa0nuk9g_itkdy4n2mpcw9ow...@mail.gmail.com
Bug#690707:
On 10/17, Tom Lee wrote:
Hi Alessandro,
Hi,
I'm a long time Debian user who's eager to contribute. I have a fair bit of
experience with Debian packaging, but this would be my first
quot;officialquot; package.
No doubt I'd have a bit of a learning curve ahead of me with regard to process
amp; policy, but if you think that hiredis is appropriate for somebody like
me
to take on, I'd be happy to adopt it.
Well, the hard part (i.e. the initial packaging) has been already done and
it's pretty standard except for a couple of patches to the build system and
another couple of odd things.
Though some people believe that library packages are not the best way to start
packaging for Debian because they are usually a little bit harder, but if you
want to try and are willing to learn you are very welcome.
You may want to start by the first 3 manuals at [0] which document pretty much
all you need to know (particularly the New Maintainers' Guide).
Cheers
[0] http://www.debian.org/doc/devel-manuals
--
perl -E '$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'
signature.asc
Description: Digital signature
Bug#690707:
Thanks Alessandro. I think I'm comfortable with the idea of starting out
with a library am willing to deal with any extra learning curve that
comes with that. Thanks too for the pointers RE: documentation -- looks
like I've got some reading to do. :)
I'll attempt to update this bug to reflect its ITA status, though I'm not
sure if permissions on the bug tracker will prevent me from doing that.
I'll nudge this ticket again if it seems like I can't. Once that's done,
I'll check out the code from git update the control file etc.
I'm assuming I won't have access to push to that repository even after I
take over as maintainer, correct? Is it typical for somebody in my position
to continue maintaining the package using third-party infrastructure (e.g.
github)? If so, I'll update the Vcs-* fields, too.
Last of all, you mentioned that you're willing to sponsor uploads. I guess
I can just build new packages put them up somewhere, then ping you when
there's something that needs your attention?
Appreciate your patience apologies if I'm asking questions here that are
answered by the documentation you provided!
Cheers,
Tom
On Sat, Oct 20, 2012 at 6:55 AM, Alessandro Ghedini al3x...@gmail.comwrote:
On 10/17, Tom Lee wrote:
Hi Alessandro,
Hi,
I'm a long time Debian user who's eager to contribute. I have a fair bit
of
experience with Debian packaging, but this would be my first
quot;officialquot; package.
No doubt I'd have a bit of a learning curve ahead of me with regard to
process
amp; policy, but if you think that hiredis is appropriate for somebody
like me
to take on, I'd be happy to adopt it.
Well, the hard part (i.e. the initial packaging) has been already done
and
it's pretty standard except for a couple of patches to the build system and
another couple of odd things.
Though some people believe that library packages are not the best way to
start
packaging for Debian because they are usually a little bit harder, but if
you
want to try and are willing to learn you are very welcome.
You may want to start by the first 3 manuals at [0] which document pretty
much
all you need to know (particularly the New Maintainers' Guide).
Cheers
[0] http://www.debian.org/doc/devel-manuals
--
perl -E '$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'
Bug#690707:
Hi Alessandro, I'm a long time Debian user who's eager to contribute. I have a fair bit of experience with Debian packaging, but this would be my first official package. No doubt I'd have a bit of a learning curve ahead of me with regard to process policy, but if you think that hiredis is appropriate for somebody like me to take on, I'd be happy to adopt it. Cheers, Tom
Bug#690707: RFA: hiredis -- minimalistic C client library for Redis
Package: wnpp Severity: normal I request an adopter for the hiredis package since I've lost interest in it and I'm not using it that much anymore. If needed I'm open to sponsoring uploads. It's IMO in a pretty good state. The git repository can be found at: http://anonscm.debian.org/gitweb/?p=collab-maint/hiredis.git;a=summary The package description is: Hiredis is a minimalistic C client library for the Redis database. It is minimalistic because it just adds minimal support for the protocol, but at the same time it uses an high level printf-alike API in order to make it much higher level than otherwise suggested by its minimal code base and the lack of explicit bindings for every Redis command. . Apart from supporting sending commands and receiving replies, it comes with a reply parser that is decoupled from the I/O layer. It is a stream parser designed for easy reusability, which can for instance be used in higher level language bindings for efficient reply parsing. . Hiredis only supports the binary-safe Redis protocol, so you can use it with any Redis version = 1.2.0. . The library comes with multiple APIs. There is the synchronous API, the asynchronous API and the reply parsing API. Cheers -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121016180818.29062.486.reportbug@dexter
