Bug#1051112: marked as pending in planetblupi

[Didier Raboud]

Control: tag -1 pending

Hello,

Bug #1051112 in planetblupi reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/games-team/planetblupi/-/commit/60cb81f057ece4028119eda4fad6525db4b56d13


Bump libsdl-kitchinsink B-D to 1.0.11

Closes: #1051112


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1051112

Bug#1032240: akonadi server fails to start since it cannot connect to mysql database

[Didier 'OdyX' Raboud]

Control: tags -1 +moreinfo
Control: severity -1 important

Le vendredi, 10 mars 2023, 21.04:56 h CEST Patrick Franz a écrit :
> the issue is connected to MariaDB when upgrading after the shutdown was
> not clean, see https://bugs.debian.org/cgi-bin/bugreport.cgi?
> bug=1032047#40
> 
> We are trying to find a solution for this.

Enrique; the mentionned bug is now fixed; do you still experience your issue?

Best,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#1029775: pyhst2: FTBFS with setuptools 66: Invalid version: '2020ca'

[Didier 'OdyX' Raboud]

Le lundi, 30 janvier 2023, 18.59:04 h CET Andreas Beckmann a écrit :
> On 28/01/2023 18.09, Didier 'OdyX' Raboud wrote:
> > So. I have a much shorter (and better) patch, that I'll upload to
> > DELAYED/5 in few minutes.
> 
> Thanks alot.

No problem.

Should I push it to unstable?

> There is now a new lintian error (not caused by your patch,
> but by some changed B-D). Since you were looking into
> the python building bits, perhaps you have an idea where this
> is originating from? Notice the difference lib vs. lib64

The code in setup.py does non-Debian stuff around guessing library paths.

A possible patch is attached, I've also pushed it on a branch:

https://salsa.debian.org/science-team/pyhst2/-/merge_requests/2

I have no idea if the resulting package works though.

Best,
OdyXDrop all CUDA-specific library path search

Fixes the superfluous /usr/lib or /usr/lib64 paths in RUNPATH

Author: Didier Raboud 
Origin: vendor

--- a/setup.py
+++ b/setup.py
@@ -261,15 +261,6 @@ def do_pyhst():
 
 cudaconfig = {'home':home, 'nvcc':nvcc,
   'include': pjoin(home, 'include')}
-lib =  pjoin(home, 'lib')
-if os.path.exists(lib+"64") andmath.log(sys.maxsize)/math.log(2) > 60: ##sys.maxint == 2**63-1:
-cudaconfig["lib"] = lib+"64"
-elif os.path.exists(lib+"32") and math.log(sys.maxsize)/math.log(2) < 60:
-cudaconfig["lib"] = lib+"32"
-elif os.path.exists(lib):
-cudaconfig["lib"] = lib
-else:
-print(("No cuda library found "))
 for key, val in cudaconfig.items():
 if not os.path.exists(val):
 raise EnvironmentError('The CUDA %s path could not be located in %s' % (key, val))
@@ -469,9 +460,7 @@ def do_pyhst():
 
 module = Extension('PyHST2_'+version+'/libgputomo',
 sources=sources,
-library_dirs=[CUDA['lib']],
 libraries=['cudart', "cublas", "cuda", "cufft", hdf5_lib],
-runtime_library_dirs=[CUDA['lib']],
 # this syntax is specific to this build system
 # we're only going to use certain compiler args with nvcc and not with gcc
 # the implementation of this trick is in customize_compiler() below
@@ -495,11 +484,8 @@ def do_pyhst():
 module = Extension(name='PyHST2_'+version+'.unsharp3D',
sources=sources ,
depends=[],
-   library_dirs=[CUDA['lib']],
libraries=['cudart','QtGui','QtCore','cudart','tiff'],

-   runtime_library_dirs=[CUDA['lib']],
-   
extra_compile_args={'gcc': ["-std=c99","-g","-fPIC", "-O3","-Wall"],
'nvcc': CUDA["arch"] + [ "--compiler-options",  "-fPIC", "-O3", "-g","-D_FORCE_INLINES" ]},
include_dirs=[numpy.get_include(), CUDA['include'], 'PyHST/Cspace',"/usr/include/qt4"] )
@@ -518,9 +504,7 @@ def do_pyhst():
 global version
 module = Extension('PyHST2_'+version+'/libprojection',
sources=["PyHST/Cspace/c_hst_project_1over.cu"],
-   library_dirs=[CUDA['lib']],
libraries=['cudart', "cuda", "cufft"],
-   runtime_library_dirs=[CUDA['lib']],
extra_compile_args={'gcc': ["-fPIC", "-O3"],
'nvcc': CUDA["arch"] + ["--compiler-options", "-fPIC,-O3" ,"-D_FORCE_INLINES"]},
include_dirs=[numpy.get_include(), CUDA['include'], 'PyHST/Cspace']+ hdf5_dirs)
@@ -542,9 +526,7 @@ def do_pyhst():
 
 module = Extension('PyHST2_'+version+'/libwavelets',
sources=sources,
-   library_dirs=[CUDA['lib']],
libraries=["cudart", "cuda", "cublas"],
-   runtime_library_dirs=[CUDA['lib']],
extra_compile_args={'gcc': ["-fPIC", "-O3"],
'nvcc': CUDA["arch"] + ["--compiler-options", "-fPIC,-O3" ,"-D_FORCE_INLINES"]},
include_dirs=[numpy.get_include(), CUDA['include'], 'PyHST/Cspace'])


signature.asc
Description: This is a digitally signed message part.

Bug#1029775: pyhst2: diff for NMU version 2020c-6.1

[Didier Raboud]

Dear maintainer,

I've prepared an NMU for pyhst2 (versioned as 2020c-6.1) and
uploaded it to DELAYED/5 yesterday (will now migrate in 4 days).
Please feel free to tell me if I should delay it longer.

Regards.

diff -Nru pyhst2-2020c/debian/changelog pyhst2-2020c/debian/changelog
--- pyhst2-2020c/debian/changelog   2022-11-22 15:39:59.0 +0100
+++ pyhst2-2020c/debian/changelog   2023-01-28 18:09:31.0 +0100
@@ -1,3 +1,11 @@
+pyhst2 (2020c-6.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Add patch to set Debian-specific PEP-440-compliant version
+(Closes: #1029775)
+
+ -- Didier Raboud   Sat, 28 Jan 2023 18:09:31 +0100
+
 pyhst2 (2020c-6) unstable; urgency=medium
 
   * Team upload.
diff -Nru 
pyhst2-2020c/debian/patches/0003-set-debian-specific-pep-440-version.patch 
pyhst2-2020c/debian/patches/0003-set-debian-specific-pep-440-version.patch
--- pyhst2-2020c/debian/patches/0003-set-debian-specific-pep-440-version.patch  
1970-01-01 01:00:00.0 +0100
+++ pyhst2-2020c/debian/patches/0003-set-debian-specific-pep-440-version.patch  
2023-01-28 18:00:03.0 +0100
@@ -0,0 +1,50 @@
+Set a Debian-specific PEP-440-compliant version: 2020.3.20230128
+
+This is needed since setuptools 66.0
+
+Bug-Debian: https://bugs.debian.org/1029775
+Author: Didier Raboud 
+Origin: vendor
+
+--- a/setup.py
 b/setup.py
+@@ -88,6 +88,9 @@ global version
+ global aumento_versione
+ aumento_versione="a"
+ 
++# Debian-specific version to match PEP-440 with setuptools v66.0.0
++pep440_version = "2020.3.20230128" # 3 for c, today's date
++
+ global version
+ 
+ if DO_LINK==0:
+@@ -121,7 +124,8 @@ def do_link():
+ 
+ distrib = setup(name="pyhst2_links",
+ license="GPL",
+-version=version+aumento_versione,
++# Debian-specific version to fit PEP-440
++version=pep440_version,
+ description=description,
+ author="Alessandro Mirone",
+ author_email="mir...@esrf.fr",
+@@ -156,7 +160,8 @@ def do_link_unstable():
+ 
+ distrib = setup(name="pyhst2unstable_links",
+ license="GPL",
+-version=version+aumento_versione,
++# Debian-specific version to fit PEP-440
++version=pep440_version,
+ description=description,
+ author="Alessandro Mirone",
+ author_email="mir...@esrf.fr",
+@@ -697,7 +702,8 @@ def do_pyhst():
+ 
+ distrib = setup(name="PyHST2_"+version+post_fix,
+ license="GPL",
+-version=version+aumento_versione, ## aumenta qua versione
++# Debian-specific version to fit PEP-440
++version=pep440_version,
+ description=description,
+ author="Alessandro Mirone",
+ author_email="mir...@esrf.fr",
diff -Nru pyhst2-2020c/debian/patches/series pyhst2-2020c/debian/patches/series
--- pyhst2-2020c/debian/patches/series  2022-11-22 15:39:59.0 +0100
+++ pyhst2-2020c/debian/patches/series  2023-01-28 17:44:39.0 +0100
@@ -1,3 +1,4 @@
 0001-support-cuda-11.patch
 0002-executable-vol2-script
+0003-set-debian-specific-pep-440-version.patch
 typos.patch

Bug#1026568: python-distutils-extra: FTBFS: AssertionError: "diff -x foo.pot -x '*.pyc' -Nur /tmp/tmp[1578 chars]n+\n" != ''

[Didier 'OdyX' Raboud]

Control: tags -1 +pending

Le dimanche, 29 janvier 2023, 12.32:37 h CET Didier 'OdyX' Raboud a écrit :
> I've also pushed this to
> https://salsa.debian.org/python-team/packages/python-distutils-extra/-/merg
> e_requests/7 for review, but given the freeze and as I've tested building
> python-apt with that code and don't see any regressions, I'll upload a Team
> upload to DELAYED/5 later today.

Eh. With tumbleweed's "LGTM" on IRC, I just went ahead and uploaded this.

It looks like the autopkgtest might be failing, so I'll keep an eye on this if 
it fails or delays migration.


Regards,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#1026568: python-distutils-extra: FTBFS: AssertionError: "diff -x foo.pot -x '*.pyc' -Nur /tmp/tmp[1578 chars]n+\n" != ''

[Didier 'OdyX' Raboud]

Control: tags -1 +patch -help

Ok. It turns out staying at a BSP helps finding the brain space to fix such 
things.

Le dimanche, 29 janvier 2023, 00.01:26 h CET Didier 'OdyX' Raboud a écrit :
> The crux of the issue is that python3-setuptools from 54.0.0
> (https://setuptools.pypa.io/en/latest/history.html#v54-0-0) does _not_ build
> the .egg-info as single file, but _only_ as directory [0].
> 
> This has the direct consequence that all tests fail for either of these
> reasons:
> * the .egg-info is not a file, and cannot be compared with the expected
> version
> * the .egg-info directory is not cleaned in clean() , hence the snapshot-vs-
> result directory comparison is always going to flag the .egg-info directory
> as resulting cruft.

Here comes a patch to fix 1 issue in the code itself, and fix all the tests to 
match that new reality.

I've also pushed this to 
https://salsa.debian.org/python-team/packages/python-distutils-extra/-/merge_requests/7
 for review, but given the freeze and as 
I've tested building python-apt with that code and don't see any regressions, 
I'll upload a Team upload to DELAYED/5 later today.

Best,

OdyXdiff --git a/DistUtilsExtra/auto.py b/DistUtilsExtra/auto.py
index 7b3cce1..6376c5e 100644
--- a/DistUtilsExtra/auto.py
+++ b/DistUtilsExtra/auto.py
@@ -85,6 +85,9 @@ def setup(**attrs):
 for d in ignore_dirs:
 if f.startswith(d + os.path.sep):
 src.remove(f)
+# Also remove files from the .egg-info directory
+if '.egg-info/' in f:
+src.remove(f)
 
 __cmdclass(attrs)
 __modules(attrs, src)
diff --git a/debian/changelog b/debian/changelog
index 6147f2f..7209f57 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+python-distutils-extra (2.47.1) UNRELEASED; urgency=medium
+
+  * Adapt tests to distutils 54+; fixes FTBFS (Closes: #1026568)
+
+ -- Didier Raboud   Sun, 29 Jan 2023 12:05:51 +0100
+
 python-distutils-extra (2.47) unstable; urgency=medium
 
   * Team upload.
diff --git a/test/auto.py b/test/auto.py
index 61286d1..17bb81a 100755
--- a/test/auto.py
+++ b/test/auto.py
@@ -51,6 +51,17 @@ setup(
 self.snapshot = None
 self.install_tree = None
 
+def assert_egg_info_directory_is_present_and_well(self):
+'''Check that no .egg-info file is present, that an egg_info directory is present and that it contains the expected files'''
+
+f = self.installed_files()
+# All files are in an .egg-info directory; no .egg-info file is created
+self.assertFalse(any([_.endswith('.egg-info') for _ in f ]))
+# There are 4 files in said directory
+self.assertEqual(len(f), 4)
+# Check that the four exist
+self.assertTrue(all([any([_.endswith(c) for c in ['PKG-INFO', 'SOURCES.txt', 'dependency_links.txt', 'top_level.txt']]) for _ in f]))
+
 #
 # actual tests come here
 #
@@ -63,10 +74,7 @@ setup(
 self.assertEqual(s, 0)
 self.assertNotIn('following files are not recognized', o)
 
-f = self.installed_files()
-# just installs the .egg_info
-self.assertEqual(len(f), 1)
-self.assertTrue(f[0].endswith('.egg-info'))
+self.assert_egg_info_directory_is_present_and_well()
 
 def test_vcs(self):
 '''Ignores revision control files'''
@@ -81,10 +89,7 @@ setup(
 self.assertEqual(s, 0)
 self.assertNotIn('following files are not recognized', o)
 
-f = self.installed_files()
-# just installs the .egg_info
-self.assertEqual(len(f), 1)
-self.assertTrue(f[0].endswith('.egg-info'))
+self.assert_egg_info_directory_is_present_and_well()
 
 def test_modules(self):
 '''Python modules'''
@@ -157,7 +162,7 @@ Exec=/usr/bin/foo-gtk
 self.assertIn('\n  stuff/super.service\n', o)
 
 f = self.installed_files()
-self.assertEqual(len(f), 4) # 3 D-BUS files plus .egg-info
+self.assertEqual(len(f), 7) # 3 D-BUS files plus 4 files in egg-info directory
 self.assertIn('/etc/dbus-1/system.d/com.example.foo.conf', f)
 self.assertIn('/usr/share/dbus-1/system-services/com.example.foo.service', f)
 self.assertIn('/usr/share/dbus-1/services/com.example.foo.gui.service', f)
@@ -178,7 +183,7 @@ Exec=/usr/bin/foo-gtk
 self.assertEqual(s, 0)
 
 f = self.installed_files()
-self.assertEqual(len(f), 3) # 2 schema files plus .egg-info
+self.assertEqual(len(f), 6) # 2 schema files plus 4 files in .egg-info directory
 self.assertIn('/usr/share/glib-2.0/schemas/org.test.myapp.gschema.xml', f)
 self.assertNotIn('gschemas.compiled', '\n'.join(f))
 
@@ -201,7 +206,7 @@ def add_info(report):
 self.assertNotIn('following files are not recognized', o)
 
 f = self.installed_files()
-self.assertEqual(len(f), 3, f) # 2 hook files plus .egg-info
+self.assertEqual(le

Bug#1026568: python-distutils-extra: FTBFS: AssertionError: "diff -x foo.pot -x '*.pyc' -Nur /tmp/tmp[1578 chars]n+\n" != ''

[Didier 'OdyX' Raboud]

Control: tags -1 +confirmed +help

Hello there from the St-Cergue BSP where I've taken a look at this RC bug.

I can confirm this still FTBFS, and doesn't in stable, so let's check why.

The crux of the issue is that python3-setuptools from 54.0.0
(https://setuptools.pypa.io/en/latest/history.html#v54-0-0) does _not_ build 
the .egg-info as single file, but _only_ as directory [0].

This has the direct consequence that all tests fail for either of these 
reasons:
* the .egg-info is not a file, and cannot be compared with the expected 
version
* the .egg-info directory is not cleaned in clean() , hence the snapshot-vs-
result directory comparison is always going to flag the .egg-info directory as 
resulting cruft.

I've trimmed down the report below with an example result, which clearly shows 
the above two things.

Btw, from the FTBFS build directory, the fastest way to reproduce this is to 
run:

 LC_ALL=C LANGUAGE= LANG=C PYTHONPATH=. python3.10 test/auto.py -v -k empty -f


So. python-distutils-extra is broken by src:setuptools which is not going to 
revert this. python3-distutils-extra has 34 reverse Build-Depends, including 
python-apt, which makes it a "key package". Even if the B-D from python-apt 
can be amended, I also identify unattended-upgrades, software-properties and 
command-not-found. It looks like this won't be easy to remove from testing; we 
need to fix it.

Suggestions on the angle to use to tackle this welcome!

Best,

OdyX


[0] Also, distutils is deprecated "soon", so all this should get nuked post-
bookworm, but that's a discussion for another time.

Le mardi, 20 décembre 2022, 18.23:15 h CET Lucas Nussbaum a écrit :
> Source: python-distutils-extra
> Version: 2.47
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20221220 ftbfs-bookworm
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> Relevant part (hopefully):
> > make[1]: Entering directory '/<>'
> > # run tests with all supported python 2 and 3 versions
> > set -e; for python in `py3versions -s`; do \
> > 
> >   echo "-- Running tests with $python "; \
> >   LC_ALL=C LANGUAGE= LANG=C PYTHONPATH=. $python test/auto.py -v; \
> > 
> > done
> > -- Running tests with python3.11 
> > (...)
> > test_empty (__main__.T.test_empty)
> > empty source tree (just setup.py) ... FAIL
> > test_empty (__main__.T.test_empty)
> > empty source tree (just setup.py) ... FAIL

(...)

> > ==
> > FAIL: test_empty (__main__.T.test_empty)
> > empty source tree (just setup.py)
> > --
> > 
> > Traceback (most recent call last):
> >   File "/<>/test/auto.py", line 68, in test_empty
> >   
> > self.assertEqual(len(f), 1)
> > 
> > AssertionError: 4 != 1
> > 
> > ==
> > FAIL: test_empty (__main__.T.test_empty)
> > empty source tree (just setup.py)
> > --
> > 
> > Traceback (most recent call last):
> >   File "/<>/test/auto.py", line 43, in tearDown
> >   
> > self.assertEqual(cruft, '', 'no cruft after cleaning:\n' + cruft)
> > 
> > AssertionError: "diff -x foo.pot -x '*.pyc' -Nur /tmp/tmp[1578 chars]n+\n"
> > != '' - diff -x foo.pot -x '*.pyc' -Nur
> > /tmp/tmp56zs21t4/s/foo.egg-info/PKG-INFO
> > /tmp/tmp15hh51oe/foo.egg-info/PKG-INFO - ---
> > /tmp/tmp56zs21t4/s/foo.egg-info/PKG-INFO1970-01-01 
00:00:00.0
> > + - +++ /tmp/tmp15hh51oe/foo.egg-info/PKG-INFO  2022-12-20
> > 09:38:33.086490908 + - @@ -0,0 +1,8 @@
> > - +Metadata-Version: 2.1
> > - +Name: foo
> > - +Version: 0.1
> > - +Summary: Test suite package
> > - +Home-page: https://foo.example.com
> > - +Author: Martin Pitt
> > - +Author-email: martin.p...@example.com
> > - +License: GPL v2 or later
> > - diff -x foo.pot -x '*.pyc' -Nur
> > /tmp/tmp56zs21t4/s/foo.egg-info/SOURCES.txt
> > /tmp/tmp15hh51oe/foo.egg-info/SOURCES.txt - ---
> > /tmp/tmp56zs21t4/s/foo.egg-info/SOURCES.txt 1970-01-01 
00:00:00.0
> > + - +++ /tmp/tmp15hh51oe/foo.egg-info/SOURCES.txt   2022-12-20
> > 09:38:33.090490943 + - @@ -0,0 +1,5 @@
> > - +setup.py
> > - +foo.egg-info/PKG-INFO
> > - +foo.egg-info/SOURCES.txt
> > - +foo.egg-info/dependency_links.txt
> > - +foo.egg-info/top_level.txt
> > - \ No newline at end of file
> > - diff -x foo.pot -x '*.pyc' -Nur
> > /tmp/tmp56zs21t4/s/foo.egg-info/dependency_links.txt
> > /tmp/tmp15hh51oe/foo.egg-info/dependency_links.txt - ---
> > /tmp/tmp56zs21t4/s/foo.egg-info/dependency_links.txt1970-01-01
> > 00:00:00.0 + - +++
> > /tmp/tmp15hh51oe/foo.egg-info/dependency_links.txt  2022-12-20
> > 09:38:33.086490908 + - @@ -0,0 +1 @@
> > - +
> > - diff -x foo.pot -x '*.pyc' -Nur
> > 

Bug#1028638: libproxy1v5: Gajim 1.6.0-1 crashes in libproxy call

[Didier 'OdyX' Raboud]

Le vendredi, 27 janvier 2023, 17.50:40 h CET Martin a écrit :
> Control: tags -1 + patch
> 
> So far only good reports about the patch by Sebastian ,
> applied in experimental.

From the St-Cergue BSP; could confirm that the crash is fixed by installing 
libproxy1v5 from experimental. Looking forward to getting this fixed in 
unstable!

Best,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#1029775: pyhst2: FTBFS with setuptools 66: Invalid version: '2020ca'

[Didier 'OdyX' Raboud]

Control: tags -1 +pending

So. I have a much shorter (and better) patch, that I'll upload to DELAYED/5 in 
few minutes.

See the attached patch, which consists of setting the setup.py version to a 
PEP-440-compliant Debian-specific version (which I have confirmed to sort 
bigger than "2020ca"). This fixes the FTBFS.

I've also pushed this as an MR on your VCS repository there:

https://salsa.debian.org/science-team/pyhst2/-/merge_requests/1

Best,

OdyX

Le samedi, 28 janvier 2023, 17.21:35 h CET Didier 'OdyX' Raboud a écrit :
> Hello there,
> 
> while at St-Cergue's BSP, I took a look at this issue, so here are my
> findings.
> 
> * I can confirm it fails to build from source in a main+contrib+non-free
> cowbuilder.
> 
> * This FTBFS is the consequence of a new requirement from setuptools; see
> this issue to get it better: https://github.com/pypa/setuptools/issues/2497
> . setuptools now imposes PEP-440-style versioning, that is, the version has
> to match this format:
> 
>   [N!]N(.N)*[{a|b|rc}N][.postN][.devN]
> 
> But pyHST2 uses the version number in some paths (such as /usr/lib/
python3/
> dist-packages/PyHST2_2020c(...) ), so it can't simply be patched to use
> "2020.3" (c ~= 3 ?). I can't login to upstream's issues tracker at
> https://gitlab.esrf.fr/mirone/pyhst2 but it's clearly something that needs
> to be fixed by a new upstream release.
> 
> The attached patch is basically a `sed 's/2020c/2021/g' -i` (also check
> aumento_versione="a" which can work, but should also be amended)  on
> concerned files. It allows to finish building, but the paths have become
> /usr/lib/python3/dist-packages/PyHST2_2021(...), which is clearly not
> upstream's intent.
> 
> I'll check if it's possible to only patch the version and not all files.
> 
> See you in a bit.
> 
> Cheers,
> 
> OdyX
> 
> Le vendredi, 27 janvier 2023, 15.37:13 h CET Andreas Beckmann a écrit :
> > Source: pyhst2
> > Version: 2020c-6
> > Severity: serious
> > Tags: ftbfs
> > Justification: fails to build from source
> > 
> > Hi,
> > 
> > pyhst2 FTBFS with setuptools 66 that was uploaded today:
> > /usr/lib/python3/dist-packages/setuptools/dist.py:548: UserWarning: The
> > version specified ('2020ca') is an invalid version, this may not work as
> > expected with newer versions of setuptools, pip, and PyPI. Please see PEP
> > 440 for more details. warnings.warn(
> > running clean
> > removing '/build/pyhst2-2020c/.pybuild/cpython3_3.10_pyhst2/build' (and
> > everything under it) 'build/bdist.linux-x86_64' does not exist -- can't
> > clean it
> > 'build/scripts-3.10' does not exist -- can't clean it
Set a Debian-specific PEP-440-compliant version: 2020.3.20230128

This is needed since setuptools 66.0

Bug-Debian: https://bugs.debian.org/1029775
Author: Didier Raboud 
Origin: vendor

--- a/setup.py
+++ b/setup.py
@@ -88,6 +88,9 @@ global version
 global aumento_versione
 aumento_versione="a"
 
+# Debian-specific version to match PEP-440 with setuptools v66.0.0
+pep440_version = "2020.3.20230128" # 3 for c, today's date
+
 global version
 
 if DO_LINK==0:
@@ -121,7 +124,8 @@ def do_link():
 
 distrib = setup(name="pyhst2_links",
 license="GPL",
-version=version+aumento_versione,
+# Debian-specific version to fit PEP-440
+version=pep440_version,
 description=description,
 author="Alessandro Mirone",
 author_email="mir...@esrf.fr",
@@ -156,7 +160,8 @@ def do_link_unstable():
 
 distrib = setup(name="pyhst2unstable_links",
 license="GPL",
-version=version+aumento_versione,
+# Debian-specific version to fit PEP-440
+version=pep440_version,
 description=description,
 author="Alessandro Mirone",
 author_email="mir...@esrf.fr",
@@ -697,7 +702,8 @@ def do_pyhst():
 
 distrib = setup(name="PyHST2_"+version+post_fix,
 license="GPL",
-version=version+aumento_versione, ## aumenta qua versione
+# Debian-specific version to fit PEP-440
+version=pep440_version,
 description=description,
 author="Alessandro Mirone",
 author_email="mir...@esrf.fr",


signature.asc
Description: This is a digitally signed message part.

Bug#1029775: pyhst2: FTBFS with setuptools 66: Invalid version: '2020ca'

[Didier 'OdyX' Raboud]

Control: tags -1 confirmed +patch

Hello there,

while at St-Cergue's BSP, I took a look at this issue, so here are my 
findings.

* I can confirm it fails to build from source in a main+contrib+non-free 
cowbuilder.

* This FTBFS is the consequence of a new requirement from setuptools; see this 
issue to get it better: https://github.com/pypa/setuptools/issues/2497 .
setuptools now imposes PEP-440-style versioning, that is, the version has to 
match this format:

[N!]N(.N)*[{a|b|rc}N][.postN][.devN]

But pyHST2 uses the version number in some paths (such as /usr/lib/python3/
dist-packages/PyHST2_2020c(...) ), so it can't simply be patched to use 
"2020.3" (c ~= 3 ?). I can't login to upstream's issues tracker at
https://gitlab.esrf.fr/mirone/pyhst2 but it's clearly something that needs to 
be fixed by a new upstream release.

The attached patch is basically a `sed 's/2020c/2021/g' -i` (also check 
aumento_versione="a" which can work, but should also be amended)  on concerned 
files. It allows to finish building, but the paths have become 
/usr/lib/python3/dist-packages/PyHST2_2021(...), which is clearly not 
upstream's intent.

I'll check if it's possible to only patch the version and not all files.

See you in a bit.

Cheers,

OdyX

Le vendredi, 27 janvier 2023, 15.37:13 h CET Andreas Beckmann a écrit :
> Source: pyhst2
> Version: 2020c-6
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source
> 
> Hi,
> 
> pyhst2 FTBFS with setuptools 66 that was uploaded today:
> /usr/lib/python3/dist-packages/setuptools/dist.py:548: UserWarning: The
> version specified ('2020ca') is an invalid version, this may not work as
> expected with newer versions of setuptools, pip, and PyPI. Please see PEP
> 440 for more details. warnings.warn(
> running clean
> removing '/build/pyhst2-2020c/.pybuild/cpython3_3.10_pyhst2/build' (and
> everything under it) 'build/bdist.linux-x86_64' does not exist -- can't
> clean it
> 'build/scripts-3.10' does not exist -- can't clean it


-- 
OdyXIndex: pyhst2/PyHST/__init__.py
===
--- pyhst2.orig/PyHST/__init__.py
+++ pyhst2/PyHST/__init__.py
@@ -30,4 +30,4 @@
 # is a problem for you.
 #*/
 
-version = "2020c"
+version = "2021"
Index: pyhst2/TEST_PYHST/nonregression.py
===
--- pyhst2.orig/TEST_PYHST/nonregression.py
+++ pyhst2/TEST_PYHST/nonregression.py
@@ -67,7 +67,7 @@ casi=[   "CRAYON",  "HEIKKI",  "HELICOID
 "PATCHES_VECTORIAL",  "SINO_THRESHOLD" ]
 casi=["ID11_SNOW",  "BIG", "LENA",  "LENA_MULTIRINGS",  "MOUSSE",  "MULTIPAGANIN","NANOPOINTS",  "PATCHES_VECTORIAL",  "SINO_THRESHOLD"]
 
-LAUNCHING_INSTRUCTION  = "PyHST2_2020c  input.par"
+LAUNCHING_INSTRUCTION  = "PyHST2_2021  input.par"
 outputprefix="/home/esrf/mirone/nobackup/TEST_PYHST/RESULTS/p9/monogpu"
 # outputprefix="/tmp/TEST_PYHST/RESULTS/p9-04/"
 ###
Index: pyhst2/scripts_link/pyhst2
===
--- pyhst2.orig/scripts_link/pyhst2
+++ pyhst2/scripts_link/pyhst2
@@ -1 +1 @@
-PyHST2_2020c $*
+PyHST2_2021 $*
Index: pyhst2/scripts_link/pyhst2_info
===
--- pyhst2.orig/scripts_link/pyhst2_info
+++ pyhst2/scripts_link/pyhst2_info
@@ -1,6 +1,6 @@
 #!python
 msg = """
-The pyhst2 script launches PyHST2_2020c
+The pyhst2 script launches PyHST2_2021
 
*** PyHST2_2020a
 
Index: pyhst2/setup.py
===
--- pyhst2.orig/setup.py
+++ pyhst2/setup.py
@@ -86,7 +86,7 @@ DO_LINK  = 0
 
 global version
 global aumento_versione
-aumento_versione="a"
+aumento_versione=".1"
 
 global version
 
@@ -95,7 +95,7 @@ if DO_LINK==0:
 os.path.abspath(__file__)), "PyHST", "__init__.py"))
if l.strip().startswith("version")][0]
 else:
-version = "2020c"
+version = "2021"
 
 
 def do_link():
@@ -104,7 +104,7 @@ def do_link():
 # aumento_versione=""
 
 
-version = "2020c"
+version = "2021"
 
 packages = []
 
Index: pyhst2/stdeb_link.cfg
===
--- pyhst2.orig/stdeb_link.cfg
+++ pyhst2/stdeb_link.cfg
@@ -1,3 +1,3 @@
 [DEFAULT]
-Depends: python-pyhst2-2020c | python-pyhst2-2020c-base
-Depends3: python3-pyhst2-2020c | python3-pyhst2-2020c-base
+Depends: python-pyhst2-2021 | python-pyhst2-2021-base
+Depends3: python3-pyhst2-2021 | python3-pyhst2-2021-base


signature.asc
Description: This is a digitally signed message part.

Bug#1029046: Wayland session doesn't get back to life post-suspend

[Didier 'OdyX' Raboud]

Control: tags -1 +patch -help
Control: clone -1 -2
Control: retitle -2 Thinkpad AMD: amd_pmc module is required for correct s0ix 
(Windows mode) suspend
Control: severity -2 important

Hello there, 

My understanding is that there are two distinct bugs here; hereby splitting 
to make this clearer.

* Original bug, as retitled by Salvatore; S3 suspend is broken on some AMD
  Ryzens. This is fixed by this patch queue, also attached.
https://gitlab.freedesktop.org/superm1/linux/-/commits/mlimonci/rhbz-2162013-gitlab-2357-v4/

  In the BIOS, "S3" is "Linux mode" for suspend.

* While investigating this; it turns out modern kernels can also suspend
  on s0ix "Windows mode", but this _requires_ the `amd_pmc` module, which
  is not loaded automatically, but it really should. This doesn't look
  like an upstream bug, but rather a Debian one.

  As this only shows on Laptops with a "Windows mode" BIOS configuration
  (in a box that also shows "Linux mode"), I think it's reasonable to see
  this as a bug of only "important" level (even though not resuming from
  suspend is _bad_).

  I don't think we have seen a patch to fix this one yet though.

Best,

OdyX
Index: linux/drivers/gpio/gpiolib-acpi.c
===
--- linux.orig/drivers/gpio/gpiolib-acpi.c
+++ linux/drivers/gpio/gpiolib-acpi.c
@@ -361,7 +361,7 @@ err:
 }
 
 static bool acpi_gpio_irq_is_wake(struct device *parent,
-  struct acpi_resource_gpio *agpio)
+  const struct acpi_resource_gpio *agpio)
 {
 	unsigned int pin = agpio->pin_table[0];
 
@@ -754,7 +754,7 @@ static int acpi_populate_gpio_lookup(str
 		lookup->info.pin_config = agpio->pin_config;
 		lookup->info.debounce = agpio->debounce_timeout;
 		lookup->info.gpioint = gpioint;
-		lookup->info.wake_capable = agpio->wake_capable == ACPI_WAKE_CAPABLE;
+		lookup->info.wake_capable = acpi_gpio_irq_is_wake(>info.adev->dev, agpio);
 
 		/*
 		 * Polarity and triggering are only specified for GpioInt
@@ -1080,7 +1080,7 @@ int acpi_dev_gpio_irq_wake_get_by(struct
 dev_dbg(>dev, "IRQ %d already in use\n", irq);
 			}
 
-			if (wake_capable)
+			if (wake_capable && acpi_gbl_FADT.flags & ACPI_FADT_LOW_POWER_S0)
 *wake_capable = info.wake_capable;
 
 			return irq;
@@ -1599,6 +1599,19 @@ static const struct dmi_system_id gpioli
 			.ignore_interrupt = "AMDI0030:00@18",
 		},
 	},
+	{
+		/*
+		 * Spurious wakeups from TP_ATTN# pin
+		 * Found in BIOS 1.7.8
+		 * https://gitlab.freedesktop.org/drm/amd/-/issues/1722#note_1720627
+		 */
+		.matches = {
+			DMI_MATCH(DMI_BOARD_NAME, "NL5xRU"),
+		},
+		.driver_data = &(struct acpi_gpiolib_dmi_quirk) {
+			.ignore_wake = "ELAN0415:00@9",
+		},
+	},
 	{} /* Terminating entry */
 };
 
Index: linux/drivers/pinctrl/pinctrl-amd.c
===
--- linux.orig/drivers/pinctrl/pinctrl-amd.c
+++ linux/drivers/pinctrl/pinctrl-amd.c
@@ -365,6 +365,7 @@ static void amd_gpio_dbg_show(struct seq
 
 			} else {
 debounce_enable = "  ∅";
+time = 0;
 			}
 			snprintf(debounce_value, sizeof(debounce_value), "%u", time * unit);
 			seq_printf(s, "debounce %s ( %sus)| ", debounce_enable, debounce_value);


signature.asc
Description: This is a digitally signed message part.

Bug#1028451: 2nd DisplayPort doesn't get video

[Didier 'OdyX' Raboud]

Control: tags -1 +patch

Le vendredi, 20 janvier 2023, 21.38:42 h CET Salvatore Bonaccorso a écrit :
> There is the patchset currently asked for inclusion at
> https://lore.kernel.org/stable/20230119235200.441386-1-harry.wentl...@amd.co
> m/T/#m3b5b3616eac750cfd7c9bd00ac1cf95006a6aeec which is for addressing this
> issue.

Indeed. I can confirm this fixes my issue with the attached patch on top of 
6.1.7-1, which is all 4 patches from :
 https://gitlab.freedesktop.org/hwentland/linux/-/commits/mst_regression_6.1
aka:
 https://gitlab.freedesktop.org/hwentland/linux/-/compare/
21e996306a6afaae88295858de0ffb8955173a15...1521e9dcb431f31c15a0256cb619b09cca3efc4e?
from_project_id=12209=false

I hope this can either get to 6.1 stable, or be backported / carried over by 
Debian! Happy to MR this if it makes sense!

Best,
OdyXdiff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index dacad8b85963..fbc89129e7de 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -9399,6 +9399,8 @@ static int amdgpu_dm_atomic_check(struct drm_device *dev,
 	struct drm_connector_state *old_con_state, *new_con_state;
 	struct drm_crtc *crtc;
 	struct drm_crtc_state *old_crtc_state, *new_crtc_state;
+	struct drm_dp_mst_topology_mgr *mgr;
+	struct drm_dp_mst_topology_state *mst_state;
 	struct drm_plane *plane;
 	struct drm_plane_state *old_plane_state, *new_plane_state;
 	enum dc_status status;
@@ -9654,6 +9656,28 @@ static int amdgpu_dm_atomic_check(struct drm_device *dev,
 		lock_and_validation_needed = true;
 	}
 
+#if defined(CONFIG_DRM_AMD_DC_DCN)
+	/* set the slot info for each mst_state based on the link encoding format */
+	for_each_new_mst_mgr_in_state(state, mgr, mst_state, i) {
+		struct amdgpu_dm_connector *aconnector;
+		struct drm_connector *connector;
+		struct drm_connector_list_iter iter;
+		u8 link_coding_cap;
+
+		drm_connector_list_iter_begin(dev, );
+		drm_for_each_connector_iter(connector, ) {
+			if (connector->index == mst_state->mgr->conn_base_id) {
+aconnector = to_amdgpu_dm_connector(connector);
+link_coding_cap = dc_link_dp_mst_decide_link_encoding_format(aconnector->dc_link);
+drm_dp_mst_update_slots(mst_state, link_coding_cap);
+
+break;
+			}
+		}
+		drm_connector_list_iter_end();
+	}
+#endif
+
 	/**
 	 * Streams and planes are reset when there are changes that affect
 	 * bandwidth. Anything that affects bandwidth needs to go through
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index f72c013d3a5b..16623f73ddbe 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -120,23 +120,50 @@ enum dc_edid_status dm_helpers_parse_edid_caps(
 }
 
 static void
-fill_dc_mst_payload_table_from_drm(struct drm_dp_mst_topology_state *mst_state,
-   struct amdgpu_dm_connector *aconnector,
+fill_dc_mst_payload_table_from_drm(struct dc_link *link,
+   bool enable,
+   struct drm_dp_mst_atomic_payload *target_payload,
    struct dc_dp_mst_stream_allocation_table *table)
 {
 	struct dc_dp_mst_stream_allocation_table new_table = { 0 };
 	struct dc_dp_mst_stream_allocation *sa;
-	struct drm_dp_mst_atomic_payload *payload;
+	struct link_mst_stream_allocation_table copy_of_link_table =
+		link->mst_stream_alloc_table;
+
+	int i;
+	int current_hw_table_stream_cnt = copy_of_link_table.stream_count;
+	struct link_mst_stream_allocation *dc_alloc;
+
+	/* TODO: refactor to set link->mst_stream_alloc_table directly if possible.*/
+	if (enable) {
+		dc_alloc =
+		_of_link_table.stream_allocations[current_hw_table_stream_cnt];
+		dc_alloc->vcp_id = target_payload->vcpi;
+		dc_alloc->slot_count = target_payload->time_slots;
+	} else {
+		for (i = 0; i < copy_of_link_table.stream_count; i++) {
+			dc_alloc =
+			_of_link_table.stream_allocations[i];
+
+			if (dc_alloc->vcp_id == target_payload->vcpi) {
+dc_alloc->vcp_id = 0;
+dc_alloc->slot_count = 0;
+break;
+			}
+		}
+		ASSERT(i != copy_of_link_table.stream_count);
+	}
 
 	/* Fill payload info*/
-	list_for_each_entry(payload, _state->payloads, next) {
-		if (payload->delete)
-			continue;
-
-		sa = _table.stream_allocations[new_table.stream_count];
-		sa->slot_count = payload->time_slots;
-		sa->vcp_id = payload->vcpi;
-		new_table.stream_count++;
+	for (i = 0; i < MAX_CONTROLLER_NUM; i++) {
+		dc_alloc =
+			_of_link_table.stream_allocations[i];
+		if (dc_alloc->vcp_id > 0 && dc_alloc->slot_count > 0) {
+			sa = _table.stream_allocations[new_table.stream_count];
+			sa->slot_count = dc_alloc->slot_count;
+			sa->vcp_id = dc_alloc->vcp_id;
+			new_table.stream_count++;
+		}
 	}
 
 	/* Overwrite the old table */
@@ -185,7 +212,7 @@ bool dm_helpers_dp_mst_write_payload_allocation_table(
 	 * AUX message. The sequence is slot 1-63 allocated 

Bug#1029046: Wayland session doesn't get back to life post-suspend

[Didier 'OdyX' Raboud]

Control: retitle -1 Thinkpad: amd_pmc module required for on 6.1 for correct 
suspend

Le mardi, 17 janvier 2023, 22.53:54 h CET Didier 'OdyX' Raboud a écrit :
> Le mardi, 17 janvier 2023, 15.32:37 h CET Diederik de Haas a écrit :
> > On Monday, 16 January 2023 22:33:05 CET Didier 'OdyX' Raboud wrote:
> > > This is on 6.1.4-1a~test, patched against the "2nd DisplayPort doesn't
> > > light up", so feel free to close the bug; I'll test if I get the same
> > > symptoms on an unpatched kernel anyway :-)
> > 
> > If this issue doesn't occur with the unpatched kernel, that would be VERY
> > important extra information!
> > https://gitlab.freedesktop.org/drm/amd/-/issues/2171#note_1724186 may be
> > the same or similar finding?
> > 
> > If that issue doesn't occur with the unpatched kernel, could you add your
> > finding to that upstream/forwarded issue?
> 
> Now that I got my kernel build in place; I can actually confirm that:
> 
> On my Thinkpad X13 Gen 2a, without any dongle, hub or docking station (on
> battery), with a KDE Plasma Wayland session:
> 
> * 6.0.0-6-amd64 (6.0.12-1)
>   suspends and resumes correctly
> * 6.1.0-1-amd64 (6.1.4-1, unpatched)
>   doesn't finish suspending
> * 6.1.0-2-amd64 (6.1.6-1, from the 'sid' branch on salsa, not patched)
>   doesn't finish suspending
> * 6.1.0-2-amd64 (6.1.6-1, from the 'sid' branch on salsa, patched),
>   doesn't finish suspending
> 
> All three 6.1 kernels (whether patched or not) don't bring the laptop to the
> suspended state (power led 'breathing', fans off), but it's kept in an "on"
> state (power led on, fans on), from which I found that I *can* wake the
> laptop up by short-pressing the power button; the screens gets back to life
> and show my lockscreen. But from there, I can't move the mouse nor do
> anything else. Alt-SysRq-r + ctrl-alt-f2 give me a tty, but any comeback to
> tty1 only blank (not even a blank screen, just a freeze).
> 
> This seems to point to a quite severe regression in amdgpu or other amd-
> related code; I can't suspend-and-resume the laptop anymore on any 6.1
> kernel, on battery, without anything attached to it.
> 
> I'll forward the above findings to the bug you pointed to, hoping it could
> help upstream too!

OK. I've gone and done this: 
https://gitlab.freedesktop.org/drm/amd/-/issues/2171#note_1727281

It turns out to get suspend to work, the `amd_pmc` module needs to be enabled
(_AND_ the BIOS needs to have the "Sleep State" toggled to Windows (from
Linux).

I _think_ Debian should make sure amd_pmc is loaded on (all?) modern AMD
laptops. I have no idea (yet) what the mechanism to make this happen is though.

-- 
OdyX

Bug#1028451: 2nd DisplayPort doesn't get video

[Didier 'OdyX' Raboud]

Hello Salvatore,

17 janvier 2023 07:14 "Salvatore Bonaccorso"  a écrit:
> I will bite the bullet (taking full responsibility for it if
> necessary, don't blame the other kernel team members) and ask here now
> the release team: Can we let linux 6.1.4-1 despite the RC bug
> reported, migrate to testing, so we can move on to 6.1.y? Let's keep
> the bug as RC severity. I'm currently working on uploading as well
> 6.1.6 or 6.1.7 (depending on the timing) further after that to
> unstable. Unfortuantely there is still not a solution to address
> #1028451 but will contain other important fixes (including security
> ones).
> 
> Thank you for considering it,
> 
> Odyx, I feel sorry, this will knowingly impact your and others!

No problem; such is the life on the unstable/testing edge.

I'll keep a 6.0.0-6 kernel around, and will keep testing the most
recent kernels; as well as report back if these help.

Best,

OdyX

Bug#1028451: 2nd DisplayPort doesn't get video

[Didier 'OdyX' Raboud]

Hello there,

I finally managed to test

https://github.com/archlinux/linux/commit/7c4fed4d2afd27d7acb8835f8e79f49c99c03cdf.patch

(which is a revert of 4d07b0bc403403438d9cf88450506240c5faf92f)

… on top of 6.1.4-1.

I can confirm (without looking into any code-related details), that the two
of my DisplayPort-connected screens light up and work correctly.

(The "first" external screen is connected with a DisplayPort-DVI converter; that
one always worked; the "second" is connected directly via DisplayPort, which 
didn't
work on unpatched 6.1.4)


14 janvier 2023 17:52 "Diederik de Haas"  a écrit:
> On Saturday, 14 January 2023 16:30:05 CET Salvatore Bonaccorso wrote:
>> On Thu, Jan 12, 2023 at 02:51:05PM +0100, Diederik de Haas wrote:
>> On Thursday, 12 January 2023 12:03:24 CET Sjoerd Simons wrote:
>>> Fwiw there is a general regression with AMDGPU MST on linux 6.1; tracked
>>> 
>>> upstream here:
>>> https://gitlab.freedesktop.org/drm/amd/-/issues/2171
>> 
>> Thanks! About an hour ago the suggested fix was to revert commit
>> 4d07b0bc403403438d9cf88450506240c5faf92f part of v6.1-rc1
>> 
>> https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#
>> s4.2.2 describes a procedure to build a kernel with the proposed patch
>> (attached).
>> 
>> OdyX: Can you try to see whether that resolves the issue?
>> 
>> Should we keep 6.1.y based kernel out of testing until this is clear?
>> As we aim though to have 6.1.y into bookworm I would see it as more
>> preferable to get 6.1.4 in for testing, we will need to followup as
>> well soonish with another interation for e.g. for fixing
>> CVE-2023-0266.
> 
> As CVE-2023-0266 is fixed in 6.1.6, I'd suggest to upload that now, which I
> believe is ready to be uploaded already.
> That should keep 6.1.y out of testing for a few more days.
> 
>> Now if it turns out that this is the same issue as the referenced
>> upstream, reverting I think we only should really revert the commit if
>> that's queued up for 6.1. There is currently some furhter discussion
>> on
>> https://lore.kernel.org/stable/dcf0612f-7d40-d607-e9aa-94599594e...@amd.com
>> /T/#m38bdafb9c6c64b167ec94ac1bd131f1d2db66e40
>> 
>> Given the size of the revert, there is as well a chance to re-break
>> other parts. So preferring to closely follow upstream here, whatever
>> the decision will be.
> 
> Agreed.
> 
> I asked 'OdyX' to test the revert to make sure it would indeed fix *this*
> issue, IOW what I consider standard bug triaging.
> 
> But even Daniel Vetter has SERIOUS 'issues' with the revert, next to the other
> people who weren't happy about it. So *I* wouldn't suggest applying it to
> Debian (although I don't think my opinion should have much weight).
> 
> As for letting this bug _continue_ to prevent a migration, ie keep the RC
> status, I'm against it and for downgrading it to 'important'.
> You could opt to add a NEWS item to warn people about this potential issue.
> 
> But the original report is about the *2nd* DisplayPort being 'broken'.
> 
> On zaterdag 14 januari 2023 17:04:52 CET you wrote:
> 
>> Basically this issue breaks all usage of Displayport MST on amdgpu systems.
>> Which roughly translates to breaking external monitors for everyone using
>> an USB-C docks with multiple display outputs (which is pretty common these
>> days) on AMD laptops. As well as those like myself who daisy-chain display
>> port monitors with an amdgpu using graphics card.
> 
> I understand that would be annoying for you, but I don't think that it would
> affect the majority of our users.

Hrm. More and more laptops come with usb-c only, and dongles/docks become more
and more common.

It's clearly a serious regression, as such setups "just worked" with 6.0.

Best,

OdyX

Bug#1028451: 2nd DisplayPort doesn't get video

[Didier 'OdyX' Raboud]

Hello there,

It's really time-consuming to download, reboot, wait cryptsetup prompt, fail,
reboot, wait cryptsetup prompt, type long passphrase, log in account, dpkg -i,
reboot, rinse repeat.

Anyway, I can confirm that on my Lenovo X13 AMD;

* 6.1~rc3+1~exp1 doesn't boot until the cryptsetup prompt
* 6.1~rc5+1~exp1 doesn't boot until the cryptsetup prompt
* 6.1~rc6+1~exp1 doesn't boot until the cryptsetup prompt
* 6.1~rc7+1~exp1 boots until the cryptsetup prompt, but the culprit screen
  doesn't get anything

So it seems the issue was already there in 6.1~rc7+1~exp1, but I can't rewind
further.

Hope that helps!

OdyX

11 janvier 2023 10:04 "Diederik de Haas"  a écrit:

> On Wednesday, 11 January 2023 08:33:29 CET Didier 'OdyX' Raboud wrote:
> 
>> Package: src:linux
>> Version: 6.1.4-1
>> Severity: serious
>> 
>> Since booting 6.1.0-1, the 2nd DisplayPort output from my Lenovo Docking
>> Station doesn't get any output.
> 
> Can you try the previous versions of the 6.1.x series which you can get via
> snapshot.debian.org? I recommend to start with the first 6.1-rcX version.
> 
> A `git bisect` is the best way to figure out what caused it, but the above
> procedure is the quickest way to narrow down the search space.

Bug#1028451: 2nd DisplayPort doesn't get video

[Didier 'OdyX' Raboud]

Package: src:linux
Version: 6.1.4-1
Severity: serious

Hello there,

Since booting 6.1.0-1, the 2nd DisplayPort output from my Lenovo Docking
Station doesn't get any output. It is _seen_ as connected by the screen, but
apparently gets no video signal (or just blank). This is clearly a regression
from 6.0.0-6 where this was working.

I'm quite confident this is a kernel-level change (and not X11 or Plasma) as
this already appears clearly at cryptsetup password prompt (which usually goes
to all outputs, but not on 6.1.0-1 which only displays it on the laptop screen
and the 1st connected DisplayPort.

Happy to help solve this.

Best,
OdyX


-- Package-specific info:
** Version:
Linux version 6.1.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 
12.2.0-13) 12.2.0, GNU ld (GNU Binutils for Debian) 2.39.90.20221231) #1 SMP 
PREEMPT_DYNAMIC Debian 6.1.4-1 (2023-01-07)

** Command line:
BOOT_IMAGE=/vmlinuz-6.1.0-1-amd64 root=/dev/mapper/turnagra--vg-root ro quiet 
splash cgroup_enable=memory apparmor=1 security=apparmor

** Tainted: W (512)
 * kernel issued warning

** Kernel log:
[   15.343546] input: HD-Audio Generic Headphone as 
/devices/pci:00/:00:08.1/:05:00.6/sound/card4/input38
[   15.443246] usbcore: registered new interface driver btusb
[   15.481320] bluetooth hci0: firmware: direct-loading firmware 
mediatek/BT_RAM_CODE_MT7961_1_2_hdr.bin
[   15.493335] intel_rapl_common: Found RAPL domain package
[   15.493340] intel_rapl_common: Found RAPL domain core
[   15.499969] mt7921e :03:00.0: enabling device ( -> 0002)
[   15.518411] mt7921e :03:00.0: ASIC revision: 79610010
[   15.602835] mt7921e :03:00.0: firmware: direct-loading firmware 
mediatek/WIFI_MT7961_patch_mcu_1_2_hdr.bin
[   15.602842] mt7921e :03:00.0: HW/SW Version: 0x8a108a10, Build Time: 
20221109110918a

[   15.603213] Bluetooth: hci0: Device setup in 121459 usecs
[   15.603217] Bluetooth: hci0: HCI Enhanced Setup Synchronous Connection 
command is advertised, but not supported.
[   15.614235] mt7921e :03:00.0: firmware: direct-loading firmware 
mediatek/WIFI_RAM_CODE_MT7961_1.bin
[   15.614240] mt7921e :03:00.0: WM Firmware Version: 01, Build 
Time: 20221109111005
[   15.654966] mt7921e :03:00.0: firmware: direct-loading firmware 
mediatek/WIFI_RAM_CODE_MT7961_1.bin
[   15.676225] EXT4-fs (nvme0n1p2): mounting ext2 file system using the ext4 
subsystem
[   15.677063] EXT4-fs (nvme0n1p2): mounted filesystem without journal. Quota 
mode: none.
[   15.679393] EXT4-fs (dm-4): mounted filesystem with ordered data mode. Quota 
mode: none.
[   15.679984] EXT4-fs (dm-2): mounted filesystem with ordered data mode. Quota 
mode: none.
[   15.689038] systemd-journald[673]: Received client request to flush runtime 
journal.
[   15.692904] systemd-journald[673]: File 
/var/log/journal/554675a9a7254eeea535d3d6aa31a8a6/system.journal corrupted or 
uncleanly shut down, renaming and replacing.
[   15.849074] audit: type=1400 audit(1673421894.663:4): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-senddoc" 
pid=980 comm="apparmor_parser"
[   15.849408] audit: type=1400 audit(1673421894.663:5): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="lsb_release" pid=966 
comm="apparmor_parser"
[   15.849475] audit: type=1400 audit(1673421894.663:6): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-oosplash" 
pid=979 comm="apparmor_parser"
[   15.849517] audit: type=1400 audit(1673421894.663:7): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="torbrowser_tor" pid=974 
comm="apparmor_parser"
[   15.849866] audit: type=1400 audit(1673421894.663:8): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=969 
comm="apparmor_parser"
[   15.849871] audit: type=1400 audit(1673421894.663:9): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod" 
pid=969 comm="apparmor_parser"
[   15.849949] audit: type=1400 audit(1673421894.663:10): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/bin/man" pid=977 
comm="apparmor_parser"
[   15.849954] audit: type=1400 audit(1673421894.663:11): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="man_filter" pid=977 
comm="apparmor_parser"
[   15.849957] audit: type=1400 audit(1673421894.663:12): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="man_groff" pid=977 
comm="apparmor_parser"
[   15.851055] audit: type=1400 audit(1673421894.667:13): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="system_tor" pid=972 
comm="apparmor_parser"
[   16.466830] mt7921e :03:00.0 wlp3s0: renamed from wlan0
[   16.789424] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   16.789428] Bluetooth: BNEP filters: protocol multicast
[   16.789433] Bluetooth: BNEP socket layer initialized
[   16.790811] Bluetooth: MGMT ver 1.22

Bug#995792: printing text files

[Didier 'OdyX' Raboud]

Le dimanche, 30 octobre 2022, 00.43:02 h CET Thorsten Alteholz a écrit :
> The problem seems to be that it was installed on a system without need
> for it. Wouldn't there be a better package than printer-driver-all-enforce
> to add a Recommends: for it?  Maybe OdyX can shed some light on it?

The printer-driver-all metapackage was introduced as an easy way to get the 
widest possible support for all potential printing drivers.  As britney 
doesn't look (or enforce) recommends, the source package also ships printer-
driver-all-enforce that has the same recommends as depends, to abuse britney 
in keeping all drivers in testing.  The latter package was not really meant to 
be installed or used.

Anyway, when that mechanism was introduced, printer-driver-all was a 
dependency of task-printing, but for buster (or bullseye), I had decided to 
drop that task, and let cups rely on driverless printing by default.  I'd say 
printer-driver-all is still a useful "if you have printing problems, install 
that with its recommends", but definitely not as central to the printing stack 
as it used to be.

As for indexbraille, as Samuel wrote, it was a mimetype mismatch, so that's 
solved!

-- 
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#1017130: yakuake FTBFS

[Didier 'OdyX' Raboud]

Control: tags -1 +upstream +patch +fixed-upstream

Hello,

I can confirm this is fixed in 22.08 [0]. Specifically, the commits are as 
follows:
- 
https://invent.kde.org/utilities/yakuake/-/commit/56c0b6f38968902765ffe706e2694eb50b0834f7
 (not all of it)
- 
https://invent.kde.org/utilities/yakuake/-/commit/9e691cfa077bb2e26efc14dd021da0836d70782d

I'd be happy to join the yakuake maintenance team BTW.

Best,

OdyX

[0] https://invent.kde.org/utilities/yakuake/-/commits/release/22.08/

Bug#996761: some problem (debian testing and nouveau drever)

[didier]

I have the same problem with kwin 4:5.21.5-2 in testing

I use the 4:5.23.0-2 98 from sid.

Need to add some dependency (plasma ) from sid.

System not fully fonctional, mais usable

Bug#972339: more info

[Didier 'OdyX' Raboud]

Control: unarchive -1 

Hello there,

I have gotten more info from good folks at OpenSuse:

> We at openSUSE got a similar (perhaps even same?) issue
> https://bugzilla.suse.com/show_bug.cgi?id=1187232
> 
> In the end the root cause there was that the installed
> HPLIP plugin did not match the installed HPLIP, see
> https://bugzilla.suse.com/show_bug.cgi?id=1187232#c8
> 
> Perhaps this might also help you with
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972339
> 
> Even if the openSUSE issue is actually a different one
> it may help to know that HPLIP programs seem to blindly
> use plugin code and may fail in arbitrary ways if the
> plugin code does not fit.

-- 
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#987457: gutenprint-locales is empty

[Didier 'OdyX' Raboud]

Control: tags -1 +patch +pending

Le samedi, 24 avril 2021, 11.10:04 h CEST Adrian Bunk a écrit :
> Package: gutenprint-locales
> Version: 5.3.1-7
> Severity: grave
> 
> $ dpkg -L gutenprint-locales

Hello Adrian,

I'm not sure I agree with the severity; but it certainly needs fixing!

I'm going to ask for an unblock with the following patch, feedback welcome.

--- a/debian/rules
+++ b/debian/rules
@@ -26,9 +26,15 @@ override_dh_auto_configure:
  $(MAINTAINER_MODE) \
  --enable-nls
 
+execute_after_dh_auto_build-indep:
+   # Build the gettext translations (#987457)
+   cd po && make update-gmo
+
 override_dh_install-indep:
dh_install -i
rm -f debian/gutenprint-locales/usr/share/locale/*/*.po
+   # Make sure at least some locales are installed (#987457)
+   test -n "$$(find debian/gutenprint-locales/usr/share/locale -name 
gutenprint.mo)"
 
 override_dh_installdocs:
dh_installdocs -pescputil --link-doc=libgutenprint9


OdyX


signature.asc
Description: This is a digitally signed message part.

Bug#974828: printer-driver-hpcups: SIGABRT with "free(): invalid next size (normal)" in HPCupsFilter::cleanup

[Didier 'OdyX' Raboud]

Control: tags -1 +pending

Le vendredi, 26 février 2021, 15.41:07 h CET Bernhard Übelacker a écrit :
> Dear Maintainer,
> with the original PPD and input files from Ian I could
> reproduce the issue and with the help of rr-debugger
> this is what I assume what happens:
> 
> - The buffer m_pPrinterBuffer is allocated here with
>the current sizes inside cups_header. [1]
> 
> - The first page got processed and for the second page
>a new cups_header record gets copied. [2]
>Unfortunately now the header contains higher sizes,
>but the buffer is not grown accordingly.
> 
> - Now to this buffer is written by a read function, and beyond
>where the management information of malloc got overwritten for
>some other random memory. [3]
> 
> - The defect in the management information of malloc is detected
>and the process is aborted. [4]
> 
> 
> The attached patch is an attempt to grow the buffer size
> if the header changes on a new page.
> This is just tested for the given crash, nothing more, therefore
> there might be side effects on replacing this buffer?

I have forwarded this upstream, but don't hold your breath; I don't expect any 
feedback from them, sadly. :-(

I'll apply this and upload to unstable once the current version migrated.

Thanks a lot for your work!

OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#972339: armhf: hpcups crashes with free() invalid pointer for some printers

[Didier 'OdyX' Raboud]

Control: found -1 3.21.2+dfsg1-1

Hello there Bernhard,
(CC'ing d-arm for help)

Sadly, I could confirm on a local armhf QEMU instance that this serious bug is 
still present, in sid and bullseye; the steps in
https://bugs.debian.org/972339#10 still apply and trigger the SIGABRT.

Although I understand what you're saying in theoretical terms here, I'm 
completely at loss to propose a patch: I'm way over my head with my 10+years-
old C and gdb competences. In the absence of any interest from upstream, I 
need help to fix hplip on armhf.

(Note that amd64 is apparently also affected; see #974828)

Whoever willing to help; if you need anything from me (as maintainer), please 
ask! I'm happy to explain my use of git-debrebase, or provide a different git 
history if it helps, I mostly don't want to be in the way of a fix!

Humbly,
OdyX

Le samedi, 24 octobre 2020, 14.05:04 h CET Bernhard Übelacker a écrit :
> I could reproduce this issue too.
> 
> Attached is a valgrind run showing one invalid write
> and a gdb session showing the issue.
> 
> It looks like mallocs management data, which resides in the 8 bytes
> before a returned pointer, gets overwritten and therefore
> the free fails because "mchunk_size" is then 0.
> 
> Kind regards,
> Bernhard
> 
> 
> Old value = 6057
> New value = 0
> __memcpy_neon () at ../sysdeps/arm/armv7/multiarch/memcpy_impl.S:295
> warning: Source file is more recent than executable.
> 295 tst count, #4
> 1: compressBuf =  named `this'> 2: /x *(int*)(0x7f5f43e8-4) = 0x0
> (gdb) bt
> #0  __memcpy_neon () at ../sysdeps/arm/armv7/multiarch/memcpy_impl.S:295
> #1  0x7f55b8d2 in memcpy (__len=379, __src=,
> __dest=) at
> /usr/include/arm-linux-gnueabihf/bits/string_fortified.h:34 #2 
> Mode9::Process (this=0x7f5e0e70, input=0x7f5e0e84) at
> prnt/hpcups/Mode9.cpp:405 #3  0x7f562de0 in Pipeline::Process
> (raster=, this=0x7f5d7340) at prnt/hpcups/Pipeline.cpp:79 #4
>  Pipeline::Execute (this=0x7f5d7340, InputRaster=) at
> prnt/hpcups/Pipeline.cpp:79 #5  0x7f562e02 in Pipeline::Execute
> (this=0x7f5e6b88, InputRaster=) at
> prnt/hpcups/Pipeline.cpp:83 #6  0x7f562e02 in Pipeline::Execute
> (this=0x7f5e6b70, InputRaster=) at
> prnt/hpcups/Pipeline.cpp:83 #7  0x7f55a20a in
> HPCupsFilter::processRasterData (this=0x7f5b87c4 ,
> cups_raster=) at prnt/hpcups/HPCupsFilter.cpp:766 #8 
> 0x7f55a6ee in HPCupsFilter::StartPrintJob (this=0x7f5b87c4 ,
> argc=6, argv=0xbefff7b4) at prnt/hpcups/HPCupsFilter.cpp:584 #9  0xb6bd9a20
> in __libc_start_main (main=0x7f5587d1 , argc=6,
> argv=0xbefff7b4, init=, fini=0x7f56ed5d <__libc_csu_fini>,
> rtld_fini=0xb6fe1075 <_dl_fini>, stack_end=0xbefff7b4) at libc-start.c:308
> #10 0x7f55889c in _start () at prnt/hpcups/HPCupsFilter.cpp:919
> 
> 
> https://sources.debian.org/src/hplip/3.21.2+dfsg1-1/prnt/hpcups/Mode9.cpp/#L
> 405


-- 
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#983263: 3.21.2 should not migrate automatically (yet)

[Didier 'OdyX' Raboud]

Source: hplip
Version: 3.21.2+dfsg0-1
Severity: serious

As hplip maintainer, I'm hereby making sure that hplip 3.21.2 doesn't migrate
automatically to bullseye. It was uploaded by mistake to unstable, but two
alternatives exist:
- A) Revert to 3.20.11, because the changes are too disruptive;
- B) Allow 3.21.2 in bullseye, because the increased hardware support is worth
 it.

Let's give the autobuilders, autopkgtest runners and Debian sid users some
time in this soft freeze, to see whether there are important regressions
tilting this balance towards A).

OdyX

Bug#982838: RoM: win32-loader must not migrate automatically

[Didier 'OdyX' Raboud]

Source: win32-loader
Version: 0.10.5
Severity: serious
X-Debbugs-Cc: debian-b...@lists.debian.org, debian-rele...@lists.debian.org

win32-loader is one of the rare packages always blocked, because it has a
'byhand' counterpart per release: `/debian/tools/win32-loader/{release}`, and
therefore needs a manual action by FTP masters in sync ("around the time of")
with the unblock.

This bug exists to manually block any src:win32-loader migration without a
manual sync from FTP masters.

It'll be updated to be marked "found" in the latest version, and "notfound"
in any version allowed to migrate.

Best, for the win32-loader maintainers,
  OdyX

Bug#972339: armhf: hpcups crashes with free() invalid pointer for some printers

[Didier 'OdyX' Raboud]

Control: tags -1 +help

Hello there Paul,

Le jeudi, 11 février 2021, 16.55:09 h CET Paul Gevers a écrit :
> On Fri, 16 Oct 2020 14:23:59 +0200 Didier 'OdyX' Raboud wrote:
> > According to the 3.20.9-3 armhf auutopkgtest run for migration testing;
> > https://ci.debian.net/data/autopkgtest/testing/armhf/h/hplip/7460676/log.g
> > z
> > 
> > hpcups sometimes crashes with free(): invalid pointer. For instance, it
> > seems that setting up a 'drv:///hpcups.drv/hp-officejet_pro_1150c.ppd'
> > printer will let hpcups crash.
> 
> Just to have the information for the release process, do you think this
> is a regression compared to buster, or did you just found out now
> because of autopkgtest?

I found out because of autopkgtest only. I think it's a real bug (printing a 
test PDF to a specific printer should naturally work), unlikely to be fixed by 
upstream (we carry 77 patches, none of which ever got merged), on a non-
classical architecture. It's very likely not a regression from buster, but I 
couldn't formally confirm this.

> Is there any progress on this issue?

No, and I don't expect to make progress myself there; my C-fu is way too 
limited.

I hope that helps, and sure hope you're well!

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#981394: sane-airscan: zzz

[Didier 'OdyX' Raboud]

Control: retitle -1 sane-airscan: missing dependency on sane-utils
Control: severity -1 important
Control: tags -1 +pending 

Le samedi, 30 janvier 2021, 15.13:25 h CET Brian Potkin a écrit :
> On a system without a SANE frontend or libsane1, sane-airscan is
> effectively useless. I reckon there should be a Depends: on at
> least sane-utils.
> 
> I hope the severity level is not over the top.

Hello there Brian, and thanks for this bug report!

traditionally, dependencies go "top-down"; from tools to libraries, and from 
generic utils to backends, not in reverse. For example, libsane1 is 
effectively useless on its own on my laptop; and it doesn't depend on sane-
utils.

So, this missing dependency doesn't
* makes the package in question unusable by most or all users, or
* causes data loss, or
* introduces a security hole allowing access to the accounts of users who use
  the package
(definition of the "grave" severity).

It _does_ make it a no-op, and useless, but not "unuseable", I'd argue. Also, 
the side-effect of a "grave" severity is that it makes the package subject to 
auto-removal from the next stable release, as "release-critical bug". In other 
words, such a severity marks a package as unfit for release (== the release 
would be better off without this package, rather than with this bug). For all 
these reasons, an "important" severity seems much more adequate (to me).

All this said, I think it's a valid bug, and I'll therehore add a sane-utils 
"Recommends"; this will pull it by default, but not enforce it.

Best regards,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#972339: armhf: hpcups crashes with free() invalid pointer for some printers

[Didier 'OdyX' Raboud]

Control: forwarded -1 https://bugs.launchpad.net/hplip/+bug/1901209

Le vendredi, 23 octobre 2020, 09.42:59 h CEST Didier 'OdyX' Raboud a écrit :
> As this is testable at build-time, I'll add a test for this and upload this
> to experimental. I'll report this to upstream today.

Damn. It seems the bug doesn't trigger in buildd environments. I have also 
tried building hplip on the abel.debian.org porterbox, and the build-time test 
doesn't fail there.

So it seems that there's a reproductible bug when run:
- in qemu
- in ci.debian.net's 
- in a sid chroot in abel.debian.org

… but not:
- in a buildd build;
- in a manual build in abel.debian.org.

I'm wondering what makes the build process immune to that error.

The attached script will fail in a sid chroot on armhf, and I have reported 
this to the upstream bugtracker at
https://bugs.launchpad.net/hplip/+bug/1901209

-- 
OdyX

test_972339.sh
Description: application/shellscript


signature.asc
Description: This is a digitally signed message part.

Bug#972339: armhf: hpcups crashes with free() invalid pointer for some printers

[Didier 'OdyX' Raboud]

Control: found -1 3.20.5+dfsg0-3
Control: tags -1 +bullseye +upstream

Le vendredi, 16 octobre 2020, 14.23:59 h CEST Didier 'OdyX' Raboud a écrit :
> According to the 3.20.9-3 armhf auutopkgtest run for migration testing;
> https://ci.debian.net/data/autopkgtest/testing/armhf/h/hplip/7460676/log.gz
> 
> hpcups sometimes crashes with free(): invalid pointer. For instance, it
> seems that setting up a 'drv:///hpcups.drv/hp-officejet_pro_1150c.ppd'
> printer will let hpcups crash.
> 
> I'd welcome assistance here as I'm no C gdb fluent person.

So.

This bug can be reproduced by the following suite of  commands on armhf:

  $ export PPD=./prnt/hp-officejet_pro_1150c.ppd.gz
  $ /usr/lib/cups/filter/pdftopdf   1 debian '' 1 '' 
print_step_1.pdf
  $ /usr/lib/cups/filter/gstoraster 1 debian '' 1 '' print_step_2.raster
  $ /usr/lib/cups/filter/hpcups 1 debian '' 1 '' print_step_3.hpcups

As I have confirmed that this is also _already_ a bug in the current bullseye
version, I'll mark this RC bug as affecting the corresponding versions, and
I'll upload a version without the autopkgtest to unstable, to let this version
migrate.

As this is testable at build-time, I'll add a test for this and upload this to 
experimental. I'll report this to upstream today.

Cheers,

OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#972339: armhf: hpcups crashes with free() invalid pointer for some printers

[Didier 'OdyX' Raboud]

Package: printer-driver-hpcups
Version: 3.20.9+dfsg0-3
Severity: serious
Tags: upstream help

According to the 3.20.9-3 armhf auutopkgtest run for migration testing;
https://ci.debian.net/data/autopkgtest/testing/armhf/h/hplip/7460676/log.gz

hpcups sometimes crashes with free(): invalid pointer. For instance, it
seems that setting up a 'drv:///hpcups.drv/hp-officejet_pro_1150c.ppd'
printer will let hpcups crash.

I'd welcome assistance here as I'm no C gdb fluent person.

  
-- Package-specific info:

-- System Information:
Debian Release: bullseye/sid
  APT prefers buildd-unstable
  APT policy: (990, 'buildd-unstable'), (500, 'unstable-debug'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (100, 
'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.8.0-3-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_CH:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages printer-driver-hpcups depends on:
ii  cups 2.3.3-3
ii  cups-filters [ghostscript-cups]  1.28.5-1
ii  libc62.31-4
ii  libcups2 2.3.3-3
ii  libdbus-1-3  1.12.20-1
ii  libgcc-s110.2.0-15
ii  libhpmud03.20.9+dfsg0-3
ii  libjpeg62-turbo  1:2.0.5-1.1
ii  libstdc++6   10.2.0-15
ii  zlib1g   1:1.2.11.dfsg-2

printer-driver-hpcups recommends no packages.

Versions of packages printer-driver-hpcups suggests:
pn  hplip  
pn  hplip-doc  

-- no debconf information

Bug#957884: #957884 trousers: ftbfs with GCC-10

[Didier 'OdyX' Raboud]

Control: tags -1 +patch

 Hello there,

 my simple-tpm-pk11 package is threatened by a removal of testing because of 
the trousers FTBFS. So here comes a patch proposal (from an upstream patch over 
at 
https://sourceforge.net/p/trousers/trousers/ci/c9b8c4434f3b11bae4f7e72c3aec5b4f3459eecc/
 ).

 Unfortunately, it means removing two symbols from the library, but that feels 
safe as according to https://codesearch.debian.net/search?q=tcsd_sa_chld they 
are not in use.

 I'm likely to upload this to DELAYED/$n soon. I'll mail the bug again when I 
do.

 Cheers,
 Didier


trousers_0.3.14+fixed1-1.1.debdiff
Description: Binary data

Bug#957096: marked as pending in colobot

[Didier 'OdyX' Raboud]

Control: tag -1 pending

Hello,

Bug #957096 in colobot reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/games-team/colobot/-/commit/cf0563e8d0b3583f2f107e47764b213d4fa885ee


Backport upstream 'fix missing std includes' patch, fixing FTBFS with GCC-10

Closes: #957096


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/957096

Bug#952105: marked as pending in planetblupi

[Didier 'OdyX' Raboud]

Control: tag -1 pending

Hello,

Bug #952105 in planetblupi reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/games-team/planetblupi/-/commit/d00242ce65cb608190a0eb61fe83a6f8d404c21a


Don't assume that SDL2 headers are in /usr/include/SDL2

Closes: #952105


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/952105

Bug#952763: One-page print jobs to foo2zjs printers are empty

[Didier 'OdyX' Raboud]

Package: cups-filters
Version: 1.27.1-1
Severity: serious
Tags: bullseye

1.27.1 is affected by a serious bug, fixed in 1.27.2:

- foomatic-rip: Zero-page-job handling changes made the last
  page of PostScript files not printed, also turning one-page
  jobs into zero-page jobs (Issue #200, Issue #206, Issue
  #208, Pull request #209, Pull request #210, Pull request
  #211).

As maintainer, I'm therefore filing this bug to let the BTS know, and
accelerate the transition of fixed versions.

I'll send the -done immediately when I get the bugnumber.

Bug#952269: nsis: FTBFS: dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 2

[Didier 'OdyX' Raboud]

Le dimanche, 23 février 2020, 14.24:13 h CET Lucas Nussbaum a écrit :
> Source: nsis
> Version: 3.05-1
> Severity: serious
> Justification: FTBFS on amd64
> (…)
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> Relevant part (hopefully):
> > make[1]: Entering directory '/<>'
> > scons -c  VERSION=3.05-1 VER_MAJOR=3 VER_MINOR=05 VER_REVISION=1
> > PREFIX=/usr PREFIX_CONF=/etc CHMDOCS=0 STRIP_CP=no  UNICODE=yes
> > SKIPUTILS=zip2exe 2>&1 scons: Reading SConscript files ...
> > Mkdir("build/urelease/config")
> > Delete("nsis-3.05-1")
> > Delete(".instdist")
> > Delete(".test")
> > Using GNU tools configuration
> > Checking for linker flag $MAP_FLAG... yes
> > Checking for linker flag $MAP_FLAG... yes
> > Checking for memcpy requirement... no
> > Checking for memset requirement... no
> > Checking for linker flag -pthread... yes
> > Checking for __BIG_ENDIAN__... no
> > i686-w64-mingw32-gcc --version
> > i686-w64-mingw32-gcc (GCC) 8.3-win32 20191201
> > Copyright (C) 2018 Free Software Foundation, Inc.
> > This is free software; see the source for copying conditions.  There is NO
> > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> > PURPOSE.
> > 
> > g++ --version
> > g++ (Debian 9.2.1-29) 9.2.1 20200220
> > Copyright (C) 2019 Free Software Foundation, Inc.
> > This is free software; see the source for copying conditions.  There is NO
> > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> > PURPOSE.
> > 
> > Checking for C library gdi32... no
> > Checking for C library user32... no
> > Checking for C library pthread... yes
> > Checking for C library iconv... no
> > Checking for C library shlwapi... no
> > Checking for C library oleaut32... no
> > Checking for C library dl... yes
> > Checking for C library gdi32... no
> > Checking for C library iconv... no
> > Checking for C library pthread... yes
> > Checking for C library user32... no
> > Checking for C library oleaut32... no
> > Checking for C++ library cppunit... yes
> > scons: done reading SConscript files.
> > scons: Cleaning targets ...
> > scons: done cleaning targets.
> > Removing autogenerated file .sconsign.dblite
> > Removing autogenerated directory .sconf_temp
> > rm -rf .sconf_temp .sconsign.dblite SCons/Tools/crossmingw.pyc build
> > config.log .test /<>/build/test rm -f Source/exehead/sconf.h
> > Source/version.h Source/defines.h config.log make[1]: Leaving directory
> > '/<>'
> > 
> >dh_clean
> >  
> >  dpkg-source -b .
> > 
> > dpkg-source: info: using source format '3.0 (quilt)'
> > dpkg-source: info: building nsis using existing ./nsis_3.05.orig.tar.gz
> > dpkg-source: info: using patch list from debian/patches/series
> > dpkg-source: error: cannot represent change to
> > SCons/Tools/__pycache__/crossmingw.cpython-37.pyc: binary file contents
> > changed dpkg-source: error: add
> > SCons/Tools/__pycache__/crossmingw.cpython-37.pyc in
> > debian/source/include-binaries if you want to store the modified binary
> > in the debian tarball dpkg-source: error: unrepresentable changes to
> > source
> > dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status
> > 2


Even after fixing this bug (pushed to the repo), I still can't manage to build 
NSIS:

scons: done reading SConscript files.
scons: Building targets ...
scons: *** Do not know how to make File target `install-utils' (/
<>/install-utils).  Stop.
scons: building terminated because of errors.
make[1]: *** [debian/rules:194: override_dh_auto_test-indep] Error 2

@Thomas: any idea?

OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#916178: roger-router-cli: missing dependency on cups

[Didier 'OdyX' Raboud]

Control: -1 +wontfix 
# No change is going to happen in CUPS

Le lundi, 20 janvier 2020, 09.25:11 h CET Gianfranco Costamagna a écrit :
> On Mon, 10 Dec 2018 23:29:14 +0100 Marc Lehmann wrote:
> > Package: roger-router-cli
> > Version: 1.8.14-2+b3
> > Severity: serious
> > Justification: Policy 3.5
> > 
> > Dear Maintainer,
> > 
> > roger-router-cli apparently depends on cups-daemon, but has no required
> > dependency on it. if only cups-client is installed, installation fails
> > because the daemon is not running:
> > 
> > Setting up roger-router-cli (1.8.14-2+b3) ...
> > lpadmin: Unable to connect to server: Bad file descriptor
> > 
> > dpkg: error processing package roger-router-cli (--configure):
> >  subprocess installed post-installation script returned error exit status
> >  1
> > 
> > I *guess* the fix would be to make the dependency on cups optional in the
> > post-install script somehow.
> 
> I think, that if cups provides a client that doesn't work without the
> corresponding daemon, its a cups bug.
> 
> If they provide a cups-client containing binaries (e.g. lpadmin) that works
> only with cups-daemon installed, maybe they can think about adding that
> dependency, or split them into a new subpackage, or something else (like
> fail less badly).

Absolutely not, no, sorry.

cups-client software works fine against non-local CUPS servers (see lpadmin's
-h option), so adding a cups-client dependency against cups-daemon would
impose a server on client-only setup. Quite like if firefox would grow a
dependency on Apache2.

> Not sure, but I have the feeling that reassigning to cups team is the right
> choice to do.

I'm not going to engage in reassign combat, but my understanding is that the
following code from roger-router-cli.postinst _assumes_ that a local CUPS
daemon is available (as no -h is specified):

if which lpadmin >/dev/null
then
lpadmin -p "Roger-Router-Fax" -E -v roger-cups:/ -P 
/usr/share/roger/roger-fax.ppd
fi

(from 
https://salsa.debian.org/debian/roger-router/blob/master/debian/roger-router-cli.postinst#L17
 )

If the postinst of roger-router-cli depends on a running, local, cups-daemon,
it has to grow a dependency on the daemon itself, and cups-client will not
grow that dependency.

I'm tagging this bug as wontfix in CUPS, feel free to remove that tag when
reassigning back to roger-router-cli.

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#948257: depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/var/tmp/mkinitramfs_N1a1Mk/lib/modules/5.4.0-1-amd64/modules.builtin.bin'

[didier]

Same problem on my computer

 kmod -V
kmod version 26
+XZ -ZLIB +LIBCRYPTO -EXPERIMENTAL

uname -ar
5.4.0-2-amd64 #1 SMP Debian 5.4.8-1 (2020-01-05) x86_64 GNU/Linux






On Mon, 06 Jan 2020 10:02:05 +0530 crvi  wrote:

> Package: kmod
> Version: 26+20191223-1
> Severity: important
>
> Dear Maintainer,
>
> * What led up to the situation?
>
> apt-get dist-upgrade
>
> * What exactly did you do (or not do) that was effective (or
> ineffective)?
>
> apt-get dist-upgrade
>
> * What was the outcome of this action?
>
> Processing triggers for initramfs-tools (0.135) ...
> update-initramfs: Generating /boot/initrd.img-5.4.0-1-amd64
> depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could
not open
> builtin file
> '/var/tmp/mkinitramfs_DRc0S1/lib/modules/5.4.0-1-amd64/modules.builtin.bin
> depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could
not open
> builtin file
> '/var/tmp/mkinitramfs_DRc0S1/lib/modules/5.4.0-1-amd64/modules.builtin.bin
> depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could
not open
> builtin file
> '/var/tmp/mkinitramfs_DRc0S1/lib/modules/5.4.0-1-amd64/modules.builtin.bin
>
> * What outcome did you expect instead?
>
> Successful ramfs generation
>
>
>
> -- System Information:
> Debian Release: bullseye/sid
> APT prefers unstable-debug
> APT policy: (500, 'unstable-debug'), (500, 'unstable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.4.0-1-amd64 (SMP w/1 CPU core)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en
(charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages kmod depends on:
> ii libc6 2.29-8
> ii libkmod2 26+20191223-1
> ii liblzma5 5.2.4-1+b1
> ii libssl1.1 1.1.1d-2
> ii lsb-base 11.1.0
>
> kmod recommends no packages.
>
> kmod suggests no packages.
>
> -- no debconf information

Bug#946561: Bug #946561

[Didier 'OdyX' Raboud]

Control: severity -1 important
Control: tags -1 +moreinfo

Le mercredi, 11 décembre 2019, 21.04:58 h CET Stefano Fabri a écrit :
> Try to apt-get install hplip when you have in the system python >=3.8
> (https://packages.debian.org/experimental/python3).
> 
> In this status hplip is not installable.

Well. Your bugreport still is not actionable for me as maintainer. What do you 
see on-screen when you do this installation combination (ideally in a 
terminal)? When you say "not installable", what exactly do you mean?

OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#943549: dymo-cups-drivers FTBFS: ../common/CupsPrintEnvironment.cpp:139:23: error: ‘cupsBackChannelRead’ was not declared in this scope

[Didier 'OdyX' Raboud]

Control: tags -1 +pending

Le samedi, 26 octobre 2019, 11.20:34 h CET Helmut Grohne a écrit :
> Source: dymo-cups-drivers
> Version: 1.4.0-8
> Severity: serious
> Tags: ftbfs
> 
> dymo-cups-drivers fails to build from source in unstable using sbuild on
> amd64. 

Indeed, thanks for the bug Helmut.

The fix is straightforward and uploaded :-)

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#875190: [shiboken] Future Qt4 removal from Buster

[Didier 'OdyX' Raboud]

Le mardi, 1 octobre 2019, 09.20:40 h CEST Raphael Hertzog a écrit :
> On Tue, 01 Oct 2019, Didier 'OdyX' Raboud wrote:
> > > There are no reverse dependencies of src:shiboken in unstable and it has
> > > been replaced by src:pyside2, let's remove from the archive?
> > 
> > As maintainer: agreed!
> 
> Can you file the RM request then?

Thanks for the reminder; I had not re-read the bug's context.

Filed as #941469.

-- 
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#875190: [shiboken] Future Qt4 removal from Buster

[Didier 'OdyX' Raboud]

Le lundi, 30 septembre 2019, 22.04:05 h CEST Moritz Mühlenhoff a écrit :
> On Sat, Sep 09, 2017 at 11:09:45PM +0200, Lisandro Damián Nicanor Pérez 
Meyer wrote:
> > Source: shiboken
> > Version: 1.2.2-5
> > Severity: wishlist
> > User: debian-qt-...@lists.debian.org
> > Usertags: qt4-removal
> > 
> > 
> > Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
> > as [announced] in:
> > 
> > [announced]
> > 
> > 
> > Currently Qt4 has been dead upstream and we are starting to have problems
> > maintaining it, like for example in the [OpenSSL 1.1 support] case.
> > 
> > [OpenSSL 1.1 support]
> > 
> > 
> > In order to make this move, all packages directly or indirectly depending
> > on the Qt4 libraries have to either get ported to Qt5 or eventually get
> > removed from the Debian repositories.
> > 
> > Therefore, please take the time and:
> > - contact your upstream (if existing) and ask about the state of a Qt5
> > port of your application
> > - if there are no activities regarding porting, investigate whether there
> > are suitable alternatives for your users
> > - if there is a Qt5 port that is not yet packaged, consider packaging it
> > - if both the Qt4 and the Qt5 versions already coexist in the Debian
> > archives, consider removing the Qt4 version
> 
> There are no reverse dependencies of src:shiboken in unstable and it has
> been replaced by src:pyside2, let's remove from the archive?

As maintainer: agreed!

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#940127: ghostscript makes c2esp autopkgtest timeout

[Didier 'OdyX' Raboud]

Le dimanche, 22 septembre 2019, 13.25:19 h CEST Brian Potkin a écrit :
> On Sat 21 Sep 2019 at 17:39:20 +0200, Didier 'OdyX' Raboud wrote:
> > Le samedi, 21 septembre 2019, 16.24:30 h CEST Brian Potkin a écrit :
> > > > There's clearly a regression in ghostscript 9.28 that started
> > > > segfaulting
> > > > in the c2esp filter chain. But I can't manage to reproduce it outside
> > > > of
> > > > the "cups + c2esp + cups-filters (gstoraster) + ghostscript"
> > > > environment.
> > > > 
> > > > Brian; Till: any idea?
> > > 
> > > No ideas from me really. I too get gstoraster stopping when attempting
> > > to print /usr/share/cups/data/form_russian.pdf; but the same is true for
> > > form_english.pdf.
> > 
> > Ah, sorry; I formulated my inquiry weakly. Let me try again:
> > 
> > Do you have a hint on how to reproduce the failing ghostscript call (or
> > the
> > gstoraster call) directly, without using CUPS in the middle?
> 
> Would this do?
> 
> cat /usr/share/cups/data/form_russian.pdf | gs -dQUIET -dPARANOIDSAFER
> -dNOPAUSE -dBATCH -dNOINTERPOLATE -dNOMEDIAATTRS -dShowAcroForm
> -sstdout=%stderr -sOutputFile=%stdout -sDEVICE=cups -r600x600
> -dDEVICEWIDTHPOINTS=595 -dDEVICEHEIGHTPOINTS=842 -dcupsBitsPerColor=8
> -dcupsColorOrder=0 -dcupsColorSpace=4 -scupsPageSizeName=A4
> -I/usr/share/cups/fonts -c '< 3.00] /Margins[00]>>setpagedevice' -f -_ > out.ras

The problem is… This doesn't segfault. :-(

-- 
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#940127: ghostscript makes c2esp autopkgtest timeout

[Didier 'OdyX' Raboud]

Le samedi, 21 septembre 2019, 16.24:30 h CEST Brian Potkin a écrit :
> > There's clearly a regression in ghostscript 9.28 that started segfaulting
> > in the c2esp filter chain. But I can't manage to reproduce it outside of
> > the "cups + c2esp + cups-filters (gstoraster) + ghostscript" environment.
> > 
> > Brian; Till: any idea?
> 
> No ideas from me really. I too get gstoraster stopping when attempting
> to print /usr/share/cups/data/form_russian.pdf; but the same is true for
> form_english.pdf.

Ah, sorry; I formulated my inquiry weakly. Let me try again:

Do you have a hint on how to reproduce the failing ghostscript call (or the 
gstoraster call) directly, without using CUPS in the middle?

signature.asc
Description: This is a digitally signed message part.

Bug#940127: ghostscript makes c2esp autopkgtest timeout

[Didier 'OdyX' Raboud]

t;
D [21/Sep/2019:09:20:30 +0200] [Job 2201] envp[25]=\"PRINTER=test-printer0\"
D [21/Sep/2019:09:20:30 +0200] [Job 2201] 
envp[26]=\"PRINTER_STATE_REASONS=none\"
D [21/Sep/2019:09:20:30 +0200] [Job 2201] envp[27]=\"CUPS_FILETYPE=document\"
D [21/Sep/2019:09:20:30 +0200] [Job 2201] 
envp[28]=\"FINAL_CONTENT_TYPE=application/vnd.cups-raster\"
D [21/Sep/2019:09:20:30 +0200] [Job 2201] envp[29]=\"AUTH_INFO_REQUIRED=none\"
D [21/Sep/2019:09:20:30 +0200] [Job 2201] Start rendering...
D [21/Sep/2019:09:20:30 +0200] [Job 2201] Set job-printer-state-message to 
"Start rendering...", current level=INFO
D [21/Sep/2019:09:20:30 +0200] [Job 2201] Processing page 1...
D [21/Sep/2019:09:20:30 +0200] [Job 2201] Set job-printer-state-message to 
"Processing page 1...", current level=INFO
D [21/Sep/2019:09:20:31 +0200] [Job 2201] PID 11684 
(/usr/lib/cups/filter/gstoraster) stopped with status 1.


Using snapshot.debian.org:

* ghostscript 9.27~dfsg-3.1 works
* ghostscript 9.28~~rc1~dfsg-1 and all the later versions segfault

So…

There's clearly a regression in ghostscript 9.28 that started segfaulting in
the c2esp filter chain. But I can't manage to reproduce it outside of the
"cups + c2esp + cups-filters (gstoraster) + ghostscript" environment.

Brian; Till: any idea?

Cheers,
Didier

signature.asc
Description: This is a digitally signed message part.

Bug#934957: cups: multiple security issues (including CVEified CVE-2019-8675 and CVE-2019-8696)

[Didier 'OdyX' Raboud]

clone -1 -2
reassign -2 release.debian.org
retitle -2 buster-pu: package cups/2.2.10-6+deb10u1
user release.debian@packages.debian.org
usertags -1 pu
clone -1 -3
reassign -3 release.debian.org
retitle -3 stretch-pu: package cups/2.2.1-8+deb9u3
user release.debian@packages.debian.org
usertags -3 opu
thanks

Le samedi, 17 août 2019, 11.34:01 h CEST Salvatore Bonaccorso a écrit :
> Filling for tracking. The recent 2.2.12[1] release includes fixes for
> several security issues, two of those got CVEs and are related to SNMP
> buffer overflows. [2] includes all those.

This was fixed in unstable through the CUPS minor release.

The Security Team declined to fix these in a security upload, so let's fix 
these in stable point releases. I'll prepare patches soon.

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#934957: cups: multiple security issues (including CVEified CVE-2019-8675 and CVE-2019-8696)

[Didier 'OdyX' Raboud]

Control: tags -1 +pending

Le samedi, 17 août 2019, 11.34:01 h CEST Salvatore Bonaccorso a écrit :
> Filling for tracking. The recent 2.2.12[1] release includes fixes for
> several security issues, two of those got CVEs and are related to SNMP
> buffer overflows. [2] includes all those.

I had already gotten informed by Apple, and had forwarded the notice to the 
Security Team, but thanks for the report, it pinged me to do the actual 
upload.

Do you (or the security team) need assistance to prepare the buster/stretch 
packages? These should be pretty straightforward. As for the jessie packages, 
I'd probably need to take a closer look, but do you need me to? :-) 

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#921558: lsb-base: killproc does not pass name parameter to start-stop-daemon

[Didier 'OdyX' Raboud]

Le mercredi, 13 mars 2019, 18.17:34 h CET Dmitry Bogatov a écrit :
> [2019-03-11 21:51] Axel Beckert 
> > > I believe it would be reasonable to add '--name $base' into `else'
> > > clause. Opinions?
> > 
> > Sounds sane, I just checked that with #924311 (miredo, uses
> > start-stop-daemon directly, edited the init script) as well as #924312
> > (stunnel4, by editing /lib/lsb/init-functions) and it worked in both
> > cases.
> > 
> > Here's the change I made to /lib/lsb/init-functions (as Dmitry already
> > suggested):

Great. Thanks for the tests, you got me convinced. :-)

> Okay. Should I NMU or not? Anybody know what is the current status of
> maintenance?

I'll upload tonight, crediting the patch to Dmitry.

Regarding the maintenance status of src:lsb: I'm only keeping an (opinionated) 
eye on it, to avoid having it orphaned (hence my upload of tonight). But 
really, it is up for adoption. I should perhaps make that clearer by removing 
myself from uploader. Opinions?

Cheers, and thanks again for the testing!

OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#921558: lsb-base: killproc does not pass name parameter to start-stop-daemon

[Didier 'OdyX' Raboud]

Hi there Andreas,

Le mercredi, 6 février 2019, 20.20:54 h CET Andreas Metzler a écrit :
> there is a logic error in /lib/lsb/init-functions's killproc:
> 
> base=${1##*/}
> if [ ! $pidfile ]; then
> name_param="--name $base --pidfile /var/run/$base.pid"
> else
> name_param="--pidfile $pidfile"
> fi

This is there since 3.2-20, 10+ years ago:

In 2.0-5 (2005-01-30):
if [ ! $pidfile ]; then
pidfile=/var/run/$(basename "$1").pid

fi

In 3.0-11 (2005-10-27):
base=$(basename "$1")
if [ ! $pidfile ]; then
pidfile=/var/run/$base.pid
fi

In 3.1-20 (2006-11-16):
"Don't use --name in killproc() when a pidfile is provided (Closes: #397977)"

base=${1##*/}
if [ ! $pidfile ]; then
pidfile=/var/run/$base.pid
name_param="--name $base"
fi

In 3.2-16 (2008-08-01):
"Fix behavior of killproc and pidofproc when no pidfile is passed in."

base=${1##*/}
if [ ! $pidfile ]; then
name_param="--name $base"
else
name_param="--pidfile $pidfile"
fi

In 3.2-20 (2008-08-18):
"pidofproc now also checks for /var/run/$base.pid if -p is not specified, 
fixing conformance with the spec."

base=${1##*/}
if [ ! $pidfile ]; then
name_param="--name $base --pidfile /var/run/$base.pid"
else
name_param="--pidfile $pidfile"
fi

I'm just pointing out that it's an old bug; and that makes me uncomfortable to 
fix it, especially for a shell script installed on virtually _all_ Debian 
hosts.

> The if clause checks for nonempty $pidfile instead of nonempty $base to
> decide whether --name is used.
> 
> Also --pidfile $pidfile is always used, even when $pidfile is empty.

… but arguably, the code is bogus. :-)

(Will answer to other points down the thread)

Cheers,
OdyX

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Didier 'OdyX' Raboud]

Le lundi, 25 février 2019, 14.58:09 h CET Didier 'OdyX' Raboud a écrit :
> I call for vote immediately on the following resolution.
> 
> === Resolution ===
> 
> The Technical Committee resolves to decline to override the debootstrap
> maintainers.
> 
> Furthermore, using its §6.1.5 "Offering advice" power, the Technical
> Committee considers that the desirable solution at the time of `bullseye`
> is:
> 
> * W: `weak`: both directory schemes are allowed, but packages should only
>  be built on hosts with classical directory schemes (or in such
>  chroots)
> 
> * M: `middle`: both directory schemes are allowed, and packages (including
>official packages) can be built on hosts with either
> classical or "merged `/usr`" directory schemes
> 
> * H: `hard`: both directory schemes are allowed, but packages should only
>  be built on hosts with "merged `/usr`" directory schemes (or in
> such chroots)
> 
> * FD: Further Discussion
> 
> === End Resolution ===

Dear all,

with 6 votes in, and one week gone, the outcome of this vote is still in 
doubt; here's an abstract of the vote calculation (a clearsigned verbose 
version is attached):

/--WMHF
V: 3214 odyx
V: 2134 bremner
V: 4213 gwolf
V: 3124 ntyni
V: 2134 marga
V: 4213 fil
  Option
  W M H F 
===   ===   ===   === 
Option W0 2 4 
Option M  6   3 6 
Option H  4 3   6 
Option F  2 0 0   

Option W Reached quorum: 4 >= 2
Option M Reached quorum: 6 >= 2
Option H Reached quorum: 6 >= 2

Option W passes Majority.   2.000 (4/2) > 1

  Option M defeats Option W by (   6 -0) =6 votes.
  Option H defeats Option W by (   4 -2) =2 votes.
  Option W defeats Option F by (   4 -2) =2 votes.
  Option M defeats Option F by (   6 -0) =6 votes.
  Option H defeats Option F by (   6 -0) =6 votes.

- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

The winners are:
 Option M `middle`
 Option H `hard`

- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=


So. We have a tie, and the voting period is over. I am quite confident we can 
neither continue discussing (FD lost to M and H unanimously, and to W by 2), 
nor allow smcv to vote (the voting period is over). We're left with the 
Chair's casting vote (as per §6.3.2). So…

Dear Marga, as Chair, could you please make use of your casting vote to break 
this tie?

Cheers,
OdyX-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Starting results calculation at Mon Mar  4 15:34:31 2019

/--WMHF
V: 3214 odyx
V: 2134 bremner
V: 4213 gwolf
V: 3124 ntyni
V: 2134 marga
V: 4213 fil
Option W "`weak`: both directory schemes are allowed, but packages should only 
be built on hosts with classical directory schemes (or in such chroots)"
Option M "`middle`: both directory schemes are allowed, and packages (including 
official packages) can be built on hosts with either classical or "merged 
`/usr`" directory schemes"
Option H "`hard`: both directory schemes are allowed, but packages should only 
be built on hosts with "merged `/usr`" directory schemes (or in such chroots)"
Option F "Further Discussion"

In the following table, tally[row x][col y] represents the votes that
option x received over option y.

  Option
  W M H F 
===   ===   ===   === 
Option W0 2 4 
Option M  6   3 6 
Option H  4 3   6 
Option F  2 0 0   



Looking at row 2, column 1, M
received 6 votes over W

Looking at row 1, column 2, W
received 0 votes over M.

Option W Reached quorum: 4 >= 2
Option M Reached quorum: 6 >= 2
Option H Reached quorum: 6 >= 2


Option W passes Majority.   2.000 (4/2) > 1


  Option M defeats Option W by (   6 -0) =6 votes.
  Option H defeats Option W by (   4 -2) =2 votes.
  Option W defeats Option F by (   4 -2) =2 votes.
  Option M defeats Option F by (   6 -0) =6 votes.
  Option H defeats Option F by (   6 -0) =6 votes.


The Schwartz Set contains:
 Option M "`middle`: both directory schemes are allowed, and packages 
(including official packages) can be built on hosts with either classical or 
"merged `/usr`" directory schemes"
 Option H "`hard`: both directory schemes are allowed, but packages 
should only be built on hosts with "merged `/usr`" directory schemes (or in 
such chroots)"



- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

The winners are:
 

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Didier 'OdyX' Raboud]

Le lundi, 25 février 2019, 14.58:09 h CET Didier 'OdyX' Raboud a écrit :
> === Resolution ===
> 
> The Technical Committee resolves to decline to override the debootstrap
> maintainers.
> 
> Furthermore, using its §6.1.5 "Offering advice" power, the Technical
> Committee considers that the desirable solution at the time of `bullseye`
> is:
> 
> * W: `weak`: both directory schemes are allowed, but packages should only
>  be built on hosts with classical directory schemes (or in such
>  chroots)
> 
> * M: `middle`: both directory schemes are allowed, and packages (including
>official packages) can be built on hosts with either
>classical or "merged `/usr`" directory schemes
> 
> * H: `hard`: both directory schemes are allowed, but packages should only
>  be built on hosts with "merged `/usr`" directory schemes (or in
>  such chroots)
> 
> * FD: Further Discussion
> 
> === End Resolution ===

I vote:

H > M > W > FD

OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Didier 'OdyX' Raboud]

Dear Technical Committee members,

I call for vote immediately on the following resolution.

=== Resolution ===

The Technical Committee resolves to decline to override the debootstrap
maintainers.

Furthermore, using its §6.1.5 "Offering advice" power, the Technical
Committee considers that the desirable solution at the time of `bullseye` is:

* W: `weak`: both directory schemes are allowed, but packages should only
 be built on hosts with classical directory schemes (or in such
 chroots)

* M: `middle`: both directory schemes are allowed, and packages (including
   official packages) can be built on hosts with either classical
   or "merged `/usr`" directory schemes

* H: `hard`: both directory schemes are allowed, but packages should only
 be built on hosts with "merged `/usr`" directory schemes (or in
 such chroots)

* FD: Further Discussion

=== End Resolution ===



=== Rationale ===

## What is "merged `/usr`"

"Merged `/usr`" describes a possible future standard directories scheme in
which the `/{bin,sbin,lib*}/` directories have been made superfluous through
replacing them by symlinks to their `/usr` equivalents
(`/usr/{bin,sbin,lib*}`).
The motivation to get Debian systems to converge towards such a scheme is
vastly documented elsewhere ([FDO's TheCaseForTheUsrMerge][0],
[wiki.d.o UsrMerge][1]) but can be summarized as the following points:

* having separate `/` and `/usr` filesystems has been useful in the past for
booting without initramfs onto a minimal root filesystem that carried just
enough to mount the `/usr` filesystem later in the boot process. Given the
evolution of physical hosts' capabilities, initramfs'es have been default in
Debian (and elsewhere) for a long time, and most systems no longer have an
intermediate state during boot in which they have only `/`, but not `/usr`,
mounted. Booting hosts through that intermediate state is not systematically
tested in Debian anymore.
* another use-case is to share system files from `/usr` between hosts (over a
network link) or containers (locally) which use different data or
configuration. Having all software under `/usr` (instead of spread between
`/` and `/usr`) makes the centralized update and the sharing easier.
* the packaging infrastructure to install files outside of `/usr` (e.g.
installing libs under `/lib` instead of `/usr/lib`) is not standard and
represents technical debt.
* given its status as remnant "folklore", the distinction between what
_needs_ to be shipped in `/` and what can stay in `/usr` is often interpreted
arbitrarily;
* allowing shipment of identically-named libraries or binaries in different
paths can confuse common understanding of paths precedence.

[0]: https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
[1]: https://wiki.debian.org/UsrMerge

The arguments against moving the base directories' scheme towards "merged
`/usr`" are as follows:

* there's no gain in disrupting something that is not inherently broken;
* `/{bin,sbin,lib*}/` → `/usr/{bin,sbin,lib*}/` symlinks create confusing
views of the system (`/bin/cat` and `/usr/bin/cat` are the same file), and
dpkg doesn't support this situation cleanly:
[#134758](https://bugs.debian.org/134758).
* it is possible for distributions to converge towards having all system
files in `/usr` in finite time instead of shortcutting this migration with
`/{bin,sbin,lib*}/` → `/usr/{bin,sbin,lib*}/` symlinks.

The compatibility symbolic links `/lib` → `/usr/lib` and `/lib64` →
`/usr/lib64` are required by the various CPUs' platform ABIs (for example
i386 requires `/lib/ld-linux.so.2` to resolve to glibc's `ld.so`, and amd64
requires `/lib64/ld-linux-x86-64.so.2`) so there are no plans to remove them
altogether. Similarly, removing `/bin` is not under consideration because it
would break the assumption that `/bin/sh` exists, and removing `/sbin` would
break the assumption that `/sbin/fsck.*` and `/sbin/mount.*` exist.

## "merged `/usr`" in Debian

In Debian buster, the current testing suite, "merged `/usr`" is only
considered for implementation with symlinks (there are no proposals for
simply dropping `/{bin,sbin,lib*}`) and is implemented in two main ways:

* existing hosts can be made to have a "merged `/usr`" by installing the
[usrmerge][2] package;
* new hosts get the `/{bin,sbin,lib*}/`→ `/usr/{bin,sbin,lib*}/` symlinks
by default when using debootstrap >= 1.0.102.

The usrmerge package contains a `/usr/lib/convert-usrmerge` perl executable
that runs in `postinst`, that will move the contents of `/{bin,sbin,lib*}/`
and replace these directories with symlinks when empty.

It is also possible to merge `/usr` in other ways, for example with
`debootstrap --merged-usr` or by bootstrapping into a chroot that already
contains the necessary symlinks.

[2]: https://tracker.debian.org/pkg/usrmerge

## Issues from "merged `/usr`"

Since the default change in debootstrap 1.0.102, some issues 

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Didier 'OdyX' Raboud]

(Corrected the recipients, these mails should go to the bug).

Le lundi, 25 février 2019, 14.23:31 h CET Didier 'OdyX' Raboud a écrit :
> Le samedi, 23 février 2019, 12.12:13 h CET Niko Tyni a écrit :
> > > * B: The desireable solution at the time of bullseye is `hard`; both
> > > directory schemes should be allowed, and packages can be built on hosts
> > > with either classical or "merged-`/usr`" directory schemes.
> > 
> > Isn't this the 'middle' option above rather than 'hard'?
> 
> Actually, it's both.  The only difference between 'middle' and 'hard' is
> that in 'middle', _official_ packages can be built on either directory
> schemes, where in 'hard', they are only built on "merged-`/usr`" directory
> schemes.
> 
> The distinction I was trying to make in the table is the following:
> 
> * on which directory scheme Debian would build its "official" packages on
> (columns 5 & 6) ; 'weak' is "classical directory scheme", 'middle' is
> "both", 'hard' is "merged-/usr".
> * whether .debs built on A can break on B (columns 7 & 8).  All of 'weak',
> 'middle' and 'hard' long-term statuses allow .debs to be built from either
> directory scheme and be installed on either without constraints

Wrong, actually (hit send too fast). The intent behind 'weak' was: "merged-/
usr" is allowed, but packages built on these directory schemes can break on 
classical directory schemes.

So that should have read:

* whether .debs built on A can break on B (columns 7 & 8). 'middle' and 'hard' 
long-term statuses allow .debs to be built from either directory scheme and be 
installed on either without constraints; 'weak' permits "merged-/usr" 
directory schemes, but packages built there can break on classical directory 
schemes.

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Didier 'OdyX' Raboud]

Le jeudi, 21 février 2019, 15.28:23 h CET Ian Jackson a écrit :
> Back in the wider world, of course many people build packages on
> Debian systems for installation `somewhere else'.  I have done it
> myself and probably many of the people reading this message have too.
> 
> What is implicitly going on here is that it is mostly-tacitly[2] being
> assumed (or declared) that `I built this .deb on my laptop[1] and gave
> it to my friend' is wrongheaded.

I don't think it is wrongheaded, but I do think that assuming that it is meant 
to work consistently under any circumstances, is.  There are _so many_ 
circumstances that make this exercise error-prone:

"I built this amd64 .deb and gave it to my friend for use on their RasbperryPi 
arm64 host"

"I built this .deb on my laptop on which I had installed a /usr/local/bin/
grep"

"I built this .deb an gave it to my friend who runs CentOS"

etc
 
> I don't think doing that is wrongheaded.  Certainly it is extremely
> common; we don't have any public pronouncements saying it is somehow
> wrong; and we have had little discussion where we as a project decided
> that this was now a use case which we feel free to just break.

Frankly, while it's not _broken_ per se, it is and has always really been 
fragile.  True, merged-/usr arguably worsens _one_ aspect of building packages 
on one's host, but in ways that are really easy to detect, and warn for.

> Personally I think that this is a very important thing to keep
> working.  It is the very core of users' collective software freedom.

You seem to be conflating "building on one's host" with "outside of any 
chroot", and equating this with "users' collective software freedom" is really 
making your point a disservice.  Being able to improve, build and share binary 
artifacts of free software is _vital_, and the whole point of building 
software distributions in the first place, but insisting that these rights are 
only "truly" exercised when builds are done outside of chroots is 
disingenuine. .deb packages already have to be built using certain tools, so 
we do set the limit (of what minimal set of tools are mandatory) somewhere, 
and my point is that this limit might not be at the right place. I'd be 
totally OK with saying "the only supported way to build .deb packages from 
buster on is using by pdebuild; however, you _can_ use dpkg-buildpackage 
alone, but be aware (and you'll get warnings) that this can lead to building 
.deb packages with undesireable properties."  The second half of the sentence 
is already true, and has always been; we probably just failed at communicating 
it sufficiently clearly.

> And that software freedom needs to be easy to exercise in practice.
> Despite a lot of excellent tooling, chroots are still not entirely
> trivial to set up and maintain.

Then that's maybe what we should be fixing.  

> I would invite the TC to read this manpage, which is trying to explain
> to a Debian user how to change the programs on their own computer
>   https://manpages.debian.org/stretch-backports/dgit/dgit-user.7.en.html
> and then consider how much even worse it would be if we had to write
> about chroots too.

Perhaps dpkg-buildpackage should be grown to build in a chroot by default? Or 
get an option to do that?

Really, I think we should stop considering that .debs built outside of 
"controlled environments" are more than temporary software transports. Our 
"standard" package building tools should build in such environments by 
default.

> To TC members who are minded to uphold the current approach, I would
> ask: can you please explicitly state your opinion on this ?  That is:
> 
>   Is it OK for a Debian user to build .deb on their laptop and give it
>   to their friend ?

Yes; provided that said .deb is built in a sane (sanitized / controlled) 
environment.  As you're talking about non-chroot builds; it is OK, provided 
that the tools warn about that. In that area, I think the "Build-Tainted-By" 
are steps in the right direction.

>   If it is OK, how will we make sure that it does not pointlessly break ?

As it is already broken in many ways, your question is biased. But I think the 
good way is to normalize "proper builds", by making sure our standard tools 
"do the right thing" by default.

> I readily admit that there are many ways that this can produce a
> result significantly different to the official Debian package,
> particularly because the package build system may configure itself
> differently in the the presence of unexpected.  The resulting package
> is probably not going to be suitable for wide distribution.
> 
> But those kind of problems are (a) not serious in practice
> (b) generally have obvious symptoms and (c) are easily worked around
> by various means.  Working around a usrmerge-generated failure is
> difficult; it usually involves doing serious violence to the upstream
> build system, or perhaps horrific rules file bodges.

Given a Build-Tainted-By flag in the binary 

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Didier 'OdyX' Raboud]

Le mardi, 19 février 2019, 01.59:18 h CET Steve McIntyre a écrit :
> While I'm not necessarily disagreeing with the overall point(s) here,
> some of the points in this list of arguments seem dubious at
> best. Maybe you could expand?

Sure. Sorry for publishing a new ballot before answering.

> >* booting with `/` only is not systematically tested in Debian anymore;
> 
> I'm assuming you mean "/ without /usr" here?

Yes. Clarified this point by merging it with the "separate / and /usr" one 
above.

> >* the packaging infrastructure to install files outside of `/usr` is not
> >  standard and represents technical debt:
> 
> I have no idea what you're suggesting here.

Same here (clarified in the ballot). What I'm trying to say here is that 
installing (e.g.) libs to /lib instead of /usr/lib is usually a deviation from 
standard software building (either in upstream packaging, or in debian/rules), 
that needs to be maintained on the long-term.

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Didier 'OdyX' Raboud]

Le lundi, 18 février 2019, 08.58:53 h CET Didier 'OdyX' Raboud a écrit :
> Dear Technical Committee members,
> (CC'ed to submitter, and debootstrap maintainers for information and
> feedack)
> 
> Here's the current state of the draft resolution; which `master` is at
> https://salsa.debian.org/debian/tech-ctte/blob/master/914897_merged_usr/ball
> ot.md
> 
> I will submit it to vote on Friday 22.; the discussion period is open!

Thank you for the various comments. I have amended the ballot (which is more a
"explanation text + short ballot" incorporating the suggestions from the IRC
meeting as well as taking into accounts remarks on this bug.

I intend to answer some mails on that bug, and call for a vote on Sunday I
guess.

See: 
https://salsa.debian.org/debian/tech-ctte/blob/master/914897_merged_usr/ballot.md
for the markdown-rendered version; and below:

# #914897: tech-ctte: Should debootstrap disable merged `/usr` by default?

## What is "merged `/usr`"

"Merged `/usr`" describes a possible future standard directories scheme in
which the `/{bin,sbin,lib*}/` directories have been made superfluous through
replacing them by symlinks to their `/usr` equivalents
(`/usr/{bin,sbin,lib*}`).
The motivation to get Debian systems to converge towards such a scheme is
vastly documented elsewhere ([FDO's TheCaseForTheUsrMerge][0],
[wiki.d.o UsrMerge][1]) but can be summarized as the following points:

* having separate `/` and `/usr` filesystems has been useful in the past for
booting without initramfs onto a minimal root filesystem that carried just
enough to mount the `/usr` filesystem later in the boot process. Given the
evolution of physical hosts' capabilities, initramfs'es have been default in
Debian (and elsewhere) for a long time, and most systems no longer have an
intermediate state during boot in which they have only `/`, but not `/usr`,
mounted. Booting hosts through that intermediate state is not systematically
tested in Debian anymore.
* another use-case is to share system files from `/usr` between hosts (over a
network link) or containers (locally) which use different data or
configuration. Having all software under `/usr` (instead of spread between `/`
and `/usr`) makes the centralized update and the sharing easier.
* the packaging infrastructure to install files outside of `/usr` (e.g.
installing libs under `/lib` instead of `/usr/lib`) is not standard and
represents technical debt.
* given its status as remnant "folklore", the distinction between what _needs_
to be shipped in `/` and what can stay in `/usr` is often interpreted
arbitrarily;
* allowing shipment of identically-named libraries or binaries in different
paths can confuse common understanding of paths precedence.

[0]: https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
[1]: https://wiki.debian.org/UsrMerge

The arguments against moving the base directories' scheme towards
"merged `/usr`" are as follows:

* there's no gain in disrupting something that is not inherently broken;
* `/{bin,sbin,lib*}/` → `/usr/{bin,sbin,lib*}/` symlinks create confusing
views of the system (`/bin/cat` and `/usr/bin/cat` are the same file), and
dpkg doesn't support this situation cleanly:
[#134758](https://bugs.debian.org/134758).
* it is possible for distributions to converge towards having all system files
in `/usr` in finite time instead of shortcutting this migration with
`/{bin,sbin,lib*}/` → `/usr/{bin,sbin,lib*}/` symlinks.

The compatibility symbolic links `/lib` → `/usr/lib` and `/lib64` →
`/usr/lib64` are required by the various CPUs' platform ABIs (for example i386
requires `/lib/ld-linux.so.2` to resolve to glibc's `ld.so`, and amd64
requires `/lib64/ld-linux-x86-64.so.2`) so there are no plans to remove them
altogether. Similarly, removing `/bin` is not under consideration because it
would break the assumption that `/bin/sh` exists, and removing `/sbin` would
break the assumption that `/sbin/fsck.*` and `/sbin/mount.*` exist.

## "merged `/usr`" in Debian

In Debian buster, the current testing suite, "merged `/usr`" is only
considered for implementation with symlinks (there are no proposals for simply
dropping `/{bin,sbin,lib*}`) and is implemented in two main ways:

* existing hosts can be made to have a "merged `/usr`" by installing the
[usrmerge][2] package;
* new hosts get the `/{bin,sbin,lib*}/`→ `/usr/{bin,sbin,lib*}/` symlinks by
default when using debootstrap >= 1.0.102.

The usrmerge package contains a `/usr/lib/convert-usrmerge` perl executable
that runs in `postinst`, that will move the contents of `/{bin,sbin,lib*}/`
and replace these directories with symlinks when empty.

It is also possible to merge `/usr` in other ways, for example with
`debootstrap --merged-usr` or by bootstrapping into a chroot that already
contains the necessary symlinks.

[2]: https://tracker.debian.org/pkg/usrmerge

## Issues f

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Didier 'OdyX' Raboud]

Dear Technical Committee members,
(CC'ed to submitter, and debootstrap maintainers for information and feedack)

Here's the current state of the draft resolution; which `master` is at
https://salsa.debian.org/debian/tech-ctte/blob/master/914897_merged_usr/ballot.md

I will submit it to vote on Friday 22.; the discussion period is open!

# #914897: tech-ctte: Should debootstrap disable merged `/usr` by default?

## What is "merged `/usr`"

"Merged `/usr`" describes a possible future standard directories scheme in
which the `/{bin,sbin,lib*}/` directories have been made superfluous through
replacing them by symlinks to their `/usr` equivalents (/usr/{bin,sbin,lib*}).
The motivation to get Debian systems to converge towards such a scheme is
vastly documented elsewhere ([FDO's TheCaseForTheUsrMerge][0],
[wiki.d.o UsrMerge][1]) but can be summarized as the following points:

* having separate `/` and `/usr` filesystems has been useful in the past for
  booting without initramfs onto a minimal root filesystem that carried just
  enough to mount the `/usr` filesystem later in the boot process. Given the
  evolution of physical hosts' capabilities, initramfs'es have been default in
  Debian (and elsewhere) for a long time, and most systems no longer have an
  intermediate state during boot in which they have only `/`, but not `/usr`,
  mounted.
* another use-case is to be able to share an identical `/usr` over a network
  link; hence booting an initramfs, mounting a local `/`, then mounting `/usr`
  over the network. It seems that an initramfs with everything needed to mount
  a filesystem over a network link directly actually has a smaller footprint.
* booting with `/` only is not systematically tested in Debian anymore;
* the packaging infrastructure to install files outside of `/usr` is not
  standard and represents technical debt:
* given its status as remnant "folklore", the distinction between what _needs_
  to be shipped in `/` and what can stay in `/usr` is often interpreted
  arbitrarily;
* allowing shipment of identically-named libraries or binaries in different
  paths can confuse common understanding of paths precedence.

The arguments against moving the base directories' scheme towards
"merged `/usr`" are as follows:

* there's no gain in disrupting something that is not inherently broken;
* `/{bin,sbin,lib*}/` → `/usr/{bin,sbin,lib*}/` symlinks create confusing views
  of the system (`/bin/cat` and `/usr/bin/cat` are the same file), and dpkg
  doesn't support this situation cleanly
  [#134758](https://bugs.debian.org/134758).

[0]: https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
[1]: https://wiki.debian.org/UsrMerge

The compatibility symbolic links `/lib` → `/usr/lib` and
`/lib64` → `/usr/lib64` are required by the various CPUs' platform ABIs (for
example i386 requires `/lib/ld-linux.so.2` to resolve to glibc's `ld.so`, and
amd64 requires `/lib64/ld-linux-x86-64.so.2`) so there are no plans to remove
them altogether. Similarly, removing `/bin` is not under consideration because
it would break the assumption that `/bin/sh` exists, and removing `/sbin` would
break the assumption that `/sbin/fsck.*` and `/sbin/mount.*` exist.

## "merged `/usr`" in Debian

In Debian buster, the current testing suite, "merged `/usr`" is only considered
for implementation with symlinks (there are no proposals for simply dropping
`/{bin,sbin,lib*}`) and is implemented in two main ways:

* existing hosts can be made to have a "merged `/usr`" by installing the
  [usrmerge][2] package;
* new hosts get the `/{bin,sbin,lib*}/`→ `/usr/{bin,sbin,lib*}/` symlinks by
  default when using debootstrap >= 1.0.102.

The usrmerge package contains a `/usr/lib/convert-usrmerge` perl executable
that runs in `postinst`, that will move the contents of `/{bin,sbin,lib*}/` and
replace these directories with symlinks when empty.

It is also possible to merge `/usr` in other ways, for example with
`debootstrap --merged-usr` or by bootstrapping into a chroot that already
contains the necessary symlinks.

[2]: https://tracker.debian.org/pkg/usrmerge

## Issues from "merged `/usr`"

Since the default change in debootstrap 1.0.102, some issues have arisen.
Due to the fact that some buster/sid hosts have the "merged `/usr`" symlinks in
place, it has been observed that some binary packages carried some traces of
these differences (notably official packages built on Debian buildd hosts which
had been resetup).
Some such differences can actually render the built packages unuseable on
non-"merged `/usr`" systems.
For example, if `cat` is detected at build-time in `/usr/bin/cat` (where
coreutils ships `/bin/cat`), a binary hardcoding that path will try to use
`/usr/bin/cat` after installation, but that path doesn't exist in
non-"merged `/usr`" systems.
In order to mitigate this, debootstrap has been modified to let its "buildd"
variant be non-"merged `/usr`", the Debian buildds have been resetup and the
affected packages 

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Didier 'OdyX' Raboud]

Le samedi, 2 février 2019, 14.48:22 h CET Ian Jackson a écrit :
> Ping ?

Thank for the ping.

Gunnar and myself have started working on a draft, the latest version of which 
is available at

https://salsa.debian.org/debian/tech-ctte/blob/master/914897_merged_usr/
ballot.md

It's really work-in-progress, and hasn't had much scrutiny yet (hence why I'm 
not pasting it here).  I've started working on the various long-term 
desireable situations, but have realized I need to draw a table to wrap my 
head around this.

I hope to get it done during Monday (FOSDEM is not the ideal space+time to get 
the needed calm to think about these complex issues).

Cheers,
OdyX

Bug#916198: [piuparts] libpaper1 fails to purge: ucf not found

[Didier 'OdyX' Raboud]

Package: libpaper1
Version: 1.1.25
Severity: serious

piuparts detected that libpaper1 fails to purge, because its postrm
doesn't check that ucf is available during purge.

https://piuparts.debian.org/sid/fail/libpaper1_1.1.25.log

  Purging configuration files for libpaper1:amd64 (1.1.25) ...
  /var/lib/dpkg/info/libpaper1:amd64.postrm: 16: 
/var/lib/dpkg/info/libpaper1:amd64.postrm: ucf: not found
  dpkg: error processing package libpaper1:amd64 (--purge):
   installed libpaper1:amd64 package post-removal script subprocess returned 
error exit status 127
  Errors were encountered while processing:
   libpaper1:amd64
  
It should test for ucf's presence, for example as openssh does:

if which ucf >/dev/null 2>&1; then
ucf --purge /etc/ssh/sshd_config
fi

(This is serious as it affects all reverse dependencies of libpaper1 in their 
piuparts logs too)

Cheers,
OdyX

Bug#908147: restarting cups-browsed deleted print jobs

[Didier 'OdyX' Raboud]

Le mercredi, 5 décembre 2018, 22.49:57 h CET Till Kamppeter a écrit :
> cups-browsed is part of cups-filters, not of CUPS. The patch you find here:
> 
> https://github.com/OpenPrinting/cups-filters/commit/0d29084a864ca80ada8b4eaf
> c2d36f072e06f984

I'm uploading a fixed cups-filters with this patch cherry-picked "as we 
speak".

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#905674: GNU Parallel patch

[Didier 'OdyX' Raboud]

Control: clone -1 -2
Control: retitle -2 parallel 20161222-1.1 NMU removes upstream "--will-cite" 
functionality
Control: reopen -2
Control: notfound -2 20161222
Control: found -2 20161222-1.1
Control: severity -2 important

Dear Ole,

Le lundi, 3 décembre 2018, 18.55:00 h CET Ole Tange a écrit :
> I have noticed that you have submitted a patch and closed this bug:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905674#77
> 
> I am sure you are trying to do what is best for free software. But
> what looks like a good idea in the short run, may be a bad idea in the
> long run. The long term survival of Debian depends on others building
> free software that can be packaged, so destroying these people's
> livelihood is a bad long term strategy.
> 
> In the reasoning for the patch you state:
> > Quoting the gpl-faq:
> [... https://www.gnu.org/licenses/gpl-faq.en.html#RequireCitation ...]
> 
> > Therefore, removing this to make parallel GPL-compliant.
> 
> I think this is due to a misunderstanding.
> 
> Maybe you not aware that Richard M. Stallman together with the GNU
> leaders have cleared the wording and the use of the citation notice,
> and that he sees it as complying fully with GPLv3?

I was not, but, as Debian Developer, I don't feel bound by RMS' (and "GNU
leaders", whomever this designates) statements about GPLv3.  What mattered for
this now-closed bugreport is our DFSG; specifically it's article 1 (emphasis
mine) and 5.

> DFSG 1: Free Redistribution
> The license of a Debian component may not restrict any party from selling or
> giving away the software as a component of an aggregate software
> distribution containing programs from several different sources. The license
> *may not require a royalty or other fee* for such sale.

> DFSG 5: No Discrimination Against Persons or Groups
> The license must not discriminate against any person or group of persons.

Le lundi, 3 décembre 2018, 18.55:00 h CET Ole Tange a écrit :
> Your patch therefore does not change the GPLv3-compliancy: The code
> was already compliant.

I disagree; my understanding is that RMS declared parallel to carry no
problem with regards to GPLv3 compliance in October 2018, probably for the
latest upstream release.

But Debian ships parallel 20161222 which:
* contains a request for the user to promise academic citation,
* imposes the use of either "--will-cite" or the presence of a
  `~.parallel/will-cite`, which makes it unnecessarily burdensome to use
  in a scripted manner.

This is a clear attempt at side-stepping GPLv3 software freedoms by using
guilt-inducting language.  As the GPLv3 allows (almost any) modification, I've
just went and did that, also to ensure that src:parallel can stay in the
Debian main archive, where it belongs.

> But what your patch *does* do, is to make it harder to earn a living
> from developing GNU Parallel and will make it much harder for me to
> justify spending time maintaining GNU Parallel.

Be careful with such arguments: by merely distributing GNU parallel in its
main archive, Debian is also vastly expanding the availability of GNU
parallel.  And if you do insist on getting Debian to rename it, you'll
likely lose any incentive from "renamed GNU parallel" users getting it from
the Debian archive.

> As Nadia Eghbal puts it in
> https://www.slideshare.net/NadiaEghbal/consider-the-maintainer:
> 
> "Is it alright to compromise, or even deliberately ignore, the
> happiness of maintainers so we that can enjoy free and open source
> software?"
> 
> This describes very well what you are doing with the patch, and I
> refuse to think that was your goal.

For the record:
* My primary goal was to remove a "Release Critical" bug from Debian's next
  stable release, during a Bug Squashing Party;
* While looking at this bug, it seemed obvious to me that merely removing the
  obnoxious phrasing and functionality was an easy way to fix this bug; in a
  GPLv3- and DFSG-compatible way.
* I am not the Debian maintainer of src:parallel, so my contribution was one-
  -off.
* I did a Non-Maintainer Upload immediately, following DevRef 5.11.1:
  
https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#nmu-guidelines
* I do think that making fine free software unnecessarily cumbersome to use,
  only to increase user's knowledge of the original author's funding
  initiatives is bad practice.  This reduces the quality of software and
  is really on the line of what makes software really "free software"
  (I'm fine to disagree with RMS on that front).  Weaker phrasing doesn't
  make the intent any better.
* Prominent links or funding pitches are fine in _documentation_, as long as
  they:
  - don't imply that payment is mandatory;
  - don't impose citation;
  For instance, parallel 20161222 manpage's 
  > If you pay 1 EUR you should feel free to use GNU Parallel without 
citing.
  … is not acceptable IMHO.
* I am not a Debian FTP-master, in charge of specific interpretations of
  the DFSG.

> So if you 

Bug#858937: kde4libs: Please migrate to openssl1.1 in buster

[Didier 'OdyX' Raboud]

Le samedi, 1 décembre 2018, 15.33:37 h CET Sebastian Andrzej Siewior a écrit :
> On December 1, 2018 2:02:42 PM UTC, Didier 'OdyX' Raboud  
wrote:
> >So; to get the ball rolling on this RC bug:
> >
> >* I've prepared a Debian patch with it
> 
> If you switch to openssl-dev with this upload, please make it depend on
> libssl1.1 (which does not happen because it does not depend on any symbols)
> and the you could also close
> 
> #913959 [S|  |  ] [src:kde4libs] kde4libs: Build-Depends on libssl1.0-dev

I've checked thoroughly, and didn't find any package from src:kde4libs which 
has a relationship with libssl*; so I think this upload at least is no 
regression in that regard.

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#900160: closed by Didier Raboud (Bug#900160: fixed in ruby-eventmachine 1.0.7-4.1)

[Didier 'OdyX' Raboud]

Le dimanche, 2 décembre 2018, 23.18:38 h CET Sebastian Andrzej Siewior a écrit 
:
> On 2018-12-02 13:06:04 [+], Debian Bug Tracking System wrote:
> > #900160: ruby-eventmachine: FTBFS against openssl 1.1.1
> > 
> >  ruby-eventmachine (1.0.7-4.1) unstable; urgency=medium
> >  .
> >  
> >* Non-maintainer upload.
> >* Build-Depend against libssl1.0-dev; aka OpenSSL << 1.1
> >
> >  (Closes: #900160)
> 
> Please revert that one. We don't want more dependencies on
> libssl1.0-dev. We want it actually out of testing and are down to one
> package.

Which one?

> I wouldn't care much but since ruby-eventmachine is a key package it
> might migrate to testing…

That's exactly the point: porting ruby-eventmachine to work with OpenSSL 1.1 
is not easy and not done upstream.  An apparently it is not easily removable 
from Debian testing either.  Sure, removing OpenSSL 1.0 is important, but 
specifically for ruby-eventmachine, it's better to have one that builds (and 
works) instead of one that doesn't, especially as it's a dependency for lots 
of other software.

With these updated Build-Dependencies, at some point, the Release Team could 
"just" remove libssl1.0-dev (and all the reverse dependencies tree) from 
testing, thereby forcing the update of the concerned packages to depend (and 
work) on OpenSSL 1.1.

(Also, I can't revert the NMU, the package would not build :-) )

Cheers,
OdyX

Bug#897651: u1db: FTBFS against openssl 1.1.1

[Didier 'OdyX' Raboud]

Control: user debian-rele...@lists.debian.org
Control: usertag -1 +bsp-2018-12-ch-bern
Control: tags -1 +pending

Le jeudi, 3 mai 2018, 21.49:15 h CET Sebastian Andrzej Siewior a écrit :
> The new openssl 1.1.1 is currently in experimental [0]. This package
> failed to build against this new package [1] while it built fine against
> the openssl version currently in unstable [2].
> Could you please have a look?
> 
> The error
> 
> |OpenSSL.SSL.Error: [('SSL routines', 'SSL_CTX_use_certificate', 'ee key too
> |small')]
> is due to:
> 
> 1.1.1~~pre6-1 changelog):
> |   * Increase default security level from 1 to 2. This moves from the 80
> |   bit
> |   
> | security level to the 112 bit securit level and will require 2048 bit
> | RSA
> | and DHE keys.

Indeed; regenerating the test-keys with 4096bit keys makes the build pass.

I just NMUed u1db with the attached debdiff.

Cheers,
OdyXdiff -Nru u1db-13.10/debian/changelog u1db-13.10/debian/changelog
--- u1db-13.10/debian/changelog	2016-04-28 13:56:59.0 +0200
+++ u1db-13.10/debian/changelog	2018-12-02 15:46:45.0 +0100
@@ -1,3 +1,11 @@
+u1db (13.10-6.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Patch testsuite with regenerated 4096 bits RSA keys for OpenSSL 1.1 support
+(Closes: 897651)
+
+ -- Didier Raboud   Sun, 02 Dec 2018 15:46:45 +0100
+
 u1db (13.10-6.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru u1db-13.10/debian/patches/openssl-1.1-compatibility.patch u1db-13.10/debian/patches/openssl-1.1-compatibility.patch
--- u1db-13.10/debian/patches/openssl-1.1-compatibility.patch	1970-01-01 01:00:00.0 +0100
+++ u1db-13.10/debian/patches/openssl-1.1-compatibility.patch	2018-12-02 15:46:45.0 +0100
@@ -0,0 +1,374 @@
+Description: Replace old 1024bits certificates with 4096bits certificates for OpenSSL 1.1+ compatibility
+Author: Didier Raboud 
+Last-Update: 2018-12-02
+
+Bug-Debian: https://bugs.debian.org/897651
+
+--- a/u1db/tests/testing-certs/Makefile
 b/u1db/tests/testing-certs/Makefile
+@@ -13,7 +13,7 @@
+ 	echo 01>$(CATOP)/crlnumber
+ 	@echo ' Making CA certificate ...'
+ 	openssl req -nodes -new \
+-	 	-newkey rsa -keyout $(CATOP)/private/cakey.pem \
++		-newkey rsa:4096 -keyout $(CATOP)/private/cakey.pem \
+ 		-out $(CATOP)/careq.pem \
+ 		-multivalue-rdn \
+ -subj "/C=UK/ST=-/O=u1db LOCAL TESTING ONLY, DO NO TRUST/CN=u1db testing CA"
+--- a/u1db/tests/testing-certs/cacert.pem
 b/u1db/tests/testing-certs/cacert.pem
+@@ -2,57 +2,121 @@
+ Data:
+ Version: 3 (0x2)
+ Serial Number:
+-e4:de:01:76:c4:78:78:7e
+-Signature Algorithm: sha1WithRSAEncryption
++49:2a:ef:92:11:f4:d1:ce:24:7e:bd:26:a4:8a:74:20:7c:7a:67:5a
++Signature Algorithm: sha256WithRSAEncryption
+ Issuer: C=UK, ST=-, O=u1db LOCAL TESTING ONLY, DO NO TRUST, CN=u1db testing CA
+ Validity
+-Not Before: May  3 11:11:11 2012 GMT
+-Not After : May  1 11:11:11 2023 GMT
++Not Before: Dec  2 14:45:42 2018 GMT
++Not After : Nov 29 14:45:42 2029 GMT
+ Subject: C=UK, ST=-, O=u1db LOCAL TESTING ONLY, DO NO TRUST, CN=u1db testing CA
+ Subject Public Key Info:
+ Public Key Algorithm: rsaEncryption
+-Public-Key: (1024 bit)
++RSA Public-Key: (4096 bit)
+ Modulus:
+-00:bc:91:a5:7f:7d:37:f7:06:c7:db:5b:83:6a:6b:
+-63:c3:8b:5c:f7:84:4d:97:6d:d4:be:bf:e7:79:a8:
+-c1:03:57:ec:90:d4:20:e7:02:95:d9:a6:49:e3:f9:
+-9a:ea:37:b9:b2:02:62:ab:40:d3:42:bb:4a:4e:a2:
+-47:71:0f:1d:a2:c5:94:a1:cf:35:d3:23:32:42:c0:
+-1e:8d:cb:08:58:fb:8a:5c:3e:ea:eb:d5:2c:ed:d6:
+-aa:09:b4:b5:7d:e3:45:c9:ae:c2:82:b2:ae:c0:81:
+-bc:24:06:65:a9:e7:e0:61:ac:25:ee:53:d3:d7:be:
+-22:f7:00:a2:ad:c6:0e:3a:39
++00:af:51:11:ef:ce:49:b1:42:37:ef:60:e9:04:dd:
++c6:f9:d6:24:45:4c:30:f8:63:64:bc:df:67:ab:31:
++c5:8f:ec:c5:d3:85:68:4d:7e:43:ef:5b:c7:b0:1a:
++49:e4:93:a0:39:b0:18:bc:89:e2:fb:d0:aa:eb:58:
++53:09:af:d5:43:74:d0:83:ae:23:78:1e:1b:8a:b5:
++73:8e:fe:64:e1:ff:ea:96:89:b1:8d:22:8d:aa:45:
++ce:76:cb:23:e8:0b:b7:f2:4d:89:0c:75:ff:83:5f:
++d0:2c:cc:04:2e:0b:9d:f0:1e:21:9f:78:5e:a5:3d:
++9c:38:37:9d:e4:5a:e6:91:5f:78:f9:17:6f:f3:45:
++96:e7:39:8b:8c:41:38:59:f5:d5:07:a4:cb:ff:53:
++37:cc:a8:71:c9:97:4a:97:d2:61:27:ad:ec:a0:54:
++cf:3b:cc:8c:15:f8:e8:30:89:b3:fa:54:c1:b6:a3:
++e6:43:ca:fc:03:90:af:d2:92:50:ec:ba:5a:67:95:
++76:32:71:f6:

Bug#900160: ruby-eventmachine: FTBFS against openssl 1.1.1

[Didier 'OdyX' Raboud]

Control: user debian-rele...@lists.debian.org
Control: usertag -1 +bsp-2018-12-ch-bern
Control: clone -1 -2
Control: retitle -2 ruby-eventmachine: B-D against libssl1.0-dev
Control: severity -2 important
Control: tags -2 +help +upstream
Control: tags -1 +pending

Le jeudi, 4 octobre 2018, 15.38:39 h CET peter green a écrit :
> It seems that ruby-eventmachine has a hardcoded 1024 bit CA certificate and
> key, I tried replacing this with a 4096 bit one but the testsuite still
> failed, I then tried replacing the client cert in the test with one signed
> by the new CA but that didn't fix things either.

I've taken another look, and your patch gets rid of the first error; but then 
other errors trigger:

```
TestSslVerify: 
  test_accept_server: /build/ruby-eventmachine-1.0.7/tests/test_ssl_verify.rb:
64: warning: global variable `$cert_from_server' not initialized
F
```

This seems to indicate that the `ssl_verify_peer` method from the test Servers 
are just not called. If I comment these lines out, then the error becomes:

```
TestSslVerify: 
  test_accept_server:   F
===
Failure: test_accept_server(TestSslVerify):  is not true.
/build/ruby-eventmachine-1.0.7/tests/test_ssl_verify.rb:66:in 
`test_accept_server'
 63: 
 64: #assert_equal($cert_from_file, $cert_from_server)
 65: assert($client_handshake_completed)
  => 66: assert($server_handshake_completed)
 67:   end
 68: 
 69:   def test_deny_server
===
: (0.029365)
```

So it's really not working, even with bigger keys; deactivating the test is 
only going to hide the fact that SSL verification is broken.

I have also tried to build the current status of the VCS repository from 
https://salsa.debian.org/ruby-team/ruby-eventmachine but many other tests fail 
with that version too.

Finally, I have tried backporting various patches from upstream without luck; 
I felt mostly stabbing ghosts in the dark.

In Debian, the package seems very old (2015) and not maintained very actively; 
it should be updated or removed (but has too many reverse dependencies).

That said, the situation upstream doesn't look very bright either; upstream 
doesn't seem to test against OpenSSL 1.1 either:
https://travis-ci.org/eventmachine/eventmachine/jobs/414199579

But… One not too horrible way to fix this bug is to let ruby-eventmachine 
Build-Depend against libssl1.0-dev; thereby letting it build in unstable 
again, and documenting in its Build-Depends that it only builds against 
openssl << 1.1.

debdiff attached, package uploaded!

Cheers,
OdyXdiff -Nru ruby-eventmachine-1.0.7/debian/changelog ruby-eventmachine-1.0.7/debian/changelog
--- ruby-eventmachine-1.0.7/debian/changelog	2017-01-23 01:36:45.0 +0100
+++ ruby-eventmachine-1.0.7/debian/changelog	2018-12-02 13:44:21.0 +0100
@@ -1,3 +1,11 @@
+ruby-eventmachine (1.0.7-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Build-Depend against libssl1.0-dev; aka OpenSSL << 1.1
+    (Closes: #900160)
+
+ -- Didier Raboud   Sun, 02 Dec 2018 13:44:21 +0100
+
 ruby-eventmachine (1.0.7-4) unstable; urgency=medium
 
   * Team upload.
diff -Nru ruby-eventmachine-1.0.7/debian/control ruby-eventmachine-1.0.7/debian/control
--- ruby-eventmachine-1.0.7/debian/control	2017-01-23 01:36:45.0 +0100
+++ ruby-eventmachine-1.0.7/debian/control	2018-12-02 13:31:53.0 +0100
@@ -9,7 +9,7 @@
Per Andersson 
 Build-Depends: debhelper (>= 9~),
gem2deb,
-   libssl-dev,
+   libssl1.0-dev,
rake,
ruby-test-unit
 Standards-Version: 3.9.8


signature.asc
Description: This is a digitally signed message part.

Bug#914897: debootstrap, buster: Please disabled merged /usr by default

[Didier 'OdyX' Raboud]

Le dimanche, 2 décembre 2018, 00.23:05 h CET Andreas Henriksson a écrit :
> On Sat, Dec 01, 2018 at 07:20:57PM +0100, Didier 'OdyX' Raboud wrote:
> > * With my TC hat on, I have formally asked the debootstrap maintainers
> >   (and specifically Hideki Yamane) if they would consider a toggle of the
> >   default.
> > 
> > https://bugs.debian.org/914897#73
> 
> May I ask you to share why you did that? I'm interested to know the
> reasoning.

Sure. My reasoning is: as there's a non-zero probability for the TC to end up 
using it's "§6.1.4 Overrule a Developer" power, I want to make sure that:
* said developers are aware of the situation as presented to the TC;
* they are given explicit advance notice that the TC might end up using this
  power to overrule a decision of theirs;
* given the surrounding discussions (that they might not necessarily follow),
  I feel it's important to give them as much context as possible.

Both our understanding of the situation and the state of the discussion have 
changed since the decision at hand was taken (5+ months ago); I want to make 
sure that the TC would only overrule a _recent_ and _active_ decision of the 
debootstrap maintainers.  

In other words, if the debootstrap maintainers now agree with Ian about 
toggling the "merged-/usr" default back to false, there's really no point for 
the TC to overrule unnecessarily, or even continue discussing this.  And if 
they don't agree, their _current_ reasoning will provide value to the 
discussion, and ideally provide for a better TC decision.

OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#905674: Ready for closing?

[Didier 'OdyX' Raboud]

Control: tags -1 +pending

Le dimanche, 21 octobre 2018, 18.59:26 h CET Ole Tange a écrit :
> Upgrading from 20141022 to 20180922 seems to address all issues.
> 
> Can we close this ticket?

Live from the Bern BSP. 

I have taken a long look at this bugreport log, and have concluded that under 
GPL, Debian can as well just remove the concerned "parallel --citation" 
functionality, and keep "parallel" in Debian main.

I have therefore uploaded a DELAYED/0 NMU with version 20161222-1.1 fixing 
this bug through removal of all the citation mechanism. The full debdiff is 
attached.

Cheers,
OdyXdiff -Nru parallel-20161222/debian/changelog parallel-20161222/debian/changelog
--- parallel-20161222/debian/changelog	2016-12-31 14:24:10.0 +0100
+++ parallel-20161222/debian/changelog	2018-12-01 23:18:34.0 +0100
@@ -1,3 +1,11 @@
+parallel (20161222-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Update Vcs-* to point to salsa
+  * Remove citation requirements completely (Closes: #905674)
+
+ -- Didier Raboud   Sat, 01 Dec 2018 23:18:34 +0100
+
 parallel (20161222-1) unstable; urgency=medium
 
   [ Rogério Brito ]
diff -Nru parallel-20161222/debian/control parallel-20161222/debian/control
--- parallel-20161222/debian/control	2016-12-31 14:24:10.0 +0100
+++ parallel-20161222/debian/control	2018-12-01 21:08:59.0 +0100
@@ -10,8 +10,8 @@
texinfo
 Standards-Version: 3.9.6
 Homepage: https://www.gnu.org/software/parallel/
-Vcs-Git: https://anonscm.debian.org/git/collab-maint/parallel.git
-Vcs-Browser: https://anonscm.debian.org/cgit/collab-maint/parallel.git
+Vcs-Git: https://salsa.debian.org/debian/parallel.git
+Vcs-Browser: https://salsa.debian.org/debian/parallel
 
 Package: parallel
 Architecture: all
diff -Nru parallel-20161222/debian/patches/remove-overreaching-citation-request.patch parallel-20161222/debian/patches/remove-overreaching-citation-request.patch
--- parallel-20161222/debian/patches/remove-overreaching-citation-request.patch	1970-01-01 01:00:00.0 +0100
+++ parallel-20161222/debian/patches/remove-overreaching-citation-request.patch	2018-12-01 23:11:50.0 +0100
@@ -0,0 +1,169 @@
+Description: Remove overreaching citation notice
+ Quoting the gpl-faq:
+ .
+ > Does the GPL allow me to add terms that would require citation or
+ > acknowledgment in research papers which use the GPL-covered software or its
+ > output? (#RequireCitation)
+ > .
+ > No, this is not permitted under the terms of the GPL. While we recognize
+ > that proper citation is an important part of academic publications,
+ > citation cannot be added as an additional requirement to the GPL. Requiring
+ > citation in research papers which made use of GPL'd software goes beyond
+ > what would be an acceptable additional requirement under section 7(b) of
+ > GPLv3, and therefore would be considered an additional restriction under
+ > Section 7 of the GPL. And copyright law does not allow you to place such a
+ > requirement on the output of software, regardless of whether it is licensed
+ > under the terms of the GPL or some other license.
+ .
+ Therefore, removing this to make parallel GPL-compliant.
+
+Author: Didier Raboud 
+Bug-Debian: https://bugs.debian.org/905674
+
+Last-Update: 2018-12-01
+
+--- a/src/parallel
 b/src/parallel
+@@ -906,7 +906,6 @@
+ 	 "gnu" => \$opt::gnu,
+ 	 "link|xapply" => \$opt::link,
+ 	 "linkinputsource|xapplyinputsource=i" => \@opt::linkinputsource,
+-	 "bibtex|citation" => \$opt::citation,
+ 	 "wc|willcite|will-cite|nn|nonotice|no-notice" => \$opt::willcite,
+ 	 # Termination and retries
+ 	 "halt-on-error|halt=s" => \$opt::halt,
+@@ -1040,7 +1039,6 @@
+ print Limits::Command::real_max_length(),"\n"; wait_and_exit(0);
+ }
+ if(defined $opt::version) { version(); wait_and_exit(0); }
+-if(defined $opt::citation) { citation(); wait_and_exit(0); }
+ if(defined $opt::record_env) { record_env(); wait_and_exit(0); }
+ if(defined $opt::show_limits) { show_limits(); }
+ if(@opt::sshlogin) { @Global::sshlogin = @opt::sshlogin; }
+@@ -1181,7 +1179,6 @@
+ if(defined $opt::bar) {
+ $opt::progress = $opt::bar;
+ }
+-citation_notice();
+ 
+ parse_halt();
+ parse_sshlogin();
+@@ -3801,43 +3798,9 @@
+ 	 "  O. Tange (2011): GNU Parallel - The Command-Line Power Tool,",
+ 	 "  ;login: The USENIX Magazine, February 2011:42-47.",
+ 	 "",
+-	 "This helps funding further development; AND IT WON'T COST YOU A CENT.",
+-	 "If you pay 1 EUR you should feel free to use GNU Parallel without citing.",
+-	 "",
+ 	 "",);
+ }
+ 
+-sub citation_notice {
+-# if --will-cite or --plain: do nothing
+-# if stderr redirected: do nothing
+-# if ~/.parallel/will-cite:

Bug#914897: debootstrap, buster: Please disabled merged /usr by default

[Didier 'OdyX' Raboud]

Le samedi, 1 décembre 2018, 19.29:59 h CET Marc Haber a écrit :
> This might sound like a stupid question, what will happen when a package
> built on a usrmerged System will be installed on a non-usrmerged system?

FTR, I try to always assume that no question is stupid.  Only answers can be.

My understanding is that there's no universal answer to this; for a lot of 
packages, the answer is "nothing"; it will just work.  For some packages 
though, if they embed executable paths such as /usr/bin/grep where only
/bin/grep exists on the host system, this will break.

> Will binaries move from /usr/bin to /bin? Or will binaries move from
> /bin to /usr/bin?

A merged-/usr has a /bin → /usr/bin symlink; so a .deb package unpacking
/bin/grep will make that binary end up in /usr/bin/grep; but the
/bin → /usr/bin symlink ensures that you can either access /usr/bin/grep  
directly or /bin/grep through the symlink.

An open question I think is whether dpkg should/could at one point in the 
future always unpack binaries to /usr/bin and never in /bin no matter what the 
package contains (+ setup a convenience symlink in /bin if /bin is a real dir 
?).

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#914897: debootstrap, buster: Please disabled merged /usr by default

[Didier 'OdyX' Raboud]

As a way to improve my understanding of the issue at hand, here's my current
collection of data points regarding the "merged-/usr" question:

* "merged-/usr" was enabled by default in debootstrap on June 13. 2018, some 
  5+ months ago. Any buster rootfs setup since has the /bin → /usr/bin 
  symlink (and other caracteristics of merged-/usr).


https://tracker.debian.org/news/965045/accepted-debootstrap-10102-source-all-into-unstable/

* With my TC hat on, I have formally asked the debootstrap maintainers
  (and specifically Hideki Yamane) if they would consider a toggle of the
  default.

https://bugs.debian.org/914897#73

* a discussion "usrmerge -- plan B?" was started on Nov. 20 on debian-
  devel@l.d.o

https://lists.debian.org/20181120211617.gxnuwxpx2hy44...@angband.pl
  
  It apparently follows #913229, #914204 and others.

* Currently, according to my `apt-file`, 259 binaries are shipped in /bin
  directly, accross 85 packages. (for /sbin, 597 binaries for 190 packages).

* There exists a 'usrmerge' package since 2015, which transforms a rootfs with 
  separate /{bin,sbin,lib} into a "merged-usr/" rootfs.  It has had 28 bugs 
  over its lifetime; of which 4 are currently open.  After successful 
  "installation" (when the postinst successfully ran the
  /usr/lib/convert-usrmerge program), /{bin,sbin,lib} are made symlinks and 
  the package can be removed.  The package doesn't include a way to revert the
  rootfs to its previous state.

* Building source packages in a merged-/usr rootfs can make the resulting
  binary packages broken in non-merged-/usr rootfs'es, because they'd be 
  embedding references to /usr/bin/grep (e.g.), which don't exist in non-
  merged-/usr rootfs'es.  To ensure this doesn't happen for packages built on 
  Debian infrastructure, debootstrap has been updated to disable merged-/usr 
  for the `buildd` variant (and buildd chroots have been rebuilt).

* According to investigation done thanks to reproducible builds (which now
  also varies the merged-/usr state of the build rootfs), and by others,
  packages affected by this problem have begun receiving either 
  reproducibility issue tags or Debian bugs:


https://tests.reproducible-builds.org/debian/issues/unstable/paths_vary_due_to_usrmerge_issue.html
(currently: 59)


https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=m...@linux.it;tag=usrmerge
(current total: 81; outstanding: 17)

I'll post my thoughts separately; please enhance or correct the above data
as needed!

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#858937: kde4libs: Please migrate to openssl1.1 in buster

[Didier 'OdyX' Raboud]

Control: user debian-rele...@lists.debian.org
Control: usertag -1 +bsp-2018-12-ch-bern
Control: tags -1 +patch +pending

On Fri, 16 Nov 2018 10:07:08 +0100 Emilio Pozuelo Monfort  wrote:
> > this is a remainder about the openssl transition [0]. We really want to
> > remove libssl1.0-dev from unstable for Buster. I will raise the severity
> > of this bug to serious in a month. Please react before that happens.
> 
> This is the last blocker for the openssl 1.0 removal from testing.
> 
> There is a patch at [1], could you look into using it?
>
> [1]
> https://src.fedoraproject.org/rpms/kdelibs/blob/
d68bdeabf80bf618b085bfb914c17153115e7e36/f/kdelibs-4.14.38-openssl-1.1.patch

Jumping in from Bern's BSP. :-)

I've imported the patch from Emilio's link; which:
- is originally from upstream's kde4libs4support repository (by Daniel Vrátil 
  , on 2017-10-17):

https://cgit.kde.org/kdelibs4support.git/commit/?
id=9a990c69c606126bcd60cd7718462aec2a92460d

- was backported to Fedora by Wolfgang Bauer  on 2017-10-25,
  and integrated there by Kevin Kofler  on 2018-01-05:

https://src.fedoraproject.org/rpms/kdelibs/c/
a4a16201d5f09c6aeb443eeeb823c4e44896014a?branch=master

  It is integrated since their 4.14.38-2 kdelibs package.

So; to get the ball rolling on this RC bug:

* I've prepared a Debian patch with it and pushed it to my salsa fork:

https://salsa.debian.org/qt-kde-team/kde/kde4libs/merge_requests/1/commits
* Hereattached is the debdiff I propose;
* I have uploaded this update to DELAYED/5.

Thanks for your consideration!

Cheers,
OdyXdiff -Nru kde4libs-4.14.38/debian/changelog kde4libs-4.14.38/debian/changelog
--- kde4libs-4.14.38/debian/changelog	2018-07-28 10:39:03.0 +0200
+++ kde4libs-4.14.38/debian/changelog	2018-12-01 14:29:23.0 +0100
@@ -1,3 +1,12 @@
+kde4libs (4:4.14.38-3) unstable; urgency=medium
+
+  * Team upload
+  * Build against OpenSSL 1.1 (Closes: #858937)
+- use Fedora-provided patch backport by Daniel Vrátil and Wolfgang Bauer
+- In Build-Depends, replace libssl1.0-dev by "libssl-dev (>= 1.1)"
+
+ -- Didier Raboud   Sat, 01 Dec 2018 14:29:23 +0100
+
 kde4libs (4:4.14.38-2) unstable; urgency=medium
 
   * Team upload.
diff -Nru kde4libs-4.14.38/debian/control kde4libs-4.14.38/debian/control
--- kde4libs-4.14.38/debian/control	2018-07-28 10:39:03.0 +0200
+++ kde4libs-4.14.38/debian/control	2018-12-01 14:29:07.0 +0100
@@ -39,7 +39,7 @@
libqt4-opengl-dev (>= 4:4.8.0),
libqtwebkit-dev,
libsm-dev,
-   libssl1.0-dev,
+   libssl-dev (>= 1.1),
libudev-dev [linux-any],
libutempter-dev,
libxml2-dev,
diff -Nru kde4libs-4.14.38/debian/patches/kdelibs-4.14.38-openssl-1.1.patch kde4libs-4.14.38/debian/patches/kdelibs-4.14.38-openssl-1.1.patch
--- kde4libs-4.14.38/debian/patches/kdelibs-4.14.38-openssl-1.1.patch	1970-01-01 01:00:00.0 +0100
+++ kde4libs-4.14.38/debian/patches/kdelibs-4.14.38-openssl-1.1.patch	2018-12-01 14:25:25.0 +0100
@@ -0,0 +1,984 @@
+From a015996bb55bbd63d94b227a2c82d0d97cd86ae8 Mon Sep 17 00:00:00 2001
+From: Wolfgang Bauer 
+Date: Wed, 25 Oct 2017 07:49:32 +0200
+Subject: [PATCH] Make kssl compile against OpenSSL 1.1.0
+
+OpenSSL 1.1.0 contains some source-incompatible changes, most notably
+making most of the structures opaque and introducing new getter/setter
+functions to modify the structures. This patch adds some of the newly
+introduced functions to the KOpenSSL class and modifies the code to
+call them. The implementation of those newly introduced methods
+contains both OpenSSL < 1.1 compatible code (direct structure member
+access) and calls to real functions resolved from OpenSSL>= 1.1
+library. Which implementation is used is decided at compile time. Some
+of the existing methods were renamed to match the OpenSSL 1.1 naming
+and to avoid conflicts with backward-compatibility names provided by
+OpenSSL 1.1.
+
+KSSLCertificate::toNetscape() returns empty result when built against
+OpenSSL 1.1 since I wasn't able to find a proper equivalent in OpenSSL
+1.1 API (and there does not seem to be any).
+
+(Backport of commit 9a990c69c606126bcd60cd7718462aec2a92460d from
+kdelibs4support)
+---
+ kio/kssl/kopenssl.cpp| 250 ++-
+ kio/kssl/kopenssl.h  |  80 --
+ kio/kssl/kssl.cpp|   4 -
+ kio/kssl/ksslcallback.c  |   6 +-
+ kio/kssl/ksslcertchain.cpp   |  53 +++--
+ kio/kssl/ksslcertificate.cpp |  68 +++-
+ 6 files changed, 351 insertions(+), 110 deletions(-)
+
+--- a/kio/kssl/kopenssl.cpp
 b/kio/kssl/kopenssl.cpp
+@@ -75,18 +75,26 @@
+ static int (*K_X509_verify_cert) (X509_STORE_CTX *) = 0L;
+ static X509_STORE_CTX *(*K_X509_STORE_CTX_new) (void) = 0L;
+ static void (*K_X509_STORE_free) (X509_STORE *) = 0L;
++sta

Bug#915153: gutenprint: FTBFS: ../../scripts/ylwrap: line 176: yacc: command not found

[Didier 'OdyX' Raboud]

Le samedi, 1 décembre 2018, 09.06:09 h CET Andreas Beckmann a écrit :
> the last upload FTBFS everywhere with
> 
> ../../scripts/ylwrap: line 176: yacc: command not found
> make[4]: *** [Makefile:714: printrcy.c] Error 127
> 
> https://buildd.debian.org/status/package.php?p=gutenprint=experimental

Oah. You're either very fast, or automated. :-)

I'm in the Bern BSP; uploaded before going to sleep (for too short) and I wake 
up with a bug; nice!

Thanks for the bug, I'll upload a fix (after build-testing in a schroot this 
time) soon.

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#914897: #914897: debootstrap, buster: Please disabled merged /usr by default

[Didier 'OdyX' Raboud]

Dear Hideki, dear src:debootstrap maintainers,

tl;dr: debootstrap maintainers; can you agree to disable "merged /usr" by 
default now, or are you OK letting the TC decide on this subject?

Longer version:

As you might be aware, #914897 (initially filed on src:debootstrap) has now 
been reassigned to the Technical Committee.  As, formally, the Maintainer of 
src:debootstrap is "debian-boot@l.d.o and the current Uploaders", I would like 
to make sure that the TC is not going to overrule unnecessarily.

Hideki, if I read the debootstrap history correctly, you enabled "merged /usr" 
by default in debootstrap 1.0.102.  Given the recent discussion in debian-
devel@ (starting at [0]) and on #914897, could you (or anyone speaking as with 
a "debootstrap maintainer" hat on) state if, either of:

* you would be willing to toggle the "merged /usr" default in debootstrap in a
  subsequent upload;
* you maintain that the "merged /usr" default (to yes) is here to stay.

Many thanks in advance for your consideration,

OdyX

[0] https://lists.debian.org/debian-devel/2018/11/msg00354.html

P.S. I'm aware that this might sound formal, or dismissive of Julien's
 statements.  I just _really_ don't want the TC to eventually overrule
 "the debootstrap maintainers" without need.

Bug#913578: printer-driver-postscript-hp: PPDs are missing

[Didier 'OdyX' Raboud]

Control: tags -1 +confirmed
Control: found -1 3.18.3+dfsg0-1

Le lundi, 12 novembre 2018, 16.00:46 h CET Brian Potkin a écrit :
> Package: printer-driver-postscript-hp
> Version: 3.18.10+dfsg0-2
> Severity: grave
> Justification: renders package unusable
> 
> Executing
> 
> /usr/lib/cups/driver/postscript-hp list
> 
> shows only four PPDs (all for Fax).

Right; this looks like a regression from 3.18.3+dfsg0-1 already, when printer-
driver-postscript-hp was made an arch:any package.

Will look into this…

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#907493: ghostscript breaks cups autopkgtest: test times out

[Didier 'OdyX' Raboud]

Le vendredi, 31 août 2018, 01.25:24 h CEST Jonas Smedegaard a écrit :
> Do the freshly released experimental Ghostscript release help anything?

It doesn't seem to, unfortunately. :-(

To reproduce the issue; just run this as root:
/usr/share/cups/test-drivers

Surprisingly; it will fail when testing the _second_ printer, always. Also, it 
doesn't seem to get fixed with the ghostscript from testing.

There's something fishy here, but I can't say with certainty that it's 
ghostscript's fault :-(

(No more time to investigate this today, sorry)

-- 
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#906345: Bug #906345 in colobot marked as pending

[Didier Raboud]

Control: tag -1 pending

Hello,

Bug #906345 in colobot reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below, and you can check the diff of the fix at:

https://salsa.debian.org/games-team/colobot/commit/83ab5358060faf561e20ac2f81fc41a23abdd5ca


Backport upstream-merged fix for GCC8 FTBFS

Closes: #906345



(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/906345

Bug#891498: Needs fog-core (~> 1.44.0), but ruby-fog-core is now 1.45.0

[Didier 'OdyX' Raboud]

Package: vagrant-libvirt
Version: 0.0.43-1
Severity: serious

Upon Debian Sid upgrade, vagrant (with vagrant-libvirt) became unuseable
with this error:

> Vagrant failed to initialize at a very early stage:
> 
> The plugins failed to initialize correctly. This may be due to manual
> modifications made within the Vagrant home directory. Vagrant can
> attempt to automatically correct this issue by running:
> 
>   vagrant plugin repair
> 
> If Vagrant was recently updated, this error may be due to incompatible
> versions of dependencies. To fix this problem please remove and re-install
> all plugins. Vagrant can attempt to do this automatically by running:
> 
>   vagrant plugin expunge --reinstall
> 
> Or you may want to try updating the installed plugins to their latest
> versions:
> 
>   vagrant plugin update
> 
> Error message given during initialization: Unable to resolve dependency: 
> 'vagrant-libvirt (> 0)' requires 'fog-core (~> 1.44.0)

That's because ruby-fog-core was recently upgraded to 1.45.0 in Debian 
Sid.

It seems that the .gemspec's dependencies need to be relaxed again. In
any case, the Depends in vagrant-libvirt should really have an
upper-version limit.

Bug#880721: FTBFS: fatal error: doctest/doctest.h: No such file or directory

[Didier 'OdyX' Raboud]

Control: reassign -1 src:doctest 1.2.5+repack0-2
Control: retitle -1 doctest-dev built without doctest.h
Control: affects -1 argagg

Le samedi, 4 novembre 2017, 14.27:07 h CET Andreas Moog a écrit :
> Source: argagg
> Severity: serious
> Justification: fails to build from source (but built successfully in the
> past)
> 
> argagg seems to FTBFS in a clean sid environment:

Oh. That's pretty bad. The doctest I uploaded just recently doesn't ship it's 
doctest.h anymore.

Reassigning; fix in progress.

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#784512: Is anybody working on PySide2?

[Didier 'OdyX' Raboud]

Le dimanche, 27 août 2017 16.53:30 h CEST, vous avez écrit :
> Hi,
> 
> python-ghost depends on pyside, which will be removed with Qt4.
> Upstream already ported to pyside2, but I can't find pyside2 in
> Debian, not even an ITP or RFP. But somewhere I read, that
> pyside2 will be part of Qt. Is somebody working on this? It
> would be bad to remove pyside from Debian before pyside2 is in
> place, right?

For what is worth: I'm not working on pyside, nor pyside2. I removed myself 
from both shiboken and pyside's uploader fields (but should really have mailed 
debian-python about that earlier).

Cheers,
OdyX

Bug#871917: hplip-gui: hp-toolbox will not start

[Didier 'OdyX' Raboud]

Le samedi, 12 août 2017, 18.17:51 h EDT Brad Rogers a écrit :
> Actually, that info is in my original bug report, but wy too far
> down.  I hadn't realised just how much info reportbug had put in place.
> I'll know to check next time.

Nah, I should have checked, don't worry.

Cheers,
OdyX

Bug#868743: gutenprint FTBFS on mips64el: check-TESTS killed with signal TERM after 150 minutes of inactivity

[Didier 'OdyX' Raboud]

Control: severity -1 important
Control: retitle -1 gutenprint sometimes FTBFS on mips64el: check-TESTS killed 
with signal TERM after 150 minutes of inactivity

Le mardi, 18 juillet 2017, 11.05:34 h CEST Adrian Bunk a écrit :
> https://buildd.debian.org/status/fetch.php?pkg=gutenprint=mips64el=
> 5.2.13-1=1500347072=0
> 
> ...
> Making check in cups
> make[4]: Entering directory '/<>/src/cups'
> make  check-TESTS
> make[5]: Entering directory '/<>/src/cups'
> make[6]: Entering directory '/<>/src/cups'
> E: Build killed with signal TERM after 150 minutes of inactivity

It built when it was retried on mipsel-aql-03; hereby downgrading the severity
accordingly.

Cheers,
OdyX

Bug#868283: cups-browsed ignores "DefaultPolicy authenticated" from cupsd.conf

[Didier 'OdyX' Raboud]

Control: severity -1 important

Le vendredi, 14 juillet 2017, 08.54:29 h CEST Christoph Pleger a écrit :
> cups-browsed from Debian stretch ignores the "DefaultPolicy
> authenticated" entry in my cupsd.conf, so that all browsed-imported
> printers in /etc/cups/printers.conf are listed with "OpPolicy default".
> That differs from how it was in older Debian versions and their
> cups-browseds, and it allows users to print with another user id than
> their own without authentication, critical in an environment like ours
> where users have to pay for their print quota.

Although a bug that needs to be investigated, that certainly doesn't qualify 
as "critical" in Debian Bug severities [0]. At most 'important'.

No time _right now_ to investigate this, but tagging at the correct severity 
for now. 

Cheers,
OdyX
[0] https://www.debian.org/Bugs/Developer#severities

signature.asc
Description: This is a digitally signed message part.

Bug#860695: win32-loader: FTBFS on i386: segmentation fault

[Didier 'OdyX' Raboud]

Control: clone -1 -2
Control: reassign -2 mawk 1.3.3-17
Control: reopen -2 o...@debian.org
Control: retitle -2 mawk: segfaults on i386 during win32-loader build
Control: severity -2 serious

Le mercredi, 19 avril 2017, 17.31:26 h CEST Didier 'OdyX' Raboud a écrit :
> Le mercredi, 19 avril 2017, 15.44:00 h CEST Sven Joachim a écrit :
> > >> Relevant part (hopefully):
> > > Actually:
> > >> > # Prepare the README file
> > >> > awk
> > >> > (…)
> > >> > Segmentation fault
> > > 
> > > `awk` segfaults here. This seems to be an awk bug, or problem. Is the
> > > command- line for it too long, or is it something else?
> > 
> > Possibly it's the same problem as #158481.  A workaround is to use
> > original-awk or gawk instead of awk (and build-depend on it, of course).
> > 
> > I don't feel like debugging this issue, since mawk in Debian is
> > unmaintained. :-(
> 
> Thanks for the information; I've successfully reproduced the awk segfault in
> a  i386 porterbox, and I can confirm the gawk replacement fixes that.

Hereby cloning, reopening and reassigning to mawk, with a severity: serious. 
Will see if I can reproduce with a simpler test-case.

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#860695: win32-loader: FTBFS on i386: segmentation fault

[Didier 'OdyX' Raboud]

Control: tags -1 -moreinfo +pending

Le mercredi, 19 avril 2017, 15.44:00 h CEST Sven Joachim a écrit :
> >> Relevant part (hopefully):
> > Actually:
> >> > # Prepare the README file
> >> > awk
> >> > (…)
> >> > Segmentation fault
> > 
> > `awk` segfaults here. This seems to be an awk bug, or problem. Is the
> > command- line for it too long, or is it something else?
> 
> Possibly it's the same problem as #158481.  A workaround is to use
> original-awk or gawk instead of awk (and build-depend on it, of course).
> 
> I don't feel like debugging this issue, since mawk in Debian is
> unmaintained. :-(

Thanks for the information; I've successfully reproduced the awk segfault in a 
i386 porterbox, and I can confirm the gawk replacement fixes that.

I will upload a simple fix later today.

-- 
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#860695: win32-loader: FTBFS on i386: segmentation fault

[Didier 'OdyX' Raboud]

Control: tags -1 +moreinfo +help

Le mercredi, 19 avril 2017, 09.28:30 h CEST Lucas Nussbaum a écrit :
> During a rebuild of all packages in stretch (in a stretch chroot, not a
> sid chroot), your package failed to build on i386.

win32-loader is a arch:all package, and is "usually" built on amd64 buildds, 
on which it builds fine. This i386-specific FTBFS has been visible through the 
reproducible builds infrastructure for a while:


https://tests.reproducible-builds.org/debian/rb-pkg/testing/i386/win32-loader.html

> Relevant part (hopefully):

Actually:

> > # Prepare the README file
> > awk
> > '{sub(/@PACKAGES_LIST@/,"grub2 2.02~beta3-5  
> > http://ftp.debian.org/debian/pool/main/g/grub2\ncpio  
> > 2.11+dfsg-6   http://ftp.debian.org/debian/pool/main/c/cpi
> > o\ngzip  1.6-5 http://ftp.debian.o
> > rg/debian/pool/main/g/gzip\ngnupg22.1.18-6
> >   http://ftp.debian.org/debian/pool/main/g/gnupg2\ndebian-archive-keyr
> > ing2014.3http://ftp.debian.org/debian/pool/main/d/
> > debian-archive-keyring\nloadlin   1.6f-5  
> >   http://ftp.debian.org/debian/pool/main/l/loadlin\nipxe  
> > 1.0.0+git-20161027.b991c6
> > http://ftp.debian.org/debian/pool/main/i/ipxe\nnsis  
> > 2.51-1http://ftp.debian.org/debian/pool/main/n/nsis\nl
> > ibgcrypt20   1.7.6-1   http://ftp.debian.org/d
> > ebian/pool/main/l/libgcrypt20\nlibgpg-error  1.26-2   
> >  http://ftp.debian.org/debian/pool/main/l/libgpg-error\n;)}1 \
> > {sub(/@NSIS_VERSION@/,"2.51-1+b1")}1 \
> > {sub(/@W32_VERSION@/,"0.8.2")}1' \
> > debian/win32-loader_doc.txt > win32-loader_0.8.2_all.txt
> > Segmentation fault

`awk` segfaults here. This seems to be an awk bug, or problem. Is the command-
line for it too long, or is it something else?

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#853783: ping

[Didier 'OdyX' Raboud]

Control: severity -1 important
Control: tags -1 +moreinfo

Hi Svante,

Le vendredi, 10 février 2017, 21.46:05 h CET Svante Signell a écrit :
> I view of the imminent release I'm upgrading the severity, since there has
> been no replies so far, really strange.

Please don't mix severities, release schedule and maintainer responsiveness, 
they have nothing to do with eachothers, at all. This bug is rightfully 
'important', hereby downgrading. 

> Do you not get reports about bugs via the bug tracker?

I do; it doesn't mean I have time to respond anything meaningful. Bug squasing 
can take some time, and hardware-related bugs are even harder: I don't have a 
scanner at home. It's only been _ten_ days too.

> How come 3.16.7-1 works and not later versions?

I don't know, but here are the facts I could gather:
* there are no significant differences in the Debian packaging;
* the only relevant difference regarding hpaio is the addition of more models 
(but nothing related to your model) in scan/sane/hpaio.desc

When you write that "3.16.7-1" works, is that the version of the Debian 
package? (I ask because that version is not an hplip Debian release).

Can you confirm using http://snapshot.debian.org/package/hplip/ until exactly 
which version it works, and from which version it fails?

Thanks in advance,
-- 
OdyX

Bug#818875: konqueror: green SSL checkbox despite expired server certificate

[Didier 'OdyX' Raboud]

Le lundi, 21 mars 2016, 11.03:13 h CET Thorsten Glaser a écrit :
> Package: konqueror
> Version: 4:15.08.3-1
> Severity: grave
> Tags: security
> Justification: user security hole
> 
> See attached screenshot – konqueror does not error out when the
> certificate is expired and even shows a green checkbox. (I may
> or may not have ACK’d the certificate in an earlier session, I
> don’t know right now, but showing a green checkbox is still
> wrong.)

https://expired.identrustssl.com/ is an online example to test that use-case, 
which I can reproduce.

konqueror is RC-buggy in stretch because of that (IMHO rightful) bug. It is 
also plagued by other bugs, I wonder if konqueror should really be shipped in 
stretch. How feasible is it to remove it ?

-- 
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#839747: debian-installer-netboot-images: FTBFS in testing (no properly formatted SHA256 checksum lines found)

[Didier 'OdyX' Raboud]

Le mercredi, 5 octobre 2016, 00.32:19 h CEST Santiago Vila a écrit :
> On Wed, Oct 05, 2016 at 12:22:31AM +0200, Cyril Brulebois wrote:
> > It might make sense to start uploading it to unstable since we're
> > slowly approaching freeze time. Say: starting with the next d-i
> > release.

Works for me, don't hesitate to ping if needed.

-- 
Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#839400: hplip: setup of HPLIP toolbox is faulty

[Didier 'OdyX' Raboud]

Control: severity -1 wishlist
Control: retitle -1 Make Debian install work over previous manual install

Le samedi, 1 octobre 2016, 09.00:39 h CEST WRMelgaard a écrit :
> Dear Maintainer,
> Previously installed version was done manually from HP website, decided to
> use the Debian packag system for upgrade Using Synaptic, installed the
> hplip package.

This is not a supported use-case, sorry. When installing Debian packages, the 
unpacking will only care about files that it knows about, that is the files 
that 
have previously been unpacked when installing other Debian packages.

Third-party package installer interfere with Debian packages installation, and 
it's not something we can really support. I'll keep this bug open, as a 
wishlist (because it's _possible_ to have some code in place to circumvent 
this, but not realistic.) Patches welcome.

-- 
Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#832873: ghostscript: FTBFS: sjpx_openjpeg.c:605: undefined reference to `opj_image_destroy'

[Didier 'OdyX' Raboud]

Control: tags -1 +patch

Le vendredi, 29 juillet 2016, 08.48:47 h CEST Lucas Nussbaum a écrit :
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
> 
> Relevant part (hopefully):
> > ./base/sjpx_openjpeg.c:249: undefined
> > reference to `opj_decode' /usr/bin/ld: ./sobin/libgs.so.9.19: hidden
> > symbol `opj_setup_decoder' isn't defined /usr/bin/ld: final link failed:

I've now spent quite some time investigating this and finally found the
problem: libopenjp2-7-dev (>= 2.1.1) has changed it's
/usr/include/openjpeg-2.1/openjpeg.h
to include the following lines:

#if defined(OPJ_STATIC) || !defined(_WIN32)
/* http://gcc.gnu.org/wiki/Visibility */
#   if __GNUC__ >= 4
#   if defined(OPJ_STATIC) /* static library uses "hidden" */
#   define OPJ_API__attribute__ ((visibility 
("hidden")))
#   else
#   define OPJ_API__attribute__ ((visibility 
("default")))
#   endif

This makes all API symbols hidden if '-DOPJ_STATIC' is passed to GCC; as
it happens to be passed in base/lib.mak :

$(GLOBJ)sjpx_openjpeg.$(OBJ) : $(GLSRC)sjpx_openjpeg.c $(AK) \
 $(memory__h) $(gserror_h) $(gserrors_h) \
 $(gdebug_h) $(strimpl_h) $(sjpx_openjpeg_h) $(LIB_MAK) $(MAKEDIRS)
   $(GLJPXOPJCC) $(GLO_)sjpx_openjpeg.$(OBJ) \
   $(C_) -DOPJ_STATIC $(GLSRC)sjpx_openjpeg.c

Patching this -DOPJ_STATIC out fixes the FTBFS; patch attached.

Cheers,
-- 
OdyXDescrtiption: Don't pass -DOPJ_STATIC when compiling the OpenJPEG code, as it
 makes the symbols hidden when including /usr/include/openjpeg-2.1/openjpeg.h
 .
 Fixes a FTBFS against libopenjp2-7 (>= 2.1.1)
Author: Didier Raboud <o...@debian.org>
Origin: vendor
Bug-Debian: https://bugs.debian.org/832873

--- a/base/lib.mak
+++ b/base/lib.mak
@@ -1830,11 +1830,11 @@
 
 $(GLOBJ)sjpx_openjpeg.$(OBJ) : $(GLSRC)sjpx_openjpeg.c $(AK) \
  $(memory__h) $(gserror_h) $(gserrors_h) \
  $(gdebug_h) $(strimpl_h) $(sjpx_openjpeg_h) $(LIB_MAK) $(MAKEDIRS)
 	$(GLJPXOPJCC) $(GLO_)sjpx_openjpeg.$(OBJ) \
-		$(C_) -DOPJ_STATIC $(GLSRC)sjpx_openjpeg.c
+		$(C_) $(GLSRC)sjpx_openjpeg.c
 
 #  Pixel-difference filters  #
 # The Predictor facility of the LZW and Flate filters uses these.
 
 pdiff_=$(GLOBJ)spdiff.$(OBJ)


signature.asc
Description: This is a digitally signed message part.

Bug#816870: hplip: contains non-free code

[Didier 'OdyX' Raboud]

Control: tags -1 +pending +patch.

Hi Julian,

Le dimanche, 6 mars 2016, 02.26:14 h CEST Julian Andres Klode a écrit :
> In prnt/hpcups, the headers of ErnieFilter.cpp and .h say:
> 
> // This software is licensed solely for use with HP products. Redistribution
> // and use with HP products in source and binary forms, with or without //
> modification, are permitted provided that the following conditions are met:
> 
> As such, the code is non-free because I cannot safely redistribute it. 

Without any indication of progress from upstream, I went and checked if it was 
possible to compile hplip without these two files, it seems possible.

I'll go ahead and upload a new repack'ed package without these two files and 
the attached patch. We'll see if that brings regressions.

--
Cheers,
OdyXDescription: Cope with prnt/hpcups/ErnieFilter.{cpp,h} removal by disabling the
 functionality
Origin: vendor
Author: Didier Raboud <o...@debian.org>
Last-Update: 2016-07-10

--- a/Makefile.am
+++ b/Makefile.am
@@ -519,7 +519,7 @@
 	prnt/hpcups/Mode2.cpp prnt/hpcups/Mode2.h prnt/hpcups/Mode3.cpp prnt/hpcups/Mode3.h \
 	prnt/hpcups/Mode9.cpp prnt/hpcups/Mode9.h prnt/hpcups/Mode10.cpp prnt/hpcups/Mode10.h \
 	prnt/hpcups/ModeDeltaPlus.cpp prnt/hpcups/ModeDeltaPlus.h prnt/hpcups/ModeJbig.cpp prnt/hpcups/ModeJbig.h \
-	prnt/hpcups/ErnieFilter.cpp prnt/hpcups/ErnieFilter.h prnt/hpcups/EncapsulatorFactory.cpp prnt/hpcups/EncapsulatorFactory.h \
+	prnt/hpcups/EncapsulatorFactory.cpp prnt/hpcups/EncapsulatorFactory.h \
 	prnt/hpcups/Encapsulator.cpp prnt/hpcups/Encapsulator.h prnt/hpcups/Pcl3.cpp prnt/hpcups/Pcl3.h \
 	prnt/hpcups/Pcl3Gui.cpp prnt/hpcups/Pcl3Gui.h prnt/hpcups/Pcl3Gui2.cpp prnt/hpcups/Pcl3Gui2.h \
 	prnt/hpcups/LJMono.cpp prnt/hpcups/LJMono.h prnt/hpcups/LJColor.cpp prnt/hpcups/LJColor.h \
--- a/prnt/hpcups/Pcl3Gui2.cpp
+++ b/prnt/hpcups/Pcl3Gui2.cpp
@@ -30,7 +30,6 @@
 
 #include "CommonDefinitions.h"
 #include "Pcl3Gui2.h"
-#include "ErnieFilter.h"
 #include "Mode10.h"
 #include "Mode9.h"
 #include "PrinterCommands.h"
@@ -38,7 +37,6 @@
 Pcl3Gui2::Pcl3Gui2() : Encapsulator()
 {
 speed_mech_enabled = true;
-m_run_ernie_filter = true;
 crd_type = eCrd_both;
 strcpy(m_szLanguage, "PCL3GUI");
 }
@@ -59,21 +57,6 @@
 }
 
 width = m_pMA->printable_width;;
-if (m_run_ernie_filter) {
-	ErnieFilter*pErnie;
-
-   // Normal: threshold = (resolution) * (0.0876) - 2
-   int threshold = ((m_pQA->horizontal_resolution * 876) / 1) - 2;
-
-   pErnie = new ErnieFilter (width, eBGRPixelData, threshold);
-   p = new Pipeline (pErnie);
-   if (head) {
-  head->AddPhase (p);
-   }
-   else {
-   head = p;
-   }
-}
 
 if (crd_type != eCrd_black_only) {
 Mode10*pMode10;
--- a/prnt/hpcups/Pcl3Gui2.h
+++ b/prnt/hpcups/Pcl3Gui2.h
@@ -60,7 +60,6 @@
 DRIVER_ERROR encapsulateRaster(BYTE *input_raster, unsigned int num_bytes, COLORTYPE c_type);
 boolspeed_mech_enabled;
 int page_number;
-boolm_run_ernie_filter;
 eCrdTypecrd_type;
 };
 


signature.asc
Description: This is a digitally signed message part.

Bug#822500: Patch for FTBFS

[Didier 'OdyX' Raboud]

Le lundi, 25 avril 2016, 15.13:54 Peter Spiess-Knafl a écrit :
> A quick "#include " did the trick.
> (…)
> I also forwarded it upstream:
> https://github.com/pdewacht/brlaser/pull/9

Uploaded, credited to you. Thanks!

-- 
Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#819586: debian-installer-netboot-images: unhelpful handling of GPG errors

[Didier 'OdyX' Raboud]

Hoy KiBi,

Le vendredi, 22 avril 2016, 19.57:55 Cyril Brulebois a écrit :
> Adam D. Barratt <a...@adam-barratt.org.uk> (2016-03-30):
> > Whilst a failure to verify the Release signature does mean that we
> > don't attempt to build an image using untrusted inputs, the package
> > build continues with no sign of a problem having occurred until the
> > binary packages are examined.
> 
> Thanks for the catch!
> 
> Didier, I see you have committed a fix in git master, so I'm tagging
> this bug report accordingly. Did you test it (e.g. by faking a Release
> file corruption)?

Yes, right. I hacked on that bug, but forgot to update the buglog; sorry
for that.

> This seems like something we should cherry-pick in
> stable branches, but I don't want to do so without a confirmation
> first.

The following patch makes the build fail indeed:

diff --git a/get-images.sh b/get-images.sh
index caea03d..31f25bf 100755
--- a/get-images.sh
+++ b/get-images.sh
@@ -159,6 +159,9 @@ unpack_installer () {
 wget -c $MIRROR/dists/$DISTRIBUTION/Release.gpg -O $RELEASE_FILE.gpg
 wget -c $MIRROR/dists/$DISTRIBUTION/Release -O $RELEASE_FILE
 
+# Corrupt the release file
+echo "Break the signature" >> $RELEASE_FILE
+
 gpgv --keyring /usr/share/keyrings/debian-archive-keyring.gpg 
$RELEASE_FILE.gpg $RELEASE_FILE
 
 get_di_built_using $1


-- 
Cheers,
OdyX

Bug#818997: [pkg-gnupg-maint] Bug#818997: gpgv.exe linked dynamically against zlib1, doesn't allow proper signature verification

[Didier 'OdyX' Raboud]

Hi Daniel,

gpgv-win32 from unstable seems to work for me now (using the 
debian/tests/gpgv-win32 test at least).

The CI test still fails though, you might want to try integrating 
Antonio's proposal below.

Le jeudi, 24 mars 2016, 14.41:54 Antonio Terceiro a écrit :
> the caveat in this case is that since wine32 is not directly
> installable in a plain amd64 system, you can't declare it as test
> dependency, but you can say that the test requires root permissions,
> and do whatever special setup you need from within the test itself.
> 
> You want something like this: (…)
> (…)
> The above patch solves the installability issue, but the test still
> fails for me. The portion of the log after the installation phase
> looks like this:
> 
> (…)
> gpgv-win32   FAIL non-zero exit status 53
> 
> 
> maybe you need to wrap the wine call with xvfb-run or something like
> that? or maybe it's related to running wine as root (which is probably
> as scary as it sounds), so you could also create a fresh user to run
> the gpg commands as.

That '53' error is gpgv.exe failing to load zlib1, so it was just 
exposing this very bug. :) There's no need to wrap it in xvfb-run, 
AFAIK.

-- 
Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#818997: [pkg-gnupg-maint] Bug#818997: gpgv.exe linked dynamically against zlib1, doesn't allow proper signature verification

[Didier 'OdyX' Raboud]

Le mercredi, 23 mars 2016, 23.14:59 Daniel Kahn Gillmor a écrit :
> On Tue 2016-03-22 12:49:10 -0400, Didier 'OdyX' Raboud wrote:
> > I've noticed that gpgv.exe fails its CI test
> > (debian/tests/gpgv-win32) in version 1.4.20-4 (-3 and previous work
> > fine):
> 
> interesting, there was no change between -3 and -4 other than
> re-adding the gpgv-udeb for constrained armel devices at tbm's
> request (see #814027).
> 
> I suspect this means that the toolchain changed in some significant
> way between these releases.

I agree with this analyis; I've rebuilt gnupg in a clean chroot and the 
resulting gpgv.exe works, so we could just get the package rebuilt.

> hm, right.  I'm actually working on moving gpgv.exe over to the gnupg2
> packaging, so that we can get support for elliptic curve signatures
> as well.  I'll definitely test to ensure that it's properly
> statically linked when i produce it from that source.

Cool; saw the branch there, looking forward!

> > (By the way, the CI seems to have never run successfully in the last
> > months: https://ci.debian.net/packages/g/gnupg/unstable/amd64/ …)
> 
> this appears to be because of uninstallable dependencies; the tests
> can really only run on i386 systems or multiarch systems, right?  is
> wine32 available in amd64?

As far as I understand it, wine32 is only available on i386, and the 
current way to install it on amd64 hosts is through multiarch.

> I don't see any other architectures available at
> https://ci.debian.net/packages/g/gnupg/unstable/, and i'm assuming
> that the amd64 ci tester isn't multiarch.  or am i misinterpreting
> something?

CC'ing Antonio: there's no way to setup multiarch within an autopkgtest, 
right ?

-- 
Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#818997: gpgv.exe linked dynamically against zlib1, doesn't allow proper signature verification

[Didier 'OdyX' Raboud]

Package: gpgv-win32
Version: 1.4.20-4
Severity: serious
Tags: d-i

Dear maintainers,

I've noticed that gpgv.exe fails its CI test (debian/tests/gpgv-win32) in
version 1.4.20-4 (-3 and previous work fine):

(This is after adding WINEDEBUG=err+all as prefix to the latest line):

err:menubuilder:init_xdg error looking up the desktop directory
err:module:import_dll Library zlib1.dll (which is needed by 
L"Z:\\usr\\share\\win32\\gpgv.exe") not found
err:module:LdrInitializeThunk Main exe initialization for 
L"Z:\\usr\\share\\win32\\gpgv.exe" failed, status c135

It seems gpgv-win32 is dynamically linked against zlib1.dll, where it should
probably be statically linked. This appears to be a problem in the dependency
chain.

(By the way, the CI seems to have never run successfully in the last months:
https://ci.debian.net/packages/g/gnupg/unstable/amd64/ …)

Cheers, OdyX


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-proposed-updates'), (500, 
'proposed-updates'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 
'testing'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

gpgv-win32 depends on no packages.

gpgv-win32 recommends no packages.

Versions of packages gpgv-win32 suggests:
ii  wine  1.8.1-2

-- no debconf information

Bug#807380: Regression for 'PKCS11Provider libsimple-tpm-pk11.so' - ignoring uninitialised token in slot 0

[Didier 'OdyX' Raboud]

Le mardi, 8 décembre 2015, 03.35:33 Michael Stapelberg a écrit :
> If you could do an upload (possibly even of the new version), that’d
> be appreciated.

Uploaded 0.04-1 to unstable. Also pushed branches and tags to the 
collab-maint git.

I added a (hopefully) harmless change in the debian/watch to fit with 
more recent practices, that helped merging the new version in.

Cheers,
OdyX

Bug#807168: debian-installer-netboot-images: required resources not declared as build-dependencies (fetches via network)

[Didier 'OdyX' Raboud]

Control: tags -1 +wontfix

Le dimanche, 6 décembre 2015, 18.02:48 Jonas Smedegaard a écrit :
> debian-installer-netboot-images source package is less than 6k in
> size. Clearly the main part of the resulting binary packages come
> from fetching resources over the network (apparently using wget).
> Debian Policy includes the following in §4.2:
> > If build-time dependencies are specified, it must be possible to
> > build the package and produce working binaries on a system with
> > only essential and build-essential packages installed and also
> > those required to satisfy the build-time relationships (including
> > any implied relationships).
> 
> I can only interpret above as disallowing fetching resources over the
> network using wget.

d-i-n-i does (it's own) trust-path checking upon download, and it's 
doing so because there's (currently) no way to have these files local 
through Build-Depends.

The specificity of the resulting packages is that they are arch-all 
while containing arch-specific files. Their value comes from the fact 
that you can install netboot images for all Debian architectures 
(through arch:all packages) on any Debian architecture, without having 
to add add these archs through multiarch.

So the alternative would be to build these arch:all packages in the 
debian-installer build-arch target, but that wouldn't pass the incoming 
processing, as far as I know, as dak currently considers that there will 
be only one arch:all changes file per source.

Now talkin' crazy; we could also (ab)use byhand processing to produce 
these packages on the archive side; but using the archive to produce 
packages isn't really something we want to dive into.

So, the situation is known to not be Policy-compliant, but at least 
there's trust-path checking. In this specific case, I value the 
existance of these packages in their current form higher than Policy-
compliance, thereby tagging +wontfix. But I'm open to ideas!

What would you propose?

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#792655: Further details on 792655

[Didier 'OdyX' Raboud]

Control: retitle 792655 libgnutls segfault crashing CUPS
Control: reassign 792655 gnutls28 3.3.8-6+deb8u1
Control: forcemerge 788704 792655
Control: affects 788704 + cups

Le jeudi, 13 août 2015, 10.28:17 Johannes Dröge a écrit :
 after upgrading to CUPS version 2 from testing if found that it gave
 the same errors when accessing SSL functions. So I concluded that
 this might be a problem in the package libgnutls-deb0-28. After a
 little searching I found this recent (14 June 2015) bug report:
 
 https://bugs.debian.org/788704
 
 It turns out that the bug in GnuTLS is platform-specific
 
 processor   : 0
 vendor_id   : CentaurHauls
 cpu family  : 6
 model   : 13
 model name  : VIA Eden Processor 1500MHz
 
 The bug is fixed in newer upstream versions of GnuTLS but the one
 included in Debian Jessie still has the bug. After installing patched
 versions of the package, the segfault vanished. For me this is fine
 now but I hope that the patch finds its way into the stable release
 so other users don't run into this problem. Therefore, its good to
 have this documented here.

Great, thanks for the findings and explanation. I'm hereby reassigning 
this bug as not being a CUPS bug, assign it to GnuTLS and mark CUPS 
affected.

Thanks for your time!

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#792655: Further details on 792655

[Didier 'OdyX' Raboud]

Control: tags -1 +unreproducible

Hi Johannes, and thanks for your bugreport. Sorry for the time it took 
me to answer this serious bug.

Le vendredi, 17 juillet 2015, 10.11:05 Johannes Dröge a écrit :
 I cleared configuration files and reinstalled all packages. The daemon
 is reproducibly crashing when I access the CUPS configuration page on
 port 631 AND if the folder /etc/cups/ssl exists. If the folder
 doesn't exist, it does not crash but does also not work properly
 here.

Unfortunately, I can't reproduce this on my Jessie box: I setup SSLPort 
in cupsd.conf and restarted cups, then accessed the webinterface without 
problems or crashes.

 I believe that this is a linking problem, was it linked against the
 correct version of the libgnutls library?

I don't see why it wouldn't have, and there was no SONAME bump in 
stable.

 I remember that this worked after the upgrade to Debian 8, so could
 the be a defective security update?

That would be weird, but I can't check: the build logs aren't 
accessible.

Could you describe in details how you can manage to crash cupsd, 
starting from a clean install, with precise instructions on what you're 
changing in cupsd.conf ? That'd help a lot.

That said, testing that a stretch version does (or doesn't) crash would 
also be good to have!

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#792321: Segfaults on session start

[Didier 'OdyX' Raboud]

Le mardi, 14 juillet 2015, 00.10:03 Didier 'OdyX' Raboud a écrit :
 I can't open my second session (uid 1001, if that matters), now that
 my external screen isn't connected anymore. On session opening, I get
 multiple segfaults, starting with kscreen_backend and KSC_XRandR:

I managed to get my session started by deleting the users' 
.local/share/kscreen, if that helps someone else!

Cheers,
OdyX


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org