Bug#1027407: ruby-rubygems: kernel_require.rb LoadError breaks dhelp
Control: tag -1 + pending On Fri, Dec 30, 2022 at 08:08:50PM -0300, Antonio Terceiro wrote: > Control: reassign -1 dhelp > Control: severity -1 serious > Control: retitle: dhelp: depends on module removed from the Ruby stdlib (dbm) > > On Fri, Dec 30, 2022 at 06:09:03PM +0100, Drew Parsons wrote: > > Package: ruby-rubygems > > Version: 3.3.15-1 > > Severity: important > > > > /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb from > > ruby-rubygems causes a LoadError which prevents dhelp from updating > > succcessfully (when packages register a doc-base entry). > > > > This affects all other packages (unrelated to ruby) registering with > > doc-base, hence marking Severity: important > > > > The error message (when installing any packing using doc-base, in this > > case python-lmfit-doc) is > > > > Setting up python-lmfit-doc (1.1.0-1) ... > > Processing triggers for doc-base (0.11.1) ... > > Processing 1 added doc-base file... > > Registering documents with dhelp... > > :85:in > > `require': cannot load such file -- dbm (LoadError) > > from > > :85:in > > `require' > > from /usr/lib/ruby/vendor_ruby/dhelp.rb:21:in `' > > from > > :85:in > > `require' > > from > > :85:in > > `require' > > from /usr/sbin/dhelp_parse:32:in `' > > The issue is that dhelp depends on a module that has been removed from > the Ruby standard library (dbm). I imagine the dhelp database is just a > cache and can be rebuilt from scratch on upgrades, so one way to fix > this would be to migrate to a similar module that is available and > probably has a similar enough API, like sdbm (ruby-sdbm). Actually this would invalidate existing databases, creating extra complications. I have just uploaded a ruby-dbm package to NEW, and made the necessary adjustments to the dhelp git repository to use it. I will make an upload when the new package is accepted. signature.asc Description: PGP signature
Bug#996154: obexftp: FTBFS with ruby3.0: ld: final link failed: bad value
Source: obexftp Version: 0.24-6 Severity: serious Justification: FTBFS Tags: bookworm sid ftbfs User: debian-r...@lists.debian.org Usertags: ruby3.0 Hi, We are about to enable building against ruby3.0 on unstable. During a test rebuild, obexftp was found to fail to build in that situation. To reproduce this locally, you need to install ruby-all-dev from experimental on an unstable system or build chroot. This, however, looks unrelated to ruby3.0. Relevant part (hopefully): > /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libopenobex.a(api.c.o): relocation > R_X86_64_PC32 against symbol `stderr@@GLIBC_2.2.5' can not be used when > making a shared object; recompile with -fPIC > /usr/bin/ld: final link failed: bad value > collect2: error: ld returned 1 exit status The full build log is available at https://people.debian.org/~kanashiro/ruby3.0/round2/builds/3/obexftp/obexftp_0.24-6+rebuild1633373966_amd64.build.txt signature.asc Description: PGP signature
Bug#937647: marked as done (python-cliapp: Python2 removal in sid/bullseye)
On Fri, Nov 29, 2019 at 08:47:15PM -0500, Sandro Tosi wrote: > >* QA upload > >* Drop python2 support (Closes: #937647) > >* Run tests during build and under autopkgtest > > there are still 2 rdeps > http://sandrotosi.me/debian/py2removal/python-cliapp_1.svg ! Yes. $ reverse-depends python-cliapp Reverse-Depends === * live-wrapper * vmdebootstrap Packages without architectures listed are reverse-dependencies in: amd64, arm64, armel, armhf, i386, mipsel, ppc64el, s390x $ rmadison live-wrapper vmdebootstrap live-wrapper | 0.6+nmu1 | oldstable| source, all live-wrapper | 0.8 | stable | source, all live-wrapper | 0.10 | unstable | source, all vmdebootstrap | 0.5-2 | oldoldstable | source, amd64, armel, armhf, i386 vmdebootstrap | 1.7-1 | oldstable| source, amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x vmdebootstrap | 1.11-2| stable | source, amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x vmdebootstrap | 1.11-2| unstable | source, amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x Both are out of testing. vmdebootstrap is deprecated, and its removal is pending; live-wrapper uses vmdebootstrap, and needs to migrate away from it. more info: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910201 IMO there is no point in blocking on those two. signature.asc Description: PGP signature
Bug#936313: [PATCH 1/3] Port to python3
On Mon, Nov 25, 2019 at 10:58:42AM -0500, Sandro Tosi wrote: > Antonio, this package is orphaned - just go ahead and do a QA upload for it :) Yes, I know. That was me sending the patches upstream - I copied the bug report to have a publically archived record of them. I'm actually adopting it in the python modules team because it's a dependency for stuff I use. signature.asc Description: PGP signature
Bug#936313: [PATCH 2/3] Add more tests to the check script
--- check | 14 +- fail-tests/fail.stdout-diff | 4 ++-- 2 files changed, 15 insertions(+), 3 deletions(-) diff --git a/check b/check index 83fb46b..43d3ac6 100755 --- a/check +++ b/check @@ -2,4 +2,16 @@ set -eu -./cmdtest yarn.tests +rc=0 + +python3 -m unittest discover -p '*tests.py' || rc=1 + +./cmdtest echo-tests || rc=1 + +./cmdtest sort-tests || rc=1 + +./cmdtest fail-tests && echo "fail-tests did not fail!" && rc=1 || true + +./cmdtest yarn.tests || rc=1 + +exit $rc diff --git a/fail-tests/fail.stdout-diff b/fail-tests/fail.stdout-diff index 47ac588..5ff15ca 100644 --- a/fail-tests/fail.stdout-diff +++ b/fail-tests/fail.stdout-diff @@ -1,4 +1,4 @@ /dev/null 2017-04-20 17:06:09.455944599 +0300 -+++ fail-tests/fail.stdout-actual 2017-04-30 11:15:56.619905930 +0300 +--- /dev/null 2019-11-15 19:57:15.955999653 -0300 fail-tests/fail.stdout-actual 2019-11-25 12:17:53.315392072 -0300 @@ -0,0 +1 @@ +this is not empty output to make test fail -- 2.24.0
Bug#936313: [PATCH 1/3] Port to python3
---
cmdtest | 2 +-
setup.py| 8
yarn| 20 +---
yarnlib/mdparser.py | 11 +--
4 files changed, 19 insertions(+), 22 deletions(-)
diff --git a/cmdtest b/cmdtest
index 1d60900..5a3f445 100755
--- a/cmdtest
+++ b/cmdtest
@@ -1,4 +1,4 @@
-#!/usr/bin/env python
+#!/usr/bin/env python3
# Copyright 2011 Lars Wirzenius
#
# This program is free software: you can redistribute it and/or modify
diff --git a/setup.py b/setup.py
index 9ba00a2..1c11194 100644
--- a/setup.py
+++ b/setup.py
@@ -1,4 +1,4 @@
-#!/usr/bin/python
+#!/usr/bin/python3
# Copyright (C) 2011 Lars Wirzenius
#
# This program is free software; you can redistribute it and/or modify
@@ -43,13 +43,13 @@ class GenerateManpage(build):
def run(self):
build.run(self)
-print 'building manpages'
+print('building manpages')
cmds = ['cmdtest']
if markdown_version:
cmds.append('yarn')
for x in cmds:
with open('%s.1' % x, 'w') as f:
-subprocess.check_call(['python', x,
+subprocess.check_call(['python3', x,
'--generate-manpage=%s.1.in' % x,
'--output=%s.1' % x], stdout=f)
@@ -76,7 +76,7 @@ class Check(Command):
def run(self):
if markdown_version:
subprocess.check_call(
-['python', '-m', 'CoverageTestRunner',
+['python3', '-m', 'CoverageTestRunner',
'--ignore-missing-from', 'without-tests'])
if os.path.exists('.coverage'):
os.remove('.coverage')
diff --git a/yarn b/yarn
index d67c115..ca2035f 100755
--- a/yarn
+++ b/yarn
@@ -1,4 +1,4 @@
-#!/usr/bin/env python
+#!/usr/bin/env python3
# Copyright 2013 Lars Wirzenius
#
# This program is free software: you can redistribute it and/or modify
@@ -116,8 +116,6 @@ class YarnRunner(cliapp.Application):
self._write(sys.stderr, msg)
def _write(self, output, msg):
-if isinstance(msg, unicode):
-msg = msg.encode(locale.getpreferredencoding())
output.write(msg)
output.flush()
@@ -332,7 +330,7 @@ class YarnRunner(cliapp.Application):
started = time.time()
self.info(0, 'Running scenario %s' % scenario.name)
-self.ts['scenario_name'] = scenario.name.encode('utf-8')
+self.ts['scenario_name'] = scenario.name
self.ts.flush()
self.scenarios_run += 1
@@ -450,7 +448,7 @@ class YarnRunner(cliapp.Application):
self.info(1, 'Running step "%s %s"' % (step.what, step.text))
self.ts['current_step'] = step
-self.ts['step_name'] = '%s %s' % (step.what, step.text.encode('utf8'))
+self.ts['step_name'] = '%s %s' % (step.what, step.text)
self.ts.flush()
self.steps_run += 1
@@ -461,7 +459,7 @@ class YarnRunner(cliapp.Application):
env['SRCDIR'] = os.getcwd()
env['HOME'] = self.homedir(datadir)
for i, match in enumerate(m.groups('')):
-env['MATCH_%d' % (i+1)] = match.encode('utf-8')
+env['MATCH_%d' % (i+1)] = match
self.add_srcdir_to_pythonpath(env, env['SRCDIR'])
if self.settings['cd-datadir']:
@@ -487,11 +485,11 @@ class YarnRunner(cliapp.Application):
logging.debug('Exit code: %d' % exit)
if stdout:
-logging.debug('Standard output:\n%s' % self.indent(stdout))
+logging.debug('Standard output:\n%s' %
self.indent(stdout.decode()))
else:
logging.debug('Standard output: empty')
if stderr:
-logging.debug('Standard error:\n%s' % self.indent(stderr))
+logging.debug('Standard error:\n%s' % self.indent(stderr.decode()))
else:
logging.debug('Standard error: empty')
@@ -500,9 +498,9 @@ class YarnRunner(cliapp.Application):
self.error('step "%s %s" failed,' % (step.what, step.text))
self.error('with exit code %d:' % exit)
self.error('Standard output from shell command:\n%s' %
- self.indent(stdout))
+ self.indent(stdout.decode()))
self.error('Standard error from shell command:\n%s' %
- self.indent(stderr))
+ self.indent(stderr.decode()))
self.remember_step_timing(
'%s %s' % (step.what, step.text), time.time() - started)
@@ -541,7 +539,7 @@ class YarnRunner(cliapp.Application):
exit, out, err = cliapp.runcmd_unchecked(
['cp', '-ax', datadir, snapshot])
if exit != 0:
-logging.warning('Snapshot copy failed:\n%s\n%s' % (out, err))
+logging.warning('Snapshot copy failed:\n%s\n%s' %
(out.decode(), err.decode()))
def nice(self, name):
# Quote a scenario or step name so it
Bug#936313: [PATCH 3/3] Fix: remove typo in manpage
--- cmdtest.1.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cmdtest.1.in b/cmdtest.1.in index c76f30c..9d13edd 100644 --- a/cmdtest.1.in +++ b/cmdtest.1.in @@ -182,7 +182,7 @@ Furthermore, the directory will contain the actual output files, and diffs from the expected files. If one of the actual output files is actually correct, -you can actualy rename it to be the expected file. +you can actually rename it to be the expected file. Actually, that's a very convenient way of creating the expected output files: you run the test, -- 2.24.0
Bug#922447: lighttpd: autopkgtest regression
On Mon, Feb 18, 2019 at 07:38:49PM +0100, Paul Gevers wrote: > Hi Helmut, > > [Adding the debian-ci team into the discussion] > > On 18-02-2019 08:06, Helmut Grohne wrote: > >> autopkgtest [00:11:07]: test defconfig: [--- > >> 2019-02-16 00:11:07: (configfile.c.1599) server.upload-dirs doesn't > >> exist: /var/cache/lighttpd/uploads > >> 2019-02-16 00:11:07: (mod_compress.c.275) can't stat compress.cache-dir > >> /var/cache/lighttpd/compress/ Permission denied > > > > What happens here is that /var/cache/lighttpd/compress is not created > > during installation. That actually is a problem, but the question is > > whether the test environment is "sane". > > The ci.d.n runs its tests in a standard LXC. So depending on what you > think you should support, that is where delta's from bare metal > configurations come from. > > > The very same autopkgtest does not fail on salsa-ci: > > https://salsa.debian.org/debian/lighttpd/-/jobs/126948 > > I don't know how salsa-ci runs it's pipelines. > > > Upon closer inspection the difference becomes apparent. salsa-ci is > > performing a regular package installation. > > As does ci.d.n, except in an LXC. > > > lighttpd's init script > > ensures the presence of said directory as does the tmpfile.d config. > > However ci.debian.net runs neither (because it seems to come without an > > init system). > > Didn't know about that. Does anybody know if that is normal for LXCs? That is not the case; it's the other way around: salsa-ci runs stuff on docker containers -- and so have no init system. LXC is designed to run system containers, and it does have a full init system. > > We can of course create these locations in the package itself. Indeed we > > already do that for e.g. /var/log/lighttpd (and that makes us require > > root for build). > > > > It turns out that ci.debian.net's environment is a bit artificial in > > this regard. Should we weaken the test here or should we ensure presence > > of those locations through non-init means? Again, this argument does not hold. LXC (and ci.debian.net) boots an actual init system inside the container, and it has *always* been like this. I have downloaded the lighttpd source here, and read all the tests. All of them to start lighttpd directly, and at least the first test requires being run as root; Tests that need to run as root need to say so in the control file; salsa-ci runs stuff as root already, and that's why it doesn't fail there. In fact, just adding `Restrictions: needs-root` makes the test pass again. Just tested this here. By the way, since all the tests are starting lighttpd directly means that the service definitions and the init integration is not being tested being "the service starts" (because the package installation, and therefore autopkgtest, would fail if that fails). Also, note that when you start lighttpd directly in your script, there will be another instance -- the one started by the init system -- running in the background. signature.asc Description: PGP signature
Bug#780613: diakonos: completely broken in jessie
Package: diakonos Version: 0.9.0-2 Severity: grave Justification: renders package unusable $ diakonos /usr/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in `require': cannot load such file -- curses (LoadError) from /usr/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in `require' from /usr/lib/ruby/vendor_ruby/diakonos.rb:16:in `top (required)' from /usr/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in `require' from /usr/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in `require' from /usr/bin/diakonos:3:in `main' The `curses` library used to be in the Ruby standard library, but it has been removed in newer versions of the Ruby interpreter; it was never packaged independently. https://rubygems.org/gems/curses Just running `gem2deb curses` and installing the resulting package made diakonos work for me. It will also need a dependency on ruby-curses when/if that gets packaged. -- System Information: Debian Release: 8.0 APT prefers buildd-unstable APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- Antonio Terceiro terce...@debian.org signature.asc Description: Digital signature
Bug#735434: ruby1.8 won't be available on Jessie
Dear maintainer, Your package still uses ruby1.8, which is unmaintainable at this point. We can't keep ruby1.8 around for Jessie. We plan to request its removal in 4 weeks. Recommendations for some common cases: If your package contains Ruby programs that are hardcoded to use ruby1.8, you need to port those to a more recent version. Please use /usr/bin/ruby instead. Please do not change to /usr/bin/ruby1.9.1 If your package calls `ruby1.8` during build, please make it call `ruby` instead. If your scripts don't work with a newer Ruby, you need to port them. Please do not change `ruby1.8` to `ruby1.9.1` as it will require more work later when we want to get rid of ruby1.9.1 (and we will). If your packages builds binary extensions for ruby1.8, you need to remove those. Please consider building binary extensions for all supported Ruby versions. You can get a list of supported Ruby versions at runtime by build-depending on gem2deb and running $ dh_ruby --print-supported I'm flagging this bug as release critical, since it's impossible to have ruby1.8 in the next release. If you need advice on the best way to handle your package, please feel free to get in touch with debian-r...@lists.debian.org -- Antonio Terceiro terce...@debian.org signature.asc Description: Digital signature
