Re: Packaging ghostscript's X11 support separately
Jonathan Underwood wrote: On 18 December 2014 at 17:57, Peter Lemenkov lemen...@gmail.com wrote: 2014-12-18 20:20 GMT+03:00 Tim Waugh twa...@redhat.com: I could package it in its own sub-package, ghostscript-x11, but that might be a bit surprising to people who expect 'ghostscript' to have an x11alpha driver. Alternatively I could move everything else from ghostscript to a new sub-package ghostscript-base, and have 'ghostscript' (i.e. just the X11.so plugin) require ghostscript-base (i.e. everything else). The latter approach (ghostscript depending on *-core and *-x11/gui) is better. it won't break any installations while providing enough flexibility for the new ones. ... but has the downside that many packages will need to change their Requires from ghostscript to ghostscript-core to prevent them from pulling in the X stack. That strikes me as the right way round. If you don't change your requires, you still get what you currently get. If you want to trim them, you change to ghostscript-core. -- Paul Flo Williams http://hisdeedsaredust.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Reopening: Q: webfonts:
Petr Vobornik wrote: Nicolas Mailhot wrote: Just write a fontforge or ttx script that flips this bit at rpm build time, assuming you've done your legal review correctly the bit is in contradiction with the font license (if the font was no installable we could not package it in the first place). You'll be doing nothing more than fixing a bug in upstream's font implementation. OK, seems to be the easiest way. Originally, I wanted to avoid it because idk what is the correct way. I've created a simple script to do it: [snip] The script is not good because it doesn't touch only OS/2 table but it regenerates the whole font file (different GPOS, dropping DSIG and without fmflags also dropping KERN table). I've also tried to use ttx with a hope that it won't touch other tables, but it crashed on parsing OpenSans font. Considering changing fsType is just a change to 16 bits + a 32-bit checksum, it shouldn't be necessary to regenerate the entire font. In fact, Tom7 created a program to do just this job many years ago, called embed: http://carnage-melon.tom7.org/embed/ I've just improved this to recalculate the OS/2 table checksum correctly and handle multiple fonts in one go: https://github.com/hisdeedsaredust/ttembed If you'd like to package this as well, you could use it in your Open Sans package and you'd have something else to show sponsors :-) -- Paul Flo Williams http://hisdeedsaredust.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Reopening: Q: webfonts:
Nicolas Mailhot wrote: Le Mer 27 novembre 2013 15:39, Petr Vobornik a écrit : OTF/TTF fails in all modern versions of IE when the font does not have embedding permissions set to 'installable' [1]. It's more common that one would say. Of course it is very common, it's the default setting in most font authoring tools, and the authors of those tools were very much against web fonts in the first place. So font authors that actually want to do web fonts and actually choose free font licenses get betrayed by their tooling. And a lot of them do not care for ie at all anyway. Just write a fontforge or ttx script that flips this bit at rpm build time, assuming you've done your legal review correctly the bit is in contradiction with the font license (if the font was no installable we could not package it in the first place). You'll be doing nothing more than fixing a bug in upstream's font implementation. Perhaps we should add this to the font packaging guidelines? Flipping through the 235 packaged fonts installed on my system, I see that 26 of them have fsType fields that limit embedding rights. The ones affected are those from smaller foundries and OFLB, as you might expect, but also Droid Sans, which was a surprise. -- Paul Flo Williams http://hisdeedsaredust.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Software Management call for RFEs
john.flor...@dart.biz wrote: From: Rahul Sundaram methe...@gmail.com What I would like to see is solid git integration. Git has become the standard distributed vcs and github and google code etc have stopped hosting tarballs and/or discouraging it and GNOME is planning to do that as well. If Source URL could point directly to a git url with a hash or git tag, we would benefit. Amen to that! I roll my own rpms daily from locally developed sources where we have no policy of pushing tarballs. From everything I've ever been able to figure out, it's necessary for me to make temporary tarballs just to feed rpmbuild. It always seems such a huge waste of time, especially for very large packages. RPM would still be making tarballs behind the scenes, even with better integration with git, wouldn't it? -- you still need the ability to make SRPMs. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora release name problem
Jaroslav Reznik wrote: - Original Message - Once upon a time, G.Wolfe Woodbury redwo...@gmail.com said: submit a Feature and do proper testing/bug fixing/etc. for a future release (if and when another name with non ASCII alphanumeric characters is chosen). +1! Jaroslav What do you mean, if and when? I can already see the next Release Name page shaping up with Motörhead's Moshpit is a name with non ASCII alphanumeric characters, like ... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
afraid-dyndns has been orphaned
afraid-dyndns has recently been orphaned, following a discussion here: https://bugzilla.redhat.com/show_bug.cgi?id=830458 Upstream used to maintain the package in Fedora but no longer remembers how(!) Apologies if this is a repeat, but I don't recall seeing a mention here. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Unusual SCM Request?
I'm trying to make an SCM Request on a Package Review ticket to add a pseudo-user (the Fonts SIG) to a fonts package that has already been approved. I'd like to do a number of these, but I've started with bug 857487: https://bugzilla.redhat.com/show_bug.cgi?id=857487#c4 I thought that the template I've used followed the one shown here: http://fedoraproject.org/wiki/Package_SCM_admin_requests#Package_Change_Requests_for_existing_packages As the request is unusual, I've explained the meaning of the template below the comment, per the wiki explanation, which says that If you need other special changes done which cannot be handled by the template field, such as a package that was created with the wrong name that has never been imported or built, or otherwise out of the scope of the template please state your desire and justification below the template in your Bugzilla comment. However, the SCM request has been cancelled with the comment Misformatted request. Could anyone here enlighten me further? The wiki page doesn't make it clear who Admins are, so I'm also not sure whether Infrastructure or Rel-eng deal with these requests. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Licence change for vollkorn-fonts
I've just picked up the recently orphaned vollkorn-fonts. A new (May 2010!) release is available, and the licence has changed from CC-BY to OFL. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages in F-16 (v3)
Bill Nottingham wrote: Each release, before branching, we block currently orphaned packages. It's that time again for Fedora 16. Orphan jomolhari-fonts Orphan kanjistrokeorders-fonts Orphan tibetan-machine-uni-fonts Taken. EPEL branches for kanjistrokeorders-fonts are available. -- Paul Flo Williams http://hisdeedsaredust.com/category/fonts/feed -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Unorphaning onesixtyone
Now that the revised orphaning procedure allows me to pick this up without a re-review, I've just claimed onesixtyone in the pkgdb. onesixtyone is a tiny SNMP tool that spews multiple simultaneous SNMP requests and reports the results. It has been unloved since F12, but I use it fairly frequently, it has no outstanding bugs and has been stable upstream since 2002. Having said that, I'm about to become upstream because I want a man page and I've added the ability to quickly scan subnets without enumerating all the IPs by hand. When I've built it for devel, I'll pick up the other branches, including EPEL. -- Paul Flo Williams http://hisdeedsaredust.com/category/fonts/feed -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packages that will be orphaned
Richard Shaw wrote: On Tue, Jun 21, 2011 at 2:22 AM, Hans de Goede hdego...@redhat.com wrote: And I've also taken the liberty of sending a personal mail to nim (Nicolas Mailhot) pointing out that he needs to sign the new CLA, to stop all the font packages he is the owner of getting orphaned. If you do get a hold of Nicolas let him know he can have google-droid-fonts back if he wants it. I'm not a fonts guy and reading through the bug reports I can see I'm over my head. Don't worry about it. I pinged Nim this morning too, and told Toshio that I'd take all unclaimed font packages, including fontpackages and xgridfit, if Nim isn't able to. I'll co-maintain Droid if you need a hand. Regarding #517789, at a quick glance it seems to be held on determining the fontconfig incantations to correctly prioritise bits of Droid, and doesn't look broken at the moment, so it can be left as FutureFeature. -- Paul Flo Williams http://hisdeedsaredust.com/category/fonts/feed -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Self Introduction
Khusro Jaleel wrote: I asked Máirín Duffy on twitter what I could do to contribute for packages and she suggested fonts as an easy place to start so here I am :-) She might have been half joking. Although packaging fonts is theoretically easy because of the packaging templates we use, the state of upstream archives is often very poor, with no clear versioning, missing licenses and limited language coverage. Welcome :-) She has suggested some fonts I could package so I'm working through the first one, League Gothic. I'm having some trouble understanding what foundries are and how font packaging works in Fedora in general so any help along those lines is much appreciated. The font packaging lifecycle is here: https://fedoraproject.org/wiki/Font_package_lifecycle League Gothic is already on the wishlist, so its page is here: https://fedoraproject.org/wiki/TLOMT_League_Gothic_fonts A foundry is an organisation or single person who issues fonts. The League of Moveable Type is one such, and our foundry abbreviation for them is tlomt. You'll find some of their other fonts have been packaged already, so taking a look at those src.rpms may give you some pointers. If you look through the wiki pages of fonts that have already been packaged, you'll find the bugzilla numbers of their review requests, and looking through some of the comments in those reviews will help you avoid common mistakes. I would recommend you join the fonts mailing list if you have further questions. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Font fallback for non-latin unicode chars
Martin Langhoff wrote: When you open a page with Armenian characters such as http://en.wikipedia.org/wiki/Armenian_language the font server (or perhaps xulrunner) digs around to find a font that has that codepoint. Often it's just one font in your system that can provide it (so if you ask for it to be styled in serif, sans, monospace... it's always the same). Is there a way to query (or see a log) that describes what font has been used? Or a means to query what fonts supply unicode codepoint N? Fedora uses language provides on fonts, so you can see which scripts are supported in your currently-installed fonts: rpm -q --whatprovides 'font(:lang=hy)' or in fonts you may not have installed: yum whatprovides 'font(:lang=hy)' -- Paul Flo Williams http://hisdeedsaredust.com/category/fonts/feed -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
