Bug#1013063: w1retap: diff for NMU version 1.4.6-1.1

[Thomas Stewart]

On 18 Aug 2022, at 16:39, Adrian Bunk wrote:
> I've prepared an NMU for w1retap (versioned as 1.4.6-1.1) and uploaded 
> it to DELAYED/14. Please feel free to tell me if I should cancel it.

Thanks for that Adrain, it's been on my TODO list for far too long.

Kind Regards
--
Tom

Bug#1005972: sourced functions when run from set -e shells are suprising

[Thomas Stewart]

Package: initramfs-tools
Version: 0.140
Severity: minor

Dear Maintainer,

Half of the initramfs-tools hook scripts on my system use "set -e"[0].
However if /usr/share/initramfs-tools/scripts/functions is sourced it
does not handle errors correctly when called from a "set -e" shell, for
example the function "configure_networking" runs ipconfig and if it
times out it will exit non-zero. S the "for ROUNDTTT" loop does not
complete, further ipconfig invocations are not attempted and the calling
hook script exists before completion.

The hook scripts on my system (fsck, resume and xfs) that call
scripts/functions don't use "set -e". However some scripts in the
archive do call configure_networking from a "set -e" shell, eg aoe[2].

I ran into this when writing a new custom hook script for clevis and was
surprised by the current behaviour. I think all functions that are
sourced should be audited to handle "set -e" and all initramfs-tools
eventually modified to use "set -e".

Kind Regards
Tom

-- mkinitramfs hooks
/etc/initramfs-tools/hooks/:

/usr/share/initramfs-tools/hooks:
amd64_microcode
btrfs
cryptgnupg
cryptgnupg-sc
cryptkeyctl
cryptopensc
cryptpassdev
cryptroot
cryptroot-unlock
dmsetup
fsck
fuse
intel_microcode
keymap
klibc-utils
kmod
lvm2
mdadm
ntfs_3g
plymouth
reiserfsprogs
resume
thermal
thin-provisioning-tools
udev
xfs
zz-busybox

[0]
$ head -10 /usr/share/initramfs-tools/hooks/* | egrep "^=|-e"
==> /usr/share/initramfs-tools/hooks/amd64_microcode <==
==> /usr/share/initramfs-tools/hooks/btrfs <==
set -e
==> /usr/share/initramfs-tools/hooks/cryptgnupg <==
set -e
==> /usr/share/initramfs-tools/hooks/cryptgnupg-sc <==
set -e
==> /usr/share/initramfs-tools/hooks/cryptkeyctl <==
set -e
==> /usr/share/initramfs-tools/hooks/cryptopensc <==
set -e
==> /usr/share/initramfs-tools/hooks/cryptpassdev <==
set -e
==> /usr/share/initramfs-tools/hooks/cryptroot <==
==> /usr/share/initramfs-tools/hooks/cryptroot-unlock <==
==> /usr/share/initramfs-tools/hooks/dmsetup <==
==> /usr/share/initramfs-tools/hooks/fsck <==
==> /usr/share/initramfs-tools/hooks/fuse <==
set -e
==> /usr/share/initramfs-tools/hooks/intel_microcode <==
==> /usr/share/initramfs-tools/hooks/keymap <==
==> /usr/share/initramfs-tools/hooks/klibc-utils <==
==> /usr/share/initramfs-tools/hooks/kmod <==
#!/bin/sh -e
==> /usr/share/initramfs-tools/hooks/lvm2 <==
==> /usr/share/initramfs-tools/hooks/mdadm <==
set -eu
==> /usr/share/initramfs-tools/hooks/ntfs_3g <==
set -e
==> /usr/share/initramfs-tools/hooks/plymouth <==
set -e
==> /usr/share/initramfs-tools/hooks/reiserfsprogs <==
==> /usr/share/initramfs-tools/hooks/resume <==
==> /usr/share/initramfs-tools/hooks/thermal <==
==> /usr/share/initramfs-tools/hooks/thin-provisioning-tools <==
==> /usr/share/initramfs-tools/hooks/udev <==
#!/bin/sh -e
==> /usr/share/initramfs-tools/hooks/xfs <==
==> /usr/share/initramfs-tools/hooks/zz-busybox <==
set -e

[1] 
https://sources.debian.org/src/initramfs-tools/0.140/scripts/functions/?hl=236#L315
[2] https://sources.debian.org/src/aoetools/36-5/debian/local-top_aoe/

Bug#943343: fwupd: fwupd-refresh.service failed to start Refresh fwupd metadata and update motd.

[Thomas Stewart]

On 29 Jan 2021, at 03:29, Limonciello, Mario wrote:
> I'm unsure what to do here, it seems to me that there is a problem with 
> systemd using DynamicUser and sssd when the service uses dbus.
> Perhaps this should be re-assigned to systemd.

I will attempt to reproduce on a non freeipa joined machine.

Kind Regards
--
Tom

Bug#943343: fwupd: fwupd-refresh.service failed to start Refresh fwupd metadata and update motd.

[Thomas Stewart]

Yes, I'm using sssd against FreeIPA.

Tom


On 28 January 2021 02:12:11 GMT, "Limonciello, Mario" 
 wrote:
>Are you by chance using NFS mounted directories?  Or external entity
>for authentication such as LDAP or SSSD?

Bug#943343: fwupd: fwupd-refresh.service failed to start Refresh fwupd metadata and update motd.

[Thomas Stewart]

On 27 Jan 2021, at 14:18, Limonciello, Mario wrote:
> Can you check if fwupdmgr works as a standard user to talk to the daemon for 
> you?

As a normal user I can run "fwupdmgr --version" fine[0].

However if I amend the unit to run the above[1] the output stops before
daemon version[2].

Kind Regards
--
Tom

[0]
$ id
uid=1000(thomas) gid=1000(thomas) 
groups=1000(thomas),20(dialout),27(sudo),128(docker)
$
$ /usr/bin/fwupdmgr --version
client version: 1.5.5
compile-time dependency versions
gusb:   0.3.5

daemon version: 1.5.5
$

[1]
ExecStart=/usr/bin/fwupdmgr --version

[2]
Jan 27 14:24:38 systemd[1]: Starting Refresh fwupd metadata and update motd...
Jan 27 14:24:38 fwupdmgr[199579]: client version:1.5.5
Jan 27 14:24:38 fwupdmgr[199579]: compile-time dependency versions
Jan 27 14:24:38 fwupdmgr[199579]: gusb:0.3.5
Jan 27 14:24:38 fwupdmgr[199579]: Failed to connect to daemon: Exhausted all 
available authentication mechanisms (tried: EXTERNAL) (available: EXTERNAL)
Jan 27 14:24:38 systemd[1]: fwupd-refresh.service: Main process exited, 
code=exited, status=1/FAILURE
Jan 27 14:24:38 systemd[1]: fwupd-refresh.service: Failed with result 
'exit-code'.
Jan 27 14:24:38 systemd[1]: Failed to start Refresh fwupd metadata and update 
motd.

Bug#943343: fwupd: fwupd-refresh.service failed to start Refresh fwupd metadata and update motd.

[Thomas Stewart]

Hi,

I'm running testing/sid and have fwupd-1.5.5-2 installed. I have found
that when fwupd-refresh.service restarts either with the timer or
manually that if DynamicUser=yes is enabled then the service fails to
start[0]. When I remove DynamicUser from the unit it restarts fine.

I noticed that the unit has: CacheDirectory=fwupdmgr but the
metadata seems to live in /var/cache/fwupd[1].

After purging the package and removing /var/cache/fwup* /var/lib/fwupd
/var/cache/private/fwupd and reinstalling I can see the /var/cache dirs
created[2] but the service does not start.

When removing the "StandardError=null" directive from the unit I get an
additional error[3], which seems to indicate it's having trouble
talking to dbus.

Kind Regards
--
Tom

[0]
$ sudo systemctl restart fwupd-refresh.service
Job for fwupd-refresh.service failed because the control process exited with 
error code.
See "systemctl status fwupd-refresh.service" and "journalctl -xe" for details.
$

$ sudo journalctl -f 
Jan 27 10:09:30 systemd[1]: Starting Refresh fwupd metadata and update motd...
Jan 27 10:09:31 fwupdmgr[176638]: (fwupdmgr:176638): GLib-DEBUG: 10:09:31.089: 
setenv()/putenv() are not thread-safe and should not be used after threads are 
created
Jan 27 10:09:31 systemd[1]: fwupd-refresh.service: Main process exited, 
code=exited, status=1/FAILURE
Jan 27 10:09:31 systemd[1]: fwupd-refresh.service: Failed with result 
'exit-code'.
Jan 27 10:09:31 systemd[1]: Failed to start Refresh fwupd metadata and update 
motd.
$

[1]
$ find /var/cache/fw*
/var/cache/fwupd
/var/cache/fwupd/metadata.xmlb
/var/cache/fwupd/quirks.xmlb
/var/cache/fwupd/metainfo.xmlb
/var/cache/fwupdmgr
$

[2]
$ sudo ls -la /var/cache/fwupdmgr /var/cache/private/fwupdmgr
lrwxrwxrwx 1 root  root16 Jan 27 10:57 /var/cache/fwupdmgr -> 
private/fwupdmgr

/var/cache/private/fwupdmgr:
total 8
drwxr-xr-x 2 62803 62803 4096 Jan 27 10:57 .
drwx-- 3 root  root  4096 Jan 27 10:57 ..
$

[3]
Jan 27 11:09:30 fwupdmgr[189035]: Failed to connect to daemon: Exhausted all 
available authentication mechanisms (tried: EXTERNAL) (available: EXTERNAL)

Bug#968728: RFS: w1retap/1.4.4-4 [RC] -- Data logger for 1-Wire weather sensors

[Thomas Stewart]

Package: sponsorship-requests
Severity: important

Dear mentors,

As my existing sponsor seems very busy I am looking for a new sponsor
for my package "w1retap":

 * Package name: w1retap
   Version : 1.4.4-4
   Upstream Author : Jonathan Hudson 
 * URL : http://www.zen35309.zen.co.uk/wx/tech.html
 * License : Expat-Dallas-Semiconductor-Corporation and 
Expat-University-of-Newcastle-upon-Tyne and GPL-2+, GPL-2+, 
Expat-Dallas-Semiconductor-Corporation and GPL-2+, Expat
 * Vcs : https://salsa.debian.org/thomasdstewart-guest/w1retap
   Section : electronics

It builds those binary packages:

  w1retap-sqlite - Data logger for 1-Wire weather sensors (SQLite plugin)
  w1retap-pgsql - Data logger for 1-Wire weather sensors (PostgreSQL plugin)
  w1retap-odbc - Data logger for 1-Wire weather sensors (ODBC plugin)
  w1retap-mongo - Data logger for 1-Wire weather sensors (MongoDB plugin)
  w1retap-mysql - Data logger for 1-Wire weather sensors (MySQL plugin)
  w1retap-doc - Data logger for 1-Wire weather sensors (docs)
  w1retap - Data logger for 1-Wire weather sensors

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/w1retap/

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/w/w1retap/w1retap_1.4.4-4.dsc

Changes since the last upload:

 w1retap (1.4.4-4) unstable; urgency=medium
 .
   * Refresh dquilt patches
   * Rename fix-w1pgsql-snprintf-timet.patch to fix-timet.patch
   * Add timet fixes for w1file, w1pgsql, w1util and w1xml
   * Update patch descriptions
   * Fix lintian autotools-pkg-config-macro-not-cross-compilation-safe
   * Add fix-autotools-libxml2.patch (Closes: #949511)
   * Fix gcc-10 build errors (Closes: #957921)
   * Fix owerr spelling
   * Replace build dependency asciidoc with asciidoc-base
   * Update standards from 3.9.8 to 4.5.0
   * Fix lintian init.d-script-should-always-start-service
   * Upgrade debhelper compat from 10 to 13
   * Add Vcs-Git and Vcs-Browser fields to control file
   * Fix lintian skip-systemd-native-flag-missing-pre-depends
   * Add Rules-Requires-Root to control
   * Added salsa-ci.yml
   * Fix man page spelling
   * Add Documentation key to service
   * Add systemd service hardening-features
   * Make copyright format URL https
   * Update lintian-overrides
   * Add some autopkgtest tests
   * Remove training whitespace from changelog
   * Fix lintian debian-rules-uses-as-needed-linker-flag
   * Fix lintian upstream-metadata-file-is-missing

Kind Regards
--
Tom

Bug#945404: hard coded workaround for 945404

[Thomas Stewart]

Hi,

As a nasty workaround I created /etc/grub.d/06_debian_theme_fix[0] with
hard coded content. I've got a separate LUKS1 crypted /boot, hence
"(crypto0)", update with appropriate grub device name for /boot (eg
hd0,1) and remember to delete this when a proper fix appears. If
/boot/grub/.background_cache.png resides on a LUKS2 this will not work.

Kind Regards
--
Tom

[0]
"""
#!/bin/sh
set -e

cp /usr/share/images/desktop-base/desktop-grub.png 
/boot/grub/.background_cache.png

cat << EOF
background_image (crypto0)/grub/.background_cache.png
set color_normal=white/black
set color_highlight=black/white
set menu_color_normal=white/black
set menu_color_highlight=black/white
EOF
"""

Bug#949511: w1retap: FTBFS with libxml2 not shipping xml2-config

[Thomas Stewart]

Thanks, this is fixed in https://salsa.debian.org/thomasdstewart-guest/w1retap. 
I'm just waiting for my mentor to upload. 

Kind Regards 
Tom

Bug#950793: blhc: Reports missing -D_FORTIFY_SOURCE=2 for libtool linking

[Thomas Stewart]

Package: blhc
Version: 0.11-1
Severity: normal

Hi,

I've been trying to fix a dpkg-buildflags-missing CPPFLAGS lintian issue
in the w1retap package, the blhc output on the build log is:

CPPFLAGS missing (-D_FORTIFY_SOURCE=2): libtool: link: (cd .libs && gcc -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wall -c -fno-builtin "w1retapS.c")

However looking at the build log snippet[0] the full command is actually
a call to libtool in link mode. This libtool invocation generates a new
S.c file to generate dlsyms information. Looking at the internals of a
generated libtool[1], it's basing the gcc args on LTCFLAGS.

When libtool is generated it bases its LTCFLAGS from CFLAGS[2]. Looking
at the dpkg-buildflags hardening the -D_FORTIFY_SOURCE=2 flag is for
CPPFLAGS rather than CFLAGS[3].

If I rebuild[4] adding qa=+canary to DEB_BUILD_MAINT_OPTIONS I can see
that the canary CFLAGS get added to the libtool call and to the same gcc
call for w1retapS.c for dlsyms generation.

I suspect that blhc is erroneously reporting this.

Kind Regards
Tom

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (800, 'testing'), (700, 'unstable'), (600, 'experimental'), (500, 
'unstable-debug'), (500, 'testing-debug'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: armel, armhf, i386

Kernel: Linux 5.4.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages blhc depends on:
ii  libdpkg-perl  1.19.7

blhc recommends no packages.

blhc suggests no packages.

-- debconf-show failed

-- footnotes
[0]
/bin/bash ../libtool  --tag=CC   --mode=link gcc  -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wall -m
odule -Wl,--export-dynamic -lgmodule-2.0 -pthread -lglib-2.0 -lxml2 
-Wl,-z,relro -Wl,-z,now -Wl,--as-needed -Wl,--disable-new-dtags -o libw1xml.la 
-rpath /usr/li
b/x86_64-linux-gnu/w1retap libw1xml_la-w1xml.lo  -lxml2 -lrt -lm 
libtool: link: gcc -shared  -fPIC -DPIC  .libs/w1csv.o   -lgmodule-2.0 
-lglib-2.0 -lxml2 -lrt -lm  -g -O2 -fstack-protector-strong 
-Wl,--export-dynamic -pthread 
-Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,--as-needed -Wl,--disable-new-dtags   
-pthread -Wl,-soname -Wl,libw1csv.so.0 -o .libs/libw1csv.so.0.0.0
libtool: link: gcc -shared  -fPIC -DPIC  .libs/w1file.o   -lgmodule-2.0 
-lglib-2.0 -lxml2 -lrt -lm  -g -O2 -fstack-protector-strong 
-Wl,--export-dynamic -pthread
 -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,--as-needed -Wl,--disable-new-dtags   
-pthread -Wl,-soname -Wl,libw1file.so.0 -o .libs/libw1file.so.0.0.0
libtool: link: gcc -shared  -fPIC -DPIC  .libs/libw1xml_la-w1xml.o   
-lgmodule-2.0 -lglib-2.0 -lxml2 -lrt -lm  -g -O2 -fstack-protector-strong 
-Wl,--export-dynam
ic -pthread -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,--as-needed 
-Wl,--disable-new-dtags   -pthread -Wl,-soname -Wl,libw1xml.so.0 -o 
.libs/libw1xml.so.0.0.0
libtool: link: (cd ".libs" && rm -f "libw1file.so.0" && ln -s 
"libw1file.so.0.0.0" "libw1file.so.0")
libtool: link: (cd ".libs" && rm -f "libw1csv.so.0" && ln -s 
"libw1csv.so.0.0.0" "libw1csv.so.0")
libtool: link: (cd ".libs" && rm -f "libw1file.so" && ln -s 
"libw1file.so.0.0.0" "libw1file.so")
libtool: link: (cd ".libs" && rm -f "libw1csv.so" && ln -s "libw1csv.so.0.0.0" 
"libw1csv.so")
libtool: link: ar cru .libs/libw1file.a  w1file.o
ar: `u' modifier ignored since `D' is the default (see `U')
libtool: link: ranlib .libs/libw1file.a
libtool: link: ar cru .libs/libw1csv.a  w1csv.o
ar: `u' modifier ignored since `D' is the default (see `U')
libtool: link: ranlib .libs/libw1csv.a
libtool: link: (cd ".libs" && rm -f "libw1xml.so.0" && ln -s 
"libw1xml.so.0.0.0" "libw1xml.so.0")
libtool: link: (cd ".libs" && rm -f "libw1xml.so" && ln -s "libw1xml.so.0.0.0" 
"libw1xml.so")
libtool: link: ( cd ".libs" && rm -f "libw1file.la" && ln -s "../libw1file.la" 
"libw1file.la" )
libtool: link: ( cd ".libs" && rm -f "libw1csv.la" && ln -s "../libw1csv.la" 
"libw1csv.la" )
libtool: link: ar cru .libs/libw1xml.a  libw1xml_la-w1xml.o
/bin/bash ../libtool  --tag=CC   --mode=link gcc  -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wall -r
dynamic  -Wl,--export-dynamic -lgmodule-2.0 -pthread -lglib-2.0  -Wl,-z,relro 
-Wl,-z,now -Wl,--as-needed -Wl,--disable-new-dtags -o w1retap w1retap-w1retap.o 
w1r
etap-w1conf.o w1retap-w1util.o w1retap-w1sensors.o "-dlopen" libw1file.la  
-L./libusblinux300/.libs -L./libusblinux300 -lowfat -lw1common -lm -lxml2 -lrt 
-lm 
ar: `u' modifier ignored since `D' is the default (see `U')
libtool: link: ranlib .libs/libw1xml.a
libtool: link: ( cd ".libs" && rm -f "libw1xml.la" && ln -s "../libw1xml.la" 
"libw1xml.la" )
libtool: link: rm -f .libs/w1retap.nm .libs/w1retap.nmS .libs/w1retap.nmT

Bug#933945: bc: Carriage return stopped working between calculations

[Thomas Stewart]

Hi,

I performed a git bisect compiling[1] both readline and bc from
upstream[0] and found the commit (8e6ccd0) that introduced the issue.
However this commit is the entire diff from "readline-7.0 patch 5" to
"readline-8.0 distribution sources and documentation".

I also found that if I compiled without readline or libedit support the
behaviour reverted to normal, albeit without any readline history.

Kind Regards
--
Tom

[0]
http://git.savannah.gnu.org/cgit/readline.git
https://git.savannah.gnu.org/git/readline.git
https://ftp.gnu.org/gnu/bc/

[1] compile.sh
#!/bin/bash -eux
cd /home/thomas/scratch/bctest/readline
rm -r -f /home/thomas/scratch/bctest/readline/i
./configure --prefix=`pwd`/i
make -j 8
make install

cd /home/thomas/scratch/bctest
wget -c https://ftp.gnu.org/gnu/bc/bc-1.07.1.tar.gz
rm -r -f /home/thomas/scratch/bctest/bc-1.07.1
tar xf bc-1.07.1.tar.gz
cd bc-1.07.1/
export CFLAGS="-I/home/thomas/scratch/bctest/readline/i/include/"
export LDFLAGS="-L/home/thomas/scratch/bctest/readline/i/lib/"
./configure --prefix=`pwd`/i 
--with-readline=/home/thomas/scratch/bctest/readline/i/
make -j 8
make install

echo
echo "LD_LIBRARY_PATH=\"/home/thomas/scratch/bctest/readline/i/lib\" 
/home/thomas/scratch/bctest/bc-1.07.1/i/bin/bc"

Bug#933945: bc: Carriage return stopped working between calculations

[Thomas Stewart]

Package: bc
Version: 1.07.1-2+b2
Severity: normal

Dear Maintainer,

   * What led up to the situation?

Instead of a normal calculator I use bc for quick calculations. Often
between different calculations I press return a few times to space
things out (and to focus the mind).


   * What outcome did you expect instead?

It seems this functionality does not work anymore. Historically if you
run bc and press enter, newlines are shown on screen scrolling the
output up one line. However now pressing enter does nothing (unless you
are doing an actual calculation).

I expect to be able to press return at a bc(1) prompt and for a newline
to scroll the output up.


   * What I found out.

I think I have narrowed the issue down to the libreadline.so.7 to
libreadline.so.8 update that hit the mirrors on the 22nd July 2019.

If two chroots are created from the 22nd July, one at 03:59 and one at
08:59 with the following commands:
$ sudo debootstrap --variant=minbase --include=bc bullseye 
bullseye-20190722T035916Z 
https://snapshot.debian.org/archive/debian/20190722T035916Z/
$ sudo debootstrap --variant=minbase --include=bc bullseye 
bullseye-20190722T085948Z 
https://snapshot.debian.org/archive/debian/20190722T085948Z/

The first chroot works as expected however the second does not, I tested
as below:
$ sudo chroot bullseye-20190722T035916Z/ bc
$ sudo chroot bullseye-20190722T085948Z/ bc

Looking at the libraries linked and comparing them shows that
libreadline changed version from 7 to 8.
$ ldd bullseye-20190722T035916Z/usr/bin/bc | awk '{print $1}' > 1
$ ldd bullseye-20190722T085948Z/usr/bin/bc | awk '{print $1}' > 2
$ diff -u 1 2
--- 1   2019-08-02 13:45:33.594849157 +0100
+++ 2   2019-08-02 13:45:36.334827465 +0100
@@ -1,5 +1,5 @@
 linux-vdso.so.1
-libreadline.so.7
+libreadline.so.8
 libncurses.so.6
 libtinfo.so.6
 libc.so.6

I'm not sure what to try next.

Kind Regards
--
Tom

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (800, 'testing'), (700, 'unstable'), (600, 'experimental'), (500, 
'unstable-debug'), (500, 'testing-debug'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: armel, armhf, i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages bc depends on:
ii  libc6 2.28-10
ii  libncurses6   6.1+20190713-1
ii  libreadline8  8.0-2
ii  libtinfo6 6.1+20190713-1

bc recommends no packages.

bc suggests no packages.

-- no debconf information

Bug#906548: chromium: Chromium crashes with SEGV on startup on RPI

[Thomas Stewart]

On 20 Dec 2018, at 17:10, Patrick Häcker wrote:
> you wrote on the upstream bug tracker that you have resolved the issue with 
> an 
> upgrade and version 70.0.3538.67-2. Did you upgrade to testing? Maybe you can 
> elaborate on your working setup.
> 
> I upgraded to testing, but to no avail. As there is no testing or unstable 
> armhf version of chromium as of today, I wouldn't expect a working chromium 
> in 
> testing/unstable on armhf if it's really a compiler issue.

Hi Patrick,

I'm running testing/unstable on a Raspberry Pi. I tend to dist-upgrade
every few months. It was one of these upgrades that fixed the issue when
version 70.0.3538.67-2 was installed. I then reported it on the upstream
tracker.

I read your email a few weeks ago and also saw that no version was
installable. I looked at the buildd logs at the time but could not see
anything obvious. Grabbing a version from snapshot.debian.org may have
been an option.

A compiler issue was only a guess because the compiler changed
between broken and working versions. Building for 32bit is hard. I
was unable to build my own version, I suspect by adding full debugging
symbols pushed the limits of gold with something this big. I didn't try 
compiling
70.0.3538.67-2 with an older compiler or compiling a broken version with
a newer compiler.

I've just run a dist-upgrade and 72.0.3626.7-6 installed and works.

Kind Regards
--
Tom

Bug#906548: chromium: Chromium crashes with SEGV on startup on RPI

[Thomas Stewart]

Hi,

I have reported this upstream:
https://bugs.chromium.org/p/chromium/issues/detail?id=877480

Kind Regards
--
Tom

Bug#906548: chromium: Chromium crashes with SEGV on startup on RPI

[Thomas Stewart]

Hi,

I don't think it is related to a minor update, it seemed to break when
going from version 67 to 68.

I tried some packages from snapshot and it works with: 
https://snapshot.debian.org/package/chromium-browser/67.0.3396.87-1/

and crashes with:
https://snapshot.debian.org/package/chromium-browser/68.0.3440.17-1/

(I have not tried 69 as it currently ftbfs on armhf:
https://buildd.debian.org/status/fetch.php?pkg=chromium-browser=armhf=69.0.3497.12-1=1532873819=0)

Kind Regards
--
Tom

Bug#906548: chromium: Chromium crashes with SEGV on startup in Stable on RPI

[Thomas Stewart]

Package: chromium
Version: 68.0.3440.75-2
Followup-For: Bug #906548

Hi,

I run selenium, chromium-driver and chromium on my Raspberry Pi and I
think I have run into the same issue as my setup stopped working after
an update. It is a testing/unstable system and like Patrick has some
Raspbian packages installed, namely raspberrypi-bootloader and
raspberrypi-kernel. So it is FrankenDebian[0] however everything else is
Debain.

My system has all the chromium depends installed[2].

I ran "chromium --debug" with symbols which gives a slightly more
readable backtrace[1]. 

Kind Regards
Tom

[0]
$ aptitude search '~S~i!~Odebian'
i   raspberrypi-bootloader  
 - Raspberry Pi bootloader
i A raspberrypi-kernel  
 - Raspberry Pi bootloader
$

[1]
$ chromium --debug
# Env:
# LD_LIBRARY_PATH=
#PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
#GTK_PATH=
#  CHROMIUM_FLAGS= --show-component-extension-options 
--ignore-gpu-blacklist --no-default-browser-check --disable-pings 
--media-router=0 --enable-remote-extensions
/usr/bin/gdb /usr/lib/chromium/chromium -x /tmp/chromiumargs.BefADJ
GNU gdb (Debian 8.1-4) 8.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/lib/chromium/chromium...Reading symbols from 
/usr/lib/debug/.build-id/43/f92dc2a09900348561aa51a915a8ec6cf8d852.debug...done.
done.
(gdb) run
Starting program: /usr/lib/chromium/chromium --show-component-extension-options 
--ignore-gpu-blacklist --no-default-browser-check --disable-pings 
--media-router=0 --enable-remote-extensions --single-process 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
[New Thread 0x6fe16170 (LWP 8809)]
[New Thread 0x6f4ff170 (LWP 8814)]
[New Thread 0x6eaff170 (LWP 8815)]
Gtk-Message: 12:41:57.841: Failed to load module "canberra-gtk-module"
Gtk-Message: 12:41:58.005: Failed to load module "canberra-gtk-module"
[New Thread 0x6d7fa170 (LWP 8826)]
[New Thread 0x6cdff170 (LWP 8827)]
[New Thread 0x6c3ff170 (LWP 8828)]
[New Thread 0x6e228170 (LWP 8829)]
[8802:8802:0822/124203.487048:ERROR:default_network_context_params.cc(60)] 
Cannot use V8 Proxy resolver in single process mode.
[New Thread 0x6b7ff170 (LWP 8830)]
[New Thread 0x6affe170 (LWP 8831)]
[New Thread 0x6a7fd170 (LWP 8832)]
[New Thread 0x69ffc170 (LWP 8833)]
[New Thread 0x697fb170 (LWP 8834)]
[New Thread 0x68ffa170 (LWP 8835)]
[New Thread 0x687f9170 (LWP 8836)]
[New Thread 0x67ff8170 (LWP 8837)]
[New Thread 0x677f7170 (LWP 8838)]
[New Thread 0x66ff6170 (LWP 8839)]
[New Thread 0x667f5170 (LWP 8840)]
[New Thread 0x65ff4170 (LWP 8841)]
[New Thread 0x657f3170 (LWP 8842)]
[New Thread 0x64ff2170 (LWP 8843)]
[New Thread 0x647f1170 (LWP 8844)]
[New Thread 0x63ff0170 (LWP 8845)]
[New Thread 0x6047b170 (LWP 8853)]
[New Thread 0x5fc7a170 (LWP 8854)]
[New Thread 0x5f479170 (LWP 8923)]
[New Thread 0x5ec78170 (LWP 8949)]
[New Thread 0x5e477170 (LWP 8950)]
[New Thread 0x5dc76170 (LWP 8951)]
[New Thread 0x5d475170 (LWP 8952)]
[New Thread 0x5c8ff170 (LWP 9193)]
[New Thread 0x5c0fe170 (LWP 9194)]
[8802:9194:0822/124238.295911:ERROR:object_proxy.cc(616)] Failed to call 
method: org.freedesktop.Notifications.GetCapabilities: object_path= 
/org/freedesktop/Notifications: org.freedesktop.DBus.Error.ServiceUnknown: The 
name org.freedesktop.Notifications was not provided by any .service files
[8802:8802:0822/124238.722603:ERROR:default_network_context_params.cc(60)] 
Cannot use V8 Proxy resolver in single process mode.
[New Thread 0x5b8fd170 (LWP 9196)]
[Thread 0x6047b170 (LWP 8853) exited]
[New Thread 0x6047b170 (LWP 9197)]
[Thread 0x6047b170 (LWP 9197) exited]
[Thread 0x5f479170 (LWP 8923) exited]
[New Thread 0x5f479170 (LWP 9210)]
[New Thread 0x5b0fc170 (LWP 9211)]
[New Thread 0x5a84e170 (LWP 9215)]
[New Thread 0x5a04d170 (LWP 9216)]
[New Thread 0x54aa9170 (LWP 9219)]

Thread 1 "chromium" received signal SIGSEGV, Segmentation fault.
0x5523256c in void std::vector, 
std::allocator > 
>::_M_insert_aux 
>(__gnu_cxx::__normal_iterator*, 
std::vector, 
std::allocator > > >, 
std::pair&&) ()
(gdb) bt
#0  0x5523256c in void std::vector, 
std::allocator > 
>::_M_insert_aux 
>(__gnu_cxx::__normal_iterator*, 

Bug#850445: w1retap: fails to start: cannot open shared object

[Thomas Stewart]

Package: w1retap
Version: 1.4.4-2
Severity: important


Hi,

When I uploaded w1retap-1.4.4-2 to mentors.d.n the package worked.
However I recently found out that something changed which breaks the
package. It now fails to run and gives the error[0] "libw1serial.so:
cannot open shared object file".

I still had a copy of the deb I built so I compared my version against
the version compiled on the buildds with diffoscope[1]. The main
difference was that the dynamic flag RPATH changed to RUNPATH.

I didn't understand why this would break the application. The main
application (/usr/bin/w1retap) was able to load libw1common.so from it's
RUNPATH (/usr/lib/i386-linux-gnu/w1retap/), however when libw1common.so
tried to load libw1serial.so it failed to find it.

The code uses g_module_open() to try to load the object:
http://sources.debian.net/src/w1retap/1.4.4-2/src/libusblinux300/acquire.c/#L25
(acquire.c is compiled to acquire.lo, archived into libw1common.la and
thus libw1common.so)

I found a number of articles that reference RPATH and RUNPATH:
https://wiki.debian.org/RpathIssue
http://blog.qt.io/blog/2011/10/28/rpath-and-runpath/
https://blog.feabhas.com/2014/04/static-and-dynamic-libraries-on-linux/
https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1253638

It seems that both RPATH and RUNPATH specify paths that the system
should look in to find libraries without the need to set
LD_LIBRARY_PATH. However the main difference is that RPATH is the first
place searched before looking in LD_LIBRARY_PATH, hence if RPATH is used
there is no way to override that path with LD_LIBRARY_PATH. I assume for
this reason RPATH was deprecated some years ago. A further subtlety is
that if RUNPATH is used in the main binary then this path is not
searched when looking for sub-libraries (called transitive dependencies
in the above Ubuntu bug), this is different the RPATH behaviour. The
code for this seems to be around line 2278 in elf/dl-load.c of glibc:
http://sources.debian.net/src/glibc/2.24-8/elf/dl-load.c/#L2280

I was able to verify the above by taking my working binary and running
chrpath(1) on it to change the RPATH to RUNPATH. After this test it
stopped working in the same way.

However it was still unclear why my binary had RPATH rather than
RUNPATH. I also found out that when I rebuilt on the same machine the
binaries now had RUNPATH. After a little searching I found out that when
binutils-2.27.51.20161116-2 was released (which closed #835859) it
changed the default setting for the linker to enable the new dtags
behaviour which uses RUNPATH rather than RPATH. This seems like a good
idea and was implemented in this patch:
http://sources.debian.net/src/binutils/2.27.90.20161231-1/debian/patches/ld-new-dtags-by-default.diff/

Once I knew this I was able to rebuild with LD_FLAGS to disable this by
adding "export DEB_LDFLAGS_MAINT_APPEND = -Wl,--disable-new-dtags" to
the rules. After this it started producing RPATH binaries again.
Obviously relying on the old behaviour is not ideal however it does fix
the issue.

I will upload an updated package to mentors.d.n and ask my sponsor to
upload.

Kind Regards
--
Tom


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (400, 'testing'), (300, 'unstable'), (200, 'experimental')
Architecture: i386 (i686)

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

Versions of packages w1retap depends on:
ii  adduser  3.115
ii  init-system-helpers  1.46
ii  libc62.24-8
ii  libglib2.0-0 2.50.2-2
ii  libusb-0.1-4 2:0.1.12-30
ii  libxml2  2.9.4+dfsg1-2.1
ii  lsb-base 9.20161125
ii  ruby 1:2.3.3

Versions of packages w1retap recommends:
pn  w1retap-doc  

w1retap suggests no packages.

-- Configuration Files:
/etc/w1retap-sensors.dat changed [not included]

-- no debconf information

-- footnotes
[0]
$ w1retap -1 -v
w1retap v1.4.4 (c) 2005-2015 Jonathan Hudson
Built: 1479212267 gcc 6.2.1 20161119
Plugins:
 0: c [0x5635f4a88ba0] /usr/lib/x86_64-linux-gnu/w1retap/libw1file.so => 
/etc/w1retap-sensors.dat
 1: l [0x5635f4a88ba0] /usr/lib/x86_64-linux-gnu/w1retap/libw1file.so => 
/var/lib/w1retap/w1retap.log
Log file is /var/lib/w1retap/.w1retap.dat
Interval 0s, cycle -1s
Release i/face 0
Can't open the device library libw1serial.so
System returned:
libw1serial.so: cannot open shared object file: No such file or directory
This is typically a build dependency or installation error
$ 

[1]
$ diffoscope w1retap_1.4.4-2_i386.deb.working w1retap_1.4.4-2_i386.deb.broken
||
  100%  Time: 0:00:07
--- w1retap_1.4.4-2_i386.deb.working
+++ w1retap_1.4.4-2_i386.deb.broken
├── file list
│ @@ -1,3 +1,3 @@
│  -rw-r--r--   0004 2016-11-15 

Bug#843857: w1retap: FTBFS on mips and mipsel: braces around scalar initializer [-Werror]

[Thomas Stewart]

Hi Daniel,

Thanks for the report, patch and testing! I'm going to send this
upstream, update the w1retap package and ask my sponsor to upload the
new package.

Thanks :-)

Kind Regards
--
Tom

Bug#844144: w1retap: FTBFS on mips and mipsel: braces around scalar initializer [-Werror]

[Thomas Stewart]

Hi Daniel,

Thanks for the report, patch and testing! I'm going to send this
upstream, update the w1retap package and ask my sponsor to upload the
new package.

Thanks :-)

Kind Regards
--
Tom

Bug#844144: w1retap: FTBFS: ld: cannot find -lowfat

[Thomas Stewart]

Hi Lucas,

Thanks for the report. I don't think this is TSX related, I think it's a
parallel build error.

Also the owfat referenced is not related to libowfat. The former being a
internal library built as part of w1retap and the latter being a
reimplementation of libdjb.

To replicate the build issue I created a 32 core KVM virtual machine[0]
on a host[1] and did a normal build of the package. This resulted in
what looks like the same error as your report[2].

When looking at src/libusblinux300/Makefile.am, Sam Morris
 noticed that it does not include libowfat.a in all the
_DEPENDENCIES lines. After I created a patch[3] to add this, the build
on the virtual machine started succeeding.

This does not prove it's not TSX related, however this does fix an
issue. So I'm going to send this upstream and ask my sponsor to upload
an update as well. After this is done it would be good if you could
retest on a m4.16xlarge instance again.

Thanks :-)

Kind Regards
--
Tom

[0] /proc/cpuinfo on vm
model   : 42
model name  : Intel Xeon E312xx (Sandy Bridge)
stepping: 1

[1] /proc/cpuinfo on host
model   : 62
model name  : Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz
stepping: 4

[2]
libtool: link: gcc -g -O2 -fdebug-prefix-map=/root/w1retap-1.4.4=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wall -rdynamic 
-Wl,--export-dynamic -pthread -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,--as-needed 
-o .libs/thermoms thermoms.o findtype.o thermo21.o  -lgmodule-2.0 -lglib-2.0 
-L. -lowfat /root/w1retap-1.4.4/src/libusblinux300/.libs/libw1common.so -lxml2 
-lrt -lm -pthread -Wl,-rpath -Wl,/usr/lib/x86_64-linux-gnu/w1retap
libtool: link: gcc -shared  -fPIC -DPIC  .libs/ds2480ut.o .libs/linuxlnk.o 
.libs/owllu.o .libs/ownetu.o .libs/owsesu.o .libs/owtrnu.o   -Wl,-rpath 
-Wl,/root/w1retap-1.4.4/src/libusblinux300/.libs -Wl,-rpath 
-Wl,/usr/lib/x86_64-linux-gnu/w1retap -L. 
/root/w1retap-1.4.4/src/libusblinux300/.libs/libw1common.so -lxml2 -lrt -lm  -g 
-O2 -fstack-protector-strong -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,--as-needed   
-pthread -Wl,-soname -Wl,libw1serial.so.0 -o .libs/libw1serial.so.0.0.0
libtool: link: gcc -g -O2 -fdebug-prefix-map=/root/w1retap-1.4.4=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wall -rdynamic 
-Wl,--export-dynamic -pthread -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,--as-needed 
-o .libs/ds192xtest ds192xtest-ds192x.o  -lgmodule-2.0 -lglib-2.0 -L. -lowfat 
/root/w1retap-1.4.4/src/libusblinux300/.libs/libw1common.so -lxml2 -lrt -lm 
-pthread -Wl,-rpath -Wl,/usr/lib/x86_64-linux-gnu/w1retap
libtool: link: gcc -g -O2 -fdebug-prefix-map=/root/w1retap-1.4.4=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wall -rdynamic 
-Wl,--export-dynamic -pthread -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,--as-needed 
-o .libs/coupler coupler.o findtype.o  -lgmodule-2.0 -lglib-2.0 -L. -lowfat 
/root/w1retap-1.4.4/src/libusblinux300/.libs/libw1common.so -lxml2 -lrt -lm 
-pthread -Wl,-rpath -Wl,/usr/lib/x86_64-linux-gnu/w1retap
/usr/bin/ld: cannot find -lowfat
collect2: error: ld returned 1 exit status

[3]
--- w1retap-1.4.4.orig/src/libusblinux300/Makefile.am
+++ w1retap-1.4.4/src/libusblinux300/Makefile.am
@@ -31,92 +31,92 @@ libowfat_a_SOURCES = mbappreg.c mbeprom.
ds192x.c hbuv.c hbht.c
 
 w1find_SOURCES = w1find.c findtype.c
-w1find_DEPENDENCIES = libw1common.la
+w1find_DEPENDENCIES = libw1common.la libowfat.a
 w1find_LDADD = -L. -lowfat -lw1common -lm
 w1find_LDFLAGS = -rdynamic  $(GLIB_LIBS)
 
 braybaro_SOURCES = braybaro.c atod26.c screenio.c findtype.c
-braybaro_DEPENDENCIES = libw1common.la
+braybaro_DEPENDENCIES = libw1common.la libowfat.a
 braybaro_LDADD = -L. -lowfat -lw1common -lm
 braybaro_LDFLAGS = -rdynamic  $(GLIB_LIBS)
 
 temp_SOURCES = temp.c findtype.c
-temp_DEPENDENCIES = libw1common.la
+temp_DEPENDENCIES = libw1common.la libowfat.a
 temp_LDADD = -L. -lowfat -lw1common -lm
 temp_LDFLAGS = -rdynamic  $(GLIB_LIBS)
 
 gethumd_SOURCES = gethumd.c findtype.c
-gethumd_DEPENDENCIES = libw1common.la
+gethumd_DEPENDENCIES = libw1common.la libowfat.a
 gethumd_LDADD = -L. -lowfat -lw1common -lm
 gethumd_LDFLAGS = -rdynamic  $(GLIB_LIBS)
 
 coupler_SOURCES = coupler.c findtype.c
-coupler_DEPENDENCIES = libw1common.la
+coupler_DEPENDENCIES = libw1common.la libowfat.a
 coupler_LDADD = -L. -lowfat -lw1common -lm
 coupler_LDFLAGS = -rdynamic  $(GLIB_LIBS)
 
 humids_SOURCES = humid.c
-humids_DEPENDENCIES = libw1common.la
+humids_DEPENDENCIES = libw1common.la libowfat.a
 humids_LDADD = -L. -lowfat -lw1common -lm
 humids_LDFLAGS = -rdynamic  $(GLIB_LIBS)
 
 setds2409_SOURCES = setds2409.c
-setds2409_DEPENDENCIES = libw1common.la
+setds2409_DEPENDENCIES = libw1common.la libowfat.a
 setds2409_LDADD = -L. -lowfat -lw1common -lm
 setds2409_LDFLAGS = -rdynamic  $(GLIB_LIBS)
 
 counter_SOURCES = counter.c findtype.c
-counter_DEPENDENCIES = libw1common.la
+counter_DEPENDENCIES = libw1common.la libowfat.a
 counter_LDADD = -L. -lowfat 

Bug#791724: RFS: w1retap/1.4.4-1 [ITP] -- Data logger for 1-Wire weather sensors

[Thomas Stewart]

Hi Gianfranco,

Thanks again for another review and the suggestions you made! I have
made a number of the fixes you suggested and have tried to explain my
choices below. I have just uploaded a fresh version of the package to
http://mentors.debian.net/package/w1retap. 

If you have any further comments they would really be appreciated,
alternatively if you think that the package is ready would you be
willing to sponsor the upload?


On 15 Oct 2016, at 11:10, Gianfranco Costamagna wrote:
> >The plugin packages contain .so files, the --noscripts option stops an
> >ldconfig run when installing. Without it I get a lintian useless
> >ldconfig run warnings.
> 
> well, I usually don't care about such warnings, but I wonder if somewhen
> in the future the package starts shipping an external shared library
> and ldconfig won't be run because of this.
> (I'm not asking to change this, just wondering about a possible future
> side effect, and please note I have no clues about the possibilities
> of this scenario, and probably lintian will complain in such case)
> 

I think w1retap is in maintenance mode, so this is currently unlikely.
However I'll keep it in mind in the future.


> >I did run all of the above and found some issues. Some of the issues
> >seemed to be more related to actual upstream development rather than
> >packaging. Most notably predicable file creation in /tmp, which is
> >fixed in the above mentioned movetmp.patch. Did you spot anything
> >else that needing fixing?
> 
> mmm movetmp.patch... 
> 
> -w1->tmpname = "/tmp/.w1retap.dat";
> +w1->tmpname = "/var/lib/w1retap/.w1retap.dat";
> 
> I don't think using /var/lib for tmp stuff is something 
> 
> this is a log, isn't /var/log something better?
> (with some logrotate stuff)
>

The /var/lib/w1retap directory contains the location for the default
w1retap data log file. If I were to record the data to PostgreSQL or
MySQL the actual data would end up somewhere else under /var/lib too.
Given that the data will be sensor readings (temperature, windspeed,
rainfall, etc) I would not expect this data to be rotated.

The ".w1retap.dat" file contains the last successful data reading. This
data can then be read by various other programs or scripts that only
want current readings (eg the current outside temperature). I think /tmp
is not the correct place to store it and I think that it does not fit
well into /var/log either. This is why I changed it to /var/lib.

 
> additional little points:
> - please enable hardening if possible, according to blhc 
> http://debomatic-amd64.debian.net/distribution#unstable/w1retap/1.4.4-1/blhc
> somebody is overriding flags
> 
> - 
> DPKG_EXPORT_BUILDFLAGS = 1
> include /usr/share/dpkg/default.mk
> 
> 
> ^^ this is useless now
> 

I removed the above and I think the buildflags or the include was
overriding the flags. The build now includes "-fPIE
-fstack-protector-strong -Wformat -Werror=format-security" when
building.


> - why the upstream build system is creating all this stuff in /usr/bin?

Dallas Semiconductor Corp (now Maxim Integrated) created the 1-wire
standard and devices. They created a software release (confusingly
called libusblinux300.tar.gz) to interface with the devices. The idea
was to enable anyone to make use of the devices quickly without
restrictions. It was this software that was used to create the w1retap
project.

The upstream build system continues to create the sample utilities that
were included in the original software release. While these utilities
may be useful for w1retap development, to my knowledge they are not
required to actually run a w1retap setup. This is why I've not packaged
those extra binary's.


> - doc might be split easily into a w1retap-doc package
> 

Good idea, I've split it out and created w1retap-doc. This nicely
reduced the size of the main w1retap deb file. This also prompted me to
install another useful script called w1sensors.


> usr/lib/*/w1retap/libw1common.so*
> usr/lib/*/w1retap/libw1csv.so*
> usr/lib/*/w1retap/libw1file.so*
> usr/lib/*/w1retap/libw1serial.so*
> usr/lib/*/w1retap/libw1usb.so*
> usr/lib/*/w1retap/libw1xml.so*
> 
> what about a single
> usr/lib/*/w1retap/lib*.so* entry?
> 

I do like that shorter version, however that glob will match all the
available plugins. So it would also include mondo, mysql, odbc, etc.
For example libw1mongo.so.0 would be packaged in w1retap and
w1retap-mongo. I can't see a simple way to get around this.


> - why systemd as runtime dependency?
>

That looks like my mistake, I thought I needed to depend on it given
that I'm shipping a service file that starts the main daemon with
systemd. I have removed that dependency.


> - with compat 10 you can avoid --parallel and --with autoreconf
> 

Excellent, I've changed to compat 10.

> this should be enough for now (and probably now the review is complete)
> 
> last thing about your patch
> 
> -w1->rcfile = strdup("/etc/default/w1retap");
> +w1->rcfile 

Bug#791724: RFS: w1retap/1.4.4-1 [ITP] -- Data logger for 1-Wire weather sensors

[Thomas Stewart]

Hi Gianfranco,

Thank you for the comments and suggestions, they are really appreciated.
Apologies for the delay, I have slowly worked through your email on and
off over the past few months. I think I have addressed most of the
issues you mentioned (see my comments below), so I have uploaded a fresh
version to http://mentors.debian.net/package/w1retap.

Thanks again for reviewing the package, I would appreciate any other
comments you have or uploading it if you feel it's ready.

On 01 Apr 2016, at 20:52, Gianfranco Costamagna wrote:
> control:
> "retrieved   data" <-- double space
> std version is 3.9.7 now
> please run wrap-and-sort
> please remove quilt from b-d
> changelog:
> one single changelog entry please
> 
> -rm -f $(CURDIR)/debian/w1retap.1 $(CURDIR)/debian/w1find.1 -> debian/clean 
> might be easier to maintain
> 
> rules:
> dh_auto_install is a no-op please remove

All fixed.

> dh_makeshlibs --noscripts <-- why?

The plugin packages contain .so files, the --noscripts option stops an
ldconfig run when installing. Without it I get a lintian useless
ldconfig run warnings.

> remove quilt

Fixed.

> libw1retap0-odbc.install <-- is that the mysql wrapper?

No, it's a odbc plugin and the mysql plugin is separate. The confusion was
caused by a typo on my part. In anycase, both are now fixed.

> service file:
> ExecStop=/bin/kill $MAINPID
> 
> really needed?

Fixed.

> patches: remove-data-time-macro.patch
> you can dpkg-parsechangelog and export the changelog date an build date.
> (this will make the package reproducible I think)

The current upstream code (src/w1retap.c) uses the "__DATE__" and
"__TIME__" GCC standard macros directly. I don't think
dpkg-parsechangelog can affect these macros. My patch replaces these
macros with __BUILD_DATE__.
 
> question:
> usually libraries are ship in this way
> 
> libfooSONAME shipping libfoo.so.SONAME
> 
> libfoo-dev with an hard dependency on libfooSONAME
> and a libfoo.so symlink to libfoo.so.SONAME and /usr/include/foo
> headers files.
> 
> In your package you are shipping them together
> 
> not an issue, but do you know what you are doing here?
> are them useful and being linked outside the package?
> are them just internal?

The .so files are not useful or used and outside the w1retap, they are
all internal. Thus I agree and have removed all the libw1retap*
packages. They act more like plugins so I now have a main w1retap
package and 5 separate plugin package for each database type.

> lots of stuff (systemd script udev rules) should be upstreamed to me

There are a number of patches that I will send upstream:
 - add-etc-w1retap-conf.patch
 - movetmp.patch
 - remove-data-time-macro.patch 
 - udev rule
 - systemd service
 
> check-all-the-things review:
> codespell --quiet-level=3
> cppcheck -j1 --quiet -f .
> grep -riE 'fixme|todo|hack|xxx' .
> grep -r '/tmp/' .

I did run all of the above and found some issues. Some of the issues
seemed to be more related to actual upstream development rather than
packaging. Most notably predicable file creation in /tmp, which is fixed
in the above mentioned movetmp.patch. Did you spot anything else that
needing fixing?

Regards
--
Tom

Bug#791724: RFS: w1retap/1.4.4-1 [ITP] -- Data logger for 1-Wire weather sensors

[Thomas Stewart]

Dear mentors,

I am looking for a sponsor for my package "w1retap":

* Package name: w1retap
  Version : 1.4.4-1
  Upstream Author : Jonathan Hudson 
* URL : http://www.zen35309.zen.co.uk/wx/tech.html
* License : GPL with some Expat
  Programming Lang: C
  Description : Data logger for 1-Wire weather sensors

It builds those binary packages:
  libw1retap0 - Data logger for 1-Wire weather sensors
  libw1retap0-mongo - Data logger for 1-Wire weather sensors
  libw1retap0-odbc - Data logger for 1-Wire weather sensors
  libw1retap0-pgsql - Data logger for 1-Wire weather sensors
  libw1retap0-sqlite - Data logger for 1-Wire weather sensors
  w1retap - Data logger for 1-Wire weather sensors

To access further information about this package, please visit the following 
URL:
http://mentors.debian.net/package/w1retap

Alternatively, one can download the package with dget using this command:
dget -x http://mentors.debian.net/debian/pool/main/w/w1retap/w1retap_1.4.4-1.dsc

More information about hello can be obtained from 
http://www.zen35309.zen.co.uk/wx/tech.html.

Changes since the last upload:
 w1retap (1.4.4-1) unstable; urgency=medium
 .
   * New upstream release.

Kind Regards
--
Tom

Bug#791724: closing RFS: w1retap/1.4.2-1 [ITP] -- Data logger for 1-Wire weather sensors

[Thomas Stewart]

On 11 Jan 2016, at 21:11, Gianfranco Costamagna wrote:
> On Wed, 02 Dec 2015 16:32:19 + Bart Martens wrote:
> > Package w1retap has been removed from mentors.
> 
> do you still need this package? if so please reupload and I'll review it.

Hi Gianfranco,

Thank you very much for offering to review the w1retap package. I still
use this software and would like it packaged. I have created an updated
package following two minor upstream releases.

I have uploaded it to: http://mentors.debian.net/package/w1retap

Thanks :-)

Regards
--
Tom

Bug#791724: RFS: w1retap/1.4.2-1 [ITP] -- Data logger for 1-Wire weather sensors

[Thomas Stewart]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package w1retap:

* Package name: w1retap
  Version : 1.4.2
  Upstream Author : Jonathan Hudson jh+w1re...@daria.co.uk
* URL : http://www.zen35309.zen.co.uk/wx/tech.html
* License : GPL with some Expat
  Programming Lang: C
  Description : Data logger for 1-Wire weather sensors

It builds those binary packages:
  libw1retap0 - Data logger for 1-Wire weather sensors
  libw1retap0-mongo - Data logger for 1-Wire weather sensors
  libw1retap0-odbc - Data logger for 1-Wire weather sensors
  libw1retap0-pgsql - Data logger for 1-Wire weather sensors
  libw1retap0-sqlite - Data logger for 1-Wire weather sensors
  w1retap - Data logger for 1-Wire weather sensors

To access further information about this package, please visit the following 
URL:
http://mentors.debian.net/package/w1retap

Alternatively, one can download the package with dget using this command:
dget -x http://mentors.debian.net/debian/pool/main/w/w1retap/w1retap_1.4.2-1.dsc

More information about hello can be obtained from 
http://www.zen35309.zen.co.uk/wx/tech.html.

Changes since the last upload:
 w1retap (1.4.2-1) unstable; urgency=low
 .
   * Initial release (Closes: #787770)


Kind Regards
--
Tom


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

Bug#787770: ITP: w1retap -- Data logger for 1-Wire weather sensors

[Thomas Stewart]

Package: wnpp
Severity: wishlist
Owner: Thomas Stewart tho...@stewarts.org.uk

* Package name: w1retap
  Version : 1.4.2
  Upstream Author : Jonathan Hudson jh+w1re...@daria.co.uk
* URL : http://www.zen35309.zen.co.uk/wx/tech.html
* License : GPL with some Expat
  Programming Lang: C
  Description : Data logger for 1-Wire weather sensors

The w1retap package reads weather sensors on a 1-Wire bus and logs the 
retrieved  data to the configured databases or files. It supports a
number of different 1-Wire host bus adapters and 1-Wire sensors designed
by Dallas Semiconductor Corp (now Maxim Integrated) and compatible
sensors including those from AAG Electrónica and other hobby sensors.


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

Bug#699367: similar issue with crash(8) for Linux 4.x

[Thomas Stewart]

Package: crash
Version: 7.0.8-1
Followup-For: Bug #699367

Dear Maintainer,

I have found that crash(8) fails in a similar manor when trying to
analyse Linux 4.x kernel kdumps, see below for the is not SMP error:

$ sudo crash /usr/lib/debug/boot/vmlinux-4.0.0-1-amd64 
/var/crash/201505221035/dump.201505221035 

crash 7.0.8
Copyright (C) 2002-2014  Red Hat, Inc.
Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation
Copyright (C) 1999-2006  Hewlett-Packard Co
Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited
Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
Copyright (C) 2005, 2011  NEC Corporation
Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions.  Enter help copying to see the conditions.
This program has absolutely no warranty.  Enter help warranty for details.
 
GNU gdb (GDB) 7.6
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type show copying
and show warranty for details.
This GDB was configured as x86_64-unknown-linux-gnu...

WARNING: kernels compiled by different gcc versions:
  /usr/lib/debug/boot/vmlinux-4.0.0-1-amd64: (unknown)
  /var/crash/201505221035/dump.201505221035 kernel: 4.9.2

WARNING: kernel version inconsistency between vmlinux and dumpfile

crash: incompatible arguments: 
   /usr/lib/debug/boot/vmlinux-4.0.0-1-amd64 is not SMP -- 
/var/crash/201505221035/dump.201505221035 is SMP

Usage:

  crash [OPTION]... NAMELIST MEMORY-IMAGE[@ADDRESS] (dumpfile form)
  crash [OPTION]... [NAMELIST]  (live system form)

Enter crash -h for details.
$

This is an issue with crash(8) that has been fixed upstream. See 
https://github.com/crash-utility/crash/commit/db07dbf5a7e19806b1629bd4125e6643978c6f9f
and 
https://github.com/crash-utility/crash/commit/466b9f476a977ef5e39d1c2786858091365db882
that add support for Linux 4.x and 5.x. Neither of these patches have
made it into the current 7.1.0 release. When I checkout and compile 
HEAD (3cbecbcd3c025b70078bd8a54c40981d5c32e9c1) it works OK:

$ sudo ~/scratch/crash/crash /usr/lib/debug/boot/vmlinux-4.0.0-1-amd64 
/var/crash/201505221035/dump.201505221035 

crash 7.1.0
Copyright (C) 2002-2014  Red Hat, Inc.
Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation
Copyright (C) 1999-2006  Hewlett-Packard Co
Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited
Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
Copyright (C) 2005, 2011  NEC Corporation
Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions.  Enter help copying to see the conditions.
This program has absolutely no warranty.  Enter help warranty for details.
 
GNU gdb (GDB) 7.6
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type show copying
and show warranty for details.
This GDB was configured as x86_64-unknown-linux-gnu...

  KERNEL: /usr/lib/debug/boot/vmlinux-4.0.0-1-amd64
DUMPFILE: /var/crash/201505221035/dump.201505221035  [PARTIAL DUMP]
CPUS: 4
DATE: Fri May 22 10:35:36 2015
  UPTIME: 00:01:16
LOAD AVERAGE: 2.44, 0.75, 0.26
   TASKS: 397
NODENAME: NBENG0008
 RELEASE: 4.0.0-1-amd64
 VERSION: #1 SMP Debian 4.0.2-1 (2015-05-11)
 MACHINE: x86_64  (2693 Mhz)
  MEMORY: 15.9 GB
   PANIC: BUG: unable to handle kernel paging request at 8805660b7ffc
 PID: 40
 COMMAND: kworker/0:1
TASK: 88046bb26310  [THREAD_INFO: 88046b528000]
 CPU: 0
   STATE: TASK_RUNNING (PANIC)

crash

I'm not sure if it's appropriate to apply these patches to stable as
bpo does not have a 4.0 kernel yet. I assume once a new version of
crash is released it will start working on sid and testing with time.

However this info might prove useful to anyone trying and failing to
inspect Linux 4.x kdump files.

Kind Regards
--
Tom

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (400, 'testing'), (300, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages crash 

Bug#755257: munin-plugins-core should suggest libdbd-pg-perl

[Thomas Stewart]

Package: munin-plugins-core
Version: 2.0.6-4+deb7u2
Severity: normal

Dear Maintainer,

The postgres munin plugins fail on a freshly installed system after
postgres, munin-node and munin-plugins-core are installed:

thomas@beryl:~$ readlink /etc/munin/plugins/postgres_cache_ALL
/usr/share/munin/plugins/postgres_cache_
thomas@beryl:~$ sudo -u postgres /etc/munin/plugins/postgres_cache_ALL
Failed to connect to database: DBD::Pg not found, and cannot do psql yet
thomas@beryl:~$ 

Once libdbd-pg-perl is installed:
thomas@beryl:~$ sudo -u postgres /etc/munin/plugins/postgres_cache_ALL
blks_read.value 49238
blks_hit.value 20241867
thomas@beryl:~$

If munin-plugins-core suggests libdbd-pg-perl this might be prevented.

Kind Regards
Tom

-- System Information:
Debian Release: 7.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages munin-plugins-core depends on:
ii  munin-common  2.0.6-4+deb7u2
ii  perl  5.14.2-21+deb7u1

Versions of packages munin-plugins-core recommends:
ii  libnet-snmp-perl  6.0.1-2

Versions of packages munin-plugins-core suggests:
pn  libnet-netmask-perl  none
pn  libnet-telnet-perl   none
ii  python   2.7.3-4+deb7u1
pn  ruby | ruby-interpreter  none

-- no debconf information


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

Bug#310442: rdiff-backup: no space on dest device can be irrecoverable fix

[Thomas Stewart]

Hi,

In the situation where rdiff-backup appears broken because the
destination has become full and the recommended --check-destination-dir
option only gives [Errno 28] No space left on device errors. The
option --tempdir can be given to recover the backup directory. The
python module tempfile will use /tmp by default, overriding that to
somewhere with more space enabled the check to complete.

For example:
rdiff-backup --tempdir /diskb/backups/pub --check-destination-dir 
/diskb/backups/pub
 
A quick note in the man page about this would be useful. Something
like this would have saved me quite some time. :-)

--- rdiff-backup.1.orig 2011-08-03 11:36:57.0 +0100
+++ rdiff-backup.1  2011-08-03 11:39:49.0 +0100
@@ -78,7 +78,7 @@
 If an rdiff-backup session fails, running rdiff-backup with this
 option on the destination dir will undo the failed directory.  This
 happens automatically if you attempt to back up to a directory and the
-last backup failed.
+last backup failed. The option --tempdir might be needed if the default system 
tempdir does not have sufficient space available.
 .TP
 .B \-\-compare
 This is equivalent to

Regards
--
Tom



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

Bug#565706: Enabling floppy is a workaround

[Thomas Stewart]

Hi,

I had what appears to be a very similar issue. I had the floppy drives
disabled in the bios. Once I enabled them as USB emulation, grub worked.

Regards
--
Tom



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

Bug#564936: grub-pc: unexpectable reboot

[Thomas Stewart]

Hi,

I just ran into this while upgrading from 1.98~20100101-1 to
1.98~20100115-1. Installing 1.98~20100126-1 seemed to fix it for me.

Regards
--
Tom



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

Bug#546472: ucarp man page should mention signals

[Thomas Stewart]

Package: ucarp
Version: 1.5.1-1
Severity: wishlist
Tags: patch

Hi,

Although signals are mentioned in the other documentation, it would be
nice if they were documented in the man page too. Something like this:

--- debian/ucarp.8.sgml.orig2009-09-13 13:04:20.0 +0100
+++ debian/ucarp.8.sgml 2009-09-13 13:17:37.0 +0100
@@ -19,7 +19,7 @@
   !ENTITY dhfirstname firstnameEric/firstname
   !ENTITY dhsurname   surnameEvans/surname
   !-- Please adjust the date whenever revising the manpage. --
-  !ENTITY dhdate  dateApril 2, 2008/date
+  !ENTITY dhdate  dateSeptember 13, 2009/date
   !ENTITY dhsection   manvolnum8/manvolnum
   !ENTITY dhemail emaileev...@debian.org/email
   !ENTITY dhusername  Eric Evans
@@ -269,6 +269,19 @@
   /refsect1
 
   refsect1
+titleSIGNALS/title
+paraSending the ucarp process a SIGUSR1 will have it log a status line to
+syslog, eg Sep 13 12:59:56 localhost ucarp[2654]: [INFO] MASTER on eth0 
id 1 or Sep 13 13:00:25 localhost ucarp[2644]: [INFO] BACKUP on eth0 id 1
+/para
+paraSending the ucarp process a SIGUSR2 will demote itself from master to
+backup, pause 3 seconds, then proceed as usual to listen for other masters
+and promote itself if necessary. This could be useful if you wish another
+node to take over master.
+/para
+
+  /refsect1
+
+  refsect1
 titleAUTHOR/title
 paradhpackage; was written by Frank Denis, 
lt;j...@ucarp.orggt;./para
 
Regards
--
Tom

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (400, 'testing'), (300, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-2-686 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages ucarp depends on:
ii  libc6 2.9-23 GNU C Library: Shared libraries
ii  libpcap0.81.0.0-2system interface for user-level pa

Versions of packages ucarp recommends:
ii  iproute   20090324-1 networking and traffic control too

ucarp suggests no packages.

-- no debconf information



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

Bug#520428: units: Does not have the twip unit

[Thomas Stewart]

Package: units
Version: 1.87-1
Severity: wishlist
Tags: patch


The units database does not have the twip unit. A twip is a unit of
length that is a 1/20th of a point, a point being a 1/72th of an inch.
It is an abbreviation of twentieth of a point. See
http://en.wikipedia.org/wiki/Twip for more details and some sketchy
references.

This works for me:

--- /usr/share/misc/units.dat.orig  2009-03-19 17:27:00.0 +
+++ /usr/share/misc/units.dat   2009-03-19 17:30:42.0 +
@@ -2736,6 +2736,7 @@
 point   computerpoint
 computerpica12 computerpoint  # to an even 1|72 inch by computer
 postscriptpoint computerpoint # people at some point. 
+twip1|20 computerpoint # abbreviation of twentieth of a 
point
 pspoint postscriptpoint
 Q   1|4 mm# Used in Japanese phototypesetting
   # Q is for quarter

-- System Information:
Debian Release: 5.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.27.12-bytemark-kvm-2009-01-19
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages units depends on:
ii  libc6 2.7-18 GNU C Library: Shared libraries
ii  libncurses5   5.7+20081213-1 shared libraries for terminal hand
ii  libreadline5  5.2-3.1GNU readline and history libraries

units recommends no packages.

units suggests no packages.

-- no debconf information



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

Bug#420151: wvdial: breaks are sent to serial ports without asking

[Thomas Stewart]

Package: wvdial
Version: 1.56-1.2
Severity: normal

I recently upgraded my serial console server from Sarge to Etch. During 
the upgrade while setting it up it seemed to scan all my serial ports.
It seemed to try a few baud rates and a few AT commands to gather some
information. Usually this would be quite useful, but in my case I have
several usb serial adapters that are connected to serial ports on other
servers. After the upgrade I found a few of the sun boxes sitting at an
ok prompt, obviously something along the line sent a break to them 
which dropped them to prom. Probably it was not a proper break but a 
bunch of nulls which look just like a break at the other end.

If would be nice if the setup script asked if it would be ok to probe.
Alternatively it could check if the port is allready in use. Probably 
fuser would do the job:-

$ fuser /dev/ttyUSB8
/dev/ttyUSB8: 4193
$
$ fuser /dev/ttyS0
$

Regards
--
Tom

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-686
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1)

Versions of packages wvdial depends on:
ii  debconf 1.5.11   Debian configuration management sy
ii  libc6   2.3.6.ds1-13 GNU C Library: Shared libraries
ii  libuniconf4.2   4.2.2-2.2C++ network libraries for rapid ap
ii  libwvstreams4.2-base4.2.2-2.2C++ network libraries for rapid ap
ii  libwvstreams4.2-extras  4.2.2-2.2C++ network libraries for rapid ap
ii  libxplc0.3.13   0.3.13-1 Light weight component system
ii  ppp 2.4.4rel-8   Point-to-Point Protocol (PPP) daem

wvdial recommends no packages.

-- debconf information:
* wvdial/phone:
  wvdial/passphrases_mismatch:
  wvdial/wvdialconf: true
* wvdial/login:


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#413499: another test case

[Thomas Stewart]

I looked up the char from broken.html on unicode.org.
I get the same tick in the lookup text box:
http://www.unicode.org/cgi-bin/GetUnihanData.pl?codepoint=0641


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#385934: Fixed by using xen-hypervisor-3.0-unstable-1-i386

[Thomas Stewart]

Hi,

I got exactly, the same problem. I tryed installing 
xen-hypervisor-3.0-unstable-1-i386. It seems to have fixed the problem.

I have no idea what the original issue is but this might be of use to
people that need to get going again.

Regards
--
Tom


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#385934: Fixed by using xen-hypervisor-3.0-unstable-1-i386

[Thomas Stewart]

On Thu, Sep 07, 2006 at 03:54:12PM +0200, Thomas Schwinge wrote:
 Hello!
 
 Indeed I can confirm that `xen-hypervisor-3.0-unstable-1-i386' together
 with `linux-image-2.6.17-2-xen-686' gets the Dom0 going again.  So far, I
 had no luck to get a DomU running, however:
 
 #v+
 [EMAIL PROTECTED]:~ $ sudo /etc/init.d/xendomains restart
 Shutting down Xen domains:Starting auto Xen domains: riemannError: Device 0 
 (vif) could not be connected. Hotplug scripts not working.
 #v-

I got the same messsage, however if you create a dom without networking or
disable networking, I found that the a dom will start and run fine.

I think this networking issue has something todo with kernel module that
creates the devices.

It's somethign todo with:
/lib/modules/2.6.17-2-xen-686/kernel/drivers/xen/netback/netloop.ko

I found that if I added netloop to /etc/modules, everything works ok.

I have a feeling that its named changed and whatever was auto loading
it before is not now. (Thow I have no idea)

Regards
--
Tom


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#381290: (no subject)

[Thomas Stewart]

Subject: xen-tools: xen-create-image never finishes when behind a http proxy
Package: xen-tools
Version: 2.2-3
Severity: important

*** Please type your report below this line ***
/usr/lib/xen-tools/debian.d/20-setup-apt creates a 
canned /etc/apt/sources.list with 4 repo lines. The first 2 are 
${mirror} which in my case I set in /etc/xen-tools/xen-tools.conf to a 
local apt-cacher that knows about the http proxy. However the last 2 
repo lines are security.debian.org ones. Later 20-setup-apt runs apt-get 
update. As the box can't connect directly to the Internet the process 
just sits there timing out.

When the setup scripts were in /etc/xen-tools/hooks.d, I created a 
19-setup-apt-proxy that created /etc/apt/apt.conf.d/10proxy:
Acquire::http::Proxy http://wwwcache:3128;
This meant that apt knew about the proxy, which worked fine.

I considered using /etc/xen-tools/skel instead, but skel is not copied 
till 65-copy-user-files is run.

I suggest either a more configurable 20-setup-apt, so that I can change 
the security.debian.org lines to point at my apt-casher. Or implement a 
19-setup-apt-proxy. Or have I missed the obvious way to do custom  
modifications/overrides for /usr/lib/xen-tools/debian.d?

Something like this:
#!/bin/sh
#
#  This script sets up the /etc/apt/apt.conf.d/10proxy for APT.
#

prefix=$1

cat E_O_APT  ${prefix}/etc/apt/apt.conf.d/10proxy
Acquire::http::Proxy $proxy;
E_O_APT


-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (400, 'testing'), (300, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-2-xen-686
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1)

Versions of packages xen-tools depends on:
ii  debootstrap   0.3.3  Bootstrap a basic Debian system
ii  libtext-template-perl 1.44-1.1   Text::Template perl module
ii  perl-modules  5.8.8-4Core Perl modules

Versions of packages xen-tools recommends:
pn  reiserfsprogs none (no description available)
pn  rpmstrap  none (no description available)
ii  xen-hypervisor-3.0-i386 [ 3.0.2+hg9697-1 The Xen Hypervisor for i386
ii  xen-hypervisor-3.0-i386-p 3.0.2+hg9697-1 The Xen Hypervisor for i386 (pae e
pn  xfsprogs  none (no description available)

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#381290: (no subject)

[Thomas Stewart]

On Thu, Aug 03, 2006 at 02:40:35PM +0100, Steve Kemp wrote:
   I think that the real solution is to see if there is a proxy in
  use on the host, and if so create the identical proxy in the new
  guest.
 
   That seems like it would satisfy your goal whilst still being
  understandable.  (Alternatively testing for ${http_proxy} might
  work.)
 
   So I'd suggest that the setup apt script was prefixed with this:
 
SNIP
 
   Does that seem reasonable?  And if so would you mind testing it?

Yes, that sounds like a great idea. I popped that script just after the
logMessage line in 20-setup-apt. It works great and just as
expected. xen-create-image now completes fine :-)

Regards
--
Tom


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]