Bug#754643: gradle: FTBFS: Caused by: java.lang.RuntimeException: Could not determine the local IP addresses for this machine.
On Mon, 14 Jul 2014 23:07:34 -0700, tony mancill wrote:
> On 07/12/2014 08:21 PM, Miguel Landaeta wrote:
> > I'm unable to run gradle in a clean cowbuilder chroot. It dies on me
> > with a java.lang.RuntimeException error.
> > FAILURE: Build failed with an exception.
> > * What went wrong:
> > Execution failed for task ':compileGroovy'.
> >> Could not determine the local IP addresses for this machine.
> Is it possible that it's trying to make a connection to your X server?
(Without having looked at the package:)
Maybe this is yet another instance of #753944
("pbuilder: USENETWORK=no breaks package builds").
Cheers,
gregor
--
.''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
: :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/
`. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
`- BOFH excuse #426: internet is needed to catch the etherbunny
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#751929: gdb-doc uninstallable on Jessie alongside gdb and or gdbserver
Dear Maintainer, +1 here. I'm not acquainted with the Debian policies but I don't understand why a doc-only package should have a `break' directive. It makes an importart piece of software (`gdb') uninstallable. Thank you Emílio -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash -- 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#754655: polarssl: CVE-2014-4911: Denial of Service against GCM enabled servers and clients
Hi,
Attached is a (not-yet tested) proposed debdiff for wheezy-security.
Regards,
Salvatore
diff -Nru polarssl-1.2.9/debian/changelog polarssl-1.2.9/debian/changelog
--- polarssl-1.2.9/debian/changelog 2014-02-25 20:46:03.0 +0100
+++ polarssl-1.2.9/debian/changelog 2014-07-15 06:52:47.0 +0200
@@ -1,3 +1,12 @@
+polarssl (1.2.9-1~deb7u3) wheezy-security; urgency=high
+
+ * Non-maintainer upload by the Security Team.
+ * Add CVE-2014-4911.patch patch.
+CVE-2014-4911: Fix Denial of Service against GCM enabled servers (and
+clients). (Closes: #754655)
+
+ -- Salvatore Bonaccorso Tue, 15 Jul 2014 06:39:38 +0200
+
polarssl (1.2.9-1~deb7u2) stable-proposed-updates; urgency=medium
* Fix FTBFS bug due to expired certificates, backport from upstream 1.3.4,
diff -Nru polarssl-1.2.9/debian/patches/CVE-2014-4911.patch
polarssl-1.2.9/debian/patches/CVE-2014-4911.patch
--- polarssl-1.2.9/debian/patches/CVE-2014-4911.patch 1970-01-01
01:00:00.0 +0100
+++ polarssl-1.2.9/debian/patches/CVE-2014-4911.patch 2014-07-15
06:52:47.0 +0200
@@ -0,0 +1,43 @@
+Description: Fix CVE-2014-4911
+ Denial of Service against GCM enabled servers (and clients)
+Origin: upstream,
https://github.com/polarssl/polarssl/commit/5bad6afd8c72b2c3a6574dff01ca5f8f2f04800a
+Bug-Debian: https://bugs.debian.org/754655
+Forwarded: not-needed
+Author: Salvatore Bonaccorso
+Last-Update: 2014-07-14
+Applied-Upstream: 1.2.11
+
+--- a/library/ssl_tls.c
b/library/ssl_tls.c
+@@ -1237,6 +1237,9 @@ static int ssl_decrypt_buf( ssl_context
+ size_t dec_msglen;
+ unsigned char add_data[13];
+ int ret = POLARSSL_ERR_SSL_FEATURE_UNAVAILABLE;
++unsigned char taglen = 16;
++unsigned char explicit_iv_len = ssl->transform_in->ivlen -
++ssl->transform_in->fixed_ivlen;
+
+ #if defined(POLARSSL_AES_C) && defined(POLARSSL_GCM_C)
+ if( ssl->session_in->ciphersuite == TLS_RSA_WITH_AES_128_GCM_SHA256 ||
+@@ -1244,11 +1247,16 @@ static int ssl_decrypt_buf( ssl_context
+ ssl->session_in->ciphersuite ==
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 ||
+ ssl->session_in->ciphersuite ==
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 )
+ {
+-dec_msglen = ssl->in_msglen - ( ssl->transform_in->ivlen -
+-ssl->transform_in->fixed_ivlen );
+-dec_msglen -= 16;
+-dec_msg = ssl->in_msg + ( ssl->transform_in->ivlen -
+- ssl->transform_in->fixed_ivlen );
++if( ssl->in_msglen < explicit_iv_len + taglen )
++{
++ SSL_DEBUG_MSG( 1, ( "msglen (%d) < explicit_iv_len (%d) "
++ "+ taglen (%d)", ssl->in_msglen,
++ explicit_iv_len, taglen ) );
++ return( POLARSSL_ERR_SSL_INVALID_MAC );
++}
++dec_msglen = ssl->in_msglen - explicit_iv_len - taglen;
++
++dec_msg = ssl->in_msg + explicit_iv_len;
+ dec_msg_result = ssl->in_msg;
+ ssl->in_msglen = dec_msglen;
+
diff -Nru polarssl-1.2.9/debian/patches/series
polarssl-1.2.9/debian/patches/series
--- polarssl-1.2.9/debian/patches/series2014-02-16 12:14:44.0
+0100
+++ polarssl-1.2.9/debian/patches/series2014-07-15 06:52:47.0
+0200
@@ -2,3 +2,4 @@
02-makefile-destdir-fix.patch
03-library-makefile-adjustments.patch
04-update-certs-in-testsuite.patch
+CVE-2014-4911.patch
Bug#728280:
Bug#754643: gradle: FTBFS: Caused by: java.lang.RuntimeException: Could not determine the local IP addresses for this machine.
On 07/12/2014 08:21 PM, Miguel Landaeta wrote: > Package: src:gradle > Version: 1.5-1 > Severity: serious > Justification: fails to build from source (but built successfully in the past) > > I'm unable to run gradle in a clean cowbuilder chroot. It dies on me > with a java.lang.RuntimeException error. > > Since gradle build-depends on itself this is a FTBFS bug. > This doesn't happen when I run it outside a chroot. > > Relevant error message: > > [snip] > > fakeroot debian/rules clean > dh clean --with javahelper >dh_testdir >debian/rules override_dh_auto_clean > make[1]: Entering directory '/tmp/buildd/gradle-1.5' > dh_auto_clean > gradle --project-prop finalRelease=true --stacktrace --offline clean > :buildSrc:clean UP-TO-DATE > :buildSrc:compileJava UP-TO-DATE > :buildSrc:compileGroovy FAILED > > FAILURE: Build failed with an exception. > > * What went wrong: > Execution failed for task ':compileGroovy'. >> Could not determine the local IP addresses for this machine. Hi Miguel, Is it possible that it's trying to make a connection to your X server? When I try to build in a chroot from a shell where DISPLAY is set, the build dies with an error that it cannot connect to :0. But if I unset DISPLAY before starting the build, it completes successfully (3x in a row now). I haven't looked into it in more depth, but maybe the build can just unset DISPLAY? Cheers, tony signature.asc Description: OpenPGP digital signature
Bug#601504:
I don't know
Bug#753444: Bug#753542: Bug#753444: Bug#753542: perl-base - Segfaults in libperl.so.5.18
On 14/07/14 23:17, Niko Tyni wrote:
> On Mon, Jul 14, 2014 at 09:34:35AM +0200, Emilio Pozuelo Monfort wrote:
>> On 14/07/14 09:05, Niko Tyni wrote:
>
>>> So can I go ahead with dropping perlapi-5.18.2 or do we need to dig in
>>> the libimager-perl/libpng problem first?
>>
>> If you're ok with removing libimager-perl, libimager-qrcode-perl and
>> libmojomojo-perl from testing if those don't get fixed in time, then yes.
>
>> As for sereal, we'd need to remove libsereal-{en,de}coder-perl,
>> libsession-storage-secure-perl and libdancer-session-cookie-perl.
>
> The libimager-perl/libpng thing looks thorny enough that I don't
> think we should wait for that. The libsereal-encoder-perl package
> has been failing on s390x for a long time, if it has to be removed
> then so be it.
>
> I've just uploaded perl_5.18.2-7 providing only perlapi-5.18.2d on s390x
> and closing this bug (#753444).
Sounds good, thanks for your work!
Emilio
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#754853: dnssec-trigger: NetworkManager script fails to parse nmcli version as of 0.9.10.0
Package: dnssec-trigger
Version: 0.13~svn683-2
Severity: normal
Tags: patch
Dear Maintainer,
After upgrading package network-manager in jessie (0.9.8.10-4 →
0.9.10.0-1), the dnssec-trigger NetworkManager hook script fails with
the following output:
Jul 14 22:09:30 p4xb3k nm-dispatcher[14902]:
/etc/NetworkManager/dispatcher.d/01-dnssec-trigger: 55: [: nmcli: unexpected
operator
Jul 14 22:09:30 p4xb3k nm-dispatcher[14902]:
/etc/NetworkManager/dispatcher.d/01-dnssec-trigger: 1:
/etc/NetworkManager/dispatcher.d/01-dnssec-trigger: nm-tool: not found
I see three problems:
Unquoted [ -n $foo ] vs. [ -n "$foo" ];
The fallback on nm-tool fails now that the binary was removed from
0.9.10.0-1;
The regex used in `nmcli -v | sed` doesn't work with multi-digit
revision numbers >= 10 (the "10" is too wide), as in "0.9.10.0", note
that the trailing revision number (the z in w.x.y.z) is simply
truncated, so it used to work in "0.9.8.10" (truncated to "0.9.8.1");
Attached patch fixes those problems, as long as revision numbers are <=
999, and they don't change from w.x.y.z format, kludgy stuff!
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.14-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages dnssec-trigger depends on:
ii init-system-helpers 1.19
ii libc62.19-7
ii libgdk-pixbuf2.0-0 2.30.7-1
ii libglib2.0-0 2.40.0-3
ii libgtk2.0-0 2.24.24-1
ii libldns1 1.6.17-4
ii libssl1.0.0 1.0.1h-3
ii python 2.7.6-2
ii unbound 1.4.22-1
dnssec-trigger recommends no packages.
dnssec-trigger suggests no packages.
-- Configuration Files:
/etc/NetworkManager/dispatcher.d/01-dnssec-trigger changed [not included]
-- no debconf information
--
Gerald Turner Encrypted mail preferred!
OpenPGP: 4096R / CA89 B27A 30FA 66C5 1B80 3858 EC94 2276 FDB8 716D
diff -ur dnssec-trigger-0.13~svn683.orig/01-dnssec-trigger.in dnssec-trigger-0.13~svn683/01-dnssec-trigger.in
--- dnssec-trigger-0.13~svn683.orig/01-dnssec-trigger.in 2014-07-14 22:24:40.0 -0700
+++ dnssec-trigger-0.13~svn683/01-dnssec-trigger.in 2014-07-14 22:26:51.437356743 -0700
@@ -50,11 +50,11 @@
#
# get global nameservers
# try to get nmcli version
-NMCLI_VER="`nmcli -v 2> /dev/null | sed 's/.*version \([0-9]\)\.\([0-9]\)\.\([0-9]\)\.\([0-9]\).*/\1\2\3\4/'`"
+NMCLI_VER=$(printf '%03d%03d%03d%03d\n' $(nmcli -v 2>/dev/null | sed 's/.*version \([0-9]\+\)\.\([0-9]\+\)\.\([0-9]\+\)\.\([0-9]\+\).*/\1 \2 \3 \4/'))
# if nmcli exists
-if [ -n $NMCLI_VER ]; then
+if [ -n "$NMCLI_VER" ]; then
# if the version is greater or equal 0.9.9.0
-if [ $NMCLI_VER -ge 0990 ]; then
+if [ $NMCLI_VER -ge 09009000 ]; then
global_nameservers="`nmcli -f IP4,IP6 dev show | fgrep 'DNS' | awk '{print $2;}'`"
else
global_nameservers="`nmcli -f IP4,IP6 dev list | fgrep 'DNS' | awk '{print $2;}'`"
pgpHRuddyrLSC.pgp
Description: PGP signature
Bug#754852: nfs-utils: contains amd64 binaries (.o, .a, etc.)
Source: nfs-utils Version: 1:1.2.8-6 Severity: normal Hi folks, > $ pwd > /home/jon/tmp/nfs-utils-1.2.8 > $ find . -name '*.o' -o -name '*.a' | wc -l > 113 This is inherited from upstream's tarball and doesn't appear to be replicated in your git repository (that is: you've imported upstream's source from their repository and that doesn't have the object files committed: but you've uploaded their prepared orig tarball which does). -- System Information: Debian Release: 7.5 APT prefers stable APT policy: (700, 'stable'), (600, 'unstable') Architecture: i386 (i686) Kernel: Linux 3.9.2-x86-linode51 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages nfs-common depends on: ii adduser 3.113+nmu3 ii initscripts 2.88dsf-41+deb7u1 ii libc6 2.13-38+deb7u1 ii libcap2 1:2.22-1.2 ii libcomerr2 1.42.5-1.1 ii libdevmapper1.02.1 2:1.02.74-8 ii libevent-2.0-5 2.0.19-stable-3 ii libgssglue1 0.4-2 ii libk5crypto31.10.1+dfsg-5+deb7u1 ii libkeyutils11.5.5-3 ii libkrb5-3 1.10.1+dfsg-5+deb7u1 ii libmount1 2.20.1-5.3 ii libnfsidmap20.25-4 ii libtirpc1 0.2.2-5 ii libwrap07.6.q-24 ii lsb-base4.1+Debian8+deb7u1 ii rpcbind 0.2.0-8 ii ucf 3.0025+nmu3 Versions of packages nfs-common recommends: ii python 2.7.3-4+deb7u1 Versions of packages nfs-common suggests: pn open-iscsi pn watchdog -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#747468: Thanks
Hi, Thanks for the patch. I'll apply it to the next release of src:mpclib3 (which obsoletes src:mpclib). Laurent.
Bug#754706: [initramfs-tools] It is impossible configure initramfs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The package live-boot-initramfs-tools is not installed in my computer. Il 13/07/2014 19:11, Ben Hutchings ha scritto: > Control: reassign -1 live-boot-initramfs-tools > > On Sun, 2014-07-13 at 16:43 +0200, Marco Righi wrote: >> Package: initramfs-tools Version: 0.115 Severity: important >> >> --- Please enter the report below this line. --- Hi, after hfs >> utility (using synaptyc tool) I noticed some problem with the >> package initramfs-tools. It does not finish its own >> configuration. >> >> The complete error (in Italian, it is my default language) is: >> >> Command 523 of 24 #dpkg --configure -a >> >> >> Configurazione di initramfs-tools (0.115)... update-initramfs: >> deferring update (trigger activated) Elaborazione dei trigger per >> initramfs-tools (0.115)... update-initramfs: Generating >> /boot/initrd.img-3.14-1-amd64 cp: impossibile eseguire stat di >> "/lib/libacl*": File o directory non esistente E: >> /usr/share/initramfs-tools/hooks/live failed with return 1. > ^^ > > The bug is not in the initramfs-tools package, but in file which is > part of live-boot-initramfs-tools. > > Ben. > - -- Think Marco, think different web site:http://www.di.unipi.it/~righi/ -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlPEvMcACgkQ4+L/eCZYK/wYZwCgjNkz9kDU38tkAm2yjL7ket1l 7VQAoJoMB8FqDoCZItoYD/f91xk2zRT4 =Z/3D -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#753500: RM: movabletype-opensource/4.3.8+dfsg-0+squeeze4
On Mon, Jul 14, 2014 at 08:10:13PM +0100, Adam D. Barratt wrote: > Hi, > > On Wed, 2014-07-02 at 17:00 +0200, Moritz Muehlenhoff wrote: > > as briefly discussed on #debian-release. Please remove this package > > in the 6.0.10 point release. It's not covered by squeeze-lts support > > and debian-security-support marks existing packages as deprecated. > > How much were the decisions on what is (or, more to the point, isn't) > covered in -lts based on discussion with the maintainers? The list of unsupported packages was discussed on the debian-lts mailing list. E.g. the maintainer of movabletype took part in the discussion. > > Removing it ensures that new squeeze installations (which can still > > happen in some cases) odon't install an unsupported package. It make > > tracking open issues easier. And the binaries can still be fetched > > from snapshot.debian.org. > > I'm slightly in two minds about some of these, partly because some of > the packages have been getting updates during squeeze's lifetime. And they've all been EOLed for a reason. That we somehow managed to support some applications for three years doesn't mean the same applies to five years (e.g. typo3). Cheers, Moritz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#754851: duplicity: Fails with Unknown exception: Python int too large to convert to C long
Package: duplicity Version: 0.6.24-1 Severity: important Attempting to run duplicity at least with sftp backend fails with unhandled Python exception: $ duplicity -v 4 --volsize 50 --ssh-askpass /media/prj sftp://xxx@xxx/prj ssh: Unknown exception: Python int too large to convert to C long ssh: Traceback (most recent call last): ssh: File "/usr/lib/python2.7/dist-packages/paramiko/transport.py", line 1442, in run ssh: self._handler_table[ptype](self, m) ssh: File "/usr/lib/python2.7/dist-packages/paramiko/transport.py", line 1848, in _parse_channel_open_success ssh: server_window_size = m.get_int() ssh: File "/usr/lib/python2.7/dist-packages/paramiko/message.py", line 140, in get_int ssh: return util.inflate_long(self.get_binary()) ssh: File "/usr/lib/python2.7/dist-packages/paramiko/message.py", line 198, in get_binary ssh: return self.get_bytes(self.get_size()) ssh: File "/usr/lib/python2.7/dist-packages/paramiko/message.py", line 108, in get_bytes ssh: b = self.packet.read(n) ssh: OverflowError: Python int too large to convert to C long ssh: BackendException: sftp negotiation failed: Python int too large to convert to C long This is on a 32-bit Debian testing, if that matters. The issue appeared recently, possibly with Duplicity package upgrade to 0.6.24, but since the old 0.6.23 is no longer available for downgrading, I can't confirm if that is the cause. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.14.12-grsec-dc (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/bash Versions of packages duplicity depends on: ii libc62.19-5 ii librsync10.9.7-10 ii python 2.7.6-2 ii python-lockfile 1:0.8-2 Versions of packages duplicity recommends: pn python-oauthlib ii python-paramiko 1.14.0-2 pn python-urllib3 ii rsync3.1.0-3 Versions of packages duplicity suggests: ii lftp4.5.3-1 pn ncftp pn python-boto pn python-cloudfiles pn python-gdata pn python-swiftclient pn tahoe-lafs -- 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#750361: chromium: upstream dropped support for older i386 processors
Ignacio Areta wrote: > https://code.google.com/p/chromium/issues/detail?id=313032 > > Also reported at Debian... That bug probably will be back if you > bring non-SSE2 support back. > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741006 That bug is http://crbug.com/349543, with the most likely fix being http://crbug.com/349053. Relying on build flags to work around that is incredibly fragile. If you get a chance to work on one of those two bugs then I imagine upstream will be happy. In the meantime, if you want to avoid excess precision due to holding floating point values in registers, the flag for that is -ffloat-store. Thanks, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#750361: [Pkg-chromium-maint] Bug#750361: marked as done (chromium: upstream dropped support for older i386 processors)
Em 20-06-2014 20:54, Michael Gilbert escreveu: Please don't try to fix this. Chromium devs decided to drop SSE2 because it fixes other bugs, as you can see in the upstream bug which I linked previously (also see comment #25 from that bug). http://code.google.com/p/chromium/issues/detail?id=348761 This is about testing solutions for maintaining backwards compatibility between wheezy updates, which should retain a somewhat stable feature set even though google is adamantly against that. I'm not worried about google music bugs, re comment #25. Best wishes, Mike Nor the blocking bug? https://code.google.com/p/chromium/issues/detail?id=313032 Also reported at Debian... That bug probably will be back if you bring non-SSE2 support back. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741006 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#750361: [Pkg-chromium-maint] Bug#750361: marked as done (chromium: upstream dropped support for older i386 processors)
Em 20-06-2014 20:54, Michael Gilbert escreveu: Please don't try to fix this. Chromium devs decided to drop SSE2 because it fixes other bugs, as you can see in the upstream bug which I linked previously (also see comment #25 from that bug). http://code.google.com/p/chromium/issues/detail?id=348761 This is about testing solutions for maintaining backwards compatibility between wheezy updates, which should retain a somewhat stable feature set even though google is adamantly against that. I'm not worried about google music bugs, re comment #25. Best wishes, Mike Nor the blocking bug? https://code.google.com/p/chromium/issues/detail?id=313032 Also reported at Debian... That bug probably will be back if you bring non-SSE2 support back. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741006 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#754850: [Pkg-utopia-maintainers] Bug#754850: upower: no suspend/hibernate on non-systemd systems
reassign 754850 xfce4-session forcemerge 752425 754850 thanks Am 15.07.2014 02:49, schrieb Adam Borowski: > Package: upower > Version: 0.99.0-3 > Severity: important > > The newest update of upower (0.99.0-3) doesn't appear to be functional > anymore. As I'm on a desktop, this means suspend and hibernate (obviously, > there's no battery I could test). These functions don't even show up in > XFCE's logout menu. On the other hand, pm-utils (pm-suspend from the > command line) are fully functional. > > Unlike #718493 which is caused by interactions with logind, my system is > free of any systemd components, so this is an unrelated regression. > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752425 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#754850: upower: no suspend/hibernate on non-systemd systems
Package: upower Version: 0.99.0-3 Severity: important The newest update of upower (0.99.0-3) doesn't appear to be functional anymore. As I'm on a desktop, this means suspend and hibernate (obviously, there's no battery I could test). These functions don't even show up in XFCE's logout menu. On the other hand, pm-utils (pm-suspend from the command line) are fully functional. Unlike #718493 which is caused by interactions with logind, my system is free of any systemd components, so this is an unrelated regression. upower 0.9.23-2+b2 worked fine. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (150, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.15.3-x32 (SMP w/6 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 upower depends on: ii dbus 1.8.6-1 ii libc6 2.19-5 ii libdbus-1-31.8.6-1 ii libdbus-glib-1-2 0.102-1 ii libglib2.0-0 2.40.0-3 ii libgudev-1.0-0 204-14 ii libimobiledevice4 1.1.6+dfsg-2 ii libplist2 1.11-3 pn libpolkit-gobject-1-0 ii libupower-glib10.9.23-2+b2 ii libusb-1.0-0 2:1.0.19-1 ii pm-utils 1.4.1-15 ii udev 204-14 Versions of packages upower recommends: ii policykit-1 0.105-4 upower 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#740560: sslh fails to start with systemd as PID=1
Le dimanche 02 mars 2014 à 22:35 +0100, Gilles Filippini a écrit : > Package: sslh > Version: 1.15-1 > Severity: normal > > Hi, Hi, > > I've just switched to systemd as init system on my box, and after rebbot > sslh wasn't running. From what I understand the cause of the failure is > a missing /var/run/sslh directory. > > After adding the settings below to the sslh.service file, I can start it > manually using invoke-rc.d but it keeps failing at boot time: > ExecStartPre=/bin/mkdir -p /var/run/sslh > ExecStartPre=/bin/chown -R sslh:sslh /var/run/sslh/ Instead, i can propose to use a /usr/lib/tmpfiles.d/sslh.conf file like this: d /run/sslh 0755 sslh sslh - I'll test this soon, but maybe you'll test this before me. > > Please let me know about any missing information in this report. > > Thanks, > > _g. -- Guillaume Delacour signature.asc Description: This is a digitally signed message part
Bug#754846: upower upgrade breaks xfce4-power-manager suspend
Problem confirmed by downgrading upower 0.9.23-2+b2, which immediately fixes the issue. -- Ben Caradoc-Davies -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#614784: (no subject)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I think I may have encountered the bug today. Saving the log when prompted, it gives: Checking session consistency (brasero_burn_check_session_consistency brasero-burn.c:1739) Unsupported type of task operation Session error : An internal error occurred (brasero_burn_record brasero-burn.c:2856) using brasero 3.10.0-1 on jessie (testing). I found the solution from the ubuntu bug tracker, fixed with a simple install of the brasero-cdrkit package. Note you will need to close and restart brasero if you had it open during install. I believe bug #604407 relates to the same issue of not having brasero-cdrkit installed; and this also relates to bug #734517 To fix this issue, I would suggest either: - - Adding brasero-cdrkit as a suggested packing, and ensuring that whenever brasero hits this codepath, that it throws an error telling the user that they need to install brasero-cdrkit - - Or add brasero-cdrkit as a dependancy -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQEcBAEBAgAGBQJTxGtgAAoJEO2WJtL/WBIk6KYIAJWbDHic8Pvo8nJa6ratYWYU D6+fcV2zkPcGpmIWQm7RWdmLcizDgdNLuWwwPIl54f/1QfyPTgRx9CFIK2a9YmDC b0Xk1V8fn+0w1gUuRF7LhEh09ZQfKxlsAqfjLYu+TvtmdMaxbcY1uPnsiwvdEAKp tgquqqTZdavBznEsc2+YcyUz7CFtv3dIfX3D4+CC8lSYDCjlkmXGen5ClyExsF04 QvN5jRiHX1DuVF+Kp1Nz9NTBgHS1VFM5fS7EgKaN7pBFwkN9qH3e8bp6kSvlobUc 7nVv5VGlL/IEYFtac+IAS4HNWIj/G2juLq8hGwzgrSlwTxAW36ppWQQ6fq37m5A= =mpDG -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#754849: runit: s/runit-run/runit-init
Package: runit Version: 2.1.1-6.2 Followup-For: Bug #754849 sorry for the typo. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages runit depends on: ii procps 1:3.3.9-7 Versions of packages runit recommends: pn fgetty Versions of packages runit suggests: pn socklog-run -- 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#754849: runit: utmpset.c mixes "int32_t *" and "time_t *"
Package: runit Version: 2.1.1-6.2 Severity: normal Dear Maintainer, if you build runit on a 64-bit system, you'll see a couple of warnings when compiling utmpset.c: utmpset.c:38:9: warning: passing argument 1 of ‘time’ from incompatible pointer type if (time(&ut.ut_time) == -1) break; In file included from utmpset.c:2:0: /usr/include/diet/time.h:44:8: note: expected ‘time_t *’ but argument is of type ‘int32_t *’ I haven't actually used utmpset since the sad day when I noticed that runit-run was gone, but I think it's a safe guess that on systems with the wrong endianness utmpset will write absurd values of ut.ut_time. No idea if anyone is actually relying on ut_time :) -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages runit depends on: ii procps 1:3.3.9-7 Versions of packages runit recommends: pn fgetty Versions of packages runit suggests: pn socklog-run -- 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#754846: [Pkg-utopia-maintainers] Bug#754846: upower upgrade breaks xfce4-power-manager suspend
reassign 754846 xfce4-power-manager forcemerge 752428 754846 thanks Am 15.07.2014 01:11, schrieb Ben Caradoc-Davies: > Package: upower > Version: 0.99.0-3 > Severity: important > > Dear Maintainer, > > after upgrading upower:amd64 (0.9.23-2+b2, 0.99.0-3), xfce4-power-manager can > no longer suspend the system in response to a hardware power button press. > Notification dialog screenshot attached. In /etc/systemd/logind.conf I am > using > HandlePowerKey=ignore so xfce4-power-manager can handle the button press and > lock the screen before suspend. Now suspend fails. > > Using: > xfce4-power-manager 1.2.0-4 amd64 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752428 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#754848: helpviewer.app: Crashes on startup
Package: helpviewer.app Version: 0.3-7+b4 Severity: grave Justification: renders package unusable $ HelpViewer 2014-07-15 02:09:26.144 HelpViewer[5068] Exception occured while loading model: Codepoint out of range in constant string 2014-07-15 02:09:26.145 HelpViewer[5068] Failed to load Gorm 2014-07-15 02:09:26.146 HelpViewer[5068] Cannot load the main model file 'Main' Нарушение на разделянето(segfault) -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.14-1-686-pae (SMP w/1 CPU core) Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages helpviewer.app depends on: ii gnustep-back0.24 0.24.0-2 ii gnustep-base-runtime 1.24.6-2 ii gnustep-common [gnustep-fslayout-fhs] 2.6.6-2 ii gnustep-gui-runtime0.24.0-2 ii libc6 2.19-7 ii libgnustep-base1.241.24.6-2 ii libgnustep-gui0.24 0.24.0-2 ii libobjc4 4.9.0-10 helpviewer.app recommends no packages. helpviewer.app 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#754736: fwsnort is missing a dependency on NetAddr::IP Perl module
I've patched the debian/control file to fix the dependency issues. The patches are in my fork of https://alioth.debian.org/anonscm/git/collab-maint/fwsnort.git, which is available publicly at: https://github.com/isislovecruft/fwsnort The patches consist of top two from the following commits, and they are in my branch named `fix/754736`, based upon the `debian` branch of https://alioth.debian.org/anonscm/git/collab-maint/fwsnort.git : * c055cfb798e58a0c8e2b5393808a6e7d77cb887e (HEAD, isislovecruft/fix/754736, fix/754736) Add dependency on libnet-rawip-perl. * 94825f8e60c004d6e36920ba17c68fd97744732d Remove libnet-ip-perl dependency; add libnetaddr-ip-perl. * 2d0395545d69a12755b19499fe7a8c996a24c882 (tag: debian/1.6.3-1, debian, origin/debian, origin/HEAD) * Removed patch directory which is now useless. Thanks for working on Debian! -- ♥Ⓐ isis agora lovecruft _ GPG: 4096R/A3ADB67A2CDB8B35 Current Keys: https://blog.patternsinthevoid.net/isis.txt signature.asc Description: Digital signature
Bug#754847: ITP: golang-nfnt-resize -- Image resizing library for Go
Package: wnpp Severity: wishlist Owner: Tonnerre LOMBARD * Package name: golang-nfnt-resize Version : 0.0~git20140715 Upstream Author : Jan Schlicht * URL : http://github.com/nfnt/resize/ * License : Expat Programming Lang: Go Description : Image resizing library for Go Resize provides a couple of popular image resizing algorithms implemented in Go. It can be used to create thumbnails of images or to scale them up or down as desired. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#754846: upower upgrade breaks xfce4-power-manager suspend
Package: upower Version: 0.99.0-3 Severity: important Dear Maintainer, after upgrading upower:amd64 (0.9.23-2+b2, 0.99.0-3), xfce4-power-manager can no longer suspend the system in response to a hardware power button press. Notification dialog screenshot attached. In /etc/systemd/logind.conf I am using HandlePowerKey=ignore so xfce4-power-manager can handle the button press and lock the screen before suspend. Now suspend fails. Using: xfce4-power-manager 1.2.0-4 amd64 Kind regards, Ben. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-1-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 Versions of packages upower depends on: ii dbus 1.8.6-1 ii libc6 2.19-7 ii libdbus-1-31.8.6-1 ii libdbus-glib-1-2 0.102-1 ii libglib2.0-0 2.40.0-3 ii libgudev-1.0-0 204-14 ii libimobiledevice4 1.1.6+dfsg-2 ii libplist2 1.11-3 ii libpolkit-gobject-1-0 0.105-6 ii libupower-glib20.99.0-3 ii libusb-1.0-0 2:1.0.19-1 ii pm-utils 1.4.1-15 ii systemd204-14 ii udev 204-14 Versions of packages upower recommends: ii policykit-1 0.105-6 upower suggests no packages. -- no debconf information
Bug#754845: gnu-smalltalk: new upstream version is available
Source: gnu-smalltalk Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 There is a both a bugfix release and an alpha release available. Git also seems active. - -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (900, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQGcBAEBCAAGBQJTxFhlAAoJEPIClx2kp54sPogL/0ilwNGKnxXVbM4Cr8gSjNor 18R0/vu6VZoLyX0ijbORmA5HbNBdvON8EztDsyOznGbfcX0oQluzgmWU3tGmVbXJ /MVfSURciiU6TzGmTeHh/hfpeUXtQ1RS80jkJ4xaRpd+lv5JHpnEkm9/CgXvKdhg rODsuYYvfjdR0nFA/MMBp8aamozx99DWeQX5PG63Qksui2780UA0YUa1vHQr06w6 VQPrK2fSsZJxOyIAPuCdwlv0VDCr5pqeUUlXvrx0cNgOlskeW1rfN3yl5l08eH7P zWD4H/AWpauiLFRnK8hhTstR1MHe8t29kiYKWIcWSusWXYp7MC/PYdS4GqE03M27 pLl2LulaLwe3wPkuikSRuU8+YeG56rq2NosCCFzv8Ui5U5yhyCgW1HEAtntWqPMM h4m1qPg9FdygmQyPpZkGQaghrHC448en/stHw6O/WZgi0iHysEZgBvxxp6Gef5R/ QJjIYO0/vffiZBt2HkbcZrSvDH9d/koMalcXyca+Zg== =FK3P -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#754843: (no subject)
I also merged in the changes from testing/unstable postgrey. The 'rm $PIDFILE' issue is also present in testing/unstable. Thanks # diff postgrey.dist postgrey 54c54 < --pidfile $PIDFILE --name $NAME \ --- > --pidfile $PIDFILE \ 66c66 < --pidfile $PIDFILE --name $NAME --- > --pidfile $PIDFILE 68a69 > rm -f $PIDFILE 73d73 < rm -f $PIDFILE 78c78 < --pidfile $PIDFILE --name $NAME --- > --pidfile $PIDFILE -- John Howe, Seattle Girls' School Director of Technology Happiness = Reality / Expectations Some problems are so complex that you have to be highly intelligent and well-informed just to be undecided about them. - Dr. L. J. Peter Use it up, wear it out, make due, or do without. - Old Maine saying ( Pluto in Capricorn ) Fail cheap. Fail fast. Fail often. Always make new mistakes. - Esther Dyson -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#735922: wishlist: document logging in /var/log/auth.log
Le samedi 18 janvier 2014 à 17:28 +0100, Geert Stappers a écrit : > Package: sslh > Version: 1.13b-3.2 > Severity: minor > > Dear Maintainer, > > > When I have logged in through sslh, my connection is from localhost. I > do understand this artifact of sslh. I did took me some time to find > out from where the connection came from. > > It would be nice if the manual page says that logging > is done in /var/log/auth.log Yes you're right, sslh use LOG_AUTH facility (in common.c:488) which is on Debian systems logged in /var/log/auth.log (in /etc/rsyslog.conf:61). I'll propose upstream to add a syslog paragraph in the manpage to document this. > > > Thank you for maintaining sslh in Debian. > > > Cheers > Geert Stappers > > > -- System Information: > Debian Release: 7.0 > APT prefers stable-updates > APT policy: (500, 'stable-updates'), (500, 'stable') > Architecture: amd64 (x86_64) > > Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) > Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) > Shell: /bin/sh linked to /bin/dash > > Versions of packages sslh depends on: > ii adduser 3.113+nmu3 > ii debconf 1.5.49 > ii libc6 2.13-38 > ii libconfig91.4.8-5 > ii lsb-base 4.1+Debian8 > ii update-inetd 4.43 > > Versions of packages sslh recommends: > ii apache2 2.2.22-13 > ii apache2-mpm-prefork [httpd] 2.2.22-13 > ii openssh-server [ssh-server] 1:6.0p1-4 > > Versions of packages sslh suggests: > pn openbsd-inetd | inet-superserver > > -- Configuration Files: > /etc/default/sslh changed: > RUN=yes > DAEMON=/usr/sbin/sslh > DAEMON_OPTS="--user sslh --listen 0.0.0.0:443 --numeric --ssh 127.0.0.1:22 > --ssl 127.0.0.1:443 --pidfile /var/run/sslh/sslh.pid" > > > -- debconf information: > * sslh/inetd_or_standalone: standalone > -- Guillaume Delacour signature.asc Description: This is a digitally signed message part
Bug#751953: transition: upower
On 14/07/14 23:05, Michael Biebl wrote: > Please schedule a binNMU for the following packages > > tracker > mate-applets > mate-power-manager Scheduled. Emilio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#718127: [buildd-tools-devel] Bug#718127: Bug#718127: Bug#718127: schroot: CHROOT_SESSION_PURGE and tar-based source chroots
tags 718127 + patch pending
thanks
On Sun, Jul 13, 2014 at 10:49:46PM +0100, Roger Leigh wrote:
> On Thu, Jul 10, 2014 at 10:36:28PM +0100, Roger Leigh wrote:
> > To implement this, we need session and source facets to have a
> > pointer to the parent chroot. So we query a session chroot
> > and ask if its parent was a source chroot, and also link from
> > a source chroot to plain chroot for generality and
> > completeness. Initial scoping for 1.7 (1.6 will be backported):
> >
> > - chroot to inherit enable_shared_from_this and/or switch to
> > using weak_ptr rather than bare pointers for the facet->chroot
> > back reference
> > - session and source need "shared_ptr parent" fields
> > - session::create and source::create constructors to take a
> > "shared_ptr parent" argument. This will be passed by
> > session_clonable::clone_session and source_clonable::clone_source,
> > respectively
> > - session can check for the presence of a source facet in its
> > parent and set SESSION_SOURCE if parent is not null and the
> > facet is present.
> > - chroot will set CHROOT_SESSION_SOURCE=true if the SESSION_SOURCE
> > flag is set, otherwise set to false.
>
> Initial implementation here:
>
> http://anonscm.debian.org/gitweb/?p=users/rleigh/schroot.git;a=shortlog;h=refs/heads/source-env
>
> (last three commits). Works as above.
> Now needs backporting to 1.6.
Now rewritten for 1.6. I'd very much appreciate it if you could
try rebuilding 1.6.10 with these patches applied, and let me know
if it's doing what you want. Run with -v to see the value of
CHROOT_SESSION_SOURCE for source and non-source chroots.
http://anonscm.debian.org/gitweb/?p=users/rleigh/schroot.git;a=shortlog;h=refs/heads/source-env-1.6
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
>From 60175439a842d2bc96c56986409fbf1c2ad4acce Mon Sep 17 00:00:00 2001
From: Roger Leigh
Date: Mon, 14 Jul 2014 21:17:37 +0100
Subject: [PATCH 1/3] sbuild::chroot::chroot: Inherit from
enable_shared_from_this
---
sbuild/sbuild-chroot.cc | 2 ++
sbuild/sbuild-chroot.h | 2 +-
sbuild/sbuild-tr1types.h | 2 ++
3 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/sbuild/sbuild-chroot.cc b/sbuild/sbuild-chroot.cc
index 6ec7088..e808551 100644
--- a/sbuild/sbuild-chroot.cc
+++ b/sbuild/sbuild-chroot.cc
@@ -105,6 +105,7 @@ error::error_strings
init_errors + (sizeof(init_errors) / sizeof(init_errors[0])));
sbuild::chroot::chroot ():
+ std::enable_shared_from_this(),
name(),
description(),
users(),
@@ -132,6 +133,7 @@ sbuild::chroot::chroot ():
}
sbuild::chroot::chroot (const chroot& rhs):
+ std::enable_shared_from_this(),
name(rhs.name),
description(rhs.description),
users(rhs.users),
diff --git a/sbuild/sbuild-chroot.h b/sbuild/sbuild-chroot.h
index e3f1cf7..98ed958 100644
--- a/sbuild/sbuild-chroot.h
+++ b/sbuild/sbuild-chroot.h
@@ -42,7 +42,7 @@ namespace sbuild
* configuration file, and may be initialised directly from an open
* keyfile.
*/
- class chroot
+ class chroot : public std::enable_shared_from_this
{
public:
/// Type of setup to perform.
diff --git a/sbuild/sbuild-tr1types.h b/sbuild/sbuild-tr1types.h
index 2739a50..a3b3191 100644
--- a/sbuild/sbuild-tr1types.h
+++ b/sbuild/sbuild-tr1types.h
@@ -39,6 +39,7 @@ namespace std {
using std::tr1::static_pointer_cast;
using std::tr1::const_pointer_cast;
using std::tr1::dynamic_pointer_cast;
+using std::tr1::enable_shared_from_this;
}
# elif HAVE_BOOST_SHARED_PTR_HPP
# include
@@ -48,6 +49,7 @@ namespace std {
using boost::static_pointer_cast;
using boost::const_pointer_cast;
using boost::dynamic_pointer_cast;
+using boost::enable_shared_from_this;
}
# else
# error A shared_ptr implementation is not available
--
2.0.1
>From 7608267215790c1d7459c50773667f15785a942d Mon Sep 17 00:00:00 2001
From: Roger Leigh
Date: Mon, 14 Jul 2014 22:22:28 +0100
Subject: [PATCH 2/3] sbuild::chroot: Add SESSION_SOURCE and
CHROOT_SESSION_SOURCE
- add new SESSION_SOURCE session flag
- store session parent chroot in session facet when cloning
a session
- set CHROOT_SESSION_SOURCE in setup environment if the
session parent chroot had a source facet
---
sbuild/sbuild-chroot-facet-session-clonable.cc | 2 +-
sbuild/sbuild-chroot-facet-session.cc | 28 -
sbuild/sbuild-chroot-facet-session.h | 29 --
sbuild/sbuild-chroot.cc| 2 ++
sbuild/sbuild-chroot.h | 3 ++-
test/sbuild-chroot-block-device.cc | 24 +
test/sbuild-chroot-btrfs-snapshot.cc | 12 ---
test/sbuild-chroot-custom.cc | 1 +
test/sbuild-chroot-direct
Bug#754843: postgrey: Stopping postgrey daemon always deletes pid file, regardless of exit status
Package: postgrey
Version: 1.34-1.1
Severity: important
Tags: patch
-- System Information:
Debian Release: 7.6
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages postgrey depends on:
ii adduser3.113+nmu3
ii debconf [debconf-2.0] 1.5.49
ii libberkeleydb-perl 0.51-1
ii libnet-dns-perl0.66-2+b2
ii libnet-server-perl 2.006-1+deb7u1
ii perl 5.14.2-21+deb7u1
ii ucf3.0025+nmu3
Versions of packages postgrey recommends:
ii libnet-rblclient-perl 0.5-2
ii libparse-syslog-perl 1.10-2
ii postfix2.9.6-2
postgrey suggests no packages.
-- Configuration Files:
/etc/init.d/postgrey changed:
set -e
PATH=/sbin:/bin:/usr/sbin:/usr/bin
DAEMON=/usr/sbin/postgrey
NAME=postgrey
DESC="postfix greylisting daemon"
PIDFILE=/var/run/$NAME.pid
SCRIPTNAME=/etc/init.d/$NAME
test -x $DAEMON || exit 0
. /lib/lsb/init-functions
if [ -r /etc/default/$NAME ]
then
. /etc/default/$NAME
fi
POSTGREY_OPTS="--pidfile=$PIDFILE --daemonize $POSTGREY_OPTS"
if [ -z "$POSTGREY_TEXT" ]; then
POSTGREY_TEXT_OPT=""
else
POSTGREY_TEXT_OPT="--greylist-text=$POSTGREY_TEXT"
fi
ret=0
case "$1" in
start)
log_daemon_msg "Starting $DESC" "$NAME"
if start-stop-daemon --start --oknodo --quiet \
--pidfile $PIDFILE \
--startas $DAEMON -- $POSTGREY_OPTS "$POSTGREY_TEXT_OPT"
then
log_end_msg 0
else
ret=$?
log_end_msg 1
fi
;;
stop)
log_daemon_msg "Stopping $DESC" "$NAME"
if start-stop-daemon --stop --oknodo --quiet \
--pidfile $PIDFILE
then
log_end_msg 0
rm -f $PIDFILE
else
ret=$?
log_end_msg 1
fi
;;
reload|force-reload)
log_action_begin_msg "Reloading $DESC configuration..."
if start-stop-daemon --stop --signal 1 --quiet \
--pidfile $PIDFILE
then
log_action_end_msg 0
else
ret=$?
log_action_end_msg 1
fi
;;
restart)
$0 stop
$0 start
ret=$?
;;
status)
status_of_proc -p $PIDFILE $DAEMON "$NAME" 2>/dev/null
ret=$?
;;
*)
echo "Usage: $SCRIPTNAME
{start|stop|restart|reload|force-reload|status}" >&2
exit 1
;;
esac
exit $ret
-- debconf information:
postgrey/1.32-3_changeport:
In the stop section, I moved the 'rm -f $PIDFILE' from the bottom of the if
statement to the end of the then statement ( good exit status ).
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#754844: SSL handshake failed for my.owndrive.com
Package: owncloud-client-cmd Version: 1.5.0+dfsg-4~bpo70+1 I was using ocsync successfully before. But I was unable to connect to my.owndrive.com after switching to owncloud-client-cmd (from wheezy-backports). This is the error printed on the screen: 07-14 22:33:22:074 oc_module: opendir method called on ownclouds://s-andy:*@my.owndrive.com/remote.php/webdav/Redmine/Database 07-14 22:33:22:074 oc_module: * scheme ownclouds 07-14 22:33:22:074 oc_module: * host my.owndrive.com 07-14 22:33:22:074 oc_module: * port 0 07-14 22:33:22:074 oc_module: * path /remote.php/webdav/Redmine/Database 07-14 22:33:22:075 oc_module: * user s-andy 07-14 22:33:22:075 oc_module: fetch_resource_list_recursive Starting recursive propfind ownclouds://s-andy:*@my.owndrive.com/remote.php/webdav/Redmine/Database /remote.php/webdav/Redmine/Database 07-14 22:33:22:088 oc_module: Neon error code was 1 07-14 22:33:22:088 oc_module: WRN: propfind named failed with 1, request error: SSL handshake failed: SSL error: ASN1 parser: Element was not found. 07-14 22:33:22:088 oc_module: fill_recursive_propfind_cache /remote.php/webdav/Redmine/Database Server maybe did not give us an 'infinity' depth result 07-14 22:33:22:088 oc_module: get_listdir_context_from_recursive_cache No cache 07-14 22:33:22:093 oc_module: Neon error code was 1 07-14 22:33:22:093 oc_module: Neon error code was 1 07-14 22:33:22:093 oc_module: WRN: propfind named failed with 1, request error: SSL handshake failed: SSL error: ASN1 parser: Element was not found. 07-14 22:33:22:093 oc_module: Errno set to 10013 07-14 22:33:22:094 csync_ftw: opendir failed for ownclouds://s-andy:*@my.owndrive.com/remote.php/webdav/Redmine/Database - Unknown error 10013 (errno 10013) 07-14 22:33:22:094 ERROR during csync_update : "An internal error number 1060 happend. SSL handshake failed: SSL error: ASN1 parser: Element was not found."
Bug#730600: [pkg-kolab] Bug#730600: libkolabxml FTBFS (because of unit test failures)
No I don't know why its happening. I made a few updates to Paul Klos' 1.0.1 package that was living in git. I have a source package up on mentors http://mentors.debian.net/package/libkolabxml (and the updated libkolab) http://mentors.debian.net/package/libkolab I wasn't able to duplicate the test case failure, however it worked with the 0.8.4 version as well for me so I'm not sure why. Diane (successful build) make[3]: Leaving directory '/tmp/buildd/libkolabxml-1.0.1/obj-x86_64-linux- gnu' /usr/bin/cmake -E cmake_progress_report /tmp/buildd/libkolabxml-1.0.1/obj- x86_64-linux-gnu/CMakeFiles 38 39 [100%] Built target validationtest make[2]: Leaving directory '/tmp/buildd/libkolabxml-1.0.1/obj-x86_64-linux- gnu' /usr/bin/cmake -E cmake_progress_start /tmp/buildd/libkolabxml-1.0.1/obj- x86_64-linux-gnu/CMakeFiles 0 make[1]: Leaving directory '/tmp/buildd/libkolabxml-1.0.1/obj-x86_64-linux- gnu' dh_auto_test -O--parallel make[1]: Entering directory '/tmp/buildd/libkolabxml-1.0.1/obj-x86_64-linux- gnu' Running tests... /usr/bin/ctest --force-new-ctest-process -j1 Test project /tmp/buildd/libkolabxml-1.0.1/obj-x86_64-linux-gnu Start 1: phptest 1/5 Test #1: phptest .. Passed0.05 sec Start 2: bindingstest 2/5 Test #2: bindingstest . Passed0.72 sec Start 3: conversiontest 3/5 Test #3: conversiontest ... Passed0.27 sec Start 4: parsingtest 4/5 Test #4: parsingtest .. Passed0.02 sec Start 5: validationtest 5/5 Test #5: validationtest ... Passed0.05 sec 100% tests passed, 0 tests failed out of 5 On Sunday, July 13, 2014 21:51:22 Mike Gabriel wrote: > Hi all, > > I tried to build libkolabxml in a jessie chroot and the build fails > due to failing unittests (see below). > > Any idea why that is happening? > > I wanted to test libkolab+libkolabxml on my roundcube instance, but > due to these test failures I stopped playing with it (as I am > currently on VAC ;-) ). > > Mike > > """ > [...] > Start 1: phptest > 1/5 Test #1: phptest ..***Failed 12.95 sec > PHP Warning: Module 'kolabformat' already loaded in Unknown on line 0 > OK - Event::exceptionDates() > OK - Event::addExceptionDate() > Critical: > /build/libkolabxml-SJB5qx/libkolabxml-0.8.4/src/xcalconversions.h > 1906: failed to write Incidence > FAIL - Event::setStart() with date only > -- Expected '2012-07-31', got false -- > FAIL - Event::setCreated() with date-time > -- Expected > '2012-03-14T09:05:30Z', got > false -- > FAIL - RecurrenceRule::setFrequency() > -- Expected 'MINUTELY', got false -- > FAIL - RecurrenceRule::setBySecond() > -- Expected > 'MINUTELY13 ond>', got false -- > FAIL - Event Recurrence Exceptions > -- Expected '2009-10-12', got false -- > FAIL - Alarm::setRelativeStart(Duration) > -- Expected '-PT6H30M', got false -- > FAIL - Alarm::setStart() > -- Expected '2012-07-30T20:30:00Z', > got false -- > FAIL - Alarm relative to Start > -- Expected 'START', got false -- > FAIL - Email alarm > -- Expected 'EMAIL', got false -- > FAIL - Email alarm attendee > -- Expected > 'mailto:%3Calarms%40kolab.org%3E', got > false -- > FAIL - kolabformat::readEvent() => kolabformat::writeEvent() > -- Expected ' > > > > > > Libkolabxml-0.8.4 > > > 2.0 > > > 3.0dev1 > > > > > > > 894cd943-0165-4a34-aac8-c727a6d256a6 > > > 2014-07-13T21:27:14Z > > > 2014-07-13T21:27:14Z > > > 0 > > > PUBLIC > > > > > > > > schema exception > > :1:1 error: invalid document structure > > Critical: > /build/libkolabxml-SJB5qx/libkolabxml-0.8.4/src/xcalconversions.h > 1938: Failed to parse calendar! > Error: > /build/libkolabxml-SJB5qx/libkolabxml-0.8.4/src/xcalconversions.h > 1465: Start date is missing, but is mandatory for events > Error: > /build/libkolabxml-SJB5qx/libkolabxml-0.8.4/src/xcalconversions.h > 1465: Start date is missing, but is mandatory for events > ', got '' -- > FAIL - Event::start() > -- Expected '2012-7-31', got '-1--1--1' -- > FAIL - RecurrenceRule::frequency() > -- Expected 6, got 0 -- > FAIL - RecurrenceRule::bysecond() > -- Expected 2, got 0 -- > FAIL - Read Event::exceptionDates() > -- Expected 1, got 0 -- > FAIL - Event::alarms() > -- Expected 2, got 0 -- > OK - Recurrence by weekday > OK - NameComponents::setSurnames() > OK - NameComponents::setGiven() > OK - NameComponents::setAdditional() > OK - NameComponents::setPrefixes() > OK - NameComponents::suffixes() > OK - Generate Contact UID as urn::uuid > OK - Contact::setNameComponents() > OK - Contact::setTitles() > OK - Contact::setPhoto() > OK - Contact::setBDay() >
Bug#754842: [openssh-client] weird output from ssh-add -D when used with ssh-agent-filter
Package: openssh-client
Version: 1:6.6p1-6
Severity: minor
> $ SSH_ASKPASS=true afssh -A -- localhost ssh-add -D | cat
> SSH_AGENT_FAILURE
> All identities removed.
See the relevant part of an strace of ssh-add -D, annotated with the names
for the message numbers:
> connect(3, {sa_family=AF_FILE, path="/tmp/ssh-H8TZMh3Lsb/agent.5962"}, 110) = > 0
> write(3, "\0\0\0\1", 4) = 4
> write(3, "\t", 1) = 1
SSH_AGENTC_REMOVE_ALL_RSA_IDENTITIES
> read(3, "\0\0\0\1", 4) = 4
> read(3, "\6", 1)= 1
SSH_AGENT_SUCCESS
> write(3, "\0\0\0\1", 4) = 4
> write(3, "\23", 1) = 1
SSH2_AGENTC_REMOVE_ALL_IDENTITIES
> read(3, "\0\0\0\1", 4) = 4
> read(3, "\5", 1)= 1
SSH_AGENT_FAILURE
> write(2, "SSH_AGENT_FAILURE\r\n", 19) = 19
> write(2, "All identities removed.\n", 24) = 24
> close(3)= 0
> exit_group(0) = ?
The message "All identities removed." is wrong here, ssh-agent-filter denied
the request and the SSH2 identities are still in the ssh-agent.
Greetings
Timo
signature.asc
Description: This is a digitally signed message part.
Bug#754834: squeeze-pu: package libdbi-perl/1.612-1+deb6u1
Control: tags -1 + pending On Mon, 2014-07-14 at 22:35 +0200, Salvatore Bonaccorso wrote: > On Mon, Jul 14, 2014 at 09:26:06PM +0100, Adam D. Barratt wrote: > > On Mon, 2014-07-14 at 22:14 +0200, Salvatore Bonaccorso wrote: > > > This is the corresponding proposed update for libdbi-perl as for > > > wheezy, see [1], in case I'm still in time for squeeze-pu. Attached is > > > proposed debdiff for squeeze. libplrpc-perl was removed from the > > > archive for unstable[1] as it uses Storable in an unsafe way, leading > > > to a remote code execution vulnerability. The idea is to also drop > > > libplrpc-perl from squeeze. As first step again the dependency needs > > > to be removed from libdbi-perl. > > > > > > [1] https://bugs.debian.org/751527 > > > > As mentioned on IRC, I think we should get this sorted for Squeeze, > > despite being after the window officially closed. Please go ahead; > > thanks. > > Thank you, uploaded. Flagged for acceptance. 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#753662: ITA: vlock
Package: wnpp Severity: normal Owner: elbonian.m...@gmail.com Hello! I still use this package, and wish to adopt it. Pedro -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#663388: closed by Yavor Doganov (Bug#663388: fixed in gnustep-back 0.24.0-2)
reopen 663388 found 663388 0.24.0-2 thanks On Mon, Jul 07, 2014 at 05:57:19PM +, Debian Bug Tracking System wrote: >* Upload to unstable; should finally fix the piuparts issue once > mknfonts.tool is binNMUed (Closes: #663388). That would have been true if I didn't make one stupid change in 0.24.0-1 :/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#754841: doxymacs: FTBFS on arm64 due to emacs23 dependency
Package: doxymacs Version: 1.8.0-6 Severity: normal Tags: patch User: debian-...@lists.debian.org Usertag: arm64 This package build-depends on emacs23 which is going away at some point now that 'emacs' depends on emacs24. There is no emacs23 for arm64 (it won't build) so I tried building this against emacs24. (in fact by setting the build-dep to simply 'emacs' (I don't know if that's a good - idea it seems that there are reasons for the specific-version build-dep?) The package builds OK but does not install on an emacs24-only system: (log below) I'm afraid I know nothing of emacs module installation and 23-24 API changes. Hopefully this is a simple matter to fix? sudo dpkg -i ../doxymacs_1.8.0-6.1_arm64.deb [sudo] password for buildd: Sorry, try again. [sudo] password for buildd: Selecting previously unselected package doxymacs. (Reading database ... 86326 files and directories currently installed.) Preparing to unpack .../doxymacs_1.8.0-6.1_arm64.deb ... Unpacking doxymacs (1.8.0-6.1) ... Setting up doxymacs (1.8.0-6.1) ... ERROR: doxymacs is broken - called emacs-package-install as a new-style add-on, but has no compat file. Install doxymacs for emacs install/doxymacs: Handling install of emacsen flavor emacs Install doxymacs for emacs24 install/doxymacs: Handling install of emacsen flavor emacs24 install/doxymacs: byte-compiling for emacs24 -- System Information: Debian Release: 7.6 APT prefers stable APT policy: (990, 'stable') Architecture: i386 (i686) Kernel: Linux 3.2.0-kvm-i386-20110111 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#754840: packages should not build-depend on binutils-dev
Package: axiom,gcl,hol88,axiom Severity: serious Packages which were not updated upstream for over a decade should not start build-depending on binutils-dev. There is absolutely NO reason to rely on the UNSTABLE libbfd ABI. Please drop these build dependencies again. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#754185: avahi-daemon: Packet too short or invalid while reading known answer record. (Maybe a UTF-8 problem?)
Package: avahi-daemon Version: 0.6.31-4 Followup-For: Bug #754185 I'm seeing exactly the same problem. -- System Information: Debian Release: jessie/sid APT prefers stable APT policy: (650, 'stable'), (600, 'unstable') Architecture: i386 (i686) Kernel: Linux 3.14-1-686-pae (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 avahi-daemon depends on: ii adduser 3.113+nmu3 ii bind9-host [host]1:9.9.5.dfsg-4 ii dbus 1.8.6-1 ii host 1:9.9.5.dfsg-4 ii init-system-helpers 1.19 ii libavahi-common3 0.6.31-4 ii libavahi-core7 0.6.31-4 ii libc62.19-5 ii libcap2 1:2.22-1.2 ii libdaemon0 0.14-6 ii libdbus-1-3 1.8.6-1 ii libexpat12.1.0-6 ii lsb-base 4.1+Debian13 Versions of packages avahi-daemon recommends: ii libnss-mdns 0.10-6 Versions of packages avahi-daemon suggests: ii avahi-autoipd 0.6.31-4 -- 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#753079: c++11 mode in GCC is still marked as experimental (although armel needs work)
Hi,
On Sun, Jul 13, 2014 at 10:41 PM, Guo Yixuan wrote:
>
> On Sat, Jul 12, 2014 at 11:10 AM, Osamu Aoki wrote:
>>
>> On Sat, Jul 12, 2014 at 02:00:35PM +0200, Matthias Klose wrote:
>> > I would rather drop any package which does use c++11 features without
any
>> > reflection.
>>
>> I now understand the problem. Thanks.
>>
>> On Sat, Jul 12, 2014 at 01:10:52PM +0200, Julien Cristau wrote:
>> > No, just because some random c++11 thing doesn't work on armel doesn't
>> > mean we drop the arch.
>> >
>> > What it means is packages get to work without it until it's fixed.
>>
>> Yes, I see. (I was wrong.)
>>
>> https://bugs.debian.org/727621
>> There seems to be some issue related to ATOMIC_type_LOCK_FREE. (I have
>> no clue but it is related to type.)
>>
>> I also see FEDORA applied attached arm patch changing float to double
>> and doing the alignment computing for mapped file.
>>
>> Is this patch something which work around the issue on armel?
>>
>> Also, as I see the upstream git repo, just after his release of this
>> tar, he is commiting
>> 5c274357ceaaff941b91e12d3f2f4714df0ecd16
>> to revert CMakeLists.txt of oldscheool branch as:
>>
>> -if(UNIX)
>> - add_definitions("-std=c++11")
>> -endif(UNIX)
>>
>> Then recent commit has
>> + if(NOT BOOST_USE_CXX11)
>> + add_definitions("-DBOOST_NO_CXX11_SCOPED_ENUMS")
>> + endif()
>>
>> Are these kind of updates needed?
>>
>> Guo Yixuan,
>>
>> Can you talk to the upstream on this issue and what oldschool devel
>> branches mean?
>
> This branch is intended for the compilers without full support of c++11.
[1]
> (Although currently it doesn't build. Perhaps we can switch to it when
it's
> working.)
>
> [1] https://code.google.com/p/rimeime/issues/detail?id=632#c1
With a confirmation from the upstream[1], I'm going to prepare
an upload based on the oldschool branch, which doesn't depend
on c++11 features.
[1] https://code.google.com/p/rimeime/issues/detail?id=632#c7
Regards,
Yixuan
Bug#754828: xserver-xorg-video-nvidia / xserver-xorg-core compatibility
xserver-xorg-core (in SID) bumps video ABI version causing reported incompatibility with xserver-xorg-video-nvidia (affecting both SID/experimental packages). Downgrade of relevant xserver-xorg packages of course is also workaround for this problem. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#736773: org.osgi.framework.BundleException: Unresolved constraint in bundle net.java.sip.communicator.plugin.propertieseditor
I can reproduce this problem when deleting ~/.jitsi and starting jitsi from the command-line. Jitsi is based on the OSGi container Apache Felix. The OSGi container tries to resolve the dependencies for the OSGi bundle net.java.sip.communicator.plugin.propertieseditor. It tries to find the OSGi bundle org.apache.commons.lang3. Based on felix.client.run.properties, it tries to find the bundle in sc-bundles/commons-lang.jar which does find a file at /usr/share/java/commons-lang3.jar. The package libcommons-lang3-java in version 3.3.2-1 seemingly does not have an appropriate META-INF/MANIFEST.MF in it to constitute a valid OSGi bundle. The jitsi package from jitsi.org works fine because it ships a commons-lang.jar which has an appropriate MANIFEST.MF. I can workaround the problem by copying the MANIFEST.MF from the jitsi package from jitsi.org into /usr/share/java/commons-lang3.jar. Debians libcommons-logging-java on the other hand has also a valid MANIFEST.MF which comes from src/conf/MANIFEST.MF from upstream. Maybe libcommons-lang3-java the build system either of Debian or Apache Commons Lang does not create the file. Apache has a status tracking page called Commons OSGi(1) and Apache Felix Commons(2) to track the progress of moving the commons libraries to OSGi. When I fetch commons-lang from Github(3) and run ant jar, I do not get the adequate results. When I run a mvn package verify (maven3), I get a commons-lang3-3.4-SNAPSHOT.jar which contains a MANIFEST.MF and replace /usr/share/java/commons-lang3.jar it seems to work for me. Hope that helps. (1) https://wiki.apache.org/commons/CommonsOsgi (2) https://felix.apache.org/documentation/subprojects/apache-felix-commons.html (3) https://github.com/apache/commons-lang -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#740701: [Netapp-Linux-Community] Bug#740701: multipath-tools: mkfs fails "Add. Sense: Incompatible medium installed"
Hi,
On 07/02/2014 07:13 PM, Bill MacAllister wrote:
We have a working solution after iterating through multiple
configuration changes on both the NetApp box and the debian system.
Our first consistent success came after ALUA was disabled on the
NetApp. With a modified configuration we were able to subsequently
enable ALUA. Unfortunately I don't know that details of the changes
made to the NetApp boxes other than what I just told you. Here is the
working multiplath configuration we are using on the Debian systems.
[...]
Aha, well, thanks for replying. The fun thing is that I have a situation
where two different luns in the same configuration are acting different.
I just created a case at NetApp, (no. 2005131664). Let's see what happens!
Our multipath.conf is pretty simple by the way:
defaults {
path_grouping_policy multibus
rr_min_io 1000
failback immediate
no_path_retry queue
user_friendly_names yes
}
# be explicit about what to multipath, prevent local disks and
# crap to be inserted into multipath/bindings
blacklist {
device {
vendor "*"
product "*"
}
}
blacklist_exceptions {
device {
vendor "NETAPP"
product "LUN"
}
}
--
Hans van Kranenburg - System / Network Engineer
T +31 (0)10 2760434 | hans.van.kranenb...@mendix.com | www.mendix.com
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#477498: Fwd: Shutdown & Reboot scripts try umount CIFS but CIFSD is killed first
-- Forwarded message -- From: Peter Nowee Date: Mon, Jul 14, 2014 at 11:38 PM Subject: Re: Shutdown & Reboot scripts try umount CIFS but CIFSD is killed first To: 477...@bugs.debia.org, 516...@bugs.debian.org, 431...@bugs.debian.org Hi, I think this 7-year-old bug affects my fresh and up-to-date install of Debian Wheezy. My CPU is a AMD Athlon XP 2200+, so I'm on i386-architecture, not amd64. I'm running wpa_supplicant and NetworkManager to connect to wireless, and made an /etc/fstab entry for a cifs network mount. On shutdown or reboot, the system hangs for a long time (probably five minutes) between: ... stopping enhanced syslogd: rsyslogd and CIFS VFS: Server bigbee.local has not responded in 300 seconds. Reconnecting... ... See links below to forum reports of other users running into this problem on Debian Wheezy and Ubuntu. Workarounds commonly suggested are: - Manually changing init-scripts or their priorities to ensure umounting before the network goes down, or - Avoiding the use of auto-mounted network shares, or - Using /etc/network/interfaces instead of NetworkManager. In 2011, Mike Perrin on the Ubuntu bug tracker suggested this problem had to be solved in NetworkManager, so he filed a bug report upstream. His report was marked duplicate at the time, but the original bug (that his report was a duplicate of) was fixed last month. The fix got included in the recently released NetworkManager 0.9.10: "The NetworkManager dispatcher got some enhancements too. It now has a “pre-up” event that allow scripts to execute before NetworkManager announces connectivity to applications. We also added a “pre-down” event that lets network filesystems flush data before the interface is actually disconnected from the network." - Dan Williams, NetworkManager developer, June 20, 2014. I see that unstable currently has a package for network-manager 0.9.10. I'm running stable here, so I cannot check if this solves the problem, but perhaps someone else can? Regards, Peter Recent forum mentions of users running into this problem: forums.debian.net/viewtopic.php?f=5&t=70798&start=30 forums.debian.net/viewtopic.php?f=5&t=111509 Upstream: bugs.launchpad.net/ubuntu/+source/wpasupplicant/+bug/211631/comments/148 https://bugzilla.gnome.org/show_bug.cgi?id=650925 https://bugzilla.gnome.org/show_bug.cgi?id=387832 http://blogs.gnome.org/dcbw/2014/06/20/well-build-a-dream-house-of-net/ Debian Package Tracking System - network-manager: https://packages.qa.debian.org/n/network-manager.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#431966: Shutdown & Reboot scripts try umount CIFS but CIFSD is killed first
Hi, I think this 7-year-old bug affects my fresh and up-to-date install of Debian Wheezy. My CPU is a AMD Athlon XP 2200+, so I'm on i386-architecture, not amd64. I'm running wpa_supplicant and NetworkManager to connect to wireless, and made an /etc/fstab entry for a cifs network mount. On shutdown or reboot, the system hangs for a long time (probably five minutes) between: ... stopping enhanced syslogd: rsyslogd and CIFS VFS: Server bigbee.local has not responded in 300 seconds. Reconnecting... ... See links below to forum reports of other users running into this problem on Debian Wheezy and Ubuntu. Workarounds commonly suggested are: - Manually changing init-scripts or their priorities to ensure umounting before the network goes down, or - Avoiding the use of auto-mounted network shares, or - Using /etc/network/interfaces instead of NetworkManager. In 2011, Mike Perrin on the Ubuntu bug tracker suggested this problem had to be solved in NetworkManager, so he filed a bug report upstream. His report was marked duplicate at the time, but the original bug (that his report was a duplicate of) was fixed last month. The fix got included in the recently released NetworkManager 0.9.10: "The NetworkManager dispatcher got some enhancements too. It now has a “pre-up” event that allow scripts to execute before NetworkManager announces connectivity to applications. We also added a “pre-down” event that lets network filesystems flush data before the interface is actually disconnected from the network." - Dan Williams, NetworkManager developer, June 20, 2014. I see that unstable currently has a package for network-manager 0.9.10. I'm running stable here, so I cannot check if this solves the problem, but perhaps someone else can? Regards, Peter Recent forum mentions of users running into this problem: forums.debian.net/viewtopic.php?f=5&t=70798&start=30 forums.debian.net/viewtopic.php?f=5&t=111509 Upstream: bugs.launchpad.net/ubuntu/+source/wpasupplicant/+bug/211631/comments/148 https://bugzilla.gnome.org/show_bug.cgi?id=650925 https://bugzilla.gnome.org/show_bug.cgi?id=387832 http://blogs.gnome.org/dcbw/2014/06/20/well-build-a-dream-house-of-net/ Debian Package Tracking System - network-manager: https://packages.qa.debian.org/n/network-manager.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#753444: Bug#753542: Bug#753444: Bug#753542: perl-base - Segfaults in libperl.so.5.18
On Mon, Jul 14, 2014 at 09:34:35AM +0200, Emilio Pozuelo Monfort wrote:
> On 14/07/14 09:05, Niko Tyni wrote:
> > So can I go ahead with dropping perlapi-5.18.2 or do we need to dig in
> > the libimager-perl/libpng problem first?
>
> If you're ok with removing libimager-perl, libimager-qrcode-perl and
> libmojomojo-perl from testing if those don't get fixed in time, then yes.
> As for sereal, we'd need to remove libsereal-{en,de}coder-perl,
> libsession-storage-secure-perl and libdancer-session-cookie-perl.
The libimager-perl/libpng thing looks thorny enough that I don't
think we should wait for that. The libsereal-encoder-perl package
has been failing on s390x for a long time, if it has to be removed
then so be it.
I've just uploaded perl_5.18.2-7 providing only perlapi-5.18.2d on s390x
and closing this bug (#753444).
--
Niko Tyni nt...@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#754125: libimager-perl: FTBFS on s390x
On Mon, Jul 14, 2014 at 11:44:22PM +0300, Niko Tyni wrote:
> (Cc'ing the libpng maintainers.)
>
> On Sun, Jul 13, 2014 at 08:12:38PM +0200, Aurelien Jarno wrote:
>
> > A quick debugging seems to show the problem is on the libpng side.
> > Rebuilding it makes the problem disappear. It looks like it is due to
> > the same issue we are doing this transition, ie the libpng structure
> > expose a jmp_buf structure. I don't really now what to do...
>
> Ouch. I see. From png.h:
>
> struct png_struct_def
> {
> #ifdef PNG_SETJMP_SUPPORTED
>jmp_buf jmpbuf;/* used in png_error */
> #endif
> [...]
>
> PNG_SETJMP_SUPPORTED seems to be the default, if I read pngconf.h
> correctly.
>
> As libpng was built against libc6-dev_2.17-97 168 days ago and hasn't
> been binNMU'd since, does that mean that all its reverse dependencies
> built against libc6 2.19 (in the last month or so) are potentially broken
> on s390x? Or do I misunderstand something?
You are correct :-( Currently it seems to not break too much, but as
soon as libpng will be rebuilt, it will break a lot of things...
> Doesn't the fact that it's at the start of the struct make things
> even worse?
Indeed, it *might* have worked if it was at the end.
> There are 500ish packages depending on libpng12-0. So do we need
> an SONAME bump on s390x only? How hard would that be?
I think it is urgent to wait to decide about a global strategy how to
handle that. Upstream suggested to do like Red Hat, ie just rebuild
everything and warn the users their system might break during upgrade.
I have sent a mail to debian-s390 so that we can decide on a strategy.
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#664761: apache2/conf.d migration: what should webapp packagers do?
reopen 664761 block 669292 by 664761 quit Hi Arno, Arno Töll wrote: > In lack of responses, I assume that all your questions have been > answered or properly addressed. Alas, no. Since message #58 wasn't cc-ed to me, I didn't see it. https://wiki.debian.org/Apache/PackagingFor24 is helpful (thanks!), but I'm still stuck --- I really just don't know how to package gitweb in the new setup. See also http://bugs.debian.org/669292#28: * It's not clear when to run "apache2_invoke enconf gitweb" for a package like gitweb that does not have a Depends against apache 2.4. If I run it conditionally based on the Apache version, then gitweb will still be broken when the user upgrades apache, unless gitweb happens to be upgraded later in the same upgrade run. * It's not clear when to run "apache2_invoke disconf gitweb". At "remove" and "purge" time doesn't seem to be enough. And https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=23;filename=update-apache-packaging.patch;att=1;bug=669292: - prerm deconfigure does not clean up as much as it should - needs triggers to reconfigure when apache is updated? Basically, I am stuck on understanding the state machine: (1) What is the intended update order between webapps, apache-common, and apache itself? What Depends, Pre-Depends, or triggers should be used to make sure everything works okay regardless of the update order? In particular, the conditional enconf and disconf invocations seem to make it easy to get into a non-working state and never get out of it. (2) What is the intended uninstallation procedure? https://wiki.debian.org/Apache/PackagingFor24 tells me I should enconf in postinst and disconf in postrm. That's confusing because: * Usually in packaging, postinst is a mirror image of prerm so when the package is in a given dpkg state, the state of configuration matches that. Why here is postinst's mirror image in postrm instead? * Dependencies are not guaranteed to be present during postrm, so the disconf is not guaranteed to happen. Thanks, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#751953: transition: upower
Please schedule a binNMU for the following packages tracker mate-applets mate-power-manager All other packages need sourceful uploads (or removal from testing). -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#754829: [binutils-mingw-w64-i686] i686-w64-mingw32-windres running on s390x does not properly convert string
Hi Thomas, On Mon, 14 Jul 2014 21:27:08 +0200, Thomas Gaugler wrote: > i686-w64-mingw32-windres running on s390x behaves differently when it > comes to strings. Thanks for reporting this! I've forwarded the issue upstream; you can follow things there at https://sourceware.org/bugzilla/show_bug.cgi?id=17159 I noticed that using L"String" fixes things, I don't know whether that's an appropriate fix in your case. Regards, Stephen signature.asc Description: PGP signature
Bug#753745: vserver-debiantools: please depend on iproute2 instead of iproute transitional package
On Mon, Jul 14, 2014 at 04:51:20PM +0200, Ola Lundqvist wrote: > Den 4 jul 2014 17:30 skrev "Andreas Henriksson" : > > > Package: vserver-debiantools [...] > > Thanks. This package should be removed though, so I will probably not fix > it. > In that case, could you please file a RM request with reportbug ftp.debian.org to get this taken care of? Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#754839: irssi-plugin-xmpp: does not require STARTTLS, vulnerable to MITM attack
Package: irssi-plugin-xmpp Version: 0.52+git20140102-1 Severity: normal For XMPP servers that do not offer TLS-wrapped-XMPP on port 5223, the usual standard is to offer STARTTLS (enabling TLS at the start of the XMPP exchange). In fact, there was a strong consensus to do ensure encrypted XMPP by many contributors: https://github.com/stpeter/manifesto irssi's XMPP plugin should also default to requiring STARTTLS in case TLS-wrapped-XMPP is not available. This patch should require STARTTLS, according to the loudmouth documenation. note that sslstrip tools for XMPP are freely available: http://www.beneaththewaves.net/Software/XMPPPeek.html This patch should defend against these sort of changes. --dkg -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (200, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages irssi-plugin-xmpp depends on: ii irssi0.8.15-5+b1 ii libc62.19-4 ii libglib2.0-0 2.40.0-3 ii libloudmouth1-0 1.4.3-12 irssi-plugin-xmpp recommends no packages. irssi-plugin-xmpp suggests no packages. -- debconf-show failed --- a/src/core/xmpp-servers.c +++ b/src/core/xmpp-servers.c @@ -423,7 +423,7 @@ ssl = lm_ssl_new(NULL, lm_ssl_cb, user_data, NULL); lm_connection_set_ssl(lmconn, ssl); if (use_starttls) - lm_ssl_use_starttls(ssl, TRUE, FALSE); + lm_ssl_use_starttls(ssl, TRUE, TRUE); lm_ssl_unref(ssl); return TRUE; }
Bug#754838: grr.app: Cannot add new feeds
Package: grr.app
Version: 0.9.0-1+b1
Severity: grave
Justification: renders package unusable
On amd64, adding a feed results in:
2014-07-14 20:30:48.495 Grr[16032] Unnamed feed finished loading
https://tracker.debian.org/pkg/grr.app/rss
2014-07-14 20:30:48.497 Grr[16032] Date=Mon, 14 Jul 2014 18:09:18
+, calc'd from Mon, 14 Jul 2014 18:09:18 +, which matched to
%a, %d %b %Y %H:%M:%S %Z (1th try)
2014-07-14 20:30:48.498 Grr[16032] Problem posting notification:
NAME:NSRangeException REASON:Index
18446744073709551615 is out of range 0 (in 'objectAtIndex:')
INFO:{Array = (); Count = 0; Index = 4294967295; }
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#727295: exiv2: diff for NMU version 0.23-1.1
tags 727295 + pending thanks Dear maintainer, This bug has been around for quite some time, and you have not responded about the possibility of moving the (fixed) 0.24 in experimental into unstable. Moving the new version to unstable without maintainer say-so that was OK seemed presumptious, so I've prepared an NMU with just the autotools-dev fix for exiv2 (versioned as 0.23-1.1) and uploaded it to DELAYED/7. Please feel free to tell me if I should delay it longer. I did try to make dh-autoreconf work on this package, but because configure is at the top level whilst configure.ac and the config.* files are inside the config dir this is messy, and in fact I still couldn't get it to autoreconf successfully, which may be because the macros need updating. autotools-dev is sufficient for arm64, and libtool is not obviously being used so this may well work for ppc64el too. If not we will have to come back to this. Regards. -- Wookey http://wookware.org/ Principal hats: Linaro, ARM, Debian, Wookware diff -Nru exiv2-0.23/debian/changelog exiv2-0.23/debian/changelog --- exiv2-0.23/debian/changelog 2012-05-05 00:32:30.0 +0100 +++ exiv2-0.23/debian/changelog 2014-07-14 14:50:16.0 +0100 @@ -1,3 +1,10 @@ +exiv2 (0.23-1.1) unreleased; urgency=low + + * Non-maintainer upload. + * Ensure configurey is updated for new architectures (Closes: #727295) + + -- Wookey Wed, 18 Jun 2014 21:55:26 + + exiv2 (0.23-1) unstable; urgency=low * New upstream release diff -Nru exiv2-0.23/debian/rules exiv2-0.23/debian/rules --- exiv2-0.23/debian/rules 2012-01-24 20:19:10.0 + +++ exiv2-0.23/debian/rules 2014-07-14 16:27:40.0 +0100 @@ -1,7 +1,7 @@ #!/usr/bin/make -f %: - dh $@ --parallel + dh $@ --parallel --with autotools-dev override_dh_auto_configure: dh_auto_configure -- --disable-rpath $(shell dpkg-buildflags --export=configure)
Bug#754125: libimager-perl: FTBFS on s390x
(Cc'ing the libpng maintainers.)
On Sun, Jul 13, 2014 at 08:12:38PM +0200, Aurelien Jarno wrote:
> A quick debugging seems to show the problem is on the libpng side.
> Rebuilding it makes the problem disappear. It looks like it is due to
> the same issue we are doing this transition, ie the libpng structure
> expose a jmp_buf structure. I don't really now what to do...
Ouch. I see. From png.h:
struct png_struct_def
{
#ifdef PNG_SETJMP_SUPPORTED
jmp_buf jmpbuf;/* used in png_error */
#endif
[...]
PNG_SETJMP_SUPPORTED seems to be the default, if I read pngconf.h
correctly.
As libpng was built against libc6-dev_2.17-97 168 days ago and hasn't
been binNMU'd since, does that mean that all its reverse dependencies
built against libc6 2.19 (in the last month or so) are potentially broken
on s390x? Or do I misunderstand something?
Doesn't the fact that it's at the start of the struct make things
even worse?
There are 500ish packages depending on libpng12-0. So do we need
an SONAME bump on s390x only? How hard would that be?
--
Niko Tyni nt...@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#748805: initrd-tools: Systems on btrfs root fail to boot due to missing module dependency
Control: retitle -1 initrd-tools: Systems on btrfs root fail to boot due
to missing module dependency
Control: severity -1 critical
Control: tags -1 patch
Control: reassign -1 initramfs-tools 0.115
Dear kernel maintainers,
I recently ran into this very issue on a head-less armel system,
effectively making the system un-bootable. I had to attach a serial
console to un-brick the box.
Since Linux 3.14 (or 0b947aff1599afbbd2ec07ada87b05af0f94cf10, to be
precise), the btrfs module no longer depends on libcrc32c, but only on
crc32c. However, this is one of the "hidden" dependencies, so
modules.dep doesn't list it. If mkinitramfs doesn't happen to include
crc32c for some other reason, an initrd without that module is
generated, even if btrfs needs it to boot. For me, this led to the same
error upon boot, as others have posted, before:
modprobe: can't load module btrfs (kernel/fs/btrfs/btrfs.ko): unknown
symbol in module, or unknown parametr
(Without any further hints in dmegs, BTW)
The attached patch adds an entry to the list of hidden dependencies to
/usr/share/initramfs-tools/hook-functions to fix this issue. This also
renders the work-around proposed by Tristan unnecessary.
Thanks to WorMzy Tykashi for the actual analysis of the issue [0].
Regards
Markus Wanner
[0]: Mail by WorMzy Tykashi on the linux-btrfs list:
http://marc.info/?l=linux-btrfs&m=139370881713639&w=2
--- a/hook-functions 2014-07-14 14:27:43.32400 +0200
+++ b/hook-functions 2014-07-14 14:28:19.96000 +0200
@@ -512,7 +512,9 @@
hidden_dep_add_modules()
{
local modules=
- for dep in "lib/libcrc32c crc32c" "fs/ubifs/ubifs deflate zlib lzo"; do
+ for dep in "lib/libcrc32c crc32c" \
+ "fs/ubifs/ubifs deflate zlib lzo" \
+ "fs/btrfs/btrfs crc32c"; do
set -- $dep
if [ -f "${DESTDIR}/lib/modules/${version}/kernel/$1.ko" ]; then
shift
signature.asc
Description: OpenPGP digital signature
Bug#754834: squeeze-pu: package libdbi-perl/1.612-1+deb6u1
Hi Adam, On Mon, Jul 14, 2014 at 09:26:06PM +0100, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Mon, 2014-07-14 at 22:14 +0200, Salvatore Bonaccorso wrote: > > This is the corresponding proposed update for libdbi-perl as for > > wheezy, see [1], in case I'm still in time for squeeze-pu. Attached is > > proposed debdiff for squeeze. libplrpc-perl was removed from the > > archive for unstable[1] as it uses Storable in an unsafe way, leading > > to a remote code execution vulnerability. The idea is to also drop > > libplrpc-perl from squeeze. As first step again the dependency needs > > to be removed from libdbi-perl. > > > > [1] https://bugs.debian.org/751527 > > As mentioned on IRC, I think we should get this sorted for Squeeze, > despite being after the window officially closed. Please go ahead; > thanks. Thank you, uploaded. > > I'll clone the libplrpc-perl wheezy bug for squeeze. Sorry, haven't seen this reply before opening a new one myself, it is #754836. Thank you, Regards, Salvatore -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#745427: Pending fixes for bugs in the libdbi-perl package
tag 745427 + pending thanks Some bugs in the libdbi-perl package are closed in revision 7dec9cc6dda36fa400e63cbf86e2cb1d3a6a0f46 in branch ' squeeze' by Salvatore Bonaccorso The full diff can be seen at http://anonscm.debian.org/gitweb/?p=pkg-perl/packages/libdbi-perl.git;a=commitdiff;h=7dec9cc Commit message: Remove libplrpc-perl from Build-Depends and Depends Closes: #745427 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL
On 14/07/14 21:08, Toni Mueller wrote: >> > You forget one of the big problems with OpenSSL that LibreSSL doesn't >> > fix: the license. > Granted. Due to the amount of inherited code, it can't. We'll see how > things evolve as the amount of inherited code will dwindle. So, merely as a result of the licensing, we could have a fascinating situation whereby: * BSD-licensed software contemplates switching from OpenSSL to LibreSSL * GNU-licensed software keeps using OpenSSL with license exception, or maybe someday switches to GnuTLS So, this reduces the amount of software that could potentially switch from OpenSSL from LibreSSL. And since BSD and GNU software are unable to link against each other, it reduces the likelihood that something will indirectly link against OpenSSL and LibreSSL at the same time (the situation Russ Allbery described). So actually I think this simplifies things. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#714531: xserver-xorg-core: Xorg freezes with i915 intel_crtc_wait_for_pending_flips problem
On Thu, 11 Jul 2013 22:48:05 +0200 Francesco Poli wrote: > On Wed, 10 Jul 2013 22:31:25 +0200 Francesco Poli wrote: > > [...] > > I am currently trying to see what happens if I disable dpms in > > xscreensaver... > > After disabling dpms, I again experienced the slowness issue > similar to #682816. > After leaving the box with a locked display, I type my password, unlock > the X session and find that almost everything (especially the text > displayed inside XTerm windows) is repainted extremely slowly. > If I close all the graphical applications and try to exit from the X > session (which was started with startx), I never get back to the > console. Hence I cannot login again and the only way out is to press > the power button to shut the system down (luckily the power button > press event is handled and triggers a clean shutdown...). I had found out that the issue vanishes when using SNA acceleration. Hence, I set: $ cat /etc/X11/xorg.conf Section "Device" Identifier "Intel Graphics" Driver "intel" Option "AccelMethod" "sna" EndSection and I am keeping DPMS disabled. I have just given another try without forcing the SNA acceleration (that is to say, after moving /etc/X11/xorg.conf out of the way): I was again able to reproduce the slowness-and-never-get-back-to-console issue. Is there any progress on this issue? Has the bug been investigated? Has the report been forwarded upstream? I am looking forward to hearing back from the X Strike Force: thanks for your time and for any help you may provide. Olivier, did you manage to find out a (better) workaround? Do you still experience the freeze issue? Do you also experience the slowness issue? Please let me know: thanks for your time. -- http://www.inventati.org/frx/ fsck is a four letter word... . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpyxyMyetUWF.pgp Description: PGP signature
Bug#754835: swi-prolog: fix host cpu to set _JNI_LIB{DIRS,SUBDIRS} for ppc64el [FTBFS]
Source: swi-prolog
Version: 6.6.6-1
Severity: normal
Tags: patch
User: debian-powe...@lists.debian.org
Usertags: ppc64el
Dear Maintainer,
There is already a patch within debian/patches of source package swi-prolog
that attempts to
set _JNI_LIB{DIRS,SUBDIRS} for ppc64el.
However, the host_cpu should be powerpc64le rather than powerpc64el for the
path. So it fails
to build from source.
The patch attached makes that litle modification so the package builds
succesfully.
Thanks and regards.
Fernando
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: ppc64el (ppc64le)
Kernel: Linux 3.13-1-powerpc64le (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru swi-prolog-6.6.6/debian/patches/java-fixes.diff swi-prolog-6.6.6/debian/patches/java-fixes.diff
--- swi-prolog-6.6.6/debian/patches/java-fixes.diff 2014-06-10 20:19:56.0 +
+++ swi-prolog-6.6.6/debian/patches/java-fixes.diff 2014-07-14 19:34:31.0 +
@@ -8,7 +8,7 @@
+ _JNI_LIBDIRS="lib/ppc64"
+ _JNI_LIBSUBDIRS="server"
+ ;;
-+ powerpc64el)
++ powerpc64le)
+ _JNI_LIBDIRS="lib/ppc64le"
+ _JNI_LIBSUBDIRS="server"
+ ;;
Bug#754834: squeeze-pu: package libdbi-perl/1.612-1+deb6u1
Control: tags -1 + confirmed On Mon, 2014-07-14 at 22:14 +0200, Salvatore Bonaccorso wrote: > This is the corresponding proposed update for libdbi-perl as for > wheezy, see [1], in case I'm still in time for squeeze-pu. Attached is > proposed debdiff for squeeze. libplrpc-perl was removed from the > archive for unstable[1] as it uses Storable in an unsafe way, leading > to a remote code execution vulnerability. The idea is to also drop > libplrpc-perl from squeeze. As first step again the dependency needs > to be removed from libdbi-perl. > > [1] https://bugs.debian.org/751527 As mentioned on IRC, I think we should get this sorted for Squeeze, despite being after the window officially closed. Please go ahead; thanks. I'll clone the libplrpc-perl wheezy bug for squeeze. 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#686869: BinkD upstream v1.0 now available
Marco, On 06/14/2014 09:55 PM, Marco d'Itri wrote: The new 1.0.2 package is available in my git tree: http://anonscm.debian.org/gitweb/?p=users/md/binkd.git So far it builds... If there will be no comments from anybody then I will probably try to install it on my system and upload it next week. Have you had a chance to do that yet? Took me longer than I'd hoped to get to it but I'm running a test build (branched from your 'next' branch) on one system and will likely do another test build (for jessie) to use until an official package is available. (Specifically, I want to test IPv6 connections.) Robert James Clay j...@rocasa.us rjc...@gmail.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#754834: squeeze-pu: package libdbi-perl/1.612-1+deb6u1
Package: release.debian.org
Severity: normal
Tags: squeeze
User: release.debian@packages.debian.org
Usertags: pu
Hi release team
This is the corresponding proposed update for libdbi-perl as for
wheezy, see [1], in case I'm still in time for squeeze-pu. Attached is
proposed debdiff for squeeze. libplrpc-perl was removed from the
archive for unstable[1] as it uses Storable in an unsafe way, leading
to a remote code execution vulnerability. The idea is to also drop
libplrpc-perl from squeeze. As first step again the dependency needs
to be removed from libdbi-perl.
[1] https://bugs.debian.org/751527
Thanks for considering,
Regards,
Salvatore
diff -Nru libdbi-perl-1.612/debian/changelog libdbi-perl-1.612/debian/changelog
--- libdbi-perl-1.612/debian/changelog 2010-07-18 20:02:53.0 +0200
+++ libdbi-perl-1.612/debian/changelog 2014-07-14 22:02:32.0 +0200
@@ -1,3 +1,15 @@
+libdbi-perl (1.612-1+deb6u1) squeeze; urgency=low
+
+ * Team upload.
+ * Remove libplrpc-perl from Build-Depends and Depends (Closes: #745427)
+ * warn users of DBI::Proxy about its unsafe usage of Storable
+patch by Petr Písař from
+https://rt.cpan.org/Public/Bug/Display.html?id=90475
+ * Add dont-install-dbiproxy-script.patch patch.
+Don't install dbiproxy script into /usr/bin.
+
+ -- Salvatore Bonaccorso Mon, 14 Jul 2014 21:59:37 +0200
+
libdbi-perl (1.612-1) unstable; urgency=low
* New upstream release.
diff -Nru libdbi-perl-1.612/debian/control libdbi-perl-1.612/debian/control
--- libdbi-perl-1.612/debian/control 2010-07-18 20:02:53.0 +0200
+++ libdbi-perl-1.612/debian/control 2014-07-14 22:02:32.0 +0200
@@ -7,7 +7,7 @@
gregor herrmann , Ryan Niebur ,
Jonathan Yu , Ansgar Burchardt
Build-Depends: perl, debhelper (>= 7.0.50~),
- libplrpc-perl, libtest-pod-perl, libtest-pod-coverage-perl,
+ libtest-pod-perl, libtest-pod-coverage-perl,
perl (>= 5.10.1) | libtest-simple-perl (>= 0.90)
Standards-Version: 3.9.0
Homepage: http://dbi.perl.org/
@@ -16,7 +16,7 @@
Package: libdbi-perl
Architecture: any
-Depends: ${misc:Depends}, ${perl:Depends}, ${shlibs:Depends}, libplrpc-perl
+Depends: ${misc:Depends}, ${perl:Depends}, ${shlibs:Depends}
Provides: perl-dbdabi-${perl-dbdabi-version}
Breaks: libdbd-anydata-perl (<< 0.09+),
libdbd-csv-perl (<< 0.3000),
diff -Nru libdbi-perl-1.612/debian/patches/Security-notice-for-Proxy.patch libdbi-perl-1.612/debian/patches/Security-notice-for-Proxy.patch
--- libdbi-perl-1.612/debian/patches/Security-notice-for-Proxy.patch 1970-01-01 01:00:00.0 +0100
+++ libdbi-perl-1.612/debian/patches/Security-notice-for-Proxy.patch 2014-07-14 22:02:32.0 +0200
@@ -0,0 +1,56 @@
+From cd8fcbbf402e1d70c9f325f8b0fcd99e02cf14be Mon Sep 17 00:00:00 2001
+From: Petr Písař
+Date: Mon, 18 Nov 2013 12:52:09 +0100
+Subject: [PATCH] Security notice for Proxy
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+Bug: https://rt.cpan.org/Public/Bug/Display.html?id=90475
+
+PlRPC is not secure due to Storable. Warn Proxy users about it.
+
+Signed-off-by: Petr Písař
+---
+ lib/DBD/Proxy.pm | 7 +++
+ lib/DBI/ProxyServer.pm | 7 +++
+ 2 files changed, 14 insertions(+)
+
+diff --git a/lib/DBD/Proxy.pm b/lib/DBD/Proxy.pm
+index 287b2dc..5948255 100644
+--- a/lib/DBD/Proxy.pm
b/lib/DBD/Proxy.pm
+@@ -974,6 +974,13 @@ The workaround is storing the modified local copy back to the server:
+ $dbh->{"csv_tables"} = $tables;
+
+
++=head1 SECURITY WARNING
++
++L used underneath is not secure due to serializing and
++deserializing data with L module. Use the proxy driver only in
++trusted environment.
++
++
+ =head1 AUTHOR AND COPYRIGHT
+
+ This module is Copyright (c) 1997, 1998
+diff --git a/lib/DBI/ProxyServer.pm b/lib/DBI/ProxyServer.pm
+index 68ad4af..78a0d78 100644
+--- a/lib/DBI/ProxyServer.pm
b/lib/DBI/ProxyServer.pm
+@@ -867,6 +867,13 @@ Don't try to put parameters into the sql-query like this:
+ =back
+
+
++=head1 SECURITY WARNING
++
++L used underneath is not secure due to serializing and
++deserializing data with L module. Use the proxy driver only in
++trusted environment.
++
++
+ =head1 AUTHOR
+
+ Copyright (c) 1997Jochen Wiedmann
+--
+1.8.3.1
+
diff -Nru libdbi-perl-1.612/debian/patches/dont-install-dbiproxy-script.patch libdbi-perl-1.612/debian/patches/dont-install-dbiproxy-script.patch
--- libdbi-perl-1.612/debian/patches/dont-install-dbiproxy-script.patch 1970-01-01 01:00:00.0 +0100
+++ libdbi-perl-1.612/debian/patches/dont-install-dbiproxy-script.patch 2014-07-14 22:02:32.0 +0200
@@ -0,0 +1,17 @@
+Description: Don't install /usr/bin/dbiproxy
+Origin: vendor
+Forwarded: no
+Author: Salvatore Bonaccorso
+Last-Update: 2014-06-10
+
+--- a/Makefile.PL
b/Makefile.PL
+@@ -120,7 +120,7 @@ my %opts = (
+ 'DBD::PO' => '2.10',
+ },
+ LICENSE => 'perl',
+-EXE_FILES => [ "dbiproxy$ext_pl", "dbiprof$ext_pl", "dbilogstrip$ext_pl" ],
++EXE_FIL
Bug#753444: Bug#753542: perl-base - Segfaults in libperl.so.5.18
On Mon, 14 Jul 2014 21:40:42 +0200, Emilio Pozuelo Monfort wrote: > On 13/07/14 20:12, Aurelien Jarno wrote: > > On Sun, Jul 13, 2014 at 03:19:51PM +0200, gregor herrmann wrote: > >> - libsereal-* FTBFS on various architectures and are perfect removal > >> candidates from testing (#742409 and #750770). > >> hm, except that libsession-storage-secure-perl depends on them, > >> which is depended upon by libdancer-session-cookie-perl. hm. > > This one is missing support for big-endian architectures. > These got uploaded with fixes. libsereal-decoder-perl built fine, but > libsereal-encoder-perl (built against the new libsereal-decoder-perl) failed. Right, too bad ... It almost builds everywhere, only sparc and s390x fail. I'm going to update https://github.com/Sereal/Sereal/issues/47 with these new results once all build logs are in (or before I go to bed, whatever happens first). Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/ `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- NP: Rolling Stones signature.asc Description: Digital Signature
Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL
Hi Jeroen, On Sun, Jul 13, 2014 at 12:22:49PM +0200, Jeroen Dekkers wrote: > At Sat, 12 Jul 2014 14:46:45 +0200, Toni Mueller wrote: > > Ok, but for whatever reason, they have an imho not as shiny track > > record, as has OpenBSD. Which is no wonder, given all the revelations we > > have had recently, but hey, sometimes one has to make a decision. > > OpenSSL was part of OpenBSD before they created the LibreSSL fork, so > how isn't OpenSSL part of the OpenBSD track record? it is in the way that they include it, and it also contributed a significant amount of all patches that were required over the years, but the typical way OpenBSD operates - from my perspective - is, they include something (eg. Sendmail), and once they get fed up with it for whatever reason, unless they find something acceptable out there (eg. nginx instead of Apache, or nsd(?)+unbound instead of BIND), they start to roll their own. A few releases later, the old stuff is being demoted or removed entirely (eg. for RAIDframe -> softraid, the switchover period where you could choose was more than four years, afair). Such changes do happen in a disruptive manner, as there is usually nothing that aids you in converting your setup from the old to the new software. > It depends on how you look at it. If you see the OpenSSL API as > something that isn't really well designed then other libraries not > copying the API is actually a good thing. Yes and no, but if it is more than ten times the amount of work, it is likely never getting done, for the simple reason that everyone is lacking resources. > You forget one of the big problems with OpenSSL that LibreSSL doesn't > fix: the license. Granted. Due to the amount of inherited code, it can't. We'll see how things evolve as the amount of inherited code will dwindle. > It actually makes the mess even bigger, given that > some of the GPL exceptions only talk about "the OpenSSL library" and > don't exempt OpenSSL-derived code. So even if LibreSSL is a drop-in > for OpenSSL we can't replace OpenSSL with LibreSSL for those projects. Yes. Thanks for pointing this out. > You also forget to list two other TLS libraries: > > * NSS, in my opinion the biggest downside of NSS is that it includes > NSPR. This both increases the code size a lot and makes the API less > nice if I remember correctly. Hmmm... yes. I was under the impression that not very many people were using it, but looking at my system, NSS + NSPR ~ 3,5MB, while libssl1.0.0 comes in at ~3MB. Add ~1MB for sqlite3 and zlib1g in the case of NSS... > * PolarSSL, which I really like from a technical point of > view. Featurewise it is pretty complete (the only major feature it > doesn't implement is DTLS AFAICS), while being one tenth the size of > OpenSSL / GnuTLS: > > https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations#Code_size_and_dependencies > PolarSSL is also used by OpenVPN-NL, the hardened OpenVPN version > that is used by the Dutch government. > The downsides are that it looks like it doesn't have a stable API > and contributing needs copyright assignment because it is > dual-licensed. It still gets 5 out of 16 answers wrong, as per the comparison sheet included here: https://www.cs.utexas.edu/~shmat/shmat_oak14.pdf Kind regards, --Toni++ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#752114: needrestart: bug-script runs /usr/games/pacman when trying to use ArchLinux's pacman package manager in /etc/needrestart/hook.d/30-pacman
wb Patrick, On 07/14/2014 10:11 AM, Patrick Matthäi wrote: rpm should be kept, right. But I tend to remove the 30-pacman script, since pacman (the package manager) is not packaged for Debian. Any other opinions? ACK - I don't like to drop it upstream... since I'm trying to keep upstream multi distri compatible. Droping 30-pacman during package building looks good. Thanks, Thomas -- :: WWW: http://fiasko-nw.net/~thomas/ :: ::: Jabber: xmpp:tho...@jabber.fiasko-nw.net ::: :: flickr: http://www.flickr.com/photos/laugufe/ :: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#746863: FTBFS src:insighttoolkit4
Hi, First, please note I made an error regarding the GCCXML bug tracker -- it is still in the old location. However, Steve's patch has now been merged upstream. I was able to reproduce the build error, but it only occurs when using the gccxml package. The build completes fine with a local build of upstream GCCXML Git master. But, after examining the sources of the package [1] and comparing to Git master, significant differences are not apparent. As a result, I suspect it has to do with how GCCXML finds its default include's. Punting to Brad King or others for input on this. Thanks, Matt [1] https://packages.debian.org/sid/gccxml On Sun, Jul 13, 2014 at 12:30 PM, Matt McCormick wrote: > I will see if I can reproduce the build error. > > As a side note, the GCCXML bug tracker has moved (now at the > gccxml/gccxml project on GitHub). I've created a pull request for > Steve's stl algo patch here: > > https://github.com/gccxml/gccxml/pull/8 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#754740: Avoiding gender-specific language
Hi Justin,
thanks a million and apologies for the mistakes.
Please, find attached a new patch where all your suggestions have been
applied. I also analyzed (using grep) all the other files in the same
directory for gender-specific language and corrected some other
occurrences. Among them, there's the one you spotted in kernel.sgml:
thanks a lot!
On 14/07/14 19:21, Justin B Rye wrote:
> ^^^
> Except that now my eyes drift to the previous paragraph, which talks
> about the boot-floppies package, last seen in... what, Potato?
Unfortunately I do not have yet enough knowledge to correct those kind
of semantic mistakes.
Please, find the latest patch attached.
All the best,
Myriam
There
> are some intimidating cobwebs in here.
>
>> Index: pkg_basics.sgml
>> ===
>> --- pkg_basics.sgml (revision 10421)
>> +++ pkg_basics.sgml (working copy)
> [...]
>>package foo once foo has been unpacked from its Debian
>>archive (".deb") file. Often, 'postinst' scripts ask the user for input,
>> - and/or warn the user that if he accepts default values, he should remember
>> + and/or warn the users that if they accepted default values, they should
>> remember
>
> Make that
> archive (".deb") file. Often, 'postinst' scripts ask users for input,
> and/or warn them that if they accept default values, they should remember
>
>>to go back and re-configure that package as the situation warrants.
>>Many 'postinst' scripts then execute any commands necessary to start or
>>restart a service once a new package has been installed or upgraded.
> [...]
>>
>> Their meanings are:
>>
>> - unknown - the user has never indicated whether he wants the package
>> - install - the user wants the package installed or upgraded
>> - remove - the user wants the package removed, but does not want to
>> + unknown - users have never indicated whether they want the package
>> + install - users want the package installed or upgraded
>> + remove - users want the package removed, but do not want to
>
> I don't think this works (it sounds as if the users on any given
> machine decide things like this communally). Instead, just change the
> first one to
>
> unknown - the user has never indicated whether the package is
> wanted
>
> [...]
>> - hold - the user wants this package not to be processed, i.e., he
>> -wants to keep the current version with the current status whatever that
>> is.
>> + hold - users want this package not to be processed, i.e., they
>> +want to keep the current version with the current status whatever that
>> is.
>
> Try:
> hold - the user wants this package not to be processed, or in
> other words
>wants to keep the current version with the current status whatever
> that is.
>
> [...]
>>
>> - guide the user as he/she chooses among packages to install or
>> remove,
>> + guide the users as they choose among packages to install or remove,
>> ensuring that no packages are installed that conflict with one another,
>> and that all packages required to make each package work properly are
>> installed;
>> - warn the user about inconsistencies or incompatibilities in their
>> + warn the users about inconsistencies or incompatibilities in their
>> selections;
>>determine the order in which the packages must be installed;
>>automatically perform the installation or removal; and
>> - guide the user through whatever configuration process are required
>> + guide the users through whatever configuration process are required
>> for each package.
>
> These are all okay-ish, but would be more idiomatic if you dropped the
> article - that is, s/the user/users/. Wait... is this is talking
> about dselect?
>
>> ^^^
> You missed one here! Tricky, but "on the system" would do.
>
>> After choosing this menu item, the user is first presented with a full
>> screen of help (unless the `--expert' command line option was used).
>> -Once the user exits the Help screen, he sees the split-screen menu for
>> +Once exiting the Help screen, a user sees the split-screen menu for
>> choosing packages to install (or remove).
>
> Oh, a good idea, but you can't do it with "once", and you can't turn
> "the" user (definite in the previous sentence) into "a" user. It
> would work as:
>
>On exiting the Help screen, the user sees the split-screen menu for
>
Index: choosing.sgml
===
--- choosing.sgml (revision 10421)
+++ choosing.sgml (working copy)
@@ -177,7 +177,7 @@
So on June 20, both testing and unstable have
XYZ-3.7 in their repositories.
Let's say, The user of testing distribution sees
-that a new XYZ package is available and updates his XYZ-3.6 to XYZ-3.7
+that a new XYZ pack
Bug#754832: debian-maintainers: Annual ping for Michael Ziegler
Package: debian-maintainers Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear Maintainer, here's my annual ping. Regards, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJTxDJTAAoJEEn0ejpI+BVDBNcH/1EzaME5ETC/jraMmAYfW0Uh nvdI7mKbCkm5u1DNzQkG6+dP/3VhGAvN9fFIZHH/lhicqIVNTQAs2isoJT66k+68 5NrKFbmtetSCtYoMHsmIfEBh5PkTJ6ldKolj8UfpOfBv5fJS1+ZIKTq7qK6zep0P +5M5zSQbrM4rN3xK37qk204P9pDz1j0IvD6LgzumM4moXPy6ERiyBVpzcfxXeLjY Y2RFlfs+xx5pibS0XehSKYfktS3bFBh6LSmtNsT4I2rT54OXTuAOt5InOILthRJ9 A57CUUq6c4ZBalcFiqBOeNOimDyELxoYTJ8Y8HX7+X/29RDO3zstFagheCUZEFk= =jthp -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#754833: zipios++: please include dh-autoreconf to build properly on new architectures
Source: zipios++
Version: 0.1.5.9+cvs.2007.04.28-5.1
Severity: normal
Tags: patch
User: debian-de...@lists.debian.org
Usertags: autoreconf
User: debian-powe...@lists.debian.org
Usertags: ppc64el
Dear Maintainer,
Although the package zipios++ builds from source, in ppc64el, it fails to
generate and
install the shared object, which is needed so the lib works properly.
Running autoreconf will update the package accordingly and it will build
successfully,
with the shared object.
Please consider the patch attached.
Thanks.
Fernando
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: ppc64el (ppc64le)
Kernel: Linux 3.13-1-powerpc64le (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -u zipios++-0.1.5.9+cvs.2007.04.28/debian/control zipios++-0.1.5.9+cvs.2007.04.28/debian/control
--- zipios++-0.1.5.9+cvs.2007.04.28/debian/control
+++ zipios++-0.1.5.9+cvs.2007.04.28/debian/control
@@ -2,7 +2,7 @@
Section: devel
Priority: optional
Maintainer: Masayuki Hatta (mhatta)
-Build-Depends: automake | automaken, debhelper (>> 4.0.0), doxygen, dpatch, graphicsmagick-imagemagick-compat, libcppunit-dev, libz-dev
+Build-Depends: automake | automaken, dh-autoreconf, debhelper (>> 4.0.0), doxygen, dpatch, graphicsmagick-imagemagick-compat, libcppunit-dev, libz-dev
Standards-Version: 3.8.0
Package: libzipios++-dev
diff -u zipios++-0.1.5.9+cvs.2007.04.28/debian/rules zipios++-0.1.5.9+cvs.2007.04.28/debian/rules
--- zipios++-0.1.5.9+cvs.2007.04.28/debian/rules
+++ zipios++-0.1.5.9+cvs.2007.04.28/debian/rules
@@ -31,6 +31,7 @@
config.status: configure
dh_testdir
+ dh_autoreconf
# Add here commands to configure the package.
./configure --host=$(DEB_HOST_GNU_TYPE) --build=$(DEB_BUILD_GNU_TYPE) --prefix=/usr --mandir=\$${prefix}/share/man --infodir=\$${prefix}/share/info
@@ -56,12 +57,8 @@
rm -rf $(CURDIR)/doc/latex
rm -rf $(CURDIR)/doc/man
rm -rf $(CURDIR)/doc/images/zipios++.eps
- -test -r /usr/share/misc/config.sub && \
- cp -f /usr/share/misc/config.sub config.sub
- -test -r /usr/share/misc/config.guess && \
- cp -f /usr/share/misc/config.guess config.guess
-
+ dh_autoreconf_clean
dh_clean
install: build
Bug#753444: Bug#753542: perl-base - Segfaults in libperl.so.5.18
On 13/07/14 20:12, Aurelien Jarno wrote: > On Sun, Jul 13, 2014 at 03:19:51PM +0200, gregor herrmann wrote: >> - libsereal-* FTBFS on various architectures and are perfect removal >> candidates from testing (#742409 and #750770). >> hm, except that libsession-storage-secure-perl depends on them, >> which is depended upon by libdancer-session-cookie-perl. hm. > > This one is missing support for big-endian architectures. These got uploaded with fixes. libsereal-decoder-perl built fine, but libsereal-encoder-perl (built against the new libsereal-decoder-perl) failed. Emilio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#754831: [apt-listchanges] Program Crashes On Konsole Sessions
Package: apt-listchanges
Version: 2.85.13
Severity: important
--- Please enter the report below this line. ---
When run from a tty console, seems OK, but when run from a KDE Konsole-based
session, get the following:
No protocol specified
/usr/lib/python2.7/dist-packages/gtk-2.0/gtk/__init__.py:57: GtkWarning: could
not open display
warnings.warn(str(e), _gtk.Warning)
/usr/share/apt-listchanges/AptListChangesGtk.py:34: Warning: invalid (NULL)
pointer instance
self.glade = gtk.glade.XML("/usr/share/apt-listchanges/apt-
listchanges.glade")
/usr/share/apt-listchanges/AptListChangesGtk.py:34: Warning:
g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
self.glade = gtk.glade.XML("/usr/share/apt-listchanges/apt-
listchanges.glade")
/usr/share/apt-listchanges/AptListChangesGtk.py:34: GtkWarning:
IA__gtk_settings_get_for_screen: assertion 'GDK_IS_SCREEN (screen)' failed
self.glade = gtk.glade.XML("/usr/share/apt-listchanges/apt-
listchanges.glade")
/usr/share/apt-listchanges/AptListChangesGtk.py:34: Warning: g_object_get:
assertion 'G_IS_OBJECT (object)' failed
self.glade = gtk.glade.XML("/usr/share/apt-listchanges/apt-
listchanges.glade")
/usr/share/apt-listchanges/AptListChangesGtk.py:34: GtkWarning:
IA__gdk_pango_context_get_for_screen: assertion 'GDK_IS_SCREEN (screen)'
failed
self.glade = gtk.glade.XML("/usr/share/apt-listchanges/apt-
listchanges.glade")
/usr/share/apt-listchanges/AptListChangesGtk.py:34: PangoWarning:
pango_context_set_font_description: assertion 'context != NULL' failed
self.glade = gtk.glade.XML("/usr/share/apt-listchanges/apt-
listchanges.glade")
/usr/share/apt-listchanges/AptListChangesGtk.py:34: PangoWarning:
pango_context_set_base_dir: assertion 'context != NULL' failed
self.glade = gtk.glade.XML("/usr/share/apt-listchanges/apt-
listchanges.glade")
/usr/share/apt-listchanges/AptListChangesGtk.py:34: PangoWarning:
pango_context_set_language: assertion 'context != NULL' failed
self.glade = gtk.glade.XML("/usr/share/apt-listchanges/apt-
listchanges.glade")
/usr/share/apt-listchanges/AptListChangesGtk.py:34: Warning: g_object_unref:
assertion 'G_IS_OBJECT (object)' failed
self.glade = gtk.glade.XML("/usr/share/apt-listchanges/apt-
listchanges.glade")
/usr/share/apt-listchanges/AptListChangesGtk.py:34: GtkWarning:
IA__gdk_screen_get_display: assertion 'GDK_IS_SCREEN (screen)' failed
self.glade = gtk.glade.XML("/usr/share/apt-listchanges/apt-
listchanges.glade")
/usr/share/apt-listchanges/AptListChangesGtk.py:34: GtkWarning:
IA__gdk_keymap_get_for_display: assertion 'GDK_IS_DISPLAY (display)' failed
self.glade = gtk.glade.XML("/usr/share/apt-listchanges/apt-
listchanges.glade")
Segmentation fault
--- System information. ---
Architecture: amd64
Kernel: Linux 3.2.0-4-amd64
Debian Release: jessie/sid
500 unstableftp.us.debian.org
500 testing ftp.us.debian.org
500 sid linux.dropbox.com
--- Package information. ---
Depends (Version) | Installed
==-+-
python(>= 2.4) | 2.7.8-1
python-support (>= 0.90.0) | 1.0.15
apt (>= 0.5.3) | 1.0.6
python-apt (>= 0.7.93) | 0.9.3.8
ucf (>= 0.28) | 3.0030
debianutils (>= 2.0.2) | 4.4
dpkg-dev | 1.17.10
debconf (>= 0.5) | 1.5.53
OR debconf-2.0|
Package's Recommends field is empty.
Suggests (Version) | Installed
===-+-===
x-terminal-emulator |
www-browser |
python-glade2 | 2.24.0-3+b1
python-gtk2 | 2.24.0-3+b1
default-mta |
OR mail-transport-agent|
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#753785: [Python-modules-team] Bug#753785: flask-silk: please ship icons in a new package which does not depends on python
On Sun, Jul 13, 2014 at 8:35 AM, Sebastian Ramacher wrote: > Hi Dustin > > On 2014-07-08 18:34:45, Dustin Kirkland wrote: >> dget >> http://www.dustinkirkland.com/debian/famfamfam-silk/famfamfam-silk_1.3-1.dsc >> >> You might need my GPG key (which is signed by several DD's): 0xF1529469 >> http://keyserver.ubuntu.com:11371/pks/lookup?search=0xE2D9E1C5F9F5D59291F4607D95E64373F1529469&op=index >> http://keyserver.ubuntu.com:11371/pks/lookup?op=get&search=0x95E64373F1529469 >> >> Please let me know if you need anything else! > > Thanks for all you work on the icon set. Here are some comments: > > * The icons are released with the following restriction: > > As an author, I would appreciate a reference to my authorship of the Silk > icon set contents within a readme file or equivalent documentation for > the > software which includes the set or a subset of the icons contained > within. > >Please add this restriction to the copyright file. A Comment: after the >License: block is enough. Done. >Since the two readme files only mention CC-BY-2.5, please also add a line > to >the Comment: explaining that although CC-BY-3.0 is mentioned nowhere, it is >actually available under CC-BY-3.0 according to upstream's website. Done. >As I read CC-BY-3.0 it is enough to mention to license or add a link back > to >it. Since this is done in d/copyright, there is no need to patch a copy of >CC-BY-3.0 in. If the FTP masters want a copy of (or a link to) the license, >we would need to repack the orig tarball anyway to include it there. Okay. Any changes required by me, then? > * The debian/* paragraph in the copyright file needs to be moved after the * >paragraph. CF-1.0 contains the following note: > > Multiple Files paragraphs are allowed. The last paragraph that matches a > particular file applies to it. More general paragraphs should therefore > be > given first, followed by more specific overrides. Done. Thanks. Sorry about that. I knew that... Whoops. > * Please specify which source package version you want to use. I don't >care if you want to use 1.0 or 3.0 (quilt), but make it explicit in >debian/source/format. 3.0. Done. > * I think there is no point in installing readme.txt as it contains no >additional information. For readme.html to be useful, the image links need > to >be patched. After this has been fixed, registering readme.html with > doc-base >would be nice. Hmm, so I did that, created the patch, and it's over 1000 lines, touching basically every in that file. So, instead, I just created a single symlink in debian/links, that puts the icons dir in the doc location, so that those relative links work. This is a lot simpler and cleaner, in my opinion, than creating a thousand line patch against the upstream readme.html. As for registering with doc-base, does dh not just handle that for us already, since readme.html is in debian/docs? > * Please keep the Debian revsion at -1 until the version hit the archive. Done. >> Sure :-) Though it hasn't released in many, many years, and the zip >> file needs to be manually repacked to an .orig.tar.gz. > > With a watch file, uscan does the repacking for us with the --repack switch. > Since there is a watch file now, I think debian/README.source is unnecessary. Done. > Cheers > -- > Sebastian Ramacher Updated sources at: http://www.dustinkirkland.com/debian/famfamfam-silk Cheers, :-Dustin Dustin Kirkland Ubuntu Core Developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#754830: bluez: rfcomm and bluetoothd fail to start
Package: bluez
Version: 5.21-1
Severity: grave
/etc/init.d/bluetooth fails to start.
First:
Starting bluetooth: bluetoothd rfcomm/usr/bin/rfcomm: invalid option --
'f'
After editing the file and removing that option, next thing coms up:
Starting bluetooth: bluetoothd rfcommMissing dev parameter
Still, everything is reported with an [ ok ] message, which is confusing
at best.
I identified two other bug reports pointing in the same direction:
712386 [bluez] invalid option passed to rfcomm tool
737502 bluez: conffiles not removed
reported already on some experimental version.
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.14-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Versions of packages bluez depends on:
ii dbus 1.8.6-1
ii init-system-helpers 1.19
ii kmod 18-1
ii libc62.19-7
ii libdbus-1-3 1.8.6-1
ii libglib2.0-0 2.40.0-3
ii libreadline6 6.3-6
ii libudev1 204-14
ii lsb-base 4.1+Debian13
ii udev 204-14
bluez recommends no packages.
bluez suggests no packages.
-- Configuration Files:
/etc/init.d/bluetooth [Errno 2] No such file or directory:
'/etc/init.d/bluetooth'
Yes. The attempt to make it work:
--- /etc/init.d/bluetooth.orig 2014-06-27 21:50:43.0 +0200
+++ /etc/init.d/bluetooth.mine 2014-07-14 18:39:02.721719759 +0200
@@ -103,14 +103,17 @@
start_rfcomm()
{
- if [ -x $RFCOMM ] && [ -f $RFCOMM_CONF ] ; then
+# if [ -x $RFCOMM ] && [ -f $RFCOMM_CONF ] ; then
+ if [ -x $RFCOMM ] ; then
# rfcomm must always succeed for now: users
# may not yet have an rfcomm-enabled kernel
if [ "$VERBOSE" != no ]; then
log_progress_msg "${RFCOMM##*/}"
- $RFCOMM -f $RFCOMM_CONF bind all || :
+# $RFCOMM -f $RFCOMM_CONF bind all || :
+ $RFCOMM bind all || :
else
- $RFCOMM -f $RFCOMM_CONF bind all >/dev/null 2>&1 || :
+# $RFCOMM -f $RFCOMM_CONF bind all >/dev/null 2>&1 || :
+ $RFCOMM bind all >/dev/null 2>&1 || :
fi
fi
}
@@ -129,14 +132,17 @@
restart_rfcomm()
{
- if [ -x $RFCOMM ] && [ -f $RFCOMM_CONF ] ; then
+# if [ -x $RFCOMM ] && [ -f $RFCOMM_CONF ] ; then
+ if [ -x $RFCOMM ] ; then
if [ "$VERBOSE" != no ]; then
log_progress_msg "${RFCOMM##*/}"
$RFCOMM unbind all || :
- $RFCOMM -f $RFCOMM_CONF bind all || :
+# $RFCOMM -f $RFCOMM_CONF bind all || :
+ $RFCOMM bind all || :
else
$RFCOMM unbind all >/dev/null 2>&1|| :
- $RFCOMM -f $RFCOMM_CONF bind all >/dev/null 2>&1 || :
+# $RFCOMM -f $RFCOMM_CONF bind all >/dev/null 2>&1 || :
+ $RFCOMM bind all >/dev/null 2>&1 || :
fi
fi
}
-- 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#754709: mednafen: no longer buildable on powerpc/s390x/sparc: libtrio-dev missing
Control: block -1 747012 Hi Kibi, On Sun, 13 Jul 2014 17:07:25 +0200, Cyril Brulebois wrote: > your package can no longer be built on powerpc/s390x/sparc, presumably > since the following bug was resolved: > 1) #746817 Should build against and link with system's libtrio > [RESOLVED] > > given that libtrio is still uncompiled on those three archs: > https://buildd.debian.org/status/package.php?p=libtrio&suite=sid > > This means you have out-of-date binaries and your package can't migrate > to testing. Thanks for taking the time to file this. I've been working with libtrio's upstream to resolve this issue, and the necessary patches have now landed in upstream git. So libtrio should appear on powerpc/s390x/sparc reasonably soon... Regards, Stephen signature.asc Description: PGP signature
Bug#754829: [binutils-mingw-w64-i686] i686-w64-mingw32-windres running on s390x does not properly convert string
Package: binutils-mingw-w64-i686
Version: 2.24.51.20140617-1+3
Severity: normal
i686-w64-mingw32-windres running on s390x behaves differently when it
comes to strings.
s390x:
$ echo 'STRINGTABLE { 1, "String" }' | i686-w64-mingw32-windres
/* Type: stringtable
Name: 1. */
LANGUAGE 9, 1
STRINGTABLE MOVEABLE PURE DISCARDABLE
BEGIN
1, L"\x5300\x7400\x7200\x6900\x6e00\x6700"
END
amd64:
$ echo 'STRINGTABLE { 1, "String" }' | i686-w64-mingw32-windres
/* COFF information not part of RC
Time stamp: 1405365542
Type: stringtable
COFF information not part of RC
Time stamp: 1405365542
Name: 1
COFF information not part of RC
Time stamp: 1405365542. */
LANGUAGE 9, 1
STRINGTABLE MOVEABLE PURE DISCARDABLE
BEGIN
1, "String"
END
I would have expected the same output on the s390x and amd64 system.
It seems the endianness might be the cause of the different behavior.
The s390x architecture uses big endian.
I rebuild the binutils-mingw-w64-i686 debian package to make sure the issue
still occurs in the latest version.
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: s390x
Kernel: Linux 3.14-1-s390x (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Versions of packages binutils-mingw-w64-i686 depends on:
ii binutils 2.24.51.20140617-1
ii libc6 2.19-5
ii zlib1g1:1.2.8.dfsg-1
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#750681: uploaded to the archives
The package got uploaded to the archives without closing this bug. Doing so now. -- regards, Mattia Rizzolo GPG Key: 4096R/B9444540 http://goo.gl/I8TMB more about me: http://mapreri.org Launchpad User: https://launchpad.net/~mapreri Ubuntu Wiki page: https://wiki.ubuntu.com/MattiaRizzolo signature.asc Description: Digital signature
Bug#752870: #752870 not fixed by latest upload
Control: reopen -1 Hi there, as indicated by my later messages to the bug, the latest development version does not fix all the reported problems. I tested latest upload (0.2.32-2) from sid, and indeed the problems are still there, so I don't think this bug should be closed. Thanks, -- Rémi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#753500: RM: movabletype-opensource/4.3.8+dfsg-0+squeeze4
Hi, On Wed, 2014-07-02 at 17:00 +0200, Moritz Muehlenhoff wrote: > as briefly discussed on #debian-release. Please remove this package > in the 6.0.10 point release. It's not covered by squeeze-lts support > and debian-security-support marks existing packages as deprecated. How much were the decisions on what is (or, more to the point, isn't) covered in -lts based on discussion with the maintainers? > Removing it ensures that new squeeze installations (which can still > happen in some cases) odon't install an unsupported package. It make > tracking open issues easier. And the binaries can still be fetched > from snapshot.debian.org. I'm slightly in two minds about some of these, partly because some of the packages have been getting updates during squeeze's lifetime. 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#754828: xserver-xorg-video-nvidia: Installation broken in sid
Package: xserver-xorg-video-nvidia Severity: important Dear Maintainer, After upgrade, nvidia drivers were unusable in X. Attempting to install xserver-xorg-video-nvidia yielded: *** The following packages have unmet dependencies: xserver-xorg-video-nvidia : Depends: xorg-video-abi-15 but it is not installable or xorg-video-abi-14 but it is not installable or xorg-video-abi-13 but it is not installable or xorg-video-abi-12 but it is not installable or xorg-video-abi-11 but it is not installable or xorg-video-abi-10 but it is not installable or xorg-video-abi-8 but it is not installable or xorg-video-abi-6.0 but it is not installable Depends: xserver-xorg-core (< 2:1.15.99) but 2:1.15.99.904-1 is to be installed Recommends: nvidia-driver (>= 331.79) but it is not going to be installed Recommends: nvidia-vdpau-driver (>= 331.79) but it is not going to be installed Recommends: nvidia-kernel-dkms (= 331.79-1) or nvidia-kernel-331.79 Recommends: nvidia-settings (>= 331) but it is not installable E: Unable to correct problems, you have held broken packages. *** I "fixed" this by uninstalling all nvidia packages, and used nvidia's own installer to install the latest drivers, 340.24. My apologies if I filed this bug under the wrong package. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages xserver-xorg-video-nvidia depends on: ii debconf [debconf-2.0] 1.5.53 ii libc6 2.19-7 pn libgl1-nvidia-glx pn nvidia-alternative pn nvidia-installer-cleanup pn nvidia-support pn xorg-video-abi-15 | xorg-video-abi-14 | xorg-video-abi-13 ii xserver-xorg-core 2:1.15.99.904-1 Versions of packages xserver-xorg-video-nvidia recommends: pn nvidia-driver pn nvidia-kernel-dkms | nvidia-kernel-337.19 pn nvidia-settings pn nvidia-vdpau-driver Versions of packages xserver-xorg-video-nvidia suggests: pn nvidia-kernel-dkms | nvidia-kernel-source -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL
Hi Thomas,
On Sun, Jul 13, 2014 at 11:52:24AM +0800, Thomas Goirand wrote:
> On 07/12/2014 08:46 PM, Toni Mueller wrote:
> > As libressl is currently under
> > heavy development, it is imho not to be expected to have that stable ABI
> > you are asking for.
>
> Well, I don't agree with this view. If LibreSSL pretends to be a
> replacement for OpenSSL, then they should care about being ABI
> compatible,
but they are only partially compatible already. The one thing that
appears to stick out is that libressl has *no* support for egd, and on
purpose (ie, it will not come back). And the other is arc4random().
> so we can easily switch from one implementation to the
> other. Just like for MariaDB / MySQL in fact (not sure if these are
> still ABI compatible though). If that's not the case, then it looses a
> lot of its purpose. As Kurt wrote, GNUTLS becomes a better alternative then.
If your application does not use things which are deemed deprecated,
then it should be quite compatible, but by ripping out tons of old
stuff, they of course also break something, at some point. The whole API
becomes smaller simply because of that (I don't think this will be
offset by the added features in other areas, like adding better cipher
suites).
As for GnuTLS, all I read so far is that it requires a *lot* of work to
make a single application which has been developed together with
OpenSSL, compatible with GnuTLS, because apparently almost everything
differs to the point that it is unfeasible or impossible to have a
compatibility layer. That turns smaller adjustments in applications into
developing entirely different interfaces for each application, while
GnuTLS itself still lacks a lot of features. At the face of it, that
sounds like it is at least an order of magnitude more work, but likely
even much more than that. And add to that that GnuTLS apparently works
incorrectly almost half of the time (which translates to a significant
security *downgrade* in my eyes), there is a huge amount of work set for
those who would really try to fix it (ignoring the row between the
upstream author and the FSF aside for the moment).
> > OTOH, one guy already switched his entire Linux
> > system over, so far with no visible adverse effects.
>
> And then? This gives no clue if he had to rebuild everything that
> build-depended on OpenSSL...
That I don't know, but I have posed this question to the guy who made
that statement. I'll keep you posted.
> On 07/13/2014 01:15 AM, Russ Allbery wrote:
> > If you start using both for different packages, then you end up with
> > shared libraries conflicting over which libssl they want to use, and
> > then bad things start happening.
>
> Exactly! I fully agree with you on this.
I do not think that accidentically using one library when one wanted to
use the other will be an issue. FWIW, I've been told that a separate
"libressl.so" is in the making, and if so, binary incompatibility can be
taken for granted.
> This reminds me issues I had with mod-log-sql linked to MySQL and php
> as well, and when they were built against different versions... BOOM!
> I certainly do *not* want this kind of things to happen in Debian.
> Therefore, I'd very much prefer if we used OpenSSL *or* LibreSSL, but
> not have the choice between the 2, otherwise, that's a recipe for
> disaster.
Ummm... what was "BOOM" exactly, please? Because within a release,
OpenSSL ("letter") versions should all be compatible with each other.
> Please don't upload LibreSSL to Sid *ever*, unless we collectively
> decide that we are switching away from OpenSSL (and for which a
> discussion would have to start).
Well... as I said, I'm first and foremost planning to get it into
experimental, and then we can see what it really is, fix the packaging
etc.pp., and evaluate the package along the way. And while I hold the
OpenBSD developers in very high esteem, I am still a bit wary that the
package might be not as secure as we wish it to be, and therefore guess
that we want to evaluate the package thoroughly for some time before the
discussion about switching over can even start in a reasonable manner.
Having said that, I value all of your input, but feel not halfway as
much trigger happy as some of you seem to think I am.
Kind regards,
--Toni++
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#754827: Please make quilt provide/replace quilt-el
Package: quilt Version: 0.63-3 Severity: wishlist Hi Martin, On Mon, May 19, 2014 at 09:15:21PM +0200, Martin Quinson wrote: > I'll try to not forget to provide the package quilt-el from the quilt > source once quilt-el is removed, but I would appreciate a bug as a > reminder, just in case. As far as I can see this hasn't been done yet, so here's your bug ;-). (And it's even better if I get the bug submission right...) Regards, Stephen signature.asc Description: PGP signature
Bug#754825: libgnustep-gui0.24: Crashes when loading some XIBs
Package: libgnustep-gui0.24 Version: 0.24.0-2 Severity: serious Forwarded: http://savannah.gnu.org/bugs/index.php?42717 Control: affects -1 cenon.app Makes cenon.app unusable on i386 at least. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.14-1-686-pae (SMP w/1 CPU core) Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libgnustep-gui0.24 depends on: ii gnustep-base-runtime 1.24.6-2 ii gnustep-common [gnustep-fslayout-fhs] 2.6.6-2 ii gnustep-gui-common 0.24.0-2 ii libc6 2.19-7 ii libgcc11:4.9.0-10 ii libgif44.1.6-11 ii libgnustep-base1.241.24.6-2 ii libicu52 52.1-4 ii libjpeg8 8d1-1 ii libmagickcore5 8:6.7.7.10+dfsg-4 ii libobjc4 4.9.0-10 ii libpng12-0 1.2.50-1 ii libtiff5 4.0.3-10 libgnustep-gui0.24 recommends no packages. libgnustep-gui0.24 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#754200: kde-baseapps-bin: KDE fails to recognize keyboard backlight capabilities on fresh boot
A workaround is possible by creating a small script in ~.kde/env/ invoking: qdbus --system org.freedesktop.UPower For more info see: https://forum.kde.org/viewtopic.php?f=63&t=121045 This bug appears to be in KDE. The power manager which is relying on upower should start it before login to become aware of all the laptop capabilities. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#754740: Avoiding gender-specific language
myr wrote:
>> The text could also do with some general proofreading, but I'm not
>> sure if the version I get from "apt-get source" is up-to-date. For
>> instance, there's a use of "he" in kernel.sgml, but it occurs in a
>> sentence about /usr/sbin/modconf, which hasn't existed since Squeeze!
>
> The sources I'm using come from
> svn://svn.debian.org/svn/ddp/manuals/trunk/debian-faq/
> and the kernel.sgml that I have does not contain any instance of 'he'.
> It is dated 3rd of April 2008: is yours an older version?
Same version, but I was misreporting the regexp that matched;
kernel.sgml lines 45-6 have
prompting the user for particulars on the loadable device drivers
in his system. The responses are used to customize the file
^^^
Except that now my eyes drift to the previous paragraph, which talks
about the boot-floppies package, last seen in... what, Potato? There
are some intimidating cobwebs in here.
> Index: pkg_basics.sgml
> ===
> --- pkg_basics.sgml (revision 10421)
> +++ pkg_basics.sgml (working copy)
[...]
>package foo once foo has been unpacked from its Debian
>archive (".deb") file. Often, 'postinst' scripts ask the user for input,
> - and/or warn the user that if he accepts default values, he should remember
> + and/or warn the users that if they accepted default values, they should
> remember
Make that
archive (".deb") file. Often, 'postinst' scripts ask users for input,
and/or warn them that if they accept default values, they should remember
>to go back and re-configure that package as the situation warrants.
>Many 'postinst' scripts then execute any commands necessary to start or
>restart a service once a new package has been installed or upgraded.
[...]
>
> Their meanings are:
>
> - unknown - the user has never indicated whether he wants the package
> - install - the user wants the package installed or upgraded
> - remove - the user wants the package removed, but does not want to
> + unknown - users have never indicated whether they want the package
> + install - users want the package installed or upgraded
> + remove - users want the package removed, but do not want to
I don't think this works (it sounds as if the users on any given
machine decide things like this communally). Instead, just change the
first one to
unknown - the user has never indicated whether the package is wanted
[...]
> - hold - the user wants this package not to be processed, i.e., he
> -wants to keep the current version with the current status whatever that
> is.
> + hold - users want this package not to be processed, i.e., they
> +want to keep the current version with the current status whatever that
> is.
Try:
hold - the user wants this package not to be processed, or in
other words
wants to keep the current version with the current status whatever that
is.
[...]
>
> - guide the user as he/she chooses among packages to install or remove,
> + guide the users as they choose among packages to install or remove,
> ensuring that no packages are installed that conflict with one another,
> and that all packages required to make each package work properly are
> installed;
> - warn the user about inconsistencies or incompatibilities in their
> + warn the users about inconsistencies or incompatibilities in their
> selections;
>determine the order in which the packages must be installed;
>automatically perform the installation or removal; and
> - guide the user through whatever configuration process are required
> + guide the users through whatever configuration process are required
> for each package.
These are all okay-ish, but would be more idiomatic if you dropped the
article - that is, s/the user/users/. Wait... is this is talking
about dselect?
> After choosing this menu item, the user is first presented with a full
> screen of help (unless the `--expert' command line option was used).
> -Once the user exits the Help screen, he sees the split-screen menu for
> +Once exiting the Help screen, a user sees the split-screen menu for
> choosing packages to install (or remove).
Oh, a good idea, but you can't do it with "once", and you can't turn
"the" user (definite in the previous sentence) into "a" user. It
would work as:
On exiting the Help screen, the user sees the split-screen menu for
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#702030: Bug#754744: forbid most packages to depend on or recommend apparmor
Hi, [adding the SELinux team into the loop] Steve Langasek wrote (14 Jul 2014 05:44:44 GMT) : > Why should apparmor be automatically enabled when the userspace tools are > installed? Usability: the idea is to lower the barrier for using AppArmor on Debian. Learning how to install a package is one thing, learning how to edit /etc/default/grub without any mistake is another. Patrick and I want to make AppArmor available to the category of users who can learn how to do the former, but won't learn how to perform the latter any time soon. Also, it would make things easier for derivatives to enable AppArmor without messing with conffiles, and without patching the kernel to enable it their preferred LSM by default. > AFAIK this is inconsistent with how selinux is handled, which is > only enabled via an explicit boot option. I was not aware of that, thanks for pointing it out. @SELinux maintainers: is this behavior on purpose, or is it due to the historical lack of a facility (recently added by the /etc/default/grub.d support) to easily have a package append arguments to the kernel command-line? > Shouldn't we handle our LSMs symmetrically? Indeed, I think we should. I see several ways of keeping things consistent while reaching the aforementioned AppArmor usability goal: a) Having the SELinux equivalent of the apparmor package enable it by default too (and then, we'll need conflicts); I've no idea if this is feasible; one would need to look at the SELinux packages and their chain of reverse-dependencies. b) Implementing the behavior proposed by Patrick via a dedicated apparmor-$something configuration package. ftp-masters likely won't be happy with it (understandably), unless we demonstrate it's the best available solution to reach a sensible goal. The SELinux team is then free to create a corresponding package. c) A new package whose job is to select and enable a LSM (or none). Likely "none" would be the default for now. It's tempting to take benefit from debconf here. d) An apparmor-activate command, very similar to selinux-activate (from the selinux-basics package). The resulting user experience would be less friendly than "just install the apparmor package", but perhaps that's acceptable for now. Other ideas? SELinux maintainers, any thoughts on this? I've no idea what's the current situation wrt. SELinux policies in Debian — are they in a shape that warrants thinking of usability matters for the target userbase described above, or do potential users anyway have to play with a terminal and text editor as root? In other words, should we work on a shared solution to this problem, or should the AppArmor folks do their bit on their side, merely being careful not to break the SELinux usecases? > (Also, what happens if someone has already enabled selinux, then installs > this apparmor package which is intended to automatically enable apparmor?) The *last* LSM activated on the kernel command-line is the one that's enabled in practice (tested both ways). So, installing a apparmor package, that automatically enables this LSM, would override the previous manual enabling of SELinux. The reciprocal applies when running selinux-activate (which is arguably a more explicit choice made by the administrator than installing the apparmor package). IMO, both should first check if another LSM is enabled. > Regardless, I don't think this rises to the level of something that needs > to be documented in policy, at least at this point. Full ACK, we're not there yet. I suggest we drop 754744@ from the Cc list on next reply. Cheers, -- intrigeri -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#754824: systemd not user-friendly in case of a problem at boot time
Am 14.07.2014 19:28, schrieb Harald Dunkel: > Package: systemd > Version: 204-14 > > systemd takes >2 minutes to find out that a usb disk mentioned > in /etc/fstab is missing. And then it doesn't tell, but asks > me to examine more than 1 bazillion lines of system log to find > out where the problem might be. > > This could be improved, as it seems. If you boot without the "quiet" kernel command line option, systemd will tell which device it was waiting for when the timeout happened. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#754740: Avoiding gender-specific language
Hi David and Justin,
thanks a million for your valuable input!
On 14/07/14 15:26, Justin B Rye wrote:
> David Prévot wrote:
>> I’m no native English, but believe using singular they would be more
I took your advice and used the plural "they" for "users" in the patch
attached here.
> case above the "safe" option to cause the least annoyance to readers
> might be:
>
> specified by the Debian developer (or individual users if they choose
> to build the package themselves). This number corresponds to the revision
>
> or maybe
>
> specified by the Debian developer (or a user who chooses to rebuild
> the package locally). This number corresponds to the revision
I did apply your latter suggestion in the patch attached here.
>
> The text could also do with some general proofreading, but I'm not
> sure if the version I get from "apt-get source" is up-to-date. For
> instance, there's a use of "he" in kernel.sgml, but it occurs in a
> sentence about /usr/sbin/modconf, which hasn't existed since Squeeze!
>
The sources I'm using come from
svn://svn.debian.org/svn/ddp/manuals/trunk/debian-faq/
and the kernel.sgml that I have does not contain any instance of 'he'.
It is dated 3rd of April 2008: is yours an older version?
Thanks a million!
Myriam
Index: pkg_basics.sgml
===
--- pkg_basics.sgml (revision 10421)
+++ pkg_basics.sgml (working copy)
@@ -87,8 +87,7 @@
number may have formats as different as "19990513" and "1.3.8pre1".
The RRR component is the Debian revision number, and is
-specified by the Debian developer (or an individual user if he chooses
-to build the package himself). This number corresponds to the revision
+specified by the Debian developer (or a user who chooses to rebuild the package locally). This number corresponds to the revision
level of the Debian package, thus, a new revision level usually signifies
changes in the Debian Makefile (debian/rules), the Debian control
file (debian/control), the installation or removal scripts
@@ -195,7 +194,7 @@
This script typically completes any required configuration of the
package foo once foo has been unpacked from its Debian
archive (".deb") file. Often, 'postinst' scripts ask the user for input,
- and/or warn the user that if he accepts default values, he should remember
+ and/or warn the users that if they accepted default values, they should remember
to go back and re-configure that package as the situation warrants.
Many 'postinst' scripts then execute any commands necessary to start or
restart a service once a new package has been installed or upgraded.
@@ -365,14 +364,14 @@
Their meanings are:
- unknown - the user has never indicated whether he wants the package
- install - the user wants the package installed or upgraded
- remove - the user wants the package removed, but does not want to
+ unknown - users have never indicated whether they want the package
+ install - users want the package installed or upgraded
+ remove - users want the package removed, but do not want to
remove any existing configuration files.
- purge- the user wants the package to be removed completely,
+ purge- users want the package to be removed completely,
including its configuration files.
- hold - the user wants this package not to be processed, i.e., he
-wants to keep the current version with the current status whatever that is.
+ hold - users want this package not to be processed, i.e., they
+want to keep the current version with the current status whatever that is.
How do I put a package on hold?
Index: pkgtools.sgml
===
--- pkgtools.sgml (revision 10421)
+++ pkgtools.sgml (working copy)
@@ -239,15 +239,15 @@
- guide the user as he/she chooses among packages to install or remove,
+ guide the users as they choose among packages to install or remove,
ensuring that no packages are installed that conflict with one another,
and that all packages required to make each package work properly are
installed;
- warn the user about inconsistencies or incompatibilities in their
+ warn the users about inconsistencies or incompatibilities in their
selections;
determine the order in which the packages must be installed;
automatically perform the installation or removal; and
- guide the user through whatever configuration process are required
+ guide the users through whatever configuration process are required
for each package.
@@ -256,9 +256,9 @@
by using the arrow keys to move the highlighter bar, then pressing the
key to select the highlighted action.
-What the user sees next depends on the action he selected. If he selects
+What the users see next depends on the action they selected. If they select
any option but Access or Select, then Remove, then dselect would proceed to remove
Bug#508729: #508729 - nautilus: cannot delete files under a NFS-mounted volume
> Is it a remote drive ? maybe those drives do not support trash idk. Yes, it was a remote drive. Maybe that is the case. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#740137: transition: gnome-desktop3
Control: retitle -1 transition: gnome 3.12 Control: tags -1 confirmed On 25/05/14 13:05, Emilio Pozuelo Monfort wrote: > A status update. > > On 06/04/14 02:04, Emilio Pozuelo Monfort wrote: >> On 24/03/14 23:04, Julien Cristau wrote: >>> Control: tag -1 confirmed >>> >>> On Wed, Feb 26, 2014 at 08:06:36 +0100, Emilio Pozuelo Monfort wrote: >>> Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Another GNOME transition. For this one we have to wait till mid-March or so for gnome-desktop3 3.11.91 or .92 (beta and RC respectively), but I'm opening this now as I just rebuilt all the rdeps, and to let you know so we can plan in advance. The affected packages are: >>> Feel free to upload to sid. Please tag this bug pending when you do, >>> and ping us when you need binNMUs (ie source uploads are done and built >>> everywhere). >> >> I forgot to comment here. When I tested the new gnome-desktop with the sid >> rdeps >> rebuilt against it, I realized that gnome-settings-daemon had a few plugins >> that >> were failing because of the missing API (which didn't trigger a build failure >> because they are plugins...). I was able to fix a few but one or two >> important >> ones I couldn't fix because they relied on the removed API. What upstream has >> done is move that functionality to gnome-shell/mutter, so we need to update >> gnome-shell/mutter/gnome-settings-daemon/gnome-desktop at the same time (or >> at >> least that is my current understanding). Thus I'd like to do the other >> transitions (gnome-online-accounts, evolution-data-server) first, and leave >> this >> one for the end. > > Those were done now, but there's another one that needs to be done first: > upower > 0.99 (bugs are being filed, I suppose a transition bug will come soon). After > upower is done, I think the whole gnome-desktop/mutter/gjs/gnome-shell > transition could be done (with a few patches to keep using bluez 4 for now). I > need to check if there are any other problems and I'll also prepare it > (including those patches) to (try to) make the whole thing as smooth as > possible. upower has started now and bluez 5 is in sid, so let's go with this as there are no other conflicts. This will allow upower to finish, and upower can smooth-update so the two won't get entangled. Emilio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#754366: gecko-mediaplayer: please consider npapi-sdk-dev B-D
On 2014-07-10 12:55:01, Gabriele Giacone wrote: > Source: gecko-mediaplayer > Severity: wishlist > User: npapi-...@packages.debian.org > Usertags: b-d-switch > > Dear maintainer, > > your package Build-Depends on xulrunner-dev or iceweasel-dev. > If it only needs NPAPI headers, you might be interested in switching B-D > to npapi-sdk-dev, very small package providing them only, just landed to > unstable. I'd love to switch, but I haven't actually tried if it is possible and I don't have the motivation to do so. gecko-mediaplayer's build system contains a lot of old cruft and I don't feel like touching it. But if someone sends patches, I'm happy to apply them. Cheers -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#508729: #508729 - nautilus: cannot delete files under a NFS-mounted volume
Hi Rodrigo, ok thanks. Is it a remote drive ? maybe those drives do not support trash idk. cheers, althaser On 14 July 2014 18:25, Rodrigo Valiña Gutiérrez wrote: > > Could you please still reproduce this issue with newer nautilus version > > like 3.4.2-1+build1 or 3.8.2-3 ? > > Hi Pedro, > > I did a quick test with nautilus 3.4.2-1+build1 (Debian 7.6) and it > seems ok; works well. > > It warns about: > Cannot move file to trash, do you want to delete immediately? > The file "b" cannot be moved to the trash. > but then I can delete files. > > So maybe the bug no longer affects nautilus. > > Thanks. >
Bug#734634: freeipmi: new upstream version 1.3.4
Hi Sergei, Sorry that we have missed your "pull request". On Sat, 25 Jan 2014, Sergei Ianovich wrote: > Please test https://github.com/yanovich/freeipmi-debian.git > Repackaged v1.3.4 with a minor bugfix. > I've tried to be consistent with the existing policies. I have just pushed to alioth the freshly imported 1.4.4 sources (those need to come under upstream branch, not directly into master, which is for debian packaging layer). Would you mind updating your changes for the status of 1.4.4? (it seems not all of those patches you dropped were actually adopted upstream btw) I would also welcome you to join our FreeIPMI packaging team https://alioth.debian.org/projects/pkg-freeipmi/ -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist,Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#747907: [cmake] Patch from upstream
Package: cmake Version: 2.8.12.1-1.4 Hi, Patch [1] will help Please apply [1] http://www.cmake.org/Bug/file_download.php?file_id=5186&type=bug Bastien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#734634: [Pkg-freeipmi-devel] Bug#734634: Some work in Ubuntu
Would you be interested just to join the FreeIPMI maintenance team within Debian and help updating packaging for fresh FreeIPMI release (1.4.4): https://alioth.debian.org/projects/pkg-freeipmi/ ? On Wed, 09 Apr 2014, Robie Basak wrote: > Hi, > I looked at bringing this into Ubuntu ahead of Debian (and submit my > work here), though it looks like I need to defer this for now. I hope > some of my investigation is useful to anybody else who takes this up. > Sergei's branch was very helpful to me - thank you! I intended to pull > in your commits to Ubuntu had I finished this, but I didn't get that > far. > I also noticed that from current git HEAD I had to change > override_dh_fixperms to override_dh_fixperms-indep, since > etc/freeipmi/freeipmi.conf is only available when building > arch-dependent packages. Otherwise the build breaks when not building > indeps (eg. on other arches). > Full notes at: https://launchpad.net/bugs/1303692 -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist,Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
