Processed: found 992046 in 0.12.1-1
Processing commands for cont...@bugs.debian.org: > found 992046 0.12.1-1 Bug #992046 [src:rust-anymap] rust-anymap: CVE-2021-38187 Marked as found in versions rust-anymap/0.12.1-1. > thanks Stopping processing here. Please contact me if you need assistance. -- 992046: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992046 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: tagging 992046, tagging 992045 ..., tagging 992047
Processing commands for cont...@bugs.debian.org: > tags 992046 + upstream Bug #992046 [src:rust-anymap] rust-anymap: CVE-2021-38187 Added tag(s) upstream. > tags 992045 + upstream Bug #992045 [cpio] CVE-2021-38185 Added tag(s) upstream. > forwarded 992045 > https://lists.gnu.org/archive/html/bug-cpio/2021-08/msg0.html Bug #992045 [cpio] CVE-2021-38185 Set Bug forwarded-to-address to 'https://lists.gnu.org/archive/html/bug-cpio/2021-08/msg0.html'. > tags 992047 + upstream Bug #992047 [src:rust-generator] rust-generator: CVE-2020-36471 Added tag(s) upstream. > thanks Stopping processing here. Please contact me if you need assistance. -- 992045: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992045 992046: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992046 992047: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992047 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#991971: [pkg-lynx-maint] Bug#991971: [CVE-2021-38165] lynx: bug in SSL certificate validation -> leaks password in clear text via SNI (under some circumstances)
Hi, Axel Beckert wrote: > I can also look into how well the patch applies to buster's version of > Lynx, but it might take until Monday. Done now, built with -sa, did a source-only uploaded to security-master and pushed it into the branch 10_buster on Salsa including the according git tag. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE signature.asc Description: PGP signature
Bug#992046: rust-anymap: CVE-2021-38187
Source: rust-anymap X-Debbugs-CC: t...@security.debian.org Severity: grave Tags: security Hi, The following vulnerability was published for rust-anymap. CVE-2021-38187[0]: | An issue was discovered in the anymap crate through 0.12.1 for Rust. | It violates soundness via conversion of a *u8 to a *u64. https://rustsec.org/advisories/RUSTSEC-2021-0065.html If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2021-38187 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-38187 Please adjust the affected versions in the BTS as needed.
Bug#991971: marked as done (lynx: [CVE-2021-38165] SSL certificate validation fails with URLs containing user name or user name and password, i.e. https://user:password@host/ and https://user@host/\;
Your message dated Mon, 09 Aug 2021 21:18:51 + with message-id and subject line Bug#991971: fixed in lynx 2.9.0dev.6-3~deb11u1 has caused the Debian Bug report #991971, regarding lynx: [CVE-2021-38165] SSL certificate validation fails with URLs containing user name or user name and password, i.e. https://user:password@host/ and https://user@host/\; leaks password in clear text via SNI to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 991971: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991971 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: lynx Version: 2.9.0dev.8-1 Severity: important Tags: upstream, confirmed Control: forwarded -1 https://lists.nongnu.org/archive/html/lynx-dev/2021-08/msg0.html Control: found -1 2.8.9dev1-2+deb8u1 Control: found -1 2.8.9dev11-1 Control: found -1 2.8.9rel.1-3 Control: found -1 2.9.0dev.6-2 Thorsten Glaser reported the following on the upstream dev mailing list at https://lists.nongnu.org/archive/html/lynx-dev/2021-08/msg0.html (citing the parts that affect Debian, i.e. those when compiled against GnuTLS and not OpenSSL): > this affects both OpenSSL and Debian’s nonGNUtls builds: > > lynx https://user:pass@host/ > > … will lead to… […] > SSL error:host(user:pass@host)!=cert(CN)-Continue? (n) > > … for nonGNUtls lynx. > > Obviously, user:pass@ need to be stripped before comparing. The > nonGNUtls version could also be changed to display the > subjectAltName''s the certificate has like the OpenSSL one does (after > my patch from ages ago; […] https://user@host/ is affected as well. I was able to reproduce this issue in Lynx in all currently (in some way) supported releases of Debian back to Debian 8 Jessie with ELTS support and also in the most recent version in Debian Experimental. P.S. to Thorsten: Feel free to set yourself as submitter of this bug report. ☺ -- System Information: Debian Release: 11.0 APT prefers unstable APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), (500, 'testing-security'), (500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 'buildd-experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages lynx depends on: ii libbsd0 0.11.3-1 ii libbz2-1.01.0.8-4 ii libc6 2.31-13 ii libgnutls30 3.7.1-5 ii libidn2-0 2.3.0-5 ii libncursesw6 6.2+20201114-2 ii libtinfo6 6.2+20201114-2 ii lynx-common 2.9.0dev.6-2 ii zlib1g1:1.2.11.dfsg-2 Versions of packages lynx recommends: ii mime-support 3.66 lynx suggests no packages. -- no debconf information --- End Message --- --- Begin Message --- Source: lynx Source-Version: 2.9.0dev.6-3~deb11u1 Done: Andreas Metzler We believe that the bug you reported is fixed in the latest version of lynx, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 991...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Andreas Metzler (supplier of updated lynx package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 08 Aug 2021 13:36:32 +0200 Source: lynx Architecture: source Version: 2.9.0dev.6-3~deb11u1 Distribution: bullseye-security Urgency: high Maintainer: Debian Lynx Packaging Team Changed-By: Andreas Metzler Closes: 991971 Changes: lynx (2.9.0dev.6-3~deb11u1) bullseye-security; urgency=high . * Rebuild for bullseye-security. . lynx (2.9.0dev.6-3) unstable; urgency=high . * Apply fix from Lynx 2.9.0dev.9 for CVE-2021-38165 to fix leakage of username and password in the TLS 1.2 SNI Extension if username and password were given in the URL, i.e. as https://user:p...@example.org/ (Closes: #991971) Checksums-Sha1: d5ba3abe6c59ef3dc85557c37de7798222642cc3 2560 lynx_2.9.0dev.6-3~deb11u1.dsc bc62d8915a0083c2fe4fa0dc5cf48fd9f83fd9b2 2730690 lynx_2.9.0dev.6.orig.tar.bz2 0517d1a5630ed147597fd350c68c4689ec2c12d2 265
Bug#992045: CVE-2021-38185
Package: cpio Version: 2.13+dfsg-4 Severity: grave Tags: security X-Debbugs-Cc: Debian Security Team https://github.com/fangqyi/cpiopwn https://git.savannah.gnu.org/cgit/cpio.git/commit/?id=dd96882877721703e19272fe25034560b794061b https://lists.gnu.org/archive/html/bug-cpio/2021-08/msg0.html https://lists.gnu.org/archive/html/bug-cpio/2021-08/msg2.html Cheers, Moritz
Bug#991046: marked as done (tomcat9: CVE-2021-33037 CVE-2021-30640 CVE-2021-30639)
Your message dated Mon, 09 Aug 2021 21:19:52 + with message-id and subject line Bug#991046: fixed in tomcat9 9.0.43-2~deb11u1 has caused the Debian Bug report #991046, regarding tomcat9: CVE-2021-33037 CVE-2021-30640 CVE-2021-30639 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 991046: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991046 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: tomcat9 X-Debbugs-CC: t...@security.debian.org Severity: grave Tags: security Hi, The following vulnerabilities were published for tomcat9. Commit references below, although it's worth considering to simply update to 9.0.47, given that stable-security upgraded to new Tomcat point releases before. CVE-2021-33037[0]: | Apache Tomcat 10.0.0-M1 to 10.0.6, 9.0.0.M1 to 9.0.46 and 8.5.0 to | 8.5.66 did not correctly parse the HTTP transfer-encoding request | header in some circumstances leading to the possibility to request | smuggling when used with a reverse proxy. Specifically: - Tomcat | incorrectly ignored the transfer encoding header if the client | declared it would only accept an HTTP/1.0 response; - Tomcat honoured | the identify encoding; and - Tomcat did not ensure that, if present, | the chunked encoding was the final encoding. https://github.com/apache/tomcat/commit/45d70a86a901cbd534f8f570bed2aec9f7f7b88e (9.0.47) https://github.com/apache/tomcat/commit/05f9e8b00f5d9251fcd3c95dcfd6cf84177f46c8 (9.0.47) https://github.com/apache/tomcat/commit/a2c3dc4c96168743ac0bab613709a5bbdaec41d0 (9.0.47) CVE-2021-30640[1]: | A vulnerability in the JNDI Realm of Apache Tomcat allows an attacker | to authenticate using variations of a valid user name and/or to bypass | some of the protection provided by the LockOut Realm. This issue | affects Apache Tomcat 10.0.0-M1 to 10.0.5; 9.0.0.M1 to 9.0.45; 8.5.0 | to 8.5.65. https://bz.apache.org/bugzilla/show_bug.cgi?id=65224 https://github.com/apache/tomcat/commit/c4df8d44a959a937d507d15e5b1ca35c3dbc41eb (9.0.46) https://github.com/apache/tomcat/commit/749f3cc192c68c34f2375509aea087be45fc4434 (9.0.46) https://github.com/apache/tomcat/commit/c6b6e1015ae44c936971b6bf8bce70987935b92e (9.0.46) https://github.com/apache/tomcat/commit/91ecdc61ce3420054c04114baaaf1c1e0cbd5d56 (9.0.46) https://github.com/apache/tomcat/commit/e50067486cf86564175ca0cfdcbf7d209c6df862 (9.0.46) https://github.com/apache/tomcat/commit/b5585a9e5d4fec020cc5ebadb82f899fae22bc43 (9.0.46) https://github.com/apache/tomcat/commit/329932012d3a9b95fde0b18618416e659ecffdc0 (9.0.46) https://github.com/apache/tomcat/commit/3ce84512ed8783577d9945df28da5a033465b945 (9.0.46) CVE-2021-30639[2]: | A vulnerability in Apache Tomcat allows an attacker to remotely | trigger a denial of service. An error introduced as part of a change | to improve error handling during non-blocking I/O meant that the error | flag associated with the Request object was not reset between | requests. This meant that once a non-blocking I/O error occurred, all | future requests handled by that request object would fail. Users were | able to trigger non-blocking I/O errors, e.g. by dropping a | connection, thereby creating the possibility of triggering a DoS. | Applications that do not use non-blocking I/O are not exposed to this | vulnerability. This issue affects Apache Tomcat 10.0.3 to 10.0.4; | 9.0.44; 8.5.64. https://bz.apache.org/bugzilla/show_bug.cgi?id=65203 https://github.com/apache/tomcat/commit/8ece47c4a9fb9349e8862c84358a4dd23c643a24 (9.0.45) If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2021-33037 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-33037 [1] https://security-tracker.debian.org/tracker/CVE-2021-30640 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-30640 [2] https://security-tracker.debian.org/tracker/CVE-2021-30639 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-30639 Please adjust the affected versions in the BTS as needed. --- End Message --- --- Begin Message --- Source: tomcat9 Source-Version: 9.0.43-2~deb11u1 Done: Markus Koschany We believe that the bug you reported is fixed in the latest version of tomcat9, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them
Bug#992008: ruby-google-protobuf: Missing lib/google/protobuf directory and fails require
Control: tags -1 patch On Mon, 09 Aug 2021 01:35:43 +0530 Pirate Praveen wrote: > Adding, > ruby/lib/google usr/lib/ruby/vendor_ruby > to debian/ruby-google-protobuf.install makes require 'google/protobuf' > to pass. This can be used as a workaround until we figure out why > gem2deb is not installing these files even though gemspec includes them > in files. Hi Laszlo, Can you upload this change? Or if you are okay with this change, I can upload it as well. Once this is fixed, I can switch back to the packaged version (currently using gem install google-protobuf as work around). I had seen this bug earlier https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989774 but I thought it was something similar/related to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966653 (between, this bug also seems to be fixed with newer protobuf/grpc versions in experimental). diff -Nru protobuf-3.17.3/debian/changelog protobuf-3.17.3/debian/changelog --- protobuf-3.17.3/debian/changelog 2021-06-23 21:06:44.0 +0530 +++ protobuf-3.17.3/debian/changelog 2021-08-09 21:32:33.0 +0530 @@ -1,3 +1,10 @@ +protobuf (3.17.3-1.1) experimental; urgency=medium + + * Non-maintainer upload. + * Include ruby/lib in ruby-google-protobuf binary (Closes: #992008) + + -- Pirate Praveen Mon, 09 Aug 2021 21:32:33 +0530 + protobuf (3.17.3-1) experimental; urgency=medium * New upstream release. diff -Nru protobuf-3.17.3/debian/ruby-google-protobuf.install protobuf-3.17.3/debian/ruby-google-protobuf.install --- protobuf-3.17.3/debian/ruby-google-protobuf.install 1970-01-01 05:30:00.0 +0530 +++ protobuf-3.17.3/debian/ruby-google-protobuf.install 2021-08-09 21:30:39.0 +0530 @@ -0,0 +1 @@ +ruby/lib/google usr/lib/ruby/vendor_ruby
Processed: Re: ruby-google-protobuf: Missing lib/google/protobuf directory and fails require
Processing control commands: > tags -1 patch Bug #992008 [ruby-google-protobuf] ruby-google-protobuf: Missing lib/google/protobuf directory and fails require Added tag(s) patch. -- 992008: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992008 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#992040: marked as done (gitlab 2FA broken: NoMethodError (undefined method `module_count' for #)
Your message dated Mon, 09 Aug 2021 18:03:35 + with message-id and subject line Bug#992040: fixed in ruby-rqrcode-rails3 0.1.7-2 has caused the Debian Bug report #992040, regarding gitlab 2FA broken: NoMethodError (undefined method `module_count' for # to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 992040: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992040 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: gitlab Version: 13.12.9+ds1-1 Severity: important When trying to enable two factor authentication, gitlab shows a 500 error and production.log has this error. Started GET "/-/profile/two_factor_auth" for 192.168.122.1 at 2021-08-09 16:19:49 + Processing by Profiles::TwoFactorAuthsController#show as HTML Completed 500 Internal Server Error in 349ms (ActiveRecord: 11.8ms | Elasticsearch: 0.0ms | Allocations: 84358) NoMethodError (undefined method `module_count' for # Did you mean? modules): app/controllers/profiles/two_factor_auths_controller.rb:134:in `build_qr_code' app/controllers/profiles/two_factor_auths_controller.rb:39:in `show' app/controllers/application_controller.rb:490:in `set_current_admin' lib/gitlab/session.rb:11:in `with_session' app/controllers/application_controller.rb:481:in `set_session_storage' lib/gitlab/i18n.rb:99:in `with_locale' lib/gitlab/i18n.rb:105:in `with_user_locale' app/controllers/application_controller.rb:475:in `set_locale' app/controllers/application_controller.rb:468:in `block in set_current_context' lib/gitlab/application_context.rb:70:in `block in use' lib/gitlab/application_context.rb:70:in `use' lib/gitlab/application_context.rb:27:in `with_context' app/controllers/application_controller.rb:459:in `set_current_context' lib/gitlab/middleware/speedscope.rb:13:in `call' lib/gitlab/request_profiler/middleware.rb:17:in `call' lib/gitlab/jira/middleware.rb:19:in `call' lib/gitlab/middleware/go.rb:20:in `call' lib/gitlab/etag_caching/middleware.rb:21:in `call' lib/gitlab/middleware/multipart.rb:172:in `call' lib/gitlab/middleware/read_only/controller.rb:50:in `call' lib/gitlab/middleware/read_only.rb:18:in `call' lib/gitlab/middleware/same_site_cookies.rb:27:in `call' lib/gitlab/middleware/handle_malformed_strings.rb:21:in `call' lib/gitlab/middleware/basic_health_check.rb:25:in `call' lib/gitlab/middleware/handle_ip_spoof_attack_error.rb:25:in `call' lib/gitlab/middleware/request_context.rb:21:in `call' config/initializers/fix_local_cache_middleware.rb:11:in `call' lib/gitlab/middleware/rack_multipart_tempfile_factory.rb:19:in `call' lib/gitlab/metrics/requests_rack_middleware.rb:76:in `call' lib/gitlab/middleware/release_env.rb:12:in `call' Started GET "/favicon.ico" for 192.168.122.1 at 2021-08-09 16:19:49 + --- End Message --- --- Begin Message --- Source: ruby-rqrcode-rails3 Source-Version: 0.1.7-2 Done: Pirate Praveen We believe that the bug you reported is fixed in the latest version of ruby-rqrcode-rails3, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 992...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Pirate Praveen (supplier of updated ruby-rqrcode-rails3 package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 09 Aug 2021 23:17:47 +0530 Source: ruby-rqrcode-rails3 Architecture: source Version: 0.1.7-2 Distribution: unstable Urgency: medium Maintainer: Debian Ruby Team Changed-By: Pirate Praveen Closes: 992040 Changes: ruby-rqrcode-rails3 (0.1.7-2) unstable; urgency=medium . * Team upload . [ Cédric Boutillier ] * Bump debhelper compatibility level to 9 * Use https:// in Vcs-* fields * Bump Standards-Version to 3.9.7 (no changes needed) . [ Utkarsh Gupta ] * Add salsa-ci.yml . [ Debian Janitor ] * Use secure copyright file specification URI. * Use secure URI in Homepage field. * Set upstream metadata fields: Bug-Database, Bug-Submit. * Update Vcs-* headers from URL redirect. * Use canonical URL in Vcs-Git. . [ Pirate Praveen ] * Fix for ruby-rqrcode 1.0 compatibility (Thanks to Florence Foo) (Closes: #992040) * Bump Standards-Version to
Processed: severity of 992040 is grave
Processing commands for cont...@bugs.debian.org: > severity 992040 grave Bug #992040 [ruby-rqrcode-rails3] gitlab 2FA broken: NoMethodError (undefined method `module_count' for # Severity set to 'grave' from 'important' > thanks Stopping processing here. Please contact me if you need assistance. -- 992040: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992040 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#992008: ruby-google-protobuf: Missing lib/google/protobuf directory and fails require
On Mon, Aug 9, 2021 at 1:50 pm, Antonio Terceiro wrote: On Mon, Aug 09, 2021 at 01:35:43AM +0530, Pirate Praveen wrote: On Mon, Aug 9, 2021 at 12:12 am, Pirate Praveen wrote: > [copying debian-ruby list] > > On Sun, 08 Aug 2021 22:08:39 +0530 Akshay S Dinesh > wrote: > > Package: ruby-google-protobuf > > Version: 3.17.3-1 > > Severity: grave > > Justification: renders package unusable > > > > Dear Maintainer, > > > > I was trying to install gitlab to reproduce #966653 > > > > Installed ruby-google-protobuf from experimental > > > > The pg_query library was erroring at startup, > > with failure to require 'google/protobuf' > > > > I tried to isolate it to debian by `gem install google-protobuf` > > > > It worked correctly with that. > > > > On comparing stable version > > http://ftp.debian.org/debian/pool/main/p/protobuf/ruby-google-protobuf_3.12.4-1_amd64.deb > > with the experimental version > > http://ftp.debian.org/debian/pool/main/p/protobuf/ruby-google-protobuf_3.17.3-1_amd64.deb > > > > I could see that the latter lacks the > /2.7.0/gems/lib/google/protobuf directory altogether > > > > The upstream gem at > https://rubygems.org/downloads/google-protobuf-3.17.3.gem includes > > this lib directory with lots of ruby files > > > > I'm suspecting that this folder is critical to the functioning of this > package > > > > I think this is a problem with gem2deb not including the pure ruby files > along with the extention. I think we have seen such issues before, but > don't remember how we fixed it. > > Another possibility is that the rules is calling ruby build only in > override_dh_auto_build-arch. Adding, ruby/lib/google usr/lib/ruby/vendor_ruby to debian/ruby-google-protobuf.install makes require 'google/protobuf' to pass. This can be used as a workaround until we figure out why gem2deb is not installing these files even though gemspec includes them in files. protobuf is nothing like an usual Ruby package. The top of debian/rules has this: export DH_RUBY = --gem-install export DH_RUBY_USE_DH_AUTO_INSTALL_DESTDIR = debian/ruby-google-protobuf export GEM2DEB_TEST_RUNNER = --check-dependencies But this is completely misleading, since the part that seems to actually do the Ruby build does not use gem2deb at all, and looks like this: ifeq (,$(filter noruby,$(DEB_BUILD_PROFILES))) # Ruby build cd ruby && rake package genproto endif So this has definitively nothing to do with gem2deb. Well, I tried with dh_auto_build -O--buildsystem=ruby -O--package=ruby-google-protobuf after this rake command without any change Also it has the following lines below it and dh_auto_install -O--buildsystem=ruby -O--package=ruby-google-protobuf --destdir=$(CURDIR)/debian/ruby-google-protobuf and you can see in the build logs at https://buildd.debian.org/status/fetch.php?pkg=protobuf=amd64=3.17.3-1=1624466935=0 this looks to me pretty much gem2deb's doing. dh_auto_install -O--buildsystem=ruby -O--package=ruby-google-protobuf --destdir=/<>/debian/ruby-google-protobuf dh_ruby --install /<>/debian/ruby-google-protobuf dh_ruby --install /usr/bin/ruby2.7 -S gem build --config-file /dev/null --verbose /tmp/d20210623-865026-7jt4fj/gemspec Failed to load /dev/null because it doesn't contain valid YAML hash Successfully built RubyGem Name: google-protobuf Version: 3.17.3 File: google-protobuf-3.17.3.gem /usr/bin/ruby2.7 -S gem install --config-file /dev/null --verbose --local --verbose --no-document --ignore-dependencies --install-dir /<>/debian/ruby-google-protobuf/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0 /tmp/d20210623-865026-7jt4fj/google-protobuf-3.17.3.gem Failed to load /dev/null because it doesn't contain valid YAML hash /<>/debian/ruby-google-protobuf/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0/gems/google-protobuf-3.17.3/ruby/ext/google/protobuf_c/convert.c /<>/debian/ruby-google-protobuf/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0/gems/google-protobuf-3.17.3/ruby/ext/google/protobuf_c/convert.h /<>/debian/ruby-google-protobuf/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0/gems/google-protobuf-3.17.3/ruby/ext/google/protobuf_c/defs.c /<>/debian/ruby-google-protobuf/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0/gems/google-protobuf-3.17.3/ruby/ext/google/protobuf_c/defs.h /<>/debian/ruby-google-protobuf/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0/gems/google-protobuf-3.17.3/ruby/ext/google/protobuf_c/extconf.rb /<>/debian/ruby-google-protobuf/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0/gems/google-protobuf-3.17.3/ruby/ext/google/protobuf_c/map.c /<>/debian/ruby-google-protobuf/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0/gems/google-protobuf-3.17.3/ruby/ext/google/protobuf_c/map.h
Bug#991982: nano does not work with TERM unset
Le dimanche 8 août 2021, 10:04:30 UTC Benno Schulenberg a écrit : > > $env -i nano > > command fail because TERM is unset > > I can work around an unset TERM. But what if TERM=="" or TERM=="nonsense"? > Checking whether TERM is a valid terminal name goes too far, in my opinion. > > Also, is the 'vt100' terminal description guaranteed to exist? I ask, > because 'dumb' and 'vt52' are not good enough for nano (ncurses) to work > properly, and 'ansi' leaves the cursor invisible on a VTE-based terminal. nano work with TERM=dumb (but is strange but it work), so safer will be to consider as best effort TERM="" , TERM not set, equivalent to dumb. At least it fix this bug. Bastien > > Benno signature.asc Description: This is a digitally signed message part.
Bug#991982: nano does not work with TERM unset
Le dimanche 8 août 2021, 14:57:42 UTC Bastien Roucariès a écrit : > Le dimanche 8 août 2021, 10:04:30 UTC Benno Schulenberg a écrit : > > > $env -i nano > > > command fail because TERM is unset > > > > I can work around an unset TERM. But what if TERM=="" or > > TERM=="nonsense"? > > Checking whether TERM is a valid terminal name goes too far, in my > > opinion. > > > > Also, is the 'vt100' terminal description guaranteed to exist? I ask, > > because 'dumb' and 'vt52' are not good enough for nano (ncurses) to work > > properly, and 'ansi' leaves the cursor invisible on a VTE-based terminal. > > I do not know but I think the only sensible way to behave is like vi under > POSIX (https://pubs.opengroup.org/onlinepubs/9699919799/utilities/ex.html): > TERM > Determine the name of the terminal type. If this variable is unset or > null, an unspecified default terminal type shall be used. > > The other way are broken. I should add if term is not supported failling with exit code 126 will help. > > > Benno signature.asc Description: This is a digitally signed message part.
