Lo’  nearly a week ago we had a FAD and came up with some proposals. One of the proposals was Critical Path Packages. The gist of this proposal is that all packages are equal, but some are more equal than others. Or to put it another way – there are a set of packages that will need to jump through an extra hoop if the maintainer pushes an update.

There a bunch of areas where we want to be sure the packages all work together, so I made a brief list of the pkgs involved in those areas:

Deps of these pkgs included:

• graphical network install
  • anaconda
• post-install booting
  • firstboot
  • grub/bootmanager
  • kernel
• decrypt encrypted filesystems
  • cryptsetup-luks
• graphics
  • bitmap-fonts
  • desktop-backgrounds-basic
  • xorg-x11-drivers
  • xorg-x11-server-Xorg
  • xorg-x11-xauth
  • xorg-x11-xinit
  • gdm
  • mandatory pkgs in gnome group
• login
  • gdm
  • pam
• networking
  • NetworkManager?
• get updates
  • yum
• minimal buildroot
  • bash
  • bzip2
  • coreutils
  • cpio
  • diffutils
  • fedora-release
  • findutils
  • gawk
  • gcc
  • gcc-c++
  • grep
  • gzip
  • info
  • make
  • patch
  • redhat-rpm-config
  • rpm-build
  • sed
  • shadow-utils
  • tar
  • unzip
  • util-linux-ng
  • which
• compose new trees
  • pungi
  • mash
  • createrepo

• compose live
  • livecd-creator
  • pungi

I’m thinking of depsolving out the complete list, uniquing it and creating a new comps group which includes these pkgs as mandatory members so it can be referenced easily.

Anyone with a package in this group will have to get some member of releng and QA to sign off on the package update going through before it happens. I realize this is an extra level of bureaucracy but I don’t think we have any choice. For an example problem that we could have avoided if another person had to test and signoff on the update I’d like to refer everyone to the dbus update from earlier in the F10 release.

I’m looking for feedback on this idea, but I’ll probably go ahead with some of it as-is.

About 30dozen people sent me to the test comparing yum to apt-deb. Always a fun comparison. It’d be even more fun if any of the numbers seemed accurate.

I put a short script together for myself – just to see how yum is doing.

Here’s the very simple script:

http://skvidal.fedorapeople.org/misc/yum-test.sh.txt

I ran it like this:

sudo ./yum-test.sh >> /tmp/simple-yum-results.txt 2>&1

Here are my results on my x61s laptop running F11:

http://skvidal.fedorapeople.org/misc/simple-yum-results.txt

Full disclosure. I had already updated the metadata b/c I didn’t feel like testing the network speed in this coffee shop. I also downloaded the pkgs that it installed already by pulling them into the cache with a yumdownloader. Again, I wanted to test yum (and rpm) not the bandwidth of  the coffee shop. I’m running yum 3.2.23-3.fc11 on a 686 install of f11.

Overall the numbers look pretty good to me. Run a test for yourself and point out your results below.

Update enabled repos for the benchmarks

sudo yum repolist
repo id             repo name                                 status
fedora              Fedora 11 – i386                          enabled: 13,289
updates            Fedora 11 – i386 – Updates                enabled:  1,988
repolist: 15,277

For checking changes from one package to another we’ve discussed a better rpmdiff that wouldn’t report so many bogons in the filelists and provides, requires, obsoletes, conflicts.

After giving it a bit of a think I worked out a mungingdiff for pkgs.

It reports items that matter, not all the stuff you EXPECT to change. For example:

if the pkg goes from foo-1.1-1 to foo-1.2-1

and its provides change from:

Provides: fooball = 1.1-1

to

Provides: fooball = 1.2-1

it’s a little silly to report that in a diff. Same thing with filenames. If a bunch of files move from /usr/share/doc/foo-1.1 to /usr/share/doc/foo-1.2 but don’t change otherwise does it matter? No. Not in any functional way.

So I cobbled together a proof of concept that I’ll be moving internal to yum package objects so they can provide a diff between two pkg objects, I think.

http://skvidal.fedorapeople.org/misc/mungingdiff.py

Run it like:

mungingdiff.py pkg1 pkg2

a couple of minor things. It doesn’t return diffs between the name, arch, epoch, ver, release. It is working on the assumption that if you don’t know those things have changed then you’re Sorry out of Luck.

I also know the output sucks, big surprise.

I updated to fedora 11 from the mishmash my laptop was today. I did it in three steps b/c I was going out for dinner.

All of these steps were run in screen:

1. yum –downloadonly update

2. yum update

3. yum groupupdate “GNOME Desktop Environment”

then I removed a bunch of packages I didn’t want and checked to see if evolution works with vfolders of vfolders (it doesn’t). Maybe I’ll try thunderbird out.

But, for the record – yum updating in place worked – but do it in screen b/c of the fontconfig issue that’s documented on the common issues page.

just to be clear the phone was only muted at all today b/c:

a. Josh wanted to talk some smack about my parentage and we didn’t think everyone needed to hear it

b. Spot was playing some inappropriate SNL videos

c. We were playing that game that asok the intern played badly with speaker phones

d. all of the above.

Seriously, FAD today was the big – what things we have problems with and why. You might think this would be an easy thing but in reality with N people in the room you tend to have N^N number of opinions on what is wrong. So we had to hash out a consensus of what was wrong.

We got through about 1/3rd of our list you can find these things on the FAD wiki page. There is hope for more tomorrow.

Then we had pizza and popsicles.

1. It is surprising to me how thrilled folks to seem to be about presto getting in for F11. I’m glad it is done. I’m sorry it took so long but it is nice to see all the happy remarks on fedora planet.

2. For a long time I wanted a nice-ish blog editor for wordpress-ish blogs that ran natively. It looks like I have that now in Lekhonee

It is not w/o bugs but what isn’t?

1. as Josh said we have rescued deltarpms from apparent unavailability

2. nahbs is going to be in richmond, va next year.

3. yehuda moon is coming back in June

4. eunice and I did a nice (and somewhat quick) 50 mile cap2cap ride this morning.

I’m sure tomorrow will go very very wrong.

Luis asked me a question about how to get some info out of koji. We ended up
getting the same kind of info out of the source rpm repodata, instead. It
wasn’t hard with repoquery but once I started getting it, I wanted to find
out how we’ve been doing for a while.

In fedora, we try to encourage folks to push their patches upstream and not
carry them locally. So I put together a little script to see how many
patches we’re carrying per source rpm, on average.

The script is simple, obviously:

#!/bin/bash

srcrepo=$2
repoid=$1

patches=`repoquery –quiet –repofrompath=$repoid,$srcrepo –repoid=$repoid \
–archlist=src -l -a | grep patch | wc -l`
pkgs=`repoquery –quiet –repofrompath=$repoid,$srcrepo –repoid=$repoid \
–archlist=src -a |  wc -l`

result=`echo “$patches/$pkgs” | bc -l`
echo $repoid has $patches patches in $pkgs src rpms
echo $repoid has $patches in $pkgs src rpms

Here are the locations I used:
f7:

http://archive.fedoraproject.org/pub/archive/fedora/linux/releases/7/Everything/source/SRPMS/

f8:

http://archive.fedoraproject.org/pub/archive/fedora/linux/releases/8/Everything/source/SRPMS/

f9:

http://download.fedora.redhat.com/pub/fedora/linux/releases/9/Everything/source/SRPMS/

f10:

http://download.fedora.redhat.com/pub/fedora/linux/releases/10/Everything/source/SRPMS/

rawhide:

http://download.fedora.redhat.com/pub/fedora/linux/development/source/SRPMS/

And here are the results:

f7 has 7475 patches in 4226 src rpms
1.76881211547562707051 patches per srpm

f8 has 7991 patches in 4834 src rpms
1.65308233347124534546 patches per srpm

f9 has 9151 patches in 5547 src rpms
1.64972056967730304669 patches per srpm

f10 has 9386 patches in 6406 src rpms
1.46518888541991882610 patches per srpm

rawhide patches has 10278 in 7444 src rpms
1.38070929607737775389 patches per srpm

So we’ve been improving from release to release. Not a lot of improvement
between f8 and f9 but still some. All in all, I’m pretty happy about that.

As a contrast I also ran it on centos4.7 and centos5.3. Now, these two
distros have to carry a lot of patches in order to maintain backward compat
with their original versions:

centos 4.7 has 8446 patches in 876 src rpms
9.64155251141552511415 patches per srpm

centos 5.3 has 10238 patches in 1186 src rpms
8.63237774030354131534 patches per srpm

That looks about right, I think.

Maybe this is useful trivia, maybe not, but it was interesting nevertheless.

Update:  Josh Boyer pointed out that my script didn’t pick up patches named *.diff so I changed the script and here are the results:

f7 has 7648 patches in 4226 src rpms
1.80974917179365830572 patches per srpm

rawhide-src has 10548 patches in 7444 src rpms
1.41698011821601289629 patches per srpm

same ballpark afaict.

In an unprecedented turn of events the presto test day went shockingly smoothly. A little problem with the x86_64 repo being made available but we managed to squeak out a solution that worked in the interim.

But more to the point things seemed to work. Not a lot of things broke (well, fine, some broke the day before yesterday but we got those fixed.

but today there were a fair number of testers and fairly few actual errors.

Thanks goes to jlaska, jhutar, psklenar, and jdieter for making it all happen.

After reading a massively long list of posts on various subjects on fedora-devel-list and fedora-test-list this weekend I’d like to offer a minor recommendation:

Let’s all stop with sarcastic, rhetorical, derisive retorts.

If we assume that all people who work on fedora are well intentioned then we shouldn’t be responding to them with derision or haughtiness. So, don’t.

Figure someone is well-intentioned but perhaps misinformed (or misperceived) and respond to them with this in mind.

Just to stave off this thread: No, I don’t think a code of conduct solves this problem.