Bug 487912 - Unable to upgrade apanov-edrip-fonts, due to i18n provide issue
Summary: Unable to upgrade apanov-edrip-fonts, due to i18n provide issue
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: yum
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Seth Vidal
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 488058 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-03-01 10:45 UTC by Bruno Wolff III
Modified: 2014-01-21 23:08 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-03-14 13:18:09 UTC
Type: ---


Attachments (Terms of Use)

Description Bruno Wolff III 2009-03-01 10:45:31 UTC
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:

Comment 1 Nicolas Mailhot 2009-03-01 11:02:21 UTC
It's a yum bug. Yum chokes on rpmbuild-generated autoprovides (rpm itself is fine with them as a rpm -Uvh will show)

Comment 2 Nicolas Mailhot 2009-03-01 11:09:34 UTC
# 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.

Comment 3 seth vidal 2009-03-02 14:44:31 UTC
can you show all the versions of:
python
sqlite
python-sqlite
yum
rpm

installed on your system?

Comment 4 Bruno Wolff III 2009-03-02 15:59:17 UTC
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

Comment 5 Bruno Wolff III 2009-03-02 16:05:32 UTC
After looking around I think maybe you meant to ask about python-sqlite2-2.3.3-5.fc11.x86_64.

Comment 6 James Antill 2009-03-02 16:07:30 UTC
I upgraded yum and rpm first ... but I had no problem upgrading the fonts as part of a mass update, or on their own.

Comment 7 James Antill 2009-03-02 16:07:53 UTC
*** Bug 488058 has been marked as a duplicate of this bug. ***

Comment 8 Herbert Carl Meyer 2009-03-02 16:56:06 UTC
thanks james, version info later. problem is package related or yum ?

Comment 9 seth vidal 2009-03-02 17:28:36 UTC
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.

Comment 10 Nicolas Mailhot 2009-03-02 18:10:11 UTC
-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)

Comment 11 seth vidal 2009-03-02 18:28:32 UTC
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?

Comment 12 Herbert Carl Meyer 2009-03-02 19:51:23 UTC
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

Comment 13 seth vidal 2009-03-02 22:21:38 UTC
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?

Comment 14 Nicolas Mailhot 2009-03-02 22:55:55 UTC
(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?

Comment 15 Richard Hughes 2009-03-03 08:38:07 UTC
(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...

Comment 16 seth vidal 2009-03-03 17:54:22 UTC
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.

Comment 17 seth vidal 2009-03-03 18:12:10 UTC
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.

Comment 18 seth vidal 2009-03-12 05:42:44 UTC
nicholas, can you check out latest yum from yum's git repo and give it a try?

Comment 19 seth vidal 2009-03-12 16:44:01 UTC
latest rawhide pkg yum-3.2.21-14 has a patch that I believe fixes this problem entirely.

Comment 20 Nicolas Mailhot 2009-03-14 13:18:09 UTC
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

Comment 21 Herbert Carl Meyer 2009-03-15 00:08:41 UTC
also fixed by yum -15. Thank you for a very interesting discussion.


Note You need to log in before you can comment on or make changes to this bug.