swegener’s blog

Here is what happened yesterday:

• 17:35 UTC

  I decided to give my webserver a package update. So as always I launched an emerge –sync, following an emerge -upD world to see what portage would like to update. What I saw was not what I expected:

  [blocks B ] >=net-www/apache-2.0.52-r3 (is blocking dev-php/mod_php-4.3.11)
  [blocks B ] >=net-www/apache-2.0.52-r3 (is blocking dev-util/subversion-1.1.3)

  Well, I said to myself: Probably a mistake, so let’s wait one or two hours to give our developers some time to fix these issues.

• 19:11 UTC

  About 1.5 hours passed by. Looking at #gentoo-commits on freenode I saw that our developers fixed the blockers. I issued another emerge –sync and afterwards an emerge -upD world. Everything looked good, so I removed -p from the command and started emerge again. But now this:

  >>> emerge (4 of 4) net-www/apache-2.0.54-r4 to /
  >>> Previously fetched file: apache-patches-2.0.54-r4.tar.bz2 size ;-)
  >>> Previously fetched file: apache-patches-2.0.54-r4.tar.bz2 MD5 ;-)
  >>> Previously fetched file: apache-conf-2.0.54-r4.tar.bz2 size ;-)
  >>> Previously fetched file: apache-conf-2.0.54-r4.tar.bz2 MD5 ;-)

  !!! No message digest entry found for file “httpd-2.0.54.tar.gz.”
  !!! Most likely a temporary problem. Try ‘emerge sync’ again later.
  !!! If you are certain of the authenticity of the file then you may type
  !!! the following to generate a new digest:
  !!! ebuild /usr/portage/category/package/package-version.ebuild digest

  Well, I don’t say that this never happens to me. There might be one excuse for it, repoman has a digest.unused check for digest entries that are not used by a file in SRC_URI, but misses a reverse check that checks for missing digest entries. But it’s up to the developers to make sure that what they commit to the tree actually works. And there is no excuse that two arch teams mark this version stable on their arch without notifying the missing digest entry.

• 19:34 UTC

  I finally finished updating apache, after fixing the above issue myself.

What else drives me nuts it that I sometimes catch developers that do not use repoman to commit their changes. This results in Manifests that break FEATURES=”strict” which has been added to the base profile about one month ago. I often fix them silently because I’m tired of telling developers to use repoman. They should know that, else I wonder who made them developers.

Other developers don’t enter something into repoman’s commit message prompt and just accept the empty line. This makes it really hard to track their CVS changes. Are these developers just to lazy or (sorry) to dumb to create an ecommit shell alias/function/script/whatever that takes care of creating a ChangeLog entry and passing the message to repoman for use as the CVS commit message. Like this:

ecommit() {
        echangelog "${*}"
        repoman --commitmsg "${*}" commit
}

I say, if we want to play where the big boys play, we need to do something about it. Giving a first-time Gentoo user such an experience will probably make them go to another distribution.

This entry was posted on Friday, May 13th, 2005 at 12:53 pm and is filed under Gentoo. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.