Bug#703467: pu: package graphviz/2.26.3-5+b1

[Adam D. Barratt]

Control: tags -1 + pending

On Wed, 2013-03-20 at 20:00 +, Adam D. Barratt wrote:
> On Tue, 2013-03-19 at 23:46 +, David Claughton wrote:
> > Bug #702436 has recently been reported against graphviz, which advises
> > that graphviz is being linked with an ancient shipped version of libltdl
> > instead of the system version.  On investigation it has become clear
> > that the version being linked against is susceptible to a known security
> > issue - DSA-1958-1 (CVE-2009-3736).
> 
> Assuming that the resulting package has been tested on a stable system,
> please go ahead; thanks.

Uploaded and flagged for acceptance in to p-u; thanks.

Regards,

Adam


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

Bug#703458: pu: package clamav/0.97.7+dfsg-1~squeeze1

[Adam D. Barratt]

Control: tags -1 + pending

On Wed, 2013-03-20 at 16:41 -0400, Scott Kitterman wrote:
> "Adam D. Barratt"  wrote:
> >On Tue, 2013-03-19 at 17:38 -0400, Scott Kitterman wrote:
> >> I'd like to upload clamav 0.97.7 for all the same reasons (and with
> >the same
> >> diff modulo a slightly different debian/changelog entry) as I wanted
> >it in
> >> Wheezy (See #703391: unblock: clamav/0.97.7+dfsg-1).
> >
> >Please go ahead; thanks.
> >
> >I'm guessing you'd like to see this hit stable-updates as well (once
> >0.97.7 migrates to testing)?
> >
> Yes.  Thanks. 

Flagged for acceptance in to p-u.

Regards,

Adam


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

Bug#668779: /usr/bin/latex2man: latex2man: predictable /tmp filenames

[Norbert Preining]

Dear Release Managers, dear Jonathan,

On Mo, 18 Mär 2013, Jonathan Wiltshire wrote:
> through point releases:
> 
> squeeze (6.0.7) - use target "stable"
> 
> Please prepare a minimal-changes upload targetting each of these suites,
> and submit a debdiff to the Release Team [0] for consideration. They will
> offer additional guidance or instruct you to upload your package.

Attached is a debdiff for the version prepared. Please let me know
if this is fine and I will upload the files.

Thanks

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094   fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094

diff -u texlive-extra-2009/debian/changelog texlive-extra-2009/debian/changelog
--- texlive-extra-2009/debian/changelog
+++ texlive-extra-2009/debian/changelog
@@ -1,3 +1,10 @@
+texlive-extra (2009-10+squeeze1) stable; urgency=low
+
+  * fix predictable temp file names in latex2man (Closes: #668779)
+(patch by Tatsuya Kinoshita)
+
+ -- Norbert Preining   Thu, 21 Mar 2013 13:45:06 +0900
+
 texlive-extra (2009-10) unstable; urgency=low
 
   * add the forgotten epoch for musixtex dependency (Closes: #587746)
diff -u texlive-extra-2009/debian/patches/series 
texlive-extra-2009/debian/patches/series
--- texlive-extra-2009/debian/patches/series
+++ texlive-extra-2009/debian/patches/series
@@ -8,0 +9 @@
+latex2man-mktemp
only in patch2:
unchanged:
--- texlive-extra-2009.orig/debian/patches/latex2man-mktemp
+++ texlive-extra-2009/debian/patches/latex2man-mktemp
@@ -0,0 +1,27 @@
+Do no use predictable temp file names, but mktemp
+patch by Tatsuya Kinoshita
+Debian bug #668779
+---
+ texmf-dist/scripts/latex2man/latex2man |4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- texlive-extra-2009.orig/texmf-dist/scripts/latex2man/latex2man
 texlive-extra-2009/texmf-dist/scripts/latex2man/latex2man
+@@ -29,8 +29,6 @@
+ $VERSION = "1.23";
+ $DATE= date2str ('$Date: 2008/11/11 07:21:14 $' =~ m|(\d+/\d+/\d+)|);
+ 
+-$tmp = "/tmp/$CMD.$$";
+-
+ ##
+ # check option and arguments
+ ##
+@@ -122,6 +120,8 @@
+ $DestFile = $ARGV[1];
+ open (SRC,  "<$SrcFile")  || die "$CMD: Can't open file \`$SrcFile' for 
reading.\n";
+ if ($opt_H || $opt_T) {
++$tmp = `mktemp` || die;
++chomp $tmp;
+ # DestFile will be written in the postprocess
+ open (DEST, ">$tmp")  || die "$CMD: Can't open file \`$tmp' for 
writing.\n";
+ } else {

Bug#702843: claws-mail-bogofilter: Does not add X-Bogosity header when that option checked in preferences

[Daniel Dickinson]

On Tue, 12 Mar 2013 09:50:06 +0100
Ricardo Mones  wrote:

> tags 702843 moreinfo
> thanks
> 
> On Tue, Mar 12, 2013 at 12:27:36AM -0400, Daniel Dickinson wrote:
> > Package: claws-mail-bogofilter
> > Version: 3.8.1-2
> > Severity: normal
> > 
> > claws-mail-bogofilter plugin has an option labelled 'add X-Bogosity
> > header', however when receiving mail such a header is not added,
> > which means that one is not able to filter based on the header
> > (e.g. so one can have per-server on-server Spam folder instead of a
> > single spam folder for all spam on one server or MH folder).
> > 
> > This is a bug because the option offers an option to add a header,
> > but doesn't do it.
> 
>   Can you see message source (View/Message source) of one of the
> filtered messages and check if there's a header named
> "X-Claws-Bogosity:" ?
> 
>   Seems the label doesn't have the right header name... or the
> opposite ;)
> 
>   regards,

As you can see below, no X-*Bogosity is added.

Return-path: 
Envelope-to: deb...@cshore.neomailbox.net
Delivery-date: Tue, 12 Mar 2013 09:50:16 +0100
Received: from _exim by s1.neomailbox.net with procmailed (Exim 4.76)
(envelope-from )
id 1UFKuT-00053V-Rx
for deb...@cshore.neomailbox.net; Tue, 12 Mar 2013 09:50:13
+0100 procmail: Error while writing to
"/home/neomailbox/.procmailfw-log" Received: from [88.191.146.52]
(helo=mx.colino.net) by s1.neomailbox.net with esmtps
(TLSv1:AES256-SHA:256) (Exim 4.76)
(envelope-from )
id 1UFKuT-00014K-41
for deb...@cshore.neomailbox.net; Tue, 12 Mar 2013 09:50:13
+0100 Received: by mx.colino.net (Postfix, from userid 1017)
id 907DA8556D; Tue, 12 Mar 2013 09:50:12 +0100 (CET)
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on srv
X-Spam-Level: 
X-Spam-Status: No, score=-1.0 required=5.0
tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.3.1
Received: from trasgu (cm-85-152-246-230.telecable.es [85.152.246.230])
by mx.colino.net (Postfix) with ESMTPSA id A0EBB8539E;
Tue, 12 Mar 2013 09:50:10 +0100 (CET)
Received: by trasgu (sSMTP sendmail emulation); Tue, 12 Mar 2013
09:50:06 +0100 Date: Tue, 12 Mar 2013 09:50:06 +0100
From: Ricardo Mones 
To: Daniel Dickinson ,
702...@bugs.debian.org Subject: Re: Bug#702843: claws-mail-bogofilter:
Does not add X-Bogosity header when that option checked in preferences
Message-ID: <20130312085006.GC2919@trasgu>
References: <20130312042736.18291.16139.report...@pwyllwork.fionavar.dd>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="yNb1oOkm5a9FJOVX" Content-Disposition: inline
In-Reply-To:
<20130312042736.18291.16139.report...@pwyllwork.fionavar.dd>
X-Face: 
;%Ws3L$.3^vnZGdjc-N\sIaOI1)zEJW{~f!E|WLg0}[]]#'p=~f7uZT=?r!{yZ#g!4qH7(VA}AFiACRfNW5?[XLG3Bx#.BX9A|\yVgr]v:QIn*b,#vUS30QH!*1]:ah(_DioSgsy(K{(Vno,2ED
User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Score: 1.3
X-SA-Report: Spam detection software, running on the system
"switch.trancecrypt.com", has identified this incoming email as
possible spam.  The original message has been attached to this so you
can view it (if it isn't spam) or label similar future email.  If you
have any questions, see @@CONTACT_ADDRESS@@ for details.
 
 Content preview:  tags 702843 moreinfo thanks On Tue, Mar 12, 2013 at
12:27:36AM -0400, Daniel Dickinson wrote: > Package:
claws-mail-bogofilter > Version: 3.8.1-2 > Severity: normal > >
claws-mail-bogofilter plugin has an option labelled 'add X-Bogosity
header', > however when receiving mail such a header is not added,
which means that > one is not able to filter based on the header (e.g.
so one can have > per-server on-server Spam folder instead of a single
spam folder for all > spam on one server or MH folder). > > This is a
bug because the option offers an option to add a header, but > doesn't
do it. [...] 
 Content analysis details:   (1.3 points, 5.0 required)
 
  pts rule name  description
  --
-- 1.3
RDNS_NONE  Delivered to internal network by a host with no
rDNS


--yNb1oOkm5a9FJOVX
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

tags 702843 moreinfo
thanks

On Tue, Mar 12, 2013 at 12:27:36AM -0400, Daniel Dickinson wrote:
> Package: claws-mail-bogofilter
> Version: 3.8.1-2
> Severity: normal
>=20
> claws-mail-bogofilter plugin has an option labelled 'add X-Bogosity
> heade=
r',
> however when receiving mail such a header is not added, which means
> that one is not able to filter based on the header (e.g. so one can
> have=20 per-server on-server Spam folder instead of a single spam
> folder for all=
=20
> spam on one server or MH folder).
>=20
> This is a bug because the option offers an option to add a header,
> but=20 doesn't do it.

  Can you see message source (View/Message source) of one of the
  filtered messages an

Bug#703588: gtk-vnc: FTBFS on all autobuilders (/usr/bin/python2.6: not found)

[Ralf Treinen]

Source: gtk-vnc
Version: 0.5.2-1
Severity: serious

Hi, gtk-vnc fails to build on all autobuilders [1]. On i386, the build
log ends on


/usr/bin/pygobject-codegen-2.0: 11: exec: /usr/bin/python2.6: not found
make[4]: *** [vncmodule.defs.c] Error 127
make[4]: Leaving directory 
`/build/buildd-gtk-vnc_0.5.2-1-i386-dPW3x3/gtk-vnc-0.5.2/build/gtk2/src'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory 
`/build/buildd-gtk-vnc_0.5.2-1-i386-dPW3x3/gtk-vnc-0.5.2/build/gtk2'
make[2]: *** [all] Error 2
make[2]: Leaving directory 
`/build/buildd-gtk-vnc_0.5.2-1-i386-dPW3x3/gtk-vnc-0.5.2/build/gtk2'
dh_auto_build: make -j1 returned exit code 2
make[1]: *** [override_dh_auto_build] Error 2
make[1]: Leaving directory 
`/build/buildd-gtk-vnc_0.5.2-1-i386-dPW3x3/gtk-vnc-0.5.2'
make: *** [build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2


-Ralf.



[1] https://buildd.debian.org/status/package.php?p=gtk-vnc&suite=sid


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

Bug#703587: libnss3 update disables some (self signed) certs (with Icedove)

[Erik C.J. Laan]

Package: libnss3
Version: 2:3.14.3-1
Severity: important

Dear Maintainer,

   * What led up to the situation?
I upgraded libnss* from 2:3.13.6-2 (previously in wheezy) to 2:3.14.3-1 (new in 
wheezy).
Suddenly Icedove cannot connect to my IMAP-mail server anymore. That 
mail-server has
a self-signed certificate.
Thunderbird on other PCs (Win7) does not have the problem. 
Mail-clients on other devices do nave the problem.
So it seems related to wheezy specifically.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Restart Icedove. 
   * What was the outcome of this action?
   * What outcome did you expect instead?
Downgraded libnss* to 2:3.13.6-2 to verify that libnss is the culprit. This 
solves the issue.
Upgrading to 2:3.14.3-1 again makes the issue appear again.
I also read some bug-reports. One of them talked about cert8.db being the 
problem.
So I moved ~/.icedove//cert8.db to cert8.db.bak and stopped/started 
Icedove to 
re-created cert8.db. This does not solve the issue, so the issue is not related 
to cert8.db and
thus not to #670882 and/or Mozilla bug 634074 .

If you need any more information please specify.

 have added a dump of the certificate generated with
openssl s_client -connect imap.intranet:993 -showcerts
for you and attached it to this report.

To resolve this issue I have to downgrade to 2:3.13.6-2 and am thus stuck with 
a vulnerable
version. If using a different (non self-signed) certificate solves the issue, 
please specify.
The imap.intranet server certificate is going to expire in a few months anyway. 
I can generate
a certificate using a local PKI I've setup for OpenVPN after generating this 
certiticate in 2005.


-- System Information:
Debian Release: 7.0
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-686-pae (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 libnss3 depends on:
ii  libc6  2.13-38
ii  libnspr4   2:4.9.2-1
ii  libnspr4-0d2:4.9.2-1
ii  libsqlite3-0   3.7.13-1
ii  multiarch-support  2.13-38
ii  zlib1g 1:1.2.7.dfsg-13

libnss3 recommends no packages.

libnss3 suggests no packages.

-- no debconf information
CONNECTED(0003)
---
Certificate chain
 0 s:/C=NL/ST=Zuid-Holland/L=Den 
Haag/O=intranet/OU=sysadmin/CN=imap.intranet/emailAddress=none
   i:/C=NL/ST=Zuid-Holland/L=Den 
Haag/O=intranet/OU=sysadmin/CN=imap.intranet/emailAddress=none
-BEGIN CERTIFICATE-
MIIGjDCCBHSgAwIBAgIJAOXpf4Sm+5IaMA0GCSqGSIb3DQEBBAUAMIGKMQswCQYD
VQQGEwJOTDEVMBMGA1UECBMMWnVpZC1Ib2xsYW5kMREwDwYDVQQHEwhEZW4gSGFh
ZzERMA8GA1UEChMIaW50cmFuZXQxETAPBgNVBAsTCHN5c2FkbWluMRYwFAYDVQQD
Ew1pbWFwLmludHJhbmV0MRMwEQYJKoZIhvcNAQkBFgRub25lMB4XDTA1MDYyNzIw
NTA0MloXDTEzMDkxMzIwNTA0MlowgYoxCzAJBgNVBAYTAk5MMRUwEwYDVQQIEwxa
dWlkLUhvbGxhbmQxETAPBgNVBAcTCERlbiBIYWFnMREwDwYDVQQKEwhpbnRyYW5l
dDERMA8GA1UECxMIc3lzYWRtaW4xFjAUBgNVBAMTDWltYXAuaW50cmFuZXQxEzAR
BgkqhkiG9w0BCQEWBG5vbmUwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoIC
AQC6Kozv3DzzWc2qv1Q2wiXQSCVIX8LtU0OCk9GvunJ1wk4g0G5PWqHKiJwbtYyH
91QE2FaLJCKvHIyVMDlHkUBVReWlxk3ELvWG9nv/doNQ1lF7pK2gdbmHbkV0ogRj
eKq6kzPWb/ydqNk3JSb2fX3Z6Ll0P2vHExw0eYzAmPaPX1PTFtp7dvoYeRFo0SJV
ITwkcC5grEkKSUz9XJZBAH0JqWPzz1zoKBdFBZzqyNhguvQgndpr4ORUjaHsxBAH
ytSuQZuHec1nMtVbUvLimDPPyYKtdWvqmbK/1jL2XLDeiDpRT54a9rZ+xyc6EEbT
N05pTTTm+nEmUWUKFzif6qWCRDOASF715krFma2rUSsAwdViB6T3Z87qMCvMl6dS
uQWnO1O5jbmVjl0hBL7ZM+AQElyjTS0ZSerktRDEhZiElEDNl7TOu+DxJCcc0lGB
YlR74rmicQoUTdVU0LgDcJ6oHSSSCtU9HNfPZ+vVAiTZuJB36UVGAFiUU88SHyCm
UNjdAm4mtryWp/AhPJRiPDTCvZiPosVkt0PMXkvQF0geS9vwRib2RzNPd7lf9iO+
Fp/b1smtxl8CQmBNm9tpl3+ikR1B6tMbxo+dL3odiSGrdHmh9K6KFkc/gw1mH3ia
tCWnA37xQI5cufcwooysSwwhkED8OJNjQpabQyKhjQ+FOwIDAQABo4HyMIHvMB0G
A1UdDgQWBBSQGcZJ+5b5fXV4JytzEBFmFlyE3zCBvwYDVR0jBIG3MIG0gBSQGcZJ
+5b5fXV4JytzEBFmFlyE36GBkKSBjTCBijELMAkGA1UEBhMCTkwxFTATBgNVBAgT
DFp1aWQtSG9sbGFuZDERMA8GA1UEBxMIRGVuIEhhYWcxETAPBgNVBAoTCGludHJh
bmV0MREwDwYDVQQLEwhzeXNhZG1pbjEWMBQGA1UEAxMNaW1hcC5pbnRyYW5ldDET
MBEGCSqGSIb3DQEJARYEbm9uZYIJAOXpf4Sm+5IaMAwGA1UdEwQFMAMBAf8wDQYJ
KoZIhvcNAQEEBQADggIBAIylxgMcnZt9k8feCA1mqAJJeBPrnpNx2EhTvKRKj+im
r53IXFQxv0PjpcXq4Gq/qpRN8uRglBI9U1KGBHUbmBJsqw4cvctGBpFdJ5W5xEFL
ilSTTGFoynM8k2czcMZCOa2osY1eA5f4OOYzHF83GwDa9oXbLc4QaSTkLHnv4qWC
jstfmiISEmb+jsxWHW5k846JByw0JrU02Y9MKWtXDkIw+7NJ5c/pciooRM1GxEFE
2sE0MY6sQauKYw5auWRoX657nC8cHFzWeG5cGnIUpUJ72ggrafW9g0jE1GpHkwwK
OBbNw1hq09/WtsJFUU/NpRN874tvQvosfkBlYjAnaio/jNIvLplc6Y5fvW+D1WK9
jXyIi+B+AFntMK6A+s1sC/hxyU4CxTG7tok2qwlW1WpWdMZ8G8WvoZ58L6tvcx4Y
WWmLXXBhpbJs+s0z9I0Ux7wAsqnUXVMggayjxQF2+20IF5qwOqdOYMezbfAtVMnp
Igxwv6FJZH5cC+OhnW+z2w+022m9QIdD+/auh6nu64maSB2tZkwpBiDmVXvExVkv
8XSLSSSCbe7i1V5Za1kFfq+dT05EhCOqVrAJ77hI1OLYeyVV9W4wzgdS5RdXOegm
w77QUeBTHr56YZDf4OA1Y3ZIvS8FUnJiEQQaQVKC3ZBol/qfrXiOsrB3jtnEoi1t
-END CERTIFICATE-
---
Server certificate
subject=/C=NL/ST=Zuid-Holland/L=Den 
Haag/O=intranet/OU=sysadmi

Bug#703456: [Pkg-fonts-devel] Bug#703456: Please add Nafees Nastaleeq

[Christian PERRIER]

Quoting Gunnar Hjalmarsson (gunna...@ubuntu.com):

> I prepared a temporary (for Ubuntu 13.04) package with both fonts, and
> at the Ubuntu bug we are trying to figure out how to distinguish between
> those two. :(


After a closer look, I changed my mind : imho, we should switch from
one "fonts-nafees" package providing only one font, to a family of
fonts-nafees-* packages, eventually, with a virtual package providing
all fonts.

The reason for this is that each font in the "family" (indeed, "from
that foundry") has its own version numbering scheme, so we want to be
able to update one without updating the whole package.

Regarding Khaled's mention of enhancing some of the fonts, I'm fine
with that but, imho, it should be proposed upstream so that they can
include an update with Arabic glyphs in future releases.




signature.asc
Description: Digital signature

Bug#703485: [3.2->3.8.3 regression] Battery not detected on Dell Latitude E5530

[Jonathan Nieder]

# regression
severity 703485 important
quit

Hi Jean-Christophe,

Jean-Christophe Dubacq wrote:

> While trying to resolve stability issues with the testing linux image,
> I tried kernel 3.8 in experimental. I fully understand that this kernel
> may not be used in production. However, when booting with this kernel,
> the battery is not detected (and thus, laptop-detect thinks that it is
> a desktop computer, which it is not). Of course, no /proc/acpi/BAT0 is
> created, which makes system tools not work. I think the problem lies
> in the kernel because of this.
>
> The first significant difference that I see in the logs is:
> -ACPI Error: [DCK9] Namespace lookup failure, AE_ALREADY_EXISTS 
> (20121018/dswload2-330)

Please report this upstream at bugzilla.kernel.org, product ACPI,
component Power-Battery, and let us know the bug number so we can
track it.

Be sure to include:

 - steps to reproduce the problem, expected result, actual result, and
   how the difference indicates a bug (should be simple enough)

 - which kernel versions you have tested and what happened with each

 - full "dmesg" output from an affected and unaffected boot, as
   attachments

 - "acpidump" output, as an attachment

Hopefully the upstream developers may have ideas for further tracking
the problem down from that point.

Then if you'd like to track this down further before hearing back from
them, a good way can be to try versions halfway between the newest
known-good and oldest known-bad kernels from
, which can help narrow down
the search for the problematic patch.

Hope that helps,
Jonathan


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

Bug#680458: fixed before Wheezy release?

[Paul Muster]

Hello,


is there something one can do to get this fixed before Wheezy is released?

http://www.debian.org/Bugs/Developer.en.html#severities sounds to me
like increasing severity to "serious" should only be done by the package
maintainer or the release manager...


Thanks,

Paul


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

Bug#703146: #703146 release critical?

[Christian PERRIER]

Quoting Holger Levsen (hol...@layer-acht.org):
> Hi Christian,
> 
> On Mittwoch, 20. März 2013, Christian PERRIER wrote:
> > I have an upload ready that includes MIchael Vogt's patch and moves
> > gpg from Recommends to Depends.
> 
> does it include the -f option as needed for live-$something? (see this bugs 
> log)

if [ "$release_file_variant" = "IN" ]; then
rm -f $reldest
gpg --output "$reldest" --decrypt --keyring "$KEYRING" 
--ignore-time-conflict "$relsigdest"
fi

> > Please object if I shouldn't upload.
> > 
> > This upload allows pbuilder to build a build chroot, so it seems fine,
> > but, not being a wizard with debootstrap and archive stuff, I'd
> > appreciate someone to confirm that fixing this is OK and fixing it the
> > way it has been proposed in #703146 is OK too.
> 
> a debdiff to the version in wheezy would have been nice :)


Will do that.





signature.asc
Description: Digital signature

Bug#703506: GMA500: higher resolutions than 800x600 don't work

[Jonathan Nieder]

Hi again,

I left out the URL for Intel's bug reporting guidelines:

Jonathan Nieder wrote:
> Georg Sassen wrote:

>> While the native resolution (1280x720) worked fine until kernel
>> version 3.2.0.4-686-pae_3.2.35-2, I now only have 800x600 resolution
>> in X11 and the initial framebuffer now on my Nokia Booklet 3G since
>> the update.
>
> Thanks for reporting.  Can you reproduce this using
> xserver-xorg-video-modesetting and the 3.8.y kernel from experimental
> as well?
>
> If so, please file a report upstream at bugzilla.kernel.org, product
> Drivers, component Video(DRI - Intel) with the information described
> at [1] and let us know the bug number so we can track it.

[1] https://01.org/linuxgraphics/documentation/how-report-bugs-0

> If not, we can try to find what patch fixed it and apply the same to
> wheezy.  So either result is progress.

Thanks again, and sorry for the noise.


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

Bug#702685: mr: add a mr clean command

[Paul Wise]

On Wed, 2013-03-20 at 11:53 -0400, Joey Hess wrote:

> I have to say, I'm fairly frightened of git-clean. I think it might
> delete large parts of my home directory. 

Ah, you're doing vcs-home stuff. I'm not so I'm not worried about it.

Perhaps an addon would be the most appropriate place to put it?

> Maybe mr clean should omit the -f, so the user has to explicitly force
> foot-shooting.

Unfortunately there is a lot of variation in the clean commands of
various VCSes, so it would need to handle that. Some commands take extra
arguments for cleaning only subtrees etc. Maybe something like this:

clean = if [ $1 = -f ] ; then shift; $vcs_clean_act "$@"; else $vcs_clean_noact 
"$@"; fi
git_clean_noact = git clean -dx --dry-run "$@"
git_clean_act = git clean -dx --force "$@"

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Bug#688140: file-rc: File-rc doesn't restore rcX.d dirs at remove, breaks sysv-rc installation.

[Alexander Wirt]

On Wed, 20 Mar 2013, Roger Leigh wrote:

> On Wed, Mar 20, 2013 at 05:04:57PM +0100, Michael Stapelberg wrote:
> > at this point I cannot spend any more time on this bug report.
> 
> I've tested your patch, and it appears to work correctly in all
> the cases I've tried.  I've updated it slightly (attached) to
> log what's happening during transition to dependency-based boot,
> particularly if things go wrong, but it's otherwise functionally
> identical to your patch.  It also runs insserv in verbose mode
> so that any errors/warnings are not hidden (as for sysv-rc).
> 
> Alexander, is this approach OK with you?  If you're happy with
> what this is doing, can this go into wheezy?
its basically your feature, so if you think its working - I am happy with it. 

Alex


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

Bug#674110: modprobe: ../tools/kmod-modprobe.c:550

[Lucas De Marchi]

On Fri, Mar 15, 2013 at 12:34 AM, Lucas De Marchi
 wrote:
>
> On Mar 14, 2013 4:25 PM, "Alberto Milone" 
> wrote:
>>
>> On 14/03/13 23:34, Lucas De Marchi wrote:
>> > Do you realize you are quoting the man page of modutils?  It's not
>> > kmod or module-init-tools, which kmod replaced. It's the old modutils
>> > used with Linux 2.4.  kmod is a drop-in replacement to m-i-t, but we
>> > are not putting back the things from modutils if we don't have a
>> > reason to.
>>
>> It wasn't documented in m-i-t but it was supported. See line 167 of the
>> following file:
>>
>> https://github.com/vadmium/module-init-tools/blob/master/generate-modprobe.conf
>
> This script shows exactly the opposite... it was not supported in m-i-t and
> thus they were converted to install commands using /bin/true
>
>>
>> > Why do you want to get the initstate of an inexistent module? Why do
>> > you think null and off should be special?  And more important, you
>> > still didn't answer why the available options are not working for you
>> > - you said you cannot get the initstate - but that is a non-issue
>> > since  libkmod shouldn't even try to get the initstate.
>> >
>> > Please give some real example of what you are trying to do so we can
>> > figure out a solution.
>>
>> All I'm saying is that modprobe raises an error if it finds strings such
>> as the following in configuration files in /etc/modprobe.d/ :
>>
>> alias nouveau off
>
> And it's right to complain, it's not something valid in the
> configuration It never was, even in m-i-t.
>
>>
>> As in comment 15, this is particularly annoying when it causes
>> update-initramfs to fail:
>>
>> update-initramfs: Generating /boot/initrd.img-3.8.0-3-generic
>> modprobe: ../tools/modprobe.c:550: print_action: Assertion
>> `kmod_module_get_initstate(m) == KMOD_MODULE_BUILTIN' failed.
>> Aborted (core dumped)
>>
>> It seems that update-initramfs calls modprobe in the following way:
>>
>> modprobe --set-version=3.8.0-3-generic --ignore-install --quiet
>> --show-depends nouveau

Ok... I pushed an alternative fix to have the same behavior as for
modprobe (except the exit code). As I said "off" and "null" are note
special, and they weren't in module-init-tools neither. The thing we
were doing wrong is that in presence of an alias to anything that
doesn't exist we should exit silently instead of exploding.

I fixed and added a test case to the testsuite with this in the config
file:  "alias psmouse deaddood". It's working now, at least for me.

Let me know if you still have issues.

Lucas De Marchi


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

Bug#702790: FTBFS: local changes detected

[tony mancill]

On 03/20/2013 10:23 PM, Michael Gilbert wrote:
> I've done a more minimal repacking (which doesn't require refreshing
> patches) and I've uploaded an nmu.  It's in delayed/2 to give you time
> to review, but if you'd like more time, please let me know.  Please
> see attached patch.
> 
> Best wishes,
> Mike

Thank you Mike!  I'm happy that you performed the NMU with a minimal
changeset.  I will import the changes into the packaging repo.

Cheers,
tony



signature.asc
Description: OpenPGP digital signature

Bug#702790: FTBFS: local changes detected

[Michael Gilbert]

I've done a more minimal repacking (which doesn't require refreshing
patches) and I've uploaded an nmu.  It's in delayed/2 to give you time
to review, but if you'd like more time, please let me know.  Please
see attached patch.

Best wishes,
Mike


wrapper.patch
Description: Binary data

Bug#703586: Xen fails to boot Linux

[Mike]

Package: xen-hypervisor-4.1-amd64
Version: 4.1.4-2
Severity: important

I've installed wheezy Linux successfully (ref. bug 703469).  Installed 
xen-linux-system-amd64, with the diversion in 
http://wiki.debian.org/Xen#Prioritise_Booting_Xen_Over_Native followed 
by "grub-install".

Xen appears to boot (messages go by fast), then I get a blank screen, 
followed seconds later by a reboot.  No messages redolent of Linux.

/ is on dm-crypt, if that matters; a straight Linux boot finds it.

I notice in /boot/grub/grub.cfg, the menuentrys for Xen are missing the 
"load_video" and "insmod gzio" that straight Linux has, if that matters.


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

Bug#692877: libav-tools: avconv segfault when deprecated -deinterlace is used

[Reinhard Tartler]

tags 692877 upstream
stop

Hi Paul,

First of all, thank you for your time to report this bugreport and
sorry for the delay.


On Sat, Nov 10, 2012 at 9:30 AM, Paul Gevers  wrote:
> Package: libav-tools
> Version: 6:9~beta1-1
> Severity: normal

> I ran the deprecated -deinterlace option on my test video (attached). avconv 
> first
> warns about deprecation, and then segfaults. (See below).
>
> Paul
>
> paul@wollumbin ~ $ avconv -i test.avi -vcodec libxvid -deinterlace 
> /tmp/bla.aviavconv version 9_beta1-6:9~beta1-1, Copyright (c) 2000-2012 the 
> Libav developers
>   built on Oct 16 2012 20:18:50 with gcc 4.7 (Debian 4.7.2-4)
> Guessed Channel Layout for  Input Stream #0.1 : mono
> Input #0, avi, from '/home/paul/test.avi':
>   Metadata:
> encoder : Lavf53.20.0
>   Duration: 00:00:00.23, start: 0.00, bitrate: 9890 kb/s
> Stream #0.0: Video: mjpeg, yuvj422p, 640x480, 30 fps, 30 tbr, 30 tbn
> Metadata:
>   title   : FUJIFILM AVI STREAM 0100
> Stream #0.1: Audio: pcm_u8, 16000 Hz, mono, u8, 128 kb/s
> - -deinterlace is deprecated, use -filter:v yadif instead
> File '/tmp/bla.avi' already exists. Overwrite ? [y/N] y
> Output #0, avi, to '/tmp/bla.avi':
>   Metadata:
> ISFT: Lavf54.18.0
> Stream #0.0: Video: libxvid, yuv420p, 640x480, q=2-31, 200 kb/s, 30 tbn, 
> 30 tbc
> Metadata:
>   title   : FUJIFILM AVI STREAM 0100
> Stream #0.1: Audio: libmp3lame, 16000 Hz, mono, s16p
> Stream mapping:
>   Stream #0:0 -> #0:0 (mjpeg -> libxvid)
>   Stream #0:1 -> #0:1 (pcm_u8 -> libmp3lame)
> Press ctrl-c to stop encoding
> Segmentation fault
>
>

Could you please take your time to report this bug upstream
following the guidelines here:
http://libav.org/bugreports.html. It really makes more sense if you
contact upstream yourself as they will definitely have some follow-up
questions.

Please also share the upstream bugzilla number as a reply to this
email, so that we can track progress done upstream.

-- 
regards,
Reinhard


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

Bug#692609: ffmpeg: converting with avconv to mpeg4 makes jerking and short pauses of video

[Reinhard Tartler]

tags 692609 upstream
stop

Hi,

First of all, thank you for your time to report this bugreport.

On Wed, Nov 7, 2012 at 10:17 PM, rpnpif  wrote:
> Package: ffmpeg
> Version: 6:0.8.3-1~bpo60+1
> Severity: normal
>
> Converting videos with avconv/ffmpeg to mpeg4 makes jerking, short pauses
> periodically all about 5 sec.

Unfortunately, this description lacks a number of criticial pieces of
information that would be necessary to process this bug.

> Avidemux (not in Debian repositery) has not this issue.

This is unfortunately irrelevant.

> avconv -i video.x output.mp4
> x in wmv or mpg1 format.

So does it work for you for other formats?

In any case, please take your time to report this bug upstream
following the guidelines here:
http://libav.org/bugreports.html. It really makes more sense if you
contact upstream yourself as they will definitely have some follow-up
questions.

Please also share the upstream bugzilla number as a reply to this
email, so that we can track progress done upstream.

-- 
regards,
Reinhard


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

Bug#703456: [Pkg-fonts-devel] Bug#703456: Bug#703456: Please add Nafees Nastaleeq

[Khaled Hosny]

On Thu, Mar 21, 2013 at 04:04:19AM +0100, Gunnar Hjalmarsson wrote:
> Hi Christian!
> 
> On 2013-03-20 06:58, Christian PERRIER wrote:
> > We could indeed package *all* fonts from this resource:
> > 
> > http://www.crulp.org/software/localization.htm
> 
> Right now I'm not sure that would be desirable.
> 
> I prepared a temporary (for Ubuntu 13.04) package with both fonts, and
> at the Ubuntu bug we are trying to figure out how to distinguish between
> those two. :(

All Nafees fonts have the same preferred family name, Nafees, which is
wrong since they are different families.

As regard to Nafees Nastaleeq, I had a fork of it[1] mainly adding
Arabic support since it is an Urdu only font, but also fixing some bugs
in the original font. I mad no releases so far because I'm not very
happy with the quality of vowel mark positioning but had no time to work
on it yet (but it is not any worse than the original).

Regards,
Khaled

[1] https://github.com/khaledhosny/hussaini-nastaleeq


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

Bug#703402: PTS: link to the blends website for packages involved in blends

[Paul Wise]

On Thu, Mar 21, 2013 at 12:05 AM, Andreas Tille wrote:

> Well, machine readable file is one thing.  At first we need to define
> the SQL table layout.  Currently the philosophy in UDD is to have the
> tables not normalised but I think it makes sense to normalise to some
> extend into three tables because it simplifies things we intend to do:
>
>   CREATE TABLE blends_metadata (
...
>   CREATE TABLE blends_tasks (
...
>   CREATE TABLE blends_packages (
...

I'm not an expert in SQL, but those look good to me.

> From the table layout above it is a simple task to create YAML,JSON
> which I consider rather *your* choice - I even wonder if there is any
> need for an intermediate format.  Isn't PTS not created from UDD
> queries?

The PTS isn't created from UDD queries, but I think/guess/hope the
planned rewrite would be:

http://wiki.debian.org/SummerOfCode2013/Projects#PTS_rewrite_in_Django

So for now we need an intermediate data format. JSON or YAML is fine,
both of those are currently parsed by the PTS, munged, turned into XML
and then rendered using XSLT. I'd recommend a list of tasks with their
names and lists of packages.

> prevent).  So this approach is a bit hackish because there is a reason
> why tasks are binary package centric (== user oriented) and PTS is
> source centric (== developer oriented).  I guess this mix of target
> groups leads to the technical problem we are facing.

Agreed.

> IMHO this would be the better solution because it resolves the conflict
> above.

Ok, lets do that.

> OK, that's fine for me.  I will not question PTS development decisions.

Please do question PTS decisions when appropriate, the PTS should
serve the needs of the Debian packaging community and if it isn't
doing that, we should fix it.

> In any case I'd applause the intention to make Blends more visible.

There are more ways to do that, I can think of at least two, will
bring those up in a new thread.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Bug#703209: linux: Please Add multiplatform flavour to armhf

[Nobuhiro Iwamatsu]

Hi,

On Wed, Mar 20, 2013 at 12:17 AM, Paul Wise  wrote:
> On Tue, 2013-03-19 at 15:05 +, Ian Campbell wrote:
>
>> I think the question here is what the `uname -r` bit should be.
>> Specifically the $FLAVOUR in 3.x.y-z-$FLAVOUR.
>
> Woops, I missed that uname -r includes the flavour bit.
>
>> I think there is an argument for making the multiplatform case be the
>> default "no-flavour flavour" i.e. $FLAVOUR is armhf/arm64 etc. Or
>> maybe that's what you are suggesting having not realised that `uname
>> -r` currently includes the -$FLAVOUR suffix. Hrm, I think we may
>> actually be talking about the same thing ;-)
>
> Right, my suggestion is just to use the architecture for the flavour, as
> is done on the other architectures.
>

Thank you for your comment.

In ARM ((but may be used on other architectures as well) ) all architectures,
flavor with the name of the CPU do is that it is multiplatform?
For example,  armv7 flavor is multiplatform support in armhf.

I think this is a very simple rule.

Best regards,
  Nobuhiro

-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6


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

Bug#703209: linux: Please Add multiplatform flavour to armhf

[Nobuhiro Iwamatsu]

On Tue, Mar 19, 2013 at 5:34 PM, Ian Campbell  wrote:
> On Tue, 2013-03-19 at 08:44 +0100, Arnaud Patard wrote:
>> I already commented some days ago on debian-arm that currently
>> multiplatform support must wait. It is useless as usb support is
>> _broken_ on multiplatform. Hopefully, Linaro devs seem back to work
>> and looks like we may have a patch merged soon. Until then, doing more
>> is near to a waste of time.
>
> I don't think making a start on a MP flavour is a waste of time at all.
>
> We are talking about packages in trunk (currently == experimental)
> rather than Sid/Wheezy. There's no possibility of us releasing anything
> with 3.8 but in the meantime adding the multiplatform flavour allows us
> to start laying the packaging ground work, finding bugs in the MP stuff
> and generally kicking the tyres etc. It's also an obvious step in the
> right direction. As you say the known issues, like the USB think, will
> be fixed upstream sooner rather than later.
>
> Since we are currently not yet talking about removing existing flavours
> I'm not sure there are any downsides to just doing it.
>
>> And about the patch in this bug, it fails to be really
>> multiplatform. During my tests on 3.8, I could already enable platforms
>> like MVEBU, HIGHBANK, BCM, MXC and you can enable OMAP too with 2-3
>> backports. Once done, it needs to be tested on real platforms as it
>> would probably allow to detect some more bugs. 3.9 may be better.
>
> This patch is a start though and doesn't preclude adding those other
> platforms either straight away or when 3.9 comes around as we like.
> Having the flavour would also enable testing on real platforms so that
> isn't a reason to wait IMHO.

Thank you for following this up.
I want to explain to me what you wrote.

>
>> On the long term, we'll have also to consider if we should keep
>> omap/mx5/vexpress or not. If we remove them, we should make sure that
>> the transition will work nicely.
>
> Ack.

me too.

-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6


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

Bug#703585: [pyopengl] run-time warning: "No Numeric module present: No module named Numeric"

[Dmitry Smirnov]

Package: pyopengl
Version: 3.0.1-1
Severity: minor

I wonder if run-time warnings like the following can be avoided:

Unable to load registered array format handler numeric:
Traceback (most recent call last):
  File 
"/usr/lib/python2.7/dist-packages/OpenGL/arrays/formathandler.py", line 44, in 
loadPlugin
plugin_class = entrypoint.load()
  File "/usr/lib/python2.7/dist-packages/OpenGL/plugins.py", line 14, 
in load
return importByName( self.import_path )
  File "/usr/lib/python2.7/dist-packages/OpenGL/plugins.py", line 28, 
in importByName
module = __import__( ".".join(moduleName), {}, {}, moduleName)
  File "/usr/lib/python2.7/dist-packages/OpenGL/arrays/numeric.py", 
line 15, in 
raise ImportError( """No Numeric module present: %s"""%(err))
ImportError: No Numeric module present: No module named Numeric

Long time ago python-numeric was removed from Debian (#546570)
in favour of python-numpy so perhaps the above warning regarding
lack of "numeric" module in nothing but confusing.

It this a legacy compatibility issue? 

Thanks.

All the best,
 Dmitry Smirnov
 GPG key : 4096R/53968D1B


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

Bug#692609: avconv: converting videos to mpeg4 makes jerking and short pauses of video

[Bob Bib]

control: reassign -1 libav-tools 6:0.8.3-1~bpo60+1
control: retitle -1 avconv: converting videos to mpeg4 makes jerking and short 
pauses of video
control: tags -1 moreinfo

Hi rpnpif,

> Converting videos with avconv/ffmpeg

ffmpeg is deprecated in Libav project (which is upstream for Debian libav 
packages),
only avconv should be used when possible.

> Converting videos with avconv/ffmpeg to mpeg4 makes jerking, short pauses 
> periodically all about 5 sec.
> Avidemux (not in Debian repositery) has not this issue.
> 
> avconv -i video.x output.mp4
> x in wmv or mpg1 format.

Maybe, the default avconv encoding settings are non-optimal,
or smth. else is wrong with avconv...

Please update libav-tools to a newer version
(it seems you're already using squeeze-backports, and now it has 
6:0.8.5-1~bpo60+1 version).

If the problem still persists with a new avconv version, please post an output 
log.



Best wishes, Bob

Bug#703584: min-size causes squid3 to fail

[wintch]

Package: squid3
Version: 3.1.6-1.2+squeeze3
Severity: normal



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

Kernel: Linux 2.6.32-5-686 (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 squid3 depends on:
ii  adduser3.112+nmu2add and remove users and groups
ii  libc6  2.11.3-4  Embedded GNU C Library: Shared lib
ii  libcap21:2.19-3  support for getting/setting POSIX.
ii  libcomerr2 1.41.12-4stable1  common error description library
ii  libdb4.8   4.8.30-2  Berkeley v4.8 Database Libraries [
ii  libexpat1  2.0.1-7+squeeze1  XML parsing C library - runtime li
ii  libgcc11:4.4.5-8 GCC support library
ii  libgssapi-krb5-2   1.8.3+dfsg-4squeeze6  MIT Kerberos runtime libraries - k
ii  libk5crypto3   1.8.3+dfsg-4squeeze6  MIT Kerberos runtime libraries - C
ii  libkrb5-3  1.8.3+dfsg-4squeeze6  MIT Kerberos runtime libraries
ii  libldap-2.4-2  2.4.23-7.3OpenLDAP libraries
ii  libltdl7   2.2.6b-2  A system independent dlopen wrappe
ii  libpam0g   1.1.1-6.1+squeeze1Pluggable Authentication Modules l
ii  libsasl2-2 2.1.23.dfsg1-7Cyrus SASL - authentication abstra
ii  libstdc++6 4.4.5-8   The GNU Standard C++ Library v3
ii  libxml22.7.8.dfsg-2+squeeze6 GNOME XML library
ii  logrotate  3.7.8-6   Log rotation utility
ii  lsb-base   3.2-23.2squeeze1  Linux Standard Base 3.2 init scrip
ii  netbase4.45  Basic TCP/IP networking system
ii  squid3-common  3.1.6-1.2+squeeze3A full featured Web Proxy cache (H

squid3 recommends no packages.

Versions of packages squid3 suggests:
pn  resolvconf (no description available)
pn  smbclient  (no description available)
pn  squid-cgi  (no description available)
ii  squidclient   3.1.6-1.2+squeeze3 A full featured Web Proxy cache (H

-- Configuration Files:
/etc/logrotate.d/squid3 changed:
/var/log/squid3/*.log {
daily
compress
delaycompress
rotate 31
missingok
nocreate
sharedscripts
postrotate
test ! -e /var/run/squid3.pid || /usr/sbin/squid3 -k rotate
endscript
}

/etc/squid3/squid.conf changed:
acl manager proto cache_object
acl localhost src 127.0.0.1/32
acl to_localhost dst 127.0.0.0/8
acl intranet src 192.168.2.0/24
acl SSL_ports port 443
acl Safe_ports port 80  # http
acl Safe_ports port 21  # ftp
acl Safe_ports port 443 # https
acl Safe_ports port 70  # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535  # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl CONNECT method CONNECT
acl no_cache_domain1 dstdomain .marqs.com.ar
acl no_cache_domain2 dstdomain .barinoticias.com.ar
cache deny no_cache_domain1
cache deny no_cache_domain2
http_access allow manager localhost
http_access allow manager intranet
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access deny to_localhost
http_access allow localhost
http_access allow intranet
http_access deny all
icp_access deny all
htcp_access deny all
http_port 192.168.2.1:3128 transparent
hierarchy_stoplist cgi-bin ?
cache_mem 256 MB
memory_replacement_policy heap GDSF
maximum_object_size_in_memory 256 KB
cache_replacement_policy heap GDSF
maximum_object_size 4 MB
cache_dir aufs /reiserdir/squid_cache1_1 1024 16 256 max-size=1048576
store_dir_select_algorithm round-robin
max_open_disk_fds 0
cache_swap_low 85
cache_swap_high 95
digest_generation off
half_closed_clients off
memory_pools off
logformat rustik %>a %Ss/%03

Bug#703583: commit-patch: Emacs interface can't find its sources

[Dima Kogan]

Package: commit-patch
Version: 2.4-1
Severity: normal

When emacs brings up the help for any of the commit-patch functions (for
instance with 'C-h f commit-patch-buffer'), the current package does not provide
a link to the function sources. This happens because the .el and the .elc live
in different directories in this package.

This can be fixed by using the dh_make default versions of
debian/emacsen-install and debian/emacsen-remove, since those versions make .el
symlinks in the .elc directory.

So this can be fixed with something like

$ perl 's/#PACKAGE#/commit-patch/g' 
/usr/share/debhelper/dh_make/emacs/emacsen-install.ex > 
commit-patch/debian/emacsen-install
$ perl 's/#PACKAGE#/commit-patch/g' 
/usr/share/debhelper/dh_make/emacs/emacsen-remove.ex > 
commit-patch/debian/emacsen-remove

Ideally we'd have a dh_emacsen to consolidate the boilerplate, but we don't yet.


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

Bug#703479: [Packaging] Bug#703479: munin: Huge munin-graph log with cron graph_strategy

[Christian Kujau]

FYI, I've updated the upstream package with some more information, as 
munin-graph still logs quite a lot, even with the commit applied :-\


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

Bug#703456: [Pkg-fonts-devel] Bug#703456: Please add Nafees Nastaleeq

[Gunnar Hjalmarsson]

Hi Christian!

On 2013-03-20 06:58, Christian PERRIER wrote:
> We could indeed package *all* fonts from this resource:
> 
> http://www.crulp.org/software/localization.htm

Right now I'm not sure that would be desirable.

I prepared a temporary (for Ubuntu 13.04) package with both fonts, and
at the Ubuntu bug we are trying to figure out how to distinguish between
those two. :(

Possibly this is an easy one for somebody who - unlike me - knows these
things. A helping hand from you at https://launchpad.net/bugs/1153188
would be much appreciated.

> And, ifyou're in touch with people interested in Urdu localization,
> this language is one of the major ones that we're missing in Debian
> Installerhint, hint.

Will mention it once this font issue has been resolved.

-- 
Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj


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

Bug#703582: rhn-client-tools: rhnreg_ks fails to register with spacewalk

[root]

Package: rhn-client-tools
Version: 1.8.9-3
Severity: important

Dear Maintainer,

The installTime function in debUtils.py doesn't work for packages that have the 
arch
appended to the filename in /var/lib/dpkg/info
e.g. e2fslibs:amd64.list

There seem to be a quite a lot of files named like this in wheezy.
installTime returns None for the above which in turn can't be marshaled by 
xmlrpclib
and registration fails with:

[Thu Mar 21 14:15:53 2013] up2date D: rpcServer: Calling XMLRPC 
registration.new_system
[Thu Mar 21 14:15:53 2013] up2date D: rpcServer: Calling XMLRPC 
registration.welcome_message
[Thu Mar 21 14:15:53 2013] up2date D: rpcServer: Calling XMLRPC 
registration.add_hw_profile
[Thu Mar 21 14:15:53 2013] up2date D: rpcServer: Calling XMLRPC 
registration.welcome_message
[Thu Mar 21 14:15:53 2013] up2date D: rpcServer: Calling XMLRPC 
registration.add_packages
[Thu Mar 21 14:15:53 2013] up2date
Traceback (most recent call last):
  File "/usr/sbin/rhnreg_ks", line 218, in 
cli.run()
  File "/usr/share/rhn/up2date_client/rhncli.py", line 96, in run
sys.exit(self.main() or 0)
  File "/usr/sbin/rhnreg_ks", line 151, in main
rhnreg.sendPackages(systemId, packageList)
  File "/usr/share/rhn/up2date_client/rhnreg.py", line 487, in sendPackages
s.registration.add_packages(systemId, packageList)
  File "/usr/share/rhn/up2date_client/rhnserver.py", line 63, in __call__
return rpcServer.doCall(method, *args, **kwargs)
  File "/usr/share/rhn/up2date_client/rpcServer.py", line 196, in doCall
ret = method(*args, **kwargs)
  File "/usr/lib/python2.7/xmlrpclib.py", line 1224, in __call__
return self.__send(self.__name, args)
  File "/usr/share/rhn/up2date_client/rpcServer.py", line 37, in _request1
ret = self._request(methodname, params)
  File "/usr/lib/python2.7/dist-packages/rhn/rpclib.py", line 377, in _request
request = self._req_body(self._strip_characters(params), methodname)
  File "/usr/lib/python2.7/dist-packages/rhn/rpclib.py", line 232, in _req_body
return xmlrpclib.dumps(params, methodname, encoding=self._encoding)
  File "/usr/lib/python2.7/xmlrpclib.py", line 1085, in dumps
data = m.dumps(params)
  File "/usr/lib/python2.7/xmlrpclib.py", line 632, in dumps
dump(v, write)
  File "/usr/lib/python2.7/xmlrpclib.py", line 654, in __dump
f(self, value, write)
  File "/usr/lib/python2.7/xmlrpclib.py", line 714, in dump_array
dump(v, write)
  File "/usr/lib/python2.7/xmlrpclib.py", line 654, in __dump
f(self, value, write)
  File "/usr/lib/python2.7/xmlrpclib.py", line 735, in dump_struct
dump(v, write)
  File "/usr/lib/python2.7/xmlrpclib.py", line 654, in __dump
f(self, value, write)
  File "/usr/lib/python2.7/xmlrpclib.py", line 658, in dump_nil
raise TypeError, "cannot marshal None unless allow_none is enabled"
: cannot marshal None unless allow_none is enabled



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

Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core)
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 rhn-client-tools depends on:
ii  debconf   1.5.49
ii  gnupg 1.4.12-7
ii  lsb-release   4.1+Debian8
ii  python2.7.3-4
ii  python-apt0.8.8.2
ii  python-dbus   1.1.1-1
ii  python-dmidecode  3.10.13-1.1
ii  python-ethtool0.7-1.1
ii  python-gudev  147.2-3
ii  python-newt   0.52.14-11.1
ii  python-openssl0.13-2
ii  python-rhn2.5.52-1

Versions of packages rhn-client-tools recommends:
pn  apt-spacewalk  

Versions of packages rhn-client-tools suggests:
pn  python-glade2  
pn  python-gnome2  
pn  python-gtk2

-- Configuration Files:
/etc/sysconfig/rhn/up2date changed [not included]

-- 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#703565: Dualing BTS's!

[Filipus Klutiero]

On 2013-03-20 19:09, Bob Proulx wrote:

Hi Filipus,

Filipus Klutiero wrote:

forwarded 703565 http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14012

Does that work?


Yes, see http://www.debian.org/Bugs/server-control#forwarded

  I thought that needed to be an email address there
not a URL.


It might have been that way, but a really long time ago. Both are 
supported currently.

tags 703565 + upstream
thanks

Oops... reporting to 2 ITS-s at the same time is a nice feature, but
I didn't mean to try it with this case.
Anyway, as it's already done, this is also #14012 upstream.

Yes.  I probably would have simply reported it directly upstream and
hashed it out there first.  Unless you think Debian should deviate
from upstream on this?


I apologize for the noise here. I used reportbug-ng to avoid making an 
error in the pseudo-headers formatting, but instead of changing the 
recipient for GNU, I added one keeping Debian. So my little trick is 
uncovered!


I never intended to report this to Debian, and suggest that discussion 
is kept on GNU's ITS, unless the discussion gets Debian-specific.


If the only problem with the addition was the increased size of 
coreutils, I think that shouldn't be a reason to prevent the addition 
for my PC (modern laptop). But Debian also targets somewhat embedded 
devices. And it's far from the only distribution designed for modern 
PCs. So I consider this issue as very little Debian-specific.






[...]


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

Bug#692193: ffmpeg: description claims that ffmpeg is a transitional package, but it isn't

[Bob Bib]

And what about making /usr/bin/ffmpeg a symlink to /usr/bin/avconv in future 
package versions?


Best wishes, Bob

Bug#703581: unblock: e2fsprogs/1.42.5-1.1

[Dmitrijs Ledkovs]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Please unblock package e2fsprogs

Closes #698879

This is also a request for udeb-unblock from the installer team.

unblock e2fsprogs/1.42.5-1.1

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

Kernel: Linux 3.8.0-13-generic (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

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

iQIcBAEBCAAGBQJRSm0SAAoJEIh7YGGLPBauB6MP/iTl4ulKrqAnn9Xr2TPtudd/
Rt12pCLUcJ3KReyE/DHjIKAeiq41IYcr2nZ7087eRuT+EFZGtTWYxHv4U3CX89bT
zNWdX2UqUMKQR6xwc/3+BXKbTJOswcjQxnF0qb/8TJbQkhREub5ts7G2dx2SDqWZ
x2ke/DOO6lbslO6G/N1+RUYY7fHgpwpQCm0RZF8t17b1xTVVUhhs/awwt1wzoaKi
oDAdtU4TidO3FdlYQxBAqAqqT+Jcoj2jzxTmEV4tDeRptowd42PIKmKAyXk3ippA
2o3FgVQNVZ81sMQEN1MDpxhi302YSfyym0x8rS/DTqayIuT1PoQfJ5MzvVI0nukJ
x3UGbJhIQokJVMoeFH7sEzftqTJIrAPlVNv7t9OGycYYNlCp1Gn6FO7tmYknWDye
1z91djudgLYcnUHpSU9hh1T8zBTQgavq9E4/oPs4LQlTr64+wamgQLpCVd27LSm3
B4KqylEEHzKB+3KuPcbz9SxfCAGyKnHN0KQKN+R9AgMThdDrv6E7drz8Yy0qMwdB
JBpHhXhzAXYwr05LZs6mgmmwjSysIJyFhG2MMs3mCqEo8zsCbwp50uviAKnx4e8F
+MOPOZi4AwMN0VGTcYZ4X6svuZt60ugcxozDY7gJ1zOGdpxd3mq5OtVpx6MLE/xy
IDNQ6WycVIMro+mgBMTe
=DClc
-END PGP SIGNATURE-
diff -Nru e2fsprogs-1.42.5/debian/changelog e2fsprogs-1.42.5/debian/changelog
--- e2fsprogs-1.42.5/debian/changelog	2012-07-30 01:01:45.0 +0100
+++ e2fsprogs-1.42.5/debian/changelog	2013-03-21 00:07:18.0 +
@@ -1,3 +1,12 @@
+e2fsprogs (1.42.5-1.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * e2fsck-static, e2fsprogs: let preinst remove a symbolic link in
+/usr/share/doc, that should have been replaced with a directory since
+1.39+1.40-WIP-2006.10.02+dfsg-1. (Closes: #698879).
+
+ -- Nicolas Boulenguez   Fri, 22 Feb 2013 23:14:59 +0100
+
 e2fsprogs (1.42.5-1) unstable; urgency=low
 
   * New upstream version
diff -Nru e2fsprogs-1.42.5/debian/e2fsck-static.preinst e2fsprogs-1.42.5/debian/e2fsck-static.preinst
--- e2fsprogs-1.42.5/debian/e2fsck-static.preinst	1970-01-01 01:00:00.0 +0100
+++ e2fsprogs-1.42.5/debian/e2fsck-static.preinst	2013-03-21 00:07:18.0 +
@@ -0,0 +1,19 @@
+#!/bin/sh
+
+# Abort on error.
+set -e
+
+PKG=e2fsck-static
+DOCLNK=/usr/share/doc/$PKG
+if test "$1" = upgrade \
+-a -L $DOCLNK
+then
+rm $DOCLNK
+fi
+
+# dh_installdeb will replace this with shell code automatically
+# generated by other debhelper scripts.
+
+#DEBHELPER#
+
+exit 0
diff -Nru e2fsprogs-1.42.5/debian/e2fsprogs.preinst e2fsprogs-1.42.5/debian/e2fsprogs.preinst
--- e2fsprogs-1.42.5/debian/e2fsprogs.preinst	1970-01-01 01:00:00.0 +0100
+++ e2fsprogs-1.42.5/debian/e2fsprogs.preinst	2013-03-21 00:07:18.0 +
@@ -0,0 +1,19 @@
+#!/bin/sh
+
+# Abort on error.
+set -e
+
+PKG=e2fsprogs
+DOCLNK=/usr/share/doc/$PKG
+if test "$1" = upgrade \
+-a -L $DOCLNK
+then
+rm $DOCLNK
+fi
+
+# dh_installdeb will replace this with shell code automatically
+# generated by other debhelper scripts.
+
+#DEBHELPER#
+
+exit 0

Bug#697594: any update on having the new version of youtube-dl 2013.02.25 at least in experimental

[Rogério Brito]

Hi, Shirish.

On Wed, Mar 20, 2013 at 10:08 PM, shirish शिरीष  wrote:
> Hi all,
> @Rogério Brito  I know that Debian is in freeze so you can't target it
> either in testing or unstable/sid but you could maybe up an release to
> experimental.

Well, I am quite ready to upload newer versions of my packages, but
there's an issue:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699043#10

I guess that I will have to ask someone else for sponsoring my
packages/giving me privileges.


Thanks,

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://rb.doesntexist.org/blog : Projects : https://github.com/rbrito/
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br


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

Bug#703580: Metapackage doesn't depend on similar version mongodb-server & mongodb-client

[Mark D. Blackwell]

Package: mongodb
Version: 1:2.0.0-2~bpo60+1
Severity: important

The backports metapackage doesn't depend on mongodb-server & mongodb-client 
packages with the same version.

It's a fair assumption that a metapackage for a database will pull in all its 
components of the same version. If someone were to desire otherwise, they could 
force apt-get to do so.

As a result, as a mongodb newby, I puzzled for some days over a few, 
mysteriously strange behaviors, until I learned how to query the database for 
its version:

$ mongo
> db.serverStatus().version

Only then did I notice the results from:

$ dpkg-query -l 'mongodb*'


Steps to reproduce:

$ sudo apt-get install mongodb-server mongodb-dev

or maybe just:

$ sudo apt-get install mongodb-server

and then:

$ sudo apt-get -t squeeze-backports install mongodb



-- System Information:

Debian Release: 6.0.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-686 (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 mongodb depends on:
ii  mongodb-dev   1:1.4.4-3  An object/document-oriented databa
ii  mongodb-server1:1.4.4-3  An object/document-oriented databa

mongodb recommends no packages.

mongodb 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#703265: lletters: crashes on most buttons on non-OSS3 systems

[Michael Gilbert]

control: tag -1 patch

Hi, I don't think its worth spending too much time on this issue since
its a small game, so I've applied the simplest solution (the
oss-compat dependency, even though it requires a reboot).  I've
uploaded an nmu to delayed/5 to give enough time for others to put
together a better fix if they want.

Best wishes,
Mike


lletters.patch
Description: Binary data

Bug#702428: [Pkg-xen-devel] Bug#702428: HVM networking tap/vif bug (Debian bug 702428)

[Ian Campbell]

On Wed, 2013-03-20 at 23:32 +0100, Daniel Pocock wrote:
> 
> Should the script be using the ovs-vsctl command instead of brctl?

As a general rule one should be using the ovs tools directly wherever
possible and not the brctl compat layer.

>  Or
> have I misconfigured something and the wrong script is being run? 

This is something which AFAIR differs between upstream Xen and XCP. With
upstream Xen we disable the qemu script explicitly and expect the xen
vif hotplug scripts (which handle Xen tap devices too) to do the job,
that is the scripts under /etc/xen/scripts/vif-foo (for foo in bridge,
openvswitch etc)

Ian


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

Bug#703579: ITP: PCL (Point Cloud Library) -- Framework for 3D point clouds data processing

[Paride Legovini]

Package: wnpp
Severity: wishlist
Owner: Paride Legovini 

* Package name: PCL (Point Cloud Library)
  Version : 1.6
  Upstream Author : Open Perception, Inc. (http://www.openperception.org/)
* URL : http://www.pointclouds.org/
* License : BSD-3-clause
  Programming Lang: C++
  Description : Framework for 3D point clouds data processing

PCL (Point Cloud Library) is a standalone open-source framework including
numerous state-of-the art algorithms for n-dimensional point clouds and
3D geometry processing. The library contains algorithms for filtering,
feature estimation, surface reconstruction, registration, model fitting,
and segmentation. PCL is developed by a large consortium of researchers
and engineers around the world. It is written in C++ and released under
the BSD license.


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

Bug#697594: any update on having the new version of youtube-dl 2013.02.25 at least in experimental

[shirish शिरीष]

Hi all,
@Rogério Brito  I know that Debian is in freeze so you can't target it
either in testing or unstable/sid but you could maybe up an release to
experimental.

Looking forward to some positive development on this.
-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
065C 6D79 A68C E7EA 52B3  8D70 950D 53FB 729A 8B17


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

Bug#703141: scratch: fails to install if gnome-session-common is installed but hicolor-icon-theme is no

[Michael Gilbert]

On Wed, Mar 20, 2013 at 6:22 PM, Jonathan Wiltshire  wrote:
> Your patch doesn't seem to address the underlying issue, which is the
> problematic postinst/postrm scripts. Does scratch /actually/ depend on
> hicolor-icon-theme, or is this just to solve the call to
> gtk-update-icon-cache (which if I've understood correctly, should actually
> be handled by a trigger)?

On the contrary, it solves the rc breakage in the simplest way
possible.  Fixing up those problematic scripts would certainly be
nice, but I'm not going to waste my own time to do the maintainer's
job.   I'm interested in is fixing rc stuff, not making things
perfect.

> I think you should reconsider this upload.

Canceled, but I don't really see the logic of preferring a
non-existent perfect solution to a dead simple one that works now.

Best wishes,
Mike


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

Bug#703578: lockdev: Memory leak

[Roger Leigh]

Package: lockdev
Version: 1.0.3-1
Severity: important

Forwarding to BTS.

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
--- Begin Message ---

Hello,

I just filled an ubuntu bug for that.

Please discard my email if this is the regular process, meaning
that the bug report will come to you anyway.  I have doubts
since some ubuntu bugs are still opened but closed in debian's
changelog.

Otherwise, here is the attached patch that seems to fix the
memory leak detected by valgrind.  Package files are (from dsc):
lockdev_1.0.3.orig.tar.gz
lockdev_1.0.3-1.4build2.diff.gz

with regards,

david gauchard


lockdev-1.0.3-fix-memory-leak.diff.gz
Description: Binary data
--- End Message ---

Bug#703577: screen goes black when starting mcedit from command line

[Dmitry Borisyuk]

Package: mc
Version: 3:4.7.0.9-1
Severity: minor

Hi,

if I start mcedit from command line, and mc is already running,
the screen becomes black and no text is visible.
I can see only top and bottom lines (status and hints).
Then, if I press any arrow key, the text become visible and everything is OK.

To reproduce:

$ mc
$ mcedit ~/.mc/ini


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

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

Versions of packages mc depends on:
ii  e2fslibs1.41.12-4stable1 ext2/ext3/ext4 file system librari
ii  libc6   2.11.3-4 Embedded GNU C Library: Shared lib
ii  libcomerr2  1.41.12-4stable1 common error description library
ii  libglib2.0-02.24.2-1 The GLib library of C routines
ii  libgpm2 1.20.4-3.3   General Purpose Mouse - shared lib
ii  libslang2   2.2.2-4  The S-Lang programming library - r

Versions of packages mc recommends:
ii  mime-support  3.48-1 MIME files 'mime.types' & 'mailcap

Versions of packages mc suggests:
pn  arj(no description available)
ii  bzip2  1.0.5-6+squeeze1  high-quality block-sorting file co
pn  catdvi (no description available)
pn  dbview (no description available)
pn  djvulibre-bin  (no description available)
ii  evince [pdf-viewer]2.30.3-2+squeeze1 Document (PostScript, PDF) viewer
ii  file   5.04-5+squeeze2   Determines file type using "magic"
ii  gv [pdf-viewer]1:3.7.1-1 PostScript and PDF viewer for X
pn  imagemagick(no description available)
pn  odt2txt(no description available)
ii  perl   5.10.1-17squeeze5 Larry Wall's Practical Extraction 
ii  python 2.6.6-3+squeeze7  interactive high-level object-orie
pn  python-boto(no description available)
pn  python-tz  (no description available)
ii  unzip  6.0-4 De-archiver for .zip files
ii  w3m0.5.2-9   WWW browsable pager with excellent
ii  zip3.0-3 Archiver for .zip files

-- 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#699827: ebtables: --xxxx-target RETURN is not accepted in non-base chains

[William Dauchy]

Package: ebtables
Followup-For: Bug #699827

I guess this bug report is more suitable for upstream.
Have you considered sending an email to the netfilter developer
mailinglist? see http://netfilter.org/mailinglists.html
This will help having feedbacks from the core team.

Regards,

-- 
William


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

Bug#703574: efivars can turn some Samsung systems into bricks

[Ben Hutchings]

Package: src:linux
Version: 3.2.39-2
Severity: critical
Tags: upstream fixed-upstream patch

EFI can store named variables in persistant storage (i.e. flash),
which is compacted at boot.  On some Samsung systems (and maybe
others), compaction fails and the system will not boot if the
variable space is more than 50% full.

The workaround for this is:

commit 7feecf3f2b587e535550bb3e7bf75b2fee06fccf
Author: Josh Boyer 
Date:   Mon Mar 11 17:48:53 2013 -0400

efi: be more paranoid about available space when creating variables

which I backported into 3.2.41.

Ben.

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

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.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#703563: tshark: uses wrong default output format, and cannot change output format

[Bálint Réczey]

Hi Lucas,

2013/3/20 Lucas Nussbaum :
> Package: tshark
> Version: 1.8.2-5wheezy1
> Severity: important
>
> Hi,
>
> tshark's man page says:
>When writing packets to a file, TShark, by default, writes the file
>in libpcap format [..]
> and also says:
>-F  
>Set the file format of the output capture file written using the
>-w option.  The output written with the -w option is raw packet
>data, not text, so there is no -F option to request text output.
>The option -F without a value will list the available formats.
Please note that it also says:
...
   When writing packets to a file, TShark, by default, writes the
file in libpcap
   format, and writes all of the packets it sees to the output file.  The -F
   option can be used to specify the format in which to write the
file.  This list
   of available file formats is displayed by the -F flag without a value.
   However, you can't specify a file format for a live capture.


>
>
> However:
> 1) tshark uses the pcap-ng format, not the libpcap format.
> 2) the -F switch does not work.
>
> The problem can be produced with:
>
> $ sudo tshark -i lo -w - > f ; file f
> [..]
> f: pcap-ng capture file - version 1.0
>
> $ sudo tshark -F libpcap -i lo -w - > f ; file f
> [..]
> f: pcap-ng capture file - version 1.0
>
> In both cases, I would expect tshark to use the libpcap format, like
> tcpdump:
> $ sudo tcpdump -i lo -w - > f ; file f
> [..]
> f: tcpdump capture file (little-endian) - version 2.4 (Ethernet, capture 
> length 65535)
Please use dumpcap -P instead. From man dumpcap:

   -P  Save files as pcap instead of the default pcap-ng. In situations that
   require pcap-ng, such as capturing from multiple
interfaces, this option
   will be overridden.


>
>
> The version in experimental (1.9.1-1) is also affected.
> The version in squeeze is not affected.
>
>
> This breaks the "use tshark or dumpcap as a remote probe over SSH" use
> case described in http://wiki.wireshark.org/CaptureSetup/Pipes :
> $ wireshark -k -i <( ssh root@host tshark -i eth0 -w -)
Please use dumpcap -P instead in this scenario, it is expected to work.

Cheers,
Balint


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

Bug#703573: unblock: roundcube/0.7.2-7

[Dmitrijs Ledkovs]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Please unblock package roundcube

Closes: #680917, #656886, #688634, #699604.
The #688634 is the most important to close here.

unblock roundcube/0.7.2-7

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

Kernel: Linux 3.8.0-13-generic (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

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

iQIcBAEBCAAGBQJRSk7lAAoJEIh7YGGLPBauMFwP/AvwrVRXkhuiMTX9g2TVsooo
ZMWjI+mipShUzpoFndukegwojCa4tFktQ9/NI/gZJZEN5TEmya8uUrzs9IiUrtrh
jFhgPBZYcudtHzcbVGE6q7DnYG/+iHPbvretOZ+V6s/lLXLMYFtPHN1a/mj1p177
iaNtLCgPFugYdXiLwzcvpptJv2O+4lF20ADE+ElVmn9bpmC3JXDuUF+Lrkfvc1Cs
bZhinbbUW9Y9bJkeKzB+2OWGCFEmIj7Sb3lFKczdlouQfCzh0ZOuCyXSsPee9K/s
vGjKQ+ILnu44CX10GNg7Goe7TW+UyxgSEkogCcsRpzTInIpza9OCjOgQjgxYBpfw
VEdEQRn5qSNCDfeC5IrTtlW7n8kOHHvyf+a5W/Ygl5p0g49rIEFnWzBwXy8anksL
Jr0VxnD0nMIqELIZRIIIhivBRSwAcgJi2dvwcBnmqVrgEewoUZBpe4nNWSsCxecL
PH4w3OzpKeT0N550PHm4OeZQoEtURiTpHSlmxqYmFpWjSd/1Fg8VMBx0A37ldQid
DHYf7VqUWBlIZHAeUQrIo0nUXmFb9YBS8IrrhORpFLde6JMIdz5exvNkypm4tY07
RHCJ1OtWabRW5LiquGu0EiGKQW8c1a/Sn31VZ7NsQsL6dp1OMQE0//9fGSQ0WBQR
HOJJcqsSnHT1xebD+2qn
=EZXZ
-END PGP SIGNATURE-
diff -Nru roundcube-0.7.2/debian/changelog roundcube-0.7.2/debian/changelog
--- roundcube-0.7.2/debian/changelog	2012-09-29 10:39:58.0 +0100
+++ roundcube-0.7.2/debian/changelog	2013-03-16 16:26:29.0 +
@@ -1,3 +1,20 @@
+roundcube (0.7.2-7) unstable; urgency=low
+
+  * Fix dependencies to postgresql and postgresql-client. Closes: #699604.
+  * Drop roundcube-sqlite transition package since we don't provide an
+automatic upgrade path. The user will have to remove the package by
+herself. Move the related NEWS entry from roundcube-sqlite to
+roundcube-core and explain how to continue upgrade. Closes: #688634.
+
+ -- Vincent Bernat   Sat, 16 Mar 2013 17:26:20 +0100
+
+roundcube (0.7.2-6) unstable; urgency=low
+
+  * Fix the symlink mess in postinst when upgrading from 0.5 to a more
+recent version. Closes: #680917, #656886.
+
+ -- Vincent Bernat   Sat, 10 Nov 2012 13:51:17 +0100
+
 roundcube (0.7.2-5) unstable; urgency=low
 
   * Fix problem with some uuencoded attachments. Patch from Michał
diff -Nru roundcube-0.7.2/debian/control roundcube-0.7.2/debian/control
--- roundcube-0.7.2/debian/control	2012-09-29 10:39:58.0 +0100
+++ roundcube-0.7.2/debian/control	2013-03-16 16:26:29.0 +
@@ -46,13 +46,6 @@
  .
  This package will install a full roundcube application.
 
-Package: roundcube-sqlite
-Architecture: all
-Depends: roundcube-mysql | roundcube-pgsql, ${misc:Depends}
-Section: oldlibs
-Description: transitional dummy package
- This package is a dummy transitional package. It can be safely removed.
-
 Package: roundcube-mysql
 Architecture: all
 Depends: php-mdb2-driver-mysql (>= 1.5.0b2), mysql-client | virtual-mysql-client, ${misc:Depends}
@@ -64,8 +57,8 @@
 
 Package: roundcube-pgsql
 Architecture: all
-Depends: php-mdb2-driver-pgsql (>= 1.5.0b2), postgresql-client-8.1 | postgresql-client, ${misc:Depends}
-Suggests: postgresql-server
+Depends: php-mdb2-driver-pgsql (>= 1.5.0b2), postgresql-client-9.1 | postgresql-client, ${misc:Depends}
+Suggests: postgresql
 Description: metapackage providing PostgreSQL dependencies for RoundCube
  This package provides PostgreSQL dependencies for RoundCube Webmail,
  a skinnable AJAX based webmail solution for IMAP servers. Install
diff -Nru roundcube-0.7.2/debian/roundcube-core.NEWS roundcube-0.7.2/debian/roundcube-core.NEWS
--- roundcube-0.7.2/debian/roundcube-core.NEWS	2012-09-29 10:39:58.0 +0100
+++ roundcube-0.7.2/debian/roundcube-core.NEWS	2013-03-16 16:26:29.0 +
@@ -1,3 +1,22 @@
+roundcube (0.7.2-7) unstable; urgency=low
+
+Roundcube SQLite support is limited to SQLite 2.x. No support for
+SQLite 3.x currently exists. Unfortunately, SQLite 2.x is unmaintained
+for several years and therefore has been dropped from php5
+package.
+
+You need to select another database to continue to use
+Roundcube. Unfortunately, there is currently no migration script
+available. You have to start from an empty database and migrate
+data yourself if you want to keep your settings. You can find some
+directions here:
+ http://wiki.debian.org/Roundcube/DeprecationOfSQLitev2
+
+Once the migration is done, you can remove roundcube-sqlite
+package.
+
+ -- Vincent Bernat   Sat, 02 Mar 2013 22:20:17 +0100
+
 roundcube (0.3.1-2) unstable; urgency=low
 
 Starting from Roundcube 0.3, an incompatibility with Suhosin session
diff -Nru roundcube-0.7.2/de

Bug#703572: lintian4python: don't warn on version mismatch with .rcX upstream version suffix

[Julian Taylor]

Package: lintian4python
Version: 0.16
Severity: wishlist

lintian4py warns about mapping of of .rc (or .beta, .alpha etc) version
suffix mapping to debian versions via ~:

egg-info-version-mismatch 0.13.2.rc1 0.13.2~rc1

a possible regex to match these is in lintian, see 649277.

If possible one could keep the warning after applying the usual debian
tilde transformation to catch typos like:
0.13.2.rc1 <-> 0.13.~rc1


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

Bug#703571: sysvinit: systemd: update check to look for /run/systemd/system

[Michael Stapelberg]

Package: sysv-rc
Version: 2.88dsf-22.1
Severity: wishlist
Tags: patch

Please apply the attached patch to jessie-pending. It fixes the systemd
checks to work properly on systems that use standalone logind without
systemd.

Quote from the commit message:

[PATCH] systemd: update check to look for /run/systemd/system

The old check (for /sys/fs/cgroup/systemd) is a false-positive on
systems which use standalone logind, but not systemd.

The new one is recommended and used by upstream systemd in their
sd_booted() implementation, see
http://cgit.freedesktop.org/systemd/systemd/tree/src/libsystemd-daemon/sd-daemon.c#n518

-- 
Best regards,
Michael
>From 37dcf68cc98f47d4661db86e8263ccb8a56b8ec9 Mon Sep 17 00:00:00 2001
From: Michael Stapelberg 
Date: Thu, 21 Mar 2013 00:47:56 +0100
Subject: [PATCH] systemd: update check to look for /run/systemd/system

The old check (for /sys/fs/cgroup/systemd) is a false-positive on
systems which use standalone logind, but not systemd.

The new one is recommended and used by upstream systemd in their
sd_booted() implementation, see
http://cgit.freedesktop.org/systemd/systemd/tree/src/libsystemd-daemon/sd-daemon.c#n518
---
 debian/postinst |2 +-
 debian/src/sysv-rc/sbin/invoke-rc.d |2 +-
 debian/src/sysv-rc/sbin/update-rc.d |2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/debian/postinst b/debian/postinst
index 515eb99..1750412 100755
--- a/debian/postinst
+++ b/debian/postinst
@@ -96,7 +96,7 @@ fi
 
 # If systemd is running, don't restart init or doing any initctl
 # migration.
-if [ -e /sys/fs/cgroup/systemd ]; then
+if [ -d /run/systemd/system ]; then
 	restart=no
 fi
 if [ "$(uname -s)" = "GNU" ]; then
diff --git a/debian/src/sysv-rc/sbin/invoke-rc.d b/debian/src/sysv-rc/sbin/invoke-rc.d
index 3d99591..b589721 100644
--- a/debian/src/sysv-rc/sbin/invoke-rc.d
+++ b/debian/src/sysv-rc/sbin/invoke-rc.d
@@ -274,7 +274,7 @@ if which initctl >/dev/null && initctl version | grep -q upstart \
&& [ -e "$UPSTARTDIR/${INITSCRIPTID}.conf" ]
 then
 is_upstart=1
-elif test -e /sys/fs/cgroup/systemd ; then
+elif test -d /run/systemd/system ; then
 is_systemd=1
 elif test ! -f "${INITDPREFIX}${INITSCRIPTID}" ; then
 ## Verifies if the given initscript ID is known
diff --git a/debian/src/sysv-rc/sbin/update-rc.d b/debian/src/sysv-rc/sbin/update-rc.d
index fb5b009..f3ef2bf 100755
--- a/debian/src/sysv-rc/sbin/update-rc.d
+++ b/debian/src/sysv-rc/sbin/update-rc.d
@@ -393,7 +393,7 @@ sub make_systemd_links {
 # If we changed anything and this machine is running systemd, tell
 # systemd to reload so that it will immediately pick up our
 # changes.
-if ($changed_sth && -e "/sys/fs/cgroup/systemd") {
+if ($changed_sth && -d "/run/systemd/system") {
 system("systemctl", "daemon-reload");
 }
 }
-- 
1.7.10.4

Bug#701189: linux-image-3.7-trunk-amd64: 3.7.8 locks up occasionally

[Ben Hutchings]

On Wed, 2013-03-20 at 22:51 +0100, Christian Ohm wrote:
> > On Monday, 25 February 2013 at  4:10, Ben Hutchings wrote:
> > > Instead of updating to 3.7.9, I'll be uploading 3.8 to experimental
> > > shortly.  Could you report whether that is more stable, once you've used
> > > it for a while?
> 
> So far, I've had two more hangs under 3.7, but in general it was pretty
> ok. 3.8 didn't hang in the short time I tried it, but it lost the
> network card pretty soon after booting, spamming the kernel log with
> lots of "atl1c :02:00.0: PCI-DMA: Out of IOMMU space for 1522 bytes"
> (with different sizes). Google gives
> https://bugzilla.redhat.com/show_bug.cgi?id=918393 which indicates that
> the just released kernel 3.8.4 includes a fix for that.

Right, there was a change to atl1c in Linux 3.8 that causes it to leak
memory very quickly.

> I've also found
> https://www.kernel.org/pub/linux/kernel/projects/backports/stable/v3.8/ChangeLog-3.8-1
> saying "2) PCI dma mapping errors in atl1c are not checked for and this
> cause hard crashes for some users, from Xiong Huang." which seems to be
> the cause of the broken network, and also might be a fix for the hangs
> in 3.7.

That was the change that caused this memory leak.  I doubt that it has
anything to do with the bug you reported.  Well, I'll upload 3.8.4 soon
and you can find out whether it is really fixed.

Ben.

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


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

Bug#703570: courier-mta: makealiases builds incorrect .xalias files

[Markus Wanner]

Package: courier-mta
Version: 0.68.2-1
Severity: normal

Hi,

very much like the archived issue #254181, I see that makealiases is
(again? still?) generating incorrect .xalias files. In my case,
'makealiases -dump' says (adjusted for privacy):

al...@example.com: ".xalias/alice@example+2ecom"@bluegap.ch

The file that 'makealiases' creates is:
/etc/courier/aliasdir/.courier-:xalias/alice@example+2ecom

According to an strace, the file courier looks for is:
/etc/courier/aliasdir/.courier-:xalias/alice@example+2ecom@bluegap:ch
  (notice the colon instead of the dot at the end)

I'm using a virtual domain setup, bluegap.ch being the defaultdomain,
example.com a random hosteddomain.

Manually symlinking that file corrects the issue. So I guess it's just
makealiases that does the wrong thing. Also note that this is not a
long-term fix, as subsequent invocations of makealiases remove the symlink.

Regards

Markus Wanner


-- System Information:
Debian Release: wheezy
Architecture: i686
Kernel: Linux 3.2.0-4-686-pae

Some package versions:
ii  courier-base0.68.2-1
ii  courier-authdaemon  0.63.0-6+b1





signature.asc
Description: OpenPGP digital signature

Bug#703482: pu: package smarty/2.6.26-1

[Hideki Yamane]

On Wed, 20 Mar 2013 19:38:05 +
"Adam D. Barratt"  wrote:

> 2.6.26-0.2+squeeze1 would be more conventional.

> diff -Nru smarty-2.6.26/debian/source/format 
> smarty-2.6.26/debian/source/format
> --- smarty-2.6.26/debian/source/format  1970-01-01 09:00:00.0 +0900
> +++ smarty-2.6.26/debian/source/format  2013-03-10 22:31:20.0 +0900
> @@ -0,0 +1 @@
> +3.0 (quilt)
> 
> Definitely not in a stable update.

 Okay, then as below. I'll upload it today if it's okay.


diff -u smarty-2.6.26/debian/changelog smarty-2.6.26/debian/changelog
--- smarty-2.6.26/debian/changelog
+++ smarty-2.6.26/debian/changelog
@@ -1,3 +1,12 @@
+smarty (2.6.26-0.2+squeeze1) stable-proposed-updates; urgency=high
+
+  * QA upload.
+  * add debian/patches/avoid_possible_script_execution_from_2.6.27.patch
+- CVE-2012-4437: cherry picked from upstream, prevent XSS (Closes: #702710)
+  Thanks to Yoshinari Takaoka  for the report.
+
+ -- Hideki Yamane   Mon, 11 Mar 2013 01:18:46 +0900
+
 smarty (2.6.26-0.2) unstable; urgency=low
 
   * QA upload:
diff -u smarty-2.6.26/debian/rules smarty-2.6.26/debian/rules
--- smarty-2.6.26/debian/rules
+++ smarty-2.6.26/debian/rules
@@ -9,6 +9,7 @@
dh_clean
 
 build:
+   patch -p1 < 
debian/patches/avoid_possible_script_execution_from_2.6.27.patch
 
 install:
dh_testdir
only in patch2:
unchanged:
--- 
smarty-2.6.26.orig/debian/patches/avoid_possible_script_execution_from_2.6.27.patch
+++ 
smarty-2.6.26/debian/patches/avoid_possible_script_execution_from_2.6.27.patch
@@ -0,0 +1,22 @@
+Description: avoid possible XSS
+ As Yoshinari Takaoka  pointed out, upstream puts
+ a (possible) security fix in Smarty 2.6.27.
+ .
+ See upstream commit as 
https://code.google.com/p/smarty-php/source/detail?r=4660
+
+---
+Origin: upstream
+Last-Update: 2013-03-11
+
+--- smarty-2.6.26.orig/libs/Smarty.class.php
 smarty-2.6.26/libs/Smarty.class.php
+@@ -1090,7 +1090,8 @@ class Smarty
+  */
+ function trigger_error($error_msg, $error_type = E_USER_WARNING)
+ {
+-trigger_error("Smarty error: $error_msg", $error_type);
++$msg = htmlentities($error_msg);
++trigger_error("Smarty error: $msg", $error_type);
+ }
+ 
+ 


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

Bug#690399: dh_installinit: add systemd support

[Michael Stapelberg]

Hi Joey,

Here is another patch which I’d like you to apply. Quote from the commit
message:

[PATCH] systemd: update check to look for /run/systemd/system

The old check (for /sys/fs/cgroup/systemd) is a false-positive on
systems which use standalone logind, but not systemd.

The new one is recommended and used by upstream systemd in their
sd_booted() implementation, see
http://cgit.freedesktop.org/systemd/systemd/tree/src/libsystemd-daemon/sd-daemon.c#n518

Thanks!

-- 
Best regards,
Michael
>From c4d06b521ac6fc9bfb611646d01fd706516d8274 Mon Sep 17 00:00:00 2001
From: Michael Stapelberg 
Date: Thu, 21 Mar 2013 00:37:47 +0100
Subject: [PATCH] systemd: update check to look for /run/systemd/system

The old check (for /sys/fs/cgroup/systemd) is a false-positive on
systems which use standalone logind, but not systemd.

The new one is recommended and used by upstream systemd in their
sd_booted() implementation, see
http://cgit.freedesktop.org/systemd/systemd/tree/src/libsystemd-daemon/sd-daemon.c#n518
---
 autoscripts/postinst-init-nostart  |2 +-
 autoscripts/postinst-init-restart  |2 +-
 autoscripts/postinst-init-tmpfiles |2 +-
 autoscripts/postrm-init|2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/autoscripts/postinst-init-nostart b/autoscripts/postinst-init-nostart
index ec6bdbd..6ccb483 100644
--- a/autoscripts/postinst-init-nostart
+++ b/autoscripts/postinst-init-nostart
@@ -1,7 +1,7 @@
 if [ -x "/etc/init.d/#SCRIPT#" ]; then
 	# In case this system is running systemd, we need to ensure that all
 	# necessary tmpfiles (if any) are created before starting.
-	if [ -d /sys/fs/cgroup/systemd ] ; then
+	if [ -d /run/systemd/system ] ; then
 		systemd-tmpfiles --create >/dev/null || true
 	fi
 
diff --git a/autoscripts/postinst-init-restart b/autoscripts/postinst-init-restart
index 862f9cc..d27cc8d 100644
--- a/autoscripts/postinst-init-restart
+++ b/autoscripts/postinst-init-restart
@@ -1,7 +1,7 @@
 if [ -x "/etc/init.d/#SCRIPT#" ]; then
 	# In case this system is running systemd, we need to ensure that all
 	# necessary tmpfiles (if any) are created before starting.
-	if [ -d /sys/fs/cgroup/systemd ] ; then
+	if [ -d /run/systemd/system ] ; then
 		systemd-tmpfiles --create >/dev/null || true
 	fi
 
diff --git a/autoscripts/postinst-init-tmpfiles b/autoscripts/postinst-init-tmpfiles
index 41f738a..e6cb785 100644
--- a/autoscripts/postinst-init-tmpfiles
+++ b/autoscripts/postinst-init-tmpfiles
@@ -1,5 +1,5 @@
 # In case this system is running systemd, we need to ensure that all
 # necessary tmpfiles (if any) are created before starting.
-if [ -d /sys/fs/cgroup/systemd ] ; then
+if [ -d /run/systemd/system ] ; then
 	systemd-tmpfiles --create >/dev/null || true
 fi
diff --git a/autoscripts/postrm-init b/autoscripts/postrm-init
index 61dcfc5..6f5bb09 100644
--- a/autoscripts/postrm-init
+++ b/autoscripts/postrm-init
@@ -5,6 +5,6 @@ fi
 
 # In case this system is running systemd, we make systemd reload the unit files
 # to pick up changes.
-if [ -d /sys/fs/cgroup/systemd ] ; then
+if [ -d /run/systemd/system ] ; then
 	systemctl --system daemon-reload >/dev/null || true
 fi
-- 
1.7.10.4

Bug#703290: davical: possible code insertion or XSS

[Christoph Anton Mitterer]

Oh and just for the records:
I've opened an issue upstream that will handled (2):
https://github.com/DAViCal/davical/issues/4


smime.p7s
Description: S/MIME cryptographic signature

Bug#703569: libipc-run-perl: full_result is buggy or confusing

[Vincent Lefevre]

Package: libipc-run-perl
Version: 0.92-1
Severity: normal

The IPC::Run(3pm) man page says:

  result
 $h->result;

  Returns the first non-zero result code (ie $? >> 8).  See
  "full_result" to get the $? value for a child process.

  To get the result of a particular child, do:

 $h->result( 0 );  # first child's $? >> 8
 $h->result( 1 );  # second child

So, one has the impression that "full_result" is equivalent to "result"
except that it considers $? instead of $? >> 8. But this is apparently
not the case when one gives an argument:

  full_result
 $h->full_result;

  Returns the first non-zero $?.  See "result" to get the first
  $? >> 8 value for a child process.

  To get the result of a particular child, do:

 $h->full_result( 0 );  # first child's $? >> 8
  ^
 $h->full_result( 1 );  # second child

I first thought that this was an error in the man page, but this is
really the behavior, as this can be seen on the following script:


#!/usr/bin/env perl

use strict;
use IPC::Run qw(start);

my ($out,$err);
my $h = start \@ARGV, \*STDIN, \$out, \$err;

while (1)
  {
eval { $h->pump };
last if $@ ne '';
foreach (split /\n/, $out)
  { printf "OUT: $_\n" }
foreach (split /\n/, $err)
  { printf "ERR: $_\n" }
undef $out, $err;
  }

if ($@ !~ /^process ended prematurely/)
  { die $@ }

$h->finish;

my $r = $h->full_result;
my $s = $h->full_result(0);
print "$r $s\n";


$ ./ipcrun.pl sh -c 'kill $$'
15 0
$ ./ipcrun.pl sh -c 'exit 2'
512 2

I'm wondering whether this is the wanted behavior.

* If it is, then it seems that one cannot get the $? of the next
children (in scripts where there are such children), i.e. to know
whether they have been terminated by a signal.

In such a case, the man page should be modified to say:

  See "full_result" to get the first non-zero $? value for a child
  process.

and for "full_result", it should say that with an argument,
"full_result" is equivalent to "result" (so that the user isn't
surprised).

* It it isn't, then the behavior and the man page should be fixed.

-- System Information:
Debian Release: 7.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages libipc-run-perl depends on:
ii  libio-pty-perl  1:1.08-1+b2
ii  perl5.14.2-20

libipc-run-perl recommends no packages.

libipc-run-perl 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#695150: what micah actually meant here...

[anarcat]

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

But that bug is now fixed in Debian, so it seems we'd be good to go
unless we get a clarification of what else is blocking this to be
packaged...

Control: block -1 by 698746
Control: block 569506 by 695150
Control: block 576696 by 695150
Control: block 499229 by 695150

As things stand, there are a lot of critical bugs in this package, even
in wheezy or stable, i marked a few above which i really believe are
fixed in the new version.

Anything else than the current version would be an improvement right
now.

A.


signature.asc
Description: Digital signature

Bug#578937: filesystem notification initialization error

[Markus Wanner]

found 578937 0.68.2-1
thanks

I can still reproduce this issue with libfam0 installed but fam either
not installed or installed but not running. Running fam or using
libgamin0 instead doesn't show the same notification.

As libgamin0 directly depends on gamin, and gam_server gets (re)started
automatically, the danger of having libgamin0 provide libfam.so.0
without a proper daemon behind it is close to zero.

However, libfam0 doesn't depend on fam. So it's not unreasonable to end
up with a system with libfam0 providing libfam.so.0 without a (running) fam.

A possible solution to this problem could be to make courier depend on
"gamin | fam" (in addition to the existing libfam0 dependency, as fam
doesn't depend on libfam0 for reasons obscure to me).


To summarize my experiments:

 - libfam0 installed, fam not installed: NOTIFICATION
 - libfam0 and fam installed, fam running: OKAY
 - libfam0 and fam installed, fam not running: NOTIFICATION
 - libgamin0 and gamin installed, gam_server running: OKAY
 - libgamin0 and gamin installed, gam_server killed: OKAY
   (gam_server gets restarted automatically)

 (libgamin0 depends on gamin and vice-versa, so I didn't test a
  "gamin not installed" variant.)

All of this on a wheezy system with the following versions:
courier-0.68.2-1
libfam0/fam-2.7.0-17
libgamin0/gamin-0.1.10-4.1


Regards

Markus Wanner


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

Bug#703568: ifupdown: examples/network-interfaces contains no inet6 example

[Axel Beckert]

Package: ifupdown
Version: 0.7.5+nmu1
Severity: wishlist
Tags: ipv6

Dear Maintainer,

the file /usr/share/doc/ifupdown/examples/network-interfaces.gz referred
by the man page interfaces(5) contains no IPv6 related examples.

It'd be nice if there were some examples for common dualstack
configurations.

-- System Information:
Debian Release: 7.0
  APT prefers testing-updates
  APT policy: (902, 'testing-updates'), (901, 'testing-proposed-updates'), 
(900, 'testing'), (800, 'unstable'), (110, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages ifupdown depends on:
ii  dpkg 1.16.9
ii  initscripts  2.88dsf-41
ii  iproute  20120521-3+b3
ii  libc62.13-38
ii  lsb-base 4.1+Debian8

ifupdown recommends no packages.

Versions of packages ifupdown suggests:
ii  isc-dhcp-client [dhcp-client]  4.2.2.dfsg.1-5+deb70u3
ii  net-tools  1.60-24.2
ii  ppp2.4.5-5.1+b1
pn  rdnssd 

-- 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#703567: munin-node: ip_ does not work with an ipv6 address

[Kenyon Ralph]

tags 703567 fixed-upstream
thanks

On 2013-03-20T23:21:52+0100, Jean-Philippe Guerard 
 wrote:
> Package: munin-node
> Version: 1.4.5-3
> Severity: normal
> 
> Running ip_ with an ipv6 address yields the following error:
> 
> --
> munin-run ip_:222:2:::2
> + :
> + . /usr/share/munin/plugins/plugin.sh
> + IP=:222:2:::2
> + INPUT=INPUT
> + OUTPUT=OUTPUT
> + eval function iptables() {
>   /sbin/ip6tables "$@"
>   }
> eval: 1: Syntax error: "(" unexpected
> --
> 
> The ip_ script starts with #!/bin/sh and "function" is a bash-ism.
> 
> Replacing #!/bin/sh by #!/bin/bash on line 1 (and line 2) solves this issue.

This was fixed upstream:
https://github.com/munin-monitoring/munin/commit/2f72cd57dba6d148bf013cdc96bc9ae92f2bd936

> Replacing:
> 
> --
> eval 'function iptables() {
> /sbin/ip6tables "$@"
> }'
> --
> 
> by
> 
> --
> eval 'iptables() {
> /sbin/ip6tables "$@"
> }'
> --
> 
> also solves this issue.

This was also fixed upstream:
https://github.com/munin-monitoring/munin/commit/fa0b8dd560c3be41d0b1b8bcce1a2aca8924ac0a

-- 
Kenyon Ralph


signature.asc
Description: Digital signature

Bug#703565: Forwarded

[Filipus Klutiero]

forwarded 703565 http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14012
tags 703565 + upstream
thanks

Oops... reporting to 2 ITS-s at the same time is a nice feature, but I 
didn't mean to try it with this case.

Anyway, as it's already done, this is also #14012 upstream.


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

Bug#703290: davical: possible code insertion or XSS

[Christoph Anton Mitterer]

forwarded 703290 https://github.com/DAViCal/davical/pull/3
fixed 703290 1.1.2
stop

I fixed that upstream. So once we get an upload with this into Debian,
we can actually close the bug.


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Bug#702072: RFS: tilda/1.1.4-1 [ITA] New upload

[Lanoxx]

Hi Anton,

I have just uploaded the package again (I added -Wl,--as-needed, to the 
src/Makefile, that fixed the issue). I also changed the version to 
1.1.5, which was actually the last version I had tagged in git. Are you 
now going to upload the package for me?


Kind Regards
Sebastian

On 20/03/13 19:59, Anton Gladky wrote:

On 03/19/2013 11:26 PM, Lanoxx wrote:

dpkg-shlibdeps: warning: package could avoid a useless dependency if
debian/tilda/usr/bin/tilda was not linked against libcairo-gobject.so.2
(it uses none of the library's symbols)

Do you know how to fix that?


You can try to add "--as-needed" parameter to LD_FLAGS.

Anton






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

Bug#696782: RFS: sequitur-g2p/0.0.r1668-1 [ITP] -- Grapheme to Phoneme conversion tool

[Jakub Wilk]

* Jakub Wilk , 2013-02-16, 13:10:
Are the Python modules shipped by this package supposed to be 
used by other software?

If not, they should be moved to a private directory.
If yes, then they need to be renamed or moved into a namespace, 
because their are way to generic ("tool", "misc", etc.).


It is the former case. It was my fault because I did not read 
carefully the Debian policy about Python.
I moved the modules to 
/usr/lib/sequitur-g2p/python//dist-packages. After 
installation I also change the main script so that it can locate 
the modules.

Is this approach ok?


I'm afraid that dh_python2 doesn't support such layout.
I asked for advice on how to handle similar cases on debian-python@:
http://lists.debian.org/20130216120158.ga3...@jwilk.net


Okay. So I see the following ways to go forward:

B) Install the modules as public ones, but put them in a namespace 
starting with underscore, say _sequitur_gp2.


C1) Build the modules only for the default Python version and install 
them to a private directory (/usr/lib/sequitur-gp2/). But then this will 
trigger #702677, so either implement a work-around for it, or wait until 
it's fixed, or switch back to python-support...


I leave to your discretion which option to choose. B is my preference, 
although it didn't gain recognition on debian-python.



Now some other business:

There are some tests, it would be good to run them at build time. 
(Although at least some of them seem to only touch code that doesn't 
even end up in binary packages...)


If I were packaging this myself, I'd use "0+r1668-1" as version number, 
just in case upstream decides to make a proper release versioned 
"0.0.1". But you can keep the current versioning scheme if you like it, 
of course.


Did you manually edit the manpage? If yes, then "DO NOT MODIFY THIS 
FILE" should be probably removed; otherwise it might be a good idea to 
regenerate it at build time.


--
Jakub Wilk


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

Bug#649240: release-notes: Upcoming upgrade issues with GNU Screen for Wheezy

[Axel Beckert]

Control: tag -1 +patch

Hi,

Joost van Baal-Ilić wrote:
> For the record: Julien Cristau's patch is incorporated in screen in wheezy.
> Axel told me "thanks for the reminder" when I told him about this bugreport.
> He'll likely work on the release notes.

Here's a patch against revision 9641 of the release notes which covers
screen's upgrade issues:

Index: upgrading.dbk
===
--- upgrading.dbk   (revision 9641)
+++ upgrading.dbk   (working copy)
@@ -1281,7 +1281,41 @@
 hand.
 
 
+
+Screen
+
+The GNU Screen versions in Squeeze and Wheezy don't use the same
+communication protocol between the screen client
+and the SCREEN server. Wheezy's screen package has been patched so that
+the most important functionality is present even if the versions of
+screen client and server don't match.
+
+
+The most prominent functionality which does not work properly when
+connecting to a Screen session started with Squeeze's version of
+screen with Wheezy's version
+of screen as client is
+terminal resizing (WINCH signal). The workaround is
+to detach and reattach again to get the size of the terminals inside
+the screen session adjusted propely.
+
+
+Another (harmless) symptom of such an inter-version connection is
+screen issuing messages like "Message 40 of 12376
+bytes too small".
+
+
+All those issues vanish as soon as the Screen sessions started with
+Squeeze's version of screen
+exited.
+
+
+See also /usr/share/doc/screen/NEWS.Debian.gz of
+Wheezy's screen package.
+
 
+
 
 
 

HTH.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-|  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5


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

Bug#703565: [coreutils] Please add timestamps to the output of tail -f

[Bob Proulx]

Filipus Klutiero wrote:
> tail --follow is useful to see what is being added to a file.
> However, if the monitored file is followed for a certain period, it
> doesn't indicate when the new content was added. It would be nice if
> tail allowed to prepend timestamps to the output, as MultiTail's -ts
> option does.

But, but, but... multitail already does this.

> This is a little delicate to do. The timestamp could be prepended to
> each line, or only to each atomic addition to the file. Also, as we
> don't know when the existing lines were added, we can't give them an
> exact timestamp. MultiTail stamps them with the time of MultiTail's
> launch, but I find that a bit misleading. I would consider simply
> not stamping these.

As you note there is no clean solution for those previously added
lines.  No matter what is done it cannot be correct.

> In any case, as this alters the output, this should be optional.
> 
> Scanning the changelog suggests this has not been implemented as of 8.21.

This is most easily done using normal tools already.  As you know the
philosophy is that programs should do one thing and then those should
work together to build more complex things.  For example here is one
way to do what you are asking.  And this is just one of many
possibilities.

  $ tail -f /var/log/syslog | perl -MPOSIX -lne 'print strftime("%T 
",localtime()), $_;'

Also there already exists multitail which does what you are asking.
If so then why not simply use multitail?  Is the natural progression
that tail be mutated into multitail?  In that case we should simply
use multitail directly.  But that does have a size penalty.

  $ ll -h /usr/bin/tail /usr/bin/multitail
  -rwxr-xr-x 1 root root 264K Jan 23  2012 /usr/bin/multitail
  -rwxr-xr-x 1 root root  67K Nov 18 08:25 /usr/bin/tail

Bob


signature.asc
Description: Digital signature

Bug#688140: file-rc: File-rc doesn't restore rcX.d dirs at remove, breaks sysv-rc installation.

[Roger Leigh]

On Wed, Mar 20, 2013 at 05:04:57PM +0100, Michael Stapelberg wrote:
> at this point I cannot spend any more time on this bug report.

I've tested your patch, and it appears to work correctly in all
the cases I've tried.  I've updated it slightly (attached) to
log what's happening during transition to dependency-based boot,
particularly if things go wrong, but it's otherwise functionally
identical to your patch.  It also runs insserv in verbose mode
so that any errors/warnings are not hidden (as for sysv-rc).

Alexander, is this approach OK with you?  If you're happy with
what this is doing, can this go into wheezy?


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
diff -urN file-rc-0.8.14.original/debian/changelog file-rc-0.8.15/debian/changelog
--- file-rc-0.8.14.original/debian/changelog	2012-08-19 19:56:20.0 +0100
+++ file-rc-0.8.15/debian/changelog	2013-03-20 22:39:54.191661297 +
@@ -1,3 +1,16 @@
+file-rc (0.8.15) unstable; urgency=low
+
+  [ Michael Stapelberg ]
+  * Call rcfile2link.sh followed by insserv to properly restore links
+when removing file-rc. (Closes: #688140)
+
+  [ Roger Leigh ]
+  * When migrating to dependency-based boot in the prerm, log
+what's happening, and if insserv fails issue an informative
+message (taken from sysv-rc postinst).
+
+ -- Roger Leigh   Wed, 20 Mar 2013 21:31:30 +
+
 file-rc (0.8.14) unstable; urgency=low
 
   * Depend on insserv, this prevents upgrade problems with systems
diff -urN file-rc-0.8.14.original/debian/prerm file-rc-0.8.15/debian/prerm
--- file-rc-0.8.14.original/debian/prerm	2012-07-30 06:49:08.0 +0100
+++ file-rc-0.8.15/debian/prerm	2013-03-20 22:35:07.459268780 +
@@ -16,12 +16,32 @@
 # for details, see http://www.debian.org/doc/debian-policy/ or
 # the debian-policy package
 
+# Make sure insserv is in path
+PATH=/sbin:$PATH
 
 case "$1" in
 remove)
+echo "info: restoring rc.d links" 1>&2
+/usr/share/file-rc/rcfile2link.sh
+echo "info: running insserv" 1>&2
+if insserv -v ; then
+echo "success: Enabled dependency based boot system." 1>&2
+else
+echo "error: Something failed while migrating." 1>&2
+cat 1>&2 

Bug#703539: Upgrade fails with `/etc/grub.d/10_hurd: line 22: /usr/lib/grub/update-grub_lib: No such file or directory`

[Paul Menzel]

Dear Colin,


thank you for your quick reply.


Am Mittwoch, den 20.03.2013, 22:27 + schrieb Colin Watson:
> Control: severity -1 important
> 
> On Wed, Mar 20, 2013 at 06:45:23PM +0100, Paul Menzel wrote:
> > So `10_hurd` is not touched? See below.
> 
> /etc/grub.d/10_hurd hasn't been shipped by Debian's grub-common package
> on i386 for rather a long time now; in fact, until I did some
> archaeology as a result of this bug, I was unaware that it was ever
> shipped on non-Hurd architectures.  The last package version to ship it
> was 1.96+20081201-1, uploaded on 2008-12-01.  Since really not that many
> people were using grub2 back then, I'm downgrading severity, although we
> still ought to clean this up.

Agreed.

> Can you confirm that you were using grub2 that long ago?

Yes, I think so. I switched to it pretty early.

$ ls -l 10_hurd
-rwxr-xr-x 1 root root 2339 Sep  1  2008 10_hurd
$ dpkg -S 10_hurd
grub-common: /etc/grub.d/10_hurd


Thanks,

Paul


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

Bug#703539: Upgrade fails with `/etc/grub.d/10_hurd: line 22: /usr/lib/grub/update-grub_lib: No such file or directory`

[Colin Watson]

Control: severity -1 important

On Wed, Mar 20, 2013 at 06:45:23PM +0100, Paul Menzel wrote:
> So `10_hurd` is not touched? See below.

/etc/grub.d/10_hurd hasn't been shipped by Debian's grub-common package
on i386 for rather a long time now; in fact, until I did some
archaeology as a result of this bug, I was unaware that it was ever
shipped on non-Hurd architectures.  The last package version to ship it
was 1.96+20081201-1, uploaded on 2008-12-01.  Since really not that many
people were using grub2 back then, I'm downgrading severity, although we
still ought to clean this up.

Can you confirm that you were using grub2 that long ago?

-- 
Colin Watson   [cjwat...@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#702523: Bug#702486: libnet-twitter-perl: version 4.x required for new Twitter API

[Jonathan Wiltshire]

On Wed, Mar 20, 2013 at 08:51:30PM +, Jonathan Wiltshire wrote:
> On Sun, Mar 17, 2013 at 08:25:51PM +, Dominic Hargreaves wrote:
> > On Thu, Mar 07, 2013 at 07:49:56PM +0100, Salvatore Bonaccorso wrote:
> > > Control: clone 702486 -1
> > > Control: reassign -1 libnet-twitter-lite-perl
> > > Control: retitle -1 libnet-twitter-perl: needs update for new Twitter API
> > > 
> > > On Thu, Mar 07, 2013 at 07:28:50AM +0100, Ansgar Burchardt wrote:
> > > > Package: libnet-twitter-perl
> > > > Severity: grave
> > > > 
> > > > Let's turn this into a proper bug report:
> > > > 
> > > > Patrick Brewer  writes:
> > > > > For those using Net:Twitter the latest version of the lib is needed
> > > > > ASAP.  Twitter is turning off their old API sometime this month
> > > > > (official date was yesterday).  A version of the module in 4.x is
> > > > > required for the new API.  The very latest I can find for debian is
> > > > > 3.18003 here: http://packages.debian.org/sid/libnet-twitter-perl
> > > 
> > > Cloning this for libnet-twitter-lite-perl as support for Twitter API
> > > 1.1 was also only introduced in Net::Twitter::Lite in
> > > 
> > > 0.12000 2013-03-04
> > > - URI encode POSTDATA to match Twitter's more stringent 
> > > (non-standard) requirements
> > > - created Net::Twitter::Lite::WithAPIv1_1 for Twitter API v1.1 support
> > 
> > This is now fixed for libnet-twitter-lite-perl in experimental.
> > 
> > Release team: the old API from twitter is very close to going away;
> > https://dev.twitter.com/blog/api-v1-retirement-update
> > 
> > and new upstream releases of both Net::Twitter and Net::Twitter::Lite
> > are needed to allow continued usage of these modules.
> > 
> > The upstream diffs are quite large:
> > 
> > https://metacpan.org/diff/release/MMIMS/Net-Twitter-Lite-0.11002/MMIMS/Net-Twitter-Lite-0.12000
> > 
> > https://metacpan.org/diff/release/MMIMS/Net-Twitter-3.18003/MMIMS/Net-Twitter-4.3
> > 
> > but the alternative is probably removing both from wheezy (and squeeze).
> > 
> > FWIW, there's a (somewhat sloppy, to be tidied up) backport of
> > Net::Twitter::Lite 0.11002 for squeeze at
> > 
> > http://anonscm.debian.org/gitweb/?p=pkg-perl/packages/libnet-twitter-lite-perl.git;a=shortlog;h=refs/heads/experimental-squeeze
> > 
> > Thoughts: new upstream releases; remove; something else?
> 
> I'm tending towards removal, sadly. The upstream diff is indeed rather
> large and at this stage, rather unwieldy. I realise lots of it is
> refactoring, but the functional changes would normally rule this out for an
> unblock.
> 
> There is a reverse dependency to consider, I just opened a bug to get
> Michael's comments.

Michael is happy for tircd to be removed too, since it is dead upstream. So
the way is clear for libnet-twitter-perl and libnet-twitter-lite-perl if
that is the way you want to go.


-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

 i have six years of solaris sysadmin experience, from
8->10. i am well qualified to say it is made from bonghits
layered on top of bonghits


signature.asc
Description: Digital signature

Bug#702428: [Pkg-xen-devel] Bug#702428: HVM networking tap/vif bug (Debian bug 702428)

[Daniel Pocock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 17/03/13 18:49, Ian Campbell wrote:
> On Sun, 2013-03-17 at 18:44 +0100, Daniel Pocock wrote:
>> 
>> On 17/03/13 18:38, Ian Campbell wrote:
>>> I'm afraid I don't know about the issue you are seeing but I
>>> can comment on one part:
>>> 
>>> On Sun, 2013-03-17 at 15:02 +0100, Daniel Pocock wrote:
 while the output from dmesg suggests that the interface
 vif10.0 was created.  It appears there is confusion between
 the vifX.Y and tapX.Y naming schemes.
>>> 
>>> An HVM guest with a network device should get *both* vifX.Y
>>> and tapX.Y, they are kind of two faces of the same "device".
>>> The tapX.Y is the emulated NIC (rtl8169 or e1000 or something)
>>> while the vifX.Y is the PV NIC which the guest can choose to
>>> switch over too (for increased perf etc) if it has a suitable
>>> driver (e.g. Linux PVHVM support, PV drivers for Windows etc
>>> etc).
>>> 
>>> As to why tapX.Y cannot be added to a bridge, I've no idea,
>>> sorry. Are you using bridge or vswitch? Can you manually
>>> enslave the tap device to the bridge?
>>> 
>> I'm using Open vSwitch
> 
> I wonder if something might be logged by ovs about why it is
> refusing this operation? I think OVS has pretty extensive logging
> capabilities too so you might be able to increase the verbosity.
> 

Ok, I played with it some more, there is definite progress but I still
believe something is wrong in one of the scripts:

I notice this in syslog:

 domid: 19
 -c config qemu network with xen bridge for
 tap19.0 xapi1
 can't add tap19.0 to bridge xapi1: Operation not supported
 /etc/xen/scripts/qemu-ifup: could not launch network script
 Could not initialize device 'tap'


After seeing that, I decided to look inside the script mentioned
there, /etc/xen/scripts/qemu-ifup

I found the brctl command in the script

brctl addif $2 $1


Commented out that line so the script now returns 0 (success)

Booted the VM - it boots successfully, but without network
connectivity.  It has a VIF, but no ping

Looking at `brctl show xapi1' and I see vif20.0 is in there, but
tap20.0 is not

Manually run the command

ovs-vsctl add-port xapi1 tap20.0

Now it is possible to ping the running HVM domU

Should the script be using the ovs-vsctl command instead of brctl?  Or
have I misconfigured something and the wrong script is being run?

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJRSjkEAAoJEOm1uwJp1aqDw8EP/3Er1BTtGmfZn16kndFzklUl
gU901PTVtNOaLODI9c+ecE4Z+vBMWebPhwwXeiDEjCS32xlufJAeSBG5hf31lHt2
mhPjHMzO8MjvIicC4zqN85soNIYz0T57bjWJhUoYhPvZCnwFSoi7vegteE9der+C
J1xfh3BzdyUHNMphDsuHPuZSninEpUrZT4Ez9jRKM585UpNgM75tIMoHzzm+j/Ek
qwTZKISyc+0sd/QGwCzet3/P3lUkKXhZ296SjsBcPjqq0IHkO391xD9jCX4XMLxR
2lQMfVlvW+KciZwnKsvPWQC9NsyhtnTBZ9sSof9e/WYYsxZ9PWRDZ60QPn8RIHrg
pP0WwYbfGvs1cGj5Gu7kjq0ikhRQ4HLcE/b3S8Y8knv4/LyIZj98D+RAiIbPuq48
MF8BHFZw5QjLPPe24Dhq7684YiFUpInFvHx1i7PBJdv1RwxA32pmauPNUHLOg232
qoBjoY5IjEUJI3+OwV772DF38WqsZru25ANwbNXh4PSs4PVnCt6eXc/w70UQeNEG
7OEEkQ7qyPG4iAWQvaFlvrOnwS47g1E9ARMnLhjPGKXwU88PMawmqMf0pVlaR499
199GIc28lAnTkLJHfNs6FdJlGvp8xl0BzhGK7BSPgEm0Y83PV/COwvDFpDNLXNng
MDh3YrAb/VHQxzTnNmzj
=zyPi
-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#703567: munin-node: ip_ does not work with an ipv6 address

[Jean-Philippe Guerard]

Package: munin-node
Version: 1.4.5-3
Severity: normal

Running ip_ with an ipv6 address yields the following error:

--
munin-run ip_:222:2:::2
+ :
+ . /usr/share/munin/plugins/plugin.sh
+ IP=:222:2:::2
+ INPUT=INPUT
+ OUTPUT=OUTPUT
+ eval function iptables() {
/sbin/ip6tables "$@"
}
eval: 1: Syntax error: "(" unexpected
--

The ip_ script starts with #!/bin/sh and "function" is a bash-ism.

Replacing #!/bin/sh by #!/bin/bash on line 1 (and line 2) solves this issue.

Replacing:

--
eval 'function iptables() {
/sbin/ip6tables "$@"
}'
--

by

--
eval 'iptables() {
/sbin/ip6tables "$@"
}'
--

also solves this issue.

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

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

Versions of packages munin-node depends on:
ii  adduser3.112+nmu2add and remove users and groups
ii  gawk   1:3.1.7.dfsg-5GNU awk, a pattern scanning and pr
ii  libnet-server-perl 0.97-1An extensible, general perl server
ii  lsb-base   3.2-23.2squeeze1  Linux Standard Base 3.2 init scrip
ii  munin-common   1.4.5-3   network-wide graphing framework (c
ii  perl   5.10.1-17squeeze6 Larry Wall's Practical Extraction 
ii  procps 1:3.2.8-9squeeze1 /proc file system utilities

Versions of packages munin-node recommends:
ii  libnet-snmp-perl  5.2.0-4Script SNMP connections

Versions of packages munin-node suggests:
ii  acpi   1.5-2 displays information on ACPI devic
pn  ethtool(no description available)
ii  hdparm 9.32-1tune hard disk parameters for high
pn  libcache-cache-perl(no description available)
pn  libcrypt-ssleay-perl   (no description available)
pn  libdbd-mysql-perl  (no description available)
ii  libdbd-pg-perl 2.17.1-2+squeeze1 Perl DBI driver for the PostgreSQL
pn  liblwp-useragent-deter (no description available)
pn  libnet-irc-perl(no description available)
pn  libnet-ssleay-perl (no description available)
pn  libtext-csv-xs-perl(no description available)
ii  libwww-perl5.836-1   Perl HTTP/WWW client/server librar
pn  libxml-simple-perl (no description available)
ii  logtail1.3.13Print log file lines that have not
ii  munin  1.4.5-3   network-wide graphing framework (g
pn  munin-java-plugins (no description available)
ii  munin-plugins-extra1.4.5-3   network-wide graphing framework (u
pn  mysql-client   (no description available)
ii  net-tools  1.60-23   The NET-3 networking toolkit
ii  python 2.6.6-3+squeeze7  interactive high-level object-orie
ii  ruby   4.5   An interpreter of object-oriented 
ii  smartmontools  5.39.1+svn3124-2  control and monitor storage system

-- Configuration Files:
/etc/munin/munin-node.conf changed [not included]
/etc/munin/plugin-conf.d/munin-node [Errno 13] Permission denied: 
u'/etc/munin/plugin-conf.d/munin-node'

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/share/munin/plugins/ip_ (from munin-node package)


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

Bug#703566: libasound2: valgrind aplay -L prints scary warnings

[Julien Pommier]

Package: libasound2
Version: 1.0.25-4
Severity: normal

Dear Maintainer,

When I run this command:

valgrind aplay -L

it complains about quite a few invalid reads in libasound:

==24995== Memcheck, a memory error detector
==24995== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==24995== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==24995== Command: aplay -L
==24995==
==24995== Invalid read of size 8
==24995==at 0x506AB30: snd_config_iterator_next (in 
/usr/lib/x86_64-linux-gnu/libasound.so.2.0.0)
==24995==by 0x5075A8C: snd_device_name_hint (in 
/usr/lib/x86_64-linux-gnu/libasound.so.2.0.0)
==24995==by 0x4042B2: ??? (in /usr/bin/aplay)
==24995==by 0x40992D: ??? (in /usr/bin/aplay)
==24995==by 0x59EBEAC: (below main) (libc-start.c:228)
==24995==  Address 0x5d62eb8 is 40 bytes inside a block of size 72 free'd
==24995==at 0x4C27D4E: free (vg_replace_malloc.c:427)
==24995==by 0x506B5B4: snd_config_delete (in 
/usr/lib/x86_64-linux-gnu/libasound.so.2.0.0)
==24995==by 0x506BAE7: parse_defs (in 
/usr/lib/x86_64-linux-gnu/libasound.so.2.0.0)
==24995==by 0x506BEA5: snd_config_load1 (in 
/usr/lib/x86_64-linux-gnu/libasound.so.2.0.0)
==24995==by 0x506C0CC: config_file_open (in 
/usr/lib/x86_64-linux-gnu/libasound.so.2.0.0)
==24995==by 0x506D8EC: snd_config_hook_load (in 
/usr/lib/x86_64-linux-gnu/libasound.so.2.0.0)
==24995==by 0x6157C48: ???
==24995==by 0x506E496: snd_config_hooks.constprop.24 (in 
/usr/lib/x86_64-linux-gnu/libasound.so.2.0.0)
==24995==by 0x506EAA3: snd_config_searcha_hooks (in 
/usr/lib/x86_64-linux-gnu/libasound.so.2.0.0)
==24995==by 0x506EB78: snd_config_searchva_hooks (in 
/usr/lib/x86_64-linux-gnu/libasound.so.2.0.0)
==24995==by 0x506EC55: snd1_config_search_alias_hooks (in 
/usr/lib/x86_64-linux-gnu/libasound.so.2.0.0)
==24995==by 0x506DDB0: snd_config_search_definition (in 
/usr/lib/x86_64-linux-gnu/libasound.so.2.0.0)
==24995== 
==24995== Invalid read of size 8
==24995==at 0x5069E5E: snd_config_get_id (in 
/usr/lib/x86_64-linux-gnu/libasound.so.2.0.0)
==24995==by 0x5075A54: snd_device_name_hint (in 
/usr/lib/x86_64-linux-gnu/libasound.so.2.0.0)
==24995==by 0x4042B2: ??? (in /usr/bin/aplay)
==24995==by 0x40992D: ??? (in /usr/bin/aplay)
==24995==by 0x59EBEAC: (below main) (libc-start.c:228)
==24995==  Address 0x5d62e90 is 0 bytes inside a block of size 72 free'd
==24995==at 0x4C27D4E: free (vg_replace_malloc.c:427)
==24995==by 0x506B5B4: snd_config_delete (in 
/usr/lib/x86_64-linux-gnu/libasound.so.2.0.0)
==24995==by 0x506BAE7: parse_defs (in 
/usr/lib/x86_64-linux-gnu/libasound.so.2.0.0)
==24995==by 0x506BEA5: snd_config_load1 (in 
/usr/lib/x86_64-linux-gnu/libasound.so.2.0.0)
==24995==by 0x506C0CC: config_file_open (in 
/usr/lib/x86_64-linux-gnu/libasound.so.2.0.0)
==24995==by 0x506D8EC: snd_config_hook_load (in 
/usr/lib/x86_64-linux-gnu/libasound.so.2.0.0)
==24995==by 0x6157C48: ???
==24995==by 0x506E496: snd_config_hooks.constprop.24 (in 
/usr/lib/x86_64-linux-gnu/libasound.so.2.0.0)
==24995==by 0x506EAA3: snd_config_searcha_hooks (in 
/usr/lib/x86_64-linux-gnu/libasound.so.2.0.0)
==24995==by 0x506EB78: snd_config_searchva_hooks (in 
/usr/lib/x86_64-linux-gnu/libasound.so.2.0.0)
==24995==by 0x506EC55: snd1_config_search_alias_hooks (in 
/usr/lib/x86_64-linux-gnu/libasound.so.2.0.0)
==24995==by 0x506DDB0: snd_config_search_definition (in 
/usr/lib/x86_64-linux-gnu/libasound.so.2.0.0)
==24995== 
==24995== Invalid read of size 1
==24995==at 0x5A12CBA: vfprintf (vfprintf.c:1623)
==24995==by 0x5ABA65C: __vsprintf_chk (vsprintf_chk.c:87)
==24995==by 0x5ABA59E: __sprintf_chk (sprintf_chk.c:33)
==24995==by 0x507499F: try_config (in 
/usr/lib/x86_64-linux-gnu/libasound.so.2.0.0)
==24995==by 0x5075A7C: snd_device_name_hint (in 
/usr/lib/x86_64-linux-gnu/libasound.so.2.0.0)
==24995==by 0x4042B2: ??? (in /usr/bin/aplay)
==24995==by 0x40992D: ??? (in /usr/bin/aplay)
==24995==by 0x59EBEAC: (below main) (libc-start.c:228)
==24995==  Address 0x5d62de0 is 0 bytes inside a block of size 8 free'd
==24995==at 0x4C27D4E: free (vg_replace_malloc.c:427)
==24995==by 0x506B5AC: snd_config_delete (in 
/usr/lib/x86_64-linux-gnu/libasound.so.2.0.0)
==24995==by 0x506BAE7: parse_defs (in 
/usr/lib/x86_64-linux-gnu/libasound.so.2.0.0)
==24995==by 0x506BEA5: snd_config_load1 (in 
/usr/lib/x86_64-linux-gnu/libasound.so.2.0.0)
==24995==by 0x506C0CC: config_file_open (in 
/usr/lib/x86_64-linux-gnu/libasound.so.2.0.0)
==24995==by 0x506D8EC: snd_config_hook_load (in 
/usr/lib/x86_64-linux-gnu/libasound.so.2.0.0)
==24995==by 0x6157C48: ???
==24995==by 0x506E496: snd_config_hooks.constprop.24 (in 
/usr/lib/x86_64-linux-gnu/libasound.so.2.0.0)
==24995==by 0x506EAA3: snd_config_searcha_hooks (in 
/usr/lib/x86_64-linux-gnu/libasound.so.2.0.0)
==24995=

Bug#703141: scratch: fails to install if gnome-session-common is installed but hicolor-icon-theme is no

[Jonathan Wiltshire]

On Sun, Mar 17, 2013 at 03:03:20PM -0400, Michael Gilbert wrote:
> control: tag -1 patch
> 
> Hi, I've uploaded an nmu to delayed/5 fixing this issue.  Please see
> attached patch.

Your patch doesn't seem to address the underlying issue, which is the
problematic postinst/postrm scripts. Does scratch /actually/ depend on
hicolor-icon-theme, or is this just to solve the call to
gtk-update-icon-cache (which if I've understood correctly, should actually
be handled by a trigger)?

I think you should reconsider this upload.


-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

 i have six years of solaris sysadmin experience, from
8->10. i am well qualified to say it is made from bonghits
layered on top of bonghits


signature.asc
Description: Digital signature

Bug#703556: tircd: depends on libnet-twitter-lite-perl, removal likely

[Jonathan Wiltshire]

On Wed, Mar 20, 2013 at 10:15:55PM +0100, Michael Stapelberg wrote:
> Hi Jonathan,
> 
> Jonathan Wiltshire  writes:
> > As your package depends on it, tircd would also be removed at the same time.
> Given that tircd seems dead upstream, please feel free to remove tircd
> from Debian.

Scheduled for removal. Thanks for the quick answer!


-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

 i have six years of solaris sysadmin experience, from
8->10. i am well qualified to say it is made from bonghits
layered on top of bonghits


signature.asc
Description: Digital signature

Bug#689991: CUPS: error_log flooded due to AllowUser restriction

[Brian Potkin]

On Mon 08 Oct 2012 at 21:47:46 +0200, Sergio Gelato wrote:

 
> I've created a print queue with an
>   AllowUser user1
> option. When submitting a print job as user1 all goes as expected, but
> if I submit it as some other user I see a flood of error messages appear
> (observed rates: 375-500 Hz, depending on the client) in
> /var/log/cups/error_log:
> 
> E [08/Oct/2012:20:31:23 +0200] Returning IPP client-error-not-authorized for 
> Create-Job (ipp://xxx.yyy.zzz.ttt:631/printers/test1) from aaa.bbb.ccc.ddd
> 
> cupsd consumes significant amounts of CPU time while the client is trying
> to submit the job. Both the log flood and the CPU consumption stop as soon
> as I cancel the print job on the client.
> 
> Conclusion: use of AllowUser/DenyUser can lead to (often inadvertent) denial

Hello Sergio,

Thank you for your comprehensive bug report.

I've done some preliminary work on this by creating a print queue on an
Wheezy machine:

  lpadmin -p TEST-AllowUser -v /dev/null -u allow:debian -m 

>From the same machine I do (as user brian):

  lp -d TEST-AllowUser ~/.profile ,

which gives

  lp: Not allowed to print.

The error_log says

  E [20/Mar/2013:21:36:06 +] Returning IPP client-error-not-authorized for 
Create-Job (ipp://localhost:631/printers/TEST-AllowUser) from localhost

which looks as one would expect.

Then the same command was issued from a Sid machine. This lead to the
message flood mentioned above.


On the client:

  top - 22:10:00 up 12:42,  2 users,  load average: 0.56, 0.15, 0.09
  Tasks:  65 total,   2 running,  63 sleeping,   0 stopped,   0 zombie
  %Cpu(s): 37.6 us, 35.5 sy,  0.0 ni, 17.2 id,  0.0 wa,  0.0 hi,  9.7 si, 0.0 st
  KiB Mem:   1034180 total,   172860 used,   861320 free,52412 buffers
  KiB Swap:0 total,0 used,0 free,62840 cached

PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEM TIME+ COMMAND
2121 root  20   0 11128 6784 2532 R 44.8  0.7  22:49.43 cupsd
   13420 root  20   0 19244 6684 1432 S 34.8  0.6   0:09.40 ipp

On the server:

  top - 22:15:37 up  4:45,  2 users,  load average: 0.51, 0.38, 0.20
  Tasks:  67 total,   2 running,  65 sleeping,   0 stopped,   0 zombie
  %Cpu(s): 13.0 us,  9.1 sy,  0.0 ni, 76.0 id,  0.8 wa,  0.0 hi,  1.0 si, 0.0 st
  KiB Mem:   2072492 total,   740336 used,  1332156 free,15332 buffers
  KiB Swap:0 total,0 used,0 free,   676132 cached

PID USER  PR  NI  VIRT  RES  SHR S  %CPU %MEMTIME+  COMMAND
   3405 root  20   0  9176 3304 2516 R  44.2  0.2   2:45.24 cupsd


So, Sergio, which one one of us is going to report this upstream? You or
I?

Regards,

Brian.


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

Bug#612341: could anyone summarize the status on libjpeg-turbo WNPPs?

[Mike Gabriel]

Hi Yaroslav,

On Mi 20 Mär 2013 20:26:24 CET Yaroslav Halchenko wrote:



On Sat, 16 Mar 2013, Mike Gabriel wrote:


Hi Yaroslav,



On Fr 01 Mär 2013 16:11:10 CET Yaroslav Halchenko wrote:



>Hi Guys,



>I wonder if anyone could give a concise summary stopping libjpeg-turbo
>from being uploaded?  there seemed to be lots of work, clarifications
>from upstream, downstream distributions including it,... and no
>clarity why we do not have it in Debian yet (could simply be a lack of
>time?).



>Thank you in advance!



I have experimented around with libjpeg-turbo.git on collab-maint recently.



I have updated upstream to 1.2.90.



By now the current version already looks quite promosing (I hope).
The dpkg-divert stuff, I have remove. The current policy is:



  o link native libjpeg-turbo code against libturbojpeg1
-> a package like TigerVNC or VirtualGL should use libturbojpeg1
  o if the system admin chooses to replaced libjpeg8 by libjpeg8-turbo,
he/she may do so. Only then libjpeg8 is replaced (including all
consequences for all applications on the system)


I think Conflicts/Replaces should be cleaned-up for the libjpeg8-turbo

Package: libjpeg8-turbo
Architecture: any
Multi-Arch: same
Section: libs
Pre-Depends: multiarch-support
Depends: ${shlibs:Depends}, ${misc:Depends}
Conflicts: libjpeg62, libjpeg7
Replaces: libjpeg62, libjpeg7, libjpeg8 (<< 9)
Provides: libjpeg8
Description: IJG JPEG compliant runtime library - SIMD optimized
 This library is based on libjpeg-turbo and not on the IJG JPEG.
 .
 This package provides the runtime library supporting the Independent JPEG
 Group's standard for JPEG files.
 .
 WARNING: This package contains a shared library which is a drop in
 replacement for libjpeg8. Replacing the standard libjpeg6 library
 may have unexpected/unknown effects on certain applications.


atm it conflicts with libjpeg62 libjpeg7 but doesn't actually provide them,
thus resulting in need to remove a bulk of packages happen I decide to give
libjpeg8-turbo a shout as a replacement for libjpeg8.

So why there are those Conflicts: and Replaces for the lib package?


Agreement from here. I guess the different libjpegXX  
Conflicts:/Replaces: relates to the historical arising of the  
different compat levels available in libjpeg-turbo.


Also, the earlier package versions did not conflict+replace, they  
played around with dpkg-divert and allowed simultaneous installation  
of libjpeg8 and libjpeg8-turbo. Only with the last packaging efforts I  
changed it over to Conflicts:/Replaces:. So it might have been me, you  
did some unlean control file editing.


Greets,
Mike


--

DAS-NETZWERKTEAM
mike gabriel, rothenstein 5, 24214 neudorf-bornstein
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb

pgpV8CdjnGrJv.pgp
Description: Digitale PGP-Unterschrift

Bug#703565: [coreutils] Please add timestamps to the output of tail -f

[Filipus Klutiero]

Package: coreutils
Version: 8.13
Severity: wishlist

tail --follow is useful to see what is being added to a file. However, 
if the monitored file is followed for a certain period, it doesn't 
indicate when the new content was added. It would be nice if tail 
allowed to prepend timestamps to the output, as MultiTail's -ts option does.


This is a little delicate to do. The timestamp could be prepended to 
each line, or only to each atomic addition to the file. Also, as we 
don't know when the existing lines were added, we can't give them an 
exact timestamp. MultiTail stamps them with the time of MultiTail's 
launch, but I find that a bit misleading. I would consider simply not 
stamping these.

In any case, as this alters the output, this should be optional.

Scanning the changelog suggests this has not been implemented as of 8.21.


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

Bug#703358: virtualbox-guest-dkms: vboxvideo_drm.c fails to compile after upgrade of linux-headers-3.2.0-4 from 3.2.35-2 to 3.2.39-2

[Roger Leigh]

severity 703358 serious
thanks

On Mon, Mar 18, 2013 at 08:06:29PM +0100, Tomasz Wierzbicki wrote:
> Making dpkg-reconfigure on virtualbox-guest-dkms gives the following error:
> 
> Loading new virtualbox-guest-4.1.18 DKMS files...
> Building only for 3.2.0-4-amd64
> Building initial module for 3.2.0-4-amd64
> Error! Bad return status for module build on kernel: 3.2.0-4-amd64 (x86_64)
> Consult /var/lib/dkms/virtualbox-guest/4.1.18/build/make.log for more
> information.

Having virtualbox kernel modules broken out of the box for wheezy
isn't ideal.  Looks like this broke relatively recently; increasing
the severity.

VirtualBox maintainers: would backporting the necessary bits be
possible to make it buildable with the wheezy kernel?


Thanks,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


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

Bug#615703: fixed

[Markus Wanner]

fixed 615703 0.68.2
thanks

Hi,

I'm pretty sure this issue got fixed somewhere in between 0.65.0-3 and
0.68.2-1. At least I can compile the later even with explicitly adding
'--no-copy-dt-needed-entries' to the LDFLAGS on wheezy (where I think it
already is the default, but anyways).

Regards

Markus Wanner



signature.asc
Description: OpenPGP digital signature

Bug#703417: [Pkg-haskell-maintainers] Bug#703417: haskell-hfuse: fails to build with GHC 7.6

[Joachim Breitner]

Hi,

Am Mittwoch, den 20.03.2013, 14:57 +0900 schrieb TANIGUCHI Takaki:
> > On Tue, 19 Mar 2013 12:49:11 +0100
> > nome...@debian.org(Joachim Breitner)  said:
> 
> > Takaki originally packages haskell-hfuse, so he must have had a use-case
> > for it. Takaki, can you test the fix provided at
> > https://github.com/toothbrush/hfuse/pull/1#issuecomment-13282307
> 
> I built patched deb and ran my scripts with that. It looked fine
> for me. 

ok. Care to upload a patched package to experimental?

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#703564: dump: restore -t should acceppt a -0 option (output zero separated, instead of newline separated)

[Heiko Schlittermann]

Package: dump
Version: 0.4b44-1
Severity: wishlist
Tags: patch upstream

Hello,

processing the output of restore -t (as amanda does) is much more
reliable, if the file names of the listing would be zero terminated,
instead of using a newline as terminator. (Newline can be part of the
filename and if the filename continues with "leaf 4711 …" it's not easy
to parse.

I've written a small patch and it would be great if this patch would
make it into debian and even the upstream.

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

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

Versions of packages dump depends on:
ii  e2fslibs  1.42.5-1
ii  libblkid1 2.20.1-5.3
ii  libc6 2.13-38
ii  libcomerr21.42.5-1
ii  libreadline6  6.2+dfsg-0.1
ii  libselinux1   2.1.9-5
ii  libtinfo5 5.9-10
ii  libuuid1  2.20.1-5.3
ii  tar   1.26+dfsg-0.1

dump recommends no packages.

dump suggests no packages.

-- no debconf information
--- dump-0.4b44.orig/restore/main.c	2009-06-18 11:42:12.0 +0200
+++ dump-0.4b44/restore/main.c	2013-03-20 22:39:36.905605953 +0100
@@ -92,6 +92,7 @@
 int	aflag = 0, bflag = 0, cvtflag = 0, dflag = 0, vflag = 0, yflag = 0;
 int	hflag = 1, mflag = 1, Mflag = 0, Nflag = 0, Vflag = 0, zflag = 0;
 int	uflag = 0, lflag = 0, Lflag = 0, oflag = 0;
+int	nullflag = 0;		/* \0 terminated file names */
 int	ufs2flag = 0;
 char	*Afile = NULL;
 int	dokerberos = 0;
@@ -198,7 +199,7 @@
 #ifdef USE_QFA
 		"P:Q:"
 #endif
-		"Rrs:tT:uvVxX:y")) != -1)
+		"Rrs:tT:uvVxX:y0")) != -1)
 		switch(ch) {
 		case 'a':
 			aflag = 1;
@@ -343,6 +344,9 @@
 		case 'y':
 			yflag = 1;
 			break;
+		case '0':
+			nullflag = 1;
+			break;
 		default:
 			usage();
 		}
--- dump-0.4b44.orig/restore/restore.8.in	2009-06-18 11:42:12.0 +0200
+++ dump-0.4b44/restore/restore.8.in	2013-03-20 22:44:45.511062849 +0100
@@ -79,7 +79,7 @@
 [\fB\-T \fIdirectory\fR]
 .PP
 .B restore \-t
-[\fB\-cdhHklMNuvVy\fR]
+[\fB\-cdhHklMNuvV0y\fR]
 [\fB\-A \fIfile\fR]
 [\fB\-b \fIblocksize\fR]
 [\fB\-f \fIfile\fR]
@@ -264,6 +264,10 @@
 program.  See also the
 .B \-X
 option below.
+If the 
+.B \-0
+flag is used, the output is not line separated anymore, but the NULL
+byte is used as separator.
 .TP
 .B \-x
 The named files are read from the given media. If a named file matches a 
@@ -523,6 +527,12 @@
 (verbose) flag causes it to type the name of each file it treats preceded by 
 its file type.
 .TP
+.B \-0
+(zero terminated) flag causes the output lines to be zero terminated,
+not line feed terminated. This flag is recognized for 
+.B \-t
+(listing) only.
+.TP
 .B \-V
 Enables reading multi-volume non-tape mediums like CDROMs.
 .TP
--- dump-0.4b44.orig/restore/restore.c	2010-12-06 15:26:50.0 +0100
+++ dump-0.4b44/restore/restore.c	2013-03-20 22:33:44.463922398 +0100
@@ -100,9 +100,12 @@
 		fprintf(stdout, "%10lu\t%ld\t%lld\t%s\n", (unsigned long)ino, 
 			tnum, tpos, name);
 	}
-	else
+	else {
 #endif
-		fprintf(stdout, "%10lu\t%s\n", (unsigned long)ino, name);
+		fprintf(stdout, "%10lu\t%s", (unsigned long)ino, name);
+		if (nullflag) putchar('\0');
+		else putchar('\n');
+	}
 	return (descend);
 }
 
--- dump-0.4b44.orig/restore/restore.h	2007-02-22 21:12:50.0 +0100
+++ dump-0.4b44/restore/restore.h	2013-03-20 22:36:16.976654545 +0100
@@ -64,6 +64,7 @@
 extern int	vflag;		/* print out actions taken */
 extern int	yflag;		/* always try to recover from tape errors */
 extern int	zflag;		/* tape is in compressed format */
+extern int	nullflag;	/* \0 separated output in t mode */ 
 extern int	ufs2flag;	/* tape is a FreeBSD UFS2 dump */
 extern char*	bot_script;	/* beginning of tape script */
 /*

Bug#703563: tshark: uses wrong default output format, and cannot change output format

[Lucas Nussbaum]

Package: tshark
Version: 1.8.2-5wheezy1
Severity: important

Hi,

tshark's man page says:
   When writing packets to a file, TShark, by default, writes the file
   in libpcap format [..]
and also says:
   -F  
   Set the file format of the output capture file written using the
   -w option.  The output written with the -w option is raw packet
   data, not text, so there is no -F option to request text output.
   The option -F without a value will list the available formats.


However:
1) tshark uses the pcap-ng format, not the libpcap format.
2) the -F switch does not work.

The problem can be produced with:

$ sudo tshark -i lo -w - > f ; file f
[..]
f: pcap-ng capture file - version 1.0

$ sudo tshark -F libpcap -i lo -w - > f ; file f
[..]
f: pcap-ng capture file - version 1.0

In both cases, I would expect tshark to use the libpcap format, like
tcpdump:
$ sudo tcpdump -i lo -w - > f ; file f
[..]
f: tcpdump capture file (little-endian) - version 2.4 (Ethernet, capture length 
65535)


The version in experimental (1.9.1-1) is also affected.
The version in squeeze is not affected.


This breaks the "use tshark or dumpcap as a remote probe over SSH" use
case described in http://wiki.wireshark.org/CaptureSetup/Pipes :
$ wireshark -k -i <( ssh root@host tshark -i eth0 -w -)

Wireshark displays "Unrecognized libpcap format", since only libpcap
format is supported in that mode.

A workaround is to use tcpdump to capture packets on the remote host.

Lucas


-- System Information:
Debian Release: 7.0
  APT prefers testing
  APT policy: (990, 'testing'), (800, 'stable'), (300, 'unstable'), (150, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages tshark depends on:
ii  libc6 2.13-38
ii  libglib2.0-0  2.33.12+really2.32.4-5
ii  libpcap0.81.3.0-1
ii  libwireshark2 1.8.2-5wheezy1
ii  libwiretap2   1.8.2-5wheezy1
ii  libwsutil21.9.1-1
ii  wireshark-common  1.8.2-5wheezy1
ii  zlib1g1:1.2.7.dfsg-13

tshark recommends no packages.

tshark 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#703562: xen-utils-common: Unable to attach block device with special characters (spaces, etc.) in file or path name

[Mike Edwards]

Package: xen-utils-common
Version: 4.0.0-1
Severity: minor
Tags: patch

/etc/xen/scripts/block doesn't properly enclose $file in quotes for two out
of three stat calls, which causes the script to fail on files which contain
special characters (i.e. spaces) in their filename or pathname.

See attached for patch.


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

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

Versions of packages xen-utils-common depends on:
ii  gawk1:3.1.7.dfsg-5   GNU awk, a pattern scanning and pr
ii  lsb-base3.2-23.2squeeze1 Linux Standard Base 3.2 init scrip
ii  udev164-3/dev/ and hotplug management daemo
ii  xenstore-utils  4.0.1-5.8Xenstore utilities for Xen

xen-utils-common recommends no packages.

xen-utils-common suggests no packages.

-- Configuration Files:
/etc/xen/scripts/block changed [not included]
/etc/xen/xend-config.sxp changed [not included]

-- no debconf information
--- /etc/xen/scripts/block.orig 2010-06-21 09:46:02.0 -0400
+++ /etc/xen/scripts/block  2013-03-20 13:03:29.846945047 -0400
@@ -272,8 +272,8 @@
 
 if [ "x$mode" != 'x!' ]
 then
-  inode=$(stat -c '%i' $file)
-  dev=$(stat -c '%D' $file)
+  inode=$(stat -c '%i' "$file")
+  dev=$(stat -c '%D' "$file")
   if [ -z "$inode" ] || [ -z "$dev" ]
   then
 fatal "Unable to lookup $file: dev: $dev inode: $inode"

Bug#703561: release-notes: Mention Perl 5.14 in Wheezy release notes

[Alessandro Ghedini]

Package: release-notes
Severity: normal

Since Python and PHP are already there, mentioning the updated Perl won't hurt
I guess. I don't (yet) have a patch (if someone wants to step in, please go
ahead), but in the meantime I already updated the wiki page [0].

Cheers

[0] http://wiki.debian.org/NewInWheezy


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

Bug#703560: pychess: not working correctly, engine crafty failed discovery

[gp]

Package: pychess
Version: 0.10~beta3-2
Severity: normal



*** /tmp/reportbug-pychess-20130320-4046-5MjDUu
Subject: pychess: not working correctly, engine crafty failed discovery
Package: pychess
Version: 0.10~beta3-2
Severity: normal


Dear maintainer,

I think that pychess should depend on gstreamer0.10-plugins-base as I had to 
install that package to make pychess work. I have attached the error log 
(pychess.err).

Best regards,
gp


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

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

Versions of packages pychess depends on:
ii  gnome-icon-theme  2.30.3-2   GNOME Desktop icon theme
ii  python2.6.6-3+squeeze7   interactive high-level object-orie
ii  python-cairo  1.8.8-1+b1 Python bindings for the Cairo vect
ii  python-central0.6.16+nmu1register and build utility for Pyt
ii  python-glade2 2.17.0-4   GTK+ bindings: Glade support
ii  python-gobject2.21.4+is.2.21.3-1 Python bindings for the GObject li
ii  python-gst0.100.10.19-1  generic media-playing framework (P
ii  python-gtk2   2.17.0-4   Python bindings for the GTK+ widge
ii  python-gtksourceview2 2.10.1-1   Python bindings for the GtkSourceV
ii  python-pysqlite2  2.6.0-1Python interface to SQLite 3
ii  python-rsvg   2.30.0-4   Python bindings for the RSVG libra

pychess recommends no packages.

pychess suggests no packages.

-- no debconf information


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

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

Versions of packages pychess depends on:
ii  gnome-icon-theme  2.30.3-2   GNOME Desktop icon theme
ii  python2.6.6-3+squeeze7   interactive high-level object-orie
ii  python-cairo  1.8.8-1+b1 Python bindings for the Cairo vect
ii  python-central0.6.16+nmu1register and build utility for Pyt
ii  python-glade2 2.17.0-4   GTK+ bindings: Glade support
ii  python-gobject2.21.4+is.2.21.3-1 Python bindings for the GObject li
ii  python-gst0.100.10.19-1  generic media-playing framework (P
ii  python-gtk2   2.17.0-4   Python bindings for the GTK+ widge
ii  python-gtksourceview2 2.10.1-1   Python bindings for the GtkSourceV
ii  python-pysqlite2  2.6.0-1Python interface to SQLite 3
ii  python-rsvg   2.30.0-4   Python bindings for the RSVG libra

pychess recommends no packages.

pychess suggests no packages.

-- no debconf information
20:02:28 Default Warning: Engine crafty failed discovery: 
20:02:28 ('Crafty', '20:02:28.089') Warning: Chan closed for 'nopost'
20:02:28 ('Crafty', '20:02:28.089') Warning: Chan closed for '\n'
Traceback (most recent call last):
  File "/usr/lib/python2.6/dist-packages/pychess/widgets/ionest.py", line 47, 
in onPublished
gamenanny.nurseGame(gmwidg, game)
  File "/usr/lib/python2.6/dist-packages/pychess/widgets/gamenanny.py", line 
38, in nurseGame
on_game_started(gamemodel, gmwidg)
  File "/usr/lib/python2.6/dist-packages/pychess/widgets/gamenanny.py", line 
166, in on_game_started
preferencesDialog.SoundTab.playAction("gameIsSetup")
  File "/usr/lib/python2.6/dist-packages/pychess/widgets/preferencesDialog.py", 
line 291, in playAction
cls.getPlayer().play(uri)
  File "/usr/lib/python2.6/dist-packages/pychess/widgets/preferencesDialog.py", 
line 271, in getPlayer
cls._player = gstreamer.Player()
  File "/usr/lib/python2.6/dist-packages/pychess/System/gstreamer.py", line 31, 
in __init__
self.player = gst.element_factory_make("playbin")
gst.ElementNotFoundError: playbin
Exception AttributeError: "'Player' object has no attribute 'player'" in > ignored
Traceback (most recent call last):
  File "/usr/lib/python2.6/dist-packages/pychess/System/glock.py", line 47, in 
handler
function(emitter, *extra)
  File "/usr/lib/python2.6/dist-packages/pychess/widgets/BoardView.py", line 
186, in game_changed
preferencesDialog.SoundTab.playAction(sound)
  File "/usr/lib/python2.6/dist-packages/pychess/widgets/preferencesDialog.py", 
line 291, in playAction
cls.getPlayer().play(uri)
  File "/usr/lib/python2.6/dist-packages/pychess/widgets/preferencesDialo

Bug#701189: linux-image-3.7-trunk-amd64: 3.7.8 locks up occasionally

[Christian Ohm]

> On Monday, 25 February 2013 at  4:10, Ben Hutchings wrote:
> > Instead of updating to 3.7.9, I'll be uploading 3.8 to experimental
> > shortly.  Could you report whether that is more stable, once you've used
> > it for a while?

So far, I've had two more hangs under 3.7, but in general it was pretty
ok. 3.8 didn't hang in the short time I tried it, but it lost the
network card pretty soon after booting, spamming the kernel log with
lots of "atl1c :02:00.0: PCI-DMA: Out of IOMMU space for 1522 bytes"
(with different sizes). Google gives
https://bugzilla.redhat.com/show_bug.cgi?id=918393 which indicates that
the just released kernel 3.8.4 includes a fix for that. I've also found
https://www.kernel.org/pub/linux/kernel/projects/backports/stable/v3.8/ChangeLog-3.8-1
saying "2) PCI dma mapping errors in atl1c are not checked for and this
cause hard crashes for some users, from Xiong Huang." which seems to be
the cause of the broken network, and also might be a fix for the hangs
in 3.7.

Best regards,
Christian Ohm


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

Bug#694870: Bug#699109: unblock (pre-approval): initramfs-tools-tcos/0.89.91

[Mario Izquierdo]

El mié, 20-03-2013 a las 00:00 +, Jonathan Wiltshire escribió:
> user release.debian@packages.debian.org
> usertag 699109 + wheezy-will-remove
> usertag 694870 + wheezy-will-remove
> thanks
> 
> On Fri, Mar 01, 2013 at 02:14:58PM +0100, Julien Cristau wrote:
> > On Mon, Jan 28, 2013 at 09:22:35 +, Manuel A. Fernandez Montecelo wrote:
> > 
> > > 2013/1/27 Julien Cristau :
> > > > On Sun, Jan 27, 2013 at 17:42:48 +, Manuel A. Fernandez Montecelo 
> > > > wrote:
> > > >>
> > > >> Could Release Team please say if the changes proposed in #694870 to
> > > >> fix an RC bug are OK to go?
> > > >>
> > > > Please include an actual diff in this bug instead of a pointer to
> > > > $somewhere_else.
> > > 
> > > Attached.
> > > 
> > > According to the discussion in that bug report, the patch does need to
> > > be so big to fix three separate issues, and without the fixes it seems
> > > that the software will not be functional.
> > > 
> > I'm not overly happy with this patch.  The multiarch "fixes" just
> > hardcode two paths in an arch:all package with no apparent x86
> > dependency.  And the /etc/console-setup stuff looks like it'd break if
> > two files match the glob.  I'm more tempted by a removal at this point
> > to be honest.
> 
> Is there any progress on this? With a low popcon, maintainer seemingly
> unresponsive, RC buggy and never in a stable release, please note that
> removal will happen in a few days if this can't be resolved a better way.
> 
> Thanks,
> 

Thanks for CC me in this last email, I don't know any of this bug
comments.


I attach a new patch with a better multiarch and console-setup hacks


If you still want to remove from wheezy, not agree but ok for me, Ubuntu
have TCOS since 12.04 and I would be very disappointed that Debian not.


Best regards

--
Mario

diff --git a/bin/gentcos b/bin/gentcos
index 4999489..e1f5174 100755
--- a/bin/gentcos
+++ b/bin/gentcos
@@ -29,8 +29,10 @@ fi
 
 # Multiarch DIR
 LIB_MULTIARCH=/usr/lib/
-[ -e /usr/lib/i386-linux-gnu   ] && LIB_MULTIARCH=/usr/lib/i386-linux-gnu/
-[ -e /usr/lib/x86_64-linux-gnu ] && LIB_MULTIARCH=/usr/lib/x86_64-linux-gnu/
+DEB_HOST_MULTIARCH=$(dpkg-architecture -qDEB_HOST_MULTIARCH 2>&1)
+if [ -n "$DEB_HOST_MULTIARCH" ] && [ -e "/usr/lib/$DEB_HOST_MULTIARCH" ]; then
+  LIB_MULTIARCH="/usr/lib/$DEB_HOST_MULTIARCH"
+fi
 export LIB_MULTIARCH
 
 . /etc/tcos/tcos.conf
@@ -466,14 +468,10 @@ check_modules() {
if [ "$(echo $_module | awk -F "|" '{print $2}')" != "" ]; then
  for _mod in $(echo $_module | sed 's/|/ /g'); do
#_echo "searching for module $_mod"
-   have_one_module=$(modprobe --set-version="${TCOS_KERNEL}" -l ${_mod} | wc -l)
-   if [ ${have_one_module} != 0 ]; then
-  #_echo "have $_mod !!!"
-  have_module=1
-   fi
+   tcos_find_module "${_mod}" && have_module=1
  done
else
- have_module=$(modprobe --set-version="${TCOS_KERNEL}" -l ${_module} | wc -l)
+ tcos_find_module "${_module}" && have_module=1
fi
 
if [ ${have_module} = 0 ] ; then
diff --git a/bin/tcos-buildchroot b/bin/tcos-buildchroot
index 3afc892..8d6450c 100755
--- a/bin/tcos-buildchroot
+++ b/bin/tcos-buildchroot
@@ -179,13 +179,13 @@ chrootcreate() {
 --divert /usr/sbin/invoke-rc.d.original \
 /usr/sbin/invoke-rc.d
 
-  # avoid calling udevadm inside chroot
-  # http://bugs.debian.org/627790
-  chroot ${TCOS_CHROOT} dpkg-divert --package initramfs-tools-tcos \
---add --rename --quiet \
---divert /sbin/udevadm.original \
-/sbin/udevadm
-  createEmptyCMD /sbin/udevadm
+#  # avoid calling udevadm inside chroot
+#  # http://bugs.debian.org/627790
+#  chroot ${TCOS_CHROOT} dpkg-divert --package initramfs-tools-tcos \
+#--add --rename --quiet \
+#--divert /sbin/udevadm.original \
+#/sbin/udevadm
+#  createEmptyCMD /sbin/udevadm
 
 
   cat << EOF > ${TCOS_CHROOT}/etc/apt/apt.conf
@@ -282,23 +282,24 @@ cat /etc/resolv.conf > ${TCOS_CHROOT}/etc/resolv.conf
 [ ! -e ${TCOS_CHROOT}/sbin/start-stop-daemon ] &&   createEmptyCMD /sbin/start-stop-daemon
 [ ! -e ${TCOS_CHROOT}/usr/sbin/invoke-rc.d ] && createEmptyCMD /usr/sbin/invoke-rc.d
 
-if [ ! -e /sbin/udevadm.original ]; then
-  chroot ${TCOS_CHROOT} dpkg-divert --package initramfs-tools-tcos \
---add --rename --quiet \
---divert /sbin/udevadm.original \
-/sbin/udevadm
-  createEmptyCMD /sbin/udevadm
-fi
+#if [ ! -e /sbin/udevadm.original ]; then
+#  chroot ${TCOS_CHROOT} dpkg-divert --package initramfs-tools-tcos \
+#--add --rename --quiet \
+#  

Bug#702102:

[Simon Chopin]

For those who like me are (were) testing systemd, reverting to the default
init (SysV) in testing/unstable would also work around this problem.



signature.asc
Description: signature

Bug#628996: apt-listbugs: please use debconf [was: Bug#628996: Bug#671726: Bug#671728: Bug#671726: apt: should be able to provide hook information through a named pipe]

[Francesco Poli]

On Tue, 19 Mar 2013 21:03:28 +0100 Serafeim Zanikolas wrote:

[...]
> I think technical minded users would appreciate the same level of options
> currently provided by apt-get ran as root, ie. to be able to upgrade selected
> RC-buggy packages while pinning others.

To me, it is of paramount importance to refrain from removing features
or flexibility from apt-listbugs.
In other words, I agree with you: let's not disappoint power users, in
order to become friendlier to newbies!

> 
> Less savvy users (eg. someone who can't tell the different between
> a DFSG-violation and system-wide breakage) would be served best by upgrading
> all upgrade-able packages except for those that are RC-buggy.  In practise,
> this means pinning any RC-buggy packages (what the patch for #441689 does) and
> proceeding with the upgrade (after an apt-get re-invocation, or whatever
> action is required for the pinning to become effective).

Yes, this looks like a possible use case.

> 
> Do you agree about these use cases or do you have others to suggest as more
> important?

Nothing else comes to my mind for the time being.
Anyway, if we manage to add features, without removing previously
implemented ones, we should automatically preserve existing use cases
(even those we are not aware of!).

> 
> Back to mechanics:
> 
> The current non-interactive default (with --force-no) of aborting the whole
> upgrade in the face of any RC bug means that users are denied of (potentially
> security-critical) updates to packages that are safely upgrade-able. I
> consider this unacceptable if we're serious about supporting Debian testing.

It's definitely sub-optimal: personally, I would not use apt-listbugs
that way, but, after all, I don't consider myself to be a total
newbie... This brings us back to the above distinction between more and
less sophisticated use cases. 

> 
> Severity based filtering (-s) seems meaningless to me. I'd never do blind
> upgrades based on a "ignore bugs up to X severity" policy, because that
> doesn't say anything about the packages and package features that I rely on as
> a user.

Please note that the current apt-listbugs default behavior is to ignore
any non-RC bug. I consider this to be a reasonable default, especially
taking into account that the behavior may be configured differently by
the user.


-- 
 http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt
 New GnuPG key, see the transition document!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgp2tBmxK7DwS.pgp
Description: PGP signature

Bug#703559: libc6-dev: sparc: no prototype for prlimit

[Emilio Pozuelo Monfort]

Package: libc6-dev
Version: 2.13-38
Severity: important

glibc doesn't provide a prototype for prlimit in sparc. It probably
should as it implements that function.

This currently makes glib2.0 fail to build:
https://buildd.debian.org/status/fetch.php?pkg=glib2.0&arch=sparc&ver=2.35.9-1&stamp=1363706912

Emilio


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

Bug#702671: please make missing-debian-source-format proper W

[Russ Allbery]

"Bernhard R. Link"  writes:
> * Niels Thykier  [130320 16:25]:

>> As I recall, when d/s/format was advertised as "soon-to-be-mandatory"
>> it caused quite a riot among some people.  Do we have any reason to
>> believe that has changed since then?

> Making this file mandatory is the only sensible thing to do in the long
> run. It immensly helps new maintainers not suddently ending up with
> non-native packages without .orig.tar and other absurdities. And it
> comes with no measurable cost to people wanting to keep their packages
> the legacy 1.0 format.

I agree, but that's not really the point -- the point, rather, was that
several long-time DDs responded to the suggestion that it become mandatory
with quite a bit of outrage in debian-devel, and several people said that
they absolutely refused to add it.

Hopefully that's all blown over now.

> So what route to suggest then.

Bring it up on debian-devel again.  If it doesn't provoke the same
reaction it did last time, I think we can bump the tag severity.  It would
just be nice to have a general project discussion about it first, rather
than having it appear to be a one-sided initiative on the part of Lintian.

Now is probably not the greatest time, though.  Everyone's touchier during
the tail end of the release freeze.

-- 
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#702102: Acknowledgement (fails to upgrade (cowbuilder) chroot)

[Chris Knadle]

On Wednesday, March 20, 2013 15:25:26, Michael Biebl wrote:
> from IRC:
> 
>  i ran into that one today, i think.  had to set a variable in
> pbuilderrc to tell it to not bother mounting shm
>  iirc it tries to check whether /run/shm exists on the host to
> decide whether to use /dev/shm or /run/shm in the chroot
>  which makes no sense at all
> 
> 
> That's the problem indeed. I don't have /run/shm (but /dev/shm), and
> pbuilder trips over that.

Symptoms match: I have /run/shm as well as /dev/shm, and both directories seem 
bound together.

  -- Chris

--
Chris Knadle
chris.kna...@coredump.us


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

Bug#703558: ITP: ruby-oj -- fast JSON parser and serializer for Ruby

[Cédric Boutillier]

Package: wnpp
Severity: wishlist
Owner: "Cédric Boutillier" 

* Package name: ruby-oj
  Version : 2.0.9
  Upstream Author : Peter Ohler 
* URL : https://github.com/ohler55/oj
* License : BSD-3-clause
  Programming Lang: Ruby
  Description : fast JSON parser and serializer for Ruby

 JSON (or JavaScript Object Notation) is a text-based open standard designed
 for human-readable data interchange.
 .
 Oj (Optimized JSON) is a Ruby library written to provide speed optimized
 handling of JSON, for parsing JSON and serializing objects.

This package is part of the packaging effort for diaspora, and will be
maintained in the Ruby Extras team.

Cheers,

Cédric


signature.asc
Description: Digital signature

Bug#703146: #703146 release critical?

[Holger Levsen]

Hi Christian,

On Mittwoch, 20. März 2013, Christian PERRIER wrote:
> I have an upload ready that includes MIchael Vogt's patch and moves
> gpg from Recommends to Depends.

does it include the -f option as needed for live-$something? (see this bugs 
log)

> Please object if I shouldn't upload.
> 
> This upload allows pbuilder to build a build chroot, so it seems fine,
> but, not being a wizard with debootstrap and archive stuff, I'd
> appreciate someone to confirm that fixing this is OK and fixing it the
> way it has been proposed in #703146 is OK too.

a debdiff to the version in wheezy would have been nice :)


cheers,
Holger


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

Bug#703556: tircd: depends on libnet-twitter-lite-perl, removal likely

[Michael Stapelberg]

Hi Jonathan,

Jonathan Wiltshire  writes:
> As your package depends on it, tircd would also be removed at the same time.
Given that tircd seems dead upstream, please feel free to remove tircd
from Debian.

-- 
Best regards,
Michael


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

Bug#703554: mysql-query-browser: Dependency on libgtkhtml3.14-19 in wheezey breaks package

[Adam Majer]

close 703554
done

On Wed, Mar 20, 2013 at 03:07:45PM -0500, Karl Schmidt wrote:
> Package: mysql-query-browser
> Version: 5.0r14+openSUSE-2.1
> Severity: normal
> 
> Pulling in the older version from squeeze fixes the install.  This
> might be a packaging error?

This package does not exist anymore. It was pulled from the archive as
it is replaced by mysql-workbench.

Please update to mysql-workbench if you update to Wheezy.

- Adam



-- 
Adam Majer
ad...@zombino.com


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

Bug#703146: #703146 release critical?

[Christian PERRIER]

Quoting Christian PERRIER (bubu...@debian.org):
> I just installed a new wheezy machine as my brand new "garage" build
> server and got hit by  #703146. No way to create cowbuilder/pbuilder
> chroots.
> 
> 
> The patch in #703146 does indeed fix the issue.
> 
> Shouldn't this definitely go in wheezy?

I have an upload ready that includes MIchael Vogt's patch and moves
gpg from Recommends to Depends.

Please object if I shouldn't upload.

This upload allows pbuilder to build a build chroot, so it seems fine,
but, not being a wizard with debootstrap and archive stuff, I'd
appreciate someone to confirm that fixing this is OK and fixing it the
way it has been proposed in #703146 is OK too.



signature.asc
Description: Digital signature

Bug#703458: pu: package clamav/0.97.7+dfsg-1~squeeze1

[Scott Kitterman]

"Adam D. Barratt"  wrote:

>Control: tags -1 + confirmed squeeze
>
>On Tue, 2013-03-19 at 17:38 -0400, Scott Kitterman wrote:
>> I'd like to upload clamav 0.97.7 for all the same reasons (and with
>the same
>> diff modulo a slightly different debian/changelog entry) as I wanted
>it in
>> Wheezy (See #703391: unblock: clamav/0.97.7+dfsg-1).
>
>Please go ahead; thanks.
>
>I'm guessing you'd like to see this hit stable-updates as well (once
>0.97.7 migrates to testing)?
>
Yes.  Thanks. 

Scott K


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

Bug#702486: libnet-twitter-perl: version 4.x required for new Twitter API

[Jonathan Wiltshire]

On Sun, Mar 17, 2013 at 08:25:51PM +, Dominic Hargreaves wrote:
> On Thu, Mar 07, 2013 at 07:49:56PM +0100, Salvatore Bonaccorso wrote:
> > Control: clone 702486 -1
> > Control: reassign -1 libnet-twitter-lite-perl
> > Control: retitle -1 libnet-twitter-perl: needs update for new Twitter API
> > 
> > On Thu, Mar 07, 2013 at 07:28:50AM +0100, Ansgar Burchardt wrote:
> > > Package: libnet-twitter-perl
> > > Severity: grave
> > > 
> > > Let's turn this into a proper bug report:
> > > 
> > > Patrick Brewer  writes:
> > > > For those using Net:Twitter the latest version of the lib is needed
> > > > ASAP.  Twitter is turning off their old API sometime this month
> > > > (official date was yesterday).  A version of the module in 4.x is
> > > > required for the new API.  The very latest I can find for debian is
> > > > 3.18003 here: http://packages.debian.org/sid/libnet-twitter-perl
> > 
> > Cloning this for libnet-twitter-lite-perl as support for Twitter API
> > 1.1 was also only introduced in Net::Twitter::Lite in
> > 
> > 0.12000 2013-03-04
> > - URI encode POSTDATA to match Twitter's more stringent (non-standard) 
> > requirements
> > - created Net::Twitter::Lite::WithAPIv1_1 for Twitter API v1.1 support
> 
> This is now fixed for libnet-twitter-lite-perl in experimental.
> 
> Release team: the old API from twitter is very close to going away;
> https://dev.twitter.com/blog/api-v1-retirement-update
> 
> and new upstream releases of both Net::Twitter and Net::Twitter::Lite
> are needed to allow continued usage of these modules.
> 
> The upstream diffs are quite large:
> 
> https://metacpan.org/diff/release/MMIMS/Net-Twitter-Lite-0.11002/MMIMS/Net-Twitter-Lite-0.12000
> 
> https://metacpan.org/diff/release/MMIMS/Net-Twitter-3.18003/MMIMS/Net-Twitter-4.3
> 
> but the alternative is probably removing both from wheezy (and squeeze).
> 
> FWIW, there's a (somewhat sloppy, to be tidied up) backport of
> Net::Twitter::Lite 0.11002 for squeeze at
> 
> http://anonscm.debian.org/gitweb/?p=pkg-perl/packages/libnet-twitter-lite-perl.git;a=shortlog;h=refs/heads/experimental-squeeze
> 
> Thoughts: new upstream releases; remove; something else?

I'm tending towards removal, sadly. The upstream diff is indeed rather
large and at this stage, rather unwieldy. I realise lots of it is
refactoring, but the functional changes would normally rule this out for an
unblock.

There is a reverse dependency to consider, I just opened a bug to get
Michael's comments.

libnet-twitter-perl has no reverses.

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

 i have six years of solaris sysadmin experience, from
8->10. i am well qualified to say it is made from bonghits
layered on top of bonghits


signature.asc
Description: Digital signature

Bug#703557: opensc: pls update to 0.13.0

[stef]

Package: opensc
Version: 0.12.2-3
Severity: wishlist
Tags: upstream

A new was released on 04.12.2012.
thanks for packaging!

-- System Information:
Debian Release: 7.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (x86_64)

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

Versions of packages opensc depends on:
ii  libc6 2.13-38
ii  libltdl7  2.4.2-1.2
ii  libreadline6  6.2+dfsg-0.1
ii  libssl1.0.0   1.0.1e-2
ii  zlib1g1:1.2.7.dfsg-13

opensc recommends no packages.

opensc 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#678979: request freeze exception for slony1-2

[Peter Eisentraut]

On 3/19/13 2:48 PM, Steve Singer wrote:
> Since the original bug was opened we've figured out why adding PG 9.1
> support to slony 2.0.x was causing occasional test failures.
> 
> The fixes for PG 9.1 (upstream bugs #255) along with the fixes for the
> MOVE SET issue caused by the #255 fix (upstream bug #285) I think will
> produce a working slony 2.0.x against 9.1.
> 
> If Debian would like I can assemble assemble these two patches and run
> it through the testing suite.

Sure, if it's only two isolated patches that upstream is endorsing, we
can give this a try.


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