Re: Nuke of certain packages @ revu
Hi, On Tue, Aug 30, 2011 at 11:42:21PM +0200, Stefan Handschuh wrote: Hi, since clicking on nuke on some of my previous uploads, I would kindly ask you to delete the following two packages from revu.ubuntuwire.com: - libauvitoapiaxis-java - jaolt done. Cheers, Stefan. 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: Debconf help
Hi, Am Thursday 22 July 2010 21:34:19 schrieb Tony Yarusso: [..] * Do not use service to invoke initscripts from package maintainer scripts. Instead follow Debian policy: http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.3.3.2 Okay. I was sort of under the impression that service was replacing invoke-rc.d, although without any evidence. Just out of curiosity, what's the difference between them? afaict: service is used to start upstart services, invoke-rc.d starts SysV init scripts. To my knowledge, the best option is to use dh_installinit -R for the init-script, as it will generate the correct code for SysV or upstart (given you use the debhelper token in the maintainer scripts). Oh, just saw another thing while taking a glimpse: sed -i 's/\#includedir\ \/etc\/sudoers\.d/includedir\ \/etc\/sudoers\.d/' /etc/sudoers Please don't modify settings of a different package apart from the official interface (that is exactly what sudoers.d is for). HTH, 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 Friday 26 February 2010 20:37:24 schrieb Scott Kitterman: On Thu, Feb 18, 2010 at 03:52:49PM -0500, Scott Kitterman wrote: Regarding the team unification, is there an expectation that the two-vote approach will continue? I don't have a strong preference between the ubuntu-release and motu-release approaches, but I think it would be strange to be applying different procedures for different archive sections - or to different members of the team! - so we should probably pick one... I think it should go. IMO one of the main reasons to unify the teams is to simply the process for people trying to work through getting needed approvals. If we have two separate rule sets, we may as well keep it two teams (I'm not proposing we do this). I think the attached diff for FreezeExceptionProcess reflects the emerging consensus. Are there any objections if I apply this to the wiki and send out an updated freeze process mail to u-d-a? Are there any team delegations we want to have in place before sending out the announcement? It looks good to me. No objections. no objection, but still got a few questions: 1) how are FFe's handled? I assume that one ACK from a member of ubuntu-release suffices, correct? 2) new packages: do we also just require one ACK there, or do we want two ACKs? Also, new packages was delegated from MOTU to motu-release (or rather motu-uvf which got renamed to motu-release later). Even later ubuntu-release was made a member of motu-release, acknowledging that ubuntu-release should always be able to decide for motu-release. Do we need a formal MOTU decision to transfer this responsibility? If so (please speak up if you anyone think that it's needed, otherwise I'll assume consensus), what is the current process to get this decision? 3) Universe used to have a later deadline for final freeze, to get latest bug fixes in. Past the deadline we used -proposed to get very late fixes in, handing over the queue to -sru. I think this could prove worthwhile again. Maybe we should replace universe with unseeded packages and decide later on it? WRT delegations: I think between Riddell and myself Kubuntu is already well covered. In the past I was the server team delegate for Universe, but the only purpose that served was to obviate the double ack rule. Since we're getting rid of that rule, I think there's no need. I woulnd't let getting delegation sorted out stop announcing thins. delegations also served to have the people with best knowledge cover an FFe. Teams not mentioned yet were we had delegates are: * mythbuntu * mozilla team * ubuntustudio * xubuntu * desktop (gnome) * netbook * edubuntu I'm not yet 100% sure how delegates fit in with the motu-release and ubuntu-release merge. Personally, for few requests I've simply subscribed the relevant persons and requested input from them, which gave the basis on my decision. I'd suggest that this scheme can be applied until we reach consensus about delegates. 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 Thursday 18 February 2010 02:09:04 schrieb Steve Langasek: 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. Ok, was just an idea. Your proposal sounds good to me as well. 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 Thursday 18 February 2010 12:21:34 schrieb Steve Langasek: [..] Ack; freeze announcement sent out with the status quo. Thanks! Regarding the team unification, is there an expectation that the two-vote approach will continue? I don't have a strong preference between the ubuntu-release and motu-release approaches, but I think it would be strange to be applying different procedures for different archive sections - or to different members of the team! - so we should probably pick one... Definitely makes sense. I don't have a strong preference over the exact procedure as well. How did ubuntu-release handle FFe's so far? I assume the worklist is the list of subscribed bugs? Do you also use the +nominations page? 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: [..] - 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
motu-release
Hi, 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. 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.) - Merge motu-release and ubuntu-release? Add team members of the flavours to ubuntu-release to form kind of a release taskforce? - Just drop motu-release and let ubuntu-release make the decisions? - fill in you alternative The final question is: should we aim to resolve this for Lucid or should it be for Lucid+1? Cheers, Stefan -- [1]: https://launchpad.net/~motu-release/+members 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: Søren Hansen and Michael Bienia
Hi Mark, Am Monday 02 November 2009 11:00:57 schrieb Mark Shuttleworth: Stefan Potyra wrote: Hi Martin, Am Saturday 31 October 2009 10:57:21 schrieb Martin Pitt: Stefan Potyra [2009-10-31 2:58 +0100]: That aside, I find it very interesting and disturbing that membership of otherwise voted upon boards are (as it occurs to me from this mail) prolonged by the will of one developer. Well, it wasn't just that. It was discussed on th DMB list, and there was general agreement (Mark voted +1 on the list, Colin on IRC, I agreed as well, and there was no objection from other members). thanks for clearing that up, but I must admit that I'm now even more confused: Daniel wrote that this was a decision of TB and CC, while you wrote that it was done on the (private) DMB list, making me assume that it was an action of DMB. Which board did take the decision then? Oh for Pete's sake! This was a simple pragmatic decision to preserve the status quo while we move to a cleaner, better structure. Let's not bog ourselves down in procedural pedantry. If the CC need to, we can make direct appointments and replacements on any structure in Ubuntu, and will do so. Thanks, Mark, that's at least a clear announcement, helping me better understand how the Ubuntu government works in reality, and to what degree government bodies value the community. 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: Søren Hansen and Michael Bienia
Hi Martin, Am Saturday 31 October 2009 10:57:21 schrieb Martin Pitt: Stefan Potyra [2009-10-31 2:58 +0100]: That aside, I find it very interesting and disturbing that membership of otherwise voted upon boards are (as it occurs to me from this mail) prolonged by the will of one developer. Well, it wasn't just that. It was discussed on th DMB list, and there was general agreement (Mark voted +1 on the list, Colin on IRC, I agreed as well, and there was no objection from other members). thanks for clearing that up, but I must admit that I'm now even more confused: Daniel wrote that this was a decision of TB and CC, while you wrote that it was done on the (private) DMB list, making me assume that it was an action of DMB. Which board did take the decision then? We will talk about the MC/DMB at next Tuesday's TB meeting, but didn't want to inhibit the current MC's function for this week. How would not taking action have inhibited the MC's function? Cheers, Stefan. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Søren Hansen and Michael Bienia
Hi, Am Friday 30 October 2009 17:30:44 schrieb Benj. Mako Hill: Martin Pitt has apparently recently extended the terms of Søren Hansen and Michael Bienia by 3 months. As folks should know by now, there's a recently executed plan to split developer membership out from the TB into a new developer membership board (DMB) and a plan to merge the DMB with the MC or work out some sort of other arrangement. For a reasons related to the release and archive restructuring, a bunch of things are still up in the air. Rather than run an election for a position that may disappear in the next couple months, the CC, DMB, Søren, and Michael talked about this and agreed to a 3 month extension of their terms on the MOTU Council to give everyone involved some time to make the decisions and changes that are necessary and figure out the process by which the MC/DMB seats will be filled. As soon as it's clear what needs to happen, we will run elections. I'm sure someone will correct me if I've managed to screw that up. :) yep, you screwed up, at least in my eyes :P ;). First off, such an announcement won't reach a large number of developers unless sent to e.g. ubuntu-motu or ubuntu-devel (@l.u.c). CC'ing ubuntu-motu and keeping the complete original text for reference. That aside, I find it very interesting and disturbing that membership of otherwise voted upon boards are (as it occurs to me from this mail) prolonged by the will of one developer. Maybe you can clear up what happened? Did that happen on request of the community council? Or was it that tech board interfered here? And if either, on what basis? Or anything else I just didn't get? 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
fixing build failures - practice session
Hi, looking at http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20090909-karmic.html there's still so much to do! Hence I'll be holding a practice session at 19.00 UTC *today* in #ubuntu-classroom (if available, otherwise straight in #ubuntu-motu) targeted to fix build failures. If anyone wants to help out with the session, that would be excellent. Anyone is welcome to attend. For those who cannot upload to the archive yet, I'll also try to sponsor as much build failures as I can. 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: upstream Source patches and patch systems
Hi, Am Wednesday 07 October 2009 08:13:36 schrieb fabrice: John Dong escribió: Can you clarify these two points? To my 2AM mind it reads as if the It's because my 7AM mind needs some coffee :-) let me rephrase it this way: - if modification has already been done, stick to what the Debian maintainer or Ubuntu is already doing. That mean use the existing patch system, if any, or modify directly the source if some modifications has already been done, but do not add a patch system. - if it's a Debian package and no previous modifications has been done, modify directly the source, and do not introduce a patch system Yes, sounds good! - if it's an Ubuntu (-0ubuntuX) package and no previous modifications has been done, adding a patch system is preferred I must admit that I usually don't introduce patch systems there (as I don't like these too much *g*). However I guess that's a case-by-case decision: Adding a patch system for a one-line change seems like overkill to me. OTOH a patch system can help if you have several changes, which target different bugs, because you can then split these in separate patches which targetting one bug. 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: let's do a motu-meeting again
Hi, oops, that was meant to go to the list, while I've written to Morten only. Am Tuesday 06 October 2009 17:18:33 schrieb Stefan Potyra: Hi, Am Saturday 03 October 2009 13:32:58 schrieben Sie: [..] Any proposals for a better time/date? We should return to the old principle of regular MOTU meetings with a schedule that rotates with the timezones. Perhaps once a month? Yes, sounds like a good plan. Cheers, Stefan. 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: let's do a motu-meeting again
Hi, ahem, shame on me, as I scheduled the meeting in conflict with a Kubuntu meeting. So no meeting for us right now. Any proposals for a better time/date? Cheers and sorry for the inconvenience, 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
let's do a motu-meeting again
Hi folks, we haven't had a motu-meeting for quite some time. Let's do one again, shall we? I propose next Friday (Oct 2nd), 19.00h UTC at #ubuntu-meeting. What do you think? 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: FTBFS fixing session at Fri Sep 18, 19.00h UTC
Hi, Am Thursday 17 September 2009 07:02:40 schrieb Daniel Holbach: On Wed, 2009-09-16 at 18:10 +0200, Stefan Potyra wrote: [..] So, next Friday at 19.00h UTC there'll be another session about fixing FTBFS in #ubuntu-motu. The session is intended to be open-ended, where everyone will hopefully fix a package or two :). [..] That's awesome! If you could hold it in #ubuntu-classroom (the log will probably a bit more readable afterwards), Good idea, so it shall be #ubuntu-classroom :). I'd announce it on https://wiki.ubuntu.com/Packaging/Training and http://ubuntupackaging.wordpress.com/ Excellent, thanks! 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: Launchpad Bug Filing Changes for Ubuntu
Hi Brian, Am Tuesday 15 September 2009 19:53:19 schrieb Brian Murray: [..] [1] https://wiki.ubuntu.com/QATeam/Specs/IncreaseApportAdoption (*) There will be a +filebug?no-redirect if you really really need it. After a quick read of the spec, I'm curious about: * Do Not allow users to file a bug at all without specifying a package Will this interfere with the needs-packaging bugs which are not filed against any package (heh, because there isn't one yet :D)? Thanks, 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
FTBFS fixing session at Fri Sep 18, 19.00h UTC
Hi folks, as you might be aware, the rebuild test[1] has shown lots of build failures related to gcc-4.4 / new eglibc. To get things down, I held a spontaneous training session together with Michael Bienna and Steve Langasek in #ubuntu-motu last Friday. As this session worked out quite well (and I could sponsor a number of FTBFS fixes last weekend), let's do it again... there's still lots of work to do. So, next Friday at 19.00h UTC there'll be another session about fixing FTBFS in #ubuntu-motu. The session is intended to be open-ended, where everyone will hopefully fix a package or two :). P.S.: If anyone wants to help out with the session, that would be totally awesome :). Cheers, Stefan. -- [1]: http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20090909.html 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
ffmpeg transition, almost there, call for help
Hi, ffmpeg changed it's library names from -unstripped- to -extra-, e.g. libavutil-unstripped-49 - libavutil-extra-49. While the -unstripped- variants are still there as dummy packages, it would help apts dependency resolver a lot, if we could get rid of rdepends against -unstripped- packages. The good news, there are not many source packages left. A number of packages that are left have hard-coded these as depends/recommends. Generally I dislike this practice (libraries should get calculated from the shlibs file), but admitted, there are good reasons for some of the packages to do so. While I guess there might be a better scheme to do this, I wouldn't advise to change the way things work at this point of the freeze. The remaining source packages can be calculated with the following scriptlet: for i in $(apt-cache rdepends libavutil-unstripped-49 \ libavcodec-unstripped-52 libavdevice-unstripped-52 libavfilter-unstripped-0 \ libpostproc-unstripped-51 libavformat-unstripped-52 \ libswscale-unstripped-0 | \ sed -e 's/Reverse Depends://' | grep ' '); \ do apt-cache showsrc $i | grep ^Package | \ sed -e 's/Package: //'; done | sort -u Please help to get these adjusted. == Various info I obtained while migrating a large set (info might be outdated): The following packages should simply get rebuild, but FTBFS: ffmpeg4ip smilutils For mythexport I've already filed a bug (427508). Benjamin (hey, congrats for your MOTU-ship!) is on audacious (pending a fix in wxwidgets2.8 - which I thought I'd come around to upload last weekend, sorry... at least now you can upload the fix yourself ;). Please also note, that unstable has the new ffmpeg as well, so bug reports due to *hard-coded* depends/recommends should get forwarded where applicable. (please don't forward requests for mere rebuilds, as these can be handled via binNMUs in unstable). Final note: not every of my rebuilds built fine on every architecture. This fallout should be in NBS though, so please look at there as well. 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
ffmpeg transition: unstripped - extra (Re: [ubuntu/karmic] xvidcap 1.1.7-0.2ubuntu3 (Accepted))
Hi, first off sorry, I wanted to have a mail sent about this yesterday already but didn't come around to it yet :(. In short: the ffmpeg-extra package has renamed the binary packages from -unstripped- to -extra-, the -unstripped- ones are only transitional packages and should no longer be dependend on. Am Monday 31 August 2009 17:00:14 schrieb Alessio Treglia: [..] * debian/control: - Add dependency on libavcodec-unstripped-52 to fix LP: #290728. So that should be libavcodec-extra-52. For a number of packages that have hard-coded depends/recommends like this one, I'm not sure if it is always the best choice, as many packages don't seem to directly make use of ffmpeg symbols. But I didn't complete my investigations on this yet, so I can't say yet if it still might be the best solution after all ;). Once I have more findings and a list of packages that still need to be transitioned, I'll send another mail. In the case of xvidcap it seems like it's the right thing to add the dep to -extra- though. Can you update it please? Thanks, 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: FFe request for audacity
Hi, Am Friday 21 August 2009 15:17:54 schrieb Benjamin Drung: Hello, I would like to have a general feature freeze exception for audacity for karmic. The odd 1.3.* releases of audacity are beta releases. Since hardy Ubuntu is using the 1.3 series. Upstream focuses now a stable release (1.4 or 2.0). They are polishing audacity and fixing many bugs and they try to not introduce new features. According to their mailing list they have following release time line: * 1.3.9 - Aug 25 * 1.3.10 - Sep 25 * rc - Oct 7 * release - Oct 15 If they need more time, they will probably release a 1.3.11 on Oct 15 and the final release after karmic. I would like to see the latest release of audacity in Ubuntu 9.10. I assume, upstream are aware of karmic's release schedule[1]? That'd be good, and I'm personally in favor of having upstream supported versions in the release. Release happening at Oct 15 might be a bit short of time, due to Ubuntu's FinalFreeze starting there. Bugfixes (and I assume rc - release would mean bug fixes only) could still go in though. That said, I'm also raising this on ubuntu-studio-devel (CC'd) for further input. Cheers, Stefan. -- [1]: https://wiki.ubuntu.com/KarmicReleaseSchedule 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: FeatureFreeze Aug 27 - motu-release planning ahead
Hi, Am Thursday 13 August 2009 16:27:36 schrieb Steve Stalcup: On Thu, Aug 13, 2009 at 9:27 AM, Iulian Udreaiul...@ubuntu.com wrote: What about Friday, the 21st? Scott, when do you come back from holiday? I would very much like to see all members of the motu-release team present at the meeting. yes, I agree. That date works for me. Works for me as well. 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
FeatureFreeze Aug 27 - motu-release planning ahead
Hi folks, first off, welcome Steve, great to see you joining motu-release! Now, Feature Freeze starting at August 27 is not too far ahead, I'd like everyone to get ready for it. In particular: Start to fix 1) uninstallable packages [1] 2) FTBFS [2] 3) review NEW packages on REVU [3] 4) sponsor fixes [4] (more or less random list from my head, please anynone chime in with additions/corrections) Now, with Feature Freeze pending, maybe it would be a good idea to do a motu-release meeting again, to sort out the details for karmic's freeze. How about Monday, 17th Aug, 13.00 UTC? (or what other date/time would suit you?) Then we could sort out details like if we want delegates again, or what general exception policy we want for karmic's release or what package sets need immediate attention. Given the expectation, that delegates are desired again, and as I've had the pleasure to select delegates during Jaunty's cycle, whom would you suggest for karmic? Anyone volunteering for a particular position? Finally, even if this may be the last time due to the archive reorganisation, I'd like to thank the Ubuntu release team for the good coordination and collaboration during the last cycles. I hope for karmic we'll perform well together again! Cheers, Stefan. [1]: http://qa.ubuntuwire.com/debcheck/ [2]: http://qa.ubuntuwire.com/ftbfs/ [3]: http://revu.ubuntuwire.com/ [4]: https://bugs.launchpad.net/~ubuntu-universe-sponsors/+subscribedbugs 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: Resigning from motu-release and sponsor queue admins
Hi Luca, Am Tuesday 07 July 2009 19:11:30 schrieb Luca Falavigna: Hello, I decided to resign from motu-release and ubuntu-universe-sponsors queue administrator teams due to time constraints. These two roles require much attention than the one I can give to them right now. That's sad to hear, and I can only chime in to thank you for your excellent work! You'll definitely be missed by the teams! 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: Maintainer/XSBC-Original-Maintainer in Ubuntu packages
Hi Luca, Am Friday 12 June 2009 23:05:32 schrieb Luca Falavigna: Il giorno Fri, 12 Jun 2009 18:04:52 +0200 Morten Kjeldgaard m...@bioxray.au.dk ha scritto: Maintainer: Morten Kjeldgaard (https://launchpad.net/~mok0) Soyuz would complain about wrong email address format and reject upload. I'm not entirely sure, but I think using an email address registered with launchpad as Maintainer entry will make you a bug contact. However maybe that's limited to @ubuntu.com addresses, and maybe I'm even there still wrong. What you want could be addressed using a pseudo-header (I invent a name for it: XSBC-Ubuntu-Maintainer), but I think we should not introduce the concept of maintainership in Ubuntu. MOTUs and contributors are responsible at a whole about the packages in universe and multiverse, enabling some sense of ownership makes people less prone to fix things in a package they see as a do-not-touch-my-stuff thing. Admitted, I've used (and still am) using my Ubuntu address as Maintainer entry for a few packages which I tend to care for, mainly in the hope to give a point of contact for change requests History so far showed to me, that this didn't stop anyone from making bad or good uploads. mainly it boiled down to me sponsoring good uploads which I guess was mainly a result of being subscribed to bug reports. I've also seen a few cases in the past, where I in fact wanted to know whom to contact and looked at packages.debian.org/packages.ubuntu.com to find out wether it's a Ubuntu local package or if the XSBC-Original-Maintainer came from Debian. That usually resulted in digging debian/changelog, which didn't always give too much clue (e.g. if packages are touched by many people, who's the best then to contact?) I personally don't believe that using the Maintainer-Field for Ubuntu local packages will void that any packages are free for all, or impose any Maintainership concept. If it helps to have a genuine information whom to contact, and also if it will create bug contacts for Ubuntu local packages, I'm in favor of it. To be clear though, I don't think that this will impose any Maintainer-ship concept or that I'd be in favor of such a Maintainer-ship concept. To put it in a nutshell, I'd like to have an automated mechanism to subscribe initial packagers to bug-mail, and to have an easy way to reach those who have the most knowledge about a package. If the Maintainer field can do so, I'm in favour. If not, I hope we can find some other means. 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: Archive frozen for preparation of Ubuntu 9.04
Hi Iain, Am Thursday 09 April 2009 12:33:04 schrieb Iain Lane: On 9 Apr 2009, at 08:39, Steve Langasek wrote: Uploads to universe should again follow the guidelines described here: https://lists.ubuntu.com/archives/ubuntu-devel/2008-April/025259.html first off the delegates changed a little bit for jaunty, see https://lists.ubuntu.com/archives/ubuntu-devel-announce/2009-February/000533.html for the current list. Being in FinalFreeze, the archive is now frozen, so any upload will need to be shoved through the queue by an archive admin, warranting a FreezeException to be granted. Can motu-release clarify the processes in place for freeze exceptions that are in force now? I see the old policy at [0] that was in force for Intrepid. Do you plan on doing this again? hm... for Intrepid, that worked out pretty well imho, so yes. Scott, Luca, Nathan, Iulian any objections? The above mail also seems to imply that only 1 +1 is needed from a -release member for bugfix uploads after the (possibly eventual) freeze. Is this right? Correct. anything still unclear? 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: Hello release team...
Hi Bhavani, Am Tuesday 03 March 2009 15:29:04 schrieb Bhavani Shankar R: On Fri, Feb 27, 2009 at 3:11 PM, Luca Falavigna dktrkr...@ubuntu.comwrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bhavani Shankar R ha scritto: I am now working on updating the geda suite in ubuntu and I need your guidance so as to whether I require FFe for [1] [1] https://bugs.edge.launchpad.net/ubuntu/+source/geda-gattrib/+bug/334373 I see there have been some geda updates already, and I think more would be required to have a good-shaped geda stack. Could you please check them (a search on packages.ubuntu.com could help) and do some tests? Once you have a well-defined package update roadmap, we can discuss about it in time for the release. Thanks! I am on it surely but I need a couple of days time as I ve some assignments to complete in the university.. Hello again... I ve reported the bugs for 3 packages that was required to complete the new geda stack [1] [2] and [3] Please guide me whether any further analysis is required (So I ve assigned them to myself) looks all good to me (appear to be only bugfix versions and we've got libgeda already in the archives). So the next steps would be to get these packages sponsored. 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: Voting for MC members is open
Hi Michael, Am Friday 27 February 2009 14:10:40 schrieb Michael Bienia: Hi, as I didn't see any offical announcement about it yet: The voting for the new MC members is open and ends 2009-03-12. https://edge.launchpad.net/~ubuntu-dev/+polls What exactly does the result of this vote determine? Is a member accepted if he has a fixed number of yes votes, or the majority of yes votes, or more yes than no votes? (what does None of the above do there?). Something completely different *g*? 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: Staging area for REVU uploads?
Hi Morten, Am Saturday 21 February 2009 19:32:13 schrieb Morten Kjeldgaard: Hi MOTUs, I propose that we establish a PPA staging area for certain packages in REVU. There are several reasons why this could be practical: * At times, uploaders submit library packages, and also have other packages that depend on that library package uploaded for review. With the REVU PPA in listed in the pbuilder environments, it will be easy to build and review the dependent packages, without having to wait for the library package to reach the final archive. hm... not too sure: Just adding *all* packages on revu to my pbuilder environment is something which I feel uncomfortable with. Personally, I use mini-dinstall for this task, because it lets me explicitely select which package I want to be able to see in my pbuilder environment. * With the packages in a staging area, it would be easier and more convienient to invite people to do some preliminary installation and testing of the packages. that's a good point. * We can continue some level of reviewing and uploading, even during FF. With my motu-release hat on, I'm not too fond of this idea: FF has also the social component to shift people towards fixing bugs instead of reviewing new packages. * Certain build problems with packages might be exposed before being uploaded to the final archive. Yes. That would be good. I even think, that ideally every package uploaded to REVU should get autobuilt. However using a ppa for this would need the acceptance of launchpad developers, as it might contain indistributable code. Can you check with lp devs about this? 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 team needs members
Hi, On Fri, Feb 13, 2009 at 04:25:45AM +, Nathan Handler wrote: [..] Hello, I [1] would like to apply to become the 5th member of the motu-release team. I filed many Freeze Exception requests during the last release cycle, and I understand the impact upgrades can have. I also have devoted a lot of time to reviewing patches, merge/sync requests, and new packages on REVU. Several times, these reviews have ended with me telling the contributor that the patch/merge/sync/package is not appropriate for Ubuntu. As a result of this, I do not think that I will have any problems with rejecting freeze exceptions. I also have plenty of experience carefully reviewing changelog entries and debdiffs from the sponsoring/reviewing I have done. For these reasons, I feel I possess all of the qualities necessary to be a members of the motu-release team. I second the application. Cheers, Stefan. 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: Needs Packaging bug reports
Hi Brian, On Wednesday 11 February 2009 20:34:38 Brian Murray wrote: [..] On Tue, Feb 10, 2009 at 02:18:56PM -0800, Brian Murray wrote: As a part of the managing needs-packaging bug reports specification[1] [..] Barring any objections I plan on running this on the Friday the 13th, which will modify approximately 254 bug reports, and scheduling it to run weekly thereafter. I strongly object to both the specification and the result of you running that script. I'm interested to hear and discuss your objections to both of these. Sorry for not providing a rationale in the first place. After reading the spec, I personally can't see any benefit in moving the needs-packaging bugs around, but rather the drawback that documentation and scripts (e.g. my personal completely messy script which tries to check wether an upload fixes the right bugs - and hence has some heuristics for needs packaging bugs as well) would be broken by that approach. Furthermore, I also don't think that announcing most-wanted packages in forums or blogs is necessarily a good thing. On one side, this goes back to the lengthy discussion wether to shift the scope away from packaging new things for motu-hopefuls to fixing bugs. Additionally, this might create uncertainty to where to ask for packaging reviews: During last? (or last but one?) feature freeze cycle, I've even seen a FFe request for a package wich has only been discussed on the LP needs-packaging bug (and which as a result had a number of beginner mistakes, s.th. which I guess could have been sorted out much easier/earlier on with revu). Now, sorry, if I didn't understand it correctly, but if the script you intend to run now only sets the priority to wishlist (and won't move bugs around), then I don't object to this at all. Cheers, Stefan. -- 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 team needs members
Hi, thanks to Iulian, we're back at 4 members right now. Maybe someone is still interested in becoming the 5th member, so that we'd be back at full strength for jaunty's freeze? Quoting myself: If you know the impact of upgrades at late stages, don't shy away from reading changelogs and patches, also have the ability to make unliked decisions like rejecting freeze exceptions, then motu-release needs you. Please send in your application as reply to this thread. Oh, and being a MOTU is required. Side-word: Imho we could also need bug-triagers that help with looking at and sorting incomplete FFe requests, or to ping FFe requestors after some time of inactivity... Is this the right list to ask for those? (If not, please bounce to the correct location). Cheers, Stefan. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
motu-release meeting Feb 3rd - very short minutes
Hi folks, just a short heads up, sorry that I didn't come around to write a few points of the results of the meeting yet. So here a few points we discussed. Please refer to the full log, in case you're interested in getting the full picture at [1]. 1) grilling Iulian first off, after the call for volunteers, Iulian was the victim to become a member of motu-release. Questions were asked and Iulian answered them all to our consent [and he's a member of motu-release in the meantime]. 2) bi-weekly ubuntu-release meetings: Scottk brought this up, and thought it would be good if a motu-release person would be there (luckily, ScottK fullfilled this quite good last release and volunteered to do the same for jaunty -- of course other members are invited, too!) 3) new packages: We'll take a harder policy in regrads to NEW this time, so bring in your pet package before FF, otherwise we'll just say NO! other items of action: * DktrKranz to take a stab at drafting a motu-release policy. * sistpoty to review motu-release delegations. * DktrKranz to book ubuntu-meeting for next meeting [already done]. Finally, next organisational meeting will take place on Monday 16th - 19:00 UTC, #ubuntu-meeting. Cheers, Stefan. -- [1]: http://irclogs.ubuntu.com/2009/02/03/%23ubuntu-meeting.html -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Needs Packaging bug reports
Hi Brian, first off, why didn't you CC ubuntu-m...@l.u.c, who are most affected? On Tue, Feb 10, 2009 at 02:18:56PM -0800, Brian Murray wrote: As a part of the managing needs-packaging bug reports specification[1] [..] Barring any objections I plan on running this on the Friday the 13th, which will modify approximately 254 bug reports, and scheduling it to run weekly thereafter. I strongly object to both the specification and the result of you running that script. Cheers, Stefan. -- 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 team needs members
Hi, On Wednesday 04 February 2009 12:02:43 Luca Falavigna wrote: Iulian Udrea ha scritto: I would like to join the MOTU Release team, so please consider this my application to become a MOTU Release member. I second Iulian's application. I also second Iulian's application. 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: R: motu-release organisational meeting
Hi Cesare, On Wednesday 28 January 2009 11:41:32 norse...@alice.it wrote: Unfortunately, I'm rather busy at the moment and won't be able to contribute much for this (and I'm afraid also next) release, certainly not as a motu-release member. Please remove me from the team, if any volunteer want to step in to fill the post please do so. That's sad to hear. So the meeting is scheduled for Tuesday, February 3rd, 14.00 UTC. 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
motu-release team needs members
Hi, first of all thanks a lot, Cesare, for your efforts within the motu-release team! Now looking that [1], I see that we've only 3 members left, so I guess motu-release could need at least one or better yet two more members. Now I completely forgot what the policy to add more members to key teams was, but I vaguely recall that it started with asking for applicants on this list. So that's what I'm doing right now. If you know the impact of upgrades at late stages, don't shy away from reading changelogs and patches, also have the ability to make unliked decisions like rejecting freeze exceptions, then motu-release needs you. Please send in your application as reply to this thread. Thanks, Stefan. -- [1]: https://launchpad.net/~motu-release/+members 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
motu-release organisational meeting
Hi motu-release members, with FeatureFreeze approaching at Feb 19, I guess it'd be good if we schedule an organisational meeting. What do you think? What date would suit you? Maybe this Friday, at 14.00h UTC? 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 organisational meeting
Hi, On Tuesday 27 January 2009 15:03:11 Luca Falavigna wrote: Stefan Potyra ha scritto: What date would suit you? Maybe this Friday, at 14.00h UTC? Probably I'll be buried in office for that time, I'd rather prefer Tuesday, February 3rd at the same timeframe, but I'll try to be there anytime (I can't promise I can catch things quickly, though). Tuesday, Feb 3 would work for me as well. Others? 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: REVU: Automated Package Checks
Hi, On Friday 23 January 2009 01:31:42 Loïc Martin wrote: Nathan Handler wrote: [..] What happens when lintian (or another automated check) throws an error, but that error is not justified? I've seen the case for all cdemu related packages (for example http://revu.ubuntuwire.com/details.py?package=cdemu-client ) where lintian reports an error but according to the packager (and my newbie review ;) ) the error is bogus. Nope, in this case (cdemu-client) it is indeed a packaging error (don't copy config.sub/config.guess in clean -- rather remove/restore the original ones in clean. Otherwise the .diff.gz gets cluttered). 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: REVU Upload problems
Hi Joel, On Tuesday 13 January 2009 02:45:51 Joel Cross wrote: Hi MOTU, I recently signed up to REVU in order to upload my project to Ubuntu. (The bug report is at https://bugs.launchpad.net/bugs/314237). I have uploaded the package three times now over the past week or so, but it still will not show on the website, and it still says I have no uploads. Can you tell me what might be wrong? My REVU name is ukch. the package in question is sabacc, right? You've uploaded a binary package instead of a source package, so REVU didn't accept it. Please build a source package using -S -sa as arguments to debuild/dpkg-buildpackage, and upload the resulting .changes file to REVU, then everything should hopefully work. 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: Jaunty pre-freeze Freeze Exception Request: mrpt
Hi, On Friday 09 January 2009 09:43:40 Jose Luis Blanco wrote: Dear MOTUs, I wonder if it'd be possible to allow the newer version of the package mrpt 0.6.5svn706-1 [1] to enter Jaunty from Debian. That would fix the build errors [2] in the current Jaunty's version for big-endian architectures. as we're not yet in FeatureFreeze, you don't need an exception for new upstream versions yet. 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: Proposal for motu-release charter
Hi, On Monday 27 October 2008 04:37:48 Emmet Hikory wrote: Soren Hansen wrote: Dear motu-release! In order to reduce misunderstandings, the MC would like to request that you, motu-release, come up with a proposal for a charter for yourself. We'd like to be able to discuss and approve it at the next MOTU Meeting, if possible. It's been a while, and you've all been busy chasing the release. Great job on handling the final transitions and getting the RCbugs queue down to a manageable size for the SRU team. Thanks! Now that there's a little breathing space, would it be possible to revisit a charter and bring it to a MOTU Meeting in the near future? Perhaps for the 14th of November? I've been thinking quite long about this topic, and I must admit, that I didn't come to conclusion yet. Technically, there aren't any powers that motu-release has, that any other developer doesn't have: motu-release cannot reject a new upstream version while in FeatureFreeze, nor can we accept an uploaded package while in deep freeze (that's left to archive-admins). However I believe that motu-release has a social influence, i.e. if we'd reject a new upstream version, it would imply to developers or sponsors that they shouldn't upload it, and most probably won't do so. Same goes for the reverted upload of libgems-ruby. Being within a team, however means that the general attitude towards or against that team is perceived from a differnet point of view, and (to my observations) is often misleading of what a team should do or should not, or what the purpose of that team is. Hence I guess it would be a better idea to have other developers propose a charter for motu-release. Maybe motu-council has a good proposal? Cheers, Stefan. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
what to do in between releases?
Hi folks, it won't be a long time, until Jaunty will open for uploads[1]. Until that time,you shouldn't sit on your back though. Please fix Intrepid issues via StableReleaseUpdates, see [2] for details. Also, I'd like you to look at REVU[3] to review new packages. It's never early enough to start with reviewing. As a side note, for those who are fixated to translations: There's a go-ahead to open translations for Jaunty :). Cheers, Stefan. -- [1]: it will be announced on ubuntu-devel-announce, so be patient [2]: https://wiki.ubuntu.com/StableReleaseUpdates [3]: http://revu.ubuntuwire.com -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: When does MOTU Release need to start approving every upload ...
Hi, On Thursday 16 October 2008 12:33:51 Cesare Tirabassi wrote: On Thu, 16 Oct 2008 06:17:35 -0400 Scott Kitterman [EMAIL PROTECTED] wrote: Based on: https://lists.ubuntu.com/archives/ubuntu-devel/2008-April/025259.html One might think it's now, but I propose this not start until the last week before release (i.e. one more week from now). +1, one week before release is more than reasonable. that would be Oct 23rd? sounds like a good idea to me. Would it be even possible to set universe/multiverse back to auto until that time? 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: When does MOTU Release need to start approving every upload ...
Hi again, On Thursday 16 October 2008 12:41:53 Stefan Potyra wrote: [..] Would it be even possible to set universe/multiverse back to auto until that time? wgrant sistpoty|work: Launchpad provides no facility to freeze just some components. 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-sru needs you
Hi again, On Friday 03 October 2008 19:47:24 Nicolas Valcárcel wrote: On Fri, 2008-10-03 at 19:23 +0200, Stefan Potyra wrote: ok, what possible problems would both of you see with getting the current version into -updates? Also, would you think that there are possible advantages of doing so? An advantage would be that -updates is activated on most systems while -backports not, so less people will receive the update. Problem is that it will break somehow the versioning schema, almost all packages in the -updates repository have the hardy revision + 0.X, while this package will have + Y, which can be somehow confusing aswell as the changelog entry, also it can break some updates and/or other packages given the new versioning, [..] Ah, that's interesting. I of course assumed that it would be clear that I'd give it a suitable version number. Why must a package in -updates have a different version number than a package e.g. in intrepid? Cheers, Stefan. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: motu-sru needs you
Hi, On Thursday 02 October 2008 22:25:16 Nicolas Valcárcel wrote: I would like to apply for SRU team aswell, my daily work involves working with the current stable release, so i think i can do o a good job on it. I'm also interested in QA and security, which are some things that will help me on this, so please consider this as my application for the motu-sru team. speaking of it, I'm interested where you'd draw the border between what should go into -security and -updates. Also, I'd be interested about a personal nitpick: The ghc6 package as in intrepid right now, hasn't seen a new upstream version since hardy, but was updated with a number of fixes since then, a few irrelevant to hardy (e.g. adding a script that produces some output during the time-taking build, so that slow buildds won't fail due to timeout), but some which fix imho important bugs. How would you react if I'd request the current version in intrepid to go into hardy-updates? @Devid: maybe you'd also like to answer to these questions? Cheers, Stefan. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Freeze exception for 'fai'
Hi, On Wednesday 03 September 2008 16:22:44 Cesare Tirabassi wrote: On Wednesday 03 September 2008 16:15:30 you wrote: If you tell me that a freeze exception is not necessary anyways, that's fine with me as well. From what you are telling me it doesn't seem like an additional FFe is indeed necessary; if you get your exception now, you merge your packages from Debian and from then on is only bug fixes. This is just my opinion though, I'm curious to hear what other members of motu-release think. Actually, I beg to differ, from what I've read: Imho, fai changing features with every little release does in fact call for FFe's. However, I do believe that it'd be best to delegate this to Reinhard and Stephan, since I trust both of them to be the ones who have the best knowledge about fai (and packages related to it). However if the result would be the same (i.e. Reinhard and Stephan taking care of fai), then I don't think we need to argue much about specific semantics ;). Cheers, Stefan. -- 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 will revert libgems-ruby to the old state.
Hi Matthias, On Monday 01 September 2008 20:27:27 Mathias Gug wrote: Hi Stefan, On Mon, Sep 01, 2008 at 08:04:06PM +0200, Stefan Potyra wrote: On Monday 01 September 2008 18:21:53 Mathias Gug wrote: Oh, one thing that hasn't been discussed by motu-release is actually the effect on the passenger package, as posted by the server team meeting minutes. In this regard, I'd like to bring your attention however to [1], without further comments. [1]: http://revu.ubuntuwire.com/revu1- incoming/passenger-0808222010/passenger-2.0.3/debian/postinst While this file is there because it's in the upstream tarball, it isn't used. The diff.gz file adds the file debian/libapache2-mod-passenger.postinst [2]. phew, that's good news! :) Maybe you/the packager might want to strip debian out of the upstream tarball then? Cheers, Stefan. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Minutes of motu-release meeting, Friday 29th August, 11.00 UTC.
Minutes of motu-release meeting, Friday 29th August, 11.00 UTC. motu-release members present (4/4): * Cesare Tirabassi (norsetto) * Scott Kitterman (ScottK) * Luke Yelavich (TheMuso) * Stefan Potyra (sistpoty|work) Present on invitation: * Luca Falavigna (DktrKranz) Relationship between ubuntu-release and motu-release: There were no objections raised, that ubuntu-release could also approve FFe's for universe packages in case of need. Scott noted, that ubuntu-release may, but [they] generally ought not to approve universe FFe's. [Note: To reflect this, ubuntu-release was added as a member to motu-release on request from Colin Watson]. ACK's for FFe's: All members agreed to go with 2 ACKs from motu-release for exception requests again, as has been the case during the last cycle. Delegations: All motu-release members were very much in favour to once again have delegates handling relevant subsets of packages. The following flavors have been agreed on to be handled by the following delegates: - Kubuntu: Jonathan Ridell (Ridell) - Mythbuntu: Mario Limonciello (superm1) - Xubuntu: Code Sommerville (code-sommerville) - Mozilla Team: Alexander Sack (asac) - Ubuntu Studio: _MMA_ - Ubuntu Destkop: Sebastien Bacher (seb128) - Ubuntu Mobile: Oliver Gravert (ogra) - Ubuntu MID: Loic Minier (lool) - Ubuntu Server: Scott Kitterman (ScottK) Packages covered by delegations: Scott raised the question, what package sets would be covered by delegates. After a short discussion, it was agreed on that every delegate should reply to this mail with a set of packages to take release responsibility for. In case of overlap, motu-release can then trim down the lists, taking over coordination of conflicting packages. Standing freeze exceptions: To request a standing freeze exception, an email should be sent to the Ubuntu MOTU mailing list for discussions. It is granted, once three members of motu- release have given their ACK. At around 12.00 UTC, Cesare, Stefan and Luca had to leave, so that quorum was no longer guaranteed. The following points where discussed afterwards: Per-Package delegations: In case of need, persons requesting per-package delegations should sent a mail the MOTU mailing list with the request, so that it can be discussed there. Diffstat requirements: Scott raised the point, to get rid of the requirement to add a diffstat. Bugfix only releases: Another point Scott raised, was wether bugfix only releases would need freeze exceptions as well. Misc/personal notes: Luke will be on vacation for the next two weeks. Stefan will be on vacation for the next week. The logs can be found at [1], mootbot wasn't used due to technical problems. Cheers, Stefan. -- [1]: http://irclogs.ubuntu.com/2008/08/29/%23ubuntu-meeting.html -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Minutes of motu-release meeting, Friday 29th August, 11.00 UTC.
Hi, On Monday 01 September 2008 23:33:40 Stefan Potyra wrote: [..] - Kubuntu: Jonathan Ridell (Ridell) - Mythbuntu: Mario Limonciello (superm1) - Xubuntu: Code Sommerville (code-sommerville) ahem, mea culpa, Cody, for getting your name/nick wrong. - Mozilla Team: Alexander Sack (asac) - Ubuntu Studio: _MMA_ - Ubuntu Destkop: Sebastien Bacher (seb128) - Ubuntu Mobile: Oliver Gravert (ogra) - Ubuntu MID: Loic Minier (lool) - Ubuntu Server: Scott Kitterman (ScottK) Finally, I'm not 100% sure who already agreed to accept the delegation during the meeting. If you're on the list and haven't been asked during the meeting, please state if you accept the delegation, or if not, please make a suggestion for a replacement. Thanks. [..] At around 12.00 UTC, Cesare, Stefan and Luca had to leave, so that quorum was no longer guaranteed. The following points where discussed afterwards: [..] Diffstat requirements: Scott raised the point, to get rid of the requirement to add a diffstat. Well, it's partly usuable, to get a quick overview of the amount of changes. However most of the times during hardy, I didn't find the diffstat to be particular useful, so I don't object to dropping the requirement. Bugfix only releases: Another point Scott raised, was wether bugfix only releases would need freeze exceptions as well. Imho we shouldn't need exceptions for bugfix only releases, but it would be nice have it documented (be it either in debian/changelog or via a bug or both). Cheers, Stefan. -- 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 needs you
Hi, On Wednesday 27 August 2008 14:51:37 Luca Falavigna wrote: Stefan Potyra ha scritto: motu-release is short one member, please apply here If nobody nominates, I'd like to apply. ok, there are two advocations, so this application is valid. In case there are objections, comments, questions in regards to this application, please raise them within one week. P.S.: Please also shout if I interpret the new policy wrongly ;). Cheers, Stefan. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
motu-release team meeting today at 11.00 UTC
Hi, sorry for the short notice, date/time was agreed on just at this moment :). motu-release will hold a meeting today at 11.00 UTC, so feel free to step by in #ubuntu-meeting if you're interested. 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 will revert libgems-ruby to the old state.
Hi, and just a personal note from me: One of the problems with the upload was obviously the rush before FeatureFreeze. Please don't rush towards any freeze, having a hard point after which everything is too late seems not like a good thing to me. That's why we had a gradual freeze policy for hardy, and will do so again for intrepid. And in case the gradual freeze policy doesn't address this problem, I'm happy to hear any ideas to alleviate this issue. If this upload was the result of a policy problem in the first place the policy should get fixed imho. Also I'd like to state that I am convinced that all changes were done on good will, in order to make Ubuntu better. I'd like to encourage you who were involved with the upload in the first place, to also look for problems, why this could happen at all. If there are underlying problems in the system (be it freeze or sponsorship or s.th. else), please shout now, ideally with your idea how these could be resolved. Cheers, Stefan. -- 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
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
motu-release needs you
Hi, motu-release is short one member, please apply here (cf. [1] for full procedure). Cheers, Stefan. -- [1]: https://wiki.ubuntu.com/MOTU/Teams/KeyTeamPolicy 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 needs you
Hi, On Wednesday 27 August 2008 14:51:37 Luca Falavigna wrote: Stefan Potyra ha scritto: motu-release is short one member, please apply here If nobody nominates, I'd like to apply. Excellent! I hereby advocate your application. 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
next motu meeting - sep 5th, 20.00 UTC
Hi, today's motu meeting was cancelled due to lack of people present. Following the regular schedule, the next MOTU meeting will take place on Friday, September 5th, 20.00 UTC, in #ubuntu-meeting. 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: libsyck0-dev
Hi Thomas and Alex,
Thomas, Alex asked the following on the ubuntu-motu list[1], so I thought it
would be best to forward it to you:
On Monday 04 August 2008 23:19:53 Alex Norman wrote:
Hi, I'm developing some code with libsyck but I'm using C++, one issue with
the way that the package is built is that one cannot throw a c++ exception
in the syck error handlers and recover in the c++ code.
Basically what happens is that if you throw an exception in the error
handler (which is called by C code) you cannot catch it in a c++ try{}
block, and so your application will terminate.
If libsyck is built with -fexceptions then this problem is solved [and it
only adds 5k to the size of the binary].
I'm wondering if it might be a good idea to build the package with this
option?
-Alex
Alex, Thomas is the debian maintainer for syck, which is synced w.o.
modification to ubuntu as of right now. As I don't have experience with the
syck library, I think the sanest choice for Ubuntu is to follow debian
packaging in this regard.
Cheers,
Stefan.
[1]: https://lists.ubuntu.com/archives/ubuntu-motu/2008-August/004360.html
--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Can't upload to REVU
Hi,
On Thursday 31 July 2008 20:09:30 Matvey Kozhev wrote:
It says:
Error '425 Security: Bad IP connecting.' during ftp transfer of
libbrowserlauncher2-java_1.3.dfsg-0ubuntu1.dsc
hm... interesting, doesn't appear anywhere in the logs (only that the upload
failed). However I'm quite sure that bit in vsftpd is responsible in what
you're seeing:
int
vsf_ftpdataio_get_pasv_fd(struct vsf_session* p_sess)
[..]
/* SECURITY:
* Reject the connection if it wasn't from the same IP as the
* control connection.
*/
if (!tunable_pasv_promiscuous)
{
if (!vsf_sysutil_sockaddr_addr_equal(p_sess-p_remote_addr,
p_accept_addr))
{
vsf_cmdio_write(p_sess, FTP_BADSENDCONN, Security: Bad IP
connecting.);
vsf_sysutil_close(remote_fd);
vsf_sysutil_sockaddr_clear(p_accept_addr);
return -1;
}
}
Now I don't have the best knowledge about networking stuff, but it looks like
the passive ftp data connection seen by vsftpd on spooky doesn't originate
from the same address. The question is what this tells us (maybe someone is
intercepting this connections? s.th. else?) or how to fix it. Maybe using
active instead of passive mode helps? Anyone with better network knowledge
got some more hints?
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: universe-contributors
Hi, On Saturday 05 July 2008 21:10:11 Soren Hansen wrote: On Fri, Jul 04, 2008 at 11:07:00PM +0200, Stefan Potyra wrote: first off, it's great to have a team to grant ubuntu-membership to prospective MOTU's. However I have the feeling, that we create the impression, that being a member of this team is more than just what it is, which is at the moment to indirectly be in the group of ubuntu-members. Imho, that gives a wrong perspective for members of that team, and we should fix this. I'm not sure what you mean? What exactly is you think people expect to achieve by becoming a member of universe-contributors, but don't? I believe that there is expectation to have additional privileges apart from plain ubuntu-membership when being accepted as a universe-contributor. As Nathan already pointed out, this is partly reflected in the wiki page, and I'd like to add that the team description [1] is also a bit misleading. Currently, I have the feeling that we've just added another step in the process of becoming MOTU (and hence prolonged that procedure) even though it doesn't grant practical benefits to be a member of universe-contributors. Now the question however is how to fix this: a) to make it clear that universe-contributors is just ubuntu membership on behalf of MOTU activity or b) to actually hand out additional privileges, ranging from being able to triage bugs to being able to upload a set of packages (as soon as LP can do this). IIRC there were some good ideas back during the initial discussion about universe-contributors, might eventually make sense to revisit these. Cheers, Stefan. -- [1]: https://launchpad.net/~universe-contributors 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: Packaging question
Hi Paul, On Friday 04 July 2008 09:03:28 Paul Gevers wrote: Hello, I am working on packaging a GUI for ffmpeg called winff video and audio batch converter using ffmpeg (see [1]). I requested sponsorship for Debian [2][3] in the beginning of this week as everything looks all right in Debian. Great! Now I try to make a package for Ubuntu, If you get in into unstable, that should not be necessary, we can sync it straight from there then. [..] but I have a problem with the following. This program is written in Free Pascal (Lazarus) and is compiled with the following line: /usr/lib/lazarus/lazbuild --widgetset=gtk2 -B winff.lpr Unfortunately the gtk2 widgetset is not compiled in the lazarus package (it is however in the current unstable distribution of Debian). Hm... we have the same version of lazarus in intrepid as in unstable. [..] Does anybody know how I should handle this? Yes, the right thing is to find out why lazarus in intrepid is different from unstable and to get this sorted out. 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: policy for membership in MOTU key teams
Hi folks, since we're trying out the new MOTU decision making process [1, 2], I'm asking if anyone of you would like to act as a shepherd for this discussion. Since I started the discussion with my initial mail, I guess I'm out due to policy. Nonetheless, I'd volunteer, if noone else would like to step in, and noone raises any objections in this regard until Sunday evening (from an UTC+2 POV). Cheers, Stefan. -- [1]: https://lists.ubuntu.com/archives/ubuntu-motu/2008-June/004060.html [2]: https://lists.ubuntu.com/archives/ubuntu-motu/2008-July/004177.html 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
universe-contributors
Hi folks, first off, it's great to have a team to grant ubuntu-membership to prospective MOTU's. However I have the feeling, that we create the impression, that being a member of this team is more than just what it is, which is at the moment to indirectly be in the group of ubuntu-members. Imho, that gives a wrong perspective for members of that team, and we should fix this. What do you think? 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 Samstag 28 Juni 2008 13:37:06 schrieb [EMAIL PROTECTED]: On Saturday 28 June 2008 00:08:20 Stefan Potyra wrote: Subquestions are: what do you (members of motu-release) would like to add, what did you observer generally in regards to motu-release, what to improve? One thing that irked me, and I would really do something about for Intrepid, was the fact that two positive votes are enough to approve any FFe, no matter if 3 out of 5 members are against it. hm... that implies that we came to (a number of) bad decisions? Do you have the feeling that we performed badly in this regard? (Personally, I recall only one problematic case, and that was the envy issue, where I was the major guilty party, sorry. In retrospect, I guess I wouldn't have acted that way there). I would definitively change this to a majority vote. The problem is that with the current number of members this would require 3/5 to pass which might not be attainable in a reasonable amount of time. Reducing the number of members to 3 (and therefore having 2/3 to pass) doesn't seem a good idea too. So, I'd propose a +2 in a (insert a reasonable amount of time here, 2 days since the date a _valid_ request was filed seems reasonable to me) ? The obvious drawback is that no FFe can be approved before the 2 days elapse, in my view a reasonable price to pay. An alternative would be to have a veto system, in which any member can stop the regular process by simply objecting (obviously with reasonable arguments) against the FFe. In this case the FFe will not be approved until the required majority is obtained. hm... in theory, this is a good proposal, but I have doubts that it will work in practice. Looking back, I've been having a hard time just to keep up with FFe requests in general, so tracking majority votes would even add another burden on motu-release imho. Maybe it could still work though, and I've been thinking about the following since a while: Imho much motu-release work apart from making decisions is also to track FFe requests, pinging the requestor in case there are question unanswered or trying to find requests were no vote from motu-release have been cast since some time or fixing bug status. I guess these tasks could also be fulfilled by other people than motu-release, e.g. bug triagers. I'd also discourage the practice of accepting an FFe on the base of a short IRC chat without apparently any research on the implications and background of the request. Agreed, that makes tracking imho much harder. We have an FFe process so lets make the best use of it (accepting an FFe because your buddy is asking you to do it on IRC, or because somebody you trust is telling you that it will be good to have that package, are not, in my humble view, good reasons to accept an FFe). Fully agreed :). Finally, I always found a nonsense that we have a rather strict system until few days before release and then exactly when we should really tighten the tap, we relax all requirements (its enough to have one IRC approval without sometime even filing a request). Agreed. However very shortly before the release, I guess it's time for motu-release to cherrypick stuff we really think necessary to get in. And especially in the last remaining hours, availability of motu-release members is problematic. Not too sure what's the best approach here, *shrug* 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
Debian Import Freeze
Hi folks, as you might have noticed, we're in Debian Import Freeze (DIF) right now. What does that mean? First off all, quite simply, that automatic syncs of unmodified ubuntu packages from unstable are turned off. However it also means, that we'll need to look a bit ahead towards stabilizing universe, as the first alpha releases are upcoming (alpha1 is already out). This means, that more and more people will be using intrepid, and hence apart from the still ongoing tasks of - get packages merged - clear the sponsors queue - review packages on REVU we now should also look forward to - clear unmet dependencies - check the archive for FTBFS - bring critical fixes from unstable in - fix bugs Also, since autosyncs are turned off, the only way to get a new version from unstable in is to file a sync request. However please don't overuse this feature just because there is a new unstable version, but rather take a look if there are really changes worth to be picked up. Thanks, 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, first off, I'm happy that all motu-release members are ok to go for intrepid as well. Imho it was a good working team during hardy, and has fulfilled its purpose well. Nonetheless, I believe it's also important to look at things that didn't go so well, and I'd like to start this with some personal observations regarding members of motu-release. Please don't get me wrong here, I don't want to flame anyone here, as I believe all motu-release members did a great job, but it's imho important to also point out what still could be improved. Everyone please also post your observerations in regards to motu-release in this thread. So, that's what I've been observing: Imho the most driving force of motu-release was Scott, thanks a lot! We wouldn't have managed the release without you. Cesare also did a good job at working through motu-release bugs, though sometimes he was lacking activity. (not too sure why, my guess is that Cesare felt he couldn't make a decisions for some packages. Hey the worst decision is to not make one, and have FFe requests unanswered ;)) Sarah, while having great skills and knowledge, I've seen rarely activity in regards to motu-release/FFe's. Luke, the same I wrote in regards to Sarah applies as well. So my question still stands: what do we do with motu-release for intrepid. Subquestions are: what do you (members of motu-release) would like to add, what did you observer generally in regards to motu-release, what to improve? Finally, would anyone new like to apply for motu-relase, and what would he/she think to add to the team? 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
REVU: mi2svg (0.1.6) uploaded.
Hi, Format: 1.8 Date: Tue, 17 Jun 2008 16:15:56 +0300 Source: mi2svg Binary: mi2svg Architecture: source Version: 0.1.6-0ubuntu1 Distribution: intrepid Urgency: low Maintainer: Ubuntu MOTU Developers ubuntu-motu@lists.ubuntu.com Changed-By: Toni Ruottu [EMAIL PROTECTED] Description: mi2svg - a tool for creating svg presentations of Mapinfo mif/mid maps Launchpad-Bugs-Fixed: 199633 Changes: mi2svg (0.1.6-0ubuntu1) intrepid; urgency=low . * Initial release (LP: #199633). Checksums-Sha1: 03a3ca8aedb6762f32cfbddabea8aa72f6766927 1097 mi2svg_0.1.6-0ubuntu1.dsc 04e45c0fe0aa2aa644a5bebaf0e8124e6025762e 22969 mi2svg_0.1.6.orig.tar.gz 2c5e530f9bce2519e7bc8a80ed0a7133635982f0 1507 mi2svg_0.1.6-0ubuntu1.diff.gz Checksums-Sha256: 8fa519fac41624d3009cc84e0fec53693c76784c8794eadcd8c04751431c5bb9 1097 mi2svg_0.1.6-0ubuntu1.dsc 1dd9ead3f7d3707929ae775d45f98d6a2ba46beaf79a47d635f9235d1057165c 22969 mi2svg_0.1.6.orig.tar.gz 372b85e0c4c17d4732b6b8dcd3505fbe2ddacb4ef59604c14b5d1adc7aa9e146 1507 mi2svg_0.1.6-0ubuntu1.diff.gz Files: a7ba60d54e6e148cb33250e102a46e59 1097 graphics optional mi2svg_0.1.6-0ubuntu1.dsc 4387877bb1162cb6eb57c2b39e11e94d 22969 graphics optional mi2svg_0.1.6.orig.tar.gz 2f889d4fc567ed5b49dd0c2b5c9434fe 1507 graphics optional mi2svg_0.1.6-0ubuntu1.diff.gz Original-Maintainer: Toni Ruottu [EMAIL PROTECTED] 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
merges free for all?
Hi folks, we're getting closer and closer to DebianImportFreeze, which is scheduled next week[1], and we still have a big number of oustanding merges. Hence I'd like to propose that everyone works towards getting merges done, regardless who did the last merge/upload. Of course checking bugs in LP (there are some debdiffs waiting in the sponsors-queue) should always been done first. What do you think? Cheers, Stefan. -- [1]: https://wiki.ubuntu.com/IntrepidReleaseSchedule 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: merges free for all?
Hi Iain, Am Mittwoch 18 Juni 2008 14:14:36 schrieb Iain Lane: [..] Can we assume that the advice in the thread from the Hardy cycle[1] is still valid for us now? Right now we haven't reached DebianImportFreeze yet. Generally I think most bits should still apply after DIF. I'll bring that up again, once we've reached DIF, ok? Iain [1] https://lists.ubuntu.com/archives/ubuntu-motu/2007-December/thread.html#288 8 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 Decision Making Process
Hi, thanks Scott, for bringing this up! Am Montag 16 Juni 2008 21:47:16 schrieb Scott Kitterman: It has seemed to me for some time that making decisions about process and policy changes at MOTU meetings based on votes of those present is not serving us particularly well. The major problems with the current system, as I see it are: 1. Not very many MOTU at the meeting, so a vote may or may not represent the will of the larger body of MOTU (due to time zone spread it is not practical to expect everyone to be able to make every meeting). 2. Due to this risk, MOTU present at a meeting are often unwilling to make a decision on controversial issues. So we tend to get decisions on easy topics and not on hard ones. hm... imo it also depends on who hosts a meeting, if a harder decision is taken or not. However I don't think that's necessarily an argument in favor of the current procedure. I'd like to propose an alternative approach based on the IETF rough consensus model. There are two major features I'd like to bring foward from this model for MOTU: 1. Decisions need to be made by achieving rough consensus rather than by 51% vote. I think working together to develop an answer to a problem that most everyone can agree to is a more Ubuntu way than holding a vote that can leave only slightly less than half the people unhappy. http://en.wikipedia.org/wiki/Rough_consensus 2. Decisions must be ratified on the appropriate mailing list. Discussions at a meeting are good and necessary, but the mailing list has the final say. This is important so that all time zones can be represented and missing a meeting doesn't leave people out. If a process or policy is needed, my proposal would work something like this: 1. Someone makes an announcement to the MOTU ML describing the problem and the proposed solution (much like this mail). 2. MOTU discuss on the ML. 3. The issue is on the agenda for the next meeting. It's discussed at the meeting and someone other than the person asking for the change is appointed to guage the consensus on the issue. 4. Meeting minutes get published that include the issue, a summary of the discussion, and who is appointed to guage the consensus. 5. More discussion on the ML the selected person tries to guage the rough consensus of the group. 6. That individual announces if rough consensus has been achieved. If so, the change is approved, if not, more disucssion and new proposals. 7. Anyone who feels strongly that the consensus call was wrong, can appeal to the MOTU Council who would have oversight over the process. [..] sounds pretty good to me. Two comments: - For real uncontroversial issues, I don't really think the ping pong from mailing list to meeting back to mailing list is needed (take motu-sru membership discussion as an example -- even though that's not a very good example for us coming to a decision fast *g*). - I guess if there are really controversial issues, we'd not be able to come to a decision regarding those with this model? Maybe it should also be possible to call for a vote after a certain time when no outcome is reached until then? Anyway, excellent proposal! 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 Samstag 14 Juni 2008 00:29:16 schrieb Stefan Potyra: Hi folks, I'd like to ask you how we want to proceed with the motu-release team. Keep the team as is for intrepid, or do a new call for applicants or s.th. else? since there has been no response so far, let's try the other way round: Cesare, Luke, Sarah, Scott: Are you up for intrepid as well? Personally, I'd be happy to go for another cycle. 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
motu-release
Hi folks, I'd like to ask you how we want to proceed with the motu-release team. Keep the team as is for intrepid, or do a new call for applicants or s.th. else? 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: REVU don't want my package
Hi Julien, Am Dienstag 10 Juni 2008 21:36:00 schrieb Julien Dehee: Hi, I'm new to the whole Debian/Ubuntu packaging process. I've made a package (flabber) after answering a need-packaging from the mentoring section. Everything went well, except for the upload to REVU. I followed the tutorials very carefully and got no errors, but my package doesn't show up on http://revu.ubuntuwire.com [..] Can anyone help me on that one ? REVU's keyring wasn't synced yet. I've done a sync now and put back your package from the rejected to the incoming queue. Looks like it got already processed and is displayed on revu now ;). 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: tk-brief: broken dependency in hardy
Hi Oliver, Am Samstag 07 Juni 2008 17:12:46 schrieb Oliver Stuch: Hi there,, have you already seen https://bugs.launchpad.net/ubuntu/+source/tk-brief/+bug/220910 ? Would you please fix the bug. Would be great! fixed in intrepid, for hardy I'll still need an ACK to go ahead with the SRU. Side note: please don't use tk-brief, it's crack. You're much better off with using e.g. g-brief/g-brief2 directly in a plain latex file (been there, done that ;)). 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: mplayer should be moved to universe
Hi, (CC-ing ubuntu-devel for clarification) Am Samstag 31 Mai 2008 23:03:32 schrieb Michael Bienia: As mplayer and mencoder are build from the same source package, it's not really easy to put them into different components (universe/multiverse). I'm not sure if it's allow that a source package from multiverse can built a package for universe, but my guess would be that it's not allowed. actually, this seems to be possible, at least based on comments from Colin on irc (see [1], somewhere after 19:18). Moving the source package to universe and put mencoder into multiverse isn't probably possible either: I didn't check if mplayer has some build-depends from multiverse (which would prevent putting mplayer source into universe) or if it's possible to put the source into universe at all (due to the patents as afaik that's a reason why it's in multiverse). hm... if only patent issues are a problem, I'd like to know what patents can actually cover. If patents only limit usage, but not distribution, I see no problems with putting mplayer sources in universe, and building binary mencoder packages in multiverse. Can someone clarify this? Cheers, Stefan. -- [1]: http://irclogs.ubuntu.com/2007/10/23/%23ubuntu-devel.html 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
motu-sru extension
Dear MC, please set up polls for extending motu-sru/replacing retired members [1]. Daniel, maybe you'd also like to transfer team ownership to MC (see [2]). Candidates: Stephan Hermann [3] Scott Kitterman [4] Cody A.W. Somerville [5] looks, like we need two members (follow-ups to [1]), but that might be subject to discussion. Thanks, Stefan. -- [1]: https://lists.ubuntu.com/archives/ubuntu-motu/2008-May/003873.html [2]: https://lists.ubuntu.com/archives/ubuntu-motu/2008-May/003963.html [3]: https://lists.ubuntu.com/archives/ubuntu-motu/2008-May/003912.html [4]: https://lists.ubuntu.com/archives/ubuntu-motu/2008-May/003954.html [5]: https://lists.ubuntu.com/archives/ubuntu-motu/2008-May/003961.html 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: wanted: motu-sru members
Hi folks, Am Freitag 23 Mai 2008 15:48:31 schrieb Stephan Hermann: [..] Count me as candidate... \sh so it's Friday now, and Stephan is the only candidate so far (thanks again for volunteering, Stephan!). Imho voting doesn't make too much sense to me for this case, given that we don't have much choices. If you however still want a vote, or believe, that we should follow a different procedure *for this particular case* please reply until Monday evening. Otherwise I'd ask that Stephan gets added to motu-sru on Tuesday. 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: wanted: motu-sru members
Hi again, thanks for more volunteers. Siegfried: Having no big track of sru history doesn't imho warrant that you couldn't be a member of motu-sru. Do you also volunteer? So, how do we proceed now? I'd say, we extent the deadline until tomorrow (31.05.08), 20.00 UTC. If there should be more than two volunteers (it looks like we need to replace two members right now), I'd call for a vote then. Otherwise, let's just add the members to the team on Monday, at 20.00h UTC unless anyone disagrees with that. Any objections? 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
don't use bug tasks for transitions
Hi folks, as overheard on #ubuntu-devel today, please don't use one bug with many different tasks for transitions. The problem with this is, that any subscriber of an affected package will get every mail for a change in that bug (in short: [he/she'll get] zillion mails [in which he/she has] no interest in[1]). For what tasks are not meant to be used, I'll give you this quotation: if the fixes required would be independent, they should be separate bugs [2] Finally, one option to handle transitions via LP was also proposed: it's easier to file [separate] bugs and tag those [3]. Cheers, Stefan. -- [1]: two quotes mixed up here from seb128 in #ubuntu-devel [2]: cjwatson [3]: seb128 (cf. http://irclogs.ubuntu.com/2008/05/30/%23ubuntu-devel.html). 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
one-a-day
Hi folks, looking at what needs to be done currently, I see that we 1) need to clear the sponsors queue [1] and 2) merge packages and also 3) need to also look at new packages via REVU Due to the recent popularity of similar actions, I'd like to start an initiative myself: One-a-day :) So you're a MOTU? please either review one debdiff from the sponsors-queue [1], merge one package as seen on[2,3] or review one package on REVU [4] every day. That should help us clear the queues as soon as possible. Feel free to do more than one a day though, or less, as long as you do it :). Cheers, Stefan. -- [1]: https://bugs.launchpad.net/~ubuntu-universe-sponsors/+subscribedbugs [2]: http://merges.ubuntu.com/ [3]: http://dad.dunnewind.net/universe.php [4]: http://revu.ubuntuwire.com/ 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: don't use bug tasks for transitions
Hi, Am Samstag 31 Mai 2008 02:01:56 schrieb Scott Kitterman: On Sat, 31 May 2008 01:14:16 +0200 Stefan Potyra [EMAIL PROTECTED] wrote: Hi folks, as overheard on #ubuntu-devel today, please don't use one bug with many different tasks for transitions. The problem with this is, that any subscriber of an affected package will get every mail for a change in that bug (in short: [he/she'll get] zillion mails [in which he/she has] no interest in[1]). I think this is an unfortunate aspect of the curent LP design. Can you elaborate on this? (as Sebastien already noted on irc, one might be interested in comments to fixed bugs as well. So I personally don't see a design, which would fix this... of course I'd be happy to get good ideas on this). For what tasks are not meant to be used, I'll give you this quotation: if the fixes required would be independent, they should be separate bugs [2] I don't understand. By definition all packages that need changes to fix a bug will be different. If I understand this statement, then also affect should never be used for different packages. This isn't what I would have expected. Let me give two examples: perl transition: you can upload each package individually, so these should be two different bugs. OTOH, you might want to look at bug #59945 (which I wrongly never added a task for nvidia-settings). This was only fixed by updating both nvidia-settings and sensors-applet. (sorry, you'll need to dig in the bug comments probably to find out the problem for this example.) Finally, one option to handle transitions via LP was also proposed: it's easier to file [separate] bugs and tag those [3]. Tags have their own problems (see recent discussions on ubuntu-devel). I'd say it's much harder. One mass bug is one email. One bug per package is one email per package. The problem afaict is that mass bugs generate email, for each package, even if this package is already fixed. And yes, tags have their own problems. That's why I wrote that it could be one option. I'd be eager to hear what other solutions exist for this problem. I don't think LP currently offers a good solution for this type of problem. This may very well be true ;). 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
wanted: motu-sru members
Hi, I'd like to call for volunteers to supplement the motu-sru team (see [1]). Requirements: * have a good understanding of the SRU process * being able to work together with current team members * ability to read and judge patches If you're up for it, please reply to this thread. @motu-sru: Once we have a number of applicants, can you select whom you'd like to see in your team? Cheers, Stefan. -- [1]: https://lists.ubuntu.com/archives/ubuntu-motu/2008-May/003873.html 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: wanted: motu-sru members
Hi, Am Freitag 23 Mai 2008 16:11:30 schrieb Scott Kitterman: Stefan Potyra wrote: @motu-sru: Once we have a number of applicants, can you select whom you'd like to see in your team? Shouldn't that be voted by the entire MOTU team? We need a clear process about this... (/me goes and adds it to the motu-processes Gobby document) I agree. That's how we've been appointing members lately. I vote is needed. To be honest, I don't mind too much how it is done, as long as it is done soon. How about the following: 1) applicants reply in this thread 2) motu-sru does a preselection 3) we'll vote on the result Regardless of all, 1) needs to happen anyways, so please don't hesitate to reply if you are volunteering. 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: wanted: motu-sru members
Hi, Am Freitag 23 Mai 2008 18:53:25 schrieb Scott Kitterman: Emilio Pozuelo Monfort wrote: What is the benefit of 2) ? Can't the MOTU team do the selection in the voting? If there's some people motu-sru would remove, I would hope for the MOTU team to remove them too in the voting. The large benefit of allowing the existing members of motu-sru to select amoung the volunteers is to ensure that the team works well together. If there is a removal with which MOTU disagree, such objection ought be raised in response to the motu-sru publication of the candidates. heh, yeah... and since my request is for additional members to an existing team, I guess it's polite to ask them. While I can't be entirely sure, I suspect there will be time between the publication of the slate of candidates and MOTU Council configuring the appropriate polls for selection. I am strongly opposed to pre-selection. We have had cases in the past where a non-transparent pre-selection process resulted in a very limited and from the perspective of at least a significant slice of the community very unsuitable set of choices. Ok, let me make s.th. clear: My proposal so far is aimed at *one* particular goal. To get motu-sru back to full strength *now*. It is *not* meant as a general policy for handling membership for motu key-teams. As Emilio noted in the gobby document, we need a good general policy, and I fully support this idea. However for this particular case (and that's why I didn't write s.th. about a MOTU vote in my initial mail), I just don't expect that there will be much to discuss. So far, only Stephan volunteered (thanks!), so unless more people will also volunteer, there won't be even much to vote about ;). So maybe we can agree to the following: - everyone volunteering to back up motu-sru please reply in this thread - in one week (Friday, 30th of May), we'll see how many applicants we have - and then we'll decide how to proceed, and if s.th. is worthwhile to vote on (which I really don't expect so far, but I hope you all prove me wrong by volunteering for motu-sru ;)). And for the general discussion about membership in key teams: I'll start a new thread about that, so please use that thread instead. (hah, so at least I invented a new tongue twister *g*.) 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
policy for membership in MOTU key teams
Hi, as evolved by the discussion for motu-sru members, I guess it might make sense to have a good general policy. First off, what key teams do we have? - motu-sru - motu-release - motu-council* what else? [*]: There already is a policy. What is good, what is bad about it? Policy proposals: - what worked good so far - what needs improvement - any good idea? Please discuss ;). 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
motu-sru extension?
Hi folks, with the sad news, that Jordan needs to focus his work on his PhD thesis (good luck, Jordan!), I'm curious if motu-sru could benefit from additional member(s)? motu-sru, what do you think? 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: call for REVU admins
Hi, Am Montag 12 Mai 2008 12:35:03 schrieb Stefan Potyra: Hi, as intrepid is open, and REVU sees more and more uploads, I'm calling for help with managing the REVU instance. Excellent, thank you all for your offers to help. @Matt Darcy and ZhengPeng Hou: I'm sorry, since both of you are no (or no longer) MOTUs and we imho have enough MOTUs who'd like to help, I'd prefer to not grant you access to spooky. Others than that, I'm happy with everyone, hence I'm handing this list over to UWSA to create the accounts on spooky (and I guess check for ssh-keys as well, due to the recent incident). Thanks in advance! Basically, almost all tasks should be doable with rights of the revu1 user (like cleaning up the incoming queue, syncing the keyring, creating accounts etc). However IIRC processing removals still requires root privileges. So please hand out accounts with necessary sudo privileges as you see fit (which also means to not hand out an account at all, if you're not comfortable with someone). Here's the list with names and LP ids: Emmet Hikory (persia) Sarah Hobbs (hobbsee) Raphaël Pinson (raphink) Richard Johnson (nixternal) Morten Kjeldgaard (mok0) Jonathan Patrick Davies (jdavies) Oh, there is no real manual for revu adminning... the best we have so far is: https://lists.ubuntu.com/archives/ubuntu-motu/2008-March/003470.html 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
call for REVU admins
Hi, as intrepid is open, and REVU sees more and more uploads, I'm calling for help with managing the REVU instance. Standard jobs to be done is to sync the keyring from time to time, to process nuked packages on spooky (so that these are really removed from the server's disk), and to clean up the uploads-queue from binary uploads and/or clutter (and sometimes put back rejected uploads after the key got picked up from a keyring sync), and finally to manage account privileges of REVU (e.g. if we have new MOTUs). Requirements: * be trusted by UWSA to be let on spooky * being able to execute a few simple shell commands there * spent some time on irc to answer pings regarding REVU problems So if you want to help, please reply in this thread. 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: login problems
Hi Henrik, Am Sonntag 11 Mai 2008 14:28:50 schrieb Henrik Stokseth: i have a problem logging in. i lost my GPG-key and created a new one. unfortunately it seems the REVU service doesn't allow password recovery using this new key. can you reset the user account or something? Thanks. Sincerely, Henrik Stokseth. I've updated REVU's keyring, so that it now uses your new key instead of the old one. 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: RFC: Sponsor Day
Hi, Am Samstag 10 Mai 2008 20:36:10 schrieb Nicolas Valcarcel: Hi, Last week we have had Ubuntu Open Week, conference which makes a lot of people get involved in ubuntu development, starting, as i think everyone has, on universe. No one of them as access to the servers, so everyone needs sponsorship, and the queue is growing and growing. The problem with this is that new contributor aren't seeing their work uploaded, and that can be frustrating for them, at least for the first packages it always is. So what i'm purposing is, as we have REVU days before FF, i purpose to have Sponsor Days before DF, so we can have a lot of contributors work reviewed and sponsored, si they get motivated and more involved on the project. do you mean that the ubuntu-universe-sponsors queue is growing (as I've seen not too many uploads to revu recently)? If so, I guess that's a very good thing! 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: Stefan Ebner (sebner) is now an Ubuntu Universe Contributor
Hi, Am Samstag 10 Mai 2008 18:15:20 schrieb Emmet Hikory: MOTU, I am happy to announce that Stefan Ebner has been approved as a Ubuntu Universe Contributor. Although Stefan has only been working with development since January, his focus on pulling the best of changes from Debian and reducing the Hardy RC bug count led him to achieve 134 uploads in the Hardy cycle, becoming the 21st most active developer by upload count. Please give him a warm welcome to the development team. woohooo... congrats to Stefan for being the first one, and congrats that member applications can finally get progressed :). 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: package libsuitesparse missing, makes fenics not installable
Hi. On Monday 28 April 2008 16:42:57 Chong Luo wrote: After upgrading to Ubuntu 8.04, I can't install fenics (http://www.fenics.org/wiki/Download). I found that the problem is that fenics depends on libdolfin, while libdolfin depends on libsuitesparse, which is not available in the repository, instead there is only this libsuitesparse-3.1.0 available. please report bugs regarding 3rd party repositories to the people hosting these, as we cannot support 3rd party repositories. Maybe we can create a transition package with the name libsuitesparse? In short: No, having such a package would be a bug. (The explanation why would be a bit lengthy, so I'm skipping this for now.) 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: Ubuntu Universe Contributors
Hi, On Monday 21 April 2008 16:34:18 Emmet Hikory wrote: [..] Consider the possibility that there exists a set of privileges that are both normally open to all after self-election, would be useful for those interested in becoming involved with development, and can be controlled through a Launchpad group (either directly or indirectly). Having this set of privileges collected into a single group allows would-be members of the development effort to gain all appropriate access with a single membership, rather than having to track down each specific permission group individually. Further, such a team allows for a single, accurate, label to indicate those so interested, and further provides an answer to the frequently asked question What do I have to do to get involved in development, that being to join the team, and dig in. This may be perceived as an improvement over the current answer, to simply get started, with new developers seeking additional permissions one-by-one as they discover things they are unable to do without membership in the several relevant permission-granting teams. aha, thanks for clearing it up. What other privileges are planned? 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: NEW Packages process
Hi, On Wednesday 16 April 2008 10:45:22 Daniel Holbach wrote: Hello everybody, after a recent discussion about a perceived disconnect between main processes and universe processes, I thought a bit about the process for NEW Packages. Historically it was introduced to make sure that new packages are of tip-top quality when they enter the archive. We started with 3 necessary ACKs and changed it to 2 ACKs for non-MOTUs and encouraged MOTUs to get an ACK from other MOTUs. I feel we've been very successful with the work we've put into Universe and the quality of new packages. I propose the following changes: 1) cut down the requirement to one ACK of a ubuntu-dev member I don't think, that's a good idea. One argument against it raised in the past is, that this might lead to fewer people reviewing a package (or giving an ACK for a package), as they might be unsure about it. Actually, I believe that reviewing a package is actually a more difficult task then to create a new package from scratch, and so I think that this argument might still be true. As I've often cherrypicked reviews in the past (that is reviewed packages, which had one ACK already), and very often found issues with these, I fear that the package quality might get worse, and the rejection count from ubuntu-archive might increase. Now I wouldn't think, that I'm a so good reviewer, but rather that this is basically just, because different people spot different issues in packages. Overall, I believe we should encourage non-motus to go for reviews, now that anyone can comment on REVU to weed out basic packaging problems. The only downside to this is imho, that sometimes pseudo-knowledge starts to spread about issues of a package (I've seen wrong comments in the past, which got picked up by other reviewers and got commented to other packages. I'd need to look a little bit, to find concrete examples of this happening though). 2) requirement for the person who packaged the new software to become bug contact Yes, that sounds very good! 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: NEW Packages process
Hi, On Wednesday 16 April 2008 12:07:46 Daniel Holbach wrote: Stefan Potyra schrieb: One argument against it raised in the past is, that this might lead to fewer people reviewing a package (or giving an ACK for a package), as they might be unsure about it. Maybe the right fix for this the situation is to establish an easy way to - solicit feedback about a packaging situation one is unsure about Maybe I don't understand what you are meaning: I thought reviewing was that feedback? - document the best way to solve problem X either in https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews or https://wiki.ubuntu.com/PackagingGuide Having recipes, how to solve a problem is imho orthogonal to the question of reviewing. It's good to be able to point people to these, if they have questions on how to do it, but in my experience, that's not the problem when reviewing a package. Also, from my experience, usually many different solution to a problem X exist, so I guess saying that there is a best way might even result in reviewers stating s.th. like: do it that way, even if it's equally right to be done differently. (cdbs vs. plain debhelper for example). (Side note: since when became the guideline criteria in CodeReviews stable? There used to be a note stating that these are not stable and links to the ml discussion in the wiki page which are gone now). I can see a number of additional benefits in this solution. As I've often cherrypicked reviews in the past (that is reviewed packages, which had one ACK already), and very often found issues with these, I fear that the package quality might get worse, and the rejection count from ubuntu-archive might increase. Also in this case a feedback loop would help to educate the whole team. Do you mean feedback loop from ubuntu-archive to reviewers? Yes, that would be very good! 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: NEW Packages process
Hi, On Wednesday 16 April 2008 12:31:59 James Westby wrote: On Wed, 2008-04-16 at 11:38 +0200, Stefan Potyra wrote: One argument against it raised in the past is, that this might lead to fewer people reviewing a package (or giving an ACK for a package), as they might be unsure about it. Actually, I believe that reviewing a package is actually a more difficult task then to create a new package from scratch, and so I think that this argument might still be true. As I've often cherrypicked reviews in the past (that is reviewed packages, which had one ACK already), and very often found issues with these, I fear that the package quality might get worse, and the rejection count from ubuntu-archive might increase. Now I wouldn't think, that I'm a so good reviewer, but rather that this is basically just, because different people spot different issues in packages. Hi, Do you think that this could perhaps be because some people don't review the package as thoroughly as they know that someone else will look at it first? From my experience: No, I don't think that people were less thorough with a review just because someone else would look at a package, but rather ... Increasing the quality of reviews is great, but just having a second reviewer doesn't necessarily guarantee that. As well as each reviewer knowing that someone else will look, the responsibility is diluted. If I were to miss something in a review when I was the only reviewer then it would be my omission, but with two reviewers both missed it, so it's not really one persons fault. ... yes, exactly. 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
