Open pghmcfc opened 8 years ago
I agree this would make sense
I'm not sure. The bundled version has a few small fixes, and I think the process of getting them merged and distributed is a rathole that I'd rather not go down.
Debian seems to think it's a doc and license file fix.
Suggestions?
I'm not sure. The bundled version has a few small fixes, and I think the process of getting them merged and distributed is a rathole that I'd rather not go down.
Why would it be a rathole?
Debian seems to think it's a doc and license file fix.
I think that was an additional issue that is now resolved.
Correct, the license documentation issue was https://bugs.debian.org/664196 which is fixed. https://bugs.debian.org/664224 was cloned from that one to track the embedded library issue itself. And yes, we still would like to be able to build against the system libyaml. Currently we are violating a "should" in Debian Policy 4.13: https://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles
Incidentally, did anyone notice the (unauthorized) release of YAML-LibYAML 0.71 by RURBAN?
https://metacpan.org/release/RURBAN/YAML-LibYAML-0.71 https://github.com/rurban/yaml-libyaml-pm
What's happening there?
@pghmcfc why not ask him? Did he ever submit a PR with requested fixes?
fwiw, I've been given maintenance bits for libyaml from the author. ie A python guy and I are the new maintainers. So now we can revisit this with some sanity. @pghmcfc @Leont @gregoa @karenetheridge advice welcome.
@pghmcfc I had not seen @rurban's release. @rurban what are you doing there?
On Sep 13, 2016, at 1:19 AM, Ingy döt Net notifications@github.com wrote:
fwiw, I've been given maintenance bits for libyaml from the author. ie A python guy and I are the new maintainers. So now we can revisit this with some sanity. @pghmcfc @Leont @gregoa @karenetheridge advice welcome.
@pghmcfc I had not seen @rurban's release. @rurban what are you doing there?
I published the state I used for cperl, even without perms and even if I forgot to include the Test::Base dependency. Deal with it.
Waiting a year is too long, i have release deadlines.
fwiw, I've been given maintenance bits for libyaml from the author. ie A python guy and I are the new maintainers. So now we can revisit this with some sanity. @pghmcfc @Leont @gregoa @karenetheridge advice welcome.
This is good news. Things I'd look at would include:
@pghmcfc Thanks for the thoughtful comments. I've already made PRs for all the diffs between YAML::XS's master and libyaml, and some of them are even merged now. I'm not 100% sure if I got everything. Could you maybe take a look and see if the PRs are representative (ir I can look later this weekend).
I fixed yesterday the intermediate YAML::XS/libyaml work for utf8 and option problems. I had several problems. It's on my github now as 0.74.
What's still todo is safety. Either as in python with SafeLoad/SafeLoadFile, or as in YAML::Syck with global variables: local ($YAML::Syck::LoadCode, $YAML::Syck::UseCode, $YAML::Syck::LoadBlessed);
.
cperl's Parse::CPAN::Meta can now use YAML::XS, YAML::Syck and it's own CPAN::Meta::YAML to parse META.yml
, while ignoring the YAML::XS problem of embedded code and classes.
cpan ditto.
https://github.com/rurban/libyaml/tree/perl-yaml-xs is not mergable as of now, I'll see what happened. https://github.com/rurban/yaml-libyaml-pm needs a tiny rebase for Tina's uploads.
@rurban yeah, I'd also like to see SafeLoad
Hi,
is there any prospect of being able to unbundle libyaml and build against a system-wide version at some point? It would certainly be appreciated downstream:
Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=664224 Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1081559 Gentoo: https://bugs.gentoo.org/show_bug.cgi?id=410653