(That's pronounced like geronimo.)

I've been playing with a way to ensure that the JIRA tickets that get made for rMake have the correct information associated with them. To that end, I developed a python SOAP client for JIRA, called pyjira. I also created a front end, called jiranemo (good for plunging into the dark and murky seas of bug finding). They're still very much alpha, and JIRA's api has some holes as well*, so don't expect miracles. I have been able to create, display, and search for issues, and add comments with it however. I have an API for adding attachments but haven't exposed it through JIRAnemo yet though.

Another thing this will let us do, I am hoping, is automatically add information to JIRA when a fix is committed that links to the hg repository. That way we can track more easily what code was committed to fix a bug. That will let people who are interested in the patch(es) related to that bug find the relevant fix. A hook like that for cvc would be nice as well!

To install jiranemo type:
conary update jiranemo --install-label contrib.rpath.org@rpl:devel --resolve

To use JIRAnemo with rPath, you have to go through some extra hoops, because our JIRA instance setup is a little non-standard.

To use jiranemo with the rPath JIRA, set up a .jirarc in your home directory with the following entries:
wsdl http://people.rpath.com/~dbc/rpath.wsdl
user youruser
password yourpassword


Then you can run commands like jiranemo list issue CNY-200, jiranemo list projects, and so on.

In general, the wsdl you'll use for more standard setups looks like
http://[project]/rpc/soap/jirasoapservice-v2?wsdl, but that one won't work for rPath.

* For example, if you submit a comment with a security level that doesn't exist, it fails silently. Also, as far as I can tell there's no way to determine what valid security levels are. Also the search by filter api seems to always return empty results. Exceptions returned from JIRA are often cryptic if the parameters are wrong.

Conary command line processing approaches the modern era:

[dbc@wallace ~]cvc commit --help
usage: cvc commit

options:
  --version             show program's version number and exit
  -h, --help            show this help message and exit

  Common Options:
    --build-label=LABEL
                        Use build label LABEL as default search loc
...
  Command Options:
    -m MESSAGE, --message=MESSAGE
                        Use MESSAGE to describe why the commit was performed

We've started publishing our current development version of conary twice a day into conary-unstable.conary.com@rpl:devel. I'll be manually pushing versions that I think are more or less appropriate for public consumption to conary-unstable.conary.com@rpl:1. We'd love for enterprising testers to start using this label to give us an early heads up for bugs in conary.

And, currently there's a special reason to download conary from the unstable branch - I've just added code that makes our dependency resolution algorithm more powerful. Let's imagine this "hypothetical" situation:

1. conary:python v.1 provides "trove: conary:python(1)"
2. conary-build:python v.1 requires "trove: conary:python(1)"
3. conary:runtime v.1 requires "trove: conary:python(1)"

A new version of conary, version 2.0 comes out, which looks exactly like version 1.0 except for it requires version 2 of everything.

So let's say you want to update conary from version 1 to version 2, and so run 'conary update conary'.

Currently, conary will fail to perform the update, even with --resolve, because conary-build v.1 requires conary:python v.1, and conary doesn't want to make conary-build v.1 unusable! The new conary will see this dependency problem and try to update conary-build. If you have conary and conary-build installed, you will have seen that you cannot update one without specifying the other as well. The new conary will allow you to use dep resolution to solve this problem.

Because the algorithm almost certainly still needs tweaks, we have turned it off by default. To enable it, add "resolveLevel 2" to your conary configuration.

So update to conary using 'conary update {conary,conary-build}=conary-unstable.rpath.org@rpl:1', set your conaryrc 'resolveLevel 2'.

So, if you were really paying attention to my last post, you might have noticed something strange in the output from the new conary erase glibc command:

warning: keeping glibc:devel - required by at least kdelibs:devel
warning: keeping glibc:devellib - required by at least kdelibs:devel
The following updates will be performed:
    Erase   glibc(:doc :locale)=2.3.5-4-0.1

What's wrong here? There's no mention of the glibc:lib or glibc:runtime components! That is, conary is neither erasing glibc:lib or warning you that it's not erasing it. The reason is this: conary doesn't delete a trove from your system until all the groups (or packages) that reference that trove are deleted. So, if you have glibc installed which has a reference to glibc:lib, and group-core installed, which _also_ references glibc:lib, then conary won't erase glibc:lib until both glibc (the package) and group-core are erased.

So, I thought that sucked. Although components are nice, they are often not the correct level of abstraction for either beginner or advanced conary users. So I worked over the last week on fixing this problem.

Here's how I did it: Now when groups include a particular component, (say, glibc:runtime), they actually contain a reference to the parent package (glibc), with all the components except the one you specify "byDefault False", meaning they won't be installed when the group is installed. That means in the future no groups will have references to individual components, which means that conary erase glibc will work as expected. Note that I also added code to automatically install the package for a component when you resolve that component.

Doing the work to make this possible meant adding something called weak references to conary. I'll blog about how that makes it possible to shrink the size of your distro later.

Oh, and by the way, none of this is in the main conary-repository yet, but it should be arriving very soon.

A blogger once mentioned that 'conary erase glibc' seemed to work on their system. They had used this test with multiple package managers to see how they handled what might be seen as a monstrously stupid thing to do.

Here's the blog entry in question.

http://rpath.blogspot.com/2005/11/oh-god.html

According to the blogger, conary just blithely erased glibc, no complaints!

Of course, that's not exactly what happened. Conary simply erased the components of glibc that are not depended on by anything else. Those include:

• the package (which is just an index to the components which hold the actual files)
• the :doc component (no other package compares if glibc:doc is installed!)
• the :locale component

The reason conary has this behavior is because it's very nice for groups! Suppose you run conary erase group-gnome. You might expect it to fail, because, say, the group includes gtk which you use for other programs outside of group-gnome. But it won't fail, it will do exactly what you want, erasing all of the programs and their documentation and keeping exactly what you need.

Still, the behavior can be confusing, and has caught me unexpectedly on occasion. So I just added code that makes conary warn you when it keeps a component around because other troves require it. So, now, when I type conary erase glibc I get the following output:

warning: keeping glibc:devel - required by at least kdelibs:devel
warning: keeping glibc:devellib - required by at least kdelibs:devel
The following updates will be performed:
    Erase   glibc(:doc :locale)=2.3.5-4-0.1

Next up: making conary q glibc return glibc:devel and glibc:devellib even if you don't have the glibc package installed.