Arch Linux

This is a shortcoming of the web system. When it encounters a Testing package that doesn't (yet) exist in any of the main 3 repos (Current, Extra, or Unstable), then it has no idea where the package actually resides. Testing is not a real CVS repo, it's actually a different branch of the main three repos. The web system doesn't directly interact with the CVS repositories, so it can't lookup the real repo unless it can find the same package in one of the real repos for a reference point.

This can be fixed when we redo the website, but it may be a little while. As for mkinitramfs, the problem will go away once it is introduced into Current, Extra, or Unstable.

Ok, I understand.
Can I see the sources of web system? I can help to fix it while devs can work on more important tasks.
Right now I'm still developing new Arch and AUR site ("just for fun") in my free time. Maybe you'll like my work, when it's finished.

With the new archlinux.org the problem still remains
For example gtk2 in Testing has the following URL for CVS entry: http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/lib/gtk2/?cvsroot=Testing&only_with_tag=CURRENT
It is worng.

The above appears to be the case with all packages in Testing. In addition, some aren't viewable when using the correct URL, and as far as I can tell are not in CVS. Take, for example, dbus from Testing:

http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/system/dbus/?cvsroot=Current&only_with_tag=TESTING

Any progress here? It makes it very difficult to track changes in the testing repo.

None at all.

assigned to neotuli who will maintain the website from now on.

any progress here? or atleast a way to view it without clicking on a link?

The problem is still that the web system doesn't know where a package resides in the underlying cvs.

Assume we have package foo. Foo is in current and testing.
For the web interface, foo has a package ID of 1334 in current, and a package ID of 1335 in testing.

Somebody clicks on http://www.archlinux.org/packages/1335/ in the web interface.
The web interface pulls the data from the database, and gets this.

package:
id = 1335
repo = Testing
maintainer = Mr.Awesome
category = Base
needupdate = False
pkgname = foo
pkgver = 1.0
pkgrel = 2
pkgdesc = Makes bar run better
url = http://house.ofbar.net

The problem is the 'repo' column in the database. This package has no meta belying its origin. If the package soley exists in testing, the problem is even worse (because there is no way we could just do a second query, get the non-testing package, and find out which repo *that one* is in).

If we only had one backend repository, then it would be a simple matter of hard coding the repo to something, and then adding the 'Testing' flag, but we don't have that luxury here.

I don't think this is fixable until we move to a different backend repository system.

If somebody has a good idea, or thinks they have a solution to the general case, let me know.

I think we should do an official 'punt' on this one for now.
In the (hopefully) not too distant future, we will be moving to a different scm backend.
We will revisit this issue at that time if needed.

@cactus: I'm not suggesting this needs to be done (especially since you said things may change in the future), but using your foo example above, isn't it as simple as searching the database for any other packages with pkgname=foo and grabbing their repo if one exists?

Let me quote from myself from two comments ago:

"""
If the package soley exists in testing, the problem is even worse (because there is no way we could just do a second query, get the non-testing package, and find out which repo *that one* is in).
"""

Right, I saw that. But how does that prevent a fix for those packages that do have a non-testing package?

if package_name_also_in_non-testing_repo:
correct link!
else:
bad link :(

We should just fail hard now if it is *only* in testing.
go us!