Bug#1067588: E: /usr/share/initramfs-tools/hooks/lvm2 failed with return 1.

[Kingsley G. Morse Jr.]

Hi Bastian,

Thank you for telling me about Debian's package
named "usrmerge".

You very nicely asked me to verify that "usrmerge"
is installed properly.

dpkg says it is now installed:

$ dpkg -l usrmerge
Desired=Unknown/Install/Remove/Purge/Hold
| 
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description

+++-==---
ii  usrmerge   39   all  Convert the system to the 
merged /usr directories scheme

You also asked me to verify that /bin, /lib, /sbin
are symlinks to /usr/*.

The

"$ ls -l"

command says 3 of mine are linked to "usr/*."

So,
Kingsley

PS: usrmerge was hard to install.

I seem to have installed it with *something like*...

$ dpkg -i /var/cache/apt/archives/usrmerge_39_all.deb

dpkg: dependency problems prevent configuration of usrmerge:
 usrmerge depends on perl:any; however:
  Package perl is not configured yet.


$ dpkg --configure perl

dpkg: dependency problems prevent configuration of perl:
 perl depends on perl-modules-5.38 (>= 5.38.2-3.2); however:
  Package perl-modules-5.38 is not configured yet.
 perl depends on libperl5.38t64 (= 5.38.2-3.2); however:
  Package libperl5.38t64:i386 is not configured yet.


$ dpkg  --configure perl-modules-5.38


$ dpkg  --configure libperl5.38t64:i386

dpkg: dependency problems prevent configuration of 
libperl5.38t64:i386:
 libperl5.38t64:i386 depends on libdb5.3t64; however:
  Package libdb5.3t64:i386 is not configured yet.
 libperl5.38t64:i386 depends on libgdbm-compat4t64 (>= 1.18-3); 
however:
  Package libgdbm-compat4t64:i386 is not configured yet.


$ dpkg  --configure libdb5.3t64:i386


$ dpkg  --configure libgdbm-compat4t64:i386


$ dpkg  --configure libperl5.38t64:i386


$ dpkg  --configure perl


$ dpkg -i /var/cache/apt/archives/usrmerge_39_all.deb

FATAL ERROR:
Both /lib/udev/hwdb.d/20-sane.hwdb and 
/usr/lib/udev/hwdb.d/20-sane.hwdb exist.

$ for f in /lib/udev/rules.d/*.rules ; do if test -e /usr$f ; then mv 
$f ~kingsley/tmp/copy_of_$(basename "$f")_from_lib_udev_rules.d ; fi ; done


$ dpkg -i /var/cache/apt/archives/usrmerge_39_all.deb

The system has been successfully converted.


On 03/24/2024 08:30, Bastian Blank wrote:
> On Sun, Mar 24, 2024 at 12:04:35AM -0700, Kingsley G. Morse Jr. wrote:
> > As you can see below, lines 25 and 26 of the hook
> > script look in a path starting with "/lib"
> > 
> > [...]
> > 25  elif [ -e /lib/udev/rules.d/$rules ]; then
> > 26  cp -p /lib/udev/rules.d/$rules $DESTDIR/lib/udev/rules.d/
> > [...]
> > 
> > But they are in a path starting with "/usr".
> 
> Your system is in an unsupported state.
> 
> Please verify that "usrmerge" is installed properly and /bin, /lib,
> /sbin are symlinks to /usr/*.
> 
> Bastian
> 
> -- 
> Men will always be men -- no matter where they are.
>   -- Harry Mudd, "Mudd's Women", stardate 1329.8

-- 
Time is the fire in which we all burn.

Bug#1067591: E: /usr/share/initramfs-tools/hooks/dmsetup failed with return 1.

[Kingsley G. Morse Jr.]

Package: dmsetup
Version: 2:1.02.196-1
Severity: normal

Dear Maintainer,

Thank you very much for maintaining Debian's dmsetup
package.

Please allow me to draw your attention to a
possible improvement.

It's very similar to one I just reported for the
lvm2 package.

Eidently they share the same source code.

I humbly suggest reconciling 

where dmsetup writes its rule files

55-dm,

60-persistent-storage-dm and

95-dm-notify

with where its hook script

/usr/share/initramfs-tools/hooks/dmsetup

looks for them.

As you can see below, lines 16 and 17 of the hook
script look in a path starting with "/lib"

[...]
16  elif [ -e /lib/udev/rules.d/$rules ]; then
17  cp -p /lib/udev/rules.d/$rules $DESTDIR/lib/udev/rules.d/
[...]

But they are in a path starting with "/usr".

You can see this is so by doing

$ for f in 
/{etc,lib}/udev/rules.d/{55-dm.rules,60-persistent-storage-dm.rules,95-dm-notify.rules}
 ; do apt-file search "$f" ;done

dmsetup: /usr/lib/udev/rules.d/55-dm.rules
dmsetup: /usr/lib/udev/rules.d/60-persistent-storage-dm.rules
dmsetup: /usr/lib/udev/rules.d/95-dm-notify.rules

I seem to have worked around the problem by
prefacing the paths in lines 16 and 17 in

/usr/share/initramfs-tools/hooks/dmsetup

with "/usr", like

16  elif [ -e /usr/lib/udev/rules.d/$rules ]; then
17  cp -p /usr/lib/udev/rules.d/$rules $DESTDIR/lib/udev/rules.d/

but I 

dunno if there is an official path for rule
files and

suppose a compliant fix may depend on it.

Thanks again for maintaining Debian's dmsetup
package!

Kind regards,
Kingsley

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
merged-usr: no
Architecture: i386 (i686)

Kernel: Linux 6.5.0-1-686-pae (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dmsetup depends on:
ii  libc6   2.37-12
ii  libdevmapper1.02.1  2:1.02.196-1

dmsetup recommends no packages.

dmsetup suggests no packages.

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/share/initramfs-tools/hooks/dmsetup (from dmsetup 
package)

Bug#1067588: E: /usr/share/initramfs-tools/hooks/lvm2 failed with return 1.

[Kingsley G. Morse Jr.]

Package: lvm2
Version: 2.03.22-1
Severity: normal

Dear Maintainer,

Thank you very much for maintaining Debian's lvm2
package.

Please allow me to draw your attention to a
possible improvement.

I humbly suggest reconciling 

where lvm2 writes its rule files

56-lvm and

69-lvm

with where its hook script

/usr/share/initramfs-tools/hooks/lvm2

looks for them.

As you can see below, lines 25 and 26 of the hook
script look in a path starting with "/lib"

[...]
25  elif [ -e /lib/udev/rules.d/$rules ]; then
26  cp -p /lib/udev/rules.d/$rules $DESTDIR/lib/udev/rules.d/
[...]

But they are in a path starting with "/usr".

You can see this is so by doing

$ for f in /{etc,lib}/udev/rules.d/{56-lvm.rules,69-lvm.rules} ; do 
apt-file search "$f" ;done

lvm2: /usr/lib/udev/rules.d/56-lvm.rules
lvm2: /usr/lib/udev/rules.d/69-lvm.rules

I seem to have worked around the problem by
prefacing the paths in lines 25 and 26 in

/usr/share/initramfs-tools/hooks/lvm2

with "/usr", like

25  elif [ -e /usr/lib/udev/rules.d/$rules ]; then
26  cp -p /usr/lib/udev/rules.d/$rules $DESTDIR/lib/udev/rules.d/

but I 

dunno if there is an official path for rule
files and

suppose a compliant fix may depend on it.

Thanks again for maintaining Debian's lvm2
package!

Kind regards,
Kingsley

Bug#989706: Now it works for me too (Was: [...] DeprecationWarning from csvclean)

[Kingsley G. Morse Jr.]

Hi Tony,

Thanks.

I'm happy to report

I just retested

$ echo -e "1,2,3\n4,5,6\n7,8" | csvclean

and got no DeprecationWarning with version

1.0.7-1 of csvkit and

3.11.4-5+b1 of python3.

Kind regards,
Kingsley

On 02/25/2024 22:39, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the csvkit package:
> 
> #989706: csvkit: DeprecationWarning from csvclean
> 
> It has been closed by tony mancill .
> 
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact tony mancill 
>  by
> replying to this email.
> 
> 
> -- 
> 989706: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989706
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

> Date: Sun, 25 Feb 2024 14:37:14 -0800
> From: tony mancill 
> To: 989706-d...@bugs.debian.org
> Subject: Re: Bug#989706: csvkit: DeprecationWarning from csvclean
> 
> On Thu, Jun 10, 2021 at 04:08:09PM -0700, Kingsley G. Morse Jr. wrote:
> > Here's a one-liner that causes its "csvclean"
> > command to complain, at least on my computer.
> > 
> > bash$ echo -e "1,2,3\n4,5,6\n7,8" | csvclean 
> > /usr/lib/python3/dist-packages/unittest2/compatibility.py:143: 
> > DeprecationWarning: Using or importing the ABCs from 'collections' instead 
> > of from 'collections.abc' is deprecated since Python 3.3, and in 3.10 it 
> > will stop working
> > 1 error logged to stdin_err.csv
> 
> I can't reproduce the reported behavior on Debian bullseye, bookwork, 
> trixie, or unstable.  I suspect it was resolved during the bullseye
> release cycle.
> 
> Therefore, I am closing the bug.  Feel free to either reopen or file a
> new bug if you detect any problems with csvkit.
> 
> Thank you,
> tony

> Date: Thu, 10 Jun 2021 16:08:09 -0700
> From: "Kingsley G. Morse Jr." 
> To: Debian Bug Tracking System 
> Subject: csvkit: DeprecationWarning from csvclean
> X-Mailer: reportbug 6.6.6
> 
> Package: csvkit
> Version: 1.0.5-2
> Severity: normal
> 
> Dear Maintainer,
> 
> Thank you very much for sharing your valuable time
> and skill to maintain Debian's csvkit package.
> 
> Here's a one-liner that causes its "csvclean"
> command to complain, at least on my computer.
> 
> bash$ echo -e "1,2,3\n4,5,6\n7,8" | csvclean 
> /usr/lib/python3/dist-packages/unittest2/compatibility.py:143: 
> DeprecationWarning: Using or importing the ABCs from 'collections' instead of 
> from 'collections.abc' is deprecated since Python 3.3, and in 3.10 it will 
> stop working
> 1 error logged to stdin_err.csv
> 
> I'd like to think eliminating the warning is as
> easy as importing the ABCs from 'collections.abc'.
> 
> Maybe you'd like to use my little one liner to
> test fixes for csvkit and python3-csvkit.
> 
> Thanks again,
> Kingsley
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable')
> Architecture: i386 (i686)
> 
> Kernel: Linux 4.4.0-1-686-pae (SMP w/2 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/bash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages csvkit depends on:
> ii  python3-csvkit  1.0.5-2
> pn  python3:any 
> 
> csvkit recommends no packages.
> 
> Versions of packages csvkit suggests:
> ii  csvkit-doc  1.0.2-1
> 
> -- no debconf information


-- 
Time is the fire in which we all burn.

Bug#1043240: pandas 1.5 -> 2.1?

[Kingsley G. Morse Jr.]

Hi Rebecca, Julian and all science minded pythonistas of debian, great and 
small!

I like your correspondence about upgrading from
version 1.5 of pandas to 2.1.

It's open, scientific and explores the ideal of
proceeding wisely in a matter of public interest.

My humble thoughts are:

1.) Rebecca: *Why* did you write that you'd like
to move forward with the pandas 1.5 -> 2.1
transition? What's your reason?

2.) What may be the advantage of migrating to
version 3.0 of Cython?

3.) The following one-liner suggests 44 debian
packages might be affected by the breaks
Rebecca said would be caused by pandas 2.x:

$ for s in augur cnvkit dyda emperor esda mirtop pymatgen pyranges 
python-anndata python-biom-format python-cooler python-nanoget python-skbio 
python-ulmo q2-quality-control q2-demux q2-taxa q2-types q2templates 
sklearn-pandas ; do apt-cache search "$s" ; done | less

4.) The break that worries me the most is
sklearn-pandas, because it seems to me that
sklearn is 

popular and 

fundamental.

Comment welcome,
Kingsley

On 12/10/2023 20:16, Julian Gilbey wrote:
> On Sun, Dec 10, 2023 at 01:06:01PM +, Rebecca N. Palmer wrote:
> > I'd like to move forward with the pandas 1.5 -> 2.1 transition reasonably
> > soon.
> > 
> > Given that pandas 2.x is *not* required for Python 3.12 (but is required for
> > Cython 3.0), should we wait for the Python 3.12 transition to be done first?
> 
> Well, I have seen at least one package that has an RC bug for the
> Python 3.12 transition that might be because it's still using an old
> version of cython3 :(  So it's a bit of chicken-and-egg - having Cython
> 3.0 might be very helpful.  But then there is this list of 28 packages
> broken by pandas 2.x.  On the other hand, these will need fixing at
> some point soon anyway, so I'd be in favour of doing the pandas
> transition now, which will allow Cython 3.0 to move into unstable.
> 
> Just my 2 cents' worth...
> 
> Best wishes,
> 
>Julian
> 

-- 
Time is the fire in which we all burn.

Bug#1057439: Thanks for the update (Was: datamash: "antimode"...)

[Kingsley G. Morse Jr.]

Very good, Erik.

Happy holidays,
Kingsley

On 12/09/2023 18:13, Erik Auerswald wrote:
> [...]
> I have just pushed a fix for this issue to the datamash development 
> repository:
> https://git.savannah.gnu.org/gitweb/?p=datamash.git;a=commitdiff;h=a4b48a8ac04ea9813fb83952e51ed87af44cbf6a

-- 
Time is the fire in which we all burn.

Bug#1057439: datamash: "antimode" returns lowest, instead of least common, value

[Kingsley G. Morse Jr.]

Package: datamash
Version: 1.8-1
Severity: normal

Dear Maintainer,

Thanks for maintaining datamash.

I like that it lets shell scripts calculate
statistics.

The main reason I'm writing is datamash's
"antimode" statistical grouping operation did not
work as I expected.

datamash's man page says its "antimode"
statistical grouping operation is for the "least
common value".

But, my testing suggests datamash's "antimode"
instead returns the lowest value.

My simple test is to 

1.) copy 

echo -e "1\n1\n2" | datamash antimode 1

to the bash command prompt and 

2.) press the  key.


At least on my computer, it returns "1".

But, I expected it to return "2", because "2" is
the least common value.

I suppose maybe either datamash's man page and/or code
could be changed so they're consistent.

Thanks again for datamash!

Kind regards,
Kingsley

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
merged-usr: no
Architecture: i386 (i686)

Kernel: Linux 6.5.0-1-686-pae (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages datamash depends on:
ii  libc6  2.37-12

datamash recommends no packages.

datamash suggests no packages.

-- no debconf information

-- 
Time is the fire in which we all burn.

Bug#1055815: python3-sympy: nsimplify() fails with: KeyError: 'extended_nonnegative'

[Kingsley G. Morse Jr.]

Package: python3-sympy
Version: 1.12-6
Severity: normal

Thanks for maintaining Debian's cool python3-sympy
package.

If you happen to have the time, and are so
inclined, feel free to share any thoughts you may
happen to have on whether it might be improved to
not crash when asked to nsimplify() the
following...

(1/(1 - (0.5*Y + 1)**1.5583266249))**6.5


I can replicate the crash with 

python3-sympy   1.12-6

python3 3.11.4-5+b1 

by copying and pasting the following line to a
bash shell prompt

$ python3 -c 'import sympy ; sympy.nsimplify(sympy.sympify("(1/(1 - (0.5*Y 
+ 1)**1.5583266249))**6.5"))'


It seems to me it should not crash, but it fails
with

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/sympy/core/assumptions.py", line 
499, in getit
return self._assumptions[fact]
   ~^^
KeyError: 'extended_nonnegative'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/sympy/simplify/simplify.py", line 
1446, in nsimplify
return _real_to_rational(expr, tolerance, rational_conversion)
   ^^^
  File "/usr/lib/python3/dist-packages/sympy/simplify/simplify.py", line 
1582, in _real_to_rational
return p.subs(reps, simultaneous=True)
   ^^^
  File "/usr/lib/python3/dist-packages/sympy/core/basic.py", line 1036, in 
subs
return rv.xreplace(reps)
   ^
  File "/usr/lib/python3/dist-packages/sympy/core/basic.py", line 1230, in 
xreplace
value, _ = self._xreplace(rule)
   
  File "/usr/lib/python3/dist-packages/sympy/core/basic.py", line 1252, in 
_xreplace
return self.func(*args), True
   
  File "/usr/lib/python3/dist-packages/sympy/core/cache.py", line 72, in 
wrapper
retval = cfunc(*args, **kwargs)
 ^^
  File "/usr/lib/python3/dist-packages/sympy/core/power.py", line 371, in 
__new__
obj = b._eval_power(e)
  
  File "/usr/lib/python3/dist-packages/sympy/core/power.py", line 471, in 
_eval_power
elif re(b).is_extended_nonnegative and (abs(e) < 2) == True:
 ^
  File "/usr/lib/python3/dist-packages/sympy/core/assumptions.py", line 
503, in getit
return _ask(fact, self)
   
  File "/usr/lib/python3/dist-packages/sympy/core/assumptions.py", line 
559, in _ask
fact_i_value = handler_i(obj)
   ^^
  File "/usr/lib/python3/dist-packages/sympy/core/add.py", line 863, in 
_eval_is_extended_negative
v = _monotonic_sign(a)
^^
  File "/usr/lib/python3/dist-packages/sympy/core/exprtools.py", line 76, 
in _monotonic_sign
if not self.is_Add and self.as_numer_denom()[1].is_number:
   ^
  File "/usr/lib/python3/dist-packages/sympy/core/mul.py", line 1234, in 
as_numer_denom
numers, denoms = list(zip(*[f.as_numer_denom() for f in self.args]))
   ^^^
  File "/usr/lib/python3/dist-packages/sympy/core/mul.py", line 1234, in 

numers, denoms = list(zip(*[f.as_numer_denom() for f in self.args]))
^^
  File "/usr/lib/python3/dist-packages/sympy/core/power.py", line 1584, in 
as_numer_denom
return self.func(n, exp), self.func(d, exp)
  ^
  File "/usr/lib/python3/dist-packages/sympy/core/cache.py", line 72, in 
wrapper
retval = cfunc(*args, **kwargs)
 ^^
  File "/usr/lib/python3/dist-packages/sympy/core/power.py", line 371, in 
__new__
obj = b._eval_power(e)
  
  File "/usr/lib/python3/dist-packages/sympy/core/numbers.py", line 2351, 
in _eval_power
x, xexact = integer_nthroot(abs(self.p), expt.q)

  File "/usr/lib/python3/dist-packages/sympy/core/power.py", line 83, in 
integer_nthroot
x, t = gmpy.iroot(y, n)
   
ValueError: n must be > 0


I think it's possible to do better.

Version 16.0.5-4 of another computer algebra
package called "mathomatic" does not crash on the
same example:

$ mathomatic -e "(1/(1 - (0.5*Y + 1)**1.5583266249))**6.5" simplify

1-> (1/(1 - (0.5*Y + 1)**1.5583266249))**6.5

 1   13
#1: ^--
   Y 2
(1 - ((- + 

Bug#1052596: Maybe tell user when input to Poly() == 0

[Kingsley G. Morse Jr.]

I'm happy to report another open source computer
algebra system said my input equals zero.

You can see this is so at Bash's shell command
line with

$ mathomatic -e "((a - b) - (((a - b) + (c - d) + (e - f))/3)) + ((c - d) - 
(((a - b) + (c - d) + (e - f))/3)) + (e - f) - ((a - b) + (c - d) + (e - f))/3" 
simplify

At least on my computer, it returns


(a - b + c - d + e - f)   (a - b + c - d + e - f)   
(a - b + c - d + e - f)
#1: a - b - --- + c - d - --- + e - 
f - ---
   3 3  
   3


#1: 0


If you happen to have the time, and are so
inclined, I'd be interested in your thoughts on
whether Poly() might be improved by distinguishing
between

GeneratorsNeeded: Cannot initialize from 'dict' without generators

and

its input equaling 0.

I think the relevant code may be near line 250 in
/usr/lib/python3/dist-packages/sympy/polys/polytools.py

Thanks again for maintaining Debian's cool sympy
package.

Kind regards,
Kingsley

-- 
Time is the fire in which we all burn.

Bug#1052596: python3-sympy: sympy.Poly() fails with: GeneratorsNeeded: Cannot initialize from 'dict' without generators

[Kingsley G. Morse Jr.]

Package: python3-sympy
Version: 1.12-6
Severity: normal

Thank you very mcuh for maintaining Debian Linux's
"python3-sympy" package.

It's interesting and sophisticated.

Please allow me to draw your attention a possible
bug.

I can elicit it with just 2 lines of code.

Here is how:

$ ipython3

In [1]: from sympy import Poly

In [2]: Poly('((a - b) - (((a - b)  +  (c - d)  +  (e - f))/3)) + ((c - d) 
- (((a - b)  +  (c - d)  +  (e - f))/3)) + (e - f) - ((a - b)  +  (c - d)  +  
(e - f))/3')

sympy.Poly() complains with

---
GeneratorsNeeded  Traceback (most recent call last)
Cell In [2], line 1
> 1 Poly('((a - b) - (((a - b)  +  (c - d)  +  (e - f))/3)) + ((c - d) 
- (((a - b)  +  (c - d)  +  (e - f))/3)) + (e - f) - ((a - b)  +  (c - d)  +  
(e - f))/3')

File /usr/lib/python3/dist-packages/sympy/polys/polytools.py:182, in 
Poly.__new__(cls, rep, *gens, **args)
180 return cls._from_poly(rep, opt)
181 else:
--> 182 return cls._from_expr(rep, opt)

File /usr/lib/python3/dist-packages/sympy/polys/polytools.py:312, in 
Poly._from_expr(cls, rep, opt)
310 """Construct a polynomial from an expression. """
311 rep, opt = _dict_from_expr(rep, opt)
--> 312 return cls._from_dict(rep, opt)

File /usr/lib/python3/dist-packages/sympy/polys/polytools.py:249, in 
Poly._from_dict(cls, rep, opt)
246 gens = opt.gens
248 if not gens:
--> 249 raise GeneratorsNeeded(
250 "Cannot initialize from 'dict' without generators")
252 level = len(gens) - 1
253 domain = opt.domain

GeneratorsNeeded: Cannot initialize from 'dict' without generators


I expected it to work.

Especially because simply deleting the trailing "/3" from the input does, like 
this...

In [3]: Poly('((a - b) - (((a - b)  +  (c - d)  +  (e - f))/3)) + ((c - d) 
- (((a - b)  +  (c - d)  +  (e - f))/3)) + (e - f) - ((a - b)  +  (c - d)  +  
(e - f))')

Out[3]: Poly(-2/3*a + 2/3*b - 2/3*c + 2/3*d - 2/3*e + 2/3*f, a, b, c, d, e, 
f, domain='QQ')


I suppose an approximate workaround is to replace the trailing

.../3

with a leading

0.333*...

like this...

In [4]: Poly('((a - b) - (((a - b)  +  (c - d)  +  (e - f))/3)) + ((c - d) 
- (((a - b)  +  (c - d)  +  (e - f))/3)) + (e - f) - 0.333*((a - b)  + 
   ...:  (c - d)  +  (e - f))')
Out[4]: Poly(0.000297*a - 0.000297*b + 
0.000297*c - 0.000297*d + 0.000297*e - 
0.000297*f, a, b, c, d, e, f, domain='RR')


I also noticed that replacing the trailing "/3" with division by 1, 2, 4, 5 and 
6 worked.

Thanks again for maintaining Debian's python3-sympy package.

Kind regards,
Kingsley


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
merged-usr: no
Architecture: i386 (i686)

Kernel: Linux 4.4.0-1-686-pae (SMP w/2 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages python3-sympy depends on:
ii  python3 3.11.1-3
ii  python3-mpmath  1.2.1-1

Versions of packages python3-sympy recommends:
ii  isympy-common  1.7.1-2
ii  python3-numpy  1:1.24.2-1
ii  python3-pil9.4.0-1.1+b1

Versions of packages python3-sympy suggests:
pn  dvipng   
pn  python-sympy-doc 
pn  texlive-fonts-extra  

-- no debconf information

Bug#987185: Upgrading pypy3 fixed it for...

[Kingsley G. Morse Jr.]

Hi guys,

I had a similar problem.

Maybe you'll be interested in how I fixed it.

I also got

from __future__ import annotations
^
SyntaxError: future feature annotations is not defined

But, mine happened after

root$ aptitude reinstall python3-numpy

with version 3.11.2-1 of the python3.11 package
installed.

I fixed it by upgrading

package old new

pypy3   7.3.3+dfsg-47.3.11+dfsg-2
pypy3-lib   7.3.3+dfsg-47.3.11+dfsg-2
python3-virtualenv  20.13.0+ds-120.17.1+ds-1

I hope that helps!

Best wishes,
Kingsley

-- 
Time is the fire in which we all burn.

Bug#1029659: AttributeError: module 'inspect' has no attribute 'getargspec'. Did you mean: 'getargs'?

[Kingsley G. Morse Jr.]

Package: python3-reportbug
Version: 11.6.0
Severity: important

Thank you very much for maintaining Debian's
python3-reportbug package.

I love the ideal of freely cooperating.

I happened to notice version 11.5.1 crashed with

$ reportbug
Traceback (most recent call last):
  File "/usr/bin/reportbug", line 40, in 
from reportbug import utils
  File "/usr/lib/python3/dist-packages/reportbug/utils.py", line 70, in 

from . import debbugs   # noqa: E402
^
  File "/usr/lib/python3/dist-packages/reportbug/debbugs.py", line 33, in 

import debianbts
  File "/usr/lib/python3/dist-packages/debianbts/__init__.py", line 1, in 

from debianbts.debianbts import * # noqa
^
  File "/usr/lib/python3/dist-packages/debianbts/debianbts.py", line 21, in 

import pysimplesoap
  File "/usr/lib/python3/dist-packages/pysimplesoap/__init__.py", line 16, 
in 
from . import client, server, simplexml, transport
  File "/usr/lib/python3/dist-packages/pysimplesoap/client.py", line 33, in 

from .transport import get_http_wrapper, set_http_wrapper, get_Http
  File "/usr/lib/python3/dist-packages/pysimplesoap/transport.py", line 
109, in 
if 'timeout' in inspect.getargspec(httplib2.Http.__init__)[0]:
^^
AttributeError: module 'inspect' has no attribute 'getargspec'. Did you 
mean: 'getargs'?


I expected to see

Please enter the name of the package in which you have found a problem, or 
type 'other' to report a more general problem. If you don't know what package 
the bug is in, please contact debian-u...@lists.debian.org for assistance.
> 


I'm happy to report I seem to have fixed it by
upgrading Debian's python3-pysimplesoap package
from version

1.16.2-3

to

1.16.2-5


Humble suggestion:

Please consider updating python3-reportbug to
depend on at least version 1.16.2-5 of
python3-pysimplesoap.

Kind regards,
Kingsley

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
merged-usr: no
Architecture: i386 (i686)

Kernel: Linux 4.4.0-1-686-pae (SMP w/2 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages python3-reportbug depends on:
ii  apt2.1.13
ii  file   1:5.39-3
ii  python33.11.1-1
ii  python3-apt2.5.2
ii  python3-debian 0.1.48
ii  python3-debianbts  3.2.0
ii  python3-requests   2.25.1+dfsg-2
ii  sensible-utils 0.0.17

python3-reportbug recommends no packages.

Versions of packages python3-reportbug suggests:
ii  reportbug  11.6.0

-- no debconf information

Bug#1022740: miller: Maybe versions newer than 5.x siliently drop data

[Kingsley G. Morse Jr.]

Package: miller
Version: 6.4.0-1

Thank you very much for maintaining miller.

I like, use and respect it.

The main reason I'm writing is to report a
circumstance where miller 

ignores an empty row of data and 

moves all subsequent rows up.

I don't want to over-react, but I'm worried that
shifting data might lead downstream applications
to misinterpret it.

Here's a small example that elicits the behavior:

$ echo -e "a,b\n1,2\n\n5,6" | mlr --csv cut -f a

At least on my computer, it responded with

a
1
5

I expected to see

a
1

5

The guy maintaining debian's package, Stephen
Kitts, seems to think it used to work with version
5.x.

At least for me, both versions 

6.2.0-1 and 

6.4.0-1

of miller ignored the blank row, both 

with and

without

"--ragged".

Feel free to contact me with any questions or
concerns.

Kind regards,
Kingsley

PS: Normally I'd report bugs with Debian's "reportbug"
command line utility, but at the moment, at least
mine is crashing with the following python error:

AttributeError: module 'collections' has no attribute 'Mapping'

So I'm trying the instructions for sending bug
reports via e-mail at

https://www.debian.org/Bugs/Reporting
-- 
Time is the fire in which we all burn.

Bug#1011255: mathomatic: "Simplify"ing powers can lead to "Complex" results and NaNs

[Kingsley G. Morse Jr.]

Package: mathomatic
Version: 16.0.5-4
Severity: normal

Dear Tony,

Thank you very much for maintaining Debian's
mathomatic package.

It's colorful and easy to use.

The main reason I'm writing is to give a specific
example suggesting, at least to yours truly, that
ol' mathomatic might try to simplify math
expressions containing exponents/powers a little
too agressively.

When I type this at a linux bash shell command
line...

$ mathomatic -e -- "(X^2)^0.50001"

mathomatic returns

1-> (X^2)^0.50001

#1: X^1.2

As you can see, mathomatic automatically
simplifyed the 

"^2" and

"^0.50001"

powers into just

"^1.2"

But, I'm worried that if the X variable contains a
*negative* number, mathomatic's automatic
"simplification" may lead to 

"complex" imaginary numbers and

so called "Not a Number"s (ie: "NaN"s)

down stream.

To be fair, mathomatic's documentation admits

"With Mathomatic, if x is imaginary, you may
get an unwanted imaginary result"

at

https://fossies.org/linux/mathomatic/doc/manual.html

I humbly suggest

1.) Consider enhancing mathomatic to give its
user more control over

when and

how aggressively

it simplifies exponents.

Three options are reviewed at

https://docs.sympy.org/latest/tutorial/simplification.html#powers

Mathomatic's "simplify" command already has a
"symbolic" option that approaches a fix.

You can see this is so at

https://fossies.org/linux/mathomatic/doc/am.html#simplify


2.) Use python's sympy module instead.

But it's not quite as

easy or

colorful.

Thanks again,
Kingsley

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 4.4.0-1-686-pae (SMP w/2 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages mathomatic depends on:
ii  libc6 2.33-7
ii  libedit2  3.1-20210910-1
ii  m41.4.18-2

mathomatic recommends no packages.

Versions of packages mathomatic suggests:
ii  gnuplot5.2.7+dfsg1-3
ii  gnuplot-x11 [gnuplot]  5.2.7+dfsg1-3
pn  rlwrap 

-- no debconf information

Bug#1010184: miller: Parse error on token "1e+"

[Kingsley G. Morse Jr.]

Package: miller
Version: 6.2.0-1
Severity: normal

Hi Stephen,

Thanks again for maintaining a convenient Debian
package of John Kerl's cool "mlr".

I happened to notice mlr doesn't seem to recognize
numbers in scientific notation with explicitly
positive exponents.

Since awk seems to work with them, I 

thought you and maybe John would want to know,
and 

filed this bug report.

Here are some simple examples that I hope will
also reveal the bug on your computer:

$ echo | mlr put 'print 1e+0'

On my computer, mlr complains with:

mlr: cannot parse DSL expression.
Parse error on token "1e+" at line 1 column 7.
Please check for missing semicolon.
Expected one of:
  $ ; { > >> | ( field_name $[ braced_field_name $[[ $[[[ full_srec 
oosvar_name
  @[ braced_oosvar_name full_oosvar all non_sigil_name float int + - .+ .-
  ! ~ string_literal regex_case_insensitive int_literal float_literal 
boolean_literal
  null_literal inf_literal nan_literal const_M_PI const_M_E panic [ ctx_IPS
  ctx_IFS ctx_IRS ctx_OPS ctx_OFS ctx_ORS ctx_FLATSEP ctx_NF ctx_NR ctx_FNR
  ctx_FILENAME ctx_FILENUM env func

I'm happy to report a workaround is simply
omitting the positive "+" sign before the exponent
like this:

$ echo | mlr put 'print 1e0'

At least on my computer, mlr returns

1e0

For what it's worth, here's an analogous example
with the great grand daddy of csv tools, awk:

$ echo | awk '{ print 1e+0 }

At least on my computer, awk returns

1

If I understand the following link correctly, John
originally implemented scientific notation in DSL
literals back in version 3.0.1:

Allow scientific notation in DSL literals; mlr bar --auto
https://github.com/johnkerl/miller/releases/tag/v3.0.1

Thanks again,
Kingsley

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 4.4.0-1-686-pae (SMP w/2 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages miller depends on:
ii  libc6  2.33-7

miller recommends no packages.

miller suggests no packages.

-- no debconf information

Bug#1010046: miller: Negative exponent elicits 'cannot parse DSL expression' and 'Parse error on token "-"'

[Kingsley G. Morse Jr.]

Package: miller
Version: 6.2.0-1
Severity: normal

Hi Stephen,

Thank you very much for maintaining Debian's
miller package.

I'm so impressed with how 

practical and 

sophisticated

it is that I'm inclined to describe it as "an
intellectual tour de force".

The main reason I'm writing is to report what I
think may be 

a minor parsing error and

a way to work around it.

Here's a nice, short and sweet one liner that
demonstrates the problem on bash's command line,
at least on my computer:

$ echo |  mlr put -q 'print 2**-0.5' 
  mlr: cannot parse DSL expression.
  Parse error on token "-" at line 1 column 10.
  Expected one of:
{ ( field_name $[ braced_field_name $[[ $[[[ full_srec oosvar_name @[ 
braced_oosvar_name
full_oosvar all non_sigil_name float int string_literal 
regex_case_insensitive
int_literal float_literal boolean_literal null_literal inf_literal 
nan_literal
const_M_PI const_M_E panic [ ctx_IPS ctx_IFS ctx_IRS ctx_OPS ctx_OFS 
ctx_ORS
ctx_FLATSEP ctx_NF ctx_NR ctx_FNR ctx_FILENAME ctx_FILENUM env func

Please note that mlr appears to be unable to parse
the negative exponent "-0.5".

I'm happy to report I worked around the problem by
enclosing the negative exponent in parentheses.

Here's an example:

$ echo |  mlr put -q 'print 2**(-0.5)'
0.7071067811865475

If you decide to mention this issue to the
upstream author, John Kerl, feel free to let him
know how impressed I am with his code.

Thanks,
Kingsley

miller recommends no packages.

miller suggests no packages.

-- no debconf information

Bug#1003378: More data for Bug 1003378

[Kingsley G. Morse Jr.]

I tried again.

This time, I did

$ aptitude install kde-standard

and then tried adding the same .mp4 file to
Kdenlive's project bin.

Kdenlive didn't crash this time, but it

1.) openned an orange error window that says

"Cannot open file
/home/kingsley/doc/movies/public_domain/
Twelve+Days+of+Christmas+(Instrumental)+(feat.
+Public+Domain+Royalty+Free+Music)-F-b6WYUHBWY.mp4"

and

2.) printed this on the console

=== REG FOCUS:  true
qml: item not found
=== REG FOCUS:  false
/// starting to add bin clips
/// found list 
(QUrl("file:///home/kingsley/doc/movies/public_domain/Twelve+Days+of+Christmas+(Instrumental)+(feat.+Public+Domain+Royalty+Free+Music)-F-b6WYUHBWY.mp4"))
/// creatclipsfromlist 
(QUrl("file:///home/kingsley/doc/movies/public_domain/Twelve+Days+of+Christmas+(Instrumental)+(feat.+Public+Domain+Royalty+Free+Music)-F-b6WYUHBWY.mp4"))
 true "-1"
/// createClipFromFile 
"/home/kingsley/doc/movies/public_domain/Twelve+Days+of+Christmas+(Instrumental)+(feat.+Public+Domain+Royalty+Free+Music)-F-b6WYUHBWY.mp4"
 "-1"
=== GOT DROPPED MIME:  "video/mp4"
/// final xml "\n /home/kingsley/doc/movies/public_domain/Twelve+Days+of+Christmas+(Instrumental)+(feat.+Public+Domain+Royalty+Free+Music)-F-b6WYUHBWY.mp4\n\n"
== STARTING TASK FOR:  4
/// creatclipsfromlist return false
STARTING LOAD TASK FOR:  
"/home/kingsley/doc/movies/public_domain/Twelve+Days+of+Christmas+(Instrumental)+(feat.+Public+Domain+Royalty+Free+Music)-F-b6WYUHBWY.mp4"
 

:::
QFSFileEngine::open: No file name specified
// WARNING EMPTY CLIP HASH: 
== READY FOR TASK DELETION ON:  4
= REMOVING MASTER PRODUCER; CURRENT COUNT:  0 
:::

You can try to replicate it with the video at

https://invidious.snopyta.org/watch?v=F-b6WYUHBWY

Download the version...

"audio/mp4 @ 131.141k audio only"

I wonder if a bug is in 

creatclipsfromlist

or

createClipFromFile

Thanks,
Kingsley

-- 
Time is the fire in which we all burn.

Bug#1003378: QFSFileEngine::open: No file name specified...

[Kingsley G. Morse Jr.]

Package: kdenlive
Version: 21.12.1-1
Severity: important

Hi Padrick,

Thank you for maintaining Debian's kdenlive
package.

It can be a lot of fun!

I seem to have found a bug after upgrading to version 21.12.1-1.

I ran kdenlive on the command line

user$ kdenlive &

then followed the menu path

"Add Clip or Folder"





Then I see this in the console

=== REG FOCUS:  false
/// found list 
(QUrl("file:///home/kingsley/doc/movies/public_domain/Twelve+Days+of+Christmas+(Instrumental)+(feat.+Public+Domain+Royalty+Free+Music)-F-b6WYUHBWY.mp4"))
/// creatclipsfromlist 
(QUrl("file:///home/kingsley/doc/movies/public_domain/Twelve+Days+of+Christmas+(Instrumental)+(feat.+Public+Domain+Royalty+Free+Music)-F-b6WYUHBWY.mp4"))
 true "-1"
/// createClipFromFile 
"/home/kingsley/doc/movies/public_domain/Twelve+Days+of+Christmas+(Instrumental)+(feat.+Public+Domain+Royalty+Free+Music)-F-b6WYUHBWY.mp4"
 "-1"
=== GOT DROPPED MIME:  "video/mp4"
/// final xml "\n /home/kingsley/doc/movies/public_domain/Twelve+Days+of+Christmas+(Instrumental)+(feat.+Public+Domain+Royalty+Free+Music)-F-b6WYUHBWY.mp4\n\n"
== STARTING TASK FOR:  2
/// creatclipsfromlist return false
STARTING LOAD TASK FOR:  
"/home/kingsley/doc/movies/public_domain/Twelve+Days+of+Christmas+(Instrumental)+(feat.+Public+Domain+Royalty+Free+Music)-F-b6WYUHBWY.mp4"
 

:::
QFSFileEngine::open: No file name specified
// WARNING EMPTY CLIP HASH: 
== READY FOR TASK DELETION ON:  2
= REMOVING MASTER PRODUCER; CURRENT COUNT:  0 
:::
terminate called after throwing an instance of 'std::out_of_range'
  what():  _Map_base::at

After I wait maybe about a minute, kdenlive
crashed.

I expected it to add the video file to kdenlive's
project bin and keep working.

Feel free to suggest what I might try next.

Thanks again,
Kingsley

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 4.4.0-1-686-pae (SMP w/2 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages kdenlive depends on:
ii  breeze 4:5.23.4-1
ii  breeze-icon-theme  4:5.88.0-2
ii  ffmpeg 7:4.4.1-1
ii  gstreamer1.0-plugins-bad   1.18.4-2
ii  kded5  5.77.0-2
ii  kdenlive-data  21.12.1-1
ii  kinit  5.77.0-2
ii  kio5.88.0-1
ii  libc6  2.33-2
ii  libgcc-s1  11.2.0-13
ii  libkf5archive5 5.88.0-1
ii  libkf5bookmarks5   5.88.0-1
ii  libkf5completion5  5.88.0-1
ii  libkf5configcore5  5.88.0-1
ii  libkf5configgui5   5.88.0-1
ii  libkf5configwidgets5   5.88.0-1
ii  libkf5coreaddons5  5.88.0-1
ii  libkf5crash5   5.88.0-1
ii  libkf5dbusaddons5  5.88.0-1
ii  libkf5declarative5 5.88.0-1
ii  libkf5filemetadata35.77.0-2
ii  libkf5guiaddons5   5.88.0-1
ii  libkf5i18n55.88.0-2
ii  libkf5iconthemes5  5.88.0-1
ii  libkf5itemviews5   5.88.0-1
ii  libkf5jobwidgets5  5.88.0-1
ii  libkf5kiocore5 5.88.0-1
ii  libkf5kiofilewidgets5  5.88.0-1
ii  libkf5kiogui5  5.88.0-1
ii  libkf5kiowidgets5  5.88.0-1
ii  libkf5newstuff55.88.0-1
ii  libkf5newstuffcore55.88.0-1
ii  libkf5notifications5   5.88.0-2
ii  libkf5notifyconfig55.77.0-2
ii  libkf5purpose-bin  5.77.0-2
ii  libkf5purpose5 5.77.0-2
ii  libkf5service-bin  5.88.0-1
ii  libkf5service5 5.88.0-1
ii  libkf5solid5   5.88.0-1
ii  libkf5textwidgets5 5.88.0-1
ii  libkf5widgetsaddons5   5.88.0-2
ii  libkf5xmlgui5  5.88.0-1
ii  libmlt++7  7.4.0-1
ii  libmlt77.4.0-1
ii  libqt5core5a   5.15.2+dfsg-14
ii  libqt5dbus55.15.2+dfsg-14
ii  libqt5gui5 5.15.2+dfsg-14
ii  libqt5multimedia5  5.15.2-3
ii  libqt5network5 5.15.2+dfsg-14
ii  libqt5networkauth5 5.15.2-2
ii  libqt5qml5 5.15.2+dfsg-9
ii  libqt5quick5-gles  5.15.2+dfsg-3
ii  libqt5quickcontrols2-5 5.15.2+dfsg-2
ii  libqt5quickwidgets55.15.2+dfsg-2
ii  libqt5svg5 5.15.2-3
ii  libqt5widgets5 5.15.2+dfsg-14
ii  libqt5xml5 5.15.2+dfsg-14
ii  libstdc++6 11.2.0-13
ii  melt   6.24.0-1
ii  

Bug#998363: certbot: Too many flags setting configurators/installers/authenticators

[Kingsley G. Morse Jr.]

Package: certbot
Version: 1.18.0-1
Severity: normal

Dear Maintainer,

Thank you very much for generously sharing your
time and skill.


It's not a crisis, but I humbly suggest improving
a certain error message to lead users to faster
fixes.

When I do

root$ certbot certonly --apache --manual --dry-run 

certbot complains with

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Too many flags setting configurators/installers/authenticators 'apache' -> 
'manual'
Ask for help or search for solutions at https://community.letsencrypt.org. 
See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v 
for more details.

The fix appears to be

root$ certbot certonly -i apache -a manual --dry-run


Maybe certbot's error message could be improved from

Too many flags setting configurators/installers/authenticators 'apache' -> 
'manual'

to something more helpful like

Try rep[acing "--apache --manual" with "-i apache -a manual".


So it is said.

So it is done.

Reporting bugs may be fun, but

thanking maintainers is number one!

Thanks,
Kingsley


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 4.4.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages certbot depends on:
ii  cdebconf [debconf-2.0]  0.253
ii  debconf [debconf-2.0]   1.5.74
ii  python3-certbot 1.18.0-1
pn  python3:any 

certbot recommends no packages.

Versions of packages certbot suggests:
pn  python-certbot-doc  
ii  python3-certbot-apache  1.18.0-1
pn  python3-certbot-nginx   

-- Configuration Files:
/etc/letsencrypt/cli.ini changed [not included]

-- debconf information excluded

Bug#989706: csvformat has a similar warning

[Kingsley G. Morse Jr.]

$ echo -e "1,2,3\n4,5,6\n7,8" | csvformat -d , -D ,
/usr/lib/python3/dist-packages/unittest2/compatibility.py:143: 
DeprecationWarning: Using or importing the ABCs from 'collections' instead of 
from 'collections.abc' is deprecated since Python 3.3, and in 3.10 it will stop 
working
1,2,3
4,5,6
7,8

-- 
Time is the fire in which we all burn.

Bug#989706: csvkit: DeprecationWarning from csvclean

[Kingsley G. Morse Jr.]

Package: csvkit
Version: 1.0.5-2
Severity: normal

Dear Maintainer,

Thank you very much for sharing your valuable time
and skill to maintain Debian's csvkit package.

Here's a one-liner that causes its "csvclean"
command to complain, at least on my computer.

bash$ echo -e "1,2,3\n4,5,6\n7,8" | csvclean 
/usr/lib/python3/dist-packages/unittest2/compatibility.py:143: 
DeprecationWarning: Using or importing the ABCs from 'collections' instead of 
from 'collections.abc' is deprecated since Python 3.3, and in 3.10 it will stop 
working
1 error logged to stdin_err.csv

I'd like to think eliminating the warning is as
easy as importing the ABCs from 'collections.abc'.

Maybe you'd like to use my little one liner to
test fixes for csvkit and python3-csvkit.

Thanks again,
Kingsley

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 4.4.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages csvkit depends on:
ii  python3-csvkit  1.0.5-2
pn  python3:any 

csvkit recommends no packages.

Versions of packages csvkit suggests:
ii  csvkit-doc  1.0.2-1

-- no debconf information

Bug#988613: gnumeric: SIGSEGV, Segmentation fault from /usr/lib/goffice/0.10.44/plugins/plot_surface/surface.so

[Kingsley G. Morse Jr.]

Package: gnumeric
Version: 1.12.44-1
Severity: normal

Dear Dmitry,

Thanks again for maintaining the very cool and
useful gnumeric package for Debian's epic
distribution.

   * What led up to the situation?

 A head wind of bugs mightier than a biblical
 plague of locust swarming through a computer
 buggier than Maine in June.

 corrupted_workbook.gnumeric is a Gnumeric
 workbook with many sheets, one of which is
 corrupted. 

 Where once a mighty sheet was filled with
 data, now only 

comments,

empty charts and

the last number entered

 remain!


   * What exactly did you do (or not do) that was effective (or
 ineffective)?

 Typing this at the command line

$ gnumeric corrupted_workbook.gnumeric


   * What was the outcome of this action?

An almighty "Segmentation fault".

 Here's the back trace from gdb:

Starting program: /usr/bin/gnumeric 
Using host libthread_db library 
"/lib/x86_64-linux-gnu/libthread_db.so.1".
Thread 1 "gnumeric" received signal SIGSEGV, Segmentation fault.
0x70056339 in ?? () from 
/usr/lib/goffice/0.10.44/plugins/plot_surface/surface.so
#0  0x70056339 in ?? () from 
/usr/lib/goffice/0.10.44/plugins/plot_surface/surface.so
#1  0x76fdaac4 in ?? () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x76fda8b4 in ?? () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x76fda8a6 in ?? () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x76fda8a6 in ?? () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x76fda8a6 in ?? () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#6  0x76fda8a6 in ?? () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#7  0x76fda8a6 in ?? () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#8  0x76fda8a6 in ?? () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#9  0x76fda8a6 in ?? () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#10 0x76fda8a6 in ?? () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#11 0x76fda8a6 in ?? () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#12 0x76fdad2f in ?? () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#13 0x7005786f in ?? () from 
/usr/lib/goffice/0.10.44/plugins/plot_surface/surface.so
#14 0x70056cb4 in ?? () from 
/usr/lib/goffice/0.10.44/plugins/plot_surface/surface.so
#15 0x77957314 in gog_object_update () from 
/lib/libgoffice-0.10.so.10
#16 0x779572b4 in gog_object_update () from 
/lib/libgoffice-0.10.so.10
#17 0x779572b4 in gog_object_update () from 
/lib/libgoffice-0.10.so.10
#18 0x77960387 in gog_graph_force_update () from 
/lib/libgoffice-0.10.so.10
#19 0x77c28ab0 in workbook_update_graphs () from 
/lib/libspreadsheet-1.12.44.so
#20 0x77c27104 in workbook_view_new_from_input () from 
/lib/libspreadsheet-1.12.44.so
#21 0x77c2734d in workbook_view_new_from_uri () from 
/lib/libspreadsheet-1.12.44.so
#22 0x77b73cba in gui_file_read () from 
/lib/libspreadsheet-1.12.44.so
#23 0x77b746ae in gui_file_open () from 
/lib/libspreadsheet-1.12.44.so
#24 0x770acc8d in g_closure_invoke () from 
/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#25 0x770c0365 in ?? () from 
/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#26 0x770c92be in g_signal_emit_valist () from 
/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#27 0x770c997f in g_signal_emit () from 
/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#28 0x7729a7e0 in ?? () from 
/lib/x86_64-linux-gnu/libgtk-3.so.0
#29 0x770acec6 in ?? () from 
/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#30 0x770c938d in g_signal_emit_valist () from 
/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#31 0x770c997f in g_signal_emit () from 
/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#32 0x7756888a in gtk_widget_activate () from 
/lib/x86_64-linux-gnu/libgtk-3.so.0
#33 0x7743ba86 in gtk_menu_shell_activate_item () from 
/lib/x86_64-linux-gnu/libgtk-3.so.0
#34 0x7743bd23 in ?? () from 
/lib/x86_64-linux-gnu/libgtk-3.so.0
#35 0x775b8274 in ?? () from 
/lib/x86_64-linux-gnu/libgtk-3.so.0
#36 0x770acec6 in ?? () from 
/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#37 0x770c8d74 in g_signal_emit_valist () from 
/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#38 0x770c997f in g_signal_emit () from 
/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#39 

Bug#988403: gnumeric: http://www.gnumeric.org/v10.dtd and http://www.gnumeric.org/v9.xsd do not exist

[Kingsley G. Morse Jr.]

Package: gnumeric
Version: 1.12.48-1+b2
Severity: minor

Hi Dmitry,

I happened to notice 2 URLs in the second line of a
gnumeric work book do not exist.

They are

http://www.gnumeric.org/v10.dtd

and

http://www.gnumeric.org/v9.xsd

You can see this is so by using the attached file
"bug.gnumeric" as follows

$zcat  bug.gnumeric | sed -n 2p

I imagine several fixes.

1.) Add the pages to www.gnumeric.org.

2.) Delete the second line of the workbook's XML.

3.) Put working URLs in the second line of the workbook's XML.

Thanks again!
Kingsley

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 4.4.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages gnumeric depends on:
ii  cdebconf [debconf-2.0]  0.253
ii  debconf [debconf-2.0]   1.5.74
ii  gnumeric-common 1.12.48-1
ii  gsfonts 1:8.11+urwcyr1.0.7~pre44-4.4
ii  libatk1.0-0 2.36.0-2
ii  libc6   2.31-10
ii  libcairo2   1.16.0-5
ii  libgdk-pixbuf2.0-0  2.40.2-2
ii  libglib2.0-02.66.7-2
ii  libgoffice-0.10-10  0.10.48-1
ii  libgsf-1-1141.14.46-1
ii  libgtk-3-0  3.24.20-1
ii  libpango-1.0-0  1.46.2-3
ii  libpangocairo-1.0-0 1.46.2-3
ii  libxml2 2.9.10+dfsg-6.6
ii  procps  2:3.3.15-2+b1
ii  pxlib1  0.6.7-1+b1
ii  zlib1g  1:1.2.11.dfsg-2

Versions of packages gnumeric recommends:
ii  evince3.32.0-3
ii  gnumeric-doc  1.12.48-1
ii  lp-solve  5.5.2.5-2

Versions of packages gnumeric suggests:
ii  fonts-liberation1:1.07.4-11
ii  gnumeric-plugins-extra  1.12.48-1+b2
pn  libgsf-1-dev

-- debconf information:
  gnumeric/existing-process-title:
* gnumeric/existing-process: false


bug.gnumeric
Description: application/gzip

Bug#988397: gnumeric: [GOData::get_value] Wrong number of coordinates (given 2 - needed 1)

[Kingsley G. Morse Jr.]

Package: gnumeric
Version: 1.12.48-1+b2
Severity: normal

Hi Dmitry,

Thank you very much for maintaining Debian's
gnumeric package!

Here's a bug report that gnumeric's
developer named Jean asked me to file.

He would prefer it is filed at gitlab.gnome.org.

Maybe that would be easier for you than I.

I don't have an account, and it's sign page said

""Please note that due to spam, new user
registrations are disabled."


   * What led up to the situation?

Typing 

$ gnumeric bug.gnumeric

on the command line of a FrankenUnstableDebian
computer whose packages are updated peicemeal
by doing

$ apt-get install 


   * What was the outcome of this action?

gnumeric complaining with thousands of

** (gnumeric:28770): WARNING **: 15:23:36.184: [GOData::get_value] 
Wrong number of coordinates (given 2 - needed 1)

on the console.

   * What outcome did you expect instead?

   No warnings.

A copy of the workbook that elicits the warnings
should be attached to this bug report.

Thanks,
Kingsley

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 4.4.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages gnumeric depends on:
ii  cdebconf [debconf-2.0]  0.253
ii  debconf [debconf-2.0]   1.5.74
ii  gnumeric-common 1.12.48-1
ii  gsfonts 1:8.11+urwcyr1.0.7~pre44-4.4
ii  libatk1.0-0 2.36.0-2
ii  libc6   2.31-10
ii  libcairo2   1.16.0-5
ii  libgdk-pixbuf2.0-0  2.40.2-2
ii  libglib2.0-02.66.7-2
ii  libgoffice-0.10-10  0.10.48-1
ii  libgsf-1-1141.14.46-1
ii  libgtk-3-0  3.24.20-1
ii  libpango-1.0-0  1.46.2-3
ii  libpangocairo-1.0-0 1.46.2-3
ii  libxml2 2.9.10+dfsg-6.6
ii  procps  2:3.3.15-2+b1
ii  pxlib1  0.6.7-1+b1
ii  zlib1g  1:1.2.11.dfsg-2

Versions of packages gnumeric recommends:
ii  evince3.32.0-3
ii  gnumeric-doc  1.12.48-1
ii  lp-solve  5.5.2.5-2

Versions of packages gnumeric suggests:
ii  fonts-liberation1:1.07.4-11
ii  gnumeric-plugins-extra  1.12.48-1+b2
pn  libgsf-1-dev

-- debconf information:
  gnumeric/existing-process-title:
* gnumeric/existing-process: false


bug.gnumeric
Description: application/gzip

Bug#977579: Yes, Andreas helped (Was: Bug#977579: gnumeric: Please ask upstream...)

[Kingsley G. Morse Jr.]

On 12/18/2020 09:58, Dmitry Smirnov wrote:
> On Thursday, 17 December 2020 3:22:28 PM AEDT Kingsley G. Morse Jr. wrote:
> > Thank you very much for maintaining gnumeric!
> 
> Thank you for your kind words.

You're welcome!

And thanks for the links to 

1.) Andreas' report of now()'s issue today at

https://gitlab.gnome.org/GNOME/gnumeric/-/issues/549


2.) and arguably the very important data about
COVID-19 lockdowns surprisingly INcreasing
mortality at 


https://medium.com/@JohnPospichal/questions-for-lockdown-apologists-32a9bbf2e247

My quick and dirty search for rebutals to it
at duckduckgo.com suggests it hasn't been
refuted!


Keep up the good work and HAPPY HOLIDAYS!
Kingsley

-- 
Time is the fire in which we all burn.

Bug#977579: gnumeric: Please ask upstream to increase the precision of "=now()" to at least milliseconds.

[Kingsley G. Morse Jr.]

Package: gnumeric
Version: 1.12.47-1
Severity: wishlist

Dear Dmitry, 

Thank you very much for maintaining gnumeric!

I like it very much and have used it many times.

The main reason I'm writing is to politely ask you
to please forward something like an enhancement
request or bug report to gnumeric's fine upstream
maintainers.

I'd like gnumeric's "=now()" time function to be
more precise.

My testing and reading suggest the most precise
time gnumeric's =now() currently supports is 1
second intervals.

This is done with time formats like "[mm]:ss".

However localc (Libre Office Calc), and evidently
also Excel, can format times with much greater
precision.

Like in milliseconds.

localc supports it with the "MM:SS.000" format.

I tried to report this directly to the gnumeric
guys at

https://gitlab.gnome.org/GNOME/gnumeric/-/issues

but it says

"new user registrations are disabled".

Thanks again for sharing your skill so generously!

Happy holidays,
Kingsley

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 4.4.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages gnumeric depends on:
ii  cdebconf [debconf-2.0]  0.253
ii  debconf [debconf-2.0]   1.5.74
ii  gnumeric-common 1.12.47-1
ii  gsfonts 1:8.11+urwcyr1.0.7~pre44-4.4
ii  libatk1.0-0 2.36.0-2
ii  libc6   2.31-5
ii  libcairo2   1.16.0-4
ii  libgdk-pixbuf2.0-0  2.40.0+dfsg-8
ii  libglib2.0-02.64.4-1
ii  libgoffice-0.10-10  0.10.46-1
ii  libgsf-1-1141.14.46-1
ii  libgtk-3-0  3.24.20-1
ii  libpango-1.0-0  1.46.1-1
ii  libpangocairo-1.0-0 1.46.1-1
ii  libxml2 2.9.10+dfsg-6.2
ii  procps  2:3.3.15-2+b1
ii  pxlib1  0.6.7-1+b1
ii  zlib1g  1:1.2.11.dfsg-2

Versions of packages gnumeric recommends:
ii  evince3.32.0-3
ii  gnumeric-doc  1.12.47-1
ii  lp-solve  5.5.0.15-4+b1

Versions of packages gnumeric suggests:
ii  fonts-liberation1:1.07.4-11
ii  gnumeric-plugins-extra  1.12.47-1
pn  libgsf-1-dev

-- debconf information:
  gnumeric/existing-process-title:
* gnumeric/existing-process: true

Bug#973512: RuntimeError: dictionary keys changed during iteration

[Kingsley G. Morse Jr.]

Package: onioncircuits
Version: 0.7-1
Severity: normal

Dear Maintainer,

Thank you for maintaining onioncircuits.

Much like the tenet of patron privacy that public
libraries hold dear, I love the ideal of voters
using TOR to privately and safely explore new
ideas without fear of repercussion from neighbors
or employers, and ultimately become a better
informed electorate that can actually rule itself
wisely enough to successfully sustain a democratic
form of government.

The main reason I'm writing is to suggest
improving the dependency info for the
onioncircuits package to specify at least version
1.8.0-2 of the python3-stem package.

It currently accepts any version, but when I tried
1.7.1-1, onioncircuits failed with

Traceback (most recent call last):
  File "/usr/bin/onioncircuits", line 668, in 
app = OnionCircuitsApplication()
  File "/usr/bin/onioncircuits", line 644, in __init__
self.connect_controller()
  File "/usr/bin/onioncircuits", line 658, in connect_controller
self.controller = stem.connection.connect(**connect_args)
  File "/usr/lib/python3/dist-packages/stem/connection.py", line 291, in 
connect
return _connect_auth(control_connection, password, password_prompt, 
chroot_path, controller)
  File "/usr/lib/python3/dist-packages/stem/connection.py", line 375, in 
_connect_auth
return controller(control_socket, is_authenticated = True)
  File "/usr/lib/python3/dist-packages/stem/control.py", line 1057, in 
__init__
super(Controller, self).__init__(control_socket, is_authenticated)
  File "/usr/lib/python3/dist-packages/stem/control.py", line 585, in 
__init__
self._post_authentication()
  File "/usr/lib/python3/dist-packages/stem/control.py", line 3902, in 
_post_authentication
owning_pid = self.get_conf('__OwningControllerProcess', None)
  File "/usr/lib/python3/dist-packages/stem/control.py", line 2170, in 
get_conf
entries = self.get_conf_map(param, default, multiple)
  File "/usr/lib/python3/dist-packages/stem/control.py", line 2273, in 
get_conf_map
for key in reply:
RuntimeError: dictionary keys changed during iteration


Doing 

root$ aptitude install python3-stem

fixed it.

Thanks, and kind regards,
Kingsley

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 4.4.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages onioncircuits depends on:
ii  gir1.2-glib-2.01.62.0-5
ii  gir1.2-gtk-3.0 3.24.13-1
ii  python3-gi 3.34.0-6
ii  python3-pkg-resources  41.1.0-1
ii  python3-pycountry  20.7.3+ds1-1
ii  python3-stem   1.8.0-2
pn  python3:any

onioncircuits recommends no packages.

Versions of packages onioncircuits suggests:
ii  tor-geoipdb  0.4.2.7-1

-- no debconf information

Bug#972121: ImportError: cannot import name 'load_emacs_shift_selection_bindings' from...

[Kingsley G. Morse Jr.]

Package: xonsh
Version: 0.9.22+dfsg-1
Severity: important

TLDR; Add a dependency on at least version 3.0.7-1 of python3-prompt-toolkit.

Dear Maintainer,

Thank you very much for maintaining the cool
looking package named "xonsh".

I've often wanted to combine python's array math
with shell pipes, like APL and jsoftware.

So I tried installing the xonsh package, and
running it.

$ ~ xonsh
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/xonsh/__amalgam__.py", line 24554, 
in main
args = premain(argv)
  File "/usr/lib/python3/dist-packages/xonsh/__amalgam__.py", line 24490, 
in premain
env = start_services(shell_kwargs, args)
  File "/usr/lib/python3/dist-packages/xonsh/__amalgam__.py", line 24439, 
in start_services
builtins.__xonsh__.shell = Shell(execer=execer, **shell_kwargs)
  File "/usr/lib/python3/dist-packages/xonsh/__amalgam__.py", line 16310, 
in __init__
from xonsh.ptk_shell.shell import PromptToolkitShell as shell_class
  File "/usr/lib/python3/dist-packages/xonsh/ptk_shell/shell.py", line 24, 
in 
from prompt_toolkit.key_binding.bindings.emacs import (
ImportError: cannot import name 'load_emacs_shift_selection_bindings' from 
'prompt_toolkit.key_binding.bindings.emacs' 
(/usr/lib/python3/dist-packages/prompt_toolkit/key_binding/bindings/emacs.py)
Xonsh encountered an issue during launch
Failback to /bin/bash

As you can see, it failed.

Next, I checked which package contains a file
xonsh complained about.

$ apt-file search 
/usr/lib/python3/dist-packages/prompt_toolkit/key_binding/bindings/emacs.py
python3-prompt-toolkit: 
/usr/lib/python3/dist-packages/prompt_toolkit/key_binding/bindings/emacs.py

Next, I checked if a newer version of the python3-prompt-toolkit was available.

$ apt-cache policy python3-prompt-toolkit
[...]
Installed: 2.0.10-2
Candidate: 3.0.7-1
[...]

Next, I upgraded python3-prompt-toolkit from
version 2.0.10-2 to 3.0.7-1.

root$ aptitude install python3-prompt-toolkit

Then I tried running xonsh again.

$ xonsh
~ Crustaceanly Yours ~

It worked!

So, it seems to me that Debian's fine xonsh
package might be improved by adding a dependency
for at least version 3.0.7-1 of the
python3-prompt-toolkit package.

So it is said.

So it is done.

Correct package dependencies, are

(wait for it...)

NUMBER ONE!

;-)

So,
Kingsley


*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 4.4.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages xonsh depends on:
ii  python3-ply  3.11-4
pn  python3:any  

Versions of packages xonsh recommends:
ii  python3-prompt-toolkit  3.0.7-1
ii  python3-pygments2.3.1+dfsg-1
ii  python3-setproctitle1.1.10-2

Versions of packages xonsh suggests:
pn  xonsh-doc  

-- no debconf information

Bug#969399: bash-completion: Hang completing ~userame inside command substitution solved by upgrading

[Kingsley G. Morse Jr.]

Package: bash-completion
Version: 1:2.11-2
Severity: minor

   * What led up to the situation?

1.) Using version 1:2.9-1 and

2.) Typing

 $ egrep -i keyword $( find ~kin^I

3.) but bash hung, and didn't respond to
pressing control-c. 

I expected pressing the tab key to let
bash-completion complete "~kin" to
~kingsley/.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

1.) Upgrading to version 1:2.11-2

2.) launching a new shell

3.) completion worked!

Thanks,
Kingsley

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 4.4.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

-- no debconf information

Bug#967401: ginkgocadx: version `WXU_3.0.5' not found

[Kingsley G. Morse Jr.]

Package: ginkgocadx
Followup-For: Bug #967401

For what it's worth

1.) version 3.0.4+dfsg-10 of the
libwxgtk3.0-gtk3-0v5 package seems to have
caused ginkgocadx to

complain with

ginkgocadx: /usr/lib/i386-linux-gnu/libwx_gtk3u_core-3.0.so.0: 
version `WXU_3.0.5' not found (required by ginkgocadx)

and refuse to run, and

2.) Upgrading libwxgtk3.0-gtk3-0v5 to version
3.0.5.1+dfsg-2 seems to have fixed the
problem.

To be fair, the ginkgocadx package depends on >=
version 3.0.4+dfsg-10~ of libwxgtk3.0-gtk3-0v5,
which looks close to my version that elicited the
error. 

I dunno what the trailing "~" means in the
version.

I hope that helps.

Peace,
Kingsley

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 4.4.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages ginkgocadx depends on:
ii  libc6  2.30-4
ii  libcairo2  1.16.0-4
ii  libcurl3-gnutls7.72.0-1
ii  libdcmtk14 3.6.4-2
ii  libgcc11:9.2.1-24
ii  libgl1 1.3.1-1
ii  libgtk-3-0 3.24.20-1
ii  libinsighttoolkit4.13  4.13.2-dfsg1-8+b2
ii  libjsoncpp11.7.4-3+b1
ii  libsqlite3-0   3.32.2-2
ii  libssl1.1  1.1.1d-2
ii  libstdc++6 9.2.1-24
ii  libvtk6.3  6.3.0+dfsg2-5+b2
ii  libwxbase3.0-0v5   3.0.5.1+dfsg-2
ii  libwxgtk3.0-gtk3-0v5   3.0.5.1+dfsg-2

ginkgocadx recommends no packages.

ginkgocadx suggests no packages.

-- no debconf information

Bug#961313: Thanks! (Was: Bug#961313: pyspread: Fix example in package's tutorial?)

[Kingsley G. Morse Jr.]

Dear Andreas,

Thank you very much!

Sharing your tech skill so quickly and generously
are all fine qualities!

Kind regards,
Kingsley

On 05/23/2020 12:45, Andreas Noteng wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Looks like Pyspread is not correctly rendering the markdown files, the file
> included in the package is the same one that is used by upstream on the web
> page. I have identified the error and will try to make a patch to have the
> files display correctly.
> 
> Andreas
> -BEGIN PGP SIGNATURE-
> Version: FlowCrypt 7.7.7 Gmail Encryption
> Comment: Seamlessly send and receive encrypted email
> 
> wsFcBAEBCgAGBQJeyVMNAAoJELRG7qgympRa50UP/2zbvG+04Zg0tODNLn/4
> oaF2xJyRUqpujGV1bKzEwiDdJ8a4Ef35h9G9LH++gP0ikoYpG1EUnSg6WgU+
> wgkdZuAlxQ00BwScSD9tQe0L2ys/m1kkykM8lyNfMHMIUq2ofeDvm1WBlVMa
> FeJp3KX4xAZRcWjaQUXA4fNxst1RIY0sBB5mS9hT1WiwBzkr47jAeFxQmMHS
> BDhCMMpYz67MWaXcihj5YiO2TBntCIjlrNu+RrSUtTWZ5M40hIY8baB1J1Zs
> zBPFSOpnlJwo5Urwb1MoD/4IQyRZURI5J7DkHv/sH9Wuf4G/Y1g+7uSXFY3x
> AVKMpQSKRi62kkZw6g8K6CqsqxdNaX0b5pNniVEQ1XaBpWNyFxoplKucmqb+
> 5Mxw8XAooV+gxn0vNDCZm9sjXQhpRswqsjG3PJNE1jxHHEqe/47dmrll9aVb
> 4yGaX5X5LnwB2cVILbLe6SARBnp758hRTJuT9i5YCikj8kc99oEuXOaq48nc
> IzLSs9hHKvOzQkbOMo6MLjZG/xlmlL2KuFXH3JFWvQ33UPWmbw8/cWPyyPES
> Je/4DjU5F/QUmuuhMkXzNUtsRSoCwb/j1qaG8QVcoA23LCoydPIwJdmLfZMF
> /KxltD9TLEnVM7oNczOBA7LCnZjw/pz24wPsxGy8/0xsOnf5hJL7E4Fe8HMO
> BgZt
> =1tua
> -END PGP SIGNATURE-

-- 
Time is the fire in which we all burn.

Bug#961313: pyspread: Fix example in package's tutorial?

[Kingsley G. Morse Jr.]

Package: pyspread
Version: 1.99.2-2
Severity: normal

Dear Andreas,

Thanks for pyspread.

I installed version 1.99.2-2.

I tried an example in its tutorial.

pyspread->Help->Tutorial says

"Select the top-left cell and type: python 1 + 5 * 2"

but when I type

python 1 + 5 * 2

in cell [0, 0, 0], pyspread complains with

"invalid syntax (, line1)"

I expected to see

11

So, I checked the documentation on line at

https://pyspread.gitlab.io/tutorial.html

It suggests typing

1 + 5 * 2

(no "python " ).

It works!

Yay!

Maybe the tutorial in debian's package should be
more like the Quick Start Tutorial online at

https://pyspread.gitlab.io/tutorial.html

Thanks,
Kingsley








*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 4.4.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages pyspread depends on:
ii  python3  3.7.5-1
ii  python3-numpy1:1.16.5-1
ii  python3-pyqt55.14.1+dfsg-2
ii  python3-pyqt5.qtsvg  5.14.1+dfsg-2
pn  python3:any  

Versions of packages pyspread recommends:
ii  python3-enchant 3.0.1-1
ii  python3-matplotlib  3.0.2-2

pyspread suggests no packages.

-- no debconf information

Bug#958280: https://wiki.debian.org/DokuWiki says no farming yet

[Kingsley G. Morse Jr.]

At least to me

https://wiki.debian.org/DokuWiki

seems to make contradictory claims about whether
Debain supports farming.

https://wiki.debian.org/DokuWiki#Configuration_of_multisite_support_.28farm.29_with_virtual_hosts

suggests it works, but

https://wiki.debian.org/DokuWiki#Questions_and_answers

suggests it doesn't.

So,
Kingsley

-- 
Time is the fire in which we all burn.

Bug#958280: dokuwiki: Firefox says "404 Not Found" for URL of newly created multisite farm animal

[Kingsley G. Morse Jr.]

Package: dokuwiki
Version: 0.0.20180422.a-2
Severity: normal

Hi Tanguuy,

Thanks for maintaining Debian's dokuwiki package.

I like the simplicity of not depending on a
database.

I've been using dokuwiki for years.

The main reason I'm writing is I'm worried I may
have found a bug.

But maybe I just don't understand the
documentation.

   * What led up to the situation?

I've maintained a local wiki on my daily
driver/local host computer for years.

Firefox finds it at an apache virtual host

localhost:2001/dokuwiki

I want to add a second wiki.

Dokuwiki calls it a multisite farm animal.


   * What exactly did you do (or not do) that was effective (or
 ineffective)?

I upgraded from version 0.0.20180422.a-1 to 0.0.20180422.a-2

$ aptitude install dokuwiki

Then I added a new wiki

$ dokuwiki-addsite testsite2

It seemed to add OK.

Then I tried to access the new farm animal/wiki through Firefox at

http://localhost:2001/dokuwiki/testsite2

   * What was the outcome of this action?

Firefox complained with

404 Not Found

The requested URL was not found on this server.

/var/log/apache2/access.log contains

"GET /dokuwiki/testsite2 HTTP/1.1" 404 490

and /var/log/apache2/error.log contains

AH00128: File does not exist: /usr/share/dokuwiki/testsite2


   * What outcome did you expect instead?

I expected Firefox to render a page that said
something like 

"Welcome to dokuwiki"


I happened to notice 

/usr/share/dokuwiki/index.php

normally redirects to doku.php.

Should 

$ dokuwiki-addsite testsite2

create something like

/usr/share/dokuwiki/testsite2/index.php

that also redirects to a doku.php?

If so, how would it know to look in the new data
page path

/var/lib/dokuwiki/farm/testsite2/

instead of the default

/var/lib/dokuwiki/

?

Thanks,
Kingsley

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 4.4.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages dokuwiki depends on:
ii  cdebconf [debconf-2.0]  0.249
ii  debconf [debconf-2.0]   1.5.73
ii  javascript-common   11
ii  libjs-jquery3.3.1~dfsg-3
ii  libjs-jquery-cookie 10-2
ii  libjs-jquery-ui 1.12.1+dfsg-5
ii  libphp-simplepie1.3.1+dfsg-3.1
ii  php 1:7.2+62
ii  php-geshi   1.0.8.11-2
ii  php-phpseclib   2.0.12-1
ii  php-random-compat   2.0.17-1
ii  php-xml 1:7.2+61
ii  php7.2 [php]7.2.8-1
ii  php7.2-xml [php-xml]7.2.8-1
ii  ucf 3.0038+nmu1

Versions of packages dokuwiki recommends:
ii  imagemagick  8:6.9.10.23+dfsg-2.1
ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.23+dfsg-2.1
ii  php-cli  1:7.2+61
ii  php-ldap 1:7.2+62
ii  php7.2-cli [php-cli] 7.2.8-1
ii  php7.2-ldap [php-ldap]   7.2.8-1
ii  wget 1.20.3-1

Versions of packages dokuwiki suggests:
pn  libapache2-mod-xsendfile  

-- Configuration Files:
/etc/dokuwiki/plugins.local.php changed:

Bug#951561: lyx: Clicking on a cross-reference goes to the wrong page

[Kingsley G. Morse Jr.]

Package: lyx
Version: 2.3.4.2-2
Severity: normal

Dear Maintainer,

Thank you very much for maintaining lyx!

It has been a venerable and trustworthy tool for
many years!

The main reason I'm writing is I may have
discovered a small bug.

Basically, some cross-references lead to the wrong
pages.

I'll attach 3 files that I hope you can use to
duplicate the problem:

1.) A very short .lyx file named "bug.lyx".

2.) A PDF of it, created with the following menu
path

File->Export->PDF (ps2pdf)

3.) A screen shot of the mismatched page numbers I
see.

Maybe you'll see them too.

I expected

a.) hoovering the mouse's pointer over the page
number "2" in the red cross-reference box
to pop up a yellow tool tip that said

"Go to page 2."

But it says 

"Go to page 1."


b.) clicking on the page number "2" in the red
cross-reference box to advance to page 2.

But it stays on page 1.


Most cross-references in a bigger, real life, .lyx
file have correct page numbers.

I hope that helps,
Kingsley

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 4.4.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages lyx depends on:
ii  libc62.29-9
ii  libenchant-2-2   2.2.7+repack1-1
ii  libgcc-s110-20200211-1
ii  libmagic11:5.37-6
ii  libmythes-1.2-0  2:1.2.4-3+b1
ii  libqt5core5a 5.12.5+dfsg-8
ii  libqt5gui5   5.12.5+dfsg-8
ii  libqt5svg5   5.12.5-2
ii  libqt5widgets5   5.12.5+dfsg-8
ii  libstdc++6   9.2.1-24
ii  lyx-common   2.3.4.2-2
ii  xdg-utils1.1.3-1
ii  zlib1g   1:1.2.11.dfsg-1+b1

Versions of packages lyx recommends:
pn  dvipng   
ii  epdfview [pdf-viewer]0.1.8-3
ii  evince [pdf-viewer]  3.32.0-3
ii  fonts-lyx2.1.4-2
ii  ghostscript  9.50~dfsg-5
ii  gv [pdf-viewer]  1:3.7.4-1
ii  imagemagick  8:6.9.10.23+dfsg-2.1
ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.23+dfsg-2.1
ii  mupdf [pdf-viewer]   1.15.0+ds1-1
ii  okular [pdf-viewer]  4:17.12.2-2.2
ii  poppler-utils0.71.0-5+b1
ii  preview-latex-style  11.88-1.1
ii  psutils  1.17.dfsg-2
ii  qpdfview [pdf-viewer]0.4.18-1+b1
ii  texlive-fonts-recommended2019.20200210-1
ii  texlive-latex-extra  2019.202000210-1
ii  texlive-latex-recommended2019.20200210-1
ii  texlive-plain-generic2019.202000210-1
pn  texlive-science  
ii  xpdf [pdf-viewer]3.03-17+b1

Versions of packages lyx suggests:
ii  chktex  1.7.4-1
pn  gnuhtml2latex   
ii  groff   1.22.4-3
ii  inkscape0.92.2-1+b1
pn  latex2rtf   
ii  librsvg2-bin2.46.4-1
ii  libtiff-tools   4.0.10+git190818-1
pn  linuxdoc-tools  
pn  noweb   
ii  rcs 5.9.4-3
pn  sgmltools-lite  
ii  texlive-plain-generic [tex4ht]  2019.202000210-1
pn  texlive-xetex   
pn  writer2latex
pn  wv  

-- debconf information:
  lyx/upgrade-notice:
#LyX 2.3 created this file. For more info see http://www.lyx.org/
\lyxformat 544
\begin_document
\begin_header
\save_transient_properties true
\origin unavailable
\textclass article
\use_default_options false
\maintain_unincluded_children false
\language american
\language_package default
\inputencoding default
\fontencoding global
\font_roman "default" "default"
\font_sans "default" "default"
\font_typewriter "default" "default"
\font_math "auto" "auto"
\font_default_family default
\use_non_tex_fonts false
\font_sc false
\font_osf false
\font_sf_scale 100 100
\font_tt_scale 100 100
\use_microtype false
\use_dash_ligatures true
\graphics dvips
\default_output_format default
\output_sync 0
\bibtex_command default
\index_command default
\paperfontsize 10
\spacing single
\use_hyperref true
\pdf_bookmarks true
\pdf_bookmarksnumbered false
\pdf_bookmarksopen false
\pdf_bookmarksopenlevel 1
\pdf_breaklinks false
\pdf_pdfborder false
\pdf_colorlinks false
\pdf_backref false
\pdf_pdfusetitle true
\papersize default
\use_geometry true
\use_package amsmath 1
\use_package amssymb 1
\use_package cancel 1
\use_package esint 0
\use_package mathdots 1
\use_package mathtools 1
\use_package mhchem 1
\use_package stackrel 1
\use_package stmaryrd 1
\use_package undertilde 1
\cite_engine basic
\cite_engine_type default
\biblio_style plain

Bug#950524: apt: Please let users specify how deeply to update the dependency tree

[Kingsley G. Morse Jr.]

Package: apt
Version: 1.8.4
Severity: wishlist

Dear Maintainer,

Thank you very much for helping keep Debian's
admin tools so cool!

It seems to me that managing software complexity
is becoming more important as Debian acquires more
packages.

The main reason I'm writing is to humbly suggest a
new feature to apt, apt-get and/or aptitude.

It would let users specify how deeply into a
packages dependency tree to upgrade dependencies
to their current versions.

My understanding is the current policy is to
upgrade the named package to its current version,
and only its dependencies if their installed
versions do not happen to satisfy the named
package's dependency.

For example

"$ aptitude upgrade sagemath 

failed to upgrade its dependency on the cython3
package to the latest version available in
unstable, 0.29.14-0.1+b1. 

sagemath's dependency says ">= 0.29.1" is good
enough, and 0.29.2-2 was installed.

I humbly suggest added a cool new option: "-dl "
where  is a number specifying how deeply
into the named package's dependency tree to
upgrade dependencies to the currently available
version.

I suppose it may also accept a key word like "max"
or "all" to freshen the whole dependency tree.

I can imagine it helping 

find bugs and/or

our understanding of software complexity.

Either way, Debian may get better.

So,
Kingsley

Bug#950467: Maybe upgrading the cython3 package fixed it

[Kingsley G. Morse Jr.]

I'm happy to report I'm now looking at a cool 

sage:

prompt.

Since the last error message also alluded to 
cython

> ImportError: 
> /usr/lib/python3/dist-packages/sage/libs/gap/element.cpython-37m-i386-linux-gnu.so:
>  undefined symbol: GAP_EnterStack_

I tried manually upgrading the cython3 package
from 0.29.2-2 to 0.29.14-0.1+b1.

I wish I were more confident I knew what actually
fixed it, but as a practical metter, it's OK with
me if you close this bug report.

So,
Kingsley

-- 
Time is the fire in which we all burn.

Bug#950467: Nice catch, Tobias! Up for another? (Was: Install, run & crash w/ ...)

[Kingsley G. Morse Jr.]

I'm happy to report your guess was correct.

Through no fault of yours

$ apt-get install sagemath

on my computer failed to upgrade the
libgsl23 package to the latest version in
unstable.

Evidently not upgrading compliant dependencies to
their latest available versions is intentional.

But, I'm also happy to report, manually upgrading
it with

$ apt-get install libgsl23

seems to have fixed

>  ImportError: /usr/lib/i386-linux-gnu/libgsl.so.23: undefined symbol: 
> cblas_ctrmv

That's the good news.

The bad?

$ sage 

crashed with a new error.

Toward the end of Sage_crash_report.txt I now see

ImportError: 
/usr/lib/python3/dist-packages/sage/libs/gap/element.cpython-37m-i386-linux-gnu.so:
 undefined symbol: GAP_EnterStack_

If I understand correctly, it suggests sage
didn't find the symbol

GAP_EnterStack_

which seems to be associated with the GAP computer
algebra system.

Upgrading the following gap packages to their
latest versions in unstable elicited the same
error:

gap-core
gap-smallgrp-extra
gap-design
gap-float
gap-grape
gap-guava
gap-laguna
gap-openmath
gap-radiroot
gap-scscp
gap-sonata
gap-toric

I also checked if the versions of packages owning
files listed in its stack trace were currently in
unstable.

Unless I overlooked something, they are.

If you happen to have the time, and are so
inclined, feel free to share more insight!

The latest Sage_crash_report.txt isi attached to
this email, and hopefully, bug report.

Thanks,
Kingsley

On 02/02/2020 09:56, Tobias Hansen wrote:
> Hi,
> 
> looks like an instance of #907119 which was fixed in gsl 2.5+dfsg-5, however 
> you have gsl 2.5+dfsg-4 installed. Please update your packages to the 
> versions in unstable.
> 
> Best,
> Tobias
> 
> On 2/2/20 9:13 AM, Kingsley G. Morse Jr. wrote:
> > ImportError: /usr/lib/i386-linux-gnu/libgsl.so.23: undefined 
> > symbol: cblas_ctrmv
> 
> > ii  libgsl23  2.5+dfsg-4
> 

-- 
Time is the fire in which we all burn.

***

IPython post-mortem report

{'commit_hash': '',
 'commit_source': '(none found)',
 'default_encoding': 'UTF-8',
 'ipython_path': '/usr/lib/python3/dist-packages/IPython',
 'ipython_version': '7.11.1',
 'os_name': 'posix',
 'platform': 'Linux-4.4.0-1-686-pae-i686-with-debian-bullseye-sid',
 'sys_executable': '/usr/bin/python3',
 'sys_platform': 'linux',
 'sys_version': '3.7.5rc1 (default, Oct  2 2019, 04:19:31) \n'
'[GCC 9.2.1 20190909]'}

***



***

Crash traceback:

---
---
ImportError   Python 3.7.5rc1: /usr/bin/python3
   Sun Feb  2 15:13:05 2020
A problem occurred executing Python code.  Here is the sequence of function
calls leading up to the error, with the most recent (innermost) call last.
/usr/share/sagemath/bin/sage-ipython in 
  1 #!/usr/bin/env sage-python
  2 # -*- coding: utf-8 -*-
  3 """
  4 Sage IPython startup script.
  5 """
  6 
  7 # Display startup banner. Do this before anything else to give the user
  8 # early feedback that Sage is starting.
  9 from sage.misc.banner import banner
 10 banner()
 11 
 12 from sage.repl.interpreter import SageTerminalApp
 13 
 14 app = SageTerminalApp.instance()
---> 15 app.initialize()
global app.initialize = >
 16 app.start()

 in initialize(self=, argv=None)

/usr/lib/python3/dist-packages/traitlets/config/application.py in 
catch_config_error(method=, 
app=, *args=(None,), **kwargs={})
 72 TRAITLETS_APPLICATION_RAISE_CONFIG_FILE_ERROR = False
 73 else:
 74 raise ValueError("Unsupported value for environment variable: 
'TRAITLETS_APPLICATION_RAISE_CONFIG_FILE_ERROR' is set to '%s' which is none of 
 {'0', '1', 'false', 'true', ''}."% _envvar )
 75 
 76 
 77 @decorator
 78 def catch_config_error(method, app, *args, **kwargs):
 79 """Method decorator for catching invalid config 
(Trait/ArgumentErrors) during init.
 80 
 81 On a TraitError (generally caused by bad config), this will print 
the trait's
 82 message, and exit the app.
 83 
 84 For use on init methods, to prevent invoking excepthook on invalid 
input.
 85 """
 86 try:
---> 87 return method(app, *args, **kwargs)
method = 
app = 
args = (None,)
kwargs = {}
 88 except (Tr

Bug#950467: sagemath: Install, run & crash w/ "---> 15 app.initialize()"

[Kingsley G. Morse Jr.]

Package: sagemath
Version: 9.0-1
Severity: important

   * What led up to the situation?

   Trying to run sage immediately after installing
   it.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

$ sage

   * What was the outcome of this action?

Behold!

The contents of ~/.ipython/Sage_crash_report.txt!


***

IPython post-mortem report

{'commit_hash': '',
 'commit_source': '(none found)',
 'default_encoding': 'UTF-8',
 'ipython_path': '/usr/lib/python3/dist-packages/IPython',
 'ipython_version': '7.11.1',
 'os_name': 'posix',
 'platform': 'Linux-4.4.0-1-686-pae-i686-with-debian-bullseye-sid',
 'sys_executable': '/usr/bin/python3',
 'sys_platform': 'linux',
 'sys_version': '3.7.5rc1 (default, Oct  2 2019, 04:19:31) \n'
'[GCC 9.2.1 20190909]'}


***




***

Crash traceback:


---

---
ImportError   Python 3.7.5rc1: 
/usr/bin/python3
   Sat Feb  1 23:54:19 
2020
A problem occurred executing Python code.  Here is the sequence of 
function
calls leading up to the error, with the most recent (innermost) call 
last.
/usr/share/sagemath/bin/sage-ipython in 
  1 #!/usr/bin/env sage-python
  2 # -*- coding: utf-8 -*-
  3 """
  4 Sage IPython startup script.
  5 """
  6 
  7 # Display startup banner. Do this before anything else to give 
the user
  8 # early feedback that Sage is starting.
  9 from sage.misc.banner import banner
 10 banner()
 11 
 12 from sage.repl.interpreter import SageTerminalApp
 13 
 14 app = SageTerminalApp.instance()
---> 15 app.initialize()
global app.initialize = >
 16 app.start()

 in 
initialize(self=, argv=None)

/usr/lib/python3/dist-packages/traitlets/config/application.py in 
catch_config_error(method=, 
app=, *args=(None,), **kwargs={})
 72 TRAITLETS_APPLICATION_RAISE_CONFIG_FILE_ERROR = False
 73 else:
 74 raise ValueError("Unsupported value for environment 
variable: 'TRAITLETS_APPLICATION_RAISE_CONFIG_FILE_ERROR' is set to '%s' which 
is none of  {'0', '1', 'false', 'true', ''}."% _envvar )
 75 
 76 
 77 @decorator
 78 def catch_config_error(method, app, *args, **kwargs):
 79 """Method decorator for catching invalid config 
(Trait/ArgumentErrors) during init.
 80 
 81 On a TraitError (generally caused by bad config), this will 
print the trait's
 82 message, and exit the app.
 83 
 84 For use on init methods, to prevent invoking excepthook on 
invalid input.
 85 """
 86 try:
---> 87 return method(app, *args, **kwargs)
method = 
app = 
args = (None,)
kwargs = {}
 88 except (TraitError, ArgumentError) as e:
 89 app.print_help()
 90 app.log.fatal("Bad config encountered during 
initialization:")
 91 app.log.fatal(str(e))
 92 app.log.debug("Config at the time: %s", app.config)
 93 app.exit(1)
 94 
 95 
 96 class ApplicationError(Exception):
 97 pass
 98 
 99 
100 class LevelFormatter(logging.Formatter):
101 """Formatter with additional `highlevel` record
102 

/usr/lib/python3/dist-packages/IPython/terminal/ipapp.py in 
initialize(self=, argv=None)
302 
303 return super(TerminalIPythonApp, 
self).parse_command_line(argv)
304 
305 @catch_config_error
306 def initialize(self, argv=None):
307 """Do actions after construct, but before starting the 
app."""
308 super(TerminalIPythonApp, self).initialize(argv)
309 if self.subapp is not None:
310 # don't bother initializing further, starting subapp
311 return
312 # print self.extra_args
313

Bug#946451: +1

[Kingsley G. Morse Jr.]

Yes, please upgrade to version 4.

So,
Kingsley


-- 
Time is the fire in which we all burn.

Bug#807996: This may still be a bug in 2019

[Kingsley G. Morse Jr.]

First of all, thank you very much for maintaining
apt.

It seems to me that Debian's fine system
administration tools, like apt, make the life of
system administrators easier.

The main reason I'm writing is I may have
replicated the bug originally reported here.

In 2019.

While trying to upgrade a computer running stable
to testing on DVDs.

Here's what I tried:

root$ cd-rom add   # With testing DVD 1 in the optical drive
root$ cd-rom add   # With testing DVD 2 in the optical drive
root$ cd-rom add   # With testing DVD 3 in the optical drive
root$ apt update
Ign:1 cdrom://[Debian GNU/Linux testing _Bullseye_ - Official Snapshot i386 
DVD Binary-1 (date and time bla bla bla)] bullseye InRelease
(5 similar error messages)
Err:7 cdrom://[Debian GNU/Linux testing _Bullseye_ - Official Snapshot i386 
DVD Binary-1 (date and time bla bla bla)] bullseye Release
  Please use apt-cdrom to make this CD-ROM recognized by APT. apt-get 
update cannot be used to add new CD-ROMs
(10 similar error messages)
Reading package lists... Done
E: The repository 'cdrom://[Debian GNU/Linux testing _Bullseye_ - Official 
Snapshot i386 DVD Binary-1 (date and time bla bla bla)] Release' does not have 
a Release file.
N: Updating from such a repository can't be done securely, and is therefore 
disabled by default.
(10 similar error messages)
N: See apt-secure(8) manpage for repository creation and user configuration 
details.

I also tried 

root$ apt-get update

and editing /etc/apt/sources.list by

commenting out stable's cdrom lines and

inserting between the words "deb" and "cdrom:" 

[ trusted=yes ] and

[ trusted=yes allow-insecure=yes ]

No luck.

So,
Kingsley

-- 
Time is the fire in which we all burn.

Bug#942357: Unencrypted logical volume and Stable's encrypted worked

[Kingsley G. Morse Jr.]

Here's more info.

1.) Testing's installer worked when I asked it to
create an UNencrypted logical volume.

2.) The 2019-09-08 Stable AMD64 distribution
successfully installed an encrypted logical volume.

3.) Similar bug reports are

#935973 and

#927165.

Thanks,
Kingsley


-- 
Time is the fire in which we all burn.

Bug#942357: debian-installer: Install and boot fails with... Volume group "-vg" not found

[Kingsley G. Morse Jr.]

Package: debian-installer
Version: AMD64 Testing October 7, 2019
Severity: normal
Tags: d-i

Dear Maintainer,

Thank you very much for your efforts to make
Debian available to so many people.

I've been testing the installer.

The main reason I'm writing is that I seem to have
uncovered a (wait for ...) BUG!

   * What led up to the situation?

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

1.) I burned 3 DVDs of the AMD64 Testing distribution
dated October 7, 2019.

2.) I installed from them, specifying

UEFI,

no network connection,

Xfce instead of Gnome,

No printer and

guided configuration of an encrypted
logical volume. I used the default
configuration of 

all available space,

root encrypted

swap encrypted

boot not encrypted

3.) I rebooted

   * What was the outcome of this action?

Volume group "-vg" not found
Cannot process volume group logger-vg

(The previous 2 lines were repeated about
30 times>)

  Gave up waiting for suspend/resume device
  Gave up waiting for root file system device. Common problems:
   - Boot args (cat /proc/cmdline)
 - Check rootdelay= (did the system wait long enough?)
   - Missing modules (cat /proc/modules; ls /dev)
  ALERT! /dev/mapper/--vg-root does not exist. Dropping to a 
shell!


  BusyBox v1.30.1 (bla bla bla...)

   * What outcome did you expect instead?

Xfce's login 

Thanks,
Kingsley

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 4.4.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Bug#941830: pypy3: "import numpy" complains with: "Original error was: No module named 'numpy.core._multiarray_umath'"

[Kingsley G. Morse Jr.]

Package: pypy3
Version: 7.1.1+dfsg-1
Severity: normal

Thank you very much for maintaining pypy3.

It executes code I wrote 2X as fast as python3.

The main reason for this bug report is I happened
to notice pypy3 failed to import a math module
named "numpy".

Here's how I elicited the error:

1.) $ pypy3

2.) import numpy

I expected to see the ">>> " prompt next.

Unfortunately, instead I saw

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/numpy/core/__init__.py", line 40, in 

from . import multiarray
  File "/usr/lib/python3/dist-packages/numpy/core/multiarray.py", line 13, 
in 
from . import overrides
  File "/usr/lib/python3/dist-packages/numpy/core/overrides.py", line 6, in 

from numpy.core._multiarray_umath import (
ModuleNotFoundError: No module named 'numpy.core._multiarray_umath'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/numpy/__init__.py", line 142, in 

from . import core
  File "/usr/lib/python3/dist-packages/numpy/core/__init__.py", line 71, in 

raise ImportError(msg)
ImportError: 

IMPORTANT: PLEASE READ THIS FOR ADVICE ON HOW TO SOLVE THIS ISSUE!

Importing the multiarray numpy extension module failed.  Most
likely you are trying to import a failed build of numpy.
Here is how to proceed:
- If you're working with a numpy git repository, try `git clean -xdf`
  (removes all files not under version control) and rebuild numpy.
- If you are simply trying to use the numpy version that you have installed:
  your installation is broken - please reinstall numpy.
- If you have already reinstalled and that did not fix the problem, then:
  1. Check that you are using the Python you expect (you're using 
/usr/bin/pypy3),
 and that you have no directories in your PATH or PYTHONPATH that can
 interfere with the Python and numpy versions you're trying to use.
  2. If (1) looks fine, you can open a new issue at
 https://github.com/numpy/numpy/issues.  Please include details on:
 - how you installed Python
 - how you installed numpy
 - your operating system
 - whether or not you have multiple versions of Python installed
 - if you built from source, your compiler versions and ideally a build 
log

 Note: this error has many possible causes, so please don't comment on
 an existing issue about this - open a new one instead.

Original error was: No module named 'numpy.core._multiarray_umath'

I read the above advice, and

1.) tested the latest versions of pypy3 and
python3-numpy in unstable, and 

2.) didn't notice any directory in my $PATH or
$PYTHONPATH environemnt variables that
looked suspicious.

No luck!

My understanding is pypy has only recently
supported numpy.

At least for me, python3 can import it.

So,
Kingsley

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 4.4.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages pypy3 depends on:
ii  dpkg  1.19.7
ii  libbz2-1.01.0.8-2
ii  libc6 2.29-1
ii  libexpat1 2.2.7-2
ii  libffi6   3.2.1-9
ii  libgcc1   1:9.2.1-7
ii  libgdbm6  1.18.1-5
ii  liblzma5  5.2.4-1+b1
ii  libncurses6   6.1+20190803-1
ii  libncursesw6  6.1+20190803-1
ii  libsqlite3-0  3.29.0-2
ii  libssl1.1 1.1.1d-1
ii  libtinfo6 6.1+20190803-1
ii  pypy3-lib 7.1.1+dfsg-1
ii  zlib1g1:1.2.11.dfsg-1+b1

pypy3 recommends no packages.

Versions of packages pypy3 suggests:
pn  pypy3-doc  
pn  pypy3-tk   

-- no debconf information

Bug#901931: Me too after upgrading timidity-daemon from 2.13.2-40.2 to 2.14.0-8

[Kingsley G. Morse Jr.]

I upgraded the timidity-daemon package.

I suspect it ran

/var/lib/dpkg/info/timidity-daemon.postinst

Line 48 appears to me to add 

the SERVER_GROUP "timidity" 

to 

the "audio" group.

The result?

No sound!

Not even the shrill, bowel constricting voices of
Gilbert Gottfried and my ex (who, to the best of my
knowledge, have never been seen together in the
same room)

;-)


Running 

$ pavucontrol

revealed pulseaudio saw only a "dummy" output
device instead of my sound card.

Something like

$ fuser /dev/snd/*

revealed something like the PID of timidity,
indicating the later had pre-emptively grabbed my
sound card.

I temporarily fixed sound by doing

root$ /etc/init.d/timidity stop

I tested if sound would survive rebooting by

1.) editing 

/etc/group

and manually deleting 

",timidity"

from the end of the "audio:*" line.

2.) and rebooting.

I'm happy to report sound kept working.


Humble suggestion to our timid-ity overlords:

Fixing timidity-daemon now might avoid problems
later, like many users 

1.) loosing all sound, 

2.) eventually finding this bug report,

3.) getting madder that it hasn't been fixed yet
and

4.) complaining loudly.

I'll trust you to proceed as you see fit.

So,
Kingsley

-- 
Time is the fire in which we all burn.

Bug#939295: kdenlive: Warnings after upgrading to version 19.08.0-1

[Kingsley G. Morse Jr.]

Package: kdenlive
Version: 19.08.0-1
Severity: normal

Hi Patrick,

Maybe it'd be helpful if I relay warnings that
appear on my console after upgrading from version
18.12.3-1 to 19.08.0-1.

Here's how I elicited them:

Open a console window and at its bash command line prompt type

$ kdenlive

Then I see in the console

WARNING : Fails to parse  "glsl.manager"
WARNING : Fails to parse  "movit.convert"
WARNING : Fails to parse  "movit.crop"
WARNING : Fails to parse  "movit.resample"
WARNING : Fails to parse  "movit.resize"
WARNING : Fails to parse  "jack"
"jackrack" is blacklisted
"qtext" is blacklisted
WARNING : Fails to parse  "audiochannels"
WARNING : Fails to parse  "audioconvert"
WARNING : Fails to parse  "data_feed"
"data_show" is blacklisted
WARNING : Fails to parse  "imageconvert"
"mask_apply" is blacklisted
"mask_start" is blacklisted
"mono" is blacklisted
"region" is blacklisted
"resize" is blacklisted
"transition" is blacklisted
"watermark" is blacklisted
"rgblut" is blacklisted
"spot_remover" is blacklisted
"text" is blacklisted
"timer" is blacklisted
"videostab" is blacklisted
"videostab2" is blacklisted
WARNING : Fails to parse  "telecide"
"resample" is blacklisted
"gtkrescale" is blacklisted
"frei0r.3dflippo" is blacklisted
"frei0r.bluescreen0r" is blacklisted
"frei0r.bw0r" is blacklisted
"frei0r.gamma" is blacklisted
"frei0r.invert0r" is blacklisted
"frei0r.rgbsplit0r" is blacklisted
"frei0r.transparency" is blacklisted
"frei0r.vertigo" is blacklisted
WARNING : Fails to parse  "avcolour_space"
WARNING : Fails to parse  "avcolor_space"
WARNING : Fails to parse  "avdeinterlace"
WARNING : Fails to parse  "swscale"
"avfilter.abench" is blacklisted
"avfilter.acompressor" is blacklisted
"avfilter.adelay" is blacklisted
"avfilter.aecho" is blacklisted
"avfilter.aemphasis" is blacklisted
"avfilter.aeval" is blacklisted
"avfilter.afade" is blacklisted
"avfilter.afftfilt" is blacklisted
"avfilter.agate" is blacklisted
"avfilter.ametadata" is blacklisted
"avfilter.arealtime" is blacklisted
"avfilter.ashowinfo" is blacklisted
"avfilter.channelmap" is blacklisted
"avfilter.chorus" is blacklisted
"avfilter.earwax" is blacklisted
"avfilter.volume" is blacklisted
"avfilter.volumedetect" is blacklisted
"avfilter.ass" is blacklisted
"avfilter.atadenoise" is blacklisted
"avfilter.avgblur" is blacklisted
"avfilter.bbox" is blacklisted
"avfilter.bench" is blacklisted
"avfilter.blackdetect" is blacklisted
"avfilter.blackframe" is blacklisted
"avfilter.boxblur" is blacklisted
"avfilter.bwdif" is blacklisted
"avfilter.chromakey" is blacklisted
"avfilter.colorkey" is blacklisted
"avfilter.colormatrix" is blacklisted
"avfilter.colorspace" is blacklisted
"avfilter.convolution" is blacklisted
"avfilter.crop" is blacklisted
"avfilter.cropdetect" is blacklisted
"avfilter.curves" is blacklisted
"avfilter.datascope" is blacklisted
"avfilter.dctdnoiz" is blacklisted
"avfilter.deband" is blacklisted
"avfilter.deflate" is blacklisted
"avfilter.deinterlace_vaapi" is blacklisted
"avfilter.deshake" is blacklisted
"avfilter.despill" is blacklisted
"avfilter.doubleweave" is blacklisted
"avfilter.drawbox" is blacklisted
"avfilter.drawgraph" is blacklisted
"avfilter.drawgrid" is blacklisted
"avfilter.drawtext" is blacklisted
"avfilter.elbg" is blacklisted
"avfilter.eq" is blacklisted
"avfilter.fade" is blacklisted
"avfilter.field" is blacklisted
"avfilter.fieldhint" is blacklisted
"avfilter.fieldorder" is blacklisted
"avfilter.find_rect" is blacklisted
"avfilter.floodfill" is blacklisted
"avfilter.fspp" is blacklisted
"avfilter.gblur" is blacklisted
"avfilter.geq" is blacklisted
"avfilter.hflip" is blacklisted
"avfilter.hqdn3d" is blacklisted
"avfilter.hqx" is blacklisted
"avfilter.hue" is blacklisted
"avfilter.hwdownload" is blacklisted
"avfilter.idet" is blacklisted
"avfilter.il" is blacklisted
"avfilter.lenscorrection" is blacklisted
"avfilter.loop" is blacklisted
"avfilter.lumakey" is blacklisted
"avfilter.lut" is blacklisted
"avfilter.lutrgb" is blacklisted
"avfilter.lutyuv" is blacklisted
"avfilter.mcdeint" is blacklisted
"avfilter.metadata" is blacklisted
"avfilter.negate" is blacklisted
"avfilter.nlmeans" is blacklisted
"avfilter.nnedi" is blacklisted
"avfilter.owdenoise" is blacklisted
"avfilter.pad" is blacklisted
"avfilter.perspective" is blacklisted
"avfilter.phase" is blacklisted
"avfilter.pixscope" is blacklisted
"avfilter.pp" is blacklisted
"avfilter.pp7" is blacklisted
"avfilter.prewitt" is blacklisted

Bug#778357: Yes, I agree that failed "apt-get update"s should not return 0

[Kingsley G. Morse Jr.]

Hi guys,

Thank you very much for filing this bug report and
trying to make Debian more reliable.

I agree with Patrick and Philipp.

When "apt-get update" fails, it should not return
an error status of 0.

Scripts routinely check the exit status of
command, and assume they worked if 0 was returned.

I ran into this bug with a cron job that updates
local copies of package indices.

Since 0 was returned, I was none the wiser of a
problem.

I agree that "apt-get update" should return
something other than 0 when it fails.

Please fix it.

So,
Kingsley

-- 
Time is the fire in which we all burn.

Bug#928274: python-openopt: Here is a script to test all of the examples

[Kingsley G. Morse Jr.]

Package: python-openopt
Version: 0.38+svn1589-1.1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

   I tested an example script that comes with
   the package named "python-openopt".

   It failed.

   I emailed the package's maintainer a few days
   ago.

   No reply.

   Yet.

   It occurred to me 
   
1.) it may interesting to test all of the
example scripts in the package,

2.) I can code, 

3.) curse these good looks and

4.) ;-)


   * What exactly did you do (or not do) that was effective (or
 ineffective)?

 I wrote the following shell code to test all
 of the examples included in the
 python-openopt package

$ for f in /usr/share/doc/python-openopt/examples/*.py ; do echo 
"===" ; echo ; echo "$f" ; echo ; echo ; echo ; python "$f" ; done 
| tee /tmp/python-openopt_examples.log

   * What was the outcome of this action?

The output file is attached.

   * What outcome did you expect instead?

   Less errors.

Thanks,
Kingsley


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 4.4.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages python-openopt depends on:
ii  python-numpy 1:1.16.2-1
ii  python-setproctitle  1.1.10-1+b2
pn  python:any   

Versions of packages python-openopt recommends:
ii  python-cvxopt  1.1.9+dfsg-3+b1
ii  python-matplotlib  2.2.3-6
ii  python-scipy   0.19.1-1

Versions of packages python-openopt suggests:
ii  lp-solve  5.5.0.13-7+b1

-- no debconf information
===

/usr/share/doc/python-openopt/examples/dfp_1.py




- OpenOpt 0.38 -
solver: ralg   problem: unnamedtype: DFP
OpenOpt Error: To perform gradients check you should have DerApproximator 
installed, see http://openopt.org/DerApproximator
===

/usr/share/doc/python-openopt/examples/dfp_2.py




- OpenOpt 0.38 -
solver: ralg   problem: unnamedtype: DFP
OpenOpt Error: To perform gradients check you should have DerApproximator 
installed, see http://openopt.org/DerApproximator
===

/usr/share/doc/python-openopt/examples/eig_1.py




- OpenOpt 0.38 -
solver: arpack   problem: unnamedtype: EIG   goal: largest magnitude
 iter   objFunVal   
0  0.000e+00 
istop: 0
Solver:   Time Elapsed = 0.19   CPU Time Elapsed = 0.004887
objFunValue: 0
[ 0.14607289-0.19602952j -0.65372843+0.j  2.89776724+0.j]
[[ 0.56334829-0.10391145j  0.19592536+0.j  0.43733688+0.j]
 [-0.1812288 -0.20999235j -0.03219327+0.j  0.49662623+0.j]
 [-0.21648181-0.21334642j -0.55544796+0.j  0.42977207+0.j]
 [-0.36295959+0.34828527j  0.62338178+0.j  0.38727512+0.j]
 [ 0.49714496+0.0482076j  -0.51327338+0.j  0.47687818+0.j]]
===

/usr/share/doc/python-openopt/examples/eig_2.py




- OpenOpt 0.38 -
solver: numpy_eig   problem: unnamedtype: EIG   goal: all eigenvectors and 
eigenvalues
 iter   objFunVal   
0  0.000e+00 
istop: 0
Solver:   Time Elapsed = 0.05   CPU Time Elapsed = 0.002157
objFunValue: 0
[ 2.89776724+0.j -0.65372843+0.j  0.14607289+0.19602952j
  0.14607289-0.19602952j -0.08530815+0.j]
[[ 0.43733688+0.j -0.19592536+0.j  0.57285154+0.j
   0.57285154-0.j  0.63764724+0.j]
 [ 0.49662623+0.j  0.03219327+0.j -0.14013112+0.23938241j
  -0.14013112-0.23938241j -0.53642409+0.j]
 [ 0.42977207+0.j  0.55544796+0.j -0.17419089+0.24907549j
  -0.17419089-0.24907549j  0.29171743+0.j]
 [ 0.38727512+0.j -0.62338178+0.j -0.42011495-0.27666898j
  -0.42011495+0.27666898j -0.45403266+0.j]
 [ 0.47687818+0.j  0.51327338+0.j  0.4801531 -0.13758665j
   0.4801531 +0.13758665j  0.12004364+0.j]]
===

/usr/share/doc/python-openopt/examples/glp_1.py




- OpenOpt 0.38 -
solver: de   problem: unnamedtype: GLP
 iter   objFunVal   
0  3.167e+03 
   10  1.788e+03 
   20  1.786e+03 
   30  1.786e+03 
   40  1.786e+03 
   50  1.786e+03 
   60  1.786e+03 
   70  1.786e+03 
   80  1.786e+03 
   90  1.786e+03 
  100  1.786e+03 
  110  1.786e+03 
  120  1.786e+03 
  130  1.786e+03 
  140  1.786e+03 
  150  1.786e+03 
  160  1.786e+03 
  170  1.786e+03 
  180  1.786e+03 
  190  1.786e+03 
  200  1.786e+03 
  210  1.786e+03 
  213  1.786e+03 
istop: 11 (Non-Success Number > maxNonSuccess = 15)
Solver:   Time Elapsed = 0.6CPU Time Elapsed = 0.450416

Bug#925316: TypeError: type.__new__(metaclass) is not safe

[Kingsley G. Morse Jr.]

Package: sagemath
Version: 8.6-6
Severity: important

Dear Maintainer,

Thank you for maintaining sage.

I look forward to using it.

The main reason I'm writing is to report a bug.

I typed...

root$ aptitude install sagemath

on a computer with piecemeal updates from Debian's
unstable distribution, and then

kingsley$ sage

and got  "kaBOOM!".

The crash traceback is attached.

It reminds me of

https://trac.sagemath.org/ticket/18503

So,
Kingsley

-- 
Time is the fire in which we all burn.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 4.4.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages sagemath depends on:
ii  cysignals-tools   1.8.1+ds-2
ii  cython0.29.2-2
ii  ecl   16.1.3+ds-2
ii  eclib-tools   20180815-2
ii  fflas-ffpack  2.3.2-3
ii  flintqs   1:1.0-3
ii  gap-atlasrep  1.5.1-2
ii  gap-core  4r10p0-7
ii  gap-dev   4r10p0-7
ii  gap-online-help   4r10p0-7
ii  gap-primgrp   3.3.2-1
ii  gap-smallgrp  1.3-1
ii  gap-table-of-marks1.2.7-2
ii  gap-transgrp  2.0.4-1
ii  gfan  0.6.2-2
ii  gmp-ecm   7.0.4+ds-5
ii  ipython   5.8.0-1
ii  iso-codes 3.63-1
ii  jmol  14.6.4+2016.11.05+dfsg1-4
ii  lcalc 1.23+dfsg-11
ii  less  481-2.1
ii  libatlas3-base [liblapack.so.3]   3.10.3-5
ii  libblas3 [libblas.so.3]   3.7.1-4
ii  libbraiding0  1.0-1
ii  libbrial-groebner31.2.4-2
ii  libbrial3 1.2.4-2
ii  libc6 2.28-8
ii  libcdd-tools  094j-2
ii  libcliquer1   1.21-2
ii  libec420180815-2
ii  libecm1   7.0.4+ds-5
ii  libflint-2.5.22.5.2-3
ii  libflint-arb2 1:2.16.0-2
ii  libgc1c2  1:7.6.4-0.4
ii  libgcc1   1:8.3.0-3
ii  libgd32.2.5-5.1
ii  libgivaro94.0.4-2
ii  libglpk40 4.65-2
ii  libgmp10  2:6.1.2+dfsg-4
ii  libgmpxx4ldbl 2:6.1.2+dfsg-4
ii  libgomp1  8.3.0-3
ii  libgsl23  2.5+dfsg-4
ii  libgslcblas0  2.5+dfsg-4
ii  libhomfly01.02r5-1
ii  libiml0   1.0.4-1+b2
ii  libjs-mathjax 2.7.4+dfsg-1
ii  libjs-three   80+dfsg2-2
ii  liblapack3 [liblapack.so.3]   3.7.1-4
ii  liblfunction0 1.23+dfsg-11
ii  liblinbox-1.5.2-0 1.5.2-2
ii  liblinboxsage-1.5.2-0 1.5.2-2
ii  liblrcalc11.2-2+b1
ii  libm4ri-0.0.20140914  20140914-2
ii  libm4rie-0.0.20150908 20150908-2
ii  libmpc3   1.1.0-1
ii  libmpfi0  1.5.3+ds-2
ii  libmpfr6  4.0.0-7
ii  libntl35  10.5.0-2
ii  libpari-gmp-tls6  2.11.1-2
ii  libplanarity0 3.0.0.5-3
ii  libpng16-16   1.6.36-5
ii  libppl14  1:1.2-7
ii  libpynac180.7.23-2
ii  libratpoints-2.1.31:2.1.3-1+b2
ii  

Bug#924448: Debug data! (Was: gimp: Bug#924448: segfault when using measuring tool)

[Kingsley G. Morse Jr.]

Hi Bernhard,

Thank you very much for sharing your clever debug
fu!

I tried it.

I'm happy to report your advice elicited a stack
trace like the one in bug report #908549.

It's OK with me if you merge my  stupendous
bug report, #924448, with it.

Plus, if it would be comfortable, convenient, and
all those good things, feel free to share any
thoughts you may happen to have on how I might
reconcile why

1.) Frederic MASSOT wrote

"The fix is built-in for versions 2.10"

at

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908549#20

2.) but version 2.10.8-2 of debian's gimp
package seems to still have the same bug?

Thank you again for maintaining gimp and sharing
your considerable skills so freely.

Both are fine qualities!

So,
Kingsley

PS: For what it's worth, details of what I tried
follows.

root:~ aptitude install gimp-dbgsym libglib2.0-0-dbgsym

km:~ script -c "gdb -q -ex 'set width 0' -ex 'set pagination off' -ex 'run' 
-ex 'bt' -ex 'detach' -ex 'quit' --args gimp" -a gdb_gimp_$(date 
+%Y-%m-%d_%H-%M-%S).log

Its output is the first file attached to this email.

Maybe we agree it has less of a back trace.


Next, I installed the systemd-coredump package.

root:~ aptitude install systemd-coredump

re-ran gimp,

km:~ gimp

( create a new image

  select the measure tool

  left click on the new image

  wait a few seconds, and.

  kaBOOM! )

and found a cool new core!

root:~ coredumpctl list
TIMEPID   UID   GID SIG COREFILE  EXE
Tue 2019-03-19 11:27:04 PDT   20581  1000  1000  11 present   
/usr/bin/gimp-2.10

root:~ coredumpctl gdb 20581

coredumpctl's output is in the second file
attached to this email.

It looks to me like the main stack trace (of
thread 20581) reveals frames

g_closure_invoke (libgobject-2.0.so.0)
signal_emit_unlocked_R (libgobject-2.0.so.0)
g_signal_emit_valist (libgobject-2.0.so.0)
g_signal_emit (libgobject-2.0.so.0)
gimp_tool_widget_changed (gimp-2.10)
g_object_notify_by_spec_internal (libgobject-2.0.so.0)
gimp_tool_compass_update_angle (gimp-2.10)
gimp_tool_compass_changed (gimp-2.10)

like in your email for the similar bug report at

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908549#10

Plus, much as you astutely asked yesterday, yes,
they do repeat.

8 times.

On 03/19/2019 14:28, Bernhard Übelacker wrote:
> Hello Kingsley G. Morse Jr.,
> 
> 
> > My main concern?>> The normal way of eliciting a back trace from> within 
> > gdb didn't work.> > The non repeating lines were reported by defining> a 
> > function in gdb and logging output to a file.
> 
> You can start gimp that way to get a backtrace:
> 
> script -c "gdb -q -ex 'set width 0' -ex 'set pagination off' -ex 'run' 
> -ex 'bt' -ex 'detach' -ex 'quit' --args gimp" -a gdb_gimp_$(date 
> +%Y-%m-%d_%H-%M-%S).log
> 
> This gave me a 11MB file, so it took some time
> for gdb to finish to write the 68000 stack frames.
> 
> Another alternative is to install a coredump collector
> like systemd-coredump. After that you should be able to
> list collected core dumps of the current boot by:
> 
> coredumpctl list
> 
> And have that core dump loaded into gdb by:
> 
> coredumpctl gdb 
> 
> Both may lead to better results if you have debug
> symbols installed like described in [1].
> In this case packages gimp-dbgsym libglib2.0-0-dbgsym.
> 
> For debugging graphical applications it may also be convenient
> to ssh into the target machine if a second computer is available,
> or at least start gdb from the "ctl-alt-F1 old school console".
> 
> This can be combined with running gdb inside tmux in the graphical
> environment and, if keyboard gets locked, ctl-alt-F1 and 'tmux attach'
> to access the locked gdb. And if the tmux step was missed, it may be
> possible to "move" the locked gdb process to another terminal ...
> 
> Happy debugging. :-)
> 
> Kind regards,
> Bernhard
> 
> [1] 
> https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols

-- 
Time is the fire in which we all burn.

Script started on 2019-03-19 11:11:34-0700
Reading symbols from gimp...Reading symbols from 
/usr/lib/debug/.build-id/5a/56cddb418553f4e42eb66a0c9148bb7543ddcd.debug...done.
done.
Starting program: /usr/bin/gimp 
BFD: /usr/lib/debug/.build-id/da/c552d8815d9a4ef5d055ab6cd81e0478998e2c.debug: 
unable to initialize decompress status for section .debug_aranges
BFD: /usr/lib/debug/.build-id/da/c552d8815d9a4ef5d055ab6cd81e0478998e2c.debug: 
unable to initialize decompress status for section .debug_aranges
warning: File 
"/usr/lib/debug/.build-id/da/c552d8815d9a4ef5d055ab6cd81e0478998e2c.debug" has 
no build-id, file skippe

Bug#924448: gimp: Bug#924448: segfault when using measuring tool

[Kingsley G. Morse Jr.]

O' big bug buster Bernhard!

Congratulations on finding a similar bug.

You did better than I!

I did as you suggested, and checked if my top 19
frames in gdb's back trace kind of repeat all the
time.

At this point, I think I have to report that, no,
I can not confirm they repeat.

I just see one copy.

My main concern?

The normal way of eliciting a back trace from
within gdb didn't work.

The non repeating lines were reported by defining
a function in gdb and logging output to a file.

Details are in this bug report's 15th message.

Maybe it omitted duplicate lines.

I dunno.

But yeah, the stack traces to have some similar
code.

Thank you very much for finding the similar bug!

So,
Kingsley

On 03/18/2019 18:22, Bernhard Übelacker wrote:
> Hello Kingsley G. Morse Jr.,
> the backtrace of the crash you reported seems to be quite
> similar to another bug reported in #908549.
> 
> Can you confirm that you just forwarded the top 19 frames
> and that they kind of repeat all the time?
> 
> Kind regards,
> Bernhard
> 
> 
> #908549: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908549

-- 
Time is the fire in which we all burn.

Bug#924448: Da stack trace

[Kingsley G. Morse Jr.]

I elicited a stack trace from gdb by 

1.) redirecting output to a file

(gdb) set logging on /tmp/gimp.gdb.log


2.) and defining a function that requested a
back trace after running gimp

(gdb) define mc
>file gimp
>r
>bt 1000
>^d


3.) running the function

(gdb) mc


Here's ist output

warning: File 
"/usr/lib/debug/.build-id/da/c552d8815d9a4ef5d055ab6cd81e0478998e2c.debug" has 
no build-id, file skipped
warning: File 
"/usr/lib/debug/.build-id/e5/02ab31fa523af198980f0f57ccb2949798ec9d.debug" has 
no build-id, file skipped
warning: File 
"/usr/lib/debug/.build-id/41/f29963806d55346284ccbbbff7ce1568c05a4b.debug" has 
no build-id, file skipped
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
warning: File 
"/usr/lib/debug/.build-id/c8/2785938ed49369549f97c435a2164d5537d787.debug" has 
no build-id, file skipped
warning: File 
"/usr/lib/debug/.build-id/b4/8ee7d166852be63462d6a8f2d1599b6c65a89d.debug" has 
no build-id, file skipped
warning: File 
"/usr/lib/debug/.build-id/b0/929a0b74877b19ff6ae956d9c3a23b2211d39e.debug" has 
no build-id, file skipped
warning: File 
"/usr/lib/debug/.build-id/b1/1e8718bce950a16015ee80c15c6b488369fb38.debug" has 
no build-id, file skipped
[New Thread 0xb5d28b40 (LWP 30375)]
warning: File 
"/usr/lib/debug/.build-id/ff/9a2994397cf6d0556c3eff4084392dc31eb2a7.debug" has 
no build-id, file skipped
[New Thread 0xb4205b40 (LWP 30402)]
[New Thread 0xb3a04b40 (LWP 30403)]
warning: File 
"/usr/lib/debug/.build-id/3e/91fc79df7ef64213ada45340cd54a7d110a90f.debug" has 
no build-id, file skipped
[New Thread 0xa9cdfb40 (LWP 30408)]
[New Thread 0xa94deb40 (LWP 30409)]
[New Thread 0xa8cddb40 (LWP 30410)]
[New Thread 0xa71c1b40 (LWP 30451)]
[Thread 0xa71c1b40 (LWP 30451) exited]
[New Thread 0xa71c1b40 (LWP 30524)]
[Thread 0xa8cddb40 (LWP 30410) exited]
[New Thread 0xa8cddb40 (LWP 30527)]

Thread 1 "gimp" received signal SIGSEGV, Segmentation fault.
0xb6fbbef9 in signal_emit_unlocked_R (node=node@entry=0x82e9d680, 
detail=detail@entry=0, 
instance=instance@entry=0x82e119a8, emission_return=0x0, 
instance_and_params=0xbf8000d0)
at ../../../gobject/gsignal.c:3501
3501../../../gobject/gsignal.c: No such file or directory.
#0  0xb6fbbef9 in signal_emit_unlocked_R (node=node@entry=0x82e9d680, 
detail=detail@entry=0, 
instance=instance@entry=0x82e119a8, emission_return=0x0, 
instance_and_params=0xbf8000d0)
at ../../../gobject/gsignal.c:3501
#1  0xb6fc5e00 in g_signal_emit_valist (instance=, 
signal_id=, 
detail=, 
var_args=0xbf80022c 
"\235(\033\200\207(\033\200\330\334\377\266\250\031\341\202\060\372\372\266\250\031\341\202\001")
 at ../../../gobject/gsignal.c:3391
#2  0xb6fc63f5 in g_signal_emit (instance=0x82e119a8, signal_id=619, detail=0)
at ../../../gobject/gsignal.c:3447
#3  0x801b28c9 in gimp_tool_widget_changed ()
#4  0xb6fafa30 in g_object_notify_by_spec_internal (pspec=, 
object=0x82e119a8)
at ../../../gobject/gobject.c:1181
#5  g_object_notify (object=0x82e119a8, property_name=0x804bf8dd "unit-angle")
at ../../../gobject/gobject.c:1229
#6  0x801996c0 in ?? ()
#7  0x8019a3af in ?? ()
#8  0xb6fa9037 in g_closure_invoke (closure=0x82e9ead0, return_value=0x0, 
n_param_values=1, 
param_values=0xbf800520, invocation_hint=0xbf8004c4) at 
../../../gobject/gclosure.c:810
#9  0xb6fbcd45 in signal_emit_unlocked_R (node=node@entry=0x82e9d680, 
detail=detail@entry=0, 
instance=instance@entry=0x82e119a8, emission_return=0x0, 
instance_and_params=0xbf800520)
at ../../../gobject/gsignal.c:3565
#10 0xb6fc5e00 in g_signal_emit_valist (instance=, 
signal_id=, 
detail=, 
var_args=0xbf80067c 
"\235(\033\200\207(\033\200\330\334\377\266\250\031\341\202\060\372\372\266\250\031\341\202\001")
 at ../../../gobject/gsignal.c:3391
#11 0xb6fc63f5 in g_signal_emit (instance=0x82e119a8, signal_id=619, detail=0)
at ../../../gobject/gsignal.c:3447
#12 0x801b28c9 in gimp_tool_widget_changed ()
#13 0xb6fafa30 in g_object_notify_by_spec_internal (pspec=, 
object=0x82e119a8)
at ../../../gobject/gobject.c:1181
#14 g_object_notify (object=0x82e119a8, property_name=0x804bf8dd "unit-angle")
at ../../../gobject/gobject.c:1229
#15 0x801996c0 in ?? ()
#16 0x8019a3af in ?? ()
#17 0xb6fa9037 in g_closure_invoke (closure=0x82e9ead0, return_value=0x0, 
n_param_values=1, 
param_values=0xbf800970, invocation_hint=0xbf800914) at 
../../../gobject/gclosure.c:810
#18 0xb6fbcd45 in signal_emit_unlocked_R (node=node@entry=0x82e9d680, 
detail=detail@entry=0, 
instance=instance@entry=0x82e119a8, emission_return=0x0, 
instance_and_params=0xbf800970)
at ../../../gobject/gsignal.c:3565
#19 0xb6fc5e00 in g_signal_emit_valist (instance=, 
signal_id=, 
detail=, 
var_args=0xbf800acc "\235(\033\200\207(\033\200\330\334\377\266\250\031\34Quit

So,
Kingsley

-- 
Time is the fire in which we all burn.

Bug#924448: Duplicating in gdb blocked key board (mostly)

[Kingsley G. Morse Jr.]

Another clue:

After gimp crashed in gdb, I couldn't type
anything in any xterminal.

However, pressing ctl-alt-F1, to go to an old
school console, worked.

That let me kill gdb's process and fix my key
baord.


Another clue, maybe:

gdb reported

Thread 1 "gimp" received signal SIGSEGV, Segmentation fault.
0xb7010f49 in signal_emit_unlocked_R (node=node@entry=0x82e7b2a0, 
detail=detail@entry=0, 
instance=instance@entry=0x80ba2288, emission_return=0x0, 
instance_and_params=0xbf8000d0)
at ../../../gobject/gsignal.c:3501
3501../../../gobject/gsignal.c: No such file or directory.

So,
Kingsley

-- 
Time is the fire in which we all burn.

Bug#924448: gimp: Measure tool -> click on image -> Segmentation fault

[Kingsley G. Morse Jr.]

Package: gimp
Version: 2.10.8-2
Severity: normal

Dear Maintainer,

Thank you very much for maintaining gimp!

It's very, very useful!

I seem to have found a way to crash it.

Maybe you can too.

(And ultimately, fix it.)

   * What led up to the situation?

1.) Run gimp from the command line with

$ gimp
gimp: LibGimpBase-WARNING: gimp: gimp_wire_read(): error
gimp: LibGimpBase-WARNING: gimp: gimp_wire_read(): error
gimp: LibGimpBase-WARNING: gimp: gimp_wire_read(): error
gimp: LibGimpBase-WARNING: gimp: gimp_wire_read(): error
gimp: LibGimpBase-WARNING: gimp: gimp_wire_read(): error
gimp: LibGimpBase-WARNING: gimp: gimp_wire_read(): error
gimp: LibGimpBase-WARNING: gimp: gimp_wire_read(): error
gimp: LibGimpBase-WARNING: gimp: gimp_wire_read(): error
gimp: LibGimpBase-WARNING: gimp: gimp_wire_read(): error
gimp: LibGimpBase-WARNING: gimp: gimp_wire_read(): error
gimp: LibGimpBase-WARNING: gimp: gimp_wire_read(): error
gimp: LibGimpBase-WARNING: gimp: gimp_wire_read(): error



2.) Create a new image

File->New->OK


3.) Select gimp's "measure" tool by 

a.) moving the mouse's pointer over the
icon of a compass and

b.) clicking the mouse's left button.


4.) Move the mouse's pointer over the newly
created image.


5.) Click the mouse's left button.


6.) Watch gimp crash with

(script-fu:3615): LibGimpBase-WARNING **: 22:37:47.912: script-fu: 
gimp_wire_read(): error
Segmentation fault

   * What outcome did you expect instead?

I expected to be able to measure the distance
between 2 points.

I tried to work around the crash with different
options for the measure tool.

No luck.

I hope that helps,
Kingsley


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 4.4.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages gimp depends on:
ii  gimp-data2.10.8-2
ii  libaa1   1.4p5-44
ii  libbabl-0.1-00.1.62-1
ii  libbz2-1.0   1.0.6-8.1
ii  libc62.28-8
ii  libcairo21.15.10-2
ii  libfontconfig1   2.13.0-5
ii  libfreetype6 2.9.1-3
ii  libgcc1  1:8.3.0-2
ii  libgdk-pixbuf2.0-0   2.36.11-2
ii  libgegl-0.4-00.4.14-1
ii  libgexiv2-2  0.10.8-1
ii  libgimp2.0   2.10.8-2
ii  libglib2.0-0 2.58.2-4
ii  libgs9   9.26a~dfsg-2
ii  libgtk2.0-0  2.24.32-1
ii  libgudev-1.0-0   232-2
ii  libharfbuzz0b1.9.0-1
ii  libheif1 1.3.2-1
ii  libilmbase23 2.2.1-2
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  liblcms2-2   2.9-3
ii  liblzma5 5.2.2-1.3
ii  libmng1  1.0.10+dfsg-3.1+b5
ii  libmypaint-1.3-0 1.3.0-2
ii  libopenexr23 2.2.1-4
ii  libopenjp2-7 2.3.0-1.1
ii  libpango-1.0-0   1.42.4-1
ii  libpangocairo-1.0-0  1.42.4-1
ii  libpangoft2-1.0-01.42.4-1
ii  libpng16-16  1.6.36-2
ii  libpoppler-glib8 0.71.0-3
ii  librsvg2-2   2.40.20-2
ii  libstdc++6   8.3.0-2
ii  libtiff5 4.0.10-4
ii  libwebp6 0.6.0-4
ii  libwebpdemux20.6.0-4
ii  libwebpmux3  0.6.1-2
ii  libwmf0.2-7  0.2.8.4-10.6
ii  libx11-6 2:1.6.6-1
ii  libxcursor1  1:1.1.15-1
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxmu6  2:1.1.2-2
ii  libxpm4  1:3.5.12-1
ii  xdg-utils1.1.3-1
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages gimp recommends:
ii  ghostscript  9.26a~dfsg-2

Versions of packages gimp suggests:
ii  gimp-data-extras  1:2.0.2-1
ii  gimp-help-en [gimp-help]  2.8.2-0.1
pn  gimp-python   
ii  gvfs-backends 1.26.2-1
ii  libasound21.1.3-5

-- no debconf information

Bug#909935: Now the developer says it looks like a bug

[Kingsley G. Morse Jr.]

Gnumeric's developer dug a little deeper, and wrote

"For some reason Gnumeric thinks your symbols
differ only in case. That looks like a bug."

So,
Kingsley

-- 
Time is the fire in which we all burn.

Bug#909935: exact() fixes/works around it

[Kingsley G. Morse Jr.]

A gnumeric maintainer whose name rhymes with
"Amadeus" suggested using exact().

On GIMPNet's #gnumeric channel.

Like

=if(exact("♂","♀"),"The same","different")

He seemed to think it's intentional.

I dunno. 

But exact() seems to work for me.

So,
Kingsley

-- 
Time is the fire in which we all burn.

Bug#909935: gnumeric: =if(...) fails

[Kingsley G. Morse Jr.]

Package: gnumeric
Version: 1.12.43-1
Severity: important

Hi Dmitry,

1.) Thanks for maintaining debian's gnuemric
package.

2.) It rocks.

3.) Maybe I found a bug.

A tiny spread sheet it attached.

It has only one cell.

It is just an if() statement.

It compares the male emojie character to the
female emojie character.

I expected it to report they are different.

At least for me, it says they are the same.

4.) I suppose it might corrupt data.

5.) Libre Office's calc correctly reports they are
different.

6.) I admit it.

Maybe I made a mistake.

7.) What do you think?

Thanks again for maintaining Debian's gnumeric
package.

So,
Kingsley


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 4.4.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages gnumeric depends on:
ii  debconf [debconf-2.0]  1.5.66
ii  gnumeric-common1.12.43-1
ii  gsfonts1:8.11+urwcyr1.0.7~pre44-4.3
ii  libatk1.0-02.28.1-1
ii  libc6  2.27-3
ii  libcairo2  1.15.10-2
ii  libgdk-pixbuf2.0-0 2.36.11-2
ii  libglib2.0-0   2.56.0-2
ii  libgoffice-0.10-10 0.10.43-1
ii  libgsf-1-114   1.14.41-2
ii  libgtk-3-0 3.22.29-1
ii  libpango-1.0-0 1.42.4-1
ii  libpangocairo-1.0-01.42.4-1
ii  libxml22.9.4+dfsg1-6.1
ii  procps 2:3.3.15-1
ii  pxlib1 0.6.7-1
ii  zlib1g 1:1.2.11.dfsg-1

Versions of packages gnumeric recommends:
ii  evince3.26.0-1
ii  gnumeric-doc  1.12.43-1
ii  lp-solve  5.5.0.13-7+b1

Versions of packages gnumeric suggests:
ii  fonts-liberation1.07.4-1
pn  gnumeric-plugins-extra  
pn  libgsf-1-dev

-- debconf information:
* gnumeric/existing-process: true
  gnumeric/existing-process-title:


if_bug.gnumeric
Description: application/gzip

Bug#894852: OK, thanks (Was: Here's a URL to that core dump of qemu's segfault)

[Kingsley G. Morse Jr.]

Hey Michael,

Thanks for your polite and informative email.

It all makes sense.

I wish us the best of luck with version 2.12!

So,
Kingsley

On 04/05/2018 08:17, Michael Tokarev wrote:
> 05.04.2018 07:55, Kingsley G. Morse Jr. wrote:
> > It's at
> > 
> > http://loaner.com/core_of_qemu_SIGSEGV.1.gz
> > 
> > You should be able to decompress it with a command
> > like:
> > 
> > $ gunzip kingsleys_stupendous_core_dump.gz
> 
> Thank you very much for your attempts.
> 
> But I *think* this bug has been already addressed in an upcoming
> release of qemu (wich will contain a *ton* of changes all over).
> 
> 2.11 version in debian is built with SDL2 GUI front-end. This one
> turned out to be not mature enough, with numerous bugs starting from
> crashes and up to various small nits here and there.  New release will
> be compiled with GTK3 GUI, which is much more mature. I already marked
> all bugs related to SDL2 GUI as "pending upload", this one will follow.
> 
> But there are some issues still. Due to large amount of changes I'd love
> to test things as much as possible before uploading, to ensure it doesn't
> break anything. And there's really lots of changes. Upstream hasn't
> released 2.12 yet, only a few release candidates, and a few issues
> still remain there as well. Expecting the new release really soon now.
> And finally, qemu package in Debian will contain several new binary
> packages, which will have to enter manual NEW queue (each new package
> need manual approval from the Debian FTP team), so it might delay
> things even more.  Still I'm sure we'll be there very soon :)
> 
> Thank you for your understanding!
> 
> /mjt

-- 
Time is the fire in which we all burn.

Bug#894852: Here's a URL to that core dump of qemu's segfault

[Kingsley G. Morse Jr.]

It's at

http://loaner.com/core_of_qemu_SIGSEGV.1.gz

You should be able to decompress it with a command
like:

$ gunzip kingsleys_stupendous_core_dump.gz

So,
Kingsley

-- 
Time is the fire in which we all burn.

Bug#890848: 1.75g -> 0.24g (Was: A smaller test ...)

[Kingsley G. Morse Jr.]

On 03/16/2018 22:38, Dan Dennedy wrote:
> [...]
> reduced from 1.75g RES to
> [...]
> 0.24g

Looks good, Dan.

Thank you very much,
Kingsley

-- 
Time is the fire in which we all burn.

Bug#890848: Well, well, well! (Was: A smaller test case ...)

[Kingsley G. Morse Jr.]

O Dan who can and has began!

Thank you very much for focusing your laser like
skilz on my bug.

I like your plan to take a closer look at what can
be done to reduce memory usage.

So,
Kingsley

On 03/16/2018 19:52, Dan Dennedy wrote:
> I took some time today to build kdenlive (master branch) and test this
> out...
> 
> On Thu, Feb 22, 2018 at 12:20 AM Jean-Baptiste Mardelle <j...@kdenlive.org>
> wrote:
> 
> > On 17.02.2018 05:55, Kingsley G. Morse Jr. wrote:
> > > I'm happy to provide you with an even smaller and
> > > easier test case.
> > >
> > > Just
> > >
> > >  1.) copy the attached tar archive "bug.2.tar"
> > >  to the /tmp directory and
> > >
> > >  2.) do what the attached video shows
> > >
> > >  $ cd /tmp
> > >
> > >  $ tar -xvf bug.2.tar
> > >
> > >  $ kdenlive bug.2.kdenlive
> > >
> > >  Select track Video 3's Affine transition
> > >  by clicking on it with the mouse
> > >
> > >  Click on the "Go to next key frame"
> > >  button.
> > >
> > >  Wait a moment for
> > >
> > >  "[mlt_pool] out of memory"
> > >
> > >  in the console.
> >
> 
> I did not get the above error even though my system only has 6 GiB RAM and
> only 2.7 free at this time with Gnome Shell, Firefox with 2 tabs, and a
> terminal window open. However, running top in the terminal I do observe the
> RES going up to about 2.4g when running this test.
> 
> 
> >
> > Hi all,
> >
> > Sorry for the late feedback. So I made a few tests and found some
> > interesting facts.
> > The problem seems related to frame buffer.
> >
> > When setting the "buffer" property to 0 on the consumer (sdl2_audio) in
> > Kdenlive, the memory usage stays stable (around 500Mb).
> >
> > When setting the buffer to 25 (default in Kdenlive), I get 2 different
> > situations:
> > - When using an HD 25fps profile, memory usage goes to about 700Mb
> > - When using a SD NTSC profile, memory usage quickly goes up to 2.3Gb.
> >
> >
> The only way I was able to reproduce the above was by using the Project
> Settings dialog in Kdenlive to change the profile because in that case, for
> me, images no longer load and all I get is black in the preview area. If I
> edit the .kdenlive file to change the profile element, then I still
> reproduce a high memory usage. Curiously, the lower resolution does use
> about 200 MiB more than 1280x720 in my tests. The frame rate did not make a
> difference. Also, it is not really necessary to select the Affine effect
> and click next keyframe. Simply scrubbing the timeline or switching to
> Project Monitor and playing the project through also uses up to ~2.4g RES.
> 
> 
> > These tests were done with the image attached in the latest email
> > (3800x2500 jpeg).
> >
> 
> At this point, I should point out that, in MLT, using high resolution
> images with affine generally requires a lot of memory. This is because
> affine requests the full source resolution from the source producer and
> bypasses the automatic scaling to project resolution. It does this so you
> can use affine to crop and scale and take advantage of all the available
> resolution. Imagine a heavy cropping scenario like a portrait photo
> included in a 16:9 video resolution and wanting little-to-no black bars.
> Best to do that by cropping from the original image instead of scaling
> original image down to 1280x720, cropping top and bottom to achieve 16:9,
> and then scaling that up to fill the video frame.
> 
> Affine works in RGBA such that there are 4 bytes per pixel. As a result
> 3800 * 2500 * 4 = ~36.24 MiB. If for some reason - for example, lack of
> optimizations - there are 2 of these per MLT frame (after all there are 2
> affine effects in the project), and there are 25 MLT frames in the consumer
> buffer JB mentions above; then 36.24 MiB * 2 * 25 ~= 1.8 GiB. Add to that
> memory used by the MLT  and Kdenlive, and we start to approach the RES
> number I was seeing. I should also point out that the RES number stays
> around this high level and does not grow excessively while scrubbing,
> playing, and clicking next keyframe.
> 
> Playing the project with "melt -consumer sdl2 buffer=1" uses ~1.5g RES
> where buffer=25 makes it shoot up to 2.8g.
> Now I can take a closer look at what can be done to reduce memory usage.
> 
> I will try to make more tests but wondering if the frame caching bugs
> > when using profile with a non integer fps profile..
> >
> > Regards
> > jb
> >
> >
> > > So,
> > > Kingsley
> > >
> >
> >
> >
> > --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > ___
> > Mlt-devel mailing list
> > mlt-de...@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/mlt-devel
> >

-- 
Time is the fire in which we all burn.

Bug#884268: Fixed?

[Kingsley G. Morse Jr.]

kdenlive's upstream maintainer, Jean-Baptiste
Mardelle wrote that he pushed a fix into branch
'Applications/17.12'[1].

That's the good news.

The bad news?

I tested debian's version 17.12.1-1 and it was
still broken.

I worked around it again by changing 

/usr/share/kdenlive/export/profiles.xml

from

   acodec=vorbis

to

   acodec=libvorbis

So,
Kingsley

[1]  Changing "acodec=vorbis" to "acodec=libvorbis" fixes a SIGSEGV
 https://bugs.kde.org/show_bug.cgi?id=388503

-- 
Time is the fire in which we all burn.

Bug#889493: tech-ctte: Please review if systemd is reliable enough to be the default

[Kingsley G. Morse Jr.]

Hi Phil,

I find I often benefit from other people's point
of view.

If you happen to have the time, and are so
inclined, and it would be comfortable, feel free
to elaborate on your comment in bug report #889493.

I'm particularly curious why you wrote it had no
merit.

So,
Kingsley

-- 
Time is the fire in which we all burn.

Bug#889493: tech-ctte: Please review if systemd is reliable enough to be the default

[Kingsley G. Morse Jr.]

Package: tech-ctte
Severity: important

First of all, thank you very much for sharing your
time and expertise with the debian project.

I'm happy to report I've been using it 24x7 since 1996.


The main reason I'm writing is that it seems to
me 

1.) the committee decided in 2014 that systemd
would be the default init system[1].

2.) enough

a.) years have passed,

b.) committee members have changed[2] and

c.) bugs have been reported[3]

to re-evaluate whether systemd is reliable enough
to be debian's default init system.

So,
Kingsley

[1] [CTTE #727708] Default init system for Debian
https://lists.debian.org/debian-devel-announce/2014/02/msg5.html

[2] WikiPedia
systemd
https://en.wikipedia.org/wiki/Systemd

"In November 2014 Debian maintainers and
Technical Committee members Joey Hess,[81]
Russ Allbery,[82] Ian Jackson[83] and systemd
package-maintainer Tollef Fog Heen[84]
resigned from their positions."

[3] Debian Bug report logs: Bugs in package systemd
https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=systemd;dist=stable

Bug#884268: Worked around by editing profiles.xml

[Kingsley G. Morse Jr.]

Hey Patrick,

I'm happy to report I worked around the bug by
changing line 6 of

/usr/share/kdenlive/export/profiles.xml

from

   acodec=vorbis

to

   acodec=libvorbis

Someone using the nick name "furq" on freenode's
#ffmpeg channel showed me that ffmpeg's web site
recommends using libvorbis


https://trac.ffmpeg.org/wiki/Encode/HighQualityAudio#AudioencodersFFmpegcanuse

I reported the bug upstream at

https://bugs.kde.org/show_bug.cgi?id=388503

Maybe you'd like to change line 6 of debian's copy
of

/usr/share/kdenlive/export/profiles.xml

Thanks,
Kingsley

-- 
Time is the fire in which we all burn.

Bug#884268: gdb back trace after installing libavcodec57-dbgsym

[Kingsley G. Morse Jr.]

Here's gdb's back trace of the seg fault, but
with debugging symbols for libavcodec57.

-- 
Time is the fire in which we all burn.
#0  move_audio (sf_size=, venc=0x9e40ddc0) at 
src/libavcodec/vorbisenc.c:1073
save = 
input = 
len = 
cur = 0x0
frame_size = 
subframes = 
sf = 0
ch = 0
#1  vorbis_encode_frame (avctx=0x9e40d380, avpkt=0x9ed9ce94, frame=0x9e4708a0, 
got_packet_ptr=0x9ed9ce88)
at src/libavcodec/vorbisenc.c:1124
venc = 0x9e40ddc0
i = 
ret = 
frame_size = 1024
mode = 
mapping = 
pb = {bit_buf = 0, bit_left = -1208666538, buf = 0x4 , 
  buf_ptr = 0xb7f53c8c  
"\203\304\020\203\304\034\061\300[^_]Í\264&", 
  buf_end = 0x8000 "\177ELF\001\001\001", size_in_bits = 0}
#2  0xabd8ffa4 in avcodec_encode_audio2 (avctx=, 
avpkt=, frame=0x9e4708a0, 
got_packet_ptr=) at src/libavcodec/encode.c:198
extended_frame = 
padded_frame = 0x0
ret = 
user_pkt = 
needs_realloc = 
#3  0xb2005f23 in consumer_thread (arg=0x80770710) at consumer_avformat.c:1622
p = 0x912a6030
got_packet = 0
ret = 
stream = 0x9e40d0a0
codec = 0x9e40d380
pkt = {buf = 0x0, pts = -9223372036854775808, dts = 
-9223372036854775808, data = 0x9e400480 "", size = 43008, 
  stream_index = 0, flags = 0, side_data = 0x0, side_data_elems = 0, 
duration = 0, pos = -1, convergence_duration = 0}
j = 0
n = 
consumer = 0x80770710
properties = 0x80770710
terminate_on_pause = 1
terminated = 0
real_time_output = -1
ante = {tv_sec = 1514957417, tv_usec = 124160}
fps = 25
width = 1920
height = 1080
img_width = 1920
img_height = 1080
channels = 2
total_channels = 2
frequency = 48000
pcm = 0x950298e0
samples = 64
audio_outbuf = 0x9e400480 ""
audio_input_nb_samples = 64
frame_count = 1
video_outbuf = 0x9a3ff020 "P\222\r\235\001*\200\a8\004"
frame = 0x0
frame_properties = 
queue = 0x8076ecd0
fifo = 0x9e40bb88
image = 0x925f8030 
"\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200"...
img_fmt = mlt_image_yuv422
converted_avframe = 
audio_avframe = 0x9e4708a0
video_avframe = 0x9e40cf00
audio_buf_1 = 0x9a343020 ""
audio_buf_2 = 0x0
count = 1
oc = 0x9e40b080
video_st = 0x9e40bc60
audio_st = {0x9e40d0a0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}
audio_pts = 0.02
video_pts = 0.040001
frames = 1
total_time = 39562
fmt = 0xabb53c40 
filename = 0x9e40acd8 "/home/kingsley/tmp/test.webm"
format = 
vcodec = 
acodec = 
audio_codec = 
video_codec = 
audio_codec_id = 86021
video_codec_id = 
key = "channels.7", '\000' 
frame_meta_properties = 0x9e40ad00
error_count = 0
sample_count = {1024, 0, 0, 0, 0, 0, 0, 0}
header_written = 1
i = 0
aud_fmt = mlt_audio_f32le
sample_bytes = 4
#4  0xb7f2c32d in start_thread (arg=0x9ed9db40) at pthread_create.c:456
__res = 
pd = 0x9ed9db40
now = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {-1208741888, -1629889728, 
-1629889728, -1629891544, 435968905, 1340044251}, 
  mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = 
{prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = 0
#5  0xb7e54616 in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:110
No locals.

Bug#884268: Could kdenlive be passing a bad acodec option to melt and libav*?

[Kingsley G. Morse Jr.]

Hey Patrick,

When rendering to .webm, kdenlive passes

acodec=vorbis

to melt.

Here's an example

$ /usr/bin/melt /tmp/saved.mlt in=0 out=63 -profile atsc_1080p_25 -consumer 
avformat:/home/kingsley/tmp/test.webm f=webm vcodec=libvpx acodec=vorbis crf=23 
vb=0 quality=good aq=6 max-intra-rate=1000 cpu-used=4 threads=1 real_time=-1

But, it crashes with a seg fault.

ffmpeg's audio codec documentation says to use
libvorbis[1].

libvorbis works for me.

$ /usr/bin/melt /tmp/saved.mlt in=0 out=63 -profile atsc_1080p_25 -consumer 
avformat:/home/kingsley/tmp/test.webm f=webm vcodec=libvpx acodec=libvorbis 
crf=23 vb=0 quality=good aq=6 max-intra-rate=1000 cpu-used=4 threads=1 
real_time=-1

rendered OK.

Could kdenlive be passing a bad option to melt
(and ffmpeg/libav*)?

Thanks,
Kingsley

[1] FFmpeg Codecs Documentation
https://ffmpeg.org/ffmpeg-codecs.html#libvorbis

-- 
Time is the fire in which we all burn.

Bug#885971: libgdal20 depends on version 1:8.300.1+dfsg-1 of libarmadillo8

[Kingsley G. Morse Jr.]

Hi Patrick,

I'm happy to report that upgrading the package
named 

libarmadillo8

from version

1:8.200.0+dfsg-3

to 

1:8.300.1+dfsg-1

seems to have fixed it.


Why?

I suspect because

melt uses /usr/lib/frei0r-1/facedetect.so,

/usr/lib/frei0r-1/facedetect.so interacts somehow with libopencv,
(they're in the attached stack trace and valgrind log)

libopencv-imgcodecs3.2 (3.2.0+dfsg-4+b2) depends on libgdal20 (>= 2.0.1) and

libgdal20 (2.2.3+dfsg-1) SAYS it depends on ANY version of libarmadillo8,

but it ACTUALLY needs 1:8.300.1+dfsg-1.

It seems to me that the dependencies of the
libgdal20 package might be updated to say it
depends on at least version 1:8.300.1+dfsg-1 of
libarmadillo8.

Humble suggestion:

If you agree, maybe you could reassign this bug
report to the libgdal20 package.

Happy new year,
Kingsley

-- 
Time is the fire in which we all burn.

Bug#885971: melt: Segmentation fault

[Kingsley G. Morse Jr.]

Package: melt
Version: 6.4.1-6+b1
Severity: normal

Hey Patrick,

Happy new year.

I'm chasing another bug.

When I run melt on the command line, it crashes
with

$ melt
Segmentation fault

kdenlive does too.

gdb's full back trace and valgrind's log for melt
are attached.

It looks to me like it's failing while trying to
load 

/usr/lib/frei0r-1/facedetect.so

I also see 

"opendap" in gdb's frame #1

and

"opencv" in the 46th line of valgrind's log.

These remind me of #881777, when I found similar
dependencies.

Happy new year,
Kingsley

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 4.4.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages melt depends on:
ii  libc62.25-5
ii  libmlt-data  6.4.1-6
ii  libmlt6  6.4.1-6+b1

melt recommends no packages.

melt suggests no packages.

-- no debconf information

#0  0x0001a616 in ?? ()
No symbol table info available.
#1  0xb060b95c in std::__cxx11::basic_string::_M_construct (this=0xbfffde54, 
__beg=0x801a7950 "http://xml.opendap.org/ns/DAP2;, __end=)
at /usr/include/c++/7/bits/basic_string.tcc:219
__dnew = 30
#2  0xb0630562 in std::__cxx11::basic_string::_M_construct_aux (__end=, 
__beg=, this=0xbfffde54)
at /usr/include/c++/7/bits/basic_string.h:236
No locals.
#3  std::__cxx11::basic_string::_M_construct (__end=, 
__beg=, 
this=0xbfffde54) at /usr/include/c++/7/bits/basic_string.h:255
No locals.
#4  std::__cxx11::basic_string::basic_string (__str="http://xml.opendap.org/ns/DAP2;, 
this=0xbfffde54)
at /usr/include/c++/7/bits/basic_string.h:440
No locals.
#5  std::operator+ (
__lhs="http://xml.opendap.org/ns/DAP2;, __rhs=0xa4f7d8d3 " ")
at /usr/include/c++/7/bits/basic_string.h:5916
__str = ""
#6  0xa4e6b133 in __static_initialization_and_destruction_0 (__initialize_p=1, 
__priority=65535) at DDS.cc:108
No locals.
#7  _GLOBAL__sub_I_DDS.cc(void) () at DDS.cc:1566
No locals.
#8  0xb7fea9e5 in call_init (l=, argc=argc@entry=1, 
argv=argv@entry=0xb904, env=0xb90c) at dl-init.c:72
j = 3
jm = 80
addrs = 0xa4fc683c
init_array = 
#9  0xb7feab0e in call_init (env=0xb90c, argv=0xb904, argc=1, 
l=) at dl-init.c:30
No locals.
#10 _dl_init (main_map=main_map@entry=0x8018d430, argc=1, argv=0xb904, 
env=0xb90c) at dl-init.c:120
preinit_array = 
preinit_array_size = 
i = 215
#11 0xb7feec17 in dl_open_worker (a=) at dl-open.c:575
args = 
file = 
mode = 
call_map = 
dst = 
new = 
__PRETTY_FUNCTION__ = "dl_open_worker"
r = 
reloc_mode = 
nmaps = 
l = 
maps = 
any_tls = 
first_static_tls = 
#12 0xb7e8df35 in __GI__dl_catch_error (objname=0xbfffe0b4, 
errstring=0xbfffe0b8, mallocedp=0xbfffe0b3, 
operate=0xb7fee850 , args=0xbfffe0bc)
at dl-error-skeleton.c:198
errcode = 16843009
c = {objname = 0xbfffe0b4, errstring = 0xbfffe0b8, 
  malloced = 0xbfffe0b3, errcode = 0xbfffdfcc, env = {{__jmpbuf = {
-1208868864, -1073749616, 0, -1073749768, -1654656300, 
-1285648188}, __mask_was_saved = 0, __saved_mask = {__val = {
  6, 16843009, 16843009, 16843009, 3086969542, 3087003680, 
  3221217280, 3087003696, 2392154112, 16843009, 3087003680, 
  3085491435, 3087003648, 3221217360, 0, 3221217528, 
  3086935453, 3221217360, 2149110728, 56, 805303552, 
  1701080693, 1701734758, 2037588068, 1819239021, 1920409658, 
  1701867617, 1734631282, 1601598306, 1937059584, 1768697714, 
  3086150297}
old = 
#13 0xb7fee409 in _dl_open (file=0x8013b948 "/usr/lib/frei0r-1/facedetect.so", 
mode=-2147483647, caller_dlopen=0xb2782072 , 
nsid=, argc=1, argv=0xb904, env=0xb90c)
at dl-open.c:660
args = {file = 0x8013b948 "/usr/lib/frei0r-1/facedetect.so", 
  mode = -2147483647, caller_dlopen = 0xb2782072 , 
  caller_dl_open = 0xb7d63cc7 , map = 0x8018d430, 
  nsid = 0, argc = 1, argv = 0xb904, env = 0xb90c}
objname = 0xbfffe071 "/usr/li\231\352", 
errstring = 0x8018d3c8 "/usr/lib/frei0r-1"
malloced = true
errcode = 
__PRETTY_FUNCTION__ = "_dl_open"
#14 0xb7d63cc7 in dlopen_doit (a=0xbfffe28c) at dlopen.c:66
 

Bug#884268: kdenlive: Rendering to .webm crashes.

[Kingsley G. Morse Jr.]

On 12/13/2017 10:44, Patrick Matthäi wrote:
> Am 13.12.2017 um 10:35 schrieb Kingsley G. Morse Jr.:
> > [...]
> > $ melt a_color.xml
> > [...]
> 
> And there is no crash?

Yes.

You are correct.

I see no crash.

> Can you please provide me somewhere the whole (as simple as possible)
> project which crashes on your pc

That's a good suggestion, Patrick.

One is attached.

With 2 "but"s.

But #1: I only know that it also crashes the
renderer. I do not know if it crashes for
the same reason.

But #2: I simplified it to 46 lines. It might be
simplified more. But I want to reproduce
the same bug and save time.

Here's how to use it.

$ kdenlive simple.xml

Click on...

Render->Generic (HD for web, mobile devices...)->WebM - the widespread 
free format (VP8/Vorbis)

Render to File

Look for "Rendering crashed".

Thanks,
Kingsley

-- 
Time is the fire in which we all burn.



simple.xml
Description: XML document

Bug#884268: kdenlive: Rendering to .webm crashes.

[Kingsley G. Morse Jr.]

On 12/13/2017 09:02, Patrick Matthäi wrote:
[...]
> What happens if you render your project file
> directly with melt? => $ melt
> /path/to/project/file.xml

Sorry, I'm not sure I understand your question.

Yes, my project files are XML, but I usually use
the file name suffix ".kdenlive".

When I tried running melt with a project file with
just a 5 second long color clip

$ melt a_color.xml

it didn't render a file.

It played a 5 second video of the color.

I hope that helps,
Kingsley

-- 
Time is the fire in which we all burn.

Bug#884267: OK, done

[Kingsley G. Morse Jr.]

On 12/13/2017 09:00, Patrick Matthäi wrote:
> [...]
> From a grep through the source code, it is not
> available anymore.  If you want to report
> documentation / wishlist bugs, please do it at
> the kdenlive bugreport page
> [...]

OK

I reported bug 387867 at https://bugs.kde.org/show_bug.cgi?id=387867

Thanks,
Kingsley

-- 
Time is the fire in which we all burn.

Bug#884268: kdenlive: Rendering to .webm crashes.

[Kingsley G. Morse Jr.]

Package: kdenlive
Version: 17.08.3-2
Severity: normal

Hi Patrick,

I like the free .webm video format.

kdenlive used to render to it for me.

Unfortunately, now it crashes.

Here's how:

1.) $ kdenlive

2.) File->New->Full HD 1080->HD 1080p 25 fps

3.) Project->Add color clip->Clip Color = black

4.) Drag the color clip from

the project bin 

to

the time line

5.) (red) Render (button)
->Generic (HD for web, mobile devices...)
->WebM - the widespread free format (VP8/Vorbis)

6.) Render to File (button)

I expected to see

Rendering finished in 

in the render window's Job Queue tab.

Unfortunately, I saw

Rendering crashed.

The render window's Job Queue tab has an error log
that says

[webm @ 0x9bd0b080] Using AVStream.codec to
pass codec parameters to muxers is deprecated,
use AVStream.codecpar instead. [webm @
0x9bd0b080] Using AVStream.codec to pass codec
parameters to muxers is deprecated, use
AVStream.codecpar instead

Rendering to the 

Lossless/HQ .mkv (HuffYUV (huffyuv + flac) 

format works OK.

ffmpeg can convert that .mkv file to .webm with

$ ffmpeg -i tmp/black.mkv tmp/black.webm

I hoped to find diagnostic info in kdenlive's
render log.

Unfortunately, I couldn't find the log.

See bug 884267.

Thanks,
Kingsley

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 4.4.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages kdenlive depends on:
ii  ffmpeg   7:3.4.1-1
ii  kded55.37.0-2
ii  kdenlive-data17.08.3-2
ii  kinit5.37.0-2
ii  kio  5.37.0-2
ii  libc62.25-3
ii  libgcc1  1:7.2.0-17
ii  libgl1-mesa-glx [libgl1] 17.1.3-2
ii  libglu1-mesa [libglu1]   9.0.0-2.1
ii  libkf5archive5   5.28.0-2
ii  libkf5attica55.37.0-2
ii  libkf5auth5  5.37.0-2
ii  libkf5bookmarks5 5.37.0-2
ii  libkf5codecs55.37.0-2
ii  libkf5completion55.37.0-2
ii  libkf5configcore55.37.0-2
ii  libkf5configgui5 5.37.0-2
ii  libkf5configwidgets5 5.37.0-2
ii  libkf5coreaddons55.37.0-2
ii  libkf5crash5 5.37.0-2
ii  libkf5dbusaddons55.37.0-2
ii  libkf5filemetadata3  5.37.0-2
ii  libkf5guiaddons5 5.28.0-1
ii  libkf5i18n5  5.37.0-2
ii  libkf5iconthemes55.37.0-2
ii  libkf5itemviews5 5.37.0-2
ii  libkf5jobwidgets55.37.0-2
ii  libkf5kiocore5   5.37.0-2
ii  libkf5kiofilewidgets55.37.0-2
ii  libkf5kiowidgets55.37.0-2
ii  libkf5newstuff5  5.37.0-2
ii  libkf5newstuffcore5  5.37.0-2
ii  libkf5notifications5 5.37.0-2
ii  libkf5notifyconfig5  5.37.0-2
ii  libkf5service-bin5.37.0-2
ii  libkf5service5   5.37.0-2
ii  libkf5solid5 5.37.0-2
ii  libkf5sonnetui5  5.28.0-2+b1
ii  libkf5textwidgets5   5.37.0-2
ii  libkf5widgetsaddons5 5.37.0-2
ii  libkf5xmlgui55.37.0-2
ii  libmlt++36.4.1-6+b1
ii  libmlt6  6.4.1-6+b1
ii  libqt5concurrent55.9.2+dfsg-4
ii  libqt5core5a 5.9.2+dfsg-6
ii  libqt5dbus5  5.9.2+dfsg-6
ii  libqt5gui5   5.9.2+dfsg-6
ii  libqt5network5   5.9.2+dfsg-6
ii  libqt5qml5   5.9.2-3
ii  libqt5quick5 5.9.2-3
ii  libqt5script55.9.2+dfsg-1
ii  libqt5svg5   5.9.2-3
ii  libqt5webkit55.212.0~alpha2-5
ii  libqt5widgets5   5.9.2+dfsg-6
ii  libqt5xml5   5.9.2+dfsg-6
ii  libstdc++6   7.2.0-17
ii  libv4l-0 1.12.6-1
ii  melt 6.4.1-6
ii  qml-module-qtquick-controls  5.9.2-2
ii  qml-module-qtquick2  5.9.2-3

Versions of packages kdenlive recommends:
ii  breeze-icon-theme  4:5.25.0-2
ii  dvdauthor  0.7.0-1.3
ii  dvgrab 3.5-2+b3
ii  frei0r-plugins 1.6.1-1+b1
ii  genisoimage9:1.1.11-3
ii  oxygen-icon-theme  5:5.25.0-1
ii  recordmydesktop0.3.8.1+svn602-1+b1
ii  swh-plugins0.4.16+git20160602~repack1-2

Versions of packages kdenlive suggests:
ii  khelpcenter  4:16.08.3-1

-- no debconf information

Bug#884267: kdenlive: Where is kdenlive_render.log.XXXXXXXX?

[Kingsley G. Morse Jr.]

Package: kdenlive
Version: 17.08.3-2
Severity: normal

Hi Patrick,

Happy holidays!

I'd like to use kdenlive's render log to find and
fix rendering bugs.

I followed the instructions in kdenlive_render's man 
page to create on by setting the environment variable
named "KDENLIVE_RENDER_LOG".

I set it before before trying to render in
kdenlive

$ export KDENLIVE_RENDER_LOG=1 ; export LANG=C ;  kdenlive

and before running kdenlive_render with a render
script generated by kdenlive

#! /bin/sh
RENDERER="/usr/bin/kdenlive_render"
MELT="/usr/bin/melt"
SOURCE_0=
TARGET_0=
PARAMETERS_0="-pid:7095 in=0 out=1565 $MELT atsc_720p_2997 avformat - 
$SOURCE_0 $TARGET_0 f=webm vcodec=libvpx acodec=vorbis crf=23 vb=0 quality=good 
aq=6 max-intra-rate=1000 cpu-used=4 threads=1 real_time=-1"
KDENLIVE_RENDER_LOG=1
$RENDERER $PARAMETERS_0

I expected to find a render log file named like

/tmp/kdenlive_render.log.

Unfortunately, I didn't.

I wish rendering left a log file.

I think it would make debugging easier.

Thanks,
Kingsley

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 4.4.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages kdenlive depends on:
ii  ffmpeg   7:3.4.1-1
ii  kded55.37.0-2
ii  kdenlive-data17.08.3-2
ii  kinit5.37.0-2
ii  kio  5.37.0-2
ii  libc62.25-3
ii  libgcc1  1:7.2.0-17
ii  libgl1-mesa-glx [libgl1] 17.1.3-2
ii  libglu1-mesa [libglu1]   9.0.0-2.1
ii  libkf5archive5   5.28.0-2
ii  libkf5attica55.37.0-2
ii  libkf5auth5  5.37.0-2
ii  libkf5bookmarks5 5.37.0-2
ii  libkf5codecs55.37.0-2
ii  libkf5completion55.37.0-2
ii  libkf5configcore55.37.0-2
ii  libkf5configgui5 5.37.0-2
ii  libkf5configwidgets5 5.37.0-2
ii  libkf5coreaddons55.37.0-2
ii  libkf5crash5 5.37.0-2
ii  libkf5dbusaddons55.37.0-2
ii  libkf5filemetadata3  5.37.0-2
ii  libkf5guiaddons5 5.28.0-1
ii  libkf5i18n5  5.37.0-2
ii  libkf5iconthemes55.37.0-2
ii  libkf5itemviews5 5.37.0-2
ii  libkf5jobwidgets55.37.0-2
ii  libkf5kiocore5   5.37.0-2
ii  libkf5kiofilewidgets55.37.0-2
ii  libkf5kiowidgets55.37.0-2
ii  libkf5newstuff5  5.37.0-2
ii  libkf5newstuffcore5  5.37.0-2
ii  libkf5notifications5 5.37.0-2
ii  libkf5notifyconfig5  5.37.0-2
ii  libkf5service-bin5.37.0-2
ii  libkf5service5   5.37.0-2
ii  libkf5solid5 5.37.0-2
ii  libkf5sonnetui5  5.28.0-2+b1
ii  libkf5textwidgets5   5.37.0-2
ii  libkf5widgetsaddons5 5.37.0-2
ii  libkf5xmlgui55.37.0-2
ii  libmlt++36.4.1-6+b1
ii  libmlt6  6.4.1-6+b1
ii  libqt5concurrent55.9.2+dfsg-4
ii  libqt5core5a 5.9.2+dfsg-6
ii  libqt5dbus5  5.9.2+dfsg-6
ii  libqt5gui5   5.9.2+dfsg-6
ii  libqt5network5   5.9.2+dfsg-6
ii  libqt5qml5   5.9.2-3
ii  libqt5quick5 5.9.2-3
ii  libqt5script55.9.2+dfsg-1
ii  libqt5svg5   5.9.2-3
ii  libqt5webkit55.212.0~alpha2-5
ii  libqt5widgets5   5.9.2+dfsg-6
ii  libqt5xml5   5.9.2+dfsg-6
ii  libstdc++6   7.2.0-17
ii  libv4l-0 1.12.6-1
ii  melt 6.4.1-6
ii  qml-module-qtquick-controls  5.9.2-2
ii  qml-module-qtquick2  5.9.2-3

Versions of packages kdenlive recommends:
ii  breeze-icon-theme  4:5.25.0-2
ii  dvdauthor  0.7.0-1.3
ii  dvgrab 3.5-2+b3
ii  frei0r-plugins 1.6.1-1+b1
ii  genisoimage9:1.1.11-3
ii  oxygen-icon-theme  5:5.25.0-1
ii  recordmydesktop0.3.8.1+svn602-1+b1
ii  swh-plugins0.4.16+git20160602~repack1-2

Versions of packages kdenlive suggests:
ii  khelpcenter  4:16.08.3-1

-- no debconf information

Bug#883050: python-pandas: Also auto-detect datetime data types by default

[Kingsley G. Morse Jr.]

Package: python-pandas
Version: 0.20.3-10
Severity: wishlist

Dear Maintainer,

Thank you very much for maintaining Debian's
pandas package.

I say with little fear of contradiction, its very
useful!

The main reason I'm writing is to humbly suggest
improving read_csv() to also automatically detect
datetime data types by default.

read_csv() already automatically detects numeric
data types by default.

And, if its "parse_dates" option is specified with
one or more column indices, it also detects
datetimes.

But, but, but... it seems to me that it would be
convenient and reasonable for read_csv() to
automatically detect BOTH numeric AND datetime
data types by default.

Keep it simple!

Worried about speed?

Assuming numeric data types can be detected
faster, check for them first.

Then datetimes.

Still worried about speed?

Have an option to turn off auto-detection of
datetime data.

Thanks,
Kingsley

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 4.4.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages python-pandas depends on:
ii  python2.7.13-1
ii  python-dateutil   2.2-2
ii  python-numpy  1:1.13.1-1
ii  python-pandas-lib 0.20.3-10
ii  python-pkg-resources  18.4-2
ii  python-six1.10.0-1
ii  python-tz 2012c+dfsg-0.1
pn  python:any

Versions of packages python-pandas recommends:
ii  python-bs4  4.4.1-1
ii  python-html5lib 0.9-1
ii  python-lxml 4.1.0-1
ii  python-matplotlib   2.0.0-3
ii  python-numexpr  2.6.2-2
ii  python-openpyxl 2.3.0-3
ii  python-scipy0.19.1-1
ii  python-statsmodels  0.8.0-1
pn  python-tables   
ii  python-xlrd 0.9.4-1
ii  python-xlwt 0.7.5+debian1-1

Versions of packages python-pandas suggests:
pn  python-pandas-doc  

-- no debconf information

Bug#882384: ffmpeg: Gratuitous valgrind log

[Kingsley G. Morse Jr.]

Hi James,

Yeah, I saw glib and gobject in valgrind's stack
traces too.

I agree ffmpeg may not have a memory bug.

My only doubt?

A dynamic library call might hide one.

I see "dl-init.c" in valgraind's stack traces.

And, I read the following blunt criticism

/* Stupid users forced the ELF specification to be changed.  It now
   says that the dynamic loader is responsible for determining the
   order in which the constructors have to run.  The constructors
   for all dependencies of an object must run before the constructor
   for the object itself.  Circular dependencies are left unspecified.
   This is highly questionable since it puts the burden on the dynamic
   loader which has to find the dependencies at runtime instead of
   letting the user do it right.  Stupidity rules!  */

at

https://code.woboq.org/userspace/glibc/elf/dl-init.c.html

FAQ 4.1 at

http://valgrind.org/docs/manual/faq.html#faq.reports

suggests exporting GLIBCPP_FORCE_NEW and
GLIBCXX_FORCE_NEW.

I did.

At least for me, valgrind still complained.

But, I concede that you may be in a better
position to know.

I just happened to run valgrind, saw ffmpeg stuff,
and thought I should forward it along.

I'll trust you to do with it as you see fit.

So,
Kingsley

-- 
Time is the fire in which we all burn.

Bug#882384: ffmpeg: Gratuitous valgrind log

[Kingsley G. Morse Jr.]

Hi Carl,

> Nearly all messages seem to relate to melt, not FFmpeg.

Thanks for your informed thoughts.

> Can you reproduce any issues with ffmpeg (the executable)?
> 
> The crc issue surprises me a little: Can you produce different
> output files if you use the valgrind option --malloc-fill?

Sure.

A script is attached.

It uses ffmpeg, without melt.

I also attached two log files from valgrind.

One ran it with --malloc-fill.

The other didn't.

So,
Kingsley

-- 
Time is the fire in which we all burn.

# Demonstrate ffmpeg valgrind errors.

# If they do not already exist, create 2 input files for valgrind-ing ffmpeg.
for bailout in 0.9 10 ; do
input_file_name="/tmp/mandelbrot_bailout_${bailout}.mkv"
if ! test -e "$input_file_name" ; then
ffmpeg -t 5 -y -f lavfi -i 
mandelbrot=inner=convergence:bailout=$bailout 
/tmp/mandelbrot_bailout_${bailout}.mkv
fi
done

valgrind --fullpath-after=  \
--leak-check=full   \
--track-origins=yes \
ffmpeg  -y  \
-i /tmp/mandelbrot_bailout_0.9.mkv  \
-i /tmp/mandelbrot_bailout_10.mkv   \
-filter:v tblend=all_mode=hardlight \
/tmp/mandelbrot_bailout_0.9_and_10_hardlight.mkv 2>&1   |
tee /tmp/valgrind_without_--malloc-fill.log

valgrind --fullpath-after=  \
--leak-check=full   \
--track-origins=yes \
 --malloc-fill= \
ffmpeg  -y  \
-i /tmp/mandelbrot_bailout_0.9.mkv  \
-i /tmp/mandelbrot_bailout_10.mkv   \
-filter:v tblend=all_mode=hardlight \
/tmp/mandelbrot_bailout_0.9_and_10_hardlight.mkv 2>&1   |
tee /tmp/valgrind_with_--malloc-fill.log

==32631== Memcheck, a memory error detector
==32631== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==32631== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==32631== Command: ffmpeg -y -i /tmp/mandelbrot_bailout_0.9.mkv -i 
/tmp/mandelbrot_bailout_10.mkv -filter:v tblend=all_mode=hardlight 
/tmp/mandelbrot_bailout_0.9_and_10_hardlight.mkv
==32631== 
--32631-- WARNING: Serious error when reading debug info
--32631-- When reading debug info from 
/usr/lib/i386-linux-gnu/libavcodec.so.57.107.100:
--32631-- get_Form_contents: DW_FORM_strp points outside .debug_str
--32631-- WARNING: Serious error when reading debug info
--32631-- When reading debug info from 
/usr/lib/i386-linux-gnu/libavutil.so.55.78.100:
--32631-- get_Form_contents: DW_FORM_strp points outside .debug_str
ffmpeg version 3.4-3 Copyright (c) 2000-2017 the FFmpeg developers
  built with gcc 7 (Debian 7.2.0-14)
  configuration: --prefix=/usr --extra-version=3 --toolchain=hardened 
--libdir=/usr/lib/i386-linux-gnu --incdir=/usr/include/i386-linux-gnu 
--enable-gpl --disable-stripping --enable-avresample --enable-avisynth 
--enable-gnutls --enable-ladspa --enable-libass --enable-libbluray 
--enable-libbs2b --enable-libcaca --enable-libcdio --enable-libflite 
--enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme 
--enable-libgsm --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg 
--enable-libopenmpt --enable-libopus --enable-libpulse --enable-librubberband 
--enable-librsvg --enable-libshine --enable-libsnappy --enable-libsoxr 
--enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame 
--enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp 
--enable-libx265 --enable-libxml2 --enable-libxvid --enable-libzmq 
--enable-libzvbi --enable-omx --enable-openal --enable-opengl --enable-sdl2 
--enable-libdc1394 --enable-libdrm --enable-libiec61883 --enable-chromaprint 
--enable-frei0r --enable-libopencv --enable-libx264 --enable-shared
  WARNING: library configuration mismatch
  avutil  configuration: --prefix=/usr --extra-version=2+b1 
--toolchain=hardened --libdir=/usr/lib/i386-linux-gnu 
--incdir=/usr/include/i386-linux-gnu --enable-gpl --disable-stripping 
--enable-avresample --enable-avisynth --enable-gnutls --enable-ladspa 
--enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca 
--enable-libcdio --enable-libflite --enable-libfontconfig --enable-libfreetype 
--enable-libfribidi --enable-libgme --enable-libgsm --enable-libmp3lame 
--enable-libmysofa --enable-libopenjpeg --enable-libopenmpt --enable-libopus 
--enable-libpulse --enable-librubberband --enable-librsvg --enable-libshine 
--enable-libsnappy 

Bug#882384: ffmpeg: Gratuitous valgrind log

[Kingsley G. Morse Jr.]

Package: ffmpeg
Version: 7:3.4-3
Severity: normal

Hey guys,

Thank you very much for maintaining Debian's
ffmpeg package.

It's been an enormous source of fun.

In the course of chasing down a different bug, I
had the opportunity to run "melt" with valgrind.

Valgrind reported more ffmpeg problems than I
expected.

It's log is attached.

The code for replicating it is in

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881777

So,
Kingsley

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 4.4.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages ffmpeg depends on:
ii  libavcodec-extra57  7:3.4-2+b1
ii  libavdevice57   7:3.4-2+b1
ii  libavfilter67:3.4-2+b1
ii  libavformat57   7:3.4-2+b1
ii  libavresample3  7:3.4-2+b1
ii  libavutil55 7:3.4-2+b1
ii  libc6   2.25-1
ii  libpostproc54   7:3.4-2+b1
ii  libsdl2-2.0-0   2.0.7+dfsg1-3
ii  libswresample2  7:3.4-2+b1
ii  libswscale4 7:3.4-2+b1

ffmpeg recommends no packages.

Versions of packages ffmpeg suggests:
pn  ffmpeg-doc  

-- no debconf information

Bug#881777: Upgrading libdap fixed it

[Kingsley G. Morse Jr.]

I'm happy to report I seem to have found a
solution.

I'll reveal it, and humbly suggest improvements to
debian's package recommendations and suggestions.


The important lines in valgring's copious output
appear to be

==5040== Invalid free() / delete / delete[] / realloc()
==5040==at 0x482F978: operator delete(void*) 
(coregrind/m_replacemalloc/vg_replace_malloc.c:576)
==5040==by 0x54D3504: deallocate 
(/build/gcc-7-2ld3ob/gcc-7-7.2.0/build/i686-linux-gnu/libstdc++-v3/include/ext/new_allocator.h:125)
==5040==by 0x54D3504: deallocate 
(/build/gcc-7-2ld3ob/gcc-7-7.2.0/build/i686-linux-gnu/libstdc++-v3/include/bits/alloc_traits.h:462)
==5040==by 0x54D3504: _M_destroy 
(/build/gcc-7-2ld3ob/gcc-7-7.2.0/build/i686-linux-gnu/libstdc++-v3/include/bits/basic_string.h:226)
==5040==by 0x54D3504: _M_dispose 
(/build/gcc-7-2ld3ob/gcc-7-7.2.0/build/i686-linux-gnu/libstdc++-v3/include/bits/basic_string.h:221)
==5040==by 0x54D3504: std::__cxx11::basic_string::~basic_string() 
(/build/gcc-7-2ld3ob/gcc-7-7.2.0/build/i686-linux-gnu/libstdc++-v3/include/bits/basic_string.h:647)
==5040==by 0x491A7AA: __run_exit_handlers 
(/build/glibc-EGkrdO/glibc-2.24/stdlib/exit.c:83)
==5040==by 0x491A810: exit 
(/build/glibc-EGkrdO/glibc-2.24/stdlib/exit.c:105)
==5040==by 0x4904291: (below main) 
(/build/glibc-EGkrdO/glibc-2.24/csu/../csu/libc-start.c:325)
==5040==  Address 0x4e13250 is 0 bytes inside a block of size 25 free'd
==5040==at 0x482F978: operator delete(void*) 
(coregrind/m_replacemalloc/vg_replace_malloc.c:576)
==5040==by 0x54D3504: deallocate 
(/build/gcc-7-2ld3ob/gcc-7-7.2.0/build/i686-linux-gnu/libstdc++-v3/include/ext/new_allocator.h:125)
==5040==by 0x54D3504: deallocate 
(/build/gcc-7-2ld3ob/gcc-7-7.2.0/build/i686-linux-gnu/libstdc++-v3/include/bits/alloc_traits.h:462)
==5040==by 0x54D3504: _M_destroy 
(/build/gcc-7-2ld3ob/gcc-7-7.2.0/build/i686-linux-gnu/libstdc++-v3/include/bits/basic_string.h:226)
==5040==by 0x54D3504: _M_dispose 
(/build/gcc-7-2ld3ob/gcc-7-7.2.0/build/i686-linux-gnu/libstdc++-v3/include/bits/basic_string.h:221)
==5040==by 0x54D3504: std::__cxx11::basic_string::~basic_string() 
(/build/gcc-7-2ld3ob/gcc-7-7.2.0/build/i686-linux-gnu/libstdc++-v3/include/bits/basic_string.h:647)
==5040==by 0x491A7AA: __run_exit_handlers 
(/build/glibc-EGkrdO/glibc-2.24/stdlib/exit.c:83)
==5040==by 0x491A810: exit 
(/build/glibc-EGkrdO/glibc-2.24/stdlib/exit.c:105)
==5040==by 0x4904291: (below main) 
(/build/glibc-EGkrdO/glibc-2.24/csu/../csu/libc-start.c:325)
==5040==  Block was alloc'd at
==5040==at 0x482E91C: operator new(unsigned int) 
(coregrind/m_replacemalloc/vg_replace_malloc.c:328)
==5040==by 0x54D2C2B: allocate 
(/build/gcc-7-2ld3ob/gcc-7-7.2.0/build/i686-linux-gnu/libstdc++-v3/include/ext/new_allocator.h:111)
==5040==by 0x54D2C2B: allocate 
(/build/gcc-7-2ld3ob/gcc-7-7.2.0/build/i686-linux-gnu/libstdc++-v3/include/bits/alloc_traits.h:436)
==5040==by 0x54D2C2B: std::__cxx11::basic_string::_M_create(unsigned int&, 
unsigned int) 
(/build/gcc-7-2ld3ob/gcc-7-7.2.0/build/i686-linux-gnu/libstdc++-v3/include/bits/basic_string.tcc:153)
==5040==by 0x17FBEDDB: void std::__cxx11::basic_string::_M_construct(char*, 
char*, std::forward_iterator_tag) [clone .isra.25] 
(/usr/include/c++/7/bits/basic_string.tcc:219)
==5040==by 0x17F01878: __static_initialization_and_destruction_0 
(./D4AsyncUtil.cc:23)
==5040==by 0x17F01878: _GLOBAL__sub_I_D4AsyncUtil.cc 
(./D4AsyncUtil.cc:357)
==5040==by 0x400FC54: call_init.part.0 
(/build/glibc-EGkrdO/glibc-2.24/elf/dl-init.c:72)
==5040==by 0x400FD7D: call_init 
(/build/glibc-EGkrdO/glibc-2.24/elf/dl-init.c:30)
==5040==by 0x400FD7D: _dl_init 
(/build/glibc-EGkrdO/glibc-2.24/elf/dl-init.c:120)
==5040==by 0x4013F56: dl_open_worker 
(/build/glibc-EGkrdO/glibc-2.24/elf/dl-open.c:575)
==5040==by 0x400FB00: _dl_catch_error 
(/build/glibc-EGkrdO/glibc-2.24/elf/dl-error.c:187)
==5040==by 0x4013748: _dl_open 
(/build/glibc-EGkrdO/glibc-2.24/elf/dl-open.c:660)
==5040==by 0x4AA3BF4: dlopen_doit 
(/build/glibc-EGkrdO/glibc-2.24/dlfcn/dlopen.c:66)
==5040==by 0x400FB00: _dl_catch_error 
(/build/glibc-EGkrdO/glibc-2.24/elf/dl-error.c:187)
==5040==by 0x4AA42EC: _dlerror_run 
(/build/glibc-EGkrdO/glibc-2.24/dlfcn/dlerror.c:163)

These show

the bogus second delete() on line 2,

the legit delete() on the 12th line, and

the memory originally being allocated by D4AsyncUtil.cc on the 10th line 
from the bottom.

D4AsyncUtil.cc is part of libdap.

Upgrading these libdap packages

libdapclient6v5:i386from3.15.1-1to  3.19.1-1

and

Bug#881777: Want any more data before I try a full-upgrade?

[Kingsley G. Morse Jr.]

Hey Patrick,

Feel free to let me know if you'd like any more
diagnostic data.

I'm thinking about trying...

root$ aptitude full-upgrade

I expect it would destroy data that might
otherwise help diagnose the bug.

So,
Kingsley

-- 
Time is the fire in which we all burn.

Bug#881777: (gthumb crashed with ... double free or corruption (fasttop))

[Kingsley G. Morse Jr.]

An image viewer and browser named "gthumb" 
crashed with a similar error message...

*** Error in 
`/usr/lib/i386-linux-gnu/gstreamer1.0/gstreamer-1.0/gst-plugin-scanner': double 
free or corruption (fasttop): 0x81319610 ***

Its Backtrace ...

/lib/i386-linux-gnu/libc.so.6(+0x6738a)[0xb729c38a]
/lib/i386-linux-gnu/libc.so.6(+0x6dfc7)[0xb72a2fc7]
/lib/i386-linux-gnu/libc.so.6(+0x6e806)[0xb72a3806]
/usr/lib/i386-linux-gnu/libstdc++.so.6(_ZdlPv+0x18)[0xb6d2ba28]

/usr/lib/i386-linux-gnu/libstdc++.so.6(_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED1Ev+0x25)[0xb6dc7505]
/lib/i386-linux-gnu/libc.so.6(+0x2e7ab)[0xb72637ab]
/lib/i386-linux-gnu/libc.so.6(+0x2e811)[0xb7263811]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0x102)[0xb724d292]

/usr/lib/i386-linux-gnu/gstreamer1.0/gstreamer-1.0/gst-plugin-scanner(+0x715)[0x8008c715]

Upgrading ...

gthumb  3:3.4.3-2 -> 3:3.5.4-1
gthumb-data 3:3.4.3-2 -> 3:3.5.4-1
libcap2 1:2.24-12 -> 1:2.25-1.1
libcap2-bin 1:2.24-12 -> 1:2.25-1.1

seems to have fixed gthumb, but not melt.



So,
Kingsley

-- 
Time is the fire in which we all burn.

Bug#881777: gdb output

[Kingsley G. Morse Jr.]

Running melt in the debugger and waiting for it to
crash gives...

/lib/i386-linux-gnu/libc.so.6(+0x6738a)[0xb7dd438a]
/lib/i386-linux-gnu/libc.so.6(+0x6dfc7)[0xb7ddafc7]
/lib/i386-linux-gnu/libc.so.6(+0x6e806)[0xb7ddb806]
/usr/lib/i386-linux-gnu/libstdc++.so.6(_ZdlPv+0x18)[0xb773da28]

/usr/lib/i386-linux-gnu/libstdc++.so.6(_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED1Ev+0x25)[0xb77d9505]
/lib/i386-linux-gnu/libc.so.6(+0x2e7ab)[0xb7d9b7ab]
/lib/i386-linux-gnu/libc.so.6(+0x2e811)[0xb7d9b811]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0x102)[0xb7d85292]
/usr/bin/melt(+0x2d26)[0x80002d26]

Maybe the last line shows an informative offset
into melt. (0x80002d26).

I checked the package build log for code offsets.

http://clang.debian.net/logs/2017-08-20/mlt_6.4.1-5_unstable_clang.log

No luck.

Worse, it says 434 packages are required to
compile melt.

That looks hard.

So I tried something different: typing "bt", for "back trace".

It reported

(gdb) bt
#0  0x in __kernel_vsyscall ()
#1  0x in __GI_raise (set=0xb290) at 
../sysdeps/unix/sysv/linux/nptl-signals.h:79
#2  0x in __GI_raise (sig=6) at 
../sysdeps/unix/sysv/linux/raise.c:48
#3  0x in __GI_abort () at abort.c:89
#4  0x in __libc_message (do_abort=, fmt=) at ../sysdeps/posix/libc_fatal.c:175
#5  0x in malloc_printerr (action=, str=0xb7ece35c 
"double free or corruption (fasttop)", ptr=, ar_ptr=0xb7f20780 
) at malloc.c:5049
#6  0x in _int_free (av=0xb7f20780 , p=0x801ad508, 
have_lock=0) at malloc.c:3905
#7  0x in operator delete(void*) () at 
/usr/lib/i386-linux-gnu/libstdc++.so.6
#8  0x in std::__cxx11::basic_string::~basic_string() () at 
/usr/lib/i386-linux-gnu/libstdc++.so.6
#9  0x in __run_exit_handlers (status=0, listp=0xb7f203dc 
<__exit_funcs>, run_list_atexit=true, run_dtors=true) at exit.c:83
#10 0x in __GI_exit (status=0) at exit.c:105
#11 0x in __libc_start_main (main=0x80001960 , argc=9, 
argv=0xb854, init=0x80004160 <__libc_csu_init>, fini=0x800041c0 
<__libc_csu_fini>, rtld_fini=0xb7feb070 <_dl_fini>, stack_end=0xb84c) at 
../csu/libc-start.c:325
#12 0x in _start ()

Note: There's no "melt" or "mlt" in any stack
frame.

Frame number 9 mentions "atexit", which suggests
to me that glibc code is crashing when it tries to
execute a function specified in melt before it
exited.

That suggests to me melt's stack is gone.

And of no use.

If it weren't for bad luck, I'd have no luck at
all.

Certainly, valgrind will find the bug.

Next time: Or will it...?

So,
Kingsley

-- 
Time is the fire in which we all burn.

Bug#881777: Workaround

[Kingsley G. Morse Jr.]

Check out the environment variable MALLOC_CHECK_
in ...

$ export MALLOC_CHECK_=5 ; /usr/bin/melt /tmp/mandelbrot.mlt in=0 out=149 
-profile /tmp/customprofile3 -consumer avformat:/tmp/melt.mkv 
properties=lossless/HuffYUV

MALLOC_CHECK_ controls  how  glibc responds to
programming errors.

Setting it to 5 

a.) prints a simple error message and

b.) continues execution.

It doesn't fix the bug.

But, on the plus side, it renders a watchable video.

So,
Kingsley

-- 
Time is the fire in which we all burn.

Bug#881777: Maybe this bug is related to #847700

[Kingsley G. Morse Jr.]

Hi Patrick and David,

I seem to recall that my bug was initially limited
to only the .mkv format.

But, now all renders fail.

Even kdenlive projects that used to render to
.webm fail.

Maybe this bug is related to #847700.

In it, David wrote

Tested with WebM, MP4, MP4-H265, Webm... The
render doesn't end.

I just tried mv-ing

~/.config
~/.local

and

~/.cache

and re-rendering a kdenlive project to .webm that
used to work.

No luck.

It still crashed.

Comments welcome.

So,
Kingsley

-- 
Time is the fire in which we all burn.

Bug#881461: frei0r-plugins: Breaks frei0r-plugins (<= 1.1.22)

[Kingsley G. Morse Jr.]

Hi Sebastian,

Thank you very much for sharing your thoughts.

It seems to me you asked a reasonable question:

> Why should frei0r-plugins break itself?

Through no fault of your own, when I filed the bug
report, I 

1.) was unaware that a source package named
just "frei0r" existed, and

2.) failed to mention I assumed 

a.) the "Breaks" header referred to a
non-existent package, and

b.) what the original author meant was to say 
frei0r-plugins broke an *earlier version*
of itself.

So...

You were right!

I was wrong!


But, but, but, I now find myself wondering if
maybe the "Breaks:" header should just be removed.

Why?

If 

a.) it doesn't make sense for a package to
break itself, then maybe

b.) it also doesn't make sense for a package
to break its own source package.

I dunno.

And I don't have a strong preference.

Thanks again for sharing your thoughts.

I find I often benefit from other peoples' point
of view.

Now seems to be one of those times!

:-)

So,
Kingsley

-- 
Time is the fire in which we all burn.

Bug#881461: frei0r-plugins: Breaks frei0r-plugins (<= 1.1.22)

[Kingsley G. Morse Jr.]

Package: frei0r-plugins
Version: 1.6.1-1+b1
Severity: minor

Dear Maintainer,

Thanks for maintaining frei0r's plugins.

They look cool.

* What led up to the situation?

I wondered why ffmpeg failed to use frei0r plugins
as ffmpeg sources.

* What exactly did you do (or not do) that was effective (or
 ineffective)?

I typed

$ apt-cache show frei0r-plugins

and read the "Breaks:" header.

* What was the outcome of this action?

Breaks: frei0r (<= 1.1.22)

* What outcome did you expect instead?

Breaks: frei0r-plugins (<= 1.1.22)


Thanks,
Kingsley

Bonus:  Tell me where to look for documentation on
parameters and syntax for using frei0r effects as
ffmpeg sources.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 4.4.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages frei0r-plugins depends on:
ii  libc62.24-17
ii  libcairo21.14.8-1
ii  libgavl1 1.4.0-3
ii  libgcc1  1:7.2.0-12
ii  libopencv-calib3d3.2 3.2.0+dfsg-3
ii  libopencv-contrib3.2 3.2.0+dfsg-3
ii  libopencv-core3.23.2.0+dfsg-3
ii  libopencv-features2d3.2  3.2.0+dfsg-3
ii  libopencv-flann3.2   3.2.0+dfsg-3
ii  libopencv-highgui3.2 3.2.0+dfsg-3
ii  libopencv-imgcodecs3.2   3.2.0+dfsg-3
ii  libopencv-imgproc3.2 3.2.0+dfsg-3
ii  libopencv-ml3.2  3.2.0+dfsg-3
ii  libopencv-objdetect3.2   3.2.0+dfsg-3
ii  libopencv-photo3.2   3.2.0+dfsg-3
ii  libopencv-shape3.2   3.2.0+dfsg-3
ii  libopencv-stitching3.2   3.2.0+dfsg-3
ii  libopencv-superres3.23.2.0+dfsg-3
ii  libopencv-video3.2   3.2.0+dfsg-3
ii  libopencv-videoio3.2 3.2.0+dfsg-3
ii  libopencv-videostab3.2   3.2.0+dfsg-3
ii  libopencv-viz3.2 3.2.0+dfsg-3
ii  libstdc++6   7.2.0-12

frei0r-plugins recommends no packages.

Versions of packages frei0r-plugins suggests:
pn  opencv-data  

-- no debconf information

Bug#826701: Same error with 5.0.6+dfsg1-1

[Kingsley G. Morse Jr.]

Hi Anton,

Thanks for replying so quickly.

I seem to have worked around the problem by doing

$ dpkg -i --force-overwrite 
/var/cache/apt/archives/gnuplot-data_5.0.6+dfsg1-1_all.deb
$ apt-get -f install

So,
Kingsley

On 07/24/2017 21:47, Anton Gladky wrote:
> Hi,
> 
> the upgrade 4.6.6-3 -> 5.0.6+dfsg1-1 is not supported. The only
> supported upgrade between stable versions: 4.6.6-3 -> 5.0.5+dfsg1-6+deb9u1.
> 
> All other combination are not guaranteed.
> 
> Best regards
> 
> Anton
> 
> 
> 2017-07-24 21:09 GMT+02:00 Kingsley G. Morse Jr. <kings...@loaner.com>:
> > Hey guys,
> >
> > Thank you very much for maintaining gnuplot.
> >
> > I love how many options it has.
> >
> > I happened to notice this report's bug seems to
> > also be in a newer version.
> >
> > It was originally reported against 5.0.3+dfsg3-1.
> >
> > I see it with 5.0.6+dfsg1-1.

-- 
Time is the fire in which we all burn.

Bug#826701: Same error with 5.0.6+dfsg1-1

[Kingsley G. Morse Jr.]

Hey guys,

Thank you very much for maintaining gnuplot.

I love how many options it has.

I happened to notice this report's bug seems to
also be in a newer version.

It was originally reported against 5.0.3+dfsg3-1.

I see it with 5.0.6+dfsg1-1.

Here's some output that aptitude sent to my console:

[...]
(Reading database ... 660620 files and directories currently installed.)
Preparing to unpack .../gnuplot-data_5.0.6+dfsg1-1_all.deb ...
Unpacking gnuplot-data (5.0.6+dfsg1-1) over (4.6.6-3) ...
dpkg: error processing archive 
/var/cache/apt/archives/gnuplot-data_5.0.6+dfsg1-1_all.deb (--unpack):
 trying to overwrite 
'/usr/share/texmf/tex/latex/gnuplot/gnuplot-lua-tikz-common.tex', which is also 
in package gnuplot-tex 4.6.6-3
Errors were encountered while processing:
 /var/cache/apt/archives/gnuplot-data_5.0.6+dfsg1-1_all.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
[...]

So,
Kingsley


-- 
Time is the fire in which we all burn.

Bug#832801: mv ~/.config/kdenliverc tmp works again!

[Kingsley G. Morse Jr.]

New symptom:

Positions within a kdenlive project's timeline
and a clip's effects and transitions weren't
synchronized.

Same solution:

$ mv ~/.config/kdenliverc tmp

worked again!


That's the good news.

The bad news?

The aptly named "debugger" (gdb) fixes

[mlt_pool] out of memory

Not by finding the bug.

It just stops it from happening.

So far.

So,
Kingsley


-- 
Time is the fire in which we all burn.

Bug#864531: systemd: No sound

[Kingsley G. Morse Jr.]

Package: systemd
Version: 232-25
Severity: normal

* What led up to the situation?

a.) Upgrading systemd and udev from version 231-9 to
232-25.

b.) Trying to play sound.


* What exactly did you do (or not do) that was effective (or
  ineffective)?

a.) root$ dmesg | egrep -i error

revealled

cannot find the slot for index 0 (range 0-0), error: -16

b.) Moved /etc/modprobe.d/sound.conf to a
temporary directory.

It contains

alias snd-card-0 snd-
options snd- index=0

c.) Rebooted.

d.) Tried playing a sound.


* What was the outcome of this action?

a.) Sound.

b.) Note to self: Check how Devuan is coming along.



-- Package-specific info:

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 4.4.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages systemd depends on:
ii  adduser 3.113+nmu3
ii  libacl1 2.2.52-2
ii  libapparmor12.11.0-3
ii  libaudit1   1:2.4.4-4
ii  libblkid1   2.28.1-1
ii  libc6   2.24-11
ii  libcap2 1:2.24-12
ii  libcryptsetup4  2:1.7.3-2
ii  libgcc1 1:6.3.0-12
ii  libgcrypt20 1.7.6-1
ii  libgpg-error0   1.26-2
ii  libidn111.33-1
ii  libip4tc0   1.6.0+snapshot20161117-6
ii  libkmod221-1
ii  liblz4-10.0~r131-1
ii  liblzma55.2.2-1.1
ii  libmount1   2.28.1-1
ii  libpam0g1.1.8-3.2
ii  libseccomp2 2.3.1-2.1
ii  libselinux1 2.3-2+b1
ii  libsystemd0 232-25
ii  mount   2.28.1-1
ii  procps  2:3.3.12-3
ii  util-linux  2.28.1-1

Versions of packages systemd recommends:
ii  dbus1.10.16-1
ii  libpam-systemd  232-25

Versions of packages systemd suggests:
ii  policykit-10.105-13
pn  systemd-container  
pn  systemd-ui 

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.120
ii  udev 232-25

-- no debconf information

Bug#863847: gnumeric: CPU hog

[Kingsley G. Morse Jr.]

Package: gnumeric
Version: 1.12.32-1+b1
Severity: normal

Hi Dmitry,

Thank you very much for maintaining Debian's
gnumeric package.

I like it!

Disclaimer: This is a long and inconclusive bug
report.

So,
Kingsley

   * What led up to the situation?

 Maybe 
 
copying sheets between workbooks,

sorting,

using mismatched versions of packages from
Debian's unstable distribution, or

my cursed good looks.


   * What exactly did you do (or not do) that was effective (or
 ineffective)?

 I dunno.


   * What was the outcome of this action?


 The "top" command said gnumeric was using
 100% of CPU.

 (Plus, sorting started failing for me a few
 weeks ago.)


 The "sar" command said over half was for
 "%user".


strace didn't help.

$ strace -c -p 11579

% time seconds  usecs/call callserrors syscall
-- --- --- - - 
  0.000.00   043   writev
  0.000.00   0   128   poll
  0.000.00   08987 recvmsg
-- --- --- - - 
100.000.00   26087 total


gdb reported 

kingsley$ gdb --q --n --ex bt --batch --pid 11579

[New LWP 11583]
[New LWP 11581]
[New LWP 11580]
[Thread debugging using libthread_db enabled]
Using host libthread_db library 
"/lib/i386-linux-gnu/libthread_db.so.1".
0xb616521c in ?? () from /usr/lib/i386-linux-gnu/libcairo.so.2
#0  0xb616521c in ?? () from /usr/lib/i386-linux-gnu/libcairo.so.2
#1  0xb6160559 in ?? () from /usr/lib/i386-linux-gnu/libcairo.so.2
#2  0xb61656dc in ?? () from /usr/lib/i386-linux-gnu/libcairo.so.2
#3  0xb61a2266 in ?? () from /usr/lib/i386-linux-gnu/libcairo.so.2
#4  0xb613fe57 in ?? () from /usr/lib/i386-linux-gnu/libcairo.so.2
#5  0xb61bf013 in ?? () from /usr/lib/i386-linux-gnu/libcairo.so.2
#6  0xb618e0ab in ?? () from /usr/lib/i386-linux-gnu/libcairo.so.2
#7  0xb6149082 in ?? () from /usr/lib/i386-linux-gnu/libcairo.so.2
#8  0xb61418e6 in ?? () from /usr/lib/i386-linux-gnu/libcairo.so.2
#9  0xb6139fdc in cairo_stroke_preserve () from 
/usr/lib/i386-linux-gnu/libcairo.so.2
#10 0xb741343c in ?? () from /usr/lib/libspreadsheet-1.12.32.so
#11 0xb71d6aa8 in ?? () from /usr/lib/libgoffice-0.10.so.10
#12 0xb71d6a93 in ?? () from /usr/lib/libgoffice-0.10.so.10
#13 0xb71d290c in ?? () from /usr/lib/libgoffice-0.10.so.10
#14 0xb6d066d4 in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#15 0xb6ad1cdb in gtk_container_propagate_draw () from 
/usr/lib/i386-linux-gnu/libgtk-3.so.0
#16 0xb6ad1dae in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#17 0xb6b5b87e in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#18 0xb6ad73e5 in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#19 0xb6adcc62 in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#20 0xb6b5c802 in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#21 0xb6d066d4 in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#22 0xb6ad1cdb in gtk_container_propagate_draw () from 
/usr/lib/i386-linux-gnu/libgtk-3.so.0
#23 0xb6bce63c in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#24 0xb6ad73e5 in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#25 0xb6adcc62 in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#26 0xb6a852d7 in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#27 0xb6adcc62 in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#28 0xb6bd0eec in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#29 0xb6d066d4 in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#30 0xb6ad1cdb in gtk_container_propagate_draw () from 
/usr/lib/i386-linux-gnu/libgtk-3.so.0
#31 0xb6ad1dae in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#32 0xb6a80d0e in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#33 0xb6ad73e5 in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#34 0xb6adcc62 in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#35 0xb6a83832 in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#36 0xb6d066d4 in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#37 0xb6ad1cdb in gtk_container_propagate_draw () from 
/usr/lib/i386-linux-gnu/libgtk-3.so.0
#38 0xb6ad1dae in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#39 0xb6a80d0e in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0

Bug#863451: veusz: Segmentation fault

[Kingsley G. Morse Jr.]

Package: veusz
Version: 1.21.1-1
Severity: important

O' mighty maintainers o' mega math maps!

   * What led up to the situation?

root$ aptitude install veusz
The following NEW packages will be installed:
  veusz veusz-helpers{a}

kingsley$ veusz

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Curse these good looks!

;-)

   * What was the outcome of this action?

VO table import: astropy module not available
SAMP: sampy module not available
Segmentation fault

   * What outcome did you expect instead?

A Louvre-worthy GUI.

Thanks,
Kingsley

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 4.4.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages veusz depends on:
ii  python 2.7.13-1
ii  python-numpy   1:1.12.0-2
ii  python-qt4 4.11.4+dfsg-2
ii  veusz-helpers  1.21.1-1

veusz recommends no packages.

Versions of packages veusz suggests:
ii  python-dbus1.2.0-2+b4
pn  python-h5py
pn  python-pyfits  

-- no debconf information

Bug#860449: python-statsmodels: KaplanMeier.fit() crashes

[Kingsley G. Morse Jr.]

Package: python-statsmodels
Version: 0.8.0-1
Severity: normal

In a secret underground lab, a solitary caped
figure kneels in front of a computer screen.

Who is this mysterious genius??

And why has he never been photographed together
with tall, dark, handsome Kingsley?

A lightning bolt blasts across the keyboard!

Look!

Up in the sky!

Is it a bird?

No!

Is it a plane?

NO!

It's...

IT'S...

YES!!!

It'S ... SCIENCE MAN!!!

Champion of critical thinking!

Defender of data!

Sworn foe of boring bug reports everywhere!

But wait!

What's this?

A diabolical bug has infested the python-statsmodels package!

Oh no!

It threatens to establish a totalitarian system of
rule over Kaplan Meier calculations!

What CAN be done?

SCIENCE MAN uses his super powers to reveal to all
lovers of truth, justice and statistics just how to
elicit the bug.

He tried the example starting on line 64 of

/usr/lib/python2.7/dist-packages/statsmodels/sandbox/survival2.py

What woe befell our hero?

Behold!

>>> import statsmodels.api as sm
>>> import matplotlib.pyplot as plt
>>> import numpy as np
>>> from statsmodels.sandbox.survival2 import KaplanMeier
>>> dta = sm.datasets.strikes.load()
>>> dta = dta.values()[-1]
>>> dta[range(5),:]
array([[  7.e+00,   1.1380e-02],
   [  9.e+00,   1.1380e-02],
   [  1.3000e+01,   1.1380e-02],
   [  1.4000e+01,   1.1380e-02],
   [  2.6000e+01,   1.1380e-02]])
>>> km = KaplanMeier(dta,0)
>>> km.fit()
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/dist-packages/statsmodels/sandbox/survival2.py", 
line 203, in fit
self.fitting_proc(self.data)
  File "/usr/lib/python2.7/dist-packages/statsmodels/sandbox/survival2.py", 
line 249, in fitting_proc
events = events[:,list(t)]
IndexError: too many indices for array

Zounds

An IndexError has rendered SCIENCE MAN'S super
powers useless!

SCIENCE MAN has been vanquished by his
arch-nemesis, bad code!

With his last breath, SCIENCE MAN gasps that the
same error happened with version
0.8.0~rc1+git59-gef47cd9-5.

Certainly the bug will now be fixed by a super genius maintainer!

Or will it...?


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 4.4.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages python-statsmodels depends on:
ii  python  2.7.13-1
ii  python-numpy1:1.12.0-2
ii  python-patsy0.4.0-1
ii  python-scipy0.18.1-2
ii  python-statsmodels-lib  0.8.0-1
pn  python:any  

Versions of packages python-statsmodels recommends:
pn  python-cvxopt  
ii  python-joblib  0.9.2-1
ii  python-matplotlib  2.0.0-3
ii  python-nose1.3.6-1
ii  python-pandas  0.17.0+git8-gcac4ad2-2

Versions of packages python-statsmodels suggests:
ii  python-statsmodels-doc  0.8.0~rc1+git59-gef47cd9-5

-- no debconf information

Bug#832801: [mlt_pool] out of memory

[Kingsley G. Morse Jr.]

Oops!

I forgot to mention that

[mlt_pool] out of memory

also appears on the console when kdenlive hangs.

Sorry,
Kingsley

-- 
Time is the fire in which we all burn.

Bug#832801: Moving kdenlive's config file fixed another bug

[Kingsley G. Morse Jr.]

For what it's worth, the workaround I described
above

$ rm .config/kdenliverc

basically seems to have fixed another bug.

Here's what happened:

$ export MESA_EXTENSION_OVERRIDE=-GL_ARB_draw_indirect ; kdenlive

  kdenlive->File->Open recent->(a kdenlive project)

  kdenlive->mute a track's audio

  move the mouse pointer to about 3 minutes on
  kdenlive's time line and click

  play the project starting at that point
  (if I recall correctlym by pressing the key
  board's space bar)

  It plays back in the preview monitor for a
  few seconds, then freezes.

  An error message *somewhat* *like*

nouveau: kernel rejected pushbuf: Invalid argument 
nouveau: ch3: krec 0 pushes 1 bufs 1 relocs 0
nouveau: ch3: buf  000b 0006 0006 

  appeared on the console, and

[883948.153199] nouveau :01:00.0: kdenlive[16711]: multiple 
instances of buffer 36 on validation list
[883948.153208] nouveau :01:00.0: kdenlive[16711]: validate_init
[883948.153210] nouveau :01:00.0: kdenlive[16711]: validate: -22

  appeared in dmesg.

I'm happy to report

a.) moving kdenlive's config file with

$ mv .config/kdenliverc tmp

seems to have worked around this bug too,
and

b.) I saved a copy of the config file.


My question?

Is there somethink like "lint"[1] that can check
kdenliverc files for corruption?

It seems to me that knowing which part of my
kdenliverc is corrupted might facilitate fixing
a bug or two.

Thanks,
Kingsley

[1] Lint (software)
https://en.wikipedia.org/wiki/Lint_%28software%29



-- 
Time is the fire in which we all burn.

Bug#832801: $ rm .config/kdenliverc

[Kingsley G. Morse Jr.]

I tried

$ rm .config/kdenliverc

and re-ran kdenlive.

It worked!

Humble suggestion:

Keep this bug open for a month or so, in case the
bug reappears.

Thanks,
Kingsley

-- 
Time is the fire in which we all burn.

Bug#832801: gdb trace with symbols

[Kingsley G. Morse Jr.]

Hi,

Julien Cristau very nicely explained that
libgl1-mesa-dri-dbgsym is available in the debug
archive.

So, I'm happy to report the following gdb trace
with symbolic offsets in nouveau:

Program received signal SIGSEGV, Segmentation fault.
0xa2c17e2e in list_del (item=0x48920048) at 
../../../../../src/util/list.h:84
84  ../../../../../src/util/list.h: No such file or directory.
(gdb) bt full
#0  0xa2c17e2e in list_del (item=0x48920048) at 
../../../../../src/util/list.h:84
No locals.
#1  nouveau_fence_trigger_work (fence=fence@entry=0x4a7e0d20) at 
../../../../../src/gallium/drivers/nouveau/nouveau_fence.c:57
work = 0x48920048
tmp = 0x484800d8
#2  0xa2c18079 in nouveau_fence_update (screen=0x80b547d0, flushed=false) 
at ../../../../../src/gallium/drivers/nouveau/nouveau_fence.c:132
fence = 0x4a7e0d20
next = 0x0
sequence = 2550
#3  0xa2c1838b in nouveau_fence_wait (fence=0xb090e160, debug=0x0) at 
../../../../../src/gallium/drivers/nouveau/nouveau_fence.c:223
screen = 0x80b547d0
spins = 1432577896
start = 0
#4  0xa2c18f98 in nouveau_screen_fence_finish (screen=0x80b547d0, 
pfence=0xb090e160, timeout=18446744073709551615)
at ../../../../../src/gallium/drivers/nouveau/nouveau_screen.c:79
screen = 0x80b547d0
timeout = 18446744073709551615
pfence = 0xb090e160
#5  0xa2adaa8b in dri_flush (cPriv=0x82059580, dPriv=0x81fa53c8, flags=3, 
reason=__DRI2_THROTTLE_SWAPBUFFER)
at ../../../../../src/gallium/state_trackers/dri/dri_drawable.c:528
screen = 0x80b547d0
fence = 0xb090e160
flush_flags = 
swap_msaa_buffers = 0 '\000'
#6  0xb7c8cd95 in ?? () from /usr/lib/i386-linux-gnu/libGL.so.1
No symbol table info available.
#7  0xb7c8d18e in ?? () from /usr/lib/i386-linux-gnu/libGL.so.1
No symbol table info available.
#8  0xb7c63103 in glXSwapBuffers () from /usr/lib/i386-linux-gnu/libGL.so.1
No symbol table info available.
#9  0xb1dfc0b0 in ?? () from 
/usr/lib/i386-linux-gnu/qt5/plugins/xcbglintegrations/libqxcb-glx-integration.so
No symbol table info available.
#10 0xb5537801 in QOpenGLContext::swapBuffers(QSurface*) () from 
/usr/lib/i386-linux-gnu/sse2/libQt5Gui.so.5
No symbol table info available.
#11 0xb760efaf in ?? () from /usr/lib/i386-linux-gnu/libQt5Quick.so.5
No symbol table info available.
#12 0xb76101c8 in ?? () from /usr/lib/i386-linux-gnu/libQt5Quick.so.5
No symbol table info available.
#13 0xb6325f6a in QApplicationPrivate::notify_helper(QObject*, QEvent*) () 
from /usr/lib/i386-linux-gnu/libQt5Widgets.so.5
No symbol table info available.
#14 0xb632b7fc in QApplication::notify(QObject*, QEvent*) () from 
/usr/lib/i386-linux-gnu/libQt5Widgets.so.5
No symbol table info available.
#15 0xb51b3c84 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () 
from /usr/lib/i386-linux-gnu/sse2/libQt5Core.so.5
No symbol table info available.
#16 0xb520a0bd in QTimerInfoList::activateTimers() () from 
/usr/lib/i386-linux-gnu/sse2/libQt5Core.so.5
No symbol table info available.
#17 0xb520a689 in ?? () from /usr/lib/i386-linux-gnu/sse2/libQt5Core.so.5
No symbol table info available.
#18 0xb4516ee9 in g_main_context_dispatch () from 
/lib/i386-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#19 0xb4517189 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#20 0xb4517254 in g_main_context_iteration () from 
/lib/i386-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#21 0xb520b233 in 
QEventDispatcherGlib::processEvents(QFlags) () 
from /usr/lib/i386-linux-gnu/sse2/libQt5Core.so.5
No symbol table info available.
#22 0xb1cfdc71 in ?? () from /usr/lib/i386-linux-gnu/libQt5XcbQpa.so.5
No symbol table info available.
#23 0xb51b12d6 in 
QEventLoop::processEvents(QFlags) () from 
/usr/lib/i386-linux-gnu/sse2/libQt5Core.so.5
No symbol table info available.
#24 0xb51b170a in QEventLoop::exec(QFlags) 
() from /usr/lib/i386-linux-gnu/sse2/libQt5Core.so.5
No symbol table info available.
#25 0xb51ba3a5 in QCoreApplication::exec() () from 
/usr/lib/i386-linux-gnu/sse2/libQt5Core.so.5
No symbol table info available.
#26 0xb54ed211 in QGuiApplication::exec() () from 
/usr/lib/i386-linux-gnu/sse2/libQt5Gui.so.5
No symbol table info available.
#27 0xb6322b14 in QApplication::exec() () from 
/usr/lib/i386-linux-gnu/libQt5Widgets.so.5
No symbol table info available.
#28 0x8005b64e in main (argc=, argv=) at 
/build/kdenlive-txSbfO/kdenlive-16.04.3/src/main.cpp:130
app = 
aboutData = {d = 0x806f62d0}
parser = {d = 0x806f6be8}
programDBusService = 
result = 

I now see this bears an uncanny resemblance to a
known 

Bug#832801: libgl1-mesa-dri: kdenlive->play clip->nouveau_dri.so->segmentation fault

[Kingsley G. Morse Jr.]

Package: libgl1-mesa-dri
Version: 11.2.2-1
Severity: normal

Dear Maintainer,

Sorry, I wish I didn't feel the need to mention
thia, but I seem to have stumbled upon a way to
elicit a SIGSEGV from

/usr/lib/i386-linux-gnu/dri/nouveau_dri.so

I was using a video editor named "kdenlive" to
preview a video clip.

After playing it for a few seconds, video playback
hangs, while audio continues.

Then, a few seconds later... CRASH!

Here's a full old-school back trace from gdb

#0  0xb7fdac31 in __kernel_vsyscall ()
No symbol table info available.
#1  0xb4be1c19 in raise () from /lib/i386-linux-gnu/libc.so.6
No symbol table info available.
#2  0xb4be3117 in abort () from /lib/i386-linux-gnu/libc.so.6
No symbol table info available.
#3  0xb4c1c67c in ?? () from /lib/i386-linux-gnu/libc.so.6
No symbol table info available.
#4  0xb4c22627 in ?? () from /lib/i386-linux-gnu/libc.so.6
No symbol table info available.
#5  0xb4c22dd1 in ?? () from /lib/i386-linux-gnu/libc.so.6
No symbol table info available.
#6  0xa2c17e42 in ?? () from /usr/lib/i386-linux-gnu/dri/nouveau_dri.so
No symbol table info available.
#7  0xa2c18079 in ?? () from /usr/lib/i386-linux-gnu/dri/nouveau_dri.so
No symbol table info available.
#8  0xa2c1838b in ?? () from /usr/lib/i386-linux-gnu/dri/nouveau_dri.so
No symbol table info available.
#9  0xa2c18f98 in ?? () from /usr/lib/i386-linux-gnu/dri/nouveau_dri.so
No symbol table info available.
#10 0xa2adaa8b in ?? () from /usr/lib/i386-linux-gnu/dri/nouveau_dri.so
No symbol table info available.
#11 0xb7c8cd95 in ?? () from /usr/lib/i386-linux-gnu/libGL.so.1
No symbol table info available.
#12 0xb7c8d18e in ?? () from /usr/lib/i386-linux-gnu/libGL.so.1
No symbol table info available.
#13 0xb7c63103 in glXSwapBuffers () from /usr/lib/i386-linux-gnu/libGL.so.1
No symbol table info available.
#14 0xb1dfc0b0 in ?? ()
   from 
/usr/lib/i386-linux-gnu/qt5/plugins/xcbglintegrations/libqxcb-glx-integration.so
No symbol table info available.
#15 0xb5537801 in QOpenGLContext::swapBuffers(QSurface*) ()
   from /usr/lib/i386-linux-gnu/sse2/libQt5Gui.so.5
No symbol table info available.
#16 0xb760efaf in ?? () from /usr/lib/i386-linux-gnu/libQt5Quick.so.5
No symbol table info available.
#17 0xb76101c8 in ?? () from /usr/lib/i386-linux-gnu/libQt5Quick.so.5
No symbol table info available.
#18 0xb6325f6a in QApplicationPrivate::notify_helper(QObject*, QEvent*) ()
   from /usr/lib/i386-linux-gnu/libQt5Widgets.so.5
No symbol table info available.
#19 0xb632b7fc in QApplication::notify(QObject*, QEvent*) ()
   from /usr/lib/i386-linux-gnu/libQt5Widgets.so.5
No symbol table info available.
#20 0xb51b3c84 in QCoreApplication::notifyInternal2(QObject*, QEvent*) ()
   from /usr/lib/i386-linux-gnu/sse2/libQt5Core.so.5
No symbol table info available.
#21 0xb520a0bd in QTimerInfoList::activateTimers() ()
   from /usr/lib/i386-linux-gnu/sse2/libQt5Core.so.5
No symbol table info available.
#22 0xb520a689 in ?? () from /usr/lib/i386-linux-gnu/sse2/libQt5Core.so.5
No symbol table info available.
#23 0xb4516ee9 in g_main_context_dispatch ()
   from /lib/i386-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#24 0xb4517189 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#25 0xb4517254 in g_main_context_iteration ()
   from /lib/i386-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#26 0xb520b233 in 
QEventDispatcherGlib::processEvents(QFlags) () 
from /usr/lib/i386-linux-gnu/sse2/libQt5Core.so.5
No symbol table info available.
#27 0xb1cfdc71 in ?? () from /usr/lib/i386-linux-gnu/libQt5XcbQpa.so.5
No symbol table info available.
#28 0xb51b12d6 in 
QEventLoop::processEvents(QFlags) () from 
/usr/lib/i386-linux-gnu/sse2/libQt5Core.so.5
No symbol table info available.
#29 0xb51b170a in QEventLoop::exec(QFlags) ()
   from /usr/lib/i386-linux-gnu/sse2/libQt5Core.so.5
No symbol table info available.
#30 0xb51ba3a5 in QCoreApplication::exec() ()
   from /usr/lib/i386-linux-gnu/sse2/libQt5Core.so.5
No symbol table info available.
#31 0xb54ed211 in QGuiApplication::exec() ()
   from /usr/lib/i386-linux-gnu/sse2/libQt5Gui.so.5
No symbol table info available.
#32 0xb6322b14 in QApplication::exec() ()
   from /usr/lib/i386-linux-gnu/libQt5Widgets.so.5
No symbol table info available.
#33 0x8005b64e in main (argc=, argv=)
at /build/kdenlive-txSbfO/kdenlive-16.04.3/src/main.cpp:130
app = 
aboutData = {d = 0x806f5dc8}
parser = {d = 0x806f6d58}
programDBusService = 
result = 

Sorry about not giving you symbolic code offsets.

(I just filed a related bug report (#832800)
asking for an i386/11.2.2-1 version of 

Bug#832800: libgl1-mesa-dri-dbgsym: Please release for i386 architecture

[Kingsley G. Morse Jr.]

Package: libgl1-mesa-dri-dbgsym
Version: 11.2.2-1
Severity: normal

Dear Maintainer,

Thanks for helping with mesa.

I get the impression maintaining it requires an
agile mind.

The main reason I'm writing is to politely ask for
an i386 / 11.2.2-1 version of
libgl1-mesa-dri-dbgsym.

When I looked for one at

https://packages.debian.org/search?keywords=libgl1-mesa-dri-dbg

I only saw other architectures listed.

(Alternatively, I expect I'd also be OK with a
libgl1-mesa-dri-dbg.)

Why?

I seem to have stumbled upon a way to elicit a
segmentation fault from 

 /usr/lib/i386-linux-gnu/dri/nouveau_dri.so

As you know, symbolic code offsets would help
debug it.

It basically happens after playing a few seconds
of a clip in the video editor named kdenlive.

Thanks,
Kingsley

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 4.4.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Bug#826290: libc6-i686: Neither "$ aptitude show" or "$ apt-cache show" says libc6-i686 is a virtual package

[Kingsley G. Morse Jr.]

Package: libc6-i686
Version: 2.22-7
Severity: minor

Hey guys,

I hope you're well.


* What led up to the situation?

   While installing security patches, aptitude
   asked if it would be OK to remove libc6-i686,
   and neither

$ apt-cache show libc6-i686

or

$ aptitude show libc6-i686

reported that libc6-i686 is now a virtual
package.

Instead, they said libc6-i686 contains the
standard libraries that are used by nearly all
programs on the system.


* What exactly did you do (or not do) that was effective (or
  ineffective)?

With some help from awwal and Alam_Squeeze on
OFTC's #debian-next channel, I saw that
libc6-i686's web page at

https://packages.debian.org/sid/libc6-i686

says it's a virtual package.

So I removed libc6-i686.


* What was the outcome of this action?

It worked, at least for the (about) half hour
between removal and typing this bug report.


* What outcome did you expect instead?

I expected 

"$ aptitude show libc60i686"

and 

"$ apt-cache show libc6-i686" 

to report that libc6-i686 is a virtual
package, and not that it contains the standard
libraries that are used by nearly all programs
on the system.

Thanks,
Kingsley

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 4.4.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages libc6-i686 depends on:
ii  libc6  2.22-10

libc6-i686 recommends no packages.

libc6-i686 suggests no packages.