|Summary:||FTBFS in rawhide|
|Product:||[Fedora] Fedora||Reporter:||Parag Nemade <pnemade>|
|Component:||lilypond||Assignee:||Gwyn Ciesla <gwync>|
|Status:||CLOSED RAWHIDE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2015-01-21 17:41:59 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Parag Nemade 2014-10-20 09:14:52 UTC
Description of problem: For the gnome-software font metainfo file addition, I rebuild this package in fedora 21 successfully but its failed in rawhide. I am filing this to make sure we will not miss this to fix. I will look into this issue by next week otherwise package maintainer or anyone else can fix this issue before me :) Actual results: http://koji.fedoraproject.org/koji/buildinfo?buildID=586524 Expected results: should be built successfully
Comment 1 Parag Nemade 2014-11-04 05:43:54 UTC
Finally found its problem of urw-fonts package. This is different package in F22 compared to F21 that is why F21 lilypond build worked but F22 not. lilypond build in F22 is failing due to checking for New Century Schoolbook PFB files... no which mean fc-list "Century Schoolbook L:foundry=urw:fontformat=Type 1:lang=ru" does not show any results in F22 as urw-fonts is changed now. Let me file a bug against urw-fonts for this.
Comment 2 Parag Nemade 2014-11-04 06:08:25 UTC
Jon, I have filed bug1160132 for urw-fonts but I am not sure how to fix this. Can you look into this issue? Thanks.
Comment 3 Gwyn Ciesla 2014-11-04 12:58:59 UTC
Thanks for looking into this. I'm thinking of updating rawhide to the latest dev release, and there's a chance that might fix the issue. There may be nothing the urw-fonts maintainer can do.
Comment 4 Gwyn Ciesla 2014-11-04 14:48:40 UTC
That didn't help, same problem.
Comment 5 Gwyn Ciesla 2015-01-21 17:41:59 UTC
urw-fonts change reverted, built in rawhide.
Comment 6 Parag Nemade 2015-01-22 04:23:56 UTC
Thanks Jon for looking into this issue.