Michael Ciuffo created a sanserif typeface in the style of xkcd. Here is an ebuild. What it can look like: https://build.enlightenment.org/view/Test%20Coverage/ Reproducible: Always
Created attachment 356126 [details] media-fonts/humor-sans/humor-sans-9999.ebuild
This package has no maintainer so this bug may go unnoticed for a long time. Gentoo has a dedicated team[1] for assisting users in maintaining orphaned packages. If you are interested in maintaining this package, please contact proxy-maint@gentoo.org. [1]: http://www.gentoo.org/proj/en/qa/proxy-maintainers/index.xml
> media-fonts/humor-sans/humor-sans-9999.ebuild Users will likely want to use this without unmasking the package; so, for their convenience, I think we should regularly check this file and take a snapshot from it. The way the ebuild is now, it would break with a checksum mismatch whenever the file is changed; so, we can't really add it like this and expect users to unmask it. (We can add the 9999 to check breakage alongside the snapshots) Quoting from an important note in the Gentoo Developer Handbook [1]: > Snapshot ebuilds of pre-release CVS sources should be named as follows: foo x.y_preYYYYMMDD.ebuild. foo is the package name, x.y is the version number of the upcoming release, _pre is a literal string, and YYYYMMDD is a timestamp of the day the CVS snapshot was taken. Use this naming convention to ensure that a x.y.1 release version won't be considered to be older than a x.y snapshot, while at the same time ensuring that the official x.y release will be considered newer than your CVS snapshot version. For CVS snapshots of already-released CVS sources, use the format foo-x.y_pYYYYMMDD.ebuild (notice the _p for "patchlevel.") This will ensure that your CVS ebuild will be considered newer than the standard x.y release. Whenever this reads CVS sources, you could basically assume the file instead. The license permits redistribution under some permissions, so merely rehosting the file should not appears to be a problem; another option, although I suspect the font won't change that much and therefore might not be done, is to contact the author in an attempt to ask if he can give the font versions. Or at least we can ask if he can guarantee that the file itself won't change; that way, it could be considered as already versioned. As you can see, some part of maintenance is upstreaming efforts where possible. If you want, or can't host yourself; one of us can rehost the file for you. [1]: http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1
(In reply to Tom Wijsman (TomWij) from comment #3) > > media-fonts/humor-sans/humor-sans-9999.ebuild > > Users will likely want to use this without unmasking the package True. The main reason for me to not have KEYWORD it is that I was considering it a live ebuild as we have no available version, so can lead to checksum mismatch. > so, for > their convenience, I think we should regularly check this file and take a > snapshot from it. The way the ebuild is now, it would break with a checksum > mismatch whenever the file is changed; so, we can't really add it like this > and expect users to unmask it. (We can add the 9999 to check breakage > alongside the snapshots) > > Quoting from an important note in the Gentoo Developer Handbook [1]: > > > Snapshot ebuilds of pre-release CVS sources should be named as follows: foo x.y_preYYYYMMDD.ebuild. foo is the package name, x.y is the version number of the upcoming release, _pre is a literal string, and YYYYMMDD is a timestamp of the day the CVS snapshot was taken. Use this naming convention to ensure that a x.y.1 release version won't be considered to be older than a x.y snapshot, while at the same time ensuring that the official x.y release will be considered newer than your CVS snapshot version. For CVS snapshots of already-released CVS sources, use the format foo-x.y_pYYYYMMDD.ebuild (notice the _p for "patchlevel.") This will ensure that your CVS ebuild will be considered newer than the standard x.y release. > > Whenever this reads CVS sources, you could basically assume the file instead. > > The license permits redistribution under some permissions, so merely > rehosting the file should not appears to be a problem; another option, > although I suspect the font won't change that much and therefore might not > be done, is to contact the author in an attempt to ask if he can give the > font versions. Or at least we can ask if he can guarantee that the file > itself won't change; that way, it could be considered as already versioned. I'm contacting the font author asking him if he can add some versioning in filenaming, otherwise I can do this versioning based on date and host it.
(In reply to Bertrand Jacquin from comment #4) > (In reply to Tom Wijsman (TomWij) from comment #3) > > > media-fonts/humor-sans/humor-sans-9999.ebuild > > > > Users will likely want to use this without unmasking the package > > True. The main reason for me to not have KEYWORD it is that I was > considering it a live ebuild as we have no available version, Agreed. > so can lead to checksum mismatch. No, the version or keywords have no implication on this; even as 9999, it will still result in a checksum mismatch. You would need to inherit an eclass from one or another vcs to get this behavior to change. > I'm contacting the font author asking him if he can add some versioning in > filenaming, otherwise I can do this versioning based on date and host it. Yes, then you can also use the checksum of the file to see if it has changed.
Created attachment 356536 [details] media-fonts/humor-sans/humor-sans-1.0.ebuild (In reply to Bertrand Jacquin from comment #4) > (In reply to Tom Wijsman (TomWij) from comment #3) > > > media-fonts/humor-sans/humor-sans-9999.ebuild > > > > Users will likely want to use this without unmasking the package > > True. The main reason for me to not have KEYWORD it is that I was > considering it a live ebuild as we have no available version, so can lead to > checksum mismatch. > > > so, for > > their convenience, I think we should regularly check this file and take a > > snapshot from it. The way the ebuild is now, it would break with a checksum > > mismatch whenever the file is changed; so, we can't really add it like this > > and expect users to unmask it. (We can add the 9999 to check breakage > > alongside the snapshots) > > > > Quoting from an important note in the Gentoo Developer Handbook [1]: > > > > > Snapshot ebuilds of pre-release CVS sources should be named as follows: foo x.y_preYYYYMMDD.ebuild. foo is the package name, x.y is the version number of the upcoming release, _pre is a literal string, and YYYYMMDD is a timestamp of the day the CVS snapshot was taken. Use this naming convention to ensure that a x.y.1 release version won't be considered to be older than a x.y snapshot, while at the same time ensuring that the official x.y release will be considered newer than your CVS snapshot version. For CVS snapshots of already-released CVS sources, use the format foo-x.y_pYYYYMMDD.ebuild (notice the _p for "patchlevel.") This will ensure that your CVS ebuild will be considered newer than the standard x.y release. > > > > Whenever this reads CVS sources, you could basically assume the file instead. > > > > The license permits redistribution under some permissions, so merely > > rehosting the file should not appears to be a problem; another option, > > although I suspect the font won't change that much and therefore might not > > be done, is to contact the author in an attempt to ask if he can give the > > font versions. Or at least we can ask if he can guarantee that the file > > itself won't change; that way, it could be considered as already versioned. > > I'm contacting the font author asking him if he can add some versioning in > filenaming, otherwise I can do this versioning based on date and host it. Done. Here is the Author response : « I have no plans to release a newer version, but I went ahead and versioned it v1.0. I've updated the page. http://www.antiyawn.com/uploads/humorsans.html » So here is an updated ebuild
Created attachment 356576 [details] media-fonts/humor-sans/humor-sans-1.0.ebuild Fix src_install warning cause by missing FONT_S, name the font file with no version
+ 01 Sep 2013; Tom Wijsman <TomWij@gentoo.org> +Humor-Sans-1.0.ebuild, + +metadata.xml: + New ebuild for Humor-Sans, a sanserif typeface in the style of xkcd. Proxied + commit for Bertrand Jacquin, who will be maintaining this package; fixes bug + #481224.