Bug#501151: Preparing packaging for ocfs2-tools 1.4.1-1
Hi! I already ha d deep look at the current packaging included in upstream git, basically the initscripts need to be rewritten as they are full of redhadisms, but thats'it basically. I think the debconf templates and the corresponding configuration parts in the maintainer scripts should be removed for Lenny, because I doubt we would get this into testing in time, lacking all translations. It's broken anyway, and I currently have no time to fix that due to RL work overload. To your question, Alioth seems fine to me, but why not use oracle git, and make it a native package? Best regards Frederik Schüler On Friday 21 November 2008 08:38:02 Jeremy Lainé wrote: Frederik, Joel, I have started putting together the packaging for ocfs2-tools here: https://svn.jerryweb.org/public/packages/ocfs2-tools/ What would you think of applying for some space on alioth so that we can maintain ocfs2-tools collaboratively and finally upload a recent version of ocfs2-tools? Cheers, Jeremy -- ENOSIG signature.asc Description: This is a digitally signed message part.
Bug#501151: Preparing packaging for ocfs2-tools 1.4.1-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi! I already ha d deep look at the current packaging included in upstream git, basically the initscripts need to be rewritten as they are full of redhadisms, but thats'it basically. As far as I can tell, the packaging in upstream git (and upstream tarballs) is a not-quite-up-to-date copy of the Ubuntu packaging for ocfs2-tools 1.3.9. I disagree about rewriting the initscripts, until now the init scripts shipped with Debian have always been based on upstream with some minor Debian patches, and upstream has integrated all these patches. As time is short for lenny I'd rather stick to well-tested upstream init scripts. I think the debconf templates and the corresponding configuration parts in the maintainer scripts should be removed for Lenny, because I doubt we would get this into testing in time, lacking all translations. It's broken anyway, and I currently have no time to fix that due to RL work overload. In the Ubuntu packaging, the changes that were made were simply to update the default values for timeouts. I have manually integrated these changes into all of Debian's translations, so there should not be any translation issue. Are there any additional changes to your knowledge? To your question, Alioth seems fine to me, but why not use oracle git, and make it a native package? I'd rather go the opposite way: ask upstream to drop the packaging in their git which is not quite up to date, and encourage them (and Ubuntu maintainers) to contribute to the packaging on alioth. Is there some cluster-related project on Alioth we can tack onto or should I ask for a new project? Cheers, Jeremy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkmehcACgkQ4mJJZqJp2Sc5cQCeMvUAN88oBJSB0ade73pcuYBJ Y4wAoKUVly1es2mDzbPOL2yLGzT9jqZH =IJyT -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#501151: Preparing packaging for ocfs2-tools 1.4.1-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 What would you think of applying for some space on alioth so that we can maintain ocfs2-tools collaboratively and finally upload a recent version of ocfs2-tools? I have moved the packaging to the collab-maint Subversion repository: http://svn.debian.org/viewsvn/collab-maint/deb-maint/ocfs2-tools/trunk/ I pruned the debian directory from the upstream tarball to make packaging cleaner and have uploaded ocfs2-tools 1.4.1-1 to unstable. It will probably sit in the NEW queue for a bit due to the addition of ocfs2-tools-dev. Frederik, you are listed in the Uploaders, so we're all set up for collaborative maintenance. What do you think about asking for this version to be allowed to migrate to lenny? Cheers, Jeremy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkm7UYACgkQ4mJJZqJp2SfKMgCeNBW47ditlqmE6vvmUXk71BzF wzcAoJhrA5sBy9pKU5zwqlLOI/Kzw4on =qKfc -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#501151: Preparing packaging for ocfs2-tools 1.4.1-1
On Fri, Nov 21, 2008 at 09:35:13AM +0100, Frederik Schüler wrote: Hi! I already ha d deep look at the current packaging included in upstream git, basically the initscripts need to be rewritten as they are full of redhadisms, but thats'it basically. Um, they use lsb bits, because they are portable scripts. If you can find something that fails on Debian, send me a note or a patch. Joel -- Viro's Razor: Any race condition, no matter how unlikely, will occur just often enough to bite you. Joel Becker Principal Software Developer Oracle E-mail: [EMAIL PROTECTED] Phone: (650) 506-8127 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#501151: Preparing packaging for ocfs2-tools 1.4.1-1
On Fri, Nov 21, 2008 at 08:38:02AM +0100, Jeremy Lainé wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frederik, Joel, I have started putting together the packaging for ocfs2-tools here: https://svn.jerryweb.org/public/packages/ocfs2-tools/ FYI, iceweasel reports: -- Secure Connection Failed svn.jerryweb.org uses an invalid security certificate. The certificate is not trusted because the issuer certificate is unknown. (Error code: sec_error_unknown_issuer) -- Hmm, I added a temporary exception, and now I just get a 404. What would you think of applying for some space on alioth so that we can maintain ocfs2-tools collaboratively and finally upload a recent version of ocfs2-tools? I don't know why maintaining it upstream is a problem - I'll happily take patches. The nice part about upstream maintenance is that one can build a package from the source without having to navigate other places. That doesn't matter for release packaging, but it does if I want to build packages while developing. Joel -- Up and down that road in our worn out shoes, Talking bout good things and singing the blues. Joel Becker Principal Software Developer Oracle E-mail: [EMAIL PROTECTED] Phone: (650) 506-8127 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#501151: Preparing packaging for ocfs2-tools 1.4.1-1
On Fri, Nov 21, 2008 at 06:17:58PM +0100, Jeremy Lainé wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 What would you think of applying for some space on alioth so that we can maintain ocfs2-tools collaboratively and finally upload a recent version of ocfs2-tools? I have moved the packaging to the collab-maint Subversion repository: http://svn.debian.org/viewsvn/collab-maint/deb-maint/ocfs2-tools/trunk/ I pruned the debian directory from the upstream tarball to make packaging cleaner and have uploaded ocfs2-tools 1.4.1-1 to unstable. It will probably sit in the NEW queue for a bit due to the addition of ocfs2-tools-dev. Still don't know why an upstream debian/ tree is so frowned upon. I will say, I really like what /usr/share/cdbs does for debian/rules. Joel -- Vote early and vote often. - Al Capone Joel Becker Principal Software Developer Oracle E-mail: [EMAIL PROTECTED] Phone: (650) 506-8127 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#501151: Preparing packaging for ocfs2-tools 1.4.1-1
On Fri, Nov 21, 2008 at 10:06:32AM +0100, Jeremy Lainé wrote: I already ha d deep look at the current packaging included in upstream git, basically the initscripts need to be rewritten as they are full of redhadisms, but thats'it basically. As far as I can tell, the packaging in upstream git (and upstream tarballs) is a not-quite-up-to-date copy of the Ubuntu packaging for ocfs2-tools 1.3.9. I disagree about rewriting the initscripts, until now the init scripts shipped with Debian have always been based on upstream with some minor Debian patches, and upstream has integrated all these patches. As time is short for lenny I'd rather stick to well-tested upstream init scripts. Again, let me know if anything doesn't work. To your question, Alioth seems fine to me, but why not use oracle git, and make it a native package? I'd rather go the opposite way: ask upstream to drop the packaging in their git which is not quite up to date, and encourage them (and Ubuntu maintainers) to contribute to the packaging on alioth. Is there some cluster-related project on Alioth we can tack onto or should I ask for a new project? Why can't we just make our packaging up to date? Regarding Alioth, what do we gain? git is a distributed system, so it's plenty collaborative. Joel -- A good programming language should have features that make the kind of people who use the phrase software engineering shake their heads disapprovingly. - Paul Graham Joel Becker Principal Software Developer Oracle E-mail: [EMAIL PROTECTED] Phone: (650) 506-8127 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#501151: Preparing packaging for ocfs2-tools 1.4.1-1
Hi! no, please, no way for cdbs. Best regards Frederik Schüler On Friday 21 November 2008 22:31:53 Joel Becker wrote: On Fri, Nov 21, 2008 at 06:17:58PM +0100, Jeremy Lainé wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 What would you think of applying for some space on alioth so that we can maintain ocfs2-tools collaboratively and finally upload a recent version of ocfs2-tools? I have moved the packaging to the collab-maint Subversion repository: http://svn.debian.org/viewsvn/collab-maint/deb-maint/ocfs2-tools/trunk/ I pruned the debian directory from the upstream tarball to make packaging cleaner and have uploaded ocfs2-tools 1.4.1-1 to unstable. It will probably sit in the NEW queue for a bit due to the addition of ocfs2-tools-dev. Still don't know why an upstream debian/ tree is so frowned upon. I will say, I really like what /usr/share/cdbs does for debian/rules. Joel -- Vote early and vote often. - Al Capone Joel Becker Principal Software Developer Oracle E-mail: [EMAIL PROTECTED] Phone: (650) 506-8127 -- ENOSIG signature.asc Description: This is a digitally signed message part.
Bug#501151: Preparing packaging for ocfs2-tools 1.4.1-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Joel! Still don't know why an upstream debian/ tree is so frowned upon. I have no problem with upstream working on debian/ or even on with packaging being hosted upstream, I went with alioth for the sake of expediency. If you want to collaborate you can apply for access to the collab-maint on alioth.debian.org, or we can re-discuss hosting options - no problem. I *do* have a problem with debian/ being included in release tarballs though, it makes for messy .diff.gz if for instance files get dropped or moved around from packaging between revision 1.4.1-1 and 1.4.1-2. Also, at times there are minor differences between Ubuntu / Debian packages, and it's a shame to have to carry that around in the .diffs. Slightly off topic, Joel you might want to take a peek at svn-buildpackage (and/or git-buildpackage) if you're not familiar with them yet, they make slapping the packaging onto upstream code (and tagging package releases) a breeze. I will say, I really like what /usr/share/cdbs does for debian/rules. I'm pretty fond of CDBS, but I know it's not universally loved. :) Cheers, Jeremy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkknK6wACgkQ4mJJZqJp2Sd0jACgj4SXf6dYmk/qbyptj96wKZb+ K0AAoJ0c6jHE4R8wY6So2KJMSitgvOME =o/8u -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#501151: Preparing packaging for ocfs2-tools 1.4.1-1
On Fri, Nov 21, 2008 at 10:44:12PM +0100, Jeremy Lainé wrote: I *do* have a problem with debian/ being included in release tarballs though, it makes for messy .diff.gz if for instance files get dropped or moved around from packaging between revision 1.4.1-1 and 1.4.1-2. Also, at times there are minor differences between Ubuntu / Debian packages, and it's a shame to have to carry that around in the .diffs. I'm not sure why there are messy .diffs if we've got the master debian/. Are you saying that you want to tweak a problem with the 1.4.1 debian/ directory, and you're stuck with the 1.4.1 tarball as released even if we have the fix in the upstream source? Slightly off topic, Joel you might want to take a peek at svn-buildpackage (and/or git-buildpackage) if you're not familiar with them yet, they make slapping the packaging onto upstream code (and tagging package releases) a breeze. I will. Thanks. I will say, I really like what /usr/share/cdbs does for debian/rules. I'm pretty fond of CDBS, but I know it's not universally loved. :) Well, I haven't looked at the actual include hunks. But the debian/rules you provided looks pretty clean. I see that fs doesn't like it so much. Joel -- It is not the function of our government to keep the citizen from falling into error; it is the function of the citizen to keep the government from falling into error. - Robert H. Jackson Joel Becker Principal Software Developer Oracle E-mail: [EMAIL PROTECTED] Phone: (650) 506-8127 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#501151: Preparing packaging for ocfs2-tools 1.4.1-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frederik, Joel, I have started putting together the packaging for ocfs2-tools here: https://svn.jerryweb.org/public/packages/ocfs2-tools/ What would you think of applying for some space on alioth so that we can maintain ocfs2-tools collaboratively and finally upload a recent version of ocfs2-tools? Cheers, Jeremy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkmZVoACgkQ4mJJZqJp2Se/tACffFdlJQ+gIhVuX1q/ztuLSP0Y /NgAoMpRSXywkX+p7DkOf65e36nQhKcH =KhPU -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
