Bug#1073205: docker-compose: new python3-requests dependency brokes docker-compose

[anomie]

This appears to be a duplicate of bug #1073196 in python3-docker. I was
able to reproduce this problem with version 6.1.3-0.1 of that package
but can no longer reproduce after updating that package to 6.1.3-0.2.

Bug#1067547: FTBFS: "vsnprintf is so broken we can't compensate. Sorry."

[anomie]

The check for whether snprintf and vsnprintf honors its length argument
was failing due to the use of -Werror=implicit-function-declaration in
Debian's builds now.

https://sourceforge.net/p/wmweatherplus/git/ci/393394818cf4aa9b34071297a6947409cb19d74b/
should fix it for you.

Bug#989315: composer: Needs update for GitHub token format change

[anomie]

Package: composer
Version: 2.0.9-2

On March 4, 2021, GitHub announced a change to the format of their
tokens: 
https://github.blog/changelog/2021-03-04-authentication-token-format-updates/

A few days later, Composer updated their token validation regex to
account for the new token format: 
https://github.com/composer/composer/commit/dc83ba93f3d8a35629f9a387632e8cd373a144d0#diff-0ad46c42da3ec5293b4b4df61bb6c837304d5e72f1a434ba3cff31c0f3e44934

It looks like Debian is still on 2.0.9 for the Bullseye freeze, implying
that Bullseye will release with 2.0.9. You may want to backport the
above fix so that people can use new format GitHub tokens with composer.

Bug#989260: exim4-config: Default configuration enables sieve filters but cannot deliver from them

[anomie]

Package: exim4-config
Version: 4.94.2-6

The default configuration provided by exim4-config allows for sieve
filters to be used in ~/.forward, but if a user attempts to configure
such a filter their mail delivery will most likely break.

More specifically, the keep action (including the default "keep" when
nothing matches the filter) will fail to deliver mail with an error
along the lines of

  2021-05-30 15:17:10 1lnNBd-rr-U4 == save inbox  
R=userforward T=address_file defer (-21): appendfile: file or directory name 
"inbox" is not absolute

Most uses of a fileinto action will do the same, unless the user
specifies an absolute path to the desired mailbox file rather than the
plain mailbox name that the sieve specification calls for.

This can be tested as follows, using `docker run --rm -it debian:sid`:

  # Install exim
  apt-get update
  apt-get -y install dialog
  apt-get -y install exim4

  # Create test user and .forward file
  useradd --create-home test
  touch /home/test/.forward
  chown test.test /home/test/.forward
  chmod 0644 /home/test/.forward

  # Test 1: Default "keep", should deliver to /var/mail/test but fails
  echo '# Sieve filter' > /home/test/.forward
  mail test@localhost <<<"Testing"
  sleep 1

  # Test 2: Relative folder name, should deliver to /home/test/mail/testing but 
fails
  echo '# Sieve filter' > /home/test/.forward
  echo 'require "fileinto";' >> /home/test/.forward
  echo 'fileinto "testing";' >> /home/test/.forward
  mail test@localhost <<<"Testing 2"
  sleep 1

  # Test 3: Absolute path, will deliver to /home/test/somefile
  echo '# Sieve filter' > /home/test/.forward
  echo 'require "fileinto";' >> /home/test/.forward
  echo 'fileinto "/home/test/somefile";' >> /home/test/.forward
  mail test@localhost <<<"Testing 3"
  sleep 1

  # Show logs
  cat /var/log/exim4/mainlog

Adding the following to the "address_file" transport seems to fix it:

  group = mail
  file = ${if eq{$address_file}{inbox} \
   {/var/mail/$local_part_data} \
   {${if eq{${substr_0_1:$address_file}}{/} \
 {$address_file} \
 {$home/mail/$address_file} \
   }} \
 }

Or if you'd rather just disable sieve filters by default (so manual
configuration is needed to enable them), you might set
`forbid_sieve_filter` in the "userforward" router.

P.S. README.SIEVE.gz needs updating for the taint change in 4.94-18, it
uses $local_part rather than $local_part_data.

Bug#986117: yarnpkg is not compatible with node-proper-lockfile 3.0.0+

[anomie]

Package: yarnpkg
Version: 1.22.10+~cs22.25.14-2

Yarn uses proper-lockfile to implement its `--mutex=file:whatever`
option. Its package.json depends on proper-lockfile ^2.0.0, which had
the calling convention

  lockfile.lock( file, options, callback )

In proper-lockfile 3.0.0 they removed that calling convention in favor
of use of promises (much like what happened with mkdirp in bug #972952).
This causes yarn's callback to never be called, so yarn does nothing
other than print the command name. See, for example,

  $ yarn init --mutex=file:whatever
  yarn init v1.22.10
  $

Bug#980775: your initial example also fails with upstream

[anomie]

On Sat, 23 Jan 2021 15:37:08 +0100 Paolo Greppi  wrote:
> you need to add the following as in my previous message:
> 
>cd foo
>yes '' | yarn init
>cd ..

Yes. The example was simplified to show exactly the bug at hand, not to
fully work.

I confirm that your patch fixes the bug I was seeing. Thanks!

Bug#980775: yarnpkg is not compatible with node-uuid 7.0.0+

[anomie]

Package: yarnpkg
Version: 1.22.10+~cs22.25.14-1

>From https://www.npmjs.com/package/uuid/v/7.0.1#default-export-removed:

> Default Export Removed
>
> uuid@3 was exporting the Version 4 UUID method as a default export:
> 
> const uuid = require('uuid'); // <== REMOVED!
> 
> This usage pattern was already discouraged in uuid@3 and has been removed in 
> uuid@7.

But yarnpkg uses that pattern in src/resolvers/exotics/file-resolver.js,
src/cli/commands/install.js, and src/cli/commands/import.js.

This results in failures at runtime, for example

  $ mkdir -p /tmp/test/foo
  $ cd /tmp/test
  $ yes '' | yarn init
  yarn init v1.22.10
  question name (test): 
  question version (1.0.0): 
  question description: 
  question entry point (index.js): 
  question repository url: 
  question author: 
  question license (MIT): 
  question private: 
  success Saved package.json
  Done in 0.14s.
  $ yarn add file:foo
  yarn add v1.22.10
  info No lockfile found.
  [1/4] Resolving packages...
  error An unexpected error occurred: "Cannot read property 'v4' of undefined".
  info If you think this is a bug, please open a bug report with the 
information provided in "/tmp/test/yarn-error.log".
  info Visit https://yarnpkg.com/en/docs/cli/add for documentation about this 
command.

Bug#972952: node-mkdirp 1.0 is incompatible with 0.5, breaks yarnpkg

[anomie]

Package: node-mkdirp
Version: 1.0.4-2
Severity: critical

I don't know whether to report this against node-mkdirp for breaking
compatibility, or yarnpkg for depending on "node-mkdirp (>= 0.5.1)"
rather than "node-mkdirp (>= 0.5.1), node-mkdirp (<<1.0.0)". Either way,
things are currently broken in unstable and shouldn't migrate to
testing.

I upgraded various packages this morning, and found that yarn would no
longer work.

  $ yarn
  yarn install v1.22.4
  warning Skipping preferred cache folder "/home/redacted/.cache/yarn" because 
it is not writable.
  warning Skipping preferred cache folder "/tmp/.yarn-cache-1000" because it is 
not writable.
  warning Skipping preferred cache folder "/tmp/.yarn-cache" because it is not 
writable.
  error Yarn hasn't been able to find a cache folder it can use. Please use the 
explicit --cache-folder option to tell it what location to use, or make one of 
the preferred locations writable.
  info Visit https://yarnpkg.com/en/docs/cli/install for documentation about 
this command.

This turns out to be due to this error being thrown:

  TypeError: invalid options argument
at optsArg (/usr/share/nodejs/mkdirp/lib/opts-arg.js:13:11)
at mkdirp (/usr/share/nodejs/mkdirp/index.js:11:10)
at /usr/share/nodejs/yarn/lib/util/promise.js:37:10
at new Promise ()
at /usr/share/nodejs/yarn/lib/util/promise.js:17:12
at Object. (/usr/share/nodejs/yarn/lib/util/fs.js:1024:15)
at Generator.throw ()
at step (/usr/share/nodejs/babel-runtime/helpers/asyncToGenerator.js:17:30)
at /usr/share/nodejs/babel-runtime/helpers/asyncToGenerator.js:30:13

It turns out yarn is expecting node-mkdirp to accept a callback, which
was apparently dropped in node-mkdirp 1.0 in favor of it returning a
promise.

Downgrading node-mkdirp to 0.5.1-2 fixed it:

  $ yarn
  yarn install v1.22.4
  info No lockfile found.
  [1/4] Resolving packages...
  [2/4] Fetching packages...
  [3/4] Linking dependencies...
  [4/4] Building fresh packages...
  success Saved lockfile.
  Done in 0.07s.

Bug#970525: docker.io: Unable to start minikube/kubernetes containers: unable to find user 0: invalid argument

[anomie]

On Sun, Sep 20, 2020 at 09:58:45AM +0700, El boulangero wrote:
> Do you know what's special with the `tianon/true` image? On what OS/release
> is it based?

It's an image that contains only a single binary that returns 0. That
binary uses no libraries, not even libc.

It's intended as an extremely light-weight image for purposes that don't
need a whole OS. See, for example,
https://stackoverflow.com/questions/37120260/configure-docker-compose-override-to-ignore-hide-some-containers

It seems that something changed between 19.03.12+dfsg1-3 and
19.03.12+dfsg1-4 that is somehow or other assuming the container
contains more infrastructure. If you determine that the bug is upstream,
feel free to forward it to them (and, ideally, revert whatever patch was
added to 19.03.12+dfsg1-4 that caused the problem in the mean time to
avoid breaking other software on the system).

Bug#970525: docker.io: Unable to start minikube/kubernetes containers: unable to find user 0: invalid argument

[anomie]

Here's a simpler test case:

  $ sudo dpkg -i docker.io_19.03.12+dfsg1-4_amd64.deb 
  (Reading database ... 257350 files and directories currently installed.)
  Preparing to unpack docker.io_19.03.12+dfsg1-4_amd64.deb ...
  Unpacking docker.io (19.03.12+dfsg1-4) over (19.03.12+dfsg1-3) ...
  Setting up docker.io (19.03.12+dfsg1-4) ...
  insserv: Script sysstat has overlapping Default-Start and Default-Stop 
runlevels (2 3 4 5) and (2 3 4 5). This should be fixed.
  Processing triggers for systemd (246.5-1) ...
  Processing triggers for man-db (2.9.3-2) ...
  $ sudo systemctl restart docker
  $ sudo docker run tianon/true && echo "ok"
  docker: Error response from daemon: unable to find user 0: invalid argument.
  ERRO[] error waiting for container: context canceled 

versus

  $ sudo dpkg -i docker.io_19.03.12+dfsg1-3_amd64.deb 
  dpkg: warning: downgrading docker.io from 19.03.12+dfsg1-4 to 19.03.12+dfsg1-3
  (Reading database ... 257350 files and directories currently installed.)
  Preparing to unpack docker.io_19.03.12+dfsg1-3_amd64.deb ...
  Unpacking docker.io (19.03.12+dfsg1-3) over (19.03.12+dfsg1-4) ...
  Setting up docker.io (19.03.12+dfsg1-3) ...
  insserv: Script sysstat has overlapping Default-Start and Default-Stop 
runlevels (2 3 4 5) and (2 3 4 5). This should be fixed.
  Processing triggers for systemd (246.5-1) ...
  Processing triggers for man-db (2.9.3-2) ...
  $ sudo systemctl restart docker
  $ sudo docker run tianon/true && echo "ok"
  ok

Bug#933230: acpid: Race during startup can result in event devices not being opened

[anomie]

Package: acpid
Version: 1:2.0.31-2

When using netlink and the input layer, acpid opens the existing devices
in /dev/input/event* first and only after sets an inotify to be told
about newly created devices. If an event device is created between the
time acpid reads the directory and the time it sets the inotify, it
won't open that device and events provided by that device will be lost.

On my system, this race happens frequently for /dev/input/event8 "Video
Bus" during boot, preventing acpid from handling my system's brightness
keys.

The attached patch changes the ordering, setting the inotify before
opening the existing devices. It also adds a check to prevent
double-opening of a device if it is created between the inotify and the
reading of the directory.
diff -urN acpid-2.0.31-old/acpid.c acpid-2.0.31/acpid.c
--- acpid-2.0.31-old/acpid.c	2018-03-29 11:05:57.252312727 -0400
+++ acpid-2.0.31/acpid.c	2019-07-27 15:48:34.468992622 -0400
@@ -99,12 +99,12 @@
 	}
 
 	if (netlink) {
-		/* open the input layer */
-		open_input();
-
 		/* watch for new input layer devices */
 		open_inotify();
 
+		/* open the input layer */
+		open_input();
+
 		/* open netlink */
 		open_netlink();
 	}
diff -urN acpid-2.0.31-old/input_layer.c acpid-2.0.31/input_layer.c
--- acpid-2.0.31-old/input_layer.c	2018-08-01 10:11:59.934141098 -0400
+++ acpid-2.0.31/input_layer.c	2019-07-27 15:50:55.725832853 -0400
@@ -490,6 +490,12 @@
 	for (i = 0; i < globbuf.gl_pathc; ++i) {
 		filename = globbuf.gl_pathv[i];
 
+		/* skip if already opened */
+		if (find_connection_name(filename) != NULL) {
+			success = 1;
+			continue;
+		}
+
 		/* open this input layer device file */
 		if (open_inputfile(filename) == 0)
 			success = 1;

Bug#919019: Interval timers with CLOCK_*_CPUTIME_ID fail to reschedule with 4.19.13-1

[anomie]

Package: linux-image-4.19.0-1-amd64
Version: 4.19.13-1

The attached test program should print about 100 lines each for "Hit
CLOCK_MONOTONIC!", "Hit CLOCK_PROCESS_CPUTIME_ID!", and "Hit
CLOCK_THREAD_CPUTIME_ID!".

On my laptop running kernel linux-image-4.19.0-1-amd64 version
4.19.13-1, however, it prints the ~100 for CLOCK_MONOTONIC but only one
each for CLOCK_PROCESS_CPUTIME_ID and CLOCK_THREAD_CPUTIME_ID.

On a VirtualBox virtual machine, freshly installed and dist-upgraded to
sid, I see the same thing. Downgrading to version 4.19.12-1 from
https://snapshot.debian.org/package/linux-signed-amd64/4.19.12%2B1/#linux-image-4.19.0-1-amd64_4.19.12-1
(and rebooting, of course) causes the test program to give the expected
output.

I don't know if this was something broken upstream or if it's something
specific to Debian's kernel package. Please forward upstream if
appropriate. Thanks!
/* Compile:
   gcc foo.c -o foo -lrt
*/

#include 
#include 
#include 
#include 
#include 
#include 

void handle_event( union sigval sv ) {
printf( "Hit %s!\n", (const char *)sv.sival_ptr );
}

void test( const char *name, clockid_t clock_id ) {
timer_t timer;
struct sigevent ev;
struct itimerspec start = { { 0, 2000 }, { 0, 2000 } };
struct itimerspec zero = { { 0, 0 }, { 0, 0 } };
struct timespec ts0, ts1;

printf( "Testing %s...\n", name );

memset( &ev, 0, sizeof(ev) );
ev.sigev_notify = SIGEV_THREAD;
ev.sigev_notify_function = handle_event;
ev.sigev_value.sival_ptr = (void *)name;

if ( timer_create( clock_id, &ev, &timer ) != 0 ) {
fprintf( stderr, "Failed to create %s timer: %s\n", name, strerror( errno ) );
return;
}
if ( timer_settime( timer, 0, &start, NULL ) != 0 ) {
fprintf( stderr, "Failed to start %s timer: %s\n", name, strerror( errno ) );
return;
}

clock_gettime( clock_id, &ts0 );
ts1 = ts0;
ts0.tv_sec += 2;
while ( ts1.tv_sec < ts0.tv_sec || ts1.tv_sec == ts0.tv_sec && ts1.tv_nsec < ts0.tv_nsec ) {
clock_gettime( clock_id, &ts1 );
}

if ( timer_settime( timer, 0, &zero, NULL ) != 0 ) {
fprintf( stderr, "Failed to stop %s timer: %s\n", name, strerror( errno ) );
}
if ( timer_delete( timer ) != 0 ) {
fprintf( stderr, "Failed to delete %s timer: %s\n", name, strerror( errno ) );
}
printf( "Done testing %s\n", name );
}

int main( void ) {
test( "CLOCK_MONOTONIC", CLOCK_MONOTONIC );
test( "CLOCK_PROCESS_CPUTIME_ID", CLOCK_PROCESS_CPUTIME_ID );
test( "CLOCK_THREAD_CPUTIME_ID", CLOCK_THREAD_CPUTIME_ID );
return 0;
}

Bug#909109: php-memcached package is missing support for PHP 7.0, 7.1, and 7.3

[anomie]

Package: php-memcached
Version: 3.0.4+2.2.0-3

For some reason the current version of the package only contains the
extension files for PHP 7.2, while Debian currently also has packages
php7.0, php7.1, and php7.3.

  $ dpkg -c php-memcached_3.0.4+2.2.0-3_amd64.deb 
  drwxr-xr-x root/root 0 2018-08-19 11:07 ./
  drwxr-xr-x root/root 0 2018-08-19 11:07 ./etc/
  drwxr-xr-x root/root 0 2018-08-19 11:07 ./etc/php/
  drwxr-xr-x root/root 0 2018-08-19 11:07 ./etc/php/7.2/
  drwxr-xr-x root/root 0 2018-08-19 11:07 ./etc/php/7.2/mods-available/
  -rw-r--r-- root/root   176 2018-08-19 11:07 
./etc/php/7.2/mods-available/memcached.ini
  drwxr-xr-x root/root 0 2018-08-19 11:07 ./usr/
  drwxr-xr-x root/root 0 2018-08-19 11:07 ./usr/lib/
  drwxr-xr-x root/root 0 2018-08-19 11:07 ./usr/lib/php/
  drwxr-xr-x root/root 0 2018-08-19 11:07 ./usr/lib/php/20170718/
  -rw-r--r-- root/root114704 2018-08-19 11:07 
./usr/lib/php/20170718/memcached.so
  drwxr-xr-x root/root 0 2018-08-19 11:07 ./usr/share/
  drwxr-xr-x root/root 0 2018-08-19 11:07 ./usr/share/doc/
  drwxr-xr-x root/root 0 2018-08-19 11:07 ./usr/share/doc/php-memcached/
  -rw-r--r-- root/root   362 2018-08-19 11:07 
./usr/share/doc/php-memcached/NEWS.Debian.gz
  -rw-r--r-- root/root  1875 2017-11-21 00:01 
./usr/share/doc/php-memcached/README.markdown
  -rw-r--r-- root/root  3075 2018-08-19 11:07 
./usr/share/doc/php-memcached/changelog.Debian.gz
  -rw-r--r-- root/root  3577 2018-08-19 11:07 
./usr/share/doc/php-memcached/copyright

Rebuilding php-memcached using dpkg-builpackage (after rebuilding various of its
dependencies, which also seem to suffer from this bug) generates a version that
does have the necessary extension files.

  $ dpkg -c 
/usr/local/src/bugfix-debs/php-redis/php-memcached_3.0.4+2.2.0-3_amd64.deb 
  drwxr-xr-x root/root 0 2018-08-19 11:07 ./
  drwxr-xr-x root/root 0 2018-08-19 11:07 ./etc/
  drwxr-xr-x root/root 0 2018-08-19 11:07 ./etc/php/
  drwxr-xr-x root/root 0 2018-08-19 11:07 ./etc/php/7.0/
  drwxr-xr-x root/root 0 2018-08-19 11:07 ./etc/php/7.0/mods-available/
  -rw-r--r-- root/root   176 2018-08-19 11:07 
./etc/php/7.0/mods-available/memcached.ini
  drwxr-xr-x root/root 0 2018-08-19 11:07 ./etc/php/7.1/
  drwxr-xr-x root/root 0 2018-08-19 11:07 ./etc/php/7.1/mods-available/
  -rw-r--r-- root/root   176 2018-08-19 11:07 
./etc/php/7.1/mods-available/memcached.ini
  drwxr-xr-x root/root 0 2018-08-19 11:07 ./etc/php/7.2/
  drwxr-xr-x root/root 0 2018-08-19 11:07 ./etc/php/7.2/mods-available/
  -rw-r--r-- root/root   176 2018-08-19 11:07 
./etc/php/7.2/mods-available/memcached.ini
  drwxr-xr-x root/root 0 2018-08-19 11:07 ./etc/php/7.3/
  drwxr-xr-x root/root 0 2018-08-19 11:07 ./etc/php/7.3/mods-available/
  -rw-r--r-- root/root   176 2018-08-19 11:07 
./etc/php/7.3/mods-available/memcached.ini
  drwxr-xr-x root/root 0 2018-08-19 11:07 ./usr/
  drwxr-xr-x root/root 0 2018-08-19 11:07 ./usr/lib/
  drwxr-xr-x root/root 0 2018-08-19 11:07 ./usr/lib/php/
  drwxr-xr-x root/root 0 2018-08-19 11:07 ./usr/lib/php/20151012/
  -rw-r--r-- root/root114704 2018-08-19 11:07 
./usr/lib/php/20151012/memcached.so
  drwxr-xr-x root/root 0 2018-08-19 11:07 ./usr/lib/php/20160303/
  -rw-r--r-- root/root114704 2018-08-19 11:07 
./usr/lib/php/20160303/memcached.so
  drwxr-xr-x root/root 0 2018-08-19 11:07 ./usr/lib/php/20170718/
  -rw-r--r-- root/root114704 2018-08-19 11:07 
./usr/lib/php/20170718/memcached.so
  drwxr-xr-x root/root 0 2018-08-19 11:07 ./usr/lib/php/20180606/
  -rw-r--r-- root/root114704 2018-08-19 11:07 
./usr/lib/php/20180606/memcached.so
  drwxr-xr-x root/root 0 2018-08-19 11:07 ./usr/share/
  drwxr-xr-x root/root 0 2018-08-19 11:07 ./usr/share/doc/
  drwxr-xr-x root/root 0 2018-08-19 11:07 ./usr/share/doc/php-memcached/
  -rw-r--r-- root/root   362 2018-08-19 11:07 
./usr/share/doc/php-memcached/NEWS.Debian.gz
  -rw-r--r-- root/root  1875 2017-11-21 00:01 
./usr/share/doc/php-memcached/README.markdown
  -rw-r--r-- root/root  3075 2018-08-19 11:07 
./usr/share/doc/php-memcached/changelog.Debian.gz
  -rw-r--r-- root/root  3577 2018-08-19 11:07 
./usr/share/doc/php-memcached/copyright

Bug#909111: php-redis package is missing support for PHP 7.0, 7.1, and 7.3

[anomie]

Package: php-redis
Version: 4.1.1-1

For some reason the current version of the package only contains the
extension files for PHP 7.2, while Debian currently also has packages
php7.0, php7.1, and php7.3.

  $ dpkg -c php-redis_4.1.1-1_amd64.deb 
  drwxr-xr-x root/root 0 2018-08-19 09:14 ./
  drwxr-xr-x root/root 0 2018-08-19 09:14 ./etc/
  drwxr-xr-x root/root 0 2018-08-19 09:14 ./etc/php/
  drwxr-xr-x root/root 0 2018-08-19 09:14 ./etc/php/7.2/
  drwxr-xr-x root/root 0 2018-08-19 09:14 ./etc/php/7.2/mods-available/
  -rw-r--r-- root/root19 2018-08-19 09:14 
./etc/php/7.2/mods-available/redis.ini
  drwxr-xr-x root/root 0 2018-08-19 09:14 ./usr/
  drwxr-xr-x root/root 0 2018-08-19 09:14 ./usr/lib/
  drwxr-xr-x root/root 0 2018-08-19 09:14 ./usr/lib/php/
  drwxr-xr-x root/root 0 2018-08-19 09:14 ./usr/lib/php/20170718/
  -rw-r--r-- root/root490688 2018-08-19 09:14 
./usr/lib/php/20170718/redis.so
  drwxr-xr-x root/root 0 2018-08-19 09:14 ./usr/share/
  drwxr-xr-x root/root 0 2018-08-19 09:14 ./usr/share/doc/
  drwxr-xr-x root/root 0 2018-08-19 09:14 ./usr/share/doc/php-redis/
  -rw-r--r-- root/root  1729 2018-08-19 09:14 
./usr/share/doc/php-redis/changelog.Debian.gz
  -rw-r--r-- root/root  4707 2018-08-19 09:14 
./usr/share/doc/php-redis/copyright

Rebuilding php-redis using dpkg-builpackage (after rebuilding various of its
dependencies, which also seem to suffer from this bug) generates a version that
does have the necessary extension files.

  $ dpkg -c /usr/local/src/bugfix-debs/php-redis/php-redis_4.1.1-1_amd64.deb 
  drwxr-xr-x root/root 0 2018-08-19 09:14 ./
  drwxr-xr-x root/root 0 2018-08-19 09:14 ./etc/
  drwxr-xr-x root/root 0 2018-08-19 09:14 ./etc/php/
  drwxr-xr-x root/root 0 2018-08-19 09:14 ./etc/php/7.0/
  drwxr-xr-x root/root 0 2018-08-19 09:14 ./etc/php/7.0/mods-available/
  -rw-r--r-- root/root19 2018-08-19 09:14 
./etc/php/7.0/mods-available/redis.ini
  drwxr-xr-x root/root 0 2018-08-19 09:14 ./etc/php/7.1/
  drwxr-xr-x root/root 0 2018-08-19 09:14 ./etc/php/7.1/mods-available/
  -rw-r--r-- root/root19 2018-08-19 09:14 
./etc/php/7.1/mods-available/redis.ini
  drwxr-xr-x root/root 0 2018-08-19 09:14 ./etc/php/7.2/
  drwxr-xr-x root/root 0 2018-08-19 09:14 ./etc/php/7.2/mods-available/
  -rw-r--r-- root/root19 2018-08-19 09:14 
./etc/php/7.2/mods-available/redis.ini
  drwxr-xr-x root/root 0 2018-08-19 09:14 ./etc/php/7.3/
  drwxr-xr-x root/root 0 2018-08-19 09:14 ./etc/php/7.3/mods-available/
  -rw-r--r-- root/root19 2018-08-19 09:14 
./etc/php/7.3/mods-available/redis.ini
  drwxr-xr-x root/root 0 2018-08-19 09:14 ./usr/
  drwxr-xr-x root/root 0 2018-08-19 09:14 ./usr/lib/
  drwxr-xr-x root/root 0 2018-08-19 09:14 ./usr/lib/php/
  drwxr-xr-x root/root 0 2018-08-19 09:14 ./usr/lib/php/20151012/
  -rw-r--r-- root/root502976 2018-08-19 09:14 
./usr/lib/php/20151012/redis.so
  drwxr-xr-x root/root 0 2018-08-19 09:14 ./usr/lib/php/20160303/
  -rw-r--r-- root/root490688 2018-08-19 09:14 
./usr/lib/php/20160303/redis.so
  drwxr-xr-x root/root 0 2018-08-19 09:14 ./usr/lib/php/20170718/
  -rw-r--r-- root/root490688 2018-08-19 09:14 
./usr/lib/php/20170718/redis.so
  drwxr-xr-x root/root 0 2018-08-19 09:14 ./usr/lib/php/20180606/
  -rw-r--r-- root/root490688 2018-08-19 09:14 
./usr/lib/php/20180606/redis.so
  drwxr-xr-x root/root 0 2018-08-19 09:14 ./usr/share/
  drwxr-xr-x root/root 0 2018-08-19 09:14 ./usr/share/doc/
  drwxr-xr-x root/root 0 2018-08-19 09:14 ./usr/share/doc/php-redis/
  -rw-r--r-- root/root  1729 2018-08-19 09:14 
./usr/share/doc/php-redis/changelog.Debian.gz
  -rw-r--r-- root/root  4707 2018-08-19 09:14 
./usr/share/doc/php-redis/copyright

Bug#909110: Extraneous 'L' in /usr/bin/phpize7.3

[anomie]

Package: php7.3-dev
Version: 7.3.0~alpha3-1

There's an extraneous 'L' at the end of line 14 of /usr/bin/phpize7.3 which
causes it to fail to copy the files necessary for "make test".

  $ phpize7.3
  Configuring for:
  PHP Api Version: 20180606
  Zend Module Api No:  20180606
  Zend Extension Api No:   320180606
  cp: cannot stat 'run-tests*.phpL': No such file or directory

It works when the 'L' is removed.

Bug#901353: wmifs segfaults occasionally

[anomie]

Package: wmifs
Version: 1.8-1

I noticed that wmifs was randomly crashing on my laptop. I have no idea
how to reproduce it besides letting it run for a long time, it didn't
seem to be associated with hibernation or anything else obvious. If I
have multiple instances running, usually only one will crash while the
others continue without issue.

Running it under gdb with wmifs-dbgsym installed produced this trace:

  Program received signal SIGSEGV, Segmentation fault.
  _IO_fgets (buf=0x7fffd9d0 "\001", n=512, fp=0x0) at iofgets.c:47
  47iofgets.c: No such file or directory.
  (gdb) bt
  #0  _IO_fgets (buf=0x7fffd9d0 "\001", n=512, fp=0x0) at iofgets.c:47
  #1  0x6d1f in fgets (__stream=0x0, __n=512, __s=0x7fffd9d0 
"\001") at /usr/include/x86_64-linux-gnu/bits/stdio2.h:263
  #2  get_statistics (devname=, ip=0x7fffdc70, 
op=0x7fffdc78, is=0x7fffdc80, os=0x7fffdc88) at wmifs.c:767
  #3  0x73b9 in wmifs_routine (argc=, 
argv=) at wmifs.c:555
  #4  0x5dbe in main (argc=5, argv=0x7fffe198) at wmifs.c:367

Apparently the fopen() on wmifs.c line 766 can fail in some cases, and
that needs to be checked for to avoid passing a NULL file pointer to
fgets(). It could be as simple as inserting

if (!fp) {
return -1;
}

to match the minimal error handling on subsequent lines when an fgets() fails.

Bug#850660: nodejs-dev: npm conflicts transitively with libssl-dev since nodejs-dev 4.7.2~dfsg-1

[anomie]

It looks like this is fixed with nodejs version 8.9.3~dfsg-1.

  * Backport #16130: support both openssl 1.0.1 and 1.1.0
Add openssl/fixups.patch to take care of additional fixes.
  * Build against latest ssl-dev version

Only took a year...

Bug#879475: php-igbinary: Please recompile to support php7.1

[anomie]

Package: php-igbinary
Version: 2.0.1-1

The package does not contain the shared library compiled for php 7.1,
only for php 7.0. Simply recompiling it locally with dpkg-buildpackage
produces a package that contains the necessary shared library and other
infrastructure, and seems to function correctly.

Bug#879477: php-redis: Please recompile to support php7.1

[anomie]

Package: php-redis
Version: 3.1.2-1

The package does not contain the shared library compiled for php 7.1,
only for php 7.0. Simply recompiling it locally with dpkg-buildpackage
produces a package that contains the necessary shared library and other
infrastructure, and seems to function correctly.

Bug#879476: php-msgpack: Please recompile to support php7.1

[anomie]

Package: php-msgpack
Version: 2.0.2+0.5.7-1

The package does not contain the shared library compiled for php 7.1,
only for php 7.0. Simply recompiling it locally with dpkg-buildpackage
produces a package that contains the necessary shared library and other
infrastructure, and seems to function correctly.

Bug#872879: wmaker menu lost most of my apps

[anomie]

On Fri, Aug 25, 2017 at 06:03:20PM -0400, Doug Torrance wrote:
> Ok, great!  So it seems like the issue was that the WMRootMenu in your home
> directory was no longer pointing to the correct file.
> 
> Do you think the correct fix to this bug would be better documentation for
> the change?  Or something else?

Yeah, a notice in the NEWS file or something like that would probably be
a good idea.

I've been copying around the same wmaker config since 1999, so who knows
how that got added in the first place.

Bug#872879: wmaker menu lost most of my apps

[anomie]

On Tue, Aug 22, 2017 at 08:58:01AM -0400, Doug Torrance wrote:
> What are the contents of your ~/GNUstep/Defaults/WMRootMenu

One line:

/etc/GNUstep/Defaults/menu.hook

Removing ~/GNUstep/Defaults/WMRootMenu brings back some/most of the
applications, although all the submenus are somewhat annoyingly nested
under an "Applications" submenu.

Also, /etc/GNUstep/Defaults/menu.hook doesn't exist.

> and /etc/GNUstep/Defaults/WMRootMenu?

One line:

"menu.hook"

> Does the file /usr/share/WindowMaker/menu.hook exist? Is it a symbolic link
> to /etc/GNUstep/Defaults/plmenu.Debian?  (For some reason, they're not
> showing up in the filelist [1], even though they ought to...)

Yes, and yes.

Bug#872879: wmaker menu lost most of my apps

[anomie]

Package: wmaker
Version: 0.95.8-2

After upgrading from 0.95.8-1 to 0.95.8-2, the menu seems to have lost
the vast majority of my applications.

~/.xsession-errors tells me the following:

/usr/lib/WindowMaker/wmaker(configureMenu(rootmenu.c:1513)): warning: using 
default menu file "/usr/share/WindowMaker/menu" as the menu referenced in 
WMRootMenu could not be found 
/usr/lib/WindowMaker/wmaker(WMReadPropListFromFile(proplist.c:1548)): warning: 
syntax error in file /usr/share/WindowMaker/menu, line 1: extra data after end 
of property list

Not that /usr/share/WindowMaker/menu actually contains reference to the
missing applications anyway.

I suspect that whatever the "fix" was for bug 868431 somehow broke
things.

Bug#857050: firefox no longer plays sound without pulseaudio daemon

[anomie]

For the record, the upstream bug asking them to reverse this poor
decision is at https://bugzilla.mozilla.org/show_bug.cgi?id=1345661

Bug#854407: procps: kill -l doesn't work

[anomie]

Package: procps
Version: 2:3.3.12-3

POSIX specifies that "kill -l " should print the symbolic name
of the signal (without the SIG prefix). The binary supplied by procps
ignores the signum argument.

 $ /bin/kill -l 11
 HUP INT QUIT ILL TRAP ABRT BUS FPE KILL USR1 SEGV USR2 PIPE ALRM TERM STKFLT
 CHLD CONT STOP TSTP TTIN TTOU URG XCPU XFSZ VTALRM PROF WINCH POLL PWR SYS

I note this is even given as an example in the manpage.

It does work if there is no space in between the -l and the signal
number, however this is *not* what POSIX specifies.

 $ /bin/kill -l11
 SEGV

Bug#850660: nodejs-dev: npm conflicts transitively with libssl-dev since nodejs-dev 4.7.2~dfsg-1

[anomie]

I've been unable to upgrade nodejs and nodejs-dev thanks to this issue:
I need npm for some things, but also php7.0-dev (which depends on
libssl-dev) for something else.

Bug#842952: firefox: Things that are still bad with GTK+3 enabled

[anomie]

One thing that has really been bugging me is that the buttons in
webpages are crazily large, breaking the layout of sites that expect
buttons to have more normal dimensions. Selection lists, input fields,
checkboxes, and radio buttons are also enough larger to be annoying.

In 49.0-4:
button:31x18; padding: 0 6px; border-width: 2px
select:15x17; padding: 0; border-width: 2px 19px 2px 2px
input:180x16; padding: 1px;   border-width: 2px
checkbox:  13x13; padding: 0; border-width: 3px 3px 3px 4px
radio: 13x13; padding: 0; border-width: 3px 3px 0 5px
textarea: 156x44; padding: 0 1px; border-width: 2px

In 49.0-5:
button:31x18; padding: 0 6px; border-width: 4px 16px
select:15x17; padding: 0; border-width: 5px 24px 5px 9px
input:180x16; padding: 1px;   border-width: 0px 8px
checkbox:  16x16; padding: 0; border-width: 3px 3px 3px 4px
radio: 16x16; padding: 0; border-width: 3px 3px 0 5px
textarea: 156x44; padding: 0 1px; border-width: 1px

As far as I can tell it's using the default Adwaita:light theme. If this
won't be fixed or able to be disabled in Firefox, is there at least a
packaged theme available that I could specify with the GTK_THEME
environment variable to have normal-sized form widgets instead?

Also, in the browser itself, I find that the indicator for submenus
inside menus is sometimes (but not always) white-on-white so it's
invisible until the menu item is moused over. This happens with the
default browser theme.

Bug#826407: Missing dependency on php-igbinary

[anomie]

Package: php-redis
Version: 2.2.7-394-g892f928+2.2.7-3

After upgrading to the mentioned version of the package, I see the
following warning when running PHP.

 PHP Warning:  PHP Startup: Unable to load dynamic library
 '/usr/lib/php/20151012/redis.so' - /usr/lib/php/20151012/redis.so:
 undefined symbol: igbinary_serialize in Unknown on line 0

I see that the package has a Recommends for php-igbinary, but since it
seems to not function unless that package is installed you should
either upgrade that to a Depends or revert the change that makes it
required.

Bug#805519: wmifs: Buffer overflow on startup. Process crashes.

[anomie]

This recently started happening to me locally. In my case, at least, it
turns out to be due to wmifs blindly assuming all interface names are 8
bytes or shorter (including the trailing nul). Looks like IFNAMSIZ has
been 16 for some time now.
--- wmifs.c.orig2016-04-19 07:34:59.873085155 -0400
+++ wmifs.c 2016-04-19 07:33:11.634910715 -0400
@@ -247,6 +247,7 @@
 
 /* the size of the buffer read from /proc/net/ */
 #define BUFFER_SIZE 512
+
   /**/
  /* External Variables */
 /**/
@@ -317,7 +318,7 @@
switch (arg[1]) {
case 'c' :
if (argc > i+1) {
-   strcpy(color, argv[i+1]);
+   strncpy(color, argv[i+1], 
sizeof(color));
i++;
}
break;
@@ -392,7 +393,7 @@
 
 typedef struct {
 
-   charname[8];
+   charname[IFNAMSIZ];
int his[55][2];
longistatlast;
longostatlast;
@@ -478,7 +479,7 @@
fprintf(stderr, "Unknown $HOME directory, please check your 
environment\n");
return;
}
-   strcpy(temp, p);
+   strncpy(temp, p, BUFFER_SIZE - 10);
strcat(temp, "/.wmifsrc");
parse_rcfile(temp, wmifs_keys);
 
@@ -852,7 +853,7 @@
int i = 0, j;
int k;
int devsfound = 0;
-   charfoundbuffer[MAX_STAT_DEVICES][8];
+   charfoundbuffer[MAX_STAT_DEVICES][IFNAMSIZ];
 
for (i = 0; i < MAX_STAT_DEVICES; i++)
foundbuffer[i][0] = 0;
@@ -890,7 +891,7 @@
   skip it! */
 
if (strcmp(p, "lo") || (active_interface && 
!strcmp(active_interface, "lo"))) {
-   strcpy(foundbuffer[devsfound], p);
+   strncpy(foundbuffer[devsfound], p, IFNAMSIZ);
devsfound++;
}
if (devsfound >= MAX_STAT_DEVICES)
@@ -930,7 +931,7 @@
for (j = 0; j < MAX_STAT_DEVICES; j++) {
if (foundbuffer[j][0]) {
 
-   strcpy(stat_devices[i].name, foundbuffer[j]);
+   strncpy(stat_devices[i].name, foundbuffer[j], IFNAMSIZ);
 
for (k = 0; k < 48; k++) {
stat_devices[i].his[k][0] = 0;
@@ -948,7 +949,7 @@
break;
}
if (!k) {
-   strcpy(stat_devices[i].name, active_interface);
+   strncpy(stat_devices[i].name, active_interface, 
IFNAMSIZ);
for (k = 0; k < 48; k++) {
stat_devices[i].his[k][0] = 0;
stat_devices[i].his[k][1] = 0;

Bug#815794: [php-maint] Bug#815794: Broken symlink: /usr/lib/php5/build/ltmain.sh

[anomie]

On Wed, Feb 24, 2016 at 04:26:50PM +0100, Ondřej Surý wrote:
> On Wed, Feb 24, 2016, at 16:24, ano...@users.sourceforge.net wrote:
> > On Wed, Feb 24, 2016 at 03:52:42PM +0100, Ondřej Surý wrote:
> > > Yeah,
> > > 
> > > just use php-dev (that pulls php7.0-dev); src:php5 is going away from
> > > unstable and testing when we finish the transition to PHP 7.0.
> > 
> > I wonder how many of the incompatible changes in PHP 7 will require
> > working around in stuff that I use (and that needs to remain PHP-5
> > compatible) if PHP 5 is no longer available.
> 
> Not a question for this bugreport, but for a Google, right?

You're the one who brought up PHP5 going away in Debian soon. My
rhetorical question was intended as a polite way of complaining about
that statement by pointing out how it will likely be troublesome for me.

Bug#815794: [php-maint] Bug#815794: Broken symlink: /usr/lib/php5/build/ltmain.sh

[anomie]

On Wed, Feb 24, 2016 at 03:52:42PM +0100, Ondřej Surý wrote:
> Yeah,
> 
> just use php-dev (that pulls php7.0-dev); src:php5 is going away from
> unstable and testing when we finish the transition to PHP 7.0.

I wonder how many of the incompatible changes in PHP 7 will require
working around in stuff that I use (and that needs to remain PHP-5
compatible) if PHP 5 is no longer available.

Bug#815794: Broken symlink: /usr/lib/php5/build/ltmain.sh

[anomie]

Package: php5-dev
Version: 5.6.17+dfsg-3

The file /usr/lib/php5/build/ltmain.sh is symlinked to
../../../share/libtool/config/ltmain.sh, which does not exist in the
libtool package as of version 2.4.6-0.1 (it was present in 2.4.2-1.11).
The new path seems to be /usr/share/libtool/build-aux/ltmain.sh.

Bug#777140: Using mdadm to install Debian on Intel RST RAID array stopped working between Wheezy 7.8 and Jessie RC1

[anomie]

I ran into this problem recently on an ASUS UX301L. Worse, I ran into it
after *upgrading* to Jessie, the system wouldn't even boot anymore
because it couldn't assemble the root device.

After narrowing it down to mdadm and IMSM, I came across this
workaround:
https://bbs.archlinux.org/viewtopic.php?pid=1565988#p1565988

Executing "IMSM_NO_PLATFORM=1 mdadm --assemble --scan" at the initrd
shell finally allowed me to successfully boot.

Bug#800445: nf_conntrack: table full, dropping packet

[anomie]

On Sat, Oct 03, 2015 at 02:33:22AM +0100, Ben Hutchings wrote:
> 
> I think I found the fix for this, but please can you test the attached
> patch?  (Instructions for building a patched kernel package are at 
> .)

Sorry for the delay in testing. The attached patch does seem to work.

Thanks!

Bug#800445: nf_conntrack: table full, dropping packet

[anomie]

Package: linux-image-4.2.0-1-amd64
Version: 4.2.1-2

After booting the kernel image provided by this package and attempting
to connect to the Internet, network access doesn't actually work. The
message "nf_conntrack: table full, dropping packet" is repeatedly
logged.

Comparing the contents of the various /proc/sys conntrack files between
a working 4.1 kernel (from linux-image-4.1.0-2-amd64) and the broken
4.2, the only difference I see is that nf_conntrack_count has a value
"-5". Yes, negative 5. /proc/net/stat/nf_conntrack's "entries" column
matches this with a value of fffb. /proc/net/nf_conntrack is empty
on the 4.2 kernel, while it has a handful of expected entries on 4.1.

I have iptables rules set up by shorewall on this machine, including
configuration to forward/masq traffic on the interface used by vde2, in
case that helps reproduce this. Removing all the iptables rules and
removing the nf_conntrack_ipv4 module (and everything that depends on
it, of course) stops the error. Disabling shorewall at boot allows
network functionality and starting shorewall later didn't immediately
cause the problem, but in some experimentation after the system locked
up.

Bug#755726: alsa-utils: arecord doesn't exit when -d is specified

[anomie]

What seems to be going on here is that the loop in capture() is
expecting pcm_read() to return the passed-in count, while pcm_read() is
insisting that the count be equal to the chunk size. Thus the last read
for the timelimit is considered to have failed, and it then gets stuck
in a loop creating more-and-more numbered files.

The attached patch seems to fix things, although I don't know if it's
optimal or if this bug exists elsewhere in the code too.
--- aplay/aplay.c.orig  2015-03-31 10:12:12.267580577 -0400
+++ aplay/aplay.c   2015-03-31 10:12:14.319613606 -0400
@@ -2998,7 +2998,7 @@
size_t c = (rest <= (off64_t)chunk_bytes) ?
(size_t)rest : chunk_bytes;
size_t f = c * 8 / bits_per_frame;
-   if (pcm_read(audiobuf, f) != f)
+   if (pcm_read(audiobuf, f) < f)
break;
if (write(fd, audiobuf, c) != c) {
perror(name);

Bug#561281: util-linux hwclock problems with rtc not in utc, resolved?

[anomie]

Wow, old bug.

I don't have my system clock set to local time anymore, so I'm not able
to test this. Sorry.


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

Bug#741532: fonts-linuxlibertine: Odd font priority for "Linux Libertine,Times"

[anomie]

Package: fonts-linuxlibertine
Version: 5.3.0-2

Expected result:

 $ fc-match 'Linux Libertine O,Times'
 LinLibertine_R.otf: "Linux Libertine O" "Regular"
 $ fc-match 'Linux Libertine,Times'
 LinLibertine_R.otf: "Linux Libertine O" "Regular"
 
Actual result:

 $ fc-match 'Linux Libertine O,Times'
 LinLibertine_R.otf: "Linux Libertine O" "Regular"
 $ fc-match 'Linux Libertine,Times'
 texgyretermes-regular.otf: "TeX Gyre Termes" "Regular"

Details:

In the file /etc/fonts/conf.avail/30-fonts-texgyre-aliases.conf
installed by fonts-texgyre, I see the following:


  Times
  TeX Gyre Termes


Also in /usr/share/fontconfig/conf.avail/30-metric-aliases.conf
installed by fontconfig-config, I see:


  Times
  
  TeX Gyre Termes
  Nimbus Roman No9 L
  


In /etc/fonts/conf.avail/90-fonts-linux-libertine.conf, I see:


Linux Libertine
Linux Libertine O


If I change  to  in the latter, I get the
expected result from fc-match 'Linux Libertine,Times'.


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

Bug#628654: xbindkeys: New release blocks seahorse

[anomie]

This should have been in the NEWS.Debian file, so apt-listchanges would
have flagged it on upgrade. I rebooted my laptop this morning and had to
track down why xbindkeys suddenly wasn't running.


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

Bug#737247: gparted resizes partition to smaller than the filesystem

[anomie]

On Wed, Feb 05, 2014 at 01:14:23PM -0500, Phillip Susi wrote:
> The end sector also is not aligned to a 1 MiB boundary.

The explanation for that seems simple enough: this drive itself is not a
multiple of 1 MiB in size, the partition was using the whole drive, and
I never told gparted to change the end position of the partition.

If gparted had insisted on ignoring the last 89600 bytes of the drive,
I'd probably have changed to "None" alignment (if I noticed).


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

Bug#720434: Bug #720434: php5-cli installs incorrect /etc/php5/cli/php.ini

[anomie]

found 720434 5.5.8+dfsg-3
thanks

Does no one care about fixing this bug? It seems simple enough, just use
the right config file.


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

Bug#571438: Does not set up root device on boot

[anomie]

Looking into this bug again, it seems that it's the same problem as
https://bugzilla.redhat.com/show_bug.cgi?id=1011704. udev apparently
needs OPTIONS+="db_persist" set at some point in the initrd or it throws
away the necessary information.

I've made this change locally (adding the attached file to
/etc/udev/rules.d/69-local-dm-persist.rules, plus a hook to
/etc/initramfs-tools/hooks/ so it gets copied to the initrd) and my root
device has the correct properties now.
# Apparently this is needed or udev breaks the initfs

SUBSYSTEM!="block", GOTO="dm_end"
KERNEL!="dm-[0-9]*", GOTO="dm_end"
ACTION!="add|change", GOTO="dm_end"

OPTIONS+="db_persist"

LABEL="dm_end"

Bug#737694: Should support "Interface name"

[anomie]

Package: network-manager-vpnc
Version: 0.9.8.6-1

For firewall rules, it would be nice if the VPN interface could be
configured to have a predictable name instead of generic "tun0".

It turns out vpnc already supports this, we just need to expose the
option in NetworkManager.
diff -urN a/properties/nm-vpnc.c b/properties/nm-vpnc.c
--- a/properties/nm-vpnc.c  2013-09-13 12:01:23.0 -0400
+++ b/properties/nm-vpnc.c  2014-02-04 18:21:47.714491746 -0500
@@ -702,6 +702,16 @@
}
g_signal_connect (G_OBJECT (widget), "changed", G_CALLBACK 
(spinbutton_changed_cb), self);
 
+   widget = GTK_WIDGET (gtk_builder_get_object (priv->builder, 
"interface_name_entry"));
+   g_return_val_if_fail (widget != NULL, FALSE);
+   gtk_size_group_add_widget (priv->group, GTK_WIDGET (widget));
+   if (s_vpn) {
+   value = nm_setting_vpn_get_data_item (s_vpn, 
NM_VPNC_KEY_INTERFACE_NAME);
+   if (value && strlen (value))
+   gtk_entry_set_text (GTK_ENTRY (widget), value);
+   }
+   g_signal_connect (G_OBJECT (widget), "changed", G_CALLBACK 
(stuff_changed_cb), self);
+
widget = GTK_WIDGET (gtk_builder_get_object (priv->builder, 
"disable_dpd_checkbutton"));
g_return_val_if_fail (widget != NULL, FALSE);
if (s_vpn) {
@@ -992,6 +1002,11 @@
port = gtk_spin_button_get_value_as_int (GTK_SPIN_BUTTON (widget));
nm_setting_vpn_add_data_item (s_vpn, NM_VPNC_KEY_LOCAL_PORT, 
g_strdup_printf ("%d", port));
 
+   widget = GTK_WIDGET (gtk_builder_get_object (priv->builder, 
"interface_name_entry"));
+   str = (char *) gtk_entry_get_text (GTK_ENTRY (widget));
+   if (str && strlen (str))
+   nm_setting_vpn_add_data_item (s_vpn, 
NM_VPNC_KEY_INTERFACE_NAME, str);
+
widget = GTK_WIDGET (gtk_builder_get_object (priv->builder, 
"disable_dpd_checkbutton"));
if (gtk_toggle_button_get_active (GTK_TOGGLE_BUTTON (widget))) {
nm_setting_vpn_add_data_item (s_vpn, 
NM_VPNC_KEY_DPD_IDLE_TIMEOUT, "0");
@@ -1540,6 +1555,12 @@
g_free (tmp);
}
 
+   buf = key_file_get_string_helper (keyfile, "main", "InterfaceName", 
NULL);
+   if (buf) {
+   nm_setting_vpn_add_data_item (s_vpn, 
NM_VPNC_KEY_INTERFACE_NAME, buf);
+   g_free (buf);
+   }
+
g_key_file_free (keyfile);
return connection;
 
@@ -1572,6 +1593,7 @@
const char *group_pw = NULL;
GString *routes = NULL;
GString *uselegacyikeport = NULL;
+   const char *interfacename = NULL;
gboolean success = FALSE;
guint32 routes_count = 0;
gboolean save_password = FALSE;
@@ -1697,6 +1719,10 @@
if (!value || !strcmp (value, "0"))
g_string_assign (uselegacyikeport, "UseLegacyIKEPort=0\n");
 
+   value = nm_setting_vpn_get_data_item (s_vpn, 
NM_VPNC_KEY_INTERFACE_NAME);
+   if (value && strlen (value))
+   interfacename = value;
+
fprintf (f, 
 "[main]\n"
 "Description=%s\n"
@@ -1736,6 +1762,7 @@
 "SingleDES=%s\n"
 "SPPhonebook=\n"
 "%s"
+ "InterfaceName=%s\n"
 "X-NM-Use-NAT-T=%s\n"
 "X-NM-Force-NAT-T=%s\n"
 "X-NM-SaveGroupPassword=%s\n"
@@ -1752,6 +1779,7 @@
 /* PeerTimeout */   peertimeout != NULL ? peertimeout : "0",
 /* SingleDES */ singledes ? "1" : "0",
 /* UseLegacyIKEPort */ (uselegacyikeport->len) ? 
uselegacyikeport->str : "",
+/* InterfaceName */ interfacename != NULL ? interfacename : "",
 /* X-NM-Use-NAT-T */ use_natt ? "1" : "0",
 /* X-NM-Force-NAT-T */ use_force_natt ? "1" : "0",
 /* X-NM-SaveGroupPassword */ save_group_password ? "1" : "0",
diff -urN a/properties/nm-vpnc-dialog.ui b/properties/nm-vpnc-dialog.ui
--- a/properties/nm-vpnc-dialog.ui  2013-02-18 18:08:36.0 -0500
+++ b/properties/nm-vpnc-dialog.ui  2014-02-04 18:16:39.050497185 -0500
@@ -477,6 +477,36 @@
   
 
 
+  
+True
+False
+0
+Interface 
name:
+True
+interface_name_entry
+  
+  
+5
+6
+  
+
+
+  
+True
+True
+•
+True
+Visible name of the TUN/TAP interface
+config: Interface name 
+  
+  
+1
+2
+ 

Bug#737247: gparted resizes partition to smaller than the filesystem

[anomie]

On Mon, Feb 03, 2014 at 07:45:39PM +, Mike Fleetwood wrote:
> 
> Can you confirm the version of Debian you are using as my attempt to
> re-create the bug on my normal distribution didn't find an issue.

I'm using unstable. gparted version 0.17.0-4.

On Mon, Feb 03, 2014 at 02:02:34PM -0700, Curtis Gedak wrote:
> 
> Which alignment option did you choose?
>   (MiB, Cylinder, or None.  Default is MiB)

I left it at the default.

> Would you be able to provide the output from the following two commands?
> 
>   sudo fdisk -l -u

Note I've finished repartitioning the drive since this bug report.[1]

Disk /dev/sdc: 2000.4 GB, 2000398933504 bytes
81 heads, 62 sectors/track, 777982 cylinders, total 3907029167 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00023c76

   Device Boot  Start End  Blocks   Id  System
/dev/sdc12048  3907029166  1953513559+  83  Linux

>   sudo parted /path-to-your-device unit s print

Model: Seagate GoFlex Desk (scsi)
Disk /dev/sdc: 3907029167s
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start  End  Size Type File system  Flags
 1  2048s  3907029166s  3907027119s  primary


On Mon, Feb 03, 2014 at 07:45:39PM +, Mike Fleetwood wrote:
>   https://bugzilla.gnome.org/show_bug.cgi?id=723543#c2

Based on that, I managed to recreate the issue as follows:

$ truncate -s 2000398933504 /tmp/loop0.img
$ sudo losetup -f --show /tmp/loop0.img
/dev/loop0
$ echo -e "o\nn\np\n\n\n\nw\nq\n" | sudo fdisk /dev/loop0
[...]
$ sudo partprobe -s /dev/loop0
/dev/loop0: msdos partitions 1
$ sudo fdisk -l /dev/loop0

Disk /dev/loop0: 2000.4 GB, 2000398933504 bytes
81 heads, 62 sectors/track, 777982 cylinders, total 3907029167 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xcf75b6a0

  Device Boot  Start End  Blocks   Id  System
/dev/loop0p12048  3907029166  1953513559+  83  Linux
$ sudo mkfs.ext4 -q /dev/loop0p1 
$ sudo gparted /dev/loop0

* Select the partition
* Click "Resize/Move"
* Drag the left end of the slider to the right. This time it says free
  space preceeding is 1556706, size is 351022, free space following is
  0, align is MiB.
* Hit "Ok" and confirm. Then apply.
* The output is roughly the same as in the original attachment: the
  resize2fs step reports the new filesystem is 89861654 blocks, the
  partition shrink takes it down to 718893231 sectors, then the e2fsck
  complains that the filesystem is 89861654 blocks while the device is
  only 89861653.

Then I removed the loop device, deleted /tmp/loop0.img, and redid the
above except I typed "160" in the free space before box instead of
using the slider. e2fsck again failed saying the filesystem was 78778390
blocks while the partition was 78778389. And I did it again a few more
times, same sort of results each time.


 [1]: The plan was to shrink the existing filesystem, move it to the end
  of the disk, create a new dm-crypt partition taking up most of the
  disk, copy everything from the old to the new, delete the old,
  expand the new to use the whole disk again, and then at some point
  run zerofree or the like over it. gparted was supposed to make it
  so I didn't have to worry about matching filesystem blocks and
  disk sectors when shrinking and moving...


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

Bug#737247: gparted resizes partition to smaller than the filesystem

[anomie]

Package: gparted
Version: 0.17.0-4

I tried to shrink-and-move a partition on an external hard drive. It
seems that gparted shrunk the parition to 93768726 4K blocks, but then
resized the parition to only 750149807 512-byte sectors (93768725.875 4K
blocks). The post-shrink e2fsck then errored out before the partition
could be moved.

gparted log attached.
Title: GParted Details




GParted 0.17.0 --enable-libparted-dmraid --enable-online-resize
Libparted 2.3



Move /dev/sdb1 to the right and shrink it from 1.82 TiB to 357.70 GiB  00:34:04( ERROR )








calibrate /dev/sdb1  00:00:00( SUCCESS )








path: /dev/sdb1start: 2048end: 3907029166size: 3907027119 (1.82 TiB)









check file system on /dev/sdb1 for errors and (if possible) fix them  00:12:59( SUCCESS )








e2fsck -f -y -v -C 0 /dev/sdb1








Pass 1: Checking inodes, blocks, and sizesPass 2: Checking directory structure   Pass 3: Checking directory connectivityPass 4: Checking reference counts  Pass 5: Checking group summary information  720259 inodes used (0.59%, out of 122101760)1666 non-contiguous files (0.2%) 256 non-contiguous directories (0.0%) # of inodes with ind/dind/tind blocks: 54238/1153/481366570 blocks used (16.66%, out of 488378389)   0 bad blocks  51 large files  576227 regular files  134638 directories1120 character device files 740 block device files  24 fifos   0 links7472 symbolic links (6954 fast symbolic links)  29 sockets  720250 files






e2fsck 1.42.9 (28-Dec-2013)












shrink file system  00:21:05( SUCCESS )








resize2fs -p /dev/sdb1 375074904K








Resizing the filesystem on /dev/sdb1 to 93768726 (4k) blocks.Begin pass 2 (max = 2011620)Relocating blocks Begin pass 3 (max = 14905)Scanning inode table  Begin pass 4 (max = 135768)Updating inode references The filesystem on /dev/sdb1 is now 93768726 blocks long.






resize2fs 1.42.9 (28-Dec-2013)












shrink partition from 1.82 TiB to 357.70 GiB  00:00:00( SUCCESS )








old start: 2048old end: 3907029166old size: 3907027119 (1.82 TiB)






new start: 2048new end: 750151854new size: 750149807 (357.70 GiB)









check file system on /dev/sdb1 for errors and (if possible) fix them  00:00:00( ERROR )








e2fsck -f -y -v -C 0 /dev/sdb1








The filesystem size (according to the superblock) is 93768726 blocksThe physical size of the device is 93768725 blocksEither the superblock or the partition table is likely to be corrupt!Abort? yes






e2fsck 1.42.9 (28-Dec-2013)

Bug#736965: Network detection fails in 2014-01-28 daily installer

[anomie]

Package: installation-reports

Preparing to install Debian on my new T430, which has an e1000e on eth0
and an Intel Centrino Advanced-N 6205 (supported with iwlwifi and
non-free firmware) as wlan0.

I formatted a USB stick, copied the contents of boot.img.gz,[1] copied
the netinst ISO,[2] and untarred the firmware tarball.[3]. I then booted
from the USB stick, and proceeded through the advanced installer to the
"automatically set up networking" step.

At this point, things went wrong: it decided, despite no cable being
plugged in, that it sensed a link on eth0 and tried to configure
networking. I then tried going into a shell, modprobe -r e1000e, and
then removing e1000e.ko. Now the "detect network hardware" step failed
to detect any network device; the wifi card was apparently not seen.

Then I downloaded the Wheezy 7.3.0 versions of boot.img.gz, the netinst
ISO, and the firmware tarball, and put them on the USB stick. This
detected the wifi card correctly and asked which I wanted to use to set
up networking. At this point I aborted the install, because I had yet to
install my new SSD.


 [1]: http://d-i.debian.org/daily-images/amd64/daily/hd-media/boot.img.gz
 [2]: 
http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd/debian-testing-amd64-netinst.iso
 [3]: http://cdimage.debian.org/cdimage/unofficial/non-free/firmware/


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

Bug#720434: php5-cli installs incorrect /etc/php5/cli/php.ini

[anomie]

Package: php5-cli
Version: 5.5.2+dfsg-1

When attempting to run a command-line PHP program that has run in the
past, I received errors that pcntl_signal was disabled. It appears that
sometime recently php5-cli started copying its php.ini from
/usr/share/php5/php.ini-production instead of
/usr/share/php5/php.ini-production.cli, so it's picking up the rules
that disable the pcntl functions for the webserver.

This bug is also present in 5.5.1+dfsg-2, and seems to not be present in
5.4.4-14+deb7u3; I haven't checked other versions.


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

Bug#720433: libapache2-mod-php5: Segmentation fault in 5.5.2+dfsg-1

[anomie]

Package: libapache2-mod-php5
Version: 5.5.2+dfsg-1
Severity: important

After upgrading php and apache this afternoon, I receive many segfaults
from my local MediaWiki installation. Downgrading libapache2-mod-php5
and the various php5-* packages to 5.5.1+dfsg-2 fixes the problem.

Backtrace:

(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
_get_zval_ptr_ptr_var (should_free=, 
execute_data=0x7faba65d4990, var=) at 
/tmp/buildd/php5-5.5.2+dfsg/Zend/zend_execute.c:384
384 /tmp/buildd/php5-5.5.2+dfsg/Zend/zend_execute.c: No such file or 
directory.
(gdb) bt
#0  _get_zval_ptr_ptr_var (should_free=, 
execute_data=0x7faba65d4990, var=) at 
/tmp/buildd/php5-5.5.2+dfsg/Zend/zend_execute.c:384
#1  ZEND_FETCH_DIM_R_SPEC_VAR_CONST_HANDLER (execute_data=0x7faba65d4990) at 
/tmp/buildd/php5-5.5.2+dfsg/Zend/zend_vm_execute.h:14783
#2  0x7faba3a3e578 in execute_ex (execute_data=0x7faba65d4990) at 
/tmp/buildd/php5-5.5.2+dfsg/Zend/zend_vm_execute.h:356
#3  0x7faba3a163b0 in zend_execute_scripts (type=type@entry=8, 
retval=retval@entry=0x0, file_count=file_count@entry=3) at 
/tmp/buildd/php5-5.5.2+dfsg/Zend/zend.c:1316
#4  0x7faba39b67f5 in php_execute_script 
(primary_file=primary_file@entry=0x7fff6285dff0) at 
/tmp/buildd/php5-5.5.2+dfsg/main/main.c:2484
#5  0x7faba3ac651a in php_handler (r=) at 
/tmp/buildd/php5-5.5.2+dfsg/sapi/apache2handler/sapi_apache2.c:667
#6  0x7faba6700350 in ap_run_handler (r=0x7faba64b40a0) at config.c:175
#7  0x7faba67008a9 in ap_invoke_handler (r=r@entry=0x7faba64b40a0) at 
config.c:445
#8  0x7faba67156fa in ap_process_async_request (r=0x7faba64b40a0) at 
http_request.c:317
#9  0x7faba67159e4 in ap_process_request (r=r@entry=0x7faba64b40a0) at 
http_request.c:363
#10 0x7faba6712492 in ap_process_http_sync_connection (c=0x7faba64b8290) at 
http_core.c:190
#11 ap_process_http_connection (c=0x7faba64b8290) at http_core.c:231
#12 0x7faba6709420 in ap_run_process_connection (c=0x7faba64b8290) at 
connection.c:41
#13 0x7faba6709808 in ap_process_connection (c=c@entry=0x7faba64b8290, 
csd=) at connection.c:202
#14 0x7faba419e767 in child_main (child_num_arg=child_num_arg@entry=0) at 
prefork.c:704
#15 0x7faba419e9a6 in make_child (s=0x7faba666be30, slot=slot@entry=0) at 
prefork.c:800
#16 0x7faba419ea06 in startup_children (number_to_start=5) at prefork.c:818
#17 0x7faba419f6f0 in prefork_run (_pconf=, 
plog=0x7faba6665028, s=0x7faba666be30) at prefork.c:976
#18 0x7faba66e75ee in ap_run_mpm (pconf=0x7faba669f028, 
plog=0x7faba6665028, s=0x7faba666be30) at mpm_common.c:96
#19 0x7faba66e0df6 in main (argc=3, argv=0x7fff6285e718) at main.c:777
(gdb)

-- Package-specific info:
 Additional PHP 5 information 

 PHP 5 SAPI (php5query -S): 
cli
apache2

 PHP 5 Extensions (php5query -M -v): 
pdo_mysql (Enabled for cli by maintainer script)
pdo_mysql (Enabled for apache2 by maintainer script)
pdo (Enabled for cli by maintainer script)
pdo (Enabled for apache2 by maintainer script)
intl (Enabled for cli by maintainer script)
intl (Enabled for apache2 by maintainer script)
pdo_pgsql (Enabled for cli by maintainer script)
pdo_pgsql (Enabled for apache2 by maintainer script)
mysql (Enabled for cli by maintainer script)
mysql (Enabled for apache2 by maintainer script)
readline (Enabled for cli by local administrator)
readline (Enabled for apache2 by local administrator)
curl (Enabled for cli by maintainer script)
curl (Enabled for apache2 by maintainer script)
mcrypt (Enabled for cli by maintainer script)
mcrypt (Enabled for apache2 by maintainer script)
opcache (Enabled for cli by maintainer script)
opcache (Enabled for apache2 by maintainer script)
gd (Enabled for cli by maintainer script)
gd (Enabled for apache2 by maintainer script)
pgsql (Enabled for cli by maintainer script)
pgsql (Enabled for apache2 by maintainer script)
json (Enabled for cli by local administrator)
json (Enabled for apache2 by local administrator)
mysqli (Enabled for cli by maintainer script)
mysqli (Enabled for apache2 by maintainer script)

 Configuration files: 
[PHP]
engine = On
short_open_tag = Off
asp_tags = Off
precision = 14
output_buffering = 4096
zlib.output_compression = Off
implicit_flush = Off
unserialize_callback_func =
serialize_precision = 17
disable_functions = 
pcntl_alarm,pcntl_fork,pcntl_waitpid,pcntl_wait,pcntl_wifexited,pcntl_wifstopped,pcntl_wifsignaled,pcntl_wexitstatus,pcntl_wtermsig,pcntl_wstopsig,pcntl_signal,pcntl_signal_dispatch,pcntl_get_last_error,pcntl_strerror,pcntl_sigprocmask,pcntl_sigwaitinfo,pcntl_sigtimedwait,pcntl_exec,pcntl_getpriority,pcntl_setpriority,
disable_classes =
zend.enable_gc = On
expose_php = On
max_execution_time = 30
max_input_time = 60
memory_limit = 128M
error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT
display_errors = Off
display_startup_errors = Off
log_errors = On
log_errors_max_len = 1024
ignore_repeated_errors = Off
ignore_repeated_source = Off
rep

Bug#711689: No longer ignores '.dpkg-dist' files in /etc/laptop-mode/conf.d/

[anomie]

Package: laptop-mode-tools
Version: 1.63-2

I noticed today that my console bell wasn't working, despite the volume
being set appropriately. Having seen this issue before, I quickly found
that /sys/module/snd_hda_intel/parameters/power_save was being set to "2"
instead of "0" whenever I unplugged the AC. (On my laptop, powersave
mode causes the console bell and headphone/mic input events to fail, and
has since at least Linux 2.6.32.3)

Further investigation turned up laptop-mode-tools as the culprit,
despite that I've had CONTROL_INTEL_HDA_POWER=0 in
/etc/laptop-mode/conf.d/intel-hda-powersave.conf for over three years
now. Removing /etc/laptop-mode/conf.d/intel-hda-powersave.conf.dpkg-dist
made it start working correctly again. Comparing /usr/sbin/laptop_mode
from 1.61-2 and 1.63-2, I see it now reads all files where before it
only read *.conf, explaining the regression.


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

Bug#669883: notification-daemon crashes in gdk_pixbuf_scale_simple

[anomie]

Ok, I think I have this worked out. GTK is throwing a critical warning,
and since notification-daemon calls
g_log_set_always_fatal (G_LOG_LEVEL_ERROR | G_LOG_LEVEL_CRITICAL) it
results in SIGTRAP where most GTK-using programs will just output a
message to stderr.

The problem seems to be that GtkStatusIcon defaults to a size of 4
somewhere, and then rounds this down to 0, and so tries to make a
zero-sized icon. If the critical warning doesn't terminate the program,
GtkStatusIcon will later on get a larger size and create an
appropriately-sized icon. As far as I can tell, older versions of GTK
didn't do this because they used a minimum size of GTK_ICON_SIZE_MENU
rather than 0 for GtkStatusIcons. I think this changed in
http://git.gnome.org/browse/gtk+/commit/gtk/gtkstatusicon.c?id=2e01dc1b7a134a6482f39ae7b3b6c840442c93db
in the block @@ -1364,9 +1327,9 @@.

This bug should probably be reassigned to gtk+3.0, since it has little
to do with notification-daemon. I've attached a small test program to
illustrate the problem. As a workaround, the g_log_set_always_fatal call
could be commented out in daemon.c.
/* Compile with:
   gcc -g -Wall bug.c `pkg-config --cflags --libs gtk+-3.0` -o bug
*/

#include 

int main(int argc, char *argv[]) {
GtkStatusIcon *statusicon;
GIcon *icon;
	
	// Remove this line to make it not crash on the critical error.
g_log_set_always_fatal (G_LOG_LEVEL_ERROR | G_LOG_LEVEL_CRITICAL);

	gtk_init(&argc, &argv);
statusicon = gtk_status_icon_new();
gtk_status_icon_set_visible(statusicon, TRUE);
icon = g_themed_icon_new("help");
gtk_status_icon_set_from_gicon(statusicon, icon);

gtk_main();

return 0;
}

Bug#669883: notification-daemon crashes in gdk_pixbuf_scale_simple

[anomie]

Same problem here, although I'm not sure what "switching to the default
Gnome theme" would entail. I note that downgrading libgtk-3-0 and
libgtk-3-common to 3.2.3-1 makes the problem go away.



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

Bug#615020: xdm: ConsoleKit support

[anomie]

It's sad that upstream doesn't seem to care about this bug.

I refreshed the patch against 1.1.11. Nothing has changed in the patch
itself, just the diff metadata and contexts so it will actually apply.
diff -bBurN a/debian/control b/debian/control
--- a/debian/control	2011-10-23 08:30:39.0 -0400
+++ b/debian/control	2011-10-23 08:29:05.902560613 -0400
@@ -15,6 +15,7 @@
  libselinux1-dev [linux-any],
  libxinerama-dev (>= 1:1.0.1),
  libxft-dev,
+ libck-connector-dev,
  quilt,
  automake,
  libtool,
diff -bBurN a/debian/patches/consolekit.diff b/debian/patches/consolekit.diff
--- a/debian/patches/consolekit.diff	1969-12-31 19:00:00.0 -0500
+++ b/debian/patches/consolekit.diff	2011-10-23 08:38:44.02107 -0400
@@ -0,0 +1,231 @@
+Description: Implement ConsoleKit support
+ Starting from 0.4.2, ConsoleKit has more strict securty requirements
+ and ck-launch-session doesn't create a local and active session
+ anymore.
+Forwarded: http://lists.x.org/archives/xorg-devel/2011-February/019615.html
+Origin: https://build.opensuse.org/package/view_file?file=xdm-consolekit.diff&package=xorg-x11&project=openSUSE:11.3:Update:Test&srcmd5=5e43d91b0bf84c8a82fc23b1cb550931
+--- a/configure.ac
 b/configure.ac
+@@ -430,6 +430,20 @@
+ AC_SUBST(XDMSHELL_CFLAGS)
+ AC_SUBST(XDMSHELL_LIBS)
+ 
++# ConsoleKit support
++AC_ARG_WITH(consolekit, AC_HELP_STRING([--with-consolekit], [Use ConsoleKit]),
++	[USE_CONSOLEKIT=$withval], [USE_CONSOLEKIT=yes])
++if test x"$USE_CONSOLEKIT" != xno; then
++	PKG_CHECK_MODULES(CK_CONNECTOR, ck-connector,
++		[USE_CONSOLEKIT=yes], [USE_CONSOLEKIT=no])
++	if test x"$USE_CONSOLEKIT" = xyes; then
++		AC_DEFINE([USE_CONSOLEKIT], 1, [Define to 1 to use ConsoleKit])
++		XDM_CFLAGS="$XDM_CFLAGS $CK_CONNECTOR_CFLAGS"
++		XDM_LIBS="$XDM_LIBS $CK_CONNECTOR_LIBS"
++	fi
++fi
++dnl AM_CONDITIONAL(USE_CONSOLEKIT, test$USE_CONSOLEKIT = xyes)
++
+ #
+ # Chooser
+ #
+--- a/include/dm.h
 b/include/dm.h
+@@ -325,6 +325,9 @@
+ extern char	*prngdSocket;
+ extern int	prngdPort;
+ # endif
++#ifdef USE_CONSOLEKIT
++extern int	use_consolekit;
++#endif
+ 
+ extern char	*greeterLib;
+ extern char	*willing;
+--- a/xdm/resource.c
 b/xdm/resource.c
+@@ -65,6 +65,9 @@
+ char	*prngdSocket;
+ int	prngdPort;
+ #endif
++#ifdef USE_CONSOLEKIT
++int	use_consolekit;
++#endif
+ 
+ char	*greeterLib;
+ char	*willing;
+@@ -196,6 +199,10 @@
+ "false"} ,
+ { "willing",	"Willing",	DM_STRING,	&willing,
+ ""} ,
++#ifdef USE_CONSOLEKIT
++{ "consoleKit",	"ConsoleKit",	DM_BOOL,	(char **) &use_consolekit,
++"true"} ,
++#endif
+ };
+ 
+ #define NUM_DM_RESOURCES	(sizeof DmResources / sizeof DmResources[0])
+@@ -380,7 +387,11 @@
+ {"-debug",	"*debugLevel",		XrmoptionSepArg,	(caddr_t) NULL },
+ {"-xrm",	NULL,			XrmoptionResArg,	(caddr_t) NULL },
+ {"-daemon",	".daemonMode",		XrmoptionNoArg,		"true" },
+-{"-nodaemon",	".daemonMode",		XrmoptionNoArg,		"false"}
++{"-nodaemon",	".daemonMode",		XrmoptionNoArg,		"false"},
++#ifdef USE_CONSOLEKIT
++{"-consolekit",	".consoleKit",		XrmoptionNoArg,		"true"  },
++{"-noconsolekit", ".consoleKit",	XrmoptionNoArg,		"false" }
++#endif
+ };
+ 
+ static int	originalArgc;
+--- a/xdm/session.c
 b/xdm/session.c
+@@ -67,6 +67,11 @@
+ # endif
+ #endif /* USE_PAM */
+ 
++#ifdef USE_CONSOLEKIT
++#include 
++#include 
++#endif
++
+ #ifdef __SCO__
+ # include 
+ #endif
+@@ -504,6 +509,97 @@
+ }
+ }
+ 
++#ifdef USE_CONSOLEKIT
++
++static CkConnector *connector;
++
++static int openCKSession(struct verify_info *verify, struct display *d)
++{
++int ret;
++DBusError error;
++char  *remote_host_name = "";
++dbus_bool_t is_local;
++char *display_name = "";
++char *display_device = "";
++char devtmp[16];
++
++if (!use_consolekit)
++	return 1;
++
++is_local = d->displayType.location == Local;
++if (d->peerlen > 0 && d->peer)
++	remote_host_name = d->peer;
++if (d->name)
++	display_name = d->name;
++/* how can we get the corresponding tty at best...? */
++if (d->windowPath) {
++	display_device = strchr(d->windowPath, ':');
++	if (display_device && display_device[1])
++	display_device++;
++	else
++	display_device = d->windowPath;
++	snprintf(devtmp, sizeof(devtmp), "/dev/tty%s", display_device);
++	display_device = devtmp;
++}
++
++connector = ck_connector_new();
++if (!connector) {
++	LogOutOfMem("ck_connector");
++	return 0;
++}
++
++dbus_error_init(&error);
++ret = ck_connector_open_session_with_parameters(
++		connector, &error,
++		"unix-user", &verify->uid,
++		"x11-display", &display_name,
++		"x11-display-device", &display_device,
++		"remote-host-name", &remote_host_name,
++		"is-local", &is_local,
++		NULL);
++if (!ret) {
++	if (dbus_error_is_set(&error)) {
++	LogError("Dbus error: %s\n", error.message);
++	dbus_error_free(&error);
++	} else {
++	LogError("ConsoleKit error\n");
++	}
++	LogError("console-kit-daemon not running?\n");
++	ck_connector_unref(conne

Bug#636323: notification-daemon: crashes on wrong type of 'transient' hint

[anomie]

found 636323 0.7.2-1
tags 636323 patch
thanks

This patch against 0.7.2-1 seems to fix the problem. What it does is
check the type of the incoming hint and use the appropriate
g_variant_get_* function.

It also applies the same fix for the "resident" and "action-icons"
hints.
--- a/src/nd-notification.c
+++ b/src/nd-notification.c
@@ -224,54 +224,53 @@
 }
 
 gboolean
-nd_notification_get_is_transient (NdNotification *notification)
+nd_notification_get_bool (NdNotification *notification, const char *name)
 {
 gboolean  ret;
 GVariant *value;
-
 ret = FALSE;
 g_return_val_if_fail (ND_IS_NOTIFICATION (notification), FALSE);
 
-value = g_hash_table_lookup (notification->hints, "transient");
+value = g_hash_table_lookup (notification->hints, name);
 if (value != NULL) {
-ret = g_variant_get_boolean (value);
+if (g_variant_is_of_type (value, G_VARIANT_TYPE_BOOLEAN)) {
+ret = g_variant_get_boolean (value);
+} else if (g_variant_is_of_type (value, G_VARIANT_TYPE_BYTE)) {
+ret = (g_variant_get_byte (value) != 0);
+} else if (g_variant_is_of_type (value, G_VARIANT_TYPE_INT16)) {
+ret = (g_variant_get_int16 (value) != 0);
+} else if (g_variant_is_of_type (value, G_VARIANT_TYPE_UINT16)) {
+ret = (g_variant_get_uint16 (value) != 0);
+} else if (g_variant_is_of_type (value, G_VARIANT_TYPE_INT32)) {
+ret = (g_variant_get_int32 (value) != 0);
+} else if (g_variant_is_of_type (value, G_VARIANT_TYPE_UINT32)) {
+ret = (g_variant_get_uint32 (value) != 0);
+} else if (g_variant_is_of_type (value, G_VARIANT_TYPE_INT64)) {
+ret = (g_variant_get_int64 (value) != 0);
+} else if (g_variant_is_of_type (value, G_VARIANT_TYPE_UINT64)) {
+ret = (g_variant_get_uint64 (value) != 0);
+}
 }
 
 return ret;
 }
 
 gboolean
-nd_notification_get_is_resident (NdNotification *notification)
+nd_notification_get_is_transient (NdNotification *notification)
 {
-gboolean  ret;
-GVariant *value;
-
-ret = FALSE;
-g_return_val_if_fail (ND_IS_NOTIFICATION (notification), FALSE);
-
-value = g_hash_table_lookup (notification->hints, "resident");
-if (value != NULL) {
-ret = g_variant_get_boolean (value);
-}
+return nd_notification_get_bool (notification, "transient");
+}
 
-return ret;
+gboolean
+nd_notification_get_is_resident (NdNotification *notification)
+{
+return nd_notification_get_bool (notification, "resident");
 }
 
 gboolean
 nd_notification_get_action_icons (NdNotification *notification)
 {
-gboolean  ret;
-GVariant *value;
-
-ret = FALSE;
-g_return_val_if_fail (ND_IS_NOTIFICATION (notification), FALSE);
-
-value = g_hash_table_lookup (notification->hints, "action-icons");
-if (value != NULL) {
-ret = g_variant_get_boolean (value);
-}
-
-return ret;
+return nd_notification_get_bool (notification, "action-icons");
 }
 
 guint32

Bug#639359: lintian should check if udev rules attempt to access programs in /usr

[anomie]

Package: lintian
Version: 2.5.2
Severity: wishlist

Rules installed into /lib/udev/rules.d may be called at boot before /usr
is mounted. Any rules files installed into this directory that attempt
to access binaries in /usr will fail with an error message printed at
boot, and whatever the rule was trying to set up may not be set up
properly.

Detection may be as simple as looking for '="/usr/' in these rules
files.

The fix, BTW, is also relatively simple. Packages that need to execute a
binary in /usr from a udev rule can install a wrapper script into
/lib/udev that waits for /usr to be mounted before executing the
program. Such a script may be as simple as:

#!/bin/sh -e
# /usr is not guaranteed to be mounted when udev starts

(
. /lib/udev/hotplug.functions
wait_for_file /usr/sbin/program
exec /usr/sbin/program "$@"
) &

Or, of course, they could move binaries to /sbin, or install a binary
for udev handling into /lib/udev, or install a more complicated script.

See bugs #624678, #635622, #636437, and #639356 for examples of bugs
this would detect.



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

Bug#639356: Bluez udev rules attempt to access /usr when /usr may not be mounted

[anomie]

Package: bluez
Version: 4.96-1

The file /lib/udev/rules.d/97-bluetooth.rules installed by this package
contains calls to programs in /usr, which may not be mounded at the time
it is first used during boot. This causes error messages to be printed
during boot as udev complains about being unable to execute the command.
Note this only occurs on systems where /usr is a separate partition.

The fix is to install an appropriate script in /lib/udev and then use
that from the udev rules. The script could be something as simple as
this:

#!/bin/sh -e
# /usr is not guaranteed to be mounted when udev starts

(
. /lib/udev/hotplug.functions
wait_for_file /usr/sbin/bluetoothd
exec /usr/sbin/bluetoothd "$@"
) &

See bug #624678 for a similar bug in a different package.



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

Bug#634325: cups-polld does not properly handle network errors, uses 100% CPU in loop

[anomie]

found 634325 1.4.8-2
fixed 634325 1.5.0-1
thanks

The patch seems to have been applied upstream in 1.5.0.



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

Bug#634325: cups-polld does not properly handle network errors, uses 100% CPU in loop

[anomie]

Package: cups
Version: 1.4.7-1
Tags: patch

If cups-polld runs into a network error after connecting to a remote IPP
server while polling, it will wind up in an endless loop using 100% CPU.
This can be quickly tested using the following procedure:

  1. Configure cups with BrowsePoll to poll a remote server
  2. Use strace on the cups-polld instance for the remote server
  3. Use iptables to block responses from the server, e.g.
  iptables -I INPUT 1 -p tcp -s 192.2.0.2 --sport ipp -j REJECT 
--reject-with tcp-reset
  4. Wait for the strace to show that cups-polld is blocking in recvfrom
  5. Use iptables to send RST on packets to the server, e.g.
  iptables -I OUTPUT 1 -p tcp -d 192.2.0.2 --dport ipp -j REJECT 
--reject-with tcp-reset
  6. Wait until TCP decides it has waited too long for an ACK and
 resends the packet.
  7. Observe that the recvfrom now fails with ECONNRESET, and then
 strace outputs lines like the following until the process is killed:
  recvfrom(6, "", 2048, 0, NULL, NULL)   = 0

Note that step 5 may be skipped, in which case you have to wait until
the TCP connection times out in step 6. In the wild, this sort of
situation may occur if the machine is suspended or if the network
connection goes down at the wrong time.

This appears to be the same as
https://bugzilla.redhat.com/show_bug.cgi?id=720921, and the patch
extracted from
http://pkgs.fedoraproject.org/gitweb/?p=cups.git;a=commitdiff;h=a8d53773cf4e1014d4fbb065ab6f0ea480184de9
seems to work. I've attached the actual patch to this message, which
should be importable with quilt import -p1.
--- a/cups/request.c
+++ b/cups/request.c
@@ -395,7 +395,7 @@
   {
 status = httpUpdate(http);
   }
-  while (http->state == HTTP_POST_RECV);
+  while (status != HTTP_ERROR && http->state == HTTP_POST_RECV);
 
   DEBUG_printf(("2cupsGetResponse: status=%d", status));
 

Bug#624678: I can confirm this bug

[anomie]

On Fri, Jul 08, 2011 at 07:21:01PM +0530, Ritesh Raj Sarraf wrote:
> 
> That should be it. Please let me know if that fixes the problem.

I suspect the %k in /lib/udev/lmt-udev won't get expanded correctly,
in this line:

>   exec /usr/sbin/laptop_mode "force modules=usb-autosuspend 
> devices=%k"

You might have to pass the value of %k in from 99-laptop-mode.rules instead.

Just out of curiousity, is there any particular reason you abandoned the
earlier approach of just using "%@" in /lib/udev/lmt-udev?



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

Bug#624678: 99-laptop-mode.rules uses programs in /usr

[anomie]

On Sun, May 01, 2011 at 10:09:41PM +0530, Ritesh Raj Sarraf wrote:
> 
> I'm not sure about this error. I've not seen it on my laptop. That rule
> is supposed to run when there's an Add event in the USB subsystem. Does
> it generate events at boot time?

Yes.

> Can you give me steps on how to reproduce this?

Have /usr on a separate partition, and boot the computer. Udev 168-1,
let me know if you want versions on anything else, but it's sid as of
shortly before the bug was filed.

> And if you are seeing this error, can you capture the udev logs
> (preferably with udev logging enabled) and put it here?

I'll have to check. /var, of course, isn't mounted at that point either.



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

Bug#624678: 99-laptop-mode.rules uses programs in /usr

[anomie]

On Sun, May 01, 2011 at 12:56:18AM +0530, Ritesh Raj Sarraf wrote:
> On 04/30/2011 07:11 PM, ano...@users.sourceforge.net wrote:
> > The file 99-laptop-mode.rules installed by this package contains calls
> > to programs in /usr, which may not be mounted at the time it is first
> > used during boot. This causes numerous error messages to be printed
> > during boot as udev complains about being unable to execute the command.
> laptop_mode is itself part of /usr. So, if /usr/ is not mounted, it'd
> just fail. No?

It does "just fail". And that means at boot we get an error along the
lines of 'exec of program "/usr/sbin/laptop_mode force
modules=usb-autosuspend devices=..." failed' printed for every USB hub
and device on boot.

The solution is probably to install an appropriate script into
/lib/udev, along the lines of the others installed in that directory.



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

Bug#556694: FTBFS with binutils-gold

[anomie]

Here is a patch to configure.ac to make it pull in the needed libraries.
Note that the selinux check must be moved, otherwise PKG_CHECK_MODULES
skips setting XDM_LIBS entirely; as an alternative, you could have it
set some other variable than XDM_LIBS and merge it in later.
--- a/configure.ac
+++ b/configure.ac
@@ -131,23 +131,6 @@
 		 fi])
 fi
 
-use_selinux_default=no
-# Check for selinux support
-AC_ARG_WITH(selinux, AC_HELP_STRING([--with-selinux],[Add support for selinux]),
-	[USE_SELINUX=$withval], [USE_SELINUX=$use_selinux_default])
-if test "x$USE_SELINUX" != "xno" ; then
-   	old_LIBS="$LIBS"
-	LIBS=""
-	AC_SEARCH_LIBS(is_selinux_enabled,[selinux])
-	AC_CHECK_FUNC(is_selinux_enabled,
-		[AC_DEFINE(HAVE_SELINUX,1,[Add support for selinux])],
-		[if test "x$USE_SELINUX" != "xtry" ; then
-			AC_MSG_ERROR(["selinux support requested, but is_selinux_enabled not found."])
-		 fi])
-	XDM_LIBS="$XDM_LIBS $LIBS"
-	LIBS="$old_LIBS"
-fi
-
 # FIXME: Find better test for which OS'es use su -m  - for now, just try to
 # mirror the Imakefile setting of:
 # if  defined(OpenBSDArchitecture) || defined(NetBSDArchitecture) || defined(FreeBSDArchitecture) || defined(DarwinArchitecture)
@@ -309,7 +292,7 @@
 
 # Checks for pkg-config packages
 
-PKG_CHECK_MODULES(XDM, xmu x11 xau)
+PKG_CHECK_MODULES(XDM, xmu x11 xext xrender xau)
 
 XDM_LIBS="$XDM_LIBS $XDM_OS_LIBS"
 
@@ -325,6 +308,23 @@
 	GREETER_LIBS="$GREETER_LIBS $XINERAMA_LIBS"
 ])
 
+use_selinux_default=no
+# Check for selinux support
+AC_ARG_WITH(selinux, AC_HELP_STRING([--with-selinux],[Add support for selinux]),
+	[USE_SELINUX=$withval], [USE_SELINUX=$use_selinux_default])
+if test "x$USE_SELINUX" != "xno" ; then
+   	old_LIBS="$LIBS"
+	LIBS=""
+	AC_SEARCH_LIBS(is_selinux_enabled,[selinux])
+	AC_CHECK_FUNC(is_selinux_enabled,
+		[AC_DEFINE(HAVE_SELINUX,1,[Add support for selinux])],
+		[if test "x$USE_SELINUX" != "xtry" ; then
+			AC_MSG_ERROR(["selinux support requested, but is_selinux_enabled not found."])
+		 fi])
+	XDM_LIBS="$XDM_LIBS $LIBS"
+	LIBS="$old_LIBS"
+fi
+
 # Xft text drawing for the greeter screen
 AC_ARG_WITH(xft, 
 	AC_HELP_STRING([--with-xft], 
@@ -379,7 +379,7 @@
 
 PKG_CHECK_MODULES(XDM_PRINT, xaw7)
 PKG_CHECK_MODULES(DMCP, xdmcp)
-PKG_CHECK_MODULES(XLIB, x11)
+PKG_CHECK_MODULES(XLIB, x11 xext)
 PKG_CHECK_MODULES(AUTH, xau)
 
 #

Bug#624678: 99-laptop-mode.rules uses programs in /usr

[anomie]

Package: laptop-mode-tools
Version: 1.57-1

The file 99-laptop-mode.rules installed by this package contains calls
to programs in /usr, which may not be mounted at the time it is first
used during boot. This causes numerous error messages to be printed
during boot as udev complains about being unable to execute the command.



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

Bug#568169: devicekit-disks forgets dm devices on udevadm trigger

[anomie]

Package: devicekit-disks
Version: 009-2

Executing udevadm trigger causes devicekit-disks to forget all dm
devices (i.e. lvm volumes and luks cleartext devices). See the attached
session transcript.
Script started on Tue 02 Feb 2010 01:16:31 PM EST
# devkit-disks --enumerate
/org/freedesktop/DeviceKit/Disks/devices/dm_2d1
/org/freedesktop/DeviceKit/Disks/devices/dm_2d2
/org/freedesktop/DeviceKit/Disks/devices/dm_2d3
/org/freedesktop/DeviceKit/Disks/devices/dm_2d4
/org/freedesktop/DeviceKit/Disks/devices/dm_2d5
/org/freedesktop/DeviceKit/Disks/devices/dm_2d6
/org/freedesktop/DeviceKit/Disks/devices/dm_2d7
/org/freedesktop/DeviceKit/Disks/devices/dm_2d8
/org/freedesktop/DeviceKit/Disks/devices/dm_2d9
/org/freedesktop/DeviceKit/Disks/devices/sda1
/org/freedesktop/DeviceKit/Disks/devices/sda2
/org/freedesktop/DeviceKit/Disks/devices/sda3
/org/freedesktop/DeviceKit/Disks/devices/sda4
/org/freedesktop/DeviceKit/Disks/devices/sda5
/org/freedesktop/DeviceKit/Disks/devices/sda6
/org/freedesktop/DeviceKit/Disks/devices/dm_2d11
/org/freedesktop/DeviceKit/Disks/devices/dm_2d10
/org/freedesktop/DeviceKit/Disks/devices/sr0
/org/freedesktop/DeviceKit/Disks/devices/sda
# udevadm trigger
# devkit-disks --enumerate
/org/freedesktop/DeviceKit/Disks/devices/sda6
/org/freedesktop/DeviceKit/Disks/devices/sda
/org/freedesktop/DeviceKit/Disks/devices/sr0
/org/freedesktop/DeviceKit/Disks/devices/sda1
/org/freedesktop/DeviceKit/Disks/devices/sda2
/org/freedesktop/DeviceKit/Disks/devices/sda3
/org/freedesktop/DeviceKit/Disks/devices/sda4
/org/freedesktop/DeviceKit/Disks/devices/sda5
# killall devkit-disks-daemon
# devkit-disks --enumerate
/org/freedesktop/DeviceKit/Disks/devices/dm_2d1
/org/freedesktop/DeviceKit/Disks/devices/dm_2d2
/org/freedesktop/DeviceKit/Disks/devices/dm_2d3
/org/freedesktop/DeviceKit/Disks/devices/dm_2d4
/org/freedesktop/DeviceKit/Disks/devices/dm_2d5
/org/freedesktop/DeviceKit/Disks/devices/dm_2d6
/org/freedesktop/DeviceKit/Disks/devices/dm_2d7
/org/freedesktop/DeviceKit/Disks/devices/dm_2d8
/org/freedesktop/DeviceKit/Disks/devices/dm_2d9
/org/freedesktop/DeviceKit/Disks/devices/sda1
/org/freedesktop/DeviceKit/Disks/devices/sda2
/org/freedesktop/DeviceKit/Disks/devices/sda3
/org/freedesktop/DeviceKit/Disks/devices/sda4
/org/freedesktop/DeviceKit/Disks/devices/sda5
/org/freedesktop/DeviceKit/Disks/devices/sda6
/org/freedesktop/DeviceKit/Disks/devices/dm_2d11
/org/freedesktop/DeviceKit/Disks/devices/dm_2d10
/org/freedesktop/DeviceKit/Disks/devices/sr0
/org/freedesktop/DeviceKit/Disks/devices/sda
# exit

Script done on Tue 02 Feb 2010 01:17:52 PM EST

Bug#567363: evince cannot correctly save some pdf forms

[anomie]

Package: evince
Version: 2.28.2-1

Some PDF forms, such as http://www.irs.gov/pub/irs-pdf/f1040es.pdf, can
be opened with evince and edited fine, but when saving all the changes
are forgotten and the modified fields in the saved version can no longer
be edited. When saving, evince outputs the following error to the
console once for each field in the form that was modified:

 Error: Reference in Fields array to an invalid or non existant object

Running the original pdf through either pdfopt or pdfedit's delinearize
function creates a form that can be correctly saved, at least in this
case.



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

Bug#566174: gtk apps set WM_COMMAND incorrectly on the leader window

[anomie]

I suppose it would help if I actually sent the testcase.
/* gcc -Wall foo.c -o foo `pkg-config --cflags --libs gtk+-2.0` */
#include 

int main(int argc, char **argv){
g_set_prgname("this-will-be-wrong");
gtk_init(&argc, &argv);
gtk_widget_show(gtk_window_new(GTK_WINDOW_TOPLEVEL));
gtk_main();
return 0;
}

Bug#566174: gtk apps set WM_COMMAND incorrectly on the leader window

[anomie]

Package: libgtk2.0-0
Version: 2.18.6-1

Gtk apps but don't set WM_COMMAND correctly on their leader window. Most
end up setting it to just the filename component of argv[0], while a few
that call g_set_prgname before gtk_init set it to whatever name was
passed to g_set_prgname, which may not even be an extant command name or
may even refer to a different program. Interestingly, the real client
window somehow gets the correct WM_COMMAND set (even though it should
have no or a zero-length WM_COMMAND since it is not the group leader).

I've attached a minimal test program. Running the program will just open
a blank window. Inspecting this window with xprop will reveal a
WM_COMMAND with the correct information, including the path and command
line arguments, something like this: (extraneous output snipped)
  WM_COMMAND(STRING) = { "./foo", "bar", "baz" }
  WM_HINTS(WM_HINTS):
Client accepts input or input focus: True
Initial state is Normal State.
window id # of group leader: 0x561
  WM_CLIENT_LEADER(WINDOW): window id # 0x561

Inspecting the client leader window (0x561 here) shows the incorrect
WM_COMMAND:
  WM_COMMAND(STRING) = { "this-will-be-wrong" }

This incorrect WM_COMMAND can cause problems for other programs that may
want to know how to re-execute a running gtk program (e.g. kept dock and
clip icons in wmaker, which is how I noticed this issue).



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

Bug#565479: Vorbis plugin should support METADATA_BLOCK_PICTURE

[anomie]

Package: xmms2-plugin-vorbis
Version: 0.6DrMattDestruction-7
Severity: wishlist
Tags: patch

Just as mp3 files can contain embedded cover art via the APIC frame,
vorbis files can contain images in a METADATA_BLOCK_PICTURE comment. See
http://wiki.xiph.org/index.php/VorbisComment#Cover_art for details.

It would be nice if this were supported. Patch attached.
diff -bBur xmms2-0.6DrMattDestruction.old/src/plugins/vorbis/vorbis.c 
xmms2-0.6DrMattDestruction/src/plugins/vorbis/vorbis.c
--- xmms2-0.6DrMattDestruction.old/src/plugins/vorbis/vorbis.c  2009-04-21 
13:51:11.0 -0400
+++ xmms2-0.6DrMattDestruction/src/plugins/vorbis/vorbis.c  2010-01-15 
22:45:08.971009555 -0500
@@ -246,6 +246,74 @@
}
 }
 
+static void
+handle_image_comment (xmms_xform_t *xform, const gchar *value, gsize len)
+{
+   guint32 typ, mime_len, desc_len, img_len;
+   guchar *pos, *end, *mime_data, *img_data;
+   gchar hash[33];
+
+   pos = value;
+   end = value + len;
+
+   if (pos + 4 > end) {
+   XMMS_DBG ("Malformed picture comment");
+   return;
+   }
+   typ = GUINT32_FROM_BE (*(guint32 *)pos);
+   if (typ != 0 && typ != 3) {
+   XMMS_DBG ("Picture type %d not handled", typ);
+   return;
+   }
+   pos += 4;
+
+   if (pos + 4 > end) {
+   XMMS_DBG ("Malformed picture comment");
+   return;
+   }
+   mime_len = GUINT32_FROM_BE (*(guint32 *)pos);
+   pos += 4;
+   mime_data = pos;
+   pos += mime_len;
+
+   if (pos + 4 > end) {
+   XMMS_DBG ("Malformed picture comment");
+   return;
+   }
+   desc_len = GUINT32_FROM_BE (*(guint32 *)pos);
+   pos += 4;
+   pos += desc_len;
+
+   pos += 4; /* width */
+   pos += 4; /* height */
+   pos += 4; /* depth */
+   pos += 4; /* indexed palette length */
+
+   if (pos + 4 > end) {
+   XMMS_DBG ("Malformed picture comment");
+   return;
+   }
+   img_len = GUINT32_FROM_BE (*(guint32 *)pos);
+   pos += 4;
+   img_data = pos;
+
+   if (img_data + img_len > end) {
+   XMMS_DBG ("Malformed picture comment");
+   return;
+   }
+
+   if (xmms_bindata_plugin_add ((const guchar *)img_data, img_len, hash)) {
+   const gchar *metakey;
+
+   metakey = XMMS_MEDIALIB_ENTRY_PROPERTY_PICTURE_FRONT;
+   xmms_xform_metadata_set_str (xform, metakey, hash);
+
+   metakey = XMMS_MEDIALIB_ENTRY_PROPERTY_PICTURE_FRONT_MIME;
+   mime_data[mime_len] = '\0';
+   xmms_xform_metadata_set_str (xform, metakey, mime_data);
+   }
+}
+
 /* note that "key" is NOT NUL-terminated here,
  * but "value" is.
  */
@@ -256,6 +324,14 @@
 {
gint i;
 
+   if (!g_ascii_strncasecmp (key, "METADATA_BLOCK_PICTURE", key_len)) {
+   gsize dlen;
+   gchar *dvalue = g_base64_decode (value, &dlen);
+   handle_image_comment (xform, dvalue, dlen);
+   g_free (dvalue);
+   return;
+   }
+
for (i = 0; i < G_N_ELEMENTS (properties); i++) {
if ((!g_ascii_strncasecmp (key, "MUSICBRAINZ_ALBUMARTISTID", 
key_len)) &&
(!g_ascii_strcasecmp (value, MUSICBRAINZ_VA_ID))) {

Bug#547382: Detect windows recovery partitions (fix provided)

[anomie]

I'm not sure if it came that way or if it got changed by the Debian
installer (snapshot from 2009-12-11), but the recovery partition on my
new Thinkpad T500 is type 7 rather than 27. The recovery partition is
also detected as Vista rather than 7, FWIW.

This check along the same lines as the Windows 7 check seems to work for
me:

@@ -21,6 +21,8 @@
bcd="$(item_in_dir bcd "$2/$boot")"; then
if grep -qs "W.i.n.d.o.w.s. .7" "$2/$boot/$bcd"; then
long="Windows 7 (loader)"
+   elif grep -qs "W.i.n.d.o.w.s. .R.e.c.o.v.e.r.y. .E.n.v.i.r.o.n.m.e.n.t" 
"$2/$boot/$bcd"; then
+   long="Windows Recovery Environment (loader)"
else
long="Windows Vista (loader)"
fi

Of course, if that generic naming is used then grub-common's
30_os-prober probably has to be updated to match.



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

Bug#561281: /lib/udev/rules.d/85-hwclock.rules screws up time on udevadm trigger if hw clock is not UTC

[anomie]

Package: util-linux
Version: 2.16.2-0

/lib/udev/rules.d/85-hwclock.rules attempts to adjust the system clock
when /dev/rtc0 becomes available. However, it uses --systz rather than
--hctosys, which means that instead of reading the RTC it just assumes
that the system clock is the correct UTC time and adjusts it based on
/etc/localtime. This works fine on boot on recent 2.6 kernels, but if
"udevadm trigger" is called (or /dev/rtc0 is re-announced for some other
reason), it screws things up.

For example:

# ntpdate-debian 
15 Dec 16:48:50 ntpdate[5081]: adjust time server 204.9.54.119 offset 0.013977 
sec
# date
Tue Dec 15 16:48:54 EST 2009
# udevadm trigger
# date
Tue Dec 15 21:49:05 EST 2009
# ntpdate-debian 
15 Dec 16:49:11 ntpdate[5488]: step time server 204.9.54.119 offset 
-17999.992513 sec



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

Bug#561243: Obsolete udev rules

[anomie]

Package: barry-util
Version: 0.15-1

udev has begun complaining about the use of certain keys deprecated
since 2006. It issues the following complaints related to this package's
rules file:

 udevd[1337]: BUS= will be removed in a future udev version, please use 
SUBSYSTEM= to match the event device, or SUBSYSTEMS= to match a parent device, 
in /etc/udev/rules.d/10-blackberry.rules:21
 udevd[1337]: SYSFS{}= will be removed in a future udev version, please use 
ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in 
/etc/udev/rules.d/10-blackberry.rules:21
 udevd[1337]: BUS= will be removed in a future udev version, please use 
SUBSYSTEM= to match the event device, or SUBSYSTEMS= to match a parent device, 
in /etc/udev/rules.d/10-blackberry.rules:23
 udevd[1337]: SYSFS{}= will be removed in a future udev version, please use 
ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in 
/etc/udev/rules.d/10-blackberry.rules:23
 udevd[1337]: BUS= will be removed in a future udev version, please use 
SUBSYSTEM= to match the event device, or SUBSYSTEMS= to match a parent device, 
in /etc/udev/rules.d/10-blackberry.rules:29
 udevd[1337]: SYSFS{}= will be removed in a future udev version, please use 
ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in 
/etc/udev/rules.d/10-blackberry.rules:29
 udevd[1337]: BUS= will be removed in a future udev version, please use 
SUBSYSTEM= to match the event device, or SUBSYSTEMS= to match a parent device, 
in /etc/udev/rules.d/10-blackberry.rules:30
 udevd[1337]: SYSFS{}= will be removed in a future udev version, please use 
ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in 
/etc/udev/rules.d/10-blackberry.rules:30
 udevd[1337]: BUS= will be removed in a future udev version, please use 
SUBSYSTEM= to match the event device, or SUBSYSTEMS= to match a parent device, 
in /etc/udev/rules.d/10-blackberry.rules:31
 udevd[1337]: SYSFS{}= will be removed in a future udev version, please use 
ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in 
/etc/udev/rules.d/10-blackberry.rules:31
 udevd[1337]: BUS= will be removed in a future udev version, please use 
SUBSYSTEM= to match the event device, or SUBSYSTEMS= to match a parent device, 
in /etc/udev/rules.d/10-blackberry.rules:33
 udevd[1337]: SYSFS{}= will be removed in a future udev version, please use 
ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in 
/etc/udev/rules.d/10-blackberry.rules:33
 udevd[1337]: BUS= will be removed in a future udev version, please use 
SUBSYSTEM= to match the event device, or SUBSYSTEMS= to match a parent device, 
in /etc/udev/rules.d/10-blackberry.rules:34
 udevd[1337]: SYSFS{}= will be removed in a future udev version, please use 
ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in 
/etc/udev/rules.d/10-blackberry.rules:34
 udevd[1337]: BUS= will be removed in a future udev version, please use 
SUBSYSTEM= to match the event device, or SUBSYSTEMS= to match a parent device, 
in /etc/udev/rules.d/10-blackberry.rules:35
 udevd[1337]: SYSFS{}= will be removed in a future udev version, please use 
ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in 
/etc/udev/rules.d/10-blackberry.rules:35



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

Bug#561126: Please work around Firefox bug 492459 (Websites are no longer rendered if SSL requests for JavaScripts are blocked by a proxy)

[anomie]

Package: privoxy
Version: 3.0.15-2
Severity: wishlist
Tags: patch

Firefox (and thus Iceweasel) since 3.0.10 has a bug[1] in which it will
wait forever for a javascript file to load if the SSL proxy (e.g.
privoxy) returns a failure status code in response to the CONNECT. Since
javascript must be loaded for page rendering to proceed, this means some
sites are completely unusable as they never render for waiting for the
javascript that will never come.

A patch is available in the upstream bug tracker[2] to add a
configuration option to enable Privoxy to return a "200 OK" response in
this situation, which effectively works around this issue. Please
consider picking this up until it gets into an official upstream version
or until Firefox fixes their bug. Thanks.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=492459
[2] 
http://sourceforge.net/tracker/index.php?func=detail&aid=2893965&group_id=8&atid=38



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

Bug#514463: Poor bounds checking causes abnormal exits or crashes

[anomie]

Package: gfpoken
Version: 0.31-2

There are small regions to the right of and below the grid that cause
gfpoken to fail when they are clicked, due to poor bounds checking in
the click event handlers.

For example:
1. Clicking the right region in line with the top row of the grid
   manipulates the second cell in the second row of the grid; in a grid
   with five columns numbered 0-4, that click tried to manipulate column
   *6* which wrapped in the linear array in memory. 
2. Clicking the right region in line with the bottom row, or the bottom
   region in line with any of the columns, results in an exit with
   "BUG: unknown case in nextobj" or a SEGV. In this case, it tried to
   manipulate a cell off the edge of the grid and hence off the end of
   the memory array.
3. Clicking either region in line with the "ball rolling" areas results
   in corrupted graphics (as if a ball is rolling through the
   out-of-bounds region) followed by an exit with a "Hash overrun"
   message.

It seems the mouse button event handlers need to do better checking for
out-of-bounds values, and/or the grid widget needs to size itself
correctly so these regions don't exist.



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

Bug#465388: wmacpi doesn't work with sysfs

[anomie]

On Wed, Feb 13, 2008 at 10:14:40PM +0100, Julien BLACHE wrote:
> 
> I've just uploaded 2.2~rc1-4, please tell me how well/bad it goes.

Works fine, thanks.



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

Bug#465388: wmacpi doesn't work with sysfs

[anomie]

Package: wmacpi
Version: wmacpi-2.2~rc1

wmacpi fails to give any battery data on my system (2.6.24.2 from
kernel.org, also tested on 2.6.24.1). This seems to be due to the fact
that wmacpi attempts to access BAT1/energy_*, while these values are not
available on my laptop.

$ ls /sys/class/power_supply/BAT1
alarm   current_now   power  technology  voltage_now
charge_full devicepresenttype
charge_full_design  manufacturer  status uevent
charge_now  model_namesubsystem  voltage_min_design



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