Bug#844895: libapache-mod-musicindex: FTBFS: x86_64-linux-gnu-gcc: error: .specs: No such file or directory

[Thibaut VARENE]

forcemerge 844302 844895
stop

Thanks for the noise.

> Le 19 nov. 2016 à 07:44, Lucas Nussbaum  a écrit :
> 
> Source: libapache-mod-musicindex
> Version: 1.4.1-1
> Severity: serious
> Tags: stretch sid
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-20161118 qa-ftbfs
> Justification: FTBFS on amd64
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
> 
> Relevant part (hopefully):
>> /bin/bash ../libtool  --tag=CC   --mode=compile x86_64-linux-gnu-gcc 
>> -DHAVE_CONFIG_H -I. -I../../src -I.. -I/usr/include/apache2 
>> -I/usr/include/apr-1.0 -I/usr/include/mysql -DLINUX -D_REENTRANT 
>> -D_GNU_SOURCE -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -pedantic 
>> -fstrict-aliasing -pipe -g -O2 -fdebug-prefix-map=/build/apache2-2.4.23=. 
>> -fstack-protector-strong -Wformat -Werror=format-security   -pthread 
>> -I/usr/include  -I/usr/include/mysql 
>> -fdebug-prefix-map=/build/mysql-5.7-lG4h93/mysql-5.7-5.7.16=. .specs 
>> -fabi-version=2 -fno-omit-frame-pointer -g -O2 
>> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
>> -Werror=format-security -MT mod_musicindex_la-mod_musicindex.lo -MD -MP -MF 
>> .deps/mod_musicindex_la-mod_musicindex.Tpo -c -o 
>> mod_musicindex_la-mod_musicindex.lo `test -f 'mod_musicindex.c' || echo 
>> '../../src/'`mod_musicindex.c
>> libtool: compile:  x86_64-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../../src -I.. 
>> -I/usr/include/apache2 -I/usr/include/apr-1.0 -I/usr/include/mysql -DLINUX 
>> -D_REENTRANT -D_GNU_SOURCE -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -pedantic 
>> -fstrict-aliasing -pipe -g -O2 -fdebug-prefix-map=/build/apache2-2.4.23=. 
>> -fstack-protector-strong -Wformat -Werror=format-security -pthread 
>> -I/usr/include -I/usr/include/mysql 
>> -fdebug-prefix-map=/build/mysql-5.7-lG4h93/mysql-5.7-5.7.16=. .specs 
>> -fabi-version=2 -fno-omit-frame-pointer -g -O2 
>> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
>> -Werror=format-security -MT mod_musicindex_la-mod_musicindex.lo -MD -MP -MF 
>> .deps/mod_musicindex_la-mod_musicindex.Tpo -c ../../src/mod_musicindex.c  
>> -fPIC -DPIC -o .libs/mod_musicindex_la-mod_musicindex.o
>> x86_64-linux-gnu-gcc: error: .specs: No such file or directory
>> Makefile:462: recipe for target 'mod_musicindex_la-mod_musicindex.lo' failed
>> make[3]: *** [mod_musicindex_la-mod_musicindex.lo] Error 1
> 
> The full build log is available from:
>   
> http://aws-logs.debian.net/2016/11/18/libapache-mod-musicindex_1.4.1-1_unstable.log
> 
> A list of current common problems and possible solutions is available at
> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
> 
> About the archive rebuild: The rebuild was done on EC2 VM instances from
> Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
> failed build was retried once to eliminate random failures.

Bug#844302: libapache-mod-musicindex: FTBFS: x86_64-linux-gnu-gcc: error: .specs: No such file or directory

[Thibaut VARENE]

> Le 14 nov. 2016 à 11:37, Chris Lamb  a écrit :
> 
> Source: libapache-mod-musicindex
> Version: 1.4.1-1
> Severity: serious
> Justification: fails to build from source
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: ftbfs
> X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
> 
> Dear Maintainer,
> 
> libapache-mod-musicindex fails to build from source in unstable/amd64:
> 
>  […]

> Making all in src
> make[3]: Entering directory 
> '/home/lamby/temp/cdt.20161114094607.osX7pL8bcm.db.libapache-mod-musicindex/libapache-mod-musicindex-1.4.1/build/src'
> /bin/bash ../libtool  --tag=CC   --mode=compile x86_64-linux-gnu-gcc 
> -DHAVE_CONFIG_H -I. -I../../src -I.. -I/usr/include/apache2 
> -I/usr/include/apr-1.0 -I/usr/include/mysql -DLINUX -D_REENTRANT 
> -D_GNU_SOURCE -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -pedantic 
> -fstrict-aliasing -pipe -g -O2 -fdebug-prefix-map=/build/apache2-2.4.23=. 
> -fstack-protector-strong -Wformat -Werror=format-security   -pthread 
> -I/usr/include  -I/usr/include/mysql 
> -fdebug-prefix-map=/build/mysql-5.7-lG4h93/mysql-5.7-5.7.16=. .specs 
> -fabi-version=2 -fno-omit-frame-pointer -g -O2 
> -fdebug-prefix-map=/home/lamby/temp/cdt.20161114094607.osX7pL8bcm.db.libapache-mod-musicindex/libapache-mod-musicindex-1.4.1=.
>  -fstack-protector-strong -Wformat -Werror=format-security -MT 
> mod_musicindex_la-mod_musicindex.lo -MD -MP -MF 
> .deps/mod_musicindex_la-mod_musicindex.Tpo -c -o 
> mod_musicindex_la-mod_musicindex.lo `test -f 'mod_musicindex.c' || echo 
> '../../src/'`mod_musicindex.c
>  libtool: compile:  x86_64-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../../src -I.. 
> -I/usr/include/apache2 -I/usr/include/apr-1.0 -I/usr/include/mysql -DLINUX 
> -D_REENTRANT -D_GNU_SOURCE -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -pedantic 
> -fstrict-aliasing -pipe -g -O2 -fdebug-prefix-map=/build/apache2-2.4.23=. 
> -fstack-protector-strong -Wformat -Werror=format-security -pthread 
> -I/usr/include -I/usr/include/mysql 
> -fdebug-prefix-map=/build/mysql-5.7-lG4h93/mysql-5.7-5.7.16=. .specs 
> -fabi-version=2 -fno-omit-frame-pointer -g -O2 
> -fdebug-prefix-map=/home/lamby/temp/cdt.20161114094607.osX7pL8bcm.db.libapache-mod-musicindex/libapache-mod-musicindex-1.4.1=.
>  -fstack-protector-strong -Wformat -Werror=format-security -MT 
> mod_musicindex_la-mod_musicindex.lo -MD -MP -MF 
> .deps/mod_musicindex_la-mod_musicindex.Tpo -c ../../src/mod_musicindex.c  
> -fPIC -DPIC -o .libs/mod_musicindex_la-mod_musicindex.o
>  x86_64-linux-gnu-gcc: error: .specs: No such file or directory

I don’t see how this is a bug in my package. I don’t know where that spurious « 
.specs » on the command line comes from. Looks like a build system cockup to me.

Besides, this package is orphaned.

T.

Bug#830769: O: flashybrid

[Thibaut VARENE]

Package: wnpp
Severity: normal

Orphaning my packages following the removal of my key from the keyring.

Bug#830767: O: schedtool

[Thibaut VARENE]

Package: wnpp
Severity: normal

Orphaning my packages following the removal of my key from the keyring.

Bug#830768: O: libapache-mod-musicindex

[Thibaut VARENE]

Package: wnpp
Severity: normal

Orphaning my packages following the removal of my key from the keyring.

Bug#830765: O: uptimed

[Thibaut VARENE]

Package: wnpp
Severity: normal

Orphaning my packages following the removal of my key from the keyring.

Bug#830766: O: tagainijisho

[Thibaut VARENE]

Package: wnpp
Severity: normal

Orphaning my packages following the removal of my key from the keyring.

Bug#784890: flashybrid: Unable to Sync ramstore directories ...

[Thibaut VARENE]

> Le 9 juil. 2016 à 17:53, Andreas Beckmann  a écrit :
> 
> On Sun, 8 Nov 2015 11:24:34 +0100 Tim Weippert  wrote:
>> DM's not allowed to do an NMU Upload. Sorry, can't help. 
> 
>>> On Sun, May 17, 2015 at 03:00:24PM +0200, Thibaut Varène wrote:
 For the records, I'm attaching source for flashybrid-0.19 and a patch from 
 0.18 to this bug report. I can't upload it to the archive, but if some DD 
 wants to, let them be my guest.
> 
> What about uploading to mentors.debian.net and filing a RFS?

I don’t need a sponsor. The package needs a DD. I used to be one, now that’s 
over.

Best,
T.

Bug#796612: flashybrid: diff for NMU version 0.18+nmu2

[Thibaut VARENE]

> Le 8 juil. 2016 à 16:03, Felipe Sateler  a écrit :
> 
> On 7 July 2016 at 19:12, Thibaut Varène  wrote:
>> 
>>> On 08 Jul 2016, at 01:01, Felipe Sateler  wrote:
>>> 
>>> Hi Thibaut,
>>> 
>>> On 7 July 2016 at 18:41, Thibaut Varène  wrote:
 
> On 03 Jul 2016, at 22:06, z...@debian.org wrote:
> 
> Control: tags 796612 + patch
> Control: tags 796612 + pending
> 
> Dear maintainer,
> 
> I've prepared an NMU for flashybrid (versioned as 0.18+nmu2) and
> uploaded it to DELAYED/5. Please feel free to tell me if I
> should delay it longer.
 
 It’s ok, you do what you have to do.
 If you want to take over maintainership, please be my guest. I’m 
 maintaining “upstream” here now:
 
 http://hacks.slashdirt.org/sw/flashybrid/
 
 I’d welcome a patch to merge btw.
>>> 
>>> Your upstream page claims that 0.19 supports systemd.
>> 
>> It “supports” it to the extent that it fixes #784890 and boots correctly on 
>> Jessie (as far as my very basic tests showed). It does not have the glue 
>> that the NMU supposedly fixes. Glue I’d be happy to merge were I sent a 
>> patch.
> 
> Christian, you didn't attach the first nmu diff apparently, could you
> please re send it?
> 
>> 
>>> Why not upload
>>> that version to debian?
>> 
>> Because my upload rights have been revoked with the 1024-bit keys purge, and 
>> at this point I don’t care anymore.
> 
> I'd be happy to sponsor the upload. But if you are no longer
> maintaining the package in debian maybe it should be RMed instead.

I’m not interested in becoming a second-class DD after 12 years of service. If 
that package cannot muster the interest of an actual maintainer, then maybe it 
should indeed be removed from the archive. I will keep it alive on my website 
anyway.

Best,
T.

Bug#770179: sessionclean: sed: invalid option -- 'z'

[Thibaut VARENE]

Package: php5
Version: 5.4.35-0+deb7u1
Severity: normal

unattended-upgrades upgraded php5 on my machine last night, and since then I
receive the following email every 30 minutes:

Cron root@   [ -x /usr/lib/php5/maxlifetime ]  [ -x 
/usr/lib/php5/sessionclean ]  [ -d /var/lib/php5 ]  
/usr/lib/php5/sessionclean /var/lib/php5 $(/usr/lib/php5/maxlifetime)

sed: invalid option -- 'z'
Usage: sed [OPTION]... {script-only-if-no-other-script} [input-file]...

 -n, --quiet, --silent
suppress automatic printing of pattern space
 -e script, --expression=script
add the script to the commands to be executed
 -f script-file, --file=script-file
add the contents of script-file to the commands to be executed
 --follow-symlinks
follow symlinks when processing in place
 -i[SUFFIX], --in-place[=SUFFIX]
edit files in place (makes backup if extension supplied)
 -l N, --line-length=N
specify the desired line-wrap length for the `l' command
 --posix
disable all GNU extensions.
 -r, --regexp-extended
use extended regular expressions in the script.
 -s, --separate
consider files as separate rather than as a single continuous
long stream.
 -u, --unbuffered
load minimal amounts of data from the input files and flush
the output buffers more often
 --help display this help and exit
 --version  output version information and exit

If no -e, --expression, -f, or --file option is given, then the first
non-option argument is taken as the sed script to interpret.  All
remaining arguments are names of input files; if no input files are
specified, then the standard input is read.

GNU sed home page: http://www.gnu.org/software/sed/.
General help using GNU software: http://www.gnu.org/gethelp/.

-- System Information:
Debian Release: 7.7
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: powerpc (ppc)

Kernel: Linux 2.6.32.61
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages php5 depends on:
ii  libapache2-mod-php5  5.4.35-0+deb7u1
ii  php5-common  5.4.35-0+deb7u1

php5 recommends no packages.

php5 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#564045: ITA flashybrid

[Thibaut VARENE]

subject 564045 ITA: flashybrid -- automates use of a flash disk as the root
filesystem
thanks

Hi,

I feel like adopting this package which I happen to use myself. Raise a
hand if you object and/or there's something I should know before uploading
:-)

T-Bone

-- 
Thibaut VARENE
http://hacks.slashdirt.org/

Bug#730744: Update

[Thibaut VARENE]

Just a quick update to confirm that rebuilding libapr1 with apr_cv_accept4=no
did indeed fix the issue.

HTH

-- 
Thibaut VARENE
http://hacks.slashdirt.org/

Bug#730702: flashybrid: Init script is loaded too late, prevents flashybrid from working

[Thibaut VARENE]

Package: flashybrid
Version: 0.17
Severity: normal
Tags: patch

Flashybrid init script is loaded too late in the boot process, rendering
the service unable to work since the underlying filesystem is already busy
(with files open for writing) at the time flashybrid tries to run.

Attached is a modified init script that starts in the S runlevel, as early
as possible in the boot process and fixes this issue.

I've also taken the liberty to quickly update the script to lsb functions.

HTH

T-Bone

-- System Information:
Debian Release: 7.2
Architecture: armhf (armv6l)

Kernel: Linux 3.6.11+ (PREEMPT)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages flashybrid depends on:
ii  debconf [debconf-2.0]  1.5.49
ii  rsync  3.0.9-4

flashybrid recommends no packages.

flashybrid suggests no packages.

-- Configuration Files:
/etc/flashybrid/config changed [not included]
/etc/flashybrid/ramstore changed [not included]
/etc/flashybrid/ramtmp changed [not included]
/etc/init.d/flashybrid changed [included]

-- debconf information:
* flashybrid/remove:
#!/bin/sh

# Set up/shutdown the flashybrid system, including the ramdisk and partial
# directory bind mounts. This needs to run at the part of system bootup that
# mounts all the disks. It should also run at shutdown right before
# filesystems are unmounted.

# Licensed under the terms of GPL v2
#  Diego Iastrubni diego.iastru...@xorcom.com 2006
#  Joey Hess jo...@debian.org 2002-2006


### BEGIN INIT INFO
# Provides:  flashybrid
# Required-Start:$local_fs
# Required-Stop: $local_fs
# Should-Start:  
# Should-Stop:   
# Default-Start: S
# Default-Stop:  0 1 6
# X-Start-Before:$network
# X-Stop-Before: $network
# Short-Description: automates use of a flash disk as the root filesystem
# Description:   Flashybrid is a system to help in setting up and managing hybrid
#flash/disk/ram based Debian systems which can run most of the time
#using only a small flash disk for their root filesystem and do a useful,
#but limited task (such as being a router, or a PDA, or a rescue system
#on a USB keydrive). The flash can be as small as 32 mb, though 64 to 256
#mb is more comfortable.
### END INIT INFO

. /lib/lsb/init-functions

CONFDIR=/etc/flashybrid
if [ -e $CONFDIR/config ]; then
	. $CONFDIR/config
fi

ENABLED=no
if [ -e /etc/default/flashybrid ]; then
	. /etc/default/flashybrid
fi

if [ -z $RAMMOUNT ]; then
	exit 0
fi

is_mounted () {
	grep -q  $1  /proc/mounts
}

case $1 in
start)
	if [ $ENABLED != yes ]; then
		log_warning_msg Not setting up flashybrid system: disabled.
		exit
	fi
	
	if [ ! -d $RAMMOUNT ] ; then
		log_failure_msg Error, RAMMOUNT directory is not found ($RAMMOUNT)
		exit 1
	fi
	
	log_daemon_msg Setting up flashybrid system for
		
	EXTRA_PARAMS=
	
	if [ xx$FLASH_MAX != xx ]; then
	EXTRA_PARAMS= -o size=$FLASH_MAX 
	fi
			
	# Set up ram disk to hold variable data.
	if ! is_mounted $RAMMOUNT; then
		mount tmpfs -t tmpfs $RAMMOUNT $EXTRA_PARAMS
	fi

	# Temporary directories on ram disk.
	cp $CONFDIR/ramtmp $RAMMOUNT/.fh-config-ramtmp
	for dir in $(grep -v '^#' $CONFDIR/ramtmp); do
		if [ -d $dir ]; then
		mkdir -p -m 1777 $RAMMOUNT/$dir
			if is_mounted $dir; then
umount $dir
			fi
			mount --bind $RAMMOUNT/$dir $dir
		fi
	done

	# when syncing we will use this configuration for restoring,
	# as the user may modify the configuration on the disk, and completely
	# mess up the system, eventually making his machine unusable
	cp $CONFDIR/ramstore $RAMMOUNT/.fh-config-ramstore
	
	# Copy data from flash to ram disk for these directories
	for dir in $(grep -v '^#' $CONFDIR/ramstore); do
		# Skip dirs that are not present.
		if [ -d $dir ]; then
			if [ $VERBOSE = yes ]; then
			log_progress_msg $dir
			fi
			
			ramdir=$RAMMOUNT$dir
			if is_mounted $dir; then
umount $dir
			fi
			
			if is_mounted $ramdir.flash; then
umount $ramdir.flash
			fi
			
			if [ ! -d $ramdir ]; then
mkdir -p ${ramdir%/*} # dirname
			cp -a $dir $ramdir
			fi			
			mkdir -p $ramdir.flash
			mount --bind $dir $ramdir.flash
			mount --bind $ramdir $dir
		fi
	done

	log_end_msg 0
	mountro
	;;

stop)
	if [ $ENABLED != yes ]; then
		log_warning_msg Not shutting down flashybrid system: disabled.
		exit
	fi
	
	fh-sync
	mountrw
	;;

reload)
	echo This target is available only for compatibility.
	echo Gracefully exiting
	;;

restart)
	echo This target is available only for compatibility, and usually will fail to work
	echo If you really want to restart this service please try 'force-reload'.
	echo 
	echo Gracefully exiting
	;;

force-reload)
	$0 stop
	$0 start
	;;

*)
	echo Usage: $0 {start|stop|restart|force-reload}
	exit 1
;;
esac

Bug#730744: apache2 stopped working with [error] (38)Function not implemented: apr_socket_accept: (client socket)

[Thibaut VARENE]

Package: apache2.2-common
Version: 2.2.22-13
Severity: normal

I can't tell whether that's an apache2 or libc bug, here's the story:

Apache suddenly stopped working (it was still working a week ago, and there was
no configuration change on the system in the interval). I suspect the last
logrotation triggered this, but unfortunately I can't track it down to an
upgraded packages: I run unattended-upgrades, but there's nothing in the logs
for that period, and I don't remember manually dist-upgrading either,
so I'm really clueless as to what broke.

Symptoms:

Apache won't serve any incoming connection, they just hang forever. Logs are
filled with:

[error] (38)Function not implemented: apr_socket_accept: (client socket)

strace'ing httpd -X shows:

open(/etc/group, O_RDONLY|O_CLOEXEC)  = 12
_llseek(12, 0, [0], SEEK_CUR)   = 0
fstat64(12, {st_mode=S_IFREG|0644, st_size=860, ...}) = 0
mmap2(NULL, 860, PROT_READ, MAP_SHARED, 12, 0) = 0x4802b000
_llseek(12, 860, [860], SEEK_SET)   = 0
fstat64(12, {st_mode=S_IFREG|0644, st_size=860, ...}) = 0
munmap(0x4802b000, 860) = 0
close(12)   = 0
setgroups(1, [33])  = 0
geteuid()   = 0
setuid(33)  = 0
epoll_create1(O_CLOEXEC)= 12
epoll_ctl(12, EPOLL_CTL_ADD, 5, {EPOLLIN, {u32=1220006224, 
u64=5239886832996450304}}) = 0
epoll_ctl(12, EPOLL_CTL_ADD, 4, {EPOLLIN, {u32=1220006256, 
u64=5239886970435403776}}) = 0
epoll_ctl(12, EPOLL_CTL_ADD, 3, {EPOLLIN, {u32=1220006288, 
u64=5239887107874357248}}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x48b81000
semop(1015808, {{0, -1, SEM_UNDO}}, 1)  = 0
epoll_wait(12, {{EPOLLIN, {u32=1220006224, u64=5239886832996450304}}}, 3, 
1) = 1
SYS_344(0x5, 0xbff0f62c, 0xbff0f618, 0x8, 0x1) = -1 ENOSYS (Function 
not implemented)
write(2, [Fri Nov 29 01:36:32 2013] [erro..., 100) = 100
semop(1015808, {{0, 1, SEM_UNDO}}, 1)   = 0
close(12)   = 0

This looks quite like the issue mentioned in this thread:
http://lists.debian.org/debian-powerpc/2013/06/msg5.html

In particular, I'm also running 2.6.32, which is the minimum version for
wheezy's glibc.

HTH

-- Package-specific info:
List of enabled modules from 'apache2 -M':
  actions* alias auth_basic authn_file authz_default authz_groupfile
  authz_host authz_user autoindex cgi deflate dir env include mime
  negotiation php5 reqtimeout setenvif status userdir
  (A * means that the .conf file for that module is not enabled in
   /etc/apache2/mods-enabled/)
List of enabled php5 extensions:
  ldap mcrypt mysql mysqli pdo pdo_mysql

-- System Information:
Debian Release: 7.2
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: powerpc (ppc)

Kernel: Linux 2.6.32.61
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages apache2 depends on:
ii  apache2-mpm-prefork  2.2.22-13
ii  apache2.2-common 2.2.22-13

apache2 recommends no packages.

apache2 suggests no packages.

Versions of packages apache2.2-common depends on:
ii  apache2-utils  2.2.22-13
ii  apache2.2-bin  2.2.22-13
ii  lsb-base   4.1+Debian8+deb7u1
ii  mime-support   3.52-1
ii  perl   5.14.2-21+deb7u1
ii  procps 1:3.3.3-3

Versions of packages apache2.2-common recommends:
ii  ssl-cert  1.0.32

Versions of packages apache2.2-common suggests:
pn  apache2-doc none
pn  apache2-suexec | apache2-suexec-custom  none
ii  elinks [www-browser]0.12~pre5-9
ii  lynx-cur [www-browser]  2.8.8dev.12-2

-- 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#708307: e2fsprogs: fsck.ext3 on ia64 is linked to /usr/lib/libunwind, which can live on a different partition, breaking boot

[Thibaut VARENE]

On Thu, May 16, 2013 at 4:58 AM, Theodore Ts'o ty...@mit.edu wrote:

 On Wed, May 15, 2013 at 01:57:25AM +0200, Thibaut VARENE wrote:
  Package: e2fsprogs
  Version: 1.42.5-1.1
  Severity: grave
  Justification: renders package unusable

 #1) This looks to be ia64 specific.  This is the output of ldd
 /sbin/fsck.ext3 on an x86-64 platform:


Indeed. I've also checked PPC and fsck.ext3 is good as well there.
But a little more digging shows something rather frightening: this bug (of
linking from /usr) is quite widespread.
I've run a quick check on some of my machines (they have different sets of
package installed):

$ for b in /bin/* /sbin/* ; do ldd $b | grep -q /usr/  echo $b ; done

on amd64:
/bin/ping6
/sbin/crda
/sbin/discover
/sbin/nfnl_osf
/sbin/regdbdump
/sbin/umount.udisks
/sbin/wpa_supplicant

on ppc:
/sbin/fsck.cramfs
/sbin/mkfs.cramfs

on ia64:
/bin/ping6
/sbin/dhclient
/sbin/dhclient3
/sbin/e2fsck
/sbin/fsck.ext2
/sbin/fsck.ext3
/sbin/fsck.ext4
/sbin/fsck.ext4dev
/sbin/parted
/sbin/partprobe

on kfreebsd_amd64:
/sbin/camcontrol
/sbin/ccdconfig
/sbin/devd
/sbin/fsck.cramfs
/sbin/fsdb.ufs
/sbin/ifconfig
/sbin/mdconfig
/sbin/mkfs.cramfs
/sbin/mount_cd9660
/sbin/mount_msdosfs
/sbin/mount_ntfs
/sbin/mount_udf

I'm quite surprised, I'd have expected lintian to catch these types of
problems.

#2)  We need to determine whether it's /sbin/fsck.ext3 or one of its
  shared libraries which is depending upon which is pulling in
  libunwind.

  Can you run the command objdump -p /sbin/fsck.ext3 | grep
  NEEDED?  On my x86-64 system, this is what I see:

   NEEDED   libext2fs.so.2
   NEEDED   libcom_err.so.2
   NEEDED   libblkid.so.1
   NEEDED   libuuid.so.1
   NEEDED   libe2p.so.2
   NEEDED   libc.so.6

  Then do a recursive expansion of each of the libraries which you
  see, i.e. replace /sbin/fsck.ext3 with /lib/*/libblkid.so.1, etc.


Didn't have to recurse very far:

$ objdump -p /sbin/fsck.ext3 | grep NEEDED
  NEEDED   libext2fs.so.2
  NEEDED   libcom_err.so.2
  NEEDED   libblkid.so.1
  NEEDED   libuuid.so.1
  NEEDED   libe2p.so.2
  NEEDED   libunwind.so.7
  NEEDED   libc.so.6.1

none of the other NEEDED libraries pull in libunwind or anything suspicious.

HTH
T-Bone

-- 
Thibaut VARENE
http://hacks.slashdirt.org/

Bug#708307: e2fsprogs: fsck.ext3 on ia64 is linked to /usr/lib/libunwind, which can live on a different partition, breaking boot

[Thibaut VARENE]

Package: e2fsprogs
Version: 1.42.5-1.1
Severity: grave
Justification: renders package unusable

This bug affects wheezy. Trying to upgrade one of my ia64 boxes from squeeze
to wheezy turned into a non-booting system because:

Checking root file system...fsck from util-linux 2.20.1
fsck.ext3: error while loading shared libraries: libunwind.so.7: cannot open 
shared object file: No such file or directory
fsck died with exit status 127
failed (code 127).
An automatic file system check (fsck) of the root filesystem failed. A manual 
fsck must be performed, then the system restarted. The fsck should be performed 
in maintenance mode with the root filesystem mounted in read-only mode. ... 
failed!
The root filesystem is currently mounted in read-only mode. A maintenance shell 
will now be started. After performing system maintenance, press CONTROL-D to 
terminate the maintenance shell and restart the system. ... (warning).
Give root password for maintenance
(or type Control-D to continue): 

And then the problem is that:
ldd /sbin/fsck.ext3
linux-gate.so.1 =  (0xa000)
libext2fs.so.2 = /lib/ia64-linux-gnu/libext2fs.so.2 
(0x200800054000)
libcom_err.so.2 = /lib/ia64-linux-gnu/libcom_err.so.2 
(0x2008000e8000)
libblkid.so.1 = /lib/ia64-linux-gnu/libblkid.so.1 (0x20080010)
libuuid.so.1 = /lib/ia64-linux-gnu/libuuid.so.1 (0x20080016)
libe2p.so.2 = /lib/ia64-linux-gnu/libe2p.so.2 (0x200800178000)
HERE - libunwind.so.7 = /usr/lib/libunwind.so.7 (0x20080019c000)
libc.so.6.1 = /lib/ia64-linux-gnu/libc.so.6.1 (0x2008001e8000)
libpthread.so.0 = /lib/ia64-linux-gnu/libpthread.so.0 
(0x200800478000)
/lib/ld-linux-ia64.so.2 (0x2008)

(don't ask me why it links libunwind, btw)

The problem is that fsck is a program that lives in /sbin, and it links a
library that lives in /usr, which can (and in this particular case does) reside
on a different filesystem, which will no be mounted at the time of the rootfs
filesystem check. That's an obvious violation of everything sacred, it kills
kittens, etc.

Please fix.

T-Bone

PS: sending this report from another machine as reportbug still ignores
http_proxy whenever it pleases.

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: ia64

Kernel: Linux 2.6.27.39 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash


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

Bug#698746: NMU for experimental

[Thibaut VARENE]

On Fri, May 10, 2013 at 3:50 PM, micah mi...@riseup.net wrote:

 micah mi...@debian.org writes:

  micah anderson mi...@debian.org writes:
 
  Hi,
 
  I'd like to propose that this bug be fixed in an upload to experimental,
  and I am willing to do the NMU for that.
 
  I don't suggest this to push you, or be aggressive or step on your
  work. I know some people have some of those feelings about NMUs, I only
  offer the NMU in the spirit of respect and help. So please do let me
  know as soon as possible if that is not desirable, otherwise I will
  prepare one.
 
  Hello - now that wheezy has released, it would be really useful if this
  was available in sid. I've been using this for a while now and it works
  really well.
 
  Do you have plans for a sid upload soon, or would you like me to just
  push this there?

 By the way, the patch in question has been merged in upstream libotr
 now.

 Sorry for the delayed answer, mail relay was down.
I don't have any particular reason to upload a new version to sid just yet
so feel free to push your NMU. Might as well bump standards version in the
process ;)

Thx

-- 
Thibaut VARENE
http://hacks.slashdirt.org/

Bug#698746: NMU for experimental

[Thibaut VARENE]

On Fri, Mar 1, 2013 at 3:07 AM, Ian Goldberg i...@cs.uwaterloo.ca wrote:

 On Tue, Feb 26, 2013 at 07:24:38PM -0500, micah anderson wrote:
  The patch has been merged into the upstream staging repository.
 
  I've CC'd upstream on this issue, could one of you give the go ahead?
 
  It is a bit of a chicken and egg thing because it would help a lot of
  this could get more testing, but if it isn't put somewhere that can get
  more testing... hence the idea to put it into experimental where people
  who chose to can give it a try.

 We're talking about the patch below, right?  If so, yes, feel free to
 include it; it will be in the next release of libotr.  It's clear that
 it was a bug, and that this patch is the correct fix.


Thanks!

Micah, I unfortunately don't have time to prepare an experimental upload
now, so feel free to do it.

Best

-- 
Thibaut VARENE
http://hacks.slashdirt.org/

Bug#698746: NMU for experimental

[Thibaut VARENE]

On Tue, Feb 26, 2013 at 2:21 AM, micah anderson mi...@debian.org wrote:


 Hi,

 I'd like to propose that this bug be fixed in an upload to experimental,
 and I am willing to do the NMU for that.

 I don't suggest this to push you, or be aggressive or step on your
 work. I know some people have some of those feelings about NMUs, I only
 offer the NMU in the spirit of respect and help. So please do let me
 know as soon as possible if that is not desirable, otherwise I will
 prepare one.

 Hi,

I would very much like to get a go from upstream before changing their
source. Which is why I haven't applied this patch yet.

Thanks

-- 
Thibaut VARENE
http://hacks.slashdirt.org/

Bug#698449: pidgin-otr: French translation does not properly report security status of a discussion

[Thibaut VARENE]

Hi,

Can you sync with the release team to see if they're OK pushing this to
wheezy?

Thank you.


On Fri, Jan 18, 2013 at 6:49 PM, intrig...@debian.org wrote:

 Package: pidgin-otr
 Version: 3.2.1-3
 Severity: important
 Tags: security

 Hi,

 the 3.2.1 upstream release brought in an updated French translation,
 which was great.

 Unfortunately, this translation has a few bugs, among which some are
 serious: a few missing %s placeholders make it so the OTR user is not
 correctly made aware of the security status of the current discussion.
 I'm specifically thinking of strings such as La confidentialité de
 cette conversation est désormais : that lacks the %s.

 I believe that failing to communicate their current security level to
 the user, in an implementation of OTR, has a (admittedly, non
 critical) security impact. I think this should be fixed in Wheezy.

 Upstream 4.0.0 shipped with a reworked French translation that fixes
 these problems. Unfortunately, this new upstream release was uploaded
 to unstable, so the translation fix will have to go through t-p-u :(

 I'll shortly provide a patch that fixes the worse problems, as well as
 a few trivial typo fixes.

 Cheers,
 --
   intrigeri
   | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
   | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc

 --
 Thibaut VARENE
 http://hacks.slashdirt.org/
 https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc

Bug#696097: libotr: stopped building libotr2-dev which is still used

[Thibaut VARENE]

No. See #692327

On Sun, Dec 16, 2012 at 6:21 PM, Thorsten Glaser t...@mirbsd.de wrote:
 Source: libotr
 Version: 4.0.0-2
 Severity: grave
 Justification: lets unrelated software FTBFS

 Hi,

 packages such as src:kdenetwork build-depend on libotr2-dev
 which used to be provided by src:libotr but which stopped
 building it. The situation is akin to the openssl versus
 openssl0.9.8 and tiff3 versus tiff4 situation.

 Please provide a libotr2 (or something) source package which
 will build libotr2-dev and related binary packages until such
 time as those are no longer needed.

 bye,
 //mirabilos
 --
 I want one of these. They cost 720 € though… good they don’t have the HD hole,
 which indicates 3½″ floppies with double capacity… still. A tad too much, atm.
 ‣ http://www.floppytable.com/floppytable-images-1.html



-- 
Thibaut VARENE
http://hacks.slashdirt.org/


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

Bug#692327: libotr: Please provide libotr2

[Thibaut VARENE]

On Tue, Nov 6, 2012 at 10:48 AM, Philipp Kern pk...@debian.org wrote:
 On Mon, Nov 05, 2012 at 03:04:21PM +0100, Thibaut VARENE wrote:
 I thought that Wheezy having been frozen for quite some time, it was okay
 to upload new packages to unstable again.

 I'm sure we would've communicated that on d-d-a if this would've been
 the case.

Okay then. Wheezy has been frozen for 4 months already. Out of
curiosity, how long will we have to wait before new software can be
pushed again to Debian?

 (Also please don't put a  before the lines you wrote yourself.)

I blame Gmail's silly new interface :-P

Best

--
Thibaut VARENE
http://hacks.slashdirt.org/


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

Bug#692327: libotr: Please provide libotr2

[Thibaut VARENE]

On Tue, Nov 6, 2012 at 1:04 PM, Neil Williams codeh...@debian.org wrote:
 On Tue, 6 Nov 2012 10:59:42 +0100
 Thibaut VARENE vare...@debian.org wrote:

 On Tue, Nov 6, 2012 at 10:48 AM, Philipp Kern pk...@debian.org wrote:
  On Mon, Nov 05, 2012 at 03:04:21PM +0100, Thibaut VARENE wrote:
  I thought that Wheezy having been frozen for quite some time, it was okay
  to upload new packages to unstable again.
 
  I'm sure we would've communicated that on d-d-a if this would've been
  the case.

 Okay then. Wheezy has been frozen for 4 months already. Out of
 curiosity, how long will we have to wait before new software can be
 pushed again to Debian?

 If it's targeting experimental, that is already possible and has never
 been a problem.

 If it's to target unstable then expect an announcement on d-d-a to the
 effect that unstable is now open again a few days after the Wheezy
 release. (Release, not freeze). i.e. around the time that Jessie
 becomes available as the new testing.

 Note that from past experience, it's not advisable to upload very soon
 after the d-d-a announcement anyway. So many other packages get
 uploaded at that point that many dependencies become uninstallable. Talk
 to maintainers of packages which your package needs and co-ordinate in
 advance.

 If you want it in Debian now, push it into experimental. If you want it
 Jessie (the next testing), then wait for the d-d-a announcement. If you
 wanted it in Wheezy it's too late. If you just wanted it in unstable
 then it's clear that this is not desirable and your only option is
 experimental.

Noted. The package was in experimental for several weeks and got zero
attention. My general understanding is that nobody looks at
experimental anyway. Another part of the issue was upstream's will to
have it in Ubuntu as soon as possible. Ubuntu autosync doesn't fetch
from experimental.

--
Thibaut VARENE
http://hacks.slashdirt.org/


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

Bug#692327: libotr: Please provide libotr2

[Thibaut VARENE]

On Tue, Nov 6, 2012 at 2:43 PM, Neil Williams codeh...@debian.org wrote:

 Having a freeze simply means that some package changes *must* be
 delayed until after the freeze. Experimental works for some, if it
 doesn't work for you then you cannot update the package in Debian until
 the release, so maybe help get the release out.

I believe I was mistaken as to what a freeze is. To me the freeze
impacted testing, not unstable, being the whole purpose of a freeze,
i.e. ensuring that new packages in unstable don't make it to
testing-soon-to-be-stable. I didn't realize this meant that /unstable/
was to be considered as frozen too. Maybe it should effectively be so,
so that new packages that aren't RC fixes can't even be uploaded to
sid. This would avoid something like this happening again in the
future.

Anyway, I stand corrected.

That being said, I'd like to point out again that all this fuss was
made for nothing, since none of the packages listed in the initial
email are being blocked from entering wheezy because of this upload,
since none of them are unfrozen, and wheezy is unaffected by this
change. And I see nothing wrong with breaking packages in unstable,
but maybe there too I'm mistaken.

--
Thibaut VARENE
http://hacks.slashdirt.org/


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

Bug#692327: libotr: Please provide libotr2

[Thibaut VARENE]

severity 692327 important
thanks

On Mon, Nov 5, 2012 at 1:32 AM, Dmitrijs Ledkovs x...@debian.org wrote:

 Package: libotr, release.debian.org
 Severity: serious
 User: release.debian@packages.debian.org
 Usertags: transition

 Recently libotr has been updated to version 4.x.x with binary package
 name libotr5.

 By the looks of things, it was done because of pidgin-otr package which
 now requires libotr5.


It was done because upstream has updated their source and the new libotr is
incompatible with the old one.


 But this means an un-coordinated transition has started, as there are 6
 other packages that build-depend on libotr2-dev and all of them fail to
 build from source against libotr5-dev:


I was not aware a coordinated transition was necessary for such a small
library. I'm under the impression the release team has bigger fish to fry
right now.


 * bitlbee
 * irssi-plugin-otr
 * kdenetwork
 * mcabber
 * psi-plus
 * python-otr

 Please do something to resolve this. Input from release team is highly
 welcome.

 Possibilities I can think of are:
 * revert libotr source package to 3.2.1-1  upload libotr5 (4.0.0-2)
 source package


No. Upstream will not provide maintenance for 3.x.


 * keep libotr source package as it is, upload libotr2 (3.2.1-1) source
 package


No. See above.


 * provide patches/NMUs to fix FTBFS for above packages when built
   against libotr5-dev.


How about letting their upstreams doing their jobs? libotr 3.x is gone, I'm
sure they'll wake up eventually.


 Usually disruptive uploads like this one, should be co-ordinated with
 the release team with a transition bug, and staged in experimental to do
 test rebuilds.


I don't see how this is a serious bug.
1) it only affects unstable (which is named so for a reason)
2) libotr5 has been sitting in experimental for quite a while, and upstream
devs have been quite vocal about the transition
3) libotr5 can be installed alongside libotr2

kthxbye

-- 
Thibaut VARENE
http://hacks.slashdirt.org/

Bug#692327: libotr: Please provide libotr2

[Thibaut VARENE]

On Mon, Nov 5, 2012 at 2:36 PM, Julien Cristau jcris...@debian.org wrote:

 On Mon, Nov  5, 2012 at 11:58:12 +0100, Thibaut VARENE wrote:

  severity 692327 important
  thanks
 
  On Mon, Nov 5, 2012 at 1:32 AM, Dmitrijs Ledkovs x...@debian.org
 wrote:
 
   Package: libotr, release.debian.org
   Severity: serious
   User: release.debian@packages.debian.org
   Usertags: transition
  
   Recently libotr has been updated to version 4.x.x with binary package
   name libotr5.
  
   By the looks of things, it was done because of pidgin-otr package which
   now requires libotr5.
  
 
  It was done because upstream has updated their source and the new libotr
 is
  incompatible with the old one.
 
 Which means it's not an appropriate change during a freeze.

 I thought that Wheezy having been frozen for quite some time, it was okay
to upload new packages to unstable again. Please note in passing that
libotr5, being NEW, went through the NEW queue and was reviewed at that
time.


 
   But this means an un-coordinated transition has started, as there are 6
   other packages that build-depend on libotr2-dev and all of them fail to
   build from source against libotr5-dev:
  
 
  I was not aware a coordinated transition was necessary for such a small
  library. I'm under the impression the release team has bigger fish to fry
  right now.
 
 Which is why they very much don't appreciate this kind of disruption.
 A SONAME bump in a library right now in sid is not welcome, and needs to
 wait until the wheezy release.  Please revert.

 That wasn't obvious to me. What do you mean revert? I cannot upload a
package with an older revision.

-- 
Thibaut VARENE
http://hacks.slashdirt.org/

Bug#692327: libotr: Please provide libotr2

[Thibaut VARENE]

On Mon, Nov 5, 2012 at 2:32 PM, Dmitrijs Ledkovs x...@debian.org wrote:

 On 05/11/12 10:58, Thibaut VARENE wrote:
  severity 692327 important
  thanks
 
  I don't see how this is a serious bug.

 Currently libotr2* are not build from any source package in sid.
 That means that any packages depending on it cannot transition into
 testing (if it was not frozen).


Is there such a not frozen package?


 That also means that libotr5 cannot transition into testing (if it was
 not frozen).


That was never the plan, considering libotr5 got uploaded (purposefully)
after the freeze.


 Sure it's not a problem. But if the existing status quo is kept, neither
 libotr5 nor the new pidgin will make it into wheezy nor jessie.


That it won't make it to wheezy, I can see why and that's intended. I don't
see how jessie is affected. My package is fine, pidgin-otr is fine, and
they both work. The other packages that depend on libotr need to update,
and again, I don't see why they wouldn't considering that libotr5 is the
NEW libotr. Or are you suggesting that for the sake of the argument, all
dependencies are going to stick using libotr2 just to piss me off?


 Your package is not fit for inclusion in a stable release.


Really? That's news to me.


 Given your position, maybe you should file removal requests for package
 that still depend on libotr2.


I don't see a need for that when all it takes to resolve this issue is
an update from the dependent packages. If we were to request package
removal everytime a new library breaks its API, things would get pretty
ugly (and by that I mean, more than they usually are).


 In Ubuntu, I have uploaded libotr2 source package to transition libotr5
 into testing and keep all applications that use libotr2 or libotr5
 installable and releasable.


Very nice. Enjoy dealing with the innevitable mess this will provoke.


-- 
Thibaut VARENE
http://hacks.slashdirt.org/

Bug#686463: RM: lomoco/1.0beta1+1.0-5

[Thibaut VARENE]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm

Dead upstream, orphaned.

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-2-amd64 (SMP w/32 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


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

Bug#686463: followup

[Thibaut VARENE]

 Adam D. Barratt a...@adam-barratt.org.uk

 In that case, would it not make more sense to remove it from unstable?

Sure, why not. Removing it from the upcoming stable distribution is
really necessary anyway.

-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/


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

Bug#563061: Same here

[Thibaut VARENE]

exactly the same problem here, there's apparently no other way to
disable this stupid line than commenting out lines 129-132 in
/usr/lib/grub-mkconfig_lib

I have no idea why this line makes the boot fail.

-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/


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

Bug#685664: libotr: Please package 4.0 branch in experimental

[Thibaut VARENE]

In NEW queue. I'll see if I have time to deal with pidgin-otr later on.

HTH

On Thu, Aug 23, 2012 at 8:48 AM, Jérémy Bobbio lu...@debian.org wrote:
 Package: libotr
 Severity: wishlist

 Hi!

 Upstream has released the first release candidate for the 4.0 branch:
 http://www.cypherpunks.ca/pipermail/otr-dev/2012-August/001376.html

 It would be great to have it in experimental.

 Thanks,
 --
 Jérémy Bobbio.''`.
 lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
 `. `'`
   `-

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.10 (GNU/Linux)

 iQIcBAEBCAAGBQJQNdIlAAoJEEgU3sIrMHw87X0P/2TJm2gWiTaB3Eyzthu8hcMZ
 01MbFyeMuJqNImS00O0iDEr692nv/TIHHVFB0EEM3UpwqVosY7Dh3zv5IuUt2qie
 hoAyEXrxDhrXyHGskFzRnWqHTjHUyFq7XNrXdW2AnwTBZ6ig8+T+5k0TUjZFWnku
 MZmwiHOCMOpEADjYiZ+ZDyldDCxlj+ba2d5HRQiSCBref21ZDMBrS2+hoeEtuMod
 b22Oanx0YWPmEe6lwj1S9edUb7WgmFuq09ZpEaqvYgMlx22wNOqYVV5lTntHIMtr
 FYPyPaqt14o960F+Tsp4vDrUidEfxIyNQh6R5jpMVpY7PxIrBY4ill9w7mf5i8R4
 SeTOAseOdAiCksanY9meuDzSbTOC9Q5cb87WE2dtpiUjOvzYODlYulTU9juHLE9x
 h5BLEhAaB4me/J6h/PQYx+v1qZcWfCU+Ye0ohQxj3FJMv+ZZWUwveOaTXaFsaOIZ
 useol4pJWTFlVsavmchqU+JDWy/PPLpQMHOUeVz3qk73hsrZmJ3i+blFi3scF7nE
 vU8kiBvr7Kv6gEK80juz6Sxk7q4XPSD75n0qqHkgGt9i/RoxxDsHUtVGr0jwELOt
 sPTnm0xQYYq7bf3sQJwH1lMPS+vqhbM+ccyygmbolAXMowGAZ+J2pWF+anlNUPlP
 gygfIBBNr4dJRuO93dh4
 =twCB
 -END PGP SIGNATURE-




-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/


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

Bug#685664: libotr: Please package 4.0 branch in experimental

[Thibaut VARENE]

On Fri, Aug 24, 2012 at 9:13 PM, Ian Goldberg i...@cs.uwaterloo.ca wrote:
 On Fri, Aug 24, 2012 at 06:05:18PM +0200, Thibaut VARENE wrote:
 In NEW queue. I'll see if I have time to deal with pidgin-otr later on.

 Please do not package libotr 4 yet.  The release candidate is not
 working properly; see otr-dev.

OK. Can you keep me posted? I'm not subscribed to otr-dev...

There's not much harm done either, it's uploaded to experimental,
which is for packages that are expected to be broken anyway ;-)

Cheers

-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/


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

Bug#684140: unblock: libotr/3.2.1-1

[Thibaut VARENE]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package libotr

Fixes security hole (possible buffer overflow in base64 routines): #684121

The only change from 3.2.0-4 (currently in wheezy) and 3.2.1-1 is the security
fix, see the attached debdiff.

unblock libotr/3.2.1-1

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: ia64

Kernel: Linux 2.6.29.2 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
diff -Nru libotr-3.2.0/ChangeLog libotr-3.2.1/ChangeLog
--- libotr-3.2.0/ChangeLog	2008-06-15 22:16:34.0 +0200
+++ libotr-3.2.1/ChangeLog	2012-08-07 12:21:35.0 +0200
@@ -1,3 +1,20 @@
+2012-07-27
+
+	* src/version.h: Update libotr version number to 3.2.1
+
+2012-07-19
+
+	* src/b64.[ch], src/proto.c, toolkit/parse.c: Clean up the
+	previous b64 patch and apply it to all places where
+	otrl_base64_decode() is called.
+
+2012-07-17
+
+	* src/b64.c: Use ceil instead of floor to compute the size
+	of the data buffer.  This prevents a one-byte heap buffer
+	overflow.  Thanks to Justin Ferguson jnfergu...@gmail.com
+	for the report.
+
 2008-06-15:
 
 	* README: Release version 3.2.0.
diff -Nru libotr-3.2.0/debian/changelog libotr-3.2.1/debian/changelog
--- libotr-3.2.0/debian/changelog	2011-12-26 18:34:38.0 +0100
+++ libotr-3.2.1/debian/changelog	2012-08-07 12:25:12.0 +0200
@@ -1,3 +1,9 @@
+libotr (3.2.1-1) unstable; urgency=high
+
+  * Fix potential buffer overflow in base64 routines (Closes: #684121)
+
+ -- Thibaut VARENE vare...@debian.org  Tue, 07 Aug 2012 12:24:15 +0200
+
 libotr (3.2.0-4) unstable; urgency=low
 
   * lintian cleanup:
diff -Nru libotr-3.2.0/src/b64.c libotr-3.2.1/src/b64.c
--- libotr-3.2.0/src/b64.c	2008-05-27 14:35:28.0 +0200
+++ libotr-3.2.1/src/b64.c	2012-08-07 12:21:31.0 +0200
@@ -55,7 +55,7 @@
 \*** */
 
 /* system headers */
-#include stdlib.h
+#include stdio.h
 #include string.h
 
 /* libotr headers */
@@ -147,8 +147,9 @@
  * base64 decode data.  Skip non-base64 chars, and terminate at the
  * first '=', or the end of the buffer.
  *
- * The buffer data must contain at least (base64len / 4) * 3 bytes of
- * space.  This function will return the number of bytes actually used.
+ * The buffer data must contain at least ((base64len+3) / 4) * 3 bytes
+ * of space.  This function will return the number of bytes actually
+ * used.
  */
 size_t otrl_base64_decode(unsigned char *data, const char *base64data,
 	size_t base64len)
@@ -234,13 +235,18 @@
 	return -2;
 }
 
+/* Skip over the ?OTR: */
+otrtag += 5;
+msglen -= 5;
+
 /* Base64-decode the message */
-rawlen = ((msglen-5) / 4) * 3;   /* maximum possible */
+rawlen = OTRL_B64_MAX_DECODED_SIZE(msglen);   /* maximum possible */
 rawmsg = malloc(rawlen);
 if (!rawmsg  rawlen  0) {
 	return -1;
 }
-rawlen = otrl_base64_decode(rawmsg, otrtag+5, msglen-5);  /* actual size */
+
+rawlen = otrl_base64_decode(rawmsg, otrtag, msglen);  /* actual size */
 
 *bufp = rawmsg;
 *lenp = rawlen;
diff -Nru libotr-3.2.0/src/b64.h libotr-3.2.1/src/b64.h
--- libotr-3.2.0/src/b64.h	2008-05-27 14:35:28.0 +0200
+++ libotr-3.2.1/src/b64.h	2012-08-07 12:21:31.0 +0200
@@ -20,6 +20,19 @@
 #ifndef __B64_H__
 #define __B64_H__
 
+#include stdlib.h
+
+/* Base64 encodes blocks of this many bytes: */
+#define OTRL_B64_DECODED_LEN 3
+/* into blocks of this many bytes: */
+#define OTRL_B64_ENCODED_LEN 4
+
+/* An encoded block of length encoded_len can turn into a maximum of
+ * this many decoded bytes: */
+#define OTRL_B64_MAX_DECODED_SIZE(encoded_len) \
+(((encoded_len + OTRL_B64_ENCODED_LEN - 1) / OTRL_B64_ENCODED_LEN) \
+	* OTRL_B64_DECODED_LEN)
+
 /*
  * base64 encode data.  Insert no linebreaks or whitespace.
  *
@@ -33,8 +46,9 @@
  * base64 decode data.  Skip non-base64 chars, and terminate at the
  * first '=', or the end of the buffer.
  *
- * The buffer data must contain at least (base64len / 4) * 3 bytes of
- * space.  This function will return the number of bytes actually used.
+ * The buffer data must contain at least ((base64len+3) / 4) * 3 bytes
+ * of space.  This function will return the number of bytes actually
+ * used.
  */
 size_t otrl_base64_decode(unsigned char *data, const char *base64data,
 	size_t base64len);
diff -Nru libotr-3.2.0/src/proto.c libotr-3.2.1/src/proto.c
--- libotr-3.2.0/src/proto.c	2008-05-27 14:35:28.0 +0200
+++ libotr-3.2.1/src/proto.c	2012-08-07 12:21:31.0 +0200
@@ -537,13 +537,17 @@
 	msglen = strlen(otrtag);
 }
 
+/* Skip over the ?OTR: */
+otrtag += 5;
+msglen -= 5;
+
 /* Base64-decode the message */
-rawlen = ((msglen-5) / 4) * 3;   /* maximum possible */
+rawlen = OTRL_B64_MAX_DECODED_SIZE(msglen

Bug#684121: libotr2: Buffer overflows in libotr

[Thibaut VARENE]

Hi,

I just uploaded 3.2.1-1 to unstable, it contains the changes listed here:

http://otr.git.sourceforge.net/git/gitweb.cgi?p=otr/libotr;a=log;h=refs/heads/3.2_dev

I'm CC'ing security as I suppose they might want to push this package
to unstable as well.

Note, the only difference between 3.2.0-4 (currently in testing) and
3.2.1-1 (just uploaded to unstable) is the security fix, see the
attached debdiff on the unblock request #684140.

The only difference between 3.2.0-2 in stable and 3.2.0-4 in testing
are packaging cosmetics (shipping .pc, null out dependency_libs in .la
and lintian fixes).

HTH

On Tue, Aug 7, 2012 at 9:42 AM, Göran Weinholt go...@weinholt.se wrote:
 Package: libotr2
 Version: 3.2.0-4
 Severity: grave
 Tags: security upstream
 Justification: user security hole

 libotr contains buffer overflows in a few base64 decoding functions:
 http://lists.cypherpunks.ca/pipermail/otr-dev/2012-July/001347.html

 Fixes for the bugs are available from git:
 http://lists.cypherpunks.ca/pipermail/otr-dev/2012-July/001348.html



 -- System Information:
 Debian Release: wheezy/sid
   APT prefers testing
   APT policy: (500, 'testing')
 Architecture: amd64 (x86_64)

 Kernel: Linux 3.2.0-3-amd64 (SMP w/8 CPU cores)
 Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/bash

 Versions of packages libotr2 depends on:
 ii  libc62.13-33
 ii  libgcrypt11  1.5.0-3

 libotr2 recommends no packages.

 Versions of packages libotr2 suggests:
 ii  libotr2-bin  3.2.0-4

 -- no debconf information

-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/


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

Bug#682617: O: lomoco

[Thibaut VARENE]

Package: wnpp
Severity: normal

Moving on with #669614, it's time to orphan this package.

Note to release manager: I don't think it should be part of wheezy, feel free 
to remove it from testing.

HTH

T-Bone


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

Bug#680419: uptimed: dpkg cannot configure uptimed

[Thibaut VARENE]

title 680419 uptimed fails to configure on upgrade if config file is missing
severity 680419 normal
thanks

On Thu, Jul 5, 2012 at 8:27 PM, Ian Campbell i...@hellion.org.uk wrote:
 Package: uptimed
 Version: 1:0.3.17-3.1
 Severity: important

 Dear Maintainer,

 A recent upgrade attempt failed with:
 Preparing to replace uptimed 1:0.3.17-3 (using 
 .../uptimed_1%3a0.3.17-3.1_amd64.deb) ...
 [...]
 Setting up uptimed (1:0.3.17-3.1) ...
 /var/lib/dpkg/info/uptimed.postinst: line 39: /etc/uptimed.conf: No such 
 file or directory
 dpkg: error processing uptimed (--configure):
  subprocess installed post-installation script returned error exit status 
 1

 and indeed I found that /etc/uptimed.conf did not exist. However I did
 have /etc/uptimed.conf.dpkg-old. I moved it to /etc/uptimed.conf and ran dpkg
 --configure -a which succeeded. Now I have:

Hi

I can't reproduce your bug unless I manually remove /etc/uptimed.conf
first. I don't know how much of a bug it is to have upgrade configure
fail on missing config file. Maybe it should fail gracefully.
Nonetheless, it's possible to apt-get remove the package anyway and
install it back again afterwards.

Since this is not a typical use case of the software and since it
doesn't affect the normal upgrade path, I'm downgrading this bug to
normal.

Thanks

-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/



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

Bug#671034: [ia64] linux fails to load INIT (Still affects 3.2.19-1)

[Thibaut VARENE]

On Wed, Jun 27, 2012 at 12:46 PM, Thibaut VARENE vare...@debian.org wrote:
 On Wed, Jun 27, 2012 at 7:11 AM, Jonathan Nieder jrnie...@gmail.com wrote:
 Thibaut VARENE wrote:

 Sadly I don't have testing points between Squeeze's kernel (which
 works) and the first kernel with which I reported the issue...

 For concreteness: do you mean that 2.6.32-45 works or some earlier
 kernel that was in squeeze?

 I have 2.6.32-31 running on a similar machine. I'll see about
 2.6.32-45 and will report back.

2.6.32-45 works

HTH


-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/



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

Bug#671034: [ia64] linux fails to load INIT (Still affects 3.2.19-1)

[Thibaut VARENE]

On Wed, Jun 27, 2012 at 7:11 AM, Jonathan Nieder jrnie...@gmail.com wrote:
 Thibaut VARENE wrote:

 Sadly I don't have testing points between Squeeze's kernel (which
 works) and the first kernel with which I reported the issue...

 For concreteness: do you mean that 2.6.32-45 works or some earlier
 kernel that was in squeeze?

I have 2.6.32-31 running on a similar machine. I'll see about
2.6.32-45 and will report back.

 If you suddenly find yourself with a lot of time and no idea what to
 do with it, there are pre-compiled kernels in between (e.g., 2.6.35)
 available from http://snapshot.debian.org/.  I don't think anyone
 on ia64 was tracking experimental, so there's not much reason to
 believe in the quality of those kernels, but it would be interesting
 to see roughly when the bug was introduced.

 Though the symptoms are different, I wonder how much of this bug
 related to #595502.

 I hope not much. :)

 Thanks,
 Jonathan



-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/



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

Bug#671034: Still affects 3.2.19-1

[Thibaut VARENE]

Package: linux-image-3.2.0-2-mckinley
Version: 3.2.19-1

-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/



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

Bug#671034: [ia64] linux fails to load INIT (Still affects 3.2.19-1)

[Thibaut VARENE]

On Wed, Jun 27, 2012 at 1:51 AM, Jonathan Nieder jrnie...@gmail.com wrote:
 severity 671034 important
 quit

 Hi Thibaut,

 Thibaut VARENE wrote:

 [Subject: Bug#671034: Still affects 3.2.19-1]

 Please keep in mind that these appear as emails in a crowded inbox, so
 the subject line can be a good place to put valuable context.

 Version: 3.2.19-1

 Thanks for the update.  Was this a regression?  What is the last
 kernel that worked?

Sadly I don't have testing points between Squeeze's kernel (which
works) and the first kernel with which I reported the issue...

Though the symptoms are different, I wonder how much of this bug
related to #595502. Note that the latter didn't affect this particular
hardware...

HTH

-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/



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

Bug#674860: uptimed: General update after the debconf review process

[Thibaut VARENE]

On Sat, Jun 16, 2012 at 4:56 PM, Christian PERRIER bubu...@debian.org wrote:
 Quoting Christian PERRIER (bubu...@debian.org):
 Dear Debian maintainer,

 On Monday, May 28, 2012, I sent you a notification about the beginning of a 
 review
 action on debconf templates for uptimed.

 Then, I sent you a bug report with rewritten templates and announcing
 the beginning of the second phase of this action: call for translation
 updates.

 Translators have been working hard and here is now the result of their 
 efforts.

 Please consider using it EVEN if you committed files to your
 development tree as long as they were reported.


 Is there any chance that an upload happens soon (which will move
 uptimed out of my radar...:-))?

No time for it right now.

Feel free to NMU.

Cheers



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

Bug#674860: [BTS#674860] templates://uptimed/{uprecords-cgi.templates,uptimed.templates} : Final update for English review

[Thibaut VARENE]

On Fri, Jun 1, 2012 at 9:34 AM, Christian PERRIER bubu...@debian.org wrote:
 Quoting Thibaut VARENE (vare...@debian.org):

 And I misread the patch. Scratch that. Sorry ;P


 So, in short, I can go ahead with the translation update round, right?

Yes.

-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/



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

Bug#674860: [BTS#674860] templates://uptimed/{uprecords-cgi.templates,uptimed.templates} : Final update for English review

[Thibaut VARENE]

On Thu, May 31, 2012 at 10:13 PM, Christian PERRIER bubu...@debian.org wrote:
 Dear Debian maintainer,

 On Monday, May 28, 2012, I notified you of the beginning of a review process
 concerning debconf templates for uptimed.

 The debian-l10n-english contributors have now reviewed these templates,
 and the final proposed changes are attached to this update to the
 original bug report.

 Please review the suggested changes, and if you have any
 objections, let me know in the next 3 days.

Only one:

 Template: uptimed/interval
 Type: string
 Default: 600
-_Description: Seconds that should pass between database updates:
- Uptimed will update its database every n seconds so that the uptime
+_Description: Delay between database updates (seconds):
+ Uptimed will update its database regularly so that the uptime
  doesn't get lost in case of a system crash. You can set how frequently
  this will happen (use higher values if you want to avoid disk activity,
- for example on a laptop). 60 seconds should be a reasonable default.
+ for instance on a laptop).

In the Description, the suggested value should match the default value of 600.

Thanks.

-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/



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

Bug#674860: [BTS#674860] templates://uptimed/{uprecords-cgi.templates,uptimed.templates} : Final update for English review

[Thibaut VARENE]

On Thu, May 31, 2012 at 10:30 PM, Thibaut VARENE vare...@debian.org wrote:
 On Thu, May 31, 2012 at 10:13 PM, Christian PERRIER bubu...@debian.org 
 wrote:
 Dear Debian maintainer,

 On Monday, May 28, 2012, I notified you of the beginning of a review process
 concerning debconf templates for uptimed.

 The debian-l10n-english contributors have now reviewed these templates,
 and the final proposed changes are attached to this update to the
 original bug report.

 Please review the suggested changes, and if you have any
 objections, let me know in the next 3 days.

 Only one:

  Template: uptimed/interval
  Type: string
  Default: 600
 -_Description: Seconds that should pass between database updates:
 - Uptimed will update its database every n seconds so that the uptime
 +_Description: Delay between database updates (seconds):
 + Uptimed will update its database regularly so that the uptime
  doesn't get lost in case of a system crash. You can set how frequently
  this will happen (use higher values if you want to avoid disk activity,
 - for example on a laptop). 60 seconds should be a reasonable default.
 + for instance on a laptop).

 In the Description, the suggested value should match the default value of 600.

And I misread the patch. Scratch that. Sorry ;P

-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/



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

Bug#674624: uprecords-cgi: fails to install with DEBIAN_FRONTEND=noninteractive

[Thibaut VARENE]

tags 674624 patch pending
thanks

On Sat, May 26, 2012 at 4:49 AM, Andreas Beckmann deb...@abeckmann.de wrote:
 Package: uprecords-cgi
 Followup-For: Bug #674624

 Fix is trivial as I expected.
 Patch attached.

Thanks, I'll prepare a new upload soon.

-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/



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

Bug#657922: closed by Thibaut VARENE vare...@debian.org (Bug#657922: fixed in uptimed 1:0.3.17-1)

[Thibaut VARENE]

fixed in -2

On Fri, May 25, 2012 at 10:32 AM, shawn shawnland...@gmail.com wrote:
 On Fri, 2012-05-25 at 01:51 +, Debian Bug Tracking System wrote:
 This is an automatic notification regarding your Bug report
 which was filed against the uptimed package:

 #657922: /var/run = /run, systemd unit file

 It has been closed by Thibaut VARENE vare...@debian.org.

 Their explanation is attached below along with your original report.
 If this explanation is unsatisfactory and you have not received a
 better one in a separate message then please contact Thibaut VARENE 
 vare...@debian.org by
 replying to this email.
 This patch I sent you was broken, sorry about that.


 MHTML Document attachment (Bug#657922: fixed in uptimed 1:0.3.17-1)
   Forwarded Message 
  From: Thibaut VARENE vare...@debian.org
  To: 657922-cl...@bugs.debian.org
  Subject: Bug#657922: fixed in uptimed 1:0.3.17-1
  Date: Fri, 25 May 2012 01:47:50 +
 
  MHTML Document attachment
  Source: uptimed
  Source-Version: 1:0.3.17-1
 
  We believe that the bug you reported is fixed in the latest version
  of
  uptimed, which is due to be installed in the Debian FTP archive:
 
  libuptimed-dev_0.3.17-1_ia64.deb
    to main/u/uptimed/libuptimed-dev_0.3.17-1_ia64.deb
  libuptimed0_0.3.17-1_ia64.deb
    to main/u/uptimed/libuptimed0_0.3.17-1_ia64.deb
  uprecords-cgi_0.3.17-1_all.deb
    to main/u/uptimed/uprecords-cgi_0.3.17-1_all.deb
  uptimed_0.3.17-1.debian.tar.gz
    to main/u/uptimed/uptimed_0.3.17-1.debian.tar.gz
  uptimed_0.3.17-1.dsc
    to main/u/uptimed/uptimed_0.3.17-1.dsc
  uptimed_0.3.17-1_ia64.deb
    to main/u/uptimed/uptimed_0.3.17-1_ia64.deb
  uptimed_0.3.17.orig.tar.bz2
    to main/u/uptimed/uptimed_0.3.17.orig.tar.bz2
 
 
 
  A summary of the changes between this version and the previous one
  is
  attached.
 
  Thank you for reporting the bug, which will now be closed.  If you
  have further comments please address them to 657...@bugs.debian.org,
  and the maintainer will reopen the bug report if appropriate.
 
  Debian distribution maintenance software
  pp.
  Thibaut VARENE vare...@debian.org (supplier of updated uptimed
  package)
 
  (This message was generated automatically at their request; if you
  believe that there is a problem with it please contact the archive
  administrators by mailing ftpmas...@debian.org)
 
 
  Format: 1.8
  Date: Fri, 25 May 2012 02:47:05 +0200
  Source: uptimed
  Binary: uptimed libuptimed0 libuptimed-dev uprecords-cgi
  Architecture: source all ia64
  Version: 1:0.3.17-1
  Distribution: unstable
  Urgency: low
  Maintainer: Thibaut VARENE vare...@debian.org
  Changed-By: Thibaut VARENE vare...@debian.org
  Description:
   libuptimed-dev - Development files for uptimed
   libuptimed0 - Library for uptimed
   uprecords-cgi - CGI script to show the world your highest uptimes
   uptimed    - Utility to track your highest uptimes
  Closes: 645504 648948 650109 657922 659797
  Changes:
   uptimed (1:0.3.17-1) unstable; urgency=low
   .
     * New upstream release (Closes: #648948, #650109)
     * Switch to dpkg-source 3.0 (quilt) format
     * Move PID to /run and provide systemd .service file (Closes: #657922)
     * Use maintscript support, patch from Colin Watson (Closes: #659797)
     * Add status in init script, patch from Peter Eisentraut (Closes: 
  #645504)
     * Enabled hardened build
     * Fixed some lintian warnings
  Checksums-Sha1:
   e87a545ad7f6003684d0de7a1c8a436965ca332b 1263 uptimed_0.3.17-1.dsc
   a40728353b153d1967371c2fd498e6bc3274c4c9 269102 
  uptimed_0.3.17.orig.tar.bz2
   9a230cdcc1edab769970bd832952a6b703bb986b 44731 
  uptimed_0.3.17-1.debian.tar.gz
   28cd7ec51390d50297d25347ec593929335d9c6a 19168 
  uprecords-cgi_0.3.17-1_all.deb
   c78c09fd02da452998ae4b7351e135ace100ad0e 41714 uptimed_0.3.17-1_ia64.deb
   8debd43d576344c1bc3d9e52c3b57e7a07d63954 18732 
  libuptimed0_0.3.17-1_ia64.deb
   87ca3cf7629e1d775333ff835661e7ca3e8305d7 18832 
  libuptimed-dev_0.3.17-1_ia64.deb
  Checksums-Sha256:
   8619439719b5122b920caa53e5eaafcffdca853e386767f8447848256fe5aea5 1263 
  uptimed_0.3.17-1.dsc
   524ce8984c0d0a780a32025ba3ffb980e5eec3d78e65cf68c91edec7fe833a06 269102 
  uptimed_0.3.17.orig.tar.bz2
   9b289b8ebe636bc46bd459dcf24ccbc34e5bd1ba1348120df561693c68c283d3 44731 
  uptimed_0.3.17-1.debian.tar.gz
   f394264ad2a8a6547996b44d151da9f6dcf3ff06c5a70d454275b8bd186ca3e1 19168 
  uprecords-cgi_0.3.17-1_all.deb
   a80116ea1e55900d1b4c76b6a1371712eafa75a11ea9c1025f4bd1b79e9bc5c6 41714 
  uptimed_0.3.17-1_ia64.deb
   644537dafada6a7f3b9862b77544064b04af9031f78633da9eaa18b18b85e0ed 18732 
  libuptimed0_0.3.17-1_ia64.deb
   56f111226cd444e3880ab69c9462b8119b0d4d07bde616e8da0f8cfb63740983 18832 
  libuptimed-dev_0.3.17-1_ia64.deb
  Files:
   119261c715b921b241613072d456b5be 1263 utils extra uptimed_0.3.17-1.dsc
   528b62c33454b33537c3bf2366977bdb 269102 utils extra 
  uptimed_0.3.17.orig.tar.bz2
   9c3aa3c4ee52cf21d099af580caa94d8 44731 utils extra 
  uptimed_0.3.17

Bug#674624: uprecords-cgi: fails to install with DEBIAN_FRONTEND=noninteractive

[Thibaut VARENE]

tags 674624 help
thanks

No time to deal with it, sorry. I hope someone can check this out, I
will not be able to look into this before the end of June.

Thanks

On Fri, May 25, 2012 at 6:48 PM, Andreas Beckmann deb...@abeckmann.de wrote:
 Package: uprecords-cgi
 Version: 1:0.3.17-1
 Severity: serious
 User: debian...@lists.debian.org
 Usertags: piuparts

 Hi,

 during a test with piuparts I noticed your package failed to install. As
 per definition of the release team this makes the package too buggy for
 a release, thus the severity.

 From the attached log (scroll to the bottom...):

  Selecting previously unselected package uprecords-cgi.
  (Reading database ... 8314 files and directories currently installed.)
  Unpacking uprecords-cgi (from .../uprecords-cgi_1%3a0.3.17-1_all.deb) ...
  Setting up uprecords-cgi (1:0.3.17-1) ...
  dpkg: error processing uprecords-cgi (--configure):
   subprocess installed post-installation script returned error exit status 30
  Errors were encountered while processing:
   uprecords-cgi


 exit status 30 looks very much like a debconf question that won't be
 asked due to noninteractive mode (that should be db_input exit code)
 (no, I didn't even look at the postinst script)

 cheers,

 Andreas



-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/



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

Bug#673154: CVE-2012-2369: Format string security vulnerability

[Thibaut VARENE]

On Sat, May 19, 2012 at 9:55 AM, Jonathan Wiltshire j...@debian.org wrote:
 On Thu, May 17, 2012 at 07:20:37AM -0700, Thibaut VARÈNE wrote:
 I've no idea how to fix this in stable and I'm currently in vacation with 
 limited Internet access...

 I'll take care of it (I wish you'd asked for help sooner).

Thanks

 For your reference:
 http://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security

Well, FYI I did pop up on #debian-security on OFTC to ask for help
when upstream advised me of their intent to publicize the
vulnerability, and I waited there for several hours and nobody even
paid attention to me. I've also been told that the initial bug
reporter (intrigueri) did contact d-s about the issue and also never
got any answer, and he couldn't point me to a RT ticket since
apparently it was private until upstream's disclosure, so I couldn't
even sync on that. I'm guessing nobody considered this a high enough
priority to warrant more attention. Which is fine by me, it's not like
everyone is using pidgin-otr anyway. It's not a high-profile package.

T-Bone



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

Bug#673118: tagainijisho: should not check for new version by default

[Thibaut VARENE]

severity 673118 minor
tags 673118 confirmed
thanks

Thanks for your report.
I'll include the suggested change in the next upload.

On Wed, May 16, 2012 at 2:35 AM, Stepan Golosunov
ste...@golosunov.pp.ru wrote:
 Package: tagainijisho
 Version: 0.9.2-3
 Severity: normal


 The first thing tagainijisho from testing displays on the start is the
 offer to download new version from somewhere. This is rather pointless
 for Debian (especially if this package is going to be released with
 stable) as updates are supposed to be received via the Debian archive.

 Also, unsolicited report to some site of the fact that user is running
 the program is dubious from the privacy point of view. Network access
 itself can be expensive in some situations.

 I guess that changing default value of autoCheckUpdates to false in
 src/gui/MainWindow.cc should fix the problem.


 -- System Information:
 Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (900, 'testing'), (400, 'stable')
 Architecture: i386 (x86_64)

 Kernel: Linux 3.2.0-2-amd64 (SMP w/2 CPU cores)
 Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash

 Versions of packages tagainijisho depends on:
 ii  libc6                2.13-32
 ii  libgcc1              1:4.7.0-7
 ii  libqt4-network       4:4.8.1-1
 ii  libqtcore4           4:4.8.1-1
 ii  libqtgui4            4:4.8.1-1
 ii  libsqlite3-0         3.7.11-3
 ii  libstdc++6           4.7.0-7
 ii  tagainijisho-common  0.9.2-3
 ii  tagainijisho-dic-en  0.9.2-3

 tagainijisho recommends no packages.

 tagainijisho suggests no packages.

 -- no debconf information





-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/



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

Bug#672721: tagainijisho: circular package dependency

[Thibaut VARENE]

No.

On Sun, May 13, 2012 at 11:19 AM, Osamu Aoki os...@debian.org wrote:
 Hi,

 I have a second thought.  In stead of the original patch, I propose
 attached alternative.

 Whoever install KDE library have enough disk space and usually wish to
 have full features of package as default without making any efforts.  So
 let's make all translations installed but also make them unselectable.

 It is your call whah one to apply.

 If anyone starts from translated dictionary (very odd case), there is
 still Recommends to guide people.

 If Translations are not needed, you can drop them since they are only
 Recommends.

 Osamu



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

Bug#672718: tagainijisho: some part of GUI is too small to display its content

[Thibaut VARENE]

tags 672718 moreinfo unreproducible
thanks

It works for me, could you provide a screenshot?

Thanks

On Sun, May 13, 2012 at 10:17 AM, Osamu Aoki os...@debian.org wrote:
 Package: tagainijisho
 Version: 0.9.4-1
 Severity: minor

 Program - Preferences

 The line heights for Preferred GUI language and Preferred disctionary
 language are too small to to display its content.

 Osamu

 -- System Information:
 Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (10, 'experimental')
 Architecture: amd64 (x86_64)

 Kernel: Linux 3.3.0-trunk-amd64 (SMP w/8 CPU cores)
 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash

 Versions of packages tagainijisho depends on:
 ii  libc6                2.13-32
 ii  libqt4-network       4:4.8.1-1
 ii  libqtcore4           4:4.8.1-1
 ii  libqtgui4            4:4.8.1-1
 ii  libsqlite3-0         3.7.11-3
 ii  libstdc++6           4.7.0-8
 ii  tagainijisho-common  0.9.4-1
 ii  tagainijisho-dic-en  0.9.4-1

 tagainijisho recommends no packages.

 tagainijisho suggests no packages.

 -- no debconf information





-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/



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

Bug#672728: tagainijisho: tagaini jisho doesn't warn when preferred dictionary language isn't installed

[Thibaut VARENE]

Package: tagainijisho
Version: 0.9.4-1
Severity: minor
Tags: upstream

When selecting a different dictionary language (or if GUI language isn't 
english),
Tagaini Jisho doesn't warn the user if said language isn't installed.

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

Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages tagainijisho depends on:
ii  libc6 2.11.3-2   Embedded GNU C Library: Shared lib
ii  libqt4-network4:4.6.3-4+squeeze1 Qt 4 network module
ii  libqtcore44:4.6.3-4+squeeze1 Qt 4 core module
ii  libqtgui4 4:4.6.3-4+squeeze1 Qt 4 GUI module
ii  libsqlite3-0  3.7.11-2~bpo60+1   SQLite 3 shared library
ii  libstdc++64.4.5-8The GNU Standard C++ Library v3
ii  tagainijisho-common   0.9.4-1Common files for Tagaini Jisho
ii  tagainijisho-dic-en   0.9.4-1English dictionary files for Tagai

tagainijisho recommends no packages.

tagainijisho 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#672731: override: tagainijisho*:education/extra

[Thibaut VARENE]

Package: ftp.debian.org
Severity: normal

REQUEST:
please change the override section for the following packages to 'education':

tagainijisho-common
tagainijisho-dic-de
tagainijisho-dic-en
tagainijisho-dic-es
tagainijisho-dic-fr
tagainijisho-dic-ru
tagainijisho

RATIONALE:
Tagaini Jisho is a Japanese dictionary and learning assistant.
Newest binary packages (tagainijisho-dic-it, tagainijisho-dic-pt,
tagainijisho-dic-th, tagainijisho-dic-tr) are already in section 'education'.

Thanks.



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

Bug#672718: tagainijisho: some part of GUI is too small to display its content

[Thibaut VARENE]

tags 672718 - moreinfo unreproducible + upstream confirmed
thanks

I finally hit that bug.

Steps to reproduce:

In Preferences, select a different GUI language (e.g. French). Restart
TJ, open Preferences. Dropdown menu is now very small.

Apparently it scales to the height of the flag, and the dictionary
menu scales to the same size.

HTH

T-Bone



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

Bug#666834: Test rebuild of your package libapache-mod-musicindex

[Thibaut VARENE]

Hi,

On Sun, May 6, 2012 at 10:34 PM, Arno Töll a...@debian.org wrote:
 tags 666834 + patch
 thanks

 Hi Thibaut,

 you will find attached below a patch porting your module to Apache2 2.4.
 Please test it and consider its inclusion. Note, I hardly tried more
 than compiling and loading the module. I didn't test it in detail.

 I've also fixed two problems while driving-by: You missed a
 build-dependency against dpkg-dev  1.16.1 (that's the fist version to
 support --export=configure) and a build-dependency against libapr1-dev.

 The patch includes upstream changes, too. Given you are upstream you
 might judge yourself whether it's suitable to you. Besides I consider
 the whole patch mostly a proof of concept.

As I told you in my previous email which you quote just below, I had
/already/ done the necessary upstream source changes. I'm sorry you
wasted your time on this and I thank you for suggesting packaging
changes anyway.

 Pretty sure I saw a debian wiki page or other debian page stating that
 2.4 wasn't due for Wheezy, but it seems I can't find it anymore. Last
 minute transition seems like added fun.

 Well, it's not exactly last minute. We announced the transition in March
 already [1].

March 22 was like yesterday, apache-2.4 didn't get any extensive
in-archive testing by virtue of not having hit unstable even yet, and
I understand that Wheezy is to be released tomorrow. Unless that
tomorrow turns out to be in a year, I guess that's pretty much a last
minute change. Not that I care that much anyway, I've got a fairly
strong impression of the modifications in Debian's overall quality
and I'm adjusting to it, as far as I'm concerned :-P

 Practical question: how am I supposed to upload a package that can be
 built either against 2.2 or 2.4 now that you have removed the
 apache2-dev package from 2.4? I've modified my source to build against
 2.4 and it also supports (from the same source, 1.3 (yes!), 2.0 and
 2.2).

 I guess you meant vice versa, we dropped apache2-dev from the 2.2
 package (which was a virtual package in 2.2). I am not sure whether
 there is a way to support both, a 2.2 module and a 2.4 module from the
 same source package. There are quite orthogonal changes regarding binary
 package dependencies and maintainer scripts. I guess one could figure
 something, but at least from our side no further support is approached.
 At least from our side we do not plan to support more than one major web
 server in Debian at the same time.

 If you can or want to make sure the binary dependencies end up right
 (apache2.2-bin for 2.2 packages, apache2-api-20120211 for 2.4 packages;
 a2enmod/a2dismod for 2.2 maintainer script, maintscript-helper for 2.4
 packages), it would possible to support both. Likewise for
 build-dependencies, but note Debian buildds do not resolve alternative
 build-dependencies in the form a | b.

My point was merely making my life and/or backports' life (and/or
debian-based distros') easier by providing a package that, when built
against either 2.4 (wheezy, as it seems) or 2.2 (squeeze) would not
require any modification. It seems it won't be possible, as the
package as per your own patch won't be buildable in squeeze and as
building against apache-2.2 and apache-2.4 require conflicting
build-deps (which is a departure from the previous 2.0 to 2.2
transition, iirc); well, so be it. I'll upload a new package when 2.4
hits unstable.

T-Bone

PS: CCing (instead of BCCing) cont...@debian.org is annoying when your
recipient hits reply all.



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

Bug#666834: Test rebuild of your package libapache-mod-musicindex

[Thibaut VARENE]

I don't get it: I thought Apache 2.4 wasn't scheduled for Wheezy?

On Sat, May 5, 2012 at 1:48 PM,  a...@debian.org wrote:
 tags 666834 '+upstream'
 thanks
 Dear maintainer,

 this is a follow-up message to your Apache 2.4 transition bug for
 package libapache-mod-musicindex. We are approaching an upload of the web 
 server to
 Debian's Unstable repository as soon as the release team acknowledges
 the upload. Along that upload we are planning to raise the importance of
 this bug to a release-critical severity.

 Please port your packages now to Apache 2.4. Below you can find a
 test-rebuild for your package for the 2.4 version of the Apache web
 server. Please note, even if the rebuild was successful, you still need
 to make changes in the Debian specific part of your package.

 The rebuild below was made by using a specially prepared build
 environment where these conditions where met:

 * We had apache2 and apache2-dev preinstalled
 * We provided a void apache2-threaded-dev and apache2-prefork-dev
  package to satisfy build-dependencies of your existing package (but
  this WILL NOT be the case in a real upload of the apache2 source
  package)
 * We prepared apxs to unconditionally inject
  -Werror=implicit-function-declaration to gcc to make sure we can spot
  the use of removed API calls (e.g. missing signatures for ap_*
  functions). Note, this might also cause false positives in some cases.

 These are the outcome criterias we defined:

 * VERIFIED-OK: The package rebuilt and linked successfully using the
  Apache 2.4 development headers. It still needs adapting to Debian
  package changes
 * VERIFIED-FAIL: The package does not rebuild successufully using the
  Apache 2.4 development headers. It may need some porting in the
  upstream code base
 * BYHAND: We may rebuild your package another time with manual
  interception. Not clear outcome could be determined out of the build
  log

 This is the outcome we determined:

 outcome: VERIFIED-FAIL
 comment: needs porting: fatal error: apr.h: No such file or directory

 You will find a full build log attached below.

 Here are some hints about porting problems. See [1] for a comprehensive
 overview:

 error: 'conn_rec' has no member named 'remote_ip'

        These fields have been renamed in order to distinguish between
        the client IP address of the connection and the useragent IP
        address of the request. Porting is trivial, in most cases
        changing the pointer from conn_rec-remote_ip to
        request_rec-useragent_ip is enough

 error: implicit declaration of function 'ap_requires'
 error: implicit declaration of function 'ap_default_type'

        These functions were removed along the 2.2 authnz API. It needs
        a non-trivial API redesign.

 error: implicit declaration of function 'ap_get_server_version'

        Use ap_get_server_banner()

 error: format not a string literal and no format arguments 
 [-Werror=format-security]

        Apache2 modules are being built with hardening build flags now
        in order to satisfy the hardening release goal [2]. A trivial
        fix comes over that problem.

 [1] http://httpd.apache.org/docs/2.4/developer/new_api_2_4.html
 [2] http://wiki.debian.org/ReleaseGoals/SecurityHardeningBuildFlags



-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/



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

Bug#666834: Test rebuild of your package libapache-mod-musicindex

[Thibaut VARENE]

On Sat, May 5, 2012 at 7:48 PM, Arno Töll a...@debian.org wrote:
 Hi,

 On 05.05.2012 19:44, Thibaut VARENE wrote:
 I don't get it: I thought Apache 2.4 wasn't scheduled for Wheezy?

 what makes you think that? We definitively want to have 2.4 in Wheezy.
 However, the final decision might come from the release team.

Pretty sure I saw a debian wiki page or other debian page stating that
2.4 wasn't due for Wheezy, but it seems I can't find it anymore. Last
minute transition seems like added fun.

Practical question: how am I supposed to upload a package that can be
built either against 2.2 or 2.4 now that you have removed the
apache2-dev package from 2.4? I've modified my source to build against
2.4 and it also supports (from the same source, 1.3 (yes!), 2.0 and
2.2).

Thanks

-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/



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

Bug#671031: reportbug: ignore proxy settings

[Thibaut VARENE]

On Wed, May 2, 2012 at 6:55 PM, Sandro Tosi mo...@debian.org wrote:
 reassign 671031 python-debianbts
 forcemerge 659013 671031
 thanks

 Hello,

 On Tue, May 1, 2012 at 2:01 PM, Thibaut VARENE vare...@debian.org wrote:
 Ignores proxy settings ($http_proxy and/or --proxy/--http_proxy) when 
 querying
 the BTS for source reports.

 Please see 659013 for reasoning.

That's a different bug. 659013 is about $http_proxy not working (which
it was before, namely in the sarge version). 671031 is for $http_proxy
AND --proxy not working as they should. The first version check
connection is proxied, but the BTS check isn't.

Feel free to merge anyway.

-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/



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

Bug#671031: reportbug: ignore proxy settings

[Thibaut VARENE]

Package: reportbug
Version: 6.3.1
Severity: normal

Ignores proxy settings ($http_proxy and/or --proxy/--http_proxy) when querying
the BTS for source reports.

Running netstat in parallel with reportbug shows direct attempt at contacting
busoni.debian.org.

-- Package-specific info:
** Environment settings:
INTERFACE=text

** /home/varenet/.reportbugrc:
reportbug_version 3.32
mode advanced
ui text
email vare...@debian.org

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: ia64

Kernel: Linux 2.6.29.2 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=locale: Cannot set 
LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages reportbug depends on:
ii  apt   0.9.2
ii  python2.7.2-10
ii  python-reportbug  6.3.1

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  debconf-utilsnone
pn  debsums  none
pn  dlocate  none
pn  emacs22-bin-common | emacs23-bin-common  none
pn  file 5.11-1
pn  gnupg1.4.12-4
pn  python-gtk2  none
pn  python-gtkspell  none
pn  python-urwid none
pn  python-vte   none
pn  ssmtp [mail-transport-agent] 2.64-6
pn  xdg-utilsnone

Versions of packages python-reportbug depends on:
ii  apt   0.9.2
ii  python2.7.2-10
ii  python-debian 0.1.21
ii  python-debianbts  1.11
ii  python-support1.0.14

python-reportbug suggests no packages.

-- debconf information:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = en_US.UTF-8
are supported and installed on your system.
perl: warning: Falling back to the standard locale (C).
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory



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

Bug#671034: linux-image-3.2.0-2-mckinley: fails to load INIT

[Thibaut VARENE]

Package: linux-2.6
Version: 3.2.16-1
Severity: normal

Stops short of loading INIT:

Loading.: Debian GNU/Linux  
Starting: Debian GNU/Linux
ELILO v3.12 for EFI/IA-64
..
Uncompressing Linux... done
Loading file \EFI\debian\initrd.img...done
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 3.2.0-2-mckinley (Debian 3.2.16-1) 
(debian-ker...@lists.debian.org) (gcc version 4.6.2 (Debian 4.6.2-12) ) #1 SMP 
Mon Apr 30 08:32:39 UTC 2012
[0.00] EFI v1.10 by HP: SALsystab=0x3fb38000 ACPI 2.0=0x3fb2e000 
SMBIOS=0x3fb3a000 HCDP=0x3fb2c000
[0.00] booting generic kernel on platform hpzx1
[0.00] PCDP: v0 at 0x3fb2c000
[0.00] Early serial console at MMIO 0xf805 (options '9600n8')
[0.00] bootconsole [uart8250] enabled
[0.00] ACPI: RSDP 3fb2e000 00028 (v02 HP)
[0.00] ACPI: XSDT 3fb2e02c 0009C (v01 HP   rx2600   
 HP )
[0.00] ACPI: FACP 3fb369e0 000F4 (v03 HP   rx2600   
 HP )
[0.00] ACPI Warning: 32/64X length mismatch in Gpe0Block: 32/16 
(20110623/tbfadt-529)
[0.00] ACPI Warning: 32/64X length mismatch in Gpe1Block: 32/16 
(20110623/tbfadt-529)
[0.00] ACPI: DSDT 3fb2e0e0 05781 (v01 HP   rx2600 0007 
INTL 02012044)
[0.00] ACPI: FACS 3fb36ad8 00040
[0.00] ACPI: SPCR 3fb36b18 00050 (v01 HP   rx2600   
 HP )
[0.00] ACPI: DBGP 3fb36b68 00034 (v01 HP   rx2600   
 HP )
[0.00] ACPI: APIC 3fb36c28 000C0 (v01 HP   rx2600   
 HP )
[0.00] ACPI: SPMI 3fb36ba0 00050 (v04 HP   rx2600   
 HP )
[0.00] ACPI: CPEP 3fb36bf0 00034 (v01 HP   rx2600   
 HP )
[0.00] ACPI: SSDT 3fb33870 001D6 (v01 HP   rx2600 0006 
INTL 02012044)
[0.00] ACPI: SSDT 3fb33a50 00342 (v01 HP   rx2600 0006 
INTL 02012044)
[0.00] ACPI: SSDT 3fb33da0 00A16 (v01 HP   rx2600 0006 
INTL 02012044)
[0.00] ACPI: SSDT 3fb347c0 00A16 (v01 HP   rx2600 0006 
INTL 02012044)
[0.00] ACPI: SSDT 3fb351e0 00A16 (v01 HP   rx2600 0006 
INTL 02012044)
[0.00] ACPI: SSDT 3fb35c00 00A16 (v01 HP   rx2600 0006 
INTL 02012044)
[0.00] ACPI: SSDT 3fb36620 001D8 (v01 HP   rx2600 0006 
INTL 02012044)
[0.00] ACPI: SSDT 3fb36800 000EB (v01 HP   rx2600 0006 
INTL 02012044)
[0.00] ACPI: SSDT 3fb368f0 000EF (v01 HP   rx2600 0006 
INTL 02012044)
[0.00] ACPI: Local APIC address c000fee0
[0.00] 2 CPUs available, 2 CPUs total
[0.00] SMP: Allowing 2 CPUs, 0 hotplug CPUs
[0.00] Initial ramdisk at: 0xe040fdea5000 (17744800 bytes)
[0.00] SAL 3.1: HP version 2.31
[0.00] SAL Platform features: None
[0.00] SAL: AP wakeup using external interrupt vector 0xff
[0.00] MCA related initialization done
[0.00] Virtual mem_map starts at 0xa0007fffc720
[0.00] Zone PFN ranges:
[0.00]   DMA  0x0400 - 0x0004
[0.00]   Normal   0x0004 - 0x0104
[0.00] Movable zone start PFN for each node
[0.00] early_node_map[6] active PFN ranges
[0.00] 0: 0x0400 - 0xfd79
[0.00] 0: 0xfec0 - 0xfecb
[0.00] 0: 0x0004 - 0x0006
[0.00] 0: 0x0101 - 0x0103ff3a
[0.00] 0: 0x0103ff49 - 0x0103ff84
[0.00] 0: 0x0103ffa0 - 0x0103fff0
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 333260
[0.00] Policy zone: Normal
[0.00] Kernel command line: BOOT_IMAGE=scsi0:/EFI/debian/boot/vmlinuz 
root=/dev/sda2  ro
[0.00] PID hash table entries: 4096 (order: 1, 32768 bytes)
[0.00] Memory: 6202848k/6233536k available (7787k code, 61104k 
reserved, 4468k data, 1184k init)
[0.00] Leaving McKinley Errata 9 workaround enabled
[0.00] Hierarchical RCU implementation.
[0.00]  CONFIG_RCU_FANOUT set to non-default value of 32
[0.00] NR_IRQS:1024
[0.00] ACPI: Local APIC address c000fee0
[0.00] GSI 36 (level, low) - CPU 0 (0x) vector 49
[0.00] Console: colour VGA+ 80x25
[0.004000] Calibrating delay loop... 1343.48 BogoMIPS (lpj=2686976)
[0.016100] pid_max: default: 32768 minimum: 301
[0.016521] Security Framework initialized
[0.017470] AppArmor: AppArmor disabled by boot time parameter
[0.018253] Dentry cache hash table entries: 1048576 (order: 9, 8388608 
bytes)
[0.037785] Inode-cache hash table entries: 524288 (order: 8, 4194304 bytes)
[0.043205] Mount-cache hash table entries: 1024
[

Bug#669614: RFA: lomoco

[Thibaut VARENE]

Package: wnpp
Severity: normal

Lomoco is essentially dead upstream, and I don't use it anymore. At this point
I do not think it should be part of wheezy.

Unless someone steps up to take over maintainership, I intend to orphan it
by the end of May.

HTH

T-Bone



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

Bug#650109: uptimed: kFreeBSD not detected as *BSD during build

[Thibaut VARENE]

On Thu, Apr 5, 2012 at 11:50 PM, Samuel Moritz samuel.mor...@gmail.com wrote:
 Hi!

 Has there been any progress regarding this upload? The patch works, but the
 latest version of uptimed in unstable (0.3.16-3.2) is still unpatched.

I'm waiting for feedback from upstream (CC'd), and/or maybe a new
upstream release.

HTH

-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/



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

Bug#667627: libapache-mod-musicindex: Dropping the apache2-dev virtual package

[Thibaut VARENE]

On Sat, Apr 7, 2012 at 11:37 AM, Arno Töll a...@debian.org wrote:
 Hi Thibaut,

Hi Arno,

 On 07.04.2012 11:24, Thibaut VARENE wrote:
 False positive and -EWTF?

 My package build-deps on: apache2-dev | apache2-threaded-dev

 buildds do not resolve A | B build-dependencies. They look at the first
 alternative only.

Sweet. Have to wonder about the actual use of alternative build-deps ;P

 Also, I'm not sure I get the point of asking maintainers to remove
 build-dep on apache2-dev in favor of apache2-threaded-dev when Apache
 2.4 will require the exact opposite...

 Yes, that's a bit unfortunate and this was primarily just for your
 information. You can completely ignore this bug, but you should at least
 know about the problem.

Well, I'm about to do a bugfix upload of my package, so I guess I
can't just ignore the bug for now and I will have to do the build-dep
dance. It also means I cannot upload a package that will nicely build
with both apache-2.2 AND apache-2.4 from the same source, which I was
planning to do to ease backporting work. Bummer.

 I realize this generates unnecessary work for you, but the alternative
 would be to require people to declare a versioned build-dependency for
 all 73 affected reverse dependencies until we get rid of the 2.2 -dev
 packages entirely.

I'm not versed into the specifics, but all I can say is that I liked
the idea of the status quo, that is, don't break something that worked
well for so long. Maybe it couldn't be done ;-P

Cheers

-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/



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

Bug#516382: [2.6.22 - 2.6.23 regression] [alpha] tg3: incoming ssh fails with Corrupted MAC on input

[Thibaut VARENE]

On Mon, Mar 19, 2012 at 8:29 AM, Jonathan Nieder jrnie...@gmail.com wrote:
 Thibaut VARENE wrote:

 I don't really have time to play with it nowadays, but if somebody
 wants to try it out I can probably arrange for remote access.

 I'd be happy to try if there's some kind of remote interface for
 interacting with the bootloader and rebooting.

There is. I'll get in touch with you again later this week, I'm
currently on vacation ;)

T-Bone

-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/



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

Bug#516382: [2.6.22 - 2.6.23 regression] [alpha] tg3: incoming ssh fails with Corrupted MAC on input

[Thibaut VARENE]

On Sat, Mar 17, 2012 at 12:09 AM, Jonathan Nieder jrnie...@gmail.com wrote:
 Hi Thibaut,

Hi Jonathan,

 Thibaut VARÈNE wrote:

 After upgrading from etch to lenny, and booting the new kernel, I
 realized I couldn't login into the box anymore: ssh would
 consistently fail to connect with:

 Corrupted MAC on input

 It's reproducible across reboots. When I rebooted into 2.6.18, the
 problem vanished. I'm using a BCM 5701 (tg3 driver) GigE NIC.
 [...]
 This bug has sufficient evidence proving
 that it's real and affecting 2.6.26 in lenny.

 I'm just curious about the current status: do you still have access
 to a machine reproducing this?  If so, do you know if squeeze or
 wheezy is affected?

I still have the machine but it's stuck on lenny with a 2.6.18 kernel
because since it's a remote machine, having trouble with networking is
a major inconvenience...

I don't really have time to play with it nowadays, but if somebody
wants to try it out I can probably arrange for remote access.

Cheers,
T-Bone

-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/



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

Bug#575461: finch: ability to use OTR-encryption

[Thibaut VARENE]

On Fri, Mar 9, 2012 at 12:17 AM, Howard Chu h...@highlandsun.com wrote:
 Thibaut VARENE wrote:

 On Sun, Feb 26, 2012 at 1:36 AM, Howard Chuh...@highlandsun.com  wrote:

 Just fyi, all of my pidgin/finch patches have been merged upstream.
 They're

 targeted at a 3.0.0 release though, so it doesn't seem there will be any
 official 2.10.x update with the features enabled. Personally I would
 recommend you add my patches to your own 2.10.1 builds, in the
 meantime...


 fyi, this bug is against pidgin-otr, the otr plugin for pidgin. I am
 not responsible for the pidgin or finch packages, so if you want
 patches merged there, you need to submit appropriate bug reports
 against them or ping their respective maintainers... I can only merge
 patches that apply to pidgin-otr, and I'd rather do so with the
 approval of upstream maintainers...


 OK. Fyi, it looks like my plugin patches will not be merged upstream.

 http://lists.cypherpunks.ca/pipermail/otr-dev/2012-March/001267.html

Sadly, another perfect example of doing the wrong thing by multiplying
redundant efforts. Open source at its best.

Anyhow, I'm undecided about continuing to maintain pidgin-otr which is
unbearably buggy when there seems to be a technically better
replacement for it (purple-otr). I need to ponder this a little. I'm
gonna be offline for the next couple weeks, this might be the right
time for me to evaluate the options ;-)

I'll keep you posted.

-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/



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

Bug#575461: finch: ability to use OTR-encryption

[Thibaut VARENE]

On Sun, Feb 26, 2012 at 1:36 AM, Howard Chu h...@highlandsun.com wrote:
 Howard Chu wrote:

 Just for reference, the upstream bug report has been re-opened since I
 started
 working on the issue:

 http://developer.pidgin.im/ticket/11623

 3 out of 4 of my patches have already been integrated into pidgin
 upstream,
 and I expect the last will be merged soon.


 Just fyi, all of my pidgin/finch patches have been merged upstream. They're
 targeted at a 3.0.0 release though, so it doesn't seem there will be any
 official 2.10.x update with the features enabled. Personally I would
 recommend you add my patches to your own 2.10.1 builds, in the meantime...

fyi, this bug is against pidgin-otr, the otr plugin for pidgin. I am
not responsible for the pidgin or finch packages, so if you want
patches merged there, you need to submit appropriate bug reports
against them or ping their respective maintainers... I can only merge
patches that apply to pidgin-otr, and I'd rather do so with the
approval of upstream maintainers...

HTH

-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/



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

Bug#654830: uprecords: Shows duplicated entry and impossible values

[Thibaut VARENE]

severity 654830 minor
tags 654830 upstream
quit

Hi,

The uptime percentage and dowtime values are bogus, upstream is aware
of that and I  believe they will be removed in the next release.

The double entry is puzzling though, thanks for reporting. I wonder if
that's just the addition of the current exact uptime at the moment you
ran uprecords which tops out max recorded uptime + the display of the
last recorded highest uptime. Need to check the code.

On Fri, Jan 6, 2012 at 12:59 AM, Axel Beckert a...@debian.org wrote:
 Package: uptimed
 Version: 1:0.3.16-3.2
 Severity: normal

 Hi,

 on a netbook which I suspend to RAM quite often (not sure if that's
 relevant :-), I found the following strange output of uprecords:

 $ uprecords
     #               Uptime | System                                    Boot up
 +--
 -   1     6 days, 05:04:09 | Linux 3.2.0-rc7-amd64    Fri Dec 30 19:42:06 
 2011
     2     6 days, 05:03:35 | Linux 3.2.0-rc7-amd64    Fri Dec 30 19:42:10 2011
     3     1 day , 09:16:42 | Linux 3.1.0-1-amd64      Fri Dec 23 03:26:52 2011
     4     1 day , 05:32:43 | Linux 3.2.0-rc4-amd64    Sat Dec 24 12:43:57 2011
     5     0 days, 19:12:32 | Linux 3.2.0-rc7-amd64    Thu Dec 29 23:09:59 2011
     6     0 days, 05:43:05 | Linux 3.1.0-1-amd64      Thu Dec 22 21:25:32 2011
     7     0 days, 01:42:10 | Linux 3.2.0-rc4-amd64    Wed Dec 28 21:52:54 2011
     8     0 days, 01:08:25 | Linux 3.2.0-rc4-amd64    Thu Dec 29 15:50:37 2011
     9     0 days, 00:51:51 | Linux 3.2.0-rc7-amd64    Thu Dec 29 16:59:50 2011
    10     0 days, 00:35:10 | Linux 3.2.0-rc4-amd64    Tue Dec 27 04:04:43 2011
 +--
 NewRec     0 days, 00:00:33 | since                    Fri Jan  6 00:45:41 
 2012
    up    16 days, 06:36:17 | since                    Thu Dec 22 21:25:32 2011
  down   -2 days, -03:-16:- | since                    Thu Dec 22 21:25:32 2011
   %up              115.108 | since                    Thu Dec 22 21:25:32 2011

 The first entry seems to be duplicated more or less, leading to wrong
 uptime percentage (115%) and wrong downtime (-2 days).

 I though can't find this duplicated entry in the
 /var/spool/uptimed/records file, so I suspect a bug in the statistics
 part of uprecords:

 $ cat /var/spool/uptimed/records
 536855:1325270530:Linux 3.2.0-rc7-amd64
 119802:1324607212:Linux 3.1.0-1-amd64
 106363:1324727037:Linux 3.2.0-rc4-amd64
 69152:1325196599:Linux 3.2.0-rc7-amd64
 20585:1324585532:Linux 3.1.0-1-amd64
 6130:1325105574:Linux 3.2.0-rc4-amd64
 4105:1325170237:Linux 3.2.0-rc4-amd64
 3111:1325174390:Linux 3.2.0-rc7-amd64
 2110:1324955083:Linux 3.2.0-rc4-amd64
 802:1324833446:Linux 3.2.0-rc4-amd64
 753:1325056802:Linux 3.2.0-rc4-amd64
 $

 -- System Information:
 Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (900, 'testing'), (110, 'experimental')
 Architecture: amd64 (x86_64)

 Kernel: Linux 3.2.0-rc7-amd64 (SMP w/2 CPU cores)
 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash

 Versions of packages uptimed depends on:
 ii  debconf [debconf-2.0]  1.5.41
 ii  libc6                  2.13-24
 ii  libuptimed0            1:0.3.16-3.2

 uptimed recommends no packages.

 uptimed suggests no packages.

 -- debconf information:
  uptimed/mail/do_mail: Never
  uptimed/mail/address: root@localhost
  uptimed/mail/milestones_info:
  uptimed/maxrecords: 50
  uptimed/interval: 60





-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/



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

Bug#575461: finch: ability to use OTR-encryption

[Thibaut VARENE]

Thanks for your effort.

Let us know how the upstream integration is going on.

If you have a chance, you might want to take a look at the bugs listed
here[0], and see if your rewrite fixes any of them (other than the
ones you have already commented on).

[0] http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=pidgin-otr

On Tue, Dec 20, 2011 at 12:40 PM, Howard Chu h...@highlandsun.com wrote:
 I've rewritten the pidgin-otr-3.2.0 plugin to use the libpurple API, so a
 single plugin works for both pidgin and finch. Details are here

 http://lists.cypherpunks.ca/pipermail/otr-dev/2011-December/001237.html

 and the source code is here

 https://gitorious.org/purple-otr

 I expect that with some user and developer feedback we'll find a way forward
 to bring this support into the official OTR sources down the road.

 I use this with pidgin/finch 2.10.1 with 4 additional patches, as detailed
 in the links above.
 --
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/





-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/



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

Bug#648948: uptimed: FTBFS on hurd-i386: add support for GNU

[Thibaut VARENE]

On Tue, Nov 29, 2011 at 9:47 AM, Svante Signell
svante.sign...@telia.com wrote:
 On Wed, 2011-11-16 at 14:15 +0100, Thibaut VARENE wrote:
 On Wed, Nov 16, 2011 at 1:46 PM, Svante Signell
 svante.sign...@telia.com wrote:
  On Wed, 2011-11-16 at 12:06 +0100, Thibaut VARENE wrote:
  Replying to myself as I mistyped the bug forward address ;P
 
  On Wed, Nov 16, 2011 at 12:02 PM, Thibaut VARENE vare...@debian.org 
  wrote:
   severity 648948 normal
   thanks
   Thanks for your patch, I've forwarded it upstream for review and 
   inclusion.
 
  So there is an active upstream, nice. The latest release is from 2009.

 Not so active, but he reviews patches and includes them. I think he
 has a new release planned.

 Does the patch have to applied upstream, a new release be made to have
 it in Debian. Or can it be applied to the existing version, creating
 0.3.16-3.3 if NMUed or 0.3.16-4 if from the DM (you).

Please be patient, upstream is reviewing your patch.

-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/



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

Bug#633671: [buildd-tools-devel] Bug#633671: Bug#633671: Bug#633671: schroot behaves differently depending on cwd

[Thibaut VARENE]

On Sun, Nov 27, 2011 at 9:46 PM, Roger Leigh rle...@codelibre.net wrote:
 On Sun, Nov 27, 2011 at 07:43:08PM +0100, Thibaut VARENE wrote:
 On Sun, Nov 27, 2011 at 4:54 PM, Roger Leigh rle...@codelibre.net wrote:
  tags 63367 + fixed-upstream pending
  thanks
 
  On Tue, Jul 12, 2011 at 11:08:13PM +0200, Thibaut VARENE wrote:
  On Tue, Jul 12, 2011 at 10:43 PM, Roger Leigh rle...@codelibre.net 
  wrote:

   The thing is that the error message isn't really explicit, when you're
   unaware of this design choice... I don't how it could be improved
   though.
  
   We could add an additional information message e.g.
  
   E: Failed to change to directory ‘/tmp/syscheck’: No such file or 
   directory
   I: Does this directory exist inside the chroot?
   I: Use the --directory option to run the command in a different 
   directory.
 
  Well, the problem is that when I first saw the error message, I didn't
  realize it was talking about the chroot, but I quickly suspected it
  (it wouldn't have made /any/ sense otherwise). This clarifies the
  situation. What remains unclear to the average user unaware of the
  implications of a fallback policy for commands is /why/ the directory
  needs to be in the chroot. Put another way, at some point I started
  believing schroot wouldn't work unless the whole /home/buildd was
  loop-mounted into the chroot. I didn't realize it only need the
  specific directory it was executed from. I suppose some extra
  documentation in the manpages regarding the behaviour of schroot when
  executing shells vs commands might be helpful to clarify this.
 
  I've written a new section into the manual page (Directory Fallbacks)
  to properly document this (attached).  Is this OK with you?

 Looks good to me, thanks!

 Did you also implement the more elaborate error message as quoted
 above? The combination of both changes would certainly clear up any
 possible misunderstanding :)

 That's now also done:

 % schroot -c sid -d /invalid
 E: Failed to change to directory ‘/invalid’: No such file or directory
 I: The directory does not exist inside the chroot.  Use the --directory 
 option to run the command in a different directory.

 % mkdir /tmp/invalid
 % cd /tmp/invalid
 % schroot -c sid
 W: Failed to change to directory ‘/tmp/invalid’: No such file or directory
 I: The directory does not exist inside the chroot.  Use the --directory 
 option to run the command in a different directory.
 W: Falling back to directory ‘/home/rleigh’
 W: Shell ‘/usr/bin/zsh’ not available: /usr/bin/zsh: Failed to stat file: No 
 such file or directory
 W: Falling back to shell ‘/bin/sh’
 $

 Is this OK for you?

Looks great, many thanks!

-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/



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

Bug#650109: uptimed: kFreeBSD not detected as *BSD during build

[Thibaut VARENE]

tags 650109 confirmed pending
thanks

Hi,

Thanks for your feedback, I'll schedule the change for an upcoming
upload. I've CC'd upstream so that he can update his source as well.

HTH

T-Bone

On Sat, Nov 26, 2011 at 5:17 PM, Kacper Gutowski mwgam...@gmail.com wrote:
 Package: uptimed
 Version: 1:0.3.16-3.2
 Severity: normal
 Tags: patch

 Dear Maintainer,
 When trying to start uptimed on kFreeBSD it gives the following
 error message:

 Starting uptime daemon: Error reading boot id from file, exiting!
 You probably forgot to create a bootid with with the -b option.
 You really want the system to do this on bootup, read the INSTALL file!

 This happens only because it gets compiled with PLATFORM_UNKNOWN
 defined instead of PLATFORM_BSD, so there is no need to modify
 startup scripts and following patch solves the issue:

 --- uptimed-0.3.16.orig/configure.ac    2009-01-01 23:46:00.0 +
 +++ uptimed-0.3.16/configure.ac 2011-11-26 15:19:45.0 +
 @@ -19,6 +19,9 @@
   *-freebsd*)
     AC_DEFINE(PLATFORM_BSD, 1, [Define if you are compiling for *BSD])
     ;;
 +  *-kfreebsd*)
 +    AC_DEFINE(PLATFORM_BSD, 1, [Define if you are compiling for *BSD])
 +    ;;
   *-bsdi*)
     AC_DEFINE(PLATFORM_BSD, 1, [Define if you are compiling for *BSD])
     ;;


 -- System Information:
 Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
 Architecture: kfreebsd-amd64 (x86_64)

 Kernel: kFreeBSD 9.0-0-amd64
 Locale: LANG=pl_PL.utf8, LC_CTYPE=pl_PL.utf8 (charmap=UTF-8) (ignored: LC_ALL 
 set to pl_PL.utf8)
 Shell: /bin/sh linked to /bin/dash

 Versions of packages uptimed depends on:
 ii  debconf [debconf-2.0]  1.5.41
 ii  libc0.1                2.13-21
 ii  libuptimed0            1:0.3.16-3.2

 uptimed recommends no packages.

 uptimed suggests no packages.

 -- debconf information excluded






-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/



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

Bug#633671: [buildd-tools-devel] Bug#633671: Bug#633671: schroot behaves differently depending on cwd

[Thibaut VARENE]

On Sun, Nov 27, 2011 at 4:54 PM, Roger Leigh rle...@codelibre.net wrote:
 tags 63367 + fixed-upstream pending
 thanks

 On Tue, Jul 12, 2011 at 11:08:13PM +0200, Thibaut VARENE wrote:
 On Tue, Jul 12, 2011 at 10:43 PM, Roger Leigh rle...@codelibre.net wrote:

  The thing is that the error message isn't really explicit, when you're
  unaware of this design choice... I don't how it could be improved
  though.
 
  We could add an additional information message e.g.
 
  E: Failed to change to directory ‘/tmp/syscheck’: No such file or directory
  I: Does this directory exist inside the chroot?
  I: Use the --directory option to run the command in a different directory.

 Well, the problem is that when I first saw the error message, I didn't
 realize it was talking about the chroot, but I quickly suspected it
 (it wouldn't have made /any/ sense otherwise). This clarifies the
 situation. What remains unclear to the average user unaware of the
 implications of a fallback policy for commands is /why/ the directory
 needs to be in the chroot. Put another way, at some point I started
 believing schroot wouldn't work unless the whole /home/buildd was
 loop-mounted into the chroot. I didn't realize it only need the
 specific directory it was executed from. I suppose some extra
 documentation in the manpages regarding the behaviour of schroot when
 executing shells vs commands might be helpful to clarify this.

 I've written a new section into the manual page (Directory Fallbacks)
 to properly document this (attached).  Is this OK with you?

Looks good to me, thanks!

Did you also implement the more elaborate error message as quoted
above? The combination of both changes would certainly clear up any
possible misunderstanding :)

Thanks,
T-Bone

-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/



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

Bug#648948: uptimed: FTBFS on hurd-i386: add support for GNU

[Thibaut VARENE]

Replying to myself as I mistyped the bug forward address ;P

On Wed, Nov 16, 2011 at 12:02 PM, Thibaut VARENE vare...@debian.org wrote:
 severity 648948 normal
 thanks
 Thanks for your patch, I've forwarded it upstream for review and inclusion.
 Please note that adding support for a new architecture that never previously
 built for a package does not qualify for severity important.

 On Wed, Nov 16, 2011 at 11:35 AM, Svante Signell svante.sign...@telia.com
 wrote:

 Package: uptimed
 Version: 0.3.16-3.2
 Severity: important
 Tags: patch
 User: debian-h...@lists.debian.org
 Usertags: hurd

 Hi,

 The attached patch fixes the FTBFS problems of uptimed on GNU/Hurd,
 adding support for the GNU platform. Additionally it replaces the NOFILE
 parameter for architectures supporting getdtablesize() with a fallback
 to sysconf() or 3 for other architectures.

 The NOFILE parameter is obsolete even on GNU/Linux.
 From /usr/include/i386-linux-gnu/sys/param.h:

 /* The following are not really correct but it is a value we used for a
   long time and which seems to be usable.  People should not use NOFILE
   and NCARGS anyway.  */
 #define NOFILE          256
 #define NCARGS          131072

 The patched uptimed has been build and run tested on GNU/Linux and
 GNU/Hurd for some time with no problems so far.

 Thanks!






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

Bug#648948: uptimed: FTBFS on hurd-i386: add support for GNU

[Thibaut VARENE]

On Wed, Nov 16, 2011 at 1:46 PM, Svante Signell
svante.sign...@telia.com wrote:
 On Wed, 2011-11-16 at 12:06 +0100, Thibaut VARENE wrote:
 Replying to myself as I mistyped the bug forward address ;P

 On Wed, Nov 16, 2011 at 12:02 PM, Thibaut VARENE vare...@debian.org wrote:
  severity 648948 normal
  thanks
  Thanks for your patch, I've forwarded it upstream for review and inclusion.

 So there is an active upstream, nice. The latest release is from 2009.

Not so active, but he reviews patches and includes them. I think he
has a new release planned.

 Does forwarding a bug to upstream make the bug disappear from the bug
 database? I cannot find it any longer in the Debian bugs for this
 package.

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

HTH

-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/



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

Bug#515653: database corruption detection patch works

[Thibaut VARENE]

As usual your comments are completely out of place.
From http://hg.podgorny.cz/uptimed/rev/bbe117e5

Backup database logic from Martin Steigerwald.

The email was addressed to *upstream*, because upstream's attribution
*is* incorrect.

Thank you.

On Wed, Nov 2, 2011 at 9:26 AM, Martin Steigerwald mar...@lichtvoll.de wrote:
 Am Montag, 31. Oktober 2011 schrieb Thibaut VARENE:
 Hi Radek,

 Hi Thibaut,

 Not that I particularly bitch about who did what, but I think it's
 good practice to credit the right people. The patch you merged in [1]
 was developped by me (Thibaut VARENE t-b...@parisc-linux.org), and
 tested by Martin. I shall mention that I still consider it a dirty
 hack (see [2] for references).

 And its exactly like that in the changelog:

  * Add database corruption detection/recovery patch (Closes: #515653)
    - Authored by Thibaut VARENE, tested by Martin Steigerwald

 Ciao,
 Martin


 HTH

 T-Bone

 [1] http://hg.podgorny.cz/uptimed/rev/bbe117e5
 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515653#79




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

Bug#515653: database corruption detection patch works

[Thibaut VARENE]

No problem, thanks for your quick response!

On Wed, Nov 2, 2011 at 6:07 PM, Radek Podgorny ra...@podgorny.cz wrote:

 Hello Thibaut!

 Please accept my sincere apologies for the wrong attribution. Martin's
 inline attachment tricked me into wrongly thinking it was a whole different
 patch. Fixed in the CREDITS file now.

 Sorry again and keep up the good work!

 Radek P.



 On 10/31/2011 09:42 PM, Thibaut VARENE wrote:

 Hi Radek,

 Not that I particularly bitch about who did what, but I think it's
 good practice to credit the right people. The patch you merged in [1]
 was developped by me (Thibaut VARENEt-b...@parisc-linux.org**), and
 tested by Martin. I shall mention that I still consider it a dirty
 hack (see [2] for references).

 HTH

 T-Bone

 [1] 
 http://hg.podgorny.cz/uptimed/**rev/bbe117e5http://hg.podgorny.cz/uptimed/rev/bbe117e5
 [2] 
 http://bugs.debian.org/cgi-**bin/bugreport.cgi?bug=515653#**79http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515653#79

 On Thu, Oct 6, 2011 at 3:36 PM, Radek Podgornyra...@podgorny.cz  wrote:

 Hello again,

 merged without problems. Now dwells in main repo, waiting for the next
 release.

 Thanks a lot again for your contribution!

 Radek Podgorny


 On 10/05/2011 06:49 PM, Martin Steigerwald wrote:


 Am Mittwoch, 5. Oktober 2011 schrieb Radek Podgorny:


 Hello Martin,


 Hi Radek,

  will take a look at it and will try to merge during this week. Thanks a
 lot for you effort!


 Thanks. I appreciate it.

 Ciao,











-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/

Bug#515653: database corruption detection patch works

[Thibaut VARENE]

Hi Radek,

Not that I particularly bitch about who did what, but I think it's
good practice to credit the right people. The patch you merged in [1]
was developped by me (Thibaut VARENE t-b...@parisc-linux.org), and
tested by Martin. I shall mention that I still consider it a dirty
hack (see [2] for references).

HTH

T-Bone

[1] http://hg.podgorny.cz/uptimed/rev/bbe117e5
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515653#79

On Thu, Oct 6, 2011 at 3:36 PM, Radek Podgorny ra...@podgorny.cz wrote:
 Hello again,

 merged without problems. Now dwells in main repo, waiting for the next
 release.

 Thanks a lot again for your contribution!

 Radek Podgorny


 On 10/05/2011 06:49 PM, Martin Steigerwald wrote:

 Am Mittwoch, 5. Oktober 2011 schrieb Radek Podgorny:

 Hello Martin,

 Hi Radek,

 will take a look at it and will try to merge during this week. Thanks a
 lot for you effort!

 Thanks. I appreciate it.

 Ciao,







-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/



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

Bug#586788: Not fixed

[Thibaut VARENE]

found 586788 6.10.58+dfsg-3
notfixed 586788 6.10.58+dfsg-3
thanks

Hi,

I can confirm this bug still affects 6.10.58+dfsg-3.
A fix is proposed here:
http://boincstats.com/forum/forum_thread.php?id=5912nowrap=true#96768

HTH

T-Bone

-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/



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

Bug#636687: pending NMU for uptimed

[Thibaut VARENE]

On Sat, Aug 27, 2011 at 9:03 AM, Andreas Henriksson andr...@fatal.se wrote:
 Hello!

Hi

 Since there's been no reply for some weeks (and the last upload was a NMU
 as well), I'll assume you're very busy at the moment so I've prepared
 another NMU.

I am ;-)
Go for it.
Thanks

-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/



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

Bug#633671: [buildd-tools-devel] Bug#633671: schroot behaves differently depending on cwd

[Thibaut VARENE]

On Wed, Jul 13, 2011 at 1:25 PM, Philipp Kern pk...@debian.org wrote:
 On Tue, Jul 12, 2011 at 08:41:53PM +0200, Thibaut VARENE wrote:
 While debugging the old 'create-chroot.sh' script from pkern that
 was having hickups, I finally realized that schroot behaves
 apparently inconsistently depending on the cwd:

 It's not old.  It's the one supposed to be used on the buildds.

The copy I use is old (from 2009). It's possible you've updated it
since then ;)

 (I don't know if you know the apt repo in
 https://buildd.debian.org/apt/ though.)

I'm aware of it, but last time I tried using it it turned out the
software there was (too) heavily tuned for Debian buildds to suit my
needs.

Thx

-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/



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

Bug#633777: sbuild: virtual dependency resolver broken?

[Thibaut VARENE]

Package: sbuild
Version: 0.60.0-2squeeze1
Severity: normal

Hi, it's me again ;P

I've recently discovered that some of my packages stopped building because of 
the following error:

Checking for source dependency conflicts...
E: Package 'libjpeg-dev' has no installation candidate
libjpeg-dev is a virtual package provided by: 
Using  (no default, using first one)
Use of uninitialized value in join or string at 
/usr/share/perl5/Sbuild/Chroot.pm line 339.
Use of uninitialized value in join or string at 
/usr/share/perl5/Sbuild/Chroot.pm line 340.
Use of uninitialized value in join or string at 
/usr/share/perl5/Sbuild/Chroot.pm line 341.
Use of uninitialized value $command in join or string at 
/usr/share/perl5/Sbuild/Chroot.pm line 353.
Use of uninitialized value in exec at /usr/share/perl5/Sbuild/Chroot.pm line 
354.
terminate called after throwing an instance of 'std::out_of_range'
  what():  basic_string::compare
Installing positive dependencies: debhelper docbook-xml docbook-xsl ladspa-sdk 
libaa1-dev libasound2-dev libaudio-dev libcaca-dev libcdparanoia-dev 
libdirectfb-dev libdts-dev libdvdnav-dev libdvdread-dev libenca-dev libfaad-dev 
libfontconfig1-dev libfreetype6-dev libfribidi-dev libgif-dev libgl1-mesa-dev 
libjack-dev libjpeg-dev liblircclient-dev liblivemedia-dev liblzo2-dev 
libmpcdec-dev libncurses5-dev libopenal-dev libpng12-dev libpulse-dev 
libschroedinger-dev libsdl1.2-dev xsltproc libsmbclient-dev libspeex-dev yasm 
zlib1g-dev libtheora-dev libvdpau-dev libvorbis-dev libvorbisidec-dev 
libx11-dev libxext-dev libxinerama-dev libxv-dev libxvmc-dev libxxf86dga-dev 
libxxf86vm-dev pkg-config python vstream-client-dev x11proto-core-dev ccache 
quilt
Reading package lists...
Building dependency tree...
Reading state information...
Package libjpeg-dev is a virtual package provided by:
E: Package 'libjpeg-dev' has no installation candidate
libjpeg-dev is a virtual package provided by: 
Using  (no default, using first one)
Use of uninitialized value in join or string at 
/usr/share/perl5/Sbuild/Chroot.pm line 339.
Use of uninitialized value in join or string at 
/usr/share/perl5/Sbuild/Chroot.pm line 340.
Use of uninitialized value in join or string at 
/usr/share/perl5/Sbuild/Chroot.pm line 341.
Use of uninitialized value $command in join or string at 
/usr/share/perl5/Sbuild/Chroot.pm line 353.
Use of uninitialized value in exec at /usr/share/perl5/Sbuild/Chroot.pm line 
354.
Reading package lists...
Building dependency tree...
Reading state information...
terminate called after throwing an instance of 'std::out_of_range'
  what():  basic_string::compare
apt-get failed.
Package installation failed

Investigating this, I noticed that sbuild calls apt-get with '-q' in -s mode:
D: Running command: /usr/bin/schroot -d / -c 
sid-ia64-sbuild-3667d049-42aa-43a0-88ac-f064fee342c4 --run-session -q -u root 
-p -- /usr/bin/apt-get --purge -o DPkg::Options::=--force-confold -q -s install 
debhelper docbook-xml docbook-xsl ladspa-sdk libaa1-dev libasound2-dev 
libaudio-dev libcaca-dev libcdparanoia-dev libdirectfb-dev libdts-dev 
libdvdnav-dev libdvdread-dev libenca-dev libfaad-dev libfontconfig1-dev 
libfreetype6-dev libfribidi-dev libgif-dev libgl1-mesa-dev libjack-dev 
libjpeg-dev liblircclient-dev liblivemedia-dev liblzo2-dev libmpcdec-dev 
libncurses5-dev libopenal-dev libpng12-dev libpulse-dev libschroedinger-dev 
libsdl1.2-dev xsltproc libsmbclient-dev libspeex-dev yasm zlib1g-dev 
libtheora-dev libvdpau-dev libvorbis-dev libvorbisidec-dev libx11-dev 
libxext-dev libxinerama-dev libxv-dev libxvmc-dev libxxf86dga-dev 
libxxf86vm-dev pkg-config python vstream-client-dev x11proto-core-dev ccache 
quilt

Turns out -q apparently inhibits apt-get from displaying the providers of the 
virtual package:

buildd@envy:~/build$ /usr/bin/schroot -d / -c sid-ia64-sbuild -q -u root -p -- 
/usr/bin/apt-get --purge -o DPkg::Options::=--force-confold -q -s install 
libjpeg-dev
Reading package lists...
Building dependency tree...
Reading state information...
Package libjpeg-dev is a virtual package provided by:
E: Package 'libjpeg-dev' has no installation candidate
buildd@envy:~/build$ /usr/bin/schroot -d / -c sid-ia64-sbuild -q -u root -p -- 
/usr/bin/apt-get --purge -o DPkg::Options::=--force-confold -s install 
libjpeg-dev
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Package libjpeg-dev is a virtual package provided by:
  libjpeg8-dev 8c-2
  libjpeg62-dev 6b1-1
You should explicitly select one to install.

So, I tried editing /usr/share/perl5/Sbuild/Build.pm:1136 to remove the '-q' 
bit, but unfortunately it didn't fix the issue.

I've checked that the apt-get command did NOT include '-q', and that was right. 
Still, for some reason, either sbuild doesn't get the output from apt-get, or 
apt-get isn't showing its
expected behaviour when run through sbuild, because I still got the same error 
messages. Adding a 'print(pipe: $_);' at line 1147, in the while(pipe) 

Bug#633777: [buildd-tools-devel] Bug#633777: sbuild: virtual dependency resolver broken?

[Thibaut VARENE]

On Wed, Jul 13, 2011 at 6:05 PM, Roger Leigh rle...@codelibre.net wrote:
 On Wed, Jul 13, 2011 at 05:38:16PM +0200, Thibaut VARENE wrote:

 In any case, the fact is it breaks the virtual resolver for packages with 
 multiple providers (i've tested that when there's only one provider, there 
 is no problem. I suppose apt-get does
 the right thing then).

 There are two areas of brokeness here: apt-get and sbuild itself.
 While apt-get is definitely misbehaving here, sbuild's internal
 resolver is also absolutely awful at working with virtual packages.
 While we did do some refactoring when introducing the apt resolver,
 it could well be that the root cause was apt-get being broken.
 You could try using the apt resolver which delegates all dependency
 resolution to apt-get.  It's the default in current unstable, and
 can handle virtual dependencies without issues, including alternatives.

So, I tried the 'aptitude' resolver, since I couldn't find any mention
of a 'apt' resolver in the source code (note by the way that as far as
I can tell, none of this is documented anywhere ;P) using the
following in .sbuildrc:
$build_dep_resolver=aptitude;

And it did fix the issue, while installing more stuff (aptitude)
into the chroot.

 I would also suggest trying the latest sbuild/libsbuild-perl in
 testing/unstable.  They should run without problems on squeeze by
 design.  If the bugs are still causing problems with this version,
 we can at least address them whereas updating the squeeze version
 is rather more difficult.

Well, given the lack of documentation, especially on upgrade process,
and my previous experience with generally painful upgrades from
version to version (0.60 entirely broke backward compatibility with
0.58 configs), I'm not exactly thrilled by the idea... ;P

Cheers,
T-Bone

-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/



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

Bug#633777: [buildd-tools-devel] Bug#633777: sbuild: virtual dependency resolver broken?

[Thibaut VARENE]

On Wed, Jul 13, 2011 at 6:38 PM, Roger Leigh rle...@codelibre.net wrote:
 On Wed, Jul 13, 2011 at 06:28:53PM +0200, Thibaut VARENE wrote:

 Well, given the lack of documentation, especially on upgrade process,
 and my previous experience with generally painful upgrades from
 version to version (0.60 entirely broke backward compatibility with
 0.58 configs), I'm not exactly thrilled by the idea... ;P

 In theory, we should be completely backward compatible--we continue
 to allow the use of older configuration variables in order to not
 break compatibility with older formats.  If you are seeing breakage,
 I would appreciate knowing what's broken, so we can fix it.

 We have definitely made the config parser stricter though--it will now
 error out where it would previously continue e.g. if you misnamed a
 variable.  And where we have removed configuration options, you might
 well be required to comment out/remove them from your configuration.
 But anything that's present in old and new versions should continue to
 work.  If it doesn't, I'll fix it.

Well, from the top of my head problems were:
- local config name changes (buildd.conf - .builddrc)
- removed/renamed config variables, which simply prevented
sbuild/buildd to run until commented out / renamed.
- config variable refactoring (the whole @distributions array was
brand new in 0.60 and didn't work well (read: at all) with the good ol
@take_from_dists(), and basically meant redoing entirely the buildd
local configuration) - this is what I call breaking backward compat,
fwiw ;-)
- upgrading schroot wasn't exactly a pleasant trip either

HTH

-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/



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

Bug#628568: external images should be provided by the package

[Thibaut VARENE]

tags 628568 moreinfo
thanks

On Mon, May 30, 2011 at 11:46 AM, martin f krafft madd...@debian.org wrote:
 Package: mod-musicindex-common
 Version: 1.3.5-1
 Severity: wishlist

 It seems possible to override much of the mod-musicindex look by
 providing a custom /musicindex/ alias or directory. However, the
 valid-xhtml etc. images are not fetched from there. Instead, it
 seems as if the module is hardcoded to check
 /usr/share/mod-musicindex for their presence and to fall back to
 fetching remote contents in their absence.

 Please either distribute those stock images with the package, or
 make it such that they are pulled from /musicindex/ instead of
 hardcoding the underlying filesystem location.

So, I'm having a hard time understanding this bug. The location is
hardcoded nowhere. As a matter of fact, the module does /exactly/ what
you require: it will lookup the filesystem path for the /musicindex
URI, and check whether the images are present in that folder or not.
If interested you can check out send_foot() at the bottom of html.c
for details.

This module was written with extreme portability in mind, and has
almost nothing hardcoded.

HTH

-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/



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

Bug#633671: schroot behaves differently depending on cwd

[Thibaut VARENE]

Package: schroot
Version: 1.4.19-1+squeeze1
Severity: normal

While debugging the old 'create-chroot.sh' script from pkern that was having 
hickups, I finally realized that schroot behaves
apparently inconsistently depending on the cwd:

This works:
buildd@envy:~$ schroot -c sid-ia64-sbuild -u root -- apt-get update
Hit http://debian.ens-cachan.fr sid InRelease
[...]

This doesn't work:
buildd@envy:~/chroots$ schroot -c sid-ia64-sbuild -u root -- apt-get update
E: Failed to change to directory '/home/buildd/chroots': No such file or 
directory

From what I can tell, trying to run schroot from any directory /below/ the 
home directory fails with the above error.
Running from higher directories (such as /, or /tmp) works.

I've traced both schroot invocations with -v, there is absolutely no difference 
(save of course for the session UUID) in the outputs.

HTH

-- System Information:
Debian Release: 6.0.2
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: ia64

Kernel: Linux 2.6.32.40 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=locale: Cannot set 
LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages schroot depends on:
ii  libboost-filesystem1.4 1.42.0-4  filesystem operations (portable pa
ii  libboost-program-optio 1.42.0-4  program options library for C++
ii  libboost-regex1.42.0   1.42.0-4  regular expression library for C++
ii  libboost-system1.42.0  1.42.0-4  Operating system (e.g. diagnostics
ii  libc6.12.11.2-10 Embedded GNU C Library: Shared lib
ii  libgcc11:4.4.5-8 GCC support library
ii  liblockdev11.0.3-1.4 Run-time shared library for lockin
ii  libpam0g   1.1.1-6.1 Pluggable Authentication Modules l
ii  libstdc++6 4.4.5-8   The GNU Standard C++ Library v3
ii  libunwind7 0.99-0.2  A library to determine the call-ch
ii  libuuid1   2.17.2-9  Universally Unique ID library
ii  schroot-common 1.4.19-1+squeeze1 common files for schroot

schroot recommends no packages.

Versions of packages schroot suggests:
pn  aufs-modules | unionfs-m none  (no description available)
pn  btrfs-tools  none  (no description available)
ii  debootstrap  1.0.26+squeeze1 Bootstrap a basic Debian system
pn  lvm2 none  (no description available)
ii  unzip6.0-4   De-archiver for .zip files

-- Configuration Files:
/etc/schroot/default/fstab changed:
/proc   /proc   nonerw,rbind0   0
/sys/sysnonerw,rbind0   0
/dev/devnonerw,rbind0   0
/tmp/tmpnonerw,bind 0   0

/etc/schroot/default/nssdatabases changed:
passwd
group
services
protocols
networks
hosts


-- debconf information:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = en_US.UTF-8
are supported and installed on your system.
perl: warning: Falling back to the standard locale (C).
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory



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

Bug#633671: [buildd-tools-devel] Bug#633671: schroot behaves differently depending on cwd

[Thibaut VARENE]

On Tue, Jul 12, 2011 at 9:33 PM, Roger Leigh rle...@codelibre.net wrote:

 This is known and expected behaviour.  The reason is that when you
 enter the chroot, schroot will change you into the /same directory/
 inside the chroot that you were in on the host system.  When you
 run a login shell, it will try a set of fallback directories; but
 when you run a command it's not possible to do that (see below).

 If you're in a location present in both the chroot and on the host,
 e.g. /, /usr, /tmp etc., it will work just fine.  If you don't
 bind mount /home and you're in /home/$user or in /srv/foobar, then
 the same path won't exist in the chroot, and schroot will bail out.

I see.

 The solution is to run schroot with the -d|--directory option to
 explictly specify the path you want inside the chroot.  In this
 case, you can simply use -d / to run in the root.

Good point, I've tweaked the script accordingly.

 The reason we don't implement a fallback is because it would make
 the behaviour unpredictable.  The exact logic is as follows:

OK. I'm not entirely sure I see how it would be unpredictable, and
more to the point why dchroot behaves differently from schroot, but
then again, I'm not very familiar with either tool.

The thing is that the error message isn't really explicit, when you're
unaware of this design choice... I don't how it could be improved
though.

 Chdir fallback behaviour:
[...]

noted

  Note that --debug=notice will show the internal fallback list
  computed for the session.

OK.

You might want to mark this bug as wontfix, it might serve as some
documentation in websearches ;-)

Thanks
T-Bone

-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/



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

Bug#633671: [buildd-tools-devel] Bug#633671: schroot behaves differently depending on cwd

[Thibaut VARENE]

On Tue, Jul 12, 2011 at 10:43 PM, Roger Leigh rle...@codelibre.net wrote:
 On Tue, Jul 12, 2011 at 09:50:22PM +0200, Thibaut VARENE wrote:
 On Tue, Jul 12, 2011 at 9:33 PM, Roger Leigh rle...@codelibre.net wrote:

  The reason we don't implement a fallback is because it would make
  the behaviour unpredictable.  The exact logic is as follows:

 OK. I'm not entirely sure I see how it would be unpredictable, and
 more to the point why dchroot behaves differently from schroot, but
 then again, I'm not very familiar with either tool.

 When you run a command, you might need it to operate in a specific
 directory.  Examples:

  rm foo
  ls foo
  make
  dpkg-buildpackage

 If we can't chdir to the specific directory, the results could be
 both unpredictable and disastrous!  In the case of other commands
 such as apt-get ... the current directory doesn't matter, but
 there's no way for schroot to know that in advance, so we always
 have to play it safe.

Yeah I get that.

 The thing is that the error message isn't really explicit, when you're
 unaware of this design choice... I don't how it could be improved
 though.

 We could add an additional information message e.g.

 E: Failed to change to directory ‘/tmp/syscheck’: No such file or directory
 I: Does this directory exist inside the chroot?
 I: Use the --directory option to run the command in a different directory.

Well, the problem is that when I first saw the error message, I didn't
realize it was talking about the chroot, but I quickly suspected it
(it wouldn't have made /any/ sense otherwise). This clarifies the
situation. What remains unclear to the average user unaware of the
implications of a fallback policy for commands is /why/ the directory
needs to be in the chroot. Put another way, at some point I started
believing schroot wouldn't work unless the whole /home/buildd was
loop-mounted into the chroot. I didn't realize it only need the
specific directory it was executed from. I suppose some extra
documentation in the manpages regarding the behaviour of schroot when
executing shells vs commands might be helpful to clarify this.

Cheers,
T-Bone

-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/



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

Bug#633509: [buildd-tools-devel] Bug#633509: Bug#633509: E: /etc/buildd/wanna-build.conf: Errors found in configuration file:

[Thibaut VARENE]

On Mon, Jul 11, 2011 at 10:42 AM, Roger Leigh rle...@codelibre.net wrote:
 On Mon, Jul 11, 2011 at 09:27:42AM +0200, Philipp Kern wrote:
 Thibaut,

 am Mon, Jul 11, 2011 at 12:59:47AM +0200 hast du folgendes geschrieben:
  Just curious, has wanna-build 0.60.0-2 ever been tested outside of a
  debian official buildd setup? ;P

 we don't use the packages on buildd.d.o.  That's why.

 And we have subsequently removed it.  I would recommend using the
 wanna-build used by buildd.debian.org

  git://git.debian.org/mirror/wanna-build.git

 Note that it's a pain to configure, and you'll probably need to
 get some of the scripts from buildd.debian.org to make it usable.

Yeah well, I'll stick to my 2006 version from neuro, at least it works.
Why ship broken packages? It's detrimental to the users...

-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/



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

Bug#633509: [buildd-tools-devel] Bug#633509: Bug#633509: E: /etc/buildd/wanna-build.conf: Errors found in configuration file:

[Thibaut VARENE]

On Mon, Jul 11, 2011 at 11:34 AM, Roger Leigh rle...@codelibre.net wrote:
 On Mon, Jul 11, 2011 at 11:19:57AM +0200, Thibaut VARENE wrote:
 On Mon, Jul 11, 2011 at 10:42 AM, Roger Leigh rle...@codelibre.net wrote:
  On Mon, Jul 11, 2011 at 09:27:42AM +0200, Philipp Kern wrote:
  Thibaut,
 
  am Mon, Jul 11, 2011 at 12:59:47AM +0200 hast du folgendes geschrieben:
   Just curious, has wanna-build 0.60.0-2 ever been tested outside of a
   debian official buildd setup? ;P
 
  we don't use the packages on buildd.d.o.  That's why.
 
  And we have subsequently removed it.  I would recommend using the
  wanna-build used by buildd.debian.org
 
   git://git.debian.org/mirror/wanna-build.git
 
  Note that it's a pain to configure, and you'll probably need to
  get some of the scripts from buildd.debian.org to make it usable.

 Yeah well, I'll stick to my 2006 version from neuro, at least it works.
 Why ship broken packages? It's detrimental to the users...

 In the wannabuild case, having zero users resulted in bitrot.  Not at

Not zero, 1 ;)
Problem is, I've delayed for a very longtime the upgrade because every
new version had a tendency to break backward compat with config files
and such. I was running sbuild/buildd 0.58-something from db.d.o until
I decided to move. The upgrade wasn't painless, but at least it
worked. What prompts me for the wanna-build move is the lack of
--built support from the old version, but that's not a really big deal
either. Also I hoped that moving to what's in squeeze would mean
moving to something slightly more supported. Seems it's not really
the case...

 all good, and that was why it was removed.  The actual bugs in it are
 most likely fairly simple to fix--it just needs someone with the time
 to do it.  Most are as a result of changes in other parts of the
 codebase.

Well, I'd be glad to help, but I have no idea how to do that...


 Note that the new wanna-build above uses PostgreSQL rather than
 MLDBM, so has a number of advantages over the old neuro version.


Given the limited number of packages being handled (about 80), it's
not worth the hassle. I planned to keep using the MLDBM backend. Is it
broken?

Thanks
T-Bone

-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/



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

Bug#633464: Can't locate object method fixup_pkgv via package Sbuild::Build at /usr/bin/sbuild line 166.

[Thibaut VARENE]

Package: sbuild
Version: 0.60.0-2squeeze1
Severity: normal

It seems sbuild and libsbuild-perl 0.60.0-2squeeze1 are out of sync: 
/usr/bin/sbuild requires fixup_pkgv()
which isn't part of the /usr/share/perl5/Sbuild/Build.pm shipped with 
libsbuild-perl anymore.

Renders sbuild unusable in my buildd setup.

Sbuild called with:
sbuild --apt-update --batch --stats-dir=/home/buildd/stats --dist=unstable 
packagname

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

Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages sbuild depends on:
ii  adduser3.112+nmu2add and remove users and groups
ii  libsbuild-perl 0.60.0-2squeeze1  Tool for building Debian binary pa
ii  perl   5.10.1-17squeeze1 Larry Wall's Practical Extraction 
ii  perl-modules   5.10.1-17squeeze1 Core Perl modules

Versions of packages sbuild recommends:
ii  debootstrap  1.0.26+squeeze1 Bootstrap a basic Debian system
ii  fakeroot 1.14.4-1Gives a fake root environment

Versions of packages sbuild suggests:
pn  deborphan none (no description available)
ii  wget  1.12-2.1   retrieves files from the web

-- 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#633464: [buildd-tools-devel] Bug#633464: Can't locate object method fixup_pkgv via package Sbuild::Build at /usr/bin/sbuild line 166.

[Thibaut VARENE]

On Sun, Jul 10, 2011 at 5:04 PM, Roger Leigh rle...@codelibre.net wrote:
 tags 633464 + confirmed
 severity 633464 serious
 thanks

 On Sun, Jul 10, 2011 at 04:09:29PM +0200, Thibaut VARENE wrote:
 Package: sbuild
 Version: 0.60.0-2squeeze1
 Severity: normal

 It seems sbuild and libsbuild-perl 0.60.0-2squeeze1 are out of sync: 
 /usr/bin/sbuild requires fixup_pkgv()
 which isn't part of the /usr/share/perl5/Sbuild/Build.pm shipped with 
 libsbuild-perl anymore.

 Renders sbuild unusable in my buildd setup.

 Sbuild called with:
 sbuild --apt-update --batch --stats-dir=/home/buildd/stats --dist=unstable 
 packagname

 fixup_pkgv was removed in 0.60.0-2squeeze1 and is no longer used
 anywhere else.  It looks like this was missed (it's only called
 with --batch).  Still annoying that it got missed; I'll add a
 --batch test to the testsuite to catch this.

 Fixing this should be as simple as deleting the fixup_pkgv line
 in /usr/bin/sbuild.  If you do that, does this fix the issue for
 you?

Apparently it does, yes. I've tried building a package with the line
commented out and it seems all went fine.

 If it does, I'll see if we can get a fix into stable.  Since it
 makes sbuild unusable for your use case, I'll set the severity
 higher.

Thanks,
T-Bone

-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/



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

Bug#633509: E: /etc/buildd/wanna-build.conf: Errors found in configuration file:

[Thibaut VARENE]

Package: wanna-build
Version: 0.60.0-2squeeze1
Severity: normal

Still trying to upgrade my old buildd setup to something a little more current, 
I'm running into interesting
issues.

On this machine, after installing wanna-build and leaving it with its default 
configuration, simply running wanna-build
yields:

$ wanna-build
E: /etc/buildd/wanna-build.conf: Errors found in configuration file:
Global symbol $notforus_maint requires explicit package name at (eval 12) 
line 101.
Global symbol $log_mail requires explicit package name at (eval 12) line 104.
Global symbol $stat_mail requires explicit package name at (eval 12) line 107.
Global symbol $web_stats requires explicit package name at (eval 12) line 110.

I have not modified /etc/buildd/wanna-build.conf in any way, it's straight 
what's shipped with the package.

Commenting out the offending lines (which are nonetheless necessary config 
options) then gives:
Can't use an undefined value as a HASH reference at 
/usr/share/perl5/Sbuild/ConfBase.pm line 98.

For fun and giggles, I tried installing wanna-build on a clean amd64 squeeze 
box, and got this instead right after instal:

$ wanna-build
Can't locate DBI.pm in @INC (@INC contains: /etc/perl 
/usr/local/lib/perl/5.10.1 /usr/local/share/perl/5.10.1 /usr/lib/perl5 
/usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 
/usr/local/lib/site_perl .) at /usr/share/perl5/Sbuild/DB/Postgres.pm line 30.
BEGIN failed--compilation aborted at /usr/share/perl5/Sbuild/DB/Postgres.pm 
line 30.
Compilation failed in require at /usr/bin/wanna-build line 32.
BEGIN failed--compilation aborted at /usr/bin/wanna-build line 32.

I suppose that's a different bug though...

Anyway, turns out this incarnation of wanna-build is apparently totally 
unusable, I had to downgrade.

Just curious, has wanna-build 0.60.0-2 ever been tested outside of a debian 
official buildd setup? ;P

-- System Information:
Debian Release: 6.0.2
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: ia64

Kernel: Linux 2.6.32-3-mckinley (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages wanna-build depends on:
ii  libmldbm-perl  2.04-1module for storing multidimensiona
ii  libsbuild-perl 0.60.0-2squeeze1  Tool for building Debian binary pa
ii  perl   5.10.1-17squeeze2 Larry Wall's Practical Extraction 
ii  perl-modules   5.10.1-17squeeze2 Core Perl modules

Versions of packages wanna-build recommends:
ii  cron3.0pl1-116   process scheduling daemon
ii  postfix [mail-transport 2.7.1-1+squeeze1 High-performance mail transport ag
pn  postgresql-8.4-debversi none   (no description available)
ii  wget1.12-2.1 retrieves files from the web

Versions of packages wanna-build suggests:
ii  gnupg 1.4.10-4   GNU privacy guard - a free PGP rep

-- 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#619674: libotr: please wipe out dependency_libs from .la files (Policy 10.2)

[Thibaut VARENE]

On Sat, Jun 18, 2011 at 2:06 PM, Andreas Metzler
ametz...@downhill.at.eu.org wrote:
 On 2011-03-29 Thibaut VARENE vare...@debian.org wrote:
 tags 619674 pending
 thanks

 Hi Steve,

 Thanks for the patch, will apply on next upload.
 [...]

 Hello,
 Any idea when this might happen? libotr is one out of 4 packages
 (actually 3, jabberd2 is broken anyway) that is blocking me from
 dropping libgcrypt's la file and converting it to multi-arch.

 thanks, cu andreas

Well, I'm currently unable to do an upload atm, but if you feel like
doing a NMU to address this pending issue I would certainly not object
;-)
(I have nothing else to change in the package, besides bumping std-ver
and changing dh_clean -k in rules, both not being especially urgent).

Thanks

T-Bone

-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/



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

Bug#619674: libotr: please wipe out dependency_libs from .la files (Policy 10.2)

[Thibaut VARENE]

On Sat, Jun 18, 2011 at 2:54 PM, Andreas Metzler
ametz...@downhill.at.eu.org wrote:
 On 2011-06-18 Thibaut VARENE vare...@debian.org wrote:
 On Sat, Jun 18, 2011 at 2:06 PM, Andreas Metzler
 ametz...@downhill.at.eu.org wrote:
 [...]
 Well, I'm currently unable to do an upload atm, but if you feel like
 doing a NMU to address this pending issue I would certainly not object
 ;-)
 [...]

 Hello,

 thank for the quick heads-up. I have just uploaded the NMU, diff is
 attached.

Thanks!

-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/



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

Bug#515653: fsync() based test version

[Thibaut VARENE]

On Wed, May 11, 2011 at 8:48 PM, Martin Steigerwald mar...@lichtvoll.de wrote:

 So my approach failed. But I wonder whether your approach would have done
 more good than my daily backups, since uptimed doesn't do a regular backup
 of the configuration, but only on stopping it, maybe also on starting it.

If by configuration you mean its database, then you're wrong. The
database (and backup) is written every UPDATE_INTERVAL seconds.

-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/



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

Bug#515653: how to recover lost uptime record by calculating manually

[Thibaut VARENE]

On Wed, May 11, 2011 at 9:10 PM, Martin Steigerwald mar...@lichtvoll.de wrote:
 I attached a text file that shows on how to recover / re-set a lost uptime
 span in the last record manually by editing records file. Attached due to
 word wrap in mails.

 I will resync the whole issue. I might be testing with fsync() everywhere,
 cause I want to fix that truncated file issue *at the cause*. When it then
 still does not work as expected, I at least now, that the file is truncated
 even due to use of fsync() and can then file a linux kernel bug report.

Have fun.

-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/



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

Bug#515653: different way of saving needed

[Thibaut VARENE]

On Wed, May 11, 2011 at 9:28 PM, Martin Steigerwald mar...@lichtvoll.de wrote:
 the fsync() based approach - when it works - would give the following
 advantage: either the new records or the old records file is there. Thus at
 maximum one interval of uptime is lost. With checking sanity of
 configuration file everything since the last backup from uptimed is lost,
 which might be days, *weeks or more..

 An idea comes to my mind: How about saving the *current* record in an own
 file in the same format, one line, thats no more than a sector. Either this
 thing is on disk or the old one is still there, fsync() or not.

By which logic do you come to that conclusion? You seem to be gravely
mistaken about how the VFS works. Also, did you notice that a 50-entry
record file is generally under 4KB, typical filesystem block size?

 Then when uptimed starts up from a fresh boot it generated a new bootid
 and integrated the old one into the records file. uprecords would be
 changed to read both records and current-record, merging them.

Bootid is not used on BSD.

 This also makes saving records an O(1) operation. No matter how many
 records are stored in the records file, the current-records file just holds
 the current record.

Wow, now that's a performance improvement. We're talking dumping less
than 5KB to disk...

Other than that I give you some credit: I do believe that such a
scheme would indeed only lose the current/last uprecord entry upon
crash. Except it still doesn't fix the issue which you seem to be
really unhappy about, which is uptimed not being able to track uptimes
after crash (which is a feature, afai'm concerned), and it will
probably quite complicate the whole thing.

And oh, what's happening to people running new (per your design)
uptimed with old database, and/or re-running old uptimed with new
database?

The patch I proposed should most likely fix 99.9% of the issues you're
complaining about, while remaining 100% compatible with the current
behavior.

Finally, if you want to propose a design change and/or a patch, I
suggest CCing or writing directly to upstream, as I am *not* uptimed's
developer.

-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/



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

Bug#622565: still ships rules files in /etc/udev/

[Thibaut VARENE]

Hi,

I'm considering orphaning this package which is mostly abandoned upstream.

If you feel like taking over, now would be a good time to do so ;-)

Cheers

On Wed, Apr 13, 2011 at 3:13 AM, Marco d'Itri m...@linux.it wrote:
 Package: lomoco
 Severity: important

 Please move all rules files to /lib/udev/rules.d/ .
 Rules files in /etc/udev/ are especially bad because they are not
 re-read by udev on upgrades.

 --
 ciao,
 Marco

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.11 (GNU/Linux)

 iEYEARECAAYFAk2k+NEACgkQFGfw2OHuP7HKWgCeOnRCg1huh0Kms0mjQkd/Vqqh
 GMMAn1Ez++en//B+Kc5gTx3UvZCehMTE
 =5yrl
 -END PGP SIGNATURE-





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

Bug#619674: libotr: please wipe out dependency_libs from .la files (Policy 10.2)

[Thibaut VARENE]

tags 619674 pending
thanks

Hi Steve,

Thanks for the patch, will apply on next upload.

Cheers,

T-Bone

On Sat, Mar 26, 2011 at 2:45 AM, Steve Langasek
steve.langa...@canonical.com wrote:
 Package: libotr
 Version: 3.2.0-2
 Severity: normal
 Tags: patch
 User: ubuntu-de...@lists.ubuntu.com
 Usertags: origin-ubuntu natty ubuntu-patch

 Hi Thibaut,

 The attached patch has just been applied to the Ubuntu libotr package, to
 null out the dependency_libs field in the libtool .la files being shipped in
 the -dev package.  This is generally a good idea because it avoids causing
 consumers of your library to require other .la files listed here to be
 available at build time when they're not actually needed (i.e., in the
 dynamic linking common case).  It's specifically a good idea right now
 because multiarch is imminent, and that means the .la files referenced here
 are going to *move* soon, causing build failures for anything using libtool
 to build against libotr.  As long as libotr is going to need a rebuild to
 fix up the invalid .la references, it would be nice to get rid of them
 altogether.

 Thanks,
 --
 Steve Langasek                   Give me a lever long enough and a Free OS
 Debian Developer                   to set it on, and I can move the world.
 Ubuntu Developer                                    http://www.debian.org/
 slanga...@ubuntu.com                                     vor...@debian.org




-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/



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