unsubscribe
__ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: How to not collaborate with Debian (and upstream)
On Thursday 28 August 2008 16:43, Mathias Gug wrote: > Hi, > > On Thu, Aug 28, 2008 at 10:14:06AM +0200, Lucas Nussbaum wrote: > > Besides the minor packaging strangeness in Neil's version (change of > > packaging system, use of a git snapshot without saying it, copyright > > problems, etc), > > Agreed. There are some packaging mistakes. > > > the root problem is the hack around update-alternatives > > to remove the possibility for rubygems to overwrite binaries when > > several versions of the same gem are installed (possibly for different > > versions of ruby). > > > > * I don't think that this problem is grave enough to warrant maintaining > > a long term divergence with upstream in Debian/Ubuntu. > > > > * When discussed with upstream, they suggested a different solution > > (warn the user when rubygems is going to overwrite a binary). > > The upload tries to address one specific issue raised in bug 145267 [1]: > > Providing binaries shipped by gems on the default path. > > In hardy, the end user using a gem (let's say the rails gem) would > have to do the following things: > > 1. sudo apt-get install rubygems > 2. sudo gem install rails > 3. Modify the default PATH in the environment to include > /var/lib/gems/1.X/bin/ so that the rails command can be invoked from the > command line. > > The upload aims at removing step number 3 from the process by symlinking > the gem binary from /var/lib/gems/1.X/bin/ into /usr/local/bin/. This is > accomplished by hooking calls to update-alternatives in the post-install > phase of a gem. These hooks were added by the upstream developers in > order to be able to do exactly that kind of things. Thus the reason to > use an upstream snapshot. However labling it an RC version when it's a snapshot is fundamentally deceptive, wrong, and not at all Ubuntu. > And that's all what the upload is trying to solve. Other concerns raised > in this thread and other threads are valid - there were valid before the > upload and are still valid after the upload. It's one step toward > improving the end-user experience of rubygems in the next version of > Ubuntu. > > [1]: https://bugs.launchpad.net/ubuntu/+source/libgems-ruby/+bug/145267 Apparently all the concerns about this raised by numerous Ubuntu developers are irrelevent then? https://bugs.launchpad.net/bugs/262063 It may 'solve' that problem but it raises much more sever possiblities. Scott K -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: How to not collaborate with Debian (and upstream)
Hi, On Thu, Aug 28, 2008 at 10:14:06AM +0200, Lucas Nussbaum wrote: > Besides the minor packaging strangeness in Neil's version (change of > packaging system, use of a git snapshot without saying it, copyright > problems, etc), Agreed. There are some packaging mistakes. > the root problem is the hack around update-alternatives > to remove the possibility for rubygems to overwrite binaries when > several versions of the same gem are installed (possibly for different > versions of ruby). > > * I don't think that this problem is grave enough to warrant maintaining > a long term divergence with upstream in Debian/Ubuntu. > > * When discussed with upstream, they suggested a different solution > (warn the user when rubygems is going to overwrite a binary). > The upload tries to address one specific issue raised in bug 145267 [1]: Providing binaries shipped by gems on the default path. In hardy, the end user using a gem (let's say the rails gem) would have to do the following things: 1. sudo apt-get install rubygems 2. sudo gem install rails 3. Modify the default PATH in the environment to include /var/lib/gems/1.X/bin/ so that the rails command can be invoked from the command line. The upload aims at removing step number 3 from the process by symlinking the gem binary from /var/lib/gems/1.X/bin/ into /usr/local/bin/. This is accomplished by hooking calls to update-alternatives in the post-install phase of a gem. These hooks were added by the upstream developers in order to be able to do exactly that kind of things. Thus the reason to use an upstream snapshot. And that's all what the upload is trying to solve. Other concerns raised in this thread and other threads are valid - there were valid before the upload and are still valid after the upload. It's one step toward improving the end-user experience of rubygems in the next version of Ubuntu. [1]: https://bugs.launchpad.net/ubuntu/+source/libgems-ruby/+bug/145267 -- Mathias Gug Ubuntu Developer http://www.ubuntu.com signature.asc Description: Digital signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: I cannot continue with Ubuntu development using LP
On Thursday 28 August 2008 04:32, Michael Casadevall wrote: ... > As for OpenID, if your using noscript with firefox, it will interfere > with the login (its a bug in Launchpad's OpenID server, since, to my > knowledge, openid works on other sites). The recent OpenID change broke compatibliity with Konqueror, so for KDE users, many of us now are required to use a non-standard browser for w.u.c edits. See https://bugs.launchpad.net/bugs/259436 for details. Scott K -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Request for guidance from motu-release
Hi, first off: sorry, there will detailed instructions for universe FFe's soonish (I guess I won't come around to this until Friday, maybe someone else from motu-release is faster though ;)). On Thursday 28 August 2008 15:15:25 Reinhard Tartler wrote: > Michael Haas <[EMAIL PROTECTED]> writes: > > Last cycle, some people had special FFe powers to take care of their > > distributions e.g. Mario Limonciello for Mythbuntu. Can we have that > > again for this release? I'm all for it :). > > We had a standing freeze exception for some selected packages, which > included wine and fai. I guess the best approach to request a standing FFe is to write to the ubuntu-motu list, stating the reason why this is requested. (e.g. upstream releasing a well-tested stable version somewhen during FF is a good reason). > > > I didn't manage to merge and test fai. I do have an untested preliminary > merge ready, but I want to take my time to test it properly. I therefore > ask for such a standing freeze exception for the 'fai' package so that I > don't have to upload a premature and untested package in intrepid. Ahem, this doesn't sound like a very convincing reason for a standing FFe though. As we've just started with FF, I doubt that a normal FFe will be rejected for your merge. Or are there other reasons for a standing FFe? (side note: a premature package should never be uploaded, regardless if we're in FF or not). Cheers, Stefan. signature.asc Description: This is a digitally signed message part. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Request for guidance from motu-release
Michael Haas <[EMAIL PROTECTED]> writes: > Last cycle, some people had special FFe powers to take care of their > distributions e.g. Mario Limonciello for Mythbuntu. Can we have that > again for this release? We had a standing freeze exception for some selected packages, which included wine and fai. I didn't manage to merge and test fai. I do have an untested preliminary merge ready, but I want to take my time to test it properly. I therefore ask for such a standing freeze exception for the 'fai' package so that I don't have to upload a premature and untested package in intrepid. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Request for guidance from motu-release
James Westby schrieb: > Hi motu-release, > > First of all, thanks for the difficult job that you are about to > undertake. > > I would appreciate a statement from the team about the freeze > now that it is in effect. We have general freeze exception > guidelines > > https://wiki.ubuntu.com/FreezeExceptionProcess > > but I would be interested in what your approach would be for this > cycle. What extra policies will you be applying? What do you > expect of contributors? Is there anything that you think should > people should focus on? > Last cycle, some people had special FFe powers to take care of their distributions e.g. Mario Limonciello for Mythbuntu. Can we have that again for this release? -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
please don't make changes to libgems-ruby for the moment (was Re: How to not collaborate with Debian (and upstream))
Hi, On Thursday 28 August 2008 02:33:52 Scott Kitterman wrote: [..] > > I've filed Bug #262063. One clear solution would be to simply revert this > change. [..] just to make it clear: motu-release is currently considering to revert this upload, so please don't touch libgems-ruby until we came to a decision. Thanks, Stefan - on behalf of motu-release. signature.asc Description: This is a digitally signed message part. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Request for guidance from motu-release
Hi motu-release, First of all, thanks for the difficult job that you are about to undertake. I would appreciate a statement from the team about the freeze now that it is in effect. We have general freeze exception guidelines https://wiki.ubuntu.com/FreezeExceptionProcess but I would be interested in what your approach would be for this cycle. What extra policies will you be applying? What do you expect of contributors? Is there anything that you think should people should focus on? I think we have a lot of new contributors since the last freeze, so some people won't have experience to fall back on, and an email explaining things has a different feel to a standing wiki page. Also, during a discussion about the rush to upload things, even when there are known problems, before the hardy feature freeze, and ways to avoid it, Stefan said: > I guess one measure is a gradual freeze policy, which starts out with a very > soft layer of thin ice at the beginning, and gets to an unbreakable barrier > at the end of the freeze. (I tried to apply this measure for this cycle, with > almost waiving through new packages at the beginning). Of course such a > policy must also be made well known (which didn't happen this cycle yet, > sorry for this). [1] Will a similar policy be followed this cycle? It's too late to make this policy well known pre-freeze, but it would still help people to decide what should be proposed for a freeze exception, helping them to work more effectively. Thanks, James [1] https://lists.ubuntu.com/archives/motu-council/2008-April/001002.html -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: I cannot continue with Ubuntu development using LP
I haven't seen any font changes in the past few days on LP; could you post a screenshot somewhere? As for OpenID, if your using noscript with firefox, it will interfere with the login (its a bug in Launchpad's OpenID server, since, to my knowledge, openid works on other sites). Michael On Thu, 2008-08-28 at 10:21 +0200, Cesare Tirabassi wrote: > The recent LP changes for the worst I can still cope with, the switch to > OpenID which stops me from being able to edit any wiki page anymore I can > still abide, but the recent change of font size is too much for me: > > https://bugs.launchpad.net/launchpad/+bug/262166 > > Please tell me that this is not LP faults and that there is a simple way to > solve this problem as this makes LP totally unusable for me. > Until this is (hopefully) solved, I will be unable to do any development > using > LP. > > Cesare > -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: How to not collaborate with Debian (and upstream)
Hi, First, Some background on Ruby/rubygems and Debian: In the past (before sarge), the controversial decision to split the ruby stdlib into several different packages was taken. This made the installation of non-packaged ruby apps very hard, and was very unpopular in the Ruby community. This was fixed a long time ago (maybe before sarge, surely before etch), but some people in the Ruby community still start shouting as soon as you mention Debian. Rubygems is a very problematic issue, and unfortunately, the Ruby community (esp. the part of the ruby community that does web apps) relies more and more on it (there are many applications and libs that are only distributed as gems). For more details, see Gunnar Wolf's talk at debconf.[1,2] [1] https://penta.debconf.org/dc8_schedule/events/241.en.html [2] http://meetings-archive.debian.net/pub/debian-meetings/2008/debconf8/low/630_Bringing_closer_Debian_and_Rails.ogg Also, the Ruby community tends to be quite bad at release management. Rails users often prefer to use the latest git snapshot for everything, even on production systems (that's probably why Neil decided to package a rubygems git snapshot). Ruby, Rubygems and Rails releases often break each other. All of this makes it very difficult to work on those issues. And clearly, we could use some help with talking with upstream to improve this. I've also had contacts with the openSUSE ruby maintainer, who shares exactly the same concerns. Now, on this particular issue, the discussion on the launchpad bug was clearly not the best example of well-behaved discussions between developers. From my POV, the claims that the Debian packaging "crippled" Rubygems, that I'm getting desparate, etc. clearly didn't help. I'm sorry that the whole discussion happened like that, and I would have preferred a more healthy discussion. Besides the minor packaging strangeness in Neil's version (change of packaging system, use of a git snapshot without saying it, copyright problems, etc), the root problem is the hack around update-alternatives to remove the possibility for rubygems to overwrite binaries when several versions of the same gem are installed (possibly for different versions of ruby). * I don't think that this problem is grave enough to warrant maintaining a long term divergence with upstream in Debian/Ubuntu. * When discussed with upstream, they suggested a different solution (warn the user when rubygems is going to overwrite a binary). Answers to various comments from the thread: On 27/08/08 at 20:35 -0400, Steven Harms wrote: > This sounds more like 'How not to encourage anyone to help at all'. > The tone of the comments in the bug are very confrontational when > clearly all these people wanted was a functional package. > > They saw a package that didn't work for *anyone* and wanted to change > it. They were not seasoned pro's, and I think this is just a > testimate to the lack of a obvious process. Rubygems, as packaged in Debian, is functional. Sure, some things are disabled, like the fact that rubygems can't update itself anymore. Or the fact that binaries from gems are installed in /usr/bin, possibly overwriting binaries from other packages. If you found serious issues with the package, please report them. But please stop the FUD. On 27/08/08 at 18:41 -0700, Steve Langasek wrote: > I don't think it's warranted to criticize people for finding > OS-specific solutions for problems in Ubuntu. We're not here to try > to solve all software problems for all distributions, we're here to > make *Ubuntu* the best OS it can be - and healthy collaboration with > upstream is an important part of that, but it's not the *only* thing. I agree. The problem here is that: * Rubygems' behaviour in Ubuntu will be different from upstream, and this divergence will have to be maintained. * This divergence, even documented, might be confusing for users (most users probably don't know about update-alternatives) * Nothing was done to try to find an upstream solution to this problem. In the past, the Debian Ruby maintainers decided to diverge from upstream by splitting stdlib into several packages. We got bitten very badly. It looks like the same mistake is being done here. -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | signature.asc Description: Digital signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
I cannot continue with Ubuntu development using LP
The recent LP changes for the worst I can still cope with, the switch to OpenID which stops me from being able to edit any wiki page anymore I can still abide, but the recent change of font size is too much for me: https://bugs.launchpad.net/launchpad/+bug/262166 Please tell me that this is not LP faults and that there is a simple way to solve this problem as this makes LP totally unusable for me. Until this is (hopefully) solved, I will be unable to do any development using LP. Cesare -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: How to not collaborate with Debian (and upstream)
Good Morning, On Wed, 2008-08-27 at 20:35 -0400, Steven Harms wrote: > This sounds more like 'How not to encourage anyone to help at all'. > The tone of the comments > in the bug are very confrontational when clearly all these people > wanted was a functional > package. > > They saw a package that didn't work for *anyone* and wanted to change > it. They were not > seasoned pro's, and I think this is just a testimate to the lack of a > obvious process. Well, I made this mistake with ruby1.9 in the past, and Lucas and I were discussing it, and somehow we came over that. The problem with a change inside this package, speak: "We changed something really serious, which has a "gem" in the name" is really not trivial. Even if you think your fix is a good one, and helps your people, but it won't help the common situation in general. There needs to be a talk...and when I recall my inbox, there was a lot of talk because of this crap named gem. > It would be a shame, on the heels of developer week, to lambaste new > contributors on > mailing lists. TBH, ruby is a very strange thing...and imho it would have been better to include Lucas in this discussion and finding with him a good solution which suites all, not only ubuntu. The problem with gem is not ubunut specific, and we need to come to a good solution with upstream + all downstreams. Lucas reply to this issue was very sarcastic, but nevertheless regarding this issue, he was right. Regards, \sh -- Stephan '\sh' Hermann | OSS Developer & Systemadministrator JID: [EMAIL PROTECTED]| http://www.sourcecode.de/ GPG ID: 0xC098EFA8 | http://leonov.tv/ 3D8B 5138 0852 DA7A B83F DCCB C189 E733 C098 EFA8 -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
