gnudatalanguage: newer upstream version available
Hello, The gnudatalanguage package in Ubuntu is based on a 20-month-old 0.9rc1 version of GDL. There is a 0.9rc4 version available. The 0.9rc3 is packaged for Debian: https://bugs.launchpad.net/ubuntu/+source/gnudatalanguage/+bug/498781 Any chances for getting an update? :) Best regards, Sylwester -- http://www.igf.fuw.edu.pl/~slayoo/ | http://slayoo.itstudio.pl/ Please consider your environmental responsibility before printing this e-mail. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: motu-release
On 17.02.2010 11:03, Steve Langasek wrote: > On Wed, Jan 27, 2010 at 03:03:35PM +0100, Stefan Potyra wrote: >> - Merge motu-release and ubuntu-release? Add team members of the >>"flavours" to ubuntu-release to form kind of a "release >>taskforce"? > > As a first step, I suggest merging motu-release and ubuntu-release for > lucid. That sounds reasonable to me. After a cleanup the documentation should be simpler too: https://wiki.ubuntu.com/FreezExceptionProcess Just in time for Feature Freeze, eh? ;-) Have a great day, Daniel -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: motu-release
On Wed, Jan 27, 2010 at 03:03:35PM +0100, Stefan Potyra wrote: > I've (only) talked to Daniel so far and we came up with the following > possible > alternatives: > - Flavours like Kubuntu can approve their own members, so it would >make sense to let them make decisions in terms of freeze exceptions >too. (The MOTU Release team had delegates of various teams that >made decisions, which worked out well.) Between Jonathan's Riddell's status as a member of the release team, and his repeated delegation by motu-release regarding Kubuntu packages in universe, I think that reasonably approximates the status quo; but I hesitate to describe this as "flavors making their own decisions about freeze exceptions". So long as the Ubuntu family of distributions continue to make releases together out of the same archive, there's a need for coordination on such matters as the timing of the archive freeze, buildd quiescing for ISO mastering, and release-readiness criteria; I think the best option is to continue having a central team, which can either solicit team members from the flavour communities or delegate freeze decisions for a set of packages. > - Merge motu-release and ubuntu-release? Add team members of the >"flavours" to ubuntu-release to form kind of a "release >taskforce"? As a first step, I suggest merging motu-release and ubuntu-release for lucid. > - Just drop motu-release and let ubuntu-release make the decisions? I think that would only frustrate contributors, as the existing ubuntu-release team isn't likely to be able to keep up with all requests. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org 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: motu-release
On Thu, Jan 28, 2010 at 01:04:25AM +0900, Emmet Hikory wrote: > Scott Kitterman wrote: > > On Wednesday 27 January 2010 09:03:35 am Stefan Potyra wrote: > >> FeatureFreeze is less than a month away, so the discussion over > >> restaffing the current MOTU Release team, which is a short of members > >> [1], brought up the topic how best to deal with release decisions in > >> light of Permissions Reorg. > <...> > > motu-sru and ubuntu-sru merged into a single team. I've had a couple of > > conversations with people in terms of doing something simllar with motu- > > release and ubuntu-release. I think it's the right answer. So far it's > > been > > a matter of finding time to talk with everyone about it and decide what > > should > > be done. > Could such an item be added to the agenda of the next release > meeting? It seems like the various groups typically reporting there > would be natural delegates for the various areas on which they report If you mean that they should be delegates for all the packages related to their teams, I don't think that's a good idea. If not an outright conflict of interest, leaving these decisions to the individual teams directly brings the problem of myopia alluded to in my previous message. The point of having a team approve freeze exceptions at all, instead of letting individual developers continue to upload directly to the archive, is to make sure we're collectively on the same page regarding what should be going into the release when; that means the people approving freeze exceptions for packages that land on CDs need to have an overview of the release as a whole. I don't think per-team delegates are the way to achieve this. > (and those groups that had historical delegates ought be encouraged to > participate and report in that forum). Unfortunately, the structure of the release meetings today doesn't scale well to a large number of teams, and the length of the meeting is already a challenge for scheduling. Where there is a need for other coordination within the release team, I would prefer to see this take place via either separately scheduled meetings, or email. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org 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: motu-release
Hi, Am Wednesday 17 February 2010 11:03:09 schrieb Steve Langasek: [..] > > > - Merge motu-release and ubuntu-release? Add team members of the > >"flavours" to ubuntu-release to form kind of a "release > >taskforce"? > > As a first step, I suggest merging motu-release and ubuntu-release for > lucid. This seems to be the consensus so far, anyone disagree? As FeatureFreeze is already tomorrow, I think we should immediately try to find the procedure how to handle freeze exception requests (which I guess will start to get filed from tomorrow on). To not block lucid development on the lack of a procedure, I suggest that we keep the status quo and have motu-release handle universe/multiverse exception requests with two +1 votes and have ubuntu-release handle main/restricted as an interim solution. Hopefully we'll find a common procedure on how to hande freeze exceptions in the next few days then. 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: motu-release
Hi, Am Wednesday 17 February 2010 11:03:09 schrieb Steve Langasek: > On Wed, Jan 27, 2010 at 03:03:35PM +0100, Stefan Potyra wrote: > > I've (only) talked to Daniel so far and we came up with the following > > possible alternatives: > > > > - Flavours like Kubuntu can approve their own members, so it would > >make sense to let them make decisions in terms of freeze exceptions > >too. (The MOTU Release team had delegates of various teams that > >made decisions, which worked out well.) > > Between Jonathan's Riddell's status as a member of the release team, and > his repeated delegation by motu-release regarding Kubuntu packages in > universe, I think that reasonably approximates the status quo; but I > hesitate to describe this as "flavors making their own decisions about > freeze > exceptions". So long as the Ubuntu family of distributions continue to > make releases together out of the same archive, there's a need for > coordination on such matters as the timing of the archive freeze, buildd > quiescing for ISO mastering, and release-readiness criteria; I think the > best option is to continue having a central team, which can either solicit > team members from the flavour communities or delegate freeze decisions for > a set of packages. Agreed. Delegating freeze decisions for a set of packages matches very much what we've done with delegates so far :). motu-release chose the relevant delegates themselves. With "decisions in terms of freeze exceptions", I meant that not motu-release chooses delegates, but any team can handle freeze exception requests for a given subset of packages how the team think it's best. Of course this should include a responsibility to ask the release-team in case of potentially contentious packages. 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
Stunnel-Package on ubuntu 8.04
Dear Sirs, is it possible for you to compile the Stunnel Package with use oft he actual source-version which is currently 4.31 ? The version that is installable via apt-get is 4.21 on ubuntu 8.04 and pretty buggy. We need this Stunnel for our company and I am not able to compile this package for myself. (I tried it, but I didnt get the required OpenSSL to be compiled) Best regards Mit freundlichen Grüßen Thomas Schürstedt Daniel Schrauben GmbH EDV-Abteilung Daimlerstrasse 17 32312 Lübbecke Telefon: (05741) 3480-19 Fax: (05741) 3480-50 Mobil: (0172) 8393339 Internet: www.daniel-schrauben.de eMail : e...@daniel-schrauben.de Handelsregister: Amtsgericht Bad Oeynhausen - HRB 8497 Geschäftsführer: Christian Daniel - UST-IdNr. DE 125747347 -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: motu-release
On Wed, Feb 17, 2010 at 11:32:13PM +0100, Stefan Potyra wrote: > Agreed. Delegating freeze decisions for a set of packages matches very much > what we've done with delegates so far :). > motu-release chose the relevant delegates themselves. With "decisions in > terms > of freeze exceptions", I meant that not motu-release chooses delegates, but > any team can handle freeze exception requests for a given subset of packages > how the team think it's best. Of course this should include a responsibility > to ask the release-team in case of potentially contentious packages. That's precisely the model that I'm arguing against. If there are to be delegations here, they should be decided on a per-team basis, not as a blanket policy. So not "any team can handle" - only teams for which we identify delegates that we're confident are on the same page with the rest of the release team. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org 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
