yum todo list part 2

September 30, 2004

Icon spent a bunch of time profiling the metadata import today and then we brainstormed some. I think we might have some ways to make the importing of the xml metadata faster, especially on concurrent runs against the same xml files. He did some spiffy work, now we just need to make it function in use. 🙂

I sat down and made my self write up the stubs for the group functions and clean up yum/groups.py. Generic but not useless. 🙂

I also cleaned out my old todo list and made the new one and even prioritized:

  • log output – to files and to console – make it nicer/real
  • pre-transaction confirmation output needs to be clearer and easier to read
  • group* functions (duh)
  • transactioninfo.py needs fleshing out of methods and then cli.py and yum/depsolve.py need to start using it.
  • Menno’s Xtrigger needs to happen once the transactioninfo class is in place

Less important but useful items:

  • list output and function changes:
    • yum deplist somepkg
    • yum recent needs to be based relative to current date and limited to a package count
    • yum list obsoletes should be dressed up so it lists the obsoleting and obsoleted packages easily – fitting all this in 80 chars is a pain
    • ditto above with updates/updated
  • sigcheck routine needs to handback siginfo from any successful check
  • urlgrabber module IN yum needs to be renamed so it doesn’t conflict with urlgrabber on system
  • yum-downloader code needs to be merged and cleaned
  • yum-arch-legacy needs to show up in 2.1.X to make some folks happy
  • urlgrabber needs to add socket timeout ability
  • work to be done to make the optimization routines icon came up with to work with more than one repository, sanely
  • DOCS

Anyone wanna help?

/me hears crickets

Came across a cool idea that Rick Graves came up with. He’s calling the scripts lagmirror. The idea is simple. The longer a package is in a repository without any update the greater the likelihood that the package is stable/safe.

So a package that shows up is in the day1 repo

after 2 days it’s in the day3 repo

but then a new package of the same name shows up. So the day3 repo notes this and that package never moves beyond day3. While the new package that just shows up starts over in day1.

So you could have really mission critical stuff be on like a day25 repo and your less critical stuff could pull from day3 or day4.

Now, granted it’s not a fullproof metric but in a large number of cases it is accurate. And it correlates nicely to the concepts of:

testing, unstable, stable that fedora, debian and other folks use for package/distro releases.


September 30, 2004

Luis told me about this first thing this morning. I hope those hospitalized come out okay. The open source and gnome communities have lost enough people in the last few years.

staying home is good to do

September 29, 2004

Stayed home and worked from here today. Probably in my best interest over all. I got yum 2.1.4 working and built some packages and tested some other things.

yum 2.1.4 should be mo-betta than 2.1.3 – a whole pile of fixed bugs in addition to yum search and yum provides working nicely. There are a couple of aspects of yum provides that I hate, a lot, but we shall persevere.

I need help with docs, now-ish. So if anyone wants to pick my brain via email and then write up docs on:

– new yum.conf options

– how the new metadata works

– new options, disabled options, etc

I’d LOVE to hear from you.

I’m also interested to hear from people who want to work on entirely new features that will sorta sit outside of yum. Specifically: yum-shell, yum-queue. Someone already submitted patches for a yum-downloader module. It’s just cool.

it imports goodies from the yum module then you can do:

yum-download foo.src

and it fetches you foo-somever-rel.src.rpm of the highest version from whatever repository.

It’s not trying to be hyperintelligent it just downloads a specific file which I can definitely feel as useful. The number of times I’ve needed a specific src.rpm and didn’t feel like going to find it.

And with the new yum package specification you can do:

yum-download foo-1.1-2.src

and get that SPECIFIC version, if it exists.

So much more stuff to do, of course, but some of it is fun.


September 27, 2004

I think I can summarize my week with the following picture:


Any other questions?

This dog is available from the aps of durham if you live in/around durham, nc.


September 23, 2004

Netflix is destroying my life. My clearly evil girlfriend and dog have conspired against me to make it impossible for me to accomplish any work. Netflix, having a distribution center in greensboro, quickly brings new West Wing DVDs to my door.

Grr. Argh.

What I did today

September 21, 2004

1. moved a country from europe to south america

2. moved it back

3. ordered some disks

4. cleaned up a proposal

5. answered a lot of questions


Things I’ll do tomorrow:

1. go to the dentist

2. be in pain

3. be cranky

4. work on something useful

5. work on something meaningless.

At some point in there at least one episode of law and order will probably cross my path.

So very tired

September 20, 2004

Saturday was kinda crappy. Woke up ok then I went to read my email and just got angry. I was feeling pretty put-upon and under-appreciated by a lot of people. I settled down but god I was not in a mood where others should be near me. I did realize one thing, though. Most freesoftware development is about masochism. ESR had it wrong, it’s not about fame, nor about ‘cred’ it’s all about wanting other, random strangers to abuse you via email, irc and bugzilla postings. Do not make any mistake about that.

Today was a pretty day. I woke up happily. Feeling good. It was bizarre. The temperature was comfortable all day long. I spent some time doing some misc items (like laundry) then worked on various things. I cleaned up silly grub splash screens on some machines w/ either no video or where it made the kernel output look like garbage. Then I worked on yum a while and cleaned up a lot of various little things. I noticed a place in the depsolver where I could save some time if A LOT of packages report the same requirement, However, I’m not quite sure _how_ to make that part faster without making the code MORE ugly. We’ll see. I need to sit down with it for a little while more. Moved a lot of other code around and cleaned up the rss generation scripts. I also worked on changes to the:

yum list [recent|obsoletes] commands

After that I need to write out the full depsolve progress callback into output.py to give the user more lovely information. Then back over to fix yum search and yum provides. Then out to fix the logging. However, before I can do the logging ‘correctly’ I need to implement the transactionInfo.py work I setup last week. I’m kinda pleased about that part too.

Then it’s back over for group* re-implementation with the new metadata. This is not so much hard as it is interesting b/c I’m working with code I wrote about a year ago and I’m noticing lots of places where it should be a lot prettier.

Finished off a bunch of centos stuff today. Now that it’s done I can get back to merging all those changes back down to duke’s internal install and work on the FC2 changes as well.

And all this in addition to the FC3test2 mirror and torrent stuff. Never a dull moment around here.

I was forced to watch Hackers this weekend by my cruel and vindictive girlfriend.

I’d like to sum up this movie by this comment from the goofs page at imdb:

Factual errors: Generally ill-informed and ridiculous to the extreme regarding the capabilities and characteristics of computers, technology, and phone systems.

I think that says just about enough. 🙂

Oh and I confessed something to my girlfriend I don’t think I’ve told another soul. I’m one of the 4 people on the planet who have not seen Titanic. It’s really nothing against the movie. But I don’t think I can sit through 3+hours of Leonardo Dicaprio being himself or anyone else. Does this make me a bad person.

This entry has rambled for quite long enough, I think.