Description of problem: When upgrading from 20081007-6.fc11 to 20081007-7.fc11 I got an error message from yum while building the package list. Uninstalling and reinstalling, got by the problem. I lost the exact error message, but it referred to 8 bit bytes and text-factory. apanov-heuristica-fonts has the same issue. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
It's a yum bug. Yum chokes on rpmbuild-generated autoprovides (rpm itself is fine with them as a rpm -Uvh will show)
# yum --skip-broken -y update Loaded plugins: dellsysidplugin2, post-transaction-actions, refresh-packagekit Excluding Packages in global exclude list Finished Setting up Update Process Resolving Dependencies --> Running transaction check ---> Package apanov-edrip-fonts.noarch 0:20081007-7.fc11 set to be updated Error: You must not use 8-bit bytestrings unless you use a text_factory that can interpret 8-bit bytestrings (like text_factory = str). It is highly recommended that you instead just switch your application to Unicode strings.
can you show all the versions of: python sqlite python-sqlite yum rpm installed on your system?
I have updated some stuff since then and am not sure the current versions are the same as the ones I was using then. (They might be though as I have had several attempts at finishing the updates after the mass rebuild thwarted by file conflicts.) python-2.6-4.fc11.x86_64 yum-3.2.21-11.fc11.noarch rpm-4.6.0-11.fc11.x86_64 sqlite-3.6.10-3.fc11.i386 sqlite-3.6.10-3.fc11.x86_64 package python-sqlite is not installed
After looking around I think maybe you meant to ask about python-sqlite2-2.3.3-5.fc11.x86_64.
I upgraded yum and rpm first ... but I had no problem upgrading the fonts as part of a mass update, or on their own.
*** Bug 488058 has been marked as a duplicate of this bug. ***
thanks james, version info later. problem is package related or yum ?
unclear. Nicholas, I can replicate this - but it is ONLY on the upgrade from -6 to -7 of apanov-edrip-fonts. I'll try to track it back to see where the problem is.
-6 and -7 are the only edrip versions built with an rpm that includes font autoprovides magic (as I noted in comment #1). Edrip and Heuristica are also currently our only fonts where upstream uses non-ascii font metadata. I suppose both of those trigger a yum bug Panu didn't notice when he did his coding (rpm itself seems fine)
okay, a little more debugging. So the font provides being generated. One of them appears to be a unicode string. However, when I get it back from rpm-python from the hdr object it is being reported as a string object - is there something I'm missing in between?
Package related, if I exclude the apanov fonts, I can upgrade everything else. Versions: python-2.6-5.fc11.i586 sqlite-3.6.10-4.fc11.i586 python-sqlite2-2.3.3-6.fc11.i586 yum-3.2.21-11.fc11.noarch rpm-4.6.0-11fc11.i586
okay, I've been mucking with this for a good portion of the day. There are two problems here: 1. it looks like rpm is generating an encoded string as a provide 2. rpm-python appears to be claiming it is a string object Additionally the provides generated by the fontprov script are; config(apanov-edrip-fonts) = 20081007-7.fc11 font(:lang=ava) font(:lang=be) font(:lang=bg) font(:lang=ce) font(:lang=fj) font(:lang=ho) font(:lang=ia) font(:lang=ie) font(:lang=ik) font(:lang=io) font(:lang=kum) font(:lang=kv) font(:lang=lez) font(:lang=mn-mn) font(:lang=ms) font(:lang=nr) font(:lang=om) font(:lang=os) font(:lang=ru) font(:lang=rw) font(:lang=sel) font(:lang=sh) font(:lang=so) font(:lang=sr) font(:lang=ss) font(:lang=st) font(:lang=sw) font(:lang=ts) font(:lang=uk) font(:lang=xh) font(:lang=zu) font(edrip) font(едрип) apanov-edrip-fonts = 20081007-7.fc11 Do we really want an '=' in the name section of a provide? I kinda hope we do not. I think the provides script needs some love and I think we need to figure out what rpm-python is doing with the objects it is getting. Panu, Florian, Jindrich comments?
(In reply to comment #13) > okay, I've been mucking with this for a good portion of the day. There are two > problems here: > > 1. it looks like rpm is generating an encoded string as a provide Since the autoprovides stuff extracts metadata from the font files, and I don't think any font format spec mandates this metadata must be ASCII only, this is pretty much required to work with font files. > 2. rpm-python appears to be claiming it is a string object This is probably the bug > Additionally the provides generated by the fontprov script are; > > config(apanov-edrip-fonts) = 20081007-7.fc11 > font(:lang=ava) ... > font(edrip) > font(едрип) This font file declares two names, one ASCII and the other — not. This is an upstream choice. Each of the names can be referenced in a digital document, wo we can't really drop it if we want autoinstall to work. > apanov-edrip-fonts = 20081007-7.fc11 > > > Do we really want an '=' in the name section of a provide? I kinda hope we do > not. Behdad really liked this syntax, it's very close to the kind of options every fontconfig command knows how to process. Since it was properly enclosed in a font() namespace Panu and Richard let it be. > I think the provides script needs some love It's not a script it's a binary that was coded for packaging systems such as rpm/pk The problem I have with that any syntax change requires a rebuild of all the packages providing fonts before the next release (including beasts like OO.o) and I'd really like not to do one every other week. > and I think we need to figure out > what rpm-python is doing with the objects it is getting. > > Panu, Florian, Jindrich comments?
(In reply to comment #13) > Do we really want an '=' in the name section of a provide? I kinda hope we do > not. Why not? I don't see how '=' is any different from '-' in this sense. > 2. rpm-python appears to be claiming it is a string object I think that's the bug also. (In reply to comment #14) > The problem I have with that any syntax change requires a rebuild of all the > packages providing fonts before the next release (including beasts like OO.o) > and I'd really like not to do one every other week. I second that -- we shouldn't be rebuilding everything again...
Just to make everything sideways: It looks like this is a conversion issue somewhere. if I localupdate the pkg in question it works. Getting the metadata from the repodata is where it all goes horribly wrong.
Adding a bit more detail. This problem does not surface if: 1. the older pkg is not installed and you are only installing the pkg 2. the newer pkg is being installed from a localpkg Which suggests it's the process of traversing the provides coming out of the rpmdb for the older pkg which is tripping it up. this note is mostly for my own sanity, no other comments needed.
nicholas, can you check out latest yum from yum's git repo and give it a try?
latest rawhide pkg yum-3.2.21-14 has a patch that I believe fixes this problem entirely.
It works on my rawhide system with rpm-4.7.0-0.beta1.4.fc11.x86_64 yum-3.2.21-15.fc11.noarch Thank you for fixing this
also fixed by yum -15. Thank you for a very interesting discussion.