Your package rubygem-sanitize failed to build from source in current rawhide. http://koji.fedoraproject.org/koji/taskinfo?taskID=12867407 For details on mass rebuild see https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild
Created attachment 1126304 [details] build.log
Created attachment 1126305 [details] root.log
Created attachment 1126306 [details] state.log
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle. Changing version to '24'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase
Let me check this!
Created attachment 1149855 [details] A script to check nokogiri behavior I am still trying to fix this test suite issue. But I would like to share a information which I found. I looks useful. After checking below build.log files at koschei [1], and checking the source code, I found the difference of the behavior for the ruby environments. At fedora-rawhide-x86_64 mock environment, I did run the test for both system ruby (rubypick-1.1.1-5.fc24.noarch) (= describe ruby [a]), and the ruby that was installed from source code (= describe ruby [b]). system ruby [a]: failure the test. source compiled ruby [b]: success the test. The difference of the result is the difference for result of running the attached script. See following result. *GCC version* # gcc --version gcc (GCC) 6.0.0 20160406 (Red Hat 6.0.0-0.20) *ruby [a]* # /usr/bin/ruby -v ruby 2.3.0p0 (2015-12-25 revision 53290) [x86_64-linux] # rpm -qf /usr/bin/ruby rubypick-1.1.1-5.fc24.noarch # /usr/bin/gem list *** LOCAL GEMS *** bigdecimal (1.2.8) did_you_mean (1.0.0) io-console (0.4.5) json (1.8.3) minitest (4.7.0) nokogiri (1.6.7.2) psych (2.0.17) rdoc (4.2.1) # /usr/bin/ruby test_nokogiri.rb 1.6.7.2 <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd"> <html><body><<a>b</a> </body></html> false => false means with test failure. *ruby [b]* how to install the ruby [b] -> [2] # /usr/local/ruby-2.3.0/bin/ruby -v ruby 2.3.0p0 (2015-12-25 revision 53290) [x86_64-linux] # /usr/local/ruby-2.3.0/bin/gem list *** LOCAL GEMS *** bigdecimal (1.2.8) did_you_mean (1.0.0) io-console (0.4.5) json (1.8.3) mini_portile2 (2.0.0) minitest (5.8.3) net-telnet (0.1.1) nokogiri (1.6.7.2) power_assert (0.2.6) psych (2.0.17) rake (10.4.2) rdoc (4.2.1) test-unit (3.1.5) # /usr/local/ruby-2.3.0/bin/ruby test_nokogiri.rb 1.6.7.2 <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd"> <html><body>b</body></html> true => true means with test success. [1] https://apps.fedoraproject.org/koschei/package/rubygem-sanitize [2] *Get source to install these things with off-line in mock environment. - https://cache.ruby-lang.org/pub/ruby/2.3/ruby-2.3.0.tar.gz - gem fetch mini_portile2 -v 2.0.0 - gem fetch nokogiri -v 1.6.7 *Install package to run the test script. mock -r fedora-rawhide-x86_64 -i zlib-devel => zlib-devel-1.2.8-10.fc24.x86_64 mock -r fedora-rawhide-x86_64 -i openssl-devel => openssl-devel-1.0.2g-4.fc25.x86_64 *Install Ruby from source in the mock environment. tar xzvf ruby-2.3.0.tar.gz ./configure --prefix=/usr/local/ruby-2.3.0 make make install *Install gem packages in the mock environment. /usr/local/ruby-2.3.0/bin/gem install --local mini_portile2-2.0.0.gem /usr/local/ruby-2.3.0/bin/gem install --local nokogiri-1.6.7.2.gem
Well, this is reoccurring issue. I think we changed this escaping back and forward several times already. You should check what libxml2 is in use for each of your scenarios, since nokogiri bundles libxml2 as far as I know, so the "gem install" version is very likely using different version of libxml2 then the rubygem-nokogiri.
Hi, Vit Thanks for your message. After checking my environment, I found that it was the difference of libxml2 version. *ruby [a] / system ruby -> rubygem-nokogiri-1.6.7.2-1 -> system libxml2 v2.9.3 -> rubygem-sanitize test failure *ruby [b] / the ruby installed from source by myself. -> nokogiri 1.6.7.2 -> bundled libxml2 v2.9.2 -> rubygem-sanitize test success About ruby [b], after updating libxml2 to nokogiri-1.6.8.rc3 (using bundled libxml2 v2.9.3), the test was failed. That became same with ruby [a]. So, now everything is clear for me. I will update rubygem-sanitize test suite to pass for libxml2 v2.9.3. Thanks.
Firstly I will check rubygem-nokogiri package.
(In reply to Jun Aruga from comment #9) > Firstly I will check rubygem-nokogiri package. I checked rubygem-sanitize test suite with rubygem-nokogiri 1.6.8.rc3 that I created by myself for test. [1] But the test suite was failed in the mock environment, though I expected that nokogiri 1.6.8.rc3 fixed the difference of libxml2 v2.9.2 and v2.9.3. # /usr/bin/gem list *** LOCAL GEMS *** bigdecimal (1.2.8) did_you_mean (1.0.0) io-console (0.4.5) json (1.8.3) minitest (4.7.0) nokogiri (1.6.8.rc3) pkg-config (1.1.7) psych (2.0.17) rdoc (4.2.1) # ruby -Ilib -e 'Dir.glob "./test/test_*.rb", &method(:require)' ... 142 tests, 194 assertions, 5 failures, 0 errors, 0 skips # ruby test_nokogiri.rb 1.6.8.rc3 <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd"> <html><body><<a>b</a> </body></html> false [1] Install rubygem-nokogiri 1.6.8.rc3 rpm package to mock environment. After creating rubygem-nokogiri-1.6.8-0.1.rc3.fc25.x86_64.rpm package by myself. mock -r fedora-rawhide-x86_64 -i rubygem-pkg-config mock -r fedora-rawhide-x86_64 -i nokogiri_work/rubygem-nokogiri-1.6.8-0.1.rc3.fc25.x86_64.rpm
Hi, I think it is a similar problem to I have had with rails-html-sanitizer[1]. It did not get resolved though. It is some difference between libxml2 v2.9.2 and v2.9.3, which causes the failures. I think this would be best addressed upstream. [1] https://github.com/rails/rails-html-sanitizer/issues/49
Hi, Pavel. Thanks for the information!
I am also asking to upstream: "nokogiri", that is used by "sanitize"[1]. [1] https://github.com/sparklemotion/nokogiri/issues/1465
(In reply to Jun Aruga from comment #13) > I am also asking to upstream: "nokogiri", that is used by "sanitize"[1]. > > [1] https://github.com/sparklemotion/nokogiri/issues/1465 Today I got the response from the owner of nokogiri. https://github.com/sparklemotion/nokogiri/issues/1465 > Because Nokogiri on MRI relies on libxml to do markup correction, I absolutely > believe that the version of libxml affects this behavior. > > Further, there is no standard way to correct broken or invalid markup, and so > this cannot be classified as a bug, since the behavior of parsers is undefined. > > Finally, this correction behavior is entirely internal within libxml, and so the Nokogiri code cannot reasonably "fix" the output to be consistent across libxml versions (though we have on occasion tried). So, I am planning 2 ways as my next steps. 1. Try to ask the owner of libxml about this situation, what is the reason for the changing. 2. I will try to update the sanitize version to latest one with 2 new rubygem packages: rubygem-crass", "rubygem-nokogumbo" that we need to create, in my local environment.
This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '24'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 24 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.