Bug#994741: regression tests: skipped vs failed

[ian_bruce]

On Tue, 21 Sep 2021 19:03:07 +0200
Mattia Rizzolo  wrote:

> concerning the ftbfs of 1.1. I know of it of course. Just that I've
> been busy over the past month. I'm as weirded out by that test failure
> as you, especially since I couldn't reproduce it anywhere else.

Does that not suggest that the problem is some peculiarity of the build
environment, rather than any specific problem with the Inkscape code?

Comparing the build logs for v1.0.2 and v1.1, one discovers that the
reason that this is not a problem for v1.0.2 is that this specific test
apparently does not exist in that version.

https://buildd.debian.org/status/fetch.php?pkg=inkscape=amd64=1.0.2-4=1618427913=0

https://buildd.debian.org/status/fetch.php?pkg=inkscape=amd64=1.1-1=1629559190=0

But what is this?


Unable to init server: Could not connect: Connection refused
Failed to get connection
** (inkscape:2024671): CRITICAL **: 15:19:35.442: 
dbus_g_proxy_new_for_name: assertion 'connection != NULL' failed

** (inkscape:2024671): CRITICAL **: 15:19:35.442: dbus_g_proxy_call: 
assertion 'DBUS_IS_G_PROXY (proxy)' failed

** (inkscape:2024671): CRITICAL **: 15:19:35.442: 
dbus_g_connection_register_g_object: assertion 'connection != NULL' failed
end_font_face_cb: font face rule limited support.
  font-family : 'GeomTest';
  src : url(fonts/GeomTest-gzipped-SVG-glyphs.otf)
end_font_face_cb: Added font: 
/<>/testfiles/rendering_tests/fonts/GeomTest-gzipped-SVG-glyphs.otf
Background RRGGBBAA: ff00
Area 0:0:110:40 exported to 110 x 40 pixels (96 dpi)
Pixbuf::create_from_file: Unrecognized image file format
   ()
Pixbuf::create_from_file: Unrecognized image file format
   ()
Pixbuf::create_from_file: Unrecognized image file format
   ()
1589
text-gzipped-svg-glyph FAILED
text-gzipped-svg-glyph-large SKIPPED


Why is a "connection" necessary to retrieve a font file from a "url"?
And why should the "server" then "refuse" it? Is this not expecting
entirely too much from a mere package-build server?

How does D-Bus come into this mess? Surely the resources provided by the
filesystem should be all that is required for compilation and regression
testing? This is not some kind of network client, or if it somehow is,
that functionality should not be required to just build the distribution
package.

The "src: url(fonts/GeomTest-gzipped-SVG-glyphs.otf)" part actually does
come from the regression test, but otherwise that tiny file provides no
hint of what is going on.

https://sources.debian.org/src/inkscape/1.1-1/testfiles/rendering_tests/text-gzipped-svg-glyph.svg/

But again: why does a font file need to be retrieved from a "url", in
the context of a regression test?

> But no, I'm not going to ignore a test failure just because it's
> skipped in other architectures for different reasons: I'll need more
> convincing reasons.

Do we know that it's skipped in other architectures for different
reasons? Maybe it's skipped in other architectures for the same reason:
it breaks things.

Again, note that this particular test was not present in previous
versions, which is why it never caused a problem before.

Bug#994741: regression tests: skipped vs failed

[ian_bruce]

On Tue, 21 Sep 2021 18:57:41 +0300
Andrius Merkys  wrote:

> I cannot reproduce the failure myself on amd64. I tried building on a
> machine without a display, and yet the test succeeds. I will try a
> porterbox next.

If the test succeeds, is the overall build then successful? Is that the
cause of the amd64 build failure on the autobuild systems?

If so, then cannot this problem be temporarily fixed by ignoring the
test result on amd64, also? If it's acceptable to not run the test at
all on 32-bit architectures, and to ignore the result on 64-bit BE
architectures, then it cannot really be that important for 64-bit LE
architectures.

By temporarily ignoring the test result, the immediate problem can be
solved: Inkscape v1.1 is not currently available for amd64 and other
64-bit LE systems. Having temporarily disabled this test, the actual
cause of the failure can then be investigated at anybody's convenience,
without further delaying the availability of the Inkscape distribution
package.

Inkscape v1.0.2 is REALLY buggy. This needs to be fixed soon.

Bug#994741: regression tests: skipped vs failed

[ian_bruce]

On Tue, 21 Sep 2021 12:33:07 +0300
Andrius Merkys  wrote:

> if(${CMAKE_SIZEOF_VOID_P} EQUAL 8)
>  set(RENDERING_TESTS_64bit
>  # .otf font with compressed SVG glyphs
>  # (test not stable on 32bit Windows)
>  text-gzipped-svg-glyph
>  )
> endif()
> 
> Thus this test is only run on 64bit architectures.

Thanks for pointing that out.

It appears that my assumption that this regression test failure was the
cause of the overall build failure on amd64, was incorrect. According to
the build logs, this test also fails on ppc64 and sparc64, and yet the
builds for those architectures have apparently succeeded.

This appears to be the critical failure on amd64:


cd /<>/obj-x86_64-linux-gnu && /usr/bin/ctest 
--force-new-ctest-process
ninja: build stopped: subcommand failed.
dh_auto_test: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 
MESON_TESTTHREADS=1 ninja test returned exit code 1
make[1]: *** [debian/rules:21: override_dh_auto_test-arch] Error 25
make[1]: Leaving directory '/<>'
make: *** [debian/rules:8: binary-arch] Error 2
dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2


Build finished at 2021-08-21T15:19:37Z


Since the regression test failure is apparently an unrelated problem,
how should that be interpreted?

Bug#994741: regression tests: skipped vs failed

[ian_bruce]

The Inkscape v1.1 build fails on amd64, because of a regression test
called "text-gzipped-svg-glyph", which can be found here:

https://sources.debian.org/src/inkscape/1.1-1/testfiles/rendering_tests/text-gzipped-svg-glyph.svg/

from the build log:


Start 301: render_text-glyphs-vertical
301/303 Test #301: render_text-glyphs-vertical    Passed2.25 sec
Start 302: render_test-powerstroke-join
302/303 Test #302: render_test-powerstroke-join ...   Passed0.55 sec
Start 303: render_text-gzipped-svg-glyph
303/303 Test #303: render_text-gzipped-svg-glyph ..***Failed0.26 sec

text-gzipped-svg-glyph FAILED
text-gzipped-svg-glyph-large SKIPPED

99% tests passed, 1 tests failed out of 303


On i386, the build succeeds, apparently because this test does not run
at all:


Start 301: render_text-glyphs-vertical
301/302 Test #301: render_text-glyphs-vertical    Passed2.65 sec
Start 302: render_test-powerstroke-join
302/302 Test #302: render_test-powerstroke-join ...   Passed0.94 sec

100% tests passed, 0 tests failed out of 302


If this test is not required on i386 (and presumably other architectures
where the build succeeds), then it shouldn't be required on amd64, either.

This discrepancy needs to be investigated.

Bug#994741: Inkscape v1.1 build failure

[ian_bruce]

This page provides a compact overview of the Inkscape v1.1 build failure:

https://buildd.debian.org/status/package.php?p=inkscape=experimental

There is no obvious reason why one particular regression test should succeed
on some architectures, but fail on others, so it seems likely that some defect
in the arch-specific build environment is the cause of the problem.

Bug#977345: enabling vector acceleration on non- x86/amd64 hardware

[ian_bruce]

> Use hardware-accelerated XXH3 computation on x86 architecture, and
> install the hardware-accelerating header file.

note that the upstream source code also includes vectorized algorithms
for ARM NEON and POWER VSX CPUs:

XXH_VECTOR : manually select a vector instruction set (default:
auto-selected at compilation time). Available instruction sets are
XXH_SCALAR, XXH_SSE2, XXH_AVX2, XXH_AVX512, XXH_NEON and XXH_VSX.
Compiler may require additional flags to ensure proper support (for
example, gcc on linux will require -mavx2 for AVX2, and -mavx512f
for AVX512).

https://github.com/Cyan4973/xxHash#build-modifiers

https://en.wikipedia.org/wiki/ARM_architecture#Advanced_SIMD_(Neon)

https://en.wikipedia.org/wiki/AltiVec#VSX_(Vector_Scalar_Extension)

also note that there is a provision for inlining the hash functions, for
even greater speedup in the case where the input length is known at
compile time:

XXH_INLINE_ALL: Make all functions inline, with implementations
being directly included within xxhash.h. Inlining functions is
beneficial for speed on small keys. It's extremely effective when
key length is expressed as a compile time constant, with performance
improvements observed in the +200% range.

please ensure that the vectorized algorithms are enabled for both
inlining and link library, on ARM and POWER platforms, as well as on
x86/amd64.

thanks.

Bug#902606: closed by Debian FTP Masters (Bug#902606: fixed in man2html 1.6g-13)

[ian_bruce]

On Sun, 20 Dec 2020 20:21:05 +
"Debian Bug Tracking System"  wrote:

> * Add the following patches:
>   + 037-man2html-Nm-and-Bk-mdoc.patch to ensure that .Nm mdoc macro
> properly remembers command name, and .Bk ignores -word option
> (closes: #902606);

This still does not work properly. Again, from the manual page for the
dash shell, compare the first lines in the SYNOPSIS section:

text mode:

dash [-aCefnuvxIimqVEbp] [+aCefnuvxIimqVEbp] [-o option_name] [+o 
option_name] [command_file [argument ...]]

man2html:

dash -aCefnuvxIimqVEbp [+aCefnuvxIimqVEbp ] -o option_name [+o option_name 
] command_file [argument ... ]

It is immediately apparent that many brackets ("[]") have been omitted
from the HTML version. This is a new bug; the version for which the
original bug was reported did not do this, as can be seen in the
screenshot in the original report.

Not fixed.

Bug#970420: python dependencies now uninstallable

[ian_bruce]

Matthias Klose  wrote:

> no, the python package is gone.

It may be going, but it's not gone:


# apt-show-versions -a python
python:amd64 2.7.16-1 stable   ftp.us.debian.org
No stable-updates version
No testing version
python:amd64 2.7.17-2 unstable ftp.us.debian.org
No experimental version
python:amd64 not installed


What's supposed to happen to the huge list of packages that "Depend" on
a package called "python"?


# apt-cache showpkg python |
  sed -n '/^Reverse Depends/,/^Dependencies/p' |
  wc -l
2674


There doesn't seem to be anything else that satisfies this dependency,
so these have all suddenly become uninstallable:


# apt-get install gimp-plugin-registry
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 python : PreDepends: python-minimal (= 2.7.17-2) but it is not going to be 
installed
  Depends: libpython-stdlib (= 2.7.17-2) but it is not going to be 
installed
  Depends: python2 (= 2.7.17-2) but 2.7.18-2 is to be installed
E: Unable to correct problems, you have held broken packages.


This situation is doubleplus ungood; something needs to be done about it
immediately.


-- Ian Bruce

Bug#949444: bug #949444 : now affects Linux v4 kernels

[ian_bruce]

kmod : v 27-1

initramfs-tools : v 0.136


# apt-get install linux-image-4.19.0-8-amd64
...
depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open 
builtin file '/lib/modules/4.19.0-8-amd64/modules.builtin.bin'
depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open 
builtin file '/lib/modules/4.19.0-8-amd64/modules.builtin.bin'
depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open 
builtin file '/lib/modules/4.19.0-8-amd64/modules.builtin.bin'
...


> Please check:
>
> https://bugs.launchpad.net/curtin/+bug/1864992/comments/34
> https://bugs.launchpad.net/curtin/+bug/1864992/comments/35

-- bug apparently renamed; see here instead:

https://bugs.launchpad.net/ubuntu/+source/kmod/+bug/1864992/comments/34

Bug#953146: texlive-extra : bad version number

[ian_bruce]

It appears that an extra "0" has been inserted into the version number
of packages derived from the "texlive-extra" source package:

texlive-base 2019.20200302-1 
texlive-extra-utils  2019.202000302-1
texlive-font-utils   2019.202000302-1
texlive-fonts-recommended2019.20200302-1 
texlive-lang-english 2019.20200302-1 
texlive-lang-greek   2019.20200302-1 
texlive-latex-base   2019.20200302-1 
texlive-latex-extra  2019.202000302-1
texlive-latex-recommended2019.20200302-1 
texlive-luatex   2019.20200302-1 
texlive-pictures 2019.20200302-1 
texlive-plain-generic2019.202000302-1
texlive-pstricks 2019.202000302-1
texlive-publishers   2019.202000302-1
texlive-science  2019.202000302-1

https://packages.debian.org/source/bullseye/texlive-extra

> if I drop the 0 the version **decreases**. One would need to add an
> epoch 1:200... but I don't want to do this, because I am preparing
> 2020 packages now, and with the switch to 2020 I can revert the error.

What if you just re-release the same packages with a phony version
number, like "2020.20200101-1" or "2020.20200303-1"? Won't that sort
correctly?


-- Ian Bruce

Bug#949444: confirm

[ian_bruce]

confirm.

kmod: v 26+20191223-1

initramfs-tools: v 0.136


depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open 
builtin file '/lib/modules/5.4.0-3-amd64/modules.builtin.bin'
depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open 
builtin file '/lib/modules/5.4.0-3-amd64/modules.builtin.bin'
depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open 
builtin file '/lib/modules/5.4.0-3-amd64/modules.builtin.bin'

... ad infinitum, on initial install of package "linux-image-5.4.0-3-amd64".

Bug#949211: bad opencv dependency

[ian_bruce]

It seems to be the dependency on OpenCV-3.2 that is the source of the
problem. OpenCV-4.1 appears to be the current version in the "testing"
archive.

-- Ian Bruce

Bug#945824: depending on multiple interpreter versions is obviously a bug

[ian_bruce]

Package: python3-numpy
Depends:
  python3 (<< 3.9),
  python3 (>= 3.7~),
  python3.7:any,
  python3.8:any,
  python3:any,
  libblas3 | libblas.so.3,
  libc6 (>= 2.29),
  liblapack3 | liblapack.so.3,
  python3-pkg-resources

How can it possibly not be a bug that a single package depends on two
different versions of the Python interpreter? How long can this
situation persist until it qualifies as a bug? When the python3.7
package is no longer present in the standard repository, will it be a
bug then?

Either the package would work with any version of Python3 (as suggested
by "python3:any") or it actually does require a specific version (as
suggested by "python3 (>= 3.7~)" and "python3 (<< 3.9)"). It cannot
possibly be dependent on two specific versions simultaneously.

If this nonsensical dependency list was generated by some automated
tool, then that tool is broken, and ought to be fixed. Forward the bug
to that package, if appropriate, but this is clearly a bug in something,
and should be fixed immediately. It is not acceptable that two different
versions of Python3 must be simultaneously installed.

> this is likely an artifact of shipping f2py3.7 and f2py3.8 with a
> shebang referring directly to a versioned interpreter. that's always
> been the case with multiple interpreters.

-- then don't do that. Specify the interpreter as "/usr/bin/python3",
and leave it at that. There obviously aren't any differences between
them that would actually require different versions of the interpreter:

$ diff /usr/bin/f2py3.{7,8}
1,2c1,2
< #!/usr/bin/python3.7
< # EASY-INSTALL-ENTRY-SCRIPT: 'numpy==1.17.4','console_scripts','f2py3.7'
---
> #!/usr/bin/python3.8
> # EASY-INSTALL-ENTRY-SCRIPT: 'numpy==1.17.4','console_scripts','f2py3.8'
11c11
< load_entry_point('numpy==1.17.4', 'console_scripts', 'f2py3.7')()
---
> load_entry_point('numpy==1.17.4', 'console_scripts', 'f2py3.8')()

If it's a question of the interpreter itself behaving differently
depending on the specific version, then have the f2py script check the
version and complain if the one it wants is not present.

Bug#922396: webext-noscript is now one year out-of-date

[ian_bruce]

It appears that the firefox-esr package is going to be upgraded to v68,
which will not work with this badly-out-of-date version of noscript,
probably the single most important browser extension available.

The current version is 11.0.3 :

https://addons.mozilla.org/en-US/firefox/addon/noscript/versions/

Either these browser extension packages need to be updated much more
frequently, or there needs to be some automatic mechanism for installing
current versions, which does not depend on manual packaging. It seems
like a script which would fetch the current version of any named browser
extension from the Mozilla website, and install it to the standard
Debian /usr/share/webext/ directory, would not be especially hard to
write.

In any case, please upgrade this important package to the current
version, as it is now one year out-of-date, and does not work with
current versions of Firefox.

Bug#932620: example program fails to link

[ian_bruce]

An example program, found here --

https://www.cryptopp.com/wiki/BLAKE2#Sample_Programs

-- also fails to link. In contrast, the equivalent example program from
here --

https://www.cryptopp.com/wiki/MD5

-- compiles, links, and runs without any problem.

Apparently, the BLAKE2 object module is not present in the dynamic
library.


$ cat btest.cc 

#include "cryptlib.h"
#include "blake2.h"
#include 

int main (int argc, char* argv[])
{
using namespace CryptoPP;

BLAKE2b hash;   
std::cout << "Name: " << hash.AlgorithmName() << std::endl;
std::cout << "Digest size: " << hash.DigestSize() << std::endl;
std::cout << "Block size: " << hash.BlockSize() << std::endl;

return 0; 
}


$ g++ -I/usr/include/cryptopp -o btest btest.cc -lcryptopp

/usr/bin/ld: /tmp/ccfdvMC5.o: in function `CryptoPP::BLAKE2b::BLAKE2b(bool, 
unsigned int)':
btest.cc:(.text._ZN8CryptoPP7BLAKE2bC2Ebj[_ZN8CryptoPP7BLAKE2bC5Ebj]+0x25): 
undefined reference to `CryptoPP::BLAKE2_Base::BLAKE2_Base(bool, unsigned int)'
/usr/bin/ld: 
/tmp/ccfdvMC5.o:(.data.rel.ro._ZTVN8CryptoPP7BLAKE2bE[_ZTVN8CryptoPP7BLAKE2bE]+0x88):
 undefined reference to `CryptoPP::BLAKE2_Base::UncheckedSetKey(unsigned char const*, unsigned int, 
CryptoPP::NameValuePairs const&)'
/usr/bin/ld: 
/tmp/ccfdvMC5.o:(.data.rel.ro._ZTVN8CryptoPP7BLAKE2bE[_ZTVN8CryptoPP7BLAKE2bE]+0xa8):
 undefined reference to `CryptoPP::BLAKE2_Base::Update(unsigned char const*, unsigned long)'
/usr/bin/ld: 
/tmp/ccfdvMC5.o:(.data.rel.ro._ZTVN8CryptoPP7BLAKE2bE[_ZTVN8CryptoPP7BLAKE2bE]+0xb0):
 undefined reference to `CryptoPP::BLAKE2_Base::Restart()'
/usr/bin/ld: 
/tmp/ccfdvMC5.o:(.data.rel.ro._ZTVN8CryptoPP7BLAKE2bE[_ZTVN8CryptoPP7BLAKE2bE]+0xb8):
 undefined reference to `CryptoPP::BLAKE2_Base::TruncatedFinal(unsigned char*, unsigned long)'
/usr/bin/ld: 
/tmp/ccfdvMC5.o:(.data.rel.ro._ZTVN8CryptoPP7BLAKE2bE[_ZTVN8CryptoPP7BLAKE2bE]+0xf0):
 undefined reference to `non-virtual thunk to CryptoPP::BLAKE2_Base::Update(unsigned char const*, unsigned long)'
/usr/bin/ld: 
/tmp/ccfdvMC5.o:(.data.rel.ro._ZTVN8CryptoPP7BLAKE2bE[_ZTVN8CryptoPP7BLAKE2bE]+0x108):
 undefined reference to `non-virtual thunk to CryptoPP::BLAKE2_Base::Restart()'
/usr/bin/ld: 
/tmp/ccfdvMC5.o:(.data.rel.ro._ZTVN8CryptoPP7BLAKE2bE[_ZTVN8CryptoPP7BLAKE2bE]+0x148):
 undefined reference to `non-virtual thunk to CryptoPP::BLAKE2_Base::TruncatedFinal(unsigned char*, unsigned long)'
/usr/bin/ld: 
/tmp/ccfdvMC5.o:(.data.rel.ro._ZTVN8CryptoPP11BLAKE2_BaseIyLb1EEE[_ZTVN8CryptoPP11BLAKE2_BaseIyLb1EEE]+0x88):
 undefined reference to `CryptoPP::BLAKE2_Base::UncheckedSetKey(unsigned char const*, unsigned int, 
CryptoPP::NameValuePairs const&)'
/usr/bin/ld: 
/tmp/ccfdvMC5.o:(.data.rel.ro._ZTVN8CryptoPP11BLAKE2_BaseIyLb1EEE[_ZTVN8CryptoPP11BLAKE2_BaseIyLb1EEE]+0xa8):
 undefined reference to `CryptoPP::BLAKE2_Base::Update(unsigned char const*, unsigned long)'
/usr/bin/ld: 
/tmp/ccfdvMC5.o:(.data.rel.ro._ZTVN8CryptoPP11BLAKE2_BaseIyLb1EEE[_ZTVN8CryptoPP11BLAKE2_BaseIyLb1EEE]+0xb0):
 undefined reference to `CryptoPP::BLAKE2_Base::Restart()'
/usr/bin/ld: 
/tmp/ccfdvMC5.o:(.data.rel.ro._ZTVN8CryptoPP11BLAKE2_BaseIyLb1EEE[_ZTVN8CryptoPP11BLAKE2_BaseIyLb1EEE]+0xb8):
 undefined reference to `CryptoPP::BLAKE2_Base::TruncatedFinal(unsigned char*, unsigned long)'
/usr/bin/ld: 
/tmp/ccfdvMC5.o:(.data.rel.ro._ZTVN8CryptoPP11BLAKE2_BaseIyLb1EEE[_ZTVN8CryptoPP11BLAKE2_BaseIyLb1EEE]+0xf0):
 undefined reference to `non-virtual thunk to CryptoPP::BLAKE2_Base::Update(unsigned char const*, unsigned long)'
/usr/bin/ld: 
/tmp/ccfdvMC5.o:(.data.rel.ro._ZTVN8CryptoPP11BLAKE2_BaseIyLb1EEE[_ZTVN8CryptoPP11BLAKE2_BaseIyLb1EEE]+0x108):
 undefined reference to `non-virtual thunk to CryptoPP::BLAKE2_Base::Restart()'
/usr/bin/ld: 
/tmp/ccfdvMC5.o:(.data.rel.ro._ZTVN8CryptoPP11BLAKE2_BaseIyLb1EEE[_ZTVN8CryptoPP11BLAKE2_BaseIyLb1EEE]+0x148):
 undefined reference to `non-virtual thunk to CryptoPP::BLAKE2_Base::TruncatedFinal(unsigned char*, unsigned long)'
collect2: error: ld returned 1 exit status

Bug#932620: bad package Makefile

[ian_bruce]

It appears that there may be a problem with the Makefile for this
package. The "libcrypto___la_SOURCES" macro does not reference the
"blake2.cpp" source file, although it ought to.

https://sources.debian.org/src/libcrypto++/5.6.4-8/blake2.cpp/

https://sources.debian.org/src/libcrypto++/5.6.4-8/debian/autotools/Makefile.am/

This may be why the BLAKE2 module does not get included in the dynamic
library, and the linker fails to resolve the associated symbols.

Please review the list of object modules which are to be included in the
static and dynamic libraries provided by this source package.

Bug#904988: /bin/su does not set $PATH

[ian_bruce]

 wrote:

> I thought I (or something) had hosed my system, but it turns out this
> change is by design.

That was exactly my reaction. I don't think that it's acceptable to have
a major (unannounced) change in behaviour for an essential system
utility like "/bin/su".

some discussion here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833256#90

quote:

Debian would have to add "ALWAYS_SET_PATH yes" to "/etc/login.defs"
to preserve its current behavior.

current source code reference:

https://sources.debian.org/src/util-linux/2.32-0.3/login-utils/su-common.c/#L980

It seems that the previous behaviour can be restored, without source
code modifications, simply by changing a config file. That would seem to
be by far the best option.


-- Ian Bruce

Bug#888026: FreeCAD v0.17 release

[ian_bruce]

As mentioned above, FreeCAD v0.17 has been released, as of April 6th,
2018.

https://freecadweb.org/wiki/Release_notes_0.17

Also, OpenCascade v7.3.0 has been packaged for Debian.

https://packages.debian.org/source/experimental/opencascade

Hopefully, this means that the Debian FreeCAD package can soon be
updated to v0.17, the current release.

Bug#881812: xul-ext-treestyletab: nine months out-of-date

[ian_bruce]

This package is now nine months out-of-date.

When might we expect a version that actually works with current versions
of Firefox?

https://addons.mozilla.org/en-US/firefox/addon/tree-style-tab/versions/2.0

Even the firefox-esr package will soon require a newer version:

https://packages.debian.org/experimental/firefox-esr


duplicate bug:

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

Bug#883917: closed by Osamu Aoki <os...@debian.org> (Bug#883917: fixed in im-config 0.33-1)

[ian_bruce]

On Sat, 23 Dec 2017 13:39:06 +
"Debian Bug Tracking System"  wrote:

> #883917: im-config: doesn't offer UIM as an option
> 
> It has been closed by Osamu Aoki .

Now im-config offers both ibus and uim as input methods, but neither of
them actually work, even though they are both installed. That is, they
don't appear in the XFCE panel, as they used to, prior to whatever these
recent changes have been.


$ dpkg -l | grep ibus | egrep -v '(l|scr)ibus'
ii  gir1.2-ibus-1.0:amd64  1.5.14-3  amd64  Intelligent Input Bus - 
introspection data
ii  ibus   1.5.14-3  amd64  Intelligent Input Bus - 
core
ii  ibus-mozc  2.20.2673.102+dfsg-2  amd64  Mozc engine for IBus - 
Client of the Mozc input method
ii  libibus-1.0-5:amd641.5.14-3  amd64  Intelligent Input Bus - 
shared library

Bug#884097: lightdm-gtk-greeter: default panel options have disappeared

[ian_bruce]

It appears that the default panel layout has changed between
lightdm-gtk-greeter versions  and , although this is not
mentioned in the changelog. Specifically, the language selector,
session/environment selector, accessibility options, and reboot/poweroff
menu have all disappeared. The default now seems to be to display only
the hostname and clock in the panel.

Rather than using the default, the panel layout can be explicitly
controlled with the "indicators" option in the config file
. This patch approximates the
previous default configuration:


--- unpack/etc/lightdm/lightdm-gtk-greeter.conf 2017-12-09 15:38:30.0 
-0800
+++ /etc/lightdm/lightdm-gtk-greeter.conf   2017-12-21 23:27:25.998580178 
-0800
@@ -54,7 +54,7 @@
 #xft-dpi=
 #xft-hintstyle=
 #xft-rgba=
-#indicators=
+indicators=~clock;~spacer;~host;~spacer;~language;~session;~power
 #clock-format=
 #keyboard=
 #reader=


This at least restores the reboot/poweroff function. However, problems
with the other functions remain:

- both the Debian and upstream changelogs indicate that the
accessibility options have been removed, for unspecified reasons. This
being so, the comment in  offering the "~a11y"
option should also be removed, to avoid confusion.

- the language selector does not now work, and has not worked for a long
time. Apparently, this is not considered to be a problem.

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

- the session selector defaults to whatever the previous user chose,
which is clearly absurd.

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

Hopefully, these long-standing problems can be fixed, and lightdm can be
restored to the functionality it once had, but no longer does. Wasn't
the progressive removal of functionality from Gnome and GDM, the reason
why lightdm was started in the first place?


-- Ian Bruce

Bug#765077: language selection still broken, after all these years

[ian_bruce]

I don't understand why this bug is marked "unreproducible". I find it
extremely reproducible, in that language selection ABSOLUTELY NEVER
WORKS.

quoting :

> $LANG and $LANGUAGE are completely untouched by lightdm.
> ~/.dmrc is always written with correct settings on login

That is just exactly what happens. Has anybody observed anything
different?

and quoting :

> Why can such Bugs life that long? And even reappear over 2-3 versions?
> No wonder that the acceptance for Linux on desktops is so low if such
> small but annoying things reappear every 2nd dist-upgrade. How should
> a casual user get around this whole stuff?

I have often wondered this, and not just in the context of this bug.
What's the point of writing software at all, if it's never going to be
made to work properly? It's almost as if nobody actually gives a rat's
ass.

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

Bug#857631: bug #857631 : why isn't this fixed?

[ian_bruce]

Antonio Ospite  wrote:

> I saw that 4.0-5 has been uploaded without this fix,
> is this fix going to be in 4.0.1?

It appears that the answer to this question is "no":

$ clang-4.0 --version
clang version 4.0.1-+rc1-1 (tags/RELEASE_401/rc1)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

$ cat ptr-expr2.c
int ptr_expr(int *p)
{
if (!p)
return(0);
else
return(1);
}

$ clang-4.0 -x cl -emit-llvm -S ptr-expr2.c
ptr-expr2.c:3:9: error: invalid argument type 'int *' to unary expression
if (!p)
^~
1 error generated.

Can the same fix that was applied to llvm-3.9 be applied to llvm-4.0?
It is apparently a ONE-LINE PATCH. (see initial bug report for reference.)


-- Ian Bruce

Bug#857394: Debian Policy violation -- libgegl-dev contains duplicate copy of openCL library files

[ian_bruce]

On Thu, 13 Apr 2017 01:25:29 -0700
 wrote:

>> I'm not going to try a 'merge-on-the-fly' on headers to save a bunch
>> of kilobytes. Sorry.
> 
> Saving a bunch of kilobytes is really not the issue, as I suggested
> when I said "isn't that a Policy violation?".

I was right -- it IS a Debian Policy violation:

* 4.13 Convenience copies of code *

Some software packages include in their distribution convenience
copies of code from other software packages, generally so that users
compiling from source don't have to download multiple packages.
Debian packages should not make use of these convenience copies
unless the included package is explicitly intended to be used in
this way. If the included code is already in the Debian archive in
the form of a library, the Debian packaging should ensure that
binary packages reference the libraries already in Debian and the
convenience copy is not used. If the included code is not already in
Debian, it should be packaged separately as a prerequisite if
possible.

https://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles

That seems to describe this situation EXACTLY.


-- Ian Bruce

Bug#857394: libgegl-dev: contains duplicate copy of openCL library files

[ian_bruce]

On Wed, 12 Apr 2017 23:51:03 +0200
"Matteo F. Vescovi"  wrote:

>> /usr/include/gegl-0.3/opencl/gegl-cl-color.h
>> /usr/include/gegl-0.3/opencl/gegl-cl.h
>> /usr/include/gegl-0.3/opencl/gegl-cl-init.h
>> /usr/include/gegl-0.3/opencl/gegl-cl-random.h
>> /usr/include/gegl-0.3/opencl/gegl-cl-types.h  
> 
> What about these?

What about them?

I just pasted in the output of the "dpkg -L libgegl-dev" command. I
didn't claim that ALL the header files in that directory were duplicates
of those in the  package. Those are the only ones that
aren't.
 
> They're not provided by the Debian package and I'm not going to try a
> 'merge-on-the-fly' on headers to save a bunch of kilobytes. Sorry.

Saving a bunch of kilobytes is really not the issue, as I suggested when
I said "isn't that a Policy violation?". Here's a relevant quote:

* No inclusion of third party code *

Please do not include other code (like libraries) or data that are
also shipped separately inside your source archive, or if you do,
please make sure they can be reliably ignored. Instead of shipping
third party libraries you should rather make sure your program will
be link nicely against recent versions of these libraries. If a
security issue is found in one of the bundled packages, it is far
easier for the package maintainers or the Security Team to patch and
rebuild one package than to scan the entire archive for all copies
of this code and patch them individually (this happened for zlib,
for example). It's also preferable for the end users to receive an
update for just one package (e.g. OpenSSL) rather than a large
number of applications.

https://wiki.debian.org/UpstreamGuide#No_inclusion_of_third_party_code

>> The included version of openCL seems to be many years out of date:
>>
>>
>> $ diff -u /usr/include/{gegl-0.3/opencl,CL}/opencl.h
>> --- /usr/include/gegl-0.3/opencl/opencl.h2016-06-26 05:02:45.0 
>> -0700
>> +++ /usr/include/CL/opencl.h 2016-06-14 08:44:21.0 -0700
>> @@ -1,5 +1,5 @@
>>  
>> /***
>> - * Copyright (c) 2008-2010 The Khronos Group Inc.
>> + * Copyright (c) 2008-2015 The Khronos Group Inc.  
> 
> Impressed. ;)

Here's another relevant quote:

If your software depends on other libraries, then Debian also needs
to make sure that your software compiles and works with the version
of these libraries available in Debian. Debian may compile your
software against a different version of some library than you do.
Therefore it's not of any help for Debian if you include convenience
copies of these dependencies in your source tarball.

https://wiki.debian.org/UpstreamGuide#Source_only_tarball

>> It appears that there may also be another independent library, under
>> the /usr/include/gegl-0.3/npd/ directory.
> 
> I asked upstream about this and I got no consistent reply. So it'll
> keep its position.

This seems to be a sub-project of GEGL:

https://github.com/GNOME/gegl/tree/master/libs/npd

If it's not packaged independently, then the considerations above may
not apply.

However, they most certainly do apply to openCL.


-- Ian Bruce

Bug#848258: Blender: libclc version needs to be updated

[ian_bruce]

It turns out that the "implicit declaration of function
{lgamma,native_tan} is invalid in C99" compiler warning results from
using an insufficiently up-to-date version of libclc, and would turn
into a linker error, if other problems did not prevent the compilation
from progressing that far. See here for details:

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

I have filed a bug report against the Debian Blender package, to
aggregate this bug and the two referenced above, which seem to be what
is currently preventing GPU rendering from working in Blender. There are
now solutions available for all three, which can and should be applied
to the Debian archive; see the individual bug reports for details.

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


-- Ian Bruce

Bug#848258: two known issues; patches are available

[ian_bruce]

It turns out that the "invalid argument type 'X *' to unary expression"
compiler error is the result of a known bug in LLVM. See here for
details:

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

The "unsupported call to function get_local_size" compiler error is the
result of a known bug in Mesa. See here for details:

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

Patches are available upstream for both of those problems, as I have
explained in the above two bug reports.


-- Ian Bruce

Bug#848258: openCL / Blender problems: solutions now available

[ian_bruce]

the openCL component of this problem is addressed here:

https://bugs.freedesktop.org/show_bug.cgi?id=99856#c24

related Debian bug report:

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

the unrelated Blender bugs are being discussed here:

https://developer.blender.org/T50522

Hopefully, the solutions now available can be quickly applied.


-- Ian Bruce

Bug#848258: openCL errors: patch available upstream

[ian_bruce]

On Fri, 10 Mar 2017 10:47:37 +0900
Michel Dänzer  wrote:

>> https://bugs.freedesktop.org/show_bug.cgi?id=99856#c24
> 
> That's a different issue from the one this bug report is about. It
> would have to be reported against the libclc-amdgcn package.

That's a bug report (now with patch) filed against Mesa, entitled
"unsupported call to function get_local_size", which is one of the
things that the Debian bug submitter was complaining about, when he
filed this bug against the Debian Mesa package. The recommended solution
from the Mesa maintainers, which I quoted, is that distributions apply
the patch locally.

It turns out that this is the ONLY Mesa problem that the Debian bug
submitter was complaining about -- all the other problems are Blender
bugs, found in the upstream Blender build that he was using, and
therefore not Debian-specific:

error: invalid argument type 'ShaderClosure *' (aka 'struct ShaderClosure 
*') to unary expression

error: invalid argument type 'MicrofacetExtra *' (aka 'struct 
MicrofacetExtra *') to unary expression

I have attached a patch to solve these Blender openCL errors. Perhaps
the bug submitter could confirm that it fixes these openCL compile
errors, and if so, submit a bug report to Blender, upstream. Of course,
I would prefer to be given credit for the patch.


-- Ian Bruce
--- blender/scripts/addons/cycles/kernel/closure/alloc.h.orig	2016-10-25 02:55:07.0 -0700
+++ blender/scripts/addons/cycles/kernel/closure/alloc.h	2017-03-10 00:59:12.191241611 -0800
@@ -62,7 +62,7 @@
 {
 	ShaderClosure *sc = closure_alloc(sd, size, CLOSURE_NONE_ID, weight);
 
-	if(!sc)
+	if(sc == 0)
 		return NULL;
 
 	float sample_weight = fabsf(average(weight));
--- blender/scripts/addons/cycles/kernel/closure/bsdf_microfacet.h.orig	2016-10-25 05:09:56.0 -0700
+++ blender/scripts/addons/cycles/kernel/closure/bsdf_microfacet.h	2017-03-10 00:58:32.140963906 -0800
@@ -266,7 +266,7 @@
 	   (bsdf_a->alpha_y == bsdf_b->alpha_y) &&
 	   (isequal_float3(bsdf_a->T, bsdf_b->T)) &&
 	   (bsdf_a->ior == bsdf_b->ior) &&
-	   ((!bsdf_a->extra && !bsdf_b->extra) ||
+	   ((bsdf_a->extra == 0 && bsdf_b->extra == 0) ||
 ((bsdf_a->extra && bsdf_b->extra) &&
 	 (isequal_float3(bsdf_a->extra->color, bsdf_b->extra->color;
 }

Bug#848258: openCL errors: patch available upstream

[ian_bruce]

 wrote:

> You should get in touch with Mesa upstream developers about these
> issues. Your Debian bug reports are mostly creating additional
> overhead for the Debian package maintainers, for little gain towards
> your goal of using Blender with OpenCL.

quote from Mesa upstream bug report:

>> the patch fixes the problem and hello world works here. Should I
>> report the bug in llvm bug tracker?
>
> I'm not sure if that'd help. There is no release_39 stable branch for
> libclc. Even if there was, afaik there is no plan for another 3.9
> release. distros will probably have to apply that patch individually.
   ^^^

https://bugs.freedesktop.org/show_bug.cgi?id=99856#c24


On my system also, up-to-date Debian/testing, with different GPU (AMD
TAHITI) from the bug submitter, even running the "clinfo" utility
program, from the Debian package of the same name, is sufficient to
trigger this "unsupported call to function get_local_size" bug.


-- Ian Bruce

Bug#855871: non-metadata RAID arrays are limited to 27 component devices

[ian_bruce]

It appears that the 27-component-device limit is specific to
non-metadata arrays ("mdadm --build"). More research:

When the RAID assembly fails --


# mdadm --build /dev/md/md-test --level=linear --raid-devices=28 
/dev/loop{0..27}
mdadm: ADD_NEW_DISK failed for /dev/loop27: Device or resource busy


-- this shows up in the kernel log:


kernel: [126679.205703] md: nonpersistent superblock ...
kernel: [126679.205718] md: md125: array is limited to 27 devices
kernel: [126679.205722] md: export_rdev(loop27)
kernel: [126679.221644] md: md125 stopped.


The problem seems to be some kind of kernel limit. A Google search finds
this book:

https://books.google.ca/books?id=EbWbAgAAQBAJ=PT75=PT75

quote: "MD_SB_DISKS indicates that each software array is limited to 27
member disks."

This appears to be a constant relating to the MD-RAID v0.90 superblock
format:

http://lxr.free-electrons.com/ident?i=MD_SB_DISKS

some discussion:

* The version-0.90 Superblock Format *

Though it used to be the default format of raid superblock during
array creation on most distributions until 2009, the older
version-0.90 superblock format has several limitations that limit
its applicability for use on large arrays or arrays with many
component devices.

The version-0.90 superblock limits the number of component devices
within an array to 28, and limits each component device to a maximum
size of 2TB on kernel version <3.1 and 4TB on kernel version >=3.1.

...

* The version-1 Superblock Format *

The newer and well-supported version-1 superblock format is
more-expansion friendly than the previous format. It is the default
as of v3.1.1. More specifically, --metadata=1.2 is used as of
v3.1.2.

The version-1 superblock is capable of supporting arrays with 384+
component devices, and supports arrays with 64-bit sector lengths.

https://raid.wiki.kernel.org/index.php/RAID_superblock_formats

When the RAID assembly succeeds --


# mdadm --build /dev/md/md-test --level=linear --raid-devices=27 
/dev/loop{0..26}
mdadm: array /dev/md/md-test built and started.
# 
# mdadm --detail /dev/md/md-test
/dev/md/md-test:
Version : 
  Creation Time : Thu Feb 23 02:50:20 2017
 Raid Level : linear
 Array Size : 1769472 (1728.00 MiB 1811.94 MB)
   Raid Devices : 27
  Total Devices : 27

  State : clean 
 Active Devices : 27
Working Devices : 27
 Failed Devices : 0
  Spare Devices : 0

   Rounding : 64K

Number   Major   Minor   RaidDevice State
   0   700  active sync   /dev/loop0
   1   711  active sync   /dev/loop1
   2   722  active sync   /dev/loop2
   3   733  active sync   /dev/loop3
   ...


-- notice that "Version:", the superblock type, is left unspecified.

This was a non-metadata array ("mdadm --build"). An internal-metadata
array ("mdadm --create") allows the use of more than 27 component block
devices, with a v1.2 superblock:


# mdadm --create /dev/md/md-test --level=linear --raid-devices=32 
/dev/loop{0..31}
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md/md-test started.
# 
# mdadm --detail /dev/md/md-test
/dev/md/md-test:
Version : 1.2
  Creation Time : Thu Feb 23 03:12:21 2017
 Raid Level : linear
 Array Size : 2094592 (2045.50 MiB 2144.86 MB)
   Raid Devices : 32
  Total Devices : 32
Persistence : Superblock is persistent

Update Time : Thu Feb 23 03:12:21 2017
  State : clean 
 Active Devices : 32
Working Devices : 32
 Failed Devices : 0
  Spare Devices : 0

   Rounding : 0K

   Name : quadlie:md-test  (local to host quadlie)
   UUID : 79a9278b:125af417:91b0c7ab:75267ede
 Events : 0

Number   Major   Minor   RaidDevice State
   0   700  active sync   /dev/loop0
   1   711  active sync   /dev/loop1
   2   722  active sync   /dev/loop2
   3   733  active sync   /dev/loop3
   ...


mdadm refuses to attempt creating the same array with a v0.90
superblock:


# mdadm --create /dev/md/md-test --level=linear --metadata=0 --raid-devices=32 
/dev/loop{0..31}
mdadm: 0.90 metadata supports at most 27 devices per array


This error message is, however, a lot more informative than
"/dev/loop27: Device or resource busy", the initial one with a
non-metadata array.

mdadm won't allow the v1.2 superblock type with a non-metadata array:


# mdadm --build /dev/md/md-test --level=linear --metadata=1 --raid-devices=32 
/dev/loop{0..31}
mdadm: :option --metadata not valid in build mode


-- so apparently, we're out of luck; it can't be done.

We may infer that when assembling a non-metadata array ("mdadm
--build"), the in-kernel superblock defaults to the v0.90 type, which
imposes the 27-component-device limit. Unfortunately, 

Bug#846382: display artifacts in Blender

[ian_bruce]

I confirm this bug. It's extremely easy to reproduce; simply moving the
mouse pointer across any of the controls is sufficient to trigger
flickering and display corruption. This program is currently unusable.

I, too, have Mesa v13 installed. Whatever the cause of the problem is,
it's of very recent origin. However, it has been the case for a long
time that using the "Toggle Window Fullscreen" option from the "Window"
menu (as opposed to the window manager "maximize" button) causes similar
problems.

Bug#694879: Blender + OpenCOLLADA FTBFS

[ian_bruce]

On Thu, 4 Aug 2016 04:08:30 -0700
 wrote:

> If removing the illegal UTF-8 and Windows-1252 characters doesn't fix
> the problem, then try this:
> 
> 
> --- opencollada/COLLADAFramework/COLLADAFWPrerequisites.h.orig
> 2014-07-03 09:30:54.0 -0700
> +++ opencollada/COLLADAFramework/COLLADAFWPrerequisites.h 2016-08-04 
> 03:42:44.765860036 -0700
> @@ -11,6 +11,7 @@
>  #ifndef __COLLADAFW_PREREQUISITES_H__
>  #define __COLLADAFW_PREREQUISITES_H__
>  
> +#include 
>  #include 
>  
>  namespace COLLADAFW

Apparently, I was right:


--- 
opencollada_0.1.0~20140703.ddf8f47+dfsg1/COLLADAFramework/include/COLLADAFWInstanceBindingBase.h
2014-07-03 09:30:54.0 -0700
+++ 
opencollada_0.1.0~20160714.0ec5063+dfsg1/COLLADAFramework/include/COLLADAFWInstanceBindingBase.h
2016-07-13 12:25:45.0 -0700
@@ -15,6 +15,11 @@
 #include "COLLADAFWInstanceBase.h"
 #include "COLLADAFWMaterialBinding.h"
 
+#include "COLLADABUURI.h"
+
+#include 
+
+
 namespace COLLADAFW
 {
 

Bug#694879: Blender + OpenCOLLADA FTBFS

[ian_bruce]

If removing the illegal UTF-8 and Windows-1252 characters doesn't fix
the problem, then try this:


--- opencollada/COLLADAFramework/COLLADAFWPrerequisites.h.orig  2014-07-03 
09:30:54.0 -0700
+++ opencollada/COLLADAFramework/COLLADAFWPrerequisites.h   2016-08-04 
03:42:44.765860036 -0700
@@ -11,6 +11,7 @@
 #ifndef __COLLADAFW_PREREQUISITES_H__
 #define __COLLADAFW_PREREQUISITES_H__
 
+#include 
 #include 
 
 namespace COLLADAFW

Bug#694879: Blender still missing Collada support, one year after opencollada was packaged

[ian_bruce]

On Tue, 2 Aug 2016 14:49:26 +0200
"Matteo F. Vescovi"  wrote:

>> Is there any remaining reason why the Blender package should not be
>> linked against it? Blender is supposed to have built-in support for
>> Collada.

> Simple, it fails:

I didn't know that; it hasn't previously been mentioned in this bug
report.

> In file included from
> 
> /usr/include/opencollada/COLLADAFramework/COLLADAFWInstanceGeometry.h:15:0,
>  from
> /usr/include/opencollada/COLLADAFramework/COLLADAFWNode.h:17,
>  from
> 
> /<>/blender-2.77.a+dfsg0/source/blender/collada/ArmatureImporter.h:30,
>  from
> 
> /<>/blender-2.77.a+dfsg0/source/blender/collada/ArmatureImporter.cpp:43:
> 
> /usr/include/opencollada/COLLADAFramework/COLLADAFWInstanceBindingBase.h:53:14:
> error: 'vector' in namespace 'std' does not name a template type
>  std::vector  () { return mSkeletons; }
>   ^
> 
> /usr/include/opencollada/COLLADAFramework/COLLADAFWInstanceBindingBase.h:65:14:
> error: 'vector' in namespace 'std' does not name a template type
>  std::vector  mSkeletons;
>   ^

That's very odd.

How is it that the official binaries from the Blender website are built
with Collada support? What's different about their build environment?
Has anybody asked them?

> Feel free to help debugging. Patches are really welcome.

One potential problem is that many of the OpenCOLLADA header files are
filled with a weird mixture of UTF-8 and Windows-1252 characters,
neither of which are actually legal in C/C++ source code, except maybe
as quoted strings. In particular, in a UTF-8 environment, the
Windows-1252 characters can be interpreted as the beginning of a
multibyte sequence, which screws up the following text. It's unlikely
that that's the entire cause of the problem, but let's try getting rid
of them:


# export LANG=C   # THIS IS IMPORTANT!!!
# 
# dpkg -s opencollada-dev | egrep "Package|Status|Version"
Package: opencollada-dev
Status: install ok installed
Version: 0.1.0~20140703.ddf8f47+dfsg1-3
# 
# pwd
/usr/include/opencollada
# 
# BADCHARS=$(echo {8,9,a,b,c,d,e,f}{0,1,2,3,4,5,6,7,8,9,a,b,c,d,e,f})
# PATTERN=$(for n in $BADCHARS ; do echo -ne "\x${n}" ; [ $n = ff ] || echo -n 
"|" ; done)
# BADFILES=$(egrep -l "$PATTERN" $(find . -name '*.h'))
# 
# for n in $BADCHARS ; do c=$(echo -ne "\x${n}") ; grep -q "${c}" $BADFILES && 
echo "character: \\x${n}" ; done
character: \x92
character: \x93
character: \x94
character: \x95
character: \x97
character: \xbd
character: \xbf
character: \xe9
character: \xef
# 
# grep -a -C3 --color=always $'\x95' $BADFILES | less -R
# 
# echo $'s/(\xef\xbf\xbd|\*|")?Curve Interpolation("|\*|\xef\xbf\xbd)?/*Curve 
Interpolation*/g' >~/sedscript
# echo $'s/plus (\xef\xbf)?\xbd/plus 
half/g\ns/\xef\xbf\xbds/\'s/g\ns/\xef\xbf\xbd /- /g' >>~/sedscript
# echo 
$'s/\x92/\'/g\ns/\x93/"/g\ns/\x94/"/g\ns/\x95/-/g\ns/\x97/-/g\ns/\xe9/e/g' 
>>~/sedscript
# 
# BADFILES=$(egrep -l "${PATTERN}|Curve Interpolation" $(find . -name '*.h'))
# 
# sed -r -i.badchar -f ~/sedscript $BADFILES
# 
# for n in $BADCHARS ; do c=$(echo -ne "\x${n}") ; grep -q "${c}" $BADFILES && 
echo "character: \\x${n}" ; done
# 
# cd ..
#
# find opencollada/ -name '*.badchar' | wc
 32  322061
# 
# (for f in $(find opencollada/ -name '*.badchar') ; do diff -u ${f} 
${f%.badchar} ; done) >~/opencollada-headers-badchars.diff
# 


See attached patchfile. That should also be sent upstream, wherever that
is.

Let me know if that helps. Otherwise, there must be some way of finding
out what that template instantiation error is.


-- Ian Bruce
--- opencollada/COLLADAStreamWriter/COLLADASWInputList.h.badchar	2014-07-03 09:30:54.0 -0700
+++ opencollada/COLLADAStreamWriter/COLLADASWInputList.h	2016-08-03 23:34:59.984290928 -0700
@@ -35,20 +35,20 @@
 			BINORMAL=0, /** Geometric binormal (bitangent) vector */
 			BINDMATRIX, 
 			COLOR, /** Color coordinate vector. Color inputs are RGB (float3) */
-			CONTINUITY, /** Continuity constraint at the control vertex (CV). See also "Curve Interpolation" in Chapter 4: Programming Guide. */
+			CONTINUITY, /** Continuity constraint at the control vertex (CV). See also *Curve Interpolation* in Chapter 4: Programming Guide. */
 			IMAGE, /** Raster or MIP-level input. */
-			INPUT, /** Sampler input. See also "Curve Interpolation" in Chapter 4: Programming Guide. */
-			IN_TANGENT, /** Tangent vector for preceding control point. See also "Curve Interpolation" in Chapter 4: Programming Guide. */
-			INTERPOLATION, /** Sampler interpolation type. See also "Curve Interpolation" in Chapter 4: Programming Guide. */
+			INPUT, /** Sampler input. See also *Curve Interpolation* in Chapter 4: Programming Guide. */
+			IN_TANGENT, /** Tangent vector for preceding control point. See also *Curve Interpolation* in Chapter 4: Programming Guide. */
+			INTERPOLATION, /** 

Bug#694879: Blender still missing Collada support, one year after opencollada was packaged

[ian_bruce]

It has now been over a year since the opencollada-dev package became
available in the Debian archive.

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

https://packages.debian.org/stretch/opencollada-dev

Is there any remaining reason why the Blender package should not be
linked against it? Blender is supposed to have built-in support for
Collada.

https://wiki.blender.org/index.php/Doc%3A2.6/Manual/Data_System/Files/Import/COLLADA

Is it not expected that anybody will actually want to use this software?
If so, why was the effort made to package either OpenCOLLADA or Blender?

Bug#827104: [Pkg-xfce-devel] Bug#827104: Recommends: obsolete package xfce4-volumed

[ian_bruce]

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


On Sun, 12 Jun 2016 17:30:19 +0200
Yves-Alexis Perez  wrote:

 Please remove this false dependency.
>>> 
>>> It's not a false dependency, it's just that the package has been
>>> removed and the dependency line not updated.
>> 
>> If a dependency on a currently non-existent package is "not false",
>> then I wonder what meaning you think the word has.
>> 
>> Again, do you think this situation is perfectly proper and correct?
>> Do you propose that it should persist indefinitely? Was it incorrect
>> to file a bug report describing it? After all, what's the purpose of
>> filing ANY bug reports; the final collapse of the universe will
>> eventually happen anyway, rendering the whole point moot, as you say.
>
> I honestly don't know what you're talking about, and I frankly don't
> care. This will be fixed in the next package upload anyway.

I'm confused. Does the Debian Project actually WANT people to file bug
reports? If not, why bother having a public bug-tracker, where the
standard reply is, "That's not a bug, you're just too stupid to
understand the perfection that we've created."

Conversely, if bug reports ARE wanted, then why is it considered
appropriate to reply in such a condescending and insulting way, to the
people who file them?

Do you want bug reports, or not? Would anybody care to argue that this
current case is NOT a bug? Should I infer that in the future, you would
prefer that I f*** off, and mind my own business?


-- Ian Bruce

Bug#827104: [Pkg-xfce-devel] Bug#827104: Recommends: obsolete package xfce4-volumed

[ian_bruce]

On Sun, 12 Jun 2016 12:45:23 +0200
Yves-Alexis Perez  wrote:

>> xfce4-volumed doesn't seem to exist in Xfce 4.12, but the
>> xfce4-settings package still recommends it.
> 
> Indeed.

This situation is perfectly proper and correct, in your opinion?

>> This is especially bad, because xfce4-volumed then pulls in the
>> entire gstreamer0.10 set of packages, which are otherwise totally
>> unnecessary and obsolete.
> 
> I don't parse that actually. Either it pulls in volumed and then
> pulling gstreamer0.10 is fine, or it doesn't and the point is moot.

xfce4-settings does pull in xfce4-volumed, which does pull in
gstreamer0.10, whereas gstreamer1.0 is the current version.

Therefore 26MB of totally useless packages are installed, because of
what you claim is not a false dependency.


# apt-get remove libgstreamer0.10-0
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following packages were automatically installed and are no longer 
required:
  libcdaudio1 libkeybinder0 libslv2-9
Use 'apt autoremove' to remove them.
The following packages will be REMOVED:
  gstreamer0.10-alsa* gstreamer0.10-chromaprint* gstreamer0.10-gconf*
  gstreamer0.10-gnomevfs* gstreamer0.10-nice* gstreamer0.10-plugins-bad*
  gstreamer0.10-plugins-base* gstreamer0.10-plugins-good* 
gstreamer0.10-pulseaudio*
  gstreamer0.10-x* libgstreamer-plugins-bad0.10-0* 
libgstreamer-plugins-base0.10-0*
  libgstreamer0.10-0*
0 upgraded, 0 newly installed, 13 to remove and 17 not upgraded.
After this operation, 26.1 MB disk space will be freed.
Do you want to continue? [Y/n] 


Whether or not this situation is "fine", is a matter of opinion. Of
course, the world could end tomorrow, and then this bug report, along
with all others, would be totally unnecessary.

>> Please remove this false dependency.
> 
> It's not a false dependency, it's just that the package has been
> removed and the dependency line not updated.

If a dependency on a currently non-existent package is "not false", then
I wonder what meaning you think the word has.

Again, do you think this situation is perfectly proper and correct? Do
you propose that it should persist indefinitely? Was it incorrect to
file a bug report describing it? After all, what's the purpose of filing
ANY bug reports; the final collapse of the universe will eventually
happen anyway, rendering the whole point moot, as you say.


-- Ian Bruce

Bug#780754: README.html screenshot

[ian_bruce]

 See attached screenshot.

Bug#779544: phppgadmin: apache config needs mod_dir enabled

[ian_bruce]

On Mon, 02 Mar 2015 11:24:18 +
Jean-Michel Nirgal Vourgère jmv_...@nirgal.com wrote:

 Do you know how you came to have that module disabled? Do you remember
 if you disabled it as an admin?

I can't imagine why I would have done so.

 Can you check for apache related package you installed that would
 disable that mod_dir or at least post the list of apache/php related
 packages you are using?

# deborphan apache2
apache2
  libapache2-mod-php5
  phppgadmin
  phppgadmin
  analog
  analog
  info2www
  info2www
  javascript-common
  javascript-common
  man2html
  man2html

(I don't know why deborphan sometimes repeats items.)

As for php, phppgadmin is the only thing that needs it.

 Can you give us an history of that server? I mean: Was it installed as
 a Wheezy (Debian 7) then upgraded?

That is almost certainly what happened, which would mean that the
installation started off as Apache-2.2, and was then upgraded to
Apache-2.4 .

Just now, I tried purging all the Apache packages, and then reinstalling
them. mod_dir is now enabled by default, so the problem has not
reappeared. Apart from the above, I don't know how it could have arisen.

HOWEVER: phppgadmin still doesn't work. The README.Debian file advises
that The application is available at http://localhost/phppgadmin/ after
installation. This is not so. From the access log:

::1 - - [02/Mar/2015:05:00:57 -0800] GET /phppgadmin/ HTTP/1.1 404 501 -

Oddly, the Apache configuration file goes into
/etc/apache2/conf.d/phppgadmin, instead of
/etc/apache2/conf-{available,enabled}, like everything else. It does say
Alias /phppgadmin /usr/share/phppgadmin, but a2enconf doesn't know
about it. Is that how it's supposed to be? If so, why doesn't it work?


-- Ian Bruce


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

Bug#763412: libjpeg-dev reinstalls over itself

[ian_bruce]

Package: libjpeg-dev
Version: 1:1.3.1-3

Surely there is something wrong with this.

This can be repeated indefinitely; there's something wrong with the
version checking.

It would be nice if somebody would fix reportbug, so we could use that
again.

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


# apt-get install libjpeg-dev
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following packages will be upgraded:
  libjpeg-dev
1 upgraded, 0 newly installed, 0 to remove and 876 not upgraded.
Need to get 0 B/48.3 kB of archives.
After this operation, 0 B of additional disk space will be used.
Reading changelogs... Done
(Reading database ... 233968 files and directories currently installed.)
Preparing to unpack .../libjpeg-dev_1%3a1.3.1-3_all.deb ...
Unpacking libjpeg-dev (1:1.3.1-3) over (1:1.3.1-3) ...


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

Bug#660163: three versions, and three and a half years, out of date

[ian_bruce]

PoDoFo 0.9.3 has been released.

http://podofo.sourceforge.net/download.html

Version 0.9.0 is the latest available in the Debian archive.
This is now three versions, and three and a half years, out of date.

Please upgrade to the current release.


-- Ian Bruce


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

Bug#725107: this bug was previously reported, and wrongly closed

[ian_bruce]

This is the same problem I previously reported under bug #715314 :

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=715314#35

That bug should not have been closed, because the fix is worse than
the problem it was supposed to cure; the program is now much less useful
than the previous version in the archive. It now reports no version
information at all for packages which are not installed, which is
commonly when you might want to know this.

# apt-show-versions -a gdb   # version 0.20
Not installed
gdb 7.4.1+dfsg-0.1 stable   ftp.us.debian.org
No stable-updates version
gdb 7.6.2-1.1+b1   testing  ftp.us.debian.org
gdb 7.6.2-1.1+b1   unstable ftp.us.debian.org
gdb not installed
# 

# apt-show-versions -a gdb   # version 0.22.3
gdb not installed (available for: amd64)
# 

I suggest that the relevant code sections should be reverted to version
0.20, if no better fix can be found. As is, this package is close to
useless.

This bug is currently rated as Severity: important. Surely something
should be done about it, as soon as possible?


-- Ian Bruce


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

Bug#724931: Please include the patch in git

[ian_bruce]

I'm not done with this yet. I'm working on a more general patch with new
features, which will be forthcoming shortly. I would ask that nothing
major be done until that is ready.

The current version is certainly ready for testing, although Andreas
already seems to have done so extensively.


On Sat, 12 Oct 2013 20:03:53 +0200
Andreas Cadhalpun andreas.cadhal...@googlemail.com wrote:

 The patch created by Ian Bruce and myself adds ISO loopback support
 for the Debian installer using a new boot parameter, to be used as
 follows:
 
 loopmount=[DEVICE:]ISO

loopback is the name of a virtual network device; the proper term in
this context is in fact loopmount, hence the name of the boot
parameter.

 Here ISO specifies the path to the ISO, i.e.
 /ISO/debian-7.1.0-amd64-CD-1.iso.

Relative to the root directory of some block device, of course.

 DEVICE is for the name or UUID of the device, on which the ISO is
 located. Giving this is optional and if it is not given, all devices
 are searched for the ISO.

It specifies the filesystem label or UUID, as found in
/dev/disk/by-label/ or /dev/disk/by-uuid/, or returned by /sbin/blkid.

At least in my version of the patch, if it is not specified, then
partitions and CD/DVD drives are searched, but not other devices.

 If the boot parameter is not given (or no ISO could be found),
 everything works essentially as before.

As far as I know, if the loopmount parameter is not specified, then
everything works EXACTLY as before (by design).

 For the patch to work, the loop-module is needed in the initrd, so I
 suggest to make it a dependency of cdrom-detect. I furthermore highly
 recommend to make the ext2/ext3/ext4, ntfs and udf modules
 dependencies of cdrom-detect, since these are the most common
 filesystems and thus being able to loopmount from them would be good.

It appears that the ext4 module would be sufficient to also mount
ext2/ext3, whereas the reverse would not be true.

https://ext4.wiki.kernel.org/index.php/Frequently_Asked_Questions#What_is_the_difference_between_ext2.2C_ext3.2C_and_ext4.3F

https://ext4.wiki.kernel.org/index.php/Frequently_Asked_Questions#Can_I_mount_existing_Ext3_as_Ext4.3F_And_vice_versa.3F_Similarly_from_Ext2_to_Ext4_and_its_reverse.3F

https://ext4.wiki.kernel.org/index.php/Ext4_Howto#Compatibility

There might be some value in including NTFS, so that you could
loop-mount from Windoze partitions.

I don't know what usage UDF gets (besides DVDs) that would justify
including it in the initrd.

 (Fat is somewhat outdated.)

VFAT is by no means outdated, since it is used on almost every USB
flashdrive in existence. You might expect that it would eventually be
replaced for this purpose by F2FS, but that certainly hasn't happened
yet.

Anyway, it's already in the initrd.

 The patch makes it possible to boot using USB-HDD from any filesystems
 with drivers in the initrd.

Actually, from any supported block device with a supported filesystem.
It appears that most standard PATA/SATA/SCSI/CDROM/USB drivers are
already included in the initrd, so the only thing that would need to be
added is loop.ko and a few filesystem drivers.

 The patch also cleans up the somewhat messy workaround for bug
 #608201.

A proper fix would be for all ISO images to be treated the same,
regardless of whether they were contained in a CD, a disk partition, or
a loop-mounted file. I'm not sure why this shouldn't be possible, but
it's not the issue we're mainly concerned with at the moment.

 For ease of use, I propose to add a loopback.cfg similar to the the
 attached one to the ISO in the folder /boot/grub/. This would allow to
 easily mount the ISO using grub2.

I can supply similar config files for Syslinux, allowing the use of the
original boot menus with a loop-mounted ISO.

 I tested loopmounting with the following ISOs. (They were modified
 with the attached Apply_Patches.sh.)

   * debian-7.1.0-amd64-netinst.iso
   * debian-7.1.0-i386-netinst.iso
   * debian-7.1.0-amd64-CD-1.iso
   * debian-7.1.0-amd64-CD-2.iso (+)
   * debian-7.1.0-amd64-CD-3.iso (+)
   * debian-7.1.0-amd64-DVD-1.iso
   * debian-7.1.0-amd64-DVD-2.iso (+)

 (+): Not modified, just copied to the folder of the first ISO in the
 set.

As I have suggested previously, you don't actually have to modify the
ISOs for testing; you can just patch an external copy of the initrd and
boot with that. That way, the official MD5 and SHA256 hashes still
verify.

 This worked without problems. To make sure all other boot mechanisms
 still work, I tested them for the patched debian-7.1.0-amd64-CD-1.iso:

   * Isohybrid: OK
   * USB-HDD: OK

Thanks for testing all that.

 * CD: I can't open the CD drive with the button the on the drive. I
 have to change to another TTY and use 'eject'. (This problem exists
 also with the original ISO image, see #726137.)

I think I also ran into this at some point.

 Since the patch works well and does no harm, I ask you to include it
 in git.

I think this will be a highly 

Bug#724931: PATCH: improved(2) ISO loopmount option

[ian_bruce]

(I see that Andreas has recently posted a set of patches. The patches I
have attached below are not based on that work, although they address
some of the same problems. At the end of this message, are some comments
about how our alternative solutions might be combined.)


On Fri, 4 Oct 2013 06:02:46 -0700
ian_br...@fastmail.net wrote:

 Andreas Cadhalpun andreas.cadhal...@googlemail.com wrote:
 
 Sadly it only seems to work well, but in fact, your previous (and I
 assume also this) patch break apt-setup trying to add the CD to
 /etc/sources.list. I am currently working on this problem and hope to
 finish this soon.
 
 I'm sorry to hear that. I'll look into it as well; the error log you
 included in your previous message seemed to indicate that assumptions
 were being made about what block device represented the ISO, or where
 it was mounted. Since the cdrom-detect script already figures this
 out, this information just needs to be exported (via a file?) to other
 scripts.

I think the problem is related to this bug:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=608201

I have therefore adopted the (partial?) solution which was applied in
that case, which is that ISO images which are found somewhere other than
an actual CD, do not get included in sources.list. Which seems kind of
unfortunate; the same USB flashdrive could be used again, or an actual
CD might show up later, but that's how they resolved it, and it's not
what we're mainly concerned with right now. If a better solution is
developed sometime later for those situations, it should apply to the
loopmount case as well.

So for now, the solution is to export the fact of the loopmount to the
configuration database, where it can later be checked by the apt-setup
package, and handled the same way as the other non-CD cases.

Two patchfiles are attached: a slightly altered one for cdrom-detect,
and a new one for apt-setup. I haven't actually tested the latter,
because I'm working with the netinst ISO, which doesn't seem to
include that package.

Here are the relevant sections of the installer logs:


loopmount=KINGSTON:/linux/debian-7.1.0-amd64-i386-netinst.iso

Oct  6 07:35:06 cdrom-detect: Searching for Debian installation media...
Oct  6 07:35:06 cdrom-detect: removable devices: (/dev/sr0)
Oct  6 07:35:06 cdrom-detect: LOOPDEV='KINGSTON' 
LOOPFILE='/linux/debian-7.1.0-amd64-i386-netinst.iso'
Oct  6 07:35:06 cdrom-detect: trying loop-mount on 
(/dev/disk/by-label/KINGSTON)...
Oct  6 07:35:06 kernel: [  322.483186] FAT-fs (sdf1): utf8 is not a recommended 
IO charset for FAT filesystems, filesystem will be case sensitive!
Oct  6 07:35:06 kernel: [  322.495521] loop: module loaded
Oct  6 07:35:06 kernel: [  322.571304] ISO 9660 Extensions: Microsoft Joliet 
Level 3
Oct  6 07:35:06 cdrom-detect: CD-ROM loop-mount succeeded: 
device=/dev/disk/by-label/KINGSTON/linux/debian-7.1.0-amd64-i386-netinst.iso 
fstype=iso9660
Oct  6 07:35:06 kernel: [  322.578804] ISO 9660 Extensions: RRIP_1991A
Oct  6 07:35:06 cdrom-detect: Detected CD 'Debian GNU/Linux 7.1.0 Wheezy - 
Official Multi-architecture amd64/i386 NETINST #1 20130615-23:44'
Oct  6 07:35:06 cdrom-detect: Detected CD with 'stable' (wheezy) distribution


loopmount=/linux/debian-7.1.0-amd64-i386-netinst.iso

Oct  6 08:01:19 cdrom-detect: Searching for Debian installation media...
Oct  6 08:01:19 cdrom-detect: removable devices: (/dev/sr0)
Oct  6 08:01:19 cdrom-detect: LOOPDEV='' 
LOOPFILE='/linux/debian-7.1.0-amd64-i386-netinst.iso'
Oct  6 08:01:19 cdrom-detect: trying loop-mount on (/dev/sda1 /dev/sda10 
/dev/sda2 /dev/sda3 /dev/sda4 /dev/sda5 /dev/sda6 /dev/sda7 /dev/sda8 /dev/sda9 
/dev/sdb1 /dev/sdb10 /dev/sdb2 /dev/sdb3 /dev/sdb4 /dev/sdb5 /dev/sdb6 
/dev/sdb7 /dev/sdb8 /dev/sd
Oct  6 08:01:19 kernel: [  211.616937] FAT-fs (sda1): utf8 is not a recommended 
IO charset for FAT filesystems, filesystem will be case sensitive!
Oct  6 08:01:19 kernel: [  211.664572] FAT-fs (sda10): utf8 is not a 
recommended IO charset for FAT filesystems, filesystem will be case sensitive!
Oct  6 08:01:19 kernel: [  211.740574] FAT-fs (sda2): utf8 is not a recommended 
IO charset for FAT filesystems, filesystem will be case sensitive!
Oct  6 08:01:19 kernel: [  211.804567] FAT-fs (sda3): utf8 is not a recommended 
IO charset for FAT filesystems, filesystem will be case sensitive!

...

Oct  6 08:01:22 kernel: [  214.316771] FAT-fs (sdf1): utf8 is not a recommended 
IO charset for FAT filesystems, filesystem will be case sensitive!
Oct  6 08:01:22 kernel: [  214.329130] loop: module loaded
Oct  6 08:01:22 kernel: [  214.399019] ISO 9660 Extensions: Microsoft Joliet 
Level 3
Oct  6 08:01:22 cdrom-detect: CD-ROM loop-mount succeeded: 
device=/dev/sdf1/linux/debian-7.1.0-amd64-i386-netinst.iso fstype=iso9660
Oct  6 08:01:22 kernel: [  214.406518] ISO 9660 Extensions: RRIP_1991A
Oct  6 08:01:22 cdrom-detect: Detected CD 'Debian GNU/Linux 7.1.0 Wheezy - 
Official Multi-architecture amd64/i386 NETINST #1 

Bug#724931: PATCH: improved ISO loopmount option

[ian_bruce]

This is an improved version of the patch I originally posted to this bug
report. It applies mainly to the cdrom-detect udeb, although I suggest
that the ISO volume label (such as Debian 7.1.0 M-A 1) be included
somewhere in the initrd; currently it does not appear to be. As I said
previously, a dependency on loop-modules will have to be added, so
that the loop.ko kernel module gets copied into the initrd.

This patch adds support for a boot parameter, loopmount=, which
specifies an ISO image file to be loaded from another filesystem, and
used to boot from. For example:

loopmount=KINGSTON:/linux/debian-7.1.0-amd64-i386-netinst.iso

This directs the initrd to look for a block device filesystem with the
label KINGSTON (as reported by /sbin/blkid), and to use the file
debian-7.1.0-amd64-i386-netinst.iso, in the subdirectory /linux (the
leading / is not actually necessary) as a boot image.

In addition to the filesystem labels found in /dev/disk/by-label/, the
block device can be identified by UUID, as found in /dev/disk/by-uuid/.

If the filesystem label/UUID (and :) is not specified, then all
available partitions and CD devices will be searched for the specified
ISO image file, in the specified directory.

If the loopmount parameter is not used, then the initrd will search
for a direct ISO filesystem in the same way as previously, although any
block device with the expected volume label (Debian 7.1.0 M-A 1) will
be tried first.

It is expected that this facility will be most useful with USB
flashdrives, although it is in no way limited to those. It can be
applied to any block device with a vfat, ext{2,3,4}, or iso9660
filesystem; others could easily be added.

Testing seems to show that the patch works well; the relevant portion of
the installation log is reproduced below.


Oct  4 06:02:19 cdrom-detect: Searching for Debian installation media...
Oct  4 06:02:19 cdrom-detect: Devices: '/dev/sr0'
Oct  4 06:02:19 cdrom-detect: LOOPDEV='KINGSTON' 
LOOPFILE='/linux/debian-7.1.0-amd64-i386-netinst.iso'
Oct  4 06:02:19 cdrom-detect: trying loopmount on 
(/dev/disk/by-label/KINGSTON)...
Oct  4 06:02:19 kernel: [  226.383202] FAT-fs (sdf1): utf8 is not a recommended 
IO charset for FAT filesystems, filesystem will be case sensitive!
Oct  4 06:02:19 kernel: [  226.395607] loop: module loaded
Oct  4 06:02:19 cdrom-detect: CD-ROM mount succeeded: 
device=/loop/linux/debian-7.1.0-amd64-i386-netinst.iso fstype=iso9660
Oct  4 06:02:19 kernel: [  226.474076] ISO 9660 Extensions: Microsoft Joliet 
Level 3
Oct  4 06:02:19 kernel: [  226.474149] ISO 9660 Extensions: RRIP_1991A
Oct  4 06:02:19 cdrom-detect: Detected CD 'Debian GNU/Linux 7.1.0 Wheezy - 
Official Multi-architecture amd64/i386 NETINST #1 20130615-23:44'
Oct  4 06:02:19 cdrom-detect: Detected CD with 'stable' (wheezy) distribution


This patch will increase the size of the (uncompressed) initrd by about
37KB: 36KB for the required loop.ko module, and 1KB of extra boot
script. In a 200MB or 300MB ISO image, this is surely immaterial.

Since the patch adds a previously unavailable feature, which will not
operate unless activated by an explicit boot parameter, there seems to
be no reason why it should not be applied. Compare it with the current
procedure for installing Debian from a USB flashdrive:

http://www.debian.org/releases/stable/amd64/ch04s03.html

As an administrative note, I recommend that this bug report be retitled;
the current title no longer reflects what we are discussing, and the
availability of my patch is surely now the most important issue relating
to it.


-- Ian Bruce
--- debian-7.1.0-amd64.orig/var/lib/dpkg/info/cdrom-detect.postinst	2013-09-10 17:45:08.305375296 -0700
+++ debian-7.1.0-amd64/var/lib/dpkg/info/cdrom-detect.postinst	2013-10-03 21:46:39.392315543 -0700
@@ -1,4 +1,8 @@
-#! /bin/sh
+#!/bin/sh
+
+# this should go in /etc/lsb-release or somewhere
+
+DISTRIB_LABEL=Debian 7.1.0 M-A 1
 
 set -e
 . /usr/share/debconf/confmodule
@@ -14,12 +18,21 @@
 	exit 1
 }
 
+list_devices_by_id()
+{
+	local dir disk=$(echo $1 | sed 's/ /\\x20/g')
+	for dir in /dev/disk/by-label /dev/disk/by-uuid ; do
+		[ -e ${dir}/${disk} ]  echo ${dir}/${disk} || true
+	done
+}
+
 try_mount() {
 	local device=$1
 	local type=$2
+	local options=$3
 
 	local ret=1
-	if mount -t $type -o $OPTIONS $device /cdrom; then
+	if mount -t $type -o $options $device /cdrom; then
 		log CD-ROM mount succeeded: device=$device fstype=$type
 		if [ -e /cdrom/.disk/info ]; then
 			CDNAME=$(cat /cdrom/.disk/info)
@@ -68,6 +81,7 @@
 		CDFS=iso9660
 		FATFS=vfat
 		OPTIONS=ro,exec
+		LOOPFS=vfat,ext4,iso9660
 		;;
 	hurd)
 		CDFS=iso9660fs
@@ -95,12 +109,26 @@
 
 mkdir /cdrom 2/dev/null || true
 
+for arg in $(cat /proc/cmdline); do
+	case $arg in
+	loopmount=*)
+		LOOPMOUNT=${arg#loopmount=}
+		LOOPFILE=${LOOPMOUNT#*:}
+		[ $LOOPFILE != $LOOPMOUNT ]  LOOPDEV=${LOOPMOUNT%:*}
+		;;
+	esac
+done
+
+if [ $LOOPMOUNT ]; then
+	mkdir /loop 2/dev/null || true
+fi
+
 # Need to wait for the 

Bug#724931: PATCH: improved ISO loopmount option

[ian_bruce]

On Fri, 04 Oct 2013 12:45:24 +0200
Andreas Cadhalpun andreas.cadhal...@googlemail.com wrote:

 Sadly it only seems to work well, but in fact, your previous (and I
 assume also this) patch break apt-setup trying to add the CD to
 /etc/sources.list. I am currently working on this problem and hope to
 finish this soon.

I'm sorry to hear that. I'll look into it as well; the error log you
included in your previous message seemed to indicate that assumptions
were being made about what block device represented the ISO, or where it
was mounted. Since the cdrom-detect script already figures this out,
this information just needs to be exported (via a file?) to other
scripts.

 Furthermore, for consistency I suggest to rename the boot option to
 'findiso=', since the live image already uses this option. They use a
 implementation fairly similar to your first patch

The effect of my second patch is that the ISO no longer has to be
found; we can specify EXACTLY where (what filesystem, what pathname)
it is located, and so that parameter name is now even more
inappropriate, and that implementation quite incompatible with mine.

 and I am sure, that they would gladly add any additional features
 implemented in the debian-installer.

I'm not at all sure about that. I've previously found them to be quite
unwilling to make obviously beneficial changes, without being able to
provide any rational reason for that refusal.

http://lists.debian.org/debian-live/2013/08/threads.html#00054
http://lists.debian.org/debian-live/2013/09/threads.html#0

And notice that so far, loopmount ISN'T implemented in the Debian
installer; this discussion doesn't yet involve anybody except you and
me.

 The iso-scan package on the other hand seems not be in use currently.

It turns out that it is, but only in the hd-media images, not the
standard ISOs.

http://lists.debian.org/debian-boot/2013/09/msg00097.html

Which as you and I have both pointed out, is actually kind of dumb.

 (I really don't care for the name, but it should be the same for all
 Debian ISOs. It's bad enough, that this is inconsistent between
 distributions!)

I agree on both counts, but as I said above, there's not much point in
making the names consistent, if the behavior isn't.

For example, the iso-scan package in Ubuntu allows you to specify, via a
boot parameter, the pathname for the image file, whereas the Debian
version apparently doesn't, even if it is included in the initrd. So it
would actually be better if the names WERE different, so as not to
delude people into thinking that the features are the same.

On another issue, I have some advice about your ISO-patching script. (I
don't patch ISOs, but only initrds, because I prefer that the official
MD5 and SHA256 hashes can still be verified.) You said it had to be
executed with root privileges, presumably so that file ownership and
device files come out right. You should investigate the fakeroot
utility, which obviates the need for this.

And is it possible to rename the bug report to something more
descriptive?


-- Ian Bruce


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

Bug#724931: loop-mounted ISO images

[ian_bruce]

On Mon, 30 Sep 2013 13:10:01 +0200
Andreas Cadhalpun andreas.cadhal...@googlemail.com wrote:

 j...@kitenet.net wrote:

 iso-scan is part of the Debian installer.

 However, it is only included in the hd-media initrd. There is no
 reason to include it on the regular CD initrd, because isohybrid
 allows mounting the USB stick directly.
 
 How can isohybrid replace the findiso option? At least for me it makes
 a huge difference, whether I can use my 32 GB stick for ONE
 netinst.iso or ONE HUNDRED.

I said the same thing, in my post to the mailing list:

This is unnecessarily destructive, and makes it hard to install
multiple distributions on the same flashdrive, or to use it for
other purposes. The smallest flashdrive you can currently buy is
8GB; it makes no sense that you would have to have a different one
for every live ISO you might want to use.

 Aside from that it is an unnecessary complexity to download the
 hd-media initrd, which is why I never did that, but instead only
 downloaded the loop.ko.

Even if you did download the hd-media initrd, it still wouldn't allow
you to use a boot parameter to specify the pathname of the ISO image
file you want to use. It appears that it just grabs anything it can find
that looks like a Debian ISO, and asks the user to confirm it.

Note that loop.ko is included on the ISO (but not the initrd), in the
form of /pool/main/l/linux/loop-modules-*.udeb packages.

 By the way, I think that it is reason enough to include findiso on the
 regular CD, when several persons request it. One always has to balance
 gain and cost and the only cost that I can see, is that the ISO will
 be larger. I don't know how big findiso is, but probably less then 100
 kB. The loop.ko file is 37 kB, so together this gives 137 kB. Since
 the netinst.iso is about 270 MB, it would grow by about 0.05 %. Who
 will be hurt by that?

My patch, which seems to do everything that's necessary, is a few
hundred BYTES (uncompressed). So including that and the loop.ko module
in the initrd will increase the size of the ISO image by about one part
in ten thousand, which certainly doesn't seem worth worrying about.

 On the other hand according to many post etc. on the subject, which I
 read in the course of the last two years or so, I imagine that a lot
 of people would like it. I certainly would have installed Debian
 earlier, if this option had been included on the netinst.iso.

As you point out next, it appears that this functionality is included on
the Debian live CD. What possible rationale could there be for having it
there, but not on the installer image?

I actually didn't think to investigate the live CD. It never occurred to
me that one might have it, and the other not.

 ian_br...@fastmail.net wrote:

 As for the iso-scan package, if you search the source code for the
 string findiso, you will not find it.
 
 I don't know about the hd-media initrd, but there is a debian live ISO
 at: http://live.debian.net/

 There the option 'findiso=$iso' works as advertised

The hd-media initrd is no different from the ones on the standard
installer ISO, in this regard:

$ zcat debian-7.1.0-amd64-i386-netinst/install.{386,amd}/{,gtk/}initrd.gz |
  strings | grep -i findiso
$ 

$ zcat debian-7.1.0-amd64-hd-media/{,gtk/}initrd.gz |
  strings | grep -i findiso
$ 

My loopmount= patch is again attached to this message, for the sake of
the bug report.


-- Ian Bruce
--- debian-7.1.0-amd64.orig/var/lib/dpkg/info/cdrom-detect.postinst	2013-09-10 17:45:08.305375296 -0700
+++ debian-7.1.0-amd64/var/lib/dpkg/info/cdrom-detect.postinst	2013-09-28 00:14:38.058505180 -0700
@@ -17,9 +17,10 @@
 try_mount() {
 	local device=$1
 	local type=$2
+	local options=$3
 
 	local ret=1
-	if mount -t $type -o $OPTIONS $device /cdrom; then
+	if mount -t $type -o $options $device /cdrom; then
 		log CD-ROM mount succeeded: device=$device fstype=$type
 		if [ -e /cdrom/.disk/info ]; then
 			CDNAME=$(cat /cdrom/.disk/info)
@@ -68,6 +69,7 @@
 		CDFS=iso9660
 		FATFS=vfat
 		OPTIONS=ro,exec
+		LOOPFS=vfat,ext4,iso9660
 		;;
 	hurd)
 		CDFS=iso9660fs
@@ -95,6 +97,19 @@
 
 mkdir /cdrom 2/dev/null || true
 
+for arg in $(cat /proc/cmdline); do
+	case $arg in
+	loopmount=*)
+		LOOPMOUNT=${arg#loopmount=}
+		LOOPMOUNT=${LOOPMOUNT#/}
+		;;
+	esac
+done
+
+if [ $LOOPMOUNT ]; then
+	mkdir /loop 2/dev/null || true
+fi
+
 # Need to wait for the usb device scan to complete
 if [ $OS = linux ]; then
   for count in 1 2 3 4 5 6 8 9 10; do
@@ -109,26 +124,45 @@
 fi
 
 while true; do
-	WRONG=
+	WRONG=''
 
-	devices=$(list-devices cd; list-devices maybe-usb-floppy)
-	for device in $devices; do
-		if try_mount $device $CDFS; then
-			break 2
-		fi
-	done
-	
-	devices=$(list-devices usb-partition)
-	for device in $devices; do
-		if try_mount $device $CDFS; then
-			db_set cdrom-detect/hybrid true
-			break 2
-		fi
-		if try_mount $device $FATFS; then
-			db_set cdrom-detect/usb-hdd true
-			break 2
-		fi
-	

Bug#724931: Patch works great

[ian_bruce]

On Mon, 30 Sep 2013 21:54:15 +0200
Andreas Cadhalpun andreas.cadhal...@googlemail.com wrote:

 I have applied your patch to the debian-testing-amd64-netinst.iso and
 also included the loop.ko. This increased the size from 230.7 MB to
 232.3 MB, i.e. by 0.7 %.

This must be because of differences in compression, or something else in
the build method. The combined size of the patch code and the loop.ko
module is about 37KB (uncompressed), not 1.6MB. In other words, it's
completely negligible.

 The patch itself is very straightforward, short, and most importantly
 works very well. Thank you!

I'm glad you found it satisfactory.

 The only missing thing is 'LOOPFS=' for kfreebsd and hurd.

Yes, I pointed that out in my original post to the mailing list. I will
forward that to the bug report, for completeness.

 Therefore I would suggest to forget about the findiso option and
 simply apply this patch to all the Debian isos.

I certainly have no objection to that, although I think it would be a
good thing if the install ISOs and the live ISOs both used the same
loopmount mechanism.

 (For comptability one could rename 'loopmount=' into 'findiso='.)

It might be better not to do that, in case there are any slight
differences in function, which is to say, incompatibilities.

I think that loopmount is more descriptive of what is happening than
findiso, anyway.


-- Ian Bruce


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

Bug#724931: Fw: PATCH: specify pathname for ISO loop-mount

[ian_bruce]

This message describes the motivation for the
debian-iso-loopmount.diff patch, which is reproduced above.
It was originally posted here:

http://lists.debian.org/debian-boot/2013/09/msg00509.html


Begin forwarded message:

Date: Sat, 28 Sep 2013 03:08:48 -0700
From: ian_br...@fastmail.net
To: debian-b...@lists.debian.org
Subject: PATCH: specify pathname for ISO loop-mount


This patch introduces a boot parameter, loopmount=, which allows the
specification of a full pathname (relative to the root directory of some
block device) of an ISO image file which should be loop-mounted as the
Debian installer root filesystem.

The main purpose of this feature is to facilitate the creation of USB
flashdrives which can contain multiple Linux live distributions,
selectable at boot time via a Syslinux menu.

http://sourceforge.net/projects/multibootusb/

The current method of creating a Debian installer flashdrive overwrites
the existing partition table and filesystem:

*Warning*

The procedures described in this section will destroy anything
already on the device!

http://www.debian.org/releases/stable/amd64/ch04s03.html.en

This is unnecessarily destructive, and makes it hard to install multiple
distributions on the same flashdrive, or to use it for other purposes.
The smallest flashdrive you can currently buy is 8GB; it makes no sense
that you would have to have a different one for every live ISO you might
want to use.

The effect of this patch is that you can just copy the Debian installer
ISO into the existing filesystem on the flashdrive, and boot it with
GRUB or Syslinux, using the loopmount= boot parameter to specify the
ISO pathname.

It will be apparent from reading the patch that if this parameter is not
specified, everything functions EXACTLY as before; the new code will not
be run. The changes amount to no more than forty lines of new code, in
one file.

I suppose that this patch applies to the cdrom-detect udeb, although I
just patched the initrd directly. A dependency on loop-modules will
need to be added, to make sure that the loop.ko kernel module gets
copied into the initrd.

One issue that probably should be addressed is what to do if the
specified ISO is not actually present; the boot process should fail
gracefully, but I'm not sure how best to accomplish that.

Minor changes (see the LOOPFS variable) would be needed to make it
work for FreeBSD and Hurd; I've only tried it with Linux.

Comments are welcome, but apart from the above, I don't think there's
much wrong with this patch; testing shows that it seems to work
perfectly.


-- Ian Bruce


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

Bug#715314: apt-show-versions now completely nonfunctional

[ian_bruce]

On Wed, 11 Sep 2013 13:14:24 +0200
Christoph Martin mar...@uni-mainz.de wrote:

 apt-show-versions now knows absolutely nothing about any package that
 isn't already installed:
 
 # apt-show-versions -a mplayer
 mplayer not installed (available for: amd64)  
 
 This is weird. You did not say on what release your maschine is, but I
 think it could be on unstable/testing.

It's a recent 7.1 installation, which has been partially upgraded to
testing.

 On a Wheezy system it is working for uninstalled packages but not for
 some packages which have a binary release like mplayer =
 2:1.0~rc4.dfsg1+svn34540-1+b2 or nano = 2.2.6-1+b1.

apt-show-versions v0.20 :

# apt-show-versions -a gdb
Not installed
gdb 7.4.1+dfsg-0.1 stable   ftp.us.debian.org
No stable-updates version
gdb 7.6-5  testing  ftp.us.debian.org
gdb 7.6-5  unstable ftp.us.debian.org
gdb not installed

apt-show-versions v0.22.2 :

# apt-show-versions -a gdb
gdb not installed (available for: amd64)

No changes between these two tests other than apt-show-versions itself.

 On a Sid system it is not working for all uninstalled packages.

some other relevant package versions:

# dpkg -l | egrep '( |lib)apt( |-)'
ii  apt  0.9.9.4   amd64
ii  apt-listchanges  2.85.11   all  
ii  apt-show-versions0.22.2all  
ii  apt-utils0.9.9.4   amd64
ii  libapt-inst1.5:amd64 0.9.9.4   amd64
ii  libapt-pkg-perl  0.1.29+b1 amd64
ii  libapt-pkg4.12:amd64 0.9.9.4   amd64
ii  python-apt   0.8.8.2   amd64
ii  python-apt-common0.8.8.2   all  

# dpkg -l | egrep '(ii  |lib)perl'
ii  libperl4-corelibs-perl   0.003-1   all  
ii  libperl5.18  5.18.1-3  amd64
ii  perl 5.18.1-3  amd64
ii  perl-base5.18.1-3  amd64
ii  perl-modules 5.18.1-3  all  

 Thanks for the hint, we will try to find a fix.

If there's any other relevant information I can provide, let me know.


-- Ian Bruce


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

Bug#721360: blockdev-wipe can be very slow

[ian_bruce]

b...@decadent.org.uk wrote:

 I have to wonder why this is so slow.  We should be able to write
 about 100 MB/s sequentially to a recent HD, so 750 GB would take
 about 2 hours and not 36 hours.

I chose an encrypted swap volume, of size 16GB.

The Debian installer took close to an hour to wipe this. This result
is comparable to the speed reported upthread, five or six megabytes
per second, a truly absurd speed when the underlying disk is capable
of at least twenty times that.

 Is encryption really that expensive, and if so can we fix this by
 adding accelerated crypto drivers to d-i (such as aesni_intel)?

It should be clear that if all you want to do is wipe some disk
volume, by writing either zeros or random data to it, YOU DON'T HAVE
TO ENCRYPT THAT DATA, even if that volume will later be used for
encrypted data. It is of no use whatsoever to encrypt the wipe data.

In other words: wipe the underlying real volume, preferably with zeros
so as not to waste time computing /dev/urandom; don't wipe the
dm-crypt volume layered on top of it.

It could also be asked why it is any more relevant to wipe the
previous contents of a new encrypted volume than an unencrypted
one. Even if the physical disk previously contained sensitive data,
there is no reason to suppose that such data is exclusively contained
within the boundaries of a newly-created encrypted volume which uses
it.

There should be a (non-default) option to wipe the entire contents of
specific physical disks, with either zeros or pseudorandom
data. Whether the new usage of those disks will be encrypted or not,
is a completely irrelevant consideration.


-- Ian Bruce


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

Bug#715314: apt-show-versions now completely nonfunctional

[ian_bruce]

apt-show-versions now knows absolutely nothing about any package that
isn't already installed:

# apt-show-versions -a mplayer
mplayer not installed (available for: amd64)

It doesn't even know its own version, which is not very encouraging:

# apt-show-versions -h
Apt-Show-Versions v.0.16 (c) Christoph Martin

Usage:
 apt-show-versions shows available versions of installed packages.

...

(The actual package version is 0.22.2 .)

I don't see how this qualifies as a bug fix. It used to work
regardless of whether or not the package was installed, because it's
supposed to get its information from the package lists, not dpkg.

version 0.20 :

# apt-show-versions -a mplayer
Not installed
mplayer 2:1.0~rc4.dfsg1+svn34540-1+b2 stable   ftp.us.debian.org
No stable-updates version
No testing version
mplayer 2:1.0~rc4.dfsg1+svn34540-1+b2 unstable ftp.us.debian.org
mplayer not installed

So this is actually a regression; the previous bug, whatever it was,
did not render the program totally useless, as it now is.


-- Ian Bruce


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

Bug#660163: two years and four months out of date

[ian_bruce]

Now two years and four months out of date.

I must point out that this is a dependency of scribus, surely an
important package, which does seem to get updated, so it's not
irrelevant.

If there have been no major changes in the last two releases, then it
should be easy to package. If there HAVE been major changes, then all
the more reason it should be updated.


-- Ian Bruce


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

Bug#684128: down the memory hole

[ian_bruce]

It seems that Historical Revisionism, of the bad kind, is now in
operation at Debian, in that critical commentary about unapplied patches
is made to disappear down the memory hole, without leaving so much as a
trace on the relevant bug report.

If it were thought that the criticism was unfair, or inaccurate, then it
could be allowed to remain in place, so that other people might judge
its lack of merit for themselves.

In the case of bug #684128, post #108, however, the fact that the
offending message was promptly vaporized* (as will be this one also), of
course suggests that the opposite is true.

It seems to me that this kind of thing sets a bad precedent for the
future, but I'm just a bug reporter, of the worst kind, those that
actually fix the problem that they're complaining about.

So what do I know?



* after an automatic acknowledgement had been sent:

Subject: Bug#684128: Info received (When I use a word, Humpty Dumpty said...)
Message-ID: handler.684128.b684128.136491666013227.acki...@bugs.debian.org
References: 20130402083114.6bba69b4.ian_br...@fastmail.net


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

Bug#684128: so long, and thanks for all the fish

[ian_bruce]

On Thu, 04 Apr 2013 12:45:55 -0300
Ben Armstrong sy...@debian.org wrote:

 Just take care in future that the style of communications you used
 triggered someone's wetware spam filter with a false positive.

I initially wrote up a detailed bug report, and then when somebody
suggested that the problem would get fixed faster if a patch were
provided, I wrote that too. Somebody else pointed out that the patch
contained a bashism, which couldn't be used in the installer, so I fixed
that within a day. It was then objected that the patch might break
something, so I wrote a set of test scripts to show that it produced
exactly the same results as the existing code if operated in decimal
mode, and offered to write tests for binary mode, if anybody could
suggest what would constitute acceptable correctness proofs.

I then waited for eight months for any indication that the slightest
notice would be taken of any of this.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684128

Seeing none, and concluding that a technical style of communications
had failed, it occurred to me to resort to allegory, and a literary
reference which I thought would be both familiar and directly relevant.

http://lists.debian.org/debian-boot/2013/04/msg00020.html

When THAT disappeared into a black hole, another literary reference came
to mind (1984, if anyone cares).

http://lists.debian.org/debian-devel/2013/04/msg00176.html

Apparently some conclusions are so obvious that they may never be
mentioned.

 Learn and move on.

Yes, indeed. What I've learned is that technical arguments, and patches
offered in support of them, will be either completely ignored,
apparently forever, or actually ridiculed as being incredibly picky
and splitting hairs.

Previous experience with the Debian BTS suggests that if I presume to
offer ANY technical comment at all, I may be subjected to personal
insults and told to keep my mouth shut.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=495049

Attempts to reason by way of analogy to different but parallel
situations, while quoting directly from previous argument, will be
assumed to be spam, and vaporized at the click of a mouse button.

So you win. There is apparently no mode of argument, or style of
communications, which is capable of penetrating the Debian
bureaucracy. It is impervious, even to patches which have been
previously solicited. Silly me, for taking that seriously.

As for moving on, I think I will, to some other project where they don't
think that lying to absolutely everybody who installs it, about the size
of their disk partitions, by as much as seven or ten percent, is a
matter of complete indifference, to be dismissed in favour of More
Important Things.

And in case you hadn't noticed, the subject line of this message is yet
a THIRD literary reference. I guess you're well rid of me and my spam.

Goodbye.


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

Bug#684128: failure to communicate

[ian_bruce]

On Thu, 4 Apr 2013 19:09:04 +0200
Christian PERRIER bubu...@debian.org wrote:

 This mail is a very good argument to confirm that overcomplicated
 methods to make your point will just fail.
 
 If you have a point to make it, make ti. Once. With facts.

I supplied plenty of facts.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684128#5

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684128#12

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684128#36

I even supplied patches, after I was invited to do so.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684128#66

The first was justly criticised on the grounds that it contained a
bashism. I immediately corrected it.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684128#88

It was stated that the time was not appropriate to introduce
user-visible changes in the installer. I pointed out that my patch did
not require any such thing, and that if it had been acceptable for the
installer to operate for many years, and many Debian releases, without
mentioning that it was using a definition of megabytes and gigabytes
contrary to what technically knowledgeable people would expect, it could
just as well operate in conformance with their expectations, and not
mention that either.

The only other objection raised was the danger of introducing
regressions. I supplied test scripts which demonstrated that my code
produced results which were byte-for-byte identical to the existing code
when operating in decimal mode, and offered to write tests for binary
mode if anybody could suggest what would be accepted as proof of
correctness.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684128#103

I was polite to everyone involved in the discussion, and answered every
question put to me.

Then I waited to see if anything would happen, or any further comment
would be made. For eight months.

 You will never convince anyone with a mail like yours.

If Debian bug report #684128 proves anything, it is that you will never
convince anyone with technical argument, facts advanced in support of
it, patches which completely solve the problem, test scripts which prove
non-regression of those patches, and answering every single question or
objection advanced regarding any of this.

All of that will be completely ignored, without further comment.

If you then attempt, as a last resort, to reason by way of analogy, this
message will be categorized as spam and disappear into thin air.

Perhaps there's some new and improved way of convincing people that I'm
just unaware of. If so, tutorial references would be appreciated.

 Sorry, but this is only about failure to communicate.

Well, that's certainly clear.

As I said, I've tried everything I can think of.

I'm out.


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

Bug#684128: so long, and thanks for all the fish

[ian_bruce]

On Thu, 04 Apr 2013 16:45:26 -0300
Ben Armstrong sy...@debian.org wrote:

 the long and sordid tale of your bid to get attention for this bug

That's right; I wrote it up in detail, provided patches when asked to do
so, provided test scripts to demonstrate the correctness of those
patches, answered every question and objection raised about it.

And then waited patiently to see if any notice would be taken of it. In
silence. For eight months.

Hearing nothing, I concluded that my previous mode of argument was not
persuasive, and decided to try something else. That disappeared into
thin air. I wondered whether anybody thought that was a problem, and
asked. So here we are.

What could possibly be longer and more sordid than that?


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

Bug#684128: When I use a word, Humpty Dumpty said...

[ian_bruce]

When I use a word, Humpty Dumpty said in rather a scornful tone, it
means just what I choose it to mean -- neither more nor less.

The question is, said Alice, whether you can make words mean so many
different things.

The question is, said Humpty Dumpty, which is to be master -- that's
all.

*

A long time ago, in a galaxy far, far, away...

A man walked into a bank, and wrote out a withdrawal slip for $1073.74
on an account that he had there. He handed it to a teller, who said:

Thank you, sir, I'll get that for you immediately.

The teller went to the bank's cash dispenser to get the money. When he
came back, he handed the man ten $100 bills. Seeing this, the man said:

I'm sorry, that's not what I asked for, if you look at the withdrawal
slip I gave you.

Well, it's close enough, don't you think?

Look, I was quite specific, I asked for $1073.74, not just something
within eight percent of it.

Only incredibly picky people really care about differences of that
sort.

Just about everybody understands the importance of such a difference.

I think you probably have a strange definition of 'just about
everybody'. In reality, I think that just about nobody cares about
$1073.74 versus $1000.00. This is basically splitting hairs, which we
don't have time for.

Why can't you just do what I asked you to?

Actually, our cash machine can't accommodate transactions like that,
because the people who designed it were in a rush and didn't bother with
exact calculations; it justs sticks a few zeros on the end of every
number you give it.

Aren't exact calculations kind of the whole point of having computers?

Look, I already told you, you're being incredibly picky, and just
splitting hairs, and we don't have time for it.

In that case, I'd like to change my withdrawal to $1100, because $1000
is less than what I actually need.

Well, then, you should have thought of that in the first place. We've
already processed your request for approximately $1000, and we can't
undo it now. You'll just have to close out your account and start all
over again.

A few days later, the man returned to the same bank, carrying a package.
He handed it to the teller he had spoken to previously.

I understand why you made me open a whole new account, just so I could
get as much money as I asked for. It's because your equipment is
defective. Look, just to show that there's no hard feelings, I brought
you a new cash machine, which actually does what it's told to. You can
have it, so none of your customers will be subjected to this absurd
inconvenience in the future.

That's very kind of you, sir, but how do we know that this machine is
actually reliable? What if it implements some kludge even more
ridiculous than trying to do arithmetic by appending '000' to a string,
like the last one did? We've had it for YEARS AND YEARS, and nobody ever
bothered to do anything about it until you did. You see, our programmers
really don't give a rat's ass about seven or eight percent differences
like that. They have Important Things To Do.

I thought of that too. Look, here's a comprehensive test report,
showing that my machine produces exactly the same results as your
current one for every transaction which that one is actually capable of.
But my machine, unlike yours, actually does what the customer asks of
it, rather than making some dumb approximation for the convenience of
programmers who were less than Incredibly Picky. Of course there's no
way to test those results against the current machine, but if you can
think of any correctness test which would satisfy you, I'll be happy to
carry it out.

Again, that's very kind of you, sir. We'll be happy to accept your
machine, and give it due consideration and study.

Eight months later, the man returned to the bank once again, just to see
if anything had changed. It hadn't. The new cash machine was sitting on
a shelf, gathering dust. It did not seem that anybody had even looked at
it in all that time. Maybe the bank would someday remember it, if they
ever felt the need to give their customers what they actually asked for.
Or maybe they wouldn't.

After all, the bank had Important Things To Do.

*

Of course, nothing like this could ever happen in the Real World(TM).

Because if it did, such an institution would be laughed out of
existence. For example, if anybody were so careless about the size of
computer filesystems, they would be subjected to scorn and derision, as
when the author of resize2fs(8) says:

Note: when kilobytes is used above, I mean real, power-of-2
kilobytes, (i.e., 1024 bytes), which some politically correct folks
insist should be the stupid-sounding kibibytes. The same holds
true for megabytes, also sometimes known as mebibytes, or
gigabytes, as the amazingly silly gibibytes. Makes you want to
gibber, doesn't it?


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

Bug#704198: VFAT header from USB flashdrive partition

[ian_bruce]

$ dd if=/dev/sde1 bs=512 count=32 | gzip usb-flash-partition-vfat.gz
32+0 records in
32+0 records out
16384 bytes (16 kB) copied, 0.000119295 s, 137 MB/s


usb-flash-partition-vfat.gz
Description: GNU Zip compressed data

Bug#687009: archivemount: package description contains unicode quote characters

[ian_bruce]

On Sat, 8 Sep 2012 18:20:38 +0300
Nanakos Chrysostomos nana...@wired-net.gr wrote:

 would it be better if there were single quotation marks (1 byte)? The
 Debian Policy, section 5.1 dictates that control files should be UTF8
 encoded.

Thanks for pointing that out; I had assumed that they were supposed to
be Latin-1 or something like that.

Even so, using Unicode quote marks seems to be overkill, when an ASCII
quote mark (0x22) would do just as well.

What do other packages do?


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

Bug#687009: archivemount: package description contains unicode quote characters

[ian_bruce]

On Sun, 9 Sep 2012 06:13:04 -0700
ian_br...@fastmail.net wrote:

 Thanks for pointing that out; I had assumed that they were supposed to
 be Latin-1 or something like that.
 
 Even so, using Unicode quote marks seems to be overkill, when an ASCII
 quote mark (0x22) would do just as well.

I probably wouldn't have even noticed it, except for

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679386

which breaks locale-setting, and therefore Unicode text.


-- Ian Bruce


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

Bug#666783: ST290 USB device information

[ian_bruce]

This is the information reported by my ST290 joystick, in case it is
helpful.

***

# lsusb -v -d 06a3:0460

Bus 002 Device 003: ID 06a3:0460 Saitek PLC ST290 Pro Flight Stick
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize0 8
  idVendor   0x06a3 Saitek PLC
  idProduct  0x0460 ST290 Pro Flight Stick
  bcdDevice1.01
  iManufacturer   0 
  iProduct2 Saitek ST290 Pro
  iSerial 0 
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   34
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0x80
  (Bus Powered)
MaxPower   90mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 3 Human Interface Device
  bInterfaceSubClass  0 No Subclass
  bInterfaceProtocol  0 None
  iInterface  5 EP1
HID Device Descriptor:
  bLength 9
  bDescriptorType33
  bcdHID   1.00
  bCountryCode0 Not supported
  bNumDescriptors 1
  bDescriptorType34 Report
  wDescriptorLength 109
 Report Descriptors: 
   ** UNAVAILABLE **
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0008  1x 8 bytes
bInterval  10
Device Status: 0x
  (Bus Powered)


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

Bug#673314: flightgear: please upgrade to v2.8.0

[ian_bruce]

In case you don't already know, FlightGear v2.8.0 has been released,
as of August 17, 2012.

http://www.flightgear.org/news/flightgear-v2-8-0-released/

Presumably it would make sense to cease packaging work on v2.6.0, and
concentrate on the newer version instead.


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

Bug#684128: PATCH: choice of binary or decimal disk storage units is runtime-configurable

[ian_bruce]

On Thu, 9 Aug 2012 13:53:30 +0200
Christian PERRIER bubu...@debian.org wrote:

 I'd like to get other D-I people advice about including these changes
 *now* as thereis always a risk of regressions which, at this point of
 the release, we would like to avoid.

That's an important consideration. I offer the following test scripts as
evidence of non-regression.

The h-to-l.sh and l-to-h.sh scripts should be run in busybox, once with
the old definitions of human2longint() and longint2human(), and once
with the new definitions, and the output saved to file.

The old and new versions of human2longint() produce output that is
byte-for-byte identical.

The new versions of longint2human() produces output that is different
from the old in the following respects, as previously advertised:

- if the chosen unit is bytes, then decimal fractions are not printed

- otherwise, two decimal places are printed

- values such as 99 are rounded up to 1.00 MB

The third script, round.sh, when applied to the new version output,
accounts for the first two causes of difference, leaving the third:

$ ./round.sh l-to-h.new | diff l-to-h.old -

These tests must obviously be run in decimal mode, since the reason for
the patch is that the old code does not operate with binary unit values.

I would be interested to hear suggestions as to what sort of tests of
binary mode operation would be considered sufficient for the patch to be
accepted.


-- Ian Bruce


h-to-l.sh
Description: application/shellscript


l-to-h.sh
Description: application/shellscript


round.sh
Description: application/shellscript

Bug#684128: PATCH: choice of binary or decimal disk storage units is runtime-configurable

[ian_bruce]

On Thu, 9 Aug 2012 10:59:20 -0400
Joey Hess jo...@debian.org wrote:

 I hate to bring this news, but this cannot be used in the installer,
 because shell arrays are a bashism, and the installer uses busybox sh.

Thanks for pointing that out. It seems that shell arrays are more of a
ksh-ism; see the manual page for mksh(1). I did try to avoid obvious
bashisms, but I didn't know that Bourne shell doesn't have arrays, or
that its arithmetic was so crippled.

Fixed now; I've tested this version with busybox, and it seems to work
fine. See attachments.

checksums:
425334e865579c218e15f66fa018dd50  partman-base_158.diff
0e38d0168a14c42cccd24857c0fd219c  cvt.sh

 FWIW, it is possible, though painful to emulate shell arrays using
 eval, or other tricks.

I'll remember that trick; it will be useful sometime. In this case, the
arrays are read-only, so a case statement wrapped up in a function will
do fine. Arrays are just functions on a subset of integers, anyway.

As a special bonus, this version outputs KiB, MiB, etc, when
operating in binary mode.

As an extra special bonus, it now has support for {peta,pebi}bytes, just
in case somebody wants to set up an array of 400 three-terabyte disks. 
Unfortunately, this isn't currently working, apparently because of
64-bit arithmetic overflows in expr. (Isn't that what expr is
supposed to avoid?)

For those who don't care, a decimal petabyte is only 8/9 of a binary
pebibyte.


-- Ian Bruce
--- partman-base-158/lib/base.sh.orig	2012-01-03 07:49:51.0 -0800
+++ partman-base-158/lib/base.sh	2012-08-10 00:55:43.0 -0700
@@ -278,110 +278,142 @@
 	else
 		return 1
 	fi
 }
 
+name_units ()
+{
+	local n=$1 s
+	if [ $USE_BINARY_UNITS ]
+	then
+		case $n in
+		0) s=B ;;
+		1) s=KiB ;;
+		2) s=MiB ;;
+		3) s=GiB ;;
+		4) s=TiB ;;
+		5) s=PiB ;;
+		esac
+	else
+		case $n in
+		0) s=B ;;
+		1) s=kB ;;
+		2) s=MB ;;
+		3) s=GB ;;
+		4) s=TB ;;
+		5) s=PB ;;
+		esac
+	fi
+	echo $s
+}
+
+disk_units ()
+{
+	local n=$1 r
+	if [ $USE_BINARY_UNITS ]
+	then
+		case $n in   # (2^10)^{0,1,2,3,4,5}
+		0) r=1 ;;
+		1) r=1024 ;;
+		2) r=1048576 ;;
+		3) r=1073741824 ;;
+		4) r=1099511627776 ;;
+		5) r=1125899906842624 ;;
+		esac
+	else
+		case $n in   # (10^3)^{0,1,2,3,4,5}
+		0) r=1 ;;
+		1) r=1000 ;;
+		2) r=100 ;;
+		3) r=10 ;;
+		4) r=1 ;;
+		5) r=1000 ;;
+		esac
+	fi
+	echo $r
+}
+
 longint2human () {
-	local longint suffix bytes int frac deci
+	local longint radix bytes int frac deci exp
 	# fallback value for $deci:
 	deci=${deci:-.}
-	case ${#1} in
-	1|2|3)
-		suffix=B
-		longint=${1}00
-		;;
-	4|5|6)
-		suffix=kB
-		longint=${1%?}
-		;;
-	7|8|9)
-		suffix=MB
-		longint=${1%}
-		;;
-	10|11|12)
-		suffix=GB
-		longint=${1%???}
-		;;
-	*)
-		suffix=TB
-		longint=${1%??}
-		;;
-	esac
-	longint=$(($longint + 5))
-	longint=${longint%?}
-	int=${longint%?}
-	frac=${longint#$int}
-	printf %i%s%i %s\n $int $deci $frac $suffix
+	bytes=$1
+	exp=6   # possible units
+	while [ $exp -gt 0 ]
+	do
+		exp=$((exp-1))
+		radix=$(disk_units $exp)
+#		expr $bytes = $radix /dev/null  break
+		expr 1000 \* $bytes = 995 \* $radix /dev/null  break
+	done
+	longint=$(expr $bytes \* 1000 + $radix \* 5)
+	int=$(expr $longint / \( $radix \* 1000 \) )
+	frac=$(expr $longint % \( $radix \* 1000 \) / \( $radix \* 10 \) )
+	if [ $exp -gt 0 ]
+	then
+		printf %i%s%02i %s\n $int $deci $frac $(name_units $exp)
+	else
+		printf %i %s\n $int $(name_units $exp)
+	fi
 }
 
 human2longint () {
-	local human orighuman gotb suffix int frac longint
+	local human orighuman gotb suffix int frac longint exp
 	set -- $*; human=$1$2$3$4$5 # without the spaces
 	orighuman=$human
 	human=${human%b} #remove last b
 	human=${human%B} #remove last B
 	gotb=''
 	if [ $human != $orighuman ]; then
 		gotb=1
 	fi
 	suffix=${human#${human%?}} # the last symbol of $human
 	case $suffix in
-	k|K|m|M|g|G|t|T)
+	k|K|m|M|g|G|t|T|p|P)
 		human=${human%$suffix}
 		;;
 	*)
 		if [ $gotb ]; then
 			suffix=B
 		else
-			suffix=''
+			suffix=M # default to megabytes
 		fi
 		;;
 	esac
 	int=${human%[.,]*}
 	[ $int ] || int=0
 	frac=${human#$int}
 	frac=${frac#[.,]} # to be sure there are at least 4 digits
 	frac=${frac%${frac#}} # only the first 4 digits of $frac
-	longint=$(expr $int \* 1 + $frac)
+	longint=$(expr $int \* 1 + $frac)
 	case $suffix in
 	b|B)
-		longint=${longint%}
-		[ $longint ] || longint=0
-		;;
+		exp=0 ;;
 	k|K)
-		longint=${longint%?}
-		;;
+		exp=1 ;;
 	m|M)
-		longint=${longint}00
-		;;
+		exp=2 ;;
 	g|G)
-		longint=${longint}0
-		;;
+		exp=3 ;;
 	t|T)
-		longint=${longint}
-		;;
-	*) # no suffix:
-		# bytes
-		#longint=${longint%}
-		#[ $longint ] || longint=0
-		# megabytes
-		longint=${longint}00
-		;;
+		exp=4 ;;
+	p|P)
+		exp=5 ;;
 	esac
-	echo $longint
+	expr $longint \* $(disk_units $exp) / 1
 }
 
 valid_human () {
 	local IFS patterns
 	patterns='[0-9][0-9]* *$
 [0-9][0-9]* *[bB] *$
-[0-9][0-9]* 

Bug#684128: PATCH: choice of binary or decimal disk storage units is runtime-configurable

[ian_bruce]

On Thu, 9 Aug 2012 17:33:04 +0200
Didier 'OdyX' Raboud o...@debian.org wrote:

 By defining a single environment variable, the new code can be
 configured to use the binary, rather than decimal, values of the
 suffixes {K, M, G, T} for both input and output, while retaining the
 above features.
 
 To be completely coherent, I think the patch should actually use the
 correct units in the two modes: {K,M,G,T}B in the case of 10^ and
 {Ki,Mi,Gi,Ti}B in the case of 2^, otherwise we're just allowing two
 interpretations of the same units instead of making sure the correct
 units are used for the correct numbers.

Do you mean for input, or for output?

For output, there's no problem with that; see my second patch, here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684128#88

If the {Ki,Mi,Gi,Ti}B units were to be used for input, then the
installer text would have to explain that. However, it was stated that
it is not now feasible to get new text translated. This is why I wrote
the patch such that binary or decimal units would be selected
automatically, possibly depending on a boot parameter; no text changes
are necessary.

In any case, not everybody agrees that the correct units are those
officially certified for the convenience of the hard disk manufacturers,
rather than what has been conventional usage for decades. I offer again
the example of lvcreate(8), which only provides the binary units, with
incorrect symbols, and does not see any need to even explain this.


-- Ian Bruce


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

Bug#684128: PATCH: choice of binary or decimal disk storage units is runtime-configurable

[ian_bruce]

On Thu, 9 Aug 2012 13:53:30 +0200
Christian PERRIER bubu...@debian.org wrote:

 Thanks for your care providing a patch. Even if I don't give a great
 importance to this issue, some people seem to (including you) so
 there's no reason to not consider your patch.

Thanks for taking seriously, the fact that /other/ people take this
issue seriously. I'm quite willing to change the patch, to incorporate
other people's advice.


-- Ian Bruce


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

Bug#684128: PATCH: choice of binary or decimal disk storage units is runtime-configurable

[ian_bruce]

o...@debian.org wrote:

 I don't think anyone is trying to avoid a proper resolution of this
 bug. So the people who care mostly (and know what a gibibyte is)
 should start working on patches if they really want to get this fixed;
 this work will not come magically out of the blue.

See attached patch, and code excerpt, for new versions of the functions
longint2human() and human2longint(), which implement both base-1000 and
base-1024 conversions to/from decimal, depending on a configuration
option.

MD5 checksums:
c75b7b8e66eff67f188fa18d328897ad  partman-base_158.diff
77d5ea04ee877a29cd9246d621156f0d  cvt.sh

Apart from the 2^(10*n) versus 10^(3*n) issue, this code improves on the
current version in the following respects:

- the longint2human() function produces a result with a precision of two
decimal places, rather than just one. This is consistent with what lvm,
mdadm, and parted do. This could be extended to any number of decimal
places with no code changes, just by altering a few constants.

- if the unit displayed is bytes, then the decimal places are omitted. 
There cannot be a fractional number of bytes allocated, so it makes no
sense to suggest this by printing a decimal point followed by zeros.

- the current code suffers from the following anomaly: longint2human()
maps the value 99 to 1000.0 kB, and 100 to 1.0 MB. These
rounded values are equivalent, so they ought to be displayed the same
way. The new code maps the entire range [995000..1004999] to 1.00 MB,
and behaves analogously with other units.

- the new code is twelve lines shorter than the original.

By defining a single environment variable, the new code can be
configured to use the binary, rather than decimal, values of the
suffixes {K, M, G, T} for both input and output, while retaining the
above features.

***

I take the point that it is not currently feasible to get translations
of new or changed text for the installer. What I propose is to apply
this small patch, and make no changes at all to any text. When operating
in decimal mode, the new code is functionally identical to the old,
apart from the improvements listed above. When operating in binary mode,
identical input text will simply be interpreted as s*(2^(10*n)) rather
than s*(10^(3*n)).

The choice of whether the partitioner operates in binary or decimal mode
can be controlled by a boot parameter, so as not to introduce any new
user-visible text into the installer.

http://www.debian.org/releases/stable/i386/ch05s03.html.en#installer-args

***

Now we can all fight about whether the default partitioning mode should
be binary or decimal. I'm curious to hear why, if just about nobody
cares about the difference between 2^(10*n) and 10^(3*n), it would be
unacceptable to default to 2^(10*n), which is what just about everybody
who does care would expect.


-- Ian Bruce
--- partman-base-158/lib/base.sh.orig	2012-01-03 07:49:51.0 -0800
+++ partman-base-158/lib/base.sh	2012-08-08 23:28:58.0 -0700
@@ -278,45 +278,44 @@
 	else
 		return 1
 	fi
 }
 
+suffix_units=(B kB MB GB TB)
+
+decimal_units=(1 1000 100 10 1)  # (10^3)^{0,1,2,3,4}
+
+binary_units=(1 1024 1048576 1073741824 1099511627776)   # (2^10)^{0,1,2,3,4}
+
 longint2human () {
-	local longint suffix bytes int frac deci
+	local longint radix bytes int frac deci units exp
 	# fallback value for $deci:
 	deci=${deci:-.}
-	case ${#1} in
-	1|2|3)
-		suffix=B
-		longint=${1}00
-		;;
-	4|5|6)
-		suffix=kB
-		longint=${1%?}
-		;;
-	7|8|9)
-		suffix=MB
-		longint=${1%}
-		;;
-	10|11|12)
-		suffix=GB
-		longint=${1%???}
-		;;
-	*)
-		suffix=TB
-		longint=${1%??}
-		;;
-	esac
-	longint=$(($longint + 5))
-	longint=${longint%?}
-	int=${longint%?}
-	frac=${longint#$int}
-	printf %i%s%i %s\n $int $deci $frac $suffix
+	[ $USE_BINARY_UNITS ]  units=(${binary_units[*]}) \
+|| units=(${decimal_units[*]})
+	bytes=$1
+	exp=${#units[*]}
+	while ((exp0))
+	do
+		((exp-=1))
+		radix=${units[exp]}
+#		expr $bytes = $radix /dev/null  break
+		expr 1000 \* $bytes = 995 \* $radix /dev/null  break
+	done
+	longint=$(expr $bytes \* 1000 + $radix \* 5)
+	int=$(expr $longint / \( $radix \* 1000 \) )
+	frac=$(expr $longint % \( $radix \* 1000 \) / \( $radix \* 10 \) )
+	if ((exp0))
+	then
+		printf %i%s%02i %s\n $int $deci $frac ${suffix_units[exp]}
+	else
+		printf %i %s\n $int ${suffix_units[exp]}
+	fi
 }
 
 human2longint () {
-	local human orighuman gotb suffix int frac longint
+	local human orighuman gotb suffix int frac longint units exp
 	set -- $*; human=$1$2$3$4$5 # without the spaces
 	orighuman=$human
 	human=${human%b} #remove last b
 	human=${human%B} #remove last B
 	gotb=''
@@ -330,46 +329,35 @@
 		;;
 	*)
 		if [ $gotb ]; then
 			suffix=B
 		else
-			suffix=''
+			suffix=M # default to megabytes
 		fi
 		;;
 	esac
 	int=${human%[.,]*}
 	[ $int ] || int=0
 	frac=${human#$int}
 	frac=${frac#[.,]} # to be sure there are at least 4 digits
 	

Bug#684128: false advertising

[ian_bruce]

 Severity set to 'wishlist' from 'important'

So if the partitioner invites people to specify their swap space, or any
other volume, in units of gigabytes, which JUST ABOUT EVERYBODY
understands to mean 2^30 in that context, and instead it uses the hard
disk manufacturers' phony units which are seven percent smaller, WITHOUT
EVEN TELLING YOU THIS, and you only find out when the installation is
complete, and nothing can be done about it except starting all over
again, then this isn't a real bug, but just wishlist?

Thanks for clearing that up.



quote from ls(1) man page:

--block-size=SIZE

scale sizes by SIZE before printing them. E.g., `--block-size=M'
prints sizes in units of 1,048,576 bytes. See SIZE format below.


quote from df(1) man page:

-B, --block-size=SIZE

scale sizes by SIZE before printing them. E.g., `-BM' prints
sizes in units of 1,048,576 bytes. See SIZE format below.


quote from du(1) man page:

-B, --block-size=SIZE

scale sizes by SIZE before printing them. E.g., `-BM' prints
sizes in units of 1,048,576 bytes. See SIZE format below.


[for all of the above, K=1024, M=1024^2, G=1024^3, T=1024^4]


quote from lvcreate(8) man page:

-L, --size LogicalVolumeSize[bBsSkKmMgGtTpPeE]

Gives the size to allocate for the new logical volume. A size
suffix of K for kilobytes, M for megabytes, G for gigabytes, T
for terabytes, P for petabytes or E for exabytes is optional. 
Default unit is megabytes.


[here it is considered so obvious that binary units are intended that
they don't even bother to mention it]


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

Bug#684128: false advertising

[ian_bruce]

On Tue, 7 Aug 2012 14:11:05 +0200
Christian PERRIER bubu...@debian.org wrote:

 So if the partitioner invites people to specify their swap space, or
 any other volume, in units of gigabytes, which JUST ABOUT EVERYBODY
 understands to mean 2^30 in that context, and instead it uses the
 hard disk manufacturers' phony units which are seven percent smaller,
 WITHOUT EVEN TELLING YOU THIS,
 
 I think you probably have a strange definition of just about
 everybody. In reality, I think that just about nobody cares about
 gigabytes being 2^30, or 10. This is basically splitting
 hairs, which wishlist perfectly fits.

$ bc  scale=6 ; (2^40) / (10^12)
1.099511

The difference between a binary and decimal terabyte is ten percent, or
one hundred gigabytes.

I would have thought that a lot of people would care about that, but
maybe I'm just strange.

$ bc  scale=6 ; (2^30) / (10^9)
1.073741

$ bc  scale=6 ; (2^20) / (10^6)
1.048576

Clearly the hard disk manufacturers care about differences of even five
and seven percent, or they wouldn't have been deliberately ripping
people off for decades.

http://en.wikipedia.org/wiki/Binary_prefix#Legal_disputes


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

Bug#641749: package libmtp-runtime breaks AR3011 Bluetooth

[ian_bruce]

Andres Cimmarusti acimmaru...@gmail.com wrote:

 I believe I have finally narrowed down the problem. It lies in the
 'libmtp-runtime' package with the command 'mtp-probe' (only present in
 wheezy or newer).

 I'm not sure what this is doing to my system, but when the package
 mentioned is installed, it messes up my atheros bluetooth device so
 that the kernel/udev cannot load the firmware into it.

 As soon as I uninstalled this package and thus caused the boot process
 to throw some errors about missing mtp-probe command, my bluetooth
 module was correctly loaded and the led turned on.


James M. Leddy jm.le...@gmail.com wrote:

 This turned out to be a problem with the firmware. It should be fixed
 by this modification to the firmware:

 http://comments.gmane.org/gmane.linux.kernel/1262485


I also found that removal of the libmtp-runtime package (version
1.1.2-2) solved the problem with my AR3011 Bluetooth device.
(AMD64 CPU, Linux v3.2)

After reading here:

https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/714862/comments/43

https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/714862/comments/45

http://permalink.gmane.org/gmane.linux.kernel1.73/1262485

-- that there was a firmware patch which supposedly addressed this
problem, I obtained the Ubuntu linux-firmware package which contains
the updated ath3k-1.fw file (as of version 1.73):

http://packages.ubuntu.com/precise/linux-firmware

http://changelogs.ubuntu.com/changelogs/pool/main/l/linux-firmware/linux-firmware_1.79/changelog

-- and substituted their file in place of the one from the Debian
firmware-atheros package (version 0.36). I confirmed that the firmware
images are in fact different.

Result: the firmware change appears to have no effect at all. I tried
booting up with all four combinations of

{libmtp-runtime present/not present} x {Debian firmware/Ubuntu firmware}

and the Bluetooth device works or not depending on the presence (no) or
absence (yes) of libmtp-runtime, regardless of the firmware version.

I urge other people to try this experiment.

Later comments in the corresponding Ubuntu bug report:

https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/714862

-- agree with this result:

https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/714862/comments/40

https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/714862/comments/53

https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/714862/comments/55

The changelog for the Ubuntu linux-firmware development package lists
under version 1.87 the entry UBUNTU: Remove obsolete ath3k firmware. I
do not know what the significance of this comment is.

http://packages.ubuntu.com/quantal/linux-firmware

http://changelogs.ubuntu.com/changelogs/pool/main/l/linux-firmware/linux-firmware_1.88/changelog


-- Ian Bruce


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

Bug#679386: [Pkg-xfce-devel] Bug#679386: lightdm: Language selection is ignored in session, $LANG is system default

[ian_bruce]

On Mon, 23 Jul 2012 07:59:32 +0200
Yves-Alexis Perez cor...@debian.org wrote:

 It seems that this was done on purpose because, apparently, the data
 should come from PAM. See upstream bug for more details.

Presumably you mean here:

https://bugs.launchpad.net/lightdm/+bug/1019314

I agree with your description of the situation, except for this:

In 1.2, when the user selects the locale in LightDM greeter, it's
set for the session and saved in .dmrc. Then for the following
sessions, nothing loads .dmrc and the locale is not correctly set.

That's not what I'm seeing.

In 1.2, when the user selects the locale in the LightDM greeter, it's
saved in ~/.dmrc, but it IS NOT set in the environment for that session,
or any other.

See my comment on the Debian bug report, and the explanation by the
original submitter, which are in agreement on this point:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679386

In other words, LightDM locale selection is currently completely
useless, because it has no effect at all on the session being started,
or any subsequent one.

One might ask why a Pluggable Authentication Module ought to be
responsible for things which clearly have nothing to do with
authentication, such as locale selection, especially when they are
liable to change at every login.


-- Ian Bruce


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

Bug#679386: [Pkg-xfce-devel] Bug#679386: Bug#679386: lightdm: Language selection is ignored in session, $LANG is system default

[ian_bruce]

On Mon, 23 Jul 2012 10:33:32 +0200
Yves-Alexis Perez cor...@debian.org wrote:

 One might ask why a Pluggable Authentication Module ought to be
 responsible for things which clearly have nothing to do with
 authentication, such as locale selection, especially when they are
 liable to change at every login.
 
 PAM is more than authentication, it handles quite some login-related
 stuff. And maybe it makes sense to store login-specific settings like
 locales into PAM. But my feeling is that it's not the case. It seems
 that PAM (through pam_env module) only handles /default/ environment,
 taken from /etc/environment. So while it might be useful to have a
 default setting for the box, it's plain useless for user-specific
 settings. So if my analysis is right, I'm a bit puzzled about the
 change.

This.

Not just user-specific settings, but session-specific settings.

 Note that you might try with accountsservice installed, it might help.

Doesn't seem to, and I don't see why it would. According to the README:

The AccountsService project provides

 - A set of D-Bus interfaces for querying and manipulating user
 account information.

 - An implementation of these interfaces based on the usermod(8),
 useradd(8) and userdel(8) commands.

There's nothing session-specific about that.


-- Ian Bruce


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

Bug#679386: [Pkg-xfce-devel] Bug#679386: Bug#679386: lightdm: Language selection is ignored in session, $LANG is system default

[ian_bruce]

On Mon, 23 Jul 2012 11:29:26 +0200
Yves-Alexis Perez cor...@debian.org wrote:

 Not just user-specific settings, but session-specific settings.
 
 Eh?

The same user might want to work in different languages at various
times.

The natural place to specify this is when they log in, rather than with
some inconvenient account management utility. That would only take
effect once they logged out and then logged in again, which would be a
real nuisance.

See the discussion here:

https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/803858

https://lists.ubuntu.com/archives/ubuntu-desktop/2011-July/thread.html#3137

-- between multilingual users who need this feature, and unilingual
developers who Gnomeishly inform them that you'll do as we tell you to,
and you'll like it.


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

Bug#675016: ifupdown: don't use PPP updetach option by default

[ian_bruce]

On Tue, 29 May 2012 14:47:58 +0200
Andrew Shadura bugzi...@tut.by wrote:

 I agree with many points of yours, but please explain how does it
 break the boot sequence. Networking initscript allows ifup to fail as
 far as I can see. How exactly does it break for you?

pppd persist maxfail 0 updetach does not return until the PPP link
comes up. If this does not happen for some reason, it never returns at
all, and the boot sequence stops before any console is available, even
in recovery mode. It's easy to reproduce the problem: enable the
persist and maxfail 0 options, unplug the ethernet cable to the
modem, and reboot.

Simple solution: take the updetach out of the ifup binary, as it was
until recently, and if necessary, put it in /etc/network/interfaces,
since this is now allowed to specify arbitrary options.

Better solution: find some dependency mechanism with hotplug or udev
that also works for DHCP or any other network configuration system.

There's no valid reason why the entire boot sequence should have to wait
until some WAN interface comes up; anything that actually depends on
that happening should find some other way of noticing it.


-- Ian Bruce



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

Bug#652660: 70-persistent-net.rules not generated

[ian_bruce]

I confirm this bug, and the fix proposed here:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652660#25

Since this will break a lot of network configurations (it broke mine),
and the fix is trivial, why is this not being urgently updated?

This seems absurd.



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

Bug#578019: closed by Gustavo Noronha Silva k...@debian.org (Bug#578019: fixed in webkit 1.2.7-3)

[ian_bruce]

On Fri, 29 Apr 2011 12:36:10 +
ow...@bugs.debian.org (Debian Bug Tracking System) wrote:

 This is an automatic notification regarding your Bug report
 which was filed against the libwebkit-1.0-2 package:
 
 #578019: libwebkit-1.0-2: makes DNS query for every mouse movement
 
 It has been closed by Gustavo Noronha Silva k...@debian.org.

Bug reopened because it doesn't seem to have been fixed.

After installing libwebkit-1.0-2 v1.2.7-3, Epiphany and Midori still
exhibit the same problem. Chromium doesn't, but for some reason it does
not depend on libwebkit-1.0-2, and does not appear to be doing any DNS
prefetching at all, even though this is supposed to be enabled. I don't
know why that would be.


This is all on i386, if that matters.




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

Bug#578019: libwebkit-1.0-2: makes DNS query for every mouse movement

[ian_bruce]

On Tue, 20 Apr 2010 10:12:16 -0300
Gustavo Noronha Silva k...@debian.org wrote:

 I can reproduce the problem with the HTML page you crafted. Seems
 worth reporting upstream (I will do it later today).

 For some reason WebKit thinks it should do the pre-resolution when the
 mouse is moved on top of the blank area of the page indeed.

Just to clarify:

-- with the test HTML page, do you get the DNS query storm only when the
mouse is over the http://./ links, or also over the non-link areas of
the page?

-- if it happens on the non-link areas, is that true only for the test
page, or also for any random web page, for example
http://www.debian.org/?

-- if it happens for just about any web page, why do you suppose that
the other two investigators can't reproduce it? Does it have something
to do with the hostname resolver configuration, as I suggested above?

-- why would the behavior disappear when the same page is referenced
with a file:// rather than a http:// URL?

I note the following item in your backtrace, which may reveal where and
how this bug was introduced:

#2  0x7f0f1d4bc740 in WebCore::Chrome::mouseDidMoveOverElement (
this=0x7f0f204da270, result=..., modifierFlags=24594032)
at ../WebCore/page/Chrome.cpp:340

(The Chrome label is probably significant.)




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

Bug#578019: libwebkit-1.0-2: makes DNS query for every mouse movement

[ian_bruce]

On Tue, 20 Apr 2010 10:12:16 -0300
Gustavo Noronha Silva k...@debian.org wrote:

 I can reproduce the problem with the HTML page you crafted. Seems
 worth reporting upstream (I will do it later today).

 For some reason WebKit thinks it should do the pre-resolution when the
 mouse is moved on top of the blank area of the page indeed.

It turns out that this bug was already reported OVER A YEAR AGO:

https://bugs.webkit.org/show_bug.cgi?id=23846#c3

A fix was proposed over six months ago:

https://bugs.webkit.org/show_bug.cgi?id=23846#c5

I don't understand why this fix hasn't been applied upstream. Even if
you don't think this behaviour is a security problem, it's a big waste
of CPU and network resources to issue a completely useless external DNS
query for every mouse movement event -- that is, for every few pixels
that the pointer moves. That is a ridiculously stupid thing to do.

Gustavo, I draw your attention particularly to the following comments:

https://bugs.webkit.org/show_bug.cgi?id=23846#c14

https://bugs.webkit.org/show_bug.cgi?id=23846#c19




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

Bug#578019: libwebkit-1.0-2: makes DNS query for every mouse movement

[ian_bruce]

On Sun, 18 Apr 2010 10:08:23 -0400
Michael Gilbert michael.s.gilb...@gmail.com wrote:

 i suppose i am not able to reproduce it either.  i see a modest amount
 of dns queries when the page is first loaded, then more queries when
 links are moused over.

I have that too, the first time the mouse pointer touches a link to some
website. I think we can agree that this DNS pre-resolution is an
intentional feature. What I claim is a bug is this:

 but i don't see the claimed activity for every pixel moved by the
 mouse.

-- except, strangely enough, if the mouse pointer moves along a link
which has already been resolved once, no more DNS queries are
generated. As soon as it ceases to touch any hyperlink at all, there is
a continuous stream of DNS queries for every mouse movement event.

Some thoughts:

-- the domain name which is being queried seems to be literally . (or
perhaps even the null string). Naturally, the response from the DNS
server is that this name cannot be resolved.

-- suppose that WebKit, for some obscure reason, fails to distinguish
between the cases that the mouse is hovering over a link with a hostname
of ., and that the mouse is not over any link at all.

-- suppose further that WebKit fails to remember that . is
unresolvable, and queries it again every time it thinks the mouse is
hovering over such a link.

-- then the above-mentioned DNS pre-resolution will result in exactly
the behavior that I've described, with the observed result that when the
mouse is over an actual hyperlink which has already been resolved, the
stream of DNS queries ceases.

Confirmation -- consider the following HTML page:

html
head
  style
  a:hover { color: #00FF00 }
  /style
/head
body
  h1It works!/h1
  pThis is the default web page for this server./p
  pThe web server software is running
 but no content has been added, yet./p
  p
a href=null link/a
a href=page.htmlpage.html/a
a href=http://./;http://.//a
a href=http://./page.html;http://./page.html/a
  /p
/body
/html

When viewing this page (in Midori) as http://127.0.0.1/index.html,
mouse movement over the non-link area of the page produces the usual DNS
query storm. Movement over the first two links does not produce any DNS
queries. However, movement over the second two links produces EXACTLY
the same DNS storm as the non-link area.

Strangely, when the page is viewed as file:///var/www/index.html,
mouse movement over the hyperlinks or any other part of the page does
not result in the DNS query storm.

This still doesn't explain why you do not observe the same behavior.
Maybe it depends on what kind of error gethostbyname(3) returns for the
hostname . .

If so, then it might have something to do with the contents of the files
/etc/{host.conf,resolv.conf,nsswitch.conf} .

Here's mine; maybe you can reproduce the problem by using these:

$ cat /etc/host.conf 
multi on
order hosts,bind

$ cat /etc/resolv.conf
nameserver NS1-IP-ADDR
nameserver NS2-IP-ADDR

$ cat /etc/nsswitch.conf 
passwd: compat
group:  compat
shadow: compat
hosts:  files dns
networks:   files
protocols:  db files
services:   db files
ethers: db files
rpc:db files
netgroup:   nis




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

Bug#578019: libwebkit-1.0-2: makes DNS query for every mouse movement

[ian_bruce]

On Sat, 17 Apr 2010 17:46:50 -0400
Michael Gilbert michael.s.gilb...@gmail.com wrote:

 I have to say that I find this behaviour appalling. It seems to be a
 security issue all by itself, and is probably a symptom of even
 bigger problems.
 
 it may actually be undesirable,

It may actually be completely illegitimate and pointless to try
thousands of times to resolve the domain name . .

 but i don't think it can be considered a security issue.

As long as you don't mind having every movement of your mouse, no matter
how tiny, reported on your external network connection.

 iceweasel does pretty much the same thing anyway.

That is absolutely false. If you would try it for yourself, you would
see that it does no such thing.

 i think this has to do with page precaching, and there are options to
 disable that.

There can be no rational reason for making an unlimited number of DNS
queries for the hostname . on the pretext that the mouse has moved. It
has to do with being a particularly stupid bug.




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

Bug#578019: libwebkit-1.0-2: makes DNS query for every mouse movement

[ian_bruce]

On Sun, 18 Apr 2010 08:41:30 +0200
Mike Hommey m...@glandium.org wrote:

 I can't reproduce this behaviour... Are you sure these requests come
 from epiphany ?

Epiphany, or Midori.

midori : version 0.2.4-2

epiphany-browser : version 2.30.2-1

libwebkit-1.0-2 : version 1.2.0-1

The correlation between moving the mouse pointer around in the browser
window, and getting this stream of DNS queries, is 100%. If the mouse
pointer is motionless, or not inside the browser window, nothing
happens. If it moves inside the browser window, there are two DNS
queries for every pixel of movement (or more probably, every mouse event
from the X server):

00:27:05.355933 IP web.client.52494  dns.server.53: 44565+ A? . (17)
00:27:05.356072 IP web.client.52494  dns.server.53: 6626+ ? . (17)
00:27:05.378726 IP dns.server.53  web.client.52494: 44565 0/1/0 (92)
00:27:05.379457 IP dns.server.53  web.client.52494: 6626 0/1/0 (92)

It doesn't even matter whether the browser window has the input
focus. However, if the mouse pointer moves along a hyperlink, then no
DNS queries are generated.

This is probably a stupid question, but does your /etc/resolv.conf point
to a remote DNS server? Does tcpdump show the DNS query for the webhost
when a page gets loaded?




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

Bug#578019: libwebkit-1.0-2: makes DNS query for every mouse movement

[ian_bruce]

On Sun, 18 Apr 2010 09:53:26 +0200
Mike Hommey m...@glandium.org wrote:

 Does tcpdump show the DNS query for the webhost when a page gets
 loaded?
 
 Yes it does. Have you tried with another window manager ?

xfwm4 (v4.6.1-1) and metacity (v1:2.28.0-3) exhibit exactly the same
behavior. Are there any others you would like me to try?

I don't really see why the window manager would have anything to do with
it anyway. Either mouse movement events get reported to the window in
question, or they don't. The real issue is, why WebKit (or whatever)
feels compelled to make a DNS query for . every time it receives a
mouse move event.

As I already mentioned, neither Galeon nor Iceweasel have this problem;
it seems to be WebKit-specific. But since you can't reproduce it, there
must be some other dependency as well.

some library versions:

libgtk2.0-0 : 2.20.0-2

libglib2.0-0 : 2.24.0-1

Anything else come to mind?




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

Bug#431809: podofo packages available from scribus project

[ian_bruce]

The scribus project seems to have produced podofo packages for Debian
(and Ubuntu).

download here:

http://debian.scribus.net/debian/dists/stable/main/
http://debian.scribus.net/debian/dists/testing/main/
http://debian.scribus.net/debian/dists/unstable/main/

A number of people seem to be interested in this; it's unfortunate that
it's not available as an official Debian package.


-- Ian Bruce




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

Bug#545274: dpkg-dev: dpkg-source cannot verify GPG signatures

[ian_bruce]

On Mon, 7 Sep 2009 08:45:58 +0200
Raphael Hertzog hert...@debian.org wrote:

 Other idea, please paste the output of
 dpkg-vendor --query Vendor  echo $?.
 
 I guess that's more likely to be the problem... you have not upgraded
 base-files to the unstable version. Install version 5.0.0 or newer and
 try again.

# dpkg-vendor --query Vendor ; echo $?
dpkg-vendor: error: vendor default doesn't exist in /etc/dpkg/origins/
2
# 
# ls -l /etc/dpkg/origins/
total 4
-rw-r--r-- 1 root root 82 2009-02-02 14:13 debian
# 
# cat /etc/dpkg/origins/debian 
Vendor: Debian
Vendor-URL: http://www.debian.org/
Bugs: debbugs://bugs.debian.org
# 
# apt-show-versions -a base-files
base-files 5lenny2 install ok installed
base-files 5lenny4 stable   ftp.us.debian.org
base-files 5.0.0   testing  ftp.us.debian.org
base-files 5.0.0   unstable ftp.us.debian.org
base-files/testing upgradeable from 5lenny2 to 5.0.0
# 
# apt-get install base-files
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following packages will be upgraded:
  base-files
1 upgraded, 0 newly installed, 0 to remove and 548 not upgraded.
Need to get 68.0kB of archives.
After this operation, 24.6kB of additional disk space will be used.
Get:1 http://ftp.us.debian.org testing/main base-files 5.0.0 [68.0kB]
Fetched 68.0kB in 0s (118kB/s)
(Reading database ... 141937 files and directories currently installed.)
Preparing to replace base-files 5lenny2 (using 
.../base-files_5.0.0_i386.deb) ...
Unpacking replacement base-files ...
Setting up base-files (5.0.0) ...
Installing new version of config file /etc/debian_version ...
Installing new version of config file /etc/issue ...
Installing new version of config file /etc/issue.net ...
# 
# dpkg-source --require-valid-signature -x psutils_1.17-27.dsc
dpkg-source: info: extracting psutils in psutils-1.17
dpkg-source: info: unpacking psutils_1.17.orig.tar.gz
dpkg-source: info: applying psutils_1.17-27.diff.gz
# 

 That explains why it doesn't use the Debian keyring since it doesn't
 know that the current vendor is Debian, since no keyring are passed to
 gpgv, it fallbacks to usings trustedkeys which doesn't exist and
 complains about it.

Seems like it. Maybe a versioned Depends: would help?


-- Ian Bruce




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

Bug#545274: dpkg-dev: dpkg-source cannot verify GPG signatures

[ian_bruce]

On Sun, 6 Sep 2009 10:38:37 +0200
Raphael Hertzog hert...@debian.org wrote:

  $ dpkg-source --require-valid-signature -x psutils_1.17-27.dsc
  gpgv: keyblock resource `/home/ian/.gnupg/trustedkeys.gpg': general 
  error
  gpgv: Signature made Wed 19 Aug 2009 04:21:54 PM PDT using DSA key ID 
  D688E0A7
  gpgv: Can't check signature: public key not found
  dpkg-source: error: failed to verify signature on ./psutils_1.17-27.dsc 
   
 
 What's up with /home/ian/.gnupg/trustedkeys.gpg?
 Is it a good keyring file? Does it have correct permissions?

 Try again after moving it out of the way?

It doesn't exist -- but it shouldn't have to, since the required key is
supplied by the debian-keyring package, as shown by the fact that
dscverify succeeds where dpkg-source fails.


-- Ian Bruce




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

Bug#531052: claws-mail: Message-ID header does not conform to RFC-2822

[ian_bruce]

On Sun, 31 May 2009 23:16:04 +0200
Colin Leroy co...@colino.net wrote:

 As Colin Leroy pointed out, there's already an option to set the
 domain name of the Message-ID, so most of the necessary code is
 already there. It just needs to be changed so that the default option
 is to use the email address instead of the hostname.
 
 We're not willing to change this.

Well then, how about making it an option?

That is, have a checkbox to select time.number.use...@domain as the
Message-ID, where use...@domain is the account email address. The
current option doesn't actually allow this, because it omits the userid
part of the email address.

It seems to me that this is a superior choice in every respect. It
certainly has no disadvantages relative to using the local domain name,
which, as I already pointed out, potentially creates a security threat
because it exposes information about private networks.


-- Ian Bruce




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

Bug#531052: claws-mail: Message-ID header does not conform to RFC-2822

[ian_bruce]

On Sat, 30 May 2009 12:04:54 +0200
Ricardo Mones mo...@debian.org wrote:

 Claws-Mail generates Message-ID headers of the form
 time.num...@hostname ; for example,
 20090529055315.7f6ad...@foobar .
 
 This does not conform to RFC-2822, which requires that the string
 after the @ character be a fully-qualified domain name, in order to
 make the Message-ID globally unique.
 
 That's simply not true: it requires the Message-ID to be globally
 unique and provides an example of algorithm to generate it, and
 *recommends* the domain name to be in the right side to help it to be
 unique.

Yes. Anyway, the point is that without a FQDN in the Message-ID, there
can be no guarantee that some other site will not coincidentally
generate the same identifier.

 Some mailing list software will refuse to process messages because of
 this problem.
 
 That's interesting because they are wrongly interpreting then the RFC
 in the way you exposed here while the RFC clearly states that there's
 several algorithms to get a globally unique identifier and they would
 also work.  IOW: these list software are buggy regarding RFC 2822. Do
 you have a list of them?

See here, for example:

http://www.robomod.net/doc/faq.txt

It's clear that what Claws-Mail currently generates is not guaranteed to
be globally unique, and is thus in violation of RFC-2822.

Another problem with using the hostname of the sending machine is that
this can expose information about a private network, which is
undesirable. The message recipient doesn't need to know the name of the
machine where the message was generated.

 A better choice would be for the Message-ID to be of the form
 time.number.use...@fqdn , where use...@fqdn is the sender's email
 address; for example,
 20090309043710.b6bc3b96.ian_br...@fastmail.net . This is what
 Sylpheed already does.
 
 This doesn't guarantee the identifier is globally unique and is just
 slightly better than current one. Notice also the FQDN can also be
 poorly configured in lots of machines which simply return the
 hostname.

That's why it should use the SENDER'S EMAIL ADDRESS, which is guaranteed
to be qualified with respect to whatever domain the email is being
transmitted within.

Note that for POP and IMAP accounts, the domain part of the email
address will probably have nothing to do with the host on which the
message is generated.

 The main source of uniqueness of the identifier goes to the number
 part which I think is correct as it is.

It can go right on being the main source of uniqueness; the point is
that if the Message-ID includes the sender's email address, you won't
get a collision when some unrelated host picks the same random number.

It's important to also include the userid part of the email address, to
cover the situation of a large number of accounts being hosted on the
same POP or IMAP server, and having their messages generated on multiple
uncoordinated client machines.

 Please import the relevant code section from Sylpheed, and also send
 this patch upstream. Thanks.
 
 It can be somewhat better to use the FQDN, hence I will probably
 prepare a patch, but that won't solve the problem on machines whose
 FQDN is the hostname.

Once again, the machine hostname is irrelevant, because it's got nothing
to do with the sender's email address.

As Colin Leroy pointed out, there's already an option to set the domain
name of the Message-ID, so most of the necessary code is already there.
It just needs to be changed so that the default option is to use the
email address instead of the hostname.

And again, the Sylpheed code already does the right thing; I don't know
why Claws-Mail doesn't just inherit that.


-- Ian Bruce




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

Bug#503067: claws-mail: should depend on package libc-ares2

[ian_bruce]

Package: claws-mail
Version: 3.5.0-2
Severity: important


If this package is not installed, the program will not run
because of a missing dynamic library.

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages claws-mail depends on:
ii  libaspell15   0.60.6-1   GNU Aspell spell-checker runtime l
ii  libc6 2.7-14 GNU C Library: Shared libraries
ii  libcairo2 1.6.4-6The Cairo 2D vector graphics libra
ii  libcompfaceg1 1:1.5.2-4  Compress/decompress images for mai
ii  libdbus-glib-1-2  0.76-1 simple interprocess messaging syst
ii  libetpan130.54-4 mail handling library
ii  libglib2.0-0  2.16.3-2   The GLib library of C routines
ii  libgtk2.0-0   2.12.10-2  The GTK+ graphical user interface 
ii  libice6   1:1.0.1-2  X11 Inter-Client Exchange library
ii  libldap-2.4-2 2.4.7-6.1  OpenLDAP libraries
ii  libpango1.0-0 1.20.3-2   Layout and rendering of internatio
ii  libpisock90.12.1-5   library for communicating with a P
ii  libsm61:1.0.1-3  X11 Session Management library
ii  libssl0.9.8   0.9.8g-10  SSL shared libraries

Versions of packages claws-mail recommends:
ii  aspell-en [aspell-dictionary] 6.0-0-5.1  English dictionary for GNU Aspell
ii  claws-mail-i18n   3.5.0-2Locale data for Claws Mail (i18n s
ii  xfonts-100dpi 1:1.0.0-3  100 dpi fonts for X
ii  xfonts-75dpi  1:1.0.0-3  75 dpi fonts for X

Versions of packages claws-mail suggests:
pn  claws-mail-doc   none  (no description available)
pn  claws-mail-tools none  (no description available)
ii  epiphany-gecko [www-browser] 2.22.3-4+b1 Intuitive GNOME web browser - Geck
ii  galeon [www-browser] 2.0.6-2 GNOME web browser for advanced use
ii  gedit2.22.3-1official text editor of the GNOME 
ii  iceweasel [www-browser]  3.0.3-2 lightweight web browser based on M
ii  w3m [www-browser]0.5.1-5.1   WWW browsable pager with excellent
ii  xemacs21-nomule [www-browser 21.4.21-4   highly customizable text editor --

-- no debconf information



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#496283: nvidia-kernel-2.6.26-1-amd64 still broken

[ian_bruce]

There's still a problem.

nvidia-kernel-2.6.26-1-amd64 depends on nvidia-kernel-common, which
contains the header Recommends: nvidia-kernel-source | nvidia-kernel.

Apparently there is no package which Provides: nvidia-kernel.
Therefore, nvidia-kernel-common sucks in an extra 96MB of stuff with
nvidia-kernel-source, which is completely unnecessary.

The solution is to have nvidia-kernel-2.6.26-1-amd64 Provides:
nvidia-kernel, nvidia-kernel-173.14.09.

Either that, or change the header in nvidia-kernel-common to
Recommends: nvidia-kernel-173.14.09.




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#495049: don't scan floppy disks for LVM or RAID

[ian_bruce]

Bean wrote:

 Just like raid, lvm needs to scan all device. I think this is caused
 when it try to open (fd0), and fails. The grub_errno is not cleared,
 it's carried out and cause the rescue shell. I think we can improve
 the test of (fd0) so that it won't appear in machine that don' t have
 floppy, or reset grub_errno in lvm scan code when error occurs.


http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=495049


--- grub2/disk/lvm.c.orig   2008-08-16 03:00:30.0 -0700
+++ grub2/disk/lvm.c2008-08-16 06:07:43.0 -0700
@@ -221,10 +221,15 @@
   struct grub_lvm_vg *vg;
   struct grub_lvm_pv *pv;
   
+  if (name[0]=='f'  name[1]=='d')
+return 0;
+
   disk = grub_disk_open (name);
   if (!disk)
 return 0;
 
+  grub_dprintf (lvm, Scanning (%s) for LVM devices\n, name);
+
   /* Search for label. */
   for (i = 0; i  GRUB_LVM_LABEL_SCAN_SECTORS; i++)
 {
--- grub2/disk/raid.c.orig  2008-08-16 03:00:30.0 -0700
+++ grub2/disk/raid.c   2008-08-16 06:07:46.0 -0700
@@ -358,12 +358,15 @@
   struct grub_raid_super_09 sb;
   struct grub_raid_array *p, *array = NULL;
 
-  grub_dprintf (raid, Scanning for RAID devices\n);
+  if (name[0]=='f'  name[1]=='d')
+return 0;
 
   disk = grub_disk_open (name);
   if (!disk)
 return 0;
 
+  grub_dprintf (raid, Scanning (%s) for RAID devices\n, name);
+
   /* The sector where the RAID superblock is stored, if available. */
   size = grub_disk_get_size (disk);
   sector = GRUB_RAID_NEW_SIZE_SECTORS(size);




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#495049: why is (fd0) hard-coded into the grub image?

[ian_bruce]

I should point out that when grub drops into the rescue prompt, it
coughs up the message error: unknown device fd0. Perhaps this is why
it goes into rescue mode?

My device.map file, as previously listed, does not contain an entry
for fd0, because the machine does not in fact have a floppy
drive. Wondering if this might help, I added the entry (fd0) /dev/fd0,
and reinstalled grub.

It did NOT help. Grub dropped into rescue mode as before, with the same
error message, but with the difference that this time the pc module
was not included in the core image, with the effect that the partition
table could not be read, rendering the machine completely unbootable. I
had to make use of a grub rescue CD to restart it.

I tried again, changing the device.map entry to (fd0) /dev/sda, to
see if that would make it happy. It didn't. It still went into rescue
mode, with the same error message, but this time chose to include the
pc module again. So I was back where I started, booting the system
with insmod normal.

Some questions suggest themselves:

-- why is there a hard-coded dependency on fd0, when neither
device.map nor grub.cfg mention it?

-- is the fd0 dependency the reason why grub drops into rescue mode?

-- why does adding an fd0 entry to device.map not resolve this
error?

-- why does adding an fd0 entry to device.map cause the pc module
to be omitted from the core image, when both device.map and grub.cfg
indicate that the system will be booted from a hard disk?

This problem seems to have some similarity with bug #494501, in that
something that is not really an error condition may be causing grub to
drop into rescue mode unnecessarily.

Finally, I suggest the following patch for clarifying exactly what
grub-install is doing, at least until some of these issues are
resolved.


--- grub-install2008-08-10 11:39:26.0 -0700
+++ /usr/sbin/grub-install  2008-08-13 17:21:46.0 -0700
@@ -259,11 +259,18 @@
 prefix_drive=`$grub_probe --target=drive --device ${grub_device}`
 fi

+echo $grub_mkimage --output=${grubdir}/core.img \
+--prefix=${prefix_drive}`make_system_path_relative_to_its_root 
${grubdir}`/ \
+$modules
+
 $grub_mkimage --output=${grubdir}/core.img \
 --prefix=${prefix_drive}`make_system_path_relative_to_its_root 
${grubdir}`/ \
 $modules || exit 1

 # Now perform the installation.
+echo $grub_setup --directory=${grubdir} --device-map=${device_map} \
+${install_device}
+
 $grub_setup --directory=${grubdir} --device-map=${device_map} \
 ${install_device} || exit 1




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#495049: why is (fd0) hard-coded into the grub image?

[ian_bruce]

On Fri, 15 Aug 2008 16:15:30 +0200
Felix Zielcke [EMAIL PROTECTED] wrote:

 I should point out that when grub drops into the rescue prompt, it
 coughs up the message error: unknown device fd0. Perhaps this is
 why it goes into rescue mode?
 
 Thanks for telling us.

I would have mentioned it before, except that it didn't seem relevant,
because I don't have a floppy disk, and neither device.map nor
grub.cfg refer to it.

 This is a bit different then:
 GRUB doestn't load normal.mod because there is no string normal in
 core.img

GRUB doesn't load normal.mod -- which is true.

there is no string normal in core.img -- which is also true.

because -- I didn't say that. You made it up.

 My device.map file, as previously listed, does not contain an entry
 for fd0, because the machine does not in fact have a floppy
 drive. Wondering if this might help, I added the entry
 (fd0) /dev/fd0, and reinstalled grub.
 
 I think you understand something wrong.
 The problem is that GRUB thinks fd0 is your bootdevice, even though your
 device.map is right.

-- which was the point of my first question:

 -- why is there a hard-coded dependency on fd0, when neither
 device.map nor grub.cfg mention it?

 -- is the fd0 dependency the reason why grub drops into rescue
 mode?
 
 Please stop assuming things if you don't understand how GRUB works.

If the problem is that GRUB thinks fd0 is your bootdevice, then
actually it seems that I understood the situation correctly.

 -- why does adding an fd0 entry to device.map not resolve this
 error?

If (fd0) is an unknown device, then why doesn't (fd0) /dev/fd0 make
it known?

 Finally, I suggest the following patch for clarifying exactly what
 grub-install is doing, at least until some of these issues are
 resolved.
 
 Please read man bash

I do so frequently.

 There's an -x option which does something like that.

Which also produces a lot of useless verbiage, when what we really want
to know is what modules grub-mkimage is including.

 I assume you don't know enough C to understand the whole sourcecode.

You assume wrong.

 Please let it to Robert and me trying to find out the `why?'.
 
 It is totally okay if you would your report just like this
 
 for me grub goes to rescue mode with unknown device fd0
 I only need to do
 insmod normal
 normal
 
 then the menu comes up and I can boot my system
 I have LVM on /

You didn't mention that adding (fd0) /dev/fd0 to device.map causes
the pc module to be omitted from the image. Would you have known that
if I hadn't mentioned it? Or do you claim that is the expected
behaviour?

 Don't tell us that probable XYZ is the problem and that it's easy to
 fix, if you are not sure that it is.

I told you that grub.cfg was not getting read because the module
normal was not loaded. I was absolutely sure of this, and I was
absolutely correct.

 And error messages like that unknown device fd0 are shown for a reason
 and so should be in your bug report _submission_. (that means not in the
 3rd mail but instead already in the 1st)

The grub rescue CD produces exactly the same error message. That doesn't
stop it from working. It's not always immediately clear which facts are
relevant, and which aren't.




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#495049: why is (fd0) hard-coded into the grub image?

[ian_bruce]

On Fri, 15 Aug 2008 18:36:49 +0200
Felix Zielcke [EMAIL PROTECTED] wrote:

 -- why does adding an fd0 entry to device.map not resolve this
 error?
 
 If (fd0) is an unknown device, then why doesn't (fd0) /dev/fd0
 make it known?
 
 Because the file is called device.map
 Which means map linux devices to grub devices.

-- which was my point.

I appreciate that English is a second language for you, but perhaps if
you were to review the distinction between does and does not, these
questions would seem more sensible.

 I assume you don't know enough C to understand the whole sourcecode.
 
 You assume wrong.
 
 I still assume that, because you even failed to choose the right
 severity of this report. The Debian documentation about this is very
 clear.

Yes, it says failure to boot == critical. That seems clear
enough. But perhaps you have a different interpretation?

 Honourly I don't have still any motivation at all for this report.
 
 Luckly I have already forwarded this to grub-devel and somebody had an
 idea.

Forget it, I'll fix it myself, and send the patch to upstream.

 So now you can proof how much your C knowledge is and your understanding
 of GRUB sourcecode.
 
 please add to disk/lvm.c to the mod_init function:
 grub_errno = GRUB_ERR_NONE;

This does nothing to explain why grub is worried about (fd0), when none
of its inputs mention any such device, as I pointed out several times
already.

But I suppose that your lofty arrogance prohibits you from addressing
such mundane questions.




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#495049: grub-pc: does not boot because module normal is not loaded

[ian_bruce]

On Thu, 14 Aug 2008 13:20:53 +0200
Felix Zielcke [EMAIL PROTECTED] wrote:

  After running grub-install and rebooting, grub drops into the
  grub rescue prompt. The pc, lvm, and ext2 modules are loaded,
  ls finds the root volume, and the variable root is set 
  appropriately.
 
 Only the variable root or the prefix too?

Both.

 Are sure that if you boot you only type
 
 insmod normal
 normal
 
 and then the menu shows? i.e. nothing before like set prefix or set
 root?

Only those two commands. Nothing else.

 That would be very weird if GRUB set it's variables right, but still
 fails to load grub.cfg by it's own.
 
 [EMAIL PROTECTED]:~$ strings /boot/grub/core.img|grep normal
 [EMAIL PROTECTED]:~$ 

# strings /boot/grub/normal.mod | grep grub.cfg
%s/grub.cfg
# 

The reason it doesn't load grub.cfg is because that filename is only found
in the normal module, which as I said, doesn't get loaded automatically,
but is located without problem with the insmod command.

 I think that core.img doestn't contain the string `normal' is just well
 normal, grub2 works fine for me, but I don't have LVM or RAID ;)

I don't know how the normal module is supposed to get loaded, but it's
clear that it IS supposed to, and that it isn't happening here.

I don't know if the problem is related to lvm, or if it's specific to AMD64,
or what.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]