Re: PROBLEM
On 25/03/2010, at 10.32, natalya hutagalung wrote: i have a problem dpkg --configure -a dpkg: parse error, in file `/var/lib/dpkg/updates/0012' near line 16: missing package name it make me can run apt-get install can you help me ? The error message is trying to tell you what the problem is. You need to specify the package name: dpkg --configure -a PACKAGENAME_HERE Cheers, Morten -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Future of MOTU
On 23/03/2010, at 10.02, jdetaeye wrote: The tools and the intention of the REVU process are right. But if there aren't any reviewers working on the list, the process will remain broken. One problem is that we have no active REVU-coordinator for the time being, and that REVU-days have not been regularly organized since a very long time. -- Morten -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Future of MOTU
On 23/03/2010, at 22.32, Benjamin Drung wrote: How many people working on that task and how many Ubuntu packages needs to be ported to Debian? Can we rely on the folks who port Ubuntu packages back into Debian or is this more only a wish? Porting is not the problem, it's getting the package sponsored in Debian. -- Morten -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Future of MOTU
On Tuesday 02 March 2010 16:27:36 Morten Kjeldgaard wrote: I my opinion, REVU is a hugely useful tool. A lot of work has quietly been done on the software lately, in large part thanks to RainCT, and I now think it is quite close to ideal: easy to use, and robust. Uhm, well OK, it still needs be taught to understand source package format: 3.0 (quilt) :-) -- Morten -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: MOTU-science for official development team delegation
On 07/02/2010, at 19.37, Scott Howard wrote: With the archive reorganization currently going on [1], I'd like to gauge the team's interest (especially William Grant and Morten) in becoming an official development team [2] for science packages. I am afraid the team is too small and scattered to really make an effort. As it stands now, it is my feeling that the current purpose of the team *mostly* is that members can display an emblem on their LP page showing their interest in science packages. It is my impression that the team's members indeed are active in the day-to-day maintenance of these packages, they care about bugs, new releases etc. and report bugs on LP. However, I am not sure that the team with its current strength can take on a more formal and active role. When joining Ubuntu as a MOTU is was my vision that it might be possible to make a branded Science Ubuntu version. However, I do not myself have the time or energy required to pull such a thing through, and in addition, some of the most active members from the past have retired. A more realistic goal might be to join forces with the edubuntu team, and perhaps form a science subgroup under that umbrella. As our team stands now, we have 9 members: 4 are full ubuntu-dev, one more should ubuntu-dev (but hasn't applied, I think), one is inactive, and the other three are at least -contributor level (but have not applied yet). I think we are ready to take part in this new system. We would have to make the non ubuntu-dev people apply to stay in the team since they would have upload permissions. I'll be willing to take on the communication with the technical board over the implementation for this. I have approved 3 new members today; welcome to you! Our current policy is that new applicants are required to have 500 bonus points. Science packages are often a little bit complex, and so Grant and I some tima ago decided that it was a good idea that applicants have demonstrated some activity and gained some experience before letting them in the team. Cheers, Morten -- ubuntu-motu-science mailing list ubuntu-motu-science@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu-science
Re: sailcut 3.8.0
mario yoddlerboy wrote: I am unable to force the package (from the synaptic manager) to upgrade the only version 1.8 (?) to the most current release. note there is no listing for versions other than the original jaunty version 1.8.my current ubuntu OS is 9.04. I cannot reproduce any problems installing sailcut, on neither jaunty mor karmic. The version of sailcut currently in karmic is 1.3.3, jaunty has 1.3.2. The newsest version on upstreams website is 1.3.4. I can't find any information about a version named 3.8.0. You shouldn't need to force anything; in fact it is a bad idea and is likely to screw up your system. I am an aspiring small boat designer/builder, NOT for sale or profit. Being recently retired I'm heading for the mid atlantic florida coast. my intention is to use this program for panel/conical development of sheet plywood. any/all information concerning obtaining a copy of working software will be most appreciated. Sounds nice, good luck! :-) Cheers, Morten -- 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
On 02/11/2009, at 17.23, Benj. Mako Hill wrote: quote who=Stefan Potyra date=Mon, Nov 02, 2009 at 12:43:22PM +0100 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. Everyone involved values the community. If you doubt that, we have very serious problems. Unfortunately, a few minutes after posting the above statement, Stefan sent an email to u-m saying he's no longer sure if he wants to be involved with Ubuntu Development. I'm not sure if these things are connected, but given the timestamps it's certainly possible. When you're at the top of the pyramid, it's easy to view discussions and information as procedural pedantry. When you're at the _bottom_ of the pyramid, working your behind off for the common good of the project, it is equally easy to become demotivated if you start feeling you're taken for granted and that relevant information doesn't come your way. It's in everybodys good interest to maintain a high level of information and discussion, and since everybody has stated that they have no problem with the actual outcome of the decision, that should pose no problem. What is relevant is that everybodys desire to be in the loop is satisfied. Cheers, Morten -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: LuaRocks package out of date
On 26/10/2009, at 23.49, Linus Sjögren wrote: I would just like to notify you, as maintainers of the package 'luarocks' on the Ubuntu universe repo, that the version 2.0 is the latest one available. Please push that version to the repos. The luarocks source package is sync'ed unchanged from Debian unstable and compiled for Ubuntu. Your request therefore belongs with the Debian maintainer of the package [0]. I've forwarded a copy of your email to him, so there's probably no need for you to do more. Cheers, Morten [0] http://packages.qa.debian.org/l/luarocks.html -- Morten Kjeldgaard m...@ubuntu.com Ubuntu MOTU Developer GPG Key ID: 404825E7 -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Hugging our universe hero
On 28/10/2009, at 15.06, Stefan Ebner wrote: So go, hug them (or yourself, or both xD) Did you just say go hug yourself??! :-) -- Morten -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Hugging our universe hero
On 27/10/2009, at 20.05, Chow Loong Jin wrote: Thanks Scott! =) Karmic is poised to be the greatest Ubuntu release ever! Let me join the universe-wide hugfest! Thanks ScottK :-) -- Morten -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Serious bug in atlas, yet no action
On 06/10/2009, at 16.41, Cyrus Hall wrote: I've recently run into what appears to be a known and reported problem in Atlas 3.2.1: the SSE2 optimized version is broken. This version is currently shipped with Jaunty, and is reported to still be broken in the Karmic (see bug reports below). There are numerous unassigned bug reports in launchpad which appear related to the problem, some of which are six months old: Thank you for drawing our attention to this bug. I will take a look at the problems. Anyone willing to pitch in, please do so! In particular, if you are aware of patches, make a note on the bugs. Cheers, Morten -- Morten Kjeldgaard m...@ubuntu.com Ubuntu MOTU Developer GPG Key ID: 404825E7 -- ubuntu-motu-science mailing list ubuntu-motu-science@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu-science
Re: let's do a motu-meeting again
On 02/10/2009, at 21.10, Stefan Potyra wrote: Hi, Hi Stefan, ahem, shame on me, as I scheduled the meeting in conflict with a Kubuntu meeting. So no meeting for us right now. Phew. I was the only one replying to this thread and then I @'!!#%!! forgot about the meeting. Shame on ME. 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? Cheers and sorry for the inconvenience, Ahem. No problem ;-) -- Morten -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Xpaint new release
Hi Jean-Pierre, Thanks for your message! It is indeed wonderful that there are still people actively maintaining programs with names that start with x :-) It's brings a fuzzy nostalgic feeling back :-) The enhancements you talk about indeed sound very good and should make users of xpaint happy. As karmic approaches, I'd like to inform the Ubuntu MOTU team that new versions of xpaint have just been released on Sourceforge, currently at 2.8.3. The Karmic Koala is now in beta stage and has been frozen for new features for some time. But version 2.8.x of xpaint will surely make it's way into Ubuntu 10.04, which is a long-term-support release. Most likely via Debian, and, if you now have a .desktop file for xpaint, it will be a straight sync without local Ubuntu modifications. Eventually xpaint 2.8.* may be backported to 9.10 if there is sufficient interest to do so and if the normal requirements for backporting are fulfilled. Cheers, Morten -- Morten Kjeldgaard m...@ubuntu.com Ubuntu MOTU Developer GPG Key ID: 404825E7 -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Request new ubuntu universe sponsors admin.
I volunteer. Cheers, Morten -- Morten Kjeldgaard m...@ubuntu.com Ubuntu MOTU Developer GPG Key ID: 404825E7 -- 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
On 25/09/2009, at 15.03, Stefan Potyra wrote: 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? +1 I'll be there. -- Morten -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: 64 bit pat Mrbayes executable
On 25/09/2009, at 04.04, s...@aol.in wrote: Dear Ubuntu MOTU developers, The problem with MrBayes in 64 bit MrBayes is that there is a bug that makes it segfault everytime. This is a known issue and there is patch available for this. The Ubuntu version of MrBayes is not usable in 64bit systems. I am attaching the patch and the compiled binary. Please apply the patch and compile the source, or you can directly use the binary that i have already patched and it works perfectly in 64-bit systems. Kindly update the repos with the patched .debs. Thank you for submitting a patch to MrBayes. Unfortunately the patch is either reversed or has alreaady been applied, I can't offhand tell which. The right way to address bugs in Ubuntu is via the bugtracker on Launchpad.net. Bugs reported to the mailing list tend to get lost. Go to the Ubuntu project, find the mrbayes source package and file a bug under it. We can continue the discussion there. You write the there is a patch available. Can you please inform us of he origin of the patch? Please do it in the bug's comment Please do not submit binary files, we have no need for those. Thanks for your interest in Ubuntu, Morten -- Morten Kjeldgaard m...@ubuntu.com Ubuntu MOTU Developer GPG Key ID: 404825E7 -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Reminder: Three wishes for Soyuz and Launchpad Bugs 4.0
On 22/09/2009, at 16.39, Michael Bienia wrote: On 2009-09-20 08:36:11 +1000, William Grant wrote: It also appears that we now have three wishes for Launchpad Bugs. I've been asked to give both on Wednesday, so get any opinions in soon! - Better support to see which Ubuntu releases are affected by a bug (version support) +1 -- Morten -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
powerpc arch is in a sad state
The powerpc platform is not officially supported in the archives, but it exists as a port and is without a doubt useful for many users. However, the platform is in a sad state for karmic, almost all builds I have submitted as of late have failed, and the FTBFS list is a mile long. It is my firm impression that the powerpc port has deteriorated during the last releases. I do not myself have a powerpc machine to do testbuilding, and so debugging becomes a very slow and tedious affair. Perhaps someone with access to powerpc platform could be persuaded to do something about it? With so many packages to fix, it is important to start at the bottom nodes of the dependency graph. A web based tool to visualize the ancestors (and children) of a particular package, along with their build status would be extremely useful. Perhaps we could have a project to create such a tool? Any thoughts on this? Cheers, Morten -- Morten Kjeldgaard m...@ubuntu.com Ubuntu MOTU Developer GPG Key ID: 404825E7 PGP.sig 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
On 12/06/2009, at 23.05, Luca Falavigna wrote: 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 realize that Soyuz at the moment probably would not accept a URL. However, it DOES recognize various email addresses and translate those to Launchpad teams or people. I have put my ubuntu.com address in the maintainer field of a few packages, and Soyuz actually translate those to my Launchpad homepage. I am proposing something similar, it could also be a pseudo-email-address (e.g. m...@launchpad.net). I am sure the nice Launchpad developers would repond favourably if we asked them politely via lp-liason. Not exactly. For each package uploaded, Launchpad UI displays two fields, Uploaded by and Maintainer, so users have two contacts to send requests to in case it is needed. We cannot assume users know our policies, give them references is a win-win choice. Uploaded by would probably be the real maintainer of the package, so users could contact a person interested in package anyway. There will still be two fields, one for MOTU and one for the packager, exactly like now, only the packager's field would not be his/her private email, but a link to their Launchpad account. PLUS the packager would automatiically be subscribed to bugmail of the package. 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. I also don't think we should have a concept of maintainership like they do in Debian. However, there are people -- both packagers and MOTUs who in practice do maintain some packages anyway, in the sense that they make sure bugs get fixed, new upstream versions get packaged, and they communicate with upstream. The latter is especially important when it comes to Ubuntu-only packages, since it is both more practical and more polite that we have a single contact person communicating with upstream, rather than a lot of different drive-by bugfixers who don't know the software and the package in detail. So IF there is an Ubuntu member who wants to care for a package, I don't see why it should be forbidden. Perhaps that could be signalled with an XSBC-Ubuntu-Maintainer: field like you suggest, but it is another discussion than this one (which basically only is that packagers have to put their Launchpad-Id in debian/control rather than their private email address). Cheers, Morten -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Maintainer/XSBC-Original-Maintainer in Ubuntu packages
Hi, I would like us to discuss the merit of the XSBC-Orignal-Maintainer: policy for -0ubuntu* packages in Ubuntu Universe. These are packages that have been introduced into Ubuntu somehow, either through REVU or an upstream-upgrade via a MOTU. This post concerns that type of packages, NOT merged or sync'ed packages. I think the XSBC-Original-Maintainer field doesn't work as intended, and that the field Maintainer field is redundant. Currently, we put the email address of this mailing list in the maintainer field. That is redundant, because the Maintainer: field of all packages in universe then is identical. It contributes no information other than what is already known by the package being in Universe. From the release string, it is quite easy to determine that this is an Ubuntu-only package, and it's already known that it's from Universe. One of our big problems is that people (understandably) love to get packages into Ubuntu e.g. via REVU. But often/occasionally/sometimes it happens that after getting the package uploaded, the packager disappears, leaving the package in an unloved and abandoned state. Although we encourage packagers to subscribe to bugs etc. of their packages on Launchpad, this is often not done. Perhaps because you have to remember to go to Launchpad yourself to subscribe to bugs. And, that is only possible quite some time -- often weeks -- after the package has been sponsored via REVU. I suggest that for -0ubuntu* packages, the maintainer field MUST be the Launchpad ID of the packager/contributor. That would enable bug subscriptions etc. to be enabled automatically, and we would have a much better handle on the maintainers/packagers. Quite simply, I think it will make it easier to motivate packagers to take care of their packages. Let me underline that for _merged_ packages and Ubuntu _bugfixes_, the maintainer mangling policy makes more sense, because we cannot expect Debian maintainers to be responsible for what MOTUs and others have done to their packages. Here it makes sense to move the Debian maintainer to the XSBC-Original-Maintainer: field, and put something else in the Maintainer field. Cheers, Morten -- Morten Kjeldgaard m...@ubuntu.com Ubuntu MOTU Developer GPG Key ID: 404825E7 -- 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
Reinhard Tartler wrote: I disagree here a bit. Some of the package I maintain are being maintained in a team on alioth. Most prominent teams here are pkg-wpa and pkg-multimedia. I leave the alioth mailing list in the maintainer field to indicate where the maintainers can be reached. I am not sure I fully understand: you maintain these packages in a team on alioth, but they are still -0ubuntu1 packages? Cheers, Morten -- 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
Stephan Hermann wrote: Moins, Moins to you too! My packages have Maintainer: MOTU and XSBC-Orig-Maintainer: insert my realname + email addr. as an example. Yes, that is the way most REVU contributors also do it. I do take care of them (depending on Time and Priority of usage of the packages).invented It follows the latest ubuntu policy. Furthermore, if someone wants to push them to debian, I'm happy to sync those packages back from debian, if they will stay with the same quality. You are a first class citizen and an admirable Ubuntu developer! Even if a maintainer of package only in ubuntu is MIA, MOTU can deal with those packages (update, remove, whatever), that's the intention why we let those packages through revu/direct uploads into ubuntu. As of today we have 861 universe packages that are maintained in Ubuntu (*). We _can_ use some help with those! I think it's worth the effort to try to motivate a certain sense of responsibility on the part of the packagers. One way to do that is for example if people were automatically subscribed to bug-mail on their packages. That would be possible if the Launchpad ID was hardwired via the Maintainer: field. Example of what it would look inventedlike: Maintainer: Morten Kjeldgaard (https://launchpad.net/~mok0) The last resort is always a removal of this package in question, if it's not already in debian... Not having an active maintainer is not the same as the package not being interesting and valuable. invented I don't see why we should change this? That's what Microsoft's programmers said about their missing TCP stack before Bill Gates discovered the Internet in 1998 ;-) Cheers, Mortenwe (*) Furthermore, MOTUs maintain 1301 packages with local Ubuntu changes. -- 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
On 12/06/2009, at 19.11, Charlie Smotherman wrote: [snip} As of today we have 861 universe packages that are maintained in Ubuntu (*). We _can_ use some help with those! So where can someone find a list of these 861 packages that need love and affection? I used the number from multidistrotools: http://qa.ubuntuwire.com/multidistrotools/universe.html Cheers, Morten -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Closing LP bug
Charlie Smotherman wrote: sync'd to karmic. I have some bugs that are on the BTS and I have some LP bugs that I would like to close with this upload to debian. Charlie, you rock! If only more developers were like you! :-) -- Morten -- 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?
On 22/02/2009, at 12.47, Michael Bienia wrote: On 2009-02-21 20:52:47 +0100, Morten Kjeldgaard wrote: Oh, I didn't make it quite clear: I imagine that packages uploaded to the PPA would be the ones that passed reviewing with 2 advocates. So essentially, these package would be in a state ready for upload to Ubuntu's archive. I agree that dealing with every upload in the PPA would be unmanagable. I guess I'm missing something here. When a package has two advocates why not upload it to the archive? Or do you mean upload it to the archive and to the PPA? What's the benefit of it? Is the NEW processing that slow that it blocks reviewing? After FF there's a period of ~ 2 months where we can't upload new packages. I would be good to be able to finish the processing of those packages that are _almost_ finished, but just didn't make it. While it's still in fresh memory of the reviewers and uploaders. Also, many uploaders are quite disappointed. It would be a consolation if we published those packages that didn't quite make it (but still get +2 votes) on the PPA. They should be compiled for the version they missed, currently jaunty. Thus, the PPA would contain a preview of packages that didn't make it for jaunty, but will be included in karmic. Cheers, Morten -- 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?
On 22/02/2009, at 04.45, Stefan Potyra wrote: 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. You wouldn't be adding _all_ REVU packages to your pbuilder environment, only the ones that passed muster and got +2 votes. A package would be uploaded to Ubuntu's archive if it's open, otherwise the PPA. I think it is important to maintain that packages in the PPA would have the same high quality as the distributed ones, except they didn't make the current distribution for administrative reasons etc. Cheers, Morten -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Staging area for REVU uploads?
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. * 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. * We can continue some level of reviewing and uploading, even during FF. * Certain build problems with packages might be exposed before being uploaded to the final archive. * Perhaps it is possible to pull packages directly from the PPA into the NEW queue? Cheers, Morten -- 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?
On 21/02/2009, at 19.51, Mario Limonciello wrote: What happens when someone needs to make changes without modifying the build number? REVU allows this, but PPAs explicitly wouldn't unless you deleted the old build, waited for the publisher to see the deletion, and reran it. You'd then run into weird situations on environments that might have already installed a package from the REVU PPA. Oh, I didn't make it quite clear: I imagine that packages uploaded to the PPA would be the ones that passed reviewing with 2 advocates. So essentially, these package would be in a state ready for upload to Ubuntu's archive. I agree that dealing with every upload in the PPA would be unmanagable. Perhaps an exception from this rule could be made wrt. library packages. Generally when people upload to PPAs, they'll append ~ppaX or +ppaY to the revision to reflect the fact that these aren't really in the archive yet. There can be some confusion especially when there are changes to the packaging, but the build number hasn't changed. Yes, this is a good point. We may have to solve the problem by appending ~ppa* (or ~revu*) to be able to deal with situations like you describe. That extension needs to be stripped on the final upload. Cheers, Morten -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: MOTU Meeting Minutes for 2009-01-30
Nathan Handler wrote: However, the more I think about this issue, the more I feel that more lists are not the correct solution. Your philosophy behind adding more lists was to not have packages that already had one advocate but received a non-advocating comment from a MOTU be sent to the Needs Work list. Well, the philosophy is rather to clearly separate packages in different stages of reviewing so they don't get lost in the muddle of entirely new, unreviewed packages, packages that have been abandoned, etc. The result is that packages might wait a bit longer for their first review, but should then progress faster as MOTUs will be able to focus their attention on packages that are steadily improving. What if instead of lists, we had searches? These searches would allow each user to specify exactly what type of packages they wish to see. For instance, there could be searches based on the number of comments, searches based on the number of days since the package was uploaded, or even searches based on the name of the package. We could then allow the user to choose which search(s) should be displayed on the main page. I think that this would make it much easier for MOTUs to find the packages they are interested in and review them. I am interested in hearing what the rest of the community thinks about this ideas. What you are proposing is a cool idea that would be very useful and flexible. In practical terms though, it sounds like a major revision of the interface, and from my limited knowledge of the software I can't say what it entails in terms of programming. Perhaps you can follow in my footsteps and make a mockup site that could present your ideas? My workflow proposal does not represent the ultimate system for reviewing; although REVU is really very good, I am sure one could imagine a much more powerful revuing system, for example under Launchpad auspices. My suggestion was based on a quite minimal change of the underlying software (despite that, it turned out to be a bit more than I had originally envisioned!) so it really is a compromise. Cheers, Morten -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: ical2sqlite
Hi Remo, I don't really know if I'm at the right address. If it's not, please send this email forward to the maintainer of ical2sqlite!! Reoccurring events aren't working completely with the version 0.1 Attached you find the patch for the main.c file I double checked the values with sqlitebrowser. The reoccurrencies are perfectly working on my iPhone now! The mailing list is actually not the best place to submit patches, nobody will know if it gets applied, and after a while people will forget about it. The best way to report bugs for Ubuntu is via our bug tracking system at Launchpad.net. The procedure is to file the bug under the source package it belongs to, for your convenience I enclose the relevant link: https://bugs.launchpad.net/ubuntu/jaunty/+source/ical2sqlite There's a Report a Bug button on that page. The bug report has facilities for attaching files, so you can attach the patch and tick off the box that says the attachment is a patch. You probably need to register/log on to LP first, but with your programming skills (demonstrated by your patch) you may be able to help fixing other bugs, so having an account will enable you to help us even more! Cheers, Morten -- Morten Kjeldgaard m...@ubuntu.com Ubuntu MOTU Developer GPG Key ID: 404825E7 -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: MOTU Meeting Minutes for 2009-01-30
Hi, == Discussion about REVU == Morten Kjeldgaard raised a proposal to improve REVU workflow [1]. With this new approach, packages uploaded to REVU would fall into four categories depending on reviewers' actions (need-work comments or advocations). It could also be possible to inhibit new uploads to REVU at a choosen time (i.e. after FeatureFreeze), but Nathan Handler and Emmet Hikory put some objections about this feature. Discussion was taken to describe the new display method for REVU packages, Nathan Handler and Emmet Hikory argued about the real usefulness of the new interface, especially because of the notification feature already implemented in REVU (interested parties can subscribe to a given package to receive updates about a package status). After a short discussion, there was no consensus about the proposed workflow because there is not a clear idea of the benefits of it. Luca Falavigna proposed to set up a staging REVU server to familiarize with the new display method to see how it performs and if there is room for improvements. Following up on last MOTU meeting, I have set up a mock-up site displaying the revised REVU workflow [1]. The original proposal is available on the wiki [2]. Please note, that most functionality that you know and love from REVU is not working correctly, in part because my server does not have a copy of the 48 Gb source package upload data that is hosted on the real REVU site ;-) What *should* be working is the links at the top labelled: Package rung: Unreviewed | In Progress | Advocated | Upload | Archived Packages These links lead to pages that are in different stages (rungs) of reviewing. The listings are a bit different from what you are used to, there are columns listing the total number of comments and the number of days since upload. This is *not* a part of the proposal; I have merely played around with data that I thought was useful in gauging the activity of each package. In any case, I hope the mockup site will help you see how the proposed workflow will look in practice! I am grateful to Siegfried Gevatter (RainCT) for his patience with all my stupid questions concerning the revu code! Cheers, Morten [1] http://dmz-212.daimi.au.dk/~mok/revu/ [2] https://wiki.ubuntu.com/REVUWorkflowProposal -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Widelands 13
j...@marvec.org wrote: I'd like to ask whether there are any plans to update Widelands in Ubuntu 8.10 to version 13 which is already out for a while... You have to request a sync at Launchpad. I did it for you this time: https://edge.launchpad.net/bugs/327557 Cheers, Morten -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: New LP-liason MOTU Leaders
On 03/02/2009, at 01.02, Scott Kitterman wrote: Now that I've read the input, I find that in many significant respects it does not reflect my interests as a MOTU. As an example, Do an emergent heat on PPA's, which would quietly factor in downloads, subscribers, karma of uploaders etc. is listed as #3. I'm fairly certain as a MOTU I really don't care. Another example is Soyuz instant messenger buddy (XMPP). For notifications of important events like build failures. Probably not limited to Soyuz. I know I don't need that. Email works great for this stuff. Just for the record: I am fairly sure it is a typo that the PPA heat got priority 3; that placement is indeed occupied by another item, namely Package sets. As I recall it's position was near the bottom. We included it for a good reason. Wrt. the XMPP notification, it is yet-another-notification-method that we judged might be attractive to some. If people prefer email notification, that is of course still available. However, we were told that only the first 10 priorities matter, so its placement near the bottom of the list is without consequences. Cheers, Morten -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
New LP-liason MOTU Leaders
Hi MOTUs, Due to lack of time, Reinhard Tartler (siretart) has chosen to resign as the MOTU Launchpad Liason. William Grant (wgrant) and Morten Kjeldgaard (mok0) have stepped forward and will share these duties. The Launchpad Liason provides Launchpad developers with prioritized bugs/specs relevant to MOTU and MOTU with information on Launchpad changes and progress. Because of limited time, and also due to the lack of a satisfactory solutions for conducting a proper poll among the MOTUs, William and Morten have already -- on behalf of the MOTU -- given the LP developer team feedback on the priorities of the MOTUs for the LP 3.0 development cycle (see https://dev.launchpad.net/VersionThreeDotO/Soyuz/Inputs column T). We focussed our attention on features we judged would be of importance and of concequence to the day-to-day work of the MOTU. In the future, we will attempt to find a more satisfactory solution to getting broader input from the whole team. Cheers, Morten -- Morten Kjeldgaard m...@ubuntu.com Ubuntu MOTU Developer GPG Key ID: 404825E7 -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: New LP-liason MOTU Leaders
On 02/02/2009, at 22.15, Scott Kitterman wrote: However good this list may be, it has no legitimate basis to be considered a MOTU input. Part of our process for role transfer includes a chance for community review of such delegations. Until this has happened (I guess we now have that chance), I don't see any legitimacy to speak on our behalf. Alternatively, this list could have been based on input from the community. That didn't happen either. I'd like to ask you to withdraw this subission and instead give the community a chance for input. Your concern is completely legitimate. However, it was short notice, and wgrant and myself decided that we would try to represent the interest of the MOTUs as well as we could. We took this chance because none of the items on the list seemed really controversial. The items we chose to prioritize have to do with making our life as MOTUs easier, such as getting more efficient buildds, a user-interface for doing rebuilds easily, etc. Please take a look at the list. if anyone has any serious objections to our choices, please give us feedback and we'll see if we can get changes accepted. (Since there are N! ways of arranging N items, you should probably try to make your comments general in nature.) I hope this procedure will be acceptable to everyone. Cheers, Morten -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: New LP-liason MOTU Leaders
On 02/02/2009, at 23.40, Emilio Pozuelo Monfort wrote: I'm with Scott here. There should have been a call for volunteers as in the past. On 03/02/2009, at 01.02, Scott Kitterman wrote: I do not think this can be considered a MOTU input. Fair enough. Personally, I will then take the consequence of this and step back as LP-liason, and make the position available for other volunteers. Unfortunately, William Grant is travelling without internet access and can not be reached at this time. He will have to make his position clear when he returns. The other consequence is that I will ask that the priorities made by wgrant and myself be nullified. Cheers, Morten -- 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 revised REVU workflow
On 25/01/2009, at 05.39, charliej wrote: Two quick questions 1. Would anyone be able to review and leave comments on packages (as it is now), or would reviewing packages be a MOTU only activity? The reviewing and commenting procedures would not be changed. I think that REVU generally is very useful and works very well as a reviewing tool. It is certainly the best solution of any Linux distro I am aware of. For users of REVU, there would be mainly two differences from the present situation. Firstly, the page with the long list of packages that we have now would be partitioned into several pages, according to how far you've gotten in the process. Packages will spend the longest time on the In Process page, and so the user experience would be exactly like now, except the view would not be cluttered by other packages in different stages of development. The In Process and Advocacy pages would still have a needs- review and needs-work section. Non-MOTUs will still be able to comment, in fact it's a great help when people do that. 2. If I read your proposal correctly REVU would only be open for uploads from the beginning of the release cycle to feature freeze? Exactly, that's the second difference users will experience in their use of REVU. NEW packages that users want to have reviewed will enter the Unreviewed page. So yes, a reasonable way to use this incoming page would be to close it at Feature Freeze like you say, or perhaps slightly before. But the MOTU team could also choose to close it for say, a release cycle, if they want to focus on another effort during that time. However, while the close is in effect, uploads will still be possible for packages In Process, so the reviewing does not stop. I think the Ubuntu community will accept that solution, especially because people can sort of have their package in Ubuntu via the PPAs, to the benefit of themselves and their friends. And the community can also maintain their packages freely in bazaar on LP. I hope it's clearer now! Cheers, Morten -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Proposal for revised REVU workflow
I have written up a proposal for an updated workflow for our REVU, please see: https://wiki.ubuntu.com/REVUWorkflowProposal . The proposal is not wildly different from what we have now, it is more of a re-structuring. I think it can be implemented with quite few modfications to the existing software. I hope we can discuss this proposal at the next MOTU meeting, I have taken the liberty of putting the issue on the agenda. Cheers, Morten -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Hello there
On 22/12/2008, at 08.16, Daniel Holbach wrote: Take a look at https://wiki.ubuntu.com/MOTU/GettingStarted - it explains how to work with the MOTU team, how to get patches included, where to find documentation about packaging, etc. On a side note, this page is quite outdated, and furthermore, it seems to point people in the wrong direction: One of the best means of contributing to Ubuntu is by helping to package the thousands of different free software applications available. This statement encourages people to start packaging software, a road filled with frustration and -- given the huge backlog at REVU -- a long waiting time before you feel that you start contributing. I am afraid that many Ubuntu fans and prospects are lost with this approach. I think we need to re-think this introduction as an _educational effort_. And I think the FIRST thing newcomers should be taught is how to use Launchpad, how it is structured, how the developers use it, and how the newcomers can help the developers by reporting bugs and triaging. Another very useful and easy thing a newcomer can do is to help with translations. Rosetta is a wonderful tool, it's really easy to use and you immediately feel you are being useful. Some newcomers are experienced programmers and packagers already, and although we should channel these people into a different direction, it is still really important that they know how Launchpad works (it's not always obvious, even to a tech-savvy person :-)). Perhaps everybody should be required to have triaged a certain number of bugs successfully before being allowed to move on in the training process. I volunteer to draft a new GettingStarted page, and I will collect with gratitude any contributions from this list or otherwise. Cheers, Morten -- Morten Kjeldgaard m...@ubuntu.com Key fingerprint = FC53 53B2 81D1 27CA 45D5 F864 078C F31B 4048 25E7 -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: what compat level for debhelper in jaunty?
Scott Kitterman wrote: using a debhelper 7 feature and having a backport fail, but as a general rule overspecifying the required version is frowned upon as it complicates backports and is just not correct. That makes sense. If you are using a basic set of debhelper scripts, there is no reason to require features you're not using be present. Lintian on the source package is able to tell you if you've used a feature not available at the given debhelper version. However, it would be quite useful to have a table of dh_* scripts specifying at what compat level and debhelper version they were introduced. I've not been able to find something like that anywhere. Btw, I'd like if someone could explain what good debian/compat is, now that there are versioned depends and e.g. dh_lintian requires debhelper = 6.0.7~ and dh_icons requires = 5.0.51~. In these cases, compat could be correct and the build would still not work if the microversion of debhelper was not up to specifications. Couldn't debian/compat be dropped? Cheers, Morten -- 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: monodevelop
On 20/11/2008, at 13.26, Sarah Hobbs wrote: The harm has already been done by letting monodevelop into the distribution. Although I would advocate a removal, the next-best thing is to leave monodevelop at version 1.0 Morten, this is a packaging list. This is a list for getting stuff done. Exactly. I am proposing not to do anything. Cheers, Morten -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Outdated New Upstream Review proposal on the wiki
Hi, The New Upstream Review proposal described here seems outdated and never upgraded to policy: https://wiki.ubuntu.com/MOTU/Meetings/2007-11-05/NewUpstreamReview The document states that it is only tentative, and the Meetings Minutes referred to at the end of the document does not seem to finalize the proposal. It mentions the use of interdiff, which is deprecated? I propose as an agenda item for the next MOTU meeting that this issue be resolved, and the policy finalized. Cheers, Morten -- Morten Kjeldgaard [EMAIL PROTECTED] Key fingerprint = FC53 53B2 81D1 27CA 45D5 F864 078C F31B 4048 25E7 -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Doubts while creating a new package
On 17/08/2008, at 13.06, Jose Luis Blanco wrote: Firstly, sorry if this is not the mailing list for asking these questions. I've been packaging a new set of libraries of programs for Ubuntu and uploaded them to REVU: http://revu.ubuntuwire.com/details.py?package=mrpt Normally, you'd want to look for comments either on the #ubuntu-motu IRC channel, or on the REVU webpage itself. 1) I haven't sent this to Debian yet, so this package is not a derived version of any previous one. Should I still add the postfix -0ubuntu1 For a package not in Debian, -0ubuntu1 is indeed the correct format of the release string. to the package? (there are not specific changes in the sources for Ubuntu). Should I instead leave the changelog with unstable distribution and rename the package -1 so the same package can be used If the package is submitted to Debian later on, it will receive a release string of -1 which eventually will override the -0ubuntu* version. for Debian Ubuntu? Is there any problem in leaving unstable instead of intrepid? At this point, new packages go into intrepid which should be given in debian/changelog. Lintian will complain, but that is one of the few warnings you are permitted to disregard. 3) I've built the new package with pbuilder for intrepid sid under i386 amd64. Is there any other architecture I should tried for Ubuntu?? Most people don't have access to more than one architecture, and you can't be expected to test out things on a platform you don't have. If you do have access to some of the more exotic architectures, you may help yourself by testing the builds. Some applications may not work on all platforms, often due to the build system, so you are making your own life easier. Cheers, Morten (mok0) -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
A blog for the MOTU?
Some time ago, dholbach and mok0 were talking on IRC, and came to the agreement that it would be useful to have a blog for the MOTU, like the server team has one. A blog would be orthogonal to the other means of communication that we use: - Mailing list - Wiki - IRC - Launchpad bugs Each of these have their own justification: Mailing lists: + Very useful for announcements and messages. - Less suited for discussions that are often hard to follow, because there is a lot of noise. Messages in a thread tend to become longer and longer because many people are not disciplined in editing the thread, and some even do top posting (tsk tsk! Very bad habbit!). - Usually no good way to tag/categorize things (depends on your email client). - mok0 regularly cleans out old entries (follows 30 mailing lists), so he has no long-term archive. You can go to the mailman archive for old stuff, but that has _terrible_ search facilities. Wiki + Mostly suited for static article style, HOWTO and FAQ information. + Great for casual, user generated information + Suited for summing up discussions, but has: - no structured comment system. - Information may be scattered. Contains a lot of orphan documentation. - Information difficult to keep up-to-date. +/- Everyone can edit IRC: + Truly great for casual discussions and for creating the atmosphere in the developent teams! - Not suited for lengthy explanations, but + excellent for ping-pong style questions/answers. + excellent for teaching and help LP bugs: + Great for having a very specific. technical discussion on a subject -- usually a bug in software but could be other things like ideas. + Good for including files like patches, screendumps, etc. - Bad for announcements and general discussions A blog would give some orthogonal capabilities, and would help develop the community in a helpful way. MOTUs can post a wide variety of messages: educational, entertaining, new ideas. Useful properties are: + Comment system, so all these things can be discussed. + Nice window for the MOTU team to the outside world + Importantly: errors, wrong information etc. can be edited and fixed. + Information can be tagged, and reorganized at any stage. + Additional information can be added to content at any time. + Can host (edited?) important information and discussions from mailing list + text can include formatting, images, etc. + Can be made visually attractive + Somewhat useful for announcements + Many good ways to read blog (can be aggregated) +/- Can be hosted externally (e.g. wordpress.org) - Not suited for messages In addition, if the blog is run on a MOTU controlled machine, QA pages can be integrated directly. We feel that it is only a good idea to establish a blog if there is a critical mass of MOTUs that want to contribute. The blog would be an offer and opportunity for MOTUs to write various Ubuntu/MOTU related stuff for the Internet. It could perhaps better express the soul of the development team than some of the other avenues of information do. Currently, there is a lot of MOTU-related information scattered on several different systems and servers. It may seem to be a bad idea to introduce yet another one, but on the other hand, it could be a logical place to assemble the many threads, and if successful, the blog could be the main portal to the MOTU world. The blog should be voluntary, no one should be forced to using a tool they don't want to. Cheers, Morten -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: contributions
ScottK wrote: This would help with preventing duplicate work, but I do see how that would address my concern about having to wait to get a bug number? AFAICS there is no reason why the claim-merge.py script should not be able to return the bug number right away. -- Morten -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: A call for a packager [memaker]
On Friday 16 May 2008 06:34:38 Jason (spot) Brower wrote: There is a program that I and some friends have been working on that makes Avatars that can be used in mnay ways. One of the most common ways is for your chat login picture. If anyone is willing to help package memaker please respond. You can even contact me personally threw my Jabber Account. encompass gmail com. This looks like a cool and fun application! I am many people would like to give a hand in this. However, I'm a bit puzzled here, because there already seems to be a memaker package in Ubuntu: https://bugs.edge.launchpad.net/ubuntu/+source/memaker Is that not your application? Cheers, Morten -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Use of hfsprogs in Ubuntu
Rogério Brito wrote: I have updated the package hfsprogs with a new upload to Debian (which has not been incorporated in intrepid yet), but the package has a catch: it is not 64-bit clean and I have to resort to some hacks for compilation under my amd64 system (actually, a Pentium D with Debian unstable). I would like to ask you two things: 1 - would it be possible to upgrade the package from the Debian repository? Packages in Ubuntu are synchronized with packages from Debian/unstable at regular intervals. At the moment, packages are getting sync'ed into Intrepid. 2 - since I plan on packaging it so that it compiles on all arches available on Debian, I would like to ask if any of you would like to help me with this task in a cooperative way (I plan on creating a repository on Debian's Alioth service). We do uploads of source code (actually: source packages) that are compiled on a set of build-hosts without human intervention (and so does Debian). It is not possible to tweak compilations on a particular machine and upload binary packages. Therefore, the package should be able to handle the different architectures automatically, and if something special needs to be set (compiler options or such) it should be take care of in debian/rules. It is more difficult to handle different patches for different platforms, and although it can be done, it is discouraged. The closest to being acceptable is passing different arguments to ./configure, and of course your code can rely on #ifdefs etc. Putting your project on alioth is a good idea, and perhaps your best bets is to collaborate with the Debian maintainers to get the package compile working. Then those packages will quickly show up in Ubuntu. Cheers, Morten -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: contributions
It seems the main concern of many of the posters in this thread is that you may have a package you care about and would like to maintain, and you do not want a random contributor grabbing it in front of your nose. I am a big believer in letting computers solve as many problems as possible. That way we humans don't need to argue needlessly :-) The concern above can be solved if people subscribe to bugmail for a specific source package that they want to claim. If that involves several people, they will have to work it out among themselves. This can be detected by software (i.e. MoM or other automated procedures) and a note could be given that a given package is claimed and should not be touched unless otherwise agreed. My guess is that the number of claimed packages is rather small, and that in most cases, the last merger will be happy that someone else carries out the next merge. Cheers, Morten PS: At the moment, there is collective maintainership of all packages in Universe. Does this discussion in reality stem from a wish that Ubuntu maintainership of some packages should be possible? If so, that question should be dealt with politically. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: contributions
Jordan Mantha wrote: My feeling is that the best way to help make sure this kind of thing doesn't happen is to have *one*, canonical place to track merges. Launchpad bugs seems to be the best way we have of doing that currently. Basically, file a merge bug if you're going to be working on a merge and *all* people working on merges, including MOTU sponsors, should be looking *first* to see if somebody has already filed a bug before working on it. I agree with Jordan. Using LP to track the progress of merges is the only realistic way to go if we are to avoid that people are duplicating efforts, and that MOTUs short-circuit the endeavors of contributors. ScottK wrote: Personally I'd find a file a bug first rule very demotivating. One more rule to convince me to spend my time on other things. It _should_ be possible to write a simple CLI tool that would submit an email merge request to [EMAIL PROTECTED] given a package name and -version. The script could fill in the necessary fields, assign the bug to the submitter, gpg-sign the message, etc. Although it may be a bit of a bother to some of the more proficient and experienced MOTUs, the reward is a greater satisfaction on the part of the contributors, as well as a better documentation of the merging workflow. Another possibility is to let MoM file the merging bugs as the merges are processed. I can't overview the consequences of this, though. Cheers, Morten -- 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
IMHO there are many good reasons to maintain the 2 ACK requirement for new packages. As someone who has contributed several packages through the REVU system, I admit that I was initially frustrated with the slow and circumstantial reviewing procedure. However, the advantage of the system gradually became clear to me, and I became quite impressed with the great care and professionalism that was put into the review of each and every package. Needing two advocates for my packages forced me to use IRC and get to know people. It quickly became clear to me as a contributor that getting your stuff into Ubuntu is not something you just do. It takes perseverance and hard work. This contributes to giving the Universe a good reputation in the free software world. And, it ensures a top notch repo. Needing two ACKs from MOTUs has nothing to do with not being able to trust just one.The scientific world uses a peer review system, with two, three or more reviewers involved, and that system is not based on a lack of trust. It's simply a sensible QA procedure. For the MOTUs, there is an additional advantage involved in requiring co-sponsors, and that is the development and maintenance of an interacting and collaborating culture. If MOTUs could simply grab an upload from REVU, review and sponsor it, they could in practice work in parallel universes without ever having to interact. The package review system may need a service check, and it is always constructive to see if a workflow can be improved. But let's not abolish a reasonable up-front QA procedure. Cheers, Morten (mok0) -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Please use LP subscriptions correctly
Just becoming MOTU, I've found myself often checking the bugs tab of u-u-s, perhaps in the hope to catch a bitesized upload :-) I appears to me that a lot of the bugs in the u-u-s list shouldn't be there, because they are not ready for sponsorship/upload. A lot of them are sync requests without ACKs from motu-release. I've gone through several of them, unsubscribed u-u-s and subscribed motu-release instead, so the bugs will be listed there for processing. It would be helpful if packages were not subscribed to u-u-s unless they are ready to upload, i.e. with the required acks. Once the motu-release team are done with them, they will unsubscribe themselves, and subscribe u-u-s so someone else can build/check/upload etc. Adhering to this scheme will make the most efficient use of the limited human resources we have available. Cheers, Morten (mok0) -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Open source tracking system...
Hey, Hewlett-Packard has launched [1] a very cool open source tracking tool called FOSSology. If you check out the FOSSology website [2], there is a short video showing how the tool can be used for example to analyse licenses of open source projects. This tool is something that would be extremely useful for maintaining Universe, and the License browsing feature is awsome. Take a look! Cheers, Morten [1] http://www.computerworlduk.com/toolbox/open-source/applications/ news/index.cfm?newsid=7095print [2] http://fossology.org/ -- 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 REVUers
Emmet wrote: With only four weeks to go to Feature Freeze, it would be nice to make a call on the packages on REVU before feature freeze. I'd like to ask for more reviewers to take a look at a package or two, and either point out some problems or advocate it for inclusion in Ubuntu. In addition, I would like to ask for a MOTU volunteer to specifically collaborate on the TORQUE package, which is now in REVU. I have done the grunt work, it's gone through a couple of cycles of reviewing by persia and minghua, and I estimate that the package is 90% complete. It is, however, a complicated packaging with 10 splitoff packages, init maintainer scripts and the works. I imagine with such a complicated package, it will be difficult for me alone as a non-MOTU to get it finished in time for Hardy. I will be a lot of back and forth on REVU and waiting for someone to have time to get acquainted with the package and review it. For those who don't know, TORQUE is a batch queue client-server system, especially designed to be the user front end of a computing cluster. It would be really good to get this into Hardy, especially since Mark Shuttleworth's vision for UL2008 includes: large-scale government deployments of Ubuntu on the desktop (there have now been several) specialist deployments, for example high- performance computing clusters, or vertical market solutions Torque is a piece of key software for a HPC cluster! So, if there's a MOTU out there willing to put a bit of work in helping me get the package done in time, it would be most welcome! Cheers, Morten (aka mok0) -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Naming problem for the Falcon Programming Language in Ubuntu.
Scott Kitterman wrote: My suggestion is to call your package falconpl as you've said you would and then conflict against falcon. After that, we can let the market decide. If one of these packages gets popular enough to cause the other difficulty with the conflicts, then the less popular one will move their file in /usr/bin. I second that. I seems to me that Giancarlo has not understood what several people have already attempted to explain on IRC, and that Scott also writes above. Thus, let me try again to make it clear: It is required that there is no package name clash, and by choosing falconpl as the package name, that has been achieved. The remaining problem is the clash of binary names. Dpkg has a way of dealing with that, and that is the Conflicts: tag in debian/control. This ensures that the packages falcon and falconpl can not be installed at the same time on a given computer. But that is a small price to pay, and given the small user bases of Falcon the programming language, and falcon the repo manager, the likelihood of a situation where a user wants both packages installed, is close to nil. We already have git the VCS and git the GNU file browser (git-core vs. git). I am sure that there are numerous other program name clashes in Ubuntu/Debian; programs with generic names like display, show, merge, find, link, config etc. are common and countless. I see no point of making a big fuzz about this rather trivial problem. Put a Conflicts: tag in control, and Bob's your uncle. Cheers, Morten (aka mok0) -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Order of packages on REVU
Emmet Hikory wrote: I'd like something a little more complex: First: Oldest-first list of packages where there is at least one advocation, and any comments after the advocation are by the uploader. Second: Oldest-first list of packages where any comments since the last upload are by the uploader. Third: Oldest-first list of all remaining packages And perhaps in three separate tables with a heading containing the above explanation. -- Morten -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Suggestion for reviewing guidelines
I have started to use my PPA as a development platform for packages that are not quite ready to go into Universe, perhaps awaiting upstream action on issues like missing gpl clause in source files and such. In the meantime, my lab can benefit from the PPA as a repository for packages that can actually be installed and used. When using the PPA -- I always forget this initially -- you (often) need to specify universe/* in the Section: field of the control file. I gather it is also customary to add ~ppa* to the end of the release string. In addition, I find it useful to use debian/changelog to record work I have done between the different ~ppa* versions (and perhaps new upstream versions). When time is ripe, I will submit these packages to REVU, but I fear the first things reviewers will say is: 1. Remove the ~ppa* from the release, 2. Delete all your changelog stuff, 3. Remove universe/ from Section: I would suggest a procedure that would allow for such issues. (AFAIK, In Debian, they encourage you to record all packaging changes in changelog). Cheers, Morten (mok0) -- Morten Kjeldgaard, Asc. professor, Ph.D. Department of Molecular Biology, Aarhus University Gustav Wieds Vej 10 C, DK-8000 Aarhus C, Denmark Lab +45 89425026 * Mobile +45 51860147 * Fax +45 86123178 Home +45 86188180 * http://www.bioxray.dk/~mok -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Files added to a package? Patches or files in debian/?
Is there a consensus on what to do when you are adding files to a package? I am thinking for example on a situation where I am authoring a complete autotools system to a software package, and upstream is, say, dead or unresponsive ;-) Of course, I can add these as patches against /dev/null, but that honestly seems a bit awkward. An alternative is to put the files in debian/ and let debian/rules move them to their proper place in the directory tree. What say you, oh MOTUs? Cheers, Morten aka mok0 -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
