Re: ruby-gettext-setup: FTBFS [Re: RFS: ruby-tzinfo, ruby-gettext, ruby-kgio, ruby-solve]
On 4/4/18, Georg Faerber wrote: >> I've checked ruby-gettext-setup and can say that it doesn't actually >> use anything from gettext gem, only from fast-gettext. So its test >> failures caused by something else, not the new gettext version. > I would be interested in how you came to this conclusion: I did `fgrep -R require | fgrep gettext` and saw nothing (actually this gem uses rxgettext from ruby-gettext). > ruby-gettext-setup FTBFS now, with errors like > > /usr/lib/ruby/vendor_ruby/gettext/tools/parser/ruby.rb:50:in `gsub': invalid > byte sequence in US-ASCII (ArgumentError) > > See #894829 for details. > /usr/lib/ruby/vendor_ruby/gettext/tools/parser/ruby.rb is UTF-8 file, it contains japanese letters (こんにちは世界), of course these letters can't be processed in C locale. So you either patch it to remove UTF-8 characters or run tests in C.UTF-8. I don't think that the last ruby-gettext update introduced a regression as in the previous version it had a terrible insecure parser for ruby strings: begin; s = eval(s); rescue Exception; end Now it has a proper one.
ruby-gettext-setup: FTBFS [Re: RFS: ruby-tzinfo, ruby-gettext, ruby-kgio, ruby-solve]
Hi Hleb, all, On 18-03-21 23:29:33, Hleb Valoshka wrote: > On 3/21/18, Cédric Boutillier wrote: > > Is it "normal" that ruby-gettext-setup tests fail with the new > > ruby-gettext? They seem to pass with the current version on > > ci.debian.net. > > I've checked ruby-gettext-setup and can say that it doesn't actually > use anything from gettext gem, only from fast-gettext. So its test > failures caused by something else, not the new gettext version. I would be interested in how you came to this conclusion: ruby-gettext-setup FTBFS now, with errors like /usr/lib/ruby/vendor_ruby/gettext/tools/parser/ruby.rb:50:in `gsub': invalid byte sequence in US-ASCII (ArgumentError) See #894829 for details. IOW: We should take regressions in autopkgtests seriously. If we don't, chances are high we're just running into situations like this one, causing extra work for all people involved. Cheers, Georg signature.asc Description: Digital signature
Re: RFS: ruby-tzinfo, ruby-gettext, ruby-kgio, ruby-solve
On Fri, Mar 23, 2018 at 07:06:36PM +0300, Hleb Valoshka wrote: > I've implemented your suggestion. Uploaded! signature.asc Description: PGP signature
Re: RFS: ruby-tzinfo, ruby-gettext, ruby-kgio, ruby-solve
On 3/22/18, Cédric Boutillier wrote: > I would rather see this minimal patch to disallow gecode engine in > ruby-solve, and a Breaks: berkshelf (<= current version) > instead of the Conflicts: ruby-dep-selector. > I think it would ease a lot upgrade path if we just prevent ruby-solve > from using ruby-dep-selector instead of preventing coinstalling them. I've implemented your suggestion.
Re: RFS: ruby-tzinfo, ruby-gettext, ruby-kgio, ruby-solve
On 18-03-21 23:34:50, Cédric Boutillier wrote: > On Wed, Mar 21, 2018 at 11:29:33PM +0300, Hleb Valoshka wrote: > > On 3/21/18, Cédric Boutillier wrote: > > > > Is it "normal" that ruby-gettext-setup tests fail with the new > > > ruby-gettext? They seem to pass with the current version on > > > ci.debian.net. > > > I've checked ruby-gettext-setup and can say that it doesn't actually > > use anything from gettext gem, only from fast-gettext. So its test > > failures caused by something else, not the new gettext version. > > Ok. I've just uploaded ruby-gettext. FWIW: I've updated ruby-gettext-setup five days ago to the latest upstream release, it was severely outdated, and especially broke completely puppet, making the later next to unusable. Are you using a current testbed? Cheers, Georg signature.asc Description: Digital signature
Re: RFS: ruby-tzinfo, ruby-gettext, ruby-kgio, ruby-solve
On Wed, Mar 21, 2018 at 11:29:33PM +0300, Hleb Valoshka wrote: > On 3/21/18, Cédric Boutillier wrote: > > Is it "normal" that ruby-gettext-setup tests fail with the new > > ruby-gettext? They seem to pass with the current version on > > ci.debian.net. > I've checked ruby-gettext-setup and can say that it doesn't actually > use anything from gettext gem, only from fast-gettext. So its test > failures caused by something else, not the new gettext version. Ok. I've just uploaded ruby-gettext. > > I was wondering if instead of conflicting with ruby-dep-selector, it was > > possible to deactivate this engine in ruby-solve, just by forbidding the > > use of :gecode key in solver_for_engine method in lib/solve.rb. > I thought about this, maybe patching solve is a better idea, but see > above. The only solve user is berkshelf so it seems better to patch it > instead. I maybe a bit picky here, but I think that Conflicts: is not semantically right in this situation. I would rather see this minimal patch to disallow gecode engine in ruby-solve, and a Breaks: berkshelf (<= current version) instead of the Conflicts: ruby-dep-selector. I think it would ease a lot upgrade path if we just prevent ruby-solve from using ruby-dep-selector instead of preventing coinstalling them. Cheers, Cédric signature.asc Description: PGP signature
Re: RFS: ruby-tzinfo, ruby-gettext, ruby-kgio, ruby-solve
On 3/21/18, Cédric Boutillier wrote: > Is it "normal" that ruby-gettext-setup tests fail with the new > ruby-gettext? They seem to pass with the current version on > ci.debian.net. I've checked ruby-gettext-setup and can say that it doesn't actually use anything from gettext gem, only from fast-gettext. So its test failures caused by something else, not the new gettext version. > For ruby-solve, I couldn't run the tests for berkshelf with the new > ruby-solve in autopkgtest, because it would complain about unsatisfiable > dependencies. Berkshelf by default it uses gecode solver (so it needs to be patched). And Conflicts header in ruby-solve will prevent its upgrade if Berkshelf is installed, because the latter has Depends: ruby-dep-selector. > I was wondering if instead of conflicting with ruby-dep-selector, it was > possible to deactivate this engine in ruby-solve, just by forbidding the > use of :gecode key in solver_for_engine method in lib/solve.rb. I thought about this, maybe patching solve is a better idea, but see above. The only solve user is berkshelf so it seems better to patch it instead.
Re: RFS: ruby-tzinfo, ruby-gettext, ruby-kgio, ruby-solve
ruby-kgio uploaded. signature.asc Description: PGP signature
Re: RFS: ruby-tzinfo, ruby-gettext, ruby-kgio, ruby-solve
hi! I uploaded ruby-tzinfo. I just added the Testsuite: autopkgtest-pkg-ruby in the control file. Is it "normal" that ruby-gettext-setup tests fail with the new ruby-gettext? They seem to pass with the current version on ci.debian.net. For ruby-solve, I couldn't run the tests for berkshelf with the new ruby-solve in autopkgtest, because it would complain about unsatisfiable dependencies. See log below [my lxc autopkg is uptodate]. I was wondering if instead of conflicting with ruby-dep-selector, it was possible to deactivate this engine in ruby-solve, just by forbidding the use of :gecode key in solver_for_engine method in lib/solve.rb. The engine could be reactivated once ruby-dep-selector is fixed. If someone wants to use dep-selector, I understand that s/he has to install it from the gem to get the correct version of libgecode. Then in this case, why not install the solve gem the same way bypassing the package system completely. I think that disabling the engine in ruby-solve with a patch has the same effect as the conflicts instruction, but without putting additional pressure on the package management system to solve dependencies. What do you think? Cédric Reading state information... Done Correcting dependencies...Starting pkgProblemResolver with broken count: 1 Starting 2 pkgProblemResolver with broken count: 1 Investigating (0) ruby-solve:amd64 < none -> 4.0.0-1 @un uN Ib > Broken ruby-solve:amd64 Conflicts on ruby-dep-selector:amd64 < none -> 1.0.3-2+b4 @un uN > (< 1.0.5-1~) Considering ruby-dep-selector:amd64 0 as a solution to ruby-solve:amd64 1 Added ruby-dep-selector:amd64 to the remove list Fixing ruby-solve:amd64 via keep of ruby-dep-selector:amd64 Investigating (0) autopkgtest-satdep:amd64 < 0 @iU mK Nb Ib > Broken autopkgtest-satdep:amd64 Depends on ruby-dep-selector:amd64 < none | 1.0.3-2+b4 @un uH > (>= 1.0) Considering ruby-dep-selector:amd64 0 as a solution to autopkgtest-satdep:amd64 -2 Removing autopkgtest-satdep:amd64 rather than change ruby-dep-selector:amd64 Done Done Starting pkgProblemResolver with broken count: 0 Starting 2 pkgProblemResolver with broken count: 0 Done The following package was automatically installed and is no longer required: libgdbm3 Use 'apt autoremove' to remove it. The following additional packages will be installed: ca-certificates git git-man libcurl3-gnutls liberror-perl libldap-2.4-2 libldap-common libnghttp2-14 libpcre2-8-0 libpsl5 librtmp1 libsasl2-2 libsasl2-modules-db libssh2-1 openssl Suggested packages: gettext-base git-daemon-run | git-daemon-sysvinit git-doc git-el git-email git-gui gitk gitweb git-cvs git-mediawiki git-svn Recommended packages: less publicsuffix libsasl2-modules The following packages will be REMOVED: autopkgtest-satdep The following NEW packages will be installed: ca-certificates git git-man libcurl3-gnutls liberror-perl libldap-2.4-2 libldap-common libnghttp2-14 libpcre2-8-0 libpsl5 librtmp1 libsasl2-2 libsasl2-modules-db libssh2-1 openssl 0 upgraded, 15 newly installed, 1 to remove and 0 not upgraded. 1 not fully installed or removed. Need to get 8,759 kB of archives. After this operation, 40.3 MB of additional disk space will be used. Get:1 http://deb.debian.org/debian sid/main amd64 openssl amd64 1.1.0g-2 [741 kB] Get:2 http://deb.debian.org/debian sid/main amd64 ca-certificates all 20170717 [178 kB] Get:3 http://deb.debian.org/debian sid/main amd64 libsasl2-modules-db amd64 2.1.27~101-g0780600+dfsg-3 [68.2 kB] Get:4 http://deb.debian.org/debian sid/main amd64 libsasl2-2 amd64 2.1.27~101-g0780600+dfsg-3 [105 kB] Get:5 http://deb.debian.org/debian sid/main amd64 libldap-common all 2.4.45+dfsg-1 [87.0 kB] Get:6 http://deb.debian.org/debian sid/main amd64 libldap-2.4-2 amd64 2.4.45+dfsg-1 [223 kB] Get:7 http://deb.debian.org/debian sid/main amd64 libnghttp2-14 amd64 1.31.0-1 [81.4 kB] Get:8 http://deb.debian.org/debian sid/main amd64 libpsl5 amd64 0.19.1-5 [44.9 kB] Get:9 http://deb.debian.org/debian sid/main amd64 librtmp1 amd64 2.4+20151223.gitfa8646d.1-1+b1 [60.4 kB] Get:10 http://deb.debian.org/debian sid/main amd64 libssh2-1 amd64 1.8.0-1 [138 kB] Get:11 http://deb.debian.org/debian sid/main amd64 libcurl3-gnutls amd64 7.58.0-2 [310 kB] Get:12 http://deb.debian.org/debian sid/main amd64 libpcre2-8-0 amd64 10.31-3 [208 kB] Get:13 http://deb.debian.org/debian sid/main amd64 liberror-perl all 0.17025-1 [26.9 kB] Get:14 http://deb.debian.org/debian sid/main amd64 git-man all 1:2.16.2-1 [1,531 kB] Get:15 http://deb.debian.org/debian sid/main amd64 git amd64 1:2.16.2-1 [4,957 kB] Fetched 8,759 kB in 0s (55.8 MB/s) Preconfiguring packages ... (Reading database ... 11922 files and directories currently installed.) Removing autopkgtest-satdep (0) ... Selecting previously unselected package openssl. (Reading database ... 11922 files and directories currently installed.) Preparing to unpack .../00-openssl_1.1.0g-2_amd64.deb ... Unpacking openssl (1.1.0g-2) ... Selectin
Re: RFS: ruby-tzinfo, ruby-gettext, ruby-kgio, ruby-solve
On 3/20/18, Cédric Boutillier wrote: > Could you please update the Standards-Version field and the debhelper > compatibility for these packages, as well as switching the debian/watch > to https? Done. I usually don't change them if lintian doesn't say to. > Can you clarify the situation of ruby-solve with respect to > ruby-dep-selector? The presence of ruby-dep-selector in itself is really > problematic for ruby-solve? Or is it just because ruby-dep-selector is > broken? I understand that it is the latter. > If it is indeed the case, is it not possible to upload an updated, non > broken > ruby-dep-selector before ruby-solve to avoid the extra Conflict: statement? Dep-selector is a one of two available solve backends. Unlike Molinillo based one it's optional. It's currently broken in Sid as it needs libgecode v4 while in Sid we have v5, so there is no lib.so for ruby 2.5. Therefore I just want to prevent broken package installation. I don't think that I can upload fixed dep-selector in reasonable time as it requires good knowledge of both libgecode and C++. My previous attempts to port it failed.
Re: RFS: ruby-tzinfo, ruby-gettext, ruby-kgio, ruby-solve
Hi Hleb, On Sat, Mar 17, 2018 at 04:17:19PM +0300, Hleb Valoshka wrote: > * just a new minor version + vcs-* updated: >- ruby-tzinfo >- ruby-gettext >- ruby-kgio > * a new major version + d/control changes to prevent broken > ruby-dep-selector installation >- ruby-solve Could you please update the Standards-Version field and the debhelper compatibility for these packages, as well as switching the debian/watch to https? Can you clarify the situation of ruby-solve with respect to ruby-dep-selector? The presence of ruby-dep-selector in itself is really problematic for ruby-solve? Or is it just because ruby-dep-selector is broken? I understand that it is the latter. If it is indeed the case, is it not possible to upload an updated, non broken ruby-dep-selector before ruby-solve to avoid the extra Conflict: statement? Cheers, Cédric signature.asc Description: PGP signature
