Debian Bug report logs - #705262
[ceph] New upstream release available

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Liang Guo <bluestonechina@gmail.com>

To: submit@bugs.debian.org

Subject: [ceph] New upstream release available

Date: Fri, 12 Apr 2013 15:46:16 +0800

[Message part 1 (text/plain, inline)]

Package: ceph
Severity: wishlist

Hi, Ceph 0.56.4 is out, please package it for Debian

Thanks, 


--- System information. ---
Architecture: amd64
Kernel:       Linux 3.9.0-rc1

Debian Release: 7.0
  500 unstable        localhost 
    1 experimental    localhost 

--- Package information. ---
Depends                             (Version) | Installed
=============================================-+-=====================
libc6                                (>= 2.6) | 
libcrypto++9                                  | 
libedit2                 (>= 2.11-20080614-1) | 
libgcc1                          (>= 1:4.1.1) | 
libglib2.0-0                      (>= 2.12.0) | 
libglibmm-2.4-1c2a                (>= 2.28.0) | 
libgoogle-perftools0                          | 
libgtkmm-2.4-1c2a               (>= 1:2.20.0) | 
libsigc++-2.0-0c2a                 (>= 2.0.2) | 
libstdc++6                           (>= 4.5) | 
hdparm                                        | 
binutils                                      | 


Recommends             (Version) | Installed
================================-+-===========
ceph-client-tools                | 
ceph-fuse                        | 
libceph1                         | 
librados2                        | 0.48-1
librbd1                          | 0.48-1
libcrush1                        | 
btrfs-tools                      | 0.19+20130131-3+really20121004-1


Package's Suggests field is empty.




-- 
Thanks and Regards,
--
Liang Guo
http://bluestone.cublog.cn

[signature.asc (application/pgp-signature, inline)]

Message #10 received at 705262@bugs.debian.org (full text, mbox, reply):

From: Vedran Miletić <rivanvx@gmail.com>

To: 705262@bugs.debian.org

Subject: Ceph Downloads

Date: Wed, 12 Jun 2013 10:04:23 +0200

Packages of Ceph 0.61 for wheezy are provided at
http://ceph.com/resources/downloads/

It would be nice to have them back in Debian archive as well.

Regards,
Vedran Miletić

Message #15 received at 705262@bugs.debian.org (full text, mbox, reply):

From: Daniel Swarbrick <daniel.swarbrick@profitbricks.com>

To: 705262@bugs.debian.org

Subject: RBD support in qemu

Date: Wed, 19 Jun 2013 11:29:40 +0200

I have a few test VMs running on Ubuntu 13.04, which connect to a
Debian-powered Ceph cluster (using v0.61.3 ceph packages from ceph.com
repos). This is working without any problems.

The ceph / librbd packages in Debian are *ancient*, even by Debian
standards. Can we please sync with what the Inktank guys build, and get
things moving again? It would be great to have RBD support added back to
the Debian qemu packages.

Message #20 received at 705262@bugs.debian.org (full text, mbox, reply):

From: Bastian Blank <waldi@debian.org>

To: 705262@bugs.debian.org

Subject: unsupportable

Date: Sat, 7 Sep 2013 21:47:31 +0200

Control: severity -1 serious

The version 0.48 was removed from wheezy because it is unsupportable.
In the meantime this is _twenty_ versions behind the last release.  This
means it is even less supportable.

Setting the bug to serious, as unsupportable is RC by the current
release policy.

If you don't intend to actually maintain ceph, please orphan the
package.  Otherwise I may do a NMU with the latest version 0.68 in the
next two weeks.

Bastian

-- 
It would seem that evil retreats when forcibly confronted.
		-- Yarnek of Excalbia, "The Savage Curtain", stardate 5906.5

Message #29 received at 705262@bugs.debian.org (full text, mbox, reply):

From: László Böszörményi (GCS) <gcs@debian.org>

To: Bastian Blank <waldi@debian.org>, 705262@bugs.debian.org

Subject: Re: Bug#705262: unsupportable

Date: Sat, 7 Sep 2013 23:13:09 +0200

Hi Bastian,

On Sat, Sep 7, 2013 at 9:47 PM, Bastian Blank <waldi@debian.org> wrote:
> The version 0.48 was removed from wheezy because it is unsupportable.
> In the meantime this is _twenty_ versions behind the last release.  This
> means it is even less supportable.
 Sure, it's very old. Even if that was a long term support one.
Btw, Ceph was not part of Wheezy. Do you mean Jessie?

> If you don't intend to actually maintain ceph, please orphan the
> package.  Otherwise I may do a NMU with the latest version 0.68 in the
> next two weeks.
 Ceph is maintained in the background. There's a more fresh version
online[1], a maintaince team formed[2] with the newest stable version
in Git[3]. Please contact us before doing an actual NMU.

Laszlo/GCS
[1] http://www.barcikacomp.hu/gcs/ceph_0.61.7-1.dsc
[2] https://alioth.debian.org/projects/pkg-ceph/
[3] http://anonscm.debian.org/gitweb/?p=pkg-ceph/pkg-ceph.git;a=summary

Message #34 received at 705262@bugs.debian.org (full text, mbox, reply):

From: Hilko Bengen <bengen@debian.org>

To: László Böszörményi (GCS) <gcs@debian.org>

Cc: 705262@bugs.debian.org, Bastian Blank <waldi@debian.org>

Subject: Re: Bug#705262: unsupportable

Date: Sun, 08 Sep 2013 00:37:11 +0200

* László Böszörményi (GCS):

> On Sat, Sep 7, 2013 at 9:47 PM, Bastian Blank <waldi@debian.org> wrote:
>> The version 0.48 was removed from wheezy because it is unsupportable.
>> In the meantime this is _twenty_ versions behind the last release.  This
>> means it is even less supportable.
> Sure, it's very old. Even if that was a long term support one.
> Btw, Ceph was not part of Wheezy. Do you mean Jessie?

A look at <http://packages.qa.debian.org/c/ceph.html> shows that it was
part of wheezy but was removed after the freeze:

[2012-09-30] ceph REMOVED from testing (Britney)

>> If you don't intend to actually maintain ceph, please orphan the
>> package.  Otherwise I may do a NMU with the latest version 0.68 in the
>> next two weeks.
>  Ceph is maintained in the background. There's a more fresh version
> online[1], a maintaince team formed[2] with the newest stable version
> in Git[3]. Please contact us before doing an actual NMU.

Packaging efforts that happen entirely outside the unstable/testing
distribution like this are pretty much useless for Debian. After all,
there are reverse dependencies that would benefit from being able to use
some of the provided libraries: The QEMU maintainer, for instance,
removed ceph support a year ago because that ceph package was not usable
then:

qemu (1.1.2+dfsg-1) unstable; urgency=low
  [...]
  * do not build-depend on ceph (librbd-dev librados-dev), since ceph is
    having longstanding issues in wheezy.
  [...]
 -- Michael Tokarev <mjt@tls.msk.ru>  Sun, 09 Sep 2012 18:52:57 +0400

If you consider your 8-week-old package (0.61.7-1) to be even remotely
fit for unstable, please upload.

Cheers,
-Hilko

Message #39 received at 705262@bugs.debian.org (full text, mbox, reply):

From: Bastian Blank <waldi@debian.org>

To: László Böszörményi (GCS) <gcs@debian.org>

Cc: 705262@bugs.debian.org, Hilko Bengen <bengen@debian.org>

Subject: Re: Bug#705262: unsupportable

Date: Sun, 8 Sep 2013 09:56:03 +0200

On Sat, Sep 07, 2013 at 11:13:09PM +0200, László Böszörményi (GCS) wrote:
> On Sat, Sep 7, 2013 at 9:47 PM, Bastian Blank <waldi@debian.org> wrote:
> > If you don't intend to actually maintain ceph, please orphan the
> > package.  Otherwise I may do a NMU with the latest version 0.68 in the
> > next two weeks.
>  Ceph is maintained in the background. There's a more fresh version
> online[1], a maintaince team formed[2] with the newest stable version
> in Git[3]. Please contact us before doing an actual NMU.

Who is "us"?  Why did "us" not respond to this bug for four months?  Why
is there an open NMU bug against Ceph?  Why is the team not listed as
maintainer?  Sorry, but random teams do not help if the effort does not
end up in Debian.

Anyway, I need something by september, 21th.  So please feel contacted.

Bastian

-- 
Earth -- mother of the most beautiful women in the universe.
		-- Apollo, "Who Mourns for Adonais?" stardate 3468.1

Message #44 received at 705262@bugs.debian.org (full text, mbox, reply):

From: Bastian Blank <waldi@debian.org>

To: László Böszörményi (GCS) <gcs@debian.org>

Cc: 705262@bugs.debian.org

Subject: Re: Bug#705262: unsupportable

Date: Sun, 8 Sep 2013 18:27:30 +0200

On Sat, Sep 07, 2013 at 11:13:09PM +0200, László Böszörményi (GCS) wrote:
> On Sat, Sep 7, 2013 at 9:47 PM, Bastian Blank <waldi@debian.org> wrote:
> > If you don't intend to actually maintain ceph, please orphan the
> > package.  Otherwise I may do a NMU with the latest version 0.68 in the
> > next two weeks.
>  Ceph is maintained in the background. There's a more fresh version
> online[1], a maintaince team formed[2] with the newest stable version
> in Git[3]. Please contact us before doing an actual NMU.

When was the last time this was actually built?  debian/control contains
a syntax error that breaks building at all.

Bastian

-- 
Insults are effective only where emotion is present.
		-- Spock, "Who Mourns for Adonais?"  stardate 3468.1

Message #49 received at 705262@bugs.debian.org (full text, mbox, reply):

From: Bastian Blank <waldi@debian.org>

To: László Böszörményi (GCS) <gcs@debian.org>

Cc: 705262@bugs.debian.org, Hilko Bengen <bengen@debian.org>

Subject: Re: Bug#705262: unsupportable

Date: Sun, 8 Sep 2013 21:58:39 +0200

On Sun, Sep 08, 2013 at 06:27:29PM +0200, Bastian Blank wrote:
> On Sat, Sep 07, 2013 at 11:13:09PM +0200, László Böszörményi (GCS) wrote:
> > On Sat, Sep 7, 2013 at 9:47 PM, Bastian Blank <waldi@debian.org> wrote:
> > > If you don't intend to actually maintain ceph, please orphan the
> > > package.  Otherwise I may do a NMU with the latest version 0.68 in the
> > > next two weeks.
> >  Ceph is maintained in the background. There's a more fresh version
> > online[1], a maintaince team formed[2] with the newest stable version
> > in Git[3]. Please contact us before doing an actual NMU.
> When was the last time this was actually built?  debian/control contains
> a syntax error that breaks building at all.

Work in progress, can be rebased:
git://anonscm.debian.org/users/waldi/ceph.git

Not sure how this survived QA in Ubuntu.

Bastian

-- 
Vulcans believe peace should not depend on force.
		-- Amanda, "Journey to Babel", stardate 3842.3

Message #54 received at 705262@bugs.debian.org (full text, mbox, reply):

From: Dererk <dererk@debian.org>

To: 705262@bugs.debian.org, "László Böszörményi (GCS)" <gcs@debian.org>

Cc: 714881@bugs.debian.org

Subject: Please clarify NMU/Upload intentions

Date: Wed, 11 Sep 2013 21:00:34 -0300

[Message part 1 (text/plain, inline)]

Hi László && Pkg-Ceph!

Since I think the essence of this Bug Report is clear for everyone and
no objections has been made from any of the parts involved about the
version and the status of the Ceph software present at the archive, I
would like you to clarify what your intentions are surrounding the NMU
request (#714881) or any possible duploads in the closest future.

Furthermore, If It's possible for you/pkg-ceph team to provide a time
reference of what and when your plans would be taking place, it will be
extremely appreciated.



Thanks in advance and have a great day!


Cheers,

Dererk

-- 
BOFH excuse #229:
wrong polarity of neutron flow

[signature.asc (application/pgp-signature, attachment)]

Message #59 received at 705262@bugs.debian.org (full text, mbox, reply):

From: László Böszörményi (GCS) <gcs@debian.org>

To: Dererk <dererk@debian.org>

Cc: 705262@bugs.debian.org

Subject: Re: Please clarify NMU/Upload intentions

Date: Thu, 12 Sep 2013 03:13:57 +0200

Hi Derek,

On Thu, Sep 12, 2013 at 2:00 AM, Dererk <dererk@debian.org> wrote:
> Since I think the essence of this Bug Report is clear for everyone and
> no objections has been made from any of the parts involved about the
> version and the status of the Ceph software present at the archive, I
> would like you to clarify what your intentions are surrounding the NMU
> request (#714881) or any possible duploads in the closest future.
 #714881 is already fixed with 0.48-2 , closed the bugreport.
Bastian won't NMU Ceph, but started cooperating. He started working on
the current pkg-ceph Git tree[1], which is version 0.67.2 . It's the
latest stable version. Upstream released 0.68 meanwhile as a
development version. Anyway, the current Git package version may not
be 100% correct in QA view, but builds and ready for upload.

> Furthermore, If It's possible for you/pkg-ceph team to provide a time
> reference of what and when your plans would be taking place, it will be
> extremely appreciated.
 The plan is the following.
Bastian made correct improvements to the Git tree. I only included
only two of his commits as both are same with my previous but
uncommitted changes. I may not agree that he joined the -dbg packages,
will read policy about it. As far as I can remember, every library
should have its -dbg counterpart and not one joined package. His other
commits look fine, will merge them. Yesterday I didn't have time, but
today will look into it again.
Will upload 0.67.2-1 on Friday evening. I'm not sure we should upload
development releases. At least not for Sid, but for experimental.

Kind regards,
Laszlo/GCS
[1] http://anonscm.debian.org/gitweb/?p=pkg-ceph/pkg-ceph.git

Message #64 received at 705262@bugs.debian.org (full text, mbox, reply):

From: Daniel Swarbrick <daniel.swarbrick@profitbricks.com>

To: "László Böszörményi (GCS)" <gcs@debian.org>, 705262@bugs.debian.org

Cc: Dererk <dererk@debian.org>

Subject: Re: Bug#705262: Please clarify NMU/Upload intentions

Date: Fri, 13 Sep 2013 14:58:30 +0200

On 09/12/2013 03:13 AM, László Böszörményi (GCS) wrote:
>  #714881 is already fixed with 0.48-2 , closed the bugreport.
> Bastian won't NMU Ceph, but started cooperating. He started working on
> the current pkg-ceph Git tree[1], which is version 0.67.2 . It's the
> latest stable version. Upstream released 0.68 meanwhile as a
> development version. Anyway, the current Git package version may not
> be 100% correct in QA view, but builds and ready for upload.
Actually, 0.67.3 is the latest stable release. It fixes some important
performance regressions.

http://ceph.com/releases/v0-67-3-dumpling-released/

Message #69 received at 705262@bugs.debian.org (full text, mbox, reply):

From: László Böszörményi (GCS) <gcs@debian.org>

To: Daniel Swarbrick <daniel.swarbrick@profitbricks.com>

Cc: 705262@bugs.debian.org, Dererk <dererk@debian.org>

Subject: Re: Bug#705262: Please clarify NMU/Upload intentions

Date: Fri, 13 Sep 2013 22:18:54 +0200

On Fri, Sep 13, 2013 at 2:58 PM, Daniel Swarbrick
<daniel.swarbrick@profitbricks.com> wrote:
> Actually, 0.67.3 is the latest stable release. It fixes some important
> performance regressions.
> http://ceph.com/releases/v0-67-3-dumpling-released/
 Indeed. Merged with almost all changes from Bastian to
http://anonscm.debian.org/gitweb/?p=pkg-ceph/pkg-ceph.git

Laszlo/GCS

Message #74 received at 705262@bugs.debian.org (full text, mbox, reply):

From: Bastian Blank <waldi@debian.org>

To: 705262@bugs.debian.org

Subject: ceph

Date: Sun, 15 Sep 2013 12:00:38 +0200

Thank you for not Cc-ing me.

However there are several problems left:
- ceph-common depends on python-flask and python-ceph.
- ceph-common is not _arch-all_, why does it exist?
- Why ceph-mds?
- ceph depends on fdisk, parted and whole lot other crap it does not
  need.
- A lot of Replaces.
- python-ceph needs stricter dependencies.
- Split between -java and -jni for no apparent reason, it only add a
  package to the global index.

About the debug packages: I can also ask ftp-team to kill it, because it
ten packages that can't be used independently fills the package index.

Bastian

-- 
Oblivion together does not frighten me, beloved.
		-- Thalassa (in Anne Mulhall's body), "Return to Tomorrow",
		   stardate 4770.3.

Message #79 received at 705262@bugs.debian.org (full text, mbox, reply):

From: László Böszörményi (GCS) <gcs@debian.org>

To: Bastian Blank <waldi@debian.org>, 705262@bugs.debian.org

Cc: James Page <james.page@ubuntu.com>

Subject: Re: Bug#705262: ceph

Date: Sun, 15 Sep 2013 12:30:22 +0200

On Sun, Sep 15, 2013 at 12:00 PM, Bastian Blank <waldi@debian.org> wrote:
> Thank you for not Cc-ing me.
 Can be my fault, I'd the thought as a bugreport owner, you'll get all mails.

> However there are several problems left:
> - ceph-common depends on python-flask and python-ceph.
 Why this is a problem? What I see is that python-flask should be
moved to python-ceph .

> - ceph-common is not _arch-all_, why does it exist?
 Tools that used by other packages that can be installed
independently. Should it be named like ceph-base or ceph-tools?

> - Why ceph-mds?
 Ceph has three independent blocks. Metadata servers (-mds) are one of
them. Please see the overview[1].

> - ceph depends on fdisk, parted and whole lot other crap it does not
>   need.
 Agree on this. Don't know how it made there.

> - A lot of Replaces.
 There were package renames, users may have packages from upstream or
Ubuntu. That's make it complex.

> - python-ceph needs stricter dependencies.
 Will check.

> - Split between -java and -jni for no apparent reason, it only add a
>   package to the global index.
 James?

> About the debug packages: I can also ask ftp-team to kill it, because it
> ten packages that can't be used independently fills the package index.
 Still not sure they should be integrated.

In a rush now, may write more later.
Laszlo/GCS
[1] http://ceph.com/docs/next/cephfs/

Message #84 received at 705262@bugs.debian.org (full text, mbox, reply):

From: Daniel Swarbrick <daniel.swarbrick@profitbricks.com>

To: Bastian Blank <waldi@debian.org>, 705262@bugs.debian.org

Subject: Re: Bug#705262: ceph

Date: Sun, 15 Sep 2013 12:50:04 +0200

[Message part 1 (text/plain, inline)]

On Sun, Sep 15, 2013 at 12:00 PM, Bastian Blank <waldi@debian.org> wrote:

> - ceph depends on fdisk, parted and whole lot other crap it does not
>   need.
>

This is most likely a dependency of the ceph-disk-prepare or ceph-deploy
scripts, which handle preparing partitions and filesystems on new disks
intended for Ceph OSDs.

[Message part 2 (text/html, inline)]

Message #89 received at 705262@bugs.debian.org (full text, mbox, reply):

From: Bastian Blank <waldi@debian.org>

To: László Böszörményi (GCS) <gcs@debian.org>

Cc: 705262@bugs.debian.org, James Page <james.page@ubuntu.com>

Subject: Re: Bug#705262: ceph

Date: Sun, 15 Sep 2013 13:03:40 +0200

On Sun, Sep 15, 2013 at 12:30:22PM +0200, László Böszörményi (GCS) wrote:
> On Sun, Sep 15, 2013 at 12:00 PM, Bastian Blank <waldi@debian.org> wrote:
> > However there are several problems left:
> > - ceph-common depends on python-flask and python-ceph.
>  Why this is a problem? What I see is that python-flask should be
> moved to python-ceph .

There is a python script ceph-rest-api.  Where is this used?  Why does
it warrant a dependency on 20 other packages?

> > - ceph-common is not _arch-all_, why does it exist?
>  Tools that used by other packages that can be installed
> independently. Should it be named like ceph-base or ceph-tools?

Not sure right now.  It looks like a random dash of tools, stashed
together without much thinking.
- ceph, rados, rbd: Tools to manage different parts of ceph, remotely.
- ceph-authtool: Works on keyring files, so needs to run locally on the
  monitor.
- ceph-rest-api: Where does this belong to?
- ceph-dencoder, ceph-syn: This are test or debugging tools.

I would
- move ceph-authotool and maybe ceph-rest-api into ceph,
- move cephfs and mount.ceph into ceph-common
- move ceph-dencoder and ceph-syn into ceph-test,
- move stuff from ceph-resource-agents into ceph and
- drop ceph-fs-common and ceph-resource-agents.

> > - Why ceph-mds?
>  Ceph has three independent blocks. Metadata servers (-mds) are one of
> them. Please see the overview[1].

Yeah.  But why does it need a different package?  What does this extra
package bring for the user?

> > - ceph depends on fdisk, parted and whole lot other crap it does not
> >   need.
>  Agree on this. Don't know how it made there.

Because ceph-disk (another incompletely documented indirection) uses it.
The important parts (ceph-mon, ceph-osd) works fine without it.

> > - A lot of Replaces.
>  There were package renames, users may have packages from upstream or
> Ubuntu. That's make it complex.

Not a concern for Debian.  It was never in a stable release.

> > - python-ceph needs stricter dependencies.
>  Will check.

At least the dependencies for librados2 and librdb1 needs to be
stricter.  The dependency on libcephfs1 is missing.

- Symbols files are missing.

Bastian

-- 
There's a way out of any cage.
		-- Captain Christopher Pike, "The Menagerie" ("The Cage"),
		   stardate unknown.

Message #94 received at 705262@bugs.debian.org (full text, mbox, reply):

From: Daniel Swarbrick <daniel.swarbrick@profitbricks.com>

To: Bastian Blank <waldi@debian.org>, 705262@bugs.debian.org

Subject: Re: Bug#705262: ceph

Date: Sun, 15 Sep 2013 16:18:05 +0200

[Message part 1 (text/plain, inline)]

On Sun, Sep 15, 2013 at 1:03 PM, Bastian Blank <waldi@debian.org> wrote:

> There is a python script ceph-rest-api.  Where is this used?  Why does
> it warrant a dependency on 20 other packages?
>

This is the as yet sparsely documented admin REST WSGI app (which can also
run as a standalone server), which was a new feature in the 0.67 "dumpling"
release. This should not be confused with the RADOSGW REST stuff.

I have not looked at the source of the script yet, but have had a play with
it. I suspect it depends on things like Jinja2 because it renders HTML
tables for self-documenting purposes if you simply open the API with a web
browser. This seems like a bit of an overkill for using a template engine
like Jinja2, but oh well. If you make an API request using a "non-browser"
client (e.g. wget or XmlHttpRequest), it returns JSON for the most part.

I suspect this could be made a separate package, since it is not essential
to running an OSD, MDS or mon.

> > - Why ceph-mds?
>
>  Ceph has three independent blocks. Metadata servers (-mds) are one of
> > them. Please see the overview[1].
>
> Yeah.  But why does it need a different package?  What does this extra
> package bring for the user?
>
>
Ceph MDS are not needed on every OSD, and are in fact only needed if using
CephFS. If you're only using RBD pools and RADOSGW, then a MDS is
completely unnecessary. Similarly, a mon is not needed on every Ceph node
either.

A typical setup consists of two or more OSDs (likely many more), three or
more (preferably an odd number) monitors - either on selected OSD nodes, or
separate servers, and one or more MDS nodes - but only if using CephFS.

I only know of one or two people who've actually tried CephFS, and
according to the developers, it should not be considered quite
production-ready yet.

Bear in mind however that OSDs, mons, and MDSs all use the same
/etc/ceph/ceph.conf config file, making it potentially hard to split them
into separate packages.

[Message part 2 (text/html, inline)]

Message #99 received at 705262@bugs.debian.org (full text, mbox, reply):

From: Bastian Blank <waldi@debian.org>

To: Daniel Swarbrick <daniel.swarbrick@profitbricks.com>

Cc: 705262@bugs.debian.org

Subject: Re: Bug#705262: ceph

Date: Sun, 15 Sep 2013 16:43:28 +0200

On Sun, Sep 15, 2013 at 04:18:05PM +0200, Daniel Swarbrick wrote:
> On Sun, Sep 15, 2013 at 1:03 PM, Bastian Blank <waldi@debian.org> wrote:
> > There is a python script ceph-rest-api.  Where is this used?  Why does
> > it warrant a dependency on 20 other packages?
> This is the as yet sparsely documented admin REST WSGI app (which can also
> run as a standalone server), which was a new feature in the 0.67 "dumpling"
> release. This should not be confused with the RADOSGW REST stuff.

Thats why I asked it this sparsely documented and not enabled by default
piece of software warrants the hard inclusion of a lot of dependencies.

> > Yeah.  But why does it need a different package?  What does this extra
> > package bring for the user?
> Ceph MDS are not needed on every OSD, and are in fact only needed if using
> CephFS. If you're only using RBD pools and RADOSGW, then a MDS is
> completely unnecessary. Similarly, a mon is not needed on every Ceph node
> either.

Neither mon, osd nor mds should run on the same system I would assume,
at least in large installations.  So my question is just _why_ mds needs
this extra package, while mon/osd can live in the same.

Bastian

-- 
Vulcans never bluff.
		-- Spock, "The Doomsday Machine", stardate 4202.1

Message #104 received at 705262@bugs.debian.org (full text, mbox, reply):

From: James Page <james.page@ubuntu.com>

To: Bastian Blank <waldi@debian.org>

Cc: "László Böszörményi (GCS)" <gcs@debian.org>, 705262@bugs.debian.org

Subject: Re: Bug#705262: ceph

Date: Sun, 15 Sep 2013 18:23:23 +0100

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Bastian & Lazlo

On 15/09/13 12:03, Bastian Blank wrote:
> On Sun, Sep 15, 2013 at 12:30:22PM +0200, László Böszörményi (GCS)
> wrote:
>> On Sun, Sep 15, 2013 at 12:00 PM, Bastian Blank
>> <waldi@debian.org> wrote:
>>> However there are several problems left: - ceph-common depends
>>> on python-flask and python-ceph.
>> Why this is a problem? What I see is that python-flask should be 
>> moved to python-ceph .
> There is a python script ceph-rest-api.  Where is this used?  Why
> does it warrant a dependency on 20 other packages?

Dumpling (0.67.x) is the first release with basic support for a REST
api for administering a ceph cluster - this binary supports this
feature - but more of a demo of how to use than anything really usable
(dev mode only).  However I do agree that it looks like it should be
in ceph.

>>> - ceph-common is not _arch-all_, why does it exist?
>> Tools that used by other packages that can be installed 
>> independently. Should it be named like ceph-base or ceph-tools?
> 
> Not sure right now.  It looks like a random dash of tools, stashed 
> together without much thinking. - ceph, rados, rbd: Tools to manage
> different parts of ceph, remotely. - ceph-authtool: Works on
> keyring files, so needs to run locally on the monitor. -
> ceph-rest-api: Where does this belong to? - ceph-dencoder,
> ceph-syn: This are test or debugging tools.
> 
> I would - move ceph-authotool and maybe ceph-rest-api into ceph, -
> move cephfs and mount.ceph into ceph-common - move ceph-dencoder
> and ceph-syn into ceph-test, - move stuff from ceph-resource-agents
> into ceph and - drop ceph-fs-common and ceph-resource-agents.
> 
>>> - Why ceph-mds?
>> Ceph has three independent blocks. Metadata servers (-mds) are
>> one of them. Please see the overview[1].
> 
> Yeah.  But why does it need a different package?  What does this
> extra package bring for the user?

For context, the ceph-mds function was split out in the packaging as
MDS is not as well tested/production grade as the RADOS and RBD
features;  In Ubuntu we use this to signal which parts receive full
support from the Ubuntu Server and Security teams. I appreciate that
this is not required for Debian but its also in the upstream packaging
so it would be nice if these splits could stay (see notes below about
why keeping packaging consistent across upstream, Debian and Ubuntu is
a good idea).

>>> - ceph depends on fdisk, parted and whole lot other crap it
>>> does not need.
>> Agree on this. Don't know how it made there.
> 
> Because ceph-disk (another incompletely documented indirection)
> uses it. The important parts (ceph-mon, ceph-osd) works fine
> without it.

ceph-disk is a key part of the deployment infrastructure for ceph so
these are important dependencies for anyone deploying ceph at scale
using upstream Chef recipes or ceph-deploy.

>>> - A lot of Replaces.
>> There were package renames, users may have packages from upstream
>> or Ubuntu. That's make it complex.
> 
> Not a concern for Debian.  It was never in a stable release.

I think it is a concern for Debian; the principle source of Ceph
packages for Debian to-date has been from upstream, so ensuring smooth
transitions to/from Debian/upstream is important IMHO.

>>> - python-ceph needs stricter dependencies.
>> Will check.
> 
> At least the dependencies for librados2 and librdb1 needs to be 
> stricter.  The dependency on libcephfs1 is missing.

Agreed - python-ceph only just grew bindings for cephfs so that's just
an oversight. Good spot.  >= on equiv binary package version should do
the job for the librbd/rados depends.

Laszlo - re -java/-jni split - this is in compliance with the Java
packaging policy:

http://www.debian.org/doc/packaging-manuals/java-policy/x114.html

I really think we need to stick with the packaging structure and
naming that is already in place as much as possible; All of the
existing deployment tooling (chef, juju, ceph-deploy) is written based
on this structure on Debian based systems; diverging is just going to
create work in other areas and potentially alienate the Debian
packaging as its different to the packaging that the Ceph community
has been using for the last two years... at least!

FYI once ceph is up-to-date in Debian I'm intending on landing
ceph-deploy as a way of deploying ceph on Debian - it makes testing
much easier.

- -- 
James Page
Ubuntu and Debian Developer
james.page@ubuntu.com
jamespage@debian.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQIcBAEBCAAGBQJSNe0LAAoJEL/srsug59jDGLEP/3KDiq6fbzcNUeaw0JuCSK0F
QNfMdAQWRa86UX8zOJvtlhjbRJlwPWY4kRj52fxsXZTOcs+9t+ooTZ0ACwYTy0K3
jPscTwoev1rBvbYD1kJXCrd8OVg9I1WC0cK30OiPQ7y6SrTf+84fpHWHAZhcoQa7
TD5j+stSk0Nfko8Wj6K3xEy1J7PgoY16gcAbozEW/35zAz7tFUjhRgwJSJ9tBCdR
2H7rn2Dmxdk5RPNutKM1pKFiOdCTYOz87+ptYYdeKbvRuxU9b+dl2wb5U9D5IfTH
mBJm4dcQQr0IDxMdhG7VJxb/wSA8Nog5fxIxelloPg7wI65D4Lf/m0QvYXEpRc56
N5xCWaLKw5aTmh4Cviz7k6SvnXNfWoemF7LueETJFo1IUFS2jBB2tbYOcXFpzvhX
IrZN745JEIkSQ7071LpLYfB0/WyPr7Kcwgwx+4fr/Lo1tWKmm37fARic6TAJGkg7
V2K2pXH5kDWdTjnQ9//0NNVzAVUU9+JLiG0qWcXYCqmpAts8xnUvuG0CAAcQogmq
EP3QAm3f1u9w4jc5uRnRTFX38xuKnPZz3X6so8HCvB3jPjmiPZYZzhhR4OwqaXCz
wcQMRLyP+6lg3sV5teRaHhgnuzUXtGOV4870G9z0oycJavHANNGAPoHm3S8OJmd6
ImJkC6cOr0XQ4flnmaJp
=Jxi7
-----END PGP SIGNATURE-----

Message #109 received at 705262@bugs.debian.org (full text, mbox, reply):

From: Bastian Blank <waldi@debian.org>

To: James Page <james.page@ubuntu.com>

Cc: "László Böszörményi (GCS)" <gcs@debian.org>, 705262@bugs.debian.org

Subject: Re: Bug#705262: ceph

Date: Sun, 15 Sep 2013 21:04:19 +0200

On Sun, Sep 15, 2013 at 06:23:23PM +0100, James Page wrote:
> On 15/09/13 12:03, Bastian Blank wrote:
> > There is a python script ceph-rest-api.  Where is this used?  Why
> > does it warrant a dependency on 20 other packages?
> Dumpling (0.67.x) is the first release with basic support for a REST
> api for administering a ceph cluster - this binary supports this
> feature - but more of a demo of how to use than anything really usable
> (dev mode only).  However I do agree that it looks like it should be
> in ceph.

How does the authentication work?  The whole Python code in Ceph looks
pretty bad for me.

> > Because ceph-disk (another incompletely documented indirection)
> > uses it. The important parts (ceph-mon, ceph-osd) works fine
> > without it.
> ceph-disk is a key part of the deployment infrastructure for ceph so
> these are important dependencies for anyone deploying ceph at scale
> using upstream Chef recipes or ceph-deploy.

Well.  Then it would be one, not three diffrent implementations of
fdisk.

> > Not a concern for Debian.  It was never in a stable release.
> I think it is a concern for Debian; the principle source of Ceph
> packages for Debian to-date has been from upstream, so ensuring smooth
> transitions to/from Debian/upstream is important IMHO.

Nope.  Other sources are no concern.

> > At least the dependencies for librados2 and librdb1 needs to be 
> > stricter.  The dependency on libcephfs1 is missing.
> Agreed - python-ceph only just grew bindings for cephfs so that's just
> an oversight. Good spot.  >= on equiv binary package version should do
> the job for the librbd/rados depends.

Nope.  They need to be ==.  The (bad written) Python wrappers uses
ctypes, which does not implement a full ELF-loader.

> Laszlo - re -java/-jni split - this is in compliance with the Java
> packaging policy:
> http://www.debian.org/doc/packaging-manuals/java-policy/x114.html

You forgot the "should".  Plus this is not part of the Debian policy.

> I really think we need to stick with the packaging structure and
> naming that is already in place as much as possible; All of the
> existing deployment tooling (chef, juju, ceph-deploy) is written based
> on this structure on Debian based systems; diverging is just going to
> create work in other areas and potentially alienate the Debian
> packaging as its different to the packaging that the Ceph community
> has been using for the last two years... at least!

I'm talked to the ftp-masters.  They usualy don't like if a package is
split too much for no apparent reason.  It is nice if they are
compatible, but for Debian all problems have to be taken into account.

Bastian

-- 
Pain is a thing of the mind.  The mind can be controlled.
		-- Spock, "Operation -- Annihilate!" stardate 3287.2

Message #114 received at 705262@bugs.debian.org (full text, mbox, reply):

From: James Page <james.page@ubuntu.com>

To: Bastian Blank <waldi@debian.org>

Cc: "László Böszörményi (GCS)" <gcs@debian.org>, 705262@bugs.debian.org

Subject: Re: Bug#705262: ceph

Date: Sun, 15 Sep 2013 21:32:02 +0100

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 15/09/13 20:04, Bastian Blank wrote:
> On Sun, Sep 15, 2013 at 06:23:23PM +0100, James Page wrote:
>> On 15/09/13 12:03, Bastian Blank wrote:
>>> There is a python script ceph-rest-api.  Where is this used?
>>> Why does it warrant a dependency on 20 other packages?
>> Dumpling (0.67.x) is the first release with basic support for a
>> REST api for administering a ceph cluster - this binary supports
>> this feature - but more of a demo of how to use than anything
>> really usable (dev mode only).  However I do agree that it looks
>> like it should be in ceph.
> 
> How does the authentication work?  The whole Python code in Ceph
> looks pretty bad for me.

Ceph itself uses a key based kerberos style authentication system
called cephx; the ceph_rest_api library uses the keys/config in
/etc/ceph but provides no additional auth for HTTP API access; neither
does the wrapper ceph-rest-api which is why right now there is no init
script or upstart configuration for this feature.

I make no general observations about the python code in ceph other
than it's worked well for me for the last 18 months.

> 
>>> Because ceph-disk (another incompletely documented
>>> indirection) uses it. The important parts (ceph-mon, ceph-osd)
>>> works fine without it.
>> ceph-disk is a key part of the deployment infrastructure for ceph
>> so these are important dependencies for anyone deploying ceph at
>> scale using upstream Chef recipes or ceph-deploy.
> 
> Well.  Then it would be one, not three diffrent implementations of 
> fdisk.

Technically its just two - gdisk and parted; I don't have any strong
objection to upstream using two different tools if it makes massaging
block devices easier for them.

>>> Not a concern for Debian.  It was never in a stable release.
>> I think it is a concern for Debian; the principle source of Ceph 
>> packages for Debian to-date has been from upstream, so ensuring
>> smooth transitions to/from Debian/upstream is important IMHO.
> 
> Nope.  Other sources are no concern.

I'd like to try and play nice with other methods of distribution
especially if one of those has been used extensively by Debian users
to-date; makes life easier for potential users of these packages.

>>> At least the dependencies for librados2 and librdb1 needs to be
>>>  stricter.  The dependency on libcephfs1 is missing.
>> Agreed - python-ceph only just grew bindings for cephfs so that's
>> just an oversight. Good spot.  >= on equiv binary package version
>> should do the job for the librbd/rados depends.
> 
> Nope.  They need to be ==.  The (bad written) Python wrappers uses 
> ctypes, which does not implement a full ELF-loader.

OK; I know they are just a simple wrap over the core libs so that
makes sense.

>> Laszlo - re -java/-jni split - this is in compliance with the
>> Java packaging policy: 
>> http://www.debian.org/doc/packaging-manuals/java-policy/x114.html
>
>> 
> You forgot the "should".  Plus this is not part of the Debian
> policy.

Meh - well it works for me; the -java is arch independent whereas the
- -jni is not; saves duping the jar file in binary packages. If the -jni
every gets multi-arched then this approach is required anyway.

>> I really think we need to stick with the packaging structure and 
>> naming that is already in place as much as possible; All of the 
>> existing deployment tooling (chef, juju, ceph-deploy) is written
>> based on this structure on Debian based systems; diverging is
>> just going to create work in other areas and potentially alienate
>> the Debian packaging as its different to the packaging that the
>> Ceph community has been using for the last two years... at
>> least!
> 
> I'm talked to the ftp-masters.  They usualy don't like if a package
> is split too much for no apparent reason.  It is nice if they are 
> compatible, but for Debian all problems have to be taken into
> account.

I don't think the ceph packages are split for no apparent reason;  I
believe that by adopting the current structure which works with the
most popular deployment tooling for ceph we work with upstream, rather
than going against the grain.

- -- 
James Page
Ubuntu and Debian Developer
james.page@ubuntu.com
jamespage@debian.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQIcBAEBCAAGBQJSNhlBAAoJEL/srsug59jDgQgQAM91nm57XBaWGQoxJ6mC7hy3
n0hsT9ehI+FJDL2nC9jr1vSBCMgQKgfkt4LHrBXUt4t/Dz6YVu1vwZbmrhfP36Bi
O1WcZ+StIJZaBxHYq37XheoLqShR39VSPfGmp7dK5u0RBrcqj1PatVfF/oYrLSxL
KSkqmccaOeAvbE0G4gGuceEuLnR6ZI1kgeJkFCE0daEtJdDe89ojj3PBRz6H4Ya0
zRSP3Es4YcHgEr6vlFV0+jDNrsuq72g/1kn+ouW0jLQQ+a9+12+v4kkVBNL4fUBj
d9+2wwOEuiFOK1/tOGQjwc5XdOtPe+P6oHQ1uWoZzYOYOCw45+LDO6IIMgrr8+Xa
QtolHNKPJtEr24myCowOkQ9tmbrx7YRzs/y7EMAo6faYI7ZPDc6gwRZESUtiqAuJ
+HgyEGyqUjuJGOjQ0PIhB1KteJdJNoFFeAUAvbDh1UaEgMLdrRw+ZyFoC0NkeGjX
2xoHPIInN8v/qeOc1vGkwzCXg9SFe6VkVi338SU8M4k/nEGwPxr6TCgKs0bK+P9x
lbdK17HPr5ZtzmoMyVT83WPTyIad7IfyeLOU2N0EX3zbWaBwp1NplZhKRx+qeAGP
CYL5UdN0YQCXGiWbS4FFJrl2q603uuvq1FqiObGnMPZdjliBUnhqUXeBMgxuUNPB
cj7DnhsMhZO2xBA91WqV
=Mp6n
-----END PGP SIGNATURE-----

Message #121 received at 705262-close@bugs.debian.org (full text, mbox, reply):

From: Laszlo Boszormenyi (GCS) <gcs@debian.org>

To: 705262-close@bugs.debian.org

Subject: Bug#705262: fixed in ceph 0.67.3-1

Date: Sun, 27 Oct 2013 16:00:30 +0000

Source: ceph
Source-Version: 0.67.3-1

We believe that the bug you reported is fixed in the latest version of
ceph, 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 705262@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Laszlo Boszormenyi (GCS) <gcs@debian.org> (supplier of updated ceph 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 ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Tue, 01 Oct 2013 02:29:08 +0200
Source: ceph
Binary: ceph ceph-dbg ceph-mds ceph-mds-dbg ceph-fuse ceph-fuse-dbg rbd-fuse rbd-fuse-dbg ceph-common ceph-common-dbg ceph-fs-common ceph-fs-common-dbg ceph-resource-agents librados2 librados2-dbg librados-dev librbd1 librbd1-dbg librbd-dev libcephfs1 libcephfs1-dbg libcephfs-dev radosgw radosgw-dbg rest-bench rest-bench-dbg ceph-test ceph-test-dbg python-ceph libcephfs-java libcephfs-jni libcephfs-jni-dbg
Architecture: source amd64 all
Version: 0.67.3-1
Distribution: unstable
Urgency: low
Maintainer: Ceph Maintainers <ceph-maintainers@lists.ceph.com>
Changed-By: Laszlo Boszormenyi (GCS) <gcs@debian.org>
Description: 
 ceph       - distributed storage and file system
 ceph-common - common utilities to mount and interact with a ceph storage cluste
 ceph-common-dbg - debugging symbols for ceph-common
 ceph-dbg   - debugging symbols for ceph
 ceph-fs-common - common utilities to mount and interact with a ceph file system
 ceph-fs-common-dbg - debugging symbols for ceph-fs-common
 ceph-fuse  - FUSE-based client for the Ceph distributed file system
 ceph-fuse-dbg - debugging symbols for ceph-fuse
 ceph-mds   - metadata server for the ceph distributed file system
 ceph-mds-dbg - debugging symbols for ceph-mds
 ceph-resource-agents - OCF-compliant resource agents for Ceph
 ceph-test  - Ceph test and benchmarking tools
 ceph-test-dbg - Debugging symbols for ceph-test
 libcephfs-dev - Ceph distributed file system client library (development files)
 libcephfs-java - Java library for the Ceph File System
 libcephfs-jni - Java Native Interface library for CephFS Java bindings
 libcephfs-jni-dbg - Debugging symbols for libcephfs-jni
 libcephfs1 - Ceph distributed file system client library
 libcephfs1-dbg - debugging symbols for libcephfs1
 librados-dev - RADOS distributed object store client library (development files)
 librados2  - RADOS distributed object store client library
 librados2-dbg - debugging symbols for librados2
 librbd-dev - RADOS block device client library (development files)
 librbd1    - RADOS block device client library
 librbd1-dbg - debugging symbols for librbd1
 python-ceph - Python libraries for the Ceph distributed filesystem
 radosgw    - REST gateway for RADOS distributed object store
 radosgw-dbg - debugging symbols for radosgw
 rbd-fuse   - FUSE-based rbd client for the Ceph distributed file system
 rbd-fuse-dbg - debugging symbols for rbd-fuse
 rest-bench - RESTful bencher that can be used to benchmark radosgw performance
 rest-bench-dbg - RESTful bencher that can be used to benchmark radosgw performance
Closes: 693866 705262 722957
Changes: 
 ceph (0.67.3-1) unstable; urgency=low
 .
   [ Laszlo Boszormenyi ]
   * New upstream release (Closes: #693866, #705262).
   * Update debian/copyright.
   * Sync with Ubuntu.
 .
   [ James Page ]
   * d/control,rules,libcephfs-{java,jni}: Enable Java CephFS library,
     add new BD's on javahelper and default-jdk, add dbg package.
   * d/control: Add new BD on libboost-thread-dev for RADOS Gateway
     keystone integration.
   * d/{control,obsync.install}: Drop obsync package inline with
     upstream.
   * d/librbd-dev.install: Pickup new features.h file.
   * Remove manual calls to ldconfig:
     - d/lib{rados2|rbd1|cephfs1}.post*: Dropped - all these do is call
       ldconfig which will automatically be done.
     - d/rules: Let dh_makeshlibs do its magic with postinst/postrm.
   * d/tests/*: Added autopkgtests for librbd, librados, python-ceph
     and the ceph CLI.
   * d/control: Fix versions of librbd1, librados2 and libcephfs1 for
     python-ceph as it requires an exact version match.
   * d/ceph.docs: Drop - README from upstream is only useful for developers
     (Closes: #722957).
   * d/rules: Drop --upstart-only from dh_installinit calls for upstart
     configurations; this is deprecated in Ubuntu and not support in Debian.
   * d/rules: Exclude jni package from shlibs generation to avoid pointless
     ldconfig calls in maintainer scripts.
 .
   [ Bastian Blank ]
   * Use debhelper 9.
   * Use dh-autoreconf.
   * Install files from source tree if possible.
   * Run test-suite:
     - Build-depend on python-virtualenv.
     - Ask virtualenv to never download anything.
   * Fix clean target.
   * Properly mark library modules:
     - Don't longer exclude them from stripping.
   * Drop all libtool .la files.
   * Generate python dependencies.
   * Don't exclude stuff from shlibs generation.
Checksums-Sha1: 
 ac3a5c14c17471fa12d4b17299528d730e0fd693 3225 ceph_0.67.3-1.dsc
 fc06a2364512058783020c7c0441759734735770 4279916 ceph_0.67.3.orig.tar.gz
 66f3b76d28bb6e0daa2b14ce8981c1cfb589b415 14737 ceph_0.67.3-1.debian.tar.gz
 5e53567df2d568648cc6b0695003a4dd104bb8df 3959950 ceph_0.67.3-1_amd64.deb
 0dd2afb338df5493aae1cbaf7a1a89e2a8f5a24b 73920098 ceph-dbg_0.67.3-1_amd64.deb
 c88e6717c8465ec38d36676a7e89bfd5f17f454a 1934128 ceph-mds_0.67.3-1_amd64.deb
 7bb70299045b8b494c251af1236bc51af9caeda6 33781622 ceph-mds-dbg_0.67.3-1_amd64.deb
 ec2a72b2b3ac246da45287253251ec4575e887da 1202426 ceph-fuse_0.67.3-1_amd64.deb
 6eedecfb26b8c76f485f64adfb2602e4a823ecbe 17995138 ceph-fuse-dbg_0.67.3-1_amd64.deb
 ef46583a63c07a9bc30f2c66502aece545f49ec1 14146 rbd-fuse_0.67.3-1_amd64.deb
 37d117201a692241cc1f95d6515b5fdcaae4fd32 20736 rbd-fuse-dbg_0.67.3-1_amd64.deb
 c6ff2f689d7baef377553d64da3bfcfc2b5ea0c8 3416752 ceph-common_0.67.3-1_amd64.deb
 5f7ad2d910f410de4b711a95c2d2be4e6c4dec6f 67502252 ceph-common-dbg_0.67.3-1_amd64.deb
 e8775f5cd1e9984e30bc7fa505a13b06d3b62726 25794 ceph-fs-common_0.67.3-1_amd64.deb
 f14a18b731e0bcf2c6fe3ffdf48f8ec926705c5c 68932 ceph-fs-common-dbg_0.67.3-1_amd64.deb
 fae6e37c80b1fe7c66792fc8c65186bfd64b72c5 9616 ceph-resource-agents_0.67.3-1_all.deb
 4b3f2fa87291867e0e19b41a75ffd359738175f7 1171820 librados2_0.67.3-1_amd64.deb
 ba3dbdae2ac0281a767d0eb5e008eb4d0222494c 17397840 librados2-dbg_0.67.3-1_amd64.deb
 5d2999a626b78348c92439b301d46c07d9bb7d9c 1401668 librados-dev_0.67.3-1_amd64.deb
 be1c13e635c55d80b06c91912b578ecca30bc790 220866 librbd1_0.67.3-1_amd64.deb
 9b5a40b9a3ead0499371bbb849ec3298bfb37d4d 4064668 librbd1-dbg_0.67.3-1_amd64.deb
 5d7fcb7606f5f91ca38372a0c92b3ebb57960e57 4322056 librbd-dev_0.67.3-1_amd64.deb
 cd47b915ad48eeecfabff2ba13a8934cac9bdb40 1316272 libcephfs1_0.67.3-1_amd64.deb
 48fd92b85f8b083933b670f5360eb73ea1091455 19649936 libcephfs1-dbg_0.67.3-1_amd64.deb
 2616586836ad6ac7e0f997790bf41a9730a57a46 21950826 libcephfs-dev_0.67.3-1_amd64.deb
 1d57cfacf015ea482c49feaaaa658d3e5fb81673 783560 radosgw_0.67.3-1_amd64.deb
 4aa3f63449a18dbf9a36f994f953bc1611691eb7 16519064 radosgw-dbg_0.67.3-1_amd64.deb
 d8a9d696825b0deb54f0d6bcd34982f871d7080a 352354 rest-bench_0.67.3-1_amd64.deb
 2a545120b2d5d5e4b0f86f951ae3394ce712a36d 4402736 rest-bench-dbg_0.67.3-1_amd64.deb
 a5d070790e1f1b7979d4735648c20bc978921945 11847650 ceph-test_0.67.3-1_amd64.deb
 3ee136789d762a2b24a6281eea26f8914090e858 266078820 ceph-test-dbg_0.67.3-1_amd64.deb
 3167dbc910260b1f8b808ade088e35af18fece6e 36348 python-ceph_0.67.3-1_amd64.deb
 852fc3fd71f4939ba75bc688d527f23c0979abe4 14754 libcephfs-java_0.67.3-1_all.deb
 7f9a525a25675cacdc45e009ebd2ecc4d99d3fad 34576 libcephfs-jni_0.67.3-1_amd64.deb
 313391254b41e8d80be5939a8bd51b907184dd68 256966 libcephfs-jni-dbg_0.67.3-1_amd64.deb
Checksums-Sha256: 
 cd74bba98ffea2c22e6acaecc0a695e5201f9fc5bbbd2a2febb1a866bdb8e24b 3225 ceph_0.67.3-1.dsc
 8dd0d0fd036dff5aebdc66608154dc54db5b10bba34d446adb2c3f38efeeaba8 4279916 ceph_0.67.3.orig.tar.gz
 b2c3c41029e0032d61349f3063a3486ac70837b4ed3aa49ecb5c2a076834d43a 14737 ceph_0.67.3-1.debian.tar.gz
 65e83c46b9e4f46d32b249b253a181eba18c40834cc4a9e04b2b319460265311 3959950 ceph_0.67.3-1_amd64.deb
 292b2250bde35babd6d9841b2e31834918d2146221eb909d2bc9f351519f0714 73920098 ceph-dbg_0.67.3-1_amd64.deb
 b8b4324ec6dae908eacfd0fadaf51842280fbccb09adf8a86de607c7eaa9de25 1934128 ceph-mds_0.67.3-1_amd64.deb
 a04ce94a8ec53c2146eaa052ab2aa77a471fd31519886b4822ae86c4a1cf2ce5 33781622 ceph-mds-dbg_0.67.3-1_amd64.deb
 d358bea9d470f762ec267ab19929a4c881358f881e57bc6f8145ec49a309b3ca 1202426 ceph-fuse_0.67.3-1_amd64.deb
 e2566c16ee60b430b872af60f538e482d92560685b64ea0ae8ea95ea773af898 17995138 ceph-fuse-dbg_0.67.3-1_amd64.deb
 335b97e9d258bb5cbc9fd9eb29ccb3db01fa2976a9c9ce3972a9643ed1edc96b 14146 rbd-fuse_0.67.3-1_amd64.deb
 470b3888762d75ed39a6e3df17a4e5c4019f9047bcf4ba1d7565a37792aa20bd 20736 rbd-fuse-dbg_0.67.3-1_amd64.deb
 3eb99695ae001ffa93bf5d388409166b033a02fafd85040b4f48a33dd6e8f18e 3416752 ceph-common_0.67.3-1_amd64.deb
 6800c1676dfdb715d21dec15a6a9b4de8c6557d484924760bc26e9ba2de429b9 67502252 ceph-common-dbg_0.67.3-1_amd64.deb
 f3edc0414905d2c5e751f0add59baa28c984ae6123cad3b174dc89c87b13a4d8 25794 ceph-fs-common_0.67.3-1_amd64.deb
 9a626ca7df94d30df87de85747798bfba6557994e745e07d24c9c8d66ae578c8 68932 ceph-fs-common-dbg_0.67.3-1_amd64.deb
 a168dead82dd72aa2daf84867692b3986a44166d33e9949fed2e26ff309d2856 9616 ceph-resource-agents_0.67.3-1_all.deb
 05ca80177556c3505d92a26d98db3a0d28da3515b508dd05539a606cb8c461d7 1171820 librados2_0.67.3-1_amd64.deb
 eb297d44a5f153b0f166f02abb6e5612f29e843489001790b3ae83318ad0402f 17397840 librados2-dbg_0.67.3-1_amd64.deb
 1c8c6db37cddf9847fc25b67d2c44660494567e006530f74174cd457ad05b2bc 1401668 librados-dev_0.67.3-1_amd64.deb
 0e2b6fe87d251a18f6294971d9939feec7824d03d0244dbcedac213136c6f4a3 220866 librbd1_0.67.3-1_amd64.deb
 83838c8937da954292f17ffbfc3d37fc4690bc4cd3e11b4033545594b120c8d1 4064668 librbd1-dbg_0.67.3-1_amd64.deb
 6efd6935f80edaea223d542b23e92f4924a90c73ef2a61006a04cdb726878f66 4322056 librbd-dev_0.67.3-1_amd64.deb
 61e887aae48cdce8147faea2871471c82876c19215cf2b5c9bd7f0b49dcad9bf 1316272 libcephfs1_0.67.3-1_amd64.deb
 646013f984fdc7fb70aae985277076e129fb80b5f1785aaac23d00e4d864b249 19649936 libcephfs1-dbg_0.67.3-1_amd64.deb
 e0423109fbab263e6ee8ba46ca7d2590092437c1dee4508d605dbbe6d26fb284 21950826 libcephfs-dev_0.67.3-1_amd64.deb
 774791c8169f3f9a5f070c4123ef918d85fe1d97add63f740deb678b832d4236 783560 radosgw_0.67.3-1_amd64.deb
 a84dccab8e774e30c97979c6fffad7a793e83197be3ca3eb390e036bb2abd768 16519064 radosgw-dbg_0.67.3-1_amd64.deb
 983c84c9a66cf22d0d275616ff09fe472053e391d6297e50b9c5db6dd36931cb 352354 rest-bench_0.67.3-1_amd64.deb
 ae596f3591dda0bab5cc2f0d230eafa74bb7db0a42829446cf0c97eda8262620 4402736 rest-bench-dbg_0.67.3-1_amd64.deb
 7352324d5d64f5e87f89a8b554db4e2573df6a10c855accd75f90430a2d983ee 11847650 ceph-test_0.67.3-1_amd64.deb
 6067040f5c2a9187cced6c629e6422da5702d3de34bf1a6767208935aa7a92c8 266078820 ceph-test-dbg_0.67.3-1_amd64.deb
 ca297710c4718df67b0ad2f63552368c4accf424ea3e2ae49c4c2b7ddd1d5af2 36348 python-ceph_0.67.3-1_amd64.deb
 d8e5686f23b713a4638b9533554085febbc405126d50f49de73dfcffe3c6a591 14754 libcephfs-java_0.67.3-1_all.deb
 410757f65d1a69006ddb4cec2fb26c54308041affb049a226543d3df75239550 34576 libcephfs-jni_0.67.3-1_amd64.deb
 a7cf9ee78780de68d674872f6db4f4ca1b89d3ec8a1458bbbc1e9362f42b80ea 256966 libcephfs-jni-dbg_0.67.3-1_amd64.deb
Files: 
 ed2dc4fec453efac0b0c9372ae9f8be8 3225 admin optional ceph_0.67.3-1.dsc
 480db3f01ad21644402ca3b6d641450f 4279916 admin optional ceph_0.67.3.orig.tar.gz
 42bb8d360680f3cb8cd879c0a41b6c8a 14737 admin optional ceph_0.67.3-1.debian.tar.gz
 9b300adaf64e6fb4392a188eee78c91a 3959950 admin optional ceph_0.67.3-1_amd64.deb
 ca1844153983da4d93f20ff24406b06d 73920098 debug extra ceph-dbg_0.67.3-1_amd64.deb
 f7183eedc5a11af3745d8daf3053137b 1934128 admin optional ceph-mds_0.67.3-1_amd64.deb
 da2909c1dc844f9e2fefdbe53358f3a6 33781622 debug extra ceph-mds-dbg_0.67.3-1_amd64.deb
 b379095b506f736fc9e1bcaacc5574a6 1202426 admin optional ceph-fuse_0.67.3-1_amd64.deb
 3edb2e0d3081d9f213c78ca5ffbb3c17 17995138 debug extra ceph-fuse-dbg_0.67.3-1_amd64.deb
 159018b46e96137dd9380e1992cecccb 14146 admin optional rbd-fuse_0.67.3-1_amd64.deb
 8c67f046e6f5176fa61db717cd4f62d3 20736 debug extra rbd-fuse-dbg_0.67.3-1_amd64.deb
 fb3e5051aa5a276a33060032e163c9c8 3416752 admin optional ceph-common_0.67.3-1_amd64.deb
 177660c464cccd32605c7c2ed0df28d0 67502252 debug extra ceph-common-dbg_0.67.3-1_amd64.deb
 acf6d5cfb12c7d1210741678511399bd 25794 admin optional ceph-fs-common_0.67.3-1_amd64.deb
 fe2663f8fdb12800a9e57edf7070c26a 68932 debug extra ceph-fs-common-dbg_0.67.3-1_amd64.deb
 7974b9b91d88a9ff7f357f4e39654e8d 9616 admin extra ceph-resource-agents_0.67.3-1_all.deb
 f0fcac08afcf6ba6c4b6c53f4ad37d1e 1171820 libs optional librados2_0.67.3-1_amd64.deb
 07393572c8e5be5e2eb63773d18358d9 17397840 debug extra librados2-dbg_0.67.3-1_amd64.deb
 00deacf3be554e17c5fbe5efb1194108 1401668 libdevel optional librados-dev_0.67.3-1_amd64.deb
 ee6529a1431805f8e0b0d3b9d105c4a2 220866 libs optional librbd1_0.67.3-1_amd64.deb
 b9313c9dbda03a236a97eeb063975364 4064668 debug extra librbd1-dbg_0.67.3-1_amd64.deb
 d1dd304b8c41860ecbe6d75d8fb73a56 4322056 libdevel optional librbd-dev_0.67.3-1_amd64.deb
 09dac5844102e59893df974ce2961d8d 1316272 libs optional libcephfs1_0.67.3-1_amd64.deb
 82d698fb933cb4828b50034d385147b2 19649936 debug extra libcephfs1-dbg_0.67.3-1_amd64.deb
 0ba644fae0e4723a2b87032b7a04aa4d 21950826 libdevel optional libcephfs-dev_0.67.3-1_amd64.deb
 a05b3db02c42b193ceb6d67de96046a6 783560 admin optional radosgw_0.67.3-1_amd64.deb
 c30fc2b5c46891f51c026602775f7154 16519064 debug extra radosgw-dbg_0.67.3-1_amd64.deb
 20bdc5a48186265793ee13e6bb05c61e 352354 admin optional rest-bench_0.67.3-1_amd64.deb
 dc8c7ed69374161ef5c23a849e28f600 4402736 debug extra rest-bench-dbg_0.67.3-1_amd64.deb
 bd40bec019ef6cf0252cfdafb2b699d6 11847650 admin optional ceph-test_0.67.3-1_amd64.deb
 451429276315b3d500a5cfad6612007b 266078820 debug extra ceph-test-dbg_0.67.3-1_amd64.deb
 176c984fabe63289974e9fe41b38c3eb 36348 python optional python-ceph_0.67.3-1_amd64.deb
 025509b041a3cd79de7b1871bfc695ce 14754 java optional libcephfs-java_0.67.3-1_all.deb
 1d62d6b4c9c79dba32be6dec72c4cd61 34576 libs optional libcephfs-jni_0.67.3-1_amd64.deb
 45e0992b227c1291506c00dc55b14f92 256966 debug extra libcephfs-jni-dbg_0.67.3-1_amd64.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iEYEARECAAYFAlJKVYMACgkQMDatjqUaT92H7gCgi2xNcJs1iCN+bgQzt+1cY6LE
OnkAnj4wujjb6ftSRdGyyddYUyvZpWUd
=iVJE
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.