Jeff Bailey <jbailey@nisa.net> writes: > So far, I've been keeping my turtle pages up to date on my Debian home > page. > > Do you guys see any value in me trying to keep up a "most wanted" page > for tasks that everyone can work on? I can't remember (or find the > email of the person) who got apt to work, but it was great to say > "Here's what's needed" and have someone actually take the task. I provided the patch in bug 92025, if you mean that. The thing is, most snags are really small things: if a package has compiled once, failure in newer versions are usually quite easy to fix. Normally the whole affair doesn't take more than 30 minutes. > However, this will be a commitment of time to keep it going, and I'd > rather not do it if it won't get used. Personally, I don't find it necessary. I'm perfectly fine with the Turtle pages. Here's my how-to for people looking for small maintainance hacking (open to enhancements): 1. Look at <URL:http://people.debian.org/~jbailey/turtle/group/Debian/index.html> or <URL:http://people.debian.org/~jbailey/turtle1/group/Debian/index.html> Packages with a red status need work. 2. Pick a red package you care about. If you don't have any preferences, look from top to bottom -- the higher-priority packages are near the top. Another key point for choosing is the status: "out-of-date" means that a previous version was successfully ported, and therefore that any problems should remain relatively small -- pick one of those if you want an easy target. "missing" denotes packages without a working version. These are generally harder (often not by much) -- on the other hand, work here is more valuable, so look at these if you have more time on your hand. 3. In most cases, a build log is linked from the Turtle main page. These can be used to quickly assess problems. The most common bug is a missing dependency. In this case, you have to determine the thing that's missing. Make sure it's mentioned in the build-depends (if not, file a bug), and finally check that the dependencies have working versions for hurd-i386 (if not, fix them first). 4. Check the bug tracking system, a patch (or at least some discussion) may already be there! Be sure to look at all binaries built from a source package. 5. If you spend more than a short while on a package, inform others to prevent duplicated work. A short mail to debian-hurd@lists.debian.org should suffice. Corollary: read this list. 6. Once you have a fix in hand that works, put the patch in the BTS. Give the bug a "patch" tag. I normally use severity "Important" for doesnt-compile-on-hurd patches. Things would help making the Turtle pages even more useful: * failing build dependencies should be mentioned up front. For example, a lot of packages failed due to no working cdebconf [fixed now], but I only discovered that after looking through a lot of build logs. * add more packages. Perhaps I'm insane, but having everything of "standard" or higher priority under Turtle would be quite a blessing. Resource constraints may prevent that, though. -- Robbe
Attachment:
signature.ng
Description: PGP signature