Blog

  • Enforcing proper /trunk/MAINTAINERS files in SVN

    I enabled a pre-commit check which validates if there is a /trunk/MAINTAINERS file. It also quickly checks if the format of that file is ok. If a module doesn’t have a /trunk/MAINTAINERS file, or it isn’t in the right format, the commit will be rejected. See http://live.gnome.org/MaintainersCorner#maintainers for how a proper /trunk/MAINTAINERS file should look like.

    Note that I gave various pre-warnings regarding this, and your commit is not lost. You can commit a proper /trunk/MAINTAINERS file to allow normal commits again.

    Since enabling the pre-commit just over an hour ago, 6 additional modules have a proper /trunk/MAINTAINERS file. Only a few hundred to go. 🙂

  • Wanted: html5lib package for EPEL / Fedora

    Could someone please make a package of html5lib for EPEL or Fedora (target is RHEL5)? This would be very helpful to improve our GNOME Library layout. Some of the gtk-doc documentation doesn’t build. For this the HTML files within the tarball are used instead. If html5lib is installed, the library-web scripts will automatically change the HTML files to contain the standard GNOME Library layout. See the difference between libgnome (built from source, has standard layout) documentation with the GTK+ (copied from supplied HTML files, lacks standard layout) documentation.

    Frederic Peters, many thanks for writing the second version of the library-web scripts and all the improvements you are making.

    Thanks to Oded, html5lib is now installed on the server. A full rebuild will be done during the night (CET), however a small preview of what the GTK+ documentation looks like now:lgo-gtkdoc.png

  • New accounts team member: Diego

    Diego Escalante Urrelo joined the accounts team. He is the third non-sysadmin being able to create accounts. Earlier joiners are Behdad Esfahbod and Riccardo Setti. We are still considering adding more members. Hopefully we will have a few more during/after GUADEC (as it allows meeting people in person).

  • http://build.gnome.org/

    We have a Build Bot running on a GNOME server; available at http://build.gnome.org/. It is far from being a full green build, but hopefully with some help this can be achieved. Especially the scrollkeeper error is strange (to me):

    gcc -g3 -O0 -fprofile-arcs -ftest-coverage -o .libs/scrollkeeper-tree-separate separate.o  -L/usr/local/buildslave/gnome/work/bin/lib64 ../libs/.libs/libscrollkeeper.so /usr/local/buildslave/gnome/work/bin/lib64/libxslt.so /usr/local/buildslave/gnome/work/bin/lib64/libxml2.so -lgcov -ldl -lz -lm -Wl,--rpath -Wl,/usr/local/buildslave/gnome/work/bin/lib64
    /usr/bin/ld: .libs/scrollkeeper-tree-separate: hidden symbol `__gcov_merge_add' in /usr/local/buildslave/gnome/work/bin/lib64/libgcov.a(_gcov_merge_add.o) is referenced by DSO
    /usr/bin/ld: final link failed: Nonrepresentable section on output

    Click here to see the full log. Help with all the errors is appreciated. Please subscribe to the build-brigade-list. More build bot slaves are appreciated too. If you have slaves (machines building GNOME at least 4 times a day.. preferably with root access) to donate, please mail us (the rest of the team -Iago Toral- is much better at setting these things up than me). Not sure what Iago is planning, but I want at least 5 slaves.

  • GUADEC 2008 proposal — Istanbul

    Istanbul has been proposed to host GUADEC 2008. Some details:

    • It is not as hot as I expected; average high temperature = 27 degrees celcius
    • great place to be/party/enjoy the culture
    • 4 star hotel: $30,- per night
    • cheaper/free accomodation should be possible (IMO this is very important so we can have as many people join as possible)
    • two international airports

    To see the whole proposal, read the following PDF document: guadec2008-proposal.pdf. If you have any questions please contact Barış Çiçek (GNOME Türkiye board contact, part of the membership committee and also responsible for the Mango Summer of Code enhancement).

    Note: I do not know about other proposals for 2008. Further, I am not involved with any of them. My ideal proposal would let as many people join as possible (avoiding visa/money/etc problems). Although sponsoring people is good, I’d rather sponsor even more people just due to the tickets/accommodation/food/venue/etc being cheaper.

  • Checking out a single file with SVN 1.5 dev

    SVN 1.5 dev can now check out a single file. This is important for translators who want to check out and commit a single file and not all the other languages.

    Requirements

    • SVN 1.5 dev

    Usage

    svn co --depth=empty the-dir
    svn up the-dir/the-file

    More information

  • Accounts Team + Membership Committee transparency

    Guilherme de S. Pastore created an overview for some of the RequestTracker3 queues in www.gnome.org/rt3-stats. After some discussion with Federico I’ve enhanced these to show an overview of all new/open/stalled tickets. Before you could only see the totals; not what the state of your ticket was in. For stalled tickets it even tries to figure out why it is in stalled state (waiting for someone to reply). That is a hack though and although it should often be incorrect; it might show the wrong information.

    Quick explanation of the various states:

    • new: nobody ever touched it
    • open: someone touched it (e.g. goes into this state again after someone sends a mail to a stalled ticket)
    • stalled: we are waiting for something. Usually either a reply from the requestor or someone we manually cc’ed (maintainer to ask for approval).

    All new tickets will now be informed about this URL in the autoreply. I’m planning to inform all new/open/stalled tickets requestors as well if easily doable.

  • Nazgul on GNOME Bugzilla

    Christian Kirbach will now handle all product creation requests on GNOME Bugzilla. Hopefully he likes perl as well… for his sake.

    In other news, about 1500 people clicked on the porno spam link posted as a few HTML files in GNOME Bugzilla. Spammer has been banned of course, plus the files aren’t visible anymore. Please inform bugmaster@gnome.org, or someone in #bugs on irc.gnome.org when you notice this in future.
    Aside from GNOME Bugzilla, the spammer abused at least Red Hat Bugzilla, and some wiki site. The spammer didn’t use a bot btw, the account creation was manual (easy to determine from the logs).

    Read (via Digg) a blog about 14 rules for fast web pages. Enabled that gzip stuff for Bugzilla. Ignored the rest.

  • Slow ticket processing

    I was questioned by Vincent at UDS if the GNOME sysadmin team needed help as some tickets took a while to process. We (me,Vincent) didn’t have the time to discuss it, but I mailed my thoughts to him. He suggested I’d blog about it. This is it. Below is the almost pristine mail that he received. He did suggest I’d make a summary, but it is late and I do not want to. I slightly reworded small parts though.
    PS: These are my thoughts and plans. Haven’t discussed this on gnome-sysadmin.

    There are a few problems:

    • Account requests take long to process
    • Mailing list requests take long to setup correctly

    I am not aware of problems aside from above (meaning, AFAIK everything is running smoothly). Note that not everything
    is sysadmin related. E.g. I am *very* slow with Bugzilla related bugs
    (‘tickets’) currently due to lack of time. However, that is not a
    sysadmin problem.

    Long to process account requests
    First of all, this is handled by the accounts team; not by the
    sysadmin team. Although in practice there is an overlap. In short:
    some sysadmins do not setup accounts; and some accounts people are not a sysadmin (have root). The delay is not just new accounts, also e.g.
    updating the email address takes a long time.
    I think this is basically caused by the following:

    • Some of the active accounts team have been scared away (some
      requests are so ‘friendly’ that a few accounts@ people quit).

    • Some people are just busy with other stuff
    • Handling accounts is a stupid boring task that should be automated for 99%; it is not fun
      nor rewarding (people have better things to do with their time)

    Mailing lists setup takes a long time
    I refuse to setup new mailing lists as it will only result in a broken
    one. Nobody else seems to handle these within a reasonable timeframe,
    so the end result is that they take months to process.

    Solutions to the problems I stated initially that will not work:

    • Add people to the sysadmin team
    • Add people to the accounts team

    Add more people to sysadmin team
    From my experience I noticed that adding more people really
    does not help (apart from making sure they can be trusted, are a
    sysadmin, etc). The people who have the new privileges usually stop
    helping after a few months at most. Although people do want to help,
    it seems they don’t keep the interest.

    Someone I would add is someone who continually says what needs to be
    changed and how to do it (in a constructive way); plus knows what
    should not be done. The reason for this is that as a sysadmin there is
    not someone who will tell you either what to do or how to do it.
    Meaning, a sysadmin will need to know that by heart.
    In short: I want people who would join anyway, not people who want to help.

    Add people to the accounts team
    Due to reasons I specified before, I think it is better to automate
    much of the task away (Summer of Code project) than spend lots of time to find more people to
    do a boring task. Although I’d appreciate people helping out with
    enhancing Mango.

    Other causes:

    • Not every sysadmin follows RT3

    Not every sysadmin follows RT3
    Not sure why some do not have an account or they do not look at
    tickets. They are subscribed to gnome-sysadmin though (which mostly receives cron/logwatch, etc etc).

    I hope most problems can be solved by the following:

    • Implementation of new account creation system within mango
    • Redo the mailing list setup.
    • Avoid using RT3, make use of Bugzilla instead (sysadmin product).

    New account creation system
    This should provide transparency and automate most of the process.
    This hopefully also includes ways to securely have people change their
    account as well (e.g. add/remove SSH keys, update email address, etc).

    Redo mailing list setup
    Basically the mailing list setup is so strange that when a new mailing
    list is created, it fails to work. Usually either the alias does not
    exist (you cannot mail to it), the archive is not listed or the
    archive does not work. I plan to redo the mailing list setup together
    with the upgrade of that machine from RHEL3 to RHEL5.
    Note: Currently it feels to me like a black box. Symlinks to symlinks,
    etc. Also the available sysadmin instructions do not result in a
    mailing list that actually works. This is also the reason the machine
    still runs RHEL3 (I do not want to break it).
    Oh, and the indexing of the archives is still broken.

    Avoid using RT3
    We currently require RT3 basically for the account system and generic
    requests. This because we need a system which can mail random people
    to setup accounts. Tickets are not shown as we have no way to verify
    someone did not change the From:. The solution is sending people a
    token and verifying that they mail this token back.
    For the non-accounts uses I think we should be able to use Bugzilla in
    theory. However, currently something that I do not want to explain publicly blocks a switch from RT3 to Bugzilla.
    Note: gnome-sysadmin@gnome.org will stay for urgent requests and/or
    when e.g. Bugzilla is down (which would be an urgent request).

  • Bugzilla 3.0

    Part of this was copy/pasted from the announcement.

    Here’s just a sampling of the major new features in version 3.0:

    • Less ugly perl code (almost everything is readable&understandable now)
    • Custom Fields
    • mod_perl support for greatly-improved performance
      While sucking up loads of memory 🙁

    • Per-Product Permissions
      non hacky version of what is available on GNOME Bugzilla (patch wasn’t by me)

    • XML-RPC Interface; see the WebService stuff on this page
    • Create and Modify Bugs by Email
      Still not GPG authenticated though; so I won’t enable it on b.g.o without at least a hack to make it more secure.

    • And even more. See all the new features at: http://www.bugzilla.org/releases/3.0/new-features.html

    GNOME Bugzilla
    I am really busy. Help with the port is appreciated. The current (very rough and unfinished) port is available in the bugzilla.gnome.org SVN module; while the site currently uses the bugzilla-newer SVN module. I think that probably the port should use Bugzilla HEAD (what will eventually be 3.2) though. I basically need at least 3.0 to easily avoid those bug-buddy crash duplicates.