Bug#506040: Status of ceph ITP?
On Sat, 2010-12-18 at 22:08 -0500, Asheesh Laroia wrote: I have nothing to contribute to this, except: Thanks to Sage and Clint for pinging us again! Here's another ping. Seeing as squeeze is out, and the NEW queue is, as I understand it, hundreds and hundreds of packages long right now, it would probably be good to get CEPH into that NEW queue ASAP. I'm a little unclear where any additional packaging changes reside, but I've gone ahead and packaged 0.24.2 for Ubuntu, it is here: https://code.launchpad.net/~clint-fewbar/ubuntu/natty/ceph/upstream-0.24 Note a few changes for policy v3.9.1 including removing the .la files from the -dev libs. -- 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/1297103194.3020.381.camel@clint-MacBookPro
Bug#506040: Status of ceph ITP?
Hi Clint, On Mon, 2011-02-07 at 10:26 -0800, Clint Byrum wrote: Seeing as squeeze is out, and the NEW queue is, as I understand it, hundreds and hundreds of packages long right now, it would probably be good to get CEPH into that NEW queue ASAP. Please don't get me wrong, but did you check the NEW queue? I've uploaded ceph there[1] for more than two months. It's not processed yet, but I hope that the backlog of the queue is going to shrink as Squeeze is out. I'm a little unclear where any additional packaging changes reside, but I've gone ahead and packaged 0.24.2 for Ubuntu, it is here: I've also packaged it a while ago and also uploaded to the NEW queue[2]. Note a few changes for policy v3.9.1 including removing the .la files from the -dev libs. Well, it's not entirely true. The exact wording[3] says [...] For public libraries intended for use by other packages, these files normally should not be included in the Debian package, since the information they include is not necessary to link with the shared library on Debian and can add unnecessary additional dependencies to other programs or libraries. [...]. Of course please read the whole paragraph. In short, it's not 'you must remove all *.la files'; but yes, I should remove them as well. I hope I can check your packages today and may write an other mail. Cheers, Laszlo/GCS [1] http://ftp-master.debian.org/new/ceph_0.24-1.html [2] http://ftp-master.debian.org/new/ceph_0.24.2-1.html [3] http://www.debian.org/doc/debian-policy/ch-files.html#s-libraries -- 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/1297105745.4008.16.ca...@julia.gcs.org.hu
Bug#506040: Status of ceph ITP?
On Mon, 2011-02-07 at 20:09 +0100, Laszlo Boszormenyi wrote: Hi Clint, On Mon, 2011-02-07 at 10:26 -0800, Clint Byrum wrote: Seeing as squeeze is out, and the NEW queue is, as I understand it, hundreds and hundreds of packages long right now, it would probably be good to get CEPH into that NEW queue ASAP. Please don't get me wrong, but did you check the NEW queue? I've uploaded ceph there[1] for more than two months. It's not processed yet, but I hope that the backlog of the queue is going to shrink as Squeeze is out. Ah! I did not. That is good to see then. :) I'm a little unclear where any additional packaging changes reside, but I've gone ahead and packaged 0.24.2 for Ubuntu, it is here: I've also packaged it a while ago and also uploaded to the NEW queue[2]. Note a few changes for policy v3.9.1 including removing the .la files from the -dev libs. Well, it's not entirely true. The exact wording[3] says [...] For public libraries intended for use by other packages, these files normally should not be included in the Debian package, since the information they include is not necessary to link with the shared library on Debian and can add unnecessary additional dependencies to other programs or libraries. [...]. Of course please read the whole paragraph. In short, it's not 'you must remove all *.la files'; but yes, I should remove them as well. I hope I can check your packages today and may write an other mail. Right, its not a must but a should. Still, this seems reason enough to leave them out. Since the license issue is critical, I'm going to go ahead and leave the ubuntu package up for sponsorship so the bug is closed ASAP. Once your packages clear the debian queue, it should be easy enough to issue a sync request to override the -0ubuntu1 packages. -- 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/1297108469.3020.388.camel@clint-MacBookPro
Bug#506040: Status of ceph ITP?
I have nothing to contribute to this, except: Thanks to Sage and Clint for pinging us again! And thanks to Laszlo for his excellent review and packaging work. I'm happy to stay CC:d so I can keep track of this lovely packaging process! -- Asheesh. -- 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/alpine.deb.2.00.1012182207140.8...@rose.makesad.us
Bug#506040: Status of ceph ITP?
Hi Sage, Yehuda, On Fri, 2010-12-03 at 22:02 -0800, Yehuda Sadeh Weinraub wrote: [ about OpenSSL license exception for ceph ] I removed all the openssl references in the ceph code and replaced it with crypto++, so hopefully all this discussion is now moot. It's all pushed to the ceph rc branch. Does it mean that I shouldn't upload v0.23.2 [1] to Debian? Wait for the v0.24.0 release and upload that one? I know v0.23.2 is not even noted as a release on the homepage, but tagged in the git tree. Main changes are that debian/source/format is re-added, the tree cleaned as make distclean, backported cephfs.8 manpage as a patch, pristine clean the source, noted myself as maintainer while Sage remains as an uploader. Laszlo/GCS Ps: Please delete parts of the email that not relevant to the conversation. [1] dget http://www.routers.hu/gcs/ceph_0.23.2-1.dsc -- 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/1291467221.25001.30.ca...@julia.gcs.org.hu
Bug#506040: Status of ceph ITP?
Hey Laszlo, On Sat, 4 Dec 2010, Laszlo Boszormenyi wrote: On Fri, 2010-12-03 at 22:02 -0800, Yehuda Sadeh Weinraub wrote: [ about OpenSSL license exception for ceph ] I removed all the openssl references in the ceph code and replaced it with crypto++, so hopefully all this discussion is now moot. It's all pushed to the ceph rc branch. Does it mean that I shouldn't upload v0.23.2 [1] to Debian? Wait for the v0.24.0 release and upload that one? I know v0.23.2 is not even noted as a release on the homepage, but tagged in the git tree. Main changes are that debian/source/format is re-added, the tree cleaned as make distclean, backported cephfs.8 manpage as a patch, pristine clean the source, noted myself as maintainer while Sage remains as an uploader. Yeah, let's just wait for 0.24. BTW, I made radosacl only build --with-debug; it can be dropped from the package. Thanks- sage Laszlo/GCS Ps: Please delete parts of the email that not relevant to the conversation. [1] dget http://www.routers.hu/gcs/ceph_0.23.2-1.dsc -- To unsubscribe from this list: send the line unsubscribe ceph-devel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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/pine.lnx.4.64.1012042108030.28...@cobra.newdream.net
Bug#506040: Status of ceph ITP?
On Thu, Dec 2, 2010 at 8:57 AM, Laszlo Boszormenyi g...@debian.hu wrote: Hi Clint, On Wed, 2010-12-01 at 23:19 -0800, Clint Byrum wrote: On Thu, 2010-12-02 at 01:30 +0100, Laszlo Boszormenyi wrote: Essentially, as long as the files don't have a license that conflicts with COPYING, then there's no need for a license header. Got a confirmation from an FTP Assistant, Mike O'Connor; he says exactly the same. Its not required, for instance, that every single .h .c file etc have a license information, as long as it can be reasonably assumed that we know the copyright holders' intention. When the upstream author says i'm the copyright holder for everything in the src directory, and its distributable under the LGPL, we'll assume this to be correct unless there is something that indicates otherwise. I just have a memory that recently a package was rejected due to this, but I assume it neither had the license information in debian/copyright . Laszlo, I did a thorough review of the licensing before working to get ceph uploaded to Ubuntu, but I wasn't aware of the incompatibility between the GPL/LGPL and OpenSSL. This page details it pretty well: http://people.gnome.org/~markmc/openssl-and-the-gpl.html Please note two things. First is the bottom line of the page which says: Usual disclaimers apply, I've no legal background whatsoever, don't trust a word I say ... I'm quite probably completely wrong. and it was written in 2004. More recently, three months ago a bug was filed[1] in Debian that states there's indeed a need for that license exception for a GPL programs. On the other hand, yes, I do realize that ceph is mostly LGPL which may or may not need this exception. Just found a conversation on debian-legal, where the second message[2] states: There is no need for an OpenSSL exception for a LGPL-licensed work.; thus I'm ready to upload ceph as soon as the two missing manpages are written. Also Sage, if the other authors (or you) are not comfortable with the OpenSSL advertising clause, there's always GNUTLS which exists in large part to address this sort of thing. Rewrite the SSL part may not be that easy, but see above that it seems it's not needed for LGPL sources. I removed all the openssl references in the ceph code and replaced it with crypto++, so hopefully all this discussion is now moot. It's all pushed to the ceph rc branch. I tried using gnutls, but it didn't quite fit ceph's needs (only requires a few lower level crypto functions and it seems that gnutls hasn't exported those up until recently or at least I haven't found an easy way to do this). IANAL but for my untrained eyes the crypto++ seems ok in terms of GPL compatibility. Although most of ceph's code is LGPL, we do have a couple of utilities that are licensed as GPL and might pose a license conflict, so removing openssl seems the best road to choose. Yehuda -- 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/aanlktikz6y6qt4oqe+gvmdbmsrh-kve9l_4ok8jsy...@mail.gmail.com
Bug#506040: Status of ceph ITP?
Hi Clint, On Wed, 2010-12-01 at 23:19 -0800, Clint Byrum wrote: On Thu, 2010-12-02 at 01:30 +0100, Laszlo Boszormenyi wrote: Essentially, as long as the files don't have a license that conflicts with COPYING, then there's no need for a license header. Got a confirmation from an FTP Assistant, Mike O'Connor; he says exactly the same. Its not required, for instance, that every single .h .c file etc have a license information, as long as it can be reasonably assumed that we know the copyright holders' intention. When the upstream author says i'm the copyright holder for everything in the src directory, and its distributable under the LGPL, we'll assume this to be correct unless there is something that indicates otherwise. I just have a memory that recently a package was rejected due to this, but I assume it neither had the license information in debian/copyright . Laszlo, I did a thorough review of the licensing before working to get ceph uploaded to Ubuntu, but I wasn't aware of the incompatibility between the GPL/LGPL and OpenSSL. This page details it pretty well: http://people.gnome.org/~markmc/openssl-and-the-gpl.html Please note two things. First is the bottom line of the page which says: Usual disclaimers apply, I've no legal background whatsoever, don't trust a word I say ... I'm quite probably completely wrong. and it was written in 2004. More recently, three months ago a bug was filed[1] in Debian that states there's indeed a need for that license exception for a GPL programs. On the other hand, yes, I do realize that ceph is mostly LGPL which may or may not need this exception. Just found a conversation on debian-legal, where the second message[2] states: There is no need for an OpenSSL exception for a LGPL-licensed work.; thus I'm ready to upload ceph as soon as the two missing manpages are written. Also Sage, if the other authors (or you) are not comfortable with the OpenSSL advertising clause, there's always GNUTLS which exists in large part to address this sort of thing. Rewrite the SSL part may not be that easy, but see above that it seems it's not needed for LGPL sources. Laszlo/GCS [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595446 [2] http://lists.debian.org/debian-legal/2008/06/msg7.html -- 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/1291309051.14018.667.ca...@julia.gcs.org.hu
Bug#506040: Status of ceph ITP?
Hi Sage, On Tue, 2010-11-30 at 10:21 -0800, Sage Weil wrote: Great! There are a handful of bug fixes I'd like to roll into v0.23.2 first, if it isn't too much trouble. I can do that today. I've found the manpage problem that I've noted before. It's about monmaptool, the CLI says it's usage: [--print] [--create [--clobber]] [--add name 1.2.3.4:567] [--rm name] mapfilename But the manpage states this as an example: monmaptool --create --add 192.168.0.10:6789 --add 192.168.0.11:6789 --add 192.168.0.12:6789 --clobber monmap This definitely misses 'name' after the 'add' switch, resulting: invalid ip:port '--add' as an error message. Attached patch fixes this inconsistency. Clint, do you see any remaining issues I should fix first? Just for the record, I have tested ceph on Ubuntu Maverick. It builds fine and upgrades from the previous version in the archive. Clint is lost somewhere :-( , but I think everything is OK from his side as well. So what if I would step in for being the packager of ceph both in Debian and Ubuntu? Sage can contact me before he makes a release, I adjust the packaging if necessary and he can roll out packages immediately. I recheck them and if they are OK, I make the upload to the archives. All I need is a commit right to the debian/ subdir in the git tree of ceph. Regards, Laszlo/GCS --- ./man/monmaptool.8.orig 2010-12-01 17:27:15.136967000 +0100 +++ ./man/monmaptool.8 2010-12-01 17:33:58.352967001 +0100 @@ -34,15 +34,15 @@ \fB\-\-create\fP will create a new monitor map with a new UUID (and with it, a new, empty Ceph file system). .TP -\fB\-\-add\fI ip:port\fP +\fB\-\-add\fI name ip:port\fP will add a monitor with the specified \fIip:port\fP to the map. .TP -\fB\-\-rm\fI ip:port\fP +\fB\-\-rm\fI name\fP will remove the monitor with the specified \fIip:port\fP from the map. .SH EXAMPLE To create a new map with three monitors (for a fresh Ceph file system): .IP -monmaptool --create --add 192.168.0.10:6789 --add 192.168.0.11:6789 --add 192.168.0.12:6789 --clobber monmap +monmaptool --create --add mon0 192.168.0.10:6789 --add mon1 192.168.0.11:6789 --add mon2 192.168.0.12:6789 --clobber monmap .PP To display the contents of the map: .IP @@ -50,7 +50,7 @@ .PP To replace one monitor: .IP -monmaptool --rm 192.168.0.10:6789 --add 192.168.0.9:6789 --clobber monmap +monmaptool --rm mon0 --add mon0 192.168.0.9:6789 --clobber monmap .SH AVAILABILITY .B monmaptool is part of the Ceph distributed file system. Please refer to the Ceph wiki at
Bug#506040: Status of ceph ITP?
Hi Laszlo, On Wed, 1 Dec 2010, Laszlo Boszormenyi wrote: Hi Sage, On Tue, 2010-11-30 at 10:21 -0800, Sage Weil wrote: Great! There are a handful of bug fixes I'd like to roll into v0.23.2 first, if it isn't too much trouble. I can do that today. I've found the manpage problem that I've noted before. It's about monmaptool, the CLI says it's usage: [--print] [--create [--clobber]] [--add name 1.2.3.4:567] [--rm name] mapfilename But the manpage states this as an example: monmaptool --create --add 192.168.0.10:6789 --add 192.168.0.11:6789 --add 192.168.0.12:6789 --clobber monmap This definitely misses 'name' after the 'add' switch, resulting: invalid ip:port '--add' as an error message. Attached patch fixes this inconsistency. Applied, thanks! Clint, do you see any remaining issues I should fix first? Just for the record, I have tested ceph on Ubuntu Maverick. It builds fine and upgrades from the previous version in the archive. Clint is lost somewhere :-( , but I think everything is OK from his side as well. So what if I would step in for being the packager of ceph both in Debian and Ubuntu? Sage can contact me before he makes a release, I adjust the packaging if necessary and he can roll out packages immediately. I recheck them and if they are OK, I make the upload to the archives. All I need is a commit right to the debian/ subdir in the git tree of ceph. Can you take a look at the 'testing' branch in git commit 5bdae2af? That's how I've been doing releases, more or less. Assuming packaging issues are sorted out prior to that point, that's all that should be needed, right? I can also set you up with push access to update the debian/ stuff at your leisure without sending patches over the list. (BTW, the v0.23.2 bugfix release is mostly pointless as v0.24 is just a couple days away anyway. Just for the sake of illustration...) sage -- 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/pine.lnx.4.64.1012011010570.29...@cobra.newdream.net
Bug#506040: Status of ceph ITP?
Hi Sage, On Wed, 2010-12-01 at 10:15 -0800, Sage Weil wrote: Can you take a look at the 'testing' branch in git commit 5bdae2af? That's how I've been doing releases, more or less. Assuming packaging issues are sorted out prior to that point, that's all that should be needed, right? I think I've noted that cephfs and radosacl are without manpages. Please write one for them. Do you have an upstream changelog somewhere? ChangeLog is still empty. Really minor that I write 'new upstream release' to debian/changelog . Otherwise it's OK for uploading. I can also set you up with push access to update the debian/ stuff at your leisure without sending patches over the list. Would be easier with push rights for debian/ if you trust me. I've my GnuPG key that you can check with any local or nearby Debian Developer(s) that I'm in the web of trust. (BTW, the v0.23.2 bugfix release is mostly pointless as v0.24 is just a couple days away anyway. Just for the sake of illustration...) There's no chance that ceph will be included in Squeeze and the next release of Ubuntu is several months away. You have time and it's your decision when should I first upload ceph. Please note that Debian is in freeze ATM, it may need even two weeks to be accepted to the archive[1]; and even if it's in the NEW queue, I can upload new versions into it. I'm not an ftp-master, but your package maybe rejected[2] for two reasons. I think only debian/copyright is not enough, all source files should have a comment header about their license in short. You have it in cephfs.cc , cfuse.cc , etc; but missing in barclass.cc , cconf.cc , cls_acl.cc and in others. Second is that you link with OpenSSL when your license is (L)GPL. See their FAQ[3] and the fact that I can't find any upstream license file permitting that nor it's mentioned in debian/copyright . Also you may see the debian/copyright of my packages, like neon27[4]: it has a pointer to the full license file under /usr/share/common-licenses/ . On the other hand, it went into Ubuntu without any problems. Clint, Noèl? Feel free to post comment on what needs to be done with ceph packaging to be accepted on the first round. Regards, Laszlo/GCS [1] http://ftp-master.debian.org/new.html [2] http://ftp-master.debian.org/REJECT-FAQ.html [3] http://www.openssl.org/support/faq.html#LEGAL2 [4] http://packages.debian.org/changelogs/pool/main/n/neon27/current/copyright signature.asc Description: This is a digitally signed message part
Bug#506040: Status of ceph ITP?
On Thu, 2 Dec 2010, Laszlo Boszormenyi wrote: Hi Sage, On Wed, 2010-12-01 at 10:15 -0800, Sage Weil wrote: Can you take a look at the 'testing' branch in git commit 5bdae2af? That's how I've been doing releases, more or less. Assuming packaging issues are sorted out prior to that point, that's all that should be needed, right? I think I've noted that cephfs and radosacl are without manpages. Please write one for them. Do you have an upstream changelog somewhere? ChangeLog is still empty. Really minor that I write 'new upstream release' to debian/changelog . Otherwise it's OK for uploading. I'm wondering if it's even worth generating a ChangeLog. Maybe only for the release tarball? It's all in git. I guess we can just put the old debian/changelog at ChangeLog and continue summarizing the main items... (BTW, the v0.23.2 bugfix release is mostly pointless as v0.24 is just a couple days away anyway. Just for the sake of illustration...) There's no chance that ceph will be included in Squeeze and the next release of Ubuntu is several months away. You have time and it's your decision when should I first upload ceph. Please note that Debian is in freeze ATM, it may need even two weeks to be accepted to the archive[1]; and even if it's in the NEW queue, I can upload new versions into it. Okay. I'd mainly like to get the packaging issues sorted out so that it's just a matter of updating on each release, and so that sid users can get it. I'm not an ftp-master, but your package maybe rejected[2] for two reasons. I think only debian/copyright is not enough, all source files should have a comment header about their license in short. You have it in cephfs.cc , cfuse.cc , etc; but missing in barclass.cc , cconf.cc , cls_acl.cc and in others. Any chance you want to submit a patch? Unless otherwise noted, everything is LGPL2 and copyright whatever git log tells you. Second is that you link with OpenSSL when your license is (L)GPL. See their FAQ[3] and the fact that I can't find any upstream license file permitting that nor it's mentioned in debian/copyright . Also you may see the debian/copyright of my packages, like neon27[4]: it has a pointer to the full license file under /usr/share/common-licenses/ . On the other hand, it went into Ubuntu without any problems. Clint, Noèl? Feel free to post comment on what needs to be done with ceph packaging to be accepted on the first round. Hmm, yeah, that may be an issue here. See [1] and [2]. Maybe we should look at using gnutls instead of openssl. sage [1] http://lists.debian.org/debian-legal/2002/11/msg00253.html [2] http://www.mail-archive.com/debian-le...@lists.debian.org/msg14110.html
Bug#506040: Status of ceph ITP?
On Thu, 2010-12-02 at 01:30 +0100, Laszlo Boszormenyi wrote: I'm not an ftp-master, but your package maybe rejected[2] for two reasons. I think only debian/copyright is not enough, all source files should have a comment header about their license in short. You have it I don't see where this is a hard requirement in the reject faq. Essentially, as long as the files don't have a license that conflicts with COPYING, then there's no need for a license header. I DO think its a good idea to have a Copyright header in every file, but thats also probably ok to have in an AUTHORS file or something like that. in cephfs.cc , cfuse.cc , etc; but missing in barclass.cc , cconf.cc , cls_acl.cc and in others. Second is that you link with OpenSSL when your license is (L)GPL. See their FAQ[3] and the fact that I can't find any upstream license file permitting that nor it's mentioned in debian/copyright . Also you may see the debian/copyright of my packages, like neon27[4]: it has a pointer to the full license file under /usr/share/common-licenses/ . On the other hand, it went into Ubuntu without any problems. Clint, Noèl? Feel free to post comment on what needs to be done with ceph packaging to be accepted on the first round. Laszlo, I did a thorough review of the licensing before working to get ceph uploaded to Ubuntu, but I wasn't aware of the incompatibility between the GPL/LGPL and OpenSSL. This page details it pretty well: http://people.gnome.org/~markmc/openssl-and-the-gpl.html Sage, I'd guess that you can work on getting an OK from the other authors on adding an exception. I've opened a bug against CEPH in ubuntu here: https://bugs.launchpad.net/ubuntu/+source/ceph/+bug/684011 Sage, if you can please update that bug's status when you have secured an exception, that would be ideal, as I'm going to mark it as Critical, so we'll probably have to drop ceph from Natty if there's no resolution before the release, and consider dropping it from Maverick as well. Also Sage, if the other authors (or you) are not comfortable with the OpenSSL advertising clause, there's always GNUTLS which exists in large part to address this sort of thing. -- 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/1291274357.20409.171.ca...@clint-macbookpro
Bug#506040: Status of ceph ITP?
Hey Laszlo, These changes are great! I incorporated all of your changes into ceph.git, and also fixed up the ceph.spec.in to include the missed gui files. I've changed the way debug parts of the packages are handled. It may sound harsh and so I'm open to revert that back to your way. Yay, the old way was definitely a hack. Sage: may you let me handle the packaging for Debian and Ubuntu? So you can find more time working on ceph itself as it has some inconsistency as well. Binaries without manpages like cephfs and radosacl ; somewhere the manpage contains an example which is not a valid command (at least in v0.23 , it passed midnight and now I can't remember which one is it). Whatever you think would work best. I would like to keep the debian/ files in some form or another (although whether they live in ceph.git is an open question) since I build packages for sid, squeeze, and lenny for the ceph.newdream.net site, and would like to do so immediately when a release is made. But if you can handle the packaging changes and uploading to debian that would (continue to be) helpful. Or if the packaging stuff is managed by you separately, but still available somewhere for me pull and build my packages against. What do you suggest? Are you sure that ceph should depend on hdparm? What if my box has SCSI, SAS or other disk that isn't [sP]ATA? Yes, there's sdparm, but do you use it directly from ceph? Should it be a recommendation instead? Currently it's only used by os/FileJournal.cc to check for a journal on a block device with write caching off. This is only a problem for kernels prior to 2.6.33 (which unfortunately includes squeeze!), so I'm inclined to keep it for now. In any case, though, the code fails gracefully if it's not found, so a recommendation would work. And yeah, it doesn't try sdparm if hdparm doesn't do the trick. But it catches most administrator error as is, which is the goal. If others agree, I'll upload it in some days. It'll sit into the NEW queue and may take a while to be officially accepted. Great! There are a handful of bug fixes I'd like to roll into v0.23.2 first, if it isn't too much trouble. I can do that today. Clint, do you see any remaining issues I should fix first? Thanks! sage -- 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/pine.lnx.4.64.1011300922530.30...@cobra.newdream.net
Bug#506040: Status of ceph ITP?
Hi Sage, On Tue, 2010-11-30 at 10:21 -0800, Sage Weil wrote: Sage: may you let me handle the packaging for Debian and Ubuntu? [...] Whatever you think would work best. I would like to keep the debian/ files in some form or another (although whether they live in ceph.git is an open question) since I build packages for sid, squeeze, and lenny for the ceph.newdream.net site, and would like to do so immediately when a release is made. But if you can handle the packaging changes and uploading to debian that would (continue to be) helpful. Or if the packaging stuff is managed by you separately, but still available somewhere for me pull and build my packages against. What do you suggest? It's not an easy situation as its packaging goes on three way. First is yours, to make it up-to-date quickly as new release happens. The other two is for Debian and Ubuntu. Divergency will be minimum, expect debian/changelog I think. Still it would be good to use quilt format for packaging[1]. On the other hand, do you really need so fast package release cycles? Usually I'm fast and active, still you'll lose at least a day or two waiting on me for release an updated package. I don't know Clint, but he seems to be active as well. Also I may apply for a per-package Ubuntu upload rights which means I can upload the package simultaneously to Debian and Ubuntu. This would help users in two ways: they don't need to look for and setup an external package pool (Debian and Ubuntu already have a backports archive) and ceph would be consistent on all archs (backports have autobuild on all archs, including but not limited to alpha, mips, sparc, s390). Only one question remains, if we go three way packaging, how should we version our package versions? Yours should have a priority, but official backports from me and Clint should override it. I propose that your version number should be upstream_version-[123...] and ours should be upstream_version-[123...][lenny|squeeze|maverick][123...]. Clint? [ about hdparm dependency ] Currently it's only used by os/FileJournal.cc to check for a journal on a block device with write caching off. Would it be hard to get this info by yourself somehow? Please note that I'm not a security expert, but as I see you create your temp file in a very deterministic way. What if I'm evil and I make a symlink named as your soon-to-be tempfile to a system binary / file? Of course I see that you test for root (euid == 0) and if not, you don't run hdparm. It's not a set[ug]id binary (I mean ceph), so we are safe as normal user really can't start it. This is only a problem for kernels prior to 2.6.33 (which unfortunately includes squeeze!), so I'm inclined to keep it for now. [...] OK, it can remain as a dependency for user safety. Great! There are a handful of bug fixes I'd like to roll into v0.23.2 first, if it isn't too much trouble. I can do that today. We can wait for the release to be safe. Some more days to upload it doesn't make the world. Clint, do you see any remaining issues I should fix first? He prompted for checking upgrades of previous ceph versions to this one on Ubuntu Maverick. Don't know how it goes, today I'll check it myself as well. Regards, Laszlo/GCS [1] http://raphaelhertzog.com/2010/10/21/the-secret-plan-behind-the-3-0-quilt-debian-source-package-format/ -- 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/1291180845.14018.537.ca...@julia.gcs.org.hu
Bug#506040: Status of ceph ITP?
Hi Clint, On Mon, 22 Nov 2010, Clint Byrum wrote: Yes we'd much rather have a single package that works in both Debian and Ubuntu. If you know exactly what package is being looked at for upload into Debian, I can at least start with that so that the merge when it finally does get uploaded is much simpler. The current latest is at http://ceph.newdream.net/debian/pool/ceph-stable/c/ceph/ceph_0.23.1-1.dsc As I understand it, the current issues are: - whitespace in debian/rules - something with the .install files and installing into the source tree that I didn't understand.. can you clarify Laszlo? Thanks! sage -- 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/pine.lnx.4.64.1011291120510.4...@cobra.newdream.net
Bug#506040: Status of ceph ITP?
Hi all, On Mon, 2010-11-29 at 11:24 -0800, Sage Weil wrote: On Mon, 22 Nov 2010, Clint Byrum wrote: Yes we'd much rather have a single package that works in both Debian and Ubuntu. That would be an important goal. Feel free to contact me if you need any changes to be more suitable for Ubuntu. If you know exactly what package is being looked at for upload into Debian, I can at least start with that so that the merge when it finally does get uploaded is much simpler. You can get the modified package from my site[1]. I don't say it's ready, but fixes most of the problems that Sage made. As I understand it, the current issues are: - whitespace in debian/rules Yes, there was some extra whitespace, an extra and missing blank lines in debian/rules . It's cosmetic only of course. - something with the .install files and installing into the source tree that I didn't understand.. can you clarify Laszlo? Sure. The biggest problem was that you installed everything to $(CURDIR) , which is the source tree. Then you used dh_install to move out the files from there. make install was a bit nonsense this way, as the compiled binaries was already in the source tree; there was no need to install them the same place. I've changed it to the more common $(DESTDIR) which is debian/tmp/ . This way you can use --list-missing or the more aggressive --fail-missing to dh_install to see if you miss files. Yes, you do missed files. One is the radosacl binary, that I put into the radosgw package. You neither installed usr/share/ceph_tool/gui_resources/ (SVG and glade files) that went into the ceph package. Your cleaning process missed several points like the missing removal of src/.deps/ and some generated files. There are more you can find. I've changed the way debug parts of the packages are handled. It may sound harsh and so I'm open to revert that back to your way. Less important mistakes that debian/changes is for packaging changes, for upstream changes you can use ChangeLog ; it can be installed with dh_installdocs . Also implicitly noted that this is a first generation package (not converted to quilt as Sage said it should build on Lenny as well). Sage: may you let me handle the packaging for Debian and Ubuntu? So you can find more time working on ceph itself as it has some inconsistency as well. Binaries without manpages like cephfs and radosacl ; somewhere the manpage contains an example which is not a valid command (at least in v0.23 , it passed midnight and now I can't remember which one is it). Are you sure that ceph should depend on hdparm? What if my box has SCSI, SAS or other disk that isn't [sP]ATA? Yes, there's sdparm, but do you use it directly from ceph? Should it be a recommendation instead? Also uniformed *.install files, don't start them with a slash. Added a watch file and specific fields to debian/control . If others agree, I'll upload it in some days. It'll sit into the NEW queue and may take a while to be officially accepted. Regards, Laszlo/GCS [1] dget http://www.routers.hu/gcs/ceph_0.23.1-1.dsc -- 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/1291075213.14018.101.ca...@julia.gcs.org.hu
Bug#506040: Status of ceph ITP?
On Tue, 2010-11-30 at 01:00 +0100, Laszlo Boszormenyi wrote: Hi all, On Mon, 2010-11-29 at 11:24 -0800, Sage Weil wrote: On Mon, 22 Nov 2010, Clint Byrum wrote: Yes we'd much rather have a single package that works in both Debian and Ubuntu. That would be an important goal. Feel free to contact me if you need any changes to be more suitable for Ubuntu. If you know exactly what package is being looked at for upload into Debian, I can at least start with that so that the merge when it finally does get uploaded is much simpler. You can get the modified package from my site[1]. I don't say it's ready, but fixes most of the problems that Sage made. Laszlo, great work so far really. I'll have an in depth look at the package and see how it performs on upgrade from the one we have in Maverick. -- 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/1291077278.2879.67.ca...@clint-macbookpro
Bug#506040: Status of ceph ITP?
On Sun, 2010-11-21 at 15:26 -0800, Sage Weil wrote: Hi Clint, On Sun, 21 Nov 2010, Clint Byrum wrote: Hi guys, I'm about to start working on merging 0.23 into Ubuntu, and I'm just wondering if there has been any progress on adding CEPH to debian before I do so. Whoops, I thought it was uploaded a month or so ago, but checking now it looks like it wasn't. Laszlo was most recently going to do it, but if he doesn't have the bandwidth Noel also offered to. I'm assuming it's simpler to base the ubuntu package off what's in debian? I'd hold off a day or two for that. Yes we'd much rather have a single package that works in both Debian and Ubuntu. If you know exactly what package is being looked at for upload into Debian, I can at least start with that so that the merge when it finally does get uploaded is much simpler. -- 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/1290436452.9821.5.ca...@clint-macbookpro
Bug#506040: Status of ceph ITP?
Hi guys, I'm about to start working on merging 0.23 into Ubuntu, and I'm just wondering if there has been any progress on adding CEPH to debian before I do so. Thanks! -- 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/1290365977.9821.3.ca...@clint-macbookpro
Bug#506040: Status of ceph ITP?
Hi Clint, On Sun, 21 Nov 2010, Clint Byrum wrote: Hi guys, I'm about to start working on merging 0.23 into Ubuntu, and I'm just wondering if there has been any progress on adding CEPH to debian before I do so. Whoops, I thought it was uploaded a month or so ago, but checking now it looks like it wasn't. Laszlo was most recently going to do it, but if he doesn't have the bandwidth Noel also offered to. I'm assuming it's simpler to base the ubuntu package off what's in debian? I'd hold off a day or two for that. Thanks! sage -- 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/pine.lnx.4.64.1011211521510.17...@cobra.newdream.net
