Bug#727708: systemd as cgroup writer (was: Bug#727708: systemd jessie -> jessie+1 upgrade problems)

[Andreas Barth]

* Steve Langasek (vor...@debian.org) [131220 16:57]:
> The design which claims this role for systemd-as-pid-1, and which does not
> adequately address use cases of other existing cgroups consumers in the
> ecosystem (lmctfy, lxc) is broken by design.
> 
> Having a single cgroup writer in userspace is fine.  Coupling it to systemd
> in this manner is not.

I would like to understand that topic further, so I have two questions
(to different people):

1. Does systemd (or a part of the systemd project) need to be the
single cgroup writer and if so, why?

2. What problems do arise from there for other parts of the linux
ecosystem?


Andi


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

Bug#732756: socket-event(7) missing key information

[Russ Allbery]

Package: upstart
Version: upstart/1.10-2
Severity: minor

I assume that this is the only documentation for socket activation;
at least, I've not been able to find any other documentation for how
this works.

Several questions are left unanswered for me after reading this man
page.  First, what are the valid values of PROTO in the start on
socket directive?  There are examples for "inet" and "unix", but no
list of valid values.  socket(2) documents quite a few protocols, and
I suspect they're not *all* supported, but I can't tell which ones are.

Second, is there some way to use socket activation for UDP services?
The service I'm currently using to experiment with systemd and upstart
is UDP-based.  systemd has a separate directive for SOCK_DGRAM sockets,
but there's no mention of socket types in socket-event(7).  The web
examples I've seen seem to indicate the default is SOCK_STREAM (hence
TCP).

Third, what does "inet" mean here?  Does that mean AF_INET (hence no
IPv6)?  Does it mean AF_INET6 with the system default bindv6-only
behavior?  Is there any way to control the bindv6-only behavior?

If I've missed some other key source of documentation, please let me
know.

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 3.11-2-686-pae (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 upstart depends on:
ii  initscripts 2.88dsf-43
ii  libc6   2.17-97
ii  libdbus-1-3 1.6.18-2
pn  libnih-dbus1
pn  libnih1 
ii  libselinux1 2.2.1-1
ii  sysv-rc 2.88dsf-43
ii  sysvinit-utils  2.88dsf-43

upstart recommends no packages.

upstart suggests no packages.


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

Bug#732743: [Pkg-fonts-devel] Bug#732743: fontforge: please mark fontforge multiarch foreign

[Christian PERRIER]

Quoting Dimitri John Ledkov (x...@debian.org):
> Package: fontforge
> Version: 20120731.b-4
> Severity: normal
> Tags: patch
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu ubuntu-patch trusty
> 
> Dear Maintainer,
> 
> fontforge is typically used to generate and process fonts at buildtime,
> the output that is produced by fontforge under such conditions is
> platform independant. There are packages that build-depend on fontforge,
> and thus to enable cross-compilation of those, it would help to mark
> fontforge / fontforge-nox packages as Multi-Arch: foreign, similar to
> other build-tools, e.g. automake, autoconf, et. al.


I see no harm to this.

Any objection from other font packages maintainers?


Otherwise...added to my TODO list.




signature.asc
Description: Digital signature

Bug#732754: openssl: CVE-2013-6449: crash when using TLS 1.2

[Salvatore Bonaccorso]

Package: openssl
Version: 1.0.1e-2
Severity: grave
Tags: security upstream patch

Hi,

the following vulnerability was published for openssl.

CVE-2013-6449[0]:
crash when using TLS 1.2

It was reported in Apache Traffic Server[1] and upstream at [2], see
also [3]. I was not able to reproduce any crash myself, just checking
against the openssl source package to verify upstrem patches apply.
See [4] and [5] for the patches applied.

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-6449
http://security-tracker.debian.org/tracker/CVE-2013-6449
[1] https://issues.apache.org/jira/browse/TS-2355
[2] http://rt.openssl.org/Ticket/Display.html?id=3200&user=guest&pass=guest
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1045363
[4] http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=ca98926
[5] http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=0294b2b

Regards,
Salvatore


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

Bug#732717: growisofs - TRACKING SERVO FAILURE - Input/output error "

[Thomas Schmitt]

Hi,

> :-[ WRITE@LBA=538f0h failed with SK=4h/TRACKING SERVO FAILURE]:

This is a problem between drive and medium.
It does not necessary mean that either of them is bad.
But at least the combination does not work properly.

Try other media. If the problem persists, get another drive.

Have a nice day :)

Thomas


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

Bug#725422: Some more thinking about this bug

[Raphaël HALIMI]

Hi,

I recently experienced a situation when one of my machine (a Sid 
desktop) froze and I tried to use the magic SysRq keys, to no avail. 
After 40 minutes or so I decided to do a hardware reboot and tried to 
find why the magic keys didn't worked. That's when I found this new 
default behavior introduced by systemd.


At first I tried to override this default by writing an adequate file in 
/etc/sysctl.d but, since I named it 10-sysrq.conf, I was very surprised 
to see that restarting procps' init script didn't set the value 
according to my file. After carefully checking /etc/sysctl.conf and all 
files in /etc/sysctl.d, I didn't find anything that would explain why my 
configuration file didn't work.


Then I looked for reports in Debian BTS about SysRq and found this bug, 
and finally I understood why my configuration file didn't work as 
intended. After renaming it to 99-sysrq.conf, it worked.


To be honest, I didn't even know about the existence of 
/usr/lib/sysctl.d. I admit it is mentioned in the manpage, but according 
to a quick search with apt-file, it's only used by systemd so far.


Even if the new kernel.sysrq default value is considered to be a good 
default (to which I don't agree, see below), I think that the file 
/usr/lib/sysctl.d/50-default.conf which sets this value should at least 
be moved to /etc/sysctl.d, which is the "natural" place a Debian 
sysadmin would look first for sysctl settings.


Furthermore, I'm no systemd expert (yet... :)) but as far as I know, 
it's intended to replace SysV, and take charge of the boot process 
(amongst other things); since /usr isn't guaranteed to be available at 
boot-time, I think it's another reason to move the 50-default.conf file 
to /etc/sysctl.d (besides, the procps init script only requires 
$local_fs, which may exclude /usr, so, in the - admittedly rare - case 
of a /usr partition located on a remote fs, the current location of this 
file would prevent it from being read and thus applied when the procps 
init script is executed).


To conclude, I'd like to give my opinion about the setting itself.

The very first question asked to the original reporter was :

"You failed to justify why kernel.sysrq = 16 is a bad default.
Can you elaborate?"

That's only my opinion, but personally, I think that any experienced 
Linux sysadmin (Debian or otherwise)  expects most (if not all) magic 
SysRq keys to be available out-of-the-box, without any further 
configuration. I use Debian since Slink and the SysRq keys got me out of 
quite a bunch of sticky situations, either at home or at work. The 
problem I recently experienced was with a personal Sid desktop that I 
didn't mind to hard reset, but if I encountered the same kind of 
situation at work with an important server, I think that being unable to 
use the SysRq keys and discovering this new default setting afterwards 
would have made me... very upset, to say the least. Not only do I 
totally agree with the original poster about the fact that it's not 
systemd's job to define a new default value for this setting, but I also 
think that this value of 16 (sync only) is far too restrictive, compared 
to the one compiled in the kernels currently shipped by Debian (0x01b6, 
or 438, which means all but signals and dump) which is fine; not to 
mention that two different "defaults" can be confusing even for an 
experienced sysadmin. If nothing is done to change this "second" default 
value introduced by systemd, I expect a lot more users to complain about 
it once Jessie becomes the new stable release and they find out that 
only one SysRq key is now available on their new systemd-enabled Debian 
systems.


Thanks for reading, and I really hope someone will do something about 
this, be it matching kernel's current default setting, or moving the 
responsible file to a more common place (personally I'd prefer the 
former solution but I understand that the choice is not mine to make).


Hope it helps.

--
Raphaël HALIMI


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

Bug#729203: Tired of Libav "virus"

[Ma Xiaojun]

Libav is an annoying "virus".
On one hand, it pretends itself to be FFmpeg; maybe this is due to the
fact that many software don't bother to port.
On the other hand, it tries very hard to discredit FFmpeg and doesn't
bother to be compatible with new FFmpeg development.
( The converse is not true. )
The end result is that breakage occurs here and there, users are
confused and ended up compiling FFmpeg manually.

In case Debian insists on weird choice, interested people may instead
try getting FFmpeg reappear in Ubuntu. I've filed a bug here:
https://bugs.launchpad.net/ubuntu/+source/libav/+bug/1263278

Ubuntu is arguably the biggest contributor of the spreading of Libav
"virus". Innocent, uninformed Ubuntu users just get confused:
http://stackoverflow.com/questions/12651816/libswresample-in-recent-ubuntu-version
http://stackoverflow.com/questions/9477115/who-can-tell-me-the-difference-and-relation-between-ffmpeg-libav-and-avconv
https://github.com/hrydgard/ppsspp/issues/2322
They need our help.


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

Bug#617196: grub-pc: GRUB_GFXMODE silently ignored if font unavailable

[Ben Longbons]

I managed to fix the core problem by doing:
cp /usr/share/grub/unicode.pf2 /boot/grub/unicode.pf2
Obviously it can't read any partition but /boot since it's on encrypted LVM.

For some reason, other computers I've looked at *do* have the font in
the right place.

It's still a bug that the fallback to text mode is silent though.

-Ben


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

Bug#727708: upstart proposed policy in Debian [and 1 more messages]

[Russ Allbery]

Ian Jackson  writes:

> I don't see the merit in extensibility; or rather, I think that there is
> room in the world for a non-extensible but trivial protocol.  (And there
> are other potential simple protocols which would be more extensible.)

Well, the extensibility is already providing another obviously-useful
feature, namely the watchdog support, which is done over the same channel.
How do you think that should be implemented in upstart?  It seems like a
good example of a place where a daemon needs an ongoing communication
channel with the init system.

And you're never going to convince me that repurposing SIGSTOP to mean go
is anything other than a hack.  Sorry.  :)  I agree that it's a useful
hack with low impact when patching upstream source, but it's still exactly
the sort of repurposing of one thing to mean something entirely unrelated
that tends to create problems and undermine guarantees that unknown other
parties might be depending on.  It makes the standards writer in me
cringe.

I personally have used kill -STOP on daemons started by init before as a
systems administrator, usually when setting up debugging and sometimes
when trying to temporarily pause a daemon while I figure out what's going
on with a load issue without terminating it entirely and losing state.  I
believe it's also the first step of a gdb attach.  The argument that
admins may use this for other purposes is not theoretical.  SIGSTOP is
very useful because it's uncatchable, so you know that daemons with weird
signal handlers can't make it ineffective.  It always works the same in
every situation (except, now, with daemons started by upstart).  This is
not true of SIGTTOU.

Now, that being said, upstart only cares about SIGSTOP when the job hasn't
yet signaled that it's ready, so this is only an issue if you try to
attach during the early startup stage.  That's not an entirely impossible
situation, but less likely and not one of the cases where I've done this
as an administrator before.

-- 
Russ Allbery (r...@debian.org)   


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

Bug#717839: lcms2 ftbfs on arm64

[Wookey]

Source: lcms2
Version: lcms2_2.2+git20110628-2.3
Followup-For: Bug #717839
User: debian-...@lists.debian.org
Usertag: arm64

Attaqched is a small clean patch which adds autotools-dev support so
that up-to-date config.sub and guess files are used. This fixes the
general case of 'not building on new architecture'.

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

Kernel: Linux 3.2.0-kvm-i386-20110111 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
diff -Nru lcms2-2.2+git20110628/debian/changelog lcms2-2.2+git20110628/debian/changelog
--- lcms2-2.2+git20110628/debian/changelog	2013-10-06 21:34:38.0 +
+++ lcms2-2.2+git20110628/debian/changelog	2013-12-21 00:56:41.0 +
@@ -1,3 +1,10 @@
+lcms2 (2.2+git20110628-2.4) unstable; urgency=low
+
+  * Ensure config.{sub,guess} up to date using autotools-dev, avoiding 
+ftbfs on new architectures
+
+ --Sat, 21 Dec 2013 00:54:52 +
+
 lcms2 (2.2+git20110628-2.3) unstable; urgency=low
 
   * Non-maintainer upload.
diff -Nru lcms2-2.2+git20110628/debian/rules lcms2-2.2+git20110628/debian/rules
--- lcms2-2.2+git20110628/debian/rules	2013-10-06 21:38:15.0 +
+++ lcms2-2.2+git20110628/debian/rules	2013-12-21 02:01:49.0 +
@@ -18,9 +18,11 @@
 	dh_testdir
 	dh_testroot
 	rm -f build-stamp
+	dh_autotools-dev_updateconfig
 	./configure
 	touch config.status
 
+	dh_autotools-dev_restoreconfig
 	dh_clean
 	$(MAKE) distclean
 	-rm -rf config.log \
@@ -45,4 +47,4 @@
 #override_dh_auto_test:
 
 %:
-	dh $@ 
+	dh $@ --with autotools-dev

Bug#727708: upstart proposed policy in Debian [and 1 more messages]

[Ian Jackson]

Andreas Barth writes ("Bug#727708: upstart proposed policy in Debian [and 1 
more messages]"):
> However I think it is relevant if we could get an patch integrated to
> support the other protocol as well (means: not replacing the current
> protocol). Which might be a good thing anyways as both protocols have
> their own merits.

Yes, I agree that this is relevant.

> > Also relevant is the response from systemd upstream to the request to
> > support this protocol as an option.  I found it unsatisfactory.
> 
> You mean #732157 / https://bugzilla.redhat.com/show_bug.cgi?id=833105 ?

Yes.  I agree with the comments from Vincent and Niklaus.  For me,
Zbigniew's response shows where this approach leads and I don't find
it attractive.

I found Lennart's comments tendentious and his complaint about an
admin's potential use of SIGSTOP (during startup) unconvincing (and
easily resolved by the use of (say) SIGTTOU instead).

I don't see the merit in extensibility; or rather, I think that there
is room in the world for a non-extensible but trivial protocol.  (And
there are other potential simple protocols which would be more
extensible.)

Ian.


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

Bug#732752: New upstream release 6.0

[Jackson Doak]

Package: javacc
Priority: wishlist
Version: 5.0-5

There is a new major release of javacc is available at
https://javacc.java.net/ , could debian please package it?

Bug#732751: acsccid: use dh-autoreconf instead of autotools-dev for better new-port coverage

[Dimitri John Ledkov]

Package: acsccid
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu ubuntu-patch trusty

Hi,

The ppc64el port requires a patch to libtool.m4.  I don't think that's
in Debian yet, but when it is it will require autoreconfing a bunch of
packages to pick it up.  acsccid could handle this quite easily by using
dh-autoreconf rather than just autotools-dev; when libtool is in use (as
of course it is here), dh-autoreconf is a superset of autotools-dev, and
it seems to still build just fine if I do the following.

  * Convert to dh-autoreconf in order to update libtool.m4 for new ports.

diff --git a/debian/control b/debian/control
index a65dce0..b6e125f 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,7 @@ Section: libs
 Priority: extra
 Maintainer: Godfrey Chung 
 Build-Depends:
- autotools-dev,
+ dh-autoreconf,
  debhelper (>= 9~),
  flex,
  libpcsclite-dev (>= 1.3.3~),
diff --git a/debian/rules b/debian/rules
index 15ad606..8b52f20 100755
--- a/debian/rules
+++ b/debian/rules
@@ -4,7 +4,7 @@
 #export DH_VERBOSE=1
 
 %:
-	dh $@ --with autotools-dev --parallel
+	dh $@ --with autoreconf --parallel
 
 override_dh_auto_configure:
 	# Enable composite device as multi-slot reader.


Regards,

Dimitri.

Bug#732750: devhelp: use dh-autoreconf for better new-port coverage

[Dimitri John Ledkov]

Package: devhelp
Version: 3.8.2-2
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu ubuntu-patch trusty

Hi,

The ppc64el port requires a patch to libtool.m4.  I don't think that's
in Debian yet, but when it is it will require autoreconfing a bunch of
packages to pick it up. devhelp could handle this quite easily by using
dh-autoreconf; when libtool is in use (as of course it is here),
dh-autoreconf is a superset of autotools-dev, and it seems to still
build just fine if I do the following.  I did have to do a bit of extra
work to make things happy: use intltoolize & include non-standard
include dir for aclocal/autoconf.

diff -Nru devhelp-3.8.2/debian/control.in devhelp-3.8.2/debian/control.in
--- devhelp-3.8.2/debian/control.in	2013-07-31 21:42:57.0 +0100
+++ devhelp-3.8.2/debian/control.in	2013-12-21 00:28:19.0 +
@@ -7,6 +7,8 @@
 Build-Depends: cdbs,
debhelper (>= 8),
gnome-pkg-tools,
+   gnome-common,
+   dh-autoreconf,
intltool,
libglib2.0-dev (>= 2.32),
libgtk-3-dev (>= 3.5.6),
diff -Nru devhelp-3.8.2/debian/rules devhelp-3.8.2/debian/rules
--- devhelp-3.8.2/debian/rules	2013-07-31 21:44:35.0 +0100
+++ devhelp-3.8.2/debian/rules	2013-12-21 00:30:25.0 +
@@ -1,5 +1,6 @@
 #!/usr/bin/make -f
 
+include /usr/share/cdbs/1/rules/autoreconf.mk
 include /usr/share/cdbs/1/rules/debhelper.mk
 include /usr/share/cdbs/1/class/gnome.mk
 include /usr/share/cdbs/1/rules/utils.mk
@@ -10,6 +11,9 @@
 
 DEB_DH_MAKESHLIBS_ARGS_ALL += -V -- -c4
 
+export AUTOPOINT=intltoolize --automake --copy
+DEB_DH_AUTORECONF_ARGS=autoreconf -- -f -i -I libgd/
+
 X_TOOLS += misc/devhelp.vim \
 	misc/html2funcs.py \
 	misc/html2xml.py \

--
Regards,


Dimitri.

Bug#732623: [Pkg-xfce-devel] Bug#732623: lightdm-gtk-greeter: Hibernate and Restart buttons disappear after first login/logout

[Vincent Lefevre]

On 2013-12-21 00:32:37 +0100, Yves-Alexis Perez wrote:
> Well, that confirms logind disable suspend/hibernate/shutdown.

Suspend and Restart are not disabled. That's strange that only 2 of
them are disabled. If there's a "good" reason to disable one, I think
that all of them should be disabled.

FYI, on another machine, the bug didn't occur. But after upgrading
some packages (which also installed new packages due to dependencies),
the bug now occurs.

> If it's not a gnupg issue, check if something else is holding the
> previous session?

I'm wondering. Even if I kill all my processes except the window
manager and check with "ps -fu $USER" in a VT as root, then quit
the window manager (which is the remaining process), the problem
still occurs.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


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

Bug#727708: upstart proposed policy in Debian [and 1 more messages]

[Russ Allbery]

Russ Allbery  writes:

> Overall, I think the approach outlined in daemon(3) is more
> forward-looking and thoughtful upstart's more conservative approach, and I
> like the long-term vision.

Sorry, that should have been daemon(7).

-- 
Russ Allbery (r...@debian.org)   


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

Bug#732740: CVS in stable does not allow to commit as root

[Thorsten Glaser]

Klaus Ethgen dixit:

>> This does not warrant an upload to stable, though.
>> At best, a backport.
>
>Why not? I did file the bug for stable and not for testing.

Because the Stable Release Team only permits uploads for
security fixes and other grave issues in packages. Not
even my decision, see.

bye,
//mirabilos
-- 
Yay for having to rewrite other people's Bash scripts because bash
suddenly stopped supporting the bash extensions they make use of
-- Tonnerre Lombard in #nosec


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

Bug#732749: please consider adding vendor information for raspbian.

[peter green]

Package: apt
Version: 0.9.14.1
Severity: wishlist
Tags: patch

While updating the apt package in raspbian I noticed that the keyring 
related settings that we have to change have now moved into a new vendor 
system. So I added an entry for raspbian by copying the debian one and 
changing the keyring and example sources.list settings.


I notice that you include settings for both debian and ubuntu in the 
debian source package. Please consider also including the settings for 
raspbian so we don't have to manually alter the source package every 
time a new version enters debian.


Debdiff of the most recent upload to raspbian is attatched, no intent to 
nmu.
diff -Nru apt-0.9.14.1/debian/changelog apt-0.9.14.1+rpi1/debian/changelog
--- apt-0.9.14.1/debian/changelog   2013-12-12 17:36:44.0 +
+++ apt-0.9.14.1+rpi1/debian/changelog  2013-12-20 23:02:16.0 +
@@ -1,3 +1,9 @@
+apt (0.9.14.1+rpi1) jessie-staging; urgency=low
+
+  * Include vendor information for raspbian.
+
+ -- Peter Michael Green   Fri, 20 Dec 2013 22:51:48 +
+
 apt (0.9.14.1) unstable; urgency=medium
 
   * fix apt-get source -t dist regression (closes: #731853)
diff -Nru apt-0.9.14.1/vendor/raspbian/apt-vendor.ent 
apt-0.9.14.1+rpi1/vendor/raspbian/apt-vendor.ent
--- apt-0.9.14.1/vendor/raspbian/apt-vendor.ent 1970-01-01 00:00:00.0 
+
+++ apt-0.9.14.1+rpi1/vendor/raspbian/apt-vendor.ent2013-12-20 
22:59:28.0 +
@@ -0,0 +1,7 @@
+
+
+raspbian-archive-keyring">
+/usr/share/keyrings/raspbian-archive-keyring.gpg">
+/usr/share/keyrings/raspbian-archive-removed-keys.gpg">
+
+
diff -Nru apt-0.9.14.1/vendor/raspbian/makefile 
apt-0.9.14.1+rpi1/vendor/raspbian/makefile
--- apt-0.9.14.1/vendor/raspbian/makefile   1970-01-01 00:00:00.0 
+
+++ apt-0.9.14.1+rpi1/vendor/raspbian/makefile  2013-12-20 23:35:44.0 
+
@@ -0,0 +1,11 @@
+# -*- make -*-
+BASE=../..
+SUBDIR=vendor/raspbian
+
+# Bring in the default rules
+include ../../buildlib/defaults.mak
+
+doc binary manpages: sources.list
+
+sources.list: sources.list.in ../../doc/apt-verbatim.ent
+   sed -e 's#&stable-codename;#$(shell ../getinfo 
debian-stable-codename)#g' $< > $@
diff -Nru apt-0.9.14.1/vendor/raspbian/sources.list.in 
apt-0.9.14.1+rpi1/vendor/raspbian/sources.list.in
--- apt-0.9.14.1/vendor/raspbian/sources.list.in1970-01-01 
00:00:00.0 +
+++ apt-0.9.14.1+rpi1/vendor/raspbian/sources.list.in   2013-12-20 
23:01:09.0 +
@@ -0,0 +1,6 @@
+# See sources.list(5) manpage for more information
+# Remember that CD-ROMs, DVDs and such are managed through the apt-cdrom tool.
+deb http://mirrordirector.raspbian.org/raspbian &stable-codename; main contrib 
non-free
+
+# Uncomment if you want the apt-get source function to work
+#deb-src http://mirrordirector.raspbian.org/raspbian &stable-codename; main 
contrib non-free

Bug#732727: RFP: scrz -- supervisor to run many isolated linux containers on a host system

[Joachim Breitner]

Dear Thomas,

Am Freitag, den 20.12.2013, 19:16 +0100 schrieb Thomas Koch:
> Hi Debian-Haskell folks,
> 
> I hope that somebody might be interested in this cool project. I've no
> experience with Haskell and would be curious how much work it might be to
> package this cool and promising project for Debian?
> 
> Regards, Thomas Koch

the packaging of Haskell applications is usually no big deal, if the
dependencies are available. The list is in the field Build-Depends in
https://github.com/scrz/scrz/blob/master/scrz.cabal, and missing in
Debian seems to be only friendly-time, which is another tiny haskell
package that would ideally be part of something else, but if someone
wants to maintain scrz in Debian, we’ll happily package and maintain
libghc-friendly-time-dev.

As for scrz itself I would not suggest the Haskell group to be the
maintainer, as the Haskell aspect of maintaining the package is minor
compared to the other issues (e.g. dpkg scripts, documentation,
security, handling bug reports). But if someone steps up to maintain it,
we’ll be here to help with the Haskell side and any problems related to
it.

In the current form I have some doubts that it is ready to be shipped in
Debian. For example, the Build-Depends of scrz do not specify version
ranges, which is expected from a polished haskell package. Also, it has
not been uploaded to Hackage. All these are signs of a slight immaturity
of the project (which can be misleading, of course), so I suggest a
thorough evaluation before uploading it to Debian.

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


signature.asc
Description: This is a digitally signed message part

Bug#732747: gtkmm3.0: use dh-autoreconf for better new-port coverage

[Dimitri John Ledkov]

Package: gtkmm3.0
Severity: normal
Version: 3.8.1-1
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu ubuntu-patch trusty

Hi,

The ppc64el port requires a patch to libtool.m4.  I don't think that's
in Debian yet, but when it is it will require autoreconfing a bunch of
packages to pick it up.  cwidget could handle this quite easily by using
dh-autoreconf rather than just cdbs autotools-dev; when libtool is in
use (as of course it is here), dh-autoreconf is a superset of
autotools-dev, and it seems to still build just fine if I do the
following.

diff -Nru gtkmm3.0-3.10.1/debian/control.in gtkmm3.0-3.10.1/debian/control.in
--- gtkmm3.0-3.10.1/debian/control.in   2013-12-16 23:33:17.0 +
+++ gtkmm3.0-3.10.1/debian/control.in   2013-12-20 02:02:17.0 +
@@ -1,13 +1,15 @@
 Source: gtkmm3.0
 Section: libs
 Priority: optional
-Maintainer: Debian GNOME Maintainers 

+Maintainer: Ubuntu Developers 
+XSBC-Original-Maintainer: Debian GNOME Maintainers 

 Uploaders: @GNOME_TEAM@
 Homepage: http://www.gtkmm.org/
 Vcs-Browser: 
http://anonscm.debian.org/viewvc/pkg-gnome/desktop/unstable/gtkmm3.0
 Vcs-Svn: svn://anonscm.debian.org/svn/pkg-gnome/desktop/unstable/gtkmm3.0
 Build-Depends: cdbs (>= 0.4.93),
debhelper (>= 8.1.3),
+  dh-autoreconf,
gnome-pkg-tools (>= 0.11),
libgtk-3-dev (>= 3.10.0),
libglibmm-2.4-dev (>= 2.38.0),
diff -Nru gtkmm3.0-3.10.1/debian/rules gtkmm3.0-3.10.1/debian/rules
--- gtkmm3.0-3.10.1/debian/rules2013-12-16 23:33:17.0 +
+++ gtkmm3.0-3.10.1/debian/rules2013-12-20 02:08:29.0 +
@@ -1,5 +1,6 @@
 #!/usr/bin/make -f
 
+include /usr/share/cdbs/1/rules/autoreconf.mk
 include /usr/share/cdbs/1/rules/debhelper.mk
 include /usr/share/cdbs/1/rules/utils.mk
 include /usr/share/cdbs/1/class/autotools.mk


--
Regards,

Dimitri.


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

Bug#732748: imanx: FTBFS on autobuilders: unconditionally relies on stuff from arch-indep builds

[Roland Stigge]

Source: imanx
Version: 0.50-9.1
Severity: serious

Hi,

imanx FTBFS on autobuilders like this:

...
make[2]: Entering directory `/«PKGBUILDDIR»'
wc -l manx.words > gv_GB.dic
cat manx.words >> gv_GB.dic
mkdir -p /«PKGBUILDDIR»/debian/myspell-gv/usr/share/myspell/dicts
mkdir -p /«PKGBUILDDIR»/debian/myspell-gv/usr/share/myspell/infos/ooo
cp gv_GB.aff gv_GB.dic /«PKGBUILDDIR»/debian/myspell-gv/usr/share/myspell/dicts
cp debian/myspell.info 
/«PKGBUILDDIR»/debian/myspell-gv/usr/share/myspell/infos/ooo/myspell-gv
make[2]: Leaving directory `/«PKGBUILDDIR»'
# For debian bug  #541923
mv debian/myspell-gv/usr/share/myspell/dicts/* 
debian/myspell-gv/usr/share/hunspell
mv: target 'debian/myspell-gv/usr/share/hunspell' is not a directory
make[1]: *** [override_dh_auto_install] Error 1
make[1]: Leaving directory `/«PKGBUILDDIR»'
make: *** [binary-arch] Error 2
...

Autobuilders only build arch specific packages. I checked that when building
both arch and arch-indep packages, the problem is gone. Looks like the package
unconditionally relies on stuff from arch-indep builds.

Roland


-- System Information:
Debian Release: 7.0
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: powerpcspe (ppc)

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


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

Bug#732746: apt: Empty /etc/apt/preferences file is not allowed

[Will Marler]

Package: apt
Version: 0.9.7.9+deb7u1
Severity: normal

Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

   * What led up to the situation?

I was configuring Puppet to manage a number of nodes. Puppetlabs has an 'apt' 
module, and they
use code fragments in /etc/apt/preferences.d to control pins. However, my 
organization was using
entries in /etc/apt/preferences, so I had to migrate. I decided to put a 
comment in 
/etc/apt/preferences saying "# This file is managed by Puppet" (similar to what 
the puppetlabs/apt
module does for /etc/apt/sources.list), and discovered this caused 'apt-get 
upgrade' to fail. 

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

This topic has been covered by a previous bug, but the resolution is 
poor/unclear. That bug is 
641245, archived, and it seems the resolution is "comments should be entered in 
/etc/apt/preferences in the form 'Explanation: '" and the bug was 
archived. This does 
not work, however, and does not seem to be a good solution. The "#" as a 
comment is so ubiquitous
across Linux programs, and files containing only comments are acceptable almost 
everywhere. 
apt-get should be updated to current expectations. 

The bug can be reproduced quite simply by putting a single comment in 
/etc/apt/preferences. 
For example:
# This file is maintained by Puppet. Contents will be overwritten.

When running apt-get, the output will be:
"E: Unable to parse package file /etc/apt/preferences (1)"

In the discussion of bug 641245, it is mentioned that apt_preferences (5) says 
comments should
be indicated with "Explanation:" . If the only line in 
/etc/apt/preferences is like so:

Explanation: This file is maintained by Puppet. Contents will be overwritten.

the output is as follows:

"E: Invalid record in the preferences file /etc/apt/preferences, no Package 
header"

A workaround is actually quite simple. As long as "Package: " is 
included, 'apt-get
upgrade' works without complaint. Quite literally, the following is acceptable:

# This file is maintained by Puppet. Contents will be overwritten.
Package: arbitrary_non_existent_package_used_to_demonstrate_the_point

It's clear that apt-get isn't checking the validity of the text following the 
"Package:" line, so
why is it a requirement that the "Package:" line be present at all? 

-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image.*";
APT::NeverAutoRemove:: "^kfreebsd-image.*";
APT::NeverAutoRemove:: "^linux-restricted-modules.*";
APT::NeverAutoRemove:: "^linux-ubuntu-modules-.*";
APT::NeverAutoRemove:: "^gnumach$";
APT::NeverAutoRemove:: "^gnumach-image.*";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "restricted/metapackages";
APT::Never-MarkAuto-Sections:: "universe/metapackages";
APT::Never-MarkAuto-Sections:: "multiverse/metapackages";
APT::Never-MarkAuto-Sections:: "oldlibs";
APT::Never-MarkAuto-Sections:: "restricted/oldlibs";
APT::Never-MarkAuto-Sections:: "universe/oldlibs";
APT::Never-MarkAuto-Sections:: "multiverse/oldlibs";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "1";
APT::Compressor::gzip "";
APT::Compressor::gzip::Name "gzip";
APT::Compressor::gzip::Extension ".gz";
APT::Compressor::gzip::Binary "gzip";
APT::Compressor::gzip::Cost "2";
APT::Compressor::gzip::CompressArg "";
APT::Compressor::gzip::CompressArg:: "-9n";
APT::Compressor::gzip::UncompressArg "";
APT::Compressor::gzip::UncompressArg:: "-d";
APT::Compressor::bzip2 "";
APT::Compressor::bzip2::Name "bzip2";
APT::Compressor::bzip2::Extension ".bz2";
APT::Compressor::bzip2::Binary "bzip2";
APT::Compressor::bzip2::Cost "3";
APT::Compressor::bzip2::CompressArg "";
APT::Compressor::bzip2::CompressArg:: "-9";
APT::Compressor::bzip2::UncompressArg "";
APT::Compressor::bzip2::UncompressArg:: "-d";
APT::Compressor::xz "";
APT::Compressor::xz::Name "xz";
APT::Compressor::xz::Extension ".xz";
APT::Compressor::xz::Binary "xz";
APT::Compressor::xz::Cost "4";
APT::Compressor::xz::CompressArg "";
APT::Compressor::xz::CompressArg:: "-6";
APT::Compressor::xz::UncompressArg "";
APT::Compressor::xz::UncompressArg:: "-d";
APT::Compressor::lzma "";
APT::Compressor::lzma::Name "lzma";
APT::Compressor::lzma::Extension ".lzma";
APT::Compressor::lzma::Binary "xz";
APT::Compressor::lzma::Cost "5";
APT::Compressor::lzma::CompressArg "";
APT::Compressor::lzma::CompressArg:: "--format=lzma";
APT::Compressor

Bug#732745: igaelic: FTBFS on autobuilders: unconditionally relies on stuff from arch-indep builds

[Roland Stigge]

Source: igaelic
Version: 0.50-8
Severity: serious

Hi,

igaelic FTBFS on autobuilders like this:

...
make[2]: Entering directory `/«PKGBUILDDIR»'
wc -l gaelic.words > gd_GB.dic
cat gaelic.words >> gd_GB.dic
mkdir -p /«PKGBUILDDIR»/debian/myspell-gd/usr/share/myspell/dicts
mkdir -p /«PKGBUILDDIR»/debian/myspell-gd/usr/share/myspell/infos/ooo
cp gd_GB.aff gd_GB.dic /«PKGBUILDDIR»/debian/myspell-gd/usr/share/myspell/dicts
cp debian/myspell.info 
/«PKGBUILDDIR»/debian/myspell-gd/usr/share/myspell/infos/ooo/myspell-gd
make[2]: Leaving directory `/«PKGBUILDDIR»'
# For debian bug  #541923
mv debian/myspell-gd/usr/share/myspell/dicts/* 
debian/myspell-gd/usr/share/hunspell
mv: target 'debian/myspell-gd/usr/share/hunspell' is not a directory
make[1]: *** [override_dh_auto_install] Error 1
make[1]: Leaving directory `/«PKGBUILDDIR»'
make: *** [binary-arch] Error 2
...

Autobuilders only build arch specific packages. I checked that when building
both arch and arch-indep packages, the problem is gone. Looks like the package
unconditionally relies on stuff from arch-indep builds.

Roland


-- System Information:
Debian Release: 7.0
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: powerpcspe (ppc)

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


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

Bug#732726: Fwd (potential regression in 5.0.3): Bug#732726: zsh function freeze

[Vincent Lefevre]

On 2013-12-20 12:27:00 -0800, Bart Schaefer wrote:
> I think that's unlikely unless svnwrapper is using zpty.  I'm not a user
> of SVN at this point so I don't have a reference.

That's the pipe itself that is completely broken.
The problem can be reproduced with "zsh -f" (version 5.0.3) and:

ypig% foo() { ls -R / }
ypig% foo | head

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


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

Bug#727708: upstart proposed policy in Debian [and 1 more messages]

[Russ Allbery]

Andreas Barth  writes:
> * Ian Jackson (ijack...@chiark.greenend.org.uk) [131221 00:33]:

>> Also relevant is the response from systemd upstream to the request to
>> support this protocol as an option.  I found it unsatisfactory.

> You mean #732157 / https://bugzilla.redhat.com/show_bug.cgi?id=833105 ?

Lennart here manages to put into words several of the things that I
thought when I first heard about this method and didn't express as well:

SIGSTOP is a mechanism for stopping processes, not for notifying
service readiness. We shouldn't attempt to overload OS functionality
like this, as SIGSTOP might happen for it's real purpose too.

[...]

Another big problem with raise(SIGSTOP) is that if done on an init
system that can't handle it will result in a freeze. OTOH sd_notify()
handles this gracefully and just becomes a NOP.

I basically agree with his response here.  If I were him, I probably would
have added support for it anyway just on the grounds of supporting a
mechanism that's already widely used in a major Linux distribution, but I
understand his reluctance and, had I added it, I would have marked it as
discouraged and documented why.

-- 
Russ Allbery (r...@debian.org)   


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

Bug#727708: upstart proposed policy in Debian [and 1 more messages]

[Russ Allbery]

Ian Jackson  writes:
> Russ Allbery writes:

>> I'd like to see both of them support systemd's method, since it's
>> extensible and provides more general functionality.  I think the
>> benefit of support for SIGSTOP is marginal; adding sd_notify calls is
>> not that much harder and doesn't have the conceptual weirdness of
>> stopping the daemon to notify the init system that it's running.

> I strongly disagreee.

> As the upstream author of a daemon I'm
>  - not willing to add a library dependency for this
>  - not willing to write a 50-100 lines of tiresome socket code for this
>  - not willing to copy the library file into my source tree
> so the result is that userv upstream won't support systemd's readiness
> protocol.

Yes, we completely disagree.

Among other things, that's about the smallest and least-impactful library
dependency I can imagine.  My intent in integrating support for sd_notify
is to just stub out the call when not built with systemd support, which is
pretty trivial to do with Autoconf and means that those who want systemd
integration get it and those who don't care can easily ignore it.

-- 
Russ Allbery (r...@debian.org)   


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

Bug#727708: upstart proposed policy in Debian [and 1 more messages]

[Andreas Barth]

* Ian Jackson (ijack...@chiark.greenend.org.uk) [131221 00:33]:
> Steve Langasek writes ("Bug#727708: upstart proposed policy in Debian [and 1 
> more messages]"):
> > Of course if you disagree, and feel this is a point that's relevant to the
> > TC decision, I'd like to understand why.
> 
> I think it's relevant to the TC decision.

As I think that both protocols have their own advantages (and
currently I don't think that any is so much better that we have to
take it) I don't think it is relevant which of the protocols is
supported right now.

However I think it is relevant if we could get an patch integrated to
support the other protocol as well (means: not replacing the current
protocol). Which might be a good thing anyways as both protocols have
their own merits.


> Also relevant is the response from systemd upstream to the request to
> support this protocol as an option.  I found it unsatisfactory.

You mean #732157 / https://bugzilla.redhat.com/show_bug.cgi?id=833105 ?



Andi


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

Bug#727708: upstart proposed policy in Debian [and 1 more messages]

[Russ Allbery]

Steve Langasek  writes:

> But as Andi said, there's no real conceptual difference between the two
> approaches, and I don't see anything here that weighs in favor of one
> project over the other.  Do you agree?

No -- for me, this is a plus in the systemd column over upstart, and
likely will have an effect on my vote.

> Of course if you disagree, and feel this is a point that's relevant to
> the TC decision, I'd like to understand why.

I don't think the upstart synchronization approach has a future.  It's
basically a hack to work around only the lack of synchronization, and all
it can deliver is a single bit of data.  The problem is that there may be
more than a single bit of data that needs to be delivered.  There may be
multiple synchronization points, there may be more information that the
daemon wants to tell its management process (the existing status reporting
interface is an example), and so on.  But there's no way to extend
SIGSTOP.  The systemd approach, while necessarily requiring a more complex
communications protocol, is clealy extensible for future needs as they
arise.

This is consistent with a pattern that I'm seeing when evaluating the core
init system functionality between systemd and upstart.  upstart takes a
very conservative approach of only addressing known problems and doing so
in a fairly limited way.  systemd takes a broader approach of trying to
understand the general problem and trying to create a way to write daemons
and other startup code that can be much simpler once systemd interfaces
are available.

There are pluses and minuses to those approaches, but given that both
projects are maintaining backward compatibility, and given that I find
myself generally nodding along with the systemd design decisions, I think
the systemd approach is more interesting and has more long-term upside
potential.  upstart as it exists right now would solve a bunch of problems
for us, but not lay groundwork for solving more problems in the future.
systemd would both solve an equivalent set of problems and provide a path
forward towards making the overall system much more robust, and given the
breadth of the existing systemd deployment, it's likely that our upstreams
are going to start adding that support.  It's a more appealing picture.

-- 
Russ Allbery (r...@debian.org)   


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

Bug#732623: [Pkg-xfce-devel] Bug#732623: lightdm-gtk-greeter: Hibernate and Restart buttons disappear after first login/logout

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Fri, Dec 20, 2013 at 04:53:59PM +0100, Vincent Lefevre wrote:
> Control: reassign -1 lightdm 1.8.5-2
> Control: retitle -1 lightdm_get_can_hibernate and lightdm_get_can_restart 
> return FALSE after first login/logout
> 
> On 2013-12-19 15:09:01 +0100, Vincent Lefevre wrote:
> > Package: lightdm-gtk-greeter
> > Version: 1.6.1-4
> > Severity: normal
> > 
> > Initially the following buttons are present in the top-right menu:
> > 
> > Suspend
> > Hibernate
> > Restart...
> > Shutdown...
> > 
> > But after the first login/logout, the Hibernate and Restart ones
> > disappear. I don't see any reason for that.
> 
> This is not a bug in lightdm-gtk-greeter itself, as the greeter
> just calls the lightdm_get_can_* functions to decide whether the
> menu items should be visible or not.
> 
> If I modify the liblightdm-gobject/power.c lightdm file to return
> TRUE in all these functions, the problem no longer occurs. So, this
> confirms that the problem comes from there. Thus reassigning.
> 
> I've tried to add some debug messages in these functions, but they
> do not appear in the log files! I've attached the patch I've used.

Well, that confirms logind disable suspend/hibernate/shutdown. If it's
not a gnupg issue, check if something else is holding the previous
session?
- -- 
Yves-Alexis Perez
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)

iQEcBAEBCgAGBQJStNORAAoJEG3bU/KmdcCl+xUH/1Rud7QzxAdqefFQJ1VUsoEZ
6dL/kua4Z/ARqSgVFai6naurlcXZ6uthUgtmJbi5br/dV7P4e/QV981JQldo++l9
QUJK89AvJ+WOTXjn1u5IXa2/kMRn21DPZC3BJiKp2KztxKpOg1v2IHe2vqLn58Kd
9YUI/JY7YeqEWJA1vSDTG3AFBOg+tPVmyUR8SbhkzmO5lA/4JUxOAuQJIY3/mZMQ
Sh0tyej9ZaYspJb8JhxUCRmv40HPnh/xJoKF69FSLMK17XstjDCJDVN6I8Ktb1LC
ZFOJrUOPezfCL4DN/gK8gTmu5zyI6/RnORIXbzyORwC0abXT/6SPAu0lgdD2ZBc=
=/TOg
-END PGP SIGNATURE-


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

Bug#727708: upstart proposed policy in Debian [and 1 more messages]

[Ian Jackson]

Steve Langasek writes ("Bug#727708: upstart proposed policy in Debian [and 1 
more messages]"):
> Of course if you disagree, and feel this is a point that's relevant to the
> TC decision, I'd like to understand why.

I think it's relevant to the TC decision.

Also relevant is the response from systemd upstream to the request to
support this protocol as an option.  I found it unsatisfactory.

Ian.


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

Bug#727708: upstart proposed policy in Debian [and 1 more messages]

[Ian Jackson]

Russ Allbery writes ("Bug#727708: upstart proposed policy in Debian [and 1 more 
messages]"):
> I'd like to see both of them support systemd's method, since it's
> extensible and provides more general functionality.  I think the benefit
> of support for SIGSTOP is marginal; adding sd_notify calls is not that
> much harder and doesn't have the conceptual weirdness of stopping the
> daemon to notify the init system that it's running.

I strongly disagreee.

As the upstream author of a daemon I'm
 - not willing to add a library dependency for this
 - not willing to write a 50-100 lines of tiresome socket code for this
 - not willing to copy the library file into my source tree
so the result is that userv upstream won't support systemd's readiness
protocol.

Luckily the systemd socket activation is less fiddly than the general
readiness protcol, so for systemd I am doing that instead.

Ian.


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

Bug#732744: clamav: use dh-autoreconf for better new-port coverage

[Dimitri John Ledkov]

Package: clamav
Severity: normal
Tags: patch
Version: 0.97.8+dfsg-1
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu ubuntu-patch trusty

Hi,

The ppc64el port requires a patch to libtool.m4. I don't think that's in
Debian yet, but when it is it will require autoreconfing a bunch of
packages to pick it up. clamav could handle this quite easily by using
dh-autoreconf, when libtool is in use (as of course it is here),
dh-autoreconf is a superset of autotools-dev, and it seems to still
build just fine if I do the following.  I did have to do a bit of extra
work to make things happy with new automake.

  * Convert to dh-autoreconf in order to update libtool.m4 for new
ports.
  * Remove -Werror from automake flags, to avoid failing autoreconf with
new automake.

diff -u clamav-0.97.8+dfsg/debian/rules clamav-0.97.8+dfsg/debian/rules
--- clamav-0.97.8+dfsg/debian/rules
+++ clamav-0.97.8+dfsg/debian/rules
@@ -57,6 +57,7 @@
  fi;\
done;
# Add here commands to configure the package.
+   dh_autoreconf
./configure CFLAGS="$(CFLAGS)" CPPFLAGS="$(CPPFLAGS)" 
CXXFLAGS="$(CXXFLAGS)" LDFLAGS="$(LDFLAGS)" --build=$(DEB_BUILD_GNU_TYPE) 
--prefix=/usr --mandir=\$${prefix}/share/man --infodir=\$${prefix}/share/info 
--disable-clamav --with-dbdir=/var/lib/clamav/ --sysconfdir=/etc/clamav 
--enable-milter --disable-clamuko --with-gnu-ld --enable-dns-fix ${DEBUG_OPTS} 
--disable-unrar --libdir=\$${prefix}/lib --with-system-tommath  
--without-included-ltdl
 
 build: build-stamp
@@ -126,6 +126,7 @@
rm -f debian/clamav-freshclam.config
rm -f debian/clamav-freshclam.postinst
rm -f libclamav/c++/llvm/utils/lit/lit/*.pyc
+   dh_autoreconf_clean
dh_clean
 
 install: install-indep install-arch
diff -u clamav-0.97.8+dfsg/debian/control clamav-0.97.8+dfsg/debian/control
--- clamav-0.97.8+dfsg/debian/control
+++ clamav-0.97.8+dfsg/debian/control
@@ -4,6 +4,6 @@
 Maintainer: ClamAV Team 
 Uploaders: Stephen Gran , Michael Meskes 
, Michael Tautschnig , Scott Kitterman 

-Build-Depends: debhelper (>= 6.0.7), po-debconf, zlib1g-dev, libbz2-dev, 
libmilter-dev, perl, bc, check, libtommath-dev, libltdl-dev, libncurses5-dev, 
python
+Build-Depends: debhelper (>= 6.0.7), po-debconf, zlib1g-dev, libbz2-dev, 
libmilter-dev, perl, bc, check, libtommath-dev, libltdl-dev, libncurses5-dev, 
python, dh-autoreconf
 Standards-Version: 3.9.3
 Vcs-Git: git://git.debian.org/pkg-clamav/clamav.git
 Vcs-Browser: http://git.debian.org/?p=pkg-clamav/clamav.git;a=summary
only in patch2:
unchanged:
--- clamav-0.97.8+dfsg.orig/configure.in
+++ clamav-0.97.8+dfsg/configure.in
@@ -34,7 +34,7 @@
 
 dnl -Wall and -Werror here are NOT CFLAGS, they refer to automake warnings
 dnl enable stealth builds and psychedelic tests
-AM_INIT_AUTOMAKE([1.11 -Wall -Wportability -Wno-override -Werror std-options 
foreign dist-bzip2 no-define color-tests parallel-tests tar-ustar])
+AM_INIT_AUTOMAKE([1.11 -Wall -Wportability -Wno-override std-options foreign 
dist-bzip2 no-define color-tests parallel-tests tar-ustar])
 AM_SILENT_RULES([yes])
 
 dnl we told automake to not define these, since we want to include
only in patch2:
unchanged:
--- clamav-0.97.8+dfsg.orig/libclamav/c++/configure.ac
+++ clamav-0.97.8+dfsg/libclamav/c++/configure.ac
@@ -20,7 +20,7 @@
 AC_CONFIG_MACRO_DIR([m4])
 AC_CONFIG_HEADER([clamavcxx-config.h])
 AC_CANONICAL_TARGET
-AM_INIT_AUTOMAKE([1.9 -Wall -Wportability -Werror foreign no-define 
color-tests tar-pax])
+AM_INIT_AUTOMAKE([1.9 -Wall -Wportability foreign no-define color-tests 
tar-pax])
 AM_SILENT_RULES([yes])
 
 cxxset=${CXXFLAGS+set}


--
Regards,

Dimitri.


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

Bug#727708: upstart proposed policy in Debian [and 1 more messages]

[Steve Langasek]

On Fri, Dec 20, 2013 at 03:03:25PM -0800, Russ Allbery wrote:
> Andreas Barth  writes:
> > * Russ Allbery (r...@debian.org) [131219 04:09]:
> >> Ian Jackson  writes:

> >>> systemd supports the non-forking daemon too.  Only, instead of
> >>> raise(SIGSTOP) the daemon has to fetch an AF_UNIX socket name from an
> >>> environment variable, connect to it, and send a special message with
> >>> socket credentials attached.

> >> I assume this is functionality provided by the libsystemd-daemon
> >> library if you're willing to have a dependency on it?  (Checks.)  Ah,
> >> yes, this is one of the things that sd_notify is for.

> > I don't think this is a conceptual difference, but both inits would be
> > able to work either way without changing their basic concepts.  So if we
> > have strong reasons to prefer one above the other this could also mean
> > convincing upstream to implement the second approach. (It also could of
> > course mean that there are too many things to adjust.)

> Agreed.

> I'd like to see both of them support systemd's method, since it's
> extensible and provides more general functionality.  I think the benefit
> of support for SIGSTOP is marginal; adding sd_notify calls is not that
> much harder and doesn't have the conceptual weirdness of stopping the
> daemon to notify the init system that it's running.

The one benefit of not using sd_notify() is that it doesn't require
introducing build-time dependencies or portability concerns; upstreams who
may not use Linux at all can still validate the correctness of the SIGSTOP
interface manually, and low barrier to entry for upstream is a good thing.

But as Andi said, there's no real conceptual difference between the two
approaches, and I don't see anything here that weighs in favor of one
project over the other.  Do you agree?  If so, perhaps we should table this
particular thread; we can always discuss the finer points of implementation
outside the TC decision.

Of course if you disagree, and feel this is a point that's relevant to the
TC decision, I'd like to understand why.

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


signature.asc
Description: Digital signature

Bug#732740: CVS in stable does not allow to commit as root

[Klaus Ethgen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Fr den 20. Dez 2013 um 23:23 schrieb Thorsten Glaser:
> >Looking at the source I can see that this stupid idea (not allowing root
> 
> It???s actually a very good idea, but???

Yes, generally. But not in the case of cvs that is used for ages also
for system changes.

> >to commit) is not overwritable when using cvs. It is a configure option
> >(--enable-rootcommit).
> 
> ??? anyway, this was changed (not saying ???fixed???) in:
>   cvs (2:1.12.13+real-10) unstable; urgency=low

Great, thanks, yes. Unfortunately not in stable. (On my desktop I use
unstable but the server is always using stable.)

> This does not warrant an upload to stable, though.
> At best, a backport.

Why not? I did file the bug for stable and not for testing.

I can use the version from unstable for my server. So for me personal,
the bug might be fixed. But this is not very social, I think. Other
people might stumble over the same issue.

Regards
   Klaus
- -- 
Klaus Ethgen  http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16   Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)

iQGcBAEBCgAGBQJStNDpAAoJEKZ8CrGAGfas9bwL/iPSMfSMjcW1sg3vTycnHWNw
P6FGXYxvX2PZW53mKOSB6e6aavv2js65OHbup3T/2AYuZ71J4fLVVq/LhtQIbZdl
PM/0fySpDmXf//CfsR6PaD4YuMhelOL1yeImjPTfUAteLF7SRNMwOH3cmCPX6Qcx
BgFU6jUqHB9VUk2FL+Xed/164cCsXMH7wpF4nEutBcN01tb9KB9qiSec/b5I9VsN
Mh6cwoyXHa0Pu+64+0PZRBoDLQeZK6VwfKjvoAVGHrQgDd9ADBkZh1iVUsRqfDvM
EwipmoUOxSE4ByclIg9tP25kBU7braSBunY3C96mj4DUGHSlUmteoXuaS+fwRxTO
9xHU6vPPj4eBi8neRb4JAR1+Rca485xNPM/SJ1BiXpSmzMtlp+WZpKe3kLPMsv42
CYbiD1XGa3XfxW3b75X67fQPPg/Nus/ajCmpaBri2C6anrYxI2NFcYY2iRfWo8Ex
oQf0kPwLAhT1HmJZZn8Xqf9qrTTANKp3JPH0vBMAdA==
=p0Ye
-END PGP SIGNATURE-


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

Bug#727708: upstart upstream maintenance practices

[Russ Allbery]

Steve Langasek  writes:

> I'm attaching the full delta against upstream currently in the Ubuntu
> packaging VCS branch, for reference.  FWIW, I'm not sure which version
> you were looking at, but the current version of the Ubuntu package
> (1.11-0ubuntu1) does not include any delta against autogenerated
> autotools files (and does use dh-autoreconf).  Also FWIW, the attached
> patch includes changes not yet released to Ubuntu (actually, just an
> update to sync the packaging with the version in Debian).

Thank you for this!  That was a more thorough answer than I was expecting!

For the record, I pulled the Ubuntu patch from:

http://patches.ubuntu.com/u/upstart/upstart_1.11-0ubuntu1.patch

linked off of the Debian PTS.  What I hadn't realized is that this patch
appears to be generated relative to the current version in Debian, which
is a different upstream release, and that explains the huge delta.  This
was just a misunderstanding on my part on how the Ubuntu patches shown on
the PTS are generated (obvious in retrospect).

> I've dissected the current delta and provided an explanation below for
> each bit, but the short answer to your question is yes: there are
> different policies for upstream vs. the Ubuntu package.  Although
> efforts are made to keep the distro delta as small as possible, changes
> are sometimes applied to the package before they're in a state that they
> can be included in upstream in the interest of expediency.

Indeed, most of this seems quite reasonable to me and the sort of thing
that makes sense to carry as a distribution patch, apart from the SELinux
change (which is stuck on the CLA).

> As for Upstart and Ubuntu being maintained "by the same project": if
> Upstart were intended to be "Ubuntu's init system", it would be
> reasonable to do all of the maintenance on a single upstream branch.
> But it was never intended to be Ubuntu's init system, but rather "the
> init system", and as there are other downstreams besides Ubuntu, care is
> taken to not embed Ubuntu-specific policy upstream.

That makes sense.  I take a different approach as upstream for my Debian
packages and try fairly hard to embed everything into the upstream release
with necessary conditionals where needed, but that's just a philosophical
approach and neither approach is inherently superior.

-- 
Russ Allbery (r...@debian.org)   


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

Bug#732743: fontforge: please mark fontforge multiarch foreign

[Dimitri John Ledkov]

Package: fontforge
Version: 20120731.b-4
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu ubuntu-patch trusty

Dear Maintainer,

fontforge is typically used to generate and process fonts at buildtime,
the output that is produced by fontforge under such conditions is
platform independant. There are packages that build-depend on fontforge,
and thus to enable cross-compilation of those, it would help to mark
fontforge / fontforge-nox packages as Multi-Arch: foreign, similar to
other build-tools, e.g. automake, autoconf, et. al.

Something like below patch should be sufficient:

diff -Nru fontforge-20120731.b/debian/control 
fontforge-20120731.b/debian/control
--- fontforge-20120731.b/debian/control 2013-11-02 18:52:10.0 +
+++ fontforge-20120731.b/debian/control 2013-12-20 23:11:54.0 +
@@ -35,6 +35,7 @@
 
 Package: fontforge
 Architecture: any
+Multi-Arch: foreign
 Depends: ${misc:Depends},
  fontforge-common (= ${source:Version}),
  libfontforge1 (= ${binary:Version}),
@@ -55,6 +56,7 @@
 
 Package: fontforge-nox
 Architecture: any
+Multi-Arch: foreign
 Depends: ${misc:Depends},
  fontforge-common (= ${source:Version}),
  libfontforge1 (= ${binary:Version}),


--
Regards,

Dimitri.


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

Bug#727708: upstart proposed policy in Debian [and 1 more messages]

[Russ Allbery]

Andreas Barth  writes:
> * Russ Allbery (r...@debian.org) [131219 04:09]:
>> Ian Jackson  writes:

>>> systemd supports the non-forking daemon too.  Only, instead of
>>> raise(SIGSTOP) the daemon has to fetch an AF_UNIX socket name from an
>>> environment variable, connect to it, and send a special message with
>>> socket credentials attached.

>> I assume this is functionality provided by the libsystemd-daemon
>> library if you're willing to have a dependency on it?  (Checks.)  Ah,
>> yes, this is one of the things that sd_notify is for.

> I don't think this is a conceptual difference, but both inits would be
> able to work either way without changing their basic concepts.  So if we
> have strong reasons to prefer one above the other this could also mean
> convincing upstream to implement the second approach. (It also could of
> course mean that there are too many things to adjust.)

Agreed.

I'd like to see both of them support systemd's method, since it's
extensible and provides more general functionality.  I think the benefit
of support for SIGSTOP is marginal; adding sd_notify calls is not that
much harder and doesn't have the conceptual weirdness of stopping the
daemon to notify the init system that it's running.

Overall, I think the approach outlined in daemon(3) is more
forward-looking and thoughtful upstart's more conservative approach, and I
like the long-term vision.  (Not horribly surprising, since it's an
evolution of the vision that daemontools represented early on, and which I
became convinced of some time ago.)  It's going to take a lot of upstream
work to get there, and a lot of older or abandoned upstreams may not adopt
it fully, but it provides incremental benefits as more daemons are
switched over to a simpler and saner model that has clearly-defined and
well-specified synchronization points.

-- 
Russ Allbery (r...@debian.org)   


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

Bug#723142: RFS: dnt/0.10-1 [ITP]

[Vincent Prat]

Hello everybody,

I have taken into account the reviews of Markus and Pabs, and a new 
version of the DNT package (project for a satirical post-apocalyptical 
3D RPG) is now ready for other reviews and sponsorship.
It is available on Debian Mentors 
(http://mentors.debian.net/package/dnt) and in the SVN repository of the 
team (http://anonscm.debian.org/viewvc/pkg-games/packages/trunk/dnt).

Feel free to take a look at it.

Best regards,
Vincent

Bug#732724: mygui: Please upgrade OGRE dependency to 1.9 when upstream ready

[Scott Howard]

On Fri, Dec 20, 2013 at 1:11 PM,   wrote:
> Source: mygui
> Severity: wishlist
>
> Hello,
>
> "mygui" depends on OGRE v1.8, which is discontinued and unsupported
> after 1.9.0 was released, and so it should not be present in future
> releases of Debian.

Thanks for the update. There's a package in the NEW queue (openmw)
that is built against mygui and ogre-1.8. Once it's cleared from NEW,
they can build against 1.9 and we can update mygui to 1.9.
I think, for now, that is my plan unless there is a precessing reason
why we should update sooner.

Cheers,
Scott


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

Bug#727708: upstart proposed policy in Debian [and 1 more messages]

[Andreas Barth]

* Russ Allbery (r...@debian.org) [131219 04:09]:
> Ian Jackson  writes:

> > systemd supports the non-forking daemon too.  Only, instead of
> > raise(SIGSTOP) the daemon has to fetch an AF_UNIX socket name from an
> > environment variable, connect to it, and send a special message with
> > socket credentials attached.

> I assume this is functionality provided by the libsystemd-daemon library
> if you're willing to have a dependency on it?  (Checks.)  Ah, yes, this is
> one of the things that sd_notify is for.

I don't think this is a conceptual difference, but both inits would be
able to work either way without changing their basic concepts. So if
we have strong reasons to prefer one above the other this could also
mean convincing upstream to implement the second approach. (It also
could of course mean that there are too many things to adjust.)


Andi


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

Bug#732742: Acknowledgement (icedove: calendar fails with Components.classes[cid] is undefined (calUtils.js line 22))

[Daniel Kahn Gillmor]

Control: affects 732742 iceowl-extension

hm, it looks like http://bugs.debian.org/732742 is is due to a version
mismatch between icedove 24.1.1-1 and iceowl-extension 24.0-1

apparently these need to be more tightly tightly-coupled, version-wise:

  https://blog.mozilla.org/calendar/2013/10/

Upgrading iceowl-extension to 24.1.1-1 from experimental resolved my
immediate problem.

but the package manager should have caught this, i think.

--dkg



signature.asc
Description: OpenPGP digital signature

Bug#732741: Serious bug

[Dominik George]

Control: severity -1 serious

This bug can cause data loss.

-- 
* mirabilos is handling my post-1990 smartphone *
 Aaah, it vibrates! Wherefore art thou, demonic device??

PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17  FD26 B79A 3C16 A0C4 F296


signature.asc
Description: Digital signature

Bug#732741: mailman: Please backport upstream fix for TypeError in sync_members

[Dominik George]

Package: mailman
Version: 1:2.1.15-1
Severity: important
Tags: upstream l10n

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The sync_members script has a known bug (LP: #1243343) that throws a
TypeError when importing members with non-ascii characters in their
names [1].

Upstream fixed this bug with two commits (the first caused a new
TypeError, Python 2 FTW!). The change looks trivial enough to backport
it to the stable version, because I think non-ascii characters in names
are very common and that makes sync_members unusable at a larger scale.

The important commit is revision 1437 [2].

- -nik

[1]: https://bugs.launchpad.net/mailman/+bug/1243343
[2]: https://bazaar.launchpad.net/~mailman-coders/mailman/2.1/revision/1437

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

iQJOBAEBCAA4BQJStMFKMRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n
cGctcG9saWN5LnR4dC5hc2MACgkQt5o8FqDE8pYxdg//cGjUPUlqJZhJ/ydG35ri
Hbisi4HR+pXaQEJ0/X+VRvKdCqLSq8yVrSREyNSPcRhjfir2YORbuD72IvZZ+BZI
yWzjiEsKrXrM5p7NS2xX80UECg1130QUkNo+xaYDXiguqfFwDn789ylpXV+iJZbb
Y43zMdMM4rlNGiKnWltghXfJFN+ipylvMVFpfHsrlOro7hNGgZkgMSRgrPuSlb6w
x688uGYRPX5WsK8hOBHfb4+ARF8yUcxPz9JDNr9tpSQXlVRN9LCKwaS/ZTyYDN/S
/uSouu5JQ+21lG/MiR3+QvR8oPevUFlKlFYNvaSk1uSbbKkmeP6gZKtegYZf+gLe
6I9U0gXJg+wxNwW0Tz4DT8rGpRTOXrzgDCibmRvEMDdJ5kpW4G18OtMuszJOsaQp
FGzOuh5T+NQ+KwFdWY/D5SgU4l/EaQxvtlZjyUoMNd+4+9TF2qFDudqGnzTe2rLR
TWZSLLh7lJ+f1sBtp2UIZlYoU/zJIsAscCwArXGGlbwjcEQyPeOnB5WCapNjjUwm
Cz8jlGD9FKIKjP0ArJvsrVrNyLuI/EIK6G3SSjdwigN4OD5KW18r+gruBw9M7SlF
7mc4mNSJsM1nG93Iub0S254nP2KsenlV57eHjlhi3Bl+WZxAKNqM/+1re5UrgvCb
x4PUFTpAA6ceQAXVH1nbJlI=
=72Bi
-END PGP SIGNATURE-


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

Bug#687332: Not openscenegraph's, and probably fixed

[Rebecca N. Palmer]

Control: reassign -1 gnome-settings-daemon
# found -1 3.6.4-0ubuntu8 # 13.04 raring
# fixed -1 3.8.5-0ubuntu9 # 13.10 saucy
(Those versions don't exist in Debian, so I won't try to run them 
through the control server.)


This is fixed in Ubuntu 13.10, with no changes to openscenegraph other 
than a no-code-change libcoin60->80 transition and some very visible 
changes to the keyboard layout switcher, so I suspect the problem was 
actually there.  I also suspect it is fixed in Debian as well, but don't 
have that here to test.



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

Bug#732740: CVS in stable does not allow to commit as root

[Klaus Ethgen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: cvs
Version: 2:1.12.13+real-9
Severity: important

I use cvs solely to manage my DNS zones via dnscvsutil. dnscvsutil is
not anymore in debian, I know, but this is not the reason for this
report.

The reason is, that, for obvious reasons (reload of bind afterwards) the
cvs hooks has to be done as root. I am the only one that change the
zones so it is not a security problem at all to commit as root.

Moreover there might be other reasons to have a local cvs repository
that has to run as root. For example using it as backend for etckeeper.
The use of cvs is not that uncommon to have a time history of local
changes.

So, back to the problem. The server was migrated from oldstable to
stable recently and now I am unable to manage my DNS zones. There is
even no note in changelog that this change was done.

Looking at the source I can see that this stupid idea (not allowing root
to commit) is not overwritable when using cvs. It is a configure option
(--enable-rootcommit).

Please enable this again to make cvs usable again. In the mean time I
have to go back to the version in oldstable.

- -- System Information:
Debian Release: wheezy
Architecture: amd64 (x86_64)
- -- 
Klaus Ethgen  http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16   Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)

iQGcBAEBCgAGBQJStLoWAAoJEKZ8CrGAGfasbVkL/izZiCsiywCB8aCT2vrqQBx2
lrWHgDNI99d6hfR49ljuvT1BPfZfJoTckQMTIZdgVO0wqdoURd/Ea3vhY2MKTgWl
XWPyQHZrBax4jZaVua9nX3kUBCby6Dke5A0WUIpMMSewCH2fZ4Ua1kR1lL1PjDrn
JFi6VsICmwf9rwUmpza94bgMKRVYENSv9Px5QxifKD2AxC+PUh3cjB8fRfxS2GXk
4xjKNn/iCuscCkqgdOQ/i1tXqivVWMc4Pba9v2otpP4H10I3f1YTUjrl1hpa5qRG
ORrvmmK7ifGH0UzCY4Mifc5aaIH0KOmohPqjDII97eI+bl2Fx5y6v2nwsHH+2jG7
hRig9G75SCqKYPkoAIUv9Jc+A//FF/p02z6XlUPM9F6hiZCa/s1KAN7ulUxbqowt
mUIWlmpjwmSCI2fxfzAHHuviQK0B0+UdbitgMrsNUkJAh9srFe6Slq4ixWzCp/WF
J/8L1dWUdnWKdrBpfPK75IxChncrxe34eDfpWGXJPw==
=Bp03
-END PGP SIGNATURE-


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

Bug#732210: Some serious incompatibilities with wheezy php 5.4

[Dmitry Katsubo]

On 18/12/2013 20:01, Thijs Kinkhorst wrote:
> On Tue, December 17, 2013 02:15, Dmitry Katsubo wrote:
>> In case somebody will try to install SquirrelMail 1.5.1, there are two
>> issues with it:
>>
>> 1) PHP Fatal error:  Call to undefined function session_unregister() in
>> /usr/share/squirrelmail/functions/global.php on line 111
>>
>> 2) PHP Fatal error:  Cannot redeclare hex2bin() in
>> /usr/share/squirrelmail/plugins/mail_fetch/functions.php on line 309
>>
>> Attached patches solve these problems.
>>
>> Also after installation one need to pickup sqspell_config.php from
>> latest stable (e.g. 1.4.23) to make aspell dictionaries working.
>>
>> I personally need 1.5.1 to be able to STARTTLS for IMAP/SMTP server.
>> Otherwise PLAIN authentication is forbidden.
> 
> If you want to use 1.5 branch, you should take a snapshot from
> squirrelmail.org, as the 1.5.1 release is very dated and indeed suffers
> from the problems above.
> 
> Thijs

Would it be difficult for package maintainers to take
squirrelmail-20131220_0200-SVN.devel.tar.bz2 and pull it to experimental
as is (provided the rest infrastructure is taken from 1.4.23)? If it
does not need patches above I will be happy to test it. For me the
difficulty is that I need to combine Debian-specific features from
1.4.23 with latest sources and I will certainly do something wrong.

-- 
With best regards,
Dmitry


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

Bug#732739: wicd daemon fails to start if /etc/resolv.conf is a broken symlink

[Javier P.L.]

Package: wicd
Version: 1.7.2.4-4.1
Severity: wishlist
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu trusty ubuntu-patch

Dear Maintainer,

Wicd fails to start if /etc/resolv.conf is a broken sysmlink

Traceback (most recent call last):
  File "/usr/share/wicd/daemon/wicd-daemon.py", line 1859, in 
main(sys.argv)
  File "/usr/share/wicd/daemon/wicd-daemon.py", line 1708, in main
os.symlink(dest, backup_location)
OSError: [Errno 17] File exists

When wicd-daemon.py checks if it has backed this file up, it uses
"os.path.exists" on the backup location. os.path.exists returns False
for broken symlinks. The location "../run/resolvconf/resolv.conf" (for
Ubuntu) does not exist relative to the backup location.  Thus
wicd-daemon.py assumes there is nothing there and tries to write to it,
when in fact there is a (correctly backed up, but broken) symlink there.

Even when Debian doesn't ship a broken symlink on
/etc/resolv.conf_backup you may be affected if it happens in the future.

The attached patch could be integrated to:

http://anonscm.debian.org/gitweb/?p=collab-maint/wicd.git;a=blob;f=debian/patches/04-fix_resolv.conf_backup-restore.patch;h=25903d6cfdeee3dced21608c451272dfcfb65ce6;hb=HEAD

Which is related

*** /tmp/tmpzaB8yn/bug_body
In Ubuntu, the attached patch was applied to achieve the following:

## fix /etc/resolv.conf resolution when it's a relative sysmlink

  * debian/patches/34-fix-resolv.conf_backup-restore-broken-link.patch:
allow wicd-daemon to start when /etc/resolv.conf is a broken link
(LP: #1132529)

Thanks for considering the patch.


-- System Information:
Debian Release: wheezy/sid
  APT prefers precise-updates
  APT policy: (500, 'precise-updates'), (500, 'precise-security'), (500, 
'precise'), (100, 'precise-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 3.12.1-ck1-ck (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
=== modified file 'debian/changelog'

=== modified file 'debian/control'

=== added file 'debian/patches/34-fix-resolv.conf_backup-restore-broken-link.patch'
--- debian/patches/34-fix-resolv.conf_backup-restore-broken-link.patch	1970-01-01 00:00:00 +
+++ debian/patches/34-fix-resolv.conf_backup-restore-broken-link.patch	2013-12-20 21:15:22 +
@@ -0,0 +1,15 @@
+## Description: fix /etc/resolv.conf resolution when it's a relative sysmlink
+## Forwarded: yes https://code.launchpad.net/~chilicuil/ubuntu/trusty/wicd/fix-1132529/+merge/197998
+## Bug: https://bugs.launchpad.net/wicd/+bug/1193856
+## Author: Tommy (mesilliac)
+--- a/wicd/wicd-daemon.py
 b/wicd/wicd-daemon.py
+@@ -1702,7 +1702,7 @@ def main(argv):
+ backup_location = wpath.varlib + 'resolv.conf.orig'
+ # don't back up if .orig exists, probably there cause
+ # wicd exploded
+-if not os.path.exists(backup_location):
++if not os.path.exists(backup_location) and not os.path.islink(backup_location):
+ if os.path.islink('/etc/resolv.conf'):
+ dest = os.readlink('/etc/resolv.conf')
+ os.symlink(dest, backup_location)

=== modified file 'debian/patches/series'
--- debian/patches/series	2013-06-07 18:42:23 +
+++ debian/patches/series	2013-12-20 21:15:22 +
@@ -5,3 +5,4 @@
 26-support_etc-network_scripts.patch
 32-prefer_gksu.patch
 33-focus_property.patch
+34-fix-resolv.conf_backup-restore-broken-link.patch

Bug#691576: GDB still broken with 3.11.10-1

[Ben Hutchings]

On Fri, Dec 20, 2013 at 09:15:23PM +0100, Émeric MASCHINO wrote:
> 2013/12/12 Ben Hutchings :
> > So far as I know, there is no longer any commercial development of
> > Linux on Itanium.  Some old 'enterprise' distributions might
> > continue to be supported for a few years but mainline isn't
> > supported.
> 
> It seems that Intel must provide hp with Itanium CPUs till 2017 [1][2].
> 
> With respect to this GDB problem, but also people having problem
> booting Wheezy on some systems, does it mean that nobody at Intel
> ensure that Linux still works fine with actual (and upcoming?) Itanium
> CPUs?

Tony Luck at Intel is still maintainer for ia64 but I don't think
even he's working full time on it.

> Well, since hp is the major customer for Itanium CPUs, it's entirely
> plausible after all that hp focuses on hp-ux and thus Intel doesn't
> care about Linux on ia64.

HP focuses on propietary operating systems that it can maintain by
itself and which are now exclusive to Itanium - HP-UX, NonStop and
OpenVMS.

I assume they gave up on Linux/ia64 once the enterprise distributors
did.

> > I heard from Will Deacon that gcc's code generation for ia64 has
> > regressed in 4.6 or earlier and this may be responsible for some
> > reported kernel bugs.  He also though that reducing the
> > optimisation level could help.
> >
> > I actually tried building the kernel like that, so you could try the
> > packages in:
> >
> > http://people.debian.org/~benh/packages/wheezy-ia64-kernel-O1/
> 
> No, I didn't play with GCC optimization settings.
> 
> Was your O1-compiled kernel working fine?

I have no idea as no-one has reported their results yet.

> Do you know if GCC regressions observed by Will Deacon are documented 
> somewhere?

No, you'd have to ask him.

Ben.

-- 
Ben Hutchings
The generation of random numbers is too important to be left to chance.
- Robert Coveyou


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

Bug#729749: ITP: fonts-rabat -- Arabic Maghribi Mabsout OpenType font

[Mohamed Amine]

Hi,


I think you should contact the upstream and obtain a license which
allows at least distribution.  Also, point out concerns and encourage
him to pick established font license, hopefully free one.

Good luck,


Unfortunately, I still haven't had a replay from the upstream.

Thank you for your interest,

Regards,


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

Bug#732738: RFS: qpid-proton/0.6-1 [ITP]

[Darryl L. Pierce]

Package: sponsorship-requests
  Severity: wishlist

  Dear mentors,

  I am looking for a sponsor for my package "qpid-proton"

 * Package name: qpid-proton
   Version : 0.6-1
   Upstream Author : Qpid Proton Team 
 * URL : http://qpid.apache.org/proton
 * License : ASL 2.0
   Section : libs

  It builds those binary packages:

libqpid-proton - C libraries for Qpid Proton.
 libqpid-proton-dev - Development libraries for writing messaging apps
with Qpid Proton
 libqpid-proton-dev-doc - Developer documentation for Qpid Proton
 libqpid-proton-dev-examples - Example applications for writign
messaging apps with Qpid Proton
 python-qpid-proton - Python language bindings for Qpid Proton messaging
framework
 python-qpid-proton-doc - Documentation for the Python language bindings
for Qpid Proton
 qpid-proton - Qpid Proton messaging tools

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

  http://mentors.debian.net/package/qpid-proton


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

dget -x
http://mentors.debian.net/debian/pool/main/q/qpid-proton/qpid-proton_0.6-1.dsc

  More information about hello can be obtained from
http://www.example.com.

  Changes since the last upload:


  Regards,
   Darryl Pierce



pgpE8y9Yw6JGz.pgp
Description: PGP signature

Bug#732737: debian-reference-common: crufty /usr/share/doc/debian-reference-common/html/index.html after upgrade

[Sven Joachim]

Package: debian-reference-common
Version: 2.51
Severity: normal

While upgrading your package I noticed a warning from dpkg that it could
not remove /usr/share/doc/debian-reference-common/html because it's not
empty, and indeed it contains an index.html file which seems to be a
remnant of earlier versions.


-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: i386 (x86_64)

Kernel: Linux 3.13.0-rc4-nouveau (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

debian-reference-common depends on no packages.

debian-reference-common recommends no packages.

Versions of packages debian-reference-common suggests:
pn  calibre  
ii  chromium [www-browser]   31.0.1650.63-1
ii  conkeror [www-browser]   1.0~~pre+git131116-1
ii  iceweasel [www-browser]  24.2.0esr-1
ii  konqueror [www-browser]  4:4.11.3-1
ii  lynx-cur [www-browser]   2.8.8pre1-1
ii  mc   3:4.8.11-1
ii  vim  2:7.4.052-1
ii  w3m [www-browser]0.5.3-13

-- 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#732736: debian-maintainers: Please add Ximin Luo as a DM

[Ximin Luo]

Package: debian-maintainers
Severity: normal

Hello,

Please add Ximin Luo (me) to the Debian Maintainer keyring. The jetring 
changeset is attached with links to my advocates' messages.

Thanks!

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

Kernel: Linux 3.9-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Comment: Add Ximin Luo  as a Debian Maintainer
Date: Fri, 20 Dec 2013 20:31:41 +
Action: import
Recommended-By:
  Mathieu Malaterre 
  Andrea Veri 
  Jérémy Bobbio 
Agreement:
  https://lists.debian.org/debian-newmaint/2013/12/msg00019.html
Advocates:
  https://lists.debian.org/debian-newmaint/2013/12/msg00020.html
  https://lists.debian.org/debian-newmaint/2013/12/msg00023.html
  https://lists.debian.org/debian-newmaint/2013/12/msg00024.html
Data: 
  -BEGIN PGP PUBLIC KEY BLOCK-
  Version: GnuPG v1.4.15 (GNU/Linux)
  
  mQINBExYT8UBEAC+HVwMsQsgclgPDd9v6sTlQFHlVa1ZjgX+Avd8/d+xJZfdIfQb
  MyWEDm9cGjNtMQmcXXmLvsFueatwTHwKPwyMCSD1Irtcv5z7ULT48huHrl19N68l
  hCAp8SRW/NkBQPsJKHNP2GdTNodKHGW9HZtRIgc6fhw49qG00+SCzImQzHZAYlZ1
  dvxhj31Jgzs+xP0sf+zAH/ZdbZOrCDtXKLFO+aN7cg9KOUDBvjkfxDyf0FSLOugt
  Gd/gveEjB4K/urGOe+7CCS0dROevobziHs0v7nZ6yeFd+6SYpN/oEFC8MiEP8e0S
  QWQP+JUKlKE/c6nCpISF6kLCZFgNN6a1rtdDU2P+oQx/PIgnZ1VcDU1lRQTPzFJR
  mwXCP7sUzHXOxlF22P1jxib/Kki6cmdem5wWwO5Q8sDeDkWCGLQDLcKXnDQDQTFA
  mckGYwhpe5lkaU//QjoMn3Ix07ov1oidSc+5QG4iwp2OmCaW0IeKDrqESjwF0iWb
  ojA0HYo37rTz2XAAdDTmmTIwt9wLTgArVPWa6OMGO66WQeZnPnd4Z9FIiAV/0s/K
  GXxHzvuqGm7QDafm2vVAOMOn1ZSd/JokE+bgyk70DcrsWz3IWWRz1QAKhD97gG9n
  g8gUWkLwq7KWpURXafPdG5SH1KL8rbA2/54UXYoyG9tEWUvRNcfsuuLpTwARAQAB
  tB1YaW1pbiBMdW8gPGluZmluaXR5MEBnbXguY29tPohGBBMRAgAGBQJPmbuKAAoJ
  EJAm274fwjevdbgAn2kJ4l1v5d4mNFnzuAgWm0tQPKswAJ4tWcrxBjHbwAkFZhdU
  c+8QRoNcSYhJBBARAgAJBQJMWFA4AgcAAAoJEIQyE86kPHCAVuIAmgNtQwMBNpMq
  YuQUganxtYxWUkl6AJ9ELd5gQkOmt20wn686MFMszJbRq4heBBARCAAGBQJPZNiK
  AAoJECuFpVcgUfJ0ewYA/jop1lrqZXMFaJxfoM4VIQYOiZzQepcYZIYKKdhQ1BJy
  AQCcjGBDBXHv3P0FNxIbGUztUXG3H2CsZ3j5G6uJ+eBkF4kBHAQQAQIABgUCTzgn
  6wAKCRAdV6KXVIKMquWVB/9uioYTq6qQmqZQQHPOtprfCd7SBjLyqpHsPBkSFxki
  8hKDD7vQz5InqTJnHKDjpR1jGiYEHo8mtaHfOPXAT+FMjB5E2hZ/kJceMYcb7uu/
  xN0kpm9ZeNFdn5pADFpEqulJhvQAYyj5pDAJnj+Q0qkuMT6YtAZcrUASf2othGxK
  koqmpockduwMR9zg4OjRCYdKioNUuYc7jSocAjdbMGQjl4WAJXa4SLjGngQgFaLQ
  tgtACHCulBValDHjqmCY8jXGQFC12VnrCr1jbYdIKLZzs52XueCc5k64xic+Nzhf
  vUwSi7E7vWL7fA5I7IB3Tm3N14OiLNNJJ5LKUNO782JqiQEcBBABAgAGBQJQZ0b7
  AAoJEPTMj4/ESJ9vh0kIALMfFNgdcbAFTwsLjCPEtLxDzfawVhQR8k7QjYh6XzrE
  jLhA6Arm/V7IBz9/6ib66Z7qPVIwyKFva41bW6S1LFYuqr4s/8qQYS2fueeB4MYi
  vtiDIeOiof6ut27YpGcaJfUzkTSP4syTNo8uh4oX34pdFbsoYzcW0sdgk1QbRdMS
  0+drHOHLecj1uNdm5lGvHFDL5KILTL9mIgDaODb82UCnYTcyZ9lXgTzPGU5N3o4l
  bawf67In0XyIdcDKn6X+IPcSbthCfHaLos611fVi1OnLk9Z93lixVsiAwr8EnQa9
  XE/2KtUHH0qyUJLjDPE72H++eQp0I8II9ARc5TVU+TGJARwEEAECAAYFAlCDKsYA
  CgkQEop+nrGL4/bTQQgAlOCIGAg3NlqFbFV8Gr8vyw6DUQ98O9Yz5Zk/1JzAU3k1
  dbzLVKgkJj7CpLAQGbHsaqn740o+tI1LLCd0UciSar0TqojMEFXwX9goqR00R3cB
  qVmzLfTX0bjxEaaXaGq7zMWNuPOZKL/C6v+ouU5p3VQvlZ3/WIxArySpbIvi5uZS
  pIABjV7uxH5uNQ63eVfIEQu7RMaLkbq57L5P1WdX4Led3e8gULLcQrLJ/N91f46Z
  v3LCM0UAlTWTuTxE2pv655TRDnqcGVYK/T8yJClet+IZckl1JEUeXwHeQnJH2ZHj
  NIyamAkqzxQsmlIvfI2HF0obJTTV/nAB+kCcjON66YkBsAQQAQIABgUCT6muUAAK
  CRChRVKtoQDxp1ufDJwJDeW5vNtyOhEgRigbh2s73+8mvNprSy/4gQCHc8//IQw/
  9I7Ht4WplgYS4h2lNPLkEbwAp8v8VKW39Th5KRSC+fJDaLppLUR6WMOep+E3ndjj
  AIluxPTF1kdCTTF1Wj7prkdyKwvDN8ZjPvpHxyYPXB/FtPebaJHEMTA6qV4TOH9z
  ebJhdVJr88hJxHFxVbNxdwEH00ddHlt918Z84G6ti3kwiBV2lhedwzrDrNPP1KZ2
  fUvCdmqIZ6fR/3BYkZFVxsEPv9cufhI6cvKNa5tGi8ZjBt4AqXlaJklzUgwK122E
  l6usvXS/0binxzLC594Hu0UAMBUgsLEzeOlmLNxw/iJbt0O6xw/dIh3f84hLyjRS
  IVLPcT0mGYVooowSIdV/hAkzYgSPveyd1eUK5vS3cX3ikTbtco2JXTvPbU/ZLdNB
  i1/xiHw+FA9eg/krs72fiQcGBT+7Q39AqWaF9QlommLrCWbILiTTSyIUVXE3qkE0
  cbbnXy1QukOvs6m7mLkfs0FGvlhBPdbpwxe2IU1WjZhyAIkCHAQQAQIABgUCT4mD
  6wAKCRDNllQWCHi9DnqNEACxl6+tB9CoKqaccui0KcRLhf8zb6lAFCLK7sRwDy31
  sZ2H6TwqMm5iibH2iKgy3+yEWRYZzFctx7TW1rTGQ479WV72CY24FPOAE+GdQi6Q
  utK1hWuw7zPwF5e3wjGBz40YMunwny55Bz5yUWriwQOQLCQEWXDSolrjSE5Oq780
  Bi3eJ23g+ykRYHtUJIflRiL8o7oxYZ1pbsCXgAZCU7f3x/u6zX5MtQ+ZfF44WXQd
  AB85+HacBvbYgF0LxBKsUGy4t527ap4x1Zcpc+xypuqyPUIPgpspbgLFM8kfi6Wh
  KjNbBMlMpfQWIotffbPdhvy9RLzkeGe3Fthx2VtGW5n9wbwFfFzL1ErhKOqsUN4c
  3i+/aP30knuyhXig/6P2cERo27AQ+8CIbCaNzvPJBLu9fe/o6mEVEQe2K7sq/krd
  Cq+cJsr/9PIm4+CZFukSzPhAAm4k+muRfaKdI5jGNomxCq8zSu4t+/s1j9XZrzXp
  AShcqWmiv5mM5Nq8SB+SpsYgvWyqAD++qdJ9OBbTbpj8h0AVhU9JLyFqhn3sn2No
  TEnmd8UNXd2FX3LACh+RpFrP3R9o1raQUHn4VL+DbadM3B1HdJ4p1MCZ7omNn++l
  M06SDVSv6OvC8zzi19XrmPRcfOKPWLO9lh1yBq/gykRifMg3aNvMBDAknzr1AL20
  lokCHAQQAQIABgUCT5eKTAAKCRAP+GWv4myfkDIxEACIspakSvKv+owxH3yyGTJf
  c8xOCi0VJg+csn4XNmiOFlFibqKiOepz7YfJY8Fp9EbC9I3U8dPbFBpqZ6aCnBWc
  5WynQsDe4ECp/b/vTI/PrMn2nkEhk1fVfDISThPYKLvNW49cshckwlUijAET0OUt
  KU6tklisC/3wP6

Bug#732735: performous: FTBFS: Required library Freetype NOT FOUND.

[Roland Stigge]

Source: performous
Version: 0.7.0-2
Severity: serious

Hi,

performous FTBFS in current unstable like this:

...
-- Found Boost 1.54.0
-- Boost_INCLUDE_DIRS: /usr/include
-- Boost_LIBRARIES: 
/usr/lib/powerpc-linux-gnuspe/libboost_thread.so;/usr/lib/powerpc-linux-gnuspe/libboost_date_time.so;/usr/lib/powerpc-linux-gnuspe/libboost_program_options.so;/usr/lib/powerpc-linux-gnuspe/libboost_regex.so;/usr/lib/powerpc-linux-gnuspe/libboost_filesystem.so;optimized;/usr/lib/powerpc-linux-gnuspe/libboost_system.so;debug;/usr/lib/powerpc-linux-gnuspe/libboost_system.so;optimized;/usr/lib/powerpc-linux-gnuspe/libboost_system.so;debug;/usr/lib/powerpc-linux-gnuspe/libboost_system.so
-- checking for module 'sdl'
--   found sdl, version 1.2.15
-- Found SDL 
-- checking for module 'freetype2'
--   found freetype2, version 17.0.11
Freetype_INCLUDE_DIR=Freetype_INCLUDE_DIR-NOTFOUND
Freetype_LIBRARY=/usr/lib/powerpc-linux-gnuspe/libfreetype.so
CMake Error at cmake/Modules/LibFindMacros.cmake:71 (message):
  Required library Freetype NOT FOUND.

  Install the library (dev version) and try again.  If the library is already
  installed, use ccmake to set the missing variables manually.
Call Stack (most recent call first):
  cmake/Modules/FindFreetype.cmake:30 (libfind_process)
  cmake/Modules/LibFindMacros.cmake:10 (find_package)
  cmake/Modules/FindPango.cmake:11 (libfind_package)
  cmake/Modules/LibFindMacros.cmake:10 (find_package)
  cmake/Modules/FindPangoCairo.cmake:11 (libfind_package)
  game/CMakeLists.txt:75 (find_package)


-- Configuring incomplete, errors occurred!
See also "/«PKGBUILDDIR»/build-tree/CMakeFiles/CMakeOutput.log".
make: *** [configure-stamp] Error 1
...


Please note that this happens with cmake 2.8.12.1-1.1 that fixes #731089, a
similar issue.

I also checked that the same happens on amd64.

Roland


-- System Information:
Debian Release: 7.0
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: powerpcspe (ppc)

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


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

Bug#691576: GDB still broken with 3.11.10-1

[Émeric MASCHINO]

2013/12/12 Ben Hutchings :
> So far as I know, there is no longer any commercial development of
> Linux on Itanium.  Some old 'enterprise' distributions might
> continue to be supported for a few years but mainline isn't
> supported.

It seems that Intel must provide hp with Itanium CPUs till 2017 [1][2].

With respect to this GDB problem, but also people having problem
booting Wheezy on some systems, does it mean that nobody at Intel
ensure that Linux still works fine with actual (and upcoming?) Itanium
CPUs?

Well, since hp is the major customer for Itanium CPUs, it's entirely
plausible after all that hp focuses on hp-ux and thus Intel doesn't
care about Linux on ia64.

> I heard from Will Deacon that gcc's code generation for ia64 has
> regressed in 4.6 or earlier and this may be responsible for some
> reported kernel bugs.  He also though that reducing the
> optimisation level could help.
>
> I actually tried building the kernel like that, so you could try the
> packages in:
>
> http://people.debian.org/~benh/packages/wheezy-ia64-kernel-O1/

No, I didn't play with GCC optimization settings.

Was your O1-compiled kernel working fine?

Do you know if GCC regressions observed by Will Deacon are documented somewhere?

 Émeric


[1] 
http://www.xbitlabs.com/news/cpu/display/20120201201109_HP_Paid_Intel_690_Million_to_Keep_Itanium_Alive_Court_Findings.html
[2] http://www.wired.com/wiredenterprise/2012/02/hp-itanium/


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

Bug#732733: [pepperflashplugin-nonfree] Automatically make updates

[Pau Koning]

Package: pepperflashplugin-nonfree
Version: 1.1
Severity: wishlist
Cc: Ariel 

As explained here by Ariel
http://www.deb-multimedia.org/lurker/message/20131219.101816.82419efa.en.html
- it would be very good when this package would automatically download
new version. The flash plugin is one of the most important packages to
get updated next to the browser itself because they are always
interacting with external sources (aka World Wide Web) which cannot be
trusted. It is also a not well hidden secret that the flash plugin is
one of the most vulnerable pieces and therefore has to be updated
quite fast to keep the users safe. The current
pepperflashplugin-nonfree and flashplugin-nonfree packages are not
updated via the normal debian sources and tools but have to be updated
using not easy understandable commands ("easy" as in "every user
capable of handling a package manager and has this thing installed
will run it because it is logical and a everybody knows about it and
understands why it must be done")

It is currently not known how to best implement it but this bug may be
used to discuss it


--- System information. ---
Architecture: amd64
Kernel:   Linux 3.11-2-amd64

Debian Release: jessie/sid
  500 unstablehttp.debian.net


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

Bug#732652: icedove does not load libraries from /usr/lib/icedove

[Carsten Schoenert]

Hello Ximin,

On Thu, Dec 19, 2013 at 10:00:45PM +, Ximin Luo wrote:
> It works fine with iceweasel 26.0. A previous similar package I built
> against icedove 24.0 also worked fine.
> 
> However, with the new icedove 24.1.1, the package installs fine but I
> get this error in the log when starting icedove:
> 
> Failed to load native module at path 
> '/usr/lib/mozilla/extensions/{3550f703-e582-4d05-9a08-453d09bdfdc6}/{6f9d85e0-794d-11dd-ad8b-0800200c9a66}/platform/Linux_x86_64-gcc3/components/libgnomekeyring-icedove.so':
>  (80004005) libldif60.so: cannot open shared object file: No such file or 
> directory
> 
> and the extension is "enabled" but does not work. But libldif60.so
> does exist in /usr/lib/icedove.
> 
> OTOH, if I start icedove with LD_LIBRARY_PATH=/usr/lib/icedove, then
> everything works fine.
> 
> This is possibly related to #724688, but I'm not sure. Shortly after I
> posted my message there, I was no longer able to reproduce the
> "xul24.0" error; instead this "libldif60.so" error popped up, and I
> worked around it as I just described.

can you please make a log with debugging symbols?
https://wiki.debian.org/Icedove#Debugging

Thanks and regards
Carsten


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

Bug#724688: icedove: affects mozilla-gnome-keyring too

[Carsten Schoenert]

forwarded 724688 https://bugzilla.mozilla.org/show_bug.cgi?id=925823
retitle 724688 icedove: libxul.so incompatible with some external addons
thanks

Hello Ximin,

On Thu, Dec 19, 2013 at 06:52:55PM +, Ximin Luo wrote:

> Control: retitle -1 icedove unnecessarily incompatible with some binary 
> extensions, potentially crashing
> Control: severity -1 serious
> 
> This affects mozilla-gnome-keyring too, though only for icedove-dev
> 24.1.1 (worked in icedove-dev 24.0 for me).
> 
> When I try to rebuild that extension against 24.1.1, it installs into
> icedove and is enabled but ineffective, and I get this in the error
> log:
> 
> Failed to load native module at path 
> '/usr/lib/mozilla/extensions/{3550f703-e582-4d05-9a08-453d09bdfdc6}/{6f9d85e0-794d-11dd-ad8b-0800200c9a66}/platform/Linux_x86_64-gcc3/components/libgnomekeyring-icedove.so':
>  (80004005) /usr/lib/icedove/libxul.so: version `xul24.0' not found (required 
> by 
> /usr/lib/mozilla/extensions/{3550f703-e582-4d05-9a08-453d09bdfdc6}/{6f9d85e0-794d-11dd-ad8b-0800200c9a66}/platform/Linux_x86_64-gcc3/components/libgnomekeyring-icedove.so)

Mozilla is versioning the libxul.so since the release of version 24 or
before. So basicly this is not a bug I think. Especially we build our
own "lightning".
The forwareded link is showing that it is nessesary to respect the
correct libxul version for the usage of a own extension.

As i can see you use icedove-dev (>= 17.0) in your control file, the
icedove version has to fit the version from experiemental (currently) if
you want build against the icedove 24.

We are planning to build icedove 24.2 right after the New Years Day and
upload it to unstable, the last ESR version 17 is now eol.

Regards
Carsten


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

Bug#732678: git-buildpackage -A calls lintian with the wrong .changes file

[Raphael Hertzog]

Hi,

On Fri, 20 Dec 2013, Guido Günther wrote:
> On Fri, Dec 20, 2013 at 04:05:14PM +0100, Guido Günther wrote:
> > Can you attach (or mail me directly) the full build output with
> > --git-verbose please.
> [..snip..] 
> 
> Scratch that, patch forthcoming.

Thanks!

> > Do you have any better ideas than checking the dpkg-buildpackage command
> > line for -A to detect wheter we need arch or all? I'd be so cool if
> > dpkg-buildpackage would have a nice way to communicate back such
> > information to build tools.
> 
> This still holds though.

Feel free to open a wishlist bug report. We can certainly imagine
something to improve this, similar to what --status-fd does for dpkg
itself.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


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

Bug#732732: Obtain timezone from environment

[martin f krafft]

Package: iceowl
Version: 1.9-3
Severity: wishlist

Iceowl needs me to specify the local timezone to be able to properly
display the times of appointments. This information is readily
available in the environment on Unix systems, and I think Iceowl
should default to that, rather than making it individually
configurable within the application.

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

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

Versions of packages iceowl depends on:
ii  libasound2  1.0.27.2-3
ii  libatk1.0-0 2.10.0-2
ii  libc6   2.17-96
ii  libcairo2   1.12.16-2
ii  libdbus-1-3 1.6.18-1
ii  libdbus-glib-1-20.100.2-1
ii  libevent-2.0-5  2.0.21-stable-1
ii  libffi5 3.0.10-3
ii  libfontconfig1  2.11.0-2
ii  libfreetype62.4.9-1.1
ii  libgcc1 1:4.8.2-5
ii  libgdk-pixbuf2.0-0  2.28.2-1
ii  libglib2.0-02.37.6-1
ii  libgtk2.0-0 2.24.22-1
ii  libhunspell-1.3-0   1.3.2-6
ii  libjpeg88d-1
ii  libnspr42:4.10.2-1
ii  libnss3 2:3.15.3-1
ii  libnss3-1d  2:3.15.3-1
ii  libpango1.0-0   1.36.0-1
ii  libpixman-1-0   0.30.2-2
ii  libsqlite3-03.8.1-1
ii  libstdc++6  4.8.2-5
ii  libvpx1 1.2.0-2
ii  libx11-62:1.6.2-1
ii  libxext62:1.3.2-1
ii  libxrender1 1:0.9.8-1
ii  libxt6  1:1.1.4-1
ii  zlib1g  1:1.2.8.dfsg-1

Versions of packages iceowl recommends:
pn  calendar-google-provider  

iceowl suggests no packages.

-- no debconf information


-- 
 .''`.   martin f. krafft   Related projects:
: :'  :  proud Debian developer   http://debiansystem.info
`. `'`   http://people.debian.org/~madduckhttp://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#732731: removal of ivritex package broke Hebrew LaTeX.

[Ilya Tsindlekht]

Package: ivritex
Version: 1.1.1-6

Trying to process Hebrew LaTeX document ended in series of error
messages complaining about absence of font files. Manually downloading
and installing ivritex package fixed the problem.

I am using Debian sid. I suggest returning ivritex into debian. (Its
removal is bug #662181.)


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

Bug#727708: Quick upstart and systemd feature comparison

[Russ Allbery]

Ian Jackson  writes:
> Steve Langasek writes:

>> It would be a straightforward incremental change on top of the existing
>> logging support in Upstart.  I'm not sure it's such a great idea to
>> have some logs going to /var/log/upstart and some going via syslog,
>> however; the resulting user/admin confusion may outweigh any benefit
>> from supporting syslog.

> Perhaps it would be possible to have a global setting that changes the
> effect of "log console" to use syslog.

Take a look at the systemd support for how to direct the logs.  (It's in
systemd.exec(5).)  It's quite nice: you can choose whether to log or
discard stdout and stderr independently, you can set the syslog priority
and (more importantly) facility, and you can prefix each line of output
with some identifier.  You can also do a bunch of other stuff with
standard output and standard error for which I don't have as much
immediate need, but which looks rather nice, such as sending output to
both the console and syslog, logging to a tty, logging to a socket, etc.

systemd provides enough facilities to fully replace the daemontools
logging infrastructure plus some, so you can use it to run daemons that
were designed to log to standard output and standard error and direct
those logs to syslog (instead of djb's multilog, which is a nice idea but
which doesn't play well with central infrastructure).  That means that,
for small homegrown stuff, you don't have to bother to add explicit syslog
code and a switch saying whether to use syslog or stdout/stderr; you can
just handle it all in the unit configuration.

-- 
Russ Allbery (r...@debian.org)   


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

Bug#732730: deja-dup missing required dependencies: gvfs gvfs-backends

[Max Badran]

Package: deja-dup
Version: 20.2-2.1
Severity: normal

Hello,

I run a kde desktop and installed deja-dup for automating backups.
There was an issue mounting remote locations as a destination both 
smb and ftp. After a quick look online, it was evident that two 
package were missing:
 
 gvfs 
 gvfs-backends.

After installing the above missing packages, the issue was 
resolved.


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

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

Versions of packages deja-dup depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.12.1-3
ii  duplicity0.6.18-3
ii  libatk1.0-0  2.4.0-2
ii  libc62.13-38
ii  libcairo-gobject21.12.2-3
ii  libcairo21.12.2-3
ii  libgdk-pixbuf2.0-0   2.26.1-1
ii  libglib2.0-0 2.33.12+really2.32.4-5
ii  libgnome-keyring03.4.1-1
ii  libgtk-3-0   3.4.2-7
ii  libnautilus-extension1a  3.4.2-1+build1
ii  libnotify4   0.7.5-1
ii  libpango1.0-01.30.0-1

Versions of packages deja-dup recommends:
ii  openssh-client [ssh-client]  1:6.0p1-4
ii  python-boto  2.3.0-1
pn  python-rackspace-cloudfiles  

deja-dup 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#727708: Quick upstart and systemd feature comparison

[Steve Langasek]

On Fri, Dec 20, 2013 at 10:15:37AM -0800, Russ Allbery wrote:
> > Are you actually looking for syslog per se here, or are you primarily
> > interested in logging of stderr generally?

> I am specifically looking for syslog.  I consider logging to disk files to
> be significantly inferior: I can't use rsyslog to send them to Splunk or
> any other central log server, I have to figure out some special
> incantation to safely rotate them instead of just throwing them into the
> syslog rotation rules, and the date stamp format isn't picked up from the
> general rsyslog configuration.

> Our existing Tomcat init scripts already capture Tomcat output in local
> disk files, so upstart currently doesn't add much value there.  Getting
> them into syslog would be quite helpful.

> This is a relatively minor thing since one can set up some simple
> pipelines to do this (and you can tell that it's minor in that we've not
> done that work yet), but for something as critical as logging it's nice to
> not have to worry about the other end of the pipeline dying and not
> getting restarted or having log messages lost when it does.

Right, those are all pretty much the reasons I would expect for preferring
rsyslog.  As I said, I just think there's a trade-off between supporting
this and having confusing complexity exposed to the users.

On Fri, Dec 20, 2013 at 06:52:51PM +, Ian Jackson wrote:
> Steve Langasek writes ("Bug#727708: Quick upstart and systemd feature 
> comparison"):
> > It would be a straightforward incremental change on top of the existing
> > logging support in Upstart.  I'm not sure it's such a great idea to have
> > some logs going to /var/log/upstart and some going via syslog, however; the
> > resulting user/admin confusion may outweigh any benefit from supporting
> > syslog.

> Perhaps it would be possible to have a global setting that changes the
> effect of "log console" to use syslog.

Yes, I think if we were to implement this, this would be the way I'd prefer
to see it done.

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


signature.asc
Description: Digital signature

Bug#727708: Quick upstart and systemd feature comparison

[Ian Jackson]

Steve Langasek writes ("Bug#727708: Quick upstart and systemd feature 
comparison"):
> It would be a straightforward incremental change on top of the existing
> logging support in Upstart.  I'm not sure it's such a great idea to have
> some logs going to /var/log/upstart and some going via syslog, however; the
> resulting user/admin confusion may outweigh any benefit from supporting
> syslog.

Perhaps it would be possible to have a global setting that changes the
effect of "log console" to use syslog.

> Are you actually looking for syslog per se here, or are you primarily
> interested in logging of stderr generally?  Upstart already does that by
> default, it just logs it to /var/log/upstart instead of to syslog (for
> reasons of avoiding a dependency on on external daemon for debuggability).

Many people are fans of syslog.  I'm sure I don't have to explain why.

Ian.


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

Bug#725143: Bug#728521: ogre-1.9 / gcc-4.8

[Rebecca N. Palmer]

My whole intent of posting my previous message was to agree that you had 
been right about 4.8 becoming required and that this was hence no longer 
our problem.



I think that your attempt to merge the bugs failed.
Yes, can't merge bugs when only one of them is forwarded, and since the 
forwarded part is the part that isn't in the other bug I decided not to 
try again (so if you want to close them, you need to close both).



It's been built successfully in s390x and most other arches (at least
the ones where it was present before with src:ogre-1.9)

The only one we still need is armhf, where this has never been a problem.


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

Bug#732729: libfreetype6: Please upgrade to upstream 2.5.2

[Emmanuel Charpentier]

Package: libfreetype6
Version: 2.5.1-2
Severity: normal

Perusing upstream Web page (http://www.freetype.org/), I saw this on
the front page :

"FreeType 2.5.2 has been released. It fixes a serious bug introduced
in version 2.5.1; all users should upgrade."

The relevant log is :
"CHANGES BETWEEN 2.5.1 and 2.5.2 
I. IMPORTANT BUG FIXES 

  - Improving the display of some broken TrueType fonts introduced a
bug that made FreeType crash on some popular (but not fully
conformant) fonts like `ahronbd.ttf'.

  - Another round of improvements to correct positioning and hinting
of composite glyphs in TrueType fonts.

II. MISCELLANEOUS

  - Version 2.5.1 introduced a bug in handling embedded bitmap strikes
of TrueType fonts, causing garbage display under some circumstances. -
The `ftgrid' demo program couldn't be compiled in non-development
builds."

This might or might not be related to bug#730742.

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (650, 'testing'), (500, 'testing-updates'), (500, 
'testing-proposed-updates'), (60, 'unstable'), (50, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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


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

Bug#732728: quassel-core: 1024 bit key is not secure

[Debian User]

Package: quassel-core
Version: 0.9.2-1
Severity: normal
Tags: patch

When installing quassel-core a 1024 bit private RSA key is generated,
but a 1024 bit key is considered not sufficient for quite some time now.
In the postinst script the nbits value is explicitly set to 1024 and I
see no reason why. According to man:req 
"The argument takes one of several forms. rsa:nbits, where nbits is the
number of bits, generates an RSA key nbits in size. If nbits is omitted,
i.e. -newkey rsa specified, the default key size, specified in the
configuration file is used."

So by not specifying the nbits part, the default (currently 2048) is
used, so the following patch does exactly that.

diff --git a/postinst b/postinst
index b53ac33..87dba5e 100755
--- a/postinst
+++ b/postinst
@@ -40,7 +40,7 @@ fi
 # FIXME: Not over-writing existing certs, but need to (someday) replace
 # old certs
  if [ ! -e $QUASSEL_CERT ] ; then
echo "Generating SSL certificate as $QUASSEL_CERT ..."
-   openssl req -x509 -nodes -batch -days 680 -newkey rsa:1024 -keyout \
+   openssl req -x509 -nodes -batch -days 680 -newkey rsa -keyout \
$QUASSEL_CERT -out $QUASSEL_CERT
chown $QUASSEL_USER:$QUASSEL_GROUP $QUASSEL_CERT
  fi

Cheers,
  Diederik

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'testing-updates'), (500, 'unstable'), 
(1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages quassel-core depends on:
ii  adduser3.113+nmu3
ii  libc6  2.17-97
ii  libgcc11:4.8.2-1
ii  libqca22.0.3-5
ii  libqt4-network 4:4.8.5+git192-g085f851+dfsg-2
ii  libqt4-script  4:4.8.5+git192-g085f851+dfsg-2
ii  libqt4-sql 4:4.8.5+git192-g085f851+dfsg-2
ii  libqt4-sql-sqlite  4:4.8.5+git192-g085f851+dfsg-2
ii  libqtcore4 4:4.8.5+git192-g085f851+dfsg-2
ii  libstdc++6 4.8.2-1
ii  lsb-base   4.1+Debian12
ii  openssl1.0.1e-4

quassel-core recommends no packages.

quassel-core 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#732726: zsh function freeze

[Vincent Lefevre]

On 2013-12-20 19:14:36 +0100, Vincent Lefevre wrote:
> I think that this occurs on big changesets.

Indeed I can reproduce it with:

  svncdiff -c 8540 svn://scm.gforge.inria.fr/svn/mpfr/trunk | head

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


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

Bug#732710: [Pkg-openssl-devel] Bug#732710: openssl: rdrand should be disabled by default

[Kurt Roeckx]

On Fri, Dec 20, 2013 at 09:38:19AM -0500, Marc Deslauriers wrote:
> Package: openssl
> Version: 1.0.1e-4
> Severity: normal
> Tags: patch
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu trusty ubuntu-patch
> 
> OpenSSL uses rdrand exclusively if it is available.
> 
> http://seclists.org/fulldisclosure/2013/Dec/99
> http://wiki.openssl.org/index.php/Library_Initialization#ENGINEs_and_RDRAND
> 
> Upstream has changed this behaviour.

Is this something you want to release a DSA for?  Or should I
upload this to proposed-updates instead?


Kurt


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

Bug#720426: pu: package openssl/1.0.1e-2

[Kurt Roeckx]

On Sat, Dec 14, 2013 at 03:34:03PM +0100, Kurt Roeckx wrote:
> > So can someone please do something about this request?
> 
> Ping?

I'll be makeing an upload to either stable-security or stable
soon.  If you do not want this speak up now.


Kurt


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

Bug#727708: Quick upstart and systemd feature comparison

[Russ Allbery]

Steve Langasek  writes:

> Are you actually looking for syslog per se here, or are you primarily
> interested in logging of stderr generally?

I am specifically looking for syslog.  I consider logging to disk files to
be significantly inferior: I can't use rsyslog to send them to Splunk or
any other central log server, I have to figure out some special
incantation to safely rotate them instead of just throwing them into the
syslog rotation rules, and the date stamp format isn't picked up from the
general rsyslog configuration.

Our existing Tomcat init scripts already capture Tomcat output in local
disk files, so upstart currently doesn't add much value there.  Getting
them into syslog would be quite helpful.

This is a relatively minor thing since one can set up some simple
pipelines to do this (and you can tell that it's minor in that we've not
done that work yet), but for something as critical as logging it's nice to
not have to worry about the other end of the pipeline dying and not
getting restarted or having log messages lost when it does.

-- 
Russ Allbery (r...@debian.org)   


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

Bug#732727: RFP: scrz -- supervisor to run many isolated linux containers on a host system

[Thomas Koch]

Package: wnpp
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: scrz
  Version : 0.0.1
  Upstream Author : Tomas Carnecky 
* URL : http://scrz.io , https://github.com/scrz/scrz
* License : MIT like: http://unlicense.org
  Programming Lang: Haskell
  Description : supervisor to run many isolated linux containers on a host 
system

scrz manages linux containers (configure, start, stop, supervize) and the
images that should be run in those containers. It's inspired by docker.io but
written in Haskell and uses btrfs instead of aufs for image and snapshot
management.

Hi Debian-Haskell folks,

I hope that somebody might be interested in this cool project. I've no
experience with Haskell and would be curious how much work it might be to
package this cool and promising project for Debian?

Regards, Thomas Koch

CC'ed upstream.

More infos on scrz:

- - https://blog.caurea.org/2013/02/03/scrz-deployment-tool.html
- - https://blog.caurea.org/2013/04/04/docker-like-tool-written-in-haskell.html
- - 
https://blog.caurea.org/2013/07/20/scrz-features-which-docker-doesn-t-have.html

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

iQIcBAEBCAAGBQJStIlkAAoJEAf8SJEEK6ZaL2EQAJS3pF8JUmb5RMta5rkHSrhy
n7P3gWLeKxQYGVhpAry9xSIzjikzEYisjZHWsKlCnMQO3/xqvnZrMnnw37bhotov
UBH/GBCULoJM3YjHpJFcDKzVbGKRSLuHZCnPe2jKEPMfOYwMRm8HpAlUEyLGOcm6
kDH/B7qB//HOMplUaAF2QlgyaJO5IhUKb7Sw863BKV3+vCdiA7cb1QBRWJTPqJcr
RM7ZTZ/4nnyAoJYk8nAN7dnrw5PS7bEYtoWEz9nGpllCoxiQn38nXXU4UG10St3h
ZR6+TB/YzIFEasp2fa59tqBJSDbeh7TGSXKvhAthaIWE/hIMlapzcMfaragzBDAZ
g47dUgqr9nOPKHjReYN2hUY7A1tY01WDKSXuwCYv9wFmc4SuWdhaYUFZ8bnZHYDH
xg5R4MCGgsLdZ0Ue3ykFDcOfVOPE3Hdus0ao1zSHHtvZgDLLSljil5i06G3WWJ9e
5X9cPbC9m4kjUBRoM5geWT2QcGJ3WiYJ1uXDW+zkLUn5hYTvX839SkhGDnBrMAxH
PGlz8APpW4b2Dd+5h5MhL2PiogFQCYgtH+AJClUmO0Cqqnv7Ci00Vock3YphKzWr
r/KY2ucfL1G3SuFwIU9LRsURmgK17+XU+x8cVvZ65jdVsftN67mlFfs3KsyNMWj5
5IwOl+1ujso3szKL8Bhw
=UemP
-END PGP SIGNATURE-


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

Bug#732726: zsh function freeze

[Vincent Lefevre]

Package: zsh
Version: 5.0.3-1
Severity: important

This is an important regression (no problems after downgrading to
5.0.2-6), always reproducible.

With a private SVN repository, "svncdiff -c65935 ~/wd | head" freezes, where
svncdiff is the following zsh function (I have "autoload -U svncdiff"):


#!/usr/bin/env zsh

# Wrapper to "svn diff", written by Vincent Lefevre 

# Needs my tdiff utility to process the diff output; otherwise you need
# to remove the "| tdiff" at the end.

# Example of svncdiff usage:
#   svncdiff -5 -x -p file
# for 5 lines of unified context and function information.

emulate -LR zsh
local -a args xopt
setopt EXTENDED_GLOB

while [[ $# -ge 1 ]]
do
  if [[ "x$1" == x-[0-9]# ]] then
args=($args --diff-cmd diff)
xopt=($xopt -U${1[2,-1]})
  elif [[ $# -ge 2 && "x$1" == x-x ]] then
shift
xopt=($xopt $1)
  else
args=($args $1)
  fi
  shift
done

[[ $#xopt -ge 1 ]] && args=(-x "$xopt" $args)
svnwrapper diff "$args[@]" | tdiff

# $Id: svncdiff 38442 2010-08-05 11:41:16Z vinc17/ypig $


The dependencies can be found on .

When svncdiff is called as a script, this is no such problem.

With my tps utility, I can observe:

10987  sshd: vlefevre@pts/2
└─> 10988  -zsh
  └─> 11262  -zsh
├─> 11264  zsh -f -- /home/vlefevre/bin/svnwrapper diff -c65935 
/home/vlefevre/wd
│ └─> 11269  svn diff -c65935 /home/vlefevre/wd
│   ├─> 11273  zsh /home/vlefevre/scripts/ssh mysvn svnserve -t
│   │ ├─> 11295  cat
│   │ └─> 11298  ssh -F /home/vlefevre/.ssh/config -C mysvn svnserve -t
│   └─> 11299  zsh /home/vlefevre/scripts/ssh mysvn svnserve -t
│ ├─> 11317  cat
│ └─> 11320  ssh -F /home/vlefevre/.ssh/config -C mysvn svnserve -t
└─> 11265  perl /home/vlefevre/bin/tdiff

I think that this occurs on big changesets.

$ svncdiff -c65935 ~/wd | wc
   2166   14746  212680

I'll try to investigate, but any idea about which zsh change could
trigger the problem?

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

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

Versions of packages zsh depends on:
ii  libc6   2.17-97
ii  libcap2 1:2.22-1.2
ii  libtinfo5   5.9+20130608-1
ii  zsh-common  5.0.3-1

Versions of packages zsh recommends:
ii  libncursesw5  5.9+20130608-1
ii  libpcre3  1:8.31-2

Versions of packages zsh suggests:
ii  zsh-doc  5.0.3-1

-- 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#732720: RFS: sassc/1.0.1-1 [ITP] -- Command line tool for processing Sass

[Josh Bussdieker]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "sassc"

 * Package name: sassc
   Version : 1.0.1-1
   Upstream Author : Hampton Catlin 
 * URL : http://github.com/hcatlin/sassc
 * License : MIT
   Section : web

It builds those binary packages:

  sassc - Command line tool for processing Sass

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

http://mentors.debian.net/package/sassc


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

  dget -x http://mentors.debian.net/debian/pool/main/s/sassc/sassc_1.0.1-1.dsc

More information about sassc can be obtained from
http://github.com/hcatlin/sassc.

Changes since the last upload:

sassc (1.0.1-1) unstable; urgency=low

  * Initial release (Closes: #732601)

 -- Joshua Bussdieker   Wed, 19 Dec 2013 03:59:20 +0500


  Regards,
   Joshua Bussdieker


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

Bug#732719: libisoburn: use dh-autoreconf for better new-port coverage

[Colin Watson]

Package: libisoburn
Version: 1.3.2-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu ubuntu-patch trusty

Hi,

The ppc64el port requires a patch to libtool.m4.  I don't think that's
in Debian yet, but when it is it will require autoreconfing a bunch of
packages to pick it up.  libisoburn could handle this quite easily by
using dh-autoreconf rather than just autotools-dev; when automake and
libtool are in use (as they are here), dh-autoreconf is a superset of
autotools-dev, and it seems to still build just fine if I do the
following.

  * Use dh-autoreconf to update libtool macros for new ports.

diff -Nru libisoburn-1.3.2/debian/control libisoburn-1.3.2/debian/control
--- libisoburn-1.3.2/debian/control 2013-09-08 14:47:24.0 +0100
+++ libisoburn-1.3.2/debian/control 2013-12-20 17:58:21.0 +
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Debian Libburnia packagers 

 Uploaders: George Danchev , Mario Danic 

-Build-Depends: autotools-dev, pkg-config, debhelper (>= 8),
+Build-Depends: dh-autoreconf, pkg-config, debhelper (>= 8),
libburn-dev (>= 1.3.2), libisofs-dev (>= 1.3.2),
   libreadline-dev, libjte-dev
 Build-Depends-Indep: doxygen
diff -Nru libisoburn-1.3.2/debian/rules libisoburn-1.3.2/debian/rules
--- libisoburn-1.3.2/debian/rules   2011-06-17 20:59:21.0 +0100
+++ libisoburn-1.3.2/debian/rules   2013-12-20 18:01:51.0 +
@@ -6,7 +6,10 @@
 
 
 %:
-   dh $@
+   dh $@ --with autoreconf
+
+override_dh_autoreconf:
+   AUTOMAKE='automake --foreign' dh_autoreconf
 
 override_dh_auto_build:
@@ printf "\n*** libburn  required version: %s ***" 
${libburn_required}

Thanks,

-- 
Colin Watson   [cjwat...@ubuntu.com]


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

Bug#732718: ITP: travatar -- tree based machine translation toolkit

[Koichi Akabe]

Package: wnpp
Severity: wishlist
Owner: Koichi Akabe 

* Package name: travatar
  Version : 0.1.0+git20131219
  Upstream Author : Graham Neubig 
* URL : http://www.phontron.com/travatar/
* License : LGPL-3+
  Programming Lang: C++, Perl
  Description : tree based machine translation toolkit

travatar is tree based statistical machine translation system containing
Tree-to-String (T2S) and Forest-to-String (F2S).

Tree based translation uses syntax trees of natural language and it's
particularly effective for language pairs that require a large amount of
reordering, such as English-Japanese translation.


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

Bug#727708: systemd jessie -> jessie+1 upgrade problems

[Uoti Urpala]

On Fri, 2013-12-20 at 07:53 -0800, Steve Langasek wrote:
> On Thu, Dec 19, 2013 at 11:26:19PM +0100, Josselin Mouette wrote:
> > Le jeudi 19 décembre 2013 à 12:35 -0800, Steve Langasek a écrit :
> > > ecosystem.  This needs to be resolved before logind v205 can reasonably be
> > > adopted, because it's broken by design and needs to be worked around.
> 
> > The new logind is not “broken by design”. Using the cgroups tree is the
> > most correct and secure way to identify which processes are permitted to
> > access specific devices or services. You might disagree with the idea of
> > a single cgroups manager or prefer a less secure mechanism in order to
> > handle corner cases (that have yet to be described), but that doesn’t
> > make the design less correct.
> 
> The design which claims this role for systemd-as-pid-1, and which does not
> adequately address use cases of other existing cgroups consumers in the
> ecosystem (lmctfy, lxc) is broken by design.
> 
> Having a single cgroup writer in userspace is fine.  Coupling it to systemd
> in this manner is not.

You're still not saying what would actually be broken about this. On one
hand you say that you don't disagree with "single cgroup writer"[1], but
on the other hand you talk about "existing cgroups consumers" like lxc.
You certainly can't expect lxc to be the only cgroup user on the system.
Thus the old lxc would not work in the new model in any case, and has to
be modified to use other APIs instead. Given that, what's wrong with
systemd being the one to provide those APIs? If you want to criticize
some specifics of the APIs it provides at the moment, that's mostly
irrelevant to the general design decision in logind to depend on
systemd.

The arguments for using systemd as the cgroup manager given at
http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/
are much better than any you've given against it.


[1] The plan still seems to be to eventually deprecate direct kernel
tree read access too, not only write access; Josselin's "cgroups
manager" is more accurate.


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

Bug#732126: state machine semantics of "initctl restart" are unclear

[James Hunt]

Hi Ian,

Fixed in upstream commit r1585:

http://bazaar.launchpad.net/~upstart-devel/upstart/trunk/revision/1585

Kind regards,

James.
--
James Hunt

#upstart on freenode
http://upstart.ubuntu.com/cookbook
https://lists.ubuntu.com/mailman/listinfo/upstart-devel


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

Bug#732654: zeromq3: FTBFS on powerpcspe: Please update symbols file

[Alessandro Ghedini]

On gio, dic 19, 2013 at 11:09:37 +0100, Roland Stigge wrote:
> I'm attaching a patch that fixes it on powerpcspe. Please note that upon
> integrating, you probably need some conditional adjustments to make it still
> work on other arches.

I'd rather drop the .symbols file for now, and have those symbols not exported
at all upstream, since this is causing problems on other architectures as well.

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;;eg;say~~reverse'


signature.asc
Description: Digital signature

Bug#722217: dpkg --version

[jerome . sequier]

>  > What version of dpkg are you using?  Could it be this problem? >  > dpkg 
> (1.17.5) unstable; urgency=low >  >   [ Guillem Jover ] > [...] >   * Fix 
> segfault in update-alternatives when adding or renaming slaves for > an 
> existing alternative. Regression introduced in dpkg 1.17.2. > Closes: 
> #731710 > 


dpkg is also Debian version 1.16.12 (amd64) on my computer

Jerome

Bug#566279: ruby-prof - new version, adds support for Ruby 1.9

[Jonas Genannt]

Hello,

thanks, could you please write to the bugreport, so I can ask for an sponsor.

Thanks,
Jonas

On Thu, 19 Dec 2013 18:19:30 -0500
Arnaud Cornet  wrote:

> Agreed.
> On Dec 19, 2013 2:27 PM, "Jonas Genannt"  wrote:
> 
> > Hello,
> >
> > > If you agree, please send me an mail or update your package yourself.
> >
> > I will package the newest upstream version of ruby-prof and NMU your
> > package shortly.
> >
> > Thanks,
> > Jonas
> >


-- 


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

Bug#732717: growisofs - TRACKING SERVO FAILURE - Input/output error "

[André Verwijs]

Package: growisofs
Version: 7.1-10
Severity: grave
Tags: upstream
Justification: causes non-serious data loss


using growisofs within terminal fails to burn DVD 

root@Debian-local:/home/verwijs# growisofs -dvd-compat -Z /dev/dvdrw=/media
/DEBIAN-BACKUP-2/Mondo-ISO/mondorescue-1.iso -speed=4
Executing 'builtin_dd if=/media/DEBIAN-BACKUP-2/Mondo-ISO/mondorescue-1.iso
of=/dev/dvdrw obs=32k seek=0'
/dev/dvdrw: restarting DVD+RW format...
/dev/dvdrw: "Current Write Speed" is 4.1x1352KBps.
   16678912/2325174272 ( 0.7%) @3.6x, remaining 9:13 RBU 100.0% UBU   1.2%
   35160064/2325174272 ( 1.5%) @4.0x, remaining 7:35 RBU 100.0% UBU 100.0%
   53608448/2325174272 ( 2.3%) @4.0x, remaining 7:46 RBU 100.0% UBU 100.0%
   72089600/2325174272 ( 3.1%) @4.0x, remaining 7:17 RBU 100.0% UBU 100.0%
   90570752/2325174272 ( 3.9%) @4.0x, remaining 6:59 RBU 100.0% UBU 100.0%
  109051904/2325174272 ( 4.7%) @4.0x, remaining 7:06 RBU  99.9% UBU 100.0%
  127500288/2325174272 ( 5.5%) @4.0x, remaining 6:53 RBU 100.0% UBU 100.0%
  145981440/2325174272 ( 6.3%) @4.0x, remaining 6:43 RBU 100.0% UBU 100.0%
  164462592/2325174272 ( 7.1%) @4.0x, remaining 6:47 RBU 100.0% UBU 100.0%
  182943744/2325174272 ( 7.9%) @4.0x, remaining 6:38 RBU 100.0% UBU 100.0%
  201424896/2325174272 ( 8.7%) @4.0x, remaining 6:30 RBU  99.9% UBU 100.0%
  219873280/2325174272 ( 9.5%) @4.0x, remaining 6:32 RBU 100.0% UBU 100.0%
  238354432/2325174272 (10.3%) @4.0x, remaining 6:25 RBU 100.0% UBU 100.0%
  256835584/2325174272 (11.0%) @4.0x, remaining 6:18 RBU  99.9% UBU 100.0%
  275283968/2325174272 (11.8%) @4.0x, remaining 6:19 RBU 100.0% UBU 100.0%
  293765120/2325174272 (12.6%) @4.0x, remaining 6:13 RBU 100.0% UBU 100.0%
  312246272/2325174272 (13.4%) @4.0x, remaining 6:07 RBU 100.0% UBU 100.0%
  330727424/2325174272 (14.2%) @4.0x, remaining 6:07 RBU 100.0% UBU 100.0%
  349208576/2325174272 (15.0%) @4.0x, remaining 6:02 RBU 100.0% UBU 100.0%
  367656960/2325174272 (15.8%) @4.0x, remaining 5:56 RBU 100.0% UBU 100.0%
  386138112/2325174272 (16.6%) @4.0x, remaining 5:56 RBU 100.0% UBU 100.0%
  404619264/2325174272 (17.4%) @4.0x, remaining 5:51 RBU 100.0% UBU 100.0%
  423100416/2325174272 (18.2%) @4.0x, remaining 5:46 RBU 100.0% UBU 100.0%
  441581568/2325174272 (19.0%) @4.0x, remaining 5:45 RBU 100.0% UBU 100.0%
  460062720/2325174272 (19.8%) @4.0x, remaining 5:40 RBU 100.0% UBU 100.0%
  478511104/2325174272 (20.6%) @4.0x, remaining 5:35 RBU 100.0% UBU 100.0%
  496992256/2325174272 (21.4%) @4.0x, remaining 5:34 RBU 100.0% UBU 100.0%
  515473408/2325174272 (22.2%) @4.0x, remaining 5:30 RBU 100.0% UBU 100.0%
  533954560/2325174272 (23.0%) @4.0x, remaining 5:25 RBU 100.0% UBU 100.0%
  552435712/2325174272 (23.8%) @4.0x, remaining 5:24 RBU 100.0% UBU 100.0%
  570916864/2325174272 (24.6%) @4.0x, remaining 5:19 RBU 100.0% UBU 100.0%
  589398016/2325174272 (25.3%) @4.0x, remaining 5:15 RBU 100.0% UBU 100.0%
  607879168/2325174272 (26.1%) @4.0x, remaining 5:13 RBU 100.0% UBU 100.0%
  626360320/2325174272 (26.9%) @4.0x, remaining 5:09 RBU 100.0% UBU 100.0%
  644841472/2325174272 (27.7%) @4.0x, remaining 5:04 RBU 100.0% UBU 100.0%
  663322624/2325174272 (28.5%) @4.0x, remaining 5:03 RBU 100.0% UBU 100.0%
  681803776/2325174272 (29.3%) @4.0x, remaining 4:58 RBU 100.0% UBU 100.0%
  60016/2325174272 (30.1%) @3.9x, remaining 4:54 RBU 100.0% UBU 100.0%
  700874752/2325174272 (30.1%) @0.2x, remaining 5:03 RBU 100.0% UBU 100.0%
:-[ WRITE@LBA=538f0h failed with SK=4h/TRACKING SERVO FAILURE]: Input/output
error
:-( write failed: Input/output error
/dev/dvdrw: flushing cache
:-[ FLUSH CACHE failed with SK=4h/TRACKING SERVO FAILURE]: Input/output error
/dev/dvdrw: writing lead-out

root@Debian-local:/home/verwijs#


need advice on how to solve it or fix this bug...



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

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

Versions of packages growisofs depends on:
ii  libc6   2.13-38
ii  libgcc1 1:4.7.2-5
ii  libstdc++6  4.7.2-5

growisofs recommends no packages.

growisofs 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#732122: semantics of boolean event specification not defined in init(5)

[James Hunt]

Hi Ian,

I've expanded the section on 'start on' in upstream commit r1584:

http://bazaar.launchpad.net/~upstart-devel/upstart/trunk/revision/1584

Kind regards,

James.
--
James Hunt

#upstart on freenode
http://upstart.ubuntu.com/cookbook
https://lists.ubuntu.com/mailman/listinfo/upstart-devel


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

Bug#732200: ITP: Open Time Zone Converter -- A simple app to convert the time and date between two different zones.

[Steve Cotton]

On Tue, Dec 17, 2013 at 00:06 +0900, David Maiorino wrote:
> Questions:
> 1. "please use system-supplied widgets on the right hand panel
> too". For this request, my idea was to limit the amount of knobs
> that could be touched. So the date and time the user knows would be
> but on the left, and the result they wanted would be on the right.
> Would it make sense to have this adjustable on both sides.

I was wrong to suggest using widgets on the right hand side,
limiting the number of knobs is better.  I was thinking of ways to
show the date in the right hand panel in a system-supplied
localised format.

Please use the DateFormat class to create the string that goes in
newTimeLabel, so that it is localised. 

> 2. Copyrights. Would anybody know if we need to add copyrights
> for the classes used in this program? The program runs fine with
> OpenJDK as well, so maybe a solution would be to package it to run
> with OpenJDK?

My concern was with the lists of timezones in
TimeZoneMenu.simplifiedTimezoneList, africaTimezoneList etc, and I
thought that they would be removed as part of the localisation
process anyway.

But now I see that those lists are selected by hand from a much
longer list that's available from the TimeZone system class, with
no way to create the short list programatically.  Also those
strings are IDs which don't change between locales.

I think that's OK, it's similar to names of methods and classes.
(But I'm not an authority on this).

Cheers,
Steve


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

Bug#722217: legacy304 also

[Wendy J. Elmer]

> 
> What version of dpkg are you using?  Could it be this problem?
> 
> dpkg (1.17.5) unstable; urgency=low
> 
>   [ Guillem Jover ]
> [...]
>   * Fix segfault in update-alternatives when adding or renaming slaves for
> an existing alternative. Regression introduced in dpkg 1.17.2.
> Closes: #731710
> 

dpkg 1.16.12 from jessie/testing

Brent

Bug#732064: lapack depends on specific blas implementation

[Andrey Gursky]

2013/12/19, Sébastien Villemot :
> Le mardi 17 décembre 2013 à 16:47 +0100, Andrey Gursky a écrit :
>
>> Sebastien, thanks for pointing this out. I've also got caught in the
>> same trap. But this would mean a trade-off, since openblas's version
>> of lapack is just striped away for now. Should I open a new bug for
>> openblas or could it be, that optimizations of openblas's lapack are
>> not significant enough?
>
> My understanding is that OpenBLAS does not provide a specialized version
> of LAPACK. It just gives the possibility of bundling LAPACK within the
> libopenblas.a, which is uninteresting for us. But I have not
> investigated this too much, so if OpenBLAS provides a customized LAPACK
> as ATLAS does, then please open a wishlist bug against openblas.

I just was confused by the thread [1], where an opinion(?) was expressed:
"Now, because the both ATLAS and OpenBLAS versions of LAPACK have some
functions overridden with more efficient versions..."

Now comparing OpenBLAS.git and lapack-3.5.0 yields:
...
Only in OpenBLAS.git/lapack: getf2
Only in OpenBLAS.git/lapack: getrf
Only in OpenBLAS.git/lapack: getri
Only in OpenBLAS.git/lapack: getrs
...
Only in OpenBLAS.git/lapack: laswp
Only in OpenBLAS.git/lapack: lauu2
Only in OpenBLAS.git/lapack: lauum
...
Only in OpenBLAS.git/lapack: potf2
Only in OpenBLAS.git/lapack: potrf
Only in OpenBLAS.git/lapack: trti2
Only in OpenBLAS.git/lapack: trtri

>> I'm wondering, whether lapack interface could be remaining general
>> modified in a way, atlas and openblas could use it without changing.
>> Or the things are more complicated?
>
> When you use the general LAPACK in Debian, you still benefit from ATLAS
> and OpenBLAS optimizations everytime LAPACK calls a BLAS function. Does
> this answer your question?

Yes, I was surprised, that besides a BLAS optimization an optimization
of LAPACK is also needed. Considering at least a statement from ATLAS
FAQ [2]:
"The provided LAPACK routines utilize a recursive algorithm that
should yield reliably better results than the more common
staticly-blocked algorithms."
and it seems the ATLAS LAPACK is not a patched general netlib LAPACK at all.

Anyway, I believe, this bug report belongs to be merged with the one
you've mentioned (#576972).

[1] https://fedorahosted.org/fpc/ticket/352
[2] http://math-atlas.sourceforge.net/faq.html#optcomp


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

Bug#732716: RFP: weave-minimal -- lightweight firefox weave/sync server

[nodiscc]

Package: wnpp
Severity: wishlist

* Package name: weave-minimal
  Version : 1.4
  Upstream Author : Martin Zimmermann 
* URL : https://github.com/posativ/weave-minimal
* License : MIT
  Programming Lang: Python
  Description : lightweight firefox weave/sync server

a Firefox Sync Server that just works: This is a lightweight implementation of 
Mozillas' User API v1.0 and Storage API v1.1 without LDAP, MySQL, Redis etc. 
overhead. It is multi users capable and depends only on werkzeug.

I mean, really lightweight and really simple to install. No hg-attack clone 
fetch fail apt-get install. It just works.


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

Bug#732678: [git-buildpackage/master] Determine changes file name based on dpkg-buildpackage options

[Guido Günther]

tag 732678 pending
thanks

Date:   Fri Dec 20 17:01:17 2013 +0100
Author: Guido Günther 
Commit ID: eec8ce3e2f35d6f06a5ddb9b4a6f264a1ecf4bca
Commit URL: 
https://honk.sigxcpu.org/gitweb/?p=git-buildpackage.git;a=commitdiff;h=eec8ce3e2f35d6f06a5ddb9b4a6f264a1ecf4bca
Patch URL: 
https://honk.sigxcpu.org/gitweb/?p=git-buildpackage.git;a=commitdiff_plain;h=eec8ce3e2f35d6f06a5ddb9b4a6f264a1ecf4bca

Determine changes file name based on dpkg-buildpackage options

Closes: #732678
  


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

Bug#732678: git-buildpackage -A calls lintian with the wrong .changes file

[Guido Günther]

On Fri, Dec 20, 2013 at 04:05:14PM +0100, Guido Günther wrote:
> Can you attach (or mail me directly) the full build output with
> --git-verbose please.
[..snip..] 

Scratch that, patch forthcoming.

> Do you have any better ideas than checking the dpkg-buildpackage command
> line for -A to detect wheter we need arch or all? I'd be so cool if
> dpkg-buildpackage would have a nice way to communicate back such
> information to build tools.

This still holds though.
Cheers,
 -- Guido


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

Bug#732714: ca-certificates: New version of certdata.txt distrusts AC DG Tresor SSL CA

[Marc Deslauriers]

Package: ca-certificates
Severity: normal
Tags: security


Mozilla has released nss 3.15.3.1 that specifically distrusts
the AC DG Tresor SSL CA.

ca-certificates needs to be updated to the new certdata.txt.


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

Bug#732715: liblist-moreutils-perl: "Attempt to free unreferenced scalar" in some use cases of List::MoreUtils::part

[Christoph Biedl]

Package: liblist-moreutils-perl
Version: 0.33-1+b2
Severity: normal

Dear Maintainer,

This is quite weird. If the code used in `part`

* is built using given..when
* does a return after a match on the first value of the list

the code will result in the dreaded "Attempt to free unreferenced scalar"
message. Reproducer (tested on amd64 and i386):

{{{
#!/usr/bin/perl

use 5.010;
use List::MoreUtils;

my @files = (
'foo',
'bar',
);

my @groups = List::MoreUtils::part (
sub {
given ($_) {
when ('foo') {
return 0;   # this return is evil
}
default {
return 1;   # this one does no harm
}
}
},
@files,
);
}}}

Output:
{{{
given is experimental at reproducer line 13.
when is experimental at reproducer line 14.
Attempt to free unreferenced scalar: SV 0x1c1ae98, Perl interpreter: 0x1c18010.
}}}

There is more than one workaround: Omit the "return" keyword.
Rewriting the code to "return" outside the given..when block does
the trick, too. The pure Perl implementation does the right thing,
too.

As said before, the message is triggered by the way the code block
is left for the first list element of the list processed, in other
words, this one

{{{
when ('bar') {
1;
}
default {
return 0;
}
}}}

is affected, too.

So I think somebody should take a look into that. I'm concerned the
observation is just a symptom of a bigger problem like data
corruption.


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

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

Versions of packages liblist-moreutils-perl depends on:
ii  libc6   2.17-97
ii  perl5.18.1-5
ii  perl-base [perlapi-5.18.1]  5.18.1-5

liblist-moreutils-perl recommends no packages.

liblist-moreutils-perl suggests no packages.

-- no debconf information



signature.asc
Description: Digital signature

Bug#732623: lightdm-gtk-greeter: Hibernate and Restart buttons disappear after first login/logout

[Vincent Lefevre]

Control: reassign -1 lightdm 1.8.5-2
Control: retitle -1 lightdm_get_can_hibernate and lightdm_get_can_restart 
return FALSE after first login/logout

On 2013-12-19 15:09:01 +0100, Vincent Lefevre wrote:
> Package: lightdm-gtk-greeter
> Version: 1.6.1-4
> Severity: normal
> 
> Initially the following buttons are present in the top-right menu:
> 
> Suspend
> Hibernate
> Restart...
> Shutdown...
> 
> But after the first login/logout, the Hibernate and Restart ones
> disappear. I don't see any reason for that.

This is not a bug in lightdm-gtk-greeter itself, as the greeter
just calls the lightdm_get_can_* functions to decide whether the
menu items should be visible or not.

If I modify the liblightdm-gobject/power.c lightdm file to return
TRUE in all these functions, the problem no longer occurs. So, this
confirms that the problem comes from there. Thus reassigning.

I've tried to add some debug messages in these functions, but they
do not appear in the log files! I've attached the patch I've used.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
--- liblightdm-gobject/power.c  2013-10-09 05:16:00.0 +0200
+++ liblightdm-gobject/power.c  2013-12-20 16:13:29.559203457 +0100
@@ -88,6 +88,7 @@
 gboolean can_suspend = FALSE;
 GVariant *r;
 
+g_debug ("lightdm_get_can_suspend: calling login1_call_function 
(CanSuspend)");
 r = login1_call_function ("CanSuspend", NULL, NULL);
 if (r)
 {
@@ -96,18 +97,23 @@
 {
 g_variant_get (r, "(&s)", &result);
 can_suspend = g_strcmp0 (result, "yes") == 0;
+g_debug ("lightdm_get_can_suspend: can_suspend == %d via 
login1_call_function", (int) can_suspend);
 }
 }
 else
 {
+g_debug ("lightdm_get_can_suspend: calling upower_call_function 
(SuspendAllowed)");
 r = upower_call_function ("SuspendAllowed", NULL);
 if (r && g_variant_is_of_type (r, G_VARIANT_TYPE ("(b)")))
+{
 g_variant_get (r, "(b)", &can_suspend);
+g_debug ("lightdm_get_can_suspend: can_suspend == %d via 
upower_call_function", (int) can_suspend);
+}
 }
 if (r)
 g_variant_unref (r);
 
-return can_suspend;
+return TRUE;
 }
 
 /**
@@ -153,6 +159,7 @@
 gboolean can_hibernate = FALSE;
 GVariant *r;
 
+g_debug ("lightdm_get_can_hibernate: calling login1_call_function 
(CanHibernate)");
 r = login1_call_function ("CanHibernate", NULL, NULL);
 if (r)
 {
@@ -161,18 +168,23 @@
 {
 g_variant_get (r, "(&s)", &result);
 can_hibernate = g_strcmp0 (result, "yes") == 0;
+g_debug ("lightdm_get_can_hibernate: can_hibernate == %d via 
login1_call_function", (int) can_hibernate);
 }
 }
 else
 {
+g_debug ("lightdm_get_can_hibernate: calling upower_call_function 
(HibernateAllowed)");
 r = upower_call_function ("HibernateAllowed", NULL);
 if (r && g_variant_is_of_type (r, G_VARIANT_TYPE ("(b)")))
+{
 g_variant_get (r, "(b)", &can_hibernate);
+g_debug ("lightdm_get_can_hibernate: can_hibernate == %d via 
upower_call_function", (int) can_hibernate);
+}
 }
 if (r)
 g_variant_unref (r);
 
-return can_hibernate;
+return TRUE;
 }
 
 /**
@@ -248,6 +260,7 @@
 gboolean can_restart = FALSE;
 GVariant *r;
 
+g_debug ("lightdm_get_can_restart: calling login1_call_function 
(CanReboot)");
 r = login1_call_function ("CanReboot", NULL, NULL);
 if (r)
 {
@@ -256,18 +269,23 @@
 {
 g_variant_get (r, "(&s)", &result);
 can_restart = g_strcmp0 (result, "yes") == 0;
+g_debug ("lightdm_get_can_restart: can_restart == %d via 
login1_call_function", (int) can_restart);
 }
 }
 else
 {
+g_debug ("lightdm_get_can_restart: calling ck_call_function 
(CanRestart)");
 r = ck_call_function ("CanRestart", NULL);
 if (r && g_variant_is_of_type (r, G_VARIANT_TYPE ("(b)")))
+{
 g_variant_get (r, "(b)", &can_restart);
+g_debug ("lightdm_get_can_restart: can_restart == %d via 
ck_call_function", (int) can_restart);
+}
 }
 if (r)
 g_variant_unref (r);
 
-return can_restart;
+return TRUE;
 }
 
 /**
@@ -310,6 +328,7 @@
 gboolean can_shutdown = FALSE;
 GVariant *r;
 
+g_debug ("lightdm_get_can_shutdown: calling login1_call_function 
(CanPowerOff)");
 r = login1_call_function ("CanPowerOff", NULL, NULL);
 if (r)
 {
@@ -318,18 +337,23 @@
 {
 g_variant_get (r, "(&s)", &result);
 can_shutdown = g_strcmp0 (result, "yes") == 0;
+g_debug ("lightdm_get_can_shutdown: can_shutdown == %d via 
login1_call_function", (int) can_shutdown);
 }
 }
   

Bug#727708: systemd jessie -> jessie+1 upgrade problems

[Steve Langasek]

On Thu, Dec 19, 2013 at 11:26:19PM +0100, Josselin Mouette wrote:
> Le jeudi 19 décembre 2013 à 12:35 -0800, Steve Langasek a écrit :
> > The reasons for not upgrading to the current version of logind aren't to do
> > with any fragility of the existing glue code (the systemd-shim package), but
> > because logind 205 has a new dependency on systemd as cgroup manager, which
> > is architecturally incompatible with other consumers of cgroups in the
> > ecosystem.  This needs to be resolved before logind v205 can reasonably be
> > adopted, because it's broken by design and needs to be worked around.

> The new logind is not “broken by design”. Using the cgroups tree is the
> most correct and secure way to identify which processes are permitted to
> access specific devices or services. You might disagree with the idea of
> a single cgroups manager or prefer a less secure mechanism in order to
> handle corner cases (that have yet to be described), but that doesn’t
> make the design less correct.

The design which claims this role for systemd-as-pid-1, and which does not
adequately address use cases of other existing cgroups consumers in the
ecosystem (lmctfy, lxc) is broken by design.

Having a single cgroup writer in userspace is fine.  Coupling it to systemd
in this manner is not.

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


signature.asc
Description: Digital signature

Bug#727708: upstart upstream maintenance practices

[Steve Langasek]

Hi Russ,

On Thu, Dec 19, 2013 at 11:19:37AM -0800, Russ Allbery wrote:
> Could someone (Steve, most likely) provide a bit of background for how
> upstart upstream maintenance works and relates to its packaging?

> This question is prompted by a few different things, set off by looking at
> the SELinux support since this is something I expect to start looking at
> for my day job.  From there, I found that the SELinux context support in
> upstart is somewhat limited, but more interestingly is being maintained as
> a patch in the Debian package.  (But maybe that's because the Debian
> packaging is one version behind?)

> I then looked at the Ubuntu patch for upstart and was rather surprised to
> find that it's quite large (although a lot of that is regeneration of the
> Autotools files -- can I recommend dh-autoreconf?).  There appear to be
> substantive code changes in Ubuntu's packaging of upstart that aren't
> upstream, which surprised me.

> How does this all work?  How do changes flow from Debian and Ubuntu
> packaging into upstream, and why would the packaging be carrying
> substantial local patches for software that's maintained upstream by (at
> least as I understand it) the same project?  Is there a separate policy
> about what goes into upstream that precludes things that aren't considered
> fully baked?

I'm attaching the full delta against upstream currently in the Ubuntu
packaging VCS branch, for reference.  FWIW, I'm not sure which version you
were looking at, but the current version of the Ubuntu package
(1.11-0ubuntu1) does not include any delta against autogenerated autotools
files (and does use dh-autoreconf).  Also FWIW, the attached patch includes
changes not yet released to Ubuntu (actually, just an update to sync the
packaging with the version in Debian).

The attached delta is generated from:

  bzr diff -pa/:b/ -r tag:upstream-1.11 lp:ubuntu/upstart | filterdiff -x 
'**/debian/**'

plus a bit of postprocessing.

I've dissected the current delta and provided an explanation below for each
bit, but the short answer to your question is yes: there are different
policies for upstream vs. the Ubuntu package.  Although efforts are made to
keep the distro delta as small as possible, changes are sometimes applied to
the package before they're in a state that they can be included in upstream
in the interest of expediency.

As for Upstart and Ubuntu being maintained "by the same project": if Upstart
were intended to be "Ubuntu's init system", it would be reasonable to do all
of the maintenance on a single upstream branch.  But it was never intended
to be Ubuntu's init system, but rather "the init system", and as there are
other downstreams besides Ubuntu, care is taken to not embed Ubuntu-specific
policy upstream.

So while there is some delta between Ubuntu and upstream right now, the
delta between Debian and Ubuntu packages has been the greater focus of
attention and has posed the greater maintenance challenge while trying to
converge Ubuntu's packaging (which made reasonable assumptions of
Upstart-everywhere) with Debian's (which did not).


Now for the current delta, the changes here consist of a few different
things:

 - Changes to core jobs for integration with Debian/Ubuntu.  E.g.,
   conf/rc-sysinit.conf is changed to refer to 'filesystem' and
   'static-network-up' events that are provided by components external to
   upstart (mountall and ifupdown respectively).  They are deemed
   inappropriate for upstream, because upstream upstart shouldn't have
   dependencies on distro-specific implementations.  Likewise, conf/rc.conf
   has 'emits' lines added for documentation, which are only true when using
   a version of initscripts that includes upstart integration.
 - References to the Debian/Ubuntu-specific upstart-events(7) manpage, which
   describes event policy as it exists here.  Not upstreamable for the same
   reason as the job changes; none of this applies to other users of upstart
   (e.g.: RHEL6, Chrome OS).
 - SELinux support.  This was accepted as a distro patch in Debian, but has
   not been submitted under Canonical's contributor licensing agreement, so
   at present is not suitable for inclusion upstream per the upstream
   contribution policy.  We are happy to carry such patches in the
   Debian/Ubuntu packaging delta where appropriate, though of course would
   prefer that such changes be mergeable upstream.
 - A minor build fix for configure.ac, to make the test suite function
   correctly under make -j.  This is needed on systems with newer automake,
   and incompatible with systems with older automake, so carried as a distro
   patch for now.
 - A patch to disable apparmor in containers and liveCDs.  This patch is
   from a member of the Ubuntu security team.  I'm not sure why it's not
   upstreamed, but it's a minor patch and not at the top of my todo list to
   resolve.
 - A patch to work around
   , which

Bug#732713: dh-python testsuite fails (wrong assumptions about symlink handling)

[Steve Langasek]

Package: dh-python
Version: 1.20131021-2
Severity: important

The dh-python package in Debian has its test suite disabled via
debian/rules, with a 'FIXME' comment.  The reason for this, it appears, is
that t201 is completely broken wrt the actual symlink handling in dh-python.

tests/t201/Makefile includes the following check:

[ "`readlink 
debian/python-foo/usr/lib/python$(DPY)/dist-packages/foo/absolute_link_to_tmp`" 
= "/tmp" ]
[ "`readlink 
debian/python-foo/usr/lib/python$(DPY)/dist-packages/foo/link_to_parent_dir`" = 
".." ]

But dh_python2 unconditionally moves symlinks from /usr/lib/python* to
/usr/share/pyshared, replacing them with relative symlinks in the original
directory.

for package, pdetails in dh.packages.items():
[...]
if not private_dir:
share(package, stats, options)d exists(pyshared_dir):

I don't know which of these you consider "correct", but they're obviously
inconsistent, which makes it impossible to use the test suite for the
purpose of detecting regressions in the code.

I'm happy to provide a patch if you can tell me which should be changed, the
code or the test.

Bypassing this check gives me a subsequent failure in tests t202, t204, and
t206 because of hard-coded references to python2.6 that are easily fixed,
and presumably would have been noticed if the testsuite hadn't been disabled
in the package.

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


signature.asc
Description: Digital signature

Bug#727708: Quick upstart and systemd feature comparison

[Steve Langasek]

On Wed, Dec 18, 2013 at 06:59:50PM -0800, Russ Allbery wrote:
> Features that systemd provides that I didn't see in upstart (please
> correct me if I'm wrong):

> * StandardError=syslog.  This would be *so nice* for *so many things*.
>   Particularly for running Java applications, which are very bad about not
>   sending everything to syslog even when one tries to write them to do so.
>   I would start using this immediately.  There are various external
>   programs that can do this, but with sysvinit you have to set up the
>   pipelines yourself and worry about the programs dying, whereas systemd
>   takes care of all of that.

It would be a straightforward incremental change on top of the existing
logging support in Upstart.  I'm not sure it's such a great idea to have
some logs going to /var/log/upstart and some going via syslog, however; the
resulting user/admin confusion may outweigh any benefit from supporting
syslog.

Are you actually looking for syslog per se here, or are you primarily
interested in logging of stderr generally?  Upstart already does that by
default, it just logs it to /var/log/upstart instead of to syslog (for
reasons of avoiding a dependency on on external daemon for debuggability).

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


signature.asc
Description: Digital signature

Bug#702882:

[Mathieu Malaterre]

reopen 702882
thanks

Logs states:

https://buildd.debian.org/status/fetch.php?pkg=igraph&arch=i386&ver=0.6.5-4&stamp=1387553594

[...]

checking for f77_alloc_ in -lf2c... no
checking for f77_alloc in -lf2c... no
checking for F77_ALLOC_ in -lf2c... no
checking for F77_ALLOC in -lf2c... no
not found

[...]


dpkg-shlibdeps: warning: package could avoid a useless dependency if
debian/libigraph0/usr/lib/i386-linux-gnu/libigraph.so.0.0.0 was not
linked against libf2c.so.2 (it uses none of the library's symbols)
   dh_installdeb -a -O--parallel


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

Bug#732144: Bug#731357: opu: package librsvg/2.26.3-2

[Raphael Geissert]

Hi again,

Found another case where it didn't work as expected. Updated,
attached, patch should do it.

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net
Index: librsvg-2.26.3/rsvg-image.c
===
--- librsvg-2.26.3.orig/rsvg-image.c	2013-12-20 14:28:57.731991069 +0100
+++ librsvg-2.26.3/rsvg-image.c	2013-12-20 14:38:59.384692376 +0100
@@ -325,22 +325,7 @@ rsvg_acquire_vfs_resource (const char *f
 
 file = g_file_new_for_uri (filename);
 
-if (!(res = g_file_load_contents (file, NULL, &data, &size, NULL, error))) {
-if (base_uri != NULL) {
-GFile *base;
-
-rsvg_free_error (error);
-
-g_object_unref (file);
-
-base = g_file_new_for_uri (base_uri);
-file = g_file_resolve_relative_path (base, filename);
-g_object_unref (base);
-
-res = g_file_load_contents (file, NULL, &data, &size, NULL, error);
-}
-}
-
+res = g_file_load_contents (file, NULL, &data, &size, NULL, error);
 g_object_unref (file);
 
 if (res) {
@@ -356,23 +341,136 @@ rsvg_acquire_vfs_resource (const char *f
 }
 #endif
 
+/* Partial origin-based policy, based on the one implemented in f01aded72c38f0e1  */
+gboolean
+_rsvg_acquire_xlink_allow_load (const char *href, const char *base_uri, GError ** err)
+{
+char *base_scheme = NULL, *href_scheme = NULL;
+
+if (base_uri)
+base_scheme = g_uri_parse_scheme (base_uri);
+if (href)
+href_scheme = g_uri_parse_scheme (href);
+
+/* Not a valid URI */
+if (href_scheme == NULL)
+goto deny;
+
+/* Allow loads of data: from any location */
+if (g_str_equal (href_scheme, "data"))
+goto allow;
+
+/* no valid base URI */
+if (base_scheme == NULL)
+goto deny;
+
+/* Deny loads from differing URI schemes */
+if (href_scheme == NULL || !g_str_equal (href_scheme, base_scheme))
+goto deny;
+
+/* resource: is allowed to load anything from other resources */
+if (g_str_equal (href_scheme, "resource"))
+goto allow;
+
+/* Non-file: isn't allowed to load anything */
+if (!g_str_equal (href_scheme, "file"))
+goto deny;
+
+/* no local-file policy is applied here */
+
+allow:
+free(base_scheme);
+free(href_scheme);
+return TRUE;
+
+deny:
+free(base_scheme);
+free(href_scheme);
+g_set_error (err, G_IO_ERROR, G_IO_ERROR_PERMISSION_DENIED,
+ "File may not link to URI \"%s\"", href);
+return FALSE;
+}
+
 GByteArray *
 _rsvg_acquire_xlink_href_resource (const char *href, const char *base_uri, GError ** err)
 {
 GByteArray *arr = NULL;
+char *base_scheme = NULL, *href_scheme = NULL;
+char *href_uri = NULL;
+#ifndef HAVE_GIO
+/* to be used ONLY for the policy check */
+GString *href_uri_str = NULL;
+#endif
 
 if (!(href && *href))
 return NULL;
 
-if (!strncmp (href, "data:", 5))
+if (base_uri)
+base_scheme = g_uri_parse_scheme (base_uri);
+if (href)
+href_scheme = g_uri_parse_scheme (href);
+
+if (href_scheme && g_str_equal (href_scheme, "data"))
 arr = rsvg_acquire_base64_resource (href, NULL);
+if (arr)
+goto done;
 
-if (!arr)
+#ifdef HAVE_GIO
+/* if href is not a URI already, turn it into one based on base_uri */
+if (href_scheme == NULL) {
+GFile *file, *base, *parentless_base;
+base = g_file_new_for_uri (base_uri);
+/* now strip the file name: */
+parentless_base = g_file_get_parent (base);
+file = g_file_resolve_relative_path (parentless_base, href);
+
+g_object_unref (base);
+g_object_unref (parentless_base);
+href_uri = g_file_get_uri(file);
+g_object_unref (file);
+} else {
+href_uri = strdup (href);
+if (!href_uri) /* FIXME: better handling failure */
+goto done;
+}
+#else
+if (href_scheme == NULL) {
+href_uri_str = g_string_new(href);
+if (base_scheme) {
+/* try to turn href into a uri */
+g_string_prepend (href_uri_str, "://");
+g_string_prepend (href_uri_str, base_scheme);
+/* no need to free, as href_scheme is NULL, remember? */
+href_scheme = strdup (base_scheme);
+if (!href_scheme) /* FIXME: better handling failure */
+goto done;
+} else
+goto done;
+} else {
+href_uri_str = g_string_new(href);
+}
+href_uri = href_uri_str->str;
+#endif
+
+if (!_rsvg_acquire_xlink_allow_load(href_uri, base_uri, err))
+goto done;
+
+#ifdef HAVE_GIO
+arr = rsvg_acquire_vfs_resource (href_uri, base_uri, NULL);
+#else
+/* href must be a path for fopen() to work */
+if (g_str_equal (href_scheme, "file"))
 arr = rsvg_acquire_file_resource (href, base_uri, NULL);
+#endif
+
+done:
+f

Bug#732677: RFS: ruby-specinfra/0.0.16-1 [ITP]

[Satoru KURASHIKI]

hi,

On Fri, Dec 20, 2013 at 6:15 PM,  wrote:

> checked and uploaded.
>

Thanks!

regards,
-- 
KURASHIKI Satoru

Bug#732125: upstart-events(7) title is misleading

[James Hunt]

Hi Ian,

As suggested, I've moved the appropriate sections to init(8) upstream as commit
r1581:

http://bazaar.launchpad.net/~upstart-devel/upstart/trunk/revision/1581

Note that upstart-events(7) is an Ubuntu+Debian-specific man page so
debian/manpages/upstart-events.7 will need to be tweaked in Debian to:

1) Remove the Job States and Job Lifecycle sections from upstart-events.7.
2) Remove reference to Table 6 in the Event Summary section.

I've already done this in Ubuntu as commit r1532:

http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/upstart/trusty/revision/1532

Kind regards,

James.
--
James Hunt

#upstart on freenode
http://upstart.ubuntu.com/cookbook
https://lists.ubuntu.com/mailman/listinfo/upstart-devel


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