Kubuntu Desktop Bugs Week!
Hello Kubuntu fans, With a bit over a month left until Feisty is released, it's a great time to sort out bugs and polish up the desktop. We are having a week of bug triaging focusing on Kubuntu Desktop applications, inspired by a similar effort by the Ubuntu Desktop Team. Every day the week of Monday March 12 through Friday March 16 we will pick a major application/package in the Kubuntu Desktop and triage (and maybe fix!) as many of its bugs as we can. With enough people helping, we can get all the bugs in major desktop components sorted out and fixed. Everybody can help! More information, tasks, bug lists, and a schedule are here: https://wiki.ubuntu.com/KubuntuTeam/Bugs There is lots of information on how to triage there too, so please read that page and stop by #kubuntu-devel and #ubuntu-bugs on IRC and help out! ~ Yuriy Kozlov -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: gstreamer-ffmpeg package - incorrect description
Firstly, sorry I'm not replying directly to the thread, I was not subscribed to the list... > Actually, FFmpeg can also decode "DivX 3.11 ;-)" videos that have been > encoded by a hacked version of Microsoft pre-standard MPEG4 codec, which > is _not_ (100% identical to) "MPEG-4 ASP video". This codec and its > "nickname" predate the commercial DivX company/trademark/codec. As you may notice, DivX ;-) is not DivX. Just like DivX is not DIVX: 1. DivX ;-) was a name of a hack of the MS MPEG-4 v3 codec. What FFmeg can also decode is therefore MS MPEG-4 v3 video. 2. DIVX was a name of the failed DVD rental system. 3. DivX is a brand name of products of a company of the same name. It is their trademark. You are right - "DivX ;-)" and "DIVX" cannot be their trademarks. But DivX is: http://www.divx.com/company/about/trademark.php "The DivX and Stage6 brand names and logos are owned solely by DivX, Inc. and their use is limited to DivX and its licensed partners." Products made by the DivX company have the DivX brand name. Anyhing else than DivX is not and cannot be called DivX. Again, I strongly recommend reading the Wikipedia article, it's all explained there. > What you mean by "the MP4 container format" is based on QuickTime (a > subset of it is the MPEG-4 standard's container format IIRC). I know very well what I mean by that. MP4 is the standard MPEG-4 container specified in MPEG-4 Part 14. > AVI is not a standardised container format for MPEG-4 and in fact, Microsoft While this is all true (I never said AVI was a standard container for MPEG-4 ASP video, but it is very widely used for storing MPEG-4 ASP video anyway), this is completely irrelevant to the point I'm making - the package description is simply wrong. FFmpeg or the FFmpeg plugin cannot encode and decode DivX because: 1. DivX is not a format of a video stream (the thing codecs encode and decode) 2. FFmpeg does not support DivX 3. DivX is a brand name of irrelevant commercial software products 4. Software product and format are two different things So I ask you to remove the wrong description, because it's simply wrong. Thanks, Jakub Misak -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: [ubuntu-motu] Re: KDE 4 uploads to universe
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 john levin wrote: > I recall that there were plans for Ubuntu having a 'Sid'; an unstable > version precisely for this sort of situation. (Wasn't it going to be > called Grumpy?) Has anything come of this, or has the idea been dropped? I believe the current status is that it is pending on Soyuz being capable of it, like many of the other features that we'd like have been for the past year or two. > It strikes me that KDE4 is an example of something that will probably > re-occur: incorporating long-term development cycles and alpha packages > into the K/Ubuntu release process. Grumpy would probably be a very good place for KDE4 to go at the moment, however we don't have such a thing at the moment (/me kicks LP a bit). William. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFF8dD8Ac+S8KckfcURAjUeAJ9yzdzgFpi/zEiUwMt71d5O4qJkgwCdHNYq k+CxzeEj1Hc2f+yyk4D0hAc= =1u0m -END PGP SIGNATURE- -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: gstreamer-ffmpeg package - incorrect description
On vr, 2007-03-09 at 08:02 +0100, Jakub Misak wrote: > There's incorrect description displayed for the gstreamer-ffmpeg package > (FFmpeg plugin for GSstreamer). It says it can be used for encoding/decoding > the DivX format (or even "play divx"). This is wrong, and in case you don't > know why (most people don't understand what DivX is, there's a lot of > confusion and intentional misinformation about this topic), I'd like to > explain it in more detail. [...] > Now, this common confusion stems from the fact that most people don't > know that DivX is not a format - the DivX codec (which is what most > people call "DivX", along with video encoded with this piece of > software) is a proprietary software product that encodes and decodes > standard MPEG-4 ASP video. That is, video encoded with this codec is > not "DivX video" or "DivX", it is standard MPEG-4 ASP video. Actually, FFmpeg can also decode "DivX 3.11 ;-)" videos that have been encoded by a hacked version of Microsoft pre-standard MPEG4 codec, which is _not_ (100% identical to) "MPEG-4 ASP video". This codec and its "nickname" predate the commercial DivX company/trademark/codec. > Another confusion is that while the MPEG-4 ASP video must be stored in a > container format (usually AVI or MP4), What you mean by "the MP4 container format" is based on QuickTime (a subset of it is the MPEG-4 standard's container format IIRC). AVI is not a standardised container format for MPEG-4 and in fact, Microsoft dropped MPEG-4 support because they were pissed about losing from Apple--they proposed the WindowsMedia container instead of QuickTime. > So, there is no way the description could be considered correct. FFmeg has > nothing to do with DivX. That's why I would like to ask you to correct it, > because wrong descriptions like that confuse a lot of people, make a lot of > damage (even to FFmpeg itself) and the trademark issue itself is quite clear. I can't see how any company can claim the "DivX" trademark, considering that _at least_ two other video products used the same name before them, and they didn't buy the rights from those people... -- Jan Claeys -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: KTorrent 2.1.2
http://revu.tauware.de/details.py?upid=4557 -- Rich Johnson [EMAIL PROTECTED] GPG Key: 0x2E2C0124 pgpREU55jXd4A.pgp Description: PGP signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
KTorrent 2.1.2
http://lists.kde.org/?l=kde-announce&m=117346514411140&w=2 This was just announced a few minutes ago. I am in the process of building the current package now. -- Rich Johnson [EMAIL PROTECTED] GPG Key: 0x2E2C0124 pgpZCbfOQJ5tI.pgp Description: PGP signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: [ubuntu-motu] KDE 4 uploads to universe
On Fri, Mar 09, 2007 at 11:10:40AM +, Jonathan Riddell wrote: > If Jeremie Corbier is reading, please reply to this thread if you have > a point to make and please do not flame me in your blog. There is a > reason we have mailing lists and IRC, blogs are not a replacement. > > Having KDE 4 packages is a good idea because it helps people see the > current state of KDE 4 and hopefully help out from there. It ensure > we have good quality packages when KDE 4 releases rather than hoping > upstream will magically fix all the problems without us having to even > look at it, then we package for the first time on the day of release. > > Feel free to disagree with that but do so in the correct place. > Flaming me seems to be your entire contribution to Planet Ubuntu, I > recommend you remove your blog if that is the most constructive thing > you have to announce to the world. My sincere apologies if you felt like my blog post was an attack towards you or any other member of the Kubuntu development team. I did not mean it to be offensive at all. The reason why I used a blog post instead of an email on this mailing-list is that I think people deserve the right to know what's happening during the development of their OS and I feel like planet.u.c has a wider audience than this maling list. Besides I had nothing to add to what had already been said in previous emails and did not want to clutter the list with a "me too" email. Cheers, -- Jeremie /* ``Cryptography is nothing more than a mathematical framework for discussing the implications of various paranoid delusions.'' -- Don Alvarez */ pgpj1rf6rV9bL.pgp Description: PGP signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Universe Bug Triage
Hello everybody, I'm very very very happy with how the Universe Hug Day goes from now. We have quite some fodder for MOTU hopefuls now: * Bugs marked as 'packaging': http://tinyurl.com/368977 * Bugs marked as 'bitesize': http://tinyurl.com/2us2se Some other observations: * there are lots of irrelevant and obsolete bugs: if we all spend an hour on bugs sorting the Universe/Multiverse list by "oldest first", we will be able to clean up a lot of them. * I added an 'upgrade' tag - lots of bugs request a new upstream version of a package, some are already fixed and some need to get reviewed/rejected/postponed. * lots of easy bugs, lots of things we should forward to the upstream authors. Being so pleased, I took the liberty of adding a fixed item reading "agree on date and time of next Universe HUG DAY" to our MOTU meetings. Thanks for helping with the HUG DAY and let's keep working on them. Have a nice day, Daniel 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-motu] Re: KDE 4 uploads to universe
Jonathan Riddell wrote: > On Fri, Mar 09, 2007 at 12:41:32PM +0100, Reinhard Tartler wrote: > >> I understand that you all like to have always the latest stuff in the >> archive, espc. when it's doesn't affect any existing installations >> and/or packages. However I feel that it would help the feisty release >> more, if the time and energy which is put into these KDE4 package was >> devoted to the KDE3 packages. However, since I don't want to tell anyone >> what do do, and everyone is free to work on any project he wants, I >> don't have strong objections either. My concern is rather that having >> KDE4 distracts developers and users from using, testing and fixing the >> existing KDE3 packages. > > The packages help upstream developers as well as ensuring Kubuntu is > ready for KDE 4 when it does get released. > I recall that there were plans for Ubuntu having a 'Sid'; an unstable version precisely for this sort of situation. (Wasn't it going to be called Grumpy?) Has anything come of this, or has the idea been dropped? It strikes me that KDE4 is an example of something that will probably re-occur: incorporating long-term development cycles and alpha packages into the K/Ubuntu release process. John -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: [ubuntu-motu] Re: KDE 4 uploads to universe
On Fri, Mar 09, 2007 at 12:41:32PM +0100, Reinhard Tartler wrote: > I summarise the request from my POV with arguments that count to me, > please correct me if I got something wrong: > > * the KDE4 packages don't affect any existing KDE3 installation from > ubuntu main > * the KDE4 packages from universe are co-installable with the packages > from main > * user settings are kept separately, no migration is planned > * the packages are provided as-is, this means: no support after > release, and are intended as technology preview packages. They're correct. > I understand that you all like to have always the latest stuff in the > archive, espc. when it's doesn't affect any existing installations > and/or packages. However I feel that it would help the feisty release > more, if the time and energy which is put into these KDE4 package was > devoted to the KDE3 packages. However, since I don't want to tell anyone > what do do, and everyone is free to work on any project he wants, I > don't have strong objections either. My concern is rather that having > KDE4 distracts developers and users from using, testing and fixing the > existing KDE3 packages. The packages help upstream developers as well as ensuring Kubuntu is ready for KDE 4 when it does get released. Jonathan -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
About SRU and Backports
Hello, some more comments about upgrades in general and the backport request process. I hope it is clear for the Ubuntu development team that the existing SRU policy fails to meet the majority of desktop users expectations regarding application upgrades. You can confirm that by looking into the forums for the several postings about users asking when version Y will be available on the updates. This is also because on other OSes (guess which) most of the applications have already self-upgrade functions, such upgrades are defined by the authors according to the applications own roadmap. The back porting process is expected to overcome this but in my opinion it still doest not meet users expectations because: - Backports are Ubuntu+1 release based (in my opinion they should be application release based) - It's visibility is not sufficient (at the moment most people which uses backports are probably those which know how to build from the source) The current backport request process is a technical oriented processed, meaning backports are initiated by technical persons, which have the ability to lookup if the package is in Ubuntu+1, if the upgrade can be done as an SRU or not, etc. This results on backports being implemented for applications which have a broader technical audience and not based on users requirements. I understand that there are a lot f other things to manage besides user's expectations like applications stability, Ubuntu specific integration, etc. but I still feel that the current rules/procedures are too blind. There are critical and non critical applications there complex and trivial changes and they can't simply be treated all by the same rules Best regards, -- João Pinto GetDeb Packager http://www.getdeb.net 2007/3/8, João Pinto < [EMAIL PROTECTED]>: Daniel, before answering to your questions let me explain better the context of my comments regarding the packaging and updates policy. From my experience, home PCs and enterprise PCs don't share the same requirements. The current policy/processes are mandatory for enterprise/business IT managed environments where sw and hw upgrades are (slow) business driven and the key factors are security, stability, certification and support. At home, upgrades are user's driven and the key factors are features, people want to be able to use their latest gadget and to export files to the newest online service they have subscribed, etc, etc., for those this strict policy may be an adoption blocker. I believe Ubuntu/Debian packaging aims business IT, while I am aiming home users. Answering your questions: The sources are not available online yet, I have this pending with the script which is not yet implemented that will take care of populating the getdeb database and upload all the files, please note that I am not using a repository and the associated tools. I am providing the sources every time I get a request, which is rare, most of getdeb visitors are end users which have no use for the source. I understand the benefits on working a greater team like the MOTU but to be honest I don't believe I would be able to participate to the Ubuntu users as much I believe I am doing with GetDeb. Browsing on REVU I don't see that much activity and I see packages introduced from September which are pending, to be honest, such "Welcome to REVU" is not encouraging for someone willing to provide the newest applications to the users. Please don't get me wrong but in my opinion the best hands to fix bugs are the software developers not the software packagers, if it's a trivial bug, I will fix it and contact the author, if is not trivial it should be up to the upstream developers to fix it, turning the packagers into co-developers is not very efficient, specially for bug fixing. Ideally it would be the way around, developers providing and updating their own packages. I have not decided yet about the bug reporting system, it will point to a launchpad entry or I will use the upstream bug reporting system. Despite our different approaches and concerns I am sure we will be able to cooperate. Best regards, 2007/3/8, Daniel Holbach <[EMAIL PROTECTED] >: > > Hello João, > > On Do, 2007-03-08 at 13:33 +, João Pinto wrote: > > I have been a software developer for a long time and just recently got > > interested into software packaging, mostly because during my Ubuntu > > forum's participation I realized there is a lot of non-developers > > spending too much time to get a specific application or feature which > > is not yet available on the repositories. > > I am not an experienced packager but I did understood the strict > > policy/requirements to be a Debian/Ubuntu maintainer by looking into > > REVU and Debian mentors, I would never be able to keep > > updating/creating packages with such quality requirements and be able > > to have "0 days" packages together with the site building and > > packaging requests scouting. > > I can see your point. It often t
Re: KDE 4 uploads to universe
Jonathan Riddell <[EMAIL PROTECTED]> writes: > The Kubuntu Council have decided to treat KDE 4 and related packages > with a general upstream version freeze exception, pending any > objections from MOTU Council. This includes other pre-release > software such as decibel and strigi that is not used by anything > except KDE 4. > > Rationale: these are pre-release packages which are clearly marked as > having no stability guarantees. It allows us to implment the KDE 4 > spec https://wiki.kubuntu.org/KubuntuFeistyKde4Plan I summarise the request from my POV with arguments that count to me, please correct me if I got something wrong: * the KDE4 packages don't affect any existing KDE3 installation from ubuntu main * the KDE4 packages from universe are co-installable with the packages from main * user settings are kept separately, no migration is planned * the packages are provided as-is, this means: no support after release, and are intended as technology preview packages. I understand that you all like to have always the latest stuff in the archive, espc. when it's doesn't affect any existing installations and/or packages. However I feel that it would help the feisty release more, if the time and energy which is put into these KDE4 package was devoted to the KDE3 packages. However, since I don't want to tell anyone what do do, and everyone is free to work on any project he wants, I don't have strong objections either. My concern is rather that having KDE4 distracts developers and users from using, testing and fixing the existing KDE3 packages. My personal conclusion (given that the 4 points above are correct!) is that I'd give a very weak accept. I'm sure that you (the kubuntu council) already discussed the concern and that you came to the conclusion that having KDE4 in kubuntu was more worthwhile than working on KDE3. It would have just been nice if this concern would have been mentioned on https://wiki.kubuntu.org/KubuntuFeistyKde4Plan in the first place. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 pgpddma2ApnkB.pgp Description: PGP signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: [ubuntu-motu] KDE 4 uploads to universe
Jonathan Riddell <[EMAIL PROTECTED]> writes: > If Jeremie Corbier is reading, please reply to this thread if you have > a point to make and please do not flame me in your blog. There is a > reason we have mailing lists and IRC, blogs are not a replacement. Sure thing. I feel quite similar like Jeremie, but I didn't say anything to the descision, because I have no idea about the state of KDE 4. My current feeling is that it isn't a good idea to include KDE4 into feisty at this point. We have an UVF for a reason, you know. However I see that you discuss the issues in the kubuntu community, and seem to have come to an agreement, that it was a good idea to push this into feisty anyway. I didn't participate in that discussion, so I don't know how you came to this conclusion. Your mail only indicated that you came to this conclusion, but not how. Therefore I'm not convinced that getting KDE4 into feisty is a good idea, but I have no strong objection either. IMO the kubuntu community should decide what's best for them. I think Jeremie is thinking quite similar, and expressed his feelings in his blog, a think that's perfectly legitimate to do in one's personal blog. > Having KDE 4 packages is a good idea because it helps people see the > current state of KDE 4 and hopefully help out from there. It ensure > we have good quality packages when KDE 4 releases rather than hoping > upstream will magically fix all the problems without us having to even > look at it, then we package for the first time on the day of release. Sure, but I don't expect that the KDE4 developers will devote enough energy and time to fix KDE4 in feisty to a point that we were all satisfied with the quality of the packages. No idea if this is correct, though. But please don't give my words too much weigth, I don't use KDE atm, and I don't have enough time left to contribute time to improve the kde packages. sorry. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: [ubuntu-motu] KDE 4 uploads to universe
If Jeremie Corbier is reading, please reply to this thread if you have a point to make and please do not flame me in your blog. There is a reason we have mailing lists and IRC, blogs are not a replacement. Having KDE 4 packages is a good idea because it helps people see the current state of KDE 4 and hopefully help out from there. It ensure we have good quality packages when KDE 4 releases rather than hoping upstream will magically fix all the problems without us having to even look at it, then we package for the first time on the day of release. Feel free to disagree with that but do so in the correct place. Flaming me seems to be your entire contribution to Planet Ubuntu, I recommend you remove your blog if that is the most constructive thing you have to announce to the world. Jonathan -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: [ubuntu-motu] Re: [ubuntu-motu] Re: KDE 4 uploads to universe
On Fri, Mar 09, 2007 at 01:37:37AM +0100, Stefan Potyra wrote: > On Friday 09 March 2007 01:20:24 Jonathan Riddell wrote: > > On Fri, Mar 09, 2007 at 01:02:04AM +0100, Stefan Potyra wrote: > > > Do I get it right that you ask for an UVF exception for NEW packages > > > (rather than for updates)? > > > > Both. > > About how many packages would fall under new upstream versions? kde4*, stigi, decibel at the moment. As for if or when that might happen I've no idea since they are development versions and there's no strict release plan. Jonathan -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Improving the MOTU Community
Hi all, This is going to be a long email, so bear with me. :) Thanks very much for discussing the different issues about the MOTU community in your last meeting. I had a look over them, and looked at some of the things we can do to improve the community, and I would like to offer some advice for things to do in this mail. I recommend you follow this advice and implement the things I suggest, and then we schedule another meeting which I will be at to discuss any other improvements that can be made. One thing is clear - MOTU has incredible potential, and with some of the right community building techniques, I am positive we can improve things. Fixing these problems basically falls into two core areas: (1) Making MOTU easier to be part of (2) Spreading the word and outchreach Fixing (1) means improving the MOTU resources and fixing (2) means babbling to the world about how cool MOTU is and getting people involved. You need to make sure (1) is fixed before moving onto (2). So, lets look at the things in (1) that need fixing first: * The MOTU Wiki pages - Looking at https://wiki.ubuntu.com/MOTU it is just too difficult to figure out where to start - it is a mess of informaton. Many teams face this problem, so I have created a consistent design that can be seen at https://wiki.ubuntu.com/BuildingCommunity/SampleTeam - you should make use of this consistent design and use the same sections shown in the above link. This is what you put in the sections: - Roadmap - more on this later. - Getting Involved - write a simple guide to getting started - what are the first five things every MOTU should do? Write them into this page as a really simple guide. This is the very first thing that every new MOTU should read. - Knowledge Base - each of the guides, documentation and HOWTOs but doing MOTU things should be linked inside this section. This should be an index of MOTU knowledge - existing and new MOTUs go here to find out how to do things. - FAQ - work to make a huge and detailed FAQ answering the typical questions about MOTU that you often get on the list and IRC channel. You should grow a culture in MOTU that if something is asked that the FAQ does cover, the FAQ should be updated. This will create a definitive document that you can always point people at. :) - Contacts - in here list the mailing list and IRC channel as well as any key contacts who are happy to answer specific questions. This would be a good place to put mentors. Getting your wiki pages together is priority #1 - it will make MOTU a much easier project to approach. This design I have constructed is also being used by other Ubuntu projects on the wiki. * Define a Roadmap - You may have done this already, but the team needs to have a consistent set of doable goals that can be approached. Only you folks can know what these goals are, but they need to be clearly documented. The roadmap is essential so that the team know what needs working on and so that new MOTUs can start working on something. It can be particularly useful to identify the kind of things that new MOTUs can get started with too. * Create regular events - Right now you have a regular MOTU meeting, and it seems you sometimes have MOTU school. I would *really* recommend that you regularly have sessions that teach MOTU skills and also have a Q+A session for MOTUs. As an example, I have a monthly Community Q+A session which proves popular for people to just come along and ask what is on their mind. I recommend having a monthly Q+A session in addition to the MOTU meeting, and then having at least one tuition session each month. This creates a rich set of events that makes MOTU feel alive and kicking. Packaging is hard, so people need (1) documentation and (2) events to help them get started. So those are the bits and pieces in (1) that need sorting first, but now lets look at the outreach goals in part (2). This is *hugely* important. MOTU basically needs regular pimping - people of the world need to know it is a cool and important project to be a part of. So, you should each do the following: * Blog, blog, blog! - I very rarely see MOTU appear on Planet Ubuntu. This needs to change. If you have a blog, blog about MOTU, if you don't have a blog, get one from wordpress.com and blog about MOTU! Write about events, things you are working on, things you have learned, packages you would like to see packaged, things you need help with, amusing discussions...it doesn't matter what. I would like to see at least two posts about MOTU every day when I read Planet Ubuntu. This is *hugely* important - blogging is the way you spread the word about the project and get new people involved. * Publicise your events - A MOTU event is useless if people don't know about it. Firstly, make sure it is in the Fridge events calendar. Secondly, make sure you blog about it and talk about what the sessions is all about - you should particularly get people excited about the tuition ses
First task
First of all, thanks for your pointers, help and especially patience with this newbie. I went along with something easy at first (Bug LP#88232: Package description is very out of date) :-) I changed the short description and long description in 'control' as follows: The award-winning Web browser from Mozilla Firefox 2 is now faster, more secure, and fully customizable. New powerful features have been added, among others: Web feeds, in line spell checking, integrated search capabilities, identity theft protection, and advanced tabbed browsing. The 'changelog' was changed with the following addition (using dch -i): firefox (2.0.0.2+1-0ubuntu2) feisty; urgency=low * package description updated (Closes: LP#88232) -- Cesare Tirabassi <[EMAIL PROTECTED]> Fri, 9 Mar 2007 09:08:04 +0100 I then rebuild the source package and checked that the executable build is ok. This is the diff between the two source packages: diff -Nru /tmp/JlARGXGcGM/firefox-2.0.0.2 +1/debian/changelog /tmp/goRRKpBClM/firefox-2.0.0.2+1/debian/changelog --- /tmp/JlARGXGcGM/firefox-2.0.0.2+1/debian/changelog 2007-03-09 09:59:15.0 +0100 +++ /tmp/goRRKpBClM/firefox-2.0.0.2+1/debian/changelog 2007-03-09 09:59:52.0 +0100 @@ -1,3 +1,9 @@ +firefox (2.0.0.2+1-0ubuntu2) feisty; urgency=low + + * package description updated (Closes: LP#88232) + + -- Cesare Tirabassi <[EMAIL PROTECTED]> Fri, 9 Mar 2007 09:08:04 +0100 + firefox (2.0.0.2+1-0ubuntu1) feisty; urgency=low * new upstream release 2.0.0.2 diff -Nru /tmp/JlARGXGcGM/firefox-2.0.0.2 +1/debian/control /tmp/goRRKpBClM/firefox-2.0.0.2+1/debian/control --- /tmp/JlARGXGcGM/firefox-2.0.0.2+1/debian/control2007-03-09 09:59:15.0 +0100 +++ /tmp/goRRKpBClM/firefox-2.0.0.2+1/debian/control2007-03-09 09:59:52.0 +0100 @@ -12,12 +12,11 @@ Provides: www-browser Conflicts: mozilla-firefox (<< 1.5.dfsg-1) Replaces: mozilla-firefox -Description: lightweight web browser based on Mozilla - Firefox is a redesign of the Mozilla browser component, similar to - Galeon, K-Meleon and Camino, but written using the XUL user interface - language and designed to be lightweight and cross-platform. - . - This browser was previously known as Firebird and Phoenix. +Description: The award-winning Web browser from Mozilla + Firefox 2 is now faster, more secure, and fully customizable. + New powerful features have been added, among others: + Web feeds, in line spell checking, integrated search capabilities, + identity theft protection, and advanced tabbed browsing. Package: firefox-dom-inspector Architecture: all I guess this is somehow useless as most probably you don't want to update the source package just with this bit but it was a good exercise for me nonetheless :-) I will keep trying to do something useful for the MOTU/TODO but your comments/requests on the above will be highly appreciated! ct -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
