I would like to update the fedora package for asciidoc as our software's documentation requires an asciidoc >= 8.6.2 to be built and fedora still ships with 8.4.5 (even in rawhide).
One of the patches no longer applies cleanly and I wanted to see if it was implemented upstream or not. It's called datadir (see attached asciidoc-8.4.5-datadir.patch). And I couldn't figure it out..
Fails with: 1 out of 2 hunks FAILED -- saving rejects to file asciidoc.py.rej 4 out of 4 hunks FAILED -- saving rejects to file Makefile.in.rej
The other one has been integrated[1] so I'm droppping it.
On 19 April 2012 04:29, Olivier Bilodeau <obilod...@inverse.ca> wrote:
> Hi,
> I would like to update the fedora package for asciidoc as our software's > documentation requires an asciidoc >= 8.6.2 to be built and fedora still > ships with 8.4.5 (even in rawhide).
> One of the patches no longer applies cleanly and I wanted to see if it > was implemented upstream or not. It's called datadir (see attached > asciidoc-8.4.5-datadir.patch). And I couldn't figure it out..
Hi,
No its not integrated, but I can't figure out what it is trying to achieve?
Note, the handling of all plugins was unified in 8.6.6 for backends, filters and themes and that is probably why it doesn't apply. With this change the patch might not be required any more or it will need to be completely re-written depending on what it is trying to do.
> -- > You received this message because you are subscribed to the Google Groups "asciidoc" group. > To post to this group, send email to asciidoc@googlegroups.com. > To unsubscribe from this group, send email to asciidoc+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/asciidoc?hl=en.
>> I would like to update the fedora package for asciidoc as our software's
>> documentation requires an asciidoc >= 8.6.2 to be built and fedora still
>> ships with 8.4.5 (even in rawhide).
>> One of the patches no longer applies cleanly and I wanted to see if it
>> was implemented upstream or not. It's called datadir (see attached
>> asciidoc-8.4.5-datadir.patch). And I couldn't figure it out..
> Hi,
> No its not integrated, but I can't figure out what it is trying to achieve?
> Note, the handling of all plugins was unified in 8.6.6 for backends,
> filters and themes and that is probably why it doesn't apply. With
> this change the patch might not be required any more or it will need
> to be completely re-written depending on what it is trying to do.
It seems to put most of asciidoc's files under /usr/share/asciidoc/
instead of /etc/asciidoc/ in order to align with the Filesystem
Hierarchy Standard (FHS)[1]. Which says:
"The /etc hierarchy contains configuration files. A "configuration file"
is a local file used to control the operation of a program; it must be
static and cannot be an executable binary."
Is it something that asciidoc supports through it's Makefile now?
In any case, I'll look at what the debian package does and I'll update
the spec accordingly.
>>> I would like to update the fedora package for asciidoc as our software's
>>> documentation requires an asciidoc >= 8.6.2 to be built and fedora still
>>> ships with 8.4.5 (even in rawhide).
>>> One of the patches no longer applies cleanly and I wanted to see if it
>>> was implemented upstream or not. It's called datadir (see attached
>>> asciidoc-8.4.5-datadir.patch). And I couldn't figure it out..
>> Hi,
>> No its not integrated, but I can't figure out what it is trying to achieve?
>> Note, the handling of all plugins was unified in 8.6.6 for backends,
>> filters and themes and that is probably why it doesn't apply. With
>> this change the patch might not be required any more or it will need
>> to be completely re-written depending on what it is trying to do.
> It seems to put most of asciidoc's files under /usr/share/asciidoc/
> instead of /etc/asciidoc/ in order to align with the Filesystem
> Hierarchy Standard (FHS)[1]. Which says:
> "The /etc hierarchy contains configuration files. A "configuration file"
> is a local file used to control the operation of a program; it must be
> static and cannot be an executable binary."
> Is it something that asciidoc supports through it's Makefile now?
> In any case, I'll look at what the debian package does and I'll update
> the spec accordingly.
Hi,
Ok, I see, it is high time distros stopped just dumping stuff in one
directory, but that gripe is OT for this list :)
On my machine it looks like debian configured it with prefix=/usr
datadir=/usr/share/asciidoc sysconfdir=/etc/asciidoc
But they must also have changed progsymlink to rename and not link the
"executables" asciidoc and a2x since they are python files without an
extension (bad Karma there too :(
> --
> You received this message because you are subscribed to the Google Groups "asciidoc" group.
> To post to this group, send email to asciidoc@googlegroups.com.
> To unsubscribe from this group, send email to asciidoc+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/asciidoc?hl=en.
> But they must also have changed progsymlink to rename and not link the
> "executables" asciidoc and a2x since they are python files without an
> extension (bad Karma there too :(
Hi again,
Told you it was bad Karma, this breaks Python import which requires
.py extension.
Since asciidocapi imports asciidoc it has to load the source manually
instead of letting the Python process work, and that disables
pre-compiled caching, meaning it has to compile the source each time.
Since that mess exists in asciidocapi you can get away with it if you
*MUST*, but it would be better if the normal asciidoc link method was
used so caching worked.
Or of course if you can suggest some alternative method that meets
both requirements and is suitably backward compatible that would be
even better :)
>> --
>> You received this message because you are subscribed to the Google Groups "asciidoc" group.
>> To post to this group, send email to asciidoc@googlegroups.com.
>> To unsubscribe from this group, send email to asciidoc+unsubscribe@googlegroups.com.
>> For more options, visit this group at http://groups.google.com/group/asciidoc?hl=en.
> Told you it was bad Karma, this breaks Python import which requires
> .py extension.
> Since asciidocapi imports asciidoc it has to load the source manually
> instead of letting the Python process work, and that disables
> pre-compiled caching, meaning it has to compile the source each time.
> Since that mess exists in asciidocapi you can get away with it if you
> *MUST*, but it would be better if the normal asciidoc link method was
> used so caching worked.
> Or of course if you can suggest some alternative method that meets
> both requirements and is suitably backward compatible that would be
> even better :)
I found a patch in the repoforge repository that applies cleanly and
meets the FHS requirement. I've updated the SPEC[1] and it also installs
the vim ftdetect and plugin. All stolen from Dag's work at repoforge. ;)
I attached the patch. Is this a "bad karma" patch? For us asciidoc has
been performing up to expectation with this and anyways compared to fop
I'm pretty sure it'll always be the faster part of the document
rendering process.
I'll try to get in touch with Fedora's asciidoc package maintainers and
have them accept this. If you have any comment let me know.
Sorry if my help is rather hackish but python and distro-grade packaging
is not my fort� but we rely on a modern asciidoc and I would rather
prefer to have it upstream in Fedora than downstream in our repo or from
source.
> 12:25 < plaxx> under what license are the repoforge specs and patches?
> 12:25 <@zaytsev> plaxx: most public domain, some gpl
> 12:26 < plaxx> I've taken a patch from the asciidoc package (which was probably adapted from a fedora one) and integrated it > into an updated asciidoc SPEC that is meant for Fedora.
> 12:27 < plaxx> so I guess this is ok with both licenses?
> 12:29 <@zaytsev> plaxx: yes, i believe so. these patches techincally contain asciidoc source, so they can't be released > under anything but gpl
> 12:30 < plaxx> ok, super! thanks for clarifying
> 12:31 <@zaytsev> plaxx: honestly, no one ever raised concern with regards to specs themselves and hence there is no general > consesus or any official statements with regards to which licenses they are covered by and whether they are > licensable at all. dag used to say though, that specs the he authors he considers to be public domain, so > do i.
> 12:32 <@zaytsev> plaxx: patches are a bit different in that when you make a patch, in forcibly contains source code from the > original application. it is arguable whether it can be considered a derivative work, but i can imagine so, > and therefore for gpl licensed softwre, i would assume that released patches are also under gpl
> 12:33 <@zaytsev> plaxx: otherwise most patches are just one-liners to fix build system hicckups, so makes no sense to use > anything but public domain
We went on a little bit and, of course, he told me he is not a lawyer.
Due to size of the said "borrowed work" and the positive reaction of
someone embodying that community, I think it'll be an acceptable
contribution for Fedora.
I contacted the maintainer. He gave me two other things to do:
- vim plugin should be separately [sub]packaged
- build the git doc with it and it shall still be pretty
I'll get to tasks, eventually, and let you guys know.
On Mon, 7 May 2012, Olivier Bilodeau wrote:
> I contacted the maintainer. He gave me two other things to do:
> - vim plugin should be separately [sub]packaged
> - build the git doc with it and it shall still be pretty
> I'll get to tasks, eventually, and let you guys know.
I'll give you my view of sub-packages on this. I think Fedora is making the mistake to create too many sub-packages and loosing control over what makes packages useful.
I don't see the point in making a separate vim sub-package, given that the vim syntax file is pretty small, a sub-package does not offer anything subtantially, a subpackage increases the chance that someone will not install it and does not know it exists which is bad for the repository and the project (in this case vim and/or asciidoc) and most of all, there is no real downside to shipping the plugin even when vim is not installed.
So my opinion is that these sub-package rules is a form of bureaucratic autism, where any introduced rules are more important than the case at hand and defy common sense.
Of course, there are cases where they can make sense.
>> I contacted the maintainer. He gave me two other things to do:
>> - vim plugin should be separately [sub]packaged
>> - build the git doc with it and it shall still be pretty
>> I'll get to tasks, eventually, and let you guys know.
> I'll give you my view of sub-packages on this. I think Fedora is making
> the mistake to create too many sub-packages and loosing control over
> what makes packages useful.
> I don't see the point in making a separate vim sub-package, given that
> the vim syntax file is pretty small, a sub-package does not offer
> anything subtantially, a subpackage increases the chance that someone
> will not install it and does not know it exists which is bad for the
> repository and the project (in this case vim and/or asciidoc) and most
> of all, there is no real downside to shipping the plugin even when vim
> is not installed.
> So my opinion is that these sub-package rules is a form of bureaucratic
> autism, where any introduced rules are more important than the case at
> hand and defy common sense.
> Of course, there are cases where they can make sense.
I see your point. I'll ask the maintainer.
However I just realized that most vim ftplugin are provided by
vim-commons (it provides 175 of them) and not individually provided by
git, dpkg, mplayer or xfree86 (as a few examples).
On Wed, 9 May 2012, Olivier Bilodeau wrote:
> However I just realized that most vim ftplugin are provided by
> vim-commons (it provides 175 of them) and not individually provided by
> git, dpkg, mplayer or xfree86 (as a few examples).
> So maybe that's the route it should take?
It depends. If it is shipped as part of asciidoc it is easier to maintain/update by Stuart, which may be harder when it ships with vim.
AFAIK all of the syntax-files in vim-common are maintained as part of vim. So the real question is if Stuart is interested in this.
PS This is not a packager's decision IMO. Otherwise it becomes a maintenance nightmare.
