[PATCH master] Bugfix: migrate needs HypervisorClass, not an instance

[David Mohr]

Otherwise it will complain about permissions of
/var/run/ganeti/kvm-hypervisor

Signed-off-by: David Mohr <da...@mcbf.net>
---
 lib/cmdlib/instance_migration.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/cmdlib/instance_migration.py b/lib/cmdlib/instance_migration.py
index b93b334..ad6f9c3 100644
--- a/lib/cmdlib/instance_migration.py
+++ b/lib/cmdlib/instance_migration.py
@@ -746,7 +746,7 @@ class TLMigrateInstance(Tasklet):
 self.feedback_fn("* warning: hypervisor version mismatch between"
  " source (%s) and target (%s) node" %
  (src_version, dst_version))
-hv = hypervisor.GetHypervisor(self.instance.hypervisor)
+hv = hypervisor.GetHypervisorClass(self.instance.hypervisor)
 if hv.VersionsSafeForMigration(src_version, dst_version):
   self.feedback_fn("  migrating from hypervisor version %s to %s 
should"
" be safe" % (src_version, dst_version))
-- 
2.9.3

[PATCH master] Bugfix for migration with different qemu versions on source and destination host

[David Mohr]

Migrating a qemu hypervisor when upgrading qemu versions will fail with an
obscure error complaining about directory permissions while the real problem is
a small bug in the code that passes the wrong type around. Unfortunately I
don't have an example error message handy at this time. I didn't file a bug for 
this issue.

David Mohr (1):
  Bugfix: migrate needs HypervisorClass, not an instance

 lib/cmdlib/instance_migration.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
2.9.3

[PATCH master] New configuration option for the rbd user-id

[David Mohr]

The user id is used by ceph to determine the keyring to use for
authentication. By default the admin keyring is used, which may
not be desirable. Example usage:

$ gnt-cluster modify -D rbd:user-id=foobar

Signed-off-by: David Mohr <da...@mcbf.net>
---
 lib/storage/bdev.py| 48 --
 src/Ganeti/Constants.hs| 18 +-
 test/py/cmdlib/cluster_unittest.py |  3 ++-
 3 files changed, 50 insertions(+), 19 deletions(-)

diff --git a/lib/storage/bdev.py b/lib/storage/bdev.py
index 81e60d0..96d670e 100644
--- a/lib/storage/bdev.py
+++ b/lib/storage/bdev.py
@@ -886,6 +886,13 @@ class RADOSBlockDevice(base.BlockDev):
 self.Attach()
 
   @classmethod
+  def MakeRbdCmd(cls, params, cmd):
+r_cmd = [constants.RBD_CMD] + cmd
+if params.get(constants.RBD_USER_ID, ""):
+  r_cmd.extend(["--id", str(params[constants.RBD_USER_ID])])
+return r_cmd
+
+  @classmethod
   def Create(cls, unique_id, children, size, spindles, params, excl_stor,
  dyn_params, **kwargs):
 """Create a new rbd device.
@@ -903,8 +910,8 @@ class RADOSBlockDevice(base.BlockDev):
 rbd_name = unique_id[1]
 
 # Provision a new rbd volume (Image) inside the RADOS cluster.
-cmd = [constants.RBD_CMD, "create", "-p", rbd_pool,
-   rbd_name, "--size", "%s" % size]
+cmd = cls.MakeRbdCmd(params, ["create", "-p", rbd_pool, rbd_name,
+  "--size", str(size)])
 result = utils.RunCmd(cmd)
 if result.failed:
   base.ThrowError("rbd creation failed (%s): %s",
@@ -928,7 +935,8 @@ class RADOSBlockDevice(base.BlockDev):
 self.Shutdown()
 
 # Remove the actual Volume (Image) from the RADOS cluster.
-cmd = [constants.RBD_CMD, "rm", "-p", rbd_pool, rbd_name]
+cmd = self.__class__.MakeRbdCmd(self.params, ["rm", "-p", rbd_pool,
+  rbd_name])
 result = utils.RunCmd(cmd)
 if result.failed:
   base.ThrowError("Can't remove Volume from cluster with rbd rm: %s - %s",
@@ -987,7 +995,7 @@ class RADOSBlockDevice(base.BlockDev):
   return rbd_dev
 
 # The mapping doesn't exist. Create it.
-map_cmd = [constants.RBD_CMD, "map", "-p", pool, name]
+map_cmd = self.__class__.MakeRbdCmd(self.params, ["map", "-p", pool, name])
 result = utils.RunCmd(map_cmd)
 if result.failed:
   base.ThrowError("rbd map failed (%s): %s",
@@ -1017,14 +1025,13 @@ class RADOSBlockDevice(base.BlockDev):
 try:
   # Newer versions of the rbd tool support json output formatting. Use it
   # if available.
-  showmap_cmd = [
-constants.RBD_CMD,
+  showmap_cmd = cls.MakeRbdCmd({}, [
 "showmapped",
 "-p",
 pool,
 "--format",
 "json"
-]
+])
   result = utils.RunCmd(showmap_cmd)
   if result.failed:
 logging.error("rbd JSON output formatting returned error (%s): %s,"
@@ -1036,7 +1043,7 @@ class RADOSBlockDevice(base.BlockDev):
 except RbdShowmappedJsonError:
   # For older versions of rbd, we have to parse the plain / text output
   # manually.
-  showmap_cmd = [constants.RBD_CMD, "showmapped", "-p", pool]
+  showmap_cmd = cls.MakeRbdCmd({}, ["showmapped", "-p", pool])
   result = utils.RunCmd(showmap_cmd)
   if result.failed:
 base.ThrowError("rbd showmapped failed (%s): %s",
@@ -1168,7 +1175,8 @@ class RADOSBlockDevice(base.BlockDev):
 
 if rbd_dev:
   # The mapping exists. Unmap the rbd device.
-  unmap_cmd = [constants.RBD_CMD, "unmap", "%s" % rbd_dev]
+  unmap_cmd = self.__class__.MakeRbdCmd(self.params, ["unmap",
+  str(rbd_dev)])
   result = utils.RunCmd(unmap_cmd)
   if result.failed:
 base.ThrowError("rbd unmap failed (%s): %s",
@@ -1212,8 +1220,8 @@ class RADOSBlockDevice(base.BlockDev):
 new_size = self.size + amount
 
 # Resize the rbd volume (Image) inside the RADOS cluster.
-cmd = [constants.RBD_CMD, "resize", "-p", rbd_pool,
-   rbd_name, "--size", "%s" % new_size]
+cmd = self.__class__.MakeRbdCmd(self.params, ["resize", "-p", rbd_pool,
+   rbd_name, "--size", str(new_size)])
 result = utils.RunCmd(cmd)
 if result.failed:
   base.ThrowError("rbd resize failed (%s): %s",
@@ -1248,16 +1256,18 @@ class RADOSBlockDevice(base.BlockDev):
 self._UnmapVolumeFromBlockdev(self.unique_id)
 
 # Remove the actual Volume (Image) from the RADOS clu

Re: [PATCH master] New configuration option for the rbd user-id

[David Mohr]

This was in reply to 
https://groups.google.com/forum/#!topic/ganeti-devel/dWVgZFk-MdM ; I seem 
to have screwed up the message-id when using send-email.

It has the fix for the unit tests. However, the check-local target doesn't 
pass on my system. It doesn't seem to be related to my patch, but still, 
he's the output:

 % make check-local
> RELEASE=2.18.0~alpha1 ./autotools/check-news < ./NEWS
> ./autotools/check-python-code ./autotools/build-bash-completion 
> ./autotools/check-imports ./autotools/check-header ./autotools/docpp 
> tools/ganeti-listrunner tools/cfgshell tools/cfgupgrade tools/cfgupgrade12 
> tools/cluster-merge tools/confd-client tools/fmtjson tools/lvmstrap 
> tools/move-instance tools/ovfconverter tools/post-upgrade 
> tools/sanitize-config tools/query-config daemons/import-export 
> tools/check-cert-expired tools/ensure-dirs tools/node-daemon-setup 
> tools/prepare-node-join tools/ssh-update tools/ssl-update  lib/__init__.py 
> lib/asyncnotifier.py lib/backend.py lib/bootstrap.py lib/cli.py 
> lib/cli_opts.py lib/compat.py lib/constants.py lib/daemon.py lib/errors.py 
> lib/hooksmaster.py lib/ht.py lib/jstore.py lib/locking.py lib/luxi.py 
> lib/mcpu.py lib/metad.py lib/netutils.py lib/objects.py lib/opcodes_base.py 
> lib/outils.py lib/ovf.py lib/pathutils.py lib/qlang.py lib/query.py 
> lib/rpc_defs.py lib/runtime.py lib/serializer.py lib/ssconf.py lib/ssh.py 
> lib/uidpool.py lib/vcluster.py lib/network.py lib/wconfd.py 
> lib/workerpool.py lib/client/__init__.py lib/client/base.py 
> lib/client/gnt_backup.py lib/client/gnt_cluster.py lib/client/gnt_debug.py 
> lib/client/gnt_group.py lib/client/gnt_instance.py lib/client/gnt_job.py 
> lib/client/gnt_node.py lib/client/gnt_network.py lib/client/gnt_os.py 
> lib/client/gnt_storage.py lib/client/gnt_filter.py lib/cmdlib/__init__.py 
> lib/cmdlib/backup.py lib/cmdlib/base.py lib/cmdlib/common.py 
> lib/cmdlib/group.py lib/cmdlib/instance.py lib/cmdlib/instance_create.py 
> lib/cmdlib/instance_helpervm.py lib/cmdlib/instance_migration.py 
> lib/cmdlib/instance_operation.py lib/cmdlib/instance_query.py 
> lib/cmdlib/instance_set_params.py lib/cmdlib/instance_storage.py 
> lib/cmdlib/instance_utils.py lib/cmdlib/misc.py lib/cmdlib/network.py 
> lib/cmdlib/node.py lib/cmdlib/operating_system.py lib/cmdlib/query.py 
> lib/cmdlib/tags.py lib/cmdlib/test.py lib/cmdlib/cluster/__init__.py 
> lib/cmdlib/cluster/verify.py lib/config/__init__.py lib/config/verify.py 
> lib/config/temporary_reservations.py lib/config/utils.py 
> lib/hypervisor/__init__.py lib/hypervisor/hv_base.py 
> lib/hypervisor/hv_chroot.py lib/hypervisor/hv_fake.py 
> lib/hypervisor/hv_lxc.py lib/hypervisor/hv_xen.py 
> lib/hypervisor/hv_kvm/__init__.py lib/hypervisor/hv_kvm/monitor.py 
> lib/hypervisor/hv_kvm/netdev.py lib/jqueue/__init__.py lib/jqueue/exec.py 
> lib/jqueue/post_hooks_exec.py lib/storage/__init__.py lib/storage/bdev.py 
> lib/storage/base.py lib/storage/container.py lib/storage/drbd.py 
> lib/storage/drbd_info.py lib/storage/drbd_cmdgen.py 
> lib/storage/extstorage.py lib/storage/filestorage.py lib/storage/gluster.py 
> lib/rapi/__init__.py lib/rapi/baserlib.py lib/rapi/client.py 
> lib/rapi/client_utils.py lib/rapi/connector.py lib/rapi/rlib2.py 
> lib/rapi/testutils.py lib/rapi/auth/__init__.py lib/rapi/auth/basic_auth.py 
> lib/rapi/auth/pam.py lib/rapi/auth/users_file.py lib/server/__init__.py 
> lib/server/masterd.py lib/server/noded.py lib/server/rapi.py 
> lib/rpc/__init__.py lib/rpc/client.py lib/rpc/errors.py lib/rpc/node.py 
> lib/rpc/transport.py lib/rpc/stub/__init__.py lib/tools/__init__.py 
> lib/tools/burnin.py lib/tools/common.py lib/tools/ensure_dirs.py 
> lib/tools/node_cleanup.py lib/tools/node_daemon_setup.py 
> lib/tools/prepare_node_join.py lib/tools/ssh_update.py 
> lib/tools/ssl_update.py lib/tools/cfgupgrade.py lib/http/__init__.py 
> lib/http/auth.py lib/http/client.py lib/http/server.py 
> lib/confd/__init__.py lib/confd/client.py lib/masterd/__init__.py 
> lib/masterd/iallocator.py lib/masterd/instance.py lib/impexpd/__init__.py 
> lib/utils/__init__.py lib/utils/algo.py lib/utils/filelock.py 
> lib/utils/hash.py lib/utils/io.py lib/utils/livelock.py lib/utils/log.py 
> lib/utils/lvm.py lib/utils/mlock.py lib/utils/nodesetup.py 
> lib/utils/process.py lib/utils/retry.py lib/utils/security.py 
> lib/utils/storage.py lib/utils/text.py lib/utils/tags.py 
> lib/utils/version.py lib/utils/wrapper.py lib/utils/x509.py 
> lib/utils/bitarrays.py lib/watcher/__init__.py lib/watcher/nodemaint.py 
> lib/watcher/state.py lib/build/__init__.py lib/build/shell_example_lexer.py 
> lib/build/sphinx_ext.py qa/__init__.py qa/ganeti-qa.py qa/qa_cluster.py 
> qa/qa_config.py qa/qa_daemon.py qa/qa_env.py qa/qa_error.py 
> qa/qa_filters.py qa/qa_group.py qa/qa_global_hooks.py qa/qa_instance.py 
> qa/qa_instance_utils.py qa/qa_iptables.py qa/qa_job.py qa/qa_job_utils.py 
> qa/qa_logging.py qa/qa_maintd.py qa/qa_monitoring.py qa/qa_network.py 
> 

[PATCH master] New configuration option for the rbd user-id

[David Mohr]

The user id is used by ceph to determine the keyring to use for
authentication. By default the admin keyring is used, which may
not be desirable. Example usage:

  $ gnt-cluster modify -D rbd:user-id=foobar

Signed-off-by: David Mohr <da...@mcbf.net>
---
 lib/storage/bdev.py|   44 ++--
 src/Ganeti/Constants.hs|   18 ++-
 test/py/cmdlib/cluster_unittest.py |3 ++-
 3 files changed, 46 insertions(+), 19 deletions(-)

diff --git a/lib/storage/bdev.py b/lib/storage/bdev.py
index 1f95004..5a4772f 100644
--- a/lib/storage/bdev.py
+++ b/lib/storage/bdev.py
@@ -886,6 +886,12 @@ class RADOSBlockDevice(base.BlockDev):
 self.Attach()
 
   @classmethod
+  def MakeRbdCmd(cls, params, cmd):
+if params.get(constants.RBD_USER_ID, ""):
+  cmd.extend(["--id", str(params[constants.RBD_USER_ID])])
+return [constants.RBD_CMD] + cmd
+
+  @classmethod
   def Create(cls, unique_id, children, size, spindles, params, excl_stor,
  dyn_params, **kwargs):
 """Create a new rbd device.
@@ -903,8 +909,8 @@ class RADOSBlockDevice(base.BlockDev):
 rbd_name = unique_id[1]
 
 # Provision a new rbd volume (Image) inside the RADOS cluster.
-cmd = [constants.RBD_CMD, "create", "-p", rbd_pool,
-   rbd_name, "--size", "%s" % size]
+cmd = cls.MakeRbdCmd(params, ["create", "-p", rbd_pool, rbd_name,
+  "--size", str(size)])
 result = utils.RunCmd(cmd)
 if result.failed:
   base.ThrowError("rbd creation failed (%s): %s",
@@ -928,7 +934,7 @@ class RADOSBlockDevice(base.BlockDev):
 self.Shutdown()
 
 # Remove the actual Volume (Image) from the RADOS cluster.
-cmd = [constants.RBD_CMD, "rm", "-p", rbd_pool, rbd_name]
+cmd = self.__class__.MakeRbdCmd(self.params, ["rm", "-p", rbd_pool, 
rbd_name])
 result = utils.RunCmd(cmd)
 if result.failed:
   base.ThrowError("Can't remove Volume from cluster with rbd rm: %s - %s",
@@ -987,7 +993,7 @@ class RADOSBlockDevice(base.BlockDev):
   return rbd_dev
 
 # The mapping doesn't exist. Create it.
-map_cmd = [constants.RBD_CMD, "map", "-p", pool, name]
+map_cmd = self.__class__.MakeRbdCmd(self.params, ["map", "-p", pool, name])
 result = utils.RunCmd(map_cmd)
 if result.failed:
   base.ThrowError("rbd map failed (%s): %s",
@@ -1017,14 +1023,13 @@ class RADOSBlockDevice(base.BlockDev):
 try:
   # Newer versions of the rbd tool support json output formatting. Use it
   # if available.
-  showmap_cmd = [
-constants.RBD_CMD,
+  showmap_cmd = cls.MakeRbdCmd({}, [
 "showmapped",
 "-p",
 pool,
 "--format",
 "json"
-]
+])
   result = utils.RunCmd(showmap_cmd)
   if result.failed:
 logging.error("rbd JSON output formatting returned error (%s): %s,"
@@ -1036,7 +1041,7 @@ class RADOSBlockDevice(base.BlockDev):
 except RbdShowmappedJsonError:
   # For older versions of rbd, we have to parse the plain / text output
   # manually.
-  showmap_cmd = [constants.RBD_CMD, "showmapped", "-p", pool]
+  showmap_cmd = cls.MakeRbdCmd({}, ["showmapped", "-p", pool])
   result = utils.RunCmd(showmap_cmd)
   if result.failed:
 base.ThrowError("rbd showmapped failed (%s): %s",
@@ -1168,7 +1173,7 @@ class RADOSBlockDevice(base.BlockDev):
 
 if rbd_dev:
   # The mapping exists. Unmap the rbd device.
-  unmap_cmd = [constants.RBD_CMD, "unmap", "%s" % rbd_dev]
+  unmap_cmd = self.__class__.MakeRbdCmd(self.params, ["unmap", 
str(rbd_dev)])
   result = utils.RunCmd(unmap_cmd)
   if result.failed:
 base.ThrowError("rbd unmap failed (%s): %s",
@@ -1212,8 +1217,8 @@ class RADOSBlockDevice(base.BlockDev):
 new_size = self.size + amount
 
 # Resize the rbd volume (Image) inside the RADOS cluster.
-cmd = [constants.RBD_CMD, "resize", "-p", rbd_pool,
-   rbd_name, "--size", "%s" % new_size]
+cmd = self.__class__.MakeRbdCmd(self.params, ["resize", "-p", rbd_pool,
+   rbd_name, "--size", str(new_size)])
 result = utils.RunCmd(cmd)
 if result.failed:
   base.ThrowError("rbd resize failed (%s): %s",
@@ -1248,16 +1253,17 @@ class RADOSBlockDevice(base.BlockDev):
 self._UnmapVolumeFromBlockdev(self.unique_id)
 
 # Remove the actual Volume (Image) from the RADOS cluster.
-cmd = [constants.RBD_CMD, "rm", "-p", rbd_pool, rbd_name]
+cmd = self.__class__.MakeRbdCm

Re: [PATCH master] New configuration option for the rbd user-id

[David Mohr]

Hi Brian,

this is the squashed commit of the actual code changes; without this the 
documentation update is slightly misleading ;-)

Thanks for applying it! I'll be back soon with more patches.

~David

On Thursday, June 23, 2016 at 3:57:52 PM UTC+2, David Mohr wrote:
>
> The user id is used by ceph to determine the keyring to use for 
> authentication. By default the admin keyring is used, which may 
> not be desirable. Example usage: 
>
>   $ gnt-cluster modify -D rbd:user-id=foobar 
>
> Signed-off-by: David Mohr <da...@mcbf.net > 
> --- 
>  lib/storage/bdev.py |   44 
> +++- 
>  src/Ganeti/Constants.hs |   18 +- 
>  2 files changed, 44 insertions(+), 18 deletions(-) 
>

[PATCH master] New configuration option for the rbd user-id

[David Mohr]

The user id is used by ceph to determine the keyring to use for
authentication. By default the admin keyring is used, which may
not be desirable. Example usage:

  $ gnt-cluster modify -D rbd:user-id=foobar

Signed-off-by: David Mohr <da...@mcbf.net>
---
 lib/storage/bdev.py |   44 +++-
 src/Ganeti/Constants.hs |   18 +-
 2 files changed, 44 insertions(+), 18 deletions(-)

diff --git a/lib/storage/bdev.py b/lib/storage/bdev.py
index 1f95004..5a4772f 100644
--- a/lib/storage/bdev.py
+++ b/lib/storage/bdev.py
@@ -886,6 +886,12 @@ class RADOSBlockDevice(base.BlockDev):
 self.Attach()
 
   @classmethod
+  def MakeRbdCmd(cls, params, cmd):
+if params.get(constants.RBD_USER_ID, ""):
+  cmd.extend(["--id", str(params[constants.RBD_USER_ID])])
+return [constants.RBD_CMD] + cmd
+
+  @classmethod
   def Create(cls, unique_id, children, size, spindles, params, excl_stor,
  dyn_params, **kwargs):
 """Create a new rbd device.
@@ -903,8 +909,8 @@ class RADOSBlockDevice(base.BlockDev):
 rbd_name = unique_id[1]
 
 # Provision a new rbd volume (Image) inside the RADOS cluster.
-cmd = [constants.RBD_CMD, "create", "-p", rbd_pool,
-   rbd_name, "--size", "%s" % size]
+cmd = cls.MakeRbdCmd(params, ["create", "-p", rbd_pool, rbd_name,
+  "--size", str(size)])
 result = utils.RunCmd(cmd)
 if result.failed:
   base.ThrowError("rbd creation failed (%s): %s",
@@ -928,7 +934,7 @@ class RADOSBlockDevice(base.BlockDev):
 self.Shutdown()
 
 # Remove the actual Volume (Image) from the RADOS cluster.
-cmd = [constants.RBD_CMD, "rm", "-p", rbd_pool, rbd_name]
+cmd = self.__class__.MakeRbdCmd(self.params, ["rm", "-p", rbd_pool, 
rbd_name])
 result = utils.RunCmd(cmd)
 if result.failed:
   base.ThrowError("Can't remove Volume from cluster with rbd rm: %s - %s",
@@ -987,7 +993,7 @@ class RADOSBlockDevice(base.BlockDev):
   return rbd_dev
 
 # The mapping doesn't exist. Create it.
-map_cmd = [constants.RBD_CMD, "map", "-p", pool, name]
+map_cmd = self.__class__.MakeRbdCmd(self.params, ["map", "-p", pool, name])
 result = utils.RunCmd(map_cmd)
 if result.failed:
   base.ThrowError("rbd map failed (%s): %s",
@@ -1017,14 +1023,13 @@ class RADOSBlockDevice(base.BlockDev):
 try:
   # Newer versions of the rbd tool support json output formatting. Use it
   # if available.
-  showmap_cmd = [
-constants.RBD_CMD,
+  showmap_cmd = cls.MakeRbdCmd({}, [
 "showmapped",
 "-p",
 pool,
 "--format",
 "json"
-]
+])
   result = utils.RunCmd(showmap_cmd)
   if result.failed:
 logging.error("rbd JSON output formatting returned error (%s): %s,"
@@ -1036,7 +1041,7 @@ class RADOSBlockDevice(base.BlockDev):
 except RbdShowmappedJsonError:
   # For older versions of rbd, we have to parse the plain / text output
   # manually.
-  showmap_cmd = [constants.RBD_CMD, "showmapped", "-p", pool]
+  showmap_cmd = cls.MakeRbdCmd({}, ["showmapped", "-p", pool])
   result = utils.RunCmd(showmap_cmd)
   if result.failed:
 base.ThrowError("rbd showmapped failed (%s): %s",
@@ -1168,7 +1173,7 @@ class RADOSBlockDevice(base.BlockDev):
 
 if rbd_dev:
   # The mapping exists. Unmap the rbd device.
-  unmap_cmd = [constants.RBD_CMD, "unmap", "%s" % rbd_dev]
+  unmap_cmd = self.__class__.MakeRbdCmd(self.params, ["unmap", 
str(rbd_dev)])
   result = utils.RunCmd(unmap_cmd)
   if result.failed:
 base.ThrowError("rbd unmap failed (%s): %s",
@@ -1212,8 +1217,8 @@ class RADOSBlockDevice(base.BlockDev):
 new_size = self.size + amount
 
 # Resize the rbd volume (Image) inside the RADOS cluster.
-cmd = [constants.RBD_CMD, "resize", "-p", rbd_pool,
-   rbd_name, "--size", "%s" % new_size]
+cmd = self.__class__.MakeRbdCmd(self.params, ["resize", "-p", rbd_pool,
+   rbd_name, "--size", str(new_size)])
 result = utils.RunCmd(cmd)
 if result.failed:
   base.ThrowError("rbd resize failed (%s): %s",
@@ -1248,16 +1253,17 @@ class RADOSBlockDevice(base.BlockDev):
 self._UnmapVolumeFromBlockdev(self.unique_id)
 
 # Remove the actual Volume (Image) from the RADOS cluster.
-cmd = [constants.RBD_CMD, "rm", "-p", rbd_pool, rbd_name]
+cmd = self.__class__.MakeRbdCmd(self.params, ["rm", "-p", rbd

[PATCH master] Update documentation for rbd:user-id

[David Mohr]

Signed-off-by: David Mohr <da...@mcbf.net>
---
 doc/design-ceph-ganeti-support.rst |9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/doc/design-ceph-ganeti-support.rst 
b/doc/design-ceph-ganeti-support.rst
index 7ec865c..9bd939c 100644
--- a/doc/design-ceph-ganeti-support.rst
+++ b/doc/design-ceph-ganeti-support.rst
@@ -72,7 +72,14 @@ Updated commands
   $ gnt-instance info
 
 ``access:userspace/kernelspace`` will be added to Disks category. This
-output applies to KVM based instances only.
+output applies to KVM based instances only.::
+
+  $ gnt-cluster modify -D rbd:user-id=foobar
+
+The user id for ceph authentication is an optional setting. If it is not
+provided, then no special option is passed to ceph. If it is provided,
+then all ceph commands are run with the ``--user`` option and the
+configured username.
 
 Ceph configuration on Ganeti nodes
 ==
-- 
1.7.9.5

Bug#484575: nagios-nrpe-plugin is missing IPv6-Support

[David Mohr]

Should this be closed?

2.15 is in jessie and IPv6 is working fine for me.

~David

Re: [PATCH master] New configuration option for the rbd user id

[David Mohr]

On Tuesday, May 3, 2016 at 6:20:43 AM UTC-6, Brian Foley wrote:

> Hi David, 
>
> Thanks for the patch. 
>
> I'm afraid we don't use Ceph internally, so we don't really have a good 
> way 
> of testing this. I assume you've tested it and it's working for you 
> locally. 
>

 Hi Brian,

thank you for evaluating the patch and giving me some feedback. Yes, we are 
using this patch internally and it is working well for us.

I hope the small patch update that I sent is appropriate, of course I will 
send a squashed patch once everything is fixed.
>> @@ -1284,7 +1292,10 @@ class RADOSBlockDevice(base.BlockDev): 

> >   
> >  """ 
> >  if hypervisor == constants.HT_KVM: 
> > -  return "rbd:" + self.rbd_pool + "/" + self.rbd_name 
> > +  uri = "rbd:" + self.rbd_pool + "/" + self.rbd_name 
> > +  if constants.RBD_USER_ID in self.params and 
> self.params[constants.RBD_USER_ID]: 
> > +uri += ":id=%s" % self.params[constants.RBD_USER_ID] 
> > +  return uri 
>
> A question here about escaping parameters. What happens if the RBD pool, 
> device names, or user id have a : or = in them? Does ceph have a defined 
> escaping mechanism for this? Should we be using it? 
>

As far as I can tell these are valid characters for ceph. I'm not sure what 
the best mechanism would be to escape them in ganeti. Maybe a note in the 
documenation would be appropriate that these characters are not supported 
as part of the user id. While not idea, this doesn't seem overly 
restrictive to me.

Speaking of documentation, my patch is obviously lacking that so far. Any 
pointers for me where in the source tree I'd need to add that to?
 

>
> >  else: 
> >base.ThrowError("Hypervisor %s doesn't support RBD userspace 
> access" % 
> >hypervisor) 
> > diff --git a/src/Ganeti/Constants.hs b/src/Ganeti/Constants.hs 
> > index 09ca78d..c186877 100644 
> > --- a/src/Ganeti/Constants.hs 
> > +++ b/src/Ganeti/Constants.hs 
> > @@ -2330,6 +2330,9 @@ ldpPlanAhead = "c-plan-ahead" 
> >  ldpPool :: String 
> >  ldpPool = "pool" 
> >   
> > +ldpUserId :: String 
> > +ldpUserId = "user-id" 
> > + 
> >  ldpProtocol :: String 
> >  ldpProtocol = "protocol" 
> >   
> > @@ -2357,7 +2360,8 @@ diskLdTypes = 
> > (ldpDelayTarget, VTypeInt), 
> > (ldpMaxRate, VTypeInt), 
> > (ldpMinRate, VTypeInt), 
> > -   (ldpPool, VTypeString)] 
> > +   (ldpPool, VTypeString), 
> > +   (ldpUserId, VTypeString)] 
> >   
> >  diskLdParameters :: FrozenSet String 
> >  diskLdParameters = ConstantUtils.mkSet (Map.keys diskLdTypes) 
> > @@ -2418,6 +2422,9 @@ lvStripes = "stripes" 
> >  rbdAccess :: String 
> >  rbdAccess = "access" 
> >   
> > +rbdUserId :: String 
> > +rbdUserId = "user-id" 
> > + 
> >  rbdPool :: String 
> >  rbdPool = "pool" 
> >   
> > @@ -2440,6 +2447,7 @@ diskDtTypes = 
> >  (drbdMinRate, VTypeInt), 
> >  (lvStripes, VTypeInt), 
> >  (rbdAccess, VTypeString), 
> > +(rbdUserId, VTypeString), 
> >  (rbdPool, VTypeString), 
> >  (glusterHost, VTypeString), 
> >  (glusterVolume, VTypeString), 
> > @@ -4240,6 +4248,9 @@ defaultPlanAhead = 20 
> >  defaultRbdPool :: String 
> >  defaultRbdPool = "rbd" 
> >   
> > +defaultRbdUserId :: String 
> > +defaultRbdUserId = "" 
> > + 
> >  diskLdDefaults :: Map DiskTemplate (Map String PyValueEx) 
> >  diskLdDefaults = 
> >Map.fromList 
> > @@ -4266,11 +4277,13 @@ diskLdDefaults = 
> >, (DTPlain, Map.fromList [(ldpStripes, PyValueEx lvmStripecount)]) 
> >, (DTRbd, Map.fromList 
> >  [ (ldpPool, PyValueEx defaultRbdPool) 
> > +, (ldpUserId, PyValueEx defaultRbdUserId) 
> >  , (ldpAccess, PyValueEx diskKernelspace) 
> >  ]) 
> >, (DTSharedFile, Map.empty) 
> >, (DTGluster, Map.fromList 
> >  [ (rbdAccess, PyValueEx diskKernelspace) 
> > +, (rbdUserId, PyValueEx defaultRbdUserId) 
> >  , (glusterHost, PyValueEx glusterHostDefault) 
> >  , (glusterVolume, PyValueEx glusterVolumeDefault) 
> >  , (glusterPort, PyValueEx glusterPortDefault) 
> > @@ -4301,16 +4314,19 @@ diskDtDefaults = 
> > ]) 
> >, (DTExt,Map.fromList 
> > [ (rbdAccess, PyValueEx diskKernelspace) 
> > +   , (rbdUserId, PyValueEx defaultRbdUserId) 
> > ]) 
> >, (DTFile,   Map.empty) 
> >, (DTPlain,  Map.fromList [(lvStripes, PyValueEx 
> lvmStripecount)]) 
> >, (DTRbd,Map.fromList 
> > [ (rbdPool, PyValueEx defaultRbdPool) 
> > , (rbdAccess, PyValueEx diskKernelspace) 
> > +   , (rbdUserId, PyValueEx defaultRbdUserId) 
> > ]) 
> >, (DTSharedFile, Map.empty) 
> >, (DTGluster, Map.fromList 
> >  [ (rbdAccess, PyValueEx 

[PATCH master] Patch based on Brian's suggestions

[David Mohr]

Signed-off-by: David Mohr <da...@mcbf.net>
---
 lib/storage/bdev.py |   11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/lib/storage/bdev.py b/lib/storage/bdev.py
index 4892ec2..94ded76 100644
--- a/lib/storage/bdev.py
+++ b/lib/storage/bdev.py
@@ -887,9 +887,8 @@ class RADOSBlockDevice(base.BlockDev):
 
   @classmethod
   def MakeRbdCmd(cls, params, cmd):
-if constants.RBD_USER_ID in params and params[constants.RBD_USER_ID]:
-  cmd.append("--id")
-  cmd.append("%s" % params[constants.RBD_USER_ID])
+if params.get(constants.RBD_USER_ID, ""):
+  cmd.extend(["--id", str(params[constants.RBD_USER_ID])])
 return [constants.RBD_CMD] + cmd
 
   @classmethod
@@ -911,7 +910,7 @@ class RADOSBlockDevice(base.BlockDev):
 
 # Provision a new rbd volume (Image) inside the RADOS cluster.
 cmd = cls.MakeRbdCmd(params, ["create", "-p", rbd_pool, rbd_name,
-  "--size", "%s" % size])
+  "--size", str(size)])
 result = utils.RunCmd(cmd)
 if result.failed:
   base.ThrowError("rbd creation failed (%s): %s",
@@ -1174,7 +1173,7 @@ class RADOSBlockDevice(base.BlockDev):
 
 if rbd_dev:
   # The mapping exists. Unmap the rbd device.
-  unmap_cmd = self.__class__.MakeRbdCmd(self.params, ["unmap", "%s" % 
rbd_dev])
+  unmap_cmd = self.__class__.MakeRbdCmd(self.params, ["unmap", 
str(rbd_dev)])
   result = utils.RunCmd(unmap_cmd)
   if result.failed:
 base.ThrowError("rbd unmap failed (%s): %s",
@@ -1219,7 +1218,7 @@ class RADOSBlockDevice(base.BlockDev):
 
 # Resize the rbd volume (Image) inside the RADOS cluster.
 cmd = self.__class__.MakeRbdCmd(self.params, ["resize", "-p", rbd_pool,
-   rbd_name, "--size", "%s" % new_size])
+   rbd_name, "--size", str(new_size)])
 result = utils.RunCmd(cmd)
 if result.failed:
   base.ThrowError("rbd resize failed (%s): %s",
-- 
1.7.9.5

[PATCH master] Configurable ceph authentication user id

[David Mohr]

On our cluster we did not want to deploy the ceph admin keyring everywhere, so
we created a new identity for ganeti. This patch adds the configuration option
to specify the user id to be passed to rbd commands.

Comments are welcome, I will update the patch as needed.

David Mohr (1):
  New configuration option for the rbd user id

 lib/storage/bdev.py |   45 -
 src/Ganeti/Constants.hs |   18 +-
 2 files changed, 45 insertions(+), 18 deletions(-)

-- 
1.7.9.5

[PATCH master] New configuration option for the rbd user id

[David Mohr]

The user id is used by ceph to determine the keyring to use for
authentication. By default the admin keyring is used, which may
not be desirable.

Signed-off-by: David Mohr <da...@mcbf.net>
---
 lib/storage/bdev.py |   45 -
 src/Ganeti/Constants.hs |   18 +-
 2 files changed, 45 insertions(+), 18 deletions(-)

diff --git a/lib/storage/bdev.py b/lib/storage/bdev.py
index e3a48de..4892ec2 100644
--- a/lib/storage/bdev.py
+++ b/lib/storage/bdev.py
@@ -886,6 +886,13 @@ class RADOSBlockDevice(base.BlockDev):
 self.Attach()
 
   @classmethod
+  def MakeRbdCmd(cls, params, cmd):
+if constants.RBD_USER_ID in params and params[constants.RBD_USER_ID]:
+  cmd.append("--id")
+  cmd.append("%s" % params[constants.RBD_USER_ID])
+return [constants.RBD_CMD] + cmd
+
+  @classmethod
   def Create(cls, unique_id, children, size, spindles, params, excl_stor,
  dyn_params, *args):
 """Create a new rbd device.
@@ -903,8 +910,8 @@ class RADOSBlockDevice(base.BlockDev):
 rbd_name = unique_id[1]
 
 # Provision a new rbd volume (Image) inside the RADOS cluster.
-cmd = [constants.RBD_CMD, "create", "-p", rbd_pool,
-   rbd_name, "--size", "%s" % size]
+cmd = cls.MakeRbdCmd(params, ["create", "-p", rbd_pool, rbd_name,
+  "--size", "%s" % size])
 result = utils.RunCmd(cmd)
 if result.failed:
   base.ThrowError("rbd creation failed (%s): %s",
@@ -928,7 +935,7 @@ class RADOSBlockDevice(base.BlockDev):
 self.Shutdown()
 
 # Remove the actual Volume (Image) from the RADOS cluster.
-cmd = [constants.RBD_CMD, "rm", "-p", rbd_pool, rbd_name]
+cmd = self.__class__.MakeRbdCmd(self.params, ["rm", "-p", rbd_pool, 
rbd_name])
 result = utils.RunCmd(cmd)
 if result.failed:
   base.ThrowError("Can't remove Volume from cluster with rbd rm: %s - %s",
@@ -987,7 +994,7 @@ class RADOSBlockDevice(base.BlockDev):
   return rbd_dev
 
 # The mapping doesn't exist. Create it.
-map_cmd = [constants.RBD_CMD, "map", "-p", pool, name]
+map_cmd = self.__class__.MakeRbdCmd(self.params, ["map", "-p", pool, name])
 result = utils.RunCmd(map_cmd)
 if result.failed:
   base.ThrowError("rbd map failed (%s): %s",
@@ -1017,14 +1024,13 @@ class RADOSBlockDevice(base.BlockDev):
 try:
   # Newer versions of the rbd tool support json output formatting. Use it
   # if available.
-  showmap_cmd = [
-constants.RBD_CMD,
+  showmap_cmd = cls.MakeRbdCmd({}, [
 "showmapped",
 "-p",
 pool,
 "--format",
 "json"
-]
+])
   result = utils.RunCmd(showmap_cmd)
   if result.failed:
 logging.error("rbd JSON output formatting returned error (%s): %s,"
@@ -1036,7 +1042,7 @@ class RADOSBlockDevice(base.BlockDev):
 except RbdShowmappedJsonError:
   # For older versions of rbd, we have to parse the plain / text output
   # manually.
-  showmap_cmd = [constants.RBD_CMD, "showmapped", "-p", pool]
+  showmap_cmd = cls.MakeRbdCmd({}, ["showmapped", "-p", pool])
   result = utils.RunCmd(showmap_cmd)
   if result.failed:
 base.ThrowError("rbd showmapped failed (%s): %s",
@@ -1168,7 +1174,7 @@ class RADOSBlockDevice(base.BlockDev):
 
 if rbd_dev:
   # The mapping exists. Unmap the rbd device.
-  unmap_cmd = [constants.RBD_CMD, "unmap", "%s" % rbd_dev]
+  unmap_cmd = self.__class__.MakeRbdCmd(self.params, ["unmap", "%s" % 
rbd_dev])
   result = utils.RunCmd(unmap_cmd)
   if result.failed:
 base.ThrowError("rbd unmap failed (%s): %s",
@@ -1212,8 +1218,8 @@ class RADOSBlockDevice(base.BlockDev):
 new_size = self.size + amount
 
 # Resize the rbd volume (Image) inside the RADOS cluster.
-cmd = [constants.RBD_CMD, "resize", "-p", rbd_pool,
-   rbd_name, "--size", "%s" % new_size]
+cmd = self.__class__.MakeRbdCmd(self.params, ["resize", "-p", rbd_pool,
+   rbd_name, "--size", "%s" % new_size])
 result = utils.RunCmd(cmd)
 if result.failed:
   base.ThrowError("rbd resize failed (%s): %s",
@@ -1248,16 +1254,17 @@ class RADOSBlockDevice(base.BlockDev):
 self._UnmapVolumeFromBlockdev(self.unique_id)
 
 # Remove the actual Volume (Image) from the RADOS cluster.
-cmd = [constants.RBD_CMD, "rm", "-p", rbd_pool, rbd_name]
+cmd = self.__class__.MakeRbdCmd(self.params, ["rm", "

Bug#822870: libiscsi2: Please update to new upstream release 1.15.0

[David Mohr]

Package: libiscsi2
Version: 1.12.0-2
Severity: wishlist

Dear Maintainer,

1.15.0 was released a couple of months ago [1], and it would be nice to
get it added to Debian. In particular it's used for qemu's iSCSI support
which needs that version for proper handling of timeouts.

Overall there don't seem to be any packaging changes necessary, although
I am not sure how the soname changes should be evaluated.

I can share my updated packaging but the changes are so minimal that I 
doubt it's worth the effort (I just removed the patches and updated the 
package name to reflect the new so version).


~David

[1]: https://github.com/sahlberg/libiscsi/releases

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

Kernel: Linux 4.2.0-0.bpo.1-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages libiscsi2 depends on:
ii  libc6  2.19-18+deb8u3
ii  multiarch-support  2.19-18+deb8u3

libiscsi2 recommends no packages.

libiscsi2 suggests no packages.

-- no debconf information

Bug#819961: nslcd: package upgrade fails in postinst due to uncommon characters in bindpw config parameter

[David Mohr]

Package: nslcd
Version: 0.9.4-3+deb8u1
Severity: important

Hi, the latest package update broke on my system:

---SNIP---
# apt-get -f install
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following package was automatically installed and is no longer required:
  libicu48
Use 'apt-get autoremove' to remove it.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
3 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Setting up nslcd (0.9.4-3+deb8u1) ...
sed: -e expression #1, char 87: unterminated address regex
dpkg: error processing package nslcd (--configure):
 subprocess installed post-installation script returned error exit status 1
dpkg: dependency problems prevent configuration of libnss-ldapd:amd64:
 libnss-ldapd:amd64 depends on nslcd (>= 0.9.0) | nslcd-2; however:
  Package nslcd is not configured yet.
  Package nslcd-2 is not installed.
  Package nslcd which provides nslcd-2 is not configured yet.

dpkg: error processing package libnss-ldapd:amd64 (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of libpam-ldapd:amd64:
 libpam-ldapd:amd64 depends on nslcd (>= 0.9.0) | nslcd-2; however:
  Package nslcd is not configured yet.
  Package nslcd-2 is not installed.
  Package nslcd which provides nslcd-2 is not configured yet.

dpkg: error processing package libpam-ldapd:amd64 (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 nslcd
 libnss-ldapd:amd64
 libpam-ldapd:amd64
E: Sub-process /usr/bin/dpkg returned an error code (1)
---SNAP--

This seems to be because the postinst script uses sed to update the
config file using sed, and my "bindpw" contains a ']' character. I am
not sure what the best solution is here, since there are a number of
characters which are interpreted as regex special characters. But the
package upgrade failing like this doesn't seem an acceptable state
either.

I know it's a weird password character but the generator program I used
at the time tried to be extra secure, I guess.

~David

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

Kernel: Linux 4.1.16-x86_64-jb1 (SMP w/3 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages nslcd depends on:
ii  adduser3.113+nmu3
ii  debconf [debconf-2.0]  1.5.56
ii  libc6  2.19-18+deb8u4
ii  libgssapi-krb5-2   1.12.1+dfsg-19+deb8u2
ii  libldap-2.4-2  2.4.40+dfsg-1+deb8u2

Versions of packages nslcd recommends:
ii  bind9-host [host]   1:9.9.5.dfsg-9+deb8u6
ii  ldap-utils  2.4.40+dfsg-1+deb8u2
iu  libnss-ldapd [libnss-ldap]  0.9.4-3+deb8u1
iu  libpam-ldapd [libpam-ldap]  0.9.4-3+deb8u1
pn  nslcd-utils 
ii  unscd [nscd]0.51-1+b2

Versions of packages nslcd suggests:
pn  kstart  

-- debconf information:
* nslcd/ldap-uris: ldap://localhost/
  nslcd/xdm-needs-restart:
  nslcd/ldap-sasl-realm:
  nslcd/ldap-starttls: false
  nslcd/ldap-cacertfile: /etc/ssl/certs/ca-certificates.crt
  nslcd/ldap-binddn: uid=pam,ou=sysusers,dc=de,dc=mcbf,dc=net
  nslcd/ldap-reqcert:
  nslcd/ldap-auth-type: simple
  nslcd/ldap-sasl-mech:
* libraries/restart-without-asking: false
  nslcd/ldap-sasl-authzid:
* nslcd/ldap-base: dc=de,dc=mcbf,dc=net
  nslcd/ldap-sasl-krb5-ccname: /var/run/nslcd/nslcd.tkt
* nslcd/restart-services: saslauthd postgresql exim4 dovecot danted cron
  nslcd/ldap-sasl-authcid:
* nslcd/restart-failed:
  nslcd/disable-screensaver:
  nslcd/ldap-sasl-secprops:

Bug#806842: lldb: Broken lldb man page

[David Mohr]

Package: lldb
Version: 1:3.6-32
Severity: normal

Dear Maintainer,

the man page of lldb just contains:

DESCRIPTION
ERROR:  ld.so:  object  'libfakeroot-sysv.so'  from LD_PRELOAD cannot be
preloaded (cannot open shared object file): ignored.
build-llvm/Release/bin/lldb: error while loading shared  libraries:
liblldb-3.6.so:  cannot open shared object file: No such file or directory

I was expecting a little more information here :-)

~David

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages lldb depends on:
ii  lldb-3.6  1:3.6.2-3

lldb recommends no packages.

lldb suggests no packages.

-- no debconf information

Bug#801921: gdm3: Broken greeter, maybe Unable to init server: Could not connect: Connection refused

[David Mohr]

Package: gdm3
Version: 3.18.0-2
Severity: normal

Dear Maintainer,

I ran a dist-upgrade yesterday (2015-10-14), shut down, and on booting
today it just fails with the strange graphical prompt "Oh no! Something
has gone wrong." and a 'Log Out' button even though I'm not logged in
yet and just expected to see the greeter.

I can't find anything useful in the logs. The output of
`journalctl -f` after starting the gdm3 service is attached below.

I installed lightdm instead, and it works without any issues.

Let me know if there's something I can try to debug this.

Thanks,
~David

---SNIP---
Oct 15 23:12:54 alucardo sudo[2817]: squisher : TTY=pts/1 ; PWD=/home/squisher 
; USER=root ; COMMAND=/bin/systemctl gdm3 start
Oct 15 23:12:54 alucardo sudo[2817]: pam_unix(sudo:session): session opened for 
user root by squisher(uid=0)
Oct 15 23:12:54 alucardo sudo[2817]: pam_unix(sudo:session): session closed for 
user root
Oct 15 23:12:58 alucardo sudo[2839]: squisher : TTY=pts/1 ; PWD=/home/squisher 
; USER=root ; COMMAND=/bin/systemctl start gdm3
Oct 15 23:12:58 alucardo sudo[2839]: pam_unix(sudo:session): session opened for 
user root by squisher(uid=0)
Oct 15 23:12:58 alucardo polkitd(authority=local)[1652]: Registered 
Authentication Agent for unix-process:2840:41106 (system bus name :1.47 
[/usr/bin/pkttyagent --notify-fd 4 --fallback], object path 
/org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8)
Oct 15 23:12:58 alucardo systemd[1]: Starting GNOME Display Manager...
Oct 15 23:12:58 alucardo systemd[1]: Started GNOME Display Manager.
Oct 15 23:12:58 alucardo sudo[2839]: pam_unix(sudo:session): session closed for 
user root
Oct 15 23:12:58 alucardo polkitd(authority=local)[1652]: Unregistered 
Authentication Agent for unix-process:2840:41106 (system bus name :1.47, object 
path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) 
(disconnected from bus)
Oct 15 23:12:58 alucardo gdm-launch-environment][2866]: 
pam_unix(gdm-launch-environment:session): session opened for user Debian-gdm by 
(uid=0)
Oct 15 23:12:58 alucardo systemd[1]: Created slice user-108.slice.
Oct 15 23:12:58 alucardo systemd[1]: Starting User Manager for UID 108...
Oct 15 23:12:58 alucardo systemd-logind[1263]: New session c3 of user 
Debian-gdm.
Oct 15 23:12:58 alucardo systemd[2882]: pam_unix(systemd-user:session): session 
opened for user Debian-gdm by (uid=0)
Oct 15 23:12:58 alucardo systemd[1]: Started Session c3 of user Debian-gdm.
Oct 15 23:12:58 alucardo systemd[2882]: Reached target Sockets.
Oct 15 23:12:58 alucardo systemd[2882]: Removed slice Root Slice.
Oct 15 23:12:58 alucardo systemd[2882]: Reached target Timers.
Oct 15 23:12:58 alucardo systemd[2882]: Reached target Paths.
Oct 15 23:12:58 alucardo systemd[2882]: Reached target Basic System.
Oct 15 23:12:58 alucardo systemd[2882]: Reached target Default.
Oct 15 23:12:58 alucardo systemd[2882]: Startup finished in 20ms.
Oct 15 23:12:58 alucardo systemd[1]: Started User Manager for UID 108.
Oct 15 23:12:58 alucardo console-kit-daemon[1837]: (process:2892): 
GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
Oct 15 23:12:58 alucardo console-kit-daemon[1837]: (process:2894): 
GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
Oct 15 23:12:58 alucardo console-kit-daemon[1837]: (process:2895): 
GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
Oct 15 23:12:58 alucardo gnome-session[2899]: Entering running state
Oct 15 23:12:58 alucardo gnome-session[2899]: Unable to init server: Could not 
connect: Connection refused
Oct 15 23:12:58 alucardo gnome-session[2899]: ** (gnome-session-failed:2905): 
WARNING **: Cannot open display:
Oct 15 23:12:59 alucardo gdm-launch-environment][2866]: 
pam_unix(gdm-launch-environment:session): session closed for user Debian-gdm
Oct 15 23:12:59 alucardo gdm3[2854]: GdmDisplay: display lasted 1.332457 seconds
Oct 15 23:12:59 alucardo systemd-logind[1263]: Removed session c3.
Oct 15 23:12:59 alucardo gdm3[2854]: Child process -2896 was already dead.
Oct 15 23:12:59 alucardo gdm3[2854]: Child process 2866 was already dead.
Oct 15 23:12:59 alucardo gdm3[2854]: Unable to kill session worker process
Oct 15 23:12:59 alucardo console-kit-daemon[1837]: (process:2914): 
GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
Oct 15 23:12:59 alucardo systemd[1]: Stopping User Manager for UID 108...
Oct 15 23:12:59 alucardo systemd[2882]: Created slice Root Slice.
Oct 15 23:12:59 alucardo systemd[2882]: Stopped target Default.
Oct 15 23:12:59 alucardo systemd[2882]: Stopped target Basic System.
Oct 15 23:12:59 alucardo systemd[2882]: Stopped target Paths.
Oct 15 23:12:59 alucardo systemd[2882]: Stopped target Timers.
Oct 15 23:12:59 alucardo systemd[2882]: Reached target Shutdown.
Oct 15 23:12:59 alucardo systemd[2882]: Starting Exit the Session...
Oct 15 23:12:59 alucardo systemd[2882]: Stopped target Sockets.
Oct 15 23:12:59 alucardo 

Bug#801240: ceph: Logrotate reload is broken (at least with systemd)

[David Mohr]

Package: ceph
Version: 0.94.3-1
Severity: important
Tags: patch

Dear Maintainer,

the logrotate script tries to detect the init system, but fails with
systemd because it finds invoke-rc.d, which is installed by default.

Upstream fixed this already in a pretty universal way (commit
c1b28591a2ba55abd644186938d440fc90743f15), could you please
include the attached patch with the next upload?

Thanks,
~David

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
diff --git a/src/logrotate.conf b/src/logrotate.conf
index 1833d55..50e7ee8 100644
--- a/src/logrotate.conf
+++ b/src/logrotate.conf
@@ -4,25 +4,7 @@
 compress
 sharedscripts
 postrotate
-if which invoke-rc.d > /dev/null 2>&1 && [ -x `which invoke-rc.d` ]; then
-invoke-rc.d ceph reload >/dev/null
-elif which service > /dev/null 2>&1 && [ -x `which service` ]; then
-service ceph reload >/dev/null
-fi
-# Possibly reload twice, but depending on ceph.conf the reload above may be a no-op
-if which initctl > /dev/null 2>&1 && [ -x `which initctl` ]; then
-for daemon in osd mon mds ; do
-  find -L /var/lib/ceph/$daemon/ -mindepth 1 -maxdepth 1 -regextype posix-egrep -regex '.*/[A-Za-z0-9]+-[A-Za-z0-9._-]+' -printf '%P\n' \
-| while read f; do
-if [ -e "/var/lib/ceph/$daemon/$f/done" -o -e "/var/lib/ceph/$daemon/$f/ready" ] && [ -e "/var/lib/ceph/$daemon/$f/upstart" ] && [ ! -e "/var/lib/ceph/$daemon/$f/sysvinit" ]; then
-  cluster="${f%%-*}"
-  id="${f#*-}"
-
-  initctl reload ceph-$daemon cluster="$cluster" id="$id" 2>/dev/null || :
-fi
-  done
-done
-fi
+killall -q -1 ceph-mon ceph-mds ceph-osd || true
 endscript
 missingok
 notifempty

Bug#799814: obnam tries to use fuse.Fuse, while the jessie version seems to be called fuse.FUSE

[David Mohr]

Package: obnam
Version: 1.8-1
Severity: important

Dear Maintainer,

I just installed obnam, and it seems to be completely broken in jessie?
Seems like a quick fix, but I wonder if I'm doing something wrong or is
really noone using it in jessie?

~David

(2095)-walter:~% obnam  
CRITICAL:root:Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/cliapp/app.py", line 174, in _run
self.enable_plugins()
  File "/usr/lib/python2.7/dist-packages/cliapp/app.py", line 503, in 
enable_plugins
for plugin in self.pluginmgr.plugins:
  File "/usr/lib/python2.7/dist-packages/cliapp/pluginmgr.py", line 75, in 
plugins
self._plugins = self.load_plugins()
  File "/usr/lib/python2.7/dist-packages/cliapp/pluginmgr.py", line 112, in 
load_plugins
for plugin in self.load_plugin_file(pathname):
  File "/usr/lib/python2.7/dist-packages/cliapp/pluginmgr.py", line 132, in 
load_plugin_file
('.py', 'r', imp.PY_SOURCE))
  File "/usr/lib/python2.7/dist-packages/obnamlib/plugins/fuse_plugin.py", line 
212, in 
class ObnamFuse(fuse.Fuse):
AttributeError: 'module' object has no attribute 'Fuse'

Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/cliapp/app.py", line 174, in _run
self.enable_plugins()
  File "/usr/lib/python2.7/dist-packages/cliapp/app.py", line 503, in 
enable_plugins
for plugin in self.pluginmgr.plugins:
  File "/usr/lib/python2.7/dist-packages/cliapp/pluginmgr.py", line 75, in 
plugins
self._plugins = self.load_plugins()
  File "/usr/lib/python2.7/dist-packages/cliapp/pluginmgr.py", line 112, in 
load_plugins
for plugin in self.load_plugin_file(pathname):
  File "/usr/lib/python2.7/dist-packages/cliapp/pluginmgr.py", line 132, in 
load_plugin_file
('.py', 'r', imp.PY_SOURCE))
  File "/usr/lib/python2.7/dist-packages/obnamlib/plugins/fuse_plugin.py", line 
212, in 
class ObnamFuse(fuse.Fuse):
AttributeError: 'module' object has no attribute 'Fuse'

% python
Python 2.7.9 (default, Mar  1 2015, 12:57:24) 
[GCC 4.9.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import fuse
>>> help(fuse)

>>> f = fuse.FUSE()
Traceback (most recent call last):
  File "", line 1, in 
TypeError: __init__() takes at least 3 arguments (1 given)
>>> fuse.FUSE

>>> 


-- System Information:
Debian Release: 8.1
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages obnam depends on:
ii  libc6 2.19-18
ii  python2.7.9-1
ii  python-cliapp 1.20140719-1
ii  python-fuse   2:0.2.1-10
ii  python-larch  1.20131130-1
ii  python-paramiko   1.15.1-1
ii  python-tracing0.8-1
ii  python-ttystatus  0.23-1

obnam recommends no packages.

obnam suggests no packages.

-- no debconf information

[Pkg-xfce-devel] Bug#770283: xfburn: No longer found in Stretch

[David Mohr]

retitle 770283 xfburn crashes when adding Data Composition files on ppc 
(32bit)

severity 770283 normal
tags 770283 + wontfix jessie
thanks

Hi Dan,

thanks for the report! My guess is that gtk fixed something, but we'll 
probably never find out... great to hear that the situation has improved 
for you though!


~David

On 2015-08-17 01:07, Dan DeVoto wrote:

Package: xfburn
Followup-For: Bug #770283

Dear Maintainer,

I no longer experience this bug in 0.5.4-1 in Debian Stretch. 
Everything

seems fine now.

Regards,

Dan


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: powerpc (ppc)

Kernel: Linux 4.1.0-1-powerpc
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages xfburn depends on:
ii  libburn41.3.2-1.1
ii  libc6   2.19-19
ii  libexo-1-0  0.10.6-1
ii  libgdk-pixbuf2.0-0  2.31.5-1
ii  libglib2.0-02.44.1-1.1
ii  libgstreamer-plugins-base1.0-0  1.4.5-2
ii  libgstreamer1.0-0   1.4.5-2
ii  libgtk2.0-0 2.24.28-1
ii  libgudev-1.0-0  230-2
ii  libisofs6   1.3.2-1.1
ii  libxfce4ui-1-0  4.12.1-2
ii  libxfce4util7   4.12.1-2

xfburn recommends no packages.

xfburn suggests no packages.

-- no debconf information


___
Pkg-xfce-devel mailing list
Pkg-xfce-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-xfce-devel

Bug#770283: xfburn: No longer found in Stretch

[David Mohr]

retitle 770283 xfburn crashes when adding Data Composition files on ppc 
(32bit)

severity 770283 normal
tags 770283 + wontfix jessie
thanks

Hi Dan,

thanks for the report! My guess is that gtk fixed something, but we'll 
probably never find out... great to hear that the situation has improved 
for you though!


~David

On 2015-08-17 01:07, Dan DeVoto wrote:

Package: xfburn
Followup-For: Bug #770283

Dear Maintainer,

I no longer experience this bug in 0.5.4-1 in Debian Stretch. 
Everything

seems fine now.

Regards,

Dan


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: powerpc (ppc)

Kernel: Linux 4.1.0-1-powerpc
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages xfburn depends on:
ii  libburn41.3.2-1.1
ii  libc6   2.19-19
ii  libexo-1-0  0.10.6-1
ii  libgdk-pixbuf2.0-0  2.31.5-1
ii  libglib2.0-02.44.1-1.1
ii  libgstreamer-plugins-base1.0-0  1.4.5-2
ii  libgstreamer1.0-0   1.4.5-2
ii  libgtk2.0-0 2.24.28-1
ii  libgudev-1.0-0  230-2
ii  libisofs6   1.3.2-1.1
ii  libxfce4ui-1-0  4.12.1-2
ii  libxfce4util7   4.12.1-2

xfburn recommends no packages.

xfburn suggests no packages.

-- no debconf information

Re: [Operators] Please enable Forward Secrecy for your servers!

[David Mohr]

I second this a little bit.

In my case I need to upgrade from Debian wheezy to jessie to get PFS, so 
there is more work involved. And I'd expect a decent number of servers 
to be in the same situation. Jessie came out in April, so it's not brand 
new. But it is still fairly recent and you can't just expect everyone to 
have upgraded already.


On the other hand, there will never be a perfect time to make such a 
switch and I do appreciate the push for more security.


~David

On 2015-07-27 07:46, Eric Koldeweij wrote:
Yes, my server would be one of those who cannot reach jabber.ccc.de any 
more.
I did not get around to turning it on yet, I need a software upgrade 
for that.


I understand the need for extra security but enforcing it right away
without giving fellow operators time to upgrade as well will only hurt
the community. I thought I had until end of september for this.

Not happy.

Eric.

On 07/27/15 15:07, Peter Schwindt wrote:

Hi Mike,

On 07/10/2015 01:11 PM, Mike Barnes wrote:


Do you have any details on which client software and versions you've
tested, Mathias? I've been looking at doing this but I've been more
concerned about the client experience than s2s issues.

At jabber.ccc.de, I had (forcing Forward Secrecy for a week now) not a
single person experiencing (and messaging me about it) client issues.

But, and that's quite a lot more than Mathias observed, we're missing
about 1/3 of all the S2S connections.

Best,
Peter

Re: [ANNOUNCE] bcachefs!

[David Mohr]

On 2015-07-13 18:58, Kent Overstreet wrote:
Short announcement, because I'm in the process of moving - but I wanted 
to get
this out there because the code is up and I think it's reasonably 
stable right

now.

Bcachefs is a posix filesystem that I've been working towards for - 
well, quite
awhile now: it's intended as a competitor/replacement for 
ext4/xfs/btrfs.


Current features
 - multiple devices
 - replication
 - tiering
 - data checksumming and compression (zlib only; also the code doesn't 
work with

   tiering yet)
 - most of the normal posix fs features (no fallocate or quotas yet)

Planned features:
 - snapshots!
 - erasure coding
 - more

There will be a longer announcement on LKML/linux-fs in the near future 
(after
I'm finished moving) - but I'd like to get it a bit more testing from a 
wider

audience first, if possible.


Hi Kent,

one quick question about the roadmap at this point: As far as I 
understand bcachefs basically integrates bcache features directly in the 
filesystem. So does this deprecate bcache itself in your opinion? Bcache 
is obviously still useful for other FS, but I just want to know how 
things will get maintained in the future.


I wanted to suggest / possibly start implementing bcache support for the 
debian installer - obviously that only makes sense if I can expect it to 
be in the mainline kernel for the foreseeable future :-).


Thanks,
~David
--
To unsubscribe from this list: send the line unsubscribe linux-bcache in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Bug#791491: lives: Crashes on startup

[David Mohr]

On 2015-07-11 10:24, Sebastian Ramacher wrote:

On 2015-07-05 10:29:47, David Mohr wrote:
LiVES info: Invalid effect 
farneback_analyserfarneback_analysersalsaman1 found in compound effect 
image_stabilizer, line 4


LiVES info: Invalid effect 
farneback_analyserfarneback_analysersalsaman1 found in compound effect 
motion_analyser, line 4


**
Gtk:ERROR:/build/gtk+3.0-8FBlWQ/gtk+3.0-3.16.4/./gtk/gtkprogressbar.c:609:tick_cb: 
assertion failed: (priv-pulse2  priv-pulse1)


I'm unable to reproduce the issue. Are you using a special theme or 
something

that could mess with GTK+?


I selected NOX in xfce4-settings-manager. AFAIK that's gtk2 though, gtk3 
applications have this ugly white/grayish theme. I don't know of a 
better way to check.


lives 2.4.0~ds0-1 should hit the archive any minute. Is this issue 
reproducible

with the new upstream version?


I don't see it yet, will report on it later.

When reporting crashes, please include details of your operating 
system, distribution, and the LiVES version (2.2.8)

and any information shown below:

#0  0x7fb3543974c9 in __libc_waitpid (pid=873, 
stat_loc=stat_loc@entry=0x7ffefeee664c, options=options@entry=0) at 
../sysdeps/unix/sysv/linux/waitpid.c:40
#1  0x7fb357057433 in g_on_error_stack_trace (prg_name=0x1104700 
/usr/lib/lives/lives-exe) at 
/tmp/buildd/glib2.0-2.44.1/./glib/gbacktrace.c:252

#2  0x0041ecd8 in  ()
#3  0x7fb3543978d0 in signal handler called ()
#4  0x7fb35400d107 in __GI_raise (sig=sig@entry=6)
#5  0x7fb35400e4e8 in __GI_abort () at abort.c:89
#6  0x7fb3570a7b55 in g_assertion_message 
(domain=domain@entry=0x7fb358d4b527 Gtk, 
file=file@entry=0x7fb358d9b2b0 
/build/gtk+3.0-8FBlWQ/gtk+3.0-3.16.4/./gtk/gtkprogressbar.c, 
line=line@entry=609, func=func@entry=0x7fb358d9b4b7 tick_cb, 
message=message@entry=0x2a47ec0 assertion failed: (priv-pulse2  
priv-pulse1)) at /tmp/buildd/glib2.0-2.44.1/./glib/gtestutils.c:2356
#7  0x7fb3570a7bea in g_assertion_message_expr 
(domain=0x7fb358d4b527 Gtk, file=0x7fb358d9b2b0 
/build/gtk+3.0-8FBlWQ/gtk+3.0-3.16.4/./gtk/gtkprogressbar.c, 
line=609, func=0x7fb358d9b4b7 tick_cb, expr=optimized out)
#8  0x7fb358c1ae6e in  () at 
/usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#9  0x7fb358d0cf44 in  () at 
/usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#10 0x7fb357358504 in _g_closure_invoke_va (closure=0x145aec0, 
return_value=0x0, instance=0x11052c0, args=0x7ffefeee70c8, 
n_params=optimized out, param_types=0x0) at 
/tmp/buildd/glib2.0-2.44.1/./gobject/gclosure.c:831
#11 0x7fb357371fa7 in g_signal_emit_valist 
(instance=instance@entry=0x11052c0, signal_id=signal_id@entry=139, 
detail=detail@entry=0, var_args=var_args@entry=0x7ffefeee70c8) at 
/tmp/buildd/glib2.0-2.44.1/./gobject/gsignal.c:3214
#12 0x7fb357372e4a in g_signal_emit_by_name (instance=0x11052c0, 
detailed_signal=0x7fb358792414 update)
#13 0x7fb35872c3bc in  () at 
/usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#14 0x7fb35871bcf8 in  () at 
/usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#15 0x7fb3570825e3 in g_timeout_dispatch (source=0x154f690, 
callback=optimized out, user_data=optimized out)

#16 0x7fb357081b4d in g_main_context_dispatch (context=0x10bd3f0)
#17 0x7fb357081b4d in g_main_context_dispatch 
(context=context@entry=0x10bd3f0) at 
/tmp/buildd/glib2.0-2.44.1/./glib/gmain.c:3737
#18 0x7fb357081f20 in g_main_context_iterate 
(context=context@entry=0x10bd3f0, block=block@entry=0, 
dispatch=dispatch@entry=1, self=optimized out)
#19 0x7fb357081fcc in g_main_context_iteration (context=0x10bd3f0, 
may_block=0) at /tmp/buildd/glib2.0-2.44.1/./glib/gmain.c:3869

#20 0x0041d531 in  ()
#21 0x004b6b34 in  ()
#22 0x00423b74 in  ()
#23 0x00424b3f in  ()
#24 0x7fb357081b4d in g_main_context_dispatch (context=0x10bd3f0)
#25 0x7fb357081b4d in g_main_context_dispatch 
(context=context@entry=0x10bd3f0) at 
/tmp/buildd/glib2.0-2.44.1/./glib/gmain.c:3737
#26 0x7fb357081f20 in g_main_context_iterate (context=0x10bd3f0, 
block=block@entry=1, dispatch=dispatch@entry=1, self=optimized out)

#27 0x7fb357082242 in g_main_loop_run (loop=0x11046a0)
#28 0x7fb358bc6a85 in gtk_main ()
#29 0x00417421 in main ()


Please install lives-dbg and libgtk-3-0-dbg so that we know what the 
missing

bits are.


Ah yes, should've done that right away. Funny thing is that with the two 
-dbg packages installed, I don't get a backtrace anymore!


(2120)-alucardo:~/tmp/lives% lives -debug

LiVES 2.2.8
Copyright 2002-2015 Gabriel Finch (salsa...@gmail.com) and others.
LiVES comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details.

LiVES info: Invalid effect farneback_analyserfarneback_analysersalsaman1 
found in compound effect image_stabilizer, line 4


LiVES info: Invalid effect farneback_analyserfarneback_analysersalsaman1 
found in compound effect motion_analyser

Bug#791491: lives: Crashes on startup

[David Mohr]

On 2015-07-11 10:24, Sebastian Ramacher wrote:

On 2015-07-05 10:29:47, David Mohr wrote:
LiVES info: Invalid effect 
farneback_analyserfarneback_analysersalsaman1 found in compound effect 
image_stabilizer, line 4


LiVES info: Invalid effect 
farneback_analyserfarneback_analysersalsaman1 found in compound effect 
motion_analyser, line 4


**
Gtk:ERROR:/build/gtk+3.0-8FBlWQ/gtk+3.0-3.16.4/./gtk/gtkprogressbar.c:609:tick_cb: 
assertion failed: (priv-pulse2  priv-pulse1)


I'm unable to reproduce the issue. Are you using a special theme or 
something

that could mess with GTK+?


I selected NOX in xfce4-settings-manager. AFAIK that's gtk2 though, gtk3 
applications have this ugly white/grayish theme. I don't know of a 
better way to check.


lives 2.4.0~ds0-1 should hit the archive any minute. Is this issue 
reproducible

with the new upstream version?


I don't see it yet, will report on it later.

When reporting crashes, please include details of your operating 
system, distribution, and the LiVES version (2.2.8)

and any information shown below:

#0  0x7fb3543974c9 in __libc_waitpid (pid=873, 
stat_loc=stat_loc@entry=0x7ffefeee664c, options=options@entry=0) at 
../sysdeps/unix/sysv/linux/waitpid.c:40
#1  0x7fb357057433 in g_on_error_stack_trace (prg_name=0x1104700 
/usr/lib/lives/lives-exe) at 
/tmp/buildd/glib2.0-2.44.1/./glib/gbacktrace.c:252

#2  0x0041ecd8 in  ()
#3  0x7fb3543978d0 in signal handler called ()
#4  0x7fb35400d107 in __GI_raise (sig=sig@entry=6)
#5  0x7fb35400e4e8 in __GI_abort () at abort.c:89
#6  0x7fb3570a7b55 in g_assertion_message 
(domain=domain@entry=0x7fb358d4b527 Gtk, 
file=file@entry=0x7fb358d9b2b0 
/build/gtk+3.0-8FBlWQ/gtk+3.0-3.16.4/./gtk/gtkprogressbar.c, 
line=line@entry=609, func=func@entry=0x7fb358d9b4b7 tick_cb, 
message=message@entry=0x2a47ec0 assertion failed: (priv-pulse2  
priv-pulse1)) at /tmp/buildd/glib2.0-2.44.1/./glib/gtestutils.c:2356
#7  0x7fb3570a7bea in g_assertion_message_expr 
(domain=0x7fb358d4b527 Gtk, file=0x7fb358d9b2b0 
/build/gtk+3.0-8FBlWQ/gtk+3.0-3.16.4/./gtk/gtkprogressbar.c, 
line=609, func=0x7fb358d9b4b7 tick_cb, expr=optimized out)
#8  0x7fb358c1ae6e in  () at 
/usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#9  0x7fb358d0cf44 in  () at 
/usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#10 0x7fb357358504 in _g_closure_invoke_va (closure=0x145aec0, 
return_value=0x0, instance=0x11052c0, args=0x7ffefeee70c8, 
n_params=optimized out, param_types=0x0) at 
/tmp/buildd/glib2.0-2.44.1/./gobject/gclosure.c:831
#11 0x7fb357371fa7 in g_signal_emit_valist 
(instance=instance@entry=0x11052c0, signal_id=signal_id@entry=139, 
detail=detail@entry=0, var_args=var_args@entry=0x7ffefeee70c8) at 
/tmp/buildd/glib2.0-2.44.1/./gobject/gsignal.c:3214
#12 0x7fb357372e4a in g_signal_emit_by_name (instance=0x11052c0, 
detailed_signal=0x7fb358792414 update)
#13 0x7fb35872c3bc in  () at 
/usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#14 0x7fb35871bcf8 in  () at 
/usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#15 0x7fb3570825e3 in g_timeout_dispatch (source=0x154f690, 
callback=optimized out, user_data=optimized out)

#16 0x7fb357081b4d in g_main_context_dispatch (context=0x10bd3f0)
#17 0x7fb357081b4d in g_main_context_dispatch 
(context=context@entry=0x10bd3f0) at 
/tmp/buildd/glib2.0-2.44.1/./glib/gmain.c:3737
#18 0x7fb357081f20 in g_main_context_iterate 
(context=context@entry=0x10bd3f0, block=block@entry=0, 
dispatch=dispatch@entry=1, self=optimized out)
#19 0x7fb357081fcc in g_main_context_iteration (context=0x10bd3f0, 
may_block=0) at /tmp/buildd/glib2.0-2.44.1/./glib/gmain.c:3869

#20 0x0041d531 in  ()
#21 0x004b6b34 in  ()
#22 0x00423b74 in  ()
#23 0x00424b3f in  ()
#24 0x7fb357081b4d in g_main_context_dispatch (context=0x10bd3f0)
#25 0x7fb357081b4d in g_main_context_dispatch 
(context=context@entry=0x10bd3f0) at 
/tmp/buildd/glib2.0-2.44.1/./glib/gmain.c:3737
#26 0x7fb357081f20 in g_main_context_iterate (context=0x10bd3f0, 
block=block@entry=1, dispatch=dispatch@entry=1, self=optimized out)

#27 0x7fb357082242 in g_main_loop_run (loop=0x11046a0)
#28 0x7fb358bc6a85 in gtk_main ()
#29 0x00417421 in main ()


Please install lives-dbg and libgtk-3-0-dbg so that we know what the 
missing

bits are.


Ah yes, should've done that right away. Funny thing is that with the two 
-dbg packages installed, I don't get a backtrace anymore!


(2120)-alucardo:~/tmp/lives% lives -debug

LiVES 2.2.8
Copyright 2002-2015 Gabriel Finch (salsa...@gmail.com) and others.
LiVES comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details.

LiVES info: Invalid effect farneback_analyserfarneback_analysersalsaman1 
found in compound effect image_stabilizer, line 4


LiVES info: Invalid effect farneback_analyserfarneback_analysersalsaman1 
found in compound effect motion_analyser

Bug#791491: lives: Crashes on startup

[David Mohr]

On 2015-07-11 10:24, Sebastian Ramacher wrote:

On 2015-07-05 10:29:47, David Mohr wrote:
LiVES info: Invalid effect 
farneback_analyserfarneback_analysersalsaman1 found in compound effect 
image_stabilizer, line 4


LiVES info: Invalid effect 
farneback_analyserfarneback_analysersalsaman1 found in compound effect 
motion_analyser, line 4


**
Gtk:ERROR:/build/gtk+3.0-8FBlWQ/gtk+3.0-3.16.4/./gtk/gtkprogressbar.c:609:tick_cb: 
assertion failed: (priv-pulse2  priv-pulse1)


I'm unable to reproduce the issue. Are you using a special theme or 
something

that could mess with GTK+?


I selected NOX in xfce4-settings-manager. AFAIK that's gtk2 though, gtk3 
applications have this ugly white/grayish theme. I don't know of a 
better way to check.


lives 2.4.0~ds0-1 should hit the archive any minute. Is this issue 
reproducible

with the new upstream version?


I don't see it yet, will report on it later.

When reporting crashes, please include details of your operating 
system, distribution, and the LiVES version (2.2.8)

and any information shown below:

#0  0x7fb3543974c9 in __libc_waitpid (pid=873, 
stat_loc=stat_loc@entry=0x7ffefeee664c, options=options@entry=0) at 
../sysdeps/unix/sysv/linux/waitpid.c:40
#1  0x7fb357057433 in g_on_error_stack_trace (prg_name=0x1104700 
/usr/lib/lives/lives-exe) at 
/tmp/buildd/glib2.0-2.44.1/./glib/gbacktrace.c:252

#2  0x0041ecd8 in  ()
#3  0x7fb3543978d0 in signal handler called ()
#4  0x7fb35400d107 in __GI_raise (sig=sig@entry=6)
#5  0x7fb35400e4e8 in __GI_abort () at abort.c:89
#6  0x7fb3570a7b55 in g_assertion_message 
(domain=domain@entry=0x7fb358d4b527 Gtk, 
file=file@entry=0x7fb358d9b2b0 
/build/gtk+3.0-8FBlWQ/gtk+3.0-3.16.4/./gtk/gtkprogressbar.c, 
line=line@entry=609, func=func@entry=0x7fb358d9b4b7 tick_cb, 
message=message@entry=0x2a47ec0 assertion failed: (priv-pulse2  
priv-pulse1)) at /tmp/buildd/glib2.0-2.44.1/./glib/gtestutils.c:2356
#7  0x7fb3570a7bea in g_assertion_message_expr 
(domain=0x7fb358d4b527 Gtk, file=0x7fb358d9b2b0 
/build/gtk+3.0-8FBlWQ/gtk+3.0-3.16.4/./gtk/gtkprogressbar.c, 
line=609, func=0x7fb358d9b4b7 tick_cb, expr=optimized out)
#8  0x7fb358c1ae6e in  () at 
/usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#9  0x7fb358d0cf44 in  () at 
/usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#10 0x7fb357358504 in _g_closure_invoke_va (closure=0x145aec0, 
return_value=0x0, instance=0x11052c0, args=0x7ffefeee70c8, 
n_params=optimized out, param_types=0x0) at 
/tmp/buildd/glib2.0-2.44.1/./gobject/gclosure.c:831
#11 0x7fb357371fa7 in g_signal_emit_valist 
(instance=instance@entry=0x11052c0, signal_id=signal_id@entry=139, 
detail=detail@entry=0, var_args=var_args@entry=0x7ffefeee70c8) at 
/tmp/buildd/glib2.0-2.44.1/./gobject/gsignal.c:3214
#12 0x7fb357372e4a in g_signal_emit_by_name (instance=0x11052c0, 
detailed_signal=0x7fb358792414 update)
#13 0x7fb35872c3bc in  () at 
/usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#14 0x7fb35871bcf8 in  () at 
/usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#15 0x7fb3570825e3 in g_timeout_dispatch (source=0x154f690, 
callback=optimized out, user_data=optimized out)

#16 0x7fb357081b4d in g_main_context_dispatch (context=0x10bd3f0)
#17 0x7fb357081b4d in g_main_context_dispatch 
(context=context@entry=0x10bd3f0) at 
/tmp/buildd/glib2.0-2.44.1/./glib/gmain.c:3737
#18 0x7fb357081f20 in g_main_context_iterate 
(context=context@entry=0x10bd3f0, block=block@entry=0, 
dispatch=dispatch@entry=1, self=optimized out)
#19 0x7fb357081fcc in g_main_context_iteration (context=0x10bd3f0, 
may_block=0) at /tmp/buildd/glib2.0-2.44.1/./glib/gmain.c:3869

#20 0x0041d531 in  ()
#21 0x004b6b34 in  ()
#22 0x00423b74 in  ()
#23 0x00424b3f in  ()
#24 0x7fb357081b4d in g_main_context_dispatch (context=0x10bd3f0)
#25 0x7fb357081b4d in g_main_context_dispatch 
(context=context@entry=0x10bd3f0) at 
/tmp/buildd/glib2.0-2.44.1/./glib/gmain.c:3737
#26 0x7fb357081f20 in g_main_context_iterate (context=0x10bd3f0, 
block=block@entry=1, dispatch=dispatch@entry=1, self=optimized out)

#27 0x7fb357082242 in g_main_loop_run (loop=0x11046a0)
#28 0x7fb358bc6a85 in gtk_main ()
#29 0x00417421 in main ()


Please install lives-dbg and libgtk-3-0-dbg so that we know what the 
missing

bits are.


Ah yes, should've done that right away. Funny thing is that with the two 
-dbg packages installed, I don't get a backtrace anymore!


(2120)-alucardo:~/tmp/lives% lives -debug

LiVES 2.2.8
Copyright 2002-2015 Gabriel Finch (salsa...@gmail.com) and others.
LiVES comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details.

LiVES info: Invalid effect farneback_analyserfarneback_analysersalsaman1 
found in compound effect image_stabilizer, line 4


LiVES info: Invalid effect farneback_analyserfarneback_analysersalsaman1 
found in compound effect motion_analyser

Bug#791491: lives: Crashes on startup

[David Mohr]

Running it directly in gdb allows me to get a backtrace:

Reading symbols from /usr/lib/lives/lives-exe...Reading symbols from 
/usr/lib/debug/.build-id/4b/89b56dd51625e18b580231f82597f040d7c029.debug...done.

done.
(gdb) run
Starting program: /usr/lib/lives/lives-exe
[Thread debugging using libthread_db enabled]
Using host libthread_db library 
/lib/x86_64-linux-gnu/libthread_db.so.1.

[New Thread 0x7fffe71d4700 (LWP 29544)]

LiVES 2.2.8
Copyright 2002-2015 Gabriel Finch (salsa...@gmail.com) and others.
LiVES comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details.

LiVES info: Invalid effect farneback_analyserfarneback_analysersalsaman1 
found in compound effect image_stabilizer, line 4


LiVES info: Invalid effect farneback_analyserfarneback_analysersalsaman1 
found in compound effect motion_analyser, line 4


**
Gtk:ERROR:/build/gtk+3.0-VSpacm/gtk+3.0-3.16.5/./gtk/gtkprogressbar.c:609:tick_cb: 
assertion failed: (priv-pulse2  priv-pulse1)


Program received signal SIGABRT, Aborted.
0x72b9a107 in __GI_raise (sig=sig@entry=6) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:56

56  ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) thread apply all bt

Thread 2 (Thread 0x7fffe71d4700 (LWP 29544)):
#0  0x72c4253d in poll () at 
../sysdeps/unix/syscall-template.S:81
#1  0x75bc9ebc in g_main_context_iterate (priority=2147483647, 
n_fds=2, fds=0x7fffe00010c0, timeout=-1, context=0x10597e0) at 
/tmp/buildd/glib2.0-2.44.1/./glib/gmain.c:4103
#2  0x75bc9ebc in g_main_context_iterate (context=0x10597e0, 
block=block@entry=1, dispatch=dispatch@entry=1, self=optimized out) at 
/tmp/buildd/glib2.0-2.44.1/./glib/gmain.c:3803
#3  0x75bca242 in g_main_loop_run (loop=0x1059770) at 
/tmp/buildd/glib2.0-2.44.1/./glib/gmain.c:4002
#4  0x761c0af6 in gdbus_shared_thread_func (user_data=0x10597b0) 
at /tmp/buildd/glib2.0-2.44.1/./gio/gdbusprivate.c:274
#5  0x75bf0955 in g_thread_proxy (data=0x1046ca0) at 
/tmp/buildd/glib2.0-2.44.1/./glib/gthread.c:764
#6  0x72f160a4 in start_thread (arg=0x7fffe71d4700) at 
pthread_create.c:309
#7  0x72c4b07d in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:111


Thread 1 (Thread 0x77f18a80 (LWP 29522)):
#0  0x72b9a107 in __GI_raise (sig=sig@entry=6) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:56

#1  0x72b9b4e8 in __GI_abort () at abort.c:89
#2  0x75befb55 in g_assertion_message 
(domain=domain@entry=0x778777a7 Gtk, 
file=file@entry=0x778c7570 
/build/gtk+3.0-VSpacm/gtk+3.0-3.16.5/./gtk/gtkprogressbar.c, 
line=line@entry=609, func=func@entry=0x778c __FUNCTION__.52871 
tick_cb, message=message@entry=0x29da860 assertion failed: 
(priv-pulse2  priv-pulse1)) at 
/tmp/buildd/glib2.0-2.44.1/./glib/gtestutils.c:2356
#3  0x75befbea in g_assertion_message_expr 
(domain=domain@entry=0x778777a7 Gtk, 
file=file@entry=0x778c7570 
/build/gtk+3.0-VSpacm/gtk+3.0-3.16.5/./gtk/gtkprogressbar.c, 
line=line@entry=609, func=func@entry=0x778c __FUNCTION__.52871 
tick_cb, expr=expr@entry=0x778a027d priv-pulse2  priv-pulse1) 
at /tmp/buildd/glib2.0-2.44.1/./glib/gtestutils.c:2371
#4  0x7774706e in tick_cb (widget=0x123e1c0 [GtkProgressBar], 
frame_clock=optimized out, user_data=optimized out) at 
/build/gtk+3.0-VSpacm/gtk+3.0-3.16.5/./gtk/gtkprogressbar.c:609
#5  0x778391b4 in gtk_widget_on_frame_clock_update 
(frame_clock=0x10992c0 [GdkFrameClockIdle], widget=0x123e1c0 
[GtkProgressBar]) at 
/build/gtk+3.0-VSpacm/gtk+3.0-3.16.5/./gtk/gtkwidget.c:5299
#6  0x75e9f504 in _g_closure_invoke_va (closure=0x13e9660, 
return_value=0x0, instance=0x10992c0, args=0x7fffc618, 
n_params=optimized out, param_types=0x0)

at /tmp/buildd/glib2.0-2.44.1/./gobject/gclosure.c:831
#7  0x75eb8fa7 in g_signal_emit_valist 
(instance=instance@entry=0x10992c0, signal_id=signal_id@entry=139, 
detail=detail@entry=0, var_args=var_args@entry=0x7fffc618)

at /tmp/buildd/glib2.0-2.44.1/./gobject/gsignal.c:3214
#8  0x75eb9e4a in g_signal_emit_by_name 
(instance=instance@entry=0x10992c0, 
detailed_signal=detailed_signal@entry=0x772bc654 update) at 
/tmp/buildd/glib2.0-2.44.1/./gobject/gsignal.c:3401
#9  0x7725644c in gdk_frame_clock_paint_idle (data=0x10992c0) at 
/build/gtk+3.0-VSpacm/gtk+3.0-3.16.5/./gdk/gdkframeclockidle.c:380

zsh: segmentation fault  gdb /usr/lib/lives/lives-exe

It crashed when the startup window said Loading realtime effect 
plugins...


Not sure why the bt kills gdb... (but fyi, no other odd crashes on my 
system).


~David

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#791491: lives: Crashes on startup

[David Mohr]

Running it directly in gdb allows me to get a backtrace:

Reading symbols from /usr/lib/lives/lives-exe...Reading symbols from 
/usr/lib/debug/.build-id/4b/89b56dd51625e18b580231f82597f040d7c029.debug...done.

done.
(gdb) run
Starting program: /usr/lib/lives/lives-exe
[Thread debugging using libthread_db enabled]
Using host libthread_db library 
/lib/x86_64-linux-gnu/libthread_db.so.1.

[New Thread 0x7fffe71d4700 (LWP 29544)]

LiVES 2.2.8
Copyright 2002-2015 Gabriel Finch (salsa...@gmail.com) and others.
LiVES comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details.

LiVES info: Invalid effect farneback_analyserfarneback_analysersalsaman1 
found in compound effect image_stabilizer, line 4


LiVES info: Invalid effect farneback_analyserfarneback_analysersalsaman1 
found in compound effect motion_analyser, line 4


**
Gtk:ERROR:/build/gtk+3.0-VSpacm/gtk+3.0-3.16.5/./gtk/gtkprogressbar.c:609:tick_cb: 
assertion failed: (priv-pulse2  priv-pulse1)


Program received signal SIGABRT, Aborted.
0x72b9a107 in __GI_raise (sig=sig@entry=6) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:56

56  ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) thread apply all bt

Thread 2 (Thread 0x7fffe71d4700 (LWP 29544)):
#0  0x72c4253d in poll () at 
../sysdeps/unix/syscall-template.S:81
#1  0x75bc9ebc in g_main_context_iterate (priority=2147483647, 
n_fds=2, fds=0x7fffe00010c0, timeout=-1, context=0x10597e0) at 
/tmp/buildd/glib2.0-2.44.1/./glib/gmain.c:4103
#2  0x75bc9ebc in g_main_context_iterate (context=0x10597e0, 
block=block@entry=1, dispatch=dispatch@entry=1, self=optimized out) at 
/tmp/buildd/glib2.0-2.44.1/./glib/gmain.c:3803
#3  0x75bca242 in g_main_loop_run (loop=0x1059770) at 
/tmp/buildd/glib2.0-2.44.1/./glib/gmain.c:4002
#4  0x761c0af6 in gdbus_shared_thread_func (user_data=0x10597b0) 
at /tmp/buildd/glib2.0-2.44.1/./gio/gdbusprivate.c:274
#5  0x75bf0955 in g_thread_proxy (data=0x1046ca0) at 
/tmp/buildd/glib2.0-2.44.1/./glib/gthread.c:764
#6  0x72f160a4 in start_thread (arg=0x7fffe71d4700) at 
pthread_create.c:309
#7  0x72c4b07d in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:111


Thread 1 (Thread 0x77f18a80 (LWP 29522)):
#0  0x72b9a107 in __GI_raise (sig=sig@entry=6) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:56

#1  0x72b9b4e8 in __GI_abort () at abort.c:89
#2  0x75befb55 in g_assertion_message 
(domain=domain@entry=0x778777a7 Gtk, 
file=file@entry=0x778c7570 
/build/gtk+3.0-VSpacm/gtk+3.0-3.16.5/./gtk/gtkprogressbar.c, 
line=line@entry=609, func=func@entry=0x778c __FUNCTION__.52871 
tick_cb, message=message@entry=0x29da860 assertion failed: 
(priv-pulse2  priv-pulse1)) at 
/tmp/buildd/glib2.0-2.44.1/./glib/gtestutils.c:2356
#3  0x75befbea in g_assertion_message_expr 
(domain=domain@entry=0x778777a7 Gtk, 
file=file@entry=0x778c7570 
/build/gtk+3.0-VSpacm/gtk+3.0-3.16.5/./gtk/gtkprogressbar.c, 
line=line@entry=609, func=func@entry=0x778c __FUNCTION__.52871 
tick_cb, expr=expr@entry=0x778a027d priv-pulse2  priv-pulse1) 
at /tmp/buildd/glib2.0-2.44.1/./glib/gtestutils.c:2371
#4  0x7774706e in tick_cb (widget=0x123e1c0 [GtkProgressBar], 
frame_clock=optimized out, user_data=optimized out) at 
/build/gtk+3.0-VSpacm/gtk+3.0-3.16.5/./gtk/gtkprogressbar.c:609
#5  0x778391b4 in gtk_widget_on_frame_clock_update 
(frame_clock=0x10992c0 [GdkFrameClockIdle], widget=0x123e1c0 
[GtkProgressBar]) at 
/build/gtk+3.0-VSpacm/gtk+3.0-3.16.5/./gtk/gtkwidget.c:5299
#6  0x75e9f504 in _g_closure_invoke_va (closure=0x13e9660, 
return_value=0x0, instance=0x10992c0, args=0x7fffc618, 
n_params=optimized out, param_types=0x0)

at /tmp/buildd/glib2.0-2.44.1/./gobject/gclosure.c:831
#7  0x75eb8fa7 in g_signal_emit_valist 
(instance=instance@entry=0x10992c0, signal_id=signal_id@entry=139, 
detail=detail@entry=0, var_args=var_args@entry=0x7fffc618)

at /tmp/buildd/glib2.0-2.44.1/./gobject/gsignal.c:3214
#8  0x75eb9e4a in g_signal_emit_by_name 
(instance=instance@entry=0x10992c0, 
detailed_signal=detailed_signal@entry=0x772bc654 update) at 
/tmp/buildd/glib2.0-2.44.1/./gobject/gsignal.c:3401
#9  0x7725644c in gdk_frame_clock_paint_idle (data=0x10992c0) at 
/build/gtk+3.0-VSpacm/gtk+3.0-3.16.5/./gdk/gdkframeclockidle.c:380

zsh: segmentation fault  gdb /usr/lib/lives/lives-exe

It crashed when the startup window said Loading realtime effect 
plugins...


Not sure why the bt kills gdb... (but fyi, no other odd crashes on my 
system).


~David


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

Bug#791491: lives: Crashes on startup

[David Mohr]

Running it directly in gdb allows me to get a backtrace:

Reading symbols from /usr/lib/lives/lives-exe...Reading symbols from 
/usr/lib/debug/.build-id/4b/89b56dd51625e18b580231f82597f040d7c029.debug...done.

done.
(gdb) run
Starting program: /usr/lib/lives/lives-exe
[Thread debugging using libthread_db enabled]
Using host libthread_db library 
/lib/x86_64-linux-gnu/libthread_db.so.1.

[New Thread 0x7fffe71d4700 (LWP 29544)]

LiVES 2.2.8
Copyright 2002-2015 Gabriel Finch (salsa...@gmail.com) and others.
LiVES comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details.

LiVES info: Invalid effect farneback_analyserfarneback_analysersalsaman1 
found in compound effect image_stabilizer, line 4


LiVES info: Invalid effect farneback_analyserfarneback_analysersalsaman1 
found in compound effect motion_analyser, line 4


**
Gtk:ERROR:/build/gtk+3.0-VSpacm/gtk+3.0-3.16.5/./gtk/gtkprogressbar.c:609:tick_cb: 
assertion failed: (priv-pulse2  priv-pulse1)


Program received signal SIGABRT, Aborted.
0x72b9a107 in __GI_raise (sig=sig@entry=6) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:56

56  ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) thread apply all bt

Thread 2 (Thread 0x7fffe71d4700 (LWP 29544)):
#0  0x72c4253d in poll () at 
../sysdeps/unix/syscall-template.S:81
#1  0x75bc9ebc in g_main_context_iterate (priority=2147483647, 
n_fds=2, fds=0x7fffe00010c0, timeout=-1, context=0x10597e0) at 
/tmp/buildd/glib2.0-2.44.1/./glib/gmain.c:4103
#2  0x75bc9ebc in g_main_context_iterate (context=0x10597e0, 
block=block@entry=1, dispatch=dispatch@entry=1, self=optimized out) at 
/tmp/buildd/glib2.0-2.44.1/./glib/gmain.c:3803
#3  0x75bca242 in g_main_loop_run (loop=0x1059770) at 
/tmp/buildd/glib2.0-2.44.1/./glib/gmain.c:4002
#4  0x761c0af6 in gdbus_shared_thread_func (user_data=0x10597b0) 
at /tmp/buildd/glib2.0-2.44.1/./gio/gdbusprivate.c:274
#5  0x75bf0955 in g_thread_proxy (data=0x1046ca0) at 
/tmp/buildd/glib2.0-2.44.1/./glib/gthread.c:764
#6  0x72f160a4 in start_thread (arg=0x7fffe71d4700) at 
pthread_create.c:309
#7  0x72c4b07d in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:111


Thread 1 (Thread 0x77f18a80 (LWP 29522)):
#0  0x72b9a107 in __GI_raise (sig=sig@entry=6) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:56

#1  0x72b9b4e8 in __GI_abort () at abort.c:89
#2  0x75befb55 in g_assertion_message 
(domain=domain@entry=0x778777a7 Gtk, 
file=file@entry=0x778c7570 
/build/gtk+3.0-VSpacm/gtk+3.0-3.16.5/./gtk/gtkprogressbar.c, 
line=line@entry=609, func=func@entry=0x778c __FUNCTION__.52871 
tick_cb, message=message@entry=0x29da860 assertion failed: 
(priv-pulse2  priv-pulse1)) at 
/tmp/buildd/glib2.0-2.44.1/./glib/gtestutils.c:2356
#3  0x75befbea in g_assertion_message_expr 
(domain=domain@entry=0x778777a7 Gtk, 
file=file@entry=0x778c7570 
/build/gtk+3.0-VSpacm/gtk+3.0-3.16.5/./gtk/gtkprogressbar.c, 
line=line@entry=609, func=func@entry=0x778c __FUNCTION__.52871 
tick_cb, expr=expr@entry=0x778a027d priv-pulse2  priv-pulse1) 
at /tmp/buildd/glib2.0-2.44.1/./glib/gtestutils.c:2371
#4  0x7774706e in tick_cb (widget=0x123e1c0 [GtkProgressBar], 
frame_clock=optimized out, user_data=optimized out) at 
/build/gtk+3.0-VSpacm/gtk+3.0-3.16.5/./gtk/gtkprogressbar.c:609
#5  0x778391b4 in gtk_widget_on_frame_clock_update 
(frame_clock=0x10992c0 [GdkFrameClockIdle], widget=0x123e1c0 
[GtkProgressBar]) at 
/build/gtk+3.0-VSpacm/gtk+3.0-3.16.5/./gtk/gtkwidget.c:5299
#6  0x75e9f504 in _g_closure_invoke_va (closure=0x13e9660, 
return_value=0x0, instance=0x10992c0, args=0x7fffc618, 
n_params=optimized out, param_types=0x0)

at /tmp/buildd/glib2.0-2.44.1/./gobject/gclosure.c:831
#7  0x75eb8fa7 in g_signal_emit_valist 
(instance=instance@entry=0x10992c0, signal_id=signal_id@entry=139, 
detail=detail@entry=0, var_args=var_args@entry=0x7fffc618)

at /tmp/buildd/glib2.0-2.44.1/./gobject/gsignal.c:3214
#8  0x75eb9e4a in g_signal_emit_by_name 
(instance=instance@entry=0x10992c0, 
detailed_signal=detailed_signal@entry=0x772bc654 update) at 
/tmp/buildd/glib2.0-2.44.1/./gobject/gsignal.c:3401
#9  0x7725644c in gdk_frame_clock_paint_idle (data=0x10992c0) at 
/build/gtk+3.0-VSpacm/gtk+3.0-3.16.5/./gdk/gdkframeclockidle.c:380

zsh: segmentation fault  gdb /usr/lib/lives/lives-exe

It crashed when the startup window said Loading realtime effect 
plugins...


Not sure why the bt kills gdb... (but fyi, no other odd crashes on my 
system).


~David


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

Re: Bug#791964: gdm3: upgrade causes X session to be terminated

[David Mohr]

On 2015-07-10 10:46, Michael Biebl wrote:

Am 10.07.2015 um 18:38 schrieb Josh Triplett:

On Fri, Jul 10, 2015 at 02:37:49PM +0200, Michael Biebl wrote:
  * Systemd has been fixed in v222 to no longer kill services on 
reload

if BusName is set, so drop that part from 92_systemd_unit.patch.
but that is EXACTLY what happened to me right now, in the middle of


Right. Subsequent reloads of gdm3.service should no longer kill
gdm3.service though. So this was indeed fixed in v222 but there seems 
to

be a specific issue for the upgrade path.
Once gdm3 has been restarted, a reload no longer causes it to be 
killed.


Note, though, that it doesn't help for systemd to be upgraded first.
Even if running the new systemd 222, upgrading gdm3 kills the active
session.


Well, that's exactly what I said, right?


apt used this order on my system:

2015-07-09 12:05:33 status installed systemd:amd64 222-1
[...]
2015-07-09 12:05:46 status installed gdm3:amd64 3.14.2-1

___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#791964: gdm3: upgrade causes X session to be terminated

[David Mohr]

On 2015-07-10 10:46, Michael Biebl wrote:

Am 10.07.2015 um 18:38 schrieb Josh Triplett:

On Fri, Jul 10, 2015 at 02:37:49PM +0200, Michael Biebl wrote:
  * Systemd has been fixed in v222 to no longer kill services on 
reload

if BusName is set, so drop that part from 92_systemd_unit.patch.
but that is EXACTLY what happened to me right now, in the middle of


Right. Subsequent reloads of gdm3.service should no longer kill
gdm3.service though. So this was indeed fixed in v222 but there seems 
to

be a specific issue for the upgrade path.
Once gdm3 has been restarted, a reload no longer causes it to be 
killed.


Note, though, that it doesn't help for systemd to be upgraded first.
Even if running the new systemd 222, upgrading gdm3 kills the active
session.


Well, that's exactly what I said, right?


apt used this order on my system:

2015-07-09 12:05:33 status installed systemd:amd64 222-1
[...]
2015-07-09 12:05:46 status installed gdm3:amd64 3.14.2-1


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

Bug#791964: gdm3: upgrade causes X session to be terminated

[David Mohr]

On 2015-07-10 10:46, Michael Biebl wrote:

Am 10.07.2015 um 18:38 schrieb Josh Triplett:

On Fri, Jul 10, 2015 at 02:37:49PM +0200, Michael Biebl wrote:
  * Systemd has been fixed in v222 to no longer kill services on 
reload

if BusName is set, so drop that part from 92_systemd_unit.patch.
but that is EXACTLY what happened to me right now, in the middle of


Right. Subsequent reloads of gdm3.service should no longer kill
gdm3.service though. So this was indeed fixed in v222 but there seems 
to

be a specific issue for the upgrade path.
Once gdm3 has been restarted, a reload no longer causes it to be 
killed.


Note, though, that it doesn't help for systemd to be upgraded first.
Even if running the new systemd 222, upgrading gdm3 kills the active
session.


Well, that's exactly what I said, right?


apt used this order on my system:

2015-07-09 12:05:33 status installed systemd:amd64 222-1
[...]
2015-07-09 12:05:46 status installed gdm3:amd64 3.14.2-1


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

Bug#791964: gdm3: upgrade causes X session to be terminated

[David Mohr]

Package: gdm3
Version: 3.14.2-1
Severity: normal

Dear Maintainer,

the changelog reads:
  * Systemd has been fixed in v222 to no longer kill services on reload
if BusName is set, so drop that part from 92_systemd_unit.patch.
but that is EXACTLY what happened to me right now, in the middle of
doing some work. That's highly unacceptable IMHO.

I ran an apt-get upgrade, and suddenly my X session closed and I was
brought back to the gdm login screen.

Pretty busy right now, but do let me know what could help to pinpoint
this issue and I'll try to provide more details.

~David

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages gdm3 depends on:
ii  accountsservice   0.6.40-2
ii  adduser   3.113+nmu3
ii  awesome [x-window-manager]3.5.6-1
ii  dconf-cli 0.24.0-2
ii  dconf-gsettings-backend   0.24.0-2
ii  debconf [debconf-2.0] 1.5.56
ii  gir1.2-gdm3   3.14.2-1
ii  gnome-session-bin 3.16.0-1
ii  gnome-settings-daemon 3.16.2-3
ii  gnome-shell   3.16.3-1
ii  gsettings-desktop-schemas 3.16.1-1
ii  libaccountsservice0   0.6.40-2
ii  libaudit1 1:2.4.2-1
ii  libc6 2.19-18
ii  libcanberra-gtk3-00.30-2.1
ii  libcanberra0  0.30-2.1
ii  libgdk-pixbuf2.0-02.31.4-2
ii  libgdm1   3.14.2-1
it  libglib2.0-0  2.44.1-1.1
ii  libglib2.0-bin2.44.1-1.1
iu  libgtk-3-03.16.5-1
ii  libpam-modules1.1.8-3.1
ii  libpam-runtime1.1.8-3.1
ii  libpam-systemd222-1
ii  libpam0g  1.1.8-3.1
ii  librsvg2-common   2.40.9-2
ii  libselinux1   2.3-2+b1
ii  libsystemd0   222-1
ii  libwrap0  7.6.q-25
ii  libx11-6  2:1.6.3-1
ii  libxau6   1:1.0.8-1
ii  libxdmcp6 1:1.1.2-1
ii  libxrandr22:1.4.2-1+b1
ii  lsb-base  4.1+Debian13+nmu1
iu  metacity [x-window-manager]   1:3.17.2-4
ii  mutter [x-window-manager] 3.16.3-1
ii  policykit-1   0.105-10
ii  rxvt [x-terminal-emulator]1:2.7.10-6
ii  ucf   3.0030
ii  x11-common1:7.7+9
ii  x11-xserver-utils 7.7+4
ii  xfce4-session [x-session-manager] 4.12.1-3
ii  xfce4-terminal [x-terminal-emulator]  0.6.3-1+b2
ii  xfwm4 [x-window-manager]  4.12.3-1
ii  xterm [x-terminal-emulator]   318-2

Versions of packages gdm3 recommends:
ii  at-spi2-core   2.16.0-1
ii  desktop-base   8.0.2
ii  gnome-icon-theme   3.12.0-1
ii  gnome-icon-theme-symbolic  3.12.0-1
ii  x11-xkb-utils  7.7+2
ii  xserver-xephyr 2:1.17.2-1
ii  xserver-xorg   1:7.7+9
ii  zenity 3.16.3-1

Versions of packages gdm3 suggests:
pn  gnome-orcanone
ii  libpam-gnome-keyring  3.16.0-4

-- debconf information:
* shared/default-x-display-manager: gdm3
  gdm3/daemon_name: /usr/sbin/gdm3


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

Bug#791491: lives: Crashes on startup

[David Mohr]

Package: lives
Version: 2.2.8~ds0-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

just wanted to give lives a shot, but it crashes immediately after the startup
dialog made some progress:


% lives -debug   

LiVES 2.2.8
Copyright 2002-2015 Gabriel Finch (salsa...@gmail.com) and others.
LiVES comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details.

LiVES info: Invalid effect farneback_analyserfarneback_analysersalsaman1 found 
in compound effect image_stabilizer, line 4

LiVES info: Invalid effect farneback_analyserfarneback_analysersalsaman1 found 
in compound effect motion_analyser, line 4

**
Gtk:ERROR:/build/gtk+3.0-8FBlWQ/gtk+3.0-3.16.4/./gtk/gtkprogressbar.c:609:tick_cb:
 assertion failed: (priv-pulse2  priv-pulse1)

Unfortunately LiVES crashed.
Please report this bug at 
http://sourceforge.net/tracker/?group_id=64341atid=507139
Thanks. Recovery should be possible if you restart LiVES.


When reporting crashes, please include details of your operating system, 
distribution, and the LiVES version (2.2.8)
and any information shown below:

#0  0x7fb3543974c9 in __libc_waitpid (pid=873, 
stat_loc=stat_loc@entry=0x7ffefeee664c, options=options@entry=0) at 
../sysdeps/unix/sysv/linux/waitpid.c:40
#1  0x7fb357057433 in g_on_error_stack_trace (prg_name=0x1104700 
/usr/lib/lives/lives-exe) at 
/tmp/buildd/glib2.0-2.44.1/./glib/gbacktrace.c:252
#2  0x0041ecd8 in  ()
#3  0x7fb3543978d0 in signal handler called ()
#4  0x7fb35400d107 in __GI_raise (sig=sig@entry=6)
#5  0x7fb35400e4e8 in __GI_abort () at abort.c:89
#6  0x7fb3570a7b55 in g_assertion_message 
(domain=domain@entry=0x7fb358d4b527 Gtk, file=file@entry=0x7fb358d9b2b0 
/build/gtk+3.0-8FBlWQ/gtk+3.0-3.16.4/./gtk/gtkprogressbar.c, 
line=line@entry=609, func=func@entry=0x7fb358d9b4b7 tick_cb, 
message=message@entry=0x2a47ec0 assertion failed: (priv-pulse2  
priv-pulse1)) at /tmp/buildd/glib2.0-2.44.1/./glib/gtestutils.c:2356
#7  0x7fb3570a7bea in g_assertion_message_expr (domain=0x7fb358d4b527 
Gtk, file=0x7fb358d9b2b0 
/build/gtk+3.0-8FBlWQ/gtk+3.0-3.16.4/./gtk/gtkprogressbar.c, line=609, 
func=0x7fb358d9b4b7 tick_cb, expr=optimized out)
#8  0x7fb358c1ae6e in  () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#9  0x7fb358d0cf44 in  () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#10 0x7fb357358504 in _g_closure_invoke_va (closure=0x145aec0, 
return_value=0x0, instance=0x11052c0, args=0x7ffefeee70c8, n_params=optimized 
out, param_types=0x0) at /tmp/buildd/glib2.0-2.44.1/./gobject/gclosure.c:831
#11 0x7fb357371fa7 in g_signal_emit_valist 
(instance=instance@entry=0x11052c0, signal_id=signal_id@entry=139, 
detail=detail@entry=0, var_args=var_args@entry=0x7ffefeee70c8) at 
/tmp/buildd/glib2.0-2.44.1/./gobject/gsignal.c:3214
#12 0x7fb357372e4a in g_signal_emit_by_name (instance=0x11052c0, 
detailed_signal=0x7fb358792414 update)
#13 0x7fb35872c3bc in  () at /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#14 0x7fb35871bcf8 in  () at /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#15 0x7fb3570825e3 in g_timeout_dispatch (source=0x154f690, 
callback=optimized out, user_data=optimized out)
#16 0x7fb357081b4d in g_main_context_dispatch (context=0x10bd3f0)
#17 0x7fb357081b4d in g_main_context_dispatch 
(context=context@entry=0x10bd3f0) at 
/tmp/buildd/glib2.0-2.44.1/./glib/gmain.c:3737
#18 0x7fb357081f20 in g_main_context_iterate 
(context=context@entry=0x10bd3f0, block=block@entry=0, 
dispatch=dispatch@entry=1, self=optimized out)
#19 0x7fb357081fcc in g_main_context_iteration (context=0x10bd3f0, 
may_block=0) at /tmp/buildd/glib2.0-2.44.1/./glib/gmain.c:3869
#20 0x0041d531 in  ()
#21 0x004b6b34 in  ()
#22 0x00423b74 in  ()
#23 0x00424b3f in  ()
#24 0x7fb357081b4d in g_main_context_dispatch (context=0x10bd3f0)
#25 0x7fb357081b4d in g_main_context_dispatch 
(context=context@entry=0x10bd3f0) at 
/tmp/buildd/glib2.0-2.44.1/./glib/gmain.c:3737
#26 0x7fb357081f20 in g_main_context_iterate (context=0x10bd3f0, 
block=block@entry=1, dispatch=dispatch@entry=1, self=optimized out)
#27 0x7fb357082242 in g_main_loop_run (loop=0x11046a0)
#28 0x7fb358bc6a85 in gtk_main ()
#29 0x00417421 in main ()


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages lives depends on:
ii  frei0r-plugins1:1.4-dmo4
ii  imagemagick   8:6.8.9.9-5
ii  libasound21.0.28-1
ii  libatk1.0-0   

Bug#791491: lives: Crashes on startup

[David Mohr]

Package: lives
Version: 2.2.8~ds0-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

just wanted to give lives a shot, but it crashes immediately after the startup
dialog made some progress:


% lives -debug   

LiVES 2.2.8
Copyright 2002-2015 Gabriel Finch (salsa...@gmail.com) and others.
LiVES comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details.

LiVES info: Invalid effect farneback_analyserfarneback_analysersalsaman1 found 
in compound effect image_stabilizer, line 4

LiVES info: Invalid effect farneback_analyserfarneback_analysersalsaman1 found 
in compound effect motion_analyser, line 4

**
Gtk:ERROR:/build/gtk+3.0-8FBlWQ/gtk+3.0-3.16.4/./gtk/gtkprogressbar.c:609:tick_cb:
 assertion failed: (priv-pulse2  priv-pulse1)

Unfortunately LiVES crashed.
Please report this bug at 
http://sourceforge.net/tracker/?group_id=64341atid=507139
Thanks. Recovery should be possible if you restart LiVES.


When reporting crashes, please include details of your operating system, 
distribution, and the LiVES version (2.2.8)
and any information shown below:

#0  0x7fb3543974c9 in __libc_waitpid (pid=873, 
stat_loc=stat_loc@entry=0x7ffefeee664c, options=options@entry=0) at 
../sysdeps/unix/sysv/linux/waitpid.c:40
#1  0x7fb357057433 in g_on_error_stack_trace (prg_name=0x1104700 
/usr/lib/lives/lives-exe) at 
/tmp/buildd/glib2.0-2.44.1/./glib/gbacktrace.c:252
#2  0x0041ecd8 in  ()
#3  0x7fb3543978d0 in signal handler called ()
#4  0x7fb35400d107 in __GI_raise (sig=sig@entry=6)
#5  0x7fb35400e4e8 in __GI_abort () at abort.c:89
#6  0x7fb3570a7b55 in g_assertion_message 
(domain=domain@entry=0x7fb358d4b527 Gtk, file=file@entry=0x7fb358d9b2b0 
/build/gtk+3.0-8FBlWQ/gtk+3.0-3.16.4/./gtk/gtkprogressbar.c, 
line=line@entry=609, func=func@entry=0x7fb358d9b4b7 tick_cb, 
message=message@entry=0x2a47ec0 assertion failed: (priv-pulse2  
priv-pulse1)) at /tmp/buildd/glib2.0-2.44.1/./glib/gtestutils.c:2356
#7  0x7fb3570a7bea in g_assertion_message_expr (domain=0x7fb358d4b527 
Gtk, file=0x7fb358d9b2b0 
/build/gtk+3.0-8FBlWQ/gtk+3.0-3.16.4/./gtk/gtkprogressbar.c, line=609, 
func=0x7fb358d9b4b7 tick_cb, expr=optimized out)
#8  0x7fb358c1ae6e in  () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#9  0x7fb358d0cf44 in  () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#10 0x7fb357358504 in _g_closure_invoke_va (closure=0x145aec0, 
return_value=0x0, instance=0x11052c0, args=0x7ffefeee70c8, n_params=optimized 
out, param_types=0x0) at /tmp/buildd/glib2.0-2.44.1/./gobject/gclosure.c:831
#11 0x7fb357371fa7 in g_signal_emit_valist 
(instance=instance@entry=0x11052c0, signal_id=signal_id@entry=139, 
detail=detail@entry=0, var_args=var_args@entry=0x7ffefeee70c8) at 
/tmp/buildd/glib2.0-2.44.1/./gobject/gsignal.c:3214
#12 0x7fb357372e4a in g_signal_emit_by_name (instance=0x11052c0, 
detailed_signal=0x7fb358792414 update)
#13 0x7fb35872c3bc in  () at /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#14 0x7fb35871bcf8 in  () at /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#15 0x7fb3570825e3 in g_timeout_dispatch (source=0x154f690, 
callback=optimized out, user_data=optimized out)
#16 0x7fb357081b4d in g_main_context_dispatch (context=0x10bd3f0)
#17 0x7fb357081b4d in g_main_context_dispatch 
(context=context@entry=0x10bd3f0) at 
/tmp/buildd/glib2.0-2.44.1/./glib/gmain.c:3737
#18 0x7fb357081f20 in g_main_context_iterate 
(context=context@entry=0x10bd3f0, block=block@entry=0, 
dispatch=dispatch@entry=1, self=optimized out)
#19 0x7fb357081fcc in g_main_context_iteration (context=0x10bd3f0, 
may_block=0) at /tmp/buildd/glib2.0-2.44.1/./glib/gmain.c:3869
#20 0x0041d531 in  ()
#21 0x004b6b34 in  ()
#22 0x00423b74 in  ()
#23 0x00424b3f in  ()
#24 0x7fb357081b4d in g_main_context_dispatch (context=0x10bd3f0)
#25 0x7fb357081b4d in g_main_context_dispatch 
(context=context@entry=0x10bd3f0) at 
/tmp/buildd/glib2.0-2.44.1/./glib/gmain.c:3737
#26 0x7fb357081f20 in g_main_context_iterate (context=0x10bd3f0, 
block=block@entry=1, dispatch=dispatch@entry=1, self=optimized out)
#27 0x7fb357082242 in g_main_loop_run (loop=0x11046a0)
#28 0x7fb358bc6a85 in gtk_main ()
#29 0x00417421 in main ()


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages lives depends on:
ii  frei0r-plugins1:1.4-dmo4
ii  imagemagick   8:6.8.9.9-5
ii  libasound21.0.28-1
ii  libatk1.0-0   

Bug#791491: lives: Crashes on startup

[David Mohr]

Package: lives
Version: 2.2.8~ds0-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

just wanted to give lives a shot, but it crashes immediately after the startup
dialog made some progress:


% lives -debug   

LiVES 2.2.8
Copyright 2002-2015 Gabriel Finch (salsa...@gmail.com) and others.
LiVES comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details.

LiVES info: Invalid effect farneback_analyserfarneback_analysersalsaman1 found 
in compound effect image_stabilizer, line 4

LiVES info: Invalid effect farneback_analyserfarneback_analysersalsaman1 found 
in compound effect motion_analyser, line 4

**
Gtk:ERROR:/build/gtk+3.0-8FBlWQ/gtk+3.0-3.16.4/./gtk/gtkprogressbar.c:609:tick_cb:
 assertion failed: (priv-pulse2  priv-pulse1)

Unfortunately LiVES crashed.
Please report this bug at 
http://sourceforge.net/tracker/?group_id=64341atid=507139
Thanks. Recovery should be possible if you restart LiVES.


When reporting crashes, please include details of your operating system, 
distribution, and the LiVES version (2.2.8)
and any information shown below:

#0  0x7fb3543974c9 in __libc_waitpid (pid=873, 
stat_loc=stat_loc@entry=0x7ffefeee664c, options=options@entry=0) at 
../sysdeps/unix/sysv/linux/waitpid.c:40
#1  0x7fb357057433 in g_on_error_stack_trace (prg_name=0x1104700 
/usr/lib/lives/lives-exe) at 
/tmp/buildd/glib2.0-2.44.1/./glib/gbacktrace.c:252
#2  0x0041ecd8 in  ()
#3  0x7fb3543978d0 in signal handler called ()
#4  0x7fb35400d107 in __GI_raise (sig=sig@entry=6)
#5  0x7fb35400e4e8 in __GI_abort () at abort.c:89
#6  0x7fb3570a7b55 in g_assertion_message 
(domain=domain@entry=0x7fb358d4b527 Gtk, file=file@entry=0x7fb358d9b2b0 
/build/gtk+3.0-8FBlWQ/gtk+3.0-3.16.4/./gtk/gtkprogressbar.c, 
line=line@entry=609, func=func@entry=0x7fb358d9b4b7 tick_cb, 
message=message@entry=0x2a47ec0 assertion failed: (priv-pulse2  
priv-pulse1)) at /tmp/buildd/glib2.0-2.44.1/./glib/gtestutils.c:2356
#7  0x7fb3570a7bea in g_assertion_message_expr (domain=0x7fb358d4b527 
Gtk, file=0x7fb358d9b2b0 
/build/gtk+3.0-8FBlWQ/gtk+3.0-3.16.4/./gtk/gtkprogressbar.c, line=609, 
func=0x7fb358d9b4b7 tick_cb, expr=optimized out)
#8  0x7fb358c1ae6e in  () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#9  0x7fb358d0cf44 in  () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#10 0x7fb357358504 in _g_closure_invoke_va (closure=0x145aec0, 
return_value=0x0, instance=0x11052c0, args=0x7ffefeee70c8, n_params=optimized 
out, param_types=0x0) at /tmp/buildd/glib2.0-2.44.1/./gobject/gclosure.c:831
#11 0x7fb357371fa7 in g_signal_emit_valist 
(instance=instance@entry=0x11052c0, signal_id=signal_id@entry=139, 
detail=detail@entry=0, var_args=var_args@entry=0x7ffefeee70c8) at 
/tmp/buildd/glib2.0-2.44.1/./gobject/gsignal.c:3214
#12 0x7fb357372e4a in g_signal_emit_by_name (instance=0x11052c0, 
detailed_signal=0x7fb358792414 update)
#13 0x7fb35872c3bc in  () at /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#14 0x7fb35871bcf8 in  () at /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#15 0x7fb3570825e3 in g_timeout_dispatch (source=0x154f690, 
callback=optimized out, user_data=optimized out)
#16 0x7fb357081b4d in g_main_context_dispatch (context=0x10bd3f0)
#17 0x7fb357081b4d in g_main_context_dispatch 
(context=context@entry=0x10bd3f0) at 
/tmp/buildd/glib2.0-2.44.1/./glib/gmain.c:3737
#18 0x7fb357081f20 in g_main_context_iterate 
(context=context@entry=0x10bd3f0, block=block@entry=0, 
dispatch=dispatch@entry=1, self=optimized out)
#19 0x7fb357081fcc in g_main_context_iteration (context=0x10bd3f0, 
may_block=0) at /tmp/buildd/glib2.0-2.44.1/./glib/gmain.c:3869
#20 0x0041d531 in  ()
#21 0x004b6b34 in  ()
#22 0x00423b74 in  ()
#23 0x00424b3f in  ()
#24 0x7fb357081b4d in g_main_context_dispatch (context=0x10bd3f0)
#25 0x7fb357081b4d in g_main_context_dispatch 
(context=context@entry=0x10bd3f0) at 
/tmp/buildd/glib2.0-2.44.1/./glib/gmain.c:3737
#26 0x7fb357081f20 in g_main_context_iterate (context=0x10bd3f0, 
block=block@entry=1, dispatch=dispatch@entry=1, self=optimized out)
#27 0x7fb357082242 in g_main_loop_run (loop=0x11046a0)
#28 0x7fb358bc6a85 in gtk_main ()
#29 0x00417421 in main ()


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages lives depends on:
ii  frei0r-plugins1:1.4-dmo4
ii  imagemagick   8:6.8.9.9-5
ii  libasound21.0.28-1
ii  libatk1.0-0   

Accepted bcache-tools 1.0.8-2 (source amd64) into unstable

[David Mohr]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 11 Jun 2015 10:23:48 -0600
Source: bcache-tools
Binary: bcache-tools
Architecture: source amd64
Version: 1.0.8-2
Distribution: unstable
Urgency: medium
Maintainer: David Mohr da...@mcbf.net
Changed-By: David Mohr da...@mcbf.net
Description:
 bcache-tools - bcache userspace tools
Closes: 788442
Changes:
 bcache-tools (1.0.8-2) unstable; urgency=medium
 .
   * Only run update-initramfs if installed. Fix dracut. (Closes: #788442)
Checksums-Sha1:
 7692e7aafb9e5ed14c6e42a11a1efbe48beee74d 1957 bcache-tools_1.0.8-2.dsc
 2e80693c55b3256ef1daa68f3256f1aa25f64338 4596 
bcache-tools_1.0.8-2.debian.tar.xz
 cb90fa0179cdf8442a7184c93ece4543207958a5 18346 bcache-tools_1.0.8-2_amd64.deb
Checksums-Sha256:
 3ecd4b3d4e4c9c17e8980a4119c40e99496a5facb3c90d9070fd60ef1203571c 1957 
bcache-tools_1.0.8-2.dsc
 536a5d45a6c5e4239c56373cb6669b6ea972908a69591b7f63d8fd8c6763b4df 4596 
bcache-tools_1.0.8-2.debian.tar.xz
 f950fe3c6ee2674373cffc0cc3313ccfe51060492bea9a5be9b7b49c4ef4f501 18346 
bcache-tools_1.0.8-2_amd64.deb
Files:
 76d7d891382c07212229802861863ab5 1957 utils optional bcache-tools_1.0.8-2.dsc
 97afec386ca537e7e599267f4a045f65 4596 utils optional 
bcache-tools_1.0.8-2.debian.tar.xz
 e84e0f52c52179549518d974ba83648c 18346 utils optional 
bcache-tools_1.0.8-2_amd64.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJVjWF4AAoJEL/srsug59jD/WkQAJ1Rrpg1k0146XulDUOvyEap
+SNBTFa/jM63+GNwiwSahq+CMO6greYPMf+KRK0BX8XrAfrdwcwF0xGJ/afcoV3I
G5mEF0Pq1Mflxkuhehk2CxPExqd/lRsclG9CKQiiw0Up2WeoWirwCUQLCNx+qlYk
TfmA2JQpg8WpBqcZIiaKOpyfO+qB/954+M5d/CrkkY0syLwDvGH7Y6l8m16SMu1f
j5mUVo8RGxoNbTurAmaInv6QgeT4KdiBw92PTB1+JpY24SntJPef3HCHkNVm8EgT
W6qCGEX9ooXiES4hvvlomvuAxW7Z1bxPULIz6zW7rHuT5EYamxIzB2T+hzFxuG5x
mnMTCf6OLdnXUeLdXFByffdm79jXD0eLClXGWddPFN9WzNfWMK7DxvqgfO4/Jd27
oQ6OA7H2hbBXoKZj5MJTSn/rk36fQRC8VovhfXzNyePYHzCh5ja+AUK45zSOOivY
JEZ+k4C0hyieGEWHRSd2KAS1AGP8kYkC4/ghrrQDWP83+Vt9e4kIoImR2ngc+ht9
3lQnBB0yFI3jvYyaco6ZrIrqJQAhpR8mSzZ3uxhKyHcySQQbfWy0urjdDcL95K0V
Igv0AE8zmV3FgxAbB4mP+xq0s91RRjCaX8Bg2JtcQmcm2XqhDV73H3ZYVWlhKztb
g2mK65hrIZwT8jdZJbn9
=eSxY
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1z8vqj-mw...@franck.debian.org

Bug#788904: systemd fails to activate vg on crypt device after upgrade to 215-17+deb8u1

[David Mohr]

close 788904
thanks

On 2015-06-16 00:19, Michael Biebl wrote:

Am 16.06.2015 um 08:12 schrieb Michael Biebl:

Am 16.06.2015 um 06:35 schrieb David Mohr:
I have a crypto device which I use as a physical volume for LVM. 
After

upgrading to systemd 215-17+deb8u1 my system fails to boot, because
`vgchange -ay` is not run after the crypto device is set up (which


[..]


Please let me know if I can help to fix this, since I think that's a
pretty bad regression.


I assume you had 215-17 installed before the upgrade. Can you 
downgrade

to that version again?
The changes in 215-17+deb8u1 do not look like they could be related to
your problem, but let's verify if the downgrade actually helps.


downgrade both systemd and udev to be sure.


Hm, I'm guessing it was a race condition... I tried several times and I 
couldn't reproduce the issue.


~David


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

Bug#788904: systemd fails to activate vg on crypt device after upgrade to 215-17+deb8u1

[David Mohr]

close 788904
thanks

On 2015-06-16 00:19, Michael Biebl wrote:

Am 16.06.2015 um 08:12 schrieb Michael Biebl:

Am 16.06.2015 um 06:35 schrieb David Mohr:
I have a crypto device which I use as a physical volume for LVM. 
After

upgrading to systemd 215-17+deb8u1 my system fails to boot, because
`vgchange -ay` is not run after the crypto device is set up (which


[..]


Please let me know if I can help to fix this, since I think that's a
pretty bad regression.


I assume you had 215-17 installed before the upgrade. Can you 
downgrade

to that version again?
The changes in 215-17+deb8u1 do not look like they could be related to
your problem, but let's verify if the downgrade actually helps.


downgrade both systemd and udev to be sure.


Hm, I'm guessing it was a race condition... I tried several times and I 
couldn't reproduce the issue.


~David

___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#788904: systemd fails to activate vg on crypt device after upgrade to 215-17+deb8u1

[David Mohr]

close 788904
thanks

On 2015-06-16 00:19, Michael Biebl wrote:

Am 16.06.2015 um 08:12 schrieb Michael Biebl:

Am 16.06.2015 um 06:35 schrieb David Mohr:
I have a crypto device which I use as a physical volume for LVM. 
After

upgrading to systemd 215-17+deb8u1 my system fails to boot, because
`vgchange -ay` is not run after the crypto device is set up (which


[..]


Please let me know if I can help to fix this, since I think that's a
pretty bad regression.


I assume you had 215-17 installed before the upgrade. Can you 
downgrade

to that version again?
The changes in 215-17+deb8u1 do not look like they could be related to
your problem, but let's verify if the downgrade actually helps.


downgrade both systemd and udev to be sure.


Hm, I'm guessing it was a race condition... I tried several times and I 
couldn't reproduce the issue.


~David


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

Accepted bcache-tools 1.0.8-1 (source amd64) into unstable

[David Mohr]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 26 May 2015 20:57:58 -0600
Source: bcache-tools
Binary: bcache-tools
Architecture: source amd64
Version: 1.0.8-1
Distribution: unstable
Urgency: medium
Maintainer: David Mohr da...@mcbf.net
Changed-By: David Mohr da...@mcbf.net
Description:
 bcache-tools - bcache userspace tools
Closes: 775674 98
Changes:
 bcache-tools (1.0.8-1) unstable; urgency=medium
 .
   [ James Page ]
   * d/control: Add Vcs fields.
 .
   [ David Mohr ]
   * Don't depend on initramfs-tools, instead recommend it (Closes: #775674)
   * New upstream release 1.0.8
   * Update changelog
   * Add patch to clean bcache-register
   * Update changelog
   * Adding dep3 headers to the 0001 patch
   * Update watch to use http://evilpiepirate.org/git/bcache-tools.git
   * Add patch for gcc-5 compatability.
 Thanks to James Cowgill (Closes: #98)
Checksums-Sha1:
 14aa8a5063dded4448f7ea76c4ac656137a87788 1957 bcache-tools_1.0.8-1.dsc
 e848aa9ab376d93588de3fe3dd5ed33bacaae53c 22039 bcache-tools_1.0.8.orig.tar.gz
 b6f0d2d093d511c3f6f8249eb8ae0ed67a33 4456 
bcache-tools_1.0.8-1.debian.tar.xz
 6367d1ff7b91d344ccce7308a1dd5f3a67be1bef 18236 bcache-tools_1.0.8-1_amd64.deb
Checksums-Sha256:
 66b70d3307717b3c4855aee5d1fa855d50dce6d7556bc83470ec4fceb17d1b81 1957 
bcache-tools_1.0.8-1.dsc
 0aadaa15e263aef1fcab19c73ae8429e7a854a692be2865d1ab637d5f291f6d8 22039 
bcache-tools_1.0.8.orig.tar.gz
 c456bf83adbddca0be3818f79f93ecd7664690819f6ac0eb3a7971424647ad61 4456 
bcache-tools_1.0.8-1.debian.tar.xz
 c31c9f5ac1e121820088f4cdacebba4cbcd585d6ef16cf5af62ff71c2894f115 18236 
bcache-tools_1.0.8-1_amd64.deb
Files:
 9d1f9383d03d3f3f47f1281b8a1a444b 1957 utils optional bcache-tools_1.0.8-1.dsc
 bfd64b4f54ca91e5f10078e46e9d4b46 22039 utils optional 
bcache-tools_1.0.8.orig.tar.gz
 c458770711dfad9974b15874f1c60176 4456 utils optional 
bcache-tools_1.0.8-1.debian.tar.xz
 423db43da5762ad50d6e5e6fe44d1255 18236 utils optional 
bcache-tools_1.0.8-1_amd64.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJVeDoxAAoJEL/srsug59jDeLwQAL3oZxEhXNZWEK3+d6VeSdNt
NU/tNSGyztcqVvpZLnnCe3RzmLsgo0mGNRPkJ5x9HZVZ18Pw6T0GxMAtyIj1i9Zu
DMtyit0Be+dpDa6OApDphz2l0PGITZpni7GcxaZgOvqjkcgN4ewfU7Wpp97OPFGx
o3hqY0EOlvRri5ptsPF4LsIOSk+TRrK2sxwTEdAJrK0XeQplKNd48kKypUvAvJEK
YoljC0c/HbEQk9Vnn2P+Lkmkb3LpgNC0zC6SntPv4MW5Jw3yalbepkN8dISmFZvf
0MIsu3+e6cOdANX7OLa2RWDSOt0njW99xsI1yI6r9mKaniy1ucmgk4qx/mcZebUX
ilM3y9ZDoJ25pyEygG5prG5DEeGrwVqQnx3hHNYKyGmai/PzsFMxbGbGW/aWNOH1
aJW3lZ2Fmj4rtw8QWBAD4ypx/QDhQovixi0YFWSugvMOjSWLE0W6jnyKh1xP6vxs
ZNKO/gyp0eSoMfvYx0vHp56FHZEDLyPrpTyP36IKYGczHhAXm6MHUtFpVcjsOp4F
8/Yy2w79u0Ho6TYDzSm24+e+olDOsEh8/eVcp9woVvOWTfQUPpcG08+ds6+TdMZi
HhWL7r+WQIjZ2TH9mcrnN/CkCQUx6ULC2DCKniAJl/7GzXKMS2lzMqa22qQ3yXVq
Sc2lrjWoQ2WckmCP6A4A
=lwI8
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1z2g8v-dh...@franck.debian.org

udev 220 rules broken for bcache

[David Mohr]

Hi,

just a heads up to other distros that the udev rules broke bcache 
/dev/disk/by-uuid symlinks (and hence booting if the fstab uses UUIDs) 
in v220. The fix is already applied, but afaik not released yet.


The small patch to fix it is at 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787367


~David
--
To unsubscribe from this list: send the line unsubscribe linux-bcache in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[systemd-devel] bcache broke in udev 220

[David Mohr]

Hi,

udev 220 arrived in Debian sid and this update broke bcache support [1]: 
no /dev/disk/by-uuid/ symlink is being created for the filesystem on top 
of /dev/bcache*. That's because 60-persistent-storage now uses a 
whitelist instead of blacklist. The simple attached patch fixes this, 
could you please apply it?


Thanks,
~David

[1]: http://bugs.debian.org/787367--- lib/udev/rules.d/60-persistent-storage.rules.orig   2015-05-31 
13:30:08.327444638 -0600
+++ lib/udev/rules.d/60-persistent-storage.rules2015-05-31 
13:30:14.799448929 -0600
@@ -6,7 +6,7 @@
 ACTION==remove, GOTO=persistent_storage_end
 
 SUBSYSTEM!=block, GOTO=persistent_storage_end
-KERNEL!=loop*|mmcblk*[0-9]|msblk*[0-9]|mspblk*[0-9]|nvme*|sd*|sr*|vd*, 
GOTO=persistent_storage_end
+KERNEL!=loop*|mmcblk*[0-9]|msblk*[0-9]|mspblk*[0-9]|nvme*|sd*|sr*|vd*|bcache*,
 GOTO=persistent_storage_end
 
 # ignore partitions that span the entire disk
 TEST==whole_disk, GOTO=persistent_storage_end
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Bug#787367: Acknowledgement (udev: 220-2 does not create /dev/disk/by-uuid link (required for system mounting) for filesystem on a bcache device)

[David Mohr]

Forwarded: 
http://lists.freedesktop.org/archives/systemd-devel/2015-May/032610.html



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

Bug#787322: bcache-tools: bcache array undetected by probe and does not appear in /dev/disk/by-uuid thus breaking boot

[David Mohr]

severity 787322 normal
reassign 787322 udev
merge 787322 787367
affects 787367 bcache-tools
thanks

Thanks Matthew for the report! Your analysis is correct (and thanks for 
providing a workaround). See the patch that I included in #787367 if you 
want to fix udev.


~David


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

Bug#786941: lmbench: config-run writes and results uses config file in /usr/lib

[David Mohr]

Package: lmbench
Version: 3.0-a9-1.1
Severity: important
Tags: patch

Dear Maintainer,

patches/02_paths.dpatch doesn't update config-run and results correctly,
from config-run:
 C=${BINDIR}/bin/$OS/`${SCRIPTSDIR}/config`

which means the config file gets written to /usr/lib/lmbench...

lmbench-run uses a sensible location, so I moved that path into
$BIN_DIR/config, and updated lmbench-run, config-run and results
accordingly.

Please see the attached patch which updates 02_paths.

Sorry about the git noise, but this is too annoying manually (maybe
quilt would be a better option than dpatch?)

Thanks,
~David

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages lmbench depends on:
ii  gcc   4:4.9.2-4
ii  libc6 2.19-18
ii  libc6-dev [libc-dev]  2.19-18
ii  perl  5.20.2-6

Versions of packages lmbench recommends:
ii  lmbench-doc  3.0-a9-1.1

lmbench suggests no packages.

-- no debconf information
diff --git a/lmbench-run b/lmbench-run
index c699897..fc9b211 100644
--- a/lmbench-run
+++ b/lmbench-run
@@ -10,7 +10,7 @@ SCRIPTSDIR=$BINDIR/scripts
 RESULTSDIR=$DATADIR/results
 SRCDIR=$SHAREDIR/src
 export SHAREDIR DATADIR BINDIR SCRIPTSDIR RESULTSDIR SRCDIR
-CONFIG=$DATADIR/config/`$SCRIPTSDIR/config`
+CONFIG=`$SCRIPTSDIR/config`
 
 runuid=`id -u`
 
diff --git a/patches/02_paths.dpatch b/patches/02_paths.dpatch
index be7a4b9..04b542e 100755
--- a/patches/02_paths.dpatch
+++ b/patches/02_paths.dpatch
@@ -5,9 +5,25 @@
 ## DP: No description.
 
 @DPATCH@
-diff -urNad lmbench-3.0~/lmbench-3.0-a9/scripts/config-run lmbench-3.0/lmbench-3.0-a9/scripts/config-run
 lmbench-3.0~/lmbench-3.0-a9/scripts/config-run	2005-09-04 05:04:28.0 -0600
-+++ lmbench-3.0/lmbench-3.0-a9/scripts/config-run	2006-03-21 17:50:36.0 -0700
+diff --git a/lmbench-3.0-a9/scripts/config b/lmbench-3.0-a9/scripts/config
+index b58cb60..2a50513 100755
+--- a/lmbench-3.0-a9/scripts/config
 b/lmbench-3.0-a9/scripts/config
+@@ -1,7 +1,8 @@
+ #!/bin/sh
++DATADIR=/var/lib/lmbench
+ 
+ UNAME=`uname -n 2/dev/null`
+ if [ X$UNAME = X ]
+-then	echo CONFIG
+-else	echo CONFIG.$UNAME
++then	echo $DATADIR/config/CONFIG
++else	echo $DATADIR/config/CONFIG.$UNAME
+ fi
+diff --git a/lmbench-3.0-a9/scripts/config-run b/lmbench-3.0-a9/scripts/config-run
+index f620c15..b20252a 100755
+--- a/lmbench-3.0-a9/scripts/config-run
 b/lmbench-3.0-a9/scripts/config-run
 @@ -3,7 +3,10 @@
  # Configure parameters for lmbench.
  # %I% %E% %@%
@@ -20,7 +36,7 @@ diff -urNad lmbench-3.0~/lmbench-3.0-a9/scripts/config-run lmbench-3.0/lmbench-3
  L='='
  echo $L; 
  catEOF;
-@@ -36,20 +39,20 @@
+@@ -132,20 +135,20 @@ export LMBENCH_SCHED
  
  echo $L; echo ;
  echo Hang on, we are calculating your timing granularity.
@@ -47,7 +63,7 @@ diff -urNad lmbench-3.0~/lmbench-3.0-a9/scripts/config-run lmbench-3.0/lmbench-3
  export LOOP_O
  echo OK, it looks like your benchmark loop costs $LOOP_O usecs.
  echo 
-@@ -164,7 +167,7 @@
+@@ -177,7 +180,7 @@ then
  fi
  if [ X$MB = X ]
  then	$ECHON Probing system for available memory: $ECHOC
@@ -56,7 +72,7 @@ diff -urNad lmbench-3.0~/lmbench-3.0-a9/scripts/config-run lmbench-3.0/lmbench-3
  fi
  TOTAL_MEM=$MB
  MB=`echo \( $MB \* 7 \) / 10 | bc 2/dev/null`
-@@ -192,9 +195,9 @@
+@@ -205,9 +208,9 @@ fi
  # Certain machines tend to barf when you try and bcopy 8MB.
  # Figure out how much we can use.
  echo Checking to see if you have $MB MB; please wait for a moment...
@@ -69,7 +85,7 @@ diff -urNad lmbench-3.0~/lmbench-3.0-a9/scripts/config-run lmbench-3.0/lmbench-3
  if [ `expr $SYNC_MAX \* $MB` -gt `expr $TOTAL_MEM` ]
  then
  	MB=`expr $TOTAL_MEM / $SYNC_MAX`
-@@ -210,8 +213,8 @@
+@@ -223,8 +226,8 @@ then	echo Warning: you have only ${MB}MB available memory.
  fi
  
  echo Hang on, we are calculating your cache line size.
@@ -80,7 +96,7 @@ diff -urNad lmbench-3.0~/lmbench-3.0-a9/scripts/config-run lmbench-3.0/lmbench-3
  export LINE_SIZE
  echo OK, it looks like your cache line is $LINE_SIZE bytes.
  echo 
-@@ -459,7 +462,7 @@
+@@ -479,7 +482,7 @@ EOF
  	then	
  		for i in $disks
  		do	if [ -r $i ]
@@ -89,7 +105,7 @@ diff -urNad lmbench-3.0~/lmbench-3.0-a9/scripts/config-run lmbench-3.0/lmbench-3
  if [ $? -eq 1 ]
  then	echo Must be root to run disk benchmarks.
  	echo Root is needed to flush the buffer cache
-@@ -564,7 +567,7 @@
+@@ -584,7 +587,7 @@ fi
  echo $L
  echo 
  echo Calculating mhz, please wait for a moment...
@@ -98,7 +114,7 @@ diff -urNad 

Re: bcache-tools fails to build with gcc 5.1.1

[David Mohr]

Debian also noticed this issue [1] and had a submission of a slightly 
simpler patch below. Since crc64 doesn't seem to be particularly 
performance sensitive, I think it's nicer to just remove the inline (and 
that's what I will include for now until one or the other is applied to 
git).


~David

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=98#10

diff --git a/bcache.c b/bcache.c
index 8f37445..8b4b986 100644
--- a/bcache.c
+++ b/bcache.c
@@ -115,7 +115,7 @@ static const uint64_t crc_table[256] = {
0x9AFCE626CE85B507ULL
 };

-inline uint64_t crc64(const void *_data, size_t len)
+uint64_t crc64(const void *_data, size_t len)
 {
uint64_t crc = 0xULL;
const unsigned char *data = _data;


On 2015-05-22 12:03, Rolf Fokkens wrote:

Hi all,

By upgrading to Fedora 22 I've become a gcc 5.1.1 user. gcc rightfully
complains about the following during make:

[rolf.fokkens@home07 bcache-tools-1.0.8.orig]$ make
cc -O2 -Wall -g `pkg-config --cflags uuid blkid`   -c -o bcache.o 
bcache.c

bcache.c:125:9: warning: ‘crc_table’ is static but used in inline
function ‘crc64’ which is not static
   crc = crc_table[i] ^ (crc  8);
 ^
cc -O2 -Wall -g `pkg-config --cflags uuid blkid`make-bcache.c
bcache.o  `pkg-config --libs uuid blkid` -o make-bcache
/tmp/cchVVBrJ.o: In function `write_sb':
/tmp/bcache-tools-1.0.8.orig/make-bcache.c:277: undefined reference to 
`crc64'

collect2: error: ld returned 1 exit status
builtin: recipe for target 'make-bcache' failed
make: *** [make-bcache] Error 1
[rolf.fokkens@home07 bcache-tools-1.0.8.orig]$

This fix is:

diff -ruN bcache-tools-1.0.8.orig/bcache.c bcache-tools-1.0.8/bcache.c
--- bcache-tools-1.0.8.orig/bcache.c2014-12-04 23:51:24.0 
+0100

+++ bcache-tools-1.0.8/bcache.c2015-05-22 19:40:41.039355096 +0200
@@ -26,7 +26,7 @@
  * x^7 + x^4 + x + 1
 */

-static const uint64_t crc_table[256] = {
+const uint64_t crc_table[256] = {
 0xULL, 0x42F0E1EBA9EA3693ULL, 
0x85E1C3D753D46D26ULL,
 0xC711223CFA3E5BB5ULL, 0x493366450E42ECDFULL, 
0x0BC387AEA7A8DA4CULL,
 0xCCD2A5925D9681F9ULL, 0x8E224479F47CB76AULL, 
0x9266CC8A1C85D9BEULL,

@@ -114,16 +114,3 @@
 0x5DEDC41A34BBEEB2ULL, 0x1F1D25F19D51D821ULL, 
0xD80C07CD676F8394ULL,

 0x9AFCE626CE85B507ULL
 };
-
-inline uint64_t crc64(const void *_data, size_t len)
-{
-uint64_t crc = 0xULL;
-const unsigned char *data = _data;
-
-while (len--) {
-int i = ((int) (crc  56) ^ *data++)  0xFF;
-crc = crc_table[i] ^ (crc  8);
-}
-
-return crc ^ 0xULL;
-}
diff -ruN bcache-tools-1.0.8.orig/bcache.h bcache-tools-1.0.8/bcache.h
--- bcache-tools-1.0.8.orig/bcache.h2014-12-04 23:51:24.0 
+0100

+++ bcache-tools-1.0.8/bcache.h2015-05-22 19:40:34.924320569 +0200
@@ -115,7 +115,20 @@
 #define BDEV_STATE_DIRTY2U
 #define BDEV_STATE_STALE3U

-uint64_t crc64(const void *_data, size_t len);
+extern const uint64_t crc_table[];
+
+inline uint64_t crc64(const void *_data, size_t len)
+{
+uint64_t crc = 0xULL;
+const unsigned char *data = _data;
+
+while (len--) {
+int i = ((int) (crc  56) ^ *data++)  0xFF;
+crc = crc_table[i] ^ (crc  8);
+}
+
+return crc ^ 0xULL;
+}

 #define node(i, j)((void *) ((i)-d + (j)))
 #define end(i)node(i, (i)-keys)

This is also on github:

https://github.com/g2p/bcache-tools/pull/24

Cheers!

Rolf
--
To unsubscribe from this list: send the line unsubscribe linux-bcache 
in

the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line unsubscribe linux-bcache in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Bug#774797: initramfs-tools: Include bcache.ko by default

[David Mohr]

severity 774797 wishlist
retitle 774797 bcache support in the installer (most importantly include 
bcache.ko)

thanks


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

Bug#774797: initramfs-tools: Include bcache.ko by default

[David Mohr]

Sorry for getting back so late on this issue.

On 2015-01-07 11:46, Andreas Kloeckner wrote:

I'm therefore suggesting that at the very least bcache.ko (and perhaps
also bcache-tools) should be made part of the default initramfs image.


I totally agree.


/usr/share/initramfs-tools/hooks:
bcache


This file exists on your system and does install bcache.ko into the 
initrd:


% lsinitramfs /boot/initrd.img-3.16.0-4-amd64 | grep bcache
lib/modules/3.16.0-4-amd64/kernel/drivers/md/bcache
lib/modules/3.16.0-4-amd64/kernel/drivers/md/bcache/bcache.ko
lib/modules/3.16.0-4-amd64/kernel/fs/mbcache.ko
lib/udev/probe-bcache
lib/udev/rules.d/69-bcache.rules
lib/udev/bcache-register

Maybe the initramfs somehow did not get updated on your system?

~David


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

Bug#774797: initramfs-tools: Include bcache.ko by default

[David Mohr]

On 2015-05-02 16:58, Andreas Kloeckner wrote:

That does exist, and it appears to be doing its job, but it comes from
the bcache-tools package. That's not entirely what I'm talking about
though. I'm more concerned about an annoying bootstrap issue that I've
faced multiple times when installing Debian onto a bcache volume. 
Here's

what I currently have to do:

- Format as bcache using some live system

- Reboot into d-i.

- From within the debian installer, unpack bcache.ko out of the
  installer's kernel .deb, insmod it.

- Register the bcache, install to it.

- Reboot into the new system. Oops, boot fails, because there's no
  bcache.ko. Back to a live system, drop the right bcache.ko into 
/boot,

  reboot, insmod it, register the bcache, boot. (*)

- Then install bcache-tools, and things start looking up.

(*) This step is the most annoying, and what I'd like to see
fixed. Alternatively, if d-i understood that I'm installing onto bcache
and installed bcache-tools, my problem would also be solved...


Ah, yes, so it's all about the installer. That was not obvious to me 
from the original bug report. Ideally I'd like to see full installer 
support but I don't know how much effort is involved. It is something 
that has been on my personal TODO list, and will get tackled sometimes 
now that jessie is out of the door.


Thanks,
~David


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

Re: caching device setup

[David Mohr]

On 2015-04-06 09:44, arnaud gaboury wrote:

Here is my overall plan:

root filesystem  OS on a SSD
DB and other stuff on HD.
Use ssd as caching device and HD as backing.

Shall I partition the SSD with : one partition for OS and one empty
for bcache? Or install the OS on the whole SSD and use the whole SSD
as caching device?

Thank you for hint.


So this is just depending on your preference, how big the SSD is, and 
how much space you expect your OS to take up.


Personally I split my SSD into two partitions: one for the root FS, and 
the other as a caching device for /home.


~David
--
To unsubscribe from this list: send the line unsubscribe linux-bcache in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Bug#770283: debugging 32bit crashes (or lack thereof)

[David Mohr]

Hi,

unfortunately I don't have any good ideas of debugging these 32bit 
issues. Since it seems to be an issue in how xfburn uses gtk, it won't 
be easy to find. Some of the gtk code is pretty messy, I admit that, but 
cleaning it up is a major project. And right now for a lack of time, and 
small number of 32bit users, I don't think it'll happen. I hate to say 
that, but it's the realistic answer right now.


Thomas, thanks as always for your time to get to the root of the 
problem! I very much appreciate it.


~David


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

[Pkg-xfce-devel] Bug#770283: debugging 32bit crashes (or lack thereof)

[David Mohr]

Hi,

unfortunately I don't have any good ideas of debugging these 32bit 
issues. Since it seems to be an issue in how xfburn uses gtk, it won't 
be easy to find. Some of the gtk code is pretty messy, I admit that, but 
cleaning it up is a major project. And right now for a lack of time, and 
small number of 32bit users, I don't think it'll happen. I hate to say 
that, but it's the realistic answer right now.


Thomas, thanks as always for your time to get to the root of the 
problem! I very much appreciate it.


~David

___
Pkg-xfce-devel mailing list
Pkg-xfce-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-xfce-devel

Bug#780319: major regression

[David Mohr]

Hi,

I would like to add that with initramfs-tools 0.116 and lvm2 2.02.111-2 
the following fstab entry was mounted just fine during boot when using 
systemd:


/dev/vg0/usr/usrxfs rw,relatime,nodev   
0   2

This is a really annoying regression for us. I'm wondering if there 
would be issue to resolve the /dev/VG/LV path into exactly those 
components, and then to run the vgchange. After all, this is a valid 
path in /dev in a running system.


~David


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

Bug#780481: grub2-common: next_entry is not reset in grubenv on boot

[David Mohr]

Package: grub2-common
Version: 2.02~beta2-21
Severity: minor

Dear Maintainer,

grub-reboot sets next_entry in /boot/grub/grubenv. Usually this variable
is reset on boot, but that has not been happening for a while now. I
think it's related to uefi, because on my jessie laptop it seems to work
fine with grub2-pc.

When I use grub-reboot I expect to only boot into the selection _once_,
and not every time.

Thanks,
~David

-- Package-specific info:

*** BEGIN /proc/mounts
/dev/dm-0 / ext4 rw,noatime,discard,errors=remount-ro,commit=30,data=ordered 0 0
/dev/sdb3 /boot/efi vfat 
rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=utf8,shortname=mixed,errors=remount-ro
 0 0
/dev/mapper/vg0-libvirtimg /var/lib/libvirt/images jfs rw,relatime 0 0
/dev/bcache0 /home ext4 rw,noatime,discard,commit=15,data=ordered 0 0
/dev/bcache0 /srv/torrents ext4 rw,noatime,discard,commit=15,data=ordered 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/device.map
(hd0)   /dev/disk/by-id/ata-ST2000DL003-9VT166_5YD10B5A
(hd1)   /dev/disk/by-id/ata-Zalman_S64GB_WWW--E94
(hd2)   /dev/disk/by-id/ata-ST1500DL003-9VT16L_5YD20TRG
*** END /boot/grub/device.map

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ ${next_entry} ] ; then
   set default=${next_entry}
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default=${saved_entry}
fi

if [ x${feature_menuentry_id} = xy ]; then
  menuentry_id_option=--id
else
  menuentry_id_option=
fi

export menuentry_id_option

if [ ${prev_saved_entry} ]; then
  set saved_entry=${prev_saved_entry}
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z ${boot_once} ]; then
saved_entry=${chosen}
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_msdos
insmod lvm
insmod ext2
set 
root='lvmid/RjKUeG-3qSL-cf1a-2b02-cogH-Lb2z-GiqBSZ/yZguv8-E0Jc-baGj-xCQA-9Lwo-Smnl-RVY6fL'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root 
--hint='lvmid/RjKUeG-3qSL-cf1a-2b02-cogH-Lb2z-GiqBSZ/yZguv8-E0Jc-baGj-xCQA-9Lwo-Smnl-RVY6fL'
  271eabf2-2806-4cab-a250-0d9db82b877a
else
  search --no-floppy --fs-uuid --set=root 271eabf2-2806-4cab-a250-0d9db82b877a
fi
font=/usr/share/grub/unicode.pf2
fi

if loadfont $font ; then
  set gfxmode=1024x768
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=en_US
  insmod gettext
fi
terminal_output gfxterm
if [ ${recordfail} = 1 ] ; then
  set timeout=-1
else
  if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
  # Fallback normal timeout code in case the timeout_style feature is
  # unavailable.
  else
set timeout=5
  fi
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/02_custom_uefi ###
insmod efi_gop
insmod efi_uga
insmod font

if loadfont ${prefix}/unicode.pf2
then
insmod gfxterm
set gfxmode=auto
set gfxpayload=keep
#set gfxpayload=text # no effect on NVRM error, and no console output
terminal_output gfxterm
fi
### END /etc/grub.d/02_custom_uefi ###

### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_msdos
insmod lvm
insmod ext2
set 
root='lvmid/RjKUeG-3qSL-cf1a-2b02-cogH-Lb2z-GiqBSZ/yZguv8-E0Jc-baGj-xCQA-9Lwo-Smnl-RVY6fL'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root 
--hint='lvmid/RjKUeG-3qSL-cf1a-2b02-cogH-Lb2z-GiqBSZ/yZguv8-E0Jc-baGj-xCQA-9Lwo-Smnl-RVY6fL'
  271eabf2-2806-4cab-a250-0d9db82b877a
else
  search --no-floppy --fs-uuid --set=root 271eabf2-2806-4cab-a250-0d9db82b877a
fi
insmod png
if background_image /usr/share/images/desktop-base/lines-grub-1920x1080.png; 
then
  set color_normal=white/black
  set color_highlight=black/white
else
  set menu_color_normal=cyan/blue
  set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload=${1}
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu 
--class os $menuentry_id_option 
'gnulinux-simple-271eabf2-2806-4cab-a250-0d9db82b877a' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_msdos
insmod lvm
insmod ext2
set 

Bug#779153: Packaged php 5.4.38

[David Mohr]

Hi,

please consider reviewing my packaging:
  http://de.mcbf.net/~squisher/debian/php/php5_5.4.38-0.dsc

A couple of patches seem to have been adopted upstream, and I had to add 
one minor fix for the crypt config.m4.


Thank you for your hard work!

~David


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

Bug#779153: php5: Please package new upstream version 5.4.38 because of CVE-2015-0273

[David Mohr]

Package: php5
Version: 5.4.36-0+deb7u3
Severity: normal

Dear Maintainer,

I'm a little concerned that there doesn't seem to be much activity to
package php 5.4.38 which came out with the following announcement about
a week ago:


This release fixes several bugs and addresses CVE-2015-0235 and
CVE-2015-0273. All PHP 5.5 users are encouraged to upgrade to this
version.


This affects squeeze as well, but I have no idea if a patch is available
for 5.3.

https://security-tracker.debian.org/tracker/CVE-2015-0273

Is there a particular reason for this delay?

Thanks,
~David

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

Kernel: Linux 3.12.20-x86_64-jb1 (SMP w/3 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages php5 depends on:
ii  libapache2-mod-php5  5.4.36-0+deb7u3
ii  php5-common  5.4.36-0+deb7u3
ii  php5-fpm 5.4.36-0+deb7u3

php5 recommends no packages.

php5 suggests no packages.

-- no debconf information


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

Bug#767569: systemd - please update documentation

[David Mohr]

Hi,

I think that's because now systemd is used and smartmontools ships with 
a .service file instead of relying on the LSB compatibility layer. My 
guess all that is required is to correct README.Debian and place some 
notice into /etc/default/smartmontools.


I do wonder though: was it intentional that now smartd is enabled by 
default, whereas it was disabled by default pre-systemd?


Thanks,
~David


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

Bug#774643: verify_active_connections is not present in ruby-activerecord 4.1.8

[David Mohr]

On 2015-02-02 20:11, micah wrote:

David Mohr b...@da.mcbf.net writes:

Is noone using puppet in jessie with storeconfigs? That seems really 
odd

to me...


Unfortunately, all my puppet recipes are on nothing newer than wheezy
right now, and need some serious tending to before they can get to 
using

the newer version so I haven't had the ability to test this out :o


It doesn't matter what kind of recipe you have. I tried it with a dummy 
catalog and a random exec {} -- it will fail as soon as you set

storeconfigs = true
in puppet.conf

So it's fairly easy to reproduce. Btw the only suggestion I have 
received from ask.puppetlabs.com is to downgrade the package :-(


~David


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

Bug#774643: verify_active_connections is not present in ruby-activerecord 4.1.8

[David Mohr]

I'm also struggling to understand what the issue is. I need 
storedconfigs, but puppetdb is not packaged, and it seems that the 
version of activerecord in jessie is too new for puppet, because 
according to 
http://apidock.com/rails/ActiveRecord/Base/verify_active_connections!/class 
that method isn't available anymore. However, google doesn't return much 
at all about this problem.


I asked about this at puppetlabs: 
http://ask.puppetlabs.com/question/15610/current-activerecords-breaks-puppet-with-storeconfigs/ 
(link currently awaiting moderation).


Let's see if someone offers some insight!

Is noone using puppet in jessie with storeconfigs? That seems really odd 
to me...


Thanks,
~David


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

Bug#774865: 5.7p3, epoch

[David Mohr]

Hi,

thanks for getting the new version into experimental! However, there's 
already a new version released: 
http://openntpd.org/txt/release-5.7p3.txt


Another question: why keep the YMD-Version scheme? I'd think it'd be 
better to increment epoch and use 1:5.7p3


~David


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

Bug#773539: ifupdown: Please return exit status 1 when up command fails (unconfigured interface affects network-manager)

[David Mohr]

Package: ifupdown
Version: 0.7.50
Severity: normal

Dear Maintainer,

please consider returning exit status 1 when the up command of an
interface fails. Since the interface is not marked as configured,
network-manager will think there is no connectivity and programs
interacting with NM won't work (for example pidgin).

My situation was that I wanted to turn on jumbo frames for my network
bridge, and I mistakenly added the up commands in the wrong order:
up ifconfig br0 mtu 9000
up ifconfig eth0 mtu 9000

Now on the next reboot network-manager thought I was offline. The reason
for that was a little difficult to debug because systemd thought
everything was just fine: no error was reported from
/etc/init.d/networking. Since my computer boots up too fast to watch the
initialization messages, I didn't notice the error there either. And I
did not suspect ifup as the culprit because I did have a working network
access.

Yes, the man page mentions that this is expected behavior. But given
that it is difficult to debug, and there is real breakage when
network-manager is used, I think that it would be preferable to actually
return an error.

Thanks,
~David

-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages ifupdown depends on:
ii  adduser  3.113+nmu3
ii  initscripts  2.88dsf-58
ii  iproute  1:3.16.0-2
ii  iproute2 3.16.0-2
ii  libc62.19-13
ii  lsb-base 4.1+Debian13+nmu1

Versions of packages ifupdown recommends:
ii  isc-dhcp-client [dhcp-client]  4.3.1-5

Versions of packages ifupdown suggests:
ii  net-tools  1.60-26+b1
ii  ppp2.4.6-3
pn  rdnssd none

-- no debconf information


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

Re: [DRBD-user] 40MBps Sync Limit 8.4.4 and Above

[David Mohr]

On 2014-11-19 14:29, Matt Kereczman wrote:

On 11/18/2014 09:44 AM, Darren Ginter wrote:

Hello all,

With Ubuntu 14.04 (drbd 8.4.4), I cannot get more than 40MBps out of 
the

initial DRBD initialization sync no matter what settings (sync-rate,
c-max-rate, c-min-rate, etc).  I've been playing with this for tens of
hours now.  I've tried drbd 8.4.5 and above to no avail.

With Ubuntu 12.04 (drbd 8.4.3) I can max out a 10GbE NIC without issue 
on

the same hardware.


You may need to tune 'max-buffers' and 'max-epoch-size' to get some 
more

performance out of the secondary node. This is outlined in the user's
guide (section 15.3.1).

I have the values below configured on a system running DRBD 8.4.5,
resyncing at ~400MiB/s (almost the max write speed of the backing 
disk):


resource resource {
  net {
max-buffers 80k;
max-epoch-size 20k;
...
  }
  ...
}

Those settings are a little extreme; start at 8000, and tune 
accordingly.


I'd suggest to add this info as a note to the docs @ 
http://www.drbd.org/users-guide-emb/s-configure-sync-rate.html .


Yes, the drbdsetup man page already explains that these parameters may 
be important when you can't saturate link speed, but finding them in the 
first place is not as easy as it should be IMHO.


Thanks,
~David
___
drbd-user mailing list
drbd-user@lists.linbit.com
http://lists.linbit.com/mailman/listinfo/drbd-user

Bug#769612: unblock: bcache-tools/1.0.7-1

[David Mohr]

On 2014-12-03 14:56, Jack Douglas wrote:
I appreciate your additional input, but I'm afraid it doesn't persuade 
me

to
change my mind. If the maintainer is on the ball, it could be in 
jessie-

backports very soon after release.


That's a very gracious reply, and I'm grateful that you gave it further
consideration even if the answer remains no :)


I second that, and thank you Jack for the help.

Let's shoot for a quick upload to jessie-backports!

~David


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

Bug#769612: unblock: bcache-tools/1.0.7-1

[David Mohr]

On 2014-12-03 14:56, Jack Douglas wrote:
I appreciate your additional input, but I'm afraid it doesn't persuade 
me

to
change my mind. If the maintainer is on the ball, it could be in 
jessie-

backports very soon after release.


That's a very gracious reply, and I'm grateful that you gave it further
consideration even if the answer remains no :)


I second that, and thank you Jack for the help.

Let's shoot for a quick upload to jessie-backports!

~David


--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/6cb64ceb5e3782822a96fb841c8c2...@de.mcbf.net

Bug#729924: Ping

[David Mohr]

Hi,

I just wanted to say that this is an active issue for me. I am 
developing code in Python 3, and python-mode etc don't work when started 
with Python 2 since then they don't recognize the Python 3 syntax. While 
Python 2 is still in widespread use, Python 3 usage is rising and it is 
a shame that vim can't handle it out of the box.


I don't have time to actively work on this issue, but I'd be more than 
happy to test any patches.


Thanks,
~David


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

Bug#767257: grub-choose-default: Please upgrade to upstream version 1.1

[David Mohr]

Package: grub-choose-default
Version: 1.1-1
Severity: wishlist

Dear Maintainer,

please upgrade to the newer upstream version 1.1 which supports grub2
(which would close #714276). I can help with the packaging if required.
Thanks!

~David


-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages grub-choose-default depends on:
ii  libatk1.0-0  2.14.0-1
ii  libc62.19-12
ii  libcairo21.14.0-2
ii  libfontconfig1   2.11.0-6.1
ii  libfreetype6 2.5.2-2
ii  libgdk-pixbuf2.0-0   2.31.1-2+b1
ii  libglib2.0-0 2.42.0-2
ii  libgtk2.0-0  2.24.25-1
ii  libpango-1.0-0   1.36.8-2
ii  libpangocairo-1.0-0  1.36.8-2
ii  libpangoft2-1.0-01.36.8-2

Versions of packages grub-choose-default recommends:
ii  grub-efi  2.02~beta2-15

grub-choose-default suggests no packages.

-- no debconf information


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

Bug#762036: nut-nutrition: File conflict with nut-nutrition-data on upgrade

[David Mohr]

Package: nut-nutrition
Version: 20.1-1
Severity: important

Dear Maintainer,

I just ran a dist-upgrade and it fails on nut-nutrition-data:

Selecting previously unselected package nut-nutrition-data.
Preparing to unpack .../nut-nutrition-data_20.1-1_all.deb ...
Unpacking nut-nutrition-data (20.1-1) ...
dpkg: error processing archive
/var/cache/apt/archives/nut-nutrition-data_20.1-1_all.deb (--unpack):
 trying to overwrite '/usr/share/nut-nutrition/WEIGHT.lib', which is
 also in package nut-nutrition 19.2-1

Of course there is an easy workaround:
$ dpkg -r nut-nutrition  apt-get install nut-nutrition

Thanks,
~David

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages nut-nutrition depends on:
ii  libc6   2.19-11
ii  nut-nutrition-data  20.1-1

nut-nutrition recommends no packages.

nut-nutrition suggests no packages.

-- no debconf information


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

Bug#708132: bcache-tools ITP

[David Mohr]

About the licensing  copyright: I emailed Gabriel and Kent Overstreet 
on 2014-06-02 but did not get a reply. I admit though that I didn't 
follow up afterwards.


On 2014-09-17 05:55, Robie Basak wrote:

As far as I know this is the status of the git trees:


1) http://evilpiepirate.org/git/bcache-tools.git


Original sources, no changes in a while.


2) git://github.com/g2p/bcache-tools.git


First clone by Gabriel, contains work and bugfixes to the bcache-tools 
userland and some initial Debian packaging.



3) git://github.com/squisher/bcache-tools.git


My work on Debian packaging. I set Vcs-Git to g2p's version instead of 
mine because that seems to be the most active upstream repository. I 
thought this was relevant for uscan, but obviously I was wrong (as was 
pointed out on mentors.debian.net).



4) git://github.com/basak/bcache-tools.git


Vcs-Git points to 2 (g2p). I also noted that the github branches seem 
to

contain commits to the upstream source, too, that aren't present in the
upstream repository (1).


I thought that (1) is historic at this point and considered (2) the 
upstream. I did not verify that though.


I would suggest to co-maintain the package on 
https://alioth.debian.org/projects/collab-maint


I think it would be easiest to upload, since I think it's good to go 
and

this will at least result in a definitive packaging state that we can
work from.


Fine by me.

In the meantime, I think branch 3 contained everything, so I cloned 
that

one to add my two commits. To keep Vcs-Git correct g2p should pull my
commits, or else we can change Vcs-Git.


Right, see above.


So in summary:

1) Define and agree maintainers.


I'd like to get my feet wet and co-maintain, if you're interested.


2) g2p to pull my commits, or we agree to change Vcs-Git, or we drop
Vcs-Git for now.


I'd say point it at 3) or at collab-maint, if that's where the packaging 
ends up being.



3) Upload. Either my colleague (James Page) can do it as he's already
reviewed the packaging itself, or someone else. Let me know if there 
are

any objections to James uploading.


Bernd Zeimetz, I added him to the CC, was willing to sponsor the package 
once it was ready. But since he has been pretty busy recently, I don't 
think he'll object to James uploading. I definitely don't; it'd be 
awesome to get this finally into the official repository!



4) Sort out which trees are canonical upstream and packaging branches,
and push all commits to those places.


I very much agree.

~David


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

Bug#708132: bcache-tools ITP

[David Mohr]

About the licensing  copyright: I emailed Gabriel and Kent Overstreet 
on 2014-06-02 but did not get a reply. I admit though that I didn't 
follow up afterwards.


On 2014-09-17 05:55, Robie Basak wrote:

As far as I know this is the status of the git trees:


1) http://evilpiepirate.org/git/bcache-tools.git


Original sources, no changes in a while.


2) git://github.com/g2p/bcache-tools.git


First clone by Gabriel, contains work and bugfixes to the bcache-tools 
userland and some initial Debian packaging.



3) git://github.com/squisher/bcache-tools.git


My work on Debian packaging. I set Vcs-Git to g2p's version instead of 
mine because that seems to be the most active upstream repository. I 
thought this was relevant for uscan, but obviously I was wrong (as was 
pointed out on mentors.debian.net).



4) git://github.com/basak/bcache-tools.git


Vcs-Git points to 2 (g2p). I also noted that the github branches seem 
to

contain commits to the upstream source, too, that aren't present in the
upstream repository (1).


I thought that (1) is historic at this point and considered (2) the 
upstream. I did not verify that though.


I would suggest to co-maintain the package on 
https://alioth.debian.org/projects/collab-maint


I think it would be easiest to upload, since I think it's good to go 
and

this will at least result in a definitive packaging state that we can
work from.


Fine by me.

In the meantime, I think branch 3 contained everything, so I cloned 
that

one to add my two commits. To keep Vcs-Git correct g2p should pull my
commits, or else we can change Vcs-Git.


Right, see above.


So in summary:

1) Define and agree maintainers.


I'd like to get my feet wet and co-maintain, if you're interested.


2) g2p to pull my commits, or we agree to change Vcs-Git, or we drop
Vcs-Git for now.


I'd say point it at 3) or at collab-maint, if that's where the packaging 
ends up being.



3) Upload. Either my colleague (James Page) can do it as he's already
reviewed the packaging itself, or someone else. Let me know if there 
are

any objections to James uploading.


Bernd Zeimetz, I added him to the CC, was willing to sponsor the package 
once it was ready. But since he has been pretty busy recently, I don't 
think he'll object to James uploading. I definitely don't; it'd be 
awesome to get this finally into the official repository!



4) Sort out which trees are canonical upstream and packaging branches,
and push all commits to those places.


I very much agree.

~David


--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/0ecf62b8d8b1632a283805e759954...@de.mcbf.net

Re: bcache-tools ITP

[David Mohr]

About the licensing  copyright: I emailed Gabriel and Kent Overstreet 
on 2014-06-02 but did not get a reply. I admit though that I didn't 
follow up afterwards.


On 2014-09-17 05:55, Robie Basak wrote:

As far as I know this is the status of the git trees:


1) http://evilpiepirate.org/git/bcache-tools.git


Original sources, no changes in a while.


2) git://github.com/g2p/bcache-tools.git


First clone by Gabriel, contains work and bugfixes to the bcache-tools 
userland and some initial Debian packaging.



3) git://github.com/squisher/bcache-tools.git


My work on Debian packaging. I set Vcs-Git to g2p's version instead of 
mine because that seems to be the most active upstream repository. I 
thought this was relevant for uscan, but obviously I was wrong (as was 
pointed out on mentors.debian.net).



4) git://github.com/basak/bcache-tools.git


Vcs-Git points to 2 (g2p). I also noted that the github branches seem 
to

contain commits to the upstream source, too, that aren't present in the
upstream repository (1).


I thought that (1) is historic at this point and considered (2) the 
upstream. I did not verify that though.


I would suggest to co-maintain the package on 
https://alioth.debian.org/projects/collab-maint


I think it would be easiest to upload, since I think it's good to go 
and

this will at least result in a definitive packaging state that we can
work from.


Fine by me.

In the meantime, I think branch 3 contained everything, so I cloned 
that

one to add my two commits. To keep Vcs-Git correct g2p should pull my
commits, or else we can change Vcs-Git.


Right, see above.


So in summary:

1) Define and agree maintainers.


I'd like to get my feet wet and co-maintain, if you're interested.


2) g2p to pull my commits, or we agree to change Vcs-Git, or we drop
Vcs-Git for now.


I'd say point it at 3) or at collab-maint, if that's where the packaging 
ends up being.



3) Upload. Either my colleague (James Page) can do it as he's already
reviewed the packaging itself, or someone else. Let me know if there 
are

any objections to James uploading.


Bernd Zeimetz, I added him to the CC, was willing to sponsor the package 
once it was ready. But since he has been pretty busy recently, I don't 
think he'll object to James uploading. I definitely don't; it'd be 
awesome to get this finally into the official repository!



4) Sort out which trees are canonical upstream and packaging branches,
and push all commits to those places.


I very much agree.

~David
--
To unsubscribe from this list: send the line unsubscribe linux-bcache in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Bug#484974: ntpdate's ip-up script runs even for virtual interfaces

[David Mohr]

Package: ntpdate
Version: 1:4.2.6.p5+dfsg-3.1
Followup-For: Bug #484974

Dear Maintainer,

I also think this is a problem, specially on hosts with a lot of alias
interfaces.

This may possibly be related to
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=647465
and
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=649692

I attached a patch to fix it.

Thanks,
~David

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages ntpdate depends on:
ii  dpkg 1.17.13
ii  libc62.19-10
ii  libssl1.0.0  1.0.1i-2
ii  netbase  5.2

Versions of packages ntpdate recommends:
ii  lockfile-progs  0.1.17

ntpdate suggests no packages.

-- no debconf information
--- /etc/network/if-up.d/ntpdate~   2014-09-02 18:01:01.0 +0200
+++ /etc/network/if-up.d/ntpdate2014-09-02 18:50:34.0 +0200
@@ -16,6 +16,11 @@
exit 0
 fi
 
+# Check if an alias interface is being brought up. If so, don't do anything.
+if echo $IFACE | grep -q : ; then
+   exit 0
+fi
+
 # Check whether ntpdate was removed but not purged; it's useless to wait for 
 # it in that case.
 if [ ! -x /usr/sbin/ntpdate-debian ]  [ -d /usr/sbin ]; then

Bug#484974: #484974

[David Mohr]

tag 484974 patch

thanks


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

[Bug 1317125] Re: Xfburn crashes when trying to add files to data composition on Lubuntu 14.04

[David Mohr]

I'm discussing this here because the bug is likely ubuntu specific:

There's an add window (not dialog), after a button click the callback
add_cb() runs which calls gtk_widget_destroy () on the add window  (see
attachment for callback).

This code was introduced in e18bcd65f8b02514c8f1ef8ec96b183a721fa727 in
2012, but because of my lazy release policy I have no clue when/if that
was included in ubuntu before.

But in any case, since it works just fine on Debian 6  sid I suspect
some ubuntu patches to be responsible.

** Attachment added: gdb.txt
   
https://bugs.launchpad.net/ubuntu/+source/xfburn/+bug/1317125/+attachment/4124497/+files/gdb.txt

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1317125

Title:
  Xfburn crashes when trying to add files to data composition on Lubuntu
  14.04

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xfburn/+bug/1317125/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Bug#708132: bcache-tools ITP

[David Mohr]

Hi Robie,

thanks for checking in! It's good to know there is interest.

I think I have the package in pretty good shape, see 
https://github.com/squisher/bcache-tools/tree/debian-mentors . Bernd 
(bzed) was the sponsor for when Gabriel uploaded to mentors. That's not 
visible anymore because the package was once removed due to inactivity. 
He is still willing to sponsor the package, but has been pretty busy as 
of lately.


My current hung-up is that I'm fighting with a smart card setup on sid 
to do the signing since the reader in my lenovo turned out to be flaky. 
So the version on debian-mentors is lacking some improvements which you 
can see on github.


So my current todo is:
1. get gpg to work with my smartcard
2. get a collab-maint account
3. upload new version to mentors

Lintian is pretty happy, and it's not a particularly complicated 
package, so I think once I get 1. out of the way, the rest should move 
more quickly.


I'm open to co-maintaining, if anyone wants to jump in and help.

~David

P.S. I'll forward this to bzed so that he can chime in if need be.

On 2014-05-30 09:57, Robie Basak wrote:

Gabriel, David,

I'd like to help with getting this package into Debian. What is this
waiting on right now, please, and how can I help speed things up?

I'd also like to see bcache-tools in Ubuntu, and I see that Gabriel is
already maintaining a PPA on Launchpad. I am not a DD (but can poke
several), but I can sponsor packages into Ubuntu. I can upload to 
Ubuntu

ahead of a Debian upload if things are held up at the Debian end, but
I'd prefer to see the package going in via Debian.

I see a recent upload to mentors by David. Is this currently a 
candidate

for upload, or there more work to be done? Do you need a sponsor, or do
you have someone looking it already?

On a separate (not-really-Debian) note, it'd be great to see somebody
maintaining bcache-tools stable releases in Ubuntu for bugfixes and so
on. Gabriel (or anyone else), if you're interested, I'd be happy to
sponsor these or otherwise coordinate against your PPA with you, rather
than step on your toes.

Robie



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

Bug#708132: bcache-tools ITP

[David Mohr]

Hi Robie,

thanks for checking in! It's good to know there is interest.

I think I have the package in pretty good shape, see 
https://github.com/squisher/bcache-tools/tree/debian-mentors . Bernd 
(bzed) was the sponsor for when Gabriel uploaded to mentors. That's not 
visible anymore because the package was once removed due to inactivity. 
He is still willing to sponsor the package, but has been pretty busy as 
of lately.


My current hung-up is that I'm fighting with a smart card setup on sid 
to do the signing since the reader in my lenovo turned out to be flaky. 
So the version on debian-mentors is lacking some improvements which you 
can see on github.


So my current todo is:
1. get gpg to work with my smartcard
2. get a collab-maint account
3. upload new version to mentors

Lintian is pretty happy, and it's not a particularly complicated 
package, so I think once I get 1. out of the way, the rest should move 
more quickly.


I'm open to co-maintaining, if anyone wants to jump in and help.

~David

P.S. I'll forward this to bzed so that he can chime in if need be.

On 2014-05-30 09:57, Robie Basak wrote:

Gabriel, David,

I'd like to help with getting this package into Debian. What is this
waiting on right now, please, and how can I help speed things up?

I'd also like to see bcache-tools in Ubuntu, and I see that Gabriel is
already maintaining a PPA on Launchpad. I am not a DD (but can poke
several), but I can sponsor packages into Ubuntu. I can upload to 
Ubuntu

ahead of a Debian upload if things are held up at the Debian end, but
I'd prefer to see the package going in via Debian.

I see a recent upload to mentors by David. Is this currently a 
candidate

for upload, or there more work to be done? Do you need a sponsor, or do
you have someone looking it already?

On a separate (not-really-Debian) note, it'd be great to see somebody
maintaining bcache-tools stable releases in Ubuntu for bugfixes and so
on. Gabriel (or anyone else), if you're interested, I'd be happy to
sponsor these or otherwise coordinate against your PPA with you, rather
than step on your toes.

Robie



--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/175f4ae1c88f5506984eb3a167382...@de.mcbf.net

Bug#748253: aspell-de fails to install because /var/lib/aspell doesn't exist

[David Mohr]

Package: aspell-de
Version: 20131206-3
Severity: grave
Justification: renders package unusable

Dear Maintainer,

I'm upgrading aspell-de from 20131206-2 to 20131206-3 and get the
following error message:

% sudo apt-get -f install
Reading package lists... Done
Building dependency tree   
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 52 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Setting up aspell-de (20131206-3) ...
/var/lib/dpkg/info/aspell-de.postinst: 58: 
/var/lib/dpkg/info/aspell-de.postinst: cannot create /var/lib/aspell/de.compat: 
Directory nonexistent
dpkg: error processing package aspell-de (--configure):
 subprocess installed post-installation script returned error exit status 2
Processing triggers for dictionaries-common (1.23.2) ...
Errors were encountered while processing:
 aspell-de
E: Sub-process /usr/bin/dpkg returned an error code (1)

~David

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages aspell-de depends on:
ii  aspell   0.60.7~20110707-1
ii  dictionaries-common  1.23.2

aspell-de recommends no packages.

aspell-de suggests no packages.

-- no debconf information


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

Bug#748253: aspell-de fails to install because /var/lib/aspell doesn't exist

[David Mohr]

Hi Roland,

On 2014-05-15 10:24, Roland Rosenfeld wrote:

On Thu, 15 May 2014, David Mohr wrote:


Package: aspell-de
Version: 20131206-3
Severity: grave
Justification: renders package unusable



I'm upgrading aspell-de from 20131206-2 to 20131206-3 and get the
following error message:


/var/lib/dpkg/info/aspell-de.postinst: 58: 
/var/lib/dpkg/info/aspell-de.postinst: cannot create 
/var/lib/aspell/de.compat: Directory nonexistent


You're right, there is a problem when you have no other aspell
dictionary package installed and upgrade from older aspell-de versions
to 20131206-3.

I'll try to fix this soon (seems to be necessary to create
/var/lib/aspell in postinst and not only preinst, since it would
otherwise be removed when the old aspell-de package is removed).

As a quick work around just install aspell-de again, this should work
without a problem (at least on my system).


Installing aspell-en also fixed it; I guess because I didn't have it 
installed before.


Danke,
~David


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

Bug#748253: aspell-de fails to install because /var/lib/aspell doesn't exist

[David Mohr]

Package: aspell-de
Version: 20131206-3
Severity: grave
Justification: renders package unusable

Dear Maintainer,

I'm upgrading aspell-de from 20131206-2 to 20131206-3 and get the
following error message:

% sudo apt-get -f install
Reading package lists... Done
Building dependency tree   
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 52 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Setting up aspell-de (20131206-3) ...
/var/lib/dpkg/info/aspell-de.postinst: 58: 
/var/lib/dpkg/info/aspell-de.postinst: cannot create /var/lib/aspell/de.compat: 
Directory nonexistent
dpkg: error processing package aspell-de (--configure):
 subprocess installed post-installation script returned error exit status 2
Processing triggers for dictionaries-common (1.23.2) ...
Errors were encountered while processing:
 aspell-de
E: Sub-process /usr/bin/dpkg returned an error code (1)

~David

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages aspell-de depends on:
ii  aspell   0.60.7~20110707-1
ii  dictionaries-common  1.23.2

aspell-de recommends no packages.

aspell-de suggests no packages.

-- no debconf information


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

Bug#748253: aspell-de fails to install because /var/lib/aspell doesn't exist

[David Mohr]

Hi Roland,

On 2014-05-15 10:24, Roland Rosenfeld wrote:

On Thu, 15 May 2014, David Mohr wrote:


Package: aspell-de
Version: 20131206-3
Severity: grave
Justification: renders package unusable



I'm upgrading aspell-de from 20131206-2 to 20131206-3 and get the
following error message:


/var/lib/dpkg/info/aspell-de.postinst: 58: 
/var/lib/dpkg/info/aspell-de.postinst: cannot create 
/var/lib/aspell/de.compat: Directory nonexistent


You're right, there is a problem when you have no other aspell
dictionary package installed and upgrade from older aspell-de versions
to 20131206-3.

I'll try to fix this soon (seems to be necessary to create
/var/lib/aspell in postinst and not only preinst, since it would
otherwise be removed when the old aspell-de package is removed).

As a quick work around just install aspell-de again, this should work
without a problem (at least on my system).


Installing aspell-en also fixed it; I guess because I didn't have it 
installed before.


Danke,
~David


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

Bug#745588: ITP: grub-choose-default -- A GUI for easily changing the default in grub2

[David Mohr]

Package: wnpp
Severity: wishlist
Owner: David Mohr b...@da.mcbf.net

* Package name: grub-choose-default
  Version : 1.1
  Upstream Author : David Mohr da...@mcbf.net
* URL : http://de.mcbf.net/david/grubchoosedefault/
* License : GPL
  Programming Lang: C
  Description : A GUI for easily changing the default in grub2

A GUI for changing the default for grub2, either permanently or for the
next reboot only. It is specially useful for making one time excursion
to another OS and safely returning to the Debian homeland on the next
reboot. It can be considered a GUI version of grub-set-default and
grub-reboot.

I think it is feasible to maintain this package by myself: I am the
author, the package is fairly simple, and the grub config is not likely
to change frequently.

A while back I published Ubuntu packages at
https://launchpad.net/~bugs-da/+archive/grub-choose-default/ which I
would use as a basis for the Debian packages.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140423042900.9997.34383.report...@alucardo.nm.mcbf.net

Bug#745588: ITP: grub-choose-default -- A GUI for easily changing the default in grub2

[David Mohr]

Package: wnpp
Severity: wishlist
Owner: David Mohr b...@da.mcbf.net

* Package name: grub-choose-default
  Version : 1.1
  Upstream Author : David Mohr da...@mcbf.net
* URL : http://de.mcbf.net/david/grubchoosedefault/
* License : GPL
  Programming Lang: C
  Description : A GUI for easily changing the default in grub2

A GUI for changing the default for grub2, either permanently or for the
next reboot only. It is specially useful for making one time excursion
to another OS and safely returning to the Debian homeland on the next
reboot. It can be considered a GUI version of grub-set-default and
grub-reboot.

I think it is feasible to maintain this package by myself: I am the
author, the package is fairly simple, and the grub config is not likely
to change frequently.

A while back I published Ubuntu packages at
https://launchpad.net/~bugs-da/+archive/grub-choose-default/ which I
would use as a basis for the Debian packages.


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

Bug#745588: ITP: grub-choose-default -- A GUI for easily changing the default in grub2

[David Mohr]

Package: wnpp
Severity: wishlist
Owner: David Mohr b...@da.mcbf.net

* Package name: grub-choose-default
  Version : 1.1
  Upstream Author : David Mohr da...@mcbf.net
* URL : http://de.mcbf.net/david/grubchoosedefault/
* License : GPL
  Programming Lang: C
  Description : A GUI for easily changing the default in grub2

A GUI for changing the default for grub2, either permanently or for the
next reboot only. It is specially useful for making one time excursion
to another OS and safely returning to the Debian homeland on the next
reboot. It can be considered a GUI version of grub-set-default and
grub-reboot.

I think it is feasible to maintain this package by myself: I am the
author, the package is fairly simple, and the grub config is not likely
to change frequently.

A while back I published Ubuntu packages at
https://launchpad.net/~bugs-da/+archive/grub-choose-default/ which I
would use as a basis for the Debian packages.


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140423042900.9997.34383.report...@alucardo.nm.mcbf.net

[Xfce4-commits] xfburn:master Use burn_drive_snooze after being done with a drive.

[David Mohr]

Updating branch refs/heads/master
 to b960f80263d438236cd1ae772863c1643e149430 (commit)
   from 219317392c393eefefa7cf70a09d1fc0ae9ca88d (commit)

commit b960f80263d438236cd1ae772863c1643e149430
Author: David Mohr da...@mcbf.net
Date:   Mon Feb 24 22:24:36 2014 -0700

Use burn_drive_snooze after being done with a drive.

Thanks Thomas.

 xfburn/xfburn-device-list.c |1 +
 xfburn/xfburn-device.c  |1 +
 2 files changed, 2 insertions(+)

diff --git a/xfburn/xfburn-device-list.c b/xfburn/xfburn-device-list.c
index 5def1aa..6c25b0c 100644
--- a/xfburn/xfburn-device-list.c
+++ b/xfburn/xfburn-device-list.c
@@ -299,6 +299,7 @@ get_libburn_device_list (XfburnDeviceList *devlist)
   g_message (Ignoring reader '%s' at '%s', name, addr);
   g_object_unref (device);
 }
+burn_drive_snooze(drives[i].drive, 0);
   }
 
   burn_drive_info_free (drives);
diff --git a/xfburn/xfburn-device.c b/xfburn/xfburn-device.c
index a799013..30b4e26 100644
--- a/xfburn/xfburn-device.c
+++ b/xfburn/xfburn-device.c
@@ -511,6 +511,7 @@ xfburn_device_release (struct burn_drive_info *drive_info, 
gboolean eject)
 {
   int ret;
 
+  burn_drive_snooze (drive_info-drive, 0);
   burn_drive_release (drive_info-drive, eject);
 
   ret = burn_drive_info_forget (drive_info, 0);
___
Xfce4-commits mailing list
Xfce4-commits@xfce.org
https://mail.xfce.org/mailman/listinfo/xfce4-commits

[Bug 1282937] Re: Please package xfburn 0.5.0

[David Mohr]

I think it is important to note that all the major changes in 0.5.0 have
been thoroughly tested since they were included as patches to 0.4.3
before. This means that accepting this package has a low chance of
regressions and will provide the advantages that others have already
mentioned.

Sorry for getting the release so late out of the door!

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1282937

Title:
  Please package xfburn 0.5.0

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xfburn/+bug/1282937/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Xfce4-commits] xfburn:master Remove MimeType from .desktop action entry.

[David Mohr]

Updating branch refs/heads/master
 to c14bdb78d9f95e01c6d99a43914fd59db283c470 (commit)
   from eac896c72e37adbf4799989961d24aa9f59ab51b (commit)

commit c14bdb78d9f95e01c6d99a43914fd59db283c470
Author: David Mohr da...@mcbf.net
Date:   Thu Feb 20 09:55:26 2014 -0700

Remove MimeType from .desktop action entry.

 xfburn.desktop.in |1 -
 1 file changed, 1 deletion(-)

diff --git a/xfburn.desktop.in b/xfburn.desktop.in
index dbea077..63e296c 100644
--- a/xfburn.desktop.in
+++ b/xfburn.desktop.in
@@ -14,7 +14,6 @@ StartupNotify=true
 Actions=BurnImage;
 
 [Desktop Action BurnImage]
-MimeType=application/x-cd-image;
 Icon=media-cdrom
 Exec=xfburn -i %f
 _Name=Burn Image (xfburn)
___
Xfce4-commits mailing list
Xfce4-commits@xfce.org
https://mail.xfce.org/mailman/listinfo/xfce4-commits

[Xfce4-commits] xfburn:master Correctly use stock_xfburn instead of xfburn (closes #9669)

[David Mohr]

Updating branch refs/heads/master
 to 202b168715dfeed1f99cde1fb10f5da2e2d76458 (commit)
   from c14bdb78d9f95e01c6d99a43914fd59db283c470 (commit)

commit 202b168715dfeed1f99cde1fb10f5da2e2d76458
Author: David Mohr da...@mcbf.net
Date:   Thu Feb 20 10:02:54 2014 -0700

Correctly use stock_xfburn instead of xfburn (closes #9669)

Thanks Christian!

 icons/16x16/Makefile.am |2 +-
 icons/16x16/{xfburn.png = stock_xfburn.png}|  Bin 962 - 962 bytes
 icons/22x22/Makefile.am |2 +-
 icons/22x22/{xfburn.png = stock_xfburn.png}|  Bin 1378 - 1378 bytes
 icons/24x24/Makefile.am |2 +-
 icons/24x24/{xfburn.png = stock_xfburn.png}|  Bin 1566 - 1566 bytes
 icons/32x32/Makefile.am |2 +-
 icons/32x32/{xfburn.png = stock_xfburn.png}|  Bin 2230 - 2230 bytes
 icons/48x48/Makefile.am |2 +-
 icons/48x48/{xfburn.png = stock_xfburn.png}|  Bin 4073 - 4073 bytes
 icons/scalable/Makefile.am  |2 +-
 icons/scalable/{xfburn.svg = stock_xfburn.svg} |0
 12 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/icons/16x16/Makefile.am b/icons/16x16/Makefile.am
index ee66fb6..8997a8d 100644
--- a/icons/16x16/Makefile.am
+++ b/icons/16x16/Makefile.am
@@ -6,7 +6,7 @@ icons_DATA =
\
stock_xfburn-data-copy.png  \
stock_xfburn-new-data-composition.png   \
stock_xfburn-import-session.png \
-   xfburn.png
+   stock_xfburn.png

 EXTRA_DIST =   \
$(icons_DATA)
diff --git a/icons/16x16/xfburn.png b/icons/16x16/stock_xfburn.png
similarity index 100%
rename from icons/16x16/xfburn.png
rename to icons/16x16/stock_xfburn.png
diff --git a/icons/22x22/Makefile.am b/icons/22x22/Makefile.am
index b9262e5..c368cac 100644
--- a/icons/22x22/Makefile.am
+++ b/icons/22x22/Makefile.am
@@ -6,7 +6,7 @@ icons_DATA =
\
stock_xfburn-data-copy.png  \
stock_xfburn-new-data-composition.png   \
stock_xfburn-import-session.png \
-   xfburn.png
+   stock_xfburn.png

 EXTRA_DIST =   \
$(icons_DATA)
diff --git a/icons/22x22/xfburn.png b/icons/22x22/stock_xfburn.png
similarity index 100%
rename from icons/22x22/xfburn.png
rename to icons/22x22/stock_xfburn.png
diff --git a/icons/24x24/Makefile.am b/icons/24x24/Makefile.am
index 1b71806..7eef446 100644
--- a/icons/24x24/Makefile.am
+++ b/icons/24x24/Makefile.am
@@ -8,7 +8,7 @@ icons_DATA =
\
stock_xfburn-data-copy.png  \
stock_xfburn-new-data-composition.png   \
stock_xfburn-import-session.png \
-   xfburn.png
+   stock_xfburn.png

 EXTRA_DIST =   \
$(icons_DATA)
diff --git a/icons/24x24/xfburn.png b/icons/24x24/stock_xfburn.png
similarity index 100%
rename from icons/24x24/xfburn.png
rename to icons/24x24/stock_xfburn.png
diff --git a/icons/32x32/Makefile.am b/icons/32x32/Makefile.am
index 756bc2b..0be7876 100644
--- a/icons/32x32/Makefile.am
+++ b/icons/32x32/Makefile.am
@@ -6,7 +6,7 @@ icons_DATA =
\
stock_xfburn-data-copy.png  \
stock_xfburn-new-data-composition.png   \
stock_xfburn-import-session.png \
-   xfburn.png
+   stock_xfburn.png
 
 EXTRA_DIST =   \
$(icons_DATA)
diff --git a/icons/32x32/xfburn.png b/icons/32x32/stock_xfburn.png
similarity index 100%
rename from icons/32x32/xfburn.png
rename to icons/32x32/stock_xfburn.png
diff --git a/icons/48x48/Makefile.am b/icons/48x48/Makefile.am
index e5c3fa2..38240fc 100644
--- a/icons/48x48/Makefile.am
+++ b/icons/48x48/Makefile.am
@@ -6,7 +6,7 @@ icons_DATA =
\
stock_xfburn-data-copy.png  \
stock_xfburn-new-data-composition.png   \
stock_xfburn-import-session.png \
-   xfburn.png
+   stock_xfburn.png
 
 EXTRA_DIST =   \
$(icons_DATA)
diff --git a/icons/48x48/xfburn.png b/icons/48x48

[Xfce4-commits] xfburn|xfburn-0.5.0 Creating annotated tag xfburn-0.5.0

[David Mohr]

Updating annotated tag refs/tags/xfburn-0.5.0
 as new annotated tag
 to c6c6d67e88c790138e26e6289c9d9390fea285fb (tag)
   succeeds xfburn-0.4.3-341-g202b168
  tagged by David Mohr da...@mcbf.net
 on 2014-02-20 19:15 +0100

David Mohr (1):
  Update docs for 0.5.0

___
Xfce4-commits mailing list
Xfce4-commits@xfce.org
https://mail.xfce.org/mailman/listinfo/xfce4-commits

Bug#691151: CC

[David Mohr]

[I reopened the bug, but I didn't realize I had to explicitly cc to have 
my reasoning be accessible, sorry]


Even if the mounts are equivalent at the kernel level, there certainly 
is information lost compared to the mtab in squeeze: namely where within 
the filesystem the bind mount originates.


Example:

david@feline:~/  mount | grep '/home '
/dev/mapper/vghs-home on /home type ext4 (rw)
david@feline:~/  sudo mount -o bind /home/david/tmp /mnt
david@feline:~/  cat /proc/mounts | grep 'vghs-home'
/dev/mapper/vghs-home /home ext4 
rw,relatime,user_xattr,acl,barrier=1,data=ordered 0 0
/dev/mapper/vghs-home /mnt ext4 
rw,relatime,user_xattr,acl,barrier=1,data=ordered 0 0


The 2nd entry is for the bind mount. In squeeze the mtab contained:
/home/david/tmp on /mnt type none (rw,bind)

So how do I figure out that /mnt refers to '/tmp' inside the device 
/dev/mapper/vghs-home in wheezy?


Thanks,
~David


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

[Xfce4-commits] xfburn:master g_cond and g_mutex updates (deprecated)

[David Mohr]

Updating branch refs/heads/master
 to cc8777fa30187a310fb6d8acd08122da29f1b2c0 (commit)
   from 295971642a1c154ec354a293338e760c02294201 (commit)

commit cc8777fa30187a310fb6d8acd08122da29f1b2c0
Author: David Mohr da...@mcbf.net
Date:   Tue Dec 3 22:11:20 2013 -0700

g_cond and g_mutex updates (deprecated)

 xfburn/xfburn-transcoder-gst.c |   49 ++--
 1 file changed, 27 insertions(+), 22 deletions(-)

diff --git a/xfburn/xfburn-transcoder-gst.c b/xfburn/xfburn-transcoder-gst.c
index b0955cf..52ca935 100644
--- a/xfburn/xfburn-transcoder-gst.c
+++ b/xfburn/xfburn-transcoder-gst.c
@@ -115,6 +115,7 @@ typedef struct {
   XfburnTranscoderGstState state;
   GCond *gst_cond;
   GMutex *gst_mutex;
+  gboolean gst_done;
   gboolean is_audio;
   gint64 duration;
 
@@ -128,7 +129,7 @@ typedef struct {
 
 /* constants */
 
-#define SIGNAL_WAIT_TIMEOUT_MICROS 150
+#define SIGNAL_WAIT_TIMEOUT_MS 1500
 
 #define SIGNAL_SEND_ITERATIONS 10
 /* SIGNAL_SEND_TIMEOUT_MICROS is the total time,
@@ -213,11 +214,11 @@ xfburn_transcoder_gst_init (XfburnTranscoderGst * obj)
 
   /* the condition is used to signal that
* gst has returned information */
-  priv-gst_cond = g_cond_new ();
+  g_cond_init (priv-gst_cond);
 
   /* if the mutex is locked, then we're not currently seeking
* information from gst */
-  priv-gst_mutex = g_mutex_new ();
+  g_mutex_init (priv-gst_mutex);
   g_mutex_lock (priv-gst_mutex);
 }
 
@@ -403,6 +404,8 @@ signal_identification_done (XfburnTranscoderGst *trans, 
const char *dbg_res)
   DBG (Trying to lock mutex (%s), dbg_res);
 #endif
 
+  priv-gst_done = TRUE;
+
   /* There is no g_mutex_lock_timed, so emulate it with a loop.
 * I have never seen this getting hung here, but one never knows! */
   for (i=0; iSIGNAL_SEND_ITERATIONS; i++) {
@@ -592,6 +595,7 @@ bus_call (GstBus *bus, GstMessage *msg, gpointer data)
 #endif
   }
 
+  priv-gst_done = TRUE;
   g_cond_signal (priv-gst_cond);
   g_mutex_unlock (priv-gst_mutex);
   break;
@@ -763,7 +767,7 @@ get_audio_track (XfburnTranscoder *trans, XfburnAudioTrack 
*atrack, GError **err
   XfburnTranscoderGstPrivate *priv= XFBURN_TRANSCODER_GST_GET_PRIVATE (tgst);
 
   XfburnAudioTrackGst *gtrack;
-  GTimeVal tv;
+  gint64 end_time;
   off_t size;
 
   priv-is_audio = FALSE;
@@ -779,18 +783,19 @@ get_audio_track (XfburnTranscoder *trans, 
XfburnAudioTrack *atrack, GError **err
 #endif
   }
 
-  g_get_current_time (tv);
-  g_time_val_add (tv, SIGNAL_WAIT_TIMEOUT_MICROS);
+  end_time = g_get_monotonic_time () + SIGNAL_WAIT_TIMEOUT_MS * 
G_TIME_SPAN_MILLISECOND;
 #if DEBUG_GST  0
   DBG (Now waiting for identification result);
 #endif
-  if (!g_cond_timed_wait (priv-gst_cond, priv-gst_mutex, tv)) {
-DBG (gst identification timed out);
-recreate_pipeline (tgst);
-g_set_error (error, XFBURN_ERROR, XFBURN_ERROR_GST_TIMEOUT,
- _(Gstreamer did not like this file (detection timed out)));
-return FALSE;
-  }
+  while (!priv-gst_done)
+if (!g_cond_wait_until (priv-gst_cond, priv-gst_mutex, end_time)) {
+  DBG (gst identification timed out);
+  recreate_pipeline (tgst);
+  g_set_error (error, XFBURN_ERROR, XFBURN_ERROR_GST_TIMEOUT,
+   _(Gstreamer did not like this file (detection timed 
out)));
+  return FALSE;
+}
+  priv-gst_done = FALSE;
 #if DEBUG_GST  0
   DBG (Got an identification result );
 #endif
@@ -899,7 +904,7 @@ prepare (XfburnTranscoder *trans, GError **error)
   XfburnTranscoderGst *gst = XFBURN_TRANSCODER_GST (trans);
   XfburnTranscoderGstPrivate *priv= XFBURN_TRANSCODER_GST_GET_PRIVATE (gst);
   gboolean ret;
-  GTimeVal tv;
+  gint64 end_time;
 
   priv-tracks = g_slist_reverse (priv-tracks);
 
@@ -907,14 +912,14 @@ prepare (XfburnTranscoder *trans, GError **error)
   ret = transcode_next_track (gst, error);
 
   //DBG (Waiting for start signal);
-  g_get_current_time (tv);
-  g_time_val_add (tv, SIGNAL_WAIT_TIMEOUT_MICROS);
-  if (!g_cond_timed_wait (priv-gst_cond, priv-gst_mutex, tv)) {
-recreate_pipeline (gst);
-g_set_error (error, XFBURN_ERROR, XFBURN_ERROR_GST_TIMEOUT,
- _(Gstreamer did not want to start transcoding (timed out)));
-return FALSE;
-  }
+  end_time = g_get_monotonic_time () + SIGNAL_WAIT_TIMEOUT_MS * 
G_TIME_SPAN_MILLISECOND;
+  while (!priv-gst_done)
+if (!g_cond_wait_until (priv-gst_cond, priv-gst_mutex, end_time)) {
+  recreate_pipeline (gst);
+  g_set_error (error, XFBURN_ERROR, XFBURN_ERROR_GST_TIMEOUT,
+  _(Gstreamer did not want to start transcoding (timed 
out)));
+  return FALSE;
+}
   //DBG (Got the start signal);
 
   priv-state = XFBURN_TRANSCODER_GST_STATE_TRANSCODING;
___
Xfce4-commits mailing list
Xfce4-commits@xfce.org
https://mail.xfce.org/mailman/listinfo/xfce4-commits

[Xfce4-commits] xfburn:master Bugfix: -d for data composition works again for one file.

[David Mohr]

Updating branch refs/heads/master
 to 411252bfa6c3f5119b330f15e67994512b65fcf9 (commit)
   from 396c82bcbf99459e056673903bbb70ed0a99ab14 (commit)

commit 411252bfa6c3f5119b330f15e67994512b65fcf9
Author: David Mohr da...@mcbf.net
Date:   Mon Dec 9 00:01:35 2013 -0700

Bugfix: -d for data composition works again for one file.

 xfburn/xfburn-main.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xfburn/xfburn-main.c b/xfburn/xfburn-main.c
index aca15fa..696a80b 100644
--- a/xfburn/xfburn-main.c
+++ b/xfburn/xfburn-main.c
@@ -340,7 +340,7 @@ main (int argc, char **argv)
   /*--evaluate parsed command line action 
options-*/
 
   /* heuristic for file names on the commandline */
-  if (argc == 2) {
+  if (argc == 2  !add_data_composition) {
 /* exactly one filename, assume it is an image */
   image_filename = argv[1];
   } else if (argc  2) {
___
Xfce4-commits mailing list
Xfce4-commits@xfce.org
https://mail.xfce.org/mailman/listinfo/xfce4-commits

[Xfce4-commits] xfburn:master g_thread_create - g_thread_new

[David Mohr]

Updating branch refs/heads/master
 to 295971642a1c154ec354a293338e760c02294201 (commit)
   from d1c51cec666de49ecfeb363273547783ceb083eb (commit)

commit 295971642a1c154ec354a293338e760c02294201
Author: David Mohr da...@mcbf.net
Date:   Tue Dec 3 21:15:37 2013 -0700

g_thread_create - g_thread_new

 xfburn/xfburn-audio-composition.c |8 
 xfburn/xfburn-blank-dialog.c  |2 +-
 xfburn/xfburn-burn-audio-cd-composition-dialog.c  |2 +-
 xfburn/xfburn-burn-data-composition-base-dialog.c |4 ++--
 xfburn/xfburn-burn-image-dialog.c |2 +-
 xfburn/xfburn-data-composition.c  |8 
 6 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/xfburn/xfburn-audio-composition.c 
b/xfburn/xfburn-audio-composition.c
index 6ae76c1..dcb2e78 100644
--- a/xfburn/xfburn-audio-composition.c
+++ b/xfburn/xfburn-audio-composition.c
@@ -1027,7 +1027,7 @@ action_add_selected_files (GtkAction *action, 
XfburnAudioComposition *dc)
 priv-selected_files = selected_files;
 
 priv-thread_params = params;
-g_thread_create ((GThreadFunc) thread_add_files_action, params, FALSE, 
NULL);
+g_thread_new (audio_add_selected, (GThreadFunc) thread_add_files_action, 
params);
 
 g_list_foreach (selected_paths, (GFunc) gtk_tree_path_free, NULL);
 g_list_free (selected_paths);
@@ -1788,7 +1788,7 @@ cb_content_drag_data_rcv (GtkWidget * widget, 
GdkDragContext * dc, guint x, guin
   gtk_tree_store_append (GTK_TREE_STORE (model), params-iter_dummy, 
NULL);
 
   priv-thread_params = params;
-  g_thread_create ((GThreadFunc) thread_add_files_drag, params, FALSE, 
NULL);
+  g_thread_new (add_files_drag, (GThreadFunc) thread_add_files_drag, 
params);
 
   gtk_drag_finish (dc, TRUE, FALSE, t);
 } else {
@@ -1851,7 +1851,7 @@ cb_content_drag_data_rcv (GtkWidget * widget, 
GdkDragContext * dc, guint x, guin
 gtk_tree_store_append (GTK_TREE_STORE (model), params-iter_dummy, 
NULL);
 
 priv-thread_params = params;
-g_thread_create ((GThreadFunc) thread_add_files_drag, params, FALSE, 
NULL);
+g_thread_new (audio_add_uri_list, (GThreadFunc) 
thread_add_files_drag, params);
 
 gtk_drag_finish (dc, TRUE, FALSE, t);
   } else {
@@ -2184,7 +2184,7 @@ xfburn_audio_composition_add_files 
(XfburnAudioComposition *dc, GSList * filelis
 xfburn_busy_cursor (priv-content);
 
 priv-thread_params = params;
-g_thread_create ((GThreadFunc) thread_add_files_cli, params, FALSE, NULL);
+g_thread_new (audio_add_files_cli, (GThreadFunc) thread_add_files_cli, 
params);
   }
 }
 
diff --git a/xfburn/xfburn-blank-dialog.c b/xfburn/xfburn-blank-dialog.c
index 638770d..b59abab 100644
--- a/xfburn/xfburn-blank-dialog.c
+++ b/xfburn/xfburn-blank-dialog.c
@@ -515,7 +515,7 @@ xfburn_blank_dialog_response_cb (XfburnBlankDialog * 
dialog, gint response_id, g
 params-device = device;
 params-blank_mode = get_selected_mode (priv);
 params-eject = gtk_toggle_button_get_active (GTK_TOGGLE_BUTTON 
(priv-check_eject)); 
-g_thread_create ((GThreadFunc) thread_blank, params, FALSE, NULL);
+g_thread_new (xfburn_blank, (GThreadFunc) thread_blank, params);
   } else {
 xfburn_main_leave_window ();
   }
diff --git a/xfburn/xfburn-burn-audio-cd-composition-dialog.c 
b/xfburn/xfburn-burn-audio-cd-composition-dialog.c
index 66a32cf..b67696c 100644
--- a/xfburn/xfburn-burn-audio-cd-composition-dialog.c
+++ b/xfburn/xfburn-burn-audio-cd-composition-dialog.c
@@ -461,7 +461,7 @@ cb_dialog_response (XfburnBurnAudioCdCompositionDialog * 
dialog, gint response_i
 params-eject = gtk_toggle_button_get_active (GTK_TOGGLE_BUTTON 
(priv-check_eject));
 params-dummy = gtk_toggle_button_get_active (GTK_TOGGLE_BUTTON 
(priv-check_dummy));
 params-burnfree = gtk_toggle_button_get_active (GTK_TOGGLE_BUTTON 
(priv-check_burnfree));
-g_thread_create ((GThreadFunc) thread_burn_composition, params, FALSE, 
NULL);
+g_thread_new (audio_cd_burn, (GThreadFunc) thread_burn_composition, 
params);
   }
 }
 
diff --git a/xfburn/xfburn-burn-data-composition-base-dialog.c 
b/xfburn/xfburn-burn-data-composition-base-dialog.c
index ab11281..f789acc 100644
--- a/xfburn/xfburn-burn-data-composition-base-dialog.c
+++ b/xfburn/xfburn-burn-data-composition-base-dialog.c
@@ -671,7 +671,7 @@ cb_dialog_response (XfburnBurnDataCompositionBaseDialog * 
dialog, gint response_
   params-dialog_progress = dialog_progress;
   params-src = src;
   params-iso_path = g_strdup (gtk_entry_get_text (GTK_ENTRY 
(priv-entry_path_iso)));
-  g_thread_create ((GThreadFunc) thread_write_iso, params, FALSE, NULL);
+  g_thread_new (burn_iso, (GThreadFunc) thread_write_iso, params);
 }
 else {
   ThreadBurnCompositionParams *params = NULL;
@@ -698,7 +698,7 @@ cb_dialog_response (XfburnBurnDataCompositionBaseDialog * 
dialog, gint response_
   params-eject

[Xfce4-commits] xfburn:master g_cond / g_mutex deprecated removed, g_thread_init removed

[David Mohr]

Updating branch refs/heads/master
 to 396c82bcbf99459e056673903bbb70ed0a99ab14 (commit)
   from cc8777fa30187a310fb6d8acd08122da29f1b2c0 (commit)

commit 396c82bcbf99459e056673903bbb70ed0a99ab14
Author: David Mohr da...@mcbf.net
Date:   Tue Dec 3 22:46:57 2013 -0700

g_cond / g_mutex deprecated removed, g_thread_init removed

 xfburn/xfburn-main.c   |1 -
 xfburn/xfburn-transcoder-gst.c |   26 +-
 2 files changed, 13 insertions(+), 14 deletions(-)

diff --git a/xfburn/xfburn-main.c b/xfburn/xfburn-main.c
index 4873d14..aca15fa 100644
--- a/xfburn/xfburn-main.c
+++ b/xfburn/xfburn-main.c
@@ -201,7 +201,6 @@ main (int argc, char **argv)
   
   g_set_application_name (_(Xfburn));
 
-  g_thread_init (NULL);
   gdk_threads_init ();
   gdk_threads_enter ();
 
diff --git a/xfburn/xfburn-transcoder-gst.c b/xfburn/xfburn-transcoder-gst.c
index 52ca935..870bded 100644
--- a/xfburn/xfburn-transcoder-gst.c
+++ b/xfburn/xfburn-transcoder-gst.c
@@ -113,8 +113,8 @@ typedef struct {
   GstElement *source, *decoder, *resample, *conv, *sink;
 
   XfburnTranscoderGstState state;
-  GCond *gst_cond;
-  GMutex *gst_mutex;
+  GCond gst_cond;
+  GMutex gst_mutex;
   gboolean gst_done;
   gboolean is_audio;
   gint64 duration;
@@ -214,12 +214,12 @@ xfburn_transcoder_gst_init (XfburnTranscoderGst * obj)
 
   /* the condition is used to signal that
* gst has returned information */
-  g_cond_init (priv-gst_cond);
+  g_cond_init (priv-gst_cond);
 
   /* if the mutex is locked, then we're not currently seeking
* information from gst */
-  g_mutex_init (priv-gst_mutex);
-  g_mutex_lock (priv-gst_mutex);
+  g_mutex_init (priv-gst_mutex);
+  g_mutex_lock (priv-gst_mutex);
 }
 
 static void
@@ -409,7 +409,7 @@ signal_identification_done (XfburnTranscoderGst *trans, 
const char *dbg_res)
   /* There is no g_mutex_lock_timed, so emulate it with a loop.
 * I have never seen this getting hung here, but one never knows! */
   for (i=0; iSIGNAL_SEND_ITERATIONS; i++) {
-if (g_mutex_trylock (priv-gst_mutex))
+if (g_mutex_trylock (priv-gst_mutex))
   break;
 g_usleep (SIGNAL_SEND_TIMEOUT_MICROS / SIGNAL_SEND_ITERATIONS);
 g_thread_yield ();
@@ -423,8 +423,8 @@ signal_identification_done (XfburnTranscoderGst *trans, 
const char *dbg_res)
 }
   }
 
-  g_cond_signal (priv-gst_cond);
-  g_mutex_unlock (priv-gst_mutex);
+  g_cond_signal (priv-gst_cond);
+  g_mutex_unlock (priv-gst_mutex);
 
 #if DEBUG_GST  0
  #if DEBUG  0
@@ -586,7 +586,7 @@ bus_call (GstBus *bus, GstMessage *msg, gpointer data)
   if (strcmp (GST_OBJECT_NAME (GST_MESSAGE_SRC (msg)), decoder) != 0)
 break;
   
-  if (!g_mutex_trylock (priv-gst_mutex)) {
+  if (!g_mutex_trylock (priv-gst_mutex)) {
 g_critical (Lock held by another thread, can't signal transcoding 
start!);
 break;
   } else {
@@ -596,8 +596,8 @@ bus_call (GstBus *bus, GstMessage *msg, gpointer data)
   }
 
   priv-gst_done = TRUE;
-  g_cond_signal (priv-gst_cond);
-  g_mutex_unlock (priv-gst_mutex);
+  g_cond_signal (priv-gst_cond);
+  g_mutex_unlock (priv-gst_mutex);
   break;
   } /* switch of priv-state */
 
@@ -788,7 +788,7 @@ get_audio_track (XfburnTranscoder *trans, XfburnAudioTrack 
*atrack, GError **err
   DBG (Now waiting for identification result);
 #endif
   while (!priv-gst_done)
-if (!g_cond_wait_until (priv-gst_cond, priv-gst_mutex, end_time)) {
+if (!g_cond_wait_until (priv-gst_cond, priv-gst_mutex, end_time)) {
   DBG (gst identification timed out);
   recreate_pipeline (tgst);
   g_set_error (error, XFBURN_ERROR, XFBURN_ERROR_GST_TIMEOUT,
@@ -914,7 +914,7 @@ prepare (XfburnTranscoder *trans, GError **error)
   //DBG (Waiting for start signal);
   end_time = g_get_monotonic_time () + SIGNAL_WAIT_TIMEOUT_MS * 
G_TIME_SPAN_MILLISECOND;
   while (!priv-gst_done)
-if (!g_cond_wait_until (priv-gst_cond, priv-gst_mutex, end_time)) {
+if (!g_cond_wait_until (priv-gst_cond, priv-gst_mutex, end_time)) {
   recreate_pipeline (gst);
   g_set_error (error, XFBURN_ERROR, XFBURN_ERROR_GST_TIMEOUT,
   _(Gstreamer did not want to start transcoding (timed 
out)));
___
Xfce4-commits mailing list
Xfce4-commits@xfce.org
https://mail.xfce.org/mailman/listinfo/xfce4-commits

Bug#714298: python-pyhyphen: Example from the README fails to work

[David Mohr]

Package: python-pyhyphen
Version: 1.0~beta1-2
Severity: important

Dear Maintainer,

please run this short script, adapted from the README, which fails to
work.

#!/usr/bin/env python

from hyphen import Hyphenator
from hyphen.dictools import *
import traceback

for lang in ['de_DE', 'fr_FR', 'en_UK', 'ru_RU']:
try:
if not is_installed(lang):
install(lang)
except OSError, e:
print traceback.format_exc()
install(lang)
#EOF

I get the following output:
% ./pyhyphen-test.py 
Traceback (most recent call last):
  File ./pyhyphen-test.py, line 9, in module
if not is_installed(lang):
  File /usr/lib/python2.7/dist-packages/hyphen/dictools.py, line 29, in 
is_installed
return (language in list_installed(directory))
  File /usr/lib/python2.7/dist-packages/hyphen/dictools.py, line 19, in 
list_installed
return [d[5:-4] for d in os.listdir(directory)
OSError: [Errno 2] No such file or directory: '$path'

Traceback (most recent call last):
  File ./pyhyphen-test.py, line 13, in module
install(lang)
  File /usr/lib/python2.7/dist-packages/hyphen/dictools.py, line 48, in 
install
s = urllib2.urlopen(url).read()
  File /usr/lib/python2.7/urllib2.py, line 127, in urlopen
return _opener.open(url, data, timeout)
  File /usr/lib/python2.7/urllib2.py, line 396, in open
protocol = req.get_type()
  File /usr/lib/python2.7/urllib2.py, line 258, in get_type
raise ValueError, unknown url type: %s % self.__original
ValueError: unknown url type: $repohyph_de_DE.dic

Thanks,
~David


-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages python-pyhyphen depends on:
ii  libc6  2.17-5
ii  python 2.7.5-2
ii  python2.6  2.6.8-2
ii  python2.7  2.7.5-6

python-pyhyphen recommends no packages.

python-pyhyphen suggests no packages.

-- debconf-show failed


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

[Python-modules-team] Bug#714298: python-pyhyphen: Example from the README fails to work

[David Mohr]

Package: python-pyhyphen
Version: 1.0~beta1-2
Severity: important

Dear Maintainer,

please run this short script, adapted from the README, which fails to
work.

#!/usr/bin/env python

from hyphen import Hyphenator
from hyphen.dictools import *
import traceback

for lang in ['de_DE', 'fr_FR', 'en_UK', 'ru_RU']:
try:
if not is_installed(lang):
install(lang)
except OSError, e:
print traceback.format_exc()
install(lang)
#EOF

I get the following output:
% ./pyhyphen-test.py 
Traceback (most recent call last):
  File ./pyhyphen-test.py, line 9, in module
if not is_installed(lang):
  File /usr/lib/python2.7/dist-packages/hyphen/dictools.py, line 29, in 
is_installed
return (language in list_installed(directory))
  File /usr/lib/python2.7/dist-packages/hyphen/dictools.py, line 19, in 
list_installed
return [d[5:-4] for d in os.listdir(directory)
OSError: [Errno 2] No such file or directory: '$path'

Traceback (most recent call last):
  File ./pyhyphen-test.py, line 13, in module
install(lang)
  File /usr/lib/python2.7/dist-packages/hyphen/dictools.py, line 48, in 
install
s = urllib2.urlopen(url).read()
  File /usr/lib/python2.7/urllib2.py, line 127, in urlopen
return _opener.open(url, data, timeout)
  File /usr/lib/python2.7/urllib2.py, line 396, in open
protocol = req.get_type()
  File /usr/lib/python2.7/urllib2.py, line 258, in get_type
raise ValueError, unknown url type: %s % self.__original
ValueError: unknown url type: $repohyph_de_DE.dic

Thanks,
~David


-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages python-pyhyphen depends on:
ii  libc6  2.17-5
ii  python 2.7.5-2
ii  python2.6  2.6.8-2
ii  python2.7  2.7.5-6

python-pyhyphen recommends no packages.

python-pyhyphen suggests no packages.

-- debconf-show failed

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Bug#610214: mumble - Segmentation fault on first startup

[David Mohr]

Package: mumble
Version: 1.2.3-349-g315b5f5-2.2
Followup-For: Bug #610214

Dear Maintainer,

I don't use mumble on Linux very frequently, but just a week or two ago
it was working and now I get the crash on start-up. I have the same
behavior as previous reporters with strace and gdb: in both those cases
there is no crash. But I can get a backtrace (attached below). Note that
I'm using pulseaudio, and not alsa. I get the same crash whether I have
an existing configuration file (with pulse configured) or not.

~David

% gdb mumble core
GNU gdb (GDB) 7.6-debian
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type show
copying
and show warranty for details.
This GDB was configured as x86_64-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /usr/bin/mumble...Reading symbols from
/usr/lib/debug/usr/bin/mumble...done.
done.
[New LWP 729]
[New LWP 730]

warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need set solib-search-path or set sysroot?
[Thread debugging using libthread_db enabled]
Using host libthread_db library
/lib/x86_64-linux-gnu/libthread_db.so.1.

warning: no loadable sections found in added symbol-file system-supplied
DSO at 0x7fff91a0
Core was generated by `mumble'.
Program terminated with signal 11, Segmentation fault.
#0  0x7fa93b412410 in snd_config_iterator_next () from
/usr/lib/x86_64-linux-gnu/libasound.so.2
(gdb) bt
#0  0x7fa93b412410 in snd_config_iterator_next () from
/usr/lib/x86_64-linux-gnu/libasound.so.2
#1  0x7fa93b41d59c in snd_device_name_hint () from
/usr/lib/x86_64-linux-gnu/libasound.so.2
#2  0x7fa93dae3fbf in ALSAEnumerator::ALSAEnumerator
(this=0x7fa93eae7ee0) at ALSAAudio.cpp:192
#3  0x7fa93dae4764 in ALSAInit::initialize (this=optimized out) at
ALSAAudio.cpp:94
#4  0x7fa93da3f3f9 in DeferInit::run_initializers () at
Global.cpp:179
#5  0x7fa93d986dc9 in main (argc=1, argv=optimized out) at
main.cpp:273



-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages mumble depends on:
ii  gconf2 3.2.6-1
ii  libasound2 1.0.27.1-1
ii  libavahi-client3   0.6.31-2
ii  libavahi-common3   0.6.31-2
ii  libavahi-compat-libdnssd1  0.6.31-2
ii  libc6  2.17-5
ii  libg15daemon-client1   1.9.5.3-8.2
ii  libgcc11:4.8.1-3
ii  libgl1-mesa-glx [libgl1]   9.1.3-6
ii  libopus0   1.1~alpha+20130512-1
ii  libprotobuf7   2.4.1-3
ii  libpulse0  4.0-2
ii  libqt4-dbus4:4.8.4+dfsg-4
ii  libqt4-network 4:4.8.4+dfsg-4
ii  libqt4-sql 4:4.8.4+dfsg-4
ii  libqt4-sql-sqlite  4:4.8.4+dfsg-4
ii  libqt4-svg 4:4.8.4+dfsg-4
ii  libqt4-xml 4:4.8.4+dfsg-4
ii  libqtcore4 4:4.8.4+dfsg-4
ii  libqtgui4  4:4.8.4+dfsg-4
ii  libsndfile11.0.25-5
ii  libspeechd20.7.1-6.2
ii  libspeex1  1.2~rc1-7
ii  libspeexdsp1   1.2~rc1-7
ii  libssl1.0.01.0.1e-3
ii  libstdc++6 4.8.1-3
ii  libx11-6   2:1.6.0-1
ii  libxi6 2:1.6.1-1+deb7u1
ii  lsb-release4.1+Debian12

Versions of packages mumble recommends:
ii  speech-dispatcher  0.7.1-6.2

Versions of packages mumble suggests:
pn  mumble-server  none

-- no debconf information


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

Bug#711153: mumble-server: Please package v1.2.4

[David Mohr]

Source: mumble-server
Severity: wishlist

Dear Maintainer,

please consider packaging v1.2.4 which was released on June 2nd.

I couldn't find a link to a source tarball, but there is a tag in git:
https://github.com/mumble-voip/mumble.git

Thank you very much!

~David

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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


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

Re: [Operators] google abandoning XMPP??

[David Mohr]

As of today my client can't connect anymore (though I can't rule out 
that's only a temporary situation).


Sad :-(

~David

On 2013-05-19 21:17, Peter Kieser wrote:

I can no longer send or receive messages to people that have updated
to Google Hangouts. It shows them as being online, and messages are
successfully sent but they are not received by either party.

-Peter

On 2013-05-16 9:12 AM, Dave Cridland wrote:
The best information I've been given is that Google are stopping S2S 
entirely, and C2S will be a legacy interface to 1:1 text chat only.


On the plus side, this means there's no reason not to require TLS 
now.


Dave.

nmu builds breaking multiarch

[David Mohr]

Hi,

I filed bug #708299 [1] but realize that it's not really an issue with 
that package: dpkg doesn't like it when buildd adds an architecture 
specific entry to  changelog.Debian:


snip
Preparing to replace libgl1-mesa-dri:amd64 8.0.5-4 (using 
.../libgl1-mesa-dri_8.0.5-4+b1_amd64.deb) ...

Unpacking replacement libgl1-mesa-dri:amd64 ...
dpkg: error processing 
/var/cache/apt/archives/libgl1-mesa-dri_8.0.5-4+b1_amd64.deb (--unpack):
 trying to overwrite shared 
'/usr/share/doc/libgl1-mesa-dri/changelog.Debian.gz', which is different 
from other instances of package libgl1-mesa-dri:amd64

snap

In fact, when I manually fixed libgl1-mesa-dri, I run across the same 
issue in other nmu uploads as well:

libgl1-mesa-glx libglapi-mesa

This currently breaks any upgrades / installs on my system, so I'm 
interested in helping to get it fixed :) Obviously the x-strike-force 
can't do much about it, can someone please reassign it (not sure 
where/how infrastructure bugs are filed).


Thanks,
~David

[1]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=708299


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e7dc68b712e8e206a281b769ea281...@de.mcbf.net

Bug#676883: moreinfo

[David Mohr]

root@(none):/# ls -l
total 64
drwxr-xr-x  2 nobody nogroup 4096 May  3 02:15 bin
drwxr-xr-x  2 nobody nogroup 4096 May  3 02:16 boot
drwxr-xr-x 14 root   root2620 May  6 20:41 dev
drwxr-xr-x 63 nobody nogroup 4096 May  3 02:16 etc
drwxr-xr-x  2 nobody nogroup 4096 Dec 14 12:56 home
lrwxrwxrwx  1 nobody nogroup   29 May  3 02:16 initrd.img - 
boot/initrd.img-3.2.0-4-amd64

drwxr-xr-x 13 nobody nogroup 4096 May  3 02:15 lib
drwxr-xr-x  2 nobody nogroup 4096 May  3 02:14 lib64
drwxr-xr-x  2 nobody nogroup 4096 May  3 02:13 media
drwxr-xr-x  2 nobody nogroup 4096 Dec 14 12:56 mnt
drwxr-xr-x  2 nobody nogroup 4096 May  3 02:13 opt
dr-xr-xr-x 56 root   root   0 May  6 20:41 proc
drwx--  4 nobody nogroup 4096 May  6 20:05 root
drwxr-xr-x  9 root   root 320 May  6 20:41 run
drwxr-xr-x  2 nobody nogroup 4096 May  3 02:15 sbin
drwxr-xr-x  2 nobody nogroup 4096 Jun 10  2012 selinux
drwxr-xr-x  2 nobody nogroup 4096 May  3 02:13 srv
drwxr-xr-x 13 root   root   0 May  6 20:41 sys
drwxrwxrwt  2 nobody nogroup 4096 May  3 02:16 tmp
drwxr-xr-x 10 nobody nogroup 4096 May  3 02:13 usr
drwxr-xr-x 11 nobody nogroup 4096 May  3 02:13 var
lrwxrwxrwx  1 nobody nogroup   26 May  3 02:16 vmlinuz - 
boot/vmlinuz-3.2.0-4-amd64


mount says:

xx.xx.xx.6:/srv/fai/nfsroot on / type nfs4 
(ro,relatime,vers=4,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=xx.xx.xx.24,minorversion=0,local_lock=none,addr=xx.xx.xx.6)


The workaround
/srv/nfs4   134.95.9.128/25(fsid=0,ro,no_subtree_check)
works; that is nfs3 is used and now all directories are properly owned 
by root.


It's too bad the rest of fai still fails ;-).

~David


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