Re: FreeNX complete suite uploaded.
On 24/01/2009, at 05.44, Marcelo Boveto Shima wrote: > I have been maintainining the FreeNX complete suite for at least 2 > years > and now I uploaded it to revu. I've reviewed this package when it was uploaded under the name "nx" and before it was split. In the comments, I asked you to clarify what version of nx it is you've uploaded. It was not at all clear to me, since the source tree contains lots of material with reference to Nomachines. Those comments are no longer accessable because the original package has been archived. Since you are now advertising your re-packaging on the mailing list, you might as well explain it here. In the interest of making a clear distinction -- if there is one -- may I suggest that you name the packages "freenx-*" instead of "nx-*"? Thank you, Morten -- Morten Kjeldgaard 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: REVU: Automated Package Checks
On 23/01/2009, at 18.17, Jordan Mantha wrote: ... a long post with points that I agree with and others that I don't. A very good outset for discussion! Just a short comment on one of your points, Jordan: > 1) New contributors are not to be encouraged to package from scratch. > If somebody wants to go for it anyway, they will be expected to be the > primary maintainer of the package and should give a rationale beyond > "dunno, I just wanted to package something" for including it in > Ubuntu. MOTU documentation should be fairly clear that generally > people should try some other packaging tasks before try to package > something from scratch. I agree that new people should be pointed in a different direction, which is why I have drafted a new "getting started" document with the specific purpose of getting people involved with things other than packaging new stuff. The document is still quite imperfect and it would be good to get more ideas and more contributions! https://wiki.ubuntu.com/GettingStartedDraft Go edit! Specifically, it would be nice to get more qualified input from folks in the bugsquad, the locos and in the ubuntu art teams! Cheers, Morten -- Morten Kjeldgaard 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: REVU: Automated Package Checks
Loïc, Nathan, It is in principle possible to transform REVU into a super- sophisticated package-analysis machine that would extend Lintian's capabilities and it is even in principle possible that virtually error- free packages would result. The point is, it doesn't solve our problem, because at some point, a human being needs to have a look at the package. Even if all packages were perfect, we still could not handle one review plus an upload with the current activity of MOTUs. In addition, having this automatic checking would not change the rate of arrival of new packages. Our rate of processing is less than the rate of arriving packages, and consequently the pool of packages awaiting review is constantly increasing. A second point is, that no matter how sophisticated the program, it will not be able to solve issues that are common with many of the packages. F.ex. that the package has to be split into several subpackages, which often is a point of discussion, that the description is not understandable, that files need to be removed from upstreams tarball, etc. etc. There are lots and lots of issues that could never be detected automatically. Thirdly, and most importantly, is the personal interaction we get with the uploaders, and in this regard the simple things people are asked to fix is often a useful beginning. It gives you an opportunity to judge the qualifications and personal qualities of the uploader, and it tells you if the uploader is truly interested in doing some work. So, in my opinion, REVU is a very good tool already that fulfills it's purpose very well. What is lacking is the involvement of more MOTUs. 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: REVU: Automated Package Checks
On 23/01/2009, at 00.30, Nathan Handler wrote: > For those of you who might be unaware, I have taken over Siegfried > Gevatter's (RainCT) role of REVU Coordinator. For the past few days, I > have been thinking about something, and I want to get the opinions of > the rest of the people in the community before taking any action. ... and kudos to you for taking on this task, Nathan! I am not sure that more automated package analysis well help much. The uploaders already have Lintian and other tools at their disposal, yet the fact is that many packages have lots of Lintian issues remaining on the binary packages. When people upload to REVU, they have read all the guides and tutorials (at least some have) and what they really want is a human being to look at it, and to get advice on what to do. Many see the warnings by the various tools, but simply don't know what to do about them. Or, they feel unsure on where to go and don't want to spend a lot of time going in the wrong direction. The REAL problem with REVU is that not enough MOTUs care about it to enable us to keep up with the demand for reviews. IF we want this interaction with the community, this way of meeting and training new developers, we really have to do more! If we don't, we should consider closing down REVU. Personally, I don't think it's a good idea, but it is even worse having a queue of over a hundred packages where uploaders are waiting months between review cycles! That is detrimental to our standing respect in the community. The large number of packages in the "needs-work" section is also testiment to the number of uploaders who have given up, and every one of those is a potentially useful contibutor lost. Those still hopeful of getting their packages processed generally re-upload quite quickly, and so their package can wait for another month or two. This is BAD. As someone who has been doing lots of REVUs this cycle, it is quite depressing seeing that no matter how hard you work, the list keeps growing, and the packages you advocate do not attract a second advocate. As a temporary measure, to get rid of this long queue, perhaps we should only require one advocate for an upload? This is what Debian does, and I'd like to suggest a discussion of that on the next MOTU meeting. Cheers, Morten -- Morten Kjeldgaard 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: Using Brainstorm for packaging requests
On 19/10/2008, at 00.25, Caroline Ford wrote: > Having them in malone makes them easier to link to the Debian request > - and we can see if the status changes in the Debian bug. This means > it is easier to see if the request has been satisfied. Agreed. We have our stuff scattered all over the Internet already. No need to introduce yet-another site for doing something that is quite adequately being tracked in LP. And, as ScottK pointed out, we now have the "affects me too" field that people can tick . I think we need to direct our actvities towards LP, and engage actively in work to get it to do what we need, in the way we want it. With the upcoming opensourcing of LP, it's going in the right direction too. 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: REVU: [ubuntu/jaunty] foo-plugins 1.0-0ubuntu1 (New)
On 23/01/2009, at 08.00, Jordan Mantha wrote: > Is there an easy way that we can include a description of packages in > the REVU emails? I really like seeing what's new from REVU but I'm > always a little disappointed when I look at the email and I can't find > any idea of what the package is. Even the short description would be > nice. I miss package descriptions everywhere, on packages.ubuntu.com, on launchpad.net's +source pages, on REVU, on DAD, MoM... Whenever you grab a package to look at, it is really nice to see what it's for. When I first met the foo-plugins package, I thought its name was a bad joke. On 23/01/2009, at 08.09, Emmet Hikory wrote: > Do you think they > should be exposed in the .dsc or .changes files? That's a wonderful idea, and if that was done, it would be a small step to include package descriptions in the webpages mentioned above! Cheers, Morten -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
All hands on deck! It's REVU day!
Hi MOTUs, It's Friday, Jan 23, 2009 and it's REVU day! We need all MOTUs on deck! A similar plea was sent out last week, but to not much avail. We really need MOTUs to go and make at least one review. This week we have ~128 packages waiting for review. That's an increase of > 15% in a week! The REVU regulars can't keep up with that growth. As I wrote last week, each upload deserves at least _one_ review. If it after that gets stuck in "needs-work" status, so be it. Perhaps someone else will come along later and care for it. Come along on #ubuntu-motu, get a friendly chat and brush up on your rusty reviewing skills! Cheers, Morten -- Morten Kjeldgaard 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
All hands on deck! It's REVU day!
Hi MOTUs, We are already well into REVU day, and we have > 100 entries sitting in the queue waiting for a review. You may not think that reviewing is the most sexy MOTU task, but as long as we refer newcomers to REVU, we owe it to the community to review uploads. Each upload deserves at least one review. If it after that gets stuck in "needs-work" status, so be it. Perhaps someone else will come along later and care for it. But, in fact many of the packages have gone through several rounds of reviewing and can soon be finalized, and their uploaders are anxiously waiting. There are many exciting software packages to look at, and many that would be a big plus for Ubuntu users. So come along on #ubuntu-motu, get a friendly chat and brush up on your rusty reviewing skills. Cheers, Morten -- Morten Kjeldgaard 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: xTide transparent
On 12/01/2009, at 10.45, Geerd HF Diercksen wrote: > > /var/cache/apt/archives/xtide-wvs1-data_20020219-0ubuntu1_all.deb: > trying to overwrite `/usr/share/xtide-wvs/wvs1.dat', which is also in > package xtide-coastline. xtide-coastline is a package from Debian with the same content as xtide-wvs1-data, an Ubuntu package which has now been removed. You should remove xtide-wvs1-data and install xtide-coastline, but for the function of the program it doesn't matter. 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: Getting started wiki page
On 12/01/2009, at 05.10, Jonathan Marsden wrote: > > Also, I think adding a table of contents to the page would be good (I > just did this!). Great, that makes it easier to get back to the section you are working on! Ideally, I would have liked some kind of check-box for every exercise that people could tick off to mark how far they've gotten, but I don't think that's possible within the Moinmoin framework. I started the exercise sections as a way to put in links to explore, but with the implicit message "come back here when you're done reading". In general, I think the problem with the Wiki approach where everything is marked by a link is that it's easy to get lost and distracted. Therefore, when you add a link to the document, consider formulating it as an exercise for people to do. > One idea: Perhaps each major section should > have a "Further Resources" bit at the end which links to more detail > about the particular topic concerned > (Launchpad/Triage/bugfixing/packaging/whatever)? I think it's better to save all the "Further Reading" links until the end of the document - where they could be organized in a table or list corresponding to the content. The reason is not to distract the reader too much from the flow of the document and exercises. So again: if there's a link you think is vital for the reader to visit, consider formulating it as an exercise, possibly with some questions to answer afterward. > I'm slightly confused as to the expected path users (wannabe community > members) would take to get to this page (say from http://www.ubuntu.com > ) > and (if they are MOTU-wannabes) from here to MOTU-specific material. > How does the new more general GettingStarted page you are creating > relate to existing non-MOTU-specific pages of a somewhat similar > nature, > such as https://wiki.ubuntu.com/UbuntuDevelopment and > https://wiki.ubuntu.com/ContributeToUbuntu ? The current "Getting Started wit h MOTU" document is the one we've been pointing newcomers at, but I think that document misses the mark and turns away a lot of not-so-technical people. On the other hand, MOTU-hopefuls also need to learn about the workflow, so the general introduction is a fair requirement before going into the more MOTU- specific stuff. So my feeling is that all community wannabes should be pointed to this document as their first step, and the document should help them find out where they best can help out. 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: Getting started wiki page (was: Hello there)
Hi, >> I volunteer to draft a new GettingStarted page, and I will collect >> with >> gratitude any contributions from this list or otherwise. > > Excellent. > I'm happy to review, improve and discuss. The only thing I'd like > MOTU/GettingStarted to be is > - a concise landing page > - that links to all the important pages (so we have one good answer > and > the new contributor one page to bookmark) > - and gets people a sense of direction I have now produced a draft page at https://wiki.ubuntu.com/GettingStartedDraft , incorporating all ideas contributed to me (the number is zero ;-)). The main idea is to give a gentle introduction suited for the people we meet on the mailing lists or IRC asking "Hi, I'm interested in Ubuntu, how can I help out?". The current introduction aims at steering people directly towards a MOTU career, but I have adopted a completely different strategy in the draft document. With this approach newcomers are taught: * Launchpad * Bug work and triaging * The workflow of packages in Ubuntu * How Ubuntu development is organized in the various teams * The Ubuntu release model (not yet written) The document includes practical exercises that gets people started with various tasks that most of us use every day. People are invited to join mailing lists and IRC, show up and ask questions, examine various Launchpad pages etc. It is always difficult to arrive at the right level of a training document. However, even the most experienced developer does not (necessarily) know how Ubuntu's bug flow works, and will benefit from an introduction. The document is a draft, with a lot of shortcomings and lacking features, but it does outline an alternative educational approach that I think could be useful and productive. Please feel free to add and/or correct the Wiki document, so we as quickly as possible can start a systematic and fruitful education of new Ubuntu enthusiasts with a desire to help out! > Agreed, though I'm not sure this should be in the MOTU namespace - > what > do you think? Yes. I think the MOTU namespace should only contain material that is strictly relevant to the MOTU team. We need a "howto become MOTU" page; the current MOTU/GettingStarted perhaps needs some revision based on the more granular training we now have with the new Ubuntu Contributor team. Cheers, Morten -- Morten Kjeldgaard 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
Fun with oneliners
Hi all, this is a long-ish post, but I hope you will enjoy it.
The other night I was discussing with persia, apachelogger and
norsetto on #ubuntu-motu, where they were using their awesome MOTU
powers to demolish my poor little theseus package.
While apachelogger was disassembling and devastating the files in
debian/ one by one, persia was vehemently attacking a little awk
script that I used in the package. I'll make a long story short, and
just say that I needed to extract the upstream version number from
debian/changelog file from inside debian/rules.
My approach when scripting is always to try to use a little hammer
first. If that doesn't work, I'll use a bigger hammer, and if _that_
doesn't work, I'll use a giant hammer.
The first line of the changelog file, which I am interested in, looks
like this:
theseus (1.1.5-0ubuntu1) hardy; urgency=low
Due to the strict format of the changelog file, it will always look
like that, but of course the version numbers etc. kan vary. I am
interested in extracting the string "1.1.5". So, first, I pulled out
my little hammer, which consists of a pipeline of standard shell
tools, such as head, tail, cut, sort, etc. The following little
hammer solves the problem.
head -1 changelog |cut -f2 -d' '|cut -f1 -d'-'|cut -f2 -d'('
What's wrong with that? Well nothing, it's just, kinda ugly. We can
do better. I pulled out the bigger hammer, sed, but within a minute
or two it grew sour on me and I took out my favourite big hammer,
awk. Awk is indeed awesome, it's an incredible tool, and if you don't
know it, you're missing out. Awk is extremely powerful, and very easy
to understand. An awk script is basically a series of patterns and
actions, like so:
/pattern/ {action}
If the pattern - an ordinary regexp - matches a line, the action is
performed on that line. The stuff inside the curly brackets is very
reminiscent of C syntax, so if you're familiar with that, you're off
to the races. In fact, awk is so powerful, that Henry Spencer has
written an nroff formatter, called awf, in the language (sic!). Henry
writes he can't believe he wrote it. Neither can anyone else :-)
There are several flavours of awk. I like gawk, which is the GNU one.
It contains several extensions to the original language. So, here is
the gawk oneliner that extracts the version:
gawk '{match($0,/\((.*)-/,arr);print arr[1];exit}' < changelog
As you see, only the action is used here. We call the function match,
which actually takes over the regexp matching job normally carried
out by the pattern. Let's dissect the regexp.
First, it will try to match the initial left parenthesis, that is
what the \( is for. The next part is (.*), here the parentheses are
not escaped, so they have a special meaning, namely a grouping.
Inside the grouping, we look for an arbitrary run of characters. This
run ends when a dash is encountered. But now the grouping becomes
important, because the match function will place the matched pattern
in arr[0] - this is "(1.1.5-" in this case, and the groupings in the
following array elements. So arr[1] contains the desired string "1.1.5".
Well, as mentioned, persia didn't like that too well. You have to
Build-depend on gawk, he said. You can use mawk, said norsetto, it's
part of the basic build environment. Granted, the gawk binary is
293K, and mawk is only 93K. It's saving valuable resources!
Unfortunately, the "match" function syntax was not accepted by mawk,
so I got a syntax error. But, not to worry, of course it can be done
with mawk!
StevenK said: Why dont you just do: dpkg-parsechangelog | grep
Version | cut -d\ -f2 ?
Well, at this stage, we were into optimization, finding the very last
CPU cycle and the very last bit of RAM. It was becoming a dogma-film
like situation: we value the minimalist creative ideal. And dpkg-
parsechangelog is a Perl script. Yeeechh.
The next oneliner worked with both gawk and awk.
mawk '{match($0,/\(.*-/);print substr($0,RSTART+1,RLENGTH-2);exit}' <
changelog
In this awk dialect, the match function will set the beginning and
the end of the string that matches the regexp. It will not deal with
groupings, so the '()' surrounding the .* are gone. Another function,
substr, is used to extract the wanted version string from the input
string ($0). Mission accomplished. Success!
But no, no, no. Persia was still not happy. "I'll accept gawk, but
couldn't resist your last comment", he said, referring to a comment I
had made about efficiency. Persia pushed me back to using sed. He said:
"Isn't it just something like sed /^theseus\s\([\d\.]*\)-.*/\1/p |
head -1 "? And indeed, the size of /bin/sed is only 40K. A huge
saving of resources compared to gawk!
I copy-pasted it, but it didn't quite work. Hmm. Back to the drawing
board. Then I came up with another suggestion:
sed 's/.*(//; s/-.*//;q' < changelog
Let's examine the regexp again. It
Re: RFC: https://wiki.ubuntu.com/UbuntuDevelopment/Merging (Was: Re: WANTED: Merging Recipe!)
> I've write a recipe (or kind of) some weeks ago, you can found it > on my > blog [1] if you find it usefull just ping me and i'll be glad to copy > it to the wiki :D > > [1].- http://nvalcarcel.aureal.com.pe/?p=146 Very nice recipe, Nicolas! Thanks! My question is how you found the LP bug #? I actually find the merging workflow extremely opaque and convoluted. And LP is still a mysterious maze to me. Probably the messiest webtool on the Internet. But the layout is pretty ;-) I would find it logical that all packages that needed merging had a (needs-merge?) bug report but it is not possible (for me at least) to locate any. -- Morten -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: REVU by Contributors (was: Order of packages on REVU)
On 08/11/2007, at 11.58, Emmet Hikory wrote: > Morten Kjeldgaard wrote: >> Another thing is that experienced non-MOTUs should be able to review >> packages, which would help the flow through the pipeline, and also >> help >> the MOTO-hopeful getting more experience. > > I'd like to advocate the use of a pastebin during interactive > discussions on #ubuntu-motu for this purpose. It provides a means by > which experienced contributors can participate in package review, but > does so in such a way that 1) The comments are not persistant (in case > there is a mistake), 2) REVU Comments are directly related to > acceptances or rejections, and 3) MOTUs present in the channel may > oversee the review, adding comments where appropriate. > > I used this model as a contributor, and believe both that I > provided real help to the packagers, and that I learned a lot from > corrections by MOTUs when I provided suboptimal recommendations. One does not rule out the other. The problem is, as pointed out by Jeffrey, that dependence on IRC may turn away a certain class of developers. The point you are making concerning wrong advice from non-MOTUs could be taken care of by the web interface, e.g. corrective comments could be attached, the wrong advice comment could be deleted by a MOTU or some such. -- Morten -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Refining MOTU Mentoring
> We have a lot of contributors in this list, and I think it is the > right > time for them to speak up and share their thoughts. We need you guys, > and we need to know if what we do is valid or not. PLEASE ADD YOUR > VOICE! As a new contributor, let me add a few comments, then. As it has been pointed out by others, the reviewing process can be quite frustrating. It is not the meticulous requirements to the packages, which I find rational and easy to understand, but rather the haphazard way you have to find reviewers. When asking how to get your package reviewed, the standard reply is "try asking on irc". I have done that, of course, but I estimate the success rate to be only around 10%. For busy professionals, it can be quite difficult to spend time hanging out on irc. Often, the changes you are required to make are only 20 minutes of work or less, but then you have to go through the motion of finding a reviewer again, and so on. The cycle time for getting a package sponsored is weeks and months, and 99.9% of the time is spent waiting.To be honest, it makes progress too slow, and you have to be very persistent and committed not to become discouraged. From the viewpoint of the contributor, it would be nice to know that someone takes on the responsibility of working with you on a regular basis. For example, on REVU, the MOTUs could "sign on" for a particular package and follow it along until it is ready to get sponsor #2. Each package should have a special flag on the web page showing that the package is actively being reviewed. Another flag should show that the package has been reviewed and is waiting for another contributor upload. Communication between MOTU and contributor should take place on the REVU webpage, so others can follow the discussion and learn. These few modifications to the process would improve the productivity of our community and help keeping us hopefuls motivated. 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: xinetd as a inetd replacement
Emmet Hikory wrote: > The xinetd license is GPL-incompatible, and the current > distributed version may not be in compliance (I'm not an expert, but I > believe there are patches in place without accompanying documentation > in COPYING). While the featureset is great, this may not be the best > basis for a default component. I am puzzled. Xinetd is listed on the FSF directory page (http:// directory.fsf.org/network/servers/xinetd.html) with explicit information that the license is a "3-clause-BSD-style license" which is said to be compatible with GPL. The page doesn't mention the patches, though. However, software listed as Free Software on FSF's webpages ought to be OK for Ubuntu, don't you think? -- Morten -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: The latest DEB file has an error in dependency
> Depends: netbase, netkit-inetd | inetd, update-inetd | xinetd, > vmware-server-kernel-modules... > > When you try to install the package on the system with xinetd (most > Ubuntu systems) the apt-get needs to remove xinetd and want to replace > it with xinetd. Inetd should be removed from the distribution altogether, IMHO. It is outdated, and superceeded by the superior xinetd which has much better configuration and security features. -- Morten -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
