updated yum packages are now available in c5-testing
 

Manuel Wolfshant wrote:
> I've just noticed that there is a small typo in %description for
> yum-basearchonly. Quoting the relevant part only:
> Description: this plugin makes Yum only install basearch packages on
> multiarch systems. If you type 'yum install
> : foo' on a x68_64 system, only 'foo-x.y.x86_46.rpm' is
> installed.
>
> note that x68_64 != x86_46 (and neither one is correct.)
> This is also valid for 1.1.10-9.el5.centos (from Base) and for
> 1.1.14-0_beta_15_2.el5.centos (testing)
>
>
> And I think that the license (GPL) is also not correct, all other
> plugins coming from the same source seem to be GPLv2+
>

Sounds like something for upstream really. Otherwise we can make the
change locally as well.

Thanks for looking.

- KB
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel

updated yum packages are now available in c5-testing
 

On Mon, 2008-12-22 at 12:29 -0800, Akemi Yagi wrote:
> On Fri, Dec 12, 2008 at 4:56 PM, Karanbir Singh <mail-lists@karan.org> wrote:
> > The following packages have been updated in the testing repo :
> > ./5/testing/SRPMS/yum-utils-1.1.16-13.el5.centos.src.rpm
> > ./5/testing/SRPMS/yum-3.2.19-18.el5.centos.src.rpm
>
> > test these on non-production machines only for now. And all feedback is
> > appreciated.
>
> yum-3.2.19-18 produces the following errors if run with the
> "--enablerepo=atrpms" option.

It goes back to working again, if you use the older yum version? Does
it then fail again if you re-use the newer yum?

[...]
> File "/usr/lib/python2.4/site-packages/yum/sqlitesack.py", line 470,
> in _sql_pkgKey2po
> pkg = self._packageByKey(repo, ob['pkgKey'])
> File "/usr/lib/python2.4/site-packages/yum/sqlitesack.py", line 413,
> in _packageByKey
> po = self.pc(repo, cur.fetchone())
> File "/usr/lib/python2.4/site-packages/yum/sqlitesack.py", line 68,
> in __init__
> self._read_db_obj(db_obj)
> File "/usr/lib/python2.4/site-packages/yum/sqlitesack.py", line 94,
> in _read_db_obj
> setattr(self, item, _share_data(db_obj[item]))
> TypeError: unsubscriptable object

This is more understandable upstream by:

http://yum.baseurl.org/gitweb?p=yum.git;a=commitdiff;h=3120676a73219b018d 317d8adaac0d858d751a3b;hp=54bd2c6eebf6be6b2596e255 38bff6b35e34c443

...which gives a "nice" message. There is also a change to
yum-metadata-parser, which should work around the problem in atrpms.
The short term. fixes are:

1. Don't use atrpms.

2. Use "yum clean metadata"

--
James Antill <james@fedoraproject.org>
Fedora
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel

updated yum packages are now available in c5-testing
 

On Mon, 2008-12-22 at 23:57 +0200, Axel Thimm wrote:
> On Mon, Dec 22, 2008 at 10:34:55PM +0100, Dag Wieers wrote:
> > Can you be a little bit more specific ? Is there a thread describing the
> > issue ? Is there going to be a real fix for it ?
> >
> > I really don't feel good with this patch. The error does not indicate
> > to a user that a "yum clean metadata" resolves their problem.
> >
> > If we are going to have all our users that use atrpms go through this by
> > default, then I think we should avoid it at all cost.

The BZ I can easily find is RH 465898:

[https://bugzilla.redhat.com/show_bug.cgi?id=465898
TypeError: 'NoneType' object is unsubscriptable error in
sqlitesack.py:94:_read_db_obj (pkgId can't be found)]

...although I'm sure we discussed something with You or Axel at one
point about multiple pkgId's in one repo. The yum-metadata-parser "fix"
is:

http://yum.baseurl.org/gitweb?p=yum-metadata-parser.git;a=commitdiff;h=c5033bfe5484ec3ecd49f1bf 8801c6a8163df482

...which seems to have cured it (just disables the "optimized" code
path, which doesn't like multiple pkgId's).

> I also don't understand the patch mentioned above. What at ATrpms
> upsets the new yum that way?

The yum patch is to stop the backtraces, and give a warning to the user
that the repo. is currently broken.

AFAIK it should break equally on all versions of yum¹, but given how it
breaks the yum .sqlite files it's not really possible to see it in
action. Maybe older versions of yum wouldn't use pkgKey in the same
way ... so if multiple pkgId's broke the pkgKey's then it'd still work.
Not sure.

> If it's something I can fix on my end,
> I'd gladly do so, but I'm just using plain createrepo (and this seems
> to work with the yum version in question with other distros).

Pass -d to create repo. and it'll work (and be faster).


¹ Hence my interest in any information from the reporter here to
disprove that.

--
James Antill <james@fedoraproject.org>
Fedora
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel

updated yum packages are now available in c5-testing
 

On Tue, 2008-12-23 at 00:04 +0100, Dag Wieers wrote:
> On Mon, 22 Dec 2008, James Antill wrote:
>
> > On Mon, 2008-12-22 at 23:57 +0200, Axel Thimm wrote:
> >> On Mon, Dec 22, 2008 at 10:34:55PM +0100, Dag Wieers wrote:
> >> > Can you be a little bit more specific ? Is there a thread describing the
> >> > issue ? Is there going to be a real fix for it ?
> >
> > The BZ I can easily find is RH 465898:
> >
> > [https://bugzilla.redhat.com/show_bug.cgi?id=465898
> > TypeError: 'NoneType' object is unsubscriptable error in
> > sqlitesack.py:94:_read_db_obj (pkgId can't be found)]
> >
> > ...although I'm sure we discussed something with You or Axel at one
> > point about multiple pkgId's in one repo.
>
> It wasn't me. How can multiple pkgId's be in one repo ?

The pkgId is¹ just the sha1sum of the .rpm file (from the checksum
element), so the easiest way is:

% mkdir foo foo/1 foo/2
% cp yum-3.2.20-3.fc10.noarch.rpm foo/1
% cp yum-3.2.20-3.fc10.noarch.rpm foo/2
% createrepo foo

...the usual way I've seen this happen is due to multilib (two .i386
packages, one in a i386 dir. and one in a x86_64 dir. say).

> I can add that I would be happy to use the latest and greatest createrepo
> if those newer versions would work with older distributions (namely, older
> python versions) and if they can produce metadata that works with older
> yum/apt releases as well. (Also on RHEL2.1 and RH7.3 systems)

AFAIK noone has any plans to backport any version of createrepo to work
with RHEL-2.1 or older.
There is a nebulous plan to create a simple script² which can be used
on "older" releases, which will take the normal createrepo (without -d)
and just add the .sqlite files in.
How far back it'll go isn't clear yet (having not been written), but
I'd guess that without help from you RHEL-2.1 is probably not going to
be tested.


¹ This will probably change a bit "soon", but mainly for Fedora 11 /
CentOS 6 timeframes ... and it should just work with older/current
createrepo too.

² In theory this is easy in that it just needs to call the APIs yum
calls, and then do the modifyrepo thing ... but again noone's done it,
yet.

--
James Antill <james@fedoraproject.org>
Fedora
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel

updated yum packages are now available in c5-testing
 

On Tue, 2008-12-23 at 08:12 +0200, Axel Thimm wrote:
> On Mon, Dec 22, 2008 at 05:48:22PM -0500, James Antill wrote:
> > > If it's something I can fix on my end,
> > > I'd gladly do so, but I'm just using plain createrepo (and this seems
> > > to work with the yum version in question with other distros).
> >
> > Pass -d to create repo. and it'll work (and be faster).
>
> OK, which version of createrepo should be used (distribution range is
> EL3-5, F8-10)? Currently I use 0.4.9, but there is even 0.9.6
> available.

Any version 0.4.9 or later should be fine (I think even 0.4.4 will
work, but I haven't checked).
Anything "recent" will also add group_gz which the yum in testing
can/will use, but that's just a bonus if it's not a problem to use that.

> Or does it not matter wrt the outcome?

In theory the DB is versioned, so you can have createrepo make a
version that yum doesn't like ... I don't think this has ever been
possible though, and it's very likely we won't use this feature going
forward due to the downsides (the client has to download the .sqlite
file to work out it can't use it -- and it'd currently "break"
mdpolicy).

--
James Antill <james@fedoraproject.org>
Fedora
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel