On 01/31/2012 04:16 PM, Andreas Tille wrote:
[KSB3] Thanks for the encouragement, Andreas, and thanks for all your efforts. Really. We would not be here without your encouragement over the years.On Tue, Jan 31, 2012 at 01:40:22PM -0500, Bhaskar, K.S wrote:I can not imagine that finding a way to create a "small number" (can you give exact numbers please) should be that hard. For instance if you take the effort I took to dive from scratch into Java packaging to build packages for several prerequisites of target programs to make them finally distributable in main this was more than creating "some files" by other means than they are usually created.[KSB2] It's not hard, but since everything is produced by heavily automated scripting, someone would have to do a small audit. Not hard, but we are trying to freeze the code for a major release.Well, there would always be an excuse because of some certain release status. I was told that Debian packaging would be important for GT.M and there is a community of about 3000 developers. Could any of them please give this a try? You say "not hard" + "small audit" this does not sound like it would occupy an interested developer in a way to be considered a showstoper in a release cycle. Perhaps you take it this way: I constantly try to release some certain packages and even though I try to spend a mentionable amount of my available time in helping others and specifically helping Luis to enable him working on the packaging which we can not do on our own for instance we have no idea how to do such "small audits". I have no idea whether Luis is deep enough in the GT.M issues to know how to do the "not hard" work but if someone from GT.M would provide him the needed information this would really prove your interest to come foreward here.
[KSB2] Yes, as human readable source code - even if generated by a script from a text file - it should be DFSG free. But the devil's advocate argument is that even if it is human readable C code, since it is generated from a text file, is is not source code. But if that works for getting GT.M into the package, lets do it.Ftpmaster is not a devil so we will not be confronted with these arguments. So I'm in all favour of doing this.However, those files are not part of the upstream source tarball, so to get the files today, you have to build GT.M once. Once you build GT.M once, the files are there and the bootstrap is accomplished.I try to rephrase my suggestion. 1. Download a GT.M source distribution as orig.tar.gz 2. Download the missing but needed autogenerated C files and add them as patch set (with dpkg source format 3.0 you can even have two source tarballs, but that's a detail) Build the package from the files exclusively without needing a running GT.M.
[KSB3] It could work with a slight difference.
Once we get the release out, I'll see about releasing an updated source tarball with the generated files. But that is a few weeks out at best.I do not know whether you follow a date based release cycle. In Debian terms like "a few weeks" frequently turn out to be "a few monthes". If this might happen with GT.M we will miss the freeze for the next Debian stable release which will in turn mean another two years no GT.M in Debian. On the other hand if we follow the plan I layed out above with *any* currently available GT.M release we have a fair chance to build your upcoming release with an at this time in Debian existing fis-gtm package and by good coincidence your new release will end up in the next Debian stable release. According to my experience this is the *only* fair chance to get GT.M into Debian in a reasonable time frame. So if you or some other GT.M developer would put the needed files next to the source tarball in the download area I could try to follow together with Luis the new strategy. This will take us long enough - so please pretty please give us the code we need to start working instead of spending time in discussing.
[KSB3] In theory we are date driven, like Ubuntu rather than criteria driven like Debian. In practice, since we have release gating criteria without which we will not release GT.M (because of the applications that use it) releases are a hybrid. We have a code freeze scheduled for this Friday, February 3 and a release for mid February. I think the odds are better than 50% that we will make it, and the odds are close to 90% of freezing by February 10.
I will see what I can do about providing the additional C files before the release, but no promises.
Kind regards Andreas.
-- GT.M - Rock solid. Lightning fast. Secure. No compromises.
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.